netdev - Re: i.mx6ul with DSA in multi chip addressing mode

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: <20190704132756.GB13859@lunn.ch>
Date:   Thu, 4 Jul 2019 15:27:56 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Benjamin Beckmeyer <beb@...-engel.de>
Cc:     netdev@...r.kernel.org
Subject: Re: i.mx6ul with DSA in multi chip addressing mode - no MDIO access

On Thu, Jul 04, 2019 at 10:54:47AM +0200, Benjamin Beckmeyer wrote:
> 
> On 03.07.19 17:55, Andrew Lunn wrote:
> > On Wed, Jul 03, 2019 at 03:10:34PM +0200, Benjamin Beckmeyer wrote:
> >> Hey folks,
> >>
> >> I'm having a problem with a custom i.mx6ul board. When DSA is loaded I can't 
> >> get access to the switch via MDIO, but the DSA is working properly. I set up
> >> a bridge for testing and the switch is in forwarding mode and i can ping the 
> >> board. But the MDIO access isn't working at address 2 for the switch. When I 
> >> delete the DSA from the devicetree and start the board up, I can access the 
> >> switch via MDIO.
> >>
> >> With DSA up and running:
> >>
> >> mii -i 2 0 0x9800
> >> mii -i 2 1
> >> phyid:2, reg:0x01 -> 0x4000
> >> mii -i 2 0 0x9803
> >> mii -i 2 1
> >> phyid:2, reg:0x01 -> 0x4000
> >> mii -i 2 1 0x1883
> >> mii -i 2 1
> >> phyid:2, reg:0x01 -> 0x4000
> > Hi Benjamin
> >
> > I'm guessing that the driver is also using register 0 and 1 at the
> > same time you are, e.g. to poll the PHYs for link status etc.
> >
> > There are trace points for MDIO, so you can get the kernel to log all
> > registers access. That should confirm if i'm right.
> >
> > 	  Andrew
> 
> Hi Andrew,
> you were absolutly right. The bus is really busy the whole time, I've 
> checked that with the tracepoints in mdio_access.
> 
> But I'm still wondering why isn't that with a single chip addressing 
> mode configured switch? I mean, okay, the switch has more ports, but
> I've checked the accesses for both. The 6321(single chip addressing 
> mode) has around 4-5 accesses to the MDIO bus and the 6390(multi chip 
> addressing mode) has around 600 accesses per second. 

Hi Benjamin

In single chip mode, reading a register is atomic. With multi-chip,
you need to access two registers, so it clearly is not atomic. And so
any other action on the bus will cause you problems when doing things
from user space without being able to take the register mutex.

But 4-5 vs 600 suggests you don't have the interrupt line in your
device tree. If you have the interrupt line connected to a GPIO, and
the driver knows about it, it has no need to poll the PHYs. I also
added support for 'polled interrupts', as a fall back when then
interrupt is not listed in device tree. 10 times a second the driver
polls the interrupt status register, and if any interrupts have
happened within the switch, it triggers the needed handlers. Reading
one status register every 100ms is much less effort than reading all
the PHY status registers once per second.

Still, 600 per second sounds too high. Do you have an SNMP agent
getting statistics?

	Andrew