This commit adds support for the TS-4800 interrupt controller. This
controller is instantiated in a companion FPGA, and multiplex interrupts
for other FPGA IPs.

As this component is external to the SoC, the SoC might need to reserve
pins, so this controller is implemented as a platform driver and doesn't
use the IRQCHIP_DECLARE construct.
Signed-off-by: NDamien Riegel <damien.riegel@savoirfairelinux.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: kernel@savoirfairelinux.com
Link: http://lkml.kernel.org/r/1450728683-31416-2-git-send-email-damien.riegel@savoirfairelinux.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

The current MSI framework can only support 256 platform MSIs. But on Hisilicon
platform, some network related devices has about 500 wired interrupts.

To support these devices and align with MSI-X increase the maximum to 2048
devices.
Signed-off-by: NMa Jun <majun258@huawei.com>
Cc: <Catalin.Marinas@arm.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <Will.Deacon@arm.com>
Cc: <mark.rutland@arm.com>
Cc: <marc.zyngier@arm.com>
Cc: <jason@lakedaemon.net>
Cc: <lizefan@huawei.com>
Cc: <huxinwei@huawei.com>
Cc: <dingtianhong@huawei.com>
Cc: <liguozhu@hisilicon.com>
Cc: <guohanjun@huawei.com>
Link: http://lkml.kernel.org/r/1450752442-9392-1-git-send-email-majun258@huawei.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

This patch contain fixes for v2m resources and SPI ranges:

  * Fix off-by-one error when set up v2m resource end range in
    gicv2m_acpi_init().

  * Fix the off-by-one print error for SPI range.

  * Use %pR to properly print resource range information.

Both ACPI and DT should now print:

  GICv2m: range[mem 0xe1180000-0xe1180fff], SPI[64:319]
Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>
Cc: <hanjun.guo@linaro.org>
Cc: <tomasz.nowicki@linaro.org>
Cc: <graeme.gregory@linaro.org>
Cc: <dhdang@apm.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <marc.zyngier@arm.com>
Cc: <jason@lakedaemon.net>
Cc: <rjw@rjwysocki.net>
Link: http://lkml.kernel.org/r/1450830263-28914-1-git-send-email-Suravee.Suthikulpanit@amd.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Avoid using hardcoded magics. We have a #define for this number.
No functional changes.
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NEric Anholt <eric@anholt.net>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Lee Jones <lee@kernel.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-rpi-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1451166444-11044-5-git-send-email-eric@anholt.netSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

On my RPi2 I got a lot of:
unexpected IRQ trap at vector 00

This happens because bcm2836_arm_irqchip_handle_irq() is sometimes
invoked even if the ISR is clear, and this case is not handled.

This patch explicitly handle this case, fixing the kernel complaints
about the bad IRQ lookup.
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NEric Anholt <eric@anholt.net>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Lee Jones <lee@kernel.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-rpi-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1451166444-11044-4-git-send-email-eric@anholt.netSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

The firmware sets the secondaries spinning waiting for a non-NULL
value to show up in the last IPI mailbox.

The original SMP port from the downstream tree was done by Andrea, and
Eric cleaned it up/rewrote it a few times from there.
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Lee Jones <lee@kernel.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-rpi-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1451166444-11044-3-git-send-email-eric@anholt.netSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

The irqchip's register area includes the the setup for the timer's
scaling factors, and for the platform we want a fixed configuration of
these registers.
Signed-off-by: NEric Anholt <eric@anholt.net>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Lee Jones <lee@kernel.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-rpi-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1451166444-11044-2-git-send-email-eric@anholt.netSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

This patch introduces gicv2m_acpi_init(), which uses information
in MADT GIC MSI frames structure to initialize GICv2m driver.
It also exposes gicv2m_init() function, which simplifies callers
to a single GICv2m init function.
Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
Tested-by: NDuc Dang <dhdang@apm.com>
Acked-by: NRafael J. Wysocki <rjw@rjwysocki.net>
Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

