netdev - Re: [PATCH netnext 04/16] net: aquantia: link interrupt handling functions

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]

Date:   Sat, 13 Apr 2019 18:22:37 +0000
From:   Igor Russkikh <Igor.Russkikh@...antia.com>
To:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>
CC:     "David S . Miller" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Nikita Danilov <Nikita.Danilov@...antia.com>,
        Dmitry Bogdanov <Dmitry.Bogdanov@...antia.com>
Subject: Re: [PATCH netnext 04/16] net: aquantia: link interrupt handling
 functions

Hi Heiner, Andrew,

>> If you just schedule a task from the hard irq handler, why not using
>> a threaded interrupt?
> 
> Yes, i was just about to say that.

Thanks, will check that.

>> And a further question because I worked on the Aquantia PHY driver:
>> I assume the integrated PHY's are identical or at least very similar
>> to the external ones like AQR107. Did you ever consider to switch
>> the PHY handling part of this driver to phylib?  This may help to
>> reduce complexity and code size of the driver.
> 
> Hi Heiner
> 
> I think this was discussed at the time the driver was first
> submitted. Or it could of been the USB version. The first version did
> actually allow access to PHY registers, and the MAC driver did poke
> some of the registers.
> 
> My guess is, other operating systems don't have a suitable PHY
> driver. So they pushed it all into firmware. As a result, they now
> possibly have an inferior experience on Linux than if they used the
> new PHY driver.

Not only because of that. Mainly because this product delivers integrated
mac/phy solution and MAC FW is made to rule all the specific phy configuration
and subtle work (things like pcie configuration, link interrupts, WOL features,
etc).

To use separate phylib driver, FW should be totally disabled, but hardware
is not designed to run in full featured mode without FW.

phylib driver could be used, and phy registers access is actually possible
from host, but using it will definitely cause conflicts with FW.

Hope that explains the current design. And Andrew is right, very similar
design is chosen on USB AQC driver we submitted recently.

Regards,
  Igor