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

On 25/06/2021 10:59, Arnd Bergmann wrote:

On Fri, Jun 25, 2021 at 11:52 AM Matthew Hagan [off-list ref] wrote:

quoted

MX64 & MX64W Hardware info:
  - CPU: Broadcom BCM58625 Cortex A9 @ 1200Mhz
  - RAM: 2 GB (4 x 4Gb SK Hynix H5TC4G83CFR)
  - Storage: 1 GB (Micron MT29F8G08ABACA)
  - Networking: BCM58625 internal switch (5x 1GbE ports)
  - USB: 1x USB2.0
  - Serial: Internal header
  - WLAN(MX64W only): 2x Broadcom BCM43520KMLG on the PCI bus

This patch adds the Meraki MX64 series-specific bindings. Since some
devices make use of the older A0 SoC, changes need to be made to
accommodate this case, including removal of coherency options and
modification to the secondary-boot-reg.

Signed-off-by: Matthew Hagan <redacted>

Removing the dma-coherent flags in the dts file seemed really odd until
I read the text above. It would seem more logical to me to have a .dtsi file
that has all the a0 revision specific changes, and include that from the
dts file.

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?

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?

       Arnd

Matthew


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel