1. 22 Aug, 2019 3 commits
    • Sam Bobroff's avatar
      powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER flag · aa06e3d6
      Sam Bobroff authored
      The EEH_DEV_NO_HANDLER flag is used by the EEH system to prevent the
      use of driver callbacks in drivers that have been bound part way
      through the recovery process. This is necessary to prevent later stage
      handlers from being called when the earlier stage handlers haven't,
      which can be confusing for drivers.
      
      However, the flag is set for all devices that are added after boot
      time and only cleared at the end of the EEH recovery process. This
      results in hot plugged devices erroneously having the flag set during
      the first recovery after they are added (causing their driver's
      handlers to be incorrectly ignored).
      
      To remedy this, clear the flag at the beginning of recovery
      processing. The flag is still cleared at the end of recovery
      processing, although it is no longer really necessary.
      
      Also clear the flag during eeh_handle_special_event(), for the same
      reasons.
      Signed-off-by: default avatarSam Bobroff <sbobroff@linux.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/b8ca5629d27de74c957d4f4b250177d1b6fc4bbd.1565930772.git.sbobroff@linux.ibm.com
      aa06e3d6
    • Sam Bobroff's avatar
      powerpc/64: Adjust order in pcibios_init() · 3f068aae
      Sam Bobroff authored
      The pcibios_init() function for PowerPC 64 currently calls
      pci_bus_add_devices() before pcibios_resource_survey(). This means
      that at boot time, when the pcibios_bus_add_device() hooks are called
      by pci_bus_add_devices(), device resources have not been allocated and
      they are unable to perform EEH setup, so a separate pass is needed.
      
      This patch adjusts that order so that it will become possible to
      consolidate the EEH setup work into a single location.
      
      The only functional change is to execute pcibios_resource_survey()
      (excepting ppc_md.pcibios_fixup(), see below) before
      pci_bus_add_devices() instead of after it.
      
      Because pcibios_scan_phb() and pci_bus_add_devices() are called
      together in a loop, this must be broken into one loop for each call.
      Then the call to pcibios_resource_survey() is moved up in between
      them. This changes the ordering but because pcibios_resource_survey()
      also calls ppc_md.pcibios_fixup(), that call is extracted out into
      pcibios_init() to where pcibios_resource_survey() was, so that it is
      not moved.
      
      The only other caller of pcibios_resource_survey() is the PowerPC 32
      version of pcibios_init(), and therefore, that is modified to call
      ppc_md.pcibios_fixup() right after pcibios_resource_survey() so that
      there is no functional change there at all.
      
      The re-arrangement will cause very few side-effects because at this
      stage in the boot, pci_bus_add_devices() does very little:
      - pci_create_sysfs_dev_files() does nothing (no sysfs yet)
      - pci_proc_attach_device() does nothing (no proc yet)
      - device_attach() does nothing (no drivers yet)
      This leaves only the pci_final_fixup calls, D3 support, and marking
      the device as added. Of those, only the pci_final_fixup calls have the
      potential to be affected by resource allocation.
      
      The only pci_final_fixup handlers that touch resources seem to be one
      for x86 (pci_amd_enable_64bit_bar()), and a PowerPC 32 platform driver
      (quirk_final_uli1575()), neither of which use this pcibios_init()
      function. Even if they did, it would almost certainly be a bug, under
      the current ordering, to rely on or make changes to resources before
      they were allocated.
      Signed-off-by: default avatarSam Bobroff <sbobroff@linux.ibm.com>
      Reviewed-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/4506b0489eabd0921a3587d90bd44c7683f3472d.1565930772.git.sbobroff@linux.ibm.com
      3f068aae
    • Masahiro Yamada's avatar
      powerpc: remove meaningless KBUILD_ARFLAGS addition · 56347074
      Masahiro Yamada authored
      The KBUILD_ARFLAGS addition in arch/powerpc/Makefile has never worked
      in a useful way because it is always overridden by the following code
      in the top Makefile:
      
        # use the deterministic mode of AR if available
        KBUILD_ARFLAGS := $(call ar-option,D)
      
      The code in the top Makefile was added in 2011, by commit 40df759e
      ("kbuild: Fix build with binutils <= 2.19").
      
      The KBUILD_ARFLAGS addition for ppc has always been dead code from the
      beginning.
      
      Nobody has reported a problem since 43c9127d ("powerpc: Add option
      to use thin archives"), so this code was unneeded.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190713032106.8509-1-yamada.masahiro@socionext.com
      56347074
  2. 21 Aug, 2019 7 commits
  3. 20 Aug, 2019 27 commits
  4. 19 Aug, 2019 3 commits