-----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Tuesday, May 03, 2016 9:44 PM To: Mike Kinney <[email protected]> Cc: Shaveta Leekha <[email protected]>; Laszlo Ersek <[email protected]>; [email protected] <[email protected]> Subject: Re: [edk2] Two PCI IO protocols getting produced by same GUID, how to open correct one?
> On May 3, 2016, at 8:59 AM, Kinney, Michael D <[email protected]> > wrote: > > Shaveta, > > As long as all PCI I/O Protocol instances in the platform conform to UEFI > spec, it can work. > > 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. > I would also point out that Subsystem ID and Subsystem Vendor ID can be used for this type of binding too. The Subsystem values exist to deal with cases when the same chip is used on different vendors PCI plug in cards. Thanks, Andrew Fish [Shaveta] Thanks for the reply My replies are in another mail pasted again here: [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? Thanks and Regards, Shaveta > Mike > > >> -----Original Message----- >> From: edk2-devel [mailto:[email protected]] On Behalf >> Of Shaveta Leekha >> Sent: Tuesday, May 3, 2016 3:27 AM >> To: Laszlo Ersek <[email protected]> >> Cc: [email protected] <[email protected]> >> Subject: Re: [edk2] Two PCI IO protocols getting produced by same >> GUID, how to open correct one? >> >> >> >> -----Original Message----- >> From: Laszlo Ersek [mailto:[email protected]] >> Sent: Tuesday, May 03, 2016 1:15 PM >> To: Shaveta Leekha <[email protected]> >> Cc: [email protected] <[email protected]> >> 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 >> [email protected] >> https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
