Tue, Aug 04, 2020 at 10:39:46PM CEST, k...@kernel.org wrote: >On Tue, 4 Aug 2020 12:04:18 +0200 Jiri Pirko wrote: >> Mon, Aug 03, 2020 at 10:57:03PM CEST, k...@kernel.org wrote: >> >I was trying to avoid having to provide a Cartesian product of >> >operation and system disruption level, if any other action can >> >be done "live" at some point. >> > >> >But no strong feelings about that one. >> > >> >Really, as long as there is no driver-specific defaults (or as >> >little driver-specific anything as possible) and user actions >> >are clearly expressed (fw-reset does not necessarily imply >> >fw-activation) - the API will be fine IMO. >> >> Clear actions, that is what I'm fine with. >> >> But not sure how you think we can achieve no driver-specific defaults. >> We have them already :/ I don't think we can easily remove them and not >> break user expectations. > >AFAIU the per-driver default is needed because we went too low >level with what the action constitutes. We need maintain the higher >level actions. > >The user clearly did not care if FW was reset during devlink reload >before this set, so what has changed? The objective user has is to
Well for mlxsw, the user is used to this flow: devlink dev flash - flash new fw devlink dev reload - new fw is activated and reset and driver instances are re-created. >activate their config / FW / move to different net ns. > >Reloading the driver or resetting FW is a low level detail which >achieves different things for different implementations. So it's >not a suitable abstraction -> IOW we need the driver default. I'm confused. So you think we need the driver default? > > >The work flow for the user is: > >0. download fw to /lib/firmware >1. devlink flash $dev $fw >2. if live activation is enabled > yes - devlink reload $dev $live-activate > no - report machine has to be drained for reboot > >fw-reset can't be $live-activate, because as Jake said fw-reset does >not activate the new image for Intel. So will we end up per-driver >defaults in the kernel space, and user space maintaining a mapping from Well, that is what what is Moshe's proposal. Per-driver kernel default.. I'm not sure what we are arguing about then :/ >a driver to what a "level" of reset implies. > >I hope this makes things crystal clear. Please explain what problems >you're seeing and extensions you're expecting. A list of user scenarios >you foresee would be v. useful.
