linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: "Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Russell King" <linux@arm.linux.org.uk>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Will Deacon" <will@kernel.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Jason Cooper" <jason@lakedaemon.net>,
	"Sumit Garg" <sumit.garg@linaro.org>,
	"Valentin Schneider" <Valentin.Schneider@arm.com>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"Gregory Clement" <gregory.clement@bootlin.com>,
	"Andrew Lunn" <andrew@lunn.ch>,
	"Android Kernel Team" <kernel-team@android.com>,
	stable <stable@vger.kernel.org>,
	"Magnus Damm" <damm+renesas@opensource.se>,
	"Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH v2 07/17] irqchip/gic: Atomically update affinity
Date: Sat, 11 Sep 2021 20:32:04 +0100	[thread overview]
Message-ID: <874kaqdi2z.wl-maz@kernel.org> (raw)
In-Reply-To: <CANqRtoTqV8sOpL=hdxeZ03tqr+5oeMcfwz+9ERqXv+hze_6Fsw@mail.gmail.com>

Hi Magnus,

On Sat, 11 Sep 2021 03:49:20 +0100,
Magnus Damm <magnus.damm@gmail.com> wrote:
> 
> Hi Geert, Mark, RMK, everyone,
> 
> Thanks for your efforts. Let me just chime in with a few details and a question.
> 
> On Fri, Sep 10, 2021 at 10:19 PM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Fri, Sep 10, 2021 at 12:23 PM Marc Zyngier <maz@kernel.org> wrote:
> > > On Thu, 09 Sep 2021 16:22:01 +0100,
> > > Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >     GIC: enabling workaround for broken byte access
> 
> Indeed, byte access is unsupported according to the EMEV2 documentation.
> 
> The EMEV2 documentation R19UH0036EJ0600 Chapter 7 Interrupt Control on
> page 97 says:
> "Interrupt registers can be accessed via the APB bus, in 32-bit units"
> "For details about register functions, see ARM Generic Interrupt
> Controller Architecture Specification Architecture version 1.0"
> The file  "R19UH0036EJ0600_1Chip.pdf" is the 6th edition version
> published in 2010 and is not marked as confidential.

This is as bad as it gets. Do you know if any other Renesas platform
is affected by the same issue?

> 
> From my basic research, "ARM Generic Interrupt Controller Architecture
> Specification Architecture version 1.0" is documented in ARM IHI 0048A
> from 2008 (Non-Confidential) which contains:
> "All GIC registers are 32-bit wide." and "All registers support 32-bit
> word access..."
> "In addition, the following registers support byte accesses:"
> "ICDIPR"

Renamed to GICD_IPRIORITYRn in IHI0048B.

> "ICDIPTR"

Renamed to GICD_ITARGETRn in IHI0048B.

See IHI0048B_b ("B.1 Alternative register names" and specifically
table B-1) for the translation table between GICv1 and GICv2 names.

> So the GICv1 documentation says byte access is partially supported
> however EMEV2 documentation says 32-bit access is required.

Which is definitely an integration bug. Both set of registers *must*
support byte accesses. This isn't optional and left to the
appreciation of the integrator. This breaks the programming model
badly, and prevents standard software from running unmodified.

One of the few things the GIC architecture got right is the absence of
locking requirements, as all the registers can be accessed
concurrently by multiple CPUs as long as they operate on distinct
interrupts. This is why the enable and pending registers have both set
and clear accessors, that the priority and target registers are byte
accessible, and that everything else happens in CPU-private registers
(the CPU interface).

This requirement has been there from day-1. Even the good old DIC (the
GIC's ancestor) that was included with the 11MP-Core says: "All
Interrupt Distributor Registers are byte accessible.", which is more
than actually necessary for the GIC. See DDI 0360F for details. And
yes, SW written for the GIC does work on the DIC.

> 
> > > +               .compatible     = "arm,pl390",
> > > +               .init           = gic_enable_rmw_access,
> > > +       },
> 
> May I ask about a clarification about the EMEV2 DTS and DT binding
> documentation in:
> arch/arm/boot/dts/emev2.dts
> Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
> 
> On EMEV2 the DT compatible string currently seems to be the rather
> generic "arm,pl390". In the DT binding documentation GICv1 is listed
> in an example as "arm,cortex-a9-gic". Is there any reason for not
> using the GICv1 compatible string (and 32-bit access) for EMEV2? Just
> curious.

GICv1 is an architecture specification. PL390 is an implementation of
GICv1. The so called "Cortex-A9 GIC" doesn't really exist. It is
simply the amalgamation of the CPU interface implemented by the A9
(with the prototype of the GICv2 virtualisation extensions) with a
distributor (usually a PL390, but not necessarily). All of them
require that the priority and target registers are byte accessible.

