On Thu, Jan 15, 2015 at 08:24:26AM -0600, Rob Herring wrote: > On Tue, Jan 13, 2015 at 2:42 AM, Jacek Anaszewski > > I am aware that it may be tempting to treat LED devices as common > > regulators, but they have their specific features which gave a > > reason for introducing LED class for them. Besides, there is already > > drivers/leds/leds-regulator.c driver for LED devices which support only > > turning on/off and setting brightness level. > > > > In your proposition a separate regulator provider binding would have > > to be created for each current output and a separate binding for > > each discrete LED connected to the LED device. It would create > > unnecessary noise in a dts file. > > > > Moreover, using regulator binding implies that we want to treat it > > as a sheer power supply for our device (which would be a discrete LED > > element in this case), whereas LED devices provide more features like > > blinking pattern and for flash LED devices - flash timeout, external > > strobe and flash faults. > Okay, fair enough. Please include some of this explanation in the > binding description. Right, the other thing here is that these chips are not normally designed with the goal that the various components be used separately - I've seen devices where the startup and shutdown procedures involve interleaved actions to the boost regulator and current sink for example. Trying to insert an abstraction layer typically just makes life more complex.
Attachment:
signature.asc
Description: Digital signature
