Re: Suspected (out of tree) HCI issue

[Vincent Pelletier]

On Wed, 26 Nov 2014 16:25:08 -0500 (EST), Alan Stern
 wrote:
> Since this driver seems to be based on work by Synopsys, maybe someone
> from that company can help.
> 
> (By the way, the license information in the ifxhcd.h header file 
> doesn't say anything about the GPL.  That doesn't seem kosher.)

Actually the topmost chunk, mentioning Lantiq copyright, does. But it
also says parts (which ?) are copyright Synopsys with a "redistribute
but keep this notice" licence.

> So at time 100.332 the URB completes and the completion routine
> resubmits it.  At time 101.436 the driver tries to kill the URB.  At
> 101.440 the URB completes (presumably with a status code indicating
> that it was killed) and the completion routine resubmits it.  
> Evidently the resubmission succeeds, because usb_hcd_submit_urb's
> atomic_dec is not hit.
> 
> Resubmission of a killed URB is not supposed to succeed.

Aha, this may just be what I was missing. I was aiming at getting
use_count down by finding some missing completion call, rather than
questioning that last submission's success.

> If it does, it means there's a bug in the HCD: It isn't calling 
> usb_hcd_link_urb_to_ep() properly.

Indeed, no trace of this function being called.

> Maybe you can adapt an in-tree HCD to work with your host controller 
> hardware.  The ifxhcd driver doesn't look so hot, at first glance.  
> Maybe it can be fixed up...

Looking at drivers/usb/host I see quite short files which I understand
as hardware-specific (ex: 551 lines for ehci-terga.c). Such length
should be in my reach, but the 6k lines of some non-[eo]hci are very
likely not. I'll try to understand how this controller would fit in.

Thanks a lot for your answers,
-- 
Vincent Pelletier
--
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: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN

[Greg Kroah-Hartman]

