Hi Greg, Sasha and all,
This is a resubmit of the patches already done in
https://lore.kernel.org/stable/20201125201215.26455-1-carnil@debian.org/
and
https://lore.kernel.org/stable/20201125201215.26455-2-carnil@debian.org/
The issue can be explained as this. In
https://lore.kernel.org/stable/20201014135627.GA3698844@kroah.com/
on request 168200b6d6ea ("perf cs-etm: Move definition of 'traceid_list' global
variable from header file") was queued back to 4.19.y to fix build failures for
perf with more recent GCCs.
But for 4.19.y this was wrong because it missed to pick as well a dependency
needed, and in turn it caused build failures with older GCC (8.3.0 as used in
Debian stable in that case).
The commit was reverted in a later in 4.19.159.
It as though requested to try to allow as well compilation with more recent
GCCs (while obviously not breaking older GCC builds) and found that the cause
was just the missing dependency to pick up, namely pick 95c6fe970a01 ("perf
cs-etm: Change tuple from traceID-CPU# to traceID-metadata") before
168200b6d6ea ("perf cs-etm: Move definition of 'traceid_list' global variable
from header file").
Regards,
Salvatore
Leo Yan (2):
perf cs-etm: Change tuple from traceID-CPU# to traceID-metadata
perf cs-etm: Move definition of 'traceid_list' global variable from
header file
.../perf/util/cs-etm-decoder/cs-etm-decoder.c | 8 ++---
tools/perf/util/cs-etm.c | 29 +++++++++++++++----
tools/perf/util/cs-etm.h | 10 +++++--
3 files changed, 33 insertions(+), 14 deletions(-)
--
2.30.0.rc2
Hi Greg & Sasha,
please apply commit 0a4e668b5d52 ("hwmon: (k10temp) Remove support for displaying
voltage and current on Zen CPUs") to v5.10.y.
I used to think that it was a good idea to report CPU voltage and current for Zen
CPUs, but due to lack of documentation this is all but impossible to maintain.
Better to get rid of it entirely. I would like to have the patch applied
to v5.10.y because that is a LTS kernel, and I don't want to be bugged
forever with "values are incorrect" reports.
Thanks,
Guenter
On Wed, Dec 09, 2020 at 03:38:11PM +0000, Barnabás Pőcze wrote:
> 2020. december 9., szerda 8:00 keltezéssel, Greg KH írta:
>
> > On Tue, Dec 08, 2020 at 09:59:20PM +0000, Barnabás Pőcze wrote:
> >
> > > 2020. november 25., szerda 16:07 keltezéssel, Greg KH írta:
> > >
> > > > [...]
> > > >
> > > > > +static u8 polling_mode;
> > > > > +module_param(polling_mode, byte, 0444);
> > > > > +MODULE_PARM_DESC(polling_mode, "How to poll (default=0) - 0 disabled; 1 based on GPIO pin's status");
> > > >
> > > > Module parameters are for the 1990's, they are global and horrible to
> > > > try to work with. You should provide something on a per-device basis,
> > > > as what happens if your system requires different things here for
> > > > different devices? You set this for all devices :(
> > > > [...]
> > >
> > > Hi
> > > do you think something like what the usbcore has would be better?
> > > A module parameter like "quirks=<vendor-id>:<product-id>:<flags>[,<vendor-id>:<product-id>:<flags>]*"?
> >
> > Not really, that's just for debugging, and asking users to test
> > something, not for a final solution to anything.
>
> My understanding is that this polling mode option is by no means intended
> as a final solution, it's purely for debugging/fallback:
>
> "Polling mode could be a fallback solution for enthusiastic Linux users
> when they have a new laptop. It also acts like a debugging feature. If
> polling mode works for a broken touchpad, we can almost be certain
> the root cause is related to the interrupt or power setting."
>
> What would you suggest instead of the module parameter?
a debugfs file? That means it's only for debugging and you have to be
root to change the value.
thanks,
greg k-h