<aka_[m]>
ERROR Timeout! No SMD response to req 2 in 10000ms
<aka_[m]>
req 2 is WCN36XX_HAL_STOP_REQ
<vknecht[m]>
just a suggestion : I had crashes recently where the used compatible was not the right one, could be you have to check where 8976 chip stands wrt. last year improvements to wcn36xx driver
<aka_[m]>
it supports dual band so has to be either 3660b or 3680
<vknecht[m]>
ie. new features used while they're not supported, firmware bug to be accomodated with, etc.
<Mis012[m]>
firmware bug? just update the - oh wait
<aka_[m]>
wcnss: IRIS Reg: 04000004
<aka_[m]>
#define WCN3660B 0x0400
<aka_[m]>
only one thing is im not sure if i should provide clocks for that
<aka_[m]>
it has " with 48MHz XO"
<Mis012[m]>
the binding should tell you if it expects clocks I guess?
<vknecht[m]>
one thing to check : wcn36xx_dbg_mask = 0xffffffff, it should show "feature bits"
<Mis012[m]>
and presumably downstream would need to touch them if it's necessary
<Mis012[m]>
vknecht[m]: is that a euphemism for errata? :P
<vknecht[m]>
could also try setting 3660 (without b), and 3620, see if it still crashes
<vknecht[m]>
more like seeing capabilities advertised by firmware, iiuc
<Mis012[m]>
and the fw gets those based on if something was fucked in hw to make stuff not work, or it feels entitled to say
<Mis012[m]>
* to say "will not do X even if hw supports it"
<Mis012[m]>
* to say "will not do X even if hw supports it"?
<vknecht[m]>
couldn't say, but I suggest you get in touch with bryanodonoghue for further debugging, he knows more ;-)
<Mis012[m]>
I guess it's qcom hw, so it's possible you can use it in multiple way
<Mis012[m]>
*ways
<aka_[m]>
vknecht: still failing with 3660
<aka_[m]>
it support 5Ghz so it cannot be it
<Mis012[m]>
missing capability that the driver assumes is present would probably be a nice and easy fix
<Mis012[m]>
but murphy can't have that can he
<vknecht[m]>
could be more like advertised-firmware-capabilities <-> wcn36xx driver incompatibility, there were struct changes not so long ago, and something might not pass anymore
<vknecht[m]>
don't presume too much, I was certain I had a 3680 since device had 5GHz, but firmware not advertising dot11ac limited it to 3660b, or something like that
<vknecht[m]>
get the log with debug, and show it to Bryan, I'm certain he'll know how to move forware
<vknecht[m]>
*forward
<aka_[m]>
And how to get that?
<aka_[m]>
Kernel conf I see
<aka_[m]>
its enabled already...
<bryanodonoghue>
hi aka_[m]
<bryanodonoghue>
hi aka_
<bryanodonoghue>
we should really pull firmware feature bits out via debugfs come to think of it
<bryanodonoghue>
but
<bryanodonoghue>
for the moment we just want to see the fw feature bits reported
<bryanodonoghue>
and the SHA for your wcn36xx driver
<bryanodonoghue>
i.e. what's the last wcn36xx commit you have in your tree ?
<aka_[m]>
I use next branch from 23.03 and I kinda lost wifi functionality somewhere during 5.15 or so as I found some photo of my device with 5.16_rc8 and it had wifi not working already.
<aka_[m]>
5.13 was working already.
<aka_[m]>
Sadly I cannot do much now, I'm in bed already and out of reach of pc.
<aka_[m]>
* 5.13 was working fine.
<aka_[m]>
Sadly I cannot do much now, I'm in bed already and out of reach of pc.
<aka_[m]>
How do I fetch this info?
<aka_[m]>
I have kernel config enabled but I always had issue understanding how to get logs out of debugfs as I don't see any folder with wcn36xx in /sys/kernel/debug
<aka_[m]>
Ok my bad 5.15_rc4 probably worked just fine.
<bryanodonoghue>
aka_ feel free to ping me a full kernel log at my email address