From: "Arnd Bergmann" <arnd@kernel.org>
To: "Geert Uytterhoeven" <geert@linux-m68k.org>
Cc: "Michael Schmitz" <schmitzmic@gmail.com>,
"Niklas Schnelle" <schnelle@linux.ibm.com>,
linux-m68k@lists.linux-m68k.org,
"Heiko Carstens" <hca@linux.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/1] m68k: Handle HAS_IOPORT dependencies
Date: Fri, 05 Apr 2024 13:24:28 +0200 [thread overview]
Message-ID: <11fdef9b-413d-4f88-b3d3-e5b27a88cf6f@app.fastmail.com> (raw)
In-Reply-To: <CAMuHMdX+M1VuhDVnC9n4hCBDjHywwsByNK1w8ibazc+-8_C53A@mail.gmail.com>
On Fri, Apr 5, 2024, at 12:16, Geert Uytterhoeven wrote:
> On Wed, Apr 3, 2024 at 8:35 PM Arnd Bergmann <arnd@kernel.org> wrote:
>> On Wed, Apr 3, 2024, at 20:11, Michael Schmitz wrote:
>>
>> For the Q40, it may be better in the long run to change the
>> drivers to just use MMIO directly though.
>
> Q40 uses ISA.
Ah, indeed. I got confused by the NE2000 example as that
contains "depends on (ISA || (Q40 && m)", which would have
indicated that it's not actually using CONFIG_ISA.
> Michael is worried about non-ISA drivers using inb() and friends.
> At some point in time (i.e. eons ago), we were told it was better to
> use in[bwl]()/read[bwl]() instead of directly dereferencing volatile
> pointers...
It's definitely still better to use an abstraction layer for MMIO
accesses using inline asm instructions than open-coding the
volatile pointer dereferences. Over time we have gotten better
at defining which of the available abstractions should be used
for a given bus, so inb()/outb() is now only really used for
things derived from ISA in some form, including e.g. PCI and LPC.
> Anyway, I don't think we have many users of inb() and friends left, and
> I assume the bots should have detected any/most remaining users in Niklas'
> branch...
>
> arch/m68k/include/asm/floppy.h on Sun-3x might be the only offender?
Could be. I think we can leave this one to whoever tries to get
sun3x floppy support working, it's been marked broken for a while
(see below). If there are any others, they will cause pretty
obvious build failures once inb()/outb() are removed from the
build, and they should be trivial to fix then.
Arnd
commit f1e0f28a85001f4faa3ea930fcf201933f42340e
Author: akpm <akpm>
Date: Mon Jan 19 18:31:30 2004 +0000
[PATCH] M68k floppy selection
From: Geert Uytterhoeven <geert@linux-m68k.org>
Floppy: On m68k, PC-style floppies are used on Q40/Q60 and Sun-3x only. Sun-3x
floppy is currently broken (needs I/O abstractions)
BKrev: 400c2282G1O-TsH5FiwzPbOorftQhg
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 2dce1d2699a9..32fdec34568e 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -6,7 +6,7 @@ menu "Block devices"
config BLK_DEV_FD
tristate "Normal floppy disk support"
- depends on !X86_PC9800 && !ARCH_S390
+ depends on (!X86_PC9800 && !ARCH_S390 && !M68K) || Q40 || (SUN3X && BROKEN)
---help---
If you want to use the floppy disk drive(s) of your PC under Linux,
say Y. Information about this driver, especially important for IBM
next prev parent reply other threads:[~2024-04-05 11:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-03 12:28 [PATCH 0/1] m68k: Handle HAS_IOPORT dependencies Niklas Schnelle
2024-04-03 12:28 ` [PATCH 1/1] m68k: Let GENERIC_IOMAP depend on HAS_IOPORT Niklas Schnelle
2024-05-08 11:44 ` Geert Uytterhoeven
2024-04-03 18:11 ` [PATCH 0/1] m68k: Handle HAS_IOPORT dependencies Michael Schmitz
2024-04-03 18:34 ` Arnd Bergmann
2024-04-05 10:16 ` Geert Uytterhoeven
2024-04-05 11:24 ` Arnd Bergmann [this message]
2024-04-08 8:23 ` Geert Uytterhoeven
2024-04-05 18:36 ` Michael Schmitz
2024-04-05 20:13 ` Arnd Bergmann
2024-04-06 1:14 ` Michael Schmitz
2024-04-06 15:27 ` Arnd Bergmann
2024-04-06 20:09 ` Michael Schmitz
2024-04-08 8:19 ` 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=11fdef9b-413d-4f88-b3d3-e5b27a88cf6f@app.fastmail.com \
--to=arnd@kernel.org \
--cc=geert@linux-m68k.org \
--cc=hca@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=schmitzmic@gmail.com \
--cc=schnelle@linux.ibm.com \
/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