[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111205083946.GE9900@legolas.emea.dhcp.ti.com>
Date: Mon, 5 Dec 2011 10:39:46 +0200
From: Felipe Balbi <balbi@...com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Shimrit Malichi <smalichi@...eaurora.org>,
Tatyana Brokhman <tlinder@...eaurora.org>,
"open list:USB GADGET/PERIPH..." <linux-usb@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>,
target-devel@...r.kernel.org
Subject: Re: [RFC] UASP on target (was: [RFC/PATCH v4 1/3] uas: MS UAS Gadget
driver - Infrastructure)
Hi,
On Mon, Dec 05, 2011 at 09:23:26AM +0100, Sebastian Andrzej Siewior wrote:
> * Sebastian Andrzej Siewior | 2011-12-05 09:20:47 [+0100]:
>
> >* Shimrit Malichi | 2011-12-04 21:53:09 [+0200]:
> >
> >>This patch implements the infrastructure for the UAS gadget driver.
> >>The UAS gadget driver registers as a second configuration of the MS
> >>gadet driver.
> >hch said to use target framework and you haven't done so. This is what I
> >have so far. It is not yet complete. What I need to do is:
> >- wire up command processing (currently here)
> >- wire up data processing
> >- check it works => post v1
> >- wire up command tagging => v2
> >- remove hard codings and fix whatever people complained about.
This is much better, indeed, but the way it is now, it's only usable by
the gadget framework because you have put the function driver on the
transport layer. I wonder if there wouldn't be a simple way to split the
"SCSI Over USB" part in a more generic way which could be shared between
gadget side UASP and host side UASP drivers ?!? Maybe ?!?
The drivers/target/uasp_*.c would really be just a transport layer and
gadget/host drivers would make calls to that "library" ? Something like
that ??
--
balbi
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists