Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp2307228pxu; Sat, 17 Oct 2020 20:39:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy5kJHiPdoKHw1sKJV+31ffziA6DKVBv++EPTIYc6BhLZmUV+xM+6+sEOzr0y3WmVrTZx7n X-Received: by 2002:a17:906:4c4c:: with SMTP id d12mr5129554ejw.299.1602992357679; Sat, 17 Oct 2020 20:39:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602992357; cv=none; d=google.com; s=arc-20160816; b=XY1UjtyqQyjFTQxkJzI4ZmW+mi/owpr5yjFggAGIpPsoiXBRRyupT7L0eoHteStJPZ oM5TRmtmov+OzjfSdZcwXeqwupuhBqCX/nmQk0Y0IqASnzkLCICh3hvb02/ZIN6qE6uI mqQp78TyYXZwvW7gFA2AU5DGGii9p3cehZSEJAgW853KAraBRovgko0dzQjekgdB3Lsq JOT4j4Jj4Xu6GRfacgi1TksbDJad8cEfa4B3lD7sjdOMlpkeUVmVpprma/4L5nrZLDK0 GJ6FTKOOSDE3ukIkiL6nvWCi/inj3yktUiNy4tH96HSB5YW3PspaoiAwdO8FKzbscYEA znTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=U/In3q0l6Pa5JAdbXQagpan98xDL74rNNlbQWM0J3X4=; b=VqrZJEq/00hpKUyx6hge1+GnVPjgf8hwN+gpgxXxRIu+EESYUUtT22DfrvB2XguRE8 Ko2/aY+rHhB9utRXdQIIqPrukAI/mspYBQrNfnPc5JROJmmyha+oqwerQjSbUZNGe3+0 L3f+5+XHKLYY63t0+60fODodfYPfnv/QJP0JVHuEa3SarqK+mis7xrLI3z31iXZvwi5O vaUHzXYNcfC//mlEL5V+Z+8RyvNtd/UEDIABeuHpEBu/rx2EAHIP/hQsPJ5hi0a4Sx4B sr7KhbyQmQezHo+ZdODFTkX55TjW5RWNul4IeW3vSeXpD11+JMGNhfrvLZG4XQ2iTpyq gf3Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id se8si4991706ejb.251.2020.10.17.20.38.54; Sat, 17 Oct 2020 20:39:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2440112AbgJRCKL (ORCPT + 99 others); Sat, 17 Oct 2020 22:10:11 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:15754 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2440101AbgJRCKL (ORCPT ); Sat, 17 Oct 2020 22:10:11 -0400 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 42E6015C4A072DBDADB7; Sun, 18 Oct 2020 10:10:06 +0800 (CST) Received: from [127.0.0.1] (10.174.177.134) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.487.0; Sun, 18 Oct 2020 10:10:04 +0800 Subject: Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges To: Florian Fainelli , Arnd Bergmann CC: Rob Herring , Ray Jui , "Scott Branden" , bcm-kernel-feedback-list , Andy Gross , Bjorn Andersson , linux-arm-msm , devicetree , linux-arm-kernel , linux-kernel References: <20201016090833.1892-1-thunder.leizhen@huawei.com> <20201016090833.1892-2-thunder.leizhen@huawei.com> <0eee3fd2-7400-7de7-27a7-7fcaa0955854@gmail.com> From: "Leizhen (ThunderTown)" Message-ID: Date: Sun, 18 Oct 2020 10:10:03 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <0eee3fd2-7400-7de7-27a7-7fcaa0955854@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.134] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/10/17 3:27, Florian Fainelli wrote: > On 10/16/20 11:23 AM, Arnd Bergmann wrote: >> On Fri, Oct 16, 2020 at 6:48 PM Florian Fainelli wrote: >>> On 10/16/20 4:01 AM, Arnd Bergmann wrote: >>>> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei wrote: >>>>> >>>>> Suggested-by: Arnd Bergmann >>>>> Signed-off-by: Zhen Lei >>>> >>>> Acked-by: Arnd Bergmann >>>> >>>> I see that at least the 'bcd' and 'xhci' devices in fact try to >>>> use 64-bit DMA. It would be good to test this on actual >>>> hardware to ensure that it works correctly when this is enabled. >>>> >>>> Ideally avoiding the swiotlb bounce buffering should only >>>> make it faster here, but there are many chips on which >>>> 64-bit DMA is broken in some form. >>> >>> Is this change really an improvement though? This 'usb' pseudo bus node >>> could just keep being defined with #address-cells = <1> and #size-cells >>> = <1> so as to satisfy the 'reg' definition however we could just adjust >>> dma-ranges to indicate full 64-bit addressing capability. Would not that >>> work? >> >> When #address-cells is '1', you cannot specify dma-ranges that >> go beyond a 32-bit address range. > > Would not it be enough to remove the 'dma-ranges' property though? Sorry > for being slow here. Remove the 'dma-ranges' property should also work. After all, it is equivalent to the original empty dma-ranges scheme. In addition, since the IOMMU nodes are defined, it should be enabled. Therefore, Arnd's concern about the scenario where the IOMMU is disabled may not be triggered. All roads lead to Rome. Which solution should be chose depends on individual preferences. For me, either solution is fine. The third solution is to define a non-empty dma-ranges property. However, because stingray-usb.dtsi is included in multiple files, it may not be appropriate. >