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.1476.1588190652072625790 for ; Wed, 29 Apr 2020 13:04:12 -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 993351063; Wed, 29 Apr 2020 13:04:10 -0700 (PDT) Received: from [192.168.1.81] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 861CB3F68F; Wed, 29 Apr 2020 13:04:09 -0700 (PDT) Subject: Re: [PATCH 0/3] BaseTools,EmbeddedPkg,Maintainers.txt: Obsolete some drivers To: Leif Lindholm Cc: devel@edk2.groups.io, Andrew Fish , Bob Feng , Laszlo Ersek , Liming Gao , Michael D Kinney References: <20200429163616.5951-1-leif@nuviainc.com> <10151f16-f903-6fcf-92c8-f28f269eab53@arm.com> <20200429195343.GI21486@vanye> From: "Ard Biesheuvel" Message-ID: <464be692-53ef-8cac-ec69-2f87cc6f59cb@arm.com> Date: Wed, 29 Apr 2020 22:04:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200429195343.GI21486@vanye> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 4/29/20 9:53 PM, Leif Lindholm wrote: > On Wed, Apr 29, 2020 at 19:51:12 +0200, Ard Biesheuvel wrote: >> On 4/29/20 6:36 PM, Leif Lindholm wrote: >>> We keep seeing new users (and copies) of EmbeddedPkg:s MmcDxe, which >>> while it predates the MdeModulePkg SD/(E)MMCsupport is in effect >>> unmaintained and also duplicates core industry standard definitions. >>> >>> Since we now have GetMaintainers.py to parse Maintainers.txt for us, >>> extend its functionality to warn about less supported code. >>> >>> Then as an indication of its unsuitability for reference (or use), set >>> its Status flag in Maintainers.txt to Obsolete. >>> >>> Once this is done, follow up and do the same with the hardware drivers >>> (not the software ones) still left in EmbeddedPkg/Drivers. They were >>> added back when not using the UEFI driver model was still cool, or >>> simply before edk2-platforms existed. >>> They should move to edk2-platforms, but most of them require some >>> level of rewriting before that. >>> >>> 1/3 adds a warning printout to GetMaintainer.py >>> >>> 2/3 obsoletes EmbeddedPkg/Universal/MmcDxe/ >>> >>> 3/3 obsoletes remaining hw drivers in EmbeddedPkg/Drivers >>> Cc: Andrew Fish >>> >>> Cc: Ard Biesheuvel >>> Cc: Bob Feng >>> Cc: Laszlo Ersek >>> Cc: Liming Gao >>> Cc: Michael D Kinney >>> >>> Leif Lindholm (3): >>> BaseTools: add handling for 'S:' flag to GetMaintainer.py >>> Maintainers.txt: mark EmbeddedPkg MmcDxe as Obsolete >>> Maintainers.txt: mark EmbeddedPkg hw drivers as bsolete >>> >> >> Acked-by: Ard Biesheuvel >> >> I am mostly concerned about the use of MmcDxe in new platforms. The other >> bits I'm not too worried about, and I think it would be fine to move those >> into Platform/ARM/VExpressPkg in edk2-platforms, instead of hoping that >> someone will turn up and turn them into driver model drivers. > > We could, although I would prefer not adding code to edk2-platforms > that would not be accepted was it submitted as a new contribution. > The SATA controller, I would ideally re-review and merge properly. > > If we do include the other drivers in platform-specific directories, I > want them to come with ... strongly worded readmes. > Right. Should we have some format for that? A way to log shortcomings along with the code? >> One thing I'd like to do in the short term is renaming >> gEfiMmcHostProtocolGuid, given that it violates the naming rules, and move >> the PL180 driver to edk2-platforms. > > I did think about moving PL180 as well. I'm not opposed to moving > it. I don't think it's widely used. > >> Any thoughts about DwEmmcDxe? Only HiKey uses that at the moment, >> given that socfpga apparently switched to the generic version. > > Well, if nothing else it might be a useful scream test. Same comment > on strongly worded readme. > OK