ChanServ changed the topic of #linux-msm to:
<bamse> DylanVanAssche: that's funny, it's supposed to allow you to change the node id...but i would not be surprised if it hasn't been tested since ~2016...
<bamse> DylanVanAssche: but, as i said...that is not your problem...
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
<DylanVanAssche> bamse: I'm trying to grasp what the problem actually is, but not sure where to begin.
junari has joined #linux-msm
Tooniis[m] has joined #linux-msm
<Tooniis[m]> bamse: interesting, so you can make your service look like it's being served by a different processor?
enok has quit [Remote host closed the connection]
enok has joined #linux-msm
<aka_[m]> Any idea if gpu can reprobe if it fails grabbing fw(=y vs fw on rootfs)
<aka_[m]> tried to boot sm6115 device and its stuck with console on screen
<aka_[m]> konradybcio: have you seen dwc3 4e00000.usb: failed to enable ep0out on lenovo?
<bamse> DylanVanAssche: looking at the kernel code, the source address/port is assigned by the kernel, and you can't bind to a node different from local_node_id...so it seems to be that you're being delivered a message from node 1 port X, and you read that as node 0 port 1...
<bamse> Tooniis[m]: yeah, in the same way as you can use ifconfig to choose a different ip address...
<DylanVanAssche> bamseSo the problem is somewhere in the routing in the kernel code probably? The code maybe assumes always to have a modem present on node 0 resulting in these routing decisions?
<bamse> DylanVanAssche: but you said you get this message from modemmanager?
<bamse> DylanVanAssche: and no, the kernel does not know that the modemmanager has anything to do with the modem services, or that this is usually found on node 0...
<DylanVanAssche> bamseI have libssc using libqmi sending the message to ask the DSP for available sensors to discover (first message to find available sensors, after you get a reply, more are send, but no reply yet). https://codeberg.org/dylanvanassche/libssc
<DylanVanAssche> bamseLibssc has a testing tool called 'ssccli' which simply enables/measurements/disable a sensor for 10 seconds. This is what I use. Libssc uses libqmi to create and send QMI messages/
<DylanVanAssche> bamseI want to mock the DSP part now with a QRTR server running on the same Linux host to have some unittesting. This server receives messages send by libssc/libqmi, but the replies from the server never end up with libqmi/libssc again
<bamse> DylanVanAssche: okay, makes sense... so when libssc wants to communicate with your service, it will invoke the socket(AF_QIPCTRTR,...) call to get a socket fd, it will then send one or more messages to "localhost" port 0xfffe (iirc) requesting information about where to find the node and port numbers of the services that it's looking for
<bamse> DylanVanAssche: the qrtr nameserver (in kernel) will respond with the list of registered services and their node/port information
<bamse> DylanVanAssche: libssc will then either create another socket, or use that same...craft a message and sendto() that node and port
<bamse> DylanVanAssche: upon either calling bind() to attach the socket to a specific port, or by invoking sendto() the kernel associates the socket with a node and port...here the node can not be different from the local node id (i.e. 1)
<bamse> DylanVanAssche: libssc will end up in qrtr_sendmsg(), which will determine that this is a "local delivery" and queue the message in your service's incoming queue
<bamse> DylanVanAssche: you then call recvmsg (or one form thereof)...to receive the message from the queue...
<bamse> DylanVanAssche: the source node id and source port has been filled in based on the sending socket's information
<bamse> DylanVanAssche: how big is a c_int? is it guaranteed to be the same size as an uint32_t?
<DylanVanAssche> bamsec_int: https://docs.python.org/3/library/ctypes.html#ctypes.c_int
<DylanVanAssche> There's a specific c_uint32 though...
<DylanVanAssche> bamseReplaced c_int by c_uint32, no diff.
<bamse> how about the fact that you're passing 4 arguments into a function that takes 5 then? ;)
<bamse> there should be a buffer_size as 3rd argument
JIaxyga[m] has joined #linux-msm
<JIaxyga[m]> Can anyone with sc7280 read /proc/cpuinfo? I want to make sure that there are cortex a55 and a78 cores for fixing PMU in the SC7280 DTS
<DylanVanAssche> Which function :) ? bamseqrtr_sendto has 5 args?
<DylanVanAssche> bamseAh wait! The receive one you mean :O Let me try some stuff!
<DylanVanAssche> bamseI now get `node c_uint(1) port c_uint(16387)`. This is WAY better. Still need to figure out how to get the length back of the buffer as it returns still `0` but message is successfull.
<DylanVanAssche> bamseQMI transaction is now a success instead of timeout :) Now I need to send some QMI indications to the same client with the actual data. By saving the node and port it should be possible I think
<bamse> DylanVanAssche: qrtr_recvmsg() should return the number of bytes it put in the buffer...
<bamse> DylanVanAssche: happy to see that you can exchange your messages though :) now you just need to deal with the qmi encoding in python
<DylanVanAssche> bamseQMI encoding/decoding already works with some unittests in Python :) This is the missing piece! Yeah indeed, it should return it, will look a bit further why it happens, not a big problem as qmi decoding of 0x0 is ignored anyway
<DylanVanAssche> bamseAh I see where I got this... The QRTR Python example has only 4 args for the recvfrom (no length) and the length is determined as the return value. https://github.com/linux-msm/qrtr/blob/master/qrtr.py#L84-L85
ungeskriptet has quit [Quit: The Lounge - https://thelounge.chat]
ungeskriptet has joined #linux-msm
<bamse> DylanVanAssche: you're right, recv() has the sz, but recvfrom() does not :(
<DylanVanAssche> bamseI figured out the length problem. The length is given as return value, the arg that is missing in the Python example is the buffer length of the buffer that is passed to it. Will make a PR to fix :)
<bamse> DylanVanAssche: quickly after writing that, we switched to an all-python implementation, with dict<->qmi decoding/encoding logic etc... got af_qipcrtr support into the python project...but both of us who poked at this left Sony before we got approval to publish that...
<bamse> DylanVanAssche: that would be much appreciated, so we save the next guy from running into this issue!
<DylanVanAssche> bamseOh using Python dicts would have been nice, my code works for my project, but isn't that abstract so it can be used with dicts. Currently, I encode TLVs manually, taken from how libqmi does it. Libqmi generates them automatically though, I do it manually
<bamse> it was super nice to prototype things that way...maybe not robust enough for something in production, but that wasn't the goal
<DylanVanAssche> Yeah totally :) same reason why I picked Python now for unittesting, so much easier to iterate compared to C
<bamse> in particular if you don't have a development environment on the target...
<DylanVanAssche> bamsePatch sent! https://github.com/linux-msm/qrtr/pull/34
junari has quit [Read error: Connection reset by peer]
<aka_[m]> There is led controller driver which seems to be IP base for one i have in my device.
<aka_[m]> According to vendor sheet its main use was meant to be backlight controller, is it suitable to convert this driver into backlight device or im supposed to write second driver?
<aka_[m]> LM36923 to be specific
<aka_[m]> it seems with some magic of capitalism this design was implemented as SGM37603 from China
<aka_[m]> funny i can see mentions of registers from even older chips like lm3533