Message ID | 20231114135553.32301-5-johan+linaro@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b909:0:b0:403:3b70:6f57 with SMTP id t9csp1874257vqg; Tue, 14 Nov 2023 05:57:27 -0800 (PST) X-Google-Smtp-Source: AGHT+IE+jDuPgrNMElGXyoJyYACgxObNfPK3G8R4/Og01A+PjBhA2YTTx8N4eLDS6qhaITlbyXHP X-Received: by 2002:aa7:80d3:0:b0:68a:5cf8:dac5 with SMTP id a19-20020aa780d3000000b0068a5cf8dac5mr8622571pfn.22.1699970246507; Tue, 14 Nov 2023 05:57:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699970246; cv=none; d=google.com; s=arc-20160816; b=GvoDGNZsW+7Lp97Pzz/vsAQxoOXeBk5cWbu3nXFaPVncNhpTzPCl103TfV7mgzuJcT kfEBzwa0ZvlPSNevNcL7yOxfrb/ohMgn3w7xGl3KDpDZflRSpoNSv+7o5SWETjb2tRCW OOMVIzXbrxxCaDrYx6oHiAr6L8D+bgG64bJQ7KOb4X8ssHGXTqUSY0ru96YJDuoHrTR9 dt1WKgabv2ZEO5SjJmlhRGlrAImmHpGNa8EcrB80q8OFs3yf+kLoghHysi3Ij60g5T2m j1ohRk7o1sgLdcDQBBrdP65f2Q5CLzu9sqmD0gSB0dgP/NNZJtAEwZ9wRVFXXeou6mPk jzcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=zDhCmhNHfQ8qVj7GG45UUzzgMpAbsamT3vaWF2nmJdI=; fh=+l5nuMYZGgX4mkGKX/kANxC8looYmFXq90w07M/6BcI=; b=p8h3AtZDX/mdGx4h08r9FgR6G2nOz7uLhmQyI35qlnwGJpeyLCmwQ/cLs2Y3gIN0Tp LWgqvIehuu4uO+lZiefeDG9quHRlkDsAlyl+WjsKMyrmadRaBZJXaMg53TZc6OIeMxH4 7lnEBIwKLKdyPlJZ/gyx0wX1ZNtS21rd3yF5hHTimOXy3rP7t9LR9BPqD4pOxtcevCPG 0j8kUmo3eox44RZTrKm1irEyl/ZZgUmxsRDLIGYVaZKFDyxN3KbZR9YZAazbZIPvifbT 8YUObCk0ee0VO9NSpGtd50GG0Ewcqo3+kDcdF5BYmFYGMgbbthqs9qyg08XN4NsFE23H w6ig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="hvzgQs4/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id fj41-20020a056a003a2900b006c339527ab8si7885839pfb.192.2023.11.14.05.57.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Nov 2023 05:57:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="hvzgQs4/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 31581804E7B3; Tue, 14 Nov 2023 05:56:49 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232904AbjKNN4o (ORCPT <rfc822;lhua1029@gmail.com> + 29 others); Tue, 14 Nov 2023 08:56:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232027AbjKNN4j (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 14 Nov 2023 08:56:39 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 20F5FD50; Tue, 14 Nov 2023 05:56:34 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B15D0C433CD; Tue, 14 Nov 2023 13:56:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1699970193; bh=eo9kfCbX6q6KqiGf0IQeZw8TC/sg5ZoML6hbCiQxCyA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hvzgQs4/9S5RUfSUDfl+ZBXj8xB4XpWCi1gh6wnZMfzRCKuYG5KTLn6y4h4DuADRA oCa5tYe+ekj/mzp5YSjsWpZ2ILuTsBhlr/KuBHdZlMyxnxNTWg9sYZwd2yJEqavC0/ LsJfY+IPxeWYpZcBJvx/XVnxsriQqgUo9bFQkTqvoJq4RKZA2xsFGNjt2z+k84xlSN qeOlTdksrKdZc1Az0YZoHAso558mOYRAKeudnfYMQ77IAKelqIDXCMQNqIj28cKbNm E1OSs/RawbAUAJ2Nym5MugY8Gubl6pA7BUIyiiUdKscX5F3dMO5qEgjIB3NCp7TBeO WgnjHWVXRD1Lg== Received: from johan by xi.lan with local (Exim 4.96.2) (envelope-from <johan+linaro@kernel.org>) id 1r2tu2-0008PV-2s; Tue, 14 Nov 2023 14:56:30 +0100 From: Johan Hovold <johan+linaro@kernel.org> To: Lorenzo Pieralisi <lpieralisi@kernel.org>, =?utf-8?q?Krzysztof_Wilczy?= =?utf-8?q?=C5=84ski?= <kw@linux.com>, Bjorn Helgaas <bhelgaas@google.com> Cc: Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Manivannan Sadhasivam <mani@kernel.org>, Rob Herring <robh@kernel.org>, Nirmal Patel <nirmal.patel@linux.intel.com>, Jonathan Derrick <jonathan.derrick@linux.dev>, linux-arm-msm@vger.kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Johan Hovold <johan+linaro@kernel.org> Subject: [PATCH 4/6] PCI: qcom: Clean up ASPM comment Date: Tue, 14 Nov 2023 14:55:51 +0100 Message-ID: <20231114135553.32301-5-johan+linaro@kernel.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20231114135553.32301-1-johan+linaro@kernel.org> References: <20231114135553.32301-1-johan+linaro@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 14 Nov 2023 05:56:49 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782548001008446685 X-GMAIL-MSGID: 1782548001008446685 |
Series |
PCI: Fix deadlocks when enabling ASPM
|
|
Commit Message
Johan Hovold
Nov. 14, 2023, 1:55 p.m. UTC
Break up the newly added ASPM comment so that it fits within the soft 80
character limit and becomes more readable.
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
---
drivers/pci/controller/dwc/pcie-qcom.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Comments
On Tue, Nov 14, 2023 at 02:55:51PM +0100, Johan Hovold wrote: > Break up the newly added ASPM comment so that it fits within the soft 80 > character limit and becomes more readable. > > Signed-off-by: Johan Hovold <johan+linaro@kernel.org> I think we discussed (80column soft limit for comments) in the past, but I don't think breaking here makes the comment more readable. - Mani > --- > drivers/pci/controller/dwc/pcie-qcom.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c > index 21523115f6a4..a6f08acff3d4 100644 > --- a/drivers/pci/controller/dwc/pcie-qcom.c > +++ b/drivers/pci/controller/dwc/pcie-qcom.c > @@ -969,7 +969,10 @@ static int qcom_pcie_post_init_2_7_0(struct qcom_pcie *pcie) > > static int qcom_pcie_enable_aspm(struct pci_dev *pdev, void *userdata) > { > - /* Downstream devices need to be in D0 state before enabling PCI PM substates */ > + /* > + * Downstream devices need to be in D0 state before enabling PCI PM > + * substates. > + */ > pci_set_power_state(pdev, PCI_D0); > pci_enable_link_state_locked(pdev, PCIE_LINK_STATE_ALL); > > -- > 2.41.0 >
On Fri, Nov 17, 2023 at 04:02:27PM +0530, Manivannan Sadhasivam wrote: > On Tue, Nov 14, 2023 at 02:55:51PM +0100, Johan Hovold wrote: > > Break up the newly added ASPM comment so that it fits within the soft 80 > > character limit and becomes more readable. > > > > Signed-off-by: Johan Hovold <johan+linaro@kernel.org> > > I think we discussed (80column soft limit for comments) in the past, but I don't > think breaking here makes the comment more readable. The coding style clearly states: The preferred limit on the length of a single line is 80 columns. Statements longer than 80 columns should be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information. Going beyond 80 chars may sometimes be warranted for code, but the exception is not intended for comments. Johan
On Fri, Nov 17, 2023 at 11:48:10AM +0100, Johan Hovold wrote: > On Fri, Nov 17, 2023 at 04:02:27PM +0530, Manivannan Sadhasivam wrote: > > On Tue, Nov 14, 2023 at 02:55:51PM +0100, Johan Hovold wrote: > > > Break up the newly added ASPM comment so that it fits within the soft 80 > > > character limit and becomes more readable. > > > > > > Signed-off-by: Johan Hovold <johan+linaro@kernel.org> > > > > I think we discussed (80column soft limit for comments) in the past, but I don't > > think breaking here makes the comment more readable. > > The coding style clearly states: > > The preferred limit on the length of a single line is 80 columns. > > Statements longer than 80 columns should be broken into sensible chunks, > unless exceeding 80 columns significantly increases readability and does > not hide information. > > Going beyond 80 chars may sometimes be warranted for code, but the > exception is not intended for comments. > Breaking the comment here is indeed making it hard to read. It's just one word that needs to be broken if we go by 80 column limit and I won't prefer that, sorry! - Mani > Johan
On Fri, Nov 17, 2023 at 04:24:04PM +0530, Manivannan Sadhasivam wrote: > On Fri, Nov 17, 2023 at 11:48:10AM +0100, Johan Hovold wrote: > > On Fri, Nov 17, 2023 at 04:02:27PM +0530, Manivannan Sadhasivam wrote: > > > On Tue, Nov 14, 2023 at 02:55:51PM +0100, Johan Hovold wrote: > > > > Break up the newly added ASPM comment so that it fits within the soft 80 > > > > character limit and becomes more readable. > > > > > > > > Signed-off-by: Johan Hovold <johan+linaro@kernel.org> > > > > > > I think we discussed (80column soft limit for comments) in the past, but I don't > > > think breaking here makes the comment more readable. > > > > The coding style clearly states: > > > > The preferred limit on the length of a single line is 80 columns. > > > > Statements longer than 80 columns should be broken into sensible chunks, > > unless exceeding 80 columns significantly increases readability and does > > not hide information. > > > > Going beyond 80 chars may sometimes be warranted for code, but the > > exception is not intended for comments. > > Breaking the comment here is indeed making it hard to read. It's just one word > that needs to be broken if we go by 80 column limit and I won't prefer that, > sorry! Please read the above quote again, it is as clear as it gets. 80 chars is the preferred limit unless (for code) exceeding it *significantly* increases readability, which clearly isn't the case here (even if this exception applied to comments). I really don't understand why you keep insisting on this. Just fix your editor. Johan
On Fri, Nov 17, 2023 at 12:00:44PM +0100, Johan Hovold wrote: > On Fri, Nov 17, 2023 at 04:24:04PM +0530, Manivannan Sadhasivam wrote: > > On Fri, Nov 17, 2023 at 11:48:10AM +0100, Johan Hovold wrote: > > > On Fri, Nov 17, 2023 at 04:02:27PM +0530, Manivannan Sadhasivam wrote: > > > > On Tue, Nov 14, 2023 at 02:55:51PM +0100, Johan Hovold wrote: > > > > > Break up the newly added ASPM comment so that it fits within the soft 80 > > > > > character limit and becomes more readable. > > > > > > > > > > Signed-off-by: Johan Hovold <johan+linaro@kernel.org> > > > > > > > > I think we discussed (80column soft limit for comments) in the past, but I don't > > > > think breaking here makes the comment more readable. > > > > > > The coding style clearly states: > > > > > > The preferred limit on the length of a single line is 80 columns. > > > > > > Statements longer than 80 columns should be broken into sensible chunks, > > > unless exceeding 80 columns significantly increases readability and does > > > not hide information. > > > > > > Going beyond 80 chars may sometimes be warranted for code, but the > > > exception is not intended for comments. > > > > Breaking the comment here is indeed making it hard to read. It's just one word > > that needs to be broken if we go by 80 column limit and I won't prefer that, > > sorry! > > Please read the above quote again, it is as clear as it gets. 80 chars > is the preferred limit unless (for code) exceeding it *significantly* Where does it say "code" in the Documentation? As I read it, the doc weighs both code and comment as "statement". And how on the world that breaking a single word to the next line improves readability? I fail to get it :/ > increases readability, which clearly isn't the case here (even if this > exception applied to comments). > > I really don't understand why you keep insisting on this. Just fix your > editor. > May you should fix yours to extend the limit to 100? But I do not want to get into a spat here. Checkpatch, the tool supposed to check for the kernel coding style is not complaining and I do not want a patch that _fixes_ a coding style that is not an issue. And I do not want to argue more on this. If the PCI maintainers are comfortable with this patch, they can apply it, but I'm not. - Mani > Johan
On Fri, Nov 17, 2023 at 04:53:52PM +0530, Manivannan Sadhasivam wrote: > On Fri, Nov 17, 2023 at 12:00:44PM +0100, Johan Hovold wrote: > > On Fri, Nov 17, 2023 at 04:24:04PM +0530, Manivannan Sadhasivam wrote: > > > On Fri, Nov 17, 2023 at 11:48:10AM +0100, Johan Hovold wrote: > > > > The coding style clearly states: > > > > > > > > The preferred limit on the length of a single line is 80 columns. > > > > > > > > Statements longer than 80 columns should be broken into sensible chunks, > > > > unless exceeding 80 columns significantly increases readability and does > > > > not hide information. > > > > > > > > Going beyond 80 chars may sometimes be warranted for code, but the > > > > exception is not intended for comments. > > > > > > Breaking the comment here is indeed making it hard to read. It's just one word > > > that needs to be broken if we go by 80 column limit and I won't prefer that, > > > sorry! > > > > Please read the above quote again, it is as clear as it gets. 80 chars > > is the preferred limit unless (for code) exceeding it *significantly* > > Where does it say "code" in the Documentation? As I read it, the doc weighs both > code and comment as "statement". No, comments are not statements (in C). You'd also never even consider interpreting it that way if you knew where that exception comes from (namely that people break long *statements* just to fit under 80 chars, thereby sometimes making the *code* unnecessarily hard to read). > And how on the world that breaking a single word to the next line improves > readability? I fail to get it :/ You got it backwards; you should only go *beyond* 80 chars if it "significantly increases readability". But again, this does NOT apply to comments in the first place. > > increases readability, which clearly isn't the case here (even if this > > exception applied to comments). > > > > I really don't understand why you keep insisting on this. Just fix your > > editor. > But I do not want to get into a spat here. Checkpatch, the tool supposed to > check for the kernel coding style is not complaining and I do not want a patch > that _fixes_ a coding style that is not an issue. Checkpatch is just a tool, not the standard, and knowing when it is ok to break the 80 column rule for code requires human judgement. Johan
diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c index 21523115f6a4..a6f08acff3d4 100644 --- a/drivers/pci/controller/dwc/pcie-qcom.c +++ b/drivers/pci/controller/dwc/pcie-qcom.c @@ -969,7 +969,10 @@ static int qcom_pcie_post_init_2_7_0(struct qcom_pcie *pcie) static int qcom_pcie_enable_aspm(struct pci_dev *pdev, void *userdata) { - /* Downstream devices need to be in D0 state before enabling PCI PM substates */ + /* + * Downstream devices need to be in D0 state before enabling PCI PM + * substates. + */ pci_set_power_state(pdev, PCI_D0); pci_enable_link_state_locked(pdev, PCIE_LINK_STATE_ALL);