I've merged the latest master (dd9c154). The UASP driver saw the following update:
[USB] UASP: Unlock device after reset; EP updates
* Unlock the device after reset.
* Initialize urb->ep directly. struct
uasp_tport_info already records the struct
usb_host_endpoint which makes it easy to
directly initialize urb->ep. This anticipates
when drivers would have to initialize the ep in
the urb directly as opposed to the USB core
having to use pipes.
* Use the UAS pipe macros throughout the code for
endpoint indexes.
The branch can be found here off of master:
https://github.com/ltuikov/linux-2.6
Original posting of the UASP driver can be found here:
http://marc.info/?l=linux-usb&m=129165511732388&w=2
Luben
--- On Thu, 1/13/11, Luben Tuikov <ltuikov@xxxxxxxxx> wrote:
> From: Luben Tuikov <ltuikov@xxxxxxxxx>
> Subject: UASP: updates and merges
> To: linux-scsi@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-usb@xxxxxxxxxxxxxxx, "Greg KH" <greg@xxxxxxxxx>
> Date: Thursday, January 13, 2011, 2:45 AM
> The UASP driver allows you to connect
> to UAS devices and use them
> as SCSI devices.
>
> I've merged latest master (f87813) and resolved a conflict
> in drivers/scsi/sd.c by adding back the truncation of the
> mode sense data.
>
> The UASP driver saw the following update:
>
> [USB] UASP: factor out GFP flags and make
> them GFP_ATOMIC
>
> Factor out the GFP flags and make them
> atomic:
> 1) The SCSI subsystem uses GFP_ATOMIC, e.g.
> before
> calling the host's slave_alloc callback (at
> the
> time of this commit).
> 2) As we are a storage driver doing I/O, we
> should
> use the lowest denominator (highest
> priority)
> allocation, and of course we shouldn't sleep,
> thus
> use GFP_ATOMIC.
>
> The branch can be found here (off of master):
> https://github.com/ltuikov/linux-2.6
>
> Original posting of the UASP driver can be found here:
> http://marc.info/?l=linux-usb&m=129165511732388&w=2
>
> Luben
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
