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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 9 Jul 2019 15:20:38 +0200
From:   Benjamin Beckmeyer <beb@...-engel.de>
To:     Andrew Lunn <andrew@...n.ch>
CC:     <netdev@...r.kernel.org>
Subject: Re: i.mx6ul with DSA in multi chip addressing mode - no MDIO access

>> Hi Andrew,
>> I got it working a little bit better. When I'm fast enough I can read
>> the registers I want but it isn't a solution.
> Why do you need to read registers?
>
> What you actually might be interested in is the debugfs patches in
> Viviens github tree.
>
>> Here is an output of the tracing even with my custom accesses.
>> mii -i 2 0 0x9b60; mii -i 2 1
>> phyid:2, reg:0x01 -> 0xc801
>>
>> Do you know how to delete EEInt bit? It is always one. And now all 
>> accesses coming from the kworker thread. Maybe this is your polling 
>> function?
> EEInt should clear on read for older chips. For 6390, it might be
> necessary to read global 2, register 0x13, index 03.
>  
>> I view the INT pin on an oscilloscope but it never changed. So maybe
>> this is the problem. We just soldered a pull-up to that pin but it 
>> still never changend. Maybe you have an idea?
> The EEInt bit is probably masked. So it will not generate in
> interrupt.
>
>> So what I think is, because of the EEInt bit is never set back to one 
>> i will poll it as fast as possible.
> Is it forever looping in mv88e6xxx_g1_irq_thread_work? Or is it the
> polling code, mv88e6xxx_irq_poll() firing every 100ms?
>
> 	Andrew

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

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.

What do you think about it?

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.

Thanks again for your help and patience.

Cheers,
Benny