src/sys/dev/led, branch release/12.3.0

MFC r343029:

2019-02-03T14:55:21Z

[led] propagate error from set_led() to the caller Do not lose error condition by always returning 0 from set_led. None of the calls to set_led checks for return value at the moment so none of API consumers in base is affected. PR: 231567 Submitted by: Bertrand Petit

SPDX: use the Beerware identifier.

2017-11-30T20:33:45Z

This implements default-state support as described in:

2015-05-24T07:45:42Z

https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/leds-gpio.txt Without this booting the VSATV102 causes the blue "working" led to turn off when the kernel starts up. With this the led (which is turned on by the firmware) stays on since that's the default state specified in the FDT. Expanded the meaning of the led_create_state state parameter in order to implement support for "keep". The original values were: == 0 Off != 0 On The new values are: == -1 don't change / keep current setting == 0 Off != -1 && != 0 On This should have no effect on acpi_asus_attach which only calls led_create_state with state set to 1. Updated acpi_ibm_attach in order to avoid surprises. Differential Revision: https://reviews.freebsd.org/D2615 Submitted by: John Wehle Reviewed by: gonzo, loos

MFcalloutng:

2013-02-19T19:25:50Z

Make led(4) fire callouts at 10Hz only when there is at least one LED that is requested to blink. Do not fire if all LEDs are static (usual case).

MFgraid/head r218174:

2011-03-24T08:56:12Z

Add simple in-kernel API for controlling leds.

Fix an incorrect use of sbuf_overflowed() after a call to sbuf_finish().

2010-09-09T18:35:08Z

(S)LIST_HEAD_INITIALIZER takes a (S)LIST_HEAD as an argument.

2009-12-28T22:56:30Z

Fix some wrong usages. Note: this does not affect generated binaries as this argument is not used. PR: 137213 Submitted by: Eygene Ryabinkin (initial version) MFC after: 1 month

Remove unit2minor() use from kernel code.

2008-09-26T14:19:52Z

When I changed kern_conf.c three months ago I made device unit numbers equal to (unneeded) device minor numbers. We used to require bitshifting, because there were eight bits in the middle that were reserved for a device major number. Not very long after I turned dev2unit(), minor(), unit2minor() and minor2unit() into macro's. The unit2minor() and minor2unit() macro's were no-ops. We'd better not remove these four macro's from the kernel, because there is a lot of (external) code that may still depend on them. For now it's harmless to remove all invocations of unit2minor() and minor2unit(). Reviewed by: kib

Add sbuf_new_auto as a shortcut for the very common case of creating a

2008-08-09T11:14:05Z

completely dynamic sbuf. Obtained from: Varnish MFC after: 2 weeks

Remove the distinction between device minor and unit numbers.

2008-05-29T12:50:46Z

Even though we got rid of device major numbers some time ago, device drivers still need to provide unique device minor numbers to make_dev(). These numbers are only used inside the kernel. They are not related to device major and minor numbers which are visible in devfs. These are actually based on the inode number of the device. It would eventually be nice to remove minor numbers entirely, but we don't want to be too agressive here. Because the 8-15 bits of the device number field (si_drv0) are still reserved for the major number, there is no 1:1 mapping of the device minor and unit numbers. Because this is now unused, remove the restrictions on these numbers. The MAXMAJOR definition was actually used for two purposes. It was used to convert both the userspace and kernelspace device numbers to their major/minor pair, which is why it is now named UMINORMASK. minor2unit() and unit2minor() have now become useless. Both minor() and dev2unit() now serve the same purpose. We should eventually remove some of them, at least turning them into macro's. If devfs would become completely minor number unaware, we could consider using si_drv0 directly, just like si_drv1 and si_drv2. Approved by: philip (mentor)