linux-toradex.git/drivers/thunderbolt/nhi.c, branch v6.0-rc7

thunderbolt: Add support for Intel Raptor Lake

2022-06-06T09:33:22+00:00

Intel Raptor Lake has the same integrated Thunderbolt/USB4 controller as
Intel Alder Lake. By default it is still using firmware based connection
manager so we can use most of the Alder Lake flows.

Signed-off-by: George D Sworo 
Signed-off-by: Mika Westerberg

Merge tag 'usb-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

2022-06-03T18:17:49+00:00

Pull USB / Thunderbolt updates from Greg KH:
 "Here is the "big" set of USB and Thunderbolt driver changes for
  5.18-rc1. For the most part it's been a quiet development cycle for
  the USB core, but there are the usual "hot spots" of development
  activity.

  Included in here are:

   - Thunderbolt driver updates:
       - fixes for devices without displayport adapters
       - lane bonding support and improvements
       - other minor changes based on device testing

   - dwc3 gadget driver changes.

     It seems this driver will never be finished given that the IP core
     is showing up in zillions of new devices and each implementation
     decides to do something different with it...

   - uvc gadget driver updates as more devices start to use and rely on
     this hardware as well

   - usb_maxpacket() api changes to remove an unneeded and unused
     parameter.

   - usb-serial driver device id updates and small cleanups

   - typec cleanups and fixes based on device testing

   - device tree updates for usb properties

   - lots of other small fixes and driver updates.

  All of these have been in linux-next for weeks with no reported
  problems"

* tag 'usb-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (154 commits)
  USB: new quirk for Dell Gen 2 devices
  usb: dwc3: core: Add error log when core soft reset failed
  usb: dwc3: gadget: Move null pinter check to proper place
  usb: hub: Simplify error and success path in port_over_current_notify
  usb: cdns3: allocate TX FIFO size according to composite EP number
  usb: dwc3: Fix ep0 handling when getting reset while doing control transfer
  usb: Probe EHCI, OHCI controllers asynchronously
  usb: isp1760: Fix out-of-bounds array access
  xhci: Don't defer primary roothub registration if there is only one roothub
  USB: serial: option: add Quectel BG95 modem
  USB: serial: pl2303: fix type detection for odd device
  xhci: Allow host runtime PM as default for Intel Alder Lake N xHCI
  xhci: Remove quirk for over 10 year old evaluation hardware
  xhci: prevent U2 link power state if Intel tier policy prevented U1
  xhci: use generic command timer for stop endpoint commands.
  usb: host: xhci-plat: omit shared hcd if either root hub has no ports
  usb: host: xhci-plat: prepare operation w/o shared hcd
  usb: host: xhci-plat: create shared hcd after having added main hcd
  xhci: prepare for operation w/o shared hcd
  xhci: factor out parts of xhci_gen_setup()
  ...

thunderbolt: Make iommu_dma_protection more accurate

2022-04-28T08:30:25+00:00

Between me trying to get rid of iommu_present() and Mario wanting to
support the AMD equivalent of DMAR_PLATFORM_OPT_IN, scrutiny has shown
that the iommu_dma_protection attribute is being far too optimistic.
Even if an IOMMU might be present for some PCI segment in the system,
that doesn't necessarily mean it provides translation for the device(s)
we care about. Furthermore, all that DMAR_PLATFORM_OPT_IN really does
is tell us that memory was protected before the kernel was loaded, and
prevent the user from disabling the intel-iommu driver entirely. While
that lets us assume kernel integrity, what matters for actual runtime
DMA protection is whether we trust individual devices, based on the
"external facing" property that we expect firmware to describe for
Thunderbolt ports.

It's proven challenging to determine the appropriate ports accurately
given the variety of possible topologies, so while still not getting a
perfect answer, by putting enough faith in firmware we can at least get
a good bit closer. If we can see that any device near a Thunderbolt NHI
has all the requisites for Kernel DMA Protection, chances are that it
*is* a relevant port, but moreover that implies that firmware is playing
the game overall, so we'll use that to assume that all Thunderbolt ports
should be correctly marked and thus will end up fully protected.

CC: Mario Limonciello 
Reviewed-by: Christoph Hellwig 
Acked-by: Mika Westerberg 
Signed-off-by: Robin Murphy 
Link: https://lore.kernel.org/r/b153f208bc9eafab5105bad0358b77366509d2d4.1650878781.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel

thunderbolt: Fix typo in comment

2022-04-19T07:26:00+00:00

Should be 'in' instead of 'bin'. Fix it.

Signed-off-by: Mika Westerberg 
Tested-by: Brad Campbell

thunderbolt: Remove useless DMA-32 fallback configuration

2022-01-24T13:55:56+00:00

As stated in [1], dma_set_mask() with a 64-bit mask never fails if
dev->dma_mask is non-NULL.
So, if it fails, the 32 bits case will also fail for the same reason.

Simplify code and remove some dead code accordingly.

While at it, include directly  instead on relying on
indirect inclusion.

[1]: https://lkml.org/lkml/2021/6/7/398

Signed-off-by: Christophe JAILLET 
Signed-off-by: Mika Westerberg

thunderbolt: Handle ring interrupt by reading interrupt status register

2021-08-09T11:58:29+00:00

As per USB4 specification by default "Disable ISR Auto-Clear" bit is set
to zero and the Tx/Rx ring interrupt status needs to be cleared.

Hence handle it by reading the interrupt status register (ISR) in the
MSI-X handler.

Signed-off-by: Basavaraj Natikar 
Signed-off-by: Sanjay R Mehta 
Signed-off-by: Mika Westerberg

thunderbolt: Add vendor specific NHI quirk for auto-clearing interrupt status

2021-08-09T11:58:29+00:00

Introduce nhi_check_quirks() routine to handle any vendor specific quirks
to manage a hardware specific implementation.

On Intel hardware the USB4 controller supports clearing the interrupt
status register automatically right after it is being issued. For this
reason add a new quirk that does that on all Intel hardware.

Signed-off-by: Basavaraj Natikar 
Signed-off-by: Sanjay R Mehta 
Signed-off-by: Mika Westerberg

thunderbolt: Add support for Intel Alder Lake

2021-06-11T08:42:54+00:00

Alder Lake has the same integrated Thunderbolt/USB4 controller as
Intel Tiger Lake. By default it is still using firmware based connection
manager so we can use most of the Tiger Lake flows.

Add the Alder Lake PCI IDs to the driver list of supported devices.

Signed-off-by: Azhar Shaikh 
Reviewed-by: Yehezkel Bernat 
Signed-off-by: Mika Westerberg

thunderbolt: Add device links only when software connection manager is used

2021-06-11T08:42:54+00:00

We only need to set up the device links when software connection manager
path is used. The firmware connection manager does not need them and if
they are present they may even cause problems.

Reviewed-by: Yehezkel Bernat 
Signed-off-by: Mika Westerberg

thunderbolt: Add support for native USB4 _OSC

2021-02-04T07:45:25+00:00

ACPI 6.4 introduced a new _OSC capability used to negotiate whether the
OS is supposed to use Software (native) or Firmware based Connection
Manager. If the native support is granted then there are set of bits
that enable/disable different tunnel types that the Software Connection
Manager is allowed to tunnel.

This adds support for this new USB4 _OSC accordingly. When PCIe
tunneling is disabled then the driver switches security level to be
"nopcie" following the security level 5 used in Firmware based
Connection Manager.

Signed-off-by: Mika Westerberg 
Acked-by: Yehezkel Bernat