[PATCH] nvme-pci: add NVME_QUIRK_NO_SECONDARY_TEMP_THRESH for WD SN740

[PATCH] nvme-pci: add NVME_QUIRK_NO_SECONDARY_TEMP_THRESH for WD SN740

[Robson Cassiano]

The WD SN740 (15b7:5017) reports two secondary temperature sensors in
the SMART/Health log but returns the 0 and 0xffff (Kelvin) sentinels
for their temperature thresholds. nvme-hwmon exposes those as
temp2_min/max and temp3_min/max, producing -273.15 C and 65261.85 C in
sysfs.

Mark the controller with NVME_QUIRK_NO_SECONDARY_TEMP_THRESH so only
the sensor inputs are exposed.

Assisted-by: LLM
Signed-off-by: Robson Cassiano <linux@robsoncassiano.software>
---
Tested on the affected system, WD SN740 512 GB, firmware 73100004:

  # lspci -nn -s 01:00.0
  01:00.0 Non-Volatile memory controller [0108]: Sandisk Corp WD SN560/SN740/SN770/SN5000 NVMe SSD [15b7:5017] (rev 01)

Before, on 7.2.8:

  temp2_label    Sensor 1
  temp2_input    53850
  temp2_min      -273150
  temp2_max      65261850
  temp3_label    Sensor 2
  temp3_input    38850
  temp3_min      -273150
  temp3_max      65261850

After, on 7.3.0 with this patch:

  temp1_label    Composite
  temp1_input    45850
  temp1_min      -40150
  temp1_max      83850
  temp1_crit     87850
  temp2_label    Sensor 1
  temp2_input    59850
  temp3_label    Sensor 2
  temp3_input    45850

temp1_* are the Composite thresholds and stay exposed; the quirk only
suppresses the secondary sensor thresholds.

The quirk also covers the other models sharing 15b7:5017 (SN560, SN770,
SN5000); only the SN740 was tested.

