On Wed 03 Feb 12:05 CST 2021, Jakub Kicinski wrote: > On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote: > > >> Jakub, Dave, Adding you both to get your reviews on this series. I've > > >> provided an explanation above and in the previous iteration [1]. > > > > > >Let's be clear what the review would be for. Yet another QMI chardev > > >or the "UCI" direct generic user space to firmware pipe? > > > > The current patchset only supports QMI channel so I'd request you to > > review the chardev node created for it. The QMI chardev node created > > will be unique for the MHI bus and the number of nodes depends on the > > MHI controllers in the system (typically 1 but not limited). > > If you want to add a MHI QMI driver, please write a QMI-only driver. But said QMI driver would be identical to what is proposed here, given that the libqmi [1] communicates in the raw messages of the given MHI channel. Should I then propose another copy of the same driver for transporting debug messages between [2] and the modem? And a third copy to support firmware flashing using [3]. [1] https://www.freedesktop.org/wiki/Software/libqmi/ [2] https://github.com/andersson/diag [3] https://github.com/andersson/qdl > This generic "userspace client interface" driver is a no go. Nobody will > have the time and attention to police what you throw in there later. PCI devices implementing this must have a MHI controller driver, which explicitly needs to specify which logical channels should be exposed to userspace using the UCI driver. So in contrast to things like USBFS or the tty layer - which is used to implement "network devices" today - there is a natural point of policing this. Regards, Bjorn