This patch replaces the struct device_node with struct fwnode_handle
since this structure is common between DT and ACPI.

It also refactors gicv2m_init_one() to prepare for ACPI support.
The only functional change is removing the node name from pr_info.
Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Since there will be several places checking if fwnode.type
is equal FWNODE_IRQCHIP, this patch adds a convenient function
for this purpose.
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

This patch introduces pci_msi_register_fwnode_provider() for irqchip
to register a callback, to provide a way to determine appropriate MSI
domain for a pci device.

It also introduces pci_host_bridge_acpi_msi_domain(), which returns
the MSI domain of the specified PCI host bridge with DOMAIN_BUS_PCI_MSI
bus token. Then, it is assigned to pci device.
Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rjw@rjwysocki.net>
Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

The Linux kernel already has the concept of IRQ domain, wherein a
component can expose a set of IRQs which are managed by a particular
interrupt controller chip or other subsystem. The PCI driver exposes
the notion of an IRQ domain for Message-Signaled Interrupts (MSI) from
PCI Express devices. This patch exposes the functions which are
necessary for creating a MSI IRQ domain within a module.

[ tglx: Split it into x86 and core irq parts ]
Signed-off-by: NJake Oshins <jakeo@microsoft.com>
Cc: gregkh@linuxfoundation.org
Cc: kys@microsoft.com
Cc: devel@linuxdriverproject.org
Cc: olaf@aepfle.de
Cc: apw@canonical.com
Cc: vkuznets@redhat.com
Cc: haiyangz@microsoft.com
Cc: marc.zyngier@arm.com
Cc: bhelgaas@google.com
Link: http://lkml.kernel.org/r/1449769983-12948-4-git-send-email-jakeo@microsoft.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Add the interrupt controller chip operation functions of mbigen chip.
Signed-off-by: NMa Jun <majun258@huawei.com>
Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

For peripheral devices which connect to mbigen,mbigen is a interrupt
controller. So, we create irq domain for each mbigen device and add
mbigen irq domain into irq hierarchy structure.
Signed-off-by: NMa Jun <majun258@huawei.com>
Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Mbigen means Message Based Interrupt Generator(MBIGEN).

Its a kind of interrupt controller that collects
the interrupts from external devices and generate msi interrupt.
Mbigen is applied to reduce the number of wire connected interrupts.

As the peripherals increasing, the interrupts lines needed is
increasing much, especially on the Arm64 server SOC.

Therefore, the interrupt pin in GIC is not enough to cover so
many peripherals.

Mbigen is designed to fix this problem.

Mbigen chip locates in ITS or outside of ITS.

Mbigen chip hardware structure shows as below:

		mbigen chip
|---------------------|-------------------|
mgn_node0	  mgn_node1		mgn_node2
 |		 |-------|		|-------|------|
dev1		dev1    dev2		dev1   dev3   dev4

Each mbigen chip contains several mbigen nodes.

External devices can connect to mbigen node through wire connecting way.

Because a mbigen node only can support 128 interrupt maximum, depends
on the interrupt lines number of devices, a device can connects to one
more mbigen nodes.

Also, several different devices can connect to a same mbigen node.

When devices triggered interrupt,mbigen chip detects and collects
the interrupts and generates the MBI interrupts by writing the ITS
Translator register.

To simplify mbigen driver,I used a new conception--mbigen device.
Each mbigen device is initialized as a platform device.

Mbigen device presents the parts(register, pin definition etc.) in
mbigen chip corresponding to a peripheral device.

So from software view, the structure likes below

	            mbigen chip
     |---------------------|-----------------|
mbigen device1       mbigen device2  mbigen device3
      |                   |                |
     dev1                dev2             dev3
Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NMa Jun <majun258@huawei.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

There is currently a hack in the GIC driver making it possible
to pass the number of GIC instances from the platform-specific
include files and thus override the variable MAX_GIC_NR.

