Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751310AbdFETnY (ORCPT ); Mon, 5 Jun 2017 15:43:24 -0400 Received: from mga03.intel.com ([134.134.136.65]:10169 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751170AbdFETnW (ORCPT ); Mon, 5 Jun 2017 15:43:22 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,302,1493708400"; d="scan'208";a="1138216883" Date: Mon, 5 Jun 2017 22:43:16 +0300 From: Mika Westerberg To: Andreas Noever Cc: Greg Kroah-Hartman , Michael Jamet , Yehezkel Bernat , Lukas Wunner , Amir Levy , Andy Lutomirski , Mario.Limonciello@dell.com, Jared.Dominguez@dell.com, Andy Shevchenko , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v3 00/27] Thunderbolt security levels and NVM firmware upgrade Message-ID: <20170605194316.GU3454@lahna.fi.intel.com> References: <20170602140524.23367-1-mika.westerberg@linux.intel.com> <20170603091704.GC1103@kroah.com> <20170605071838.GJ3454@lahna.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3033 Lines: 68 On Mon, Jun 05, 2017 at 07:01:10PM +0200, Andreas Noever wrote: > On Mon, Jun 5, 2017 at 9:18 AM, Mika Westerberg > wrote: > > On Sat, Jun 03, 2017 at 06:17:04PM +0900, Greg Kroah-Hartman wrote: > >> On Fri, Jun 02, 2017 at 05:04:57PM +0300, Mika Westerberg wrote: > >> > Hi, > >> > > >> > This is a third version of the patch series adding support for Thunderbolt > >> > security levels and NVM firmware upgrade. PCs running Intel Falcon Ridge or > >> > newer need these in order to connect devices if the security level is set > >> > to "user(SL1) or secure(SL2)" from BIOS. > >> > >> All looks good to me, very nice work. > > > > Thanks! > > > >> I don't know what tree it should go in through, but if Andreas wants me > >> to take it, I will if I can get his signed-off-by. > > > > That would be perfect. > > > > Andreas, do you have any objections? > No, Thanks a lot. > > Signed-off-by: Andreas Noever Thanks! > Greg, can you take this through your tree? > > > > Mika, I have a quick question regarding the pci side of things (your > "pci=hpbussize=10,hpmemsize=2M" workaround). Does that work for nested > hotplug or just on the first level? Back when I was having a look at > enabling chaining in the native driver I could not get pci to properly > assign bus numbers to nested bridges. It always ran out of bus number > after one level (irregardless of hpbussize). Has the pci behaviour > changed or does the ICM somehow preconfigure the bridges before > handing them of to linux? I don't think ICM does any preconfiguration when native PCIe hotplug is used. For PCs we typically use BIOS assisted ACPI hotplug and the SMI handler configures the bridges before it notifies the OS. In case of native PCIe hotplug, it still runs out of bus space, that's why it is workaround. It works to some depth though, because it adds 10 to all bridges that it finds when the scan is done. When next device is added you have that 10 which it then allocates to bridges downstream. Anyway it should be fixed properly and it is on my todo list once I get still missing parts finished. Unless someone else fixes it first, that is ;-) One solution that I've been thinking is to introduce some sort of resource allocation policies to root ports depending what is connected to them, and in case of Thunderbolt we follow the BIOS assisted hotplug way so that we assign the remaining resources to the downstream port where the chain is extended (this can be figured out from the registers, I think). There is also another PCI/ACPI related issue that Mario reported where we execute _INI() methods before the initial PCI scan on boot when Thunderbolt device is connected causing Linux to accidentally find the upstream port of the Thunderbolt host controller before it is configured properly by the BIOS ACPI hotplug handler. I've discussed this with Rafael and he has an idea how we could fix it but it probably requires some changes to ACPICA first. Also on my todo list :)