summaryrefslogtreecommitdiff
path: root/include/linux/i2c/git@git.tavy.me:linux.git
diff options
context:
space:
mode:
authorJohn Garry <john.g.garry@oracle.com>2026-01-28 08:26:23 +0000
committerKeith Busch <kbusch@kernel.org>2026-01-28 07:02:38 -0800
commitac30cd304347f2daeece6998bb5f0ae2db64e397 (patch)
tree277aefd6cda5b599880481d77b9a140ade1c08f7 /include/linux/i2c/git@git.tavy.me:linux.git
parentddfb8b322bbd8ae996f4ac0192f0190feb0a01ce (diff)
nvme: stop using AWUPF
As described at [0], much of the atomic write parts of the specification are lacking. For now, there is nothing which we can do in software about the lack of a dedicated NVMe write atomic command. As for reading the atomic write limits, it is felt that the per-namespace values are mostly properly specified and it is assumed that they are properly implemented. The specification of NAWUPF is quite clear. However the specification of NABSPF is less clear. The lack of clarity in NABSPF comes from deciding whether NABSPF applies when NSABP is 0 - it is assumed that NSABPF does not apply when NSABP is 0. As for the per-controller AWUPF, how this value applies to shared namespaces is missing in the specification. Furthermore, the value is in terms of logical blocks, which is an NS entity. Since AWUPF is so poorly defined, stop using it already together. Hopefully this will force vendors to implement NAWUPF support always. Note that AWUPF not only effects atomic write support, but also the physical block size reported for the device. To help users know this restriction, log an info message per NS. [0] https://lore.kernel.org/linux-nvme/20250707141834.GA30198@lst.de/ Tested-by: Nilay Shroff <nilay@linux.ibm.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
Diffstat (limited to 'include/linux/i2c/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions