mbox series

[0/5] scsi: ufs: ufs device as a temperature sensor

Message ID 1580640419-6703-1-git-send-email-avi.shchislowski@wdc.com (mailing list archive)
Headers show
Series scsi: ufs: ufs device as a temperature sensor | expand

Message

Avi Shchislowski Feb. 2, 2020, 10:46 a.m. UTC
UFS3.0 allows using the ufs device as a temperature sensor. The
purpose of this feature is to provide notification to the host of the
UFS device case temperature. It allows reading of a rough estimate
(+-10 degrees centigrade) of the current case temperature, And
setting a lower and upper temperature bounds, in which the device
will trigger an applicable exception event.

We added the capability of responding to such notifications, while
notifying the kernel's thermal core, which further exposes the thermal
zone attributes to user space. UFS temperature attributes are all
read-only, so only thermal read ops (.get_xxx) can be implemented.

Avi Shchislowski (5):
  scsi: ufs: Add ufs thermal support
  scsi: ufs: export ufshcd_enable_ee
  scsi: ufs: enable thermal exception event
  scsi: ufs-thermal: implement thermal file ops
  scsi: ufs: temperature atrributes add to ufs_sysfs

 drivers/scsi/ufs/Kconfig       |  11 ++
 drivers/scsi/ufs/Makefile      |   1 +
 drivers/scsi/ufs/ufs-sysfs.c   |   6 +
 drivers/scsi/ufs/ufs-thermal.c | 247 +++++++++++++++++++++++++++++++++++++++++
 drivers/scsi/ufs/ufs-thermal.h |  25 +++++
 drivers/scsi/ufs/ufs.h         |  20 +++-
 drivers/scsi/ufs/ufshcd.c      |   9 +-
 drivers/scsi/ufs/ufshcd.h      |  12 ++
 8 files changed, 329 insertions(+), 2 deletions(-)
 create mode 100644 drivers/scsi/ufs/ufs-thermal.c
 create mode 100644 drivers/scsi/ufs/ufs-thermal.h

Comments

Guenter Roeck Feb. 2, 2020, 7:21 p.m. UTC | #1
On Sun, Feb 02, 2020 at 12:46:54PM +0200, Avi Shchislowski wrote:
> UFS3.0 allows using the ufs device as a temperature sensor. The
> purpose of this feature is to provide notification to the host of the
> UFS device case temperature. It allows reading of a rough estimate
> (+-10 degrees centigrade) of the current case temperature, And
> setting a lower and upper temperature bounds, in which the device
> will trigger an applicable exception event.
> 
> We added the capability of responding to such notifications, while
> notifying the kernel's thermal core, which further exposes the thermal
> zone attributes to user space. UFS temperature attributes are all
> read-only, so only thermal read ops (.get_xxx) can be implemented.
> 

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 ?

Thanks,
Guenter

> Avi Shchislowski (5):
>   scsi: ufs: Add ufs thermal support
>   scsi: ufs: export ufshcd_enable_ee
>   scsi: ufs: enable thermal exception event
>   scsi: ufs-thermal: implement thermal file ops
>   scsi: ufs: temperature atrributes add to ufs_sysfs

attributes
Bean Huo Feb. 3, 2020, 8:51 a.m. UTC | #2
Hi, Avi
Please add "resend" prefix or version in your subject when you re-send your patches for the next time, 
Such make us easier follow your changes.

Thanks,

//Bean

