Hi Geert,
I just realized the commit message subject for this patch needs
correcting. Will that mess up your workflow (assuming I retain the
subject line for the announcement mail)?
Cheers,
Michael
Am 12.07.2022 um 08:02 schrieb Michael Schmitz:
Hi Geert,
Am 11.07.2022 um 20:27 schrieb Geert Uytterhoeven:
Hi Michael,
On Mon, Jul 11, 2022 at 9:57 AM Michael Schmitz <schmitzmic@xxxxxxxxx>
wrote:
Am 11.07.2022 um 19:16 schrieb Geert Uytterhoeven:
On Sun, Jul 10, 2022 at 6:12 PM Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
A resource would pass a phys_addr_t token, but the driver expects a
virtual address that should be an __iomem pointer. The MMIO area
already gets mapped into virtual addresses in arch/m68k/kernel/head.S,
so it makes sense to skip the extra ioremap() and just use the
address,
but then you can't pass it as an IORESOUCRE_MEM token and should
use platform_data with the pointer instead.
OK, got it now (I had missed the physical/virtual mismatch entirely).
And the __iomem is there so we can catch mistakes using sparse
(make C=2 path/to/file/.o).
I'll need to make a habit of that ...
The alternative is to do it the normal way and pass the physical
address
as a resource, that you can pass into devm_platform_ioremap_resource()
or a similar helper.
I would prefer the latter. While head.S sets up the mapping,
__ioremap() does not have support for this on the mvme platform,
so this has to be added first. Look at the amiga and virt platforms
for examples.
I see - doesn't look too hard to do, and should not affect any other
existing code.
Is it worth adding the same support for Atari as well?
From a quick glance at arch/m68k/kernel/head.S, it seems that
on Atari there is no identity mapping (the high I/O area is mapped
to the virtual low area). That means __ioremap() and iounmap()
wouldn't be symmetrical, but it can be done.
As I read it, it's the other way: virtual 0xffxxxxxx is mapped to phys.
0x00ffxxxx, and all hardware addresses are given in the upper window
(Medusa/Hades use that window only, and have identity mappings there).
So returning identity mapping in the high window would work AFAICS. I'll
give that a try sometime.
Note that on Amiga we only use the identity shortcut for Zorro III
memory (and only for the first half?), i.e. ioremap() on Zorro II I/O
does add new mappings. Hence most Zorro II drivers use ZTWO_VADDR()
instead of ioremap().
I see ZTWO_VADDR() already returns void __iomem* ... Fixing this patch
would sort out the m68k drivers, leaving SGI. I'll have to see whether I
can dig up a SGI workstation with this driver; might be easier than
getting hold of any Amgias here Dowh Under.
Cheers,
Michael
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
geert@xxxxxxxxxxxxxx
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
