[PATCH v4 2/4] ARM: dts: NSP: Add DT files for Meraki MX64 series

Arnd Bergmann arnd at arndb.de
Fri Jun 25 11:40:53 PDT 2021


On Fri, Jun 25, 2021 at 7:30 PM Florian Fainelli <f.fainelli at gmail.com> wrote:
> On 6/25/21 10:26 AM, Matthew Hagan wrote:
> > On 25/06/2021 10:59, Arnd Bergmann wrote:
> >
> > How about having separate bcm-nsp-ax and bcm-nsp-bx dtsi files with the
> > appropriate secondary-boot-reg and dma-coherent (or lack of)
> > properties, which then include bcm-nsp.dtsi. Thus we can also avoid use
> > of /delete-property/. Would this be preferable?

That sounds good to me.

> Is there any way that the Ax platforms could use a small shim between
> the boot loader and the kernel which could all of the necessary DT
> adaptation so the kernel only contains a single Device Tree source?
>
> Using something like this:
>
> https://github.com/zonque/pxa-impedance-matcher/
>
> could be useful.

I don't think that's necessary here, but I wouldn't object if someone
finds it useful and does the work. ;-)

> >> On the other hand, the /chosen, /aliases and  /memory nodes that you have
> >> in the .dtsi file should probably get moved into the .dts files, as these tend
> >> to be board specific settings, even if the examples you have are all
> >> the same.
> >
> > I did not come across any convention regarding this, though there are
> > plenty of cases where the /chosen, /aliases and /memory nodes are
> > defined in a .dtsi file and used by multiple similar boards. Also note
> > in this case /aliases is defined in bcm-nsp.dtsi, not by me. Would we
> > not prefer to avoid having 6x duplication?

We are not too consistent about this, and there are cases in which a
.dtsi file is used for a family of boards using different SoCs rather than
a particular SoC or SoC family.

In the bcm-nsp.dtsi example you mention, I would move the aliases into
the board files, mainly because there is no guarantee that each board
exposes both uarts and all three on-chip ethernet ports. Note that the
aliases are supposed to match whatever label you have on the board,
not what the numbers are in the chip.

      Arnd



More information about the linux-arm-kernel mailing list