[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