<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/pci, branch v3.16.35</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>PCI: Disable IO/MEM decoding for devices with non-compliant BARs</title>
<updated>2016-04-30T22:05:50+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2016-02-25T20:35:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fa02bc48bbd771393c75c5663f00225bf233b0bc'/>
<id>fa02bc48bbd771393c75c5663f00225bf233b0bc</id>
<content type='text'>
commit b84106b4e2290c081cdab521fa832596cdfea246 upstream.

The PCI config header (first 64 bytes of each device's config space) is
defined by the PCI spec so generic software can identify the device and
manage its usage of I/O, memory, and IRQ resources.

Some non-spec-compliant devices put registers other than BARs where the
BARs should be.  When the PCI core sizes these "BARs", the reads and writes
it does may have unwanted side effects, and the "BAR" may appear to
describe non-sensical address space.

Add a flag bit to mark non-compliant devices so we don't touch their BARs.
Turn off IO/MEM decoding to prevent the devices from consuming address
space, since we can't read the BARs to find out what that address space
would be.

Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Andi Kleen &lt;ak@linux.intel.com&gt;
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b84106b4e2290c081cdab521fa832596cdfea246 upstream.

The PCI config header (first 64 bytes of each device's config space) is
defined by the PCI spec so generic software can identify the device and
manage its usage of I/O, memory, and IRQ resources.

Some non-spec-compliant devices put registers other than BARs where the
BARs should be.  When the PCI core sizes these "BARs", the reads and writes
it does may have unwanted side effects, and the "BAR" may appear to
describe non-sensical address space.

Add a flag bit to mark non-compliant devices so we don't touch their BARs.
Turn off IO/MEM decoding to prevent the devices from consuming address
space, since we can't read the BARs to find out what that address space
would be.

Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Andi Kleen &lt;ak@linux.intel.com&gt;
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: imx6: Move link up check into imx6_pcie_wait_for_link()</title>
<updated>2016-04-30T22:05:44+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2016-01-25T22:50:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=92d27c4aaca0d15bb742de785dfd57f0f68aa586'/>
<id>92d27c4aaca0d15bb742de785dfd57f0f68aa586</id>
<content type='text'>
commit 4d107d3b5a686b5834e533a00b73bf7b1cf59df7 upstream.

imx6_pcie_link_up() previously used usleep_range() to wait for the link to
come up.  Since it may be called while holding the config spinlock, the
sleep causes a "BUG: scheduling while atomic" error.

Instead of waiting for the link to come up in imx6_pcie_link_up(), do the
waiting in imx6_pcie_wait_for_link(), where we're not holding a lock and
sleeping is allowed.

[bhelgaas: changelog, references to bugzilla and f95d3ae77191]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=100031
Fixes: f95d3ae77191 ("PCI: imx6: Wait for retraining")
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
[bwh: Backported to 3.16: also update the retry loop in
 imx6_pcie_wait_for_link() as done upstream in commit 6cbb247e85eb
 ("PCI: designware: Wait for link to come up with consistent style")]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4d107d3b5a686b5834e533a00b73bf7b1cf59df7 upstream.

imx6_pcie_link_up() previously used usleep_range() to wait for the link to
come up.  Since it may be called while holding the config spinlock, the
sleep causes a "BUG: scheduling while atomic" error.

Instead of waiting for the link to come up in imx6_pcie_link_up(), do the
waiting in imx6_pcie_wait_for_link(), where we're not holding a lock and
sleeping is allowed.

[bhelgaas: changelog, references to bugzilla and f95d3ae77191]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=100031
Fixes: f95d3ae77191 ("PCI: imx6: Wait for retraining")
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
[bwh: Backported to 3.16: also update the retry loop in
 imx6_pcie_wait_for_link() as done upstream in commit 6cbb247e85eb
 ("PCI: designware: Wait for link to come up with consistent style")]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: imx6: Remove broken Gen2 workaround</title>
<updated>2016-04-30T22:05:44+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2016-01-25T22:49:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f5aa19a43aaba8be755936fa2dbe93404fcec169'/>
<id>f5aa19a43aaba8be755936fa2dbe93404fcec169</id>
<content type='text'>
commit a77c5422d7586003643377afdb9915e76d07d21c upstream.

Remove the remnants of the workaround for erratum ERR005184 which was never
completely implemented.  The checks alone don't carry any value as we don't
act properly on the result.

A workaround should be added to the lane speed change in establish_link
later.

Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a77c5422d7586003643377afdb9915e76d07d21c upstream.

Remove the remnants of the workaround for erratum ERR005184 which was never
completely implemented.  The checks alone don't carry any value as we don't
act properly on the result.

A workaround should be added to the lane speed change in establish_link
later.

Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: imx6: Move PHY reset into imx6_pcie_establish_link()</title>
<updated>2016-04-30T22:05:44+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2016-01-25T22:49:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=79a854239e3ad02b0a369f16767173ff546633a0'/>
<id>79a854239e3ad02b0a369f16767173ff546633a0</id>
<content type='text'>
commit 54a47a83421a3b7ee0e0fab7f65d04179bdf59b6 upstream.

This adds the PHY reset into a common error path of
imx6_pcie_establish_link(), deduplicating some of the debug prints.  Also
reduce the severity of the "no-link" message in the one place where it is
expected to be hit when no peripheral is attached.

Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
[bwh: Backported to 3.16:
 - Error paths were different in imx6_pcie_start_link()
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 54a47a83421a3b7ee0e0fab7f65d04179bdf59b6 upstream.

This adds the PHY reset into a common error path of
imx6_pcie_establish_link(), deduplicating some of the debug prints.  Also
reduce the severity of the "no-link" message in the one place where it is
expected to be hit when no peripheral is attached.

Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
[bwh: Backported to 3.16:
 - Error paths were different in imx6_pcie_start_link()
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: imx6: Move imx6_pcie_reset_phy() near other PHY handling functions</title>
<updated>2016-04-30T22:05:44+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2016-01-15T18:56:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2ede10574e05887ee4b254e852dde1912990bdbc'/>
<id>2ede10574e05887ee4b254e852dde1912990bdbc</id>
<content type='text'>
commit 53eeb48b49410a47a0309bbc0516534ad71c1350 upstream.

Move imx6_pcie_reset_phy() near the other PHY related functions in the
file.  This is a cosmetic change, but also allows to do the following
changes without introducing needless forward declarations.

Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
[bwh: Prerequisite for commit 4d107d3b5a68 ("PCI: imx6: Move link up check into
 imx6_pcie_wait_for_link()").
 Backported to 3.16: apply the relevant changes from commit 1c7fae18a1fb
 ("PCI: imx6: Use "u32", not "uint32_t"")]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 53eeb48b49410a47a0309bbc0516534ad71c1350 upstream.

Move imx6_pcie_reset_phy() near the other PHY related functions in the
file.  This is a cosmetic change, but also allows to do the following
changes without introducing needless forward declarations.

Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
[bwh: Prerequisite for commit 4d107d3b5a68 ("PCI: imx6: Move link up check into
 imx6_pcie_wait_for_link()").
 Backported to 3.16: apply the relevant changes from commit 1c7fae18a1fb
 ("PCI: imx6: Use "u32", not "uint32_t"")]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted.</title>
<updated>2016-03-08T12:15:21+00:00</updated>
<author>
<name>Konrad Rzeszutek Wilk</name>
<email>konrad.wilk@oracle.com</email>
</author>
<published>2016-02-11T21:10:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2b599597d40e33b7b2ca79594e0dab5619ce4ef6'/>
<id>2b599597d40e33b7b2ca79594e0dab5619ce4ef6</id>
<content type='text'>
commit 4d8c8bd6f2062c9988817183a91fe2e623c8aa5e upstream.

Occasionaly PV guests would crash with:

pciback 0000:00:00.1: Xen PCI mapped GSI0 to IRQ16
BUG: unable to handle kernel paging request at 0000000d1a8c0be0
.. snip..
  &lt;ffffffff8139ce1b&gt;] find_next_bit+0xb/0x10
  [&lt;ffffffff81387f22&gt;] cpumask_next_and+0x22/0x40
  [&lt;ffffffff813c1ef8&gt;] pci_device_probe+0xb8/0x120
  [&lt;ffffffff81529097&gt;] ? driver_sysfs_add+0x77/0xa0
  [&lt;ffffffff815293e4&gt;] driver_probe_device+0x1a4/0x2d0
  [&lt;ffffffff813c1ddd&gt;] ? pci_match_device+0xdd/0x110
  [&lt;ffffffff81529657&gt;] __device_attach_driver+0xa7/0xb0
  [&lt;ffffffff815295b0&gt;] ? __driver_attach+0xa0/0xa0
  [&lt;ffffffff81527622&gt;] bus_for_each_drv+0x62/0x90
  [&lt;ffffffff8152978d&gt;] __device_attach+0xbd/0x110
  [&lt;ffffffff815297fb&gt;] device_attach+0xb/0x10
  [&lt;ffffffff813b75ac&gt;] pci_bus_add_device+0x3c/0x70
  [&lt;ffffffff813b7618&gt;] pci_bus_add_devices+0x38/0x80
  [&lt;ffffffff813dc34e&gt;] pcifront_scan_root+0x13e/0x1a0
  [&lt;ffffffff817a0692&gt;] pcifront_backend_changed+0x262/0x60b
  [&lt;ffffffff814644c6&gt;] ? xenbus_gather+0xd6/0x160
  [&lt;ffffffff8120900f&gt;] ? put_object+0x2f/0x50
  [&lt;ffffffff81465c1d&gt;] xenbus_otherend_changed+0x9d/0xa0
  [&lt;ffffffff814678ee&gt;] backend_changed+0xe/0x10
  [&lt;ffffffff81463a28&gt;] xenwatch_thread+0xc8/0x190
  [&lt;ffffffff810f22f0&gt;] ? woken_wake_function+0x10/0x10

which was the result of two things:

When we call pci_scan_root_bus we would pass in 'sd' (sysdata)
pointer which was an 'pcifront_sd' structure. However in the
pci_device_add it expects that the 'sd' is 'struct sysdata' and
sets the dev-&gt;node to what is in sd-&gt;node (offset 4):

set_dev_node(&amp;dev-&gt;dev, pcibus_to_node(bus));

 __pcibus_to_node(const struct pci_bus *bus)
{
        const struct pci_sysdata *sd = bus-&gt;sysdata;

        return sd-&gt;node;
}

However our structure was pcifront_sd which had nothing at that
offset:

struct pcifront_sd {
        int                        domain;    /*     0     4 */
        /* XXX 4 bytes hole, try to pack */
        struct pcifront_device *   pdev;      /*     8     8 */
}

That is an hole - filled with garbage as we used kmalloc instead of
kzalloc (the second problem).

This patch fixes the issue by:
 1) Use kzalloc to initialize to a well known state.
 2) Put 'struct pci_sysdata' at the start of 'pcifront_sd'. That
    way access to the 'node' will access the right offset.

Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4d8c8bd6f2062c9988817183a91fe2e623c8aa5e upstream.

Occasionaly PV guests would crash with:

pciback 0000:00:00.1: Xen PCI mapped GSI0 to IRQ16
BUG: unable to handle kernel paging request at 0000000d1a8c0be0
.. snip..
  &lt;ffffffff8139ce1b&gt;] find_next_bit+0xb/0x10
  [&lt;ffffffff81387f22&gt;] cpumask_next_and+0x22/0x40
  [&lt;ffffffff813c1ef8&gt;] pci_device_probe+0xb8/0x120
  [&lt;ffffffff81529097&gt;] ? driver_sysfs_add+0x77/0xa0
  [&lt;ffffffff815293e4&gt;] driver_probe_device+0x1a4/0x2d0
  [&lt;ffffffff813c1ddd&gt;] ? pci_match_device+0xdd/0x110
  [&lt;ffffffff81529657&gt;] __device_attach_driver+0xa7/0xb0
  [&lt;ffffffff815295b0&gt;] ? __driver_attach+0xa0/0xa0
  [&lt;ffffffff81527622&gt;] bus_for_each_drv+0x62/0x90
  [&lt;ffffffff8152978d&gt;] __device_attach+0xbd/0x110
  [&lt;ffffffff815297fb&gt;] device_attach+0xb/0x10
  [&lt;ffffffff813b75ac&gt;] pci_bus_add_device+0x3c/0x70
  [&lt;ffffffff813b7618&gt;] pci_bus_add_devices+0x38/0x80
  [&lt;ffffffff813dc34e&gt;] pcifront_scan_root+0x13e/0x1a0
  [&lt;ffffffff817a0692&gt;] pcifront_backend_changed+0x262/0x60b
  [&lt;ffffffff814644c6&gt;] ? xenbus_gather+0xd6/0x160
  [&lt;ffffffff8120900f&gt;] ? put_object+0x2f/0x50
  [&lt;ffffffff81465c1d&gt;] xenbus_otherend_changed+0x9d/0xa0
  [&lt;ffffffff814678ee&gt;] backend_changed+0xe/0x10
  [&lt;ffffffff81463a28&gt;] xenwatch_thread+0xc8/0x190
  [&lt;ffffffff810f22f0&gt;] ? woken_wake_function+0x10/0x10

which was the result of two things:

When we call pci_scan_root_bus we would pass in 'sd' (sysdata)
pointer which was an 'pcifront_sd' structure. However in the
pci_device_add it expects that the 'sd' is 'struct sysdata' and
sets the dev-&gt;node to what is in sd-&gt;node (offset 4):

set_dev_node(&amp;dev-&gt;dev, pcibus_to_node(bus));

 __pcibus_to_node(const struct pci_bus *bus)
{
        const struct pci_sysdata *sd = bus-&gt;sysdata;

        return sd-&gt;node;
}

However our structure was pcifront_sd which had nothing at that
offset:

struct pcifront_sd {
        int                        domain;    /*     0     4 */
        /* XXX 4 bytes hole, try to pack */
        struct pcifront_device *   pdev;      /*     8     8 */
}

That is an hole - filled with garbage as we used kmalloc instead of
kzalloc (the second problem).

This patch fixes the issue by:
 1) Use kzalloc to initialize to a well known state.
 2) Put 'struct pci_sysdata' at the start of 'pcifront_sd'. That
    way access to the 'node' will access the right offset.

Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI/AER: Flush workqueue on device remove to avoid use-after-free</title>
<updated>2016-02-25T00:18:35+00:00</updated>
<author>
<name>Sebastian Andrzej Siewior</name>
<email>bigeasy@linutronix.de</email>
</author>
<published>2016-01-25T16:08:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3a170fdad961ca1178ee82752722f23f957868c6'/>
<id>3a170fdad961ca1178ee82752722f23f957868c6</id>
<content type='text'>
commit 4ae2182b1e3407de369f8c5d799543b7db74221b upstream.

