[PATCH 0/2] scsi: ufs: critical health condition

[PATCH 0/2] scsi: ufs: critical health condition

[Avri Altman]

Martin hi,
The UFS4.1 standard, released on January 8 2025, is adding several new
features. Among them a new exception event: HEALTH_CRITICAL, which
notify the host of a device's critical health condition. This
notification implies that the device is approaching to the end of its
life time based on the amount of performed program/erase cycles.

We use the hw monitor subsystem to proliferate this info via the chip
alarm channel.

Please consider this for the next merge window.

Thanks,
Avri

Avri Altman (2):
  scsi: ufs: hwmon: Prepare for more hwmon notifications
  scsi: ufs: Add support for critical health notification

 drivers/ufs/core/Kconfig       |  2 +-
 drivers/ufs/core/ufs-hwmon.c   | 12 ++++++++----
 drivers/ufs/core/ufshcd-priv.h |  8 ++++----
 drivers/ufs/core/ufshcd.c      | 31 ++++++++++++++++++++++++++-----
 include/ufs/ufs.h              |  1 +
 5 files changed, 40 insertions(+), 14 deletions(-)

-- 
2.25.1

[PATCH 1/2] scsi: ufs: hwmon: Prepare for more hwmon notifications

[Avri Altman]

This commit updates the UFS hwmon driver to prepare for handling more
hardware monitoring notifications. Specifically, it changes the type of
the `mask` parameter from `u8` to `u16` to accommodate additional
notification types.

While at it, the Kconfig entry for `CONFIG_SCSI_UFS_HWMON` has been
updated to better reflect its purpose. The description has been changed
from "UFS Temperature Notification" to "UFS Hardware Monitoring" to
indicate that the driver now supports a broader range of hardware
monitoring notifications beyond just temperature.

Signed-off-by: Avri Altman <avri.altman@wdc.com>
---
 drivers/ufs/core/Kconfig       |  2 +-
 drivers/ufs/core/ufs-hwmon.c   |  8 ++++----
 drivers/ufs/core/ufshcd-priv.h |  8 ++++----
 drivers/ufs/core/ufshcd.c      | 16 +++++++++++-----
 4 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/ufs/core/Kconfig b/drivers/ufs/core/Kconfig
index 817208ee64ec..dd3b79ac79be 100644
--- a/drivers/ufs/core/Kconfig
+++ b/drivers/ufs/core/Kconfig
@@ -43,7 +43,7 @@ config SCSI_UFS_FAULT_INJECTION
 	  to test the UFS error handler and abort handler.
 
 config SCSI_UFS_HWMON
-	bool "UFS Temperature Notification"
+	bool "UFS Hardware Monitoring"
 	depends on SCSI_UFSHCD=HWMON || HWMON=y
 	help
 	  This provides support for UFS hardware monitoring. If enabled,
diff --git a/drivers/ufs/core/ufs-hwmon.c b/drivers/ufs/core/ufs-hwmon.c
index 34194064367f..db28f456b923 100644
--- a/drivers/ufs/core/ufs-hwmon.c
+++ b/drivers/ufs/core/ufs-hwmon.c
@@ -12,10 +12,10 @@
 
 struct ufs_hwmon_data {
 	struct ufs_hba *hba;
-	u8 mask;
+	u16 mask;
 };
 
-static int ufs_read_temp_enable(struct ufs_hba *hba, u8 mask, long *val)
+static int ufs_read_temp_enable(struct ufs_hba *hba, u16 mask, long *val)
 {
 	u32 ee_mask;
 	int err;
@@ -163,7 +163,7 @@ static const struct hwmon_chip_info ufs_hwmon_hba_info = {
 	.info	= ufs_hwmon_info,
 };
 
-void ufs_hwmon_probe(struct ufs_hba *hba, u8 mask)
+void ufs_hwmon_probe(struct ufs_hba *hba, u16 mask)
 {
 	struct device *dev = hba->dev;
 	struct ufs_hwmon_data *data;
@@ -199,7 +199,7 @@ void ufs_hwmon_remove(struct ufs_hba *hba)
 	kfree(data);
 }
 
-void ufs_hwmon_notify_event(struct ufs_hba *hba, u8 ee_mask)
+void ufs_hwmon_notify_event(struct ufs_hba *hba, u16 ee_mask)
 {
 	if (!hba->hwmon_device)
 		return;
diff --git a/drivers/ufs/core/ufshcd-priv.h b/drivers/ufs/core/ufshcd-priv.h
index 786f20ef2238..279c3e8d1b21 100644
--- a/drivers/ufs/core/ufshcd-priv.h
+++ b/drivers/ufs/core/ufshcd-priv.h
@@ -33,13 +33,13 @@ static inline bool ufshcd_is_wb_buf_flush_allowed(struct ufs_hba *hba)
 }
 
 #ifdef CONFIG_SCSI_UFS_HWMON
-void ufs_hwmon_probe(struct ufs_hba *hba, u8 mask);
+void ufs_hwmon_probe(struct ufs_hba *hba, u16 mask);
 void ufs_hwmon_remove(struct ufs_hba *hba);
-void ufs_hwmon_notify_event(struct ufs_hba *hba, u8 ee_mask);
+void ufs_hwmon_notify_event(struct ufs_hba *hba, u16 ee_mask);
 #else
-static inline void ufs_hwmon_probe(struct ufs_hba *hba, u8 mask) {}
+static inline void ufs_hwmon_probe(struct ufs_hba *hba, u16 mask) {}
 static inline void ufs_hwmon_remove(struct ufs_hba *hba) {}
-static inline void ufs_hwmon_notify_event(struct ufs_hba *hba, u8 ee_mask) {}
+static inline void ufs_hwmon_notify_event(struct ufs_hba *hba, u16 ee_mask) {}
 #endif
 
 int ufshcd_query_descriptor_retry(struct ufs_hba *hba,
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index f6c38cf10382..9fbaf74b0fef 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -8074,11 +8074,10 @@ static void ufshcd_wb_probe(struct ufs_hba *hba, const u8 *desc_buf)
 	hba->caps &= ~UFSHCD_CAP_WB_EN;
 }
 
-static void ufshcd_temp_notif_probe(struct ufs_hba *hba, const u8 *desc_buf)
+static void ufshcd_temp_notif_probe(struct ufs_hba *hba, const u8 *desc_buf, u16 *mask)
 {
 	struct ufs_dev_info *dev_info = &hba->dev_info;
 	u32 ext_ufs_feature;
-	u8 mask = 0;
 
 	if (!(hba->caps & UFSHCD_CAP_TEMP_NOTIF) || dev_info->wspecversion < 0x300)
 		return;
@@ -8086,10 +8085,17 @@ static void ufshcd_temp_notif_probe(struct ufs_hba *hba, const u8 *desc_buf)
 	ext_ufs_feature = get_unaligned_be32(desc_buf + DEVICE_DESC_PARAM_EXT_UFS_FEATURE_SUP);
 
 	if (ext_ufs_feature & UFS_DEV_LOW_TEMP_NOTIF)
-		mask |= MASK_EE_TOO_LOW_TEMP;
+		*mask |= MASK_EE_TOO_LOW_TEMP;
 
 	if (ext_ufs_feature & UFS_DEV_HIGH_TEMP_NOTIF)
-		mask |= MASK_EE_TOO_HIGH_TEMP;
+		*mask |= MASK_EE_TOO_HIGH_TEMP;
+}
+
+static void ufshcd_hwmon_probe(struct ufs_hba *hba, const u8 *desc_buf)
+{
+	u16 mask = 0;
+
+	ufshcd_temp_notif_probe(hba, desc_buf, &mask);
 
 	if (mask) {
 		ufshcd_enable_ee(hba, mask);
@@ -8288,7 +8294,7 @@ static int ufs_get_device_desc(struct ufs_hba *hba)
 
 	ufshcd_wb_probe(hba, desc_buf);
 
-	ufshcd_temp_notif_probe(hba, desc_buf);
+	ufshcd_hwmon_probe(hba, desc_buf);
 
 	ufs_init_rtc(hba, desc_buf);
 
-- 
2.25.1

[PATCH 2/2] scsi: ufs: Add support for critical health notification

[Avri Altman]

The UFS 4.1 standard, released on January 8, 2025, introduces several
new features, including a new exception event: HEALTH_CRITICAL. This
event notifies the host of a device's critical health condition,
indicating that the device is approaching the end of its lifetime based
on the number of program/erase cycles performed.

We utilize the hwmon (hardware monitoring) subsystem to propagate this
information via the chip alarm channel.

The host can gain further insight into the specific issue by reading one
of the following attributes: bPreEOLInfo, bDeviceLifeTimeEstA,
bDeviceLifeTimeEstB, bWriteBoosterBufferLifeTimeEst, and
bRPMBLifeTimeEst. However, we do not provide the corresponding .read
method in the hwmon subsystem. This is intentional: all other
end-of-life (EOL) signals are available for reading via the driver's
sysfs entries or through an applicable utility. It is up to user-space
to read these attributes if needed. It is not the kernel's
responsibility to interpret any EOL signals, as they may vary from
vendor to vendor.

Signed-off-by: Avri Altman <avri.altman@wdc.com>
---
 drivers/ufs/core/ufs-hwmon.c |  4 ++++
 drivers/ufs/core/ufshcd.c    | 15 +++++++++++++++
 include/ufs/ufs.h            |  1 +
 3 files changed, 20 insertions(+)

diff --git a/drivers/ufs/core/ufs-hwmon.c b/drivers/ufs/core/ufs-hwmon.c
index db28f456b923..410dc6568de5 100644
--- a/drivers/ufs/core/ufs-hwmon.c
+++ b/drivers/ufs/core/ufs-hwmon.c
@@ -149,6 +149,7 @@ static umode_t ufs_hwmon_is_visible(const void *data,
 
 static const struct hwmon_channel_info *const ufs_hwmon_info[] = {
 	HWMON_CHANNEL_INFO(temp, HWMON_T_ENABLE | HWMON_T_INPUT | HWMON_T_CRIT | HWMON_T_LCRIT),
+	HWMON_CHANNEL_INFO(chip, HWMON_C_ALARMS),
 	NULL
 };
 
@@ -209,4 +210,7 @@ void ufs_hwmon_notify_event(struct ufs_hba *hba, u16 ee_mask)
 
 	if (ee_mask & MASK_EE_TOO_LOW_TEMP)
 		hwmon_notify_event(hba->hwmon_device, hwmon_temp, hwmon_temp_min_alarm, 0);
+
+	if (ee_mask & MASK_EE_HEALTH_CRITICAL)
+		hwmon_notify_event(hba->hwmon_device, hwmon_chip, hwmon_chip_alarms, 0);
 }
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 9fbaf74b0fef..407dc1acca0f 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -6198,6 +6198,9 @@ static void ufshcd_exception_event_handler(struct work_struct *work)
 	if (status & hba->ee_drv_mask & MASK_EE_URGENT_TEMP)
 		ufs_hwmon_notify_event(hba, status & MASK_EE_URGENT_TEMP);
 
+	if (status & hba->ee_drv_mask & MASK_EE_HEALTH_CRITICAL)
+		ufs_hwmon_notify_event(hba, status & MASK_EE_HEALTH_CRITICAL);
+
 	ufs_debugfs_exception_event(hba, status);
 }
 
@@ -8091,12 +8094,24 @@ static void ufshcd_temp_notif_probe(struct ufs_hba *hba, const u8 *desc_buf, u16
 		*mask |= MASK_EE_TOO_HIGH_TEMP;
 }
 
+static void ufshcd_critical_health_probe(struct ufs_hba *hba, u16 *mask)
+{
+	struct ufs_dev_info *dev_info = &hba->dev_info;
+
+	if (dev_info->wspecversion < 0x410)
+		return;
+
+	*mask |= MASK_EE_HEALTH_CRITICAL;
+}
+
 static void ufshcd_hwmon_probe(struct ufs_hba *hba, const u8 *desc_buf)
 {
 	u16 mask = 0;
 
 	ufshcd_temp_notif_probe(hba, desc_buf, &mask);
 
+	ufshcd_critical_health_probe(hba, &mask);
+
 	if (mask) {
 		ufshcd_enable_ee(hba, mask);
 		ufs_hwmon_probe(hba, mask);
diff --git a/include/ufs/ufs.h b/include/ufs/ufs.h
index f151feb0ca8c..8a24ed59ec46 100644
--- a/include/ufs/ufs.h
+++ b/include/ufs/ufs.h
@@ -419,6 +419,7 @@ enum {
 	MASK_EE_TOO_LOW_TEMP		= BIT(4),
 	MASK_EE_WRITEBOOSTER_EVENT	= BIT(5),
 	MASK_EE_PERFORMANCE_THROTTLING	= BIT(6),
+	MASK_EE_HEALTH_CRITICAL		= BIT(9),
 };
 #define MASK_EE_URGENT_TEMP (MASK_EE_TOO_HIGH_TEMP | MASK_EE_TOO_LOW_TEMP)
 
-- 
2.25.1

Re: [PATCH 2/2] scsi: ufs: Add support for critical health notification

[Guenter Roeck]

On 2/3/25 07:27, Avri Altman wrote:
> The UFS 4.1 standard, released on January 8, 2025, introduces several
> new features, including a new exception event: HEALTH_CRITICAL. This
> event notifies the host of a device's critical health condition,
> indicating that the device is approaching the end of its lifetime based
> on the number of program/erase cycles performed.
> 
> We utilize the hwmon (hardware monitoring) subsystem to propagate this
> information via the chip alarm channel.
> 

That is outside the scope of the hardware monitoring subsystem,
the "alarms" attribute is deprecated and must not be used
in new drivers, and it isn't actually implemented by this code.

I can't control what is submitted into the ufs code, bu from hardware
monitoring perspective this is a NACK.

Guenter

RE: [PATCH 2/2] scsi: ufs: Add support for critical health notification

[Avri Altman]

> On 2/3/25 07:27, Avri Altman wrote:
> > The UFS 4.1 standard, released on January 8, 2025, introduces several
> > new features, including a new exception event: HEALTH_CRITICAL. This
> > event notifies the host of a device's critical health condition,
> > indicating that the device is approaching the end of its lifetime
> > based on the number of program/erase cycles performed.
> >
> > We utilize the hwmon (hardware monitoring) subsystem to propagate this
> > information via the chip alarm channel.
> >
> 
> That is outside the scope of the hardware monitoring subsystem, the
> "alarms" attribute is deprecated and must not be used in new drivers, and it
> isn't actually implemented by this code.
OK.  Thanks for letting me know.
Do you see any other path I can take within the hwmon,
To let the upper stack / HAL know that the ufs device is reaching its EOL ?
Or should I look elsewhere?

Thanks,
Avri

> 
> I can't control what is submitted into the ufs code, bu from hardware
> monitoring perspective this is a NACK.
> 
> Guenter

Re: [PATCH 2/2] scsi: ufs: Add support for critical health notification

[Guenter Roeck]

On 2/3/25 09:25, Avri Altman wrote:
>> On 2/3/25 07:27, Avri Altman wrote:
>>> The UFS 4.1 standard, released on January 8, 2025, introduces several
>>> new features, including a new exception event: HEALTH_CRITICAL. This
>>> event notifies the host of a device's critical health condition,
>>> indicating that the device is approaching the end of its lifetime
>>> based on the number of program/erase cycles performed.
>>>
>>> We utilize the hwmon (hardware monitoring) subsystem to propagate this
>>> information via the chip alarm channel.
>>>
>>
>> That is outside the scope of the hardware monitoring subsystem, the
>> "alarms" attribute is deprecated and must not be used in new drivers, and it
>> isn't actually implemented by this code.
> OK.  Thanks for letting me know.
> Do you see any other path I can take within the hwmon,
> To let the upper stack / HAL know that the ufs device is reaching its EOL ?
> Or should I look elsewhere?
> 

Again, this is not a hardware monitoring attribute. Normally I'd assume
that information like this is reported, for example, via smartctl or
whatever similar mechanism is available for ufs devices.

Just to give an example: smartctl reports for one of the nvme drives
in my system:

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        39 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    10,835,485 [5.54 TB]
Data Units Written:                 4,931,062 [2.52 TB]
Host Read Commands:                 149,936,032
Host Write Commands:                36,799,659
Controller Busy Time:               318
Power Cycles:                       12
Power On Hours:                     326
Unsafe Shutdowns:                   4
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               39 Celsius
Temperature Sensor 2:               41 Celsius

Per your logic, all of that could be declared to be "hardware monitoring".
That simply doesn't make sense. All that information is reported by smartctl,
and it can and should be monitored using smartd or a similar tool. There is
no need to invent a new mechanism to do the same. If smartmontools don't
support ufs, such support should be added there, and not be pressed into
some unrelated kernel subsystem.

Thanks,
Guenter