Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

2012-12-12 Thread Lan Tianyu 
On 2012年12月12日 05:59, Frank Schäfer wrote:
 Am 11.12.2012 17:48, schrieb Alan Stern:
 
 [snip]

 We really need to know which component is bad: the host controller or 
 the device.
 
 It happens with all USB 1.1 devices I have (several mice and a HP
 Deskjet 960c printer).
 The same devices do not cause other machines to wake up, so I assume
 it's the host controller.
Good information. Attaching device makes hc work abnormally during
entering into s3 since without device it can work, right?

I am curious about whether disabling usb device's wakeup rather than usb
hc's would make suspend work. Can you do a test?

Go to /sys/bus/usb/devices/ and enter the usb 1,1 device
directory(normally it will be something like1-1.1.)
run echo disabled  power/wakeup.
Do this for all devices under OHCI/UHCI and test again. Thanks.
This can answer Alan's question
Does the HC turn on the GPE even when the device does not send a remote
wakeup request?


 
 I don't know enough about the low level details,  so I really can't
 contribute anything else than doing testing / debugging.
 
 If it comes to blacklisting, do you think there is a chance/possibility
 to get a statement form NVIDA about this issue ?
 It seems that at least the MCP51, MCP55 and MCP61 chipsets are affected...
I think we can default disable OHCI/UHCI wakeup on these board to avoid
the problems. Before doing this, I think we should try to make the issue
clear.


Hi Alan:
About your question of Does the device send a remote wakeup request
even when it is disabled for remote wakeup?, I am not very clear.
Default, device remote wakeup is disabled and if we disable device's
remote wakeup via sysfs, the device's remote wakeup feature will not be
set during being suspended. So normally, it should not send out remote
wakeup signal but if it still sent out, this means it's a buggy device,
right?
Moreover, this test is hard to do during s3 since system suspend, we
can't see any log. So this should be done in the runtime. I think it's
easy to do this test on mouse or keyboard device.

 
 Regards,
 Frank
 

 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
 


-- 
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: Linux USB file storage gadget with new UDC

2012-12-12 Thread Felipe Balbi 
Hi,

On Wed, Dec 12, 2012 at 03:49:48PM +0800, victor wrote:
 Hi,
 
  
   Yes, the devices /dev/mmcblk0 and /dev/mmcblk0p1 exist. The
   /dev/mmcblk0 can be mounted. The dmesg does not contain other
   messages. I am not sure the way to use g_file_storage.ko with UDC.
 Please
  kindly help me.
  
   # ls /dev/mmc*
   /dev/mmc0   /dev/mmc2   /dev/mmcblk0p1
   /dev/mmc1   /dev/mmcblk0/dev/mmcblk0p2
  
   # mount /dev/mmcblk0 /mnt
   # ls /mnt/
   initramfs.gz
   # umount /mnt
   umounting 1
   umounting 0
   # insmod kagen2_udc.ko
   # insmod g_file_storage.ko file=/dev/mmcblk0
   insmod: can't insert 'g_file_storage.ko': No such device
  
  are you registering your udc with the udc class ?? Are you initilizing
  udc-gadget.dev ? Look at other udc drivers to check if you're missing
  something. For example look at
  drivers/usb/dwc3/gadget.c::dwc3_gadget_init() to see how I register the
  gadget device and how I add the gadget to the list of UDCs.
  
  Also look at drivers/usb/dwc3/gadget.c::dwc3_gadget_start() to see how
 that
  should be implemented.
  --
  balbi
 
 I look at drivers/usb/dwc3/gadget.c and compare to my UDC code. The
 difference is my UDC probe function is declared in platform driver, and the
 platform probe function is not called. How could the file storage gadget
 know it needs to call my UDC code? Is it done by the
 platform_add_devices(struct platform_device **pdevs, int ndev) which is to
 add UDC driver to the linux system?
  
 Here is my probe function. Somehow, It is not called after insmod. 

if it's not called it's because you don't have a matching
platform_device.

For a driver's probe() to be called you need a platform_device with the
same name.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 08/10] usb: add usb port auto power off mechanism

2012-12-12 Thread Lan Tianyu 
On 2012年12月12日 00:35, Alan Stern wrote:
 On Tue, 11 Dec 2012, Lan Tianyu wrote:
 
 @@ -108,11 +109,14 @@ MODULE_PARM_DESC(use_both_schemes,
  DECLARE_RWSEM(ehci_cf_port_reset_rwsem);
  EXPORT_SYMBOL_GPL(ehci_cf_port_reset_rwsem);

 +#define HUB_PORT_RECONNECT_TRIES  20

 20 is an awful lot.  Do you really need any more than one try?  The 
 debounce routine already does its own looping.
 I tested a usb ssd which consumes about 1s to makes usb port status
 enter into connect status after powering off and powering on the port.
 So I set the tries 20 and the longest latency is larger than 2s.
 The debounce routine only guarantees port status stable rather than
 enter into connect status.
 
 Then a better solution would be to first wait (up to 2 seconds) for a 
 connect status and then call the debounce routine.
But some devices don't need to wait 2s such long time,  200ms is enough
for them. So I try to check status everytime  after debounce. If it's
connected, go away.
 
 @@ -718,13 +722,26 @@ int usb_hub_set_port_power(struct usb_device
 *hdev, int port1,
bool set)
  {
int ret;
 +  struct usb_hub *hub = hdev_to_hub(hdev);
 +  struct usb_port *port_dev
 +  = hub-ports[port1 - 1];
 +
 +  if (set) {
 +  if (port_dev-power_is_on)
 +  return 0;

 -  if (set)
ret = set_port_feature(hdev, port1,
USB_PORT_FEAT_POWER);
 -  else
 +  } else {
 +  if (!port_dev-power_is_on)
 +  return 0;
 +
ret = clear_port_feature(hdev, port1,
USB_PORT_FEAT_POWER);
 +  }

 Do we need these shortcuts?  How often will this routine be called when
 the port is already in the right state
 When the PM Qos NO_POWER_OFF is changed,
 pm_runtime_get_sync/put(port_dev) will be invoked. This routine will be
 called during port resume and suspend. If one device was suspended and
 power off, the port's usage_count would be 0. After then, the port will
 be resumed and suspend every time pm qos NO_POWER_OFF flag being
 changed. So this depends on the user space.
 
 You did not understand my question.  When usb_hub_set_port_power is 
 called, won't the Set-Feature request almost always be necessary?
 
Oh. Sorry. Thanks for reminders. :)

 For example, how often will it happen that set and 
 port_dev-power_is_on are both true?  Or both false?  It seems to me 
 that this will almost never happen.  So why bother testing for it?
Ok. I get. You are right and will remove the check.
 
 @@ -2862,6 +2884,18 @@ int usb_port_suspend(struct usb_device *udev,
 pm_message_t msg)
udev-port_is_suspended = 1;
msleep(10);
}
 +
 +  /*
 +   * Check whether current status is meeting requirement of
 +   * usb port power off mechanism
 +   */
 +  if (!udev-do_remote_wakeup
 +   (dev_pm_qos_flags(port_dev-dev,
 +  PM_QOS_FLAG_NO_POWER_OFF) != PM_QOS_FLAGS_ALL)
 +   udev-persist_enabled
 +   !status)
 +  pm_runtime_put_sync(port_dev-dev);

 You need to store somewhere the fact that you made this call, so that 
 you will know whether or not to make the corresponding 
 pm_runtime_get_sync call in usb_port_resume.
 You mean I should add a new flag to keep the
 pm_runtime_put_sync/put(port_dev) being called paired, right?
 How about needs_resume?
 
 What you need isn't a resume; it's pm_runtime_get_sync.
