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.
