> On 2/6/25 9:47 AM, Avri Altman wrote: > >> On 2/6/25 12:54 AM, Avri Altman wrote: > >>> After some further internal discussions: The set conditions are > >>> vendor specific; The device may set it as many times it wants > >>> depending on its criticality. The spec does not define that nor what > >>> the host should do. So there is this concern that some vendors will > >>> report multiple times, while other wont. Hence, reading > >>> critical_health = 1 might be misleading. What do you think? > > > > Still not sure if you want this to be a counter? > > Since the event can be reported multiple times, a counter sounds better to me > than a boolean. Done. > >> How about emitting a uevent if a critical health condition has been > >> reported by a UFS device? See also sdev_evt_send(). > > Thanks for pointing this out. > > A ufs event in enum scsi_device_event seems misplaced - looks like it was > invented for unit attention codes. > > How about calling kobject_uevent() or kobject_uevent_env() directly from the > driver? > > Please note that emitting a uevent is not the only possible approach for informing > user space code. Emitting a uevent is recommended if the code that processes an > event can be implemented as a shell script. Could it be more likely that critical > health events will be processed by C or C++ code rather than a shell script? If so, > how about making the sysfs attribute that reports the number of critical health > events pollable? In C and C++ code, polling a sysfs attribute requires less code > than listening for uevents. Done. Thanks, Avri > > Thanks, > > Bart.
