03:12 <bamse> minecrell: the advantage is the solution is pretty much drop-in...while exposing the hardware directly requires a bunch of new stuff exposed in linux

11:07 <Mis012[m]> bamse: you would still need linux-side drivers...? or would that be in userspace

11:08 <Mis012[m]> bamse: in any case, exposing it in Linux is cleaner, and I already wrote the drivers

15:44 <bamse> Mis012[m]: i definitely would need linux-side driver as well...it's just that they already exist

15:45 <bamse> Mis012[m]: or could be wirtten as normal iio drivers and reused by others

15:45 <Mis012[m]> bamse: my driver allows reusing existing iio drivers, how's that worse?

15:46 <Mis012[m]> could probably also reuse existing BLSP drivers fwiw, but still not sure about the interrupt lines

15:52 <bamse> right, the iio drivers would be the same between the two cases...and the i2c bus could be handled by virtio-i2c on the linux side

15:52 <bamse> i don't know what kind of flexibility you have on the interrupt routing, but that would be quite neat

15:53 <bamse> i just see the drop-in ssc firmware as a somewhat easier path to push out broadly...but i guess it doesn't matter as long as the platform vendor isn't playing along

15:56 <Mis012[m]> bamse: I mean, I will be looking into making foss ssc firmware at some point, but arguably changing a few lines in the ssmu config array in hypervisor sources would be a lot simpler

15:58 <Mis012[m]> would still need to add a hypervisor call for enabling the one clock that is not in it's own smmu zone, but it's not that hard either

17:27 <deathmist> and I'll never see this on my retail MSM8998 device with secure boot enabled :/

17:27 <minecrell> Mis012[m]: I'd kind of expect that there is something funny to route the interrupts. I mean, 8916 has something funny to route UART and I2C interrupts to wcnss and I have no idea why qcom considered that useful

17:30 <minecrell> same for modem actually

17:32 <minecrell> the registers are called like TCSR_PHSS_UART_MSS_INT_SEL (see APQ8016E TRM)

17:33 <minecrell> eh, HRD actually

17:33 <minecrell> Although I guess you want the reverse

17:35 <minecrell> I guess if anything except APQ8016E had documentation you'd just read that to have the answer :/ This kind of stuff is briefly mentioned in the docs

17:42 <Mis012[m]> minecrell: there *are* such registers, but not for the interrupts that I am interested in afaict

17:43 <Mis012[m]> deathmist: I can send you hypervisor elf with debugging symbols if you want to look for a vulnerability

17:46 <Mis012[m]> LPASS, SSC and MSS

17:46 <Mis012[m]> neither one is the one that I care for :P

17:48 <deathmist> @Mis012 you really think I could find anything? I barely managed write a simple kernel driver...

17:49 <Mis012[m]> well, that's a completely different skillset :P

17:49 <minecrell> Mis012[m]: I think I'm not gonna click that link, but it would be fun if this was actually a regular blsp thing and it's just routed to SSC with such PHSS registers

17:50 <Mis012[m]> well... it definitely is a regular BLSP thing, the only question is how the interrupts are routed

17:51 <Mis012[m]> and I can promise you that the link only contains non-copyrightable facts :P

17:51 <Mis012[m]> it's an excerpt from the FLAT

17:51 <Mis012[m]> but with my gedit highlighting

17:52 <Mis012[m]> so it's quite a bit more pleasant to read

17:52 <minecrell> shrug, I have limited interest in the newer platforms anyway so no need to risk anything :)

17:54 <bamse> deathmist: unfortunately you won't have the custom ssc firmware signed for your 8998 device either...so neither option is likely to work for you

17:55 <Mis012[m]> worst case could swap the SoC

17:55 <minecrell> Mis012[m]: still waiting for you to proof that this is feasible xD

17:55 <Mis012[m]> best case would probably be figuring out that they used a strap and not the fuse

17:55 <Mis012[m]> but that's not exactly likely

17:56 <Mis012[m]> minecrell: just the issue with msm8998 is that it's PoP

17:57 <minecrell> Mis012[m]: Fair enough, I would be also convinced if you replace the 8916 in your samsung-a3

17:57 <minecrell> iirc 8916 is not

17:57 <Mis012[m]> yeah, it's not

17:58 <Mis012[m]> but I'm not sure if you can do it by hand

17:58 <Mis012[m]> guess it might be small enough

17:58 <Mis012[m]> will you buy me a hot air station so I can try? :P

17:59 <minecrell> if you give me the money I suppose I could buy it for you

17:59 <Mis012[m]> don't think that counts :P

18:03 <Mis012[m]> minecrell: hm, there is no TCSR_PHSS_UART_APSS_INT_SEL on msm8916 either

18:03 <Mis012[m]> how does that work then

18:06 <minecrell> Mis012[m]: The interrupts seem to go to both APSS and TCSR, and TCSR can distribute them to other peripherals. See e.g. figure 6-38 on page 1768 in the TRM

18:07 <Mis012[m]> hm, right

18:07 <minecrell> so I suppose it's not impossible that if they considered SSC to be the main target for the SSC-specific BLSP, that there might be no way to route it to APSS

18:11 <Mis012[m]> huh, 8916 QUP already had NOISE_REJECTION? :D

18:12 <minecrell> Not aware of any usages of that though

18:17 <Mis012[m]> good, that means there is no shitty board design happening :P

18:17 <Mis012[m]> >For recovery, retransmit the data and revise the hardware.

18:18 <Mis012[m]> like the data was so important that it has to be retransmitted even though the prototype should clearly be scrapped :P

18:22 <Mis012[m]> minecrell: hm, so it seems that QUP1_IRQ is directly connected to both APSS and TCSR

18:23 <minecrell> yes, that's what I said right? :D

19:24 <Mis012[m]> I hoped there would be some mux

19:24 <Mis012[m]> so that I can find it based on register name :P