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

[Andrew Lunn]

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

	Andrew