With multiplatform deployments, this will not work as we need
to get rid of the platform-specific include files.

It turns out that this feature is only used by the RealView
platform which has a cascaded GIC. So move the configuration
to Kconfig and bump to 2 instances if we're building for the
RealView. The include file hacks can then be removed.

Tested on the ARM PB11MPCore with its cascaded GIC.
Suggested-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

The GIC has no such thing as interrupt 1020: the last valid ID is
1019, and the range 1020-1023 is reserved - 1023 indicating that
no interrupt is pending. So let's make sure we don't try to handle
this ID.

This bug has been in since the initial GIC code was introduced in
8ad68bbf ("[ARM] Add support for ARM RealView board").
Reported-by: NEric Auger <eric.auger@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

On the error path, the v2m drivers drops the refcount on the parent
node instead of doing it on the node that generated the error.
Humph...
Reported-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Instead of having the irqchip being a static struct, make it part
of the per-instance data so we can assign it a dynamic name. This
has the usable side effect of displaying the GIC with an instance
number as GIC0, GIC1 ... GICn in /proc/interrupts, which is helpful
when debugging cascaded GICs, such as on the ARM PB11MPCore.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

The ARM RealView PB11MPCore reference design has some special
bits in a system controller register to set up the GIC in one
of three modes: legacy, new with DCC, new without DCC. The
register is also used to enable FIQ.

Since the platform will not boot unless this register is set
up to "new with DCC" mode, we need a special quirk to be
compiled-in for the RealView platforms.

If we find the right compatible string on the GIC TestChip,
we enable this quirk by looking up the system controller and
enabling the special bits.

We depend on the CONFIG_REALVIEW_DT Kconfig symbol as the old
boardfile code has the same fix hardcoded, and this is only
needed for the attempts to modernize the RealView code using
device tree.

After fixing this, the PB11MPCore boots with device tree
only.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

We almost have all the needed bits requiredable to create a irq domain
on top of a MSI domain.

For this, we enable a few things:
- the virq is stored in the msi_desc
- device, msi_alloc_info and domain-specific data
  are stored in the platform_priv_data structure
- we introduce a new API for platform-msi:

  /* Create a MSI-based domain */
  struct irq_domain *
  platform_msi_create_device_domain(struct device *dev,
                                    unsigned int nvec,
                                    irq_write_msi_msg_t write_msi_msg,
                                    const struct irq_domain_ops *ops,
                                    void *host_data);

  /* Allocate MSIs in an MSI domain */
  int platform_msi_domain_alloc(struct irq_domain *domain,
				unsigned int virq,
				unsigned int nr_irqs);

  /* Free MSIs from an MSI domain */
  void platform_msi_domain_free(struct irq_domain *domain,
				unsigned int virq,
				unsigned int nvec);

  /* Obtain the host data passed to platform_msi_create_device_domain */
  void *platform_msi_get_host_data(struct irq_domain *domain);

platform_msi_create_device_domain() is a hybrid of irqdomain creation
and interrupt allocation, creating a domain backed by the MSIs associated
to a device. IRQs can then be allocated in that domain using
platform_msi_domain_alloc().

This now allows a wired irq to MSI bridge to be created.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

As we're going to have multiple paths to allocate/free the
platform-msi private data, factor this out into separate
utility functions.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

