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

Heiner Kallweit
2023-11-19T15:14:01Z

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@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