<jstultz>
bamse: hey! how's it going? was curious: I noticed db845c is still coming up with a random wifi mac each boot. I know you had a solution long ago, but I can't remember the details
<jstultz>
I feel like we had some serialno based calculation to come up with a unique but consistent mac
<bamse>
jstultz: hey, nice to see you around again :)
<bamse>
jstultz: i don't remember having something for wifi, i did the ethernet mac address stuff
<jstultz>
bamse: oh, maybe that was it..
<jstultz>
bamse: i feel like we had something for wifi too, but maybe that was an android userland thing..
<bamse>
jstultz: that might be the case
<bamse>
jstultz: i believe the downstream solution relies on some files written in the factory and some userspace tooling to configure the interface on every boot...
<jstultz>
bamse: i also had a work wifi router that was inbetween my regular network previously, and i'm really only noticing now because my main router is yelling that new devices are connecting to my wifi all the time :) so maybe it was the same before, I just didn't notice it
<bamse>
yeah, that's definitely annoying
<bamse>
or the fact that your ssh known_hosts fills up with all these random devices
<jstultz>
bamse: i'll check in with pundir to see if he recalls. (luckily i don't have to ssh to the device)
<jstultz>
bamse: not having my decade old inbox to search for these details is exposing how bad my memory is
<Mis012[m]>
jstultz: I think the "cleaner" way to do this is to have the bootloader put the mac address in the device tree
<Mis012[m]>
and I believe there was some emmc serial number calculation for when you don't want to fetch the magic file
<jstultz>
Mis012[m]: no doubt - though with the number of different ways dtbs are managed, having that work consistently may be tough
<Mis012[m]>
well, the bootloader is already responsible for adding stuff to `chosen` for example
<jstultz>
Mis012[m]: ok, maybe its simpler then I'm thinking..
<jstultz>
Mis012[m]: does that work for appended dtbs? I thought the loading there was all kernel based.. but I'm probably wrong.
<Mis012[m]>
well... there is an option for arm (not 64) to do it without bootloader
<Mis012[m]>
since some old arm devices never got bootloaders which know what a device tree is
<Mis012[m]>
but on aarch64, it's always handled by the bootloader
<jstultz>
Mis012[m]: ah, I'm confusing it.. cool, that's good to know.
<Mis012[m]>
minecrell implemented this in lk2nd iirc
pevik has joined #linux-msm
<minecrell>
Mis012[m]: no, this was some patch someone at Linaro made for the db410c LK actually
<Mis012[m]>
this is with every single clock entry commented
* Mis012[m]
afk
dliviu has quit [Read error: No route to host]
dliviu has joined #linux-msm
<konradybcio>
Hmm, isn't that for dt clocks= source lookup?
<konradybcio>
(i dont have the source before my eyes rn)
<konradybcio>
Try leaving just one in
<konradybcio>
For example that qdss, since you know it makes no difference
svarbanov has quit [Remote host closed the connection]
lumag__ has quit [Ping timeout: 480 seconds]
pespin has quit [Remote host closed the connection]
jhovold has quit [Ping timeout: 480 seconds]
lumag__ has joined #linux-msm
pevik has joined #linux-msm
<calebccff>
elder_: IPA wakeups work \o/ I set up a connection with netcat over mobile data on my OnePlus 6 and then put it in suspend, sending data from the server to device caused it to wake up and immediately receive the data
<elder_>
Well that's nice...
<elder_>
I didn't expect it to work quite right, but hey, I won't complain
<calebccff>
haha
<calebccff>
i really can't thank you enough
<calebccff>
so, we can wake up the device for network notifications but it can't wake up for texts or calls
<elder_>
IPA only does IP traffic
<elder_>
Calls most likely go via some other mechanism.
<calebccff>
glink or something I think? I asked bamse about it before
<elder_>
I might have thought texts could go through IP but ultimately SMS might have its only channel (maybe on the same channel as phone calls?)
<calebccff>
huh SMS over IP sounds fun
<calebccff>
elder_: is it possible to have the IPA also handle wifi data?
<elder_>
I don't think so.
<elder_>
As I understand it some sort of WiFi stack runs on the modem. I don't know how that data gets to the AP.
<elder_>
Maybe it's possible but I don't know how, and if it is, it's not going to be supported any time soon...
<Mis012[m]>
elder_: it seems to me that the atheros firmware (the one running on the PCI-E card) was ported as a hexagon userspace app
<elder_>
Sounds about right.
<Mis012[m]>
at least that's how it is on 8998
<Mis012[m]>
elder_: it's so weird to think that the internal registers are all in Linux's address space, but I assume there are some realtime requirements :P
<elder_>
I know basically nothing about it...
<calebccff>
elder_: thanks a lot for your help, and for making all this cool hardware work :)
<elder_>
I'm glad it's working for you. It's really nice to learn things are working on hardware I haven't directly used.
<Mis012[m]>
I wonder if atheros counts as SDR...
<Mis012[m]>
since that would make having fun with it legally challenging
<konradybcio>
calebccf, calls go through mpm
<Mis012[m]>
the what
<konradybcio>
the gic abstraction layer
<konradybcio>
so that your ap doesn't have to be on 24/7
<Mis012[m]>
mpm is not exactly "gic abstraction layer"
<calebccff>
also it seems like runtime PM kills the IPA ~10 seconds after suspend, it needs to support not disabling the IPA if there's some connection open I guess
<Mis012[m]>
afaik mpm is an umbrella term for power management related hw
<Mis012[m]>
mpm interrupt is for all intents and purposes an interrupt with wake capability
<Mis012[m]>
the relevant part is still what triggers that interrupt
<konradybcio>
i mean, the interrupt part is what matters to you in the end
<Mis012[m]>
well, magic SSCAON registers also matter to me, but maybe that's just me :P
<Mis012[m]>
seems 845 hyp doesn't use any magic SSCAON registers
<Mis012[m]>
*though
<konradybcio>
845 doesn't have mpm anymore
<konradybcio>
pdc
<konradybcio>
as do rpmh platforms
<Mis012[m]>
I've seen some hints that mpm-like stuff is done in sw
<Mis012[m]>
konradybcio: eh... so just uncommenting `[RPM_SMD_QDSS_CLK] = &msm8916_qdss_clk,` results in reeeeeeeeeboot
<konradybcio>
is it true for any other random rpmcc clock?
<Mis012[m]>
I really don't feel like testing "any"...
<konradybcio>
test 2, then test n+1 and call it mathematical induction ;)
<Mis012[m]>
xD
<konradybcio>
cmon
<Mis012[m]>
contrary to popular belief, mathematical induction is not magic :P
<konradybcio>
there's a finite number of cases
<konradybcio>
and recompiling just clk-smd-rpm and re-linking the kernel should take no more than like 10 seconds
<Mis012[m]>
it's finite but arbitrarily large
<Mis012[m]>
btw I've shrunk my ext2 image to 100MiB
<Mis012[m]>
to lower the damage
<Mis012[m]>
heuristics ftw
<Mis012[m]>
`[RPM_SMD_RF_CLK3_A_PIN] = &msm8998_rf_clk3_a_pin,` doesn't cause an issue
<Mis012[m]>
probably related to the fact that it's not mentioned anywhere outside that place and the header
<konradybcio>
ok, try enabling the rest of pinctrl clocks
<Mis012[m]>
>the rest of pinctrl clocks
<Mis012[m]>
??
<Mis012[m]>
if you mean TLMM, those are definitely hw voted
<konradybcio>
no, they are called rpm pinctrl clocks
<konradybcio>
in the driver, even
<Mis012[m]>
weird name choice, any etymology for it?
<bamse>
calebccff: in general, call handling and texts communication is encoded using qmi, then send over qrtr, on top of glink or smd
<calebccff>
bamse: right, the modem surely supports firing an IRQ to wake up the AP for an SMS or incoming call though?
<bamse>
calebccff: glink works by filling up shared memory buffers and then kicking an ipc-interrupt related to the other side
<Mis012[m]>
well... the main interrupt probably won't be wakeup-enabled though?
<bamse>
calebccff: so the modem will kick smp2p and that in turn will trickle up to glink
<Mis012[m]>
since you don't want every shmem message to wake up the AP
<bamse>
Mis012[m]: it is, if you send a glink message the other side will be woken up
<Mis012[m]>
weird, I'd think there would be a lot of chatter going on there that is not wakeup worthy
<bamse>
the bulk of the communication is ap-driven, the rest is considered wakeup-worthy...and then there's some corner cases
<Mis012[m]>
I guess another way to handle this would be for the other core to check if AP is sleeping, potentially for how long already, and then decide based on that if sending a message is such a great idea
pevik has quit [Ping timeout: 480 seconds]
<bamse>
right, there are a few such cases
<bamse>
and there are a few cases where ap will send a pause/start message as it's going to sleep/waking up
<Mis012[m]>
you wouldn't happen to know why removing uefi from the boot process makes rpmcc act up?
<bamse>
what do you do instead of uefi?
<Mis012[m]>
u-boot
<Mis012[m]>
same u-boot chainloaded in boot.img doesn't manifest this problem
<bamse>
cool, but unfortunately there's too much things going on in that black box for me to have any good suggestions :/
<Mis012[m]>
well, I could even read the code if I thought it would help, but `grep` says it's not worth it
<Mis012[m]>
no rpmcc stuff seems to be like actually used
<Mis012[m]>
should really get some pogo pins already, I always forget to order tham
<Mis012[m]>
*them
<Mis012[m]>
aand a reboot after `[ 0.408847] vgaarb: loaded`
<Mis012[m]>
let me guess which one it was...
<Mis012[m]>
fwiw while I don't think that a missing parent should cause this, it's highly improbable that every clock managed by that driver has xo as direct parent...
<Mis012[m]>
I'd expect better of mainline than "it works, who cares it's objectively wrong"
<Mis012[m]>
would be nice to have an excuse to fix that though ngl
<Mis012[m]>
instead of this being something more obscure
<Mis012[m]>
ok, so we have the true culprits isolated