Pavel Machek <pavel@xxxxxx> writes:
>
> Hi!
>
> > > > The includes/linux/leds.h diff:
> > > > -/* This is obsolete/useless. We now support variable maximum brightness. */
> > > > -enum led_brightness {
> > > > - LED_OFF = 0,
> > > > - LED_ON = 1,
> > > > - LED_HALF = 127,
> > > > - LED_FULL = 255,
> > > > -};
> > > > +// default values for leds brightness
> > > > +#define LED_OFF 0
> > > > +#define LED_ON 1
> > > > +#define LED_HALF 127
> > > > +#define LED_FULL 255
> > > >
> > > I'm not aware of the history of this, however I'm even less sure how
> > > converting these from an enum to #defines makes this any better.
> > >
> >
> > Yeah. The TODO says:
> > -* On/off LEDs should have max_brightness of 1
> > -* Get rid of enum led_brightness
> > -
> > -It is really an integer, as maximum is configurable. Get rid of it, or
> > -make it into typedef or something.
> >
> > I could only remove enum led_brightness, but in some places, the
> > LED_FULL, LED_HALF...
> > are used. This is why I created this #defines.
> > I don't know what we can do in these cases that LED_FULL, FULL_HALF is used.
> > For example, in the drivers/leds/leds-ss4200.c on line 223 have this code
> >
> > u32 setting = 0;
> > if (brightness >= LED_HALF)
> > setting = 1;
>
> Yep. Such drivers should be modified to set max_brightness to real
> number of steps hardware can do... then we can remove LED_HALF,
> LED_FULL and such defines.
>
> Best regards,
> Pavel
but this will require the effort of everyone who has already written drivers
for some LED hardware. Because only the driver author himself will know
all the steps for that specific LED.
or, maybe we can adapt this drivers for understand the brightness as a 0 or 1.
0 for OFF and 1 for HALF and FULL. This is possble ?