On Wed, Nov 26, 2014 at 09:39:36PM +0100, Sebastian Andrzej Siewior wrote:
> the following error pops up during "testusb -a -t 10"
> | musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128,   
> f134e000/be842000 (bad dma)
> hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
> size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
> hcd_buffer_alloc() returning memory which is 32bytes aligned and it
> might by identified by buffer_offset() as another buffer. This means the
> buffer which is on a 32byte boundary will not get freed, instead it
> tries to free another buffer with the error message.
> 
> This patch fixes the issue by creating the smallest DMA buffer with the
> size of ARCH_DMA_MINALIGN. This will be either 32 or 64 bytes. If the
> ARCH_DMA_MINALIGN is 128 (currently powerpc64, mips ip32, x86 pentium 4) then
> it will create the first buffer with 128 bytes and will have only 3
> buffers. There is a BUILD_BUG_ON() now in case someone has a minalign of
> more than 128 bytes.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Sebastian Andrzej Siewior 
> Acked-by: Alan Stern 
> ---
> v1…v2: rewrite pool_max so it is less confusing.
> 
>  drivers/usb/core/buffer.c | 12 
>  include/linux/usb/hcd.h   |  8 ++--
>  2 files changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
> index 684ef70dc09d..5ad5f71d6358 100644
> --- a/drivers/usb/core/buffer.c
> +++ b/drivers/usb/core/buffer.c
> @@ -26,10 +26,13 @@ static const size_t   pool_max[HCD_BUFFER_POOLS] = {
>   /* platforms without dma-friendly caches might need to
>* prevent cacheline sharing...
>*/
> - 32,
> - 128,
> - 512,
> - PAGE_SIZE / 2
> +#if ARCH_KMALLOC_MINALIGN <= 32
> + 32, 128, 512, PAGE_SIZE / 2,
> +#elif ARCH_KMALLOC_MINALIGN <= 64
> + 64, 128, 512, PAGE_SIZE / 2,
> +#else
> + 128, 512, PAGE_SIZE / 2
> +#endif
G>  /* bigger --> allocate pages */
>  };
>  
> @@ -58,6 +61,7 @@ int hcd_buffer_create(struct usb_hcd *hcd)
>   !(hcd->driver->flags & HCD_LOCAL_MEM))
>   return 0;
>  
> + BUILD_BUG_ON(ARCH_KMALLOC_MINALIGN > 128);
>   for (i = 0; i < HCD_BUFFER_POOLS; i++) {
>   size = pool_max[i];
>   if (!size)
> diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
> index cd96a2bc3388..1e2234ca448d 100644
> --- a/include/linux/usb/hcd.h
> +++ b/include/linux/usb/hcd.h
> @@ -23,6 +23,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #define MAX_TOPO_LEVEL   6
>  
> @@ -171,8 +172,11 @@ struct usb_hcd {
>   struct usb_hcd  *shared_hcd;
>   struct usb_hcd  *primary_hcd;
>  
> -
> -#define HCD_BUFFER_POOLS 4
> +#if ARCH_KMALLOC_MINALIGN <= 64
> + #define HCD_BUFFER_POOLS4
> +#else
> + #define HCD_BUFFER_POOLS3
> +#endif
>   struct dma_pool *pool[HCD_BUFFER_POOLS];
>  
>   int state;

This breaks the build so badly, it's obvious you never tested it out.

never do that again.

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

Re: [PATCH v2] usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN

[Greg Kroah-Hartman]

On Wed, Nov 26, 2014 at 04:27:27PM -0500, Alan Stern wrote:
> On Wed, 26 Nov 2014, Sebastian Andrzej Siewior wrote:
> 
> > the following error pops up during "testusb -a -t 10"
> > | musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128, 
> > f134e000/be842000 (bad dma)
> > hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
> > size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
> > hcd_buffer_alloc() returning memory which is 32bytes aligned and it
> > might by identified by buffer_offset() as another buffer. This means the
> > buffer which is on a 32byte boundary will not get freed, instead it
> > tries to free another buffer with the error message.
> > 
> > This patch fixes the issue by creating the smallest DMA buffer with the
> > size of ARCH_DMA_MINALIGN. This will be either 32 or 64 bytes. If the
> > ARCH_DMA_MINALIGN is 128 (currently powerpc64, mips ip32, x86 pentium 4) 
> > then
> > it will create the first buffer with 128 bytes and will have only 3
> > buffers. There is a BUILD_BUG_ON() now in case someone has a minalign of
> > 128 bytes or more.
> 
> More than 128 bytes.  Not "128 bytes or more".

edited by hand, 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 06/19] usb: dwc3: host: Pass the XHCI_DRD_SUPPORT and XHCI_NEEDS_LHC_RESET quirk

[Lu, Baolu]

On 2014年11月25日 21:11, George Cherian wrote:

Pass the quir flag XHCI_DRD_SUPPORT from DWC3 host to xhci platform driver.

"quir" to "quirk"

Regards,
Baolu


This enables xhci driver to handle deallocation's differently while in DRD mode.
Pass the quirk flag XHCI_NEEDS_LHC_RESET from DWC3 host to xhci platform
driver. This enables to do LHRESET during xhci_reset().

Signed-off-by: George Cherian 
---
  drivers/usb/dwc3/host.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index dcb8ca0..257b5b5 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -53,6 +53,8 @@ int dwc3_host_init(struct dwc3 *dwc)
  #ifdef CONFIG_DWC3_HOST_USB3_LPM_ENABLE
pdata.usb3_lpm_capable = 1;
  #endif
+   pdata.usb_drd_support = 1;
+   pdata.usb_needs_lhc_reset = 1;
  
  	ret = platform_device_add_data(xhci, &pdata, sizeof(pdata));

if (ret) {


--
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: Lubbock interrupts fix (was lubbock udc phy)

[Dmitry Eremin-Solenikov]

2014-11-27 1:38 GMT+03:00 Robert Jarzmik :
> Dmitry Eremin-Solenikov  writes:
>
>> 2014-11-27 1:12 GMT+03:00 Robert Jarzmik :
>>> OK Dmitry, I pulled through, the interrupts are working back.
>>
>> What was the problem? Hardware issues? Firmware in CPLD being of old
>> revision?
> There were basically 2 problems :
>  - hardware: switch S13 was in a position that disabled interrupts all the 
> time
>One other problem which fooled me was the incorrect gate schematics I had,
>and which make my understanding of linear function foo such as
>GPIO0 = foo(LUB_IRQ_EN, LUB_SET_CLR) false.
>
>  - software: lubbock.c error
>Since gpio-pxa was ported to device/gpio, it is probed *after*
>lubbock_init_irq() is called. As lubbock_init_irq() installs
>lubbock_irq_handler() and sets the irq to falling edge detect before 
> gpio-pxa
>is probed, gpio-pxa probe overwrites this by :
>  - clearing any edge detection (probe state reset)
>  - installing generic handle_edge_irq() instead of the lubbock irq handler
>
> So the conclusion is that I have to rework lubbock_init_irq(), remove from it
> the PXA_GPIO_TO_IRQ(0) stuff, and move it to a code in lubbock.c which will
> provide the guarantee of being executed _after_ gpio-pxa is probed. When I'm
> happy with my patch I'll submit it.

Thank you for your explanation.

-- 
With best wishes
Dmitry
--
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

Lubbock interrupts fix (was lubbock udc phy)

[Robert Jarzmik]

Dmitry Eremin-Solenikov  writes:

> 2014-11-27 1:12 GMT+03:00 Robert Jarzmik :
>> OK Dmitry, I pulled through, the interrupts are working back.
>
> What was the problem? Hardware issues? Firmware in CPLD being of old
> revision?
There were basically 2 problems :
 - hardware: switch S13 was in a position that disabled interrupts all the time
   One other problem which fooled me was the incorrect gate schematics I had,
   and which make my understanding of linear function foo such as
   GPIO0 = foo(LUB_IRQ_EN, LUB_SET_CLR) false.

 - software: lubbock.c error
   Since gpio-pxa was ported to device/gpio, it is probed *after*
   lubbock_init_irq() is called. As lubbock_init_irq() installs
   lubbock_irq_handler() and sets the irq to falling edge detect before gpio-pxa
   is probed, gpio-pxa probe overwrites this by :
 - clearing any edge detection (probe state reset)
 - installing generic handle_edge_irq() instead of the lubbock irq handler

So the conclusion is that I have to rework lubbock_init_irq(), remove from it
the PXA_GPIO_TO_IRQ(0) stuff, and move it to a code in lubbock.c which will
provide the guarantee of being executed _after_ gpio-pxa is probed. When I'm
happy with my patch I'll submit it.

Cheers.

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

Re: [PATCH V2 3/5] usb: gadget: pxa25x_udc: prepare/unprepare clocks in pxa-ssp

[Dmitry Eremin-Solenikov]

2014-11-27 1:12 GMT+03:00 Robert Jarzmik :
> OK Dmitry, I pulled through, the interrupts are working back.

What was the problem? Hardware issues? Firmware in CPLD being of old
revision?

> Actually one of the blockers I have is in pxa25x_udc, and it is also in your
> phy-lubbock.c. The bottom of the error is that disable_irq() is called from
> within a irq handler, and it deadlocks. A disable_irq_nosync() should be used
> ...
>
> ... but a better approach would be to use a threaded irq for vbus handling. I
> think that way disable_irq() can be used, no workqueue is needed anymore in
> phy-lubbock.
>
> Would you make that change, I'll test it and review it.

OK, I will take a look in a next few days.

BTW: I have also received a pxa270 board (Sophia Sandgate II, the one
without the additional graphics accelerator), so after spending some efforts
on bringup & bsp, I should be able to also test pxa270 code.

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

Re: [PATCH V2 3/5] usb: gadget: pxa25x_udc: prepare/unprepare clocks in pxa-ssp

[Robert Jarzmik]

OK Dmitry, I pulled through, the interrupts are working back.

Actually one of the blockers I have is in pxa25x_udc, and it is also in your
phy-lubbock.c. The bottom of the error is that disable_irq() is called from
within a irq handler, and it deadlocks. A disable_irq_nosync() should be used
...

... but a better approach would be to use a threaded irq for vbus handling. I
think that way disable_irq() can be used, no workqueue is needed anymore in
phy-lubbock.

Would you make that change, I'll test it and review it.

Cheers.

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

Re: [PATCH] usb: gadget: zero: fix INT endpoint assignment

[Alan Stern]

On Wed, 26 Nov 2014, Sebastian Andrzej Siewior wrote:

> On 11/26/2014 04:24 PM, Alan Stern wrote:
> >> On 11/25/2014 10:52 PM, Sebastian Andrzej Siewior wrote:
> >>> The max packet size within the FS descriptor has to be highest possible
> >>> value and _not_ the one that is (or will be) used on FS.
> >>
> >> The current code sets wMaxPacketSize of FS interrupt endpoint descriptor 
> >> as 64, which is in accordance with the usb 2.0 specification, section 5.7.3
> >>
> >>The maximum allowable interrupt data payload size is 64 bytes
> >>or less for full-speed. High-speed endpoints are allowed
> >>maximum data payload sizes up to 1024 bytes.
> > 
> > The real problem is that we are assuming endpoints can be allocated in
> > a single way that will work correctly for all possible connection
> > speeds.  (I suspect it was done this way out of laziness and a desire
> > to minimize the code size.)  This assumption is obviously incorrect
> > when the hardware has an interrupt endpoint that supports packet sizes
> > of 64 but no larger.
> 
> The code will check properly if you pass 1024 and check the size
> accordingly. You have to "downsize" your FS descriptor later. This
> function will only fail to do this if your gadget isn't dual speed. In
> that case it expects 64 as the upper limit for INT (if I recall
> correctly).

It will also fail in situations where you use up a lot of endpoints.  
For example, let's say the UDC only supports 4 endpoints, one of which
must have a maxpacket value <= 64.  If you want to have four interrupt
endpoints, you can't run at high speed -- but you can run at full
speed.  However, the approach you outlined above won't allow it.

> But what you can't do (and this is done by ISOC and INT endpoint) is to
> upgrade your capabilities by increasing the max packet size after you
> received an endpoint. This "works" for ISOC because on FS you can use
> up to 1023 bytes and the matching FIFO has usually 1024 bytes and not
> 1023. It isn't correct but it works.
> 
> This was done out of laziness and "simplicity" as far as I recall.
> Usually the only difference between FS and HS is 0 so the only thing
> you do is to update the bEndpointAddress member in HS/SS descriptors.
> Nothing more. Most INT don't care for 1024 transfer size or anything
> like that and the first gadgets in kernel were not ISOC and even these
> days their MPS is < 200.
> 
> So it was easy just to update the endpoint address for the HS
> descriptor, you used the same endpoint as for FS. Most in tree gadgets
> don't do more.
> 
> > The right way to fix the problem is to avoid allocating endpoints until 
> > after the connection speed is known.  Then we can call 
> > usb_ep_autoconfig() with the appropriate set of descriptors, and 
> > nothing will need to be fixed up.
> > 
> > However, I don't know if this approach is compatible with the composite 
> > framework in its current form.
> 
> I've been looking at this mess by the time I started the configfs. I
> tried a few times and decided not now and there was no later.
> You need all descriptors prior you connect / at bind time. At this time
> you need also your endpoints allocated. A small change to this breaks
> things in multiple places therefore the created configfs gadget is
> "bound" once it is complete. I tried even to have "one descriptor" and
> let the code create HS/SS descriptors out of it (since in 99% they are
> the same) but a few gadgets did more and I dropped that idea again.
> 
> So this is what is expected in most parts of the code as of now. Then
> you have USB_DT_OTHER_SPEED_CONFIG where you may ask for HS descriptors
> on a FS link. So you need those.

You're right.  It looks like we need to set up separate allocations of
endpoints for all possible connection speeds, during initialization.  
If one of the allocations fails then the gadget must not be allowed to
connect at that speed.  (Unfortunately the gadget framework doesn't
include any method for telling the hardware not to connect at a certain
speed...)

> All in all I tried to minimize the effects by leaving the descriptors
> "untouched" and creating a copy after bind. I didn't manage to redo the
> endpoint allocation.
> Part of the problem is that you have no clear cut currently between
> descriptor preparation and endpoint allocation. The endpoint allocator
> does not know about HS/FS/SS. It knows that there is an endpoint, it
> can do all speeds and has a special special upper limit (it may not be
> able to INT or BULK or ISOC so it considers that as well).
> Once it finds a match, it writes the endpoint address into the
> descriptor and returns the pointer to the endpoint. So technically you
> return two values here. The endpoint is considered taken once
> ep->private is set (so it is a little racy).
> Based on this you can't get the same endpoint on HS because it is gone.
> You could but then you get another one. it will work but is a waste of
> resources.
> 
> Ah. And endpoints a

Re: [PATCH v2] usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN

[Alan Stern]

On Wed, 26 Nov 2014, Sebastian Andrzej Siewior wrote:

> the following error pops up during "testusb -a -t 10"
> | musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128,   
> f134e000/be842000 (bad dma)
> hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
> size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
> hcd_buffer_alloc() returning memory which is 32bytes aligned and it
> might by identified by buffer_offset() as another buffer. This means the
> buffer which is on a 32byte boundary will not get freed, instead it
> tries to free another buffer with the error message.
> 
> This patch fixes the issue by creating the smallest DMA buffer with the
> size of ARCH_DMA_MINALIGN. This will be either 32 or 64 bytes. If the
> ARCH_DMA_MINALIGN is 128 (currently powerpc64, mips ip32, x86 pentium 4) then
> it will create the first buffer with 128 bytes and will have only 3
> buffers. There is a BUILD_BUG_ON() now in case someone has a minalign of
> 128 bytes or more.

More than 128 bytes.  Not "128 bytes or more".

> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Sebastian Andrzej Siewior 
> ---
> v1…v2: rewrite pool_max so it is less confusing.

Acked-by: 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: Suspected (out of tree) HCI issue

[Vincent Pelletier]

On Wed, 26 Nov 2014 21:18:55 +0100, Vincent Pelletier
 wrote:
> with the only visible improvement of not getting errors when
> unplugging the modem on stuck process.

...actually, not even, I was expecting errors on the wrong terminal:
they are still present.

Just for the record, here is an entire gcom run output with my printks
(one line offset from removing show_stack call).
Lock at 68.744 and unplug at 79.920 .

[   66.956000] 81bd0380->use_count 1 drivers/usb/core/hcd.c:1553
[   66.964000] 83accd80->use_count 1 drivers/usb/core/hcd.c:1553
[   66.968000] 83accd00->use_count 1 drivers/usb/core/hcd.c:1553
[   66.972000] 81bd0380->use_count 2 drivers/usb/core/hcd.c:1553
[   66.972000] 81bd0380->use_count 1 drivers/usb/core/hcd.c:1690
[   66.984000] 83accc80->use_count 1 drivers/usb/core/hcd.c:1553
[   66.992000] 83accc00->use_count 1 drivers/usb/core/hcd.c:1553
[   66.996000] 814c5480->use_count 1 drivers/usb/core/hcd.c:1553
[   67.004000] 814c5480->use_count 0 drivers/usb/core/hcd.c:1690
[   67.528000] 83accb80->use_count 1 drivers/usb/core/hcd.c:1553
[   67.532000] 83accb80->use_count 0 drivers/usb/core/hcd.c:1690
[   67.54] 83accd80->use_count 2 drivers/usb/core/hcd.c:1553
[   67.54] 83accd80->use_count 1 drivers/usb/core/hcd.c:1690
[   67.572000] 83accb80->use_count 1 drivers/usb/core/hcd.c:1553
[   67.576000] 83accb80->use_count 0 drivers/usb/core/hcd.c:1690
[   67.58] 83accd00->use_count 2 drivers/usb/core/hcd.c:1553
[   67.58] 83accd00->use_count 1 drivers/usb/core/hcd.c:1690
[   67.616000] 83accb80->use_count 1 drivers/usb/core/hcd.c:1553
[   67.62] 83accb80->use_count 0 drivers/usb/core/hcd.c:1690
[   67.624000] 83accc80->use_count 2 drivers/usb/core/hcd.c:1553
[   67.624000] 83accc80->use_count 1 drivers/usb/core/hcd.c:1690
[   67.66] 83accb80->use_count 1 drivers/usb/core/hcd.c:1553
[   67.664000] 83accb80->use_count 0 drivers/usb/core/hcd.c:1690
[   67.668000] 83accc00->use_count 2 drivers/usb/core/hcd.c:1553
[   67.668000] 83accc00->use_count 1 drivers/usb/core/hcd.c:1690
[   67.68] 83accd80->use_count 2 drivers/usb/core/hcd.c:1553
[   67.68] 83accd80->use_count 1 drivers/usb/core/hcd.c:1690
[   68.72] 814e6700->use_count 1 drivers/usb/core/hcd.c:1553
[   68.724000] 814e6700->use_count 0 drivers/usb/core/hcd.c:1690
[   68.732000] IFXUSB: 83accd80 urbd->phase 0
[   68.732000] 83accd80->use_count 2 drivers/usb/core/hcd.c:1553
[   68.732000] 83accd80->use_count 1 drivers/usb/core/hcd.c:1690
[   68.744000] wait_event 83accd80
[   79.92] 83accd00->use_count 2 drivers/usb/core/hcd.c:1553
[   79.92] 83accd00->use_count 1 drivers/usb/core/hcd.c:1582
[   79.92] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb 
failed. (-19)
[   79.936000] 83accd00->use_count 0 drivers/usb/core/hcd.c:1690
[   79.94] 83accc80->use_count 2 drivers/usb/core/hcd.c:1553
[   79.94] 83accc80->use_count 1 drivers/usb/core/hcd.c:1582
[   79.94] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb 
failed. (-19)
[   79.96] 83accc80->use_count 0 drivers/usb/core/hcd.c:1690
[   79.968000] 83accc00->use_count 2 drivers/usb/core/hcd.c:1553
[   79.968000] 83accc00->use_count 1 drivers/usb/core/hcd.c:1582
[   79.968000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb 
failed. (-19)
[   79.988000] 83accc00->use_count 0 drivers/usb/core/hcd.c:1690
[   79.992000] 83accd80->use_count 2 drivers/usb/core/hcd.c:1553
[   79.992000] 83accd80->use_count 1 drivers/usb/core/hcd.c:1582
[   79.992000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb 
failed. (-19)
[   80.012000] 83accd80->use_count 0 drivers/usb/core/hcd.c:1690
[   80.016000] option1 ttyUSB0: option_instat_callback: error -150
[   80.016000] 81bd0380->use_count 2 drivers/usb/core/hcd.c:1553
[   80.016000] 81bd0380->use_count 1 drivers/usb/core/hcd.c:1582
[   80.036000] 81bd0380->use_count 0 drivers/usb/core/hcd.c:1690
[   80.04] 81d25a80->use_count 2 drivers/usb/core/hcd.c:1553
[   80.044000] 81d25a80->use_count 1 drivers/usb/core/hcd.c:1690
[   80.052000] 814c5680->use_count 1 drivers/usb/core/hcd.c:1553
[   80.056000] 814c5680->use_count 0 drivers/usb/core/hcd.c:1690
[   80.068000] 814c5680->use_count 1 drivers/usb/core/hcd.c:1553
[   80.072000] 814c5680->use_count 0 drivers/usb/core/hcd.c:1690
[   80.084000] 814c5680->use_count 1 drivers/usb/core/hcd.c:1553
[   80.088000] 814c5680->use_count 0 drivers/usb/core/hcd.c:1690
[   80.104000] wait_event 83accd00
[   80.104000] wait_event 83accc80
[   80.108000] wait_event 83accc00
[   80.112000] wait_event 83accb80
[   80.112000] wait_event 81bd0380
[   80.116000] usb 1-1: USB disconnect, device number 3
[   80.14] option1 ttyUSB0: GSM modem (1-port) converter now disconnected 
from ttyUSB0
[   80.164000] option 1-1:1.0: device disconnected
[   80.168000] option1 ttyUSB1: GSM modem (1-port) converter now disconnected 
from ttyUSB1
[   80.196000] option 1-1:1.1: device disconnected

(please keep me cc'ed in replies)
-- 
Vince

Re: Suspected (out of tree) HCI issue

[Alan Stern]

On Wed, 26 Nov 2014, Vincent Pelletier wrote:

> Hi.
> 
> (please keep me cc'ed in replies, I'm not subscribed)
> 
> I'm trying OpenWRT on a DSL modem[1] which has an out-of-tree HCI
> driver. I'm getting one particular process to hang in D 100% of time
> when talking to a 3G USB modem. I'm on current default OpenWRT kernel,
> 3.14.18 .
> 
> Here is the hung process:
> 
> root@OpenWrt:/# echo w > /proc/sysrq-trigger
> [   98.16] SysRq : Show Blocked State
> [   98.16]   taskPC stack   pid father
> [   98.16] gcomD 8030861c 0  2228   2188 0x08100020
> [   98.16] Stack : 81bde880 0001  80307b18 81bde880 80435698 
> 81bde88c 80414c60
> 81d213c0 0001 8041 81bb7180 0001 8030861c 81bcd480 
> 81452e00
> 81452e00 803a  814bf070 8007fc04 80435698 80435698 
> 81452e00
> 803a 0004 81d21380 0010 81be2800 81828900  
> 81d08c28
>   81be2804 81be2884 81452e00 803a  
> 81d08c28
> ...
> [   98.16] Call Trace:
> [   98.16] [<8000d954>] __schedule+0x4cc/0x578
> [   98.16] [<8030861c>] usb_kill_urb+0xe0/0x164
> [   98.16] [<81828900>] usb_wwan_close+0x100/0x2e4 [usb_wwan]
> [   98.16] [<802b6e8c>] tty_port_shutdown+0xc0/0xdc
> [   98.16] [<802b64ac>] tty_port_close+0x30/0xa4
> [   98.16] [<802b7918>] tty_release+0x168/0x524
> [   98.16] [<80041038>] __fput+0xf8/0x274
> [   98.16] [<80289560>] task_work_run+0xf0/0x128
> [   98.16] [<800ef3d0>] do_exit+0x3fc/0x858
> [   98.16] [<800f154c>] do_group_exit+0x78/0xb4
> [   98.16] [<800198a8>] SyS_faccessat+0x0/0x250

Broadly speaking, this means the kernel is waiting for a completion 
interrupt which never arrives.  The interrupt would indicate that the 
controller hardware has finished accessing the data structures 
belonging to the URB being killed.

> As can be seen, it is while cleaning up process resources on exit (at
> kernel level) that the hang happens. If I unplug the modem, process
> exits and I get the following output:
> [ 2862.228000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb 
> failed. (-19)
> [ 2862.236000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb 
> failed. (-19)
> [ 2862.244000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb 
> failed. (-19)
> [ 2862.252000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb 
> failed. (-19)
> [ 2862.26] option1 ttyUSB0: option_instat_callback: error -150
> 
> Here is the HCD driver source code:
>   
> http://git.openwrt.org/?p=openwrt.git;a=tree;f=package/kernel/lantiq/ltq-hcd/src;h=926980738d4eb39d78fdf116fe4f2f787040fa1d;hb=fee2d7ec702586850e0eafbd82f43c851d1c45b3
> (to the revision I'm at locally, which is 2 days old as I'm writing
> this, and no change since touch this path)

Since this driver seems to be based on work by Synopsys, maybe someone
from that company can help.

(By the way, the license information in the ifxhcd.h header file 
doesn't say anything about the GPL.  That doesn't seem kosher.)

> Poking around with printk debugging (*cough*), I found that the URB
> __schedule is waiting upon has a use_count of 1. Adding printks after
> the 2 atomic_dec and the only atomic_inc on it, I see this URB's history
> as:
> 
> [   99.284000] 81ae2900->use_count 1 drivers/usb/core/hcd.c:1553
> [   99.916000] 81ae2900->use_count 2 drivers/usb/core/hcd.c:1553
> [   99.916000] 81ae2900->use_count 1 drivers/usb/core/hcd.c:1691
> [  100.332000] 81ae2900->use_count 2 drivers/usb/core/hcd.c:1553
> [  100.332000] 81ae2900->use_count 1 drivers/usb/core/hcd.c:1691
> [  101.436000] IFXUSB: 81ae2900 urbd->phase 0
> [  101.44] 81ae2900->use_count 2 drivers/usb/core/hcd.c:1553
> [  101.44] 81ae2900->use_count 1 drivers/usb/core/hcd.c:1691
> [  101.512000] wait_event 81ae2900
> 
> 1553 is right after usb_hcd_submit_urb's atomic_inc
> 1691 is right after __usb_hcd_giveback_urb's atomic_dec
> usb_hcd_submit_urb's atomic_dec is not hit.
> 
> The IFXUSB line is the HCD driver's ifxhcd_urb_dequeue telling it is
> dequeueing the URB, currently in given phase (here 0, so URBD_IDLE).
> wait_event line is usb_kill_urb calling wait_event or given URB.
> This URB does not appear at any time before 99.284, when I started gcom.

So at time 100.332 the URB completes and the completion routine
resubmits it.  At time 101.436 the driver tries to kill the URB.  At
101.440 the URB completes (presumably with a status code indicating
that it was killed) and the completion routine resubmits it.  
Evidently the resubmission succeeds, because usb_hcd_submit_urb's
atomic_dec is not hit.

Resubmission of a killed URB is not supposed to succeed.  If it does, 
it means there's a bug in the HCD: It isn't calling 
usb_hcd_link_urb_to_ep() properly.

That's the problem with using out-of-tree drivers -- they don't track 
changes to the rest of the kernel.  :-(

> Is it legal for use_count 

[PATCH v2] usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN

[Sebastian Andrzej Siewior]

the following error pops up during "testusb -a -t 10"
| musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128, f134e000/be842000 (bad 
dma)
hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
hcd_buffer_alloc() returning memory which is 32bytes aligned and it
might by identified by buffer_offset() as another buffer. This means the
buffer which is on a 32byte boundary will not get freed, instead it
tries to free another buffer with the error message.

This patch fixes the issue by creating the smallest DMA buffer with the
size of ARCH_DMA_MINALIGN. This will be either 32 or 64 bytes. If the
ARCH_DMA_MINALIGN is 128 (currently powerpc64, mips ip32, x86 pentium 4) then
it will create the first buffer with 128 bytes and will have only 3
buffers. There is a BUILD_BUG_ON() now in case someone has a minalign of
128 bytes or more.

Cc: sta...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior 
---
v1…v2: rewrite pool_max so it is less confusing.

 drivers/usb/core/buffer.c | 12 
 include/linux/usb/hcd.h   |  8 ++--
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index 684ef70dc09d..5ad5f71d6358 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -26,10 +26,13 @@ static const size_t pool_max[HCD_BUFFER_POOLS] = {
/* platforms without dma-friendly caches might need to
 * prevent cacheline sharing...
 */
-   32,
-   128,
-   512,
-   PAGE_SIZE / 2
+#if ARCH_KMALLOC_MINALIGN <= 32
+   32, 128, 512, PAGE_SIZE / 2,
+#elif ARCH_KMALLOC_MINALIGN <= 64
+   64, 128, 512, PAGE_SIZE / 2,
+#else
+   128, 512, PAGE_SIZE / 2
+#endif
/* bigger --> allocate pages */
 };
 
@@ -58,6 +61,7 @@ int hcd_buffer_create(struct usb_hcd *hcd)
!(hcd->driver->flags & HCD_LOCAL_MEM))
return 0;
 
+   BUILD_BUG_ON(ARCH_KMALLOC_MINALIGN > 128);
for (i = 0; i < HCD_BUFFER_POOLS; i++) {
size = pool_max[i];
if (!size)
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index cd96a2bc3388..1e2234ca448d 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 
 #define MAX_TOPO_LEVEL 6
 
@@ -171,8 +172,11 @@ struct usb_hcd {
struct usb_hcd  *shared_hcd;
struct usb_hcd  *primary_hcd;
 
-
-#define HCD_BUFFER_POOLS   4
+#if ARCH_KMALLOC_MINALIGN <= 64
+   #define HCD_BUFFER_POOLS4
+#else
+   #define HCD_BUFFER_POOLS3
+#endif
struct dma_pool *pool[HCD_BUFFER_POOLS];
 
int state;
-- 
2.1.3

--
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 net] r8152: drop the tx packet with invalid length

[David Miller]

From: Eric Dumazet 
Date: Wed, 26 Nov 2014 10:44:19 -0800

> On Wed, 2014-11-26 at 12:06 -0500, David Miller wrote:
>> From: Eric Dumazet 
>> Date: Wed, 26 Nov 2014 08:52:28 -0800
>> 
>> > On Wed, 2014-11-26 at 17:56 +0800, Hayes Wang wrote:
>> >> Drop the tx packet which is more than the size of agg_buf_sz. When
>> >> creating a bridge with the device, we may get the tx packet with
>> >> TSO and the length is more than the gso_max_size which is set by
>> >> the driver through netif_set_gso_max_size(). Such packets couldn't
>> >> be transmitted and should be dropped directly.
>> >> 
>> >> Signed-off-by: Hayes Wang 
>>  ...
>> > Looks like a candidate for ndo_gso_check(), so that we do not drop, but
>> > instead segment from netif_needs_gso()/validate_xmit_skb()
>> 
>> You mean have the bridge implement the ndo_gso_check() method right?
> 
> No, I meant this particular driver.
> 
> Note that netif_skb_features() does only this check :
> 
> if (gso_segs > dev->gso_max_segs || gso_segs < dev->gso_min_segs)
>   features &= ~NETIF_F_GSO_MASK;
> 
> Ie not testing gso_max_size
> 
> It looks like all these particular tests should be moved on
> ndo_gso_check(), to remove code from netif_skb_features()

A check against gso_max_size is generic enough that it ought to be put
right into netif_needs_gso() rather then duplicating it into every
driver's ndo_gso_check() method don't you think?
--
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

Suspected (out of tree) HCI issue

[Vincent Pelletier]

Hi.

(please keep me cc'ed in replies, I'm not subscribed)

I'm trying OpenWRT on a DSL modem[1] which has an out-of-tree HCI
driver. I'm getting one particular process to hang in D 100% of time
when talking to a 3G USB modem. I'm on current default OpenWRT kernel,
3.14.18 .

Here is the hung process:

root@OpenWrt:/# echo w > /proc/sysrq-trigger
[   98.16] SysRq : Show Blocked State
[   98.16]   taskPC stack   pid father
[   98.16] gcomD 8030861c 0  2228   2188 0x08100020
[   98.16] Stack : 81bde880 0001  80307b18 81bde880 80435698 
81bde88c 80414c60
  81d213c0 0001 8041 81bb7180 0001 8030861c 81bcd480 
81452e00
  81452e00 803a  814bf070 8007fc04 80435698 80435698 
81452e00
  803a 0004 81d21380 0010 81be2800 81828900  
81d08c28
    81be2804 81be2884 81452e00 803a  
81d08c28
  ...
[   98.16] Call Trace:
[   98.16] [<8000d954>] __schedule+0x4cc/0x578
[   98.16] [<8030861c>] usb_kill_urb+0xe0/0x164
[   98.16] [<81828900>] usb_wwan_close+0x100/0x2e4 [usb_wwan]
[   98.16] [<802b6e8c>] tty_port_shutdown+0xc0/0xdc
[   98.16] [<802b64ac>] tty_port_close+0x30/0xa4
[   98.16] [<802b7918>] tty_release+0x168/0x524
[   98.16] [<80041038>] __fput+0xf8/0x274
[   98.16] [<80289560>] task_work_run+0xf0/0x128
[   98.16] [<800ef3d0>] do_exit+0x3fc/0x858
[   98.16] [<800f154c>] do_group_exit+0x78/0xb4
[   98.16] [<800198a8>] SyS_faccessat+0x0/0x250

As can be seen, it is while cleaning up process resources on exit (at
kernel level) that the hang happens. If I unplug the modem, process
exits and I get the following output:
[ 2862.228000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb 
failed. (-19)
[ 2862.236000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb 
failed. (-19)
[ 2862.244000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb 
failed. (-19)
[ 2862.252000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb 
failed. (-19)
[ 2862.26] option1 ttyUSB0: option_instat_callback: error -150

Here is the HCD driver source code:
  
http://git.openwrt.org/?p=openwrt.git;a=tree;f=package/kernel/lantiq/ltq-hcd/src;h=926980738d4eb39d78fdf116fe4f2f787040fa1d;hb=fee2d7ec702586850e0eafbd82f43c851d1c45b3
(to the revision I'm at locally, which is 2 days old as I'm writing
this, and no change since touch this path)

Poking around with printk debugging (*cough*), I found that the URB
__schedule is waiting upon has a use_count of 1. Adding printks after
the 2 atomic_dec and the only atomic_inc on it, I see this URB's history
as:

[   99.284000] 81ae2900->use_count 1 drivers/usb/core/hcd.c:1553
[   99.916000] 81ae2900->use_count 2 drivers/usb/core/hcd.c:1553
[   99.916000] 81ae2900->use_count 1 drivers/usb/core/hcd.c:1691
[  100.332000] 81ae2900->use_count 2 drivers/usb/core/hcd.c:1553
[  100.332000] 81ae2900->use_count 1 drivers/usb/core/hcd.c:1691
[  101.436000] IFXUSB: 81ae2900 urbd->phase 0
[  101.44] 81ae2900->use_count 2 drivers/usb/core/hcd.c:1553
[  101.44] 81ae2900->use_count 1 drivers/usb/core/hcd.c:1691
[  101.512000] wait_event 81ae2900

1553 is right after usb_hcd_submit_urb's atomic_inc
1691 is right after __usb_hcd_giveback_urb's atomic_dec
usb_hcd_submit_urb's atomic_dec is not hit.

The IFXUSB line is the HCD driver's ifxhcd_urb_dequeue telling it is
dequeueing the URB, currently in given phase (here 0, so URBD_IDLE).
wait_event line is usb_kill_urb calling wait_event or given URB.
This URB does not appear at any time before 99.284, when I started gcom.

Is it legal for use_count to exceed 1 ?
What would it mean ?
Eyeballing usb_wwan I could not see any obvious issue. I saw a large
patch set for this driver since 3.14.18 and copied it over (as of
linux-stable b0a9aa6da8088b722326a858ab572a13b5b6f9cb), with the only
visible improvement of not getting errors when unplugging the modem on
stuck process.
Is my debugging approach even reliable ? I'm reading use_count right
after an atomic_inc, which looks like a bad idea...
Any idea on what I should search for/look at next ?

I tried calling dump_stack after 1553, but kernel fails booting (maybe
URBs timing out just because of printks going through 115200 bauds
serial link ?). After ~260 seconds the router reboots (no error
message, maybe out of memory because of message buffer growing faster
than serial empties it ?).
If I only call it when count reaches 2, kernel boots and gives
stack traces I do not understand, such as (extracted from above run):

[   99.916000] CPU: 0 PID: 1413 Comm: logd Not tainted 3.14.18 #38
[   99.916000] Stack :     8095cdbe 0033 
838bd7e8 803f
  803c1644 8042136f 0585 80953b00 838bd7e8 803f 81d395a8 
0020
  000a 802f9998  80211878   803c49a4 
838b5ccc
    

Re: [PATCH V6 07/12] pinctrl: tegra-xusb: Add USB PHY support

[Andrew Bresticker]

On Tue, Nov 25, 2014 at 5:49 AM, Kishon Vijay Abraham I  wrote:
> Hi,
>
> On Tuesday 25 November 2014 05:47 AM, Andrew Bresticker wrote:
>> In addition to the PCIe and SATA PHYs, the XUSB pad controller also
>> supports 3 UTMI, 2 HSIC, and 2 USB3 PHYs.  Each USB3 PHY uses a single
>> PCIe or SATA lane and is mapped to one of the three UTMI ports.
>>
>> The xHCI controller will also send messages intended for the PHY driver,
>> so request and listen for messages on the mailbox's PHY channel.
>>
>> Signed-off-by: Andrew Bresticker 
>> Acked-by: Linus Walleij 
>> Reviewed-by: Stephen Warren 
>> ---
>> No changes from v5.
>> Changes from v4:
>>  - Disabled USB support on missing mailbox channel instead of failing
>>to probe.
>>  - Made usb3-port a pinconfig property.
>>  - Addressed review comments from Thierry.
>> No changes from v3.
>> Changes from v2:
>>  - Added support for nvidia,otg-hs-curr-level-offset property.
>>  - Moved mailbox request handling to workqueue.
>>  - Added filtering out of non-PHY mailbox messages.
>>  - Dropped "-otg" from VBUS supplies.
>> Changes from v1:
>>  - Updated to use common mailbox API.
>>  - Added SATA PHY enable sequence for USB3 ports using the SATA lane.
>>  - Made USB3 port-to-lane mappins a top-level binding rather than a pinconfig
>>binding.
>> ---
>>  drivers/pinctrl/Kconfig  |1 +
>>  drivers/pinctrl/pinctrl-tegra-xusb.c | 1262 
>> +-
>>  include/soc/tegra/xusb.h |7 +
>>  3 files changed, 1254 insertions(+), 16 deletions(-)
>
> The devm_phy_create() API has changed (see linux-phy next) and the patch that
> modified the existing devm_phy_create() in pinctrl-tegra-xusb.c has also been
> merged in linux-phy tree.

Ok, I'll rebase on top of that.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V6 00/12] Tegra xHCI support

[Andrew Bresticker]

On Tue, Nov 25, 2014 at 5:32 AM, Jassi Brar  wrote:
> On 25 November 2014 at 05:47, Andrew Bresticker  wrote:
>> This series adds support for xHCI on NVIDIA Tegra SoCs.  This includes:
>>  - patches 1, 2, and 3: minor cleanups for mailbox framework and xHCI,
>>  - patches 4 and 5: adding a driver for the mailbox used to communicate
>>with the xHCI controller's firmware,
>>  - patches 6 and 7: extending the XUSB pad controller driver to support
>>the USB PHY types (UTMI, HSIC, and USB3),
>>  - patches 8 and 9: adding a xHCI host-controller driver, and
>>  - patches 10, 11, and 12: updating the relevant DT files.
>>
>> The mailbox driver (patch 5) has a compile-time dependency on patch 2 and
>> a run-time dependency on patch 3.  Both the PHY (patch 7) and host (patch 9)
>> drivers have compile-time dependencies on the mailbox driver.  The host
>> driver also has a run-time dependency on patch 1.  Because of this, this
>> entire series should probably go through the Tegra tree.
>>
> Why shouldn't I pick 2 & 3 at least?

I don't see why not.  Because of the PHY API change I'm going to have
to re-spin the series and at this point 3.19 is looking pretty
unlikely.  Maybe we could get a Tegra maintainer's ACK for patches 4
and 5 so that you could take them through your tree as well for 3.19?
(Stephen, Thierry, Alex?)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] USB-serial updates for v3.19

[Greg Kroah-Hartman]

On Wed, Nov 26, 2014 at 06:25:07PM +0100, Johan Hovold wrote:
> Hi Greg,
> 
> Here's my pull-request for v3.19-rc1.
> 
> All have been in linux-next for a while.
> 
> Thanks,
> Johan
> 
> 
> The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1:
> 
>   Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> tags/usb-serial-3.19-rc1

Pulled and pushed out, thanks.

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

Re: ath9k -> bogus usb xfer on at91

[David Lechner]

On 11/26/14 12:29 PM, Oleksij Rempel wrote:

Am 26.11.2014 um 01:28 schrieb David Lechner:

On 7 July 2014 17:08, Oleksij Rempel  wrote:

/  Am 07.07.2014 15:40, schrieb Anders Darander:/
/> On 4 July 2014 18:54, Oleksij Rempel  wrote:/
/>> Am 04.07.2014 18:30, schrieb Alan Stern:/
/>>> On Fri, 4 Jul 2014, Anders Darander wrote:/
/ ~# usb 1-1: new full-speed USB device number 3 using at91_ohci/
/ usb 1-1: ath9k_htc: Firmware htc_9271.fw requested/
/ usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272/
/ ---[ cut here ]---/
/ WARNING: CPU: 0 PID: 93 at/
/

/mnt/cs-builds/anders/oe-build/build-ccu/tmp-eglibc/work/ccu-oe-linux-gnueabi/linux-yocto-ccu/3.14+gitAUTOINC+7b03bd3dfd-r0/linux/drivers/usb/core/urb.c:450/


/ usb_submit_urb+0x2ac/0x460()/
/ usb 1-1: BOGUS urb xfer, pipe 1 != type 3/
/>/
/>>>/
/>>> I can't tell exactly where the fault is, but this message means

that an/

/>>> URB was submitted for a bulk endpoint with a pipe of type/
/>>> PIPE_INTERRUPT./
/>>/
/>> Then kernel driver and firmware should be updated. There was some/
/>> Bulk/Interrupt issues which was fixed last year./
/>/
/> Any pointers to the bulk/interrupt issues? Was it a general issue,

or/

/> related either to/
/> at91-ohci or ar9271?/

/  It is primary ar9271 issue. The interrupt EP has different

response time/

/  on different host controllers. Initially as workaround ath9k was

forcing/

/  Bulk traffic on Interrupt EP. But this workaround is working with

some/

/  host controllers and completely fails on others. So i removed it.

The/

/  patches are included in master kernel branch and git firmware

source./

Thanks for the comments!
I'll take a look at it, though it might have to be scheduled after the
upcoming vacations...

I'll sure try to look into those workarounds (and your removal of
those). I guess that
it's the firmware in open-ath9-htc-firmware you're talking about.


/>/
/> As far as I've been able to find out, I've got the latest firmware/
/> (check again with linux-firmware)./
/> I've also tried with the master from open-ath9k-htc-firmware./
/>/
/>> I hope this HW will not be used as AP./
/>/
/> Is this based on the use of at91- SoC, or based on the ar9271?/

/  ar9271 can work as AP with limit on 8 stations but according to user/
/  reports it fails even with one station on at91/

/> The primary use case is to run as a client, though there will likely/
/> be some instances where it'll/
/> function as a AP. (Though primarily for M2M communications), thus/
/> pretty low traffic./

/  For AP usually should be created monitor mode interface for

receiving/

/  and transmitting management frames. Depending on location and STAs

or/

/  APs working on same channel, you will get a lot of traffic on this

usb/

/  interface./
/  Some users reported huge traffic drops on at91 based APs. Since i

can't/

/  debug it, i can't promise that it will be fixed any time soon./

Again, thanks for the information.
I think I've got a much better understanding of the issues (both those
that I've
seen, and those that you have mentioned / explained). I'll see
when/what I can
look into this and what I can find out.

Cheers,
Anders

Anders, did you ever have a chance to look at this? I am seeing this
same warning that is filling up the kernel logs in v3.18-rc6.

The device I am using is:

|ID 0846:9030 NetGear, Inc. WNA1100 Wireless-N 150 [Atheros AR9271]||

I found that if I revert kernel commit 2b72111 that the warning stops,
but the device does not work very well.||If you are interested to know
more about the symptoms we are seeing, there is a bug report here:
. But, I figured at least
knowing the kernel commit that introduced the problem would be helpful.|


i assume you mean this:

commit 2b721118b7821107757eb1d37af4b60e877b27e7
Author: Oleksij Rempel 
Date:   Tue Aug 13 21:10:19 2013 +0200

 ath9k_htc: do not use bulk on EP3 and EP4

 If usb auto suspend is enabled or system run in to suspend/resume
 cycle, ath9k-htc adapter will stop to response. It is reproducible
on xhci H

 Host part of problem:
 XHCI do timing calculation based on Transfer Type and bInterval,
 immediately after device was detected. Ath9k-htc try to overwrite
 this parameters on module probe and some changes in FW,
 since we do not initiate usb reset from the driver this changes
 are not took to account. So, before any kind of suspend or reset,
 host controller will operate with old parameters. Only after
suspend/resume
 and if interface id stay unchanged, new parameters will be applied. Host
 will send bulk data with no intervals (?), which will cause
 overflow on FIFO of EP4.

 Firmware part of problem:
 By default, ath9k-htc adapters configured with EP3 and EP4
 as interrupt endpoints. Current firmware will try to overwrite
 ConfigDescriptor to make EP3 and EP4 bulk. FIFO for this endpo

Re: USB storage device cause usb bus can't enter runtime suspend

[Alan Stern]

On Wed, 26 Nov 2014, liu chunlin wrote:

> Hi Stern,
> 
> 
> My platform not use udev,do you have good idea to modify usb driver to enable 
> usb storage runtime suspend?

It is not possible to do what you want by modifying the USB driver.

What does your platform use instead of udev?

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

Fix Penguin Penalty 17th October2014 ( mail-archive.com )

[topmost55668]

Dear Sir

Did your website get hit by Google Penguin update on October 17th 2014? What 
basically is Google Penguin Update? It is actually a code name for Google 
algorithm which aims at decreasing your websites search engine rankings that 
violate Google’s guidelines by using black hat SEO techniques to rank your 
webpage by giving number of spammy links to the page.
 
We are one of those few SEO companies that can help you avoid penalties from 
Google Updates like Penguin and Panda. Our clients have survived all the 
previous and present updates with ease. They have never been hit because we use 
100% white hat SEO techniques to rank Webpages.  Simple thing that we do to 
keep websites away from any Penguin or Panda penalties is follow Google 
guidelines and we give Google users the best answers to their queries.

If you are looking to increase the quality of your websites and to get more 
targeted traffic or save your websites from these Google penalties email us 
back with your interest. 

We will be glad to serve you and help you grow your business.

Regards

Roshni Patel

SEO Manager ( TOB )
B7 Green Avenue, Amritsar 143001 Punjab

NO CLICK in the subject to STOP EMAILS
--
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 net] r8152: drop the tx packet with invalid length

[Eric Dumazet]

On Wed, 2014-11-26 at 12:06 -0500, David Miller wrote:
> From: Eric Dumazet 
> Date: Wed, 26 Nov 2014 08:52:28 -0800
> 
> > On Wed, 2014-11-26 at 17:56 +0800, Hayes Wang wrote:
> >> Drop the tx packet which is more than the size of agg_buf_sz. When
> >> creating a bridge with the device, we may get the tx packet with
> >> TSO and the length is more than the gso_max_size which is set by
> >> the driver through netif_set_gso_max_size(). Such packets couldn't
> >> be transmitted and should be dropped directly.
> >> 
> >> Signed-off-by: Hayes Wang 
>  ...
> > Looks like a candidate for ndo_gso_check(), so that we do not drop, but
> > instead segment from netif_needs_gso()/validate_xmit_skb()
> 
> You mean have the bridge implement the ndo_gso_check() method right?

No, I meant this particular driver.

Note that netif_skb_features() does only this check :

if (gso_segs > dev->gso_max_segs || gso_segs < dev->gso_min_segs)
  features &= ~NETIF_F_GSO_MASK;


Ie not testing gso_max_size

It looks like all these particular tests should be moved on
ndo_gso_check(), to remove code from netif_skb_features()



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

Re: [PATCH] usb: gadget: zero: fix INT endpoint assignment

[Sebastian Andrzej Siewior]

On 11/26/2014 04:24 PM, Alan Stern wrote:
>> On 11/25/2014 10:52 PM, Sebastian Andrzej Siewior wrote:
>>> The max packet size within the FS descriptor has to be highest possible
>>> value and _not_ the one that is (or will be) used on FS.
>>
>> The current code sets wMaxPacketSize of FS interrupt endpoint descriptor 
>> as 64, which is in accordance with the usb 2.0 specification, section 5.7.3
>>
>>  The maximum allowable interrupt data payload size is 64 bytes
>>  or less for full-speed. High-speed endpoints are allowed
>>  maximum data payload sizes up to 1024 bytes.
> 
> The real problem is that we are assuming endpoints can be allocated in
> a single way that will work correctly for all possible connection
> speeds.  (I suspect it was done this way out of laziness and a desire
> to minimize the code size.)  This assumption is obviously incorrect
> when the hardware has an interrupt endpoint that supports packet sizes
> of 64 but no larger.

The code will check properly if you pass 1024 and check the size
accordingly. You have to "downsize" your FS descriptor later. This
function will only fail to do this if your gadget isn't dual speed. In
that case it expects 64 as the upper limit for INT (if I recall
correctly).

But what you can't do (and this is done by ISOC and INT endpoint) is to
upgrade your capabilities by increasing the max packet size after you
received an endpoint. This "works" for ISOC because on FS you can use
up to 1023 bytes and the matching FIFO has usually 1024 bytes and not
1023. It isn't correct but it works.

This was done out of laziness and "simplicity" as far as I recall.
Usually the only difference between FS and HS is 0 so the only thing
you do is to update the bEndpointAddress member in HS/SS descriptors.
Nothing more. Most INT don't care for 1024 transfer size or anything
like that and the first gadgets in kernel were not ISOC and even these
days their MPS is < 200.

So it was easy just to update the endpoint address for the HS
descriptor, you used the same endpoint as for FS. Most in tree gadgets
don't do more.

> The right way to fix the problem is to avoid allocating endpoints until 
> after the connection speed is known.  Then we can call 
> usb_ep_autoconfig() with the appropriate set of descriptors, and 
> nothing will need to be fixed up.
> 
> However, I don't know if this approach is compatible with the composite 
> framework in its current form.

I've been looking at this mess by the time I started the configfs. I
tried a few times and decided not now and there was no later.
You need all descriptors prior you connect / at bind time. At this time
you need also your endpoints allocated. A small change to this breaks
things in multiple places therefore the created configfs gadget is
"bound" once it is complete. I tried even to have "one descriptor" and
let the code create HS/SS descriptors out of it (since in 99% they are
the same) but a few gadgets did more and I dropped that idea again.

So this is what is expected in most parts of the code as of now. Then
you have USB_DT_OTHER_SPEED_CONFIG where you may ask for HS descriptors
on a FS link. So you need those.

All in all I tried to minimize the effects by leaving the descriptors
"untouched" and creating a copy after bind. I didn't manage to redo the
endpoint allocation.
Part of the problem is that you have no clear cut currently between
descriptor preparation and endpoint allocation. The endpoint allocator
does not know about HS/FS/SS. It knows that there is an endpoint, it
can do all speeds and has a special special upper limit (it may not be
able to INT or BULK or ISOC so it considers that as well).
Once it finds a match, it writes the endpoint address into the
descriptor and returns the pointer to the endpoint. So technically you
return two values here. The endpoint is considered taken once
ep->private is set (so it is a little racy).
Based on this you can't get the same endpoint on HS because it is gone.
You could but then you get another one. it will work but is a waste of
resources.

Ah. And endpoints are never returned to the allocator. Some gadgets set
->private to NULL, other just ignore it and let the core do it. So
re-doing the endpoint allocator is probably the right thing to do. And
then force every gadget to allocate an endpoint for FS/HS/SS and give
it back _and_ please edit the copy of the descriptor and not the global
"original".

But the work will not be done before we have the next release is out
and as of now it breaks g_zero on musb, net2280 and maybe others.

> Alan Stern

Sebastian
--
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: ath9k -> bogus usb xfer on at91

[Oleksij Rempel]

Am 26.11.2014 um 01:28 schrieb David Lechner:
>> On 7 July 2014 17:08, Oleksij Rempel  wrote:
>> >/  Am 07.07.2014 15:40, schrieb Anders Darander:/
>> >/> On 4 July 2014 18:54, Oleksij Rempel  wrote:/
>> >/>> Am 04.07.2014 18:30, schrieb Alan Stern:/
>> >/>>> On Fri, 4 Jul 2014, Anders Darander wrote:/
>> >/ ~# usb 1-1: new full-speed USB device number 3 using at91_ohci/
>> >/ usb 1-1: ath9k_htc: Firmware htc_9271.fw requested/
>> >/ usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272/
>> >/ ---[ cut here ]---/
>> >/ WARNING: CPU: 0 PID: 93 at/
>> >/
>> /mnt/cs-builds/anders/oe-build/build-ccu/tmp-eglibc/work/ccu-oe-linux-gnueabi/linux-yocto-ccu/3.14+gitAUTOINC+7b03bd3dfd-r0/linux/drivers/usb/core/urb.c:450/
>>
>> >/ usb_submit_urb+0x2ac/0x460()/
>> >/ usb 1-1: BOGUS urb xfer, pipe 1 != type 3/
>> >/>/
>> >/>>>/
>> >/>>> I can't tell exactly where the fault is, but this message means
>> that an/
>> >/>>> URB was submitted for a bulk endpoint with a pipe of type/
>> >/>>> PIPE_INTERRUPT./
>> >/>>/
>> >/>> Then kernel driver and firmware should be updated. There was some/
>> >/>> Bulk/Interrupt issues which was fixed last year./
>> >/>/
>> >/> Any pointers to the bulk/interrupt issues? Was it a general issue,
>> or/
>> >/> related either to/
>> >/> at91-ohci or ar9271?/
>> >
>> >/  It is primary ar9271 issue. The interrupt EP has different
>> response time/
>> >/  on different host controllers. Initially as workaround ath9k was
>> forcing/
>> >/  Bulk traffic on Interrupt EP. But this workaround is working with
>> some/
>> >/  host controllers and completely fails on others. So i removed it.
>> The/
>> >/  patches are included in master kernel branch and git firmware
>> source./
>>
>> Thanks for the comments!
>> I'll take a look at it, though it might have to be scheduled after the
>> upcoming vacations...
>>
>> I'll sure try to look into those workarounds (and your removal of
>> those). I guess that
>> it's the firmware in open-ath9-htc-firmware you're talking about.
>>
>> >/>/
>> >/> As far as I've been able to find out, I've got the latest firmware/
>> >/> (check again with linux-firmware)./
>> >/> I've also tried with the master from open-ath9k-htc-firmware./
>> >/>/
>> >/>> I hope this HW will not be used as AP./
>> >/>/
>> >/> Is this based on the use of at91- SoC, or based on the ar9271?/
>> >
>> >/  ar9271 can work as AP with limit on 8 stations but according to user/
>> >/  reports it fails even with one station on at91/
>> >
>> >/> The primary use case is to run as a client, though there will likely/
>> >/> be some instances where it'll/
>> >/> function as a AP. (Though primarily for M2M communications), thus/
>> >/> pretty low traffic./
>> >
>> >/  For AP usually should be created monitor mode interface for
>> receiving/
>> >/  and transmitting management frames. Depending on location and STAs
>> or/
>> >/  APs working on same channel, you will get a lot of traffic on this
>> usb/
>> >/  interface./
>> >/  Some users reported huge traffic drops on at91 based APs. Since i
>> can't/
>> >/  debug it, i can't promise that it will be fixed any time soon./
>>
>> Again, thanks for the information.
>> I think I've got a much better understanding of the issues (both those
>> that I've
>> seen, and those that you have mentioned / explained). I'll see
>> when/what I can
>> look into this and what I can find out.
>>
>> Cheers,
>> Anders
> 
> Anders, did you ever have a chance to look at this? I am seeing this
> same warning that is filling up the kernel logs in v3.18-rc6.
> 
> The device I am using is:
> 
> |ID 0846:9030 NetGear, Inc. WNA1100 Wireless-N 150 [Atheros AR9271]||
> 
> I found that if I revert kernel commit 2b72111 that the warning stops,
> but the device does not work very well.||If you are interested to know
> more about the symptoms we are seeing, there is a bug report here:
> . But, I figured at least
> knowing the kernel commit that introduced the problem would be helpful.|
> 

i assume you mean this:

commit 2b721118b7821107757eb1d37af4b60e877b27e7
Author: Oleksij Rempel 
Date:   Tue Aug 13 21:10:19 2013 +0200

ath9k_htc: do not use bulk on EP3 and EP4

If usb auto suspend is enabled or system run in to suspend/resume
cycle, ath9k-htc adapter will stop to response. It is reproducible
on xhci H

Host part of problem:
XHCI do timing calculation based on Transfer Type and bInterval,
immediately after device was detected. Ath9k-htc try to overwrite
this parameters on module probe and some changes in FW,
since we do not initiate usb reset from the driver this changes
are not took to account. So, before any kind of suspend or reset,
host controller will operate with old parameters. Only after
suspend/resume
and if interface id stay unchanged, new parameters will be applied. Host
will send bulk data with no intervals (?), which will cause
overflow

Re: [PATCH] usb: gadget: zero: fix INT endpoint assignment

[Sebastian Andrzej Siewior]

On 11/26/2014 02:21 PM, Amit Virdi wrote:
>> - if ISOC is not available, we won't have INT as well.
> 
> I didn't understand this. The original patch added a new alternate
> setting (2) that has two interrupt endpoints. ISOC EP is available
> through alternate setting 1.

The ISOC code does this:
 no_iso:
 /*
  * We still want to work even if the UDC doesn't have isoc
  * endpoints, so null out the alt interface that contains
  * them and continue.
  */
 fs_source_sink_descs[FS_ALT_IFC_1_OFFSET] = NULL;
 hs_source_sink_descs[HS_ALT_IFC_1_OFFSET] = NULL;
 ss_source_sink_descs[SS_ALT_IFC_1_OFFSET] = NULL;

That means the descriptor is terminated early:
 static struct usb_descriptor_header *fs_source_sink_descs[] = {
 (struct usb_descriptor_header *) &source_sink_intf_alt0,
 (struct usb_descriptor_header *) &fs_sink_desc,
 (struct usb_descriptor_header *) &fs_source_desc,
=> (struct usb_descriptor_header *) &source_sink_intf_alt1,
 #define FS_ALT_IFC_1_OFFSET 3

That means "no ISOC" will NULL the fourth descriptor and there is no
alt1 including your alt2. Those descs won't be passed to the host. It
was "okay" while it was ISOC only but now "disabling" ISOC means no INT
either.

>> - wMaxPacketSize is supposed to be LE. The assignments within the code
>>does not use cpu_to_le16().
> 
> Can you please point to the code where it should have been and is missing?

You look for each assignment to wMaxPacketSize and you will notice that
the cpu_to_le16 isn't used:

 /* fill in the FS isoc descriptors from the module parameters */
 fs_iso_source_desc.wMaxPacketSize = isoc_maxpacket > 1023 ?
 1023 : isoc_maxpacket;

this one example, the very same is true for your copy/pasted INT
handling.

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

[GIT PULL] USB-serial updates for v3.19

[Johan Hovold]

Hi Greg,

Here's my pull-request for v3.19-rc1.

All have been in linux-next for a while.

Thanks,
Johan


The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1:

  Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)

are available in the git repository at:

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

for you to fetch changes up to e7181d005e84b15fe3121a8d22840adc3395d496:

  USB: qcserial: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem (2014-11-19 
16:17:03 +0100)


USB-serial updates for v3.19-rc1

These changes add a new "simple" driver for Google USB-serial
devices and add support for Huawei Gobi modems to qcserial.

Included are also some removals of unnecessary atomic allocations and
a few spelling fixes.

Signed-off-by: Johan Hovold 


Anton Staaf (1):
  USB: serial: add Google simple serial SubClass support

Johan Hovold (3):
  USB: kobil_sct: replace unnecessary atomic allocation
  USB: mos7720: replace unnecessary atomic allocations
  USB: mos7840: replace unnecessary atomic allocations

Mark Knibbs (1):
  USB: serial: keyspan_pda: fix Entrega company name spelling

Martin Hauke (1):
  USB: qcserial: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem

 Documentation/usb/usb-serial.txt   |  2 +-
 drivers/usb/serial/Kconfig |  5 +++--
 drivers/usb/serial/keyspan_pda.c   | 16 
 drivers/usb/serial/kobil_sct.c |  2 +-
 drivers/usb/serial/mos7720.c   |  4 ++--
 drivers/usb/serial/mos7840.c   |  4 ++--
 drivers/usb/serial/qcserial.c  | 33 +
 drivers/usb/serial/usb-serial-simple.c | 10 ++
 8 files changed, 60 insertions(+), 16 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net] r8152: drop the tx packet with invalid length

[David Miller]

From: Eric Dumazet 
Date: Wed, 26 Nov 2014 08:52:28 -0800

> On Wed, 2014-11-26 at 17:56 +0800, Hayes Wang wrote:
>> Drop the tx packet which is more than the size of agg_buf_sz. When
>> creating a bridge with the device, we may get the tx packet with
>> TSO and the length is more than the gso_max_size which is set by
>> the driver through netif_set_gso_max_size(). Such packets couldn't
>> be transmitted and should be dropped directly.
>> 
>> Signed-off-by: Hayes Wang 
 ...
> Looks like a candidate for ndo_gso_check(), so that we do not drop, but
> instead segment from netif_needs_gso()/validate_xmit_skb()

You mean have the bridge implement the ndo_gso_check() method right?
--
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 net] r8152: drop the tx packet with invalid length

[Eric Dumazet]

On Wed, 2014-11-26 at 17:56 +0800, Hayes Wang wrote:
> Drop the tx packet which is more than the size of agg_buf_sz. When
> creating a bridge with the device, we may get the tx packet with
> TSO and the length is more than the gso_max_size which is set by
> the driver through netif_set_gso_max_size(). Such packets couldn't
> be transmitted and should be dropped directly.
> 
> Signed-off-by: Hayes Wang 
> ---
>  drivers/net/usb/r8152.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index c6554c7..ebdaff7 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -1897,6 +1897,15 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff 
> *skb,
>  {
>   struct r8152 *tp = netdev_priv(netdev);
>  
> + if ((skb->len + sizeof(struct tx_desc)) > agg_buf_sz) {
> + struct net_device_stats *stats = &netdev->stats;
> +
> + dev_kfree_skb_any(skb);
> + stats->tx_dropped++;
> + WARN_ON_ONCE(1);
> + return NETDEV_TX_OK;
> + }
> +
>   skb_tx_timestamp(skb);
>  
>   skb_queue_tail(&tp->tx_queue, skb);

Looks like a candidate for ndo_gso_check(), so that we do not drop, but
instead segment from netif_needs_gso()/validate_xmit_skb()



--
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 9/9] usb: {ohci,ehci}-platform: Use new OF big-endian helper function

[Alan Stern]

On Wed, 26 Nov 2014, Kevin Cernekee wrote:

> On Wed, Nov 26, 2014 at 7:14 AM, Alan Stern  wrote:
> >> diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt 
> >> b/Documentation/devicetree/bindings/usb/usb-ehci.txt
> >> index 43c1a4e..9505c31 100644
> >> --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
> >> +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
> >> @@ -12,6 +12,8 @@ Optional properties:
> >>   - big-endian-regs : boolean, set this for hcds with big-endian registers
> >>   - big-endian-desc : boolean, set this for hcds with big-endian 
> >> descriptors
> >>   - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc
> >> + - native-endian : boolean, enables big-endian-regs + big-endian-desc
> >> +   iff the kernel was compiled for big endian
> >
> > Is this really a property of the hardware?  It appears to depend on the
> > kernel configuration.  As such, is it appropriate for DT?
> 
> Yes, the peripheral registers automatically adjust their endianness to
> match the CPU.  So if the CPU is running an LE kernel, the peripheral
> needs to be accessed in LE mode; if the CPU is running a BE kernel,
> the peripheral needs to be accessed in BE mode.

Okay, then:

Acked-by: Alan Stern 

But you might want to update the description slightly to say:

 - native-endian : boolean, enables big-endian-regs + big-endian-desc
   iff the CPU is running in big-endian mode

It's a very minor distinction, since you can't run a kernel that was 
compiled for little endian if the CPU is running in big-endian mode, 
but this makes it clear that you're talking about the hardware rather 
than the software.

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 2/2] usb: musb: blackfin: fix build break

[Tony Lindgren]

* Felipe Balbi  [141126 06:03]:
> commit cc92f681 (usb: musb: Populate new IO
> functions for blackfin) added a typo which
> prevented MUSB's blackfin glue layer from being
> built. Due to lack of tests and compilers for
> that architecture, the typo ended up being
> merged and causing a build regression.
> 
> Fix that here

Oops sorry about the typo. I did not have blackin compilers here
either.

Regards,

Tony
 
> Cc: Tony Lindgren 
> Reported-by: Fengguang Wu 
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/usb/musb/blackfin.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
> index a441a2d..1782501 100644
> --- a/drivers/usb/musb/blackfin.c
> +++ b/drivers/usb/musb/blackfin.c
> @@ -63,7 +63,7 @@ static void bfin_writew(void __iomem *addr, unsigned 
> offset, u16 data)
>   bfin_write16(addr + offset, data);
>  }
>  
> -static void binf_writel(void __iomem *addr, unsigned offset, u32 data)
> +static void bfin_writel(void __iomem *addr, unsigned offset, u32 data)
>  {
>   bfin_write16(addr + offset, (u16)data);
>  }
> -- 
> 2.1.0.GIT
> 
--
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 9/9] usb: {ohci,ehci}-platform: Use new OF big-endian helper function

[Kevin Cernekee]

On Wed, Nov 26, 2014 at 7:14 AM, Alan Stern  wrote:
>> diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt 
>> b/Documentation/devicetree/bindings/usb/usb-ehci.txt
>> index 43c1a4e..9505c31 100644
>> --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
>> +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
>> @@ -12,6 +12,8 @@ Optional properties:
>>   - big-endian-regs : boolean, set this for hcds with big-endian registers
>>   - big-endian-desc : boolean, set this for hcds with big-endian descriptors
>>   - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc
>> + - native-endian : boolean, enables big-endian-regs + big-endian-desc
>> +   iff the kernel was compiled for big endian
>
> Is this really a property of the hardware?  It appears to depend on the
> kernel configuration.  As such, is it appropriate for DT?

Yes, the peripheral registers automatically adjust their endianness to
match the CPU.  So if the CPU is running an LE kernel, the peripheral
needs to be accessed in LE mode; if the CPU is running a BE kernel,
the peripheral needs to be accessed in BE mode.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: gadget: zero: fix INT endpoint assignment

[Alan Stern]

On Wed, 26 Nov 2014, Amit Virdi wrote:

> Dear Sebastian,
> 
> On 11/25/2014 10:52 PM, Sebastian Andrzej Siewior wrote:
> > The max packet size within the FS descriptor has to be highest possible
> > value and _not_ the one that is (or will be) used on FS.
> 
> The current code sets wMaxPacketSize of FS interrupt endpoint descriptor 
> as 64, which is in accordance with the usb 2.0 specification, section 5.7.3
> 
>   The maximum allowable interrupt data payload size is 64 bytes
>   or less for full-speed. High-speed endpoints are allowed
>   maximum data payload sizes up to 1024 bytes.

The real problem is that we are assuming endpoints can be allocated in
a single way that will work correctly for all possible connection
speeds.  (I suspect it was done this way out of laziness and a desire
to minimize the code size.)  This assumption is obviously incorrect
when the hardware has an interrupt endpoint that supports packet sizes
of 64 but no larger.

The right way to fix the problem is to avoid allocating endpoints until 
after the connection speed is known.  Then we can call 
usb_ep_autoconfig() with the appropriate set of descriptors, and 
nothing will need to be fixed up.

However, I don't know if this approach is compatible with the composite 
framework in its current form.

Alan Stern

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

Re: USB storage device cause usb bus can't enter runtime suspend

[Alan Stern]

On Wed, 26 Nov 2014, tianjulin wrote:

> Hi Stern,
> 
> Many Thanks!!!

You're welcome.

> I use command as follows,the usb bus can enter runtime suspend when I 
> connect usb storage,and if have operate on usb storage,the usb bus can 
> be resume,if have not any operate on usb storage,the usb bus can enter 
> runtime suspend.
> 
> echo auto > /sys/bus/usb/devices/1-1/power/control auto
> echo auto > 
> /sys/bus/usb/devices/1-1:1.0/host0/target0:0:0/0:0:0:0/power/control auto
> echo 1000 > 
> /sys/bus/usb/devices/1-1:1.0/host0/target0:0:0/0:0:0:0/power/autosuspend_delay_ms
>  
> 100
> 
> But how to modify source code to implement this feature?can you provide 
> some help?

If you want to enable runtime suspend automatically, you can write a 
udev script to do it (assuming your platform uses udev).

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 9/9] usb: {ohci,ehci}-platform: Use new OF big-endian helper function

[Alan Stern]

On Tue, 25 Nov 2014, Kevin Cernekee wrote:

> This handles the existing "big-endian" case, and in addition, it also does
> the right thing when "native-endian" is specified.
> 
> Signed-off-by: Kevin Cernekee 
> ---
>  Documentation/devicetree/bindings/usb/usb-ehci.txt | 2 ++
>  Documentation/devicetree/bindings/usb/usb-ohci.txt | 2 ++
>  drivers/usb/host/ehci-platform.c   | 2 +-
>  drivers/usb/host/ohci-platform.c   | 2 +-
>  4 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt 
> b/Documentation/devicetree/bindings/usb/usb-ehci.txt
> index 43c1a4e..9505c31 100644
> --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
> @@ -12,6 +12,8 @@ Optional properties:
>   - big-endian-regs : boolean, set this for hcds with big-endian registers
>   - big-endian-desc : boolean, set this for hcds with big-endian descriptors
>   - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc
> + - native-endian : boolean, enables big-endian-regs + big-endian-desc
> +   iff the kernel was compiled for big endian

Is this really a property of the hardware?  It appears to depend on the 
kernel configuration.  As such, is it appropriate for DT?

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: adutux: NULL dereferences on disconnect

[Dan Carpenter]

Both "dev->udev" and "interface->dev" are NULL.  These printks are not
very interesting so I just deleted them.

Fixes: 03270634e242 ('USB: Add ADU support for Ontrak ADU devices')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/usb/misc/adutux.c b/drivers/usb/misc/adutux.c
index 493c7f2..3071c0e 100644
--- a/drivers/usb/misc/adutux.c
+++ b/drivers/usb/misc/adutux.c
@@ -814,15 +814,10 @@ static void adu_disconnect(struct usb_interface 
*interface)
usb_set_intfdata(interface, NULL);
 
/* if the device is not opened, then we clean up right now */
-   dev_dbg(&dev->udev->dev, "%s : open count %d\n",
-   __func__, dev->open_count);
if (!dev->open_count)
adu_delete(dev);
 
mutex_unlock(&adutux_mutex);
-
-   dev_info(&interface->dev, "ADU device adutux%d now disconnected\n",
-(minor - ADU_MINOR_BASE));
 }
 
 /* usb specific object needed to register this driver with the usb subsystem */
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] usb: musb: build fixes

