All of lore.kernel.org
 help / color / mirror / Atom feed
From: "krzk@kernel.org" <krzk@kernel.org>
To: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
Cc: "daniel.baluta@nxp.com" <daniel.baluta@nxp.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"festevam@gmail.com" <festevam@gmail.com>,
	"vigneshr@ti.com" <vigneshr@ti.com>,
	"Anson.Huang@nxp.com" <Anson.Huang@nxp.com>,
	"aford173@gmail.com" <aford173@gmail.com>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"richard@nod.at" <richard@nod.at>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-imx@nxp.com" <linux-imx@nxp.com>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"miquel.raynal@bootlin.com" <miquel.raynal@bootlin.com>,
	"han.xu@nxp.com" <han.xu@nxp.com>,
	"lee.jones@linaro.org" <lee.jones@linaro.org>,
	"yibin.gong@nxp.com" <yibin.gong@nxp.com>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"jun.li@nxp.com" <jun.li@nxp.com>
Subject: Re: [PATCH 03/16] arm64: dts: imx8mm-beacon-som.dtsi: Align regulator names with schema
Date: Tue, 25 Aug 2020 10:27:37 +0200	[thread overview]
Message-ID: <20200825082737.GA12902@kozik-lap> (raw)
In-Reply-To: <3018d638b5753e629ebdb6a25973aeff7e446720.camel@fi.rohmeurope.com>

On Tue, Aug 25, 2020 at 08:22:18AM +0000, Vaittinen, Matti wrote:
> Hello Krzysztof,
> 
> On Tue, 2020-08-25 at 09:50 +0200, krzk@kernel.org wrote:
> > On Tue, Aug 25, 2020 at 09:45:00AM +0200, krzk@kernel.org wrote:
> > > On Tue, Aug 25, 2020 at 09:25:37AM +0200, krzk@kernel.org wrote:
> > > > On Tue, Aug 25, 2020 at 06:51:33AM +0000, Vaittinen, Matti wrote:
> > > > > Hello Krzysztof,
> > > > > 
> > > > > Just some questions - please ignore if I misunderstood the
> > > > > impact of
> > > > > the change.
> > > > > 
> > > > > On Mon, 2020-08-24 at 21:06 +0200, Krzysztof Kozlowski wrote:
> > > > > > Device tree schema expects regulator names to be
> > > > > > lowercase.  This
> > > > > > fixes
> > > > > > dtbs_check warnings like:
> > > > > > 
> > > > > >     arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dt.yaml: 
> > > > > > pmic@4b:
> > > > > > regulators:LDO1:regulator-name:0: 'LDO1' does not match
> > > > > > '^ldo[1-6]$'
> > > > > > 
> > > > > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > > > > > ---
> > > > > >  .../boot/dts/freescale/imx8mn-ddr4-evk.dts    | 22
> > > > > > +++++++++------
> > > > > > ----
> > > > > >  1 file changed, 11 insertions(+), 11 deletions(-)
> > > > > > 
> > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-
> > > > > > evk.dts
> > > > > > b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
> > > > > > index a1e5483dbbbe..299caed5d46e 100644
> > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
> > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
> > > > > > @@ -60,7 +60,7 @@
> > > > > >  
> > > > > >  		regulators {
> > > > > >  			buck1_reg: BUCK1 {
> > > > > > -				regulator-name = "BUCK1";
> > > > > > +				regulator-name = "buck1";
> > > > > 
> > > > > I am not against this change but I would expect seeing some
> > > > > other
> > > > > patches too? I guess this will change the regulator name in
> > > > > regulator
> > > > > core, right? So maybe I am mistaken but it looks to me this
> > > > > change is
> > > > > visible in suppliers, sysfs and debugfs too? Thus changing this
> > > > > sounds
> > > > > a bit like asking for a nose bleed :) Am I right that the
> > > > > impact of
> > > > > this change has been thoroughly tested? Are there any other
> > > > > patches
> > > > > (that I have not seen) related to this change?
> > > > 
> > > > Oh, crap, the names of regulators in the driver are lowercase,
> > > > but they
> > > > use of_match_ptr for upper case. Seriously, why making a binding
> > > > which
> > > > is contradictory to the driver implementation on the first day?
> > > > 
> > > > The driver goes with binding, right? One expects uppercase, other
> > > > lowercase...
> > > > 
> > > > And tell me, what is now the ABI? The binding or the incorrect
> > > > implementation?
> > > 
> > > Wait, my mistake. I got confused by my own change. The node name
> > > stays
> > > the same, so of_match will be correct.
> 
> Yes. I think so too. Match will still work as earler.
> 
> > > 
> > > The driver internally already uses lowercase names.
> 
> Yep. I was simply thinking that if anyone has been specifying the
> regulators as suppliers by name - then this change will change things
> (as is seen for LDO5). Additionally, if any user-space SW has been
> reading the regulator states from sysfs - then these names will also
> change the sysfs. Debugfs change is hopefully not such a big deal.

About user-space, I think the embedded DT is not part of kernel ABI, so
there is no such requirement about keeping it stable. I agree though it
might be annoying surprise.

> 
> Whether this really breaks anything is beyond my knowledge as I don't
> even have this board. Anyways, I think that by minimum the commit
> message should point out that this change will be visible outside DTS
> and the BD718x7 driver - up to the user-space.

Good point, I will extend the commit msg about possible impact and
fixing supplies.

> 
> > > 
> > > Everything looks good. I will just double check whether the
> > > constraints
> > > did not change on the board after boot.
> > 
> > Constraints look good.
> > 
> > > > > >  				regulator-min-microvolt =
> > > > > > <700000>;
> > > > > >  				regulator-max-microvolt =
> > > > > > <1300000>;
> > > > > >  				regulator-boot-on;
> > > > > > @@ -69,7 +69,7 @@
> > > > > >  			};
> > > > > >  
> > > > > >  			buck2_reg: BUCK2 {
> > > > > > -				regulator-name = "BUCK2";
> > > > > > +				regulator-name = "buck2";
> > > > > >  				regulator-min-microvolt =
> > > > > > <700000>;
> > > > > >  				regulator-max-microvolt =
> > > > > > <1300000>;
> > > > > >  				regulator-boot-on;
> > > > > > @@ -79,14 +79,14 @@
> > > > > >  
> > > > > >  			buck3_reg: BUCK3 {
> > > > > >  				// BUCK5 in datasheet
> > > > > > -				regulator-name = "BUCK3";
> > > > > > +				regulator-name = "buck3";
> > > > > >  				regulator-min-microvolt =
> > > > > > <700000>;
> > > > > >  				regulator-max-microvolt =
> > > > > > <1350000>;
> > > > > >  			};
> > > > > >  
> > > > > >  			buck4_reg: BUCK4 {
> > > > > >  				// BUCK6 in datasheet
> > > > > > -				regulator-name = "BUCK4";
> > > > > > +				regulator-name = "buck4";
> > > > > >  				regulator-min-microvolt =
> > > > > > <3000000>;
> > > > > >  				regulator-max-microvolt =
> > > > > > <3300000>;
> > > > > >  				regulator-boot-on;
> > > > > > @@ -95,7 +95,7 @@
> > > > > >  
> > > > > >  			buck5_reg: BUCK5 {
> > > > > >  				// BUCK7 in datasheet
> > > > > > -				regulator-name = "BUCK5";
> > > > > > +				regulator-name = "buck5";
> > > > > 
> > > > > What I see in bd718x7-regulator.c for LDO6 desc is:
> > > > > 
> > > > >                         /* LDO6 is supplied by buck5 */
> > > > >                         .supply_name = "buck5",
> > > > > 
> > > > > So, is this change going to change the supply-chain for the
> > > > > board? Is
> > > > > this intended? (Or am I mistaken on what is the impact of
> > > > > regulator-
> > > > > name property?)
> > > 
> > > Good point, let me check the supplies.
> > 
> > This patch actually fixes the supplies which before were not working
> > because of case mismatch.
> > Before:
> > 
> >  regulator                      use open bypass  opmode voltage
> > current     min     max
> > -------------------------------------------------------------------
> > --------------------
> >  regulator-dummy                  4    5      0
> > unknown     0mV     0mA     0mV     0mV
> >     LDO6                          1    0      0
> > unknown  1200mV     0mA   900mV  1800mV
> >  BUCK1                            1    0      0
> > unknown   850mV     0mA   700mV  1300mV
> >  BUCK2                            2    1      0
> > unknown  1000mV     0mA   700mV  1300mV
> >     cpu0-
> > cpu                      1                                 0mA  1000m
> > V  1000mV
> >  BUCK3                            1    0      0
> > unknown   975mV     0mA   700mV  1350mV
> >  BUCK4                            1    0      0
> > unknown  3300mV     0mA  3000mV  3300mV
> >  BUCK5                            1    0      0
> > unknown  1800mV     0mA  1605mV  1995mV
> >  BUCK6                            1    0      0
> > unknown  1200mV     0mA   800mV  1400mV
> >  LDO1                             1    0      0
> > unknown  1800mV     0mA  1600mV  1900mV
> >  LDO2                             1    0      0
> > unknown   800mV     0mA   800mV   900mV
> >  LDO3                             1    0      0
> > unknown  1800mV     0mA  1800mV  3300mV
> >  LDO4                             1    0      0
> > unknown   900mV     0mA   900mV  1800mV
> >  ldo5                             1    4      0
> > unknown  1800mV     0mA  1800mV  1800mV
> > 
> > 
> > 
> > After:
> >  regulator                      use open bypass  opmode voltage
> > current     min     max
> > -------------------------------------------------------------------
> > --------------------
> > buck1                            1    0      0
> > unknown   850mV     0mA   700mV  1300mV
> >  buck2                            2    1      0
> > unknown   850mV     0mA   700mV  1300mV
> >     cpu0-
> > cpu                      1                                 0mA   850m
> > V   850mV
> >  buck3                            1    0      0
> > unknown   975mV     0mA   700mV  1350mV
> >  buck4                            1    0      0
> > unknown  3300mV     0mA  3000mV  3300mV
> >  buck5                            2    1      0
> > unknown  1800mV     0mA  1605mV  1995mV
> >     ldo6                          1    0      0 
> 
> That was my point :) Before this commit the system has acted
> differently - either by accident or by purpose. In any case, the DTS
> change will change supply logic and this should probably be mentioned
> in commit log to help bisecting possible issues :)
> 
> But as I said, I am not opposed to this change - I am merely somewhat
> cautious with changes like this.

Thanks for the hints.

Best regards,
Krzysztof


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: "krzk@kernel.org" <krzk@kernel.org>
To: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
Cc: "daniel.baluta@nxp.com" <daniel.baluta@nxp.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"festevam@gmail.com" <festevam@gmail.com>,
	"vigneshr@ti.com" <vigneshr@ti.com>,
	"Anson.Huang@nxp.com" <Anson.Huang@nxp.com>,
	"aford173@gmail.com" <aford173@gmail.com>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"richard@nod.at" <richard@nod.at>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-imx@nxp.com" <linux-imx@nxp.com>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"miquel.raynal@bootlin.com" <miquel.raynal@bootlin.com>,
	"han.xu@nxp.com" <han.xu@nxp.com>,
	"lee.jones@linaro.org" <lee.jones@linaro.org>,
	"yibin.gong@nxp.com" <yibin.gong@nxp.com>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"jun.li@nxp.com" <jun.li@nxp.com>
Subject: Re: [PATCH 03/16] arm64: dts: imx8mm-beacon-som.dtsi: Align regulator names with schema
Date: Tue, 25 Aug 2020 10:27:37 +0200	[thread overview]
Message-ID: <20200825082737.GA12902@kozik-lap> (raw)
In-Reply-To: <3018d638b5753e629ebdb6a25973aeff7e446720.camel@fi.rohmeurope.com>

On Tue, Aug 25, 2020 at 08:22:18AM +0000, Vaittinen, Matti wrote:
> Hello Krzysztof,
> 
> On Tue, 2020-08-25 at 09:50 +0200, krzk@kernel.org wrote:
> > On Tue, Aug 25, 2020 at 09:45:00AM +0200, krzk@kernel.org wrote:
> > > On Tue, Aug 25, 2020 at 09:25:37AM +0200, krzk@kernel.org wrote:
> > > > On Tue, Aug 25, 2020 at 06:51:33AM +0000, Vaittinen, Matti wrote:
> > > > > Hello Krzysztof,
> > > > > 
> > > > > Just some questions - please ignore if I misunderstood the
> > > > > impact of
> > > > > the change.
> > > > > 
> > > > > On Mon, 2020-08-24 at 21:06 +0200, Krzysztof Kozlowski wrote:
> > > > > > Device tree schema expects regulator names to be
> > > > > > lowercase.  This
> > > > > > fixes
> > > > > > dtbs_check warnings like:
> > > > > > 
> > > > > >     arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dt.yaml: 
> > > > > > pmic@4b:
> > > > > > regulators:LDO1:regulator-name:0: 'LDO1' does not match
> > > > > > '^ldo[1-6]$'
> > > > > > 
> > > > > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > > > > > ---
> > > > > >  .../boot/dts/freescale/imx8mn-ddr4-evk.dts    | 22
> > > > > > +++++++++------
> > > > > > ----
> > > > > >  1 file changed, 11 insertions(+), 11 deletions(-)
> > > > > > 
> > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-
> > > > > > evk.dts
> > > > > > b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
> > > > > > index a1e5483dbbbe..299caed5d46e 100644
> > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
> > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
> > > > > > @@ -60,7 +60,7 @@
> > > > > >  
> > > > > >  		regulators {
> > > > > >  			buck1_reg: BUCK1 {
> > > > > > -				regulator-name = "BUCK1";
> > > > > > +				regulator-name = "buck1";
> > > > > 
> > > > > I am not against this change but I would expect seeing some
> > > > > other
> > > > > patches too? I guess this will change the regulator name in
> > > > > regulator
> > > > > core, right? So maybe I am mistaken but it looks to me this
> > > > > change is
> > > > > visible in suppliers, sysfs and debugfs too? Thus changing this
> > > > > sounds
> > > > > a bit like asking for a nose bleed :) Am I right that the
> > > > > impact of
> > > > > this change has been thoroughly tested? Are there any other
> > > > > patches
> > > > > (that I have not seen) related to this change?
> > > > 
> > > > Oh, crap, the names of regulators in the driver are lowercase,
> > > > but they
> > > > use of_match_ptr for upper case. Seriously, why making a binding
> > > > which
> > > > is contradictory to the driver implementation on the first day?
> > > > 
> > > > The driver goes with binding, right? One expects uppercase, other
> > > > lowercase...
> > > > 
> > > > And tell me, what is now the ABI? The binding or the incorrect
> > > > implementation?
> > > 
> > > Wait, my mistake. I got confused by my own change. The node name
> > > stays
> > > the same, so of_match will be correct.
> 
> Yes. I think so too. Match will still work as earler.
> 
> > > 
> > > The driver internally already uses lowercase names.
> 
> Yep. I was simply thinking that if anyone has been specifying the
> regulators as suppliers by name - then this change will change things
> (as is seen for LDO5). Additionally, if any user-space SW has been
> reading the regulator states from sysfs - then these names will also
> change the sysfs. Debugfs change is hopefully not such a big deal.

About user-space, I think the embedded DT is not part of kernel ABI, so
there is no such requirement about keeping it stable. I agree though it
might be annoying surprise.

> 
> Whether this really breaks anything is beyond my knowledge as I don't
> even have this board. Anyways, I think that by minimum the commit
> message should point out that this change will be visible outside DTS
> and the BD718x7 driver - up to the user-space.

Good point, I will extend the commit msg about possible impact and
fixing supplies.

> 
> > > 
> > > Everything looks good. I will just double check whether the
> > > constraints
> > > did not change on the board after boot.
> > 
> > Constraints look good.
> > 
> > > > > >  				regulator-min-microvolt =
> > > > > > <700000>;
> > > > > >  				regulator-max-microvolt =
> > > > > > <1300000>;
> > > > > >  				regulator-boot-on;
> > > > > > @@ -69,7 +69,7 @@
> > > > > >  			};
> > > > > >  
> > > > > >  			buck2_reg: BUCK2 {
> > > > > > -				regulator-name = "BUCK2";
> > > > > > +				regulator-name = "buck2";
> > > > > >  				regulator-min-microvolt =
> > > > > > <700000>;
> > > > > >  				regulator-max-microvolt =
> > > > > > <1300000>;
> > > > > >  				regulator-boot-on;
> > > > > > @@ -79,14 +79,14 @@
> > > > > >  
> > > > > >  			buck3_reg: BUCK3 {
> > > > > >  				// BUCK5 in datasheet
> > > > > > -				regulator-name = "BUCK3";
> > > > > > +				regulator-name = "buck3";
> > > > > >  				regulator-min-microvolt =
> > > > > > <700000>;
> > > > > >  				regulator-max-microvolt =
> > > > > > <1350000>;
> > > > > >  			};
> > > > > >  
> > > > > >  			buck4_reg: BUCK4 {
> > > > > >  				// BUCK6 in datasheet
> > > > > > -				regulator-name = "BUCK4";
> > > > > > +				regulator-name = "buck4";
> > > > > >  				regulator-min-microvolt =
> > > > > > <3000000>;
> > > > > >  				regulator-max-microvolt =
> > > > > > <3300000>;
> > > > > >  				regulator-boot-on;
> > > > > > @@ -95,7 +95,7 @@
> > > > > >  
> > > > > >  			buck5_reg: BUCK5 {
> > > > > >  				// BUCK7 in datasheet
> > > > > > -				regulator-name = "BUCK5";
> > > > > > +				regulator-name = "buck5";
> > > > > 
> > > > > What I see in bd718x7-regulator.c for LDO6 desc is:
> > > > > 
> > > > >                         /* LDO6 is supplied by buck5 */
> > > > >                         .supply_name = "buck5",
> > > > > 
> > > > > So, is this change going to change the supply-chain for the
> > > > > board? Is
> > > > > this intended? (Or am I mistaken on what is the impact of
> > > > > regulator-
> > > > > name property?)
> > > 
> > > Good point, let me check the supplies.
> > 
> > This patch actually fixes the supplies which before were not working
> > because of case mismatch.
> > Before:
> > 
> >  regulator                      use open bypass  opmode voltage
> > current     min     max
> > -------------------------------------------------------------------
> > --------------------
> >  regulator-dummy                  4    5      0
> > unknown     0mV     0mA     0mV     0mV
> >     LDO6                          1    0      0
> > unknown  1200mV     0mA   900mV  1800mV
> >  BUCK1                            1    0      0
> > unknown   850mV     0mA   700mV  1300mV
> >  BUCK2                            2    1      0
> > unknown  1000mV     0mA   700mV  1300mV
> >     cpu0-
> > cpu                      1                                 0mA  1000m
> > V  1000mV
> >  BUCK3                            1    0      0
> > unknown   975mV     0mA   700mV  1350mV
> >  BUCK4                            1    0      0
> > unknown  3300mV     0mA  3000mV  3300mV
> >  BUCK5                            1    0      0
> > unknown  1800mV     0mA  1605mV  1995mV
> >  BUCK6                            1    0      0
> > unknown  1200mV     0mA   800mV  1400mV
> >  LDO1                             1    0      0
> > unknown  1800mV     0mA  1600mV  1900mV
> >  LDO2                             1    0      0
> > unknown   800mV     0mA   800mV   900mV
> >  LDO3                             1    0      0
> > unknown  1800mV     0mA  1800mV  3300mV
> >  LDO4                             1    0      0
> > unknown   900mV     0mA   900mV  1800mV
> >  ldo5                             1    4      0
> > unknown  1800mV     0mA  1800mV  1800mV
> > 
> > 
> > 
> > After:
> >  regulator                      use open bypass  opmode voltage
> > current     min     max
> > -------------------------------------------------------------------
> > --------------------
> > buck1                            1    0      0
> > unknown   850mV     0mA   700mV  1300mV
> >  buck2                            2    1      0
> > unknown   850mV     0mA   700mV  1300mV
> >     cpu0-
> > cpu                      1                                 0mA   850m
> > V   850mV
> >  buck3                            1    0      0
> > unknown   975mV     0mA   700mV  1350mV
> >  buck4                            1    0      0
> > unknown  3300mV     0mA  3000mV  3300mV
> >  buck5                            2    1      0
> > unknown  1800mV     0mA  1605mV  1995mV
> >     ldo6                          1    0      0 
> 
> That was my point :) Before this commit the system has acted
> differently - either by accident or by purpose. In any case, the DTS
> change will change supply logic and this should probably be mentioned
> in commit log to help bisecting possible issues :)
> 
> But as I said, I am not opposed to this change - I am merely somewhat
> cautious with changes like this.

Thanks for the hints.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: "krzk@kernel.org" <krzk@kernel.org>
To: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
Cc: "robh+dt@kernel.org" <robh+dt@kernel.org>,
	"miquel.raynal@bootlin.com" <miquel.raynal@bootlin.com>,
	"linux-imx@nxp.com" <linux-imx@nxp.com>,
	"vigneshr@ti.com" <vigneshr@ti.com>,
	"Anson.Huang@nxp.com" <Anson.Huang@nxp.com>,
	"yibin.gong@nxp.com" <yibin.gong@nxp.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"aford173@gmail.com" <aford173@gmail.com>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"richard@nod.at" <richard@nod.at>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"daniel.baluta@nxp.com" <daniel.baluta@nxp.com>,
	"lee.jones@linaro.org" <lee.jones@linaro.org>,
	"festevam@gmail.com" <festevam@gmail.com>,
	"han.xu@nxp.com" <han.xu@nxp.com>,
	"jun.li@nxp.com" <jun.li@nxp.com>
Subject: Re: [PATCH 03/16] arm64: dts: imx8mm-beacon-som.dtsi: Align regulator names with schema
Date: Tue, 25 Aug 2020 10:27:37 +0200	[thread overview]
Message-ID: <20200825082737.GA12902@kozik-lap> (raw)
In-Reply-To: <3018d638b5753e629ebdb6a25973aeff7e446720.camel@fi.rohmeurope.com>

On Tue, Aug 25, 2020 at 08:22:18AM +0000, Vaittinen, Matti wrote:
> Hello Krzysztof,
> 
> On Tue, 2020-08-25 at 09:50 +0200, krzk@kernel.org wrote:
> > On Tue, Aug 25, 2020 at 09:45:00AM +0200, krzk@kernel.org wrote:
> > > On Tue, Aug 25, 2020 at 09:25:37AM +0200, krzk@kernel.org wrote:
> > > > On Tue, Aug 25, 2020 at 06:51:33AM +0000, Vaittinen, Matti wrote:
> > > > > Hello Krzysztof,
> > > > > 
> > > > > Just some questions - please ignore if I misunderstood the
> > > > > impact of
> > > > > the change.
> > > > > 
> > > > > On Mon, 2020-08-24 at 21:06 +0200, Krzysztof Kozlowski wrote:
> > > > > > Device tree schema expects regulator names to be
> > > > > > lowercase.  This
> > > > > > fixes
> > > > > > dtbs_check warnings like:
> > > > > > 
> > > > > >     arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dt.yaml: 
> > > > > > pmic@4b:
> > > > > > regulators:LDO1:regulator-name:0: 'LDO1' does not match
> > > > > > '^ldo[1-6]$'
> > > > > > 
> > > > > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > > > > > ---
> > > > > >  .../boot/dts/freescale/imx8mn-ddr4-evk.dts    | 22
> > > > > > +++++++++------
> > > > > > ----
> > > > > >  1 file changed, 11 insertions(+), 11 deletions(-)
> > > > > > 
> > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-
> > > > > > evk.dts
> > > > > > b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
> > > > > > index a1e5483dbbbe..299caed5d46e 100644
> > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
> > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
> > > > > > @@ -60,7 +60,7 @@
> > > > > >  
> > > > > >  		regulators {
> > > > > >  			buck1_reg: BUCK1 {
> > > > > > -				regulator-name = "BUCK1";
> > > > > > +				regulator-name = "buck1";
> > > > > 
> > > > > I am not against this change but I would expect seeing some
> > > > > other
> > > > > patches too? I guess this will change the regulator name in
> > > > > regulator
> > > > > core, right? So maybe I am mistaken but it looks to me this
> > > > > change is
> > > > > visible in suppliers, sysfs and debugfs too? Thus changing this
> > > > > sounds
> > > > > a bit like asking for a nose bleed :) Am I right that the
> > > > > impact of
> > > > > this change has been thoroughly tested? Are there any other
> > > > > patches
> > > > > (that I have not seen) related to this change?
> > > > 
> > > > Oh, crap, the names of regulators in the driver are lowercase,
> > > > but they
> > > > use of_match_ptr for upper case. Seriously, why making a binding
> > > > which
> > > > is contradictory to the driver implementation on the first day?
> > > > 
> > > > The driver goes with binding, right? One expects uppercase, other
> > > > lowercase...
> > > > 
> > > > And tell me, what is now the ABI? The binding or the incorrect
> > > > implementation?
> > > 
> > > Wait, my mistake. I got confused by my own change. The node name
> > > stays
> > > the same, so of_match will be correct.
> 
> Yes. I think so too. Match will still work as earler.
> 
> > > 
> > > The driver internally already uses lowercase names.
> 
> Yep. I was simply thinking that if anyone has been specifying the
> regulators as suppliers by name - then this change will change things
> (as is seen for LDO5). Additionally, if any user-space SW has been
> reading the regulator states from sysfs - then these names will also
> change the sysfs. Debugfs change is hopefully not such a big deal.

About user-space, I think the embedded DT is not part of kernel ABI, so
there is no such requirement about keeping it stable. I agree though it
might be annoying surprise.

> 
> Whether this really breaks anything is beyond my knowledge as I don't
> even have this board. Anyways, I think that by minimum the commit
> message should point out that this change will be visible outside DTS
> and the BD718x7 driver - up to the user-space.

Good point, I will extend the commit msg about possible impact and
fixing supplies.

> 
> > > 
> > > Everything looks good. I will just double check whether the
> > > constraints
> > > did not change on the board after boot.
> > 
> > Constraints look good.
> > 
> > > > > >  				regulator-min-microvolt =
> > > > > > <700000>;
> > > > > >  				regulator-max-microvolt =
> > > > > > <1300000>;
> > > > > >  				regulator-boot-on;
> > > > > > @@ -69,7 +69,7 @@
> > > > > >  			};
> > > > > >  
> > > > > >  			buck2_reg: BUCK2 {
> > > > > > -				regulator-name = "BUCK2";
> > > > > > +				regulator-name = "buck2";
> > > > > >  				regulator-min-microvolt =
> > > > > > <700000>;
> > > > > >  				regulator-max-microvolt =
> > > > > > <1300000>;
> > > > > >  				regulator-boot-on;
> > > > > > @@ -79,14 +79,14 @@
> > > > > >  
> > > > > >  			buck3_reg: BUCK3 {
> > > > > >  				// BUCK5 in datasheet
> > > > > > -				regulator-name = "BUCK3";
> > > > > > +				regulator-name = "buck3";
> > > > > >  				regulator-min-microvolt =
> > > > > > <700000>;
> > > > > >  				regulator-max-microvolt =
> > > > > > <1350000>;
> > > > > >  			};
> > > > > >  
> > > > > >  			buck4_reg: BUCK4 {
> > > > > >  				// BUCK6 in datasheet
> > > > > > -				regulator-name = "BUCK4";
> > > > > > +				regulator-name = "buck4";
> > > > > >  				regulator-min-microvolt =
> > > > > > <3000000>;
> > > > > >  				regulator-max-microvolt =
> > > > > > <3300000>;
> > > > > >  				regulator-boot-on;
> > > > > > @@ -95,7 +95,7 @@
> > > > > >  
> > > > > >  			buck5_reg: BUCK5 {
> > > > > >  				// BUCK7 in datasheet
> > > > > > -				regulator-name = "BUCK5";
> > > > > > +				regulator-name = "buck5";
> > > > > 
> > > > > What I see in bd718x7-regulator.c for LDO6 desc is:
> > > > > 
> > > > >                         /* LDO6 is supplied by buck5 */
> > > > >                         .supply_name = "buck5",
> > > > > 
> > > > > So, is this change going to change the supply-chain for the
> > > > > board? Is
> > > > > this intended? (Or am I mistaken on what is the impact of
> > > > > regulator-
> > > > > name property?)
> > > 
> > > Good point, let me check the supplies.
> > 
> > This patch actually fixes the supplies which before were not working
> > because of case mismatch.
> > Before:
> > 
> >  regulator                      use open bypass  opmode voltage
> > current     min     max
> > -------------------------------------------------------------------
> > --------------------
> >  regulator-dummy                  4    5      0
> > unknown     0mV     0mA     0mV     0mV
> >     LDO6                          1    0      0
> > unknown  1200mV     0mA   900mV  1800mV
> >  BUCK1                            1    0      0
> > unknown   850mV     0mA   700mV  1300mV
> >  BUCK2                            2    1      0
> > unknown  1000mV     0mA   700mV  1300mV
> >     cpu0-
> > cpu                      1                                 0mA  1000m
> > V  1000mV
> >  BUCK3                            1    0      0
> > unknown   975mV     0mA   700mV  1350mV
> >  BUCK4                            1    0      0
> > unknown  3300mV     0mA  3000mV  3300mV
> >  BUCK5                            1    0      0
> > unknown  1800mV     0mA  1605mV  1995mV
> >  BUCK6                            1    0      0
> > unknown  1200mV     0mA   800mV  1400mV
> >  LDO1                             1    0      0
> > unknown  1800mV     0mA  1600mV  1900mV
> >  LDO2                             1    0      0
> > unknown   800mV     0mA   800mV   900mV
> >  LDO3                             1    0      0
> > unknown  1800mV     0mA  1800mV  3300mV
> >  LDO4                             1    0      0
> > unknown   900mV     0mA   900mV  1800mV
> >  ldo5                             1    4      0
> > unknown  1800mV     0mA  1800mV  1800mV
> > 
> > 
> > 
> > After:
> >  regulator                      use open bypass  opmode voltage
> > current     min     max
> > -------------------------------------------------------------------
> > --------------------
> > buck1                            1    0      0
> > unknown   850mV     0mA   700mV  1300mV
> >  buck2                            2    1      0
> > unknown   850mV     0mA   700mV  1300mV
> >     cpu0-
> > cpu                      1                                 0mA   850m
> > V   850mV
> >  buck3                            1    0      0
> > unknown   975mV     0mA   700mV  1350mV
> >  buck4                            1    0      0
> > unknown  3300mV     0mA  3000mV  3300mV
> >  buck5                            2    1      0
> > unknown  1800mV     0mA  1605mV  1995mV
> >     ldo6                          1    0      0 
> 
> That was my point :) Before this commit the system has acted
> differently - either by accident or by purpose. In any case, the DTS
> change will change supply logic and this should probably be mentioned
> in commit log to help bisecting possible issues :)
> 
> But as I said, I am not opposed to this change - I am merely somewhat
> cautious with changes like this.

Thanks for the hints.

Best regards,
Krzysztof


  reply	other threads:[~2020-08-25  8:28 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-24 19:06 [PATCH 01/16] dt-bindings: mfd: rohm, bd71847-pmic: Correct clock properties requirements Krzysztof Kozlowski
2020-08-24 19:06 ` [PATCH 01/16] dt-bindings: mfd: rohm,bd71847-pmic: " Krzysztof Kozlowski
2020-08-24 19:06 ` [PATCH 01/16] dt-bindings: mfd: rohm, bd71847-pmic: " Krzysztof Kozlowski
2020-08-24 19:06 ` [PATCH 02/16] dt-bindings: mtd: gpmi-nand: Fix matching of clocks on different SoCs Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-25  6:40   ` Sascha Hauer
2020-08-25  6:40     ` Sascha Hauer
2020-08-25  6:40     ` Sascha Hauer
2020-08-25  6:49     ` Krzysztof Kozlowski
2020-08-25  6:49       ` Krzysztof Kozlowski
2020-08-25  6:49       ` Krzysztof Kozlowski
2020-08-24 19:06 ` [PATCH 03/16] arm64: dts: imx8mm-beacon-som.dtsi: Align regulator names with schema Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-25  6:51   ` Vaittinen, Matti
2020-08-25  6:51     ` Vaittinen, Matti
2020-08-25  6:51     ` Vaittinen, Matti
2020-08-25  7:25     ` krzk
2020-08-25  7:25       ` krzk
2020-08-25  7:25       ` krzk
2020-08-25  7:45       ` krzk
2020-08-25  7:45         ` krzk
2020-08-25  7:45         ` krzk
2020-08-25  7:50         ` krzk
2020-08-25  7:50           ` krzk
2020-08-25  7:50           ` krzk
2020-08-25  8:22           ` Vaittinen, Matti
2020-08-25  8:22             ` Vaittinen, Matti
2020-08-25  8:22             ` Vaittinen, Matti
2020-08-25  8:27             ` krzk [this message]
2020-08-25  8:27               ` krzk
2020-08-25  8:27               ` krzk
2020-08-25  9:35               ` Vaittinen, Matti
2020-08-25  9:35                 ` Vaittinen, Matti
2020-08-25  9:35                 ` Vaittinen, Matti
2020-08-25  8:29   ` Krzysztof Kozlowski
2020-08-25  8:29     ` Krzysztof Kozlowski
2020-08-25  8:29     ` Krzysztof Kozlowski
2020-08-24 19:06 ` [PATCH 04/16] arm64: dts: imx8mm-beacon-baseboard: Correct SPI CS polarity Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 20:07   ` Fabio Estevam
2020-08-24 20:07     ` Fabio Estevam
2020-08-24 20:07     ` Fabio Estevam
2020-08-24 19:06 ` [PATCH 05/16] arm64: dts: imx8mm-beacon: Align pin configuration group names with schema Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06 ` [PATCH 06/16] arm64: dts: imx8mm-evk: Add 32.768 kHz clock to PMIC Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06 ` [PATCH 07/16] arm64: dts: imx8mm-evk: Align pin configuration group names with schema Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06 ` [PATCH 08/16] arm64: dts: imx8mm-ddr4-evk: " Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06 ` [PATCH 09/16] arm64: dts: imx8mn-evk: " Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06 ` [PATCH 10/16] arm64: dts: imx8mq-evk: " Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06 ` [PATCH 11/16] arm64: dts: imx8mq-librem5-devkit: " Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06 ` [PATCH 12/16] arm64: dts: imx8mq-phanbell: " Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06 ` [PATCH 13/16] arm64: dts: imx8mq-pico-pi: " Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06 ` [PATCH 14/16] arm64: dts: imx8mq-sr-som: " Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:06   ` Krzysztof Kozlowski
2020-08-24 19:07 ` [PATCH 15/16] arm64: dts: imx8mq-hummingboard-pulse: " Krzysztof Kozlowski
2020-08-24 19:07   ` Krzysztof Kozlowski
2020-08-24 19:07   ` Krzysztof Kozlowski
2020-08-24 19:07 ` [PATCH 16/16] arm64: dts: imx8qxp-colibri: " Krzysztof Kozlowski
2020-08-24 19:07   ` Krzysztof Kozlowski
2020-08-24 19:07   ` Krzysztof Kozlowski
2020-08-25  6:23 ` [PATCH 01/16] dt-bindings: mfd: rohm, bd71847-pmic: Correct clock properties requirements Vaittinen, Matti
2020-08-25  6:23   ` [PATCH 01/16] dt-bindings: mfd: rohm,bd71847-pmic: " Vaittinen, Matti
2020-08-25  6:23   ` [PATCH 01/16] dt-bindings: mfd: rohm, bd71847-pmic: " Vaittinen, Matti
2020-08-25  6:55   ` krzk
2020-08-25  6:55     ` [PATCH 01/16] dt-bindings: mfd: rohm,bd71847-pmic: " krzk
2020-08-25  6:55     ` [PATCH 01/16] dt-bindings: mfd: rohm, bd71847-pmic: " krzk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200825082737.GA12902@kozik-lap \
    --to=krzk@kernel.org \
    --cc=Anson.Huang@nxp.com \
    --cc=Matti.Vaittinen@fi.rohmeurope.com \
    --cc=aford173@gmail.com \
    --cc=daniel.baluta@nxp.com \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=han.xu@nxp.com \
    --cc=jun.li@nxp.com \
    --cc=kernel@pengutronix.de \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=robh+dt@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=vigneshr@ti.com \
    --cc=yibin.gong@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.