> Subject: [EXT] [PATCH 0/5] scsi: ufs: ufs device as a temperature sensor
> 
> Avi Shchislowski (5):
>   scsi: ufs: Add ufs thermal support
>   scsi: ufs: export ufshcd_enable_ee
>   scsi: ufs: enable thermal exception event
>   scsi: ufs-thermal: implement thermal file ops
>   scsi: ufs: temperature atrributes add to ufs_sysfs
> 
>  drivers/scsi/ufs/Kconfig       |  11 ++
>  drivers/scsi/ufs/Makefile      |   1 +
>  drivers/scsi/ufs/ufs-sysfs.c   |   6 +
>  drivers/scsi/ufs/ufs-thermal.c | 247
> +++++++++++++++++++++++++++++++++++++++++
>  drivers/scsi/ufs/ufs-thermal.h |  25 +++++
>  drivers/scsi/ufs/ufs.h         |  20 +++-
>  drivers/scsi/ufs/ufshcd.c      |   9 +-
>  drivers/scsi/ufs/ufshcd.h      |  12 ++
>  8 files changed, 329 insertions(+), 2 deletions(-)  create mode 100644
> drivers/scsi/ufs/ufs-thermal.c  create mode 100644 drivers/scsi/ufs/ufs-
> thermal.h
> 
> --
> 1.9.1
Avi Shchislowski Feb. 3, 2020, 11:57 a.m. UTC | #3
> -----Original Message-----
> From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
> Sent: Sunday, February 2, 2020 9:21 PM
> To: Avi Shchislowski <Avi.Shchislowski@wdc.com>
> Cc: Alim Akhtar <alim.akhtar@samsung.com>; Avri Altman
> <Avri.Altman@wdc.com>; James E.J. Bottomley <jejb@linux.ibm.com>;
> Martin K. Petersen <martin.petersen@oracle.com>; linux-
> kernel@vger.kernel.org; linux-scsi@vger.kernel.org
> Subject: Re: [PATCH 0/5] scsi: ufs: ufs device as a temperature sensor
> 
 
> On Sun, Feb 02, 2020 at 12:46:54PM +0200, Avi Shchislowski wrote:
> > UFS3.0 allows using the ufs device as a temperature sensor. The
> > purpose of this feature is to provide notification to the host of the
> > UFS device case temperature. It allows reading of a rough estimate
> > (+-10 degrees centigrade) of the current case temperature, And setting
> > a lower and upper temperature bounds, in which the device will trigger
> > an applicable exception event.
> >
> > We added the capability of responding to such notifications, while
> > notifying the kernel's thermal core, which further exposes the thermal
> > zone attributes to user space. UFS temperature attributes are all
> > read-only, so only thermal read ops (.get_xxx) can be implemented.
> >
> 
> 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 ?
> 
> Thanks,
> Guenter
> 
Hi Guenter

Thank you for your comment

The ufs device is not a temperature sensor per-se.  It is, first and foremost, a storage device.
Reporting the device case temperature is a feature added in a recently released UFS spec (UFS3.0).
Therefore, adding a thermal-core module, in opposed to hwmon module, seemed more appropriate.
Registering a hwmon device look excessive, as no other hw-monitoring attribute is available - aside temperature.

Using Martin's tree, I wasn't able to locate the 'drivetemp' module, nor any reference to  it in the hwmon documentation.

> > Avi Shchislowski (5):
> >   scsi: ufs: Add ufs thermal support
> >   scsi: ufs: export ufshcd_enable_ee
> >   scsi: ufs: enable thermal exception event
> >   scsi: ufs-thermal: implement thermal file ops
> >   scsi: ufs: temperature atrributes add to ufs_sysfs
> 
> attributes
Guenter Roeck Feb. 3, 2020, 2:47 p.m. UTC | #4
On 2/3/20 3:57 AM, Avi Shchislowski wrote:
> 
> 
>> -----Original Message-----
>> From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
>> Sent: Sunday, February 2, 2020 9:21 PM
>> To: Avi Shchislowski <Avi.Shchislowski@wdc.com>
>> Cc: Alim Akhtar <alim.akhtar@samsung.com>; Avri Altman
>> <Avri.Altman@wdc.com>; James E.J. Bottomley <jejb@linux.ibm.com>;
>> Martin K. Petersen <martin.petersen@oracle.com>; linux-
>> kernel@vger.kernel.org; linux-scsi@vger.kernel.org
>> Subject: Re: [PATCH 0/5] scsi: ufs: ufs device as a temperature sensor
>>
>   
>> On Sun, Feb 02, 2020 at 12:46:54PM +0200, Avi Shchislowski wrote:
>>> UFS3.0 allows using the ufs device as a temperature sensor. The
>>> purpose of this feature is to provide notification to the host of the
>>> UFS device case temperature. It allows reading of a rough estimate
>>> (+-10 degrees centigrade) of the current case temperature, And setting
>>> a lower and upper temperature bounds, in which the device will trigger
>>> an applicable exception event.
>>>
>>> We added the capability of responding to such notifications, while
>>> notifying the kernel's thermal core, which further exposes the thermal
>>> zone attributes to user space. UFS temperature attributes are all
>>> read-only, so only thermal read ops (.get_xxx) can be implemented.
>>>
>>
>> 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 ?
>>
>> Thanks,
>> Guenter
>>
> Hi Guenter
> 
> Thank you for your comment
> 
> The ufs device is not a temperature sensor per-se.  It is, first and foremost, a storage device.

