Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
MIME-Version: 1.0
References: <20230802184849.1019466-1-arnd@kernel.org> <20230802184849.1019466-4-arnd@kernel.org>
 <CAMuHMdVjmD357K-yxxW-jn-6vKsXTg+u1Psw9DftyxH=dQoMEg@mail.gmail.com> <5dad2d86-78ea-4a39-8ee1-98e3eb134d36@app.fastmail.com>
In-Reply-To: <5dad2d86-78ea-4a39-8ee1-98e3eb134d36@app.fastmail.com>
From:   Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Wed, 13 Sep 2023 16:13:04 +0200
Message-ID: <CAMuHMdVYcvPL+JpPw9sA48=615cdfwa8d0LP-bVp0NWqbQ+JOw@mail.gmail.com>
Subject: Re: [PATCH 4/4] sh: machvec: remove custom ioport_{un,}map()
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     Arnd Bergmann <arnd@kernel.org>,
        John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
        linux-sh@vger.kernel.org, Rich Felker <dalias@libc.org>,
        Yoshinori Sato <ysato@users.sourceforge.jp>,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Precedence: bulk

Hi Arnd,

On Wed, Sep 13, 2023 at 4:08 PM Arnd Bergmann <arnd@arndb.de> wrote:
> 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.

"[RESEND RFC PATCH 00/12] DeviceTree support for SH7751 based boards."
https://lore.kernel.org/linux-sh/cover.1693444193.git.ysato@users.sourceforge.jp/

In the meantime, there is a v2, which I wasn't aware of when I wrote
my previous email, so perhaps my comment is no longer valid.
"[RFC PATCH v2 00/30] Device Tree support for SH7751 based board"
https://lore.kernel.org/linux-sh/cover.1694596125.git.ysato@users.sourceforge.jp

> Is this needed for the trapped_io CF stuff?

I don't know.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds