Shaveta, All UEFI drivers (not just ones for PCI controllers) are responsible for evaluating the ControllerHandle in their EFI Driver Binding Supported() and Start() APIs to make sure the ControllerHandle is the type the driver knows how to manage. If there is more than one driver that can correctly manage the same ControllerHandle, then there are precedence rules for the order that each driver's Supported() and Stop() APIs are called.
This is described in the UEFP Spec and the UEFI Driver Writer's Guide. See UEFI DWG Section 3.14.1 for precedence rules. See UEFI DWG Section 18.3 for details on what a PCI Driver is recommended to do in their Supported() and Start() functions. https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer's-Guide Mike > -----Original Message----- > From: Shaveta Leekha [mailto:shaveta.lee...@nxp.com] > Sent: Wednesday, May 4, 2016 12:23 AM > To: Kinney, Michael D <michael.d.kin...@intel.com>; Laszlo Ersek > <ler...@redhat.com> > Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org> > Subject: RE: [edk2] Two PCI IO protocols getting produced by same GUID, how > to open > correct one? > > Thanks for the reply > My replies are in-lined. > > Thanks and Regards, > Shaveta > > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Kinney, Michael > D > Sent: Tuesday, May 03, 2016 9:29 PM > To: Shaveta Leekha <shaveta.lee...@nxp.com>; Laszlo Ersek > <ler...@redhat.com>; Kinney, > Michael D <michael.d.kin...@intel.com> > Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org> > Subject: Re: [edk2] Two PCI IO protocols getting produced by same GUID, how > to open > correct one? > > Shaveta, > > As long as all PCI I/O Protocol instances in the platform conform to UEFI > spec, it can > work. > > [Shaveta] Correct. > > Your original question was about how to tell that a handle has the PCI I/O > Protocol > produced By PCI Bus Driver or your emulation of PCI. If the PCI I/O > Protocols are > conformant, then It should not matter. Just write a PCI Device Driver that > manages a > PCI controller based on PCI Class code or Vendor ID/Device ID matching and it > should > work. > > [Shaveta] Yes, eventually correct the PCI I/O Protocol produced my PCI > emulation layer > code is getting opened. > As and when a valid protocol gets opened, I am checking the CLASS code and > Sub-CLASS > code before proceeding. > And that's working. > > But what if, some other device's driver in my system, intended to open "PCI > I/O > Protocol produced By PCI Bus Driver" > Doesn't test CLASS CODE or any SUB-CLASS/VENDOR etc., then it may land up > using API's > provided with protocol > Of my PCI emulation layer code? is that understanding correct ?? > > So in such scenarios, where more than one protocol instances (with different > APIs > associated) are installed with same GUID in the system, > Then all the drivers should check VENDOR ID/CLASS etc immediately after > opening the > protocol? > > > > Mike > > > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Shaveta Leekha > > Sent: Tuesday, May 3, 2016 3:27 AM > > To: Laszlo Ersek <ler...@redhat.com> > > Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org> > > Subject: Re: [edk2] Two PCI IO protocols getting produced by same > > GUID, how to open correct one? > > > > > > > > -----Original Message----- > > From: Laszlo Ersek [mailto:ler...@redhat.com] > > Sent: Tuesday, May 03, 2016 1:15 PM > > To: Shaveta Leekha <shaveta.lee...@nxp.com> > > Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org> > > Subject: Re: [edk2] Two PCI IO protocols getting produced by same > > GUID, how to open correct one? > > > > On 05/03/16 08:54, Shaveta Leekha wrote: > > > Hi, > > > > > > I have a scenario where two separate drivers are installing/producing > > > "PCI IO" > > protocol with same GUID (gEfiPciIoProtocolGuid). > > > > > > Where: > > > > > > (1) One of the PCI Io protocol instance is produced by > > "MdeModulePkg/Bus/Pci/PciBus" driver for real PCI devices to use( like > > E1000/NIC card to use) > > > > > > (2) Other PCI Io protocol instance is produced by "Pci Emulation" > > > layer created > > for USB and SATA kind of controllers. This protocol (APIs) is intended > > to be used by USB and SATA controller drivers. > > > > > > Now when I use "OpenProtocol" in my "Platform specific Sata controller > > > driver" > using: > > > > > > Status = gBS->OpenProtocol ( > > > Controller, > > > &gEfiPciIoProtocolGuid, > > > (VOID **) &PciIo, > > > This->DriverBindingHandle, > > > Controller, > > > EFI_OPEN_PROTOCOL_GET_PROTOCOL > > > ); > > > > > > How can I make sure that PCI Io protocol that is produced by > > > "PciEmulation" layer > > driver is getting opened? > > > > > > As "gEfiPciIoProtocolGuid" is same for both protocol instances. > > > > > > How to handle such scenarios? > > > > The UEFI spec forbids installing more than one protocol interface with > > the same GUID on the same handle. See > > EFI_BOOT_SERVICES.InstallProtocolInterface(): > > > > [... The same GUID cannot be installed more than once onto the same > > handle. If installation of a duplicate GUID on a handle is attempted, > > an EFI_INVALID_PARAMETER will result. [...] > > > > EFI_INVALID_PARAMETER Protocol is already installed on the handle > > specified by Handle. > > > > If you have two separate UEFI drivers that install PciIo interfaces on > > handles, then their EFI_DRIVER_BINDING_PROTOCOL.Supported() methods > > may report success only on distinct sets of handles. There must be no > > overlap. > > > > But, in any case, I think it's very unusual to have two drivers that > > produce PciIo interfaces. According to the "Driver Writer's Guide for > > UEFI 2.3.1" (03/08/2012, Version 1.01), section "18.2 PCI Bus Drivers": > > > > TIP: PCI Bus Driver customizations are *strongly discouraged* > > because the PCI Bus Driver is designed to be conformant with > > the /PCI Specification/. Instead, focus platform specific > > customizations on the Root Bridge Driver that produced > > EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL and its PCI Device Drivers. > > > > > > [Shaveta] > > Yes, it is un-usual and we had discussed over it also. > > > > So the scenario is: > > ================ > > On LS2080 platform, we have real PCI controllers that have E1000 card > > on them(used for networking purposes) And USB and SATA controllers are > > on-board. > > So to provide SATA and USB, a PCIe emulation layer, a PCI IO protocol > > is installed in PciEmulation code. > > PciEmulation code is very thin layer that simply produce > > PciRootBridgeIo protocol and hence PCI IO protocol, Hence bypass the > > need of "real Pci Bus" code. > > > > Reference is taken from ArmJune platform code in EDK2. In it, it install : > > (1) PCI IO protocol using "gEfiPciIoProtocolGuid" in > > ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c > > (2) It also install " gEfiPciRootBridgeIoProtocolGuid" protocol, using > > which "PciBusDxe" will produce PciIo protocol > > > > The same we are doing for our platform. > > For real PCI controller, we have " installed Root Bridge PCI IO > > protocol with gEfiPciRootBridgeIoProtocolGuid" > > And for emulation layer, the code direcly install PCI IO protocol with > > gEfiPciIoProtocolGuid" > > > > Regards, > > Shaveta > > > > Laszlo > > > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
