<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/include/linux/pci.h, branch v4.2.1</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>PCI: Add dev_flags bit to access VPD through function 0</title>
<updated>2015-09-21T17:10:48+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=dbabc222f96398c3c25a2f9da404aa21dda68bc3'/>
<id>dbabc222f96398c3c25a2f9da404aa21dda68bc3</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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Make pci_msi_setup_pci_dev() non-static for use by arch code</title>
<updated>2015-08-26T11:40:49+00:00</updated>
<author>
<name>Guilherme G. Piccoli</name>
<email>gpiccoli@linux.vnet.ibm.com</email>
</author>
<published>2015-08-24T12:42:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=22b6839b914bbe5d94de11bbb83931952090719c'/>
<id>22b6839b914bbe5d94de11bbb83931952090719c</id>
<content type='text'>
Commit 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if kernel
doesn't support MSI") changed the location of the code that initialises
dev-&gt;msi_cap/msix_cap and then disables MSI/MSI-X interrupts at PCI
probe time in devices that have this flag set. It moved the code from
pci_msi_init_pci_dev() to a new function named pci_msi_setup_pci_dev(),
called by pci_setup_device().

The pseries PCI probing code does not call pci_setup_device(), so since
the aforementioned commit the function pci_msi_setup_pci_dev() is not
called and MSI/MSI-X interrupts are left enabled. Additionally because
dev-&gt;msi_cap/msix_cap are not initialised no driver can ever enable
MSI/MSI-X.

To fix this, the pseries PCI probe should manually call
pci_msi_setup_pci_dev(), so this patch makes it non-static.

Fixes: 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI")
[mpe: Update change log to mention dev-&gt;msi_cap/msix_cap]
Signed-off-by: Guilherme G. Piccoli &lt;gpiccoli@linux.vnet.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if kernel
doesn't support MSI") changed the location of the code that initialises
dev-&gt;msi_cap/msix_cap and then disables MSI/MSI-X interrupts at PCI
probe time in devices that have this flag set. It moved the code from
pci_msi_init_pci_dev() to a new function named pci_msi_setup_pci_dev(),
called by pci_setup_device().

The pseries PCI probing code does not call pci_setup_device(), so since
the aforementioned commit the function pci_msi_setup_pci_dev() is not
called and MSI/MSI-X interrupts are left enabled. Additionally because
dev-&gt;msi_cap/msix_cap are not initialised no driver can ever enable
MSI/MSI-X.

To fix this, the pseries PCI probe should manually call
pci_msi_setup_pci_dev(), so this patch makes it non-static.

Fixes: 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI")
[mpe: Update change log to mention dev-&gt;msi_cap/msix_cap]
Signed-off-by: Guilherme G. Piccoli &lt;gpiccoli@linux.vnet.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branches 'pci/aspm', 'pci/enumeration', 'pci/hotplug', 'pci/misc', 'pci/msi', 'pci/resource' and 'pci/virtualization' into next</title>
<updated>2015-06-12T20:26:45+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2015-06-12T20:26:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0ff9b9bad66730e8347cb3350c8d3d1b88a21f13'/>
<id>0ff9b9bad66730e8347cb3350c8d3d1b88a21f13</id>
<content type='text'>
* pci/aspm:
  PCI/ASPM: Simplify Clock Power Management setting
  PCI: Use dev-&gt;has_secondary_link to find downstream PCIe links
  PCI/ASPM: Use dev-&gt;has_secondary_link to find downstream links
  PCI: Add dev-&gt;has_secondary_link to track downstream PCIe links
  PCI/ASPM: Remove redundant PCIe port type checking
  PCI/ASPM: Drop __pci_disable_link_state() useless "force" parameter

* pci/enumeration:
  PCI: Remove unused pci_scan_bus_parented()
  xen/pcifront: Don't use deprecated function pci_scan_bus_parented()
  PCI: designware: Use pci_scan_root_bus() for simplicity
  PCI: tegra: Remove tegra_pcie_scan_bus()
  PCI: mvebu: Remove mvebu_pcie_scan_bus()

