[PATCH 1/1] usb: misc: usbtest: format max packet size for iso transfer

2015-08-17 Thread Peter Chen 
The current code prints all wMaxPacketSize content at endpoint
descriptor, if there is a high speed, high bandwidth endpoint,
it may confuse the users, eg, if there are 3 transactions during
microframe, it will print wMaxPacket 1400 for packet content.
This commit splits wMaxpacketSize and transaction numbers for
output messages.

Signed-off-by: Peter Chen peter.c...@freescale.com
---
 drivers/usb/misc/usbtest.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 0bbafe7..9517812 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -1925,10 +1925,11 @@ test_iso_queue(struct usbtest_dev *dev, struct 
usbtest_param *param,
memset(urbs, 0, sizeof(urbs));
udev = testdev_to_usbdev(dev);
dev_info(dev-intf-dev,
-   ... iso period %d %sframes, wMaxPacket %04x\n,
+   iso period %d %sframes, wMaxPacket %d, transactions: %d\n,
1  (desc-bInterval - 1),
(udev-speed == USB_SPEED_HIGH) ? micro : ,
-   usb_endpoint_maxp(desc));
+   usb_endpoint_maxp(desc)  0x7ff,
+   1 + (0x3  (usb_endpoint_maxp(desc)  11)));
 
for (i = 0; i  param-sglen; i++) {
urbs[i] = iso_alloc_urb(udev, pipe, desc,
@@ -1942,7 +1943,7 @@ test_iso_queue(struct usbtest_dev *dev, struct 
usbtest_param *param,
}
packets *= param-iterations;
dev_info(dev-intf-dev,
-   ... total %lu msec (%lu packets)\n,
+   total %lu msec (%lu packets)\n,
(packets * (1  (desc-bInterval - 1)))
/ ((udev-speed == USB_SPEED_HIGH) ? 8 : 1),
packets);
-- 
1.9.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] add-ZTE-pid

2015-08-17 Thread Johan Hovold 
On Sun, Aug 02, 2015 at 08:41:48PM -0700, Liu.Zhao wrote:

Make sure to always include a commit message.

Also change you Subject (patch summary) to something more descriptive
using the following format:

USB: option: add ZTE PIDs

 Signed-off-by: Liu.Zhao lzsos...@163.com
 ---
  drivers/usb/serial/option.c | 29 +
  1 file changed, 29 insertions(+)
 
 diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
 index f0c0c53..6996308 100644
 --- a/drivers/usb/serial/option.c
 +++ b/drivers/usb/serial/option.c
 @@ -285,6 +285,10 @@ static void option_instat_callback(struct urb *urb);
  #define ZTE_PRODUCT_MC2718   0xffe8
  #define ZTE_PRODUCT_AD3812   0xffeb
  #define ZTE_PRODUCT_MC2716   0xffed
 +#define ZTE_PRODUCT_ZM8620_X 0x0396
 +#define ZTE_PRODUCT_ME3620_X 0x1432
 +#define ZTE_PRODUCT_ME3620_L 0x1433
 +#define ZTE_PRODUCT_ME3620_MBIM  0x0426

I already asked you to try to keep these sorted according to PID (e.g.
add them sorted before ZTE_PRODUCT_AC2726).

  
  #define BENQ_VENDOR_ID   0x04a5
  #define BENQ_PRODUCT_H10 0x4068
 @@ -544,6 +548,23 @@ static const struct option_blacklist_info 
 zte_mc2716_z_blacklist = {
   .sendsetup = BIT(1) | BIT(2) | BIT(3),
  };
  
 +static const struct option_blacklist_info zte_zm8620_x_blacklist = {
 + .reserved = BIT(3) | BIT(4) | BIT(5),
 +};
 +
 +static const struct option_blacklist_info zte_me3620_x_blacklist = {
 + .reserved = BIT(3) | BIT(4) | BIT(5),
 +};
 +
 +static const struct option_blacklist_info zte_me3620_l_blacklist = {
 + .reserved = BIT(3) | BIT(4) | BIT(5),
 +};
 +
 +static const struct option_blacklist_info zte_me3620_mbim_blacklist = {
 + .reserved = BIT(2) | BIT(3) | BIT(4),
 +};

I also asked you to consider reusing the blacklist structs for related
devices (e.g. zte_me3620_xl).

Please keep these new structs sorted by symbol name as well.

 +
 +

Remove the stray newline.

  static const struct option_blacklist_info huawei_cdc12_blacklist = {
   .reserved = BIT(1) | BIT(2),
  };
 @@ -1592,6 +1613,14 @@ static const struct usb_device_id option_ids[] = {
   { USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x01) },
   { USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x05) },
   { USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x86, 0x10) },
 + { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ZM8620_X),
 + .driver_info = (kernel_ulong_t)zte_zm8620_x_blacklist },
 + { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_X),
 + .driver_info = (kernel_ulong_t)zte_me3620_x_blacklist },
 + { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_L),
 + .driver_info = (kernel_ulong_t)zte_me3620_l_blacklist },
 + { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_MBIM),
 + .driver_info = (kernel_ulong_t)zte_me3620_mbim_blacklist },

And try to keep these entries sorted on symbol names as well (e.g. add
them sorted after ZTE_PRODUCT_MC2716).

   { USB_DEVICE(BENQ_VENDOR_ID, BENQ_PRODUCT_H10) },
   { USB_DEVICE(DLINK_VENDOR_ID, DLINK_PRODUCT_DWM_652) },

Otherwise the patch is now on the right format.

Could you fix up the above and resend?

Please include a [PATCH v3]-prefix in you subject when resending.

Thanks,
Johan
--
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: ftdi_sio: Added custom PID for CustomWare products

2015-08-17 Thread Johan Hovold 
On Mon, Aug 03, 2015 at 08:15:40AM +0200, Matthijs Kooijman wrote:
 Hi Lars,
 
  What I meant is that ...FTDI_C. should come before ...FTDI_S
  and not after, but I've had a look at the whole ftdi_sio.c source
  now and it looks horrible.
  I think it doesn't really matter where you put your additions, do as
  others has done and put them at a random position..
 Yeah, I looked at that, the commits I looked at just added new stuff at
 the end, and so did I :-)

It's a good rule of thumb to try to keep the entries sorted, but yeah,
it's not always possible.

Johan
--
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: ftdi_sio: Added custom PID for CustomWare products

2015-08-17 Thread Johan Hovold 
On Sun, Aug 02, 2015 at 02:00:00PM +0200, Matthijs Kooijman wrote:
 CustomWare uses the FTDI VID with custom PIDs for their ShipModul MiniPlex
 products.
 
 Signed-off-by: Matthijs Kooijman matth...@stdin.nl

Applied, thanks.

Johan
--
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

[GIT PULL] USB-serial updates for v4.3-rc1

2015-08-17 Thread Johan Hovold 
Hi Greg,

Here are my updates for v4.3-rc1. All have been in linux-next for some
time.

Thanks,
Johan


