linux-kernel - Re: [RFC PATCH net-next v4 01/28] net: mdio: ipq8064: clean whitespaces in define

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, 15 May 2021 20:40:47 +0100
From:   Jonathan McDowell <noodles@...th.li>
To:     Ansuel Smith <ansuelsmth@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH net-next v4 01/28] net: mdio: ipq8064: clean
 whitespaces in define

On Sat, May 15, 2021 at 08:20:40PM +0200, Ansuel Smith wrote:
> On Sat, May 15, 2021 at 07:08:57PM +0100, Jonathan McDowell wrote:
> > On Sat, May 15, 2021 at 07:30:26PM +0200, Ansuel Smith wrote:
> > > Do you want to try a quick patch so we can check if this is the case?
> > > (about the cover letter... sorry will check why i'm pushing this
> > > wrong)
> > 
> > There's definitely something odd going on here. I went back to mainline
> > to see what the situation is there. With the GPIO MDIO driver both
> > switches work (expected, as this is what I run with). I changed switch0
> > over to use the IPQ MDIO driver and it wasn't detected (but switch1
> > still on the GPIO MDIO driver was fine).
> > 
> > I then tried putting both switches onto the IPQ MDIO driver and in that
> > instance switch0 came up fine, while switch1 wasn't detected.
> > 
> 
> Oh wait, your board have 2 different switch? So they both use the master
> bit when used... Mhhh I need to think about this if there is a clean way
> to handle this. The idea would be that one of the 2 dsa switch should
> use the already defined mdio bus.
> 
> The problem here is that to use the internal mdio bus, a bit must be
> set or 0 is read on every value (as the bit actually disable the internal
> mdio). This is good if one dsa driver is used but when 2 or more are
> used I think this clash and only one of them work. The gpio mdio path is
> not affected by this. Will check if I can find some way to address this.

They're on 2 separate sets of GPIOs if that makes a difference - switch0
is in gpio0/1 and switch1 is on gpio10/11. Is the internal MDIO logic
shared between these? Also even if that's the case it seems odd that
enabling the MDIO for just switch0 doesn't work?

J.

-- 
101 things you can't have too much of : 3 - Sleep.