Huh ? Many non-temperature-sensor devices in the kernel report their temperature
through the hardware monitoring subsystem.

> Reporting the device case temperature is a feature added in a recently released UFS spec (UFS3.0).
> Therefore, adding a thermal-core module, in opposed to hwmon module, seemed more appropriate.
> Registering a hwmon device look excessive, as no other hw-monitoring attribute is available - aside temperature.
> 
Really ? Interesting position. Are you saying that instantiating a thermal core
module, plus providing non-standard sysfs attributes to report the temperature,
is less complex ? Are you sure ? Can you provide evidence that this is indeed
the case ?

> Using Martin's tree, I wasn't able to locate the 'drivetemp' module, nor any reference to  it in the hwmon documentation.
> 

You might want to consider looking in the mainline kernel.

Guenter
Avri Altman Feb. 3, 2020, 9:29 p.m. UTC | #5
> >> 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.

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)...

As for adding those attributes to ufs-sysfs - 
this is just a supplementary as all other attributes are exposed this way.

Thanks,
Avri
Guenter Roeck Feb. 3, 2020, 9:47 p.m. UTC | #6
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
Avri Altman Feb. 4, 2020, 6:17 a.m. UTC | #7
> 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
Avi Shchislowski Feb. 6, 2020, 10:40 a.m. UTC | #8
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
Julian Calaby Feb. 6, 2020, 11:39 a.m. UTC | #9
Hi Avi,

On Thu, Feb 6, 2020 at 9:48 PM Avi Shchislowski
<Avi.Shchislowski@wdc.com> wrote:
>
> 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.

That isn't my reading of this thread.

You have two options:
1. extend drivetemp if that makes sense for this particular application.
2. follow the model of other devices that happen to have a built-in
temperature sensor and expose the hwmon compatible attributes as a
subdevice

It appears that option 1 isn't viable, so what about option 2?

Thanks,
Avri Altman Feb. 6, 2020, 12:08 p.m. UTC | #10
> 
> Hi Avi,
> 
> On Thu, Feb 6, 2020 at 9:48 PM Avi Shchislowski
> <Avi.Shchislowski@wdc.com> wrote:
> >
> > 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.
> 
> That isn't my reading of this thread.
> 
> You have two options:
> 1. extend drivetemp if that makes sense for this particular application.
> 2. follow the model of other devices that happen to have a built-in
> temperature sensor and expose the hwmon compatible attributes as a
> subdevice
> 
> It appears that option 1 isn't viable, so what about option 2?
This will require to export the ufs device management commands,
Which is privet to the ufs driver.

This is not a viable option as well, because it will allow unrestricted access
(Including format etc.) to the storage device.

Sorry for not making it clearer before.

Thanks,
Avri

> 
> Thanks,
> 
> --
> Julian Calaby
> 
> Email: julian.calaby@gmail.com
> Profile: http://www.google.com/profiles/julian.calaby/
Julian Calaby Feb. 6, 2020, 12:41 p.m. UTC | #11
Hi Avri,

On Thu, Feb 6, 2020 at 11:08 PM Avri Altman <Avri.Altman@wdc.com> wrote:
>
>
> >
> > Hi Avi,
> >
> > On Thu, Feb 6, 2020 at 9:48 PM Avi Shchislowski
> > <Avi.Shchislowski@wdc.com> wrote:
> > >
> > > 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.
> >
> > That isn't my reading of this thread.
> >
> > You have two options:
> > 1. extend drivetemp if that makes sense for this particular application.
> > 2. follow the model of other devices that happen to have a built-in
> > temperature sensor and expose the hwmon compatible attributes as a
> > subdevice
> >
> > It appears that option 1 isn't viable, so what about option 2?
> This will require to export the ufs device management commands,
> Which is privet to the ufs driver.
>
> This is not a viable option as well, because it will allow unrestricted access
> (Including format etc.) to the storage device.
>
> Sorry for not making it clearer before.

