On 7/21/2020 3:19 PM, Jiri Pirko wrote:
Tue, Jul 21, 2020 at 11:51:21AM CEST, vasundhara-v.vo...@broadcom.com wrote:
On Wed, Jul 1, 2020 at 3:17 PM Jiri Pirko <j...@resnulli.us> wrote:
Wed, Jul 01, 2020 at 11:25:50AM CEST, vasundhara-v.vo...@broadcom.com wrote:
On Wed, Jul 1, 2020 at 11:21 AM Jiri Pirko <j...@resnulli.us> wrote:
Tue, Jun 30, 2020 at 05:15:18PM CEST, vasundhara-v.vo...@broadcom.com wrote:
On Tue, Jun 30, 2020 at 6:23 PM Jiri Pirko <j...@resnulli.us> wrote:
Tue, Jun 30, 2020 at 01:34:06PM CEST, vasundhara-v.vo...@broadcom.com wrote:
Advanced NICs support live reset of some of the hardware
components, that resets the device immediately with all the
host drivers loaded.
Add devlink reset subcommand to support live and deferred modes
of reset. It allows to reset the hardware components of the
entire device and supports the following fields:
component:
----------
1. MGMT : Management processor.
2. DMA : DMA engine.
3. RAM : RAM shared between multiple components.
4. AP : Application processor.
5. ROCE : RoCE management processor.
6. All : All possible components.
Drivers are allowed to reset only a subset of requested components.
I don't understand why would user ever want to do this. He does not care
about some magic hw entities. He just expects the hw to work. I don't
undestand the purpose of exposing something like this. Could you please
explain in details? Thanks!
If a user requests multiple components and if the driver is only able
to honor a subset, the driver will return the components unset which
it is able to reset. For example, if a user requests MGMT, RAM and
ROCE components to be reset and driver resets only MGMT and ROCE.
Driver will unset only MGMT and ROCE bits and notifies the user that
RAM is not reset.
This will be useful for drivers to reset only a subset of components
requested instead of returning error or silently doing only a subset
of components.
Also, this will be helpful as user will not know the components
supported by different vendors.
Your reply does not seem to be related to my question :/
I thought that you were referring to: "Drivers are allowed to reset
only a subset of requested components."
or were you referring to components? If yes, the user can select the
components that he wants to go for reset. This will be useful in the
case where, if the user flashed only a certain component and he wants
to reset that particular component. For example, in the case of SOC
there are 2 components: MGMT and AP. If a user flashes only
application processor, he can choose to reset only application
processor.
We already have notion of "a component" in "devlink dev flash". I think
that the reset component name should be in-sync with the flash.
Thinking about it a bit more, we can extend the flash command by "reset"
attribute that would indicate use wants to do flash&reset right away.
Also, thinking how this all aligns with "devlink dev reload" which we
currently have. The purpose of it is to re-instantiate driver instances,
but in case of mlxsw it means friggering FW reset as well.
Moshe (cced) is now working on "devlink dev reload" extension that would
allow user to ask for a certain level of reload: driver instances only,
fw reset too, live fw patching, etc.
Not sure how this overlaps with your intentions. I think it would be
great to see Moshe's RFC here as well so we can aligh the efforts.
Are the patches posted yet?
I don't think so.
Moshe?
Not yet, still in internal review.
If won't pass by EOW I will send part of it as RFC.
