On Thu, 7 Mar 2019 20:42:16 +0900
William Breathitt Gray wrote:
> On Wed, Mar 06, 2019 at 12:12:07PM +0100, Patrick Havelange wrote:
> > This adds documentation for the specific prescaler entry.
> >
> > Signed-off-by: Patrick Havelange
> > ---
> > Changes v2
> > - Add doc for prescaler entry
>
k.
Otherwise I'm happy enough,
Reviewed-by: Jonathan Cameron
> ---
> Changes v2
> - Rebased on new counter subsystem
> - Cleaned up included headers
> - Use devm_ioremap()
> - Correct order of devm_ and unmanaged resources
> ---
> drivers/counter/Kconfig
On Tue, 12 Mar 2019 14:09:52 -0500
Rob Herring wrote:
> On Wed, Mar 06, 2019 at 12:12:05PM +0100, Patrick Havelange wrote:
> > FlexTimer quadrature decoder driver.
> >
> > Signed-off-by: Patrick Havelange
> > Reviewed-by: Esben Haabendal
> > ---
> > Changes v2
> > - None
> > ---
> > .../
On Tue, 2 Apr 2019 15:30:35 +0900
William Breathitt Gray wrote:
> Changes in v10:
> - Fix minor typographical errors in documentation
> - Merge the FlexTimer Module Quadrature decoder counter driver patches
>
> This revision is functionally identical to the last; changes in this
> version w
checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann
> ---
For IIO part.
Acked-by: Jonathan Cameron
Thanks,
> diff --git a/drivers/iio/industri
On Wed, 5 Sep 2018 18:59:18 +0300
Mike Rapoport wrote:
> All architecures use memblock for early memory management. There is no need
> for the CONFIG_HAVE_MEMBLOCK configuration option.
>
> Signed-off-by: Mike Rapoport
Hi Mike,
A minor editing issue in here that is stopping boot on arm64 plat
On Wed, 19 Sep 2018 13:34:57 +0300
Mike Rapoport wrote:
> Hi Jonathan,
>
> On Wed, Sep 19, 2018 at 10:04:49AM +0100, Jonathan Cameron wrote:
> > On Wed, 5 Sep 2018 18:59:18 +0300
> > Mike Rapoport wrote:
> >
> > > All architecures use memblock for
27;ve eyeballed it rather than testing the results
Acked-by: Jonathan Cameron
On Mon, 18 Feb 2019 15:03:18 +0100
Patrick Havelange wrote:
> This driver exposes the counter for the quadrature decoder of the
> FlexTimer Module, present in the LS1021A soc.
>
> Signed-off-by: Patrick Havelange
> Reviewed-by: Esben Haabendal
Given you cc'd William, I'm guessing you know abou
On Mon, 18 Feb 2019 15:03:21 +0100
Patrick Havelange wrote:
> This is implemented by polling the counter value. A new parameter
> "poll-interval" can be set in the device tree, or can be changed
> at runtime. The reason for the polling is to avoid interrupts flooding.
> If the quadrature input is
for consistency.
>
> Signed-off-by: Arnd Bergmann
For IIO, Acked-by: Jonathan Cameron
Thanks for tidying this up.
Jonathan
> ---
> .../devicetree/bindings/net/nfc/pn544.txt | 2 +-
> arch/arm/boot/dts/sun4i-a10-inet97fv2.dts | 2 +-
> arch/arm/crypto/sha256_glue.c
On Tue, 3 Dec 2019 14:46:34 +1100
Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Tally up the LPC memory on an OpenCAPI link & allow it to be mapped
>
> Signed-off-by: Alastair D'Silva
Hi Alastair,
A few trivial comments inline.
Jonathan
> ---
> drivers/misc/ocxl/core.c | 1
On Tue, 3 Dec 2019 14:46:35 +1100
Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Add functions to map/unmap LPC memory
>
> Signed-off-by: Alastair D'Silva
> ---
> drivers/misc/ocxl/config.c| 4 +++
> drivers/misc/ocxl/core.c | 50 +++
> dri
On Tue, 3 Dec 2019 14:46:36 +1100
Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> This patch retrieves the serial number of the card and makes it available
> to consumers of the ocxl driver via the ocxl_fn struct.
>
> Signed-off-by: Alastair D'Silva
> Acked-by: Frederic Barrat
> Acked-b
On Tue, 3 Dec 2019 14:46:38 +1100
Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> This driver exposes LPC memory on OpenCAPI SCM cards
> as an NVDIMM, allowing the existing nvram infrastructure
> to be used.
>
> Namespace metadata is stored on the media itself, so
> scm_reserve_metadata()
On Tue, 3 Dec 2019 14:46:40 +1100
Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> This patch reads timeouts & firmware version from the controller, and
> uses those timeouts to wait for the controller to report that it is ready
> before handing the memory over to libnvdimm.
>
> Signed-off
On Tue, 3 Dec 2019 14:46:41 +1100
Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> This patch requests the metadata required to issue admin commands, as well
> as some helper functions to construct and check the completion of the
> commands.
>
> Signed-off-by: Alastair D'Silva
A few triv
On Tue, 3 Dec 2019 14:46:42 +1100
Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Similar to the previous patch, this adds support for near storage commands.
>
> Signed-off-by: Alastair D'Silva
> ---
> drivers/nvdimm/ocxl/scm.c | 6 +
> drivers/nvdimm/ocxl/scm_internal.c |
On Tue, 3 Dec 2019 14:46:52 +1100
Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> The near storage command 'Secure Erase' overwrites all data on the
> media.
>
> This patch hooks it up to the security function 'overwrite'.
>
> Signed-off-by: Alastair D'Silva
A few things to tidy up in
On Tue, 3 Dec 2019 14:46:50 +1100
Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> The heartbeat admin command is a simple admin command that exercises
> the communication mechanisms within the controller.
>
> This patch issues a heartbeat command to the card during init to ensure
> we can
On Thu, 13 Apr 2023 15:38:07 +0200
Robert Richter wrote:
> On 12.04.23 16:29:01, Bjorn Helgaas wrote:
> > On Tue, Apr 11, 2023 at 01:03:02PM -0500, Terry Bowman wrote:
> > > From: Robert Richter
> > >
> > > RCEC AER corrected and uncorrectable internal errors (CIE/UIE) are
> > > disabled by d
On Wed, 12 Apr 2023 16:29:01 -0500
Bjorn Helgaas wrote:
> On Tue, Apr 11, 2023 at 01:03:02PM -0500, Terry Bowman wrote:
> > From: Robert Richter
> >
> > RCEC AER corrected and uncorrectable internal errors (CIE/UIE) are
> > disabled by default.
>
> "Disabled by default" just means "the power
On Fri, 14 Apr 2023 13:21:37 +0200
Robert Richter wrote:
> On 13.04.23 15:52:36, Ira Weiny wrote:
> > Jonathan Cameron wrote:
> > > On Wed, 12 Apr 2023 16:29:01 -0500
> > > Bjorn Helgaas wrote:
> > >
> > > > On Tue, Apr 11, 2023 at 01:03:
On Tue, 11 Apr 2023 13:03:01 -0500
Terry Bowman wrote:
> From: Robert Richter
>
> In Restricted CXL Device (RCD) mode a CXL device is exposed as an
> RCiEP, but CXL downstream and upstream ports are not enumerated and
> not visible in the PCIe hierarchy. Protocol and link errors are sent
> to a
On Fri, 14 Apr 2023 16:35:05 +0200
Robert Richter wrote:
> On 14.04.23 13:19:50, Jonathan Cameron wrote:
> > On Tue, 11 Apr 2023 13:03:01 -0500
> > Terry Bowman wrote:
> >
> > > From: Robert Richter
> > >
> > > In Restricted CXL Device (RCD
On Mon, 24 Apr 2023 13:52:47 +0800
Kai-Heng Feng wrote:
> There are many places that enable and disable AER interrput, so move
interrupt
> them into helpers.
Otherwise looks like a good clean up to me.
FWIW
Reviewed-by: Jonathan Cameron
>
> Reviewed-by: Mika Westerberg
&
.1.3 PCIe DVSEC for CXL Devices
>
> Co-developed-by: Terry Bowman
> Signed-off-by: Terry Bowman
> Signed-off-by: Robert Richter
> Cc: "Oliver O'Halloran"
> Cc: Bjorn Helgaas
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-...@vger.kernel.org
> ---
Reviewed-by: Jonathan Cameron
On Sat, 25 Nov 2023 03:47:41 +0300
George Stark wrote:
> Hello Andy
>
> Thanks for the review.
>
> On 11/24/23 18:28, Andy Shevchenko wrote:
> > On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
> >> Lots of drivers use devm_led_classdev_register() to register their led
> >> obje
cieport :00:1c.5: AER: Correctable error received: :00:1c.5
> - pcieport :00:1c.5: AER: can't find device of ID00e5
> + pcieport :00:1c.5: AER: Correctable error message received from
> :00:1c.5
> + pcieport :00:1c.5: AER: found no error details for :00:1c.5
>
> Signed-off-by: Bjorn Helgaas
LGTM
Reviewed-by: Jonathan Cameron
"u32" as well.
>
> No functional changes intended.
>
> Signed-off-by: Bjorn Helgaas
Another sensible cleanup. FWIW on such simple patches
Reviewed-by: Jonathan Cameron
On Wed, 6 Dec 2023 16:42:29 -0600
Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> The PCIe spec classifies errors as either "Correctable" or "Uncorrectable".
> Previously we printed these as "Corrected" or "Uncorrected". To avoid
> confusion, use the same terms as the spec.
>
> One confusing
On Wed, 17 Apr 2024 14:14:05 +0800
Zhenzhong Duan wrote:
> In some cases the detector of a Non-Fatal Error(NFE) is not the most
> appropriate agent to determine the type of the error. For example,
> when software performs a configuration read from a non-existent
> device or Function, completer wi
On Tue, 23 Apr 2024 02:25:05 +
"Duan, Zhenzhong" wrote:
> >-Original Message-
> >From: Jonathan Cameron
> >Subject: Re: [PATCH v3 1/3] PCI/AER: Store UNCOR_STATUS bits that might
> >be ANFE in aer_err_info
> >
> >On Wed, 17 Ap
On Sun, 28 Apr 2024 03:31:11 +
"Duan, Zhenzhong" wrote:
> Hi Jonathan,
>
> >-Original Message-----
> >From: Jonathan Cameron
> >Subject: Re: [PATCH v3 1/3] PCI/AER: Store UNCOR_STATUS bits that might
> >be ANFE in aer_err_info
> >
I'm going to guess a rebase issue?
Other than that
Acked-by: Jonathan Cameron # for IIO
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> index b7259234ad70..a10a4de3e5fe 100644
> --- a/Documentation
On Mon, 2 Nov 2020 15:42:50 +0100
Mauro Carvalho Chehab wrote:
> Em Mon, 2 Nov 2020 13:46:41 +0100
> Greg Kroah-Hartman escreveu:
>
> > On Mon, Nov 02, 2020 at 12:04:36PM +0100, Fabrice Gasnier wrote:
> > > On 10/30/20 11:09 AM, Mauro Carvalho Chehab wrote:
> > > > Em Fri, 30 Oct 2020 10:
Queued all of the below:
with one tweaked as per your suggestion and the highlighted one dropped on basis
I was already carrying the equivalent - as you pointed out.
I was already carrying the required dependency.
Includes the IIO ones in staging.
Thanks,
Jonathan
p.s. I perhaps foolishly di
w set of memblocks.
>
> memblks[0] = [0x00..0x1f] in node 0
> memblks[1] = [0x20..0x2f] in node MAX_NUM_NODES.
>
> i = 2 off the end of the now reduced array of memblocks, so exit the loop.
> (if we restart the loop here everything will be fine).
>
> Later spars
On Mon, 10 Aug 2020 12:27:24 +1000
Nicholas Piggin wrote:
> Not tested on x86 or arm64, would appreciate a quick test there so I can
> ask Andrew to put it in -mm. Other option is I can disable huge vmallocs
> for them for the time being.
Hi Nicholas,
For arm64 testing with a Kunpeng920.
I ran
On Mon, 10 Aug 2020 12:27:32 +1000
Nicholas Piggin wrote:
> On platforms that define HAVE_ARCH_HUGE_VMAP and support PMD vmaps,
> vmalloc will attempt to allocate PMD-sized pages first, before falling
> back to small pages.
>
> Allocations which use something other than PAGE_KERNEL protections a
On Wed, 12 Aug 2020 13:25:24 +0100
Jonathan Cameron wrote:
> On Mon, 10 Aug 2020 12:27:32 +1000
> Nicholas Piggin wrote:
>
> > On platforms that define HAVE_ARCH_HUGE_VMAP and support PMD vmaps,
> > vmalloc will attempt to allocate PMD-sized pages first, before falling
&g
pabilities that aren't tied to the vendor ID of
> the PCI component.
>
> DVSEC is critical for both the Compute Express Link (CXL) driver as well
> as the driver for OpenCAPI coherent accelerator (OCXL).
>
> Cc: David E. Box
> Cc: Jonathan Cameron
> Cc: Bj
On Tue, 10 Nov 2020 08:26:58 +0100
Mauro Carvalho Chehab wrote:
> Hi Jonathan,
>
> Em Sun, 8 Nov 2020 16:56:21 +
> Jonathan Cameron escreveu:
>
> > > PS.: the IIO subsystem is the one that currently has more duplicated
> > > ABI entries:
> > >
On Thu, 25 Apr 2019 21:36:24 +0200
Greg KH wrote:
> On Sun, Apr 07, 2019 at 03:25:50PM +0100, Jonathan Cameron wrote:
> > On Tue, 2 Apr 2019 15:30:35 +0900
> > William Breathitt Gray wrote:
> >
> > > Changes in v10:
> > > - Fix minor typographical
eq:
> there's a typo at Description
>
> - at sysfs-class-cxl, it is using the ":" character at a
> file preamble, causing it to be misinterpreted as a
> tag.
>
> - On the other files, instead of "What", they use "Where".
>
> S
On Tue, 25 Jul 2017 06:46:26 -0700
"Paul E. McKenney" wrote:
> On Tue, Jul 25, 2017 at 10:26:54PM +1000, Nicholas Piggin wrote:
> > On Tue, 25 Jul 2017 19:32:10 +0800
> > Jonathan Cameron wrote:
> >
> > > Hi All,
> > >
> > > We
On Tue, 25 Jul 2017 08:12:45 -0700
"Paul E. McKenney" wrote:
> On Tue, Jul 25, 2017 at 10:42:45PM +0800, Jonathan Cameron wrote:
> > On Tue, 25 Jul 2017 06:46:26 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Tue, Jul 25, 2017 at 10:26:5
On Tue, 25 Jul 2017 20:53:06 -0700
"Paul E. McKenney" wrote:
> On Wed, Jul 26, 2017 at 12:52:07AM +0800, Jonathan Cameron wrote:
> > On Tue, 25 Jul 2017 08:12:45 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Tue, Jul 25, 2017 at 10:42:45
On Tue, 25 Jul 2017 21:12:17 -0700
"Paul E. McKenney" wrote:
> On Tue, Jul 25, 2017 at 09:02:33PM -0700, David Miller wrote:
> > From: "Paul E. McKenney"
> > Date: Tue, 25 Jul 2017 20:55:45 -0700
> >
> > > On Tue, Jul 25, 2017 at 02:10:29PM -0700, David Miller wrote:
> > >> Just to report,
On Wed, 26 Jul 2017 09:16:23 +0100
Jonathan Cameron wrote:
> On Tue, 25 Jul 2017 21:12:17 -0700
> "Paul E. McKenney" wrote:
>
> > On Tue, Jul 25, 2017 at 09:02:33PM -0700, David Miller wrote:
> > > From: "Paul E. McKenney"
> > > Date:
On Wed, 26 Jul 2017 10:32:32 +0100
Jonathan Cameron wrote:
> On Wed, 26 Jul 2017 09:16:23 +0100
> Jonathan Cameron wrote:
>
> > On Tue, 25 Jul 2017 21:12:17 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Tue, Jul 25, 2017 at 09:02:33PM -0700,
On Wed, 26 Jul 2017 13:28:01 +0100
Jonathan Cameron wrote:
> On Wed, 26 Jul 2017 10:32:32 +0100
> Jonathan Cameron wrote:
>
> > On Wed, 26 Jul 2017 09:16:23 +0100
> > Jonathan Cameron wrote:
> >
> > > On Tue, 25 Jul 2017 21:12:17 -0700
> > > &qu
On Wed, 26 Jul 2017 07:14:17 -0700
"Paul E. McKenney" wrote:
> On Wed, Jul 26, 2017 at 01:28:01PM +0100, Jonathan Cameron wrote:
> > On Wed, 26 Jul 2017 10:32:32 +0100
> > Jonathan Cameron wrote:
> >
> > > On Wed, 26 Jul 2017 09:16:23 +0100
> >
On Wed, 26 Jul 2017 15:23:15 +0100
Jonathan Cameron wrote:
> On Wed, 26 Jul 2017 07:14:17 -0700
> "Paul E. McKenney" wrote:
>
> > On Wed, Jul 26, 2017 at 01:28:01PM +0100, Jonathan Cameron wrote:
> > > On Wed, 26 Jul 2017 10:32:32 +0100
> > > Jon
On Wed, 26 Jul 2017 09:54:32 -0700
David Miller wrote:
> From: "Paul E. McKenney"
> Date: Wed, 26 Jul 2017 08:49:00 -0700
>
> > On Wed, Jul 26, 2017 at 04:33:40PM +0100, Jonathan Cameron wrote:
> >> Didn't leave it long enough. Still bad on 4.10-r
On Wed, 26 Jul 2017 18:13:12 +0100
Jonathan Cameron wrote:
> On Wed, 26 Jul 2017 09:54:32 -0700
> David Miller wrote:
>
> > From: "Paul E. McKenney"
> > Date: Wed, 26 Jul 2017 08:49:00 -0700
> >
> > > On Wed, Jul 26, 2017 at 04:33:40PM +0100, J
On Thu, 27 Jul 2017 05:49:13 -0700
"Paul E. McKenney" wrote:
> On Thu, Jul 27, 2017 at 02:34:00PM +1000, Nicholas Piggin wrote:
> > On Wed, 26 Jul 2017 18:42:14 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Wed, Jul 26, 2017 at 04:22:00PM -0700, David Miller wrote:
> >
> > > > Indeed,
On Thu, 27 Jul 2017 14:49:03 +0100
Jonathan Cameron wrote:
> On Thu, 27 Jul 2017 05:49:13 -0700
> "Paul E. McKenney" wrote:
>
> > On Thu, Jul 27, 2017 at 02:34:00PM +1000, Nicholas Piggin wrote:
> > > On Wed, 26 Jul 2017 18:42:14 -0700
> > > "
On Thu, 27 Jul 2017 09:52:45 -0700
"Paul E. McKenney" wrote:
> On Thu, Jul 27, 2017 at 05:39:23PM +0100, Jonathan Cameron wrote:
> > On Thu, 27 Jul 2017 14:49:03 +0100
> > Jonathan Cameron wrote:
> >
> > > On Thu, 27 Jul 2017 05:49:
On Fri, 28 Jul 2017 20:54:16 +0800
Boqun Feng wrote:
> Hi Jonathan,
>
> FWIW, there is wakeup-missing issue in swake_up() and swake_up_all():
>
> https://marc.info/?l=linux-kernel&m=149750022019663
>
> and RCU begins to use swait/wake last year, so I thought this could be
> relevant.
>
On Fri, 28 Jul 2017 08:44:11 +0100
Jonathan Cameron wrote:
> On Thu, 27 Jul 2017 09:52:45 -0700
> "Paul E. McKenney" wrote:
>
> > On Thu, Jul 27, 2017 at 05:39:23PM +0100, Jonathan Cameron wrote:
> > > On Thu, 27 Jul 2017 14:49:03 +0100
> > > Jon
On Fri, 28 Jul 2017 09:55:29 -0700
"Paul E. McKenney" wrote:
> On Fri, Jul 28, 2017 at 02:24:03PM +0100, Jonathan Cameron wrote:
> > On Fri, 28 Jul 2017 08:44:11 +0100
> > Jonathan Cameron wrote:
>
> [ . . . ]
>
> > Ok. Some info. I disabled a few
On Fri, 28 Jul 2017 12:03:50 -0700
"Paul E. McKenney" wrote:
> On Fri, Jul 28, 2017 at 06:27:05PM +0100, Jonathan Cameron wrote:
> > On Fri, 28 Jul 2017 09:55:29 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Fri, Jul 28, 2017 at 02:24:03
On Wed, 26 Jul 2017 16:15:05 -0700
"Paul E. McKenney" wrote:
> On Wed, Jul 26, 2017 at 03:45:40PM -0700, David Miller wrote:
> > From: "Paul E. McKenney"
> > Date: Wed, 26 Jul 2017 15:36:58 -0700
> >
> > > And without CONFIG_SOFTLOCKUP_DETECTOR, I see five runs of 24 with RCU
> > > CPU stall
On Mon, 31 Jul 2017 08:04:11 -0700
"Paul E. McKenney" wrote:
> On Mon, Jul 31, 2017 at 12:08:47PM +0100, Jonathan Cameron wrote:
> > On Fri, 28 Jul 2017 12:03:50 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Fri, Jul 28, 2017 at 06:27:05
On Mon, 31 Jul 2017 12:09:08 +0100
Jonathan Cameron wrote:
> On Wed, 26 Jul 2017 16:15:05 -0700
> "Paul E. McKenney" wrote:
>
> > On Wed, Jul 26, 2017 at 03:45:40PM -0700, David Miller wrote:
> > > From: "Paul E. McKenney"
> > > Date: W
Sorry - accidental send. No content!
Jonathan
On Mon, 31 Jul 2017 12:55:48 +0100
Jonathan Cameron wrote:
> On Mon, 31 Jul 2017 12:09:08 +0100
> Jonathan Cameron wrote:
>
> > On Wed, 26 Jul 2017 16:15:05 -0700
> > "Paul E. McKenney" wrote:
> >
>
On Tue, 1 Aug 2017 11:46:46 -0700
"Paul E. McKenney" wrote:
> On Mon, Jul 31, 2017 at 04:27:57PM +0100, Jonathan Cameron wrote:
> > On Mon, 31 Jul 2017 08:04:11 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Mon, Jul 31, 2017 at 12:08:47
On Tue, 15 Aug 2017 08:47:43 -0700
"Paul E. McKenney" wrote:
> On Wed, Aug 02, 2017 at 05:25:55PM +0100, Jonathan Cameron wrote:
> > On Tue, 1 Aug 2017 11:46:46 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Mon, Jul 31, 2017 at 04:27:57
On Mon, 21 Aug 2017 16:06:05 +1000
Nicholas Piggin wrote:
> On Mon, 21 Aug 2017 10:52:58 +1000
> Nicholas Piggin wrote:
>
> > On Sun, 20 Aug 2017 14:14:29 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Sun, Aug 20, 2017 at 11:35:14AM -0700, Paul E. McKenney wrote:
> > > > On Sun, Aug
On Tue, 22 Aug 2017 00:19:28 +1000
Nicholas Piggin wrote:
> On Mon, 21 Aug 2017 11:18:33 +0100
> Jonathan Cameron wrote:
>
> > On Mon, 21 Aug 2017 16:06:05 +1000
> > Nicholas Piggin wrote:
> >
> > > On Mon, 21 Aug 2017 10:52:58 +1000
> > > Nich
t; I'm not getting RCU stalls on sparc64 any longer with this patch.
>
> I'm really happy you guys were able to figure out what was going
> wrong. :-)
>
> Feel free to add my Tested-by:
>
Like wise - 16 hours of clean run with the latest
Tested-by: Jonathan Cameron
Thank
r status/mask=2000/
> [13] NonFatalErr
> Uncorrectable errors that may cause Advisory Non-Fatal:
> [18] TLP
>
> Tested-by: Yudong Wang
> Co-developed-by: "Wang, Qingshun"
> Signed-off-by: "Wang, Qingshun"
> Signed-off-by:
uan
Not my most confident review ever as this is nasty and gives
me a headache but your description is good and I think the
implementation looks reasonable.
Reviewed-by: Jonathan Cameron
d-by: "Wang, Qingshun"
> Signed-off-by: "Wang, Qingshun"
> Signed-off-by: Zhenzhong Duan
Reviewed-by: Jonathan Cameron
On Wed, 03 Jul 2024 12:36:56 +0200
Luca Ceresoli wrote:
> Simplify code using of_property_for_each_u32_new() as the two additional
> parameters in of_property_for_each_u32() are not used here.
>
> Signed-off-by: Luca Ceresoli
Acked-by: Jonathan Cameron
On Tue, 16 Jul 2024 14:13:29 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Hi,
>
> Following the discussion about handling of CXL fixed memory windows on
> arm64 [1] I decided to bite the bullet and move numa_memblks from x86 to
> the generic code so they will be available
are in arch/*/mm not
arch/*/kernel so this makes it more consistent with that.
Reviewed-by: Jonathan Cameron
On Wed, 17 Jul 2024 16:32:59 +0200
David Hildenbrand wrote:
> On 16.07.24 13:13, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)"
> >
> > sgi-ip27 is the only system that defines NODE_DATA() differently than
> > the rest of NUMA machines.
> >
> > Add node_data array of struct pglist
t; Signed-off-by: Mike Rapoport (Microsoft)
FWIW rename looks fine
Reviewed-by: Jonathan Cameron
igned-off-by: Mike Rapoport (Microsoft)
Reviewed-by: Jonathan Cameron
On Fri, 19 Jul 2024 17:07:35 +0200
David Hildenbrand wrote:
> >>> - * Allocate node data. Try node-local memory and then any node.
> >>> - * Never allocate in DMA zone.
> >>> - */
> >>> - nd_pa = memblock_phys_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
> >>> - if (!nd_pa) {
> >>> -
given
that file already has mix and match of those and normal prints in
single functions I assume this change is fine and we'll just
see the prints a bit later.
Reviewed-by: Jonathan Cameron
On Tue, 16 Jul 2024 14:13:35 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Allocation of numa_distance uses memblock_phys_alloc_range() to limit
> allocation to be below the last mapped page.
>
> But NUMA initializaition runs after the direct map is populated and
initiali
t; Signed-off-by: Mike Rapoport (Microsoft)
Reviewed-by: Jonathan Cameron
allocation.
>
> Replace memblock_phys_alloc_range() with memblock_alloc().
>
> Signed-off-by: Mike Rapoport (Microsoft)
Indeed seems to be after mapping physical memory, so this looks fine.
Reviewed-by: Jonathan Cameron
t (Microsoft)
Not the most intuitive of function names but I can't immediately
think of a better one.
Reviewed-by: Jonathan Cameron
ort (Microsoft)
Reviewed-by: Jonathan Cameron
On Tue, 16 Jul 2024 14:13:42 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Move code dealing with numa_distance array from arch/x86 to
> mm/numa_memblks.c
It's not really numa memblock related. Is this the best place
to put it?
>
> This code will be later reused by arch_
On Tue, 16 Jul 2024 14:13:44 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Introduce numa_memblks_init() and move some code around to avoid several
> global variables in numa_memblks.
Hi Mike,
Adding the effectively always on memblock_force_top_down
deserves a comment on
On Tue, 16 Jul 2024 14:13:45 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Until now arch_numa was directly translating firmware NUMA information
> to memblock.
>
> Using numa_memblks as an intermediate step has a few advantages:
> * alignment with more battle tested x86 i
On Tue, 16 Jul 2024 14:13:41 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Move code dealing with numa_memblks from arch/x86 to mm/ and add Kconfig
> options to let x86 select it in its Kconfig.
>
> This code will be later reused by arch_numa.
>
> No functional changes.
>
lks are now part of the generic code, move these
> functions from x86 to mm/numa_memblks.c and select
> CONFIG_NUMA_KEEP_MEMINFO when CONFIG_NUMA_MEMBLKS=y for dax and cxl.
>
> Signed-off-by: Mike Rapoport (Microsoft)
Reviewed-by: Jonathan Cameron
Thanks. I'll poke around more next week. Have a good weekend.
Jonathan
hus is fine.
So with that in mind (and it could be completely wrong ;)
Reviewed-by: Jonathan Cameron
> ---
> arch/mips/include/asm/mach-ip27/mmzone.h | 5 -
> arch/mips/sgi-ip27/ip27-memory.c | 5 -
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff
nodes present in the system.
>
> Signed-off-by: Mike Rapoport (Microsoft)
Reviewed-by: Jonathan Cameron
> ---
> arch/mips/sgi-ip27/ip27-smp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/mips/sgi-ip27/ip27-smp.c b/arch/mips/sgi-ip27/ip27-smp.c
> index 5d2
arch_alloc_nodedata() and HAVE_ARCH_NODEDATA_EXTENSION
> from sgi-ip27.
>
> Signed-off-by: Mike Rapoport (Microsoft)
Reviewed-by: Jonathan Cameron
> ---
> arch/mips/Kconfig| 1 -
> arch/mips/sgi-ip27/ip27-memory.c | 10 --
> 2 files changed, 11
user of HAVE_ARCH_NODEDATA_EXTENSION config option
> also remove this option from arch/mips/Kconfig.
>
> Signed-off-by: Mike Rapoport (Microsoft)
These are as you say now identical to the generic form, so
don't need a special version for any reason I can see.
Reviewed-by: Jonatha
On Thu, 1 Aug 2024 09:08:07 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> There are no users of HAVE_ARCH_NODEDATA_EXTENSION left, so
> arch_alloc_nodedata() and arch_refresh_nodedata() are not needed
> anymore.
>
> Replace the call to arch_alloc_nodedata() in free_area_i
when allocation granularity was
> PAGE_SIZE anyway.
>
> Signed-off-by: Mike Rapoport (Microsoft)
> Acked-by: David Hildenbrand
> Reviewed-by: Jonathan Cameron
> Tested-by: Zi Yan # for x86_64 and arm64
One comment unrelated to this patch set as such, just made
more obvious by
; Tested-by: Zi Yan # for x86_64 and arm64
Seems sensible. FWIW (which might just be me not bothering to
read this one again ;)
Reviewed-by: Jonathan Cameron
1 - 100 of 139 matches
Mail list logo
