Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sat, 29 Jan 2022 10:55:30 +1100 (AEDT)
From:   Finn Thain <fthain@linux-m68k.org>
To:     Michael Schmitz <schmitzmic@gmail.com>
cc:     Geert Uytterhoeven <geert@linux-m68k.org>,
        linux-m68k@lists.linux-m68k.org,
        Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
        linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] m68k: mm: Remove check for VM_IO to fix deferred I/O
In-Reply-To: <b1cd50eb-e476-b4bd-0b2f-b4a8699660f6@gmail.com>
Message-ID: <4d65d2e1-5fb3-456-3cc5-fbd3167d06c@linux-m68k.org>
References: <20220128173006.1713210-1-geert@linux-m68k.org> <b1cd50eb-e476-b4bd-0b2f-b4a8699660f6@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Sat, 29 Jan 2022, Michael Schmitz wrote:

> Hi Geert,
> 
> for hwregs_present(), the exception fixup will handle any access error 
> (through send_fault_sig()), so this should continue to work.
> 
> Why the special handling of VM_IO pages? Maybe hp300 had marked all IO 
> register pages VM_IO to distinguish IO faults from VM faults...
> 
> The only other area I can imagine this might have an impact is the Mac's 
> pseudo-DMA - FInn might want to give this some testing.
> 

mac_scsi.c and mac_esp.c don't use ioremap(). They rely on head.S:

        mmu_map_eq      #0x50000000,#0x03000000,%d3

Having said that, I will run some tests if you still think it necessary.