mangix has quit [Remote host closed the connection]
Guest1646 has quit [Ping timeout: 480 seconds]
mangix has joined #openwrt-devel
ekathva has joined #openwrt-devel
<neggles>
grr. the regmaps between 8236 and 8327 are not as close as it initially appeared
gladiac is now known as Guest1648
gladiac has joined #openwrt-devel
Guest1648 has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest1649
srslypascal has joined #openwrt-devel
Guest1649 has quit [Ping timeout: 480 seconds]
<mangix>
neggles: why would they be?
<russell-->
they have similar digits!
<neggles>
mangix: the overwhelming majority are the same
<neggles>
and in fact, the registers themselves are nearly identical
<neggles>
but a couple of them have different base addresses >:(
<mangix>
i mean it's a 100mbps vs 1gbit switch
<neggles>
i'm just annoyed that it looked identical save for the L3 features (which aren't supported by DSA anyway) and 1G configuration (the bits are in the same place, but they're just 'reserved' on the 8236)
ptudor has quit [Ping timeout: 480 seconds]
<neggles>
but it's juuuuuuuust different enough that I dunno if I should duplicate-and-edit qca8k or work out how to handle different regmaps.
<neggles>
(in one driver)
<neggles>
duplicate-and-edit will be faster...
<mangix>
hmm isn't there already a dsa driver for the 8236?
<neggles>
stintel made one up for kernel 4.4, never made it into mainline
<neggles>
appears to also not have been ported up to 5.10
<mangix>
I was also thinking about https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=shortlog;h=refs/heads/dsa-ar9344 , but that seems different
<neggles>
why does it have it at 1f i wonder
<neggles>
yeah
<neggles>
tp-link's choice of switch chip here is honestly just mean.
<neggles>
who attaches an ancient QCA 10/100 switch chip to an armada 3720???
* mangix
is lost
<neggles>
mangix: it's a tp-link OC200
<neggles>
which is identical to the Armada 3720 ECK board, except only USB2.0 and with an AR8236 instead of the marvell 5x1G chip that's on the ECK
<neggles>
IMO it was purposefully kneecapped to discourage people from putting OpenWrt on it and using it as a router...
<mangix>
weird
<neggles>
I don't know why it even has two ethernet ports
<neggles>
it doesn't do anything with the 2nd port if you use it for what they meant you to use it for
* neggles
shrugs
<neggles>
i have duplicated qca8k.c/h and am going to pull out the 1G bits, change the relevant register base addresses, and if it works go from there
<mangix>
lol good luck
<mangix>
wonder if Ansuel figured out the performance stuff
<nick[m]1234>
neggles: can you mabye merge the initial ath79 commit. and afterwards we can try to convert to nvme cells? I don't know why it is not working. :/
<neggles>
heh I very much do not have commit access and that is probably for the best
<neggles>
let me take a quick look at what ath9k is doing
Tapper has joined #openwrt-devel
amaumene has quit [Ping timeout: 480 seconds]
amaumene has joined #openwrt-devel
<neggles>
nick[m]1234: it seems i have mislead you, based on what chunkeey did with the other netgears a few months ago
<neggles>
if that doesn't work i think the problem is the PCI device ID
<neggles>
which *should* be 0029
rua has quit [Ping timeout: 480 seconds]
<neggles>
for AR9220/9223
<neggles>
but yours is showing 168c:ff1d
rua has joined #openwrt-devel
<Slimey>
:)
<kabel>
blogic, nbd: could you find some time to look at rmk's RFC patches for mtk_eth_soc on netdev (phylink updates)? are you still interested in that driver?
pepe2k has quit [Remote host closed the connection]
<neggles>
nick[m]1234: i really don't know, but it might just be that it needs patching with your device ID
<neggles>
kmod-owl-loader appeared to be patching the device ID in your original boot log
<neggles>
and it's the only thing that's different
Tapper has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
Misanthropos has joined #openwrt-devel
<nick[m]1234>
I will have a look. However, I would be happy if we could already add initial support with kmod-owl-loader, since I urgently need those APs. ;)
<nick[m]1234>
any idea how I can obtain more useful debug outputß
Tapper has joined #openwrt-devel
<Slimey>
nick[m]1234 do you have pciutls installed?
<Slimey>
get output of pciutils -vvv
<Slimey>
err lspci -vvv
<nick[m]1234>
Slimey: already did this multiple times. :)
<Slimey>
sorry just now joining in :P
<Slimey>
what about that OEM cards option in menuconfig
<hurricos>
nick[m]1234: it's almost certainly some kind of cursed device tree parsing. Are you even sure ath9k is loading anything at all? If you remove the relevant device tree entries, is dmesg the same?
<hurricos>
neggles: oh boy, yeah, that's bcache all right
<hurricos>
that's raid1, too. Hmm, either I haven't tuned bcache well, or bcache is just bad at writeback.
<nick[m]1234>
hurricos: thanks. so I will wait what chunkeey is saying. However, the owl initial commit works :) So maybe this can already be merged until we find a solution that we can also use nvme? ;)
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
csharper2005 has joined #openwrt-devel
<Tapper>
Any one fixt ksmbd in master yet?
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
Borromini has joined #openwrt-devel
<aparcar[m]>
how do I refresh aka sort target/linux/generic/config-*? rsalvaterra ?
rua has quit [Ping timeout: 480 seconds]
<rsalvaterra>
aparcar[m]: Oh, I know that one! Let me see…
<aparcar[m]>
rsalvaterra: Thanks I'll check that in a bit!
<rsalvaterra>
Some Linksys AC routers are really unhappy with 5.15, most likely due to switch driver issues… and I don't have the hardware for testing. :(
<aparcar[m]>
yea we could use a build id based on e.g. our revision
<aparcar[m]>
me neither sorry...
<rsalvaterra>
I know you can't help too, no worries, but I thought you might know someone who could. :)
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<hurricos>
nick[m]1234: yes, merging now is honestly what I expect.
<hurricos>
If you're open about your awareness that it "oughta be converted to nvmem-cells" at some point, and even potentially ping e.g. chunkeey or ansuel in your Github PR, you'l catch their attention and they'll step in and try to help you get it working.
<hurricos>
If that fails, the habit is usually to give up and "merge something which works, but non-ideally."
<hurricos>
I suggest mentioning the missing bit in the commit itself; commits have a wider audience and someone else may notice what you were looking to do, find the right answer, and reach back out to you with a patch that gets things working.
<hurricos>
It's not the ideal workflow, but it keeps things moving even when authors such as you or I, who have less experience working with these things, still are prepared to get something 99% working and test / own that pocess.
<hurricos>
RE: <and they'll step in and try to help you get it working> I don't say this becasue that's the role they own or what we should all demand they do, I just mean in general, you want to work with the folks who are working on standarizing the tree, cleaning things up and getting good replacements for hacks upstream to the actual kernel
<hurricos>
because they almost always want to work with you, since it's better to have someone test a change than just make the change and wait until someone tells them what they broke.
<hurricos>
or, like, allowed to stop working. You can't really "break" something that has no user-maintainership.
<mangix>
rsalvaterra: unfortunate
<mangix>
aparcar[m]: I don't have a Mac. Need ssh access to see what's happening.
<mangix>
Upstream has a cmake based build. Wonder if it makes sense to back port.
<nick[m]1234>
hurricos: looks good. I will rewrite the commit message with more detailed information that in the future should be convrted to nvme cells, and then ping them, and then I hope its gets merged.
dedeckeh has quit [Remote host closed the connection]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<mangix>
aparcar[m]: oh cool. wrapdb also has a meson port you could try to apply.
nixuser has quit [Remote host closed the connection]
nixuser has joined #openwrt-devel
ekathva has quit [Remote host closed the connection]
robimarko_ has quit [Quit: Leaving]
srslypascal is now known as Guest1717
srslypascal has joined #openwrt-devel
philipp64 has joined #openwrt-devel
Guest1717 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Quit: Leaving]
srslypascal has joined #openwrt-devel
<hanetzer>
hrm. annoying news. the tp-link eap660-hd has what appears to be a uart (unpopulated), but there appear to be missing resistors on the data and power lines :(
<slh>
tp-link is known to cripple the serial console
<hanetzer>
the bastards also put one of the case screws under a sticker.
<slh>
that would worry me less than crippling the serial console
<slh>
one of the bigger reasons why I discarded the archer c2600 from my selection in 2017 (and went with ZyXEL's nbg6817 instead(
<hanetzer>
so. question. ipq40xx and ipq806x exist. the compatible string from the dtb I extracted for this device is qcom,ipq807x. Does this warrant a new 'target/linux/ipq807x' dir?
<slh>
a (source-only) ipq807x target has already existed before - and hopefully comes back in the near'ish future again, with support for the xiaomi ax3600/ ax9000/ ax6, qnap qhora 301w, edimax cax1800, edgecore eap102, ...