[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<BL0PR04MB6564CE4996D99B8566F27E0CFCF52@BL0PR04MB6564.namprd04.prod.outlook.com>
Date: Mon, 3 Feb 2025 17:25:53 +0000
From: Avri Altman <Avri.Altman@....com>
To: Guenter Roeck <linux@...ck-us.net>, "Martin K . Petersen"
<martin.petersen@...cle.com>
CC: "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Bart Van
Assche <bvanassche@....org>
Subject: RE: [PATCH 2/2] scsi: ufs: Add support for critical health
notification
> 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
Powered by blists - more mailing lists