The following changes since commit 52721d9d3334c1cb1f76219a161084094ec634dc:

  Linux 4.2-rc3 (2015-07-19 14:45:02 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
tags/usb-serial-4.3-rc1

for you to fetch changes up to 26c78daade0fbeef7f20bae3c5508a7c571078cd:

  USB: io_ti: Add heartbeat to keep idle EP/416 ports from disconnecting 
(2015-07-31 12:09:57 +0200)


USB-serial updates for v4.3-rc1

Here's a fix for a long-standing issue with the pl2303 divisor
calculations that affects some non-standard baudrates that were enabled
in v3.18.

Adding support for newer Edgeport devices and firmware required changes
to the io_ti driver and also exposed some issues with the driver's
current firmware handling.

Included is also a URL comment-typo fix.

Signed-off-by: Johan Hovold jo...@kernel.org


Michał Pecio (1):
  USB: pl2303: fix baud-rate divisor calculations

Nik Nyby (1):
  USB: serial: ftdi_sio: Fix broken URL in comment

Peter E. Berger (4):
  USB: io_ti: Increase insufficient timeout for firmware downloads
  USB: io_ti: Fix firmware version handling
  USB: io_ti: Add firmware image sanity checks
  USB: io_ti: Add heartbeat to keep idle EP/416 ports from disconnecting

 drivers/usb/serial/ftdi_sio_ids.h |   2 +-
 drivers/usb/serial/io_ti.c| 279 +-
 drivers/usb/serial/pl2303.c   |  35 +++--
 3 files changed, 240 insertions(+), 76 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

Re: [PATCH v2 8/9] usb: serial: mxuport: Simplify return statement

2015-08-17 Thread Johan Hovold 
On Tue, Aug 04, 2015 at 02:04:35PM +, Karajgaonkar, Saurabh (S.) wrote:
 From: Saurabh Karajgaonkar skara...@visteon.com
 
 Replace redundant variable use in return statement.
 
 Signed-off-by: Saurabh Karajgaonkar skara...@visteon.com
 ---
  drivers/usb/serial/mxuport.c | 10 +++---
  1 file changed, 3 insertions(+), 7 deletions(-)
 
 diff --git a/drivers/usb/serial/mxuport.c b/drivers/usb/serial/mxuport.c
 index 460a406..31a8b47 100644
 --- a/drivers/usb/serial/mxuport.c
 +++ b/drivers/usb/serial/mxuport.c
 @@ -1137,13 +1137,9 @@ static int mxuport_port_probe(struct usb_serial_port 
 *port)
   return err;
  
   /* Set interface (RS-232) */
 - err = mxuport_send_ctrl_urb(serial, RQ_VENDOR_SET_INTERFACE,
 - MX_INT_RS232,
 - port-port_number);
 - if (err)
 - return err;
 -
 - return 0;
 + return mxuport_send_ctrl_urb(serial, RQ_VENDOR_SET_INTERFACE,
 +  MX_INT_RS232,
 +  port-port_number);

I do not consider this an improvement as it makes the final ctrl-request
call look different from the previous two without any real benefit.

I'll drop this one.

Johan
--
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: Fwd: [Bug 102101] USB 3 storage device disconnects after S3 resume,and re-enumerate it.

2015-08-17 Thread Aaron Zhou 
Hi, all

 https://bugzilla.kernel.org/show_bug.cgi?id=102101

 Bug ID: 102101
Summary: USB 3 storage device disconnects after S3 resume,and
 re-enumerate it.

I debug this problem ,and I find that when I suspend to ram (STR),
the STS_SRE bit is set. and  re-initialize the HC during resume,

In xhci_resume() function, after xhci_handshake() is called ,
I printk the xhci-op_regs-status, it is 0x401, means the STS_SRE bit is set.
I can not understand.

This is normal ?

Aaron Chou

On Tue, Aug 4, 2015 at 8:42 AM, Aaron Zhou zhoubb.aa...@gmail.com wrote:
 Yes,I saw the code.
 And the uPD720201 's device ID is 0014.
 I have changed the code ,but it is without any help.

 On Mon, Aug 3, 2015 at 9:59 PM, Mathias Nyman
 mathias.ny...@linux.intel.com wrote:
 On 02.08.2015 08:37, Aaron Zhou wrote:
 Oh sorry!
 I have tired the 4.2-rc4 kernel, but the bug is still exist.

 Anyway,It is the first step that to kown whether the Renesas
 Technology Corp. uPD720201 chip performance fine on X86 system after
 resume.
  I don't have the experimental environment.

 xhci driver has a quirk to reset Renesas uPD720202 USB 3.0 Host Controller 
 device [0015]
 on resume.  Does the uPD720201 have the same device ID?

 lspci -vmnnd 1912

 -Mathias

--
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

Offerta di prestito tra individuo serio ed affidabile in Francia

2015-08-17 Thread angeline lopez 
Qui presento me signora Marie Anna French donna di affari che
risiedono in Francia.
Vengo da questo rende questa email fai parte di un'offerta di prestito
finanziario che vanno da € 1000 a € 2.500.000 con una percentuale di
restituzione dell'importo pari al 3%
rimborsabile al momento il numero di anni sarebbe ma favore
Se siete interessati a questa offerta di prestito si prega gentilmente
di mettersi in contatto.
Sarà seguito secondo le leggi francesi in vigore
Si prega di mettersi in contatto se siete interessati a questa offerta
di prestito all'indirizzo: marieanna...@yahoo.fr
Mrs Marie Anna
--
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

Offerta di prestito tra individuo serio ed affidabile in Francia

2015-08-17 Thread angeline lopez 
Qui presento me signora Marie Anna French donna di affari che
risiedono in Francia.
Vengo da questo rende questa email fai parte di un'offerta di prestito
finanziario che vanno da € 1000 a € 2.500.000 con una percentuale di
restituzione dell'importo pari al 3%
rimborsabile al momento il numero di anni sarebbe ma favore
Se siete interessati a questa offerta di prestito si prega gentilmente
di mettersi in contatto.
Sarà seguito secondo le leggi francesi in vigore
Si prega di mettersi in contatto se siete interessati a questa offerta
di prestito all'indirizzo: marieanna...@yahoo.fr
Mrs Marie Anna
--
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/3] Introduce usb charger framework to deal with the usb gadget power negotation

2015-08-17 Thread Li Jun 
On Mon, Aug 17, 2015 at 02:02:08PM +0800, Baolin Wang wrote:
 On 17 August 2015 at 09:15, Li Jun b47...@freescale.com wrote:
  On Fri, Aug 14, 2015 at 07:04:56PM +0800, Baolin Wang wrote:
  On 14 August 2015 at 16:55, Li Jun b47...@freescale.com wrote:
   Hi Baolin,
  
   On Fri, Aug 14, 2015 at 05:47:43PM +0800, Baolin Wang wrote:
   Currently the Linux kernel does not provide any standard integration of 
   this
   feature that integrates the USB subsystem with the system power 
   regulation
   provided by PMICs meaning that either vendors must add this in their 
   kernels
   or USB gadget devices based on Linux (such as mobile phones) may not 
   behave
   as they should.
  
   Providing a standard framework for doing this in the kernel.
  
  
   Why not add power supply class support into this?
  
 
  Hi Jun,
 
  We don't need the power supply class support into the usb charger,
  I suppose usb charger is also a power supply for the system, we can use 
  power
  supply class framework for notify mechanism and get/set many 
  attributes(maybe
  also the current limit), I see those usb charger drivers under 
  ./driver/power/
  are designed with power supply supported.
 
 
 I don't think so. The usb charger is rely on the usb gadget, which is
 not a complete power supply device and it combines the usb and the
 power supply. Thus we make it into usb gadget system. Thanks.
 
Why it cannot be a complete power supply device? I was thinking this
framework can cover it, I have no doubt on putting this framework
into gadget system, but still can't understand why we don't need
power supply class at all for a usb charger, or you think introduce
power supply into usb gadget is not a right direction from code structure
point view?

Li Jun
  Li Jun
  just introduce the notify mechanism for power to set the current limit
  when notifying some events from usb charger. Maybe I misunderstand
  your meanings, please describe it detailedly. Thanks for your
  comments.
 
   Li Jun
  
 
 
 
  --
  Baolin.wang
  Best Regards
 
 
 
 -- 
 Baolin.wang
 Best Regards
--
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: qcserial: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module

2015-08-17 Thread Johan Hovold 
On Sat, Aug 15, 2015 at 08:13:08PM -0400, David Ward wrote:
 This is an HP-branded Sierra Wireless EM7355:
 https://bugzilla.redhat.com/show_bug.cgi?id=1223646#c2
 
 Signed-off-by: David Ward david.w...@ll.mit.edu

Applied, thanks.

Johan
--
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/3] Introduce usb charger framework to deal with the usb gadget power negotation

2015-08-17 Thread Baolin Wang 
On 17 August 2015 at 16:20, Li Jun b47...@freescale.com wrote:
 On Mon, Aug 17, 2015 at 02:02:08PM +0800, Baolin Wang wrote:
 On 17 August 2015 at 09:15, Li Jun b47...@freescale.com wrote:
  On Fri, Aug 14, 2015 at 07:04:56PM +0800, Baolin Wang wrote:
  On 14 August 2015 at 16:55, Li Jun b47...@freescale.com wrote:
   Hi Baolin,
  
   On Fri, Aug 14, 2015 at 05:47:43PM +0800, Baolin Wang wrote:
   Currently the Linux kernel does not provide any standard integration 
   of this
   feature that integrates the USB subsystem with the system power 
   regulation
   provided by PMICs meaning that either vendors must add this in their 
   kernels
   or USB gadget devices based on Linux (such as mobile phones) may not 
   behave
   as they should.
  
   Providing a standard framework for doing this in the kernel.
  
  
   Why not add power supply class support into this?
  
 
  Hi Jun,
 
  We don't need the power supply class support into the usb charger,
  I suppose usb charger is also a power supply for the system, we can use 
  power
  supply class framework for notify mechanism and get/set many 
  attributes(maybe
  also the current limit), I see those usb charger drivers under 
  ./driver/power/
  are designed with power supply supported.
 

 I don't think so. The usb charger is rely on the usb gadget, which is
 not a complete power supply device and it combines the usb and the
 power supply. Thus we make it into usb gadget system. Thanks.

 Why it cannot be a complete power supply device? I was thinking this
 framework can cover it, I have no doubt on putting this framework
 into gadget system, but still can't understand why we don't need
 power supply class at all for a usb charger, or you think introduce
 power supply into usb gadget is not a right direction from code structure
 point view?


We just do not think the usb charger as a real device, which is only
used to set the current limitation when the usb charger state is
changed detecting by extcon device or usb gadget. So we just need one
message to notify the power user to set the current limitation when
uab charge is added or removed. I also agree with the power supply
framework can cover it, but we don't need to implement it to be
another power supply, cause there is a real device as the power supply
to deal with the power issue in the system. Thanks.

 Li Jun
  Li Jun
  just introduce the notify mechanism for power to set the current limit
  when notifying some events from usb charger. Maybe I misunderstand
  your meanings, please describe it detailedly. Thanks for your
  comments.
 
   Li Jun
  
 
 
 
  --
  Baolin.wang
  Best Regards



 --
 Baolin.wang
 Best Regards



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

[PATCH] usb: dwc3: pci: passing forward the ACPI companion

2015-08-17 Thread Heikki Krogerus 
Sharing the APCI companion with the core platforms device so
it has access to all DWC3's resources.

Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
 drivers/usb/dwc3/dwc3-pci.c | 1 +
 1 file changed, 1 insertion(+)

Hi,

This depends on being able to prevent execution of ACPI power methods
more then once. Mika has made a patch for that:
https://git.kernel.org/cgit/linux/kernel/git/lee/mfd.git/commit/?h=for-mfd-nextid=712e960f0ee9337f3473ba3de2bcfc7e87b7c5a4


Thanks,

diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index f626179..89eb364 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -154,6 +154,7 @@ static int dwc3_pci_probe(struct pci_dev *pci,
goto err;
 
dwc3-dev.parent = dev;
+   ACPI_COMPANION_SET(dwc3-dev, ACPI_COMPANION(dev));
 
ret = platform_device_add(dwc3);
if (ret) {
-- 
2.5.0

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

repeat... Re: BUG: usb: phy: msm: problem with EPROBE defer and extcon cleanup

2015-08-17 Thread Tim Bird 
Sorry - I mistyped Ivan's e-mail the first time.

On 08/17/2015 04:43 PM, Tim Bird wrote:
 Ivan,
 
 I'm seeing a bug in the phy-msm-usb.c code, when I get an EPROBE defer during 
 probing the driver.
 The code is statically linked in the kernel, and the dts for my board is 
 specifying an extcon phandle 
 for the ID pin.
 
 Below is a fragment of the kernel output for a boot of this code.  Messages 
 prefixed with TRB
 are my own debug printks.  Note that the notifier block (at ee23513c) that 
 gets registered
 with extcon before the first probe failure, ultimately gets used during an ID 
 pin event
 (status change) by raw_notifier_call_chain().  This notifier block should be 
 unregistered
 if the probe fails, so that only the second one registered is on the call 
 chain.
 
 Let me know if you plan to work on this.  I'm otherwise occupied the 
 remainder of this week,
 so won't have time to work on it, but I can probably get to it early next 
 week if you don't.
 
 Regards,
  -- Tim
 
 
 [1.435543] NET: Registered protocol family 17 
  
 [1.439773] Key type dns_resolver registered   
  
 [1.444041] Registering SWP/SWPB emulation handler 
  
 [1.451259] msm_otg f9a55000.usb-phy: failed to get phandle in 
 /soc/usb-phy@f9a55000 node   
 [1.452915] TRB: registering notifier for ext_id   
  
 [1.464681] TRB: motg=ee235010, id=ee23513c, nb=ee23513c   
  
 [1.465957] msm_otg f9a55000.usb-phy: OTG regs = f011e000  
  
 [1.471532] msm_otg f9a55000.usb-phy: Failed to get supply 'v3p3': -517
  
 [1.477416] msm_hsusb_host f9a55000.ehci: ehci_msm proble  
  
 [1.482889] msm_hsusb_host f9a55000.ehci: unable to find transceiver   
  
 [1.488762] msm_hsusb f9a55000.usb-controller: ci_hdrc_msm_probe   
  
 [1.501689] l20: supplied by vreg-boost-bypass 
  
 [1.503694] s3: operation not allowed  
  
 [1.505072] mmc0: Switching to 3.3V signalling voltage failed  
  
 [1.545275] mmc0: SDHCI controller on f9824900.sdhci [f9824900.sdhci] 
 using ADMA
 [1.545615] msm_otg f9a55000.usb-phy: failed to get phandle in 
 /soc/usb-phy@f9a55000 node   
 [1.551749] TRB: registering notifier for ext_id   
  
 [1.559835] TRB: motg=ed893e10, id=ed893f3c, nb=ed893f3c   
  
 [1.564578] msm_otg f9a55000.usb-phy: OTG regs = f0132000  
  
 [1.569985] l24: supplied by vreg-boost-bypass 
  
 [1.575342] l6: supplied by s2 
  
 [1.579737] l6: operation not allowed  
  
 [1.582458] l24: operation not allowed 
  
 [1.586229] reg (HPM)  
  
 [1.608277] mmc0: MAN_BKOPS_EN bit is not set  
  
 [1.615708] mmc0: new HS200 MMC card at address 0001   
  
 [1.616252] mmcblk0: mmc0:0001 SEM16G 14.6 GiB 
  
 [1.619888] mmcblk0boot0: mmc0:0001 SEM16G partition 1 4.00 MiB
  
 [1.624128] mmcblk0boot1: mmc0:0001 SEM16G partition 2 4.00 MiB
  
 [1.630063] mmcblk0rpmb: mmc0:0001 SEM16G partition 3 4.00 MiB 
  
 [1.638255]  mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15 
 p16 p17 p18 p19 p20
 [1.695676] msm_hsusb_host f9a55000.ehci: ehci_msm proble  
  
 [1.695749] msm_otg f9a55000.usb-phy: Host mode is not supported   
  
 [1.700054] msm_hsusb_host f9a55000.ehci: unable to register with 
 transceiver   
 [1.706184] msm_otg f9a55000.usb-phy: OTG runtime idle 
  
 [1.713500] msm_hsusb f9a55000.usb-controller: ci_hdrc_msm_probe   
  
 [1.718267] f9a55000.usb-controller supply vbus not found, using dummy 
 regulator
 [1.724762] TRB: in

Re: [PATCH v2 2/3] gadget: Introduce the usb charger framework

2015-08-17 Thread Baolin Wang 
On 18 August 2015 at 01:24, Mark Brown broo...@kernel.org wrote:
 On Mon, Aug 17, 2015 at 11:03:26AM +0800, Baolin Wang wrote:
 On 14 August 2015 at 23:27, Greg KH gre...@linuxfoundation.org wrote:
  On Fri, Aug 14, 2015 at 05:47:45PM +0800, Baolin Wang wrote:

  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License as published by
  + * the Free Software Foundation; either version 2 of the License, or
  + * (at your option) any later version.

  I have to ask, do you really mean any later version?

 I think I did not get your point, could you explain it detailedly?

 Unlike a lot of userspace projects the kernel is normally just licensed
 under GPLv2 without the option to relicense with a later version so the
 ...or any later version is a bit unusual.  There is some controversy
 about some of the changes in GPLv3.

Make sense. Thanks a lot.


-- 
Baolin.wang
Best Regards
--
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: [Device-mainlining] [PATCH v2 2/3] gadget: Introduce the usb charger framework

2015-08-17 Thread Baolin Wang 
On 17 August 2015 at 23:25, Tim Bird tim.b...@sonymobile.com wrote:


 On 08/16/2015 08:03 PM, Baolin Wang via device-mainlining wrote:
 On 14 August 2015 at 23:27, Greg KH gre...@linuxfoundation.org wrote:
 On Fri, Aug 14, 2015 at 05:47:45PM +0800, Baolin Wang wrote:
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.

 I have to ask, do you really mean any later version?


 I think I did not get your point, could you explain it detailedly?

 The full kernel is licensed under v2 of the GPL only, not any later version.
 See the second paragraph at the top of the COPYING file in the root directory
 of the kernel source tree. There are differences on individual files, but
 having this file allow any later version makes it different from much of
 rest of the kernel.

 Unless you have a specific reason to allow greater-than-V2 GPL licensing on 
 this
 file, you should change the licensing clause.  The following wording appears
 to be pretty popular:

 * 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.


Hi Tim,

Make sense of it. Thanks for your explanation.

   -- Tim



-- 
Baolin.wang
Best Regards
--
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: usb: phy: msm: problem with EPROBE defer and extcon cleanup

2015-08-17 Thread Tim Bird 
Ivan,

I'm seeing a bug in the phy-msm-usb.c code, when I get an EPROBE defer during 
probing the driver.
The code is statically linked in the kernel, and the dts for my board is 
specifying an extcon phandle 
for the ID pin.

Below is a fragment of the kernel output for a boot of this code.  Messages 
prefixed with TRB
are my own debug printks.  Note that the notifier block (at ee23513c) that gets 
registered
with extcon before the first probe failure, ultimately gets used during an ID 
pin event
(status change) by raw_notifier_call_chain().  This notifier block should be 
unregistered
if the probe fails, so that only the second one registered is on the call chain.

Let me know if you plan to work on this.  I'm otherwise occupied the remainder 
of this week,
so won't have time to work on it, but I can probably get to it early next week 
if you don't.

Regards,
 -- Tim


[1.435543] NET: Registered protocol family 17   
   
[1.439773] Key type dns_resolver registered 
   
[1.444041] Registering SWP/SWPB emulation handler   
   
[1.451259] msm_otg f9a55000.usb-phy: failed to get phandle in 
/soc/usb-phy@f9a55000 node   
[1.452915] TRB: registering notifier for ext_id 
   
[1.464681] TRB: motg=ee235010, id=ee23513c, nb=ee23513c 
   
[1.465957] msm_otg f9a55000.usb-phy: OTG regs = f011e000
   
[1.471532] msm_otg f9a55000.usb-phy: Failed to get supply 'v3p3': -517  
   
[1.477416] msm_hsusb_host f9a55000.ehci: ehci_msm proble
   
[1.482889] msm_hsusb_host f9a55000.ehci: unable to find transceiver 
   
[1.488762] msm_hsusb f9a55000.usb-controller: ci_hdrc_msm_probe 
   
[1.501689] l20: supplied by vreg-boost-bypass   
   
[1.503694] s3: operation not allowed
   
[1.505072] mmc0: Switching to 3.3V signalling voltage failed
   
[1.545275] mmc0: SDHCI controller on f9824900.sdhci [f9824900.sdhci] using 
ADMA
[1.545615] msm_otg f9a55000.usb-phy: failed to get phandle in 
/soc/usb-phy@f9a55000 node   
[1.551749] TRB: registering notifier for ext_id 
   
[1.559835] TRB: motg=ed893e10, id=ed893f3c, nb=ed893f3c 
   
[1.564578] msm_otg f9a55000.usb-phy: OTG regs = f0132000
   
[1.569985] l24: supplied by vreg-boost-bypass   
   
[1.575342] l6: supplied by s2   
   
[1.579737] l6: operation not allowed
   
[1.582458] l24: operation not allowed   
   
[1.586229] reg (HPM)
   
[1.608277] mmc0: MAN_BKOPS_EN bit is not set
   
[1.615708] mmc0: new HS200 MMC card at address 0001 
   
[1.616252] mmcblk0: mmc0:0001 SEM16G 14.6 GiB   
   
[1.619888] mmcblk0boot0: mmc0:0001 SEM16G partition 1 4.00 MiB  
   
[1.624128] mmcblk0boot1: mmc0:0001 SEM16G partition 2 4.00 MiB  
   
[1.630063] mmcblk0rpmb: mmc0:0001 SEM16G partition 3 4.00 MiB   
   
[1.638255]  mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15 p16 
p17 p18 p19 p20
[1.695676] msm_hsusb_host f9a55000.ehci: ehci_msm proble
   
[1.695749] msm_otg f9a55000.usb-phy: Host mode is not supported 
   
[1.700054] msm_hsusb_host f9a55000.ehci: unable to register with 
transceiver   
[1.706184] msm_otg f9a55000.usb-phy: OTG runtime idle   
   
[1.713500] msm_hsusb f9a55000.usb-controller: ci_hdrc_msm_probe 
   
[1.718267] f9a55000.usb-controller supply vbus not found, using dummy 
regulator
[1.724762] TRB: in ci_hdrc_probe
   
[1.731807] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, revision: 10, lpm: 0; 
cap: f013a100 op: f013a140
[1.737561]

Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management

2015-08-17 Thread Felipe Balbi 
On Mon, Aug 17, 2015 at 10:26:23AM -0700, Mark Brown wrote:
 On Mon, Aug 17, 2015 at 09:07:08AM +0800, Peter Chen wrote:
  On Fri, Aug 14, 2015 at 05:47:46PM +0800, Baolin Wang wrote:
 
   + 1500,
   + 1800,
   + 550,
   +};
 
  Why 550 is the last, but not 1800?
 
 You'd have to ask the hardware engineers who designed the chip.  I
 suspect it's because 550 was added at a late stage in the design process
 but I'm basically just guessing there.
 
 */
   @@ -606,8 +646,31 @@ static int wm831x_power_probe(struct platform_device 
   *pdev)
 }
 }
 
   + if (wm831x_pdata  wm831x_pdata-usb_gadget) {
 
  Where the wm831x_pdata-usb_gadget is initialized?
 
 It's platform data, it will be initialised by whatever registers the
 platform data.

passing pointers through pdata ?

-- 
balbi


signature.asc
Description: Digital signature

Fwd: USB - Generic Serial device : Unable to read more than 4095 bytes

2015-08-17 Thread arun k 
Hi,
Regarding the above issue, I was checking the USB- Generic driver,
And I tried the following things and found my data loss issue is fixed.

change point

 In usb_serial_probe() function in usb-serial.c

/* set up the endpoint information */
for (i = 0; i  num_bulk_in; ++i) {
endpoint = bulk_in_endpoint[i];
port = serial-port[i];
buffer_size = max_t(int, serial-type-bulk_in_size,
usb_endpoint_maxp(endpoint));
buffer_size = 16384;
..
..

I changed the buffer_size value  used in urb, previously it was 64
bytes now it is 16384 and I found my data loss issue fixed.

Could you tell me is there any issue with this changes ?
I am using this driver in embedded platform and in my application
other devices will not use USB -Generic driver.

Regards,
Arun







On Sat, Aug 8, 2015 at 2:50 AM, Greg KH gre...@linuxfoundation.org wrote:

 On Fri, Aug 07, 2015 at 07:26:15PM +0900, arun k wrote:
  Hi,
 
  I am stuck with the above issue,
  I have some doubts regarding USB - Generic driver
  1. Could you please explain me why USB - Generic driver is slow ?

 Because it was designed that way, it is not for high-speed data
 throughput at all.  It is a stop-gap measure for dumb usb devices that
 want to emulate a serial connection.  If you need a real driver, to
 handle high rates of data, you will need to write a new driver for it.

  2. Now I am try to study USB - Generic driver implementation , I am
  confused with the function usb_serial_generic_read_bulk_callback() ,
  could you please tell me from where this function is calling ?

 I recommend reading the USB chapter in the Linux Device Drivers book
 (version 3, free online) to understand how USB drivers work.  After
 that, the answer should be obvious (hint, look at where that function
 pointer is assigned to something...)

  3. If you have any detailed doc regarding the implementation of USB -
  Generic serial driver, Please send to me,

 The source code is pretty well documented :)

 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

[no subject]

2015-08-17 Thread Kussner, Sara 


Please contact me about this project (mrsyuen@outlook.com)
Regards
--
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 3/3] Add ACPI bindings for the EHCI platform driver.

