在 2025/3/3 11:43, Sathyanarayanan Kuppuswamy 写道:
On 2/16/25 6:42 PM, Shuai Xue wrote:
The AER driver has historically avoided reading the configuration space of
an endpoint or RCiEP that reported a fatal error, considering the link to
that device unreliable. Consequently, when a fatal error
13.2.0
archsdk_defconfiggcc-13.2.0
arc nsimosci_hs_smp_defconfiggcc-13.2.0
arc randconfig-001-20250302gcc-13.2.0
arc randconfig-002-20250302gcc-13.2.0
arm allmodconfiggcc-
On architectures where ARCH_HAS_SYNC_CORE_BEFORE_USERMODE
is not selected, sync_core_before_usermode() is a no-op.
In membarrier_mm_sync_core_before_usermode() the compiler does not
eliminate redundant branches and load of mm->membarrier_state
for this case as the atomic_read() cannot be optimized
On 2/16/25 6:42 PM, Shuai Xue wrote:
The AER driver has historically avoided reading the configuration space of
an endpoint or RCiEP that reported a fatal error, considering the link to
that device unreliable. Consequently, when a fatal error occurs, the AER
and DPC drivers do not report specif
在 2025/3/3 11:36, Sathyanarayanan Kuppuswamy 写道:
On 2/16/25 6:42 PM, Shuai Xue wrote:
The current implementation of pcie_do_recovery() assumes that the
recovery process is executed on the device that detected the error.
However, the DPC driver currently passes the error port that experienced
to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Madhavan-Srinivasan/powerpc-perf-hv-24x7-Avoid-loading-hv-24x7-during-dump-kernel/20250302-022531
base: https://git.kernel.org/pub
[Sorry, I wanted to reply earlier, but it stayed in my drafts folder for a
month]
On Sat, Feb 01, 2025 at 12:22:51PM +1100, Paul Mackerras wrote:
[snipped]
>
> 603 was a looong time ago, I don't recall the details.
>
> Regarding broadcast TLBIEs, the protocols and mechanisms for doing
> that
to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Madhavan-Srinivasan/powerpc-perf-hv-24x7-Avoid-loading-hv-24x7-during-dump-kernel/20250302-022531
base: https://git.kernel.org/pub
在 2025/2/17 10:42, Shuai Xue 写道:
changes since v3:
- squash patch 1 and 2 into one patch per Sathyanarayanan
- add comments note for dpc_process_error per Sathyanarayanan
- pick up Reviewed-by tag from Sathyanarayanan
changes since v2:
- moving the "err_port" rename to a separate patch per Sa
On 2/16/25 6:42 PM, Shuai Xue wrote:
The current implementation of pcie_do_recovery() assumes that the
recovery process is executed on the device that detected the error.
However, the DPC driver currently passes the error port that experienced
the DPC event to pcie_do_recovery().
Use the SOURC
While wondering if it was correct to call mdiobus_free() in the remove
function and only kfree() in the error handling of the probe, I
arrived at the conclusion that the code could be simpler here.
Patch 1 uses mdiobus_alloc_size() instead of a hand written
mdiobus_alloc() + kzalloc(). it also use
Use mdiobus_alloc_size() instead of a hand written mdiobus_alloc() +
kzalloc().
This is less verbose and more robust. It also reduces memory fragmentation
and saves a few bytes of memory.
While at it, switch to devm_mdiobus_alloc_size() for extra simplification.
Signed-off-by: Christophe JAILLET
Use devm_of_mdiobus_register() in order to remove the now empty .remove()
function.
Doing so dev_set_drvdata() is now also unneeded. Remove it as well.
Signed-off-by: Christophe JAILLET
---
This patch is compile tested only.
---
arch/powerpc/platforms/pasemi/gpio_mdio.c | 15 +--
1
Hello Ritesh,
Thanks for the review.
On 02/03/25 12:05, Ritesh Harjani (IBM) wrote:
Sourabh Jain writes:
The fadump kernel boots with limited memory solely to collect the kernel
core dump. Having gigantic hugepages in the fadump kernel is of no use.
Sure got it.
Many times, the fadump ke
Hello Ritesh,
Thanks for the review.
On 02/03/25 12:05, Ritesh Harjani (IBM) wrote:
Sourabh Jain writes:
The fadump kernel boots with limited memory solely to collect the kernel
core dump. Having gigantic hugepages in the fadump kernel is of no use.
Sure got it.
Many times, the fadump ker
On Friday 28 February 2025 09:30:38 Andrey Albershteyn wrote:
> On 2025-02-21 20:15:24, Amir Goldstein wrote:
> > On Fri, Feb 21, 2025 at 7:13 PM Darrick J. Wong wrote:
> > >
> > > On Tue, Feb 11, 2025 at 06:22:47PM +0100, Andrey Albershteyn wrote:
> > > > From: Andrey Albershteyn
> > > >
> > > >
16 matches
Mail list logo
