From: "Marek Behún" <marek.behun@nic.cz>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Andrew Lunn <andrew@lunn.ch>,
Maxime Chevallier <maxime.chevallier@bootlin.com>,
Baruch Siach <baruch@tkos.co.il>, Chris Healy <cphealy@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH RFC russell-king 3/4] net: phy: marvell10g: change MACTYPE according to phydev->interface
Date: Tue, 18 Aug 2020 19:28:17 +0200 [thread overview]
Message-ID: <20200818192817.427b9b12@dellmb.labs.office.nic.cz> (raw)
In-Reply-To: <20200812155441.GR1551@shell.armlinux.org.uk>
On Wed, 12 Aug 2020 16:54:41 +0100
Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> On Wed, Aug 12, 2020 at 05:44:36PM +0200, Andrew Lunn wrote:
> > > I'm aware of that problem. I have some experimental patches
> > > which add PHY interface mode bitmaps to the MAC, PHY, and SFP
> > > module parsing functions. I have stumbled on some problems
> > > though - it's going to be another API change (and people are
> > > already whinging about the phylink API changing "too quickly",
> > > were too quickly seems to be defined as once in three years), and
> > > in some cases, DSA, it's extremely hard to work out how to
> > > properly set such a bitmap due to DSA's layered approach.
> >
> > Hi Russell
> >
> > If DSAs layering is causing real problems, we could rip it out, and
> > let the driver directly interact with phylink. I'm not opposed to
> > that.
>
> The reason I mentioned it is because I have this unpublished patch
> (beware, whitespace damaged due to copy-n-pasted):
>
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index c1967e08b017..ba32492f3ec0 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -1629,6 +1629,12 @@ static int dsa_slave_phy_setup(struct
> net_device *slave_dev)
>
> dp->pl_config.dev = &slave_dev->dev;
> dp->pl_config.type = PHYLINK_NETDEV;
> + __set_bit(PHY_INTERFACE_MODE_SGMII,
> + dp->pl_config.supported_interfaces);
> + __set_bit(PHY_INTERFACE_MODE_2500BASEX,
> + dp->pl_config.supported_interfaces);
> + __set_bit(PHY_INTERFACE_MODE_1000BASEX,
> + dp->pl_config.supported_interfaces);
>
> /* The get_fixed_state callback takes precedence over polling
> the
> * link GPIO in PHYLINK (see phylink_get_fixed_state). Only
> set
>
> Which clearly is a gross hack - this code certainly has no idea about
> what interfaces the port itself supports. How do we get around that
> with DSA layering?
>
> We could add yet-another-driver-call down into the DSA driver for it
> to fill in that information and keep the current structure. However,
> is that really the best solution - to have lots of fine grained driver
> calls?
>
> DSA feels to be very cumbersome and awkward to modify at least to me.
> Almost everything seems to be "add another driver call" at the DSA
> layer, followed by "add another sub-driver call" at the mv88e6xxx
> layer.
>
So I am encountering this now when testing my SFP + marvell10g patches
on a board with SFP cage on a DSA port.
I get what you find cumbersome, but I don't think there is other
reasonable solution here. We already have .phylink_validate, which
works with ethtool mode mask. So maybe a .phylink_config_init ?
Marek
next prev parent reply other threads:[~2020-08-18 17:28 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-10 22:06 [PATCH RFC russell-king 0/4] Support for RollBall 10G copper SFP modules Marek Behún
2020-08-10 22:06 ` [PATCH RFC russell-king 1/4] net: phy: add I2C mdio bus for RollBall compatible SFPs Marek Behún
2020-08-10 22:06 ` [PATCH RFC russell-king 2/4] net: phy: sfp: add support for multigig RollBall modules Marek Behún
2020-08-11 15:15 ` Russell King - ARM Linux admin
2020-08-12 13:33 ` Marek Behún
2020-08-12 14:33 ` Russell King - ARM Linux admin
2020-08-12 14:42 ` Marek Behún
2020-08-10 22:06 ` [PATCH RFC russell-king 3/4] net: phy: marvell10g: change MACTYPE according to phydev->interface Marek Behún
2020-08-11 15:21 ` Russell King - ARM Linux admin
2020-08-12 14:44 ` Marek Behún
2020-08-12 15:00 ` Russell King - ARM Linux admin
2020-08-12 15:37 ` Marek Behún
2020-08-12 15:48 ` Russell King - ARM Linux admin
2020-08-12 15:59 ` Marek Behún
2020-08-12 16:13 ` Marek Behún
2020-08-12 16:22 ` Russell King - ARM Linux admin
2020-08-12 16:28 ` Marek Behún
2020-08-12 16:30 ` Russell King - ARM Linux admin
2020-08-12 16:01 ` Russell King - ARM Linux admin
2020-08-12 16:15 ` Marek Behún
2020-08-12 15:44 ` Andrew Lunn
2020-08-12 15:54 ` Russell King - ARM Linux admin
2020-08-18 17:28 ` Marek Behún [this message]
2020-08-10 22:06 ` [PATCH RFC russell-king 4/4] net: phylink: don't fail attaching phy on 1000base-x/2500base-x mode Marek Behún
2020-08-11 15:08 ` [PATCH RFC russell-king 0/4] Support for RollBall 10G copper SFP modules Russell King - ARM Linux admin
2020-08-12 12:31 ` Marek Behún
2020-08-12 12:31 ` Marek Behún
2020-08-12 14:20 ` Marek Behún
2020-08-17 13:49 ` Russell King - ARM Linux admin
2020-08-18 13:43 ` Marek Behún
2020-08-18 15:08 ` Russell King - ARM Linux admin
2020-08-18 15:30 ` Marek Behún
2020-08-18 15:36 ` Russell King - ARM Linux admin
2020-08-18 15:47 ` Marek Behún
2020-08-18 16:34 ` Russell King - ARM Linux admin
2020-08-19 15:49 ` Marek Behún
2020-08-19 15:54 ` Marek Behún
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=20200818192817.427b9b12@dellmb.labs.office.nic.cz \
--to=marek.behun@nic.cz \
--cc=andrew@lunn.ch \
--cc=baruch@tkos.co.il \
--cc=cphealy@gmail.com \
--cc=f.fainelli@gmail.com \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
/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).