summaryrefslogtreecommitdiff
path: root/drivers/nvme/target/loop.c
diff options
context:
space:
mode:
authorKeith Busch <kbusch@kernel.org>2023-09-13 00:38:58 +0300
committerKeith Busch <kbusch@kernel.org>2023-09-14 23:09:52 +0300
commit6cc834ba62998c65c42d0c63499bdd35067151ec (patch)
treea94d6bf202fb77aacc762d2784acf67e27bdc7d5 /drivers/nvme/target/loop.c
parentdad651b2a44eb6b201738f810254279dca29d30d (diff)
downloadlinux-6cc834ba62998c65c42d0c63499bdd35067151ec.tar.xz
nvme: avoid bogus CRTO values
Some devices are reporting controller ready mode support, but return 0 for CRTO. These devices require a much higher time to ready than that, so they are failing to initialize after the driver starter preferring that value over CAP.TO. The spec requires that CAP.TO match the appropritate CRTO value, or be set to 0xff if CRTO is larger than that. This means that CAP.TO can be used to validate if CRTO is reliable, and provides an appropriate fallback for setting the timeout value if not. Use whichever is larger. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217863 Reported-by: Cláudio Sampaio <patola@gmail.com> Reported-by: Felix Yan <felixonmars@archlinux.org> Tested-by: Felix Yan <felixonmars@archlinux.org> Based-on-a-patch-by: Felix Yan <felixonmars@archlinux.org> Cc: stable@vger.kernel.org Signed-off-by: Keith Busch <kbusch@kernel.org>
Diffstat (limited to 'drivers/nvme/target/loop.c')
0 files changed, 0 insertions, 0 deletions