[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

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

[Christoph Hellwig]

On Tue, Nov 03, 2026 at 05:31:29AM -0800, Guenter Roeck wrote:
>>> 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.

So should we drop NVME_QUIRK_NO_SECONDARY_TEMP_THRESH entirely?

Robson: what kind of adverse effects do you see without the quirk?

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

[Guenter Roeck]

On 11/4/26 01:01, Christoph Hellwig wrote:
> On Tue, Nov 03, 2026 at 05:31:29AM -0800, Guenter Roeck wrote:
>>>> 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.
> 
> So should we drop NVME_QUIRK_NO_SECONDARY_TEMP_THRESH entirely?
> 

No. I checked the commit history. Commit bd375feeaf340 ("nvme-pci: add
quirk for missing secondary temperature thresholds"), which added
the quirk, stated that attempts to set the limits on Kingston NVMEs
failed. That seems to be real.

Commit 340f4fc5508c2 added the quirk for Wodposit WPBSNM8-256GTP.
That also seems to be real since it reports an actual failure
when trying to write the limit.

This patch is different. It does not claim a failure when trying
to write the limit, or adverse effects when doing it (which might
be covered by NVME_QUIRK_NO_TEMP_THRESH_CHANGE). It just complains
about unset limits. I do not know if the submitter actually tried
to set the limits.

Thanks,
Guenter

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

[Robson Cassiano]

You are completely correct. I have now tried setting up the temperature
limits manually on the WD SN740 drive, and the NVMe accepted them without
errors.

The quirk is indeed not needed, so please drop/retract this patch request.

Thanks,
Robson


On Wed, Nov 4, 2026 at 11:11 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 11/4/26 01:01, Christoph Hellwig wrote:
> > On Tue, Nov 03, 2026 at 05:31:29AM -0800, Guenter Roeck wrote:
> >>>> 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.
> >
> > So should we drop NVME_QUIRK_NO_SECONDARY_TEMP_THRESH entirely?
> >
>
> No. I checked the commit history. Commit bd375feeaf340 ("nvme-pci: add
> quirk for missing secondary temperature thresholds"), which added
> the quirk, stated that attempts to set the limits on Kingston NVMEs
> failed. That seems to be real.
>
> Commit 340f4fc5508c2 added the quirk for Wodposit WPBSNM8-256GTP.
> That also seems to be real since it reports an actual failure
> when trying to write the limit.
>
> This patch is different. It does not claim a failure when trying
> to write the limit, or adverse effects when doing it (which might
> be covered by NVME_QUIRK_NO_TEMP_THRESH_CHANGE). It just complains
> about unset limits. I do not know if the submitter actually tried
> to set the limits.
>
> Thanks,
> Guenter
>
>


-- 
Live long and prosper 🖖
Robson Cassiano
Senior Software Engineer, Simple Software
+55 19 9 8384 6616
global.robsoncassiano.software/
robson.cassiano@pm.me