Re: [PATCH] PCI: Extend Apple Thunderbolt power quirk to Alpine Ridge

[Mika Westerberg <mika.westerberg@linux.intel.com>]

Hi,

On Thu, Oct 08, 2026 at 11:50:47PM -0300, Francisco Beltrán Millalén wrote:
> Hi Bjorn,
> 
> Thanks for looking at this one as well, and for copying the Thunderbolt
> folks.
> 
> On Thu, Oct 08, 2026 at 06:17:44PM -0500, Bjorn Helgaas wrote:
> > Thanks for all this detail.  I think it's too much for a commit log,
> > but it would be good to have it after the "---" where it's in the
> > email but not the git commit.  This is easily accessible via the
> > "Link: https://patch.msgid.link/" tag that we add when applying.
> 
> I'll move most of it below the "---" in v2 and keep the commit message
> to the problem and the fix.
> 
> > Wrap these to fit in 80 columns like the rest of the file.  Ideally 75
> > or so; that allows minor changes and typo fixes without overflowing.
> 
> I'll fix that in v2 too.
> 
> Before v2, though, I found something this week that changes the patch,
> so I'd ask you not to apply this version.
> 
> The quirk works today partly by accident.  On resume, the firmware of
> these Macs tries to write to the Thunderbolt controller through the
> PCIe2CIO mailbox of its upstream bridge, and on Linux those accesses
> currently go to the wrong device: ACPICA works out the PCI address of
> the bridge's config region while the bridge's bus numbers are still
> reset, and caches 00:00.0.  Each access then times out, which is where
> most of the ~16 s noirq resume that Darrell reported comes from.  There
> are two pull requests for this in ACPICA:
> 
>   https://github.com/open-acpica/acpica/pull/1235
>   https://github.com/open-acpica/acpica/pull/1236
> 
> With that fixed, resume drops to about 4 s, but the firmware's writes
> now succeed, and one of them sets bit 26 of dword 0x3c of the
> controller's switch config space (VSC_CS_20 in the plug events
> capability).  With that bit set, SXFP() really cuts power to the
> controller, and on resume Linux does not bring it back.  With the
> ACPICA change and this patch, and a USB disk attached, the controller
> with the disk was lost in 3 of 3 suspend cycles, in two of them
> together with the other controller, and resume took about 35 s.
> Clearing the bit through the same mailbox before SXFP() runs fixes it:
> 15 of 15 cycles resumed in about 4 s with the disk still there.
> Without the ACPICA change the firmware's write never lands, which is
> why this version works as posted and in Darrell's tests.
> 
> I also checked whether the ACPICA change makes the quirk unnecessary.
> It doesn't: in my test without the quirk, with the disk attached, the
> link to that controller still did not come up after resume (LnkSta x0),
> as described in the commit message.
> 
> So v2 would clear that bit before calling SXFP(), so that the quirk
> keeps working once the ACPICA change lands.
> 
> Mika, I only know what this bit does from measuring it: with it set,
> dropping the controller's power pin turns the NHI off; with it clear,
> the NHI stays up.  Do you know what bit 26 of VSC_CS_20 is on Alpine
> Ridge, and whether it is fine for the OS to clear it before cutting
> power this way?  If it has a name, I'd like to use it in v2 instead of
> a magic number.  And if you think this belongs in the thunderbolt
> driver rather than in a PCI quirk, I'm happy to move it there.

Sorry for the delay - I was on vacation. Unfortunately I can't expose any
of the non-public bits without going through an extensive paper work. I can
comment on the ACPI bits, though. I think they can be put into
drivers/thunderbolt/acpi.c if they are strictly TB specific.