Hi Jakub, 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: > > >> 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. > 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. Regards, Loic
