DT best practices for defining multiple closely-related boards

DT best practices for defining multiple closely-related boards

[Robert P. J. Day]

  much shorter followup to previous note -- if we extend all that to
defining, say, two very closely-related boards, the acme "coyote1" and
"coyote2", then all i should end up needing (at most) is two new .dts
files:

  coyote1.dts
  coyote2.dts

both of which could include (among other things) common coyote content
in:

  coyote.dtsi

and that's it. unless there's something really novel about these
boards, all other content should come from kernel-supplied .dtsi
files, yes? and, once again, i'm asking since the design i was handed
again copies kernel-supplied .dtsi files and modifies them, apparently
for no other reason than to remove properties, which should have been
done with /delete-property/.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DT best practices for defining multiple closely-related boards

[Rob Herring]

On Sat, Oct 28, 2017 at 05:19:23AM -0400, Robert P. J. Day wrote:
> 
>   much shorter followup to previous note -- if we extend all that to
> defining, say, two very closely-related boards, the acme "coyote1" and
> "coyote2", then all i should end up needing (at most) is two new .dts
> files:
> 
>   coyote1.dts
>   coyote2.dts

Another option is if your bootloader can distinguish between boards, you 
fixup the dtb at runtime. Depends if managing mulitple dtbs and firmware 
images is a pain or not.

> 
> both of which could include (among other things) common coyote content
> in:
> 
>   coyote.dtsi
> 
> and that's it. unless there's something really novel about these
> boards, all other content should come from kernel-supplied .dtsi
> files, yes? and, once again, i'm asking since the design i was handed
> again copies kernel-supplied .dtsi files and modifies them, apparently
> for no other reason than to remove properties, which should have been
> done with /delete-property/.

Seems so, but people just copy things for a variety of reasons (laziness 
primarily).

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html