* pci/hotplug:
  PCI: pciehp: Wait for hotplug command completion where necessary
  PCI: Propagate the "ignore hotplug" setting to parent
  ACPI / hotplug / PCI: Check ignore_hotplug for all downstream devices
  PCI: pciehp: Drop pointless label from pciehp_probe()
  PCI: pciehp: Drop pointless ACPI-based "slot detection" check

* pci/misc:
  PCI: Remove unused pci_dma_burst_advice()
  PCI: Remove unused pcibios_select_root() (again)
  PCI: Remove unnecessary #includes of &lt;asm/pci.h&gt;
  PCI: Include &lt;linux/pci.h&gt;, not &lt;asm/pci.h&gt;

* pci/msi:
  PCI/MSI: Remove unused pci_msi_off()
  PCI/MSI: Drop pci_msi_off() calls from quirks
  ntb: Drop pci_msi_off() call during probe
  virtio_pci: drop pci_msi_off() call during probe
  PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI
  PCI/MSI: Export pci_msi_set_enable(), pci_msix_clear_and_set_ctrl()
  PCI/MSI: Rename msi_set_enable(), msix_clear_and_set_ctrl()

* pci/resource:
  PCI: Add pci_bus_addr_t

* pci/virtualization:
  ACPI / PCI: Account for ARI in _PRT lookups
  PCI: Move pci_ari_enabled() to global header
  PCI: Add function 1 DMA alias quirk for Marvell 9120
  PCI: Add ACS quirks for Intel 9-series PCH root ports
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* pci/aspm:
  PCI/ASPM: Simplify Clock Power Management setting
  PCI: Use dev-&gt;has_secondary_link to find downstream PCIe links
  PCI/ASPM: Use dev-&gt;has_secondary_link to find downstream links
  PCI: Add dev-&gt;has_secondary_link to track downstream PCIe links
  PCI/ASPM: Remove redundant PCIe port type checking
  PCI/ASPM: Drop __pci_disable_link_state() useless "force" parameter

* pci/enumeration:
  PCI: Remove unused pci_scan_bus_parented()
  xen/pcifront: Don't use deprecated function pci_scan_bus_parented()
  PCI: designware: Use pci_scan_root_bus() for simplicity
  PCI: tegra: Remove tegra_pcie_scan_bus()
  PCI: mvebu: Remove mvebu_pcie_scan_bus()

* pci/hotplug:
  PCI: pciehp: Wait for hotplug command completion where necessary
  PCI: Propagate the "ignore hotplug" setting to parent
  ACPI / hotplug / PCI: Check ignore_hotplug for all downstream devices
  PCI: pciehp: Drop pointless label from pciehp_probe()
  PCI: pciehp: Drop pointless ACPI-based "slot detection" check

* pci/misc:
  PCI: Remove unused pci_dma_burst_advice()
  PCI: Remove unused pcibios_select_root() (again)
  PCI: Remove unnecessary #includes of &lt;asm/pci.h&gt;
  PCI: Include &lt;linux/pci.h&gt;, not &lt;asm/pci.h&gt;

* pci/msi:
  PCI/MSI: Remove unused pci_msi_off()
  PCI/MSI: Drop pci_msi_off() calls from quirks
  ntb: Drop pci_msi_off() call during probe
  virtio_pci: drop pci_msi_off() call during probe
  PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI
  PCI/MSI: Export pci_msi_set_enable(), pci_msix_clear_and_set_ctrl()
  PCI/MSI: Rename msi_set_enable(), msix_clear_and_set_ctrl()

* pci/resource:
  PCI: Add pci_bus_addr_t

* pci/virtualization:
  ACPI / PCI: Account for ARI in _PRT lookups
  PCI: Move pci_ari_enabled() to global header
  PCI: Add function 1 DMA alias quirk for Marvell 9120
  PCI: Add ACS quirks for Intel 9-series PCH root ports
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Remove unused pci_scan_bus_parented()</title>
<updated>2015-06-12T20:26:28+00:00</updated>
<author>
<name>Yijing Wang</name>
<email>wangyijing@huawei.com</email>
</author>
<published>2015-04-28T09:32:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c0300089fd2dbeebef5ab9b6d66b4e6cedf8500a'/>
<id>c0300089fd2dbeebef5ab9b6d66b4e6cedf8500a</id>
<content type='text'>
No one uses pci_scan_bus_parented() any more, remove it.

