1. 22 Aug, 2019 2 commits
    • 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 4 commits