Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 04 8月, 2016 1 次提交
    • K
      dma-mapping: use unsigned long for dma_attrs · 00085f1e
      由 Krzysztof Kozlowski 提交于 
      The dma-mapping core and the implementations do not change the DMA
attributes passed by pointer.  Thus the pointer can point to const data.
However the attributes do not have to be a bitfield.  Instead unsigned
long will do fine:

1. This is just simpler.  Both in terms of reading the code and setting
   attributes.  Instead of initializing local attributes on the stack
   and passing pointer to it to dma_set_attr(), just set the bits.

2. It brings safeness and checking for const correctness because the
   attributes are passed by value.

Semantic patches for this change (at least most of them):

    virtual patch
    virtual context

    @r@
    identifier f, attrs;

    @@
    f(...,
    - struct dma_attrs *attrs
    + unsigned long attrs
    , ...)
    {
    ...
    }

    @@
    identifier r.f;
    @@
    f(...,
    - NULL
    + 0
     )

and

    // Options: --all-includes
    virtual patch
    virtual context

    @r@
    identifier f, attrs;
    type t;

    @@
    t f(..., struct dma_attrs *attrs);

    @@
    identifier r.f;
    @@
    f(...,
    - NULL
    + 0
     )

Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.comSigned-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: NVineet Gupta <vgupta@synopsys.com>
Acked-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NHans-Christian Noren Egtvedt <egtvedt@samfundet.no>
Acked-by: Mark Salter <msalter@redhat.com> [c6x]
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> [cris]
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [drm]
Reviewed-by: NBart Van Assche <bart.vanassche@sandisk.com>
Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
Acked-by: Fabien Dessenne <fabien.dessenne@st.com> [bdisp]
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> [vb2-core]
Acked-by: David Vrabel <david.vrabel@citrix.com> [xen]
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [xen swiotlb]
Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
Acked-by: Richard Kuo <rkuo@codeaurora.org> [hexagon]
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [s390]
Acked-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> [avr32]
Acked-by: Vineet Gupta <vgupta@synopsys.com> [arc]
Acked-by: Robin Murphy <robin.murphy@arm.com> [arm64 and dma-iommu]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      00085f1e
  3. 14 7月, 2016 1 次提交
    • P
      x86: Audit and remove any remaining unnecessary uses of module.h · eb008eb6
      由 Paul Gortmaker 提交于 
      Historically a lot of these existed because we did not have
a distinction between what was modular code and what was providing
support to modules via EXPORT_SYMBOL and friends.  That changed
when we forked out support for the latter into the export.h file.

This means we should be able to reduce the usage of module.h
in code that is obj-y Makefile or bool Kconfig.  In the case of
some of these which are modular, we can extend that to also include
files that are building basic support functionality but not related
to loading or registering the final module; such files also have
no need whatsoever for module.h

The advantage in removing such instances is that module.h itself
sources about 15 other headers; adding significantly to what we feed
cpp, and it can obscure what headers we are effectively using.

Since module.h was the source for init.h (for __init) and for
export.h (for EXPORT_SYMBOL) we consider each instance for the
presence of either and replace as needed.

In the case of crypto/glue_helper.c we delete a redundant instance
of MODULE_LICENSE in order to delete module.h -- the license info
is already present at the top of the file.

The uncore change warrants a mention too; it is uncore.c that uses
module.h and not uncore.h; hence the relocation done there.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20160714001901.31603-9-paul.gortmaker@windriver.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      eb008eb6
  5. 13 7月, 2016 1 次提交
  7. 08 7月, 2016 1 次提交
  9. 02 7月, 2016 1 次提交
  11. 21 6月, 2016 3 次提交
    • K
      x86/PCI: VMD: Separate MSI and MSI-X vector sharing · 9c205304
      由 Keith Busch 提交于 
      Child devices in a VMD domain that want to use MSI are slowing down MSI-X
using devices sharing the same vectors.  Move all MSI usage to a single VMD
vector, and MSI-X devices can share the rest.
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJon Derrick <jonathan.derrick@intel.com>
      9c205304
    • K
      x86/PCI: VMD: Use x86_vector_domain as parent domain · e382dffc
      由 Keith Busch 提交于 
      Otherwise APIC code assumes VMD's IRQ domain can be managed by the APIC,
resulting in an invalid cast of irq_data during irq_force_complete_move().
Signed-off-by: NJon Derrick <jonathan.derrick@intel.com>
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      e382dffc
    • J
      x86/PCI: VMD: Use lock save/restore in interrupt enable path · 3f57ff4f
      由 Jon Derrick 提交于 
      Enabling interrupts may result in an interrupt raised and serviced while
