PkChU has quit [Read error: Connection reset by peer]
PkChU has joined #openwrt-devel
PkChU has quit [Read error: Connection reset by peer]
PkChU has joined #openwrt-devel
PkChU has quit [Read error: Connection reset by peer]
PkChU has joined #openwrt-devel
PkChU has quit [Read error: Connection reset by peer]
PkChU has joined #openwrt-devel
PkChU has quit [Read error: Connection reset by peer]
PkChU has joined #openwrt-devel
Tapper has quit [Ping timeout: 240 seconds]
PkChU has quit [Read error: Connection reset by peer]
PkChU has joined #openwrt-devel
PkChU has quit [Client Quit]
PkChU has joined #openwrt-devel
PkChU has quit [Client Quit]
PkChU has joined #openwrt-devel
PkChU has quit [Read error: Connection reset by peer]
philipp64 has quit [Quit: philipp64]
PkChU has joined #openwrt-devel
PkChU_ has joined #openwrt-devel
PkChU_ has quit [Read error: Connection reset by peer]
PkChU has quit [Ping timeout: 252 seconds]
PkChU has joined #openwrt-devel
PkChU has quit [Read error: Connection reset by peer]
PkChU has joined #openwrt-devel
PkChU has quit [Client Quit]
Tapper has joined #openwrt-devel
DonkeyHotei has quit [Ping timeout: 240 seconds]
whyz has quit [Ping timeout: 260 seconds]
zkrx has quit [Ping timeout: 265 seconds]
hbug__ has joined #openwrt-devel
hbug_ has quit [Ping timeout: 240 seconds]
goliath has quit [Quit: SIGSEGV]
zkrx has joined #openwrt-devel
Tapper has quit [Ping timeout: 240 seconds]
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
<guidosarducci>
aparcar[m]: Thanks for the libelf/libdw update, Paul! I think there's nothing now stopping review/merge of https://github.com/openwrt/openwrt/pull/3855, correct?
andi- has quit [Remote host closed the connection]
andi- has joined #openwrt-devel
<aparcar[m]>
guidosarducci: the buildbots need to update first
<mangix>
anyone know how to get the build system to use homebrew binaries instead of local ones?
CrazyLemon has quit [Ping timeout: 250 seconds]
danitool has quit [Ping timeout: 240 seconds]
ashkan has quit [Ping timeout: 268 seconds]
valku has quit [Quit: valku]
slh64 has joined #openwrt-devel
philipp64 has joined #openwrt-devel
philipp64 has quit [Client Quit]
philipp64 has joined #openwrt-devel
philipp64 has quit [Remote host closed the connection]
philipp64 has joined #openwrt-devel
rmilecki has joined #openwrt-devel
CrazyLemon has joined #openwrt-devel
ivanich has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
noltari has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
Ycarus_ has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
Ycarus has quit [Ping timeout: 246 seconds]
opal has quit [Remote host closed the connection]
opal has joined #openwrt-devel
Borromini has joined #openwrt-devel
danitool has joined #openwrt-devel
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
nucleo has joined #openwrt-devel
<xdarklight>
Hauke: I wonder if PHY auto polling might not work for some PHYs: https://brpaste.xyz/rVwaUA/raw - this is from a AR8030 RMII (10/100) PHY which has 1000Base-X and 1000Base-T in the extended status register (0xf). symptoms seen: the port seems completely deaf
<xdarklight>
Hauke: the old driver was not using auto polling but configuring the PHY/MAC settings individually - so I wonder if that's something we should do as well. Doing that will probably also get us support for fixed-links at the same time without any extra code
snh_ has joined #openwrt-devel
snh has quit [Ping timeout: 240 seconds]
snh_ is now known as snh
<Hauke>
xdarklight: could you check the status registers of the auto polling
<Hauke>
for such a phy
<Hauke>
xdarklight: the diagramm "Auto Polling FSM - Main Loop" inducates that auto polling is deactivated when REG0 is 0xffff
<xdarklight>
Hauke: that would be GSWIP_MAC_PSTATp(port) I assume?
<Hauke>
I was wrong it just stops the current loop when it reads 0xffff
<Hauke>
not the polling over all
<Hauke>
but GSWIP_MAC_PSTATp(port) is interesting
<Hauke>
I mean MMDIO_STAT_(port)
<xdarklight>
I think there's different names for the same thing. in lantiq/target/linux/ltqcpe/files/include/switch_api/VR9_switch.h from the TD-W9980 UGW it's called VR9_MAC_PSTAT_* and has similar bits than MMDIO_STAT in the GSW140 datasheet
<Hauke>
ok
<Hauke>
I think AR8030 is detected as a gigabit phy
<Hauke>
at least when I do the same thing as described in the state machine of the PHY polling
<xdarklight>
that's what I thank as well and I believe it's GSW's fault since BMSR_ESTATEN for the PHY is 0 (so I think it should not be trying to read reg15 / 0xf)
<xdarklight>
if set to 1 then the MII_ESTATUS register (reg15 / 0xf) is read and used
<Hauke>
thanks
<Hauke>
BMSR_ESTATEN is set to 1 in your paste
<Hauke>
REG1== 0x796d
<Hauke>
If BMSR_ESTATEN is set the polling assumes a GE PHY
<xdarklight>
oops, your're right. I was off-by-one
<xdarklight>
Hauke: so conclusion is: for some PHYs which are probably (slightly) out-of-spec we need to switch from auto polling to software configuration?
<xdarklight>
Hauke: AFAIK phylink takes the info from the PHY and the MAC -> only what both have in common is considered supported. and there we don't advertise the Gbit/s modes on the MAC side, so I assume that's where they are filtered out
<Hauke>
xdarklight: I was just confused beacsue linux has defines the same bits multiple times in ADVERTISE_
<xdarklight>
heh, I never noticed these duplicates
<Hauke>
the AR8030 datashaeet says they are using the 10 and 100 MBit/s here
<Hauke>
this should be printed when MAC and PHY have no common settings
<Hauke>
xdarklight: what device shows this problem?
<xdarklight>
Hauke: FritzBox 7360v2 is showing the problem on the two RMII ports (both are completely deaf: traffic sent by another device is not showing in ethtool -S at all and vice versa. checked also with tcpdump)
Borromini has quit [Ping timeout: 260 seconds]
<mgiganto>
does anybody know how to configure a bridge with the router ports using vlan filtering? each time i try something, either the bridge is not configuring the ports, or vlans, or lan ports are down... in the end I don't get a simple base config that stays when I reboot it
<Hauke>
xdarklight: I will just order one it is 20€ and I do not have a device with FE ports
<xdarklight>
Hauke: jwh is not in this channel but he can probably provide you access to his
<xdarklight>
Hauke: I already asked him to apply https://pastebin.com/iAubzkkq and show me the output of "ethtool -d lan4" (one of the non-working ports)
<Hauke>
I found the device for 17€ including shipping
<Hauke>
if you buy 4 you get a discount ;-)
<xdarklight>
Hauke: I decided not to buy one since I already have too many devices...
<Hauke>
xdarklight: I am tring to get a remote controlled lab working
<Hauke>
with labgrid
<Hauke>
but I also hav a lot of devices here
<xdarklight>
Hauke: nice. I bought an 8 port relay and stuffed some devices in the free areas of a PC case. then I'm using https://github.com/xdarklight/arduino_pdu_rly together with pdudaemon to control power to the boards
<xdarklight>
Hauke: the relays are taking 5V or 12V from the PC'
<xdarklight>
PC's power supply
dangole has quit [Ping timeout: 246 seconds]
<Hauke>
xdarklight: does a normal PC power suppy prove 5V and 12V without problems like some controlls from the PC?
<xdarklight>
Hauke: so far I had zero problems with this but mostly I am running Amlogic SoC based boards in there which are typically designed to run off 5V 2A USB. 12V should be no problem at all because PC PSUs provide most power on the 12V rail(s)
<Hauke>
ok
<Hauke>
is there power just there when you switch on the PC power supply?
<Hauke>
it does not want to talk some special protocol with the PC mainboard
<xdarklight>
Hauke: yes and no. you need to short two pins or get one of these ATX power supply breakout adapters which come with a power-on switch/button (which does just connects the two pins together)
<xdarklight>
Hauke: jwh has not replied back on the debug registers yet (I think he's in a different timezone, somewhere across the pond from us). currently I am trying to fix what I believe is a reset GPIO problem for the IP101 RMII PHY on my O2 6431
dangole has quit [Remote host closed the connection]
<xdarklight>
Hauke: I still don't have any feedback from jwh. as soon as he replies I'll ask him to test it
<Hauke>
ok
goliath has joined #openwrt-devel
Kamilion has quit [Remote host closed the connection]
Kamilion has joined #openwrt-devel
<xdarklight>
Hauke: first update from my HH5A: your patch doesn't break anything ;-)
muhaha has joined #openwrt-devel
muhaha has quit [Quit: Connection closed]
danitool has quit [Ping timeout: 240 seconds]
danitool_ has joined #openwrt-devel
sbrown has quit [Quit: Leaving]
whyz has joined #openwrt-devel
danitool_ has quit [Ping timeout: 240 seconds]
danitool has joined #openwrt-devel
ashkan has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<Hauke>
xdarklight: are there any other problems with the lantiq DSA driver except the problems with some external PHYs?
dangole has joined #openwrt-devel
<xdarklight>
Hauke: a) some 7412 user is reporting random disconnects b) fixed-links are not working yet but required for adding support on the Fritz 7490 (and others) c) RGMII RX/TX delays need to be configurable for Fritz 7490 (and others) support
<xdarklight>
Hauke: a) is a bit strange because it's just the internal PHY22F. the others are "new features" so nothing that I am too worried about right now
<xdarklight>
Hauke: also I got the debug registers from jwh on his 7360v2: https://brpaste.xyz/6qsruA/raw - that loks like it detected a Gbit/s connection. I'll ask him to apply your other patch now
<xdarklight>
it's seeing 0x0d38 in the MAC_PSTAT register -> my understanding is: BIT(11) means that it detected the PHY, BIT(10) means that it thinks that there should be a Gbit/s link
<Hauke>
0x0d38: BIT(6): PHY status active, it looks like the PHY is not detecetd as active
<Hauke>
the rest looke like garbage, links is up, but speed is set to reserved
<xdarklight>
Hauke: according to the TD-W9980 and Fritz 7490 source code BIT(6) is TXPAU (Transmit Pause Status)
<xdarklight>
Hauke: maybe the bit meanings have changed between the xRX200/xRX300 GSWIP and GSWIP120/GSWIP140?
<Hauke>
BIT(9) and BIT(10) are not avalibale on xrx200
dangole has quit [Remote host closed the connection]
SamantazFox has joined #openwrt-devel
<xdarklight>
these two I am already reading
dangole has joined #openwrt-devel
<Hauke>
what is the value of GSWIP_MAC_CTRL_0p of for the RMII port?
<xdarklight>
GSWIP_MAC_CTRL_0p = 0x0180 and GSWIP_MAC_CTRL_2p = 0x005
<xdarklight>
I'd say that the value for GSWIP_MAC_CTRL_0p looks appropriate: everything on AUTO, FCS enable and PADEN enabled (same as the old out-of-tree driver configured)
<Hauke>
looks good, speed is set to auto
dangole has quit [Remote host closed the connection]
<Hauke>
xdarklight: makeing it possible to configure the RGMII RX and TX delay is not hard
<Hauke>
I can add it
<Hauke>
the problem with the 7412 looks strange to me too
dangole has joined #openwrt-devel
<xdarklight>
Hauke: if the GSW120/140 documentation is also valid for xRX200/xRX300 then indeed it's easy to implement the GSWIP driver bits. but I am not sure if that is something which should come through gswip_phylink_mac_config (in struct phylink_link_state) or if the driver needs to parse the .dts itself and then do it's own magic
<Hauke>
xdarklight: yes the part is the same
<Hauke>
I think we have to parse this manually, when I grepped to code it looks like we haev to parse the dtb manually
<xdarklight>
Hauke: for the existing code you are right but I think this is something that will be added to phylink sooner or later. but I'm not sure about the plans for the phylink maintainers
<Hauke>
yes
<Hauke>
xdarklight: is there already a discussion?
<xdarklight>
Hauke: I haven't checked
<ashkan>
where can I find some documentation on procd_open_validate/procd_close_validate/procd_add_validation ? I don't seem to find any commits regarding it.
<xdarklight>
Hauke: hmm, I'd be surprised if it's related to the 7360v2 problem because there two external RMII PHYs are involved, whereas 7412 uses the internal PHY22F GPHY