Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp233508pxb; Mon, 13 Sep 2021 17:54:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxQ4Lx6boXKJU8BJklaP9PqpwG9db6jfTWt5GMwCjWlOpYf22FcvKV4IFmNY9ouzFDzszkt X-Received: by 2002:a05:6402:40c2:: with SMTP id z2mr4890617edb.340.1631580854448; Mon, 13 Sep 2021 17:54:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631580854; cv=none; d=google.com; s=arc-20160816; b=0Gp1roqSRTsU6UmtV0/RdgzTaThSrDXssd20sZPW+D9WcBuHJAT4mMgasJtObVYFuD X8d+vQE6Ca6T9dA22Dbr/kEqq4ZgZBu24gm6nyutuZ5fGThRiLq6vo61kY2T4JGe65pu vG3NvmKzOMsrCnRWhzGZARI3YKtWuIo/r4YtCz2T9g+a2YofszKrHZgLahRHSLh/9P5M N6atDvcNEykO/7FMKpRoQnVLx8cUPJlST464HaTR0mpu8sPTcTR6yFflRTqE0KepYwaN 4mpWilMrzyPTk5EyI/GWtZ/TQLaz+Y5C6TnJA9Bfg7NOPwxwvNKg9VIZmK+DqbmwqhoQ YCEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:references:subject:in-reply-to:cc:to :from:date; bh=udu/aZDqYYWXqgb8mwJN595fkqFynzUevUzE5OX4YmE=; b=pOToE7VWRhZRg6yHnK9gSZM3jck0zjXVObrs/PgPllax2i03qeY8EEajWmfDY4Wgs5 GNLzBU7LTtwh4yMtWAlM8cO8FBu7XBYmeEvv16rt2Fer2E9PRlOckmzXs8pT3dIKKvdI aTnvgtvqozksSHGWSNku8umRMZQvj2NO9J3wmieorgK9xT83cMtaxDvCHCU0TzBJyb+I ogHTuScIfcYzdcqyTXGFc5ySooMprjjqlh46LmlWgE5NQzSnjDIQdvxo0J8fk7qNxS5N kiCu4vx6O4YAHIDv5nKIdyr3OPXylyX7diot/mKzSjb0lv+ZaBUY408YRLOyCN6xROeb nySg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y7si9051441edv.503.2021.09.13.17.53.45; Mon, 13 Sep 2021 17:54:14 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347125AbhIMSgo (ORCPT + 99 others); Mon, 13 Sep 2021 14:36:44 -0400 Received: from sibelius.xs4all.nl ([83.163.83.176]:51929 "EHLO sibelius.xs4all.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241450AbhIMSgn (ORCPT ); Mon, 13 Sep 2021 14:36:43 -0400 Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id 452b42da; Mon, 13 Sep 2021 20:35:23 +0200 (CEST) Date: Mon, 13 Sep 2021 20:35:23 +0200 (CEST) From: Mark Kettenis To: Marc Zyngier Cc: devicetree@vger.kernel.org, alyssa@rosenzweig.io, kettenis@openbsd.org, tglx@linutronix.de, robh+dt@kernel.org, marcan@marcan.st, bhelgaas@google.com, nsaenz@kernel.org, jim2101024@gmail.com, f.fainelli@gmail.com, bcm-kernel-feedback-list@broadcom.com, daire.mcnamara@microchip.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, linux-rpi-kernel@lists.infradead.org In-Reply-To: <871r5tcwhp.wl-maz@kernel.org> (message from Marc Zyngier on Sun, 12 Sep 2021 22:30:42 +0100) Subject: Re: [PATCH v4 4/4] arm64: apple: Add PCIe node References: <20210827171534.62380-1-mark.kettenis@xs4all.nl> <20210827171534.62380-5-mark.kettenis@xs4all.nl> <871r5tcwhp.wl-maz@kernel.org> Message-ID: <5614581066cc67fa@bloch.sibelius.xs4all.nl> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Date: Sun, 12 Sep 2021 22:30:42 +0100 > From: Marc Zyngier Hi Marc, > On Fri, 27 Aug 2021 18:15:29 +0100, > Mark Kettenis wrote: > > > > From: Mark Kettenis > > > > Add node corresponding to the apcie,t8103 node in the > > Apple device tree for the Mac mini (M1, 2020). > > > > Clock references and DART (IOMMU) references are left out at the > > moment and will be added once the appropriate bindings have been > > settled upon. > > > > Signed-off-by: Mark Kettenis > > --- > > arch/arm64/boot/dts/apple/t8103.dtsi | 63 ++++++++++++++++++++++++++++ > > 1 file changed, 63 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/apple/t8103.dtsi b/arch/arm64/boot/dts/apple/t8103.dtsi > > index 503a76fc30e6..6e4677bdef44 100644 > > --- a/arch/arm64/boot/dts/apple/t8103.dtsi > > +++ b/arch/arm64/boot/dts/apple/t8103.dtsi > > @@ -214,5 +214,68 @@ pinctrl_smc: pinctrl@23e820000 { > > , > > ; > > }; > > + > > + pcie0: pcie@690000000 { > > + compatible = "apple,t8103-pcie", "apple,pcie"; > > + device_type = "pci"; > > + > > + reg = <0x6 0x90000000 0x0 0x1000000>, > > + <0x6 0x80000000 0x0 0x4000>, > > Only exposing 16kB for the 'rc' crashes the Linux driver as it tries > to configure the port ref-clock configurations, which live much > higher: > > #define CORE_LANE_CFG(port) (0x84000 + 0x4000 * (port)) > > Previous versions of the binding had this region as 1MB, which made > things work. Oops. When I formalized the binding, I looked at the Apple DT and used the sizes from there. And didn't notice that this wasn't sufficient since U-Boot doesn't actually use the size of the region to create a mapping like an actual OS would do. It is somewhat unclear how big the regions really are, but as marcan noted at some point in the past the sizes in the Apple DT seem to be somewhat inconsistent so religiously following what is done there may not make sense. So I'll fix this in v5 (also in the example in the DT binding). Corellium uses 1MB, which makes more sense unless we break up the block into multiple ranges. > > + <0x6 0x81000000 0x0 0x8000>, > > + <0x6 0x82000000 0x0 0x8000>, > > + <0x6 0x83000000 0x0 0x8000>; > > These used to be 16kB, and are now twice as much. Didn't cause any > issue with the Linux driver, but I wonder what trigger either change. 0x8000 is what the Apple DT uses. Since we don't have authorative documentation for the chip we have to make some guesses here. I suspect we should try to keep the sizes as small as possible while sticking to sizes of 2^n? Then it probably makes sense to use 0x4000 for these ranges. Cheers, Mark