1. 28 5月, 2014 1 次提交
  2. 23 5月, 2014 5 次提交
    • H
      powerpc/mpc85xx: Add BSC9132 QDS Support · 1be62c6c
      harninder rai 提交于
      - BSC9132 is an integrated device that targets Femto base station market.
        It combines Power Architecture e500v2 and DSP StarCore SC3850 technologies
        with MAPLE-B2F baseband acceleration processing elements
      
      - BSC9132QDS Overview
           2Gbyte DDR3 (on board DDR)
           32Mbyte 16bit NOR flash
           128Mbyte 2K page size NAND Flash
           256 Kbit M24256 I2C EEPROM
           128 Mbit SPI Flash memory
           SD slot
           eTSEC1: Connected to SGMII PHY
           eTSEC2: Connected to SGMII PHY
           DUART interface: supports one UARTs up to 115200 bps for console display
      Signed-off-by: NHarninder Rai <harninder.rai@freescale.com>
      Signed-off-by: NRuchika Gupta <ruchika.gupta@freescale.com>
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      1be62c6c
    • L
      powerpc/mpc85xx: Remove P1023 RDS support · fd7e5b7a
      Lijun Pan 提交于
      P1023RDS is no longer supported/manufactured by Freescale while P1023RDB is.
      Signed-off-by: NLijun Pan <Lijun.Pan@freescale.com>
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      fd7e5b7a
    • P
      powerpc/fsl-booke: Add initial T104x_QDS board support · 0c0fc4d3
      Prabhakar Kushwaha 提交于
      Add support for T104x board in board file t104x_qds.c, It is common for
       both T1040 and T1042 as they share same QDS board.
      
       T1040QDS board Overview
       -----------------------
       - SERDES Connections, 8 lanes supporting:
            — PCI Express: supporting Gen 1 and Gen 2;
            — SGMII
            — QSGMII
            — SATA 2.0
            — Aurora debug with dedicated connectors (T1040 only)
       - DDR Controller
           - Supports rates of up to 1600 MHz data-rate
           - Supports one DDR3LP UDIMM/RDIMMs, of single-, dual- or quad-rank types.
       -IFC/Local Bus
           - NAND flash: 8-bit, async, up to 2GB.
           - NOR: 8-bit or 16-bit, non-multiplexed, up to 512MB
           - GASIC: Simple (minimal) target within Qixis FPGA
           - PromJET rapid memory download support
       - Ethernet
           - Two on-board RGMII 10/100/1G ethernet ports.
           - PHY #0 remains powered up during deep-sleep (T1040 only)
       - QIXIS System Logic FPGA
       - Clocks
           - System and DDR clock (SYSCLK, “DDRCLK”)
           - SERDES clocks
       - Power Supplies
       - Video
           - DIU supports video at up to 1280x1024x32bpp
       - USB
           - Supports two USB 2.0 ports with integrated PHYs
           — Two type A ports with 5V@1.5A per port.
           — Second port can be converted to OTG mini-AB
       - SDHC
           - SDHC port connects directly to an adapter card slot, featuring:
           - Supporting SD slots for: SD, SDHC (1x, 4x, 8x) and/or MMC
           — Supporting eMMC memory devices
       - SPI
          -  On-board support of 3 different devices and sizes
       - Other IO
          - Two Serial ports
          - ProfiBus port
          - Four I2C ports
      
      Add T104xQDS support in Kconfig and Makefile. Also create device tree.
      Following features are currently not implmented.
        - SerDes: Aurora
        - IFC: GASIC, Promjet
        - QIXIS
        - Ethernet
        - DIU
        - power supplies management
        - ProfiBus
      Signed-off-by: NPriyanka Jain <Priyanka.Jain@freescale.com>
      Signed-off-by: NPoonam Aggrwal <poonam.aggrwal@freescale.com>
      Signed-off-by: NPrabhakar Kushwaha <prabhakar@freescale.com>
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      0c0fc4d3
    • M
      powerpc/85xx: Add OCA4080 board support · 2b09c603
      Martijn de Gouw 提交于
      OCA4080 overview:
      - 1.466 GHz Freescale QorIQ P4080E Processor
      - 4Gbyte DDR3 on board
      - 8Mbyte Nor flash
      - Serial RapidIO 1.2
      - 1 x 10/100/1000 BASE-T front ethernet
      - 1 x 1000 BASE-BX ethernet on AMC connector
      Signed-off-by: NMartijn de Gouw <martijn.de.gouw@prodrive.nl>
      [scottwood@freescale.com: minor conflict-related changes]
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      2b09c603
    • V
      powerpc/mpc85xx: add support for Keymile's kmcoge4 board · 497c8b60
      Valentin Longchamp 提交于
      This patch introduces the support for Keymile's kmcoge4 board which is
      the internal reference design for boards based on Freescale's
      P2040/P2041 SoCs. This internal reference design is named kmp204x.
      
      The peripherals used on this board are:
      - SPI NOR Flash as bootloader medium
      - NAND Flash with a ubi partition
      - 2 PCIe busses (hosts 1 and 3)
      - 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
      - 4 Local Bus windows, with one dedicated to the QRIO reset/power mgmt
        CPLD
      - 2 I2C busses
      - last but not least, the mandatory serial port
      
      The patch also adds a defconfig file for this reference design that is
      necessary because of the lowmem option that must be set higher due to
      the number of PCIe devices with big ioremapped mem ranges on the boad.
      Signed-off-by: NValentin Longchamp <valentin.longchamp@keymile.com>
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      497c8b60
  3. 20 5月, 2014 1 次提交
  4. 12 5月, 2014 1 次提交
  5. 01 5月, 2014 5 次提交
  6. 28 4月, 2014 27 次提交
    • G
      powerpc: powernv: Implement ppc_md.get_proc_freq() · fb5153d0
      Gautham R. Shenoy 提交于
      Implement a method named pnv_get_proc_freq(unsigned int cpu) which
      returns the current clock rate on the 'cpu' in Hz to be reported in
      /proc/cpuinfo. This method uses the value reported by cpufreq when
      such a value is sane. Otherwise it falls back to old way of reporting
      the clockrate, i.e. ppc_proc_freq.
      
      Set the ppc_md.get_proc_freq() hook to pnv_get_proc_freq() on the
      PowerNV platform.
      Signed-off-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      fb5153d0
    • V
      powerpc/powernv: Return secondary CPUs to firmware before FW update · 2196c6f1
      Vasant Hegde 提交于
      Firmware update on PowerNV platform takes several minutes. During
      this time one CPU is stuck in FW and the kernel complains about "soft
      lockups".
      
      This patch returns all secondary CPUs to firmware before starting
      firmware update process.
      
      [ Reworked a bit and cleaned up -- BenH ]
      Signed-off-by: NVasant Hegde <hegdevasant@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2196c6f1
    • S
      powerpc/legacy_serial: Support MVME5100 UARTS with shifted registers · 13ae4037
      Stephen Chivers 提交于
      This patch adds support to legacy serial for
      UARTS with shifted registers.
      
      The MVME5100 Single Board Computer is a PowerPC platform
      that has 16550 style UARTS with register addresses that are
      16 bytes apart (shifted by 4).
      
      Commit 	30925748
      "powerpc: Cleanup udbg_16550 and add support for LPC PIO-only UARTs"
      added support to udbg_16550 for shifted registers by adding a "stride"
      parameter to the initialisation operations for Programmed IO and
      Memory Mapped IO.
      
      As a consequence it is now possible to use the services of legacy serial
      to provide early serial console messages for the MVME5100.
      
      An added benefit of this is that the serial console will always be
      "ttyS0" irrespective of whether the computer is fitted with extra
      PCI 8250 interface boards or not.
      
      I have tested this patch using the four PowerPC platforms available to me:
      
      	MVME5100 - shifted registers,
      	SAM440EP - unshifted registers,
      	MPC8349 - unshifted registers,
      	MVME4100 - unshifted registers.
      Signed-off-by: NStephen Chivers <schivers@csc.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      13ae4037
    • C
      powerpc/boot: Add support for 64bit little endian wrapper · 147c0516
      Cédric Le Goater 提交于
      The code is only slightly modified : entry points now use the
      FIXUP_ENDIAN trampoline to switch endian order. The 32bit wrapper
      is kept for big endian kernels and 64bit is enforced for little
      endian kernels with a PPC64_BOOT_WRAPPER config option.
      
      The linker script is generated using the kernel preprocessor flags
      to make use of the CONFIG_* definitions and the wrapper script is
      modified to take into account the new elf64ppc format.
      
      Finally, the zImage file is compiled as a position independent
      executable (-pie) which makes it loadable at any address by the
      firmware.
      Signed-off-by: NCédric Le Goater <clg@fr.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      147c0516
    • G
      powerpc/powernv: Don't use pe->pbus to get the domain number · e9bc03fe
      Gavin Shan 提交于
      If the PE contains single PCI function, "pe->pbus" would be NULL.
      It's not reliable to be used by pci_domain_nr().  We just grab the
      PCI domain number from the PCI host controller (struct pci_controller)
      instance.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e9bc03fe
    • G
      powerpc/powernv: Missed IOMMU table type · 65fd766b
      Gavin Shan 提交于
      In function pnv_pci_ioda2_setup_dma_pe(), the IOMMU table type is
      set to (TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE) unconditionally.
      It was just set to TCE_PCI by pnv_pci_setup_iommu_table(). So the
      primary IOMMU table type (TCE_PCI) is lost. The patch fixes it.
      
      Also, pnv_pci_setup_iommu_table() already set "tbl->it_busno" to
      zero and we needn't do it again. The patch removes the redundant
      assignment.
      
      The patch also fixes similar issues in pnv_pci_ioda_setup_dma_pe().
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      65fd766b
    • G
      powerpc/powernv: Fundamental reset on PLX ports · b2b5efcf
      Gavin Shan 提交于
      The patch intends to support fundamental reset on PLX downstream
      ports. If the PCI device matches any one of the internal table,
      which includes PLX vendor ID, bridge device ID, register offset
      for fundamental reset and bit, fundamental reset will be done
      accordingly. Otherwise, it will fail back to hot reset.
      
      Additional flag (EEH_DEV_FRESET) is introduced to record the last
      reset type on the PCI bridge.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      b2b5efcf
    • G
      powrpc/powernv: Reset PHB in kdump kernel · 361f2a2a
      Gavin Shan 提交于
      In the kdump scenario, the first kerenl doesn't shutdown PCI devices
      and the kdump kerenl clean PHB IODA table at the early probe time.
      That means the kdump kerenl can't support PCI transactions piled
      by the first kerenl. Otherwise, lots of EEH errors and frozen PEs
      will be detected.
      
      In order to avoid the EEH errors, the PHB is resetted to drop all
      PCI transaction from the first kerenl.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      361f2a2a
    • G
      powerpc/pci: Mask linkDown on resetting PCI bus · d92a208d
      Gavin Shan 提交于
      The problem was initially reported by Wendy who tried pass through
      IPR adapter, which was connected to PHB root port directly, to KVM
      based guest. When doing that, pci_reset_bridge_secondary_bus() was
      called by VFIO driver and linkDown was detected by the root port.
      That caused all PEs to be frozen.
      
      The patch fixes the issue by routing the reset for the secondary bus
      of root port to underly firmware. For that, one more weak function
      pci_reset_secondary_bus() is introduced so that the individual platforms
      can override that and do specific reset for bridge's secondary bus.
      Reported-by: NWendy Xiong <wenxiong@linux.vnet.ibm.com>
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      d92a208d
    • G
      powerpc/eeh: Make the delay for PE reset unified · 26833a50
      Gavin Shan 提交于
      Basically, we have 3 types of resets to fulfil PE reset: fundamental,
      hot and PHB reset. For the later 2 cases, we need PCI bus reset hold
      and settlement delay as specified by PCI spec. PowerNV and pSeries
      platforms are running on top of different firmware and some of the
      delays have been covered by underly firmware (PowerNV).
      
      The patch makes the delays unified to be done in backend, instead of
      EEH core.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      26833a50
    • G
      powerpc/powernv: Reset root port in firmware · fd5cee7c
      Gavin Shan 提交于
      Resetting root port has more stuff to do than that for PCIe switch
      ports and we should have resetting root port done in firmware instead
      of the kernel itself. The problem was introduced by commit 5b2e198e
      ("powerpc/powernv: Rework EEH reset").
      
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      fd5cee7c
    • G
      powerpc/pseries: Fix overwritten PE state · 54f112a3
      Gavin Shan 提交于
      In pseries_eeh_get_state(), EEH_STATE_UNAVAILABLE is always
      overwritten by EEH_STATE_NOT_SUPPORT because of the missed
      "break" there. The patch fixes the issue.
      Reported-by: NJoe Perches <joe@perches.com>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      54f112a3
    • G
      powerpc/powernv: Fix endless reporting frozen PE · 63796558
      Gavin Shan 提交于
      Once one specific PE has been marked as EEH_PE_ISOLATED, it's in
      the middile of recovery or removed permenently. We needn't report
      the frozen PE again. Otherwise, we will have endless reporting
      same frozen PE.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      63796558
    • G
      powerpc/eeh: No hotplug on permanently removed dev · d2b0f6f7
      Gavin Shan 提交于
      The issue was detected in a bit complicated test case where
      we have multiple hierarchical PEs shown as following figure:
      
                      +-----------------+
                      | PE#3     p2p#0  |
                      |          p2p#1  |
                      +-----------------+
                              |
                      +-----------------+
                      | PE#4     pdev#0 |
                      |          pdev#1 |
                      +-----------------+
      
      PE#4 (have 2 PCI devices) is the child of PE#3, which has 2 p2p
      bridges. We accidentally had less-known scenario: PE#4 was removed
      permanently from the system because of permanent failure (e.g.
      exceeding the max allowd failure times in last hour), then we detects
      EEH errors on PE#3 and tried to recover it. However, eeh_dev instances
      for pdev#0/1 were not detached from PE#4, which was still connected to
      PE#3. All of that was because of the fact that we rely on count-based
      pcibios_release_device(), which isn't reliable enough. When doing
      recovery for PE#3, we still apply hotplug on PE#4 and pdev#0/1, which
      are not valid any more. Eventually, we run into kernel crash.
      
      The patch fixes above issue from two aspects. For unplug, we simply
      skip those permanently removed PE, whose state is (EEH_PE_STATE_ISOLATED
      && !EEH_PE_STATE_RECOVERING) and its frozen count should be greater
      than EEH_MAX_ALLOWED_FREEZES. For plug, we marked all permanently
      removed EEH devices with EEH_DEV_REMOVED and return 0xFF's on read
      its PCI config so that PCI core will omit them.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      d2b0f6f7
    • G
      powerpc/eeh: Allow to disable EEH · 7f52a526
      Gavin Shan 提交于
      The patch introduces bootarg "eeh=off" to disable EEH functinality.
      Also, it creates /sys/kerenl/debug/powerpc/eeh_enable to disable
      or enable EEH functionality. By default, we have the functionality
      enabled.
      
      For PowerNV platform, we will restore to have the conventional
      mechanism of clearing frozen PE during PCI config access if we're
      going to disable EEH functionality. Conversely, we will rely on
      EEH for error recovery.
      
      The patch also fixes the issue that we missed to cover the case
      of disabled EEH functionality in function ioda_eeh_event(). Those
      events driven by interrupt should be cleared to avoid endless
      reporting.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      7f52a526
    • G
      powerpc/eeh: Use cached capability for log dump · 2a18dfc6
      Gavin Shan 提交于
      When calling into eeh_gather_pci_data() on pSeries platform, we
      possiblly don't have pci_dev instance yet, but eeh_dev is always
      ready. So we use cached capability from eeh_dev instead of pci_dev
      for log dump there. In order to keep things unified, we also cache
      PCI capability positions to eeh_dev for PowerNV as well.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2a18dfc6
    • G
      powerpc/eeh: Avoid I/O access during PE reset · 78954700
      Gavin Shan 提交于
      We have suffered recrusive frozen PE a lot, which was caused
      by IO accesses during the PE reset. Ben came up with the good
      idea to keep frozen PE until recovery (BAR restore) gets done.
      With that, IO accesses during PE reset are dropped by hardware
      and wouldn't incur the recrusive frozen PE any more.
      
      The patch implements the idea. We don't clear the frozen state
      until PE reset is done completely. During the period, the EEH
      core expects unfrozen state from backend to keep going. So we
      have to reuse EEH_PE_RESET flag, which has been set during PE
      reset, to return normal state from backend. The side effect is
      we have to clear frozen state for towice (PE reset and clear it
      explicitly), but that's harmless.
      
      We have some limitations on pHyp. pHyp doesn't allow to enable
      IO or DMA for unfrozen PE. So we don't enable them on unfrozen PE
      in eeh_pci_enable(). We have to enable IO before grabbing logs on
      pHyp. Otherwise, 0xFF's is always returned from PCI config space.
      Also, we had wrong return value from eeh_pci_enable() for
      EEH_OPT_THAW_DMA case. The patch fixes it too.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      78954700
    • G
      powerpc/powernv: Use EEH PCI config accessors · 1d9a5446
      Gavin Shan 提交于
      For EEH PowerNV backends, they need use their own PCI config
      accesors as the normal one could be blocked during PE reset.
      The patch also removes necessary parameter "hose" for the
      function ioda_eeh_bridge_reset().
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      1d9a5446
    • G
      powerpc/eeh: Block PCI-CFG access during PE reset · d0914f50
      Gavin Shan 提交于
      We've observed multiple PE reset failures because of PCI-CFG
      access during that period. Potentially, some device drivers
      can't support EEH very well and they can't put the device to
      motionless state before PE reset. So those device drivers might
      produce PCI-CFG accesses during PE reset. Also, we could have
      PCI-CFG access from user space (e.g. "lspci"). Since access to
      frozen PE should return 0xFF's, we can block PCI-CFG access
      during the period of PE reset so that we won't get recrusive EEH
      errors.
      
      The patch adds flag EEH_PE_RESET, which is kept during PE reset.
      The PowerNV/pSeries PCI-CFG accessors reuse the flag to block
      PCI-CFG accordingly.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      d0914f50
    • G
      powerpc/powernv: Remove fields in PHB diag-data dump · b34497d1
      Gavin Shan 提交于
      For some fields (e.g. LEM, MMIO, DMA) in PHB diag-data dump, it's
      meaningless to print them if they have non-zero value in the
      corresponding mask registers because we always have non-zero values
      in the mask registers. The patch only prints those fieds if we
      have non-zero values in the primary registers (e.g. LEM, MMIO, DMA
      status) so that we can save couple of lines. The patch also removes
      unnecessary spare line before "brdgCtl:" and two leading spaces as
      prefix in each line as Ben suggested.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      b34497d1
    • G
      powerpc/powernv: Move PNV_EEH_STATE_ENABLED around · f5bc6b70
      Gavin Shan 提交于
      The flag PNV_EEH_STATE_ENABLED is put into pnv_phb::eeh_state,
      which is protected by CONFIG_EEH. We needn't that. Instead, we
      can have pnv_phb::flags and maintain all flags there, which is
      the purpose of the patch. The patch also renames PNV_EEH_STATE_ENABLED
      to PNV_PHB_FLAG_EEH.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      f5bc6b70
    • G
      powerpc/powernv: Remove PNV_EEH_STATE_REMOVED · 467f79a9
      Gavin Shan 提交于
      The PHB state PNV_EEH_STATE_REMOVED maintained in pnv_phb isn't
      so useful any more and it's duplicated to EEH_PE_ISOLATED. The
      patch replaces PNV_EEH_STATE_REMOVED with EEH_PE_ISOLATED.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      467f79a9
    • P
      ppc/powernv: Set the runlatch bits correctly for offline cpus · f2038911
      Preeti U Murthy 提交于
      Up until now we have been setting the runlatch bits for a busy CPU and
      clearing it when a CPU enters idle state. The runlatch bit has thus
      been consistent with the utilization of a CPU as long as the CPU is online.
      
      However when a CPU is hotplugged out the runlatch bit is not cleared. It
      needs to be cleared to indicate an unused CPU. Hence this patch has the
      runlatch bit cleared for an offline CPU just before entering an idle state
      and sets it immediately after it exits the idle state.
      Signed-off-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      f2038911
    • L
      powerpc/pseries: Protect remove_memory() with device hotplug lock · 42dbfc86
      Li Zhong 提交于
      While testing memory hot-remove, I found following dead lock:
      
      Process #1141 is drmgr, trying to remove some memory, i.e. memory499.
      It holds the memory_hotplug_mutex, and blocks when trying to remove file
      "online" under dir memory499, in kernfs_drain(), at
              wait_event(root->deactivate_waitq,
                         atomic_read(&kn->active) == KN_DEACTIVATED_BIAS);
      
      Process #1120 is trying to online memory499 by
         echo 1 > memory499/online
      
      In .kernfs_fop_write, it uses kernfs_get_active() to increase
      &kn->active, thus blocking process #1141. While itself is blocked later
      when trying to acquire memory_hotplug_mutex, which is held by process
      
      The backtrace of both processes are shown below:
      
      [<c000000001b18600>] 0xc000000001b18600
      [<c000000000015044>] .__switch_to+0x144/0x200
      [<c000000000263ca4>] .online_pages+0x74/0x7b0
      [<c00000000055b40c>] .memory_subsys_online+0x9c/0x150
      [<c00000000053cbe8>] .device_online+0xb8/0x120
      [<c00000000053cd04>] .online_store+0xb4/0xc0
      [<c000000000538ce4>] .dev_attr_store+0x64/0xa0
      [<c00000000030f4ec>] .sysfs_kf_write+0x7c/0xb0
      [<c00000000030e574>] .kernfs_fop_write+0x154/0x1e0
      [<c000000000268450>] .vfs_write+0xe0/0x260
      [<c000000000269144>] .SyS_write+0x64/0x110
      [<c000000000009ffc>] syscall_exit+0x0/0x7c
      
      [<c000000001b18600>] 0xc000000001b18600
      [<c000000000015044>] .__switch_to+0x144/0x200
      [<c00000000030be14>] .__kernfs_remove+0x204/0x300
      [<c00000000030d428>] .kernfs_remove_by_name_ns+0x68/0xf0
      [<c00000000030fb38>] .sysfs_remove_file_ns+0x38/0x60
      [<c000000000539354>] .device_remove_attrs+0x54/0xc0
      [<c000000000539fd8>] .device_del+0x158/0x250
      [<c00000000053a104>] .device_unregister+0x34/0xa0
      [<c00000000055bc14>] .unregister_memory_section+0x164/0x170
      [<c00000000024ee18>] .__remove_pages+0x108/0x4c0
      [<c00000000004b590>] .arch_remove_memory+0x60/0xc0
      [<c00000000026446c>] .remove_memory+0x8c/0xe0
      [<c00000000007f9f4>] .pseries_remove_memblock+0xd4/0x160
      [<c00000000007fcfc>] .pseries_memory_notifier+0x27c/0x290
      [<c0000000008ae6cc>] .notifier_call_chain+0x8c/0x100
      [<c0000000000d858c>] .__blocking_notifier_call_chain+0x6c/0xe0
      [<c00000000071ddec>] .of_property_notify+0x7c/0xc0
      [<c00000000071ed3c>] .of_update_property+0x3c/0x1b0
      [<c0000000000756cc>] .ofdt_write+0x3dc/0x740
      [<c0000000002f60fc>] .proc_reg_write+0xac/0x110
      [<c000000000268450>] .vfs_write+0xe0/0x260
      [<c000000000269144>] .SyS_write+0x64/0x110
      [<c000000000009ffc>] syscall_exit+0x0/0x7c
      
      This patch uses lock_device_hotplug() to protect remove_memory() called
      in pseries_remove_memblock(), which is also stated before function
      remove_memory():
      
       * NOTE: The caller must call lock_device_hotplug() to serialize hotplug
       * and online/offline operations before this call, as required by
       * try_offline_node().
       */
      void __ref remove_memory(int nid, u64 start, u64 size)
      
      With this lock held, the other process(#1120 above) trying to online the
      memory block will retry the system call when calling
      lock_device_hotplug_sysfs(), and finally find No such device error.
      Signed-off-by: NLi Zhong <zhong@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      42dbfc86
    • A
    • A
      powerpc/powernv: Create OPAL sglist helper functions and fix endian issues · 3441f04b
      Anton Blanchard 提交于
      We have two copies of code that creates an OPAL sg list. Consolidate
      these into a common set of helpers and fix the endian issues.
      
      The flash interface embedded a version number in the num_entries
      field, whereas the dump interface did did not. Since versioning
      wasn't added to the flash interface and it is impossible to add
      this in a backwards compatible way, just remove it.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      3441f04b
    • A
      powerpc/powernv: Fix little endian issues in OPAL error log code · 14ad0c58
      Anton Blanchard 提交于
      Fix little endian issues with the OPAL error log code.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Reviewed-by: NStewart Smith <stewart@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      14ad0c58