Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver

On Wed 10 Feb 12:41 CST 2021, Jakub Kicinski wrote:

On Wed, 10 Feb 2021 11:55:31 +0530 Manivannan Sadhasivam wrote:

quoted

On Tue, Feb 09, 2021 at 08:17:44AM -0800, Jakub Kicinski wrote:

quoted

On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote:  

quoted

This may be a stupid suggestion, but would the integration look less a
backdoor if it would have been named "mhi_wwan" and it exposed already
all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just
QMI?  

What's DIAG? Who's going to remember that this is a backdoor driver 
a year from now when Qualcomm sends a one liner patches which just 
adds a single ID to open another channel?  

I really appreciate your feedback on this driver eventhough I'm not
inclined with you calling this driver a "backdoor interface". But can
you please propose a solution on how to make this driver a good one as
per your thoughts?

I really don't know what bothers you even if the userspace tools making
use of these chardevs are available openly (you can do the audit and see
if anything wrong we are doing).

What bothers me is maintaining shim drivers which just shuttle opaque
messages between user space and firmware. One of which definitely is,
and the other may well be, proprietary. This is an open source project,
users are supposed to be able to meaningfully change the behavior of
the system.

You're absolutely right in that we in general don't like shim drivers
and there are several examples of proper MHI drivers - for e.g.
networking, WiFi

Technically we could fork/reimplement
https://github.com/freedesktop/libqmi, https://github.com/andersson/diag
and https://github.com/andersson/qdl in the kernel as "proper drivers" -
each one exposing their own userspace ABI.

But to leave these in userspace and rely on something that looks exactly
like USBDEVFS seems like a much better strategy.

What bothers me is that we have 3 WWAN vendors all doing their own
thing and no common Linux API for WWAN. It may have been fine 10 years
ago, but WWAN is increasingly complex and important.

We had a deep discussion and a few prototypes for a WWAN framework going
around 1-1.5 years ago. Unfortunately, what did fit Intel's view of what
a WWAN device is didn't fit at all with what's run and exposed by the
"modem" DSP in a Qualcomm platform. After trying to find various
contrived ways to model this we gave up.

quoted

And exposing the raw access to the
hardware is not a new thing in kernel. There are several existing
subsystems/drivers does this as pointed out by Bjorn. Moreover we don't
have in-kernel APIs for the functionalities exposed by this driver and
creating one is not feasible as explained by many.

So please let us know the path forward on this series. We are open to
any suggestions but you haven't provided one till now.

Well. You sure know how to aggravate people. I said clearly that you
can move forward on purpose build drivers (e.g. for WWAN). There is no
way forward on this common shim driver as far as I'm concerned.

But what is a WWAN device? What features does it have? What kind of APIs
does it expose?


Note that in this sense "QMI" really is a "binary equivalent" of AT
commands, the data flows over a DMA engine, which is not part of the
"WWAN device" and other services, such as GPS, already has specific
transports available upstream.

Regards,
Bjorn