I should have clarified further: I meant having the UFS device
register a HWMON driver using this API:
https://www.kernel.org/doc/html/latest/hwmon/hwmon-kernel-api.html

*Not* writing a separate HWMON driver that uses some private interface.

Thanks,
Avri Altman Feb. 6, 2020, 1:40 p.m. UTC | #12
> 
> Hi Avri,
> 
> On Thu, Feb 6, 2020 at 11:08 PM Avri Altman <Avri.Altman@wdc.com>
> wrote:
> >
> >
> > >
> > > Hi Avi,
> > >
> > > On Thu, Feb 6, 2020 at 9:48 PM Avi Shchislowski
> > > <Avi.Shchislowski@wdc.com> wrote:
> > > >
> > > > 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.
> > >
> > > That isn't my reading of this thread.
> > >
> > > You have two options:
> > > 1. extend drivetemp if that makes sense for this particular application.
> > > 2. follow the model of other devices that happen to have a built-in
> > > temperature sensor and expose the hwmon compatible attributes as a
> > > subdevice
> > >
> > > It appears that option 1 isn't viable, so what about option 2?
> > This will require to export the ufs device management commands,
> > Which is privet to the ufs driver.
> >
> > This is not a viable option as well, because it will allow unrestricted access
> > (Including format etc.) to the storage device.
> >
> > Sorry for not making it clearer before.
> 
> I should have clarified further: I meant having the UFS device
> register a HWMON driver using this API:
> https://www.kernel.org/doc/html/latest/hwmon/hwmon-kernel-api.html
> 
> *Not* writing a separate HWMON driver that uses some private interface.
Ok.
Just one last question:
The ufs spec requires to be able to react upon an exception event from the device.
The thermal core provides an api in the form of thermal_notify_framework().
What would be the hwmon equivalent for that?

Thanks,
Avri
Julian Calaby Feb. 6, 2020, 3:49 p.m. UTC | #13
Hi Avri,

On Fri, Feb 7, 2020 at 12:41 AM Avri Altman <Avri.Altman@wdc.com> wrote:
>
> >
> > Hi Avri,
> >
> > On Thu, Feb 6, 2020 at 11:08 PM Avri Altman <Avri.Altman@wdc.com>
> > wrote:
> > >
> > >
> > > >
> > > > Hi Avi,
> > > >
> > > > On Thu, Feb 6, 2020 at 9:48 PM Avi Shchislowski
> > > > <Avi.Shchislowski@wdc.com> wrote:
> > > > >
> > > > > 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.
> > > >
> > > > That isn't my reading of this thread.
> > > >
> > > > You have two options:
> > > > 1. extend drivetemp if that makes sense for this particular application.
> > > > 2. follow the model of other devices that happen to have a built-in
> > > > temperature sensor and expose the hwmon compatible attributes as a
> > > > subdevice
> > > >
> > > > It appears that option 1 isn't viable, so what about option 2?
> > > This will require to export the ufs device management commands,
> > > Which is privet to the ufs driver.
> > >
> > > This is not a viable option as well, because it will allow unrestricted access
> > > (Including format etc.) to the storage device.
> > >
> > > Sorry for not making it clearer before.
> >
> > I should have clarified further: I meant having the UFS device
> > register a HWMON driver using this API:
> > https://www.kernel.org/doc/html/latest/hwmon/hwmon-kernel-api.html
> >
> > *Not* writing a separate HWMON driver that uses some private interface.
> Ok.
> Just one last question:
> The ufs spec requires to be able to react upon an exception event from the device.
> The thermal core provides an api in the form of thermal_notify_framework().
> What would be the hwmon equivalent for that?

My understanding is that HWMON is just a standardised way to report
hardware sensor data to userspace. There are "alarm" files that can be
used to report fault conditions, so any action taken would have to be
either managed by userspace or configured using thermal zones
configured in the hardware's devicetree.

