1. 31 Mar, 2018 14 commits
    • Michael Neuling's avatar
      powerpc/eeh: Fix race with driver un/bind · f0295e04
      Michael Neuling authored
      The current EEH callbacks can race with a driver unbind. This can
      result in a backtraces like this:
      
        EEH: Frozen PHB#0-PE#1fc detected
        EEH: PE location: S000009, PHB location: N/A
        CPU: 2 PID: 2312 Comm: kworker/u258:3 Not tainted 4.15.6-openpower1 #2
        Workqueue: nvme-wq nvme_reset_work [nvme]
        Call Trace:
          dump_stack+0x9c/0xd0 (unreliable)
          eeh_dev_check_failure+0x420/0x470
          eeh_check_failure+0xa0/0xa4
          nvme_reset_work+0x138/0x1414 [nvme]
          process_one_work+0x1ec/0x328
          worker_thread+0x2e4/0x3a8
          kthread+0x14c/0x154
          ret_from_kernel_thread+0x5c/0xc8
        nvme nvme1: Removing after probe failure status: -19
        <snip>
        cpu 0x23: Vector: 300 (Data Access) at [c000000ff50f3800]
            pc: c0080000089a0eb0: nvme_error_detected+0x4c/0x90 [nvme]
            lr: c000000000026564: eeh_report_error+0xe0/0x110
            sp: c000000ff50f3a80
           msr: 9000000000009033
           dar: 400
         dsisr: 40000000
          current = 0xc000000ff507c000
          paca    = 0xc00000000fdc9d80   softe: 0        irq_happened: 0x01
            pid   = 782, comm = eehd
        Linux version 4.15.6-openpower1 (smc@smc-desktop) (gcc version 6.4.0 (Buildroot 2017.11.2-00008-g4b6188e)) #2 SM                                             P Tue Feb 27 12:33:27 PST 2018
        enter ? for help
          eeh_report_error+0xe0/0x110
          eeh_pe_dev_traverse+0xc0/0xdc
          eeh_handle_normal_event+0x184/0x4c4
          eeh_handle_event+0x30/0x288
          eeh_event_handler+0x124/0x170
          kthread+0x14c/0x154
          ret_from_kernel_thread+0x5c/0xc8
      
      The first part is an EEH (on boot), the second half is the resulting
      crash. nvme probe starts the nvme_reset_work() worker thread. This
      worker thread starts touching the device which see a device error
      (EEH) and hence queues up an event in the powerpc EEH worker
      thread. nvme_reset_work() then continues and runs
      nvme_remove_dead_ctrl_work() which results in unbinding the driver
      from the device and hence releases all resources. At the same time,
      the EEH worker thread starts doing the EEH .error_detected() driver
      callback, which no longer works since the resources have been freed.
      
      This fixes the problem in the same way the generic PCIe AER code (in
      drivers/pci/pcie/aer/aerdrv_core.c) does. It makes the EEH code hold
      the device_lock() while performing the driver EEH callbacks and
      associated code. This ensures either the callbacks are no longer
      register, or if they are registered the driver will not be removed
      from underneath us.
      
      This has been broken forever. The EEH call backs were first introduced
      in 2005 (in 77bd7415) but it's not clear if a lock was needed back
      then.
      
      Fixes: 77bd7415 ("[PATCH] powerpc: PCI Error Recovery: PPC64 core recovery routines")
      Cc: stable@vger.kernel.org # v2.6.16+
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Reviewed-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      f0295e04
    • Thiago Jung Bauermann's avatar
      powerpc/kexec_file: Fix error code when trying to load kdump kernel · bf8a1abc
      Thiago Jung Bauermann authored
      kexec_file_load() on powerpc doesn't support kdump kernels yet, so it
      returns -ENOTSUPP in that case.
      
      I've recently learned that this errno is internal to the kernel and
      isn't supposed to be exposed to userspace. Therefore, change to
      -EOPNOTSUPP which is defined in an uapi header.
      
      This does indeed make kexec-tools happier. Before the patch, on
      ppc64le:
      
        # ~bauermann/src/kexec-tools/build/sbin/kexec -s -p /boot/vmlinuz
        kexec_file_load failed: Unknown error 524
      
      After the patch:
      
        # ~bauermann/src/kexec-tools/build/sbin/kexec -s -p /boot/vmlinuz
        kexec_file_load failed: Operation not supported
      
      Fixes: a0458284 ("powerpc: Add support code for kexec_file_load()")
      Cc: stable@vger.kernel.org # v4.10+
      Reported-by: default avatarDave Young <dyoung@redhat.com>
      Signed-off-by: default avatarThiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
      Reviewed-by: default avatarSimon Horman <horms@verge.net.au>
      Reviewed-by: default avatarDave Young <dyoung@redhat.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      bf8a1abc
    • Jonathan Neuschäfer's avatar
      powerpc/mm/32: Remove the reserved memory hack · 7e140591
      Jonathan Neuschäfer authored
      This hack, introduced in commit c5df7f77 ("powerpc: allow ioremap
      within reserved memory regions") is now unnecessary.
      Signed-off-by: default avatarJonathan Neuschäfer <j.neuschaefer@gmx.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      7e140591
    • Jonathan Neuschäfer's avatar
      powerpc/wii: Don't rely on the reserved memory hack · 57deb8fe
      Jonathan Neuschäfer authored
      Because the two memory blocks (usually called MEM1 and MEM2) are not
      merged anymore, __request_region in kernel/resource.c will correctly
      allow reserving regions in the physical address space between MEM1 and
      MEM2, where many important peripherals are (GPIO, MMC, USB, ...).
      
      A previous change to __ioremap_caller in arch/powerpc/mm/pgtable_32.c
      ensures that multiple memblocks are properly considered in ioremap; this
      makes it unnecessary to set __allow_ioremap_reserved.
      Signed-off-by: default avatarJonathan Neuschäfer <j.neuschaefer@gmx.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      57deb8fe
    • Jonathan Neuschäfer's avatar
      powerpc/mm/32: Use page_is_ram to check for RAM · 2bbf6326
      Jonathan Neuschäfer authored
      On systems where there is MMIO space between different blocks of RAM in
      the physical address space, __ioremap_caller did not allow mapping these
      MMIO areas, because they were below the end RAM and thus considered RAM
      as well.  Use the memblock-based page_is_ram function, which returns
      false for such MMIO holes.
      
      v2:
        Keep the check for p < virt_to_phys(high_memory). On 32-bit systems
        with high memory (memory above physical address 4GiB), the high memory
        is expected to be available though ioremap. The high_memory variable
        marks the end of low memory; comparing against it means that only
        ioremap requests for low RAM will be denied.
        Reported by Michael Ellerman.
      Signed-off-by: default avatarJonathan Neuschäfer <j.neuschaefer@gmx.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      2bbf6326
    • Jonathan Neuschäfer's avatar
      powerpc/mm: Use memblock API for PPC32 page_is_ram · f65e67c7
      Jonathan Neuschäfer authored
      To support accurate checking for different blocks of memory on PPC32,
      use the same memblock-based approach that's already used on PPC64 also
      on PPC32.
      Signed-off-by: default avatarJonathan Neuschäfer <j.neuschaefer@gmx.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      f65e67c7
    • Jonathan Neuschäfer's avatar
      powerpc/mm: Simplify page_is_ram by using memblock_is_memory · 2615c93e
      Jonathan Neuschäfer authored
      Instead of open-coding the search in page_is_ram, call memblock_is_memory.
      Signed-off-by: default avatarJonathan Neuschäfer <j.neuschaefer@gmx.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      2615c93e
    • Jonathan Neuschäfer's avatar
      powerpc/wii.dts: Add drive slot LED · 041413b8
      Jonathan Neuschäfer authored
      The Wii has a blue LED in the disk drive slot, which is controlled via a
      GPIO line. Add this LED to wii.dts, and mark it as a panic-indicator.
      Signed-off-by: default avatarJonathan Neuschäfer <j.neuschaefer@gmx.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      041413b8
    • Jonathan Neuschäfer's avatar
      powerpc/wii.dts: Add GPIO line names · 80873a0b
      Jonathan Neuschäfer authored
      These are the GPIO line names on a Nintendo Wii, as documented in:
      https://wiibrew.org/wiki/Hardware/Hollywood_GPIOsSigned-off-by: default avatarJonathan Neuschäfer <j.neuschaefer@gmx.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      80873a0b
    • Jonathan Neuschäfer's avatar
      powerpc/wii.dts: Add ngpios property · 9693d570
      Jonathan Neuschäfer authored
      The Hollywood GPIO controller supports 32 GPIOs, but on the Wii, only 24
      are used.
      Signed-off-by: default avatarJonathan Neuschäfer <j.neuschaefer@gmx.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      9693d570
    • Jonathan Neuschäfer's avatar
      powerpc/wii: Explicitly configure GPIO owner for poweroff pin · 9cbaaec1
      Jonathan Neuschäfer authored
      The Hollywood chipset's GPIO controller has two sets of registers: One
      for access by the PowerPC CPU, and one for access by the ARM coprocessor
      (but both are accessible from the PPC because the memory firewall
      (AHBPROT) is usually disabled when booting Linux, today).
      
      The wii_power_off function currently assumes that the poweroff GPIO pin
      is configured for use via the ARM side, but the upcoming GPIO driver
      configures all pins for use via the PPC side, breaking poweroff.
      
      Configure the owner register explicitly in wii_power_off to make
      wii_power_off work with and without the new GPIO driver.
      
      I think the Wii can be switched to the generic gpio-poweroff driver,
      after the GPIO driver is merged.
      Signed-off-by: default avatarJonathan Neuschäfer <j.neuschaefer@gmx.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      9cbaaec1
    • Jonathan Neuschäfer's avatar
      powerpc/wii: Probe the whole devicetree · 7ab96c0a
      Jonathan Neuschäfer authored
      Previously, wii_device_probe would only initialize devices under the
      /hollywood node. After this patch, platform devices placed outside of
      /hollywood will also be initialized.
      
      The intended usecase for this are devices located outside of the
      Hollywood chip, such as GPIO LEDs and GPIO buttons.
      Signed-off-by: default avatarJonathan Neuschäfer <j.neuschaefer@gmx.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      7ab96c0a
    • Michael Ellerman's avatar
      powerpc/64e: Fix oops due to deferral of paca allocation · 1d0afc0d
      Michael Ellerman authored
      On 64-bit Book3E systems, in setup_tlb_core_data() we reference other
      CPUs pacas. But in commit 59f57774 ("powerpc/64: Defer paca
      allocation until memory topology is discovered") the allocation of
      non-boot-CPU pacas was deferred until later in boot.
      
      This leads to an oops:
      
        CPU maps initialized for 1 thread per core
        Unable to handle kernel paging request for data at address 0x8888888888888918
        Faulting instruction address: 0xc000000000e2f0d0
        Oops: Kernel access of bad area, sig: 11 [#1]
        NIP .setup_tlb_core_data+0xdc/0x160
        Call Trace:
          .setup_tlb_core_data+0x5c/0x160 (unreliable)
          .setup_arch+0x80/0x348
          .start_kernel+0x7c/0x598
          start_here_common+0x1c/0x40
      
      Luckily setup_tlb_core_data() is called immediately prior to
      smp_setup_pacas(). So simply switching their order is sufficient to
      fix the oops and seems unlikely to have any other unwanted side
      effects.
      
      Fixes: 59f57774 ("powerpc/64: Defer paca allocation until memory topology is discovered")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      1d0afc0d
    • Aneesh Kumar K.V's avatar
      powerpc/kvm: Fix guest boot failure on Power9 since DAWR changes · ca9a16c3
      Aneesh Kumar K.V authored
      SLOF checks for 'sc 1' (hypercall) support by issuing a hcall with
      H_SET_DABR. Since the recent commit e8ebedbf ("KVM: PPC: Book3S
      HV: Return error from h_set_dabr() on POWER9") changed H_SET_DABR to
      return H_UNSUPPORTED on Power9, we see guest boot failures, the
      symptom is the boot seems to just stop in SLOF, eg:
      
        SLOF ***************************************************************
        QEMU Starting
         Build Date = Sep 24 2017 12:23:07
         FW Version = buildd@ release 20170724
        <no further output>
      
      SLOF can cope if H_SET_DABR returns H_HARDWARE. So wwitch the return
      value to H_HARDWARE instead of H_UNSUPPORTED so that we don't break
      the guest boot.
      
      That does mean we return a different error to PowerVM in this case,
      but that's probably not a big concern.
      
      Fixes: e8ebedbf ("KVM: PPC: Book3S HV: Return error from h_set_dabr() on POWER9")
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      ca9a16c3
  2. 30 Mar, 2018 26 commits