On Thu, Jan 04, 2018 at 08:21:34AM -0600, Kyle Evans wrote: > On Wed, Jan 3, 2018 at 9:26 PM, David Gibson > <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Jan 03, 2018 at 08:04:52AM -0600, Kyle Evans wrote: > >> [... snip ...] > >> The problem is that these overlays aren't necessarily curated by a > >> single authority, so conflicts with multiple overlays trying to > >> reference a node is scary. Ideally, we'd like these things to be as > >> usable as possible for average Joe Blow. > > > > Yeah, fair enough. I'll re-evaluate your patches with that in mind. > > I appreciate your consideration, thank you. =) I'm not necessarily too > keen on requiring our users to likely have to disassemble every > overlay they receive or consider which order they apply in if they're > not functionally related. > > It also helps me out as I work on hardware that doesn't have complete > DTS in mainline Linux yet, so I'm frequently adding nodes via overlay > that reference base nodes not yet with phandles. Adding phandles to > everything as I go gets kind of messy in my overlays and makes it that > much more difficult to assemble an upstreamable patch. > > I've also had fleeting thoughts of writing a tool like dtdiff, but > will actually generate an overlay of the difference between the two > dts being compared. The main use case here being that we follow Linux > releases (not -rc) for our dts, so automatically generating a DTBO > from where we're at to the next stable release (perhaps in the later > -rc stage) would be really really helpful to evaluate if we still work > and what we need to fix. That's a cool idea. -- 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
