Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp513717ybm; Fri, 29 May 2020 05:51:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwFcseI3seoHCw4huO/hTz2m040xszpsFT5acQFk3hArp2QiCOVphFV5X1koomfV8547vSj X-Received: by 2002:a17:906:8043:: with SMTP id x3mr7806079ejw.390.1590756675702; Fri, 29 May 2020 05:51:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590756675; cv=none; d=google.com; s=arc-20160816; b=uMI/XM/04duRwslwGKQKxfUWF7DajtckPqR7W+3RR07Lxrq+5hL2tud9c0vInJTV+j 2Fk9YSc+hNo2CnIMOkBB6HrJz48mNKmSB1XPLTrEs3sh6v78cOz+HvvzwMGJ3bw6TglS l/6X7zgRLN0TOf/33JAX3Hgv3fJ3ZiKPFZEMhEZuymHShisYlKFHD3ypkGaMLQ20RFvN nLJaOrJYKph43uWHf+Nyo6GdWimir7jNGOGNIgX0TlYJzu9CxsRL4LICtWuAZKjURkmu 28mOgkJ7i5GhRrV/YuUey3aTTLm9lbkv1grIJkx17hjeyEnYhjHkgt4cA+XGL/m5tAcx /v8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=pUWIBpr+39RQzcQZX9kxTMxwEWcqnuxi9Cr7MPIw4NI=; b=LbpANRS4vWB2gekDDvltSW0gi9InIwl19XPhp9rBo7HTiaX3amaM1m+SRJeFFV7q1G eAF/93uw0Axq/TkasBNa9kgirztZ0+srRK0KMzFmUhSzft5FjqYI0mSTU+qjmpcdw+B4 I3K1NR7imjvAiDnGQSPq/oJoR7qvxqK6MdVJBoflqcVtRzJTUa/JQGFsOGREDByKoitZ P3i64R9QcdfBxm9HO9FTQM5YKp9OxvIewpUGk31jQxNrIrby3+D92QN4gZyRisu4YM3O m1+UYN8LplQY1mO+alAhOUBF/mwbYSHVfz/j/0p7fcOBg+OrpXGYm9ovWGEWn8mRT6xv FFsQ== ARC-Authentication-Results: i=1; mx.google.com; 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 lu4si5694377ejb.19.2020.05.29.05.50.51; Fri, 29 May 2020 05:51:15 -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; 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 S1726933AbgE2Msz (ORCPT + 99 others); Fri, 29 May 2020 08:48:55 -0400 Received: from jabberwock.ucw.cz ([46.255.230.98]:42116 "EHLO jabberwock.ucw.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726467AbgE2Msz (ORCPT ); Fri, 29 May 2020 08:48:55 -0400 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 6BCBB1C0389; Fri, 29 May 2020 14:48:53 +0200 (CEST) Date: Fri, 29 May 2020 14:48:43 +0200 From: Pavel Machek To: Vladimir Stankovic Cc: Greg KH , 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: <20200529124843.GA1339@bug> References: <20200327152614.26833-1-vladimir.stankovic@displaylink.com> <20200425091954.1610-1-vladimir.stankovic@displaylink.com> <20200428110459.GB1145239@kroah.com> <20200430200238.GB3843398@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! > >>>> 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. Ok > >> 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? More importantly... does that work? Userland is okay for communication setup, but if userspace is involved with every packet being sent... It will deadlock. One example: attach mass storage device over MUSB, put swap there; what happens if your userland helper is now swapped out? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html