n into a
> new function and exporting it instead is better.
>
> Reported-by: kernel test robot
> Fixes: 8c182bd7 ("CPI: processor: Fix CPU0 wakeup in
> acpi_idle_play_dead()")
> Cc: # 5.10+
> Signed-off-by: Vitaly Kuznetsov
Applied as 5.12-rc material, thanks!
On Mon, Mar 22, 2021 at 09:15:38AM +0530, Bhaskar Chowdhury wrote:
> s/sytemcall/syscall/
>
> Signed-off-by: Bhaskar Chowdhury
I forgot to ack this before putting it in for-next, so:
Reviewed-by: Darrick J. Wong
--D
> ---
> Changes from V1:
>Randy's suggestion inco
On Tue, Apr 06, 2021 at 07:16:56PM -0500, Aditya Pakki wrote:
> In gss_pipe_destroy_msg(), in case of error in msg, gss_release_msg
> deletes gss_msg. The patch adds a check to avoid a potential double
> free.
We're already dereferenced msg. Nothing has set gss_msg to NULL. It's
the
Hi,
This series simplifies acpi_bus_check_add() and related code.
It mostly is not expected to alter functionality, except for patch [4/5] that
unifies the handling of device and processor objects.
Please refer to the patch changelogs for details.
Thanks!
From: Rafael J. Wysocki
There is only one caller of acpi_bus_type_and_status() which is
acpi_bus_check_add(), so fold the former into the latter and use
the observation that the initial status of the device is
ACPI_STA_DEFAULT in all cases except for ACPI_BUS_TYPE_PROCESSOR
to simplify the code
From: Rafael J. Wysocki
Rearrange the checks in acpi_bus_check_add() to avoid checking
the "type" twice and take "check_dep" into account only for
ACPI_TYPE_DEVICE objects.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki
---
driver
From: Rafael J. Wysocki
Move the initial status check for ACPI_BUS_TYPE_PROCESSOR objects
into acpi_add_single_object() so it is not necessary to pass the
"sta" argument to it, get rid of that argument from there and update
the callers of that function accordingly.
No intentional
From: Rafael J. Wysocki
Use the observation that the initial status check for
ACPI_BUS_TYPE_PROCESSOR objects can be carried out in the same way
as for ACPI_BUS_TYPE_DEVICE objects and it is not necessary to fail
acpi_add_single_object() if acpi_bus_get_status_handle() returns an
error
From: Rafael J. Wysocki
Notice that it is not necessary to call acpi_get_object_info() from
acpi_add_single_object() in order to pass the pointer returned by it
to acpi_init_device_object() and from there to acpi_set_pnp_ids().
It is more straightforward to call acpi_get_object_info() from
From: Rafael J. Wysocki
Because pstate.max_freq is always equal to the product of
pstate.max_pstate and pstate.scaling and, analogously,
pstate.turbo_freq is always equal to the product of
pstate.turbo_pstate and pstate.scaling, the result of the
max_policy_perf computation
On Wed, Apr 7, 2021 at 1:01 PM Angela Czubak wrote:
>
> On Tue, Mar 30, 2021 at 5:50 PM Mika Westerberg
> wrote:
> >
> > Hi,
> >
> > On Tue, Mar 30, 2021 at 05:09:42PM +0200, Rafael J. Wysocki wrote:
> > > On 3/29/2021 9:52 PM, Angela Czubak wrote:
On Tue, Apr 6, 2021 at 5:51 PM John Garry wrote:
>
> Hi guys,
>
> On next-20210406, I enabled CONFIG_DEBUG_KMEMLEAK and
> CONFIG_DEBUG_TEST_DRIVER_REMOVE for my arm64 system, and see this:
Why exactly do you think that acpi_ev_install_space_handler() leaks memory?
> root@debian:/home/john# more
On Tue, Apr 6, 2021 at 5:39 PM Vitaly Kuznetsov wrote:
>
> "Rafael J. Wysocki" writes:
>
> > On Tue, Apr 6, 2021 at 4:01 PM Vitaly Kuznetsov wrote:
> >>
> >> Commit 8c182bd7 ("ACPI: processor: Fix CPU0 wakeup in
> >> acpi_idle_pl
me wakeup_cpu0() to cond_wakeup_cpu0() and fold wakeup_cpu0() in
> as it has no other users [Rafael J. Wysocki]
> ---
> arch/x86/include/asm/smp.h| 2 +-
> arch/x86/kernel/smpboot.c | 24 ++--
> drivers/acpi/processor_idle.c | 4 +---
> 3 files ch
On Tue, Apr 6, 2021 at 2:50 PM Vitaly Kuznetsov wrote:
>
> Commit 8c182bd7 ("ACPI: processor: Fix CPU0 wakeup in
> acpi_idle_play_dead()") tried to fix CPU0 hotplug breakage by copying
> wakeup_cpu0() + start_cpu0() logic from hlt_play_dead()//mwait_play_dead()
> into acpi_idle_play_dead().
On 4/6/2021 2:49 PM, Zhen Lei wrote:
Delete one of the header files that are included
twice, all included header files are then rearranged alphabetically.
Reviewed-by: Keerthy
Signed-off-by: Zhen Lei
---
drivers/thermal/ti-soc-thermal/ti-bandgap.c | 35 ++---
On Wednesday, March 31, 2021 8:22:54 AM CEST Vitaly Kuznetsov wrote:
> Stephen Rothwell writes:
>
> > Hi all,
> >
> > After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
> > produced this warning:
> >
> > drivers/acpi/processor_idle.c: In function 'acpi_idle_play_dead':
> >
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
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'
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
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
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
> > >
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
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
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;
> >
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
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
On Thu, 2021-03-25 at 08:15 +, Christoph Hellwig wrote:
> On Wed, Mar 24, 2021 at 02:30:35PM -0700, Dan Williams wrote:
> > In preparation for common register mapping facility, introduce a
> > generic
> > container, 'struct cxl_regs', for CXL device register and later
> > component register
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
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 tha
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 certa
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
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
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
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
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. Wysocki (1):
PM
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
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
> >
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
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:
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
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
On Sun, 2021-03-21 at 19:45 +0100, Thomas Hellström (Intel) wrote:
> TTM sets up huge page-table-entries both to system- and device
> memory,
> and we don't want gup to assume there are always valid backing struct
> pages for these. For PTEs this is handled by setting the pte_special
> bit,
> but
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-
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
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
On Mon, Mar 22, 2021 at 03:49:16PM +0100, Miklos Szeredi wrote:
> Remove vfs_ioc_setflags_prepare(), vfs_ioc_fssetxattr_check() and
> simple_fill_fsxattr(), which are no longer used.
>
> Signed-off-by: Miklos Szeredi
Woo hoo, so much boilerplate goes away!
Reviewed-by: Darrick J
On Mon, Mar 22, 2021 at 03:49:08PM +0100, Miklos Szeredi wrote:
> Use the miscattr API to let the VFS handle locking, permission checking and
> conversion.
>
> Signed-off-by: Miklos Szeredi
> Cc: Darrick J. Wong
> ---
> fs/xfs/libxfs/xfs_fs.h | 4 -
> fs/x
On Mon, Mar 22, 2021 at 03:48:59PM +0100, Miklos Szeredi wrote:
> There's a substantial amount of boilerplate in filesystems handling
> FS_IOC_[GS]ETFLAGS/ FS_IOC_FS[GS]ETXATTR ioctls.
>
> Also due to userspace buffers being involved in the ioctl API this is
> difficult to stack, as shown by
> > >
> > > > Greg Kroah-Hartman wrote:
> > > > > J. Bruce Fields (2):
> > > > > Revert "nfsd4: remove check_conflicting_opens warning"
> > > > > Revert "nfsd4: a client's own opens needn't prevent delegati
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
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
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
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
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':
>
On Sun, Mar 21, 2021 at 07:52:41PM -0700, Randy Dunlap wrote:
> On 3/21/21 7:46 PM, Bhaskar Chowdhury wrote:
> >
> > s/sytemcall/systemcall/
> >
> >
> > Signed-off-by: Bhaskar Chowdhury
> > ---
> > fs/xfs/xfs_inode.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff
On Sat, Mar 20, 2021 at 03:20:55PM -0500, Gustavo A. R. Silva wrote:
>
>
> On 3/20/21 15:17, Darrick J. Wong wrote:
> >>>> Below are the results of running xfstests for groups shutdown and log
> >>>> with the following configuration in local.config:
On Sun, Mar 21, 2021 at 01:26:26AM +0530, Bhaskar Chowdhury wrote:
>
> s/filesytem/filesystem/
> s/instrumention/instrumentation/
>
> Signed-off-by: Bhaskar Chowdhury
Looks good to me,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/xfs/xfs_log_recover.c | 4 ++--
On Mon, Mar 15, 2021 at 01:31:17PM -0500, Gustavo A. R. Silva wrote:
>
>
> On 3/10/21 22:47, Darrick J. Wong wrote:
> > On Wed, Mar 10, 2021 at 10:23:02PM -0600, Gustavo A. R. Silva wrote:
> >> There is a regular need in the kernel to provide a way to declare having
>
d
> > outputs it in various formats is also a possible solution. For now, it
> > seems reasonable to put this here since this particular code path is the
> > one that has repeatedly come up in production.
> >
> > Signed-off-by: Chris Down
> > Cc: Chuck Lever
> >
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:
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
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
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/
> >
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
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
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: Viresh Kumar
> > CC: linux...@vger.kernel.org
&
led 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 Kumar
Sorry
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"
Rafael J.
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 sta
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
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
201 - 300 of 41269 matches
Mail list logo
