On Thu, Apr 30, 2020 at 06:51:10PM +0200, Vladimir Stankovic wrote: > On 28.4.20. 13:04, Greg KH wrote: > > On Sat, Apr 25, 2020 at 11:19:46AM +0200, vladimir.stankovic@xxxxxxxxxxxxxxx wrote: > >> Media Agnostic (MA) USB Host driver provides USB connectivity over an > >> available network, allowing host device to access remote USB devices > >> attached to one or more MA USB devices (accessible via network). > >> > >> This driver has been developed to enable the host to communicate > >> with DisplayLink products supporting MA USB protocol (MA USB device, > >> in terms of MA USB Specification). > >> > >> MA USB protocol used by MA USB Host driver has been implemented in > >> accordance with MA USB Specification Release 1.0b. > > > > Is that a USB-released spec? > Correct, document is being maintained by USB IF and is publicly available. > However, I just noticed a typo, correct version is 1.0a. Will correct. > > In short, MA USB Specification defines an MA USB protocol that performs USB > communication via any communication medium. As such, it defines how to pack > USB data within MA USB payload, and how to communicate with remote MA USB device. > > > >> > >> This driver depends on the functions provided by DisplayLink's > >> user-space driver. > > > > Where can that userspace code be found? > > > > thanks, > > > > greg k-h > > > Userspace code is not publicly available. However, in short, it's purpose is > twofold, to provide interface to application layer, and to prepare MA USB packets > that will be used by remote device. So you want us to take a one-off char-driver kernel code for a closed source userspace application for a public spec? That feels really really odd, if not actually against a few licenses. I hate to ask it, but are your lawyers ok with this? > Related to userspace related questions (i.e. comments around two devices used), > we can provide detailed description of the used IPC. In that sense, please state > the most appropriate way/place to state/publish such description (i.e. is it ok > to add it within the cover letter, or publicly available URL is preferred). I asked a bunch of questions about this in the patches themselves, you all need to document the heck out of it everywhere you can, otherwise we can't even review the code properly. Could you review it without knowing what userspace is supposed to be doing? But, note, I will not take a spec-compliant driver that requires closed source userspace code, nor should you even want me to do that if you rely on Linux. So please, release the userspace code, as it's going to have to be changed anyway as your current user/kernel api is broken/incorrect as-is. Why not just bundle it in the kernel tree like we have the usbip code? That way you know it all works properly, and better yet, it can be tested and maintained properly over time. thanks, greg k-h
