From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web12.5274.1591080982626258912 for ; Mon, 01 Jun 2020 23:56:22 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: ard.biesheuvel@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8405A1FB; Mon, 1 Jun 2020 23:56:21 -0700 (PDT) Received: from [192.168.1.69] (unknown [10.37.8.209]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C31443F305; Mon, 1 Jun 2020 23:56:20 -0700 (PDT) Subject: Re: [edk2-devel] [PATCH edk2-platforms] Platform/OverdriveBoard: work around network ConnectAll() dependency To: Leif Lindholm , devel@edk2.groups.io Cc: alan@softiron.com References: <20200529214019.6063-1-ard.biesheuvel@arm.com> <20200601131905.GF28566@vanye> From: "Ard Biesheuvel" Message-ID: <99fee844-0fab-6cbf-400b-d5ffd9960d43@arm.com> Date: Tue, 2 Jun 2020 08:56:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200601131905.GF28566@vanye> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 6/1/20 3:19 PM, Leif Lindholm wrote: > On Fri, May 29, 2020 at 23:40:19 +0200, Ard Biesheuvel wrote: >> The AMD Seattle based platforms have been kept up to date in recent >> years, even though the hardware is obsolete and was never available >> that widely in the first place. >> >> However, one aspect that has sadly been left behind is the support for >> the builtin network controllers. These are only wired up and enabled >> on the Overdrive board to begin with, and the driver was only made >> available as two separate binary blobs implementing the SNP protocol >> for each controller separately, without taking the UEFI driver model >> into account. >> >> Even worse, the PHY initialization code that needs to run at boot in >> order for the OS to be able to use the device never executes unless >> the upper networking layers start the SNP protocol, which doesn't >> happen on a fast boot (one that does not use ConnectAll()) unless the >> boot target is a network device path. >> >> We cannot fix the driver, but fortunately, there is another way out: >> protocols that are installed on a handle during the execution of the >> entrypoint of a driver will be connected by the DXE core, and so we >> can ensure that the old behavior is retained regardless of whether >> ConnectAll() is ever invoked, by reordering the load sequence so that >> the upper layer drivers have all been registered by the time the >> entrypoints of the SNP drivers are called. >> >> This relies on FV contents to be dispatched in the order they appear >> in the .FDF file. The AMD SNP driver as well as the upper layer >> drivers in NetworkPkg are UEFI_DRIVER modules, which means their >> DEPEXes are implicitly defined as the full set of architectural >> PI protocols. This means that all these modules become available for >> dispatch at the same time, and their dispatch order is fully defined >> by the order of appearance in the FV. Unfortunately, this is an >> implementation detail rather than something that is supported by the >> PI spec, but this is unlikely to ever change since other platforms >> undoubtedly exist that depend on this behavior as well. >> >> Signed-off-by: Ard Biesheuvel > > I'm holding my nose a bit, but: > Reviewed-by: Leif Lindholm > I know :-) Pushed as 747eeac8a8b9..608d71ec9396