linux-kernel - Re: [PATCH net-next v5 4/4] phy: aquantia: Determine rate adaptation support from registers

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]

Message-ID: <20230106230343.2noq2hxr4quqbtk4@skbuf>
Date:   Sat, 7 Jan 2023 01:03:43 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Sean Anderson <sean.anderson@...o.com>,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>, netdev@...r.kernel.org,
        "David S . Miller" <davem@...emloft.net>,
        Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org,
        Jakub Kicinski <kuba@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Tim Harvey <tharvey@...eworks.com>
Subject: Re: [PATCH net-next v5 4/4] phy: aquantia: Determine rate adaptation
 support from registers

On Thu, Jan 05, 2023 at 05:46:48PM +0000, Russell King (Oracle) wrote:
> On Thu, Jan 05, 2023 at 07:34:45PM +0200, Vladimir Oltean wrote:
> > So we lose the advertisement of 5G and 2.5G, even if the firmware is
> > provisioned for them via 10GBASE-R rate adaptation, right? Because when
> > asked "What kind of rate matching is supported for 10GBASE-R?", the
> > Aquantia driver will respond "None".
> 
> The code doesn't have the ability to do any better right now - since
> we don't know what sets of interface modes _could_ be used by the PHY
> and whether each interface mode may result in rate adaption.
> 
> To achieve that would mean reworking yet again all the phylink
> validation from scratch, and probably reworking phylib and most of
> the PHY drivers too so that they provide a lot more information
> about their host interface behaviour.
> 
> I don't think there is an easy way to have a "perfect" solution
> immediately - it's going to take a while to evolve - and probably
> painfully evolve due to the slowness involved in updating all the
> drivers that make use of phylink in some way.

Serious question. What do we gain in practical terms with this patch set
applied? With certain firmware provisioning, some unsupported link modes
won't be advertised anymore. But also, with other firmware, some supported
link modes won't be advertised anymore.

IIUC, Tim Harvey's firmware ultimately had incorrect provisioning, it's
not like the existing code prevents his use case from working.