netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "Marek Behún" <kabel@kernel.org>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: Further phylink changes (was: [PATCH net-next 1/4] net: dsa: ocelot: populate supported_interfaces)
Date: Fri, 25 Feb 2022 17:40:25 +0000	[thread overview]
Message-ID: <YhkUidpCbLjrdMAE@shell.armlinux.org.uk> (raw)
In-Reply-To: <20220225181653.00708f13@thinkpad>

On Fri, Feb 25, 2022 at 06:16:53PM +0100, Marek Behún wrote:
> On Fri, 25 Feb 2022 16:31:52 +0000
> "Russell King (Oracle)" <linux@armlinux.org.uk> wrote:
> 
> > On Fri, Feb 25, 2022 at 04:25:30PM +0000, Vladimir Oltean wrote:
> > > On Fri, Feb 25, 2022 at 04:19:25PM +0000, Russell King (Oracle) wrote:  
> > > > Populate the supported interfaces bitmap for the Ocelot DSA switches.
> > > > 
> > > > Since all sub-drivers only support a single interface mode, defined by
> > > > ocelot_port->phy_mode, we can handle this in the main driver code
> > > > without reference to the sub-driver.
> > > > 
> > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> > > > ---  
> > > 
> > > Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > > Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>  
> > 
> > Brilliant, thanks.
> > 
> > This is the final driver in net-next that was making use of
> > phylink_set_pcs(), so once this series is merged, that function will
> > only be used by phylink internally. The next patch I have in the queue
> > is to remove that function.
> > 
> > Marek Behún will be very happy to see phylink_set_pcs() gone.
> 
> Yes, finally we can convert mv88e6xxx fully :)

... changing the subject line to show we've drifted off topic ...

Yes, once we've worked out what the PCS interface should look like in
order to deal with the 88E6393 errata workaround that needs to be run
each time the interface changes or whenever we "power up" the PCS.

I think that needs to be discussed, because I can see no clean and
clear solution that doesn't have some kind of down-side.

The existing pcs_enable/pcs_disable I have in my tree fits well with
the idea of changing a PCS, but not for being called every time we do
a major config when the PCS isn't being changed. To see what I mean,
would someone who didn't have the 6393 issue be happy with this
sequence on every major configuration, even when the PCS isn't being
changed:

	mac_prepare()
	pcs_disable()
	mac_config()
	pcs_enable()
	pcs_config()
	pcs_an_restart()
	mac_finish()

I thought about calling pcs_disable() pcs_prepare() but that then
throws out pcs_enable(), unless we do that after pcs_config() - but
what if pcs_enable() is used to clear the PDOWN bit of the PCS, or
other (possibly external) PCS power control that prevents its registers
being accessed.

I'm also thinking, having had another recent look at
mv88e6xxx_mac_config(), we would need to move this:

        if (mode != MLO_AN_PHY || !mv88e6xxx_phy_is_internal(ds, port)) {
                /* In inband mode, the link may come up at any time while the
                 * link is not forced down. Force the link down while we
                 * reconfigure the interface mode.
                 */
                if (mode == MLO_AN_INBAND &&
                    p->interface != state->interface &&
                    chip->info->ops->port_set_link)
                        chip->info->ops->port_set_link(chip, port,
                                                       LINK_FORCED_DOWN);

into a mac_prepare() callback so it still happens prior to the PCS
being called - which will need to happen between mac_prepare() and
mac_config() for the errata. That means extending the mac_prepare()
and mac_finish() methods into DSA as well.

I do have a patch to add those additional callbacks to DSA, but I
currently have no code that makes use of them (so haven't sent it
yet.) See "net: dsa: add support for new phylink calls".

I think I would prefer at this point - to get the mt7530 changes
settled, which will then allow the phylink_helper_basex_speed()
helper to be removed, do a few further phylink/sfp code cleanups
(using %pe consistently in that code to print errors) and then wait
until the next kernel cycle before tackling mv88e6xxx.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

  reply	other threads:[~2022-02-25 17:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-25 16:19 [PATCH net-next v2 0/4] net: dsa: ocelot: phylink updates Russell King (Oracle)
2022-02-25 16:19 ` [PATCH net-next 1/4] net: dsa: ocelot: populate supported_interfaces Russell King (Oracle)
2022-02-25 16:25   ` Vladimir Oltean
2022-02-25 16:31     ` Russell King (Oracle)
2022-02-25 17:16       ` Marek Behún
2022-02-25 17:40         ` Russell King (Oracle) [this message]
2022-02-25 17:57           ` Further phylink changes (was: [PATCH net-next 1/4] net: dsa: ocelot: populate supported_interfaces) Andrew Lunn
2022-02-25 18:11             ` Russell King (Oracle)
2022-02-25 16:19 ` [PATCH net-next 2/4] net: dsa: ocelot: remove interface checks Russell King (Oracle)
2022-02-25 16:19 ` [PATCH net-next 3/4] net: dsa: ocelot: convert to mac_select_pcs() Russell King (Oracle)
2022-02-25 16:19 ` [PATCH net-next 4/4] net: dsa: ocelot: mark as non-legacy Russell King (Oracle)
2022-02-26 13:00 ` [PATCH net-next v2 0/4] net: dsa: ocelot: phylink updates patchwork-bot+netdevbpf

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=YhkUidpCbLjrdMAE@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kabel@kernel.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@gmail.com \
    --cc=vladimir.oltean@nxp.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).