[Felipe Balbi]

Hi,

Here are two build fixes for recent breaks which can
be triggered when building MUSB for Blackfin.

I don't have any blackfin platform nor a cross compiler
for that architecture, so these breaks were merged without
me noticing.

Greg, if you want to merge these two as patches, please go
ahead. I can also create another pull request for you,
whatever works.

Steven, can you help build testing these ?

Felipe Balbi (2):
  usb: musb: debugfs: cope with blackfin's oddities
  usb: musb: blackfin: fix build break

 drivers/usb/musb/blackfin.c |  2 +-
 drivers/usb/musb/musb_debugfs.c | 18 ++
 2 files changed, 11 insertions(+), 9 deletions(-)

-- 
2.1.0.GIT

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

[PATCH 1/2] usb: musb: debugfs: cope with blackfin's oddities

[Felipe Balbi]

Blackfin's MUSB implementation lacks a bunch of
registers which they end up not defining a macro
for. In order to avoid build breaks, let's ifdef
out some of the registers from our regdump debugfs
utility so that we don't try to use those on
Blackfin builds.

Reported-by: Fengguang Wu 
Signed-off-by: Felipe Balbi 
---
 drivers/usb/musb/musb_debugfs.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index ad3701a..54e8cde 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -59,20 +59,12 @@ static const struct musb_register_map musb_regmap[] = {
{ "RxMaxPp",MUSB_RXMAXP,16 },
{ "RxCSR",  MUSB_RXCSR, 16 },
{ "RxCount",MUSB_RXCOUNT,   16 },
-   { "ConfigData", MUSB_CONFIGDATA,8 },
{ "IntrRxE",MUSB_INTRRXE,   16 },
{ "IntrTxE",MUSB_INTRTXE,   16 },
{ "IntrUsbE",   MUSB_INTRUSBE,  8 },
{ "DevCtl", MUSB_DEVCTL,8 },
-   { "BabbleCtl",  MUSB_BABBLE_CTL,8 },
-   { "TxFIFOsz",   MUSB_TXFIFOSZ,  8 },
-   { "RxFIFOsz",   MUSB_RXFIFOSZ,  8 },
-   { "TxFIFOadd",  MUSB_TXFIFOADD, 16 },
-   { "RxFIFOadd",  MUSB_RXFIFOADD, 16 },
{ "VControl",   0x68,   32 },
{ "HWVers", 0x69,   16 },
-   { "EPInfo", MUSB_EPINFO,8 },
-   { "RAMInfo",MUSB_RAMINFO,   8 },
{ "LinkInfo",   MUSB_LINKINFO,  8 },
{ "VPLen",  MUSB_VPLEN, 8 },
{ "HS_EOF1",MUSB_HS_EOF1,   8 },
@@ -103,6 +95,16 @@ static const struct musb_register_map musb_regmap[] = {
{ "DMA_CNTLch7",0x274,  16 },
{ "DMA_ADDRch7",0x278,  32 },
{ "DMA_COUNTch7",   0x27C,  32 },
+#ifndef CONFIG_BLACKFIN
+   { "ConfigData", MUSB_CONFIGDATA,8 },
+   { "BabbleCtl",  MUSB_BABBLE_CTL,8 },
+   { "TxFIFOsz",   MUSB_TXFIFOSZ,  8 },
+   { "RxFIFOsz",   MUSB_RXFIFOSZ,  8 },
+   { "TxFIFOadd",  MUSB_TXFIFOADD, 16 },
+   { "RxFIFOadd",  MUSB_RXFIFOADD, 16 },
+   { "EPInfo", MUSB_EPINFO,8 },
+   { "RAMInfo",MUSB_RAMINFO,   8 },
+#endif
{  }/* Terminating Entry */
 };
 
-- 
2.1.0.GIT

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

[PATCH 2/2] usb: musb: blackfin: fix build break

[Felipe Balbi]

commit cc92f681 (usb: musb: Populate new IO
functions for blackfin) added a typo which
prevented MUSB's blackfin glue layer from being
built. Due to lack of tests and compilers for
that architecture, the typo ended up being
merged and causing a build regression.

Fix that here

Cc: Tony Lindgren 
Reported-by: Fengguang Wu 
Signed-off-by: Felipe Balbi 
---
 drivers/usb/musb/blackfin.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index a441a2d..1782501 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -63,7 +63,7 @@ static void bfin_writew(void __iomem *addr, unsigned offset, 
u16 data)
bfin_write16(addr + offset, data);
 }
 
