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

From: Robson Cassiano

Date: Wed Nov 04 2026 - 13:23:35 EST


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@xxxxxxxxxxxx> 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@xxxxx