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)) {
Hi all,
On Thu, 5 Jan 2023 10:10:54 +1100 Stephen Rothwell <[email protected]> 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
On 1/5/2023 12:35 AM, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 5 Jan 2023 10:10:54 +1100 Stephen Rothwell <[email protected]> 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)) {
>
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
>> <[email protected]> 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
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
>>> <[email protected]> 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!