Re: Thunderbolt hotplug not working on MacMini7,1

From: Adam Goode <adam@spicenitz.org>
To: Andreas Noever <andreas.noever@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: Thunderbolt hotplug not working on MacMini7,1
Date: Mon, 4 May 2015 09:00:11 -0400	[thread overview]
Message-ID: <CADN=Wdo-WvF0sst1jFT4UUjMjm5J0PckyqRkrxHz+QVrXSvf=w@mail.gmail.com> (raw)
In-Reply-To: <CADN=Wdo3aKYZP=v9L+_6cpsf3cMm0AGTOWmHu3oVAMXLPPZwKA@mail.gmail.com>

On Sat, Apr 25, 2015 at 11:00 PM, Adam Goode <adam@spicenitz.org> wrote:
> Here's the problem:
>
> [    0.126595] ACPI Error: No handler for Region [CMS0]
> (ffff8802658a0438) [SystemCMOS] (20150410/evregion-163)
> [    0.126597] ACPI Error: Region SystemCMOS (ID=5) has no handler
> (20150410/exfldio-297)
> [    0.126600] ACPI Error: Method parse/execution failed
> [\_SB_.PCI0._INI] (Node ffff8802658ac500), AE_NOT_EXIST
> (20150410/psparse-536)
> [    0.126605] ACPI Exception: AE_NOT_EXIST, during
> \_SB_.PCI0._INI._INI execution (20150410/nsinit-588)
>
> ...
>
> [    0.170603]       bus-0130 bus_get_status        : Device [RTC]
> status [0000000f]
> [    0.170605] evhandler-0446 ev_install_space_handl: Creating object
> on Device ffff8802658a82a8 while installing handler
> [    0.170607] evhandler-0482 ev_install_space_handl: Installing
> address handler for region SystemCMOS(5) on Device RTC_
> ffff8802658a82a8(ffff880264160090)
> [    0.170610]  evregion-0506 ev_attach_region      : Adding Region
> [CMS0] ffff8802658a0438 to address handler ffff880264160480
> [SystemCMOS]
>
>
> Next step is to figure out how to install the address handler earlier.
>
>

Current status:

I have a patch out to fix the CMOS handler issue:
http://marc.info/?l=linux-acpi&m=143052869625376&w=2

The CMOS handler is called in the Darwin codepath as well, so it's a
useful fix regardless.

When I patched with this support, and booted in non-Darwin mode,
hotplug worked without further Linux driver support (I disabled the
thunderbolt module). Suspend/resume still does not work unless I don't
activate any thunderbolt device at all. This happens regardless of
which OSI mode.

So there is a suspend/resume problem which seems more generic. I am
not sure if I have time to debug this.

One thing that would be useful would be to change the Darwin special
case code to make it configurable on the kernel command line.

Lastly, when ACPI fully initializes the thunderbolt controller, the
Linux thunderbolt module hangs for several seconds upon loading, and
then fails. Which is probably correct, but I don't know if it messes
up any state in the mean time (plus it shouldn't hang). Is there a way
to have the module detect BIOS support and disable itself? Or to
properly do a handover?

Thanks,

Adam