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: <CAOX2RU7izQLrHQsTK9cFYEGtoE9=xOVTx64o7w-JZpg-+wYvuA@mail.gmail.com>
Date: Tue, 28 Nov 2023 12:47:46 +0100
From: Robert Marko <robimarko@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: andrew@...n.ch, hkallweit1@...il.com, davem@...emloft.net, 
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, ansuelsmth@...il.com, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 1/2] net: phy: aquantia: validate PHY mode on AQR107

On Fri, 17 Nov 2023 at 13:46, Russell King (Oracle)
<linux@...linux.org.uk> wrote:
>
> On Fri, Nov 17, 2023 at 11:09:48AM +0100, Robert Marko wrote:
> > The Aquantia driver is not setting the PHY mode itself, but it does however
> > still check if the PHY mode set in DTS is one of the supported modes.
> >
> > However, the set PHY mode does not have to match the actual one, so lets
> > add update the PHY mode during .config_init and warn if they differ.
>
> This looks completely wrong to me. These PHYs can be configured to
> change their MAC-facing interface mode according to the media negotiated
> speed, but you are only checking that _if_ the media is up, then the
> interface that has resulted from that negotiation matches what is in
> DTS. That could be dependent on the link partner, so what works for a
> platform when connected to one link partner may issue your "info"-level
> warning when connected to a different link partner.
>
> So no, this to me looks completely wrong.
>
> You need to check the VEND1_GLOBAL_CFG_* registers, and determine from
> those what interface mode(s) will be used, and then use that to validate
> the mode.
>
> It just so happens that...
>
> http://git.armlinux.org.uk/cgit/linux-arm.git/commit/?h=net-queue&id=f7b531ee8855f81d267a8a42c44da51576f48daf
> http://git.armlinux.org.uk/cgit/linux-arm.git/commit/?h=net-queue&id=f55389aa5d11da8a32dfd65a1b98049878ce09f0
>
> builds a bitmap that can then be tested to check this. Whether the
> above is entirely correct or not, I can't really say, I don't have
> enough information on this PHY.

Hi,
Yeah, I get the issue now.

Nice, those got merged into net-next, so I will iterate by using those.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