How about needs_runtime_get?
 
 @@ -2982,10 +3035,39 @@ static int finish_port_resume(struct usb_device
 *udev)
  int usb_port_resume(struct usb_device *udev, pm_message_t msg)
  {
struct usb_hub  *hub = hdev_to_hub(udev-parent);
 +  struct usb_port *port_dev = hub-ports[udev-portnum  - 1];
int port1 = udev-portnum;
int status;
u16 portchange, portstatus;

 +
 +  set_bit(port1, hub-busy_bits);
 +
 +  if (!port_dev-power_is_on) {

 This test is wrong.  It's possible that the port power is still on even 
 though you called pm_runtime_put_sync.
 Above, we need to check the new flag, right?
 
 Yes.
 
 +  status = pm_runtime_get_sync(port_dev-dev);
 +  if (status  0) {
 +  dev_dbg(udev-dev, can't resume usb port, status 
 %d\n,
 +  status);
 +  clear_bit(port1, hub-busy_bits);
 +  return status;
 +  }

 Don't you want to call usb_port_wait_for_connected right here?

 +  }
 +
 +
 +  /*
 +   * Wait for usb hub port to be reconnected in order to make
 +   * the resume procedure successful.
 +   */
 +  if (port_dev-needs_debounce) {
 +  status = usb_port_wait_for_connected(hub, port1);

 If you move this call earlier then you won't have to test
 needs_debounce.
 The port may have been power on when device is resumed. One case, after
 device being suspended and power off, user may set the NO_POWER_OFF flag
 and port will be power on before device being resumed. For this case,
 port

Re: USB Gadget driver: Add support for CD-ROM booting

2012-12-12 Thread Golmer Palmer 
Alan Stern stern@... writes:

 
 On Mon, 10 Dec 2012, Golmer Palmer wrote:
 
  Alan Stern stern@... writes:
  
   
   Right.  This limit represents a hypothetical 256-minute CD.
  
  256 minutes CD, ok! (75 represents 75 sectors/sec)
 
 Yes.

So 255M:60S:75F

 
Nevertheless, with a DVD the  maximum sectors are 4,173,824 (DVD-9 DL). 
So 
  why 
this limit? As we can supose that the driver can work with a DVD ISO 
image, 
  why 
not increase the limit to DVD specs?
   
   Although the driver can work with a DVD ISO image, it does not emulate 
   a DVD.  Only a CD.
  
  Yes, not a DVD. But if you mount a DVD image with the cdrom emulation, it 
  works! So, please, update the limit to 950*60*75 (4,275,000 sectors). This 
is an 
  hypothetical 950 minutes CD-ROM, with a size bigger than a DVD-9 DATA 
disk.
 
 I can't.  The CD spec requires that under certain conditions, block 
 addresses on the device be presented in MSF format, where M is 
 minutes, S is seconds, and F is frames, and each occupies a single 
 byte.  There's no way to represent more than 255 minutes.

Ok, now I know why this limit!

I feel that in the future a CD/DVD/BD USB gadget driver can be interesting.


 Alan Stern

I'll post my tests over the patches for cdrom booting when I can apply them to 
my Android device.

Thank you Alan!

--
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/1]linux-usb: optimize to match the Huawei USB storage devices and support new switch command

2012-12-12 Thread fangxiaozhi 00110321 
From: fangxiaozhi huana...@huawei.com

1. To optimize the match rules for the Huawei USB storage devices. Avoid to 
load USB storage driver for modem interface with Huawei devices.
2. Add to support new switch command for new Huawei USB dongles.

Signed-off-by: fangxiaozhi huana...@huawei.com
-
diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.c 
linux-3.7/drivers/usb/storage/initializers.c
--- linux-3.7_bak/drivers/usb/storage/initializers.c2012-12-11 
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/initializers.c2012-12-12 
16:26:53.0 +0800
@@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_dat
return 0;
 }
 
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us)
+/* This places the HUAWEI usb dongles in multi-port mode */
+static int usb_stor_huawei_feature_init(struct us_data *us)
 {
int result;
 
@@ -104,3 +104,60 @@ int usb_stor_huawei_e220_init(struct us_
US_DEBUGP(Huawei mode set result is %d\n, result);
return 0;
 }
+
+/*Find the supported Huawei USB dongles*/
+static int usb_stor_huawei_dongles_pid(struct us_data *us)
+{
+   int ret = 0;
+   struct usb_interface_descriptor *idesc = NULL;
+   idesc = us-pusb_intf-cur_altsetting-desc;
+   if (idesc != NULL  idesc-bInterfaceNumber == 0) {
+   if ((us-pusb_dev-descriptor.idProduct = 0x1401  
us-pusb_dev-descriptor.idProduct = 0x1600)
+   || (us-pusb_dev-descriptor.idProduct 
= 0x1c02  us-pusb_dev-descriptor.idProduct = 0x2202)
+   || (us-pusb_dev-descriptor.idProduct 
== 0x1001)
+   || (us-pusb_dev-descriptor.idProduct 
== 0x1003)
+   || (us-pusb_dev-descriptor.idProduct 
== 0x1004)) {
+
+   if (us-pusb_dev-descriptor.idProduct = 
0x1501 
+us-pusb_dev-descriptor.idProduct 
= 0x1504) {
+   ret = 0;
+   } else {
+   ret = 1;
+   }
+   }
+   }
+   return ret;
+}
+
+static int usb_stor_huawei_scsi_init(struct us_data *us)
+{
+   int result = 0;
+   int act_len = 0;
+   unsigned char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x00, 
0x00, 
+ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00};
+   struct bulk_cb_wrap bcbw = {0};
+   bcbw.Signature = cpu_to_le32(US_BULK_CB_SIGN);
+   bcbw.Tag = 0;
+   bcbw.DataTransferLength = cpu_to_le32(0);
+   bcbw.Flags = bcbw.Lun = 0;
+   bcbw.Length = sizeof(rewind_cmd);
+   memset(bcbw.CDB, 0, sizeof(bcbw.CDB));
+   memcpy(bcbw.CDB, rewind_cmd, sizeof(rewind_cmd));
+
+   result = usb_stor_bulk_transfer_buf (us, us-send_bulk_pipe, bcbw, 31, 
act_len);
+   US_DEBUGP(usb_stor_bulk_transfer_buf performing result is %d, transfer 
the actual length=%d\n, result, act_len);
+   return result;
+}
+
+int usb_stor_huawei_init(struct us_data *us)
+{
+   int result = 0;
+   if(usb_stor_huawei_dongles_pid(us)) {
+   if ((us-pusb_dev-descriptor.idProduct = 0x1446)) {
+   result = usb_stor_huawei_scsi_init(us);
+   } else {
+   result = usb_stor_huawei_feature_init(us);
+   }
+   }
+   return result;
+}
diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.h 
linux-3.7/drivers/usb/storage/initializers.h
--- linux-3.7_bak/drivers/usb/storage/initializers.h2012-12-11 
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/initializers.h2012-12-12 
11:43:58.0 +0800
@@ -46,5 +46,5 @@ int usb_stor_euscsi_init(struct us_data 
  * flash reader */
 int usb_stor_ucr61s2b_init(struct us_data *us);
 
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us);
+/* This places the HUAWEI usb dongles in multi-port mode */
+int usb_stor_huawei_init(struct us_data *us);
diff -uprN linux-3.7_bak/drivers/usb/storage/unusual_devs.h 
linux-3.7/drivers/usb/storage/unusual_devs.h
--- linux-3.7_bak/drivers/usb/storage/unusual_devs.h2012-12-11 
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/unusual_devs.h2012-12-12 
11:47:34.0 +0800
@@ -1527,335 +1527,10 @@ UNUSUAL_DEV(  0x1210, 0x0003, 0x0100, 0x
 /* Reported by fangxiaozhi huana...@huawei.com
  * This brings the HUAWEI data card devices into multi-port mode
  */
-UNUSUAL_DEV(  0x12d1, 0x1001, 0x, 0x,
+UNUSUAL_VENDOR_INTF(  0x12d1, 0x08, 0x06, 0x50,
HUAWEI MOBILE,
Mass Storage,
-   USB_SC_DEVICE, USB_PR_DEVICE,

Re: Linux USB file storage gadget with new UDC

2012-12-12 Thread Bjørn Mork 
Alan Stern st...@rowland.harvard.edu writes:

 If you read the confidentiality notice, you'll see that it merely says 
 that the contents of the email _may_ be confidential.  Also, it warns 
 people who _aren't_ the intended addressees -- but if the message was 
 sent to a public email list then obviously there are no such people.

 So I don't see any problem.

Then I guess you missed this unconditional part?:

 be aware that any disclosure, copying, distribution or use of this
  e-mail or any attachment is prohibited. 

This means that victor is deliberately violating his company policy by
continuing to send emails to a public list, which is the direct action
causing disclosure, copying and distribution of the e-mail.  You can of
course not blame list admins or subscribers here.

I still do not see how a patch with such restrictions can be useful to
anyone. But I am not the one to decide that...



Bjørn
--
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]linux-usb: optimize to match the Huawei USB storage devices and support new switch command

2012-12-12 Thread Felipe Balbi 
Hi,

ok, let's start.

On Wed, Dec 12, 2012 at 06:20:33PM +0800, fangxiaozhi 00110321 wrote:
 From: fangxiaozhi huana...@huawei.com
 
 1. To optimize the match rules for the Huawei USB storage devices. Avoid to 
 load USB storage driver for modem interface with Huawei devices.
 2. Add to support new switch command for new Huawei USB dongles.

first of all you're doing a whole lot more than these two things and
your commit log is a lot over 72 characters.

 Signed-off-by: fangxiaozhi huana...@huawei.com
 -
 diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.c 
 linux-3.7/drivers/usb/storage/initializers.c
 --- linux-3.7_bak/drivers/usb/storage/initializers.c  2012-12-11 
 09:56:11.0 +0800
 +++ linux-3.7/drivers/usb/storage/initializers.c  2012-12-12 
 16:26:53.0 +0800
 @@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_dat
   return 0;
  }
  
 -/* This places the HUAWEI E220 devices in multi-port mode */
 -int usb_stor_huawei_e220_init(struct us_data *us)
 +/* This places the HUAWEI usb dongles in multi-port mode */
 +static int usb_stor_huawei_feature_init(struct us_data *us)

renaming this function doesn't look like is part of $SUBJECT

  {
   int result;
  
 @@ -104,3 +104,60 @@ int usb_stor_huawei_e220_init(struct us_
   US_DEBUGP(Huawei mode set result is %d\n, result);
   return 0;
  }
 +
 +/*Find the supported Huawei USB dongles*/

comment style is wrong, you miss a space after /* and before */

 +static int usb_stor_huawei_dongles_pid(struct us_data *us)
 +{
 + int ret = 0;
 + struct usb_interface_descriptor *idesc = NULL;

could add a blank line here to aid readability

 + idesc = us-pusb_intf-cur_altsetting-desc;
 + if (idesc != NULL  idesc-bInterfaceNumber == 0) {
 + if ((us-pusb_dev-descriptor.idProduct = 0x1401  
 us-pusb_dev-descriptor.idProduct = 0x1600)
 + || (us-pusb_dev-descriptor.idProduct 
 = 0x1c02  us-pusb_dev-descriptor.idProduct = 0x2202)
 + || (us-pusb_dev-descriptor.idProduct 
 == 0x1001)
 + || (us-pusb_dev-descriptor.idProduct 
 == 0x1003)
 + || (us-pusb_dev-descriptor.idProduct 
 == 0x1004)) {

clearly you didn't even run checkpatch.pl here.

 + if (us-pusb_dev-descriptor.idProduct = 
 0x1501 

^

trailing

whitespace

 +  us-pusb_dev-descriptor.idProduct 
 = 0x1504) {
 + ret = 0;

ret is already initialized to zero, why do it again ?

 + } else {
 + ret = 1;
 + }
 + }
 + }
 + return ret;
 +}
 +
 +static int usb_stor_huawei_scsi_init(struct us_data *us)
 +{
 + int result = 0;
 + int act_len = 0;
 + unsigned char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x00, 
 0x00, 

 ^

 trailing

 whitespace

 +   0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
 0x00};
 + struct bulk_cb_wrap bcbw = {0};
 + bcbw.Signature = cpu_to_le32(US_BULK_CB_SIGN);
 + bcbw.Tag = 0;
 + bcbw.DataTransferLength = cpu_to_le32(0);
 + bcbw.Flags = bcbw.Lun = 0;
 + bcbw.Length = sizeof(rewind_cmd);
 + memset(bcbw.CDB, 0, sizeof(bcbw.CDB));

the entire structure is already initialized to zero, no ?

 + memcpy(bcbw.CDB, rewind_cmd, sizeof(rewind_cmd));
 +
 + result = usb_stor_bulk_transfer_buf (us, us-send_bulk_pipe, bcbw, 31, 
 act_len);
 + US_DEBUGP(usb_stor_bulk_transfer_buf performing result is %d, transfer 
 the actual length=%d\n, result, act_len);

waay over 80-characters. Run checkpatch.pl

 + return result;
 +}
 +
 +int usb_stor_huawei_init(struct us_data *us)
 +{
 + int result = 0;
 + if(usb_stor_huawei_dongles_pid(us)) {
 + if ((us-pusb_dev-descriptor.idProduct = 0x1446)) {
 + result = usb_stor_huawei_scsi_init(us);
 + } else {
 + result = usb_stor_huawei_feature_init(us);
 + }

read Documentation/CodingStyle, you'll see this is wrong.

 + }
 + return result;
 +}
 diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.h 
 linux-3.7/drivers/usb/storage/initializers.h
 ---

Re: [PATCH 1/1]linux-usb: optimize to match the Huawei USB storage devices and support new switch command

2012-12-12 Thread Alan Cox 
On Wed, 12 Dec 2012 18:20:33 +0800
fangxiaozhi 00110321 fangxiao...@huawei.com wrote:

 From: fangxiaozhi huana...@huawei.com
 
 1. To optimize the match rules for the Huawei USB storage devices. Avoid to 
 load USB storage driver for modem interface with Huawei devices.
 2. Add to support new switch command for new Huawei USB dongles.

This prevents people getting access to the storage device if they want.
It also means you need to change kernel not simply a user space file to
add support for different new identifiers.

So it seems a large step backwards to me.

Why not just teach udev the new switch command then it'll work as a udev
update on all sorts of existing kernels as well as being the kind of
small safe change you can get into the entprise distributions ?

Alan
--
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/1] usb: dwc3: Use devm_kzalloc

