Hi Everyone,

This is an update of

https://lore.kernel.org/linux-pm/4558384.LvFx2qVVIh@kreacher/

which is a resend of the series with one extra patch added.  That extra patch
is related to

https://lore.kernel.org/linux-pm/20240306085428.88011-1-daniel.lezcano@linaro.org/

The original description of the first two patches still applies:

> Patch [1/2] is based on the observation that the threshold field in struct
> thermal_trip really should be core-internal and to make that happen it
> introduces a wrapper structure around struct thermal_trip for internal
> use in the core.
> 
> Patch [2/2] moves the definition of the new structure and the struct
> thermal_zone_device one to a local header file in the core to enforce
> more separation between the core and drivers.
> 
> The patches are not expected to introduce any observable differences in
> behavior, so please let me know if you see any of that.

Patch [3/3] adds a mechanism to sort notifications and debug calls taking
place during one invocation of __thermal_zone_device_update() so they
always go in temperature order.

The series applies on top of 6.9-rc1 and I'm planning to create a test
branch containing it.

Thanks!

Hi Rafael,

thank you for this series.

It has been reported a regression with commit cf3986f8c01d3. I'm 
investigating and confirming it. If it is the case a revert may impact 
this series.


On 25/03/2024 14:10, Rafael J. Wysocki wrote:
> Hi Everyone,
> 
> This is an update of
> 
> https://lore.kernel.org/linux-pm/4558384.LvFx2qVVIh@kreacher/
> 
> which is a resend of the series with one extra patch added.  That extra patch
> is related to
> 
> https://lore.kernel.org/linux-pm/20240306085428.88011-1-daniel.lezcano@linaro.org/
> 
> The original description of the first two patches still applies:
> 
>> Patch [1/2] is based on the observation that the threshold field in struct
>> thermal_trip really should be core-internal and to make that happen it
>> introduces a wrapper structure around struct thermal_trip for internal
>> use in the core.
>>
>> Patch [2/2] moves the definition of the new structure and the struct
>> thermal_zone_device one to a local header file in the core to enforce
>> more separation between the core and drivers.
>>
>> The patches are not expected to introduce any observable differences in
>> behavior, so please let me know if you see any of that.
> 

-- 
<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 Monday, March 25, 2024 2:33:27 PM CET Daniel Lezcano wrote:
> 
> Hi Rafael,
> 
> thank you for this series.
> 
> It has been reported a regression with commit cf3986f8c01d3. I'm 
> investigating and confirming it. If it is the case a revert may impact 
> this series.

Sure.

Can you please give me a pointer to a BZ or e-mail thread where this is
being handled?

Thank you!


> 
> On 25/03/2024 14:10, Rafael J. Wysocki wrote:
> > Hi Everyone,
> > 
> > This is an update of
> > 
> > https://lore.kernel.org/linux-pm/4558384.LvFx2qVVIh@kreacher/
> > 
> > which is a resend of the series with one extra patch added.  That extra patch
> > is related to
> > 
> > https://lore.kernel.org/linux-pm/20240306085428.88011-1-daniel.lezcano@linaro.org/
> > 
> > The original description of the first two patches still applies:
> > 
> >> Patch [1/2] is based on the observation that the threshold field in struct
> >> thermal_trip really should be core-internal and to make that happen it
> >> introduces a wrapper structure around struct thermal_trip for internal
> >> use in the core.
> >>
> >> Patch [2/2] moves the definition of the new structure and the struct
> >> thermal_zone_device one to a local header file in the core to enforce
> >> more separation between the core and drivers.
> >>
> >> The patches are not expected to introduce any observable differences in
> >> behavior, so please let me know if you see any of that.
> > 
> 
>

On 25/03/2024 14:39, Rafael J. Wysocki wrote:
> Hi Daniel,
> 
> On Monday, March 25, 2024 2:33:27 PM CET Daniel Lezcano wrote:
>>
>> Hi Rafael,
>>
>> thank you for this series.
>>
>> It has been reported a regression with commit cf3986f8c01d3. I'm
>> investigating and confirming it. If it is the case a revert may impact
>> this series.
> 
> Sure.
> 
> Can you please give me a pointer to a BZ or e-mail thread where this is
> being handled?

That has been reported to me directly. In a moment, I'll start a thread


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

On Mon, Mar 25, 2024 at 5:05 PM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
> On 25/03/2024 14:39, Rafael J. Wysocki wrote:
> > Hi Daniel,
> >
> > On Monday, March 25, 2024 2:33:27 PM CET Daniel Lezcano wrote:
> >>
> >> Hi Rafael,
> >>
> >> thank you for this series.
> >>
> >> It has been reported a regression with commit cf3986f8c01d3. I'm
> >> investigating and confirming it. If it is the case a revert may impact
> >> this series.
> >
> > Sure.
> >
> > Can you please give me a pointer to a BZ or e-mail thread where this is
> > being handled?
>
> That has been reported to me directly. In a moment, I'll start a thread

There is only a tiny conflict in one hunk of patch [1/3] with this revert:

https://lore.kernel.org/linux-pm/20240325222424.4179635-1-daniel.lezcano@linaro.org/

and it is straightforward to resolve, so no worries.

I'll send an update of patch [1/3] nevertheless.

Cheers!