Received: by 2002:ab2:6991:0:b0:1f7:f6c3:9cb1 with SMTP id v17csp1100674lqo; Thu, 9 May 2024 05:02:19 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWv2UMNyy7UTfvCirqpXpFJg9nOfwUkc73ewBbiLdQ/7NO1P1abbGEWlJh4iA3381zPUp5fuXYgsx+12/0ZltO9+fev2JJ0WNczJ7UsAg== X-Google-Smtp-Source: AGHT+IG6x8no5SLqDN1UcEW0oF4zJCE2nvoHkqobzH/YXQt6ErXCDR72iDCYNFlEEC5alcYHwevb X-Received: by 2002:a17:902:d4c6:b0:1e9:519:d464 with SMTP id d9443c01a7336-1eeb099379cmr62972635ad.65.1715256138727; Thu, 09 May 2024 05:02:18 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1715256138; cv=pass; d=google.com; s=arc-20160816; b=WSzv8H9NFaOwcT2wdDybiG85IgpcElBJb5DmilFJyMIP3/+L0f51AFwrq0g30NZ4YA kU/4ytcOAxeA65n9V6IO3KdveaCfrH75gWff8l4MdH7MBwPG7NG1W5Kb+2Y3isAr4Rny JPKT0ko35390La4UAsY1ukr9TXA+/vzNvHUL3GxBw34qhw8cI1zALWHH9tLiHvhk6enQ 0AQnrT+5v06c4Bm7KLhBNyc7SjwuvRTo/UE5zX5Tv0vKT0oskyNX0sloAzoBCOGqAZK5 vVvCLRfn5y1hML3C6/wkTyrWYYLWymdyYjQooVh8QrgLdYG8/1Mdu/SDxyR1QYtiQILq nCKA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:references :message-id:subject:cc:to:from:date; bh=QXydRQK2hd97r4QfdIZV5NUri6+XgrjmwdtEZTDxDT4=; fh=HvfRelBnSbg3EQsbMKizmkuAE3oIZZhcXz5JvvafszY=; b=w4TeRqjT1YTNLO8A1DbIKZKRJo4mTmixugXXid1PaGaCm+qwxRwUaNsM4pScurvWGY DNz6atH85PWxItQz7c6xVopZyqvzUwofLTnKRHXayOcrBlybXNeII3mRqYm9wuTgGvKc ivMx3q3ik/Jcn/q0826BLMffathe4WTIPANgxelhuaRmfqBb5lPhrQOVWygakzH4mmEd 2R2KKuwlJXgHbE3N9X/0udxF65c/L2jmRTlJPB5wc1XGyU8OJCkSfuaRLgme0PmJ2cca yGy7JZHMafeirg1ANcrGXj8Q8QmfvFdpQFYeVQBwp0G37tl2pUNJ9xciuqfmX4QRUTVQ GoUA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=lst.de); spf=pass (google.com: domain of linux-kernel+bounces-174462-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-174462-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id d9443c01a7336-1ef0c15747fsi13843195ad.492.2024.05.09.05.02.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 May 2024 05:02:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-174462-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=lst.de); spf=pass (google.com: domain of linux-kernel+bounces-174462-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-174462-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 55BFC282F63 for ; Thu, 9 May 2024 12:02:18 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CDC3A14B958; Thu, 9 May 2024 12:02:05 +0000 (UTC) Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E0F726ACD; Thu, 9 May 2024 12:02:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.11.211 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715256125; cv=none; b=AWrIq+pWWkJ7B+OyxgfExpfgaZTYRlhVzUyp3OVBne3YoGzzsnHQdKYuullM/y1NFLo7Arg9Vn8qIdmHjyEz6syvbMHZ+yW0pvnXso3HSgZGmH7mMzvy+CN3myK8OW6o+o/Kubuag7CKESTNw7dKtm5cW+AqrHMEUln1jOte8LM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715256125; c=relaxed/simple; bh=QXydRQK2hd97r4QfdIZV5NUri6+XgrjmwdtEZTDxDT4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=S5W9+npXlxrIo+6QyYB7K5GCSik5exWmsVfG05Tc8KG4/nXLK4kfhIoUxMqw83LMlrvh2TrdCjFgrdJ6HgYisuO8aQYioSTOSBhn0PxoYn+pD0G0YEqJU2hp+uYpR8qtMF6Cvh5FKaHwJRgoJAQ6+1wx4woMRgTZWGnw1ag1RPI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de; spf=pass smtp.mailfrom=lst.de; arc=none smtp.client-ip=213.95.11.211 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lst.de Received: by verein.lst.de (Postfix, from userid 2407) id 53745227A87; Thu, 9 May 2024 14:01:50 +0200 (CEST) Date: Thu, 9 May 2024 14:01:49 +0200 From: Christoph Hellwig To: Alexander Lobakin Cc: Marek Szyprowski , Christoph Hellwig , Eric Dumazet , Jakub Kicinski , Robin Murphy , Joerg Roedel , Will Deacon , "Rafael J. Wysocki" , Magnus Karlsson , nex.sw.ncis.osdt.itp.upstreaming@intel.com, bpf@vger.kernel.org, netdev@vger.kernel.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 2/7] dma: avoid redundant calls for sync operations Message-ID: <20240509120149.GA11327@lst.de> References: <20240507112026.1803778-1-aleksander.lobakin@intel.com> <20240507112026.1803778-3-aleksander.lobakin@intel.com> <46160534-5003-4809-a408-6b3a3f4921e9@samsung.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) On Thu, May 09, 2024 at 01:44:37PM +0200, Alexander Lobakin wrote: > If I remember correctly, *all* device drivers which use DMA *must* call > dma_set_*mask() on probe. That's why we added it there and didn't care. > Alternatively, if it really breaks a lot of drivers, we can set > dma_need_sync = true by default before the driver probing. I thought of > this, but the correct approach would be to call dma_set_*mask() from the > respective drivers. No, we default to 32-bit DMA for a lot of busses for historical reasons, especially platform devices.