From patchwork Thu Jun 9 00:00:47 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yinghai Lu X-Patchwork-Id: 632577 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3rQ56v1ggZz9sC3 for ; Thu, 9 Jun 2016 10:00:55 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=JJGMt3+C; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932902AbcFIAAw (ORCPT ); Wed, 8 Jun 2016 20:00:52 -0400 Received: from mail-vk0-f65.google.com ([209.85.213.65]:35985 "EHLO mail-vk0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932119AbcFIAAu (ORCPT ); Wed, 8 Jun 2016 20:00:50 -0400 Received: by mail-vk0-f65.google.com with SMTP id x7so3869487vkf.3; Wed, 08 Jun 2016 17:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wmvDU1LtFWJWiuucwj2eNRASPxKcH+PlkW8uS28I+5U=; b=JJGMt3+CCVl6066hT53Cf5V8fTnxynVHfLyikFxDzmCdJDj3Akx0nZDSrlauBEqeG1 0mF3IAxas/nAqdjDYDjHEkVGaVr/5V1jyDgWlgzCDc9VMYiKefH7PIVdZhWJ0iZFg0Kt rFx6f7js7wnR0yUwCI7CQNuhC6v1DnShjz4n3WPCAbhvcxPmHj0hSLRboG9Hj//az3YK Lxl94L+egyR1UBW9R8zAvUIa53/aveq5n6zVr4Un8yTFDY5DjRrBkVJESVnG5Iw9jnuI d1p1DwznRILT210flnvJm2itJOHLjZ8oZUNcS18gisrRbDHmIW5NNG7yQEia1hDbzqjB KmBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wmvDU1LtFWJWiuucwj2eNRASPxKcH+PlkW8uS28I+5U=; b=I7EWaL1pYUnXfHNlCt0WjQ6cWs/ckiud8uwgj1jG7fYBrh0cy4knPKsBTgL9By+VQC Uwwxj6GuiChVfCOQ/9jHS7Z0JxavFpmmMUZmwkhp689onBn7yXZ9/k6c8tJNMSiHVmaJ MWhOkdzbqfWeAFce0ogWJ+FNXKKwcrZ2iPFfTvKwujL/EcLIM70tkeXoWxf5DtJChT7P N2NuJxglWN/fZKuXJH8OQJB/qdE12HhpfgTwBB3Boe4E9o4XF8jT6qBPEnn3jeJr0HP4 2GnjehEyeGpoFLwyz8UF/E0d3OMhWvFOuxxt/LKw+90XAAkg2jE/fnnPpYp07cwSJ2/9 AF5g== X-Gm-Message-State: ALyK8tLsC3qs/rrS9cyCxxXmOYMCTaS/8vCQ2OE2C1vaGsGgX0NzwuPnSqBl7xV/Ir1sPQVZhD87SO5+naWDSA== X-Received: by 10.176.3.72 with SMTP id 66mr3425821uat.146.1465430448568; Wed, 08 Jun 2016 17:00:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.81.11 with HTTP; Wed, 8 Jun 2016 17:00:47 -0700 (PDT) In-Reply-To: References: <20160604000642.28162-1-yinghai@kernel.org> <20160604000642.28162-2-yinghai@kernel.org> <20160608210322.GA4248@localhost> From: Yinghai Lu Date: Wed, 8 Jun 2016 17:00:47 -0700 X-Google-Sender-Auth: z1Fi83VDkSmDYQsnrl48WM2oheg Message-ID: Subject: Re: [PATCH v12 01/15] PCI: Let pci_mmap_page_range() take extra resource pointer To: Bjorn Helgaas Cc: Bjorn Helgaas , David Miller , Benjamin Herrenschmidt , Linus Torvalds , Wei Yang , Khalid Aziz , "linux-pci@vger.kernel.org" , Linux Kernel Mailing List , "linux-arm-kernel@lists.infradead.org" , linux-cris-kernel@axis.com, "linux-ia64@vger.kernel.org" , "linux-mips@linux-mips.org" , linux-am33-list@redhat.com, linux-parisc@vger.kernel.org, linuxppc-dev , linux-sh@vger.kernel.org, "sparclinux@vger.kernel.org" , linux-xtensa@linux-xtensa.org Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Wed, Jun 8, 2016 at 3:35 PM, Yinghai Lu wrote: > At the same time, can you kill __pci_mmap_set_pgprot() for powerpc. Can you please put your two patches and this attached one into to pci/next? Then I could send updated PCI: Let pci_mmap_page_range() take resource address. Thanks Yinghai From: Bjorn Helgaas Subject: [PATCH] powerpc/PCI: Remove __pci_mmap_set_pgprot() PCI: Ignore write-combining when mapping I/O port space already handle the io port mmap path. For mmio mmap path, caller should state that correctly if write_combine is really needed. via proc path it should look like: mmap(fd, ...) # default is I/O, non-combining ioctl(fd, PCIIOC_WRITE_COMBINE, 1); # request write-combining ioctl(fd, PCIIOC_MMAP_IS_MEM); # request memory space mmap(fd, ...) sysfs path, it should use resource]?]_wc. Signed-off-by: Bjorn Helgaas --- arch/powerpc/kernel/pci-common.c | 37 ++++--------------------------------- 1 file changed, 4 insertions(+), 33 deletions(-) Index: linux-2.6/arch/powerpc/kernel/pci-common.c =================================================================== --- linux-2.6.orig/arch/powerpc/kernel/pci-common.c +++ linux-2.6/arch/powerpc/kernel/pci-common.c @@ -356,36 +356,6 @@ static struct resource *__pci_mmap_make_ } /* - * Set vm_page_prot of VMA, as appropriate for this architecture, for a pci - * device mapping. - */ -static pgprot_t __pci_mmap_set_pgprot(struct pci_dev *dev, struct resource *rp, - pgprot_t protection, - enum pci_mmap_state mmap_state, - int write_combine) -{ - - /* Write combine is always 0 on non-memory space mappings. On - * memory space, if the user didn't pass 1, we check for a - * "prefetchable" resource. This is a bit hackish, but we use - * this to workaround the inability of /sysfs to provide a write - * combine bit - */ - if (mmap_state != pci_mmap_mem) - write_combine = 0; - else if (write_combine == 0) { - if (rp->flags & IORESOURCE_PREFETCH) - write_combine = 1; - } - - /* XXX would be nice to have a way to ask for write-through */ - if (write_combine) - return pgprot_noncached_wc(protection); - else - return pgprot_noncached(protection); -} - -/* * This one is used by /dev/mem and fbdev who have no clue about the * PCI device, it tries to find the PCI device first and calls the * above routine @@ -458,9 +428,10 @@ int pci_mmap_page_range(struct pci_dev * return -EINVAL; vma->vm_pgoff = offset >> PAGE_SHIFT; - vma->vm_page_prot = __pci_mmap_set_pgprot(dev, rp, - vma->vm_page_prot, - mmap_state, write_combine); + if (write_combine) + vma->vm_page_prot = pgprot_noncached_wc(vma->vm_page_prot); + else + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); ret = remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff, vma->vm_end - vma->vm_start, vma->vm_page_prot);