Re: [edk2-devel] [PATCH v2 1/2] ArmPkg: implement EFI_MP_SERVICES_PROTOCOL based on PSCI calls

["Ard Biesheuvel" <ardb@kernel.org>]

On Wed, 7 Sept 2022 at 17:11, Michael Kubacki
<mikuback@linux.microsoft.com> wrote:
>
> Maintainers have two options for Spell Check as described in the Spell
> Check CI Plugin readme -
> https://github.com/tianocore/edk2/tree/master/.pytool/Plugin/SpellCheck
>
> 1. Set AuditOnly to "true" - Disables all spelling errors in the package
> from the failing the build entirely.
>
> 2. Extend the dictionary - Add specific words that are allowed. Many
> packages already do this.
>
> 3. IgnoreStandardPaths - Do not check files by path pattern.
>
> As a maintainer, you can either opt out of Spell Check from the failing
> the build entirely by enabling AuditOnly or choose a different level of
> granularity by simply updating your package CI YAML file.
>

Thanks for the explanation - patch coming up.


> On 9/7/2022 3:35 AM, Ard Biesheuvel wrote:
> > On Wed, 7 Sept 2022 at 06:35, Rebecca Cran <quic_rcran@quicinc.com> wrote:
> >>
> >> Also, CI is failing in the SpellCheck test because of the
> >> "-mstrict-align" in
> >> ArmPsciMpServicesDxe.inf.
> >>
> >> /home/vsts/work/1/s/ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.inf:55:25
> >> - Unknown word (mstrict)
> >>
> >> Should I add "mstrict" to pytool/Plugin/SpellCheck/cspell.base.yaml ?
> >>
> >
> > This is getting ridiculous.
> >
> > I'm all for code quality and automation, but if t we cannot use
> > compiler command line options that it supported since the dawn of time
> > without bending over backwards to placate the CI machine, we are
> > throwing out the baby with the bath water.
> >
> > At the very least, maintainers should be able to override the CI - I
> > spent 2 hours yesterday preparing a submission that ultimately got
> > rejected because MPIDR is not in the permitted word list (suggestion:
> > use 'mpidr')
> >
> > In the Linux kernel, we have patch check and sparse (which is somewhat
> > similar to ECC in a sense). Some maintainers run it, some don't, but
> > in the end, the discretion lies with the person not the machine. This
> > is the only way that makes sense.
> >
> > As the co-maintainer of ArmPkg, ArmVirtPkg, ArmPlatformPkg, OvmfPkg
> > and EmbeddedPkg, I hereby request that the Ci restrictions are either
> > lifted entirely for these packages, or relaxed so that a PR can be
> > merged at my discretion, even if the CI thinks there are unresolved
> > issues.
> >
> >
> >
> >> On 9/6/22 22:25, Rebecca Cran wrote:
> >>> On 9/6/22 22:03, Rebecca Cran wrote:
> >>>> diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
> >>>> index 59fd8f295d4f..4716789402fc 100644
> >>>> --- a/ArmPkg/ArmPkg.dsc
> >>>> +++ b/ArmPkg/ArmPkg.dsc
> >>>> @@ -125,6 +125,7 @@ [Components.common]
> >>>>      ArmPkg/Drivers/CpuPei/CpuPei.inf
> >>>>      ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
> >>>>      ArmPkg/Drivers/ArmGic/ArmGicLib.inf
> >>>> +  ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.inf
> >>>>      ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
> >>>>      ArmPkg/Drivers/TimerDxe/TimerDxe.inf
> >>> This won't work, since there's no support for 32-bit ARM code.
> >>> I'll move it into the AARCH64 section.
> >>>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
> 
>
>