A Root Port's AER structure (rpc) contains a queue of events.  aer_irq()
enqueues AER status information and schedules aer_isr() to dequeue and
process it.  When we remove a device, aer_remove() waits for the queue to
be empty, then frees the rpc struct.

But aer_isr() references the rpc struct after dequeueing and possibly
emptying the queue, which can cause a use-after-free error as in the
following scenario with two threads, aer_isr() on the left and a
concurrent aer_remove() on the right:

  Thread A                      Thread B
  --------                      --------
  aer_irq():
    rpc-&gt;prod_idx++
                                aer_remove():
                                  wait_event(rpc-&gt;prod_idx == rpc-&gt;cons_idx)
                                  # now blocked until queue becomes empty
  aer_isr():                      # ...
    rpc-&gt;cons_idx++               # unblocked because queue is now empty
    ...                           kfree(rpc)
    mutex_unlock(&amp;rpc-&gt;rpc_mutex)

To prevent this problem, use flush_work() to wait until the last scheduled
instance of aer_isr() has completed before freeing the rpc struct in
aer_remove().

I reproduced this use-after-free by flashing a device FPGA and
re-enumerating the bus to find the new device.  With SLUB debug, this
crashes with 0x6b bytes (POISON_FREE, the use-after-free magic number) in
GPR25:

  pcieport 0000:00:00.0: AER: Multiple Corrected error received: id=0000
  Unable to handle kernel paging request for data at address 0x27ef9e3e
  Workqueue: events aer_isr
  GPR24: dd6aa000 6b6b6b6b 605f8378 605f8360 d99b12c0 604fc674 606b1704 d99b12c0
  NIP [602f5328] pci_walk_bus+0xd4/0x104

