Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2220918ybz; Thu, 30 Apr 2020 13:04:51 -0700 (PDT) X-Google-Smtp-Source: APiQypLjQRFQxN2rKOkE2FgEGQ66zenIYD8vAhPRhauENgCsQT/bHXZOdbRJq4TJh4UGBwKkEAhy X-Received: by 2002:a17:906:b253:: with SMTP id ce19mr85936ejb.341.1588277091177; Thu, 30 Apr 2020 13:04:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588277091; cv=none; d=google.com; s=arc-20160816; b=n02nkxXq1JZZ2gkwKpYy4jx5Vff0+aUgE2zQIyYoLVUd+exwDzy8uUikeQSA5gyPri iNtkl5/5Kl0ClDGfa604SI15aLIpS7t4VJKDSksyXY73rmU7lc5ts1nByS5010t0fSLA 5r75X7L0l0xJJC07ZyfvqYXqXTZn6/7cH7YrBoGo2nAsVFpztqkzfg2vCB9sRtAGwI0u P2icb2WgWYA+37bUw+Y8H/BsmAN2jWsJKIClbQ2U0cpcEz+wHxcVKsGrTy/2xxOtS0Bp AdxMP+waUhTrfZ3+35cIBx4BrAwT/a19Cjr7xm8HoU3rIMHUace0ffQhJSSoTwG0AQp2 eFTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=1LloHsxpdfml3/UGpY4Xm3mo/1yWyKdkQDEmIYKGLdU=; b=hzZ10qJoyGRwoIASbEWCgfSpkQZtcfgsNqLXDoTr5wgeGQ4+hw5nYJQrD6kS1kH2Rc q2Ai3//L9mDtIS5cNKu0+CFIkgyPyXLzfFgZfZD/mCVR1WWmoPIst7lApv6chZEVYZ0D J4BWcu6FtD912YLInbhxy/aTOKX7OQ4BXKXwXSnPpJZ51i+tErTDvdmP029ZI9bVKQSD 7RzIX0xUSUYnv5S+rHusfTGeUsXf2ZI6T3SmTBa0ZxuG/uIipwAOBGtyvvhc11AuDnuf H/jUUeobGbb43PrfqTzOrh0br3hzVxPgxngciMznyyKOdW4ofcB/G89H/SNunRP/n8wn 0tmQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=H4b2vurN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bs1si389582edb.200.2020.04.30.13.04.27; Thu, 30 Apr 2020 13:04:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=H4b2vurN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726778AbgD3UCl (ORCPT + 99 others); Thu, 30 Apr 2020 16:02:41 -0400 Received: from mail.kernel.org ([198.145.29.99]:60914 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726272AbgD3UCl (ORCPT ); Thu, 30 Apr 2020 16:02:41 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 10ECF2072A; Thu, 30 Apr 2020 20:02:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588276960; bh=Csk1FRgOIkPXyDs3SuTpRgxr84txcfkymZTVF3Q2W24=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=H4b2vurNh0IRcr02dgZoCe8UV0dnNbAlPIYG82dJ3/iq+gyl+Jgk6cMhnYk/2Lssa lvjUmetVvs6JLT5KJzI+rSTKAEnH5bPkdAvYSozN7nAR39nu21nXBk60lSTIAB+6Ap 5yoYU0owO/BOkxdMuY3VqMBFr1jpkR2zA5ZAYylY= Date: Thu, 30 Apr 2020 22:02:38 +0200 From: Greg KH To: Vladimir Stankovic Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, mausb-host-devel@displaylink.com Subject: Re: [External] Re: [PATCH v5 0/8] Add MA USB Host driver Message-ID: <20200430200238.GB3843398@kroah.com> References: <20200327152614.26833-1-vladimir.stankovic@displaylink.com> <20200425091954.1610-1-vladimir.stankovic@displaylink.com> <20200428110459.GB1145239@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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@displaylink.com 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