Message-ID: <CA+T6QPma+4DquH8wfY0gSdn9yaQvsK051tJrYiF6fUGBiMvQrQ@mail.gmail.com>
Date: Tue, 10 Jun 2025 08:48:16 -0400
From: Jason Kridner <jkridner@...il.com>
To: Conor Dooley <conor@...nel.org>
Cc: Kory Maincent <kory.maincent@...tlin.com>, Tony Lindgren <tony@...mide.com>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Aaro Koskinen <aaro.koskinen@....fi>, Andreas Kemnade <andreas@...nade.info>, 
	Kevin Hilman <khilman@...libre.com>, Roger Quadros <rogerq@...nel.org>, 
	Russell King <linux@...linux.org.uk>, Bajjuri Praneeth <praneeth@...com>, 
	Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, 
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>, linux-omap@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 2/5] binding: omap: Add lots of missing omap AM33 compatibles

On Mon, Jun 9, 2025 at 1:03 PM Conor Dooley <conor@...nel.org> wrote:
>
> On Mon, Jun 09, 2025 at 05:43:52PM +0200, 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@...tlin.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

What is the convention here? "beagle" is a vendor, so not sure why
this continues to be "ti". The owner of the brand for this board is
"The BeagleBoard.org Foundation". Not sure if it is reasonable to fix
this.

> >                - ti,am335x-evm
> > +              - ti,am335x-evmsk
> > +              - ti,am335x-pocketbeagle

This one is also "beagle", not "ti".

> > +              - ti,am335x-shc
> >                - ti,am3359-icev2
> > +              - vscom,onrisc
> > +          - const: ti,am33xx
> > +
> > +      - description: TI bone variants based on TI AM335
>
> "bone variant" sounds like some shortand or nickname. Are the boards not
> called "beaglebone green" and "beaglebone black"? Whatever about the
> compatible, the description should use the full name I think.

I'm not sure this is really needed. There is some desire to fall-back
to a building block level of functionality around these derivatives of
"BeagleBoard.org BeagleBone", including compatibility with the
expansion headers, but I don't think that will happen at this level.
In u-boot, it is possible to make the determination to utilize a
less-complete devicetree, but it seems impractical here.

What are the objections to just listing these all as TI AM33 based platforms?

>
> > +        items:
> > +          - enum:
> > +              - ti,am335x-bone-black

"beagle"

> > +              - ti,am335x-bone-green

This is a Seeed Technology Co., Ltd. board that licenses the
BeagleBone brand from the BeagleBoard.org Foundation, so "seeed", not
"ti".

> > +              - ti,am335x-pocketbeagle

Not sure why this one is repeated. Also, it very much begs the
definition of being a BeagleBone derivative outside of usage of the
PMIC.

> > +          - const: ti,am335x-bone
> > +          - const: ti,am33xx
> > +
> > +      - description: TI bone black variants based on TI AM335

There are lots of derivatives of BeagleBoard.org BeagleBone Black and
falling back to a compatible makes some sense, but I don't think it is
of practical benefit here the way things have worked out. The smarts
have to be in the bootloader based off of the board IDs and the kernel
is just going to do what it is told.

Now, if we had some practical overlays performed by the kernel, this
would all make some sense as patches between these variants provide
useful fallback operation, but this is otherwise confusing. I
appreciate the credit given to BeagleBoard.org for them being
variants, but this really isn't the place.

> > +        items:
> > +          - enum:
> > +              - sancloud,am335x-boneenhanced

Note that this one is correct to be "sancloud", who licenses the
BeagleBone brand from the BeagleBoard.org Foundation.

> > +              - ti,am335x-bone-black-wireless

"beagle"

> > +          - const: ti,am335x-bone-black
> > +          - const: ti,am335x-bone
> > +          - const: ti,am33xx
> > +
> > +      - description: TI bone green variants based on TI AM335
> > +        items:
> > +          - enum:
> > +              - ti,am335x-bone-green-wireless

"seeed"

> > +          - const: ti,am335x-bone-green
> > +          - const: ti,am335x-bone
> >            - const: ti,am33xx
> >
> >        - description: Compulab board variants based on TI AM33
> >
> > --
> > 2.43.0
> >


-- 
Learn about me and setup a meeting at
https://beagleboard.org/about/jkridner - a 501c3 non-profit educating
around open hardware computing

Powered by blists - more mailing lists