thermal_notify_framework() is a way to notify the "other side" of a
thermal zone to do something to reduce the temperature of that zone.
E.g. spin up a fan or switch to a lower-power state to cool a CPU.
Looking at your code, you're only implementing the "sensor" side of
the thermal zone functionality, so your calls to
thermal_notify_framework() won't do anything.

Thanks,

--
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Avri Altman Feb. 6, 2020, 7:32 p.m. UTC | #14
Hi Julian,

> 
> 
> Hi Avri,
> 
> On Fri, Feb 7, 2020 at 12:41 AM Avri Altman <Avri.Altman@wdc.com> wrote:
> >
> > >
> > > Hi Avri,
> > >
> > > On Thu, Feb 6, 2020 at 11:08 PM Avri Altman <Avri.Altman@wdc.com>
> > > wrote:
> > > >
> > > >
> > > > >
> > > > > Hi Avi,
> > > > >
> > > > > On Thu, Feb 6, 2020 at 9:48 PM Avi Shchislowski
> > > > > <Avi.Shchislowski@wdc.com> wrote:
> > > > > >
> > > > > > 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.
> > > > >
> > > > > That isn't my reading of this thread.
> > > > >
> > > > > You have two options:
> > > > > 1. extend drivetemp if that makes sense for this particular application.
> > > > > 2. follow the model of other devices that happen to have a built-in
> > > > > temperature sensor and expose the hwmon compatible attributes as
> a
> > > > > subdevice
> > > > >
> > > > > It appears that option 1 isn't viable, so what about option 2?
> > > > This will require to export the ufs device management commands,
> > > > Which is privet to the ufs driver.
> > > >
> > > > This is not a viable option as well, because it will allow unrestricted
> access
> > > > (Including format etc.) to the storage device.
> > > >
> > > > Sorry for not making it clearer before.
> > >
> > > I should have clarified further: I meant having the UFS device
> > > register a HWMON driver using this API:
> > > https://www.kernel.org/doc/html/latest/hwmon/hwmon-kernel-
> api.html
> > >
> > > *Not* writing a separate HWMON driver that uses some private
> interface.
> > Ok.
> > Just one last question:
> > The ufs spec requires to be able to react upon an exception event from the
> device.
> > The thermal core provides an api in the form of
> thermal_notify_framework().
> > What would be the hwmon equivalent for that?
> 
> My understanding is that HWMON is just a standardised way to report
> hardware sensor data to userspace. There are "alarm" files that can be
> used to report fault conditions, so any action taken would have to be
> either managed by userspace or configured using thermal zones
> configured in the hardware's devicetree.
Those "alarms" are  implemented as part of the modules under drivers/hwmon/ isn't it?
We already established that this is not an option for the ufs driver.

> 
> thermal_notify_framework() is a way to notify the "other side" of a
> thermal zone to do something to reduce the temperature of that zone.
> E.g. spin up a fan or switch to a lower-power state to cool a CPU.
> Looking at your code, you're only implementing the "sensor" side of
> the thermal zone functionality, so your calls to
> thermal_notify_framework() won't do anything.
Right.  The thermal core allows to react to such notifications,
Provided that the thermal zone device has a governor defined,
And/or notify ops etc.

Should the current patches implement those callbacks or not,
Can be discussed during their review process.
But the important thing is that the thermal core support it in an intuitive and simple way,
While the hwmon doesn't.

We are indifference with respect of which subsystem to use.
The thermal core was our first choice because we bumped into it,
Looking for a way to raise thermal exceptions.
It provides the functionality we need, and other devices uses it,
Why the insistence not to use it?


Thanks,
Avri
 
