[PATCH v3 2/2] nvme: enable generic interface (/dev/ngXnY) for unknown command sets

[Joel Granados]

On Wed, Jun 22, 2022 at 02:20:05PM -0600, Keith Busch wrote:
> On Wed, Jun 22, 2022 at 03:55:56PM +0200, Joel Granados wrote:
> >  static void nvme_validate_or_alloc_ns(struct nvme_ctrl *ctrl, unsigned nsid)
> >  {
> >  	struct nvme_ns_ids ids = { };
> > -	struct nvme_id_ns_cs_indep *id;
> > +	struct nvme_id_ns_cs_indep *id_indep;
> >  	struct nvme_ns *ns;
> > -	bool ready = true;
> >  
> >  	if (nvme_identify_ns_descs(ctrl, nsid, &ids))
> >  		return;
> >  
> > +	if (nvme_identify_ns_cs_indep(ctrl, nsid, &id_indep))
> > +		return;
> > +
> 
> There's no check that the command-set-independent namespace identification is
> supported, so an error should be expected for many controllers instead of
> abandoning the namespace.
good catch. But is the error really necessary?
If the controller supports NVM or ZNS then we can continue with the
normal (command-set-dependent) namespace identification.

I see two situations:

1. When we are dealing with NVM or ZNS command sets:
1.1 Should bring up a block device regardless of supporting command-set-
    independent namespace identification
1.2 Time-to-ready will be used only if command-set-independent is
    supported

2. When we are dealing with something that is not NVM nor ZNS:
2.1 Should bring up a char device iff the command-set-independent
    namespace identification is supported.
2.2 Should abandon the namespace with a dev_warn if the
    command-set-independent namespace identification is not supported.

Am I missing something?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20220623/fa4a6ae6/attachment.sig>