netdev - Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <CAACQVJreEC+0XhLAXpY5iPYL3R=Vpd-Bs-YXjRBKapDvfvzcng@mail.gmail.com>
Date:   Tue, 19 May 2020 16:20:14 +0530
From:   Vasundhara Volam <vasundhara-v.volam@...adcom.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Michael Chan <michael.chan@...adcom.com>,
        David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset"
 generic devlink parameter

On Tue, May 19, 2020 at 3:11 PM Jiri Pirko <jiri@...nulli.us> wrote:
>
> Tue, May 19, 2020 at 10:41:44AM CEST, michael.chan@...adcom.com wrote:
> >On Tue, May 19, 2020 at 12:30 AM Jiri Pirko <jiri@...nulli.us> wrote:
> >>
> >> Tue, May 19, 2020 at 07:43:01AM CEST, vasundhara-v.volam@...adcom.com wrote:
> >> >On Tue, May 19, 2020 at 10:57 AM Jiri Pirko <jiri@...nulli.us> 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.
>
I felt enable_hot_fw_reset is a self-descriptive name.

But to make it more common, is the name enable_live_fw_reset good?
or simply fw_reset?

Thanks.