* [PATCH 1/2] hw/block/nvme: align with existing style [not found] <CGME20210317093352epcas5p3193a70101b750934fabcb2540129e499@epcas5p3.samsung.com> @ 2021-03-17 9:30 ` Gollu Appalanaidu [not found] ` <CGME20210317093452epcas5p1be6015c3cec5c7c8a82c779f511d8bd0@epcas5p1.samsung.com> 2021-04-15 6:53 ` [PATCH 1/2] hw/block/nvme: align with existing style Klaus Jensen 0 siblings, 2 replies; 4+ messages in thread From: Gollu Appalanaidu @ 2021-03-17 9:30 UTC (permalink / raw) To: qemu-devel Cc: fam, kwolf, qemu-block, k.jensen, Gollu Appalanaidu, mreitz, its, stefanha, kbusch Make uniform hexadecimal numbers format. Signed-off-by: Gollu Appalanaidu <anaidu.gollu@samsung.com> --- hw/block/nvme.c | 30 +++++++++++++++--------------- include/block/nvme.h | 10 +++++----- 2 files changed, 20 insertions(+), 20 deletions(-) diff --git a/hw/block/nvme.c b/hw/block/nvme.c index d439e44db8..21e85374bf 100644 --- a/hw/block/nvme.c +++ b/hw/block/nvme.c @@ -2728,18 +2728,18 @@ static uint16_t nvme_io_cmd(NvmeCtrl *n, NvmeRequest *req) /* * In the base NVM command set, Flush may apply to all namespaces - * (indicated by NSID being set to 0xFFFFFFFF). But if that feature is used + * (indicated by NSID being set to 0xffffffff). But if that feature is used * along with TP 4056 (Namespace Types), it may be pretty screwed up. * - * If NSID is indeed set to 0xFFFFFFFF, we simply cannot associate the + * If NSID is indeed set to 0xffffffff, we simply cannot associate the * opcode with a specific command since we cannot determine a unique I/O * command set. Opcode 0x0 could have any other meaning than something * equivalent to flushing and say it DOES have completely different - * semantics in some other command set - does an NSID of 0xFFFFFFFF then + * semantics in some other command set - does an NSID of 0xffffffff then * mean "for all namespaces, apply whatever command set specific command * that uses the 0x0 opcode?" Or does it mean "for all namespaces, apply * whatever command that uses the 0x0 opcode if, and only if, it allows - * NSID to be 0xFFFFFFFF"? + * NSID to be 0xffffffff"? * * Anyway (and luckily), for now, we do not care about this since the * device only supports namespace types that includes the NVM Flush command @@ -3948,8 +3948,8 @@ static uint16_t nvme_set_feature(NvmeCtrl *n, NvmeRequest *req) return NVME_INVALID_FIELD | NVME_DNR; } - trace_pci_nvme_setfeat_numq((dw11 & 0xFFFF) + 1, - ((dw11 >> 16) & 0xFFFF) + 1, + trace_pci_nvme_setfeat_numq((dw11 & 0xffff) + 1, + ((dw11 >> 16) & 0xffff) + 1, n->params.max_ioqpairs, n->params.max_ioqpairs); req->cqe.result = cpu_to_le32((n->params.max_ioqpairs - 1) | @@ -4436,7 +4436,7 @@ static void nvme_write_bar(NvmeCtrl *n, hwaddr offset, uint64_t data, } break; case 0x20: /* NSSR */ - if (data == 0x4E564D65) { + if (data == 0x4e564d65) { trace_pci_nvme_ub_mmiowr_ssreset_unsupported(); } else { /* The spec says that writes of other values have no effect */ @@ -4506,11 +4506,11 @@ static void nvme_write_bar(NvmeCtrl *n, hwaddr offset, uint64_t data, n->bar.cmbmsc = (n->bar.cmbmsc & 0xffffffff) | (data << 32); return; - case 0xE00: /* PMRCAP */ + case 0xe00: /* PMRCAP */ NVME_GUEST_ERR(pci_nvme_ub_mmiowr_pmrcap_readonly, "invalid write to PMRCAP register, ignored"); return; - case 0xE04: /* PMRCTL */ + case 0xe04: /* PMRCTL */ n->bar.pmrctl = data; if (NVME_PMRCTL_EN(data)) { memory_region_set_enabled(&n->pmr.dev->mr, true); @@ -4521,19 +4521,19 @@ static void nvme_write_bar(NvmeCtrl *n, hwaddr offset, uint64_t data, n->pmr.cmse = false; } return; - case 0xE08: /* PMRSTS */ + case 0xe08: /* PMRSTS */ NVME_GUEST_ERR(pci_nvme_ub_mmiowr_pmrsts_readonly, "invalid write to PMRSTS register, ignored"); return; - case 0xE0C: /* PMREBS */ + case 0xe0C: /* PMREBS */ NVME_GUEST_ERR(pci_nvme_ub_mmiowr_pmrebs_readonly, "invalid write to PMREBS register, ignored"); return; - case 0xE10: /* PMRSWTP */ + case 0xe10: /* PMRSWTP */ NVME_GUEST_ERR(pci_nvme_ub_mmiowr_pmrswtp_readonly, "invalid write to PMRSWTP register, ignored"); return; - case 0xE14: /* PMRMSCL */ + case 0xe14: /* PMRMSCL */ if (!NVME_CAP_PMRS(n->bar.cap)) { return; } @@ -4553,7 +4553,7 @@ static void nvme_write_bar(NvmeCtrl *n, hwaddr offset, uint64_t data, } return; - case 0xE18: /* PMRMSCU */ + case 0xe18: /* PMRMSCU */ if (!NVME_CAP_PMRS(n->bar.cap)) { return; } @@ -4595,7 +4595,7 @@ static uint64_t nvme_mmio_read(void *opaque, hwaddr addr, unsigned size) * from PMRSTS should ensure prior writes * made it to persistent media */ - if (addr == 0xE08 && + if (addr == 0xe08 && (NVME_PMRCAP_PMRWBM(n->bar.pmrcap) & 0x02)) { memory_region_msync(&n->pmr.dev->mr, 0, n->pmr.dev->size); } diff --git a/include/block/nvme.h b/include/block/nvme.h index 372d0f2799..fc65cfcb01 100644 --- a/include/block/nvme.h +++ b/include/block/nvme.h @@ -840,8 +840,8 @@ enum NvmeStatusCodes { NVME_FEAT_NOT_NS_SPEC = 0x010f, NVME_FW_REQ_SUSYSTEM_RESET = 0x0110, NVME_NS_ALREADY_ATTACHED = 0x0118, - NVME_NS_NOT_ATTACHED = 0x011A, - NVME_NS_CTRL_LIST_INVALID = 0x011C, + NVME_NS_NOT_ATTACHED = 0x011a, + NVME_NS_CTRL_LIST_INVALID = 0x011c, NVME_CONFLICTING_ATTRS = 0x0180, NVME_INVALID_PROT_INFO = 0x0181, NVME_WRITE_TO_RO = 0x0182, @@ -1392,9 +1392,9 @@ typedef enum NvmeZoneState { NVME_ZONE_STATE_IMPLICITLY_OPEN = 0x02, NVME_ZONE_STATE_EXPLICITLY_OPEN = 0x03, NVME_ZONE_STATE_CLOSED = 0x04, - NVME_ZONE_STATE_READ_ONLY = 0x0D, - NVME_ZONE_STATE_FULL = 0x0E, - NVME_ZONE_STATE_OFFLINE = 0x0F, + NVME_ZONE_STATE_READ_ONLY = 0x0d, + NVME_ZONE_STATE_FULL = 0x0e, + NVME_ZONE_STATE_OFFLINE = 0x0f, } NvmeZoneState; static inline void _nvme_check_size(void) -- 2.17.1 ^ permalink raw reply related [flat|nested] 4+ messages in thread
[parent not found: <CGME20210317093452epcas5p1be6015c3cec5c7c8a82c779f511d8bd0@epcas5p1.samsung.com>]
* [PATCH 2/2] hw/block/nvme: align reserved fields declarations [not found] ` <CGME20210317093452epcas5p1be6015c3cec5c7c8a82c779f511d8bd0@epcas5p1.samsung.com> @ 2021-03-17 9:30 ` Gollu Appalanaidu 2021-04-15 6:55 ` Klaus Jensen 0 siblings, 1 reply; 4+ messages in thread From: Gollu Appalanaidu @ 2021-03-17 9:30 UTC (permalink / raw) To: qemu-devel Cc: fam, kwolf, qemu-block, k.jensen, Gollu Appalanaidu, mreitz, its, stefanha, kbusch Align the Reserved fields declaration in NvmeBar Signed-off-by: Gollu Appalanaidu <anaidu.gollu@samsung.com> --- include/block/nvme.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/block/nvme.h b/include/block/nvme.h index fc65cfcb01..e5bd00bb85 100644 --- a/include/block/nvme.h +++ b/include/block/nvme.h @@ -7,7 +7,7 @@ typedef struct QEMU_PACKED NvmeBar { uint32_t intms; uint32_t intmc; uint32_t cc; - uint32_t rsvd1; + uint8_t rsvd24[4]; uint32_t csts; uint32_t nssrc; uint32_t aqa; -- 2.17.1 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH 2/2] hw/block/nvme: align reserved fields declarations 2021-03-17 9:30 ` [PATCH 2/2] hw/block/nvme: align reserved fields declarations Gollu Appalanaidu @ 2021-04-15 6:55 ` Klaus Jensen 0 siblings, 0 replies; 4+ messages in thread From: Klaus Jensen @ 2021-04-15 6:55 UTC (permalink / raw) To: Gollu Appalanaidu Cc: fam, kwolf, qemu-block, k.jensen, qemu-devel, mreitz, stefanha, kbusch [-- Attachment #1: Type: text/plain, Size: 749 bytes --] On Mar 17 15:00, Gollu Appalanaidu wrote: >Align the Reserved fields declaration in NvmeBar > >Signed-off-by: Gollu Appalanaidu <anaidu.gollu@samsung.com> >--- > include/block/nvme.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/include/block/nvme.h b/include/block/nvme.h >index fc65cfcb01..e5bd00bb85 100644 >--- a/include/block/nvme.h >+++ b/include/block/nvme.h >@@ -7,7 +7,7 @@ typedef struct QEMU_PACKED NvmeBar { > uint32_t intms; > uint32_t intmc; > uint32_t cc; >- uint32_t rsvd1; >+ uint8_t rsvd24[4]; > uint32_t csts; > uint32_t nssrc; > uint32_t aqa; >-- >2.17.1 > Thanks. Applied to nvme-next with a small commit message fixup! [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 1/2] hw/block/nvme: align with existing style 2021-03-17 9:30 ` [PATCH 1/2] hw/block/nvme: align with existing style Gollu Appalanaidu [not found] ` <CGME20210317093452epcas5p1be6015c3cec5c7c8a82c779f511d8bd0@epcas5p1.samsung.com> @ 2021-04-15 6:53 ` Klaus Jensen 1 sibling, 0 replies; 4+ messages in thread From: Klaus Jensen @ 2021-04-15 6:53 UTC (permalink / raw) To: Gollu Appalanaidu Cc: fam, kwolf, qemu-block, k.jensen, qemu-devel, mreitz, stefanha, kbusch [-- Attachment #1: Type: text/plain, Size: 6605 bytes --] On Mar 17 15:00, Gollu Appalanaidu wrote: >Make uniform hexadecimal numbers format. > >Signed-off-by: Gollu Appalanaidu <anaidu.gollu@samsung.com> >--- > hw/block/nvme.c | 30 +++++++++++++++--------------- > include/block/nvme.h | 10 +++++----- > 2 files changed, 20 insertions(+), 20 deletions(-) > >diff --git a/hw/block/nvme.c b/hw/block/nvme.c >index d439e44db8..21e85374bf 100644 >--- a/hw/block/nvme.c >+++ b/hw/block/nvme.c >@@ -2728,18 +2728,18 @@ static uint16_t nvme_io_cmd(NvmeCtrl *n, NvmeRequest *req) > > /* > * In the base NVM command set, Flush may apply to all namespaces >- * (indicated by NSID being set to 0xFFFFFFFF). But if that feature is used >+ * (indicated by NSID being set to 0xffffffff). But if that feature is used > * along with TP 4056 (Namespace Types), it may be pretty screwed up. > * >- * If NSID is indeed set to 0xFFFFFFFF, we simply cannot associate the >+ * If NSID is indeed set to 0xffffffff, we simply cannot associate the > * opcode with a specific command since we cannot determine a unique I/O > * command set. Opcode 0x0 could have any other meaning than something > * equivalent to flushing and say it DOES have completely different >- * semantics in some other command set - does an NSID of 0xFFFFFFFF then >+ * semantics in some other command set - does an NSID of 0xffffffff then > * mean "for all namespaces, apply whatever command set specific command > * that uses the 0x0 opcode?" Or does it mean "for all namespaces, apply > * whatever command that uses the 0x0 opcode if, and only if, it allows >- * NSID to be 0xFFFFFFFF"? >+ * NSID to be 0xffffffff"? > * > * Anyway (and luckily), for now, we do not care about this since the > * device only supports namespace types that includes the NVM Flush command >@@ -3948,8 +3948,8 @@ static uint16_t nvme_set_feature(NvmeCtrl *n, NvmeRequest *req) > return NVME_INVALID_FIELD | NVME_DNR; > } > >- trace_pci_nvme_setfeat_numq((dw11 & 0xFFFF) + 1, >- ((dw11 >> 16) & 0xFFFF) + 1, >+ trace_pci_nvme_setfeat_numq((dw11 & 0xffff) + 1, >+ ((dw11 >> 16) & 0xffff) + 1, > n->params.max_ioqpairs, > n->params.max_ioqpairs); > req->cqe.result = cpu_to_le32((n->params.max_ioqpairs - 1) | >@@ -4436,7 +4436,7 @@ static void nvme_write_bar(NvmeCtrl *n, hwaddr offset, uint64_t data, > } > break; > case 0x20: /* NSSR */ >- if (data == 0x4E564D65) { >+ if (data == 0x4e564d65) { > trace_pci_nvme_ub_mmiowr_ssreset_unsupported(); > } else { > /* The spec says that writes of other values have no effect */ >@@ -4506,11 +4506,11 @@ static void nvme_write_bar(NvmeCtrl *n, hwaddr offset, uint64_t data, > n->bar.cmbmsc = (n->bar.cmbmsc & 0xffffffff) | (data << 32); > return; > >- case 0xE00: /* PMRCAP */ >+ case 0xe00: /* PMRCAP */ > NVME_GUEST_ERR(pci_nvme_ub_mmiowr_pmrcap_readonly, > "invalid write to PMRCAP register, ignored"); > return; >- case 0xE04: /* PMRCTL */ >+ case 0xe04: /* PMRCTL */ > n->bar.pmrctl = data; > if (NVME_PMRCTL_EN(data)) { > memory_region_set_enabled(&n->pmr.dev->mr, true); >@@ -4521,19 +4521,19 @@ static void nvme_write_bar(NvmeCtrl *n, hwaddr offset, uint64_t data, > n->pmr.cmse = false; > } > return; >- case 0xE08: /* PMRSTS */ >+ case 0xe08: /* PMRSTS */ > NVME_GUEST_ERR(pci_nvme_ub_mmiowr_pmrsts_readonly, > "invalid write to PMRSTS register, ignored"); > return; >- case 0xE0C: /* PMREBS */ >+ case 0xe0C: /* PMREBS */ > NVME_GUEST_ERR(pci_nvme_ub_mmiowr_pmrebs_readonly, > "invalid write to PMREBS register, ignored"); > return; >- case 0xE10: /* PMRSWTP */ >+ case 0xe10: /* PMRSWTP */ > NVME_GUEST_ERR(pci_nvme_ub_mmiowr_pmrswtp_readonly, > "invalid write to PMRSWTP register, ignored"); > return; >- case 0xE14: /* PMRMSCL */ >+ case 0xe14: /* PMRMSCL */ > if (!NVME_CAP_PMRS(n->bar.cap)) { > return; > } >@@ -4553,7 +4553,7 @@ static void nvme_write_bar(NvmeCtrl *n, hwaddr offset, uint64_t data, > } > > return; >- case 0xE18: /* PMRMSCU */ >+ case 0xe18: /* PMRMSCU */ > if (!NVME_CAP_PMRS(n->bar.cap)) { > return; > } >@@ -4595,7 +4595,7 @@ static uint64_t nvme_mmio_read(void *opaque, hwaddr addr, unsigned size) > * from PMRSTS should ensure prior writes > * made it to persistent media > */ >- if (addr == 0xE08 && >+ if (addr == 0xe08 && > (NVME_PMRCAP_PMRWBM(n->bar.pmrcap) & 0x02)) { > memory_region_msync(&n->pmr.dev->mr, 0, n->pmr.dev->size); > } >diff --git a/include/block/nvme.h b/include/block/nvme.h >index 372d0f2799..fc65cfcb01 100644 >--- a/include/block/nvme.h >+++ b/include/block/nvme.h >@@ -840,8 +840,8 @@ enum NvmeStatusCodes { > NVME_FEAT_NOT_NS_SPEC = 0x010f, > NVME_FW_REQ_SUSYSTEM_RESET = 0x0110, > NVME_NS_ALREADY_ATTACHED = 0x0118, >- NVME_NS_NOT_ATTACHED = 0x011A, >- NVME_NS_CTRL_LIST_INVALID = 0x011C, >+ NVME_NS_NOT_ATTACHED = 0x011a, >+ NVME_NS_CTRL_LIST_INVALID = 0x011c, > NVME_CONFLICTING_ATTRS = 0x0180, > NVME_INVALID_PROT_INFO = 0x0181, > NVME_WRITE_TO_RO = 0x0182, >@@ -1392,9 +1392,9 @@ typedef enum NvmeZoneState { > NVME_ZONE_STATE_IMPLICITLY_OPEN = 0x02, > NVME_ZONE_STATE_EXPLICITLY_OPEN = 0x03, > NVME_ZONE_STATE_CLOSED = 0x04, >- NVME_ZONE_STATE_READ_ONLY = 0x0D, >- NVME_ZONE_STATE_FULL = 0x0E, >- NVME_ZONE_STATE_OFFLINE = 0x0F, >+ NVME_ZONE_STATE_READ_ONLY = 0x0d, >+ NVME_ZONE_STATE_FULL = 0x0e, >+ NVME_ZONE_STATE_OFFLINE = 0x0f, > } NvmeZoneState; > > static inline void _nvme_check_size(void) >-- >2.17.1 > I do prefer lower case hex in code, but for comments I'd actually like if they used the same format as in the spec (i.e. "FFFFFFFFh"). This is total bikeshedding, but I guess this patch basically is too :) [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-04-15 6:58 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CGME20210317093352epcas5p3193a70101b750934fabcb2540129e499@epcas5p3.samsung.com>
2021-03-17 9:30 ` [PATCH 1/2] hw/block/nvme: align with existing style Gollu Appalanaidu
[not found] ` <CGME20210317093452epcas5p1be6015c3cec5c7c8a82c779f511d8bd0@epcas5p1.samsung.com>
2021-03-17 9:30 ` [PATCH 2/2] hw/block/nvme: align reserved fields declarations Gollu Appalanaidu
2021-04-15 6:55 ` Klaus Jensen
2021-04-15 6:53 ` [PATCH 1/2] hw/block/nvme: align with existing style Klaus Jensen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).