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 01:41:44 -0700
From:   Michael Chan <>
To:     Jiri Pirko <>
Cc:     Vasundhara Volam <>,
        David Miller <>,
        Netdev <>
Subject: Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset"
 generic devlink parameter

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.

Powered by blists - more mailing lists