OEM systems: Dell OptiPlex 3000, Lenovo IdeaCentre AIO 5 and Samsung
NP750QFG-KS1BR (the test system).

 drivers/nvme/host/pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 77317e5..4f1f10b 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -4170,6 +4170,8 @@ static const struct pci_device_id nvme_id_table[] = {
 	{ PCI_DEVICE(0x15b7, 0x5009),   /* Sandisk SN550 */
 		.driver_data = NVME_QUIRK_BROKEN_MSI |
 				NVME_QUIRK_NO_DEEPEST_PS },
+	{ PCI_DEVICE(0x15b7, 0x5017),   /* Sandisk SN560/SN740/SN770/SN5000 */
+		.driver_data = NVME_QUIRK_NO_SECONDARY_TEMP_THRESH, },
 	{ PCI_DEVICE(0x1987, 0x5012),	/* Phison E12 */
 		.driver_data = NVME_QUIRK_BOGUS_NID, },
 	{ PCI_DEVICE(0x1987, 0x5016),	/* Phison E16 */
-- 
2.56.0


base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222

Re: [PATCH] nvme-pci: add NVME_QUIRK_NO_SECONDARY_TEMP_THRESH for WD SN740

[Christoph Hellwig]

On Fri, Oct 30, 2026 at 12:05:13AM -0300, Robson Cassiano wrote:
> The WD SN740 (15b7:5017) reports two secondary temperature sensors in
> the SMART/Health log but returns the 0 and 0xffff (Kelvin) sentinels
> for their temperature thresholds. nvme-hwmon exposes those as
> temp2_min/max and temp3_min/max, producing -273.15 C and 65261.85 C in
> sysfs.
> 
> Mark the controller with NVME_QUIRK_NO_SECONDARY_TEMP_THRESH so only
> the sensor inputs are exposed.

Given that this is an older device I suspect we're not going to
see firmware fixes for it.  But given that we had quite a few devices
with issues like this, I wonder why nvme-hwmon can't detect these
obviously fake values instead and we could drop the quirk?

> Assisted-by: LLM
> Signed-off-by: Robson Cassiano <linux@robsoncassiano.software>
> ---
> Tested on the affected system, WD SN740 512 GB, firmware 73100004:
> 
>   # lspci -nn -s 01:00.0
>   01:00.0 Non-Volatile memory controller [0108]: Sandisk Corp WD SN560/SN740/SN770/SN5000 NVMe SSD [15b7:5017] (rev 01)
> 
> Before, on 7.2.8:
> 
>   temp2_label    Sensor 1
>   temp2_input    53850
>   temp2_min      -273150
>   temp2_max      65261850
>   temp3_label    Sensor 2
>   temp3_input    38850
>   temp3_min      -273150
>   temp3_max      65261850
> 
> After, on 7.3.0 with this patch:
> 
>   temp1_label    Composite
>   temp1_input    45850
>   temp1_min      -40150
>   temp1_max      83850
>   temp1_crit     87850
>   temp2_label    Sensor 1
>   temp2_input    59850
>   temp3_label    Sensor 2
>   temp3_input    45850
> 
> temp1_* are the Composite thresholds and stay exposed; the quirk only
> suppresses the secondary sensor thresholds.
> 
> The quirk also covers the other models sharing 15b7:5017 (SN560, SN770,
> SN5000); only the SN740 was tested.
> 
> OEM systems: Dell OptiPlex 3000, Lenovo IdeaCentre AIO 5 and Samsung
> NP750QFG-KS1BR (the test system).
> 
>  drivers/nvme/host/pci.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index 77317e5..4f1f10b 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -4170,6 +4170,8 @@ static const struct pci_device_id nvme_id_table[] = {
>  	{ PCI_DEVICE(0x15b7, 0x5009),   /* Sandisk SN550 */
>  		.driver_data = NVME_QUIRK_BROKEN_MSI |
>  				NVME_QUIRK_NO_DEEPEST_PS },
> +	{ PCI_DEVICE(0x15b7, 0x5017),   /* Sandisk SN560/SN740/SN770/SN5000 */
> +		.driver_data = NVME_QUIRK_NO_SECONDARY_TEMP_THRESH, },
>  	{ PCI_DEVICE(0x1987, 0x5012),	/* Phison E12 */
>  		.driver_data = NVME_QUIRK_BOGUS_NID, },
>  	{ PCI_DEVICE(0x1987, 0x5016),	/* Phison E16 */
> -- 
> 2.56.0
> 
> 
> base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
> 
---end quoted text---

Re: [PATCH] nvme-pci: add NVME_QUIRK_NO_SECONDARY_TEMP_THRESH for WD SN740

[Guenter Roeck]

On 11/2/26 23:58, Christoph Hellwig wrote:
> On Fri, Oct 30, 2026 at 12:05:13AM -0300, Robson Cassiano wrote:
>> The WD SN740 (15b7:5017) reports two secondary temperature sensors in
>> the SMART/Health log but returns the 0 and 0xffff (Kelvin) sentinels
>> for their temperature thresholds. nvme-hwmon exposes those as
>> temp2_min/max and temp3_min/max, producing -273.15 C and 65261.85 C in
>> sysfs.
>>
>> Mark the controller with NVME_QUIRK_NO_SECONDARY_TEMP_THRESH so only
>> the sensor inputs are exposed.
> 
> Given that this is an older device I suspect we're not going to
> see firmware fixes for it.  But given that we had quite a few devices
> with issues like this, I wonder why nvme-hwmon can't detect these
> obviously fake values instead and we could drop the quirk?
> 

Question is if the quirk is really needed. Personally I doubt it.
Normally the thresholds are simply not set. I see that with the NVMEs
on my system (Samsung SSD 990 PRO) as well. If I set min and max
values, they are stored and subsequently displayed correctly.
That means, no, the hwmon driver can _not_ detect if those values
are fake because it can not distinguish "not set" from "not really
supported".

I have not seen the patch, but I strongly suspect that it fixes
a non-issue, unless it can be shown that writing the values has no
effect.

Guenter