MSIs for a given device are normally all allocated in one go.
Make sure the internal code can allocate them one at a time
if required.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Commit bdee237c ("x86: mm: Use 2GB memory block size on large-memory
x86-64 systems") and 982792c7 ("x86, mm: probe memory block size for
generic x86 64bit") introduced large block sizes for x86.  This made it
possible to have multiple sections per memory block where previously,
there was a only every one section per block.

Since blocks consist of contiguous ranges of section, there can be holes
in the blocks where sections are not present.  If one attempts to
offline such a block, a crash occurs since the code is not designed to
deal with this.

This patch is a quick fix to gaurd against the crash by not allowing
blocks with non-present sections to be offlined.

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=107781Signed-off-by: NSeth Jennings <sjennings@variantweb.net>
Reported-by: NAndrew Banman <abanman@sgi.com>
Cc: Daniel J Blueman <daniel@numascale.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Greg KH <greg@kroah.com>
Cc: Russ Anderson <rja@sgi.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When using the Promise TX2+ SATA controller on PA-RISC, the system often
crashes with kernel panic, for example just writing data with the dd
utility will make it crash.

Kernel panic - not syncing: drivers/parisc/sba_iommu.c: I/O MMU @ 000000000000a000 is out of mapping resources

CPU: 0 PID: 18442 Comm: mkspadfs Not tainted 4.4.0-rc2 #2
Backtrace:
 [<000000004021497c>] show_stack+0x14/0x20
 [<0000000040410bf0>] dump_stack+0x88/0x100
 [<000000004023978c>] panic+0x124/0x360
 [<0000000040452c18>] sba_alloc_range+0x698/0x6a0
 [<0000000040453150>] sba_map_sg+0x260/0x5b8
 [<000000000c18dbb4>] ata_qc_issue+0x264/0x4a8 [libata]
 [<000000000c19535c>] ata_scsi_translate+0xe4/0x220 [libata]
 [<000000000c19a93c>] ata_scsi_queuecmd+0xbc/0x320 [libata]
 [<0000000040499bbc>] scsi_dispatch_cmd+0xfc/0x130
 [<000000004049da34>] scsi_request_fn+0x6e4/0x970
 [<00000000403e95a8>] __blk_run_queue+0x40/0x60
 [<00000000403e9d8c>] blk_run_queue+0x3c/0x68
 [<000000004049a534>] scsi_run_queue+0x2a4/0x360
 [<000000004049be68>] scsi_end_request+0x1a8/0x238
 [<000000004049de84>] scsi_io_completion+0xfc/0x688
 [<0000000040493c74>] scsi_finish_command+0x17c/0x1d0

The cause of the crash is not exhaustion of the IOMMU space, there is
plenty of free pages. The function sba_alloc_range is called with size
0x11000, thus the pages_needed variable is 0x11. The function
sba_search_bitmap is called with bits_wanted 0x11 and boundary size is
0x10 (because dma_get_seg_boundary(dev) returns 0xffff).

The function sba_search_bitmap attempts to allocate 17 pages that must not
cross 16-page boundary - it can't satisfy this requirement
(iommu_is_span_boundary always returns true) and fails even if there are
many free entries in the IOMMU space.

How did it happen that we try to allocate 17 pages that don't cross
16-page boundary? The cause is in the function iommu_coalesce_chunks. This
function tries to coalesce adjacent entries in the scatterlist. The
function does several checks if it may coalesce one entry with the next,
one of those checks is this:

	if (startsg->length + dma_len > max_seg_size)
		break;

When it finishes coalescing adjacent entries, it allocates the mapping:

sg_dma_len(contig_sg) = dma_len;
dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
sg_dma_address(contig_sg) =
	PIDE_FLAG
	| (iommu_alloc_range(ioc, dev, dma_len) << IOVP_SHIFT)
	| dma_offset;

It is possible that (startsg->length + dma_len > max_seg_size) is false
(we are just near the 0x10000 max_seg_size boundary), so the funcion
decides to coalesce this entry with the next entry. When the coalescing
succeeds, the function performs
	dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
And now, because of non-zero dma_offset, dma_len is greater than 0x10000.
iommu_alloc_range (a pointer to sba_alloc_range) is called and it attempts
to allocate 17 pages for a device that must not cross 16-page boundary.

To fix the bug, we must make sure that dma_len after addition of
dma_offset and alignment doesn't cross the segment boundary. I.e. change
	if (startsg->length + dma_len > max_seg_size)
		break;
to
	if (ALIGN(dma_len + dma_offset + startsg->length, IOVP_SIZE) > max_seg_size)
		break;

This patch makes this change (it precalculates max_seg_boundary at the
beginning of the function iommu_coalesce_chunks). I also added a check
that the mapping length doesn't exceed dma_get_seg_boundary(dev) (it is
not needed for Promise TX2+ SATA, but it may be needed for other devices
that have dma_get_seg_boundary lower than dma_get_max_seg_size).
Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NHelge Deller <deller@gmx.de>

