Re: [PATCH] USB enclosures seem to require read(16) with 2TB drives
On Nov 11 Stefan Richter wrote: On Nov 09 Elliott, Robert (Server Storage) wrote: I recommend broadening this patch. T10 is discussing making READ (10), WRITE (10), etc. obsolete in SBC-4 in favor of their 16-byte CDB counterparts. The algorithm should be: 1. During discovery, determine if 16-byte CDBs are supported. There are several ways to determine this: a) REPORT SUPPORTED OPERATION CODES command succeeds and reports that READ (16) et al are supported. b) READ (16) command specifying a Transfer Length of zero succeeds. c) READ CAPACITY (16) command succeeds and reports that the capacity is 2 TiB. d) (future) INQUIRY command succeeds fetching the Block Device Characteristics VPD page and notices a new field added by the SBC-4 simplified SCSI feature set proposal. Since REPORT SUPPORTED OPERATION CODES is optional, it won't always work. READ CAPACITY (16) used to be optional for 2 TiB drives, so it won't always work either. READ (16) will always work, but requires the drive to be spun up beforehand (e.g., with START STOP UNIT). This won't work. It will crash badly written device firmwares. Instead, try the (10) commands on the SBC-4 device and let it respond that it does not implement these commands. Or have other means to be certain of SBC-4 compliance without issuing commands that were optional in or not defined by earlier revisions of the spec. I wonder whether testing for INQUIRY_data.VERSION = something is a sufficiently safe test. Let me revise this: Try READ CAPACITY (10) first (unless SPC-3's INQUIRY_data.PROTECT is set, in which case I don't know what is safer; READ CAPACITY (16) first or READ CAPACITY (10) first). If this showed a capacity 2 TB, then Jason's suggestion to always only issue READ (16) to all USB attached devices makes a lot of sense to me if it is true that Windows 7 never issues READ (10) to them. That would be what the proposed patch does. What about WRITE and the various other (10)/(16) pairs of commands though? I don't know what's best in case of transports other than USB (after capacity 2 TB was established). -- Stefan Richter -=-===-- =-== -==-- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: misc: usbtest: send ISO packets for g_zero
From: Boyan Nedeltchev bo...@ti.com
since commit b4036cc (usb: gadget: add
isochronous support to gadget zero), g_zero
has learned about isochronous transfers, which
allows us to use usbtest.ko to exercise
isochronous pipes.
All we need to do to enable that functionality
on usbtest.ko, is set the iso to 1 on
struct usbtest_info
Signed-off-by: Boyan Nedeltchev bo...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/misc/usbtest.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 055b84a..f10bd97 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -2386,6 +2386,7 @@ static struct usbtest_info gz_info = {
.name = Linux gadget zero,
.autoconf = 1,
.ctrl_out = 1,
+ .iso= 1,
.alt= 0,
};
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB enclosures seem to require read(16) with 2TB drives
On Fri, 2012-11-09 at 16:33 +, Elliott, Robert (Server Storage) wrote: I recommend broadening this patch. T10 is discussing making READ (10), WRITE (10), etc. obsolete in SBC-4 in favor of their 16-byte CDB counterparts. The algorithm should be: 1. During discovery, determine if 16-byte CDBs are supported. There are several ways to determine this: a) REPORT SUPPORTED OPERATION CODES command succeeds and reports that READ (16) et al are supported. b) READ (16) command specifying a Transfer Length of zero succeeds. c) READ CAPACITY (16) command succeeds and reports that the capacity is 2 TiB. d) (future) INQUIRY command succeeds fetching the Block Device Characteristics VPD page and notices a new field added by the SBC-4 simplified SCSI feature set proposal. When you consider the problem that we must support all devices (which means the older ones as well), including the annoying USB ones which crash on unexpected commands, you can see that d) is about the only viable option. We can also force RC16 if the capacity is over 2^32 blocks, because the command will be required, so that's probably the place to start. James Since REPORT SUPPORTED OPERATION CODES is optional, it won't always work. READ CAPACITY (16) used to be optional for 2 TiB drives, so it won't always work either. READ (16) will always work, but requires the drive to be spun up beforehand (e.g., with START STOP UNIT). 2. if 16-byte CDBs are supported, then use them; only drop down to 10-byte CDBs if 16-byte CDBs are unavailable. Don't make the decision by comparing the LBA on every IO. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB enclosures seem to require read(16) with 2TB drives
On Fri, 2012-11-09 at 11:08 -0500, Jason J. Herne wrote:
diff --git a/drivers/usb/storage/scsiglue.c
b/drivers/usb/storage/scsiglue.c
index 13b8bcd..6ff785e 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -251,6 +251,11 @@ static int slave_configure(struct scsi_device
*sdev)
US_FL_SCM_MULT_TARG))
us-protocol == USB_PR_BULK)
us-use_last_sector_hacks = 1;
+
+ /* Force read-16 for large capacity drives. */
+ sdev-force_read_16 = 1;
+
+
This turns READ_16 on unconditionally for all USB disks ... is that
safe? As in have you tested this with older USB thumb drives?
Also do we have to worry about TYPE_RBC? ... this looks like a bit of a
global omission in usbstorage.c
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 5591ed5..e92b846 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -134,6 +134,7 @@ struct scsi_device {
* because we did a bus reset. */
unsigned use_10_for_rw:1; /* first try 10-byte read / write */
unsigned use_10_for_ms:1; /* first try 10-byte mode
sense/select */
+ unsigned force_read_16:1; /* Use read(16) over read(10) */
This should probably be use_16_for_rw:1 for consistency.
James
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: autodetect USB MTP device characteristics without libusb_open()
On Wed, Nov 7, 2012 at 10:22 PM, Linus Walleij linus.wall...@linaro.org wrote: I'll see what I can dig up. Mostly this has come from upstream, Alessio do you have something at hand for these color calibration crashes you've been seeing? Sorry but no, I don't. Actually, I've never had to deal with such issues by myself and so I have no chance to reproduce them. Let me know if you need support from the Debian side, as usual I'm open to help anyone out. Cheers, -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB enclosures seem to require read(16) with 2TB drives
Il 12/11/2012 12:33, James Bottomley ha scritto:
On Fri, 2012-11-09 at 11:08 -0500, Jason J. Herne wrote:
diff --git a/drivers/usb/storage/scsiglue.c
b/drivers/usb/storage/scsiglue.c
index 13b8bcd..6ff785e 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -251,6 +251,11 @@ static int slave_configure(struct scsi_device
*sdev)
US_FL_SCM_MULT_TARG))
us-protocol == USB_PR_BULK)
us-use_last_sector_hacks = 1;
+
+ /* Force read-16 for large capacity drives. */
+ sdev-force_read_16 = 1;
+
+
This turns READ_16 on unconditionally for all USB disks ... is that
safe? As in have you tested this with older USB thumb drives?
Actually it only turns it on for large capacity drives, as said in the
comment. sdp-force_read_16 only matters for 2TB drives:
+/* Many large capacity USB drives/controllers require the use of
read(16). */
+force_read16 = (sdkp-capacity 0xULL sdp-force_read_16);
+
if (host_dif == SD_DIF_TYPE2_PROTECTION) {
SCpnt-cmnd = mempool_alloc(sd_cdb_pool, GFP_ATOMIC);
@@ -833,7 +836,7 @@ static int sd_prep_fn(struct request_queue *q, struct
request *rq)
SCpnt-cmnd[29] = (unsigned char) (this_count 16) 0xff;
SCpnt-cmnd[30] = (unsigned char) (this_count 8) 0xff;
SCpnt-cmnd[31] = (unsigned char) this_count 0xff;
-} else if (block 0x) {
+} else if (block 0x || force_read16) {
so the better name would be never_use_10_for_rw_on_large_disks. For
some definitions of better. :)
Any reason not to do this always on 2TB drives, which basically means
changing this:
- } else if (block 0x) {
+ } else if (sdkp-capacity 0x) {
and nothing else?
Paolo
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 5591ed5..e92b846 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -134,6 +134,7 @@ struct scsi_device {
* because we did a bus reset. */
unsigned use_10_for_rw:1; /* first try 10-byte read / write */
unsigned use_10_for_ms:1; /* first try 10-byte mode
sense/select */
+ unsigned force_read_16:1; /* Use read(16) over read(10) */
This should probably be use_16_for_rw:1 for consistency.
James
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB enclosures seem to require read(16) with 2TB drives
On Mon, Nov 12, 2012 at 9:31 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 12/11/2012 12:33, James Bottomley ha scritto:
On Fri, 2012-11-09 at 11:08 -0500, Jason J. Herne wrote:
diff --git a/drivers/usb/storage/scsiglue.c
b/drivers/usb/storage/scsiglue.c
index 13b8bcd..6ff785e 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -251,6 +251,11 @@ static int slave_configure(struct scsi_device
*sdev)
US_FL_SCM_MULT_TARG))
us-protocol == USB_PR_BULK)
us-use_last_sector_hacks = 1;
+
+ /* Force read-16 for large capacity drives. */
+ sdev-force_read_16 = 1;
+
+
This turns READ_16 on unconditionally for all USB disks ... is that
safe? As in have you tested this with older USB thumb drives?
Actually it only turns it on for large capacity drives, as said in the
comment. sdp-force_read_16 only matters for 2TB drives:
I should have made this clearer. Sorry for any confusion.
Any reason not to do this always on 2TB drives, which basically means
changing this:
- } else if (block 0x) {
+ } else if (sdkp-capacity 0x) {
and nothing else?
This was the intent of my patch, except I wanted to *only* affect USB based
drives as my drive was functioning perfecting when connected to an internal
Sata port. I was adopting the Do not fix what isn't broke mentality.
If there is no reason to do otherwise, I like this suggestion. It is simple
and removes the need to provide an extra bit in the scsi_device struct.
It also eliminates the need to do any additional probe/init time checking.
We just want to be sure it won't cause problems for currently working
devices.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB enclosures seem to require read(16) with 2TB drives
On Mon, 2012-11-12 at 15:31 +0100, Paolo Bonzini wrote:
Il 12/11/2012 12:33, James Bottomley ha scritto:
On Fri, 2012-11-09 at 11:08 -0500, Jason J. Herne wrote:
diff --git a/drivers/usb/storage/scsiglue.c
b/drivers/usb/storage/scsiglue.c
index 13b8bcd..6ff785e 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -251,6 +251,11 @@ static int slave_configure(struct scsi_device
*sdev)
US_FL_SCM_MULT_TARG))
us-protocol == USB_PR_BULK)
us-use_last_sector_hacks = 1;
+
+ /* Force read-16 for large capacity drives. */
+ sdev-force_read_16 = 1;
+
+
This turns READ_16 on unconditionally for all USB disks ... is that
safe? As in have you tested this with older USB thumb drives?
Actually it only turns it on for large capacity drives, as said in the
comment. sdp-force_read_16 only matters for 2TB drives:
If you follow the discussion, we'll need to turn it on for some drives
regardless of size.
+ /* Many large capacity USB drives/controllers require the use of
read(16). */
+ force_read16 = (sdkp-capacity 0xULL sdp-force_read_16);
+
if (host_dif == SD_DIF_TYPE2_PROTECTION) {
SCpnt-cmnd = mempool_alloc(sd_cdb_pool, GFP_ATOMIC);
@@ -833,7 +836,7 @@ static int sd_prep_fn(struct request_queue *q, struct
request *rq)
SCpnt-cmnd[29] = (unsigned char) (this_count 16) 0xff;
SCpnt-cmnd[30] = (unsigned char) (this_count 8) 0xff;
SCpnt-cmnd[31] = (unsigned char) this_count 0xff;
- } else if (block 0x) {
+ } else if (block 0x || force_read16) {
so the better name would be never_use_10_for_rw_on_large_disks. For
some definitions of better. :)
Hm.
Any reason not to do this always on 2TB drives, which basically means
changing this:
- } else if (block 0x) {
+ } else if (sdkp-capacity 0x) {
and nothing else?
Because of the coming T10 mandate in SBC-4 deprecating everything other
than the 16 byte commands.
James
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB enclosures seem to require read(16) with 2TB drives
On Mon, Nov 12, 2012 at 10:10 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
On Mon, 2012-11-12 at 15:31 +0100, Paolo Bonzini wrote:
Il 12/11/2012 12:33, James Bottomley ha scritto:
On Fri, 2012-11-09 at 11:08 -0500, Jason J. Herne wrote:
diff --git a/drivers/usb/storage/scsiglue.c
b/drivers/usb/storage/scsiglue.c
index 13b8bcd..6ff785e 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -251,6 +251,11 @@ static int slave_configure(struct scsi_device
*sdev)
US_FL_SCM_MULT_TARG))
us-protocol == USB_PR_BULK)
us-use_last_sector_hacks = 1;
+
+ /* Force read-16 for large capacity drives. */
+ sdev-force_read_16 = 1;
+
+
This turns READ_16 on unconditionally for all USB disks ... is that
safe? As in have you tested this with older USB thumb drives?
Actually it only turns it on for large capacity drives, as said in the
comment. sdp-force_read_16 only matters for 2TB drives:
If you follow the discussion, we'll need to turn it on for some drives
regardless of size.
+ /* Many large capacity USB drives/controllers require the use of
read(16). */
+ force_read16 = (sdkp-capacity 0xULL sdp-force_read_16);
+
if (host_dif == SD_DIF_TYPE2_PROTECTION) {
SCpnt-cmnd = mempool_alloc(sd_cdb_pool, GFP_ATOMIC);
@@ -833,7 +836,7 @@ static int sd_prep_fn(struct request_queue *q, struct
request *rq)
SCpnt-cmnd[29] = (unsigned char) (this_count 16) 0xff;
SCpnt-cmnd[30] = (unsigned char) (this_count 8) 0xff;
SCpnt-cmnd[31] = (unsigned char) this_count 0xff;
- } else if (block 0x) {
+ } else if (block 0x || force_read16) {
so the better name would be never_use_10_for_rw_on_large_disks. For
some definitions of better. :)
Hm.
Any reason not to do this always on 2TB drives, which basically means
changing this:
- } else if (block 0x) {
+ } else if (sdkp-capacity 0x) {
and nothing else?
Because of the coming T10 mandate in SBC-4 deprecating everything other
than the 16 byte commands.
It seems like the deprecations in the coming SBC-4 spec (still in
draft state, yes?) are a
separate issue best handled with a separate patch. My goal with this
patch is to allow Linux
to work with some (most/all?) large capacity drives in external USB
enclosures. The one line
solution proposed by Paolo accomplishes this goal while minimizing
code changes that
might need to be revised/undone later when the deprecation of
read/write(16) is being
handled.
--
- Jason J. Herne (hern...@gmail.com)
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB enclosures seem to require read(16) with 2TB drives
On Mon, 2012-11-12 at 10:01 -0500, Jason J. Herne wrote:
Any reason not to do this always on 2TB drives, which basically means
changing this:
- } else if (block 0x) {
+ } else if (sdkp-capacity 0x) {
and nothing else?
This was the intent of my patch, except I wanted to *only* affect USB based
drives as my drive was functioning perfecting when connected to an internal
Sata port. I was adopting the Do not fix what isn't broke mentality.
There's a subtlety here: block is in units of the disk sector size,
sdkp-capacity is in units of 512 bytes (the linux native sector size),
so it would need shifting before doing the determination.
James
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB enclosures seem to require read(16) with 2TB drives
Il 12/11/2012 16:10, James Bottomley ha scritto:
Actually it only turns it on for large capacity drives, as said in the
comment. sdp-force_read_16 only matters for 2TB drives:
If you follow the discussion, we'll need to turn it on for some drives
regardless of size.
Even if the two reasons to use r/w(16) commands were setting the same
flag, it would be handled in a separate patch; it doesn't really make
sense to complicate the code now when a one-liner does it.
The proposed change is not part of the Oct 31st draft available on
t10.org, for what we know the discussion could end up in nothing.
Any reason not to do this always on 2TB drives, which basically means
changing this:
- } else if (block 0x) {
+ } else if (sdkp-capacity 0x) {
and nothing else?
Because of the coming T10 mandate in SBC-4 deprecating everything other
than the 16 byte commands.
And would this change make the upcoming patch for SBC-4 support longer
or harder to review?
Paolo
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB enclosures seem to require read(16) with 2TB drives
On Mon, 12 Nov 2012, Paolo Bonzini wrote:
Il 12/11/2012 16:10, James Bottomley ha scritto:
Actually it only turns it on for large capacity drives, as said in the
comment. sdp-force_read_16 only matters for 2TB drives:
If you follow the discussion, we'll need to turn it on for some drives
regardless of size.
Even if the two reasons to use r/w(16) commands were setting the same
flag, it would be handled in a separate patch; it doesn't really make
sense to complicate the code now when a one-liner does it.
The proposed change is not part of the Oct 31st draft available on
t10.org, for what we know the discussion could end up in nothing.
There's a simple way to do what everybody wants. Add a use_16_for_rw
flag with the understanding that it overrides use_10_for_rw, and set
this flag in sd_read_capacity() if the actual capacity is = 2^32
blocks (as opposed to 2^41 bytes). Similarly, clear the flag if the
actual capacity is smaller -- a device with removable media might
require this, in theory.
Then the test in sd_prep_fn() becomes
if (sdp-use_16_for_rw) {
rather than
if (block 0x) {
which on 32-bit architectures is a simpler test. If T10 decides to
deprecate the 10-byte commands then a second patch can set the new flag
(and avoid clearing it) under the appropriate circumstances.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] usb: musb: Make dma_controller_create __devinit
Hello.
On 08/09/2012 06:38 PM, Shubhrajyoti D wrote:
dma_controller_create is called only from musb_init_controller
which is __devint so annotate dma_controller_create also with
__devint.
fixes the warn
WARNING: vmlinux.o(.devinit.text+0x6fa8): Section mismatch in reference from
the function musb_init_controller() to the function
.init.text:dma_controller_create()
The function __devinit musb_init_controller() references
a function __init dma_controller_create().
If dma_controller_create is only used by musb_init_controller then
annotate dma_controller_create with a matching annotation.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Changes from RFC remove the stray changes
drivers/usb/musb/cppi_dma.c |2 +-
drivers/usb/musb/musb_dma.h |2 +-
drivers/usb/musb/musbhsdma.c |2 +-
drivers/usb/musb/tusb6010_omap.c |2 +-
drivers/usb/musb/ux500_dma.c |2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/musb/cppi_dma.c b/drivers/usb/musb/cppi_dma.c
index 8637c1f..e19da82 100644
--- a/drivers/usb/musb/cppi_dma.c
+++ b/drivers/usb/musb/cppi_dma.c
@@ -1316,7 +1316,7 @@ irqreturn_t cppi_interrupt(int irq, void *dev_id)
}
/* Instantiate a software object representing a DMA controller. */
-struct dma_controller *__init
+struct dma_controller *__devinit
dma_controller_create(struct musb *musb, void __iomem *mregs)
{
struct cppi *controller;
You failed to also mark cppi_controller_start() and cppi_pool_init __devinit
which causes section mismatch warning on DaVinci... I'll send a patch.
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cppi_dma: mark cppi_controller_create() and cppi_pool_init() as '__devinit'
This patch fixes the following:
WARNING: vmlinux.o(.devinit.text+0x24ac): Section mismatch in reference from
the function dma_controller_create() to the function
.init.text:cppi_controller_start()
The function __devinit dma_controller_create() references
a function __init cppi_controller_start().
If cppi_controller_start is only used by dma_controller_create then
annotate cppi_controller_start with a matching annotation.
This warning is there due to the deficiency in the commit 07a67bbb (usb: musb:
Make dma_controller_create __devinit).
Since the start() method is only called from musb_init_controller() which is
marked '__devinit', mark cppi_controller_start() '__devinit' and also mark
cppi_pool_init() as such since it gets called from that function, to avoid
another section mismatch warning...
Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com
Cc: sta...@vger.kernel.org # 3.7+
---
This patch is atop of 'musb' branch of Felipe's tree...
Would be good to have it in 3.7 as an amendment to the patch
that went into 3.7-rc1, but if not, I CC'ed stable kernels.
drivers/usb/musb/cppi_dma.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: usb/drivers/usb/musb/cppi_dma.c
===
--- usb.orig/drivers/usb/musb/cppi_dma.c
+++ usb/drivers/usb/musb/cppi_dma.c
@@ -105,7 +105,7 @@ static void cppi_reset_tx(struct cppi_tx
musb_writel(tx-tx_complete, 0, ptr);
}
-static void __init cppi_pool_init(struct cppi *cppi, struct cppi_channel *c)
+static void __devinit cppi_pool_init(struct cppi *cppi, struct cppi_channel *c)
{
int j;
@@ -150,7 +150,7 @@ static void cppi_pool_free(struct cppi_c
c-last_processed = NULL;
}
-static int __init cppi_controller_start(struct dma_controller *c)
+static int __devinit cppi_controller_start(struct dma_controller *c)
{
struct cppi *controller;
void __iomem*tibase;
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] arm: at91: move platfarm_data to include/linux/platform_data/atmel.h
On 11:54 Sat 10 Nov , Joachim Eastwood wrote: Hi Jean-Christophe, On 7 November 2012 12:22, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Cc: Nicolas Ferre nicolas.fe...@atmel.com Cc: linux-...@vger.kernel.org Cc: linux-in...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: net...@vger.kernel.org Cc: linux-pcm...@lists.infradead.org Cc: rtc-li...@googlegroups.com Cc: spi-devel-gene...@lists.sourceforge.net Cc: linux-ser...@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: linux-fb...@vger.kernel.org --- HI all, If it's ok with everyone this will go via at91 with the patch serie than clean up the include/mach For preparation to switch to arm multiarch kernel Best Regards, J. arch/arm/mach-at91/include/mach/board.h | 55 -- arch/avr32/mach-at32ap/include/mach/board.h |7 --- drivers/ata/pata_at91.c |2 +- drivers/input/touchscreen/atmel_tsadcc.c|2 +- drivers/mmc/host/atmel-mci.c|2 +- drivers/net/can/at91_can.c |3 +- drivers/net/ethernet/cadence/at91_ether.c |2 +- drivers/pcmcia/at91_cf.c|2 +- drivers/rtc/rtc-at91sam9.c |2 +- drivers/spi/spi-atmel.c |2 +- drivers/tty/serial/atmel_serial.c |2 +- drivers/usb/gadget/at91_udc.c |2 +- drivers/usb/gadget/atmel_usba_udc.c |2 +- drivers/usb/host/ohci-at91.c|2 +- drivers/video/atmel_lcdfb.c |2 +- include/linux/platform_data/atmel.h | 67 +++ 16 files changed, 80 insertions(+), 76 deletions(-) snip diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c index 4e980a7..35fc6edb 100644 --- a/drivers/net/ethernet/cadence/at91_ether.c +++ b/drivers/net/ethernet/cadence/at91_ether.c @@ -31,6 +31,7 @@ #include linux/clk.h #include linux/gfp.h #include linux/phy.h +#include linux/platform_data/atmel.h #include asm/io.h #include asm/uaccess.h @@ -38,7 +39,6 @@ #include mach/at91rm9200_emac.h #include asm/gpio.h -#include mach/board.h #include at91_ether.h The at91_ether driver in net-next does not need to be change since it all mach includes has already been removed by other patches and it includes linux/platform_data/macb.h directly. What tree was these patches based on? The at91_ether driver changes has been in linux-next for a long while now. the conflict is minor easy to handle and the cleanup need to go first on arm soc so this is based on rc3 Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] xhci: Add Lynx Point LP to list of Intel switchable hosts
Like Lynx Point, Lynx Point LP is also switchable. See
1c12443ab8eba71a658fae4572147e56d1f84f66 for more details.
This patch should be backported to stable kernels as old as 3.0,
that contain commit 69e848c2090aebba5698a1620604c7dccb448684
Intel xhci: Support EHCI/xHCI port switching.
Signed-off-by: Russell Webb russell.w...@linux.intel.com
---
drivers/usb/host/ehci-pci.c | 3 ++-
drivers/usb/host/pci-quirks.c | 4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 2cb7d37..f42b68e 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -334,7 +334,8 @@ static bool usb_is_intel_switchable_ehci(struct pci_dev
*pdev)
pdev-vendor == PCI_VENDOR_ID_INTEL
(pdev-device == 0x1E26 ||
pdev-device == 0x8C2D ||
-pdev-device == 0x8C26);
+pdev-device == 0x8C26 ||
+pdev-device == 0x9C26);
}
static void ehci_enable_xhci_companion(void)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 39f9e4a..eb5563a 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -723,6 +723,7 @@ static int handshake(void __iomem *ptr, u32 mask, u32 done,
}
#define PCI_DEVICE_ID_INTEL_LYNX_POINT_XHCI0x8C31
+#define PCI_DEVICE_ID_INTEL_LYNX_POINT_LP_XHCI 0x9C31
bool usb_is_intel_ppt_switchable_xhci(struct pci_dev *pdev)
{
@@ -736,7 +737,8 @@ bool usb_is_intel_lpt_switchable_xhci(struct pci_dev *pdev)
{
return pdev-class == PCI_CLASS_SERIAL_USB_XHCI
pdev-vendor == PCI_VENDOR_ID_INTEL
- pdev-device == PCI_DEVICE_ID_INTEL_LYNX_POINT_XHCI;
+ (pdev-device == PCI_DEVICE_ID_INTEL_LYNX_POINT_XHCI ||
+pdev-device == PCI_DEVICE_ID_INTEL_LYNX_POINT_LP_XHCI);
}
bool usb_is_intel_switchable_xhci(struct pci_dev *pdev)
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fresco Logic Problem
On Sat, Nov 10, 2012 at 02:30:36PM +0330, A Sh wrote: Ah, then you probably have the xHCI driver built-in, not built as a module. What does it mean? Wow, I googled around, and even though I know what search terms to look for, there's really no good documentation on this question. I'll add a page to kernelnewbies.org. Built-in means that the xHCI driver is built into the core kernel binary, vmlinux. Instead of compiling it into a stand-alone module that can be unloaded and reloaded at any time, the driver is built into the binary that gets executed at boot time. Many people build in drivers in order to make their systems boot faster. Other people want to build drivers as modules in order to make sure they can unload and reload them whenever they want. You can choose to make a driver built-in or a module by running `make menuconfig` in the kernel source tree, finding your driver, and choosing 'y' (for built-in) or 'm' (for module). If you look in your .config file for the kernel you compiled (it should be in the kernel source directory), you will see a CONFIG_USB_XHCI_HCD line. If that line reads CONFIG_USB_XHCI_HCD=m then the xHCI driver is configured to be compiled as a module. If instead the line reads CONFIG_USB_XHCI_HCD=y then the xHCI driver is built-in to the vmlinux binary. I hope this answered your question! Sarah Sharp On Sat, Nov 10, 2012 at 12:53 AM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: On Fri, Nov 09, 2012 at 07:32:08AM +0330, A Sh wrote: No, it's not the case. There is no xhci.ko either xhci.ko or xhci-hcd.ko. Ah, then you probably have the xHCI driver built-in, not built as a module. Have you compiled any of 3.x recently? (if not you can find official package for ubuntu here: http://packages.ubuntu.com/precise/linux-image-3.2.0-32-generic) I build 3.x from the mainline kernel source, not from Ubuntu packages. Sarah Sharp On Thu, Nov 8, 2012 at 9:03 PM, Sarah Sharp sarah.a.sh...@linux.intel.comwrote: On Thu, Nov 08, 2012 at 01:28:32PM +0330, A Sh wrote: what about xhci.ko? The module got renamed from xhci.ko to xhci-hcd.ko in 2.6.34. Sarah Sharp On Wed, Nov 7, 2012 at 10:09 PM, Sarah Sharp sarah.a.sh...@linux.intel.comwrote: On Wed, Nov 07, 2012 at 01:56:49PM +0330, A Sh wrote: 1. There is no xhci-hcd.ko at least for 3.2 kernels( I'm sure either for community compiled kernels or self-compiled kernels.) but it's the module responsible for usb3 and it's being used by kernel (for example command dmesg | grep xhci gives a lot of xhci related messages) may be it's compiled under ehci.ko or some other modules together. If you compile kernel you'll see that.(there was xhci.ko or xhci-hcd.ko in 2.6 versions but not in 3.2 ones) 2. We try to avoid module parameters, because it's confusing. Also, distros will always leave them at the default, which means you might as well not have them at all. Any module parameter besides the default isn't going to be well-tested either. I know it's a pain to recompile a kernel, but it doesn't make sense to expose every single option to userspace. So we pick a sane default, and work around any quirks in the kernel driver. Yes this should be the routine procedure but not when there is a bunch of hardware with this issue. It's really only the Fresco Logic vendor that has this issue. That probably means we should just add the quirk for all their chipsets, but I wanted to give them time to fix the issue (and they were aware of the issue when I talked to them about it). So far, they're on strike two for chipset revisions. If I hear about a third revision that needs this quirk, I'll blacklist MSI/MSI-X for all Fresco Logic chipsets. Sarah Sharp On Tue, Nov 6, 2012 at 9:32 PM, Sarah Sharp sarah.a.sh...@linux.intel.comwrote: On Tue, Nov 06, 2012 at 11:03:10AM +0330, A Sh wrote: So you patched 3.2 with the patch I sent you, and it worked? yes, I did. Ok, great, I will send that patch upstream. You mean this one? I had also a suggestion: make xhci module work in three mode: 1. without msi/msi-X 2. with msi and without msi-x 3. with both msi and msi-x That is basically what the driver does (aside from the fact that MSI and MSI-X cannot be enabled at the same time, you can only have one or the other). The driver tries to enable MSI-X, and falls back to MSI if that fails. If MSI enabling fails, it falls
Re: [PATCH] xhci: fix null-pointer dereference when destroying half-built segment rings
On Thu, Nov 01, 2012 at 01:28:46PM -0700, Julius Werner wrote: Is it just for (prev = *first; prev; prev = prev-next) xhci_segment_free(xhci, prev); ? Yeah, that seems cleaner. Sarah Sharp I can submit it that way if you want, but I would advise against it. This way you access the prev pointer after it has been freed already… that's probably not a problem in the current kernel, but it depends on how the underlying memory is managed and is generally just not a good idea in my opinion. Yep, you're right. I'll take the second patch you submitted, thanks. Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Pull Request] xHCI patches for 3.8
The following changes since commit 2f02bc8af3abb846823811af65ec6cc46a4d525d: USB: report submission of active URBs (2012-11-11 18:10:46 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-next-2012-11-12 for you to fetch changes up to 77b847677e7cb633627a9ddaa7efbc3fa8586427: usb: host: xhci: move HC_STATE_SUSPENDED check to xhci_suspend() (2012-11-12 11:45:34 -0800) xHCI patches for 3.8 Hi Greg, Here's some xHCI bug fixes. There's nothing major in here that can't wait for 3.8. The NULL pointer deref that commit 68e5254 fixes hasn't ever been reported in the three years that the xHCI driver has been available, so it can wait a few more weeks. There's two quirk updates, one for Fresco Logic (commit bba18e3) and one for xHCI hosts with the TI redriver (commit b0e4e60). Commit 4525c0a makes the xHCI driver work correctly on the SiBridge xHCI host (and perhaps other 1.0 xHCI host controllers). Commit 392a07a fixes a bug in the Intel Panther Point xHCI host bandwidth checking checking. Commits 2611bd1 and 77b8476 are trivial cleanup patches. Sarah Sharp Alexis R. Cortes (1): usb: host: xhci: Stricter conditional for Z1 system models for Compliance Mode Patch Felipe Balbi (1): usb: host: xhci: move HC_STATE_SUSPENDED check to xhci_suspend() Julius Werner (1): xhci: fix null-pointer dereference when destroying half-built segment rings Sarah Sharp (4): xhci: Avoid global symbol pollution with handshake. xhci: Fix conditional check in bandwidth calculation. xHCI: Fix TD Size calculation on 1.0 hosts. xhci: Extend Fresco Logic MSI quirk. drivers/usb/host/xhci-mem.c |9 +++-- drivers/usb/host/xhci-pci.c | 16 ++-- drivers/usb/host/xhci-ring.c | 34 -- drivers/usb/host/xhci.c | 32 +++- drivers/usb/host/xhci.h |2 +- 5 files changed, 53 insertions(+), 40 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] xhci: Fix conditional check in bandwidth calculation.
David reports that at drivers/usb/host/xhci.c:2257:
static bool xhci_is_sync_in_ep(unsigned int ep_type)
{
return (ep_type == ISOC_IN_EP || ep_type != INT_IN_EP);
}
The static analyser cppcheck says
[linux-3.7-rc2/drivers/usb/host/xhci.c:2257]: (style) Redundant condition: If
ep_type == 5, the comparison ep_type != 7 is always true.
Maybe the original programmer intention was something like
static bool xhci_is_sync_in_ep(unsigned int ep_type)
{
return (ep_type == ISOC_IN_EP || ep_type == INT_IN_EP);
}
Fix this.
This patch should be backported to stable kernels as old as 3.2, that
contain the commit 2b69899934c63b7b9432568584fb4c4a2924f40c xhci: USB
3.0 BW checking.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Reported-by: David Binderman dcb...@hotmail.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 1ca0f3a..2e29f2f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2255,7 +2255,7 @@ static bool xhci_is_async_ep(unsigned int ep_type)
static bool xhci_is_sync_in_ep(unsigned int ep_type)
{
- return (ep_type == ISOC_IN_EP || ep_type != INT_IN_EP);
+ return (ep_type == ISOC_IN_EP || ep_type == INT_IN_EP);
}
static unsigned int xhci_get_ss_bw_consumed(struct xhci_bw_info *ep_bw)
--
1.7.9
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] xhci: Avoid global symbol pollution with handshake.
Non-static xHCI driver symbols should start with the xhci_ prefix, in
order to avoid namespace pollution. Rename the handshake function to
xhci_handshake.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Reported-by: Ben Hutchings b...@decadent.org.uk
---
drivers/usb/host/xhci-ring.c |2 +-
drivers/usb/host/xhci.c | 24 +---
drivers/usb/host/xhci.h |2 +-
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 4e1a894..77f1ace 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -318,7 +318,7 @@ static int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
* seconds), then it should assume that the there are
* larger problems with the xHC and assert HCRST.
*/
- ret = handshake(xhci, xhci-op_regs-cmd_ring,
+ ret = xhci_handshake(xhci, xhci-op_regs-cmd_ring,
CMD_RING_RUNNING, 0, 5 * 1000 * 1000);
if (ret 0) {
xhci_err(xhci, Stopped the command ring failed,
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index c9e419f..1ca0f3a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -40,7 +40,7 @@ MODULE_PARM_DESC(link_quirk, Don't clear the chain bit on a
link TRB);
/* TODO: copied from ehci-hcd.c - can this be refactored? */
/*
- * handshake - spin reading hc until handshake completes or fails
+ * xhci_handshake - spin reading hc until handshake completes or fails
* @ptr: address of hc register to be read
* @mask: bits to look at in result of read
* @done: value of those bits when handshake succeeds
@@ -52,7 +52,7 @@ MODULE_PARM_DESC(link_quirk, Don't clear the chain bit on a
link TRB);
* handshake done). There are two failure modes: usec have passed (major
* hardware flakeout), or the register reads as all-ones (hardware removed).
*/
-int handshake(struct xhci_hcd *xhci, void __iomem *ptr,
+int xhci_handshake(struct xhci_hcd *xhci, void __iomem *ptr,
u32 mask, u32 done, int usec)
{
u32 result;
@@ -103,7 +103,7 @@ int xhci_halt(struct xhci_hcd *xhci)
xhci_dbg(xhci, // Halt the HC\n);
xhci_quiesce(xhci);
- ret = handshake(xhci, xhci-op_regs-status,
+ ret = xhci_handshake(xhci, xhci-op_regs-status,
STS_HALT, STS_HALT, XHCI_MAX_HALT_USEC);
if (!ret) {
xhci-xhc_state |= XHCI_STATE_HALTED;
@@ -132,7 +132,7 @@ static int xhci_start(struct xhci_hcd *xhci)
* Wait for the HCHalted Status bit to be 0 to indicate the host is
* running.
*/
- ret = handshake(xhci, xhci-op_regs-status,
+ ret = xhci_handshake(xhci, xhci-op_regs-status,
STS_HALT, 0, XHCI_MAX_HALT_USEC);
if (ret == -ETIMEDOUT)
xhci_err(xhci, Host took too long to start,
@@ -167,7 +167,7 @@ int xhci_reset(struct xhci_hcd *xhci)
command |= CMD_RESET;
xhci_writel(xhci, command, xhci-op_regs-command);
- ret = handshake(xhci, xhci-op_regs-command,
+ ret = xhci_handshake(xhci, xhci-op_regs-command,
CMD_RESET, 0, 10 * 1000 * 1000);
if (ret)
return ret;
@@ -177,7 +177,7 @@ int xhci_reset(struct xhci_hcd *xhci)
* xHCI cannot write to any doorbells or operational registers other
* than status until the Controller Not Ready flag is cleared.
*/
- ret = handshake(xhci, xhci-op_regs-status,
+ ret = xhci_handshake(xhci, xhci-op_regs-status,
STS_CNR, 0, 10 * 1000 * 1000);
for (i = 0; i 2; ++i) {
@@ -890,7 +890,7 @@ int xhci_suspend(struct xhci_hcd *xhci)
command = xhci_readl(xhci, xhci-op_regs-command);
command = ~CMD_RUN;
xhci_writel(xhci, command, xhci-op_regs-command);
- if (handshake(xhci, xhci-op_regs-status,
+ if (xhci_handshake(xhci, xhci-op_regs-status,
STS_HALT, STS_HALT, XHCI_MAX_HALT_USEC)) {
xhci_warn(xhci, WARN: xHC CMD_RUN timeout\n);
spin_unlock_irq(xhci-lock);
@@ -905,7 +905,8 @@ int xhci_suspend(struct xhci_hcd *xhci)
command = xhci_readl(xhci, xhci-op_regs-command);
command |= CMD_CSS;
xhci_writel(xhci, command, xhci-op_regs-command);
- if (handshake(xhci, xhci-op_regs-status, STS_SAVE, 0, 10 * 1000)) {
+ if (xhci_handshake(xhci, xhci-op_regs-status,
+ STS_SAVE, 0, 10 * 1000)) {
xhci_warn(xhci, WARN: xHC save state timeout\n);
spin_unlock_irq(xhci-lock);
return -ETIMEDOUT;
@@ -967,7 +968,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
command = xhci_readl(xhci, xhci-op_regs-command);
command |= CMD_CRS;
xhci_writel(xhci, command, xhci-op_regs-command);
- if
[PATCH 5/7] xhci: Extend Fresco Logic MSI quirk.
Ali reports that plugging a device into the Fresco Logic xHCI host with
PCI device ID 1400 produces an IRQ error:
do_IRQ: 3.176 No irq handler for vector (irq -1)
Other early Fresco Logic host revisions don't support MSI, even though
their PCI config space claims they do. Extend the quirk to disabling
MSI to this chipset revision. Also enable the short transfer quirk,
since it's likely this revision also has that quirk, and it should be
harmless to enable.
04:00.0 0c03: 1b73:1400 (rev 01) (prog-if 30 [XHCI])
Subsystem: 1d5c:1000
Physical Slot: 3
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 51
Region 0: Memory at d460 (32-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: feeff00c Data: 41b1
Capabilities: [80] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 2us, L1
32us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency
L0 unlimited, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Kernel driver in use: xhci_hcd
This patch should be backported to stable kernels as old as 2.6.36, that
contain the commit f5182b4155b9d686c5540a6822486400e34ddd98 xhci:
Disable MSI for some Fresco Logic hosts.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Reported-by: A Sh smr.ash1...@gmail.com
Tested-by: A Sh smr.ash1...@gmail.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-pci.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 8345d7c..dcb72f7 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -29,6 +29,7 @@
/* Device for a quirk */
#define PCI_VENDOR_ID_FRESCO_LOGIC 0x1b73
#define PCI_DEVICE_ID_FRESCO_LOGIC_PDK 0x1000
+#define PCI_DEVICE_ID_FRESCO_LOGIC_FL1400 0x1400
#define PCI_VENDOR_ID_ETRON0x1b6f
#define PCI_DEVICE_ID_ASROCK_P67 0x7023
@@ -58,8 +59,10 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
/* Look for vendor-specific quirks */
if (pdev-vendor == PCI_VENDOR_ID_FRESCO_LOGIC
- pdev-device == PCI_DEVICE_ID_FRESCO_LOGIC_PDK) {
- if (pdev-revision == 0x0) {
+ (pdev-device == PCI_DEVICE_ID_FRESCO_LOGIC_PDK ||
+pdev-device == PCI_DEVICE_ID_FRESCO_LOGIC_FL1400)) {
+ if (pdev-device == PCI_DEVICE_ID_FRESCO_LOGIC_PDK
+ pdev-revision == 0x0) {
xhci-quirks |= XHCI_RESET_EP_QUIRK;
xhci_dbg(xhci, QUIRK: Fresco Logic xHC needs configure
endpoint cmd after reset endpoint\n);
--
1.7.9
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] usb: host: xhci: Stricter conditional for Z1 system models for Compliance Mode Patch
From: Alexis R. Cortes alexis.cor...@ti.com This minor patch creates a more stricter conditional for the Z1 sytems for applying the Compliance Mode Patch, this to avoid the quirk to be applied to models that contain a Z1 in their dmi product string but are different from Z1 systems. This patch should be backported to stable kernels as old as 3.2, that contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware Signed-off-by: Alexis R. Cortes alexis.cor...@ti.com Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com Cc: sta...@vger.kernel.org --- drivers/usb/host/xhci.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 2e29f2f..09987d5 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -480,7 +480,7 @@ static bool compliance_mode_recovery_timer_quirk_check(void) if (strstr(dmi_product_name, Z420) || strstr(dmi_product_name, Z620) || strstr(dmi_product_name, Z820) || - strstr(dmi_product_name, Z1)) + strstr(dmi_product_name, Z1 Workstation)) return true; return false; -- 1.7.9 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: autodetect USB MTP device characteristics without libusb_open()
Bjørn Mork wrote: The problem appear when you ask a device which is not MTP for that descriptor, some of them just die, so I cannot do that. Really? You ask for a string descriptor and the device dies? Won't those devices also die if they are connected to a Windows system? Yes, but only once. Windows stores an entry in the registry for every device plugged into the system, and the MOD will only be requested the very first time a given device is attached, *or* if the device returned a MOD for a previous request. So the user unplugs and replugs (or reboots) and then the device works. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: autodetect USB MTP device characteristics without libusb_open()
Linus Walleij wrote: - some devices bug out on libusb_open() Please send me a debug log from when this happens. Exact steps are at http://libusb.org/wiki/debug I'll see what I can dig up. Mostly this has come from upstream, Alessio do you have something at hand for these color calibration crashes you've been seeing? Alessio Treglia wrote: Sorry but no, I don't. Can someone please provide the requested debug log, so that I can see what is actually going on when this problem is experienced? Thanks //Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.7-rc5 modpost/link failure: ezusb
On Mon, Nov 12, 2012 at 03:44:35PM +0200, Meelis Roos wrote: MODPOST 490 modules ERROR: ezusb_fx1_ihex_firmware_download [drivers/usb/serial/whiteheat.ko] undefined! ERROR: ezusb_fx1_ihex_firmware_download [drivers/usb/serial/keyspan_pda.ko] undefined! ERROR: ezusb_fx1_set_reset [drivers/usb/serial/keyspan_pda.ko] undefined! ERROR: ezusb_fx1_ihex_firmware_download [drivers/usb/serial/keyspan.ko] undefined! make[1]: *** [__modpost] Error 1 This happens when these USB modules have been selected to be modular and CONFIG_USB_EZUSB_FX2 is linked in. Full config below. Odd, the symbols are properly exported from ezusb.c, so I don't understand why they are not showing up here. René, care to take a look at this? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb: dwc3: exynos: use devm_ functions
The devm_ functions allocate memory that is released when a driver
detaches. This makes the code smaller and a bit simpler.
Signed-off-by: Jingoo Han jg1@samsung.com
---
Changes since v1:
- Rebased on usb-next branch
drivers/usb/dwc3/dwc3-exynos.c | 51 ++--
1 files changed, 23 insertions(+), 28 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index dc35c54..1a79d20 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -95,13 +95,14 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
struct platform_device *dwc3;
struct dwc3_exynos *exynos;
struct clk *clk;
+ struct device *dev = pdev-dev;
int ret = -ENOMEM;
- exynos = kzalloc(sizeof(*exynos), GFP_KERNEL);
+ exynos = devm_kzalloc(dev, sizeof(*exynos), GFP_KERNEL);
if (!exynos) {
- dev_err(pdev-dev, not enough memory\n);
- goto err0;
+ dev_err(dev, not enough memory\n);
+ return -ENOMEM;
}
/*
@@ -116,30 +117,30 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
ret = dwc3_exynos_register_phys(exynos);
if (ret) {
- dev_err(pdev-dev, couldn't register PHYs\n);
- goto err1;
+ dev_err(dev, couldn't register PHYs\n);
+ return ret;
}
dwc3 = platform_device_alloc(dwc3, PLATFORM_DEVID_AUTO);
if (!dwc3) {
- dev_err(pdev-dev, couldn't allocate dwc3 device\n);
- goto err1;
+ dev_err(dev, couldn't allocate dwc3 device\n);
+ return -ENOMEM;
}
- clk = clk_get(pdev-dev, usbdrd30);
+ clk = devm_clk_get(dev, usbdrd30);
if (IS_ERR(clk)) {
- dev_err(pdev-dev, couldn't get clock\n);
+ dev_err(dev, couldn't get clock\n);
ret = -EINVAL;
- goto err3;
+ goto err1;
}
- dma_set_coherent_mask(dwc3-dev, pdev-dev.coherent_dma_mask);
+ dma_set_coherent_mask(dwc3-dev, dev-coherent_dma_mask);
- dwc3-dev.parent = pdev-dev;
- dwc3-dev.dma_mask = pdev-dev.dma_mask;
- dwc3-dev.dma_parms = pdev-dev.dma_parms;
+ dwc3-dev.parent = dev;
+ dwc3-dev.dma_mask = dev-dma_mask;
+ dwc3-dev.dma_parms = dev-dma_parms;
exynos-dwc3= dwc3;
- exynos-dev = pdev-dev;
+ exynos-dev = dev;
exynos-clk = clk;
clk_enable(exynos-clk);
@@ -147,26 +148,23 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
ret = platform_device_add_resources(dwc3, pdev-resource,
pdev-num_resources);
if (ret) {
- dev_err(pdev-dev, couldn't add resources to dwc3 device\n);
- goto err4;
+ dev_err(dev, couldn't add resources to dwc3 device\n);
+ goto err2;
}
ret = platform_device_add(dwc3);
if (ret) {
- dev_err(pdev-dev, failed to register dwc3 device\n);
- goto err4;
+ dev_err(dev, failed to register dwc3 device\n);
+ goto err2;
}
return 0;
-err4:
+err2:
clk_disable(clk);
- clk_put(clk);
-err3:
- platform_device_put(dwc3);
err1:
- kfree(exynos);
-err0:
+ platform_device_put(dwc3);
+
return ret;
}
@@ -179,9 +177,6 @@ static int __devexit dwc3_exynos_remove(struct
platform_device *pdev)
platform_device_unregister(exynos-usb3_phy);
clk_disable(exynos-clk);
- clk_put(exynos-clk);
-
- kfree(exynos);
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/5] usb: add runtime pm support for usb port device
On 2012年11月12日 10:43, Alan Stern wrote: On Mon, 12 Nov 2012, Lan Tianyu wrote: This will consume more power than suspend it agian. No it won't, because the device will suspend itself after 3 ms. But the premise is they see a constant Idle state on their upstream facing bus lines for more than 3.0 ms, that means the port's suspend feature should be set to prevent all the bus activity(e.g sof), right? No, it only means that the port doesn't transmit packets. This could be because the port's suspend feature is set, or it could be because the port's enable feature is clear. Now I have another concern that the device will maintain address 0 after repower and not reset-resume. What happen if another device was plugged in? If the port isn't enabled, it doesn't matter. Hi Alan: I find another problem. We clear PORT_POWER feature in the port's runtime suspend callback. But when port's pm qos flags is updating, pm core will call pm_runtime_get_sync/put(dev). This will cause the PORT_POWER feature to be set and cleared. The result always is power off after port's pm qos flags being changed. Alan Stern -- Best regards Tianyu Lan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: ohci-exynos: use clk_prepare_enable and clk_disable_unprepare
Thomas Abraham wrote: Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare calls as required by common clock framework. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org (+ Alan Stern) Acked-by: Kukjin Kim kgene@samsung.com Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. --- drivers/usb/host/ohci-exynos.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci- exynos.c index 20a5008..7bca600 100644 --- a/drivers/usb/host/ohci-exynos.c +++ b/drivers/usb/host/ohci-exynos.c @@ -123,7 +123,7 @@ static int __devinit exynos_ohci_probe(struct platform_device *pdev) goto fail_clk; } - err = clk_enable(exynos_ohci-clk); + err = clk_prepare_enable(exynos_ohci-clk); if (err) goto fail_clken; @@ -167,7 +167,7 @@ static int __devinit exynos_ohci_probe(struct platform_device *pdev) return 0; fail_io: - clk_disable(exynos_ohci-clk); + clk_disable_unprepare(exynos_ohci-clk); fail_clken: clk_put(exynos_ohci-clk); fail_clk: @@ -186,7 +186,7 @@ static int __devexit exynos_ohci_remove(struct platform_device *pdev) if (pdata pdata-phy_exit) pdata-phy_exit(pdev, S5P_USB_PHY_HOST); - clk_disable(exynos_ohci-clk); + clk_disable_unprepare(exynos_ohci-clk); clk_put(exynos_ohci-clk); usb_put_hcd(hcd); @@ -232,7 +232,7 @@ static int exynos_ohci_suspend(struct device *dev) if (pdata pdata-phy_exit) pdata-phy_exit(pdev, S5P_USB_PHY_HOST); - clk_disable(exynos_ohci-clk); + clk_disable_unprepare(exynos_ohci-clk); fail: spin_unlock_irqrestore(ohci-lock, flags); @@ -247,7 +247,7 @@ static int exynos_ohci_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct exynos4_ohci_platdata *pdata = pdev-dev.platform_data; - clk_enable(exynos_ohci-clk); + clk_prepare_enable(exynos_ohci-clk); if (pdata pdata-phy_init) pdata-phy_init(pdev, S5P_USB_PHY_HOST); -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: dwc3: exynos: use devm_ functions
Hi,
On Tue, Nov 13, 2012 at 11:20:49AM +0900, Jingoo Han wrote:
The devm_ functions allocate memory that is released when a driver
detaches. This makes the code smaller and a bit simpler.
Signed-off-by: Jingoo Han jg1@samsung.com
Next time you want to use the output of scripts/get_maintainer.pl so
you're sure to Cc everybody involved.
Patch looks ok, but I will leave it in the mailing list for a couple of
weeks (no time for v3.8 merge window anyway).
---
Changes since v1:
- Rebased on usb-next branch
drivers/usb/dwc3/dwc3-exynos.c | 51
++--
1 files changed, 23 insertions(+), 28 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index dc35c54..1a79d20 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -95,13 +95,14 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
struct platform_device *dwc3;
struct dwc3_exynos *exynos;
struct clk *clk;
+ struct device *dev = pdev-dev;
int ret = -ENOMEM;
- exynos = kzalloc(sizeof(*exynos), GFP_KERNEL);
+ exynos = devm_kzalloc(dev, sizeof(*exynos), GFP_KERNEL);
if (!exynos) {
- dev_err(pdev-dev, not enough memory\n);
- goto err0;
+ dev_err(dev, not enough memory\n);
+ return -ENOMEM;
}
/*
@@ -116,30 +117,30 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
ret = dwc3_exynos_register_phys(exynos);
if (ret) {
- dev_err(pdev-dev, couldn't register PHYs\n);
- goto err1;
+ dev_err(dev, couldn't register PHYs\n);
+ return ret;
}
dwc3 = platform_device_alloc(dwc3, PLATFORM_DEVID_AUTO);
if (!dwc3) {
- dev_err(pdev-dev, couldn't allocate dwc3 device\n);
- goto err1;
+ dev_err(dev, couldn't allocate dwc3 device\n);
+ return -ENOMEM;
}
- clk = clk_get(pdev-dev, usbdrd30);
+ clk = devm_clk_get(dev, usbdrd30);
if (IS_ERR(clk)) {
- dev_err(pdev-dev, couldn't get clock\n);
+ dev_err(dev, couldn't get clock\n);
ret = -EINVAL;
- goto err3;
+ goto err1;
}
- dma_set_coherent_mask(dwc3-dev, pdev-dev.coherent_dma_mask);
+ dma_set_coherent_mask(dwc3-dev, dev-coherent_dma_mask);
- dwc3-dev.parent = pdev-dev;
- dwc3-dev.dma_mask = pdev-dev.dma_mask;
- dwc3-dev.dma_parms = pdev-dev.dma_parms;
+ dwc3-dev.parent = dev;
+ dwc3-dev.dma_mask = dev-dma_mask;
+ dwc3-dev.dma_parms = dev-dma_parms;
exynos-dwc3= dwc3;
- exynos-dev = pdev-dev;
+ exynos-dev = dev;
exynos-clk = clk;
clk_enable(exynos-clk);
@@ -147,26 +148,23 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
ret = platform_device_add_resources(dwc3, pdev-resource,
pdev-num_resources);
if (ret) {
- dev_err(pdev-dev, couldn't add resources to dwc3 device\n);
- goto err4;
+ dev_err(dev, couldn't add resources to dwc3 device\n);
+ goto err2;
}
ret = platform_device_add(dwc3);
if (ret) {
- dev_err(pdev-dev, failed to register dwc3 device\n);
- goto err4;
+ dev_err(dev, failed to register dwc3 device\n);
+ goto err2;
}
return 0;
-err4:
+err2:
clk_disable(clk);
- clk_put(clk);
-err3:
- platform_device_put(dwc3);
err1:
- kfree(exynos);
-err0:
+ platform_device_put(dwc3);
+
return ret;
}
@@ -179,9 +177,6 @@ static int __devexit dwc3_exynos_remove(struct
platform_device *pdev)
platform_device_unregister(exynos-usb3_phy);
clk_disable(exynos-clk);
- clk_put(exynos-clk);
-
- kfree(exynos);
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
balbi
signature.asc
Description: Digital signature
