[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201125092137.ehwfytsrr3x5vkiy@axis.com>
Date: Wed, 25 Nov 2020 10:21:37 +0100
From: Vincent Whitchurch <vincent.whitchurch@...s.com>
To: Adam Ward <adam.ward@...semi.com>
CC: Mark Brown <broonie@...nel.org>, Rob Herring <robh+dt@...nel.org>,
"Liam Girdwood" <lgirdwood@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 1/9] regulator: Update DA9121 dt-bindings
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@axis.com/).
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?
Powered by blists - more mailing lists