Regarding mdio0, I would add a short comment in the dts file that it is required for the correct operation of mdio1.
@mietekn re #109: already done - the comment went into the DTS the same day we measured it, with the mechanism spelled out so nobody "cleans it up" later:
/*
* The internal GE PHY behind mdio0 is not bonded out on this board (see the
* gmac0 note above) - but mdio0 must stay enabled anyway: registering the
* ge_phy deasserts GCC_GEPHY_MISC_ARES, and that reset also gates the
* MDC/MDIO path shared with mdio1. With mdio0 disabled the RTL8367S on
* mdio1 stops responding to SMI entirely (chip id read -ETIMEDOUT,
* measured 2026-07-30).
*/
And the statistics I owed you from #108, now with the delays separated on the fixed clock base - the first controlled data point goes to your #72 delay:
- reset wait alone, no ~98 ms settle: first boot came up with the classic half-alive link (carrier up, RX passing, TX completely dead, SMI healthy), recovered on a soft reboot; the next 5 boots (3 soft + 2 hard) were clean. So 1 dead out of 7 - a per-boot race at roughly the old 1-in-5..7 rate, and the reset wait alone does not close it.
- reset wait + your settle: every boot clean so far, soft and hard resets included; the counter keeps growing with daily use.
So both delays go to netdev together as a series once the with-settle counter is respectable; your Suggested-by is on the settle patch.
I'm waiting for a meaningful functional update for the RTL8367S-VB that meets the OpenWrt project's requirements. I'm available to test any changes and report or publish the results.
I have my first code attempts at: https://github.com/namiltd/openwrt/pull/134
Spent this round making sure the switch's VLAN handling runs fully in hardware, not through a software tagging workaround. Removed the opt-in 802.1Q software CPU-tag path (support opt-in standalone VLAN upper devices + its family D integration + the dsa-rtl8367d kmod) - it was already disabled by default after real-hardware testing showed it broke br-lan<vid>. With it gone, the switch relies purely on the native RTL8_4 hardware CPU tag plus its own hardware VLAN table for everything.
Re-tested on real hardware after removal: wan.<vid>, br-lan<vid>, and both together on the same port all now work cleanly through the hardware path alone - the combined case was actually broken before, from the software tagger racing the hardware VLAN filtering over the same tag protocol.
Would appreciate a review when you have a chance. Thanks!
Please group the fixes that directly apply only to the rtl8367s-vb and the rest that only apply to your router.
I see that my 6 patches are the basis. You've created more. I'd like to organize them.
Quick clarification on scope, since you asked to group by what applies where:
930-7 and 930-8 are RTL8367S-VB specific — a dedicated register init table and SDS13 PCS support respectively. Both are gated purely on chip_id/family, not on anything board-specific, so they belong alongside your 930-1..930-6: any board carrying this chip benefits from them
0966 is a different layer entirely — it's not about the switch, it's about the CPU-side conduit MAC (dwmac-ipq5018 on our SoC) not syncing its own hardware VLAN filter when VLANs come from bridge-vlan/switchdev membership rather than a plain kernel VLAN device. The RTL8367S-VB does its job correctly in that scenario; the drop happens one layer up, at the conduit. That one stays in our own tree — it's unrelated to which switch chip is attached.
Have you tested it without the 930-7-rtl8367d.patch.
In the rtl8367b driver, the initialization tables for the C and D families are the same.
you are right. I tested it thoroughly on real hardware and reached the conclusion that 930-7 is indeed unnecessary. However, i think 930-8 is strictly necessary for 2.5Gbps operation.
Maybe there is also some code in the 930-8 that could be removed or simplified