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

[Kyle Switch <kyle.switch@motor-comm.com>]

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