netdev - Re: [PATCH v2 0/5] net: qrtr: Add distant node support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMZdPi88N8WjA7ZEU0X_dhX_t-kXkAjhnhjzK7TY7HCurrLSqA@mail.gmail.com>
Date:   Tue, 10 Nov 2020 10:03:29 +0100
From:   Loic Poulain <loic.poulain@...aro.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     David Miller <davem@...emloft.net>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        cjhuang@...eaurora.org,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 0/5] net: qrtr: Add distant node support

Hi Jakub,

On Mon, 9 Nov 2020 at 19:39, Jakub Kicinski <kuba@...nel.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