Tue, Jun 23, 2020 at 01:32:49PM 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. IRA : Interrupt requester. >3. DMA : DMA engine. >4. FILTER : Filtering/flow direction. >5. OFFLOAD : Protocol offload. >6. MAC : Media access controller. >7. PHY : Transceiver/PHY.
Hmm. I think that you are mixing things which are per-ASIC and per-port. It is confusing. Why do you need this kind of reset granularity? I mean, if something goes wrong in fw/hw, the health reporter should report it and recover it. This looks like you try to add another interface for the same set of problem... >8. RAM : RAM shared between multiple components. >9. ROCE : RoCE management processor. >10. AP : Application processor. >11. All : All possible components. > >Drivers are allowed to reset only a subset of requested components. > >width: >------ >1. single - Single function. >2. multi - Multiple functions. > >mode: >----- >1. deferred - Reset will happen after unloading all the host drivers > on the device. This is be default reset type, if user > does not specify the type. >2. live - Reset will happen immediately with all host drivers loaded > in real time. If the live reset is not supported, driver > will return the error. > >This patch is a proposal in continuation to discussion to the >following thread: > >"[PATCH v3 net-next 0/6] bnxt_en: Add 'enable_live_dev_reset' and >'allow_live_dev_reset' generic devlink params." > >and here is the URL to the patch series: > >https://patchwork.ozlabs.org/project/netdev/list/?series=180426&state=* > >If the proposal looks good, I will re-send the whole patchset >including devlink changes and driver usage. > [...]
