Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp894030imm; Wed, 11 Jul 2018 12:55:39 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcXuBDtejx2KDvTRwETy52DcjHOUvxSc9As0EW6zzdOQW4R4QXtHEMKnc5j1p+T6Ix7cUBO X-Received: by 2002:a63:524e:: with SMTP id s14-v6mr24416pgl.35.1531338939524; Wed, 11 Jul 2018 12:55:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531338939; cv=none; d=google.com; s=arc-20160816; b=ZGSAKfDhMiY4/6b5eYHye5lhAdLcvePEkl0ylee83VKhVQZNZxvh82CEl0eZn6VVGv gmzvtIj7oRoiaARAeLX30J8kBo5z9wZPQk8hHXvc1u6gJDEgQZq7NlKqfKrroFVV+Mnp vq2Iq3KMph333M9nfFjObs0LY5gm/savIE1FakegOHT12UOtyfJYsbjmb0kWRRsmOzb3 /5QKGWKr4y9GUXZ1/45sDeq4qobfC34KUVRGDKWGoN6oab1nASHzSzSndtpd6xSjxfBf IsokxaNYr1qMem/X1WouaeR8G0aGjkW8//L41u13SYCAXXzea6ZbmaFVNzcZzGvpU6jP oJug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=Kq140k9nw/3YmiLGuOjqj2+s7j6ekk5/8nAfTboh+9o=; b=xo5GsRlhkfBFF34ODUb/a4N51THrkk4aIrS0hC0BUEfSRylAO9O8/Nh9aYnLy8bQMp i5cneEmHK3/7AAeLrt9Y0F83wI4x3J8omye/yz8e6m/EwkUqrcAiUz8NPYezQGXYZWv8 K0cVHHsfIF7PP9Sct2HQ/bENqpHRClWkZwSD35nA6/KvtPSQcEhFT3v7rEhKwzfqwNER O8kEy5y3XiOc7RdEcUlrgWDEdefDg5BgcPgycvh7hzcsg1nVKqRcWksXn/M7rWguflTR b2oQ9raLvQ5G5lDrEOrEnwODNu3+FbraCFgRxQdzaL6EzC7cml2Bcmd5tuMJbO01TXeG 0xcA== 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 9-v6si19363973pgu.130.2018.07.11.12.55.24; Wed, 11 Jul 2018 12:55:39 -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 S1726818AbeGKSJ0 (ORCPT + 99 others); Wed, 11 Jul 2018 14:09:26 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:41296 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726395AbeGKSJ0 (ORCPT ); Wed, 11 Jul 2018 14:09:26 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 680E580D; Wed, 11 Jul 2018 11:03:58 -0700 (PDT) Received: from [10.1.210.23] (e110467-lin.cambridge.arm.com [10.1.210.23]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9A7A53F589; Wed, 11 Jul 2018 11:03:56 -0700 (PDT) Subject: Re: [RFC PATCH 2/4] ACPI/IORT: Set bus DMA mask as appropriate To: Christoph Hellwig Cc: devicetree@vger.kernel.org, gregkh@linuxfoundation.org, x86@kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org, robh+dt@kernel.org, sudeep.holla@arm.com, frowand.list@gmail.com, linux-arm-kernel@lists.infradead.org References: <20180710180458.GC26285@lst.de> From: Robin Murphy Message-ID: Date: Wed, 11 Jul 2018 19:03:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180710180458.GC26285@lst.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/07/18 19:04, Christoph Hellwig wrote: > On Tue, Jul 10, 2018 at 06:17:17PM +0100, Robin Murphy wrote: >> When an explicit DMA limit is described by firmware, we need to remember >> it regardless of how drivers might subsequently update their devices' >> masks. The new bus_dma_mask field does that. > > Shouldn't we also stop presetting the dma mask after this? I guess initialising the device masks here only really has any effect if drivers fail to set their own, so if we're getting stricter about that then it would make sense to stop; I'll add a couple of patches on top to clean that up. Robin.