Hi David,
On Thu, Feb 21, 2019 at 03:32:20PM +1100, David Gibson wrote:
> On Thu, Feb 21, 2019 at 12:10:08PM +0800, Chen-Yu Tsai wrote:
> > On Thu, Feb 21, 2019 at 12:03 PM David Gibson
> > <david@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Thu, Feb 21, 2019 at 11:51:05AM +0800, Chen-Yu Tsai wrote:
> > > > Commit 4038fd90056e ("dtc: add ability to make nodes conditional on them
> > > > being referenced") added the new /omit-if-no-ref/ directive to mark
> > > > nodes as eligible to be discarded if not referenced. The mechanism to
> > > > process this happens before the symbol generation phase. This means even
> > > > if symbol generation is requested and the node has a label, it will be
> > > > discarded if there are no references to it within the same file.
> > > >
> > > > This is probably not what people expect. When using symbol generation to
> > > > compile base device trees for applying overlays, nodes with labels could
> > > > be referenced by the overlays, and therefore should be preserved.
> > >
> > > Hmm.. actually that does seem like the behaviour I'd expect. Using
> > > /omit-if-no-ref/ and then expecting the node to appear without
> > > referencing it seems like a user error.
> >
> > I suppose the use-case we're looking at is keeping the size small for
> > standard blobs, but having the nodes available when targeting overlay
> > uses. We're currently targeting pinctrl nodes for this. There are a
> > whole lot of muxing options for every SoC, but a board will only use
> > a small set of them. But with overlays, we'd want all the options to
> > be available so the overlays don't have to redefine them again.
> >
> > Not sure if this is practical, but it's the use case I had in mind.
> > Maybe we could come up with some new directive or compiler option?
>
> Hm, ok.
>
> Maxime, since you introduced omit-if-no-ref in the first place could
> you chime in on how this compares to your use case?
It's actually a discussion between Chen-Yu and I that started that
patch, and we have the same use-case. Basically, it all boils down to
whether or not it makes sense to remove those nodes at compile time
when the overlay support is added.
Both approaches work, either we say that the overlay cannot use nodes
marked as such all the time (but it's not really what we've documented
so far, so we're not really on the least suprise side here), or when
we're compiling with overlay support we keep all those nodes (which
would obviously fail to reduce the size of the final DTB by keeping
all these nodes around).
I'd prefer the latter, I guess. The only thing that would be broken
would be when your usecase is that you want a small DTB *and* the
overlay support, but because of the ovelay size overhead, I'm not sure
if it can happen (and we could introduce a command line option if
someone brings it up I guess?).
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Attachment:
signature.asc
Description: PGP signature
