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:   Sat, 4 Apr 2020 11:19:10 +0800
From:   Chuanhong Guo <gch981213@...il.com>
To:     René van Dorst <opensource@...rst.com>
Cc:     netdev@...r.kernel.org, stable@...r.kernel.org,
        Sean Wang <sean.wang@...iatek.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Russell King <rmk+kernel@...linux.org.uk>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-arm-kernel@...ts.infradead.org>,
        linux-mediatek@...ts.infradead.org,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net: dsa: mt7530: fix null pointer dereferencing in port5 setup

Hi!

On Sat, Apr 4, 2020 at 2:09 AM René van Dorst <opensource@...rst.com> wrote:
>
> Quoting Chuanhong Guo <gch981213@...il.com>:
>
> Hi Chuanhong,
>
> > The 2nd gmac of mediatek soc ethernet may not be connected to a PHY
> > and a phy-handle isn't always available.
> > Unfortunately, mt7530 dsa driver assumes that the 2nd gmac is always
> > connected to switch port 5 and setup mt7530 according to phy address
> > of 2nd gmac node, causing null pointer dereferencing when phy-handle
> > isn't defined in dts.
>
> MT7530 tries to detect if 2nd GMAC is using a phy with phy-address 0 or 4.

What if the 2nd GMAC connects to an external PHY on address 0 on a
different mdio-bus? This is already happening on mt7629 where the
integrated PHY connected to gmac2 is on address 0 and gmac1
connects to external mt753x switch.
On mt7621, the RGMII2 is always wired to switch mac5 as well as
external pins, and one should disable switch mac5 in this case or
there's pin conflict.

> If so, switch port 5 needs to be setup so that PHY 0 or 4 is available
> via port 5 of the switch. Any MAC can talk to PHY 0/4 directly via port 5.
> This is also explained in the kernel docs mt7530.txt.
>
> May be there are better way to detect that any node is using phy 0/4 of
> the switch.

It should never be detected. This piece of code is to configure how
RGMII2 on mt7530 is wired: PHY0/PHY4/switch MAC5/off. And it
should be implemented as a configurable dt property. We should
not make assumption that 2 RGMIIs always connected to the two
macs on mtk_eth_soc and we should never parse parent eth dts
in DSA driver.

-- 
Regards,
Chuanhong Guo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