Some USB device / host controller combinations seem to have problems
with Link Power Management.  For example, Steinar found that his xHCI
controller wouldn't handle bandwidth calculations correctly for two
video cards simultaneously when LPM was enabled, even though the bus
had plenty of bandwidth available.

This patch introduces a new quirk flag for devices that should remain
disabled for LPM, and creates quirk entries for Steinar's devices.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NSteinar H. Gunderson <sgunderson@bigfoot.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

According to USB 2 specs ports need to signal resume for at least 20ms,
in practice even longer, before moving to U0 state.
Both host and devices can initiate resume.

On device initiated resume, a port status interrupt with the port in resume
state in issued. The interrupt handler tags a resume_done[port]
timestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer.
Root hub timer requests for port status, finds the port in resume state,
checks if resume_done[port] timestamp passed, and set port to U0 state.

On host initiated resume, current code sets the port to resume state,
sleep 20ms, and finally sets the port to U0 state. This should also
be changed to work in a similar way as the device initiated resume, with
timestamp tagging, but that is not yet tested and will be a separate
fix later.

There are a few issues with this approach

1. A host initiated resume will also generate a resume event. The event
   handler will find the port in resume state, believe it's a device
   initiated resume, and act accordingly.

2. A port status request might cut the resume signalling short if a
   get_port_status request is handled during the host resume signalling.
   The port will be found in resume state. The timestamp is not set leading
   to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0.
   get_port_status will proceed with moving the port to U0.

3. If an error, or anything else happens to the port during device
   initiated resume signalling it will leave all the device resume
   parameters hanging uncleared, preventing further suspend, returning
   -EBUSY, and cause the pm thread to busyloop trying to enter suspend.

Fix this by using the existing resuming_ports bitfield to indicate that
resume signalling timing is taken care of.
Check if the resume_done[port] is set before using it for timestamp
comparison, and also clear out any resume signalling related variables
if port is not in U0 or Resume state

This issue was discovered when a PM thread busylooped, trying to runtime
suspend the xhci USB 2 roothub on a Dell XPS

Cc: stable <stable@vger.kernel.org>
Reported-by: NDaniel J Blueman <daniel@quora.org>
Tested-by: NDaniel J Blueman <daniel@quora.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are few defects in vga_get() related to signal hadning:

  - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE
    case;

  - if we found pending signal we must remove ourself from wait queue
    and change task state back to running;

  - -ERESTARTSYS is more appropriate, I guess.
Signed-off-by: NKirill A. Shutemov <kirill@shutemov.name>
Cc: stable@vger.kernel.org
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The EP93xx is registering a clocksource of 40 bits with
clocksource_mmio_init() but this is not working because of this
artificial limitation. It works fine to lift the uppe limit to
64 bits, and since cycle_t is u64, it should intuitively have been
like that from the beginning.

Fixes: 000bc178 "ARM: ep93xx: switch to GENERIC_CLOCKEVENTS"
Reported-by: NAlexander Sverdlin <alexander.sverdlin@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: http://lkml.kernel.org/r/1449768101-6879-1-git-send-email-linus.walleij@linaro.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

If dm_btree_del()'s call to push_frame() fails, e.g. due to
btree_node_validator finding invalid metadata, the dm_btree_del() error
path must unlock all frames (which have active dm-bufio buffers) that
were pushed onto the del_stack.

