Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 29 1月, 2017 1 次提交
  3. 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
  5. 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
  7. 24 11月, 2016 3 次提交
  9. 07 9月, 2016 2 次提交
  11. 31 8月, 2016 3 次提交
  13. 19 8月, 2016 1 次提交
  15. 30 7月, 2016 1 次提交
  17. 20 7月, 2016 1 次提交
  19. 11 6月, 2016 2 次提交
  21. 20 4月, 2016 3 次提交
  23. 12 4月, 2016 3 次提交
  25. 09 4月, 2016 2 次提交
    • L
      thunderbolt: Support 1st gen Light Ridge controller · 19bf4d4f
      由 Lukas Wunner 提交于 
      Add support for the 1st gen Light Ridge controller, which is built into
these systems:

  iMac12,1       2011  21.5"
  iMac12,2       2011  27"
  Macmini5,1     2011  i5 2.3 GHz
  Macmini5,2     2011  i5 2.5 GHz
  Macmini5,3     2011  i7 2.0 GHz
  MacBookPro8,1  2011  13"
  MacBookPro8,2  2011  15"
  MacBookPro8,3  2011  17"
  MacBookPro9,1  2012  15"
  MacBookPro9,2  2012  13"

Light Ridge (CV82524) was the very first copper Thunderbolt controller,
introduced 2010 alongside its fiber-optic cousin Light Peak (CVL2510).
Consequently the chip suffers from some teething troubles:

  - MSI is broken for hotplug signaling on the downstream bridges: The chip
    just never sends an interrupt.  It requests 32 MSIs for each of its six
    bridges and the pcieport driver only allocates one per bridge.  However
    I've verified that even if 32 MSIs are allocated there's no interrupt
    on hotplug.  The only option is thus to disable MSI, which is also what
    OS X does.  Apparently all Thunderbolt chips up to revision 1 of Cactus
    Ridge 4C are plagued by this issue so quirk those as well.

  - The chip supports a maximum hop_count of 32, unlike its successors
    which support only 12.  Fixup ring_interrupt_active() to cope with
    values >= 32.

  - Another peculiarity is that the chip supports a maximum of 13 ports
    whereas its successors support 12.  However the additional port (#5)
    seems to be unusable as reading its TB_CFG_PORT config space results in
    TB_CFG_ERROR_INVALID_CONFIG_SPACE.  Add a quirk to mark the port
    disabled on the root switch, assuming that's necessary on all Macs
    using this chip.

Tested-by: Lukas Wunner <lukas@wunner.de> [MacBookPro9,1]
Tested-by: William Brown <william@blackhats.net.au> [MacBookPro8,2]
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAndreas Noever <andreas.noever@gmail.com>
      19bf4d4f
    • L
      PCI: Add Intel Thunderbolt device IDs · 1d111406
      由 Lukas Wunner 提交于 
      Intel Gen 1 and 2 chips use the same ID for NHI, bridges and switch.  Gen 3
chips and onward use a distinct ID for the NHI.

No functional change intended.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAndreas Noever <andreas.noever@gmail.com>
      1d111406
  27. 15 3月, 2016 1 次提交
  29. 11 3月, 2016 1 次提交
  31. 05 2月, 2016 1 次提交
  33. 21 1月, 2016 1 次提交
  35. 16 1月, 2016 1 次提交
  37. 11 12月, 2015 1 次提交
  39. 18 11月, 2015 1 次提交
  41. 23 10月, 2015 1 次提交
    • H
      PCI: Turn off Request Attributes to avoid Chelsio T5 Completion erratum · c56d4450
      由 Hariprasad Shenai 提交于 
      The Chelsio T5 has a PCIe compliance erratum that causes Malformed TLP or
Unexpected Completion errors in some systems, which may cause device access
timeouts.

Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same values
for the Attribute as were supplied in the header of the corresponding
Request, except as explicitly allowed when IDO is used."

Instead of copying the Attributes from the Request to the Completion, the
T5 always generates Completions with zero Attributes.  The receiver of a
Completion whose Attributes don't match the Request may accept it (which
itself seems non-compliant based on sec 2.3.2), or it may handle it as a
Malformed TLP or an Unexpected Completion, which will probably lead to a
device access timeout.

Work around this by disabling "Relaxed Ordering" and "No Snoop" in the Root
Port so it always generate Requests with zero Attributes.

This does affect all other devices which are downstream of that Root Port,
but these are performance optimizations that should not make a functional
difference.

Note that Configuration Space accesses are never supposed to have TLP
Attributes, so we're safe waiting till after any Configuration Space
accesses to do the Root Port "fixup".

Based on original work by Casey Leedom <leedom@chelsio.com>

[bhelgaas: changelog, comments, rename to pci_find_pcie_root_port(), rework
to use pci_upstream_bridge() and check for Root Port device type, edit
diagnostics to clarify intent and devices affected]
Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      c56d4450
  43. 25 9月, 2015 2 次提交
  45. 25 8月, 2015 1 次提交
    • Z
      PCI: Disable async suspend/resume for JMicron multi-function SATA/AHCI · 91f15fb3
      由 Zhang Rui 提交于 
      On multi-function JMicron SATA/PATA/AHCI devices, the PATA controller at
function 1 doesn't work if it is powered on before the SATA controller at
function 0.  The result is that PATA doesn't work after resume, and we
print messages like this:

  pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3
  irq 17: nobody cared (try booting with the "irqpoll" option)

Async resume was introduced in v3.15 by 76569faa ("PM / sleep:
Asynchronous threads for resume_noirq").  Prior to that, we powered on
the functions in order, so this problem shouldn't happen.

e6b7e41c ("ata: Disabling the async PM for JMicron chip 363/361")
solved the problem for JMicron 361 and 363 devices.  With async suspend
disabled, we always power on function 0 before function 1.

Barto then reported the same problem with a JMicron 368 (see comment #57 in
the bugzilla).

Rather than extending the blacklist piecemeal, disable async suspend for
all JMicron multi-function SATA/PATA/AHCI devices.

This quirk could stay in the ahci and pata_jmicron drivers, but it's likely
the problem will occur even if pata_jmicron isn't loaded until after the
suspend/resume.  Making it a PCI quirk ensures that we'll preserve the
power-on order even if the drivers aren't loaded.

[bhelgaas: changelog, limit to multi-function, limit to IDE/ATA]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81551Reported-and-tested-by: NBarto <mister.freeman@laposte.net>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.15+
      91f15fb3
  47. 24 8月, 2015 1 次提交
    • K
      PCI: Set MPS to match upstream bridge · 27d868b5
      由 Keith Busch 提交于 
      Firmware typically configures the PCIe fabric with a consistent Max Payload
Size setting based on the devices present at boot.  A hot-added device
typically has the power-on default MPS setting (128 bytes), which may not
match the fabric.

The previous Linux default, in the absence of any "pci=pcie_bus_*" options,
was PCIE_BUS_TUNE_OFF, in which we never touch MPS, even for hot-added
devices.

Add a new default setting, PCIE_BUS_DEFAULT, in which we make sure every
device's MPS setting matches the upstream bridge.  This makes it more
likely that a hot-added device will work in a system with optimized MPS
configuration.

Note that if we hot-add a device that only supports 128-byte MPS, it still
likely won't work because we don't reconfigure the rest of the fabric.
Booting with "pci=pcie_bus_peer2peer" is a workaround for this because it
sets MPS to 128 for everything.

[bhelgaas: changelog, new default, rework for pci_configure_device() path]
Tested-by: NKeith Busch <keith.busch@intel.com>
Tested-by: NJordan Hargrave <jharg93@gmail.com>
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>
      27d868b5
  49. 12 8月, 2015 1 次提交
  51. 10 8月, 2015 1 次提交
  53. 22 7月, 2015 1 次提交