From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0797C43610 for ; Fri, 23 Nov 2018 13:21:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B514A20820 for ; Fri, 23 Nov 2018 13:21:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="DFZnldlv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B514A20820 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-parisc-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2504488AbeKXAFK (ORCPT ); Fri, 23 Nov 2018 19:05:10 -0500 Received: from pandora.armlinux.org.uk ([78.32.30.218]:51728 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2394528AbeKXAFJ (ORCPT ); Fri, 23 Nov 2018 19:05:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2014; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OOjcz63Sr/9KqmtB35xykFtz+hrAlkihgQrZlq/gPBo=; b=DFZnldlvQGplXfx5RL3N17yJo 7AT1LgZgzXJ51tma+F7PnUeOQ0aZVDMpzyYlx0dxgcDYSSaImx6WILR1uoRS79XXZvLNXJ6OFbJHi lWikAdscokOXQ3iD02ZsgDb0tj++zLRjA9H/iJl0KxNMpDClAJwx5XILh/So24GXDlVQI=; Received: from n2100.armlinux.org.uk ([fd8f:7570:feb6:1:214:fdff:fe10:4f86]:50011) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gQBO4-0008A4-MK; Fri, 23 Nov 2018 13:20:48 +0000 Received: from linux by n2100.armlinux.org.uk with local (Exim 4.90_1) (envelope-from ) id 1gQBNy-0007LO-QO; Fri, 23 Nov 2018 13:20:42 +0000 Date: Fri, 23 Nov 2018 13:20:38 +0000 From: Russell King - ARM Linux To: Joerg Roedel Cc: Robin Murphy , Linus Torvalds , Christoph Hellwig , linux-arch@vger.kernel.org, linux-alpha@vger.kernel.org, linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org, David Woodhouse , the arch/x86 maintainers , Linux List Kernel Mailing , iommu@lists.linux-foundation.org, jdmason@kudzu.us, xen-devel@lists.xenproject.org, linux-arm-kernel@lists.infradead.org, m.szyprowski@samsung.com Subject: Re: remove the ->mapping_error method from dma_map_ops V2 Message-ID: <20181123132038.GT30658@n2100.armlinux.org.uk> References: <20181122140320.24080-1-hch@lst.de> <20181122170715.GI30658@n2100.armlinux.org.uk> <11829e3c-7302-f821-cf5c-863e5267a17b@arm.com> <20181123104918.GE1586@8bytes.org> <20181123110155.GR30658@n2100.armlinux.org.uk> <20181123130313.GI1586@8bytes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181123130313.GI1586@8bytes.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org On Fri, Nov 23, 2018 at 02:03:13PM +0100, Joerg Roedel wrote: > On Fri, Nov 23, 2018 at 11:01:55AM +0000, Russell King - ARM Linux wrote: > > Yuck. So, if we have a 4GB non-PAE 32-bit system, or a PAE system > > where we have valid memory across the 4GB boundary and no IOMMU, > > we have to reserve the top 4K page in the first 4GB of RAM? > > But that is only needed when dma_addr_t is 32bit anyway, no? You said: But we can easily work around that by reserving the top 4k of the first 4GB of IOVA address space in the allocator, no? Then these values are never returned as valid DMA handles. To me, your proposal equates to this in code: int dma_error(dma_addr_t addr) { return (addr & ~(dma_addr_t)0xfff) == 0xfffff000 ? (s32)addr : 0; } Hence, the size of dma_addr_t would be entirely irrelevant. This makes dma_addr_t values in the range of 0xfffff000 to 0xffffffff special, irrespective of whether dma_addr_t is 32-bit or 64-bit. If that's not what you meant, then I'm afraid your statement wasn't worded very well - so please can you re-word to state more precisely what your proposal is? > > Rather than inventing magic cookies like this, I'd much rather we > > sanitised the API so that we have functions that return success or > > an error code, rather than trying to shoe-horn some kind of magic > > error codes into dma_addr_t and subtly break systems in the process. > > Sure, but is has the obvious downside that we need to touch every driver > that uses these functions, and that are probably a lot of drivers. So we have two options: - change the interface - subtly break drivers In any case, I disagree that we need to touch every driver. Today, drivers just do: if (dma_mapping_error(dev, addr)) and, because dma_mapping_error() returns a boolean, they only care about the true/falseness. If we're going to start returning error codes, then there's no point just returning error codes unless we have some way for drivers to use them. Yes, the simple way would be to make dma_mapping_error() translate addr to an error code, and that maintains compatibility with existing drivers. If, instead, we revamped the DMA API, and had the *new* mapping functions which returned an error code, then the existing mapping functions can be implemented as part of compatibility rather trivially: dma_addr_t dma_map_single(...) { dma_addr_t addr; int error; error = dma_map_single_error(..., &addr); if (error) addr = DMA_MAPPING_ERROR; return addr; } which means that if drivers want access to the error code, they use dma_map_single_error(), meanwhile existing drivers just get on with life as it _currently_ is, with the cookie-based all-ones error code - without introducing any of this potential breakage. Remember, existing drivers would need modification in _any_ case to make use of a returned error code, so the argument that we'd need to touch every driver doesn't really stand up. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up