-static void binf_writel(void __iomem *addr, unsigned offset, u32 data)
+static void bfin_writel(void __iomem *addr, unsigned offset, u32 data)
 {
bfin_write16(addr + offset, (u16)data);
 }
-- 
2.1.0.GIT

--
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 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7

[Alim Akhtar]

Hi Vivek,

On Mon, Nov 24, 2014 at 6:32 PM, Vivek Gautam  wrote:
> USB and Power regulator on Exynos7 require gpios available
> in BUS1 pin controller block.
> So adding the BUS1 pinctrl support.
>
> Signed-off-by: Naveen Krishna Ch 
> Signed-off-by: Vivek Gautam 
> Cc: Linus Walleij 
> ---
Looks good to me.
Thanks!

Reviewed-by: Alim Akhtar 

>
> This patch was part of series:
> "[PATCH 00/11] Exynos7: Adding USB 3.0 support"
>  https://lkml.org/lkml/2014/11/21/247
>
> Changes since V1:
>  - Added support for all pin banks which are part of BUS1 pin controller.
>
>  drivers/pinctrl/samsung/pinctrl-exynos.c |   19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
> b/drivers/pinctrl/samsung/pinctrl-exynos.c
> index d5d4cfc..44e60dc 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
> @@ -1300,6 +1300,20 @@ static const struct samsung_pin_bank_data 
> exynos7_pin_banks7[] __initconst = {
> EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr3", 0x0c),
>  };
>
> +/* pin banks of exynos7 pin-controller - BUS1 */
> +static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst = 
> {
> +   EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpf0", 0x00),
> +   EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpf1", 0x04),
> +   EXYNOS_PIN_BANK_EINTG(4, 0x060, "gpf2", 0x08),
> +   EXYNOS_PIN_BANK_EINTG(5, 0x080, "gpf3", 0x0c),
> +   EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpf4", 0x10),
> +   EXYNOS_PIN_BANK_EINTG(8, 0x0c0, "gpf5", 0x14),
> +   EXYNOS_PIN_BANK_EINTG(5, 0x0e0, "gpg1", 0x18),
> +   EXYNOS_PIN_BANK_EINTG(5, 0x100, "gpg2", 0x1c),
> +   EXYNOS_PIN_BANK_EINTG(6, 0x120, "gph1", 0x20),
> +   EXYNOS_PIN_BANK_EINTG(3, 0x140, "gpv6", 0x24),
> +};
> +
>  const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
> {
> /* pin-controller instance 0 Alive data */
> @@ -1342,5 +1356,10 @@ const struct samsung_pin_ctrl exynos7_pin_ctrl[] 
> __initconst = {
> .pin_banks  = exynos7_pin_banks7,
> .nr_banks   = ARRAY_SIZE(exynos7_pin_banks7),
> .eint_gpio_init = exynos_eint_gpio_init,
> +   }, {
> +   /* pin-controller instance 8 BUS1 data */
> +   .pin_banks  = exynos7_pin_banks8,
> +   .nr_banks   = ARRAY_SIZE(exynos7_pin_banks8),
> +   .eint_gpio_init = exynos_eint_gpio_init,
> },
>  };
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Regards,
Alim
--
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 2/2] arm64: exynos: Add bus1 pinctrl node on exynos7