[bhelgaas: changelog, stable tag]
Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4ae2182b1e3407de369f8c5d799543b7db74221b upstream.

A Root Port's AER structure (rpc) contains a queue of events.  aer_irq()
enqueues AER status information and schedules aer_isr() to dequeue and
process it.  When we remove a device, aer_remove() waits for the queue to
be empty, then frees the rpc struct.

But aer_isr() references the rpc struct after dequeueing and possibly
emptying the queue, which can cause a use-after-free error as in the
following scenario with two threads, aer_isr() on the left and a
concurrent aer_remove() on the right:

  Thread A                      Thread B
  --------                      --------
  aer_irq():
    rpc-&gt;prod_idx++
                                aer_remove():
                                  wait_event(rpc-&gt;prod_idx == rpc-&gt;cons_idx)
                                  # now blocked until queue becomes empty
  aer_isr():                      # ...
    rpc-&gt;cons_idx++               # unblocked because queue is now empty
    ...                           kfree(rpc)
    mutex_unlock(&amp;rpc-&gt;rpc_mutex)

To prevent this problem, use flush_work() to wait until the last scheduled
instance of aer_isr() has completed before freeing the rpc struct in
aer_remove().

I reproduced this use-after-free by flashing a device FPGA and
re-enumerating the bus to find the new device.  With SLUB debug, this
crashes with 0x6b bytes (POISON_FREE, the use-after-free magic number) in
GPR25:

  pcieport 0000:00:00.0: AER: Multiple Corrected error received: id=0000
  Unable to handle kernel paging request for data at address 0x27ef9e3e
  Workqueue: events aer_isr
  GPR24: dd6aa000 6b6b6b6b 605f8378 605f8360 d99b12c0 604fc674 606b1704 d99b12c0
  NIP [602f5328] pci_walk_bus+0xd4/0x104

[bhelgaas: changelog, stable tag]
Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI / PCI / hotplug: unlock in error path in acpiphp_enable_slot()</title>
<updated>2016-02-16T19:50:02+00:00</updated>
<author>
<name>Insu Yun</name>
<email>wuninsu@gmail.com</email>
</author>
<published>2016-01-23T20:44:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e4fa01001270fcf5fefa4a2f11d6c793a9fee7db'/>
<id>e4fa01001270fcf5fefa4a2f11d6c793a9fee7db</id>
<content type='text'>
commit 2c3033a0664dfae91e1dee7fabac10f24354b958 upstream.

In acpiphp_enable_slot(), there is a missing unlock path
when error occurred.  It needs to be unlocked before returning
an error.

Signed-off-by: Insu Yun &lt;wuninsu@gmail.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2c3033a0664dfae91e1dee7fabac10f24354b958 upstream.

In acpiphp_enable_slot(), there is a missing unlock path
when error occurred.  It needs to be unlocked before returning
an error.

Signed-off-by: Insu Yun &lt;wuninsu@gmail.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: host: Mark PCIe/PCI (MSI) IRQ cascade handlers as IRQF_NO_THREAD</title>
<updated>2016-02-02T19:09:18+00:00</updated>
<author>
<name>Grygorii Strashko</name>
<email>grygorii.strashko@ti.com</email>
</author>
<published>2015-12-10T19:18:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3d238df7b81dbd0d558e0badb0869f623e3095fb'/>
<id>3d238df7b81dbd0d558e0badb0869f623e3095fb</id>
<content type='text'>
commit 8ff0ef996ca00028519c70e8d51d32bd37eb51dc upstream.

