public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ni, Ray" <ray.ni@intel.com>
To: vit9696 <vit9696@protonmail.com>, "Gao, Zhichao" <zhichao.gao@intel.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>
Subject: Re: [edk2-devel] [PATCH 1/1] ShellPkg: Do not connect handles without device paths
Date: Mon, 13 Jan 2020 11:56:58 +0000	[thread overview]
Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C3F2C88@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <9A165163-4BB4-434A-8C65-A84CDCB3C3C2@protonmail.com>

We shouldn't assume that a DriverBindingStart() can only start on a handle with device path installed. DevicePath protocol is just a special protocol.
It's possible that a bus driver starts on a host controller handle and creates multiple children, each with only a Specific_IO protocol installed.
Certain device driver can start on the children handle and open the Specific_IO protocol BY_DRIVER.
I am not sure if certain today's network drivers may work like this. It's allowed per UEFI spec.

Thanks,
Ray

> -----Original Message-----
> From: vit9696 <vit9696@protonmail.com>
> Sent: Monday, January 13, 2020 5:20 PM
> To: Gao, Zhichao <zhichao.gao@intel.com>
> Cc: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>
> Subject: Re: [edk2-devel] [PATCH 1/1] ShellPkg: Do not connect handles without device paths
> 
> Hi,
> 
> ‘Freeze’ means it is hung up forever, and we believe it is caused by an invalid memory access in the firmware code.
> 
> Using loading command with ‘-nc’ (no connect) will work fine, but that is kind of expected, as the issue is caused exactly by
> the connect logic.
> 
> We do not believe it is possible for device controller to exist without a device path protocol in the wild. Would you please
> provide an example? If there is something we do not know about, I can imagine introducing a PCD for this logic.
> 
> Best wishes,
> Vitaly
> 
> > 13 янв. 2020 г., в 11:11, Gao, Zhichao <zhichao.gao@intel.com> написал(а):
> >
> >
> > Hi,
> >
> > What does 'freeze' mean? System blocked for a while or it hung up forever?
> >
> > The change would affect the operation of the 'load' command. If some drivers need to connect to the device controller
> but it doesn't have a device path protocol, the behavior of 'load' may be incorrect.
> > Is the option '-nc' working for your request?
> >
> > Thanks,
> > Zhichao
> >
> >> -----Original Message-----
> >> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> >> Vitaly Cheptsov via Groups.Io
> >> Sent: Monday, January 13, 2020 5:39 AM
> >> To: devel@edk2.groups.io
> >> Subject: [edk2-devel] [PATCH 1/1] ShellPkg: Do not connect handles without
> >> device paths
> >>
> >> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2460
> >>
> >> Doing this reduces the amount of needless work during device connection
> >> and resolves issues with firmwares that freeze when connecting handles
> >> without device paths.
> >>
> >> Signed-off-by: Vitaly Cheptsov <vit9696@protonmail.com>
> >> ---
> >> ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
> >> b/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
> >> index b6e7c952fa..083aac0dba 100644
> >> --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
> >> +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
> >> @@ -32,8 +32,8 @@ ConnectAllEfi (
> >>   UINTN       Index;
> >>
> >>   Status = gBS->LocateHandleBuffer (
> >> -                  AllHandles,
> >> -                  NULL,
> >> +                  ByProtocol,
> >> +                  &gEfiDevicePathProtocolGuid,
> >>                   NULL,
> >>                   &HandleCount,
> >>                   &HandleBuffer
> >> --
> >> 2.21.0 (Apple Git-122.2)
> >>
> >>
> >> -=-=-=-=-=-=
> >> Groups.io Links: You receive all messages sent to this group.
> >>
> >> View/Reply Online (#53170): https://edk2.groups.io/g/devel/message/53170
> >> Mute This Topic: https://groups.io/mt/69653841/1768756
> >> Group Owner: devel+owner@edk2.groups.io
> >> Unsubscribe: https://edk2.groups.io/g/devel/unsub
> >> [zhichao.gao@intel.com]
> >> -=-=-=-=-=-=
> >


  reply	other threads:[~2020-01-13 11:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-12 21:38 [PATCH 0/1] ShellPkg: Do not connect handles without device paths Vitaly Cheptsov
2020-01-12 21:38 ` [PATCH 1/1] " Vitaly Cheptsov
2020-01-13  8:11   ` [edk2-devel] " Gao, Zhichao
2020-01-13  9:19     ` Vitaly Cheptsov
2020-01-13 11:56       ` Ni, Ray [this message]
2020-01-13 17:55         ` Laszlo Ersek
2020-01-13 20:46           ` Vitaly Cheptsov
2020-01-14  2:53             ` Ni, Ray
2020-01-14  8:36               ` Vitaly Cheptsov
2020-01-14 10:34                 ` Vitaly Cheptsov
2020-01-14 12:53                   ` Laszlo Ersek

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=734D49CCEBEEF84792F5B80ED585239D5C3F2C88@SHSMSX104.ccr.corp.intel.com \
    --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