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] [day] [month] [year] [list]

Message-ID: <20190709135258.GC1965@lunn.ch>
Date:   Tue, 9 Jul 2019 15:52:58 +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

> Hi Andrew,
> good news first, it seems to be running ;-).

Great.

> 
> The interrupt GPIO pin was not correctly configured in the device tree.
> 
> For now we have around 68 accesses per second, I think this is okay 
> because we even have indirect access, so the bus must be more busy.

That sounds reasonable.

> Why we need access to the bus is because we have some software which was 
> using the DSDT driver and now we want to switch to the UMSD driver.
> But we hope that we can forget about all the UMSD driver stuff and the 
> DSDT driver stuff as well and just use the DSA part from the kernel.
> To be honest, so far I don't know what functions we need from the driver
> which aren't supported by the DSA.

You should take a close look at what you actually need. Using
DSDT/UMSD at the same time as mainline DSA does not sound like a good
idea. One can stomp over the other.

If you do decide to do this, you are going to need to add a new API to
allow DSDT/UMSD to get reliable access to the registers. You need to
take the chip->reg_lock to give you exclusive access to the
indirection registers. That also won't be accepted into mainline. We
don't want user space drivers...

      Andrew