On Thu, Feb 04, 2021 at 07:18:14PM -0800, John Hubbard wrote:
> Delete the unused "log" variable in xfs_log_cover().
>
> Fixes: 303591a0a9473 ("xfs: cover the log during log quiesce")
> Cc: Brian Foster
> Cc: Christoph Hellwig
> Cc: Darrick J. Wong
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:
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:
>
>
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
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
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
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
itional 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
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, becaus
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.
> >
> >
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 piec
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() 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
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
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
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")
> &g
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.
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
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 replied to
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
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
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 *
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
>
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
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.
>
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
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
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
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
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 Fri, Jan 29, 2021 at 02:27:55PM +0800, Shiyang Ruan wrote:
> With the support of ->rmap(), it is possible to obtain the superblock on
> a mapped device.
>
> If a pmem device is used as one target of mapped device, we cannot
> obtain its superblock directly. With the help of SYSFS, the mapped
On Fri, Jan 29, 2021 at 02:27:56PM +0800, Shiyang Ruan wrote:
> This function is used to handle errors which may cause data lost in
> filesystem. Such as memory failure in fsdax mode.
>
> In XFS, it requires "rmapbt" feature in order to query for files or
> metadata which associated to the
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
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
quot;)
> 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
> ind
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
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
> >
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
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 somet
; 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:
> > >
> > >
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
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
pm-5.11-rc6
with top-most commit fef9c8d28e28a808274a18fbd8cc2685817fd62a
PM: hibernate: flush swap writer after marking
on top of commit 6ee1d745b7c9fd573fba142a2efdad76a9f1cb04
Linux
indicates a potential issue in the code; do you think
it's worth investigation?
Thanks,
Avila
On Mon, Jan 25, 2021 at 4:00 PM J. Avila wrote:
>
> Hello,
>
> This dmesg uses /dev/kmsg; we've verified that we don't see this long
> dmesg time when reading from syslog (via dmesg -S).
On Wed, Jan 27, 2021 at 11:11:17PM -0800, Chaitanya Kulkarni wrote:
> Signed-off-by: Chaitanya Kulkarni
> ---
> fs/iomap/direct-io.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
> index f6c557a1bd25..0737192f7e5c
On Wed, Jan 27, 2021 at 11:11:26PM -0800, Chaitanya Kulkarni wrote:
> Signed-off-by: Chaitanya Kulkarni
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/xfs/xfs_buf.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/fs/xfs/xfs_buf.c b/fs/xfs
On Wed, Jan 27, 2021 at 11:11:25PM -0800, Chaitanya Kulkarni wrote:
> Signed-off-by: Chaitanya Kulkarni
Seems fine to me...
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/xfs/xfs_bio_io.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/fs/xfs
On Wed, Jan 27, 2021 at 11:11:16PM -0800, Chaitanya Kulkarni wrote:
> Signed-off-by: Chaitanya Kulkarni
Looks ok to me,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/iomap/direct-io.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/fs/ioma
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 wrote:
> > On Thu, Jan 28, 2021 at 12:27 PM Calvin Johnson
> > wrote:
> > >
> > > Hi Rafael,
> > >
> > > Thanks for the rev
On Thu, Jan 28, 2021 at 12:27 PM Calvin Johnson
wrote:
>
> Hi Rafael,
>
> Thanks for the review. I'll work on all the comments.
>
> On Fri, Jan 22, 2021 at 08:22:21PM +0100, Rafael J. Wysocki wrote:
> > On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson
> > wro
On Wed, Dec 16, 2020 at 6:47 PM Chang S. Bae wrote:
>
> When the system state switches to these sleep states, the internal key gets
> reset. Since this system transition is transparent to userspace, the
> internal key needs to be restored properly.
>
> Key Locker provides a mechanism to back up
On Thu, Jan 28, 2021 at 9:11 AM Takashi Iwai wrote:
>
> On Thu, 31 Dec 2020 07:03:19 +0100,
> Kai-Heng Feng wrote:
> >
> > HDA controller can't be runtime-suspended after commit 215a22ed31a1
> > ("ALSA: hda: Refactor codjc PM to use direct-complete optimization"),
> > which enables
On Thu, Jan 28, 2021 at 8:21 AM Chaitanya Kulkarni
wrote:
>
Please explain in the changelog why making this change is a good idea.
> Signed-off-by: Chaitanya Kulkarni
> ---
> kernel/power/swap.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git
On Thu, Jan 28, 2021 at 08:46:04AM +0800, Nicolas Boichat wrote:
> On Wed, Jan 27, 2021 at 7:38 AM Dave Chinner wrote:
> >
> > On Tue, Jan 26, 2021 at 01:50:22PM +0800, Nicolas Boichat wrote:
> > > copy_file_range (which calls generic_copy_file_checks) uses the
> > > inode file size to adjust the
d that we tell it the lock is
> always untaken for the purpose of static analisys.
>
> Thanks to Naresh Kamboju for reporting issues with the initial patch.
>
> Signed-off-by: Nicolas Pitre
> Tested-by: Naresh Kamboju
>
> ---
>
> On Mon, 25 Jan 2021, N
On Mon, Jan 25, 2021 at 5:01 AM wrote:
>
> From: Zqiang
>
> Due to kworker also is kernel thread, it's already included
> PF_KTHREAD mask, so remove PF_WQ_WORKER mask.
So you are saying that all threads having PF_WQ_WORKER set must also
have PF_KTHREAD set, right?
That sounds correct, so I'm
On Tue, Jan 26, 2021 at 11:48 PM Borislav Petkov wrote:
>
> On Tue, Jan 26, 2021 at 10:32:01AM -0600, Terry Bowman wrote:
> > From: Yazen Ghannam
> >
> > Refactor duplicated GHES identity logic into is_generic_error().
> >
> > Signed-off-by: Yazen Ghannam
> > Reviewed-by: Robert Richter
> >
ore.kernel.org/linux-pci/20200602223618.GA845676@bjorn-Precision-5520/
>
> I'm happy to merge these given your ack, Rafael, or you can take them if
> they look good to you.
They do look good to me, so
Acked-by: Rafael J. Wysocki
for the whole series.
I don't think it really mat
On Wed, Jan 27, 2021 at 11:24:41AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 25 Jan 2021 17:14:14 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the pidfd tree got a conflict in:
> >
> > fs/xfs/xfs_inode.c
> >
> > between commit:
> >
> > 01ea173e103e
Brian Foster
> Date: Mon, 25 Jan 2021 08:22:56 -0500
> Subject: [PATCH] xfs: fix unused log variable in xfs_log_cover()
>
> The log variable is only used in kernels with asserts enabled.
> Remove it and open code the dereference to avoid unused variable
> warnings.
>
>
shell.
Thanks,
Avila
On Mon, Jan 25, 2021 at 5:32 AM John Ogness wrote:
>
> On 2021-01-22, "J. Avila" wrote:
> > When doing some internal testing on a 5.10.4 kernel, we found that the
> > time taken for dmesg seemed to increase from the order of milliseconds
>
ad back stream mappings")
Signed-off-by: Isaac J. Manjarres
Cc: sta...@vger.kernel.org
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index bcda170..abb1d2
On Sun, Jan 24, 2021 at 12:07 AM Nicolas Pitre wrote:
>
> The clock API splits its interface into sleepable ant atomic contexts:
>
> - clk_prepare/clk_unprepare for stuff that might sleep
>
> - clk_enable_clk_disable for anything that may be done in atomic context
>
> The code handling runtime PM
On Fri, Jan 22, 2021 at 7:05 PM Terry Bowman wrote:
>
> From: Yazen Ghannam
>
> Refactor duplicated GHES identity logic into is_ghes_type().
>
> Signed-off-by: Yazen Ghannam
> Reviewed-by: Robert Richter
> Signed-off-by: Terry Bowman
If Terry was a co-author of the patch, please add a
On Sun, Jan 24, 2021 at 12:35 PM Christophe JAILLET
wrote:
>
> This module is 'cmfsize', not 'cfsize'.
> Fix it.
>
> Signed-off-by: Christophe JAILLET
I'm leaving this one to Bob and Erik, thanks!
> ---
> tools/power/acpi/common/cmfsize.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On Sun, Jan 24, 2021 at 2:49 PM Stephen Berman wrote:
>
> On Mon, 04 Jan 2021 16:38:43 +0100 Stephen Berman
> wrote:
>
> > On Thu, 31 Dec 2020 21:46:11 +0100 "Rafael J. Wysocki"
> > wrote:
> >
> >> ATM, I'm tempted to do s
load driver
> > for the first MODALIAS.
> >
> > So if both ACPI modalias and OF modalias are present, use the latter
> > one to ensure there's only one MODALIAS.
> >
> > Reference: https://github.com/systemd/systemd/pull/18163
> > Cc: AceLan Kao
> >
Hello,
When doing some internal testing on a 5.10.4 kernel, we found that the
time taken for dmesg seemed to increase from the order of milliseconds to
the order of seconds when the dmesg size approached the ~1.2MB limit. After
doing some digging, we found that by reverting all of the patches in
On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson
wrote:
>
> Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
> provide them to be connected to MAC.
>
> Describe properties "phy-handle" and "phy-mode".
>
> Signed-off-by: Calvin Johnson
> ---
>
> Changes in v4:
> - More cleanup
On Fri, Jan 22, 2021 at 7:11 PM Rafael J. Wysocki wrote:
>
> On Fri, Jan 22, 2021 at 6:12 PM Andy Shevchenko
> wrote:
> >
> > On Fri, Jan 22, 2021 at 05:40:41PM +0100, Rafael J. Wysocki wrote:
> > > On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
> > > wro
On Fri, Jan 22, 2021 at 7:13 PM Rafael J. Wysocki wrote:
>
> On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
> wrote:
> >
> > Using fwnode_get_id(), get the reg property value for DT node
> > or get the _ADR object value for ACPI node.
This is not accurate AFAICS, be
On Fri, Jan 22, 2021 at 6:12 PM Andy Shevchenko
wrote:
>
> On Fri, Jan 22, 2021 at 05:40:41PM +0100, Rafael J. Wysocki wrote:
> > On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
> > wrote:
> > >
> > > Using fwnode_get_id(), get the reg property value for DT nod
On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
wrote:
>
> Using fwnode_get_id(), get the reg property value for DT node
> or get the _ADR object value for ACPI node.
>
> Signed-off-by: Calvin Johnson
> ---
>
> Changes in v4:
> - Improve code structure to handle all cases
>
> Changes in v3:
> -
On Fri, Jan 22, 2021 at 5:39 PM Stephen Berman wrote:
>
> On Fri, 22 Jan 2021 17:23:36 +0100 "Rafael J. Wysocki"
> wrote:
>
> > On Thu, Jan 14, 2021 at 7:35 PM Rafael J. Wysocki
> > wrote:
> >>
> >> From: Rafael J. Wysocki
> >&g
On Thu, Jan 14, 2021 at 7:35 PM Rafael J. Wysocki wrote:
>
> From: Rafael J. Wysocki
>
> Calling acpi_thermal_check() from acpi_thermal_notify() directly
> is problematic if _TMP triggers Notify () on the thermal zone for
> which it has been evaluated (which happens on some
On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
wrote:
>
> Using fwnode_get_id(), get the reg property value for DT node
> or get the _ADR object value for ACPI node.
So I'm not really sure if this is going to be generically useful.
First of all, the meaning of the _ADR return value is specific
501 - 600 of 41269 matches
Mail list logo
