* Re: [PATCH v2 1/3] watchdog: mpc8xxx: use dev_xxxx() instead of pr_xxxx()
From: Guenter Roeck @ 2018-09-14 17:25 UTC (permalink / raw)
To: Christophe Leroy
Cc: Wim Van Sebroeck, Radu Rendec, Rob Herring, Mark Rutland,
linux-kernel, linuxppc-dev, linux-watchdog, devicetree
In-Reply-To: <5edda1a360cf7867b98a72a1dfa22db3bd5ed7b4.1536931725.git.christophe.leroy@c-s.fr>
On Fri, Sep 14, 2018 at 01:31:59PM +0000, Christophe Leroy wrote:
> mpc8xxx watchdog driver is a platform device drivers, it is
> therefore possible to use dev_xxx() messaging rather than pr_xxx()
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/watchdog/mpc8xxx_wdt.c | 24 ++++++++++++------------
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/watchdog/mpc8xxx_wdt.c b/drivers/watchdog/mpc8xxx_wdt.c
> index aca2d6323f8a..1dcf5f10cdd9 100644
> --- a/drivers/watchdog/mpc8xxx_wdt.c
> +++ b/drivers/watchdog/mpc8xxx_wdt.c
> @@ -17,8 +17,6 @@
> * option) any later version.
> */
>
> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> -
> #include <linux/fs.h>
> #include <linux/init.h>
> #include <linux/kernel.h>
> @@ -137,26 +135,27 @@ static int mpc8xxx_wdt_probe(struct platform_device *ofdev)
> struct mpc8xxx_wdt_ddata *ddata;
> u32 freq = fsl_get_sys_freq();
> bool enabled;
> + struct device *dev = &ofdev->dev;
>
> - wdt_type = of_device_get_match_data(&ofdev->dev);
> + wdt_type = of_device_get_match_data(dev);
> if (!wdt_type)
> return -EINVAL;
>
> if (!freq || freq == -1)
> return -EINVAL;
>
> - ddata = devm_kzalloc(&ofdev->dev, sizeof(*ddata), GFP_KERNEL);
> + ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> if (!ddata)
> return -ENOMEM;
>
> res = platform_get_resource(ofdev, IORESOURCE_MEM, 0);
> - ddata->base = devm_ioremap_resource(&ofdev->dev, res);
> + ddata->base = devm_ioremap_resource(dev, res);
> if (IS_ERR(ddata->base))
> return PTR_ERR(ddata->base);
>
> enabled = in_be32(&ddata->base->swcrr) & SWCRR_SWEN;
> if (!enabled && wdt_type->hw_enabled) {
> - pr_info("could not be enabled in software\n");
> + dev_info(dev, "could not be enabled in software\n");
> return -ENODEV;
> }
>
> @@ -166,7 +165,7 @@ static int mpc8xxx_wdt_probe(struct platform_device *ofdev)
> ddata->wdd.ops = &mpc8xxx_wdt_ops,
>
> ddata->wdd.timeout = WATCHDOG_TIMEOUT;
> - watchdog_init_timeout(&ddata->wdd, timeout, &ofdev->dev);
> + watchdog_init_timeout(&ddata->wdd, timeout, dev);
>
> watchdog_set_nowayout(&ddata->wdd, nowayout);
>
> @@ -189,12 +188,13 @@ static int mpc8xxx_wdt_probe(struct platform_device *ofdev)
>
> ret = watchdog_register_device(&ddata->wdd);
> if (ret) {
> - pr_err("cannot register watchdog device (err=%d)\n", ret);
> + dev_err(dev, "cannot register watchdog device (err=%d)\n", ret);
> return ret;
> }
>
> - pr_info("WDT driver for MPC8xxx initialized. mode:%s timeout=%d sec\n",
> - reset ? "reset" : "interrupt", ddata->wdd.timeout);
> + dev_info(dev,
> + "WDT driver for MPC8xxx initialized. mode:%s timeout=%d sec\n",
> + reset ? "reset" : "interrupt", ddata->wdd.timeout);
>
> platform_set_drvdata(ofdev, ddata);
> return 0;
> @@ -204,8 +204,8 @@ static int mpc8xxx_wdt_remove(struct platform_device *ofdev)
> {
> struct mpc8xxx_wdt_ddata *ddata = platform_get_drvdata(ofdev);
>
> - pr_crit("Watchdog removed, expect the %s soon!\n",
> - reset ? "reset" : "machine check exception");
> + dev_crit(&ofdev->dev, "Watchdog removed, expect the %s soon!\n",
> + reset ? "reset" : "machine check exception");
> watchdog_unregister_device(&ddata->wdd);
>
> return 0;
> --
> 2.13.3
>
^ permalink raw reply
* Re: [PATCH v2 3/3] dt-bindings: watchdog: add mpc8xxx-wdt support
From: Guenter Roeck @ 2018-09-14 17:29 UTC (permalink / raw)
To: Christophe Leroy
Cc: Wim Van Sebroeck, Radu Rendec, Rob Herring, Mark Rutland,
linux-kernel, linuxppc-dev, linux-watchdog, devicetree
In-Reply-To: <e68ed01cdfba5b7610559607a3c706b294a216fc.1536931725.git.christophe.leroy@c-s.fr>
On Fri, Sep 14, 2018 at 01:32:03PM +0000, Christophe Leroy wrote:
> Add description of DT bindings for mpc8xxx-wdt driver which
> handles the CPU watchdog timer on the mpc83xx, mpc86xx and mpc8xx.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> .../devicetree/bindings/watchdog/mpc8xxx-wdt.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/mpc8xxx-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/mpc8xxx-wdt.txt b/Documentation/devicetree/bindings/watchdog/mpc8xxx-wdt.txt
> new file mode 100644
> index 000000000000..1d99e1e4d306
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/mpc8xxx-wdt.txt
> @@ -0,0 +1,25 @@
> +* Freescale mpc8xxx watchdog driver (For 83xx, 86xx and 8xx)
> +
> +Required properties:
> +- compatible: Shall contain one of the following:
> + "mpc83xx_wdt" for an mpc83xx
> + "fsl,mpc8610-wdt" for an mpc86xx
> + "fsl,mpc823-wdt" for an mpc8xx
> +- reg: base physical address and length of the area hosting the
> + watchdog registers.
> + On the 83xx, "Watchdog Timer Registers" area: <0x200 0x100>
> + On the 86xx, "Watchdog Timer Registers" area: <0xe4000 0x100>
> + On the 8xx, "General System Interface Unit" area: <0x0 0x10>
> +
Note for Rob: The above has been implemented for several years.
This is merely to document the current implementation.
Maybe "mpc83xx_wdt" should be deprecated and replaced, but I think
that should be a separate patch.
> +Optional properties:
> +- reg: additionnal physical address and length (4) of location of the
s/additionnal/additional/
> + Reset Status Register (called RSTRSCR on the mpc86xx)
> + On the 83xx, it is located at offset 0x910
> + On the 86xx, it is located at offset 0xe0094
> + On the 8xx, it is located at offset 0x288
> +
> +Example:
> + WDT: watchdog@0 {
> + compatible = "fsl,mpc823-wdt";
> + reg = <0x0 0x10 0x288 0x4>;
> + };
> --
> 2.13.3
>
^ permalink raw reply
* Re: [PATCH v2 2/3] watchdog: mpc8xxx: provide boot status
From: Guenter Roeck @ 2018-09-14 17:35 UTC (permalink / raw)
To: Christophe Leroy
Cc: Wim Van Sebroeck, Radu Rendec, Rob Herring, Mark Rutland,
linux-kernel, linuxppc-dev, linux-watchdog, devicetree
In-Reply-To: <4381d1515addcbc5329fbc955ef4a5074ab9afef.1536931725.git.christophe.leroy@c-s.fr>
On Fri, Sep 14, 2018 at 01:32:01PM +0000, Christophe Leroy wrote:
> mpc8xxx watchdog driver supports the following platforms:
> - mpc8xx
> - mpc83xx
> - mpc86xx
>
> Those three platforms have a 32 bits register which provides the
> reason of the last boot, including whether it was caused by the
> watchdog.
>
> mpc8xx: Register RSR, bit SWRS (bit 3)
> mpc83xx: Register RSR, bit SWRS (bit 28)
> mpc86xx: Register RSTRSCR, bit WDT_RR (bit 11)
>
> This patch maps the register as defined in the device tree and updates
> wdt.bootstatus based on the value of the watchdog related bit. Then
> the information can be retrieved via the WDIOC_GETBOOTSTATUS ioctl.
>
> Hereunder is an example of devicetree for mpc8xx,
> the Reset Status Register being at offset 0x288:
>
> WDT: watchdog@0 {
> compatible = "fsl,mpc823-wdt";
> reg = <0x0 0x10 0x288 0x4>;
> };
>
> On the mpc83xx, RSR is at offset 0x910
> On the mpc86xx, RSTRSCR is at offset 0xe0094
>
> Suggested-by: Radu Rendec <radu.rendec@gmail.com>
> Tested-by: Christophe Leroy <christophe.leroy@c-s.fr> # On mpc885
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> drivers/watchdog/mpc8xxx_wdt.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/watchdog/mpc8xxx_wdt.c b/drivers/watchdog/mpc8xxx_wdt.c
> index 1dcf5f10cdd9..4a4700458b17 100644
> --- a/drivers/watchdog/mpc8xxx_wdt.c
> +++ b/drivers/watchdog/mpc8xxx_wdt.c
> @@ -47,6 +47,7 @@ struct mpc8xxx_wdt {
> struct mpc8xxx_wdt_type {
> int prescaler;
> bool hw_enabled;
> + u32 rsr_mask;
> };
>
> struct mpc8xxx_wdt_ddata {
> @@ -136,6 +137,7 @@ static int mpc8xxx_wdt_probe(struct platform_device *ofdev)
> u32 freq = fsl_get_sys_freq();
> bool enabled;
> struct device *dev = &ofdev->dev;
> + u32 __iomem *rsr = NULL;
>
> wdt_type = of_device_get_match_data(dev);
> if (!wdt_type)
> @@ -159,6 +161,21 @@ static int mpc8xxx_wdt_probe(struct platform_device *ofdev)
> return -ENODEV;
> }
>
> + res = platform_get_resource(ofdev, IORESOURCE_MEM, 1);
> + if (res)
> + rsr = ioremap(res->start, resource_size(res));
> + if (rsr) {
This if() can be inside the first if(), and it should be something like
if (res) {
rsr = ioremap(res->start, resource_size(res));
if (!rsr) {
dev_err(...);
return -ENOMEM;
}
...
}
... because _if_ the resource is provided in dt it should be valid.
Thanks,
Guenter
> + bool status = in_be32(rsr) & wdt_type->rsr_mask;
> +
> + ddata->wdd.bootstatus = status ? WDIOF_CARDRESET : 0;
> + /* clear reset status bits related to watchdog timer */
> + out_be32(rsr, wdt_type->rsr_mask);
> + iounmap(rsr);
> +
> + dev_info(dev, "Last boot was %scaused by watchdog\n",
> + status ? "" : "not ");
> + }
> +
> spin_lock_init(&ddata->lock);
>
> ddata->wdd.info = &mpc8xxx_wdt_info,
> @@ -216,6 +233,7 @@ static const struct of_device_id mpc8xxx_wdt_match[] = {
> .compatible = "mpc83xx_wdt",
> .data = &(struct mpc8xxx_wdt_type) {
> .prescaler = 0x10000,
> + .rsr_mask = BIT(3), /* RSR Bit SWRS */
> },
> },
> {
> @@ -223,6 +241,7 @@ static const struct of_device_id mpc8xxx_wdt_match[] = {
> .data = &(struct mpc8xxx_wdt_type) {
> .prescaler = 0x10000,
> .hw_enabled = true,
> + .rsr_mask = BIT(20), /* RSTRSCR Bit WDT_RR */
> },
> },
> {
> @@ -230,6 +249,7 @@ static const struct of_device_id mpc8xxx_wdt_match[] = {
> .data = &(struct mpc8xxx_wdt_type) {
> .prescaler = 0x800,
> .hw_enabled = true,
> + .rsr_mask = BIT(28), /* RSR Bit SWRS */
> },
> },
> {},
> --
> 2.13.3
>
^ permalink raw reply
* Re: [PATCH v2 1/5] powerpc/Makefiles: Fix clang/llvm build
From: Nick Desaulniers @ 2018-09-14 17:41 UTC (permalink / raw)
To: joel; +Cc: linuxppc-dev, anton, anton
In-Reply-To: <20180914040649.1794-2-joel@jms.id.au>
On Thu, Sep 13, 2018 at 9:07 PM Joel Stanley <joel@jms.id.au> wrote:
>
> From: Anton Blanchard <anton@samba.org>
>
> Commit 15a3204d24a3 ("powerpc/64s: Set assembler machine type to POWER4")
> passes -mpower4 to the assembler. We have more recent instructions in our
> assembly files, but gas permits them. The clang/llvm integrated assembler
> is more strict, and we get a build failure.
Note that we disable clang's integrated assembler in the top level
Makefile for now, but it will still validate constraints for inline
assembly. Do you know which case is meant by "build failure?"
Is there a link to the Clang bug? It would be good to have that
context in the commit message.
>
> Fix this by calling the assembler with -mcpu=power8 if as supports it,
> else fall back to power4.
>
> Suggested-by: Nicholas Piggin <npiggin@gmail.com>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> arch/powerpc/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 11a1acba164a..a70639482053 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -238,7 +238,7 @@ cpu-as-$(CONFIG_4xx) += -Wa,-m405
> cpu-as-$(CONFIG_ALTIVEC) += $(call as-option,-Wa$(comma)-maltivec)
> cpu-as-$(CONFIG_E200) += -Wa,-me200
> cpu-as-$(CONFIG_E500) += -Wa,-me500
> -cpu-as-$(CONFIG_PPC_BOOK3S_64) += -Wa,-mpower4
> +cpu-as-$(CONFIG_PPC_BOOK3S_64) += $(call as-option,-Wa$(comma)-mpower8,-Wa$(comma)-mpower4)
> cpu-as-$(CONFIG_PPC_E500MC) += $(call as-option,-Wa$(comma)-me500mc)
>
> KBUILD_AFLAGS += $(cpu-as-y)
> --
> 2.17.1
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH v2 2/5] powerpc/boot: Fix crt0.S syntax for clang
From: Nick Desaulniers @ 2018-09-14 17:47 UTC (permalink / raw)
To: joel; +Cc: linuxppc-dev, anton
In-Reply-To: <20180914040649.1794-3-joel@jms.id.au>
On Thu, Sep 13, 2018 at 9:07 PM Joel Stanley <joel@jms.id.au> wrote:
>
> Clang's assembler does not like the syntax of the cmpdi:
>
> arch/powerpc/boot/crt0.S:168:22: error: unexpected modifier on variable reference
> cmpdi 12,RELACOUNT@l
> ^
> arch/powerpc/boot/crt0.S:168:11: error: unknown operand
> cmpdi 12,RELACOUNT@l
> ^
> Enclosing RELACOUNT in () makes it is happy. Tested with GCC 8 and Clang
> 8 (trunk).
>
> Reported to clang as https://bugs.llvm.org/show_bug.cgi?id=38945
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> v2: Fix for !powerpc64 too, add bug link to commit message
> ---
> arch/powerpc/boot/crt0.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S
> index dcf2f15e6797..e453e011d7e7 100644
> --- a/arch/powerpc/boot/crt0.S
> +++ b/arch/powerpc/boot/crt0.S
> @@ -80,7 +80,7 @@ p_base: mflr r10 /* r10 now points to runtime addr of p_base */
> lwz r9,4(r12) /* get RELA pointer in r9 */
> b 12f
> 11: addis r8,r8,(-RELACOUNT)@ha
> - cmpwi r8,RELACOUNT@l
> + cmpwi r8,(RELACOUNT)@l
> bne 12f
> lwz r0,4(r12) /* get RELACOUNT value in r0 */
> 12: addi r12,r12,8
> @@ -165,7 +165,7 @@ p_base: mflr r10 /* r10 now points to runtime addr of p_base */
> ld r13,8(r11) /* get RELA pointer in r13 */
> b 11f
> 10: addis r12,r12,(-RELACOUNT)@ha
> - cmpdi r12,RELACOUNT@l
> + cmpdi r12,(RELACOUNT)@l
Yep, as we can see above, when RELACOUNT is negated, it's wrapped in
parens. It's important for Clang's assembler to match GAS eventually,
but for now, this change simply cononicalizes all of the the
references to RELACOUNT in this source file.
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> bne 11f
> ld r8,8(r11) /* get RELACOUNT value in r8 */
> 11: addi r11,r11,16
> --
> 2.17.1
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH v2 3/5] powerpc/boot: Ensure _zimage_start is a weak symbol
From: Nick Desaulniers @ 2018-09-14 17:50 UTC (permalink / raw)
To: joel; +Cc: linuxppc-dev, anton
In-Reply-To: <20180914040649.1794-4-joel@jms.id.au>
On Thu, Sep 13, 2018 at 9:07 PM Joel Stanley <joel@jms.id.au> wrote:
>
> When building with clang crt0's _zimage_start is not marked weak, which
> breaks the build when linking the kernel image:
>
> $ objdump -t arch/powerpc/boot/crt0.o |grep _zimage_start$
> 0000000000000058 g .text 0000000000000000 _zimage_start
>
> ld: arch/powerpc/boot/wrapper.a(crt0.o): in function '_zimage_start':
> (.text+0x58): multiple definition of '_zimage_start';
> arch/powerpc/boot/pseries-head.o:(.text+0x0): first defined here
>
> Clang requires the .weak directive to appear after the symbol is
> declared. The binutils manual says:
>
> This directive sets the weak attribute on the comma separated list of
> symbol names. If the symbols do not already exist, they will be
> created.
>
> So it appears this is different with clang. The only reference I could
> see for this was an OpenBSD mailing list post[1].
>
> Changing it to be after the declaration fixes building with Clang, and
> still works with GCC.
>
> $ objdump -t arch/powerpc/boot/crt0.o |grep _zimage_start$
> 0000000000000058 w .text 0000000000000000 _zimage_start
>
> Reported to clang as https://bugs.llvm.org/show_bug.cgi?id=38921
>
> [1] https://groups.google.com/forum/#!topic/fa.openbsd.tech/PAgKKen2YCY
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> v2: Add comment explaining this is a workaround for clang. I have also
> opened a clang bug to see if they plan on changing behaviour
> ---
> arch/powerpc/boot/crt0.S | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S
> index e453e011d7e7..4e32bd251b99 100644
> --- a/arch/powerpc/boot/crt0.S
> +++ b/arch/powerpc/boot/crt0.S
> @@ -47,8 +47,10 @@ p_end: .long _end
> p_pstack: .long _platform_stack_top
> #endif
>
> - .weak _zimage_start
> .globl _zimage_start
> + /* Clang appears to require the .weak directive to be after the symbol
> + * is defined. See https://bugs.llvm.org/show_bug.cgi?id=38921 */
> + .weak _zimage_start
> _zimage_start:
> .globl _zimage_start_lib
> _zimage_start_lib:
> --
> 2.17.1
>
Sure, definitely a long tail of binutils/GAS functionality to match
from Clang's integrated assembler, but this is a small fix that
results in no functional change for GCC/binutils and enables
Clang/bfd.
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH v2 4/5] powerpc: Fix duplicate const clang warning in user access code
From: Nick Desaulniers @ 2018-09-14 17:57 UTC (permalink / raw)
To: joel; +Cc: linuxppc-dev, anton, anton
In-Reply-To: <20180914040649.1794-5-joel@jms.id.au>
On Thu, Sep 13, 2018 at 9:07 PM Joel Stanley <joel@jms.id.au> wrote:
>
> From: Anton Blanchard <anton@samba.org>
>
> This re-applies b91c1e3e7a6f which was reverted in f2ca80905929
> d466f6c5cac1 f84ed59a612d (powerpc/sparse: Constify the address pointer
> ...").
>
> We see a large number of duplicate const errors in the user access
> code when building with llvm/clang:
>
> include/linux/pagemap.h:576:8: warning: duplicate 'const' declaration specifier
> [-Wduplicate-decl-specifier]
> ret = __get_user(c, uaddr);
>
> The problem is we are doing const __typeof__(*(ptr)), which will hit the
> warning if ptr is marked const.
>
> Removing const does not seem to have any effect on GCC code generation.
I wouldn't expect it to for a local variable with such localized
usage. I myself am quite liberal in applying `const` to everything,
so I will try to fix this in Clang as well, but this should silence
the warning for users of older versions of Clang and results in no
functional change.
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> If we don't want to apply this, other options are suppressing the
> warning, or wait for a fix to land in clang
> (https://github.com/ClangBuiltLinux/linux/issues/52).
> ---
> arch/powerpc/include/asm/uaccess.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
> index bac225bb7f64..15bea9a0f260 100644
> --- a/arch/powerpc/include/asm/uaccess.h
> +++ b/arch/powerpc/include/asm/uaccess.h
> @@ -260,7 +260,7 @@ do { \
> ({ \
> long __gu_err; \
> __long_type(*(ptr)) __gu_val; \
> - const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
> + __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
> __chk_user_ptr(ptr); \
> if (!is_kernel_addr((unsigned long)__gu_addr)) \
> might_fault(); \
> @@ -274,7 +274,7 @@ do { \
> ({ \
> long __gu_err = -EFAULT; \
> __long_type(*(ptr)) __gu_val = 0; \
> - const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
> + __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
> might_fault(); \
> if (access_ok(VERIFY_READ, __gu_addr, (size))) { \
> barrier_nospec(); \
> @@ -288,7 +288,7 @@ do { \
> ({ \
> long __gu_err; \
> __long_type(*(ptr)) __gu_val; \
> - const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
> + __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
> __chk_user_ptr(ptr); \
> barrier_nospec(); \
> __get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
> --
> 2.17.1
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH v2 5/5] powerpc: Remove -mno-sched-epilog
From: Nick Desaulniers @ 2018-09-14 18:03 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: joel, linuxppc-dev
In-Reply-To: <20180914150629.405c12cc@roar.ozlabs.ibm.com>
On Thu, Sep 13, 2018 at 9:07 PM Joel Stanley <joel@jms.id.au> wrote:
> Last time this was proposed there was an issue reported:
>
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-September/121214.html
Heh, did PASemi sell boxes? Interesting, I'll have to read up on my history.
On Thu, Sep 13, 2018 at 10:06 PM Nicholas Piggin <npiggin@gmail.com> wrote:
> I don't think we can remove it completely because up to at least 4.6
> maybe 4.8 has problems.
>
> I have a few patches lying around I started looking at this... I'll
> send them.
Yeah, it's too bad the link above doesn't mention gcc version.
The gcc bugreport mentions fixing the bug in
7563dc64585324f443f5ac107eb6d89ee813a2d2, not sure how to check what
release version of gcc that is? (Do they tag releases?)
Nick, do you have a test case or more context about this still being
an issue in gcc 4.8? (maybe I should wait for your patch series?)
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* [GIT PULL] Devicetree fix for 4.19-rc
From: Rob Herring @ 2018-09-14 19:25 UTC (permalink / raw)
To: Linus Torvalds
Cc: linuxppc-dev, devicetree, linux-kernel@vger.kernel.org,
Frank Rowand
Linus,
Please pull. One regression for a 20 year old PowerMac.
Rob
The following changes since commit 0413bedabc886c3a56804d1c80a58e99077b1d91:
of: Add device_type access helper functions (2018-08-31 08:30:42 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
tags/devicetree-fixes-for-4.19-2
for you to fetch changes up to e54192b48da75f025ae4b277925eaf6aca1d13bd:
of: fix phandle cache creation for DTs with no phandles (2018-09-11
11:28:40 -0500)
----------------------------------------------------------------
Devicetree fixes for 4.19, part 2:
- Fix a regression on systems having a DT without any phandles which
happens on a PowerMac G3.
----------------------------------------------------------------
Rob Herring (1):
of: fix phandle cache creation for DTs with no phandles
drivers/of/base.c | 3 +++
1 file changed, 3 insertions(+)
^ permalink raw reply
* Re: [PATCH v3 0/6] powerpc/powernv/pci: Discover surprise-hotplugged PCIe devices during rescan
From: Sergey Miroshnichenko @ 2018-09-14 20:42 UTC (permalink / raw)
To: Oliver; +Cc: linuxppc-dev, linux, Benjamin Herrenschmidt
In-Reply-To: <CAOSf1CFnqtQbR793fLt01cXWSm9AvQa_pPG10ip_kyC+TgXcwQ@mail.gmail.com>
Hello Oliver,
On 9/12/18 12:49 PM, Oliver wrote:
> On Tue, Sep 11, 2018 at 9:56 PM, Sergey Miroshnichenko
> <s.miroshnichenko@yadro.com> wrote:
>> This patchset allows hotplugged PCIe devices to be enumerated during a bus
>> rescan being issued via sysfs on PowerNV platforms, when the "Presence
>> Detect Changed" interrupt is not available.
>
> Seems to be on par with the sysfs slot power hack that pnv_php uses.
>
Yes, ours is just for manual initiation of rescan, which helps us with
reliable detection of a bridge hotplug in our particular config.
>> As a first part of our work on adding support for hotplugging PCIe bridges
>> full of devices (without special requirement such as Hot-Plug Controller,
>> reservation of bus numbers and memory regions by firmware, etc.), this
>> serie is intended to solve the first two problems of the listed below:
>>
>> I PowerNV doesn't discover new hotplugged PCIe devices
>> II EEH is falsely triggered when poking empty slots during the PCIe rescan
>
> We avoid this problem in pnv_php by having OPAL to do the rescan and
> Linux requests
> a FDT fragment of everything under the slot. I'm don't think it's a
> great system, but
> it keeps firmware and the OS on the same page.
>
So if we re-enumerate the PCIe topology from the Linux, we must then
synchronize with the firmware? How would you recommend to approach that
for PowerNV and OPAL? Can we can find somewhere a list of criteria to
ensure that they are properly synced?
>> III The PCI subsystem is not prepared to runtime changes of BAR addresses
>> IV Device drivers don't track changes of their BAR addresses
>> V BARs of working devices don't move to make space for new ones
>
> I'm having a really hard to figuring out what would make this
> necessary. Keep in mind
> that each PHB has it's own set of bus numbers and it's own MMIO space,
> so it's not
> like you're short on either.
>
> How are you planning on making this sort of live-device-migration work? And what
> are you trying to do that makes the added complexity worth it?
>
With the "pci=realloc" command line argument and with the
PCI_REASSIGN_ALL_BUS flag the kernel doesn't rely on values of bus
numbers and BAR addresses provided by a firmware (OPAL via FDT in our
case, BIOS/UEFI/Coreboot for x86_64), but re-enumerates the PCIe
topology by its own means, and it arranges BARs quite compactly.
Let's say we have two bridges plugged into neighboring ports of the
root/PHB, each of them have a few NVME drives inserted and several empty
slots, when the system boots. Linux makes their bridge windows adjacent,
so if we plug in a new NVME into the first of them, there will be just
no free space to put its BARs.
Without considering memory pre-allocation, the only way we see to free
some space for new BARs is to move existing BARs of the second bridge
(in this example).
We've implemented a "firmware-independent" proof-of-concept (not
flawless, though, as you and Ben pointed out) and verified on
PowerNV+OPAL and x86_64 that a running NVME with an ongoing "fio"
benchmark always survives BAR movement during hotplug - of course after
applying a patch that pauses the NVME Linux driver during rescan. The
only visible effect is a bandwidth temporary drops to 0 for a second or
two, until NVME restarts. The same for a network adapter - an SSH
connection just freezes for a while.
This patchset is a first part of our work, and we've just published [1]
a second part (on BAR movement and pausing the drivers) for the
community to review, discuss and validate.
[1] https://www.spinics.net/lists/linux-pci/msg76211.html
Best regards,
Serge
>> Tested on:
>> - POWER8 PowerNV+OPAL ppc64le (our Vesnin server) w/ and w/o pci=realloc;
>> - POWER8 IBM 8247-42L (pSeries);
>> - POWER8 IBM 8247-42L (PowerNV+OPAL) w/ and w/o pci=realloc.
>>
>> Changes since v2:
>> - Don't reassign bus numbers on PowerNV by default (to retain the default
>> behavior), but only when pci=realloc is passed;
>> - Less code affected;
>> - pci_add_device_node_info is refactored with add_one_dev_pci_data;
>> - Minor code cleanup.
>>
>> Changes since v1:
>> - Fixed build for ppc64le and ppc64be when CONFIG_PCI_IOV is disabled;
>> - Fixed build for ppc64e when CONFIG_EEH is disabled;
>> - Fixed code style warnings.
>>
>> Sergey Miroshnichenko (6):
>> powerpc/pci: Access PCI config space directly w/o pci_dn
>> powerpc/pci: Create pci_dn on demand
>> powerpc/pci: Use DT to create pci_dn for root bridges only
>> powerpc/powernv/pci: Enable reassigning the bus numbers
>> PCI/powerpc/eeh: Add pcibios hooks for preparing to rescan
>> powerpc/pci: Reduce code duplication in pci_add_device_node_info
>>
>> arch/powerpc/include/asm/eeh.h | 2 +
>> arch/powerpc/kernel/eeh.c | 12 ++
>> arch/powerpc/kernel/pci_dn.c | 119 ++++++++++++++-----
>> arch/powerpc/kernel/rtas_pci.c | 97 ++++++++++-----
>> arch/powerpc/platforms/powernv/eeh-powernv.c | 22 ++++
>> arch/powerpc/platforms/powernv/pci.c | 64 ++++++----
>> drivers/pci/probe.c | 14 +++
>> include/linux/pci.h | 2 +
>> 8 files changed, 253 insertions(+), 79 deletions(-)
>>
>> --
>> 2.17.1
>>
^ permalink raw reply
* Re: [PATCH v2 5/5] powerpc: Remove -mno-sched-epilog
From: Nicholas Piggin @ 2018-09-14 20:43 UTC (permalink / raw)
To: Nick Desaulniers; +Cc: joel, linuxppc-dev, Segher Boessenkool
In-Reply-To: <CAKwvOdn-e60VSvUzmSLGx6yx-wUzSaEtdA3q5xyZ+G_++nQSJg@mail.gmail.com>
On Fri, 14 Sep 2018 11:03:38 -0700
Nick Desaulniers <ndesaulniers@google.com> wrote:
> On Thu, Sep 13, 2018 at 9:07 PM Joel Stanley <joel@jms.id.au> wrote:
> > Last time this was proposed there was an issue reported:
> >
> > https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-September/121214.html
>
> Heh, did PASemi sell boxes? Interesting, I'll have to read up on my history.
>
> On Thu, Sep 13, 2018 at 10:06 PM Nicholas Piggin <npiggin@gmail.com> wrote:
> > I don't think we can remove it completely because up to at least 4.6
> > maybe 4.8 has problems.
> >
> > I have a few patches lying around I started looking at this... I'll
> > send them.
>
> Yeah, it's too bad the link above doesn't mention gcc version.
>
> The gcc bugreport mentions fixing the bug in
> 7563dc64585324f443f5ac107eb6d89ee813a2d2, not sure how to check what
> release version of gcc that is? (Do they tag releases?)
I'm not sure, that's not in my gcc tree AFAIKS.
>
> Nick, do you have a test case or more context about this still being
> an issue in gcc 4.8? (maybe I should wait for your patch series?)
Sorry I forgot to cc you. This has links to some of the sched
epilog bugs.
https://marc.info/?l=linuxppc-embedded&m=153690223909654&w=2
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
From: Darren Hart @ 2018-09-14 20:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: viro, linux-fsdevel, Greg Kroah-Hartman, David S. Miller, devel,
linux-kernel, qat-linux, linux-crypto, linux-media, dri-devel,
linaro-mm-sig, amd-gfx, linux-input, linux-iio, linux-rdma,
linux-nvdimm, linux-nvme, linux-pci, platform-driver-x86,
linux-remoteproc, sparclinux, linux-scsi, linux-usb, linux-fbdev,
linuxppc-dev, linux-btrfs, ceph-devel, linux-wireless, netdev
In-Reply-To: <20180912151134.436719-1-arnd@arndb.de>
On Wed, Sep 12, 2018 at 05:08:52PM +0200, Arnd Bergmann wrote:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will ever run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
>
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
...
> drivers/platform/x86/wmi.c | 2 +-
...
> static void link_event_work(struct work_struct *work)
> diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
> index 04791ea5d97b..e4d0697e07d6 100644
> --- a/drivers/platform/x86/wmi.c
> +++ b/drivers/platform/x86/wmi.c
> @@ -886,7 +886,7 @@ static const struct file_operations wmi_fops = {
> .read = wmi_char_read,
> .open = wmi_char_open,
> .unlocked_ioctl = wmi_ioctl,
> - .compat_ioctl = wmi_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
For platform/drivers/x86:
Acked-by: Darren Hart (VMware) <dvhart@infradead.org>
As for a longer term solution, would it be possible to init fops in such
a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg
so we don't have to duplicate this boilerplate for every ioctl fops
structure?
--
Darren Hart
VMware Open Source Technology Center
^ permalink raw reply
* Re: [PATCH 4/5] powerpc/powernv/pci: Enable reassigning the bus numbers
From: Sergey Miroshnichenko @ 2018-09-14 20:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev; +Cc: linux
In-Reply-To: <84ca69bb04ccbdb4c0ae04ef7e272b11ad8fcf01.camel@kernel.crashing.org>
Hello Ben,
On 9/12/18 1:35 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2018-09-05 at 18:40 +0300, Sergey Miroshnichenko wrote:
>> PowerNV doesn't depend on PCIe topology info from DT anymore, and now
>> it is able to enumerate the fabric and assign the bus numbers.
>
> No it's not, at least unless we drop P7 support.
>
> P7 has constraints on the bus ranges being aligned power-of-two for the
> PE assignment to work, which is why we have to honor the firmware
> provided numbers.
>
> Additionally, this breaks the mapping between the firmware idea of the
> bus numbers and Linux idea. This will probably break all of the SR-IOV
> stuff.
>
Oh, I see. To make this more controllable and less intrusive I've bound
the PCI_REASSIGN_ALL_BUS flag to the "pci=realloc" command line argument
(in version 3 of this patchset) instead of the unconditional setting.
> Now we should probably fix it all by removing the FW bits completely
> and doing it all from Linux, though we really need to better handle how
> we deal with the segmented MMIO space.
>
> I would also be weary of what other parts of the code depends on that
> matching between the FW bdfn and the Linux bdfn.
>
This approach allows us to use the same in-kernel hotplug mechanisms for
PowerNV+OPAL and other platforms, so we are highly interested. Would you
kindly advice what are the essential parts to start with, maybe point
out some documentation on EEH segmentation and FW/OS sync?
> Cheers,
> Ben.
>
Best regards,
Serge
>> Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
>> ---
>> arch/powerpc/platforms/powernv/pci.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
>> index 6d4280086a08..f6eaca3123cd 100644
>> --- a/arch/powerpc/platforms/powernv/pci.c
>> +++ b/arch/powerpc/platforms/powernv/pci.c
>> @@ -1104,6 +1104,7 @@ void __init pnv_pci_init(void)
>> struct device_node *np;
>>
>> pci_add_flags(PCI_CAN_SKIP_ISA_ALIGN);
>> + pci_add_flags(PCI_REASSIGN_ALL_BUS);
>>
>> /* If we don't have OPAL, eg. in sim, just skip PCI probe */
>> if (!firmware_has_feature(FW_FEATURE_OPAL))
>
^ permalink raw reply
* Re: [PATCH v2 2/5] powerpc/boot: Fix crt0.S syntax for clang
From: Segher Boessenkool @ 2018-09-14 21:08 UTC (permalink / raw)
To: Nick Desaulniers; +Cc: joel, linuxppc-dev
In-Reply-To: <CAKwvOdmKvxmh+Vb1UcUzOsYOsK6gjn7v62X=SpwuhimBhdM7ng@mail.gmail.com>
On Fri, Sep 14, 2018 at 10:47:08AM -0700, Nick Desaulniers wrote:
> On Thu, Sep 13, 2018 at 9:07 PM Joel Stanley <joel@jms.id.au> wrote:
> > 10: addis r12,r12,(-RELACOUNT)@ha
> > - cmpdi r12,RELACOUNT@l
> > + cmpdi r12,(RELACOUNT)@l
>
> Yep, as we can see above, when RELACOUNT is negated, it's wrapped in
> parens.
The only thing that does is make it easier for humans to read; it means
exactly the same thing.
Segher
^ permalink raw reply
* Re: [PATCH v2 5/5] PCI/powerpc/eeh: Add pcibios hooks for preparing to rescan
From: Sergey Miroshnichenko @ 2018-09-14 21:12 UTC (permalink / raw)
To: benh; +Cc: Sam Bobroff, linuxppc-dev, linux
In-Reply-To: <baf90fe99f3644b33d50966b5721991a84369a7d.camel@au1.ibm.com>
On 9/12/18 1:39 PM, wrote:
> On Mon, 2018-09-10 at 19:00 +0300, Sergey Miroshnichenko wrote:
>>
>> Yes, missing a real EEH event is possible, unfortunately, and it is
>> indeed worth mentioning.
>>
>> To reduce this probability the next patchset I'll post in a few days
>> among other things puts all the affected device drivers to pause during
>> rescan, mainly because of moving BARs and bridge windows, but it will
>> also help here a bit.
>
> How do you deal with moving BARs etc... within the segmenting
> restrictions of EEH ?
>
Actually, [un]fortunately, we haven't encountered any segmenting issues
yet, but to move BARs we are using the same existing mechanism in Linux
kernel that re-enumerated the PCIe topology during startup with
"pci=realloc" and PCI_REASSIGN_ALL_BUS. What restrictions must be broken
to provoke a segmenting event?
Are there any other limitations on segmenting besides keeping all the
BARs of the PHB within its huge M32+M64 segments which are 2GiB+4GiB on
our setup?
> It's a horrible mess right now and I don't know if the current code can
> even work properly to be honest.
>
> Cheers,
> Ben.
>
>
Best regards,
Serge
^ permalink raw reply
* Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
From: Al Viro @ 2018-09-14 20:57 UTC (permalink / raw)
To: Darren Hart
Cc: Arnd Bergmann, linux-fsdevel, Greg Kroah-Hartman, David S. Miller,
devel, linux-kernel, qat-linux, linux-crypto, linux-media,
dri-devel, linaro-mm-sig, amd-gfx, linux-input, linux-iio,
linux-rdma, linux-nvdimm, linux-nvme, linux-pci,
platform-driver-x86, linux-remoteproc, sparclinux, linux-scsi,
linux-usb, linux-fbdev, linuxppc-dev, linux-btrfs, ceph-devel,
linux-wireless, netdev
In-Reply-To: <20180914203506.GE35251@wrath>
On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote:
> Acked-by: Darren Hart (VMware) <dvhart@infradead.org>
>
> As for a longer term solution, would it be possible to init fops in such
> a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg
> so we don't have to duplicate this boilerplate for every ioctl fops
> structure?
Bad idea, that... Because several years down the road somebody will add
an ioctl that takes an unsigned int for argument. Without so much as looking
at your magical mystery macro being used to initialize file_operations.
FWIW, I would name that helper in more blunt way - something like
compat_ioctl_only_compat_pointer_ioctls_here()...
^ permalink raw reply
* Re: [PATCH 3/3] scripts/dtc: Update to upstream version v1.4.7-14-gc86da84d30e4
From: Frank Rowand @ 2018-09-14 21:32 UTC (permalink / raw)
To: Rob Herring, devicetree; +Cc: linux-kernel, linux-arm-kernel, linuxppc-dev
In-Reply-To: <20180913202828.15372-3-robh@kernel.org>
On 09/13/18 13:28, Rob Herring wrote:
> Major changes are I2C and SPI bus checks, YAML output format (for
> future validation), some new libfdt functions, and more libfdt
> validation of dtbs.
>
> The YAML addition adds an optional dependency on libyaml. pkg-config is
> used to test for it and pkg-config became a kconfig dependency in 4.18.
For Ubuntu, the libyaml dependency is provided by the packages:
libyaml-0-2
libyaml-dev
-Frank
>
> This adds the following commits from upstream:
>
> c86da84d30e4 Add support for YAML encoded output
> 361b5e7d8067 Make type_marker_length helper public
< snip >
^ permalink raw reply
* Re: [PATCH v2 5/5] powerpc: Remove -mno-sched-epilog
From: Segher Boessenkool @ 2018-09-14 21:18 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: Nick Desaulniers, joel, linuxppc-dev
In-Reply-To: <20180915064305.65eea265@roar.ozlabs.ibm.com>
On Sat, Sep 15, 2018 at 06:43:05AM +1000, Nicholas Piggin wrote:
> On Fri, 14 Sep 2018 11:03:38 -0700
> Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> > On Thu, Sep 13, 2018 at 9:07 PM Joel Stanley <joel@jms.id.au> wrote:
> > > Last time this was proposed there was an issue reported:
> > >
> > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-September/121214.html
> >
> > Heh, did PASemi sell boxes? Interesting, I'll have to read up on my history.
> >
> > On Thu, Sep 13, 2018 at 10:06 PM Nicholas Piggin <npiggin@gmail.com> wrote:
> > > I don't think we can remove it completely because up to at least 4.6
> > > maybe 4.8 has problems.
> > >
> > > I have a few patches lying around I started looking at this... I'll
> > > send them.
> >
> > Yeah, it's too bad the link above doesn't mention gcc version.
> >
> > The gcc bugreport mentions fixing the bug in
> > 7563dc64585324f443f5ac107eb6d89ee813a2d2, not sure how to check what
> > release version of gcc that is? (Do they tag releases?)
>
> I'm not sure, that's not in my gcc tree AFAIKS.
This is a git hash in the kernel tree.
> > Nick, do you have a test case or more context about this still being
> > an issue in gcc 4.8? (maybe I should wait for your patch series?)
>
> Sorry I forgot to cc you. This has links to some of the sched
> epilog bugs.
>
> https://marc.info/?l=linuxppc-embedded&m=153690223909654&w=2
PR44199 was backported to 4.4 and PR52828 is fixed in 4.8.
Segher
^ permalink raw reply
* Re: [PATCH v2 5/5] powerpc: Remove -mno-sched-epilog
From: Nick Desaulniers @ 2018-09-14 22:20 UTC (permalink / raw)
To: segher; +Cc: Nicholas Piggin, joel, linuxppc-dev
In-Reply-To: <20180914211846.GU23155@gate.crashing.org>
On Fri, Sep 14, 2018 at 2:56 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Sat, Sep 15, 2018 at 06:43:05AM +1000, Nicholas Piggin wrote:
> > On Fri, 14 Sep 2018 11:03:38 -0700
> > Nick Desaulniers <ndesaulniers@google.com> wrote:
> >
> > > On Thu, Sep 13, 2018 at 9:07 PM Joel Stanley <joel@jms.id.au> wrote:
> > > > Last time this was proposed there was an issue reported:
> > > >
> > > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-September/121214.html
> > >
> > > Heh, did PASemi sell boxes? Interesting, I'll have to read up on my history.
> > >
> > > On Thu, Sep 13, 2018 at 10:06 PM Nicholas Piggin <npiggin@gmail.com> wrote:
> > > > I don't think we can remove it completely because up to at least 4.6
> > > > maybe 4.8 has problems.
> > > >
> > > > I have a few patches lying around I started looking at this... I'll
> > > > send them.
> > >
> > > Yeah, it's too bad the link above doesn't mention gcc version.
> > >
> > > The gcc bugreport mentions fixing the bug in
> > > 7563dc64585324f443f5ac107eb6d89ee813a2d2, not sure how to check what
> > > release version of gcc that is? (Do they tag releases?)
> >
> > I'm not sure, that's not in my gcc tree AFAIKS.
>
> This is a git hash in the kernel tree.
>
> > > Nick, do you have a test case or more context about this still being
> > > an issue in gcc 4.8? (maybe I should wait for your patch series?)
> >
> > Sorry I forgot to cc you. This has links to some of the sched
> > epilog bugs.
> >
> > https://marc.info/?l=linuxppc-embedded&m=153690223909654&w=2
Cool, cc me on the thread if you'd like me to add my reviewed-by tag
visibly on the thread.
>
> PR44199 was backported to 4.4 and PR52828 is fixed in 4.8.
Are those GCC versions? If so, what does that mean for the users of
the many GCC releases between 4.4 and 4.8?
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH v2 5/5] powerpc: Remove -mno-sched-epilog
From: Segher Boessenkool @ 2018-09-15 1:04 UTC (permalink / raw)
To: Nick Desaulniers; +Cc: Nicholas Piggin, joel, linuxppc-dev
In-Reply-To: <CAKwvOdmsSbrw7oLZHWTseqxLocPmuXV=cnxSi2zskAmd9zKo0Q@mail.gmail.com>
On Fri, Sep 14, 2018 at 03:20:18PM -0700, Nick Desaulniers wrote:
> On Fri, Sep 14, 2018 at 2:56 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > On Sat, Sep 15, 2018 at 06:43:05AM +1000, Nicholas Piggin wrote:
> > > On Fri, 14 Sep 2018 11:03:38 -0700
> > > Nick Desaulniers <ndesaulniers@google.com> wrote:
> > >
> > > Sorry I forgot to cc you. This has links to some of the sched
> > > epilog bugs.
> > >
> > > https://marc.info/?l=linuxppc-embedded&m=153690223909654&w=2
>
> Cool, cc me on the thread if you'd like me to add my reviewed-by tag
> visibly on the thread.
>
> > PR44199 was backported to 4.4 and PR52828 is fixed in 4.8.
>
> Are those GCC versions? If so, what does that mean for the users of
> the many GCC releases between 4.4 and 4.8?
Yes, GCC bug 44199 was fixed in GCC version 4.4, etc. It of course also
is fixed in all later versions; so GCC releases between 4.4 and 4.8 have
the fix for PR44199 but not that for PR52828.
I didn't check exactly what 4.4.x versions have the fix, etc. I always
assume anyone using x.y.z uses the highest z available.
I don't know if those are the only fixes you need; those are the two
bugs mentioned in Nicholas' patch (that MARC link above).
Segher
^ permalink raw reply
* [PATCH -next] fsl/qe: Fix copy-paste error in ucc_get_tdm_sync_shift
From: YueHaibing @ 2018-09-15 11:10 UTC (permalink / raw)
To: qiang.zhao, leoyang.li
Cc: linux-kernel, linux-arm-kernel, linuxppc-dev, YueHaibing
if 'mode' is COMM_DIR_TX, 'shift' should use TX_SYNC_SHIFT_BASE
Fixes: bb8b2062aff3 ("fsl/qe: setup clock source for TDM mode")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/soc/fsl/qe/ucc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/qe/ucc.c b/drivers/soc/fsl/qe/ucc.c
index c646d87..681f7d4 100644
--- a/drivers/soc/fsl/qe/ucc.c
+++ b/drivers/soc/fsl/qe/ucc.c
@@ -626,7 +626,7 @@ static u32 ucc_get_tdm_sync_shift(enum comm_dir mode, u32 tdm_num)
{
u32 shift;
- shift = (mode == COMM_DIR_RX) ? RX_SYNC_SHIFT_BASE : RX_SYNC_SHIFT_BASE;
+ shift = (mode == COMM_DIR_RX) ? RX_SYNC_SHIFT_BASE : TX_SYNC_SHIFT_BASE;
shift -= tdm_num * 2;
return shift;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2 3/5] drivers: clk-qoriq: Add clockgen support for lx2160a
From: Scott Wood @ 2018-09-15 19:24 UTC (permalink / raw)
To: Vabhav Sharma, sudeep.holla, linux-kernel, devicetree, robh+dt,
mark.rutland, linuxppc-dev, linux-arm-kernel, mturquette, sboyd,
rjw, viresh.kumar, linux-clk, linux-pm, linux-kernel-owner,
catalin.marinas, will.deacon, gregkh, arnd, kstewart,
yamada.masahiro
Cc: linux, V.Sethi, udit.kumar, Yogesh Gaur, Tang Yuantian
In-Reply-To: <1536871075-3732-4-git-send-email-vabhav.sharma@nxp.com>
On Fri, 2018-09-14 at 02:07 +0530, Vabhav Sharma wrote:
> From: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
>
> Add clockgen support for lx2160a.
> Added entry for compat 'fsl,lx2160a-clockgen'.
>
> Signed-off-by: Tang Yuantian <andy.tang@nxp.com>
> Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
> Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
> Acked-by: Stephen Boyd <sboyd@kernel.org>
> ---
> drivers/clk/clk-qoriq.c | 14 +++++++++++++-
> drivers/cpufreq/qoriq-cpufreq.c | 1 +
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
> index 3a1812f..e9ae70b 100644
> --- a/drivers/clk/clk-qoriq.c
> +++ b/drivers/clk/clk-qoriq.c
> @@ -79,7 +79,7 @@ struct clockgen_chipinfo {
> const struct clockgen_muxinfo *cmux_groups[2];
> const struct clockgen_muxinfo *hwaccel[NUM_HWACCEL];
> void (*init_periph)(struct clockgen *cg);
> - int cmux_to_group[NUM_CMUX]; /* -1 terminates if fewer than
> NUM_CMUX */
> + int cmux_to_group[NUM_CMUX+1]; /* -1 terminate if fewer to
> NUM_CMUX+1 */
You need to add the -1 terminator to p4080, and remove the "if fewer" comment
since the whole point of this is that every array gets -1 terminated.
Why did you change "terminates" to "terminate" and "than" to "to"?
This +1 change should be a separate patch from lx2160a support.
-Scott
^ permalink raw reply
* Re: [PATCH] kdb: use correct pointer when 'btc' calls 'btt'
From: Daniel Thompson @ 2018-09-16 19:06 UTC (permalink / raw)
To: Christophe Leroy
Cc: Jason Wessel, Michael Ellerman, linux-kernel, linuxppc-dev,
kgdb-bugreport, stable, me
In-Reply-To: <ff05bd36b338f4f914780176e9eba8138e1b254b.1536927765.git.christophe.leroy@c-s.fr>
On Fri, Sep 14, 2018 at 12:35:44PM +0000, Christophe Leroy wrote:
> On a powerpc 8xx, 'btc' fails as follows:
>
> Entering kdb (current=0x(ptrval), pid 282) due to Keyboard Entry
> kdb> btc
> btc: cpu status: Currently on cpu 0
> Available cpus: 0
> kdb_getarea: Bad address 0x0
>
> when booting the kernel with 'debug_boot_weak_hash', it fails as well
>
> Entering kdb (current=0xba99ad80, pid 284) due to Keyboard Entry
> kdb> btc
> btc: cpu status: Currently on cpu 0
> Available cpus: 0
> kdb_getarea: Bad address 0xba99ad80
>
> On other platforms, Oopses have been observed too, see
> https://github.com/linuxppc/linux/issues/139
>
> This is due to btc calling 'btt' with %p pointer as an argument.
>
> This patch replaces %p by %px to get the real pointer value as
> expected by 'btt'
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: <stable@vger.kernel.org> # 4.15+
Would a Fixes: be better here?
Fixes: ad67b74d2469d9b82 ("printk: hash addresses printed with %p")
No blame attached to Tobin, but the fixes makes it super clear what
changed and why this breaks kdb (which was not explicitly called out
the patch description).
Daniel.
> ---
> kernel/debug/kdb/kdb_bt.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/debug/kdb/kdb_bt.c b/kernel/debug/kdb/kdb_bt.c
> index 6ad4a9fcbd6f..7921ae4fca8d 100644
> --- a/kernel/debug/kdb/kdb_bt.c
> +++ b/kernel/debug/kdb/kdb_bt.c
> @@ -179,14 +179,14 @@ kdb_bt(int argc, const char **argv)
> kdb_printf("no process for cpu %ld\n", cpu);
> return 0;
> }
> - sprintf(buf, "btt 0x%p\n", KDB_TSK(cpu));
> + sprintf(buf, "btt 0x%px\n", KDB_TSK(cpu));
> kdb_parse(buf);
> return 0;
> }
> kdb_printf("btc: cpu status: ");
> kdb_parse("cpu\n");
> for_each_online_cpu(cpu) {
> - sprintf(buf, "btt 0x%p\n", KDB_TSK(cpu));
> + sprintf(buf, "btt 0x%px\n", KDB_TSK(cpu));
> kdb_parse(buf);
> touch_nmi_watchdog();
> }
> --
> 2.13.3
>
^ permalink raw reply
* Re: [PATCH] powerpc/tm: Fix HFSCR bit for no suspend case
From: Breno Leitao @ 2018-09-16 20:21 UTC (permalink / raw)
To: linuxppc-dev, Michael Ellerman, npiggin, Michael Neuling
In-Reply-To: <20180911030756.19583-1-mikey@neuling.org>
On 09/11/2018 12:07 AM, Michael Neuling wrote:
> Currently on P9N DD2.1 we end up taking infinite TM facility
> unavailable exceptions on the first TM usage by userspace.
>
> In the special case of TM no suspend (P9N DD2.1), Linux is told TM is
> off via CPU dt-ftrs but told to (partially) use it via
> OPAL_REINIT_CPUS_TM_SUSPEND_DISABLED. So HFSCR[TM] will be off from
> dt-ftrs but we need to turn it on for the no suspend case.
>
> This patch fixes this by enabling HFSCR TM in this case.
>
> Cc: stable@vger.kernel.org # 4.15+
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Tested-by: Breno Leitao <leitao@debian.org>
^ permalink raw reply
* Re: [PATCH] kdb: use correct pointer when 'btc' calls 'btt'
From: Tobin C. Harding @ 2018-09-16 22:18 UTC (permalink / raw)
To: Daniel Thompson
Cc: Christophe Leroy, Jason Wessel, Michael Ellerman, linux-kernel,
linuxppc-dev, kgdb-bugreport, stable
In-Reply-To: <20180916190610.vzqxwps7zqy2zc6o@holly.lan>
On Sun, Sep 16, 2018 at 12:06:10PM -0700, Daniel Thompson wrote:
> On Fri, Sep 14, 2018 at 12:35:44PM +0000, Christophe Leroy wrote:
> > On a powerpc 8xx, 'btc' fails as follows:
> >
> > Entering kdb (current=0x(ptrval), pid 282) due to Keyboard Entry
> > kdb> btc
> > btc: cpu status: Currently on cpu 0
> > Available cpus: 0
> > kdb_getarea: Bad address 0x0
> >
> > when booting the kernel with 'debug_boot_weak_hash', it fails as well
> >
> > Entering kdb (current=0xba99ad80, pid 284) due to Keyboard Entry
> > kdb> btc
> > btc: cpu status: Currently on cpu 0
> > Available cpus: 0
> > kdb_getarea: Bad address 0xba99ad80
> >
> > On other platforms, Oopses have been observed too, see
> > https://github.com/linuxppc/linux/issues/139
> >
> > This is due to btc calling 'btt' with %p pointer as an argument.
> >
> > This patch replaces %p by %px to get the real pointer value as
> > expected by 'btt'
> >
> > Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> > Cc: <stable@vger.kernel.org> # 4.15+
>
> Would a Fixes: be better here?
> Fixes: ad67b74d2469d9b82 ("printk: hash addresses printed with %p")
>
> No blame attached to Tobin, but the fixes makes it super clear what
:)
> changed and why this breaks kdb (which was not explicitly called out
> the patch description).
>
>
> Daniel.
^ 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