[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190916100924.GM2286@nanopsycho.orion>
Date: Mon, 16 Sep 2019 12:09:24 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: David Ahern <dsahern@...il.com>
Cc: netdev@...r.kernel.org, stephen@...workplumber.org,
jakub.kicinski@...ronome.com, saeedm@...lanox.com,
mlxsw@...lanox.com, f.fainelli@...il.com
Subject: Re: [patch iproute2-next v4 0/2] devlink: couple forgotten flash
patches
Sun, Sep 15, 2019 at 07:58:33PM CEST, dsahern@...il.com wrote:
>On 9/14/19 12:00 AM, Jiri Pirko wrote:
>> Fri, Sep 13, 2019 at 07:25:07PM CEST, dsahern@...il.com wrote:
>>> On 9/12/19 12:29 PM, Jiri Pirko wrote:
>>>> From: Jiri Pirko <jiri@...lanox.com>
>>>>
>>>> I was under impression they are already merged, but apparently they are
>>>> not. I just rebased them on top of current iproute2 net-next tree.
>>>>
>>>
>>> they were not forgotten; they were dropped asking for changes.
>>>
>>> thread is here:
>>> https://lore.kernel.org/netdev/20190604134450.2839-3-jiri@resnulli.us/
>>
>> Well not really. The path was discussed in the thread. However, that is
>> unrelated to the changes these patches do. The flashing itself is
>> already there and present. These patches only add status.
>>
>> Did I missed something?
>>
>
>you are thinking like a kernel developer and not a user.
>
>The second patch has a man page change that should state that firmware
>files are expected to be in /lib/firmware and that path is added by the
>kernel so the path passed on the command line needs to drop that part.
The manpage change is just addition to the "EXAMPLES" section.
The fact that the file is expected to be in /lib/firmware is in the
devlink flash description right above:
devlink dev flash - write device's non-volatile memory.
DEV - specifies the devlink device to write to.
file PATH - Path to the file which will be written into device's flash. The path needs to be relative to one of the directories
searched by the kernel firmware loaded, such as /lib/firmware. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
component NAME - If device stores multiple firmware images in non-volatile memory, this parameter may be used to indicate which
firmware image should be written. The value of NAME should match the component names from devlink dev info and may be driver-
dependent.
EXAMPLES
devlink dev show
Shows the state of all devlink devices on the system.
devlink dev show pci/0000:01:00.0
Shows the state of specified devlink device.
devlink dev eswitch show pci/0000:01:00.0
Shows the eswitch mode of specified devlink device.
devlink dev eswitch set pci/0000:01:00.0 mode switchdev
Sets the eswitch mode of specified devlink device to switchdev.
devlink dev param show pci/0000:01:00.0 name max_macs
Shows the parameter max_macs attributes.
devlink dev param set pci/0000:01:00.0 name internal_error_reset value true cmode runtime
Sets the parameter internal_error_reset of specified devlink device to true.
devlink dev reload pci/0000:01:00.0
Performs hot reload of specified devlink device.
devlink dev flash pci/0000:01:00.0 file firmware.bin
Flashes the specified devlink device with provided firmware file name. If the driver supports it, user gets updates about the
flash status. For example:
Preparing to flash
Flashing 100%
Flashing done
I don't understand what is that you need :(
Powered by blists - more mailing lists