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 7DB91C77B7F for ; Tue, 16 May 2023 13:22:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233433AbjEPNWx (ORCPT ); Tue, 16 May 2023 09:22:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36672 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233071AbjEPNWw (ORCPT ); Tue, 16 May 2023 09:22:52 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBF833A9D; Tue, 16 May 2023 06:22:51 -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 57D7063A0E; Tue, 16 May 2023 13:22:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DAC46C4339C; Tue, 16 May 2023 13:22:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684243370; bh=+sPUthy7aIz73vxHLbcpB1b2jpbwC7HJrTOIMZMo2dE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uPYOuK4MsGdqbnn/xMDKkUnZ4yYcIuyBc3wmFOmWi0M1zulETSYFuwtqUCrDRWI5S wVgIQoGalPhgXBR/I5WssTLKmq6aTcrsCJUtSooWl34gqA1lzOk4MpXdwpQp4uI1ix UxdzERwnISLKF24Av3xmoQrl0qjZ57o4EfWErx8mzgrIZ5TrmzYI5ABlT5e+uuy5rl m5ShpiTBT8U6M4bVGmzempnsCwRwUYC+UX8Dwlya7GJyyjdUslWoAv5UVFoYyEhMEI 2k0EvrnUPDzM8TriF9OikZq4XzzY8CwIj/Z+UQn841ylHadecHfO4QMMpUByPVPigy Qi/cGvspkIySw== Date: Tue, 16 May 2023 18:52:46 +0530 From: Vinod Koul To: Sean Anderson Cc: Kishon Vijay Abraham I , linux-phy@lists.infradead.org, Madalin Bucur , linux-arm-kernel@lists.infradead.org, Camelia Alexandra Groza , devicetree@vger.kernel.org, Rob Herring , linuxppc-dev@lists.ozlabs.org, Bagas Sanjaya , Krzysztof Kozlowski , Ioana Ciornei , Michael Turquette , Stephen Boyd , linux-clk@vger.kernel.org Subject: Re: [PATCH v14 06/15] clk: Add Lynx 10G SerDes PLL driver Message-ID: References: <20230413160607.4128315-1-sean.anderson@seco.com> <20230413160607.4128315-7-sean.anderson@seco.com> <1012f955-180e-0013-cc13-1da10991b5f5@seco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org On 09-05-23, 11:26, Sean Anderson wrote: > On 5/9/23 09:00, Vinod Koul wrote: > > On 08-05-23, 11:31, Sean Anderson wrote: > >> On 5/8/23 05:15, Vinod Koul wrote: > > > >> >> +int lynx_clks_init(struct device *dev, struct regmap *regmap, > >> >> + struct clk *plls[2], struct clk *ex_dlys[2], bool compat); > >> > > >> > so you have an exported symbol for clk driver init in phy driver header? > >> > can you please explain why..? > >> > >> So that it can be called at the appropriate time during the phy's probe function. > >> > >> This is really an integral part of the phy driver, but I was directed to split it > >> off and put it in another subsystem's directory. > > > > That is right clock should be belong to clk driver. IIUC the hardware is > > phy along with clocks and you are doing the clk init. I think that may > > not be correct model, you should really have a device tree node to > > represent the clock and the phy node > > > > > > What stops this from being modelled as it is in the hardware? > > It *is* modeled as it is in hardware. With just the serdes compatible, > we have all the information we need to create the clocks. So we do so. > There's no need for a separate device just to create four clocks. > > These clocks cannot be used by any other device (except possibly by > putting a lane into test mode). So there is no benefit from making them > a separate device, except an increase in complexity due to ordering and > dynamic lookup. By doing things this way we know that either there was > an error or the clocks all exist, and the lifetime of the clocks matches > the serdes. Okay that does makes sense. In that case why should this not be in the phy driver itself. There are already few examples og phy drivers having inbuild clk where is makes sense. You register the clk_ops as part of phy driver Thanks -- ~Vinod 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 283C6C77B7A for ; Tue, 16 May 2023 13:22:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=9rggJbBPKcW05V6QdA485fY18z38C7VWE74FEc6rm7s=; b=hxG3NGN3Hczd75 gyapGHzg5s7po3olpmeCfTjuv1rxwzRzpPyHca+2f0MpFjCx/E32DmuAc7G7TnqCjAtJVdQ5SC5aA Bd23jQw8hRDfrsjQ+A2b891elSzbe3T5iZzdLDIjG5n08yVAsQ74tuJTqQDKAYzQPbgNPpftm6rlB JuIxNc8H26Wl4qvMvPMnHl0oQjnA+U5HrPPRoAiHdVnwrn966cTw9Z3e11mX26yQX3zz7/iP5BTlk OpPtYL9ng5ZnxW9ew7AU44pLOZ71is5moS5vUxsvhCRDYQX7lsNY3BEsd0rW1Xeig1UBmggexFAZ7 wPwLjAreEGwAyN2WUWvQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pyudj-005tyU-2g; Tue, 16 May 2023 13:22:55 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pyudf-005twa-2a; Tue, 16 May 2023 13:22:53 +0000 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 4C65260AB1; Tue, 16 May 2023 13:22:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DAC46C4339C; Tue, 16 May 2023 13:22:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684243370; bh=+sPUthy7aIz73vxHLbcpB1b2jpbwC7HJrTOIMZMo2dE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uPYOuK4MsGdqbnn/xMDKkUnZ4yYcIuyBc3wmFOmWi0M1zulETSYFuwtqUCrDRWI5S wVgIQoGalPhgXBR/I5WssTLKmq6aTcrsCJUtSooWl34gqA1lzOk4MpXdwpQp4uI1ix UxdzERwnISLKF24Av3xmoQrl0qjZ57o4EfWErx8mzgrIZ5TrmzYI5ABlT5e+uuy5rl m5ShpiTBT8U6M4bVGmzempnsCwRwUYC+UX8Dwlya7GJyyjdUslWoAv5UVFoYyEhMEI 2k0EvrnUPDzM8TriF9OikZq4XzzY8CwIj/Z+UQn841ylHadecHfO4QMMpUByPVPigy Qi/cGvspkIySw== Date: Tue, 16 May 2023 18:52:46 +0530 From: Vinod Koul To: Sean Anderson Cc: Kishon Vijay Abraham I , linux-phy@lists.infradead.org, Madalin Bucur , linux-arm-kernel@lists.infradead.org, Camelia Alexandra Groza , devicetree@vger.kernel.org, Rob Herring , linuxppc-dev@lists.ozlabs.org, Bagas Sanjaya , Krzysztof Kozlowski , Ioana Ciornei , Michael Turquette , Stephen Boyd , linux-clk@vger.kernel.org Subject: Re: [PATCH v14 06/15] clk: Add Lynx 10G SerDes PLL driver Message-ID: References: <20230413160607.4128315-1-sean.anderson@seco.com> <20230413160607.4128315-7-sean.anderson@seco.com> <1012f955-180e-0013-cc13-1da10991b5f5@seco.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230516_062251_917760_1029F340 X-CRM114-Status: GOOD ( 27.83 ) X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org On 09-05-23, 11:26, Sean Anderson wrote: > On 5/9/23 09:00, Vinod Koul wrote: > > On 08-05-23, 11:31, Sean Anderson wrote: > >> On 5/8/23 05:15, Vinod Koul wrote: > > > >> >> +int lynx_clks_init(struct device *dev, struct regmap *regmap, > >> >> + struct clk *plls[2], struct clk *ex_dlys[2], bool compat); > >> > > >> > so you have an exported symbol for clk driver init in phy driver header? > >> > can you please explain why..? > >> > >> So that it can be called at the appropriate time during the phy's probe function. > >> > >> This is really an integral part of the phy driver, but I was directed to split it > >> off and put it in another subsystem's directory. > > > > That is right clock should be belong to clk driver. IIUC the hardware is > > phy along with clocks and you are doing the clk init. I think that may > > not be correct model, you should really have a device tree node to > > represent the clock and the phy node > > > > > > What stops this from being modelled as it is in the hardware? > > It *is* modeled as it is in hardware. With just the serdes compatible, > we have all the information we need to create the clocks. So we do so. > There's no need for a separate device just to create four clocks. > > These clocks cannot be used by any other device (except possibly by > putting a lane into test mode). So there is no benefit from making them > a separate device, except an increase in complexity due to ordering and > dynamic lookup. By doing things this way we know that either there was > an error or the clocks all exist, and the lifetime of the clocks matches > the serdes. Okay that does makes sense. In that case why should this not be in the phy driver itself. There are already few examples og phy drivers having inbuild clk where is makes sense. You register the clk_ops as part of phy driver Thanks -- ~Vinod -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A501AC77B7F for ; Tue, 16 May 2023 13:23:44 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4QLH4Z6dm7z3fCH for ; Tue, 16 May 2023 23:23:42 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=uPYOuK4M; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=139.178.84.217; helo=dfw.source.kernel.org; envelope-from=vkoul@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=uPYOuK4M; dkim-atps=neutral Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4QLH3f6yjZz3bg3 for ; Tue, 16 May 2023 23:22:54 +1000 (AEST) 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 4C65260AB1; Tue, 16 May 2023 13:22:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DAC46C4339C; Tue, 16 May 2023 13:22:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684243370; bh=+sPUthy7aIz73vxHLbcpB1b2jpbwC7HJrTOIMZMo2dE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uPYOuK4MsGdqbnn/xMDKkUnZ4yYcIuyBc3wmFOmWi0M1zulETSYFuwtqUCrDRWI5S wVgIQoGalPhgXBR/I5WssTLKmq6aTcrsCJUtSooWl34gqA1lzOk4MpXdwpQp4uI1ix UxdzERwnISLKF24Av3xmoQrl0qjZ57o4EfWErx8mzgrIZ5TrmzYI5ABlT5e+uuy5rl m5ShpiTBT8U6M4bVGmzempnsCwRwUYC+UX8Dwlya7GJyyjdUslWoAv5UVFoYyEhMEI 2k0EvrnUPDzM8TriF9OikZq4XzzY8CwIj/Z+UQn841ylHadecHfO4QMMpUByPVPigy Qi/cGvspkIySw== Date: Tue, 16 May 2023 18:52:46 +0530 From: Vinod Koul To: Sean Anderson Subject: Re: [PATCH v14 06/15] clk: Add Lynx 10G SerDes PLL driver Message-ID: References: <20230413160607.4128315-1-sean.anderson@seco.com> <20230413160607.4128315-7-sean.anderson@seco.com> <1012f955-180e-0013-cc13-1da10991b5f5@seco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kishon Vijay Abraham I , devicetree@vger.kernel.org, Krzysztof Kozlowski , Madalin Bucur , Stephen Boyd , Michael Turquette , Rob Herring , Camelia Alexandra Groza , Bagas Sanjaya , Ioana Ciornei , linux-phy@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 09-05-23, 11:26, Sean Anderson wrote: > On 5/9/23 09:00, Vinod Koul wrote: > > On 08-05-23, 11:31, Sean Anderson wrote: > >> On 5/8/23 05:15, Vinod Koul wrote: > > > >> >> +int lynx_clks_init(struct device *dev, struct regmap *regmap, > >> >> + struct clk *plls[2], struct clk *ex_dlys[2], bool compat); > >> > > >> > so you have an exported symbol for clk driver init in phy driver header? > >> > can you please explain why..? > >> > >> So that it can be called at the appropriate time during the phy's probe function. > >> > >> This is really an integral part of the phy driver, but I was directed to split it > >> off and put it in another subsystem's directory. > > > > That is right clock should be belong to clk driver. IIUC the hardware is > > phy along with clocks and you are doing the clk init. I think that may > > not be correct model, you should really have a device tree node to > > represent the clock and the phy node > > > > > > What stops this from being modelled as it is in the hardware? > > It *is* modeled as it is in hardware. With just the serdes compatible, > we have all the information we need to create the clocks. So we do so. > There's no need for a separate device just to create four clocks. > > These clocks cannot be used by any other device (except possibly by > putting a lane into test mode). So there is no benefit from making them > a separate device, except an increase in complexity due to ordering and > dynamic lookup. By doing things this way we know that either there was > an error or the clocks all exist, and the lifetime of the clocks matches > the serdes. Okay that does makes sense. In that case why should this not be in the phy driver itself. There are already few examples og phy drivers having inbuild clk where is makes sense. You register the clk_ops as part of phy driver Thanks -- ~Vinod 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B25D3C77B7A for ; Tue, 16 May 2023 13:23:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=yvb7+3MxVRoyllY6ls8tq0QpgWMsdLbdurSrt1h4CTU=; b=0EI3ipcdddHpU9 HBn8CRB+PWxSANATaooVB04W2Dyw+oM8Hz65dlloWO5M/N5M8uUUYcgTmYAs4GQ1+1e6I4j9v6j9n ebY0FAJHFhsse8zOAagvfrcg/FPa8AhHFMVYdl4iXXomoEIEuvrhdy0nhZ388us18GI3t6WwMYZyE eK7fW+fFj5/k0rp9mJHE+AlTGDPyw6CnaFGDu3i6RjoI49a91n5DSaSSaedKiMm1/peY3wX7EU+Zh mmwtcldJTz3OBGYJShnKFSwc2p0mNbTKCJ1nPJLIZAuUJlwm4xpnBwBx0wyzNnqTvUXo3l99bESZ4 c50jxHxEvzr6uz5MDKzg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pyudj-005tyJ-1D; Tue, 16 May 2023 13:22:55 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pyudf-005twa-2a; Tue, 16 May 2023 13:22:53 +0000 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 4C65260AB1; Tue, 16 May 2023 13:22:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DAC46C4339C; Tue, 16 May 2023 13:22:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684243370; bh=+sPUthy7aIz73vxHLbcpB1b2jpbwC7HJrTOIMZMo2dE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uPYOuK4MsGdqbnn/xMDKkUnZ4yYcIuyBc3wmFOmWi0M1zulETSYFuwtqUCrDRWI5S wVgIQoGalPhgXBR/I5WssTLKmq6aTcrsCJUtSooWl34gqA1lzOk4MpXdwpQp4uI1ix UxdzERwnISLKF24Av3xmoQrl0qjZ57o4EfWErx8mzgrIZ5TrmzYI5ABlT5e+uuy5rl m5ShpiTBT8U6M4bVGmzempnsCwRwUYC+UX8Dwlya7GJyyjdUslWoAv5UVFoYyEhMEI 2k0EvrnUPDzM8TriF9OikZq4XzzY8CwIj/Z+UQn841ylHadecHfO4QMMpUByPVPigy Qi/cGvspkIySw== Date: Tue, 16 May 2023 18:52:46 +0530 From: Vinod Koul To: Sean Anderson Cc: Kishon Vijay Abraham I , linux-phy@lists.infradead.org, Madalin Bucur , linux-arm-kernel@lists.infradead.org, Camelia Alexandra Groza , devicetree@vger.kernel.org, Rob Herring , linuxppc-dev@lists.ozlabs.org, Bagas Sanjaya , Krzysztof Kozlowski , Ioana Ciornei , Michael Turquette , Stephen Boyd , linux-clk@vger.kernel.org Subject: Re: [PATCH v14 06/15] clk: Add Lynx 10G SerDes PLL driver Message-ID: References: <20230413160607.4128315-1-sean.anderson@seco.com> <20230413160607.4128315-7-sean.anderson@seco.com> <1012f955-180e-0013-cc13-1da10991b5f5@seco.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230516_062251_917760_1029F340 X-CRM114-Status: GOOD ( 27.83 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 09-05-23, 11:26, Sean Anderson wrote: > On 5/9/23 09:00, Vinod Koul wrote: > > On 08-05-23, 11:31, Sean Anderson wrote: > >> On 5/8/23 05:15, Vinod Koul wrote: > > > >> >> +int lynx_clks_init(struct device *dev, struct regmap *regmap, > >> >> + struct clk *plls[2], struct clk *ex_dlys[2], bool compat); > >> > > >> > so you have an exported symbol for clk driver init in phy driver header? > >> > can you please explain why..? > >> > >> So that it can be called at the appropriate time during the phy's probe function. > >> > >> This is really an integral part of the phy driver, but I was directed to split it > >> off and put it in another subsystem's directory. > > > > That is right clock should be belong to clk driver. IIUC the hardware is > > phy along with clocks and you are doing the clk init. I think that may > > not be correct model, you should really have a device tree node to > > represent the clock and the phy node > > > > > > What stops this from being modelled as it is in the hardware? > > It *is* modeled as it is in hardware. With just the serdes compatible, > we have all the information we need to create the clocks. So we do so. > There's no need for a separate device just to create four clocks. > > These clocks cannot be used by any other device (except possibly by > putting a lane into test mode). So there is no benefit from making them > a separate device, except an increase in complexity due to ordering and > dynamic lookup. By doing things this way we know that either there was > an error or the clocks all exist, and the lifetime of the clocks matches > the serdes. Okay that does makes sense. In that case why should this not be in the phy driver itself. There are already few examples og phy drivers having inbuild clk where is makes sense. You register the clk_ops as part of phy driver Thanks -- ~Vinod _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel