* Re: [PATCH] powerpc/32s: Slenderize _tlbia() for powerpc 603/603e
From: Michael Ellerman @ 2020-03-06 0:27 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <12f4f4f0ff89aeab3b937fc96c84fb35e1b2517e.1580748445.git.christophe.leroy@c-s.fr>
On Mon, 2020-02-03 at 16:47:37 UTC, Christophe Leroy wrote:
> _tlbia() is a function used only on 603/603e core, ie on CPUs which
> don't have a hash table.
>
> _tlbia() uses the tlbia macro which implements a loop of 1024 tlbie.
>
> On the 603/603e core, flushing the entire TLB requires no more than
> 32 tlbie.
>
> Replace tlbia by a loop of 32 tlbie.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e1347a020b81fe47c80cd277bfaa61295a9482a4
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/83xx: Fix some typo in some warning message
From: Michael Ellerman @ 2020-03-06 0:27 UTC (permalink / raw)
To: Christophe JAILLET, oss, galak, benh, paulus
Cc: Christophe JAILLET, kernel-janitors, linuxppc-dev, linux-kernel
In-Reply-To: <20200208140904.7521-1-christophe.jaillet@wanadoo.fr>
On Sat, 2020-02-08 at 14:09:04 UTC, Christophe JAILLET wrote:
> "couldn;t" should be "couldn't".
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/365ad0b60d944050d61252e123e6a8b2c3950398
cheers
^ permalink raw reply
* Re: [PATCH 1/6] powerpc: kernel: no need to check return value of debugfs_create functions
From: Michael Ellerman @ 2020-03-06 0:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, linuxppc-dev
Cc: Greg Kroah-Hartman, Paul Mackerras, linux-kernel, Hari Bathini
In-Reply-To: <20200209105901.1620958-1-gregkh@linuxfoundation.org>
On Sun, 2020-02-09 at 10:58:56 UTC, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Hari Bathini <hbathini@linux.ibm.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/860286cf33963fa8a0fe542995bdec2df5cb3abb
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/powernv: Treat an empty reboot string as default
From: Michael Ellerman @ 2020-03-06 0:27 UTC (permalink / raw)
To: Oliver O'Halloran, linuxppc-dev; +Cc: Oliver O'Halloran
In-Reply-To: <20200217024833.30580-1-oohall@gmail.com>
On Mon, 2020-02-17 at 02:48:32 UTC, Oliver O'Halloran wrote:
> Treat an empty reboot cmd string the same as a NULL string. This squashes a
> spurious unsupported reboot message that sometimes gets out when using
> xmon.
>
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/16985f2d25095899685952296f128a71f0aff05c
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/kernel/sysfs: Refactor current sysfs.c
From: Michael Ellerman @ 2020-03-06 0:27 UTC (permalink / raw)
To: Kajol Jain, linuxppc-dev
Cc: nasastry, kjain, Madhavan Srinivasan, maddy, anju
In-Reply-To: <20200214080606.26872-1-kjain@linux.ibm.com>
On Fri, 2020-02-14 at 08:06:05 UTC, Kajol Jain wrote:
> From: Madhavan Srinivasan <maddy@linux.ibm.com>
>
> An attempt to refactor the current sysfs.c file.
> To start with a big chuck of macro #defines and dscr
> functions are moved to start of the file. Secondly,
> HAS_ #define macros are cleanup based on CONFIG_ options
>
> Finally new HAS_ macro added:
> 1. HAS_PPC_PA6T (for PA6T) to separate out non-PMU SPRs.
> 2. HAS_PPC_PMC56 to separate out PMC SPR's from HAS_PPC_PMC_CLASSIC
> which come under CONFIG_PPC64.
>
> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/fcdb524d440d6326c286006e16f252b40ba4fd6a
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Don't kmap_atomic() in pte_offset_map() on PPC32
From: Michael Ellerman @ 2020-03-06 0:27 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <03c97f0f6b3790d164822563be80f2fd4713a955.1581932480.git.christophe.leroy@c-s.fr>
On Mon, 2020-02-17 at 09:41:35 UTC, Christophe Leroy wrote:
> On PPC32, pte_offset_map() does a kmap_atomic() in order to support
> page tables allocated in high memory, just like ARM and x86/32.
>
> But since at least 2008 and commit 8054a3428fbe ("powerpc: Remove dead
> CONFIG_HIGHPTE"), page tables are never allocated in high memory.
>
> When the page is in low mem, kmap_atomic() just returns the page
> address but still disable preemption and pagefault. And it is
> not an inlined function, so we suffer function call for no reason.
>
> Make pte_offset_map() the same as pte_offset_kernel() and make
> pte_unmap() void, in the same way as PPC64 which doesn't have HIGHMEM.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6453f9ed9d4e4b4cdf201bf34bf460c436bf50ea
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/Makefile: Mark phony targets as PHONY
From: Michael Ellerman @ 2020-03-06 0:27 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: masahiroy, linux-kbuild
In-Reply-To: <20200219000434.15872-1-mpe@ellerman.id.au>
On Wed, 2020-02-19 at 00:04:34 UTC, Michael Ellerman wrote:
> Some of our phony targets are not marked as such. This can lead to
> confusing errors, eg:
>
> $ make clean
> $ touch install
> $ make install
> make: 'install' is up to date.
> $
>
> Fix it by adding them to the PHONY variable which is marked phony in
> the top-level Makefile, or in scripts/Makefile.build for the boot
> Makefile.
>
> Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/d42c6d0f8d004c3661dde3c376ed637e9f292c22
cheers
^ permalink raw reply
* Re: [PATCH v3 1/5] powerpc: Rename current_stack_pointer() to current_stack_frame()
From: Michael Ellerman @ 2020-03-06 0:27 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20200220115141.2707-1-mpe@ellerman.id.au>
On Thu, 2020-02-20 at 11:51:37 UTC, Michael Ellerman wrote:
> current_stack_pointer(), which was called __get_SP(), used to just
> return the value in r1.
>
> But that caused problems in some cases, so it was turned into a
> function in commit bfe9a2cfe91a ("powerpc: Reimplement __get_SP() as a
> function not a define").
>
> Because it's a function in a separate compilation unit to all its
> callers, it has the effect of causing a stack frame to be created, and
> then returns the address of that frame. This is good in some cases
> like those described in the above commit, but in other cases it's
> overkill, we just need to know what stack page we're on.
>
> On some other arches current_stack_pointer is just a register global
> giving the stack pointer, and we'd like to do that too. So rename our
> current_stack_pointer() to current_stack_frame() to make that
> possible.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Series applied to powerpc next.
https://git.kernel.org/powerpc/c/3d13e839e801e081bdece0127c2affa33d0f77cf
cheers
^ permalink raw reply
* [PATCH] KVM: PPC: Book3S HV: Fix typos in comments
From: Gustavo Romero @ 2020-03-06 0:26 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, Gustavo Romero
Fix typos found in comments about the parameter passed
through r5 to kvmppc_{save,restore}_tm_hv functions.
Signed-off-by: Gustavo Romero <gromero@linux.ibm.com>
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index dbc2fec..a55dbe8 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -3121,7 +3121,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
* Save transactional state and TM-related registers.
* Called with r3 pointing to the vcpu struct and r4 containing
* the guest MSR value.
- * r5 is non-zero iff non-volatile register state needs to be maintained.
+ * r5 is non-zero if non-volatile register state needs to be maintained.
* If r5 == 0, this can modify all checkpointed registers, but
* restores r1 and r2 before exit.
*/
@@ -3194,7 +3194,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_P9_TM_XER_SO_BUG)
* Restore transactional state and TM-related registers.
* Called with r3 pointing to the vcpu struct
* and r4 containing the guest MSR value.
- * r5 is non-zero iff non-volatile register state needs to be maintained.
+ * r5 is non-zero if non-volatile register state needs to be maintained.
* This potentially modifies all checkpointed registers.
* It restores r1 and r2 from the PACA.
*/
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] crypto: Replace zero-length array with flexible-array member
From: Herbert Xu @ 2020-03-06 1:48 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Aymen Sghaier, Horia Geantă, Nayna Jain, linux-mediatek,
linux-kernel, Atul Gupta, Breno Leitão,
Paulo Flabiano Smorigo, linux-crypto, Matthias Brugger,
Paul Mackerras, linuxppc-dev, David S. Miller, linux-arm-kernel
In-Reply-To: <20200224162100.GA25697@embeddedor>
On Mon, Feb 24, 2020 at 10:21:00AM -0600, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertently introduced[3] to the codebase from now on.
>
> Also, notice that, dynamic memory allocations won't be affected by
> this change:
>
> "Flexible array members have incomplete type, and so the sizeof operator
> may not be applied. As a quirk of the original implementation of
> zero-length arrays, sizeof evaluates to zero."[1]
>
> This issue was found with the help of Coccinelle.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> drivers/crypto/caam/caamalg.c | 2 +-
> drivers/crypto/caam/caamalg_qi.c | 4 ++--
> drivers/crypto/caam/caamalg_qi2.h | 6 +++---
> drivers/crypto/caam/caamhash.c | 2 +-
> drivers/crypto/cavium/nitrox/nitrox_main.c | 2 +-
> drivers/crypto/chelsio/chcr_core.h | 2 +-
> drivers/crypto/mediatek/mtk-sha.c | 2 +-
> drivers/crypto/nx/nx.h | 2 +-
> drivers/crypto/omap-sham.c | 4 ++--
> include/crypto/if_alg.h | 2 +-
> 10 files changed, 14 insertions(+), 14 deletions(-)
Patch applied. 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] KVM: PPC: Book3S HV: Fix typos in comments
From: Gustavo Romero @ 2020-03-06 2:09 UTC (permalink / raw)
To: Gabriel Paubert, Gustavo Romero; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <20200306020607.GA29843@lt-gp.iram.es>
Hi Gabriel,
On 03/06/2020 01:06 PM, Gabriel Paubert wrote:
> On Fri, Mar 06, 2020 at 11:26:36AM +1100, Gustavo Romero wrote:
>> Fix typos found in comments about the parameter passed
>> through r5 to kvmppc_{save,restore}_tm_hv functions.
>
> Actually "iff" is a common shorthand in some fields and not necessarily
> a spelling error:
>
> https://en.wikipedia.org/wiki/If_and_only_if
I see. Thank you.
Best regards,
Gustavo
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Fix typos in comments
From: Gabriel Paubert @ 2020-03-06 2:06 UTC (permalink / raw)
To: Gustavo Romero; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <1583454396-1424-1-git-send-email-gromero@linux.ibm.com>
On Fri, Mar 06, 2020 at 11:26:36AM +1100, Gustavo Romero wrote:
> Fix typos found in comments about the parameter passed
> through r5 to kvmppc_{save,restore}_tm_hv functions.
Actually "iff" is a common shorthand in some fields and not necessarily
a spelling error:
https://en.wikipedia.org/wiki/If_and_only_if
Gabriel
>
> Signed-off-by: Gustavo Romero <gromero@linux.ibm.com>
> ---
> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index dbc2fec..a55dbe8 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -3121,7 +3121,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
> * Save transactional state and TM-related registers.
> * Called with r3 pointing to the vcpu struct and r4 containing
> * the guest MSR value.
> - * r5 is non-zero iff non-volatile register state needs to be maintained.
> + * r5 is non-zero if non-volatile register state needs to be maintained.
> * If r5 == 0, this can modify all checkpointed registers, but
> * restores r1 and r2 before exit.
> */
> @@ -3194,7 +3194,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_P9_TM_XER_SO_BUG)
> * Restore transactional state and TM-related registers.
> * Called with r3 pointing to the vcpu struct
> * and r4 containing the guest MSR value.
> - * r5 is non-zero iff non-volatile register state needs to be maintained.
> + * r5 is non-zero if non-volatile register state needs to be maintained.
> * This potentially modifies all checkpointed registers.
> * It restores r1 and r2 from the PACA.
> */
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH] Add OPAL_GET_SYMBOL / OPAL_LOOKUP_SYMBOL
From: Oliver O'Halloran @ 2020-03-06 2:42 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: skiboot list, linuxppc-dev
In-Reply-To: <20200228030751.271382-1-npiggin@gmail.com>
On Fri, Feb 28, 2020 at 2:09 PM Nicholas Piggin <npiggin@gmail.com> wrote:
>
> These calls can be used by Linux to annotate BUG addresses with symbols,
> look up symbol addresses in xmon, etc.
>
> This is preferable over having Linux parse the OPAL symbol map itself,
> because OPAL's parsing code already exists for its own symbol printing,
> and it can support other code regions than the skiboot symbols, e.g.,
> the wake-up code in the HOMER (where CPUs have been seen to get stuck).
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> core/opal.c | 2 +
> core/utils.c | 92 +++++++++++++++++++++++--
> doc/opal-api/opal-get-symbol-181.rst | 42 +++++++++++
> doc/opal-api/opal-lookup-symbol-182.rst | 35 ++++++++++
> include/opal-api.h | 4 +-
> 5 files changed, 168 insertions(+), 7 deletions(-)
> create mode 100644 doc/opal-api/opal-get-symbol-181.rst
> create mode 100644 doc/opal-api/opal-lookup-symbol-182.rst
>
> diff --git a/core/opal.c b/core/opal.c
> index d6ff6027b..d9fc4fe05 100644
> --- a/core/opal.c
> +++ b/core/opal.c
> @@ -142,6 +142,8 @@ int64_t opal_entry_check(struct stack_frame *eframe)
> case OPAL_CEC_REBOOT:
> case OPAL_CEC_REBOOT2:
> case OPAL_SIGNAL_SYSTEM_RESET:
> + case OPAL_GET_SYMBOL:
> + case OPAL_LOOKUP_SYMBOL:
These names are still awful :|
> break;
> default:
> printf("CPU ATTEMPT TO RE-ENTER FIRMWARE! PIR=%04lx cpu @%p -> pir=%04x token=%llu\n",
> diff --git a/core/utils.c b/core/utils.c
> index 8fd63fcb7..5f0d5130b 100644
> --- a/core/utils.c
> +++ b/core/utils.c
> @@ -48,40 +48,120 @@ char __attrconst tohex(uint8_t nibble)
> return __tohex[nibble];
> }
>
> -static unsigned long get_symbol(unsigned long addr, char **sym, char **sym_end)
> +static unsigned long get_symbol(unsigned long addr, char **sym, char **sym_end, unsigned long *size)
> {
> unsigned long prev = 0, next;
> char *psym = NULL, *p = __sym_map_start;
>
> *sym = *sym_end = NULL;
> - while(p < __sym_map_end) {
> + while (p < __sym_map_end) {
> next = strtoul(p, &p, 16) | SKIBOOT_BASE;
> if (next > addr && prev <= addr) {
> - p = psym + 3;;
> + p = psym + 3;
> if (p >= __sym_map_end)
> return 0;
> *sym = p;
> - while(p < __sym_map_end && *p != 10)
> + while (p < __sym_map_end && *p != '\n')
> p++;
> *sym_end = p;
> + *size = next - prev;
> return prev;
> }
> prev = next;
> psym = p;
> - while(p < __sym_map_end && *p != 10)
> + while (p < __sym_map_end && *p != '\n')
> p++;
> p++;
> }
> return 0;
> }
>
> +static unsigned long lookup_symbol(const char *name, unsigned long *size)
> +{
> + size_t len = strlen(name);
> + unsigned long addr = 0;
> + char *sym;
> + char *p = __sym_map_start;
> +
> + while (p < __sym_map_end) {
> + addr = strtoul(p, &p, 16) | SKIBOOT_BASE;
> + p += 3;
> + if (p >= __sym_map_end)
> + return 0;
> +
> + if (*(p + len) == '\n' && !strncmp(name, p, len)) {
> + char *sym_end;
> +
> + if (get_symbol(addr, &sym, &sym_end, size) == 0) {
> + assert(!strcmp(name, "_end"));
> + *size = 0;
> + }
> +
> + /*
> + * May be more than one symbol at this address but
> + * symbol length calculation should still work in
> + * that case.
> + */
> +
> + return addr;
> + }
> +
> + while(p < __sym_map_end && *p != '\n')
> + p++;
> + p++;
> + }
> + return 0;
> +}
> +
> +static int64_t opal_get_symbol(uint64_t addr, __be64 *symaddr, __be64 *symsize, char *namebuf, uint64_t buflen)
> +{
> + unsigned long saddr;
> + unsigned long ssize;
> + char *sym, *sym_end;
> + size_t l;
> +
> + saddr = get_symbol(addr, &sym, &sym_end, &ssize);
> + if (!saddr)
> + return OPAL_RESOURCE;
> +
> + if (buflen > sym_end - sym)
> + l = sym_end - sym;
> + else
> + l = buflen - 1;
> + memcpy(namebuf, sym, l);
> + namebuf[l] = '\0';
> +
> + *symaddr = cpu_to_be64(saddr);
> + *symsize = cpu_to_be64(ssize);
> +
> + return OPAL_SUCCESS;
> +}
> +opal_call(OPAL_GET_SYMBOL, opal_get_symbol, 5);
> +
> +static int64_t opal_lookup_symbol(const char *name, __be64 *symaddr, __be64 *symsize)
> +{
> + unsigned long saddr;
> + unsigned long ssize;
> +
> + saddr = lookup_symbol(name, &ssize);
> + if (!saddr)
> + return OPAL_RESOURCE;
> +
> + *symaddr = cpu_to_be64(saddr);
> + *symsize = cpu_to_be64(ssize);
> +
> + return OPAL_SUCCESS;
> +}
> +opal_call(OPAL_LOOKUP_SYMBOL, opal_lookup_symbol, 3);
> +
> size_t snprintf_symbol(char *buf, size_t len, uint64_t addr)
> {
> unsigned long saddr;
> + unsigned long ssize;
> char *sym, *sym_end;
> size_t l;
>
> - saddr = get_symbol(addr, &sym, &sym_end);
> + saddr = get_symbol(addr, &sym, &sym_end, &ssize);
> if (!saddr)
> return 0;
>
> diff --git a/doc/opal-api/opal-get-symbol-181.rst b/doc/opal-api/opal-get-symbol-181.rst
> new file mode 100644
> index 000000000..a57de6c1c
> --- /dev/null
> +++ b/doc/opal-api/opal-get-symbol-181.rst
> @@ -0,0 +1,42 @@
> +.. _OPAL_GET_SYMBOL:
> +
> +OPAL_GET_SYMBOL
> +================
> +
> +.. code-block:: c
> +
> + #define OPAL_GET_SYMBOL 181
> +
> + static int64_t opal_get_symbol(uint64_t addr, __be64 *symaddr, __be64 *symsize, char *namebuf, uint64_t buflen);
> +
> +This OPAL call looks up a firmware code address for symbol information.
> +
> +Arguments
> +---------
> +
> + ``addr``
> + Contains address to be looked up.
> +
> + ``symaddr``
> + Returns the start address of the symbol for the object which
> + contains addr or immediately precedes addr.
> +
> + ``symsize``
> + Returns the size of the object, or the number of bytes until the
> + next symbol.
> +
> + ``namebuf``
> + Contains a buffer for the symbol name to be copied into, as a NUL
> + terminated string.
> +
> + ``buflen``
> + Contains the length of the bufer that may be used.
> +
> +
> +Returns
> +-------
> +
> +:ref:`OPAL_SUCCESS`
> + Found a symbol.
> +:ref:`OPAL_RESOURCE`
> + Did not find a symbol.
> diff --git a/doc/opal-api/opal-lookup-symbol-182.rst b/doc/opal-api/opal-lookup-symbol-182.rst
> new file mode 100644
> index 000000000..e9f6eba33
> --- /dev/null
> +++ b/doc/opal-api/opal-lookup-symbol-182.rst
> @@ -0,0 +1,35 @@
> +.. _OPAL_LOOKUP_SYMBOL:
> +
> +OPAL_LOOKUP_SYMBOL
> +================
> +
> +.. code-block:: c
> +
> + #define OPAL_LOOKUP_SYMBOL 182
> +
> + static int64_t opal_lookup_symbol(const char *name, __be64 *symaddr, __be64 *symsize);
> +
> +This OPAL call looks up a firmware symbol name for its address.
> +
> +Arguments
> +---------
> +
> + ``name``
> + Contains a pointer to NUL terminated symbol name to be looked up.
> +
> + ``symaddr``
> + Returns the start address of the symbol for the object which
> + contains addr or immediately precedes addr.
> +
> + ``symsize``
> + Returns the size of the object, or the number of bytes until the
> + next symbol.
> +
> +
> +Returns
> +-------
> +
> +:ref:`OPAL_SUCCESS`
> + Found a symbol.
> +:ref:`OPAL_RESOURCE`
> + Did not find a symbol.
> diff --git a/include/opal-api.h b/include/opal-api.h
> index 5b07dea13..4474631a6 100644
> --- a/include/opal-api.h
> +++ b/include/opal-api.h
> @@ -227,7 +227,9 @@
> #define OPAL_SECVAR_ENQUEUE_UPDATE 178
> #define OPAL_PHB_SET_OPTION 179
> #define OPAL_PHB_GET_OPTION 180
> -#define OPAL_LAST 180
> +#define OPAL_GET_SYMBOL 181
> +#define OPAL_LOOKUP_SYMBOL 182
> +#define OPAL_LAST 182
>
> #define QUIESCE_HOLD 1 /* Spin all calls at entry */
> #define QUIESCE_REJECT 2 /* Fail all calls with OPAL_BUSY */
> --
> 2.23.0
>
^ permalink raw reply
* [PATCH] powerpc/vdso: Fix multiple issues with sys_call_table
From: Anton Blanchard @ 2020-03-06 2:57 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: Nicholas Piggin
The VDSO exports a bitmap of valid syscalls. vdso_setup_syscall_map()
sets this up, but there are both little and big endian bugs. The issue
is with:
if (sys_call_table[i] != sys_ni_syscall)
On little endian, instead of comparing pointers to the two functions,
we compare the first two instructions of each function. If a function
happens to have the same first two instructions as sys_ni_syscall, then
we have a spurious match and mark the instruction as not implemented.
Fix this by removing the inline declarations.
On big endian we have a further issue where sys_ni_syscall is a function
descriptor and sys_call_table[] holds pointers to the instruction text.
Fix this by using dereference_kernel_function_descriptor().
Cc: stable@vger.kernel.org
Signed-off-by: Anton Blanchard <anton@ozlabs.org>
---
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index b9a108411c0d..d186b729026e 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -17,6 +17,7 @@
#include <linux/elf.h>
#include <linux/security.h>
#include <linux/memblock.h>
+#include <linux/syscalls.h>
#include <asm/pgtable.h>
#include <asm/processor.h>
@@ -30,6 +31,7 @@
#include <asm/vdso.h>
#include <asm/vdso_datapage.h>
#include <asm/setup.h>
+#include <asm/syscall.h>
#undef DEBUG
@@ -644,19 +646,16 @@ static __init int vdso_setup(void)
static void __init vdso_setup_syscall_map(void)
{
unsigned int i;
- extern unsigned long *sys_call_table;
-#ifdef CONFIG_PPC64
- extern unsigned long *compat_sys_call_table;
-#endif
- extern unsigned long sys_ni_syscall;
+ unsigned long ni_syscall;
+ ni_syscall = (unsigned long)dereference_kernel_function_descriptor(sys_ni_syscall);
for (i = 0; i < NR_syscalls; i++) {
#ifdef CONFIG_PPC64
- if (sys_call_table[i] != sys_ni_syscall)
+ if (sys_call_table[i] != ni_syscall)
vdso_data->syscall_map_64[i >> 5] |=
0x80000000UL >> (i & 0x1f);
- if (compat_sys_call_table[i] != sys_ni_syscall)
+ if (compat_sys_call_table[i] != ni_syscall)
vdso_data->syscall_map_32[i >> 5] |=
0x80000000UL >> (i & 0x1f);
#else /* CONFIG_PPC64 */
^ permalink raw reply related
* Re: [PATCH v3 18/27] powerpc/powernv/pmem: Add controller dump IOCTLs
From: Alastair D'Silva @ 2020-03-06 3:34 UTC (permalink / raw)
To: Andrew Donnellan
Cc: Madhavan Srinivasan, Alexey Kardashevskiy, Masahiro Yamada,
Oliver O'Halloran, Mauro Carvalho Chehab, Ira Weiny,
Thomas Gleixner, Rob Herring, Dave Jiang, linux-nvdimm,
Aneesh Kumar K . V, Krzysztof Kozlowski, Anju T Sudhakar,
Mahesh Salgaonkar, Arnd Bergmann, Greg Kurz, Nicholas Piggin,
Cédric Le Goater, Dan Williams, Hari Bathini, linux-mm,
Greg Kroah-Hartman, linux-kernel, Vishal Verma, Frederic Barrat,
Paul Mackerras, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <7fc5ee46-d849-11f1-d0ad-429a8c87d7eb@linux.ibm.com>
On Wed, 2020-03-04 at 17:53 +1100, Andrew Donnellan wrote:
> On 21/2/20 2:27 pm, Alastair D'Silva wrote:
> > +static int ioctl_controller_dump_data(struct ocxlpmem *ocxlpmem,
> > + struct ioctl_ocxl_pmem_controller_dump_data __user
> > *uarg)
> > +{
> > + struct ioctl_ocxl_pmem_controller_dump_data args;
> > + u16 i;
> > + u64 val;
> > + int rc;
> > +
> > + if (copy_from_user(&args, uarg, sizeof(args)))
> > + return -EFAULT;
> > +
> > + if (args.buf_size % 8)
> > + return -EINVAL;
> > +
> > + if (args.buf_size > ocxlpmem->admin_command.data_size)
> > + return -EINVAL;
> > +
> > + mutex_lock(&ocxlpmem->admin_command.lock);
> > +
> > + rc = admin_command_request(ocxlpmem,
> > ADMIN_COMMAND_CONTROLLER_DUMP);
> > + if (rc)
> > + goto out;
> > +
> > + val = ((u64)args.offset) << 32;
> > + val |= args.buf_size;
> > + rc = ocxl_global_mmio_write64(ocxlpmem->ocxl_afu,
> > + ocxlpmem-
> > >admin_command.request_offset + 0x08,
> > + OCXL_LITTLE_ENDIAN, val);
> > + if (rc)
> > + goto out;
> > +
> > + rc = admin_command_execute(ocxlpmem);
> > + if (rc)
> > + goto out;
> > +
> > + rc = admin_command_complete_timeout(ocxlpmem,
> > + ADMIN_COMMAND_CONTROLLER_DU
> > MP);
> > + if (rc < 0) {
> > + dev_warn(&ocxlpmem->dev, "Controller dump timed
> > out\n");
> > + goto out;
> > + }
> > +
> > + rc = admin_response(ocxlpmem);
> > + if (rc < 0)
> > + goto out;
> > + if (rc != STATUS_SUCCESS) {
> > + warn_status(ocxlpmem,
> > + "Unexpected status from retrieve error
> > log",
>
> Controller dump
>
Ok
> > + rc);
> > + goto out;
> > + }
> > +
> > + for (i = 0; i < args.buf_size; i += 8) {
> > + u64 val;
> > +
> > + rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu,
> > + ocxlpmem-
> > >admin_command.data_offset + i,
> > + OCXL_HOST_ENDIAN, &val);
>
> Is a controller dump something where we want to do endian swapping?
>
No, we just have raw binary data that we want to pass through.
OCXL_HOST_ENDIAN does no swapping.
> Any reason we're not doing the usual check of the data identifier,
> additional data length etc?
>
I'll add that
> > + if (rc)
> > + goto out;
> > +
> > + if (copy_to_user(&args.buf[i], &val, sizeof(u64))) {
> > + rc = -EFAULT;
> > + goto out;
> > + }
> > + }
> > +
> > + if (copy_to_user(uarg, &args, sizeof(args))) {
> > + rc = -EFAULT;
> > + goto out;
> > + }
> > +
> > + rc = admin_response_handled(ocxlpmem);
> > + if (rc)
> > + goto out;
> > +
> > +out:
> > + mutex_unlock(&ocxlpmem->admin_command.lock);
> > + return rc;
> > +}
> > +
> > +int request_controller_dump(struct ocxlpmem *ocxlpmem)
> > +{
> > + int rc;
> > + u64 busy = 1;
> > +
> > + rc = ocxl_global_mmio_set64(ocxlpmem->ocxl_afu,
> > GLOBAL_MMIO_CHIC,
> > + OCXL_LITTLE_ENDIAN,
> > + GLOBAL_MMIO_CHI_CDA);
>
> This return code is ignored
>
> > +
> > +
> > + rc = ocxl_global_mmio_set64(ocxlpmem->ocxl_afu,
> > GLOBAL_MMIO_HCI,
> > + OCXL_LITTLE_ENDIAN,
> > + GLOBAL_MMIO_HCI_CONTROLLER_DUMP);
> > + if (rc)
> > + return rc;
> > +
> > + while (busy) {
> > + rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu,
> > + GLOBAL_MMIO_HCI,
> > + OCXL_LITTLE_ENDIAN,
> > &busy);
> > + if (rc)
> > + return rc;
> > +
> > + busy &= GLOBAL_MMIO_HCI_CONTROLLER_DUMP;
> > + cond_resched();
> > + }
> > +
> > + return 0;
> > +}
>
>
--
Alastair D'Silva
Open Source Developer
Linux Technology Centre, IBM Australia
mob: 0423 762 819
^ permalink raw reply
* Re: [PATCH v2] powerpc/Makefile: Mark phony targets as PHONY
From: Masahiro Yamada @ 2020-03-06 4:06 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Linux Kbuild mailing list, linuxppc-dev
In-Reply-To: <48YT3Y2QBsz9sSs@ozlabs.org>
On Fri, Mar 6, 2020 at 9:27 AM Michael Ellerman
<patch-notifications@ellerman.id.au> wrote:
>
> On Wed, 2020-02-19 at 00:04:34 UTC, Michael Ellerman wrote:
> > Some of our phony targets are not marked as such. This can lead to
> > confusing errors, eg:
> >
> > $ make clean
> > $ touch install
> > $ make install
> > make: 'install' is up to date.
> > $
> >
> > Fix it by adding them to the PHONY variable which is marked phony in
> > the top-level Makefile, or in scripts/Makefile.build for the boot
> > Makefile.
> >
> > Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
> > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>
> Applied to powerpc next.
>
> https://git.kernel.org/powerpc/c/d42c6d0f8d004c3661dde3c376ed637e9f292c22
>
You do not have to double your Signed-off-by.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH] powerpc/64s/radix: Fix !SMP build
From: Anton Blanchard @ 2020-03-06 4:17 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <20200302010410.2957362-1-npiggin@gmail.com>
Thanks Nick,
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Tested-by: Anton Blanchard <anton@ozlabs.org>
> ---
> arch/powerpc/mm/book3s64/radix_pgtable.c | 1 +
> arch/powerpc/mm/book3s64/radix_tlb.c | 7 ++++++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c
> b/arch/powerpc/mm/book3s64/radix_pgtable.c index
> dd1bea45325c..2a9a0cd79490 100644 ---
> a/arch/powerpc/mm/book3s64/radix_pgtable.c +++
> b/arch/powerpc/mm/book3s64/radix_pgtable.c @@ -26,6 +26,7 @@
> #include <asm/firmware.h>
> #include <asm/powernv.h>
> #include <asm/sections.h>
> +#include <asm/smp.h>
> #include <asm/trace.h>
> #include <asm/uaccess.h>
> #include <asm/ultravisor.h>
> diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c
> b/arch/powerpc/mm/book3s64/radix_tlb.c index
> 03f43c924e00..758ade2c2b6e 100644 ---
> a/arch/powerpc/mm/book3s64/radix_tlb.c +++
> b/arch/powerpc/mm/book3s64/radix_tlb.c @@ -587,6 +587,11 @@ void
> radix__local_flush_all_mm(struct mm_struct *mm) preempt_enable();
> }
> EXPORT_SYMBOL(radix__local_flush_all_mm);
> +
> +static void __flush_all_mm(struct mm_struct *mm, bool fullmm)
> +{
> + radix__local_flush_all_mm(mm);
> +}
> #endif /* CONFIG_SMP */
>
> void radix__local_flush_tlb_page_psize(struct mm_struct *mm,
> unsigned long vmaddr, @@ -777,7 +782,7 @@ void
> radix__flush_tlb_page(struct vm_area_struct *vma, unsigned long
> vmaddr) EXPORT_SYMBOL(radix__flush_tlb_page);
> #else /* CONFIG_SMP */
> -#define radix__flush_all_mm radix__local_flush_all_mm
> +static inline void exit_flush_lazy_tlbs(struct mm_struct *mm) { }
> #endif /* CONFIG_SMP */
>
> static void do_tlbiel_kernel(void *info)
^ permalink raw reply
* Re: [PATCH v2] powerpc: setup_64: set up PACA earlier to avoid kcov problems
From: Daniel Axtens @ 2020-03-06 4:40 UTC (permalink / raw)
To: Andrew Donnellan, linuxppc-dev
In-Reply-To: <59e8a506-572a-f355-e0ca-9c75758a9b65@linux.ibm.com>
> There's some special handling for CPU_FTR_HVMODE in
> cpufeatures_setup_cpu() in kernel/dt_cpu_ftrs.c:
>
> /* Initialize the base environment -- clear FSCR/HFSCR. */
> hv_mode = !!(mfmsr() & MSR_HV);
> if (hv_mode) {
> /* CPU_FTR_HVMODE is used early in PACA setup */
> cur_cpu_spec->cpu_features |= CPU_FTR_HVMODE;
> mtspr(SPRN_HFSCR, 0);
> }
>
> With this patch, the comment about PACA setup I assume is no longer
> true. It looks like we still rely on hv_mode being set to deal with
> discrepancies between the device tree and the MSR.
This code confuses me. IIUC it sets the CPU feature if we're in HV mode,
which will catch the case where the HV bit is set in the MSR but for
some reason it's not listed in the DT. With my patch, we'll directly
test the MSR so we don't need the cpu feature set for that.
However, the CPU feature is tested elsewhere, so I think the correct
behaviour is to keep the code but drop the comment. Having said that
bootstrapping is hard so lmk if I've misunderstood.
Regards,
Daniel
>
> --
> Andrew Donnellan OzLabs, ADL Canberra
> ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH v2] powerpc: setup_64: set up PACA earlier to avoid kcov problems
From: Andrew Donnellan @ 2020-03-06 4:45 UTC (permalink / raw)
To: Daniel Axtens, linuxppc-dev
In-Reply-To: <87zhcup02u.fsf@dja-thinkpad.axtens.net>
On 6/3/20 3:40 pm, Daniel Axtens wrote:
>> There's some special handling for CPU_FTR_HVMODE in
>> cpufeatures_setup_cpu() in kernel/dt_cpu_ftrs.c:
>>
>> /* Initialize the base environment -- clear FSCR/HFSCR. */
>> hv_mode = !!(mfmsr() & MSR_HV);
>> if (hv_mode) {
>> /* CPU_FTR_HVMODE is used early in PACA setup */
>> cur_cpu_spec->cpu_features |= CPU_FTR_HVMODE;
>> mtspr(SPRN_HFSCR, 0);
>> }
>>
>> With this patch, the comment about PACA setup I assume is no longer
>> true. It looks like we still rely on hv_mode being set to deal with
>> discrepancies between the device tree and the MSR.
>
> This code confuses me. IIUC it sets the CPU feature if we're in HV mode,
> which will catch the case where the HV bit is set in the MSR but for
> some reason it's not listed in the DT. With my patch, we'll directly
> test the MSR so we don't need the cpu feature set for that.
>
> However, the CPU feature is tested elsewhere, so I think the correct
> behaviour is to keep the code but drop the comment. Having said that
> bootstrapping is hard so lmk if I've misunderstood.
That was my thinking too.
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* [PATCH v3] powerpc/64s/pgtable: fix an undefined behaviour
From: Qian Cai @ 2020-03-06 4:48 UTC (permalink / raw)
To: mpe; +Cc: Qian Cai, linuxppc-dev, rashmicy, linux-kernel
Booting a power9 server with hash MMU could trigger an undefined
behaviour because pud_offset(p4d, 0) will do,
0 >> (PAGE_SHIFT:16 + PTE_INDEX_SIZE:8 + H_PMD_INDEX_SIZE:10)
Fix it by converting pud_index() and friends to static inline
functions.
UBSAN: shift-out-of-bounds in arch/powerpc/mm/ptdump/ptdump.c:282:15
shift exponent 34 is too large for 32-bit type 'int'
CPU: 6 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc4-next-20200303+ #13
Call Trace:
dump_stack+0xf4/0x164 (unreliable)
ubsan_epilogue+0x18/0x78
__ubsan_handle_shift_out_of_bounds+0x160/0x21c
walk_pagetables+0x2cc/0x700
walk_pud at arch/powerpc/mm/ptdump/ptdump.c:282
(inlined by) walk_pagetables at arch/powerpc/mm/ptdump/ptdump.c:311
ptdump_check_wx+0x8c/0xf0
mark_rodata_ro+0x48/0x80
kernel_init+0x74/0x194
ret_from_kernel_thread+0x5c/0x74
Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Qian Cai <cai@lca.pw>
---
v3: convert pud_index() etc to static inline functions.
v2: convert pud_offset() etc to static inline functions.
arch/powerpc/include/asm/book3s/64/pgtable.h | 23 ++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 201a69e6a355..bd432c6706b9 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -998,10 +998,25 @@ extern struct page *pgd_page(pgd_t pgd);
#define pud_page_vaddr(pud) __va(pud_val(pud) & ~PUD_MASKED_BITS)
#define pgd_page_vaddr(pgd) __va(pgd_val(pgd) & ~PGD_MASKED_BITS)
-#define pgd_index(address) (((address) >> (PGDIR_SHIFT)) & (PTRS_PER_PGD - 1))
-#define pud_index(address) (((address) >> (PUD_SHIFT)) & (PTRS_PER_PUD - 1))
-#define pmd_index(address) (((address) >> (PMD_SHIFT)) & (PTRS_PER_PMD - 1))
-#define pte_index(address) (((address) >> (PAGE_SHIFT)) & (PTRS_PER_PTE - 1))
+static inline unsigned long pgd_index(unsigned long address)
+{
+ return (address >> PGDIR_SHIFT) & (PTRS_PER_PGD - 1);
+}
+
+static inline unsigned long pud_index(unsigned long address)
+{
+ return (address >> PUD_SHIFT) & (PTRS_PER_PUD - 1);
+}
+
+static inline unsigned long pmd_index(unsigned long address)
+{
+ return (address >> PMD_SHIFT) & (PTRS_PER_PMD - 1);
+}
+
+static inline unsigned long pte_index(unsigned long address)
+{
+ return (address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1);
+}
/*
* Find an entry in a page-table-directory. We combine the address region
--
2.21.0 (Apple Git-122.2)
^ permalink raw reply related
* Re: [PATCH -next v2] powerpc/64s/pgtable: fix an undefined behaviour
From: Qian Cai @ 2020-03-06 4:50 UTC (permalink / raw)
To: Christophe Leroy
Cc: rashmicy, linux-kernel, linux-mm, Andrew Morton, linuxppc-dev
In-Reply-To: <a082f4c3-db68-6ca3-c832-b1abb5363e3a@c-s.fr>
> On Mar 5, 2020, at 2:22 PM, Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>
>
>
> Le 05/03/2020 à 15:32, Qian Cai a écrit :
>> Booting a power9 server with hash MMU could trigger an undefined
>> behaviour because pud_offset(p4d, 0) will do,
>> 0 >> (PAGE_SHIFT:16 + PTE_INDEX_SIZE:8 + H_PMD_INDEX_SIZE:10)
>> Fix it by converting pud_offset() and friends to static inline
>> functions.
>
> I was suggesting to convert pud_index() to static inline, because that's where the shift sits. Is it not possible ?
>
> Here you seems to fix the problem for now, but if someone reuses pud_index() in another macro one day, the same problem may happen again.
>
Sounds reasonable. I send out a v3,
https://lore.kernel.org/lkml/20200306044852.3236-1-cai@lca.pw/T/#u
> Christophe
>
>> UBSAN: shift-out-of-bounds in arch/powerpc/mm/ptdump/ptdump.c:282:15
>> shift exponent 34 is too large for 32-bit type 'int'
>> CPU: 6 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc4-next-20200303+ #13
>> Call Trace:
>> dump_stack+0xf4/0x164 (unreliable)
>> ubsan_epilogue+0x18/0x78
>> __ubsan_handle_shift_out_of_bounds+0x160/0x21c
>> walk_pagetables+0x2cc/0x700
>> walk_pud at arch/powerpc/mm/ptdump/ptdump.c:282
>> (inlined by) walk_pagetables at arch/powerpc/mm/ptdump/ptdump.c:311
>> ptdump_check_wx+0x8c/0xf0
>> mark_rodata_ro+0x48/0x80
>> kernel_init+0x74/0x194
>> ret_from_kernel_thread+0x5c/0x74
>> Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
>> Signed-off-by: Qian Cai <cai@lca.pw>
>> ---
>> arch/powerpc/include/asm/book3s/64/pgtable.h | 20 ++++++++++++++------
>> 1 file changed, 14 insertions(+), 6 deletions(-)
>> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
>> index fa60e8594b9f..4967bc9e25e2 100644
>> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
>> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
>> @@ -1016,12 +1016,20 @@ static inline bool p4d_access_permitted(p4d_t p4d, bool write)
>> #define pgd_offset(mm, address) ((mm)->pgd + pgd_index(address))
>> -#define pud_offset(p4dp, addr) \
>> - (((pud_t *) p4d_page_vaddr(*(p4dp))) + pud_index(addr))
>> -#define pmd_offset(pudp,addr) \
>> - (((pmd_t *) pud_page_vaddr(*(pudp))) + pmd_index(addr))
>> -#define pte_offset_kernel(dir,addr) \
>> - (((pte_t *) pmd_page_vaddr(*(dir))) + pte_index(addr))
>> +static inline pud_t *pud_offset(p4d_t *p4d, unsigned long address)
>> +{
>> + return (pud_t *)p4d_page_vaddr(*p4d) + pud_index(address);
>> +}
>> +
>> +static inline pmd_t *pmd_offset(pud_t *pud, unsigned long address)
>> +{
>> + return (pmd_t *)pud_page_vaddr(*pud) + pmd_index(address);
>> +}
>> +
>> +static inline pte_t *pte_offset_kernel(pmd_t *pmd, unsigned long address)
>> +{
>> + return (pte_t *)pmd_page_vaddr(*pmd) + pte_index(address);
>> +}
>> #define pte_offset_map(dir,addr) pte_offset_kernel((dir), (addr))
>>
^ permalink raw reply
* Re: [PATCH v3 6/8] perf/tools: Enhance JSON/metric infrastructure to handle "?"
From: kajoljain @ 2020-03-06 4:52 UTC (permalink / raw)
To: Jiri Olsa
Cc: mark.rutland, maddy, peterz, yao.jin, mingo, kan.liang, ak,
alexander.shishkin, anju, mamatha4, sukadev, ravi.bangoria, acme,
jmario, namhyung, tglx, mpetlan, gregkh, linux-kernel,
linux-perf-users, jolsa, linuxppc-dev
In-Reply-To: <20200302150819.GA259142@krava>
On 3/2/20 8:38 PM, Jiri Olsa wrote:
> On Sat, Feb 29, 2020 at 03:11:57PM +0530, Kajol Jain wrote:
>
> SNIP
>
>> #define PVR_VER(pvr) (((pvr) >> 16) & 0xFFFF) /* Version field */
>> #define PVR_REV(pvr) (((pvr) >> 0) & 0xFFFF) /* Revison field */
>>
>> +#define SOCKETS_INFO_FILE_PATH "/devices/hv_24x7/interface/"
>> +
>> int
>> get_cpuid(char *buffer, size_t sz)
>> {
>> @@ -44,3 +51,43 @@ get_cpuid_str(struct perf_pmu *pmu __maybe_unused)
>>
>> return bufp;
>> }
>> +
>> +int arch_get_runtimeparam(void)
>> +{
>> + int count = 0;
>> + DIR *dir;
>> + char path[PATH_MAX];
>> + const char *sysfs = sysfs__mountpoint();
>> + char filename[] = "sockets";
>> + FILE *file;
>> + char buf[16], *num;
>> + int data;
>> +
>> + if (!sysfs)
>> + goto out;
>> +
>> + snprintf(path, PATH_MAX,
>> + "%s" SOCKETS_INFO_FILE_PATH, sysfs);
>> + dir = opendir(path);
>> +
>> + if (!dir)
>> + goto out;
>> +
>> + strcat(path, filename);
>> + file = fopen(path, "r");
>> +
>> + if (!file)
>> + goto out;
>> +
>> + data = fread(buf, 1, sizeof(buf), file);
>> +
>> + if (data == 0)
>> + goto out;
>> +
>> + count = strtol(buf, &num, 10);
>> +out:
>> + if (!count)
>> + count = 1;
>> +
>> + return count;
>
> we have sysfs__read_ull for this
>
Hi Jiri,
Thanks for suggesting it. Will update.
Kajol
> jirka
>
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS 247257b03b04398ca07da4bce3d17bee25d623cb
From: kbuild test robot @ 2020-03-06 5:21 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: 247257b03b04398ca07da4bce3d17bee25d623cb powerpc/numa: Remove late request for home node associativity
elapsed time: 1022m
configs tested: 230
configs skipped: 12
The following configs have been built successfully.
More configs may be tested in the coming days.
arm allmodconfig
arm allnoconfig
arm allyesconfig
arm64 allmodconfig
arm64 allnoconfig
arm64 allyesconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 defconfig
sparc allyesconfig
microblaze nommu_defconfig
mips allnoconfig
ia64 defconfig
h8300 h8300h-sim_defconfig
parisc allnoconfig
s390 defconfig
powerpc defconfig
m68k m5475evb_defconfig
parisc allyesconfig
i386 allnoconfig
i386 allyesconfig
i386 alldefconfig
i386 defconfig
ia64 alldefconfig
ia64 allmodconfig
ia64 allnoconfig
ia64 allyesconfig
nios2 3c120_defconfig
nios2 10m50_defconfig
c6x evmc6678_defconfig
xtensa iss_defconfig
c6x allyesconfig
xtensa common_defconfig
openrisc simple_smp_defconfig
openrisc or1ksim_defconfig
alpha defconfig
csky defconfig
nds32 allnoconfig
nds32 defconfig
h8300 edosk2674_defconfig
h8300 h8s-sim_defconfig
m68k allmodconfig
m68k multi_defconfig
m68k sun3_defconfig
arc allyesconfig
arc defconfig
microblaze mmu_defconfig
powerpc allnoconfig
powerpc ppc64_defconfig
powerpc rhel-kconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
mips allyesconfig
mips fuloong2e_defconfig
mips malta_kvm_defconfig
parisc generic-32bit_defconfig
parisc generic-64bit_defconfig
x86_64 randconfig-a001-20200305
x86_64 randconfig-a002-20200305
x86_64 randconfig-a003-20200305
i386 randconfig-a001-20200305
i386 randconfig-a002-20200305
i386 randconfig-a003-20200305
x86_64 randconfig-a001-20200306
x86_64 randconfig-a002-20200306
x86_64 randconfig-a003-20200306
i386 randconfig-a001-20200306
i386 randconfig-a002-20200306
i386 randconfig-a003-20200306
alpha randconfig-a001-20200305
m68k randconfig-a001-20200305
mips randconfig-a001-20200305
nds32 randconfig-a001-20200305
parisc randconfig-a001-20200305
riscv randconfig-a001-20200305
alpha randconfig-a001-20200306
m68k randconfig-a001-20200306
mips randconfig-a001-20200306
nds32 randconfig-a001-20200306
parisc randconfig-a001-20200306
riscv randconfig-a001-20200306
c6x randconfig-a001-20200305
h8300 randconfig-a001-20200305
microblaze randconfig-a001-20200305
nios2 randconfig-a001-20200305
sparc64 randconfig-a001-20200305
csky randconfig-a001-20200305
openrisc randconfig-a001-20200305
s390 randconfig-a001-20200305
sh randconfig-a001-20200305
xtensa randconfig-a001-20200305
x86_64 randconfig-b001-20200305
x86_64 randconfig-b002-20200305
x86_64 randconfig-b003-20200305
i386 randconfig-b001-20200305
i386 randconfig-b002-20200305
i386 randconfig-b003-20200305
x86_64 randconfig-b001-20200306
x86_64 randconfig-b002-20200306
x86_64 randconfig-b003-20200306
i386 randconfig-b001-20200306
i386 randconfig-b002-20200306
i386 randconfig-b003-20200306
x86_64 randconfig-c001-20200305
x86_64 randconfig-c002-20200305
x86_64 randconfig-c003-20200305
i386 randconfig-c001-20200305
i386 randconfig-c002-20200305
i386 randconfig-c003-20200305
x86_64 randconfig-c001-20200306
x86_64 randconfig-c002-20200306
x86_64 randconfig-c003-20200306
i386 randconfig-c001-20200306
i386 randconfig-c002-20200306
i386 randconfig-c003-20200306
x86_64 randconfig-d001-20200305
x86_64 randconfig-d002-20200305
x86_64 randconfig-d003-20200305
i386 randconfig-d001-20200305
i386 randconfig-d002-20200305
i386 randconfig-d003-20200305
x86_64 randconfig-d001-20200306
x86_64 randconfig-d002-20200306
x86_64 randconfig-d003-20200306
i386 randconfig-d001-20200306
i386 randconfig-d002-20200306
i386 randconfig-d003-20200306
x86_64 randconfig-e001-20200305
x86_64 randconfig-e002-20200305
x86_64 randconfig-e003-20200305
i386 randconfig-e001-20200305
i386 randconfig-e002-20200305
i386 randconfig-e003-20200305
x86_64 randconfig-e001-20200306
x86_64 randconfig-e002-20200306
x86_64 randconfig-e003-20200306
i386 randconfig-e001-20200306
i386 randconfig-e002-20200306
i386 randconfig-e003-20200306
x86_64 randconfig-f001-20200304
x86_64 randconfig-f002-20200304
x86_64 randconfig-f003-20200304
i386 randconfig-f001-20200304
i386 randconfig-f002-20200304
i386 randconfig-f003-20200304
x86_64 randconfig-f001-20200305
x86_64 randconfig-f002-20200305
x86_64 randconfig-f003-20200305
i386 randconfig-f001-20200305
i386 randconfig-f002-20200305
i386 randconfig-f003-20200305
x86_64 randconfig-f001-20200306
x86_64 randconfig-f002-20200306
x86_64 randconfig-f003-20200306
i386 randconfig-f001-20200306
i386 randconfig-f002-20200306
i386 randconfig-f003-20200306
x86_64 randconfig-g001-20200305
x86_64 randconfig-g002-20200305
x86_64 randconfig-g003-20200305
i386 randconfig-g001-20200305
i386 randconfig-g002-20200305
i386 randconfig-g003-20200305
x86_64 randconfig-g001-20200306
x86_64 randconfig-g002-20200306
x86_64 randconfig-g003-20200306
i386 randconfig-g001-20200306
i386 randconfig-g002-20200306
i386 randconfig-g003-20200306
x86_64 randconfig-h001-20200305
x86_64 randconfig-h002-20200305
x86_64 randconfig-h003-20200305
i386 randconfig-h001-20200305
i386 randconfig-h002-20200305
i386 randconfig-h003-20200305
x86_64 randconfig-h001-20200306
x86_64 randconfig-h002-20200306
x86_64 randconfig-h003-20200306
i386 randconfig-h001-20200306
i386 randconfig-h002-20200306
i386 randconfig-h003-20200306
arc randconfig-a001-20200306
arm randconfig-a001-20200306
arm64 randconfig-a001-20200306
ia64 randconfig-a001-20200306
powerpc randconfig-a001-20200306
sparc randconfig-a001-20200306
arc randconfig-a001-20200305
arm randconfig-a001-20200305
arm64 randconfig-a001-20200305
ia64 randconfig-a001-20200305
powerpc randconfig-a001-20200305
sparc randconfig-a001-20200305
riscv allmodconfig
riscv allnoconfig
riscv allyesconfig
riscv defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
s390 alldefconfig
s390 allmodconfig
s390 allnoconfig
s390 allyesconfig
s390 debug_defconfig
s390 zfcpdump_defconfig
sh allmodconfig
sh allnoconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sh titan_defconfig
sparc defconfig
sparc64 allmodconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 defconfig
um defconfig
um i386_defconfig
um x86_64_defconfig
x86_64 fedora-25
x86_64 kexec
x86_64 lkp
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 rhel-7.6
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 5c61987c29055c619e116977c7d5db772d0f5239
From: kbuild test robot @ 2020-03-06 5:21 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 5c61987c29055c619e116977c7d5db772d0f5239 powerpc/lib: Fix emulate_step() std test
elapsed time: 1022m
configs tested: 176
configs skipped: 11
The following configs have been built successfully.
More configs may be tested in the coming days.
arm64 allyesconfig
arm allyesconfig
arm64 allnoconfig
arm allnoconfig
arm allmodconfig
arm64 allmodconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 defconfig
sparc allyesconfig
sparc64 allnoconfig
ia64 defconfig
powerpc defconfig
m68k m5475evb_defconfig
parisc allyesconfig
i386 allnoconfig
i386 alldefconfig
i386 allyesconfig
i386 defconfig
ia64 alldefconfig
ia64 allmodconfig
ia64 allnoconfig
ia64 allyesconfig
c6x allyesconfig
c6x evmc6678_defconfig
nios2 10m50_defconfig
nios2 3c120_defconfig
openrisc or1ksim_defconfig
openrisc simple_smp_defconfig
xtensa common_defconfig
xtensa iss_defconfig
alpha defconfig
csky defconfig
nds32 allnoconfig
nds32 defconfig
h8300 edosk2674_defconfig
h8300 h8300h-sim_defconfig
h8300 h8s-sim_defconfig
m68k allmodconfig
m68k multi_defconfig
m68k sun3_defconfig
arc allyesconfig
arc defconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
powerpc allnoconfig
powerpc ppc64_defconfig
powerpc rhel-kconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
mips allnoconfig
mips allyesconfig
mips fuloong2e_defconfig
mips malta_kvm_defconfig
parisc allnoconfig
parisc generic-32bit_defconfig
parisc generic-64bit_defconfig
x86_64 randconfig-a001-20200305
x86_64 randconfig-a002-20200305
x86_64 randconfig-a003-20200305
i386 randconfig-a001-20200305
i386 randconfig-a002-20200305
i386 randconfig-a003-20200305
x86_64 randconfig-a001-20200306
x86_64 randconfig-a002-20200306
x86_64 randconfig-a003-20200306
i386 randconfig-a001-20200306
i386 randconfig-a002-20200306
i386 randconfig-a003-20200306
alpha randconfig-a001-20200305
m68k randconfig-a001-20200305
mips randconfig-a001-20200305
nds32 randconfig-a001-20200305
parisc randconfig-a001-20200305
riscv randconfig-a001-20200305
c6x randconfig-a001-20200305
h8300 randconfig-a001-20200305
microblaze randconfig-a001-20200305
nios2 randconfig-a001-20200305
sparc64 randconfig-a001-20200305
csky randconfig-a001-20200305
openrisc randconfig-a001-20200305
s390 randconfig-a001-20200305
sh randconfig-a001-20200305
xtensa randconfig-a001-20200305
x86_64 randconfig-b001-20200305
x86_64 randconfig-b002-20200305
x86_64 randconfig-b003-20200305
i386 randconfig-b001-20200305
i386 randconfig-b002-20200305
i386 randconfig-b003-20200305
x86_64 randconfig-c001-20200306
x86_64 randconfig-c002-20200306
x86_64 randconfig-c003-20200306
i386 randconfig-c001-20200306
i386 randconfig-c002-20200306
i386 randconfig-c003-20200306
x86_64 randconfig-d001-20200305
x86_64 randconfig-d002-20200305
x86_64 randconfig-d003-20200305
i386 randconfig-d001-20200305
i386 randconfig-d002-20200305
i386 randconfig-d003-20200305
x86_64 randconfig-e001-20200305
x86_64 randconfig-e002-20200305
x86_64 randconfig-e003-20200305
i386 randconfig-e001-20200305
i386 randconfig-e002-20200305
i386 randconfig-e003-20200305
x86_64 randconfig-f001-20200304
x86_64 randconfig-f002-20200304
x86_64 randconfig-f003-20200304
i386 randconfig-f001-20200304
i386 randconfig-f002-20200304
i386 randconfig-f003-20200304
x86_64 randconfig-f001-20200305
x86_64 randconfig-f002-20200305
x86_64 randconfig-f003-20200305
i386 randconfig-f001-20200305
i386 randconfig-f002-20200305
i386 randconfig-f003-20200305
x86_64 randconfig-h001-20200305
x86_64 randconfig-h002-20200305
x86_64 randconfig-h003-20200305
i386 randconfig-h001-20200305
i386 randconfig-h002-20200305
i386 randconfig-h003-20200305
arc randconfig-a001-20200306
ia64 randconfig-a001-20200306
sparc randconfig-a001-20200306
arm randconfig-a001-20200306
arm64 randconfig-a001-20200306
powerpc randconfig-a001-20200306
arc randconfig-a001-20200305
arm randconfig-a001-20200305
arm64 randconfig-a001-20200305
ia64 randconfig-a001-20200305
powerpc randconfig-a001-20200305
sparc randconfig-a001-20200305
riscv allmodconfig
riscv allnoconfig
riscv allyesconfig
riscv defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
s390 alldefconfig
s390 allmodconfig
s390 allnoconfig
s390 allyesconfig
s390 debug_defconfig
s390 defconfig
s390 zfcpdump_defconfig
sh allmodconfig
sh allnoconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sh titan_defconfig
sparc defconfig
sparc64 defconfig
sparc64 allyesconfig
sparc64 allmodconfig
um defconfig
um i386_defconfig
um x86_64_defconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
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:fixes-test] BUILD SUCCESS 59bee45b9712c759ea4d3dcc4eff1752f3a66558
From: kbuild test robot @ 2020-03-06 5:21 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 59bee45b9712c759ea4d3dcc4eff1752f3a66558 powerpc/mm: Fix missing KUAP disable in flush_coherent_icache()
elapsed time: 1371m
configs tested: 206
configs skipped: 207
The following configs have been built successfully.
More configs may be tested in the coming days.
arm allmodconfig
arm allnoconfig
arm allyesconfig
arm64 allmodconfig
arm64 allnoconfig
arm64 allyesconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 defconfig
sparc allyesconfig
sh allmodconfig
ia64 defconfig
sh sh7785lcr_32bit_defconfig
ia64 allnoconfig
h8300 h8300h-sim_defconfig
parisc allnoconfig
s390 defconfig
sparc64 allyesconfig
powerpc defconfig
i386 allnoconfig
i386 alldefconfig
i386 allyesconfig
i386 defconfig
ia64 alldefconfig
ia64 allmodconfig
ia64 allyesconfig
c6x allyesconfig
c6x evmc6678_defconfig
nios2 10m50_defconfig
nios2 3c120_defconfig
openrisc or1ksim_defconfig
openrisc simple_smp_defconfig
xtensa common_defconfig
xtensa iss_defconfig
alpha defconfig
csky defconfig
nds32 allnoconfig
nds32 defconfig
h8300 edosk2674_defconfig
h8300 h8s-sim_defconfig
m68k allmodconfig
m68k m5475evb_defconfig
m68k multi_defconfig
m68k sun3_defconfig
arc allyesconfig
arc defconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
powerpc allnoconfig
powerpc ppc64_defconfig
powerpc rhel-kconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
mips allnoconfig
mips allyesconfig
mips fuloong2e_defconfig
mips malta_kvm_defconfig
parisc allyesconfig
parisc generic-32bit_defconfig
parisc generic-64bit_defconfig
x86_64 randconfig-a001-20200306
x86_64 randconfig-a002-20200306
x86_64 randconfig-a003-20200306
i386 randconfig-a001-20200306
i386 randconfig-a002-20200306
i386 randconfig-a003-20200306
alpha randconfig-a001-20200306
m68k randconfig-a001-20200306
mips randconfig-a001-20200306
nds32 randconfig-a001-20200306
parisc randconfig-a001-20200306
riscv randconfig-a001-20200306
alpha randconfig-a001-20200305
m68k randconfig-a001-20200305
mips randconfig-a001-20200305
nds32 randconfig-a001-20200305
parisc randconfig-a001-20200305
riscv randconfig-a001-20200305
c6x randconfig-a001-20200305
h8300 randconfig-a001-20200305
microblaze randconfig-a001-20200305
nios2 randconfig-a001-20200305
sparc64 randconfig-a001-20200305
csky randconfig-a001-20200305
openrisc randconfig-a001-20200305
s390 randconfig-a001-20200305
sh randconfig-a001-20200305
xtensa randconfig-a001-20200305
x86_64 randconfig-b001-20200306
x86_64 randconfig-b002-20200306
x86_64 randconfig-b003-20200306
i386 randconfig-b001-20200306
i386 randconfig-b002-20200306
i386 randconfig-b003-20200306
x86_64 randconfig-b001-20200305
x86_64 randconfig-b002-20200305
x86_64 randconfig-b003-20200305
i386 randconfig-b001-20200305
i386 randconfig-b002-20200305
i386 randconfig-b003-20200305
x86_64 randconfig-c001-20200305
x86_64 randconfig-c002-20200305
x86_64 randconfig-c003-20200305
i386 randconfig-c001-20200305
i386 randconfig-c002-20200305
i386 randconfig-c003-20200305
x86_64 randconfig-d001-20200305
x86_64 randconfig-d002-20200305
x86_64 randconfig-d003-20200305
i386 randconfig-d001-20200305
i386 randconfig-d002-20200305
i386 randconfig-d003-20200305
x86_64 randconfig-d001-20200306
x86_64 randconfig-d002-20200306
x86_64 randconfig-d003-20200306
i386 randconfig-d001-20200306
i386 randconfig-d002-20200306
i386 randconfig-d003-20200306
x86_64 randconfig-e001-20200305
x86_64 randconfig-e002-20200305
x86_64 randconfig-e003-20200305
i386 randconfig-e001-20200305
i386 randconfig-e002-20200305
i386 randconfig-e003-20200305
x86_64 randconfig-e001-20200306
x86_64 randconfig-e002-20200306
x86_64 randconfig-e003-20200306
i386 randconfig-e001-20200306
i386 randconfig-e002-20200306
i386 randconfig-e003-20200306
x86_64 randconfig-f001-20200305
x86_64 randconfig-f002-20200305
x86_64 randconfig-f003-20200305
i386 randconfig-f001-20200305
i386 randconfig-f002-20200305
i386 randconfig-f003-20200305
x86_64 randconfig-f001-20200306
x86_64 randconfig-f002-20200306
x86_64 randconfig-f003-20200306
i386 randconfig-f001-20200306
i386 randconfig-f002-20200306
i386 randconfig-f003-20200306
x86_64 randconfig-g001-20200305
x86_64 randconfig-g002-20200305
x86_64 randconfig-g003-20200305
i386 randconfig-g001-20200305
i386 randconfig-g002-20200305
i386 randconfig-g003-20200305
x86_64 randconfig-g001-20200306
x86_64 randconfig-g002-20200306
x86_64 randconfig-g003-20200306
i386 randconfig-g001-20200306
i386 randconfig-g002-20200306
i386 randconfig-g003-20200306
x86_64 randconfig-h001-20200305
x86_64 randconfig-h002-20200305
x86_64 randconfig-h003-20200305
i386 randconfig-h001-20200305
i386 randconfig-h002-20200305
i386 randconfig-h003-20200305
x86_64 randconfig-h001-20200306
x86_64 randconfig-h002-20200306
x86_64 randconfig-h003-20200306
i386 randconfig-h001-20200306
i386 randconfig-h002-20200306
i386 randconfig-h003-20200306
arc randconfig-a001-20200305
arm randconfig-a001-20200305
arm64 randconfig-a001-20200305
ia64 randconfig-a001-20200305
powerpc randconfig-a001-20200305
sparc randconfig-a001-20200305
riscv allmodconfig
riscv allnoconfig
riscv allyesconfig
riscv defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
s390 alldefconfig
s390 allmodconfig
s390 allnoconfig
s390 allyesconfig
s390 debug_defconfig
s390 zfcpdump_defconfig
sh allnoconfig
sh rsk7269_defconfig
sh titan_defconfig
sparc defconfig
sparc64 allmodconfig
sparc64 allnoconfig
sparc64 defconfig
um defconfig
um i386_defconfig
um x86_64_defconfig
x86_64 fedora-25
x86_64 kexec
x86_64 lkp
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 rhel-7.6
---
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