All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Rob Herring <robh@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Michal Marek <michal.lkml@markovi.net>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Michal Simek <michal.simek@xilinx.com>,
	Anmar Oueja <anmar.oueja@linaro.org>,
	Bill Mills <bill.mills@linaro.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	linux-kbuild <linux-kbuild@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Subject: Re: [PATCH 1/1] of: unittest: rename overlay source files from .dts to .dtso
Date: Tue, 18 Jan 2022 20:54:35 +1100	[thread overview]
Message-ID: <YeaOW8oTBykIGXgD@yekko.fritz.box> (raw)
In-Reply-To: <CAMuHMdU4oUKaGxmaPiC=cX0XpHG3KXhr+4MywEfeQ8sq-EG18A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 7462 bytes --]

On Fri, Jan 14, 2022 at 10:25:03AM +0100, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> On Fri, Jan 14, 2022 at 3:10 AM Rob Herring <robh@kernel.org> wrote:
> > On Thu, Jan 6, 2022 at 11:23 AM Frank Rowand <frowand.list@gmail.com> wrote:
> > > Patient Geert has pinged again.
> >
> > If it's not a patch to be reviewed, then I'm not going to see it most
> > likely. I don't read the DT list regularly...
> 
> Fair enough...
> 
> > > If I remember correctly you guys were not thrilled with this idea, but
> > > also did not seem strongly against it.  Are you willing to go along
> > > with .dtso for overlay source files?  If so, I will revive this patch
> > > series.
> > >
> > > David, if you are against supporting .dtso in the dtc compiler then
> > > the kernel can still support it through make rules.

TBH, I barely remember the earlier discussion.  I am more or less
indifferent on .dtso.

> > I'm not really interested in diverging from dtc. I'd suggest moving
> > the discussion to dtc list and/or devicetree-spec if you want to get
> > more attention on this.
> 
> What needs to be supported in the dtc compiler?
> The fallback passed to guess_input_format() is "dts".
> So this has been working out-of-the-box since forever?

Right.  I usually like to supply -I and -O to dtc explicitly, in which
case the extensions basically irrelevant.

I suppose we could also issue warnings if the /plugin/ tag doesn't
match the file extension.

> > Also, keep in mind that extensions also affect MIME types which
> > someone was also asking about recently.
> 
> You mean "MIME type of Devicetree Blobs and Sources"[1]?
> According to [2](2022-01-13), none of that has happened.
> 
> [1] https://www.spinics.net/lists/devicetree-spec/msg00938.html
> [2] https://www.iana.org/assignments/media-types/media-types.xhtml
> 
> > > On 1/6/22 3:00 AM, Geert Uytterhoeven wrote:
> > > > On Tue, Aug 24, 2021 at 11:20 AM Geert Uytterhoeven
> > > > <geert@linux-m68k.org> wrote:
> > > >> On Tue, Jun 22, 2021 at 11:44 AM Geert Uytterhoeven
> > > >> <geert@linux-m68k.org> wrote:
> > > >>> On Sat, May 29, 2021 at 12:16 PM Geert Uytterhoeven
> > > >>> <geert@linux-m68k.org> wrote:
> > > >>>> On Sat, May 29, 2021 at 7:16 AM David Gibson
> > > >>>> <david@gibson.dropbear.id.au> wrote:
> > > >>>>> On Thu, May 27, 2021 at 09:21:05AM +0200, Geert Uytterhoeven wrote:
> > > >>>>> 65;6401;1c> On Thu, May 27, 2021 at 3:48 AM David Gibson
> > > >>>>>> <david@gibson.dropbear.id.au> wrote:
> > > >>>>>>> On Wed, May 26, 2021 at 04:21:48PM -0500, Frank Rowand wrote:
> > > >>>>>>>> On 5/26/21 1:11 AM, Viresh Kumar wrote:
> > > >>>>>>>>> On 22-04-21, 13:54, Frank Rowand wrote:
> > > >>>>>>>>>> On 4/22/21 3:44 AM, Geert Uytterhoeven wrote:
> > > >>>>>>>>>>> On Mon, Mar 29, 2021 at 9:23 PM Frank Rowand <frowand.list@gmail.com> wrote:
> > > >>>>>>>>>>>> On 3/27/21 12:40 PM, Rob Herring wrote:
> > > >>>>>>>>>>>>> On Wed, Mar 24, 2021 at 05:37:13PM -0500, frowand.list@gmail.com wrote:
> > > >>>>>>>>>>>>>> From: Frank Rowand <frank.rowand@sony.com>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Add Makefile rule to build .dtbo.o assembly file from overlay .dtso
> > > >>>>>>>>>>>>>> source file.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Rename unittest .dts overlay source files to use .dtso suffix.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> I'm pretty lukewarm on .dtso...
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> I was originally also, but I'm warming up to it.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> What's the status of this?
> > > >>>>>>>>>>
> > > >>>>>>>>>> I was planning to resend on top of the upcoming -rc1.
> > > >>>>>>>>>
> > > >>>>>>>>> Ping.
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Thanks for the prod...
> > > >>>>>>>>
> > > >>>>>>>> The .dtso convention was added to the dtc compiler, then a patch was
> > > >>>>>>>> accepted to revert one mention of .dtso ,though there still remains
> > > >>>>>>>> two location where .dtbo is still recognized (guess_type_by_name() in
> > > >>>>>>>> dtc and the help text of the fdtoverlay program).
> > > >>>>>>>>
> > > >>>>>>>> It seems that the general .dtso and .dtbo were not popular, so I'm
> > > >>>>>>>> going to drop this patch instead of continuing to try to get it
> > > >>>>>>>> accepted.
> > > >>>>>>>
> > > >>>>>>> AFAICT .dtbo is moderately well established, and I think it's a good
> > > >>>>>>> convention, since it matters whether a blob is an overlay or base
> > > >>>>>>> tree, and it's not trivial to tell which is which.
> > > >>>>>>
> > > >>>>>> Indeed.
> > > >>>>>>
> > > >>>>>>> .dtso is much more recent,
> > > >>>>>>
> > > >>>>>> Is it?
> > > >>>>>
> > > >>>>> Well, I wouldn't bet money on it, I just seem to remember encountering
> > > >>>>> .dtbo for some time before .dtso was mentioned.
> > > >>>>>
> > > >>>>>> The oldest reference I could find is from May 2015:
> > > >>>>>> "[PATCH/RFC] kbuild: Create a rule for building device tree overlay objects"
> > > >>>>>> https://lore.kernel.org/linux-devicetree/1431431816-24612-1-git-send-email-geert+renesas@glider.be/
> > > >>>>>
> > > >>>>> Hm, I think .dtbo is even older than that, but again, I wouldn't swear
> > > >>>>> to it.
> > > >>>>
> > > >>>> Sure. My work is based on Pantelis' work for BeagleBoard capes.
> > > >>>> His code (from 2013?) used .dtbo and .dts:
> > > >>>>
> > > >>>>     overlay/v3.10/merge:firmware/Makefile:$(obj)/%.dtbo: $(obj)/%.dts
> > > >>>> | $(objtree)/$(obj)/$$(dir %)
> > > >>>>
> > > >>>> So I might be the one who introduced .dtso...
> > > >>>>
> > > >>>>>> I have always used dtbo/dtso in my published overlays branches,
> > > >>>>>> referred from https://elinux.org/R-Car/DT-Overlays, and used by
> > > >>>>>> various people.
> > > >>>>>>
> > > >>>>>>> and I think there's much less value to it.
> > > >>>>>>
> > > >>>>>> IMHO the same reasoning as for dtb vs. dtbo applies to dts vs. dtso.
> > > >>>>>> It matters if the resulting blob will be an overlay or base tree,
> > > >>>>>> as the blob will have to be called .dtb or .dtbo.
> > > >>>>>> As dtc outputs to stdout by default, the caller has to provide the
> > > >>>>>> output filename, and thus needs to know.
> > > >>>>>> Even if dtc would name the output file based on the presence of
> > > >>>>>> "/plugin/" in the input file, the build system still needs to know
> > > >>>>>> for dependency tracking.
> > > >>>>>
> > > >>>>> Hm, fair point.  I was thinking of the the /plugin/ tag as the
> > > >>>>> distinction, whereas dtb is binary and the distinction isn't even
> > > >>>>> marked in the header.  But you're right that even readable text labels
> > > >>>>> inside the file don't really help make(1).  So, I retract that
> > > >>>>> assertion.
> > > >>>>
> > > >>>> Thanks!
> > > >>>>
> > > >>>>>> We also do have .dts vs. .dtsi.
> > > >>>
> > > >>> In the mean time, we're at rc7 again?
> > > >>
> > > >> That was v5.13-rc7. Now we're at v5.14-rc7...
> > > >>
> > > >> Will we live with the inability to e.g. let make distinguish between
> > > >> DT includes and overlays forever?
> > > >
> > > > I guess this is not gonna happen, so I'll convert all my overlays
> > > > from .dtso to .dts....
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2022-01-18  9:54 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-24 22:37 [PATCH 1/1] of: unittest: rename overlay source files from .dts to .dtso frowand.list
2021-03-25  4:41 ` [PATCH V4] kbuild: Add rule to build .dt.yaml files for overlays Viresh Kumar
2021-03-27 17:40 ` [PATCH 1/1] of: unittest: rename overlay source files from .dts to .dtso Rob Herring
2021-03-29 19:23   ` Frank Rowand
2021-04-22  8:44     ` Geert Uytterhoeven
2021-04-22 18:54       ` Frank Rowand
2021-05-26  6:11         ` Viresh Kumar
2021-05-26 21:21           ` Frank Rowand
2021-05-27  1:22             ` David Gibson
2021-05-27  7:21               ` Geert Uytterhoeven
2021-05-28  3:45                 ` David Gibson
2021-05-29 10:16                   ` Geert Uytterhoeven
2021-06-22  9:44                     ` Geert Uytterhoeven
2021-08-24  9:20                       ` Geert Uytterhoeven
2022-01-06  9:00                         ` Geert Uytterhoeven
2022-01-06 17:23                           ` Frank Rowand
2022-01-14  2:10                             ` Rob Herring
2022-01-14  9:25                               ` Geert Uytterhoeven
2022-01-18  9:54                                 ` David Gibson [this message]
2022-01-26 19:31                                 ` Rob Herring
2022-04-27 21:14                                   ` Rob Herring
2022-04-28  6:25                                     ` Geert Uytterhoeven
2022-04-28 13:05                                       ` Rob Herring
2022-04-28 18:16                                         ` Frank Rowand
2021-05-27 16:23               ` Frank Rowand

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=YeaOW8oTBykIGXgD@yekko.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=anmar.oueja@linaro.org \
    --cc=bill.mills@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=michal.simek@xilinx.com \
    --cc=pantelis.antoniou@konsulko.com \
    --cc=robh@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    /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.