On Wed 03 Feb 12:40 CST 2021, Jakub Kicinski wrote: > On Wed, 3 Feb 2021 19:28:28 +0100 Loic Poulain wrote: > > On Wed, 3 Feb 2021 at 19:05, Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > > On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote: > > > > 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. > > > 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. > > > > Think it should be seen as filtered userspace access to MHI bus > > (filtered because not all channels are exposed), again it's not > > specific to MHI, any bus in Linux offers that (i2c, spi, usb, serial, > > etc...). It will not be specific to QMI, since we will also need it > > for MBIM (modem control path), AT commands, and GPS (NMEA frames), all > > these protocols are usually handled by userspace tools and not linked > > to any internal Linux framework, so it would be better not having a > > dedicated chardev for each of them. > > The more people argue for this backdoor interface the more distrustful > of it we'll become. Keep going at your own peril. With things such as USBDEVFS, UIO, spi-dev and i2c-dev already exposing various forms of hardware directly to userspace in an identical fashion, can you please explain why you believe this would be inappropriate for MHI devices? Thanks, Bjorn
