Hi, > On 16 Apr 2015, at 16:55, Keith Busch <keith.busch@xxxxxxxxx> wrote: > > 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 > > 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. > >> @@ -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. > > 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. Would you be ok with having nvme-lightnvm for LightNVM specific commands? Javier.
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
