[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <73d9824f-898a-48ea-b3a8-ea420e3be007@app.fastmail.com>
Date: Sat, 24 Feb 2024 12:24:01 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Maciej W. Rozycki" <macro@...am.me.uk>, "Sam Ravnborg" <sam@...nborg.org>
Cc: "Miquel Raynal" <miquel.raynal@...tlin.com>, sparclinux@...r.kernel.org,
linux-parport@...ts.infradead.org, "David S . Miller" <davem@...emloft.net>,
"Andreas Larsson" <andreas@...sler.com>,
"Randy Dunlap" <rdunlap@...radead.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/6] sparc32: Do not select GENERIC_ISA_DMA
On Sat, Feb 24, 2024, at 06:29, Maciej W. Rozycki wrote:
> On Sat, 24 Feb 2024, Maciej W. Rozycki wrote:
>
> The GENERIC_ISA_DMA option itself was added to arch/sparc/config.in with
> 2.5.31 as:
>
> define_bool CONFIG_GENERIC_ISA_DMA y
>
> despite of:
>
> define_bool CONFIG_ISA n
I think I've seen any combination of CONFIG_ISA (the 62/98 pin slots), CONFIG_GENERIC_ISA_DMA (the request_dma() interface) and
CONFIG_ISA_DMA_API (the set_dma_addr()/enable_dma() type interface),
but I agree that sparc should have none of the three as both
floppy and parport use some other interface.
> for a reason not clear to me (BLK_DEV_FD? -- but on SPARC that uses some
> hacks to work in the absence of ISA DMA anyway).
>
> Am I missing anything here?
I think it was part of the ISA DMA lookalike that got removed
in 334ae614772b ("sparc: Kill SBUS DVMA layer.") and should
have been changed back then.
Arnd
Powered by blists - more mailing lists