Re: [PATCH net-next v5 1/6] net: dsa: motorcomm: refactor registration path for upcoming switch families

[Kyle Switch]

On 9/7/26 11:00, Andrew Lunn wrote:
> > > >    static const struct of_device_id yt921x_of_match[] = {
> > > > -       { .compatible = "motorcomm,yt9215" },
> > > > -       {}
> > > > +       {
> > > > +               .compatible = "motorcomm,yt9215",
> > > > +               .data = &yt92xx_series_info_table[YT921X],
> > > Redundant if you use both runtime identification and the match data.
> > > Also I'm concerned with early IO operations, although I didn't see any
> > > incorrectness here.
> > Ans: we have considered this issue before. in the next version, we
> >
> > will consider whether to do it via chip_detect() or using indexed
> >
> > assignment. From your suggestion, what are the side effects of each
> >
> > approach and which of the two approaches do you recommend?
> One problem with compatible is what do you do when it does not
> actually match the hardware, because the DT author has messed up?
>
> For the Marvell devices, the compatible only indicates where the ID
> register can be found, because Marvell likes hide and seek, they keep
> moving it. Once the ID register is read, it is matched against a table
> to find the correct structure for that device.
>
> Where compatible are interesting is when the silicon vendor messed up
> and produced two different devices with the same ID value, or put no
> ID in the ID register at all. Then you have to work around the silicon
> vendors mess, and hope the DT author gets it correct.
>
> My suggestion would be to use the ID register and not have
> compatibles.

Ans: Now i finally understand why Marvell does this. When i referred

to Marvell implementation before, i had the same question as David-

isn't this redundant? So for the future optimization direction of yt92xx

driver, i can completely do without the compatible info and instead use

chip_detect to match entries in the table. is my understanding correct?

> 	Andrew