From: Linus Torvalds <firstname.lastname@example.org> To: John Paul Adrian Glaubitz <email@example.com> Cc: Guenter Roeck <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, linux-sparc <firstname.lastname@example.org>, "David S. Miller" <email@example.com>, linux-arch <firstname.lastname@example.org> Subject: Re: Linux 5.15-rc2 Date: Mon, 20 Sep 2021 13:11:33 -0700 [thread overview] Message-ID: <CAHk-=wjcCZW-Lu85djtfDSiQdOqH1hR=dDP5xHj6vhvMdBCMVA@mail.gmail.com> (raw) In-Reply-To: <email@example.com> On Mon, Sep 20, 2021 at 12:14 PM John Paul Adrian Glaubitz <firstname.lastname@example.org> wrote: > > If you want to get feedback whether the kernel actually boots, let me know. So having looked around more sparc64 actually looks to be ok as-is, because it doesn't do any ioremap at all, and the PIO accesses are done at physical address zero. Sparc uses a special IO memory address space and can basically map all of PCI that way, and it looks like the hardware does all the required special things for the PIO range at address 0-0xffff. So it turns out that the "missing iounmap()" is actually ok on sparc, because it's a no-op anyway - because the ioremap() was just a pointer cast with no actual remapping necessary. And the generic IOMAP thing does assume that PIO is special, in ways that sparc doesn't need. On x86, PIO is not remapped, but also uses different instructions, so it's not just pointer games that could be done at iomap/unmap case. (And on many other architectures you need to do different synchronization, even if you could perhaps otherwise make the PIO-vs-MMIO be only about the pointer mapping - so "writeb()" and "outb()" aren't just different in the addressing). End result: the only downside of sparc not using the generic iomap is likely that sparc will happily use a NULL __iomap pointer (error) and basically use it as a PIO access. But since other architectures like x86-64 would warn for that case (see 'bad_io_access()' in lib/iomap.c), even that isn't actually a big deal - any such bugs would have been found elsewhere. And having looked at this, I'm starting to suspect that sparc oddity is _why_ the fallback version in <asm-generic/io.h> was so broken. It did the right thing on sparc, but leaks iomap remappings almost anywhere else. But maybe sparc ended up being the only user of it? Linus
prev parent reply other threads:[~2021-09-21 3:19 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <CAHk-=wirexiZR+VO=H3xemGKOMkh8OasmXaKXTKUmAKYCzi8AQ@mail.gmail.com> [not found] ` <20210920134424.GA346531@roeck-us.net> 2021-09-20 16:18 ` Linus Torvalds 2021-09-20 17:04 ` Linus Torvalds 2021-09-20 18:03 ` Linus Torvalds 2021-09-20 19:14 ` John Paul Adrian Glaubitz 2021-09-20 20:11 ` Linus Torvalds [this message]
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='CAHk-=wjcCZW-Lu85djtfDSiQdOqH1hR=dDP5xHj6vhvMdBCMVA@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Linux 5.15-rc2' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).