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-next>] [day] [month] [year] [list]
Date: Sun, 19 Nov 2023 21:57:17 +0800
From: Jisheng Zhang <>
To: Andrew Lunn <>, HeinerKallweit <>,
	Russell King <>,
	"David S.Miller" <>,
	Eric Dumazet <>,
	Jakub Kicinski <>, Paolo Abeni <>,
	Conor Dooley <>
Subject: [RFC] support built-in ethernet phy which needs some mmio accesses


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();

int ephy_remove()
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

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

could you please give some advice?

Thanks in advance

Powered by blists - more mailing lists