As for changing the compatibility string, I don't see the point. This
will break existing setups, and doesn't change the core of the
issue. As far as I can see, the EMEV2 DT is correct in the sense that
it describes the actual implementation of the GIC used.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2021-09-11 19:32 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24 19:57 [PATCH v2 00/17] arm/arm64: Turning IPIs into normal interrupts Marc Zyngier
2020-06-24 19:57 ` [PATCH v2 01/17] genirq: Add fasteoi IPI flow Marc Zyngier
2020-06-24 19:57 ` [PATCH v2 02/17] genirq: Allow interrupts to be excluded from /proc/interrupts Marc Zyngier
2020-06-24 19:57 ` [PATCH v2 03/17] arm64: Allow IPIs to be handled as normal interrupts Marc Zyngier
2020-06-25 18:25   ` Valentin Schneider
2020-07-10 19:58   ` Valentin Schneider
2020-06-24 19:57 ` [PATCH v2 04/17] ARM: " Marc Zyngier
2020-06-25 18:25   ` Valentin Schneider
2020-06-29  9:37     ` Marc Zyngier
2020-06-24 19:57 ` [PATCH v2 05/17] irqchip/gic-v3: Describe the SGI range Marc Zyngier
2020-06-24 19:58 ` [PATCH v2 06/17] irqchip/gic-v3: Configure SGIs as standard interrupts Marc Zyngier
2020-06-25 18:25   ` Valentin Schneider
2020-06-30 10:15     ` Marc Zyngier
2020-07-02 13:23       ` Valentin Schneider
2020-07-02 13:48         ` Marc Zyngier
2020-07-02 14:24           ` Valentin Schneider
2020-06-24 19:58 ` [PATCH v2 07/17] irqchip/gic: Atomically update affinity Marc Zyngier
2020-07-01 19:33   ` Sasha Levin
2020-07-10 14:02   ` Sasha Levin
2021-09-09 15:22   ` Geert Uytterhoeven
2021-09-09 15:37     ` Russell King (Oracle)
2021-09-10 10:22     ` Marc Zyngier
2021-09-10 13:19       ` Geert Uytterhoeven
2021-09-11  2:49         ` Magnus Damm
2021-09-11 19:32           ` Marc Zyngier [this message]
2021-09-12  5:40             ` Magnus Damm
2021-09-13  8:05               ` Geert Uytterhoeven
2021-09-15  3:28                 ` Magnus Damm
2021-09-22 13:53     ` [irqchip: irq/irqchip-fixes] irqchip/gic: Work around broken Renesas integration irqchip-bot for Marc Zyngier
2020-06-24 19:58 ` [PATCH v2 08/17] irqchip/gic: Refactor SMP configuration Marc Zyngier
2020-06-24 19:58 ` [PATCH v2 09/17] irqchip/gic: Configure SGIs as standard interrupts Marc Zyngier
2020-06-24 19:58 ` [PATCH v2 10/17] irqchip/gic-common: Don't enable SGIs by default Marc Zyngier
2020-06-24 19:58 ` [PATCH v2 11/17] irqchip/bcm2836: Configure mailbox interrupts as standard interrupts Marc Zyngier
2020-06-24 19:58 ` [PATCH v2 12/17] irqchip/hip04: Configure IPIs " Marc Zyngier
2020-06-24 19:58 ` [PATCH v2 13/17] irqchip/armada-370-xp: " Marc Zyngier
2020-06-24 19:58 ` [PATCH v2 14/17] arm64: Kill __smp_cross_call and co Marc Zyngier
2020-06-25 18:25   ` Valentin Schneider
2020-07-02 13:37     ` Marc Zyngier
2020-06-24 19:58 ` [PATCH v2 15/17] arm64: Remove custom IRQ stat accounting Marc Zyngier
2020-06-25 18:26   ` Valentin Schneider
2020-06-26 11:58     ` Marc Zyngier
2020-06-26 23:15       ` Valentin Schneider
2020-06-27 11:42         ` Marc Zyngier
2020-07-10 19:58   ` Valentin Schneider
2020-06-24 19:58 ` [PATCH v2 16/17] ARM: Kill __smp_cross_call and co Marc Zyngier
2020-06-24 19:58 ` [PATCH v2 17/17] ARM: Remove custom IRQ stat accounting Marc Zyngier
2020-06-25 18:24 ` [PATCH v2 00/17] arm/arm64: Turning IPIs into normal interrupts Valentin Schneider
2020-07-10 19:58   ` Valentin Schneider
2020-08-11 13:15 ` Sumit Garg
2020-08-11 13:58   ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874kaqdi2z.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=Valentin.Schneider@arm.com \
    --cc=andrew@lunn.ch \
    --cc=catalin.marinas@arm.com \
    --cc=damm+renesas@opensource.se \
    --cc=f.fainelli@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=gregory.clement@bootlin.com \
    --cc=jason@lakedaemon.net \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=magnus.damm@gmail.com \
    --cc=niklas.soderlund+renesas@ragnatech.se \
    --cc=stable@vger.kernel.org \
    --cc=sumit.garg@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).