Only there it was, found it on another site.
Oh seems already merged…nice
committer Kernel Firmware Robot 
Once every about 10 boots I get this now:
[ 5.423234] Airoha EN8811H mdio-bus:0e: EN8811H PHY load firmware ready!
[ 5.431335] Airoha EN8811H mdio-bus:0e: EN8811H Mode 1 !
[ 5.439072] Airoha EN8811H mdio-bus:0e: Tx, Rx Polarity(0xca0f8): 01a01503
[ 5.446450] Airoha EN8811H mdio-bus:0e: MD32 FW Version(0x3b3c) : 23112102
[ 5.456605] Airoha EN8811H mdio-bus:0e: LED initialize OK !
[ 5.462166] Airoha EN8811H mdio-bus:0e: EN8811H initialize OK!
[ 7.573108] mtk_soc_eth 15100000.ethernet eth0: PHY [mdio-bus:0e] driver [Airoha EN8811H] (irq=POLL)
[ 15.364961] Airoha EN8811H mdio-bus:0f: en8811h_probe failed: -110
[ 15.371145] Airoha EN8811H mdio-bus:0f: EN8811H PHY load firmware not ready
[ 15.378163] Airoha EN8811H mdio-bus:0f: MD32 FW Status reg: 0x0
[ 15.384293] Airoha EN8811H mdio-bus:0f: Check MD32 FW Version(0x3b3c) : 00000000
[ 15.391679] Airoha EN8811H mdio-bus:0f: EN8811H initialize fail!
So I’ll try the mdio lock during (almost) the entire call to en8811h_load_firmware()
This EPROBE_DEFER is giving my quite some headaches… If it takes too long for the firmware to be ready to load in the probe() function, I get strange results. phylink/mtk_eth_soc already called get_features and failed, then firmware finished loading , and the the probe() function still fails at the poll for firmware successful as something on the driver probably is closed, as get_features() failed already.
At another time I caught another strange sequence of events: config_init() (which this time I programmed to wait returning until probe() has finished successfully) is being called before probe() has finished… But now phylink does nothing anymore with the phy…
[ 15.813024] Airoha EN8811H mdio-bus:0e: EN8811H en8811h_config_init!
[ 17.076123] Airoha EN8811H mdio-bus:0e: EN8811H PHY load firmware ready!
[ 17.082825] Airoha EN8811H mdio-bus:0e: EN8811H Mode 1 !
[ 17.089182] Airoha EN8811H mdio-bus:0e: Tx, Rx Polarity(0xca0f8): 01a01503
[ 17.096254] Airoha EN8811H mdio-bus:0e: MD32 FW Version(0x3b3c) : 23112102
[ 17.105695] Airoha EN8811H mdio-bus:0e: LED initialize OK !
[ 17.111254] Airoha EN8811H mdio-bus:0e: EN8811H initialize OK!
Using EPROBE_DEFER I do not get a stable system. Depending on the sequence of events it fails. phylink simply is not waiting until the probe() function has finished successfully.
Please don’t. There’s a sequence need to follow.
I understand, I do not change the sequence towards the phy. Only read in both the firmwares into memory first and, if successful, then execute the original sequence to the phy. It is not very useful to start the sequence to the phy, if reading the second firmwarefile into memory fails.
So anyway, I have the firmware loading now in the probe() function.
So if the mtk_soc_eth driver is builtin, and the en881h is linked to it via phylink, then the en8811 phy driver also needs to be builtin.
Then it is up to the one who sets up his system, to get the firmware available.
I’ve done it though the initramfs, See:
But i guess it will also work with: CONFIG_EXTRA_FIRMWARE, like @frank-w said.
Edit:
BUG?, the communication for read_status() now goes through genphy_c45_read_status(), but I see it reports link up, where in fact it is not… There is nothing connected to the other side… Then I think genphy_read_status() worked better, but I’ll look in to it.
Why cannot the phy driver connect later to the mac?
Good question,
Probe() and get_feateres() are called very early. I haven’t figured out how to delay that (yet).
but if you compile the phy driver as module its probe is called later and should be able to connect to phy or am i wrong? till this point the mac should be down as phy does not respond…
It’s been a while, but I believe I tried that (actually as first), but phylink examines the id registers and then cannot find the appropriate driver, early at boot, and fails. Only SFP modules (non-fiber) have adapted code in (edited: sfp state machine) which will probe the driver, when you make eth0/1 link go up.
So most things are realized now, it is in the wip branch.
So, accoring to Airoha, forced speed mode (AN off) is not supported at any speed, also not at 100Mbps.
That means only the bug of the phy not setting MDIO_AN_10GBT_STAT_LP2_5G is still an issue.
Then I think I can send as PATCH RFC net-next, I’ll add the comment that the dirty fix for MDIO_AN_10GBT_STAT_LP2_5G will be removed if the bug is fixed. At least it can be reviewed.
What do you think @dangowrt and @frank-w?
Latest version here:
I think reviwers will point to magic numbers which you can only replace by constants when you have the datasheet.
But of course you can send it to get some more responses and fixing other problems i’m not thinking of.
There are still some registers not listed in the datasheet or programming guide. Registers for mode selection and writing fimrware to the buffer etc.
You might want to remove all the phydev_info.
Upstream prefers the driver to be quiet when it works.
Thanks, I removed all but one phydev_info: Only 1 entry remains, telling about the firmware version that is loaded. I can remember this is something you usually see in the kernel log.
Further, I renamed all led functions from en8811h_xxx to airoha_xxx air_xxx as these are very generic functions. Perhapse one day can be combined with the mediatek led code.
Probably not. But it can be used with other Airoha PHY.
Ok, so using all with #define would look something like it is now at ‘wip’ branch.
I will need to changes some names, if I get the datasheet (and allowed to use the register names). But at least most of the work in the naming is done now.
1 Like
Wow,looks much better now 