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

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

[Jisheng Zhang]

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

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

Re: [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@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

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

[Andrew Lunn]

On Sun, Nov 19, 2023 at 09:57:17PM +0800, 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):

What does this initialisation do?

If you are turning on clocks, write a common clock provider, which the
PHY driver can use. If its a reset, write a reset driver. If its a
regulator, write a regulator driver, etc.

      Andrew

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

[Jisheng Zhang]

On Sun, Nov 19, 2023 at 05:18:49PM +0100, Andrew Lunn wrote:
> On Sun, Nov 19, 2023 at 09:57:17PM +0800, 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):
> 
> What does this initialisation do?

Per my understanding of the vendor code, it reads calibration data from
efuse then apply the setting, set tx bias current, set MLT3 phase code,
and so on. I can see it switches to page 5, page 16, page 17 etc. to
apply settings. Compared with normal phy driver, the programming is
done via. the mmio rather than phy_read/write.

Here is the vendor source code:
https://github.com/milkv-duo/duo-buildroot-sdk/blob/develop/linux_5.10/drivers/net/phy/cvitek.c

Hi Heiner,

IIUC, the initialization also needs redo after power off, so it's
not init-once action.

Thanks
> 
> If you are turning on clocks, write a common clock provider, which the
> PHY driver can use. If its a reset, write a reset driver. If its a
> regulator, write a regulator driver, etc.
> 
>       Andrew

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

[Andrew Lunn]

> Per my understanding of the vendor code, it reads calibration data from
> efuse

Linux should have an API for accessing efuse data. So please make use
of that.

What address space is

#define REG_EPHY_TOP_WRAP 0x03009800
#define REG_EPHY_BASE 0x03009000

in? Is this range dedicated to the PHY? Is it within the MAC address
space?

Does the datasheet describe the PHY pages? I'm wondering if you can
access the same registers via MDIO?

Where is the MDIO driver? Since this is integrated into the silicon,
it could be MDIO is not actually MDIO and is much faster. If you can
access the same registers via MIDO, that would be the cleaner way to
do it.

   Andrew