Re: [PATCH v1 3/4] scsi - convert mvme146_scsi.c to platform device

[Michael Schmitz <schmitzmic@gmail.com>]

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@gmail.com>
>> wrote:
>>> Am 11.07.2022 um 19:16 schrieb Geert Uytterhoeven:
>>>> On Sun, Jul 10, 2022 at 6:12 PM Arnd Bergmann <arnd@kernel.org> 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@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
>>