On Thu, Feb 21, 2019 at 09:57:41AM +0100, Maxime Ripard wrote:
> 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.
Ah, ok.
> 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?).
So, the former was the more obvious interpretation to me, but you're
the ones with the use case, so I think the semantics are up to you at
this point.
Given that, can you repost the change, and I'll apply it (lost track
of the original patch post, sorry).
--
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:
signature.asc
Description: PGP signature