[Alim Akhtar]

Hi Vivek,

On Mon, Nov 24, 2014 at 6:36 PM, Vivek Gautam  wrote:
> BUS1 pinctrl provides gpios for usb and power regulator
> available on exynos7-espresso board. So add relevant device
> node for pinctrl-bus1.
>
> Signed-off-by: Naveen Krishna Ch 
> Signed-off-by: Vivek Gautam 
> ---
>
Looks good to me.
Reviewed-by: Alim Akhtar 

> This patch was part of series:
> "[PATCH 00/11] Exynos7: Adding USB 3.0 support"
>  https://lkml.org/lkml/2014/11/21/247
>
> Changes since V1:
>  - Added support for all pin banks which are part of BUS1 pin controller.
>
>  arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi |   82 
> +++
>  arch/arm64/boot/dts/exynos/exynos7.dtsi |7 ++
>  2 files changed, 89 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
> index 2eef4a2..c367f0a 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
> @@ -335,6 +335,88 @@
> };
>  };
>
> +&pinctrl_bus1 {
> +   gpf0: gpf0 {
> +   gpio-controller;
> +   #gpio-cells = <2>;
> +
> +   interrupt-controller;
> +   #interrupt-cells = <2>;
> +   };
> +
> +   gpf1: gpf1 {
> +   gpio-controller;
> +   #gpio-cells = <2>;
> +
> +   interrupt-controller;
> +   #interrupt-cells = <2>;
> +   };
> +
> +   gpf2: gpf2 {
> +   gpio-controller;
> +   #gpio-cells = <2>;
> +
> +   interrupt-controller;
> +   #interrupt-cells = <2>;
> +   };
> +
> +   gpf3: gpf3 {
> +   gpio-controller;
> +   #gpio-cells = <2>;
> +
> +   interrupt-controller;
> +   #interrupt-cells = <2>;
> +   };
> +
> +   gpf4: gpf4 {
> +   gpio-controller;
> +   #gpio-cells = <2>;
> +
> +   interrupt-controller;
> +   #interrupt-cells = <2>;
> +   };
> +
> +   gpf5: gpf5 {
> +   gpio-controller;
> +   #gpio-cells = <2>;
> +
> +   interrupt-controller;
> +   #interrupt-cells = <2>;
> +   };
> +
> +   gpg1: gpg1 {
> +   gpio-controller;
> +   #gpio-cells = <2>;
> +
> +   interrupt-controller;
> +   #interrupt-cells = <2>;
> +   };
> +
> +   gpg2: gpg2 {
> +   gpio-controller;
> +   #gpio-cells = <2>;
> +
> +   interrupt-controller;
> +   #interrupt-cells = <2>;
> +   };
> +
> +   gph1: gph1 {
> +   gpio-controller;
> +   #gpio-cells = <2>;
> +
> +   interrupt-controller;
> +   #interrupt-cells = <2>;
> +   };
> +
> +   gpv6: gpv6 {
> +   gpio-controller;
> +   #gpio-cells = <2>;
> +
> +   interrupt-controller;
> +   #interrupt-cells = <2>;
> +   };
> +};
> +
>  &pinctrl_nfc {
> gpj0: gpj0 {
> gpio-controller;
> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> index 1d9e4c9..e633b02 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -26,6 +26,7 @@
> pinctrl5 = &pinctrl_ese;
> pinctrl6 = &pinctrl_fsys0;
> pinctrl7 = &pinctrl_fsys1;
> +   pinctrl8 = &pinctrl_bus1;
> };
>
> cpus {
> @@ -242,6 +243,12 @@
> interrupts = <0 383 0>;
> };
>
> +   pinctrl_bus1: pinctrl@1487 {
> +   compatible = "samsung,exynos7-pinctrl";
> +   reg = <0x1487 0x1000>;
> +   interrupts = <0 384 0>;
> +   };
> +
> pinctrl_nfc: pinctrl@14cd {
> compatible = "samsung,exynos7-pinctrl";
> reg = <0x14cd 0x1000>;
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



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

Re: [PATCH] usb: gadget: zero: fix INT endpoint assignment

[Amit Virdi]

Dear Sebastian,

On 11/25/2014 10:56 PM, Sebastian Andrzej Siewior wrote:

This fixes the test case mentioned for musb which is a regression.
Other things that I noticed:

- if ISOC is not available, we won't have INT as well.


I didn't understand this. The original patch added a new alternate 
setting (2) that has two interrupt endpoints. ISOC EP is available 
through alternate setting 1.



- wMaxPacketSize is supposed to be LE. The assignments within the code
   does not use cpu_to_le16().


Can you please point to the code where it should have been and is missing?


- the module Parameter for INT says max packet size is 0…1023 for FS.


Yes, I'll send a patch to rectify this.


   This is clearly a copy/paste bug.

Amit could you please look at this and fix it?

Sebastian



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

Re: [PATCH] usb: gadget: zero: fix INT endpoint assignment

[Amit Virdi]

Dear Sebastian,

On 11/25/2014 10:52 PM, Sebastian Andrzej Siewior wrote:

The max packet size within the FS descriptor has to be highest possible
value and _not_ the one that is (or will be) used on FS.


The current code sets wMaxPacketSize of FS interrupt endpoint descriptor 
as 64, which is in accordance with the usb 2.0 specification, section 5.7.3


The maximum allowable interrupt data payload size is 64 bytes
or less for full-speed. High-speed endpoints are allowed
maximum data payload sizes up to 1024 bytes.


The way the code works (since day 1) is that usb_ep_autoconfig() is
invoked _only_ on the FS endpoint and then the endpoint address is
copies over to HS/SS endpoints. If the any of the "critical" options are
different between FS and HS then we have to pass the HS value and
correct later.

What now happens is that we look for an INT-OUT endpoint of 64bytes. The
code will return an endpoint matching this category. Further the
sourcesink will take this endpoint and increase the MPS to 1024. On


This is valid only for HS and SS interrupt endpoints. Right?


net2280 for instance the code tries to be clever to return an endpoint
which can only do 64 MPS. The same happens on musb where we mostlike get
an endpoint which can only do 512. The result is then on the host side:



What is the speed at which your device is operating?


|~# testusb -a -t 9 -c 2
|unknown speed   /dev/bus/usb/002/0450
|usbtest 2-1:3.0: TEST 9:  ch9 (subset) control tests, 2 times
|usbtest 2-1:3.0: can't set_interface = 2, -32
|usbtest 2-1:3.0: ch9 subset failed, iterations left 1
|/dev/bus/usb/002/045 test 9 --> 32 (Broken pipe)

because the on the gadget side we can't enable the endpoint because
desc->size > ep->max_size.

Fixes: ef11982dd7a6 ("usb: gadget: zero: Add support for interrupt EP")
Signed-off-by: Sebastian Andrzej Siewior 
---
  drivers/usb/gadget/function/f_sourcesink.c | 24 
  1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/gadget/function/f_sourcesink.c 
b/drivers/usb/gadget/function/f_sourcesink.c
index 80be25b32cd7..7d8f0216e1a6 100644
--- a/drivers/usb/gadget/function/f_sourcesink.c
+++ b/drivers/usb/gadget/function/f_sourcesink.c
@@ -161,7 +161,7 @@ static struct usb_endpoint_descriptor fs_int_source_desc = {

.bEndpointAddress = USB_DIR_IN,
.bmAttributes = USB_ENDPOINT_XFER_INT,
-   .wMaxPacketSize =   cpu_to_le16(64),
+   .wMaxPacketSize =   cpu_to_le16(1024),
.bInterval =GZERO_INT_INTERVAL,
  };

@@ -171,7 +171,7 @@ static struct usb_endpoint_descriptor fs_int_sink_desc = {

.bEndpointAddress = USB_DIR_OUT,
.bmAttributes = USB_ENDPOINT_XFER_INT,
-   .wMaxPacketSize =   cpu_to_le16(64),
+   .wMaxPacketSize =   cpu_to_le16(1024),
.bInterval =GZERO_INT_INTERVAL,
  };



This change in wMAxPacketSize of FS interrupt descriptors is violation 
of the specs.



@@ -556,16 +556,6 @@ sourcesink_bind(struct usb_configuration *c, struct 
usb_function *f)
if (int_maxburst > 15)
int_maxburst = 15;

-   /* fill in the FS interrupt descriptors from the module parameters */
-   fs_int_source_desc.wMaxPacketSize = int_maxpacket > 64 ?
-   64 : int_maxpacket;
-   fs_int_source_desc.bInterval = int_interval > 255 ?
-   255 : int_interval;
-   fs_int_sink_desc.wMaxPacketSize = int_maxpacket > 64 ?
-   64 : int_maxpacket;
-   fs_int_sink_desc.bInterval = int_interval > 255 ?
-   255 : int_interval;
-
/* allocate int endpoints */
ss->int_in_ep = usb_ep_autoconfig(cdev->gadget, &fs_int_source_desc);
if (!ss->int_in_ep)
@@ -587,6 +577,16 @@ sourcesink_bind(struct usb_configuration *c, struct 
usb_function *f)
if (int_maxpacket > 1024)
int_maxpacket = 1024;

+   /* fill in the FS interrupt descriptors from the module parameters */
+   fs_int_source_desc.wMaxPacketSize = int_maxpacket > 64 ?
+   64 : int_maxpacket;
+   fs_int_source_desc.bInterval = int_interval > 255 ?
+   255 : int_interval;
+   fs_int_sink_desc.wMaxPacketSize = int_maxpacket > 64 ?
+   64 : int_maxpacket;
+   fs_int_sink_desc.bInterval = int_interval > 255 ?
+   255 : int_interval;
+
/* support high speed hardware */
hs_source_desc.bEndpointAddress = fs_source_desc.bEndpointAddress;
hs_sink_desc.bEndpointAddress = fs_sink_desc.bEndpointAddress;



Things might be working for you but this is not the correct fix, IMO. 
Looking into the patch I feel it shall introduce other reg

[PATCH net] r8152: drop the tx packet with invalid length

[Hayes Wang]

Drop the tx packet which is more than the size of agg_buf_sz. When
creating a bridge with the device, we may get the tx packet with
TSO and the length is more than the gso_max_size which is set by
the driver through netif_set_gso_max_size(). Such packets couldn't
be transmitted and should be dropped directly.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c6554c7..ebdaff7 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1897,6 +1897,15 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff 
*skb,
 {
struct r8152 *tp = netdev_priv(netdev);
 
+   if ((skb->len + sizeof(struct tx_desc)) > agg_buf_sz) {
+   struct net_device_stats *stats = &netdev->stats;
+
+   dev_kfree_skb_any(skb);
+   stats->tx_dropped++;
+   WARN_ON_ONCE(1);
+   return NETDEV_TX_OK;
+   }
+
skb_tx_timestamp(skb);
 
skb_queue_tail(&tp->tx_queue, skb);
-- 
1.9.3

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