[PATCH v2 2/5] binding: omap: Add lots of missing omap AM33 compatibles

Andreas Kemnade andreas at kemnade.info
Mon Jun 16 03:03:51 PDT 2025


Am Mon, 9 Jun 2025 18:34:10 -0500
schrieb Andrew Davis <afd at ti.com>:

> On 6/9/25 10:43 AM, Kory Maincent wrote:
> > Add several compatible strings that were missing from the binding
> > documentation. Add description for Bone, BoneBlack and BoneGreen
> > variants.
> > 
> > Add several compatible that were missing from the binding.
> > 
> > Signed-off-by: Kory Maincent <kory.maincent at bootlin.com>
> > ---
> > 
> > Change in v2:
> > - New patch
> > ---
> >   Documentation/devicetree/bindings/arm/ti/omap.yaml | 38 ++++++++++++++++++++++
> >   1 file changed, 38 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/ti/omap.yaml b/Documentation/devicetree/bindings/arm/ti/omap.yaml
> > index 3603edd7361d..c43fa4f4af81 100644
> > --- a/Documentation/devicetree/bindings/arm/ti/omap.yaml
> > +++ b/Documentation/devicetree/bindings/arm/ti/omap.yaml
> > @@ -104,12 +104,50 @@ properties:
> >         - description: TI AM33 based platform
> >           items:
> >             - enum:
> > +              - bosch,am335x-guardian
> >                 - compulab,cm-t335
> > +              - grinn,am335x-chilisom
> > +              - gumstix,am335x-pepper
> > +              - moxa,uc-2101
> >                 - moxa,uc-8100-me-t
> > +              - myir,myc-am335x
> > +              - myir,myd-am335x
> >                 - novatech,am335x-lxm
> > +              - oct,osd3358-sm-refdesign
> > +              - tcl,am335x-sl50
> >                 - ti,am335x-bone
> >                 - ti,am335x-evm
> > +              - ti,am335x-evmsk
> > +              - ti,am335x-pocketbeagle
> > +              - ti,am335x-shc
> >                 - ti,am3359-icev2
> > +              - vscom,onrisc
> > +          - const: ti,am33xx
> > +
> > +      - description: TI bone variants based on TI AM335  
> 
> Do we really need these "bone variants" split out from the above
> list of TI AM33 based boards? We don't do that for any of the other
> boards, you get a SoC and a Board compatible, every classification
> in-between is just unneeded.
> 

We have something like this for the Pandaboards models. But
e.g. the i.MX Udoo Neo stuff which just differs in what is populated
does not have this. So I do not see a clear pattern. It could be useful
for userspace to store some board-specific configurations which might be
the same for a family of boards. So if people shout out loud that these
are needs, lets kep them.

Regards,
Andreas





More information about the linux-arm-kernel mailing list