* Re: [PATCH] powerpc/boot: Use address-of operator on section symbols
From: Michael Ellerman @ 2020-08-03 11:09 UTC (permalink / raw)
To: Geert Uytterhoeven, Segher Boessenkool
Cc: Arnd Bergmann, Geoff Levand, Linux Kernel Mailing List,
clang-built-linux, Paul Mackerras, Joel Stanley,
Nathan Chancellor, linuxppc-dev
In-Reply-To: <CAMuHMdUmHE-KVQuo=b2rn9EPgmnqSDi4i16NPbL5rXLLSCoyKg@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> On Mon, Jul 20, 2020 at 11:03 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
>> On Sat, Jul 18, 2020 at 09:50:50AM +0200, Geert Uytterhoeven wrote:
>> > On Wed, Jun 24, 2020 at 6:02 AM Nathan Chancellor
>> > <natechancellor@gmail.com> wrote:
>> > > /* If we have an image attached to us, it overrides anything
>> > > * supplied by the loader. */
>> > > - if (_initrd_end > _initrd_start) {
>> > > + if (&_initrd_end > &_initrd_start) {
>> >
>> > Are you sure that fix is correct?
>> >
>> > extern char _initrd_start[];
>> > extern char _initrd_end[];
>> > extern char _esm_blob_start[];
>> > extern char _esm_blob_end[];
>> >
>> > Of course the result of their comparison is a constant, as the addresses
>> > are constant. If clangs warns about it, perhaps that warning should be moved
>> > to W=1?
>> >
>> > But adding "&" is not correct, according to C.
>>
>> Why not?
>>
>> 6.5.3.2/3
>> The unary & operator yields the address of its operand. [...]
>> Otherwise, the result is a pointer to the object or function designated
>> by its operand.
>>
>> This is the same as using the name of an array without anything else,
>> yes. It is a bit clearer if it would not be declared as array, perhaps,
>> but it is correct just fine like this.
>
> Thanks, I stand corrected.
>
> Regardless, the comparison is still a comparison between two constant
> addresses, so my fear is that the compiler will start generating
> warnings for that in the near or distant future, making this change
> futile.
They're not constant at compile time though. So I don't think the
compiler could (sensibly) warn about that? (surely!)
cheers
^ permalink raw reply
* Re: [PATCH v2] selftests/powerpc: Fix pkey syscall redefinitions
From: Michael Ellerman @ 2020-08-03 11:04 UTC (permalink / raw)
To: Sandipan Das; +Cc: sachinp, aneesh.kumar, linuxppc-dev
In-Reply-To: <566dde119ce71f00f9642807ba30ceb7f54c9bfa.1596441105.git.sandipan@linux.ibm.com>
Sandipan Das <sandipan@linux.ibm.com> writes:
> On some distros, there are conflicts w.r.t to redefinition
> of pkey syscall numbers which cause build failures. This
> fixes them.
>
> Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
> ---
> Previous versions can be found at:
> v1: https://lore.kernel.org/linuxppc-dev/20200803074043.466809-1-sandipan@linux.ibm.com/
>
> Changes in v2:
> - Fix incorrect commit message.
>
> ---
> tools/testing/selftests/powerpc/include/pkeys.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/tools/testing/selftests/powerpc/include/pkeys.h b/tools/testing/selftests/powerpc/include/pkeys.h
> index 6ba95039a034..26eef5c1f8ea 100644
> --- a/tools/testing/selftests/powerpc/include/pkeys.h
> +++ b/tools/testing/selftests/powerpc/include/pkeys.h
> @@ -31,8 +31,13 @@
>
> #define SI_PKEY_OFFSET 0x20
>
> +#undef SYS_pkey_mprotect
> #define SYS_pkey_mprotect 386
We shouldn't undef them.
They should obviously never change, but if the system headers already
have a definition then we should use that, so I think it should be:
#ifndef SYS_pkey_mprotect
#define SYS_pkey_mprotect 386
#endif
cheers
^ permalink raw reply
* Re: [merge] Build failure selftest/powerpc/mm/pkey_exec_prot
From: Michael Ellerman @ 2020-08-03 11:02 UTC (permalink / raw)
To: Sachin Sant, Sandipan Das; +Cc: linuxppc-dev
In-Reply-To: <C44DC5C2-5133-49AA-BAA6-58E334EB70BA@linux.vnet.ibm.com>
Sachin Sant <sachinp@linux.vnet.ibm.com> writes:
>> On 02-Aug-2020, at 10:58 PM, Sandipan Das <sandipan@linux.ibm.com> wrote:
>> On 02/08/20 4:45 pm, Sachin Sant wrote:
>>> pkey_exec_prot test from linuxppc merge branch (3f68564f1f5a) fails to
>>> build due to following error:
>>>
>>> gcc -std=gnu99 -O2 -Wall -Werror -DGIT_VERSION='"v5.8-rc7-1276-g3f68564f1f5a"' -I/home/sachin/linux/tools/testing/selftests/powerpc/include -m64 pkey_exec_prot.c /home/sachin/linux/tools/testing/selftests/kselftest_harness.h /home/sachin/linux/tools/testing/selftests/kselftest.h ../harness.c ../utils.c -o /home/sachin/linux/tools/testing/selftests/powerpc/mm/pkey_exec_prot
>>> In file included from pkey_exec_prot.c:18:
>>> /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:34: error: "SYS_pkey_mprotect" redefined [-Werror]
>>> #define SYS_pkey_mprotect 386
>>>
>>> In file included from /usr/include/sys/syscall.h:31,
>>> from /home/sachin/linux/tools/testing/selftests/powerpc/include/utils.h:47,
>>> from /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:12,
>>> from pkey_exec_prot.c:18:
>>> /usr/include/bits/syscall.h:1583: note: this is the location of the previous definition
>>> # define SYS_pkey_mprotect __NR_pkey_mprotect
>>>
>>> commit 128d3d021007 introduced this error.
>>> selftests/powerpc: Move pkey helpers to headers
>>>
>>> Possibly the # defines for sys calls can be retained in pkey_exec_prot.c or
>>>
>>
>> I am unable to reproduce this on the latest merge branch (HEAD at f59195f7faa4).
>> I don't see any redefinitions in pkey_exec_prot.c either.
>>
>
> I can still see this problem on latest merge branch.
> I have following gcc version
>
> gcc version 8.3.1 20191121
What libc version? Or just the distro & version?
cheers
> # git show
> commit f59195f7faa4896b7c1d947ac2dba29ec18ad569 (HEAD -> merge, origin/merge)
> Merge: 70ce795dac09 ac3a0c847296
> Author: Michael Ellerman <mpe@ellerman.id.au>
> Date: Sun Aug 2 23:18:03 2020 +1000
>
> Automatic merge of 'master', 'next' and 'fixes' (2020-08-02 23:18)
>
> # make -C powerpc
> ……
> …...
> BUILD_TARGET=/home/sachin/linux/tools/testing/selftests/powerpc/mm; mkdir -p $BUILD_TARGET; make OUTPUT=$BUILD_TARGET -k -C mm all
> make[1]: Entering directory '/home/sachin/linux/tools/testing/selftests/powerpc/mm'
> gcc -std=gnu99 -O2 -Wall -Werror -DGIT_VERSION='"v5.8-rc7-1456-gf59195f7faa4"' -I/home/sachin/linux/tools/testing/selftests/powerpc/include -m64 pkey_exec_prot.c /home/sachin/linux/tools/testing/selftests/kselftest_harness.h /home/sachin/linux/tools/testing/selftests/kselftest.h ../harness.c ../utils.c -o /home/sachin/linux/tools/testing/selftests/powerpc/mm/pkey_exec_prot
> In file included from pkey_exec_prot.c:18:
> /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:34: error: "SYS_pkey_mprotect" redefined [-Werror]
> #define SYS_pkey_mprotect 386
>
> In file included from /usr/include/sys/syscall.h:31,
> from /home/sachin/linux/tools/testing/selftests/powerpc/include/utils.h:47,
> from /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:12,
> from pkey_exec_prot.c:18:
> /usr/include/bits/syscall.h:1583: note: this is the location of the previous definition
> # define SYS_pkey_mprotect __NR_pkey_mprotect
^ permalink raw reply
* Re: [PATCH] powerpc: Fix P10 PVR revision in /proc/cpuinfo for SMT4 cores
From: Vaidyanathan Srinivasan @ 2020-08-03 10:32 UTC (permalink / raw)
To: Michael Neuling; +Cc: grimm, linuxppc-dev
In-Reply-To: <20200803035600.1820371-1-mikey@neuling.org>
* Michael Neuling <mikey@neuling.org> [2020-08-03 13:56:00]:
> On POWER10 bit 12 in the PVR indicates if the core is SMT4 or
> SMT8. Bit 12 is set for SMT4.
>
> Without this patch, /proc/cpuinfo on a SMT4 DD1 POWER10 looks like
> this:
> cpu : POWER10, altivec supported
> revision : 17.0 (pvr 0080 1100)
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com>
> ---
> arch/powerpc/kernel/setup-common.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
> index b198b0ff25..808ec9fab6 100644
> --- a/arch/powerpc/kernel/setup-common.c
> +++ b/arch/powerpc/kernel/setup-common.c
> @@ -311,6 +311,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
> min = pvr & 0xFF;
> break;
> case 0x004e: /* POWER9 bits 12-15 give chip type */
> + case 0x0080: /* POWER10 bit 12 gives SMT8/4 */
Correct. P9 and P10 have chip type (smt4 vs smt8 core) encoded in bits
PVR chip type bits 12-15.
Thanks for the fix.
--Vaidy
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Use address-of operator on section symbols
From: Geert Uytterhoeven @ 2020-08-03 10:06 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Arnd Bergmann, Geoff Levand, Linux Kernel Mailing List,
clang-built-linux, Paul Mackerras, Joel Stanley,
Nathan Chancellor, linuxppc-dev
In-Reply-To: <20200720210252.GO30544@gate.crashing.org>
Hi Segher,
On Mon, Jul 20, 2020 at 11:03 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> On Sat, Jul 18, 2020 at 09:50:50AM +0200, Geert Uytterhoeven wrote:
> > On Wed, Jun 24, 2020 at 6:02 AM Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > > /* If we have an image attached to us, it overrides anything
> > > * supplied by the loader. */
> > > - if (_initrd_end > _initrd_start) {
> > > + if (&_initrd_end > &_initrd_start) {
> >
> > Are you sure that fix is correct?
> >
> > extern char _initrd_start[];
> > extern char _initrd_end[];
> > extern char _esm_blob_start[];
> > extern char _esm_blob_end[];
> >
> > Of course the result of their comparison is a constant, as the addresses
> > are constant. If clangs warns about it, perhaps that warning should be moved
> > to W=1?
> >
> > But adding "&" is not correct, according to C.
>
> Why not?
>
> 6.5.3.2/3
> The unary & operator yields the address of its operand. [...]
> Otherwise, the result is a pointer to the object or function designated
> by its operand.
>
> This is the same as using the name of an array without anything else,
> yes. It is a bit clearer if it would not be declared as array, perhaps,
> but it is correct just fine like this.
Thanks, I stand corrected.
Regardless, the comparison is still a comparison between two constant
addresses, so my fear is that the compiler will start generating
warnings for that in the near or distant future, making this change
futile.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Build regressions/improvements in v5.8
From: Geert Uytterhoeven @ 2020-08-03 9:57 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: sparclinux, linuxppc-dev
In-Reply-To: <20200803095048.20102-1-geert@linux-m68k.org>
On Mon, Aug 3, 2020 at 11:53 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> JFYI, when comparing v5.8[1] to v5.8-rc7[3], the summaries are:
> - build errors: +2/-3
+ /kisskb/src/arch/powerpc/include/asm/mmu.h: error: unknown type
name 'next_tlbcam_idx': => 139:22
v5.8/powerpc-gcc4.9/corenet64_smp_defconfig
v5.8/powerpc-gcc4.9/ppc64_book3e_allmodconfig
v5.8/powerpc-gcc4.9/ppc64e_defconfig
v5.8/powerpc-gcc9/ppc64_book3e_allmodconfig
(fix available)
+ /kisskb/src/arch/sparc/include/asm/trap_block.h: error: 'NR_CPUS'
undeclared here (not in a function): => 54:39
v5.8/sparc64/sparc64-allmodconfig
v5.8/sparc64/sparc64-defconfig
> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/bcf876870b95592b52519ed4aafcf9d95999bc9c/ (192 out of 194 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/92ed301919932f777713b9172e525674157e983d/ (192 out of 194 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Clean code for synchronize mode
From: Shengjiu Wang @ 2020-08-03 8:04 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: <20200803054037.GA1056@Asurada-Nvidia>
On Mon, Aug 3, 2020 at 1:42 PM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>
> On Mon, Aug 03, 2020 at 11:17:54AM +0800, Shengjiu Wang wrote:
> > TX synchronous with RX: The RMR is no need to be changed when
> > Tx is enabled, the other configuration in hw_params() is enough for
>
> Probably you should explain why RMR can be removed, like what
> it really does so as to make it clear that there's no such a
> relationship between RMR and clock generating.
>
> Anyway, this is against the warning comments in the driver:
> /*
> * For SAI master mode, when Tx(Rx) sync with Rx(Tx) clock, Rx(Tx) will
> * generate bclk and frame clock for Tx(Rx), we should set RCR4(TCR4),
> * RCR5(TCR5) and RMR(TMR) for playback(capture), or there will be sync
> * error.
> */
>
> So would need to update it.
>
> > clock generation. The TCSR.TE is no need to enabled when only RX
> > is enabled.
>
> You are correct if there's only RX running without TX joining.
> However, that's something we can't guarantee. Then we'd enable
> TE after RE is enabled, which is against what RM recommends:
>
> # From 54.3.3.1 Synchronous mode in IMX6SXRM
> # If the receiver bit clock and frame sync are to be used by
> # both the transmitter and receiver, it is recommended that
> # the receiver is the last enabled and the first disabled.
>
> I remember I did this "ugly" design by strictly following what
> RM says. If hardware team has updated the RM or removed this
> limitation, please quote in the commit logs.
There is no change in RM and same recommandation.
My change does not violate the RM. The direction which generates
the clock is still last enabled.
>
> > + if (!sai->synchronous[TX] && sai->synchronous[RX] && !tx) {
> > + regmap_update_bits(sai->regmap, FSL_SAI_xCSR((!tx), ofs),
> > + FSL_SAI_CSR_TERE, FSL_SAI_CSR_TERE);
> > + } else if (!sai->synchronous[RX] && sai->synchronous[TX] && tx) {
> > + regmap_update_bits(sai->regmap, FSL_SAI_xCSR((!tx), ofs),
> > + FSL_SAI_CSR_TERE, FSL_SAI_CSR_TERE);
>
> Two identical regmap_update_bits calls -- both on !tx (RX?)
The content for regmap_update_bits is the same, but the precondition
is different.
The first one is for tx=false and enable TCSR.TE. (TX generate clock)
The second one is for tx=true and enable RSCR.RE (RX generate clock)
best regards
wang shengjiu
^ permalink raw reply
* [PATCH v2] selftests/powerpc: Fix pkey syscall redefinitions
From: Sandipan Das @ 2020-08-03 7:55 UTC (permalink / raw)
To: mpe; +Cc: sachinp, aneesh.kumar, linuxppc-dev
On some distros, there are conflicts w.r.t to redefinition
of pkey syscall numbers which cause build failures. This
fixes them.
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
Previous versions can be found at:
v1: https://lore.kernel.org/linuxppc-dev/20200803074043.466809-1-sandipan@linux.ibm.com/
Changes in v2:
- Fix incorrect commit message.
---
tools/testing/selftests/powerpc/include/pkeys.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/tools/testing/selftests/powerpc/include/pkeys.h b/tools/testing/selftests/powerpc/include/pkeys.h
index 6ba95039a034..26eef5c1f8ea 100644
--- a/tools/testing/selftests/powerpc/include/pkeys.h
+++ b/tools/testing/selftests/powerpc/include/pkeys.h
@@ -31,8 +31,13 @@
#define SI_PKEY_OFFSET 0x20
+#undef SYS_pkey_mprotect
#define SYS_pkey_mprotect 386
+
+#undef SYS_pkey_alloc
#define SYS_pkey_alloc 384
+
+#undef SYS_pkey_free
#define SYS_pkey_free 385
#define PKEY_BITS_PER_PKEY 2
--
2.25.1
^ permalink raw reply related
* [PATCH] powerpc/powernv/sriov: Fix use of uninitialised variable
From: Oliver O'Halloran @ 2020-08-03 7:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nathan Chancellor, Oliver O'Halloran
Initialising the value before using it is generally regarded as a good
idea so do that.
Fixes: 4c51f3e1e870 ("powerpc/powernv/sriov: Make single PE mode a per-BAR setting")
Reported-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
---
arch/powerpc/platforms/powernv/pci-sriov.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-sriov.c b/arch/powerpc/platforms/powernv/pci-sriov.c
index 7894745fd4f8..c4434f20f42f 100644
--- a/arch/powerpc/platforms/powernv/pci-sriov.c
+++ b/arch/powerpc/platforms/powernv/pci-sriov.c
@@ -253,9 +253,9 @@ void pnv_pci_ioda_fixup_iov(struct pci_dev *pdev)
resource_size_t pnv_pci_iov_resource_alignment(struct pci_dev *pdev,
int resno)
{
+ resource_size_t align = pci_iov_resource_size(pdev, resno);
struct pnv_phb *phb = pci_bus_to_pnvhb(pdev->bus);
struct pnv_iov_data *iov = pnv_iov_get(pdev);
- resource_size_t align;
/*
* iov can be null if we have an SR-IOV device with IOV BAR that can't
@@ -266,8 +266,6 @@ resource_size_t pnv_pci_iov_resource_alignment(struct pci_dev *pdev,
if (!iov)
return align;
- align = pci_iov_resource_size(pdev, resno);
-
/*
* If we're using single mode then we can just use the native VF BAR
* alignment. We validated that it's possible to use a single PE
--
2.26.2
^ permalink raw reply related
* [PATCH] selftests/powerpc: Fix pkey syscall redefinitions
From: Sandipan Das @ 2020-08-03 7:40 UTC (permalink / raw)
To: mpe; +Cc: sachinp, aneesh.kumar, linuxppc-dev
Some distros have the pkey syscall numbers defined under
unistd.h. This conflicts with the definitions in the pkeys
selftest header and causes build failures.
E.g. this works
$ grep -nr "SYS_pkey" /usr/include/
/usr/include/bits/syscall.h:1575:# define SYS_pkey_alloc __NR_pkey_alloc
/usr/include/bits/syscall.h:1579:# define SYS_pkey_free __NR_pkey_free
/usr/include/bits/syscall.h:1583:# define SYS_pkey_mprotect __NR_pkey_mprotect
While this does not
$ grep -nr "SYS_pkey" /usr/include/
/usr/include/bits/syscall.h:1575:# define SYS_pkey_alloc __NR_pkey_alloc
/usr/include/bits/syscall.h:1579:# define SYS_pkey_free __NR_pkey_free
/usr/include/bits/syscall.h:1583:# define SYS_pkey_mprotect __NR_pkey_mprotect
/usr/include/asm-generic/unistd.h:728:__SYSCALL(__NR_pkey_mprotect, sys_pkey_mprotect)
/usr/include/asm-generic/unistd.h:730:__SYSCALL(__NR_pkey_alloc, sys_pkey_alloc)
/usr/include/asm-generic/unistd.h:732:__SYSCALL(__NR_pkey_free, sys_pkey_free)
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
tools/testing/selftests/powerpc/include/pkeys.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/tools/testing/selftests/powerpc/include/pkeys.h b/tools/testing/selftests/powerpc/include/pkeys.h
index 6ba95039a034..26eef5c1f8ea 100644
--- a/tools/testing/selftests/powerpc/include/pkeys.h
+++ b/tools/testing/selftests/powerpc/include/pkeys.h
@@ -31,8 +31,13 @@
#define SI_PKEY_OFFSET 0x20
+#undef SYS_pkey_mprotect
#define SYS_pkey_mprotect 386
+
+#undef SYS_pkey_alloc
#define SYS_pkey_alloc 384
+
+#undef SYS_pkey_free
#define SYS_pkey_free 385
#define PKEY_BITS_PER_PKEY 2
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 2/2 v2] powerpc/powernv: Enable and setup PCI P2P
From: Oliver O'Halloran @ 2020-08-03 7:35 UTC (permalink / raw)
To: Max Gurtovoy
Cc: vladimirk, Carol L Soto, linux-pci, shlomin, israelr,
Frederic Barrat, idanw, linuxppc-dev, Christoph Hellwig, aneela
In-Reply-To: <20200430131520.51211-2-maxg@mellanox.com>
On Thu, Apr 30, 2020 at 11:15 PM Max Gurtovoy <maxg@mellanox.com> wrote:
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 57d3a6a..9ecc576 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -3706,18 +3706,208 @@ static void pnv_pci_ioda_dma_bus_setup(struct pci_bus *bus)
> }
> }
>
> +#ifdef CONFIG_PCI_P2PDMA
> +static DEFINE_MUTEX(p2p_mutex);
> +
> +static bool pnv_pci_controller_owns_addr(struct pci_controller *hose,
> + phys_addr_t addr, size_t size)
> +{
> + int i;
> +
> + /*
> + * It seems safe to assume the full range is under the same PHB, so we
> + * can ignore the size.
> + */
> + for (i = 0; i < ARRAY_SIZE(hose->mem_resources); i++) {
> + struct resource *res = &hose->mem_resources[i];
> +
> + if (res->flags && addr >= res->start && addr < res->end)
> + return true;
> + }
> + return false;
> +}
> +
> +/*
> + * find the phb owning a mmio address if not owned locally
> + */
> +static struct pnv_phb *pnv_pci_find_owning_phb(struct pci_dev *pdev,
> + phys_addr_t addr, size_t size)
> +{
> + struct pci_controller *hose;
> +
> + /* fast path */
> + if (pnv_pci_controller_owns_addr(pdev->bus->sysdata, addr, size))
> + return NULL;
Do we actually need this fast path? It's going to be slow either way.
Also if a device is doing p2p to another device under the same PHB
then it should not be happening via the root complex. Is this a case
you've tested?
> + list_for_each_entry(hose, &hose_list, list_node) {
> + struct pnv_phb *phb = hose->private_data;
> +
> + if (phb->type != PNV_PHB_NPU_NVLINK &&
> + phb->type != PNV_PHB_NPU_OCAPI) {
> + if (pnv_pci_controller_owns_addr(hose, addr, size))
> + return phb;
> + }
> + }
> + return NULL;
> +}
> +
> +static u64 pnv_pci_dma_dir_to_opal_p2p(enum dma_data_direction dir)
> +{
> + if (dir == DMA_TO_DEVICE)
> + return OPAL_PCI_P2P_STORE;
> + else if (dir == DMA_FROM_DEVICE)
> + return OPAL_PCI_P2P_LOAD;
> + else if (dir == DMA_BIDIRECTIONAL)
> + return OPAL_PCI_P2P_LOAD | OPAL_PCI_P2P_STORE;
> + else
> + return 0;
> +}
> +
> +static int pnv_pci_ioda_enable_p2p(struct pci_dev *initiator,
> + struct pnv_phb *phb_target,
> + enum dma_data_direction dir)
> +{
> + struct pci_controller *hose;
> + struct pnv_phb *phb_init;
> + struct pnv_ioda_pe *pe_init;
> + u64 desc;
> + int rc;
> +
> + if (!opal_check_token(OPAL_PCI_SET_P2P))
> + return -ENXIO;
> +
> + hose = pci_bus_to_host(initiator->bus);
> + phb_init = hose->private_data;
You can use the pci_bus_to_pnvhb() helper
> +
> + pe_init = pnv_ioda_get_pe(initiator);
> + if (!pe_init)
> + return -ENODEV;
> +
> + if (!pe_init->tce_bypass_enabled)
> + return -EINVAL;
> +
> + /*
> + * Configuring the initiator's PHB requires to adjust its TVE#1
> + * setting. Since the same device can be an initiator several times for
> + * different target devices, we need to keep a reference count to know
> + * when we can restore the default bypass setting on its TVE#1 when
> + * disabling. Opal is not tracking PE states, so we add a reference
> + * count on the PE in linux.
> + *
> + * For the target, the configuration is per PHB, so we keep a
> + * target reference count on the PHB.
> + */
This irks me a bit because configuring the DMA address limits for the
TVE is the kernel's job. What we really should be doing is using
opal_pci_map_pe_dma_window_real() to set the bypass-mode address limit
for the TVE to something large enough to hit the MMIO ranges rather
than having set_p2p do it as a side effect. Unfortunately, for some
reason skiboot doesn't implement support for enabling 56bit addressing
using opal_pci_map_pe_dma_window_real() and we do need to support
older kernel's which used this stuff so I guess we're stuck with it
for now. It'd be nice if we could fix this in the longer term
though...
> + mutex_lock(&p2p_mutex);
> +
> + desc = OPAL_PCI_P2P_ENABLE | pnv_pci_dma_dir_to_opal_p2p(dir);
> + /* always go to opal to validate the configuration */
> + rc = opal_pci_set_p2p(phb_init->opal_id, phb_target->opal_id, desc,
> + pe_init->pe_number);
> + if (rc != OPAL_SUCCESS) {
> + rc = -EIO;
> + goto out;
> + }
> +
> + pe_init->p2p_initiator_count++;
> + phb_target->p2p_target_count++;
> +
> + rc = 0;
> +out:
> + mutex_unlock(&p2p_mutex);
> + return rc;
> +}
> +
> +static int pnv_pci_dma_map_resource(struct pci_dev *pdev,
> + phys_addr_t phys_addr, size_t size,
> + enum dma_data_direction dir)
> +{
> + struct pnv_phb *target_phb;
> +
> + target_phb = pnv_pci_find_owning_phb(pdev, phys_addr, size);
> + if (!target_phb)
> + return 0;
> +
> + return pnv_pci_ioda_enable_p2p(pdev, target_phb, dir);
> +}
> +
> +static int pnv_pci_ioda_disable_p2p(struct pci_dev *initiator,
> + struct pnv_phb *phb_target)
> +{
> + struct pci_controller *hose;
> + struct pnv_phb *phb_init;
> + struct pnv_ioda_pe *pe_init;
> + int rc;
> +
> + if (!opal_check_token(OPAL_PCI_SET_P2P))
> + return -ENXIO;
This should probably have a WARN_ON() since we can't hit this path
unless the initial map succeeds.
> + hose = pci_bus_to_host(initiator->bus);
> + phb_init = hose->private_data;
pci_bus_to_pnvhb()
> + pe_init = pnv_ioda_get_pe(initiator);
> + if (!pe_init)
> + return -ENODEV;
> +
> + mutex_lock(&p2p_mutex);
> +
> + if (!pe_init->p2p_initiator_count || !phb_target->p2p_target_count) {
> + rc = -EINVAL;
> + goto out;
> + }
> +
> + if (--pe_init->p2p_initiator_count == 0)
> + pnv_pci_ioda2_set_bypass(pe_init, true);
> +
> + if (--phb_target->p2p_target_count == 0) {
> + rc = opal_pci_set_p2p(phb_init->opal_id, phb_target->opal_id,
> + 0, pe_init->pe_number);
> + if (rc != OPAL_SUCCESS) {
> + rc = -EIO;
> + goto out;
> + }
> + }
> +
> + rc = 0;
> +out:
> + mutex_unlock(&p2p_mutex);
> + return rc;
> +}
> +
> +static void pnv_pci_dma_unmap_resource(struct pci_dev *pdev,
> + dma_addr_t addr, size_t size,
> + enum dma_data_direction dir)
> +{
> + struct pnv_phb *target_phb;
> + int rc;
> +
> + target_phb = pnv_pci_find_owning_phb(pdev, addr, size);
> + if (!target_phb)
> + return;
> +
> + rc = pnv_pci_ioda_disable_p2p(pdev, target_phb);
> + if (rc)
> + dev_err(&pdev->dev, "Failed to undo PCI peer-to-peer setup for address %llx: %d\n",
> + addr, rc);
Use pci_err() or pe_err().
^ permalink raw reply
* linux-next: manual merge of the char-misc tree with the powerpc tree
From: Stephen Rothwell @ 2020-08-03 6:55 UTC (permalink / raw)
To: Greg KH, Arnd Bergmann, Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Lee Jones, Linux Kernel Mailing List,
Alastair D'Silva
[-- Attachment #1: Type: text/plain, Size: 834 bytes --]
Hi all,
Today's linux-next merge of the char-misc tree got a conflict in:
drivers/misc/ocxl/config.c
between commit:
3591538a31af ("ocxl: Address kernel doc errors & warnings")
from the powerpc tree and commit:
28fc491e9be6 ("misc: ocxl: config: Provide correct formatting to function headers")
from the char-misc tree.
I fixed it up (as it was just differences in comments, I just arbitrarily
chose the latter version) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 09/10] Powerpc/smp: Create coregroup domain
From: Srikar Dronamraju @ 2020-08-03 6:01 UTC (permalink / raw)
To: Valentin Schneider
Cc: Nathan Lynch, Gautham R Shenoy, Michael Neuling, Peter Zijlstra,
LKML, Nicholas Piggin, Morten Rasmussen, Oliver O'Halloran,
Jordan Niethe, linuxppc-dev, Ingo Molnar
In-Reply-To: <jhjlfj0ijeg.mognet@arm.com>
> > Also in the current P9 itself, two neighbouring core-pairs form a quad.
> > Cache latency within a quad is better than a latency to a distant core-pair.
> > Cache latency within a core pair is way better than latency within a quad.
> > So if we have only 4 threads running on a DIE all of them accessing the same
> > cache-lines, then we could probably benefit if all the tasks were to run
> > within the quad aka MC/Coregroup.
> >
>
> Did you test this? WRT load balance we do try to balance "load" over the
> different domain spans, so if you represent quads as their own MC domain,
> you would AFAICT end up spreading tasks over the quads (rather than packing
> them) when balancing at e.g. DIE level. The desired behaviour might be
> hackable with some more ASYM_PACKING, but I'm not sure I should be
> suggesting that :-)
>
Agree, load balance will try to spread the load across the quads. In my hack,
I was explicitly marking QUAD domains as !SD_PREFER_SIBLING + relaxing few
load spreading rules when SD_PREFER_SIBLING was not set. And this was on a
slightly older kernel (without recent Vincent's load balance overhaul).
> > I have found some benchmarks which are latency sensitive to benefit by
> > having a grouping a quad level (using kernel hacks and not backed by
> > firmware changes). Gautham also found similar results in his experiments
> > but he only used binding within the stock kernel.
> >
>
> IIUC you reflect this "fabric quirk" (i.e. coregroups) using this DT
> binding thing.
>
> That's also where things get interesting (for me) because I experienced
> something similar on another arm64 platform (ThunderX1). This was more
> about cache bandwidth than cache latency, but IMO it's in the same bag of
> fabric quirks. I blabbered a bit about this at last LPC [1], but kind of
> gave up on it given the TX1 was the only (arm64) platform where I could get
> both significant and reproducible results.
>
> Now, if you folks are seeing this on completely different hardware and have
> "real" workloads that truly benefit from this kind of domain partitioning,
> this might be another incentive to try and sort of generalize this. That's
> outside the scope of your series, but your findings give me some hope!
>
> I think what I had in mind back then was that if enough folks cared about
> it, we might get some bits added to the ACPI spec; something along the
> lines of proximity domains for the caches described in PPTT, IOW a cache
> distance matrix. I don't really know what it'll take to get there, but I
> figured I'd dump this in case someone's listening :-)
>
Very interesting.
> > I am not setting SD_SHARE_PKG_RESOURCES in MC/Coregroup sd_flags as in MC
> > domain need not be LLC domain for Power.
>
> From what I understood your MC domain does seem to map to LLC; but in any
> case, shouldn't you set that flag at least for BIGCORE (i.e. L2)? AIUI with
> your changes your sd_llc is gonna be SMT, and that's not going to be a very
> big mask. IMO you do want to correctly reflect your LLC situation via this
> flag to make cpus_share_cache() work properly.
I detect if the LLC is shared at BIGCORE, and if they are shared at BIGCORE,
then I dynamically rename the DOMAIN as CACHE and enable
SD_SHARE_PKG_RESOURCES in that domain.
>
> [1]: https://linuxplumbersconf.org/event/4/contributions/484/
Thanks for the pointer.
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH v2 15/16] powerpc/powernv/sriov: Make single PE mode a per-BAR setting
From: Michael Ellerman @ 2020-08-03 5:57 UTC (permalink / raw)
To: Nathan Chancellor; +Cc: linuxppc-dev, Oliver O'Halloran, clang-built-linux
In-Reply-To: <20200803044609.GB195@Ryzen-9-3900X.localdomain>
Nathan Chancellor <natechancellor@gmail.com> writes:
> On Sun, Aug 02, 2020 at 11:12:23PM +1000, Michael Ellerman wrote:
>> Nathan Chancellor <natechancellor@gmail.com> writes:
>> > On Wed, Jul 22, 2020 at 04:57:14PM +1000, Oliver O'Halloran wrote:
>> >> Using single PE BARs to map an SR-IOV BAR is really a choice about what
>> >> strategy to use when mapping a BAR. It doesn't make much sense for this to
>> >> be a global setting since a device might have one large BAR which needs to
>> >> be mapped with single PE windows and another smaller BAR that can be mapped
>> >> with a regular segmented window. Make the segmented vs single decision a
>> >> per-BAR setting and clean up the logic that decides which mode to use.
>> >>
>> >> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
>> >> ---
>> >> v2: Dropped unused total_vfs variables in pnv_pci_ioda_fixup_iov_resources()
>> >> Dropped bar_no from pnv_pci_iov_resource_alignment()
>> >> Minor re-wording of comments.
>> >> ---
>> >> arch/powerpc/platforms/powernv/pci-sriov.c | 131 ++++++++++-----------
>> >> arch/powerpc/platforms/powernv/pci.h | 11 +-
>> >> 2 files changed, 73 insertions(+), 69 deletions(-)
>> >>
>> >> diff --git a/arch/powerpc/platforms/powernv/pci-sriov.c b/arch/powerpc/platforms/powernv/pci-sriov.c
>> >> index ce8ad6851d73..76215d01405b 100644
>> >> --- a/arch/powerpc/platforms/powernv/pci-sriov.c
>> >> +++ b/arch/powerpc/platforms/powernv/pci-sriov.c
>> >> @@ -260,42 +256,40 @@ void pnv_pci_ioda_fixup_iov(struct pci_dev *pdev)
>> >> resource_size_t pnv_pci_iov_resource_alignment(struct pci_dev *pdev,
>> >> int resno)
>> >> {
>> >> - struct pnv_phb *phb = pci_bus_to_pnvhb(pdev->bus);
>> >> struct pnv_iov_data *iov = pnv_iov_get(pdev);
>> >> resource_size_t align;
>> >>
>> >> + /*
>> >> + * iov can be null if we have an SR-IOV device with IOV BAR that can't
>> >> + * be placed in the m64 space (i.e. The BAR is 32bit or non-prefetch).
>> >> + * In that case we don't allow VFs to be enabled since one of their
>> >> + * BARs would not be placed in the correct PE.
>> >> + */
>> >> + if (!iov)
>> >> + return align;
>> >> + if (!iov->vfs_expanded)
>> >> + return align;
>> >> +
>> >> + align = pci_iov_resource_size(pdev, resno);
>>
>> That's, oof.
>>
>> > I am not sure if it has been reported yet but clang points out that
>> > align is initialized after its use:
>> >
>> > arch/powerpc/platforms/powernv/pci-sriov.c:267:10: warning: variable 'align' is uninitialized when used here [-Wuninitialized]
>> > return align;
>> > ^~~~~
>> > arch/powerpc/platforms/powernv/pci-sriov.c:258:23: note: initialize the variable 'align' to silence this warning
>> > resource_size_t align;
>> > ^
>> > = 0
>> > 1 warning generated.
>>
>> But I can't get gcc to warn about it?
>>
>> It produces some code, so it's not like the whole function has been
>> elided or something. I'm confused.
>
> -Wmaybe-uninitialized was disabled in commit 78a5255ffb6a ("Stop the
> ad-hoc games with -Wno-maybe-initialized") upstream so GCC won't warn on
> stuff like this anymore.
Seems so. Just that there's no "maybe" here, it's very uninitialised.
> I would assume the function should still be generated since those checks
> are relevant, just the return value is bogus.
Yeah, just sometimes missing warnings boil down to the compiler eliding
whole sections of code, if it can convince itself they're unreachable.
AFAICS there's nothing weird going on here that should confuse GCC, it's
about as straight forward as it gets.
Actually I can reproduce it with:
$ cat > test.c <<EOF
int foo(void *p)
{
unsigned align;
if (!p)
return align;
return 0;
}
EOF
$ gcc -Wall -Wno-maybe-uninitialized -c test.c
$
No warning.
But I guess that's behaving as documented. The compiler can't prove that
foo() will be called with p == NULL, so it doesn't warn.
cheers
^ permalink raw reply
* Re: [merge] Build failure selftest/powerpc/mm/pkey_exec_prot
From: Sachin Sant @ 2020-08-03 5:43 UTC (permalink / raw)
To: Sandipan Das; +Cc: linuxppc-dev
In-Reply-To: <63dc2f90-9a16-21f8-51fa-cfef9df80676@linux.ibm.com>
> On 02-Aug-2020, at 10:58 PM, Sandipan Das <sandipan@linux.ibm.com> wrote:
>
> Hi Sachin,
>
> On 02/08/20 4:45 pm, Sachin Sant wrote:
>> pkey_exec_prot test from linuxppc merge branch (3f68564f1f5a) fails to
>> build due to following error:
>>
>> gcc -std=gnu99 -O2 -Wall -Werror -DGIT_VERSION='"v5.8-rc7-1276-g3f68564f1f5a"' -I/home/sachin/linux/tools/testing/selftests/powerpc/include -m64 pkey_exec_prot.c /home/sachin/linux/tools/testing/selftests/kselftest_harness.h /home/sachin/linux/tools/testing/selftests/kselftest.h ../harness.c ../utils.c -o /home/sachin/linux/tools/testing/selftests/powerpc/mm/pkey_exec_prot
>> In file included from pkey_exec_prot.c:18:
>> /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:34: error: "SYS_pkey_mprotect" redefined [-Werror]
>> #define SYS_pkey_mprotect 386
>>
>> In file included from /usr/include/sys/syscall.h:31,
>> from /home/sachin/linux/tools/testing/selftests/powerpc/include/utils.h:47,
>> from /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:12,
>> from pkey_exec_prot.c:18:
>> /usr/include/bits/syscall.h:1583: note: this is the location of the previous definition
>> # define SYS_pkey_mprotect __NR_pkey_mprotect
>>
>> commit 128d3d021007 introduced this error.
>> selftests/powerpc: Move pkey helpers to headers
>>
>> Possibly the # defines for sys calls can be retained in pkey_exec_prot.c or
>>
>
> I am unable to reproduce this on the latest merge branch (HEAD at f59195f7faa4).
> I don't see any redefinitions in pkey_exec_prot.c either.
>
I can still see this problem on latest merge branch.
I have following gcc version
gcc version 8.3.1 20191121
# git show
commit f59195f7faa4896b7c1d947ac2dba29ec18ad569 (HEAD -> merge, origin/merge)
Merge: 70ce795dac09 ac3a0c847296
Author: Michael Ellerman <mpe@ellerman.id.au>
Date: Sun Aug 2 23:18:03 2020 +1000
Automatic merge of 'master', 'next' and 'fixes' (2020-08-02 23:18)
# make -C powerpc
……
…...
BUILD_TARGET=/home/sachin/linux/tools/testing/selftests/powerpc/mm; mkdir -p $BUILD_TARGET; make OUTPUT=$BUILD_TARGET -k -C mm all
make[1]: Entering directory '/home/sachin/linux/tools/testing/selftests/powerpc/mm'
gcc -std=gnu99 -O2 -Wall -Werror -DGIT_VERSION='"v5.8-rc7-1456-gf59195f7faa4"' -I/home/sachin/linux/tools/testing/selftests/powerpc/include -m64 pkey_exec_prot.c /home/sachin/linux/tools/testing/selftests/kselftest_harness.h /home/sachin/linux/tools/testing/selftests/kselftest.h ../harness.c ../utils.c -o /home/sachin/linux/tools/testing/selftests/powerpc/mm/pkey_exec_prot
In file included from pkey_exec_prot.c:18:
/home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:34: error: "SYS_pkey_mprotect" redefined [-Werror]
#define SYS_pkey_mprotect 386
In file included from /usr/include/sys/syscall.h:31,
from /home/sachin/linux/tools/testing/selftests/powerpc/include/utils.h:47,
from /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:12,
from pkey_exec_prot.c:18:
/usr/include/bits/syscall.h:1583: note: this is the location of the previous definition
# define SYS_pkey_mprotect __NR_pkey_mprotect
In file included from pkey_exec_prot.c:18:
/home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:35: error: "SYS_pkey_alloc" redefined [-Werror]
#define SYS_pkey_alloc 384
In file included from /usr/include/sys/syscall.h:31,
from /home/sachin/linux/tools/testing/selftests/powerpc/include/utils.h:47,
from /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:12,
from pkey_exec_prot.c:18:
/usr/include/bits/syscall.h:1575: note: this is the location of the previous definition
# define SYS_pkey_alloc __NR_pkey_alloc
In file included from pkey_exec_prot.c:18:
/home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:36: error: "SYS_pkey_free" redefined [-Werror]
#define SYS_pkey_free 385
In file included from /usr/include/sys/syscall.h:31,
from /home/sachin/linux/tools/testing/selftests/powerpc/include/utils.h:47,
from /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:12,
from pkey_exec_prot.c:18:
/usr/include/bits/syscall.h:1579: note: this is the location of the previous definition
# define SYS_pkey_free __NR_pkey_free
cc1: all warnings being treated as errors
make[1]: *** [../../lib.mk:142: /home/sachin/linux/tools/testing/selftests/powerpc/mm/pkey_exec_prot] Error 1
gcc -std=gnu99 -O2 -Wall -Werror -DGIT_VERSION='"v5.8-rc7-1456-gf59195f7faa4"' -I/home/sachin/linux/tools/testing/selftests/powerpc/include -m64 pkey_siginfo.c /home/sachin/linux/tools/testing/selftests/kselftest_harness.h /home/sachin/linux/tools/testing/selftests/kselftest.h ../harness.c ../utils.c -lpthread -o /home/sachin/linux/tools/testing/selftests/powerpc/mm/pkey_siginfo
In file included from pkey_siginfo.c:22:
/home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:34: error: "SYS_pkey_mprotect" redefined [-Werror]
#define SYS_pkey_mprotect 386
In file included from /usr/include/sys/syscall.h:31,
from /home/sachin/linux/tools/testing/selftests/powerpc/include/utils.h:47,
from /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:12,
from pkey_siginfo.c:22:
/usr/include/bits/syscall.h:1583: note: this is the location of the previous definition
# define SYS_pkey_mprotect __NR_pkey_mprotect
In file included from pkey_siginfo.c:22:
/home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:35: error: "SYS_pkey_alloc" redefined [-Werror]
#define SYS_pkey_alloc 384
In file included from /usr/include/sys/syscall.h:31,
from /home/sachin/linux/tools/testing/selftests/powerpc/include/utils.h:47,
from /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:12,
from pkey_siginfo.c:22:
/usr/include/bits/syscall.h:1575: note: this is the location of the previous definition
# define SYS_pkey_alloc __NR_pkey_alloc
In file included from pkey_siginfo.c:22:
/home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:36: error: "SYS_pkey_free" redefined [-Werror]
#define SYS_pkey_free 385
In file included from /usr/include/sys/syscall.h:31,
from /home/sachin/linux/tools/testing/selftests/powerpc/include/utils.h:47,
from /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:12,
from pkey_siginfo.c:22:
/usr/include/bits/syscall.h:1579: note: this is the location of the previous definition
# define SYS_pkey_free __NR_pkey_free
cc1: all warnings being treated as errors
make[1]: *** [../../lib.mk:142: /home/sachin/linux/tools/testing/selftests/powerpc/mm/pkey_siginfo] Error 1
make[1]: Target 'all' not remade because of errors.
make[1]: Leaving directory '/home/sachin/linux/tools/testing/selftests/powerpc/mm'
make: *** [Makefile:41: mm] Error 2
make: Leaving directory '/home/sachin/linux/tools/testing/selftests/powerpc'
#
Thanks
-Sachin
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Clean code for synchronize mode
From: Nicolin Chen @ 2020-08-03 5:40 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, tiwai, lgirdwood,
perex, broonie, festevam, linux-kernel
In-Reply-To: <1596424674-32127-1-git-send-email-shengjiu.wang@nxp.com>
On Mon, Aug 03, 2020 at 11:17:54AM +0800, Shengjiu Wang wrote:
> TX synchronous with RX: The RMR is no need to be changed when
> Tx is enabled, the other configuration in hw_params() is enough for
Probably you should explain why RMR can be removed, like what
it really does so as to make it clear that there's no such a
relationship between RMR and clock generating.
Anyway, this is against the warning comments in the driver:
/*
* For SAI master mode, when Tx(Rx) sync with Rx(Tx) clock, Rx(Tx) will
* generate bclk and frame clock for Tx(Rx), we should set RCR4(TCR4),
* RCR5(TCR5) and RMR(TMR) for playback(capture), or there will be sync
* error.
*/
So would need to update it.
> clock generation. The TCSR.TE is no need to enabled when only RX
> is enabled.
You are correct if there's only RX running without TX joining.
However, that's something we can't guarantee. Then we'd enable
TE after RE is enabled, which is against what RM recommends:
# From 54.3.3.1 Synchronous mode in IMX6SXRM
# If the receiver bit clock and frame sync are to be used by
# both the transmitter and receiver, it is recommended that
# the receiver is the last enabled and the first disabled.
I remember I did this "ugly" design by strictly following what
RM says. If hardware team has updated the RM or removed this
limitation, please quote in the commit logs.
> + if (!sai->synchronous[TX] && sai->synchronous[RX] && !tx) {
> + regmap_update_bits(sai->regmap, FSL_SAI_xCSR((!tx), ofs),
> + FSL_SAI_CSR_TERE, FSL_SAI_CSR_TERE);
> + } else if (!sai->synchronous[RX] && sai->synchronous[TX] && tx) {
> + regmap_update_bits(sai->regmap, FSL_SAI_xCSR((!tx), ofs),
> + FSL_SAI_CSR_TERE, FSL_SAI_CSR_TERE);
Two identical regmap_update_bits calls -- both on !tx (RX?)
^ permalink raw reply
* Re: powerpc: build failures in Linus' tree
From: Willy Tarreau @ 2020-08-03 5:33 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux-kernel Mailing List, Linus Torvalds, Paul Mackerras,
PowerPC
In-Reply-To: <20200803141017.55dd6cc7@canb.auug.org.au>
On Mon, Aug 03, 2020 at 02:10:17PM +1000, Stephen Rothwell wrote:
> Our mails have crossed.
Ah indeed :-)
> I just sent a more comprehensive patch. I
> think your patch would require a lot of build testing and even then may
> fail for some CONFIG combination that we didn't test or added in the
> future (or someone just made up).
Your looks far more complete and very likely more future-proof, I
totally agree.
Thanks!
Willy
^ permalink raw reply
* Re: [PATCH] powerpc: fix up PPC_FSL_BOOK3E build
From: Stephen Rothwell @ 2020-08-03 4:59 UTC (permalink / raw)
To: Michael Ellerman
Cc: Linus Torvalds, Linux PowerPC List, Willy Tarreau,
Linux Kernel Mailing List
In-Reply-To: <20200803135447.3833067d@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
Hi all,
On Mon, 3 Aug 2020 13:54:47 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Commit
>
> 1c9df907da83 ("random: fix circular include dependency on arm64 after addition of percpu.h")
>
> exposed a curcular include dependency:
>
> asm/mmu.h includes asm/percpu.h, which includes asm/paca.h, which
> includes asm/mmu.h
>
> So fix it by extracting the small part of asm/mmu.h that needs
> asm/percu.h into a new file and including that where necessary.
>
> Cc: Willy Tarreau <w@1wt.eu>
> Cc: <stable@kernel.org>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
I should have put:
Fixes: 1c9df907da83 ("random: fix circular include dependency on arm64 after addition of percpu.h")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 15/16] powerpc/powernv/sriov: Make single PE mode a per-BAR setting
From: Nathan Chancellor @ 2020-08-03 4:46 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Oliver O'Halloran, clang-built-linux
In-Reply-To: <87r1sp19ag.fsf@mpe.ellerman.id.au>
On Sun, Aug 02, 2020 at 11:12:23PM +1000, Michael Ellerman wrote:
> Nathan Chancellor <natechancellor@gmail.com> writes:
> > On Wed, Jul 22, 2020 at 04:57:14PM +1000, Oliver O'Halloran wrote:
> >> Using single PE BARs to map an SR-IOV BAR is really a choice about what
> >> strategy to use when mapping a BAR. It doesn't make much sense for this to
> >> be a global setting since a device might have one large BAR which needs to
> >> be mapped with single PE windows and another smaller BAR that can be mapped
> >> with a regular segmented window. Make the segmented vs single decision a
> >> per-BAR setting and clean up the logic that decides which mode to use.
> >>
> >> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
> >> ---
> >> v2: Dropped unused total_vfs variables in pnv_pci_ioda_fixup_iov_resources()
> >> Dropped bar_no from pnv_pci_iov_resource_alignment()
> >> Minor re-wording of comments.
> >> ---
> >> arch/powerpc/platforms/powernv/pci-sriov.c | 131 ++++++++++-----------
> >> arch/powerpc/platforms/powernv/pci.h | 11 +-
> >> 2 files changed, 73 insertions(+), 69 deletions(-)
> >>
> >> diff --git a/arch/powerpc/platforms/powernv/pci-sriov.c b/arch/powerpc/platforms/powernv/pci-sriov.c
> >> index ce8ad6851d73..76215d01405b 100644
> >> --- a/arch/powerpc/platforms/powernv/pci-sriov.c
> >> +++ b/arch/powerpc/platforms/powernv/pci-sriov.c
> >> @@ -260,42 +256,40 @@ void pnv_pci_ioda_fixup_iov(struct pci_dev *pdev)
> >> resource_size_t pnv_pci_iov_resource_alignment(struct pci_dev *pdev,
> >> int resno)
> >> {
> >> - struct pnv_phb *phb = pci_bus_to_pnvhb(pdev->bus);
> >> struct pnv_iov_data *iov = pnv_iov_get(pdev);
> >> resource_size_t align;
> >>
> >> + /*
> >> + * iov can be null if we have an SR-IOV device with IOV BAR that can't
> >> + * be placed in the m64 space (i.e. The BAR is 32bit or non-prefetch).
> >> + * In that case we don't allow VFs to be enabled since one of their
> >> + * BARs would not be placed in the correct PE.
> >> + */
> >> + if (!iov)
> >> + return align;
> >> + if (!iov->vfs_expanded)
> >> + return align;
> >> +
> >> + align = pci_iov_resource_size(pdev, resno);
>
> That's, oof.
>
> > I am not sure if it has been reported yet but clang points out that
> > align is initialized after its use:
> >
> > arch/powerpc/platforms/powernv/pci-sriov.c:267:10: warning: variable 'align' is uninitialized when used here [-Wuninitialized]
> > return align;
> > ^~~~~
> > arch/powerpc/platforms/powernv/pci-sriov.c:258:23: note: initialize the variable 'align' to silence this warning
> > resource_size_t align;
> > ^
> > = 0
> > 1 warning generated.
>
> But I can't get gcc to warn about it?
>
> It produces some code, so it's not like the whole function has been
> elided or something. I'm confused.
>
> cheers
-Wmaybe-uninitialized was disabled in commit 78a5255ffb6a ("Stop the
ad-hoc games with -Wno-maybe-initialized") upstream so GCC won't warn on
stuff like this anymore.
I would assume the function should still be generated since those checks
are relevant, just the return value is bogus.
Cheers,
Nathan
^ permalink raw reply
* Re: powerpc: build failures in Linus' tree
From: Stephen Rothwell @ 2020-08-03 4:10 UTC (permalink / raw)
To: Willy Tarreau
Cc: Linux-kernel Mailing List, Linus Torvalds, Paul Mackerras,
PowerPC
In-Reply-To: <20200803034547.GA15501@1wt.eu>
[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]
Hi Willy,
On Mon, 3 Aug 2020 05:45:47 +0200 Willy Tarreau <w@1wt.eu> wrote:
>
> On Sun, Aug 02, 2020 at 07:20:19PM +0200, Willy Tarreau wrote:
> > On Sun, Aug 02, 2020 at 08:48:42PM +1000, Stephen Rothwell wrote:
> > >
> > > We are getting build failures in some PowerPC configs for Linus' tree.
> > > See e.g. http://kisskb.ellerman.id.au/kisskb/buildresult/14306515/
> > >
> > > In file included from /kisskb/src/arch/powerpc/include/asm/paca.h:18,
> > > from /kisskb/src/arch/powerpc/include/asm/percpu.h:13,
> > > from /kisskb/src/include/linux/random.h:14,
> > > from /kisskb/src/include/linux/net.h:18,
> > > from /kisskb/src/net/ipv6/ip6_fib.c:20:
> > > /kisskb/src/arch/powerpc/include/asm/mmu.h:139:22: error: unknown type name 'next_tlbcam_idx'
> > > 139 | DECLARE_PER_CPU(int, next_tlbcam_idx);
> > >
> > > I assume this is caused by commit
> > >
> > > 1c9df907da83 ("random: fix circular include dependency on arm64 after addition of percpu.h")
> > >
> > > But I can't see how, sorry.
> >
> > So there, asm/mmu.h includes asm/percpu.h, which includes asm/paca.h, which
> > includes asm/mmu.h.
> >
> > I suspect that we can remove asm/paca.h from asm/percpu.h as it *seems*
> > to be only used by the #define __my_cpu_offset but I don't know if anything
> > will break further, especially if this __my_cpu_offset is used anywhere
> > without this paca definition.
>
> I tried this and it fixed 5.8 for me with your config above. I'm appending
> a patch that does just this. I didn't test other configs as I don't know
> which ones to test though. If it fixes the problem for you, maybe it can
> be picked by the PPC maintainers.
Our mails have crossed. I just sent a more comprehensive patch. I
think your patch would require a lot of build testing and even then may
fail for some CONFIG combination that we didn't test or added in the
future (or someone just made up).
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Fix P10 PVR revision in /proc/cpuinfo for SMT4 cores
From: Michael Neuling @ 2020-08-03 3:56 UTC (permalink / raw)
To: mpe; +Cc: grimm, linuxppc-dev, Michael Neuling
On POWER10 bit 12 in the PVR indicates if the core is SMT4 or
SMT8. Bit 12 is set for SMT4.
Without this patch, /proc/cpuinfo on a SMT4 DD1 POWER10 looks like
this:
cpu : POWER10, altivec supported
revision : 17.0 (pvr 0080 1100)
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/setup-common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index b198b0ff25..808ec9fab6 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -311,6 +311,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
min = pvr & 0xFF;
break;
case 0x004e: /* POWER9 bits 12-15 give chip type */
+ case 0x0080: /* POWER10 bit 12 gives SMT8/4 */
maj = (pvr >> 8) & 0x0F;
min = pvr & 0xFF;
break;
--
2.26.2
^ permalink raw reply related
* [PATCH] powerpc: fix up PPC_FSL_BOOK3E build
From: Stephen Rothwell @ 2020-08-03 3:54 UTC (permalink / raw)
To: Michael Ellerman
Cc: Linus Torvalds, Linux PowerPC List, Willy Tarreau,
Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 3550 bytes --]
Commit
1c9df907da83 ("random: fix circular include dependency on arm64 after addition of percpu.h")
exposed a curcular include dependency:
asm/mmu.h includes asm/percpu.h, which includes asm/paca.h, which
includes asm/mmu.h
So fix it by extracting the small part of asm/mmu.h that needs
asm/percu.h into a new file and including that where necessary.
Cc: Willy Tarreau <w@1wt.eu>
Cc: <stable@kernel.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
I have done powerpc test builds of allmodconfig, ppc64e_defconfig and
corenet64_smp_defconfig.
arch/powerpc/include/asm/mmu.h | 5 -----
arch/powerpc/include/asm/mmu_fsl_e.h | 10 ++++++++++
arch/powerpc/kernel/smp.c | 1 +
arch/powerpc/mm/mem.c | 1 +
arch/powerpc/mm/nohash/book3e_hugetlbpage.c | 1 +
arch/powerpc/mm/nohash/tlb.c | 1 +
6 files changed, 14 insertions(+), 5 deletions(-)
create mode 100644 arch/powerpc/include/asm/mmu_fsl_e.h
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index f4ac25d4df05..fa602a4cf303 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -134,11 +134,6 @@
typedef pte_t *pgtable_t;
-#ifdef CONFIG_PPC_FSL_BOOK3E
-#include <asm/percpu.h>
-DECLARE_PER_CPU(int, next_tlbcam_idx);
-#endif
-
enum {
MMU_FTRS_POSSIBLE =
#ifdef CONFIG_PPC_BOOK3S
diff --git a/arch/powerpc/include/asm/mmu_fsl_e.h b/arch/powerpc/include/asm/mmu_fsl_e.h
new file mode 100644
index 000000000000..c74a81556ce5
--- /dev/null
+++ b/arch/powerpc/include/asm/mmu_fsl_e.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_POWERPC_MMU_FSL_E_H_
+#define _ASM_POWERPC_MMU_FSL_E_H_
+
+#ifdef CONFIG_PPC_FSL_BOOK3E
+#include <asm/percpu.h>
+DECLARE_PER_CPU(int, next_tlbcam_idx);
+#endif
+
+#endif
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 73199470c265..142b3e7882bf 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -35,6 +35,7 @@
#include <linux/stackprotector.h>
#include <linux/pgtable.h>
+#include <asm/mmu_fsl_e.h>
#include <asm/ptrace.h>
#include <linux/atomic.h>
#include <asm/irq.h>
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index c2c11eb8dcfc..7371061b2126 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -37,6 +37,7 @@
#include <asm/pgalloc.h>
#include <asm/prom.h>
#include <asm/io.h>
+#include <asm/mmu_fsl_e.h>
#include <asm/mmu_context.h>
#include <asm/mmu.h>
#include <asm/smp.h>
diff --git a/arch/powerpc/mm/nohash/book3e_hugetlbpage.c b/arch/powerpc/mm/nohash/book3e_hugetlbpage.c
index 8b88be91b622..cacda4ee5da5 100644
--- a/arch/powerpc/mm/nohash/book3e_hugetlbpage.c
+++ b/arch/powerpc/mm/nohash/book3e_hugetlbpage.c
@@ -9,6 +9,7 @@
#include <linux/mm.h>
#include <linux/hugetlb.h>
+#include <asm/mmu_fsl_e.h>
#include <asm/mmu.h>
#ifdef CONFIG_PPC64
diff --git a/arch/powerpc/mm/nohash/tlb.c b/arch/powerpc/mm/nohash/tlb.c
index 696f568253a0..8b3a68ce7fde 100644
--- a/arch/powerpc/mm/nohash/tlb.c
+++ b/arch/powerpc/mm/nohash/tlb.c
@@ -171,6 +171,7 @@ int extlb_level_exc;
#endif /* CONFIG_PPC64 */
#ifdef CONFIG_PPC_FSL_BOOK3E
+#include <asm/mmu_fsl_e.h>
/* next_tlbcam_idx is used to round-robin tlbcam entry assignment */
DEFINE_PER_CPU(int, next_tlbcam_idx);
EXPORT_PER_CPU_SYMBOL(next_tlbcam_idx);
--
2.28.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* Re: powerpc: build failures in Linus' tree
From: Willy Tarreau @ 2020-08-03 3:45 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux-kernel Mailing List, Linus Torvalds, Paul Mackerras,
PowerPC
In-Reply-To: <20200802172019.GB26677@1wt.eu>
[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]
Hi again Stephen,
On Sun, Aug 02, 2020 at 07:20:19PM +0200, Willy Tarreau wrote:
> On Sun, Aug 02, 2020 at 08:48:42PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > We are getting build failures in some PowerPC configs for Linus' tree.
> > See e.g. http://kisskb.ellerman.id.au/kisskb/buildresult/14306515/
> >
> > In file included from /kisskb/src/arch/powerpc/include/asm/paca.h:18,
> > from /kisskb/src/arch/powerpc/include/asm/percpu.h:13,
> > from /kisskb/src/include/linux/random.h:14,
> > from /kisskb/src/include/linux/net.h:18,
> > from /kisskb/src/net/ipv6/ip6_fib.c:20:
> > /kisskb/src/arch/powerpc/include/asm/mmu.h:139:22: error: unknown type name 'next_tlbcam_idx'
> > 139 | DECLARE_PER_CPU(int, next_tlbcam_idx);
> >
> > I assume this is caused by commit
> >
> > 1c9df907da83 ("random: fix circular include dependency on arm64 after addition of percpu.h")
> >
> > But I can't see how, sorry.
>
> So there, asm/mmu.h includes asm/percpu.h, which includes asm/paca.h, which
> includes asm/mmu.h.
>
> I suspect that we can remove asm/paca.h from asm/percpu.h as it *seems*
> to be only used by the #define __my_cpu_offset but I don't know if anything
> will break further, especially if this __my_cpu_offset is used anywhere
> without this paca definition.
I tried this and it fixed 5.8 for me with your config above. I'm appending
a patch that does just this. I didn't test other configs as I don't know
which ones to test though. If it fixes the problem for you, maybe it can
be picked by the PPC maintainers.
Willy
[-- Attachment #2: 0001-powerpc-fix-circular-dependency-in-percpu.h.patch --]
[-- Type: text/plain, Size: 1623 bytes --]
From bcd64a7d0f3445c9a75d3b4dc4837d2ce61660c9 Mon Sep 17 00:00:00 2001
From: Willy Tarreau <w@1wt.eu>
Date: Mon, 3 Aug 2020 05:27:57 +0200
Subject: powerpc: fix circular dependency in percpu.h
After random.h started to include percpu.h (commit f227e3e), several
archs broke in circular dependencies around percpu.h.
In https://lore.kernel.org/lkml/20200802204842.36bca162@canb.auug.org.au/
Stephen Rothwell reported breakage for powerpc with CONFIG_PPC_FSL_BOOK3E.
It turns out that asm/percpu.h includes asm/paca.h, which itself
includes mmu.h, which includes percpu.h when CONFIG_PPC_FSL_BOOK3E=y.
Percpu seems to include asm/paca.h only for local_paca which is used in
the __my_cpu_offset macro. Removing this include solves the issue for
this config.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes: f227e3e ("random32: update the net random state on interrupt and activity")
Link: https://lore.kernel.org/lkml/20200802204842.36bca162@canb.auug.org.au/
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
arch/powerpc/include/asm/percpu.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/include/asm/percpu.h b/arch/powerpc/include/asm/percpu.h
index dce863a..cd3f6e5 100644
--- a/arch/powerpc/include/asm/percpu.h
+++ b/arch/powerpc/include/asm/percpu.h
@@ -10,8 +10,6 @@
#ifdef CONFIG_SMP
-#include <asm/paca.h>
-
#define __my_cpu_offset local_paca->data_offset
#endif /* CONFIG_SMP */
--
2.9.0
^ permalink raw reply related
* [powerpc:merge] BUILD SUCCESS f59195f7faa4896b7c1d947ac2dba29ec18ad569
From: kernel test robot @ 2020-08-03 3:23 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: f59195f7faa4896b7c1d947ac2dba29ec18ad569 Automatic merge of 'master', 'next' and 'fixes' (2020-08-02 23:18)
elapsed time: 801m
configs tested: 99
configs skipped: 10
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
powerpc chrp32_defconfig
arc nsimosci_hs_smp_defconfig
arm pxa910_defconfig
sh sh7757lcr_defconfig
arm aspeed_g4_defconfig
sh defconfig
mips decstation_defconfig
sh se7343_defconfig
mips gcw0_defconfig
arm pxa255-idp_defconfig
arm mini2440_defconfig
sh rts7751r2d1_defconfig
nios2 3c120_defconfig
c6x evmc6457_defconfig
h8300 defconfig
arm shmobile_defconfig
arm pleb_defconfig
powerpc mpc7448_hpc2_defconfig
arm zeus_defconfig
c6x dsk6455_defconfig
sh ap325rxa_defconfig
nios2 10m50_defconfig
powerpc64 defconfig
m68k bvme6000_defconfig
mips tb0226_defconfig
sh se7780_defconfig
arc vdk_hs38_smp_defconfig
arm milbeaut_m10v_defconfig
c6x evmc6472_defconfig
mips ath79_defconfig
mips cavium_octeon_defconfig
powerpc ppc64_defconfig
mips mips_paravirt_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20200802
i386 randconfig-a005-20200802
i386 randconfig-a001-20200802
i386 randconfig-a002-20200802
i386 randconfig-a003-20200802
i386 randconfig-a006-20200802
i386 randconfig-a011-20200802
i386 randconfig-a012-20200802
i386 randconfig-a015-20200802
i386 randconfig-a014-20200802
i386 randconfig-a013-20200802
i386 randconfig-a016-20200802
x86_64 randconfig-a006-20200802
x86_64 randconfig-a001-20200802
x86_64 randconfig-a004-20200802
x86_64 randconfig-a003-20200802
x86_64 randconfig-a002-20200802
x86_64 randconfig-a005-20200802
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS af0870c4e75655b1931d0a5ffde2f448a2794362
From: kernel test robot @ 2020-08-03 3:24 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: af0870c4e75655b1931d0a5ffde2f448a2794362 powerpc/papr_scm: Add support for fetching nvdimm 'fuel-gauge' metric
elapsed time: 800m
configs tested: 96
configs skipped: 12
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
mips jazz_defconfig
mips ar7_defconfig
c6x dsk6455_defconfig
m68k amcore_defconfig
ia64 gensparse_defconfig
mips gcw0_defconfig
arm pxa255-idp_defconfig
arm mini2440_defconfig
powerpc adder875_defconfig
powerpc g5_defconfig
sh rts7751r2dplus_defconfig
s390 defconfig
arm jornada720_defconfig
sh rts7751r2d1_defconfig
nios2 3c120_defconfig
c6x evmc6457_defconfig
h8300 defconfig
arm zeus_defconfig
m68k defconfig
arm bcm2835_defconfig
powerpc pseries_defconfig
arm cerfcube_defconfig
arm multi_v7_defconfig
nds32 alldefconfig
arc haps_hs_defconfig
arm exynos_defconfig
mips pistachio_defconfig
powerpc amigaone_defconfig
arm nhk8815_defconfig
mips cavium_octeon_defconfig
powerpc ppc64_defconfig
mips mips_paravirt_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20200802
i386 randconfig-a005-20200802
i386 randconfig-a006-20200802
i386 randconfig-a001-20200802
i386 randconfig-a002-20200802
i386 randconfig-a003-20200802
x86_64 randconfig-a006-20200802
x86_64 randconfig-a001-20200802
x86_64 randconfig-a004-20200802
x86_64 randconfig-a003-20200802
x86_64 randconfig-a002-20200802
x86_64 randconfig-a005-20200802
i386 randconfig-a011-20200802
i386 randconfig-a012-20200802
i386 randconfig-a015-20200802
i386 randconfig-a014-20200802
i386 randconfig-a013-20200802
i386 randconfig-a016-20200802
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 kexec
x86_64 rhel-8.3
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ 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