From: Yoshinori Sato <ysato@users.sourceforge.jp>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Arnd Bergmann <arnd@arndb.de>, Arnd Bergmann <arnd@kernel.org>,
linux-sh@vger.kernel.org, Rich Felker <dalias@libc.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] sh: machvec: remove custom ioport_{un,}map()
Date: Mon, 25 Sep 2023 16:08:46 +0900 [thread overview]
Message-ID: <87msxau3up.wl-ysato@users.sourceforge.jp> (raw)
In-Reply-To: <CAMuHMdXFSvyTGvYrc2af_Bba9hHNQ-taufOMXRPrKJGNiCP8mw@mail.gmail.com>
On Thu, 21 Sep 2023 17:52:29 +0900,
Geert Uytterhoeven wrote:
>
> Hi Adrian,
>
> On Thu, Sep 21, 2023 at 9:45 AM John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
> > On Fri, 2023-09-15 at 17:49 +0200, Arnd Bergmann wrote:
> > > On Fri, Sep 15, 2023, at 17:41, Geert Uytterhoeven wrote:
> > > > On Wed, Sep 13, 2023 at 4:30 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > On Wed, Sep 13, 2023, at 16:13, Geert Uytterhoeven wrote:
> > > > >
> > > > > Right, it looks like the GENERIC_IOMAP part if gone from that
> > > > > series, and I also see that the PCI host bridge does not actually
> > > >
> > > > No, 02/30 still enables it.
> > >
> > > Ok.
> > >
> > > > > map the port I/O window. That's usually fine because very few
> > > > > drivers actually need it, and it also means that there should be
> > > > > no need for GENERIC_IOMAP or the simpler alternative.
> > > > >
> > > > > The first version probably only did it accidentally, which is a
> > > > > common mistake, and I think the ones for hexagon, m68k, and
> > > > > mips can probably be removed as well with some simplifiations.
> > > >
> > > > When not selecting GENERIC_IOMAP in v2, the build fails with:
> > > >
> > > > sh4-linux-gnu-ld: lib/devres.o: in function `pcim_iomap_release':
> > > > devres.c:(.text+0x234): undefined reference to `pci_iounmap'
> > >
> > > Odd, that one is provided based on CONFIG_GENERIC_PCI_IOMAP
> > > and should be provided by common code, despite the similar
> > > naming this is unrelated to CONFIG_GENERIC_IOMAP.
> >
> > So, what would be the suggestion now to move forward? Shall I include this
> > series for 6.7 or better wait until after Yoshinori's series to convert
> > to device tree has been merged?
>
> I think including Arnd's cleanups (that is, his v2) in v6.7 is fine.
> Sato-san's series needs more work, and is easy to fix for Arnd's cleanup
> (just provide sh_io_port_base unconditionally).
For devicetree support, we have been using GENERIC_IOMAP and GENERIC_PCI_IOMAP.
This change has no effect, so it's okay to be merged first.
> 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
--
Yosinori Sato
next prev parent reply other threads:[~2023-09-25 7:25 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-02 18:48 [PATCH 1/4] sh: remove stale microdev board Arnd Bergmann
2023-08-02 18:48 ` [PATCH 2/4] sh: remove unused sh4-202 support Arnd Bergmann
2023-09-08 10:00 ` John Paul Adrian Glaubitz
2023-08-02 18:48 ` [PATCH 3/4] sh: remove superhyway bus support Arnd Bergmann
2023-08-03 7:58 ` D. Jeff Dionne
2023-08-03 8:44 ` John Paul Adrian Glaubitz
2023-08-03 9:19 ` Arnd Bergmann
2023-08-03 9:36 ` John Paul Adrian Glaubitz
2023-08-03 9:58 ` Arnd Bergmann
2023-09-08 10:02 ` John Paul Adrian Glaubitz
2023-08-02 18:48 ` [PATCH 4/4] sh: machvec: remove custom ioport_{un,}map() Arnd Bergmann
2023-09-08 10:10 ` John Paul Adrian Glaubitz
2023-09-08 10:20 ` Geert Uytterhoeven
2023-09-08 10:21 ` John Paul Adrian Glaubitz
2023-09-08 10:23 ` John Paul Adrian Glaubitz
2023-09-13 12:32 ` Geert Uytterhoeven
2023-09-13 14:08 ` Arnd Bergmann
2023-09-13 14:13 ` Geert Uytterhoeven
2023-09-13 14:30 ` Arnd Bergmann
2023-09-14 6:23 ` John Paul Adrian Glaubitz
2023-09-14 15:56 ` Arnd Bergmann
2023-09-15 15:41 ` Geert Uytterhoeven
2023-09-15 15:49 ` Arnd Bergmann
2023-09-21 7:45 ` John Paul Adrian Glaubitz
2023-09-21 8:52 ` Geert Uytterhoeven
2023-09-25 7:08 ` Yoshinori Sato [this message]
2023-09-25 7:36 ` Arnd Bergmann
2023-09-26 22:15 ` John Paul Adrian Glaubitz
2023-09-08 9:59 ` [PATCH 1/4] sh: remove stale microdev board John Paul Adrian Glaubitz
2023-09-09 22:06 ` John Paul Adrian Glaubitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87msxau3up.wl-ysato@users.sourceforge.jp \
--to=ysato@users.sourceforge.jp \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=dalias@libc.org \
--cc=geert@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox