I’m testing with your latest driver now and it does not work for me when switching cables from 2500M-capable link partner to Gigabit Ethernet link partner without any 802.3bz capabilities. See email for details and pull-request for a working work-around.
It doesn’t hurt to include it at this point, also because linux-next and linux-firmware are asynchronous trees side-by-side and linux-firmware is updated in distros (and OpenWrt) independenly of the Linux kernel.
Hence, as I want to also merge this in OpenWrt asap it will have to still support the old firmware until the new one got merged to linux-firmware and a new linux-firmware release came out (because that’s what we are packaging in OpenWrt – doing a git checkout of linux-firmware is quite insane as you might now, so we rely on the released tarballs).
So please keep it, so we can have the identical driver to have users of OpenWrt and vanilla kernel with your driver test the same thing (and eventually submit bug reports for the same code).
I just added hwmon temperature readout, in a new a patch in net-next-airoha branch.
I do not have any info on the units read from the register (only register address number, I do not have datasheet), so I think only thing to check is if this is the correct units.
If this is ok, I can just squash it to the first patch version (then I do not need a new patch for it).
The hwmon temperature code is practically the same as the one in ‘mxl-gpy.c’, so I guess this would be acceptable code. I’ll squash it.
Just tested temperature reading code and the unit seems to be correct, as on cold boot, both PHY and SoC show very similar reading of around 22 deg C (room temperature). However, in sensors output I then see the CPU and WiFi-frontend temperature raising, quite quickly reaching values above 35 deg C while the temperature of the two Ethernet PHYs reads out constant – while the PHYs actually also get warm subjectively… Maybe we need to trigger latching of new sensor read-out values somehow to update the temperature?
Is pwm/thermal definition right in r3mini dts (soc temp)? Noticed no fan activity when booting linux (i’m currently most time in uboot).
Have you found a way to fix uboot phy driver? My version has now the builtin-firmware option,have a priv and probe and i replaced spaces by tabs on indentation.
Thanks, tomorrow I have some time to look in to this.
Edit:
I am following the original code and the datasheet-snippet I have received on this:
#define AIR_PHY_HOST_CMD_3 0x800e
#define AIR_PHY_HOST_CMD_3_MODE1 0x1101
#define AIR_PHY_HOST_CMD_3_DOCMD 0x1100
#define AIR_PHY_HOST_CMD_4 0x800f
#define AIR_PHY_HOST_CMD_4_MODE1 0x0002
#define AIR_PHY_HOST_CMD_4_INTCLR 0x00e4
#define AIR_PHY_HOST_CMD_4_READTEMP 0x00e5
#define EN8811H_TEMPERATURE 0x3b38
ret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AIR_PHY_HOST_CMD_3,
AIR_PHY_HOST_CMD_3_DOCMD);
if (ret < 0)
return ret;
ret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AIR_PHY_HOST_CMD_4,
AIR_PHY_HOST_CMD_4_READTEMP);
if (ret < 0)
return ret;
ret = air_buckpbus_reg_read(phydev, EN8811H_TEMPERATURE, &pbus_value);
if (ret < 0)
return ret;
*value = pbus_value;
Btw, on 1000Mbps I got:
[ 5] 0.00-1.00 sec 114 MBytes 957 Mbits/sec 0 509 KBytes
[ 5] 1.00-2.00 sec 113 MBytes 945 Mbits/sec 0 509 KBytes
[ 5] 2.00-3.00 sec 112 MBytes 943 Mbits/sec 0 509 KBytes
[ 5] 3.00-4.00 sec 113 MBytes 945 Mbits/sec 0 509 KBytes
[ 5] 4.00-5.00 sec 112 MBytes 936 Mbits/sec 0 509 KBytes
[ 5] 5.00-6.00 sec 112 MBytes 943 Mbits/sec 0 509 KBytes
[ 5] 6.00-7.00 sec 112 MBytes 942 Mbits/sec 0 509 KBytes
[ 5] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 0 509 KBytes
[ 5] 8.00-9.00 sec 112 MBytes 944 Mbits/sec 0 509 KBytes
[ 5] 9.00-10.00 sec 112 MBytes 939 Mbits/sec 0 509 KBytes
This does seem ok on this connection.
Try the other direction iperf3 -R -c ... as well…
Is there a public datashet now?
No, I have just received a small snippet, so I can continue…
So I got Russell’s ideas implemented (which is possible), also air_buckpbus_reg_modify() and 1 use of it (still need to change the others).
Seems working ok, but I should check the leds are still functioning…
So the extra device that is seen at phy-address + 8, it is the device used by the air_pbus_reg_read/write() functions.
While most host registers are accessible through ‘buckpbus’, few (for now only 1 known) registers are accessed through ‘pbus’, which presents itself as an extra device on the mdio bus. For the en8811h it is found at phy-address + 8.
So, about re-introducing air_pbus_reg_read/write() the following:
First I used the devicetree to add this extra device, I saved this version in the net-next-airoha-extradev branch.
Since it is clear that it is not really an extra device, but only a different way to access the same device, I now have a version where the mdio-device is added by the en8811h driver itself (in the .probe function). No need for any extra devicetree entries. I saved this version in the normal net-next-airoha branch. I believe this is the version to send upstream.
Any suggestions?
So it is confirmed by Airoha, the register on pbus does not need to be written to.
So the entire access to the extra mdio device can be dropped.
2 Likes
Imho it would still be good to somehow document the presence of those extra devices in the MDIO bus, just to avoid confusion of people who may look into this in the future.
So the basic outline of v3 patch-set is ready and in the net-next-airhoa branch. The firmware files must be in initramfs, or otherwise available at early boot.
I’m still in contact about how to finally describe mode 1
I’ll do some more testing, checking and cosmetics, before sending.
Any comments before sending would be easier to fix now.
1 Like
which is your latest branch here? there is a net-next-airoha-v2 too…commits have same date, but code is different
net-next-airoha is the latest branch. I forgot I had that v2 branch, it is gone now.
It has been reviewed and no comments yet 
1 Like
Patch is applied to net-next!
1 Like
Great work,hope we can port the driver to uboot to have network support there too.