[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.9999.1912181030090.14542@viisi.sifive.com>
Date: Wed, 18 Dec 2019 10:35:59 -0800 (PST)
From: Paul Walmsley <paul.walmsley@...ive.com>
To: Olof Johansson <olof@...om.net>
cc: Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Thomas Gleixner <tglx@...utronix.de>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
jason@...edaemon.net, maz@...nel.org, damien.lemoal@....com,
Christoph Hellwig <hch@....de>
Subject: Re: [PATCH] riscv: change CSR M/S defines to use "X" for prefix
On Wed, 18 Dec 2019, Olof Johansson wrote:
> Commit a4c3733d32a7 ("riscv: abstract out CSR names for supervisor vs
> machine mode") introduced new non-S/M-specific defines for some of the
> CSRs and fields that differ for when you run the kernel in machine or
> supervisor mode.
>
> One of those was "IRQ_TIMER" (instead of IRQ_S_TIMER/IRQ_M_MTIMER),
> which was generic enough to cause conflicts with other defines in
> drivers. Since it was in csr.h, it ended up getting pulled in through
> fairly generic include files, etc.
>
> I looked at just renaming those, but for consistency I chose to rename all
> M/S symbols to using 'X' instead of 'S'/'M' in the identifiers instead,
> which gives them all less generic names.
This is what Christoph did originally. I asked him to rename them to the
generic versions to align with how we discuss these internally:
https://lore.kernel.org/linux-riscv/alpine.DEB.2.21.9999.1910181647110.21875@viisi.sifive.com/
I'd propose that we just start by prefixing the IRQ_TIMER macros with
something like "RV_". By prefixing the macros with a namespace
identifier, that seems to solve the namespace problem more directly than
sprinkling Xs around. Then if it looks like there are other symbols that
start conflicting, we can do the same in a larger patch for the other
CSRs.
Of course we could also do the same to all CSRs up front. Do you have a
sense of what the current conflict situation is like with those? The only
one I'm aware of is with Mobiveil and predated this patch; it was fixed in
the last merge window as far as I know.
- Paul
Powered by blists - more mailing lists