[PATCH] nvme: do not reset controllers in NVME_CTRL_NEW state

[Keith Busch]

On Tue, Sep 15, 2026 at 04:49:31PM +0200, Daniel Wagner wrote:
> On Tue, Sep 15, 2026 at 03:49:36PM +0200, Maurizio Lombardi wrote:
> > "
> >  Fix this by removing NVME_CTRL_NEW from the allowed prior states for
> >  the NVME_CTRL_RESETTING transition. It is safe to drop this transition
> >  entirely because a controller in the NVME_CTRL_NEW state is merely
> >  allocated and not yet initialized, a reset operation at this stage is
> >  meaningless.
> > "
> > 
> > For what concernes the "why it was there in the first place" question,
> > I think that the reason is that in ancient times a CONNECTING state
> > didn't exist. The controller initialization was done via a reset;
> > so the transition was NEW -> RESETTING -> LIVE.
> 
> This rings a bell. With the introduction of the fabrics drivers, the
> CONNECTING state was introduced and the PCI driver didn't use the
> CONNECTING state for while. But due to various reasons, the PCI
> transport follows the same state transitions as the fabrics ones now.

Yep, nvme pci used to always kick most of the initialization to the
reset_work, so that transport wanted the NEW->RESETTING transition.
With asynchronous probe support added, we do the initial setup without
reset_work.