From: Marc Zyngier <maz@kernel.org>
To: Conor Dooley <conor@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
Conor Dooley <conor.dooley@microchip.com>
Subject: Re: [PATCH] irqchip/sifive-plic: default to enabled
Date: Thu, 17 Nov 2022 19:36:57 +0000 [thread overview]
Message-ID: <86y1s9nzja.wl-maz@kernel.org> (raw)
In-Reply-To: <20221117185942.3896559-1-conor@kernel.org>
On Thu, 17 Nov 2022 18:59:43 +0000,
Conor Dooley <conor@kernel.org> wrote:
>
> From: Conor Dooley <conor.dooley@microchip.com>
>
> The SiFive PLIC driver is used by all current implementations, including
> those that do not have a SiFive PLIC. Default the driver to enabled,
> with the intention of later removing the current "every SOC selects
> this" situation in Kconfig.socs at the moment.
>
> The speculative "potential others" in the description no longer makes
> any sense, as the driver is always used. Update the Kconfig symbol's
> description to reflect the driver's ubiquitous state.
>
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> Hey Marc,
>
> I recall some discussion when this driver was extended to other PLICs a
> few months ago:
> https://lore.kernel.org/linux-riscv/20511a05f39408c8ffbcc98923c4abd2@kernel.org/
>
> Perhaps I got the wrong impression, but it seemed to me that you intend
> for future implementations to reuse this driver where possible?
Well, within reasons. People seem to have some very liberal
interpretations of the architecture spec...
>
> I'd like to think, and surely will be proven wrong, that ~all future
> plic implementations should be similar enough to fit that bill.
> It's kinda on this basis that I figure switching this thing to default y
> should be okay. It's already only buildable on RISC-V & every
> implementation uses it, so no difference there.
If you expect this to be present at all times, why isn't this selected
by the architecture Kconfig instead? I always find it pretty odd to
have something that is 'default y' and yet constrained by a 'depend
MYARCH'. A 'select PLIC' would make a lot more sense.
And then you can stop making this user selectable.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2022-11-17 19:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 18:59 [PATCH] irqchip/sifive-plic: default to enabled Conor Dooley
2022-11-17 19:36 ` Marc Zyngier [this message]
2022-11-17 19:57 ` Conor Dooley
2022-11-17 20:26 ` 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=86y1s9nzja.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=aou@eecs.berkeley.edu \
--cc=conor.dooley@microchip.com \
--cc=conor@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=tglx@linutronix.de \
/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