Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp813914ybl; Fri, 10 Jan 2020 07:10:04 -0800 (PST) X-Google-Smtp-Source: APXvYqwnmhXsb9cvTjlha10qN3UBGx7LRoE4VUlh5WIrbxUfxayTs5EXdg9XGMMgM7fHPbDlXdK1 X-Received: by 2002:a9d:68d3:: with SMTP id i19mr2756797oto.71.1578669004441; Fri, 10 Jan 2020 07:10:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578669004; cv=none; d=google.com; s=arc-20160816; b=BCvbZMuWDmnoOpCicqVTmOzEAs8HkVLb5BFz2MtV1KFPc8MbLgfgM2NgjWRjPRu808 TieTT3gBp+AZjpEOJl6R5aKEo+DwLZi166ExBh2dQ40/w1teOAAbU8o1NT6fCIUWbUOc 7a71b5maQBBnkPpmJjVPYzsJh01SgPklYUL+4esZbsYxNDeVjXTBX9SJ3aWHL/LzkYn/ 28idFW02yxOvJOdBnCnRm2WmLVhaeMQpBI13L32nbTwZYgX6RjBSWpS9qhilKJ4tgyye /Wirvqascgy1zzJP0dvLw2NimvjayhFe7UV17pAF4qF1ijqe/5+kCqZ9sMV81iMwjI3E y9rw== 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:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=jG+59M06ad7oqvl0No7G916efr9Yoh+bNJduRm0MS1o=; b=0GgTh/xoA9RBlVcjL7440yPTESrdhnMyWec6QGCT97dafvob7650txJrA9FuVi0fNC uJ3q2lJKY3E4tPajj8XxzSQ+VBRZzt7mdlPmnfdb/swxwNNgseRNQxDXiaWolANM81bn 8QPDzigi9fWduyCFWzP4euo0D3R2MidDs+XMvOaAYtERNMYTjZDPP+R+5+Vfy5ZO19KA fceppBiY170C7HAlVP3h3rTWaq6iNhiYv0frIjPAZiKW7aHtnzUWmkh4q8aHckBe5gg0 vWflijP8Y+JDmIb2cc+L27KxUYHR8HrbhfUsc2oq5B7qn15KSlQvsMUiFKnNz5g0/P1A KZiw== 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 b12si1404422otl.229.2020.01.10.07.09.50; Fri, 10 Jan 2020 07:10:04 -0800 (PST) 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 S1728289AbgAJPIo (ORCPT + 99 others); Fri, 10 Jan 2020 10:08:44 -0500 Received: from foss.arm.com ([217.140.110.172]:46356 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728152AbgAJPIo (ORCPT ); Fri, 10 Jan 2020 10:08:44 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 15CEA30E; Fri, 10 Jan 2020 07:08:43 -0800 (PST) Received: from donnerap.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EF6973F6C4; Fri, 10 Jan 2020 07:08:41 -0800 (PST) Date: Fri, 10 Jan 2020 15:08:36 +0000 From: Andre Przywara To: Andrew Lunn Cc: "David S . Miller" , Radhey Shyam Pandey , Michal Simek , Robert Hancock , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 12/14] net: axienet: Autodetect 64-bit DMA capability Message-ID: <20200110150836.1f92a0a8@donnerap.cambridge.arm.com> In-Reply-To: <20200110142250.GH19739@lunn.ch> References: <20200110115415.75683-1-andre.przywara@arm.com> <20200110115415.75683-13-andre.przywara@arm.com> <20200110140852.GF19739@lunn.ch> <20200110141303.2e5863ab@donnerap.cambridge.arm.com> <20200110142250.GH19739@lunn.ch> Organization: ARM X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; aarch64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 10 Jan 2020 15:22:50 +0100 Andrew Lunn wrote: Hi, > On Fri, Jan 10, 2020 at 02:13:03PM +0000, Andre Przywara wrote: > > On Fri, 10 Jan 2020 15:08:52 +0100 > > Andrew Lunn wrote: > > > > Hi Andrew, > > > > thanks for having a look! > > > > > > To autodetect this configuration, at probe time we write all 1's to such > > > > an MSB register, and see if any bits stick. > > > > > > So there is no register you can read containing the IP version? > > > > There is, and I actually read this before doing this check. But the 64-bit DMA capability is optional even in this revision. It depends on what you give it as the address width. If you say 32, the IP config tool disables the 64-bit capability completely, so it stays compatible with older revisions. > > Anything beyond 32 will enable the MSB register and will also require you to write to them. > > So you are saying there is no way to enumerate the synthesised > configuration of the IP. Great :-( Apparently not. > Do Xilinx at least document you can discover the DMA size by writing > into these upper bits? Does Xilinx own 'vendor crap' driver do this? So far I couldn't be bothered to put my asbestos trousers on and go into BSP land ;-) Now quickly browsing the linux-xlnx github repo suggests they make this MSB register access dependent on CONFIG_PHYS_ADDR_T_64BIT. Which would mean: - A 32-bit kernel on a device configured for >32 bit DMA would not work. - They always write to the MSB registers on 64-bit and (L)PAE kernels. The DMA mask is set to the value of the xlnx,addrwidth, in a similar way I did it in the next patch. Minus the safety check for the 64-bit DMA capability. I got this idea of probing when I saw that those registers are marked as "Reserved" in earlier revisions of the documentation. I couldn't find an exact definition of "Reserved" in that manual, though. Then I confirmed that behaviour by testing this on an image configured for only a 32 bit wide address bus, where those registers are apparently hardwired to zero. So if you were hoping for an official blessing, I have to disappoint you ;-) We could rely completely on the addrwidth property, at the price of it not working when the IP is configured for >32 bits, but the addrwidth property is missing or erroneously set to 32. But I think their: struct xxx { .... phys_addr_t next; /* Physical address of next buffer descriptor */ #ifndef CONFIG_PHYS_ADDR_T_64BIT u32 reserved1; #endif construct is broken, and we should not copy this. Also they do writeq to this register, not sure that's the right thing to do. Cheers, Andre.