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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7DB9CC43334 for ; Tue, 5 Jul 2022 11:58:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231129AbiGEL6X (ORCPT ); Tue, 5 Jul 2022 07:58:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231340AbiGEL6W (ORCPT ); Tue, 5 Jul 2022 07:58:22 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EEF68383; Tue, 5 Jul 2022 04:58:20 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 732D6615BA; Tue, 5 Jul 2022 11:58:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C823CC341C7; Tue, 5 Jul 2022 11:58:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657022299; bh=lCXFzDOu/arhn1E7qbcpYeWsTGXEZM7HRnIjvJuXRQo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ItEhj+54jubFtuMGB8gFICe9Al+h8/22un5trpf08ioiYyvwAhcQzH8J88lV0U0Wk 3kjJoLEbZ999TJifjmeJ2AwV3LE8AGTm5SW8a0VbWS/jRSxWRcs0MgbfYv6I3JUbY5 oWlVK3xxkK0cuX9vrewGjpSUrtKS6NUGwyo5lmGSfYP/Etsm65PW47EAH8KnNNIBAK mbszHYkTs/pjmhQSLifETgm9myld2cOlwWOz7opBpUtW9M9iin29/e2On84my9D0dS iaLLBkRA28pyUz2XF0HEHioDPv/P3pqY+j6u2i3yZtvqyM5Gz223bCAimMTq9WM22o wp5tytzOK0tIg== Received: from johan by xi.lan with local (Exim 4.94.2) (envelope-from ) id 1o8hC7-000679-Jh; Tue, 05 Jul 2022 13:58:20 +0200 Date: Tue, 5 Jul 2022 13:58:19 +0200 From: Johan Hovold To: Dmitry Baryshkov Cc: Krzysztof Kozlowski , Johan Hovold , Vinod Koul , Rob Herring , Krzysztof Kozlowski , Andy Gross , Bjorn Andersson , Kishon Vijay Abraham I , linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 38/43] phy: qcom-qmp-pcie: drop pipe clock lane suffix Message-ID: References: <20220705094239.17174-1-johan+linaro@kernel.org> <20220705094239.17174-39-johan+linaro@kernel.org> <76508b56-6733-b65c-d81c-31ac173780c0@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76508b56-6733-b65c-d81c-31ac173780c0@linaro.org> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, Jul 05, 2022 at 02:13:04PM +0300, Dmitry Baryshkov wrote: > On 05/07/2022 13:20, Krzysztof Kozlowski wrote: > > On 05/07/2022 11:42, Johan Hovold wrote: > >> The pipe clock is defined in the "lane" node so there's no need to keep > >> adding a redundant lane-number suffix to the clock name. > >> > >> Drop the lane suffix from the pipe clock name, but continue supporting > >> the legacy name as a fall back. > >> > >> Signed-off-by: Johan Hovold > >> --- > >> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 8 ++++++-- > >> 1 file changed, 6 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c > >> index 385ea3d8de08..254ad25591b9 100644 > >> --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c > >> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c > >> @@ -2210,8 +2210,12 @@ int qcom_qmp_phy_pcie_create(struct device *dev, struct device_node *np, int id, > >> if (!qphy->pcs_misc) > >> dev_vdbg(dev, "PHY pcs_misc-reg not used\n"); > >> > >> - snprintf(prop_name, sizeof(prop_name), "pipe%d", id); > >> - qphy->pipe_clk = devm_get_clk_from_child(dev, np, prop_name); > >> + qphy->pipe_clk = devm_get_clk_from_child(dev, np, "pipe"); > > > > Just get first clock and no need for handling any deprecation. I still want to deprecate the current name as it makes no sense and risks introducing inconsistencies when adding new resources (e.g. should they also get a bogus suffix). > If I got it correctly, passing NULL instead of the name would do the trick. Ah, thanks for spotting that. I feared this would require adding a host of new devres wrappers otherwise. Would still be needed for the upcoming second pipediv2 clock though... Johan