VMD holds a lock, resulting in contention with the spin lock held while
enabling interrupts.

The solution is to disable preemption and save/restore the state during
interrupt enable and disable.

Fixes lockdep:

  ======================================================
  [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
  4.6.0-2016-06-16-lockdep+ #47 Tainted: G            E
  ------------------------------------------------------
  kworker/0:1/447 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
   (list_lock){+.+...}, at: [<ffffffffa04eb8fc>] vmd_irq_enable+0x3c/0x70 [vmd]

  and this task is already holding:
   (&irq_desc_lock_class){-.-...}, at: [<ffffffff810e1ff6>] __setup_irq+0xa6/0x610
  which would create a new lock dependency:
   (&irq_desc_lock_class){-.-...} -> (list_lock){+.+...}

  but this new dependency connects a HARDIRQ-irq-safe lock:
   (&irq_desc_lock_class){-.-...}
  ... which became HARDIRQ-irq-safe at:
    [<ffffffff810c9f21>] __lock_acquire+0x981/0xe00
    [<ffffffff810cb039>] lock_acquire+0x119/0x220
    [<ffffffff8167294d>] _raw_spin_lock+0x3d/0x80
    [<ffffffff810e36d4>] handle_level_irq+0x24/0x110
    [<ffffffff8101f20a>] handle_irq+0x1a/0x30
    [<ffffffff81675fc1>] do_IRQ+0x61/0x120
    [<ffffffff8167404c>] ret_from_intr+0x0/0x20
    [<ffffffff81672e30>] _raw_spin_unlock_irqrestore+0x40/0x60
    [<ffffffff810e21ee>] __setup_irq+0x29e/0x610
    [<ffffffff810e25a1>] setup_irq+0x41/0x90
    [<ffffffff81f5777f>] setup_default_timer_irq+0x1e/0x20
    [<ffffffff81f57798>] hpet_time_init+0x17/0x19
    [<ffffffff81f5775a>] x86_late_time_init+0xa/0x11
    [<ffffffff81f51e9b>] start_kernel+0x382/0x436
    [<ffffffff81f51308>] x86_64_start_reservations+0x2a/0x2c
    [<ffffffff81f51445>] x86_64_start_kernel+0x13b/0x14a

  to a HARDIRQ-irq-unsafe lock:
   (list_lock){+.+...}
  ... which became HARDIRQ-irq-unsafe at:
  ...  [<ffffffff810c9d8e>] __lock_acquire+0x7ee/0xe00
    [<ffffffff810cb039>] lock_acquire+0x119/0x220
    [<ffffffff8167294d>] _raw_spin_lock+0x3d/0x80
    [<ffffffffa04eba42>] vmd_msi_init+0x72/0x150 [vmd]
    [<ffffffff810e8597>] msi_domain_alloc+0xb7/0x140
    [<ffffffff810e6b10>] irq_domain_alloc_irqs_recursive+0x40/0xa0
    [<ffffffff810e6cea>] __irq_domain_alloc_irqs+0x14a/0x330
    [<ffffffff810e8a8c>] msi_domain_alloc_irqs+0x8c/0x1d0
    [<ffffffff813ca4e3>] pci_msi_setup_msi_irqs+0x43/0x70
    [<ffffffff813cada1>] pci_enable_msi_range+0x131/0x280
    [<ffffffff813bf5e0>] pcie_port_device_register+0x320/0x4e0
    [<ffffffff813bf9a4>] pcie_portdrv_probe+0x34/0x60
    [<ffffffff813b0e85>] local_pci_probe+0x45/0xa0
    [<ffffffff813b226b>] pci_device_probe+0xdb/0x130
    [<ffffffff8149e3cc>] driver_probe_device+0x22c/0x440
    [<ffffffff8149e774>] __device_attach_driver+0x94/0x110
    [<ffffffff8149bfad>] bus_for_each_drv+0x5d/0x90
    [<ffffffff8149e030>] __device_attach+0xc0/0x140
    [<ffffffff8149e0c0>] device_attach+0x10/0x20
    [<ffffffff813a77f7>] pci_bus_add_device+0x47/0x90
    [<ffffffff813a7879>] pci_bus_add_devices+0x39/0x70
    [<ffffffff813aaba7>] pci_rescan_bus+0x27/0x30
    [<ffffffffa04ec1af>] vmd_probe+0x68f/0x76c [vmd]
    [<ffffffff813b0e85>] local_pci_probe+0x45/0xa0
    [<ffffffff81088064>] work_for_cpu_fn+0x14/0x20
    [<ffffffff8108c244>] process_one_work+0x1f4/0x740
    [<ffffffff8108c9c6>] worker_thread+0x236/0x4f0
    [<ffffffff810935c2>] kthread+0xf2/0x110
    [<ffffffff816738f2>] ret_from_fork+0x22/0x50

  other info that might help us debug this:

   Possible interrupt unsafe locking scenario:

	 CPU0                    CPU1
	 ----                    ----
    lock(list_lock);
				 local_irq_disable();
				 lock(&irq_desc_lock_class);
				 lock(list_lock);
    <Interrupt>
      lock(&irq_desc_lock_class);

   *** DEADLOCK ***
Signed-off-by: NJon Derrick <jonathan.derrick@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NKeith Busch <keith.busch@intel.com>
      3f57ff4f
  13. 18 6月, 2016 1 次提交
  15. 15 6月, 2016 1 次提交
  17. 14 6月, 2016 3 次提交
  19. 11 6月, 2016 1 次提交
  21. 24 5月, 2016 1 次提交
  23. 17 5月, 2016 1 次提交
    • P
      x86/PCI: Mark Broadwell-EP Home Agent 1 as having non-compliant BARs · da77b671
      由 Prarit Bhargava 提交于 
      Commit b8941571 ("x86/PCI: Mark Broadwell-EP Home Agent & PCU as having
non-compliant BARs") marked Home Agent 0 & PCU has having non-compliant
BARs.  Home Agent 1 also has non-compliant BARs.

Mark Home Agent 1 as having non-compliant BARs so the PCI core doesn't
touch them.

The problem with these devices is documented in the Xeon v4 specification
update:

  BDF2          PCI BARs in the Home Agent Will Return Non-Zero Values
                During Enumeration

  Problem:      During system initialization the Operating System may access
                the standard PCI BARs (Base Address Registers).  Due to
                this erratum, accesses to the Home Agent BAR registers (Bus
                1; Device 18; Function 0,4; Offsets (0x14-0x24) will return
                non-zero values.

  Implication:  The operating system may issue a warning.  Intel has not
                observed any functional failures due to this erratum.

Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e5-v4-spec-update.html
Fixes: b8941571 ("x86/PCI: Mark Broadwell-EP Home Agent & PCU as having non-compliant BARs")
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Ingo Molnar <mingo@redhat.com>
CC: "H. Peter Anvin" <hpa@zytor.com>
CC: Andi Kleen <ak@linux.intel.com>
      da77b671
  25. 05 5月, 2016 1 次提交
  27. 13 4月, 2016 1 次提交
  29. 12 4月, 2016 1 次提交
  31. 11 3月, 2016 3 次提交
  33. 09 3月, 2016 3 次提交
    • B
      PCI: Set ROM shadow location in arch code, not in PCI core · 0c0e0736
      由 Bjorn Helgaas 提交于 
      IORESOURCE_ROM_SHADOW means there is a copy of a device's option ROM in
RAM.  The existence of such a copy and its location are arch-specific.
Previously the IORESOURCE_ROM_SHADOW flag was set in arch code, but the
0xC0000-0xDFFFF location was hard-coded into the PCI core.

If we're using a shadow copy in RAM, disable the ROM BAR and release the
address space it was consuming.  Move the location information from the PCI
core to the arch code that sets IORESOURCE_ROM_SHADOW.  Save the location
of the RAM copy in the struct resource for PCI_ROM_RESOURCE.

After this change, pci_map_rom() will call pci_assign_resource() and
pci_enable_rom() for these IORESOURCE_ROM_SHADOW resources, which we did
not do before.  This is safe because:

  - pci_assign_resource() will do nothing because the resource is marked
    IORESOURCE_PCI_FIXED, which means we can't move it, and

  - pci_enable_rom() will not turn on the ROM BAR's enable bit because the
    resource is marked IORESOURCE_ROM_SHADOW, which means it is in RAM
    rather than in PCI memory space.

Storing the location in the struct resource means "lspci" will show the
shadow location, not the value from the ROM BAR.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      0c0e0736
    • B
      PCI: Mark shadow copy of VGA ROM as IORESOURCE_PCI_FIXED · 63e22924
      由 Bjorn Helgaas 提交于 
      A shadow copy of an option ROM is placed by the BIOS as a fixed address.
Set IORESOURCE_PCI_FIXED to indicate that we can't move the shadow copy.
This prevents warnings like the following when we assign resources:

  BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment

This warning is emitted by pdev_sort_resources(), which already ignores
IORESOURCE_PCI_FIXED resources.

Link: http://lkml.kernel.org/r/CA+55aFyVMfTBB0oz_yx8+eQOEJnzGtCsYSj9QuhEpdZ9BHdq5A@mail.gmail.comSigned-off-by: NBjorn Helgaas <bhelgaas@google.com>
      63e22924
    • B
      x86/PCI: Mark Broadwell-EP Home Agent & PCU as having non-compliant BARs · b8941571
      由 Bjorn Helgaas 提交于 
      The Home Agent and PCU PCI devices in Broadwell-EP have a non-BAR register
where a BAR should be.  We don't know what the side effects of sizing the
"BAR" would be, and we don't know what address space the "BAR" might appear
to describe.

Mark these devices as having non-compliant BARs so the PCI core doesn't
touch them.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Tested-by: NAndi Kleen <ak@linux.intel.com>
CC: stable@vger.kernel.org
      b8941571
  35. 27 2月, 2016 1 次提交
  37. 18 2月, 2016 2 次提交
  39. 15 2月, 2016 1 次提交
  41. 06 2月, 2016 1 次提交
  43. 16 1月, 2016 2 次提交
    • K
      x86/PCI: Add driver for Intel Volume Management Device (VMD) · 185a383a
      由 Keith Busch 提交于 
      The Intel Volume Management Device (VMD) is a Root Complex Integrated
Endpoint that acts as a host bridge to a secondary PCIe domain.  BIOS can
reassign one or more Root Ports to appear within a VMD domain instead of
the primary domain.  The immediate benefit is that additional PCIe domains
allow more than 256 buses in a system by letting bus numbers be reused
across different domains.

VMD domains do not define ACPI _SEG, so to avoid domain clashing with host
bridges defining this segment, VMD domains start at 0x10000, which is
greater than the highest possible 16-bit ACPI defined _SEG.

This driver enumerates and enables the domain using the root bus
configuration interface provided by the PCI subsystem.  The driver provides
configuration space accessor functions (pci_ops), bus and memory resources,
an MSI IRQ domain with irq_chip implementation, and DMA operations
necessary to use devices through the VMD endpoint's interface.

VMD routes I/O as follows:

   1) Configuration Space: BAR 0 ("CFGBAR") of VMD provides the base
   address and size for configuration space register access to VMD-owned
   root ports.  It works similarly to MMCONFIG for extended configuration
   space.  Bus numbering is independent and does not conflict with the
   primary domain.

   2) MMIO Space: BARs 2 and 4 ("MEMBAR1" and "MEMBAR2") of VMD provide the
   base address, size, and type for MMIO register access.  These addresses
   are not translated by VMD hardware; they are simply reservations to be
   distributed to root ports' memory base/limit registers and subdivided
   among devices downstream.

   3) DMA: To interact appropriately with an IOMMU, the source ID DMA read
   and write requests are translated to the bus-device-function of the VMD
   endpoint.  Otherwise, DMA operates normally without VMD-specific address
   translation.

   4) Interrupts: Part of VMD's BAR 4 is reserved for VMD's MSI-X Table and
   PBA.  MSIs from VMD domain devices and ports are remapped to appear as
   if they were issued using one of VMD's MSI-X table entries.  Each MSI
   and MSI-X address of VMD-owned devices and ports has a special format
   where the address refers to specific entries in the VMD's MSI-X table.
   As with DMA, the interrupt source ID is translated to VMD's
   bus-device-function.

   The driver provides its own MSI and MSI-X configuration functions
   specific to how MSI messages are used within the VMD domain, and
   provides an irq_chip for independent IRQ allocation to relay interrupts
   from VMD's interrupt handler to the appropriate device driver's handler.

   5) Errors: PCIe error message are intercepted by the root ports normally
   (e.g., AER), except with VMD, system errors (i.e., firmware first) are
   disabled by default.  AER and hotplug interrupts are translated in the
   same way as endpoint interrupts.

   6) VMD does not support INTx interrupts or IO ports.  Devices or drivers
   requiring these features should either not be placed below VMD-owned
   root ports, or VMD should be disabled by BIOS for such endpoints.

