<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/pci, branch v3.12.59</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-11T14:44:00+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=b82df119eed7e6d5815c04af734ae2f527b46af0'/>
<id>b82df119eed7e6d5815c04af734ae2f527b46af0</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;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&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;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted.</title>
<updated>2016-03-03T11:46:08+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=7949b7bfff8be7cf0fc02d06b80f4e9d1c1189ae'/>
<id>7949b7bfff8be7cf0fc02d06b80f4e9d1c1189ae</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: Jiri Slaby &lt;jslaby@suse.cz&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: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI/AER: Flush workqueue on device remove to avoid use-after-free</title>
<updated>2016-03-03T11:46:05+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=b98e34c37756d8601fd29ecbed68beb9c0ee2f4e'/>
<id>b98e34c37756d8601fd29ecbed68beb9c0ee2f4e</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: Jiri Slaby &lt;jslaby@suse.cz&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: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Drop "setting latency timer" messages</title>
<updated>2016-01-09T10:28:32+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2013-09-23T21:25:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8e38535241128cb6b91bac6a115062d325d3c4b4'/>
<id>8e38535241128cb6b91bac6a115062d325d3c4b4</id>
<content type='text'>
commit a006482b67a96c16dfefc558e36863c51e1829bf upstream.

This message isn't useful any more, so drop it.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=60636
Reported-by: Oleksil Shevchuk &lt;alxchk@gmail.com&gt;
Reference: http://lkml.kernel.org/r/CALCETrWkr53ZjqdN3t7rTTfr=+ZKZXJoYsuBcwPf0kN_33GfAw@mail.gmail.com
Reported-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a006482b67a96c16dfefc558e36863c51e1829bf upstream.

This message isn't useful any more, so drop it.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=60636
Reported-by: Oleksil Shevchuk &lt;alxchk@gmail.com&gt;
Reference: http://lkml.kernel.org/r/CALCETrWkr53ZjqdN3t7rTTfr=+ZKZXJoYsuBcwPf0kN_33GfAw@mail.gmail.com
Reported-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Fix TI816X class code quirk</title>
<updated>2015-09-30T08:59:52+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2015-06-19T20:58:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8c9777e56564e7caeb93e6f61f31fadeb5063a56'/>
<id>8c9777e56564e7caeb93e6f61f31fadeb5063a56</id>
<content type='text'>
commit d1541dc977d376406f4584d8eb055488655c98ec upstream.

In fixup_ti816x_class(), we assigned "class = PCI_CLASS_MULTIMEDIA_VIDEO".
But PCI_CLASS_MULTIMEDIA_VIDEO is only the two-byte base class/sub-class
and needs to be shifted to make space for the low-order interface byte.

Shift PCI_CLASS_MULTIMEDIA_VIDEO to set the correct class code.

Fixes: 63c4408074cb ("PCI: Add quirk for setting valid class for TI816X Endpoint")
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
CC: Hemant Pedanekar &lt;hemantp@ti.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d1541dc977d376406f4584d8eb055488655c98ec upstream.

In fixup_ti816x_class(), we assigned "class = PCI_CLASS_MULTIMEDIA_VIDEO".
But PCI_CLASS_MULTIMEDIA_VIDEO is only the two-byte base class/sub-class
and needs to be shifted to make space for the low-order interface byte.

Shift PCI_CLASS_MULTIMEDIA_VIDEO to set the correct class code.

Fixes: 63c4408074cb ("PCI: Add quirk for setting valid class for TI816X Endpoint")
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
CC: Hemant Pedanekar &lt;hemantp@ti.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Add VPD function 0 quirk for Intel Ethernet devices</title>
<updated>2015-09-18T07:26:29+00:00</updated>
<author>
<name>Mark Rustad</name>
<email>mark.d.rustad@intel.com</email>
</author>
<published>2015-07-13T18:40:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=416473bd80d278c958a5637f465e48a1b150b6dc'/>
<id>416473bd80d278c958a5637f465e48a1b150b6dc</id>
<content type='text'>
commit 7aa6ca4d39edf01f997b9e02cf6d2fdeb224f351 upstream.

Set the PCI_DEV_FLAGS_VPD_REF_F0 flag on all Intel Ethernet device
functions other than function 0, so that on multi-function devices, we will
always read VPD from function 0 instead of from the other functions.

[bhelgaas: changelog]
Signed-off-by: Mark Rustad &lt;mark.d.rustad@intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Alexander Duyck &lt;alexander.h.duyck@redhat.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7aa6ca4d39edf01f997b9e02cf6d2fdeb224f351 upstream.

