As it become evident that the hwmon is not a viable option to implement ufs thermal notification, I would appreciate some concrete comments of this series. Thanks, Avi > > > On Mon, Feb 03, 2020 at 09:29:57PM +0000, Avri Altman wrote: > > > > >> Can you add an explanation why this can't be added to the just- > > > > introduced > > > > >> 'drivetemp' driver in the hwmon subsystem, and why it make > > > > >> sense to > > > > have > > > > >> proprietary attributes for temperature and temperature limits ? > > > > > > > > > Guenter hi, > > > Yeah - I see your point. But here is the thing - UFS devices support > > > only a subset of scsi commands. > > > It does not support ATA_16 nor SMART attributes. > > > Moreover, you can't read UFS attributes using any other > > > scsi/ATA/SATA Commands, nor it obey the ATA temperature sensing > conventions. > > > So unless you want to totally break the newly born drivetemp - > > > Better to leave ufs devices out of it. > > > > > > > drivetemp is written with extensibility in mind. For example, Martin > > has a prototype enhancement which supports SCSI drive temperature > sensors. > > As long as a device can be identified as ufs device, and as long as > > there > The ufs device does not identifies as such, e.g. by INQUIRY or other. > > > is a means to pass-through commands, adding a new type would be easy. > I am unaware of any such option. > Device management commands are privet to the ufs driver. > > Thanks, > Avri
