netdev - Re: [PATCH 0/4] net: dsa: b53: Enable internal GPHY on BCM63268

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] [day] [month] [year] [list]

Message-ID: <318e8b95-4ef8-43ca-a19d-129372a9dc48@gmail.com>
Date: Fri, 7 Feb 2025 08:44:31 -0800
From: Florian Fainelli <f.fainelli@...il.com>
To: Kyle Hendry <kylehendrydev@...il.com>, Andrew Lunn <andrew@...n.ch>,
 Florian Fainelli <florian.fainelli@...adcom.com>
Cc: Vladimir Oltean <olteanv@...il.com>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] net: dsa: b53: Enable internal GPHY on BCM63268

On 2/6/25 17:41, Kyle Hendry wrote:
> 
> On 2025-02-06 12:17, Andrew Lunn wrote:
>> On Thu, Feb 06, 2025 at 10:15:50AM -0800, Florian Fainelli wrote:
>>> Hi Kyle,
>>>
>>> On 2/5/25 20:30, Kyle Hendry wrote:
>>>> Some BCM63268 bootloaders do not enable the internal PHYs by default.
>>>> This patch series adds functionality for the switch driver to
>>>> configure the gigabit ethernet PHY.
>>>>
>>>> Signed-off-by: Kyle Hendry <kylehendrydev@...il.com>
>>> So the register address you are manipulating logically belongs in the 
>>> GPIO
>>> block (GPIO_GPHY_CTRL) which has become quite a bit of a sundry here. I
>>> don't have a strong objection about the approach picked up here but 
>>> we will
>>> need a Device Tree binding update describing the second (and optional)
>>> register range.
>> Despite this being internal, is this actually a GPIO? Should it be
>> modelled as a GPIO line connected to a reset input on the PHY? It
>> would then nicely fit in the existing phylib handling of a PHY with a
>> GPIO reset line?
>>
>>     Andrew
> The main reason I took this approach is because a SF2 register has
> similar bits and I wanted to be consistent with that driver. If it
> makes more sense to treat these bits as GPIOs/clocks/resets then it
> would make the implementation simpler.

I don't think there is a need to go that far, and I don't think any of 
those abstractions work really well in the sense that they are neither 
clocks, nor resets, nor GPIOs, they are just enable bits for the power 
gating logic of the PHY, power domains would be the closest to what this 
is, but this is a very heavy handed approach with little benefit IMHO.

What we do need is document this register in the binding however.
-- 
Florian