linux-kernel - Re: [PATCH] irqchip/sifive-plic: default to enabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <86y1s9nzja.wl-maz@kernel.org>
Date:   Thu, 17 Nov 2022 19:36:57 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Conor Dooley <conor@...nel.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
        Conor Dooley <conor.dooley@...rochip.com>
Subject: Re: [PATCH] irqchip/sifive-plic: default to enabled

On Thu, 17 Nov 2022 18:59:43 +0000,
Conor Dooley <conor@...nel.org> wrote:
> 
> From: Conor Dooley <conor.dooley@...rochip.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@...rochip.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.