[PATCH v3] NVMe: Add controller state for scheduling resets

[Guilherme G. Piccoli]

On 05/31/2016 08:05 PM, Keith Busch wrote:
> On Tue, May 31, 2016 at 07:24:48PM -0300, Guilherme G. Piccoli wrote:
>> But imagine a scenario I have multiple nvme devices and want to upgrade the
>> firmware for only one. In this case, the procedure is to reset_controller
>> only the specific device after the fw activation.
>> modprobe the driver in this case it too much.
>
> I agree module reload would be heavy handed in your scenario, but just
> trying to establish what conditions you really need the quirk to work.

Only in reset_controller after a firmware activation. The quirk 
implementation was delaying all reset_controller calls though.


>> Now, the quirk needs 2 sec delay, not so big, but not so small value either.
>> Would be _desirable_ to have such distinguishing, although we can live
>> without it I guess.
>
> The module is typically only loaded once on boot. The driver probes all
> controllers in a background task, so it shouldn't be blocking anything
> that doesn't need to run IO to the drive. Is the added 2 seconds there
> really harming the experience?

Heheh, not that harmful.


>> But since you just sent the patch unifying the resets, I thought worth
>> asking you if it's possible to include some kind of differentiation, or if
>> such feature already exists (and I wasn't able to find heheh)
>
> You can know if the controller was initialized once before if it has an
> allocated admin tag set.

Thanks very much for the good hint, I might use this or leave the delay 
in every reset, since 2 sec is not that much.

Thanks for the the quick responses,



Guilherme