Hi, Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git for-
5.4
to receive the latest Thermal Management updates for v5.4-rc1 with
top-most commit 0f84d1d18c46d0f995962c876c8b2900fd183fd7:
Merge branches 'thermal-core', 'thermal-intel' and 'thermal-soc' into
for-5.4 (2019-09-24 09:56:37 +0800)
on top of commit d1abaeb3be7b5fa6d7a1fbbd2e14e3310005c4c1:
Linux 5.3-rc5 (2019-08-18 14:31:08 -0700)
One thing to mention is that, all the patches have been tested in
linux-next for weeks, but there is a conflict detected, because
upstream has took commit eaf7b46083a7e34 ("docs: thermal: add it to the
driver API") from jc-docs tree while I'm keeping a wrong version of the
patch, so I just rebased my tree to fix this.
Specifics:
- Add Amit Kucheria as thermal subsystem Reviewer. (Amit Kucheria)
- Fix a use after free bug when unregistering thermal zone devices.
(Ido Schimmel)
- Fix thermal core framework to use put_device() when
device_register() fails. (Yue Hu)
- Enable intel_pch_thermal and MMIO RAPL support for Intel Icelake
platform. (Srinivas Pandruvada)
- Add clock operations in qorip thermal driver, for some platforms
with clock control like i.MX8MQ. (Anson Huang)
- A couple of trivial fixes and cleanups for thermal core and
different soc thermal drivers.(Amit Kucheria, Christophe
JAILLET, Chuhong Yuan, Fuqian Huang, Kelsey Skunberg, Nathan
Huckleberry, Rishi Gupta, Srinivas Kandagatla)
thanks,
rui
----------------------------------------------------------------
Amit Kucheria (2):
thermal: Add some error messages
MAINTAINERS: Add Amit Kucheria as reviewer for thermal
Anson Huang (5):
thermal: qoriq: Add clock operations
thermal: qoriq: Fix error path of calling
qoriq_tmu_register_tmu_zone fail
thermal: qoriq: Use devm_platform_ioremap_resource() instead of
of_iomap()
thermal: qoriq: Use __maybe_unused instead of #if CONFIG_PM_SLEEP
dt-bindings: thermal: qoriq: Add optional clocks property
Christophe JAILLET (1):
thermal: tegra: Fix a typo
Chuhong Yuan (1):
thermal: intel: Use dev_get_drvdata
Fuqian Huang (1):
thermal: rcar_gen3_thermal: Replace devm_add_action() followed by
failure action with devm_add_action_or_reset()
Ido Schimmel (1):
thermal: Fix use-after-free when unregistering thermal zone
device
Kelsey Skunberg (1):
thermal: intel: int340x_thermal: Remove unnecessary
acpi_has_method() uses
Nathan Huckleberry (1):
thermal: armada: Fix -Wshift-negative-value
Rishi Gupta (1):
thermal: intel: int3403: replace printk(KERN_WARN...) with
pr_warn(...)
Srinivas Kandagatla (1):
drivers: thermal: qcom: tsens: Fix memory leak from qfprom read
Srinivas Pandruvada (2):
drivers: thermal: processor_thermal_device: Export sysfs
interface for TCC offset
thermal: int340x: processor_thermal: Add Ice Lake support
Stefan Mavrodiev (1):
thermal_hwmon: Sanitize thermal_zone type
Yue Hu (1):
thermal/drivers/core: Use put_device() if device_register() fails
Zhang Rui (2):
Merge branches 'thermal-soc-misc' and 'thermal-soc-qoriq' into
thermal-soc
Merge branches 'thermal-core', 'thermal-intel' and 'thermal-soc'
into for-5.4
.../devicetree/bindings/thermal/qoriq-thermal.txt | 1 +
MAINTAINERS | 1 +
drivers/thermal/armada_thermal.c | 5 +-
.../intel/int340x_thermal/acpi_thermal_rel.c | 6 --
.../intel/int340x_thermal/int3403_thermal.c | 2 +-
.../int340x_thermal/processor_thermal_device.c | 96
+++++++++++++++++++++-
drivers/thermal/intel/intel_pch_thermal.c | 6 +-
drivers/thermal/qcom/tsens-8960.c | 2 +
drivers/thermal/qcom/tsens-v0_1.c | 12 ++-
drivers/thermal/qcom/tsens-v1.c | 1 +
drivers/thermal/qcom/tsens.h | 1 +
drivers/thermal/qoriq_thermal.c | 45 ++++++----
drivers/thermal/rcar_gen3_thermal.c | 3 +-
drivers/thermal/tegra/soctherm.c | 2 +-
drivers/thermal/thermal_core.c | 44 ++++++----
drivers/thermal/thermal_hwmon.c | 8 +-
16 files changed, 178 insertions(+), 57 deletions(-)
On Fri, Sep 27, 2019 at 6:08 AM Zhang Rui <[email protected]> wrote:
>
> One thing to mention is that, all the patches have been tested in
> linux-next for weeks, but there is a conflict detected, because
> upstream has took commit eaf7b46083a7e34 ("docs: thermal: add it to the
> driver API") from jc-docs tree while I'm keeping a wrong version of the
> patch, so I just rebased my tree to fix this.
Why do I have to say this EVERY single release?
A conflict is not a reason to rebase. Conflicts happen. They happen a
lot. I deal with them, and it's usually trivial.
If you feel it's not trivial, just describe what the resolution is,
rather than rebasing. Really.
Rebasing for a random conflict (particularly in documentation, for
chrissake!) is like using an atomic bomb to swat a fly. You have all
those downsides, and there are basically _no_ upsides. It only makes
for more work for me because I have to re-write this email for the
millionth time, and that takes longer and is more aggravating than the
conflict would have taken to just sort out.
Linus
On Fri, 2019-09-27 at 11:34 -0700, Linus Torvalds wrote:
> On Fri, Sep 27, 2019 at 6:08 AM Zhang Rui <[email protected]> wrote:
> > One thing to mention is that, all the patches have been tested in
> > linux-next for weeks, but there is a conflict detected, because
> > upstream has took commit eaf7b46083a7e34 ("docs: thermal: add it to
> > the
> > driver API") from jc-docs tree while I'm keeping a wrong version of
> > the
> > patch, so I just rebased my tree to fix this.
>
> Why do I have to say this EVERY single release?
Because there are literally thousands of developers working on kernel
bits here and there, and you're swatting this particular fly one
developer at a time.
I might suggest that you need to speak with the git people and politely
ask them to add a warning to the rebase command itself so that it prints
out something like:
----
If you are doing linux kernel development, and you are doing a rebase,
please read Documentation/When_Not_To_Rebase.rst before rebasing your
code and sending it to Linus. You've been warned.
Acknowledge receipt of warning and proceed with rebase? (y/N)
----
You would have free reign to put one of your more monumental yet funny
rants in place in the documentation.
You could also have a global git config to turn off the "Don't annoy
Linus with rebases" warning. But only mention that global config at the
end of the kernel documentation so you know people have read it before
they turn the warning off.
Maybe that would help.
> A conflict is not a reason to rebase. Conflicts happen. They happen a
> lot. I deal with them, and it's usually trivial.
>
> If you feel it's not trivial, just describe what the resolution is,
> rather than rebasing. Really.
>
> Rebasing for a random conflict (particularly in documentation, for
> chrissake!) is like using an atomic bomb to swat a fly. You have all
> those downsides, and there are basically _no_ upsides. It only makes
> for more work for me because I have to re-write this email for the
> millionth time, and that takes longer and is more aggravating than the
> conflict would have taken to just sort out.
>
> Linus
--
Doug Ledford <[email protected]>
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
On Fri, Sep 27, 2019 at 12:29 PM Doug Ledford <[email protected]> wrote:
>
> Because there are literally thousands of developers working on kernel
> bits here and there, and you're swatting this particular fly one
> developer at a time.
Well, at least these days it's also very clearly spelled out in the
Documentation directory.
And the "don't rebase" does get posted on the mailing lists each time,
and I've mentioned it over the years in my release notes too.
Besides, I actually only work with about a hundred top-level
maintainers, not thousands. Yes, we have thousands of developers, but
doing the stats over the 5.0 releases, there have been "only" 131
people sending me pull requests. Sure, more than a couple, but at the
same time it's not like this is a "every developer" kind of thing,
this is literally subsystem maintainers. We've got a fair number of
them, but it's definitely not about thousands.
I feel like I've sent that email out way more than a hundred times
over the last 15+ years.
.. and I don't think having git warn is right, since rebasing is
perfectly fine as you are doing development.
It's really just that maintainers shouldn't do it for bad reasons and
at bad times.
And "there was a conflict" and "yesterday" is really one of the
absolute worst reasons/times around.
Linus
On Fri, Sep 27, 2019 at 9:30 PM Doug Ledford <[email protected]> wrote:
> Because there are literally thousands of developers working on kernel
> bits here and there, and you're swatting this particular fly one
> developer at a time.
I strongly disagree. One of the golden rules of kernel development is,
read what Linus writes. Especially during the merge window.
Thanks,
//richard
On Fri, 2019-09-27 at 12:41 -0700, Linus Torvalds wrote:
> On Fri, Sep 27, 2019 at 12:29 PM Doug Ledford <[email protected]>
> wrote:
> > Because there are literally thousands of developers working on
> > kernel
> > bits here and there, and you're swatting this particular fly one
> > developer at a time.
>
> Well, at least these days it's also very clearly spelled out in the
> Documentation directory.
Yeah, but let's be fair. How many people read the documentation fully?
Or even if some new maintainer read it, did it really sink in? Or will
they rebase a year later not thinking about it?
> And the "don't rebase" does get posted on the mailing lists each time,
> and I've mentioned it over the years in my release notes too.
Lots of people here and there miss those things. You never know who
caught what.
> Besides, I actually only work with about a hundred top-level
> maintainers, not thousands. Yes, we have thousands of developers, but
> doing the stats over the 5.0 releases, there have been "only" 131
> people sending me pull requests. Sure, more than a couple, but at the
> same time it's not like this is a "every developer" kind of thing,
> this is literally subsystem maintainers. We've got a fair number of
> them, but it's definitely not about thousands.
>
> I feel like I've sent that email out way more than a hundred times
> over the last 15+ years.
I'm sure you probably have. I think I got it two or three times before
I got all the nuances of which rebases were OK and which weren't :-).
> .. and I don't think having git warn is right, since rebasing is
> perfectly fine as you are doing development.
>
> It's really just that maintainers shouldn't do it for bad reasons and
> at bad times.
>
> And "there was a conflict" and "yesterday" is really one of the
> absolute worst reasons/times around.
I think you send it out a lot because it doesn't get driven home in
people's heads until they get yelled at. And there's more to the
badness of a rebase than just annoying you when you want to see the
conflicts to judge things for yourself. There are legitimate issues
such as a rebase wipes out history. Or if you rebase a public tree it
blows up everyone that is tracking that branch. These things apply even
to when you are doing your own development. Or rebases might wipe out
merge commits from other trees, depending on options.
A git warning solely for you might not truly be appropriate, but I'm not
at all convinced that a git warning with a more general "Here are the
pros and cons of rebases, with a list of dos and donts if you are going
to do a rebase" document is a bad idea, and might actually help you out
too.
--
Doug Ledford <[email protected]>
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
On Fri, 2019-09-27 at 21:52 +0200, Richard Weinberger wrote:
> On Fri, Sep 27, 2019 at 9:30 PM Doug Ledford <[email protected]>
> wrote:
> > Because there are literally thousands of developers working on
> > kernel
> > bits here and there, and you're swatting this particular fly one
> > developer at a time.
>
> I strongly disagree. One of the golden rules of kernel development is,
> read what Linus writes. Especially during the merge window.
>
> Thanks,
> //richard
Developers come and go. Your argument is temporally flawed. A
developer might start working on the tree, read everything during a
merge window, and not catch one of Linus' rebase rants prior to
committing a rebase felony of their own.
Besides, I don't think this rule of yours is all that universal. If
Linus is off on a thread about arm64 device tree brokenness and someone
does a rebase and he rants about it, I'm very likely to miss that rant.
I read what I reasonably deem to be relevant to me and my work, or
sometimes additional stuff that just jumps out at me. But I never
learned to speed read so I don't even try to read it all and wouldn't
agree to a rule that says I have to.
--
Doug Ledford <[email protected]>
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
Hi, Linus,
I'm really sorry about this.
I thought no code change could be a reason that a rebase can be
accepted, but didn't realize this is exactly the case we should avoid
it. I wish I could read Documentation/maintainer/rebasing-and-
merging.rst earlier so that I didn't make this mistake.
Sorry to bring this trouble.
thanks,
rui
On Fri, 2019-09-27 at 11:34 -0700, Linus Torvalds wrote:
> On Fri, Sep 27, 2019 at 6:08 AM Zhang Rui <[email protected]>
> wrote:
> >
> > One thing to mention is that, all the patches have been tested in
> > linux-next for weeks, but there is a conflict detected, because
> > upstream has took commit eaf7b46083a7e34 ("docs: thermal: add it to
> > the
> > driver API") from jc-docs tree while I'm keeping a wrong version of
> > the
> > patch, so I just rebased my tree to fix this.
>
> Why do I have to say this EVERY single release?
>
> A conflict is not a reason to rebase. Conflicts happen. They happen a
> lot. I deal with them, and it's usually trivial.
>
> If you feel it's not trivial, just describe what the resolution is,
> rather than rebasing. Really.
>
> Rebasing for a random conflict (particularly in documentation, for
> chrissake!) is like using an atomic bomb to swat a fly. You have all
> those downsides, and there are basically _no_ upsides. It only makes
> for more work for me because I have to re-write this email for the
> millionth time, and that takes longer and is more aggravating than
> the
> conflict would have taken to just sort out.
>
> Linus
On Fri, 27 Sep 2019 15:29:47 -0400
Doug Ledford <[email protected]> wrote:
> If you are doing linux kernel development, and you are doing a rebase,
> please read Documentation/When_Not_To_Rebase.rst before rebasing your
> code and sending it to Linus. You've been warned.
For anybody following along at home, the proper spelling for that is
Documentation/maintainer/rebasing-and-merging.txt or
https://www.kernel.org/doc/html/latest/maintainer/rebasing-and-merging.html
jon