Re: [Bug 100631] Usb device not functioning in initramfs luks disk unlock

[Glasswall Information Point]

Op 29-06-15 om 19:01 schreef bugzilla-dae...@bugzilla.kernel.org:
> https://bugzilla.kernel.org/show_bug.cgi?id=100631
> 
> --- Comment #1 from Greg Kroah-Hartman  ---
> On Mon, Jun 29, 2015 at 09:53:04AM +, bugzilla-dae...@bugzilla.kernel.org
> wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=100631
>>
>> Bug ID: 100631
>>Summary: Usb device not functioning in initramfs luks disk
>> unlock
> 
> Please send to the linux-usb@vger.kernel.org mailing list.
> 
--
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: Errata for Freescale root-hub TT?

[Peter Chen]

 
> Le Mon, 29 Jun 2015 16:40:52 +0800,
> Peter Chen  a écrit :
> 
> > I am not sure if you have noticed the patch[1], it is the solution for
> > this issue, in the RTL, the default reserved time for one packet is
> > 1023 bytes for siTD, so after 4 * 64 packets has transfered, the
> > reserved time is not enough for 1023 bytes packet.
> >
> > This issue should exist at all ARC/Chipidea cores.
> In that case can't we enable the patch for all cores instead of using platform
> data flags ?
> 
 
Hi Matthieu

This bit may also affects QH, we only make sure Freescale's part QH design
does not be affected by this tt ctrl bits, but doesn't know other vender's.

Peter

Re: Errata for Freescale root-hub TT?

[Matthieu CASTET]

Hi Peter,


Le Mon, 29 Jun 2015 16:40:52 +0800,
Peter Chen  a écrit :

> I am not sure if you have noticed the patch[1], it is the solution for
> this issue, in the RTL, the default reserved time for one packet is
> 1023 bytes for siTD, so after 4 * 64 packets has transfered, the
> reserved time is not enough for 1023 bytes packet.
> 
> This issue should exist at all ARC/Chipidea cores.
In that case can't we enable the patch for all cores instead of using
platform data flags ?


Matthieu 
--
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 RFC] 2/2 huawei_cdc_ncm: introduce new TX ncm stack

[Enrico Mioso]

Ok, for now I should let go of this - might be it was a little bit too much for 
the time constaints I am having.

But thank you for your effort Oliver.
Anyway, trying to write this new TX engine helped me in understand better 
things and conceive the patch I sent you affecting cdc_ncm.c, which triggers 
some OOPSes but not in a qemu vm, so I can't read them actually.


Any hint on my code is always apreciated, regardless.
Enrico
--
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

About zero-length packet design for EHCI

[Peter Chen]

Hi Alan,

When reading the code (at qh_urb_transaction) about zero-length packet
for EHCI, would you please help me on below questions:

- I have not found the zero-length qtd prepared for control read (eg,
the transfer size is multiple of wMaxPacketSize), Am I missing
something?

- Why the IN transfer doesn't need to prepare zero-length qtd?
In the 2.0 spec, it does not say it is only for OUT.

Ch 5.7.3 & Ch 5.8.3
A bulk (interrupt) transfer is complete when the endpoint does one of the 
following:
- Has transferred exactly the amount of data expected
- Transfers a packet with a payload size less than wMaxPacketSize or
transfers a zero-length packet

Ch 5.6.4
An isochronous IN endpoint must return a zero-length packet whenever
data is requested at a faster interval
than the specified interval and data is not available.

Thanks.

-- 

Best Regards,
Peter Chen
--
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: Official bugreport 4.1 kernel (audio gadget and ChipIdea)

[Marek Vasut]

On Tuesday, June 30, 2015 at 04:23:01 AM, Peter Chen wrote:
> On Fri, Jun 26, 2015 at 07:15:18PM +0200, Sébastien Pruvost wrote:
> > Hello,
> > 
> > I'm sending this mail to report a bug concerning the latest kernel 4.1.
> > 
> > Here is the problem (and the test I've done):
> > I have firstly used the 3.10.53 kernel for my two
> > sabrelites in
> > 
> > order to use the audio gadget driver with the Dual Role ChipIdea
> > Controller (in order to switch roles between my two IMX6 sabreLite).
> > After loading g_audio in my two sabreLite and plugging the cable (microA
> > – microB), there is an error “ci_hdrc.0 request length too big for
> > isochronous snd_uac2.0 1116 Error”.
> > And even after running aplay command, I still got this error and there is
> > no sound getting out of the jack port.
> > I've switched roles between the two boards by following this: https://
> > www.kernel.org/doc/Documentation/usb/chipidea.txt.
> > This works fine with the serial driver, I can see a new serial interface
> > (host side) and after switching role a new serial interfaces at device
> > side. Same thing for ethernet gadget: this works fine too. But not with
> > the audio gadget. In fact, there is a new audio interface at host side
> > but I can not interact with it (even alsamixer doesn’t see any controls
> > on this new sound card). I’ve tested that audio gadget works fine if I
> > don’t use ChipIdea HighSpeed Dual Role Controller.
> > 
> > Secondly I have tested this audio gadget with the latest
> > Kernel
> > 
> > 4.1 for my two IMX6 sabrelites (imx_v6_v7_defconfig). Now these previous
> > errors are gone but there are still no sound getting out of the jack
> > port (even if there are a new sound card in host side)
> 
> It is may not a role switch problem, please check if the g_audio can
> work well with an ubuntu PC (make sure your codec works well).

ci_hdrc.0 request length too big for isochronous

Doesn't this just mean it cannot transfer such a long buffer via ISO pipe ?
I guess the UAC should send smaller buffers to work with the CI HDRC?

Best regards,
Marek Vasut
--
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

[EDT][PATCH] USB XHCI: Bugfix for NULL pointer deference in xhci_endpoint_init() function

[AMAN DEEP]

EP-D52BC23FD00D4E2BBEED88BA6AF8C4AC 

virt_dev->num_cached_rings counts on freed ring and 
is not updated correctly. In xhci_free_or_cache_endpoint_ring() function, 
the free ring is added into cache and then 
num_rings_cache is incremented as below:
virt_dev->ring_cache[rings_cached] =
virt_dev->eps[ep_index].ring;
virt_dev->num_rings_cached++;
here, free ring pointer is added to a current index and then 
index is incremented.
So current index always points to empty location in the ring cache.
For getting available free ring, 
current index should be decremented first and then
corresponding ring buffer value should be taken from ring cache.

But In function xhci_endpoint_init(), 
the num_rings_cached index is accessed before decrement.
virt_dev->eps[ep_index].new_ring =
virt_dev->ring_cache[virt_dev->num_rings_cached];
virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
virt_dev->num_rings_cached--;
This is bug in manipulating the index of ring cache.
And it should be as below:
virt_dev->num_rings_cached--;
virt_dev->eps[ep_index].new_ring =
virt_dev->ring_cache[virt_dev->num_rings_cached];
virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;

Signed-off-by: Aman Deep 
---
 drivers/usb/host/xhci-mem.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index f833640..3e442f7 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1427,10 +1427,10 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
/* Attempt to use the ring cache */
if (virt_dev->num_rings_cached == 0)
return -ENOMEM;
+   virt_dev->num_rings_cached--;
virt_dev->eps[ep_index].new_ring =
virt_dev->ring_cache[virt_dev->num_rings_cached];
virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
-   virt_dev->num_rings_cached--;
xhci_reinit_cached_ring(xhci, virt_dev->eps[ep_index].new_ring,
1, type);
}
-- 
1.7.9.5

[PATCH] usb: move assignment out of if condition

[Kris Borer]

Fix four occurrences of the checkpatch.pl error:

ERROR: do not use assignment in if condition

