* Re: [PATCH] recordmcount: Fix build failure on non arm64
From: Gregory Herrero @ 2020-08-10 9:17 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-arm-kernel, Catalin Marinas, linuxppc-dev, linux-kernel,
Steven Rostedt
In-Reply-To: <5ca1be21fa6ebf73203b45fd9aadd2bafb5e6b15.1597049145.git.christophe.leroy@csgroup.eu>
Hi Christophe,
On Mon, Aug 10, 2020 at 08:48:22AM +0000, Christophe Leroy wrote:
> Commit ea0eada45632 leads to the following build failure on powerpc:
>
> HOSTCC scripts/recordmcount
> scripts/recordmcount.c: In function 'arm64_is_fake_mcount':
> scripts/recordmcount.c:440: error: 'R_AARCH64_CALL26' undeclared (first use in this function)
> scripts/recordmcount.c:440: error: (Each undeclared identifier is reported only once
> scripts/recordmcount.c:440: error: for each function it appears in.)
> make[2]: *** [scripts/recordmcount] Error 1
>
> Make sure R_AARCH64_CALL26 is always defined.
>
Oops, thanks for fixing this.
Acked-by: Gregory Herrero <gregory.herrero@oracle.com>
Greg
> Fixes: ea0eada45632 ("recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.")
> Cc: Gregory Herrero <gregory.herrero@oracle.com>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> scripts/recordmcount.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
> index e59022b3f125..b9c2ee7ab43f 100644
> --- a/scripts/recordmcount.c
> +++ b/scripts/recordmcount.c
> @@ -42,6 +42,8 @@
> #define R_ARM_THM_CALL 10
> #define R_ARM_CALL 28
>
> +#define R_AARCH64_CALL26 283
> +
> static int fd_map; /* File descriptor for file being modified. */
> static int mmap_failed; /* Boolean flag. */
> static char gpfx; /* prefix for global symbol name (sometimes '_') */
> --
> 2.25.0
>
^ permalink raw reply
* Re: [PATCH v2] ASoC: fsl-asoc-card: Get "extal" clock rate by clk_get_rate
From: Nicolin Chen @ 2020-08-10 23:13 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, tiwai, lgirdwood,
perex, broonie, festevam, linux-kernel
In-Reply-To: <1597047103-6863-1-git-send-email-shengjiu.wang@nxp.com>
On Mon, Aug 10, 2020 at 04:11:43PM +0800, Shengjiu Wang wrote:
> On some platform(.e.g. i.MX8QM MEK), the "extal" clock is different
> with the mclk of codec, then the clock rate is also different.
> So it is better to get clock rate of "extal" rate by clk_get_rate,
> don't reuse the clock rate of mclk.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Add -EPROBE_DEFER check for regmap init
From: Nicolin Chen @ 2020-08-10 23:11 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, tiwai, lgirdwood,
perex, broonie, festevam, linux-kernel
In-Reply-To: <1596791682-4311-1-git-send-email-shengjiu.wang@nxp.com>
On Fri, Aug 07, 2020 at 05:14:42PM +0800, Shengjiu Wang wrote:
> Regmap initialization may return -EPROBE_DEFER for clock
> may not be ready, so check -EPROBE_DEFER error type before
> start another Regmap initialization.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal
From: Nathan Lynch @ 2020-08-10 20:03 UTC (permalink / raw)
To: Michael Ellerman; +Cc: tyreld, cheloha, Laurent Dufour, linuxppc-dev
In-Reply-To: <87tuxl1ant.fsf@mpe.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> One thought, which I possibly should not put in writing, is that we
> could use the alignment of the pointer as a poor man's substitute for a
> counter, eg:
>
> +static inline struct drmem_lmb *drmem_lmb_next(struct drmem_lmb *lmb)
> +{
> + if (lmb % PAGE_SIZE == 0)
> + cond_resched();
> +
> + return ++lmb;
> +}
>
> I think the lmbs are allocated in a block, so I think that will work.
> Maybe PAGE_SIZE is not the right size to use, but you get the idea.
>
> Gross I know, but might be OK as short term solution?
OK, looking into this.
^ permalink raw reply
* Re: [PATCH 19/22] crypto: inside-secure - add check for xts input length equal to zero
From: Eric Biggers @ 2020-08-10 17:03 UTC (permalink / raw)
To: Horia Geantă
Cc: Andrei Botila (OSS), Andrei Botila, Herbert Xu,
Van Leeuwen, Pascal, Antoine Tenart, linux-s390@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@axis.com, linux-crypto@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <fd3e5862-3357-7dfc-6c75-30086ab19f82@nxp.com>
On Mon, Aug 10, 2020 at 05:33:39PM +0300, Horia Geantă wrote:
> On 8/10/2020 4:45 PM, Herbert Xu wrote:
> > On Mon, Aug 10, 2020 at 10:20:20AM +0000, Van Leeuwen, Pascal wrote:
> >>
> >> With all due respect, but this makes no sense.
> >
> > I agree. This is a lot of churn for no gain.
> >
> I would say the gain is that all skcipher algorithms would behave the same
> when input length equals zero - i.e. treat the request as a no-op.
>
> We can't say "no input" has any meaning to the other skcipher algorithms,
> but the convention is to accept this case and just return 0.
> I don't see why XTS has to be handled differently.
>
CTS also rejects empty inputs.
The rule it follows is just that all input lengths >= blocksize are allowed.
Input lengths < blocksize aren't allowed.
- Eric
^ permalink raw reply
* Re: [PATCH] Documentation/features: refresh powerpc arch support files
From: Tobias Klauser @ 2020-08-10 15:36 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-doc, linuxppc-dev, Nicholas Piggin, Jonathan Corbet
In-Reply-To: <4b6b65e8-ec79-ebf0-0ab5-7b48182584f1@csgroup.eu>
On 2020-08-10 at 17:09:51 +0200, Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
>
>
> Le 10/08/2020 à 12:09, Tobias Klauser a écrit :
> > Support for these was added by commit aa65ff6b18e0 ("powerpc/64s:
> > Implement queued spinlocks and rwlocks").
> >
> > Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> > ---
> > Documentation/features/locking/queued-rwlocks/arch-support.txt | 2 +-
> > .../features/locking/queued-spinlocks/arch-support.txt | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/features/locking/queued-rwlocks/arch-support.txt b/Documentation/features/locking/queued-rwlocks/arch-support.txt
> > index 5c6bcfcf8e1f..4dd5e554873f 100644
> > --- a/Documentation/features/locking/queued-rwlocks/arch-support.txt
> > +++ b/Documentation/features/locking/queued-rwlocks/arch-support.txt
> > @@ -22,7 +22,7 @@
> > | nios2: | TODO |
> > | openrisc: | ok |
> > | parisc: | TODO |
> > - | powerpc: | TODO |
> > + | powerpc: | ok |
>
> In your commit log you are refering to a commit titled "powerpc/64s:"
>
> Are you sure it is now OK for all powerpc, not only for book3s/64 as
> suggested by yout text ?
The change was generated by running
Documentation/features/scripts/features-refresh.sh
Sorry, I should have mentioned this in the commit message. I noticed the
updated features for powerpc after updating the RISC-V supported
features [1].
[1] https://lore.kernel.org/linux-riscv/20200810095000.32092-1-tklauser@distanz.ch/T/#u
AFAIK, the features-refresh.sh script has no way of distinguishing
between different types of an architecture. It just checks for the
respective Kconfig symbols listed in the
Documentation/features/**/arch-support.txt files in all arch/**/Kconfig
files and updates the feature to "ok" if it finds the Kconfig symbol.
^ permalink raw reply
* Re: [PATCH] Documentation/features: refresh powerpc arch support files
From: Christophe Leroy @ 2020-08-10 15:09 UTC (permalink / raw)
To: Tobias Klauser, Jonathan Corbet; +Cc: linuxppc-dev, Nicholas Piggin, linux-doc
In-Reply-To: <20200810100906.3805-1-tklauser@distanz.ch>
Le 10/08/2020 à 12:09, Tobias Klauser a écrit :
> Support for these was added by commit aa65ff6b18e0 ("powerpc/64s:
> Implement queued spinlocks and rwlocks").
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> ---
> Documentation/features/locking/queued-rwlocks/arch-support.txt | 2 +-
> .../features/locking/queued-spinlocks/arch-support.txt | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/features/locking/queued-rwlocks/arch-support.txt b/Documentation/features/locking/queued-rwlocks/arch-support.txt
> index 5c6bcfcf8e1f..4dd5e554873f 100644
> --- a/Documentation/features/locking/queued-rwlocks/arch-support.txt
> +++ b/Documentation/features/locking/queued-rwlocks/arch-support.txt
> @@ -22,7 +22,7 @@
> | nios2: | TODO |
> | openrisc: | ok |
> | parisc: | TODO |
> - | powerpc: | TODO |
> + | powerpc: | ok |
In your commit log you are refering to a commit titled "powerpc/64s:"
Are you sure it is now OK for all powerpc, not only for book3s/64 as
suggested by yout text ?
Christophe
> | riscv: | TODO |
> | s390: | TODO |
> | sh: | TODO |
> diff --git a/Documentation/features/locking/queued-spinlocks/arch-support.txt b/Documentation/features/locking/queued-spinlocks/arch-support.txt
> index b55e420a34ea..b16d4f71e5ce 100644
> --- a/Documentation/features/locking/queued-spinlocks/arch-support.txt
> +++ b/Documentation/features/locking/queued-spinlocks/arch-support.txt
> @@ -22,7 +22,7 @@
> | nios2: | TODO |
> | openrisc: | ok |
> | parisc: | TODO |
> - | powerpc: | TODO |
> + | powerpc: | ok |
> | riscv: | TODO |
> | s390: | TODO |
> | sh: | TODO |
>
^ permalink raw reply
* [PATCH] Documentation/features: refresh powerpc arch support files
From: Tobias Klauser @ 2020-08-10 10:09 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linuxppc-dev, Nicholas Piggin, linux-doc
Support for these was added by commit aa65ff6b18e0 ("powerpc/64s:
Implement queued spinlocks and rwlocks").
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
Documentation/features/locking/queued-rwlocks/arch-support.txt | 2 +-
.../features/locking/queued-spinlocks/arch-support.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/features/locking/queued-rwlocks/arch-support.txt b/Documentation/features/locking/queued-rwlocks/arch-support.txt
index 5c6bcfcf8e1f..4dd5e554873f 100644
--- a/Documentation/features/locking/queued-rwlocks/arch-support.txt
+++ b/Documentation/features/locking/queued-rwlocks/arch-support.txt
@@ -22,7 +22,7 @@
| nios2: | TODO |
| openrisc: | ok |
| parisc: | TODO |
- | powerpc: | TODO |
+ | powerpc: | ok |
| riscv: | TODO |
| s390: | TODO |
| sh: | TODO |
diff --git a/Documentation/features/locking/queued-spinlocks/arch-support.txt b/Documentation/features/locking/queued-spinlocks/arch-support.txt
index b55e420a34ea..b16d4f71e5ce 100644
--- a/Documentation/features/locking/queued-spinlocks/arch-support.txt
+++ b/Documentation/features/locking/queued-spinlocks/arch-support.txt
@@ -22,7 +22,7 @@
| nios2: | TODO |
| openrisc: | ok |
| parisc: | TODO |
- | powerpc: | TODO |
+ | powerpc: | ok |
| riscv: | TODO |
| s390: | TODO |
| sh: | TODO |
--
2.27.0
^ permalink raw reply related
* Re: [PATCH] recordmcount: Fix build failure on non arm64
From: Catalin Marinas @ 2020-08-10 14:26 UTC (permalink / raw)
To: Gregory Herrero, Steven Rostedt (VMware), Christophe Leroy
Cc: linuxppc-dev, Will Deacon, linux-kernel, linux-arm-kernel
In-Reply-To: <5ca1be21fa6ebf73203b45fd9aadd2bafb5e6b15.1597049145.git.christophe.leroy@csgroup.eu>
On Mon, 10 Aug 2020 08:48:22 +0000 (UTC), Christophe Leroy wrote:
> Commit ea0eada45632 leads to the following build failure on powerpc:
>
> HOSTCC scripts/recordmcount
> scripts/recordmcount.c: In function 'arm64_is_fake_mcount':
> scripts/recordmcount.c:440: error: 'R_AARCH64_CALL26' undeclared (first use in this function)
> scripts/recordmcount.c:440: error: (Each undeclared identifier is reported only once
> scripts/recordmcount.c:440: error: for each function it appears in.)
> make[2]: *** [scripts/recordmcount] Error 1
>
> [...]
Applied to arm64 (for-next/core), thanks!
[1/1] recordmcount: Fix build failure on non arm64
https://git.kernel.org/arm64/c/3df14264ad99
--
Catalin
^ permalink raw reply
* Re: [PATCH 19/22] crypto: inside-secure - add check for xts input length equal to zero
From: Herbert Xu @ 2020-08-10 13:45 UTC (permalink / raw)
To: Van Leeuwen, Pascal
Cc: Andrei Botila, Andrei Botila, linux-s390@vger.kernel.org,
Antoine Tenart, x86@kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@axis.com, linux-crypto@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CY4PR0401MB36528610C3ABF802F8CBF35FC3440@CY4PR0401MB3652.namprd04.prod.outlook.com>
On Mon, Aug 10, 2020 at 10:20:20AM +0000, Van Leeuwen, Pascal wrote:
>
> With all due respect, but this makes no sense.
I agree. This is a lot of churn for no gain.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] recordmcount: Fix build failure on non arm64
From: Steven Rostedt @ 2020-08-10 13:27 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arm-kernel, Gregory Herrero, linuxppc-dev, linux-kernel
In-Reply-To: <20200810121855.GD9480@gaia>
On Mon, 10 Aug 2020 13:18:55 +0100
Catalin Marinas <catalin.marinas@arm.com> wrote:
> > Oops, thanks for fixing this.
> >
> > Acked-by: Gregory Herrero <gregory.herrero@oracle.com>
>
> Thanks. I'll queue it via the arm64 tree (as I did with the previous
> fix) but I'll wait a bit for Steve to ack it.
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH] powerpc/papr_scm: Make access mode of 'perf_stats' attribute file to '0400'
From: Michael Ellerman @ 2020-08-10 13:12 UTC (permalink / raw)
To: Vaibhav Jain, linuxppc-dev, linux-nvdimm
Cc: Santosh Sivaraj, Aneesh Kumar K . V, Oliver O'Halloran,
Vaibhav Jain, Dan Williams, Ira Weiny
In-Reply-To: <20200807123146.11037-1-vaibhav@linux.ibm.com>
Vaibhav Jain <vaibhav@linux.ibm.com> writes:
> The newly introduced 'perf_stats' attribute uses the default access
> mode of 0444 letting non-root users access performance stats of an
> nvdimm and potentially force the kernel into issuing large number of
> expensive HCALLs. Since the information exposed by this attribute
> cannot be cached hence its better to ward of access to this attribute
> from non-root users.
>
> Hence this patch updates the access-mode of 'perf_stats' sysfs
> attribute file to 0400 to make it only readable to root-users.
Or should we ratelimit it?
Fixes: ??
> Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
cheers
^ permalink raw reply
* [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full
From: Christian Zigotzky @ 2020-08-10 13:01 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Darren Stevens, R.T.Dickinson, kvm-ppc@vger.kernel.org,
mad skateman, Olof Johansson, linuxppc-dev
In-Reply-To: <9688335c-d7d0-9eaa-22c6-511e708e0d2a@linux.ibm.com>
Hello,
Just for info. The latest git kernel doesn't work with a virtio_gpu anymore.
QEMU command: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m
1024 -kernel uImage -drive
format=raw,file=fienix-soar_3.0-2020608-net.img,index=0,if=virtio -nic
user,model=e1000 -append "rw root=/dev/vda2" -device virtio-vga -device
virtio-mouse-pci -device virtio-keyboard-pci -device pci-ohci,id=newusb
-device usb-audio,bus=newusb.0 -smp 4
Error messages:
virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0
(slots), used 0 (slots)
BUG: Kernel NULL pointer dereference on read at 0x00000010
Faulting instruction address: 0xc0000000000c7324
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K PREEMPT SMP NR_CPUS=4 QEMU e500
Modules linked in:
CPU: 2 PID: 1678 Comm: kworker/2:2 Not tainted
5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty #1
Workqueue: events .virtio_gpu_dequeue_ctrl_func
NIP: c0000000000c7324 LR: c0000000000c72e4 CTR: c000000000462930
REGS: c00000003dba75e0 TRAP: 0300 Not tainted
(5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty)
MSR: 0000000090029000 <CE,EE,ME> CR: 24002288 XER: 00000000
DEAR: 0000000000000010 ESR: 0000000000000000 IRQMASK: 0
GPR00: c0000000000c6188 c00000003dba7870 c0000000017f2300 c00000003d893010
GPR04: 0000000000000000 0000000000000001 0000000000000000 0000000000000000
GPR08: 0000000000000000 0000000000000000 0000000000000000 7f7f7f7f7f7f7f7f
GPR12: 0000000024002284 c00000003fff9200 c00000000008c3a0 c0000000061566c0
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24: 0000000000000001 0000000000110000 0000000000000000 0000000000000000
GPR28: c00000003d893010 0000000000000000 0000000000000000 c00000003d893010
NIP [c0000000000c7324] .dma_direct_unmap_sg+0x4c/0xd8
LR [c0000000000c72e4] .dma_direct_unmap_sg+0xc/0xd8
Call Trace:
[c00000003dba7870] [c00000003dba7950] 0xc00000003dba7950 (unreliable)
[c00000003dba7920] [c0000000000c6188] .dma_unmap_sg_attrs+0x5c/0x98
[c00000003dba79d0] [c0000000005cd438] .drm_gem_shmem_free_object+0x98/0xcc
[c00000003dba7a50] [c0000000006af5b4] .virtio_gpu_cleanup_object+0xc8/0xd4
[c00000003dba7ad0] [c0000000006ad3bc] .virtio_gpu_cmd_unref_cb+0x1c/0x30
[c00000003dba7b40] [c0000000006adab8]
.virtio_gpu_dequeue_ctrl_func+0x208/0x28c
[c00000003dba7c10] [c000000000086b70] .process_one_work+0x1a4/0x258
[c00000003dba7cb0] [c0000000000870f4] .worker_thread+0x214/0x284
[c00000003dba7d70] [c00000000008c4f0] .kthread+0x150/0x158
[c00000003dba7e20] [c00000000000082c] .ret_from_kernel_thread+0x58/0x60
Instruction dump:
f821ff51 7cb82b78 7cdb3378 4e000000 7cfa3b78 3bc00000 7f9ec000 41fc0014
382100b0 81810008 7d808120 48bc1ba8 <e93d0010> ebfc0248 833d0018 7fff4850
---[ end trace f28d194d9f0955a8 ]---
virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0
(slots), used 0 (slots)
virtio_gpu virtio0: swiotlb buffer is full (sz: 16384 bytes), total 0
(slots), used 0 (slots)
----
The kernel 5.8 works without any problems in this virtual machine.
Could you please check the latest updates?
Thanks,
Christian
^ permalink raw reply
* Re: [PATCH] recordmcount: Fix build failure on non arm64
From: Catalin Marinas @ 2020-08-10 12:18 UTC (permalink / raw)
To: Gregory Herrero
Cc: linux-arm-kernel, linuxppc-dev, Steven Rostedt, linux-kernel
In-Reply-To: <20200810091730.GA3099@ltoracle>
On Mon, Aug 10, 2020 at 11:17:30AM +0200, Gregory Herrero wrote:
> On Mon, Aug 10, 2020 at 08:48:22AM +0000, Christophe Leroy wrote:
> > Commit ea0eada45632 leads to the following build failure on powerpc:
> >
> > HOSTCC scripts/recordmcount
> > scripts/recordmcount.c: In function 'arm64_is_fake_mcount':
> > scripts/recordmcount.c:440: error: 'R_AARCH64_CALL26' undeclared (first use in this function)
> > scripts/recordmcount.c:440: error: (Each undeclared identifier is reported only once
> > scripts/recordmcount.c:440: error: for each function it appears in.)
> > make[2]: *** [scripts/recordmcount] Error 1
> >
> > Make sure R_AARCH64_CALL26 is always defined.
> >
> Oops, thanks for fixing this.
>
> Acked-by: Gregory Herrero <gregory.herrero@oracle.com>
Thanks. I'll queue it via the arm64 tree (as I did with the previous
fix) but I'll wait a bit for Steve to ack it.
--
Catalin
^ permalink raw reply
* [PATCH] powerpc/pkeys: Fix boot failures with Nemo board (A-EON AmigaOne X1000)
From: Aneesh Kumar K.V @ 2020-08-10 10:26 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: Aneesh Kumar K.V, Christian Zigotzky
On p6 and before we should avoid updating UAMOR SPRN. This resulted
in boot failure on Nemo board.
Fixes: 269e829f48a0 ("powerpc/book3s64/pkey: Disable pkey on POWER6 and before")
Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/mm/book3s64/hash_utils.c | 5 ++---
arch/powerpc/mm/book3s64/pkeys.c | 12 ++++++------
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/hash_utils.c b/arch/powerpc/mm/book3s64/hash_utils.c
index 1478fceeb683..1da9dbba9217 100644
--- a/arch/powerpc/mm/book3s64/hash_utils.c
+++ b/arch/powerpc/mm/book3s64/hash_utils.c
@@ -1115,9 +1115,8 @@ void hash__early_init_mmu_secondary(void)
&& cpu_has_feature(CPU_FTR_HVMODE))
tlbiel_all();
-#ifdef CONFIG_PPC_MEM_KEYS
- mtspr(SPRN_UAMOR, default_uamor);
-#endif
+ if (IS_ENABLED(CONFIG_PPC_MEM_KEYS) && mmu_has_feature(MMU_FTR_PKEY))
+ mtspr(SPRN_UAMOR, default_uamor);
}
#endif /* CONFIG_SMP */
diff --git a/arch/powerpc/mm/book3s64/pkeys.c b/arch/powerpc/mm/book3s64/pkeys.c
index 69a6b87f2bb4..b1d091a97611 100644
--- a/arch/powerpc/mm/book3s64/pkeys.c
+++ b/arch/powerpc/mm/book3s64/pkeys.c
@@ -73,12 +73,6 @@ static int scan_pkey_feature(void)
if (early_radix_enabled())
return 0;
- /*
- * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
- */
- if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
- return 0;
-
ret = of_scan_flat_dt(dt_scan_storage_keys, &pkeys_total);
if (ret == 0) {
/*
@@ -124,6 +118,12 @@ void __init pkey_early_init_devtree(void)
__builtin_popcountl(ARCH_VM_PKEY_FLAGS >> VM_PKEY_SHIFT)
!= (sizeof(u64) * BITS_PER_BYTE));
+ /*
+ * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
+ */
+ if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
+ return;
+
/* scan the device tree for pkey feature */
pkeys_total = scan_pkey_feature();
if (!pkeys_total)
--
2.26.2
^ permalink raw reply related
* Re: [PASEMI] Nemo board doesn't boot anymore after the commit "powerpc/book3s64/pkeys: Simplify pkey disable branch"
From: Christian Zigotzky @ 2020-08-10 10:22 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Olof Johansson, Darren Stevens, linuxppc-dev, mad skateman,
R.T.Dickinson
In-Reply-To: <9688335c-d7d0-9eaa-22c6-511e708e0d2a@linux.ibm.com>
Am 10.08.20 um 10:58 schrieb Aneesh Kumar K.V:
> On 8/10/20 2:15 PM, Christian Zigotzky wrote:
>> Hello Aneesh,
>>
>> I tested the new kernel today and unfortunately it doesn't run very
>> well.
>>
>> I have only one core (1 physical processor; 1 core; 2 threads)
>> instead of two cores (1 physical processor; 2 cores; 2 threads) so
>> the system is slower.
>>
>> Boot log: http://www.xenosoft.de/dmesg_nemo_board_kernel_5.9.txt
>>
>> Could you please check the updates?
>
>
> modified arch/powerpc/mm/book3s64/hash_utils.c
> @@ -1116,7 +1116,8 @@ void hash__early_init_mmu_secondary(void)
> tlbiel_all();
>
> #ifdef CONFIG_PPC_MEM_KEYS
> - mtspr(SPRN_UAMOR, default_uamor);
> + if (mmu_has_feature(MMU_FTR_PKEY))
> + mtspr(SPRN_UAMOR, default_uamor);
> #endif
> }
> #endif /* CONFIG_SMP */
>
>
>
> -aneesh
Hello Aneesh,
Your modifications work! I have 2 cores again and I can see the boot
messages.
Thanks a lot!
Cheers,
Christian
^ permalink raw reply
* Re: [PATCH] arch/powerpc: use simple i2c probe function
From: Wolfram Sang @ 2020-08-10 9:36 UTC (permalink / raw)
To: Stephen Kitt
Cc: linux-kernel, Scott Wood, Paul Mackerras, linux-i2c, linuxppc-dev
In-Reply-To: <20200807152713.381588-1-steve@sk2.org>
[-- Attachment #1: Type: text/plain, Size: 463 bytes --]
On Fri, Aug 07, 2020 at 05:27:13PM +0200, Stephen Kitt wrote:
> The i2c probe functions here don't use the id information provided in
> their second argument, so the single-parameter i2c probe function
> ("probe_new") can be used instead.
>
> This avoids scanning the identifier tables during probes.
>
> Signed-off-by: Stephen Kitt <steve@sk2.org>
This is useful, helps deprecating the old probe method:
Acked-by: Wolfram Sang <wsa@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PASEMI] Nemo board doesn't boot anymore after the commit "powerpc/book3s64/pkeys: Simplify pkey disable branch"
From: Aneesh Kumar K.V @ 2020-08-10 8:58 UTC (permalink / raw)
To: Christian Zigotzky
Cc: Olof Johansson, Darren Stevens, linuxppc-dev, mad skateman,
R.T.Dickinson
In-Reply-To: <51482c70-1007-1202-9ed1-2d174c1e923f@xenosoft.de>
On 8/10/20 2:15 PM, Christian Zigotzky wrote:
> Hello Aneesh,
>
> I tested the new kernel today and unfortunately it doesn't run very well.
>
> I have only one core (1 physical processor; 1 core; 2 threads) instead
> of two cores (1 physical processor; 2 cores; 2 threads) so the system is
> slower.
>
> Boot log: http://www.xenosoft.de/dmesg_nemo_board_kernel_5.9.txt
>
> Could you please check the updates?
modified arch/powerpc/mm/book3s64/hash_utils.c
@@ -1116,7 +1116,8 @@ void hash__early_init_mmu_secondary(void)
tlbiel_all();
#ifdef CONFIG_PPC_MEM_KEYS
- mtspr(SPRN_UAMOR, default_uamor);
+ if (mmu_has_feature(MMU_FTR_PKEY))
+ mtspr(SPRN_UAMOR, default_uamor);
#endif
}
#endif /* CONFIG_SMP */
-aneesh
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Add -EPROBE_DEFER check for regmap init
From: Shengjiu Wang @ 2020-08-10 8:53 UTC (permalink / raw)
To: Nicolin Chen
Cc: Linux-ALSA, Timur Tabi, Xiubo Li, Fabio Estevam, Shengjiu Wang,
Takashi Iwai, Liam Girdwood, Mark Brown, linuxppc-dev,
linux-kernel
In-Reply-To: <20200810080018.GA13408@Asurada-Nvidia>
On Mon, Aug 10, 2020 at 4:02 PM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>
> On Fri, Aug 07, 2020 at 05:14:42PM +0800, Shengjiu Wang wrote:
> > Regmap initialization may return -EPROBE_DEFER for clock
> > may not be ready, so check -EPROBE_DEFER error type before
> > start another Regmap initialization.
> >
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> > ---
> > sound/soc/fsl/fsl_sai.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> > index a22562f2df47..eb933fe9b6d1 100644
> > --- a/sound/soc/fsl/fsl_sai.c
> > +++ b/sound/soc/fsl/fsl_sai.c
> > @@ -927,7 +927,7 @@ static int fsl_sai_probe(struct platform_device *pdev)
> > "bus", base, &fsl_sai_regmap_config);
> >
> > /* Compatible with old DTB cases */
> > - if (IS_ERR(sai->regmap))
> > + if (IS_ERR(sai->regmap) && PTR_ERR(sai->regmap) != -EPROBE_DEFER)
> > sai->regmap = devm_regmap_init_mmio_clk(&pdev->dev,
> > "sai", base, &fsl_sai_regmap_config);
> > if (IS_ERR(sai->regmap)) {
>
> In that case, might need a !EPROBE_DEFER check for this
> fallback devm_regmap_init_mmio_clk at "sai" clock too?
No, I think it is ok for this fallback to return directly with
EPROBE_DEFER.
best regards
wang shengjiu
^ permalink raw reply
* [PATCHv5 2/2] powerpc/pseries: update device tree before ejecting hotplug uevents
From: Pingfan Liu @ 2020-08-10 8:52 UTC (permalink / raw)
To: linuxppc-dev
Cc: Nathan Lynch, kexec, Pingfan Liu, Nathan Fontenot, Laurent Dufour,
Hari Bathini
In-Reply-To: <1597049570-19536-1-git-send-email-kernelfans@gmail.com>
A bug is observed on pseries by taking the following steps on rhel:
-1. drmgr -c mem -r -q 5
-2. echo c > /proc/sysrq-trigger
And then, the failure looks like:
kdump: saving to /sysroot//var/crash/127.0.0.1-2020-01-16-02:06:14/
kdump: saving vmcore-dmesg.txt
kdump: saving vmcore-dmesg.txt complete
kdump: saving vmcore
Checking for memory holes : [ 0.0 %] / Checking for memory holes : [100.0 %] | Excluding unnecessary pages : [100.0 %] \ Copying data : [ 0.3 %] - eta: 38s[ 44.337636] hash-mmu: mm: Hashing failure ! EA=0x7fffba400000 access=0x8000000000000004 current=makedumpfile
[ 44.337663] hash-mmu: trap=0x300 vsid=0x13a109c ssize=1 base psize=2 psize 2 pte=0xc000000050000504
[ 44.337677] hash-mmu: mm: Hashing failure ! EA=0x7fffba400000 access=0x8000000000000004 current=makedumpfile
[ 44.337692] hash-mmu: trap=0x300 vsid=0x13a109c ssize=1 base psize=2 psize 2 pte=0xc000000050000504
[ 44.337708] makedumpfile[469]: unhandled signal 7 at 00007fffba400000 nip 00007fffbbc4d7fc lr 000000011356ca3c code 2
[ 44.338548] Core dump to |/bin/false pipe failed
/lib/kdump-lib-initramfs.sh: line 98: 469 Bus error $CORE_COLLECTOR /proc/vmcore $_mp/$KDUMP_PATH/$HOST_IP-$DATEDIR/vmcore-incomplete
kdump: saving vmcore failed
* Root cause *
After analyzing, it turns out that in the current implementation,
when hot-removing lmb, the KOBJ_REMOVE event ejects before the dt updating as
the code __remove_memory() comes before drmem_update_dt().
So in kdump kernel, when read_from_oldmem() resorts to
pSeries_lpar_hpte_insert() to install hpte, but fails with -2 due to
non-exist pfn. And finally, low_hash_fault() raise SIGBUS to process, as it
can be observed "Bus error"
From a viewpoint of listener and publisher, the publisher notifies the
listener before data is ready. This introduces a problem where udev
launches kexec-tools (due to KOBJ_REMOVE) and loads a stale dt before
updating. And in capture kernel, makedumpfile will access the memory based
on the stale dt info, and hit a SIGBUS error due to an un-existed lmb.
* Fix *
This bug is introduced by commit 063b8b1251fd
("powerpc/pseries/memory-hotplug: Only update DT once per memory DLPAR
request"), which tried to combine all the dt updating into one.
To fix this issue, meanwhile not to introduce a quadratic runtime
complexity by the model:
dlpar_memory_add_by_count
for_each_drmem_lmb <--
dlpar_add_lmb
drmem_update_dt(_v1|_v2)
for_each_drmem_lmb <--
The dt should still be only updated once, and just before the last memory
online/offline event is ejected to user space. Achieve this by tracing the
num of lmb added or removed.
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Nathan Lynch <nathanl@linux.ibm.com>
Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Cc: Laurent Dufour <ldufour@linux.ibm.com>
To: linuxppc-dev@lists.ozlabs.org
Cc: kexec@lists.infradead.org
---
v4 -> v5: change dlpar_add_lmb()/dlpar_remove_lmb() prototype to report
whether dt is updated successfully.
Fix a condition boundary check bug
v3 -> v4: resolve a quadratic runtime complexity issue.
This series is applied on next-test branch
arch/powerpc/platforms/pseries/hotplug-memory.c | 102 +++++++++++++++++++-----
1 file changed, 80 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 46cbcd1..1567d9f 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -350,13 +350,22 @@ static bool lmb_is_removable(struct drmem_lmb *lmb)
return true;
}
-static int dlpar_add_lmb(struct drmem_lmb *);
+enum dt_update_status {
+ DT_NOUPDATE,
+ DT_TOUPDATE,
+ DT_UPDATED,
+};
+
+/* "*dt_update" returns DT_UPDATED if updated */
+static int dlpar_add_lmb(struct drmem_lmb *lmb,
+ enum dt_update_status *dt_update);
-static int dlpar_remove_lmb(struct drmem_lmb *lmb)
+static int dlpar_remove_lmb(struct drmem_lmb *lmb,
+ enum dt_update_status *dt_update)
{
unsigned long block_sz;
phys_addr_t base_addr;
- int rc, nid;
+ int rc, ret, nid;
if (!lmb_is_removable(lmb))
return -EINVAL;
@@ -372,6 +381,13 @@ static int dlpar_remove_lmb(struct drmem_lmb *lmb)
invalidate_lmb_associativity_index(lmb);
lmb_clear_nid(lmb);
lmb->flags &= ~DRCONF_MEM_ASSIGNED;
+ if (*dt_update) {
+ ret = drmem_update_dt();
+ if (ret)
+ pr_warn("%s fail to update dt, but continue\n", __func__);
+ else
+ *dt_update = DT_UPDATED;
+ }
__remove_memory(nid, base_addr, block_sz);
@@ -387,6 +403,7 @@ static int dlpar_memory_remove_by_count(u32 lmbs_to_remove)
int lmbs_removed = 0;
int lmbs_available = 0;
int rc;
+ enum dt_update_status dt_update = DT_NOUPDATE;
pr_info("Attempting to hot-remove %d LMB(s)\n", lmbs_to_remove);
@@ -409,7 +426,11 @@ static int dlpar_memory_remove_by_count(u32 lmbs_to_remove)
}
for_each_drmem_lmb(lmb) {
- rc = dlpar_remove_lmb(lmb);
+
+ /* combine dt updating for all LMBs */
+ if (lmbs_to_remove - lmbs_removed <= 1)
+ dt_update = DT_TOUPDATE;
+ rc = dlpar_remove_lmb(lmb, &dt_update);
if (rc)
continue;
@@ -424,13 +445,17 @@ static int dlpar_memory_remove_by_count(u32 lmbs_to_remove)
}
if (lmbs_removed != lmbs_to_remove) {
+ enum dt_update_status rollback_dt_update = DT_NOUPDATE;
+
pr_err("Memory hot-remove failed, adding LMB's back\n");
for_each_drmem_lmb(lmb) {
if (!drmem_lmb_reserved(lmb))
continue;
- rc = dlpar_add_lmb(lmb);
+ if (--lmbs_removed == 0 && dt_update == DT_UPDATED)
+ rollback_dt_update = DT_TOUPDATE;
+ rc = dlpar_add_lmb(lmb, &rollback_dt_update);
if (rc)
pr_err("Failed to add LMB back, drc index %x\n",
lmb->drc_index);
@@ -458,6 +483,7 @@ static int dlpar_memory_remove_by_count(u32 lmbs_to_remove)
static int dlpar_memory_remove_by_index(u32 drc_index)
{
+ enum dt_update_status dt_update = DT_TOUPDATE;
struct drmem_lmb *lmb;
int lmb_found;
int rc;
@@ -468,7 +494,7 @@ static int dlpar_memory_remove_by_index(u32 drc_index)
for_each_drmem_lmb(lmb) {
if (lmb->drc_index == drc_index) {
lmb_found = 1;
- rc = dlpar_remove_lmb(lmb);
+ rc = dlpar_remove_lmb(lmb, &dt_update);
if (!rc)
dlpar_release_drc(lmb->drc_index);
@@ -490,6 +516,7 @@ static int dlpar_memory_remove_by_index(u32 drc_index)
static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)
{
+ enum dt_update_status dt_update = DT_NOUPDATE;
struct drmem_lmb *lmb, *start_lmb, *end_lmb;
int lmbs_available = 0;
int rc;
@@ -519,7 +546,9 @@ static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)
if (!(lmb->flags & DRCONF_MEM_ASSIGNED))
continue;
- rc = dlpar_remove_lmb(lmb);
+ if (lmb == end_lmb)
+ dt_update = DT_TOUPDATE;
+ rc = dlpar_remove_lmb(lmb, &dt_update);
if (rc)
break;
@@ -527,14 +556,16 @@ static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)
}
if (rc) {
- pr_err("Memory indexed-count-remove failed, adding any removed LMBs\n");
+ enum dt_update_status rollback_dt_update = DT_NOUPDATE;
+ pr_err("Memory indexed-count-remove failed, adding any removed LMBs\n");
for_each_drmem_lmb_in_range(lmb, start_lmb, end_lmb) {
if (!drmem_lmb_reserved(lmb))
continue;
-
- rc = dlpar_add_lmb(lmb);
+ if (lmb == end_lmb && dt_update == DT_UPDATED)
+ rollback_dt_update = DT_TOUPDATE;
+ rc = dlpar_add_lmb(lmb, &rollback_dt_update);
if (rc)
pr_err("Failed to add LMB, drc index %x\n",
lmb->drc_index);
@@ -572,7 +603,7 @@ static inline int dlpar_memory_remove(struct pseries_hp_errorlog *hp_elog)
{
return -EOPNOTSUPP;
}
-static int dlpar_remove_lmb(struct drmem_lmb *lmb)
+static int dlpar_remove_lmb(struct drmem_lmb *lmb, bool dt_update)
{
return -EOPNOTSUPP;
}
@@ -591,10 +622,11 @@ static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)
}
#endif /* CONFIG_MEMORY_HOTREMOVE */
-static int dlpar_add_lmb(struct drmem_lmb *lmb)
+static int dlpar_add_lmb(struct drmem_lmb *lmb,
+ enum dt_update_status *dt_update)
{
unsigned long block_sz;
- int rc;
+ int rc, ret;
if (lmb->flags & DRCONF_MEM_ASSIGNED)
return -EINVAL;
@@ -607,6 +639,13 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
lmb_set_nid(lmb);
lmb->flags |= DRCONF_MEM_ASSIGNED;
+ if (*dt_update) {
+ ret = drmem_update_dt();
+ if (ret)
+ pr_warn("%s fail to update dt, but continue\n", __func__);
+ else
+ *dt_update = DT_UPDATED;
+ }
block_sz = memory_block_size_bytes();
@@ -616,6 +655,8 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
invalidate_lmb_associativity_index(lmb);
lmb_clear_nid(lmb);
lmb->flags &= ~DRCONF_MEM_ASSIGNED;
+ if (*dt_update == DT_UPDATED)
+ drmem_update_dt();
return rc;
}
@@ -627,7 +668,11 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
invalidate_lmb_associativity_index(lmb);
lmb_clear_nid(lmb);
lmb->flags &= ~DRCONF_MEM_ASSIGNED;
-
+ if (*dt_update == DT_UPDATED) {
+ ret = drmem_update_dt();
+ if (ret)
+ pr_warn("%s fail to update dt during rollback, but continue\n", __func__);
+ }
__remove_memory(nid, base_addr, block_sz);
}
@@ -636,6 +681,7 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
static int dlpar_memory_add_by_count(u32 lmbs_to_add)
{
+ enum dt_update_status dt_update = DT_NOUPDATE;
struct drmem_lmb *lmb;
int lmbs_available = 0;
int lmbs_added = 0;
@@ -666,7 +712,9 @@ static int dlpar_memory_add_by_count(u32 lmbs_to_add)
if (rc)
continue;
- rc = dlpar_add_lmb(lmb);
+ if (lmbs_to_add - lmbs_added <= 1)
+ dt_update = DT_TOUPDATE;
+ rc = dlpar_add_lmb(lmb, &dt_update);
if (rc) {
dlpar_release_drc(lmb->drc_index);
continue;
@@ -683,13 +731,18 @@ static int dlpar_memory_add_by_count(u32 lmbs_to_add)
}
if (lmbs_added != lmbs_to_add) {
+ enum dt_update_status rollback_dt_update = DT_NOUPDATE;
+
pr_err("Memory hot-add failed, removing any added LMBs\n");
for_each_drmem_lmb(lmb) {
if (!drmem_lmb_reserved(lmb))
continue;
- rc = dlpar_remove_lmb(lmb);
+ if (--lmbs_added == 0 && dt_update == DT_UPDATED)
+ rollback_dt_update = DT_TOUPDATE;
+
+ rc = dlpar_remove_lmb(lmb, &rollback_dt_update);
if (rc)
pr_err("Failed to remove LMB, drc index %x\n",
lmb->drc_index);
@@ -716,6 +769,7 @@ static int dlpar_memory_add_by_count(u32 lmbs_to_add)
static int dlpar_memory_add_by_index(u32 drc_index)
{
+ enum dt_update_status dt_update = DT_TOUPDATE;
struct drmem_lmb *lmb;
int rc, lmb_found;
@@ -727,7 +781,7 @@ static int dlpar_memory_add_by_index(u32 drc_index)
lmb_found = 1;
rc = dlpar_acquire_drc(lmb->drc_index);
if (!rc) {
- rc = dlpar_add_lmb(lmb);
+ rc = dlpar_add_lmb(lmb, &dt_update);
if (rc)
dlpar_release_drc(lmb->drc_index);
}
@@ -750,6 +804,7 @@ static int dlpar_memory_add_by_index(u32 drc_index)
static int dlpar_memory_add_by_ic(u32 lmbs_to_add, u32 drc_index)
{
+ enum dt_update_status dt_update = DT_NOUPDATE;
struct drmem_lmb *lmb, *start_lmb, *end_lmb;
int lmbs_available = 0;
int rc;
@@ -783,7 +838,9 @@ static int dlpar_memory_add_by_ic(u32 lmbs_to_add, u32 drc_index)
if (rc)
break;
- rc = dlpar_add_lmb(lmb);
+ if (lmb == end_lmb)
+ dt_update = DT_TOUPDATE;
+ rc = dlpar_add_lmb(lmb, &dt_update);
if (rc) {
dlpar_release_drc(lmb->drc_index);
break;
@@ -796,10 +853,14 @@ static int dlpar_memory_add_by_ic(u32 lmbs_to_add, u32 drc_index)
pr_err("Memory indexed-count-add failed, removing any added LMBs\n");
for_each_drmem_lmb_in_range(lmb, start_lmb, end_lmb) {
+ enum dt_update_status rollback_dt_update = DT_NOUPDATE;
+
if (!drmem_lmb_reserved(lmb))
continue;
- rc = dlpar_remove_lmb(lmb);
+ if (lmb == end_lmb && dt_update == DT_UPDATED)
+ rollback_dt_update = DT_TOUPDATE;
+ rc = dlpar_remove_lmb(lmb, &rollback_dt_update);
if (rc)
pr_err("Failed to remove LMB, drc index %x\n",
lmb->drc_index);
@@ -879,9 +940,6 @@ int dlpar_memory(struct pseries_hp_errorlog *hp_elog)
break;
}
- if (!rc)
- rc = drmem_update_dt();
-
unlock_device_hotplug();
return rc;
}
--
2.7.5
^ permalink raw reply related
* [PATCHv5 1/2] powerpc/pseries: group lmb operation and memblock's
From: Pingfan Liu @ 2020-08-10 8:52 UTC (permalink / raw)
To: linuxppc-dev
Cc: Nathan Lynch, kexec, Pingfan Liu, Nathan Fontenot, Laurent Dufour,
Hari Bathini
This patch prepares for the incoming patch which swaps the order of
KOBJ_ADD/REMOVE uevent and dt's updating.
The dt updating should come after lmb operations, and before
__remove_memory()/__add_memory(). Accordingly, grouping all lmb operations
before the memblock's.
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Nathan Lynch <nathanl@linux.ibm.com>
Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Cc: Laurent Dufour <ldufour@linux.ibm.com>
To: linuxppc-dev@lists.ozlabs.org
Cc: kexec@lists.infradead.org
---
v4 -> v5: fix the miss of clearing DRCONF_MEM_ASSIGNED in a failure path
arch/powerpc/platforms/pseries/hotplug-memory.c | 28 +++++++++++++++++--------
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 5d545b7..46cbcd1 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -355,7 +355,8 @@ static int dlpar_add_lmb(struct drmem_lmb *);
static int dlpar_remove_lmb(struct drmem_lmb *lmb)
{
unsigned long block_sz;
- int rc;
+ phys_addr_t base_addr;
+ int rc, nid;
if (!lmb_is_removable(lmb))
return -EINVAL;
@@ -364,17 +365,19 @@ static int dlpar_remove_lmb(struct drmem_lmb *lmb)
if (rc)
return rc;
+ base_addr = lmb->base_addr;
+ nid = lmb->nid;
block_sz = pseries_memory_block_size();
- __remove_memory(lmb->nid, lmb->base_addr, block_sz);
-
- /* Update memory regions for memory remove */
- memblock_remove(lmb->base_addr, block_sz);
-
invalidate_lmb_associativity_index(lmb);
lmb_clear_nid(lmb);
lmb->flags &= ~DRCONF_MEM_ASSIGNED;
+ __remove_memory(nid, base_addr, block_sz);
+
+ /* Update memory regions for memory remove */
+ memblock_remove(base_addr, block_sz);
+
return 0;
}
@@ -603,22 +606,29 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
}
lmb_set_nid(lmb);
+ lmb->flags |= DRCONF_MEM_ASSIGNED;
+
block_sz = memory_block_size_bytes();
/* Add the memory */
rc = __add_memory(lmb->nid, lmb->base_addr, block_sz);
if (rc) {
invalidate_lmb_associativity_index(lmb);
+ lmb_clear_nid(lmb);
+ lmb->flags &= ~DRCONF_MEM_ASSIGNED;
return rc;
}
rc = dlpar_online_lmb(lmb);
if (rc) {
- __remove_memory(lmb->nid, lmb->base_addr, block_sz);
+ int nid = lmb->nid;
+ phys_addr_t base_addr = lmb->base_addr;
+
invalidate_lmb_associativity_index(lmb);
lmb_clear_nid(lmb);
- } else {
- lmb->flags |= DRCONF_MEM_ASSIGNED;
+ lmb->flags &= ~DRCONF_MEM_ASSIGNED;
+
+ __remove_memory(nid, base_addr, block_sz);
}
return rc;
--
2.7.5
^ permalink raw reply related
* Re: [PATCH v2] ASoC: fsl-asoc-card: Get "extal" clock rate by clk_get_rate
From: Shengjiu Wang @ 2020-08-10 8:50 UTC (permalink / raw)
To: Nicolin Chen
Cc: Linux-ALSA, Timur Tabi, Xiubo Li, Fabio Estevam, Shengjiu Wang,
Takashi Iwai, Liam Girdwood, Mark Brown, linuxppc-dev,
linux-kernel
In-Reply-To: <20200810083728.GA7560@Asurada-Nvidia>
On Mon, Aug 10, 2020 at 4:39 PM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>
> On Mon, Aug 10, 2020 at 04:11:43PM +0800, Shengjiu Wang wrote:
> > On some platform(.e.g. i.MX8QM MEK), the "extal" clock is different
> > with the mclk of codec, then the clock rate is also different.
> > So it is better to get clock rate of "extal" rate by clk_get_rate,
> > don't reuse the clock rate of mclk.
> >
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> > ---
> > changes in v2
> > - add defer probe handler
> >
> > sound/soc/fsl/fsl-asoc-card.c | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
> > index 52adedc03245..32f8f756e6bb 100644
> > --- a/sound/soc/fsl/fsl-asoc-card.c
> > +++ b/sound/soc/fsl/fsl-asoc-card.c
> > @@ -696,6 +696,17 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> > goto asrc_fail;
> > }
> > } else if (of_node_name_eq(cpu_np, "esai")) {
> > + struct clk *esai_clk = clk_get(&cpu_pdev->dev, "extal");
> > +
> > + if (!IS_ERR(esai_clk)) {
> > + priv->cpu_priv.sysclk_freq[TX] = clk_get_rate(esai_clk);
> > + priv->cpu_priv.sysclk_freq[RX] = clk_get_rate(esai_clk);
>
> Will it break existing imx-audio-cs42888 on older i.MX platforms?
> 'cause it overwrites cpu_priv.sysclk_freq[] that are set in "card
> configurations" section.
Tested, no break for imx6.
best regards
wang shengjiu
^ permalink raw reply
* [PATCH] recordmcount: Fix build failure on non arm64
From: Christophe Leroy @ 2020-08-10 8:48 UTC (permalink / raw)
To: Gregory Herrero, Steven Rostedt, Catalin Marinas
Cc: linuxppc-dev, linux-kernel, linux-arm-kernel
Commit ea0eada45632 leads to the following build failure on powerpc:
HOSTCC scripts/recordmcount
scripts/recordmcount.c: In function 'arm64_is_fake_mcount':
scripts/recordmcount.c:440: error: 'R_AARCH64_CALL26' undeclared (first use in this function)
scripts/recordmcount.c:440: error: (Each undeclared identifier is reported only once
scripts/recordmcount.c:440: error: for each function it appears in.)
make[2]: *** [scripts/recordmcount] Error 1
Make sure R_AARCH64_CALL26 is always defined.
Fixes: ea0eada45632 ("recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.")
Cc: Gregory Herrero <gregory.herrero@oracle.com>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
scripts/recordmcount.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
index e59022b3f125..b9c2ee7ab43f 100644
--- a/scripts/recordmcount.c
+++ b/scripts/recordmcount.c
@@ -42,6 +42,8 @@
#define R_ARM_THM_CALL 10
#define R_ARM_CALL 28
+#define R_AARCH64_CALL26 283
+
static int fd_map; /* File descriptor for file being modified. */
static int mmap_failed; /* Boolean flag. */
static char gpfx; /* prefix for global symbol name (sometimes '_') */
--
2.25.0
^ permalink raw reply related
* Re: [PASEMI] Nemo board doesn't boot anymore after the commit "powerpc/book3s64/pkeys: Simplify pkey disable branch"
From: Christian Zigotzky @ 2020-08-10 8:45 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Olof Johansson, Darren Stevens, linuxppc-dev, mad skateman,
R.T.Dickinson
In-Reply-To: <bc1975fb-23df-09c2-540a-c13b39ad56c5@xenosoft.de>
Hello Aneesh,
I tested the new kernel today and unfortunately it doesn't run very well.
I have only one core (1 physical processor; 1 core; 2 threads) instead
of two cores (1 physical processor; 2 cores; 2 threads) so the system is
slower.
Boot log: http://www.xenosoft.de/dmesg_nemo_board_kernel_5.9.txt
Could you please check the updates?
Thanks,
Christian
On 10 August 2020 at 09:56 am, Christian Zigotzky wrote:
> Hello Aneesh,
>
> The Nemo board boots with your patch but unfortunately I don't see any
> boot messages anymore.
>
> Please find attached the kernel config.
>
> Thanks,
> Christian
>
>
> On 09 August 2020 at 5:49 pm, Christian Zigotzky wrote:
>> Hello Aneesh,
>>
>> Many thanks for your fast response and thanks a lot for your patch!
>> I will patch and compile a new git kernel tomorrow. I am looking
>> forward to the result.
>>
>> Have a nice day!
>>
>> Cheers,
>> Christian
>>
>>> On 9. Aug 2020, at 17:11, Aneesh Kumar K.V
>>> <aneesh.kumar@linux.ibm.com> wrote:
>>>
>>> "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
>>>
>>>>> On 8/9/20 8:04 PM, Aneesh Kumar K.V wrote:
>>>>> On 8/9/20 7:42 PM, Christian Zigotzky wrote:
>>>>>> Hello,
>>>>>>
>>>>>> The Nemo board (A-EON AmigaOne X1000) [1] doesn't start with the
>>>>>> latest Git kernel anymore after the commit "powerpc/book3s64/pkeys:
>>>>>> Simplify pkey disable branch" [2].
>>>>>>
>>>>>> I bisected today [3].
>>>>>>
>>>>>> Result: powerpc/book3s64/pkeys: Simplify pkey disable branch
>>>>>> (a4678d4b477c3d2901f101986ca01406f3b7eaea) [2] is the first bad
>>>>>> commit.
>>>>>>
>>>>>> Unfortunately I wasn't able to revert the first bad commit. The
>>>>>> first
>>>>>> bad commit depends on many other commits, which unfortunately I
>>>>>> don't
>>>>>> know. I tried to remove the modifications of the files from the
>>>>>> first
>>>>>> bad commit but without any success. There are just too many
>>>>>> dependencies.
>>>>>>
>>>>>> Additionally I reverted the commit "selftests/powerpc: Fix pkey
>>>>>> syscall redefinitions" [4] and compiled a new kernel but without any
>>>>>> success.
>>>>>>
>>>>>> Could you please check the first bad commit?
>>>>>>
>>>>>> Thanks,
>>>>>> Christian
>>>>>>
>>>>>
>>>>> Can you share a successful boot log of the system so that i can
>>>>> double
>>>>> check the cpu_feature and mmu_feature reported ? I am looking for
>>>>> details similar to below.
>>>>>
>>>>> [ 0.000000] cpu_features = 0x0001c07f8f5f91a7
>>>>> [ 0.000000] possible = 0x0001fbffcf5fb1a7
>>>>> [ 0.000000] always = 0x00000003800081a1
>>>>> [ 0.000000] cpu_user_features = 0xdc0065c2 0xefe00000
>>>>> [ 0.000000] mmu_features = 0x7c006001
>>>>> [ 0.000000] firmware_features = 0x0000001fc45bfc57
>>>>> [ 0.000000] vmalloc start = 0xc008000000000000
>>>>> [ 0.000000] IO start = 0xc00a000000000000
>>>>> [ 0.000000] vmemmap start = 0xc00c000000000000
>>>>>
>>>>>
>>>>> IIUC this is P5+? (ISA 2.04). On that pkey should be marked
>>>>> disabled via
>>>>>
>>>>> static int scan_pkey_feature(void)
>>>>> {
>>>>> int ret;
>>>>> int pkeys_total = 0;
>>>>>
>>>>> ....
>>>>>
>>>>> /*
>>>>> * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
>>>>> */
>>>>> if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
>>>>> return 0;
>>>>>
>>>>>
>>>>> }
>>>>>
>>>>> Can you boot with CONFIG_PPC_MEM_KEYS=n ?
>>>>
>>>> Can you try this change on top of master?
>>>>
>>>>
>>>> modified arch/powerpc/mm/book3s64/pkeys.c
>>>> @@ -215,10 +215,6 @@ void __init pkey_early_init_devtree(void)
>>>>
>>>> pr_info("Enabling pkeys with max key count %d\n", num_pkey);
>>>> out:
>>>> - /*
>>>> - * Setup uamor on boot cpu
>>>> - */
>>>> - mtspr(SPRN_UAMOR, default_uamor);
>>>>
>>>> return;
>>>> }
>>>>
>>> Full patch with better description.
>>>
>>> commit 919a177bcdaf1eaeaeecc0d0f50a688629d7b5df
>>> Author: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>>> Date: Sun Aug 9 20:37:38 2020 +0530
>>>
>>> powerpc/pkeys: Fix boot failures with Nemo board (A-EON AmigaOne
>>> X1000)
>>>
>>> On p6 and before we should avoid updating UAMOR SPRN. This resulted
>>> in boot failure on Nemo board.
>>>
>>> Fixes: 269e829f48a0 ("powerpc/book3s64/pkey: Disable pkey on
>>> POWER6 and before")
>>> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>>>
>>> diff --git a/arch/powerpc/mm/book3s64/pkeys.c
>>> b/arch/powerpc/mm/book3s64/pkeys.c
>>> index 69a6b87f2bb4..b1d091a97611 100644
>>> --- a/arch/powerpc/mm/book3s64/pkeys.c
>>> +++ b/arch/powerpc/mm/book3s64/pkeys.c
>>> @@ -73,12 +73,6 @@ static int scan_pkey_feature(void)
>>> if (early_radix_enabled())
>>> return 0;
>>>
>>> - /*
>>> - * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
>>> - */
>>> - if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
>>> - return 0;
>>> -
>>> ret = of_scan_flat_dt(dt_scan_storage_keys, &pkeys_total);
>>> if (ret == 0) {
>>> /*
>>> @@ -124,6 +118,12 @@ void __init pkey_early_init_devtree(void)
>>> __builtin_popcountl(ARCH_VM_PKEY_FLAGS >> VM_PKEY_SHIFT)
>>> != (sizeof(u64) * BITS_PER_BYTE));
>>>
>>> + /*
>>> + * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
>>> + */
>>> + if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
>>> + return;
>>> +
>>> /* scan the device tree for pkey feature */
>>> pkeys_total = scan_pkey_feature();
>>> if (!pkeys_total)
>
^ permalink raw reply
* Re: [PATCH v2] ASoC: fsl-asoc-card: Get "extal" clock rate by clk_get_rate
From: Nicolin Chen @ 2020-08-10 8:37 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, tiwai, lgirdwood,
perex, broonie, festevam, linux-kernel
In-Reply-To: <1597047103-6863-1-git-send-email-shengjiu.wang@nxp.com>
On Mon, Aug 10, 2020 at 04:11:43PM +0800, Shengjiu Wang wrote:
> On some platform(.e.g. i.MX8QM MEK), the "extal" clock is different
> with the mclk of codec, then the clock rate is also different.
> So it is better to get clock rate of "extal" rate by clk_get_rate,
> don't reuse the clock rate of mclk.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> changes in v2
> - add defer probe handler
>
> sound/soc/fsl/fsl-asoc-card.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
> index 52adedc03245..32f8f756e6bb 100644
> --- a/sound/soc/fsl/fsl-asoc-card.c
> +++ b/sound/soc/fsl/fsl-asoc-card.c
> @@ -696,6 +696,17 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> goto asrc_fail;
> }
> } else if (of_node_name_eq(cpu_np, "esai")) {
> + struct clk *esai_clk = clk_get(&cpu_pdev->dev, "extal");
> +
> + if (!IS_ERR(esai_clk)) {
> + priv->cpu_priv.sysclk_freq[TX] = clk_get_rate(esai_clk);
> + priv->cpu_priv.sysclk_freq[RX] = clk_get_rate(esai_clk);
Will it break existing imx-audio-cs42888 on older i.MX platforms?
'cause it overwrites cpu_priv.sysclk_freq[] that are set in "card
configurations" section.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox