From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web11.17372.1590167068699637480 for ; Fri, 22 May 2020 10:04:29 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: ard.biesheuvel@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3890855D; Fri, 22 May 2020 10:04:27 -0700 (PDT) Received: from [192.168.1.81] (unknown [10.37.8.117]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7E8F73F305; Fri, 22 May 2020 10:04:23 -0700 (PDT) Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/NonDiscoverablePciDeviceDxe: connect handles on registration To: Laszlo Ersek , devel@edk2.groups.io Cc: liming.gao@intel.com, leif@nuviainc.com, Hao A Wu , Ray Ni References: <20200521111028.25864-1-ard.biesheuvel@arm.com> <57a1a8c5-2f07-dced-f28c-b1892560881f@redhat.com> <280a3ab4-2dcc-9551-4fdf-4354ba6c52fd@arm.com> <6bbf1245-94a4-6621-be0d-699c803f9d7d@redhat.com> <2e364452-eb05-c724-096f-89ffc1421226@redhat.com> <129aa70d-d72f-3bcc-8aca-76fc6859ddf2@redhat.com> From: "Ard Biesheuvel" Message-ID: <549622c2-b643-5039-90fc-e5b2a7de0037@arm.com> Date: Fri, 22 May 2020 19:04:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <129aa70d-d72f-3bcc-8aca-76fc6859ddf2@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 5/22/20 6:48 PM, Laszlo Ersek wrote: > On 05/22/20 18:46, Laszlo Ersek wrote: > >> the spec led me to believe > > Well, if I had read a few more pages from the spec... It's totally my > fault! :) sorry, it's Friday! :) > No worries, thanks for taking the time to dig into this. I had already noticed that the DriverImageHandle[] approach does not work, it indeed simply changes the order in which drivers are considered. So I found a way to fix this in the BDS, which is not as clean as I like, but not that intrusive either. It turns out the the existing code plays nicely with the driver model in most cases, the only place where it cuts corners is when it connects the short-form USB device path for the console keyboard - this is the only place where it mucks around with PCI I/O handles explicitly, to connect USB host controllers. So we can simply do the same for non-discoverable uhci/ehci/xhci devices, i.e., connect them non-recursively so that the PCI I/O protocol as well as the USB host controller protocol are installed (which is fine, as the latter was going to be installed by the BDS anyway)