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: <9076d00e-c469-4a05-a686-94e3e55c8389@linux-m68k.org>
Date: Mon, 24 Mar 2025 23:50:19 +1000
From: Greg Ungerer <gerg@...ux-m68k.org>
To: Arnd Bergmann <arnd@...db.de>, Arnd Bergmann <arnd@...nel.org>,
 Linux-Arch <linux-arch@...r.kernel.org>
Cc: Richard Henderson <richard.henderson@...aro.org>,
 Matt Turner <mattst88@...il.com>, Geert Uytterhoeven <geert@...ux-m68k.org>,
 Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
 "James E . J . Bottomley" <James.Bottomley@...senpartnership.com>,
 Helge Deller <deller@....de>, Madhavan Srinivasan <maddy@...ux.ibm.com>,
 Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>,
 Christophe Leroy <christophe.leroy@...roup.eu>,
 Naveen N Rao <naveen@...nel.org>, Yoshinori Sato
 <ysato@...rs.sourceforge.jp>, Rich Felker <dalias@...c.org>,
 John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
 Julian Vetter <julian@...er-limits.org>, Bjorn Helgaas
 <bhelgaas@...gle.com>, linux-alpha@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-m68k@...ts.linux-m68k.org,
 linux-mips@...r.kernel.org, linux-parisc@...r.kernel.org,
 linuxppc-dev@...ts.ozlabs.org, linux-sh@...r.kernel.org
Subject: Re: [PATCH 6/6] m68k/nommu: stop using GENERIC_IOMAP

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@...db.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@...db.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@...ux-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@...db.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@...ux-m68k.org>
> Signed-off-by: Arnd Bergmann <arnd@...db.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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