lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 20 Jan 2023 14:08:16 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Ahmad Fatoum <a.fatoum@...gutronix.de>
Cc:     Arun.Ramadoss@...rochip.com, olteanv@...il.com,
        UNGLinuxDriver@...rochip.com, f.fainelli@...il.com,
        kuba@...nel.org, Woojung.Huh@...rochip.com, davem@...emloft.net,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel@...gutronix.de, pabeni@...hat.com, ore@...gutronix.de,
        edumazet@...gle.com
Subject: Re: [PATCH net] net: dsa: microchip: fix probe of I2C-connected
 KSZ8563

On Fri, Jan 20, 2023 at 08:57:03AM +0100, Ahmad Fatoum wrote:
> Hello Arun,
> 
> On 20.01.23 08:01, Arun.Ramadoss@...rochip.com wrote:
> > Hi Ahmad,
> > On Thu, 2023-01-19 at 14:10 +0100, Ahmad Fatoum wrote:
> >> [You don't often get email from a.fatoum@...gutronix.de. 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.

     Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