<bamse>
calebccff: i don't know if anything has changed...
<calebccff>
bamse: If i understand correctly the concern was that upstream wanted to automatically detect if this needs to be skipped?
<bamse>
that's my understanding as well
<bamse>
or in particular, that it should be encoded in the firmware-N.bin file
<bamse>
but we already have a quirk for the firmware incompatibility on db845c/rb3...
<calebccff>
hmm, i struggle to understand the reasoning for that, are there any devices where one particular firmware version needs the quirk and another doesn't?
<calebccff>
yes that as well, it seems similar to the 8-bit quirk
<bamse>
i think kalle's idea is that if you bump the firmware this problem would go away, but by encoding it in the .dtb we have created an external dependency on the particular behavior
kholk has joined #linux-msm
<bamse>
calebccff: kalle's argument is valid, but i don't think the scenario will happen :(
<calebccff>
yeah i definitely understand the argument, but I think you're right. The PocoPhone F1 is the only device I'm aware of needing this quirk, and it no longer receives updates...
<kholk>
hello! Marijn[m] showed me a msm8976 dtsi patch a minute ago.... just wanted to tell you guys that I do have a fully functional Xperia X (8956) on next-20221028... and most of the mistakes that are present in the dtsi that was sent out were fixed months ago (but eh, we never published that version)
<calebccff>
ah Xiaomi Polaris (Mi Mix 2S) also needs it, i guess it's a trend with sdm845 xiaomi phones
<kholk>
I was thinking that we could send out whatever is immediately upstremable from our devicetrees superseding the series that was sent by Adam... let's say on friday or something....
<calebccff>
it would be nice if we could drop the patch in our tree, I'll maybe bump the thread
<kholk>
well, s/our/my/g
<kholk>
just avoiding duplicate work :)))
<calebccff>
bamse: I've been hitting this odd issue on a few devices where using this particular SIM card breaks the modem, I hacked some debugging into rmtfs and I see this in a loop: https://p.calebs.dev/27c739@raw
<calebccff>
without my hacks it was the same behaviour. It seems like it fails to parse the QMI data properly for some reason
<calebccff>
Allocating the rmtfs_open_req object on the heap fixed it, so I guess it could be some odd stack bug with musl, but nobody else seems to have hit the issue
<calebccff>
the modem now boots and no longer crash loops, however wifi never starts up, this is the output of qrtr-lookup: https://p.calebs.dev/3b9488@raw is is possible to get more information about the state of the modem?
Caterpillar has quit [Remote host closed the connection]
<mal>
I tested with rc3 and with just the matisse-wifi device tree patches: without those above patches qcom-smem probe fails but after adding those patches it boots successfully
<mal>
probably would be nice to get those driver patching to next rc if possible
<mal>
the latter of those patches I linked is actually needed to cleanly apply the first patch so that makes adding both even more logical
<mal>
but looks like there is no review in mailing list for that "hwspinlock: qcom: add support for MMIO on older SoCs"