Messages in this thread | | | Date | Wed, 13 Sep 2023 16:08:23 +0200 | From | "Arnd Bergmann" <> | Subject | Re: [PATCH 4/4] sh: machvec: remove custom ioport_{un,}map() |
| |
On Wed, Sep 13, 2023, at 14:32, Geert Uytterhoeven wrote: > On Wed, Aug 2, 2023 at 8:49 PM Arnd Bergmann <arnd@kernel.org> wrote: >> From: Arnd Bergmann <arnd@arndb.de> >> >> These functions were only used on the microdev >> board that is now gone, so remove them to simplify >> the ioport handling. >> >> This could be further simplified to use the generic >> I/O port accessors now. >> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de> > >> --- a/arch/sh/include/asm/io.h >> +++ b/arch/sh/include/asm/io.h >> @@ -181,7 +181,7 @@ static inline void pfx##out##bwlq##p(type val, unsigned long port) \ >> { \ >> volatile type *__addr; \ >> \ >> - __addr = __ioport_map(port, sizeof(type)); \ >> + __addr = (void __iomem *)sh_io_port_base + port; \ > > Note that this adds unconditional users of sh_io_port_base, while > sh_io_port_base is provided by arch/sh/kernel/ioport.c, which is > currently only built if CONFIG_GENERIC_IOMAP=n. > > This is not a problem yet, as the final part to enable GENERIC_IOMAP > on SH never made it upstream. However, Sato-san's series enables > GENERIC_IOMAP for SH_DEVICE_TREE=y builds, leading to a link failure.
Do you have a link to that series? I don't understand why you'd want to enable GENERIC_IOMAP on sh, given that its PIO accesses are always memory mapped in the end.
Is this needed for the trapped_io CF stuff?
Arnd
| |