[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8634p6ka7j.wl-maz@kernel.org>
Date: Fri, 21 Jun 2024 08:48:32 +0100
From: Marc Zyngier <maz@...nel.org>
To: "Liao, Chang" <liaochang1@...wei.com>
Cc: Mark Rutland <mark.rutland@....com>,
<linux-arm-kernel@...ts.infradead.org>,
<alexandru.elisei@....com>,
<catalin.marinas@....com>,
<linux-kernel@...r.kernel.org>,
<tglx@...utronix.de>,
<will@...nel.org>
Subject: Re: [PATCH v2 5/5] arm64: irqchip/gic-v3: Select priorities at boot time
On Fri, 21 Jun 2024 07:23:54 +0100,
"Liao, Chang" <liaochang1@...wei.com> wrote:
>
>
>
> 在 2024/6/17 19:18, Mark Rutland 写道:
> > cpus_have_group0 = gic_has_group0();
>
> > +#define __gicv3_prio_to_ns(p) (0xff & ((p) << 1))
> > +#define __gicv3_ns_to_prio(ns) (0x80 | ((ns) >> 1))
>
> What about refactoring the gic_has_group0() using the mapping macros
> between PMR priority and GIC priority like this:
>
> ---------------%<-----------------
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -882,6 +882,7 @@ static bool gic_has_group0(void)
> {
> u32 val;
> u32 old_pmr;
> + u32 prio = BIT(8 - gic_get_pribits());
>
> old_pmr = gic_read_pmr();
>
> @@ -896,12 +897,12 @@ static bool gic_has_group0(void)
> * becomes 0x80. Reading it back returns 0, indicating that
> * we're don't have access to Group0.
> */
> - gic_write_pmr(BIT(8 - gic_get_pribits()));
> + gic_write_pmr(prio);
> val = gic_read_pmr();
>
> gic_write_pmr(old_pmr);
>
> - return val != 0;
> + return val != (__gicv3_prio_to_ns(__gicv3_ns_to_prio(prio)));
> }
> --------------->%-----------------
No, that's terrible, and makes it simply impossible to understand what
is happening without looking at 3 layers of indirection.
Read the comment, and realise that the code implements exactly that.
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists