thunderbolt: Workaround an IOMMU fault on certain systems with Intel Maple Ridge
authorMika Westerberg <mika.westerberg@linux.intel.com>
Fri, 18 Aug 2023 12:27:46 +0000 (15:27 +0300)
committerMika Westerberg <mika.westerberg@linux.intel.com>
Fri, 15 Sep 2023 09:59:02 +0000 (12:59 +0300)
commit582620d9f6b352552bc9a3316fe2b1c3acd8742d
tree5b07e6cf9b538bd033166b10dd0d41c584c128bc
parent0bb80ecc33a8fb5a682236443c1e740d5c917d1d
thunderbolt: Workaround an IOMMU fault on certain systems with Intel Maple Ridge

On some systems the IOMMU blocks the first couple of driver ready
messages to the connection manager firmware as can be seen in below
excerpts:

  thunderbolt 0000:06:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0xbb0e3400 flags=0x0020]

or

  DMAR: DRHD: handling fault status reg 2
  DMAR: [DMA Write] Request device [04:00.0] PASID ffffffff fault addr 69974000 [fault reason 05] PTE Write access is not set

The reason is unknown and hard to debug because we were not able to
reproduce this locally. This only happens on certain systems with Intel
Maple Ridge Thunderbolt controller. If there is a device connected when
the driver is loaded the issue does not happen either. Only when there
is nothing connected (so typically when the system is booted up).

We can work this around by sending the driver ready several times. After
a couple of retries the message goes through and the controller works
just fine. For this reason make the number of retries a parameter for
icm_request() and then for Maple Ridge (and Titan Ridge as they us the
same function but this should not matter) increase number of retries
while shortening the timeout accordingly.

Reported-by: Werner Sembach <wse@tuxedocomputers.com>
Reported-by: Konrad J Hambrick <kjhambrick@gmail.com>
Reported-by: Calvin Walton <calvin.walton@kepstin.ca>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=214259
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
drivers/thunderbolt/icm.c