2012-12-12 Thread Sachin Kamat 
devm_kzalloc is device managed and makes error handling and cleanup
simpler. While at it also fixed the return value when platform_device_alloc
failed in probe function.

Cc: Anton Tikhomirov av.tikhomi...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
Compile tested on linux-next tree.
---
 drivers/usb/dwc3/dwc3-exynos.c |   13 -
 1 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index aae5328..db3bd49 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -98,10 +98,10 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
 
int ret = -ENOMEM;
 
-   exynos = kzalloc(sizeof(*exynos), GFP_KERNEL);
+   exynos = devm_kzalloc(pdev-dev, sizeof(*exynos), GFP_KERNEL);
if (!exynos) {
dev_err(pdev-dev, not enough memory\n);
-   goto err0;
+   return -ENOMEM;
}
 
/*
@@ -117,13 +117,13 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
ret = dwc3_exynos_register_phys(exynos);
if (ret) {
dev_err(pdev-dev, couldn't register PHYs\n);
-   goto err1;
+   return ret;
}
 
dwc3 = platform_device_alloc(dwc3, PLATFORM_DEVID_AUTO);
if (!dwc3) {
dev_err(pdev-dev, couldn't allocate dwc3 device\n);
-   goto err1;
+   return -ENOMEM;
}
 
clk = clk_get(pdev-dev, usbdrd30);
@@ -164,9 +164,6 @@ err4:
clk_put(clk);
 err3:
platform_device_put(dwc3);
-err1:
-   kfree(exynos);
-err0:
return ret;
 }
 
@@ -181,8 +178,6 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
clk_disable(exynos-clk);
clk_put(exynos-clk);
 
-   kfree(exynos);
-
return 0;
 }
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] usb: dwc3: Use devm_kzalloc

2012-12-12 Thread Felipe Balbi 
On Wed, Dec 12, 2012 at 04:13:15PM +0530, Sachin Kamat wrote:
 devm_kzalloc is device managed and makes error handling and cleanup
 simpler. While at it also fixed the return value when platform_device_alloc
 failed in probe function.
 
 Cc: Anton Tikhomirov av.tikhomi...@samsung.com
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org

what's wrong with http://www.spinics.net/lists/linux-usb/msg74326.html ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/1] usb: dwc3: Use devm_kzalloc

2012-12-12 Thread Sachin Kamat 
On 12 December 2012 16:51, Felipe Balbi ba...@ti.com wrote:
 On Wed, Dec 12, 2012 at 04:13:15PM +0530, Sachin Kamat wrote:
 devm_kzalloc is device managed and makes error handling and cleanup
 simpler. While at it also fixed the return value when platform_device_alloc
 failed in probe function.

 Cc: Anton Tikhomirov av.tikhomi...@samsung.com
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org

 what's wrong with http://www.spinics.net/lists/linux-usb/msg74326.html ?

Looks good to me though the creation of '*dev' was not really necessary.
I had not looked at the above patch. Please ignore mine.


 --
 balbi



-- 
With warm regards,
Sachin
--
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: dwc3: Use devm_kzalloc

2012-12-12 Thread Felipe Balbi 
Hi,

On Wed, Dec 12, 2012 at 05:08:09PM +0530, Sachin Kamat wrote:
 On 12 December 2012 16:51, Felipe Balbi ba...@ti.com wrote:
  On Wed, Dec 12, 2012 at 04:13:15PM +0530, Sachin Kamat wrote:
  devm_kzalloc is device managed and makes error handling and cleanup
  simpler. While at it also fixed the return value when platform_device_alloc
  failed in probe function.
 
  Cc: Anton Tikhomirov av.tikhomi...@samsung.com
  Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 
  what's wrong with http://www.spinics.net/lists/linux-usb/msg74326.html ?
 
 Looks good to me though the creation of '*dev' was not really necessary.
 I had not looked at the above patch. Please ignore mine.

yeah, it's definitely not necessary and GCC will optimize it anyway ;-)

cheers

-- 
balbi


signature.asc
Description: Digital signature

issue with uvcvideo and xhci

2012-12-12 Thread Javier Martinez Canillas 
Hello,

We have an issue when trying to use USB cameras on a particular machine using
the latest mainline Linux 3.7 kernel. This is not a regression since the same
issue is present with older kernels (i.e: 3.5).

The cameras work fine when plugged to an USB2.0 port (using the EHCI HCD host
controller driver) but they don't when using the USB3.0 port (using the xHCI
HCD host controller driver).

The machine's USB3.0 host controller is a NEC Corporation uPD720200 USB 3.0 Host
Controller (rev 04).

When enabling trace on the uvcvideo driver I see that most frames are lost:

Dec 12 11:07:58 thinclient kernel: [ 4965.597637] uvcvideo: USB isochronous
frame lost (-18).
Dec 12 11:07:58 thinclient kernel: [ 4965.597642] uvcvideo: USB isochronous
frame lost (-18).
Dec 12 11:07:58 thinclient kernel: [ 4965.597647] uvcvideo: Marking buffer as
bad (error bit set).
Dec 12 11:07:58 thinclient kernel: [ 4965.597651] uvcvideo: Frame complete (EOF
found).
Dec 12 11:07:58 thinclient kernel: [ 4965.597655] uvcvideo: EOF in empty 
payload.
Dec 12 11:07:58 thinclient kernel: [ 4965.597661] uvcvideo: Dropping payload
(out of sync).
Dec 12 11:07:58 thinclient kernel: [ 4965.813294] uvcvideo: frame 486 stats:
0/2/8 packets, 0/0/8 pts

The uvcvideo checks if urb-iso_frame_desc[i].status  0 on the
uvc_video_decode_isoc() function (drivers/media/usb/uvc/uvc_video.c).

I checked on the xhci driver and the only place where this error code (-EXDEV)
is assigned to frame-status is inside the skip_isoc_td() function
(drivers/usb/host/xhci-ring.c).

At this point I'm not sure if this is a bug on the xhci driver, another quirk
needed by the XHCI_NEC_HOST, a camera misconfiguration on the USB Video Class
driver or a firmware/hardware bug.

The cameras are reported to work on the same machine but using another operating
system (Windows).

I was wondering if you can give me some pointers on how to be sure what's the
issue or if this rings any bells to you.

I've enabled both CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING in case you
need more debugging information.

Thanks a lot and best regards,
Javier
--
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: Tegra3 ehci_suspend and ehci_resume

2012-12-12 Thread Alan Stern 
On Wed, 12 Dec 2012, Timur wrote:

 - Unplugging and re-plugging the slave device works well.
 - Unplugging the Y-cable (disconnecting slave and external power at the 
 same time) then re-plugging the Y-cable works well.
 - Disconnecting external power to both devices, then waiting for the 
 host screen to go off and waiting for up to 20 seconds longer (staying 
 in light sleep) does also work well. Please note: slave device was 
 completely off power for roughly 20 seconds and is not causing any issues.
 
 The problem only occurs, when I pull external power, wait for the host 
 screen to go off, then wait another 60s or 10 minutes, this way making 
 sure the host will indeed transition into deep sleep. Plugging external 
 power then will wake both devices, but the host can no longer talk to 
 the slave.

What happens if you: pull external power, wait for the host screen to
go off, then wait another 60s or 10 minutes, then plug external power
back to both devices (but leave the USB connection between the host and 
slave unplugged), then wait 10 seconds, then plug in the USB 
connection?

 Is this not strong evidence the problem is with the host?

Yes, it is.  Can you force the host to go into deep sleep while the 
external power remains connected?

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: Tons of issues with xhci

2012-12-12 Thread Alan Stern 
On Tue, 11 Dec 2012, Sarah Sharp wrote:

 Hi Alan,
 
 I'm finally revisiting the issue with active transfers when a device
 disconnects.  I'm trying to refresh my memory of the issue.
 
 On Thu, Oct 18, 2012 at 03:54:06PM -0400, Alan Stern wrote:
  Unfortunately the trace isn't termendously helpful.  It shows a bunch
  of reads with a few writes sprinkled among them.  Then for no apparent
  reason, in the middle of a read the device was disconnected.
  
  Oddly, the bulk-IN URB that was in progress when the disconnect
  occurred did not complete immediately with an error.  Instead it timed
  out after 30 seconds and was cancelled.  Sarah, I thought you had fixed
  that?
 
 I don't remember what the fix for this was supposed to be.  I currently
 assume that when a USB device is logically disconnected by the USB core,
 either the driver's disconnect function is called and it should cancel
 all outstanding URBs, or the core goes and cancels all active URBs that
 are in the host queue.  Basically, I assume it's the USB core's job to
 flush out any URBs before destroying the xHCI endpoint rings when the
 struct usb_device is deallocated.  ISTR that this assumption was wrong,
 but I don't remember why.

No, your memory has gotten things mixed up.  The problem is not a 
logical disconnect.

The problem is a physical disconnect.  IIRC, the trace showed that the
root hub's Get-Port-Status reply had the connect status bit clear and
connect-change status bit set.  Nevertheless, the URB that was in
progress did not complete immediately with an error.

If the device is truly disconnected then it cannot send any packets.  
In particular, it can't send handshaking packets (or the USB-3
equivalent).  In the absence of these packets, the host hardware is
supposed to apply the 3-strikes rule and abort the transfer.  But
this didn't happen.  _That_ was the problem.

 I vaguely recall that the fix was for the xHCI driver to not accept URBs
 when it knows a particular device is disconnected.  Is that correct?

No, not even close.

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

EZUSB build failures (was Re: [opensuse-kernel] [PATCH] Fix armv7 kernel-default config)

2012-12-12 Thread Jeff Mahoney 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/12/12 10:07 AM, Greg KH wrote:
 On Wed, Dec 12, 2012 at 11:39:33AM +0100, Guillaume Gardet wrote:
 Hi,
 
 please find in attachment a patch to fix armv7 kernel-default
 config.
 
 CONFIG_USB_EZUSB_FX2 must be a module instead of built-in to fix
 build
 
 What build problem?  This should be resolved properly upstream if
 it is still an issue.  I thought I fixed it a while ago, if not,
 please let me know upstream.

Hi Greg -

Here's what I'm seeing on x86_64 w/ 3.7-final:
ERROR: ezusb_fx1_ihex_firmware_download
[drivers/usb/serial/whiteheat.ko] undefined!
ERROR: ezusb_fx1_ihex_firmware_download
[drivers/usb/serial/keyspan_pda.ko] undefined!
ERROR: ezusb_fx1_set_reset [drivers/usb/serial/keyspan_pda.ko]
undefined!
ERROR: ezusb_fx1_ihex_firmware_download
[drivers/usb/serial/keyspan.ko] undefined!

Somehow the exported symbols aren't being made available to modules
when ezusb is a built-in.

- -Jeff

- -- 
Jeff Mahoney
SUSE Labs
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQyKnYAAoJEB57S2MheeWySdsP/1VaTne96twW+CS1yh4+OT6t
apQ33kWrnI9a+4rx8Vzu5FVXgbYFhddgq1MxiqCaUfTC4L4PhIyRW9VGGnV78iSP
wYdJvKCrH852oCW8w5Aex2W1ZkDPFx+1NJQOdLymTkxC6pAbC3tyoy6Cq7otXvnw
lAL4o6oaf5x4UmCQ1Oxm26Cn8+JD90URkMUg+WWGb9sBCmjqu6scDyIt+TXvc+HQ
IP9x5Sc8tMCwkFl9u053Vd2dt5fB/tk6qOjRKNvVS1tgClZfBtoxrFsk+791Au51
uMIOCS3Ey5EEIRZcTdzNPimrkQq4R3JQsL0X6N6dyfS8oxF1QVsi4beoQDtxIkX1
V3tIN/DqIls14GdagS1Wgn9I/KzHOSXtrJV37727PK6ukpLWA3lENkgvkrJePg1a
8ACNtlREQX33RQAKF3v3EPyDFmoFrjF/yRH/WT1aCjdzy2Nm+Cg3AxiEFCu126es
K5Xif3LlNUcWoUM9aQ38nE6kCxI0GXTrb/ZTmrDv+bKh3yEibxijpw0mpzxCHKpI
amFN6W2tt2C95rXWUG+G3w9+vqZ9RQ/+93bSXcgzp4CkI2SFpKQFiBp9PNs+dRtG
nIozZofDVWyA4uEjec1TC04h8vKi4z5VP0HiH8CqkeGfI684Ev8Od5WsRNtO46FY
uUvxm9/+YverGG2AChq+
=O27f
-END PGP SIGNATURE-
--
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 Gadget driver: Add support for CD-ROM booting

2012-12-12 Thread Alan Stern 
On Wed, 12 Dec 2012, Golmer Palmer wrote:

 Alan Stern stern@... writes:
 
  
  On Mon, 10 Dec 2012, Golmer Palmer wrote:
  
   Alan Stern stern@... writes:
   

Right.  This limit represents a hypothetical 256-minute CD.
   
   256 minutes CD, ok! (75 represents 75 sectors/sec)
  
  Yes.
 
 So 255M:60S:75F

Well, actually 255M:59S:74F.  But yes, you got the idea.

   Yes, not a DVD. But if you mount a DVD image with the cdrom emulation, 
   it 
   works! So, please, update the limit to 950*60*75 (4,275,000 sectors). 
   This 
 is an 
   hypothetical 950 minutes CD-ROM, with a size bigger than a DVD-9 DATA 
 disk.
  
  I can't.  The CD spec requires that under certain conditions, block 
  addresses on the device be presented in MSF format, where M is 
  minutes, S is seconds, and F is frames, and each occupies a single 
  byte.  There's no way to represent more than 255 minutes.
 
 Ok, now I know why this limit!
 
 I feel that in the future a CD/DVD/BD USB gadget driver can be interesting.

We are always willing to accept patches to add new features.

 I'll post my tests over the patches for cdrom booting when I can apply them 
 to 
 my Android device.

Good.

 Thank you Alan!

You're welcome.

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: Linux USB file storage gadget with new UDC

2012-12-12 Thread Alan Stern 
On Wed, 12 Dec 2012, Bjørn Mork wrote:

 Alan Stern st...@rowland.harvard.edu writes:
 
  If you read the confidentiality notice, you'll see that it merely says 
  that the contents of the email _may_ be confidential.  Also, it warns 
  people who _aren't_ the intended addressees -- but if the message was 
  sent to a public email list then obviously there are no such people.
 
  So I don't see any problem.
 
 Then I guess you missed this unconditional part?:
 
  be aware that any disclosure, copying, distribution or use of this
   e-mail or any attachment is prohibited. 
 
 This means that victor is deliberately violating his company policy by
 continuing to send emails to a public list, which is the direct action
 causing disclosure, copying and distribution of the e-mail.  You can of
 course not blame list admins or subscribers here.
 
 I still do not see how a patch with such restrictions can be useful to
 anyone. But I am not the one to decide that...

This is wrong, partly because you are quoting out of context and partly
because of a grammatical error in the original notice.  Here's the text
with the context retained:

If you are not the intended addressee (or authorized to receive
for the addressee). be aware that any disclosure, copying,
distribution or use of this e-mail or any attachment is
prohibited.

It is clear, from the lack of capitalization of the word be and the 
fact that the preceding text is only a sentence fragment, that the 
period following the close-parenthesis was meant to be a comma.  
Therefore this prohibition applies only to people who are not meant to 
be reading an open mailing list -- and there are no such people.

This means that victor did not violate any policies.

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 08/10] usb: add usb port auto power off mechanism

2012-12-12 Thread Alan Stern 
On Wed, 12 Dec 2012, Alan Stern wrote:

 You should test the connect status in a loop.  Each time through the 
 loop, if it's not connected wait another 20 or so.

Typo; I meant wait another 20 ms or 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: EZUSB build failures (was Re: [opensuse-kernel] [PATCH] Fix armv7 kernel-default config)

2012-12-12 Thread Greg Kroah-Hartman 
On Wed, Dec 12, 2012 at 10:59:21AM -0500, Jeff Mahoney wrote:
 On 12/12/12 10:07 AM, Greg KH wrote:
  On Wed, Dec 12, 2012 at 11:39:33AM +0100, Guillaume Gardet wrote:
  Hi,
  
  please find in attachment a patch to fix armv7 kernel-default
  config.
  
  CONFIG_USB_EZUSB_FX2 must be a module instead of built-in to fix
  build
  
  What build problem?  This should be resolved properly upstream if
  it is still an issue.  I thought I fixed it a while ago, if not,
  please let me know upstream.
 
 Hi Greg -
 
 Here's what I'm seeing on x86_64 w/ 3.7-final:
 ERROR: ezusb_fx1_ihex_firmware_download
 [drivers/usb/serial/whiteheat.ko] undefined!
 ERROR: ezusb_fx1_ihex_firmware_download
 [drivers/usb/serial/keyspan_pda.ko] undefined!
 ERROR: ezusb_fx1_set_reset [drivers/usb/serial/keyspan_pda.ko]
 undefined!
 ERROR: ezusb_fx1_ihex_firmware_download
 [drivers/usb/serial/keyspan.ko] undefined!
 
 Somehow the exported symbols aren't being made available to modules
 when ezusb is a built-in.

Is USB being built as a module?  If so, can you add commit
9db72fe6c943852032d9ed863c87e8c02d3cb9da in Linus's kernel tree to your
kernel and see if that fixes the issue?  It's being queued up right now
for the 3.7.1 release and should solve this.

If not, it would be great to know.

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: EZUSB build failures (was Re: [opensuse-kernel] [PATCH] Fix armv7 kernel-default config)

2012-12-12 Thread Jeff Mahoney 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/12/12 10:59 AM, Jeff Mahoney wrote:
 On 12/12/12 10:07 AM, Greg KH wrote:
 On Wed, Dec 12, 2012 at 11:39:33AM +0100, Guillaume Gardet
 wrote:
 Hi,
 
 please find in attachment a patch to fix armv7 kernel-default 
 config.
 
 CONFIG_USB_EZUSB_FX2 must be a module instead of built-in to
 fix build
 
 What build problem?  This should be resolved properly upstream
 if it is still an issue.  I thought I fixed it a while ago, if
 not, please let me know upstream.
 
 Hi Greg -
 
 Here's what I'm seeing on x86_64 w/ 3.7-final: ERROR:
 ezusb_fx1_ihex_firmware_download 
 [drivers/usb/serial/whiteheat.ko] undefined! ERROR:
 ezusb_fx1_ihex_firmware_download 
 [drivers/usb/serial/keyspan_pda.ko] undefined! ERROR:
 ezusb_fx1_set_reset [drivers/usb/serial/keyspan_pda.ko] 
 undefined! ERROR: ezusb_fx1_ihex_firmware_download 
 [drivers/usb/serial/keyspan.ko] undefined!
 
 Somehow the exported symbols aren't being made available to
 modules when ezusb is a built-in.

$ nm drivers/usb/built-in.o|grep ezusb_fx1_ihex_firmware_download

$ nm drivers/usb/misc/built-in.o |grep ezusb_fx1_ihex_firmware_download
d9b16284 A __crc_ezusb_fx1_ihex_firmware_download
 r __kcrctab_ezusb_fx1_ihex_firmware_download
0021 r __kstrtab_ezusb_fx1_ihex_firmware_download
 r __ksymtab_ezusb_fx1_ihex_firmware_download
04d0 T ezusb_fx1_ihex_firmware_download

That'd do it.

Digging a little deeper, it looks like it's because
CONFIG_USB_EZUSB_FX2=y is allowed to be a built-in while CONFIG_USB=m.
drivers/usb/misc gets built with whatever CONFIG_USB is, so it's
treated by drivers/usb as a module and drivers/usb/misc/built-in.o
gets ignored.

I'll post a fix in a minute.

- -Jeff

- -- 
Jeff Mahoney
SUSE Labs
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQyKziAAoJEB57S2MheeWya6kP/iJ3Ju+tT3qN9PVzRRRF4Nlh
ztFreKxnZi+XAIPgmEUwnFU6IOGVndRP6Q/j474azPUKNzO6B27eflOLWP9t2yqj
Fw0XGCZa1ymTHxUYmvpckwUg1a1iHBnC305GpMs9udWTxYI1xAZIhH3LTowdRNEd
he2gH5eq8jb2CNhK5gkN0meRiRRBpo/UeU251HifnEjkchIE5rZZgMxQc0YJkk9w
x5JSYKLwfWI1uJfh1yco9DwUsp7BnJEXMdONfbWNDnYsKHN5HQlc+9FxNNUOXUvT
sbbxH10ke6jS1AsSGJL3OQPtSbectwp1l/OO5iPbgrqI7sBGYlpi6ho30d1Djgoi
ZfjT/bV6cQ3p2Kz2EydGRBnkEH8WrorVVhzU+QXYNmM8+cHFqmn7i3HCxlgFT2Ya
rPu/+0o/hWTswJcJORIpuUFLWmo9CaFkJMikUZV5WoWvoP7YK8WxUrF+P6PfW7u2
YoYQkyHU3s8Kw0Ic/YLtMBCepUsWnnn+RmBP08CFw4KgYtQzRpu/nXQhlaWe/8OO
994pcs8m/qg9/V6huk5BLWmK8HRnOBDKcG2pPZd5g6Z7idhTpkd2WQcgY85ymeS5
nZ7D+5mqswspsE+9xVLMVwvkWYeZ+Vhs7ire2UUd0rF7bwpewUM5lccpNW5eZi8a
WM0eG6Wve0ygCJ11g2uw
=Jeaz
-END PGP SIGNATURE-
--
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: Linux USB file storage gadget with new UDC

2012-12-12 Thread Alan Stern 
On Wed, 12 Dec 2012, Alan Stern wrote:

 On Wed, 12 Dec 2012, Bjørn Mork wrote:
 
  Alan Stern st...@rowland.harvard.edu writes:
  
   If you read the confidentiality notice, you'll see that it merely says 
   that the contents of the email _may_ be confidential.  Also, it warns 
   people who _aren't_ the intended addressees -- but if the message was 
   sent to a public email list then obviously there are no such people.
  
   So I don't see any problem.
  
  Then I guess you missed this unconditional part?:
  
   be aware that any disclosure, copying, distribution or use of this
e-mail or any attachment is prohibited. 
  
  This means that victor is deliberately violating his company policy by
  continuing to send emails to a public list, which is the direct action
  causing disclosure, copying and distribution of the e-mail.  You can of
  course not blame list admins or subscribers here.
  
  I still do not see how a patch with such restrictions can be useful to
  anyone. But I am not the one to decide that...
 
 This is wrong, partly because you are quoting out of context and partly
 because of a grammatical error in the original notice.  Here's the text
 with the context retained:
 
   If you are not the intended addressee (or authorized to receive
   for the addressee). be aware that any disclosure, copying,
   distribution or use of this e-mail or any attachment is
   prohibited.
 
 It is clear, from the lack of capitalization of the word be and the 
 fact that the preceding text is only a sentence fragment, that the 
 period following the close-parenthesis was meant to be a comma.  
 Therefore this prohibition applies only to people who are not meant to 
 be reading an open mailing list -- and there are no such people.
 
 This means that victor did not violate any policies.

One more thing.  If you interpret literally just the part of the 
sentence that you quoted above, it becomes nonsense.  ... any ... use 
of this e-mail or any attachment is prohibited would mean that the 
intended recipient was not allowed to read the message!

It's like the old joke about the warnings that used to be placed above 
Super Top-Secret messages: Burn Before Reading.  :-)

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: EZUSB build failures (was Re: [opensuse-kernel] [PATCH] Fix armv7 kernel-default config)

2012-12-12 Thread Jeff Mahoney 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/12/12 11:10 AM, Greg Kroah-Hartman wrote:
 On Wed, Dec 12, 2012 at 10:59:21AM -0500, Jeff Mahoney wrote:
 On 12/12/12 10:07 AM, Greg KH wrote:
 On Wed, Dec 12, 2012 at 11:39:33AM +0100, Guillaume Gardet
 wrote:
 Hi,
 
 please find in attachment a patch to fix armv7
 kernel-default config.
 
 CONFIG_USB_EZUSB_FX2 must be a module instead of built-in to
 fix build
 
 What build problem?  This should be resolved properly upstream
 if it is still an issue.  I thought I fixed it a while ago, if
 not, please let me know upstream.
 
 Hi Greg -
 
 Here's what I'm seeing on x86_64 w/ 3.7-final: ERROR:
 ezusb_fx1_ihex_firmware_download 
 [drivers/usb/serial/whiteheat.ko] undefined! ERROR:
 ezusb_fx1_ihex_firmware_download 
 [drivers/usb/serial/keyspan_pda.ko] undefined! ERROR:
 ezusb_fx1_set_reset [drivers/usb/serial/keyspan_pda.ko] 
 undefined! ERROR: ezusb_fx1_ihex_firmware_download 
 [drivers/usb/serial/keyspan.ko] undefined!
 
 Somehow the exported symbols aren't being made available to
 modules when ezusb is a built-in.
 
 Is USB being built as a module?  If so, can you add commit 
 9db72fe6c943852032d9ed863c87e8c02d3cb9da in Linus's kernel tree to
 your kernel and see if that fixes the issue?  It's being queued up
 right now for the 3.7.1 release and should solve this.
 
 If not, it would be great to know.

Ah. Perfect. That's the patch I came up with as well. It does fix it.

- -Jeff

- -- 
Jeff Mahoney
SUSE Labs
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQyK4PAAoJEB57S2MheeWy5MsQAKRINa8byzjXdbUbkQzWRg6G
wVftvlm3sIs7EROfKhZxYsjgWc8NKUxdooQvDwYMiBQ3YLclQKsixBiLQvJP4/gw
teohyJXvYBkqUQ8Hx9NwLle9Fz9qHr4O+F/oLOPA0Z09SsRqZ+W2/xpX6sPxbkpn
XgQfDg3jq2UfoNYxf18uB/e7FU2F6x1WMEnm4cpzYDDHrgn8dIhho3fFsA0z5r7U
TFVOxiodr9QSPMTYL8SvmCtmFdKUsmWlzfUK4b4TH53eO3wxfQhLAFBXNLJ+T+jL
IWjXPGbZHuN9N2cMZOM/skC6mK77ZH/opNb/ynU+CCEJoiKpibXmOXV9Q+E5r23D
i4yN09Mq85GwD9/uuQf2URUOafq28GnaucVahz/U0vUoEDqnkmWzH/Uapr5xetrL
TJ32RVTHHUpvFgZFCvZ53F3cB/L5fQMbwP9ZRq1ZoHKFIFfetv+sz/4zWC2jg1TF
4DKzAKnBiEKzH1t+ci5wByMwEBifS4Zi3D4ZntJ+DPS5erm4Wwv7DxSIx+2rZX7D
3eGvEoLMCRzz5DdkxnrNSyFMH/caSxcc4Jqzcekt7nF31xLKc0A9kMi792+mqNMx
oOJEDAY5mZhhkTo38nuqCe99vo08d5xTjHaOOGbriJE7wfQsxbn/0gt16K5vnclr
yxowhreBqgZ/hGoj/a6g
=lsQv
-END PGP SIGNATURE-
--
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: Tegra3 ehci_suspend and ehci_resume

2012-12-12 Thread Timur 

On 12.12.2012 16:20, Alan Stern wrote:

On Wed, 12 Dec 2012, Timur wrote:


- Unplugging and re-plugging the slave device works well.
- Unplugging the Y-cable (disconnecting slave and external power at the
same time) then re-plugging the Y-cable works well.
- Disconnecting external power to both devices, then waiting for the
host screen to go off and waiting for up to 20 seconds longer (staying
in light sleep) does also work well. Please note: slave device was
completely off power for roughly 20 seconds and is not causing any issues.

The problem only occurs, when I pull external power, wait for the host
screen to go off, then wait another 60s or 10 minutes, this way making
sure the host will indeed transition into deep sleep. Plugging external
power then will wake both devices, but the host can no longer talk to
the slave.


What happens if you: pull external power, wait for the host screen to
go off, then wait another 60s or 10 minutes, then plug external power
back to both devices (but leave the USB connection between the host and
slave unplugged), then wait 10 seconds, then plug in the USB
connection?


Nexus 7 and USB slave get their power via USB cable. This makes it a 
little difficult to connect power, but leave the USB connection 
unplugged. I'm not sure how to proceed with this.


This is the USB Y-adapter I am using: 
https://sites.google.com/site/sonicboomworld/_/rsrc/1345753009582/my-projects/otg-diagrams/Y_OTG_CABLE.png


A photo of all components (USB cables excluded): 
http://mehrvarz.github.com/img/n7-otg-power.png



Is this not strong evidence the problem is with the host?


Yes, it is.  Can you force the host to go into deep sleep while the
external power remains connected?

Alan Stern


I investigated this. Unfortunately, the answer seems to be no. I cannot 
convince the Nexus 7 to move into deep sleep mode (LP0), when a powered 
USB cable is connected to it (despite WiFi, Bt, ADB, etc. being off).


A new finding: when the N7 is coming out of deep sleep (in the 
problematic scenario), I see that method hub_port_reset() is being 
called. It seems to succeed. Because the following shows up in the log: 
usb 2-1: new full speed USB device number 3 using tegra-ehci. However, 
this is then followed by hub_set_address() failing and tegra-ehci 
tegra-ehci.0: detected XactErr len 0/8 retry x and device not 
accepting address 3, error -71 being logged.


I ran this modified test: while the N7 was in deep sleep, I unplugged 
(stole) the USB slave. Then I plugged external power and this time 
hub_port_reset() did not succeed and no entry usb 2-1: new full speed 
USB device number 3 using tegra-ehci was logged. I think this shows 
that, after LP0, a connected USB slave device _is_ still detectable. The 
problem strikes a moment later, when the host tries to set the address.


Can I try anything in code, to reset the slave, so it will accept an 
address?


Timur

--
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: issue with uvcvideo and xhci

2012-12-12 Thread Sarah Sharp 
On Wed, Dec 12, 2012 at 12:47:24PM +0100, Javier Martinez Canillas wrote:
 Hello,
 
 We have an issue when trying to use USB cameras on a particular machine using
 the latest mainline Linux 3.7 kernel. This is not a regression since the same
 issue is present with older kernels (i.e: 3.5).
 
 The cameras work fine when plugged to an USB2.0 port (using the EHCI HCD host
 controller driver) but they don't when using the USB3.0 port (using the xHCI
 HCD host controller driver).
 
 The machine's USB3.0 host controller is a NEC Corporation uPD720200 USB 3.0 
 Host
 Controller (rev 04).
 
 When enabling trace on the uvcvideo driver I see that most frames are lost:
 
 Dec 12 11:07:58 thinclient kernel: [ 4965.597637] uvcvideo: USB isochronous
 frame lost (-18).
 Dec 12 11:07:58 thinclient kernel: [ 4965.597642] uvcvideo: USB isochronous
 frame lost (-18).
 Dec 12 11:07:58 thinclient kernel: [ 4965.597647] uvcvideo: Marking buffer as
 bad (error bit set).
 Dec 12 11:07:58 thinclient kernel: [ 4965.597651] uvcvideo: Frame complete 
 (EOF
 found).
 Dec 12 11:07:58 thinclient kernel: [ 4965.597655] uvcvideo: EOF in empty 
 payload.
 Dec 12 11:07:58 thinclient kernel: [ 4965.597661] uvcvideo: Dropping payload
 (out of sync).
 Dec 12 11:07:58 thinclient kernel: [ 4965.813294] uvcvideo: frame 486 stats:
 0/2/8 packets, 0/0/8 pts
 
 The uvcvideo checks if urb-iso_frame_desc[i].status  0 on the
 uvc_video_decode_isoc() function (drivers/media/usb/uvc/uvc_video.c).
 
 I checked on the xhci driver and the only place where this error code (-EXDEV)
 is assigned to frame-status is inside the skip_isoc_td() function
 (drivers/usb/host/xhci-ring.c).
 
 At this point I'm not sure if this is a bug on the xhci driver, another quirk
 needed by the XHCI_NEC_HOST, a camera misconfiguration on the USB Video Class
 driver or a firmware/hardware bug.

It's a known performance issue, although it's not clear whether it's on
the xHCI driver side or the host controller side.  When an interface
setting is enabled where the isochronous endpoint requires two
additional transfers per service interval, the NEC host controller
starts reporting many missed service intervals.  The xHCI driver then
finds all the frame buffers that were skipped and marks them with the
-EXDEV status.

An error status of Missed Service Interval means the host controller
could not access the transfer memory fast enough through the PCI bus to
service the endpoint in time.  It could be a host hardware issue, or it
could be software slowing down the system to a crawl.  I lean towards a
software issue since, as you said, the Windows driver works fine.
(Although who knows what NEC quirks the Windows driver is working
around...)

The NEC xHCI host controller is a 0.96 revision, which doesn't support
the Block Event Interrupt (BEI) flag which cuts down on the number of
interrupts per URB submitted.  So the xHCI driver's interrupt routine
gets called on every single service interval, rather than being called
once per URB.

Since the Linux xHCI driver isn't really optimized for performance yet,
the interrupt handler is probably pretty slow and could cause delays in
submitting future URBs.  The high amount of interrupts is probably
causing other systems to be starved, possibly leading to the xHCI host
controller not being able to access memory fast enough to service the
endpoint.

 The cameras are reported to work on the same machine but using another 
 operating
 system (Windows).

Windows probably uses Event Data TRBs to cut the interrupts down to one
per URB.  It would take a major effort to make the xHCI driver use Event
Data TRBs.

 I was wondering if you can give me some pointers on how to be sure what's the
 issue or if this rings any bells to you.

I don't have time to work on performance issues right now, as I have
several other critical bugs (mostly around failed S3/S4).  However, if
you want to try to fix this issue yourself, I suggest you run perf and
see where the bottle necks in the xHCI interrupt handler are.

I suspect that part of it is that the interrupt handler reads the xHCI
status register.  That PCI register read is pretty costly, and it's not
necessary since 99% of the time the host controller is going to report
an OK status.  And there's no guarantee that when the host does have an
error that it will set a bad status.

But without an analysis by perf, we won't really know where the
bottlenecks are.

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: Tegra3 ehci_suspend and ehci_resume

2012-12-12 Thread Alan Stern 
On Wed, 12 Dec 2012, Timur wrote:

 Nexus 7 and USB slave get their power via USB cable. This makes it a 
 little difficult to connect power, but leave the USB connection 
 unplugged. I'm not sure how to proceed with this.
 
 This is the USB Y-adapter I am using: 
 https://sites.google.com/site/sonicboomworld/_/rsrc/1345753009582/my-projects/otg-diagrams/Y_OTG_CABLE.png
 
 A photo of all components (USB cables excluded): 
 http://mehrvarz.github.com/img/n7-otg-power.png

Ah, now I understand.

  Is this not strong evidence the problem is with the host?
 
  Yes, it is.  Can you force the host to go into deep sleep while the
  external power remains connected?
 
  Alan Stern
 
 I investigated this. Unfortunately, the answer seems to be no. I cannot 
 convince the Nexus 7 to move into deep sleep mode (LP0), when a powered 
 USB cable is connected to it (despite WiFi, Bt, ADB, etc. being off).

Okay.  Then how about this: Unplug both the power connector and the
slave connector.  After the N7 goes into deep sleep, plug the power
connector back in but leave the slave unplugged.  Then a few seconds
later, plug in the slave.

Also try doing the same thing, but don't wait for the N7 to go into
deep sleep.  If this works but the other test doesn't, then clearly the 
slave is working correctly and the problem lies in the host controller.

 A new finding: when the N7 is coming out of deep sleep (in the 
 problematic scenario), I see that method hub_port_reset() is being 
 called. It seems to succeed. Because the following shows up in the log: 
 usb 2-1: new full speed USB device number 3 using tegra-ehci. However, 
 this is then followed by hub_set_address() failing and tegra-ehci 
 tegra-ehci.0: detected XactErr len 0/8 retry x and device not 
 accepting address 3, error -71 being logged.
 
 I ran this modified test: while the N7 was in deep sleep, I unplugged 
 (stole) the USB slave. Then I plugged external power and this time 
 hub_port_reset() did not succeed and no entry usb 2-1: new full speed 
 USB device number 3 using tegra-ehci was logged. I think this shows 
 that, after LP0, a connected USB slave device _is_ still detectable. The 
 problem strikes a moment later, when the host tries to set the address.
 
 Can I try anything in code, to reset the slave, so it will accept an 
 address?

The hub driver already does this, in hub_port_reset().

It wouldn't be surprising if the deep-sleep code in the ehci-tegra
driver has some bugs.  I don't know how much it has been tested.

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: Need help for hardware bug in Intel's EHCI implementation

2012-12-12 Thread Alan Stern 
On Mon, 10 Dec 2012, Sarah Sharp wrote:

   Ok.  The hardware devs are asking if this problem is hit on newer
   hardware.  They think that most of the kinks in the EHCI host should
   have been worked out by the Nehalem generation.  Do you have access to a
   newer EHCI system?  If not, I will attempt to find the ez-usb device I
   have and learn how to program it.
  
  I do have hardware that's newer than ICH5 -- as best I recall, it's
  ICH9.  How does that compare with Nehalem?  I never figured out the
  relation between Intel's code names and part names.  There seem to be
  at least three different ways of describing each piece of hardware.
 
 Yep.  Even at Intel we get confused.
 
 Nehalem seems to be a particular CPU from 2008.  ICH9 came out in 2007.
 So I guess your hardware is a year older than what the devs are looking
 for.  I would suggest you test on the newer box anyway.

I just finished the test.  The ICH9 system exhibits the same sort of 
bug.

For reference, the test involves applying the patch below (which is
based on the 3.7 kernel).  Plug in a high-speed g-zero gadget and run

testusb -D /dev/bus/usb/BBB/DDD -t 24

(fill in the BBB and DDD values appropriately).  If the patch's
Writeback after IAA debugging messages appear then the bug is
present.

Alan Stern




Index: usb-3.7/drivers/usb/host/ehci-q.c
===
--- usb-3.7.orig/drivers/usb/host/ehci-q.c
+++ usb-3.7/drivers/usb/host/ehci-q.c
@@ -128,6 +128,19 @@ qh_refresh (struct ehci_hcd *ehci, struc
else {
qtd = list_entry (qh-qtd_list.next,
struct ehci_qtd, qtd_list);
+
+   if (qh-old_qtd  (qh-old_ovtok != qh-hw-hw_token ||
+   qh-old_tdtok != qh-new_tdtok ||
+   (qtd == qh-old_qtd 
+   qh-old_tdtok != qtd-hw_token)))
+   ehci_dbg(ehci, Writeback after IAA: qtd %p %p %c qtd 
token %x %x qh token %x %x\n,
+   qh-old_qtd, qtd,
+   qh-old_qtd == qtd ? ' ' : '*',
+   hc32_to_cpu(ehci, qh-old_tdtok),
+   hc32_to_cpu(ehci, qtd == qh-old_qtd ? 
qtd-hw_token : qh-new_tdtok),
+   hc32_to_cpu(ehci, qh-old_ovtok),
+   hc32_to_cpu(ehci, qh-hw-hw_token));
+
/*
 * first qtd may already be partially processed.
 * If we come here during unlink, the QH overlay region
@@ -141,6 +154,7 @@ qh_refresh (struct ehci_hcd *ehci, struc
}
}
 
+   qh-old_qtd = NULL;
if (qtd)
qh_update (ehci, qh, qtd);
 }
@@ -372,6 +386,8 @@ qh_completions (struct ehci_hcd *ehci, s
/* hardware copies qtd out of qh overlay */
rmb ();
token = hc32_to_cpu(ehci, qtd-hw_token);
+   if (qtd == qh-old_qtd)
+   qh-new_tdtok = qtd-hw_token;
 
