netdev - 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: <0d1b4dee-11bb-3605-699c-ea417484cb68@gmx.de>
Date:   Tue, 15 Nov 2016 22:24:59 +0100
From:   Lino Sanfilippo <LinoSanfilippo@....de>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     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

Hi,

On 15.11.2016 21:54, Florian Fainelli wrote:
> On 11/15/2016 12:46 PM, Lino Sanfilippo wrote:
>>> Could this be pulled out into a standard PHY driver? All the SLIC
>>> SLIC_PCR_ defines seems to be the same as those in mii.h. This could
>>> be a standard PHY hidden behind a single register.
>>>
>>>    Andrew
>> 
>> You are right, the driver should really use the defines in mii.h. I will fix this in
>>  a v2.
>> 
>> Concerning the use of the PHY API: What would be the advantage of using it? Note that the
>>  phy is always internal and not interchangeable. Is not the interchangeability of PHYs
>> the main reason for using this API?
> 
> Not reinventing the wheel primarily, while PHYLIB also solves the plug &
> play aspect of external PHYs, it also solves the basic link management,
> and consistent and reasonably well defined interface to user-space and
> drivers (statistics reporting, link, auto-negotiation, EEE etc.).
> 

Sure I see this point. But currently all the driver does concerning the phy is to
configure it for auto negotiation when the interface is brought up, nothing else.

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). 
Please also note that I do not have any datasheets or other documentation for the hardware, 
all I have as a reference is the driver code in staging. So I do not know which 
PHYs are actually used (the comments in the code mention Marvell and Cicada but this is
not very specific).

Regards,
Lino