Hi Jakub, On Mon, 9 Nov 2020 at 19:39, Jakub Kicinski <k...@kernel.org> wrote: > > On Mon, 9 Nov 2020 09:49:24 +0100 Loic Poulain wrote: > > > Looks like patch 1 is a bug fix and patches 2-5 add a new feature. > > > Is that correct? > > > > That's correct, though strictly speaking 2-5 are also bug fix since remote > > node > > communication is supposed to be supported in QRTR to be compatible with > > other implementations (downstream or private implementations). > > Is there a spec we can quote to support that, or is QRTR purely > a vendor interface?
There is no public spec AFAIK, this is a vendor interface. > What's the end user issue that we're solving? After firmware upgrade > things stop working? Things don't work on HW platforms on which this > was not tested? Don't work on new HW platforms? QRTR is usually something used in SoC context as communication protocol for accessing the differents IPs (modem, WiFi, DSP, etc) around the CPU. In that case, these components (nodes), identified with a 'node ID', are directly reachable by the CPU (QRTR over shared memory). This case is not impacted by the series, all nodes beeing CPU immediate neighbours. But today QRTR is no more a ARCH_QCOM thing only, It is also exposed as communication channel for QCOM based wireless modules (e.g. SDX55 modem), over PCIe/MHI. In that case, the host is only connected to the Modem CPU QRTR endpoint that in turn gives access to other embedded Modem endpoints, acting as a gateway/bridge for accessing non-immediate nodes from the host. currently, this case is not working and the series fix it. However, AFAIK, the only device would request this support is the SDX55 PCIe module, that just landed in mhi-next. So I assume it's fine if the related part of the series targets net-next. Regards, Loic
