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 16:13, Geert Uytterhoeven wrote:
> On Wed, Sep 13, 2023 at 4:08 PM Arnd Bergmann <[email protected]> wrote:
>> 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:
>>
>> 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/[email protected]/

Ok, thanks.

> 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/[email protected]

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
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.

x86 and ia64 want GENERIC_IOMAP because they require using
custom instructions for accessing IORESOURCE_IO registers,
but it's not really generic.

    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.