Signed-off-by: Yijing Wang &lt;wangyijing@huawei.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
No one uses pci_scan_bus_parented() any more, remove it.

Signed-off-by: Yijing Wang &lt;wangyijing@huawei.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Remove unused pci_dma_burst_advice()</title>
<updated>2015-06-08T12:56:43+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2015-06-04T21:38:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=01d72a95188880b22190e937ed8718ed4b45bdce'/>
<id>01d72a95188880b22190e937ed8718ed4b45bdce</id>
<content type='text'>
pci_dma_burst_advice() was added by e24c2d963a60 ("[PATCH] PCI: DMA
bursting advice") but apparently never used.  Remove it.

Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Michal Simek &lt;monstr@monstr.eu&gt;	# microblaze
CC: David S. Miller &lt;davem@davemloft.net&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
pci_dma_burst_advice() was added by e24c2d963a60 ("[PATCH] PCI: DMA
bursting advice") but apparently never used.  Remove it.

Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Michal Simek &lt;monstr@monstr.eu&gt;	# microblaze
CC: David S. Miller &lt;davem@davemloft.net&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Add pci_bus_addr_t</title>
<updated>2015-05-29T22:21:45+00:00</updated>
<author>
<name>Yinghai Lu</name>
<email>yinghai@kernel.org</email>
</author>
<published>2015-05-28T00:23:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d'/>
<id>3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d</id>
<content type='text'>
David Ahern reported that d63e2e1f3df9 ("sparc/PCI: Clip bridge windows
to fit in upstream windows") fails to boot on sparc/T5-8:

  pci 0000:06:00.0: reg 0x184: can't handle BAR above 4GB (bus address 0x110204000)

The problem is that sparc64 assumed that dma_addr_t only needed to hold DMA
addresses, i.e., bus addresses returned via the DMA API (dma_map_single(),
etc.), while the PCI core assumed dma_addr_t could hold *any* bus address,
including raw BAR values.  On sparc64, all DMA addresses fit in 32 bits, so
dma_addr_t is a 32-bit type.  However, BAR values can be 64 bits wide, so
they don't fit in a dma_addr_t.  d63e2e1f3df9 added new checking that
tripped over this mismatch.

Add pci_bus_addr_t, which is wide enough to hold any PCI bus address,
including both raw BAR values and DMA addresses.  This will be 64 bits
on 64-bit platforms and on platforms with a 64-bit dma_addr_t.  Then
dma_addr_t only needs to be wide enough to hold addresses from the DMA API.

[bhelgaas: changelog, bugzilla, Kconfig to ensure pci_bus_addr_t is at
least as wide as dma_addr_t, documentation]
Fixes: d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream windows")
Fixes: 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger than 4GB")
Link: http://lkml.kernel.org/r/CAE9FiQU1gJY1LYrxs+ma5LCTEEe4xmtjRG0aXJ9K_Tsu+m9Wuw@mail.gmail.com
Link: http://lkml.kernel.org/r/1427857069-6789-1-git-send-email-yinghai@kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96231
Reported-by: David Ahern &lt;david.ahern@oracle.com&gt;
Tested-by: David Ahern &lt;david.ahern@oracle.com&gt;
Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: David S. Miller &lt;davem@davemloft.net&gt;
CC: stable@vger.kernel.org	# v3.19+</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
David Ahern reported that d63e2e1f3df9 ("sparc/PCI: Clip bridge windows
to fit in upstream windows") fails to boot on sparc/T5-8:

  pci 0000:06:00.0: reg 0x184: can't handle BAR above 4GB (bus address 0x110204000)

The problem is that sparc64 assumed that dma_addr_t only needed to hold DMA
addresses, i.e., bus addresses returned via the DMA API (dma_map_single(),
etc.), while the PCI core assumed dma_addr_t could hold *any* bus address,
including raw BAR values.  On sparc64, all DMA addresses fit in 32 bits, so
dma_addr_t is a 32-bit type.  However, BAR values can be 64 bits wide, so
they don't fit in a dma_addr_t.  d63e2e1f3df9 added new checking that
tripped over this mismatch.

Add pci_bus_addr_t, which is wide enough to hold any PCI bus address,
including both raw BAR values and DMA addresses.  This will be 64 bits
on 64-bit platforms and on platforms with a 64-bit dma_addr_t.  Then
dma_addr_t only needs to be wide enough to hold addresses from the DMA API.

[bhelgaas: changelog, bugzilla, Kconfig to ensure pci_bus_addr_t is at
least as wide as dma_addr_t, documentation]
Fixes: d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream windows")
Fixes: 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger than 4GB")
Link: http://lkml.kernel.org/r/CAE9FiQU1gJY1LYrxs+ma5LCTEEe4xmtjRG0aXJ9K_Tsu+m9Wuw@mail.gmail.com
Link: http://lkml.kernel.org/r/1427857069-6789-1-git-send-email-yinghai@kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96231
Reported-by: David Ahern &lt;david.ahern@oracle.com&gt;
Tested-by: David Ahern &lt;david.ahern@oracle.com&gt;
Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: David S. Miller &lt;davem@davemloft.net&gt;
CC: stable@vger.kernel.org	# v3.19+</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Move pci_ari_enabled() to global header</title>
<updated>2015-05-29T22:14:17+00:00</updated>
<author>
<name>Alex Williamson</name>
<email>alex.williamson@redhat.com</email>
</author>
<published>2015-05-26T21:11:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=19bdb6e4ec071bc49a9871b41e6a59a1657ed365'/>
<id>19bdb6e4ec071bc49a9871b41e6a59a1657ed365</id>
<content type='text'>
pci_ari_enabled() is useful outside of drivers/pci, particularly for
deriving INTx routing via ACPI _PRT, so move it to the global header.
Also convert to bool return.

Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Don Dutile &lt;ddutile@redhat.com&gt;
Acked-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
pci_ari_enabled() is useful outside of drivers/pci, particularly for
deriving INTx routing via ACPI _PRT, so move it to the global header.
Also convert to bool return.

Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Don Dutile &lt;ddutile@redhat.com&gt;
Acked-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Propagate the "ignore hotplug" setting to parent</title>
<updated>2015-05-23T01:33:09+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2015-04-13T14:23:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0824965140fff1bf640a987dc790d1594a8e0699'/>
<id>0824965140fff1bf640a987dc790d1594a8e0699</id>
<content type='text'>
Refine the mechanism introduced by commit f244d8b623da ("ACPIPHP / radeon /
nouveau: Fix VGA switcheroo problem related to hotplug") to propagate the
ignore_hotplug setting of the device to its parent bridge in case hotplug
notifications related to the graphics adapter switching are given for the
bridge rather than for the device itself (they need to be ignored in both
cases).

Link: https://bugzilla.kernel.org/show_bug.cgi?id=61891
Link: https://bugs.freedesktop.org/show_bug.cgi?id=88927
Fixes: b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device")
Reported-and-tested-by: tiagdtd-lava &lt;tiagdtd-lava@yahoo.de&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
CC: stable@vger.kernel.org	# v3.17+</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Refine the mechanism introduced by commit f244d8b623da ("ACPIPHP / radeon /
nouveau: Fix VGA switcheroo problem related to hotplug") to propagate the
ignore_hotplug setting of the device to its parent bridge in case hotplug
notifications related to the graphics adapter switching are given for the
bridge rather than for the device itself (they need to be ignored in both
cases).

Link: https://bugzilla.kernel.org/show_bug.cgi?id=61891
Link: https://bugs.freedesktop.org/show_bug.cgi?id=88927
Fixes: b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device")
Reported-and-tested-by: tiagdtd-lava &lt;tiagdtd-lava@yahoo.de&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
CC: stable@vger.kernel.org	# v3.17+</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Add dev-&gt;has_secondary_link to track downstream PCIe links</title>
<updated>2015-05-22T14:59:33+00:00</updated>
<author>
<name>Yijing Wang</name>
<email>wangyijing@huawei.com</email>
</author>
<published>2015-05-21T07:05:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d0751b98dfa391f862e02dc36a233a54615e3f1d'/>
<id>d0751b98dfa391f862e02dc36a233a54615e3f1d</id>
<content type='text'>
A PCIe Port is an interface to a Link.  A Root Port is a PCI-PCI bridge in
a Root Complex and has a Link on its secondary (downstream) side.  For
other Ports, the Link may be on either the upstream (closer to the Root
Complex) or downstream side of the Port.

The usual topology has a Root Port connected to an Upstream Port.  We
previously assumed this was the only possible topology, and that a
Downstream Port's Link was always on its downstream side, like this:

                  +---------------------+
  +------+        |          Downstream |
  | Root |        | Upstream       Port +--Link--
  | Port +--Link--+ Port                |
  +------+        |          Downstream |
                  |                Port +--Link--
                  +---------------------+

But systems do exist (see URL below) where the Root Port is connected to a
Downstream Port.  In this case, a Downstream Port's Link may be on either
the upstream or downstream side:

                  +---------------------+
  +------+        |            Upstream |
  | Root |        | Downstream     Port +--Link--
  | Port +--Link--+ Port                |
  +------+        |          Downstream |
                  |                Port +--Link--
                  +---------------------+

We can't use the Port type to determine which side the Link is on, so add a
bit in struct pci_dev to keep track.

A Root Port's Link is always on the Port's secondary side.  A component
(Endpoint or Port) on the other end of the Link obviously has the Link on
its upstream side.  If that component is a Port, it is part of a Switch or
a Bridge.  A Bridge has a PCI or PCI-X bus on its secondary side, not a
Link.  The internal bus of a Switch connects the Port to another Port whose
Link is on the downstream side.

[bhelgaas: changelog, comment, cache "type", use if/else]
Link: http://lkml.kernel.org/r/54EB81B2.4050904@pobox.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94361
Suggested-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Yijing Wang &lt;wangyijing@huawei.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A PCIe Port is an interface to a Link.  A Root Port is a PCI-PCI bridge in
a Root Complex and has a Link on its secondary (downstream) side.  For
other Ports, the Link may be on either the upstream (closer to the Root
Complex) or downstream side of the Port.

The usual topology has a Root Port connected to an Upstream Port.  We
previously assumed this was the only possible topology, and that a
Downstream Port's Link was always on its downstream side, like this:

                  +---------------------+
  +------+        |          Downstream |
  | Root |        | Upstream       Port +--Link--
  | Port +--Link--+ Port                |
  +------+        |          Downstream |
                  |                Port +--Link--
                  +---------------------+

But systems do exist (see URL below) where the Root Port is connected to a
Downstream Port.  In this case, a Downstream Port's Link may be on either
the upstream or downstream side:

                  +---------------------+
  +------+        |            Upstream |
  | Root |        | Downstream     Port +--Link--
  | Port +--Link--+ Port                |
  +------+        |          Downstream |
                  |                Port +--Link--
                  +---------------------+

We can't use the Port type to determine which side the Link is on, so add a
bit in struct pci_dev to keep track.

A Root Port's Link is always on the Port's secondary side.  A component
(Endpoint or Port) on the other end of the Link obviously has the Link on
its upstream side.  If that component is a Port, it is part of a Switch or
a Bridge.  A Bridge has a PCI or PCI-X bus on its secondary side, not a
Link.  The internal bus of a Switch connects the Port to another Port whose
Link is on the downstream side.

[bhelgaas: changelog, comment, cache "type", use if/else]
Link: http://lkml.kernel.org/r/54EB81B2.4050904@pobox.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94361
Suggested-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Yijing Wang &lt;wangyijing@huawei.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>PCI/MSI: Remove unused pci_msi_off()</title>
<updated>2015-05-07T14:52:22+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2015-05-07T14:52:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c6201cd8513db2db54b248a862672849ed9ccb82'/>
<id>c6201cd8513db2db54b248a862672849ed9ccb82</id>
<content type='text'>
pci_msi_off() is unused, so remove it.

Removes the exported symbol pci_msi_off().

Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
pci_msi_off() is unused, so remove it.

Removes the exported symbol pci_msi_off().

Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
