On Wed, May 21, 2014 at 12:17:09PM +0200, Nicolas Ferre wrote: > On 20/05/2014 18:47, Olof Johansson : > > Hi, > > > > On Tue, May 20, 2014 at 05:19:24PM +0200, Nicolas Ferre wrote: > >> On 20/05/2014 07:50, Olof Johansson : > >>> On Wed, May 14, 2014 at 11:19:22AM +0200, Nicolas Ferre wrote: > >>>> Arnd, Olof, Kevin, > >>>> > >>>> More DT material for AT91. Some fixes that apply on what was merged for > >>>> 3.15 > >>>> but that are not very critical. > >>>> The other patches are feature additions to old or very recent > >>>> product/board: > >>>> at91sam9261 or sama5d3 Xplained. > >>>> > >>>> Thanks, best regards, > >>>> > >>>> The following changes since commit > >>>> 27a96a0364787d2b41d2a72d08143d95263e1b07: > >>>> > >>>> ARM: at91: sama5d3: clock for ssc from rk pin (2014-04-18 22:43:44 > >>>> +0200) > >>>> > >>>> are available in the git repository at: > >>>> > >>>> git://github.com/at91linux/linux-at91.git tags/at91-dt2 > >>>> > >>>> for you to fetch changes up to a93f9c88b7701d1c4c3b22d39d64a408f000a6ef: > >>>> > >>>> ARM: at91/dt: at91-sama5d3_xplained: add the regulator device node > >>>> (2014-05-12 16:48:54 +0200) > >>> > >>> Merged, but: > >>> > >>>> arch/arm/boot/dts/at91-sama5d3_xplained.dts | 62 +++++++++++++++ > >>>> arch/arm/boot/dts/at91sam9261.dtsi | 114 > >>>> ++++++++++++++++++++++++++-- > >>>> arch/arm/boot/dts/at91sam9rl.dtsi | 7 +- > >>>> arch/arm/boot/dts/sama5d3.dtsi | 78 +++++++++++++++++++ > >>> > >>> Grmbl. I remember being somewhat annoyed that you didn't use at91 prefix > >>> when you introduced the sama5d3 dtsi files, but please don't start using > >>> it on a random board like this, especially when other boards just use > >>> the sama5d3_<board>.dts format. > >> > >> Well, I don't understand completely. Since our discussion during 3.10 > >> merge window ([GIT PULL] at91: DT changes for 3.10 #2), I try to conform > >> to this rule: > >> > >> 1/ all pre-3.10 and 3.10 device tree file names stay unchanged > >> -> sama5d3.dti (SoC) > >> -> sama5d35ek.dts (board) > >> > >> 2/ all *SoC* DT files conform to their marking: > >> at91sam9263.dtsi > >> at91sam9rl.dtsi > >> sama5d3.dtsi, sama5d36.dtsi > >> sama5d4.dtsi, sama5d46.dtsi (maybe in the future, who knows...) > >> > >> 3/ all post-3.10 *boards* have the "at91-" prefix, whether they are > >> populated with sam9 or sama5: > >> at91-ariag25.dts (since 3.10, using a at91sam9g25) > >> at91-qil_a9260.dts (since 3.14, using at91sam9260) > >> at91-sama5d3_xplained.dts (since 3.14, using sama5d36) > >> > >> The rule for AT91 has never been to prefix the board DT filename with > >> the name of the SoC or SoC family. > > > > So, going back and looking at the discussion from a year ago, I think the > > disconnect was in what consistency we were looking for. Yes, we would have > > preferred to prefix the sama5d3* dts/dtsis with at91, and you even > > offered to do it. ;-) But I think even more important for sanity is > > to stay consistent with how we handle all platforms, which is that the > > board dts files are prefixed with the SoC name. > > > > In the past, we've had cases where this didn't happen, but these days we > > have > > tried to be very consistent on it. I.e. omap3*, exynos<##>*, etc. > > Okay, but once again, I tried to deal with the existing files, not break > any user's habit, before any convention had been clearly established, > and now... we are reaching a deadlock having to re-consider again our DT > filenames?
I don't think we're at a deadlock here. We're trying to figure out the best way forward. > > > So, if you have at91- as a prefix, have the SoC as the second component. But > > that gets awkward too, so I would juts use the current SoC dtsi as the > > prefix > > at91sam9263-<boardname>.dts, or sama5d35_<boardname>.dts. > > > >>> Care to fix this up in time for 3.16 merge window? > >> > >> Well, I do not know what to fix as the files were already present in > >> mainline before this kernel revision and that I am a little bit > >> reluctant to change file names after they are merged in mainline. > >> > >> Now, can we keep the current policy described above (somehow weird, I > >> admit) for future SoCs and boards? > > > > It is unfortunate that I didn't catch this for 3.14 so that name has been > > there in a release. I guess the least disruptive thing for now would be > > to change over to use the SoC dtsi prefix for any new board files from > > here on out, and treat at91-sama5d3_xplained as a one-time thing. > > That is not only about sama5d3, what about sam9-based boards? Several of > them already have this "at91-" prefix (and not a soc prefix). > > So this will introduce another temporary naming convention for these > files which are actually used by people: everyone will be puzzled. Yes, everyone is already puzzled though. > Okay, there are two ways to escape this situation: > 1/ change nothing and conform to what I stated above. It is more like > finding a rationale to an existing situation than a real neat > policy, but hey, "nobody's perfect". > 2/ change *everything* in AT91 DT file naming with a schema that > we will have to validate with care (<soc family> or <soc>, > "_" or "-", what about boards with modules, etc.). > That will certainly disturb many of our users without a real benefit. I don't think it's worth renaming everything at this time. > This directory is flat, the board names are chosen by companies and > people that we do not control, a user tend to like finding his preferred > board dtb file unchanged from a kernel revision to another... > Well all this lead me to think that we don't have to loose too much time > thinking about a new strict convention for this file naming or changing > all this once again just for the sake of it. > > Other SoC maintainers beautifully designed from the beginning the naming > scheme of their DT files, fine. AT91 did not and forgive me but when > opening arch/arm/boot/dts/Makefile file and seeing some file names, I'm > not ashamed. Moreover, now that I said to everybody since 3.10 to prefix > their *board* name with "at91-", I have to say something else, I don't > think it is worth it. I don't agree with everything above, but it's not worth arguing for the sake of arguing. :) I think we can tweak what you're doing now and get things to work well by merging new dts files with at91-<soc>-board.dts as the name. As mentioned, don't worry about the existing files. This shouldn't be a significiant change to what you've been telling people since 3.10 to cause much confusion. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
