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:   Thu, 23 Mar 2023 20:42:44 +0100
From:   Álvaro Fernández Rojas <noltari@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     jonas.gorski@...il.com, andrew@...n.ch, olteanv@...il.com,
        davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
        pabeni@...hat.com, linux@...linux.org.uk, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/1] net: dsa: b53: mmap: add dsa switch ops

El jue, 23 mar 2023 a las 19:19, Florian Fainelli
(<f.fainelli@...il.com>) escribió:
>
> On 3/23/23 10:02, Álvaro Fernández Rojas wrote:
> > B53 MMAP switches have a MDIO Mux bus controller which should be used instead
> > of the default phy_read/phy_write ops used in the rest of the B53 controllers.
> > Therefore, in order to use the proper MDIO Mux bus controller we need to
> > replicate the default B53 DSA switch ops removing the phy_read/phy_write
> > entries.
>
> Did you try to implement b53_mmap_ops::phy_read16/phy_write16 and have
> them return -EIO such that you do not fallback to the else path:

Actually I tried -EINVAL and it didn't work, but I've just tried -EIO
and it works!
Many thanks for the suggestion!

I will send another patch adding phy_read/write ops and returning
-EIO, so please ignore this patch and sorry for the noise, but it took
a while until we reached a good solution for this :(...

>
>                    ret = b53_read16(priv, B53_PORT_MII_PAGE(addr),
>                                     reg * 2, &value);
>
> The reason for the hang I believe is because the B53_PORT_MII_PAGE is
> simply not mapped into the switch register space, and there is no logic
> within the switch block to return an error when you read at that invalid
> location.
>
> Re-implementing dsa_switch_ops is usually done when you have a very
> different switch integration logic, ala bcm_sf2, here it seems a bit of
> a tall order for simply not using the phy_read16/phy_write16 functions.
> --
> Florian
>

--
Álvaro

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