[bhelgaas: add VMD BAR #defines, factor out vmd_cfg_addr(), rework VMD
resource setup, whitespace, changelog]
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de> (IRQ-related parts)
      185a383a
    • K
      x86/PCI: Allow DMA ops specific to a PCI domain · d9c3d6ff
      由 Keith Busch 提交于 
      The Intel Volume Management Device (VMD) is a PCIe endpoint that acts as a
host bridge to another PCI domain.  When devices below the VMD perform DMA,
the VMD replaces their DMA source IDs with its own source ID.  Therefore,
those devices require special DMA ops.

Add interfaces to allow the VMD driver to set up dma_ops for the devices
below it.

[bhelgaas: remove "extern", add "static", changelog]
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      d9c3d6ff
  45. 11 12月, 2015 1 次提交
  47. 02 12月, 2015 1 次提交
  49. 22 10月, 2015 1 次提交
    • J
      x86/PCI: Don't alloc pcibios-irq when MSI is enabled · 8affb487
      由 Joerg Roedel 提交于 
      The pcibios-irq and MSI both use dev->irq to store the IRQ number.  While
the MSI code checks for that and frees the pcibios-irq before overwriting
dev->irq, the pcibios_alloc_irq() function does not.

Usually this is not a problem, as the pcibios-irq is allocated before probe
time of the device and the MSI IRQ is allocted from the driver's probe
path.

