From: "Matias Bjørling" <mb@lightnvm.io>
To: "Javier González" <jg@lightnvm.io>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH 09/20] lightnvm: use generic identify structure
Date: Thu, 22 Feb 2018 10:41:35 +0100 [thread overview]
Message-ID: <25780a53-504e-70c6-3ff4-d20c43e8e3b2@lightnvm.io> (raw)
In-Reply-To: <1FE350B9-E8CD-43BC-8AE8-2593A6398D3F@lightnvm.io>
On 02/22/2018 08:49 AM, Javier González wrote:
>> On 22 Feb 2018, at 08.47, Matias Bjørling <mb@lightnvm.io> wrote:
>>
>> On 02/21/2018 10:26 AM, Javier González wrote:
>>> Create a generic identify structure to collect the identify information
>>> before knowing the spec. version. This forces different version paths to
>>> cast the structure to their spec structure, thus making the code less
>>> error prone and more maintainable.
>>> Signed-off-by: Javier González <javier@cnexlabs.com>
>>> ---
>>> drivers/nvme/host/lightnvm.c | 32 ++++++++++++++++++++------------
>>> 1 file changed, 20 insertions(+), 12 deletions(-)
>>> diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
>>> index 9c1f8225c4e1..70dc4740f0d3 100644
>>> --- a/drivers/nvme/host/lightnvm.c
>>> +++ b/drivers/nvme/host/lightnvm.c
>>> @@ -170,6 +170,12 @@ struct nvme_nvm_id12 {
>>> __u8 resv2[2880];
>>> } __packed;
>>> +/* Generic identification structure */
>>> +struct nvme_nvm_id {
>>> + __u8 ver_id;
>>> + __u8 resv[4095];
>>> +} __packed;
>>> +
>>> struct nvme_nvm_bb_tbl {
>>> __u8 tblid[4];
>>> __le16 verid;
>>> @@ -279,9 +285,10 @@ static void nvme_nvm_set_addr_12(struct nvm_addr_format_12 *dst,
>>> dst->sec_mask = ((1ULL << dst->sec_len) - 1) << dst->sec_offset;
>>> }
>>> -static int nvme_nvm_setup_12(struct nvme_nvm_id12 *id,
>>> +static int nvme_nvm_setup_12(struct nvme_nvm_id *gen_id,
>>> struct nvm_dev_geo *dev_geo)
>>> {
>>> + struct nvme_nvm_id12 *id = (struct nvme_nvm_id12 *)gen_id;
>>> struct nvme_nvm_id12_grp *src;
>>> int sec_per_pg, sec_per_pl, pg_per_blk;
>>> @@ -380,9 +387,11 @@ static void nvme_nvm_set_addr_20(struct nvm_addr_format *dst,
>>> dst->sec_mask = ((1ULL << dst->sec_len) - 1) << dst->sec_offset;
>>> }
>>> -static int nvme_nvm_setup_20(struct nvme_nvm_id20 *id,
>>> +static int nvme_nvm_setup_20(struct nvme_nvm_id *gen_id,
>>> struct nvm_dev_geo *dev_geo)
>>> {
>>> + struct nvme_nvm_id20 *id = (struct nvme_nvm_id20 *)gen_id;
>>> +
>>> dev_geo->major_ver_id = id->mjr;
>>> dev_geo->minor_ver_id = id->mnr;
>>> @@ -427,19 +436,19 @@ static int nvme_nvm_setup_20(struct nvme_nvm_id20 *id,
>>> static int nvme_nvm_identity(struct nvm_dev *nvmdev)
>>> {
>>> struct nvme_ns *ns = nvmdev->q->queuedata;
>>> - struct nvme_nvm_id12 *id;
>>> + struct nvme_nvm_id *nvme_nvm_id;
>>> struct nvme_nvm_command c = {};
>>> int ret;
>>> c.identity.opcode = nvme_nvm_admin_identity;
>>> c.identity.nsid = cpu_to_le32(ns->head->ns_id);
>>> - id = kmalloc(sizeof(struct nvme_nvm_id12), GFP_KERNEL);
>>> - if (!id)
>>> + nvme_nvm_id = kmalloc(sizeof(struct nvme_nvm_id), GFP_KERNEL);
>>> + if (!nvme_nvm_id)
>>> return -ENOMEM;
>>> ret = nvme_submit_sync_cmd(ns->ctrl->admin_q, (struct nvme_command *)&c,
>>> - id, sizeof(struct nvme_nvm_id12));
>>> + nvme_nvm_id, sizeof(struct nvme_nvm_id));
>>> if (ret) {
>>> ret = -EIO;
>>> goto out;
>>> @@ -449,22 +458,21 @@ static int nvme_nvm_identity(struct nvm_dev *nvmdev)
>>> * The 1.2 and 2.0 specifications share the first byte in their geometry
>>> * command to make it possible to know what version a device implements.
>>> */
>>> - switch (id->ver_id) {
>>> + switch (nvme_nvm_id->ver_id) {
>>> case 1:
>>> - ret = nvme_nvm_setup_12(id, &nvmdev->dev_geo);
>>> + ret = nvme_nvm_setup_12(nvme_nvm_id, &nvmdev->dev_geo);
>>> break;
>>> case 2:
>>> - ret = nvme_nvm_setup_20((struct nvme_nvm_id20 *)id,
>>> - &nvmdev->dev_geo);
>>> + ret = nvme_nvm_setup_20(nvme_nvm_id, &nvmdev->dev_geo);
>>> break;
>>> default:
>>> dev_err(ns->ctrl->device, "OCSSD revision not supported (%d)\n",
>>> - id->ver_id);
>>> + nvme_nvm_id->ver_id);
>>> ret = -EINVAL;
>>> }
>>> out:
>>> - kfree(id);
>>> + kfree(nvme_nvm_id);
>>> return ret;
>>> }
>>>
>>
>> Thanks for another way to represent it. I want to keep the original
>> path. If we are going that down road, then one should maybe look into
>> unifying the "three" data structures, and have the version as the base
>> property and the others in each their sub data structure.
>
> That's what this structure aims to do, since the version is shared. But
> you call if you want to cast unrelated structures back an forth. I'll
> revert it...
>
> Javier
>
In that case, the patch could look like
struct nvm_id {
__u8 ver_id;
union {
struct v1 {};
struct v2 {};
};
};
I'm good with just having the single cast instead of putting each under
a v1/v2 variable or using nvm_id first, and then goto either v1 or v2.
next prev parent reply other threads:[~2018-02-22 9:41 UTC|newest]
Thread overview: 48+ 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 ` [PATCH 01/20] lightnvm: simplify geometry structure Javier González
2018-02-22 7:25 ` Matias Bjørling
2018-02-22 7:44 ` Javier Gonzalez
2018-02-22 12:22 ` Matias Bjørling
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-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-22 7:28 ` Matias Bjørling
2018-02-22 7:47 ` Javier Gonzalez
2018-02-22 9:39 ` Matias Bjørling
2018-02-22 10:25 ` Javier Gonzalez
2018-02-22 11:10 ` Matias Bjørling
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-22 7:34 ` Matias Bjørling
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 ` [PATCH 06/20] lightnvm: add shorten OCSSD version in geo Javier González
2018-02-21 9:26 ` [PATCH 07/20] lightnvm: rename sect_* to sec_* Javier González
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-22 7:45 ` Matias Bjørling
2018-02-22 7:55 ` Javier Gonzalez
2018-02-22 9:45 ` Matias Bjørling
2018-02-22 9:52 ` Javier Gonzalez
2018-02-22 10:00 ` Matias Bjørling
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-22 7:47 ` Matias Bjørling
2018-02-22 7:49 ` Javier González
2018-02-22 9:41 ` Matias Bjørling [this message]
2018-02-21 9:26 ` [PATCH 10/20] lightnvm: pblk: rename ppaf* to addrf* Javier González
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-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 ` [PATCH 13/20] lightnvm: add support for 2.0 address format Javier González
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 ` [PATCH 15/20] nvme: make nvme_get_log_ext available 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 ` [PATCH 17/20] lightnvm: define chunk states 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 ` [PATCH 19/20] lightnvm: pblk: refactor init/exit sequences Javier González
2018-02-21 9:26 ` [PATCH 20/20] lightnvm: pblk: implement 2.0 support 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=25780a53-504e-70c6-3ff4-d20c43e8e3b2@lightnvm.io \
--to=mb@lightnvm.io \
--cc=jg@lightnvm.io \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®