Re: [External] Re: [PATCH v5 0/8] Add MA USB Host driver

[Vladimir Stankovic]

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.