Re: [PATCH net-next 1/4] dt-bindings: net: cdns,macb: add a compatible for Microchip p64h

[Conor Dooley]

On Tue, Mar 03, 2026 at 10:54:01AM -0800, Charles Perry wrote:
> On Tue, Mar 03, 2026 at 06:18:48PM +0000, Conor Dooley wrote:
> > On Tue, Mar 03, 2026 at 10:03:15AM -0800, Charles Perry wrote:
> > > "p64h" is shorthand for "PIC64-HPSC" and "PIC64HX"
> > 
> > No, sorry. If these are different SoCs they need to have SoC-specific
> > compatibles, particularly since PIC64HY could be something that is not
> > compatible with these devices. It'd be fine to add
> > "microchip,pic64hpsc-gem" with "microchip,pic64hx-gem" as a fallback
> > though, since they do appear to be very very very similar devices and
> 
> Yes, "very very very similar" is the right term.

FWIW, if the only difference was binning or fusing, having the same
compatible for more than one device could be okay. But these are
actually like polarfire-soc and rt-polarfire-soc, where they look very
similar to software but the rt process means that they're physically
different, right?

> > can clearly share the same match data in the driver. That's what pic64gx
> > and mpfs do.
> 
> Ok, no problem. Like this? :
> 
> ```
>       - items:
>           - enum:
>               - microchip,pic64hpsc-gem
>               - microchip,pic64hx-gem
>           - const: microchip,pic64h-gem
>           - const: cdns,gem

I was thinking
- items:
    - const: microchip,pic64hx-gem
    - const: cdns,gem
- items:
    - const: microchip,pic64hpsc-gem
    - const: microchip,pic64hx-gem
    - const: cdns,gem

And getting rid of the "pic64h" that may end up not being sufficiently
common in the future.

> Also, how important is it to use "pic64h" vs "p64h"?

Oh I didn't even notice that tbh, I just have "pic64" muscle memory from
the pic64gx, and the pic32mzda also spells it out. My OCD says says "pic",
and the fact that all the marketing stuff uses "pic" kinda votes in that
favour too.

> Much of the downstream development uses "p64h" in compatibles, file names,
> function names, etc. and it would create some overhead to rename
> everything.

This is probably one of the easiest things to absorb from a
up/down stream perspective, you could (and probably will on other
submissions) get far more disruptive feedback than something that's
effectively cosmetic and can be solved by adding a single line to a
driver. To be honest, I don't care if you rename functions or filenames,
it's only devicetree related things that I personally care about.

> Although, as I think of it, it might not be a bad thing since it would
> allow to quickly identify the mainstream from the downstream code.

Attachment: signature.asc
Description: PGP signature