Yeah, you should add:
phy-mode = "10gbase-r";
managed = "in-band-status";
To port@0
, that should as far as I remember
Yeah, you should add:
phy-mode = "10gbase-r";
managed = "in-band-status";
To port@0
, that should as far as I remember
Okay. Silly question though - isn't this inherited from the cp0_eth0
node?
&cp0_eth0 {
/* This port is connected to 88E6393X switch */
status = "okay";
phy-mode = "10gbase-r";
managed = "in-band-status";
nvmem-cells = <&macaddr_hard>;
nvmem-cell-names = "mac-address";
mac-address-increment = <0>;
};
No, they are completely separate things as far as the kernel is concerned.
Thanks, that fixes those errors indeed. Ethtool isn't reporting 2.5GBASE-T capability anymore on 6.1, I've gone through the QCA8081 related patches that were needed for 5.15, but they should all have been merged prior to 6.1. I have no means to test the 2,5 Gbps port at the moment, so if anyone can verify that would be nice.
Apart from the 2,5 Gbps capability everything looks the same.
On 5.15:
# ethtool p1
Settings for p1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
1000baseX/Full
2500baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
1000baseX/Full
2500baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Auto-negotiation: on
master-slave cfg: preferred slave
master-slave status: unknown
Port: Twisted Pair
PHYAD: 0
Transceiver: external
MDI-X: Unknown
Supports Wake-on: g
Wake-on: d
Link detected: no
On 6.1:
# ethtool p1
Settings for p1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
1000baseX/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
1000baseX/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Auto-negotiation: on
master-slave cfg: preferred slave
master-slave status: unknown
Port: Twisted Pair
PHYAD: 0
Transceiver: external
MDI-X: Unknown
Supports Wake-on: g
Wake-on: d
Link detected: no
Thanks @Borromini & @robimarko!!
just a double check; @Borromini is the 6.1 patch on the RB5009 wiki updated ? Not sure if I read it correctly.....
Yes, the link here and on the wiki point to the latest patch set.
I will.
Running 6.1.52 now for 24h. Haven’t got any 2.5 Gbps devices to test. 1Gb and SFP+ look stable.
Thanks for the 6.1 patch set
The QCA8081 no longer works at 2.5Gb, connecting with a 2.5Gb capable adapter to this port will link at 1Gbit instead.
I suspected as much, since ethtool didn't advertise 2,5 Gbps capability anymore.
@robimarko Would you mind taking a look when you have the time? I do realise it should be fully supported by now, but this seems like a regression - or maybe something missing from the DTS? I see the qualcommax
target supports multiple devices with QCA8081, but the device trees that show up don't make me any wiser.
qualcommax
is using the driver from SSDK for QCA8081 but I doubt this is a PHY driver issue as the driver had little to no changes.
It's more likely that mv88e6xxx
driver had a regression in advertising the port capabilities.
I may be able to dig my board out and try this out over the weekend but no promises
Thanks! Appreciate it.
Question about the image matching 23.05.0 (when ready). Anyone so kind to provide this?
I mean with luci and the release modules compatibility?
Thanks
Am I correct that the RB5009UPr+S+IN can run from the same set of patches as the RB5009UG+S+IN, with exception to its PoE functionality?
In what state is this, how feasible it to get PoE working on UPr model?
I would like to know if getting the PoE version of that router makes sense, even if not having the PoE functional for some time yet.
This is correct. I have the PoE version and run OpenWRT on it with these patches. No PoE functionality indeed.
I can successfully do everything except read the current port status and power (Mikrotik RB750 r2 series POE - #69 by TheChaosJack see my last two posts here. Setting the one GPIO pin could also be moved to the device tree for a more permanent setup).
I did not look at the API but the get_poe sounds like the status info only. Does it mean the PoE cable negotiation works for all the 8 ports and the peers are correctly powered?
Yes PoE is fully working. You can even select off, forced on and auto for each port.
Thank you for the patch and dts instructions. I've simply set all ports to auto and that works exactly as I hoped.
Is mainline support for this device realistic this year?
I know that everyone does it in their free time and for free, that's why I'm only asking about plans