linux-kernel - Re: [PATCH 1/2] ACPI/AEST: Initial AEST driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YaU6eyGM+bX/bEhG@fedora>
Date:   Mon, 29 Nov 2021 12:39:23 -0800
From:   Darren Hart <darren@...amperecomputing.com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Tyler Baicar <baicar@...amperecomputing.com>,
        patches@...erecomputing.com, abdulhamid@...amperecomputing.com,
        catalin.marinas@....com, will@...nel.org, james.morse@....com,
        alexandru.elisei@....com, suzuki.poulose@....com,
        lorenzo.pieralisi@....com, guohanjun@...wei.com,
        sudeep.holla@....com, rafael@...nel.org, lenb@...nel.org,
        tony.luck@...el.com, bp@...en8.de, mark.rutland@....com,
        anshuman.khandual@....com, vincenzo.frascino@....com,
        tabba@...gle.com, marcan@...can.st, keescook@...omium.org,
        jthierry@...hat.com, masahiroy@...nel.org, samitolvanen@...gle.com,
        john.garry@...wei.com, daniel.lezcano@...aro.org,
        gor@...ux.ibm.com, zhangshaokun@...ilicon.com,
        tmricht@...ux.ibm.com, dchinner@...hat.com, tglx@...utronix.de,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        kvmarm@...ts.cs.columbia.edu, linux-acpi@...r.kernel.org,
        linux-edac@...r.kernel.org, ishii.shuuichir@...itsu.com,
        Vineeth.Pillai@...rosoft.com
Subject: Re: [PATCH 1/2] ACPI/AEST: Initial AEST driver

On Wed, Nov 24, 2021 at 06:09:14PM +0000, Marc Zyngier wrote:
> On Wed, 24 Nov 2021 17:07:07 +0000,
> Tyler Baicar <baicar@...amperecomputing.com> wrote:
> > 
> > Add support for parsing the ARM Error Source Table and basic handling of
> > errors reported through both memory mapped and system register interfaces.
> > 
> > Assume system register interfaces are only registered with private
> > peripheral interrupts (PPIs); otherwise there is no guarantee the
> > core handling the error is the core which took the error and has the
> > syndrome info in its system registers.
> > 
> > Add logging for all detected errors and trigger a kernel panic if there is
> > any uncorrected error present.
> > 
> > Signed-off-by: Tyler Baicar <baicar@...amperecomputing.com>
> > ---
> >  MAINTAINERS                     |   1 +
> >  arch/arm64/include/asm/ras.h    |  52 ++++
> >  arch/arm64/include/asm/sysreg.h |   2 +
> >  arch/arm64/kernel/Makefile      |   1 +
> >  arch/arm64/kernel/ras.c         | 125 +++++++++
> >  arch/arm64/kvm/sys_regs.c       |   2 +
> >  drivers/acpi/arm64/Kconfig      |   3 +
> >  drivers/acpi/arm64/Makefile     |   1 +
> >  drivers/acpi/arm64/aest.c       | 450 ++++++++++++++++++++++++++++++++
> >  include/linux/acpi_aest.h       |  50 ++++
> >  include/linux/cpuhotplug.h      |   1 +
> >  11 files changed, 688 insertions(+)
> >  create mode 100644 arch/arm64/include/asm/ras.h
> >  create mode 100644 arch/arm64/kernel/ras.c
> >  create mode 100644 drivers/acpi/arm64/aest.c
> >  create mode 100644 include/linux/acpi_aest.h
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 5250298d2817..aa0483726606 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -382,6 +382,7 @@ ACPI FOR ARM64 (ACPI/arm64)
> >  M:	Lorenzo Pieralisi <lorenzo.pieralisi@....com>
> >  M:	Hanjun Guo <guohanjun@...wei.com>
> >  M:	Sudeep Holla <sudeep.holla@....com>
> > +R:	Tyler Baicar <baicar@...amperecomputing.com>
> >  L:	linux-acpi@...r.kernel.org
> >  L:	linux-arm-kernel@...ts.infradead.org (moderated for non-subscribers)
> >  S:	Maintained
> 
> Isn't this a bit premature? This isn't even mentioned in the commit
> message, only in passing in the cover letter.
> 

Hi Marc,

This was something I encouraged Tyler to add during internal review,
both in response to the checkpatch.pl warning about adding new drivers
as well as our interest in reviewing any future changes to the aest
driver. Since refactoring is common, this level made sense to me - but
would it be preferable to add a new entry for just the new driver Tyler
added?

Thanks,

-- 
Darren Hart
Ampere Computing / OS and Kernel