But there are PCI devices handled by the core kernel and not by a standard
PCI driver, like the AMD IOMMU for example.  For the AMD IOMMU a normal PCI
device driver does not make sense, because a driver can be forcibly unbound
from its device, which is not a good idea for an IOMMU.

Nevertheless the PCI core code tries to match the PCI device implementing
the AMD IOMMU against drivers, and allocates/frees a pcibios IRQ every time
it tries out a new driver.  This overwrites the dev->irq field set by
pci_enable_msi() and sets it to 0 in the end (because the probe fails and
the pcibios-irq is freed again).

On suspend/resume this breaks the kernel, because the IRQ descriptor for
IRQ 0 is NULL.

Fix this by not allocating a pcibios-irq when MSI is already active.  This
also has the benefit, that a device claimed by the core kernel can not be
probed by a PCI driver later.
Reported-by: NBorislav Petkov <bp@alien8.de>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
      8affb487
  51. 17 10月, 2015 2 次提交
  53. 10 10月, 2015 1 次提交
  55. 16 9月, 2015 1 次提交
    • B
      PCI: Revert "PCI: Call pci_read_bridge_bases() from core instead of arch code" · 237865f1
      由 Bjorn Helgaas 提交于 
      Revert dff22d20 ("PCI: Call pci_read_bridge_bases() from core instead
of arch code").

Reading PCI bridge windows is not arch-specific in itself, but there is PCI
core code that doesn't work correctly if we read them too early.  For
example, Hannes found this case on an ARM Freescale i.mx6 board:

  pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
  pci 0000:00:00.0: PCI bridge to [bus 01-ff]
  pci 0000:00:00.0: BAR 8: no space for [mem size 0x01000000] (mem window)
  pci 0000:01:00.0: BAR 2: failed to assign [mem size 0x00200000]
  pci 0000:01:00.0: BAR 1: failed to assign [mem size 0x00004000]
  pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x00000100]

