<elder_>
aka_[m]: The only place I see that flag used is in drivers/platform/msm/ipa/ipa_v3/ipa.c downstream (where the property becomes a Boolean gsi_ctx->per.skip_ieob_mask_wa). It applies to GSI v2.2 and v2.5, which are used on IPA v4.2 and v4.5. This was added to the downstream code and I was not informed about it, so it isn't upstream.
<elder_>
It occurs when the current channel mode is getting reconfigured from polling to callback mode; this is not how the upstream code works, so without finding out more about the details of the issue, and thinking through why it's done downstream, I can't even comment on whether it applies upstream. If it does, it seems it's only on IPA v4.2 and IPA v4.5 (and their corresponding GSI versions).
<elder_>
The switch in mode corresponds to re-enabling the interrupt after the end of NAPI polling. So it might in fact apply. Now that I know about it, I'll try to find out more.
<aka_[m]>
well i will see how it works in action probably, but first need to bring modem.
<Mis012[m]>
more like sboot off or specific test keys
<z3ntu>
aka_: no it has proper secure boot
<Mis012[m]>
interesting, also abominable of FP to do that
jhovold has quit [Ping timeout: 480 seconds]
<Mis012[m]>
I mean, it could possibly be signed solely by qcom, and the modem could accept that
<Mis012[m]>
¯\_(ツ)_/¯
<Mis012[m]>
it's several layers removed from xbl-sec/xbl.elf singnature checking, it doesn't need to care about the secure boot fuse at all
<Mis012[m]>
but since it gets loaded by/to modem, it probably is singature checked in some way
<Mis012[m]>
*signature
<Mis012[m]>
possibly even on devboards, which would be sad
<aka_[m]>
<z3ntu> "aka_: no it has proper secure..." <- proper so you can sign your own things and enforce secure boot?
<z3ntu>
just standard qualcomm stuff, a.k.a private key by odm blown in I guess the fuses
<Mis012[m]>
that's not proper, that's scummy AF
<z3ntu>
go shout at qualcomm
<Mis012[m]>
FP can do whatever the fuck they want to
<aka_[m]>
still FP can release their signed bootloader
<aka_[m]>
even if secondary
<aka_[m]>
and enforce some custom secure boot
<z3ntu>
ok I'll stop responding if you're just complaining. have fun :)
<Mis012[m]>
there is MBA, there is NO REASON WHATSOEVER they should blow those fuses
<Mis012[m]>
z3ntu: look at what google is doing
<Mis012[m]>
with chromebooks
<Mis012[m]>
it was FP's choice to blow those fuses, yes qcom probably told them that it's a great idea, but at the end of the day it's their call
<Mis012[m]>
there's a script to blow the XBL_SEC_AUTH_DISABLE in chromebook-tailored BSP, which sure makes me wonder if by any chance the SoCs do indeed come from qcom without the fusing that disables blowing that fuse
<Mis012[m]>
also aleph security could easily be the sole reason that qcom decided to be more aggressive in convincing OEMs to blow secure boot fuses
<Mis012[m]>
z3ntu: arguably it's also FP's choice to base their design off of QRD, which makes it illegal for them to share said schematics, but all I'd ask there is being honest about it and not pretending that it isn't an option
<Mis012[m]>
s/said/the/
<Mis012[m]>
something like "the device would cost $XXX dollars more if we did that, and most of the people who say they would pay that much extra for it would actually not"
<Mis012[m]>
unless it'a actually cheaper than I imagine, in which case it would be harder to excuse I guess
<Mis012[m]>
but it's probably a non-trivial amount
<Mis012[m]>
could do that calculation based off of some device they're no longer selling since it amortizes over all the units
<Mis012[m]>
when a team at bloody google gets this...
<minecrell>
bamse: Could you still pick up some of my msm8909 changes? https://patchwork.kernel.org/project/linux-arm-msm/list/?q=msm8909 The qcom soc one is mostly just one liners (btw, I would expect you to take the entire series but some of the patches are marked as non-applicable there for some reason?) I'm trying to get the DT changes ready so this would
<minecrell>
help a lot :)
<konradybcio>
sm6375 is in the same boat if you would like to pick up even more oneliners :D
<bamse>
minecrell: i should be able to do that, will take a look
<minecrell>
thanks :)
<bamse>
minecrell: i have a thing that automagically mark patches that i'm not going to apply to the qualcomm tree as not applicable, based on file path
<bamse>
minecrell: do you have something that i'm expected to apply that's incorrectly marked as such?
<minecrell>
bamse: it's the generic dt-bindings arm cpus.yaml, I think
<minecrell>
and devicetree/bindings/power/qcom,rpmpd.yaml
<bamse>
minecrell: ahh, it's not unlikely that i have skipped that in my file glob