Re: [PATCH net] net: dsa: microchip: fix probe of I2C-connected KSZ8563

[Ahmad Fatoum]

Hello Andrew,

On 20.01.23 14:08, Andrew Lunn wrote:
> On Fri, Jan 20, 2023 at 08:57:03AM +0100, Ahmad Fatoum wrote:
>> Hello Arun,
>>
>> On 20.01.23 08:01, Arun.Ramadoss@xxxxxxxxxxxxx wrote:
>>> Hi Ahmad,
>>> On Thu, 2023-01-19 at 14:10 +0100, Ahmad Fatoum wrote:
>>>> [You don't often get email from a.fatoum@xxxxxxxxxxxxxx. Learn why
>>>> this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>>>
>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>>>> know the content is safe
>>>>
>>>> Starting with commit eee16b147121 ("net: dsa: microchip: perform the
>>>> compatibility check for dev probed"), the KSZ switch driver now bails
>>>> out if it thinks the DT compatible doesn't match the actual chip:
>>>>
>>>>   ksz9477-switch 1-005f: Device tree specifies chip KSZ9893 but found
>>>>   KSZ8563, please fix it!
>>>>
>>>> Problem is that the "microchip,ksz8563" compatible is associated
>>>> with ksz_switch_chips[KSZ9893]. Same issue also affected the SPI
>>>> driver
>>>> for the same switch chip and was fixed in commit b44908095612
>>>> ("net: dsa: microchip: add separate struct ksz_chip_data for KSZ8563
>>>> chip").
>>>>
>>>> Reuse ksz_switch_chips[KSZ8563] introduced in aforementioned commit
>>>> to get I2C-connected KSZ8563 probing again.
>>>>
>>>> Fixes: eee16b147121 ("net: dsa: microchip: perform the compatibility
>>>> check for dev probed")
>>>
>>> In this commit, there is no KSZ8563 member in struct ksz_switch_chips.
>>> Whether the fixes should be to this commit "net: dsa: microchip: add
>>> separate struct ksz_chip_data for KSZ8563" where the member is
>>> introduced.
>>
>> I disagree. eee16b147121 introduced the check that made my device
>> not probe anymore, so that's what's referenced in Fixes:. Commit
>> b44908095612 should have had a Fixes: pointing at eee16b147121
>> as well, so users don't miss it. But if they miss it, they
>> will notice this at build-time anyway.
> 
> So it sounds like two different fixes are needed? For recent kernels
> this fix alone is sufficient. But for older kernels additional changes
> are needed. Is it sufficient to backport existing patches, or are new
> patches needed?
> 
> Please start fixing the current kernel. Once that is merged you can
> post a fix for older kernels, referencing the merged fix.

I misunderstood the issue. It's indeed a single commit that broke
it. I just sent a v2 with a revised commit message and the correct
Fixes:. The fix can be cherry-picked on its own to any kernel
that contains the offending commit without any prerequisite
patches.

Cheers,
Ahmad

> 
>      Andrew
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |