[BPi-R3-Mini] Airoha EN8811H 2.5G PHY driver

Banana Pi Router design BPI-R3/R3 Mini(MT7986)
102

Thanks for sharing that.

Then I think the immortalwrt solution would be ok:

103

Another option would be to expand the devicetree property:

		if (of_property_read_bool(np, "mediatek,pnswap"))
			flags |= MTK_SGMII_FLAG_PN_SWAP;

But then with rx and/or tx separately. If at all this can be applied on the BPI-R3, setting something like “mediatek,rxswap” or “mediatek,txswap”. But what does @dangowrt think about that?

104

So I have added:

Add en8811h bindings documentation yaml · ericwoud/linux@7ff2523 (github.com)

105

Afaik you need a property to map this binding to dts files…normally this is the compatible,but here we have only the phy-id…not sure how other phy bindings working

106

It is practically the same as ‘realtek,rtl82xx.yaml’, so I assumed this would be ok then.

107

Maybe it is ok as text binding,but imho is is not taken into dtbs_check

108

As I still do not like forcing the use of a firmware file in initrd, or baking it in the kernel image, I took some time to investigate further.

The registers read in genphy_c45_pma_read_abilities() and the resulting bits set in phydev->supported, are exactly the same, before or after the firmware load. Even after cold-boot. So what is supported is already fixed before firmware load. This means that get_features() can be called before firmware load, which in turn means that firmware can be loaded from config_init(). This conforms also to the description of the 2 functions as stated.

	/**
	 * @config_init: Called to initialize the PHY,
	 * including after a reset
	 */
	int (*config_init)(struct phy_device *phydev);

	/**
	 * @probe: Called during discovery.  Used to set
	 * up device-specific structures, if any
	 */
	int (*probe)(struct phy_device *phydev);

And the firmware can be loaded when rootfs is mounted (when the interface is set link up). Only for using the phy from initrd, then the firmware needs to be added to initrd.

2 Likes
109

So, most gen_phy_xxx() calls go back to C22 version… See rfc patch. Luckily I still had them in backup.

All pointers from rfc patch now in wip branch

Edit:

So the devicetree booleans will now be named:

airoha,pnswap-rx
airoha,pnswap-tx
110

Can you add a bool to indicate fw has been loaded? Like in this target/linux/mediatek/files-5.4/drivers/net/phy/mediatek-2p5ge.c - openwrt/feeds/mtk-openwrt-feeds - Gitiles

111

No problem. I was actually hoping to read in the external datasheet, when it is coming, if there is a register to read the firmware was loaded. I believe I picked up some hint there is also a possibility that it is read from an eeprom…

So I’m waiting for the external datasheet, and if no usable bit is there, will add the code as you mentioned.

Since there are 2 files, may need 2 bools or 2 bits.

112

What do you mean external datasheet?

113

A datasheet is in the making for external use… I’m waiting for it to finish my patch set.

114

I see. That’s good news.

115

Any news on that? Should I poke people at Airoha or MTK?

116

I asked when it is available last week, but until now, no reply on that. I need to supply more info on pnswap-rx and pnswap-rx, specifically, from which side it seen as tx/rx. Also would use it to change some register names to correspond with that datasheet. That’s about it. It would then be ready for rfc patch V2.

117

Have you tested this? The phy won’t initialize properly after

ip link set eth1 down
ip link set eth1 up

Without going through the entire configuration again.

So until this is sorted, there is no shortcut skipping the loading and I must leave it as such…

118

Added some missing code en8811h_c45_read_link(). It wasn’t updating autoneg_conplete status. Also changed some register names used.

In bpir-rolling-stable branch the new patch separate.

In net-next-airoha branch the updated patch as a whole, in preparation of ‘rfc patch v2’.

1 Like
119

Maybe this is also missing in uboot driver and so AN times out (but works after AN is done) and cannot be restarted?

120

It was really something I missed when changing the read link status code to use the AN mmd device. Setting autoneg_complete should be part of this code as it is gathered from the same register

But it could also be an AN problem in u-boot… I am not familiar enough with u-boot to know when it does link-up/down and/or restarts AN.

121

I’m working on adapting the driver to U-Boot and giving it various firmware loading options (from MMC, SPI-NOR and UBI/SPI-NAND).

From what I can tell the one issue which is still unresolved is having to go through the whole reset → load-firmware → … cycle every time the link is set down and the missing 2500M link-partner advertisement bit which we were promised to have in some custom register. So that didn’t happen…?