From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 160EDC433EF for ; Thu, 4 Nov 2021 17:27:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E71B061157 for ; Thu, 4 Nov 2021 17:27:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232058AbhKDRad (ORCPT ); Thu, 4 Nov 2021 13:30:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:45922 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231709AbhKDRab (ORCPT ); Thu, 4 Nov 2021 13:30:31 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id E67B961058; Thu, 4 Nov 2021 17:27:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636046873; bh=+05o/sEV+lAerK5i0XMWSi8zPzYOQpDfBy38xWvfnHI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=UDmkZIwPkCgCUGQewQ40yC8kRN6D1V378iVmzuasT5rHGF/0L11gXqhlOMVOgT0Hf jMOTqkkEDbkjaeaJ2N0d+14vatF3l8fWQtIWzNLWfxTMZYBM8AuAN1sdLSrDhZ9Ojh RjfsZqA9IlDH8m67SQTaFZRBhnrXsDYYuAGv0tZqUMXvbNd44nM3G9IDtzinjUlIxy eqLLrQDoqECcioQwMxbisohw685SdUB/qzdlHZTo1JydZv8m5Lh04Z8LuaLLVy5AK2 RBsumDDaHZKcrPolztUdBQveG+juBJHQHNhAFRikqow6q+igXbt/m9Lh5O4sGwguqG S0Q8E5WUfLlxw== Date: Thu, 4 Nov 2021 17:27:46 +0000 From: Mauro Carvalho Chehab To: Rob Herring Cc: Bjorn Helgaas , Lorenzo Pieralisi , Linuxarm , mauro.chehab@huawei.com, Krzysztof =?UTF-8?B?V2lsY3p5xYRza2k=?= , Binghui Wang , Bjorn Helgaas , Xiaowei Song , "linux-kernel@vger.kernel.org" , PCI , Kishon Vijay Abraham I Subject: Re: [PATCH v15 04/13] PCI: kirin: Add support for bridge slot DT schema Message-ID: <20211104172746.4cacf498@sal.lan> In-Reply-To: References: <20211102160612.GA612467@bhelgaas> <20211102174415.58cd3d4f@sal.lan> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Thu, 4 Nov 2021 10:36:52 -0500 Rob Herring escreveu: > On Tue, Nov 2, 2021 at 12:44 PM Mauro Carvalho Chehab > wrote: > > > > Hi Bjorn, > > > > Em Tue, 2 Nov 2021 11:06:12 -0500 > > Bjorn Helgaas escreveu: > > > > > > + > > > > + /* Per-slot clkreq */ > > > > + int n_gpio_clkreq; > > > > + int gpio_id_clkreq[MAX_PCI_SLOTS]; > > > > + const char *clkreq_names[MAX_PCI_SLOTS]; > > > > > > I think there's been previous discussion about this, but I didn't > > > follow it, so I'm just double-checking that this is what we want here. > > > > > > IIUC, this (MAX_PCI_SLOTS, "hisilicon,clken-gpios") applies to an > > > external PEX 8606 bridge, which seems a little strange to be > > > hard-coded into the kirin driver this way. > > > > > > I see that "hisilicon,clken-gpios" is optional, but what if some > > > platform connects all 6 lanes? What if there's a different bridge > > > altogether? > > Keep in mind this is HiKey. There's never been a 2nd board upstream > for the SoCs, the boards have a short lifespan in terms of both > support and availability. And yet Hikey manages to do multiple > complicated things on the board design. I have a hard time caring... > > > > > > > I'll assume this is actually the way we want thing unless I hear > > > otherwise. > > > > Yes, there was past discussions about that with Rob, with regards > > to how the DT would represent it, which got reflected at the code. > > At first I thought these were CLKREQ connections which absolutely > should be per port/bridge like PERST, but they are not. They are > simply enables for the refclk's and pretty specific to HiKey. > > > At the end, it was decided to just add a single property inside PCIe: > > > > > > pcie@f4000000 { > > compatible = "hisilicon,kirin970-pcie"; > > ... > > hisilicon,clken-gpios = <&gpio27 3 0>, <&gpio17 0 0>, > > <&gpio20 6 0>; > > > > I don't think this is a problem, as, if some day another bridge would > > need a larger number of slots, it is just a matter of changing the > > number at the MAX_PCI_SLOTS, as this controls only the size of the array > > (and the check for array overflow when parsing the properties). > > It is a problem that your host bridge driver has hardcoded board > specifics. That's not the first time you've heard that from me. But > given the board-to-soc ratio of Hikey is 1:1, I don't care that much. Ok, understood. Yeah, it sounds unlikely that we would get more boards for Kirin 960/970 with PCI support, as this SoC is used for mobile phones, where neither USB nor PCI bridges are needed. So, AFAIKT, the only the only publicly-available boards that will be using this driver are HiKey 960 and HiKey 970. Regards, Mauro