Hello, Il giorno dom 13 dic 2020 alle ore 15:22 Manivannan Sadhasivam <manivannan.sadhasivam@xxxxxxxxxx> ha scritto: > > On Fri, Dec 11, 2020 at 08:08:16PM -0800, Jakub Kicinski wrote: > > On Fri, 11 Dec 2020 11:37:34 -0600 Dan Williams wrote: > > > Just to re-iterate: QMI ~= AT commands ~= MBIM (not quite, but same > > > level) > > > > > > We already do QMI-over-USB, or AT-over-CDC-ACM. This is QMI-over-MHI. > > > > Why do we need a different QMI-over-X for every X? If you say there > > are already chardev interfaces to configure WWAN why not provide one > > of those? > > > > Just because the underlying PHY is different and it offers more services than > just configuring the modem (downloading crash dump, firmware download etc...) > > The existing chardev nodes are closely tied to the physical interfaces. For > instance, /dev/cdc_wdm is used by the USB based WWAN devices. So we really can't > reuse it for MHI/PCIe. > let me also add that the current MHI UCI approach makes sense because it makes the switch USB -> PCIe smooth, since all the current open-source userspace tools (e.g. libqmi and qmicli), according to my testing until now, properly works without any need for a change, behaving the UCI QMI char device like cdc-wdm. While a different solution (which one?) would maybe cause to re-think the userspace side for having the same high-level behavior. Thanks, Daniele > > > It's not networking data plane. It's WWAN device configuration. > > > > Ack. Not that network config doesn't fall under networking, but eh. > > I wonder - did DaveM ever ack this, or was it just out of his sight > > enough, behind the cdev, to never trigger a nack? > > > > > There are no current kernel APIs for this, and I really don't think we > > > want there to be. The API surface is *huge* and we definitely don't > > > want that in-kernel. > > > > It is what it is today for WWAN. I don't think anyone in the > > development community or among users is particularly happy about > > the situation. Which makes it rather self evident why there is > > so much apprehension about this patch set. It's going to be > > a user space channel for everything Qualcomm - AI accelerator etc. > > Widening the WWAN status quo to more device types. > > Well not everything Qualcomm but for just the subsystems where there is no > standardization right now. I think we went too far ahead for standardizing > the modems. > > Thanks, > Mani >
