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  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:   Thu, 28 May 2020 12:05:51 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Vasundhara Volam <vasundhara-v.volam@...adcom.com>,
        Netdev <netdev@...r.kernel.org>
Cc:     Michael Chan <michael.chan@...adcom.com>,
        Jiri Pirko <jiri@...nulli.us>,
        David Miller <davem@...emloft.net>,
        Jiri Pirko <jiri@...lanox.com>
Subject: Re: [PATCH v2 net-next 1/4] devlink: Add new "allow_fw_live_reset"
 generic device parameter.

On Thu, 28 May 2020 07:20:00 +0530 Vasundhara Volam wrote:
> > > The permanent value should be the NVRAM value.  If the NVRAM value is
> > > false, the feature is always and unconditionally disabled.  If the
> > > permanent value is true, the feature will only be available when all
> > > loaded drivers indicate support for it and set the runtime value to
> > > true.  If an old driver is loaded afterwards, it wouldn't indicate
> > > support for this feature and it wouldn't set the runtime value to
> > > true.  So the feature will not be available until the old driver is
> > > unloaded or upgraded.  
> >
> > Setting this permanent value to false makes the FW's life easier?  
> 
> It just disables the feature.
> 
> > Otherwise why not always have it enabled and just depend on hosts
> > not opting in?  
> 
> We are providing permanent value as a flexibility to user. We can
> remove it, if it makes things easy and clear.

I'd think less knobs means less to understand for the user and less
to test for the vendor. If disabling the feature doesn't buy FW
anything then perhaps it can just serve the purpose of setting the
default?

> > > > > 3. Now enable the capability in the device and reboot for device to
> > > > > enable the capability. Firmware does not get reset just by setting the
> > > > > param to true.
> > > > >
> > > > > $ devlink dev param set pci/0000:3b:00.1 name allow_fw_live_reset
> > > > > value true cmode permanent
> > > > >
> > > > > 4. After reboot, values of param.  
> > > >
> > > > Is the reboot required here?  
> > >
> > > In general, our new NVRAM permanent parameters will take effect after
> > > reset (or reboot).
> > >  
> > > > > $ devlink dev param show pci/0000:3b:00.1 name allow_fw_live_reset
> > > > > pci/0000:3b:00.1:
> > > > >   name allow_fw_live_reset type generic
> > > > >     values:
> > > > >       cmode runtime value true  
> > > >
> > > > Why is runtime value true now?
> > > >  
> > >
> > > If the permanent (NVRAM) parameter is true, all loaded new drivers
> > > will indicate support for this feature and set the runtime value to
> > > true by default.  The runtime value would not be true if any loaded
> > > driver is too old or has set the runtime value to false.  
> >
> > Okay, the parameter has a bit of a dual role as it controls whether the
> > feature is available (false -> true transition requiring a reset/reboot)
> > and the default setting of the runtime parameter. Let's document that
> > more clearly.  
> Please look at the 3/4 patch for more documentation in the bnxt.rst
> file. We can add more documentation, if needed, in the bnxt.rst file.

Ack, I read that, but it wasn't nearly clear enough. The command
examples helped much more.  I think the doc should be expanded.

Powered by blists - more mailing lists