From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ni.com (skprod3.natinst.com [130.164.80.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3015482229 for ; Tue, 21 Feb 2017 14:11:14 -0800 (PST) Received: from us-aus-exhub2.ni.corp.natinst.com (us-aus-exhub2.ni.corp.natinst.com [130.164.68.32]) by us-aus-skprod3.natinst.com (8.16.0.17/8.16.0.17) with ESMTPS id v1LMArew009217 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 21 Feb 2017 16:10:53 -0600 Received: from us-aus-exch3.ni.corp.natinst.com (130.164.68.13) by us-aus-exhub2.ni.corp.natinst.com (130.164.68.32) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 21 Feb 2017 16:10:53 -0600 Received: from us-aus-exhub1.ni.corp.natinst.com (130.164.68.41) by us-aus-exch3.ni.corp.natinst.com (130.164.68.13) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 21 Feb 2017 16:10:52 -0600 Received: from jmw-lm181.amer.corp.natinst.com (130.164.49.7) by us-aus-exhub1.ni.corp.natinst.com (130.164.68.41) with Microsoft SMTP Server id 15.0.1156.6 via Frontend Transport; Tue, 21 Feb 2017 16:10:52 -0600 Date: Tue, 21 Feb 2017 16:10:52 -0600 From: Jeff Westfahl X-X-Sender: jwestfah@jmw-lm181 To: "David A. Van Arnem" CC: In-Reply-To: <7598de7b-8320-a968-bada-3c3c4f2ceeff@cmlab.biz> Message-ID: References: <7598de7b-8320-a968-bada-3c3c4f2ceeff@cmlab.biz> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-21_19:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702210204 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:11:14 -0000 Content-Type: text/plain; charset="US-ASCII"; format=flowed Hello David, It sounds like you are trying to get a list of handles to your specific devices, correct? 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. 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 protocol for this purpose, although that may prove useful. 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. Regards, Jeff On Tue, 21 Feb 2017, David A. Van Arnem wrote: > 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 all > return EFI_UNSUPPORTED). My eventual goal is, given a buffer of handles > 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 recommended > 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 followed >> 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 = 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 = 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 handle. >> 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 ControllerHandle >> in my application to get EfiTestManagedDevice() to pass? I'm not sure >> if that's the right terminology, I'm having a little difficulty >> understanding the "child" concept in this context. Any tips appreciated. >> > > -- > 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 >