[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190610150607.22d4f963@cakuba.netronome.com>
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.
Powered by blists - more mailing lists