linux-kernel - Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

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: <86165d2b-f9d5-a380-9bb0-f77c12691eb6@gmx.de>
Date:   Tue, 15 Nov 2016 23:34:38 +0100
From:   Lino Sanfilippo <LinoSanfilippo@....de>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>, davem@...emloft.net,
        charrer@...critech.com, liodot@...il.com,
        gregkh@...uxfoundation.org, devel@...verdev.osuosl.org,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit
 ethernet driver

On 15.11.2016 22:59, Andrew Lunn wrote:
>> The link state is retrieved by a command to the application processor that is running 
>> on the network card. Also the register to set the phy configuration is write-only, so
>> it is not even possible to do the usual mdio bit-banging in the Phy read() and write()
>> functions (however there seems to be another application processor command reserved 
>> for retrieving the PHY settings, but I have not tried it yet). 
> 
>>> +  			val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
>>> +		     	         SLIC_PCR_AUTONEG_RST;
>>> +			slic_write(sdev, SLIC_REG_WPHY, val);
> 
> This actually looks a lot like an MDIO write operation. The upper 16
> bits are the register, and the lower 16 bits are the data. What you
> don't have is the address. But maybe it is limited to one address.
> 
> If the processor command reserved for read works in a similar way, you
> have enough to do an MDIO bus.
> 

Ok, I will give it a try. Reading values via the application processor
is a bit awkward though, since it requires an address to a dma area as part of
the command and then the AP informs the driver via irq that the dma memory has 
been written. So probably the irq handler will have to set some flag and
the mdio_read() function will have to poll for that flag in place of doing 
bit-banging a register. 

> If you can get the read working look at registers 2 and 3. Compare
> what you get with the values at the end of marvell.c.
> 

Will do, thank you!

Lino