1. 01 8月, 2017 1 次提交
  2. 01 7月, 2017 1 次提交
  3. 14 6月, 2017 1 次提交
  4. 13 6月, 2017 1 次提交
  5. 25 4月, 2017 1 次提交
  6. 20 4月, 2017 2 次提交
  7. 18 4月, 2017 1 次提交
    • J
      PCI: Avoid generating invalid ThunderX2 DMA aliases · 45a23293
      Jayachandran C 提交于
      On Cavium ThunderX2 arm64 SoCs (formerly known as Broadcom Vulcan), the PCI
      topology is slightly unusual.  For a multi-node system, it looks like:
      
          00:00.0 PCI bridge to [bus 01-1e]
          01:0a.0 PCI-to-PCIe bridge to [bus 02-04]
          02:00.0 PCIe Root Port bridge to [bus 03-04] (XLATE_ROOT)
          03:00.0 PCIe Endpoint
      
      pci_for_each_dma_alias() assumes IOMMU translation is done at the root of
      the PCI hierarchy.  It generates 03:00.0, 01:0a.0, and 00:00.0 as DMA
      aliases for 03:00.0 because buses 01 and 00 are non-PCIe buses that don't
      carry the Requester ID.
      
      Because the ThunderX2 IOMMU is at 02:00.0, the Requester IDs 01:0a.0 and
      00:00.0 are never valid for the endpoint.  This quirk stops alias
      generation at the XLATE_ROOT bridge so we won't generate 01:0a.0 or
      00:00.0.
      
      The current IOMMU code only maps the last alias (this is a separate bug in
      itself).  Prior to this quirk, we only created IOMMU mappings for the
      invalid Requester ID 00:00:0, which never matched any DMA transactions.
      
      With this quirk, we create IOMMU mappings for a valid Requester ID, which
      fixes devices with no aliases but leaves devices with aliases still broken.
      
      The last alias for the endpoint is also used by the ARM GICv3 MSI-X code.
      Without this quirk, the GIC Interrupt Translation Tables are setup with the
      invalid Requester ID, and the MSI-X generated by the device fails to be
      translated and routed.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=195447Signed-off-by: NJayachandran C <jnair@caviumnetworks.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
      Acked-by: NDavid Daney <david.daney@cavium.com>
      45a23293
  8. 13 4月, 2017 1 次提交
  9. 04 4月, 2017 1 次提交
  10. 31 3月, 2017 1 次提交
  11. 08 3月, 2017 1 次提交
    • E
      PCI: Prevent VPD access for QLogic ISP2722 · 0d5370d1
      Ethan Zhao 提交于
      QLogic ISP2722-based 16/32Gb Fibre Channel to PCIe Adapter has the VPD
      access issue too, while read the common pci-sysfs access interface shown as
      
       /sys/devices/pci0000:00/0000:00:03.2/0000:0b:00.0/vpd
      
      with simple 'cat' could cause system hang and panic:
      
        Kernel panic - not syncing: An NMI occurred. Depending on your system the reason for the NMI is logged in any one of the following resources:
        1. Integrated Management Log (IML)
        2. OA Syslog
        3. OA Forward Progress Log
        4. iLO Event Log
        CPU: 0 PID: 15070 Comm: udevadm Not tainted 4.1.12
        Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 12/27/2015
         0000000000000086 000000007f0cdf51 ffff880c4fa05d58 ffffffff817193de
         ffffffffa00b42d8 0000000000000075 ffff880c4fa05dd8 ffffffff81714072
         0000000000000008 ffff880c4fa05de8 ffff880c4fa05d88 000000007f0cdf51
        Call Trace:
         <NMI>  [<ffffffff817193de>] dump_stack+0x63/0x81
         [<ffffffff81714072>] panic+0xd0/0x20e
         [<ffffffffa00b390d>] hpwdt_pretimeout+0xdd/0xe0 [hpwdt]
         [<ffffffff81021fc9>] ? sched_clock+0x9/0x10
         [<ffffffff8101c101>] nmi_handle+0x91/0x170
         [<ffffffff8101c10c>] ? nmi_handle+0x9c/0x170
         [<ffffffff8101c5fe>] io_check_error+0x1e/0xa0
         [<ffffffff8101c719>] default_do_nmi+0x99/0x140
         [<ffffffff8101c8b4>] do_nmi+0xf4/0x170
         [<ffffffff817232c5>] end_repeat_nmi+0x1a/0x1e
         [<ffffffff815d724b>] ? pci_conf1_read+0xeb/0x120
         [<ffffffff815d724b>] ? pci_conf1_read+0xeb/0x120
         [<ffffffff815d724b>] ? pci_conf1_read+0xeb/0x120
         <<EOE>>  [<ffffffff815db4b3>] raw_pci_read+0x23/0x40
         [<ffffffff815db4fc>] pci_read+0x2c/0x30
         [<ffffffff8136f612>] pci_user_read_config_word+0x72/0x110
         [<ffffffff8136f746>] pci_vpd_pci22_wait+0x96/0x130
         [<ffffffff8136ff9b>] pci_vpd_pci22_read+0xdb/0x1a0
         [<ffffffff8136ea30>] pci_read_vpd+0x20/0x30
         [<ffffffff8137d590>] read_vpd_attr+0x30/0x40
         [<ffffffff8128e037>] sysfs_kf_bin_read+0x47/0x70
         [<ffffffff8128d24e>] kernfs_fop_read+0xae/0x180
         [<ffffffff8120dd97>] __vfs_read+0x37/0x100
         [<ffffffff812ba7e4>] ? security_file_permission+0x84/0xa0
         [<ffffffff8120e366>] ? rw_verify_area+0x56/0xe0
         [<ffffffff8120e476>] vfs_read+0x86/0x140
         [<ffffffff8120f3f5>] SyS_read+0x55/0xd0
         [<ffffffff81720f2e>] system_call_fastpath+0x12/0x71
        Shutting down cpus with NMI
        Kernel Offset: disabled
        drm_kms_helper: panic occurred, switching back to text console
      
      So blacklist the access to its VPD.
      Signed-off-by: NEthan Zhao <ethan.zhao@oracle.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v4.6+
      0d5370d1
  12. 28 2月, 2017 1 次提交
  13. 18 2月, 2017 1 次提交
    • S
      PCI: Add ACS quirk for Qualcomm QDF2400 and QDF2432 · 33be632b
      Sinan Kaya 提交于
      The Qualcomm QDF2xxx root ports don't advertise an ACS capability, but they
      do provide ACS-like features to disable peer transactions and validate bus
      numbers in requests.
      
      To be specific:
      * Hardware supports source validation but it will report the issue as
      Completer Abort instead of ACS Violation.
      
      * Hardware doesn't support peer-to-peer and each root port is a root
      complex with unique segment numbers.
      
      * It is not possible for one root port to pass traffic to the other root
      port.  All PCIe transactions are terminated inside the root port.
      
      Add an ACS quirk for the QDF2400 and QDF2432 products.
      
      [bhelgaas: changelog]
      Signed-off-by: NSinan Kaya <okaya@codeaurora.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>
      33be632b
  14. 16 2月, 2017 1 次提交
  15. 09 2月, 2017 2 次提交
  16. 29 1月, 2017 1 次提交
  17. 26 12月, 2016 1 次提交
    • T
      ktime: Cleanup ktime_set() usage · 8b0e1953
      Thomas Gleixner 提交于
      ktime_set(S,N) was required for the timespec storage type and is still
      useful for situations where a Seconds and Nanoseconds part of a time value
      needs to be converted. For anything where the Seconds argument is 0, this
      is pointless and can be replaced with a simple assignment.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      8b0e1953
  18. 13 12月, 2016 2 次提交
    • A
      PCI: Enable access to non-standard VPD for Chelsio devices (cxgb3) · 1c7de2b4
      Alexey Kardashevskiy 提交于
      There is at least one Chelsio 10Gb card which uses VPD area to store some
      non-standard blocks (example below).  However pci_vpd_size() returns the
      length of the first block only assuming that there can be only one VPD "End
      Tag".
      
      Since 4e1a6355 ("vfio/pci: Use kernel VPD access functions"), VFIO
      blocks access beyond that offset, which prevents the guest "cxgb3" driver
      from probing the device.  The host system does not have this problem as its
      driver accesses the config space directly without pci_read_vpd().
      
      Add a quirk to override the VPD size to a bigger value.  The maximum size
      is taken from EEPROMSIZE in drivers/net/ethernet/chelsio/cxgb3/common.h.
      We do not read the tag as the cxgb3 driver does as the driver supports
      writing to EEPROM/VPD and when it writes, it only checks for 8192 bytes
      boundary.  The quirk is registered for all devices supported by the cxgb3
      driver.
      
      This adds a quirk to the PCI layer (not to the cxgb3 driver) as the cxgb3
      driver itself accesses VPD directly and the problem only exists with the
      vfio-pci driver (when cxgb3 is not running on the host and may not be even
      loaded) which blocks accesses beyond the first block of VPD data.  However
      vfio-pci itself does not have quirks mechanism so we add it to PCI.
      
      This is the controller:
      Ethernet controller [0200]: Chelsio Communications Inc T310 10GbE Single Port Adapter [1425:0030]
      
      This is what I parsed from its VPD:
      ===
      b'\x82*\x0010 Gigabit Ethernet-SR PCI Express Adapter\x90J\x00EC\x07D76809 FN\x0746K'
       0000 Large item 42 bytes; name 0x2 Identifier String
      	b'10 Gigabit Ethernet-SR PCI Express Adapter'
       002d Large item 74 bytes; name 0x10
      	#00 [EC] len=7: b'D76809 '
      	#0a [FN] len=7: b'46K7897'
      	#14 [PN] len=7: b'46K7897'
      	#1e [MN] len=4: b'1037'
      	#25 [FC] len=4: b'5769'
      	#2c [SN] len=12: b'YL102035603V'
      	#3b [NA] len=12: b'00145E992ED1'
       007a Small item 1 bytes; name 0xf End Tag
      
       0c00 Large item 16 bytes; name 0x2 Identifier String
      	b'S310E-SR-X      '
       0c13 Large item 234 bytes; name 0x10
      	#00 [PN] len=16: b'TBD             '
      	#13 [EC] len=16: b'110107730D2     '
      	#26 [SN] len=16: b'97YL102035603V  '
      	#39 [NA] len=12: b'00145E992ED1'
      	#48 [V0] len=6: b'175000'
      	#51 [V1] len=6: b'266666'
      	#5a [V2] len=6: b'266666'
      	#63 [V3] len=6: b'2000  '
      	#6c [V4] len=2: b'1 '
      	#71 [V5] len=6: b'c2    '
      	#7a [V6] len=6: b'0     '
      	#83 [V7] len=2: b'1 '
      	#88 [V8] len=2: b'0 '
      	#8d [V9] len=2: b'0 '
      	#92 [VA] len=2: b'0 '
      	#97 [RV] len=80: b's\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
       0d00 Large item 252 bytes; name 0x11
      	#00 [VC] len=16: b'122310_1222 dp  '
      	#13 [VD] len=16: b'610-0001-00 H1\x00\x00'
      	#26 [VE] len=16: b'122310_1353 fp  '
      	#39 [VF] len=16: b'610-0001-00 H1\x00\x00'
      	#4c [RW] len=173: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
       0dff Small item 0 bytes; name 0xf End Tag
      
      10f3 Large item 13315 bytes; name 0x62
      !!! unknown item name 98: b'\xd0\x03\x00@`\x0c\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00'
      ===
      Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      1c7de2b4
    • B
      PCI: Expand "VPD access disabled" quirk message · 044bc425
      Bjorn Helgaas 提交于
      It's not very enlightening to see
      
        pci 0000:07:00.0: [Firmware Bug]: VPD access disabled
      
      in the dmesg log because there's no clue about what the firmware bug is.
      Expand the message to explain why we're disabling VPD.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      044bc425
  19. 24 11月, 2016 3 次提交
  20. 07 9月, 2016 2 次提交
  21. 31 8月, 2016 3 次提交
  22. 19 8月, 2016 1 次提交
  23. 30 7月, 2016 1 次提交
  24. 20 7月, 2016 1 次提交
  25. 11 6月, 2016 2 次提交
  26. 20 4月, 2016 3 次提交
  27. 12 4月, 2016 3 次提交