> 
> Thanks,
> 
> --
> Julian Calaby
> 
> Email: julian.calaby@gmail.com
> Profile: http://www.google.com/profiles/julian.calaby/
Guenter Roeck Feb. 6, 2020, 8:42 p.m. UTC | #15
On Thu, Feb 06, 2020 at 07:32:12PM +0000, Avri Altman wrote:
> Hi Julian,
> 
> > 
> > 
> > Hi Avri,
> > 
> > On Fri, Feb 7, 2020 at 12:41 AM Avri Altman <Avri.Altman@wdc.com> wrote:
> > >
> > > >
> > > > Hi Avri,
> > > >
> > > > On Thu, Feb 6, 2020 at 11:08 PM Avri Altman <Avri.Altman@wdc.com>
> > > > wrote:
> > > > >
> > > > >
> > > > > >
> > > > > > Hi Avi,
> > > > > >
> > > > > > On Thu, Feb 6, 2020 at 9:48 PM Avi Shchislowski
> > > > > > <Avi.Shchislowski@wdc.com> wrote:
> > > > > > >
> > > > > > > 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.
> > > > > >
> > > > > > That isn't my reading of this thread.
> > > > > >
> > > > > > You have two options:
> > > > > > 1. extend drivetemp if that makes sense for this particular application.
> > > > > > 2. follow the model of other devices that happen to have a built-in
> > > > > > temperature sensor and expose the hwmon compatible attributes as
> > a
> > > > > > subdevice
> > > > > >
> > > > > > It appears that option 1 isn't viable, so what about option 2?
> > > > > This will require to export the ufs device management commands,
> > > > > Which is privet to the ufs driver.
> > > > >
> > > > > This is not a viable option as well, because it will allow unrestricted
> > access
> > > > > (Including format etc.) to the storage device.
> > > > >
> > > > > Sorry for not making it clearer before.
> > > >
> > > > I should have clarified further: I meant having the UFS device
> > > > register a HWMON driver using this API:
> > > > https://www.kernel.org/doc/html/latest/hwmon/hwmon-kernel-
> > api.html
> > > >
> > > > *Not* writing a separate HWMON driver that uses some private
> > interface.
> > > Ok.
> > > Just one last question:
> > > The ufs spec requires to be able to react upon an exception event from the
> > device.
> > > The thermal core provides an api in the form of
> > thermal_notify_framework().
> > > What would be the hwmon equivalent for that?
> > 
> > My understanding is that HWMON is just a standardised way to report
> > hardware sensor data to userspace. There are "alarm" files that can be
> > used to report fault conditions, so any action taken would have to be
> > either managed by userspace or configured using thermal zones
> > configured in the hardware's devicetree.
> Those "alarms" are  implemented as part of the modules under drivers/hwmon/ isn't it?
> We already established that this is not an option for the ufs driver.

You have established nothing. What exactly is not an option ?
To create alarm attributes ? No one forces you to create any of those
if you don't want to.

> 
> > 
> > thermal_notify_framework() is a way to notify the "other side" of a
> > thermal zone to do something to reduce the temperature of that zone.
> > E.g. spin up a fan or switch to a lower-power state to cool a CPU.
> > Looking at your code, you're only implementing the "sensor" side of
> > the thermal zone functionality, so your calls to
> > thermal_notify_framework() won't do anything.
> Right.  The thermal core allows to react to such notifications,
> Provided that the thermal zone device has a governor defined,
> And/or notify ops etc.
> 
> Should the current patches implement those callbacks or not,
> Can be discussed during their review process.
> But the important thing is that the thermal core support it in an intuitive and simple way,
> While the hwmon doesn't.
> 
> We are indifference with respect of which subsystem to use.

Not really. Quite the opposite; you are quite obviously heavily
opposed to a hwmon driver.

> The thermal core was our first choice because we bumped into it,
> Looking for a way to raise thermal exceptions.
> It provides the functionality we need, and other devices uses it,
> Why the insistence not to use it?
> 

As mentioned before, the hwmon subsystem lets you create a bridge
to the thermal subsystem, it creates standard attributes to report
temperatures instead of the private ones your patch provides,
and it would result in simpler code.

Why the insistence to _not_ use the hwmon subsystem ?