Set the PCI_DEV_FLAGS_VPD_REF_F0 flag on all Intel Ethernet device
functions other than function 0, so that on multi-function devices, we will
always read VPD from function 0 instead of from the other functions.

[bhelgaas: changelog]
Signed-off-by: Mark Rustad &lt;mark.d.rustad@intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Alexander Duyck &lt;alexander.h.duyck@redhat.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Add dev_flags bit to access VPD through function 0</title>
<updated>2015-09-18T07:26:29+00:00</updated>
<author>
<name>Mark Rustad</name>
<email>mark.d.rustad@intel.com</email>
</author>
<published>2015-07-13T18:40:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4386f737d429451d61358f771e315ed47e2f451f'/>
<id>4386f737d429451d61358f771e315ed47e2f451f</id>
<content type='text'>
commit 932c435caba8a2ce473a91753bad0173269ef334 upstream.

Add a dev_flags bit, PCI_DEV_FLAGS_VPD_REF_F0, to access VPD through
function 0 to provide VPD access on other functions.  This is for hardware
devices that provide copies of the same VPD capability registers in
multiple functions.  Because the kernel expects that each function has its
own registers, both the locking and the state tracking are affected by VPD
accesses to different functions.

On such devices for example, if a VPD write is performed on function 0,
*any* later attempt to read VPD from any other function of that device will
hang.  This has to do with how the kernel tracks the expected value of the
F bit per function.

Concurrent accesses to different functions of the same device can not only
hang but also corrupt both read and write VPD data.

When hangs occur, typically the error message:

  vpd r/w failed.  This is likely a firmware bug on this device.

will be seen.

Never set this bit on function 0 or there will be an infinite recursion.

Signed-off-by: Mark Rustad &lt;mark.d.rustad@intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Alexander Duyck &lt;alexander.h.duyck@redhat.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 932c435caba8a2ce473a91753bad0173269ef334 upstream.

Add a dev_flags bit, PCI_DEV_FLAGS_VPD_REF_F0, to access VPD through
function 0 to provide VPD access on other functions.  This is for hardware
devices that provide copies of the same VPD capability registers in
multiple functions.  Because the kernel expects that each function has its
own registers, both the locking and the state tracking are affected by VPD
accesses to different functions.

On such devices for example, if a VPD write is performed on function 0,
*any* later attempt to read VPD from any other function of that device will
hang.  This has to do with how the kernel tracks the expected value of the
F bit per function.

Concurrent accesses to different functions of the same device can not only
hang but also corrupt both read and write VPD data.

When hangs occur, typically the error message:

  vpd r/w failed.  This is likely a firmware bug on this device.

will be seen.

Never set this bit on function 0 or there will be an infinite recursion.

Signed-off-by: Mark Rustad &lt;mark.d.rustad@intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Alexander Duyck &lt;alexander.h.duyck@redhat.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: pciehp: Add hotplug_lock to serialize hotplug events</title>
<updated>2015-07-30T12:10:35+00:00</updated>
<author>
<name>Rajat Jain</name>
<email>rajatxjain@gmail.com</email>
</author>
<published>2015-06-30T13:05:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=79be5a7205c9095580f3a09f40adf651fc2e47c9'/>
<id>79be5a7205c9095580f3a09f40adf651fc2e47c9</id>
<content type='text'>
commit 50b52fdee050745935d92e7026373edea2647e60 upstream.

Today it is there is no protection around pciehp_enable_slot() and
pciehp_disable_slot() to ensure that they complete before another
hot-plug operation can be done on that particular slot.

This patch introduces the slot-&gt;hotplug_lock to ensure that any hotplug
operations (add / remove) complete before another hotplug event can begin
processing on that particular slot.

Signed-off-by: Rajat Jain &lt;rajatxjain@gmail.com&gt;
Signed-off-by: Rajat Jain &lt;rajatjain@juniper.net&gt;
Signed-off-by: Guenter Roeck &lt;groeck@juniper.net&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
[backported for SLE12]
Signed-off-by: Luis R. Rodriguez &lt;mcgrof@suse.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 50b52fdee050745935d92e7026373edea2647e60 upstream.

Today it is there is no protection around pciehp_enable_slot() and
pciehp_disable_slot() to ensure that they complete before another
hot-plug operation can be done on that particular slot.

This patch introduces the slot-&gt;hotplug_lock to ensure that any hotplug
operations (add / remove) complete before another hotplug event can begin
processing on that particular slot.

Signed-off-by: Rajat Jain &lt;rajatxjain@gmail.com&gt;
Signed-off-by: Rajat Jain &lt;rajatjain@juniper.net&gt;
Signed-off-by: Guenter Roeck &lt;groeck@juniper.net&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
[backported for SLE12]
Signed-off-by: Luis R. Rodriguez &lt;mcgrof@suse.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Fix infinite loop with ROM image of size 0</title>
<updated>2015-03-01T22:34:15+00:00</updated>
<author>
<name>Michel Dänzer</name>
<email>michel.daenzer@amd.com</email>
</author>
<published>2015-01-19T08:53:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bd4b3c108399d1f842472b77bde81d090d936f0f'/>
<id>bd4b3c108399d1f842472b77bde81d090d936f0f</id>
<content type='text'>
commit 16b036af31e1456cb69243a5a0c9ef801ecd1f17 upstream.

If the image size would ever read as 0, pci_get_rom_size() could keep
processing the same image over and over again.  Exit the loop if we ever
read a length of zero.

This fixes a soft lockup on boot when the radeon driver calls
pci_get_rom_size() on an AMD Radeon R7 250X PCIe discrete graphics card.

[bhelgaas: changelog, reference]
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386973
Reported-by: Federico &lt;federicotg@gmail.com&gt;
Signed-off-by: Michel Dänzer &lt;michel.daenzer@amd.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 16b036af31e1456cb69243a5a0c9ef801ecd1f17 upstream.

If the image size would ever read as 0, pci_get_rom_size() could keep
processing the same image over and over again.  Exit the loop if we ever
read a length of zero.

This fixes a soft lockup on boot when the radeon driver calls
pci_get_rom_size() on an AMD Radeon R7 250X PCIe discrete graphics card.

[bhelgaas: changelog, reference]
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386973
Reported-by: Federico &lt;federicotg@gmail.com&gt;
Signed-off-by: Michel Dänzer &lt;michel.daenzer@amd.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Generate uppercase hex for modalias var in uevent</title>
<updated>2015-03-01T22:34:14+00:00</updated>
<author>
<name>Ricardo Ribalda Delgado</name>
<email>ricardo.ribalda@gmail.com</email>
</author>
<published>2014-12-02T16:35:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=109102cb30e106fd9e06dcd49a0abfcabacb6439'/>
<id>109102cb30e106fd9e06dcd49a0abfcabacb6439</id>
<content type='text'>
commit 145b3fe579db66fbe999a2bc3fd5b63dffe9636d upstream.

Some implementations of modprobe fail to load the driver for a PCI device
automatically because the "interface" part of the modalias from the kernel
is lowercase, and the modalias from file2alias is uppercase.

The "interface" is the low-order byte of the Class Code, defined in PCI
r3.0, Appendix D.  Most interface types defined in the spec do not use
alpha characters, so they won't be affected.  For example, 00h, 01h, 10h,
20h, etc. are unaffected.

Print the "interface" byte of the Class Code in uppercase hex, as we
already do for the Vendor ID, Device ID, Class, etc.

Commit 89ec3dcf17fd ("PCI: Generate uppercase hex for modalias interface
class") fixed only half of the problem.  Some udev implementations rely on
the uevent file and not the modalias file.

Fixes: d1ded203adf1 ("PCI: add MODALIAS to hotplug event for pci devices")
Fixes: 89ec3dcf17fd ("PCI: Generate uppercase hex for modalias interface class")
Signed-off-by: Ricardo Ribalda Delgado &lt;ricardo.ribalda@gmail.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 145b3fe579db66fbe999a2bc3fd5b63dffe9636d upstream.

Some implementations of modprobe fail to load the driver for a PCI device
automatically because the "interface" part of the modalias from the kernel
is lowercase, and the modalias from file2alias is uppercase.

The "interface" is the low-order byte of the Class Code, defined in PCI
r3.0, Appendix D.  Most interface types defined in the spec do not use
alpha characters, so they won't be affected.  For example, 00h, 01h, 10h,
20h, etc. are unaffected.

Print the "interface" byte of the Class Code in uppercase hex, as we
already do for the Vendor ID, Device ID, Class, etc.

Commit 89ec3dcf17fd ("PCI: Generate uppercase hex for modalias interface
class") fixed only half of the problem.  Some udev implementations rely on
the uevent file and not the modalias file.

Fixes: d1ded203adf1 ("PCI: add MODALIAS to hotplug event for pci devices")
Fixes: 89ec3dcf17fd ("PCI: Generate uppercase hex for modalias interface class")
Signed-off-by: Ricardo Ribalda Delgado &lt;ricardo.ribalda@gmail.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
</feed>
