lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 25 Nov 2021 12:16:15 +0100
From:   Horatiu Vultur <horatiu.vultur@...rochip.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
CC:     <davem@...emloft.net>, <kuba@...nel.org>, <robh+dt@...nel.org>,
        <UNGLinuxDriver@...rochip.com>, <p.zabel@...gutronix.de>,
        <netdev@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next v3 3/6] net: lan966x: add port module support

The 11/24/2021 16:04, Russell King (Oracle) wrote:
> On Wed, Nov 24, 2021 at 04:43:23PM +0100, Horatiu Vultur wrote:
> > > > Actually, port->config.phy_mode will not get zeroed. Because right after
> > > > the memset it follows: 'config = port->config'.
> > >
> > > Ah, missed that, thanks. However, why should portmode and phy_mode be
> > > different?
> >
> > Because the serdes knows only few modes(QSGMII, SGMII, GMII) and this
> > information will come from DT. So I would like to have one variable that
> > will configure the serdes ('phy_mode') and one will configure the MAC
> > ('portmode').
> 
> I don't follow why you need this to be different.
> 
> Isn't the point of interfaces such as phy_set_mode_ext() such that we
> can achieve independence of the details of what is behind that
> interface - so, as it takes a PHY interface mode, if we're operating
> in 1000BASE-X, we pass that to phy_set_mode_ext(). It is then the
> responsibility of the Serdes PHY driver to decide that means "sgmii"
> mode for the Serdes?

I have kept the responsability in the network driver to decide which
interface should for serdes, but I can change that as you suggested.

> 
> For example, the Marvell CP110 comphy driver does this:
> 
>         if (submode == PHY_INTERFACE_MODE_1000BASEX)
>                 submode = PHY_INTERFACE_MODE_SGMII;
> 
> because the serdes phy settings for PHY_INTERFACE_MODE_1000BASEX are
> no different from PHY_INTERFACE_MODE_SGMII - and that detail is hidden
> from the network driver.

Yes, I will add a similar check in the serdes driver.

> 
> The next question this brings up is... you're setting all the different
> interface modes in phylink_config.supported_interfaces, which basically
> means you're giving permission for phylink to switch between any of
> those modes. So, what if the serdes is in QSGMII mode but phylink
> requests SGMII mode. Doesn't your driver architecture mean that if
> you're in QSGMII mode you can't use SGMII or GMII mode?
> 
> Is there some kind of restriction that you need to split this, or is
> this purely down to the way this driver has been written?

It was just the way the driver has been written.

> 
> I don't see any other driver in the kernel making this kind of split.
> 
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

-- 
/Horatiu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