Signed-off-by: Kris Borer 
---
 drivers/usb/core/hcd.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index be5b207..e268c45 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2683,12 +2683,13 @@ int usb_add_hcd(struct usb_hcd *hcd,
 * bottom up so that hcds can customize the root hubs before hub_wq
 * starts talking to them.  (Note, bus id is assigned early too.)
 */
-   if ((retval = hcd_buffer_create(hcd)) != 0) {
+   retval = hcd_buffer_create(hcd);
+   if (retval != 0) {
dev_dbg(hcd->self.controller, "pool alloc failed\n");
goto err_create_buf;
}
-
-   if ((retval = usb_register_bus(&hcd->self)) < 0)
+   retval = usb_register_bus(&hcd->self);
+   if (retval < 0)
goto err_register_bus;
 
rhdev = usb_alloc_dev(NULL, &hcd->self, 0);
@@ -2734,7 +2735,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
/* "reset" is misnamed; its role is now one-time init. the controller
 * should already have been reset (and boot firmware kicked off etc).
 */
-   if (hcd->driver->reset && (retval = hcd->driver->reset(hcd)) < 0) {
+   retval = hcd->driver->reset(hcd);
+   if (hcd->driver->reset && retval < 0) {
dev_err(hcd->self.controller, "can't setup: %d\n", retval);
goto err_hcd_driver_setup;
}
@@ -2766,7 +2768,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
}
 
/* starting here, usbcore will pay attention to this root hub */
-   if ((retval = register_root_hub(hcd)) != 0)
+   retval = register_root_hub(hcd);
+   if (retval != 0)
goto err_register_root_hub;
 
retval = sysfs_create_group(&rhdev->dev.kobj, &usb_bus_attr_group);
-- 
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] usb: move assignment out of if condition

[Sergei Shtylyov]

Hello.

On 6/30/2015 4:02 PM, Kris Borer wrote:


Fix four occurrences of the checkpatch.pl error:



ERROR: do not use assignment in if condition



Signed-off-by: Kris Borer 
---
  drivers/usb/core/hcd.c | 13 -
  1 file changed, 8 insertions(+), 5 deletions(-)



diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index be5b207..e268c45 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c

[...]

@@ -2734,7 +2735,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
/* "reset" is misnamed; its role is now one-time init. the controller
 * should already have been reset (and boot firmware kicked off etc).
 */
-   if (hcd->driver->reset && (retval = hcd->driver->reset(hcd)) < 0) {
+   retval = hcd->driver->reset(hcd);
+   if (hcd->driver->reset && retval < 0) {


   If hcd->driver->reset() is NULL, this change warrants a kernel oops.

[...]

WBR, Sergei

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

Re: [PATCH] usb: move assignment out of if condition

[Oliver Neukum]

On Tue, 2015-06-30 at 09:02 -0400, Kris Borer wrote:
> Fix four occurrences of the checkpatch.pl error:
> 
> ERROR: do not use assignment in if condition
> 
> Signed-off-by: Kris Borer 

Sorry, but NACK!
Those patches are totally broken.

> ---
>  drivers/usb/core/hcd.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index be5b207..e268c45 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -2683,12 +2683,13 @@ int usb_add_hcd(struct usb_hcd *hcd,
>* bottom up so that hcds can customize the root hubs before hub_wq
>* starts talking to them.  (Note, bus id is assigned early too.)
>*/
> - if ((retval = hcd_buffer_create(hcd)) != 0) {
> + retval = hcd_buffer_create(hcd);
> + if (retval != 0) {
>   dev_dbg(hcd->self.controller, "pool alloc failed\n");
>   goto err_create_buf;
>   }
> -
> - if ((retval = usb_register_bus(&hcd->self)) < 0)
> + retval = usb_register_bus(&hcd->self);
> + if (retval < 0)
>   goto err_register_bus;
>  
>   rhdev = usb_alloc_dev(NULL, &hcd->self, 0);
> @@ -2734,7 +2735,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
>   /* "reset" is misnamed; its role is now one-time init. the controller
>* should already have been reset (and boot firmware kicked off etc).
>*/
> - if (hcd->driver->reset && (retval = hcd->driver->reset(hcd)) < 0) {
> + retval = hcd->driver->reset(hcd);

You happily follow the NULL pointer.

Regards
Oliver


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

Re: [PATCH v2] usb: xhci: Add support for URB_ZERO_PACKET to bulk/sg transfers

[Mathias Nyman]

Hi

On 30.06.2015 04:54, Reyad Attiyat wrote:
> Hey Mathias,
> 
> The intention is to send an extra endpoint packet of length zero as my
> wireless card needs this to function properly. I have skimmed through
> the xhci spec and assumed that each td would generate a packet. That
> is why I do not chain the last trb or add a interrupt flag, since I
> don't want to call the urb completion function called twice or called
> with the incorrect td or length.

I just found in xhci 1.0 spec section 4.9.1 that "To generate a zero-length
USB transaction software shall explicitly define a TD with a single transfer
TRB, and its TRB transfer length field shall equal 0"

So with this in mind your approach was correct, we shouldn't chain the last
data containing TRB with the zero TRB. This way xhci treats it as a separate TD.

Xhci controller thinks we have two TDs, while the driver only sees one TD.
This TD will interrupt in the middle, and has transferred all data before its 
last TRB.
I suspect that this may cause some issues, especially if we stop at the zero trb
and the driver has already returned the URB before the last TRB is handled.  

If we continue with this option we need to make sure handle_tx_events(),
process_bulk_intr_td() and finish_td() work with with a SUCCESS bulk transfer
event in the middle of a TD. and that an transfer event for the zero transfer
received after URB is already returned doesn't mess anything up.

As the xhci specs in 4.9.1 requires us to define a TD with a single TRB for
the zero-packet, I think it would be better to add an additional TD to the bulk 
URB.

Then we should check if we need a zero transfer already in xchi_urb_enqueue(),
and make sure it allocates one more TD (doing size++ should be enough), and 
make sure
xhci_queue_bulk_tx() can handle bulk URBs with two TDs.

> 
> I have since tried a patch that just chains the trbs together, with
> the zero-length trb, and this still creates a zero-length packet. I
> was thinking I could remove the use of the last_trb variable I was
> using and simply chain all the trbs together and place the interupt
> flag on the zero-length trb if it exsits. Also I noticed that the
> other host controller drivers (ehci and ohci) check to ensure that the
> endpoint is sending data out and that the urb length is greater than
> zero. I will add these checks as well to keep in line with the their
> implementation.
> 

Adding the direction out check would be good.

> Do you think this is the best method for creating a zero-length
> packet, will every trb convert into at least one endpoint packet?

I think adding a new TD for the zero length transfer would be the best option.
This way we follow the specs. I started looking at zero-packet bulk issue
only after your first patch, so there might be many things I haven't taken into
consideration yet.

-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

[PATCH] usb: host: xhci: remove typo in function documentation

[Luis de Bethencourt]

Fix "though" to "through" in documentation of xhci_alloc_streams().

Signed-off-by: Luis de Bethencourt 
---
 drivers/usb/host/xhci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 7da0d60..e66857f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3117,7 +3117,7 @@ static u32 xhci_calculate_no_streams_bitmask(struct 
xhci_hcd *xhci,
 }
 
 /*
- * The USB device drivers use this function (though the HCD interface in USB
+ * The USB device drivers use this function (through the HCD interface in USB
  * core) to prepare a set of bulk endpoints to use streams.  Streams are used 
to
  * coordinate mass storage command queueing across multiple endpoints 
(basically
  * a stream ID == a task ID).
-- 
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

self-modeswitching device

[Oliver Neukum]

Hi,

I am looking at a device that spontaneously switches
its mode. I guess that you need to actively do something
that some Windows versions do to keep the device in its
initial mode.
The device contains an SD card reader. That leaves me in
a predicament. The medium if it is mounted before the
device switches will be dirty.

Normally we say that unmounting before you switch
is a responsibility of user space. But this device
switches by itself.
In that particular case I would go as far as make
the storage driver refuse the storage interface
of the initial mode.

What do you think?

Regards
Oliver


--
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: move assignment out of if condition

[Greg KH]

On Tue, Jun 30, 2015 at 09:02:22AM -0400, Kris Borer wrote:
> Fix four occurrences of the checkpatch.pl error:
> 
> ERROR: do not use assignment in if condition

If you are going to do stuff like this, use Coccinelle so you are sure
you don't break the code.

Also always test your changes, if possible.

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][RFC] usbhid: enable autosuspend for internal devices

[Alan Stern]

On Sat, 27 Jun 2015, Greg Kroah-Hartman wrote:

> On Fri, Jun 26, 2015 at 09:20:19PM -0400, Alan Stern wrote:
> > My Apple keyboard isn't here at the moment, and I don't remember
> > exactly what its hub descriptor contains.  In theory, it _should_ mark
> > the permanently attached port as non-removable.
> > 
> > I can test it next week, if you would like to see the actual values.
> 
> That would be great.

Here we go:

# lsusb -v -s 3:4

Bus 003 Device 004: ID 05ac:1002 Apple, Inc. Extended Keyboard Hub [Mitsumi]
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize0 8
  idVendor   0x05ac Apple, Inc.
  idProduct  0x1002 Extended Keyboard Hub [Mitsumi]
  bcdDevice1.22
  iManufacturer   1 Mitsumi Electric
  iProduct2 Hub in Apple Extended USB Keyboard
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower   50mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0001  1x 1 bytes
bInterval 255
Hub Descriptor:
  bLength   9
  bDescriptorType  41
  nNbrPorts 3
  wHubCharacteristic 0x0004
Ganged power switching
Compound device
Ganged overcurrent protection
  bPwrOn2PwrGood   22 * 2 milli seconds
  bHubContrCurrent 50 milli Ampere
  DeviceRemovable0x02
  PortPwrCtrlMask0xff
 Hub Port Status:
   Port 1: .0103 power enable connect
   Port 2: .0100 power
   Port 3: .0100 power
Device Status: 0x
  (Bus Powered)

As you can see, the hub descriptor says that the hub is part of a 
compound device.  Port 1 is attached to the internal keyboard 
controller, so it is connected and enabled, whereas the other two ports 
don't have anything plugged in right now.

Most importantly, the DeviceRemovable bitmask is set to 0x02.  Since 
bit 0 is reserved, the bit that is set corresponds to port 1.  It is 
set to indicate that the port is non-removable (i.e., the meaning is 
the opposite of what the name suggests).  And sure enough:

$ cat /sys/bus/usb/devices/3-1.4.1/removable
fixed

(The internal hub is 3-1.4, and the keyboard controller is therefore 
3-1.4.1.)

I don't have any computers with a device permanently attached to an 
xHCI root-hub port.  If someone else does, maybe they can check what 
happens when these two lines:

if (!(wHubCharacteristics & HUB_CHAR_COMPOUND))
return;

are deleted from drivers/usb/core/hub.c:set_usb_port_removable().  
Deleting those lines may cause the device to show up as "fixed" rather 
than "removable".

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

[PATCH] USB: OHCI: Fix race between ED unlink and URB submission

[Alan Stern]

This patch fixes a bug introduced by commit 977dcfdc6031 ("USB: OHCI:
don't lose track of EDs when a controller dies").  The commit changed
ed_state from ED_UNLINK to ED_IDLE too early, before finish_urb() had
been called.  The user-visible consequence is that the driver
occasionally crashes or locks up when an URB is submitted while
another URB for the same endpoint is being unlinked.

This patch moves the ED state change later, to the right place.  The
drawback is that now we may unnecessarily execute some instructions
multiple times when a controller dies.  Since controllers dying is an
exceptional occurrence, a little wasted time won't matter.

Signed-off-by: Alan Stern 
Reported-by: Heiko Przybyl 
Tested-by: Heiko Przybyl 
Fixes: 977dcfdc60311e7aa571cabf6f39c36dde13339e
CC: 

---


[as1780]


 drivers/usb/host/ohci-q.c |7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

Index: usb-4.0/drivers/usb/host/ohci-q.c
===
--- usb-4.0.orig/drivers/usb/host/ohci-q.c
+++ usb-4.0/drivers/usb/host/ohci-q.c
@@ -980,10 +980,6 @@ rescan_all:
int completed, modified;
__hc32  *prev;
 
-   /* Is this ED already invisible to the hardware? */
-   if (ed->state == ED_IDLE)
-   goto ed_idle;
-
/* only take off EDs that the HC isn't using, accounting for
 * frame counter wraps and EDs with partially retired TDs
 */
@@ -1011,12 +1007,10 @@ skip_ed:
}
 
/* ED's now officially unlinked, hc doesn't see */
-   ed->state = ED_IDLE;
ed->hwHeadP &= ~cpu_to_hc32(ohci, ED_H);
ed->hwNextED = 0;
wmb();
ed->hwINFO &= ~cpu_to_hc32(ohci, ED_SKIP | ED_DEQUEUE);
-ed_idle:
 
/* reentrancy:  if we drop the schedule lock, someone might
 * have modified this list.  normally it's just prepending
@@ -1087,6 +1081,7 @@ rescan_this:
if (list_empty(&ed->td_list)) {
*last = ed->ed_next;
ed->ed_next = NULL;
+   ed->state = ED_IDLE;
list_del(&ed->in_use_list);
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
*last = ed->ed_next;

--
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 disks not recognized during boot

[Alan Stern]

On Mon, 29 Jun 2015, Raphael Hertzog wrote:

> [ Please keep me in CC as I'm not subscribed ]
> 
> Hello,
> 
> I'm the happy owner of a Intel NUC D54250WYKH (updated it to latest Intel
> firmware) which has an XHCI host controller. It's connected over USB 3 to
> a JBOD-configured disk enclosure (ICYBOX IB-RD3640SU3E2) which uses a
> JMicron USB to ATA bridge. I have attached the output of lspci -v, lsusb
> -v, lshw to describe the hardware in more details.
> 
> When I boot the computer, the disk enclosure is not detected/recognized
> (even though it's correctly powered up). I have to power cycle the disk
> enclosure while the NUC is running so that it gets properly detected
> (see dmesg-powercycle). The kernel messages do not show any obvious error
> during boot (see attached file dmesg-boot)
> 
> I have this problem with the stock 4.1 kernel as well as all Debian kernels
> (3.16.x in Jessie, 4.0.x in Stretch).
> 
> While googling for possible solutions to force a new detection of the
> hardware, I found the explanation of how to unbind/rebind the xhci_hcd
> module:
> 
> echo -n ":00:14.0" > /sys/bus/pci/drivers/xhci_hcd/unbind
> echo -n ":00:14.0" > /sys/bus/pci/drivers/xhci_hcd/bind
> 
> (with ":00:14.0" the PCI identifier of the xHCI root hub)
> 
> This does not work for me. The undetected disk enclosure stays
> unnoticed... only the hardware power cycle works.
> 
> I also tried to tweak the usbcore options (disabling autosuspend,
> old_scheme_first=Y, increasing initial_descriptor_timeout to 15000)
> but none of this did help.
> 
> Do you have any suggestion of what could be wrong in my setup ?
> 
> I'm happy to try patches and/or do further tests.

Offhand, it sounds like something is wrong with the enclosure.  It's 
possible that the BIOS does something strange to it, which prevents it 
from working until the power is cycled.  Have you checked for BIOS 
updates?

Here's another thing you can do: Try capturing a usbmon trace while
doing the unbind/bind test.  Since a controller's usbmon trace file
doesn't exist until after it is bound, you will have to run your trace
on the /sys/kernel/debug/usb/usbmon/0u file, which will capture
information on _all_ USB buses -- so try to minimize other USB activity
while running the test.

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: self-modeswitching device

[Alan Stern]

On Tue, 30 Jun 2015, Oliver Neukum wrote:

> Hi,
> 
> I am looking at a device that spontaneously switches
> its mode. I guess that you need to actively do something
> that some Windows versions do to keep the device in its
> initial mode.

When does the spontaneous mode switch occur?

> The device contains an SD card reader. That leaves me in
> a predicament. The medium if it is mounted before the
> device switches will be dirty.
> 
> Normally we say that unmounting before you switch
> is a responsibility of user space. But this device
> switches by itself.
> In that particular case I would go as far as make
> the storage driver refuse the storage interface
> of the initial mode.
> 
> What do you think?

I agree.  If a storage device is going to disconnect itself at random
times, we shouldn't try to access it.  Users can override this behavior
with usb-storage's "i" quirk flag if they need to.

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: About zero-length packet design for EHCI

[Alan Stern]

On Tue, 30 Jun 2015, Peter Chen wrote:

> Hi Alan,
> 
> When reading the code (at qh_urb_transaction) about zero-length packet
> for EHCI, would you please help me on below questions:
> 
> - I have not found the zero-length qtd prepared for control read (eg,
> the transfer size is multiple of wMaxPacketSize), Am I missing
> something?

The status stage transaction for a control-IN transfer has length 0, 
but I guess that's not what you mean.

Control-IN transfers don't have a zero-length QTD in the data stage 
because IN transfers _never_ have a zero-length QTD.

> - Why the IN transfer doesn't need to prepare zero-length qtd?
> In the 2.0 spec, it does not say it is only for OUT.
> 
> Ch 5.7.3 & Ch 5.8.3
> A bulk (interrupt) transfer is complete when the endpoint does one of the 
> following:
> - Has transferred exactly the amount of data expected
> - Transfers a packet with a payload size less than wMaxPacketSize or
> transfers a zero-length packet

Right.  The host doesn't know beforehand how much data the device will 
send during an IN transfer.  It only knows how much data to expect -- 
the device might send less than that amount.  Therefore the host must 
prepare QTDs for all the data it expects.

Suppose the host expects the device will send 525 bytes.  Then it
prepares a 525-byte QTD.  If the device sends a 512-byte packet
followed by a 13-byte packet, all is well.  But what if the device
wants to send only 512 bytes?  Then it sends a 512-byte packet followed
by a 0-byte packet.  When the host controller sees the 0-byte packet,
it knows the transfer is over -- but we still had to prepare a full
525-byte QTD, because we didn't know beforehand that the device would 
send only 512 bytes.

To put it another way, the sender indicates that he will send less
data than expected by sending a short packet.  If the amount of data he
wants to send is _not_ a multiple of the maxpacket size, then nothing
special needs to happen.  The last packet will automatically be shorter
than the maxpacket size.  But if the amount of data he wants to send 
_is_ a multiple of the maxpacket size, then after sending all the data 
he still needs to send a short packet.  Since there is no more data 
left to send, he is forced to send a zero-length packet.

Thus, when the host is the sender (i.e., for an OUT transfer), the host 
has to send a zero-length packet if the amount of data is shorter than 
the device expects and is a multiple of the maxpacket size.  When the 
host is the receiver (i.e., for an IN transfer), the _device_ is 
responsible for sending a zero-length packet -- not the host.

> Ch 5.6.4
> An isochronous IN endpoint must return a zero-length packet whenever
> data is requested at a faster interval
> than the specified interval and data is not available.

That's right, but you don't see it in ehci-hcd because for isochronous
transfers, the packet lengths are always specified by the class driver
in the urb_iso_packet_descriptor structures.

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: self-modeswitching device

[Oliver Neukum]

On Tue, 2015-06-30 at 11:34 -0400, Alan Stern wrote:
> On Tue, 30 Jun 2015, Oliver Neukum wrote:
> 
> > Hi,
> > 
> > I am looking at a device that spontaneously switches
> > its mode. I guess that you need to actively do something
> > that some Windows versions do to keep the device in its
> > initial mode.
> 
> When does the spontaneous mode switch occur?

6 seconds after device discovery.

> > In that particular case I would go as far as make
> > the storage driver refuse the storage interface
> > of the initial mode.
> > 
> > What do you think?
> 
> I agree.  If a storage device is going to disconnect itself at random
> times, we shouldn't try to access it.  Users can override this behavior
> with usb-storage's "i" quirk flag if they need to.

Good.

Regards
Oliver



--
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: [EDT][PATCH] USB XHCI: Bugfix for NULL pointer deference in xhci_endpoint_init() function

[Greg KH]

On Tue, Jun 30, 2015 at 12:10:40PM +, AMAN DEEP wrote:
> EP-D52BC23FD00D4E2BBEED88BA6AF8C4AC 

What does this mean?

And what does "[EDT]" in your subject mean?

Please fix up and resend properly.

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: [Bug 100631] Usb device not functioning in initramfs luks disk unlock

[Greg KH]

On Tue, Jun 30, 2015 at 08:53:14AM +0200, Glasswall Information Point wrote:
> 
> 
> Op 29-06-15 om 19:01 schreef bugzilla-dae...@bugzilla.kernel.org:
> > https://bugzilla.kernel.org/show_bug.cgi?id=100631
> > 
> > --- Comment #1 from Greg Kroah-Hartman  ---
> > On Mon, Jun 29, 2015 at 09:53:04AM +, 
> > bugzilla-dae...@bugzilla.kernel.org
> > wrote:
> >> https://bugzilla.kernel.org/show_bug.cgi?id=100631
> >>
> >> Bug ID: 100631
> >>Summary: Usb device not functioning in initramfs luks disk
> >> unlock
> > 
> > Please send to the linux-usb@vger.kernel.org mailing list.

Sending a random link isn't ok, please include the information here as
well.

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 2/7] usb: dwc3: omap: drop dev_dbg() usage

[Felipe Balbi]

Some of the messages were plain unnecessary
and some were actually errors. Fix it all
up.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/dwc3-omap.c | 43 ---
 1 file changed, 4 insertions(+), 39 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 6b486a36863c..e8a09a88eddd 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -225,12 +225,10 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
 
switch (status) {
case OMAP_DWC3_ID_GROUND:
-   dev_dbg(omap->dev, "ID GND\n");
-
if (omap->vbus_reg) {
ret = regulator_enable(omap->vbus_reg);
if (ret) {
-   dev_dbg(omap->dev, "regulator enable failed\n");
+   dev_err(omap->dev, "regulator enable failed\n");
return;
}
}
@@ -245,8 +243,6 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
break;
 
case OMAP_DWC3_VBUS_VALID:
-   dev_dbg(omap->dev, "VBUS Connect\n");
-
val = dwc3_omap_read_utmi_ctrl(omap);
val &= ~USBOTGSS_UTMI_OTG_CTRL_SESSEND;
val |= USBOTGSS_UTMI_OTG_CTRL_IDDIG
@@ -261,8 +257,6 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
regulator_disable(omap->vbus_reg);
 
case OMAP_DWC3_VBUS_OFF:
-   dev_dbg(omap->dev, "VBUS Disconnect\n");
-
val = dwc3_omap_read_utmi_ctrl(omap);
val &= ~(USBOTGSS_UTMI_OTG_CTRL_SESSVALID
| USBOTGSS_UTMI_OTG_CTRL_VBUSVALID
@@ -273,7 +267,7 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
break;
 
default:
-   dev_dbg(omap->dev, "invalid state\n");
+   dev_WARN(omap->dev, "invalid state\n");
}
 }
 
@@ -284,37 +278,8 @@ static irqreturn_t dwc3_omap_interrupt(int irq, void 
*_omap)
 
reg = dwc3_omap_read_irqmisc_status(omap);
 
-   if (reg & USBOTGSS_IRQMISC_DMADISABLECLR) {
-   dev_dbg(omap->dev, "DMA Disable was Cleared\n");
+   if (reg & USBOTGSS_IRQMISC_DMADISABLECLR)
omap->dma_status = false;
-   }
-
-   if (reg & USBOTGSS_IRQMISC_OEVT)
-   dev_dbg(omap->dev, "OTG Event\n");
-
-   if (reg & USBOTGSS_IRQMISC_DRVVBUS_RISE)
-   dev_dbg(omap->dev, "DRVVBUS Rise\n");
-
-   if (reg & USBOTGSS_IRQMISC_CHRGVBUS_RISE)
-   dev_dbg(omap->dev, "CHRGVBUS Rise\n");
-
-   if (reg & USBOTGSS_IRQMISC_DISCHRGVBUS_RISE)
-   dev_dbg(omap->dev, "DISCHRGVBUS Rise\n");
-
-   if (reg & USBOTGSS_IRQMISC_IDPULLUP_RISE)
-   dev_dbg(omap->dev, "IDPULLUP Rise\n");
-
-   if (reg & USBOTGSS_IRQMISC_DRVVBUS_FALL)
-   dev_dbg(omap->dev, "DRVVBUS Fall\n");
-
-   if (reg & USBOTGSS_IRQMISC_CHRGVBUS_FALL)
-   dev_dbg(omap->dev, "CHRGVBUS Fall\n");
-
-   if (reg & USBOTGSS_IRQMISC_DISCHRGVBUS_FALL)
-   dev_dbg(omap->dev, "DISCHRGVBUS Fall\n");
-
-   if (reg & USBOTGSS_IRQMISC_IDPULLUP_FALL)
-   dev_dbg(omap->dev, "IDPULLUP Fall\n");
 
dwc3_omap_write_irqmisc_status(omap, reg);
 
@@ -434,7 +399,7 @@ static void dwc3_omap_set_utmi_mode(struct dwc3_omap *omap)
reg &= ~USBOTGSS_UTMI_OTG_CTRL_SW_MODE;
break;
default:
-   dev_dbg(omap->dev, "UNKNOWN utmi mode %d\n", utmi_mode);
+   dev_WARN(omap->dev, "UNKNOWN utmi mode %d\n", utmi_mode);
}
 
dwc3_omap_write_utmi_ctrl(omap, reg);
-- 
2.4.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 4/7] usb: dwc3: exynos: switch dev_dbg() to dev_info()

[Felipe Balbi]

that message is informing that the clock is missing.
However, that's a valid condition for some setups; driver
even ignores the error and continues just fine.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/dwc3-exynos.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 7bd0a95b2815..dd5cb5577dca 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -145,7 +145,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
 
exynos->susp_clk = devm_clk_get(dev, "usbdrd30_susp_clk");
if (IS_ERR(exynos->susp_clk)) {
-   dev_dbg(dev, "no suspend clk specified\n");
+   dev_info(dev, "no suspend clk specified\n");
exynos->susp_clk = NULL;
}
clk_prepare_enable(exynos->susp_clk);
-- 
2.4.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 6/7] usb: dwc3: st: remove two unnecessary messages

[Felipe Balbi]

the mode of operation is exposed through debugfs
at all times. Because of that, we're removing
the unnecessary messages.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/dwc3-st.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
index 4a1a543deeda..de4d52f62517 100644
--- a/drivers/usb/dwc3/dwc3-st.c
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -135,8 +135,6 @@ static int st_dwc3_drd_init(struct st_dwc3 *dwc3_data)
| USB3_SEL_FORCE_DMPULLDOWN2 | USB3_FORCE_DMPULLDOWN2);
 
val |= USB3_DEVICE_NOT_HOST;
-
-   dev_dbg(dwc3_data->dev, "Configuring as Device\n");
break;
 
case USB_DR_MODE_HOST:
@@ -154,8 +152,6 @@ static int st_dwc3_drd_init(struct st_dwc3 *dwc3_data)
 */
 
val |= USB3_DELAY_VBUSVALID;
-
-   dev_dbg(dwc3_data->dev, "Configuring as Host\n");
break;
 
default:
-- 
2.4.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 5/7] usb: dwc3: qcom: switch dev_dbg() to dev_info()

[Felipe Balbi]

those two messages are informing that the clock
doesn't exist; that, however, is a valid situation
and driver continues just fine by ignoring the error.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/dwc3-qcom.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index 8c2e8eec80c2..088026048f49 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -48,13 +48,13 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
 
qdwc->iface_clk = devm_clk_get(qdwc->dev, "iface");
if (IS_ERR(qdwc->iface_clk)) {
-   dev_dbg(qdwc->dev, "failed to get optional iface clock\n");
+   dev_info(qdwc->dev, "failed to get optional iface clock\n");
qdwc->iface_clk = NULL;
}
 
qdwc->sleep_clk = devm_clk_get(qdwc->dev, "sleep");
if (IS_ERR(qdwc->sleep_clk)) {
-   dev_dbg(qdwc->dev, "failed to get optional sleep clock\n");
+   dev_info(qdwc->dev, "failed to get optional sleep clock\n");
qdwc->sleep_clk = NULL;
}
 
-- 
2.4.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 3/7] usb: dwc3: keystone: convert dev_dbg() to dev_err()

[Felipe Balbi]

that's an error condition, not a debugging message.

Let's promote it appropriately.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/dwc3-keystone.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-keystone.c b/drivers/usb/dwc3/dwc3-keystone.c
index fe3b9335a74e..c1ca2a0a56ef 100644
--- a/drivers/usb/dwc3/dwc3-keystone.c
+++ b/drivers/usb/dwc3/dwc3-keystone.c
@@ -115,7 +115,7 @@ static int kdwc3_probe(struct platform_device *pdev)
 
error = clk_prepare_enable(kdwc->clk);
if (error < 0) {
-   dev_dbg(kdwc->dev, "unable to enable usb clock, err %d\n",
+   dev_err(kdwc->dev, "unable to enable usb clock, err %d\n",
error);
return error;
}
-- 
2.4.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/7] usb: dwc3: remove CONFIG_USB_DWC3_DEBUG

[Felipe Balbi]

Hi,

I plan to get these patches merged for v4.3 merge window.
Let me know if you have any real objections. Keep in mind
that "I like dev_dbg()" or "I'm used to dev_dbg()" are not
valid objections.

cheers

Felipe Balbi (7):
  usb: dwc3: drop dev_dbg() from dwc3
  usb: dwc3: omap: drop dev_dbg() usage
  usb: dwc3: keystone: convert dev_dbg() to dev_err()
  usb: dwc3: exynos: switch dev_dbg() to dev_info()
  usb: dwc3: qcom: switch dev_dbg() to dev_info()
  usb: dwc3: st: remove two unnecessary messages
  usb: dwc3: drop CONFIG_USB_DWC3_DEBUG

 drivers/usb/dwc3/Kconfig |  9 -
 drivers/usb/dwc3/Makefile|  2 --
 drivers/usb/dwc3/core.c  |  8 +---
 drivers/usb/dwc3/dwc3-exynos.c   |  2 +-
 drivers/usb/dwc3/dwc3-keystone.c |  2 +-
 drivers/usb/dwc3/dwc3-omap.c | 43 
 drivers/usb/dwc3/dwc3-qcom.c |  4 ++--
 drivers/usb/dwc3/dwc3-st.c   |  4 
 drivers/usb/dwc3/ep0.c   |  4 ++--
 drivers/usb/dwc3/gadget.c| 41 +-
 10 files changed, 42 insertions(+), 77 deletions(-)

-- 
2.4.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 7/7] usb: dwc3: drop CONFIG_USB_DWC3_DEBUG

[Felipe Balbi]

now that we have no users of dev_dbg() in dwc3,
we can't safely remove CONFIG_USB_DWC3_DEBUG.

If dev_dbg() is ever strictly necessary - and I
don't see why it would, considering we want to
rely on tracepoints for debug - we will depend
on DYNAMIC_PRINTK to enable such messages.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/Kconfig  | 9 -
 drivers/usb/dwc3/Makefile | 2 --
 2 files changed, 11 deletions(-)

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index dede32e809b6..cdd3eae604af 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -103,12 +103,3 @@ config USB_DWC3_QCOM
help
  Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
  say 'Y' or 'M' if you have one such device.
-
-comment "Debugging features"
-
-config USB_DWC3_DEBUG
-   bool "Enable Debugging Messages"
-   help
- Say Y here to enable debugging messages on DWC3 Driver.
-
-endif
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index c7076e37c4ed..acc951d46c27 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -1,8 +1,6 @@
 # define_trace.h needs to know how to find our header
 CFLAGS_trace.o := -I$(src)
 
-ccflags-$(CONFIG_USB_DWC3_DEBUG)   := -DDEBUG
-
 obj-$(CONFIG_USB_DWC3) += dwc3.o
 
 dwc3-y := core.o debug.o trace.o
-- 
2.4.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 1/7] usb: dwc3: drop dev_dbg() from dwc3

[Felipe Balbi]

After this patch, the actual dwc3 driver
doesn't need dev_dbg(). After a couple more
patches on glue layers, we will be able to
remove CONFIG_DWC3_DEBUG and rely solely
on tracepoints for our debugging.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/core.c   |  8 +---
 drivers/usb/dwc3/ep0.c|  4 ++--
 drivers/usb/dwc3/gadget.c | 41 +++--
 3 files changed, 34 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 5c110d8e293b..80dff84c224a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -245,7 +245,8 @@ static int dwc3_event_buffers_setup(struct dwc3 *dwc)
 
for (n = 0; n < dwc->num_event_buffers; n++) {
evt = dwc->ev_buffs[n];
-   dev_dbg(dwc->dev, "Event buf %p dma %08llx length %d\n",
+   dwc3_trace(trace_dwc3_core,
+   "Event buf %p dma %08llx length %d",
evt->buf, (unsigned long long) evt->dma,
evt->length);
 
@@ -572,12 +573,13 @@ static int dwc3_core_init(struct dwc3 *dwc)
reg |= DWC3_GCTL_GBLHIBERNATIONEN;
break;
default:
-   dev_dbg(dwc->dev, "No power optimization available\n");
+   dwc3_trace(trace_dwc3_core,
+   "No power optimization available");
}
 
/* check if current dwc3 is on simulation board */
if (dwc->hwparams.hwparams6 & DWC3_GHWPARAMS6_EN_FPGA) {
-   dev_dbg(dwc->dev, "it is on FPGA board\n");
+   dwc3_trace(trace_dwc3_core, "it is on FPGA board");
dwc->is_fpga = true;
}
 
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 2ef3c8d6a9db..b8bf71634118 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -933,7 +933,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
ret = usb_gadget_map_request(&dwc->gadget, &req->request,
dep->number);
if (ret) {
-   dev_dbg(dwc->dev, "failed to map request\n");
+   dwc3_trace(trace_dwc3_ep0, "failed to map request");
return;
}
 
@@ -956,7 +956,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
ret = usb_gadget_map_request(&dwc->gadget, &req->request,
dep->number);
if (ret) {
-   dev_dbg(dwc->dev, "failed to map request\n");
+   dwc3_trace(trace_dwc3_ep0, "failed to map request");
return;
}
 
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 333a7c0078fc..c4915a095240 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -265,7 +265,8 @@ void dwc3_gadget_giveback(struct dwc3_ep *dep, struct 
dwc3_request *req,
usb_gadget_unmap_request(&dwc->gadget, &req->request,
req->direction);
 
-   dev_dbg(dwc->dev, "request %p from %s completed %d/%d ===> %d\n",
+   dwc3_trace(trace_dwc3_gadget,
+   "request %p from %s completed %d/%d ===> %d",
req, dep->name, req->request.actual,
req->request.length, status);
trace_dwc3_gadget_giveback(req);
@@ -984,7 +985,8 @@ static int __dwc3_gadget_kick_transfer(struct dwc3_ep *dep, 
u16 cmd_param,
cmd |= DWC3_DEPCMD_PARAM(cmd_param);
ret = dwc3_send_gadget_ep_cmd(dwc, dep->number, cmd, ¶ms);
if (ret < 0) {
-   dev_dbg(dwc->dev, "failed to send STARTTRANSFER command\n");
+   dwc3_trace(trace_dwc3_gadget,
+   "failed to send STARTTRANSFER command");
 
/*
 * FIXME we need to iterate over the list of requests
@@ -1095,7 +1097,8 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
struct dwc3_request *req)
 
ret = __dwc3_gadget_kick_transfer(dep, 0, true);
if (ret && ret != -EBUSY)
-   dev_dbg(dwc->dev, "%s: failed to kick transfers\n",
+   dwc3_trace(trace_dwc3_gadget,
+   "%s: failed to kick transfers",
dep->name);
return ret;
}
@@ -1112,7 +1115,8 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
struct dwc3_request *req)
ret = __dwc3_gadget_kick_transfer(dep, dep->resource_index,
false);
if (ret && ret != -EBUSY)
-   dev_dbg(dwc->dev, "%s: failed to kick transfers\n",
+   dwc3_trace(trace_dwc3_gadget,
+   "%s: failed to kick transfers",
dep->n

Re: [PATCH 7/7] usb: dwc3: drop CONFIG_USB_DWC3_DEBUG

[Felipe Balbi]

On Tue, Jun 30, 2015 at 12:56:50PM -0500, Felipe Balbi wrote:
> now that we have no users of dev_dbg() in dwc3,
> we can't safely remove CONFIG_USB_DWC3_DEBUG.
> 
> If dev_dbg() is ever strictly necessary - and I
> don't see why it would, considering we want to
> rely on tracepoints for debug - we will depend
> on DYNAMIC_PRINTK to enable such messages.
> 
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/usb/dwc3/Kconfig  | 9 -
>  drivers/usb/dwc3/Makefile | 2 --
>  2 files changed, 11 deletions(-)
> 
> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> index dede32e809b6..cdd3eae604af 100644
> --- a/drivers/usb/dwc3/Kconfig
> +++ b/drivers/usb/dwc3/Kconfig
> @@ -103,12 +103,3 @@ config USB_DWC3_QCOM
>   help
> Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
> say 'Y' or 'M' if you have one such device.
> -
> -comment "Debugging features"
> -
> -config USB_DWC3_DEBUG
> - bool "Enable Debugging Messages"
> - help
> -   Say Y here to enable debugging messages on DWC3 Driver.
> -
> -endif

argh, of course I sent the wrong version :-) Here's the correct one

8<--

From 775881f78c796a8988943ad3c487de38a18bd94f Mon Sep 17 00:00:00 2001
From: Felipe Balbi 
Date: Tue, 30 Jun 2015 12:51:49 -0500
Subject: [PATCH v2 7/7] usb: dwc3: drop CONFIG_USB_DWC3_DEBUG

now that we have no users of dev_dbg() in dwc3,
we can't safely remove CONFIG_USB_DWC3_DEBUG.

If dev_dbg() is ever strictly necessary - and I
don't see why it would, considering we want to
rely on tracepoints for debug - we will depend
on DYNAMIC_PRINTK to enable such messages.

Signed-off-by: Felipe Balbi 
---

changes since v1
- fix erroneous removal of endif

 drivers/usb/dwc3/Kconfig  | 7 ---
 drivers/usb/dwc3/Makefile | 2 --
 2 files changed, 9 deletions(-)

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index dede32e809b6..5a42c4590402 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -104,11 +104,4 @@ config USB_DWC3_QCOM
  Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
  say 'Y' or 'M' if you have one such device.
 
-comment "Debugging features"
-
-config USB_DWC3_DEBUG
-   bool "Enable Debugging Messages"
-   help
- Say Y here to enable debugging messages on DWC3 Driver.
-
 endif
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index c7076e37c4ed..acc951d46c27 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -1,8 +1,6 @@
 # define_trace.h needs to know how to find our header
 CFLAGS_trace.o := -I$(src)
 
-ccflags-$(CONFIG_USB_DWC3_DEBUG)   := -DDEBUG
-
 obj-$(CONFIG_USB_DWC3) += dwc3.o
 
 dwc3-y := core.o debug.o trace.o
-- 
2.4.4


-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] USB: OHCI: Fix race between ED unlink and URB submission

[Sergei Shtylyov]

Hello.

On 06/30/2015 06:25 PM, Alan Stern wrote:


This patch fixes a bug introduced by commit 977dcfdc6031 ("USB: OHCI:
don't lose track of EDs when a controller dies").  The commit changed
ed_state from ED_UNLINK to ED_IDLE too early, before finish_urb() had
been called.  The user-visible consequence is that the driver
occasionally crashes or locks up when an URB is submitted while
another URB for the same endpoint is being unlinked.



This patch moves the ED state change later, to the right place.  The
drawback is that now we may unnecessarily execute some instructions
multiple times when a controller dies.  Since controllers dying is an
exceptional occurrence, a little wasted time won't matter.

Signed-off-by: Alan Stern 
Reported-by: Heiko Przybyl 
Tested-by: Heiko Przybyl 
Fixes: 977dcfdc60311e7aa571cabf6f39c36dde13339e


   Documentation/SubmittingPatches says to use 12-digit SHA1 and the summary 
after it enclosed in ("").



CC: 


WBR, Sergei



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

Re: [PATCH 3/7] usb: dwc3: keystone: convert dev_dbg() to dev_err()

[Sergei Shtylyov]

Hello.

On 06/30/2015 08:56 PM, Felipe Balbi wrote:


that's an error condition, not a debugging message.



Let's promote it appropriately.



Signed-off-by: Felipe Balbi 
---
  drivers/usb/dwc3/dwc3-keystone.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)



diff --git a/drivers/usb/dwc3/dwc3-keystone.c b/drivers/usb/dwc3/dwc3-keystone.c
index fe3b9335a74e..c1ca2a0a56ef 100644
--- a/drivers/usb/dwc3/dwc3-keystone.c
+++ b/drivers/usb/dwc3/dwc3-keystone.c
@@ -115,7 +115,7 @@ static int kdwc3_probe(struct platform_device *pdev)

error = clk_prepare_enable(kdwc->clk);
if (error < 0) {
-   dev_dbg(kdwc->dev, "unable to enable usb clock, err %d\n",
+   dev_err(kdwc->dev, "unable to enable usb clock, err %d\n",


   Perhaps time to s/err/error/?

[...]

WBR, Sergei

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

Re: [PATCH 7/7] usb: dwc3: drop CONFIG_USB_DWC3_DEBUG

[Sergei Shtylyov]

Hello.

On 06/30/2015 08:56 PM, Felipe Balbi wrote:


now that we have no users of dev_dbg() in dwc3,
we can't safely remove CONFIG_USB_DWC3_DEBUG.


   s/can't/can/.


If dev_dbg() is ever strictly necessary - and I
don't see why it would, considering we want to
rely on tracepoints for debug - we will depend
on DYNAMIC_PRINTK to enable such messages.



Signed-off-by: Felipe Balbi 


[...]

WBR, Sergei

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

Re: [PATCH] USB: OHCI: Fix race between ED unlink and URB submission

[Alan Stern]

On Tue, 30 Jun 2015, Sergei Shtylyov wrote:

> Hello.
> 
> On 06/30/2015 06:25 PM, Alan Stern wrote:
> 
> > This patch fixes a bug introduced by commit 977dcfdc6031 ("USB: OHCI:
> > don't lose track of EDs when a controller dies").  The commit changed
> > ed_state from ED_UNLINK to ED_IDLE too early, before finish_urb() had
> > been called.  The user-visible consequence is that the driver
> > occasionally crashes or locks up when an URB is submitted while
> > another URB for the same endpoint is being unlinked.
> 
> > This patch moves the ED state change later, to the right place.  The
> > drawback is that now we may unnecessarily execute some instructions
> > multiple times when a controller dies.  Since controllers dying is an
> > exceptional occurrence, a little wasted time won't matter.
> >
> > Signed-off-by: Alan Stern 
> > Reported-by: Heiko Przybyl 
> > Tested-by: Heiko Przybyl 
> > Fixes: 977dcfdc60311e7aa571cabf6f39c36dde13339e
> 
> Documentation/SubmittingPatches says to use 12-digit SHA1 and the summary 
> after it enclosed in ("").

Yes, you're right.  I did it that way in the first two lines of the
body of the patch description but not in the Fixes: tag.  Greg can
alter the text of the tag (by copying the reference in the body) if he
wants.

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 v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB

[Grant Likely]

On Tue, 26 May 2015 16:18:54 +0100
, Lee Jones 
 wrote:
> On Thu, 21 May 2015, Thierry Reding wrote:
> 
> > On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
> > > On Wed, 20 May 2015, Thierry Reding wrote:
> > > > On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > > > > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > > > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > > > >  wrote:
> > > > > > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones 
> > > > > > >  wrote:
> > > > > > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > > > > > >>> On 13/05/15 15:39, Lee Jones wrote:
> > > > > > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > > > > > >>> >
> > > > > > >>> >> Add a binding document for the XUSB host complex on NVIDIA 
> > > > > > >>> >> Tegra124
> > > > > > >>> >> and later SoCs.  The XUSB host complex includes a mailbox for
> > > > > > >>> >> communication with the XUSB micro-controller and an xHCI 
> > > > > > >>> >> host-controller.
> > > > > > >>> >>
> > > > > > >>> >> Signed-off-by: Andrew Bresticker 
> > > > > > >>> >> Cc: Rob Herring 
> > > > > > >>> >> Cc: Pawel Moll 
> > > > > > >>> >> Cc: Mark Rutland 
> > > > > > >>> >> Cc: Ian Campbell 
> > > > > > >>> >> Cc: Kumar Gala 
> > > > > > >>> >> Cc: Samuel Ortiz 
> > > > > > >>> >> Cc: Lee Jones 
> > > > > > >>> >> ---
> > > > > > >>> >> Changes from v7:
> > > > > > >>> >>  - Move non-shared resources into child nodes.
> > > > > > >>> >> New for v7.
> > > > > > >>> >> ---
> > > > > > >>> >>  .../bindings/mfd/nvidia,tegra124-xusb.txt  | 37 
> > > > > > >>> >> ++
> > > > > > >>> >>  1 file changed, 37 insertions(+)
> > > > > > >>> >>  create mode 100644 
> > > > > > >>> >> Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > > >>> >>
> > > > > > >>> >> diff --git 
> > > > > > >>> >> a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > > >>> >>  
> > > > > > >>> >> b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > > >>> >> new file mode 100644
> > > > > > >>> >> index 000..bc50110
> > > > > > >>> >> --- /dev/null
> > > > > > >>> >> +++ 
> > > > > > >>> >> b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > > >>> >> @@ -0,0 +1,37 @@
> > > > > > >>> >> +NVIDIA Tegra XUSB host copmlex
> > > > > > >>> >> +==
> > > > > > >>> >> +
> > > > > > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains 
> > > > > > >>> >> an xHCI host
> > > > > > >>> >> +controller and a mailbox for communication with the XUSB 
> > > > > > >>> >> micro-controller.
> > > > > > >>> >> +
> > > > > > >>> >> +Required properties:
> > > > > > >>> >> +
> > > > > > >>> >> + - compatible: For Tegra124, must contain 
> > > > > > >>> >> "nvidia,tegra124-xusb".
> > > > > > >>> >> +   Otherwise, must contain '"nvidia,-xusb", 
> > > > > > >>> >> "nvidia,tegra124-xusb"'
> > > > > > >>> >> +   where  is tegra132.
> > > > > > >>> >> + - reg: Must contain the base and length of the XUSB FPCI 
> > > > > > >>> >> registers.
> > > > > > >>> >> + - ranges: Bus address mapping for the XUSB block.  Can be 
> > > > > > >>> >> empty since the
> > > > > > >>> >> +   mapping is 1:1.
> > > > > > >>> >> + - #address-cells: Must be 2.
> > > > > > >>> >> + - #size-cells: Must be 2.
> > > > > > >>> >> +
> > > > > > >>> >> +Example:
> > > > > > >>> >> +
> > > > > > >>> >> +  usb@0,70098000 {
> > > > > > >>> >> +  compatible = "nvidia,tegra124-xusb";
> > > > > > >>> >> +  reg = <0x0 0x70098000 0x0 0x1000>;
> > > > > > >>> >> +  ranges;
> > > > > > >>> >> +
> > > > > > >>> >> +  #address-cells = <2>;
> > > > > > >>> >> +  #size-cells = <2>;
> > > > > > >>> >> +
> > > > > > >>> >> +  usb-host@0,7009 {
> > > > > > >>> >> +  compatible = "nvidia,tegra124-xhci";
> > > > > > >>> >> +  ...
> > > > > > >>> >> +  };
> > > > > > >>> >> +
> > > > > > >>> >> +  mailbox {
> > > > > > >>> >> +  compatible = "nvidia,tegra124-xusb-mbox";
> > > > > > >>> >> +  ...
> > > > > > >>> >> +  };
> > > > > > >>> >
> > > > > > >>> > This doesn't appear to be a proper MFD.  I would have the USB 
> > > > > > >>> > and
> > > > > > >>> > Mailbox devices probe seperately and use a phandle to point 
> > > > > > >>> > the USB
> > > > > > >>> > device to its Mailbox.
> > > > > > >>> >
> > > > > > >>> > usb@xyz {
> > > > > > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > > > > > >>> > };
> > > > > > >>> >
> > > > > > >>>
> > > > > > >>> I am assuming that Andrew had laid it out like this to reflect 
> > > > > > >>> the hw
> > > > > > >>> structure. The mailbox and xhci controller are part of the xusb
> > > > > > >>> sub-system and hence appear as child nodes. My understanding is 
> > > > > > >>> that for
> > > > > > >>> device-tree we want the device-tree structure to reflect the 
> >

Re: [PATCH 7/7] usb: dwc3: drop CONFIG_USB_DWC3_DEBUG

[Felipe Balbi]

On Tue, Jun 30, 2015 at 10:23:16PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 06/30/2015 08:56 PM, Felipe Balbi wrote:
> 
> >now that we have no users of dev_dbg() in dwc3,
> >we can't safely remove CONFIG_USB_DWC3_DEBUG.
> 
>s/can't/can/.

heh, thanks :-) I'll fix in branch only.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 3/7] usb: dwc3: keystone: convert dev_dbg() to dev_err()

[Felipe Balbi]

On Tue, Jun 30, 2015 at 10:21:40PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 06/30/2015 08:56 PM, Felipe Balbi wrote:
> 
> >that's an error condition, not a debugging message.
> 
> >Let's promote it appropriately.
> 
> >Signed-off-by: Felipe Balbi 
> >---
> >  drivers/usb/dwc3/dwc3-keystone.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> >diff --git a/drivers/usb/dwc3/dwc3-keystone.c 
> >b/drivers/usb/dwc3/dwc3-keystone.c
> >index fe3b9335a74e..c1ca2a0a56ef 100644
> >--- a/drivers/usb/dwc3/dwc3-keystone.c
> >+++ b/drivers/usb/dwc3/dwc3-keystone.c
> >@@ -115,7 +115,7 @@ static int kdwc3_probe(struct platform_device *pdev)
> >
> > error = clk_prepare_enable(kdwc->clk);
> > if (error < 0) {
> >-dev_dbg(kdwc->dev, "unable to enable usb clock, err %d\n",
> >+dev_err(kdwc->dev, "unable to enable usb clock, err %d\n",
> 
>Perhaps time to s/err/error/?

what do you mean ? There's a dev_error now ? Can't seem to find it with
grep.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 3/7] usb: dwc3: keystone: convert dev_dbg() to dev_err()

[Sergei Shtylyov]

On 07/01/2015 12:10 AM, Felipe Balbi wrote:


that's an error condition, not a debugging message.



Let's promote it appropriately.



Signed-off-by: Felipe Balbi 
---
  drivers/usb/dwc3/dwc3-keystone.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)



diff --git a/drivers/usb/dwc3/dwc3-keystone.c b/drivers/usb/dwc3/dwc3-keystone.c
index fe3b9335a74e..c1ca2a0a56ef 100644
--- a/drivers/usb/dwc3/dwc3-keystone.c
+++ b/drivers/usb/dwc3/dwc3-keystone.c
@@ -115,7 +115,7 @@ static int kdwc3_probe(struct platform_device *pdev)

error = clk_prepare_enable(kdwc->clk);
if (error < 0) {
-   dev_dbg(kdwc->dev, "unable to enable usb clock, err %d\n",
+   dev_err(kdwc->dev, "unable to enable usb clock, err %d\n",



Perhaps time to s/err/error/?



what do you mean ? There's a dev_error now ? Can't seem to find it with
grep.


   I meant "err" in the message. :-)

WBR, Sergei

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

Re: [PATCH 3/7] usb: dwc3: keystone: convert dev_dbg() to dev_err()

[Felipe Balbi]

On Wed, Jul 01, 2015 at 12:12:05AM +0300, Sergei Shtylyov wrote:
> On 07/01/2015 12:10 AM, Felipe Balbi wrote:
> 
> >>>that's an error condition, not a debugging message.
> 
> >>>Let's promote it appropriately.
> 
> >>>Signed-off-by: Felipe Balbi 
> >>>---
> >>>  drivers/usb/dwc3/dwc3-keystone.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> >>>diff --git a/drivers/usb/dwc3/dwc3-keystone.c 
> >>>b/drivers/usb/dwc3/dwc3-keystone.c
> >>>index fe3b9335a74e..c1ca2a0a56ef 100644
> >>>--- a/drivers/usb/dwc3/dwc3-keystone.c
> >>>+++ b/drivers/usb/dwc3/dwc3-keystone.c
> >>>@@ -115,7 +115,7 @@ static int kdwc3_probe(struct platform_device *pdev)
> >>>
> >>>   error = clk_prepare_enable(kdwc->clk);
> >>>   if (error < 0) {
> >>>-  dev_dbg(kdwc->dev, "unable to enable usb clock, err %d\n",
> >>>+  dev_err(kdwc->dev, "unable to enable usb clock, err %d\n",
> 
> >>Perhaps time to s/err/error/?
> 
> >what do you mean ? There's a dev_error now ? Can't seem to find it with
> >grep.
> 
>I meant "err" in the message. :-)

oh, haha, I was completely blind to that. I'll fix it in my branch
(testing/next) Thanks.

-- 
balbi


signature.asc
Description: Digital signature

[RFC PATCH 0/1] RFC - Implement a usbredir kernel module

[Jeremy White]

The following patch proposes a new kernel module to provide an
alternate protocol for transporting USB devices over a TCP/IP connection.

This flows from a few conversations on the Spice devel mailing list.[1][2]

I am relying heavily on the opinion of Hans de Goede, who believes
that the usbredir protocol is superior to that used by the existing
usbip kernel module[3].

The basic approach in this module is the same as usbip (virtual hcd driver)
but it attempts to support a configurable number of devices and hubs,
rather than just one hub and the limit of 8 devices.

This version of the code should be sufficient to review my general
approach, but it is known to be incomplete.  I have successfully mounted
and operated a thumb drive across the interface.

Hopefully it is enough to warrant advice and comments; feedback is
greatly appreciated.

Anyone wishing to test this will also need a related set of usbredir patches,
recently sent to the spice-devel mailing list.[4]

Roughly half of the code (all of the code that fails checkpatch )
was copied, essentially unchanged, from the usbredir project.  I felt
that diffability was more important than checkpatch; I stand ready to
be corrected.

After review, I plan to build a fairly extensive set of unit tests
(see the new usbredirtestserver in [3]), and would hope to submit
a complete module later in the summer.

Cheers,

Jeremy


[1] http://lists.freedesktop.org/archives/spice-devel/2014-August/017145.html
[2] http://lists.freedesktop.org/archives/spice-devel/2015-April/019451.html
[3] http://lists.freedesktop.org/archives/spice-devel/2014-August/017174.html
[4] http://lists.freedesktop.org/archives/spice-devel/2015-June/020595.html

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

Re: [PATCH 5/7] usb: dwc3: qcom: switch dev_dbg() to dev_info()

[Andy Gross]

On Tue, Jun 30, 2015 at 12:56:48PM -0500, Felipe Balbi wrote:
> those two messages are informing that the clock
> doesn't exist; that, however, is a valid situation
> and driver continues just fine by ignoring the error.

Reviewed-by: Andy Gross 

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP.

[Greg KH]

On Tue, Jun 30, 2015 at 04:44:10PM -0500, Jeremy White wrote:
> This module uses the usbredir protocol and user space tools,
> which are used by the SPICE project.
> 
> Signed-off-by: Jeremy White 
> ---
>  MAINTAINERS |6 +
>  drivers/usb/Kconfig |2 +
>  drivers/usb/Makefile|1 +
>  drivers/usb/usbredir/Kconfig|   25 +
>  drivers/usb/usbredir/Makefile   |4 +
>  drivers/usb/usbredir/README |   20 +
>  drivers/usb/usbredir/TODO   |   12 +
>  drivers/usb/usbredir/device.c   |  327 +
>  drivers/usb/usbredir/hub.c  |  489 
>  drivers/usb/usbredir/main.c |  100 ++
>  drivers/usb/usbredir/redir.c|  535 
>  drivers/usb/usbredir/rx.c   |   40 +
>  drivers/usb/usbredir/strtok_r.c |   69 +
>  drivers/usb/usbredir/strtok_r.h |   26 +
>  drivers/usb/usbredir/sysfs.c|  145 +++
>  drivers/usb/usbredir/tx.c   |  151 +++
>  drivers/usb/usbredir/urb.c  |  266 
>  drivers/usb/usbredir/usbredir.h |  225 
>  drivers/usb/usbredir/usbredirfilter.c   |  294 +
>  drivers/usb/usbredir/usbredirfilter.h   |  144 +++
>  drivers/usb/usbredir/usbredirparser.c   | 1795 
> +++
>  drivers/usb/usbredir/usbredirparser.h   |  386 ++
>  drivers/usb/usbredir/usbredirproto-compat.h |   88 ++
>  drivers/usb/usbredir/usbredirproto.h|  309 +
>  24 files changed, 5459 insertions(+)
>  create mode 100644 drivers/usb/usbredir/Kconfig
>  create mode 100644 drivers/usb/usbredir/Makefile
>  create mode 100644 drivers/usb/usbredir/README
>  create mode 100644 drivers/usb/usbredir/TODO
>  create mode 100644 drivers/usb/usbredir/device.c
>  create mode 100644 drivers/usb/usbredir/hub.c
>  create mode 100644 drivers/usb/usbredir/main.c
>  create mode 100644 drivers/usb/usbredir/redir.c
>  create mode 100644 drivers/usb/usbredir/rx.c
>  create mode 100644 drivers/usb/usbredir/strtok_r.c
>  create mode 100644 drivers/usb/usbredir/strtok_r.h
>  create mode 100644 drivers/usb/usbredir/sysfs.c
>  create mode 100644 drivers/usb/usbredir/tx.c
>  create mode 100644 drivers/usb/usbredir/urb.c
>  create mode 100644 drivers/usb/usbredir/usbredir.h
>  create mode 100644 drivers/usb/usbredir/usbredirfilter.c
>  create mode 100644 drivers/usb/usbredir/usbredirfilter.h
>  create mode 100644 drivers/usb/usbredir/usbredirparser.c
>  create mode 100644 drivers/usb/usbredir/usbredirparser.h
>  create mode 100644 drivers/usb/usbredir/usbredirproto-compat.h
>  create mode 100644 drivers/usb/usbredir/usbredirproto.h

It's pointless to post a patch that you know has problems with it (i.e.
it's not even in proper kernel coding style), as it will never be
reviewed or even looked at.

Please do the most basic of polite things and fix this up before posting
things.

And really, all in one patch?  That too is pretty hard to review...

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 5/7] usb: dwc3: qcom: switch dev_dbg() to dev_info()

[Felipe Balbi]

On Tue, Jun 30, 2015 at 06:15:29PM -0500, Andy Gross wrote:
> On Tue, Jun 30, 2015 at 12:56:48PM -0500, Felipe Balbi wrote:
> > those two messages are informing that the clock
> > doesn't exist; that, however, is a valid situation
> > and driver continues just fine by ignoring the error.
> 
> Reviewed-by: Andy Gross 

thanks, added this to testing/next

-- 
balbi


signature.asc
Description: Digital signature

答复: about [PATCH] net:usb:cdc_ncm: fix that tag Huawei devices as wwan

[Chenqi (jakio)]

Hi，bjorn,

Thanks for your kindly reply and providing so much info about linux wwan 
components!

We'll make a deep research on linux wwan architecture, maybe we can support it 
in the newly developing products.
About what you saying about "submit the patch formally", what steps should I 
do? Is there any documents about it?


Best Regards！
Jakio.chen




华为技术有限公司 Huawei Technologies Co., Ltd.

Phone: 18909297056
Email: cqi.c...@huawei.com
地址：西安市锦业一路软件大厦G座 邮编：71


-邮件原件-
发件人: Bjørn Mork [mailto:bj...@mork.no] 
发送时间: 2015年6月26日 17:21
收件人: Chenqi (jakio)
抄送: torva...@linux-foundation.org; aleksan...@aleksander.es; d...@redhat.com; 
oli...@neukum.org; ben.hutchi...@codethink.co.uk; linux-usb@vger.kernel.org; 
net...@vger.kernel.org; mar...@holtmann.org; xiaomao0...@hotmail.com; Zhangyuhan
主题: Re: about [PATCH] net:usb:cdc_ncm: fix that tag Huawei devices as wwan

"Chenqi (jakio)"  writes:

> Hi, All,
>
> I'm from Huawei Technologies Co., Ltd, working in mobile broadband 
> devices department.
>
> Huawei's broadband card don't support wwan in linux OS, there are 
> several historical reasons:
>
> 1.  Huawei produced dozens of broadband card types in past years, and 
> our customers/users integrate our products in many different OS 
> versions, We need give customer/user a continuous method to let them 
> use convenience.
>
> 2.  Wwan connection need application support, while we didn't test 
> them for compatibility.
>
> Meanwhile, we have provided serial port to let other existing 
> applications dial-up the connection
>
> I understand that you guys have some confusion why the Huawei 
> broadband cards support wwan in windows OS but not in linux OS with 
> the same device ID.  Since wwan standard is used firstly in windows 
> OS, when we pronounced to support this feature, wwan is not enabled in 
> linux.  So we keep the card's behavior in linux same as before.

The Linux kernel/drivers/userspace always will attempt to use hardware in the 
same way Windows use it, or at least as close as we are able to get.  The 
reason is simple: A billion (or whatever) Windows users is the best test lab 
you can get.

You may not agree with this strategy, but as a hardware vendor you have to 
expect it to happen.  The community will continue to develop support based on 
that assumption, even if you try to accommodate Linux by adding addiotional 
"Linux specific" features or modes.

> This wwan patch has great influence on our broadband cards, we have 
> tested many our broadband cards with this kernel version, and this 
> compatible issue is common.  So please approve our modification for 
> this problem.

If noone else has any comments or objections here, then I am certainly not 
going to object to the proposed patch.

Please go ahead and submit the patch formally.  I am going to keep my big mouth 
shut :)

> I think the root cause of this issue is this kernel version trait the 
> NCM as wwan devtype, maybe we can add a flag in usb descriptor in 
> future to indicate whether the device support wwan or not, then Huawei 
> can support wwan feature later for the newest product without 
> introducing compatible issues.
>
> BTW: if we want to join the usb-ethernet kernel evolution in linux, 
> which forum or organization should we join in?  We can participate in 
> it to avoid similar problems.

USB networking drivers are discussed, along with other network drivers, on the 
net...@vger.kernel.org mailing list.  Preferable with a copy to the 
linux-usb@vger.kernel.org mailing list for USB expert review.

But as you point out above:  wwan connections need application support.
Userspace projects like ModemManager, oFono, libmbim, libqmi, umbim, uqmi and 
probably more, each have their own development forums/mailing lists.  This is 
where the most important part of the wwan developemt takes place.

Huawei have already made important contributions to the development of both 
Linux wwan drivers and userspace applications.  I am sure all those projects 
will appreciate any further help Huawei are able to offer.

Thanks a lot for your detailed introduction and explanation.


Bjørn

Re: 答复: about [PATCH] net:usb:cdc_ncm: fix that tag Huawei devices as wwan

[Greg KH]

On Wed, Jul 01, 2015 at 12:49:01AM +, Chenqi (jakio) wrote:
> Hi，bjorn,
> 
> Thanks for your kindly reply and providing so much info about linux wwan 
> components!
> 
> We'll make a deep research on linux wwan architecture, maybe we can support 
> it in the newly developing products.
> About what you saying about "submit the patch formally", what steps should I 
> do? Is there any documents about it?

The kernel source file, Documentation/SubmittingPatches describes the
steps and details everything you need to know about how to properly
submit a kernel patch.

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

答复: 答复: about [PATCH] net:usb:cdc_ncm: fix that tag Huawei devices as wwan

[Chenqi (jakio)]

Hi， Greg，

Got it！
Thanks

Jakio.chen

-邮件原件-
发件人: Greg KH [mailto:gre...@linuxfoundation.org] 
发送时间: 2015年7月1日 9:05
收件人: Chenqi (jakio)
抄送: Bjørn Mork; torva...@linux-foundation.org; aleksan...@aleksander.es; 
d...@redhat.com; oli...@neukum.org; ben.hutchi...@codethink.co.uk; 
linux-usb@vger.kernel.org; net...@vger.kernel.org; mar...@holtmann.org; 
xiaomao0...@hotmail.com; Zhangyuhan; Maqianni
主题: Re: 答复: about [PATCH] net:usb:cdc_ncm: fix that tag Huawei devices as wwan

On Wed, Jul 01, 2015 at 12:49:01AM +, Chenqi (jakio) wrote:
> Hi，bjorn,
> 
> Thanks for your kindly reply and providing so much info about linux wwan 
> components!
> 
> We'll make a deep research on linux wwan architecture, maybe we can support 
> it in the newly developing products.
> About what you saying about "submit the patch formally", what steps should I 
> do? Is there any documents about it?

The kernel source file, Documentation/SubmittingPatches describes the steps and 
details everything you need to know about how to properly submit a kernel patch.

thanks,

greg k-h
N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

Re: About zero-length packet design for EHCI

[Peter Chen]

On Tue, Jun 30, 2015 at 12:03:34PM -0400, Alan Stern wrote:
> On Tue, 30 Jun 2015, Peter Chen wrote:
> 
> > Hi Alan,
> > 
> > When reading the code (at qh_urb_transaction) about zero-length packet
> > for EHCI, would you please help me on below questions:
> > 
> > - I have not found the zero-length qtd prepared for control read (eg,
> > the transfer size is multiple of wMaxPacketSize), Am I missing
> > something?
> 
> The status stage transaction for a control-IN transfer has length 0, 
> but I guess that's not what you mean.
> 
> Control-IN transfers don't have a zero-length QTD in the data stage 
> because IN transfers _never_ have a zero-length QTD.

Then, how to cover the ch 8.5.3.2 Variable-length Data Stage:

If the data structure is an exact multiple of wMaxPacketSize for the
pipe, the function will return a zero-length packet to indicate the
end of the Data stage.

By reading your answers below, does it mean neither host nor device
need to prepare qtd and dtd for reading zero-length packet, the hardware
can handle it, and knows the data stage is over?

> 
> > - Why the IN transfer doesn't need to prepare zero-length qtd?
> > In the 2.0 spec, it does not say it is only for OUT.
> > 
> > Ch 5.7.3 & Ch 5.8.3
> > A bulk (interrupt) transfer is complete when the endpoint does one of the 
> > following:
> > - Has transferred exactly the amount of data expected
> > - Transfers a packet with a payload size less than wMaxPacketSize or
> > transfers a zero-length packet
> 
> Right.  The host doesn't know beforehand how much data the device will 
> send during an IN transfer.  It only knows how much data to expect -- 
> the device might send less than that amount.  Therefore the host must 
> prepare QTDs for all the data it expects.
> 
> Suppose the host expects the device will send 525 bytes.  Then it
> prepares a 525-byte QTD.  If the device sends a 512-byte packet
> followed by a 13-byte packet, all is well.  But what if the device
> wants to send only 512 bytes?  Then it sends a 512-byte packet followed
> by a 0-byte packet.  When the host controller sees the 0-byte packet,
> it knows the transfer is over -- but we still had to prepare a full
> 525-byte QTD, because we didn't know beforehand that the device would 
> send only 512 bytes.
> 
> To put it another way, the sender indicates that he will send less
> data than expected by sending a short packet.  If the amount of data he
> wants to send is _not_ a multiple of the maxpacket size, then nothing
> special needs to happen.  The last packet will automatically be shorter
> than the maxpacket size.  But if the amount of data he wants to send 
> _is_ a multiple of the maxpacket size, then after sending all the data 
> he still needs to send a short packet.  Since there is no more data 
> left to send, he is forced to send a zero-length packet.
> 
> Thus, when the host is the sender (i.e., for an OUT transfer), the host 
> has to send a zero-length packet if the amount of data is shorter than 
> the device expects and is a multiple of the maxpacket size.  When the 
> host is the receiver (i.e., for an IN transfer), the _device_ is 
> responsible for sending a zero-length packet -- not the host.
> 
> > Ch 5.6.4
> > An isochronous IN endpoint must return a zero-length packet whenever
> > data is requested at a faster interval
> > than the specified interval and data is not available.
> 
> That's right, but you don't see it in ehci-hcd because for isochronous
> transfers, the packet lengths are always specified by the class driver
> in the urb_iso_packet_descriptor structures.

Get it, thanks.

-- 

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

Re: [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP.

[Jeremy White]

It's pointless to post a patch that you know has problems with it (i.e.
it's not even in proper kernel coding style), as it will never be
reviewed or even looked at.


Thanks for the reply, and I'm sorry for the clumsy ask.

I would still appreciate feedback on two points:

  1.  Is the basic premise reasonable?  Is Hans correct in asserting 
that an alternate USB over IP module will be considered?


  2.  Do I correctly understand that there are no circumstances where 
copied code can be left unmodified?  Even in the case where the copied 
code is working, production code, and the changes would be just for style?




Please do the most basic of polite things and fix this up before posting
things.


It is often difficult for a newcomer to know what the polite thing is, 
even after studying FAQs and documentation.


I appreciate your patience (and clue bats) as I try to learn.



And really, all in one patch?  That too is pretty hard to review...


Yeah.  I see the point of pain.  I did not see a solution as I formed 
the patch, but I'll try harder before resending.


Cheers,

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

[PATCH 3/5] usb: phy: tahvo: Use devm_extcon_dev_[allocate|register]() and replace deprecated API

[Chanwoo Choi]

This patch uses the devm_extcon_dev_[allocate|register]() to manage the
resource automatically and replace deprecated API as following:
- extcon_[set|get]_cable_state(*edev, char *) -> 
extcon_[set|get]_cable_state_(*edev, id)

Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Signed-off-by: Chanwoo Choi 
---
 drivers/usb/phy/phy-tahvo.c | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/phy/phy-tahvo.c
index b40d6a87d694..ab5d364f6e8c 100644
--- a/drivers/usb/phy/phy-tahvo.c
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -57,7 +57,7 @@ struct tahvo_usb {
struct clk  *ick;
int irq;
int tahvo_mode;
-   struct extcon_dev   extcon;
+   struct extcon_dev   *extcon;
 };
 
 static const unsigned int tahvo_cable[] = {
@@ -121,7 +121,7 @@ static void check_vbus_state(struct tahvo_usb *tu)
prev_state = tu->vbus_state;
tu->vbus_state = reg & TAHVO_STAT_VBUS;
if (prev_state != tu->vbus_state) {
-   extcon_set_cable_state(&tu->extcon, "USB", tu->vbus_state);
+   extcon_set_cable_state_(tu->extcon, EXTCON_USB, tu->vbus_state);
sysfs_notify(&tu->pt_dev->dev.kobj, NULL, "vbus_state");
}
 }
@@ -130,7 +130,7 @@ static void tahvo_usb_become_host(struct tahvo_usb *tu)
 {
struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
 
-   extcon_set_cable_state(&tu->extcon, "USB-HOST", true);
+   extcon_set_cable_state_(tu->extcon, EXTCON_USB_HOST, true);
 
/* Power up the transceiver in USB host mode */
retu_write(rdev, TAHVO_REG_USBR, USBR_REGOUT | USBR_NSUSPEND |
@@ -149,7 +149,7 @@ static void tahvo_usb_become_peripheral(struct tahvo_usb 
*tu)
 {
struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
 
-   extcon_set_cable_state(&tu->extcon, "USB-HOST", false);
+   extcon_set_cable_state_(tu->extcon, EXTCON_USB_HOST, false);
 
/* Power up transceiver and set it in USB peripheral mode */
retu_write(rdev, TAHVO_REG_USBR, USBR_SLAVE_CONTROL | USBR_REGOUT |
@@ -365,11 +365,13 @@ static int tahvo_usb_probe(struct platform_device *pdev)
 */
tu->vbus_state = retu_read(rdev, TAHVO_REG_IDSR) & TAHVO_STAT_VBUS;
 
-   tu->extcon.name = DRIVER_NAME;
-   tu->extcon.supported_cable = tahvo_cable;
-   tu->extcon.dev.parent = &pdev->dev;
+   tu->extcon = devm_extcon_dev_allocate(&pdev->dev, tahvo_cable);
+   if (IS_ERR(tu->extcon)) {
+   dev_err(&pdev->dev, "failed to allocate memory for extcon\n");
+   return -ENOMEM;
+   }
 
-   ret = extcon_dev_register(&tu->extcon);
+   ret = devm_extcon_dev_register(&pdev->dev, tu->extcon);
if (ret) {
dev_err(&pdev->dev, "could not register extcon device: %d\n",
ret);
@@ -377,9 +379,9 @@ static int tahvo_usb_probe(struct platform_device *pdev)
}
 
/* Set the initial cable state. */
-   extcon_set_cable_state(&tu->extcon, "USB-HOST",
+   extcon_set_cable_state_(tu->extcon, EXTCON_USB_HOST,
   tu->tahvo_mode == TAHVO_MODE_HOST);
-   extcon_set_cable_state(&tu->extcon, "USB", tu->vbus_state);
+   extcon_set_cable_state_(tu->extcon, EXTCON_USB, tu->vbus_state);
 
/* Create OTG interface */
tahvo_usb_power_off(tu);
@@ -396,7 +398,7 @@ static int tahvo_usb_probe(struct platform_device *pdev)
if (ret < 0) {
dev_err(&pdev->dev, "cannot register USB transceiver: %d\n",
ret);
-   goto err_extcon_unreg;
+   goto err_disable_clk;
}
 
dev_set_drvdata(&pdev->dev, tu);
@@ -424,8 +426,6 @@ err_free_irq:
free_irq(tu->irq, tu);
 err_remove_phy:
usb_remove_phy(&tu->phy);
-err_extcon_unreg:
-   extcon_dev_unregister(&tu->extcon);
 err_disable_clk:
if (!IS_ERR(tu->ick))
clk_disable(tu->ick);
@@ -440,7 +440,6 @@ static int tahvo_usb_remove(struct platform_device *pdev)
sysfs_remove_group(&pdev->dev.kobj, &tahvo_attr_group);
free_irq(tu->irq, tu);
usb_remove_phy(&tu->phy);
-   extcon_dev_unregister(&tu->extcon);
if (!IS_ERR(tu->ick))
clk_disable(tu->ick);
 
-- 
1.8.5.5

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

[PATCH 1/5] usb: dwc3: omap: Replace deprecated API of extcon

[Chanwoo Choi]

This patch removes the deprecated notifier API of extcon framwork
and then use the new extcon API with the unique id to indicate
the each external connector (USB, USB-HOST).

Alter deprecated API as following:
- extcon_register_interest() -> extcon_register_notifier()
- extcon_get_cable_state(*edev, char *) -> extcon_get_cable_state_(*edev, id)

Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Signed-off-by: Chanwoo Choi 
---
 drivers/usb/dwc3/dwc3-omap.c | 32 +---
 1 file changed, 13 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 6b486a36863c..651a0e803882 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -128,8 +128,7 @@ struct dwc3_omap {
 
u32 dma_status:1;
 
-   struct extcon_specific_cable_nb extcon_vbus_dev;
-   struct extcon_specific_cable_nb extcon_id_dev;
+   struct extcon_dev   *edev;
struct notifier_block   vbus_nb;
struct notifier_block   id_nb;
 
@@ -454,23 +453,23 @@ static int dwc3_omap_extcon_register(struct dwc3_omap 
*omap)
}
 
omap->vbus_nb.notifier_call = dwc3_omap_vbus_notifier;
-   ret = extcon_register_interest(&omap->extcon_vbus_dev,
-  edev->name, "USB",
-  &omap->vbus_nb);
+   ret = extcon_register_notifier(edev, EXTCON_USB,
+   &omap->vbus_nb);
if (ret < 0)
dev_vdbg(omap->dev, "failed to register notifier for 
USB\n");
 
omap->id_nb.notifier_call = dwc3_omap_id_notifier;
-   ret = extcon_register_interest(&omap->extcon_id_dev,
-  edev->name, "USB-HOST",
-  &omap->id_nb);
+   ret = extcon_register_notifier(edev, EXTCON_USB_HOST,
+   &omap->id_nb);
if (ret < 0)
dev_vdbg(omap->dev, "failed to register notifier for 
USB-HOST\n");
 
-   if (extcon_get_cable_state(edev, "USB") == true)
+   if (extcon_get_cable_state_(edev, EXTCON_USB) == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
-   if (extcon_get_cable_state(edev, "USB-HOST") == true)
+   if (extcon_get_cable_state_(edev, EXTCON_USB_HOST) == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
+
+   omap->edev = edev;
}
 
return 0;
@@ -565,11 +564,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
return 0;
 
 err3:
-   if (omap->extcon_vbus_dev.edev)
-   extcon_unregister_interest(&omap->extcon_vbus_dev);
-   if (omap->extcon_id_dev.edev)
-   extcon_unregister_interest(&omap->extcon_id_dev);
-
+   extcon_unregister_notifier(omap->edev, EXTCON_USB, &omap->vbus_nb);
+   extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, &omap->id_nb);
 err2:
dwc3_omap_disable_irqs(omap);
 
@@ -586,10 +582,8 @@ static int dwc3_omap_remove(struct platform_device *pdev)
 {
struct dwc3_omap*omap = platform_get_drvdata(pdev);
 
-   if (omap->extcon_vbus_dev.edev)
-   extcon_unregister_interest(&omap->extcon_vbus_dev);
-   if (omap->extcon_id_dev.edev)
-   extcon_unregister_interest(&omap->extcon_id_dev);
+   extcon_unregister_notifier(omap->edev, EXTCON_USB, &omap->vbus_nb);
+   extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, &omap->id_nb);
dwc3_omap_disable_irqs(omap);
of_platform_depopulate(omap->dev);
pm_runtime_put_sync(&pdev->dev);
-- 
1.8.5.5

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

[PATCH 5/5] usb: phy: msm-usb: Replace deprecated API of extcon

[Chanwoo Choi]

This patch removes the deprecated notifier API of extcon framwork
and then use the new extcon API with the unique id to indicate
the each external connector (USB, USB-HOST).

Alter deprecated API as following:
- extcon_register_interest() -> extcon_register_notifier()
- extcon_get_cable_state(*edev, char *) -> extcon_get_cable_state_(*edev, id)

Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Signed-off-by: Chanwoo Choi 
---
 drivers/usb/phy/phy-msm-usb.c | 20 ++--
 include/linux/usb/msm_hsusb.h |  2 +-
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 00c49bb1bd29..61d86d8bf5b7 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1561,15 +1561,16 @@ static int msm_otg_read_dt(struct platform_device 
*pdev, struct msm_otg *motg)
}
 
if (!IS_ERR(ext_vbus)) {
+   motg->vbus.extcon = ext_vbus;
motg->vbus.nb.notifier_call = msm_otg_vbus_notifier;
-   ret = extcon_register_interest(&motg->vbus.conn, ext_vbus->name,
-  "USB", &motg->vbus.nb);
+   ret = extcon_register_notifier(ext_vbus, EXTCON_USB,
+   &motg->vbus.nb);
if (ret < 0) {
dev_err(&pdev->dev, "register VBUS notifier failed\n");
return ret;
}
 
-   ret = extcon_get_cable_state(ext_vbus, "USB");
+   ret = extcon_get_cable_state_(ext_vbus, EXTCON_USB);
if (ret)
set_bit(B_SESS_VLD, &motg->inputs);
else
@@ -1577,15 +1578,16 @@ static int msm_otg_read_dt(struct platform_device 
*pdev, struct msm_otg *motg)
}
 
if (!IS_ERR(ext_id)) {
+   motg->id.extcon = ext_id;
motg->id.nb.notifier_call = msm_otg_id_notifier;
-   ret = extcon_register_interest(&motg->id.conn, ext_id->name,
-  "USB-HOST", &motg->id.nb);
+   ret = extcon_register_notifier(ext_id, EXTCON_USB_HOST,
+   &motg->id.nb);
if (ret < 0) {
dev_err(&pdev->dev, "register ID notifier failed\n");
return ret;
}
 
-   ret = extcon_get_cable_state(ext_id, "USB-HOST");
+   ret = extcon_get_cable_state_(ext_id, EXTCON_USB_HOST);
if (ret)
clear_bit(ID, &motg->inputs);
else
@@ -1805,10 +1807,8 @@ static int msm_otg_remove(struct platform_device *pdev)
if (phy->otg->host || phy->otg->gadget)
return -EBUSY;
 
-   if (motg->id.conn.edev)
-   extcon_unregister_interest(&motg->id.conn);
-   if (motg->vbus.conn.edev)
-   extcon_unregister_interest(&motg->vbus.conn);
+   extcon_unregister_notifier(motg->id.extcon, EXTCON_USB_HOST, 
&motg->id.nb);
+   extcon_unregister_notifier(motg->vbus.extcon, EXTCON_USB, 
&motg->vbus.nb);
 
msm_otg_debugfs_cleanup();
cancel_delayed_work_sync(&motg->chg_work);
diff --git a/include/linux/usb/msm_hsusb.h b/include/linux/usb/msm_hsusb.h
index e55a1504266e..5df2c8f59aa0 100644
--- a/include/linux/usb/msm_hsusb.h
+++ b/include/linux/usb/msm_hsusb.h
@@ -128,7 +128,7 @@ struct msm_otg_platform_data {
  */
 struct msm_usb_cable {
struct notifier_block   nb;
-   struct extcon_specific_cable_nb conn;
+   struct extcon_dev   *extcon;
 };
 
 /**
-- 
1.8.5.5

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

[PATCH 4/5] usb: renesas_usbhs: Replace deprecated API of extcon

[Chanwoo Choi]

This patch removes the deprecated API of extcon and then use the new extcon API
with the unique id to indicate the each external connector (USB-HOST).
- extcon_get_cable_state(*edev, char *) -> extcon_get_cable_state_(*edev, id)

Cc: Greg Kroah-Hartman 
Cc: Felipe Balbi 
Cc: Yoshihiro Shimoda 
Cc: Sergei Shtylyov 
Cc: Yoshihiro Shimoda 
Cc: Peter Chen 
Cc: Varka Bhadram 
Cc: Takeshi Kihara 
Signed-off-by: Chanwoo Choi 
---
 drivers/usb/renesas_usbhs/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/renesas_usbhs/common.c 
b/drivers/usb/renesas_usbhs/common.c
index e8bf40808b39..7b98e1d9194c 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -388,7 +388,7 @@ static void usbhsc_hotplug(struct usbhs_priv *priv)
 
if (enable && !mod) {
if (priv->edev) {
-   cable = extcon_get_cable_state(priv->edev, "USB-HOST");
+   cable = extcon_get_cable_state_(priv->edev, 
EXTCON_USB_HOST);
if ((cable > 0 && id != USBHS_HOST) ||
(!cable && id != USBHS_GADGET)) {
dev_info(&pdev->dev,
-- 
1.8.5.5

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

[PATCH 0/5] usb: Replace deprecated API of extcon

[Chanwoo Choi]

This patch removes the deprecated API of extcon framwork
and then use the new extcon API with the unique id to indicate
the each external connector.

Th deprecated API with cable name as following:
- int extcon_register_interest(struct extcon_specific_cable_nb *obj,
const char *extcon_name,
const char *cable_name,
struct notifier_block *nb);
- int extcon_unregister_interest(struct extcon_specific_cable_nb *nb);
- int extcon_get_cable_state(struct extcon_dev *edev, const char *cable_name);
- int extcon_set_cable_state(struct extcon_dev *edev, const char *cable_name,
bool cable_state);

The recommeded API with unique id of each external connector as following:
- int extcon_register_notifier(struct extcon_dev *edev, unsigned int id,
struct notifier_block *nb);
- int extcon_unregister_notifier(struct extcon_dev *edev, unsigned int id,
struct notifier_block *nb);
- int extcon_get_cable_state_(struct extcon_dev *edev, unsigned int id);
- int extcon_set_cable_state_(struct extcon_dev *edev, unsigned int id,
bool cable_state);

Depends on:
This patch-set is based on latest linux.git[1] because this patch-set have
the dependency of extcon patches for Linux v4.2.
[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/

Chanwoo Choi (5):
  usb: dwc3: omap: Replace deprecated API of extcon
  usb: phy: omap-otg: Replace deprecated API of extcon
  usb: phy: tahvo: Use devm_extcon_dev_[allocate|register]() and replace 
deprecated API
  usb: renesas_usbhs: Replace deprecated API of extcon
  usb: phy: msm-usb: Replace deprecated API of extcon

 drivers/usb/dwc3/dwc3-omap.c   | 32 +---
 drivers/usb/phy/phy-msm-usb.c  | 20 ++--
 drivers/usb/phy/phy-omap-otg.c | 22 +++---
 drivers/usb/phy/phy-tahvo.c| 27 +--
 drivers/usb/renesas_usbhs/common.c |  2 +-
 include/linux/usb/msm_hsusb.h  |  2 +-
 6 files changed, 49 insertions(+), 56 deletions(-)

-- 
1.8.5.5

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

[PATCH 2/5] usb: phy: omap-otg: Replace deprecated API of extcon

[Chanwoo Choi]

This patch removes the deprecated notifier API of extcon framwork
and then use the new extcon API with the unique id to indicate
the each external connector (USB, USB-HOST).

Alter deprecated API as following:
- extcon_register_interest() -> extcon_register_notifier()
- extcon_get_cable_state(*edev, char *) -> extcon_get_cable_state_(*edev, id)

Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Signed-off-by: Chanwoo Choi 
---
 drivers/usb/phy/phy-omap-otg.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
index 56ee7603034b..12af8b1595ee 100644
--- a/drivers/usb/phy/phy-omap-otg.c
+++ b/drivers/usb/phy/phy-omap-otg.c
@@ -30,8 +30,7 @@ struct otg_device {
void __iomem*base;
boolid;
boolvbus;
-   struct extcon_specific_cable_nb vbus_dev;
-   struct extcon_specific_cable_nb id_dev;
+   struct extcon_dev   *extcon;
struct notifier_block   vbus_nb;
struct notifier_block   id_nb;
 };
@@ -106,6 +105,7 @@ static int omap_otg_probe(struct platform_device *pdev)
extcon = extcon_get_extcon_dev(config->extcon);
if (!extcon)
return -EPROBE_DEFER;
+   otd_dev->extcon = extcon;
 
otg_dev = devm_kzalloc(&pdev->dev, sizeof(*otg_dev), GFP_KERNEL);
if (!otg_dev)
@@ -118,20 +118,19 @@ static int omap_otg_probe(struct platform_device *pdev)
otg_dev->id_nb.notifier_call = omap_otg_id_notifier;
otg_dev->vbus_nb.notifier_call = omap_otg_vbus_notifier;
 
-   ret = extcon_register_interest(&otg_dev->id_dev, config->extcon,
-  "USB-HOST", &otg_dev->id_nb);
+   ret = extcon_register_notifier(extcon, EXTCON_USB_HOST, 
&otg_dev->id_nb);
if (ret)
return ret;
 
-   ret = extcon_register_interest(&otg_dev->vbus_dev, config->extcon,
-  "USB", &otg_dev->vbus_nb);
+   ret = extcon_register_notifier(extcon, EXTCON_USB, &otg_dev->vbus_nb);
if (ret) {
-   extcon_unregister_interest(&otg_dev->id_dev);
+   extcon_unregister_notifier(extcon, EXTCON_USB_HOST,
+   &otg_dev->id_nb);
return ret;
}
 
-   otg_dev->id = extcon_get_cable_state(extcon, "USB-HOST");
-   otg_dev->vbus = extcon_get_cable_state(extcon, "USB");
+   otg_dev->id = extcon_get_cable_state_(extcon, EXTCON_USB_HOST);
+   otg_dev->vbus = extcon_get_cable_state_(extcon, EXTCON_USB);
omap_otg_set_mode(otg_dev);
 
rev = readl(otg_dev->base);
@@ -147,9 +146,10 @@ static int omap_otg_probe(struct platform_device *pdev)
 static int omap_otg_remove(struct platform_device *pdev)
 {
struct otg_device *otg_dev = platform_get_drvdata(pdev);
+   struct extcon_dev *edev = otg_dev->extcon;
 
-   extcon_unregister_interest(&otg_dev->id_dev);
-   extcon_unregister_interest(&otg_dev->vbus_dev);
+   extcon_unregister_notifier(edev, EXTCON_USB_HOST,&otg_dev->id_nb);
+   extcon_unregister_notifier(edev, EXTCON_USB, &otg_dev->vbus_nb);
 
return 0;
 }
-- 
1.8.5.5

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

[PATCH] USB XHCI: Bugfix for NULL pointer deference in xhci_endpoint_init() function

[AMAN DEEP]

virt_dev->num_cached_rings counts on freed ring and 
is not updated correctly. In xhci_free_or_cache_endpoint_ring() function, 
the free ring is added into cache and then 
num_rings_cache is incremented as below:
virt_dev->ring_cache[rings_cached] =
virt_dev->eps[ep_index].ring;
virt_dev->num_rings_cached++;
here, free ring pointer is added to a current index and then 
index is incremented.
So current index always points to empty location in the ring cache.
For getting available free ring, 
current index should be decremented first and then
corresponding ring buffer value should be taken from ring cache.

But In function xhci_endpoint_init(), 
the num_rings_cached index is accessed before decrement.
virt_dev->eps[ep_index].new_ring =
virt_dev->ring_cache[virt_dev->num_rings_cached];
virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
virt_dev->num_rings_cached--;
This is bug in manipulating the index of ring cache.
And it should be as below:
virt_dev->num_rings_cached--;
virt_dev->eps[ep_index].new_ring =
virt_dev->ring_cache[virt_dev->num_rings_cached];
virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;

Signed-off-by: Aman Deep 
---
 drivers/usb/host/xhci-mem.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index f833640..3e442f7 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1427,10 +1427,10 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
/* Attempt to use the ring cache */
if (virt_dev->num_rings_cached == 0)
return -ENOMEM;
+   virt_dev->num_rings_cached--;
virt_dev->eps[ep_index].new_ring =
virt_dev->ring_cache[virt_dev->num_rings_cached];
virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
-   virt_dev->num_rings_cached--;
xhci_reinit_cached_ring(xhci, virt_dev->eps[ep_index].new_ring,
1, type);
}
-- 
1.7.9.5

Re: [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP.

[Greg KH]

On Tue, Jun 30, 2015 at 10:34:25PM -0500, Jeremy White wrote:
> >
> >It's pointless to post a patch that you know has problems with it (i.e.
> >it's not even in proper kernel coding style), as it will never be
> >reviewed or even looked at.
> 
> Thanks for the reply, and I'm sorry for the clumsy ask.
> 
> I would still appreciate feedback on two points:
> 
>   1.  Is the basic premise reasonable?  Is Hans correct in asserting that an
> alternate USB over IP module will be considered?

I have no idea, if it fully replaces the usbip functionality, I don't
see why that would be rejected.  But why can't you just fix up usbip for
the issues you find lacking?

>   2.  Do I correctly understand that there are no circumstances where copied
> code can be left unmodified?  Even in the case where the copied code is
> working, production code, and the changes would be just for style?

I doubt the changes would just be for "style" if you are craming it into
the kernel tree, as it's a totally different environment from any other
place this code might have been running in before.

> >Please do the most basic of polite things and fix this up before posting
> >things.
> 
> It is often difficult for a newcomer to know what the polite thing is, even
> after studying FAQs and documentation.

Did you read Documentation/SubmittingPatches?

> I appreciate your patience (and clue bats) as I try to learn.
> 
> >
> >And really, all in one patch?  That too is pretty hard to review...
> 
> Yeah.  I see the point of pain.  I did not see a solution as I formed the
> patch, but I'll try harder before resending.

Remember you need to make this trivial to review in order to get it
accepted.  You have to do extra work because of this because our limited
resource is reviewers and maintainers, not developers.

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

Cannot use the logitech k520 (046d:c52b) to unlock my luks disk at boot time

[Glasswall Information Point]

Bug as submitted on: https://bugzilla.kernel.org/show_bug.cgi?id=100631

Mailing it to this mailing list on advice of greg k-h

--

Cannot use the logitech k520 (046d:c52b) to unlock my luks disk at boot time

 Hitting keyboard keys of this specific kayboard does not register while 
entering the disk unlock password

In the 3.x mail line kernels this does work.
in the 4.1 mainline kernel a corded hid keyboard does work but this specific 
keyboard does not work anymore.

The keybaord works fine after boot



- dmesg snippet of connecting the keybaord after boot 
- I added this because there might be some valueable device 
info in it

[   99.360175] usb 1-1.3: new full-speed USB device number 7 using xhci_hcd
[   99.451438] usb 1-1.3: New USB device found, idVendor=046d, idProduct=c52b
[   99.451447] usb 1-1.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[   99.451451] usb 1-1.3: Product: USB Receiver
[   99.451455] usb 1-1.3: Manufacturer: Logitech
[   99.457673] logitech-djreceiver 0003:046D:C52B.000F: hiddev0,hidraw0: USB 
HID v1.11 Device [Logitech USB Receiver] on usb-:00:14.0-1.3/input2
[   99.585367] input: Logitech M310 as 
/devices/pci:00/:00:14.0/usb1/1-1/1-1.3/1-1.3:1.2/0003:046D:C52B.000F/0003:046D:1024.0010/input/input28
[   99.585525] logitech-hidpp-device 0003:046D:1024.0010: input,hidraw1: USB 
HID v1.11 Mouse [Logitech M310] on usb-:00:14.0-1.3:1
[   99.629488] input: Logitech K520 as 
/devices/pci:00/:00:14.0/usb1/1-1/1-1.3/1-1.3:1.2/0003:046D:C52B.000F/0003:046D:2011.0011/input/input29
[   99.629596] logitech-hidpp-device 0003:046D:2011.0011: input,hidraw2: USB 
HID v1.11 Keyboard [Logitech K520] on usb-:00:14.0-1.3:2

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