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:   Mon, 10 Jun 2019 12:06:58 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH RFC] net: phy: add state PERM_FAIL

On 6/10/19 11:51 AM, Andrew Lunn wrote:
>> - a PHY driver that requires a firmware should either be loaded prior to
>> Linux taking over the PHY, or should be loaded by the PHY driver itself
> 
> Hi Florian
> 
> Both the Marvell10g and Aquantia PHY need the firmware in their FLASH.
> It is a slow operation to perform. And so far, everybody has done it
> from user space. I'm not sure we want to hold up the PHY driver probe
> for multiple minutes if we where to do this in kernel.
> 
>> So the bottom line of my reasoning is that, if we could make this
>> marvell10g specific for now, and we generalize that later once we find a
>> second candidate, that would seem preferable.
> 
> The obvious second candidate is the Aquantia PHY. And i probably have
> a board without firmware.

Right, but that's kind of exceptional because you likely will want to do
development on this platform, so having it not provisioned is handy.

Maybe the broader question is how do you, Heiner and Russell imagine a
genuine case where the PHY does not have a firmware provided/loaded
before Linux does take over (say, BoM cost savings dictate no flash can
be used) and it must be loaded at runtime, do we call an user
helper/tool, or do we left the kernel load the firmware? I am not
talking about the case where the firmware is not found because it's the
first time you bring up the board, but it could be covered as well.
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