All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Martin Belanger <nitram_67@hotmail.com>,
	linux-nvme@lists.infradead.org, kbusch@kernel.org, hare@suse.de,
	axboe@fb.com, hch@lst.de, rafael@kernel.org,
	charles_rose@dell.com, stuart_hayes@dell.com,
	Martin Belanger <martin.belanger@dell.com>
Subject: Re: [PATCHv2 3/3] nvme: Expose cntrltype and dctype through sysfs
Date: Sun, 6 Feb 2022 13:00:58 +0100	[thread overview]
Message-ID: <Yf+4enHefqPXQx5t@kroah.com> (raw)
In-Reply-To: <93a3faf5-2e97-cd27-63ae-ea37293d5e54@grimberg.me>

On Sun, Feb 06, 2022 at 10:54:54AM +0200, Sagi Grimberg wrote:
> Hey Greg,
> 
> > > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> > > index b5e452aa3c0e..4e3db5ec3924 100644
> > > --- a/drivers/nvme/host/core.c
> > > +++ b/drivers/nvme/host/core.c
> > > @@ -2990,6 +2990,9 @@ static int nvme_init_identify(struct nvme_ctrl *ctrl)
> > >   	ctrl->max_namespaces = le32_to_cpu(id->mnan);
> > >   	ctrl->ctratt = le32_to_cpu(id->ctratt);
> > > +	ctrl->cntrltype = id->cntrltype;
> > > +	ctrl->dctype = id->dctype;
> > > +
> > >   	if (id->rtd3e) {
> > >   		/* us -> s */
> > >   		u32 transition_time = le32_to_cpu(id->rtd3e) / USEC_PER_SEC;
> > > @@ -3115,6 +3118,10 @@ int nvme_init_ctrl_finish(struct nvme_ctrl *ctrl)
> > >   			return ret;
> > >   	}
> > > +	ret = device_update_groups(ctrl->device);
> > > +	if (ret)
> > > +		return ret;
> > 
> > Why is this needed here?  How did the class or type just change?  That
> > should never change over the lifespan of a device.  If it does, you need
> > to tear down the old device and create a new one as something really
> > wrong just happened.
> 
> The class and type do not change. The fundamental need here is to update
> visible attributes of the device.

Then change the attributes and issue a uevent of KOBJECT_CHANGE like
other objects do today.  But be aware that userspace might have problems
with this.  Please test your tools to verify this works or not.

> In nvme, we create the device node with its sysfs attributes and next
> comes a process where we interrogate it for capabilities/personality.

That feels wrong, just delay, there's no rush.

> In this example, the attributes cntrltype and dctype are learned from
> the device identification, and the desire is that dctype will only be
> visible for specific cntrltype (i.e. cntrltype is I/O controllers vs.
> discovery controllers and dctype is the discovery controller type).
> 
> So perhaps a more narrowed interface to update attributes
> visibility of the controller would be more appropriate instead?
> 
> Something like:
> --
> 	ret = device_update_visibility(ctrl->device->groups);
> --

Again, suffers from the same issue where userspace is not notified.

Again, just delay and create the real object when you know what you
have.

thanks,

greg k-h


  reply	other threads:[~2022-02-06 12:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220203211748.27542-1-nitram_67@hotmail.com>
2022-02-03 21:17 ` [PATCHv2 1/3] nvme: send uevent on connection up Martin Belanger
2022-02-03 21:17 ` [PATCHv2 2/3] nvme: Add device_update_groups() Martin Belanger
2022-02-04  2:22   ` Chaitanya Kulkarni
2022-02-04  7:04   ` driver core patch, was " Christoph Hellwig
2022-02-04  7:45     ` Greg KH
2022-02-04  7:31   ` Hannes Reinecke
2022-02-04  7:42   ` Greg KH
2022-02-03 21:17 ` [PATCHv2 3/3] nvme: Expose cntrltype and dctype through sysfs Martin Belanger
2022-02-04  7:32   ` Hannes Reinecke
2022-02-04  7:43   ` Greg KH
2022-02-04  7:45   ` Greg KH
2022-02-04 13:51     ` Belanger, Martin
2022-02-04 14:05       ` Greg KH
2022-02-06  9:09         ` Sagi Grimberg
2022-02-06 12:02           ` Greg KH
2022-02-06 15:55             ` Sagi Grimberg
2022-02-06  8:54     ` Sagi Grimberg
2022-02-06 12:00       ` Greg KH [this message]
2022-02-06 13:08       ` Hannes Reinecke
2022-02-06 13:15         ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yf+4enHefqPXQx5t@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=axboe@fb.com \
    --cc=charles_rose@dell.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=martin.belanger@dell.com \
    --cc=nitram_67@hotmail.com \
    --cc=rafael@kernel.org \
    --cc=sagi@grimberg.me \
    --cc=stuart_hayes@dell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.