Re: Followup : EfiTestManagedDevice() issue in driver GetControllerName() function

[Jeff Westfahl <jeff.westfahl@ni.com>]

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,
>>             g<devicename>DriverBinding.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 <drivername>.efi" from the shell,
>> openinfo on the handle returns:
>>
>> Handle 188 (6E16A798)
>> ComponentName2
>> ComponentName
>> DriverBinding
>>   Drv[01] Ctrl[ ] Cnt(200) HandProt  Image(<null string>)
>> ImageDevicePath
>>   Drv[187] Ctrl[ ] Cnt(01) GetProt  Image(<null string>)
>> LoadedImage
>>   Drv[01] Ctrl[ ] Cnt(09) HandProt  Image(<null string>)
>>
>> 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
>