The for_each_child_of_node_scoped() helper provides a scope-based
clean-up functionality to put the device_node automatically, and
as such, there is no need to call of_node_put() directly.
Thus, use this helper to simplify the code.
Acked-by: Kuninori Morimoto
Signed-off-by: Ai Chao
---
sound/
The for_each_child_of_node_scoped() helper provides a scope-based
clean-up functionality to put the device_node automatically, and
as such, there is no need to call of_node_put() directly.
Thus, use this helper to simplify the code.
Signed-off-by: Ai Chao
---
sound/soc/qcom/lpass-cpu.c |
The for_each_child_of_node_scoped() helper provides a scope-based
clean-up functionality to put the device_node automatically, and
as such, there is no need to call of_node_put() directly.
Thus, use this helper to simplify the code.
Signed-off-by: Ai Chao
---
sound/soc/fsl/imx-card.c | 13 +
The for_each_child_of_node_scoped() helper provides a scope-based
clean-up functionality to put the device_node automatically, and
as such, there is no need to call of_node_put() directly.
Thus, use this helper to simplify the code.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org
The for_each_child_of_node_scoped() helper provides a scope-based
clean-up functionality to put the device_node automatically, and
as such, there is no need to call of_node_put() directly.
Thus, use this helper to simplify the code.
Signed-off-by: Ai Chao
---
sound/ppc/tumbler.c | 5 ++---
1 fi
The for_each_child_of_node_scoped() helper provides a scope-based
clean-up functionality to put the device_node automatically, and
as such, there is no need to call of_node_put() directly.
Thus, use this helper to simplify the code.
Signed-off-by: Ai Chao
---
sound/aoa/soundbus/i2sbus/core.c |
This patch series introduces wrapper functions for_each_child_of_node_scoped().
The for_each_child_of_node_scoped() helper provides a scope-based clean-up
functionality to put the device_node automatically, and as such, there is
no need to call of_node_put() directly.
Thus, use this helper to sim
14.2.0
arc allmodconfiggcc-14.2.0
arc allnoconfiggcc-14.2.0
arc allyesconfiggcc-14.2.0
arc defconfiggcc-14.2.0
arc randconfig-001-20250521gcc-10.5.0
arc rand
Hi Ai
Thank you for the patch
> The for_each_child_of_node_scoped() helper provides a scope-based
> clean-up functionality to put the device_node automatically, and
> as such, there is no need to call of_node_put() directly.
>
> Thus, use this helper to simplify the code.
>
> Signed-off-by: A
On Tue, May 20, 2025 at 04:50:17PM -0500, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> This work is mostly due to Jon Pan-Doh and Karolina Stolarek. I rebased
> this to v6.15-rc1, factored out some of the trace and statistics updates,
> and added some minor cleanups.
>
> I'm sorry to post a v
On Tue, May 20, 2025 at 03:33:45PM -0700, Sathyanarayanan Kuppuswamy wrote:
> On 5/20/25 2:50 PM, Bjorn Helgaas wrote:
> > From: Jon Pan-Doh
> >
> > Spammy devices can flood kernel logs with AER errors and slow/stall
> > execution. Add per-device ratelimits for AER correctable and non-fatal
> > u
On Wed, May 21, 2025 at 11:46:00AM +0100, Jonathan Cameron wrote:
> On Tue, 20 May 2025 16:50:34 -0500
> Bjorn Helgaas wrote:
>
> > From: Jon Pan-Doh
> >
> > Allow userspace to read/write log ratelimits per device (including
> > enable/disable). Create aer/ sysfs directory to store them and any
On Wed, May 21, 2025 at 11:31:21AM +0100, Jonathan Cameron wrote:
> On Tue, 20 May 2025 16:50:32 -0500
> Bjorn Helgaas wrote:
>
> > From: Jon Pan-Doh
> >
> > Spammy devices can flood kernel logs with AER errors and slow/stall
> > execution. Add per-device ratelimits for AER correctable and non-
gcc-14.2.0
arc randconfig-001-20250521gcc-10.5.0
arc randconfig-001-20250522clang-21
arc randconfig-002-20250521gcc-12.4.0
arc randconfig-002-20250522clang-21
arcvdk_hs38_smp_defconfiggcc
On Wed, May 21, 2025 at 10:00:35AM +0100, Jonathan Cameron wrote:
> On Tue, 20 May 2025 16:50:19 -0500
> Bjorn Helgaas wrote:
>
> > From: Bjorn Helgaas
> >
> > DPC Error Source ID is only valid when the DPC Trigger Reason indicates
> > that DPC was triggered due to reception of an ERR_NONFATAL
On Wed, May 21, 2025 at 10:20:41AM +0100, Jonathan Cameron wrote:
> On Tue, 20 May 2025 16:50:21 -0500
> Bjorn Helgaas wrote:
>
> > From: Bjorn Helgaas
> >
> > Previously we decoded the AER Error Source ID in aer_isr_one_error_type(),
> > then again in find_source_device() if we didn't find any
On Wed, May 21, 2025 at 09:52:18AM +0100, Jonathan Cameron wrote:
> On Tue, 20 May 2025 16:50:18 -0500
> Bjorn Helgaas wrote:
>
> > From: Bjorn Helgaas
> >
> > Previously the struct aer_err_info "info" was allocated on the stack
> > without being initialized, so it contained junk except for the
On Sat May 17, 2025 at 3:07 PM MDT, Brigham Campbell wrote:
> These changes fix the following error, which was introduced by commit
> ab1456c5 when Documentation/arch/powerpc/htm.rst was added to the
After submitting this patch, I've become aware that it's customary to
add a machine-parseable "Fix
Since the commit 3d86739c6343 ("floppy: always use the track buffer")
the CROSS_64K() is not used by the driver, remove the leftovers.
Signed-off-by: Andy Shevchenko
---
arch/alpha/include/asm/floppy.h| 19 ---
arch/arm/include/asm/floppy.h | 2 --
arch/m68k/include/asm
On Wed, May 21, 2025 at 10:56:59AM +0100, Jonathan Cameron wrote:
> On Tue, 20 May 2025 16:50:30 -0500
> Bjorn Helgaas wrote:
>
> > From: Karolina Stolarek
> >
> > Some existing logs in pci_print_aer() log with error severity by default.
> > Convert them to depend on error type (consistent with
On Wed, May 21, 2025 at 10:28 AM Likhitha Korrapati
wrote:
>
> Hi Ian,
>
> On 5/21/25 21:15, Ian Rogers wrote:
> > On Wed, May 21, 2025 at 6:03 AM Likhitha Korrapati
> > wrote:
> >>
> >> Hi Arnaldo,
> >>
> >> On 5/14/25 02:43, Arnaldo Carvalho de Melo wrote:
> >>> On Fri, May 02, 2025 at 01:14:32
Hi Ian,
On 5/21/25 21:15, Ian Rogers wrote:
On Wed, May 21, 2025 at 6:03 AM Likhitha Korrapati
wrote:
Hi Arnaldo,
On 5/14/25 02:43, Arnaldo Carvalho de Melo wrote:
On Fri, May 02, 2025 at 01:14:32PM +0530, Mukesh Kumar Chaurasiya wrote:
On Fri, Apr 25, 2025 at 02:46:43PM -0300, Arnaldo Car
On Wed, May 21, 2025 at 10:46:42AM +0100, Jonathan Cameron wrote:
> On Tue, 20 May 2025 16:50:28 -0500
> Bjorn Helgaas wrote:
>
> > From: Bjorn Helgaas
> >
> > As with the AER statistics, we always want to emit trace events, even if
> > the actual dmesg logging is rate limited.
> >
> > Call tr
On Wed, May 21, 2025 at 01:12:20PM +0300, Jarkko Sakkinen wrote:
> > I tried, but the last patch (this one) is based on the series merged
> > on the tip tree, where I introduced tpm_svsm.
> > I can see that series in linux-next merged with commit
> > 16a56ee59ab8ee05e67de35bbb5782ef9cfb4f07,
> > bu
On 5/21/25 7:54 AM, Hans Zhang wrote:
On 2025/5/21 00:09, Sathyanarayanan Kuppuswamy wrote:
On 5/19/25 7:41 AM, Hans Zhang wrote:
On 2025/5/19 22:21, Hans Zhang wrote:
On 2025/5/17 02:10, Sathyanarayanan Kuppuswamy wrote:
On 5/16/25 9:55 AM, Hans Zhang wrote:
The following series i
On Wed, May 21, 2025 at 6:03 AM Likhitha Korrapati
wrote:
>
> Hi Arnaldo,
>
> On 5/14/25 02:43, Arnaldo Carvalho de Melo wrote:
> > On Fri, May 02, 2025 at 01:14:32PM +0530, Mukesh Kumar Chaurasiya wrote:
> >> On Fri, Apr 25, 2025 at 02:46:43PM -0300, Arnaldo Carvalho de Melo wrote:
> >>> Maybe th
On 2025/5/21 00:09, Sathyanarayanan Kuppuswamy wrote:
On 5/19/25 7:41 AM, Hans Zhang wrote:
On 2025/5/19 22:21, Hans Zhang wrote:
On 2025/5/17 02:10, Sathyanarayanan Kuppuswamy wrote:
On 5/16/25 9:55 AM, Hans Zhang wrote:
The following series introduces a new kernel command-line optio
Hi Arnaldo,
On 5/14/25 02:43, Arnaldo Carvalho de Melo wrote:
On Fri, May 02, 2025 at 01:14:32PM +0530, Mukesh Kumar Chaurasiya wrote:
On Fri, Apr 25, 2025 at 02:46:43PM -0300, Arnaldo Carvalho de Melo wrote:
Maybe that max() call in perf_cpu_map__intersect() somehow makes the
compiler happy.
Le 14/05/2025 à 04:06, Paul Mackerras a écrit :
> On Sun, May 11, 2025 at 06:32:25PM +0530, Madhavan Srinivasan wrote:
>>
>> Can you try with this patch, I am testing this in my setup.
>>
>> Maddy
>>
>>
>> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
>> index a0e8b998c9b5..2
On Wed, 21 May 2025, Jonathan Cameron wrote:
> On Tue, 20 May 2025 16:50:34 -0500
> Bjorn Helgaas wrote:
>
> > From: Jon Pan-Doh
> >
> > Allow userspace to read/write log ratelimits per device (including
> > enable/disable). Create aer/ sysfs directory to store them and any
> > future aer conf
The PLPKS enabled PowerVM LPAR sysfs exposes all of the secure boot
secvars irrespective of the key management mode.
The PowerVM LPAR supports static and dynamic key management for secure
boot. The key management option can be updated in the management
console. Only in the dynamic key mode can the
On PLPKS enabled PowerVM LPAR, there is no provision to load signed
third-party kernel modules when the key management mode is static. This
is because keys from secure boot secvars are only loaded when the key
management mode is dynamic.
Allow loading of the trustedcadb and moduledb keys even in t
On a PLPKS enabled PowerVM LPAR, the secvar format property for static
key management is misrepresented as "ibm,plpks-sb-unknown", creating
reason for confusion.
Static key management mode uses fixed, built-in keys. Dynamic key
management mode allows keys to be updated in production to handle
secu
The PLPKS enabled Power LPAR sysfs exposes all of the secure boot secure
variables irrespective of the key management mode. There is support for
both static and dynamic key management and the key management mode can
be updated using the management console. The user can modify the secure
boot secvar
On Tue, 20 May 2025 16:50:34 -0500
Bjorn Helgaas wrote:
> From: Jon Pan-Doh
>
> Allow userspace to read/write log ratelimits per device (including
> enable/disable). Create aer/ sysfs directory to store them and any
> future aer configs.
>
> Update AER sysfs ABI filename to reflect the broader
On Wed, May 21, 2025 at 12:06 PM Andrey Albershteyn wrote:
>
> On 2025-05-21 11:36:31, Amir Goldstein wrote:
> > On Wed, May 21, 2025 at 10:48 AM Andrey Albershteyn
> > wrote:
> > >
> > > On 2025-05-19 21:37:04, Dave Chinner wrote:
> > > > On Thu, May 15, 2025 at 12:33:31PM +0200, Amir Goldstein
On Tue, 20 May 2025 16:50:32 -0500
Bjorn Helgaas wrote:
> From: Jon Pan-Doh
>
> Spammy devices can flood kernel logs with AER errors and slow/stall
> execution. Add per-device ratelimits for AER correctable and non-fatal
> uncorrectable errors that use the kernel defaults (10 per 5s). Logging
On Tue, 20 May 2025, Bjorn Helgaas wrote:
> From: Jon Pan-Doh
>
> Spammy devices can flood kernel logs with AER errors and slow/stall
> execution. Add per-device ratelimits for AER correctable and non-fatal
> uncorrectable errors that use the kernel defaults (10 per 5s). Logging of
> fatal erro
On 2025-05-21 11:36:31, Amir Goldstein wrote:
> On Wed, May 21, 2025 at 10:48 AM Andrey Albershteyn
> wrote:
> >
> > On 2025-05-19 21:37:04, Dave Chinner wrote:
> > > On Thu, May 15, 2025 at 12:33:31PM +0200, Amir Goldstein wrote:
> > > > On Thu, May 15, 2025 at 11:02 AM Christian Brauner
> > >
On Tue, 20 May 2025, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Previously we decoded the AER Error Source ID in aer_isr_one_error_type(),
> then again in find_source_device() if we didn't find any devices with
> errors logged in their AER Capabilities.
>
> Consolidate this so we only decod
On Tue, 20 May 2025, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> aer_isr_one_error() duplicates the Error Source ID logging and AER error
> processing for Correctable Errors and Uncorrectable Errors. Factor out the
> duplicated code to aer_isr_one_error_type().
>
> aer_isr_one_error() doesn
On Wed, May 21, 2025 at 09:13:34AM +0200, Stefano Garzarella wrote:
> On Tue, 20 May 2025 at 22:02, Jarkko Sakkinen wrote:
> > On Tue, May 20, 2025 at 06:06:50PM +0200, Stefano Garzarella wrote:
> > > On Thu, 15 May 2025 at 03:45, Jarkko Sakkinen wrote:
> > > > On Wed, May 14, 2025 at 03:46:30PM
On Tue, 20 May 2025, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> DPC Error Source ID is only valid when the DPC Trigger Reason indicates
> that DPC was triggered due to reception of an ERR_NONFATAL or ERR_FATAL
> Message (PCIe r6.0, sec 7.9.14.5).
>
> When DPC was triggered by ERR_NONFATAL (
On Tue, 20 May 2025, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Previously the struct aer_err_info "info" was allocated on the stack
> without being initialized, so it contained junk except for the fields we
> explicitly set later.
>
> Initialize "info" at declaration so it starts as all ze
On Tue, 20 May 2025, Bjorn Helgaas wrote:
> On Tue, May 20, 2025 at 02:55:32PM +0300, Ilpo Järvinen wrote:
> > On Mon, 19 May 2025, Bjorn Helgaas wrote:
> >
> > > From: Jon Pan-Doh
> > >
> > > Spammy devices can flood kernel logs with AER errors and slow/stall
> > > execution. Add per-device ra
On Tue, 20 May 2025 16:50:31 -0500
Bjorn Helgaas wrote:
> From: Karolina Stolarek
>
> Update name to reflect the broader definition of structs/variables that are
> stored (e.g. ratelimits). This is a preparatory patch for adding rate limit
> support.
>
> [bhelgaas: "aer_report" -> "aer_info"]
On Tue, 20 May 2025 16:50:30 -0500
Bjorn Helgaas wrote:
> From: Karolina Stolarek
>
> Some existing logs in pci_print_aer() log with error severity by default.
> Convert them to depend on error type (consistent with rest of AER logging).
>
> Signed-off-by: Karolina Stolarek
> Signed-off-by: B
On Tue, 20 May 2025 16:50:29 -0500
Bjorn Helgaas wrote:
> From: Karolina Stolarek
>
> When reporting an AER error, we check its type multiple times to determine
> the log level for each message. Do this check only in the top-level
> functions (aer_isr_one_error(), pci_print_aer()) and save the
On Tue, 20 May 2025 16:50:28 -0500
Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> As with the AER statistics, we always want to emit trace events, even if
> the actual dmesg logging is rate limited.
>
> Call trace_aer_event() directly from pci_dev_aer_stats_incr(), where we
> update the statis
On Tue, 20 May 2025 16:50:27 -0500
Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> There are two AER logging entry points:
>
> - aer_print_error() is used by DPC (dpc_process_error()) and native AER
> handling (aer_process_err_devices()).
>
> - pci_print_aer() is used by GHES (aer_reco
On Wed, May 21, 2025 at 10:48 AM Andrey Albershteyn wrote:
>
> On 2025-05-19 21:37:04, Dave Chinner wrote:
> > On Thu, May 15, 2025 at 12:33:31PM +0200, Amir Goldstein wrote:
> > > On Thu, May 15, 2025 at 11:02 AM Christian Brauner
> > > wrote:
> > > >
> > > > On Tue, May 13, 2025 at 11:53:23AM
On Tue, 20 May 2025 16:50:26 -0500
Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Simplify pci_print_aer() by initializing the struct aer_err_info "info"
> with a designated initializer list (it was previously initialized with
> memset()) and using pci_name().
>
> Signed-off-by: Bjorn Helgaas
On Tue, 20 May 2025 16:50:25 -0500
Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Previously the struct aer_err_info "e_info" was allocated on the stack
> without being initialized, so it contained junk except for the fields we
> explicitly set later.
>
> Initialize "e_info" at declaration wit
On Tue, 20 May 2025 16:50:24 -0500
Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Move aer_print_source() earlier in the file so a future change can use it
> from aer_print_error(), where it's easier to rate limit it.
>
> Signed-off-by: Bjorn Helgaas
> Tested-by: Krzysztof Wilczyński
> Revie
On Tue, 20 May 2025 16:50:23 -0500
Bjorn Helgaas wrote:
> From: Jon Pan-Doh
>
> Rename aer_print_port_info() to aer_print_source() to be more descriptive.
> This logs the Error Source ID logged by a Root Port or Root Complex Event
> Collector when it receives an ERR_COR, ERR_NONFATAL, or ERR_FA
On Tue, 20 May 2025 16:50:22 -0500
Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Use PCI_BUS_NUM(), PCI_SLOT(), PCI_FUNC() to extract the bus number,
> device, and function number directly from the Error Source ID. There's no
> need to shift and mask it explicitly.
>
> Signed-off-by: Bjorn H
On Tue, 20 May 2025 16:50:21 -0500
Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Previously we decoded the AER Error Source ID in aer_isr_one_error_type(),
> then again in find_source_device() if we didn't find any devices with
> errors logged in their AER Capabilities.
>
> Consolidate this s
On Tue, 20 May 2025 16:50:20 -0500
Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> aer_isr_one_error() duplicates the Error Source ID logging and AER error
> processing for Correctable Errors and Uncorrectable Errors. Factor out the
> duplicated code to aer_isr_one_error_type().
>
> aer_isr_on
On Wed, May 21, 2025, at 10:48, Andrey Albershteyn wrote:
> On 2025-05-19 21:37:04, Dave Chinner wrote:
>> > +struct fsx_fileattr {
>> > + __u32 fsx_xflags; /* xflags field value (get/set) */
>> > + __u32 fsx_extsize;/* extsize field value (get/set)*/
>> > +
On Tue, 20 May 2025 16:50:19 -0500
Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> DPC Error Source ID is only valid when the DPC Trigger Reason indicates
> that DPC was triggered due to reception of an ERR_NONFATAL or ERR_FATAL
> Message (PCIe r6.0, sec 7.9.14.5).
>
> When DPC was triggered by
On Wednesday 21 May 2025 10:48:26 Andrey Albershteyn wrote:
> On 2025-05-19 21:37:04, Dave Chinner wrote:
> > On Thu, May 15, 2025 at 12:33:31PM +0200, Amir Goldstein wrote:
> > > On Thu, May 15, 2025 at 11:02 AM Christian Brauner
> > > wrote:
> > > >
> > > > On Tue, May 13, 2025 at 11:53:23AM +0
On Tue, 20 May 2025 16:50:18 -0500
Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Previously the struct aer_err_info "info" was allocated on the stack
> without being initialized, so it contained junk except for the fields we
> explicitly set later.
>
> Initialize "info" at declaration so it s
On 2025-05-19 21:37:04, Dave Chinner wrote:
> On Thu, May 15, 2025 at 12:33:31PM +0200, Amir Goldstein wrote:
> > On Thu, May 15, 2025 at 11:02 AM Christian Brauner
> > wrote:
> > >
> > > On Tue, May 13, 2025 at 11:53:23AM +0200, Arnd Bergmann wrote:
> > > > On Tue, May 13, 2025, at 11:17, Andrey
On Tue, 20 May 2025 at 22:02, Jarkko Sakkinen wrote:
> On Tue, May 20, 2025 at 06:06:50PM +0200, Stefano Garzarella wrote:
> > On Thu, 15 May 2025 at 03:45, Jarkko Sakkinen wrote:
> > > On Wed, May 14, 2025 at 03:46:30PM +0200, Stefano Garzarella wrote:
> > > > From: Stefano Garzarella
> > > >
>
64 matches
Mail list logo
