lift numa_memblks to generic code.
>
> Signed-off-by: Mike Rapoport (Microsoft)
> Tested-by: Zi Yan # for x86_64 and arm64
Fair enough given code a few lines up has set the node
for all the memblocks so this should I think give the same
effective result.
Reviewed-by: Jonathan
.
>
> No functional changes.
>
> Signed-off-by: Mike Rapoport (Microsoft)
> Tested-by: Zi Yan # for x86_64 and arm64
Reviewed-by: Jonathan Cameron
>
> Signed-off-by: Mike Rapoport (Microsoft)
> Tested-by: Zi Yan # for x86_64 and arm64
As you say, simple code move and I'll cope with the confusion
of stuff that isn't numa_memblk in that file given the
convenience.
Reviewed-by: Jonathan Cameron
> architecture specific code.
>
> Signed-off-by: Mike Rapoport (Microsoft)
> Tested-by: Zi Yan # for x86_64 and arm64
Just code motion as expected.
Reviewed-by: Jonathan Cameron
ation.
>
> Signed-off-by: Mike Rapoport (Microsoft)
> Tested-by: Zi Yan # for x86_64 and arm64
Good. I was wondering why some of this internal detail was in the header.
Much nicer after this.
Reviewed-by: Jonathan Cameron
ace the memory range boundaries with more portable
> memblock_start_of_DRAM() and memblock_end_of_DRAM().
>
> Signed-off-by: Mike Rapoport (Microsoft)
> Tested-by: Zi Yan # for x86_64 and arm64
Makes sense
Reviewed-by: Jonathan Cameron
> ---
> mm/numa_memblks.c | 4 ++-
ike Rapoport (Microsoft)
> Tested-by: Zi Yan # for x86_64 and arm64
I ran some basic tests on ARM with this. Seems to do the job.
Reviewed-by: Jonathan Cameron
Tested-by: Jonathan Cameron
Works on both ACPI and dsdt boots.
ning is not desirable.
>
> Make sure of_numa_init() returns -EINVAL when no NUMA node information
> was found in the device tree.
>
> Signed-off-by: Mike Rapoport (Microsoft)
Reviewed-by: Jonathan Cameron
and add
> functions required by numa_emulation.
>
> Signed-off-by: Mike Rapoport (Microsoft)
> Tested-by: Zi Yan # for x86_64 and arm64
Reviewed-by: Jonathan Cameron
meters.txt
>
> Suggested-by: Zi Yan
> Signed-off-by: Mike Rapoport (Microsoft)
Reviewed-by: Jonathan Cameron
PI and FDT
> more consistent and I believe will reduce maintenance burden.
>
> And with generic numa_memblks it is (almost) straightforward to enable NUMA
> emulation on arm64 and riscv.
Tested-by: Jonathan Cameron #arm64 + CXL via QEMU
With that one fix in patch 7.
Feel free to figure
On Sun, 4 Aug 2024 10:24:15 +0300
Mike Rapoport wrote:
> On Sat, Aug 03, 2024 at 11:58:13AM -0700, Andrew Morton wrote:
> > On Fri, 2 Aug 2024 10:49:22 +0100 Jonathan Cameron
> > wrote:
> >
> > > > --- a/mm/mm_init.c
> > > > +++ b/mm/mm_init.
some small differences but I've
not analyzed if they matter or not.
Reviewed-by: Jonathan Cameron
> ---
> arch/powerpc/include/asm/uaccess.h | 1 +
> arch/x86/include/asm/uaccess.h | 1 +
> include/linux/uaccess.h| 8
> 3 files changed, 10 insertion
On Tue, 28 May 2024 16:59:11 +0800
Tong Tiangen wrote:
> For the arm64 kernel, when it processes hardware memory errors for
> synchronize notifications(do_sea()), if the errors is consumed within the
> kernel, the current processing is panic. However, it is not optimal.
>
> Take copy_from/to_use
sents
> a hardware error encountered during the copying.
>
> Signed-off-by: Tong Tiangen
LGTM
Reviewed-by: Jonathan Cameron
> ---
> include/linux/highmem.h | 8
> mm/khugepaged.c | 4 ++--
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git
On Tue, 28 May 2024 16:59:13 +0800
Tong Tiangen wrote:
> Currently, many scenarios that can tolerate memory errors when copying page
> have been supported in the kernel[1~5], all of which are implemented by
> copy_mc_[user]_highpage(). arm64 should also support this mechanism.
>
> Due to mte, ar
On Tue, 28 May 2024 16:59:15 +0800
Tong Tiangen wrote:
> For SEA exception, kernel require take some action to recover from memory
> error, such as isolate poison page adn kill failure thread, which are done
> in memory_failure().
>
> During our test, the failure thread cannot be killed due to t
On Tue, 20 Aug 2024 11:02:05 +0800
Tong Tiangen wrote:
> 在 2024/8/19 19:56, Jonathan Cameron 写道:
> > On Tue, 28 May 2024 16:59:13 +0800
> > Tong Tiangen wrote:
> >
> >> Currently, many scenarios that can tolerate memory errors when copying page
> >>
On Fri, 30 Aug 2024 11:24:14 +0800
Jinjie Ruan wrote:
> On 2024/8/29 23:58, Kousik Sanagavarapu wrote:
> > Jinjie Ruan writes:
> >> @@ -1080,17 +1080,13 @@ static int knav_queue_setup_regions(struct
> >> knav_device *kdev,
> >> {
> >>struct device *dev = kdev->dev;
> >>struct knav_re
On Fri, 3 Jan 2025 18:50:35 +0530
Atharva Tiwari wrote:
> i completed the todo on line 886 thats why
>
It is a question, not a todo. So if you wish to
make the change you need to discuss why the answer to that
question was 'yes it makes sense to print an error message here'.
Jonathan
Reviewed-by: Jonathan Cameron
> ---
> drivers/pci/pcie/tlp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pcie/tlp.c b/drivers/pci/pcie/tlp.c
> index 2bf15749cd31..65ac7b5d8a87 100644
> --- a/drivers/pci/pcie/tlp.c
> +++ b/dri
x handling happens autonomously on a low layer and the
> value in eetlp_prefix_max is not programmed anywhere by the kernel
> (i.e., there is no limiter OS can control to prevent sending more
> than n TLP Prefixes).
>
> Signed-off-by: Ilpo Järvinen
Extra explanation looks good to me.
Reviewed-by: Jonathan Cameron
n a separate file.
>
> Move TLP Log handling code to own file under pcie/ subdirectory and
> include it only when AER is enabled.
>
> Signed-off-by: Ilpo Järvinen
Reviewed-by: Jonathan Cameron
Can sort of see this might get used outside AER sometime in the future
but for now this seems sensible.
Jonathan
an this up.
Reviewed-by: Jonathan Cameron
t; Remove the unwanted EXPORT of pcie_read_tlp_log() and remove it from
> include/linux/aer.h.
>
> Link: https://lore.kernel.org/all/20240322193011.GA701027@bhelgaas/
> Signed-off-by: Ilpo Järvinen
FWIW LGTM
Reviewed-by: Jonathan Cameron
On Fri, 13 Sep 2024 17:36:29 +0300
Ilpo Järvinen wrote:
> eetlp_prefix_path in the struct pci_dev tells if End-End TLP Prefixes
> are supported by the path or not, the value is only calculated if
> CONFIG_PCI_PASID is set.
>
> The Max End-End TLP Prefixes field in the Device Capabilities Registe
TLP Prefix Log register
> and the entire length to pcie_read_tlp_log() to be able to read the
> correct number of TLP Prefix DWORDs from the correct offset.
>
> Signed-off-by: Ilpo Järvinen
Trivial comments below
Reviewed-by: Jonathan Cameron
Would have been nice if they'd jus
it) so pr_cont() is now replaced with building the string first.
>
> Signed-off-by: Ilpo Järvinen
A couple of trivial things inline but looks good to me either way.
Reviewed-by: Jonathan Cameron
> diff --git a/drivers/pci/pcie/tlp.c b/drivers/pci/pcie/tlp.c
> index def9dd7b73e8..097ac
gt;
> Signed-off-by: Ilpo Järvinen
Makes sense.
Reviewed-by: Jonathan Cameron
On Fri, 13 Sep 2024 17:36:28 +0300
Ilpo Järvinen wrote:
> Loop variable i counting from 0 upwards does not need to be signed so
> make it unsigned int.
>
> Signed-off-by: Ilpo Järvinen
To me this is unnecessary noise, but it's harmless so no problem
if you really like it.
Jonathan
> ---
> dr
On Thu, 12 Dec 2024 20:48:38 +0200 (EET)
Ilpo Järvinen wrote:
> On Thu, 12 Dec 2024, Ilpo Järvinen wrote:
>
> > On Wed, 11 Dec 2024, Jonathan Cameron wrote:
> >
> > > On Fri, 13 Sep 2024 17:36:30 +0300
> > > Ilpo Järvinen wrote:
> > >
> >
On Fri, 27 Dec 2024 12:49:10 +0530
Atharva Tiwari wrote:
> Log an error message in `find_device_iter'
> when the system cannot handle more error devices.
Needs a statement of 'why'
Jonathan
>
> Signed-off-by: Atharva Tiwari
> ---
> drivers/pci/pcie/aer.c | 2 +-
> 1 file changed, 1 insertion
On Fri, 27 Dec 2024 12:22:53 +0530
Atharva Tiwari wrote:
> update failed in drivers/pci/pcie/err.c to
> trigger a kernel panic instead of pci_info
>
> Thanks
Rewrite message as described in submitting patches documentation.
Key thing here is question of 'why?'
A question was in that comment, w
On Fri, 20 Dec 2024 15:53:11 +0800
Yicong Yang wrote:
> From: Yicong Yang
>
> On building the topology from the devicetree, we've already
> gotten the SMT thread number of each core. Update the largest
> SMT thread number and enable the SMT control by the end of
> topology parsing.
>
> The cor
smt]# cat control
> > off
> > [root@localhost smt]# cat ../online
> > 0,2
> > [root@localhost smt]# echo on > control
> > [root@localhost smt]# cat control
> > on
> > [root@localhost smt]# cat ../online
> > 0-3
>
> Tested with below
On Fri, 20 Dec 2024 15:53:13 +0800
Yicong Yang wrote:
> From: Yicong Yang
>
> Enable HOTPLUG_SMT for SMT control.
>
> Signed-off-by: Yicong Yang
FWIW LGTM
Reviewed-by: Jonathan Cameron
> ---
> arch/arm64/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> d
ps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-devices-system-cpu#n542
> Signed-off-by: Yicong Yang
A few trivial things inline. Either way it's fine as really just my style
preferences
Reviewed-by: Jonathan Cameron
> ---
&
On Tue, 14 Jan 2025 19:08:35 +0200
Ilpo Järvinen wrote:
> Add defines for AER and DPC capabilities TLP Header Logging register
> sizes (PCIe r6.2, sec 7.8.4 / 7.9.14) and replace literals with them.
>
> Suggested-by: Yazen Ghannam
> Signed-off-by: Ilpo Järvinen
Hi Ilpo,
Where it is simply th
e SMT-X (X>1) core
> platform the SMT control is also supported as expected but only
> by writing the "on/off" method.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-devices-system-cpu#n542
> Reviewed-by: Pierre Gondois
> Reviewed-by: Dietmar Eggemann
> Signed-off-by: Yicong Yang
Reviewed-by: Jonathan Cameron
On Thu, 8 May 2025 15:06:07 +0200
Markus Burri wrote:
> The buffer is set to 80 character. If a caller write more characters,
> count is truncated to the max available space in "simple_write_to_buffer".
> But afterwards a string terminator is written to the buffer at offset count
> without bound
were
> notified to extlog_print() via the IOMCA (I/O Machine Check
> Architecture) mechanism. Bring parity to the extlog_print() path by
> including a similar log_non_standard_event().
>
> Cc: Dan Williams
> Reviewed-by: Dan Williams
> Signed-off-by: Fabio M. De Francesco
Makes sen
Fabio M. De Francesco
Fair enough on reasoning and it does what you describe so
Reviewed-by: Jonathan Cameron
_one_error_type().
>
> aer_isr_one_error() doesn't need the struct aer_rpc pointer, so pass it the
> Root Port or RCEC pci_dev pointer instead.
>
> Signed-off-by: Bjorn Helgaas
One passing comment inside (on neighbouring code)
Otherwise it is a sensible bit of cleanup.
Reviewed-by: Jonathan
om
> :02:00.0 (no details found)
>
> Signed-off-by: Bjorn Helgaas
Nice little improvement. I'll assume you reuse
details later as otherwise passing a bool and creating
the (no details found) in aer_print_port_info() would
have been simpler to my eyes as it would have put all the
> Signed-off-by: Bjorn Helgaas
> Tested-by: Krzysztof Wilczyński
> Reviewed-by: Kuppuswamy Sathyanarayanan
>
> Reviewed-by: Ilpo Järvinen
Reviewed-by: Jonathan Cameron
RR_NONFATAL, or ERR_FATAL Message.
>
> [bhelgaas: aer_print_rp_info() -> aer_print_source()]
> Signed-off-by: Jon Pan-Doh
> Signed-off-by: Bjorn Helgaas
> Tested-by: Krzysztof Wilczyński
> Reviewed-by: Ilpo Järvinen
> Reviewed-by: Kuppuswamy Sathyanarayanan
>
Makes sense.
Reviewed-by: Jonathan Cameron
d-by: Krzysztof Wilczyński
> Reviewed-by: Kuppuswamy Sathyanarayanan
>
> Reviewed-by: Ilpo Järvinen
Reviewed-by: Jonathan Cameron
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
t; Signed-off-by: Bjorn Helgaas
> Tested-by: Krzysztof Wilczyński
> Reviewed-by: Ilpo Järvinen
Another nice cleanup.
Reviewed-by: Jonathan Cameron
Reviewed-by: Kuppuswamy Sathyanarayanan
>
Always felt odd that a stat got updated in a _print_ function
so even without the other reasoning this is a good change.
Reviewed-by: Jonathan Cameron
> ---
> drivers/pci/pcie/aer.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletio
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
lpo Järvinen
> Reviewed-by: Kuppuswamy Sathyanarayanan
>
Reviewed-by: Jonathan Cameron
aybe
it would be simpler to just pass it and not care that it always
takes the same value?
Either way this is fine.
Reviewed-by: Jonathan Cameron
> ---
> drivers/pci/pcie/aer.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drive
t;aer_report" -> "aer_info"]
> Signed-off-by: Karolina Stolarek
> Signed-off-by: Bjorn Helgaas
> Tested-by: Krzysztof Wilczyński
> Reviewed-by: Ilpo Järvinen
> Reviewed-by: Kuppuswamy Sathyanarayanan
>
Reviewed-by: Jonathan Cameron
So maybe needs a fixes tag?
info->tlp_header_valid is an easy one to follow as only set in some paths.
Otherwise absolutely makes sense.
Reviewed-by: Jonathan Cameron
> ---
> drivers/pci/pcie/dpc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/
G. Now the single message is at
> KERN_WARNING.
>
> Signed-off-by: Bjorn Helgaas
> Tested-by: Krzysztof Wilczyński
> Reviewed-by: Kuppuswamy Sathyanarayanan
>
Matches the spec conditions as far as I can tell.
I guess interesting debate on whether providing extra garbage info is
a bug
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 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 Sun, 11 May 2025 15:27:07 +0100
Jonathan Cameron wrote:
> On Thu, 8 May 2025 15:06:07 +0200
> Markus Burri wrote:
>
> > The buffer is set to 80 character. If a caller write more characters,
> > count is truncated to the max available space in "simple_write_to_buf
On Thu, 8 May 2025 15:06:09 +0200
Markus Burri wrote:
> The buffer is set to 20 characters. If a caller write more characters,
> count is truncated to the max available space in "simple_write_to_buffer".
> To protect from OoB access, check that the input size fit into buffer and
> add a zero ter
On Thu, 8 May 2025 15:06:09 +0200
Markus Burri wrote:
> The buffer is set to 20 characters. If a caller write more characters,
> count is truncated to the max available space in "simple_write_to_buffer".
> To protect from OoB access, check that the input size fit into buffer and
> add a zero ter
On Wed, 21 May 2025 17:54:30 -0500
Bjorn Helgaas wrote:
> 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 device
On Wed, 21 May 2025 17:59:42 -0500
Bjorn Helgaas wrote:
> 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 u
On Thu, 29 May 2025 16:32:02 +1000
Alistair Popple wrote:
> The PFN_MAP flag is no longer used for anything, so remove it. The
> PFN_SG_CHAIN and PFN_SG_LAST flags never appear to have been used so
> also remove them.
Superficial thing but you seem to be be removing PFN_SPECIAL as well and
this
On Thu, 29 May 2025 16:32:08 +1000
Alistair Popple wrote:
> DAX was the only thing that created pmd_devmap and pud_devmap entries
> however it no longer does as DAX pages are now refcounted normally and
> pXd_trans_huge() returns true for those. Therefore checking both pXd_devmap
> and pXd_trans_
PCIe Error section (UEFI v2.10, Appendix N.2.7) reported
> by the I/O MCA.
>
> Cc: Dan Williams
> Reviewed-by: Dave Jiang
> Signed-off-by: Fabio M. De Francesco
Reviewed-by: Jonathan Cameron
On Mon, 23 Jun 2025 16:54:20 +0200
"Fabio M. De Francesco" wrote:
> When Firmware First is enabled, BIOS handles errors first and then it makes
> them available to the kernel via the Common Platform Error Record (CPER)
> sections (UEFI 2.10 Appendix N). Linux parses the CPER sections via one of
>
101 - 167 of 167 matches
Mail list logo
