linux-kernel - Re: [PATCH net-next 1/2] dt-bindings: net: tja11xx: add nxp,refclk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 19 Aug 2022 15:52:38 +0300
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Wei Fang <wei.fang@....com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 1/2] dt-bindings: net: tja11xx: add nxp,refclk_in
 property

On 19/08/2022 15:44, Andrew Lunn wrote:
> 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.

IOW, all DTSes would have a fixed clock stub without any logic usable by
Common CF (like enabling)?

> 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.

Indeed.

Anyway the property name and typo need fixes.
Best regards,
Krzysztof