netdev - Re: [patch net-next v3 3/3] devlink: implement flash status monitoring

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] [day] [month] [year] [list]

Date:   Mon, 10 Jun 2019 15:06:07 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
        davem@...emloft.net, mlxsw@...lanox.com, sthemmin@...rosoft.com,
        saeedm@...lanox.com, leon@...nel.org, f.fainelli@...il.com
Subject: Re: [patch net-next v3 3/3] devlink: implement flash status
 monitoring

On Mon, 10 Jun 2019 15:56:00 -0600, David Ahern wrote:
> On 6/10/19 11:47 AM, Jakub Kicinski wrote:
> > It's the kernel that does this, the request_firmware() API.  It's
> > documented in both devlink's and ethtool's API.  I was initially
> > intending to use the file request API directly in devlink, but because
> > of the requirement to keep compatibility with ethtool that was a no go.
> > 
> > FWIW you can load from any directory, just prefix the file name
> > with ../../ to get out of /lib/firmware.
> > 
> > I guess we could add some logic into devlink user space to detect that
> > user does not know about this quirk and fix up the path for them.. 🤔  
> 
> If the user can not load a file based on an arbitrary path, what is the
> point of the option in the devlink command? You might as well just have
> the driver use the firmware interface.

This may be a question about mlxsw quirks.  Traditionally drivers don't
flash firmware on probe.  Devlink/ethtool interface is for updating
flash contents, while probe may load FW directly into SRAM for devices
which don't store firmware on flash (e.g. most WiFi cards).

Also - devlink _can_ load from arbitrary paths.  User just has to assume
getcwd() == "/lib/firmware".  Probe has a hard coded file name it 
will try to load.