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 BA6038214B for ; Tue, 21 Feb 2017 14:30:21 -0800 (PST) Received: from us-aus-exhub1.ni.corp.natinst.com (us-aus-exhub1.ni.corp.natinst.com [130.164.68.41]) by us-aus-skprod3.natinst.com (8.16.0.17/8.16.0.17) with ESMTPS id v1LMUI5l026796 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 21 Feb 2017 16:30:18 -0600 Received: from us-aus-exhub1.ni.corp.natinst.com (130.164.68.41) by us-aus-exhub1.ni.corp.natinst.com (130.164.68.41) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 21 Feb 2017 16:30:18 -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:30:18 -0600 Date: Tue, 21 Feb 2017 16:30:17 -0600 From: Jeff Westfahl X-X-Sender: jwestfah@jmw-lm181 To: "David A. Van Arnem" CC: Jeff Westfahl , In-Reply-To: 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-1702210206 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:30:22 -0000 Content-Type: text/plain; charset="US-ASCII"; format=flowed Hi David, You would install the protocol in the start function of your driver. When the start function is called, it passes you an EFI_HANDLE. You install your protocol on this handle. Regards, Jeff On Tue, 21 Feb 2017, David A. Van Arnem wrote: > Hi Jeff, > > On 02/21/2017 03:10 PM, Jeff Westfahl wrote: >> Hello David, >> >> It sounds like you are trying to get a list of handles to your specific >> devices, correct? > > Yes, exactly. > >> >> 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. > > 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 > >> >> 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 >>> > > -- > Regards, > David Van Arnem > Development Engineer IV > Computer Measurement Laboratory, LLC > >