Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible
Hello Geert, Laurent, Morimoto-san, On Tue, Aug 07, 2018 at 10:30:14AM +0200, Geert Uytterhoeven wrote: > Hi Laurent, > > On Tue, Aug 7, 2018 at 10:21 AM Laurent Pinchart > wrote: > > On Tuesday, 7 August 2018 11:18:11 EEST Kuninori Morimoto wrote: > > > > Yeah, it is true "so far". I think there is no problem on current > > > > kernel. > > > > But, unfortunately we need to keep compatibility for old/new DT > > > > (= actually, I don't like this DT rule. It is 100% "shackles for the > > > > legs") > > > > Thus, my big concern is that, in the future, > > > > "if" we added "renesas,ulcb" compatible driver/soc, > > > > both h3/m3 ulcb will use it. > > > > Then, if "h3" can work/boot by using same "m3" settings, it is no > > > > problem > > > > for me (= "works but limited" is also OK, of course. > > > > > > > > This means "matched to more generic compatible") > > > > > > "renesas,ulcb" is very generic naming. > > > Not only h3/m3, if we had v3/e3/d3 etc ulcb, > > > > Furthermore, "ulcb" is an unofficial term, the boards are named "starter > > kit" > > (SK). Using internal names in code or device tree sources is a normal > > practice > > and is fine with me, but I'm a bit bothered by the fact that the H3/M3 > > boards > > are called ULCB in DT, while the V3 board are called SK. I wonder if we > > should > > unify that or if it's too late. > > Perhaps we should. > > Renesas has a long history of boards named SK or RSK. > The inconsistency started when suddenly SK was spelled out in full, with > "Premier" or "Pro" added to differentiate, and the need arose for a shorter > nickname, which became "ULCB" I really appreciate your comments, but it looks like at least the following open questions prevent this series to advance into v2 (feel free to point out flaws in my understanding): - [A] it is not clear if H3ULCB, M3ULCB and M3NULCB boards should use a common compatible string or dedicated ones. - [B] In case a common string is used for all *ULCB boards, should it drop the unofficial "ulcb" (Ultra Low Cost Board, thanks Laurent) in exchange to "sk", "starter-kit" or similar? - [C] Same as [A] and [B], but applied to ULCB DTS filenames, which are currently formed based on the same "ulcb" stem. IMHO these questions go somewhat beyond the scope of M3-N ULCB bring-up. In spite of this, I would be happy to implement your proposals. I am also fine to wait a couple more days to collect more feedback, as well as let the ideas/thoughts to settle. However, if you expect the latter to take longer, maybe we can find some "acceptable" solution and defer the naming issues to a later point? Thanks, Eugeniu.
Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible
On Sun, Aug 05, 2018 at 01:11:02AM +0200, Eugeniu Rosca wrote: > diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt > b/Documentation/devicetree/bindings/arm/shmobile.txt > index d8cf740132c6..f391dba10574 100644 > --- a/Documentation/devicetree/bindings/arm/shmobile.txt > +++ b/Documentation/devicetree/bindings/arm/shmobile.txt > @@ -81,7 +81,7 @@ Boards: > compatible = "renesas,gose", "renesas,r8a7793" >- H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1)) > H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0)) FWIW/FTR, I have found the schematics of RTP0RC7795SKB00010S (looks like a H3-ES1x Starter-Kit) and this specific board doesn't have an entry in Documentation/devicetree/bindings/arm/shmobile.txt. Also, there is RTP0RC77951SKBX010SA03 (8GB version H3-ES20 Starter-Kit). This is also not documented. Interestingly, there is one digit difference between: - 4GiB H3-ES2.0 Starter-Kit: RTP0RC77951SKBX010SA00 - 8GiB H3-ES2.0 Starter-Kit: RTP0RC77951SKBX010SA03 which means Renesas encodes the amount of RAM in the board id/string. > -compatible = "renesas,h3ulcb", "renesas,r8a7795" > +compatible = "renesas,ulcb", "renesas,r8a7795" >- Henninger > compatible = "renesas,henninger", "renesas,r8a7791" >- iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S) > @@ -105,7 +105,7 @@ Boards: >- Lager (RTP0RC7790SEB00010S) > compatible = "renesas,lager", "renesas,r8a7790" >- M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0)) > -compatible = "renesas,m3ulcb", "renesas,r8a7796" > +compatible = "renesas,ulcb", "renesas,r8a7796" >- Marzen (R0P7779A00010S) > compatible = "renesas,marzen", "renesas,r8a7779" >- Porter (M2-LCDP) > -- > 2.18.0 Best regards, Eugeniu.
Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible
Hi Laurent,
On Tue, Aug 7, 2018 at 10:21 AM Laurent Pinchart
wrote:
> On Tuesday, 7 August 2018 11:18:11 EEST Kuninori Morimoto wrote:
> > > Yeah, it is true "so far". I think there is no problem on current kernel.
> > > But, unfortunately we need to keep compatibility for old/new DT
> > > (= actually, I don't like this DT rule. It is 100% "shackles for the
> > > legs")
> > > Thus, my big concern is that, in the future,
> > > "if" we added "renesas,ulcb" compatible driver/soc,
> > > both h3/m3 ulcb will use it.
> > > Then, if "h3" can work/boot by using same "m3" settings, it is no problem
> > > for me (= "works but limited" is also OK, of course.
> > >
> > > This means "matched to more generic compatible")
> >
> > "renesas,ulcb" is very generic naming.
> > Not only h3/m3, if we had v3/e3/d3 etc ulcb,
>
> Furthermore, "ulcb" is an unofficial term, the boards are named "starter kit"
> (SK). Using internal names in code or device tree sources is a normal practice
> and is fine with me, but I'm a bit bothered by the fact that the H3/M3 boards
> are called ULCB in DT, while the V3 board are called SK. I wonder if we should
> unify that or if it's too late.
Perhaps we should.
Renesas has a long history of boards named SK or RSK.
The inconsistency started when suddenly SK was spelled out in full, with
"Premier" or "Pro" added to differentiate, and the need arose for a shorter
nickname, which became "ULCB"
> > and if we had such compatible driver/soc, it needs to match to all ulcb.
> > In reality, maybe we don't create such compatible driver, though.
> > But, I don't know, I can follow to maintainer opinion.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
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
Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible
Hi Morimoto-san, On Tuesday, 7 August 2018 11:18:11 EEST Kuninori Morimoto wrote: > Hi Eugeniu, again > > > Yeah, it is true "so far". I think there is no problem on current kernel. > > But, unfortunately we need to keep compatibility for old/new DT > > (= actually, I don't like this DT rule. It is 100% "shackles for the > > legs") > > Thus, my big concern is that, in the future, > > "if" we added "renesas,ulcb" compatible driver/soc, > > both h3/m3 ulcb will use it. > > Then, if "h3" can work/boot by using same "m3" settings, it is no problem > > for me (= "works but limited" is also OK, of course. > > > > This means "matched to more generic compatible") > > "renesas,ulcb" is very generic naming. > Not only h3/m3, if we had v3/e3/d3 etc ulcb, Furthermore, "ulcb" is an unofficial term, the boards are named "starter kit" (SK). Using internal names in code or device tree sources is a normal practice and is fine with me, but I'm a bit bothered by the fact that the H3/M3 boards are called ULCB in DT, while the V3 board are called SK. I wonder if we should unify that or if it's too late. > and if we had such compatible driver/soc, it needs to match to all ulcb. > In reality, maybe we don't create such compatible driver, though. > But, I don't know, I can follow to maintainer opinion. -- Regards, Laurent Pinchart
Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible
Hi Eugeniu, again > Yeah, it is true "so far". I think there is no problem on current kernel. > But, unfortunately we need to keep compatibility for old/new DT > (= actually, I don't like this DT rule. It is 100% "shackles for the legs") > Thus, my big concern is that, in the future, > "if" we added "renesas,ulcb" compatible driver/soc, > both h3/m3 ulcb will use it. > Then, if "h3" can work/boot by using same "m3" settings, it is no problem for > me > (= "works but limited" is also OK, of course. > This means "matched to more generic compatible") "renesas,ulcb" is very generic naming. Not only h3/m3, if we had v3/e3/d3 etc ulcb, and if we had such compatible driver/soc, it needs to match to all ulcb. In reality, maybe we don't create such compatible driver, though. But, I don't know, I can follow to maintainer opinion. Best regards --- Kuninori Morimoto
Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible
Hi Eugeniu Thank you for your reply > > > Prior to adding M3-N Starter Kit to the list, rename: > > > - "renesas,h3ulcb" => "renesas,ulcb" > > > - "renesas,m3ulcb" => "renesas,ulcb" > > > > I'm not sure detail, but > > does it mean, both H3/M3 board can boot/work with > > "renesas,ulcb" compatible if we had such driver/soc ? > > First, assuming latest vanilla v4.18-rc8 kernel, neither > "renesas,salvator-x[s]" nor "renesas,(m3|h3)ulcb" compatibles are > used anywhere outside of DTS and DT bindings documentation: (snip) > Since there is no driver using these compatibles, no functional > breakage is expected by changing the compatible format/name. Yeah, it is true "so far". I think there is no problem on current kernel. But, unfortunately we need to keep compatibility for old/new DT (= actually, I don't like this DT rule. It is 100% "shackles for the legs") Thus, my big concern is that, in the future, "if" we added "renesas,ulcb" compatible driver/soc, both h3/m3 ulcb will use it. Then, if "h3" can work/boot by using same "m3" settings, it is no problem for me (= "works but limited" is also OK, of course. This means "matched to more generic compatible") > > My opinion is that if you want to exchange compatible name, > > related all driver/document should be exchanged in same patch. (snip) > For that reason, IMO it might be worth to detach the document updates > from DTS updates. I have no problems squashing the DTS and doc patches > into one single commit, but before doing that I would appreciate a > confirmation from the maintainer. Anyhow, many thanks for your feedback! (snip) > It was my impression that the DTS patches are always partitioned > per-file, to avoid misleading globbing patterns in the commit subjects > and allow easier DTS commit porting to future SoCs/boards. I will > gladly follow your suggestion once I get the confirmation from > maintainer. Oops, I noticed that Simon was requested from ARM maintainer(?) to merge/reduce patches Let's follow Simon's opinion (This kind of "patch categorize" is based on each ML...) Best regards --- Kuninori Morimoto
Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible
On Mon, Aug 6, 2018 at 1:13 PM Geert Uytterhoeven wrote:
> On Mon, Aug 6, 2018 at 12:38 PM Laurent Pinchart
> wrote:
> > On Sunday, 5 August 2018 02:11:02 EEST Eugeniu Rosca wrote:
> > > In the context of M3N-ULCB (RTP0RC77965SKBX010SA00) board bring-up, it's
> > > rather pointless to add a new "renesas,m3nulcb" compatible string. Any
> > > SoC-level differences between the two variants of ULCB (M3 and M3-N)
> > > should be successfully covered by making use of existing
> > > "renesas,r8a7796" and "renesas,r8a77965" compatibles.
> > >
> > > Prior to adding M3-N Starter Kit to the list, rename:
> > > - "renesas,h3ulcb" => "renesas,ulcb"
> > > - "renesas,m3ulcb" => "renesas,ulcb"
> >
> > This bothers me more than the naming convention in patch 01/14, as this
> > change
> > would completely hide differences between the H3 and M3-N versions of the
> > ULCB. Compatible strings are listed in a decreasing order of specificity,
> > and
> > having "renesas,ulcb" as the most-specific compatible string means that the
> > two boards are supposed to be identical, while they are not.
>
> AFAIK the boards are identical (cfr. ), except for the SiP mounted.
> Cfr. e.g. the combined R-Car_StarterKit_Gen3_H3_M3_DEV_Rev.053.pdf
> ("Renesas R-Car H3/M3 Device Manual", incl. schematics).
Sorry, the schematics are in a separate file
R-Car_StarterKit_Gen3_SCH_Rev.110.pdf
with title "R-Car_Gen3 Starterkit", for both the Pro and Premier versions.
But "ULCB" is an unofficial name.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
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
Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible
Hi Laurent,
On Mon, Aug 6, 2018 at 12:38 PM Laurent Pinchart
wrote:
> On Sunday, 5 August 2018 02:11:02 EEST Eugeniu Rosca wrote:
> > In the context of M3N-ULCB (RTP0RC77965SKBX010SA00) board bring-up, it's
> > rather pointless to add a new "renesas,m3nulcb" compatible string. Any
> > SoC-level differences between the two variants of ULCB (M3 and M3-N)
> > should be successfully covered by making use of existing
> > "renesas,r8a7796" and "renesas,r8a77965" compatibles.
> >
> > Prior to adding M3-N Starter Kit to the list, rename:
> > - "renesas,h3ulcb" => "renesas,ulcb"
> > - "renesas,m3ulcb" => "renesas,ulcb"
>
> This bothers me more than the naming convention in patch 01/14, as this change
> would completely hide differences between the H3 and M3-N versions of the
> ULCB. Compatible strings are listed in a decreasing order of specificity, and
> having "renesas,ulcb" as the most-specific compatible string means that the
> two boards are supposed to be identical, while they are not.
AFAIK the boards are identical (cfr. ), except for the SiP mounted.
Cfr. e.g. the combined R-Car_StarterKit_Gen3_H3_M3_DEV_Rev.053.pdf
("Renesas R-Car H3/M3 Device Manual", incl. schematics).
Hence to me the patch makes sense (modulo out-of-tree dependencies on the
old compatible values).
> > Relevant DTS changes come in separate per-DTS commits.
> >
> > Signed-off-by: Eugeniu Rosca
> > ---
> > Documentation/devicetree/bindings/arm/shmobile.txt | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt
> > b/Documentation/devicetree/bindings/arm/shmobile.txt index
> > d8cf740132c6..f391dba10574 100644
> > --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> > +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> > @@ -81,7 +81,7 @@ Boards:
> > compatible = "renesas,gose", "renesas,r8a7793"
> >- H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1))
> > H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0))
> > -compatible = "renesas,h3ulcb", "renesas,r8a7795"
> > +compatible = "renesas,ulcb", "renesas,r8a7795"
> >- Henninger
> > compatible = "renesas,henninger", "renesas,r8a7791"
> >- iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S)
> > @@ -105,7 +105,7 @@ Boards:
> >- Lager (RTP0RC7790SEB00010S)
> > compatible = "renesas,lager", "renesas,r8a7790"
> >- M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0))
> > -compatible = "renesas,m3ulcb", "renesas,r8a7796"
> > +compatible = "renesas,ulcb", "renesas,r8a7796"
> >- Marzen (R0P7779A00010S)
> > compatible = "renesas,marzen", "renesas,r8a7779"
> >- Porter (M2-LCDP)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
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
Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible
Hi Eugeniu, Thank you for the patch. On Sunday, 5 August 2018 02:11:02 EEST Eugeniu Rosca wrote: > In the context of M3N-ULCB (RTP0RC77965SKBX010SA00) board bring-up, it's > rather pointless to add a new "renesas,m3nulcb" compatible string. Any > SoC-level differences between the two variants of ULCB (M3 and M3-N) > should be successfully covered by making use of existing > "renesas,r8a7796" and "renesas,r8a77965" compatibles. > > Prior to adding M3-N Starter Kit to the list, rename: > - "renesas,h3ulcb" => "renesas,ulcb" > - "renesas,m3ulcb" => "renesas,ulcb" This bothers me more than the naming convention in patch 01/14, as this change would completely hide differences between the H3 and M3-N versions of the ULCB. Compatible strings are listed in a decreasing order of specificity, and having "renesas,ulcb" as the most-specific compatible string means that the two boards are supposed to be identical, while they are not. > Relevant DTS changes come in separate per-DTS commits. > > Signed-off-by: Eugeniu Rosca > --- > Documentation/devicetree/bindings/arm/shmobile.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt > b/Documentation/devicetree/bindings/arm/shmobile.txt index > d8cf740132c6..f391dba10574 100644 > --- a/Documentation/devicetree/bindings/arm/shmobile.txt > +++ b/Documentation/devicetree/bindings/arm/shmobile.txt > @@ -81,7 +81,7 @@ Boards: > compatible = "renesas,gose", "renesas,r8a7793" >- H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1)) > H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0)) > -compatible = "renesas,h3ulcb", "renesas,r8a7795" > +compatible = "renesas,ulcb", "renesas,r8a7795" >- Henninger > compatible = "renesas,henninger", "renesas,r8a7791" >- iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S) > @@ -105,7 +105,7 @@ Boards: >- Lager (RTP0RC7790SEB00010S) > compatible = "renesas,lager", "renesas,r8a7790" >- M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0)) > -compatible = "renesas,m3ulcb", "renesas,r8a7796" > +compatible = "renesas,ulcb", "renesas,r8a7796" >- Marzen (R0P7779A00010S) > compatible = "renesas,marzen", "renesas,r8a7779" >- Porter (M2-LCDP) -- Regards, Laurent Pinchart
Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible
Hi Morimoto-san,
Thank you for your comments.
On Mon, Aug 06, 2018 at 12:33:34AM +, Kuninori Morimoto wrote:
> Hi Eugeniu
>
> > In the context of M3N-ULCB (RTP0RC77965SKBX010SA00) board bring-up, it's
> > rather pointless to add a new "renesas,m3nulcb" compatible string. Any
> > SoC-level differences between the two variants of ULCB (M3 and M3-N)
> > should be successfully covered by making use of existing
> > "renesas,r8a7796" and "renesas,r8a77965" compatibles.
> >
> > Prior to adding M3-N Starter Kit to the list, rename:
> > - "renesas,h3ulcb" => "renesas,ulcb"
> > - "renesas,m3ulcb" => "renesas,ulcb"
>
> I'm not sure detail, but
> does it mean, both H3/M3 board can boot/work with
> "renesas,ulcb" compatible if we had such driver/soc ?
First, assuming latest vanilla v4.18-rc8 kernel, neither
"renesas,salvator-x[s]" nor "renesas,(m3|h3)ulcb" compatibles are
used anywhere outside of DTS and DT bindings documentation:
$ git grep -E --name-only "renesas,(h3ulcb|m3ulcb|salvator-x)" | xargs dirname
| sort -u
arch/arm64/boot/dts/renesas
Documentation/devicetree/bindings/arm
Since there is no driver using these compatibles, no functional
breakage is expected by changing the compatible format/name.
Secondly, as pointed out in the commit summary line and description,
there is an overlap in scope between the SoC-level compatibles and
ULCB board-level compatibles, which doesn't happen for Salvator-X{S}
targets and creates some inconsistency. This inconsistency now spawns
debates about how other ULCB-based board compatibles should be named and
for that single reason IMO should be fixed.
Lastly, I don't think any driver will ever need to use
"renesas,(m3|m3n|h3)ulcb" string, since it is too broad. On/off-chip
IP-oriented compatibles are probably better candidates for that.
>
> > diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt
> > b/Documentation/devicetree/bindings/arm/shmobile.txt
> > index d8cf740132c6..f391dba10574 100644
> > --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> > +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> > @@ -81,7 +81,7 @@ Boards:
> > compatible = "renesas,gose", "renesas,r8a7793"
> >- H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1))
> > H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0))
> > -compatible = "renesas,h3ulcb", "renesas,r8a7795"
> > +compatible = "renesas,ulcb", "renesas,r8a7795"
> >- Henninger
> > compatible = "renesas,henninger", "renesas,r8a7791"
> >- iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S)
> > @@ -105,7 +105,7 @@ Boards:
> >- Lager (RTP0RC7790SEB00010S)
> > compatible = "renesas,lager", "renesas,r8a7790"
> >- M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0))
> > -compatible = "renesas,m3ulcb", "renesas,r8a7796"
> > +compatible = "renesas,ulcb", "renesas,r8a7796"
> >- Marzen (R0P7779A00010S)
> > compatible = "renesas,marzen", "renesas,r8a7779"
> >- Porter (M2-LCDP)
>
> My opinion is that if you want to exchange compatible name,
> related all driver/document should be exchanged in same patch.
AFAIK Simon maintains a number of branches hosting solely the DT
bindings. More precisely it is the "dt-bindings-for-v4.*" branch series
in https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
For that reason, IMO it might be worth to detach the document updates
from DTS updates. I have no problems squashing the DTS and doc patches
into one single commit, but before doing that I would appreciate a
confirmation from the maintainer. Anyhow, many thanks for your feedback!
>
> For example, above "h3ulcb" case, patch subject indicates
> "rename h3ulcb" or something, and it include [03/14][04/14][05/14][06/14].
> Same for m3
It was my impression that the DTS patches are always partitioned
per-file, to avoid misleading globbing patterns in the commit subjects
and allow easier DTS commit porting to future SoCs/boards. I will
gladly follow your suggestion once I get the confirmation from
maintainer.
Thank you very much!
Best regards,
Eugeniu.
Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible
Hi Eugeniu > In the context of M3N-ULCB (RTP0RC77965SKBX010SA00) board bring-up, it's > rather pointless to add a new "renesas,m3nulcb" compatible string. Any > SoC-level differences between the two variants of ULCB (M3 and M3-N) > should be successfully covered by making use of existing > "renesas,r8a7796" and "renesas,r8a77965" compatibles. > > Prior to adding M3-N Starter Kit to the list, rename: > - "renesas,h3ulcb" => "renesas,ulcb" > - "renesas,m3ulcb" => "renesas,ulcb" I'm not sure detail, but does it mean, both H3/M3 board can boot/work with "renesas,ulcb" compatible if we had such driver/soc ? > diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt > b/Documentation/devicetree/bindings/arm/shmobile.txt > index d8cf740132c6..f391dba10574 100644 > --- a/Documentation/devicetree/bindings/arm/shmobile.txt > +++ b/Documentation/devicetree/bindings/arm/shmobile.txt > @@ -81,7 +81,7 @@ Boards: > compatible = "renesas,gose", "renesas,r8a7793" >- H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1)) > H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0)) > -compatible = "renesas,h3ulcb", "renesas,r8a7795" > +compatible = "renesas,ulcb", "renesas,r8a7795" >- Henninger > compatible = "renesas,henninger", "renesas,r8a7791" >- iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S) > @@ -105,7 +105,7 @@ Boards: >- Lager (RTP0RC7790SEB00010S) > compatible = "renesas,lager", "renesas,r8a7790" >- M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0)) > -compatible = "renesas,m3ulcb", "renesas,r8a7796" > +compatible = "renesas,ulcb", "renesas,r8a7796" >- Marzen (R0P7779A00010S) > compatible = "renesas,marzen", "renesas,r8a7779" >- Porter (M2-LCDP) My opinion is that if you want to exchange compatible name, related all driver/document should be exchanged in same patch. For example, above "h3ulcb" case, patch subject indicates "rename h3ulcb" or something, and it include [03/14][04/14][05/14][06/14]. Same for m3
