The Kioxia THGJFJT2T85BAT0A with firmware revision 0002 reports UFS 4.0
but rejects writes to the qTimestamp attribute with
QUERY_RESULT_INVALID_IDN. This causes errors during device initialization
and whenever the device resumes from runtime suspend:

  ufshcd_dev_cmd_completion: unexpected response in Query RSP: fd
  ufshcd_query_attr_qword: opcode 0x04 for idn 48 failed, index 0, selector 0, err = -22
  ufshcd_set_timestamp_attr: failed to set timestamp -22

Add UFS_DEVICE_QUIRK_NO_TIMESTAMP_SUPPORT for this model to skip the
unsupported timestamp writes, as for the other affected Kioxia devices.

Signed-off-by: Xilin Wu <sophon@radxa.com>
---
 drivers/ufs/core/ufshcd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 2ba244cf40ac..b0fea67d1585 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -321,6 +321,9 @@ static const struct ufs_dev_quirk ufs_fixups[] = {
 	{ .wmanufacturerid = UFS_VENDOR_TOSHIBA,
 	  .model = "THGJFJT1E45BATP",
 	  .quirk = UFS_DEVICE_QUIRK_NO_TIMESTAMP_SUPPORT },
+	{ .wmanufacturerid = UFS_VENDOR_TOSHIBA,
+	  .model = "THGJFJT2T85BAT0A",
+	  .quirk = UFS_DEVICE_QUIRK_NO_TIMESTAMP_SUPPORT },
 	{}
 };
 

---
base-commit: df2908090cda368b01ff43709f51890076c56157
change-id: 20260910-kioxia-ufs4-fix-d8b729a4655f

Best regards,
--  
Xilin Wu <sophon@radxa.com>

Reviewed-by: Stanley Jhu <stanleyjhu@google.com>

> ufshcd_dev_cmd_completion: unexpected response in Query RSP: fd

0xFD is QUERY_RESULT_INVALID_IDN. JESD220F has a device answer that
when an optional IDN is not implemented, so the device is declining
qTimestamp rather than failing on it, and the condition can be
recognised at runtime instead of by model. This is the third model
needing an entry for the quirk.

I have sent a series that decodes 0xFD as -EOPNOTSUPP and disables the
timestamp write on that basis:

  https://lore.kernel.org/linux-scsi/20260911024319.1346706-1-stanleyjhu@google.com/

It does not conflict with this patch; the quirk still skips the first
query. If the part is handy, could you try the series without your
quirk entry and check whether the errors stop? I have no such device
here.

Thanks,
Stanley

On 9/11/2026 11:07 AM, Stanley Jhu wrote:
> Reviewed-by: Stanley Jhu <stanleyjhu@google.com>
> 
>> ufshcd_dev_cmd_completion: unexpected response in Query RSP: fd
> 
> 0xFD is QUERY_RESULT_INVALID_IDN. JESD220F has a device answer that
> when an optional IDN is not implemented, so the device is declining
> qTimestamp rather than failing on it, and the condition can be
> recognised at runtime instead of by model. This is the third model
> needing an entry for the quirk.
> 
> I have sent a series that decodes 0xFD as -EOPNOTSUPP and disables the
> timestamp write on that basis:
> 
>    https://lore.kernel.org/linux-scsi/20260911024319.1346706-1-stanleyjhu@google.com/
> 
> It does not conflict with this patch; the quirk still skips the first
> query. If the part is handy, could you try the series without your
> quirk entry and check whether the errors stop? I have no such device
> here.
> 
> Thanks,
> Stanley
> 

Thanks for the series. It does make the error disappear.

-- 
Best regards,
Xilin Wu <sophon@radxa.com>

On 9/15/26 10:58 PM, Xilin Wu wrote:
> Thanks for the series. It does make the error disappear.

Thank you very much for taking the time to verify the runtime detection
series on actual Kioxia hardware!

With your confirmation that generic QUERY_RESULT_INVALID_IDN (0xFD)
handling resolves the error without a quirk entry, may I include your
tag:

Tested-by: Xilin Wu <sophon@radxa.com>

when posting v2 of the generic series?

I will leave it to you and Martin whether to still take this Kioxia
quirk (for instance, if a one-line quirk is preferred for stable
backports) or go directly with the generic runtime detection.

Thanks again,
Stanley