Req: thermald special case

[Koba Ko]

Thanks for Reviewing,

On Fri, Oct 21, 2022 at 7:54 PM Timo Aaltonen <tjaalton at ubuntu.com> wrote:
>
>
> Hi,
>
> Thanks for looking into this,
>
> Robie Basak kirjoitti 19.10.2022 klo 19.55:
> > On Tue, Oct 11, 2022 at 09:58:36AM +0300, Timo Aaltonen wrote:
> >> Christopher James Halse Rogers kirjoitti 28.9.2022 klo 10.07:
> >>> It's not entirely clear to me what you want to do here.
> >>>
> >>> If you need to fix some bugs in Jammy, and updating to thermald 2.5.0 is
> >>> basically the same as applying all the patches you'd need, then you can
> >>> just upload 2.5.0 and justify it in the SRU bug.
> >
> >> I've uploaded a backported thermald to jammy queue, anyone willing to have a
> >> look? Focal is next once this is accepted.
> >
> > This upload seems to contain various changes that aren't covered by SRU
> > bugs - for example to consider the risk of regression in changing that
> > code, or how you plan to test those fixes. So I don't think this fits
> > the conditions that Christopher noted above.
>  >
> > If you want to update thermald with a major version bump on the basis of
> > hardware enablement for new hardware, then that would be justifiable as
> > an SRU under existing policy, but we need to ensure that we do not
> > regress existing hardware or functionality.
> >
> > https://wiki.ubuntu.com/StableReleaseUpdates/thermald provides some
> > justification there, but I don't think it's complete. For example, is it
> > possible that users are using thermald on hardware not covered by
> > upstream tests? By "all the unit tests must pass in all the supported
> > Intel CPUs", who defines "supported"? Is it possible that Ubuntu users
> > have hardware not covered by that definition of "supported"? Is there
> > any risk to users of non-Intel hardware? How complete is upstream's test
> > coverage? What assurance is there that there will be no feature
> > regressions?
> >
> > For example, take the following upstream commit, which I think is being
> > included in this proposed SRU:
> >
> > https://github.com/intel/thermal_daemon/commit/7e490fc79d784b3faf8314af98ec14981ba7fb75
> >
> > If this code path was being used previously, I think that would be a
> > functional regression. 1) Is this safe in relation to Ubuntu kernel
> > versions? 2) Did this actually get checked before upload? 3) What in
> > your proposed QA process would catch this kind of change to ensure that
> > the specific requirements for each such deprecation is met in Ubuntu
> > stable releases?
> I'll let Koba comment on the other points, but the sysfs interface has
> been in the kernel since 5.3:
>
> commit fdf4f2fb8e8990c131b2b1a5a9c03681bb16e87a
> Author: Srinivas Pandruvada <srinivas.pandruvada at linux.intel.com>
> Date:   Mon Jul 22 18:03:02 2019 -0700
>
>      drivers: thermal: processor_thermal_device: Export sysfs interface
> for TCC offset
>
>
> so a backport to focal (which is planned) should be safe in that regard.

TCC adjustment has been offloaded to kernel driver intel_tcc_cooling,
it's registered as a thermal cooling device.
2eb87d75f980)     thermal/drivers/intel: Introduce tcc cooling driver.
This was merged to mainline since 5.13. Focal is using hwe-5.15.
Ref. https://www.phoronix.com/news/Linux-5.13-Intel-Cooling-Driver

'Supported CPU', I must modify it to the more recent CPUs.
e.g. ICL/CML/TGL/ADL,
There's a table, supported_ids_t id_table, in src/thd_engine.cpp.
Thermald doesn't support any non-Intel platform
Even if you fire it, thermald won't work.
>
>
> --
> t
>