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
| ||
|
Date: Sat, 13 Apr 2019 20:26:23 +0200 From: Heiner Kallweit <hkallweit1@...il.com> To: Igor Russkikh <Igor.Russkikh@...antia.com>, Andrew Lunn <andrew@...n.ch> 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 On 13.04.2019 20:22, Igor Russkikh wrote: > > 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. > OK, I see. Thanks for the explanation! > Regards, > Igor > Heiner
Powered by blists - more mailing lists