On -RT and if kernel is booting with "threadirqs" cmd line parameter,
PCIe/PCI (MSI) IRQ cascade handlers (like dra7xx_pcie_msi_irq_handler())
will be forced threaded and, as result, will generate warnings like this:

  WARNING: CPU: 1 PID: 82 at kernel/irq/handle.c:150 handle_irq_event_percpu+0x14c/0x174()
  irq 460 handler irq_default_primary_handler+0x0/0x14 enabled interrupts
  Backtrace:
   (warn_slowpath_common) from (warn_slowpath_fmt+0x38/0x40)
   (warn_slowpath_fmt) from (handle_irq_event_percpu+0x14c/0x174)
   (handle_irq_event_percpu) from (handle_irq_event+0x84/0xb8)
   (handle_irq_event) from (handle_simple_irq+0x90/0x118)
   (handle_simple_irq) from (generic_handle_irq+0x30/0x44)
   (generic_handle_irq) from (dra7xx_pcie_msi_irq_handler+0x7c/0x8c)
   (dra7xx_pcie_msi_irq_handler) from (irq_forced_thread_fn+0x28/0x5c)
   (irq_forced_thread_fn) from (irq_thread+0x128/0x204)

This happens because all of them invoke generic_handle_irq() from the
requested handler.  generic_handle_irq() grabs raw_locks and thus needs to
run in raw-IRQ context.

