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

[Heiner Kallweit]

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 at abcd {
> 	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