<arnd>
http://ix.io/3qMO was the fix: the problem is that you cannot pass a pointer to a local variable into an SDIO transaction, it has to be a buffer that was allocated with kmalloc() or similar
<arnd>
xradio_reg_read or __xradio_read is what you have to patch
<arnd>
I don't have that code in front of me
<arnd>
warpme_: if that's too complicated at the moment, then you can work around it temporarily by turning off CONFIG_VMAP_STACK. The code is still wrong in that case and might cause silent data corruption, but it's not worse than it was in the past
<apritzel>
warpme_: if I were you I wouldn't spend too much time on *this* driver
<warpme_>
apritzel: oh. i see your point....but "forget this driver" situation is since years. and i have already 3 boxes with unusable wifi with this chip. i'm playing with code used by armbian - so it looks like armbian guys have quite the same motivation like me. by this (in my limited view) i don't see better alternative than playing with code used by armbian and tying to get it working with 5.13.
<apritzel>
well, but this won't improve the situation: it will still bitrot, until the next kernel change
<apritzel>
what I meant is to join forces with plaes and jernej to get their approach upstream
<warpme_>
apritzel: for sure. that will be optimal!
<arnd>
how does the version from karabek relate to the one from fifteenhex?
<arnd>
Ah, I see karabek forked their version from fifteenhex in June 2017, and both versions have commits after that
<apritzel>
arnd: yeah, diverging forks, and both not upstreamable :-(
<apritzel>
that's why I wanted to prevent warpme_ creating yet another one
<arnd>
apritzel: sure, I was just wondering which of the two would be more appropriate as a base if one gets put into drivers/staging/
<arnd>
or, if they could be merged first
<warpme_>
arnd: i recall (v.rusty memory): some users were reporting fifteenhex works really well (2.4 & 5) with a,b,g while karabek had issues with n.
<warpme_>
arnd: if i can only get code working - for sure i can do some tests and report here....
<warpme_>
now i'm rebuilding 5.13 with CONFIG_VMAP_STACK unset. If this will work - them i can try play code mods to avoid pass a pointer to a local variable into an SDIO transaction. (any proposal of proper code changes are much welcomed as i have a small fraction of your's skills here :-p ))
<arnd>
warpme_: from the history, I can see that karabek has added more commits, but they are mostly cosmetic in nature, updating the readme or making it build on newer kernels, while fifteenhex has added merged more patches that do something interesting
<warpme_>
indeed - that's why armbian goes with fifteenhex i think
<apritzel>
what's with plaes' version? Can't someone take this and rebase it on top of latest fifteenhex or karabek
<arnd>
I would suggest patching__xradio_read_reg32/ __xradio_write_reg32, using a kmalloc(sizeof(u32), GFP_ATOMIC)/kfree
<warpme_>
apritzel: imho best will be to get most used (armbian code) working on 5.13 and then backport "reasonable" commits from other repos. My logic is baed in assumption armbian is most tested code base.
<arnd>
apritzel: that part of the cw1200 driver that plaes patched is already quite different from the fifteenhex/karabek versions
<warpme_>
saying tested: i mean compat with various AP
<apritzel>
warpme_: but I think we already established that those BSP based drivers have only a slim chance of being upstreamed?
<apritzel>
so I think we need something that is closer to the cw1200, either by enhancing the existing mainline driver (jernej's work) or by moving those BSP drivers closer to the cw1200 (plaes' approach)
<warpme_>
apritzel: bsp here?
<warpme_>
ah ok - you are going cw1200 route.
<apritzel>
*I* am not going anywhere, but I think that's the most promising approach for getting something upstream
<warpme_>
only thing intriguing me is: past 5y: any xr819 works I'm aware were works on various forks of the same 6..7y old initial driver code forked from cw1200. Code was forked - not extended. Why forked?: I see 2 hypothesis here: 1\devel. strategy was: get first working clean reference code for xr819 alone then use it to extend cw1200; 2\foreseen divergence between cw1200 and target xr819 was so big that - for clarity &
<warpme_>
maintability - better will be go with dedicated xr819 driver. As in last years nobody started/resume to address 1\ - probably 2\ is more probable....or 1\ is Ok - but there is no "resources" in community to do this....
<mripard>
warpme_: allwinner usually writes new drivers even if they could leverage another existing one
<mripard>
I guess it's easier for them to work in silos
<mripard>
so I'm not saying they didn't consider your second option, but the first is much more likely
<warpme_>
arnd: after CONFIG_VMAP_STACK unset i went a bit further:
<mripard>
gamiee: isolation from the rest of the kernel
<gamiee>
Ahh, thanks :)
<apritzel>
warpme_: don't try to read too much sense into what Allwinner does ;-)
<mripard>
yeah, there's a lot of examples where they pulled 1 off, even for simple things: uart, i2c, gmac, musb, etc.
gsz has joined #linux-sunxi
<karlp>
warpme_: jerne had a patch that _fixed_ the kmalloc issue, didn't arnd link it? that's a better starting point that trying to unset VMAP_STACK and pretending it's not an issue...
<arnd>
warpme_: the patch looks roughly ok, if there is a remaining problem with stack data, you get the same backtrace with CONFIG_VMAP_STACK=y (which you should enable again now)
<arnd>
warpme_: not sure where that cpu_to_le32() comes from though, if you think that is needed, that should be a separate patch, as this is unrelated
<warpme_>
arnd: as you see above - patch works (in a sense that i'm able on xr819 to scan wifi networks, connect and get ip via dhcp). re: cpu_to_le32() - only reason i saw it on other drivers. iirc arm can be switched to run in LE and BE mode - so i was thinking correct code should be ready for 2 cases. But I agree: i'll remove it as on little endian systems it does nothing and isn't that Linux is default LE on arm?.
<apritzel>
warpme_: yes, the driver should be endian-safe (even though this is practically irrelevant these days), the question is just whether this is the right way to do it
<apritzel>
warpme_: and as arnd said: it should be a separate patch
<warpme_>
apritzel: yes. for sure. fyi: for 2.4GHz/n AP standard it reports:
<arnd>
warpme_: if adding it here is required, then it's probably also needed elsewhere in the driver. Regardless of that, adding endian-conversion must be a separate change from the dma fix
<warpme_>
plaes: i went with this fork as it is most popular: used by armbian
<warpme_>
arnd: fyi: hmm. after enabling VMAP_STACK no good (probably still issue):