From: Sudeep Holla <sudeep.holla@arm.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Cristian Marussi <cristian.marussi@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Jassi Brar <jassisinghbrar@gmail.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mailbox: ARM_MHU_V3 should depend on ARM64
Date: Mon, 3 Jun 2024 14:39:20 +0100 [thread overview]
Message-ID: <Zl3HiBX8ih6Sret6@bogus> (raw)
In-Reply-To: <CAMuHMdUyW_RxfUaxnyWVzPsdXQWqCQbgZ+avHskinXkrSFqhtw@mail.gmail.com>
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@arm.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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-06-03 13:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-29 7:30 [PATCH] mailbox: ARM_MHU_V3 should depend on ARM64 Geert Uytterhoeven
2024-05-29 10:13 ` Cristian Marussi
2024-05-29 11:36 ` Geert Uytterhoeven
2024-05-29 11:48 ` Cristian Marussi
2024-06-03 13:39 ` Sudeep Holla [this message]
2024-06-03 17:52 ` Geert Uytterhoeven
2024-06-04 7:07 ` Sudeep Holla
2024-06-04 9:46 ` Cristian Marussi
2024-06-04 9:57 ` Geert Uytterhoeven
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=Zl3HiBX8ih6Sret6@bogus \
--to=sudeep.holla@arm.com \
--cc=cristian.marussi@arm.com \
--cc=geert@linux-m68k.org \
--cc=jassisinghbrar@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).