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: Sun, 19 Nov 2023 15:13:41 +0100
From: Heiner Kallweit <>
To: Jisheng Zhang <>, Andrew Lunn <>,
 Russell King <>, "David S.Miller"
 <>, Eric Dumazet <>,
 Jakub Kicinski <>, Paolo Abeni <>,
 Conor Dooley <>
Subject: Re: [RFC] support built-in ethernet phy which needs some mmio

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


Powered by blists - more mailing lists