[UPSTREAM] Move backlight handling out of pcf50633 driver

[Sean McNeil]

Werner Almesberger wrote:
> Sean McNeil wrote:
>   
>> Can you make the max brightness a #define where it can be an arbitrary
>> value such as 100 or 255?
>>     
>
> Hmm, it does seem a little gratuituous, though.
>
> Let's see what happens to code if you make that change:
>
> - code that already reads max and scales accordingly:
>   keeps on working
>
> - code that "knows" the max value and scales accordingly:
>   keeps on working
>
> - code that assumes an incorrect max value and scales accordingly:
>   it never worked correctly, but it can now be fixed via the kernel
>
> The kernel already exposes all the information you need to use the
> interface correctly.
>
> With Andy's suggestion to also change the default max value, things
> get worse, because this also breaks code that thinks it knows the max
> value and scales accordingly. This code currently works, even though
> it takes an unsafe shortcut.
>
> So this means that, while fixing code that never worked, this change
> would break code that currently does. Also, it adds a bit of
> complexity to the kernel to solve what should be entirely a user
> space problem.
>
> By the way, introducing scaling to the kernel also loses information,
> since you no longer know how many steps are there in the ramp. An
> application may very well respond to "one step brighter" by doing a
> linear interpolation, followed by a check if the result is actually
> different, and using current+1 if it isn't, so that users always get
> a visible response when trying to make a change.
>
> So I would see this more like the kind of change you may make to
> test your set of user spaces to find improper use of the ABI (set max
> to 2 and WARN_ON any attempts to set a higher brightness :), but not
> something that you'd want to deploy as a general feature.
>
> - Werner
>   

This is the best reasoning I've seen to leave the value as-is. Thanks, 
Werner, for your insight. I still wouldn't mind a #define so it can be 
adjusted in the kernel in 1 place if necessary, but I'd have to say 
unilaterally changing to 0-255 is probably not a good idea as stated above.