Re: usb3 fails to write when using usb3 hub in usb3 port
On Tue, Sep 25, 2012 at 12:38 AM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: Ok, so 3.4.11 doesn't work, and the log file was from 3.5. If you want I can provide a 3.4 log... If it's not LPM, I'm really out of ideas. I would suggest getting another USB 3.0 hub, but I know that basically the VIA chipset is the one out there, so that wouldn't be likely to help. You might go see if your USB 3.0 hub has a firmware update for it. I know other people were having problems with storage devices that stopped responding to a Set Address command after the USB storage driver tried to reset it. Maybe your issue would also go away after a firmware update? I got a gembird and a manhatan..none show firmware updaes on their websites (both seem to be using the same via chipset)... manhattan even mailed replied to my mail: Dear sirs, as this hub is not designed for Linux-OS, you may encounter such driver issues. If you want, you can test it on a Windows-PC. If you are still experiencing problems, let us know. -- 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/2] usb/xhci: release xhci-lock during turning on/off usb port's acpi power resource
When setting usb port's acpi power resource, there will be some xhci hub
requests.
This will cause dead lock since xhci-lock has been held before setting acpi
power
resource in the xhci_hub_control().
Signed-off-by: Lan Tianyu tianyu@intel.com
---
drivers/usb/host/xhci-hub.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index aa90ad4..25a1a5e 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -811,9 +811,12 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
temp = usb_acpi_power_manageable(hcd-self.root_hub,
wIndex);
- if (temp)
+ if (temp) {
+ spin_unlock_irqrestore(xhci-lock, flags);
usb_acpi_set_power_state(hcd-self.root_hub,
wIndex, true);
+ spin_lock_irqsave(xhci-lock, flags);
+ }
break;
case USB_PORT_FEAT_RESET:
temp = (temp | PORT_RESET);
@@ -919,9 +922,12 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
temp = usb_acpi_power_manageable(hcd-self.root_hub,
wIndex);
- if (temp)
+ if (temp) {
+ spin_unlock_irqrestore(xhci-lock, flags);
usb_acpi_set_power_state(hcd-self.root_hub,
wIndex, false);
+ spin_lock_irqsave(xhci-lock, flags);
+ }
break;
default:
goto error;
--
1.7.9.5
--
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/2] usb/xhci: Remove (__force__ __u16) before assigning DeviceRemovable and assign directly.
Struct usb_hub_descriptor.ss.DeviceRemovable has been defined as __le16 and (__force__ __u16) doesn't need. Signed-off-by: Lan Tianyu tianyu@intel.com --- drivers/usb/host/xhci-hub.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c index 25a1a5e..52a5ec3 100644 --- a/drivers/usb/host/xhci-hub.c +++ b/drivers/usb/host/xhci-hub.c @@ -151,9 +151,8 @@ static void xhci_usb3_hub_descriptor(struct usb_hcd *hcd, struct xhci_hcd *xhci, if (portsc PORT_DEV_REMOVE) port_removable |= 1 (i + 1); } - memset(desc-u.ss.DeviceRemovable, - (__force __u16) cpu_to_le16(port_removable), - sizeof(__u16)); + + desc-u.ss.DeviceRemovable = cpu_to_le16(port_removable); } static void xhci_hub_descriptor(struct usb_hcd *hcd, struct xhci_hcd *xhci, -- 1.7.9.5 -- 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
[BUG] FTDI driver framing error with even parity
This is seen on widely used ftdi ft232rl chips. Setting the parity to something like 'even' results in occasional framing errors when transmitting data. Relevant timing diagrams from the logic analyzer are attached to this bug: https://bugzilla.kernel.org/show_bug.cgi?id=47921 -- Regards, Andrew -- 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: USB port power off discussion
On 2012年09月25日 05:17, Alan Stern wrote: On Mon, 24 Sep 2012, Rafael J. Wysocki wrote: Well, precisely. Which means that the user would have to apply trial-and-error to figure out which sysfs file corresponds to which physical port on his/her machine. That doesn't sound really user friendly. It doesn't have to be trial-and-error. We should add symlinks between the sysfs directory for a USB device and the directory for the port it is plugged into. In fact, Tianyu, that would be a good patch to do next. Ok. I will do it next. -- 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 1/1] usb: Include generic_interrupt for OMAP2_PLUS
Hi, On Mon, Sep 24, 2012 at 09:09:14AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [120924 06:08]: Hi, On Mon, Sep 24, 2012 at 03:54:22PM +0300, Philippe De Swert wrote: Hi, On 24/09/2012, Felipe Balbi ba...@ti.com wrote: SoB's mail doesn't From mail. Well still in the progress of migrating of my personal to work laptop. Since the patch does not seem correct the replacement will have matching addresses. /*-*/ #if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_SOC_OMAP3430) || \ - defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500) + defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500) || \ + defined(CONFIG_ARCH_OMAP2PLUS) Weird, how can you build OMAP2PLUS without SOC_OMAP ?? It seems entirely possible. I quickly tried to look if it got defined somewhere and it does not seem to be set anywhere. That is why I got the impression it was replaced by CONFIG_ARCH_OMAP2PLUS. I'll dig deeper to find out why SOC_OMAP is not set if it should be. From the .config I got (used menuconfig) # # TI OMAP2/3/4 Specific Features # CONFIG_ARCH_OMAP2PLUS_TYPICAL=y CONFIG_SOC_HAS_OMAP2_SDRC=y # CONFIG_ARCH_OMAP2 is not set CONFIG_ARCH_OMAP3=y # CONFIG_ARCH_OMAP4 is not set # CONFIG_SOC_OMAP5 is not set # CONFIG_SOC_OMAP3430 is not set # CONFIG_SOC_TI81XX is not set # CONFIG_SOC_AM33XX is not set CONFIG_OMAP_PACKAGE_CBB=y Not a mention of CONFIG_SOC_OMAP2430 and CONFIG_SOC_OMAP3430 did not get set (while it is not a 3430 but a 3630 I am using). Maybe CONFIG_ARCH_OMAP3 would have been a better choice then? that's quite f**ked up. Tony, why doesn't SOC_OMAP3430 get set for all OMAP3 boards ? And another question: why don't we have a matching SOC_OMAP3530, SOC_OMAP3630 and so on ? ARCH_OMAP3 will probably eventually just disappear and be replaced with ARCH_OMAP2PLUS + SOC_. But there's no need to do it right now as most of that should be internal to arch/arm/mach-omap2 anyways. I would just set the driver to depend on ARCH_OMAP2PLUS, and rely on the platform_data and DT to do something if specified. That means that on 2420 musb should not probe unless tusb6010 in specified. It seems that things like fifo_mode and generic_interrupt can all be set during the probe based on the platform_data or DT passed information? Then maybe it's best to just remove the ifdefs and always provide generic_interrupt() ? Anyone against it ? -- balbi signature.asc Description: Digital signature
[PATCH 10/29] PCI, USB: remove find_bridge in acpi_bus_type
The struct member is not used anymore, remove it.
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-usb@vger.kernel.org
---
drivers/usb/core/usb-acpi.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index 8947b20..a6ea613 100644
--- a/drivers/usb/core/usb-acpi.c
+++ b/drivers/usb/core/usb-acpi.c
@@ -102,7 +102,6 @@ static int usb_acpi_find_device(struct device *dev,
acpi_handle *handle)
static struct acpi_bus_type usb_acpi_bus = {
.bus = usb_bus_type,
- .find_bridge = NULL,
.find_device = usb_acpi_find_device,
};
--
1.7.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: [PATCH 10/29] PCI, USB: remove find_bridge in acpi_bus_type
2012/9/25 Yinghai Lu ying...@kernel.org:
The struct member is not used anymore, remove it.
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-usb@vger.kernel.org
---
drivers/usb/core/usb-acpi.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index 8947b20..a6ea613 100644
--- a/drivers/usb/core/usb-acpi.c
+++ b/drivers/usb/core/usb-acpi.c
@@ -102,7 +102,6 @@ static int usb_acpi_find_device(struct device *dev,
acpi_handle *handle)
static struct acpi_bus_type usb_acpi_bus = {
.bus = usb_bus_type,
- .find_bridge = NULL,
.find_device = usb_acpi_find_device,
};
HI Yinghai:
This member has been populated in the usb-next tree.
http://git.kernel.org/?p=linux/kernel/git/gregkh/usb.git;a=commit;h=d557542421da643358201664903e67fd01dfca1a
--
1.7.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
--
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: usb-audio: Increasing MAX_QUEUE to prevent hiccups in the audio stream?
Matthijs Kooijman wrote: I guess that just raising nrpacks by itself is not enough to make this work, since that creates a very big buffer that alsa clients can't touch, causing a big minimum latency. Indeed. I'm not completely sure how this stuff works, but I guess there should be some way for an alsa client to rewind the stream, causing one or more urbs to canceled and resubmitted? I'm not sure if cancelling and resubmitting iso URBs work in real time on all HCDs. But if you think you can implemented this, feel free to try. Regards, Clemens -- 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 0/5] uas: bug fixes
Hi, Resending whole uas bug fix patch series. Patches #3 + #5 got updated, addressing review comments. The fixed patches have been on the list already, but not yet the whole series as updated v2. cheers, Gerd The following changes since commit 56d27adcb536b7430d5f8a6240df8ad261eb00bd: Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile (2012-09-24 16:17:17 -0700) are available in the git repository at: git://git.kraxel.org/linux uas Gerd Hoffmann (5): uas: keep track of command urbs uas: fix task management uas: remove aborted field, replace with status bit. uas: fix abort uas: add locking drivers/usb/storage/uas.c | 89 + 1 files changed, 66 insertions(+), 23 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 v2 2/5] uas: fix task management
Allocate one tag for task management functions and
use it properly.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
drivers/usb/storage/uas.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index ab66365..1d326c5 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -611,7 +611,7 @@ static int uas_eh_task_mgmt(struct scsi_cmnd *cmnd,
{
struct Scsi_Host *shost = cmnd-device-host;
struct uas_dev_info *devinfo = (void *)shost-hostdata[0];
- u16 tag = ; /* FIXME */
+ u16 tag = devinfo-qdepth - 1;
memset(devinfo-response, 0, sizeof(devinfo-response));
if (uas_submit_sense_urb(shost, GFP_NOIO, tag)) {
@@ -701,7 +701,7 @@ static int uas_slave_configure(struct scsi_device *sdev)
{
struct uas_dev_info *devinfo = sdev-hostdata;
scsi_set_tag_type(sdev, MSG_ORDERED_TAG);
- scsi_activate_tcq(sdev, devinfo-qdepth - 2);
+ scsi_activate_tcq(sdev, devinfo-qdepth - 3);
return 0;
}
@@ -880,7 +880,7 @@ static int uas_probe(struct usb_interface *intf, const
struct usb_device_id *id)
init_usb_anchor(devinfo-data_urbs);
uas_configure_endpoints(devinfo);
- result = scsi_init_shared_tag_map(shost, devinfo-qdepth - 2);
+ result = scsi_init_shared_tag_map(shost, devinfo-qdepth - 3);
if (result)
goto free;
--
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
[PATCH v2 3/5] uas: remove aborted field, replace with status bit.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
drivers/usb/storage/uas.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 1d326c5..42976ec 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -64,13 +64,13 @@ enum {
DATA_IN_URB_INFLIGHT= (1 9),
DATA_OUT_URB_INFLIGHT = (1 10),
COMMAND_COMPLETED = (1 11),
+ COMMAND_ABORTED = (1 12),
};
/* Overrides scsi_pointer */
struct uas_cmd_info {
unsigned int state;
unsigned int stream;
- unsigned int aborted;
struct urb *cmd_urb;
struct urb *data_in_urb;
struct urb *data_out_urb;
@@ -163,7 +163,7 @@ static void uas_log_cmd_state(struct scsi_cmnd *cmnd, const
char *caller)
struct uas_cmd_info *ci = (void *)cmnd-SCp;
scmd_printk(KERN_INFO, cmnd, %s %p tag %d, inflight:
- %s%s%s%s%s%s%s%s%s%s%s\n,
+ %s%s%s%s%s%s%s%s%s%s%s%s\n,
caller, cmnd, cmnd-request-tag,
(ci-state SUBMIT_STATUS_URB) ? s-st : ,
(ci-state ALLOC_DATA_IN_URB) ? a-in : ,
@@ -175,7 +175,8 @@ static void uas_log_cmd_state(struct scsi_cmnd *cmnd, const
char *caller)
(ci-state COMMAND_INFLIGHT) ? CMD : ,
(ci-state DATA_IN_URB_INFLIGHT) ? IN: ,
(ci-state DATA_OUT_URB_INFLIGHT) ? OUT : ,
- (ci-state COMMAND_COMPLETED) ? done : );
+ (ci-state COMMAND_COMPLETED) ? done : ,
+ (ci-state COMMAND_ABORTED) ? abort : );
}
static int uas_try_complete(struct scsi_cmnd *cmnd, const char *caller)
@@ -302,7 +303,7 @@ static void uas_data_cmplt(struct urb *urb)
} else {
sdb-resid = sdb-length - urb-actual_length;
}
- if (cmdinfo-aborted) {
+ if (cmdinfo-state COMMAND_ABORTED) {
return;
}
uas_try_complete(cmnd, __func__);
@@ -570,7 +571,6 @@ static int uas_queuecommand_lck(struct scsi_cmnd *cmnd,
cmdinfo-state = SUBMIT_STATUS_URB |
ALLOC_CMD_URB | SUBMIT_CMD_URB;
- cmdinfo-aborted = 0;
switch (cmnd-sc_data_direction) {
case DMA_FROM_DEVICE:
@@ -652,7 +652,7 @@ static int uas_eh_abort_handler(struct scsi_cmnd *cmnd)
int ret;
uas_log_cmd_state(cmnd, __func__);
- cmdinfo-aborted = 1;
+ cmdinfo-state |= COMMAND_ABORTED;
ret = uas_eh_task_mgmt(cmnd, ABORT TASK, TMF_ABORT_TASK);
if (cmdinfo-state DATA_IN_URB_INFLIGHT)
usb_kill_urb(cmdinfo-data_in_urb);
--
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
[PATCH v2 1/5] uas: keep track of command urbs
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
drivers/usb/storage/uas.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 638cd64..ab66365 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -41,6 +41,7 @@ struct sense_iu_old {
struct uas_dev_info {
struct usb_interface *intf;
struct usb_device *udev;
+ struct usb_anchor cmd_urbs;
struct usb_anchor sense_urbs;
struct usb_anchor data_urbs;
int qdepth, resetting;
@@ -431,6 +432,7 @@ static int uas_submit_task_urb(struct scsi_cmnd *cmnd,
gfp_t gfp,
err = usb_submit_urb(urb, gfp);
if (err)
goto err;
+ usb_anchor_urb(urb, devinfo-cmd_urbs);
return 0;
@@ -521,18 +523,22 @@ static int uas_submit_urbs(struct scsi_cmnd *cmnd,
if (cmdinfo-state ALLOC_CMD_URB) {
cmdinfo-cmd_urb = uas_alloc_cmd_urb(devinfo, gfp, cmnd,
- cmdinfo-stream);
+cmdinfo-stream);
if (!cmdinfo-cmd_urb)
return SCSI_MLQUEUE_DEVICE_BUSY;
cmdinfo-state = ~ALLOC_CMD_URB;
}
if (cmdinfo-state SUBMIT_CMD_URB) {
+ usb_get_urb(cmdinfo-cmd_urb);
if (usb_submit_urb(cmdinfo-cmd_urb, gfp)) {
scmd_printk(KERN_INFO, cmnd,
cmd urb submission failure\n);
return SCSI_MLQUEUE_DEVICE_BUSY;
}
+ usb_anchor_urb(cmdinfo-cmd_urb, devinfo-cmd_urbs);
+ usb_put_urb(cmdinfo-cmd_urb);
+ cmdinfo-cmd_urb = NULL;
cmdinfo-state = ~SUBMIT_CMD_URB;
cmdinfo-state |= COMMAND_INFLIGHT;
}
@@ -670,6 +676,7 @@ static int uas_eh_bus_reset_handler(struct scsi_cmnd *cmnd)
int err;
devinfo-resetting = 1;
+ usb_kill_anchored_urbs(devinfo-cmd_urbs);
usb_kill_anchored_urbs(devinfo-sense_urbs);
usb_kill_anchored_urbs(devinfo-data_urbs);
err = usb_reset_device(udev);
@@ -868,6 +875,7 @@ static int uas_probe(struct usb_interface *intf, const
struct usb_device_id *id)
devinfo-intf = intf;
devinfo-udev = udev;
devinfo-resetting = 0;
+ init_usb_anchor(devinfo-cmd_urbs);
init_usb_anchor(devinfo-sense_urbs);
init_usb_anchor(devinfo-data_urbs);
uas_configure_endpoints(devinfo);
@@ -913,6 +921,7 @@ static void uas_disconnect(struct usb_interface *intf)
struct uas_dev_info *devinfo = (void *)shost-hostdata[0];
scsi_remove_host(shost);
+ usb_kill_anchored_urbs(devinfo-cmd_urbs);
usb_kill_anchored_urbs(devinfo-sense_urbs);
usb_kill_anchored_urbs(devinfo-data_urbs);
uas_free_streams(devinfo);
--
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
[PATCH v2 4/5] uas: fix abort
Properly report aborted commands.
Also don't access cmdinfo after kicking task management,
it may not be valid any more once it returns.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
drivers/usb/storage/uas.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 42976ec..df1d72e 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -191,6 +191,10 @@ static int uas_try_complete(struct scsi_cmnd *cmnd, const
char *caller)
cmdinfo-state |= COMMAND_COMPLETED;
usb_free_urb(cmdinfo-data_in_urb);
usb_free_urb(cmdinfo-data_out_urb);
+ if (cmdinfo-state COMMAND_ABORTED) {
+ scmd_printk(KERN_INFO, cmnd, abort completed\n);
+ cmnd-result = DID_ABORT 16;
+ }
cmnd-scsi_done(cmnd);
return 0;
}
@@ -303,9 +307,6 @@ static void uas_data_cmplt(struct urb *urb)
} else {
sdb-resid = sdb-length - urb-actual_length;
}
- if (cmdinfo-state COMMAND_ABORTED) {
- return;
- }
uas_try_complete(cmnd, __func__);
}
@@ -654,10 +655,6 @@ static int uas_eh_abort_handler(struct scsi_cmnd *cmnd)
uas_log_cmd_state(cmnd, __func__);
cmdinfo-state |= COMMAND_ABORTED;
ret = uas_eh_task_mgmt(cmnd, ABORT TASK, TMF_ABORT_TASK);
- if (cmdinfo-state DATA_IN_URB_INFLIGHT)
- usb_kill_urb(cmdinfo-data_in_urb);
- if (cmdinfo-state DATA_OUT_URB_INFLIGHT)
- usb_kill_urb(cmdinfo-data_out_urb);
return ret;
}
--
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
[PATCH v2 5/5] uas: add locking
Add spinlock to protect uas data structures.
[ v2: s/GFP_NOIO/GFP_ATOMIC/, better don't sleep when holding a spinlock ]
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
drivers/usb/storage/uas.c | 51 ++--
1 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index df1d72e..1578909 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -50,6 +50,7 @@ struct uas_dev_info {
unsigned use_streams:1;
unsigned uas_sense_old:1;
struct scsi_cmnd *cmnd;
+ spinlock_t lock;
};
enum {
@@ -91,6 +92,7 @@ static void uas_do_work(struct work_struct *work)
struct uas_cmd_info *cmdinfo;
struct uas_cmd_info *temp;
struct list_head list;
+ unsigned long flags;
int err;
spin_lock_irq(uas_work_lock);
@@ -101,7 +103,10 @@ static void uas_do_work(struct work_struct *work)
struct scsi_pointer *scp = (void *)cmdinfo;
struct scsi_cmnd *cmnd = container_of(scp,
struct scsi_cmnd, SCp);
- err = uas_submit_urbs(cmnd, cmnd-device-hostdata, GFP_NOIO);
+ struct uas_dev_info *devinfo = (void *)cmnd-device-hostdata;
+ spin_lock_irqsave(devinfo-lock, flags);
+ err = uas_submit_urbs(cmnd, cmnd-device-hostdata, GFP_ATOMIC);
+ spin_unlock_irqrestore(devinfo-lock, flags);
if (err) {
list_del(cmdinfo-list);
spin_lock_irq(uas_work_lock);
@@ -182,7 +187,9 @@ static void uas_log_cmd_state(struct scsi_cmnd *cmnd, const
char *caller)
static int uas_try_complete(struct scsi_cmnd *cmnd, const char *caller)
{
struct uas_cmd_info *cmdinfo = (void *)cmnd-SCp;
+ struct uas_dev_info *devinfo = (void *)cmnd-device-hostdata;
+ WARN_ON(!spin_is_locked(devinfo-lock));
if (cmdinfo-state (COMMAND_INFLIGHT |
DATA_IN_URB_INFLIGHT |
DATA_OUT_URB_INFLIGHT))
@@ -222,6 +229,7 @@ static void uas_stat_cmplt(struct urb *urb)
struct uas_dev_info *devinfo = (void *)shost-hostdata[0];
struct scsi_cmnd *cmnd;
struct uas_cmd_info *cmdinfo;
+ unsigned long flags;
u16 tag;
if (urb-status) {
@@ -235,6 +243,7 @@ static void uas_stat_cmplt(struct urb *urb)
return;
}
+ spin_lock_irqsave(devinfo-lock, flags);
tag = be16_to_cpup(iu-tag) - 1;
if (tag == 0)
cmnd = devinfo-cmnd;
@@ -243,6 +252,7 @@ static void uas_stat_cmplt(struct urb *urb)
if (!cmnd) {
if (iu-iu_id != IU_ID_RESPONSE) {
usb_free_urb(urb);
+ spin_unlock_irqrestore(devinfo-lock, flags);
return;
}
} else {
@@ -262,10 +272,16 @@ static void uas_stat_cmplt(struct urb *urb)
uas_sense(urb, cmnd);
if (cmnd-result != 0) {
/* cancel data transfers on error */
- if (cmdinfo-state DATA_IN_URB_INFLIGHT)
+ if (cmdinfo-state DATA_IN_URB_INFLIGHT) {
+ spin_unlock_irqrestore(devinfo-lock, flags);
usb_unlink_urb(cmdinfo-data_in_urb);
- if (cmdinfo-state DATA_OUT_URB_INFLIGHT)
+ spin_lock_irqsave(devinfo-lock, flags);
+ }
+ if (cmdinfo-state DATA_OUT_URB_INFLIGHT) {
+ spin_unlock_irqrestore(devinfo-lock, flags);
usb_unlink_urb(cmdinfo-data_out_urb);
+ spin_lock_irqsave(devinfo-lock, flags);
+ }
}
cmdinfo-state = ~COMMAND_INFLIGHT;
uas_try_complete(cmnd, __func__);
@@ -285,14 +301,18 @@ static void uas_stat_cmplt(struct urb *urb)
Bogus IU (%d) received on status pipe\n, iu-iu_id);
}
usb_free_urb(urb);
+ spin_unlock_irqrestore(devinfo-lock, flags);
}
static void uas_data_cmplt(struct urb *urb)
{
struct scsi_cmnd *cmnd = urb-context;
struct uas_cmd_info *cmdinfo = (void *)cmnd-SCp;
+ struct uas_dev_info *devinfo = (void *)cmnd-device-hostdata;
struct scsi_data_buffer *sdb = NULL;
+ unsigned long flags;
+ spin_lock_irqsave(devinfo-lock, flags);
if (cmdinfo-data_in_urb == urb) {
sdb = scsi_in(cmnd);
cmdinfo-state = ~DATA_IN_URB_INFLIGHT;
@@ -308,6 +328,7 @@ static void uas_data_cmplt(struct urb *urb)
sdb-resid = sdb-length - urb-actual_length;
}
uas_try_complete(cmnd, __func__);
+
Re: [BUG] FTDI driver framing error with even parity
Andrew == Andrew and...@ncrmnt.org writes: Andrew This is seen on widely used ftdi ft232rl chips. Setting the Andrew parity to something like 'even' results in occasional framing Andrew errors when transmitting data. Andrew Relevant timing diagrams from the logic analyzer are attached to Andrew this bug: https://bugzilla.kernel.org/show_bug.cgi?id=47921 Is this a driver or a hardware thing? -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 -- -- 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: query on [PATCH 2/3] usb: otg: add device tree support to otg library
Hi Afzal, On 09/25/2012 10:47 AM, Mohammed, Afzal wrote: This is a query regarding patch, usb: otg: add device tree support to otg library [1] It seems there is so far no consensus on this change. After I have posted this patch, Kishon had posted a better solution [2]. We discussed the patch, but he has not posted any updates since then. Do you have ideas to proceed on this ? is there something that I can help you to proceed on this ? I'm interested in to get these patches into the kernel soon. Kishon any news on this patch? Something like this would be required for USB support on beagle bone (AM335X), which has 2 phy's of same type. Or is the plan to use generic phy framework instead ? Yes, Kishon's patches look more generic than mine. Marc [2] https://patchwork.kernel.org/patch/1457801/ -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/1] usb: Include generic_interrupt for OMAP2_PLUS
Hi, On 25/09/2012, Felipe Balbi ba...@ti.com wrote: Not a mention of CONFIG_SOC_OMAP2430 and CONFIG_SOC_OMAP3430 did not get set (while it is not a 3430 but a 3630 I am using). Maybe CONFIG_ARCH_OMAP3 would have been a better choice then? that's quite f**ked up. Tony, why doesn't SOC_OMAP3430 get set for all OMAP3 boards ? And another question: why don't we have a matching SOC_OMAP3530, SOC_OMAP3630 and so on ? ARCH_OMAP3 will probably eventually just disappear and be replaced with ARCH_OMAP2PLUS + SOC_. But there's no need to do it right now as most of that should be internal to arch/arm/mach-omap2 anyways. I would just set the driver to depend on ARCH_OMAP2PLUS, and rely on the platform_data and DT to do something if specified. That means that on 2420 musb should not probe unless tusb6010 in specified. It seems that things like fifo_mode and generic_interrupt can all be set during the probe based on the platform_data or DT passed information? Then maybe it's best to just remove the ifdefs and always provide generic_interrupt() ? Anyone against it ? Well it seems there are only two drivers that use it omap2430 and ux500. Maybe we somehow link it to the drivers that need it? (I might have missed other drivers but it looks like it is just those two) Regards, Philippe -- 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: [BUG] FTDI driver framing error with even parity
Uwe Bonnes писал 25.09.2012 12:46: Andrew == Andrew and...@ncrmnt.org writes: Andrew This is seen on widely used ftdi ft232rl chips. Setting the Andrew parity to something like 'even' results in occasional framing Andrew errors when transmitting data. Andrew Relevant timing diagrams from the logic analyzer are attached to Andrew this bug: https://bugzilla.kernel.org/show_bug.cgi?id=47921 Is this a driver or a hardware thing? I think that this is a driver problem, since windows drivers do not produce any framing errors. I stumbled upon this while reversing the STC microcontroller ISP protocol that happen to use 'even' parity. I can send in more timing diagrams both from windows and linux hosts to compare. -- Regards, Andrew -- 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: XHCI Bug discovered in 3.6-RC6 (solution included)
Hi
I have posted the required patch for this:
usb: host: xhci: Fix Null pointer dereferencing with 71c731a for non-x86 systems
Can we please get that in ?
On Tue, Sep 18, 2012 at 8:06 PM, Greg KH g...@kroah.com wrote:
On Tue, Sep 18, 2012 at 02:51:57AM +0200, Sebastian Gottschall (DD-WRT) wrote:
this following function is missing a important NULL check. if DMI is
not available or not enabled in the kernel config (which is common
in my case, since its a ARM Platform with XHCI support)
the xhci-hcd driver will crash due nullpointer access since
dmi_get_system_info returns always NULL if DMI support is not
enabled.
static bool compliance_mode_recovery_timer_quirk_check(void)
{
const char *dmi_product_name, *dmi_sys_vendor;
dmi_product_name = dmi_get_system_info(DMI_PRODUCT_NAME);
dmi_sys_vendor = dmi_get_system_info(DMI_SYS_VENDOR);
if (!(strstr(dmi_sys_vendor, Hewlett-Packard)))
return false;
if (strstr(dmi_product_name, Z420) ||
strstr(dmi_product_name, Z620) ||
strstr(dmi_product_name, Z820))
return true;
return false;
}
proposed patch: simply add
if (!dmi_sys_vendor || !dmi_product_name)
return false;
even better. disable the whole quirk handling for this case if
CONFIG_DMI is not set
Care to send a patch to fix this up?
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
Thanks
vivek
--
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-at91: fix null pointer in ohci_hcd_at91_overcurrent_irq
On 09/24/2012 07:34 PM, Greg KH : On Mon, Sep 24, 2012 at 09:44:31AM +0200, Nicolas Ferre wrote: This patches fixed the issue by adding the gpio valid check. Signed-off-by: Joachim Eastwood joachim.eastw...@jotron.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com Thanks a *lot* Joachim for having chased this bug! Alan, Greg, this one is 3.6 last minute material... I Hope that it can make it! --- Note: If 6fffb77c goes into stable please either include this patch also or fold it into 6fffb77c to avoid regressions. Absolutely, I have tagged the faulty patch: Cc: Stable sta...@vger.kernel.org [3.4+] So it can be good if this one can follow the same path. I'll queue this up for 3.7 and have it backported to 3.6.1 as it's a bit late for 3.6 for me right now. Ah, too bad! The kernel Oops may affect several AT91 SoC... Can't we push it with the help of Andrew Morton for late material? Cheers, -- Nicolas Ferre -- 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 1/5] drivers: usb: phy: add a new driver for omap usb2 phy
Hi, On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring robherri...@gmail.com wrote: On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote: All phy related programming like enabling/disabling the clocks, powering on/off the phy is taken care of by this driver. It is also used for OTG related functionality like srp. This also includes device tree support for usb2 phy driver and the documentation with device tree binding information is updated. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/usb/usb-phy.txt | 17 ++ drivers/usb/phy/Kconfig |9 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c | 271 + include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 6 files changed, 378 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt new file mode 100644 index 000..80d4148 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt This is a very generic name... @@ -0,0 +1,17 @@ +USB PHY + +OMAP USB2 PHY + +Required properties: + - compatible: Should be ti,omap-usb2 ...for a specific phy. However, I do think a generic binding to describe host ctrlr to phy connections is needed. + - reg : Address and length of the register set for the device. Also +add the address of control module dev conf register until a driver for +control module is added The dts should describe the h/w, not what you need for the current driver. The 2nd reg field does not belong here. Indeed. This was discussed and agreed upon as a interim solution till we have a control module driver in place to write to the control module register. + +This is usually a subnode of ocp2scp to which it is connected. How is usb port to phy connection described? Currently the usb controller to phy connection is established only by type. We have a couple of patches being currently discussed in the list to establish the connection by phandle. https://patchwork.kernel.org/patch/1457801/ (Generic PHY Framework: devm_of_phy_get()) http://www.spinics.net/lists/linux-usb/msg69547.html Thanks Kishon -- 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 2/2] USB: set hub's default autosuspend delay as 0
On Tue, Sep 25, 2012 at 2:13 PM, Ming Lei ming@canonical.com wrote: For hub devices, we can restore its original 2 seconds delay in open(), and set the 0 delay back in its release() to eliminate the extra suspend/resume during 'lsusb -v'. Sorry, please ignore the stupid idea, :-( Thanks -- Ming Lei -- 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: query on [PATCH 2/3] usb: otg: add device tree support to otg library
Hi, On Tue, Sep 25, 2012 at 2:24 PM, Marc Kleine-Budde m...@pengutronix.de wrote: Hi Afzal, On 09/25/2012 10:47 AM, Mohammed, Afzal wrote: This is a query regarding patch, usb: otg: add device tree support to otg library [1] It seems there is so far no consensus on this change. After I have posted this patch, Kishon had posted a better solution [2]. We discussed the patch, but he has not posted any updates since then. Do you have ideas to proceed on this ? is there something that I can help you to proceed on this ? I'm interested in to get these patches into the kernel soon. Kishon any news on this patch? Something like this would be required for USB support on beagle bone (AM335X), which has 2 phy's of same type. Or is the plan to use generic phy framework instead ? Yes, Kishon's patches look more generic than mine. Will post the next version by this week. Thanks Kishon -- 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: query on [PATCH 2/3] usb: otg: add device tree support to otg library
On Tue, Sep 25, 2012 at 16:21:39, ABRAHAM, KISHON VIJAY wrote: On Tue, Sep 25, 2012 at 2:24 PM, Marc Kleine-Budde m...@pengutronix.de wrote: I'm interested in to get these patches into the kernel soon. Kishon any news on this patch? Something like this would be required for USB support on beagle bone (AM335X), which has 2 phy's of same type. Or is the plan to use generic phy framework instead ? Yes, Kishon's patches look more generic than mine. Will post the next version by this week. Thanks Marc and Kishon Regards Afzal
Query: usbtest: Test 13: Endpoint Halt Test: At Super Speed does not work
Hi , I use 3.5.3-1.fc17 kernel on my host test PC. I use dwc3 in Super speed mode as usb device, however the issue which I see is not related to usb device. I have observed that testusb (test13, EP halt test) never passes in Supper Speed mode. When simple_io is called second time from verify_halted (ie with label verify_still_halted), wait_for_completion never completes. I need to reboot PC to get xhci port working again. Also on the bus I do not see that host is sending second IN token after Get Status (See snapshot). So, it is clear that xhci driver is stuck some where. Does anyone have faced similar issue? Should we really have infinite timeout wait_for_completion here? Regards Pratyush attachment: test13.png
Re: [PATCH v6 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
Hi Rob, On Mon, Sep 24, 2012 at 6:34 PM, Rob Herring robherri...@gmail.com wrote: On 09/17/2012 07:54 AM, Praveen Paneri wrote: This driver uses usb_phy interface to interact with s3c-hsotg. Supports phy_init and phy_shutdown functions to enable/disable phy. Tested with smdk6410 and smdkv310. More SoCs can be brought under later. Signed-off-by: Praveen Paneri p.pan...@samsung.com Acked-by: Heiko Stuebner he...@sntech.de --- .../devicetree/bindings/usb/samsung-usbphy.txt |9 + drivers/usb/phy/Kconfig|8 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/samsung-usbphy.c | 360 include/linux/platform_data/samsung-usbphy.h | 27 ++ 5 files changed, 405 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode 100644 drivers/usb/phy/samsung-usbphy.c create mode 100644 include/linux/platform_data/samsung-usbphy.h diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt new file mode 100644 index 000..fefd9c8 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -0,0 +1,9 @@ +* Samsung's usb phy transceiver + +The Samsung's phy transceiver is used for controlling usb otg phy for +s3c-hsotg usb device controller. + +Required properties: +- compatible : should be samsung,exynos4210-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. What's missing here is describing the connection of phys to host controllers. We've got several people adding usb phy bindings and need to define them in a common way. yes! it just covers the generic binding. I will update it accordingly as the generic phy framework takes its final shape. Praveen Rob diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 63c339b..313685f 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -32,3 +32,11 @@ config MV_U3D_PHY help Enable this to support Marvell USB 3.0 phy controller for Marvell SoC. + +config SAMSUNG_USBPHY + bool Samsung USB PHY controller Driver + depends on USB_S3C_HSOTG + select USB_OTG_UTILS + help + Enable this to support Samsung USB phy controller for samsung + SoCs. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index b069f29..55dcfc1 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) += omap-usb2.o obj-$(CONFIG_USB_ISP1301)+= isp1301.o obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o +obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c new file mode 100644 index 000..95ec4d0 --- /dev/null +++ b/drivers/usb/phy/samsung-usbphy.c @@ -0,0 +1,360 @@ +/* linux/drivers/usb/phy/samsung-usbphy.c + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Author: Praveen Paneri p.pan...@samsung.com + * + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/module.h +#include linux/platform_device.h +#include linux/clk.h +#include linux/delay.h +#include linux/err.h +#include linux/io.h +#include linux/of.h +#include linux/usb/otg.h +#include linux/platform_data/samsung-usbphy.h + +/* Register definitions */ + +#define S3C_PHYPWR (0x00) + +#define S3C_PHYPWR_NORMAL_MASK (0x19 0) +#define S3C_PHYPWR_OTG_DISABLE (1 4) +#define S3C_PHYPWR_ANALOG_POWERDOWN (1 3) +#define S3C_PHYPWR_FORCE_SUSPEND (1 1) +/* For Exynos4 */ +#define EXYNOS4_PHYPWR_NORMAL_MASK (0x39 0) +#define EXYNOS4_PHYPWR_SLEEP (1 5) + +#define S3C_PHYCLK (0x04) + +#define S3C_PHYCLK_MODE_SERIAL (1 6) +#define S3C_PHYCLK_EXT_OSC (1 5) +#define S3C_PHYCLK_COMMON_ON_N (1 4) +#define S3C_PHYCLK_ID_PULL (1 2) +#define S3C_PHYCLK_CLKSEL_MASK (0x3 0) +#define S3C_PHYCLK_CLKSEL_SHIFT (0) +#define
Re: [PATCH v6 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
On 09/24/2012 11:38 AM, Praveen Paneri wrote: Hi Kishon, Felipe, Any further comments on these patches? Can they be merged now? One nitpick inline. Marc Thanks, Praveen On Mon, Sep 17, 2012 at 6:24 PM, Praveen Paneri p.pan...@samsung.com wrote: This driver uses usb_phy interface to interact with s3c-hsotg. Supports phy_init and phy_shutdown functions to enable/disable phy. Tested with smdk6410 and smdkv310. More SoCs can be brought under later. Signed-off-by: Praveen Paneri p.pan...@samsung.com Acked-by: Heiko Stuebner he...@sntech.de --- .../devicetree/bindings/usb/samsung-usbphy.txt |9 + drivers/usb/phy/Kconfig|8 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/samsung-usbphy.c | 360 include/linux/platform_data/samsung-usbphy.h | 27 ++ 5 files changed, 405 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode 100644 drivers/usb/phy/samsung-usbphy.c create mode 100644 include/linux/platform_data/samsung-usbphy.h diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt new file mode 100644 index 000..fefd9c8 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -0,0 +1,9 @@ +* Samsung's usb phy transceiver + +The Samsung's phy transceiver is used for controlling usb otg phy for +s3c-hsotg usb device controller. + +Required properties: +- compatible : should be samsung,exynos4210-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 63c339b..313685f 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -32,3 +32,11 @@ config MV_U3D_PHY help Enable this to support Marvell USB 3.0 phy controller for Marvell SoC. + +config SAMSUNG_USBPHY + bool Samsung USB PHY controller Driver + depends on USB_S3C_HSOTG + select USB_OTG_UTILS + help + Enable this to support Samsung USB phy controller for samsung + SoCs. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index b069f29..55dcfc1 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) += omap-usb2.o obj-$(CONFIG_USB_ISP1301) += isp1301.o obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o +obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c new file mode 100644 index 000..95ec4d0 --- /dev/null +++ b/drivers/usb/phy/samsung-usbphy.c @@ -0,0 +1,360 @@ +/* linux/drivers/usb/phy/samsung-usbphy.c + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Author: Praveen Paneri p.pan...@samsung.com + * + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/module.h +#include linux/platform_device.h +#include linux/clk.h +#include linux/delay.h +#include linux/err.h +#include linux/io.h +#include linux/of.h +#include linux/usb/otg.h +#include linux/platform_data/samsung-usbphy.h + +/* Register definitions */ + +#define S3C_PHYPWR (0x00) + +#define S3C_PHYPWR_NORMAL_MASK (0x19 0) +#define S3C_PHYPWR_OTG_DISABLE (1 4) +#define S3C_PHYPWR_ANALOG_POWERDOWN(1 3) +#define S3C_PHYPWR_FORCE_SUSPEND (1 1) +/* For Exynos4 */ +#define EXYNOS4_PHYPWR_NORMAL_MASK (0x39 0) +#define EXYNOS4_PHYPWR_SLEEP (1 5) + +#define S3C_PHYCLK (0x04) + +#define S3C_PHYCLK_MODE_SERIAL (1 6) +#define S3C_PHYCLK_EXT_OSC (1 5) +#define S3C_PHYCLK_COMMON_ON_N (1 4) +#define S3C_PHYCLK_ID_PULL (1 2) +#define S3C_PHYCLK_CLKSEL_MASK (0x3 0) +#define S3C_PHYCLK_CLKSEL_SHIFT(0) +#define S3C_PHYCLK_CLKSEL_48M (0x0 0) +#define S3C_PHYCLK_CLKSEL_12M (0x2 0) +#define S3C_PHYCLK_CLKSEL_24M (0x3 0) + +#define
RE: removing the timer from cdc-ncm
-Original Message-
From: Oliver Neukum [mailto:oneu...@suse.de]
here is the patch that does everything I consider theoretically
necessary to have bundling of frames in usbnet and adapting cdc-ncm to
it.
I'd appreciate any review in case I am doing something stupid.
I had a brief look at cdc_ncm and a few corrections needed:
- remove the following:
#include linux/hrtimer.h
...
/* Restart the timer, if amount of datagrams is less than given value */
#define CDC_NCM_RESTART_TIMER_DATAGRAM_CNT 3
#define CDC_NCM_TIMER_PENDING_CNT 2
#define CDC_NCM_TIMER_INTERVAL (400UL * NSEC_PER_USEC)
...
In struct cdc_ncm_ctx {
...
struct hrtimer tx_timer;
struct tasklet_struct bh;
...
In cdc_ncm_unbind():
if (hrtimer_active(ctx-tx_timer))
hrtimer_cancel(ctx-tx_timer);
tasklet_kill(ctx-bh);
I didn't have time to check the new logic for data path, but I've
tried to run it on Ubuntu 12.04.
Linux host got panic right after data path has been established
(i.e. connected to mobile network).
Regards,
Alexey
--
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: Query: usbtest: Test 13: Endpoint Halt Test: At Super Speed does not work
On 9/25/2012 4:49 PM, Felipe Balbi wrote: Can you post dwc3's logs ? We need to see if it executed set_halt() or set_wedge(). Host Does SET FEATURE(ENDPOINT_HALT). dwc3 codes calls __dwc3_gadget_ep_set_halt with correct dep for the specified endpoint. I do not think that dwc3 is doing anything wrong. Anyway, log is attached. Regards Pratyush # dwc3 dwc3: ep0out: Transfer Complete dwc3 dwc3: Transfer Complete while ep0out in state 'Setup Phase' dwc3 dwc3: Inspecting Setup Bytes dwc3 dwc3: Forwarding to gadget driver dwc3 dwc3: request 8f97a780 from ep1in completed 0/4096 === -108 dwc3 dwc3: request 8f97a000 from ep1out completed 0/4096 === -108 dwc3 dwc3: request 8f97aa80 from ep2in completed 0/1024 === -108 dwc3 dwc3: request 8f97a400 from ep2in completed 0/1024 === -108 dwc3 dwc3: request 8f97a800 from ep2in completed 0/1024 === -108 dwc3 dwc3: request 8f97a680 from ep2in completed 0/1024 === -108 dwc3 dwc3: request 8f97af00 from ep2in completed 0/1024 === -108 dwc3 dwc3: request 8f97af80 from ep2in completed 0/1024 === -108 dwc3 dwc3: request 8f97ab00 from ep2in completed 0/1024 === -108 dwc3 dwc3: request 8f97a580 from ep2in completed 0/1024 === -108 dwc3 dwc3: request 8f97a880 from ep2out completed 0/1024 === -108 dwc3 dwc3: request 8f97a300 from ep2out completed 0/1024 === -108 dwc3 dwc3: request 8f97a180 from ep2out completed 0/1024 === -108 dwc3 dwc3: request 8f8c7e80 from ep2out completed 0/1024 === -108 dwc3 dwc3: request 8f8c7d00 from ep2out completed 0/1024 === -108 dwc3 dwc3: request 8f936c80 from ep2out completed 0/1024 === -108 dwc3 dwc3: request 8f936280 from ep2out completed 0/1024 === -108 dwc3 dwc3: request 8f9fde80 from ep2out completed 0/1024 === -108 dwc3 dwc3: Enabling ep1in-bulk dwc3 dwc3: ep1in-bulk: cmd 'Set Endpoint Configuration' params 00022004 06000500 dwc3 dwc3: Command Complete -- 0 dwc3 dwc3: ep1in-bulk: cmd 'Set Endpoint Transfer Resource' params 0001 dwc3 dwc3: Command Complete -- 0 dwc3 dwc3: queing request 8f9fde80 to ep1in-bulk length 4096 dwc3 dwc3: Enabling ep1out-bulk dwc3 dwc3: ep1out-bulk: cmd 'Set Endpoint Configuration' params 2004 04000500 dwc3 dwc3: Command Complete -- 0 dwc3 dwc3: ep1out-bulk: cmd 'Set Endpoint Transfer Resource' params 0001 dwc3 dwc3: Command Complete -- 0 dwc3 dwc3: queing request 8f9fd500 to ep1out-bulk length 4096 dwc3 dwc3: Enabling ep2in-isoc dwc3 dwc3: ep2in-isoc: cmd 'Set Endpoint Configuration' params 00042002 0a030700 dwc3 dwc3: Command Complete -- 0 dwc3 dwc3: ep2in-isoc: cmd 'Set Endpoint Transfer Resource' params 0001 dwc3 dwc3: Command Complete -- 0 dwc3 dwc3: queing request 8f936280 to ep2in-isoc length 1024 dwc3 dwc3: queing request 8f936c80 to ep2in-isoc length 1024 dwc3 dwc3: queing request 8f8c7d00 to ep2in-isoc length 1024 dwc3 dwc3: queing request 8f8c7e80 to ep2in-isoc length 1024 dwc3 dwc3: queing request 8f97a180 to ep2in-isoc length 1024 dwc3 dwc3: queing request 8f97a300 to ep2in-isoc length 1024 dwc3 dwc3: queing request 8f97a880 to ep2in-isoc length 1024 dwc3 dwc3: queing request 8f97a580 to ep2in-isoc length 1024 dwc3 dwc3: Enabling ep2out-isoc dwc3 dwc3: ep2out-isoc: cmd 'Set Endpoint Configuration' params 2002 08030700 dwc3 dwc3: Command Complete -- 0 dwc3 dwc3: ep2out-isoc: cmd 'Set Endpoint Transfer Resource' params 0001 dwc3 dwc3: Command Complete -- 0 dwc3 dwc3: queing request 8f97ab00 to ep2out-isoc length 1024 dwc3 dwc3: queing request 8f97af80 to ep2out-isoc length 1024 dwc3 dwc3: queing request 8f97af00 to ep2out-isoc length 1024 dwc3 dwc3: queing request 8f97a680 to ep2out-isoc length 1024 dwc3 dwc3: queing request 8f97a800 to ep2out-isoc length 1024 dwc3 dwc3: queing request 8f97a400 to ep2out-isoc length 1024 dwc3 dwc3: queing request 8f97aa80 to ep2out-isoc length 1024 dwc3 dwc3: queing request 8f97a000 to ep2out-isoc length 1024 dwc3 dwc3: queueing request 8f94c480 to ep0out length 0, state 'Setup Phase' dwc3 dwc3: ep0in: Transfer Not Ready dwc3 dwc3: Transfer Not Ready while ep0in in state 'Setup Phase' dwc3 dwc3: Control Status dwc3 dwc3: ep0in: cmd 'Start Transfer' params 0f909000 dwc3 dwc3: Command Complete -- 0 dwc3 dwc3: ep0in: Transfer Complete dwc3 dwc3: Transfer Complete while ep0in in state 'Status Phase' dwc3 dwc3: Status Phase dwc3 dwc3: request 8f94c480 from ep0out completed 0/0 === 0 dwc3 dwc3: ep0out: cmd 'Start Transfer' params 0f909000 dwc3 dwc3: Command Complete -- 0 dwc3 dwc3: ep0out: Transfer Complete dwc3 dwc3: Transfer Complete while ep0out in state 'Setup Phase' dwc3 dwc3: Inspecting Setup Bytes dwc3 dwc3: USB_REQ_GET_STATUS dwc3 dwc3: ep0in: cmd 'Start Transfer' params 0f909000 dwc3 dwc3: Command Complete -- 0 dwc3 dwc3: ep0in: Transfer Not Ready dwc3 dwc3: Transfer Not Ready while ep0in in state 'Data Phase' dwc3 dwc3: Control Data dwc3 dwc3: ep0in: Transfer Complete dwc3
Re: Query: usbtest: Test 13: Endpoint Halt Test: At Super Speed does not work
Hi, On Tue, Sep 25, 2012 at 05:24:25PM +0530, Pratyush Anand wrote: On 9/25/2012 4:49 PM, Felipe Balbi wrote: Can you post dwc3's logs ? We need to see if it executed set_halt() or set_wedge(). Host Does SET FEATURE(ENDPOINT_HALT). dwc3 codes calls __dwc3_gadget_ep_set_halt with correct dep for the specified endpoint. I do not think that dwc3 is doing anything wrong. Anyway, log is attached. indeed, logs look just fine. Sarah, do you know of any bugs on SET_FEATURE(ENDPOINT_HALT) handling on xHCI ?? -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
On 09/25/2012 06:23 AM, Praveen Paneri wrote: Hi Rob, On Mon, Sep 24, 2012 at 6:34 PM, Rob Herring robherri...@gmail.com wrote: On 09/17/2012 07:54 AM, Praveen Paneri wrote: This driver uses usb_phy interface to interact with s3c-hsotg. Supports phy_init and phy_shutdown functions to enable/disable phy. Tested with smdk6410 and smdkv310. More SoCs can be brought under later. Signed-off-by: Praveen Paneri p.pan...@samsung.com Acked-by: Heiko Stuebner he...@sntech.de --- .../devicetree/bindings/usb/samsung-usbphy.txt |9 + drivers/usb/phy/Kconfig|8 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/samsung-usbphy.c | 360 include/linux/platform_data/samsung-usbphy.h | 27 ++ 5 files changed, 405 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode 100644 drivers/usb/phy/samsung-usbphy.c create mode 100644 include/linux/platform_data/samsung-usbphy.h diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt new file mode 100644 index 000..fefd9c8 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -0,0 +1,9 @@ +* Samsung's usb phy transceiver + +The Samsung's phy transceiver is used for controlling usb otg phy for +s3c-hsotg usb device controller. + +Required properties: +- compatible : should be samsung,exynos4210-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. What's missing here is describing the connection of phys to host controllers. We've got several people adding usb phy bindings and need to define them in a common way. yes! it just covers the generic binding. I will update it accordingly as the generic phy framework takes its final shape. That sounds like the wrong way to define a binding... Figuring out how to describe the h/w should not be dependent on changes in the kernel. Bindings are an ABI and should not be evolving. Rob -- 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 v6 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
Hi,
On Tue, Sep 25, 2012 at 5:48 PM, Rob Herring robherri...@gmail.com wrote:
On 09/25/2012 06:23 AM, Praveen Paneri wrote:
Hi Rob,
On Mon, Sep 24, 2012 at 6:34 PM, Rob Herring robherri...@gmail.com wrote:
On 09/17/2012 07:54 AM, Praveen Paneri wrote:
This driver uses usb_phy interface to interact with s3c-hsotg. Supports
phy_init and phy_shutdown functions to enable/disable phy. Tested with
smdk6410 and smdkv310. More SoCs can be brought under later.
Signed-off-by: Praveen Paneri p.pan...@samsung.com
Acked-by: Heiko Stuebner he...@sntech.de
---
.../devicetree/bindings/usb/samsung-usbphy.txt |9 +
drivers/usb/phy/Kconfig|8 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/samsung-usbphy.c | 360
include/linux/platform_data/samsung-usbphy.h | 27 ++
5 files changed, 405 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/usb/samsung-usbphy.txt
create mode 100644 drivers/usb/phy/samsung-usbphy.c
create mode 100644 include/linux/platform_data/samsung-usbphy.h
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
new file mode 100644
index 000..fefd9c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -0,0 +1,9 @@
+* Samsung's usb phy transceiver
+
+The Samsung's phy transceiver is used for controlling usb otg phy for
+s3c-hsotg usb device controller.
+
+Required properties:
+- compatible : should be samsung,exynos4210-usbphy
+- reg : base physical address of the phy registers and length of memory
mapped
+ region.
What's missing here is describing the connection of phys to host
controllers. We've got several people adding usb phy bindings and need
to define them in a common way.
yes! it just covers the generic binding. I will update it accordingly
as the generic phy framework takes its final shape.
That sounds like the wrong way to define a binding... Figuring out how
to describe the h/w should not be dependent on changes in the kernel.
Bindings are an ABI and should not be evolving.
There can be multiple ways to define the binding. For e.g. We
discussed few ways of binding the phys to the controller
controller {
phy0 = phandle1_name;
phy1 = phandle2_name;
}
phy0 and phy1 are any name given to obtain a reference to the phy and
the controller should send the phandle name like
get_phy_by_phandle(phy0);. Then we thought of standardizing that
name.
and then finally we settled on something like this
controller {
phy = phandle0_name, phandle1_name;
}
so that controller can obtain a reference to the PHY using
*of_phy_get(struct device *dev, const char *phandle, u8 index)*
Thanks
Kishon
--
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: XHCI Bug discovered in 3.6-RC6 (solution included)
A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, Sep 25, 2012 at 03:12:33PM +0530, Vivek Gautam wrote: Hi I have posted the required patch for this: usb: host: xhci: Fix Null pointer dereferencing with 71c731a for non-x86 systems You sent this last saturday, a mere 3 days ago, two of them on a weekend, please be patient. 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
Re: [PATCH] USB: ohci-at91: fix null pointer in ohci_hcd_at91_overcurrent_irq
On Tue, Sep 25, 2012 at 11:48:43AM +0200, Nicolas Ferre wrote: On 09/24/2012 07:34 PM, Greg KH : On Mon, Sep 24, 2012 at 09:44:31AM +0200, Nicolas Ferre wrote: This patches fixed the issue by adding the gpio valid check. Signed-off-by: Joachim Eastwood joachim.eastw...@jotron.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com Thanks a *lot* Joachim for having chased this bug! Alan, Greg, this one is 3.6 last minute material... I Hope that it can make it! --- Note: If 6fffb77c goes into stable please either include this patch also or fold it into 6fffb77c to avoid regressions. Absolutely, I have tagged the faulty patch: Cc: Stable sta...@vger.kernel.org [3.4+] So it can be good if this one can follow the same path. I'll queue this up for 3.7 and have it backported to 3.6.1 as it's a bit late for 3.6 for me right now. Ah, too bad! The kernel Oops may affect several AT91 SoC... Can't we push it with the help of Andrew Morton for late material? 3.6.1 is really too late for you? What does one week buy you? 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
USB tree closed for 3.7
Hi all, If you haven't sent me any pending patches for 3.7, it's a bit too late as I've now closed the usb-next tree for any new stuff for 3.7, unless it's bug fixes. If you have sent me stuff and I've missed it, please let me know as I think my queue is now empty. 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
Re: [RFC] xhci: Intel Panther Point BEI quirk.
On Mon, Sep 24, 2012 at 07:58:04PM -0700, Andiry Xu wrote: On Mon, Sep 24, 2012 at 3:35 PM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: On Mon, Sep 24, 2012 at 01:05:08PM -0700, Sarah Sharp wrote: On Mon, Sep 24, 2012 at 03:50:04PM -0400, Alan Stern wrote: On Mon, 24 Sep 2012, Sarah Sharp wrote: When a device with an isochronous endpoint is behind a hub plugged into the Intel Panther Point xHCI host controller, and the driver submits multiple frames per URB, the xHCI driver will set the Block Event Interrupt (BEI) flag on all but the last TD for the URB. This causes the host controller to place an event on the event ring, but not send an interrupt. When the last TD for the URB completes, BEI is cleared, and we get an interrupt for the whole URB. However, under a Panther Point xHCI host controller, if the parent hub is unplugged when one or more events from transfers with BEI set are on the event ring, a port status change event is placed on the event ring, but no interrupt is generated. This means URBs stop completing, and the USB device disconnect is not noticed. Something like a USB headset will cause mplayer to hang when the device is disconnected. Won't that also cause a problem for hot-unplug detection? How will the hub driver learn about the unplug event if there's no interrupt? There will be an interrupt if we don't use the BEI flag. That's what this patch fixes. The BEI flag is only supposed to block isochronous interrupts, and only if there was no error associated with the transfer. But the Panther Point xHCI host is broken, and the BEI flag stops unrelated interrupts, like the port status change event interrupt. Also, does this same problem affect bulk transfers, in particular those using scatter-gather? Bulk transfers, including scatter-gather transfers, are always translated into one TD, and the BEI flag is not used. AFAIK, this bug only affects transfers with the BEI flag set, so bulk transfers should be fine. Alan, any more questions on this patch? I'd like to get it (and a couple other bug fixes) pushed to Greg this week before the 3.7 merge window. Does this bug only affect isoc devices behind a hub? Can the workaround be limited so devices connected to the root hub can still use BEI? I don't think it's isolated to isoc devices behind a hub, but I'll double check with the hardware guys. 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
Re: [RFC] xhci: Intel Panther Point BEI quirk.
On Mon, 24 Sep 2012, Sarah Sharp wrote: On Mon, Sep 24, 2012 at 01:05:08PM -0700, Sarah Sharp wrote: On Mon, Sep 24, 2012 at 03:50:04PM -0400, Alan Stern wrote: On Mon, 24 Sep 2012, Sarah Sharp wrote: When a device with an isochronous endpoint is behind a hub plugged into the Intel Panther Point xHCI host controller, and the driver submits multiple frames per URB, the xHCI driver will set the Block Event Interrupt (BEI) flag on all but the last TD for the URB. This causes the host controller to place an event on the event ring, but not send an interrupt. When the last TD for the URB completes, BEI is cleared, and we get an interrupt for the whole URB. However, under a Panther Point xHCI host controller, if the parent hub is unplugged when one or more events from transfers with BEI set are on the event ring, a port status change event is placed on the event ring, but no interrupt is generated. This means URBs stop completing, and the USB device disconnect is not noticed. Something like a USB headset will cause mplayer to hang when the device is disconnected. Alan, any more questions on this patch? I'd like to get it (and a couple other bug fixes) pushed to Greg this week before the 3.7 merge window. No more questions. I misunderstood your description of the problem, that's all. But it's already too late for Greg's 3.7 merge window... 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: usb-audio: Increasing MAX_QUEUE to prevent hiccups in the audio stream?
On Tue, 25 Sep 2012, Clemens Ladisch wrote: I'm not completely sure how this stuff works, but I guess there should be some way for an alsa client to rewind the stream, causing one or more urbs to canceled and resubmitted? I'm not sure if cancelling and resubmitting iso URBs work in real time on all HCDs. But if you think you can implemented this, feel free to try. It doesn't work with EHCI. Cancelling an isochronous URB accomplishes practically nothing; the URB is transferred as usual and doesn't terminate early. The only effect is the final value of urb-status. 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: [RFC] xhci: Intel Panther Point BEI quirk.
On Tue, Sep 25, 2012 at 11:10:15AM -0400, Alan Stern wrote: On Mon, 24 Sep 2012, Sarah Sharp wrote: On Mon, Sep 24, 2012 at 01:05:08PM -0700, Sarah Sharp wrote: On Mon, Sep 24, 2012 at 03:50:04PM -0400, Alan Stern wrote: On Mon, 24 Sep 2012, Sarah Sharp wrote: When a device with an isochronous endpoint is behind a hub plugged into the Intel Panther Point xHCI host controller, and the driver submits multiple frames per URB, the xHCI driver will set the Block Event Interrupt (BEI) flag on all but the last TD for the URB. This causes the host controller to place an event on the event ring, but not send an interrupt. When the last TD for the URB completes, BEI is cleared, and we get an interrupt for the whole URB. However, under a Panther Point xHCI host controller, if the parent hub is unplugged when one or more events from transfers with BEI set are on the event ring, a port status change event is placed on the event ring, but no interrupt is generated. This means URBs stop completing, and the USB device disconnect is not noticed. Something like a USB headset will cause mplayer to hang when the device is disconnected. Alan, any more questions on this patch? I'd like to get it (and a couple other bug fixes) pushed to Greg this week before the 3.7 merge window. No more questions. I misunderstood your description of the problem, that's all. But it's already too late for Greg's 3.7 merge window... Unless they are bug fixes :) 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
Re: [RFC] How to handle delays in isochronous transfers?
On Tue, 25 Sep 2012, Laurent Pinchart wrote: All right. It sounds like as far as uvcvideo is concerned, recovering video-in frame synchronization after a drop-out doesn't matter very much. You don't much care if some of the frames are gone from the data stream with no indication as to how many were skipped over. Or if you do care, you don't think there's much to be done about it. I care, but I don't think the USB core can provide me with any useful information. In that case I'll go ahead with the proposed API change. Leaving URB_ISO_ASAP enabled for all your URBs should continue to work as well as could be expected. 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: Question about dev_uevent_filter
On Tue, Sep 25, 2012 at 11:13:43PM +0800, Lan Tianyu wrote: hi Greg: [linux-usb added as it concerns them as well] I find only devices which has bus_type or class can add uevent callback and output the uevent information. This is because the dev_uevent_filter just return true for these devices. But some device may not have class and bus_type. e.g usb endpoint, if we assigned them to usb_bus_type, device core will try to create sysfs directory link under /sys/bus/usb. But endpoint sysfs directory's name are same for each usb devices.e.g ep_00, every usb device will create the endpoint. So in this situation, we can't assign usb endpoint to usb_bus_type. So even if uevent callback was added and with some information, it still couldn't output anything. Can we add dev-type check in the dev_uevent_filter() and return 1 if type exits? Wait, why do you want a uevent for a USB endpoint? What is the problem you are trying to solve here? 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
Re: [BUG] FTDI driver framing error with even parity
On Tue, Sep 25, 2012 at 04:57:43PM +0400, Andrew wrote: Uwe Bonnes писал 25.09.2012 12:46: Andrew == Andrew and...@ncrmnt.org writes: Andrew This is seen on widely used ftdi ft232rl chips. Setting the Andrew parity to something like 'even' results in occasional framing Andrew errors when transmitting data. Andrew Relevant timing diagrams from the logic analyzer are attached to Andrew this bug: https://bugzilla.kernel.org/show_bug.cgi?id=47921 Is this a driver or a hardware thing? I think that this is a driver problem, since windows drivers do not produce any framing errors. I stumbled upon this while reversing the STC microcontroller ISP protocol that happen to use 'even' parity. I can send in more timing diagrams both from windows and linux hosts to compare. I don't see how the ftdi device can change the timings of the signals by the USB side at all, do you? That implies that it couldn't be the driver as it has no control over this type of thing. Or am I missing something from the device spec somewhere? 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
Re: Remote wakeup vs. hub suspend
On Tue, 25 Sep 2012, Peter Chen wrote: On Mon, Sep 24, 2012 at 12:23 AM, Alan Stern st...@rowland.harvard.edu wrote: It turns out that the USB-2 spec does not take into account the possibility of the race between a hub being suspended and one of its ports receiving a remote wakeup request from downstream. The flowcharts and discussions in Chapter 11 ignore the possibility completely. Depending on how closely a particular hub's implementation follows the treatment in the spec, if the two events happen at about the same time then it is possible for the hub to lose the wakeup request, and it is even possible for the hub to think the child device has been disconnected. I believe (though I'm not certain) that people have observed both these things happen during testing. The race _was_ recognized in one of the errata documents published after the USB-2.0 spec came out. The solution recommended in that document is exactly wrong! It says that all the enabled ports on a hub should be suspended before the hub is suspended -- this just makes the race more likely to occur. The only viable solution is to make sure that _none_ of a hub's ports are suspended when the hub is suspended. That way a downstream device will not be able to send a remote wakeup request until after the hub is fully suspended, so the race will never occur. (The situation for USB-3 hubs is somewhat different. Right now I'm only talking about USB-2 hubs, or the HS/FS/LS parts of USB-3 hubs.) For us to do this would be a little difficult. System suspend is easy enough to handle because we don't actually need to put any external ports into suspend; the entire bus will go into global suspend when the root hub is suspended. In fact, this is what we should be doing now (but we aren't). Do you think is it OK to set ehci-no_selective_suspend = 1 for single port controller? In general you should avoid setting that flag if possible. Setting it would prevent the attached device from being runtime suspended. But if that device is a hub, it wouldn't prevent the hub's children from being runtime suspended. The issue described in this email thread affects only external hubs, not root hubs. It's perfectly okay to suspend an EHCI root hub while the ports are suspended -- in fact, the EHCI spec requires this. Currently, both ehci_hub_control and ehci_bus_suspend will go bus suspend routine when CONFIG_USB_SUSPEND is defined, and I am not sure if PSE and ASE is cleared before we let bus go to suspend (at ehci_hub_control). Where does ehci_hub_control put the bus into suspend? It suspends only individual ports, not the whole bus. If if there's only one port, suspending that port does not suspend the whole bus. The frame counter continues to update and the root hub will continue to respond to URBs. 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 1/2] USB: check port changes before hub runtime suspend for some bug device
On Tue, 25 Sep 2012, Ming Lei wrote:
For example on usb HID, see below code in hid_suspend():
if (PMSG_IS_AUTO(message) test_bit(HID_KEYS_PRESSED,
usbhid-iofl)) {
status = -EBUSY;
goto failed;
}
The comment said that most keyboards won't wakeup if a key is released.
If the urb is just completed during suspend(), don't we need to call
pm_wakeup_event() for it? I don't think there will be remote wakeup
for the handled action. In fact, it can be observed easily if some delay
is added before hid_cancel_delayed_stuff() inside hid_suspend().
For this case, I think hid_suspend() needs to test whether wakeup is
enabled and a key is pressed. If both of those are true, we should
call pm_wakeup_event(). We should not call pm_wakeup_event() if wakeup
is not enabled.
I'm afraid that some drivers might return -EBUSY when they shouldn't,
that is, when wakeup is not enabled or a wakeup condition is not
present. (The core can test udev-do_remote_wakeup but it can't test
for a wakeup condition.) If we can guarantee that this never happens
then yes, usb_suspend_interface() could call pm_wakeup_event().
On the other hand, for the particular case of a usb keyboard, I'm not
sure this is the right thing to do. Suppose you try to suspend the
system by typing echo ram /sys/power/state and pressing Enter.
Before you can release the Enter key, the suspend will fail. You'd
have to type something like sleep 1 ; echo ram /sys/power/state.
Also IMO, during system sleep, it is better to handle the wakeup
asap even though the remote wakeup can be generated later
suppose someone triggered one event during or before the
driver's suspend(), right?
I don't think that makes much difference. When the system is going to
sleep, people don't expect it to react quickly to anything.
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 2/2] USB: set hub's default autosuspend delay as 0
On Tue, 25 Sep 2012, Ming Lei wrote: But think of it this way: Suppose there's no driver for a particular device. Its autosuspend delay will get set to the default initially and then there won't be any driver to change it. So when would the delay be changed to 0? How about just keeping the default delay for this device? Then we should also keep the default delay (or the existing delay if it's different from the default) for all devices. I'm not sure that this is something the kernel needs to worry about. Userspace can easily set the default delay to 0 whenever it wants to. This won't affect devices that are already plugged in... but userspace can also set the delays for those devices whenever it wants to. If we can do it in kernel safely and consistently, looks not necessary to bother userspace. But our current userspace interface has this module parameter. I don't think we should start ignoring it. We aren't supposed to change existing user interfaces. This is really a matter of policy -- how long to wait before autosuspending unbound devices. Policy should be decided by userspace, not by the kernel. If the user's power management code wants to save CPU power by autosuspending devices immediately, it can do so. 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: USB tree closed for 3.7
On 09/25/12 15:45, Greg KH wrote: Hi all, If you haven't sent me any pending patches for 3.7, it's a bit too late as I've now closed the usb-next tree for any new stuff for 3.7, unless it's bug fixes. If you have sent me stuff and I've missed it, please let me know as I think my queue is now empty. [ sent to the list only, guess I better Cc you in the future ] http://marc.info/?l=linux-usbm=134856283907957w=2 cheers, Gerd -- 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: [BUG] FTDI driver framing error with even parity
On Tue, 25 Sep 2012, Greg KH wrote: On Tue, Sep 25, 2012 at 04:57:43PM +0400, Andrew wrote: Uwe Bonnes писал 25.09.2012 12:46: Andrew == Andrew and...@ncrmnt.org writes: Andrew This is seen on widely used ftdi ft232rl chips. Setting the Andrew parity to something like 'even' results in occasional framing Andrew errors when transmitting data. Andrew Relevant timing diagrams from the logic analyzer are attached to Andrew this bug: https://bugzilla.kernel.org/show_bug.cgi?id=47921 Is this a driver or a hardware thing? I think that this is a driver problem, since windows drivers do not produce any framing errors. I stumbled upon this while reversing the STC microcontroller ISP protocol that happen to use 'even' parity. I can send in more timing diagrams both from windows and linux hosts to compare. I don't see how the ftdi device can change the timings of the signals by the USB side at all, do you? That implies that it couldn't be the driver as it has no control over this type of thing. Or am I missing something from the device spec somewhere? It might be a good idea to compare a usbmon trace with an equivalent record from a Windows system. 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: Query: usbtest: Test 13: Endpoint Halt Test: At Super Speed does not work
On Tue, Sep 25, 2012 at 03:07:46PM +0300, Felipe Balbi wrote: Hi, On Tue, Sep 25, 2012 at 05:24:25PM +0530, Pratyush Anand wrote: On 9/25/2012 4:49 PM, Felipe Balbi wrote: Can you post dwc3's logs ? We need to see if it executed set_halt() or set_wedge(). Host Does SET FEATURE(ENDPOINT_HALT). dwc3 codes calls __dwc3_gadget_ep_set_halt with correct dep for the specified endpoint. I do not think that dwc3 is doing anything wrong. Anyway, log is attached. indeed, logs look just fine. Sarah, do you know of any bugs on SET_FEATURE(ENDPOINT_HALT) handling on xHCI ?? I actually had a report from someone else that SuperSpeed reset endpoint handling doesn't actually reset the sequence number. Can Pratyush recompile his Linux host side kernel with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING and send me the dmesg? 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
RE: [PATCH 2/3] usb: gadget: Add USB functions gadget
Hi Felipe, On September 19, 2012 2:18 PM Felipe Balbi wrote: snip I wouldn't make functionN a directory. I think it's better to: echo f_mass_storage /cfg/usb-function-gadget/ufg/config0/function0 I'd like to comment a little on your suggestion. In configfs there are config items, which have attributes, and config groups, which are a special kind of items allowed to contain other items (be it config groups or config items). In a filesystem speech this corresponds to directories (items, groups) and files (attributes). The user has control only over creating config items/groups - this is achieved with issuing the mkdir command. In contrast, the user has no control over creating the attributes - no possibility to use touch or echo something to create one. @Joel: Could you please correct me if I'm wrong? So IMO the shortcut you propose is not good, because either we would have to have a predefined number of functionX attributes in a config, or create them programmatically with doing echo new function name to a special attribute, like: $ echo mass_storage /cfg/usb-function-gadget/gadget1/config1/add_fun. and that would create all necessary interfaces and expose all knobs from interfaces and their endpoints. Some after running the command above you would have: /config1/intf0/ /config1/intf0/bLength /config1/intf0/bDescriptorType /config1/intf0/bInterfaceNumber /config1/intf0/bAlternateSetting /config1/intf0/bNumEndpoints /config1/intf0/bInterfaceClass /config1/intf0/bInterfaceSubClass /config1/intf0/bInterfaceProtocol /config1/intf0/iInterface /config1/intf0/ep80/ /config1/intf0/ep80/bLength /config1/intf0/ep80/bDescriptorType /config1/intf0/ep80/bInterfaceNumber /config1/intf0/ep80/bAlternateSetting /config1/intf0/ep80/bNumEndpoints /config1/intf0/ep80/bInterfaceClass /config1/intf0/ep80/bInterfaceSubClass /config1/intf0/ep80/bInterfaceProtocol /config1/intf0/ep80/iInterface /config1/intf0/ep81/ /config1/intf0/ep81/bLength /config1/intf0/ep81/bDescriptorType /config1/intf0/ep81/bInterfaceNumber /config1/intf0/ep81/bAlternateSetting /config1/intf0/ep81/bNumEndpoints /config1/intf0/ep81/bInterfaceClass /config1/intf0/ep81/bInterfaceSubClass /config1/intf0/ep81/bInterfaceProtocol /config1/intf0/ep81/iInterface This is a very strict spec-following structure, which indeed says about configs, interfaces and endpoints rather than functions. I'm not saying this is good or bad. I just want to say that for many functions (all of them?) we need some place to set their specific parameters, like number of luns and names of backing files for mass storage or number of ports and mode (acm, obex) for serial. I think that the concept of a directory lends itself nicely for this purpose. So maybe something on the lines of this should be considered: /config1 /config1/function1/name [mass_storage] /config1/function1/.[function specific stuff] /config1/intf0/. /config1/intf0/epXX/... . . . What do you think? of course only few of those would be writeable from userland, but exposing read-only versions of those might help us find bugs without needing to read the source code. And, you could create as many functionN files as you want under a particular configuration. Provided they are named differently, as a filesystem won't let two files with the same name. AP -- 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] xhci: Intel Panther Point BEI quirk.
On Tue, Sep 25, 2012 at 08:18:57AM -0700, Greg KH wrote: On Tue, Sep 25, 2012 at 11:10:15AM -0400, Alan Stern wrote: On Mon, 24 Sep 2012, Sarah Sharp wrote: On Mon, Sep 24, 2012 at 01:05:08PM -0700, Sarah Sharp wrote: On Mon, Sep 24, 2012 at 03:50:04PM -0400, Alan Stern wrote: On Mon, 24 Sep 2012, Sarah Sharp wrote: When a device with an isochronous endpoint is behind a hub plugged into the Intel Panther Point xHCI host controller, and the driver submits multiple frames per URB, the xHCI driver will set the Block Event Interrupt (BEI) flag on all but the last TD for the URB. This causes the host controller to place an event on the event ring, but not send an interrupt. When the last TD for the URB completes, BEI is cleared, and we get an interrupt for the whole URB. However, under a Panther Point xHCI host controller, if the parent hub is unplugged when one or more events from transfers with BEI set are on the event ring, a port status change event is placed on the event ring, but no interrupt is generated. This means URBs stop completing, and the USB device disconnect is not noticed. Something like a USB headset will cause mplayer to hang when the device is disconnected. Alan, any more questions on this patch? I'd like to get it (and a couple other bug fixes) pushed to Greg this week before the 3.7 merge window. No more questions. I misunderstood your description of the problem, that's all. But it's already too late for Greg's 3.7 merge window... Unless they are bug fixes :) Yeah, these are are bug fixes. I would have sent you to them in the next opportunity after the merge anyway. 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
Re: USB tree closed for 3.7
On Tue, Sep 25, 2012 at 05:00:01PM +0200, Gerd Hoffmann wrote: On 09/25/12 15:45, Greg KH wrote: Hi all, If you haven't sent me any pending patches for 3.7, it's a bit too late as I've now closed the usb-next tree for any new stuff for 3.7, unless it's bug fixes. If you have sent me stuff and I've missed it, please let me know as I think my queue is now empty. [ sent to the list only, guess I better Cc you in the future ] http://marc.info/?l=linux-usbm=134856283907957w=2 Ah, sorry, you are right, I did get those in time, they are in my queue, just no USB prefix on the front of them for my filter to catch :) I'll queue them up later today, thanks for reminding me. 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
Re: Query: usbtest: Test 13: Endpoint Halt Test: At Super Speed does not work
On Tue, 25 Sep 2012, Pratyush Anand wrote: Hi , I use 3.5.3-1.fc17 kernel on my host test PC. I use dwc3 in Super speed mode as usb device, however the issue which I see is not related to usb device. I have observed that testusb (test13, EP halt test) never passes in Supper Speed mode. When simple_io is called second time from verify_halted (ie with label verify_still_halted), wait_for_completion never completes. I need to reboot PC to get xhci port working again. Also on the bus I do not see that host is sending second IN token after Get Status (See snapshot). So, it is clear that xhci driver is stuck some where. The snapshot also shows that the device returned a STALL in the bulk transfer when verify_not_halted() called simple_io(). Why didn't the test fail at that point? 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 10/29] PCI, USB: remove find_bridge in acpi_bus_type
On Tue, Sep 25, 2012 at 1:35 AM, Lan Tianyu lantianyu1...@gmail.com wrote:
2012/9/25 Yinghai Lu ying...@kernel.org:
The struct member is not used anymore, remove it.
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-usb@vger.kernel.org
---
drivers/usb/core/usb-acpi.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index 8947b20..a6ea613 100644
--- a/drivers/usb/core/usb-acpi.c
+++ b/drivers/usb/core/usb-acpi.c
@@ -102,7 +102,6 @@ static int usb_acpi_find_device(struct device *dev,
acpi_handle *handle)
static struct acpi_bus_type usb_acpi_bus = {
.bus = usb_bus_type,
- .find_bridge = NULL,
.find_device = usb_acpi_find_device,
};
HI Yinghai:
This member has been populated in the usb-next tree.
http://git.kernel.org/?p=linux/kernel/git/gregkh/usb.git;a=commit;h=d557542421da643358201664903e67fd01dfca1a
Thanks for pointing that out.
Looks that following change is not needed in that commit.
@@ -102,7 +139,7 @@ static int usb_acpi_find_device(struct device
*dev, acpi_handle *handle)
static struct acpi_bus_type usb_acpi_bus = {
.bus = usb_bus_type,
- .find_bridge = NULL,
+ .find_bridge = usb_acpi_find_device,
.find_device = usb_acpi_find_device,
};
Can you double check if it will work without that line change?
-Yinghai
--
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: usb3 fails to write when using usb3 hub in usb3 port
After each test I've only plugged ou the drive from the hub ( the hub remained connected to the computer ) Results: Directory indexing enabled .. http://d3xt3r01.tk/~dexter/usbmon/ Nevermind my last email .. seems I've been catting the wrong 9u ! :| the files seem too small :| Will redo everything again tomorrow ( my birthday .. yey ) .. The kernel used was vanilla 3.4.11 on a gentoo system .. After all these tests .. I think the drive is ok .. at least .. the hub might have some problems ( both the gembird and the one in the asrock .. or at least one of them .. ) but I don't get what as .. it seems to work on my laptop :| Please let me know how I can be of more assistance / help :| -- 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: usb3 fails to write when using usb3 hub in usb3 port
On Tue, Sep 25, 2012 at 2:19 PM, Sarah Sharp
sarah.a.sh...@linux.intel.com wrote:
On Tue, Sep 25, 2012 at 09:26:00AM +0300, Adrian Sandu wrote:
On Tue, Sep 25, 2012 at 12:38 AM, Sarah Sharp
sarah.a.sh...@linux.intel.com wrote:
Ok, so 3.4.11 doesn't work, and the log file was from 3.5.
If you want I can provide a 3.4 log...
Hmm, does a 3.3 stable kernel work for you? I have a hypothesis.
Alan, I'm wondering if the xHCI ring expansion is causing issues with
USB hard drives under xHCI. Testing with a Buffalo USB 3.0 hard drive
with an NEC uPD720200 xHCI host, I see that the usb-storage and SCSI
initialization produces I/O errors on random sectors in 3.4.0, 3.4.6,
and 3.5.0. I can't get those errors to be reproduced in 3.3.1.
Do you see the ring get expanded(more than 2 segments) when the errors occur?
The xHCI ring expansion was added in 3.4, and we changed the xHCI's
sg_tablesize:
int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
{
...
/* Accept arbitrarily long scatter-gather lists */
hcd-self.sg_tablesize = ~0;
Actually this line is copied from ehci-hcd.
Thanks,
Andiry
The usb-storage driver sets the tablesize thus:
static unsigned int usb_stor_sg_tablesize(struct usb_interface *intf)
{
struct usb_device *usb_dev = interface_to_usbdev(intf);
if (usb_dev-bus-sg_tablesize) {
return usb_dev-bus-sg_tablesize;
}
return SG_ALL;
}
I notice that SG_ALL is set to SCSI_MAX_SG_SEGMENTS, which is only 128.
Should we be passing an arbitrarily large number to the SCSI core?
There's some wording in include/scsi/scsi.h about also limiting the
number of chained sgs to 2048. I'm wondering if we're hitting some bugs
in the SCSI layer because we're setting the sg_tablesize so high.
Alternately, we could be hitting bugs in the USB 3.0 firmware when we
attempt to issue a read or write that's too big. The read on Adrian's
hard drive failed on a bigger read request (122880 bytes). It would be
interesting to see if it works fine if the xHCI sg_tablesize is limited.
I'm going to try that with my own drive on 3.5.4 and see if it helps.
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
--
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: usb3 fails to write when using usb3 hub in usb3 port
On Wed, Sep 26, 2012 at 12:03:48AM +0300, Adrian Sandu wrote: On Tue, Sep 25, 2012 at 9:26 AM, Adrian Sandu dex...@d3xt3r01.tk wrote: On Tue, Sep 25, 2012 at 12:38 AM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: I did some more tests. Just to make sure that I wasn't imagining things ... The file I'm trying to copy is a msdn iso of about 1.7G ( don't know if this matters as I've tried with a dd if=/dev/urandom of=/root/en bs=1024 count=2GB ) Ok, good to know. So you're using 1K block sizes. Were you copying the file with dd before, or just drag and dropping it? just a reminder .. my laptop is a vaio vpcf13m1e ( which seems to work every time ) .. the one with the problems is an asrock 152d .. Both seem to share the usb3 root hub chipset ( a nec uPD720200 ) the tests are done using a gembird usb3 hub ( which reports idVendor=2109, idProduct=0810 VIA Labs, Inc. 4-Port USB 3.0 HUB .. idVendor=2109, idProduct=3431 .. USB2.0 Hub ) I have another hub, a manhattan ( which reports the same 2 stuff at lsusb ) sda3 is my local drive in the asrock ( a 2.5 normal hdd which does its job just fine for 1 year now 24/7 ) 1) Copy to/from the drive directly from/to my laptop 2 times ( in each dirrection ) WORKS 2) Copy to/from and from/to 1 drive in/through the hub on my laptop 2 times ( in each dirrection ). WORKS 3) Copy to/from the drive directly from/to the asrock 2 times ( in each dirrection ) WORKS 4) Copy to/from and from/to 1 drive in/through the hub on my asrock 2 times ( in each dirrection ). I have /dev/sdb1 mounted in /media/sdg1 .. (sdg because I usually have more drives) cp /media/sdg1/en2 ~/en2 try1 copy from sdb1 to sda3 .. seems to succeed ?! cp didn't say anything .. but /var/log/messages shows some stuff try2 copy from sdb1 to sda3 .. seems to succeed ?! cp didn't say anything .. just as above cp ~/en2 /media/sdg1/en2 try3 copy from sda3 to sdb1 .. seems to succeed .. cp didn't say anything .. nor anything weird in /var/log/messages try4 .. just plugging in the drive caused some messages .. didn't have the cat on 9u started though and couldn't reproduce it .. try5 copy from sda3 to sdb1 .. seems to succeed .. cp didn't say anything .. nor anything weird in /var/log/messages copy using mc from /media/sdg1/en2 to ~/en2 try6 .. copy from sdb1 to sda3 .. seems to succeed .. but I see messages in /var/log/messages .. try7 .. same .. Ok, so reads from the drive produce some messages, but writes don't. Note that weird stuff in /var/log/messages does not necessarily mean that the hard drive is broken. Sometimes it may take two tries to make a particular read or write succeed, or maybe the drive doesn't like a particular SCSI command type and so the SCSI layer tries another command type. The device sometimes gets reset, but that's normal. And if the messages you mention are about disabling endpoints or LPM, then those are just warnings, not errors. Basically, your file transfer should be OK as long as you don't see any I/O errors. What really matters is whether the file got successfully copied or not. If cp didn't give you any errors, the file got copied. You can make sure it's exact duplicate by running diff against the two files. Or if you're copying a large number of directories, you could use git in the base directory, create the initial commit of the files, copy the directory over, and run `git diff` to see if anything changed. copy using mc from ~/en2 to /media/sdg1/en2 try8 .. copy from sda3 to sdb1 .. succedes just fine .. no messages no nothing .. try9 .. same .. adding a new drive in the hub ! :) copy using mc from sdb to sdc try10 .. there's some weird thing going in my /var/log/messages .. plugging out and back in the hub with all drives :) ( along with some rmmod xhci_hcd .. usb_storage and modprobe-ing them again ) fails .. Is there any way you could send the logs as attachments or get your mail client not to wrap long lines? It's pretty hard to read. try11 .. 2012-09-26T00:02:38.810382+03:00 d3xt3r01 kernel: [93320.454212] xhci_hcd :04:00.0: Host not halted after 16000 microseconds. 2012-09-26T00:02:38.810393+03:00 d3xt3r01 kernel: [93320.454212] xhci_hcd :04:00.0: Host controller not halted, aborting reset. Hmm, that's not cool. The xHCI hardware didn't want to halt within 16 seconds, which usually means it's hung. I'm guessing the modprobe or rmmod failed for the xhci-hcd driver? 2012-09-26T00:02:38.815117+03:00 d3xt3r01 kernel: [93320.496220] xhci_hcd :04:00.0: USB bus 1 deregistered 2012-09-26T00:02:41.416854+03:00 d3xt3r01 kernel: [93323.097171] xhci_hcd :04:00.0: xHCI Host Controller 2012-09-26T00:02:41.416932+03:00 d3xt3r01 kernel: [93323.097927] xhci_hcd :04:00.0: new USB bus registered, assigned bus number 1 2012-09-26T00:02:41.463589+03:00 d3xt3r01 kernel: [93323.143244] xhci_hcd :04:00.0: Host not halted after 16000 microseconds.
[PATCH 1/3] Increase XHCI suspend timeout to 16ms
From: Michael Spang sp...@chromium.org
The Intel XHCI specification says that after clearing the run/stop bit
the controller may take up to 16ms to halt. We've seen a device take
14ms, which with the current timeout of 10ms causes the kernel to
abort the suspend. Increasing the timeout to the recommended value
fixes the problem.
This patch should be backported to kernels as old as 2.6.37, that
contain the commit 5535b1d5f8885695c6ded783c692e3c0d0eda8ca USB: xHCI:
PCI power management implementation.
Signed-off-by: Michael Spang sp...@chromium.org
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 a4b0ce1..52b04b0 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -888,7 +888,7 @@ int xhci_suspend(struct xhci_hcd *xhci)
command = ~CMD_RUN;
xhci_writel(xhci, command, xhci-op_regs-command);
if (handshake(xhci, xhci-op_regs-status,
- STS_HALT, STS_HALT, 100*100)) {
+ STS_HALT, STS_HALT, XHCI_MAX_HALT_USEC)) {
xhci_warn(xhci, WARN: xHC CMD_RUN timeout\n);
spin_unlock_irq(xhci-lock);
return -ETIMEDOUT;
--
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 3/3] xhci: Intel Panther Point BEI quirk.
When a device with an isochronous endpoint is behind a hub plugged into
the Intel Panther Point xHCI host controller, and the driver submits
multiple frames per URB, the xHCI driver will set the Block Event
Interrupt (BEI) flag on all but the last TD for the URB. This causes
the host controller to place an event on the event ring, but not send an
interrupt. When the last TD for the URB completes, BEI is cleared, and
we get an interrupt for the whole URB.
However, under a Panther Point xHCI host controller, if the parent hub
is unplugged when one or more events from transfers with BEI set are on
the event ring, a port status change event is placed on the event ring,
but no interrupt is generated. This means URBs stop completing, and the
USB device disconnect is not noticed. Something like a USB headset will
cause mplayer to hang when the device is disconnected.
If another transfer is sent (such as running `sudo lsusb -v`), the next
transfer event seems to unstick the event ring, the xHCI driver gets
an interrupt, and the disconnect is reported to the USB core.
The fix is not to use the BEI flag under the Panther Point xHCI host.
This will impact power consumption and system responsiveness, because
the xHCI driver will receive an interrupt for every frame in all
isochronous URBs instead of once per URB.
Intel chipset developers confirm that this bug will be hit if the BEI
flag is used on any endpoint, not just ones that are behind a hub.
This patch should be backported to kernels as old as 3.0, that contain
the commit 69e848c2090aebba5698a1620604c7dccb448684 Intel xhci: Support
EHCI/xHCI port switching.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-pci.c |1 +
drivers/usb/host/xhci-ring.c |4 +++-
drivers/usb/host/xhci.h |1 +
3 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 9bfd4ca11..8345d7c 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -103,6 +103,7 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
* PPT chipsets.
*/
xhci-quirks |= XHCI_SPURIOUS_REBOOT;
+ xhci-quirks |= XHCI_AVOID_BEI;
}
if (pdev-vendor == PCI_VENDOR_ID_ETRON
pdev-device == PCI_DEVICE_ID_ASROCK_P67) {
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index f270e70..c6ebb17 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3672,7 +3672,9 @@ static int xhci_queue_isoc_tx(struct xhci_hcd *xhci,
gfp_t mem_flags,
} else {
td-last_trb = ep_ring-enqueue;
field |= TRB_IOC;
- if (xhci-hci_version == 0x100) {
+ if (xhci-hci_version == 0x100
+ !(xhci-quirks
+ XHCI_AVOID_BEI)) {
/* Set BEI bit except for the last td */
if (i num_tds - 1)
field |= TRB_BEI;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index e44e2d3..53df4e7 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1511,6 +1511,7 @@ struct xhci_hcd {
#define XHCI_INTEL_HOST(1 12)
#define XHCI_SPURIOUS_REBOOT (1 13)
#define XHCI_COMP_MODE_QUIRK (1 14)
+#define XHCI_AVOID_BEI (1 15)
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
/* There are two roothubs to keep track of bus suspend info for */
--
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 2/3] usb: host: xhci: Fix Null pointer dereferencing with 71c731a for non-x86 systems
From: Vivek Gautam gautam.vi...@samsung.com In 71c731a: usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware when extracting DMI strings (vendor or product_name) to mark them as quirk we may get NULL pointer in case of non-x86 systems which won't define CONFIG_DMI. Hence susbsequent strstr() calls crash while driver probing. So, returning 'false' here in case we get a NULL vendor or product_name. This is tested with ARM (exynos) system. This patch should be backported to stable kernels as old as 3.6, that contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com Reported-by: Sebastian Gottschall (DD-WRT) s.gottsch...@dd-wrt.com Cc: sta...@vger.kernel.org --- drivers/usb/host/xhci.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 52b04b0..8d7fcbb 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -471,6 +471,8 @@ static bool compliance_mode_recovery_timer_quirk_check(void) dmi_product_name = dmi_get_system_info(DMI_PRODUCT_NAME); dmi_sys_vendor = dmi_get_system_info(DMI_SYS_VENDOR); + if (!dmi_product_name || !dmi_sys_vendor) + return false; if (!(strstr(dmi_sys_vendor, Hewlett-Packard))) 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: [PATCH v2 0/5] uas: bug fixes
On Tue, Sep 25, 2012 at 10:47:03AM +0200, Gerd Hoffmann wrote: Hi, Resending whole uas bug fix patch series. Patches #3 + #5 got updated, addressing review comments. The fixed patches have been on the list already, but not yet the whole series as updated v2. Sorry for the delay, now all applied. And yes, it helps to at least cc: me to ensure I don't miss the patches. 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
Re: [Pull Request] xHCI bug fixes for 3.7
On Tue, Sep 25, 2012 at 03:29:23PM -0700, Sarah Sharp wrote: The following changes since commit f3f4bf5cf0896e58e9831ea53bcb8c7d88127d20: USB: ohci-at91: fix null pointer in ohci_hcd_at91_overcurrent_irq (2012-09-24 10:42:25 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-next-2012-09-25 Pulled and pushed out, 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
libusbx-1.0.14 has been released
a.k.a. 1.0.13, we hardly knew ye. * Reverts the previous API change with regards to bMaxPower. * Note that LIBUSBX_API_VERSION is *decreased* to 0x01FF and the previous guidelines with regards to concurrent use of MaxPower/bMaxPower still apply. Regards, /Pete -- 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: XHCI Bug discovered in 3.6-RC6 (solution included)
Apologies for that. I should have been rather a bit patient. Best regards Vivek On Tue, Sep 25, 2012 at 7:10 PM, Greg KH g...@kroah.com wrote: A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, Sep 25, 2012 at 03:12:33PM +0530, Vivek Gautam wrote: Hi I have posted the required patch for this: usb: host: xhci: Fix Null pointer dereferencing with 71c731a for non-x86 systems You sent this last saturday, a mere 3 days ago, two of them on a weekend, please be patient. 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
152d:0539 JMicron Technology USB - eSata and sata port multiplier
Hi, I have been trying for some time to get a JMicron USB/eSata adapter to work properly with a 4 drive Silicon Image based port multiplier enclosure without success. The port multiplier and drives work cleanly off a PCI Silicon Image eSata card using Debian Wheezy. Bus 002 Device 004: ID 152d:0539 JMicron Technology Corp. / JMicron USA Technology Corp. First attempt was with a stock Ubuntu 12.04 kernel, further attempts were with a 3.2.27 kernel with the patches here manually applied: http://marc.info/?l=linux-usbm=132586396527466w=2 My most recent tests have been with 3.6.0-rc6 (no patches) In all cases I am getting the following kernel output trying to access any of the 4 drives (/dev/sdc - /dev/sdf): [ 463.600972] sd 7:0:0:0: [sdc] Unhandled error code [ 463.600981] sd 7:0:0:0: [sdc] [ 463.600986] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 463.600992] sd 7:0:0:0: [sdc] CDB: [ 463.600995] Read(10): 28 00 74 70 6d 70 00 00 08 00 [ 463.601016] end_request: I/O error, dev sdc, sector 1953525104 [ 463.601026] Buffer I/O error on device sdc, logical block 244190638 [ 463.720092] usb 2-4: reset high-speed USB device number 4 using ehci_hcd Please find the usbmon output (taken while trying to do an fdisk -l on each of the drives) and hopefully some other useful bits of information here: http://biggeeks.org/~harry/3.6.0-rc6/ Any suggestions, patches, etc are welcome, this system is a home system, and can be easily rebooted to try any fixes suggested. -Harry -- 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 4/4] usb: phy: omap-usb2: enable 960Mhz clock for omap5
Hi,
On Wed, Sep 19, 2012 at 5:26 PM, Felipe Balbi ba...@ti.com wrote:
On Wed, Sep 19, 2012 at 05:00:29PM +0530, Kishon Vijay Abraham I wrote:
usb_otg_ss_refclk960m is needed by usb2 phy present in omap5. For
omap4, the clk_get of this clock will fail since it does not have this
clock.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt |3 +++
drivers/usb/phy/omap-usb2.c | 28
-
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 7c5fd89..d5626de 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -24,6 +24,9 @@ Required properties:
add the address of control module phy power register until a driver for
control module is added
+Optional properties:
+ - has960mhzclk: should be added if the phy needs 960mhz clock
+
This is usually a subnode of ocp2scp to which it is connected.
usb3phy@4a084400 {
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index d36c282..d6612ba 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -146,6 +146,7 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
struct omap_usb *phy;
struct usb_otg *otg;
struct resource *res;
+ struct device_node *np = pdev-dev.of_node;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -190,6 +191,15 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
}
clk_prepare(phy-wkupclk);
+ if (of_property_read_bool(np, has960mhzclk)) {
+ phy-optclk = devm_clk_get(phy-dev, usb_otg_ss_refclk960m);
+ if (IS_ERR(phy-optclk)) {
+ dev_err(pdev-dev, unable to get refclk960m\n);
+ return PTR_ERR(phy-optclk);
+ }
+ clk_prepare(phy-optclk);
+ }
instead, can't you just always try to get the clock but ignore the error
if it fails ?
This clock is needed for usb2 to work in dwc3 (omap5). So we have to
report the error in case we dont get the clock no?
Thanks
Kishon
--
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 1/1] usb: Include generic_interrupt for OMAP2_PLUS
On Tue, Sep 25, 2012 at 2:39 PM, Philippe De Swert philippedesw...@gmail.com wrote: Hi, On 25/09/2012, Felipe Balbi ba...@ti.com wrote: Then maybe it's best to just remove the ifdefs and always provide generic_interrupt() ? Anyone against it ? Providing generic_interrupt seems fine. Well it seems there are only two drivers that use it omap2430 and ux500. Maybe we somehow link it to the drivers that need it? (I might have missed other drivers but it looks like it is just those two) One way I see is that omap2430 and ux500 implement the isr handler in platform glue driver and then call the musb_interrupt() as done in daxxx, amxxx, ti8xxx platforms. Then generic_interrupt can be removed. -- 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
