From: Greg Ungerer <gerg@linux-m68k.org>
To: Arnd Bergmann <arnd@arndb.de>, Arnd Bergmann <arnd@kernel.org>,
Linux-Arch <linux-arch@vger.kernel.org>
Cc: Richard Henderson <richard.henderson@linaro.org>,
Matt Turner <mattst88@gmail.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
"James E . J . Bottomley" <James.Bottomley@hansenpartnership.com>,
Helge Deller <deller@gmx.de>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Naveen N Rao <naveen@kernel.org>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Rich Felker <dalias@libc.org>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Julian Vetter <julian@outer-limits.org>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-sh@vger.kernel.org
Subject: Re: [PATCH 6/6] m68k/nommu: stop using GENERIC_IOMAP
Date: Mon, 24 Mar 2025 23:50:19 +1000 [thread overview]
Message-ID: <9076d00e-c469-4a05-a686-94e3e55c8389@linux-m68k.org> (raw)
In-Reply-To: <4a31c6a8-7c99-4d8f-8248-92e0e52b8db6@app.fastmail.com>
Hi Arnd,
On 24/3/25 18:02, Arnd Bergmann wrote:
> On Mon, Mar 24, 2025, at 02:33, Greg Ungerer wrote:
>> Hi Arnd,
>>
>> On 15/3/25 20:59, Arnd Bergmann wrote:
>>> From: Arnd Bergmann <arnd@arndb.de>
>>>
>>> There is no need to go through the GENERIC_IOMAP wrapper for PIO on
>>> nommu platforms, since these always come from PCI I/O space that is
>>> itself memory mapped.
>>>
>>> Instead, the generic ioport_map() can just return the MMIO location
>>> of the ports directly by applying the PCI_IO_PA offset, while
>>> ioread32/iowrite32 trivially turn into readl/writel as they do
>>> on most other architectures.
>>>
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>
>> With this applied this fails to build for me:
>>
>> UPD include/generated/utsversion.h
>> CC init/version-timestamp.o
>> LD vmlinux
>> m68k-linux-uclibc-ld: drivers/pci/quirks.o: in function
>> `quirk_switchtec_ntb_dma_alias':
>> quirks.c:(.text+0x23e4): undefined reference to `pci_iomap'
>> m68k-linux-uclibc-ld: quirks.c:(.text+0x24fe): undefined reference to
>> `pci_iounmap'
>> m68k-linux-uclibc-ld: drivers/pci/quirks.o: in function
>> `disable_igfx_irq':
>> quirks.c:(.text+0x32f4): undefined reference to `pci_iomap'
>> m68k-linux-uclibc-ld: quirks.c:(.text+0x3348): undefined reference to
>> `pci_iounmap'
>
> Thanks for the report, I was able to reproduce the problem now
> and applied the fixup below. I had tested m5475evb_defconfig earlier,
> and that built cleanly with PCI enabled, but I had missed how
> that still used GENERIC_IOMAP because it has CONFIG_MMU enabled.
>
> Does this fixup work for you?
Yes, this looks good, works for me.
Feel free to add this if you like:
Acked-by: Greg Ungerer <gerg@linux-m68k.org>
> On a related note, I'm curious about how the MCF54xx chips are
> used in practice, as I see that they are the only coldfire chips
> with PCI and they all have an MMU. Are there actual users of these
> chips that have PCI but choose not to use the MMU?
No, I think everyone with these uses them with MMU enabled.
It is probably more of an historical curiosity to use them with
the MMU disabled. That supported pre-dated mainline kernels having
full ColdFire MMU support by a good few years.
Regards
Greg
> Arnd
>
> 8<-----
> From a36995e2a64711556c6773797367d165828f6705 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Mon, 24 Mar 2025 07:53:47 +0100
> Subject: [PATCH] m68k: coldfire: select PCI_IOMAP for PCI
>
> After I dropped CONFIG_GENERIC_IOMAP, some PCI drivers started failing
> to link when CONFIG_MMU is disabled:
>
> ERROR: modpost: "pci_iounmap" [drivers/video/fbdev/i740fb.ko] undefined!
> ERROR: modpost: "pci_iounmap" [drivers/video/fbdev/vt8623fb.ko] undefined!
> ERROR: modpost: "pci_iomap_wc" [drivers/video/fbdev/vt8623fb.ko] undefined!
> ERROR: modpost: "pci_iomap" [drivers/video/fbdev/vt8623fb.ko] undefined!
> ERROR: modpost: "pci_iounmap" [drivers/video/fbdev/s3fb.ko] undefined!
> ...
>
> It turns out that there were two mistakes in my patch: on !MMU I forgot
> to enable CONFIG_GENERIC_PCI_IOMAP, and for Coldfire with MMU enabled,
> teh GENERIC_IOMAP was left in place but incorrectly configured.
>
> Fixes: 9d48cc07d0d7 ("m68k/nommu: stop using GENERIC_IOMAP")
> Reported-by: Greg Ungerer <gerg@linux-m68k.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
> index b50c275fa94d..eb5bb6d36899 100644
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@ -18,12 +18,13 @@ config M68K
> select DMA_DIRECT_REMAP if M68K_NONCOHERENT_DMA && !COLDFIRE
> select GENERIC_ATOMIC64
> select GENERIC_CPU_DEVICES
> - select GENERIC_IOMAP if HAS_IOPORT && MMU
> + select GENERIC_IOMAP if HAS_IOPORT && MMU && !COLDFIRE
> select GENERIC_IRQ_SHOW
> select GENERIC_LIB_ASHLDI3
> select GENERIC_LIB_ASHRDI3
> select GENERIC_LIB_LSHRDI3
> select GENERIC_LIB_MULDI3
> + select GENERIC_PCI_IOMAP if PCI
> select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
> select HAVE_ARCH_LIBGCC_H
> select HAVE_ARCH_SECCOMP
next prev parent reply other threads:[~2025-03-24 13:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-15 10:59 [PATCH 0/6] asm-generic: io.h cleanups Arnd Bergmann
2025-03-15 10:59 ` [PATCH 1/6] alpha: stop using asm-generic/iomap.h Arnd Bergmann
2025-03-15 10:59 ` [PATCH 2/6] sh: remove duplicate ioread/iowrite helpers Arnd Bergmann
2025-06-07 12:08 ` John Paul Adrian Glaubitz
2025-06-08 9:39 ` Geert Uytterhoeven
2025-06-08 9:44 ` John Paul Adrian Glaubitz
2025-03-15 10:59 ` [PATCH 3/6] parisc: stop using asm-generic/iomap.h Arnd Bergmann
2025-03-15 10:59 ` [PATCH 4/6] powerpc: asm/io.h: remove split ioread64/iowrite64 helpers Arnd Bergmann
2025-03-17 11:31 ` Michael Ellerman
2025-03-15 10:59 ` [PATCH 5/6] mips: drop GENERIC_IOMAP wrapper Arnd Bergmann
2025-03-18 20:39 ` Nathan Chancellor
2025-03-18 21:13 ` Arnd Bergmann
2025-03-19 17:30 ` Nathan Chancellor
2025-03-19 18:00 ` Arnd Bergmann
2025-03-15 10:59 ` [PATCH 6/6] m68k/nommu: stop using GENERIC_IOMAP Arnd Bergmann
2025-03-24 1:33 ` Greg Ungerer
2025-03-24 8:02 ` Arnd Bergmann
2025-03-24 13:50 ` Greg Ungerer [this message]
2025-03-24 14:40 ` Arnd Bergmann
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=9076d00e-c469-4a05-a686-94e3e55c8389@linux-m68k.org \
--to=gerg@linux-m68k.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=bhelgaas@google.com \
--cc=christophe.leroy@csgroup.eu \
--cc=dalias@libc.org \
--cc=deller@gmx.de \
--cc=geert@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=julian@outer-limits.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mattst88@gmail.com \
--cc=mpe@ellerman.id.au \
--cc=naveen@kernel.org \
--cc=npiggin@gmail.com \
--cc=richard.henderson@linaro.org \
--cc=tsbogend@alpha.franken.de \
--cc=ysato@users.sourceforge.jp \
/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).