Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5317384ybp; Tue, 8 Oct 2019 00:34:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqyWXugNo0YlZ4A8BSZNe4hCML8EYmzC7xbsy82qpiJUzUdCfKyt1DFfs4ON/ays6LFk4kjb X-Received: by 2002:a17:906:bcd9:: with SMTP id lw25mr19726508ejb.315.1570520093483; Tue, 08 Oct 2019 00:34:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570520093; cv=none; d=google.com; s=arc-20160816; b=sJozRSrH292aABnNrZWY4FJH6/4nhkPKd4XH+NF3SUWVV8fBcYmraEkQpVUQDXzsDz h+xNv8tLv77pz4lBrNdg5p+PNWf4qBZ73PfacI2AhqrLIDSAVT5P0HaAziXGhRETaO5O oegUc8e460LbibZWdxzr/80oPhzTlYFB83PS2+jKWPRImeiey2J5vPUn+MaGcRrzT4Fo uptmNC0Sz+Rv4B/Th1reKZJFNYqmC4ZI2Wa0t4wPee5vgvjxP1m8735Sv6Ui+v+2im8R 0f59ZmFo7auO/Ku16iPShXvpP8Km3TsARDttgDMt1kbttuRYP4gXyHmiPbzOotHOkqlX 1iHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=9FHNC8nieDjNhbrOomcz/G+F1i951EZZim1jgU61i/g=; b=ipdDCXQq3p3XYWsnGE04xGSX4tUoXdfkt6RBYbRA9QjzkTCDlm71JkSa1GCkbvI3JT V0f3IrDd2NTh+xnJ95natSYOUEV/hVeXC2Hhsk2Ec2pua0iACtipu/v+h6Ov5CRDMMDf sa7Qzjo+IoxjuHkL99B5s9vZdNI9RH1ACYNVL4iyhWbL9+R39a6blF0RlVwEpO7nmbMT cIFH9nvCylDzwXw7A2WW8rLrS+uPjWRvtGLkP6Kfoo/jD6vTnGRGoxz3//hhoUVQudGY S+DJlSIxTQSD5byMb6kiR2hautJxjuYG+VqcxG5KNL+a1r6x8Q2OESojz16/eevyWEe9 V0yw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y11si8837456ejj.363.2019.10.08.00.34.29; Tue, 08 Oct 2019 00:34:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730313AbfJHHcO (ORCPT + 99 others); Tue, 8 Oct 2019 03:32:14 -0400 Received: from verein.lst.de ([213.95.11.211]:44494 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730279AbfJHHcO (ORCPT ); Tue, 8 Oct 2019 03:32:14 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id C809A68B20; Tue, 8 Oct 2019 09:32:10 +0200 (CEST) Date: Tue, 8 Oct 2019 09:32:10 +0200 From: Christoph Hellwig To: Arvind Sankar Cc: Christoph Hellwig , Christoph Hellwig , linux-kernel@vger.kernel.org Subject: Re: ehci-pci breakage with dma-mapping changes in 5.4-rc2 Message-ID: <20191008073210.GB9452@lst.de> References: <20191007022454.GA5270@rani.riverdale.lan> <20191007073448.GA882@lst.de> <20191007175430.GA32537@rani.riverdale.lan> <20191007175528.GA21857@lst.de> <20191007175630.GA28861@infradead.org> <20191007175856.GA42018@rani.riverdale.lan> <20191007183206.GA13589@rani.riverdale.lan> <20191007184754.GB31345@lst.de> <20191007221054.GA409402@rani.riverdale.lan> <20191007235401.GA608824@rani.riverdale.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191007235401.GA608824@rani.riverdale.lan> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 07, 2019 at 07:54:02PM -0400, Arvind Sankar wrote: > > Do you want me to resend the patch as its own mail, or do you just take > > it with a Tested-by: from me? If the former, I assume you're ok with me > > adding your Signed-off-by? > > > > Thanks > > A question on the original change though -- what happens if a single > device (or a single IOMMU domain really) does want >4G DMA address > space? Was that not previously allowed either? Your EHCI device actually supports the larger addressing. Without an IOMMU (or with accidentally enabled passthrough mode as in your report) that will use bounce buffers for physical address that are too large. With an iommu we can just remap, and by default those remap addresses are under 32-bit just to make everyones life easier. The dma_get_required_mask function is misnamed unfortunately, what it really means is the optimal mask, that is one that avoids bounce buffering or other complications.