linux-kernel - Re: [PATCH] mailbox: ARM_MHU

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]

Date: Mon, 3 Jun 2024 14:39:20 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Cristian Marussi <cristian.marussi@....com>,
	Sudeep Holla <sudeep.holla@....com>,
	Jassi Brar <jassisinghbrar@...il.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mailbox: ARM_MHU_V3 should depend on ARM64

On Wed, May 29, 2024 at 01:36:42PM +0200, Geert Uytterhoeven wrote:
> Hi Cristian,
>
> On Wed, May 29, 2024 at 12:13 PM Cristian Marussi
> <cristian.marussi@....com> wrote:
> > On Wed, May 29, 2024 at 09:30:45AM +0200, Geert Uytterhoeven wrote:
> > > The ARM MHUv3 controller is only present on ARM64 SoCs.  Hence add a
> > > dependency on ARM64, to prevent asking the user about this driver when
> > > configuring a kernel for a different architecture than ARM64.
> >
> > the ARM64 dependency was dropped on purpose after a few iterations of
> > this series since, despite this being an ARM IP, it has really no technical
> > dependency on ARM arch, not even the usual one on ARM AMBA bus, being this a
> > platform driver, so it seemed an uneeded artificial restriction to impose...
> > ...having said that, surely my live testing were performed only on arm64 models
> > as of now.
>
> For that, we have COMPILE_TEST=y.
>
> > So, I am not saying that I am against this proposed fix but what is the
> > issue that is trying to solve, have you seen any compilation error ? or
> > is it just to avoid the user-prompting ?
>
> I did not see a compile error (I didn't enable it on any non-ARM
> platform).
>
> But it is rather futile to ask the user about (thousands of) drivers
> for hardware that cannot possibly be present on the system he is
> configuring a kernel for.

I am fine with this fix but I have seen quite opposite argument. That is
not to add dependency if it is not strictly required.

Also since you state that the fix is to avoid users of other archs being
posed with the question that they may get annoyed or can't answer, I
wonder if the right approach is to make this driver default "n" instead.

I don't know what is the right or preferred approach here. I am fine
either way.

--
Regards,
Sudeep