From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966358AbdCXQUS (ORCPT ); Fri, 24 Mar 2017 12:20:18 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:36410 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965231AbdCXQUI (ORCPT ); Fri, 24 Mar 2017 12:20:08 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Arnd Bergmann Date: Fri, 24 Mar 2017 17:20:01 +0100 X-Google-Sender-Auth: 0krGUhoYpf_OSVnvkdViD3_oSAs Message-ID: Subject: Re: [PATCH 00/17] PCI resource mmap cleanup To: David Woodhouse Cc: linux-pci , linux-arch , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 22, 2017 at 2:25 PM, David Woodhouse wrote: > This started out as a fairly trivial "add pci_mmap_page_range() for > ARM64" patch. But pci_mmap_page_range() is a vile interface, taking > "user visible" resource addresses converted with pci_resource_to_user() > on those platforms unlucky enough to use that... and even in the *sane* > sysfs-based mmap method, we convert through user addresses to call the > platform-specific method. > > In most cases there's just no need for any of this crap. We can migrate > most architectures to a generic implementation without much thought, > and the few that aren't converted in this series can probably be added > fairly easily too but need a little more arch-specific attention. > > Utterly untested for now; I'll do some testing while I deal with the > inevitable bikeshedding. Looks good to me overall, I have replied with one request for clarification, and would like the bikeshed in patch 17 in a different colour. Arnd