Re: [PATCH 4/4] sh: machvec: remove custom ioport_{un,}map()

"Arnd Bergmann" <[email protected]>
Newsgroups gmane.linux.ports.sh.devel,gmane.linux.kernel
Message-ID <[email protected]>
On Wed, Sep 13, 2023, at 14:32, Geert Uytterhoeven wrote:
> On Wed, Aug 2, 2023 at 8:49 PM Arnd Bergmann <[email protected]> wrote:
>> From: Arnd Bergmann <[email protected]>
>>
>> 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 <[email protected]>
>
>> --- 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.