Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux