Hello Andrew, On Wed, May 24, 2023 at 12:48:34PM -0500, Andrew Davis wrote: > On 5/24/23 9:36 AM, Francesco Dolcini wrote: > > From: Francesco Dolcini <francesco.dolcini@xxxxxxxxxxx> > > > > Add toradex,verdin-am62 for Toradex Verdin AM62 SoM, its > > nonwifi and wifi variants and the carrier boards (Dahlia, > > Verdin Development Board and Yavia) they may be mated in. > > > > Link: https://developer.toradex.com/hardware/verdin-som-family/modules/verdin-am62/ > > Link: https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62 > > Signed-off-by: Francesco Dolcini <francesco.dolcini@xxxxxxxxxxx> > > --- > > .../devicetree/bindings/arm/ti/k3.yaml | 20 +++++++++++++++++++ > > 1 file changed, 20 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml > > index e1183f90bb06..e3aee191d403 100644 > > --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml > > +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml > > @@ -33,6 +33,26 @@ properties: > > - ti,am62-lp-sk > > - const: ti,am625 > > + - description: K3 AM62x SoC Toradex Verdin Modules and Carrier Boards > > + items: > > + - enum: > > + - toradex,verdin-am62-nonwifi-dahlia # Verdin AM62 Module on Dahlia > > + - toradex,verdin-am62-nonwifi-dev # Verdin AM62 Module on Verdin Development Board > > + - toradex,verdin-am62-nonwifi-yavia # Verdin AM62 Module on Yavia > > + - const: toradex,verdin-am62-nonwifi # Verdin AM62 Module without Wi-Fi / BT > > Does this add anything? Not sure we need to split compatibles based on this, things > like wifi vs nowifi can be described in DT, same for different memory size models, etc.. > > In fact I'm not sure we get much value at all out of top level whole-SoC compatible > strings. Maybe we did when there was matching in kernel to do device specific fixups, > but that isn't really used much in ARM64. This is useful, as an example, once you add DT overlays to the mix and you use the compatible to match for "compatibility". An overlay could be compatible with the SoC, with the SoM (module + SoC) or with the complete board (Soc + SoM + carrier board). Our system is modular and this is described with this multiple layer of DT compatibles and with a similar layering of dtsi includes. On the wifi vs non-wifi topic, that is IMO the most conflicting one, the main reason is that the SoM has different assembly options, and this affects the pinmux and the functionality available to the carrier, up to the SoM edge connector (this could make an overlay compatible only with a board with/without-wifi). As an example there is a SDIO interface that is used for the on-SoM Wi-Fi in the Wi-Fi/BT variant, or available on the edge connector otherwise. An overlay using this SDIO interface would be compatible only with the non-wifi variant. Additional GPIOs or other signals might have the exact same situations. On this last variant (wifi vs non-wifi) I am not sure how often is used, we have the exact same approach with multiple NXP i.MX based boards and it proved itself to work fine. Francesco
