Re: [PATCH edk2-platforms v1 22/38] Platform/Hisilicon/D06: Add OemNicLib

[Leif Lindholm <leif.lindholm@linaro.org>]

On Wed, Aug 15, 2018 at 07:08:33PM +0800, Ming wrote:
> >>> Yes please.
> >>> It would be good if we could have some (common) code to handle the
> >>> fluke situation where you end up without your own MAC address.
> >>> (So that the node can boot up and report that it is broken.)
> >>> But it needs to be done in a reliable way, and that's too big a task
> >>> for 18.08.
> >>
> >> I found some modules which invoke OemGetMac() don't judge the Status of
> >> OemGetMac, so it may cause some issue now if changing to EFI_NOT_FOUND.
> >> How about change it while we handle the fluke situation after 18.08 ?
> > 
> > We cannot release 18.08 with known bugs.
> > And not checking return value is a bug.
> > 
> > I presume you mean that these calling functions are inside HwPkg?
> 
> Yes.
> 
> All D06 board will burn a Mac to eeprom before delivery and there is a
> command (SetMac) to write a Mac.
> 
> For handling the fluke situation, we think there are several ways:
> 1 Initialize Mac to 0xFF;
>   Kernel seems will create a random Mac while the Mac is 0xFF.

I have no objections to that, but it would prevent from netbooting.

But being unable to read the eeprom is a serious hw failure. So my gut
feeling is that this should prevent the system from booting
completely. If you want to make it possible to boot at all, and don't
mind giving up netbooting for systems with known hardware failure, I
think that's acceptable.

> 2 Make a Mac from ArmReadCntPct() and gTR->GetTime();
> 3 Make a locally administered Mac from ArmReadCntPct() and gTR->GetTime();
> 
> The 2nd is the way our product project use to handle the fluke situation.
> What is your suggestion?

2 is not OK.

3 would be totally valid, but is basically just "do 2 properly".

And doing 2 properly means doing ARP lookups to ensure we don't have
any duplicate MACs on the current network segment. Which is more
effort (and probably functionality we want to get into edk2 core).

My recommendation for 18.08 would be doing 1. Then we have time to
discuss nicer fallback options afterwards.

/
    Leif