2015-08-17 Thread Huang Shijie 
On Thu, Aug 13, 2015 at 10:13:44AM -0500, Jeremy Linton wrote:
Hi Jeremy,

Please add my tested-by for your next version:

Tested-by: Huang Shijie shijie.hu...@arm.com


thanks
Huang Shijie

--
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/3] Honor ACPI _CCA attribute setting

2015-08-17 Thread Huang Shijie 
On Fri, Aug 14, 2015 at 09:12:28AM -0500, Jeremy Linton wrote:
 Hello Suravee,
 
 On 08/13/2015 08:45 PM, Suravee Suthikulpanit wrote:
  On 8/13/15 04:51, Jeremy Linton wrote:
  ACPI configurations can now mark devices as noncoherent,
  support that choice.
 
  This change was in my earlier revisions for the original patch series to
  add ACPI CCA support. At the time, this was pushed back since we were
  not sure whether this would be a useful case, and whether such hardware
  exists.
 
 Yes, I was made aware of that conversation during the review here.
 
 Basically, the ARM Juno development platform has a mix of coherent and 
 noncoherent devices. The EHCI being one of the primary noncoherent 
 peripherals. Without which, the usefulness of the platform for 
 developing with an ACPI kernel is limited.
 
Tesed-by: Huang Shijie shijie.hu...@arm.com

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

Re: Stack dump when try to store uframe_periodic_max

2015-08-17 Thread Alan Stern 
On Mon, 17 Aug 2015, Peter Chen wrote:

 Hi Alan,
 
 When run echo 105   
 /sys/bus/platform/devices/ci_hdrc.1/uframe_periodic_max,
 if lockdep check is enabled, there is below dump, I am afraid it can't
 find how to fix it, the warning shows the key is not persistent.
 (see line 757, kernel/locking/lockdep.c).
 
 
 [   70.190430] INFO: trying to register non-static key.
 [   70.195437] the code is fine but needs lockdep annotation.
 [   70.200939] turning off the locking correctness validator.
 [   70.206455] CPU: 0 PID: 752 Comm: sh Not tainted 
 4.2.0-rc6-00030-g91b123e-dirty #475
 [   70.214216] Hardware name: Freescale i.MX6 SoloX (Device Tree)
 [   70.220064] Backtrace: 
 [   70.222585] [800142e4] (dump_backtrace) from [800144d8] 
 (show_stack+0x18/0x1c)
 [   70.230176]  r6:80b39960 r5: r4: r3:
 [   70.235965] [800144c0] (show_stack) from [807d2d58] 
 (dump_stack+0x8c/0xa4)
 [   70.243231] [807d2ccc] (dump_stack) from [8006e184] 
 (__lock_acquire+0x1d24/0x1ecc)
 [   70.251164]  r6: r5: r4:80cc3188 r3:0001
 [   70.256947] [8006c460] (__lock_acquire) from [8006ec04] 
 (lock_acquire+0x74/0x94)
 [   70.264706]  r10:bcf73f80 r9:bd7d290c r8:bbd5fe80 r7:0001 r6:804cc2ec 
 r5:60010093
 [   70.272669]  r4:
 [   70.275254] [8006eb90] (lock_acquire) from [807dc618] 
 (_raw_spin_lock_irqsave+0x48/0x5c)
 [   70.283707]  r7:bdbba010 r6:804cc2ec r5:80010013 r4:bdbba28c
 [   70.289494] [807dc5d0] (_raw_spin_lock_irqsave) from [804cc2ec] 
 (store_uframe_periodic_max+0x4c/0x12c)
 [   70.299164]  r6:bbd5fe80 r5:bdbba28c r4:0004
 [   70.303881] [804cc2a0] (store_uframe_periodic_max) from [803dae98] 
 (dev_attr_store+0x20/0x2c)
 [   70.312768]  r7: r6:bbd5fe80 r5:bd7d2900 r4:0004
 [   70.318549] [803dae78] (dev_attr_store) from [80172d24] 
 (sysfs_kf_write+0x54/0x58)
 [   70.326494] [80172cd0] (sysfs_kf_write) from [80171f10] 
 (kernfs_fop_write+0xc4/0x1a8)
 [   70.334686]  r6: r5:0004 r4:bd7d2900 r3:80172cd0
 [   70.340471] [80171e4c] (kernfs_fop_write) from [80103f44] 
 (__vfs_write+0x2c/0xe0)
 [   70.348316]  r10: r9:bcf72000 r8:80010844 r7:bcf73f80 r6:0169d408 
 r5:bcf73f80
 [   70.356278]  r4:bcdad500
 [   70.358863] [80103f18] (__vfs_write) from [801047e8] 
 (vfs_write+0x98/0x16c)
 [   70.366187]  r8:80010844 r7:bcf73f80 r6:0169d408 r5:0004 r4:bcdad500
 [   70.373029] [80104750] (vfs_write) from [80105064] 
 (SyS_write+0x4c/0xa8)
 [   70.380092]  r8:80010844 r7:0169d408 r6:0004 r5:bcdad500 r4:bcdad500
 [   70.386941] [80105018] (SyS_write) from [80010660] 
 (ret_fast_syscall+0x0/0x54)
 [   70.394525]  r7:0004 r6:76f95b48 r5:0169d408 r4:0004
 [   70.400307] ci_hdrc ci_hdrc.1: setting max periodic bandwidth to 84% (== 
 105 usec/uframe)
 [   70.408507] ci_hdrc ci_hdrc.1: max periodic bandwidth set is non-standard

I don't understand this either.

Maybe Peter Z. can help.  This dump is triggered by the
spin_lock_irqsave() call in
drivers/usb/host/ehci-sysfs.c:store_uframe_periodic_max().  That
function doesn't appear to be unusual in any way.

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 1/1] usb: host: ehci-sys: delete useless bus_to_hcd conversion

2015-08-17 Thread Alan Stern 
On Mon, 17 Aug 2015, Peter Chen wrote:

 The ehci platform device's drvdata is the pointer of struct usb_hcd
 already, so we doesn't need to call bus_to_hcd conversion again.
 
 Cc: sta...@vger.kernel.org
 Signed-off-by: Peter Chen peter.c...@freescale.com
 ---
  drivers/usb/host/ehci-sysfs.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/usb/host/ehci-sysfs.c b/drivers/usb/host/ehci-sysfs.c
 index 5e44407..5216f2b 100644
 --- a/drivers/usb/host/ehci-sysfs.c
 +++ b/drivers/usb/host/ehci-sysfs.c
 @@ -29,7 +29,7 @@ static ssize_t show_companion(struct device *dev,
   int count = PAGE_SIZE;
   char*ptr = buf;
  
 - ehci = hcd_to_ehci(bus_to_hcd(dev_get_drvdata(dev)));
 + ehci = hcd_to_ehci(dev_get_drvdata(dev));
   nports = HCS_N_PORTS(ehci-hcs_params);
  
   for (index = 0; index  nports; ++index) {
 @@ -54,7 +54,7 @@ static ssize_t store_companion(struct device *dev,
   struct ehci_hcd *ehci;
   int portnum, new_owner;
  
 - ehci = hcd_to_ehci(bus_to_hcd(dev_get_drvdata(dev)));
 + ehci = hcd_to_ehci(dev_get_drvdata(dev));
   new_owner = PORT_OWNER; /* Owned by companion */
   if (sscanf(buf, %d, portnum) != 1)
   return -EINVAL;
 @@ -85,7 +85,7 @@ static ssize_t show_uframe_periodic_max(struct device *dev,
   struct ehci_hcd *ehci;
   int n;
  
 - ehci = hcd_to_ehci(bus_to_hcd(dev_get_drvdata(dev)));
 + ehci = hcd_to_ehci(dev_get_drvdata(dev));
   n = scnprintf(buf, PAGE_SIZE, %d\n, ehci-uframe_periodic_max);
   return n;
  }
 @@ -101,7 +101,7 @@ static ssize_t store_uframe_periodic_max(struct device 
 *dev,
   unsigned long   flags;
   ssize_t ret;
  
 - ehci = hcd_to_ehci(bus_to_hcd(dev_get_drvdata(dev)));
 + ehci = hcd_to_ehci(dev_get_drvdata(dev));
   if (kstrtouint(buf, 0, uframe_periodic_max)  0)
   return -EINVAL;

Acked-by: Alan Stern st...@rowland.harvard.edu

This does indeed look like a strange mistake.  It worked only because
the embedded usb_bus structure lies at the start of the usb_hcd
structure.

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] usb: dwc3: pci: passing forward the ACPI companion

2015-08-17 Thread Felipe Balbi 
On Mon, Aug 17, 2015 at 02:32:06PM +0300, Heikki Krogerus wrote:
 Sharing the APCI companion with the core platforms device so
  
  ACPI :-)

 it has access to all DWC3's resources.

and which resources are these ? and why can't they be abstrated out in
dwc3-pci ?

 Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
 ---
  drivers/usb/dwc3/dwc3-pci.c | 1 +
  1 file changed, 1 insertion(+)
 
 Hi,
 
 This depends on being able to prevent execution of ACPI power methods
 more then once. Mika has made a patch for that:
 https://git.kernel.org/cgit/linux/kernel/git/lee/mfd.git/commit/?h=for-mfd-nextid=712e960f0ee9337f3473ba3de2bcfc7e87b7c5a4
 
 
 Thanks,
 
 diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
 index f626179..89eb364 100644
 --- a/drivers/usb/dwc3/dwc3-pci.c
 +++ b/drivers/usb/dwc3/dwc3-pci.c
 @@ -154,6 +154,7 @@ static int dwc3_pci_probe(struct pci_dev *pci,
   goto err;
  
   dwc3-dev.parent = dev;
 + ACPI_COMPANION_SET(dwc3-dev, ACPI_COMPANION(dev));
  
   ret = platform_device_add(dwc3);
   if (ret) {
 -- 
 2.5.0
 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: chipidea: reuse the platform_data to store the ci info

2015-08-17 Thread Alan Stern 
On Mon, 17 Aug 2015, Peter Chen wrote:

  That's not quite what I had in mind.  I was thinking of something more 
  like this:
  
  Platform device  drvdata  struct usb_pointers
  |
  |
  |---|---|
  |   |   |
gadget   hcd otg
  
  where struct usb_pointers (maybe you can think of a better name) looks 
  like this:
  
  struct usb_pointers {
  struct usb_hcd  *hcd;
  struct usb_gadget   *gadget;
  struct usb_otg  *otg;
  };
  
  If you want, you can use your IP Core device in place of my platform
  device.  All that matters is that the parent device of the root hub
  (for hosts) or gadget (for peripherals) should store the address of a 
  usb_pointers structure in its drvdata.
  
 
 I am wonder how you get hcd pointer at hcd core code? The platform
 device drvdata is not hcd pointer any more, instead, it is platform
 device private data.

The platform device private data will now be a usb_pointers structure.  
The hcd core code will simply do:

struct usb_pointers *usbptr = platform_get_drvdata(dev);
hcd = usbptr-hcd;

We can allocate some extra space at the end of the usb_pointers
structure if the platform/glue driver wants to store additional data in
there.

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 v2 3/3] power: wm831x_power: Support USB charger current limit management

2015-08-17 Thread Mark Brown 
On Mon, Aug 17, 2015 at 06:58:16PM -0500, Felipe Balbi wrote:
 On Mon, Aug 17, 2015 at 10:26:23AM -0700, Mark Brown wrote:
  On Mon, Aug 17, 2015 at 09:07:08AM +0800, Peter Chen wrote:
   On Fri, Aug 14, 2015 at 05:47:46PM +0800, Baolin Wang wrote:

+   if (wm831x_pdata  wm831x_pdata-usb_gadget) {

   Where the wm831x_pdata-usb_gadget is initialized?

  It's platform data, it will be initialised by whatever registers the
  platform data.

 passing pointers through pdata ?

It's a char * to a name, not a pointer to struct.


signature.asc
Description: Digital signature

[PATCH 2/2] USB: usb_wwan: silence read errors on disconnect

2015-08-17 Thread Johan Hovold 
Silence read-urb resubmission errors when the device is going away.

Signed-off-by: Johan Hovold jo...@kernel.org
---
 drivers/usb/serial/usb_wwan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/serial/usb_wwan.c b/drivers/usb/serial/usb_wwan.c
index 2f805cb386a5..825305cb71d9 100644
--- a/drivers/usb/serial/usb_wwan.c
+++ b/drivers/usb/serial/usb_wwan.c
@@ -282,7 +282,7 @@ static void usb_wwan_indat_callback(struct urb *urb)
/* Resubmit urb so we continue receiving */
err = usb_submit_urb(urb, GFP_ATOMIC);
if (err) {
-   if (err != -EPERM) {
+   if (err != -EPERM  err != -ENODEV) {
dev_err(dev, %s: resubmit read urb failed. (%d)\n,
__func__, err);
/* busy also in error unless we are killed */
-- 
2.4.6

--
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: option: silence interrupt errors

2015-08-17 Thread Johan Hovold 
Avoid spamming the logs (e.g. with -EPROTO errors) when attempting to
resubmit the interrupt urb while a disconnect of an in-use device is
being processed.

Signed-off-by: Johan Hovold jo...@kernel.org
---
 drivers/usb/serial/option.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 983c911b3986..3992f7709b70 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1942,7 +1942,7 @@ static void option_instat_callback(struct urb *urb)
} else if (status == -ENOENT || status == -ESHUTDOWN) {
dev_dbg(dev, %s: urb stopped: %d\n, __func__, status);
} else
-   dev_err(dev, %s: error %d\n, __func__, status);
+   dev_dbg(dev, %s: error %d\n, __func__, status);
 
/* Resubmit urb so we continue receiving IRQ data */
if (status != -ESHUTDOWN  status != -ENOENT) {
-- 
2.4.6

--
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/2] USB: symbolserial: Use usb_get_serial_port_data

2015-08-17 Thread Greg KH 
On Mon, Aug 17, 2015 at 05:31:46PM +0200, Philipp Hachtmann wrote:
 The driver used usb_get_serial_data(port-serial) which compiled but resulted
 in a NULL pointer being returned (and subsequently used). I did not go deeper
 into this but I guess this is a regression.
 
 Signed-off-by: Philipp Hachtmann hac...@hachti.de
 ---
  drivers/usb/serial/symbolserial.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

Doh, obviously no one has used this driver in a long time, thanks for
these patches...

Johan, mind if I take these directly?

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: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management

2015-08-17 Thread Mark Brown 
On Mon, Aug 17, 2015 at 09:07:08AM +0800, Peter Chen wrote:
 On Fri, Aug 14, 2015 at 05:47:46PM +0800, Baolin Wang wrote:

  +   1500,
  +   1800,
  +   550,
  +};

 Why 550 is the last, but not 1800?

You'd have to ask the hardware engineers who designed the chip.  I
suspect it's because 550 was added at a late stage in the design process
but I'm basically just guessing there.

*/
  @@ -606,8 +646,31 @@ static int wm831x_power_probe(struct platform_device 
  *pdev)
  }
  }

  +   if (wm831x_pdata  wm831x_pdata-usb_gadget) {

 Where the wm831x_pdata-usb_gadget is initialized?

It's platform data, it will be initialised by whatever registers the
platform data.


signature.asc
Description: Digital signature

Re: [PATCH v2 2/3] gadget: Introduce the usb charger framework

2015-08-17 Thread Mark Brown 
On Mon, Aug 17, 2015 at 11:03:26AM +0800, Baolin Wang wrote:
 On 14 August 2015 at 23:27, Greg KH gre...@linuxfoundation.org wrote:
  On Fri, Aug 14, 2015 at 05:47:45PM +0800, Baolin Wang wrote:

  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License as published by
  + * the Free Software Foundation; either version 2 of the License, or
  + * (at your option) any later version.

  I have to ask, do you really mean any later version?

 I think I did not get your point, could you explain it detailedly?

Unlike a lot of userspace projects the kernel is normally just licensed
under GPLv2 without the option to relicense with a later version so the
...or any later version is a bit unusual.  There is some controversy
about some of the changes in GPLv3.


signature.asc
Description: Digital signature

Re: [PATCH 0/2] USB: option/usb_wwan: silence errors on disconnect

2015-08-17 Thread Johan Hovold 
On Mon, Aug 17, 2015 at 09:04:37AM -0700, Greg Kroah-Hartman wrote:
 On Mon, Aug 17, 2015 at 05:35:22PM +0200, Johan Hovold wrote:
  These patches prevent URB status and resubmission errors from being
  reported when an in-use device is being disconnected.
 
 These looks good to me, want me to add them to the patches you sent the
 pull request for so we can get them into 4.3-rc1?

That'd be great, thanks.

I have a couple of device id patches queued up as well. I'll just send
them on to you tomorrow.

Johan
--
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/2] USB: symbolserial: Use usb_get_serial_port_data

2015-08-17 Thread Johan Hovold 
On Mon, Aug 17, 2015 at 09:06:15AM -0700, Greg Kroah-Hartman wrote:
 On Mon, Aug 17, 2015 at 05:31:46PM +0200, Philipp Hachtmann wrote:
  The driver used usb_get_serial_data(port-serial) which compiled but 
  resulted
  in a NULL pointer being returned (and subsequently used). I did not go 
  deeper
  into this but I guess this is a regression.
  
  Signed-off-by: Philipp Hachtmann hac...@hachti.de
  ---
   drivers/usb/serial/symbolserial.c | 6 +++---
   1 file changed, 3 insertions(+), 3 deletions(-)
 
 Doh, obviously no one has used this driver in a long time, thanks for
 these patches...

Wow...

 Johan, mind if I take these directly?

Please do.

This one should be tagged:

Fixes: a85796ee5149 (USB: symbolserial: move private-data allocation to
port_probe)
Cc: stable sta...@vger.kernel.org # v3.10

And for both patches:

Acked-by: Johan Hovold jo...@kernel.org

Thanks,
Johan
--
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: dwc3: pci: passing forward the ACPI companion

2015-08-17 Thread David Cohen 
On Mon, Aug 17, 2015 at 08:41:19AM -0500, Felipe Balbi wrote:
 On Mon, Aug 17, 2015 at 02:32:06PM +0300, Heikki Krogerus wrote:
  Sharing the APCI companion with the core platforms device so
   
 ACPI :-)
 
  it has access to all DWC3's resources.
 
 and which resources are these ? and why can't they be abstrated out in
 dwc3-pci ?

I could think about USB phy devices on legacy BYT-CR products. But since
we got Heikki's ULPI bus we are able to move ACPI companion to their own
phy device on future.

BR, David

--
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: dwc3: pci: passing forward the ACPI companion

2015-08-17 Thread Felipe Balbi 
On Mon, Aug 17, 2015 at 10:26:53AM -0700, David Cohen wrote:
 On Mon, Aug 17, 2015 at 08:41:19AM -0500, Felipe Balbi wrote:
  On Mon, Aug 17, 2015 at 02:32:06PM +0300, Heikki Krogerus wrote:
   Sharing the APCI companion with the core platforms device so

ACPI :-)
  
   it has access to all DWC3's resources.
  
  and which resources are these ? and why can't they be abstrated out in
  dwc3-pci ?
 
 I could think about USB phy devices on legacy BYT-CR products. But since
 we got Heikki's ULPI bus we are able to move ACPI companion to their own
 phy device on future.

we need a better commit log explaining why this is really needed.

-- 
balbi


signature.asc
Description: Digital signature

Re: Stack dump when try to store uframe_periodic_max

2015-08-17 Thread Alan Stern 
On Mon, 17 Aug 2015, Peter Zijlstra wrote:

 On Mon, Aug 17, 2015 at 10:32:20AM -0400, Alan Stern wrote:
  On Mon, 17 Aug 2015, Peter Chen wrote:
  
   Hi Alan,
   
   When run echo 105   
   /sys/bus/platform/devices/ci_hdrc.1/uframe_periodic_max,
   if lockdep check is enabled, there is below dump, I am afraid it can't
   find how to fix it, the warning shows the key is not persistent.
   (see line 757, kernel/locking/lockdep.c).
   
   
   [   70.190430] INFO: trying to register non-static key.
   [   70.195437] the code is fine but needs lockdep annotation.
   [   70.200939] turning off the locking correctness validator.
 
  I don't understand this either.
  
  Maybe Peter Z. can help.  This dump is triggered by the
  spin_lock_irqsave() call in
  drivers/usb/host/ehci-sysfs.c:store_uframe_periodic_max().  That
  function doesn't appear to be unusual in any way.
 
 Can it happen this code is called before a corresponding
 spin_lock_init()?

No; the spinlock gets initialized in ehci_init() long before the sysfs
file is registered.

 Alternatively, memory corruption is an option. If something stomped on
 the lockdep state you can trigger this I suppose.

Can you suggest any particular debugging printk for Peter C. to try?

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 0/2] USB: option/usb_wwan: silence errors on disconnect

