From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from server202.webhostingpad.com (server202mail.webhostingpad.com [50.31.162.9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5492382229 for ; Tue, 21 Feb 2017 14:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cmlab.biz; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc: References:To:Subject:Sender:Reply-To:Content-Transfer-Encoding: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=+YIKxYOlqhvtl7s/RQDQx8o2NpDxZVMAAxkXyHrWPCs=; b=jXatb0pZzC3wzeAnmbSAXIF4+z wKZlLFxSOG3KRwMmKKSPUeEwuAYUq2G2XgJ2UGtYK6HQss6gs4eAWbCGs9hMixLuaSbknrnmkEPOB sOu/LWuLpCiqCpZutMWhy8e7I9EIM41kaYsmWKITE8qtAMsaDPT3pr3ohXFzlSpL7ezQ=; Received: from [71.216.152.198] (port=37420 helo=[192.168.50.197]) by server202.webhostingpad.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1cgIqr-0026ju-Bi; Tue, 21 Feb 2017 16:24:05 -0600 To: Jeff Westfahl References: <7598de7b-8320-a968-bada-3c3c4f2ceeff@cmlab.biz> Cc: edk2-devel@lists.01.org From: "David A. Van Arnem" Message-ID: Date: Tue, 21 Feb 2017 15:24:04 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server202.webhostingpad.com X-AntiAbuse: Original Domain - lists.01.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - cmlab.biz X-Get-Message-Sender-Via: server202.webhostingpad.com: authenticated_id: dvanarnem@cmlab.biz X-Authenticated-Sender: server202.webhostingpad.com: dvanarnem@cmlab.biz X-Source: X-Source-Args: X-Source-Dir: X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: Followup : EfiTestManagedDevice() issue in driver GetControllerName() function X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 22:24:06 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jeff, On 02/21/2017 03:10 PM, Jeff Westfahl wrote: > Hello David, >=20 > It sounds like you are trying to get a list of handles to your specific= > devices, correct? Yes, exactly. >=20 > One way to do this is to create a new protocol for your devices and > create an instance of this protocol when your driver attaches to a PCI > device. Then you can just retrieve all handles that match your new > protocol. >=20 > Creating a new protocol for this use case could be as simple as just > allocating a unique GUID, using uuidgen or something similar. You don't= > necessarily need to have data or functions associated with your protoco= l > for this purpose, although that may prove useful. This sounds like a simple method to accomplish what I need, thanks. I assume I would install the custom protocol in the same place I install the Driver Binding and Component Name(2) implementations? Regards, David >=20 > I wouldn't consider myself an expert of any kind on UEFI drivers, so if= > others see problems with my suggestions or have better ideas, please > chime in. >=20 > Regards, > Jeff >=20 > On Tue, 21 Feb 2017, David A. Van Arnem wrote: >=20 >> Hello again, >> >> I think the problem lies in my application, as upon further >> investigation, all the handles that publish the Component Name 2 >> protocol appear to be failing the EfiTestManagedDevice() check (they a= ll >> return EFI_UNSUPPORTED). My eventual goal is, given a buffer of handl= es >> that publish EFI_PCI_IO_PROTOCOL, I would like to locate my specific >> device. I was going to do a string comparison of the ControllerName, >> but this doesn't seem to be the right approach. Is there a recommende= d >> way to accomplish this? >> >> Regards, >> David >> >> On 02/21/2017 01:07 PM, David A. Van Arnem wrote: >>> Hi all, >>> >>> I am developing a UEFI_DRIVER for a custom PCIe device. I've followe= d >>> the UEFI Driver Model, and implemented the Driver Binding, Component >>> Name, and Component Name 2 protocols for my driver. I'm trying to >>> retrieve the Controller Name from this driver in a UEFI_APPLICATION, = but >>> I've run into an issue. >>> >>> In the driver's Start() function, I open the EFI_PCI_IO_PROTOCOL on >>> ControllerHandle using the following: >>> >>> Status =3D gBS->OpenProtocol ( >>> ControllerHandle, >>> &gEfiPciIoProtocolGuid, >>> (VOID **)&PciIoProtocol, >>> This->DriverBindingHandle, >>> ControllerHandle, >>> EFI_OPEN_PROTOCOL_BY_DRIVER >>> ); >>> >>> And leave it open when Start() exits, unless some other part of the >>> Start() function fails, which doesn't appear to be happening based on= my >>> debug messages. >>> >>> Following some of the examples in edk2, in my Component Name's >>> GetControllerName() function, I used EfiTestManagedDevice() to check >>> that the ControllerHandle opened EFI_PCI_IO_PROTOCOL: >>> >>> Status =3D EfiTestManagedDevice ( >>> ControllerHandle, >>> gDriverBinding.DriverBindingHandle, >>> &gEfiPciIoProtocolGuid >>> ); >>> >>> Finally, to get the Controller Name in the application, I first get a= >>> buffer of handles that publish the ComponentName2 protocol, then walk= >>> through each and call GetControllerName(). >>> >>> However, the EfiTestManagedDevice() check in my driver is returning >>> EFI_UNSUPPORTED, indicating the protocol is not supported on the hand= le. >>> Furthermore, after using "load .efi" from the shell, >>> openinfo on the handle returns: >>> >>> Handle 188 (6E16A798) >>> ComponentName2 >>> ComponentName >>> DriverBinding >>> Drv[01] Ctrl[ ] Cnt(200) HandProt Image() >>> ImageDevicePath >>> Drv[187] Ctrl[ ] Cnt(01) GetProt Image() >>> LoadedImage >>> Drv[01] Ctrl[ ] Cnt(09) HandProt Image() >>> >>> I feel like maybe I'm missing a step here. Should I see PciIo in >>> openinfo? Do I need to open a "child" instance of the ControllerHand= le >>> in my application to get EfiTestManagedDevice() to pass? I'm not sur= e >>> if that's the right terminology, I'm having a little difficulty >>> understanding the "child" concept in this context. Any tips >>> appreciated. >>> >> >> --=20 >> Regards, >> David Van Arnem >> Development Engineer IV >> Computer Measurement Laboratory, LLC >> >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel >> --=20 Regards, David Van Arnem Development Engineer IV Computer Measurement Laboratory, LLC