netdev - Re: [PATCH] net: phy: micrel: Do not use kszphy

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] [day] [month] [year] [list]

Date:   Wed, 4 May 2022 09:45:46 -0300
From:   Fabio Estevam <festevam@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Claudiu Beznea <claudiu.beznea@...rochip.com>,
        netdev <netdev@...r.kernel.org>,
        Oleksij Rempel <o.rempel@...gutronix.de>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Fabio Estevam <festevam@...x.de>,
        stable <stable@...r.kernel.org>
Subject: Re: [PATCH] net: phy: micrel: Do not use kszphy_suspend/resume for KSZ8061

Hi Andrew,

On Wed, May 4, 2022 at 9:19 AM Andrew Lunn <andrew@...n.ch> wrote:

> Thanks for the fix. What you fail to mention is why not call
> kszphy_probe() to populate priv? What makes this PHY special that it
> does not need the probe call?

Looking at the driver history, it has been like this since the beginning.

Adding kszphy_probe() only causes another NULL pointer dereference.

I would need to add both kszphy_probe() and driver_data.

Both can be added, but I don't think this would be material for stable.

I would not like to add a wrong driver_data and cause other problems.

IMHO, I would prefer to restore the Ethernet functionality first, then
if someone
is certain on the proper driver data, this could be added to net-next.

> Looking at the ksphy_driver structure, this seems to affect
> PHY_ID_KS8737 and PHY_ID_KSZ8061

Good catch, thanks.

ksz8737 has a .driver_data field, so I can add .driver_probe there.

For v2 I plan:

- Send two patch as a series:

patch 1/2 would be same as this one
patch 2/2 would pass driver_probe to ksz8737

Do you agree?

Thanks