From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80A88C19F2D for ; Tue, 9 Aug 2022 11:08:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240642AbiHILIz (ORCPT ); Tue, 9 Aug 2022 07:08:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40826 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231717AbiHILIx (ORCPT ); Tue, 9 Aug 2022 07:08:53 -0400 Received: from ns3.fnarfbargle.com (ns3.fnarfbargle.com [103.4.19.87]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 654EB11C18 for ; Tue, 9 Aug 2022 04:08:52 -0700 (PDT) Received: from [10.8.0.1] (helo=srv.home) by ns3.fnarfbargle.com with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oLN6Q-0004ON-V5; Tue, 09 Aug 2022 21:08:50 +1000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fnarfbargle.com; s=mail; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=B4+92h9bcpkDDgAcJ3CHRFPoFp0LcxuJgNNoznaNPqE=; b=pIrPj/b/aMUIYHvG92SocqAsxe CnkwsKJZpMmxlIrd93nk1MtNB6J4ltPni4L9cv6OXTKvoCnQyWyS620RU+134B6ZuB4if+qJmOOXS 37bQMQDDx/lUQcYI+q/UXKMIjHMD7j2uvHu49Zkzhg79rYGJMjR3C3yozLCbwJc0d8v4=; Message-ID: <86bec398-7a5b-6d4e-bc02-5941fe6c2e73@fnarfbargle.com> Date: Tue, 9 Aug 2022 19:08:42 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: Apple Thunderbolt Display chaining Content-Language: en-US To: Mika Westerberg Cc: linux-kernel@vger.kernel.org References: <87c1a001-ef79-6390-dfe2-06d2850f6e84@fnarfbargle.com> <42e81a8e-e393-7a69-7339-a020ebb57935@fnarfbargle.com> <5474e599-057a-ec0f-b469-560644155907@fnarfbargle.com> From: Brad Campbell In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/8/22 18:55, Mika Westerberg wrote: > Hi, > > On Tue, Aug 09, 2022 at 06:40:54PM +0800, Brad Campbell wrote: >> G'day Mika, >> >> >> On 9/8/22 18:23, Mika Westerberg wrote: >>> Hi, >>> >>> On Mon, Aug 08, 2022 at 09:27:24PM +0800, Brad Campbell wrote: >>>> If I don't authorize the PCIe tunnels and just leave the DP enabled it >>>> works fine also. >>> >>> But you say that it fails on boot when the driver discovers the tunnels, >>> right? So there is really nothing to authorize (they should be already >>> "authorized" by the boot firmware). >>> >>> If I understand correctly this is how it reproduces (the simplest): >>> >>> 1. Connect a single Apple TB1 display to the system >>> 2. Boot it up >>> 3. Wait a while and it hangs >>> >>> If this is the case, then the driver certainly is not creating any >>> PCIe tunnels itself unless there is a bug somewhere. >>> >>> An additional question, does it reproduce with either TB1 display >>> connected or just with specific TB1 display? >>> >> >> No, I've not been clear enough, I'm sorry. I've re-read what I've written below and >> I'm still not sure I'm clear enough. >> >> The firmware never sets anything up. >> >> When I cold boot the machine (from power on), the thunderbolt displays and tunnels >> remain dark until linux initializes the thunderbolt driver the first time. >> >> If I compile the thunderbolt driver into the kernel, or let the initramfs load it >> the displays come up, all PCIe tunnels are established and everything works. >> >> When I reboot the machine (reset button or warm boot), the firmware continues to >> do nothing and all the tunnels remain in place. The machine dies when the thunderbolt >> driver is loaded for a second time. >> >> That might be a reset/warm boot with it compiled in or loaded from iniramfs. >> It may also be me loading it from the command line after booting with it as a >> module and blacklisted. >> >> The problem comes about when the thunderbolt module is loaded while the PCIe tunnels >> are already established. >> >> To reproduce in the easiest manner I compile the thunderbolt driver as a module and >> blacklist it. This prevents it from auto-loading. >> >> I cold boot the machine, let it boot completely then modprobe thunderbolt and authorize >> the tunnels. I then warm boot which lets the kernel detect and init the DP displays >> and detect/configure all the PCIe devices. The thunderbolt driver is not loaded. >> >> The machine comes up, all tunnels are established and all devices work. >> >> If I then modprobe the thunderbolt driver, things break. >> >> This is the hack in my boot script : >> >> # Spark up thunderbolt >> if [ -z "`grep notb /proc/cmdline`" -a -z "`lsusb | grep '05ac:9227'`" ] ; then >> modprobe thunderbolt >> sleep 1 >> echo 1 > /sys/bus/thunderbolt/devices/0-3/authorized >> echo 1 > /sys/bus/thunderbolt/devices/0-303/authorized >> reboot >> fi > > Thanks for the clarification! How about on macOS side, does it work (I > would expect yes)? > Ahh, forgot about the laptop I'm typing this on. Yes, works fine in MacOS.