2015-08-17 Thread Greg KH 
On Mon, Aug 17, 2015 at 05:35:22PM +0200, Johan Hovold wrote:
 These patches prevent URB status and resubmission errors from being
 reported when an in-use device is being disconnected.

These looks good to me, want me to add them to the patches you sent the
pull request for so we can get them into 4.3-rc1?

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: external USB-Speaker and Not enough bandwidth for altsetting 1

2015-08-17 Thread Jakob Schürz 

Am 2015-08-04 um 08:14 schrieb Clemens Ladisch:

Alan Stern wrote:

On Sun, 2 Aug 2015, Jakob Schürz wrote:

P:  Vendor=138a ProdID=003f Rev= 1.04


Do you happen to know what this device is?


usb.ids says Validity Sensors VFS495 Fingerprint Reader.


Yes it's true. But I don't use this Finger-Print-Reader. (Even it 
doesn't work for me...)





Does it make any difference if you remove the Bluetooth radio and the
HP webcam?  They compete for bandwidth on the same bus as the AC209N
speakers.

In theory there should be plenty of bandwidth for all these devices to
run at the same time.


All these devices have (small) interrupt endpoints for some kind of
status reporting.  It might be possible that the sheer number of
periodically scheduled transactions overflows some limit in the firmware
or driver.


Sounds bad... :-(

Jakob Schürz

--
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: Stack dump when try to store uframe_periodic_max

2015-08-17 Thread Peter Zijlstra 
On Mon, Aug 17, 2015 at 10:32:20AM -0400, Alan Stern wrote:
 On Mon, 17 Aug 2015, Peter Chen wrote:
 
  Hi Alan,
  
  When run echo 105   
  /sys/bus/platform/devices/ci_hdrc.1/uframe_periodic_max,
  if lockdep check is enabled, there is below dump, I am afraid it can't
  find how to fix it, the warning shows the key is not persistent.
  (see line 757, kernel/locking/lockdep.c).
  
  
  [   70.190430] INFO: trying to register non-static key.
  [   70.195437] the code is fine but needs lockdep annotation.
  [   70.200939] turning off the locking correctness validator.

 I don't understand this either.
 
 Maybe Peter Z. can help.  This dump is triggered by the
 spin_lock_irqsave() call in
 drivers/usb/host/ehci-sysfs.c:store_uframe_periodic_max().  That
 function doesn't appear to be unusual in any way.

Can it happen this code is called before a corresponding
spin_lock_init()?

Alternatively, memory corruption is an option. If something stomped on
the lockdep state you can trigger this I suppose.
--
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: [Device-mainlining] [PATCH v2 2/3] gadget: Introduce the usb charger framework

2015-08-17 Thread Tim Bird 


On 08/16/2015 08:03 PM, Baolin Wang via device-mainlining wrote:
 On 14 August 2015 at 23:27, Greg KH gre...@linuxfoundation.org wrote:
 On Fri, Aug 14, 2015 at 05:47:45PM +0800, Baolin Wang wrote:
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.

 I have to ask, do you really mean any later version?

 
 I think I did not get your point, could you explain it detailedly?

The full kernel is licensed under v2 of the GPL only, not any later version.
See the second paragraph at the top of the COPYING file in the root directory
of the kernel source tree. There are differences on individual files, but
having this file allow any later version makes it different from much of
rest of the kernel.

Unless you have a specific reason to allow greater-than-V2 GPL licensing on this
file, you should change the licensing clause.  The following wording appears
to be pretty popular:

* 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.

  -- Tim
--
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: symbolserial: Use usb_get_serial_port_data

2015-08-17 Thread Philipp Hachtmann 
The driver used usb_get_serial_data(port-serial) which compiled but resulted
in a NULL pointer being returned (and subsequently used). I did not go deeper
into this but I guess this is a regression.

Signed-off-by: Philipp Hachtmann hac...@hachti.de
---
 drivers/usb/serial/symbolserial.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/serial/symbolserial.c 
b/drivers/usb/serial/symbolserial.c
index 8fceec7..6ed8044 100644
--- a/drivers/usb/serial/symbolserial.c
+++ b/drivers/usb/serial/symbolserial.c
@@ -94,7 +94,7 @@ exit:
 
 static int symbol_open(struct tty_struct *tty, struct usb_serial_port *port)
 {
-   struct symbol_private *priv = usb_get_serial_data(port-serial);
+   struct symbol_private *priv = usb_get_serial_port_data(port);
unsigned long flags;
int result = 0;
 
@@ -120,7 +120,7 @@ static void symbol_close(struct usb_serial_port *port)
 static void symbol_throttle(struct tty_struct *tty)
 {
struct usb_serial_port *port = tty-driver_data;
-   struct symbol_private *priv = usb_get_serial_data(port-serial);
+   struct symbol_private *priv = usb_get_serial_port_data(port);
 
spin_lock_irq(priv-lock);
priv-throttled = true;
@@ -130,7 +130,7 @@ static void symbol_throttle(struct tty_struct *tty)
 static void symbol_unthrottle(struct tty_struct *tty)
 {
struct usb_serial_port *port = tty-driver_data;
-   struct symbol_private *priv = usb_get_serial_data(port-serial);
+   struct symbol_private *priv = usb_get_serial_port_data(port);
int result;
bool was_throttled;
 
-- 
2.1.4

--
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 0/2] USB: symbolserial: Fix OOPS (regression) and data length

2015-08-17 Thread Philipp Hachtmann 
I bought a Symbol DS3508 2D imager barcode scanner, configured it to
behave as simple COM port, and my machine OOPSed immediately.

The result are the two attached patches. The first one is actually needed
to get the whole thing again without that nasty NULL pointer dereference.

The second patch makes the driver exclude useless zero bytes from the payload
data. I assume this could lead to discussions because I found (and removed)
a comment that says that the driver will send all data from the urb buffer to
the tty layer without taking the communicated length (from the scanner, in
the first byte of a buffer) into account.

For your amusement here's what happened to my machine before writing the first
patch:

[ 3801.712295] usb 6-2: new full-speed USB device number 12 using uhci_hcd
[ 3801.883708] usb 6-2: New USB device found, idVendor=05e0, idProduct=0600
[ 3801.883712] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3801.883714] usb 6-2: Product: Symbol Bar Code Scanner
[ 3801.883716] usb 6-2: Manufacturer: Symbol Technologies, Inc, 2008
[ 3801.883718] usb 6-2: SerialNumber: S/N:5520B838ED22C34CBC619E74103732B8 
Rev:PAAALS00-002-R01-
[ 3801.889804] symbolserial 6-2:1.0: symbol converter detected
[ 3801.889962] usb 6-2: symbol converter now attached to ttyUSB0
[ 3801.896738] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[ 3801.896741] IP: [817ef2ab] _raw_spin_lock_irqsave+0xb/0x30
[ 3801.896746] PGD 61fb5b067 PUD 6208dd067 PMD 0 
[ 3801.896748] Oops: 0002 [#1] SMP 
[ 3801.896749] Modules linked in: nvidia(O)
[ 3801.896751] CPU: 7 PID: 8640 Comm: ModemManager Tainted: G   O
4.2.0-rc7 #27
[ 3801.896752] Hardware name: System manufacturer System Product Name/P6T WS 
PRO, BIOS 120409/16/2010
[ 3801.896753] task: 88061daaba80 ti: 8800ba608000 task.ti: 
8800ba608000
[ 3801.896754] RIP: 0010:[817ef2ab]  [817ef2ab] 
_raw_spin_lock_irqsave+0xb/0x30
[ 3801.896756] RSP: 0018:8800ba60bba8  EFLAGS: 00010046
[ 3801.896757] RAX:  RBX: 0296 RCX: 8806220b4800
[ 3801.896757] RDX: 0001 RSI: 8806220b4800 RDI: 
[ 3801.896758] RBP: 8806220b4800 R08: 0001 R09: c94d6000
[ 3801.896759] R10: 3000 R11: c94d5fff R12: 880623832780
[ 3801.896759] R13: 880591b09000 R14: 880591b09000 R15: 88061daaba80
[ 3801.896760] FS:  7fc35e569840() GS:88063fce() 
knlGS:
[ 3801.896761] CS:  0010 DS:  ES:  CR0: 80050033
[ 3801.896762] CR2:  CR3: 00061df01000 CR4: 06e0
[ 3801.896762] Stack:
[ 3801.896763]   8153267b 8806243dd0a8 
8806220b4808
[ 3801.896764]  8806238327e8 81511cc6 880591b09000 
813c4b2e
[ 3801.896765]  880591b09000 8806220b4808 880591b09000 
8806220b4918
[ 3801.896766] Call Trace:
[ 3801.896769]  [8153267b] ? symbol_open+0x1b/0x70
[ 3801.896772]  [81511cc6] ? serial_port_activate+0x56/0x90
[ 3801.896775]  [813c4b2e] ? tty_port_tty_set+0x2e/0x90
[ 3801.896776]  [813c50c6] ? tty_port_open+0x76/0xc0
[ 3801.896778]  [813bd94f] ? tty_init_dev+0x8f/0x1a0
[ 3801.896779]  [813bdb55] ? tty_open+0xf5/0x5a0
[ 3801.896782]  [8118c2f0] ? mount_fs+0x160/0x160
[ 3801.896784]  [8118cabc] ? chrdev_open+0x9c/0x170
[ 3801.896785]  [8118ca20] ? cdev_put+0x20/0x20
[ 3801.896786]  [81186d00] ? do_dentry_open+0x1c0/0x2f0
[ 3801.896788]  [81194bd0] ? path_openat+0x380/0x1030
[ 3801.896789]  [81191982] ? terminate_walk+0xa2/0xb0
[ 3801.896790]  [81196a60] ? do_filp_open+0x70/0xd0
[ 3801.896792]  [811a1a97] ? __alloc_fd+0x37/0x100
[ 3801.896794]  [8118808e] ? do_sys_open+0x11e/0x200
[ 3801.896795]  [817ef617] ? entry_SYSCALL_64_fastpath+0x12/0x6a
[ 3801.896795] Code: 31 c0 ba 01 00 00 00 f0 0f b1 17 85 c0 75 02 f3 c3 89 c6 
e9 68 6d 91 ff 0f 1f 84 00 00 00 00 00 53 9c 5b fa 31 c0 ba 01 00 00 00 f0 0f 
b1 17 85 c0 75 05 48 89 d8 5b c3 89 c6 e8 41 6d 91 ff 48 
[ 3801.896809] RIP  [817ef2ab] _raw_spin_lock_irqsave+0xb/0x30
[ 3801.896811]  RSP 8800ba60bba8
[ 3801.896812] CR2: 
[ 3801.896813] ---[ end trace 196415182e1cd411 ]---


Philipp Hachtmann (2):
  USB: symbolserial: Use usb_get_serial_port_data
  USB: symbolserial: Correct transferred data size

 drivers/usb/serial/symbolserial.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

-- 
2.1.4

--
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: option driver crashes on modem removal

2015-08-17 Thread Johan Hovold 
On Tue, Aug 11, 2015 at 12:31:47PM +0200, Yegor Yefremov wrote:
 On Tue, Aug 11, 2015 at 11:58 AM, Bjørn Mork bj...@mork.no wrote:
  [replaced 'netdev' with 'linux-usb' as this concerns a USB serial driver 
  only]
 
  Yegor Yefremov yegorsli...@googlemail.com writes:
 
  I have following problem. When removing USB dongle 07d1:3e01 or
  SierraWireless MC7304 I get following messages:
 
  option1 ttyUSB10: option_instat_callback: error -71
  option1 ttyUSB9: option_instat_callback: error -71
  option1 ttyUSB10: option_instat_callback: error -71
  option1 ttyUSB9: option_instat_callback: error -71
  option1 ttyUSB10: option_instat_callback: error -71
  option1 ttyUSB9: option_instat_callback: error -71
  INFO: rcu_sched detected stalls on CPUs/tasks: {} (detected by 0,
  t=2102 jiffies, g=694, c=693, q=24)
  INFO: Stall ended before state dump start
  option1 ttyUSB10: option_instat_callback: error -71
 
  drivers/usb/serial/option.c seems to make nothing with such a status
  and just prints error. How one would handle this properly and just
  unregister device? Do you need more info?
 
  Tested kernels: 3.18.20 and 4.2.0-rc5 (this kernel shows only RCU stall 
  crash)
  Hardware: TI am335x
 
 
  Isn't the device unregistered?  What else can be done here?
 
 The problem is, that the system is dead (stall). It only prints
 option1 ttyUSB10: option_instat_callback: error -71 endlessly
 (kernel 3.18.20) and console shows no reaction for input. And when you
 start watchdog from userspace the systems reboots after specified
 timeout (watchdog -t 5 -T 10 /dev/watchdog).

Related issues have been reported with musb (BeagleBone Black) and dwc
controllers (RPi) when using an external hub.

The exact reasons have not yet been fully determined, including whether
it is the hub driver that is prevented from processing the event or if
the disconnect event is never received at all. See for example:

https://lkml.kernel.org/r/20150409171314.GA30002@localhost

In the cases I've seen, changing the timing slightly was enough to make
the problem go away. Specifically, avoiding a large, unnecessary memcpy
or silencing an error message was sufficient.

This obviously does not solve the underlying issue, but could you try
the below patch nonetheless? We don't want these error messages for the
valid use case of removing an in-use device anyway.

Thanks,
Johan


From 81913b6a91bd53b4f00455618c141c35148acbfc Mon Sep 17 00:00:00 2001
From: Johan Hovold jo...@kernel.org
Date: Mon, 17 Aug 2015 16:48:47 +0200
Subject: [PATCH] USB: option: silence interrupt errors

Avoid spamming the logs (e.g. with -EPROTO errors) when attempting to
resubmit the interrupt urb while a disconnect of an in-use device is
being processed.

Signed-off-by: Johan Hovold jo...@kernel.org
---
 drivers/usb/serial/option.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 983c911b3986..3992f7709b70 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1942,7 +1942,7 @@ static void option_instat_callback(struct urb *urb)
} else if (status == -ENOENT || status == -ESHUTDOWN) {
dev_dbg(dev, %s: urb stopped: %d\n, __func__, status);
} else
-   dev_err(dev, %s: error %d\n, __func__, status);
+   dev_dbg(dev, %s: error %d\n, __func__, status);
 
/* Resubmit urb so we continue receiving IRQ data */
if (status != -ESHUTDOWN  status != -ENOENT) {
-- 
2.4.6
--
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 v5 4/5] xhci: mediatek: support MTK xHCI host controller

2015-08-17 Thread Mathias Nyman 

Hi

On 07.08.2015 15:30, Chunfeng Yun wrote:

MTK xhci host controller defines some extra SW scheduling
parameters for HW to minimize the scheduling effort for
synchronous and interrupt endpoints. The parameters are
put into reseved DWs of slot context and endpoint context




...


+ * The TD size is the number of max packet sized packets remaining in the TD
+ * (including this TRB), right shifted by 10.
+ * It must fit in bits 21:17, so it can't be bigger than 31.
+ */
+u32 xhci_mtk_td_remainder_quirk(unsigned int td_running_total,
+   unsigned trb_buffer_length, struct urb *urb)
+{
+   u32 max = 31;
+   int remainder, td_packet_count, packet_transferred;
+   unsigned int td_transfer_size = urb-transfer_buffer_length;
+   unsigned int maxp;
+
+   maxp = GET_MAX_PACKET(usb_endpoint_maxp(urb-ep-desc));
+
+   /* 0 for the last TRB */
+   if (td_running_total + trb_buffer_length == td_transfer_size)
+   return 0;
+
+   packet_transferred = td_running_total / maxp;
+   td_packet_count = DIV_ROUND_UP(td_transfer_size, maxp);
+   remainder = td_packet_count - packet_transferred;
+
+   if (remainder  max)
+   return max  17;
+   else
+   return remainder  17;
+}


I started looking at this xhci_mtk_td_remainder() function, one
of the places this patch touches the existing xhci code.

The remainder functions in xhci are already bit too messy, and
adding one more function which does almost the same thing makes
it even messier.

For example queuing a bulk transfer will end up like this:


/* Set the TRB length, TD size, and interrupter fields. */
if (xhci-hci_version  0x100) {
-   remainder = xhci_td_remainder(
+   if (xhci-quirks  XHCI_MTK_HOST) {
+   remainder = xhci_mtk_td_remainder_quirk(
+   running_total, trb_buff_len, urb);
+   } else {
+   remainder = xhci_td_remainder(
urb-transfer_buffer_length -
running_total);
+   }
} else {
remainder = xhci_v1_0_td_remainder(running_total,
trb_buff_len, total_packet_count, urb,


and similar for isoc and control transfers.

I'll see if I can simplify the existing remainder calculations into one 
function, then it should
be enough to just add something like this into it:

if (xhci-quirks  XHCI_MTK_HOST)
trb_buff_len = 0;

This way we can skip all the extra hassle that comes with a new exported quirk 
function

Is the Mediatek xhci really a xHCI 0.96 or older controller? (hci_version  
0x100)
Not a xHCI 1.0 or 1.1 ?

-Mathias
--
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: [GIT PULL] USB-serial updates for v4.3-rc1

2015-08-17 Thread Greg Kroah-Hartman 
On Mon, Aug 17, 2015 at 12:00:42PM +0200, Johan Hovold wrote:
 Hi Greg,
 
 Here are my updates for v4.3-rc1. All have been in linux-next for some
 time.
 
 Thanks,
 Johan
 
 
 The following changes since commit 52721d9d3334c1cb1f76219a161084094ec634dc:
 
   Linux 4.2-rc3 (2015-07-19 14:45:02 -0700)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
 tags/usb-serial-4.3-rc1

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

[PATCH 0/2] USB: option/usb_wwan: silence errors on disconnect

2015-08-17 Thread Johan Hovold 
These patches prevent URB status and resubmission errors from being
reported when an in-use device is being disconnected.

Johan


Johan Hovold (2):
  USB: option: silence interrupt errors
  USB: usb_wwan: silence read errors on disconnect

 drivers/usb/serial/option.c   | 2 +-
 drivers/usb/serial/usb_wwan.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.4.6

--
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: symbolserial: Correct transferred data size

2015-08-17 Thread Philipp Hachtmann 
The scanner (here DS3508) always returns 64 bytes per urb buffer. The first
byte indicates the data length used in the current buffer. There even was
a comment describing this. But the comment also said that we'll send
everything in the buffer to the tty layer. That means sending the actual
barcode data and lots of trailing zeroes. This patch lets the driver only
send the real data.

Signed-off-by: Philipp Hachtmann hac...@hachti.de
---
 drivers/usb/serial/symbolserial.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/serial/symbolserial.c 
b/drivers/usb/serial/symbolserial.c
index 6ed8044..37f3ad1 100644
--- a/drivers/usb/serial/symbolserial.c
+++ b/drivers/usb/serial/symbolserial.c
@@ -60,17 +60,15 @@ static void symbol_int_callback(struct urb *urb)
 
usb_serial_debug_data(port-dev, __func__, urb-actual_length, data);
 
+   /*
+* Data from the device comes with a 1 byte header:
+*
+* size of data data...
+*/
if (urb-actual_length  1) {
-   data_length = urb-actual_length - 1;
-
-   /*
-* Data from the device comes with a 1 byte header:
-*
-* size of datadata...
-*  This is real data to be sent to the tty layer
-* we pretty much just ignore the size and send everything
-* else to the tty layer.
-*/
+   data_length = data[0];
+   if (data_length  (urb-actual_length - 1))
+   data_length = urb-actual_length - 1;
tty_insert_flip_string(port-port, data[1], data_length);
tty_flip_buffer_push(port-port);
} else {
-- 
2.1.4

--
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 v9 1/7] usb: interface authorization: Declare authorized attribute

2015-08-17 Thread Greg KH 
On Sat, Aug 08, 2015 at 11:32:50AM +0200, Stefan Koch wrote:
 The attribute authorized shows the authorization state for an interface.
 
 Signed-off-by: Stefan Koch sk...@suse.de

This email bounces, so I have to rip this series out of the tree :(

Please resend this with a working email for a signed-off-by line.

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 v2 0/3] Introduce usb charger framework to deal with the usb gadget power negotation

2015-08-17 Thread Baolin Wang 
On 17 August 2015 at 09:15, Li Jun b47...@freescale.com wrote:
 On Fri, Aug 14, 2015 at 07:04:56PM +0800, Baolin Wang wrote:
 On 14 August 2015 at 16:55, Li Jun b47...@freescale.com wrote:
  Hi Baolin,
 
  On Fri, Aug 14, 2015 at 05:47:43PM +0800, Baolin Wang wrote:
  Currently the Linux kernel does not provide any standard integration of 
  this
  feature that integrates the USB subsystem with the system power regulation
  provided by PMICs meaning that either vendors must add this in their 
  kernels
  or USB gadget devices based on Linux (such as mobile phones) may not 
  behave
  as they should.
 
  Providing a standard framework for doing this in the kernel.
 
 
  Why not add power supply class support into this?
 

 Hi Jun,

 We don't need the power supply class support into the usb charger,
 I suppose usb charger is also a power supply for the system, we can use power
 supply class framework for notify mechanism and get/set many attributes(maybe
 also the current limit), I see those usb charger drivers under ./driver/power/
 are designed with power supply supported.


I don't think so. The usb charger is rely on the usb gadget, which is
not a complete power supply device and it combines the usb and the
power supply. Thus we make it into usb gadget system. Thanks.

 Li Jun
 just introduce the notify mechanism for power to set the current limit
 when notifying some events from usb charger. Maybe I misunderstand
 your meanings, please describe it detailedly. Thanks for your
 comments.

  Li Jun
 



 --
 Baolin.wang
 Best Regards



-- 
Baolin.wang
Best Regards
--
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