linux-kernel - Re: [PATCH] phy: aquantia: Configure SERDES mode by default

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 18 Nov 2022 19:30:14 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Sean Anderson <sean.anderson@...o.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
        Eric Dumazet <edumazet@...gle.com>,
        Tim Harvey <tharvey@...eworks.com>,
        "David S . Miller" <davem@...emloft.net>,
        linux-kernel@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH] phy: aquantia: Configure SERDES mode by default

On Fri, Nov 18, 2022 at 12:11:30PM -0500, Sean Anderson wrote:
> >> - We can check all the registers to ensure we are actually going to rate
> >>   adapt. If we aren't, we tell phylink we don't support it. This is the
> >>   least risky, but we can end up not bringing up the link even in
> >>   circumstances where we could if we configured things properly. And we
> >>   generally know the right way to configure things.
> > 
> > Like when?
> 
> Well, like whenever the phy says "Please do XFI/2" or some other mode we
> don't have a phy interface mode for. We will never be able to tell the MAC
> "Please do XFI/2" (until we add an interface mode for it), so that's
> obviously wrong.

Add an interface mode for it then... But note that I have absolutely no
clue what XFI/2 is. Apparently Aquantia doesn't want NXP to know....

> >> - Add a configuration option (devicetree? ethtool?) on which option
> >>   above to pick. This is probably what we will want to do in the long
> >>   term, but I feel like we have enough information to determine the
> >>   right thing to do most of the time (without needing manual
> >>   intervention).
> > 
> > Not sure I see the need, when long-term there is no volunteer to make
> > the Linux driver bring Aquantia PHYs to a known state regardless of
> > vendor provisioning. Until then, there is just no reason to even attempt
> > this.
> 
> I mean a config for option 1 vs 2 above.

How would this interact with Marek's proposal for phy-mode to be an
array, and some middle entity (phylink?) selects the SERDES protocol and
rate matching algorithm to use for each medium side link speed?
https://patchwork.kernel.org/project/netdevbpf/cover/20211123164027.15618-1-kabel@kernel.org/

> > Until you look at the procedure in the NXP SDK and see that things are a
> > bit more complicated to get right, like put the PHY in low power mode,
> > sleep for a while. I think a large part of that was determined experimentally,
> > out of laziness to change PHY firmware on some riser cards more than anything.
> > We still expect the production boards to have a good firmware, and Linux
> > to read what that does and adapt accordingly.
> 
> Alas, if only Marvell put stuff like this in a manual... All I have is a spec
> sheet and the register reference, and my company has an NDA...

Can't help with much more than providing this hint, sorry. All I can say
is that SERDES protocol override from Linux is possible with care, at
least on some systems. But it may be riddled with landmines.

> We aren't even using this phy on our board, so I am fine disabling rate adaptation
> for funky firmwares.

Disabling rate adaptation is one thing. But there's also the unresolved
XFI/2 issue?