The driver is accessing the thermal zone device structure but the
accessors are already existing and we want to consolidate the thermal
core code by preventing accesses to the internals from the drivers.
Let's use these accessors.
On the other side, the code is getting directly the temperature from
tz->temperature, but the temperature is a faked on, so we can replace
this access by the fake temp and remove the thermal zone device
structure access.
Signed-off-by: Daniel Lezcano <[email protected]>
---
.../thermal/intel/int340x_thermal/int3400_thermal.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
index 810231b59dcd..66e34241b33a 100644
--- a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
+++ b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
@@ -15,6 +15,7 @@
#define INT3400_THERMAL_TABLE_CHANGED 0x83
#define INT3400_ODVP_CHANGED 0x88
#define INT3400_KEEP_ALIVE 0xA0
+#define INT3400_FAKE_TEMP (20 * 1000) /* faked temp sensor with 20C */
enum int3400_thermal_uuid {
INT3400_THERMAL_ACTIVE = 0,
@@ -453,6 +454,7 @@ static void int3400_notify(acpi_handle handle,
void *data)
{
struct int3400_thermal_priv *priv = data;
+ struct device *dev;
char *thermal_prop[5];
int therm_event;
@@ -475,12 +477,14 @@ static void int3400_notify(acpi_handle handle,
return;
}
- thermal_prop[0] = kasprintf(GFP_KERNEL, "NAME=%s", priv->thermal->type);
- thermal_prop[1] = kasprintf(GFP_KERNEL, "TEMP=%d", priv->thermal->temperature);
+ dev = thermal_zone_device(priv->thermal);
+
+ thermal_prop[0] = kasprintf(GFP_KERNEL, "NAME=%s", thermal_zone_device_type(priv->thermal));
+ thermal_prop[1] = kasprintf(GFP_KERNEL, "TEMP=%d", INT3400_FAKE_TEMP);
thermal_prop[2] = kasprintf(GFP_KERNEL, "TRIP=");
thermal_prop[3] = kasprintf(GFP_KERNEL, "EVENT=%d", therm_event);
thermal_prop[4] = NULL;
- kobject_uevent_env(&priv->thermal->device.kobj, KOBJ_CHANGE, thermal_prop);
+ kobject_uevent_env(&dev->kobj, KOBJ_CHANGE, thermal_prop);
kfree(thermal_prop[0]);
kfree(thermal_prop[1]);
kfree(thermal_prop[2]);
@@ -490,7 +494,7 @@ static void int3400_notify(acpi_handle handle,
static int int3400_thermal_get_temp(struct thermal_zone_device *thermal,
int *temp)
{
- *temp = 20 * 1000; /* faked temp sensor with 20C */
+ *temp = INT3400_FAKE_TEMP;
return 0;
}
--
2.34.1
Hi Srinivas,
do you agree with the changes in patches 5 and 6 ?
Thanks
-- Daniel
On 25/05/2023 16:01, Daniel Lezcano wrote:
> The driver is accessing the thermal zone device structure but the
> accessors are already existing and we want to consolidate the thermal
> core code by preventing accesses to the internals from the drivers.
>
> Let's use these accessors.
>
> On the other side, the code is getting directly the temperature from
> tz->temperature, but the temperature is a faked on, so we can replace
> this access by the fake temp and remove the thermal zone device
> structure access.
>
> Signed-off-by: Daniel Lezcano <[email protected]>
> ---
> .../thermal/intel/int340x_thermal/int3400_thermal.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
> index 810231b59dcd..66e34241b33a 100644
> --- a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
> +++ b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
> @@ -15,6 +15,7 @@
> #define INT3400_THERMAL_TABLE_CHANGED 0x83
> #define INT3400_ODVP_CHANGED 0x88
> #define INT3400_KEEP_ALIVE 0xA0
> +#define INT3400_FAKE_TEMP (20 * 1000) /* faked temp sensor with 20C */
>
> enum int3400_thermal_uuid {
> INT3400_THERMAL_ACTIVE = 0,
> @@ -453,6 +454,7 @@ static void int3400_notify(acpi_handle handle,
> void *data)
> {
> struct int3400_thermal_priv *priv = data;
> + struct device *dev;
> char *thermal_prop[5];
> int therm_event;
>
> @@ -475,12 +477,14 @@ static void int3400_notify(acpi_handle handle,
> return;
> }
>
> - thermal_prop[0] = kasprintf(GFP_KERNEL, "NAME=%s", priv->thermal->type);
> - thermal_prop[1] = kasprintf(GFP_KERNEL, "TEMP=%d", priv->thermal->temperature);
> + dev = thermal_zone_device(priv->thermal);
> +
> + thermal_prop[0] = kasprintf(GFP_KERNEL, "NAME=%s", thermal_zone_device_type(priv->thermal));
> + thermal_prop[1] = kasprintf(GFP_KERNEL, "TEMP=%d", INT3400_FAKE_TEMP);
> thermal_prop[2] = kasprintf(GFP_KERNEL, "TRIP=");
> thermal_prop[3] = kasprintf(GFP_KERNEL, "EVENT=%d", therm_event);
> thermal_prop[4] = NULL;
> - kobject_uevent_env(&priv->thermal->device.kobj, KOBJ_CHANGE, thermal_prop);
> + kobject_uevent_env(&dev->kobj, KOBJ_CHANGE, thermal_prop);
> kfree(thermal_prop[0]);
> kfree(thermal_prop[1]);
> kfree(thermal_prop[2]);
> @@ -490,7 +494,7 @@ static void int3400_notify(acpi_handle handle,
> static int int3400_thermal_get_temp(struct thermal_zone_device *thermal,
> int *temp)
> {
> - *temp = 20 * 1000; /* faked temp sensor with 20C */
> + *temp = INT3400_FAKE_TEMP;
> return 0;
> }
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Hi Daniel,
On Mon, 2023-07-03 at 12:49 +0200, Daniel Lezcano wrote:
>
> Hi Srinivas,
>
> do you agree with the changes in patches 5 and 6 ?
>
> Thanks
>
> -- Daniel
>
>
> On 25/05/2023 16:01, Daniel Lezcano wrote:
> > The driver is accessing the thermal zone device structure but the
> > accessors are already existing and we want to consolidate the
> > thermal
> > core code by preventing accesses to the internals from the drivers.
> >
> > Let's use these accessors.
> >
> > On the other side, the code is getting directly the temperature
> > from
> > tz->temperature, but the temperature is a faked on, so we can
> > replace
> > this access by the fake temp and remove the thermal zone device
> > structure access.
> >
May be something simple description like this will be enough.
"
Use thermal core API to access thermal zone "type" field instead of
directly using the structure field.
While here, remove access to temperature field, as this driver is
reporting fake temperature, which can be replaced with
INT3400_FAKE_TEMP. Also replace hardcoded 20C with INT3400_FAKE_TEMP.
"
The change itself looks fine.
Thanks,
Srinivas
> >
> > Signed-off-by: Daniel Lezcano <[email protected]>
> > ---
> > .../thermal/intel/int340x_thermal/int3400_thermal.c | 12
> > ++++++++----
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git
> > a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
> > b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
> > index 810231b59dcd..66e34241b33a 100644
> > --- a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
> > +++ b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
> > @@ -15,6 +15,7 @@
> > #define INT3400_THERMAL_TABLE_CHANGED 0x83
> > #define INT3400_ODVP_CHANGED 0x88
> > #define INT3400_KEEP_ALIVE 0xA0
> > +#define INT3400_FAKE_TEMP (20 * 1000) /* faked temp sensor with
> > 20C */
> >
> > enum int3400_thermal_uuid {
> > INT3400_THERMAL_ACTIVE = 0,
> > @@ -453,6 +454,7 @@ static void int3400_notify(acpi_handle handle,
> > void *data)
> > {
> > struct int3400_thermal_priv *priv = data;
> > + struct device *dev;
> > char *thermal_prop[5];
> > int therm_event;
> >
> > @@ -475,12 +477,14 @@ static void int3400_notify(acpi_handle
> > handle,
> > return;
> > }
> >
> > - thermal_prop[0] = kasprintf(GFP_KERNEL, "NAME=%s", priv-
> > >thermal->type);
> > - thermal_prop[1] = kasprintf(GFP_KERNEL, "TEMP=%d", priv-
> > >thermal->temperature);
> > + dev = thermal_zone_device(priv->thermal);
> > +
> > + thermal_prop[0] = kasprintf(GFP_KERNEL, "NAME=%s",
> > thermal_zone_device_type(priv->thermal));
> > + thermal_prop[1] = kasprintf(GFP_KERNEL, "TEMP=%d",
> > INT3400_FAKE_TEMP);
> > thermal_prop[2] = kasprintf(GFP_KERNEL, "TRIP=");
> > thermal_prop[3] = kasprintf(GFP_KERNEL, "EVENT=%d",
> > therm_event);
> > thermal_prop[4] = NULL;
> > - kobject_uevent_env(&priv->thermal->device.kobj,
> > KOBJ_CHANGE, thermal_prop);
> > + kobject_uevent_env(&dev->kobj, KOBJ_CHANGE, thermal_prop);
> > kfree(thermal_prop[0]);
> > kfree(thermal_prop[1]);
> > kfree(thermal_prop[2]);
> > @@ -490,7 +494,7 @@ static void int3400_notify(acpi_handle handle,
> > static int int3400_thermal_get_temp(struct thermal_zone_device
> > *thermal,
> > int *temp)
> > {
> > - *temp = 20 * 1000; /* faked temp sensor with 20C */
> > + *temp = INT3400_FAKE_TEMP;
> > return 0;
> > }
> >
>
Hi Srinivas,
thanks for your answer. What about the patch 6?
On 03/07/2023 18:15, srinivas pandruvada wrote:
> Hi Daniel,
>
> On Mon, 2023-07-03 at 12:49 +0200, Daniel Lezcano wrote:
>>
>> Hi Srinivas,
>>
>> do you agree with the changes in patches 5 and 6 ?
>>
>> Thanks
>>
>> -- Daniel
>>
>>
>> On 25/05/2023 16:01, Daniel Lezcano wrote:
>>> The driver is accessing the thermal zone device structure but the
>>> accessors are already existing and we want to consolidate the
>>> thermal
>>> core code by preventing accesses to the internals from the drivers.
>>>
>>> Let's use these accessors.
>>>
>>> On the other side, the code is getting directly the temperature
>>> from
>>> tz->temperature, but the temperature is a faked on, so we can
>>> replace
>>> this access by the fake temp and remove the thermal zone device
>>> structure access.
>>>
> May be something simple description like this will be enough.
>
> "
> Use thermal core API to access thermal zone "type" field instead of
> directly using the structure field.
> While here, remove access to temperature field, as this driver is
> reporting fake temperature, which can be replaced with
> INT3400_FAKE_TEMP. Also replace hardcoded 20C with INT3400_FAKE_TEMP.
> "
>
> The change itself looks fine.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Hi Daniel,
On Wed, 2023-07-05 at 12:41 +0200, Daniel Lezcano wrote:
>
> Hi Srinivas,
>
> thanks for your answer. What about the patch 6?
I was not CCed. But checked from LKML,
The change looks good.
Thanks,
Srinivas
>
>
> On 03/07/2023 18:15, srinivas pandruvada wrote:
> > Hi Daniel,
> >
> > On Mon, 2023-07-03 at 12:49 +0200, Daniel Lezcano wrote:
> > >
> > > Hi Srinivas,
> > >
> > > do you agree with the changes in patches 5 and 6 ?
> > >
> > > Thanks
> > >
> > > -- Daniel
> > >
> > >
> > > On 25/05/2023 16:01, Daniel Lezcano wrote:
> > > > The driver is accessing the thermal zone device structure but
> > > > the
> > > > accessors are already existing and we want to consolidate the
> > > > thermal
> > > > core code by preventing accesses to the internals from the
> > > > drivers.
> > > >
> > > > Let's use these accessors.
> > > >
> > > > On the other side, the code is getting directly the temperature
> > > > from
> > > > tz->temperature, but the temperature is a faked on, so we can
> > > > replace
> > > > this access by the fake temp and remove the thermal zone device
> > > > structure access.
> > > >
> > May be something simple description like this will be enough.
> >
> > "
> > Use thermal core API to access thermal zone "type" field instead of
> > directly using the structure field.
> > While here, remove access to temperature field, as this driver is
> > reporting fake temperature, which can be replaced with
> > INT3400_FAKE_TEMP. Also replace hardcoded 20C with
> > INT3400_FAKE_TEMP.
> > "
> >
> > The change itself looks fine.
>
>
On 05/07/2023 13:35, srinivas pandruvada wrote:
> Hi Daniel,
>
> On Wed, 2023-07-05 at 12:41 +0200, Daniel Lezcano wrote:
>>
>> Hi Srinivas,
>>
>> thanks for your answer. What about the patch 6?
> I was not CCed. But checked from LKML,
> The change looks good.
Actually, you were Cc'ed, the mail may have been lost somehow.
Anyway, thanks for the review. I'll resend with the changelog fixed in
patch 5 and your acked-by
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog