linux-next: manual merge of the thermal tree with the pm tree

linux-next: manual merge of the thermal tree with the pm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

Hi Zhang,

Today's linux-next merge of the thermal tree got a conflict in
drivers/cpufreq/Kconfig between commit 109df086e002 ("cpufreq: Select
PM_OPP rather than depending on it") from the pm tree and commit
77cff5926a14 ("cpufreq: cpufreq-cpu0: add dt node parsing for cooling
device properties") from the thermal tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/cpufreq/Kconfig
index 386dbc9ccdfd,6b8cde5f98af..000000000000
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@@ -181,8 -181,7 +181,8 @@@ config CPU_FREQ_GOV_CONSERVATIV
  
  config GENERIC_CPUFREQ_CPU0
  	tristate "Generic CPU0 cpufreq driver"
- 	depends on HAVE_CLK && REGULATOR && OF
 -	depends on HAVE_CLK && REGULATOR && PM_OPP && OF && THERMAL && CPU_THERMAL
++	depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL
 +	select PM_OPP
  	help
  	  This adds a generic cpufreq driver for CPU0 frequency management.
  	  It supports both uniprocessor (UP) and symmetric multiprocessor (SMP)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the thermal tree with the pm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2280 bytes --]

Hi all,

Today's linux-next merge of the thermal tree got conflicts in:

  drivers/thermal/thermal_core.c
  drivers/thermal/thermal_core.h

between commit:

  a8c959402d4d ("thermal: core: Add governor callback for thermal zone change")

from the pm tree and commits:

  726edaad90f6 ("thermal/core: Prepare for introduction of thermal reboot")
  f21b0d185f75 ("reboot: Introduce thermal_zone_device_critical_reboot()")

from the thermal tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/thermal/thermal_core.c
index 58958288b559,9d47347d4242..000000000000
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@@ -309,16 -314,7 +309,16 @@@ static void handle_non_critical_trips(s
  		       def_governor->throttle(tz, trip);
  }
  
 +void thermal_governor_update_tz(struct thermal_zone_device *tz,
 +				enum thermal_notify_event reason)
 +{
 +	if (!tz->governor || !tz->governor->update_tz)
 +		return;
 +
 +	tz->governor->update_tz(tz, reason);
 +}
 +
- void thermal_zone_device_critical(struct thermal_zone_device *tz)
+ static void thermal_zone_device_halt(struct thermal_zone_device *tz, bool shutdown)
  {
  	/*
  	 * poweroff_delay_ms must be a carefully profiled positive value.
diff --cc drivers/thermal/thermal_core.h
index 479c3b6917e4,36364688b4a2..000000000000
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@@ -114,8 -114,7 +114,9 @@@ int thermal_zone_device_set_policy(stru
  int thermal_build_list_of_policies(char *buf);
  void __thermal_zone_device_update(struct thermal_zone_device *tz,
  				  enum thermal_notify_event event);
 +void thermal_governor_update_tz(struct thermal_zone_device *tz,
 +				enum thermal_notify_event reason);
+ void thermal_zone_device_critical_reboot(struct thermal_zone_device *tz);
  
  /* Helpers */
  #define for_each_trip(__tz, __trip)	\

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the thermal tree with the pm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

Hi all,

Today's linux-next merge of the thermal tree got a conflict in:

  drivers/thermal/mediatek/auxadc_thermal.c

between commit:

  10debf8c2da8 ("thermal/drivers/mediatek: Add delay after thermal banks initialization")

from the pm tree and commit:

  ed18ce7b06cc ("thermal/drivers/mediatek: Add delay after thermal banks initialization")

from the thermal tree.

I fixed it up (it is just a comment difference, so I used the former
version) and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be mentioned
to your upstream maintainer when your tree is submitted for merging.
You may also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the thermal tree with the pm tree

[Wysocki, Rafael J]

On 1/24/2023 11:39 PM, Stephen Rothwell wrote:
> Hi all,
>
> FIXME: Add owner of second tree to To:
>         Add author(s)/SOB of conflicting commits.
>
> Today's linux-next merge of the thermal tree got a conflict in:
>
>    drivers/thermal/intel/intel_pch_thermal.c
>
> between commit:
>
>    fee19c692160 ("thermal: intel: intel_pch: Use generic trip points")
>
> from the pm tree and commit:
>
>    9e631aa90c97 ("thermal/drivers/intel: Use generic trip points for intel_pch")
>
> from the thermal tree.
>
> These commits are very similar, so I just used the former version (since
> it was newer).

Thank you, this is correct.

The linux-next branch in the thermal tree needs to be updated.

Cheers,

Rafael

Re: linux-next: manual merge of the thermal tree with the pm tree

[Wysocki, Rafael J]

On 1/24/2023 11:45 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the thermal tree got a conflict in:
>
>    drivers/thermal/thermal_acpi.c
>
> between commit:
>
>    7a0e39748861 ("thermal: ACPI: Add ACPI trip point routines")
>
> from the pm tree and commit:
>
>    4bb6439371e9 ("thermal/acpi: Add ACPI trip point routines")
>
> from the thermal tree.
>
> These commits are very similar, and I just used the former (as it
> is newer).

Thank you, this is correct.

The linux-next branch in the thermal tree needs to be updated.

Cheers,

Rafael

linux-next: manual merge of the thermal tree with the pm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

Hi all,

Today's linux-next merge of the thermal tree got a conflict in:

  drivers/thermal/thermal_acpi.c

between commit:

  7a0e39748861 ("thermal: ACPI: Add ACPI trip point routines")

from the pm tree and commit:

  4bb6439371e9 ("thermal/acpi: Add ACPI trip point routines")

from the thermal tree.

These commits are very similar, and I just used the former (as it
is newer).

I fixed it up (see above) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the thermal tree with the pm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

Hi all,

FIXME: Add owner of second tree to To:
       Add author(s)/SOB of conflicting commits.

Today's linux-next merge of the thermal tree got a conflict in:

  drivers/thermal/intel/intel_pch_thermal.c

between commit:

  fee19c692160 ("thermal: intel: intel_pch: Use generic trip points")

from the pm tree and commit:

  9e631aa90c97 ("thermal/drivers/intel: Use generic trip points for intel_pch")

from the thermal tree.

These commits are very similar, so I just used the former version (since
it was newer).

I fixed it up (see above) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the thermal tree with the pm tree

[Wysocki, Rafael J]

On 1/5/2023 4:30 PM, Daniel Lezcano wrote:
> On 05/01/2023 15:27, Wysocki, Rafael J wrote:
>>
>> On 1/5/2023 12:35 AM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> On Thu, 5 Jan 2023 10:10:54 +1100 Stephen Rothwell 
>>> <sfr@canb.auug.org.au> wrote:
>>>> Today's linux-next merge of the thermal tree got a conflict in:
>>>>
>>>>    drivers/thermal/intel/x86_pkg_temp_thermal.c
>>>>
>>>> between commit:
>>>>
>>>>    58374a3970a0 ("thermal/x86_pkg_temp_thermal: Add support for 
>>>> handling dynamic tjmax")
>>>>
>>>> from the pm tree and commit:
>>>>
>>>>    03b2e86a24aa ("thermal/drivers/intel: Use generic 
>>>> thermal_zone_get_trip() function")
>>>>
>>>> from the thermal tree.
>>
>> I'm wondering why the above commit is in the linux-next branch of the 
>> thermal tree, though.
>
> If you are referring to commit 03b2e86a24aa, it is part of the series 
> which was reviewed but got some locking conflict issues just before 
> the merge window so we dropped it. You asked me to reintroduce it with 
> the fixes after v6.2-rc1 is out [1].
>
Ah, sorry.  I confused it with the new work posted recently. Apologies.


> The previous conflict and this one is because some changes were picked 
> in the linux-pm branch instead of the thermal/linux-branch.
>
So to be precise, I picked up some new material including fixes into 
linux-pm while you were away, and that should work, because linux-pm is 
an upstream for thermal anyway.

Things are slightly complicated by the fact that thermal/linux-next is 
merged directly into linux-next without going into linux-pm/linux-next.  
However, this also happens with other trees I pull from, like cpufreq 
and devfreq.  In particular, both Viresh and I sometimes apply core 
cpufreq changes and it all works.


> We find thermal Intel changes going directly in linux-pm and thermal 
> changes going through the thermal tree. And sometime thermal core 
> changes picked through linux-pm and sometime through thermal/linux-next.
>
And because effectively linux-pm is the thermal's upstream, it all 
should work.


> In order to prevent these conflicts in the future, I suggest to always 
> merge thermal patches through the thermal tree.
>
There are multiple ways to avoid such conflicts, we just need to be more 
careful IMV.

I may as well merge thermal/linux-next into linux-pm/linux-next before 
pushing it and let you know if there are any conflicts.


>> It is still under review AFAICS.
>
> The series including the patch "thermal/drivers/intel: Use generic 
> ..." are reviewed and ready for inclusion AFAICT.
>
> I'm was waiting for an update of linux-pm/thermal to send a PR against 
> this branch.
>
I see.  I didn't know that, though.


>> Daniel, can you possibly create a bleeding-edge branch for such 
>> things? I can merge it into my bleeding-edge branch on a daily basis.
>
> Yes, I can create a bleeding-edge branch for other patches. Some 
> questions about it:
>
>  - thermal/linux-next will be based on linux-pm/thermal, and 
> thermal/bleeding-edge will be based on thermal/linux-next, right?
>
thermal/bleeding-edge is what will go into thermal/linux-next after 
getting some 0-day coverage.  So the flow may look like this:

- Add stuff to thermal/bleeding-edge.

- It is merged into linux-pm/bleeding-edge (note that this will happen 
every time afresh, so you can rebase it etc. before pushing, no problem).

- Give it a couple of days to get tested.

- Move it into thermal/linux-next if all goes well (they need not be the 
same commits, rebasing is fine).

- Repeat.

There will be some topic thermal branches in linux-pm (eg. Intel thermal 
drivers), but this should not be a problem. We'll see conflicts and 
address them as they appear.


>  - When patches can be considered for the bleeding-edge?

Anything regarded as possible future linux-next material.


>  - When patches can be considered moving from bleeding-edge to 
> linux-next?
>
When they are regarded as ready to go into the mainline during the 
subsequent merge window (or during the ongoing one if there is one in 
progress ATM).  IOW, the normal linux-next rules apply I believe.


> (the questions above are for the thermal tree).
>
Sure.

Thanks!

Re: linux-next: manual merge of the thermal tree with the pm tree

[Daniel Lezcano]

On 05/01/2023 15:27, Wysocki, Rafael J wrote:
> 
> On 1/5/2023 12:35 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> On Thu, 5 Jan 2023 10:10:54 +1100 Stephen Rothwell 
>> <sfr@canb.auug.org.au> wrote:
>>> Today's linux-next merge of the thermal tree got a conflict in:
>>>
>>>    drivers/thermal/intel/x86_pkg_temp_thermal.c
>>>
>>> between commit:
>>>
>>>    58374a3970a0 ("thermal/x86_pkg_temp_thermal: Add support for 
>>> handling dynamic tjmax")
>>>
>>> from the pm tree and commit:
>>>
>>>    03b2e86a24aa ("thermal/drivers/intel: Use generic 
>>> thermal_zone_get_trip() function")
>>>
>>> from the thermal tree.
> 
> I'm wondering why the above commit is in the linux-next branch of the 
> thermal tree, though.

If you are referring to commit 03b2e86a24aa, it is part of the series 
which was reviewed but got some locking conflict issues just before the 
merge window so we dropped it. You asked me to reintroduce it with the 
fixes after v6.2-rc1 is out [1].

The previous conflict and this one is because some changes were picked 
in the linux-pm branch instead of the thermal/linux-branch.

We find thermal Intel changes going directly in linux-pm and thermal 
changes going through the thermal tree. And sometime thermal core 
changes picked through linux-pm and sometime through thermal/linux-next.

In order to prevent these conflicts in the future, I suggest to always 
merge thermal patches through the thermal tree.

> It is still under review AFAICS.

The series including the patch "thermal/drivers/intel: Use generic ..." 
are reviewed and ready for inclusion AFAICT.

I'm was waiting for an update of linux-pm/thermal to send a PR against 
this branch.

> Daniel, can you possibly create a bleeding-edge branch for such things? 
> I can merge it into my bleeding-edge branch on a daily basis.

Yes, I can create a bleeding-edge branch for other patches. Some 
questions about it:

  - thermal/linux-next will be based on linux-pm/thermal, and 
thermal/bleeding-edge will be based on thermal/linux-next, right?

  - When patches can be considered for the bleeding-edge?

  - When patches can be considered moving from bleeding-edge to linux-next?

(the questions above are for the thermal tree).

Thanks

   -- Daniel

[1] 
https://lore.kernel.org/all/CAJZ5v0gY-Lhgf_1Kfg6P5O8s+YMkP4TxggxyS=LU9jVgJikAkg@mail.gmail.com/


>>> I fixed it up (see below) and can carry the fix as necessary. This
>>> is now fixed as far as linux-next is concerned, but any non trivial
>>> conflicts should be mentioned to your upstream maintainer when your tree
>>> is submitted for merging.  You may also want to consider cooperating
>>> with the maintainer of the conflicting tree to minimise any particularly
>>> complex conflicts.
>> Actually, the resolution I needed was this:
>>
>> diff --cc drivers/thermal/intel/x86_pkg_temp_thermal.c
>> index 9e08d8c8f5fb,494f25250c2d..24c7774cc4a9
>> --- a/drivers/thermal/intel/x86_pkg_temp_thermal.c
>> +++ b/drivers/thermal/intel/x86_pkg_temp_thermal.c
>> @@@ -107,56 -108,37 +108,17 @@@ static struct zone_device *pkg_temp_the
>>    static int sys_get_curr_temp(struct thermal_zone_device *tzd, int 
>> *temp)
>>    {
>>        struct zone_device *zonedev = tzd->devdata;
>>   -    u32 eax, edx;
>>   +    int val;
>>   -    rdmsr_on_cpu(zonedev->cpu, MSR_IA32_PACKAGE_THERM_STATUS,
>>   -            &eax, &edx);
>>   -    if (eax & 0x80000000) {
>>   -        *temp = zonedev->tj_max - ((eax >> 16) & 0x7f) * 1000;
>>   -        pr_debug("sys_get_curr_temp %d\n", *temp);
>>   -        return 0;
>>   -    }
>>   -    return -EINVAL;
>>   +    val = intel_tcc_get_temp(zonedev->cpu, true);
>>   +    if (val < 0)
>>   +        return val;
>>   +
>>   +    *temp = val * 1000;
>>   +    pr_debug("sys_get_curr_temp %d\n", *temp);
>>   +    return 0;
>>    }
>> - static int sys_get_trip_temp(struct thermal_zone_device *tzd,
>> -                  int trip, int *temp)
>> - {
>> -     struct zone_device *zonedev = tzd->devdata;
>> -     unsigned long thres_reg_value;
>> -     u32 mask, shift, eax, edx;
>> -     int tj_max, ret;
>> -
>> -     if (trip >= MAX_NUMBER_OF_TRIPS)
>> -         return -EINVAL;
>> -
>> -     if (trip) {
>> -         mask = THERM_MASK_THRESHOLD1;
>> -         shift = THERM_SHIFT_THRESHOLD1;
>> -     } else {
>> -         mask = THERM_MASK_THRESHOLD0;
>> -         shift = THERM_SHIFT_THRESHOLD0;
>> -     }
>> -
>> -     tj_max = intel_tcc_get_tjmax(zonedev->cpu);
>> -     if (tj_max < 0)
>> -         return tj_max;
>> -     tj_max *= 1000;
>> -
>> -     ret = rdmsr_on_cpu(zonedev->cpu, MSR_IA32_PACKAGE_THERM_INTERRUPT,
>> -                &eax, &edx);
>> -     if (ret < 0)
>> -         return ret;
>> -
>> -     thres_reg_value = (eax & mask) >> shift;
>> -     if (thres_reg_value)
>> -         *temp = tj_max - thres_reg_value * 1000;
>> -     else
>> -         *temp = THERMAL_TEMP_INVALID;
>> -     pr_debug("sys_get_trip_temp %d\n", *temp);
>> -
>> -     return 0;
>> - }
>> -
>>    static int
>>    sys_set_trip_temp(struct thermal_zone_device *tzd, int trip, int temp)
>>    {
>> @@@ -330,18 -340,25 +325,25 @@@ static int pkg_temp_thermal_device_add(
>>        thres_count = clamp_val(thres_count, 0, MAX_NUMBER_OF_TRIPS);
>> -     err = intel_tcc_get_tjmax(cpu);
>> -     if (err < 0)
>>   -    err = get_tj_max(cpu, &tj_max);
>>   -    if (err)
>> --        return err;
>> ++    tj_max = intel_tcc_get_tjmax(cpu);
>> ++    if (tj_max < 0)
>> ++        return tj_max;
>> ++    tj_max *= 1000;
>>        zonedev = kzalloc(sizeof(*zonedev), GFP_KERNEL);
>>        if (!zonedev)
>>            return -ENOMEM;
>> +     zonedev->trips = pkg_temp_thermal_trips_init(cpu, tj_max, 
>> thres_count);
>> +     if (IS_ERR(zonedev->trips)) {
>> +         err = PTR_ERR(zonedev->trips);
>> +         goto out_kfree_zonedev;
>> +     }
>> +
>>        INIT_DELAYED_WORK(&zonedev->work, 
>> pkg_temp_thermal_threshold_work_fn);
>>        zonedev->cpu = cpu;
>> -     zonedev->tzone = thermal_zone_device_register("x86_pkg_temp",
>> -             thres_count,
>>   -    zonedev->tj_max = tj_max;
>> +     zonedev->tzone = 
>> thermal_zone_device_register_with_trips("x86_pkg_temp",
>> +             zonedev->trips, thres_count,
>>                (thres_count == MAX_NUMBER_OF_TRIPS) ? 0x03 : 0x01,
>>                zonedev, &tzone_ops, &pkg_temp_tz_params, 0, 0);
>>        if (IS_ERR(zonedev->tzone)) {
>>

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

Re: linux-next: manual merge of the thermal tree with the pm tree

[Wysocki, Rafael J]

On 1/5/2023 12:35 AM, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 5 Jan 2023 10:10:54 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Today's linux-next merge of the thermal tree got a conflict in:
>>
>>    drivers/thermal/intel/x86_pkg_temp_thermal.c
>>
>> between commit:
>>
>>    58374a3970a0 ("thermal/x86_pkg_temp_thermal: Add support for handling dynamic tjmax")
>>
>> from the pm tree and commit:
>>
>>    03b2e86a24aa ("thermal/drivers/intel: Use generic thermal_zone_get_trip() function")
>>
>> from the thermal tree.

I'm wondering why the above commit is in the linux-next branch of the 
thermal tree, though.

It is still under review AFAICS.

Daniel, can you possibly create a bleeding-edge branch for such things?  
I can merge it into my bleeding-edge branch on a daily basis.


>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging.  You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
> Actually, the resolution I needed was this:
>
> diff --cc drivers/thermal/intel/x86_pkg_temp_thermal.c
> index 9e08d8c8f5fb,494f25250c2d..24c7774cc4a9
> --- a/drivers/thermal/intel/x86_pkg_temp_thermal.c
> +++ b/drivers/thermal/intel/x86_pkg_temp_thermal.c
> @@@ -107,56 -108,37 +108,17 @@@ static struct zone_device *pkg_temp_the
>    static int sys_get_curr_temp(struct thermal_zone_device *tzd, int *temp)
>    {
>    	struct zone_device *zonedev = tzd->devdata;
>   -	u32 eax, edx;
>   +	int val;
>    
>   -	rdmsr_on_cpu(zonedev->cpu, MSR_IA32_PACKAGE_THERM_STATUS,
>   -			&eax, &edx);
>   -	if (eax & 0x80000000) {
>   -		*temp = zonedev->tj_max - ((eax >> 16) & 0x7f) * 1000;
>   -		pr_debug("sys_get_curr_temp %d\n", *temp);
>   -		return 0;
>   -	}
>   -	return -EINVAL;
>   +	val = intel_tcc_get_temp(zonedev->cpu, true);
>   +	if (val < 0)
>   +		return val;
>   +
>   +	*temp = val * 1000;
>   +	pr_debug("sys_get_curr_temp %d\n", *temp);
>   +	return 0;
>    }
>    
> - static int sys_get_trip_temp(struct thermal_zone_device *tzd,
> - 			     int trip, int *temp)
> - {
> - 	struct zone_device *zonedev = tzd->devdata;
> - 	unsigned long thres_reg_value;
> - 	u32 mask, shift, eax, edx;
> - 	int tj_max, ret;
> -
> - 	if (trip >= MAX_NUMBER_OF_TRIPS)
> - 		return -EINVAL;
> -
> - 	if (trip) {
> - 		mask = THERM_MASK_THRESHOLD1;
> - 		shift = THERM_SHIFT_THRESHOLD1;
> - 	} else {
> - 		mask = THERM_MASK_THRESHOLD0;
> - 		shift = THERM_SHIFT_THRESHOLD0;
> - 	}
> -
> - 	tj_max = intel_tcc_get_tjmax(zonedev->cpu);
> - 	if (tj_max < 0)
> - 		return tj_max;
> - 	tj_max *= 1000;
> -
> - 	ret = rdmsr_on_cpu(zonedev->cpu, MSR_IA32_PACKAGE_THERM_INTERRUPT,
> - 			   &eax, &edx);
> - 	if (ret < 0)
> - 		return ret;
> -
> - 	thres_reg_value = (eax & mask) >> shift;
> - 	if (thres_reg_value)
> - 		*temp = tj_max - thres_reg_value * 1000;
> - 	else
> - 		*temp = THERMAL_TEMP_INVALID;
> - 	pr_debug("sys_get_trip_temp %d\n", *temp);
> -
> - 	return 0;
> - }
> -
>    static int
>    sys_set_trip_temp(struct thermal_zone_device *tzd, int trip, int temp)
>    {
> @@@ -330,18 -340,25 +325,25 @@@ static int pkg_temp_thermal_device_add(
>    
>    	thres_count = clamp_val(thres_count, 0, MAX_NUMBER_OF_TRIPS);
>    
> - 	err = intel_tcc_get_tjmax(cpu);
> - 	if (err < 0)
>   -	err = get_tj_max(cpu, &tj_max);
>   -	if (err)
> --		return err;
> ++	tj_max = intel_tcc_get_tjmax(cpu);
> ++	if (tj_max < 0)
> ++		return tj_max;
> ++	tj_max *= 1000;
>    
>    	zonedev = kzalloc(sizeof(*zonedev), GFP_KERNEL);
>    	if (!zonedev)
>    		return -ENOMEM;
>    
> + 	zonedev->trips = pkg_temp_thermal_trips_init(cpu, tj_max, thres_count);
> + 	if (IS_ERR(zonedev->trips)) {
> + 		err = PTR_ERR(zonedev->trips);
> + 		goto out_kfree_zonedev;
> + 	}
> +
>    	INIT_DELAYED_WORK(&zonedev->work, pkg_temp_thermal_threshold_work_fn);
>    	zonedev->cpu = cpu;
> - 	zonedev->tzone = thermal_zone_device_register("x86_pkg_temp",
> - 			thres_count,
>   -	zonedev->tj_max = tj_max;
> + 	zonedev->tzone = thermal_zone_device_register_with_trips("x86_pkg_temp",
> + 			zonedev->trips, thres_count,
>    			(thres_count == MAX_NUMBER_OF_TRIPS) ? 0x03 : 0x01,
>    			zonedev, &tzone_ops, &pkg_temp_tz_params, 0, 0);
>    	if (IS_ERR(zonedev->tzone)) {
>

Re: linux-next: manual merge of the thermal tree with the pm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4033 bytes --]

Hi all,

On Thu, 5 Jan 2023 10:10:54 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the thermal tree got a conflict in:
> 
>   drivers/thermal/intel/x86_pkg_temp_thermal.c
> 
> between commit:
> 
>   58374a3970a0 ("thermal/x86_pkg_temp_thermal: Add support for handling dynamic tjmax")
> 
> from the pm tree and commit:
> 
>   03b2e86a24aa ("thermal/drivers/intel: Use generic thermal_zone_get_trip() function")
> 
> from the thermal tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Actually, the resolution I needed was this:

diff --cc drivers/thermal/intel/x86_pkg_temp_thermal.c
index 9e08d8c8f5fb,494f25250c2d..24c7774cc4a9
--- a/drivers/thermal/intel/x86_pkg_temp_thermal.c
+++ b/drivers/thermal/intel/x86_pkg_temp_thermal.c
@@@ -107,56 -108,37 +108,17 @@@ static struct zone_device *pkg_temp_the
  static int sys_get_curr_temp(struct thermal_zone_device *tzd, int *temp)
  {
  	struct zone_device *zonedev = tzd->devdata;
 -	u32 eax, edx;
 +	int val;
  
 -	rdmsr_on_cpu(zonedev->cpu, MSR_IA32_PACKAGE_THERM_STATUS,
 -			&eax, &edx);
 -	if (eax & 0x80000000) {
 -		*temp = zonedev->tj_max - ((eax >> 16) & 0x7f) * 1000;
 -		pr_debug("sys_get_curr_temp %d\n", *temp);
 -		return 0;
 -	}
 -	return -EINVAL;
 +	val = intel_tcc_get_temp(zonedev->cpu, true);
 +	if (val < 0)
 +		return val;
 +
 +	*temp = val * 1000;
 +	pr_debug("sys_get_curr_temp %d\n", *temp);
 +	return 0;
  }
  
- static int sys_get_trip_temp(struct thermal_zone_device *tzd,
- 			     int trip, int *temp)
- {
- 	struct zone_device *zonedev = tzd->devdata;
- 	unsigned long thres_reg_value;
- 	u32 mask, shift, eax, edx;
- 	int tj_max, ret;
- 
- 	if (trip >= MAX_NUMBER_OF_TRIPS)
- 		return -EINVAL;
- 
- 	if (trip) {
- 		mask = THERM_MASK_THRESHOLD1;
- 		shift = THERM_SHIFT_THRESHOLD1;
- 	} else {
- 		mask = THERM_MASK_THRESHOLD0;
- 		shift = THERM_SHIFT_THRESHOLD0;
- 	}
- 
- 	tj_max = intel_tcc_get_tjmax(zonedev->cpu);
- 	if (tj_max < 0)
- 		return tj_max;
- 	tj_max *= 1000;
- 
- 	ret = rdmsr_on_cpu(zonedev->cpu, MSR_IA32_PACKAGE_THERM_INTERRUPT,
- 			   &eax, &edx);
- 	if (ret < 0)
- 		return ret;
- 
- 	thres_reg_value = (eax & mask) >> shift;
- 	if (thres_reg_value)
- 		*temp = tj_max - thres_reg_value * 1000;
- 	else
- 		*temp = THERMAL_TEMP_INVALID;
- 	pr_debug("sys_get_trip_temp %d\n", *temp);
- 
- 	return 0;
- }
- 
  static int
  sys_set_trip_temp(struct thermal_zone_device *tzd, int trip, int temp)
  {
@@@ -330,18 -340,25 +325,25 @@@ static int pkg_temp_thermal_device_add(
  
  	thres_count = clamp_val(thres_count, 0, MAX_NUMBER_OF_TRIPS);
  
- 	err = intel_tcc_get_tjmax(cpu);
- 	if (err < 0)
 -	err = get_tj_max(cpu, &tj_max);
 -	if (err)
--		return err;
++	tj_max = intel_tcc_get_tjmax(cpu);
++	if (tj_max < 0)
++		return tj_max;
++	tj_max *= 1000;
  
  	zonedev = kzalloc(sizeof(*zonedev), GFP_KERNEL);
  	if (!zonedev)
  		return -ENOMEM;
  
+ 	zonedev->trips = pkg_temp_thermal_trips_init(cpu, tj_max, thres_count);
+ 	if (IS_ERR(zonedev->trips)) {
+ 		err = PTR_ERR(zonedev->trips);
+ 		goto out_kfree_zonedev;
+ 	}
+ 
  	INIT_DELAYED_WORK(&zonedev->work, pkg_temp_thermal_threshold_work_fn);
  	zonedev->cpu = cpu;
- 	zonedev->tzone = thermal_zone_device_register("x86_pkg_temp",
- 			thres_count,
 -	zonedev->tj_max = tj_max;
+ 	zonedev->tzone = thermal_zone_device_register_with_trips("x86_pkg_temp",
+ 			zonedev->trips, thres_count,
  			(thres_count == MAX_NUMBER_OF_TRIPS) ? 0x03 : 0x01,
  			zonedev, &tzone_ops, &pkg_temp_tz_params, 0, 0);
  	if (IS_ERR(zonedev->tzone)) {

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the thermal tree with the pm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3511 bytes --]

Hi all,

Today's linux-next merge of the thermal tree got a conflict in:

  drivers/thermal/intel/x86_pkg_temp_thermal.c

between commit:

  58374a3970a0 ("thermal/x86_pkg_temp_thermal: Add support for handling dynamic tjmax")

from the pm tree and commit:

  03b2e86a24aa ("thermal/drivers/intel: Use generic thermal_zone_get_trip() function")

from the thermal tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/thermal/intel/x86_pkg_temp_thermal.c
index 9e08d8c8f5fb,494f25250c2d..000000000000
--- a/drivers/thermal/intel/x86_pkg_temp_thermal.c
+++ b/drivers/thermal/intel/x86_pkg_temp_thermal.c
@@@ -107,56 -108,37 +108,17 @@@ static struct zone_device *pkg_temp_the
  static int sys_get_curr_temp(struct thermal_zone_device *tzd, int *temp)
  {
  	struct zone_device *zonedev = tzd->devdata;
 -	u32 eax, edx;
 +	int val;
  
 -	rdmsr_on_cpu(zonedev->cpu, MSR_IA32_PACKAGE_THERM_STATUS,
 -			&eax, &edx);
 -	if (eax & 0x80000000) {
 -		*temp = zonedev->tj_max - ((eax >> 16) & 0x7f) * 1000;
 -		pr_debug("sys_get_curr_temp %d\n", *temp);
 -		return 0;
 -	}
 -	return -EINVAL;
 +	val = intel_tcc_get_temp(zonedev->cpu, true);
 +	if (val < 0)
 +		return val;
 +
 +	*temp = val * 1000;
 +	pr_debug("sys_get_curr_temp %d\n", *temp);
 +	return 0;
  }
  
- static int sys_get_trip_temp(struct thermal_zone_device *tzd,
- 			     int trip, int *temp)
- {
- 	struct zone_device *zonedev = tzd->devdata;
- 	unsigned long thres_reg_value;
- 	u32 mask, shift, eax, edx;
- 	int tj_max, ret;
- 
- 	if (trip >= MAX_NUMBER_OF_TRIPS)
- 		return -EINVAL;
- 
- 	if (trip) {
- 		mask = THERM_MASK_THRESHOLD1;
- 		shift = THERM_SHIFT_THRESHOLD1;
- 	} else {
- 		mask = THERM_MASK_THRESHOLD0;
- 		shift = THERM_SHIFT_THRESHOLD0;
- 	}
- 
- 	tj_max = intel_tcc_get_tjmax(zonedev->cpu);
- 	if (tj_max < 0)
- 		return tj_max;
- 	tj_max *= 1000;
- 
- 	ret = rdmsr_on_cpu(zonedev->cpu, MSR_IA32_PACKAGE_THERM_INTERRUPT,
- 			   &eax, &edx);
- 	if (ret < 0)
- 		return ret;
- 
- 	thres_reg_value = (eax & mask) >> shift;
- 	if (thres_reg_value)
- 		*temp = tj_max - thres_reg_value * 1000;
- 	else
- 		*temp = THERMAL_TEMP_INVALID;
- 	pr_debug("sys_get_trip_temp %d\n", *temp);
- 
- 	return 0;
- }
- 
  static int
  sys_set_trip_temp(struct thermal_zone_device *tzd, int trip, int temp)
  {
@@@ -338,10 -348,17 +333,16 @@@ static int pkg_temp_thermal_device_add(
  	if (!zonedev)
  		return -ENOMEM;
  
+ 	zonedev->trips = pkg_temp_thermal_trips_init(cpu, tj_max, thres_count);
+ 	if (IS_ERR(zonedev->trips)) {
+ 		err = PTR_ERR(zonedev->trips);
+ 		goto out_kfree_zonedev;
+ 	}
+ 
  	INIT_DELAYED_WORK(&zonedev->work, pkg_temp_thermal_threshold_work_fn);
  	zonedev->cpu = cpu;
- 	zonedev->tzone = thermal_zone_device_register("x86_pkg_temp",
- 			thres_count,
 -	zonedev->tj_max = tj_max;
+ 	zonedev->tzone = thermal_zone_device_register_with_trips("x86_pkg_temp",
+ 			zonedev->trips, thres_count,
  			(thres_count == MAX_NUMBER_OF_TRIPS) ? 0x03 : 0x01,
  			zonedev, &tzone_ops, &pkg_temp_tz_params, 0, 0);
  	if (IS_ERR(zonedev->tzone)) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the thermal tree with the pm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2891 bytes --]

Hi all,

Today's linux-next merge of the thermal tree got a conflict in:

  drivers/thermal/intel/int340x_thermal/processor_thermal_device.c

between commit:

  d91a4714e54e ("thermal/int340x/processor_thermal: Use Intel TCC library")

from the pm tree and commit:

  e503a68ebfe3 ("thermal/intel/int340x: Replace parameter to simplify")

from the thermal tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/thermal/intel/int340x_thermal/processor_thermal_device.c
index a2ea22f2bffd,317703027ce9..000000000000
--- a/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c
+++ b/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c
@@@ -118,22 -174,39 +118,18 @@@ static int proc_thermal_get_zone_temp(s
  	*temp = 0;
  
  	for_each_online_cpu(cpu) {
 -		err = rdmsr_safe_on_cpu(cpu, MSR_IA32_THERM_STATUS, &eax,
 -					&edx);
 -		if (err)
 -			goto err_ret;
 -		else {
 -			if (eax & 0x80000000) {
 -				curr_temp_off = (eax >> 16) & 0x7f;
 -				if (!*temp || curr_temp_off < *temp)
 -					*temp = curr_temp_off;
 -			} else {
 -				err = -EINVAL;
 -				goto err_ret;
 -			}
 -		}
 +		curr_temp = intel_tcc_get_temp(cpu, false);
 +		if (curr_temp < 0)
 +			return curr_temp;
 +		if (!*temp || curr_temp > *temp)
 +			*temp = curr_temp;
  	}
  
 -	return 0;
 -err_ret:
 -	return err;
 -}
 -
 -static int proc_thermal_get_zone_temp(struct thermal_zone_device *zone,
 -					 int *temp)
 -{
 -	int ret;
 -
 -	ret = read_temp_msr(temp);
 -	if (!ret)
 -		*temp = (stored_tjmax - *temp) * 1000;
 +	*temp *= 1000;
  
 -	return ret;
 +	return 0;
  }
  
- static struct thermal_zone_device_ops proc_thermal_local_ops = {
- 	.get_temp       = proc_thermal_get_zone_temp,
- };
- 
  static int proc_thermal_read_ppcc(struct proc_thermal_device *proc_priv)
  {
  	int i;
@@@ -225,11 -298,12 +221,11 @@@ int proc_thermal_add(struct device *dev
  	status = acpi_evaluate_integer(adev->handle, "_TMP", NULL, &tmp);
  	if (ACPI_FAILURE(status)) {
  		/* there is no _TMP method, add local method */
 -		stored_tjmax = get_tjmax();
 -		if (stored_tjmax > 0)
 +		if (intel_tcc_get_tjmax(-1) > 0)
- 			ops = &proc_thermal_local_ops;
+ 			get_temp = proc_thermal_get_zone_temp;
  	}
  
- 	proc_priv->int340x_zone = int340x_thermal_zone_add(adev, ops);
+ 	proc_priv->int340x_zone = int340x_thermal_zone_add(adev, get_temp);
  	if (IS_ERR(proc_priv->int340x_zone)) {
  		return PTR_ERR(proc_priv->int340x_zone);
  	} else

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the thermal tree with the pm tree

[Geert Uytterhoeven]

Hi Daniel,

On Mon, Nov 28, 2022 at 3:08 PM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
> On 28/11/2022 14:48, Bagas Sanjaya wrote:
> > On Mon, Nov 28, 2022 at 02:22:27PM +0100, Daniel Lezcano wrote:
> >> On 28/11/2022 13:51, Rafael J. Wysocki wrote:
> >>> Sorry about this, but I cannot fix it myself and Daniel is on an
> >>> extended leave.
> >>>
> >>> Can you just drop it permanently from linux-next and we'll sort this out
> >>> when Daniel is back?
> >>
> >> Yes sorry for that, I'll go back in a couple of days and sort this out
> >
> > What about the upcoming merge window? At worst Linus has to figure
> > out how to solve this complex conflict when pulling either tree...
> >
> > Linus has already said that there's likely -rc8 of current cycle [1],
> > so we have about two weeks to try sorting out the conflict and be ready
> > for PR to him.
>
> Thanks for the pointer.
>
> I've been quickly through the changes for the thermal tree and I think I
> should be able to sort out most of the patches before the end of this
> week, hopefully. If there are any changes which sound too complex, I'll
> post pone them to the next release

I gave it a try for today's renesas-drivers release.
Does the conflict] resolution in [1] look good to you?

Thanks!

[1] https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/commit/?h=renesas-drivers-2022-11-29-v6.1-rc7&id=9b249c2e655ef25473afbcdae85453c66eb288be

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: linux-next: manual merge of the thermal tree with the pm tree

[Daniel Lezcano]

On 28/11/2022 14:48, Bagas Sanjaya wrote:
> On Mon, Nov 28, 2022 at 02:22:27PM +0100, Daniel Lezcano wrote:
>>
>> Hi,
>>
>> On 28/11/2022 13:51, Rafael J. Wysocki wrote:
>>> Sorry about this, but I cannot fix it myself and Daniel is on an
>>> extended leave.
>>>
>>> Can you just drop it permanently from linux-next and we'll sort this out
>>> when Daniel is back?
>>
>> Yes sorry for that, I'll go back in a couple of days and sort this out
>>
> 
> What about the upcoming merge window? At worst Linus has to figure
> out how to solve this complex conflict when pulling either tree...
> 
> Linus has already said that there's likely -rc8 of current cycle [1],
> so we have about two weeks to try sorting out the conflict and be ready
> for PR to him.

Thanks for the pointer.

I've been quickly through the changes for the thermal tree and I think I 
should be able to sort out most of the patches before the end of this 
week, hopefully. If there are any changes which sound too complex, I'll 
post pone them to the next release

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

Re: linux-next: manual merge of the thermal tree with the pm tree

[Rafael J. Wysocki]

On Mon, Nov 28, 2022 at 2:48 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>
> On Mon, Nov 28, 2022 at 02:22:27PM +0100, Daniel Lezcano wrote:
> >
> > Hi,
> >
> > On 28/11/2022 13:51, Rafael J. Wysocki wrote:
> > > Sorry about this, but I cannot fix it myself and Daniel is on an
> > > extended leave.
> > >
> > > Can you just drop it permanently from linux-next and we'll sort this out
> > > when Daniel is back?
> >
> > Yes sorry for that, I'll go back in a couple of days and sort this out
> >
>
> What about the upcoming merge window? At worst Linus has to figure
> out how to solve this complex conflict when pulling either tree...
>
> Linus has already said that there's likely -rc8 of current cycle [1],
> so we have about two weeks to try sorting out the conflict and be ready
> for PR to him.

As I said before, the thermal tree is merged through the PM tree
anyway, so it needs to be addressed in the thermal tree or worked
around somehow.  Linus will not see this conflict.

Worst-case I can apply patches directly with an ACK from Daniel.

Thanks!

Re: linux-next: manual merge of the thermal tree with the pm tree

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

On Mon, Nov 28, 2022 at 02:22:27PM +0100, Daniel Lezcano wrote:
> 
> Hi,
> 
> On 28/11/2022 13:51, Rafael J. Wysocki wrote:
> > Sorry about this, but I cannot fix it myself and Daniel is on an
> > extended leave.
> > 
> > Can you just drop it permanently from linux-next and we'll sort this out
> > when Daniel is back?
> 
> Yes sorry for that, I'll go back in a couple of days and sort this out
> 

What about the upcoming merge window? At worst Linus has to figure
out how to solve this complex conflict when pulling either tree...

Linus has already said that there's likely -rc8 of current cycle [1],
so we have about two weeks to try sorting out the conflict and be ready
for PR to him.

Thanks.

[1]: https://lore.kernel.org/lkml/CAHk-=wgUZwX8Sbb8Zvm7FxWVfX6CGuE7x+E16VKoqL7Ok9vv7g@mail.gmail.com/

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: linux-next: manual merge of the thermal tree with the pm tree

[Daniel Lezcano]

Hi,

On 28/11/2022 13:51, Rafael J. Wysocki wrote:
> Hi Stephen,
> 
> On 11/28/2022 12:22 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> On Thu, 17 Nov 2022 12:29:04 +1100 Stephen Rothwell 
>> <sfr@canb.auug.org.au> wrote:
>>> Today's linux-next merge of the thermal tree got a conflict in:
>>>
>>>    drivers/thermal/thermal_sysfs.c
>>>
>>> between commit:
>>>
>>>    05eeee2b51b4 ("thermal/core: Protect sysfs accesses to thermal 
>>> operations with thermal zone mutex")
>>>
>>> from the pm tree and commits:
>>>
>>>    dca20ad5acb7 ("thermal/core: Add a generic thermal_zone_get_trip() 
>>> function")
>>>    aed8b46d141c ("thermal/core: Add a generic thermal_zone_set_trip() 
>>> function")
>>>
>>> from the thermal tree.
>>>
>>> This was just too painful to fix up, so please fix it yourselves or
>>> supply me with a resolution.
>>>
>>> I have dropped the thermal tree for today.
>> I am still not merging the thermal tree ...
>>
> Sorry about this, but I cannot fix it myself and Daniel is on an 
> extended leave.
> 
> Can you just drop it permanently from linux-next and we'll sort this out 
> when Daniel is back?

Yes sorry for that, I'll go back in a couple of days and sort this out




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

Re: linux-next: manual merge of the thermal tree with the pm tree

[Rafael J. Wysocki]

Hi Stephen,

On 11/28/2022 12:22 AM, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 17 Nov 2022 12:29:04 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Today's linux-next merge of the thermal tree got a conflict in:
>>
>>    drivers/thermal/thermal_sysfs.c
>>
>> between commit:
>>
>>    05eeee2b51b4 ("thermal/core: Protect sysfs accesses to thermal operations with thermal zone mutex")
>>
>> from the pm tree and commits:
>>
>>    dca20ad5acb7 ("thermal/core: Add a generic thermal_zone_get_trip() function")
>>    aed8b46d141c ("thermal/core: Add a generic thermal_zone_set_trip() function")
>>
>> from the thermal tree.
>>
>> This was just too painful to fix up, so please fix it yourselves or
>> supply me with a resolution.
>>
>> I have dropped the thermal tree for today.
> I am still not merging the thermal tree ...
>
Sorry about this, but I cannot fix it myself and Daniel is on an 
extended leave.

Can you just drop it permanently from linux-next and we'll sort this out 
when Daniel is back?

Thanks,

Rafael

Re: linux-next: manual merge of the thermal tree with the pm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

Hi all,

On Thu, 17 Nov 2022 12:29:04 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the thermal tree got a conflict in:
> 
>   drivers/thermal/thermal_sysfs.c
> 
> between commit:
> 
>   05eeee2b51b4 ("thermal/core: Protect sysfs accesses to thermal operations with thermal zone mutex")
> 
> from the pm tree and commits:
> 
>   dca20ad5acb7 ("thermal/core: Add a generic thermal_zone_get_trip() function")
>   aed8b46d141c ("thermal/core: Add a generic thermal_zone_set_trip() function")
> 
> from the thermal tree.
> 
> This was just too painful to fix up, so please fix it yourselves or
> supply me with a resolution.
> 
> I have dropped the thermal tree for today.

I am still not merging the thermal tree ...

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 484 bytes --]

Re: linux-next: manual merge of the thermal tree with the pm tree

[Rafael J. Wysocki]

Hi Stephen,

On 11/17/2022 2:29 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the thermal tree got a conflict in:
>
>    drivers/thermal/thermal_sysfs.c
>
> between commit:
>
>    05eeee2b51b4 ("thermal/core: Protect sysfs accesses to thermal operations with thermal zone mutex")
>
> from the pm tree and commits:
>
>    dca20ad5acb7 ("thermal/core: Add a generic thermal_zone_get_trip() function")
>    aed8b46d141c ("thermal/core: Add a generic thermal_zone_set_trip() function")
>
> from the thermal tree.
>
> This was just too painful to fix up, so please fix it yourselves or
> supply me with a resolution.
>
> I have dropped the thermal tree for today.
>
 From my perspective, the current material in the thermal tree is work 
in progress and the thermal tree is merged via the pm tree anyway.

So I think that it would be better to merge it into linux-next through 
the linux-next branch of the pm tree as a general rule.

In my view the material from Guenter is important bug fixes and it takes 
precedence over any cleanups and new code.

In any case, sorry for the trouble.

linux-next: manual merge of the thermal tree with the pm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

Hi all,

Today's linux-next merge of the thermal tree got a conflict in:

  drivers/thermal/thermal_sysfs.c

between commit:

  05eeee2b51b4 ("thermal/core: Protect sysfs accesses to thermal operations with thermal zone mutex")

from the pm tree and commits:

  dca20ad5acb7 ("thermal/core: Add a generic thermal_zone_get_trip() function")
  aed8b46d141c ("thermal/core: Add a generic thermal_zone_set_trip() function")

from the thermal tree.

This was just too painful to fix up, so please fix it yourselves or
supply me with a resolution.

I have dropped the thermal tree for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the thermal tree with the pm tree

[Zhang Rui]

Hi, Stephen,

On Fri, 2014-10-10 at 12:10 +1100, Stephen Rothwell wrote:
> Hi Zhang,
> 
> Today's linux-next merge of the thermal tree got a conflict in
> drivers/acpi/fan.c between commit 88989fd26a74 ("ACPI / fan: printk
> replacement") from the pm tree and commits 71532a58d2b0 ("ACPI / fan:
> remove unused macro") and ff39c76855e8 ("ACPI / fan: convert to
> platform driver") from the thermal tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
thanks a lot for your patch, I don't know why but it seems that you
missed one conflict? how about the patch below?

thanks,
rui

diff --cc drivers/acpi/fan.c
index e007c49,5328b10..e0ba2af
--- a/drivers/acpi/fan.c
+++ b/drivers/acpi/fan.c
@@@ -27,11 -27,15 +27,11 @@@
  #include <linux/module.h>
  #include <linux/init.h>
  #include <linux/types.h>
- #include <asm/uaccess.h>
+ #include <linux/uaccess.h>
  #include <linux/thermal.h>
  #include <linux/acpi.h>
 -
 -#define ACPI_FAN_CLASS			"fan"
 -#define ACPI_FAN_FILE_STATE		"state"
 -
 -#define _COMPONENT		ACPI_FAN_COMPONENT
 -ACPI_MODULE_NAME("fan");
 +#include <linux/platform_device.h>
 +#include <linux/sort.h>
  
  MODULE_AUTHOR("Paul Diefenbaugh");
  MODULE_DESCRIPTION("ACPI Fan Driver");
@@@ -221,128 -125,25 +221,129 @@@ static const struct thermal_cooling_dev
  };
  
  /* --------------------------------------------------------------------------
-                                  Driver Interface
-    -------------------------------------------------------------------------- */
+  *                               Driver Interface
+  * --------------------------------------------------------------------------
+ */
  
 -static int acpi_fan_add(struct acpi_device *device)
 +static bool acpi_fan_is_acpi4(struct acpi_device *device)
  {
 -	int result = 0;
 -	struct thermal_cooling_device *cdev;
 +	return acpi_has_method(device->handle, "_FIF") &&
 +	       acpi_has_method(device->handle, "_FPS") &&
 +	       acpi_has_method(device->handle, "_FSL") &&
 +	       acpi_has_method(device->handle, "_FST");
 +}
  
 -	if (!device)
 -		return -EINVAL;
 +static int acpi_fan_get_fif(struct acpi_device *device)
 +{
 +	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
 +	struct acpi_fan *fan = acpi_driver_data(device);
 +	struct acpi_buffer format = { sizeof("NNNN"), "NNNN" };
 +	struct acpi_buffer fif = { sizeof(fan->fif), &fan->fif };
 +	union acpi_object *obj;
 +	acpi_status status;
 +
 +	status = acpi_evaluate_object(device->handle, "_FIF", NULL, &buffer);
 +	if (ACPI_FAILURE(status))
 +		return status;
 +
 +	obj = buffer.pointer;
 +	if (!obj || obj->type != ACPI_TYPE_PACKAGE) {
 +		dev_err(&device->dev, "Invalid _FIF data\n");
 +		status = -EINVAL;
 +		goto err;
 +	}
  
 -	strcpy(acpi_device_name(device), "Fan");
 -	strcpy(acpi_device_class(device), ACPI_FAN_CLASS);
 +	status = acpi_extract_package(obj, &format, &fif);
 +	if (ACPI_FAILURE(status)) {
 +		dev_err(&device->dev, "Invalid _FIF element\n");
 +		status = -EINVAL;
 +	}
  
 -	result = acpi_bus_update_power(device->handle, NULL);
 -	if (result) {
 -		dev_err(&device->dev, "Setting initial power state\n");
 -		goto end;
 +err:
 +	kfree(obj);
 +	return status;
 +}
 +
 +static int acpi_fan_speed_cmp(const void *a, const void *b)
 +{
 +	const struct acpi_fan_fps *fps1 = a;
 +	const struct acpi_fan_fps *fps2 = b;
 +	return fps1->speed - fps2->speed;
 +}
 +
 +static int acpi_fan_get_fps(struct acpi_device *device)
 +{
 +	struct acpi_fan *fan = acpi_driver_data(device);
 +	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
 +	union acpi_object *obj;
 +	acpi_status status;
 +	int i;
 +
 +	status = acpi_evaluate_object(device->handle, "_FPS", NULL, &buffer);
 +	if (ACPI_FAILURE(status))
 +		return status;
 +
 +	obj = buffer.pointer;
 +	if (!obj || obj->type != ACPI_TYPE_PACKAGE || obj->package.count < 2) {
 +		dev_err(&device->dev, "Invalid _FPS data\n");
 +		status = -EINVAL;
 +		goto err;
 +	}
 +
 +	fan->fps_count = obj->package.count - 1; /* minus revision field */
 +	fan->fps = devm_kzalloc(&device->dev,
 +				fan->fps_count * sizeof(struct acpi_fan_fps),
 +				GFP_KERNEL);
 +	if (!fan->fps) {
 +		dev_err(&device->dev, "Not enough memory\n");
 +		status = -ENOMEM;
 +		goto err;
 +	}
 +	for (i = 0; i < fan->fps_count; i++) {
 +		struct acpi_buffer format = { sizeof("NNNNN"), "NNNNN" };
 +		struct acpi_buffer fps = { sizeof(fan->fps[i]), &fan->fps[i] };
 +		status = acpi_extract_package(&obj->package.elements[i + 1],
 +					      &format, &fps);
 +		if (ACPI_FAILURE(status)) {
 +			dev_err(&device->dev, "Invalid _FPS element\n");
 +			break;
 +		}
 +	}
 +
 +	/* sort the state array according to fan speed in increase order */
 +	sort(fan->fps, fan->fps_count, sizeof(*fan->fps),
 +	     acpi_fan_speed_cmp, NULL);
 +
 +err:
 +	kfree(obj);
 +	return status;
 +}
 +
 +static int acpi_fan_probe(struct platform_device *pdev)
 +{
 +	int result = 0;
 +	struct thermal_cooling_device *cdev;
 +	struct acpi_fan *fan;
 +	struct acpi_device *device = ACPI_COMPANION(&pdev->dev);
 +
 +	fan = devm_kzalloc(&pdev->dev, sizeof(*fan), GFP_KERNEL);
 +	if (!fan) {
 +		dev_err(&device->dev, "No memory for fan\n");
 +		return -ENOMEM;
 +	}
 +	device->driver_data = fan;
 +	platform_set_drvdata(pdev, fan);
 +
 +	if (acpi_fan_is_acpi4(device)) {
 +		if (acpi_fan_get_fif(device) || acpi_fan_get_fps(device))
 +			goto end;
 +		fan->acpi4 = true;
 +	} else {
 +		result = acpi_device_update_power(device, NULL);
 +		if (result) {
 +			dev_err(&device->dev, "Setting initial power state\n");
 +			goto end;
 +		}
  	}
  
  	cdev = thermal_cooling_device_register("Fan", device,
@@@ -363,12 -164,15 +364,11 @@@
  			"'thermal_cooling'\n");
  
  	result = sysfs_create_link(&cdev->device.kobj,
 -				   &device->dev.kobj,
 +				   &pdev->dev.kobj,
  				   "device");
  	if (result)
- 		dev_err(&pdev->dev, "Failed to create sysfs link "
- 			"'device'\n");
+ 		dev_err(&device->dev, "Failed to create sysfs link 'device'\n");
  
 -	dev_info(&device->dev, "ACPI: %s [%s] (%s)\n",
 -	       acpi_device_name(device), acpi_device_bid(device),
 -	       !device->power.state ? "on" : "off");
 -
  end:
  	return result;
  }

linux-next: manual merge of the thermal tree with the pm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 5686 bytes --]

Hi Zhang,

Today's linux-next merge of the thermal tree got a conflict in
drivers/acpi/fan.c between commit 88989fd26a74 ("ACPI / fan: printk
replacement") from the pm tree and commits 71532a58d2b0 ("ACPI / fan:
remove unused macro") and ff39c76855e8 ("ACPI / fan: convert to
platform driver") from the thermal tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/acpi/fan.c
index 5328b1090e08,e007c4987bea..000000000000
--- a/drivers/acpi/fan.c
+++ b/drivers/acpi/fan.c
@@@ -27,15 -27,11 +27,11 @@@
  #include <linux/module.h>
  #include <linux/init.h>
  #include <linux/types.h>
 -#include <asm/uaccess.h>
 +#include <linux/uaccess.h>
  #include <linux/thermal.h>
  #include <linux/acpi.h>
- 
- #define ACPI_FAN_CLASS			"fan"
- #define ACPI_FAN_FILE_STATE		"state"
- 
- #define _COMPONENT		ACPI_FAN_COMPONENT
- ACPI_MODULE_NAME("fan");
+ #include <linux/platform_device.h>
+ #include <linux/sort.h>
  
  MODULE_AUTHOR("Paul Diefenbaugh");
  MODULE_DESCRIPTION("ACPI Fan Driver");
@@@ -125,25 -221,128 +221,129 @@@ static const struct thermal_cooling_dev
  };
  
  /* --------------------------------------------------------------------------
 -                                 Driver Interface
 -   -------------------------------------------------------------------------- */
 + *                               Driver Interface
 + * --------------------------------------------------------------------------
 +*/
  
- static int acpi_fan_add(struct acpi_device *device)
+ static bool acpi_fan_is_acpi4(struct acpi_device *device)
  {
- 	int result = 0;
- 	struct thermal_cooling_device *cdev;
+ 	return acpi_has_method(device->handle, "_FIF") &&
+ 	       acpi_has_method(device->handle, "_FPS") &&
+ 	       acpi_has_method(device->handle, "_FSL") &&
+ 	       acpi_has_method(device->handle, "_FST");
+ }
  
- 	if (!device)
- 		return -EINVAL;
+ static int acpi_fan_get_fif(struct acpi_device *device)
+ {
+ 	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+ 	struct acpi_fan *fan = acpi_driver_data(device);
+ 	struct acpi_buffer format = { sizeof("NNNN"), "NNNN" };
+ 	struct acpi_buffer fif = { sizeof(fan->fif), &fan->fif };
+ 	union acpi_object *obj;
+ 	acpi_status status;
+ 
+ 	status = acpi_evaluate_object(device->handle, "_FIF", NULL, &buffer);
+ 	if (ACPI_FAILURE(status))
+ 		return status;
+ 
+ 	obj = buffer.pointer;
+ 	if (!obj || obj->type != ACPI_TYPE_PACKAGE) {
+ 		dev_err(&device->dev, "Invalid _FIF data\n");
+ 		status = -EINVAL;
+ 		goto err;
+ 	}
  
- 	strcpy(acpi_device_name(device), "Fan");
- 	strcpy(acpi_device_class(device), ACPI_FAN_CLASS);
+ 	status = acpi_extract_package(obj, &format, &fif);
+ 	if (ACPI_FAILURE(status)) {
+ 		dev_err(&device->dev, "Invalid _FIF element\n");
+ 		status = -EINVAL;
+ 	}
  
- 	result = acpi_bus_update_power(device->handle, NULL);
- 	if (result) {
- 		dev_err(&device->dev, "Setting initial power state\n");
- 		goto end;
+ err:
+ 	kfree(obj);
+ 	return status;
+ }
+ 
+ static int acpi_fan_speed_cmp(const void *a, const void *b)
+ {
+ 	const struct acpi_fan_fps *fps1 = a;
+ 	const struct acpi_fan_fps *fps2 = b;
+ 	return fps1->speed - fps2->speed;
+ }
+ 
+ static int acpi_fan_get_fps(struct acpi_device *device)
+ {
+ 	struct acpi_fan *fan = acpi_driver_data(device);
+ 	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+ 	union acpi_object *obj;
+ 	acpi_status status;
+ 	int i;
+ 
+ 	status = acpi_evaluate_object(device->handle, "_FPS", NULL, &buffer);
+ 	if (ACPI_FAILURE(status))
+ 		return status;
+ 
+ 	obj = buffer.pointer;
+ 	if (!obj || obj->type != ACPI_TYPE_PACKAGE || obj->package.count < 2) {
+ 		dev_err(&device->dev, "Invalid _FPS data\n");
+ 		status = -EINVAL;
+ 		goto err;
+ 	}
+ 
+ 	fan->fps_count = obj->package.count - 1; /* minus revision field */
+ 	fan->fps = devm_kzalloc(&device->dev,
+ 				fan->fps_count * sizeof(struct acpi_fan_fps),
+ 				GFP_KERNEL);
+ 	if (!fan->fps) {
+ 		dev_err(&device->dev, "Not enough memory\n");
+ 		status = -ENOMEM;
+ 		goto err;
+ 	}
+ 	for (i = 0; i < fan->fps_count; i++) {
+ 		struct acpi_buffer format = { sizeof("NNNNN"), "NNNNN" };
+ 		struct acpi_buffer fps = { sizeof(fan->fps[i]), &fan->fps[i] };
+ 		status = acpi_extract_package(&obj->package.elements[i + 1],
+ 					      &format, &fps);
+ 		if (ACPI_FAILURE(status)) {
+ 			dev_err(&device->dev, "Invalid _FPS element\n");
+ 			break;
+ 		}
+ 	}
+ 
+ 	/* sort the state array according to fan speed in increase order */
+ 	sort(fan->fps, fan->fps_count, sizeof(*fan->fps),
+ 	     acpi_fan_speed_cmp, NULL);
+ 
+ err:
+ 	kfree(obj);
+ 	return status;
+ }
+ 
+ static int acpi_fan_probe(struct platform_device *pdev)
+ {
+ 	int result = 0;
+ 	struct thermal_cooling_device *cdev;
+ 	struct acpi_fan *fan;
+ 	struct acpi_device *device = ACPI_COMPANION(&pdev->dev);
+ 
+ 	fan = devm_kzalloc(&pdev->dev, sizeof(*fan), GFP_KERNEL);
+ 	if (!fan) {
+ 		dev_err(&device->dev, "No memory for fan\n");
+ 		return -ENOMEM;
+ 	}
+ 	device->driver_data = fan;
+ 	platform_set_drvdata(pdev, fan);
+ 
+ 	if (acpi_fan_is_acpi4(device)) {
+ 		if (acpi_fan_get_fif(device) || acpi_fan_get_fps(device))
+ 			goto end;
+ 		fan->acpi4 = true;
+ 	} else {
+ 		result = acpi_device_update_power(device, NULL);
+ 		if (result) {
+ 			dev_err(&device->dev, "Setting initial power state\n");
+ 			goto end;
+ 		}
  	}
  
  	cdev = thermal_cooling_device_register("Fan", device,

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]