All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: "Marek Behún" <marek.behun@nic.cz>
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: Wed, 12 Aug 2020 16:48:37 +0100	[thread overview]
Message-ID: <20200812154837.GQ1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <20200812173716.140bed4d@dellmb.labs.office.nic.cz>

On Wed, Aug 12, 2020 at 05:37:16PM +0200, Marek Behún wrote:
> On Wed, 12 Aug 2020 16:00:54 +0100
> Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> 
> > On Wed, Aug 12, 2020 at 04:44:31PM +0200, Marek Behún wrote:
> > > There is another problem though: I think the PHY driver, when
> > > deciding whether to set MACTYPE from the XFI with rate matching
> > > mode to the 10GBASE-R/5GBASE-R/2500BASE-X/SGMII with AN mode,
> > > should check which modes the underlying MAC support.  
> > 
> > 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.
> > 
> 
> If by your experimental patches you mean
>   net: mvneta: fill in phy interface mode bitmap
>   net: mvpp2: fill in phy interface mode bitmap
> found here
>   http://git.arm.linux.org.uk/cgit/linux-arm.git/log/?h=clearfog
> I am currently working on top of them.
> 
> > Having bitmaps means that we can take the union of what the MAC and
> > PHY supports, and decide which MACTYPE setting would be most suitable.
> > However, to do that we're into also changing phylib's interfaces as
> > well.
> > 
> > > driver to phylink in the call to phylink_create. But there is no way
> > > for the PHY driver to get this information from phylink currently,
> > > and even if phylink exposed a function to return the config member
> > > of struct phylink, the problem is that at the time when
> > > mv3310_power_up is called, the phydev->phylink is not yet set (this
> > > is done in phylink_bringup_phy, and mv3310_power_up is called
> > > sometime in the phylink_attach_phy).  
> > 
> > We _really_ do not want phylib calling back into phylink functions.
> > That would tie phylink functionality into phylib and cause problems
> > when phylink is not being used.
> > 
> > I would prefer phylib to be passed "the MAC can use these interface
> > types, and would prefer to use this interface type" and have the
> > phylib layer (along with the phylib driver) make the decision about
> > which mode should be used.  That also means that non-phylink MACs
> > can also use it.
> > 
> 
> I may try to propose something, but in the meantime do you think the
> current version of the patch
>   net: phy: marvell10g: change MACTYPE according to phydev->interface
> is acceptable?

Well, I have other questions about it.  Why are you doing it in
the power_up function?  Do you find that the MACTYPE field is
lost when clearing the power down bit?  From what I read, it should
only change on hardware reset, and we don't hardware reset when we
come out of power down - only software reset.

-- 
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:[~2020-08-12 15:48 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 [this message]
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
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=20200812154837.GQ1551@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=baruch@tkos.co.il \
    --cc=cphealy@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=marek.behun@nic.cz \
    --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 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.