> 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
