netdev - Re: [PATCH RFC] net: phy: add state PERM

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: <68508be9-1a36-48ab-7428-bf6e7f71be59@gmail.com>
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