[gPXE-devel] [PATCH] EFI Simple Network Protocol driver

[Geoff Lywood]

> -----Original Message-----
> From: Michael Brown [mailto:mbrown at fensystems.co.uk]
> Sent: Saturday, May 29, 2010 4:19 PM
> To: Geoff Lywood
> Cc: gpxe-devel at etherboot.org
> Subject: Re: [gPXE-devel] [PATCH] EFI Simple Network Protocol driver
> 
> On Saturday 29 May 2010 04:58:16 Geoff Lywood wrote:
> > > 7. You have a call to OpenProtocol() for EfiLoadedImageProtocol which
> > > isn't
> > > balanced by any call to CloseProtocol.  More generally, would it be
> > > possible
> > > to use either only OpenProtocol or only LocateProtocol in order to
> obtain
> > > all
> > > the required protocols?
> >
> > Since I use EFI_OPEN_PROTOCOL_GET_PROTOCOL, I don't have to match it
> with a
> >  CloseProtocol. It says so in the spec. I think it is safe to assume
> that
> >  the current image will not go away while it is executing.
> >
> > The problem with LocateProtocol is that it will give you any instance of
> >  the protocol, not necessarily the one associated with the handle that
> you
> >  care about. In this particular case, I want the loaded image protocol
> >  associated with my own image, not just any image.
> >
> > In fact, I'm not convinced that the current uses of LocateProtocol are
> >  actually correct. For example, a system with multiple PCI root bridges
> >  will have multiple PCI root bridge I/O protocols, and there is nothing
> in
> >  the gPXE code to select the correct one.
> 
> OK.  Would it be possible/sensible to use OpenProtocol with
> EFI_OPEN_PROTOCOL_GET_PROTOCOL for all required protocols (i.e. do not use
> LocateProtocol at all)?  (This wouldn't solve the multiple PCI root bridge
> issue, but it would make the code neater, if it's allowable; I don't know
> whether or not it would work for protocols that aren't directly related to
> the
> image.)
> 
> Michael


I don't think that it is possible to use OpenProtocol for the EFI_CPU_ARCH_PROTOCOL because you never know which handle to use. Having said that, I don't think the EFI_CPU_ARCH_PROTOCOL is defined in the UEFI spec and it may not be guaranteed to exist on all platforms. The "right thing" is probably to use boot services instead, but comments in the code hint that doing so may not always work? (Can you use a high frequency timer and increment a tick count yourself?)

For the PCI and I/O protocols, I think that the network driver is generally expected to do all accesses through the EFI_PCI_IO_PROTOCOL attached to the handle for the network device, which you already open BY_DRIVER in efi_snp_netdev. Currently the wiring isn't in place to keep it open and have all config space, I/O and memory accesses go through it. I don't see how that will be possible without some major rearchitecture: every inb/outb in every driver would have to pass a device handle as a second argument.

Thanks,
Geoff