This issue was originally reproduced on TI dra7-evem, but, as was
identified during discussion [1], other hosts can also suffer from this
issue.  Fix all them at once by marking PCIe/PCI (MSI) IRQ cascade handlers
IRQF_NO_THREAD explicitly.

[1] http://lkml.kernel.org/r/1448027966-21610-1-git-send-email-grygorii.strashko@ti.com

[bhelgaas: add stable tag, fix typos]
Signed-off-by: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Lucas Stach &lt;l.stach@pengutronix.de&gt; (for imx6)
CC: Kishon Vijay Abraham I &lt;kishon@ti.com&gt;
CC: Jingoo Han &lt;jingoohan1@gmail.com&gt;
CC: Kukjin Kim &lt;kgene@kernel.org&gt;
CC: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
CC: Richard Zhu &lt;Richard.Zhu@freescale.com&gt;
CC: Thierry Reding &lt;thierry.reding@gmail.com&gt;
CC: Stephen Warren &lt;swarren@wwwdotorg.org&gt;
CC: Alexandre Courbot &lt;gnurou@gmail.com&gt;
CC: Simon Horman &lt;horms@verge.net.au&gt;
CC: Pratyush Anand &lt;pratyush.anand@gmail.com&gt;
CC: Michal Simek &lt;michal.simek@xilinx.com&gt;
CC: "Sören Brinkmann" &lt;soren.brinkmann@xilinx.com&gt;
CC: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
[ luis: backported to 3.16:
  - dropped changes to pci-dra7xx.c, pcie-spear13xx.c, pcie-xilinx.c
  - adjusted context ]
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8ff0ef996ca00028519c70e8d51d32bd37eb51dc upstream.

On -RT and if kernel is booting with "threadirqs" cmd line parameter,
PCIe/PCI (MSI) IRQ cascade handlers (like dra7xx_pcie_msi_irq_handler())
will be forced threaded and, as result, will generate warnings like this:

  WARNING: CPU: 1 PID: 82 at kernel/irq/handle.c:150 handle_irq_event_percpu+0x14c/0x174()
  irq 460 handler irq_default_primary_handler+0x0/0x14 enabled interrupts
  Backtrace:
   (warn_slowpath_common) from (warn_slowpath_fmt+0x38/0x40)
   (warn_slowpath_fmt) from (handle_irq_event_percpu+0x14c/0x174)
   (handle_irq_event_percpu) from (handle_irq_event+0x84/0xb8)
   (handle_irq_event) from (handle_simple_irq+0x90/0x118)
   (handle_simple_irq) from (generic_handle_irq+0x30/0x44)
   (generic_handle_irq) from (dra7xx_pcie_msi_irq_handler+0x7c/0x8c)
   (dra7xx_pcie_msi_irq_handler) from (irq_forced_thread_fn+0x28/0x5c)
   (irq_forced_thread_fn) from (irq_thread+0x128/0x204)

This happens because all of them invoke generic_handle_irq() from the
requested handler.  generic_handle_irq() grabs raw_locks and thus needs to
run in raw-IRQ context.

This issue was originally reproduced on TI dra7-evem, but, as was
identified during discussion [1], other hosts can also suffer from this
issue.  Fix all them at once by marking PCIe/PCI (MSI) IRQ cascade handlers
IRQF_NO_THREAD explicitly.

[1] http://lkml.kernel.org/r/1448027966-21610-1-git-send-email-grygorii.strashko@ti.com

[bhelgaas: add stable tag, fix typos]
Signed-off-by: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Lucas Stach &lt;l.stach@pengutronix.de&gt; (for imx6)
CC: Kishon Vijay Abraham I &lt;kishon@ti.com&gt;
CC: Jingoo Han &lt;jingoohan1@gmail.com&gt;
CC: Kukjin Kim &lt;kgene@kernel.org&gt;
CC: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
CC: Richard Zhu &lt;Richard.Zhu@freescale.com&gt;
CC: Thierry Reding &lt;thierry.reding@gmail.com&gt;
CC: Stephen Warren &lt;swarren@wwwdotorg.org&gt;
CC: Alexandre Courbot &lt;gnurou@gmail.com&gt;
CC: Simon Horman &lt;horms@verge.net.au&gt;
CC: Pratyush Anand &lt;pratyush.anand@gmail.com&gt;
CC: Michal Simek &lt;michal.simek@xilinx.com&gt;
CC: "Sören Brinkmann" &lt;soren.brinkmann@xilinx.com&gt;
CC: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
[ luis: backported to 3.16:
  - dropped changes to pci-dra7xx.c, pcie-spear13xx.c, pcie-xilinx.c
  - adjusted context ]
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Fix minimum allocation address overwrite</title>
<updated>2016-02-02T19:09:18+00:00</updated>
<author>
<name>Christoph Biedl</name>
<email>linux-kernel.bfrz@manchmal.in-ulm.de</email>
</author>
<published>2015-12-23T15:51:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=af74f90720b56839d2cd3be1496122ba5000dde4'/>
<id>af74f90720b56839d2cd3be1496122ba5000dde4</id>
<content type='text'>
commit 3460baa620685c20f5ee19afb6d99d26150c382c upstream.

Commit 36e097a8a297 ("PCI: Split out bridge window override of minimum
allocation address") claimed to do no functional changes but unfortunately
did: The "min" variable is altered.  At least the AVM A1 PCMCIA adapter was
no longer detected, breaking ISDN operation.

Use a local copy of "min" to restore the previous behaviour.

[bhelgaas: avoid gcc "?:" extension for portability and readability]
Fixes: 36e097a8a297 ("PCI: Split out bridge window override of minimum allocation address")
Signed-off-by: Christoph Biedl &lt;linux-kernel.bfrz@manchmal.in-ulm.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3460baa620685c20f5ee19afb6d99d26150c382c upstream.

Commit 36e097a8a297 ("PCI: Split out bridge window override of minimum
allocation address") claimed to do no functional changes but unfortunately
did: The "min" variable is altered.  At least the AVM A1 PCMCIA adapter was
no longer detected, breaking ISDN operation.

Use a local copy of "min" to restore the previous behaviour.

[bhelgaas: avoid gcc "?:" extension for portability and readability]
Fixes: 36e097a8a297 ("PCI: Split out bridge window override of minimum allocation address")
Signed-off-by: Christoph Biedl &lt;linux-kernel.bfrz@manchmal.in-ulm.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
