On 30.4.20. 22:02, Greg KH wrote: > 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 > We've started internal discussion around user/kernel IPC. Other comments from v5 have been addressed within v6. -- Regards, Vladimir.
