| 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 |
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
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
> -----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
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
> >> 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
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
> 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
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
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,
> > 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/
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,
> > 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
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/
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/
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
> > 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
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,