linux-kernel - 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 for Android: free password hash cracker in your pocket

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

Message-ID: <a804e0a4-2275-41c3-be3b-7dd79c2418cd@gmail.com>
Date: Thu, 6 Feb 2025 17:41:19 -0800
From: Kyle Hendry <kylehendrydev@...il.com>
To: 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 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.

Best Regards,
Kyle