<digitalcircuit>
I'm a bit late to Ansuel's ping from 5 days ago (was out on a trip, sorry) - it seemed like it was in response to f00b4r0 mentioning a router crash..?
<digitalcircuit>
On my side, good news on the IPQ806x CPU crash reset bug - I've been running the 22.03rcX series for months without issue, currently up to 25 days uptime on 22.03.0-rc6 (I've rebooted for non-CPU-crash reasons, and I'll upgrade to 22.03.0 soon, probably tonight).
<slh>
:)
hanetzer1 has joined #openwrt-devel
hanetzer has quit [Ping timeout: 480 seconds]
hanetzer2 has joined #openwrt-devel
hanetzer1 has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest858
srslypascal has joined #openwrt-devel
Guest858 has quit [Ping timeout: 480 seconds]
valku1 has joined #openwrt-devel
valku has quit [Read error: Connection reset by peer]
valku1 is now known as valku
<\x>
hi, so how does linux can handle some weird wireless rules in my country, theres this rule where youre only limited to 250mW indoors but you can actually go beyond that for outdoor operations.
karim has quit [Read error: Connection reset by peer]
karim has joined #openwrt-devel
srslypascal is now known as Guest878
karim has quit [Read error: Connection reset by peer]
srslypascal has joined #openwrt-devel
karim has joined #openwrt-devel
Guest878 has quit [Ping timeout: 480 seconds]
<hurricos>
Slimey: I think so, and the 2030 are the same P101* but with a QCA9880 instead of all ath9k chips
karim has quit [Read error: Connection reset by peer]
karim has joined #openwrt-devel
valku has quit [Quit: valku]
danitool has joined #openwrt-devel
<PaulFertser>
hanetzer: hey :) remember we talked about posting your guest article on OpenOCD blog? Can I help anyhow with that? BTW, others are welcome too.
<hanetzer>
PaulFertser: mostly a matter of putting something worthwhile together.
<PaulFertser>
hanetzer: feel free to ping me if you want any review or help with rst syntax etc.
<hanetzer>
will do.
Tapper has quit [Ping timeout: 480 seconds]
<Borromini>
robimarko: any gotchas i should be checking for in particular for the RB5009UG with 5.15?
<Borromini>
I know you said 5.15 in your tree wasn't ready for prime time so to speak, I assume 5.15 being testing on mvebu doesn't really change anything about that since the RB5009UG isn't in-tree?
<Borromini>
i'm looking at what's in 6.0-RC5 compared to 5.15 when it comes to the Amethyst switch
cbeznea has joined #openwrt-devel
Tapper has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
cbeznea has quit [Quit: Leaving.]
<mrnuke>
Is the "Bootlogs" section required for device pages on the wiki?
karim has quit [Read error: Connection reset by peer]
<robimarko>
hurricos: Yes, but depending on the bus it could take some time
<robimarko>
But the expander driver should handle probe defferal
<hurricos>
Do you see what I've messed up in my device tree? :\
<robimarko>
Borromini: I cant really point in you in any specific direction
<hurricos>
Maybe I should shift the content of the &i2c0 bit back into the main i2c0 node.
<f00b4r0>
mrnuke: no, it's purely cosmetic
<robimarko>
hurricos: I doubt you messed up the DT
<robimarko>
Since your expander is under the I2C bus node
<hurricos>
Right, but in any case my dmesg -- https://paste.c-net.org/PeepingLowlifes -- shows the PXA driver for this TI TCA6416 -- linking onto the i2c bus before it exists
<hurricos>
unless that last message -- "i2c-gpio i2c: using lines 1 (SDA) and 2 (SCL)" -- would show up *after* i2c-gpio init?
<robimarko>
hurricos: Looks like the PCA953x driver is not being a platform driver, but rather using __init and __exit
<robimarko>
AFAIK, that does not work with probe defferal
gladiac has quit [Quit: k thx bye]
<hurricos>
eww
<hurricos>
OK, so there are other ath79's which use the same driver
<hurricos>
qca9531_dlink_dch_g020-a1.dts, e.g.
<robimarko>
I think there is a place in the core that prints whether probe deferal has been requested
<robimarko>
As it should be requested due to missing bus
<robimarko>
I had a similar case before where probe defferal did not work and had to convert the driver to a platform one
<hurricos>
I'm not that advanced. At this point I feel like I should just reorganize the guts of the device tree to tweak the init order. I know this is fragile, though
<hurricos>
The other thing that bothers me is that i2cdetect / i2cget doesn't see either the expander or the RTC
<robimarko>
hurricos: No, and no
<robimarko>
DT tweaking wont make the driver probe earlier
<hurricos>
Strange, because target/linux/ath79/dts/qca9531_dlink_dch-g020-a1.dts uses the same setup. It must be variables outside our control which make it work.
<hurricos>
(different cpu, potentially different compile order at the time of PR merge)
<robimarko>
Well, no probe order is guaranteed by the kernel
<hurricos>
oh.
<robimarko>
Especially if async probe is enabled
<robimarko>
So, you can compile it however you want, its the kernel which picks hows it gonna probe
<hurricos>
OK. On the other hand, I know (by tracing lines) that I have the right SDA and SCL lines to both i2c devices, yet i2cdetect sees neither. I'm guessing i2cdetect is not "wizard magic" (because i2c devices speak in very specific ways)?
<hurricos>
just to avoid going down the path again of disassembling and re-tracing.
<Habbie>
i2cdetect sends a mostly-harmless message hoping the device will respond, iirc
<hurricos>
got it
<robimarko>
Yeah, and it probes differently based on the address
<robimarko>
Some get probed with read/write while others with the fast variant
<robimarko>
hurricos: Please update the GPIO bindings under I2C gpio
<robimarko>
You are using the legacy binding
<robimarko>
And, can you also measure if there is a pull-up on both lines?
<robimarko>
As I had a weird case on a DGS-1210 where SDA has a pull-up while SCL does not
rua has quit [Quit: Leaving.]
<hurricos>
You're right RE: legacy, I don't know why I cliked the first documentation link I could find.
<Ansuel>
well rip think my r7800 is dying... 2 port dead out of lightning and now the other port can't keep connection more than a minute o.O
rua has joined #openwrt-devel
<robimarko>
hurricos: You are basically just missing the (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)
rua has quit []
<hurricos>
I know these are GPIO_ACTIVE_LOW, getting to grips with pull-up resistors ... so I should be checking the potential between unplugged I2C line and ground
<hurricos>
to see if I get 3v3 or floating
<hurricos>
3v3 = pull up, floating = none
<hurricos>
thaknfullly these are connected via headers
<robimarko>
hurricos: They are (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)
<robimarko>
By definition
<robimarko>
That is how kernel configures/means open drain
<hurricos>
Huh. But the u-boot sources for this say that these i2c lines are active low?
<robimarko>
I get you, they are active low in reality
<hurricos>
Oh, I'm misundersatnding - active low means that a state is drained when low. By default it's inactive, so high, b/c pull-up
<hurricos>
OK, last issue is getting the TI GPIO expander to delay probe. So I guess I'll have to either do some trickery or convert to a platform driver to get this working at all :\
<hurricos>
Oh, the ethernet PHY must be on the i2c bus somehow.
<hurricos>
or some other trickery is going on in the config of the gpio expander to let it directly control the eth LEDs
<hurricos>
anyway
<PaulFertser>
PHY is usually connected using MDIO (MDC + MDIO) which is kinda similar to I2C but not quite it.
<PaulFertser>
(of course some *MII also goes to PHY for data transfer)
<hurricos>
Well, reading the GPIO state shows that when I force the ETH LED down, bit 9 stays at 0x00
<hurricos>
I think the PHY knows how to chatter with the expander
<hurricos>
doesn't make much sense as i2c is not designed to do this
<hurricos>
No, it's probably reading that LED line in off the PHY's GPIO out
<hurricos>
much more sensible, just not sure why they'd bother to read that LED
<hurricos>
s/LED/line/
robimarko has quit [Quit: Leaving]
kyle_swenson has joined #openwrt-devel
kyle_swenson has quit []
<Mangix>
alright. time to do the unthinkable and get rid of sys/queue.h
Lynx- has joined #openwrt-devel
<Lynx->
auc build cache issue again a la: /home/aparcar/asu/worker1/cache/22.03-SNAPSHOT/mediatek/mt7622/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/tmp/openwrt-22.03-snapshot-r19718-0c9833d0e0-646933086007-mediatek-mt7622-linksys_e8450-ubi-squashfs-sysupgrade.itb.its:17.11-19.6: Warning (unit_address_vs_reg): /images/kernel-1/hash@1: node has a unit name, but no reg or ranges property
<Lynx->
so it gets stuck writing using auc and ctrl-c reveals errors like that
winternull has quit [Quit: Leaving]
<Ansuel>
but that is a warning o.O
<Ansuel>
Mangix context?
Lynx-- has joined #openwrt-devel
Lynx- is now known as Guest886
Lynx-- is now known as Lynx-
Guest886 has quit [Read error: Connection reset by peer]
<Mangix>
Ansuel: in the musl bump to 1.2, I got rid of all custom headers that OpenWrt adds to musl, except one because too much software broke
<Mangix>
time to check again
<Ansuel>
oh no
<Mangix>
?
<Ansuel>
anyway think i have to chose a new router rip...
Lynx-- has joined #openwrt-devel
Lynx- is now known as Guest887
Lynx-- is now known as Lynx-
<Ansuel>
any advice?
Guest887 has quit [Read error: Connection reset by peer]