MIME-Version: 1.0
References: <20230103141409.772298-1-apatel@ventanamicro.com>
 <20230103141409.772298-2-apatel@ventanamicro.com> <Y7YGp/7ufyRPhkwg@spud>
 <CAAhSdy2YKJfuxhBmsx9v-OMyxKQjys+J-z_ZqoPJF7q=YrE4Zw@mail.gmail.com> <Y8cIG6gKSlkTh5AF@spud>
In-Reply-To: <Y8cIG6gKSlkTh5AF@spud>
From:   Anup Patel <apatel@ventanamicro.com>
Date:   Fri, 27 Jan 2023 17:28:57 +0530
Message-ID: <CAK9=C2VzJvpQLPedc+ruUnw8xDDDaC6_Vmj6qg1nXv+iqU-AfQ@mail.gmail.com>
Subject: Re: [PATCH v2 1/9] RISC-V: Add AIA related CSR defines
To:     Conor Dooley <conor@kernel.org>
Cc:     Anup Patel <anup@brainfault.org>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Marc Zyngier <maz@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Atish Patra <atishp@atishpatra.org>,
        Alistair Francis <Alistair.Francis@wdc.com>,
        linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
        devicetree@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Jan 18, 2023 at 2:12 AM Conor Dooley <conor@kernel.org> wrote:
>
> Hey Anup,
>
> I thought I had already replied here but clearly not, sorry!
>
> On Mon, Jan 09, 2023 at 10:39:08AM +0530, Anup Patel wrote:
> > On Thu, Jan 5, 2023 at 4:37 AM Conor Dooley <conor@kernel.org> wrote:
> > > On Tue, Jan 03, 2023 at 07:44:01PM +0530, Anup Patel wrote:
>
> > > > +/* AIA CSR bits */
> > > > +#define TOPI_IID_SHIFT               16
> > > > +#define TOPI_IID_MASK                0xfff
>
> While I think of it, it'd be worth noting that these are generic across
> all of topi, mtopi etc. Initially I thought that this mask was wrong as
> the topi section says:
>         bits 25:16 Interrupt identity (source number)
>         bits 7:0 Interrupt priority

These defines are for the AIA CSRs and not AIA APLIC IDC registers.

As per the latest frozen spec, the mtopi/stopi/vstopi has following bits:
    bits: 27:16 IID
    bits: 7:0 IPRIO

>
> > > > +#define TOPI_IPRIO_MASK              0xff
> > > > +#define TOPI_IPRIO_BITS              8
> > > > +
> > > > +#define TOPEI_ID_SHIFT               16
> > > > +#define TOPEI_ID_MASK                0x7ff
> > > > +#define TOPEI_PRIO_MASK              0x7ff
> > > > +
> > > > +#define ISELECT_IPRIO0               0x30
> > > > +#define ISELECT_IPRIO15              0x3f
> > > > +#define ISELECT_MASK         0x1ff
> > > > +
> > > > +#define HVICTL_VTI           0x40000000
> > > > +#define HVICTL_IID           0x0fff0000
> > > > +#define HVICTL_IID_SHIFT     16
> > > > +#define HVICTL_IPRIOM                0x00000100
> > > > +#define HVICTL_IPRIO         0x000000ff
> > >
> > > Why not name these as masks, like you did for the other masks?
> > > Also, the mask/shift defines appear inconsistent. TOPI_IID_MASK is
> > > intended to be used post-shift AFAICT, but HVICTL_IID_SHIFT is intended
> > > to be used *pre*-shift.
> > > Some consistency in naming and function would be great.
> >
> > The following convention is being followed in asm/csr.h for defining
> > MASK of any XYZ field in ABC CSR:
> > 1. ABC_XYZ : This name is used for MASK which is intended
> >    to be used before SHIFT
> > 2. ABC_XYZ_MASK: This name is used for MASK which is
> >    intended to be used after SHIFT
>
> Which makes sense in theory.
>
> > The existing defines for [M|S]STATUS, HSTATUS, SATP, and xENVCFG
> > follows the above convention. The only outlier is HGATPx_VMID_MASK
> > define which I will fix in my next KVM RISC-V series.
>
> Yup, it is liable to end up like that.
>
> > I don't see how any of the AIA CSR defines are violating the above
> > convention.
>
> What I was advocating for was picking one style and sticking to it.
> These copy-paste from docs things are tedious and error prone to review,
> and I don't think having multiple styles is helpful.

On the other hand, I think we should let developers choose a style
which is better suited for a particular register field instead enforcing
it here. The best we can do is follow a naming convention for defines.

>
> Tedious as it was, I did check all the numbers though, so in that
> respect:
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

BTW, this patch is shared with KVM AIA CSR series so most likely
I will take this patch through that series.

Regards,
Anup