BaseTools/Scripts/GetMaintainer.py | 4 ++++ Maintainers.txt | 17 +++++++++++++++++ 2 files changed, 21 insertions(+)
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 <afish@apple.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> 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 BaseTools/Scripts/GetMaintainer.py | 4 ++++ Maintainers.txt | 17 +++++++++++++++++ 2 files changed, 21 insertions(+) -- 2.20.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#58316): https://edk2.groups.io/g/devel/message/58316 Mute This Topic: https://groups.io/mt/73356717/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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 <afish@apple.com> > > Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> > Cc: Bob Feng <bob.c.feng@intel.com> > Cc: Laszlo Ersek <lersek@redhat.com> > Cc: Liming Gao <liming.gao@intel.com> > Cc: Michael D Kinney <michael.d.kinney@intel.com> > > 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 <ard.biesheuvel@arm.com> 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. 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. Any thoughts about DwEmmcDxe? Only HiKey uses that at the moment, given that socfpga apparently switched to the generic version. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#58320): https://edk2.groups.io/g/devel/message/58320 Mute This Topic: https://groups.io/mt/73356717/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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 <afish@apple.com>
> >
> > Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
> > Cc: Bob Feng <bob.c.feng@intel.com>
> > Cc: Laszlo Ersek <lersek@redhat.com>
> > Cc: Liming Gao <liming.gao@intel.com>
> > Cc: Michael D Kinney <michael.d.kinney@intel.com>
> >
> > 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 <ard.biesheuvel@arm.com>
>
> 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.
> 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.
/
Leif
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#58327): https://edk2.groups.io/g/devel/message/58327
Mute This Topic: https://groups.io/mt/73356717/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
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 <afish@apple.com> >>> >>> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> >>> Cc: Bob Feng <bob.c.feng@intel.com> >>> Cc: Laszlo Ersek <lersek@redhat.com> >>> Cc: Liming Gao <liming.gao@intel.com> >>> Cc: Michael D Kinney <michael.d.kinney@intel.com> >>> >>> 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 <ard.biesheuvel@arm.com> >> >> 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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#58331): https://edk2.groups.io/g/devel/message/58331 Mute This Topic: https://groups.io/mt/73356717/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Wed, Apr 29, 2020 at 22:04:08 +0200, Ard Biesheuvel wrote:
> > > 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?
Thinking a bit more on this, maybe what we should do is add a template
to each file's top comment block. Draft proposal:
*
* WARNING:
* This driver fails to follow the UEFI driver model without a good
* reason, and only remains in the tree because it is still used by
* a small number of platforms. It will removed when no longer used.
* New platforms should not use it, and no one should use this as
* reference code for developing new drivers.
*
/
Leif
> > > 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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#58340): https://edk2.groups.io/g/devel/message/58340
Mute This Topic: https://groups.io/mt/73356717/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
On 4/29/20 11:45 PM, Leif Lindholm wrote: > On Wed, Apr 29, 2020 at 22:04:08 +0200, Ard Biesheuvel wrote: >>>> 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? > > Thinking a bit more on this, maybe what we should do is add a template > to each file's top comment block. Draft proposal: > > * > * WARNING: > * This driver fails to follow the UEFI driver model without a good > * reason, and only remains in the tree because it is still used by > * a small number of platforms. It will removed when no longer used. > * New platforms should not use it, and no one should use this as > * reference code for developing new drivers. > * > Works for me -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#58341): https://edk2.groups.io/g/devel/message/58341 Mute This Topic: https://groups.io/mt/73356717/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 04/29/20 23:47, Ard Biesheuvel wrote: > On 4/29/20 11:45 PM, Leif Lindholm wrote: >> On Wed, Apr 29, 2020 at 22:04:08 +0200, Ard Biesheuvel wrote: >>>>> 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? >> >> Thinking a bit more on this, maybe what we should do is add a template >> to each file's top comment block. Draft proposal: >> >> * >> * WARNING: >> * This driver fails to follow the UEFI driver model without a good >> * reason, and only remains in the tree because it is still used by >> * a small number of platforms. It will removed when no longer used. >> * New platforms should not use it, and no one should use this as >> * reference code for developing new drivers. >> * >> > > Works for me > You could also (or alternatively) add a separate file "DEPRECATED.txt" to the directory -- sometimes people don't read file-top comments, before duplicating or editing code. Something that's visible with a simple "ls -l" might stand out more. Just a thought, I'm neutral on this. Thanks Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#58430): https://edk2.groups.io/g/devel/message/58430 Mute This Topic: https://groups.io/mt/73356717/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Thu, Apr 30, 2020 at 13:17:26 +0200, Laszlo Ersek wrote:
> On 04/29/20 23:47, Ard Biesheuvel wrote:
> > On 4/29/20 11:45 PM, Leif Lindholm wrote:
> >> On Wed, Apr 29, 2020 at 22:04:08 +0200, Ard Biesheuvel wrote:
> >>>>> 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?
> >>
> >> Thinking a bit more on this, maybe what we should do is add a template
> >> to each file's top comment block. Draft proposal:
> >>
> >> *
> >> * WARNING:
> >> * This driver fails to follow the UEFI driver model without a good
> >> * reason, and only remains in the tree because it is still used by
> >> * a small number of platforms. It will removed when no longer used.
> >> * New platforms should not use it, and no one should use this as
> >> * reference code for developing new drivers.
> >> *
> >>
> >
> > Works for me
> >
>
> You could also (or alternatively) add a separate file "DEPRECATED.txt"
> to the directory -- sometimes people don't read file-top comments,
> before duplicating or editing code. Something that's visible with a
> simple "ls -l" might stand out more.
I think what's more visible depends on the use-case.
A comment at the top of the file is at least very visible to the
reviewer if someone submits Yet Another Clone of an inadvisible
driver.
A DEPRECATED.txt might be a good ide for something like the
EmbeddedPkg MmcDxe which we wan't people to stop *using* as opposed to
copying.
Ard?
Thanks!
/
Leif
>
> Just a thought, I'm neutral on this.
>
> Thanks
> Laszlo
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#58439): https://edk2.groups.io/g/devel/message/58439
Mute This Topic: https://groups.io/mt/73356717/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
On 4/30/20 3:28 PM, Leif Lindholm wrote: > On Thu, Apr 30, 2020 at 13:17:26 +0200, Laszlo Ersek wrote: >> On 04/29/20 23:47, Ard Biesheuvel wrote: >>> On 4/29/20 11:45 PM, Leif Lindholm wrote: >>>> On Wed, Apr 29, 2020 at 22:04:08 +0200, Ard Biesheuvel wrote: >>>>>>> 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? >>>> >>>> Thinking a bit more on this, maybe what we should do is add a template >>>> to each file's top comment block. Draft proposal: >>>> >>>> * >>>> * WARNING: >>>> * This driver fails to follow the UEFI driver model without a good >>>> * reason, and only remains in the tree because it is still used by >>>> * a small number of platforms. It will removed when no longer used. >>>> * New platforms should not use it, and no one should use this as >>>> * reference code for developing new drivers. >>>> * >>>> >>> >>> Works for me >>> >> >> You could also (or alternatively) add a separate file "DEPRECATED.txt" >> to the directory -- sometimes people don't read file-top comments, >> before duplicating or editing code. Something that's visible with a >> simple "ls -l" might stand out more. > > I think what's more visible depends on the use-case. > A comment at the top of the file is at least very visible to the > reviewer if someone submits Yet Another Clone of an inadvisible > driver. > > A DEPRECATED.txt might be a good ide for something like the > EmbeddedPkg MmcDxe which we wan't people to stop *using* as opposed to > copying. > > Ard? > Agreed. People tend to look at the file header when they add their copyright, so putting it in each file seems like a sensible way to do this. As for using the likes of MmcDxe: perhaps we should add a i-am-deprecated PCD that defaults to a value that prevents it from working? -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#58441): https://edk2.groups.io/g/devel/message/58441 Mute This Topic: https://groups.io/mt/73356717/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Thu, Apr 30, 2020 at 15:43:22 +0200, Ard Biesheuvel wrote:
> > > > > Thinking a bit more on this, maybe what we should do is add a template
> > > > > to each file's top comment block. Draft proposal:
> > > > >
> > > > > *
> > > > > * WARNING:
> > > > > * This driver fails to follow the UEFI driver model without a good
> > > > > * reason, and only remains in the tree because it is still used by
> > > > > * a small number of platforms. It will removed when no longer used.
> > > > > * New platforms should not use it, and no one should use this as
> > > > > * reference code for developing new drivers.
> > > > > *
> > > > >
> > > >
> > > > Works for me
> > > >
> > >
> > > You could also (or alternatively) add a separate file "DEPRECATED.txt"
> > > to the directory -- sometimes people don't read file-top comments,
> > > before duplicating or editing code. Something that's visible with a
> > > simple "ls -l" might stand out more.
> >
> > I think what's more visible depends on the use-case.
> > A comment at the top of the file is at least very visible to the
> > reviewer if someone submits Yet Another Clone of an inadvisible
> > driver.
> >
> > A DEPRECATED.txt might be a good ide for something like the
> > EmbeddedPkg MmcDxe which we wan't people to stop *using* as opposed to
> > copying.
> >
> > Ard?
> >
>
> Agreed. People tend to look at the file header when they add their
> copyright, so putting it in each file seems like a sensible way to do this.
>
> As for using the likes of MmcDxe: perhaps we should add a i-am-deprecated
> PCD that defaults to a value that prevents it from working?
Yes, that's even better!
/
Leif
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#58445): https://edk2.groups.io/g/devel/message/58445
Mute This Topic: https://groups.io/mt/73356717/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
Btw, the Raspberry Pi support has its own variant of MmcDxe and SD host drivers... the history behind that is that's the way it was in the original MSFT port circa 2016. When I had rebased that code to 2018 edk2 (still before Pete's work to upstream it here), the edk2 variant had significantly diverged from the MSFT changes, so the MSFT one was taken as is (and further evolved to fix issues around high-speed support). It's still a goal to move away from all of that towards something generic. The Pi has two (sometimes 3) controllers - some are kinda-SDHCI (maybe possible with the Mde stack, if quirked via _SD_MMC_OVERRIDE_PROTOCOL), while the other is completely non-standard. Mde doesn't have a non-SDHCI stack. That remains a gap... A On Wed, Apr 29, 2020 at 11:36 AM Leif Lindholm <leif@nuviainc.com> 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 <afish@apple.com> > > Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> > Cc: Bob Feng <bob.c.feng@intel.com> > Cc: Laszlo Ersek <lersek@redhat.com> > Cc: Liming Gao <liming.gao@intel.com> > Cc: Michael D Kinney <michael.d.kinney@intel.com> > > 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 > > BaseTools/Scripts/GetMaintainer.py | 4 ++++ > Maintainers.txt | 17 +++++++++++++++++ > 2 files changed, 21 insertions(+) > > -- > 2.20.1 > > > > > -- A -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#58335): https://edk2.groups.io/g/devel/message/58335 Mute This Topic: https://groups.io/mt/73356717/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
© 2016 - 2024 Red Hat, Inc.