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  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]
Date:   Tue, 19 May 2020 11:41:32 +0200
From:   Jiri Pirko <>
To:     Michael Chan <>
Cc:     Vasundhara Volam <>,
        David Miller <>,
        Netdev <>
Subject: Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset"
 generic devlink parameter

Tue, May 19, 2020 at 10:41:44AM CEST, wrote:
>On Tue, May 19, 2020 at 12:30 AM Jiri Pirko <> wrote:
>> Tue, May 19, 2020 at 07:43:01AM CEST, wrote:
>> >On Tue, May 19, 2020 at 10:57 AM Jiri Pirko <> wrote:
>> >>
>> >> I don't follow, sorry. Could you be more verbose about what you are
>> >> trying to achieve here?
>> >As mentioned below, hot_fw_reset is a device capability similar to roce.
>> >Capability can be enabled or disabled on the device, if the device supports.
>> >When enabled and if supported firmware and driver are loaded, user can
>> >utilise the capability to fw_reset or fw_live_patch.
>> I don't undestand what exactly is this supposed to enable/disable. Could
>> you be more specific?
>Let me see if I can help clarify.  Here's a little background.  Hot
>reset is a feature supported by the firmware and requires the
>coordinated support of all function drivers.  The firmware will only
>initiate this hot reset when all function drivers can support it.  For
>example, if one function is running a really old driver that doesn't
>support it, the firmware will not support this until this old driver
>gets unloaded or upgraded.  Until then, a PCI reset is needed to reset
>the firmware.
>Now, let's say one function driver that normally supports this
>firmware hot reset now wants to disable this feature.  For example,
>the function is running a mission critical application and does not
>want any hot firmware reset that may cause a hiccup during this time.
>It will use this devlink parameter to disable it.  When the critical
>app is done, it can then re-enable the parameter.  Of course other
>functions can also disable it and it is only enabled when all
>functions have enabled it.
>Hope this clarifies it.  Thanks.

Okay. So this is about the "allowing to be reseted from the outside".
I see. For that I think it makes sense to have the devlink param.
However, I think that it would be fine to find more suitable name and
describe this properly in the docs.

Powered by blists - more mailing lists