netdev - Re: [PATCH 1/2] net: phy: dp83869: Add PHY ID for chip revision 3

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]

Message-ID: <b2db4e61-8bc1-4076-a2b9-7b6a028461aa@lunn.ch>
Date: Tue, 14 May 2024 14:47:08 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Thomas Gessler <thomas.gessler@...eckmann-gmbh.de>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	MD Danish Anwar <danishanwar@...com>,
	Ravi Gunasekaran <r-gunasekaran@...com>
Subject: Re: [PATCH 1/2] net: phy: dp83869: Add PHY ID for chip revision 3

On Tue, May 14, 2024 at 02:27:27PM +0200, Thomas Gessler wrote:
> The recent silicon revision 3 of the DP83869 has a different PHY ID
> which has to be added to the driver in order for the PHY to be detected.
> There appear to be no documented differences between the revisions,
> although there are some discussions in the TI forum about different
> behavior for some registers.

Do you have the datasheet? What does it say about the ID in registers
2 and 3? Often the lower nibble is the revision. Meaning there can be
16 revisions of a PHY.

>  static struct phy_driver dp83869_driver[] = {
> -	DP83869_PHY_DRIVER(DP83869_PHY_ID, "TI DP83869"),
> +	DP83869_PHY_DRIVER(DP83869REV1_PHY_ID, "TI DP83869 Rev. 1"),
> +	DP83869_PHY_DRIVER(DP83869REV3_PHY_ID, "TI DP83869 Rev. 3"),
>  	DP83869_PHY_DRIVER(DP83561_PHY_ID, "TI DP83561-SP"),

If you look at DP83869_PHY_DRIVER() it uses:

#define DP83869_PHY_DRIVER(_id, _name)                          \
{                                                               \
        PHY_ID_MATCH_MODEL(_id),                                \

As the name suggests, it matches on the model. The revision is
ignored. A mask is applied to ignore the lower nibble. So this change
looks pointless.

>  static struct mdio_device_id __maybe_unused dp83869_tbl[] = {
> -	{ PHY_ID_MATCH_MODEL(DP83869_PHY_ID) },
> +	{ PHY_ID_MATCH_MODEL(DP83869REV1_PHY_ID) },
> +	{ PHY_ID_MATCH_MODEL(DP83869REV3_PHY_ID) },
>  	{ PHY_ID_MATCH_MODEL(DP83561_PHY_ID) },

And this has the same issue. If you want the match to include the
revision, you need to use PHY_ID_MATCH_EXACT(). If the different
revisions are supposed to be compatible, a single PHY_ID_MATCH_MODEL()
is sufficient.

    Andrew

---
pw-bot: cr