From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751619AbdFEION (ORCPT ); Mon, 5 Jun 2017 04:14:13 -0400 Received: from mailout2.hostsharing.net ([83.223.90.233]:41257 "EHLO mailout2.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751601AbdFEIOL (ORCPT ); Mon, 5 Jun 2017 04:14:11 -0400 Date: Mon, 5 Jun 2017 10:14:37 +0200 From: Lukas Wunner To: Mika Westerberg Cc: Greg Kroah-Hartman , Andreas Noever , Michael Jamet , Yehezkel Bernat , Amir Levy , Andy Lutomirski , Mario.Limonciello@dell.com, Jared.Dominguez@dell.com, Andy Shevchenko , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 19/27] thunderbolt: Add new Thunderbolt PCI IDs Message-ID: <20170605081437.GA7519@wunner.de> References: <20170602140524.23367-1-mika.westerberg@linux.intel.com> <20170602140524.23367-20-mika.westerberg@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170602140524.23367-20-mika.westerberg@linux.intel.com> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 02, 2017 at 05:05:16PM +0300, Mika Westerberg wrote: > --- a/drivers/thunderbolt/nhi.h > +++ b/drivers/thunderbolt/nhi.h > @@ -143,4 +143,21 @@ static inline int ring_tx(struct tb_ring *ring, struct ring_frame *frame) > return __ring_enqueue(ring, frame); > } > > +/* > + * PCI IDs used in this driver from Win Ridge forward. There is no > + * need for the PCI quirk anymore as we will use ICM also on Apple > + * hardware. > + */ I wrote a patch a few months ago which replaces the PCI quirk with device links: https://github.com/l1k/linux/commit/8e2e7eaa1163 I was going to upstream this sometime this year, it probably would have been better if I had done that already but I wasn't expecting your series. In any case, all Thunderbolt PCI device IDs can then be moved to a header in drivers/thunderbolt/, except for a few TB1 devices which are referenced by quirk_thunderbolt_hotplug_msi() and quirk_apple_poweroff_thunderbolt(). As to using ICM on Apple hardware, I've heard from people with Alpine Ridge MacBook Pros that the native (i.e. non-ICM) driver at least probes fine. I've yet to hear from folks who have actually tested it with any attached TB3 devices, but my expectation would be that it should work fine in native mode since the protocol seems to be the same. I think I saw somewhere that you reset the root switch when reconfiguring the chip to run in ICM mode. That's a problem because on Apple hardware, there's a (native, non-ICM) EFI NHI driver which sets up tunnels to any devices which are already attached on boot. This can be used to boot from Thunderbolt-attached harddisks. I imagine that resetting the chip to switch to ICM-mode will cause those already established tunnels to go away, essentially breaking booting from TB-attached disks. That's a regression which we should try to avoid. Ideally, the user should be able to choose whether to use ICM-mode or native mode. This could be implemented via a module parameter. I imagine it might even be possible to use native mode on non-Macs and this should be allowed as well. Thanks, Lukas