On Thu, Feb 11, 2021 at 6:15 PM Saravana Kannan wrote:
>
> On Thu, Feb 11, 2021 at 7:03 AM Rafael J. Wysocki wrote:
> >
> > On Thu, Feb 11, 2021 at 1:02 AM Saravana Kannan
> > wrote:
> > >
> > > On Thu, Jan 28, 2021 at 7:03 AM Jon Hunter wrote:
> &
On Thu, Feb 11, 2021 at 4:42 PM Andy Shevchenko
wrote:
>
> On Wed, Feb 10, 2021 at 04:44:34PM +0100, Rafael J. Wysocki wrote:
> > On Wed, Feb 10, 2021 at 4:42 PM Andy Shevchenko
> > wrote:
> > > On Wed, Feb 10, 2021 at 04:01:16PM +0100, Rafael J. Wysocki wrote:
> &
On Thu, Feb 11, 2021 at 2:50 PM Andy Shevchenko
wrote:
>
> This is last part of Intel MID (SFI based) removal. We have no more users of
> it
> in the kernel and since SFI has been marked Obsolete for a few years already,
> Remove all the stuff altogether.
>
> Note, the more recent platforms (Inte
On Thu, Feb 11, 2021 at 1:02 AM Saravana Kannan wrote:
>
> On Thu, Jan 28, 2021 at 7:03 AM Jon Hunter wrote:
> >
> >
> > On 14/01/2021 16:56, Jon Hunter wrote:
> > >
> > > On 14/01/2021 16:47, Saravana Kannan wrote:
> > >
> > > ...
> > >
> > >>> Yes this is the warning shown here [0] and this is
scaling driver and schedutil as the scaling governor.
Thanks!
---
Rafael J. Wysocki (2):
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
cpufreq: ACPI: Update arch scale-invariance max perf ratio if
CPPC is not there
---
arch/x86/kernel
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
acpi-5.11-rc8
with top-most commit fe0af09074bfeb46a35357e67635eefe33cdfc49
Revert "ACPICA: Interpreter: fix memory leak by using existing buffer"
on top of commit 92bf22614b21a2706f4993b2
On Wed, Feb 10, 2021 at 4:42 PM Andy Shevchenko
wrote:
>
> On Wed, Feb 10, 2021 at 04:01:16PM +0100, Rafael J. Wysocki wrote:
> > On Wed, Feb 10, 2021 at 3:48 PM Andy Shevchenko
> > wrote:
> > > On Wed, Feb 10, 2021 at 02:48:09PM +0100, Rafael J. Wysocki wrote:
> &
On Wed, Feb 10, 2021 at 3:48 PM Andy Shevchenko
wrote:
>
> On Wed, Feb 10, 2021 at 02:48:09PM +0100, Rafael J. Wysocki wrote:
> > On Wednesday, February 10, 2021 2:31:48 PM CET Rafael J. Wysocki wrote:
> > > On Wednesday, February 10, 2021 1:36:00 PM CET Rafael J. Wysocki
On Wednesday, February 10, 2021 2:31:48 PM CET Rafael J. Wysocki wrote:
> On Wednesday, February 10, 2021 1:36:00 PM CET Rafael J. Wysocki wrote:
> > On Wed, Feb 10, 2021 at 12:51 PM Andy Shevchenko
> > wrote:
> > >
> > > We allow to read the single valu
On Wednesday, February 10, 2021 1:36:00 PM CET Rafael J. Wysocki wrote:
> On Wed, Feb 10, 2021 at 12:51 PM Andy Shevchenko
> wrote:
> >
> > We allow to read the single value as a first element in the array.
> > Unfortunately the counting doesn't work in th
On Wed, Feb 10, 2021 at 12:51 PM Andy Shevchenko
wrote:
>
> We allow to read the single value as a first element in the array.
> Unfortunately the counting doesn't work in this case and we can't
> call fwnode_property_count_*() API without getting an error.
It would be good to mention what the sy
On Tue, Feb 9, 2021 at 12:57 PM Kalle Valo wrote:
>
> + ath10k list
>
> Peter Zijlstra writes:
>
> > On Mon, Feb 08, 2021 at 08:04:27PM +0100, Rafael J. Wysocki wrote:
> >> Hi Peter & Paul,
> >>
> >> The traces below are present in the boot
On Tue, Feb 9, 2021 at 5:54 PM Sakari Ailus
wrote:
>
> On Tue, Feb 09, 2021 at 05:42:45PM +0100, Rafael J. Wysocki wrote:
> > On Tue, Feb 9, 2021 at 5:23 PM Sakari Ailus
> > wrote:
> > >
> > > Hi Bartosz, Rafael,
> > >
> > > On Tue, Feb 0
On Tue, Feb 9, 2021 at 5:23 PM Sakari Ailus
wrote:
>
> Hi Bartosz, Rafael,
>
> On Tue, Feb 09, 2021 at 04:49:37PM +0100, Bartosz Golaszewski wrote:
> > On Mon, Feb 8, 2021 at 5:54 PM Rafael J. Wysocki wrote:
> > >
> > > On Mon, Feb 8, 2021 at 5:44
On Mon, Feb 8, 2021 at 9:49 PM Joe Perches wrote:
>
> On Mon, 2021-02-08 at 19:59 +0100, Rafael J. Wysocki wrote:
> > Replace the ACPI_DEBUG_PRINT() instance in osl.c unrelated to the
> > ACPICA debug with acpi_handle_debug(), add a pr_fmt() definition
> > to osl.c a
On Tue, Feb 9, 2021 at 4:22 AM Weidong Cui wrote:
>
> Signed-off-by: Weidong Cui
> Signed-off-by: Xinyang Ge
ACPICA material, left to Erik & Bob, thanks!
> ---
> drivers/acpi/acpica/evhandler.c | 2 ++
> include/acpi/acconfig.h | 4
> 2 files changed, 6 insertions(+)
>
> diff --g
On Mon, Feb 8, 2021 at 8:48 PM Andy Shevchenko
wrote:
>
> On Mon, Feb 8, 2021 at 9:47 PM Andy Shevchenko
> wrote:
> > On Mon, Feb 8, 2021 at 9:30 PM Rafael J. Wysocki wrote:
> > >
> > > On Friday, February 5, 2021 12:15:22 PM CET Andy Shevchenko wrote:
> &
On Friday, February 5, 2021 12:15:22 PM CET Andy Shevchenko wrote:
> On Fri, Feb 5, 2021 at 11:14 AM Andy Shevchenko
> wrote:
> > On Friday, February 5, 2021, Stephen Rothwell wrote:
>
> >> After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
> >> failed like this:
> >>
> >
Hi Peter & Paul,
The traces below are present in the boot dmesg log on my Dell XPS13 9360.
I haven't had the time to look into this in detail yet, but here it goes in
case you know what's going on already.
Cheers!
[ 86.762542] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 86.
From: Rafael J. Wysocki
Rearrange the code in acpi_check_resource_conflict() so as to drop
redundant checks and uneeded local variables from there and modify
the messages printed by that function to be more concise and
hopefully easier to understand.
While at it, replace direct printk() usage
Hi All,
These two patches clean up some code in osl.c.
The first one simplifies acpi_check_resource_confllict() and the second one
deals with
message printing in this file.
See patch changelogs for details.
Thanks!
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() instance in osl.c unrelated to the
ACPICA debug with acpi_handle_debug(), add a pr_fmt() definition
to osl.c and replace direct printk() usage in that file with the
suitable pr_*() calls.
While at it, add a physical address value to the
On Mon, Feb 8, 2021 at 5:44 PM Bartosz Golaszewski
wrote:
>
> On Fri, Feb 5, 2021 at 2:25 PM Sakari Ailus
> wrote:
> >
> > In certain use cases (where the chip is part of a camera module, and the
> > camera module is wired together with a camera privacy LED), powering on
> > the device during pro
On Mon, Feb 8, 2021 at 5:11 PM Shuah Khan wrote:
>
> Hi Rafael,
>
> Please pull the following cpupower update for Linux 5.12-rc1
>
> This cpupower update for Linux 5.12-rc1 consists of:
>
> - Updates to the cpupower command to add support for AMD family 0x19
>and cleanup the code to remove man
d
> > we should not modify that in place. This fixes a crash on arm64 with
> > initrd table overrides, in which case the DSDT is not mapped with
> > read/write permissions.
> >
> > Cc: Robert Moore
> > Cc: Erik Kaneda
> > Cc: "Rafael J. Wysocki&q
rocess_one_work+0x330/0x550)
> [] (process_one_work) from []
> (worker_thread+0x22c/0x2ec)
>
> Fix this race condition by using the freezable instead of the normal
> power-efficient workqueue.
>
> Signed-off-by: Geert Uytterhoeven
LGTM
Acked-by: Rafael J. Wy
On Sat, Jan 23, 2021 at 11:07 AM Yunfeng Ye wrote:
>
> It's not a good way to access phys_proc_id and cpu_die_id directly.
> So using topology_physical_package_id(cpu) and topology_die_id(cpu)
> instead.
>
> Signed-off-by: Yunfeng Ye
Srinivas, Rui, any concerns?
> ---
> drivers/powercap/intel_
On Wed, Feb 3, 2021 at 4:45 PM Bhaskar Chowdhury wrote:
>
>
> s/optimzation/optimization/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> include/acpi/acoutput.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/acpi/acoutput.h b/include/acpi/acoutput.h
> index c5d900
On Tue, Feb 2, 2021 at 7:52 AM Yang Li wrote:
>
> Eliminate the following coccicheck warning:
> ./drivers/acpi/apei/erst.c:691:2-3: Unneeded semicolon
>
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
> ---
> drivers/acpi/apei/erst.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On Fri, Jan 29, 2021 at 1:03 PM Shiju Jose wrote:
>
> CPU L2 cache corrected errors are detected occasionally on
> few of our ARM64 hardware boards. Though it is rare, the
> probability of the CPU cache errors frequently occurring
> can't be avoided. The earlier failure detection by monitoring
> t
On Sat, Dec 12, 2020 at 2:22 AM Dexuan Cui wrote:
>
> Hi all,
> It looks like Linux can hibernate even if the system does not support the ACPI
> S4 state, as long as the system can shut down, so "cat /sys/power/state"
> always contains "disk", unless we specify the kernel parameter "nohibernate"
>
On Fri, Feb 5, 2021 at 1:55 PM Bhaskar Chowdhury wrote:
>
>
>
> s/fucked/messed/
I wouldn't make the changelog so explicit, just say "Use more
appropriate language" or similar.
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/cpufreq/powernow-k7.c | 2 +-
> 1 file changed, 1 insertion(+),
On Tue, Jan 26, 2021 at 2:32 PM tanxiaofei wrote:
>
> @James
> Hi James, please help to review this patch. Thank you very much. :)
James, Boris, any comments?
> On 2020/12/10 20:09, Xiaofei Tan wrote:
> > After the commit 8fcc4ae6faf8 ("arm64: acpi: Make apei_claim_sea()
> > synchronise with APE
On Sat, Jan 23, 2021 at 11:07 AM Yunfeng Ye wrote:
>
> It's not a good way to access the phys_proc_id of cpuinfo directly.
> So using topology_physical_package_id(cpu) instead.
>
> Signed-off-by: Yunfeng Ye
Srinivas, Rui, any concerns?
> ---
> drivers/powercap/intel_rapl_common.c | 2 +-
> 1 f
On Fri, Feb 5, 2021 at 12:59 PM Peter Zijlstra wrote:
>
> On Thu, Feb 04, 2021 at 06:34:32PM +0100, Rafael J. Wysocki wrote:
>
> > arch/x86/kernel/smpboot.c |1 +
> > drivers/cpufreq/acpi-cpufreq.c |8
> > 2 files changed, 9 insertions(+)
>
On Fri, Feb 5, 2021 at 12:04 AM Michael Larabel wrote:
>
> On 2/4/21 7:40 AM, Rafael J. Wysocki wrote:
> > On Thu, Feb 4, 2021 at 12:36 AM Michael Larabel
> > wrote:
> >> On 2/3/21 12:25 PM, Rafael J. Wysocki wrote:
> >>> On Wednesday, February 3, 2021
On Fri, Feb 5, 2021 at 11:28 AM Ruifeng Zhang
wrote:
>
> Rafael J. Wysocki 于2021年2月4日周四 下午9:38写道：
> >
> > On Thu, Feb 4, 2021 at 10:07 AM Ruifeng Zhang
> > wrote:
> > >
> > > Greg KH 于2021年1月29日周五 下午4:53写道：
> > > >
> > >
On Thu, Feb 4, 2021 at 7:41 PM Wei Liu wrote:
>
> On Wed, Feb 03, 2021 at 03:04:27PM +, Wei Liu wrote:
> > There is already a stub function for pxm_to_node but conversion to the
> > other direction is missing.
> >
> > It will be used by Microsoft Hypervisor code later.
> >
> > Signed-off-by: W
On Tue, Feb 2, 2021 at 8:47 PM Saravana Kannan wrote:
>
> On Tue, Feb 2, 2021 at 6:34 AM Rafael J. Wysocki wrote:
> >
> > On Tue, Feb 2, 2021 at 5:33 AM Saravana Kannan wrote:
> > >
[cut]
> >
> > > + *
> > > + * This function requests fw_d
On Tue, Feb 2, 2021 at 6:42 AM Viresh Kumar wrote:
>
> This flag is set by one of the drivers but it isn't used in the code
> otherwise. Remove the unused flag and update the driver.
>
> Signed-off-by: Viresh Kumar
Applied as 5.12 material, thanks!
> ---
> Rebased over:
>
> https://lore.kernel.
On Tue, Feb 2, 2021 at 5:56 AM Viresh Kumar wrote:
>
> During cpufreq driver's registration, if the ->init() callback for all
> the CPUs fail then there is not much point in keeping the driver around
> as it will only account for more of unnecessary noise, for example
> cpufreq core will try to su
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
acpi-5.11-rc7
with top-most commit 0f347aa07f15b346a001e557f4a0a45069f7fa3d
ACPI: scan: Fix battery devices sometimes never binding
on top of commit 1048ba83fb1c00cd24172e23e8263972f6b5d9a
Hi All,
These 2 patches address a performance regression related to scale-invariance
found by Michael and analyzed by Giovanni (see the patch from Giovanni at
https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdov...@suse.cz/).
Patch [1/2] is a replacement for the one mentioned above (i
From: Rafael J. Wysocki
If the maximum performance level taken for computing the
arch_max_freq_ratio value used in the x86 scale-invariance code is
higher than the one corresponding to the cpuinfo.max_freq value
coming from the acpi_cpufreq driver, the scale-invariant utilization
falls below 100
From: Rafael J. Wysocki
A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for
AMD systems")
97
onal feature that device_add_properties() does not have. It
> allows the software nodes created with it to be part of a node
> hierarchy by taking also an optional parent node as parameter.
>
> Signed-off-by: Heikki Krogerus
The rationale is clear now, so
Rev
Hi Shuah,
First off, please indicate the component in the subject, for example:
"ACPI: extlog: convert seqno to use seqnum_ops"
On Wed, Feb 3, 2021 at 7:12 PM Shuah Khan wrote:
>
> Sequence Number api provides interfaces for unsigned atomic up counters
> leveraging atomic_t and atomic64_t ops u
On Thu, Feb 4, 2021 at 2:49 PM Giovanni Gherdovich wrote:
>
> On Wed, 2021-02-03 at 19:25 +0100, Rafael J. Wysocki wrote:
> > [cut]
> >
> > So below is a prototype of an alternative fix for the issue at hand.
> >
> > I can't really test it here, beca
On Thu, Feb 4, 2021 at 12:36 AM Michael Larabel wrote:
>
> On 2/3/21 12:25 PM, Rafael J. Wysocki wrote:
> > On Wednesday, February 3, 2021 3:11:37 PM CET Rafael J. Wysocki wrote:
> >> On Wed, Feb 3, 2021 at 2:53 PM Giovanni Gherdovich
> >> wrote:
> >> [cu
On Thu, Feb 4, 2021 at 10:07 AM Ruifeng Zhang
wrote:
>
> Greg KH 于2021年1月29日周五 下午4:53写道：
> >
> > On Fri, Jan 29, 2021 at 04:27:26PM +0800, Ruifeng Zhang wrote:
> > > From: Ruifeng Zhang
> > >
> > > Suspend type contains s2ram and s2idle, but syscore is only
> > > available for S2RAM.
> >
> > Who
On Tue, Feb 2, 2021 at 9:15 AM Lee Jones wrote:
>
> On Mon, 01 Feb 2021, Rafael J. Wysocki wrote:
>
> > On Mon, Feb 1, 2021 at 7:45 PM Andy Shevchenko
> > wrote:
> > >
> > > On Tue, Jan 26, 2021 at 12:39:59PM +0200, Andy Shevchenko wrote:
> > >
Hi All,
On Tuesday, February 2, 2021 7:11:47 PM CET Rafael J. Wysocki wrote:
>
> On Monday, February 1, 2021 7:14:38 PM CET Rafael J. Wysocki wrote:
> >
> > This series is a continuation of the effort to drop ACPICA-specific debug
> > code from non-ACPICA pieces of t
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances
in ac.c with acpi_handle_debug() and acpi_handle_info() calls,
respectively, which among other things causes the excessive log
level of the messages previously printed via ACPI_EXCEPTION() to
be increased
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances
in battery.c with acpi_handle_debug() and acpi_handle_info() calls,
respectively, which among other things causes the excessive log
level of the messages previously printed via ACPI_EXCEPTION() to
be increased
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() instance in button.c with an
acpi_handle_debug() call, drop the _COMPONENT and ACPI_MODULE_NAME()
definitions that are not used any more, drop the no longer needed
ACPI_BUTTON_COMPONENT definition from the headers and update the
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() instances in acpi_video.c with
acpi_handle_debug() calls and the ACPI_EXCEPTION()/ACPI_ERROR()/
ACPI_WARNING() instances in there with acpi_handle_info() calls,
which among other things causes the excessive log levels of those
messages to be
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() instances in thermal.c with
acpi_handle_debug() calls and modify the ACPI_THERMAL_TRIPS_EXCEPTION()
macro in there to use acpi_handle_info() internally, which among other
things causes the excessive log level of the messages printed by it
On Wednesday, February 3, 2021 2:31:08 AM CET Hanjun Guo wrote:
> Hi Rafael,
>
> On 2021/2/3 2:14, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Replace the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances
> > in ac.c with acpi_handle_deb
On Wednesday, February 3, 2021 3:11:37 PM CET Rafael J. Wysocki wrote:
> On Wed, Feb 3, 2021 at 2:53 PM Giovanni Gherdovich
> wrote:
> >
>
> [cut]
>
> > Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
> > systems")
> >
On Wed, Feb 3, 2021 at 3:27 PM Heikki Krogerus
wrote:
>
> On Wed, Feb 03, 2021 at 02:50:24PM +0100, Rafael J. Wysocki wrote:
> > On Wed, Feb 3, 2021 at 10:45 AM Heikki Krogerus
> > wrote:
> > >
> > > On Tue, Feb 02, 2021 at 05:08:40PM +0100, Rafael J. Wysock
On Wed, Feb 3, 2021 at 2:53 PM Giovanni Gherdovich wrote:
>
[cut]
> Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
> systems")
> Fixes: 976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
> frequency invariance on AMD EPYC")
> Reported-by: Michael Larab
On Wed, Feb 3, 2021 at 10:45 AM Heikki Krogerus
wrote:
>
> On Tue, Feb 02, 2021 at 05:08:40PM +0100, Rafael J. Wysocki wrote:
> > It looks like there is a use case that cannot be addressed by using
> > device_add_properties() and that's why you need this new function.
&
> On Tue, 2021-02-02 at 20:26 +0100, Rafael J. Wysocki wrote:
> > On Tue, Feb 2, 2021 at 7:59 PM Rafael J. Wysocki wrote:
> > >
> > > On Fri, Jan 22, 2021 at 9:47 PM Giovanni Gherdovich
> > > wrote:
> > >
> > > [cut]
>
On Tue, Feb 2, 2021 at 7:59 PM Rafael J. Wysocki wrote:
>
> On Fri, Jan 22, 2021 at 9:47 PM Giovanni Gherdovich
> wrote:
> >
>
> [cut]
>
> >
> > Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
> > systems")
&
On Tue, Feb 2, 2021 at 7:29 PM Rafael J. Wysocki wrote:
>
> On Tue, Feb 2, 2021 at 7:24 PM Peter Zijlstra wrote:
> >
> > On Tue, Feb 02, 2021 at 03:17:05PM +0100, Giovanni Gherdovich wrote:
> > > Hello Rafael,
> > >
> > > you haven't replie
On Tue, Feb 2, 2021 at 7:45 PM Rafael J. Wysocki wrote:
>
> On Tue, Jan 26, 2021 at 5:19 PM Giovanni Gherdovich
> wrote:
> >
> > On Mon, 2021-01-25 at 11:04 +0100, Peter Zijlstra wrote:
> > > On Fri, Jan 22, 2021 at 09:40:38PM +0100, Giovanni Gherdovich wrote:
>
On Fri, Jan 22, 2021 at 9:47 PM Giovanni Gherdovich wrote:
>
[cut]
>
> Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
> systems")
> Fixes: 976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
> frequency invariance on AMD EPYC")
> Reported-by: Michael La
On Tue, Jan 26, 2021 at 5:19 PM Giovanni Gherdovich wrote:
>
> On Mon, 2021-01-25 at 11:04 +0100, Peter Zijlstra wrote:
> > On Fri, Jan 22, 2021 at 09:40:38PM +0100, Giovanni Gherdovich wrote:
> > > This workload is constant in time, so instead of using the PELT sum we can
> > > pretend that scale
On Mon, Jan 25, 2021 at 11:11 AM Peter Zijlstra wrote:
>
> On Fri, Jan 22, 2021 at 09:40:38PM +0100, Giovanni Gherdovich wrote:
> > This workload is constant in time, so instead of using the PELT sum we can
> > pretend that scale invariance is obtained with
> >
> > util_inv = util_raw * freq_c
On Tue, Feb 2, 2021 at 10:58 AM Daniel Scally wrote:
>
> Hi Rafael
>
> On 21/01/2021 21:06, Daniel Scally wrote:
> >
> > On 21/01/2021 18:08, Rafael J. Wysocki wrote:
> >> On Thu, Jan 21, 2021 at 5:34 PM Daniel Scally wrote:
> >>>
> >>> On
On Tue, Feb 2, 2021 at 7:24 PM Peter Zijlstra wrote:
>
> On Tue, Feb 02, 2021 at 03:17:05PM +0100, Giovanni Gherdovich wrote:
> > Hello Rafael,
> >
> > you haven't replied to this patch, which was written aiming at v5.11.
>
> I've tentatively queued this for x86/urgent, but ideally this goes
> thr
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() instance in button.c with an
acpi_handle_debug() call, drop the _COMPONENT and ACPI_MODULE_NAME()
definitions that are not used any more, drop the no longer needed
ACPI_BUTTON_COMPONENT definition from the headers and update the
Hi All,
On Monday, February 1, 2021 7:14:38 PM CET Rafael J. Wysocki wrote:
>
> This series is a continuation of the effort to drop ACPICA-specific debug
> code from non-ACPICA pieces of the ACPI subsystem and to make the message
> printing in there more consistent.
>
> T
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances
in ac.c with acpi_handle_debug() and acpi_handle_info() calls,
respectively, which among other things causes the excessive log
level of the messages previously printed via ACPI_EXCEPTION() to
be more adequate
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances
in battery.c with acpi_handle_debug() and acpi_handle_info() calls,
respectively, which among other things causes the excessive log
level of the messages previously printed via ACPI_EXCEPTION() to
be more
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() instances in thermal.c with
acpi_handle_debug() calls and modify the ACPI_THERMAL_TRIPS_EXCEPTION()
macro in there to use acpi_handle_info() internally, which among other
things causes the excessive log level of the messages printed by it
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() instances in acpi_video.c with
acpi_handle_debug() calls and the ACPI_EXCEPTION()/ACPI_ERROR()/
ACPI_WARNING() instances in there with acpi_handle_info() calls,
which among other things causes the excessive log levels of those
messages to be
On Tue, Feb 2, 2021 at 5:33 AM Saravana Kannan wrote:
>
> During the initial parsing of firmware by fw_devlink, fw_devlink might
> infer that some supplier firmware nodes would get populated as devices.
> But the inference is not always correct. This patch tries to logically
> detect and fix such
On Tue, Feb 2, 2021 at 4:01 PM Heikki Krogerus
wrote:
>
> Hi Rafael,
>
> On Tue, Feb 02, 2021 at 03:44:05PM +0100, Rafael J. Wysocki wrote:
> > > +/**
> > > + * device_create_managed_software_node - Create a software node for a
> > > device
> >
On Tue, Feb 2, 2021 at 5:33 AM Saravana Kannan wrote:
>
> After a deferred probe attempt has exhaused all the devices that can be
> bound, any device that remains unbound has one/both of these conditions
> true:
>
> (1) It is waiting on its supplier to bind
> (2) It does not have a matching driver
On Tue, Feb 2, 2021 at 1:50 PM Heikki Krogerus
wrote:
>
> Adding function device_create_managed_software_node() that
> is designed to work as a drop-in replacement for
> device_add_properties(). The function has one additional
> feature compared to device_add_properties(). It takes also
> an optio
On Tue, Feb 2, 2021 at 2:38 PM Joe Perches wrote:
>
> On Mon, 2021-02-01 at 19:44 +0100, Rafael J. Wysocki wrote:
> > On Mon, Feb 1, 2021 at 7:37 PM Joe Perches wrote:
> > >
> > > On Mon, 2021-02-01 at 19:16 +0100, Rafael J. Wysocki wrote:
> > > > From:
On Mon, Feb 1, 2021 at 7:45 PM Andy Shevchenko
wrote:
>
> On Tue, Jan 26, 2021 at 12:39:59PM +0200, Andy Shevchenko wrote:
> > On Tue, Jan 26, 2021 at 08:21:01AM +, Lee Jones wrote:
> > > On Mon, 25 Jan 2021, Andy Shevchenko wrote:
> > >
> > > > This is a second part of the Intel MID outdated
On Mon, Feb 1, 2021 at 7:37 PM Joe Perches wrote:
>
> On Mon, 2021-02-01 at 19:16 +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Replace the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances
> > in battery.c with acpi_handle_debug(
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() instances in thermal.c with
acpi_handle_debug() calls and modify the ACPI_THERMAL_TRIPS_EXCEPTION()
macro in there to use acpi_handle_info() internally.
Drop the _COMPONENT and ACPI_MODULE_NAME() definitions that are not
used any more from
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() instances in acpi_video.c with
acpi_handle_debug() calls and the ACPI_EXCEPTION()/ACPI_ERROR()/
ACPI_WARNING() instances in there with acpi_handle_info() calls.
Drop the _COMPONENT and ACPI_MODULE_NAME() definitions that are not
used any
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances
in battery.c with acpi_handle_debug() and acpi_handle_info() calls,
respectively, drop the _COMPONENT and ACPI_MODULE_NAME() definitions
that are not used any more, drop the no longer needed
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() instance in button.c with an
acpi_handle_debug() call, drop the _COMPONENT and ACPI_MODULE_NAME()
definitions that are not used any more, drop the no longer needed
ACPI_BUTTON_COMPONENT definition from the headers and update the
Hi All,
This series is a continuation of the effort to drop ACPICA-specific debug
code from non-ACPICA pieces of the ACPI subsystem and to make the message
printing in there more consistent.
The patches in this series are based on linux-next from today.
Details in the patch changelogs.
Thanks!
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances
in ac.c with acpi_handle_debug() and acpi_handle_info() calls,
respectively, drop the _COMPONENT and ACPI_MODULE_NAME() definitions
that are not used any more, drop the no longer needed ACPI_AC_COMPONENT
ault")
> Signed-off-by: Saravana Kannan
Looks reasonable to me:
Acked-by: Rafael J. Wysocki
> ---
> drivers/base/core.c | 30 +++---
> 1 file changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
>
On Tue, Jan 26, 2021 at 11:40 AM Lukasz Luba wrote:
>
> Hi all,
>
> This patch set tries to add the missing feature in the Intelligent Power
> Allocation (IPA) governor which is: frequency limit set by user space.
> User can set max allowed frequency for a given device which has impact on
> max al
On Mon, Feb 1, 2021 at 11:11 AM Ulf Hansson wrote:
>
> On Wed, 27 Jan 2021 at 09:42, Abaci Team
> wrote:
> >
> > Fix the following coccicheck warnings:
> >
> > ./drivers/base/power/domain.c:938:31-33: WARNING !A || A && B is
> > equivalent to !A || B.
> >
> > Reported-by: Abaci Robot
> > Sugges
On Mon, Feb 1, 2021 at 11:06 AM Viresh Kumar wrote:
>
> On 01-02-21, 10:44, Dominik Brodowski wrote:
> > IIRC, it was required on various ARM systems,[*] as CPUs were registered as
> > subsys_initcall(), while cpufreq used to be initialized only later, as an
>
> s/later/earlier ? arch happens befo
On Fri, Jan 29, 2021 at 10:22 PM Sakari Ailus
wrote:
>
> On Fri, Jan 29, 2021 at 05:57:17PM +0100, Rafael J. Wysocki wrote:
> > On Fri, Jan 29, 2021 at 5:45 PM Sakari Ailus
> > wrote:
> > >
> > > Hi Rafael,
> > >
> > > Thanks for the comments
On Friday, January 29, 2021 7:13:14 PM CET Linus Torvalds wrote:
> On Fri, Jan 29, 2021 at 10:11 AM Rafael J. Wysocki wrote:
> >
> > [Resending, because it hasn't made it to the mailing lists, not sure why.]
>
> I see it, and I see the cc to the list, so it is likely
compatible" modalias
Rafael J. Wysocki (1):
ACPI: thermal: Do not call acpi_thermal_check() directly
---
drivers/acpi/device_sysfs.c | 20 ++--
drivers/acpi/thermal.c | 46 -
2 files changed, 39 insertions(+), 27 deletions(-)
On Fri, Jan 29, 2021 at 5:45 PM Sakari Ailus
wrote:
>
> Hi Rafael,
>
> Thanks for the comments.
>
> On Fri, Jan 29, 2021 at 03:07:57PM +0100, Rafael J. Wysocki wrote:
> > On Fri, Jan 29, 2021 at 12:27 AM Sakari Ailus
> > wrote:
> > >
> > > Sto
On Fri, Jan 29, 2021 at 5:37 PM Rafael J. Wysocki wrote:
>
> On Fri, Jan 29, 2021 at 7:48 AM Calvin Johnson
> wrote:
> >
> > On Thu, Jan 28, 2021 at 02:27:00PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Jan 28, 2021 at 2:12 PM Calvin Johnson
> > > wrot
On Fri, Jan 29, 2021 at 7:48 AM Calvin Johnson
wrote:
>
> On Thu, Jan 28, 2021 at 02:27:00PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Jan 28, 2021 at 2:12 PM Calvin Johnson
> > wrote:
> > >
> > > On Thu, Jan 28, 2021 at 01:00:40PM +0100, Rafael J. Wysocki
301 - 400 of 9612 matches
Mail list logo