The 00:00.0 mem window needs to be at least 3MB: the 01:00.0 device needs
0x204100 of space, and mem windows are megabyte-aligned.

Bus sizing can increase a bridge window size, but never *decrease* it (see
d65245c3 ("PCI: don't shrink bridge resources")).  Prior to
dff22d20, ARM didn't read bridge windows at all, so the "original size"
was zero, and we assigned a 3MB window.

After dff22d20, we read the bridge windows before sizing the bus.  The
firmware programmed a 16MB window (size 0x01000000) in 00:00.0, and since
we never decrease the size, we kept 16MB even though we only needed 3MB.
But 16MB doesn't fit in the host bridge aperture, so we failed to assign
space for the window and the downstream devices.

I think this is a defect in the PCI core: we shouldn't rely on the firmware
to assign sensible windows.

Ray reported a similar problem, also on ARM, with Broadcom iProc.

Issues like this are too hard to fix right now, so revert dff22d20.
Reported-by: NHannes <oe5hpm@gmail.com>
Reported-by: NRay Jui <rjui@broadcom.com>
Link: http://lkml.kernel.org/r/CAAa04yFQEUJm7Jj1qMT57-LG7ZGtnhNDBe=PpSRa70Mj+XhW-A@mail.gmail.com
Link: http://lkml.kernel.org/r/55F75BB8.4070405@broadcom.comSigned-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      237865f1
  57. 31 7月, 2015 1 次提交