Den 16-04-2015 kl. 16:55 skrev Keith Busch:
On Wed, 15 Apr 2015, Matias Bjørling wrote:@@ -2316,7 +2686,9 @@ static int nvme_dev_add(struct nvme_dev *dev) struct nvme_id_ctrl *ctrl; void *mem; dma_addr_t dma_addr; - int shift = NVME_CAP_MPSMIN(readq(&dev->bar->cap)) + 12; + u64 cap = readq(&dev->bar->cap); + int shift = NVME_CAP_MPSMIN(cap) + 12; + int nvm_cmdset = NVME_CAP_NVM(cap);The controller capabilities' command sets supported used here is the right way to key off on support for this new command set, IMHO, but I do not see in this patch the command set being selected when the controller is enabled
I'll get that added. Wouldn't it just be that the command set always is selected? A NVMe controller can expose both normal and lightnvm namespaces. So we would always enable it, if CAP bit is set.
Also if we're going this route, I think we need to define this reserved bit in the spec, but I'm not sure how to help with that.
Agree, we'll see how it can be proposed.
@@ -2332,6 +2704,7 @@ static int nvme_dev_add(struct nvme_dev *dev) ctrl = mem; nn = le32_to_cpup(&ctrl->nn); dev->oncs = le16_to_cpup(&ctrl->oncs); + dev->oacs = le16_to_cpup(&ctrl->oacs);I don't find OACS used anywhere in the rest of the patch. I think this must be left over from v1.
Oops, yes, that's just a left over.
Otherwise it looks pretty good to me, but I think it would be cleaner if the lightnvm stuff is not mixed in the same file with the standard nvme command set. We might end up splitting nvme-core in the future anyway for command sets and transports.
Will do. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
