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]

Message-ID: <YKAlUEt/9MU8CwsQ@Ansuel-xps.localdomain>
Date:   Sat, 15 May 2021 21:47:28 +0200
From:   Ansuel Smith <ansuelsmth@...il.com>
To:     Jonathan McDowell <noodles@...th.li>
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:40:47PM +0100, Jonathan McDowell wrote:
> 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?
> 

The dedicated internal mdio on ipq8064 is unique and present on the
gmac0 address so yes it's shared between them. And this seems to be the
problem... As you notice the fact that different gpio are used for the
different switch fix the problem. So think that to use the dedicated
mdio bus with both switch we need to introduce some type of
syncronization or something like that.