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 is a means to pass-through commands, adding a new type would be easy. > Another option is to put a ufs module under hwmon. > Do you see why would that be more advantageous to using the thermal core? > Provided that you are not going to deprecate it (Intel's wifi card is still using it)... > Deprecate what, and what does this discussion have to do with Intel's wifi card ? Either case, the hardware monitoring subsystem provides standard attributes, and it provides a bridge to the thermal subsystem. The question should be why _not_ to use the hwmon subsystem, and this question should be answered as part of this patch series. Guenter
