From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Christian Marangi <ansuelsmth@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Florian Fainelli <florian.fainelli@broadcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Robert Marko <robimarko@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com>,
Nipun Gupta <nipun.gupta@amd.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Puneet Gupta <puneet.gupta@amd.com>,
Abhijit Gangurde <abhijit.gangurde@amd.com>,
Umang Jain <umang.jain@ideasonboard.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [net-next RFC PATCH 1/6] net: phy: add support for defining multiple PHY IDs in PHY driver
Date: Sun, 18 Feb 2024 19:33:06 +0000 [thread overview]
Message-ID: <ZdJbciylnw8+ve8V@shell.armlinux.org.uk> (raw)
In-Reply-To: <20240218190034.15447-2-ansuelsmth@gmail.com>
On Sun, Feb 18, 2024 at 08:00:27PM +0100, Christian Marangi wrote:
> Some PHY driver might implement the same OPs for different PHY ID and
> using a mask is not enough to match similar PHYs.
>
> To reduce code duplication, add support for defining multiple PHY IDs in
> PHY driver struct.
>
> Introduce a new variable in phy_driver struct, .ids, where a table array of
> mdio_device_id can be defined to reference multiple PHY IDs (with their
> own masks) supporting the same group of OPs and flags.
>
> Introduce a new variable in phy_device, .dev_id, where the matching
> mdio_device_id is stored. PHYs supporting multiple PHYs for one PHY
> driver struct, should use this instead of matching for phy_id.
>
> Single PHY ID implementation is still supported and dev_id is filled
> with the data from phy_driver in this case.
This looks like it's been reworked somewhat with my suggestion, or maybe
we just came across a similar structure for comparing the IDs?
> + phy_dev_id = (struct mdio_device_id *)&phydev->dev_id;
Why this cast? Try to write code that doesn't need casts.
> + /* Fill the mdio_device_id for the PHY istance.
> + * If PHY driver provide an array of PHYs, search the right one,
> + * in the other case fill it with the phy_driver data.
> + */
> + if (phy_driver_match(phydrv, phydev, &dev_id) && dev_id) {
> + memcpy(phy_dev_id, dev_id, sizeof(*dev_id));
> + } else {
> + phy_dev_id->phy_id = phydrv->phy_id;
> + phy_dev_id->phy_id_mask = phydrv->phy_id_mask;
So this is the _driver_ phy_id.
> static inline bool phydev_id_compare(struct phy_device *phydev, u32 id)
> {
> - return phy_id_compare(id, phydev->phy_id, phydev->drv->phy_id_mask);
> + return phy_id_compare(id, phydev->dev_id.phy_id,
> + phydev->dev_id.phy_id_mask);
And thus this code is now different (since it _was_ comparing the
phydev phy_id, and you've changed it to effectively the driver's
phy_id. While that should be the same for a matched driver, that
is still a change that probably is't intentional.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2024-02-18 19:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-18 19:00 [net-next RFC PATCH 0/6] net: phy: support multi PHY in phy_driver Was: net: phy: detach PHY driver OPs from phy_driver struct Christian Marangi
2024-02-18 19:00 ` [net-next RFC PATCH 1/6] net: phy: add support for defining multiple PHY IDs in PHY driver Christian Marangi
2024-02-18 19:33 ` Russell King (Oracle) [this message]
2024-02-18 19:57 ` Christian Marangi
2024-02-18 20:10 ` Andrew Lunn
2024-02-18 20:27 ` Christian Marangi
2024-02-18 20:34 ` Russell King (Oracle)
2024-02-18 20:44 ` Christian Marangi
2024-02-18 21:06 ` Russell King (Oracle)
2024-02-18 22:07 ` Andrew Lunn
2024-02-18 19:00 ` [net-next RFC PATCH 2/6] net: phy: fill phy_id with C45 PHY Christian Marangi
2024-02-18 19:35 ` Russell King (Oracle)
2024-02-18 19:59 ` Christian Marangi
2024-02-18 19:00 ` [net-next RFC PATCH 3/6] mod_devicetable: permit to define a name for an mdio_device_id Christian Marangi
2024-02-18 19:00 ` [net-next RFC PATCH 4/6] net: phy: support named mdio_device_id PHY IDs Christian Marangi
2024-02-18 19:00 ` [net-next RFC PATCH 5/6] net: phy: aquantia: group common OPs for PHYs where possible Christian Marangi
2024-02-18 19:00 ` [net-next RFC PATCH 6/6] net: phy: bcm7xxx: rework phy_driver table to new multiple PHY ID format Christian Marangi
2024-02-19 4:26 ` Florian Fainelli
2024-02-19 16:41 ` Christian Marangi
2024-02-19 20:15 ` Florian Fainelli
2024-02-19 22:00 ` Christian Marangi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZdJbciylnw8+ve8V@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=abhijit.gangurde@amd.com \
--cc=andrew@lunn.ch \
--cc=andriy.shevchenko@linux.intel.com \
--cc=ansuelsmth@gmail.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=florian.fainelli@broadcom.com \
--cc=gregkh@linuxfoundation.org \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nipun.gupta@amd.com \
--cc=pabeni@redhat.com \
--cc=pieter.jansen-van-vuuren@amd.com \
--cc=puneet.gupta@amd.com \
--cc=robimarko@gmail.com \
--cc=umang.jain@ideasonboard.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.