netdev - Re: [RFC] support built-in ethernet phy which needs some mmio accesses

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: <9c1e9488-4fba-480c-850f-f6f9ab4a69a3@gmail.com>
Date: Sun, 19 Nov 2023 15:13:41 +0100
From: Heiner Kallweit <hkallweit1@...il.com>
To: Jisheng Zhang <jszhang@...nel.org>, Andrew Lunn <andrew@...n.ch>,
 Russell King <linux@...linux.org.uk>, "David S.Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Conor Dooley <conor.dooley@...rochip.com>
Cc: netdev@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [RFC] support built-in ethernet phy which needs some mmio
 accesses

On 19.11.2023 14:57, Jisheng Zhang wrote:
> Hi,
> 
> I want to upstream milkv duo (powered by cv1800b) ethernet support. The SoC
> contains a built-in eth phy which also needs some initialization via.
> mmio access during init. So, I need to do something like this(sol A):
> 
> in dtsi:
> 
> ephy@...d {
> 	compatbile = "sophgo,cv1800b-ephy";
> 	...
> };
> 
> in ephy driver:
> 
> static struct phy_driver ephy_driver {
> 	various implementaion via standard phy_read/phy_write;
> };
> 
> int ephy_probe(platform_device *pdev)
> {
> 	init via. readl() and writel();
> 	phy_drivers_register(&ephy_driver);
> }
> 
> int ephy_remove()
> {
> 	phy_drivers_unregister();
> }
> I'm not sure whether this kind of driver modeling can be accepted or
> not. The advantage of this solution is there's no hardcoding at all, the
> big problem is the ephy is initialized during probe() rather than
> config_init().
> 
Answer depends on what this MMIO-based initialization does and when
it's needed. Is this initialization needed only once, or also after
PHY power down or reset or system suspend?
Do the MMIO addresses belong to a specific device, e.g. MAC?

Depending on the answer a platform driver under drivers/soc may be
the right place.

> The vendor kernel src supports the ephy in the following way(will be
> called as sol B):
> in phy driver's .config_init() maps the ephy reg via. ioremap()
> then init via. readl/writel on the mapped space. Obviously, this
> isn't acceptable due to the hardcoding of ephy reg base and size.
> But the advantage is it delay the ephy init until config_init() is
> called.
> 
> could you please give some advice?
> 
> Thanks in advance

Heiner