From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=neutral (domain: softiron.com, ip: 93.95.224.70, mailfrom: alan@softiron.com) Received: from mail-03.1984.is (mail-03.1984.is [93.95.224.70]) by groups.io with SMTP; Fri, 24 May 2019 06:53:00 -0700 Received: from localhost by mail-03.1984.is with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1hUAce-0003l9-5T; Fri, 24 May 2019 13:52:36 +0000 Subject: Re: [edk2] [RFC PATCH] OptionRomPkg: import MarvelYukonDxe driver To: Ard Biesheuvel , Leif Lindholm , Thomas Panakamattam Abraham , edk2-devel-groups-io , Alan Ott Cc: Robin Murphy , Ruiyu Ni , Michael D Kinney , Andrew Fish References: <20170419142520.16571-1-leif.lindholm@linaro.org> <20190523162443.eqbgnfqbrndc3t7e@bivouac.eciton.net> From: Alan Ott Message-ID: <99c13c94-9dd6-7eb2-beee-10a6d898d7c8@softiron.com> Date: Fri, 24 May 2019 09:52:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US On 5/23/19 12:36 PM, Ard Biesheuvel wrote: > (cc the correct list) > > On Thu, 23 May 2019 at 17:24, Leif Lindholm wrote: >> On Tue, May 21, 2019 at 02:38:47PM +0100, Ard Biesheuvel wrote: >>> (+ Robin) >>> >>> On Wed, 19 Apr 2017 at 15:25, Leif Lindholm wrote: >>>> The Marvell Yukon Ethernet controller driver has existed in >>>> OpenPlatformPkg for a while now. The chip exists on plug-in cards, >>>> as well as (at least) the ARM Juno development board and the >>>> Softiron 1000 platform. >>>> >>>> Buildable as a standalone driver, also as EBC. >>>> >>>> Contributed-under: TianoCore Contribution Agreement 1.0 >>>> Signed-off-by: Leif Lindholm >>> Given that all of OptionRomPkg has been moved out of edk2 now, can we >>> resurrect this driver in edk2-platforms/Silicon/Marvell perhaps? >> Yes. The only thing holding it back was me wishing to either improve >> on its coding style conformance or at least separate the imported bits >> from the UEFI glue. The history of that driver isn't great. >> >> At the same time, as you commented on the DwEmax driver, separation >> between MAC and PHY would be a nice thing to have, and that driver >> also doesn't. >> > Yes, but since no generic abstraction exists today, this is going to > be a longer term effort anyway, and so it shouldn't block > reintroduction of this driver. > >> Then again, the driver is fairly well tested and seems to work OK, so >> if someone was to resubmit the final version from >> https://git.linaro.org/uefi/OpenPlatformPkg.git, reworked for >> edk2-platforms, I might just go along with it. >> > OK, so taking the existing code and making it build in edk2-platforms > is not going to be a huge amount of work, and I'm happy to look into > that, provided that there is a point to doing so. > > Robin brought this up so I assume he has an interest in this. > > Thomas, Alan, could you comment as well, please? It sounds good to me. The driver worked for us on OverDrive 1000 and iirc worked for others on Juno. Alan.