Hello Rob, On Fri, 2019-10-25 at 10:47 -0500, Rob Herring wrote: > On Fri, Oct 25, 2019 at 9:37 AM Vaittinen, Matti > <Matti.Vaittinen@xxxxxxxxxxxxxxxxx> wrote: > > Hello Peeps, > > > > On Fri, 2019-10-25 at 08:24 -0500, Rob Herring wrote: > > > On Fri, Oct 25, 2019 at 2:07 AM Vaittinen, Matti > > > <Matti.Vaittinen@xxxxxxxxxxxxxxxxx> wrote: > > > The cases for not having child nodes are when you have child > > > nodes > > > with nothing more than a compatible and possibly provider > > > properties > > > (e.g. #gpio-cells for gpio providers). If you have other resource > > > dependencies (e.g. clocks) or data to define (e.g. voltages for > > > regulators), then child nodes absolutely make sense. > > > > Thanks for telling the reasoning behind. Makes sense. > > > > > Once we have > > > child nodes, then generally it is easier for every function to be > > > a > > > child node and not mix the two. I'm sure I have told people > > > incorrectly to not do child nodes because they define incomplete > > > bindings. > > > > Does this mean that if I add LED controlled node with LED nodes > > inside > > - then I should actually add sub nodes for clk and GPIO too? I > > would > > prefer still having the clk provider information in MFD node as > > adding > > a sub-node for clk would probably require changes in the > > bd718x7_clk > > driver. (Not big ones but avoidable if clk provider information can > > still dwell in MFD node). > > Probably not, if there's an existing structure to follow, then > continue doing that. Ok, thanks. > > > > I would group the led nodes under an led-controller node (with a > > > compatible). The simple reason is each level only has one > > > number/address space and you can't mix different ones. You're not > > > numbering the leds here, but could you (with numbers that > > > correspond > > > to something in the h/w, not just 0..N)? > > > > I don't know what that would be. The LED controller resides in MFD > > device in I2C bus and has no meaningful numbers I can think of. The > > actual LEDs (on my board) are dummy devices and I really don't know > > how > > to invent meaningfull numbers for them either. > > If you have something like "led control registers 1, 2, 3" where > 1,2,3 > is each LED channel, then use that. Unfortunately, no. LED controls are in same register. > Or if the LED supplies (or supply > pins) have some numbering, use that. I don't know how to format the numbering either. Currently planned PMIC package is so called "UCSP55M3C" meaning the pins are in a matrix - columns having numbers from 1 to 8 and rows having letters from A to J. In this case the LED outputs are F6 and H6. I don't know if different packaging is planned. Only 'constant' I can find is the output pin naming 'GRNLED' and 'AMBLED' :/ > If there's none of that, then > following standard node names kind of falls apart. '<generic name>-N' > is what I've been defining for some schema. So I could use node names led-1 and led-2 in the example, right? Br, Matti Vaittinen
