* 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
* Re: [PATCH 03/12] powerpc/64s/hash: move POWER5 < DD2.1 slbie workaround where it is needed
From: kbuild test robot @ 2018-09-16 22:06 UTC (permalink / raw)
To: Nicholas Piggin
Cc: kbuild-all, linuxppc-dev, Aneesh Kumar K . V, Nicholas Piggin
In-Reply-To: <20180914153056.3644-4-npiggin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7968 bytes --]
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.19-rc3 next-20180913]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/SLB-miss-conversion-to-C-and-SLB-optimisations/20180917-015458
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=powerpc
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
Note: the linux-review/Nicholas-Piggin/SLB-miss-conversion-to-C-and-SLB-optimisations/20180917-015458 HEAD b26bd44c74488169a0fd19eef43ea3db189a207d builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
arch/powerpc/mm/slb.c: In function 'switch_slb':
>> arch/powerpc/mm/slb.c:258:4: error: 'slbie_data' may be used uninitialized in this function [-Werror=maybe-uninitialized]
asm volatile("slbie %0" : : "r" (slbie_data));
^~~
cc1: all warnings being treated as errors
vim +/slbie_data +258 arch/powerpc/mm/slb.c
465ccab9 arch/powerpc/mm/slb.c will schmidt 2007-10-31 224
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 225 /* Flush all user entries from the segment table of the current processor. */
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 226 void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 227 {
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 228 unsigned long offset;
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 229 unsigned long pc = KSTK_EIP(tsk);
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 230 unsigned long stack = KSTK_ESP(tsk);
de4376c2 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 231 unsigned long exec_base;
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 232
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 233 /*
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 234 * We need interrupts hard-disabled here, not just soft-disabled,
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 235 * so that a PMU interrupt can't occur, which might try to access
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 236 * user memory (to get a stack trace) and possible cause an SLB miss
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 237 * which would update the slb_cache/slb_cache_ptr fields in the PACA.
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 238 */
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 239 hard_irq_disable();
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 240 offset = get_paca()->slb_cache_ptr;
44ae3ab3 arch/powerpc/mm/slb.c Matt Evans 2011-04-06 241 if (!mmu_has_feature(MMU_FTR_NO_SLBIE_B) &&
f66bce5e arch/powerpc/mm/slb.c Olof Johansson 2007-10-16 242 offset <= SLB_CACHE_ENTRIES) {
6697d605 arch/powerpc/mm/slb.c Nicholas Piggin 2018-09-15 243 unsigned long slbie_data;
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 244 int i;
6697d605 arch/powerpc/mm/slb.c Nicholas Piggin 2018-09-15 245
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 246 asm volatile("isync" : : : "memory");
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 247 for (i = 0; i < offset; i++) {
1189be65 arch/powerpc/mm/slb.c Paul Mackerras 2007-10-11 248 slbie_data = (unsigned long)get_paca()->slb_cache[i]
1189be65 arch/powerpc/mm/slb.c Paul Mackerras 2007-10-11 249 << SID_SHIFT; /* EA */
1189be65 arch/powerpc/mm/slb.c Paul Mackerras 2007-10-11 250 slbie_data |= user_segment_size(slbie_data)
1189be65 arch/powerpc/mm/slb.c Paul Mackerras 2007-10-11 251 << SLBIE_SSIZE_SHIFT;
1189be65 arch/powerpc/mm/slb.c Paul Mackerras 2007-10-11 252 slbie_data |= SLBIE_C; /* C set for user addresses */
1189be65 arch/powerpc/mm/slb.c Paul Mackerras 2007-10-11 253 asm volatile("slbie %0" : : "r" (slbie_data));
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 254 }
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 255
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 256 /* Workaround POWER5 < DD2.1 issue */
6697d605 arch/powerpc/mm/slb.c Nicholas Piggin 2018-09-15 257 if (!cpu_has_feature(CPU_FTR_ARCH_207S) && offset == 1)
1189be65 arch/powerpc/mm/slb.c Paul Mackerras 2007-10-11 @258 asm volatile("slbie %0" : : "r" (slbie_data));
6697d605 arch/powerpc/mm/slb.c Nicholas Piggin 2018-09-15 259
6697d605 arch/powerpc/mm/slb.c Nicholas Piggin 2018-09-15 260 asm volatile("isync" : : : "memory");
6697d605 arch/powerpc/mm/slb.c Nicholas Piggin 2018-09-15 261 } else {
6697d605 arch/powerpc/mm/slb.c Nicholas Piggin 2018-09-15 262 __slb_flush_and_rebolt();
c15c9670 arch/powerpc/mm/slb.c Nicholas Piggin 2018-09-15 263 }
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 264
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 265 get_paca()->slb_cache_ptr = 0;
52b1e665 arch/powerpc/mm/slb.c Aneesh Kumar K.V 2017-03-22 266 copy_mm_to_paca(mm);
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 267
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 268 /*
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 269 * preload some userspace segments into the SLB.
de4376c2 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 270 * Almost all 32 and 64bit PowerPC executables are linked at
de4376c2 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 271 * 0x10000000 so it makes sense to preload this segment.
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 272 */
de4376c2 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 273 exec_base = 0x10000000;
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 274
5eb9bac0 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 275 if (is_kernel_addr(pc) || is_kernel_addr(stack) ||
de4376c2 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 276 is_kernel_addr(exec_base))
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 277 return;
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 278
5eb9bac0 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 279 slb_allocate(pc);
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 280
5eb9bac0 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 281 if (!esids_match(pc, stack))
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 282 slb_allocate(stack);
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 283
de4376c2 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 284 if (!esids_match(pc, exec_base) &&
de4376c2 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 285 !esids_match(stack, exec_base))
de4376c2 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 286 slb_allocate(exec_base);
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 287 }
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 288
:::::: The code at line 258 was first introduced by commit
:::::: 1189be6508d45183013ddb82b18f4934193de274 [POWERPC] Use 1TB segments
:::::: TO: Paul Mackerras <paulus@samba.org>
:::::: CC: Paul Mackerras <paulus@samba.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 23944 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: remove old GCC version checks
From: Joel Stanley @ 2018-09-17 2:31 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <20180914050854.6214-2-npiggin@gmail.com>
On Fri, 14 Sep 2018 at 14:39, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> GCC 4.6 is the minimum supported now.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
^ 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