Guenter
Avri Altman Feb. 6, 2020, 10:21 p.m. UTC | #16
> 
> On Thu, Feb 06, 2020 at 07:32:12PM +0000, Avri Altman wrote:
> > Hi Julian,
> >
> > >
> > >
> > > Hi Avri,
> > >
> > > On Fri, Feb 7, 2020 at 12:41 AM Avri Altman <Avri.Altman@wdc.com>
> wrote:
> > > >
> > > > >
> > > > > Hi Avri,
> > > > >
> > > > > On Thu, Feb 6, 2020 at 11:08 PM Avri Altman
> <Avri.Altman@wdc.com>
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Hi Avi,
> > > > > > >
> > > > > > > On Thu, Feb 6, 2020 at 9:48 PM Avi Shchislowski
> > > > > > > <Avi.Shchislowski@wdc.com> wrote:
> > > > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > > > That isn't my reading of this thread.
> > > > > > >
> > > > > > > You have two options:
> > > > > > > 1. extend drivetemp if that makes sense for this particular
> application.
> > > > > > > 2. follow the model of other devices that happen to have a built-in
> > > > > > > temperature sensor and expose the hwmon compatible attributes
> as
> > > a
> > > > > > > subdevice
> > > > > > >
> > > > > > > It appears that option 1 isn't viable, so what about option 2?
> > > > > > This will require to export the ufs device management commands,
> > > > > > Which is privet to the ufs driver.
> > > > > >
> > > > > > This is not a viable option as well, because it will allow unrestricted
> > > access
> > > > > > (Including format etc.) to the storage device.
> > > > > >
> > > > > > Sorry for not making it clearer before.
> > > > >
> > > > > I should have clarified further: I meant having the UFS device
> > > > > register a HWMON driver using this API:
> > > > > https://www.kernel.org/doc/html/latest/hwmon/hwmon-kernel-
> > > api.html
> > > > >
> > > > > *Not* writing a separate HWMON driver that uses some private
> > > interface.
> > > > Ok.
> > > > Just one last question:
> > > > The ufs spec requires to be able to react upon an exception event from
> the
> > > device.
> > > > The thermal core provides an api in the form of
> > > thermal_notify_framework().
> > > > What would be the hwmon equivalent for that?
> > >
> > > My understanding is that HWMON is just a standardised way to report
> > > hardware sensor data to userspace. There are "alarm" files that can be
> > > used to report fault conditions, so any action taken would have to be
> > > either managed by userspace or configured using thermal zones
> > > configured in the hardware's devicetree.
> > Those "alarms" are  implemented as part of the modules under
> drivers/hwmon/ isn't it?
> > We already established that this is not an option for the ufs driver.
> 
> You have established nothing. What exactly is not an option ?
> To create alarm attributes ? No one forces you to create any of those
> if you don't want to.
> 
> >
> > >
> > > thermal_notify_framework() is a way to notify the "other side" of a
> > > thermal zone to do something to reduce the temperature of that zone.
> > > E.g. spin up a fan or switch to a lower-power state to cool a CPU.
> > > Looking at your code, you're only implementing the "sensor" side of
> > > the thermal zone functionality, so your calls to
> > > thermal_notify_framework() won't do anything.
> > Right.  The thermal core allows to react to such notifications,
> > Provided that the thermal zone device has a governor defined,
> > And/or notify ops etc.
> >
> > Should the current patches implement those callbacks or not,
> > Can be discussed during their review process.
> > But the important thing is that the thermal core support it in an intuitive
> and simple way,
> > While the hwmon doesn't.
> >
> > We are indifference with respect of which subsystem to use.
> 
> Not really. Quite the opposite; you are quite obviously heavily
> opposed to a hwmon driver.
> 
> > The thermal core was our first choice because we bumped into it,
> > Looking for a way to raise thermal exceptions.
> > It provides the functionality we need, and other devices uses it,
> > Why the insistence not to use it?
> >
> 
> As mentioned before, the hwmon subsystem lets you create a bridge
> to the thermal subsystem, it creates standard attributes to report
> temperatures instead of the private ones your patch provides,
> and it would result in simpler code.
> 
> Why the insistence to _not_ use the hwmon subsystem ?
I am not. Please, guide me through it - 
We'll register a hwmon device and implement its read ops.
Since read is confined to the ufs driver, we'll still need to have the ufs-thermal module that we've created.
Next we need to respond to a thermal exception event raised by the device - 
We are expected to pass such notification onward, for whatever governor/mind to  take an applicable action,
Should such mind exists.  How do I do that?

> 
> Guenter
Julian Calaby Feb. 7, 2020, 12:47 a.m. UTC | #17
Hi Avri,

