Thanks for Reviewing, On Fri, Oct 21, 2022 at 7:54 PM Timo Aaltonen <[email protected]> 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 <[email protected]> > 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 > -- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
