lkml.org 
[lkml]   [2023]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2023-09-13 16:09    [W:0.188 / U:1.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site