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?
