netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Marangi <ansuelsmth@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"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>,
	Christian Marangi <ansuelsmth@gmail.com>,
	Robert Marko <robimarko@gmail.com>,
	"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [net-next RFC PATCH v2 0/3] net: phy: support multi PHY in phy_driver Was: net: phy: detach PHY driver OPs from phy_driver struct
Date: Tue, 20 Feb 2024 20:50:47 +0100	[thread overview]
Message-ID: <20240220195103.15809-1-ansuelsmth@gmail.com> (raw)

This is an alternative implementation of "net: phy: detach PHY driver OPs
from phy_driver struct" with the same object in mind.
v2 is used to keep track of the similar attempts but this is the 3rd try
to accomplish the same object.

As was pointed out in the previous series, deatching OPs is a way too big
change (although IMHO needed, but I understand the problem with downstream
and ugly code). As suggested and was already an idea discussed privately,
a more easier approach is introduce an alternative way in phy_driver
struct to declare PHY with the use of an array of IDs.

The second attempt to this had a fundamental problem, as pointed out by
Florian, it did cause an ABI change in sysfs. This was caused by the fact
that sysfs entry are created dased on the first name the PHY driver is
registreted and changing the dev name after (although wrong) also doesn't
update the sysfs name.

The only solution to this problem is to register one driver for each PHY
ID like it's done currently.

This was the case for attempt 1 (detached OPs) and is implemented here in
the 3rd attempt.

To accomplish this, the mdiodrv has to be moved in a separate struct and
defined for each PHY the phy_driver supports (this is already the case
for each phy_driver struct). With this change, we can keep the current
phy_driver struct and support defining multi PHY.

Each PHY will be registered as a separate driver, (even if they are defined
in the same phy_driver struct) permitting to register it directly
with the right name.

For single PHY implementation, the phy_driver is internally converted to
.ids implementation by dynamically allocating the table with only one
entry.

This is needed to handle the move of mdiodrv from the phy_driver struct
to a more specific one for each PHY ID.

Changes v2:
- Drop c45 patch
- Complete rework to handle specifi names for PHYs (no ABI
  regression)

Christian Marangi (3):
  net: phy: add support for defining multiple PHY IDs in PHY driver
  net: phy: aquantia: group common OPs for PHYs where possible
  net: phy: bcm7xxx: rework phy_driver table to new multiple PHY ID
    format

 drivers/net/phy/aquantia/aquantia_main.c | 170 +++++++++--------------
 drivers/net/phy/bcm7xxx.c                | 140 +++++++++++--------
 drivers/net/phy/phy_device.c             | 127 ++++++++++++-----
 include/linux/phy.h                      |  38 ++++-
 4 files changed, 275 insertions(+), 200 deletions(-)

-- 
2.43.0


             reply	other threads:[~2024-02-20 19:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-20 19:50 Christian Marangi [this message]
2024-02-20 19:50 ` [net-next RFC PATCH v2 1/3] net: phy: add support for defining multiple PHY IDs in PHY driver Christian Marangi
2024-02-20 19:50 ` [net-next RFC PATCH v2 2/3] net: phy: aquantia: group common OPs for PHYs where possible Christian Marangi
2024-02-20 19:50 ` [net-next RFC PATCH v2 3/3] net: phy: bcm7xxx: rework phy_driver table to new multiple PHY ID format 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=20240220195103.15809-1-ansuelsmth@gmail.com \
    --to=ansuelsmth@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=florian.fainelli@broadcom.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=robimarko@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).