/* always clean up qtds the hc de-activated */
  retry_xacterr:
@@ -552,9 +568,6 @@ qh_completions (struct ehci_hcd *ehci, s
 */
if (stopped != 0 || hw-hw_qtd_next == EHCI_LIST_END(ehci)) {
switch (state) {
-   case QH_STATE_IDLE:
-   qh_refresh(ehci, qh);
-   break;
case QH_STATE_LINKED:
/* We won't refresh a QH that's linked (after the HC
 * stopped the queue).  That avoids a race:
@@ -962,7 +975,6 @@ done:
hw-hw_info2 = cpu_to_hc32(ehci, info2);
qh-is_out = !is_input;
usb_settoggle (urb-dev, usb_pipeendpoint (urb-pipe), !is_input, 1);
-   qh_refresh (ehci, qh);
return qh;
 }
 
@@ -1226,6 +1238,22 @@ static void start_iaa_cycle(struct ehci_
 
 /* the async qh for the qtds being unlinked are now gone from the HC */
 
+static void test_qh(struct ehci_hcd *ehci, struct ehci_qh *qh)
+{
+   struct ehci_qtd *qtd;
+   __hc32  tok;
+
+   qh-old_ovtok = qh-hw-hw_token;
+   list_for_each_entry(qtd, qh-qtd_list, qtd_list) {
+   tok = ACCESS_ONCE(qtd-hw_token);
+   if (tok  ACTIVE_BIT(ehci)) {
+   qh-old_qtd = qtd;
+   qh-old_tdtok = qh-new_tdtok = tok;
+   break;
+   }
+   }
+}
+
 static void end_unlink_async(struct ehci_hcd *ehci)
 {
struct ehci_qh  *qh;
@@ -1244,6 +1272,7 @@ static void end_unlink_async(struct ehci
 
qh-qh_state = QH_STATE_IDLE;
qh-qh_next.qh = NULL;
+   test_qh(ehci, qh);
 
qh_completions(ehci, qh);
if (!list_empty(qh-qtd_list) 
Index: usb-3.7/drivers/usb/host/ehci-timer.c

Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

2012-12-12 Thread Frank Schäfer 
Am 12.12.2012 09:23, schrieb Lan Tianyu:
 On 2012年12月12日 05:59, Frank Schäfer wrote:
 Am 11.12.2012 17:48, schrieb Alan Stern:

 [snip]
 We really need to know which component is bad: the host controller or 
 the device.
 It happens with all USB 1.1 devices I have (several mice and a HP
 Deskjet 960c printer).
 The same devices do not cause other machines to wake up, so I assume
 it's the host controller.
 Good information. Attaching device makes hc work abnormally during
 entering into s3 since without device it can work, right?

Right.
The system successfully enters S3 (machine switches off = fan stops,
light off etc.) but it resumes immediately.
No errors in the log, it looks like this:

snip
...
[24685.640361] PM: Syncing filesystems ... done.
[24686.022132] PM: Preparing system for mem sleep
[24686.110208] Freezing user space processes ... (elapsed 0.01 seconds)
done.
[24686.123851] Freezing remaining freezable tasks ... (elapsed 0.01
seconds) done.
[24686.134818] PM: Entering mem sleep
[24686.134840] Suspending console(s) (use no_console_suspend to debug)
[24686.135751] sd 1:0:0:0: [sda] Synchronizing SCSI cache
[24686.136509] sd 1:0:0:0: [sda] Stopping disk
[24686.150741] i8042 kbd 00:0b: wake-up capability enabled by ACPI
[24686.150833] i8042 aux 00:0a: wake-up capability disabled by ACPI
[24686.150926] parport_pc 00:09: disabled
[24686.151029] serial 00:08: disabled
[24686.151056] serial 00:08: wake-up capability disabled by ACPI
[24686.151219] ACPI handle has no context!
[24686.151299] [drm] nouveau :00:0d.0: Disabling display...
[24686.151302] [drm] nouveau :00:0d.0: Disabling fbcon...
[24686.151311] [drm] nouveau :00:0d.0: Unpinning framebuffer(s)...
[24686.151341] [drm] nouveau :00:0d.0: Evicting buffers...
[24686.255063] usb 1-5: reset high-speed USB device number 3 using ehci_hcd
[24686.346351] [drm] nouveau :00:0d.0: Idling channels...
[24686.346668] [drm] nouveau :00:0d.0: Suspending GPU objects...
[24686.447591] [drm] nouveau :00:0d.0: And we're gone!
[24687.547695] PM: suspend of devices complete after 1412.642 msecs
[24687.547853] PM: late suspend of devices complete after 0.153 msecs
[24687.548029] forcedeth :00:07.0: wake-up capability enabled by ACPI
[24687.559652] ehci_hcd :00:02.1: wake-up capability enabled by ACPI
[24687.570602] ohci_hcd :00:02.0: wake-up capability enabled by ACPI
[24687.581671] PM: noirq suspend of devices complete after 33.815 msecs
[24687.581735] ACPI: Preparing to enter system sleep state S3
[24687.582536] PM: Saving platform NVS memory
[24687.582591] Disabling non-boot CPUs ...
[24687.583984] smpboot: CPU 1 is now offline
[24687.584703] Extended CMOS year: 2000
[24687.584703] ACPI: Low-level resume complete
[24687.584703] PM: Restoring platform NVS memory
[24687.584703] Extended CMOS year: 2000
[24687.586196] Enabling non-boot CPUs ...
[24687.589496] smpboot: Booting Node 0 Processor 1 APIC 0x1
[24687.583795] Initializing CPU#1
[24687.583795] process: Switch to broadcast mode on CPU1
[24687.601153] CPU1 is up
[24687.601538] ACPI: Waking up from system sleep state S3
[24687.613683] ohci_hcd :00:02.0: wake-up capability disabled by ACPI
[24687.624693] ehci_hcd :00:02.1: wake-up capability disabled by ACPI
[24687.624746] pci :00:00.0: Found enabled HT MSI Mapping
[24687.635726] pci :00:00.0: Found enabled HT MSI Mapping
[24687.657735] pci :00:00.0: Found enabled HT MSI Mapping
[24687.668730] pci :00:00.0: Found enabled HT MSI Mapping
[24687.679730] pci :00:00.0: Found enabled HT MSI Mapping
[24687.679803] pci :00:00.0: Found enabled HT MSI Mapping
[24687.679878] pci :00:00.0: Found enabled HT MSI Mapping
[24687.679956] pci :00:00.0: Found enabled HT MSI Mapping
[24687.773804] PM: noirq resume of devices complete after 171.507 msecs
[24687.773907] PM: early resume of devices complete after 0.056 msecs
[24687.773980] ohci_hcd :00:02.0: setting latency timer to 64
[24687.774001] ehci_hcd :00:02.1: setting latency timer to 64
[24687.774023] pci :00:04.0: setting latency timer to 64
...
snip


When I disconnect all USB 1.1 devices, suspend works fine.

 I am curious about whether disabling usb device's wakeup rather than usb
 hc's would make suspend work. Can you do a test?

 Go to /sys/bus/usb/devices/ and enter the usb 1,1 device
 directory(normally it will be something like1-1.1.)
 run echo disabled  power/wakeup.

Are you sure the file is called 'wakeup' for the devices ? I have no
such file in the power directory...

Regards,
Frank
--
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#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

2012-12-12 Thread Octavio Alvarez 
On Wed, 12 Dec 2012 12:28:16 -0800, Frank Schäfer  
fschaefer@googlemail.com wrote:



Good information. Attaching device makes hc work abnormally during
entering into s3 since without device it can work, right?


Right.
The system successfully enters S3 (machine switches off = fan stops,
light off etc.) but it resumes immediately.
No errors in the log, it looks like this:


A while ago I did some tests, and I got no errors whatsoever, not even
with PM_DEBUG. System is successfully suspended but immediately awaken.

--
Octavio.
--
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: gadget: fix switch off blocked in u_serial

2012-12-12 Thread Linus Walleij 
On Tue, Nov 27, 2012 at 3:11 PM, Linus Walleij linus.wall...@linaro.org wrote:
 On Wed, Nov 21, 2012 at 3:33 PM, Linus Walleij linus.wall...@linaro.org 
 wrote:
 On Wed, Nov 14, 2012 at 3:40 PM, Linus Walleij
 linus.wall...@stericsson.com wrote:

 From: Haipeng YU haipeng...@stericsson.com

 When a device is switched off by software, gserial_cleanup will
 be called, and switch off will be blocked in this function
 because wake_up_interruptible() in gs_close() can not wake_up
 the wait_event() in gserial_cleanup(), it should be changed to
 wake_up() to match the wait_event().

 Signed-off-by: Haipeng YU haipeng...@stericsson.com
 Signed-off-by: Linus Walleij linus.wall...@linaro.org
 ---
  drivers/usb/gadget/u_serial.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/usb/gadget/u_serial.c b/drivers/usb/gadget/u_serial.c
 index f173952..2d074ba 100644
 --- a/drivers/usb/gadget/u_serial.c
 +++ b/drivers/usb/gadget/u_serial.c
 @@ -887,7 +887,7 @@ static void gs_close(struct tty_struct *tty, struct 
 file *file)
 pr_debug(gs_close: ttyGS%d (%p,%p) done!\n,
 port-port_num, tty, file);

 -   wake_up_interruptible(port-port.close_wait);
 +   wake_up(port-port.close_wait);
  exit:
 spin_unlock_irq(port-port_lock);
  }

 Ping on this, we're trying to figure out if we're doing the right
 thing here so help...

 Ping again. This is stopping our systems from shutting down
 so would really appreciate some advice if this is the way
 to go.

Ping on this again, Felipe do you want us to repost?

Soon one month in review...

Yours,
Linus Walleij
--
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: issue with uvcvideo and xhci

2012-12-12 Thread Javier Martinez Canillas 
On 12/12/2012 06:52 PM, Sarah Sharp wrote:
 On Wed, Dec 12, 2012 at 12:47:24PM +0100, Javier Martinez Canillas wrote:
 Hello,
 
 We have an issue when trying to use USB cameras on a particular machine using
 the latest mainline Linux 3.7 kernel. This is not a regression since the same
 issue is present with older kernels (i.e: 3.5).
 
 The cameras work fine when plugged to an USB2.0 port (using the EHCI HCD host
 controller driver) but they don't when using the USB3.0 port (using the xHCI
 HCD host controller driver).
 
 The machine's USB3.0 host controller is a NEC Corporation uPD720200 USB 3.0 
 Host
 Controller (rev 04).
 
 When enabling trace on the uvcvideo driver I see that most frames are lost:
 
 Dec 12 11:07:58 thinclient kernel: [ 4965.597637] uvcvideo: USB isochronous
 frame lost (-18).
 Dec 12 11:07:58 thinclient kernel: [ 4965.597642] uvcvideo: USB isochronous
 frame lost (-18).
 Dec 12 11:07:58 thinclient kernel: [ 4965.597647] uvcvideo: Marking buffer as
 bad (error bit set).
 Dec 12 11:07:58 thinclient kernel: [ 4965.597651] uvcvideo: Frame complete 
 (EOF
 found).
 Dec 12 11:07:58 thinclient kernel: [ 4965.597655] uvcvideo: EOF in empty 
 payload.
 Dec 12 11:07:58 thinclient kernel: [ 4965.597661] uvcvideo: Dropping payload
 (out of sync).
 Dec 12 11:07:58 thinclient kernel: [ 4965.813294] uvcvideo: frame 486 stats:
 0/2/8 packets, 0/0/8 pts
 
 The uvcvideo checks if urb-iso_frame_desc[i].status  0 on the
 uvc_video_decode_isoc() function (drivers/media/usb/uvc/uvc_video.c).
 
 I checked on the xhci driver and the only place where this error code 
 (-EXDEV)
 is assigned to frame-status is inside the skip_isoc_td() function
 (drivers/usb/host/xhci-ring.c).
 
 At this point I'm not sure if this is a bug on the xhci driver, another quirk
 needed by the XHCI_NEC_HOST, a camera misconfiguration on the USB Video Class
 driver or a firmware/hardware bug.
 
 It's a known performance issue, although it's not clear whether it's on
 the xHCI driver side or the host controller side.  When an interface
 setting is enabled where the isochronous endpoint requires two
 additional transfers per service interval, the NEC host controller
 starts reporting many missed service intervals.  The xHCI driver then
 finds all the frame buffers that were skipped and marks them with the
 -EXDEV status.

 An error status of Missed Service Interval means the host controller
 could not access the transfer memory fast enough through the PCI bus to
 service the endpoint in time.  It could be a host hardware issue, or it
 could be software slowing down the system to a crawl.  I lean towards a
 software issue since, as you said, the Windows driver works fine.
 (Although who knows what NEC quirks the Windows driver is working
 around...)

 The NEC xHCI host controller is a 0.96 revision, which doesn't support
 the Block Event Interrupt (BEI) flag which cuts down on the number of
 interrupts per URB submitted.  So the xHCI driver's interrupt routine
 gets called on every single service interval, rather than being called
 once per URB.
 
 Since the Linux xHCI driver isn't really optimized for performance yet,
 the interrupt handler is probably pretty slow and could cause delays in
 submitting future URBs.  The high amount of interrupts is probably
 causing other systems to be starved, possibly leading to the xHCI host
 controller not being able to access memory fast enough to service the
 endpoint.


Hi Sarah,

Thanks for the explanation. Now it makes sense to me and I understand why it
works when I decrease either the frame rate or the frame size below certain
thresholds.

 The cameras are reported to work on the same machine but using another 
 operating
 system (Windows).
 
 Windows probably uses Event Data TRBs to cut the interrupts down to one
 per URB.  It would take a major effort to make the xHCI driver use Event
 Data TRBs.
 
 I was wondering if you can give me some pointers on how to be sure what's the
 issue or if this rings any bells to you.
 
 I don't have time to work on performance issues right now, as I have
 several other critical bugs (mostly around failed S3/S4).  However, if
 you want to try to fix this issue yourself, I suggest you run perf and
 see where the bottle necks in the xHCI interrupt handler are.
 
 I suspect that part of it is that the interrupt handler reads the xHCI
 status register.  That PCI register read is pretty costly, and it's not
 necessary since 99% of the time the host controller is going to report
 an OK status.  And there's no guarantee that when the host does have an
 error that it will set a bad status.
 
 But without an analysis by perf, we won't really know where the
 bottlenecks are.
 
 Sarah Sharp
 

Ok, I'll try do some performance analysis to figure out where these bottlenecks
could be and if I can do anything to improve them.

Thanks a lot for your help!

Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to

Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

2012-12-12 Thread Lan Tianyu 
On 2012年12月12日 23:50, Alan Stern wrote:
 On Wed, 12 Dec 2012, Lan Tianyu wrote:
 
 Hi Alan:
  About your question of Does the device send a remote wakeup request
 even when it is disabled for remote wakeup?, I am not very clear.
 Default, device remote wakeup is disabled and if we disable device's
 remote wakeup via sysfs, the device's remote wakeup feature will not be
 set during being suspended. So normally, it should not send out remote
 wakeup signal but if it still sent out, this means it's a buggy device,
 right?
 
 Right.
 
  Moreover, this test is hard to do during s3 since system suspend, we
 can't see any log. So this should be done in the runtime. I think it's
 easy to do this test on mouse or keyboard device.
 
 Yes, that should work.  But Frank says that the same mouse and keyboard 
 do not cause other machines to wake up, so the devices are probably 
 working correctly.
 
Yeah.

 Do you have one of these machines to test?
 
Unfortunately, I don't have such machine.

 Alan Stern
 


-- 
Best regards
Tianyu Lan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] usb: musb: dsps: header movement build error fix

2012-12-12 Thread Mohammed, Afzal 
Hi Felipe,

On Tue, Nov 27, 2012 at 20:15:22, Mohammed, Afzal wrote:

 54db6ee ARM: OMAP2+: Introduce local usb.h moved control module bit
 definitions from plat/usb.h (which dsps glue was using) to a local
 header in mach-omap2. And in parallel,
 c68bb4c usb: musb: dsps: control module handling (quirk) added
 control module handling capability to dsps glue driver that used
 those control module bit definitions.
 
 Integration of above two changes would cause build error in musb dsps
 glue driver (they go through different trees upstream) as is seen now
 in linux-next. Fix it by adding necessary definitions in dsps glue
 driver.
 
 Signed-off-by: Afzal Mohammed af...@ti.com
 ---

 This applies on top of your musb branch, please help this reach
 mainline along with other musb dsps changes for coming merge window
 so that they would not cause build error and so that we can have a
 working usb in mainline for am335x (beaglebone) at the earliest.

musb dsps build breaks in mainline now, this patch fixes it, can you
please help this change reach mainline.

Both commits mentioned above (control module quirk  usb header
movement) has reached mainline.

Regards
Afzal