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

[Charles Perry <charles.perry@microchip.com>]

On Tue, Mar 03, 2026 at 07:32:25PM +0000, Conor Dooley wrote:
> 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?
> 

I know they are functionally equivalent but some blocks are fused. I don't
know about manufacturing processes, sorry.

> > > 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.
> 

Ok sounds good but I'll make "pic64hpsc" the favorite child and let
"pic64hx" fallback to "pic64hpsc".

> > 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.
> 

Ok, lets use "pic".

> > 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.
> 

Understood.

Thank you,
Charles

> > 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.