On Fri, Feb 7, 2020 at 6:32 AM Avri Altman <Avri.Altman@wdc.com> wrote:
>
> Hi Julian,
>
> >
> >
> > Hi Avri,
> >
> > On Fri, Feb 7, 2020 at 12:41 AM Avri Altman <Avri.Altman@wdc.com> wrote:
> > >
> > > >
> > > > Hi Avri,
> > > >
> > > > On Thu, Feb 6, 2020 at 11:08 PM Avri Altman <Avri.Altman@wdc.com>
> > > > wrote:
> > > > >
> > > > >
> > > > > >
> > > > > > Hi Avi,
> > > > > >
> > > > > > On Thu, Feb 6, 2020 at 9:48 PM Avi Shchislowski
> > > > > > <Avi.Shchislowski@wdc.com> wrote:
> > > > > > >
> > > > > > > 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.
> > > > > >
> > > > > > That isn't my reading of this thread.
> > > > > >
> > > > > > You have two options:
> > > > > > 1. extend drivetemp if that makes sense for this particular application.
> > > > > > 2. follow the model of other devices that happen to have a built-in
> > > > > > temperature sensor and expose the hwmon compatible attributes as
> > a
> > > > > > subdevice
> > > > > >
> > > > > > It appears that option 1 isn't viable, so what about option 2?
> > > > > This will require to export the ufs device management commands,
> > > > > Which is privet to the ufs driver.
> > > > >
> > > > > This is not a viable option as well, because it will allow unrestricted
> > access
> > > > > (Including format etc.) to the storage device.
> > > > >
> > > > > Sorry for not making it clearer before.
> > > >
> > > > I should have clarified further: I meant having the UFS device
> > > > register a HWMON driver using this API:
> > > > https://www.kernel.org/doc/html/latest/hwmon/hwmon-kernel-
> > api.html
> > > >
> > > > *Not* writing a separate HWMON driver that uses some private
> > interface.
> > > Ok.
> > > Just one last question:
> > > The ufs spec requires to be able to react upon an exception event from the
> > device.
> > > The thermal core provides an api in the form of
> > thermal_notify_framework().
> > > What would be the hwmon equivalent for that?
> >
> > My understanding is that HWMON is just a standardised way to report
> > hardware sensor data to userspace. There are "alarm" files that can be
> > used to report fault conditions, so any action taken would have to be
> > either managed by userspace or configured using thermal zones
> > configured in the hardware's devicetree.
> Those "alarms" are  implemented as part of the modules under drivers/hwmon/ isn't it?
> We already established that this is not an option for the ufs driver.

The HWMON API I pointed you to is a way for _any_ driver to implement
the necessary bits and pieces to report temperatures, alarms, etc.

It is _not_ restricted to modules under drivers/hwmon/ - you can
implement all parts of the HWMON interface from any driver anywhere.

Which means that all that is required to report alarms is to simply
implement support for that particular type of file.

> > thermal_notify_framework() is a way to notify the "other side" of a
> > thermal zone to do something to reduce the temperature of that zone.
> > E.g. spin up a fan or switch to a lower-power state to cool a CPU.
> > Looking at your code, you're only implementing the "sensor" side of
> > the thermal zone functionality, so your calls to
> > thermal_notify_framework() won't do anything.
> Right.  The thermal core allows to react to such notifications,
> Provided that the thermal zone device has a governor defined,
> And/or notify ops etc.

Yes, but you don't define a cooling device, so there's nothing to
react to those notifications.

> Should the current patches implement those callbacks or not,
> Can be discussed during their review process.
> But the important thing is that the thermal core support it in an intuitive and simple way,
> While the hwmon doesn't.
>
> We are indifference with respect of which subsystem to use.
> The thermal core was our first choice because we bumped into it,
> Looking for a way to raise thermal exceptions.
> It provides the functionality we need, and other devices uses it,
> Why the insistence not to use it?

Other devices using the thermal zone subsystem implement both "sides"
of the zone: a sensor that monitors the device and cooling device(s)
which should be able to react to that. E.g. lowering the clock speed
of a CPU, slowing the transmission speed of a WiFi card, etc.

Your implementation doesn't do that.

Thanks,