From: "David A. Van Arnem" <dvanarnem@cmlab.biz>
To: Jeff Westfahl <jeff.westfahl@ni.com>
Cc: edk2-devel@lists.01.org
Subject: Re: Followup : EfiTestManagedDevice() issue in driver GetControllerName() function
Date: Tue, 21 Feb 2017 15:57:39 -0700 [thread overview]
Message-ID: <cb267745-0b90-3210-01c3-b3f7f0f1750d@cmlab.biz> (raw)
In-Reply-To: <alpine.DEB.2.20.1702211626340.8161@jmw-lm181>
On 02/21/2017 03:30 PM, Jeff Westfahl wrote:
> 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.
Great! Thanks for your time.
Regards,
David
>
> 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,
>>>>> 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
>>>>
>>
>> --
>> Regards,
>> David Van Arnem
>> Development Engineer IV
>> Computer Measurement Laboratory, LLC
>>
>>
--
Regards,
David Van Arnem
Development Engineer IV
Computer Measurement Laboratory, LLC
prev parent reply other threads:[~2017-02-21 22:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-21 20:07 EfiTestManagedDevice() issue in driver GetControllerName() function David A. Van Arnem
2017-02-21 21:37 ` Followup : " David A. Van Arnem
2017-02-21 22:10 ` Jeff Westfahl
2017-02-21 22:24 ` David A. Van Arnem
2017-02-21 22:30 ` Jeff Westfahl
2017-02-21 22:57 ` David A. Van Arnem [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cb267745-0b90-3210-01c3-b3f7f0f1750d@cmlab.biz \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox