Re: [PATCH] powerpc/ftrace: fix syscall tracing on PPC64_ELF_ABI_V1
Michael Jeanson writes:
> In v5.7 the powerpc syscall entry/exit logic was rewritten in C, on
> PPC64_ELF_ABI_V1 this resulted in the symbols in the syscall table
> changing from their dot prefixed variant to the non-prefixed ones.
>
> Since ftrace prefixes a dot to the syscall names when matching them to
> build its syscall event list, this resulted in no syscall events being
> available.
>
> Remove the PPC64_ELF_ABI_V1 specific version of
> arch_syscall_match_sym_name to have the same behavior across all powerpc
> variants.
This doesn't seem to work for me.
Event with it applied I still don't see anything in
/sys/kernel/debug/tracing/events/syscalls
Did we break it in some other way recently?
cheers
> Fixes: 68b34588e202 ("powerpc/64/sycall: Implement syscall entry/exit logic
> in C")
> Cc: sta...@vger.kernel.org # v5.7+
> Cc: Steven Rostedt
> Cc: Masami Hiramatsu
> Cc: Mark Rutland
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Christophe Leroy
> Cc: Michal Suchanek
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Michael Jeanson
> Reviewed-by: Mathieu Desnoyers
> ---
> arch/powerpc/include/asm/ftrace.h | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ftrace.h
> b/arch/powerpc/include/asm/ftrace.h
> index 3cee7115441b..e3d1f377bc5b 100644
> --- a/arch/powerpc/include/asm/ftrace.h
> +++ b/arch/powerpc/include/asm/ftrace.h
> @@ -64,17 +64,6 @@ void ftrace_graph_func(unsigned long ip, unsigned long
> parent_ip,
> * those.
> */
> #define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
> -#ifdef CONFIG_PPC64_ELF_ABI_V1
> -static inline bool arch_syscall_match_sym_name(const char *sym, const char
> *name)
> -{
> - /* We need to skip past the initial dot, and the __se_sys alias */
> - return !strcmp(sym + 1, name) ||
> - (!strncmp(sym, ".__se_sys", 9) && !strcmp(sym + 6, name)) ||
> - (!strncmp(sym, ".ppc_", 5) && !strcmp(sym + 5, name + 4)) ||
> - (!strncmp(sym, ".ppc32_", 7) && !strcmp(sym + 7, name + 4)) ||
> - (!strncmp(sym, ".ppc64_", 7) && !strcmp(sym + 7, name + 4));
> -}
> -#else
> static inline bool arch_syscall_match_sym_name(const char *sym, const char
> *name)
> {
> return !strcmp(sym, name) ||
> @@ -83,7 +72,6 @@ static inline bool arch_syscall_match_sym_name(const char
> *sym, const char *name
> (!strncmp(sym, "ppc32_", 6) && !strcmp(sym + 6, name + 4)) ||
> (!strncmp(sym, "ppc64_", 6) && !strcmp(sym + 6, name + 4));
> }
> -#endif /* CONFIG_PPC64_ELF_ABI_V1 */
> #endif /* CONFIG_FTRACE_SYSCALLS */
>
> #if defined(CONFIG_PPC64) && defined(CONFIG_FUNCTION_TRACER)
> --
> 2.34.1
[PATCH] crypto: api - Use linux/cache.h instead of asm/cache.h
On Mon, Dec 05, 2022 at 10:52:25AM +1100, Stephen Rothwell wrote:
>
> Or maybe you should have included linux/cache.h instead of asm/cache.h?
You're right Stephen. Thanks!
---8<---
Directly including asm/cache.h leads to build failures on powerpc
so replace it with linux/cache.h instead.
Fixes: e634ac4a8aaa ("crypto: api - Add crypto_tfm_ctx_dma")
Reported-by: Stephen Rothwell
Signed-off-by: Herbert Xu
diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
index 8722fd67f40a..61b327206b55 100644
--- a/include/crypto/algapi.h
+++ b/include/crypto/algapi.h
@@ -7,8 +7,8 @@
#ifndef _CRYPTO_ALGAPI_H
#define _CRYPTO_ALGAPI_H
-#include
#include
+#include
#include
#include
#include
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[V3] tools/perf: Fix printing field separator in CSV metrics output
In perf stat with CSV output option, number of fields
in metrics output is not matching with number of fields
in other event output lines.
Sample output below after applying patch to fix
printing os->prefix.
# ./perf stat -x, --per-socket -a -C 1 ls
S0,1,82.11,msec,cpu-clock,82111626,100.00,1.000,CPUs utilized
S0,1,2,,context-switches,82109314,100.00,24.358,/sec
--
> S0,1,,,1.71,stalled cycles per insn
The above command line uses field separator as ","
via "-x," option and per-socket option displays
socket value as first field. But here the last line
for "stalled cycles per insn" has more separators.
Each csv output line is expected to have 8 field
separators (for the 9 fields), where as last line
has 9 "," in the result. Patch fixes this issue.
The counter stats are displayed by function
"perf_stat__print_shadow_stats" in code
"util/stat-shadow.c". While printing the stats info
for "stalled cycles per insn", function "new_line_csv"
is used as new_line callback.
The fields printed in each line contains:
"Socket_id,aggr nr,Avg,unit,event_name,run,enable_percent,ratio,unit"
The metric output prints Socket_id, aggr nr, ratio
and unit. It has to skip through remaining five fields
ie, Avg,unit,event_name,run,enable_percent. The csv
line callback uses "os->nfields" to know the number of
fields to skip to match with other lines.
Currently it is set as:
os.nfields = 3 + aggr_fields[config->aggr_mode] + (counter->cgrp ? 1 :
0);
But in case of aggregation modes, csv_sep already
gets printed along with each field (Function "aggr_printout"
in util/stat-display.c). So aggr_fields can be
removed from nfields. And fixed number of fields to
skip has to be "4". This is to skip fields for:
"avg, unit, event name, run, enable_percent"
This needs 4 csv separators. Patch removes aggr_fields
and uses 4 as fixed number of os->nfields to skip.
After the patch:
# ./perf stat -x, --per-socket -a -C 1 ls
S0,1,79.08,msec,cpu-clock,79085956,100.00,1.000,CPUs utilized
S0,1,7,,context-switches,79084176,100.00,88.514,/sec
--
> S0,1,,0.81,stalled cycles per insn
Fixes: 92a61f6412d3 ("perf stat: Implement CSV metrics output")
Reported-by: Disha Goel
Reviewed-by: Kajol Jain
Tested-by: Disha Goel
Signed-off-by: Athira Rajeev
---
Changelog:
v2 -> v3:
- Rebased on top of tmp.perf/core
v1 -> v2:
- Rebased on top of latest source.
- Added Reviewed-by and Tested-by from Kajol and
Disha.
tools/perf/util/stat-display.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c
index f1ee4b052198..4e9696f4096f 100644
--- a/tools/perf/util/stat-display.c
+++ b/tools/perf/util/stat-display.c
@@ -686,20 +686,9 @@ static void printout(struct perf_stat_config *config,
struct outstate *os,
struct evsel *counter = os->evsel;
if (config->csv_output) {
- static const int aggr_fields[AGGR_MAX] = {
- [AGGR_NONE] = 1,
- [AGGR_GLOBAL] = 0,
- [AGGR_SOCKET] = 2,
- [AGGR_DIE] = 2,
- [AGGR_CORE] = 2,
- [AGGR_THREAD] = 1,
- [AGGR_UNSET] = 0,
- [AGGR_NODE] = 1,
- };
-
pm = config->metric_only ? print_metric_only_csv :
print_metric_csv;
nl = config->metric_only ? new_line_metric : new_line_csv;
- os->nfields = 3 + aggr_fields[config->aggr_mode] +
(counter->cgrp ? 1 : 0);
+ os->nfields = 4 + (counter->cgrp ? 1 : 0);
} else if (config->json_output) {
pm = config->metric_only ? print_metric_only_json :
print_metric_json;
nl = config->metric_only ? new_line_metric : new_line_json;
--
2.31.1
[powerpc:next] BUILD REGRESSION 22db71bcba826c607324a8ee1b21f5cf7ec71e8b
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next branch HEAD: 22db71bcba826c607324a8ee1b21f5cf7ec71e8b Merge branch 'topic/qspinlock' into next Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202212050224.i7uh9foh-...@intel.com Error/Warning: (recently discovered and may have been fixed) arch/powerpc/lib/qspinlock.c:207:2: error: call to undeclared function 'spin_end'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] arch/powerpc/lib/qspinlock.c:224:3: error: call to undeclared function 'spin_begin'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] arch/powerpc/lib/qspinlock.c:230:2: error: call to undeclared function 'spin_cpu_relax'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] include/linux/signal.h:113:11: error: array index 3 is past the end of the array (that has type 'const unsigned long[2]') [-Werror,-Warray-bounds] include/linux/signal.h:97:11: error: array index 3 is past the end of the array (that has type 'unsigned long[2]') [-Werror,-Warray-bounds] Error/Warning ids grouped by kconfigs: clang_recent_errors `-- powerpc-randconfig-r021-20221204 |-- arch-powerpc-lib-qspinlock.c:error:call-to-undeclared-function-spin_begin-ISO-C99-and-later-do-not-support-implicit-function-declarations |-- arch-powerpc-lib-qspinlock.c:error:call-to-undeclared-function-spin_cpu_relax-ISO-C99-and-later-do-not-support-implicit-function-declarations |-- arch-powerpc-lib-qspinlock.c:error:call-to-undeclared-function-spin_end-ISO-C99-and-later-do-not-support-implicit-function-declarations |-- include-linux-signal.h:error:array-index-is-past-the-end-of-the-array-(that-has-type-const-unsigned-long-)-Werror-Warray-bounds `-- include-linux-signal.h:error:array-index-is-past-the-end-of-the-array-(that-has-type-unsigned-long-)-Werror-Warray-bounds elapsed time: 724m configs tested: 86 configs skipped: 13 gcc tested configs: x86_64 rhel-8.3-kunit x86_64 rhel-8.3-kvm um i386_defconfig um x86_64_defconfig i386 randconfig-a016 x86_64randconfig-a006 x86_64 rhel-8.3-syz i386defconfig ia64 allmodconfig x86_64 defconfig i386 randconfig-a012 s390defconfig x86_64randconfig-a015 m68k allyesconfig i386 randconfig-a001 i386 randconfig-a014 arm defconfig s390 allyesconfig arc randconfig-r043-20221204 x86_64randconfig-a013 x86_64 rhel-8.3 i386 randconfig-a003 x86_64 allyesconfig x86_64rhel-8.3-kselftests x86_64randconfig-a002 arm randconfig-r046-20221204 i386 randconfig-a005 x86_64randconfig-a004 x86_64 rhel-8.3-func x86_64randconfig-a011 alphaallyesconfig i386 allyesconfig powerpc allnoconfig powerpc allmodconfig mips allyesconfig arc allyesconfig m68k allmodconfig sh allmodconfig arm allyesconfig arm64allyesconfig i386 randconfig-a016-20221205 i386 randconfig-a013-20221205 i386 randconfig-a012-20221205 i386 randconfig-a015-20221205 i386 randconfig-a011-20221205 i386 randconfig-a014-20221205 s390 allmodconfig arc defconfig alpha defconfig x86_64 randconfig-a014-20221205 x86_64 randconfig-a011-20221205 x86_64 randconfig-a012-20221205 x86_64 randconfig-a013-20221205 x86_64 randconfig-a015-20221205 x86_64 randconfig-a016-20221205 clang tested configs: i386 randconfig-a013 s390 randconfig-r044-20221204 x86_64randconfig-a005 i386 randconfig-a006 i386 randconfig-a015 i386 randconfig-a011 x86_64randconfig-a016 riscvrandconfig-r042
[powerpc:next-test] BUILD SUCCESS 6f3a81b60091031c2c14eb2373d1937b027deb46
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test branch HEAD: 6f3a81b60091031c2c14eb2373d1937b027deb46 powerpc/code-patching: Remove protection against patching init addresses after init elapsed time: 723m configs tested: 86 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: x86_64 rhel-8.3-kvm x86_64 rhel-8.3-kunit x86_64 rhel-8.3 x86_64 rhel-8.3-syz um i386_defconfig um x86_64_defconfig powerpc allnoconfig arc defconfig s390defconfig x86_64 defconfig alpha defconfig i386defconfig i386 randconfig-a016 x86_64randconfig-a002 x86_64randconfig-a015 x86_64randconfig-a006 x86_64randconfig-a004 arm randconfig-r046-20221204 arc randconfig-r043-20221204 i386 randconfig-a005 x86_64randconfig-a013 i386 randconfig-a001 x86_64randconfig-a011 s390 allmodconfig arm defconfig ia64 allmodconfig x86_64rhel-8.3-kselftests x86_64 allyesconfig x86_64 rhel-8.3-func i386 randconfig-a003 m68k allmodconfig arc allyesconfig i386 randconfig-a012 arm allyesconfig alphaallyesconfig sh allmodconfig arm64allyesconfig i386 allyesconfig i386 randconfig-a014 m68k allyesconfig s390 allyesconfig powerpc allmodconfig mips allyesconfig i386 randconfig-a016-20221205 i386 randconfig-a013-20221205 i386 randconfig-a012-20221205 i386 randconfig-a015-20221205 i386 randconfig-a011-20221205 i386 randconfig-a014-20221205 x86_64 randconfig-a014-20221205 x86_64 randconfig-a011-20221205 x86_64 randconfig-a012-20221205 x86_64 randconfig-a013-20221205 x86_64 randconfig-a015-20221205 x86_64 randconfig-a016-20221205 clang tested configs: x86_64randconfig-a001 x86_64randconfig-a016 x86_64randconfig-a005 i386 randconfig-a015 hexagon randconfig-r041-20221204 s390 randconfig-r044-20221204 x86_64randconfig-a012 i386 randconfig-a013 x86_64randconfig-a003 hexagon randconfig-r045-20221204 i386 randconfig-a002 x86_64randconfig-a014 i386 randconfig-a004 riscvrandconfig-r042-20221204 i386 randconfig-a006 i386 randconfig-a011 x86_64 randconfig-a004-20221205 x86_64 randconfig-a005-20221205 x86_64 randconfig-a003-20221205 x86_64 randconfig-a006-20221205 x86_64 randconfig-a002-20221205 x86_64 randconfig-a001-20221205 i386 randconfig-a003-20221205 i386 randconfig-a004-20221205 i386 randconfig-a001-20221205 i386 randconfig-a002-20221205 i386 randconfig-a005-20221205 i386 randconfig-a006-20221205 hexagon randconfig-r041-20221205 arm randconfig-r046-20221205 hexagon randconfig-r045-20221205 -- 0-DAY CI Kernel Test Service https://01.org/lkp
[PATCH v2] soc: fsl: qe: request pins non-exclusively
Commit 84582f9ed090 ("soc: fsl: qe: Avoid using gpio_to_desc()") changed
qe_pin_request() to request and hold GPIO corresponding to a given pin.
Unfortunately this does not work, as fhci-hcd requests these GPIOs
first, befor calling qe_pin_request() (see
drivers/usb/host/fhci-hcd.c::of_fhci_probe()).
To fix it change qe_pin_request() to request GPIOs non-exclusively, and
free them once the code determines GPIO controller and offset for each
GPIO/pin.
Also reaching deep into gpiolib implementation is not the best idea. We
should either export gpio_chip_hwgpio() or keep converting to the global
gpio numbers space until we fix the driver to implement proper pin
control.
Fixes: 84582f9ed090 ("soc: fsl: qe: Avoid using gpio_to_desc()")
Signed-off-by: Dmitry Torokhov
---
v2:
- rebased on top of soc/driver. This will conflict with
c9eb6e546a23 soc: fsl: qe: Switch to use fwnode instead of of_node
found in next, the resolution is trivial: accept
fwnode_device_is_compatible() line found in next.
- fixed leak of gpiod when gc is not found
- dropped Linus' reviewed-by as the patch changed
drivers/soc/fsl/qe/gpio.c | 51 +
drivers/usb/host/fhci-hcd.c | 2 +-
include/soc/fsl/qe/qe.h | 5 ++--
3 files changed, 28 insertions(+), 30 deletions(-)
diff --git a/drivers/soc/fsl/qe/gpio.c b/drivers/soc/fsl/qe/gpio.c
index af9193e7e49b..1440922341d8 100644
--- a/drivers/soc/fsl/qe/gpio.c
+++ b/drivers/soc/fsl/qe/gpio.c
@@ -13,19 +13,12 @@
#include
#include
#include
-#include
+#include /* for of_mm_gpio_chip */
#include
#include
#include
#include
#include
-/*
- * FIXME: this is legacy code that is accessing gpiolib internals in order
- * to implement a custom pin controller. The proper solution is to create
- * a real combined pin control and GPIO driver in drivers/pinctrl. However
- * this hack is here for legacy code reasons.
- */
-#include "../../../gpio/gpiolib.h"
struct qe_gpio_chip {
struct of_mm_gpio_chip mm_gc;
@@ -147,65 +140,70 @@ struct qe_pin {
* something like qe_pio_controller. Someday.
*/
struct qe_gpio_chip *controller;
- struct gpio_desc *gpiod;
int num;
};
/**
* qe_pin_request - Request a QE pin
- * @np:device node to get a pin from
- * @index: index of a pin in the device tree
+ * @dev: device to get the pin from
+ * @index: index of the pin in the device tree
* Context:non-atomic
*
* This function return qe_pin so that you could use it with the rest of
* the QE Pin Multiplexing API.
*/
-struct qe_pin *qe_pin_request(struct device_node *np, int index)
+struct qe_pin *qe_pin_request(struct device *dev, int index)
{
struct qe_pin *qe_pin;
struct gpio_chip *gc;
struct gpio_desc *gpiod;
+ int gpio_num;
int err;
qe_pin = kzalloc(sizeof(*qe_pin), GFP_KERNEL);
if (!qe_pin) {
- pr_debug("%s: can't allocate memory\n", __func__);
+ dev_dbg(dev, "%s: can't allocate memory\n", __func__);
return ERR_PTR(-ENOMEM);
}
- gpiod = fwnode_gpiod_get_index(of_fwnode_handle(np), NULL, index,
GPIOD_ASIS, "qe");
- if (IS_ERR(gpiod)) {
- err = PTR_ERR(gpiod);
- goto err0;
- }
- if (!gpiod) {
- err = -EINVAL;
+ /*
+* Request gpio as nonexclusive as it was likely reserved by the
+* caller, and we are not planning on controlling it, we only need
+* the descriptor to the to the gpio chip structure.
+*/
+ gpiod = gpiod_get_index(dev, NULL, index,
+ GPIOD_ASIS | GPIOD_FLAGS_BIT_NONEXCLUSIVE);
+ err = PTR_ERR_OR_ZERO(gpiod);
+ if (err)
goto err0;
- }
+
gc = gpiod_to_chip(gpiod);
+ gpio_num = desc_to_gpio(gpiod);
+ /* We no longer need this descriptor */
+ gpiod_put(gpiod);
+
if (WARN_ON(!gc)) {
err = -ENODEV;
goto err0;
}
- qe_pin->gpiod = gpiod;
+
qe_pin->controller = gpiochip_get_data(gc);
/*
* FIXME: this gets the local offset on the gpio_chip so that the driver
* can manipulate pin control settings through its custom API. The real
* solution is to create a real pin control driver for this.
*/
- qe_pin->num = gpio_chip_hwgpio(gpiod);
+ qe_pin->num = gpio_num - gc->base;
if (!of_device_is_compatible(gc->of_node, "fsl,mpc8323-qe-pario-bank"))
{
- pr_debug("%s: tried to get a non-qe pin\n", __func__);
- gpiod_put(gpiod);
+ dev_dbg(dev, "%s: tried to get a non-qe pin\n", __func__);
err = -EINVAL;
goto err0;
}
return qe_pin;
err0:
kfree(qe_pin);
- pr_debug("%s failed with status %d\n", __func__, err);
+ dev_dbg(dev,
Re: [RESEND PATCH] soc: fsl: qe: request pins non-exclusively
On Sun, Dec 04, 2022 at 01:10:19PM +0100, Arnd Bergmann wrote:
> On Sun, Dec 4, 2022, at 05:50, Dmitry Torokhov wrote:
> >
> > SoC team, the problematic patch has been in next for a while and it
> > would be great to get the fix in to make sure the driver is not broken
> > in 6.2. Thanks!
>
> I have no problem taking thsi patch, but I get a merge conflict that
> I'm not sure how to resolve:
>
>
> @@@ -186,23 -182,27 +180,43 @@@ struct qe_pin *qe_pin_request(struct de
> if (WARN_ON(!gc)) {
> err = -ENODEV;
> goto err0;
> ++<<< HEAD
> + }
> + qe_pin->gpiod = gpiod;
> + qe_pin->controller = gpiochip_get_data(gc);
> + /*
> + * FIXME: this gets the local offset on the gpio_chip so that the
> driver
> + * can manipulate pin control settings through its custom API. The
> real
> + * solution is to create a real pin control driver for this.
> + */
> + qe_pin->num = gpio_chip_hwgpio(gpiod);
> +
> + if (!of_device_is_compatible(gc->of_node,
> "fsl,mpc8323-qe-pario-bank")) {
> + pr_debug("%s: tried to get a non-qe pin\n", __func__);
> + gpiod_put(gpiod);
> ++===
> + } else if (!fwnode_device_is_compatible(gc->fwnode,
> + "fsl,mpc8323-qe-pario-bank"))
> {
> + dev_dbg(dev, "%s: tried to get a non-qe pin\n", __func__);
> ++>>> soc: fsl: qe: request pins non-exclusively
> err = -EINVAL;
> - goto err0;
> + } else {
> + qe_pin->controller = gpiochip_get_data(gc);
> + /*
> +* FIXME: this gets the local offset on the gpio_chip so that
> +* the driver can manipulate pin control settings through its
> +* custom API. The real solution is to create a real pin
> control
> +* driver for this.
> +*/
> + qe_pin->num = desc_to_gpio(gpiod) - gc->base;
> }
>
> Could you rebase the patch on top of the soc/driver branch in the
> soc tree and send the updated version?
I see, it conflicts with:
c9eb6e546a23 soc: fsl: qe: Switch to use fwnode instead of of_node
that is in next but not in soc/driver tree/branch. OK, I'll rebase and I
just noticed that I was leaking gpiod in case we could not locate gc
(unlikely but still...).
Thanks.
--
Dmitry
Re: linux-next: build failure after merge of the crypto tree
Hi all, On Mon, 5 Dec 2022 10:48:57 +1100 Stephen Rothwell wrote: > > It could be (easily) argued that arch/powerpc/include/asm/cache.h should > include linus/types.h, but it is also unusual to include an asm/... file > before all the linux/... files. Or maybe you should have included linux/cache.h instead of asm/cache.h? -- Cheers, Stephen Rothwell pgphAFnsduZ9_.pgp Description: OpenPGP digital signature
linux-next: build failure after merge of the crypto tree
Hi all,
After merging the crypto tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from include/crypto/algapi.h:10,
from include/crypto/internal/hash.h:11,
from arch/powerpc/crypto/sha1.c:15:
arch/powerpc/include/asm/cache.h:40:9: error: unknown type name 'u32'
40 | u32 size;
| ^~~
arch/powerpc/include/asm/cache.h:41:9: error: unknown type name 'u32'
41 | u32 line_size;
| ^~~
(and so on ... lots of errors)
Caused by commit
e634ac4a8aaa ("crypto: api - Add crypto_tfm_ctx_dma")
It could be (easily) argued that arch/powerpc/include/asm/cache.h should
include linus/types.h, but it is also unusual to include an asm/... file
before all the linux/... files.
Anyway, I applied the following patch for today.
From: Stephen Rothwell
Date: Mon, 5 Dec 2022 10:42:57 +1100
Subject: [PATCH] fix up for "crypto: api - Add crypto_tfm_ctx_dma"
Signed-off-by: Stephen Rothwell
---
include/crypto/algapi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
index 8722fd67f40a..fced47dbd306 100644
--- a/include/crypto/algapi.h
+++ b/include/crypto/algapi.h
@@ -7,13 +7,13 @@
#ifndef _CRYPTO_ALGAPI_H
#define _CRYPTO_ALGAPI_H
-#include
#include
#include
#include
#include
#include
+#include
#include
/*
--
2.35.1
--
Cheers,
Stephen Rothwell
pgpf_EfWOz4co.pgp
Description: OpenPGP digital signature
Re: [PATCH 2/5] arm: dts: remove label = "cpu" from DSA dt-binding
On Wed, Nov 30, 2022 at 3:13 PM Arınç ÜNAL wrote: > This is not used by the DSA dt-binding, so remove it from all devicetrees. > > Signed-off-by: Arınç ÜNAL Acked-by: Linus Walleij Yours, Linus Walleij
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-6.1-6 tag
The pull request you sent on Mon, 05 Dec 2022 00:19:45 +1100: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-6.1-6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ae6bb71711713e7b6b2d9ed2af7318dc8ae5cfb2 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH 5/5] powerpc: dts: remove label = "cpu" from DSA dt-binding
Hi Pali, On Fri, Dec 02, 2022 at 08:35:52PM +0100, Pali Rohár wrote: > On Thursday 01 December 2022 17:44:00 Rob Herring wrote: > > On Thu, Dec 01, 2022 at 06:39:02PM +0100, Pali Rohár wrote: > > > I was told by Marek (CCed) that DSA port connected to CPU should have > > > label "cpu" and not "cpu". Modern way for specifying CPU port is > > > by defining reference to network device, which there is already ( > > > and ). So that change just "fixed" incorrect naming cpu0 and cpu1. > > > > > > So probably linux kernel does not need label = "cpu" in DTS anymore. But > > > this is not the reason to remove this property. Linux kernel does not > > > use lot of other nodes and properties too... Device tree should describe > > > hardware and not its usage in Linux. "label" property is valid in device > > > tree and it exactly describes what or where is this node connected. And > > > it may be used for other systems. > > > > > > So I do not see a point in removing "label" properties from turris1x.dts > > > file, nor from any other dts file. > > > > Well, it seems like a bit of an abuse of 'label' to me. 'label' should > > be aligned with a sticker or other identifier identifying something to a > > human. Software should never care what the value of 'label' is. > > But it already does. "label" property is used for setting (initial) > network interface name for DSA drivers. And you can try to call e.g. > git grep '"cpu"' net/dsa drivers/net/dsa to see that cpu is still > present on some dsa places (probably relict or backward compatibility > before eth reference). Can you try to eliminate the word "probably" from the information you transmit and be specific about when did the DSA binding parse or require the 'label = "cpu"' property for CPU ports in any way?
Re: [PATCH] vdso: Improve cmd_vdso_check to check all dynamic relocations
Le 04/12/2022 à 05:50, Fangrui Song a écrit : > On Mon, Nov 14, 2022 at 4:46 PM Fangrui Song wrote: >> >> On 2022-11-14, Christophe Leroy wrote: >>> >>> >>> Le 28/09/2022 à 07:25, Fangrui Song a écrit : On Sat, Sep 10, 2022 at 12:53 AM Fangrui Song wrote: > > On 2022-08-30, Fangrui Song wrote: >> The actual intention is that no dynamic relocation exists. However, some >> GNU ld ports produce unneeded R_*_NONE. (If a port is not care enough to >> determine the exact .rel[a].dyn size, the trailing zeros become R_*_NONE >> relocations. E.g. powerpc64le ld as of 2.38 has the issue with >> defconfig.) R_*_NONE are generally no-op in the dynamic loaders. So just >> ignore them. >> >> With the change, we can remove ARCH_REL_TYPE_ABS. ARCH_REL_TYPE_ABS is a >> bit misnomer as ports may check RELAVETIVE/GLOB_DAT/JUMP_SLOT which are >> not called "absolute relocations". (The patch is motivated by the arm64 >> port missing R_AARCH64_RELATIVE.) >> >> While here, replace "egrep" with "grep" as "egrep" is deprecated in GNU >> grep 3.7. >> >> Signed-off-by: Fangrui Song >> --- >> [...] >> > > Ping. Ping^2 :) >>> >>> Can you explain which ARCH_REL_TYPE_ABS can be removed with this change ? >>> How is the verification done if ARCH_REL_TYPE_ABS is removed ? >> >> All ARCH_REL_TYPE_ABS relocation types can be removed. As explained, the >> real intention is to check no dynamic relocation, and this is done by >> the new Well, there was a typo in my question, I wanted to ask 'why', not 'which'. >> >> cmd_vdso_check = if $(READELF) -rW $@ | grep -v _NONE | grep -q >> "R_\w*_"; \ >> >> in this patch. >> >> grep -v _NONE is to work around some GNU ld ports (and likely older releases >> of some ports even if their latest versions are fixed) which produce >> unneeded R_*_NONE dynamic relocations. > > Ping :) Ok, that seems to work on powerpc. Reviewed-by: Christophe Leroy
[GIT PULL] Please pull powerpc/linux.git powerpc-6.1-6 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull some more powerpc fixes for 6.1: The following changes since commit eb761a1760bf30cf64e98ee8d914866e62ec9e8a: powerpc: Fix writable sections being moved into the rodata region (2022-11-16 21:37:14 +1100) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-6.1-6 for you to fetch changes up to 2e7ec190a0e38aaa8a6d87fd5f804ec07947febc: powerpc/64s: Add missing declaration for machine_check_early_boot() (2022-11-26 00:25:32 +1100) - -- powerpc fixes for 6.1 #6 - Fix oops in 32-bit BPF tail call tests - Add missing declaration for machine_check_early_boot() Thanks to: Christophe Leroy, Naveen N. Rao. - -- Christophe Leroy (1): powerpc/bpf/32: Fix Oops on tail call tests Michael Ellerman (1): powerpc/64s: Add missing declaration for machine_check_early_boot() arch/powerpc/include/asm/interrupt.h | 1 + arch/powerpc/net/bpf_jit_comp32.c| 52 2 files changed, 22 insertions(+), 31 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmOMnkwACgkQUevqPMjh pYC6iA//cPx4MT/SddmFB4bC9Vxp0lBUxu9zcepbWdsvVK/X1+eSHtPVFdfXdxYq DhfHuEHizo6pKGYZnSYXjAG8/0pUQrKvnopgX0dNHtPvXSyRdeMyW10oiaweUa5v WSRhKf6Uy+9cw1ZS9wwAAtssiLXt2rmV/xEGb9hs7o8NAW27067LKfntCkd8++9M bs5V74c4X1WY1iJ86lxH3CYvOasZ/R7f46FeAu8KXX2n7+rlt1SOEnA2zaYtPYZ0 00dOCQpN5RuwCEjixJ9mFUZIJ+gL9AgjoOVF3lAGE6Ro2fyy/XRrh4BDnUCpfLhY vylKDdy6BACz9vxQiY/phvWn//66GaLb2wbf5vhbH7Wc91ouMJlwh9g0JvD6ViRb tAt4OOvRuOgenmpeigWUpJGpvX71Ib+sfPxpnmEwZDgTvt+aIxb0bgbEewgU/9Fz BD89DxjS3lsj+B9vUYhXOSdkKbJg3B4MLcQP//0E2QWiHMTvCSuB8xoWNK68J6/D 3DnMVJkbvb0IrF0Q0rTXBzj1aMosc3dbwM/ezu5Zs3DK7/GWcRw4noKyWUXI6/NF XB/R2xhxDnOyT/oZF0ssQzbA4rh1E4m9zj/RTrgn12SprT67p1sKQ5ppWPTTyd65 x3pCgocIzZvJc9S1ExmpZ9Seo9LQZxqXEsIzTqVU+5UjzFYC6tk= =3xA+ -END PGP SIGNATURE-
Re: [RFC PATCH] Disable Book-E KVM support?
Further information: https://lists.nongnu.org/archive/html/qemu-ppc/2022-12/msg0.html -- Christian On 04 December 2022 at 12:33 pm, Christian Zigotzky wrote: Hi All, We regularly use QEMU with KVM HV on our A-EON AmigaOne X5000 machines (book3e). It works fast and without any problems. Screenshot tour of QEMU/KVM HV on our AmigaOnes: - https://i.ibb.co/m4vgwNT/Kernel-6-1-rc3-Power-PC.png - https://i.ibb.co/Fwdjf7Z/Kernel-6-0-rc6-Power-PC.png - https://i.ibb.co/LYnJGdF/Kernel-5-19-rc5-Power-PC-2.png - https://i.ibb.co/vz1Wm5z/QEMU-with-9p-and-USB-sound.png - https://i.ibb.co/ScMjtp7/Kernel-5-17-alpha5-Power-PC.png - https://i.ibb.co/LQryFcK/Kernel-5-17-alpha4-Power-PC.png - https://i.ibb.co/kKLx9mf/Kernel-5-10-89-Power-PC.png - https://i.ibb.co/LRG1RDV/Kernel-5-10-89-Power-PC-2.png - https://i.ibb.co/NCFqY0k/QEMU-USB-Audio-on-Void-PPC.png - https://i.ibb.co/N1vL5Kd/Kernel-5-16-alpha3-Power-PC.png - https://i.ibb.co/SwjTyJk/Kernel-5-16-alpha1-Power-PC.png - https://i.ibb.co/LkpWNPx/Kernel-5-15-rc5-Power-PC.png - https://i.ibb.co/F8q1jDR/Kernel-5-15-rc4-Power-PC.png - https://i.ibb.co/zZxrbhV/Kernel-5-15-alpha6-Power-PC.png - https://i.pinimg.com/originals/a8/8b/42/a88b422870201887fc01ef44ddc1a235.png - https://i.pinimg.com/originals/57/d9/83/57d98324cd055b7ae00a87ad5a45a42f.png - https://i.pinimg.com/originals/f2/a5/e3/f2a5e34e2015381b0cb87cc51232a8bc.png - https://i.pinimg.com/originals/c5/0d/85/c50d85d7e8f20b4caa1a439faf751964.png - https://i.pinimg.com/originals/6e/3b/59/6e3b59fe10276c5644b15622a81f43f1.png We solved some issues: - https://forum.hyperion-entertainment.com/viewtopic.php?p=54357#p54357 - https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/236307.html - https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-September/249021.html - https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-May/229103.html - https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-January/223342.html - https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-August/216379.html - https://forum.hyperion-entertainment.com/viewtopic.php?f=58=4655=53393=KVM#p53393 - https://forum.hyperion-entertainment.com/viewtopic.php?p=53209#p53209 Please, do not remove KVM support from Book3e because it works without any problems and fast. We need it for our work. Thanks, Christian On 12/2/22 12:04, Daniel Henrique Barboza wrote: On 11/30/22 17:45, Crystal Wood wrote: On Mon, 2022-11-28 at 14:36 +1000, Nicholas Piggin wrote: BookE KVM is in a deep maintenance state, I'm not sure how much testing it gets. I don't have a test setup, and it does not look like QEMU has any HV architecture enabled. It hasn't been too painful but there are some cases where it causes a bit of problem not being able to test, e.g., https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-November/251452.html Time to begin removal process, or are there still people using it? I'm happy to to keep making occasional patches to try keep it going if there are people testing upstream. Getting HV support into QEMU would help with long term support, not sure how big of a job that would be. Not sure what you mean about QEMU not having e500 HV support? I don't know if it's bitrotted, but it's there. AFAIK all QEMU ppc boards, aside from pSeries and the Mac ones, are always used in emulated mode in an use case similar to what Bernhard described in his reply (run in x86 due to lack of ppc hardware). I am not aware of e500 KVM support in QEMU since I never attempted it. But yes, it is present, but poorly tested - if tested at all. And the reason why there's no push on our side to removed it from QEMU is because its code is so entwined with pSeries KVM that it would take too much effort. Do not take the presence of e500 KVM support in QEMU as a blocker to disabled it in the kernel. As far as the current QEMU usage goes e500 KVM can be removed without too much drama from our side. Cedric, do you have any opinions about it? I can not tell how much e500 KVM is used. The last report we had on the topic was : https://lore.kernel.org/all/R4OPHT$7f12c66d1107397991e0e4c978fe6...@locati.it/ and the last commit mentioning e500 VMs I could find is cb3778a045, which brings us back to QEMU 2.2 or so. It would be nice to 'quickly' check the state of the KVM stack on such boards and, may be, plan for more cleanups. Thanks, C. Daniel I don't know whether anyone is still using this, but if they are, it's probably e500mc and not e500v2 (which involved a bunch of hacks to get almost- sorta-usable performance out of hardware not designed
Re: [RESEND PATCH] soc: fsl: qe: request pins non-exclusively
On Sun, Dec 4, 2022, at 05:50, Dmitry Torokhov wrote:
>
> SoC team, the problematic patch has been in next for a while and it
> would be great to get the fix in to make sure the driver is not broken
> in 6.2. Thanks!
I have no problem taking thsi patch, but I get a merge conflict that
I'm not sure how to resolve:
@@@ -186,23 -182,27 +180,43 @@@ struct qe_pin *qe_pin_request(struct de
if (WARN_ON(!gc)) {
err = -ENODEV;
goto err0;
++<<< HEAD
+ }
+ qe_pin->gpiod = gpiod;
+ qe_pin->controller = gpiochip_get_data(gc);
+ /*
+ * FIXME: this gets the local offset on the gpio_chip so that the driver
+ * can manipulate pin control settings through its custom API. The real
+ * solution is to create a real pin control driver for this.
+ */
+ qe_pin->num = gpio_chip_hwgpio(gpiod);
+
+ if (!of_device_is_compatible(gc->of_node, "fsl,mpc8323-qe-pario-bank"))
{
+ pr_debug("%s: tried to get a non-qe pin\n", __func__);
+ gpiod_put(gpiod);
++===
+ } else if (!fwnode_device_is_compatible(gc->fwnode,
+ "fsl,mpc8323-qe-pario-bank")) {
+ dev_dbg(dev, "%s: tried to get a non-qe pin\n", __func__);
++>>> soc: fsl: qe: request pins non-exclusively
err = -EINVAL;
- goto err0;
+ } else {
+ qe_pin->controller = gpiochip_get_data(gc);
+ /*
+* FIXME: this gets the local offset on the gpio_chip so that
+* the driver can manipulate pin control settings through its
+* custom API. The real solution is to create a real pin control
+* driver for this.
+*/
+ qe_pin->num = desc_to_gpio(gpiod) - gc->base;
}
Could you rebase the patch on top of the soc/driver branch in the
soc tree and send the updated version?
Arnd
Re: [RFC PATCH] Disable Book-E KVM support?
Hi All, We regularly use QEMU with KVM HV on our A-EON AmigaOne X5000 machines (book3e). It works fast and without any problems. Screenshot tour of QEMU/KVM HV on our AmigaOnes: - https://i.ibb.co/m4vgwNT/Kernel-6-1-rc3-Power-PC.png - https://i.ibb.co/Fwdjf7Z/Kernel-6-0-rc6-Power-PC.png - https://i.ibb.co/LYnJGdF/Kernel-5-19-rc5-Power-PC-2.png - https://i.ibb.co/vz1Wm5z/QEMU-with-9p-and-USB-sound.png - https://i.ibb.co/ScMjtp7/Kernel-5-17-alpha5-Power-PC.png - https://i.ibb.co/LQryFcK/Kernel-5-17-alpha4-Power-PC.png - https://i.ibb.co/kKLx9mf/Kernel-5-10-89-Power-PC.png - https://i.ibb.co/LRG1RDV/Kernel-5-10-89-Power-PC-2.png - https://i.ibb.co/NCFqY0k/QEMU-USB-Audio-on-Void-PPC.png - https://i.ibb.co/N1vL5Kd/Kernel-5-16-alpha3-Power-PC.png - https://i.ibb.co/SwjTyJk/Kernel-5-16-alpha1-Power-PC.png - https://i.ibb.co/LkpWNPx/Kernel-5-15-rc5-Power-PC.png - https://i.ibb.co/F8q1jDR/Kernel-5-15-rc4-Power-PC.png - https://i.ibb.co/zZxrbhV/Kernel-5-15-alpha6-Power-PC.png - https://i.pinimg.com/originals/a8/8b/42/a88b422870201887fc01ef44ddc1a235.png - https://i.pinimg.com/originals/57/d9/83/57d98324cd055b7ae00a87ad5a45a42f.png - https://i.pinimg.com/originals/f2/a5/e3/f2a5e34e2015381b0cb87cc51232a8bc.png - https://i.pinimg.com/originals/c5/0d/85/c50d85d7e8f20b4caa1a439faf751964.png - https://i.pinimg.com/originals/6e/3b/59/6e3b59fe10276c5644b15622a81f43f1.png We solved some issues: - https://forum.hyperion-entertainment.com/viewtopic.php?p=54357#p54357 - https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/236307.html - https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-September/249021.html - https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-May/229103.html - https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-January/223342.html - https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-August/216379.html - https://forum.hyperion-entertainment.com/viewtopic.php?f=58=4655=53393=KVM#p53393 - https://forum.hyperion-entertainment.com/viewtopic.php?p=53209#p53209 Please, do not remove KVM support from Book3e because it works without any problems and fast. We need it for our work. Thanks, Christian On 12/2/22 12:04, Daniel Henrique Barboza wrote: On 11/30/22 17:45, Crystal Wood wrote: On Mon, 2022-11-28 at 14:36 +1000, Nicholas Piggin wrote: BookE KVM is in a deep maintenance state, I'm not sure how much testing it gets. I don't have a test setup, and it does not look like QEMU has any HV architecture enabled. It hasn't been too painful but there are some cases where it causes a bit of problem not being able to test, e.g., https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-November/251452.html Time to begin removal process, or are there still people using it? I'm happy to to keep making occasional patches to try keep it going if there are people testing upstream. Getting HV support into QEMU would help with long term support, not sure how big of a job that would be. Not sure what you mean about QEMU not having e500 HV support? I don't know if it's bitrotted, but it's there. AFAIK all QEMU ppc boards, aside from pSeries and the Mac ones, are always used in emulated mode in an use case similar to what Bernhard described in his reply (run in x86 due to lack of ppc hardware). I am not aware of e500 KVM support in QEMU since I never attempted it. But yes, it is present, but poorly tested - if tested at all. And the reason why there's no push on our side to removed it from QEMU is because its code is so entwined with pSeries KVM that it would take too much effort. Do not take the presence of e500 KVM support in QEMU as a blocker to disabled it in the kernel. As far as the current QEMU usage goes e500 KVM can be removed without too much drama from our side. Cedric, do you have any opinions about it? I can not tell how much e500 KVM is used. The last report we had on the topic was : https://lore.kernel.org/all/R4OPHT$7f12c66d1107397991e0e4c978fe6...@locati.it/ and the last commit mentioning e500 VMs I could find is cb3778a045, which brings us back to QEMU 2.2 or so. It would be nice to 'quickly' check the state of the KVM stack on such boards and, may be, plan for more cleanups. Thanks, C. Daniel I don't know whether anyone is still using this, but if they are, it's probably e500mc and not e500v2 (which involved a bunch of hacks to get almost- sorta-usable performance out of hardware not designed for virtualization). I do see that there have been a few recent patches on QEMU e500 (beyond the treewide cleanup type stuff), though I don't know
Re: [PATCH 0/7] powerpc/85xx: p2020: Create one unified machine description
On Friday 19 August 2022 21:15:50 Pali Rohár wrote:
> This patch series unifies all P2020 boards and machine descriptions into
> one generic unified P2020 machine description. With this generic machine
> description, kernel can boot on any P2020-based board with correct DTS
> file.
>
> Tested on CZ.NIC Turris 1.1 board with has Freescale P2020 processor.
> Kernel during booting correctly detects P2020 and prints:
> [0.00] Using Freescale P2020 machine description
>
> Pali Rohár (7):
> powerpc/85xx: Mark mpc85xx_rdb_pic_init() as static
> powerpc/85xx: Mark mpc85xx_ds_pic_init() as static
> powerpc/85xx: p2020: Move all P2020 machine descriptions to p2020.c
> powerpc/85xx: p2020: Unify .setup_arch and .init_IRQ callbacks
> powerpc/85xx: p2020: Define just one machine description
> powerpc/85xx: p2020: Enable boards by new config option CONFIG_P2020
> powerpc: dts: turris1x.dts: Remove "fsl,P2020RDB-PC" compatible string
Christophe, could you please summarize for me what is needed to change /
fix / adjust in this patch series? We had discussion about all patches
in this thread but I have not received reply for every my reaction. And
I'm not sure what to do and what not. So I can prepare a V2 version.
> arch/powerpc/boot/dts/turris1x.dts| 2 +-
> arch/powerpc/platforms/85xx/Kconfig | 22 ++-
> arch/powerpc/platforms/85xx/Makefile | 1 +
> arch/powerpc/platforms/85xx/mpc85xx_ds.c | 25 +--
> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 46 +-
> .../platforms/85xx/{mpc85xx_ds.c => p2020.c} | 144 +++---
> 6 files changed, 75 insertions(+), 165 deletions(-)
> copy arch/powerpc/platforms/85xx/{mpc85xx_ds.c => p2020.c} (53%)
>
> --
> 2.20.1
>
