All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Wei Fang <wei.fang@nxp.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"edumazet@google.com" <edumazet@google.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"krzysztof.kozlowski+dt@linaro.org" 
	<krzysztof.kozlowski+dt@linaro.org>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next 1/2] dt-bindings: net: tja11xx: add nxp,refclk_in property
Date: Fri, 19 Aug 2022 14:44:42 +0200	[thread overview]
Message-ID: <Yv+FuiUoTjpoUZ32@lunn.ch> (raw)
In-Reply-To: <9ec575ba-784d-74f7-8861-da2f62fe0773@linaro.org>

On Fri, Aug 19, 2022 at 02:37:36PM +0300, Krzysztof Kozlowski wrote:
> On 19/08/2022 12:37, Wei Fang wrote:
> >>
> >>> +          in RMII mode. This clock signal is provided by the PHY and is
> >>> +          typically derived from an external 25MHz crystal. Alternatively,
> >>> +          a 50MHz clock signal generated by an external oscillator can be
> >>> +          connected to pin REF_CLK. A third option is to connect a 25MHz
> >>> +          clock to pin CLK_IN_OUT. So, the REF_CLK should be configured
> >>> +          as input or output according to the actual circuit connection.
> >>> +          If present, indicates that the REF_CLK will be configured as
> >>> +          interface reference clock input when RMII mode enabled.
> >>> +          If not present, the REF_CLK will be configured as interface
> >>> +          reference clock output when RMII mode enabled.
> >>> +          Only supported on TJA1100 and TJA1101.
> >>
> >> Then disallow it on other variants.
> >>
> >> Shouldn't this be just "clocks" property?
> >>
> >>
> > This property is to configure the pin REF_CLK of PHY as a input pin through phy register,
> > indicates that the REF_CLK signal is provided by an external oscillator. so I don't think it's a
> > "clock" property.
> 
> clocks, not clock.
> 
> You just repeated pieces of description as an counter-argument, so this
> does not explain anything.
> 
> If it is external oscillator shouldn't it be represented in DTS and then
> obtained by driver (clk_get + clk_prepare_enable)? Otherwise how are you
> sure that clock is actually enabled? And the lack of presence of the
> external clock means it is derived from PHY?

Using the common clock framework has been discussed in the past. But
no PHY actually does this. When the SoC provides the clock, a few PHYs
do make use of the common clock framework as clock consumers to ensure
the clock is ticking.

Plus, as the description says, this pin can be either a clock producer
or a consumer. I don't think the common clock code allows this. It is
also not something you negotiate between the MAC and PHY. The hardware
designer typically decides based on the MAC and PHY actually used. So
this is a fixed hardware property.

     Andrew

  reply	other threads:[~2022-08-19 12:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-19  7:47 [PATCH net-next 0/2] add interface mode select and RMII wei.fang
2022-08-19  7:47 ` [PATCH net-next 1/2] dt-bindings: net: tja11xx: add nxp,refclk_in property wei.fang
2022-08-19  9:14   ` Krzysztof Kozlowski
2022-08-19  9:37     ` Wei Fang
2022-08-19 11:37       ` Krzysztof Kozlowski
2022-08-19 12:44         ` Andrew Lunn [this message]
2022-08-19 12:52           ` Krzysztof Kozlowski
2022-08-19  7:47 ` [PATCH net-next 2/2] net: phy: tja11xx: add interface mode and RMII REF_CLK support wei.fang
2022-08-19 12:50   ` Andrew Lunn
2022-08-22  1:16     ` Wei Fang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yv+FuiUoTjpoUZ32@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=wei.fang@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.