On Fri, Nov 20, 2020 at 02:47:42PM +0100, Vincent Whitchurch wrote: > On Fri, Nov 20, 2020 at 01:14:50PM +0100, Adam Ward wrote: > > - buck1: > > - description: > > - Initial data for the Buck1 regulator. > > - $ref: "regulator.yaml#" > > + interrupt-parent: > > + maxItems: 1 > > + description: Specifies the reference to the interrupt controller. > > + > > + interrupts: > > + maxItems: 1 > > + description: IRQ line information. > > + > > + dlg,irq-polling-delay-passive: > > + maxItems: 1 > > + description: | > > + Specify the polling period, measured in milliseconds, between interrupt status > > + update checks. Range 1000-10000 ms. > > + > > + regulators: > > type: object > > + $ref: regulator.yaml# > > + description: | > > + This node defines the settings for the BUCK. The content of the > > + sub-node is defined by the standard binding for regulators; see regulator.yaml. > > + The DA9121 regulator is bound using their names listed below > > + buck1 - BUCK1 > > + buck2 - BUCK2 //DA9122, DA9220, DA9131, DA9132 only > > This move to a sub-node means that older devicetrees won't work. I > assume that's fine since the driver is only in linux-next at the moment, > but perhaps it's worth mentioning this in the commit message? Actually, perhaps I'm missing something, but I don't quite see why this move to a sub-node is needed. There is some flexibility in the regulator framework for this as I noted earlier (https://lore.kernel.org/lkml/20201102154848.tm5nsydaukyd7rrw@xxxxxxxx/). For the case of an MFD it certainly makes sense to have a "regulators" sub-node but for these chips it seems rather redundant. Also, perhaps you could split this patch into logical pieces too as Mark has suggested for some of the other patches in this series?
