linux-kernel - Re: [RFC PATCH 3/3] net: phy: at803x: add device tree binding

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]

Message-ID: <64c0dda8-d428-643e-5edf-ac5108c7ec5c@gmail.com>
Date:   Thu, 31 Oct 2019 10:35:16 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Michael Walle <michael@...le.cc>, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, netdev@...r.kernel.org,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [RFC PATCH 3/3] net: phy: at803x: add device tree binding

On 10/31/19 10:22 AM, Michael Walle wrote:
> Am 2019-10-31 00:59, schrieb Michael Walle:
>>>> +
>>>> +    if (of_property_read_bool(node, "atheros,keep-pll-enabled"))
>>>> +        priv->flags |= AT803X_KEEP_PLL_ENABLED;
>>>
>>> This should probably be a PHY tunable rather than a Device Tree
>>> property
>>> as this delves more into the policy than the pure hardware description.
>>
>> To be frank. I'll first need to look into PHY tunables before
>> answering ;)
>> But keep in mind that this clock output might be used anywhere on the
>> board. It must not have something to do with networking. The PHY has a
>> crystal and it can generate these couple of frequencies regardless of
>> its network operation.
> 
> Although it could be used to provide any clock on the board, I don't know
> if that is possible at the moment, because the PHY is configured in
> config_init() which is only called when someone brings the interface up,
> correct?
> 
> Anyway, I don't know if that is worth the hassle because in almost all
> cases the use case is to provide a fixed clock to the MAC for an RGMII
> interface. I don't know if that really fits a PHY tunable, because in
> the worst case the link won't work at all if the SoC expects an
> always-on clock.

Well, that was my question really, is the clock output being controlled
the actual RXC that will feed back to the MAC or is this is another
clock output pin (sorry if you indicated that before and I missed it)?

If this is the PHY's RXC, then does the configuration (DSP, PLL, XTAL)
matter at all on the generated output frequency, or is this just a
choice for the board designer, and whether the PHY is configured for
MII/RGMII, it outputs the appropriate clock at 25/125Mhz?
-- 
Florian