Otherwise, dm_bufio_client_destroy() will BUG_ON() because dm-bufio
buffers have leaked, e.g.:
  device-mapper: bufio: leaked buffer 3, hold count 1, list 0
Signed-off-by: NJoe Thornber <ejt@redhat.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org

We encountered a panic on boot in ipmi_si on a dell per320 due to an
uninitialized timer as follows.

static int smi_start_processing(void       *send_info,
                                ipmi_smi_t intf)
{
        /* Try to claim any interrupts. */
        if (new_smi->irq_setup)
                new_smi->irq_setup(new_smi);

 --> IRQ arrives here and irq handler tries to modify uninitialized timer

    which triggers BUG_ON(!timer->function) in __mod_timer().

 Call Trace:
   <IRQ>
   [<ffffffffa0532617>] start_new_msg+0x47/0x80 [ipmi_si]
   [<ffffffffa053269e>] start_check_enables+0x4e/0x60 [ipmi_si]
   [<ffffffffa0532bd8>] smi_event_handler+0x1e8/0x640 [ipmi_si]
   [<ffffffff810f5584>] ? __rcu_process_callbacks+0x54/0x350
   [<ffffffffa053327c>] si_irq_handler+0x3c/0x60 [ipmi_si]
   [<ffffffff810efaf0>] handle_IRQ_event+0x60/0x170
   [<ffffffff810f245e>] handle_edge_irq+0xde/0x180
   [<ffffffff8100fc59>] handle_irq+0x49/0xa0
   [<ffffffff8154643c>] do_IRQ+0x6c/0xf0
   [<ffffffff8100ba53>] ret_from_intr+0x0/0x11

        /* Set up the timer that drives the interface. */
        setup_timer(&new_smi->si_timer, smi_timeout, (long)new_smi);

The following patch fixes the problem.

To: Openipmi-developer@lists.sourceforge.net
To: Corey Minyard <minyard@acm.org>
CC: linux-kernel@vger.kernel.org
Signed-off-by: NJan Stancek <jstancek@redhat.com>
Signed-off-by: NTony Camuso <tcamuso@redhat.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Cc: stable@vger.kernel.org # Applies cleanly to 3.10-, needs small rework before

When applying block operations (BOPs) do not remove them from the
uncommitted BOP ring-buffer until after they've been applied -- in case
we recurse.

Also, perform BOP_INC operation, in dm_sm_metadata_create() and
sm_metadata_extend(), in terms of the uncommitted BOP ring-buffer rather
than using direct calls to sm_ll_inc().
Signed-off-by: NJoe Thornber <ejt@redhat.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org

When you take a metadata snapshot the btree roots for the mapping and
details tree need to have their reference counts incremented so they
persist for the lifetime of the metadata snap.

The roots being incremented were those currently written in the
superblock, which could possibly be out of date if concurrent IO is
triggering new mappings, breaking of sharing, etc.

Fix this by performing a commit with the metadata lock held while taking
a metadata snapshot.
Signed-off-by: NJoe Thornber <ejt@redhat.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org

Fail with error when no DMA controller is set.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

of_irq_find_parent was made static since it had no users outside of
of_irq.c. Export it again since we are going to use it again.
Signed-off-by: NCarlo Caione <carlo@endlessm.com>
[robh: move of_irq_find_parent to correct ifdef section]
Signed-off-by: NRob Herring <robh@kernel.org>

This patch makes the VCE IB test pass on Big-Endian systems. It converts
to little-endian the contents of the VCE message.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This patch fixes the VCE ring test when running on Big-Endian machines.
Every write to the ring needs to be translated to little-endian.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This patch makes the IB test on the GFX ring pass for CI-based cards
installed in Big-Endian machines.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NChunming Zhou <David1.Zhou@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>
Cc: stable@vger.kernel.org

NVIDIA have indicated that the workaround is required on all GK10[467]
boards that have the PGOB fuse set.

I've left the commandline option in place for now, as paranoia.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>