<bamse>
CosmicPenguin: there's some changes in the hardware for doing LED patterns starting in pm8350c iiuc, which are not accounted for
<CosmicPenguin>
bamse: okay, so a bit of work is needed if one wanted to use the other channels on 8150l
<bamse>
CosmicPenguin: 8150l should just need to be plugged into the dt
<bamse>
CosmicPenguin: qcom,pm8150l in my driver is defined with 5 channels, with the first 3 being routed to the led sink
<CosmicPenguin>
bamse: right, my target has a fan on channel 5
<bamse>
CosmicPenguin: driven by a gpio/mpp?
<CosmicPenguin>
yeah, its uses pwm-fan
<bamse>
right, so then i expect that you need to setup your gpio/mpp pinctrl with the right function, and point your pwm-fan driver to your <&pm8150l_lpg 5> and it should just work
<bamse>
<&pm8150l_lpg 4> is perhaps the correct numbering
<CosmicPenguin>
I would need to set the triled_mask to something sane, I think
<bamse>
i would expect your case to be identical, just pwm-fan instead of pwm-backlight
<bamse>
gpio10 in my case is selected as func1 to be driven by the pwm output...which is bound to be channel 5 in my case as well
<CosmicPenguin>
yeah, thats the same for us too
<CosmicPenguin>
Okay, this seems like painful than I thought it would be - I'll give it a shot
<bamse>
so the &bl_pwm_default_state pinctrl state binds the gpio output to the pwm signal
<bamse>
i would say it's less painful than if you have to start hacking the driver ;)
<bamse>
CosmicPenguin: pretty much, copy the &backlight, &pmc8180c_lpg and &bl_pwm_default_state to your dts and adjust the compatibles as needed...and you should be done
<calebccff>
Hey all, I still sometimes get a crashdump mode on the op6 still, it only happens during boot when the modem services are starting up, this is the snippet i get in dmesg before it crashes: https://p.calebs.dev/e49352
<CosmicPenguin>
bamse: okay, cool. Thanks for confirming
<calebccff>
It happens maybe 1 in 10 boots, I'm at a bit of a loss for how to try and debug it, the error from the modem crash is a bit generic
<bamse>
CosmicPenguin: what does [ 41.465982] ueventd: LoadWithAliases was unable to load rpmsg:IPCRTR
<bamse>
sorry, calebccff
<bamse>
calebccff: does that imply that we failed to find a kernel module for rpmsg:IPCRTR (i.e. the qrtr.ko?)
<bamse>
calebccff: how long time after you booted the modem does this happen?
<calebccff>
bamse: yeah i think that's what it means, the qrtr module would have been insmod'd previously, I think aliases are stripped on my modules for some reason
<calebccff>
it must be within a few seconds of booting the modem
<bamse>
calebccff: okay, as long as the module is loaded that excludes a bunch of obvious issues :)
<bamse>
calebccff: is it possible to get hold of stdout/stderr from rmtfs? (in particular when run with -v)
<bamse>
that would tell us if the OS on the modem is up and running, or if it fails before that
<calebccff>
I'll edit the service to log to UART and try and trigger another crash
mort_8 has joined #linux-msm
mort_ has quit [charon.oftc.net helix.oftc.net]
aedancullen has quit [charon.oftc.net helix.oftc.net]
DavidHeidelberg[m] has quit [charon.oftc.net helix.oftc.net]
alexeymin has joined #linux-msm
DavidHeidelberg[m] has joined #linux-msm
aedancullen has joined #linux-msm
<Mis012[m]>
calebccff: did you look into the SSC on your unfused board?
* calebccff
can't make the modem crash anymore :<
<bamse>
calebccff: problem solved, my work here is done ;)
<calebccff>
Mis012[m]: as in, following your approach of monkey patching the hypervisor? no, supporting the SSC services from userspace is gonna be the way to go for sensors support
<calebccff>
bamse: heh :D
<Mis012[m]>
it's not monkeypatching
<Mis012[m]>
it's static configuration
<Mis012[m]>
which happens to be stored inside the ELF as an array of structs, but I digress
<Mis012[m]>
if we had the sources for the hypervisor, it would be a completely clean configuration change
<calebccff>
more simply: investing time to support the 3 devices which are SB-off (and coincidentally also very hard to get hold of) is not a good time investment, it's useless for the other 99.9% of devices, it also won't let us use features like pocket detection or lift-to-wake
<Mis012[m]>
well, I could probably try to invest that time myself if you were willing to as much as test it on sdm845... as for msm8998, the time was already invested
<calebccff>
or the pedometer, which, well what's a phone without a pedometer, may as well leave it at home
<Mis012[m]>
the same 3 devices are coincidentally the devices which will get custom (read sane) SSC firmware once I start working on that
<Mis012[m]>
but yeah, let's invest time into supporting ugly signed blobs, because ownership is dead and we might as well accept it?
<Mis012[m]>
now, you won't need to change the static configuration in the hypervisor if you just use different SSC firmware, I'll give you that
<calebccff>
if you really want to... patch the hyp fw for the SHIFT6mq and I'll test your kernel patches...
DavidHeidelberg[m] has quit [Server closed connection]
<calebccff>
i'd like to keep the 10's of millions of sdm845 devices that have secureboot out of landfill as much as possible, we gotta deal with what we've got
DavidHeidelberg[m] has joined #linux-msm
<Mis012[m]>
you can also find a vulnerability in the hypervisor, pretty sure there will be one since it's quite bloated
<Mis012[m]>
the hypervisor is SoC-dependent, not device dependent, so that much should be fine
<Mis012[m]>
as for the kernel patches, you'll probably still need to add sdm845 pdata to the tlmm driver, and figure out if the init sequence for the ssc bus is any different
<Mis012[m]>
so I assume you want me to do that as well?
<bamse>
calebccff: the problem we have in !android is that sensor data is supposed to come out of iio...but we don't have any solution that qualcomm has agreed on yet
<bamse>
calebccff: my hope was/is that we can get ssc firmware that just exposes the busses using virtio-i2c to apps...at least as stop-gap solution
<minecrell>
bamse: what's the advantage of that compared to just giving Linux access to the buses similar to whatever Mis012[m] has done? sounds like an easier job for qcom rather than implementing virtio-i2c
<calebccff>
bamse: huh i see, either way requires a userspace component on the AP right? i mean preferably we don't have to modify the SSC firmware at all, userspace can just use iio-proxy-daemon or w/e
<calebccff>
support in-kernel would require protobuf support in kernel at least based on my current understanding (which may be incorrect..)
<calebccff>
minecrell: doing what Mis012[m] has done would require patching the hypervisor, which isn't feasible for EOL devices
<minecrell>
calebccff: right, I was replying to bamse's "hope" of getting virtio-i2c
<minecrell>
which would also require modifications I'd say
<calebccff>
ah yeah i see, yeah
<calebccff>
support for form factor devices would be quite nice :>, at least easier to test than lifting my RB3 off the desk and shaking it around :X
<minecrell>
calebccff: if you wanted to support only that it would probably be easiest and cleanest to just reimplement the same DBUS interface in a different daemon, something other than IIO doesn't really fit to the name :p
<minecrell>
but there are probably also quite some applications out there that access IIO directly
<Mis012[m]>
calebccff: if the vendor doesn't wish to sign a patched hypervisor (and we could hack around the requirement of accessing the SINGLE memory range that has unrelated stuff), then we can require them give us their signing keys
<Mis012[m]>
*to give
<Mis012[m]>
minecrell: the advantage for qcom would presumably be that they bake it into the same ugly signed blob of SSC haxagon core fw
<minecrell>
Mis012[m]: there is an infinitesimal success chance for both of that (vendor signing something for $random-phone-user and vendor giving keys to $random-phone-sensor)
<minecrell>
*-user
<Mis012[m]>
minecrell: well.. the thing is, it's not random
<Mis012[m]>
you can look at the binary diff
<Mis012[m]>
and they could just do the same changes in source...
<minecrell>
uh, I'm not referring to diffs
<minecrell>
I'm referring to the random user that wants something signed
<Mis012[m]>
well... the fact that not doing that is legal is already troublesome
<Mis012[m]>
"you want keys for your own device? haha no"
<minecrell>
welcome to life then I'm afraid :/
<Mis012[m]>
minecrell: now, qcom could probably create a hypervisor call which will do the bus init (the part that I presonally do in linux) and then changes the smmu config so that Linux can access the SSC bus range but the SSC's hexagon core cannot
<Mis012[m]>
that would be a trivial thing for them to do
<Mis012[m]>
or for me to do if I had hypervisor sources :P
<minecrell>
Mis012[m]: I think qcom has open job listings, not sure if they let you do that though :P
<Mis012[m]>
I bet their listings are the same shit as everyone else's though... "you need to have job experience with C, but guess what, that's true for every job which would give you that experience"
<Mis012[m]>
I still wonder if I should have interpreted Linaro's "work experience with debian" as "experience with debian" to get myself on the "will at least reply to" list
<Mis012[m]>
calebccff: yeah, but it's not a bug, it's a lack-of-a-feature...
flto has quit [Ping timeout: 480 seconds]
flto has joined #linux-msm
threader has quit [Ping timeout: 480 seconds]
saddsaasd has joined #linux-msm
* saddsaasd
/ame https://worldhacker.org/index.php/irc-server/ COME TO Us , Let's Learn 0day together ... . everyone welcome , after audit ... . United Nations Candidate open now ...
saddsaasd has quit [autokilled: This host violated network policy. Mail support@oftc.net if you feel this in error. (2022-02-07 21:40:15)]
<Mis012[m]>
spam?
<Rayyan>
yes
<Rayyan>
it's in other channels as well
<Mis012[m]>
well, Matrix's ingore feature seems to work good enough with this frequency of spam, so meh
<Mis012[m]>
I assume it's not actual NSA recruitment wing spamming it? :P
<Mis012[m]>
wouldn't put it past them, but sadly I think they are well on the track with M$<3Linux type stuff
<Mis012[m]>
though at least there's ghidra
<Mis012[m]>
which is genuinely amazing
<Mis012[m]>
and considering what they probably use it for, surprisingly honest