From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755293AbcHXLN3 (ORCPT ); Wed, 24 Aug 2016 07:13:29 -0400 Received: from goliath.siemens.de ([192.35.17.28]:39513 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753247AbcHXLN1 (ORCPT ); Wed, 24 Aug 2016 07:13:27 -0400 Subject: Re: x86/PCI: Scan all functions during probing To: Thomas Gleixner , Bjorn Helgaas References: <20160809134452.GA27301@localhost> <20160818203348.GK27353@localhost> Cc: LKML , x86@kernel.org, Bjorn Helgaas , linux-pci@vger.kernel.org, Benedikt Spranger , Lukas Wunner From: Jan Kiszka Message-ID: <73341fe4-9017-7dcb-7ae3-a993428c11fc@siemens.com> Date: Wed, 24 Aug 2016 07:13:12 -0400 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016-08-24 04:39, Thomas Gleixner wrote: > On Thu, 18 Aug 2016, Bjorn Helgaas wrote: >> I looked up the spec: PCI (not PCIe) r3.0, sec 3.2.2.3.4, says: >> >> A single-function device may optionally respond to all function >> numbers as the same function or may ... respond only to function 0 >> and not respond to the other function numbers. >> >> I'm concerned that a single-function device that responds to all >> function numbers might break with this patch. >> >> [multi-function devices] are also required to always implement >> function 0 in the device. >> >> Here's the reason we can advance by 8 in the "Go find them" loop. >> >> If a single function device is detected (i.e., bit 7 in the Header >> Type register of function 0 is 0), no more functions for that Device >> Number will be checked. If a multi-function device is detected >> (i.e., bit 7 in the Header Type register of function 0 is 1), then >> all remaining Function Numbers will be checked. >> >> This patch does the opposite of what the first sentence recommends. > > Fair enough. We'll need to find a way to deal with that in jailhouse then. Wouldn't it also be an option to have this fine-grained scanning only activated if we detect to run over Jailhouse (which we have to anyway)? Such code hasn't been proposed for upstream yet, but we will eventually. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux