All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Matias Bjørling" <mb@lightnvm.io>
To: Javier Gonzalez <javier@cnexlabs.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: [PATCH 03/20] lightnvm: fix capabilities for 2.0 sysfs
Date: Thu, 22 Feb 2018 12:10:55 +0100	[thread overview]
Message-ID: <e4ac9c84-3dd5-41e3-8190-905d2a7f5d5d@lightnvm.io> (raw)
In-Reply-To: <A949EA48-27DF-4370-B213-3A4CE4E4F7D1@cnexlabs.com>

On 02/22/2018 11:25 AM, Javier Gonzalez wrote:
> 
> 
>> On 22 Feb 2018, at 10.39, Matias Bjørling <mb@lightnvm.io> wrote:
>>
>> On 02/22/2018 08:47 AM, Javier Gonzalez wrote:
>>>> On 22 Feb 2018, at 08.28, Matias Bjørling <mb@lightnvm.io> wrote:
>>>>
>>>>> On 02/21/2018 10:26 AM, Javier González wrote:
>>>>> Both 1.2 and 2.0 specs define a field for media and controller
>>>>> capabilities. Also, 1.2 defines a separate field dedicated to device
>>>>> capabilities.
>>>>> In 2.0 sysfs, this values have been mixed. Revert them to the right
>>>>> value.
>>>>> Signed-off-by: Javier González <javier@cnexlabs.com>
>>>>> ---
>>>>>   drivers/nvme/host/lightnvm.c | 18 +++++++++---------
>>>>>   1 file changed, 9 insertions(+), 9 deletions(-)
>>>>> diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
>>>>> index 969bb874850c..598abba66f52 100644
>>>>> --- a/drivers/nvme/host/lightnvm.c
>>>>> +++ b/drivers/nvme/host/lightnvm.c
>>>>> @@ -914,8 +914,8 @@ static ssize_t nvm_dev_attr_show(struct device *dev,
>>>>>         if (strcmp(attr->name, "version") == 0) {
>>>>>           return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->ver_id);
>>>>> -    } else if (strcmp(attr->name, "capabilities") == 0) {
>>>>> -        return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.cap);
>>>>> +    } else if (strcmp(attr->name, "media_capabilities") == 0) {
>>>>> +        return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.mccap);
>>>>>       } else if (strcmp(attr->name, "read_typ") == 0) {
>>>>>           return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.trdt);
>>>>>       } else if (strcmp(attr->name, "read_max") == 0) {
>>>>> @@ -993,8 +993,8 @@ static ssize_t nvm_dev_attr_show_12(struct device *dev,
>>>>>           return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.tbem);
>>>>>       } else if (strcmp(attr->name, "multiplane_modes") == 0) {
>>>>>           return scnprintf(page, PAGE_SIZE, "0x%08x\n", dev_geo->c.mpos);
>>>>> -    } else if (strcmp(attr->name, "media_capabilities") == 0) {
>>>>> -        return scnprintf(page, PAGE_SIZE, "0x%08x\n", dev_geo->c.mccap);
>>>>> +    } else if (strcmp(attr->name, "capabilities") == 0) {
>>>>> +        return scnprintf(page, PAGE_SIZE, "0x%08x\n", dev_geo->c.cap);
>>>>>       } else if (strcmp(attr->name, "max_phys_secs") == 0) {
>>>>>           return scnprintf(page, PAGE_SIZE, "%u\n", NVM_MAX_VLBA);
>>>>>       } else {
>>>>> @@ -1055,7 +1055,7 @@ static ssize_t nvm_dev_attr_show_20(struct device *dev,
>>>>>     /* general attributes */
>>>>>   static NVM_DEV_ATTR_RO(version);
>>>>> -static NVM_DEV_ATTR_RO(capabilities);
>>>>> +static NVM_DEV_ATTR_RO(media_capabilities);
>>>>>     static NVM_DEV_ATTR_RO(read_typ);
>>>>>   static NVM_DEV_ATTR_RO(read_max);
>>>>> @@ -1080,12 +1080,12 @@ static NVM_DEV_ATTR_12_RO(prog_max);
>>>>>   static NVM_DEV_ATTR_12_RO(erase_typ);
>>>>>   static NVM_DEV_ATTR_12_RO(erase_max);
>>>>>   static NVM_DEV_ATTR_12_RO(multiplane_modes);
>>>>> -static NVM_DEV_ATTR_12_RO(media_capabilities);
>>>>> +static NVM_DEV_ATTR_12_RO(capabilities);
>>>>>   static NVM_DEV_ATTR_12_RO(max_phys_secs);
>>>>>     static struct attribute *nvm_dev_attrs_12[] = {
>>>>>       &dev_attr_version.attr,
>>>>> -    &dev_attr_capabilities.attr,
>>>>> +    &dev_attr_media_capabilities.attr,
>>>>>         &dev_attr_vendor_opcode.attr,
>>>>>       &dev_attr_device_mode.attr,
>>>>> @@ -1108,7 +1108,7 @@ static struct attribute *nvm_dev_attrs_12[] = {
>>>>>       &dev_attr_erase_typ.attr,
>>>>>       &dev_attr_erase_max.attr,
>>>>>       &dev_attr_multiplane_modes.attr,
>>>>> -    &dev_attr_media_capabilities.attr,
>>>>> +    &dev_attr_capabilities.attr,
>>>>>       &dev_attr_max_phys_secs.attr,
>>>>>         NULL,
>>>>> @@ -1134,7 +1134,7 @@ static NVM_DEV_ATTR_20_RO(reset_max);
>>>>>     static struct attribute *nvm_dev_attrs_20[] = {
>>>>>       &dev_attr_version.attr,
>>>>> -    &dev_attr_capabilities.attr,
>>>>> +    &dev_attr_media_capabilities.attr,
>>>>>         &dev_attr_groups.attr,
>>>>>       &dev_attr_punits.attr,
>>>>
>>>> With the mccap changes, it should make sense to keep the capabilities
>>>> as is.
>>> The change adds mccap, but sysfs points to cap, which is wrong. This
>>> patch is needed. Otherwise, we change the name of mccap to cap, which
>>> is _very_ confusing to people familiar to both specs. We can change
>>> the name of mccap to cap in a future spec revision.
>>> Javier
>>
>> Think of the sysfs capabilities as an abstract value that defines generic capabilities. It is not directly tied to either 1.2 or 2.0.
> 
> I’m thinking about the user looking at sysfs and at the spec at the same time - I myself get confused when names don’t match.
> 
> Anyway, I’ll keep it the way it was and add a comment for clarification. Would that work for you?
> 

That works. One may also wait until it is going to be used, e.g., when 
vector copy is implemented. Then it's natural to revisit.

WARNING: multiple messages have this Message-ID (diff)
From: mb@lightnvm.io (Matias Bjørling)
Subject: [PATCH 03/20] lightnvm: fix capabilities for 2.0 sysfs
Date: Thu, 22 Feb 2018 12:10:55 +0100	[thread overview]
Message-ID: <e4ac9c84-3dd5-41e3-8190-905d2a7f5d5d@lightnvm.io> (raw)
In-Reply-To: <A949EA48-27DF-4370-B213-3A4CE4E4F7D1@cnexlabs.com>

On 02/22/2018 11:25 AM, Javier Gonzalez wrote:
> 
> 
>> On 22 Feb 2018,@10.39, Matias Bj?rling <mb@lightnvm.io> wrote:
>>
>> On 02/22/2018 08:47 AM, Javier Gonzalez wrote:
>>>> On 22 Feb 2018,@08.28, Matias Bj?rling <mb@lightnvm.io> wrote:
>>>>
>>>>> On 02/21/2018 10:26 AM, Javier Gonz?lez wrote:
>>>>> Both 1.2 and 2.0 specs define a field for media and controller
>>>>> capabilities. Also, 1.2 defines a separate field dedicated to device
>>>>> capabilities.
>>>>> In 2.0 sysfs, this values have been mixed. Revert them to the right
>>>>> value.
>>>>> Signed-off-by: Javier Gonz?lez <javier at cnexlabs.com>
>>>>> ---
>>>>>   drivers/nvme/host/lightnvm.c | 18 +++++++++---------
>>>>>   1 file changed, 9 insertions(+), 9 deletions(-)
>>>>> diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
>>>>> index 969bb874850c..598abba66f52 100644
>>>>> --- a/drivers/nvme/host/lightnvm.c
>>>>> +++ b/drivers/nvme/host/lightnvm.c
>>>>> @@ -914,8 +914,8 @@ static ssize_t nvm_dev_attr_show(struct device *dev,
>>>>>         if (strcmp(attr->name, "version") == 0) {
>>>>>           return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->ver_id);
>>>>> -    } else if (strcmp(attr->name, "capabilities") == 0) {
>>>>> -        return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.cap);
>>>>> +    } else if (strcmp(attr->name, "media_capabilities") == 0) {
>>>>> +        return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.mccap);
>>>>>       } else if (strcmp(attr->name, "read_typ") == 0) {
>>>>>           return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.trdt);
>>>>>       } else if (strcmp(attr->name, "read_max") == 0) {
>>>>> @@ -993,8 +993,8 @@ static ssize_t nvm_dev_attr_show_12(struct device *dev,
>>>>>           return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.tbem);
>>>>>       } else if (strcmp(attr->name, "multiplane_modes") == 0) {
>>>>>           return scnprintf(page, PAGE_SIZE, "0x%08x\n", dev_geo->c.mpos);
>>>>> -    } else if (strcmp(attr->name, "media_capabilities") == 0) {
>>>>> -        return scnprintf(page, PAGE_SIZE, "0x%08x\n", dev_geo->c.mccap);
>>>>> +    } else if (strcmp(attr->name, "capabilities") == 0) {
>>>>> +        return scnprintf(page, PAGE_SIZE, "0x%08x\n", dev_geo->c.cap);
>>>>>       } else if (strcmp(attr->name, "max_phys_secs") == 0) {
>>>>>           return scnprintf(page, PAGE_SIZE, "%u\n", NVM_MAX_VLBA);
>>>>>       } else {
>>>>> @@ -1055,7 +1055,7 @@ static ssize_t nvm_dev_attr_show_20(struct device *dev,
>>>>>     /* general attributes */
>>>>>   static NVM_DEV_ATTR_RO(version);
>>>>> -static NVM_DEV_ATTR_RO(capabilities);
>>>>> +static NVM_DEV_ATTR_RO(media_capabilities);
>>>>>     static NVM_DEV_ATTR_RO(read_typ);
>>>>>   static NVM_DEV_ATTR_RO(read_max);
>>>>> @@ -1080,12 +1080,12 @@ static NVM_DEV_ATTR_12_RO(prog_max);
>>>>>   static NVM_DEV_ATTR_12_RO(erase_typ);
>>>>>   static NVM_DEV_ATTR_12_RO(erase_max);
>>>>>   static NVM_DEV_ATTR_12_RO(multiplane_modes);
>>>>> -static NVM_DEV_ATTR_12_RO(media_capabilities);
>>>>> +static NVM_DEV_ATTR_12_RO(capabilities);
>>>>>   static NVM_DEV_ATTR_12_RO(max_phys_secs);
>>>>>     static struct attribute *nvm_dev_attrs_12[] = {
>>>>>       &dev_attr_version.attr,
>>>>> -    &dev_attr_capabilities.attr,
>>>>> +    &dev_attr_media_capabilities.attr,
>>>>>         &dev_attr_vendor_opcode.attr,
>>>>>       &dev_attr_device_mode.attr,
>>>>> @@ -1108,7 +1108,7 @@ static struct attribute *nvm_dev_attrs_12[] = {
>>>>>       &dev_attr_erase_typ.attr,
>>>>>       &dev_attr_erase_max.attr,
>>>>>       &dev_attr_multiplane_modes.attr,
>>>>> -    &dev_attr_media_capabilities.attr,
>>>>> +    &dev_attr_capabilities.attr,
>>>>>       &dev_attr_max_phys_secs.attr,
>>>>>         NULL,
>>>>> @@ -1134,7 +1134,7 @@ static NVM_DEV_ATTR_20_RO(reset_max);
>>>>>     static struct attribute *nvm_dev_attrs_20[] = {
>>>>>       &dev_attr_version.attr,
>>>>> -    &dev_attr_capabilities.attr,
>>>>> +    &dev_attr_media_capabilities.attr,
>>>>>         &dev_attr_groups.attr,
>>>>>       &dev_attr_punits.attr,
>>>>
>>>> With the mccap changes, it should make sense to keep the capabilities
>>>> as is.
>>> The change adds mccap, but sysfs points to cap, which is wrong. This
>>> patch is needed. Otherwise, we change the name of mccap to cap, which
>>> is _very_ confusing to people familiar to both specs. We can change
>>> the name of mccap to cap in a future spec revision.
>>> Javier
>>
>> Think of the sysfs capabilities as an abstract value that defines generic capabilities. It is not directly tied to either 1.2 or 2.0.
> 
> I?m thinking about the user looking at sysfs and at the spec at the same time - I myself get confused when names don?t match.
> 
> Anyway, I?ll keep it the way it was and add a comment for clarification. Would that work for you?
> 

That works. One may also wait until it is going to be used, e.g., when 
vector copy is implemented. Then it's natural to revisit.

  reply	other threads:[~2018-02-22 11:10 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-21  9:26 [PATCH V2 00/20] lightnvm: pblk: implement 2.0 support Javier González
2018-02-21  9:26 ` Javier González
2018-02-21  9:26 ` [PATCH 01/20] lightnvm: simplify geometry structure Javier González
2018-02-21  9:26   ` Javier González
2018-02-22  7:25   ` Matias Bjørling
2018-02-22  7:25     ` Matias Bjørling
2018-02-22  7:44     ` Javier Gonzalez
2018-02-22  7:44       ` Javier Gonzalez
2018-02-22 12:22       ` Matias Bjørling
2018-02-22 12:22         ` Matias Bjørling
2018-02-22 14:13         ` Javier Gonzalez
2018-02-22 14:13           ` Javier Gonzalez
2018-02-21  9:26 ` [PATCH 02/20] lightnvm: add controller capabilities to 2.0 Javier González
2018-02-21  9:26   ` Javier González
2018-02-22  7:26   ` Matias Bjørling
2018-02-22  7:26     ` Matias Bjørling
2018-02-21  9:26 ` [PATCH 03/20] lightnvm: fix capabilities for 2.0 sysfs Javier González
2018-02-21  9:26   ` Javier González
2018-02-22  7:28   ` Matias Bjørling
2018-02-22  7:28     ` Matias Bjørling
2018-02-22  7:47     ` Javier Gonzalez
2018-02-22  7:47       ` Javier Gonzalez
2018-02-22  9:39       ` Matias Bjørling
2018-02-22  9:39         ` Matias Bjørling
2018-02-22 10:25         ` Javier Gonzalez
2018-02-22 10:25           ` Javier Gonzalez
2018-02-22 10:25           ` Javier Gonzalez
2018-02-22 11:10           ` Matias Bjørling [this message]
2018-02-22 11:10             ` Matias Bjørling
2018-02-22 11:12             ` Javier Gonzalez
2018-02-22 11:12               ` Javier Gonzalez
2018-02-21  9:26 ` [PATCH 04/20] lightnvm: add minor version to generic geometry Javier González
2018-02-21  9:26   ` Javier González
2018-02-22  7:34   ` Matias Bjørling
2018-02-22  7:34     ` Matias Bjørling
2018-02-22  7:53     ` Javier González
2018-02-22  7:53       ` Javier González
2018-02-21  9:26 ` [PATCH 05/20] lightnvm: rename number of channels and luns Javier González
2018-02-21  9:26   ` Javier González
2018-02-21  9:26 ` [PATCH 06/20] lightnvm: add shorten OCSSD version in geo Javier González
2018-02-21  9:26   ` Javier González
2018-02-21  9:26 ` [PATCH 07/20] lightnvm: rename sect_* to sec_* Javier González
2018-02-21  9:26   ` Javier González
2018-02-22  7:43   ` Matias Bjørling
2018-02-22  7:43     ` Matias Bjørling
2018-02-21  9:26 ` [PATCH 08/20] lightnvm: complete geo structure with maxoc* Javier González
2018-02-21  9:26   ` Javier González
2018-02-22  7:45   ` Matias Bjørling
2018-02-22  7:45     ` Matias Bjørling
2018-02-22  7:55     ` Javier Gonzalez
2018-02-22  7:55       ` Javier Gonzalez
2018-02-22  9:45       ` Matias Bjørling
2018-02-22  9:45         ` Matias Bjørling
2018-02-22  9:52         ` Javier Gonzalez
2018-02-22  9:52           ` Javier Gonzalez
2018-02-22 10:00           ` Matias Bjørling
2018-02-22 10:00             ` Matias Bjørling
2018-02-22 10:03             ` Javier Gonzalez
2018-02-22 10:03               ` Javier Gonzalez
2018-02-21  9:26 ` [PATCH 09/20] lightnvm: use generic identify structure Javier González
2018-02-21  9:26   ` Javier González
2018-02-22  7:47   ` Matias Bjørling
2018-02-22  7:47     ` Matias Bjørling
2018-02-22  7:49     ` Javier González
2018-02-22  7:49       ` Javier González
2018-02-22  9:41       ` Matias Bjørling
2018-02-22  9:41         ` Matias Bjørling
2018-02-21  9:26 ` [PATCH 10/20] lightnvm: pblk: rename ppaf* to addrf* Javier González
2018-02-21  9:26   ` Javier González
2018-02-21  9:26   ` Javier González
2018-02-22  7:47   ` Matias Bjørling
2018-02-22  7:47     ` Matias Bjørling
2018-02-22  7:47     ` Matias Bjørling
2018-02-21  9:26 ` [PATCH 11/20] lightnvm: pblk: check for supported version Javier González
2018-02-21  9:26   ` Javier González
2018-02-22  7:48   ` Matias Bjørling
2018-02-22  7:48     ` Matias Bjørling
2018-02-21  9:26 ` [PATCH 12/20] lightnvm: complete 2.0 values in sysfs Javier González
2018-02-21  9:26   ` Javier González
2018-02-21  9:26 ` [PATCH 13/20] lightnvm: add support for 2.0 address format Javier González
2018-02-21  9:26   ` Javier González
2018-02-22  9:24   ` Matias Bjørling
2018-02-22  9:24     ` Matias Bjørling
2018-02-21  9:26 ` [PATCH 14/20] lightnvm: make address conversions depend on generic device Javier González
2018-02-21  9:26   ` Javier González
2018-02-21  9:26 ` [PATCH 15/20] nvme: make nvme_get_log_ext available Javier González
2018-02-21  9:26   ` Javier González
2018-02-21  9:26 ` [PATCH 16/20] lightnvm: implement get log report chunk helpers Javier González
2018-02-21  9:26   ` Javier González
2018-02-21  9:26 ` [PATCH 17/20] lightnvm: define chunk states Javier González
2018-02-21  9:26   ` Javier González
2018-02-21  9:26 ` [PATCH 18/20] lightnvm: pblk: implement get log report chunk Javier González
2018-02-21  9:26   ` Javier González
2018-02-21  9:26 ` [PATCH 19/20] lightnvm: pblk: refactor init/exit sequences Javier González
2018-02-21  9:26   ` Javier González
2018-02-21  9:26 ` [PATCH 20/20] lightnvm: pblk: implement 2.0 support Javier González
2018-02-21  9:26   ` Javier González
2018-02-21 14:30   ` Javier González
2018-02-21 14:30     ` Javier González

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=e4ac9c84-3dd5-41e3-8190-905d2a7f5d5d@lightnvm.io \
    --to=mb@lightnvm.io \
    --cc=javier@cnexlabs.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    /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.