Hi Biju,
On Fri, May 19, 2023 at 4:39 PM Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote:
> > -----Original Message-----
> > From: Conor Dooley <conor.dooley@xxxxxxxxxxxxx>
> > Sent: Friday, May 19, 2023 3:10 PM
> > To: Biju Das <biju.das.jz@xxxxxxxxxxxxxx>
> > Cc: Conor Dooley <conor@xxxxxxxxxx>; Rob Herring <robh+dt@xxxxxxxxxx>;
> > Krzysztof Kozlowski <krzysztof.kozlowski+dt@xxxxxxxxxx>; Conor Dooley
> > <conor+dt@xxxxxxxxxx>; Liam Girdwood <lgirdwood@xxxxxxxxx>; Mark Brown
> > <broonie@xxxxxxxxxx>; Geert Uytterhoeven <geert+renesas@xxxxxxxxx>;
> > Magnus Damm <magnus.damm@xxxxxxxxx>; devicetree@xxxxxxxxxxxxxxx; linux-
> > renesas-soc@xxxxxxxxxxxxxxx; Fabrizio Castro
> > <fabrizio.castro.jz@xxxxxxxxxxx>
> > Subject: Re: [PATCH v4 09/11] regulator: dt-bindings: Add Renesas
> > RAA215300 PMIC bindings
> >
> > On Fri, May 19, 2023 at 06:53:03AM +0000, Biju Das wrote:
> > > > Subject: Re: [PATCH v4 09/11] regulator: dt-bindings: Add Renesas
> > > > RAA215300 PMIC bindings
> > > >
> > > > On Thu, May 18, 2023 at 12:36:41PM +0100, Biju Das wrote:
> > > > > Document Renesas RAA215300 PMIC bindings.
> > > > >
> > > > > The RAA215300 is a high Performance 9-Channel PMIC supporting DDR
> > > > > Memory, with Built-In Charger and RTC.
> > > > >
> > > > > It supports DDR3, DDR3L, DDR4, and LPDDR4 memory power
> > requirements.
> > > > > The internally compensated regulators, built-in Real-Time Clock
> > > > > (RTC), 32kHz crystal oscillator, and coin cell battery charger
> > > > > provide a highly integrated, small footprint power solution ideal
> > > > > for System-On-Module (SOM) applications. A spread spectrum feature
> > > > > provides an ease-of-use solution for noise-sensitive audio or RF
> > > > > applications.
> > > > > + reg:
> > > > > + maxItems: 2
> > > > > +
> > > > > + reg-names:
> > > > > + items:
> > > > > + - const: main
> > > > > + - const: rtc
> > > >
> > > > > +required:
> > > > > + - compatible
> > > > > + - reg
> > > > > + - reg-names
> > > >
> > > > Out of curiosity as much as anything else, why do you need reg-names
> > > > if the two registers are always required?
> > >
> > > The device has always 2 address spaces and "reg-names" provides a
> > > means of clear differentiation compared to indices.
> > >
> > > By enforcing "reg-names" as required property, dt can do some
> > > schema-validation forcing users to specify "reg-names" in device tree.
> >
> > Is that not what we have the following for:
> > reg:
> > items:
> > - description: main register space...
> > - description: special sauce rtc stuff...
> > ?
>
> OK, will add description.
>
> >
> > The schema validation doesn't stop them putting in the wrong address
> > either way!
>
> OK, will drop reg-names from required property.
Please don't, as i2c_new_ancillary_device() does rely on the name
to set the address when overriding from the default.
> > > Implementation wise, we use "rtc" for getting resource details while
> > > creating the second i2c device which overrides the default address.
> > >
> > > Strictly speaking reg-names is not required, but from a validation
> > > perspective and since driver is using the same "resource-name" it is
> > > better to have it??
> >
> > If the order is set by the descriptions, reg-names seem superfluous
> > /shrug
We have plenty of these, as it turned out to be much easier for validation
to fix the order in the bindings than to support random order ;-)
Lots of Linux drivers that do use the names don't care about the order.
If all actual DTS used the same order, usually the order was fixed during
the text to json-schema conversion...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
