Received: by 2002:ac0:e34a:0:0:0:0:0 with SMTP id g10csp642796imn; Tue, 26 Jul 2022 05:50:40 -0700 (PDT) X-Google-Smtp-Source: AGRyM1u2gsE9zkheO5O3FF/ErwsCkEUbVuYe5IQ4/l5Lf5pEUq5iC6dU5iJXbVyRzX+3o2NpWifx X-Received: by 2002:a05:6402:5201:b0:43b:f621:3ce0 with SMTP id s1-20020a056402520100b0043bf6213ce0mr11416060edd.22.1658839840584; Tue, 26 Jul 2022 05:50:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658839840; cv=none; d=google.com; s=arc-20160816; b=VtRoIHViCbLuzF21F4lXwAmmIpGg/FSACTFqrQ70fcJgHn99hJJHym4cxIi4NBhhhv kKzzSOSnxLEOqohLucYG2G/jYFudFAArbKGljhCxMhV8fA12tZWLBelRQhx3Qti+GVgk XwfQYnkKrvVAfmuBRgeuvopUZcTXfhj3Z3NgrQ03DhLAkqqOtA8JkQpBfLGA5TxgYSU9 SufvgzJimFV8mit+vTQ71QsGxWG5wgPWz+lZaUcdjreT4UPps7toQSgPZf87dzBzwx6w D6n5pqykAxcMX+pzKMrkup4DSk49JlsqzqTrFu/exVsnvBurp2b3/bybk00WpaVjR45g g89w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=tEkYIKVAYKq6cK8xiVSLAYvisODRYZlhu5tyIBCqe8c=; b=hdP34UhMAhqJv77aRZkXqs/QvO+MwXmvLauG0ex4MNFPgv5wAmGre3KV/3iu93jEXF USnJuENTmKkcUmrqwzweSyzYOEgllEohyS0sdqDBK7VH4ApPhiT1ZbX7yZF9zKDW4MfO A2dmVZItJyq3SuFbR+QXyCBK02Awg8RjoJstKRSqdq9+MRQUDMapJKvKlVUdcHw0neBy 6MTwEQCAEVCxxq0UAzp3OdoftCrSrYjFjsHKxeMHJyds6/6o5BUEbgsZAIuy5qwsj+zG 45xopQS2L1T7yY0m0ay30yHX5qvM6MLIyrS0lUxxt+6qgb2ls8PSOZbP1j67v34aurh7 NRqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=GoiM3xMT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gt13-20020a1709072d8d00b0072b40e36341si18264817ejc.748.2022.07.26.05.50.15; Tue, 26 Jul 2022 05:50:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=GoiM3xMT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238768AbiGZMp2 (ORCPT + 99 others); Tue, 26 Jul 2022 08:45:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231395AbiGZMp0 (ORCPT ); Tue, 26 Jul 2022 08:45:26 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EFECD63D5; Tue, 26 Jul 2022 05:45:25 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 95E40B8161C; Tue, 26 Jul 2022 12:45:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30EB0C341C0; Tue, 26 Jul 2022 12:45:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658839523; bh=PBX3dV218ic0+bWKkpW7iYkXLpgYrw64ydn8N4ZfCAc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GoiM3xMTQq7JdhwEgWjjNZDZWIDGmKY8y47toVe48DCFZjAYfRfCgP8oXti+ortc5 4epbacqlcH3HYngHb3rNqKgPAODeCt3xAAmqz/qCrzqMwGMfa66nVYjvbjIV+ojYzS 098CpGeZKtl/E5KKtO7C/8cqdTldAvMrM0CbrfDmdHUXin2iwO7WBOJcmwxYCe6QQm /5q+I8tM093PDlRFGF/q8J2AncJkYjrXck8eSRrAAUrejVB5Fb2lf18qdmGDY9P2FE 27x23T/INpin8++hGf8EuexBvTImQY/jBnOg6EWSvl+J6j6ti7pjYLjJT32XxYUWZD /3HkhcetH8NuQ== Received: from johan by xi.lan with local (Exim 4.94.2) (envelope-from ) id 1oGJwM-0001MH-8L; Tue, 26 Jul 2022 14:45:34 +0200 Date: Tue, 26 Jul 2022 14:45:34 +0200 From: Johan Hovold To: Bjorn Helgaas Cc: Stanimir Varbanov , Andy Gross , Bjorn Andersson , Lorenzo Pieralisi , Rob Herring , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Johan Hovold , Selvam Sathappan Periakaruppan , Baruch Siach , Dmitry Baryshkov , Robert Marko , Christian Marangi , linux-arm-msm@vger.kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Bjorn Helgaas Subject: Re: [PATCH 2/2] PCI: qcom: Sort variants by Qcom IP rev Message-ID: References: <20220722154919.1826027-1-helgaas@kernel.org> <20220722154919.1826027-3-helgaas@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220722154919.1826027-3-helgaas@kernel.org> X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 22, 2022 at 10:49:19AM -0500, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > Previously the variant resource structs, ops, etc., were in no obvious > order (mostly but not consistently in *Synopsys* IP rev order, which is not > reflected in the naming). > > Reorder them in order of the struct and function names. No functional > change intended. > > Signed-off-by: Bjorn Helgaas > --- > drivers/pci/controller/dwc/pcie-qcom.c | 732 ++++++++++++------------- > 1 file changed, 366 insertions(+), 366 deletions(-) > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c > index c27e3494179f..d0237d821323 100644 > --- a/drivers/pci/controller/dwc/pcie-qcom.c > +++ b/drivers/pci/controller/dwc/pcie-qcom.c Moving code around like this makes code forensics harder as it messes up git blame. At least the callbacks appears to be grouped by IP version currently, so not sure how much you gain from moving the callbacks around. On the other hand, it looks like the patch doesn't touch the revision I currently care about, so your call. > -/* Qcom IP rev.: 2.1.0 Synopsys IP rev.: 4.01a */ > -static const struct qcom_pcie_ops ops_2_1_0 = { > - .get_resources = qcom_pcie_get_resources_2_1_0, > - .init = qcom_pcie_init_2_1_0, > - .post_init = qcom_pcie_post_init_2_1_0, > - .deinit = qcom_pcie_deinit_2_1_0, > - .ltssm_enable = qcom_pcie_2_1_0_ltssm_enable, > -}; Similar problem with git blame here, but at least this seems a bit more warranted as these structs are small enough that you may actually search manually among them. > +static const struct qcom_pcie_cfg sm8150_cfg = { > + /* sm8150 has qcom IP rev 1.5.0. However 1.5.0 ops are same as > + * 1.9.0, so reuse the same. > + */ > + .ops = &ops_1_9_0, > +}; > +static const struct qcom_pcie_cfg sc8180x_cfg = { > + .ops = &ops_1_9_0, > + .has_tbu_clk = true, > +}; > + > static const struct qcom_pcie_cfg ipq8064_cfg = { > .ops = &ops_2_1_0, > }; > @@ -1626,42 +1662,6 @@ static const struct qcom_pcie_cfg sdm845_cfg = { > .has_tbu_clk = true, > }; > > -static const struct qcom_pcie_cfg sm8150_cfg = { > - /* sm8150 has qcom IP rev 1.5.0. However 1.5.0 ops are same as > - * 1.9.0, so reuse the same. > - */ > - .ops = &ops_1_9_0, > -}; > -static const struct qcom_pcie_cfg sc8180x_cfg = { > - .ops = &ops_1_9_0, > - .has_tbu_clk = true, > -}; > - > static const struct qcom_pcie_cfg ipq6018_cfg = { > .ops = &ops_2_9_0, > }; But this bit I disagree with. Why sort the SoCs configurations by IP revision, when what you typically need is to look them up by name? Also note that this conflicts with my sc8280xp-support and IP-revision series: https://lore.kernel.org/all/20220714071348.6792-1-johan+linaro@kernel.org/ The result of applying that series is that these structs are renamed after the IP revision (and sorted alphabetically) so the end-result is similar. Could you consider dropping this patch, or at least the struct qcom_pcie_cfg bits, and applying the above series for 5.20? Or do I need to rebase on top first? Johan