Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
pm-5.12-rc6
with top-most commit ac1790ad78f8f0cf9a588ffb530c700ad758e8b6
Merge branch 'pm-cpufreq'
on top of commit a5e13c6df0e41702d2b2c77c8ad41677ebb065b3
Linux 5.12-rc5
to receive p
On Thu, Apr 1, 2021 at 3:34 PM Rafael J. Wysocki wrote:
>
> On Thu, Apr 1, 2021 at 2:25 PM Chris von Recklinghausen
> wrote:
> >
> > Suspend fails on a system in fips mode because md5 is used for the e820
> > integrity check and is not available. Use crc32 instead.
On Thu, Apr 1, 2021 at 3:54 PM Ard Biesheuvel wrote:
>
> On Thu, 1 Apr 2021 at 15:38, Rafael J. Wysocki wrote:
> >
> > On Thu, Apr 1, 2021 at 10:47 AM Ard Biesheuvel wrote:
> > >
> > > On Tue, 30 Mar 2021 at 21:56, Simo Sorce wrote:
> > > >
On Thu, Apr 1, 2021 at 1:26 AM Pierre-Louis Bossart
wrote:
>
> remove make W=1 warnings
>
> drivers/base/power/runtime.c:926: warning: Function parameter or
> member 'timer' not described in 'pm_suspend_timer_fn'
>
> drivers/base/power/runtime.c:926: warning: Excess function parameter
> 'data' des
On Thu, Apr 1, 2021 at 10:47 AM Ard Biesheuvel wrote:
>
> On Tue, 30 Mar 2021 at 21:56, Simo Sorce wrote:
> >
> > On Tue, 2021-03-30 at 21:45 +0200, Ard Biesheuvel wrote:
> > > On Tue, 30 Mar 2021 at 20:05, Simo Sorce wrote:
> > > > On Tue, 2021-03-30
On Thu, Apr 1, 2021 at 6:22 PM Simo Sorce wrote:
>
> On Thu, 2021-04-01 at 18:02 +0200, Rafael J. Wysocki wrote:
> > On Thu, Apr 1, 2021 at 3:54 PM Ard Biesheuvel wrote:
> > > On Thu, 1 Apr 2021 at 15:38, Rafael J. Wysocki wrote:
> > > > On Thu, Apr 1, 2021
On Thu, Apr 1, 2021 at 2:56 PM Yufen Yu wrote:
>
> Recently, our syzbot test reported NULL pointer dereference in
> device_del() by injecting memory allocation fail in device_add().
>
> For now, callers of device_add(), such as add_disk(), may ignore
> device_add()'s fail and go on working. In unr
On Thu, Apr 1, 2021 at 3:59 PM Ard Biesheuvel wrote:
>
> On Thu, 1 Apr 2021 at 15:34, Rafael J. Wysocki wrote:
> >
> > On Thu, Apr 1, 2021 at 2:25 PM Chris von Recklinghausen
> > wrote:
> > >
> > > Suspend fails on a system in fips mode because md5 is u
On Thu, Apr 1, 2021 at 11:00 AM David Laight wrote:
>
> From: Bjorn Helgaas
> > Sent: 31 March 2021 18:22
> >
> > On Wed, Mar 31, 2021 at 11:55:08PM +0800, Zhang Rui wrote:
> > > ...
> >
> > > From e18c942855e2f51e814d057fff4dd951cd0d0907 Mon Sep 17 00:00:00 2001
> > > From: Zhang Rui
> > > Date:
On Thu, Apr 1, 2021 at 2:25 PM Chris von Recklinghausen
wrote:
>
> Suspend fails on a system in fips mode because md5 is used for the e820
> integrity check and is not available. Use crc32 instead.
>
> Fixes: 62a03defeabd ("PM / hibernate: Verify the consistent of e820 memory map
>by md5 d
On Thu, Apr 1, 2021 at 4:23 PM David Laight wrote:
>
> From: Rafael J. Wysocki
> > Sent: 01 April 2021 14:50
> ...
> > So what exactly is wrong with using "packed"? It is way easier to
> > understand for a casual reader of the code.
>
>
On Wed, Mar 31, 2021 at 11:09 PM Bjorn Helgaas wrote:
>
> On Thu, Mar 25, 2021 at 07:57:51PM +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > If PCI_D3cold is passed to acpi_pci_set_power_state() as the second
> > argument and there is no ACP
On Wed, Mar 31, 2021 at 5:32 PM Randy Dunlap wrote:
>
> On 3/31/21 2:43 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > News: there will be no linux-next release on Friday or the following
> > Monday.
> >
> > Changes since 20210330:
> >
>
> ../drivers/acpi/processor_idle.c:542:15: warning: extra t
On Tue, Mar 30, 2021 at 12:27 PM Vitaly Kuznetsov wrote:
>
> Kernel test robot reports build breakage with commit 5f5e49e999ac
> ("ACPI: processor: Fix CPU0 wakeup in acpi_idle_play_dead()") when
> !CONFIG_HOTPLUG_CPU/!CONFIG_SMP. wakeup_cpu0() is defined under
> CONFIG_SMP and start_cpu0() under
On Tue, Mar 30, 2021 at 10:15 AM David Laight wrote:
>
> From: Zhang Rui
> > Sent: 30 March 2021 09:00
> > To: Xiaofei Tan ; David Laight
> > ; r...@rjwysocki.net;
> > l...@kernel.org; bhelg...@google.com
> > Cc: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-...@vger.kernel
On 3/29/2021 9:52 PM, Angela Czubak wrote:
Do not overwrite flags as it leads to erasing triggering and polarity
information which might be useful in case of hard-coded interrupts.
This way the information can be read later on even though mapping to
APIC domain failed.
Signed-off-by: Angela Czub
On Tue, Mar 30, 2021 at 4:00 AM Zhou Ti (x2019cwm) wrote:
>
> On Mon 2021-03-29 14:37 Rafael J. Wysocki wrote:
> > Make the menu governor check the tick_nohz_get_next_hrtimer()
> > return value so as to avoid dealing with negative "sleep length"
> > values and ma
On Tue, Mar 30, 2021 at 12:14 AM Dexuan Cui wrote:
>
> Hi,
> MD5 was marked incompliant with FIPS in 2009:
> a3bef3a31a19 ("crypto: testmgr - Skip algs not flagged fips_allowed in fips
> mode")
> a1915d51e8e7 ("crypto: testmgr - Mark algs allowed in fips mode")
>
> But hibernation_e820_save() is
On Tue, Mar 30, 2021 at 2:19 AM Kaneda, Erik wrote:
>
>
>
> > -Original Message-
> > From: Rafael J. Wysocki
> > Sent: Monday, March 29, 2021 5:48 AM
> > To: Bhaskar Chowdhury ; Kaneda, Erik
> >
> > Cc: Wysocki, Rafael J ; ACPI Dev
From: "Rafael J. Wysocki"
Make the tick_nohz_get_next_hrtimer() kerneldoc comment state clearly
that the function may return negative numbers.
Signed-off-by: Rafael J. Wysocki
---
kernel/time/tick-sched.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: linux
Hi All,
As follows from the discussion triggered by the patch at
https://lore.kernel.org/lkml/20210311123708.23501-2-frede...@kernel.org/
the cpuidle governors using tick_nohz_get_sleep_length() assume it to always
return positive values which is not correct in general.
To address this issues,
From: "Rafael J. Wysocki"
Make the tick_nohz_get_next_hrtimer() kerneldoc comment state clearly
that the function may return negative numbers.
Signed-off-by: Rafael J. Wysocki
---
kernel/time/tick-sched.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: linux
From: "Rafael J. Wysocki"
Modify the TEO governor to take possible negative return values of
tick_nohz_get_next_hrtimer() into account by changing the data type
of some variables used by it to s64 which allows it to carry out
computations without potentially problematic data type c
From: "Rafael J. Wysocki"
Subsequent changes will cause the exit_latency_ns and target_residency_ns
fields in struct cpuidle_state to be used in computations in which data
type conversions to u64 may turn a negative number close to zero into
a verly large positive number leading to
From: "Rafael J. Wysocki"
If the time till the next timer event is shorter than the target
residency of the first idle state (state 0), the TEO governor does
not update its metrics for any idle states, but arguably it should
record a "hit" for idle state 0 in that case, so
From: "Rafael J. Wysocki"
Subject: [PATCH] cpuidle: menu: Take negative "sleep length" values into account
Make the menu governor check the tick_nohz_get_next_hrtimer()
return value so as to avoid dealing with negative "sleep length"
values and make it use that v
On Wed, Mar 24, 2021 at 4:37 PM Rafael J. Wysocki wrote:
>
> On Wed, Mar 24, 2021 at 4:23 PM Vitaly Kuznetsov wrote:
> >
> > Commit 496121c02127 ("ACPI: processor: idle: Allow probing on platforms
> > with one ACPI C-state") broke CPU0 hotplug on certain s
On Sat, Mar 27, 2021 at 1:11 PM Xiaofei Tan wrote:
>
> Fix some coding style issues reported by checkpatch.pl.
> Only cleanup and no function changes.
>
> Differences from v2 to v3:
> - Remove the modifications that may cause function change.
>
> Differences from v1 to v2:
> - Add subsystem and mo
On Fri, Mar 26, 2021 at 1:22 AM 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 1538a
On Fri, Mar 26, 2021 at 11:53 PM Zhou Ti (x2019cwm) wrote:
>
> On Fri, 26 Mar 2021 19:54:26 +0100, Rafael J. Wysocki wrote:
> > On Fri, Mar 26, 2021 at 6:53 PM Zhou Ti (x2019cwm) wrote:
> > >
> > > On Fri, 26 Mar 2021 18:01:47 +0100, Rafael J. Wysocki wrote:
> &
On Fri, Mar 26, 2021 at 6:53 PM Zhou Ti (x2019cwm) wrote:
>
> On Fri, 26 Mar 2021 18:01:47 +0100, Rafael J. Wysocki wrote:
> > On Thu, Mar 25, 2021 at 9:37 PM Zhou Ti (x2019cwm) wrote:
> > >
> > > On March 25, 2021 15:50, Rafael J. Wysocki wrote:
> > > &g
On Thu, Mar 25, 2021 at 9:37 PM Zhou Ti (x2019cwm) wrote:
>
> On March 25, 2021 15:50, Rafael J. Wysocki wrote:
> > On Thu, Mar 25, 2021 at 8:18 PM Zhou Ti (x2019cwm) wrote:
> > >
> > > On March 25, 2021 14:56, Rafael J. Wysocki wrote:
> > > > On Thursd
On Thu, Mar 25, 2021 at 8:38 PM Daniel Lezcano
wrote:
>
> The slope of the temperature increase or decrease can be high and when
> the temperature crosses the trip point, there could be a significant
> difference between the trip temperature and the measured temperatures.
>
> That forces the users
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
acpi-5.12-rc5
with top-most commit e1db18b59729e24f001459b98955019344d5b12b
Merge branches 'acpi-video' and 'acpi-scan'
on top of commit 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b
Linux 5.
s changes
to RPM_SUSPENDED (Rafael Wysocki).
- Change the Energy Model code to prevent it from attempting to
create its main debugfs directory too early (Lukasz Luba).
Thanks!
---
Lukasz Luba (1):
PM: EM: postpone creating the debugfs dir till fs_initcall
Rafael J. Wysock
On Thu, Mar 25, 2021 at 8:18 PM Zhou Ti (x2019cwm) wrote:
>
> On March 25, 2021 14:56, Rafael J. Wysocki wrote:
> > On Thursday, March 25, 2021 2:14:00 PM CET Frederic Weisbecker wrote:
> > > On Tue, Mar 16, 2021 at 04:08:08PM +, Zhou Ti (x2019cwm) wrote:
> > > &
From: Rafael J. Wysocki
If PCI_D3cold is passed to acpi_pci_set_power_state() as the second
argument and there is no ACPI D3cold support for the given device,
the debug message printed by that function will state that the
device power state has been changed to D3cold, while in fact it
will be
On Thursday, March 25, 2021 2:14:00 PM CET Frederic Weisbecker wrote:
> On Tue, Mar 16, 2021 at 04:08:08PM +, Zhou Ti (x2019cwm) wrote:
> > But I don't think it's a good idea to handle this in callers, because
> > logically the function shouldn't return negative values. Returning 0
> > direct
On Thu, Mar 25, 2021 at 8:50 AM Xiongfeng Wang
wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/pci/hotplug/acpi_pcihp.c:167: warning: expecting prototype for
> acpi_pcihp_check_ejectable(). Prototype was for acpi_pci_check_ejectable()
> instead
>
> Reported-by: Hulk Robo
On Thu, Mar 25, 2021 at 8:50 AM Xiongfeng Wang
wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/pci/pcie/aer.c:138: warning: expecting prototype for
> enable_ercr_checking(). Prototype was for enable_ecrc_checking() instead
> drivers/pci/pcie/aer.c:162: warning: expecting
On Tue, Mar 23, 2021 at 2:01 PM Xiaofei Tan wrote:
>
> Fix some errors and warnings reported by checkpatch.pl, including
> following five types:
Well, they are coding style issues rather than errors.
> ERROR: "foo * bar" should be "foo *bar"
> ERROR: code indent should use tabs where possible
>
On Wed, Mar 24, 2021 at 4:42 PM George Kennedy
wrote:
>
>
>
> On 3/24/2021 9:27 AM, Rafael J. Wysocki wrote:
> > On Wed, Mar 24, 2021 at 9:24 AM Mike Rapoport wrote:
> >> On Tue, Mar 23, 2021 at 08:26:52PM +0100, Rafael J. Wysocki wrote:
> >>> From: Rafae
On Mon, Mar 22, 2021 at 3:32 PM Rafael J. Wysocki wrote:
>
> On Tue, Mar 16, 2021 at 4:52 PM Rafael J. Wysocki wrote:
> >
> > From: Rafael J. Wysocki
> >
> > It should not be necessary to update the current_state field of
> > struct pci_dev in pci_
On Wed, Mar 24, 2021 at 4:23 PM Vitaly Kuznetsov wrote:
>
> Commit 496121c02127 ("ACPI: processor: idle: Allow probing on platforms
> with one ACPI C-state") broke CPU0 hotplug on certain systems, e.g.
> I'm observing the following on AWS Nitro (e.g r5b.xlarge but other
> instance types are affect
On Wed, Mar 24, 2021 at 9:24 AM Mike Rapoport wrote:
>
> On Tue, Mar 23, 2021 at 08:26:52PM +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > The following problem has been reported by George Kennedy:
> >
> > Since commit 7fef431be9c9
From: Rafael J. Wysocki
The following problem has been reported by George Kennedy:
Since commit 7fef431be9c9 ("mm/page_alloc: place pages to tail
in __free_pages_core()") the following use after free occurs
intermittently when ACPI tables are accessed.
BUG: KASAN: use-aft
On Tue, Mar 23, 2021 at 7:32 PM Kirill A. Shutemov wrote:
>
> On Fri, Jun 12, 2020 at 02:26:58PM +0200, Rafael J. Wysocki wrote:
> > On 6/11/2020 3:40 AM, Kaneda, Erik wrote:
> > >
> > > > -Original Message-
> > > > From: Vegard Nossu
On Tue, Mar 23, 2021 at 4:57 PM Lukasz Luba wrote:
>
>
>
> On 3/23/21 3:26 PM, Greg KH wrote:
> > On Tue, Mar 23, 2021 at 02:56:08PM +, Lukasz Luba wrote:
> >> The debugfs directory '/sys/kernel/debug/energy_model' is needed before
> >> the Energy Model registration can happen. With the recent
On Tue, Mar 23, 2021 at 3:16 PM Necip Fazil Yildiran
wrote:
>
> When PM_SLEEP_SMP is enabled and HOTPLUG_CPU is disabled, it results in
> the following Kbuild warning:
>
> WARNING: unmet direct dependencies detected for HOTPLUG_CPU
> Depends on [n]: SMP [=y] && (PPC_PSERIES [=n] || PPC_PMAC [=n]
On Sat, Mar 20, 2021 at 9:25 AM Mike Rapoport wrote:
>
> On Thu, Mar 18, 2021 at 04:22:37PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Mar 18, 2021 at 11:50 AM Rafael J. Wysocki
> > wrote:
> > >
> > > On Thu, Mar 18, 2021 at 8:25 AM Mike Rapoport wrote:
>
On Mon, Mar 22, 2021 at 5:31 PM Andy Shevchenko
wrote:
>
> The decrementation of acpi_device_bus_id->instance_no
> in acpi_device_del() is incorrect, because it may cause
> a duplicate instance number to be allocated next time
> a device with the same acpi_device_bus_id is added.
>
> Replace above
On Mon, Mar 22, 2021 at 4:02 PM Andy Shevchenko
wrote:
>
> On Mon, Mar 22, 2021 at 4:57 PM Rafael J. Wysocki wrote:
> >
> > On Fri, Mar 19, 2021 at 8:21 PM Andy Shevchenko
> > wrote:
> > >
> > > The decrementation of acpi_device_bus_id->instan
On Fri, Mar 19, 2021 at 8:21 PM Andy Shevchenko
wrote:
>
> The decrementation of acpi_device_bus_id->instance_no
> in acpi_device_del() is incorrect, because it may cause
> a duplicate instance number to be allocated next time
> a device with the same acpi_device_bus_id is added.
>
> Replace above
On Tue, Mar 16, 2021 at 4:52 PM Rafael J. Wysocki wrote:
>
> From: Rafael J. Wysocki
>
> It should not be necessary to update the current_state field of
> struct pci_dev in pci_enable_device_flags() before calling
> do_pci_enable_device() for the device, because none of the
&
On Sun, Mar 21, 2021 at 9:20 PM Necip Fazil Yildiran
wrote:
>
> When PM_SLEEP_SMP is enabled and HOTPLUG_CPU is disabled, it results in the
> following Kbuild warning:
>
> WARNING: unmet direct dependencies detected for HOTPLUG_CPU
> Depends on [n]: SMP [=y] && (PPC_PSERIES [=n] || PPC_PMAC [=n]
On Mon, Mar 22, 2021 at 11:59 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> The acpi drivers produce a number of avoidable warnings for empty macros
> when building with 'make W=1':
>
> drivers/acpi/acpi_processor.c: In function 'acpi_processor_errata_piix4':
> drivers/acpi/acpi_processor.c
On Fri, Mar 19, 2021 at 7:48 PM Pavel Machek wrote:
>
> On Fri 2021-03-19 17:44:32, Rafael J. Wysocki wrote:
> > On Sat, Mar 13, 2021 at 11:27 AM Pavel Machek wrote:
> > >
> > > On Fri 2021-03-12 11:24:30, chris.c...@canonical.com wrote:
> > > > From: Ch
On Fri, Mar 19, 2021 at 7:33 PM Andy Shevchenko
wrote:
>
> Current mechanism of incrementing and decrementing plain integer
> to get a next free instance_no when creating an ACPI device is buggy.
>
> The simple integer and operations line increment and decrement
> on top of it can't cover the poss
On Fri, Mar 19, 2021 at 7:06 PM Andy Shevchenko
wrote:
>
> On Fri, Mar 19, 2021 at 06:00:38PM +0100, Rafael J. Wysocki wrote:
> > On Fri, Mar 12, 2021 at 5:02 PM Andy Shevchenko
> > wrote:
> > >
> > > Current mechanism of incrementing and decrementing pl
On Fri, Mar 12, 2021 at 5:02 PM Andy Shevchenko
wrote:
>
> Current mechanism of incrementing and decrementing plain integer
> to get a next free instance_no when creating an ACPI device is fragile.
>
> In case of hot plug event or namespace removal of the device instances
> with the low numbers th
On Sat, Mar 13, 2021 at 4:17 AM Randy Dunlap wrote:
>
> On 3/12/21 5:55 PM, Tom Saeger wrote:
> > Fix trivial ACPI driver comment typos.
> >
> > s/notifcations/notifications/
> > s/Ajust/Adjust/
> > s/preform/perform/
> > s/atrributes/attributes/
> > s/Souce/Source/
> > s/Evalutes/Evaluates/
> > s
On Sat, Mar 13, 2021 at 11:27 AM Pavel Machek wrote:
>
> On Fri 2021-03-12 11:24:30, chris.c...@canonical.com wrote:
> > From: Chris Chiu
> >
> > The .callback of the quirk for Sony VPCEH3U1E was unintetionally
> > removed by the commit 25417185e9b5 ("ACPI: video: Add DMI quirk
> > for GIGABYTE G
On Thu, Mar 11, 2021 at 12:50 PM Andy Shevchenko
wrote:
>
> On Thu, Mar 11, 2021 at 11:25:21AM +0300, Heikki Krogerus wrote:
> > Making Andy and myself (Heikki) the designated reviewers of
> > the thing. The software node mailing list shall be
> > linux-a...@vger.kernel.org for now.
>
> Acked-by:
On Wed, Mar 17, 2021 at 6:17 AM Randy Dunlap wrote:
>
> On 3/16/21 10:06 PM, Bhaskar Chowdhury wrote:
> >
> > s/folowing/following/
> >
> > Signed-off-by: Bhaskar Chowdhury
>
> Acked-by: Randy Dunlap
>
> > ---
> > include/acpi/cppc_acpi.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-
ssor_get_pstate':
> > warning: format '%lx' expects argument of type 'long unsigned int',
> > but argument 3 has type 's64' {aka 'long long int'} [-Wformat=]
> >
> > CC: "Rafael J. Wysocki"
> > CC: Vire
ch is enabled by default.
>
> This also exports sched_setattr_nocheck() as the CPPC driver can be
> built as a module.
>
> Cc: linux-a...@vger.kernel.org
> Reviewed-by: Ionela Voinescu
> Tested-by: Ionela Voinescu
> Tested-by: Vincent Guittot
> Signed-off-by: Viresh Kuma
to improve the handling
of suppliers during PM-runtime suspend of a consumer device, but
it introduced a race condition potentially leading to unexpected
behavior (Rafael Wysocki).
Thanks!
---
Josef Bacik (1):
Revert "PM: ACPI: reboot: Use S5 for reboot"
From: "Rafael J. Wysocki"
Revert commit 44cc89f76464 ("PM: runtime: Update device status
before letting suppliers suspend") that introduced a race condition
into __rpm_callback() which allowed a concurrent rpm_resume() to
run and resume the device prematurely after its status
From: Rafael J. Wysocki
Because the PM-runtime status of the device is not updated in
__rpm_callback(), attempts to suspend the suppliers of the given
device triggered by the rpm_put_suppliers() call in there may
cause a supplier to be suspended completely before the status of
the consumer is
On Thursday, March 18, 2021 7:06:54 PM CET Rafael J. Wysocki wrote:
> Hi All,
>
> The previous attempt to address the issue tackled by this series, commit
> 44cc89f76464 ("PM: runtime: Update device status before letting suppliers
> suspend") was incorrect, because it
On Friday, March 19, 2021 8:37:51 AM CET Viresh Kumar wrote:
> On 18-03-21, 22:28, Peter Zijlstra wrote:
> > Also, is there a lock order comment in cpufreq somewhere?
>
> I don't think so.
>
> > I tried
> > following it, but eventually gave up and figured 'asking' lockdep was
> > far simpler.
>
On Fri, Mar 19, 2021 at 2:30 PM Ulf Hansson wrote:
>
> On Thu, 18 Mar 2021 at 19:15, Rafael J. Wysocki wrote:
> >
> > From: Rafael J. Wysocki
> >
> > Because the PM-runtime status of the device is not updated in
> > __rpm_callback(), attempts to suspend t
On Fri, Mar 19, 2021 at 2:31 PM Ulf Hansson wrote:
>
> On Thu, 18 Mar 2021 at 19:15, Rafael J. Wysocki wrote:
> >
> > From: "Rafael J. Wysocki"
> >
> > Revert commit 44cc89f76464 ("PM: runtime: Update device status
> > before letting suppliers
On Sun, Feb 7, 2021 at 11:47 PM Colin King wrote:
>
> From: Colin Ian King
>
> There are three occurrances of u32 variables being multiplied by
> 1000 using 32 bit multiplies and the result being assigned to a
> 64 bit signed integer. These can potentially lead to a 32 bit
> overflows, so fix th
On Wed, Feb 24, 2021 at 6:44 AM Yue Hu wrote:
>
> From: Yue Hu
>
> Note that sugov_update_next_freq() may return false, that means the
> caller sugov_fast_switch() will do nothing except fast switch check.
>
> Similarly, sugov_deferred_update() also has unnecessary operations
> of raw_spin_{lock,
On Tue, Mar 2, 2021 at 3:05 AM Pu Wen wrote:
>
> Enable Hygon Fam18h RAPL support for the power capping framework.
>
> Signed-off-by: Pu Wen
> ---
> drivers/powercap/intel_rapl_common.c | 1 +
> drivers/powercap/intel_rapl_msr.c| 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drive
On Thu, Mar 4, 2021 at 8:30 PM Ulf Hansson wrote:
>
> Runtime resuming a device upfront in the genpd_prepare() callback, to check
> if there is a wakeup pending for it, seems like an unnecessary thing to do.
> The PM core already manages these kind of things in a common way in
> __device_suspend()
From: Rafael J. Wysocki
It is reported that on certain platforms there are power resources
that are not associated with any devices physically present in the
platform. Those power resources are expected to be turned off by
the OS in accordance with the ACPI specification (section 7.3 of
ACPI
From: Rafael J. Wysocki
According to the ACPI specification (section 7.2.2 in ACPI 6.4), the
OS may evaluate the _OFF method of a power resource that is "off"
already [1], and in particular that can be done in the case of unused
power resources.
According
Hi,
Power resources that aren't associated with any devices are expected to be
turned off by the OS, but Linux only does that during resume from
suspend-to-RAM. That turns out to be problematic, so turn them off during
system initialization too (patch [1/2]).
In addition to that, turn them off u
Hi All,
The previous attempt to address the issue tackled by this series, commit
44cc89f76464 ("PM: runtime: Update device status before letting suppliers
suspend") was incorrect, because it introduced a rather nasty race condition
into __rpm_callback(), so let's revert it (patch [1/2]).
Instead,
From: "Rafael J. Wysocki"
Revert commit 44cc89f76464 ("PM: runtime: Update device status
before letting suppliers suspend") that introduced a race condition
into __rpm_callback() which allowed a concurrent rpm_resume() to
run and resume the device prematurely after its status
From: Rafael J. Wysocki
Because the PM-runtime status of the device is not updated in
__rpm_callback(), attempts to suspend the suppliers of the given
device triggered by the rpm_put_suppliers() call in there may fail.
To fix this (1) modify __rpm_callback() to avoid attempting to
actually
On Thu, Mar 18, 2021 at 6:33 PM Asutosh Das (asd)
wrote:
>
> On 3/18/2021 7:00 AM, Rafael J. Wysocki wrote:
> > On Wed, Mar 17, 2021 at 7:37 AM Adrian Hunter
> > wrote:
> >>
> >> On 16/03/21 10:35 pm, Asutosh Das (asd) wrote:
> >>> On 3/16/2021 1
On 3/18/2021 6:42 AM, Kai-Heng Feng wrote:
On Thu, Mar 18, 2021 at 1:25 AM Josef Bacik wrote:
[snipped]
"shutdown now" works fine with and without your patch. Thanks,
Rafael,
Please revert the patch while we are working on it.
Done, thanks!
Josef,
Can you please test the following patch:
On Wed, Mar 17, 2021 at 11:28 PM George Kennedy
wrote:
>
>
>
> On 3/17/2021 4:14 PM, Rafael J. Wysocki wrote:
> > On Monday, March 15, 2021 5:19:29 PM CET Rafael J. Wysocki wrote:
> >> On Sun, Mar 14, 2021 at 8:00 PM Mike Rapoport wrote:
> >>> On Thu, Mar
On Thu, Mar 18, 2021 at 11:50 AM Rafael J. Wysocki wrote:
>
> On Thu, Mar 18, 2021 at 8:25 AM Mike Rapoport wrote:
> >
> > On Wed, Mar 17, 2021 at 09:14:37PM +0100, Rafael J. Wysocki wrote:
> > > On Monday, March 15, 2021 5:19:29 PM CET Rafael J. Wysocki wrote:
> &
t;>> On 10/03/21 5:04 am, Asutosh Das (asd) wrote:
> >>>>> On 3/9/2021 7:56 AM, Asutosh Das (asd) wrote:
> >>>>>> On 3/8/2021 9:17 AM, Rafael J. Wysocki wrote:
> >>>>>>> On Mon, Mar 8, 2021 at 5:21 PM Rafael J
On Wed, Mar 17, 2021 at 10:27 PM Paul Menzel wrote:
>
> Dear Rafael,
>
>
> Am 17.03.21 um 17:49 schrieb Rafael J. Wysocki:
> > From: Rafael J. Wysocki
> >
> > It is reported that on certain platforms unused ACPI power resources
> > that have not been exp
On Thu, Mar 18, 2021 at 8:25 AM Mike Rapoport wrote:
>
> On Wed, Mar 17, 2021 at 09:14:37PM +0100, Rafael J. Wysocki wrote:
> > On Monday, March 15, 2021 5:19:29 PM CET Rafael J. Wysocki wrote:
> > > On Sun, Mar 14, 2021 at 8:00 PM Mike Rapoport wrote:
> > > >
&
On Monday, March 15, 2021 5:19:29 PM CET Rafael J. Wysocki wrote:
> On Sun, Mar 14, 2021 at 8:00 PM Mike Rapoport wrote:
> >
> > On Thu, Mar 11, 2021 at 04:36:31PM +0100, Rafael J. Wysocki wrote:
> > > On Wed, Mar 10, 2021 at 8:47 PM David Hildenbrand
> > > wr
From: Rafael J. Wysocki
It is reported that on certain platforms unused ACPI power resources
that have not been explicitly turned off prevent the platform from
reaching the lowest power state in suspend-to-idle which leads to
excessive power draw.
For this reason, turn all of the unused ACPI
From: Rafael J. Wysocki
For convenience, add empty stubs of library functions defined in
cppc_acpi.c for the CONFIG_ACPI_CPPC_LIB unset case.
Because one of them needs to return CPUFREQ_ETERNAL, include
linux/cpufreq.h into the CPPC library header file and drop the
direct inclusion of it from
From: Rafael J. Wysocki
Notice that some computations related to frequency in intel_pstate
can be simplified if (a) intel_pstate_get_hwp_max() updates the
relevant members of struct cpudata by itself and (b) the "turbo
disabled" check is moved from it to its callers, so modif
From: Rafael J. Wysocki
It should not be necessary to update the current_state field of
struct pci_dev in pci_enable_device_flags() before calling
do_pci_enable_device() for the device, because none of the
code between that point and the pci_set_power_state() call in
do_pci_enable_device
On 3/16/2021 3:53 PM, Frederic Weisbecker wrote:
On Tue, Mar 16, 2021 at 03:35:37PM +0100, Peter Zijlstra wrote:
On Tue, Mar 16, 2021 at 02:37:03PM +0100, Frederic Weisbecker wrote:
On Tue, Mar 16, 2021 at 01:21:29PM +0100, Peter Zijlstra wrote:
On Thu, Mar 11, 2021 at 01:36:59PM +0100, Freder
On Mon, Mar 15, 2021 at 7:28 PM Maximilian Luz wrote:
>
> On 3/15/21 4:34 PM, Rafael J. Wysocki wrote:
> > On Sun, Mar 14, 2021 at 1:06 AM Maximilian Luz
> > wrote:
> >>
> >> On some devices and platforms, the initial platform (e.g. ACPI) power
> >>
On Mon, Mar 15, 2021 at 5:19 PM Rafael J. Wysocki wrote:
>
> On Sun, Mar 14, 2021 at 8:00 PM Mike Rapoport wrote:
> >
> > On Thu, Mar 11, 2021 at 04:36:31PM +0100, Rafael J. Wysocki wrote:
> > > On Wed, Mar 10, 2021 at 8:47 PM David Hildenbrand
> > > wrot
On Sun, Mar 14, 2021 at 8:00 PM Mike Rapoport wrote:
>
> On Thu, Mar 11, 2021 at 04:36:31PM +0100, Rafael J. Wysocki wrote:
> > On Wed, Mar 10, 2021 at 8:47 PM David Hildenbrand wrote:
> > > >
> > > > There is some care that should be taken to make sure w
On Sun, Mar 14, 2021 at 1:06 AM Maximilian Luz wrote:
>
> On some devices and platforms, the initial platform (e.g. ACPI) power
> state is not in sync with the power state of the PCI device.
>
> This seems like it is, for all intents and purposes, an issue with the
> device firmware (e.g. ACPI). O
101 - 200 of 9612 matches
Mail list logo
