linux-kernel - Re: Re: [PATCH] arm64/Kconfig: introduce GENERIC_ISA

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: <20241029132042.GA4416@willie-the-truck>
Date: Tue, 29 Oct 2024 13:20:43 +0000
From: Will Deacon <will@...nel.org>
To: huanglei <huanglei814@....com>
Cc: catalin.marinas@....com, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, huanglei <huanglei@...inos.cn>,
	arnd@...db.de
Subject: Re: Re: [PATCH] arm64/Kconfig: introduce GENERIC_ISA_DMA

On Tue, Oct 29, 2024 at 09:41:08AM +0800, huanglei wrote:
>     Even if MAX_SMA_CANNELS is not defined, as long as GENETIC-SIA_DMA is
>     enabled， request_rma/free_rma  function will also be exported, and
>     other modules using these two interfaces will not encounter link
>     errors.
> 
>     I don't know why others haven't noticed, but I discovered it when
>     debugging pcie parallel port drivers.  And the arm/Kconfig  has been
>     around for a long time.

Please try to avoid top-posting in replies, as it makes the conversation
very hard to follow.

> At 2024-10-28 22:05:45, "Will Deacon" <will@...nel.org> wrote:
> >On Fri, Oct 25, 2024 at 09:16:41AM +0800, huanglei814 wrote:
> >> From: huanglei <huanglei@...inos.cn>
> >> 
> >> Enable GENERIC_ISA_DMA feature on arm64 platform,
> >> thus, request_dma and free_dma interface can be export.
> >> and driver modules can use the this interfaces on arm64
> >> platform.
> >> 
> >> Currently, many pcie parallel port drivers still use these
> >> interfaces when ported to arm64 platform.
> >
> >Why has it taken so long for anybody to notice?
> >
> >> Signed-off-by: huanglei <huanglei@...inos.cn>
> >> ---
> >>  arch/arm64/Kconfig | 3 +++
> >>  1 file changed, 3 insertions(+)
> >> 
> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> >> index fd9df6dcc593..986eb251f68f 100644
> >> --- a/arch/arm64/Kconfig
> >> +++ b/arch/arm64/Kconfig
> >> @@ -367,6 +367,9 @@ config GENERIC_CSUM
> >>  config GENERIC_CALIBRATE_DELAY
> >>  	def_bool y
> >>  
> >> +config GENERIC_ISA_DMA
> >> +	def_bool y
> >> +
> >
> > Does this actually do anything without MAX_DMA_CHANNELS defined?
>
>     Even if MAX_SMA_CANNELS is not defined, as long as GENETIC-SIA_DMA is
>     enabled， request_rma/free_rma  function will also be exported, and
>     other modules using these two interfaces will not encounter link
>     errors.

Do the drivers do anything useful after they've linked? Can you please
provide some in-tree examples of drivers that can be used on arm64 only
once GENERIC_ISA_DMA is selected? If they just need some stubs for
request_dma() and free_dma(), then it feels to me like that should be
the default implementation, rather than having to select something to
get them.

Will