Re: [PATCH v3] xHCI: Fixing xhci_readl definition and function call

[Dan Carpenter]

On Mon, Aug 26, 2013 at 07:38:57AM +0530, Kumar Gaurav wrote:
> This patch redefine function xhci_readl.xhci_readl function doesn't use 
> xhci_hcd argument.
> Hence there is no need of keeping it in the function arguments. 
> 
> Redefining this function breaks other functions which calls this function.
> This phatch also correct those calls in xhci driver. 
> 
> Signed-off-by: Kumar Gaurav 
> ---

Could you put a list of changes since v2 here?:

v3:  blah blah changelog mostly.

Also this doesn't apply for me against linux-next.

regards,
dan carpenter

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

Re: [Pull Request] xhci: Bug fixes for 3.12.

[Dmitry Kasatkin]

On 27/08/13 21:26, Sarah Sharp wrote:
> The following changes since commit 154547c4fe0fbe92185e69a6cdc2b0502b361995:
>
>   USB: serial: clean up attribute permissions (2013-08-25 15:12:03 -0700)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
> tags/for-usb-next-2013-08-27
>
> for you to fetch changes up to 0730d52a86919300a39a2be37f6c140997dfb82f:
>
>   xhci:prevent "callbacks suppressed" when debug is not enabled (2013-08-27 
> 08:56:31 -0700)
>
> 
> xhci: Bug fixes for 3.12.
>
> Hi Greg,
>
> Here's three low-priority bug fixes that should be queued for 3.12.
> They disable runtime PM for hosts that need the XHCI_RESET_ON_RESUME
> quirk, fix USB 2.0 Link PM on hosts that don't have BESL support, and
> prevent a bunch of log spam.
>
> Please pull into usb-next for 3.12.
>
> Sarah Sharp
>
> 
> Dmitry Kasatkin (1):
>   xhci:prevent "callbacks suppressed" when debug is not enabled
>
> Mathias Nyman (1):
>   xhci: fix port BESL LPM capability checking
>
> Shawn Nematbakhsh (1):
>   usb: xhci: Disable runtime PM suspend for quirky controllers
>
>  drivers/usb/host/xhci-ext-caps.h |2 +-
>  drivers/usb/host/xhci-ring.c |   24 
>  drivers/usb/host/xhci.c  |   22 ++
>  3 files changed, 31 insertions(+), 17 deletions(-)
>
Hello,

I sent 2 patches. Only second one was taken. [PATCHv2 2/2]
[PATCHv2 1/2] is required to prevent build break.

Thanks,

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 1/3] usb: add is_usb_mouse routine and remote wakeup quirk

[Huang Rui]

Hi Greg,

I'm glad you can take a look at my patches. :)

On Wed, Aug 28, 2013 at 11:38:28AM +0800, Greg Kroah-Hartman wrote:
> On Wed, Aug 28, 2013 at 11:13:12AM +0800, Huang Rui wrote:
> > This patch add a routine to judge if the usb device is a mouse or not.
> > The is_usb_mouse only has one input parameter of usb_device. The
> > return value is bool type, and true means this device is mouse and
> > vice-versa.
> 
> No, sorry, this isn't ok for a number of reasons.
> 
> You got "lucky" in that you can duplicate this with a mouse, the fact
> that it is a mouse that caused your problems should never mean that the
> os only triggers on a mouse device.  I can create a "keyboard" device
> that has the exact same USB characteristics that a mouse does, that
> should also be able to trigger your problem.  Or a vendor specific
> device.
> 

Yes, you're right. This issue is specific to the devices that use
Pixart controller, and the Pixart controller is only used by mouse.
That's why I filtered for usb mouse. Below answer is our HW guys'
feedback. In cover letter, you would see more details.

[Q] Why the special devices are only mice? Would high speed devices
such as 3G modem or USB Bluetooth adapter trigger this issue?
- Current this sensitivity is only confined to devices that use Pixart
  controllers. This controller is designed for use with LS mouse
devices only. We have not observed any other devices failing. There
may be a small risk for other devices also but this patch (reset
device in resume phase) will cover the cases if required.

> That's why the USB core doesn't care about the device type, they are all
> just "pipes".  So please deal with it on that level, never do something
> only depending on the "type" of device plugged into the system.
> 

I got it. Do you mean if I want do filter usb devices by usb mouse, I
should do it at hid or usbhid level?

> > It also add a remote wakeup quirk for some special AMD platforms. This
> > quirk filters southbridge revision which is 0x39 or 0x3a.
> 
> Whenever your changelog description has the phrase "it also...", that is
> a big hint that you should be breaking this up into multiple patches.
> You are doing two different things in this patch, which is another
> reason why I can't take it.

Thanks to reminder me, I will split it in two patches in v3.

> 
> Please fix this up properly, and that means, not doing things depending
> on the "type" of device, from a protocol standpoint, as that is always
> wrong.
> 

OK, again, shall I do it at hid or usbhid level? If not, I've no idea
how I should do, could you teach me? Or filter devices by "Pixart"?

> Hint, I bet you didn't fix this bug in Windows this way, right?  :)
> 

Actually, this issue is found in Windows firstly, and we set a
registry to force the driver to reset the device on S3 resume to work
around it. Then I reproduce it in Linux OS, and make a same solution. :)

Thanks,
Rui

--
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: Add UDC driver for Aeroflex Gaisler GRUSBDC

[Andreas Larsson]

On 2013-08-12 16:05, Andreas Larsson wrote:

This adds an UDC driver for GRUSBDC USB Device Controller cores available in the
GRLIB VHDL IP core library. The driver only supports DMA mode.


Any comments? It would be great to get feedback soon in case some things 
need to be changed for this driver to be accepted. Thanks!


Cheers,
Andreas Larsson

--
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:[RFT & RFC] USB: Fix USB device disconnects on resume.

[Dmitri Zolotov]

~/linux-3.9.11$ grep -r "TRSMRCY"
drivers/usb/core/hub.c:/* TRSMRCY = 20 msec */
drivers/usb/core/hub.c:/* TRSMRCY = 10 msec */
drivers/usb/core/hcd.c: * unsuspended.  If they are then a TRSMRCY 
delay is needed
drivers/usb/core/hcd.c:usleep_range(1, 11000);/* 
TRSMRCY */
drivers/usb/host/isp1362-hcd.c:/* TRSMRCY */
drivers/usb/host/ohci-hub.c:/* TRSMRCY */
Do these files contain the same 
bug?N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

Announcing libusbx-1.0.17-rc1

[Hans de Goede]

Hi All,

I'm very happy to announce libusbx-1.0.17-rc1.

2013-08-28: v1.0.17-rc1
* Hotplug callbacks now always get passed a libusb_context, even if it is
  the default context. Previously NULL would be passed for the default context,
  but since the first context created is the default context, and most apps
  use only 1 context, this meant that apps explicitly creating a context would
  still get passed NULL
* Android: Add .mk files to build with the Android NDK
* Darwin: Add Xcode project
* Darwin: Fix crash on unplug (#121)
* Linux: Fix hang (deadlock) on libusb_exit
* Linux: Fix libusbx build failure with --disable-udev (#124)
* Linux: Fix libusb_get_device_list() hang with --disable-udev (#130)
* OpenBSD: Update OpenBSD backend with support for control transfers to
  non-ugen(4) devices and make get_configuration() no longer generate I/O.
  Note that using this libusbx version on OpenBSD requires using
  OpenBSD 5.3-current or later. Users of older OpenBSD versions are advised
  to stay with the libusb shipped with OpenBSD (mpi)
* Windows: fix libusb_dll_2010.vcxproj link errors (#129)
* Various other bug fixes and improvements
The (#xx) numbers are libusbx issue numbers, see ie:
https://github.com/libusbx/libusbx/issues/121

You can download the 1.0.17-rc1 tarbal here:
http://downloads.sourceforge.net/libusbx/libusbx-1.0.17-rc1.tar.bz2

Please give it a thorough testing, and report any issues you find.

Regards,

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

Re: [PATCH v1] USB: EHCI: disable IAA_WATCHDOG and START_UNLINK_INTR if they needn't to be handled

[Ming Lei]

On Wed, Aug 28, 2013 at 12:24 PM, Ming Lei  wrote:
> On Wed, 28 Aug 2013 12:02:03 +0800
> Ming Lei  wrote:
>
>> Actually the problem only happened when underrun without
>> URB_ISO_ASAP.
>>
>> I have another fix which uses rebase trick and is simper(less change), could
>> you comment on the attachment patch?
>
> Sorry, please ignore last attachment patch, and comment on the below one:
>
> diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
> index 83be03f..4a3ddc9 100644
> --- a/drivers/usb/host/ehci-sched.c
> +++ b/drivers/usb/host/ehci-sched.c
> @@ -1370,6 +1370,21 @@ sitd_slot_ok (
> return 1;
>  }
>
> +/* rebase in case of underun without ISO_ASAP together */
> +static void iso_stream_rebase(struct ehci_hcd *ehci,
> +   struct ehci_iso_stream  *stream, u32 mod)
> +{
> +   u32 i;
> +
> +   if (ehci->last_base == -1)
> +   return;
> +
> +   for (i = ehci->last_base; i != ehci->last_iso_frame;
> +   i = (i + 1) & (mod - 1))
> +   if ((stream->next_uframe & (mod - 1)) == i)
> +   ehci->last_iso_frame = i;
> +}

mod should switch to ehci->periodic_size, and stream->next_uframe
should convert to frame.

Also if the URB has been completed('now' is behind 'start + span'), the URB
need to complete immediately, or rescan after linking simply.

I will prepare for another one later.

> +
>  /*
>   * This scheduler plans almost as far into the future as it has actual
>   * periodic schedule slots.  (Affected by TUNE_FLS, which defaults to
> @@ -1409,7 +1424,9 @@ iso_stream_schedule (
>  * (irq delays etc).  If there are, the behavior depends on
>  * whether URB_ISO_ASAP is set.
>  */
> -   if (likely (!list_empty (&stream->td_list))) {
> +   if (likely (!list_empty (&stream->td_list) ||
> +   hcd_complete_in_progress(
> +   ehci_to_hcd(ehci), urb))) {
>
> /* Take the isochronous scheduling threshold into account */
> if (ehci->i_thresh)
> @@ -1417,6 +1434,10 @@ iso_stream_schedule (
> else
> next = (now + 2 + 7) & ~0x07;   /* full frame cache */
>
> +   if (list_empty(&stream->td_list) &&
> +   !(urb->transfer_flags & URB_ISO_ASAP))
> +   iso_stream_rebase(ehci, stream, mod);
> +
> /*
>  * Use ehci->last_iso_frame as the base.  There can't be any
>  * TDs scheduled for earlier than that.
> @@ -1517,6 +1538,7 @@ iso_stream_schedule (
> /* Make sure scan_isoc() sees these */
> if (ehci->isoc_count == 0)
> ehci->last_iso_frame = now >> 3;
> +   ehci->last_base = -1;
> return 0;
>
>   fail:
> @@ -2255,6 +2277,9 @@ static void scan_isoc(struct ehci_hcd *ehci)
> }
> ehci->now_frame = now_frame;
>
> +   if (ehci->last_base == -1)
> +   ehci->last_base = ehci->last_iso_frame;
> +
> frame = ehci->last_iso_frame;
> for (;;) {
> union ehci_shadow   q, *q_p;
>
>

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

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  wrote:
> Hi all,
>
> Changes since 20130827:
>
> The f2fs tree lost its build failure.
>
> The md tree gained a conflict against the arm tree.
>
> The libata tree lost its build failure.
>
> The spi tree lost its build failure.
>
> The arm-soc tree gained conflicts against the usb tree.
>
> The dma-mapping tree gained a conflict against the driver-core tree.
>
> The akpm-current tree gained a conflict against the net tree.
>
> 
>
> My build here breaks like this:
>
>   CC  drivers/usb/host/xhci-ring.o
>   CC  drivers/video/console/softcursor.o
> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
> [-Werror=implicit-function-declaration]
> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
> (first use in this function)
> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
> is reported only once for each function it appears in
> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
> (first use in this function)
> cc1: some warnings being treated as errors
> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
> make[4]: *** [drivers/usb/host] Error 2
>
> My kernel-config is attached.
>

Looks like  or  is missing.

$ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr linux/include/
linux/include/linux/device.h:1118:
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
linux/include/linux/device.h:1121:
__dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
_ddebug *descriptor, const char *fmt, ...);
linux/include/linux/dynamic_debug.h:63:#define
DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
linux/include/linux/dynamic_debug.h:76:
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
linux/include/linux/dynamic_debug.h:78:
__dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
linux/include/linux/dynamic_debug.h:84:
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
linux/include/linux/dynamic_debug.h:92:
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
linux/include/linux/dynamic_debug.h:101:
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \

Can't say which one is preferred here.

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

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 11:56 AM, Sedat Dilek  wrote:
> On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  wrote:
>> Hi all,
>>
>> Changes since 20130827:
>>
>> The f2fs tree lost its build failure.
>>
>> The md tree gained a conflict against the arm tree.
>>
>> The libata tree lost its build failure.
>>
>> The spi tree lost its build failure.
>>
>> The arm-soc tree gained conflicts against the usb tree.
>>
>> The dma-mapping tree gained a conflict against the driver-core tree.
>>
>> The akpm-current tree gained a conflict against the net tree.
>>
>> 
>>
>> My build here breaks like this:
>>
>>   CC  drivers/usb/host/xhci-ring.o
>>   CC  drivers/video/console/softcursor.o
>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
>> [-Werror=implicit-function-declaration]
>> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
>> (first use in this function)
>> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
>> is reported only once for each function it appears in
>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
>> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
>> (first use in this function)
>> cc1: some warnings being treated as errors
>> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
>> make[4]: *** [drivers/usb/host] Error 2
>>
>> My kernel-config is attached.
>>
>
> Looks like  or  is missing.
>
> $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr 
> linux/include/
> linux/include/linux/device.h:1118:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> linux/include/linux/device.h:1121:
> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
> linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
> _ddebug *descriptor, const char *fmt, ...);
> linux/include/linux/dynamic_debug.h:63:#define
> DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
> linux/include/linux/dynamic_debug.h:76:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> linux/include/linux/dynamic_debug.h:78:
> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
> linux/include/linux/dynamic_debug.h:84:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> linux/include/linux/dynamic_debug.h:92:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> linux/include/linux/dynamic_debug.h:101:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
>
> Can't say which one is preferred here.
>

looks like device.h is preferred or used in the sources, but this does
not fix the issue here.
sth. wrong with dev_dbg_ratelimited()?

- sedat -


xhci-ring.diff
Description: Binary data

Re: [patch] usb: musb: unlock on error in cppi41_dma_callback()

[Dan Carpenter]

On Tue, Aug 27, 2013 at 03:05:27PM -0500, Felipe Balbi wrote:
> On Wed, Aug 21, 2013 at 11:38:21AM +0300, Dan Carpenter wrote:
> > We need to unlock and enable IRQs before returning on error.
> > 
> > Signed-off-by: Dan Carpenter 
> 
> doesn't apply

Wei Yongjun already fixed the bug.

regards,
dan carpenter

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

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 12:29 PM, Sedat Dilek  wrote:
> On Wed, Aug 28, 2013 at 11:56 AM, Sedat Dilek  wrote:
>> On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  wrote:
>>> Hi all,
>>>
>>> Changes since 20130827:
>>>
>>> The f2fs tree lost its build failure.
>>>
>>> The md tree gained a conflict against the arm tree.
>>>
>>> The libata tree lost its build failure.
>>>
>>> The spi tree lost its build failure.
>>>
>>> The arm-soc tree gained conflicts against the usb tree.
>>>
>>> The dma-mapping tree gained a conflict against the driver-core tree.
>>>
>>> The akpm-current tree gained a conflict against the net tree.
>>>
>>> 
>>>
>>> My build here breaks like this:
>>>
>>>   CC  drivers/usb/host/xhci-ring.o
>>>   CC  drivers/video/console/softcursor.o
>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
>>> [-Werror=implicit-function-declaration]
>>> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
>>> (first use in this function)
>>> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
>>> is reported only once for each function it appears in
>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
>>> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
>>> (first use in this function)
>>> cc1: some warnings being treated as errors
>>> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
>>> make[4]: *** [drivers/usb/host] Error 2
>>>
>>> My kernel-config is attached.
>>>
>>
>> Looks like  or  is missing.
>>
>> $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr 
>> linux/include/
>> linux/include/linux/device.h:1118:
>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>> linux/include/linux/device.h:1121:
>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>> linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
>> _ddebug *descriptor, const char *fmt, ...);
>> linux/include/linux/dynamic_debug.h:63:#define
>> DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
>> linux/include/linux/dynamic_debug.h:76:
>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>> linux/include/linux/dynamic_debug.h:78:
>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>> linux/include/linux/dynamic_debug.h:84:
>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>> linux/include/linux/dynamic_debug.h:92:
>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>> linux/include/linux/dynamic_debug.h:101:
>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
>>
>> Can't say which one is preferred here.
>>
>
> looks like device.h is preferred or used in the sources, but this does
> not fix the issue here.
> sth. wrong with dev_dbg_ratelimited()?
>

That change seems to cause the problems:

commit 0730d52a86919300a39a2be37f6c140997dfb82f
"xhci:prevent "callbacks suppressed" when debug is not enabled"

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Dmitry Kasatkin]

On 28/08/13 13:38, Sedat Dilek wrote:
> On Wed, Aug 28, 2013 at 12:29 PM, Sedat Dilek  wrote:
>> On Wed, Aug 28, 2013 at 11:56 AM, Sedat Dilek  wrote:
>>> On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  wrote:
 Hi all,

 Changes since 20130827:

 The f2fs tree lost its build failure.

 The md tree gained a conflict against the arm tree.

 The libata tree lost its build failure.

 The spi tree lost its build failure.

 The arm-soc tree gained conflicts against the usb tree.

 The dma-mapping tree gained a conflict against the driver-core tree.

 The akpm-current tree gained a conflict against the net tree.

 

 My build here breaks like this:

   CC  drivers/usb/host/xhci-ring.o
   CC  drivers/video/console/softcursor.o
 drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
 drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
 function 'DEFINE_DYNAMIC_DEBUG_METADATA'
 [-Werror=implicit-function-declaration]
 drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
 (first use in this function)
 drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
 is reported only once for each function it appears in
 drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
 function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
 drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
 drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
 (first use in this function)
 cc1: some warnings being treated as errors
 make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
 make[4]: *** [drivers/usb/host] Error 2

 My kernel-config is attached.

>>> Looks like  or  is missing.
>>>
>>> $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr 
>>> linux/include/
>>> linux/include/linux/device.h:1118:
>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>> linux/include/linux/device.h:1121:
>>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>> linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
>>> _ddebug *descriptor, const char *fmt, ...);
>>> linux/include/linux/dynamic_debug.h:63:#define
>>> DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
>>> linux/include/linux/dynamic_debug.h:76:
>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>> linux/include/linux/dynamic_debug.h:78:
>>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>> linux/include/linux/dynamic_debug.h:84:
>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>> linux/include/linux/dynamic_debug.h:92:
>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>> linux/include/linux/dynamic_debug.h:101:
>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
>>>
>>> Can't say which one is preferred here.
>>>
>> looks like device.h is preferred or used in the sources, but this does
>> not fix the issue here.
>> sth. wrong with dev_dbg_ratelimited()?
>>
> That change seems to cause the problems:
>
> commit 0730d52a86919300a39a2be37f6c140997dfb82f
> "xhci:prevent "callbacks suppressed" when debug is not enabled"
>
> - Sedat -
>
> [1] 
> http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
>
Hello,

[PATCHv2 1/2] was not applied before.
I pointed this out few hours ago...

- 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 v11 0/8] PHY framework

[Kishon Vijay Abraham I]

Hi,

On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote:
>> On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote:
>>> Added a generic PHY framework that provides a set of APIs for the PHY 
>>> drivers
>>> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
>>> the PHY with or without using phandle.
>>>
>>> This framework will be of use only to devices that uses external PHY (PHY
>>> functionality is not embedded within the controller).
>>>
>>> The intention of creating this framework is to bring the phy drivers spread
>>> all over the Linux kernel to drivers/phy to increase code re-use and to
>>> increase code maintainability.
>>>
>>> Comments to make PHY as bus wasn't done because PHY devices can be part of
>>> other bus and making a same device attached to multiple bus leads to bad
>>> design.
>>>
>>> If the PHY driver has to send notification on connect/disconnect, the PHY
>>> driver should make use of the extcon framework. Using this susbsystem
>>> to use extcon framwork will have to be analysed.
>>>
>>> You can find this patch series @
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing
>>
>> Looks like there are not further comments on this series. Can you take this 
>> in
>> your misc tree?
> 
> Do you want me to queue these for you ? There are quite a few users for
> this framework already and I know of at least 2 others which will show
> up for v3.13.

yeah sure. That would be better I think.

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

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 12:43 PM, Dmitry Kasatkin
 wrote:
> On 28/08/13 13:38, Sedat Dilek wrote:
>> On Wed, Aug 28, 2013 at 12:29 PM, Sedat Dilek  wrote:
>>> On Wed, Aug 28, 2013 at 11:56 AM, Sedat Dilek  wrote:
 On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  
 wrote:
> Hi all,
>
> Changes since 20130827:
>
> The f2fs tree lost its build failure.
>
> The md tree gained a conflict against the arm tree.
>
> The libata tree lost its build failure.
>
> The spi tree lost its build failure.
>
> The arm-soc tree gained conflicts against the usb tree.
>
> The dma-mapping tree gained a conflict against the driver-core tree.
>
> The akpm-current tree gained a conflict against the net tree.
>
> 
>
> My build here breaks like this:
>
>   CC  drivers/usb/host/xhci-ring.o
>   CC  drivers/video/console/softcursor.o
> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
> [-Werror=implicit-function-declaration]
> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
> (first use in this function)
> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
> is reported only once for each function it appears in
> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
> (first use in this function)
> cc1: some warnings being treated as errors
> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
> make[4]: *** [drivers/usb/host] Error 2
>
> My kernel-config is attached.
>
 Looks like  or  is missing.

 $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr 
 linux/include/
 linux/include/linux/device.h:1118:
 DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
 linux/include/linux/device.h:1121:
 __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
 linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
 _ddebug *descriptor, const char *fmt, ...);
 linux/include/linux/dynamic_debug.h:63:#define
 DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
 linux/include/linux/dynamic_debug.h:76:
 DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
 linux/include/linux/dynamic_debug.h:78:
 __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
 linux/include/linux/dynamic_debug.h:84:
 DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
 linux/include/linux/dynamic_debug.h:92:
 DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
 linux/include/linux/dynamic_debug.h:101:
 DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \

 Can't say which one is preferred here.

>>> looks like device.h is preferred or used in the sources, but this does
>>> not fix the issue here.
>>> sth. wrong with dev_dbg_ratelimited()?
>>>
>> That change seems to cause the problems:
>>
>> commit 0730d52a86919300a39a2be37f6c140997dfb82f
>> "xhci:prevent "callbacks suppressed" when debug is not enabled"
>>
>> - Sedat -
>>
>> [1] 
>> http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
>>
> Hello,
>
> [PATCHv2 1/2] was not applied before.
> I pointed this out few hours ago...
>
> - Dmitry
>

Yupp, just read it a few seconds ago.

Where is that whatever 2nd fix?

- Sedat -

[1] http://marc.info/?l=linux-usb&m=137767590629869&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch] dma: cppi41: off by one in desc_to_chan()

[Dan Carpenter]

The test here should be ">=" instead of ">".  The cdd->chan_busy[] array
has "ALLOC_DECS_NUM" elements.

Signed-off-by: Dan Carpenter 
Acked-by: Vinod Koul 
---
Resending to Greg and the USB people because Vinod says this goes
through the USB tree.

diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 5dcebca..7f6524c 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -241,7 +241,7 @@ static struct cppi41_channel *desc_to_chan(struct cppi41_dd 
*cdd, u32 desc)
}
 
desc_num = (desc - cdd->descs_phys) / sizeof(struct cppi41_desc);
-   BUG_ON(desc_num > ALLOC_DECS_NUM);
+   BUG_ON(desc_num >= ALLOC_DECS_NUM);
c = cdd->chan_busy[desc_num];
cdd->chan_busy[desc_num] = NULL;
return c;

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

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 12:46 PM, Sedat Dilek  wrote:
> On Wed, Aug 28, 2013 at 12:43 PM, Dmitry Kasatkin
>  wrote:
>> On 28/08/13 13:38, Sedat Dilek wrote:
>>> On Wed, Aug 28, 2013 at 12:29 PM, Sedat Dilek  wrote:
 On Wed, Aug 28, 2013 at 11:56 AM, Sedat Dilek  
 wrote:
> On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  
> wrote:
>> Hi all,
>>
>> Changes since 20130827:
>>
>> The f2fs tree lost its build failure.
>>
>> The md tree gained a conflict against the arm tree.
>>
>> The libata tree lost its build failure.
>>
>> The spi tree lost its build failure.
>>
>> The arm-soc tree gained conflicts against the usb tree.
>>
>> The dma-mapping tree gained a conflict against the driver-core tree.
>>
>> The akpm-current tree gained a conflict against the net tree.
>>
>> 
>>
>> My build here breaks like this:
>>
>>   CC  drivers/usb/host/xhci-ring.o
>>   CC  drivers/video/console/softcursor.o
>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
>> [-Werror=implicit-function-declaration]
>> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
>> (first use in this function)
>> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
>> is reported only once for each function it appears in
>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
>> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
>> (first use in this function)
>> cc1: some warnings being treated as errors
>> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
>> make[4]: *** [drivers/usb/host] Error 2
>>
>> My kernel-config is attached.
>>
> Looks like  or  is missing.
>
> $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr 
> linux/include/
> linux/include/linux/device.h:1118:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> linux/include/linux/device.h:1121:
> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
> linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
> _ddebug *descriptor, const char *fmt, ...);
> linux/include/linux/dynamic_debug.h:63:#define
> DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
> linux/include/linux/dynamic_debug.h:76:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> linux/include/linux/dynamic_debug.h:78:
> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
> linux/include/linux/dynamic_debug.h:84:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> linux/include/linux/dynamic_debug.h:92:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> linux/include/linux/dynamic_debug.h:101:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
>
> Can't say which one is preferred here.
>
 looks like device.h is preferred or used in the sources, but this does
 not fix the issue here.
 sth. wrong with dev_dbg_ratelimited()?

>>> That change seems to cause the problems:
>>>
>>> commit 0730d52a86919300a39a2be37f6c140997dfb82f
>>> "xhci:prevent "callbacks suppressed" when debug is not enabled"
>>>
>>> - Sedat -
>>>
>>> [1] 
>>> http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
>>>
>> Hello,
>>
>> [PATCHv2 1/2] was not applied before.
>> I pointed this out few hours ago...
>>
>> - Dmitry
>>
>
> Yupp, just read it a few seconds ago.
>
> Where is that whatever 2nd fix?
>
> - Sedat -
>
> [1] http://marc.info/?l=linux-usb&m=137767590629869&w=2

Was 1/2 sent to linux-usb, too?

I found your patch in the linux-kernel offline mail-archives.

[PATCHv2 1/2] dev-core: fix build break when DEBUG is enabled

- Sedat -

http://marc.info/?l=linux-kernel&m=137761487111748&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Dmitry Kasatkin]

On 28/08/13 13:46, Sedat Dilek wrote:
> On Wed, Aug 28, 2013 at 12:43 PM, Dmitry Kasatkin
>  wrote:
>> On 28/08/13 13:38, Sedat Dilek wrote:
>>> On Wed, Aug 28, 2013 at 12:29 PM, Sedat Dilek  wrote:
 On Wed, Aug 28, 2013 at 11:56 AM, Sedat Dilek  
 wrote:
> On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  
> wrote:
>> Hi all,
>>
>> Changes since 20130827:
>>
>> The f2fs tree lost its build failure.
>>
>> The md tree gained a conflict against the arm tree.
>>
>> The libata tree lost its build failure.
>>
>> The spi tree lost its build failure.
>>
>> The arm-soc tree gained conflicts against the usb tree.
>>
>> The dma-mapping tree gained a conflict against the driver-core tree.
>>
>> The akpm-current tree gained a conflict against the net tree.
>>
>> 
>>
>> My build here breaks like this:
>>
>>   CC  drivers/usb/host/xhci-ring.o
>>   CC  drivers/video/console/softcursor.o
>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
>> [-Werror=implicit-function-declaration]
>> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
>> (first use in this function)
>> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
>> is reported only once for each function it appears in
>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
>> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
>> (first use in this function)
>> cc1: some warnings being treated as errors
>> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
>> make[4]: *** [drivers/usb/host] Error 2
>>
>> My kernel-config is attached.
>>
> Looks like  or  is missing.
>
> $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr 
> linux/include/
> linux/include/linux/device.h:1118:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> linux/include/linux/device.h:1121:
> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
> linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
> _ddebug *descriptor, const char *fmt, ...);
> linux/include/linux/dynamic_debug.h:63:#define
> DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
> linux/include/linux/dynamic_debug.h:76:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> linux/include/linux/dynamic_debug.h:78:
> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
> linux/include/linux/dynamic_debug.h:84:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> linux/include/linux/dynamic_debug.h:92:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> linux/include/linux/dynamic_debug.h:101:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
>
> Can't say which one is preferred here.
>
 looks like device.h is preferred or used in the sources, but this does
 not fix the issue here.
 sth. wrong with dev_dbg_ratelimited()?

>>> That change seems to cause the problems:
>>>
>>> commit 0730d52a86919300a39a2be37f6c140997dfb82f
>>> "xhci:prevent "callbacks suppressed" when debug is not enabled"
>>>
>>> - Sedat -
>>>
>>> [1] 
>>> http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
>>>
>> Hello,
>>
>> [PATCHv2 1/2] was not applied before.
>> I pointed this out few hours ago...
>>
>> - Dmitry
>>
> Yupp, just read it a few seconds ago.
>
> Where is that whatever 2nd fix?
>
> - Sedat -
>
> [1] http://marc.info/?l=linux-usb&m=137767590629869&w=2
>

1/2 - was not applied
https://patchwork.kernel.org/patch/2850217/

2/2 - this one was applied
https://patchwork.kernel.org/patch/2850218/

- 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: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 12:53 PM, Dmitry Kasatkin
 wrote:
> On 28/08/13 13:46, Sedat Dilek wrote:
>> On Wed, Aug 28, 2013 at 12:43 PM, Dmitry Kasatkin
>>  wrote:
>>> On 28/08/13 13:38, Sedat Dilek wrote:
 On Wed, Aug 28, 2013 at 12:29 PM, Sedat Dilek  
 wrote:
> On Wed, Aug 28, 2013 at 11:56 AM, Sedat Dilek  
> wrote:
>> On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  
>> wrote:
>>> Hi all,
>>>
>>> Changes since 20130827:
>>>
>>> The f2fs tree lost its build failure.
>>>
>>> The md tree gained a conflict against the arm tree.
>>>
>>> The libata tree lost its build failure.
>>>
>>> The spi tree lost its build failure.
>>>
>>> The arm-soc tree gained conflicts against the usb tree.
>>>
>>> The dma-mapping tree gained a conflict against the driver-core tree.
>>>
>>> The akpm-current tree gained a conflict against the net tree.
>>>
>>> 
>>>
>>> My build here breaks like this:
>>>
>>>   CC  drivers/usb/host/xhci-ring.o
>>>   CC  drivers/video/console/softcursor.o
>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
>>> [-Werror=implicit-function-declaration]
>>> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
>>> (first use in this function)
>>> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
>>> is reported only once for each function it appears in
>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
>>> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
>>> (first use in this function)
>>> cc1: some warnings being treated as errors
>>> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
>>> make[4]: *** [drivers/usb/host] Error 2
>>>
>>> My kernel-config is attached.
>>>
>> Looks like  or  is missing.
>>
>> $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr 
>> linux/include/
>> linux/include/linux/device.h:1118:
>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>> linux/include/linux/device.h:1121:
>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>> linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
>> _ddebug *descriptor, const char *fmt, ...);
>> linux/include/linux/dynamic_debug.h:63:#define
>> DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
>> linux/include/linux/dynamic_debug.h:76:
>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>> linux/include/linux/dynamic_debug.h:78:
>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>> linux/include/linux/dynamic_debug.h:84:
>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>> linux/include/linux/dynamic_debug.h:92:
>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>> linux/include/linux/dynamic_debug.h:101:
>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
>>
>> Can't say which one is preferred here.
>>
> looks like device.h is preferred or used in the sources, but this does
> not fix the issue here.
> sth. wrong with dev_dbg_ratelimited()?
>
 That change seems to cause the problems:

 commit 0730d52a86919300a39a2be37f6c140997dfb82f
 "xhci:prevent "callbacks suppressed" when debug is not enabled"

 - Sedat -

 [1] 
 http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f

>>> Hello,
>>>
>>> [PATCHv2 1/2] was not applied before.
>>> I pointed this out few hours ago...
>>>
>>> - Dmitry
>>>
>> Yupp, just read it a few seconds ago.
>>
>> Where is that whatever 2nd fix?
>>
>> - Sedat -
>>
>> [1] http://marc.info/?l=linux-usb&m=137767590629869&w=2
>>
>
> 1/2 - was not applied
> https://patchwork.kernel.org/patch/2850217/
>
> 2/2 - this one was applied
> https://patchwork.kernel.org/patch/2850218/
>
> - Dmitry
>

Thanks for the patchwork-URLs, it's easier to apply from there.

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

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 12:53 PM, Dmitry Kasatkin
 wrote:
> On 28/08/13 13:46, Sedat Dilek wrote:
>> On Wed, Aug 28, 2013 at 12:43 PM, Dmitry Kasatkin
>>  wrote:
>>> On 28/08/13 13:38, Sedat Dilek wrote:
>>>> On Wed, Aug 28, 2013 at 12:29 PM, Sedat Dilek  
>>>> wrote:
>>>>> On Wed, Aug 28, 2013 at 11:56 AM, Sedat Dilek  
>>>>> wrote:
>>>>>> On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  
>>>>>> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Changes since 20130827:
>>>>>>>
>>>>>>> The f2fs tree lost its build failure.
>>>>>>>
>>>>>>> The md tree gained a conflict against the arm tree.
>>>>>>>
>>>>>>> The libata tree lost its build failure.
>>>>>>>
>>>>>>> The spi tree lost its build failure.
>>>>>>>
>>>>>>> The arm-soc tree gained conflicts against the usb tree.
>>>>>>>
>>>>>>> The dma-mapping tree gained a conflict against the driver-core tree.
>>>>>>>
>>>>>>> The akpm-current tree gained a conflict against the net tree.
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> My build here breaks like this:
>>>>>>>
>>>>>>>   CC  drivers/usb/host/xhci-ring.o
>>>>>>>   CC  drivers/video/console/softcursor.o
>>>>>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>>>>>> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
>>>>>>> [-Werror=implicit-function-declaration]
>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
>>>>>>> (first use in this function)
>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
>>>>>>> is reported only once for each function it appears in
>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>>>>>> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
>>>>>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
>>>>>>> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
>>>>>>> (first use in this function)
>>>>>>> cc1: some warnings being treated as errors
>>>>>>> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
>>>>>>> make[4]: *** [drivers/usb/host] Error 2
>>>>>>>
>>>>>>> My kernel-config is attached.
>>>>>>>
>>>>>> Looks like  or  is missing.
>>>>>>
>>>>>> $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr 
>>>>>> linux/include/
>>>>>> linux/include/linux/device.h:1118:
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>> linux/include/linux/device.h:1121:
>>>>>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>>>>> linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
>>>>>> _ddebug *descriptor, const char *fmt, ...);
>>>>>> linux/include/linux/dynamic_debug.h:63:#define
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
>>>>>> linux/include/linux/dynamic_debug.h:76:
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>> linux/include/linux/dynamic_debug.h:78:
>>>>>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>>>>> linux/include/linux/dynamic_debug.h:84:
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>> linux/include/linux/dynamic_debug.h:92:
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>> linux/include/linux/dynamic_debug.h:101:
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
>>>>>>
>>>>>> Can't say which one is preferred here.
>>>>>>
>>>>> looks like device.h is preferred or used in the sources, but this does
>>>>> not fix the issue here.
>>>>> sth. wrong with dev_dbg_ratelimited()?
>>>>>
>>>> That change seems to cause the problems:
>>>>
>>>> commit 0730d52a86919300a39a2be37f6c140997dfb82f
>>>> "xhci:prevent "callbacks suppressed" when debug is not enabled"
>>>>
>>>> - Sedat -
>>>>
>>>> [1] 
>>>> http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
>>>>
>>> Hello,
>>>
>>> [PATCHv2 1/2] was not applied before.
>>> I pointed this out few hours ago...
>>>
>>> - Dmitry
>>>
>> Yupp, just read it a few seconds ago.
>>
>> Where is that whatever 2nd fix?
>>
>> - Sedat -
>>
>> [1] http://marc.info/?l=linux-usb&m=137767590629869&w=2
>>
>
> 1/2 - was not applied
> https://patchwork.kernel.org/patch/2850217/
>

Tested-by: Sedat Dilek  (against next-20130828).

- Sedat -

> 2/2 - this one was applied
> https://patchwork.kernel.org/patch/2850218/
>
> - 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

[v2 PATCH 3/3] staging: ozwpan: Return error, if PD is not connected.

[Rupesh Gujare]

Return error if we receive write(), while PD is not connected.

Signed-off-by: Rupesh Gujare 
---
 drivers/staging/ozwpan/ozcdev.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/ozwpan/ozcdev.c b/drivers/staging/ozwpan/ozcdev.c
index 50722ea..6ccb64f 100644
--- a/drivers/staging/ozwpan/ozcdev.c
+++ b/drivers/staging/ozwpan/ozcdev.c
@@ -162,6 +162,8 @@ static ssize_t oz_cdev_write(struct file *filp, const char 
__user *buf,
spin_unlock_bh(&g_cdev.lock);
if (pd == NULL)
return -ENXIO;
+   if (!(pd->state & OZ_PD_S_CONNECTED))
+   return -EAGAIN;
eb = &pd->elt_buff;
ei = oz_elt_info_alloc(eb);
if (ei == NULL) {
-- 
1.7.9.5

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

[v2 PATCH 2/3] staging: ozwpan: Change error number.

[Rupesh Gujare]

Incorrect error number was returned here (EPERM), ENXIO is more
appropriate.

Signed-off-by: Rupesh Gujare 
---
 drivers/staging/ozwpan/ozcdev.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ozwpan/ozcdev.c b/drivers/staging/ozwpan/ozcdev.c
index 03b41ee..50722ea 100644
--- a/drivers/staging/ozwpan/ozcdev.c
+++ b/drivers/staging/ozwpan/ozcdev.c
@@ -161,7 +161,7 @@ static ssize_t oz_cdev_write(struct file *filp, const char 
__user *buf,
oz_pd_get(pd);
spin_unlock_bh(&g_cdev.lock);
if (pd == NULL)
-   return -1;
+   return -ENXIO;
eb = &pd->elt_buff;
ei = oz_elt_info_alloc(eb);
if (ei == NULL) {
-- 
1.7.9.5

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

[v2 PATCH 1/3] staging: ozwpan: Increase ISOC IN buffer depth

[Rupesh Gujare]

Buffer depth of 50 units is not sufficient when there is considerable delay
occuring on air due to interference, increase ISOC IN buffer depth to 100 units.

Signed-off-by: Rupesh Gujare 
---
 drivers/staging/ozwpan/ozhcd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ozwpan/ozhcd.c b/drivers/staging/ozwpan/ozhcd.c
index d6c3d0e..d9c43c3 100644
--- a/drivers/staging/ozwpan/ozhcd.c
+++ b/drivers/staging/ozwpan/ozhcd.c
@@ -39,7 +39,7 @@
  * Number of units of buffering to capture for an isochronous IN endpoint 
before
  * allowing data to be indicated up.
  */
-#define OZ_IN_BUFFERING_UNITS  50
+#define OZ_IN_BUFFERING_UNITS  100
 
 /* Name of our platform device.
  */
-- 
1.7.9.5

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

Re: [RFC 3/3] EHCI: handle late isochronous submissions

[Ming Lei]

On Mon, 26 Aug 2013 14:50:53 -0400 (EDT)
Alan Stern  wrote:

> This patch does the real work.  It fixes up ehci-hcd so that an URB 
> submitted by a completion handler will keep the isochronous stream 
> alive, even if the handler was delayed by running in a tasklet and the 
> queue has emptied out.
> 
> As I mentioned earlier, this is not a simple change.
> 
> Alan Stern
> 
> 
> 
>  drivers/usb/host/ehci-sched.c |  164 
> +-
>  drivers/usb/host/ehci.h   |1 
>  2 files changed, 101 insertions(+), 64 deletions(-)

Below is the approach I proposed(mentioned in another thread), which should be
simper than this one, any comments?

 drivers/usb/host/ehci-sched.c |   53 ++---
 drivers/usb/host/ehci.h   |1 +
 2 files changed, 51 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
index 83be03f..80ef95d 100644
--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -1370,6 +1370,33 @@ sitd_slot_ok (
return 1;
 }
 
+/* rebase in case of underun without ISO_ASAP together */
+static int iso_stream_rebase(struct ehci_hcd *ehci, struct urb *urb,
+   struct ehci_iso_stream  *stream, u32 span, u32 period)
+{
+   u32 i, end;
+   u32 mod = ehci->periodic_size;
+
+   if (ehci->last_base == -1)
+   return 0;
+
+   end = ((stream->next_uframe + span - period) >> 3) & (mod - 1);
+   for (i = ehci->last_base; i != ehci->last_iso_frame;
+   i = (i + 1) & (mod - 1)) {
+   /* don't schedule URB which is behind base totally */
+   if (end == i) {
+   for (i = 0; i < urb->number_of_packets; i++) {
+   urb->iso_frame_desc[i].length = 0;
+   urb->iso_frame_desc[i].status = 0;
+   }
+   return 1;
+   }
+   if (((stream->next_uframe >> 3) & (mod - 1)) == i)
+   ehci->last_iso_frame = i;
+   }
+   return 0;
+}
+
 /*
  * This scheduler plans almost as far into the future as it has actual
  * periodic schedule slots.  (Affected by TUNE_FLS, which defaults to
@@ -1409,7 +1436,9 @@ iso_stream_schedule (
 * (irq delays etc).  If there are, the behavior depends on
 * whether URB_ISO_ASAP is set.
 */
-   if (likely (!list_empty (&stream->td_list))) {
+   if (likely (!list_empty (&stream->td_list) ||
+   hcd_complete_in_progress(
+   ehci_to_hcd(ehci), urb))) {
 
/* Take the isochronous scheduling threshold into account */
if (ehci->i_thresh)
@@ -1417,6 +1446,14 @@ iso_stream_schedule (
else
next = (now + 2 + 7) & ~0x07;   /* full frame cache */
 
+   if (list_empty(&stream->td_list) &&
+   !(urb->transfer_flags & URB_ISO_ASAP))
+   if (iso_stream_rebase(ehci, urb, stream, span,
+   period)) {
+   status = 1;
+   goto fail;
+   }
+
/*
 * Use ehci->last_iso_frame as the base.  There can't be any
 * TDs scheduled for earlier than that.
@@ -1517,6 +1554,7 @@ iso_stream_schedule (
/* Make sure scan_isoc() sees these */
if (ehci->isoc_count == 0)
ehci->last_iso_frame = now >> 3;
+   ehci->last_base = -1;
return 0;
 
  fail:
@@ -1838,7 +1876,10 @@ static int itd_submit (struct ehci_hcd *ehci, struct urb 
*urb,
status = iso_stream_schedule(ehci, urb, stream);
if (likely (status == 0))
itd_link_urb (ehci, urb, ehci->periodic_size << 3, stream);
-   else
+   else if (status > 0) {
+   ehci_urb_done(ehci, urb, 0);
+   status = 0;
+   } else
usb_hcd_unlink_urb_from_ep(ehci_to_hcd(ehci), urb);
  done_not_linked:
spin_unlock_irqrestore (&ehci->lock, flags);
@@ -2224,7 +2265,10 @@ static int sitd_submit (struct ehci_hcd *ehci, struct 
urb *urb,
status = iso_stream_schedule(ehci, urb, stream);
if (status == 0)
sitd_link_urb (ehci, urb, ehci->periodic_size << 3, stream);
-   else
+   else if (status > 0) {
+   ehci_urb_done(ehci, urb, 0);
+   status = 0;
+   } else
usb_hcd_unlink_urb_from_ep(ehci_to_hcd(ehci), urb);
  done_not_linked:
spin_unlock_irqrestore (&ehci->lock, flags);
@@ -2255,6 +2299,9 @@ static void scan_isoc(struct ehci_hcd *ehci)
}
ehci->now_frame = now_frame;
 
+   if (ehci->last_base == -1)
+   ehci->last_base = ehci->last_iso_frame;
+
frame = ehci->last_iso_frame;
for (;;) {

ehci-pci 0000:00:1a.0: DMA-API: device driver maps memory fromstack

[Richard Ryniker]

https://bugzilla.redhat.com/show_bug.cgi?id=1001806

Aug 26 16:11:36 localhost kernel: [ cut here ]
Aug 26 16:11:36 localhost kernel: WARNING: CPU: 0 PID: 54 at
lib/dma-debug.c:950 check_for_stack+0xa0/0x100()
Aug 26 16:11:36 localhost kernel: ehci-pci :00:1a.0: DMA-API: device
driver maps memory fromstack [addr=880427629376]
Aug 26 16:11:36 localhost kernel: Modules linked in: floppy(+) scsi_dh_rdac
scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua iscsi_tcp libiscsi_tcp libiscsi
scsi_transport_iscsi squashfs cramfs edd dm_multipath
Aug 26 16:11:36 localhost kernel: CPU: 0 PID: 54 Comm: khubd Not tainted
3.11.0-0.rc6.git4.1.fc20.x86_64 #1
Aug 26 16:11:36 localhost kernel: Hardware name: LENOVO 7745/7745, BIOS
DUKT31AUS 05/23/2011
Aug 26 16:11:36 localhost kernel:  0009 880427629028
81723846 880427629070
Aug 26 16:11:36 localhost kernel:  880427629060 8107464d
880427f9c5b8 88042752bae0
Aug 26 16:11:36 localhost kernel:  880427629376 880427f9c5b8
81c27440 8804276290c0
Aug 26 16:11:36 localhost kernel: Call Trace:
Aug 26 16:11:36 localhost kernel:  [] dump_stack+0x54/0x74
Aug 26 16:11:36 localhost kernel:  []
warn_slowpath_common+0x7d/0xa0
Aug 26 16:11:36 localhost kernel:  []
warn_slowpath_fmt+0x4c/0x50
Aug 26 16:11:36 localhost kernel:  []
check_for_stack+0xa0/0x100
Aug 26 16:11:36 localhost kernel:  []
debug_dma_map_page+0x100/0x140
Aug 26 16:11:36 localhost kernel:  []
usb_hcd_map_urb_for_dma+0x5d0/0x700
Aug 26 16:11:36 localhost kernel:  []
usb_hcd_submit_urb+0x295/0x8f0
Aug 26 16:11:36 localhost kernel:  [] ?
lockdep_init_map+0xac/0x4a0
Aug 26 16:11:36 localhost kernel:  []
usb_submit_urb+0x155/0x3d0
Aug 26 16:11:36 localhost kernel:  []
usb_start_wait_urb+0x74/0x190
Aug 26 16:11:36 localhost kernel:  [] ?
kmem_cache_alloc_trace+0x111/0x350
Aug 26 16:11:36 localhost kernel:  []
usb_control_msg+0xc5/0x110
Aug 26 16:11:36 localhost kernel:  []
usbhid_get_raw_report+0x94/0xb0
Aug 26 16:11:36 localhost kernel:  []
hidinput_get_battery_property+0x6d/0x100
Aug 26 16:11:36 localhost kernel:  []
power_supply_show_property+0x56/0x1f0
Aug 26 16:11:36 localhost kernel:  []
power_supply_uevent+0xd2/0x2a0
Aug 26 16:11:36 localhost kernel:  [] dev_uevent+0xb9/0x2b0
Aug 26 16:11:36 localhost kernel:  []
kobject_uevent_env+0x290/0x600
Aug 26 16:11:36 localhost kernel:  [] ?
trace_hardirqs_on_caller+0xfd/0x1c0
Aug 26 16:11:36 localhost kernel:  [] kobject_uevent+0xb/0x10
Aug 26 16:11:36 localhost kernel:  [] device_add+0x4c2/0x7a0
Aug 26 16:11:36 localhost kernel:  []
power_supply_register+0x118/0x250
Aug 26 16:11:36 localhost kernel:  []
hidinput_setup_battery+0x167/0x200
Aug 26 16:11:36 localhost kernel:  [] ?
device_private_init+0x4a/0x80
Aug 26 16:11:36 localhost kernel:  []
hidinput_connect+0xa63/0x2960
Aug 26 16:11:36 localhost kernel:  [] ?
trace_hardirqs_on_caller+0xfd/0x1c0
Aug 26 16:11:36 localhost kernel:  [] hid_connect+0x2fd/0x380
Aug 26 16:11:36 localhost kernel:  [] ?
usbhid_set_leds+0x92/0xc0
Aug 26 16:11:36 localhost kernel:  [] ?
usbhid_start+0x545/0x600
Aug 26 16:11:36 localhost kernel:  []
hid_device_probe+0x144/0x160
Aug 26 16:11:36 localhost kernel:  []
driver_probe_device+0x87/0x390
Aug 26 16:11:36 localhost kernel:  [] ?
driver_probe_device+0x390/0x390
Aug 26 16:11:36 localhost kernel:  []
__device_attach+0x3b/0x40
Aug 26 16:11:36 localhost kernel:  []
bus_for_each_drv+0x63/0xa0
Aug 26 16:11:36 localhost kernel:  [] device_attach+0x90/0xb0
Aug 26 16:11:36 localhost kernel:  []
bus_probe_device+0xa8/0xd0
Aug 26 16:11:36 localhost kernel:  [] device_add+0x4ca/0x7a0
Aug 26 16:11:36 localhost kernel:  []
hid_add_device+0x174/0x380
Aug 26 16:11:36 localhost kernel:  [] usbhid_probe+0x3b0/0x4e0
Aug 26 16:11:36 localhost kernel:  []
usb_probe_interface+0x1cf/0x300
Aug 26 16:11:36 localhost kernel:  []
driver_probe_device+0x87/0x390
Aug 26 16:11:36 localhost kernel:  [] ?
driver_probe_device+0x390/0x390
Aug 26 16:11:36 localhost kernel:  []
__device_attach+0x3b/0x40
Aug 26 16:11:36 localhost kernel:  []
bus_for_each_drv+0x63/0xa0
Aug 26 16:11:36 localhost kernel:  [] device_attach+0x90/0xb0
Aug 26 16:11:36 localhost kernel:  []
bus_probe_device+0xa8/0xd0
Aug 26 16:11:36 localhost kernel:  [] device_add+0x4ca/0x7a0
Aug 26 16:11:36 localhost kernel:  []
usb_set_configuration+0x52b/0x840
Aug 26 16:11:36 localhost kernel:  [] generic_probe+0x2e/0xa0
Aug 26 16:11:36 localhost kernel:  []
usb_probe_device+0x32/0x80
Aug 26 16:11:36 localhost kernel:  []
driver_probe_device+0x87/0x390
Aug 26 16:11:36 localhost kernel:  [] ?
driver_probe_device+0x390/0x390
Aug 26 16:11:36 localhost kernel:  []
__device_attach+0x3b/0x40
Aug 26 16:11:36 localhost kernel:  []
bus_for_each_drv+0x63/0xa0
Aug 26 16:11:36 localhost kernel:  [] device_attach+0x90/0xb0
Aug 26 16:11:36 localhost kernel:  []
bus_probe_device+0xa8/0xd0
Aug 26 16:11:36 localhost kernel:  [] device_add+0x4ca/0x7a0
Aug 26 16:11:36 localhost kernel:  []
usb_new_device+0x220

Re: kernel Oops: 0003 on usbhid_submit_report

[Jiri Kosina]

On Mon, 26 Aug 2013, Andreas Lillebø Holm wrote:

> You are my hero Jiri :-) These two patches fixes the issues I was seeing 
> and I can no longer reproduce them.

Thanks a lot for confirmation.

This has been a very long-standing bug, but for some reasons I have 
started to see devices actually triggering it only now.

My plan is to push it to Linus in the upcoming merge window, and once it 
proves to be stable, I'll do a -stable backport.

Thanks again,

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

[PATCH v2 0/3] Add Generic USB VBUS/ID detection via GPIO using extcon

[George Cherian]

Hi,

These patches add generic support for USB VBUS/ID pin detection using extcon 
framework. 
The USB ID pin on DRA7xx is connected via the gpio expander pcf8575. 
The interrupt line of the same is connected to the gpio 11 of bank 6. 
The following driver relies on  the  gpio interrupt to notify the actual 
ID pin values by which the dwc3 driver determines the HOST/Peripheral roles.


These patches are on top of following merges.
v3.11-rc3 dra7 baseport tree [1] , with balbi/next ,control-usb multi instance 
support [2],
chanwoo/extcon-next, roger's patches for USB host adaptation[3],Laurent 
Pinchart's patch to 
Enable pcf857x GPIO expander for Device Tree[4] and pcf857x cleanup patch [5].

Patches are available at 
extcon_gpio_usbvid
in git tree
git://git.ti.com/~georgecherian/ti-linux-kernel/georgec-connectivity-linux-feature-tree.git
 

[1] - dra7 base tree
https://github.com/lokeshvutla/linux/tree/dra7-3.11-rc3-base
[2] - multiple control-usb instances
https://github.com/rogerq/linux/tree/usb-control-module
[3] - [PATCH 0/4] ARM: DRA7-evm: USB host adaptation
https://lkml.org/lkml/2013/8/1/335
[4] - [PATCH v5] gpio: pcf857x: Add OF support 
https://lkml.org/lkml/2013/8/27/70
[5] - [PATCH] gpio: pcf857x: cleanup irq_demux_work and use threaded irq
https://lkml.org/lkml/2013/8/27/207

George Cherian (3):
  extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO
  drivers: Makefile: Extcon is a framework so bump it up
  ARM: dts: dra7-evm: Add extcon nodes for USB ID pin detection

 .../bindings/extcon/extcon-gpio-usbvid.txt |  20 +++
 arch/arm/boot/dts/dra7-evm.dts |  52 +-
 drivers/Makefile   |   2 +-
 drivers/extcon/Kconfig |   7 +-
 drivers/extcon/Makefile|   2 +-
 drivers/extcon/extcon-gpio-usbvid.c| 185 +
 6 files changed, 226 insertions(+), 42 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt

-- 
1.8.1.4

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

[PATCH v2 3/3] ARM: dts: dra7-evm: Add extcon nodes for USB ID pin detection

[George Cherian]

Add
-extcon nodes for USB ID pin detection.
-i2c nodes.
-pcf nodes to which USB ID pin is connected.

Signed-off-by: George Cherian 
---
 arch/arm/boot/dts/dra7-evm.dts | 52 +-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index acd3c09..9ee97c0 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -17,6 +17,17 @@
device_type = "memory";
reg = <0x8000 0x6000>; /* 1536 MB */
};
+
+   extcon1: gpio_usbvid_extcon1 {
+   compatible = "ti,gpio-usb-id";
+   gpios = <&pcf_21 1 0>;
+   };
+
+   extcon2: gpio_usbvid_extcon2 {
+   compatible = "ti,gpio-usb-id";
+   gpios = <&pcf_21 2 0>;
+   };
+
 };
 
 &dra7_pmx_core {
@@ -33,10 +44,49 @@
 };
 };
 
+&i2c1 {
+   clock-frequency = <40>;
+
+   pcf_20: pcf8575@20 {
+   compatible = "ti,pcf8575";
+   reg = <0x20>;
+   n_latch = <0x4000>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&gpio6>;
+   interrupts = <11 2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   pcf_21: pcf8575@21 {
+   compatible = "ti,pcf8575";
+   reg = <0x21>;
+   n_latch = <0x1408>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&pcf_20>;
+   interrupts = <14 2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+};
+
 &dwc3_1 {
-   dr_mode = "otg";
+   dr_mode = "host";
+/* extcon = <&extcon1>;*/
 };
 
 &dwc3_2 {
dr_mode = "host";
+   /*extcon = <&extcon2>;*/
+};
+
+&usb1 {
+   extcon = <&extcon1>;
+};
+
+&usb2 {
+   extcon = <&extcon2>;
 };
-- 
1.8.1.4

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

[PATCH v2 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO

[George Cherian]

Add a generic USB VBUS/ID detection EXTCON driver. This driver expects
the ID/VBUS pin are connected via GPIOs. This driver is tested on
DRA7x board were the ID pin is routed via GPIOs. The driver supports
both VBUS and ID pin configuration and ID pin only configuration.

Signed-off-by: George Cherian 
---
 .../bindings/extcon/extcon-gpio-usbvid.txt |  20 +++
 drivers/extcon/Kconfig |   7 +-
 drivers/extcon/Makefile|   2 +-
 drivers/extcon/extcon-gpio-usbvid.c| 185 +
 4 files changed, 174 insertions(+), 40 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt

diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt 
b/Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt
new file mode 100644
index 000..eea0741
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt
@@ -0,0 +1,20 @@
+EXTCON FOR USB VIA GPIO
+
+Required Properties:
+ - compatible : Should be "ti,gpio-usb-vid" for USB VBUS-ID detector
+   using gpios or "ti,gpio-usb-id" for USB ID pin detector
+ - gpios : phandle and args ID pin gpio and VBUS gpio.
+  The first gpio used  for ID pin detection
+  and the second used for VBUS detection.
+  ID pin gpio is mandatory and VBUS is optional
+  depending on implementation.
+
+Please refer to ../gpio/gpio.txt for details of the common GPIO bindings
+
+Example:
+
+   gpio_usbvid_extcon1 {
+   compatible = "ti,gpio-usb-vid";
+   gpios = <&gpio1 1 0>,
+   <&gpio2 2 0>;
+   };
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index da21c5c..8097398 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -64,11 +64,10 @@ config EXTCON_PALMAS
  Say Y here to enable support for USB peripheral and USB host
  detection by palmas usb.
 
-config EXTCON_GPIO_USB_VID
-   tristate "USB VBUS and ID detection over GPIO EXTCON support"
+config EXTCON_GPIO_USBVID
+   tristate "Generic USB VBUS/ID detection using GPIO EXTCON support"
help
- Say Y here to enable support for USB peripheral and USB host
- detection by pcf8575 using DRA7XX extcon.
+ Say Y here to enable support for USB VBUS/ID deetction by GPIO.
 
 
 endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index cbb0932..0451f698 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -10,4 +10,4 @@ obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
 obj-$(CONFIG_EXTCON_MAX8997)   += extcon-max8997.o
 obj-$(CONFIG_EXTCON_ARIZONA)   += extcon-arizona.o
 obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
-obj-$(CONFIG_EXTCON_GPIO_USB_VID)  += extcon-gpio-usb-vid.o
+obj-$(CONFIG_EXTCON_GPIO_USBVID)   += extcon-gpio-usbvid.o
diff --git a/drivers/extcon/extcon-gpio-usbvid.c 
b/drivers/extcon/extcon-gpio-usbvid.c
index 5a85c99..e9bc2a97 100644
--- a/drivers/extcon/extcon-gpio-usbvid.c
+++ b/drivers/extcon/extcon-gpio-usbvid.c
@@ -1,5 +1,5 @@
 /*
- * DRA7XX USB ID pin detection driver
+ * Generic  USB VBUS-ID pin detection driver
  *
  * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
  * This program is free software; you can redistribute it and/or modify
@@ -38,9 +38,11 @@ struct gpio_usbvid {
 
/*GPIO pin */
int id_gpio;
+   int vbus_gpio;
 
-   int id_prev;
-   int id_current;
+   int id_irq;
+   int vbus_irq;
+   int type;
 };
 
 static const char *dra7xx_extcon_cable[] = {
@@ -51,36 +53,141 @@ static const char *dra7xx_extcon_cable[] = {
 
 static const int mutually_exclusive[] = {0x3, 0x0};
 
+/* Two types of support are provided.
+ * Systems which has
+ * 1) VBUS and ID pin connected via GPIO
+ * 2)  only ID pin connected via GPIO
+ *  For Case 1 both the gpios should be provided via DT
+ *  Always the first GPIO in dt is considered ID pin GPIO
+ */
+
+enum {
+   UNKNOWN = 0,
+   ID_DETECT,
+   VBUS_ID_DETECT,
+};
+
+#define ID_GND 0
+#define ID_FLOAT   1
+#define VBUS_OFF   0
+#define VBUS_ON1
+
+
 static irqreturn_t id_irq_handler(int irq, void *data)
 {
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *) data;
+   int id_current;
 
-   gpio_usbvid->id_current = gpio_get_value_cansleep(gpio_usbvid->id_gpio);
-   printk ("***id_irq_handler\n");
-   if (gpio_usbvid->id_current == gpio_usbvid->id_prev) {
-   return IRQ_HANDLED;
-   } else if (gpio_usbvid->id_current == 0) {
-   extcon_set_cable_state(&gpio_usbvid->edev, "USB", false);
+   id_current = gpio_get_value_cansleep(gpio_usbvid->id_gpio);
+   if (id_current == ID_GND) {
+   if (gpio_usbvid->type == ID_DETECT)
+   extcon_set_cable_state(&gpio_usbvid->edev,
+ 

[PATCH v2 2/3] drivers: Makefile: Extcon is a framework so bump it up

[George Cherian]

Bump up the order, since extcon is a framework and needed by
other drivers. With the previous order it failed to detect
extcon device in DWC3 when both were compiled built-in.

Signed-off-by: George Cherian 
---
 drivers/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index ab93de8..4573b8d 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -49,6 +49,7 @@ obj-y += char/
 obj-y  += gpu/
 
 obj-$(CONFIG_CONNECTOR)+= connector/
+obj-$(CONFIG_EXTCON)   += extcon/
 
 # i810fb and intelfb depend on char/agp/
 obj-$(CONFIG_FB_I810)   += video/i810/
@@ -145,7 +146,6 @@ obj-$(CONFIG_VIRT_DRIVERS)  += virt/
 obj-$(CONFIG_HYPERV)   += hv/
 
 obj-$(CONFIG_PM_DEVFREQ)   += devfreq/
-obj-$(CONFIG_EXTCON)   += extcon/
 obj-$(CONFIG_MEMORY)   += memory/
 obj-$(CONFIG_IIO)  += iio/
 obj-$(CONFIG_VME_BUS)  += vme/
-- 
1.8.1.4

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

Re: [PATCH 1/2] usb:gadget:dummy_hcd : Avoid infinite loop

[Alan Stern]

On Wed, 28 Aug 2013, Philippe De Swert wrote:

> When an error occurs adding a platform device there is a risk of an infinite 
> loop.
> If more than one platform device was added i will remain >= than 0. The 
> intention seems
> to clean up all the different already added platform devices before the 
> failure occurs,
> so fixed the code to actually do so. We decrement first because the adding at 
> the current
> index of i is the one that failed.
> 
> Found with coverity : CID 751073
> 
> Signed-off-by: Philippe De Swert 
> ---
>  drivers/usb/gadget/dummy_hcd.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
> index c588e8e..5c506fb 100644
> --- a/drivers/usb/gadget/dummy_hcd.c
> +++ b/drivers/usb/gadget/dummy_hcd.c
> @@ -2705,9 +2705,10 @@ static int __init init(void)
>   for (i = 0; i < mod_data.num; i++) {
>   retval = platform_device_add(the_udc_pdev[i]);
>   if (retval < 0) {
> - i--;
> - while (i >= 0)
> + while (i >= 0) {
> + i--;
>   platform_device_del(the_udc_pdev[i]);
> + }
>   goto err_add_udc;
>   }
>   }

This is definitely a bug, but you should have fixed it the same way as
the code 21 lines earlier.  Or even better, change both of them to use
this pattern:

if (retval < 0) {
while (--i >= 0)
platform_device_del(the_udc_pdev[i]);
goto err_add_udc;
}

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: 3.4.4: disabling irq

[Udo van den Heuvel]

On 2013-08-27 19:43, Alan Stern wrote:
>>>   rmmod ohci-pci
>>>   modprobe dummy-irq irq=18
>>>
>>> and see if the IRQ line gets disabled after that.
>>
>> Can I actually use that irq/ports that way? (as with no usage the
>> problem does not occur)
> 
> No, if you unload the ohci-hcd driver then the webcam won't be used.  
> Are you certain that merely stopping the daemon program will prevent 
> the problem?

Quite certain but retesting can confirm that.

>> No ohci_pci, is that a problem?
> 
> Sorry, for 3.10 it should be ohci_hcd.  In 3.11 it changed to ohci_pci.

3.10.9 is the latest here.

> Have you tried getting a USB-2 hub and plugging the webcam into it?  
> That will make a good test: You'll be able to use the webcam without 
> it affecting the ohci-hcd driver.

Not yet but I'll have hubs to test with soon.

> As a second test, you can try plugging everything _except_ the webcam 
> into the hub.

To see if the webcam itself is a factor. I see.

>> FWIW: on these boards (same type, BIOS, etc) I also see the issue
>> described at http://marc.info/?l=linux-kernel&m=137749729105329&w=2.
>> Any correlation?
> 
> Not that I can see.

This afternoon I found a 3.8.10 kernel with the disabled irq 18 and some
^@^@^@ characters on teh console.
After I did:

service motion stop
rmmod pwc
echo :00:13.0 >/sys/bus/pci/drivers/ohci_hcd/unbind
echo :00:13.0 >/sys/bus/pci/drivers/ohci_hcd/bind
modprobe pwc
service motion start

the ^@^@^@ appeared to stop.
I'll try to watch /proc/interrupts to see if the ^@^@ correlate with
i8042 interrupts.

Kind regards,
Udo
--
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:gadget:dummy_hcd : Detect port and link state correctly to avoid unreachable code

[Alan Stern]

On Wed, 28 Aug 2013, Philippe De Swert wrote:

> Since USB_SS_PORT_LS_U0 is 0x the & operation with the port state would
> always be 0. Thus the if would never be true. The code tries to check if the
> port is enabled  and link is active (U0 state). This means the port_status
> should be 0x0001, so the right check is an | with USB_SS_PORT_LS_U0.
> 
> Found with coverity: CID 744367, CID 145679
> 
> Signed-off-by: Philippe De Swert 
> ---
>  drivers/usb/gadget/dummy_hcd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
> index 5c506fb..22cd01c 100644
> --- a/drivers/usb/gadget/dummy_hcd.c
> +++ b/drivers/usb/gadget/dummy_hcd.c
> @@ -313,7 +313,7 @@ static void set_link_state_by_speed(struct dummy_hcd 
> *dum_hcd)
>   (USB_PORT_STAT_C_CONNECTION << 16);
>   if ((dum_hcd->port_status &
>USB_PORT_STAT_ENABLE) == 1 &&
> - (dum_hcd->port_status &
> + (dum_hcd->port_status |
>USB_SS_PORT_LS_U0) == 1 &&
>   dum_hcd->rh_state != DUMMY_RH_SUSPENDED)
>   dum_hcd->active = 1;

It's odd that Coverity found this bug but didn't find the bug 
immediately above: Since USB_PORT_STAT_ENABLE is 0x0002, the first 
comparison in this "if" statement can never succeed.

The test against USB_PORT_STAT_ENABLE should be != 0, not == 1.

The test against USB_SS_PORT_LS_U0 is dead code, because the driver
currently does not support USB-3 suspend.  Aside from that, the
proposed fix is wrong.  The correct test is

(dum_hcd->port_status & USB_SS_PORT_LINK_STATE) ==
USB_SS_PORT_LS_U0

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: Re:[RFT & RFC] USB: Fix USB device disconnects on resume.

[Alan Stern]

On Wed, 28 Aug 2013, Dmitri Zolotov wrote:

> ~/linux-3.9.11$ grep -r "TRSMRCY"
> drivers/usb/core/hub.c:/* TRSMRCY = 20 msec */

Where did that come from?  In the 3.9.11 kernel this says 10, not 20.

> drivers/usb/core/hub.c:/* TRSMRCY = 10 msec */
> drivers/usb/core/hcd.c: * unsuspended.  If they are then a TRSMRCY 
> delay is needed
> drivers/usb/core/hcd.c:usleep_range(1, 11000);/* 
> TRSMRCY */
> drivers/usb/host/isp1362-hcd.c:/* TRSMRCY */
> drivers/usb/host/ohci-hub.c:/* TRSMRCY */
> Do these files contain the same bug?

As far as I can see, none of them contain any bugs related to TRSMRCY.

Alan Stern

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

Re: [PATCH v2 3/3] ARM: dts: dra7-evm: Add extcon nodes for USB ID pin detection

[Sergei Shtylyov]

Hello.

On 08/28/2013 05:59 PM, George Cherian wrote:


Add
-extcon nodes for USB ID pin detection.
-i2c nodes.
-pcf nodes to which USB ID pin is connected.



Signed-off-by: George Cherian 
---
  arch/arm/boot/dts/dra7-evm.dts | 52 +-
  1 file changed, 51 insertions(+), 1 deletion(-)



diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index acd3c09..9ee97c0 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -17,6 +17,17 @@
device_type = "memory";
reg = <0x8000 0x6000>; /* 1536 MB */
};
+
+   extcon1: gpio_usbvid_extcon1 {
+   compatible = "ti,gpio-usb-id";
+   gpios = <&pcf_21 1 0>;
+   };
+
+   extcon2: gpio_usbvid_extcon2 {
+   compatible = "ti,gpio-usb-id";
+   gpios = <&pcf_21 2 0>;
+   };
+
  };

  &dra7_pmx_core {
@@ -33,10 +44,49 @@
  };
  };

+&i2c1 {
+   clock-frequency = <40>;
+
+   pcf_20: pcf8575@20 {


   Acorrding to the ePAPR spec [1], "the name of a node should be somewhat 
generic, reflecting the function of the device and not its precise 
programming model. If appropriate, the name should be one of the following 
choices:


[...]
- gpio
[...]"


+   compatible = "ti,pcf8575";
+   reg = <0x20>;
+   n_latch = <0x4000>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&gpio6>;
+   interrupts = <11 2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   pcf_21: pcf8575@21 {


   Same comment here.


+   compatible = "ti,pcf8575";
+   reg = <0x21>;
+   n_latch = <0x1408>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&pcf_20>;
+   interrupts = <14 2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+};
+


[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei

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

Re: ehci-pci 0000:00:1a.0: DMA-API: device driver maps memory fromstack

[Alan Stern]

On Wed, 28 Aug 2013, Richard Ryniker wrote:

> https://bugzilla.redhat.com/show_bug.cgi?id=1001806
> 
> Aug 26 16:11:36 localhost kernel: [ cut here ]
> Aug 26 16:11:36 localhost kernel: WARNING: CPU: 0 PID: 54 at
> lib/dma-debug.c:950 check_for_stack+0xa0/0x100()
> Aug 26 16:11:36 localhost kernel: ehci-pci :00:1a.0: DMA-API: device
> driver maps memory fromstack [addr=880427629376]
> Aug 26 16:11:36 localhost kernel: Modules linked in: floppy(+) scsi_dh_rdac
> scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua iscsi_tcp libiscsi_tcp libiscsi
> scsi_transport_iscsi squashfs cramfs edd dm_multipath
> Aug 26 16:11:36 localhost kernel: CPU: 0 PID: 54 Comm: khubd Not tainted
> 3.11.0-0.rc6.git4.1.fc20.x86_64 #1
> Aug 26 16:11:36 localhost kernel: Hardware name: LENOVO 7745/7745, BIOS
> DUKT31AUS 05/23/2011
> Aug 26 16:11:36 localhost kernel:  0009 880427629028
> 81723846 880427629070
> Aug 26 16:11:36 localhost kernel:  880427629060 8107464d
> 880427f9c5b8 88042752bae0
> Aug 26 16:11:36 localhost kernel:  880427629376 880427f9c5b8
> 81c27440 8804276290c0
> Aug 26 16:11:36 localhost kernel: Call Trace:
> Aug 26 16:11:36 localhost kernel:  [] dump_stack+0x54/0x74
> Aug 26 16:11:36 localhost kernel:  []
> warn_slowpath_common+0x7d/0xa0
> Aug 26 16:11:36 localhost kernel:  []
> warn_slowpath_fmt+0x4c/0x50
> Aug 26 16:11:36 localhost kernel:  []
> check_for_stack+0xa0/0x100
> Aug 26 16:11:36 localhost kernel:  []
> debug_dma_map_page+0x100/0x140
> Aug 26 16:11:36 localhost kernel:  []
> usb_hcd_map_urb_for_dma+0x5d0/0x700
> Aug 26 16:11:36 localhost kernel:  []
> usb_hcd_submit_urb+0x295/0x8f0
> Aug 26 16:11:36 localhost kernel:  [] ?
> lockdep_init_map+0xac/0x4a0
> Aug 26 16:11:36 localhost kernel:  []
> usb_submit_urb+0x155/0x3d0
> Aug 26 16:11:36 localhost kernel:  []
> usb_start_wait_urb+0x74/0x190
> Aug 26 16:11:36 localhost kernel:  [] ?
> kmem_cache_alloc_trace+0x111/0x350
> Aug 26 16:11:36 localhost kernel:  []
> usb_control_msg+0xc5/0x110
> Aug 26 16:11:36 localhost kernel:  []
> usbhid_get_raw_report+0x94/0xb0
> Aug 26 16:11:36 localhost kernel:  []
> hidinput_get_battery_property+0x6d/0x100

This is where the bug lies.  hidinput_get_battery_property() needs to 
allocate a buffer with kmalloc() instead of using on that's on the 
stack.

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: ehci-pci 0000:00:1a.0: DMA-API: device driver maps memory fromstack

[Jiri Kosina]

On Wed, 28 Aug 2013, Alan Stern wrote:

> > Aug 26 16:11:36 localhost kernel: [ cut here ]
> > Aug 26 16:11:36 localhost kernel: WARNING: CPU: 0 PID: 54 at
> > lib/dma-debug.c:950 check_for_stack+0xa0/0x100()
> > Aug 26 16:11:36 localhost kernel: ehci-pci :00:1a.0: DMA-API: device
> > driver maps memory fromstack [addr=880427629376]
> > Aug 26 16:11:36 localhost kernel: Modules linked in: floppy(+) scsi_dh_rdac
> > scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua iscsi_tcp libiscsi_tcp libiscsi
> > scsi_transport_iscsi squashfs cramfs edd dm_multipath
> > Aug 26 16:11:36 localhost kernel: CPU: 0 PID: 54 Comm: khubd Not tainted
> > 3.11.0-0.rc6.git4.1.fc20.x86_64 #1
> > Aug 26 16:11:36 localhost kernel: Hardware name: LENOVO 7745/7745, BIOS
> > DUKT31AUS 05/23/2011
> > Aug 26 16:11:36 localhost kernel:  0009 880427629028
> > 81723846 880427629070
> > Aug 26 16:11:36 localhost kernel:  880427629060 8107464d
> > 880427f9c5b8 88042752bae0
> > Aug 26 16:11:36 localhost kernel:  880427629376 880427f9c5b8
> > 81c27440 8804276290c0
> > Aug 26 16:11:36 localhost kernel: Call Trace:
> > Aug 26 16:11:36 localhost kernel:  [] dump_stack+0x54/0x74
> > Aug 26 16:11:36 localhost kernel:  []
> > warn_slowpath_common+0x7d/0xa0
> > Aug 26 16:11:36 localhost kernel:  []
> > warn_slowpath_fmt+0x4c/0x50
> > Aug 26 16:11:36 localhost kernel:  []
> > check_for_stack+0xa0/0x100
> > Aug 26 16:11:36 localhost kernel:  []
> > debug_dma_map_page+0x100/0x140
> > Aug 26 16:11:36 localhost kernel:  []
> > usb_hcd_map_urb_for_dma+0x5d0/0x700
> > Aug 26 16:11:36 localhost kernel:  []
> > usb_hcd_submit_urb+0x295/0x8f0
> > Aug 26 16:11:36 localhost kernel:  [] ?
> > lockdep_init_map+0xac/0x4a0
> > Aug 26 16:11:36 localhost kernel:  []
> > usb_submit_urb+0x155/0x3d0
> > Aug 26 16:11:36 localhost kernel:  []
> > usb_start_wait_urb+0x74/0x190
> > Aug 26 16:11:36 localhost kernel:  [] ?
> > kmem_cache_alloc_trace+0x111/0x350
> > Aug 26 16:11:36 localhost kernel:  []
> > usb_control_msg+0xc5/0x110
> > Aug 26 16:11:36 localhost kernel:  []
> > usbhid_get_raw_report+0x94/0xb0
> > Aug 26 16:11:36 localhost kernel:  []
> > hidinput_get_battery_property+0x6d/0x100
> 
> This is where the bug lies.  hidinput_get_battery_property() needs to 
> allocate a buffer with kmalloc() instead of using on that's on the 
> stack.

Indeed. Could you please test with the patch below, so that I could add 
your Tested-by?

Thanks.



From: Jiri Kosina 
Subject: [PATCH] HID: battery: don't do DMA from stack

Instead of using data from stack for DMA in hidinput_get_battery_property(),
allocate the buffer dynamically.

Reported-by: Richard Ryniker 
Reported-by: Alan Stern 
Signed-off-by: Jiri Kosina 
---
 drivers/hid/hid-input.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 7480799..3fc4034 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -340,7 +340,7 @@ static int hidinput_get_battery_property(struct 
power_supply *psy,
 {
struct hid_device *dev = container_of(psy, struct hid_device, battery);
int ret = 0;
-   __u8 buf[2] = {};
+   __u8 *buf;
 
switch (prop) {
case POWER_SUPPLY_PROP_PRESENT:
@@ -349,12 +349,19 @@ static int hidinput_get_battery_property(struct 
power_supply *psy,
break;
 
case POWER_SUPPLY_PROP_CAPACITY:
+
+   buf = kmalloc(2 * sizeof(__u8), GFP_KERNEL);
+   if (!buf) {
+   ret = -ENOMEM;
+   break;
+   }
ret = dev->hid_get_raw_report(dev, dev->battery_report_id,
- buf, sizeof(buf),
+ buf, 2,
  dev->battery_report_type);
 
if (ret != 2) {
ret = -ENODATA;
+   kfree(buf);
break;
}
ret = 0;
@@ -364,6 +371,7 @@ static int hidinput_get_battery_property(struct 
power_supply *psy,
buf[1] <= dev->battery_max)
val->intval = (100 * (buf[1] - dev->battery_min)) /
(dev->battery_max - dev->battery_min);
+   kfree(buf);
break;
 
case POWER_SUPPLY_PROP_MODEL_NAME:

-- 
Jiri Kosina
SUSE Labs
--
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 v3] xHCI: Fixing xhci_readl definition and function call

[Kumar Gaurav]

On Wednesday 28 August 2013 12:43 PM, Dan Carpenter wrote:

On Mon, Aug 26, 2013 at 07:38:57AM +0530, Kumar Gaurav wrote:

This patch redefine function xhci_readl.xhci_readl function doesn't use 
xhci_hcd argument.
Hence there is no need of keeping it in the function arguments.

Redefining this function breaks other functions which calls this function.
This phatch also correct those calls in xhci driver.

Signed-off-by: Kumar Gaurav 
---

Could you put a list of changes since v2 here?:

v3:  blah blah changelog mostly.

Also this doesn't apply for me against linux-next.

regards,
dan carpenter

There's no change from v2. I was sending the same patch again because 
the last one was lacking good description and i was told (or as i 
understood) that if I'm sending the same patch or patch for the same 
purpose as previous then i should increment version so i did.


I had developed this patch against linux-git, haven't tested that on 
linux-next as i haven't cloned  linux-next yet.


I've started cloning linux-next and as it's not applying on linux-next, 
I'll try it on linux-next (once i cloned it)  and will send again.


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

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 1:19 PM, Sedat Dilek  wrote:
> On Wed, Aug 28, 2013 at 12:53 PM, Dmitry Kasatkin
>  wrote:
>> On 28/08/13 13:46, Sedat Dilek wrote:
>>> On Wed, Aug 28, 2013 at 12:43 PM, Dmitry Kasatkin
>>>  wrote:
>>>> On 28/08/13 13:38, Sedat Dilek wrote:
>>>>> On Wed, Aug 28, 2013 at 12:29 PM, Sedat Dilek  
>>>>> wrote:
>>>>>> On Wed, Aug 28, 2013 at 11:56 AM, Sedat Dilek  
>>>>>> wrote:
>>>>>>> On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  
>>>>>>> wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Changes since 20130827:
>>>>>>>>
>>>>>>>> The f2fs tree lost its build failure.
>>>>>>>>
>>>>>>>> The md tree gained a conflict against the arm tree.
>>>>>>>>
>>>>>>>> The libata tree lost its build failure.
>>>>>>>>
>>>>>>>> The spi tree lost its build failure.
>>>>>>>>
>>>>>>>> The arm-soc tree gained conflicts against the usb tree.
>>>>>>>>
>>>>>>>> The dma-mapping tree gained a conflict against the driver-core tree.
>>>>>>>>
>>>>>>>> The akpm-current tree gained a conflict against the net tree.
>>>>>>>>
>>>>>>>> 
>>>>>>>>
>>>>>>>> My build here breaks like this:
>>>>>>>>
>>>>>>>>   CC  drivers/usb/host/xhci-ring.o
>>>>>>>>   CC  drivers/video/console/softcursor.o
>>>>>>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
>>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>>>>>>> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
>>>>>>>> [-Werror=implicit-function-declaration]
>>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
>>>>>>>> (first use in this function)
>>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
>>>>>>>> is reported only once for each function it appears in
>>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>>>>>>> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
>>>>>>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
>>>>>>>> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
>>>>>>>> (first use in this function)
>>>>>>>> cc1: some warnings being treated as errors
>>>>>>>> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
>>>>>>>> make[4]: *** [drivers/usb/host] Error 2
>>>>>>>>
>>>>>>>> My kernel-config is attached.
>>>>>>>>
>>>>>>> Looks like  or  is missing.
>>>>>>>
>>>>>>> $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr 
>>>>>>> linux/include/
>>>>>>> linux/include/linux/device.h:1118:
>>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>>> linux/include/linux/device.h:1121:
>>>>>>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>>>>>> linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
>>>>>>> _ddebug *descriptor, const char *fmt, ...);
>>>>>>> linux/include/linux/dynamic_debug.h:63:#define
>>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
>>>>>>> linux/include/linux/dynamic_debug.h:76:
>>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>>> linux/include/linux/dynamic_debug.h:78:
>>>>>>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>>>>>> linux/include/linux/dynamic_debug.h:84:
>>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>>> linux/include/linux/dynamic_debug

[PATCH 2nd RESEND] clk: tegra30: Don't wait for PLL_U lock bit

[Tuomas Tynkkynen]

The lock bit on PLL_U does not seem to be working correctly and
sometimes never gets set when waiting for the PLL to come up.
Remove the TEGRA_PLL_USE_LOCK flag to use a constant delay.

Signed-off-by: Tuomas Tynkkynen 
Tested-by: Stephen Warren 
Acked-by: Stephen Warren 

---
 drivers/clk/tegra/clk-tegra30.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index e2c6ca0..9103fc8 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -971,7 +971,7 @@ static void __init tegra30_pll_init(void)
/* PLLU */
clk = tegra_clk_register_pll("pll_u", "pll_ref", clk_base, pmc_base, 0,
0, &pll_u_params, TEGRA_PLLU | TEGRA_PLL_HAS_CPCON |
-   TEGRA_PLL_SET_LFCON | TEGRA_PLL_USE_LOCK,
+   TEGRA_PLL_SET_LFCON,
pll_u_freq_table,
NULL);
clk_register_clkdev(clk, "pll_u", NULL);
-- 
1.8.1.5

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

[PATCH 2nd RESEND] Clock changes for Tegra30 USB Host support

[Tuomas Tynkkynen]

Hi all,

This patch is required for USB support on Tegra30 due to a hardware
quirk in the PLL_U oscillator which clocks the USB complex.

The other USB patches for Tegra30 and Tegra114 are already on their way
to 3.12, so it would be nice to have this one as well in 3.12.

Diff from previous: Added swarren's Tested-by & Acked-by.

Tuomas Tynkkynen (1):
  clk: tegra30: Don't wait for PLL_U lock bit

 drivers/clk/tegra/clk-tegra30.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.8.1.5

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

Re: [RFC v2] usb: Fix xHCI host issues on remote wakeup.

[Sarah Sharp]

On Tue, Aug 27, 2013 at 05:41:19PM -0700, Greg KH wrote:
> On Mon, Aug 26, 2013 at 06:59:22PM -0700, Sarah Sharp wrote:
> > I attempted to replicate this bug with Ubuntu 12.04, but could not.  I
> > used Ubuntu 12.04 on the same platform, with the same BIOS that the bug
> > was triggered on ChromeOS with.  I also changed the USB sysfs settings
> > as described above, but still could not reproduce the bug under Ubuntu.
> > It may be that ChromeOS userspace triggers this bug through additional
> > settings.
> 
> Did you test this on ChromeOS to determine that the patch fixes the bug?

Yes, it does fix the bug.

> > This patch should be backported to kernels as old as 2.6.37, that
> > contain the commit 561925318725a41189a69f36ebe99199b3fb84c4 "USB: xHCI:
> > port remote wakeup implementation".  It may be difficult to backport
> > this due to xhci->bus_state being unavailable in older kernels, and the
> > code to split xHCI roothubs into a USB 2.0 roothub and a USB 3.0 roothub
> > not going in until 2.6.39.
> 
> If only ChromeOS is affected, why backport it for any stable tree?

I don't understand this logic.

The xHCI driver is violating the xHCI spec by not waiting for the port
status change to indicate the port is actually in U0 (active state)
before telling the USB core it's safe to communicate with the port.
Which OS happens to trigger this bug is not important in my mind, since
it's still a bug in the driver.

ChromeOS can trigger this bug, whether it's running on the 3.8.11
kernel, or the 3.10.7 kernel.  Therefore I would think we would want
this fix in stable kernels, case some other distribution happened to hit
the combination of sysfs writes that causes ChromeOS to trigger this
bug.

Or are you arguing that we shouldn't backport this because it's just
triggered on one distribution?  Am I required to verify all bugs are
triggered on two distributions before they should be considered for
stable?

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

Re: [PATCH] usb: dwc3: core: clarify usb-phy array binding

[Mark Rutland]

On Tue, Aug 27, 2013 at 07:53:29PM +0100, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Aug 13, 2013 at 02:34:10PM +0100, Mark Rutland wrote:
> > On Mon, Aug 12, 2013 at 07:05:53PM +0100, Felipe Balbi wrote:
> > > On Fri, Aug 09, 2013 at 01:42:15PM -0500, Kumar Gala wrote:
> > > > 
> > > > On Aug 9, 2013, at 11:28 AM, Mark Rutland wrote:
> > > > 
> > > > > On Fri, Aug 09, 2013 at 04:40:32PM +0100, Kumar Gala wrote:
> > > > >> The binding spec wasn't clear that the order of the phandles in the
> > > > >> usb-phy array has meaning.  Clarify this point in the binding that
> > > > >> it should be .
> > > > >> 
> > > > >> Signed-off-by: Kumar Gala 
> > > > >> ---
> > > > >> Documentation/devicetree/bindings/usb/dwc3.txt | 4 +++-
> > > > >> 1 file changed, 3 insertions(+), 1 deletion(-)
> > > > >> 
> > > > >> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
> > > > >> b/Documentation/devicetree/bindings/usb/dwc3.txt
> > > > >> index 7a95c65..8a9770b 100644
> > > > >> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> > > > >> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> > > > >> @@ -6,7 +6,9 @@ Required properties:
> > > > >>  - compatible: must be "synopsys,dwc3"
> > > > >>  - reg : Address and length of the register set for the device
> > > > >>  - interrupts: Interrupts used by the dwc3 controller.
> > > > >> - - usb-phy : array of phandle for the PHY device
> > > > >> + - usb-phy : array of phandle for the PHY device.  The first element
> > > > >> +   in the array is expected to be a handle to the USB2/HS PHY and
> > > > >> +   the second element is expected to be a handle to the USB3/SS PHY
> > > > > 
> > > > > Just to check - it's not valid to have a USB3 phy without a USB2 phy?
> > > > 
> > > > Don't know, hopefully Felipe will chime in on that.
> > > 
> > > that'd be a really non-standard implementation. Per-spec, USB3 is
> > > *always* backwards compatible with USB2.
> > 
> > I'm slightly confused here. From a quick look at the driver, it expects
> > two separate phys to be present -- one handling only USB2, and one
> > handling USB3 (with USB2 backwards compatibility).
> > 
> > So it's not physically possible for someone to just wire up a single phy
> > to the device, either USB2-only or USB3?
> 
> of course it is :-) In fact, TI has done it. But it causes a whole bunch
> of other problems to support that sort of model. For one, in some
> systems, a clock generated by the USB3 PHY is backfed into the IP and if
> USB3 PHY isn't running, the dwc3 IP won't start.

That sounds like a mess. But unless I've misunderstood, that doesn't
sound like a general problem with having one phy, but rather an
integration issue on a specific system? Presumably in that case as long
as the phy was brought up before poking the rest of the IP, the unit
would function correctly.

> 
> I even wrote a patch making USB3 PHY optional, but didn't push it
> exactly because it broke some other systems and I can't guarantee users
> won't mess up their DTS/pdata.

Does that mean that their dts or pdata are wrong at the moment, but
they're spared because the driver bails out due to a missing phy? If
their pdata's wrong, that should be fixable relatively easily, but if
the dt is wrong then I'm not sure how we can support those systems
sensibly. That sounds like an ideal candidate for a dt quirks
mechanism...

> 
> > You can describe the USB2-only case in the dt by only listing the first
> > phy (though the driver won't support it as it expects both to be
> > present), but it's impossible to describe that you've wired up a single
> > phy that's USB3 capable.
> 
> you might be right there...

Would it be possible to have something like (an optional) usb-phy-names?
If not present, we assume the current situation, if present then we use
it to figure out which phys are present. Maybe I'm missing something
that makes that impossible?

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

Re: [PATCH v1] USB: EHCI: disable IAA_WATCHDOG and START_UNLINK_INTR if they needn't to be handled

[Alan Stern]

On Wed, 28 Aug 2013, Ming Lei wrote:

> > Think about it this way: Why did you write the "USB: EHCI: improve
> > interrupt qh unlink" patch in the first place?  Essentially the same
> > reason applies to uhci-hcd and ohci-hcd, and they will need similar
> > patches.
> 
> Right, but drivers which submit URBs from tasklet/workque/... scheduled
> from complete() may need these patches too, even without giveback URB
> in complete() change.

That's a totally separate issue.  This email thread is about changes to
ehci-hcd, not bugs in other drivers.

Drivers that submit isochronous URBs from tasklets/workqueues/whatever 
without URB_ISO_ASAP are broken and need to be fixed.

> You have said the same problem exists on these drivers already
> without giveback in tasklet patch, so for the problem and solution,
> there is no difference.

What do you mean?  We can't fix those other drivers by changing 
ehci-hcd.  It's their fault if they misuse the isochronous API.

> >> iso_stream_schedule() will figure out that the next slot(201) is behind
> >> the scheduling threshold(case of 'start < next'), then update the next
> >> slot as one new slot which is larger 206 if URB_ISO_ASAP, so looks
> >> the TDs(USB) can't be missed too.
> >>
> >> Without URB_ISO_ASAP, there might be problem since 201 won't
> >> be scanned next time in scan_isoc, so is it what your RFC3 is fixing?
> >
> > Yes, it is.  Now you understand my point.
> 
> Actually the problem only happened when underrun without
> URB_ISO_ASAP.

Yes.  That case has to be handled correctly.

> >> If I understand the above problem correctly, the same problem exists
> >> on drivers which submit URB in tasklet scheduled from complete() too
> >> before the moving, doesn't it?
> >
> > That's right.  Probably those drivers always use URB_ISO_ASAP, so the
> > problem doesn't arise.  If they don't use URB_ISO_ASAP ... well, then
> > they will get inconsistent results when an underrun occurs.
> 
> Exactly, that is why I wouldn't like to count the change only on the
> giveback in tasklet patch, :-)

Why not?  Problems in other drivers can't be fixed by making changes to
ehci-hcd.  This change is needed so that drivers which aren't buggy
(such as snd-usb-audio) will continue to work as they should.


> > Index: usb-3.11/include/linux/usb/hcd.h
> > ===
> > --- usb-3.11.orig/include/linux/usb/hcd.h
> > +++ usb-3.11/include/linux/usb/hcd.h
> > @@ -73,6 +73,7 @@ struct giveback_urb_bh {
> > spinlock_t lock;
> > struct list_head  head;
> > struct tasklet_struct bh;
> > +   struct usb_host_endpoint *giveback_ep;
> >  };
> >
> >  struct usb_hcd {
> > @@ -378,6 +379,12 @@ static inline int hcd_giveback_urb_in_bh
> > return hcd->driver->flags & HCD_BH;
> >  }
> >
> > +static inline bool hcd_periodic_giveback_in_progress(struct usb_hcd *hcd,
> > +   struct usb_host_endpoint *ep)
> 
> Suggest not mention periodic since it can be used generally to decide if
> one urb is schedule in its complete, then better to pass urb instead of ep.

There's no reason to call this routine for non-periodic endpoints.  
Also, this way I don't have to test whether to use high_prio_bh or
low_prio_bh.

There's no reason to pass an URB pointer.  We don't care whether the
URB being submitted is the same as the one that is completing.  All
that matters is whether a completion handler for some URB on this
endpoint is running.

> Also giveback have been completed, and it is complete in progress, :-)

Good point; I will change the name.

> > +{
> > +   return hcd->high_prio_bh.giveback_ep == ep;
> > +}
> > +
> >  extern int usb_hcd_link_urb_to_ep(struct usb_hcd *hcd, struct urb *urb);
> >  extern int usb_hcd_check_unlink_urb(struct usb_hcd *hcd, struct urb *urb,
> > int status);
> > Index: usb-3.11/drivers/usb/core/hcd.c
> > ===
> > --- usb-3.11.orig/drivers/usb/core/hcd.c
> > +++ usb-3.11/drivers/usb/core/hcd.c
> > @@ -1690,7 +1690,9 @@ static void usb_giveback_urb_bh(unsigned
> >
> > urb = list_entry(local_list.next, struct urb, urb_list);
> > list_del_init(&urb->urb_list);
> > +   bh->giveback_ep = urb->ep;
> > __usb_hcd_giveback_urb(urb);
> > +   bh->giveback_ep = NULL;
> > }
> 
> Considered it can be used generally, it is better to keep it as percpu
> operation to avoid probable incorrectness, also percpu write is more
> economical, but it isn't a big deal.

By that argument, _every_ variable that isn't on the stack and is used 
only in preempt-disabled regions should be percpu.  Obviously that 
would be ridiculous overkill.  Percpu variables should be used only 
when there is significant contention.  After all, using a percpu 
variable has its own costs in time and space.

Besides, the CPU that runs this code already owns the cache line
cont

Re: [RFC 3/3] EHCI: handle late isochronous submissions

[Alan Stern]

On Wed, 28 Aug 2013, Ming Lei wrote:

> Below is the approach I proposed(mentioned in another thread), which should be
> simper than this one, any comments?
> 
>  drivers/usb/host/ehci-sched.c |   53 
> ++---
>  drivers/usb/host/ehci.h   |1 +
>  2 files changed, 51 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
> index 83be03f..80ef95d 100644
> --- a/drivers/usb/host/ehci-sched.c
> +++ b/drivers/usb/host/ehci-sched.c
> @@ -1370,6 +1370,33 @@ sitd_slot_ok (
>   return 1;
>  }
>  
> +/* rebase in case of underun without ISO_ASAP together */
> +static int iso_stream_rebase(struct ehci_hcd *ehci, struct urb *urb,
> + struct ehci_iso_stream  *stream, u32 span, u32 period)
> +{
> + u32 i, end;
> + u32 mod = ehci->periodic_size;
> +
> + if (ehci->last_base == -1)
> + return 0;
> +
> + end = ((stream->next_uframe + span - period) >> 3) & (mod - 1);
> + for (i = ehci->last_base; i != ehci->last_iso_frame;
> + i = (i + 1) & (mod - 1)) {
> + /* don't schedule URB which is behind base totally */
> + if (end == i) {
> + for (i = 0; i < urb->number_of_packets; i++) {
> + urb->iso_frame_desc[i].length = 0;
> + urb->iso_frame_desc[i].status = 0;
> + }
> + return 1;
> + }
> + if (((stream->next_uframe >> 3) & (mod - 1)) == i)
> + ehci->last_iso_frame = i;
> + }

Why do you use a loop here?  This looks like a straightforward thing to 
test: Starting from last_base, which comes first: next_uframe or 
last_iso_frame?

It's not a very good idea to change iso_frame_desc[i].length.  HCDs 
aren't suppose to touch that field.  Also, why set the frame 
descriptor status to 0?  It should remain equal to -EXDEV, because the 
frame never gets sent over the bus.

You must never alter ehci->last_iso_frame like this.  It violates the 
driver's invariants for time to run "backward".  After all, there may 
already be other TDs scheduled for the frames you are about to scan 
again; they mustn't get scanned until the frame pointer has wrapped 
around.

This last problem in particular means your proposal can't be accepted.

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

[Pull Request] xhci: Remove warnings introduced by host quirks patch.

[Sarah Sharp]

The following changes since commit 752e69555d107853043cb9405250c9387b26e708:

  Merge tag 'usb-for-v3.12-part2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next 
(2013-08-27 14:07:31 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
tags/for-usb-next-2013-08-28

for you to fetch changes up to 38cafcbc7704dae41ac8761d886f086c6319a686:

  xhci: Fix warning introduced by disabling runtime PM. (2013-08-28 09:41:04 
-0700)


xhci: Remove warnings introduced by host quirks patch.

Hi Greg,

The 0day build system caught a new warning introduced by the quirks patch I
sent you yesterday.  Please pull this fix.

Sarah Sharp


Sarah Sharp (1):
  xhci: Fix warning introduced by disabling runtime PM.

 drivers/usb/host/xhci.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] xhci: Fix warning introduced by disabling runtime PM.

[Sarah Sharp]

The 0day build server caught a new build warning that is triggered when
CONFIG_USB_DEFAULT_PERSIST is turned on:

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
for-usb-next
head:   0730d52a86919300a39a2be37f6c140997dfb82f
commit: c8476fb855434c733099079063990e5bfa7ecad6 [1/3] usb: xhci: Disable 
runtime PM suspend for quirky controllers
config: i386-randconfig-r6-0826 (attached as .config)

All warnings:

   drivers/usb/host/xhci.c: In function 'xhci_free_dev':
>> drivers/usb/host/xhci.c:3560:17: warning: unused variable 'dev' 
>> [-Wunused-variable]
 struct device *dev = hcd->self.controller;
^
   drivers/usb/host/xhci.c: In function 'xhci_alloc_dev':
>> drivers/usb/host/xhci.c:3648:17: warning: unused variable 'dev' 
>> [-Wunused-variable]
 struct device *dev = hcd->self.controller;
^

vim +/dev +3560 drivers/usb/host/xhci.c

  3554   * disabled.  Free any HC data structures associated with that device.
  3555   */
  3556  void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
  3557  {
  3558  struct xhci_hcd *xhci = hcd_to_xhci(hcd);
  3559  struct xhci_virt_device *virt_dev;
> 3560  struct device *dev = hcd->self.controller;
  3561  unsigned long flags;
  3562  u32 state;
  3563  int i, ret;
  3564
  3565  #ifndef CONFIG_USB_DEFAULT_PERSIST
  3566  /*
  3567   * We called pm_runtime_get_noresume when the device was 
attached.
  3568   * Decrement the counter here to allow controller to runtime 
suspend
  3569   * if no devices remain.
  3570   */
  3571  if (xhci->quirks & XHCI_RESET_ON_RESUME)
  3572  pm_runtime_put_noidle(dev);
  3573  #endif
  3574
...
  3641  /*
  3642   * Returns 0 if the xHC ran out of device slots, the Enable Slot command
  3643   * timed out, or allocating memory failed.  Returns 1 on success.
  3644   */
  3645  int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
  3646  {
  3647  struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> 3648  struct device *dev = hcd->self.controller;
  3649  unsigned long flags;
  3650  int timeleft;
  3651  int ret;

Fix this.

Signed-off-by: Sarah Sharp 
Cc: Shawn Nematbakhsh 
---
 drivers/usb/host/xhci.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 349d346..49b6edb 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3557,7 +3557,6 @@ void xhci_free_dev(struct usb_hcd *hcd, struct usb_device 
*udev)
 {
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_virt_device *virt_dev;
-   struct device *dev = hcd->self.controller;
unsigned long flags;
u32 state;
int i, ret;
@@ -3569,7 +3568,7 @@ void xhci_free_dev(struct usb_hcd *hcd, struct usb_device 
*udev)
 * if no devices remain.
 */
if (xhci->quirks & XHCI_RESET_ON_RESUME)
-   pm_runtime_put_noidle(dev);
+   pm_runtime_put_noidle(hcd->self.controller);
 #endif
 
ret = xhci_check_args(hcd, udev, NULL, 0, true, __func__);
@@ -3645,7 +3644,6 @@ static int xhci_reserve_host_control_ep_resources(struct 
xhci_hcd *xhci)
 int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
 {
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
-   struct device *dev = hcd->self.controller;
unsigned long flags;
int timeleft;
int ret;
@@ -3705,7 +3703,7 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device 
*udev)
 * suspend if there is a device attached.
 */
if (xhci->quirks & XHCI_RESET_ON_RESUME)
-   pm_runtime_get_noresume(dev);
+   pm_runtime_get_noresume(hcd->self.controller);
 #endif
 
/* Is this a LS or FS device under a HS hub? */
-- 
1.8.3.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 v2 1/3] usb: add is_usb_mouse routine and remote wakeup quirk

[Greg Kroah-Hartman]

On Wed, Aug 28, 2013 at 04:09:32PM +0800, Huang Rui wrote:
> On Wed, Aug 28, 2013 at 11:38:28AM +0800, Greg Kroah-Hartman wrote:
> > On Wed, Aug 28, 2013 at 11:13:12AM +0800, Huang Rui wrote:
> > > This patch add a routine to judge if the usb device is a mouse or not.
> > > The is_usb_mouse only has one input parameter of usb_device. The
> > > return value is bool type, and true means this device is mouse and
> > > vice-versa.
> > 
> > No, sorry, this isn't ok for a number of reasons.
> > 
> > You got "lucky" in that you can duplicate this with a mouse, the fact
> > that it is a mouse that caused your problems should never mean that the
> > os only triggers on a mouse device.  I can create a "keyboard" device
> > that has the exact same USB characteristics that a mouse does, that
> > should also be able to trigger your problem.  Or a vendor specific
> > device.
> > 
> 
> Yes, you're right. This issue is specific to the devices that use
> Pixart controller, and the Pixart controller is only used by mouse.
> That's why I filtered for usb mouse.

So, to "fix" one specific controller, you drag in hundreds of thousands
of other devices as well?  That's not ok.

> Below answer is our HW guys' feedback. In cover letter, you would see
> more details.

cover letters don't get applied to the kernel changelog, so they don't
count for much :)

> [Q] Why the special devices are only mice? Would high speed devices
> such as 3G modem or USB Bluetooth adapter trigger this issue?
> - Current this sensitivity is only confined to devices that use Pixart
>   controllers. This controller is designed for use with LS mouse
> devices only. We have not observed any other devices failing. There
> may be a small risk for other devices also but this patch (reset
> device in resume phase) will cover the cases if required.

Then just do this "quirk" for Pixart controller devices.  Don't penalize
everyone else.

And have you worked with the Pixart company to "fix" this issue so that
future devices they create don't have this issue in it?

> > That's why the USB core doesn't care about the device type, they are all
> > just "pipes".  So please deal with it on that level, never do something
> > only depending on the "type" of device plugged into the system.
> > 
> 
> I got it. Do you mean if I want do filter usb devices by usb mouse, I
> should do it at hid or usbhid level?

Neither, you could "miss" a mouse at those levels as well.

Think about userspace control of USB devices, as well as mice that don't
use the HID layer (rare, but I've seen it happen.)

Again, don't filter for a "mouse", filter for the controller that you
need to fix.

> > Hint, I bet you didn't fix this bug in Windows this way, right?  :)
> > 
> 
> Actually, this issue is found in Windows firstly, and we set a
> registry to force the driver to reset the device on S3 resume to work
> around it. Then I reproduce it in Linux OS, and make a same solution. :)

So on Windows you do this for all mice devices?  Or just Pixart devices?
If all mice devices, the Windows developers accepted such a change?

thanks,

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

Re: [Pull Request] xhci: Bug fixes for 3.12.

[Greg Kroah-Hartman]

On Wed, Aug 28, 2013 at 10:44:57AM +0300, Dmitry Kasatkin wrote:
> On 27/08/13 21:26, Sarah Sharp wrote:
> > The following changes since commit 154547c4fe0fbe92185e69a6cdc2b0502b361995:
> >
> >   USB: serial: clean up attribute permissions (2013-08-25 15:12:03 -0700)
> >
> > are available in the git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
> > tags/for-usb-next-2013-08-27
> >
> > for you to fetch changes up to 0730d52a86919300a39a2be37f6c140997dfb82f:
> >
> >   xhci:prevent "callbacks suppressed" when debug is not enabled (2013-08-27 
> > 08:56:31 -0700)
> >
> > 
> > xhci: Bug fixes for 3.12.
> >
> > Hi Greg,
> >
> > Here's three low-priority bug fixes that should be queued for 3.12.
> > They disable runtime PM for hosts that need the XHCI_RESET_ON_RESUME
> > quirk, fix USB 2.0 Link PM on hosts that don't have BESL support, and
> > prevent a bunch of log spam.
> >
> > Please pull into usb-next for 3.12.
> >
> > Sarah Sharp
> >
> > 
> > Dmitry Kasatkin (1):
> >   xhci:prevent "callbacks suppressed" when debug is not enabled
> >
> > Mathias Nyman (1):
> >   xhci: fix port BESL LPM capability checking
> >
> > Shawn Nematbakhsh (1):
> >   usb: xhci: Disable runtime PM suspend for quirky controllers
> >
> >  drivers/usb/host/xhci-ext-caps.h |2 +-
> >  drivers/usb/host/xhci-ring.c |   24 
> >  drivers/usb/host/xhci.c  |   22 ++
> >  3 files changed, 31 insertions(+), 17 deletions(-)
> >
> Hello,
> 
> I sent 2 patches. Only second one was taken. [PATCHv2 2/2]
> [PATCHv2 1/2] is required to prevent build break.

Ugh, Sarah, I thought you were taking both patches :(

I'll go dig up this one and add it to fix the build breakage...

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: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sarah Sharp]

Please trim your replies.

On Wed, Aug 28, 2013 at 01:53:49PM +0300, Dmitry Kasatkin wrote:
> >>> That change seems to cause the problems:
> >>>
> >>> commit 0730d52a86919300a39a2be37f6c140997dfb82f
> >>> "xhci:prevent "callbacks suppressed" when debug is not enabled"
> >>>
> >>> - Sedat -
> >>>
> >>> [1] 
> >>> http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
> >>>
> >> Hello,
> >>
> >> [PATCHv2 1/2] was not applied before.
> >> I pointed this out few hours ago...

So commit 0730d52a86919300a39a2be37f6c140997dfb82f 'xhci:prevent
"callbacks suppressed" when debug is not enabled' needed to be applied
after your first patch?  And basically applying that patch alone breaks
the build?

Ugh.  Sorry about this.  Greg, how do you want to handle this?

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

Re: [Pull Request] xhci: Remove warnings introduced by host quirks patch.

[Greg Kroah-Hartman]

On Wed, Aug 28, 2013 at 09:51:18AM -0700, Sarah Sharp wrote:
> The following changes since commit 752e69555d107853043cb9405250c9387b26e708:
> 
>   Merge tag 'usb-for-v3.12-part2' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next 
> (2013-08-27 14:07:31 -0700)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
> tags/for-usb-next-2013-08-28
> 
> for you to fetch changes up to 38cafcbc7704dae41ac8761d886f086c6319a686:
> 
>   xhci: Fix warning introduced by disabling runtime PM. (2013-08-28 09:41:04 
> -0700)

What about the other device.h fix needed by the xhci driver?  Can you
just add it to this branch so I can do one pull to fix both problems?

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 v3] xHCI: Fixing xhci_readl definition and function call

[Sarah Sharp]

On Wed, Aug 28, 2013 at 08:39:06PM +0530, Kumar Gaurav wrote:
> On Wednesday 28 August 2013 12:43 PM, Dan Carpenter wrote:
> >On Mon, Aug 26, 2013 at 07:38:57AM +0530, Kumar Gaurav wrote:
> I've started cloning linux-next and as it's not applying on
> linux-next, I'll try it on linux-next (once i cloned it)  and will
> send again.

Yeah, this doesn't apply against Greg's usb-next tree, so I can't take
it.  If you're sending non-bug fixes in, you need to base your patches
against that tree, or linux-next.

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

Re: [PATCH v2 1/3] usb: add is_usb_mouse routine and remote wakeup quirk

[Alan Stern]

On Wed, 28 Aug 2013, Greg Kroah-Hartman wrote:

> > [Q] Why the special devices are only mice? Would high speed devices
> > such as 3G modem or USB Bluetooth adapter trigger this issue?
> > - Current this sensitivity is only confined to devices that use Pixart
> >   controllers. This controller is designed for use with LS mouse
> > devices only. We have not observed any other devices failing. There
> > may be a small risk for other devices also but this patch (reset
> > device in resume phase) will cover the cases if required.
> 
> Then just do this "quirk" for Pixart controller devices.  Don't penalize
> everyone else.

Is there any way to detect when a device uses a Pixart controller?  I 
don't see how you could tell.

> > I got it. Do you mean if I want do filter usb devices by usb mouse, I
> > should do it at hid or usbhid level?
> 
> Neither, you could "miss" a mouse at those levels as well.
> 
> Think about userspace control of USB devices, as well as mice that don't
> use the HID layer (rare, but I've seen it happen.)
> 
> Again, don't filter for a "mouse", filter for the controller that you
> need to fix.

What if it's not possible to do this?

Alan Stern

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

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Greg Kroah-Hartman]

On Wed, Aug 28, 2013 at 09:59:38AM -0700, Sarah Sharp wrote:
> Please trim your replies.
> 
> On Wed, Aug 28, 2013 at 01:53:49PM +0300, Dmitry Kasatkin wrote:
> > >>> That change seems to cause the problems:
> > >>>
> > >>> commit 0730d52a86919300a39a2be37f6c140997dfb82f
> > >>> "xhci:prevent "callbacks suppressed" when debug is not enabled"
> > >>>
> > >>> - Sedat -
> > >>>
> > >>> [1] 
> > >>> http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
> > >>>
> > >> Hello,
> > >>
> > >> [PATCHv2 1/2] was not applied before.
> > >> I pointed this out few hours ago...
> 
> So commit 0730d52a86919300a39a2be37f6c140997dfb82f 'xhci:prevent
> "callbacks suppressed" when debug is not enabled' needed to be applied
> after your first patch?  And basically applying that patch alone breaks
> the build?
> 
> Ugh.  Sorry about this.  Greg, how do you want to handle this?

See my other response about your pull request, how about tacking it onto
there?

thanks,

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

Re: [RFC v2] usb: Fix xHCI host issues on remote wakeup.

[Greg KH]

On Wed, Aug 28, 2013 at 08:27:48AM -0700, Sarah Sharp wrote:
> On Tue, Aug 27, 2013 at 05:41:19PM -0700, Greg KH wrote:
> > On Mon, Aug 26, 2013 at 06:59:22PM -0700, Sarah Sharp wrote:
> > > I attempted to replicate this bug with Ubuntu 12.04, but could not.  I
> > > used Ubuntu 12.04 on the same platform, with the same BIOS that the bug
> > > was triggered on ChromeOS with.  I also changed the USB sysfs settings
> > > as described above, but still could not reproduce the bug under Ubuntu.
> > > It may be that ChromeOS userspace triggers this bug through additional
> > > settings.
> > 
> > Did you test this on ChromeOS to determine that the patch fixes the bug?
> 
> Yes, it does fix the bug.

Great, I didn't get that from the changelog entry, sorry.

> > > This patch should be backported to kernels as old as 2.6.37, that
> > > contain the commit 561925318725a41189a69f36ebe99199b3fb84c4 "USB: xHCI:
> > > port remote wakeup implementation".  It may be difficult to backport
> > > this due to xhci->bus_state being unavailable in older kernels, and the
> > > code to split xHCI roothubs into a USB 2.0 roothub and a USB 3.0 roothub
> > > not going in until 2.6.39.
> > 
> > If only ChromeOS is affected, why backport it for any stable tree?
> 
> I don't understand this logic.
> 
> The xHCI driver is violating the xHCI spec by not waiting for the port
> status change to indicate the port is actually in U0 (active state)
> before telling the USB core it's safe to communicate with the port.
> Which OS happens to trigger this bug is not important in my mind, since
> it's still a bug in the driver.
> 
> ChromeOS can trigger this bug, whether it's running on the 3.8.11
> kernel, or the 3.10.7 kernel.  Therefore I would think we would want
> this fix in stable kernels, case some other distribution happened to hit
> the combination of sysfs writes that causes ChromeOS to trigger this
> bug.
> 
> Or are you arguing that we shouldn't backport this because it's just
> triggered on one distribution?  Am I required to verify all bugs are
> triggered on two distributions before they should be considered for
> stable?

No, my point was if no one can see the bug, then it's not a bug that
needs to be fixed in a stable kernel (see
Documentation/stable_kernel_rules.txt for details.)  As no one else has
run into this before now, and no older kernels have shown the problem to
anyone, it's not all that "important" to backport this type of thing,
right?

I'm not saying it's not good to push it to older kernels, just the need
is quite low, right?

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 v3] xHCI: Fixing xhci_readl definition and function call

[Kumar Gaurav]

On Wednesday 28 August 2013 10:31 PM, Sarah Sharp wrote:

On Wed, Aug 28, 2013 at 08:39:06PM +0530, Kumar Gaurav wrote:

On Wednesday 28 August 2013 12:43 PM, Dan Carpenter wrote:

On Mon, Aug 26, 2013 at 07:38:57AM +0530, Kumar Gaurav wrote:

I've started cloning linux-next and as it's not applying on
linux-next, I'll try it on linux-next (once i cloned it)  and will
send again.

Yeah, this doesn't apply against Greg's usb-next tree, so I can't take
it.  If you're sending non-bug fixes in, you need to base your patches
against that tree, or linux-next.

Sarah Sharp

I'm trying against linux-git as
cat 0027-xHCI-Fixing-xhci_readl-definition-and-function-call.patch| 
patch

and then after i enter the required file (drivers/usb/host/xhci-dbg.c).
it's giving me  message

File to patch: drivers/usb/host/xhci-dbg.c
patching file drivers/usb/host/xhci-dbg.c
can't find file to patch at input line 180
Perhaps you should have used the -p or --strip option?
The text leading up to this was:

but when i saw the file i found changes are applied there.

I had made the patch using git format-patch. what could be the possible 
reason behind this issue or am i mistaking somewhere?



Regards
Kumar Gaurav



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

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Dmitry Kasatkin]

On 28/08/13 19:59, Sarah Sharp wrote:
> Please trim your replies.
>
> On Wed, Aug 28, 2013 at 01:53:49PM +0300, Dmitry Kasatkin wrote:
> That change seems to cause the problems:
>
> commit 0730d52a86919300a39a2be37f6c140997dfb82f
> "xhci:prevent "callbacks suppressed" when debug is not enabled"
>
> - Sedat -
>
> [1] 
> http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
>
 Hello,

 [PATCHv2 1/2] was not applied before.
 I pointed this out few hours ago...
> So commit 0730d52a86919300a39a2be37f6c140997dfb82f 'xhci:prevent
> "callbacks suppressed" when debug is not enabled' needed to be applied
> after your first patch?  And basically applying that patch alone breaks
> the build?

Right...
May be I had to stress it somehow... sorry.

> Ugh.  Sorry about this.  Greg, how do you want to handle this?
>
> Sarah "needs a vacation" Sharp
>


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

Re: [PATCH v2 1/3] usb: add is_usb_mouse routine and remote wakeup quirk

[Greg Kroah-Hartman]

On Wed, Aug 28, 2013 at 01:13:46PM -0400, Alan Stern wrote:
> On Wed, 28 Aug 2013, Greg Kroah-Hartman wrote:
> 
> > > [Q] Why the special devices are only mice? Would high speed devices
> > > such as 3G modem or USB Bluetooth adapter trigger this issue?
> > > - Current this sensitivity is only confined to devices that use Pixart
> > >   controllers. This controller is designed for use with LS mouse
> > > devices only. We have not observed any other devices failing. There
> > > may be a small risk for other devices also but this patch (reset
> > > device in resume phase) will cover the cases if required.
> > 
> > Then just do this "quirk" for Pixart controller devices.  Don't penalize
> > everyone else.
> 
> Is there any way to detect when a device uses a Pixart controller?  I 
> don't see how you could tell.

Vendor device id should tell you what you need to know, right?

thanks,

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

Re: [RFC v2] usb: Fix xHCI host issues on remote wakeup.

[Sarah Sharp]

On Wed, Aug 28, 2013 at 10:26:01AM -0700, Greg KH wrote:
> On Wed, Aug 28, 2013 at 08:27:48AM -0700, Sarah Sharp wrote:
> > On Tue, Aug 27, 2013 at 05:41:19PM -0700, Greg KH wrote:
> > > On Mon, Aug 26, 2013 at 06:59:22PM -0700, Sarah Sharp wrote:
> > > > This patch should be backported to kernels as old as 2.6.37, that
> > > > contain the commit 561925318725a41189a69f36ebe99199b3fb84c4 "USB: xHCI:
> > > > port remote wakeup implementation".  It may be difficult to backport
> > > > this due to xhci->bus_state being unavailable in older kernels, and the
> > > > code to split xHCI roothubs into a USB 2.0 roothub and a USB 3.0 roothub
> > > > not going in until 2.6.39.
> > > 
> > > If only ChromeOS is affected, why backport it for any stable tree?
> > 
> > I don't understand this logic.
> > 
> > The xHCI driver is violating the xHCI spec by not waiting for the port
> > status change to indicate the port is actually in U0 (active state)
> > before telling the USB core it's safe to communicate with the port.
> > Which OS happens to trigger this bug is not important in my mind, since
> > it's still a bug in the driver.
> > 
> > ChromeOS can trigger this bug, whether it's running on the 3.8.11
> > kernel, or the 3.10.7 kernel.  Therefore I would think we would want
> > this fix in stable kernels, case some other distribution happened to hit
> > the combination of sysfs writes that causes ChromeOS to trigger this
> > bug.
> > 
> > Or are you arguing that we shouldn't backport this because it's just
> > triggered on one distribution?  Am I required to verify all bugs are
> > triggered on two distributions before they should be considered for
> > stable?
> 
> No, my point was if no one can see the bug, then it's not a bug that
> needs to be fixed in a stable kernel (see
> Documentation/stable_kernel_rules.txt for details.)  As no one else has
> run into this before now, and no older kernels have shown the problem to
> anyone, it's not all that "important" to backport this type of thing,
> right?
> 
> I'm not saying it's not good to push it to older kernels, just the need
> is quite low, right?

Ok, yes, I see your logic now.  Backporting this patch wouldn't be high
priority for distros that don't trigger this bug.  So yes, the need for
it to get backported is low.  I'll remove the stable tagging.

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

[PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO

[George Cherian]

Add a generic USB VBUS/ID detection EXTCON driver. This driver expects
the ID/VBUS pin are connected via GPIOs. This driver is tested on
DRA7x board were the ID pin is routed via GPIOs. The driver supports
both VBUS and ID pin configuration and ID pin only configuration.

Signed-off-by: George Cherian 
---
 .../bindings/extcon/extcon-gpio-usbvid.txt |  20 ++
 drivers/extcon/Kconfig |   6 +
 drivers/extcon/Makefile|   1 +
 drivers/extcon/extcon-gpio-usbvid.c| 286 +
 4 files changed, 313 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt
 create mode 100644 drivers/extcon/extcon-gpio-usbvid.c

diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt 
b/Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt
new file mode 100644
index 000..eea0741
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt
@@ -0,0 +1,20 @@
+EXTCON FOR USB VIA GPIO
+
+Required Properties:
+ - compatible : Should be "ti,gpio-usb-vid" for USB VBUS-ID detector
+   using gpios or "ti,gpio-usb-id" for USB ID pin detector
+ - gpios : phandle and args ID pin gpio and VBUS gpio.
+  The first gpio used  for ID pin detection
+  and the second used for VBUS detection.
+  ID pin gpio is mandatory and VBUS is optional
+  depending on implementation.
+
+Please refer to ../gpio/gpio.txt for details of the common GPIO bindings
+
+Example:
+
+   gpio_usbvid_extcon1 {
+   compatible = "ti,gpio-usb-vid";
+   gpios = <&gpio1 1 0>,
+   <&gpio2 2 0>;
+   };
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index f1d54a3..8097398 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -64,4 +64,10 @@ config EXTCON_PALMAS
  Say Y here to enable support for USB peripheral and USB host
  detection by palmas usb.
 
+config EXTCON_GPIO_USBVID
+   tristate "Generic USB VBUS/ID detection using GPIO EXTCON support"
+   help
+ Say Y here to enable support for USB VBUS/ID deetction by GPIO.
+
+
 endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index e4fa8ba..0451f698 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
 obj-$(CONFIG_EXTCON_MAX8997)   += extcon-max8997.o
 obj-$(CONFIG_EXTCON_ARIZONA)   += extcon-arizona.o
 obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
+obj-$(CONFIG_EXTCON_GPIO_USBVID)   += extcon-gpio-usbvid.o
diff --git a/drivers/extcon/extcon-gpio-usbvid.c 
b/drivers/extcon/extcon-gpio-usbvid.c
new file mode 100644
index 000..e9bc2a97
--- /dev/null
+++ b/drivers/extcon/extcon-gpio-usbvid.c
@@ -0,0 +1,286 @@
+/*
+ * Generic  USB VBUS-ID pin detection driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: George Cherian 
+ *
+ * Based on extcon-palmas.c
+ *
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct gpio_usbvid {
+   struct device *dev;
+
+   struct extcon_dev edev;
+
+   /*GPIO pin */
+   int id_gpio;
+   int vbus_gpio;
+
+   int id_irq;
+   int vbus_irq;
+   int type;
+};
+
+static const char *dra7xx_extcon_cable[] = {
+   [0] = "USB",
+   [1] = "USB-HOST",
+   NULL,
+};
+
+static const int mutually_exclusive[] = {0x3, 0x0};
+
+/* Two types of support are provided.
+ * Systems which has
+ * 1) VBUS and ID pin connected via GPIO
+ * 2)  only ID pin connected via GPIO
+ *  For Case 1 both the gpios should be provided via DT
+ *  Always the first GPIO in dt is considered ID pin GPIO
+ */
+
+enum {
+   UNKNOWN = 0,
+   ID_DETECT,
+   VBUS_ID_DETECT,
+};
+
+#define ID_GND 0
+#define ID_FLOAT   1
+#define VBUS_OFF   0
+#define VBUS_ON1
+
+
+static irqreturn_t id_irq_handler(int irq, void *data)
+{
+   struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *) data;
+   int id_current;
+
+   id_current = gpio_get_value_cansleep(gpio_usbvid->id_gpio);
+   if (id_current == ID_GND) {
+   if (gpio_usbvid->type == ID_DETECT)
+   extcon_set_cable_state(&gpio_u

[PATCH v3 3/3] ARM: dts: dra7-evm: Add extcon nodes for USB ID pin detection

[George Cherian]

Add
-extcon nodes for USB ID pin detection.
-i2c nodes.
-pcf nodes to which USB ID pin is connected.

Signed-off-by: George Cherian 
---
 arch/arm/boot/dts/dra7-evm.dts | 50 +-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index acd3c09..8b0738a 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -17,6 +17,17 @@
device_type = "memory";
reg = <0x8000 0x6000>; /* 1536 MB */
};
+
+   extcon1: gpio_usbvid_extcon1 {
+   compatible = "ti,gpio-usb-id";
+   gpios = <&gpio21 1 0>;
+   };
+
+   extcon2: gpio_usbvid_extcon2 {
+   compatible = "ti,gpio-usb-id";
+   gpios = <&gpio21 2 0>;
+   };
+
 };
 
 &dra7_pmx_core {
@@ -33,10 +44,47 @@
 };
 };
 
+&i2c1 {
+   clock-frequency = <40>;
+
+   gpio20: pcf8575@20 {
+   compatible = "ti,pcf8575";
+   reg = <0x20>;
+   n_latch = <0x4000>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&gpio6>;
+   interrupts = <11 2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpio21: pcf8575@21 {
+   compatible = "ti,pcf8575";
+   reg = <0x21>;
+   n_latch = <0x1408>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&pcf_20>;
+   interrupts = <14 2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+};
+
 &dwc3_1 {
-   dr_mode = "otg";
+   dr_mode = "host";
 };
 
 &dwc3_2 {
dr_mode = "host";
 };
+
+&usb1 {
+   extcon = <&extcon1>;
+};
+
+&usb2 {
+   extcon = <&extcon2>;
+};
-- 
1.8.1.4

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

Re: [PATCH v2 0/3] Add Generic USB VBUS/ID detection via GPIO using extcon

[George Cherian]

On 8/28/2013 7:29 PM, George Cherian wrote:

Hi,

These patches add generic support for USB VBUS/ID pin detection using extcon 
framework.
The USB ID pin on DRA7xx is connected via the gpio expander pcf8575.
The interrupt line of the same is connected to the gpio 11 of bank 6.
The following driver relies on  the  gpio interrupt to notify the actual
ID pin values by which the dwc3 driver determines the HOST/Peripheral roles.

Please ignore this patch set I just noticed that patch #1 is malformed.
Sending v3 in a while.

Regards,
-George
--
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 v3] xHCI: Fixing xhci_readl definition and function call

[Sarah Sharp]

On Wed, Aug 28, 2013 at 10:45:48PM +0530, Kumar Gaurav wrote:
> On Wednesday 28 August 2013 10:31 PM, Sarah Sharp wrote:
> >On Wed, Aug 28, 2013 at 08:39:06PM +0530, Kumar Gaurav wrote:
> >>On Wednesday 28 August 2013 12:43 PM, Dan Carpenter wrote:
> >>>On Mon, Aug 26, 2013 at 07:38:57AM +0530, Kumar Gaurav wrote:
> >>I've started cloning linux-next and as it's not applying on
> >>linux-next, I'll try it on linux-next (once i cloned it)  and will
> >>send again.
> >Yeah, this doesn't apply against Greg's usb-next tree, so I can't take
> >it.  If you're sending non-bug fixes in, you need to base your patches
> >against that tree, or linux-next.
> >
> >Sarah Sharp
> I'm trying against linux-git as
> cat
> 0027-xHCI-Fixing-xhci_readl-definition-and-function-call.patch|
> patch

No, don't do that.  Use `git am` instead, possibly with the 3-way merge
options.

> and then after i enter the required file (drivers/usb/host/xhci-dbg.c).
> it's giving me  message
> 
> File to patch: drivers/usb/host/xhci-dbg.c
> patching file drivers/usb/host/xhci-dbg.c
> can't find file to patch at input line 180
> Perhaps you should have used the -p or --strip option?
> The text leading up to this was:
> 
> but when i saw the file i found changes are applied there.
> 
> I had made the patch using git format-patch. what could be the
> possible reason behind this issue or am i mistaking somewhere?

I would try checking out linux-next on a new branch, and then using `git
cherry-pick` to apply your patch.  That will try to apply the patch, and
give you merge conflicts if they don't apply.  You'll need to clean
those conflicts up and re-submit the resulting patch.  You may have to
re-do the patch if you can't get it to apply against linux-next.

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

Re: [Pull Request] xhci: Remove warnings introduced by host quirks patch.

[Sarah Sharp]

On Wed, Aug 28, 2013 at 10:09:44AM -0700, Greg Kroah-Hartman wrote:
> On Wed, Aug 28, 2013 at 09:51:18AM -0700, Sarah Sharp wrote:
> > The following changes since commit 752e69555d107853043cb9405250c9387b26e708:
> > 
> >   Merge tag 'usb-for-v3.12-part2' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next 
> > (2013-08-27 14:07:31 -0700)
> > 
> > are available in the git repository at:
> > 
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
> > tags/for-usb-next-2013-08-28
> > 
> > for you to fetch changes up to 38cafcbc7704dae41ac8761d886f086c6319a686:
> > 
> >   xhci: Fix warning introduced by disabling runtime PM. (2013-08-28 
> > 09:41:04 -0700)
> 
> What about the other device.h fix needed by the xhci driver?  Can you
> just add it to this branch so I can do one pull to fix both problems?

Sure.  I can do that.

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

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sarah Sharp]

On Wed, Aug 28, 2013 at 10:18:24AM -0700, Greg Kroah-Hartman wrote:
> On Wed, Aug 28, 2013 at 09:59:38AM -0700, Sarah Sharp wrote:
> > Please trim your replies.
> > 
> > On Wed, Aug 28, 2013 at 01:53:49PM +0300, Dmitry Kasatkin wrote:
> > > >>> That change seems to cause the problems:
> > > >>>
> > > >>> commit 0730d52a86919300a39a2be37f6c140997dfb82f
> > > >>> "xhci:prevent "callbacks suppressed" when debug is not enabled"
> > > >>>
> > > >>> - Sedat -
> > > >>>
> > > >>> [1] 
> > > >>> http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
> > > >>>
> > > >> Hello,
> > > >>
> > > >> [PATCHv2 1/2] was not applied before.
> > > >> I pointed this out few hours ago...
> > 
> > So commit 0730d52a86919300a39a2be37f6c140997dfb82f 'xhci:prevent
> > "callbacks suppressed" when debug is not enabled' needed to be applied
> > after your first patch?  And basically applying that patch alone breaks
> > the build?
> > 
> > Ugh.  Sorry about this.  Greg, how do you want to handle this?
> 
> See my other response about your pull request, how about tacking it onto
> there?

Yeah, you could take the first patch and apply it to the usb-next tree.
There would still be a few patches where build breakage occurs, but that
will be there regardless of whether we revert that patch, apply the
first one, and then re-apply the second one.  So just applying the first
patch seems to be the better option.

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

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 7:24 PM, Dmitry Kasatkin  wrote:
> On 28/08/13 19:59, Sarah Sharp wrote:
>> Please trim your replies.
>>
>> On Wed, Aug 28, 2013 at 01:53:49PM +0300, Dmitry Kasatkin wrote:
>> That change seems to cause the problems:
>>
>> commit 0730d52a86919300a39a2be37f6c140997dfb82f
>> "xhci:prevent "callbacks suppressed" when debug is not enabled"
>>
>> - Sedat -
>>
>> [1] 
>> http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
>>
> Hello,
>
> [PATCHv2 1/2] was not applied before.
> I pointed this out few hours ago...
>> So commit 0730d52a86919300a39a2be37f6c140997dfb82f 'xhci:prevent
>> "callbacks suppressed" when debug is not enabled' needed to be applied
>> after your first patch?  And basically applying that patch alone breaks
>> the build?
>
> Right...
> May be I had to stress it somehow... sorry.
>

Still noone answered me why "drivers/usb/host/xhci-ring.c" does NOT
include  (dev_info_ratelimited() and other defines).
I am expecting that... even I see...

  drivers/usb/host/.xhci-ring.o.cmd:715:  include/linux/device.h \

...where I don't know why this happens.

( For me this is a bit more important than """trimming""" my
responses, I keep the history... )

- Sedat -

P.S.: List of includes in xhci-ring.c

$ grep ^'#include' -nr drivers/usb/host/xhci-ring.c
67:#include 
68:#include 
69:#include "xhci.h"
70:#include "xhci-trace.h"


>> Ugh.  Sorry about this.  Greg, how do you want to handle this?
>>
>> Sarah "needs a vacation" Sharp
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/3] Add Generic USB VBUS/ID detection via GPIO using extcon

[George Cherian]

Hi,

These patches add generic support for USB VBUS/ID pin detection using extcon 
framework.
The USB ID pin on DRA7xx is connected via the gpio expander pcf8575.
The interrupt line of the same is connected to the gpio 11 of bank 6.
The following driver relies on  the  gpio interrupt to notify the actual
ID pin values by which the dwc3 driver determines the HOST/Peripheral roles.


These patches are on top of following merges.
v3.11-rc3 dra7 baseport tree [1] , with balbi/next ,control-usb multi instance 
support [2],
chanwoo/extcon-next, roger's patches for USB host adaptation[3],Laurent 
Pinchart's patch to
Enable pcf857x GPIO expander for Device Tree[4] and pcf857x cleanup patch [5].

Patches are available at
extcon_gpio_usbvid-v1
in git tree
git://git.ti.com/~georgecherian/ti-linux-kernel/georgec-connectivity-linux-feature-tree.git

[1] - dra7 base tree
https://github.com/lokeshvutla/linux/tree/dra7-3.11-rc3-base
[2] - multiple control-usb instances
https://github.com/rogerq/linux/tree/usb-control-module
[3] - [PATCH 0/4] ARM: DRA7-evm: USB host adaptation
https://lkml.org/lkml/2013/8/1/335
[4] - [PATCH v5] gpio: pcf857x: Add OF support
https://lkml.org/lkml/2013/8/27/70
[5] - [PATCH] gpio: pcf857x: cleanup irq_demux_work and use threaded irq
https://lkml.org/lkml/2013/8/27/207

George Cherian (3):
  extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO
  drivers: Makefile: Extcon is a framework so bump it up
  ARM: dts: dra7-evm: Add extcon nodes for USB ID pin detection

 .../bindings/extcon/extcon-gpio-usbvid.txt |  20 ++
 arch/arm/boot/dts/dra7-evm.dts |  50 +++-
 drivers/Makefile   |   2 +-
 drivers/extcon/Kconfig |   6 +
 drivers/extcon/Makefile|   1 +
 drivers/extcon/extcon-gpio-usbvid.c| 286 +
 6 files changed, 363 insertions(+), 2 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt
 create mode 100644 drivers/extcon/extcon-gpio-usbvid.c

-- 
1.8.1.4

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

[PATCH v3 1/1] dev-core: fix build break when DEBUG is enabled

[Sarah Sharp]

Any objections to queuing this patch through Greg's usb-next tree?  I've
already sent the 2/2 patch, which will cause build breakage without this
patch.

Changes since v2:
 - Fixed a checkpatch warning caused by a comment in a macro.

Sarah Sharp

>88<

From: Dmitry Kasatkin 

When DEBUG is defined, dev_dbg_ratelimited uses dynamic debug data
structures even when CONFIG_DYNAMIC_DEBUG is not defined.
It leads to build break.
For example, when I try to use dev_dbg_ratelimited in USB code and
CONFIG_USB_DEBUG is enabled, but CONFIG_DYNAMIC_DEBUG is not, I get:

  CC [M]  drivers/usb/host/xhci-ring.o
  drivers/usb/host/xhci-ring.c: In function ‘xhci_queue_intr_tx’:
  drivers/usb/host/xhci-ring.c:3059:3: error: implicit declaration of function 
‘DEFINE_DYNAMIC_DEBUG_METADATA’ [-Werror=implicit-function-declaration]
  drivers/usb/host/xhci-ring.c:3059:3: error: ‘descriptor’ undeclared (first 
use in this function)
  drivers/usb/host/xhci-ring.c:3059:3: note: each undeclared identifier is 
reported only once for each function it appears in
  drivers/usb/host/xhci-ring.c:3059:3: error: implicit declaration of function 
‘__dynamic_pr_debug’ [-Werror=implicit-function-declaration]
  drivers/usb/host/xhci-ring.c: In function ‘xhci_queue_isoc_tx_prepare’:
  drivers/usb/host/xhci-ring.c:3847:3: error: ‘descriptor’ undeclared (first 
use in this function)
  cc1: some warnings being treated as errors
  make[2]: *** [drivers/usb/host/xhci-ring.o] Error 1
  make[1]: *** [drivers/usb/host] Error 2
  make: *** [drivers/usb/] Error 2

This patch separates definition for CONFIG_DYNAMIC_DEBUG and DEBUG cases.

[Note, Sarah moved the comment above the macro to avoid checkpatch
warnings.]

Signed-off-by: Dmitry Kasatkin 
Signed-off-by: Sarah Sharp 
---
 include/linux/device.h | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index 22b546a..7d960d5 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1099,7 +1099,8 @@ do {  
\
dev_level_ratelimited(dev_notice, dev, fmt, ##__VA_ARGS__)
 #define dev_info_ratelimited(dev, fmt, ...)\
dev_level_ratelimited(dev_info, dev, fmt, ##__VA_ARGS__)
-#if defined(CONFIG_DYNAMIC_DEBUG) || defined(DEBUG)
+#if defined(CONFIG_DYNAMIC_DEBUG)
+/* descriptor check is first to prevent flooding with "callbacks suppressed" */
 #define dev_dbg_ratelimited(dev, fmt, ...) \
 do {   \
static DEFINE_RATELIMIT_STATE(_rs,  \
@@ -1108,8 +1109,17 @@ do { 
\
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT) &&\
__ratelimit(&_rs))  \
-   __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
-  ##__VA_ARGS__);  \
+   __dynamic_dev_dbg(&descriptor, dev, fmt,\
+ ##__VA_ARGS__);   \
+} while (0)
+#elif defined(DEBUG)
+#define dev_dbg_ratelimited(dev, fmt, ...) \
+do {   \
+   static DEFINE_RATELIMIT_STATE(_rs,  \
+ DEFAULT_RATELIMIT_INTERVAL,   \
+ DEFAULT_RATELIMIT_BURST); \
+   if (__ratelimit(&_rs))  \
+   dev_printk(KERN_DEBUG, dev, fmt, ##__VA_ARGS__);\
 } while (0)
 #else
 #define dev_dbg_ratelimited(dev, fmt, ...) \
-- 
1.8.3.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

[PATCH v3 2/3] drivers: Makefile: Extcon is a framework so bump it up

[George Cherian]

Bump up the order, since extcon is a framework and needed by
other drivers. With the previous order it failed to detect
extcon device in DWC3 when both were compiled built-in.

Signed-off-by: George Cherian 
---
 drivers/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index ab93de8..4573b8d 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -49,6 +49,7 @@ obj-y += char/
 obj-y  += gpu/
 
 obj-$(CONFIG_CONNECTOR)+= connector/
+obj-$(CONFIG_EXTCON)   += extcon/
 
 # i810fb and intelfb depend on char/agp/
 obj-$(CONFIG_FB_I810)   += video/i810/
@@ -145,7 +146,6 @@ obj-$(CONFIG_VIRT_DRIVERS)  += virt/
 obj-$(CONFIG_HYPERV)   += hv/
 
 obj-$(CONFIG_PM_DEVFREQ)   += devfreq/
-obj-$(CONFIG_EXTCON)   += extcon/
 obj-$(CONFIG_MEMORY)   += memory/
 obj-$(CONFIG_IIO)  += iio/
 obj-$(CONFIG_VME_BUS)  += vme/
-- 
1.8.1.4

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

Re: [PATCH v3 1/1] dev-core: fix build break when DEBUG is enabled

[Greg KH]

On Wed, Aug 28, 2013 at 10:50:31AM -0700, Sarah Sharp wrote:
> Any objections to queuing this patch through Greg's usb-next tree?  I've
> already sent the 2/2 patch, which will cause build breakage without this
> patch.
> 
> Changes since v2:
>  - Fixed a checkpatch warning caused by a comment in a macro.
> 
> Sarah Sharp
> 
> >88<
> 
> From: Dmitry Kasatkin 
> 
> When DEBUG is defined, dev_dbg_ratelimited uses dynamic debug data
> structures even when CONFIG_DYNAMIC_DEBUG is not defined.
> It leads to build break.
> For example, when I try to use dev_dbg_ratelimited in USB code and
> CONFIG_USB_DEBUG is enabled, but CONFIG_DYNAMIC_DEBUG is not, I get:
> 
>   CC [M]  drivers/usb/host/xhci-ring.o
>   drivers/usb/host/xhci-ring.c: In function ‘xhci_queue_intr_tx’:
>   drivers/usb/host/xhci-ring.c:3059:3: error: implicit declaration of 
> function ‘DEFINE_DYNAMIC_DEBUG_METADATA’ 
> [-Werror=implicit-function-declaration]
>   drivers/usb/host/xhci-ring.c:3059:3: error: ‘descriptor’ undeclared (first 
> use in this function)
>   drivers/usb/host/xhci-ring.c:3059:3: note: each undeclared identifier is 
> reported only once for each function it appears in
>   drivers/usb/host/xhci-ring.c:3059:3: error: implicit declaration of 
> function ‘__dynamic_pr_debug’ [-Werror=implicit-function-declaration]
>   drivers/usb/host/xhci-ring.c: In function ‘xhci_queue_isoc_tx_prepare’:
>   drivers/usb/host/xhci-ring.c:3847:3: error: ‘descriptor’ undeclared (first 
> use in this function)
>   cc1: some warnings being treated as errors
>   make[2]: *** [drivers/usb/host/xhci-ring.o] Error 1
>   make[1]: *** [drivers/usb/host] Error 2
>   make: *** [drivers/usb/] Error 2
> 
> This patch separates definition for CONFIG_DYNAMIC_DEBUG and DEBUG cases.
> 
> [Note, Sarah moved the comment above the macro to avoid checkpatch
> warnings.]
> 
> Signed-off-by: Dmitry Kasatkin 
> Signed-off-by: Sarah Sharp 

Acked-by: Greg Kroah-Hartman 
--
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 v3 3/3] ARM: dts: dra7-evm: Add extcon nodes for USB ID pin detection

[Sergei Shtylyov]

On 08/28/2013 09:33 PM, George Cherian wrote:


Add
-extcon nodes for USB ID pin detection.
-i2c nodes.
-pcf nodes to which USB ID pin is connected.



Signed-off-by: George Cherian 
---
  arch/arm/boot/dts/dra7-evm.dts | 50 +-
  1 file changed, 49 insertions(+), 1 deletion(-)



diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index acd3c09..8b0738a 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts

[...]

@@ -33,10 +44,47 @@
  };
  };

+&i2c1 {
+   clock-frequency = <40>;
+
+   gpio20: pcf8575@20 {


ePAPR was talking about the node naming, not about labelling. Back to the 
drawing board. ;-)



+   compatible = "ti,pcf8575";
+   reg = <0x20>;
+   n_latch = <0x4000>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&gpio6>;
+   interrupts = <11 2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpio21: pcf8575@21 {
+   compatible = "ti,pcf8575";
+   reg = <0x21>;
+   n_latch = <0x1408>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&pcf_20>;
+   interrupts = <14 2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+};
+


WBR, Sergei

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

Re: [PATCH] usb: phy: samsung-usb2: Toggle HSIC GPIO from device tree

[Julius Werner]

I've tried to get the 3503 driver to work in my case for quite some
time, but ultimately gave up. For me, playing around with the load
order was not enough to solve all issues. When you try to build a
permanent, clean solution for this, you should definitely also test
the case where the hub has already been initialized and configured by
firmware before the kernel booted, because that brought on another
bunch of issues for me.

I think it ultimately only works reliably when you first reset the
hub, then reset the HSIC port on the PHY side before the USB core gets
a chance to talk to it again (thus one of the drivers needs to be
directly connected to and call the other).
--
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: [alsa-devel] Buffer size for ALSA USB PCM audio

[Alan Stern]

On Wed, 28 Aug 2013, Clemens Ladisch wrote:

> Sorry, what I said applies more to explicit sync endpoints.  When using
> implicit sync, a playback URB is submitted for each completed capture
> URB, with the number of samples per packet identical to the
> corresponding capture packet, so the parameters must be identical.

Got it.  Below is an updated patch.

James, the problem you encountered was most likely a result of the
faulty treatment of capture endpoints that Clemens pointed out.  It was
quite obvious in the usbmon traces that the unpatched driver used 8
packets per URB whereas the patched driver used 22.  This updated patch
should fix that problem.

Alan Stern



Index: usb-3.11/sound/usb/usbaudio.h
===
--- usb-3.11.orig/sound/usb/usbaudio.h
+++ usb-3.11/sound/usb/usbaudio.h
@@ -55,7 +55,6 @@ struct snd_usb_audio {
struct list_head mixer_list;/* list of mixer interfaces */
 
int setup;  /* from the 'device_setup' module param 
*/
-   int nrpacks;/* from the 'nrpacks' module param */
bool autoclock; /* from the 'autoclock' module param */
 
struct usb_host_interface *ctrl_intf;   /* the audio control interface 
*/
Index: usb-3.11/sound/usb/card.c
===
--- usb-3.11.orig/sound/usb/card.c
+++ usb-3.11/sound/usb/card.c
@@ -79,7 +79,6 @@ static bool enable[SNDRV_CARDS] = SNDRV_
 /* Vendor/product IDs for this card */
 static int vid[SNDRV_CARDS] = { [0 ... (SNDRV_CARDS-1)] = -1 };
 static int pid[SNDRV_CARDS] = { [0 ... (SNDRV_CARDS-1)] = -1 };
-static int nrpacks = 8;/* max. number of packets per urb */
 static int device_setup[SNDRV_CARDS]; /* device parameter for this card */
 static bool ignore_ctl_error;
 static bool autoclock = true;
@@ -94,8 +93,6 @@ module_param_array(vid, int, NULL, 0444)
 MODULE_PARM_DESC(vid, "Vendor ID for the USB audio device.");
 module_param_array(pid, int, NULL, 0444);
 MODULE_PARM_DESC(pid, "Product ID for the USB audio device.");
-module_param(nrpacks, int, 0644);
-MODULE_PARM_DESC(nrpacks, "Max. number of packets per URB.");
 module_param_array(device_setup, int, NULL, 0444);
 MODULE_PARM_DESC(device_setup, "Specific device setup (if needed).");
 module_param(ignore_ctl_error, bool, 0444);
@@ -374,7 +371,6 @@ static int snd_usb_audio_create(struct u
chip->dev = dev;
chip->card = card;
chip->setup = device_setup[idx];
-   chip->nrpacks = nrpacks;
chip->autoclock = autoclock;
chip->probing = 1;
 
@@ -756,10 +752,6 @@ static struct usb_driver usb_audio_drive
 
 static int __init snd_usb_audio_init(void)
 {
-   if (nrpacks < 1 || nrpacks > MAX_PACKS) {
-   printk(KERN_WARNING "invalid nrpacks value.\n");
-   return -EINVAL;
-   }
return usb_register(&usb_audio_driver);
 }
 
Index: usb-3.11/sound/usb/endpoint.h
===
--- usb-3.11.orig/sound/usb/endpoint.h
+++ usb-3.11/sound/usb/endpoint.h
@@ -12,6 +12,8 @@ int snd_usb_endpoint_set_params(struct s
snd_pcm_format_t pcm_format,
unsigned int channels,
unsigned int period_bytes,
+   unsigned int period_frames,
+   unsigned int buffer_periods,
unsigned int rate,
struct audioformat *fmt,
struct snd_usb_endpoint *sync_ep);
Index: usb-3.11/sound/usb/card.h
===
--- usb-3.11.orig/sound/usb/card.h
+++ usb-3.11/sound/usb/card.h
@@ -2,11 +2,11 @@
 #define __USBAUDIO_CARD_H
 
 #define MAX_NR_RATES   1024
-#define MAX_PACKS  20
+#define MAX_PACKS  6   /* per URB */
 #define MAX_PACKS_HS   (MAX_PACKS * 8) /* in high speed mode */
-#define MAX_URBS   8
+#define MAX_URBS   12
 #define SYNC_URBS  4   /* always four urbs for sync */
-#define MAX_QUEUE  24  /* try not to exceed this queue length, in ms */
+#define MAX_QUEUE  18  /* try not to exceed this queue length, in ms */
 
 struct audioformat {
struct list_head list;
@@ -87,6 +87,7 @@ struct snd_usb_endpoint {
unsigned int phase; /* phase accumulator */
unsigned int maxpacksize;   /* max packet size in bytes */
unsigned int maxframesize;  /* max packet size in frames */
+   unsigned int max_urb_frames;/* max URB size in frames */
unsigned int curpacksize;   /* current packet size in bytes (for 
capture) */
unsigned int curframesize;  /* current packet size in frames (for 
capture) */
unsigned int syncmaxsize;   /* sync endpoint packet size */
@@ -116,6 +117,8 @@

Re: [PATCH v2 1/3] usb: add is_usb_mouse routine and remote wakeup quirk

[Alan Stern]

On Wed, 28 Aug 2013, Greg Kroah-Hartman wrote:

> On Wed, Aug 28, 2013 at 01:13:46PM -0400, Alan Stern wrote:
> > On Wed, 28 Aug 2013, Greg Kroah-Hartman wrote:
> > 
> > > > [Q] Why the special devices are only mice? Would high speed devices
> > > > such as 3G modem or USB Bluetooth adapter trigger this issue?
> > > > - Current this sensitivity is only confined to devices that use Pixart
> > > >   controllers. This controller is designed for use with LS mouse
> > > > devices only. We have not observed any other devices failing. There
> > > > may be a small risk for other devices also but this patch (reset
> > > > device in resume phase) will cover the cases if required.
> > > 
> > > Then just do this "quirk" for Pixart controller devices.  Don't penalize
> > > everyone else.
> > 
> > Is there any way to detect when a device uses a Pixart controller?  I 
> > don't see how you could tell.
> 
> Vendor device id should tell you what you need to know, right?

Not necessarily.  Manufacturers often get their USB hardware from other
suppliers and then overwrite the vendor and product IDs in the firmware
with their own.

Of course, I don't know if that's true in this case.  The guys at AMD 
should be able to tell easily enough; they have a bunch of these mice 
to test with.

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 v3] xHCI: Fixing xhci_readl definition and function call

[Dan Carpenter]

On Wed, Aug 28, 2013 at 08:39:06PM +0530, Kumar Gaurav wrote:
> On Wednesday 28 August 2013 12:43 PM, Dan Carpenter wrote:
> >On Mon, Aug 26, 2013 at 07:38:57AM +0530, Kumar Gaurav wrote:
> >>This patch redefine function xhci_readl.xhci_readl function doesn't use 
> >>xhci_hcd argument.
> >>Hence there is no need of keeping it in the function arguments.
> >>
> >>Redefining this function breaks other functions which calls this function.
> >>This phatch also correct those calls in xhci driver.
> >>
> >>Signed-off-by: Kumar Gaurav 
> >>---
> >Could you put a list of changes since v2 here?:
> >
> >v3:  blah blah changelog mostly.
> >
> >Also this doesn't apply for me against linux-next.
> >
> >regards,
> >dan carpenter
> >
> There's no change from v2. I was sending the same patch again
> because the last one was lacking good description and i was told (or
> as i understood) that if I'm sending the same patch or patch for the
> same purpose as previous then i should increment version so i did.

Put:
v2: no change.  just the changelog.

Otherwise we have to look for the change.

> 
> I had developed this patch against linux-git, haven't tested that on
> linux-next as i haven't cloned  linux-next yet.
> 
> I've started cloning linux-next and as it's not applying on
> linux-next, I'll try it on linux-next (once i cloned it)  and will
> send again.

Yep.  Cleanups should be done against linux-next.

regards,
dan carpenter

--
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: Memory synchronization vs. interrupt handlers

[Alan Stern]

Russell, Peter, and Ingo:

Can you folks enlighten us regarding this issue for some common 
architectures?

On Tue, 27 Aug 2013, Paul E. McKenney wrote:

> On Mon, Aug 26, 2013 at 11:49:15AM -0400, Alan Stern wrote:
> > David and Paul:
> > 
> > Here's a question that doesn't seem to be answered in 
> > Documentation/memory-barriers.txt.  Are memory accesses within an 
> > interrupt handler synchronized with respect to interrupts?
> > 
> > In more detail, suppose we have an interrupt handler that uses a memory
> > variable A.  The device attached to the IRQ line sends two interrupt
> > requests, and we get:
> > 
> > CPU 0   CPU 1
> > -   -
> > Receive IRQ
> > Call the interrupt handler
> > Write A
> > Finish IRQ processing
> > 
> > Receive IRQ
> > Call the interrupt handler
> > Read A
> > Finish IRQ processing
> > 
> > Is CPU 0's write to A guaranteed to be visible on CPU 1?  Given that 
> > interrupts on an IRQ line are serialized, and that IRQ processing must 
> > involve some amount of memory barriers, I would expect the answer to be 
> > Yes.
> 
> I have no idea.  I would hope that it did, but a lot depends on how or
> whether the end-of-interrupt processing is handled by the I/O hardware.

Isn't this the sort of thing the kernel should guarantee?  The
low-level code that fields interrupts ought to do the equivalent of an
"acquire" barrier at the start and a "release" barrier at the end, so
that operations by the higher-level handlers don't "leak out".

For example, if the low-level code would lock and unlock a spinlock at 
the start and end of the interrupt, that would be more than sufficient 
(provided it always used the same spinlock for the same IRQ line).

Of course, drivers needing this behavior can always use their own 
spinlocks.  Still, it seems like this ought to fall under the purview 
of the core kernel.

> I believe that we need to ask the architecture maintainers.  And maybe
> also someone who knows about the devices in question.

The devices aren't relevant here because the variable A resides in
main memory, not on the device.  What matter is, as you say, the
architectural code.

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: 3.4.4: disabling irq

[Alan Stern]

On Wed, 28 Aug 2013, Udo van den Heuvel wrote:

> On 2013-08-27 19:43, Alan Stern wrote:
> >>>   rmmod ohci-pci
> >>>   modprobe dummy-irq irq=18
> >>>
> >>> and see if the IRQ line gets disabled after that.
> >>
> >> Can I actually use that irq/ports that way? (as with no usage the
> >> problem does not occur)
> > 
> > No, if you unload the ohci-hcd driver then the webcam won't be used.  
> > Are you certain that merely stopping the daemon program will prevent 
> > the problem?
> 
> Quite certain but retesting can confirm that.

Maybe without activity, the OHCI controller goes into suspend.  You can 
prevent it by doing:

echo on >/sys/bus/pci/devices/:00:13.1/usb?/power/control

If you do this and stop using the webcam, but leave ohci-hcd bound to
the controller, does the problem occur?

> >> No ohci_pci, is that a problem?
> > 
> > Sorry, for 3.10 it should be ohci_hcd.  In 3.11 it changed to ohci_pci.
> 
> 3.10.9 is the latest here.
> 
> > Have you tried getting a USB-2 hub and plugging the webcam into it?  
> > That will make a good test: You'll be able to use the webcam without 
> > it affecting the ohci-hcd driver.
> 
> Not yet but I'll have hubs to test with soon.
> 
> > As a second test, you can try plugging everything _except_ the webcam 
> > into the hub.
> 
> To see if the webcam itself is a factor. I see.

By the way, since you switched to the new computer, are there any 
devices attached to this USB bus other than the webcam?

Also, at one point you had a second webcam attached to a different OHCI
controller, as well as a Bluetooth device and a USB-serial device.  
Are they still present?

> This afternoon I found a 3.8.10 kernel with the disabled irq 18 and some
> ^@^@^@ characters on teh console.
> After I did:
> 
> service motion stop
> rmmod pwc
> echo :00:13.0 >/sys/bus/pci/drivers/ohci_hcd/unbind
> echo :00:13.0 >/sys/bus/pci/drivers/ohci_hcd/bind
> modprobe pwc
> service motion start
> 
> the ^@^@^@ appeared to stop.
> I'll try to watch /proc/interrupts to see if the ^@^@ correlate with
> i8042 interrupts.

Maybe they are related somehow, but I have no idea how.

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: [Bug] [Sony VAIO SVT15117CXS] USB 2.0 ports not working with any USB device

[Alan Stern]

On Tue, 27 Aug 2013, Kevin Archer wrote:

> rmmod xhci-hcd yields:
> libkmod: ERROR ../libkmod/libkmod-module.c:753
> kmod_module_remove_module: could not remove 'xhci_hcd': No such file
> or directory
> Error: could not remove module xhci-hcd: No such file or directory

Oops.  Apparently the driver was not built as an unloadable module.
That's okay.  You can get more or less the same effect by doing:

echo :00:14.0 >/sys/bus/pci/drivers/xhci-hcd/unbind

This will prevent the Logitech trackball from working, but that's okay 
for a short test.  After the test, you can return to normal operation 
by issuing the same command with "bind" in place of "unbind".

> as far as the 2.6.39 version
> I attached dmesg and udev - I was using a usb thumb drive and an
> aluratek usb bluetooth receiver to test with

Yes, good, that all looks normal.

There's one more thing to try (maybe I asked this earlier).  Back in a
3.1 kernel (a later version, like 3.10, would be better), while a
device is plugged in and there's no response, run these two commands:

lsusb -v -s 1:2
lsusb -v -s 2:2

as root and let's see what you get.

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: Memory synchronization vs. interrupt handlers

[H. Peter Anvin]

On 08/28/2013 12:16 PM, Alan Stern wrote:
> Russell, Peter, and Ingo:
> 
> Can you folks enlighten us regarding this issue for some common 
> architectures?
> 

On x86, IRET is a serializing instruction; it guarantees hard
serialization of absolutely everything.

I would expect architectures that have weak memory ordering to put
appropriate barriers in the IRQ entry/exit code.

-hpa

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

Re: Bug report: 045e:0721 Microsoft LifeCam NX-3000 not detected

[Alan Stern]

On Wed, 28 Aug 2013, Jürgen Liebmann wrote:

> In the attachment the both usbmon traces:
> 
> usbmon-reverted.out  (camera works ok)
> usbmon-74a6af256648  (camera fails)

This is very strange indeed.  Here's where the two traces start to get
different results.  In the kernel with the commit reverted:

88023073f9c0 742830275 S Co:2:009:0 s 01 0b  0001  0
88023073f9c0 742830331 C Co:2:009:0 0 0
88023073f9c0 742830336 S Ci:2:009:0 s a1 87 0100 0001 001a 26 <
88023073f9c0 742830583 C Ci:2:009:0 -32 0
88023073f9c0 742830592 S Ci:2:009:0 s a1 81 0100 0001 001a 26 <
88023073f9c0 742831081 C Ci:2:009:0 0 26 = 01000101 15160500  
 0018 0300fc03 
88023073fc00 742831291 S Ci:2:009:0 s 80 06 0302 0409 00ff 255 <
88023073fc00 742831583 C Ci:2:009:0 0 52 = 34034d00 69006300 72006f00 
73006f00 66007400 20004c00 69006600 65004300

This shows a successful Set-Interface request, followed by an
unsuccessful class-specific request and a successful class-specific
request which returns 26 data bytes.  Following that, the computer
reads a 52-byte string descriptor.

Now here's the same thing with the commit present:

880233820f00 1078447196 S Co:2:008:0 s 01 0b  0001  0
880233820f00 1078447253 C Co:2:008:0 0 0
880233739cc0 1078447266 S Ci:2:008:0 s a1 87 0100 0001 001a 26 <
880233739cc0 1078447523 C Ci:2:008:0 -32 0
880233739cc0 1078447539 S Ci:2:008:0 s a1 81 0100 0001 001a 26 <
880233739cc0 1078447898 C Ci:2:008:0 -32 0
880233739a80 1078448123 S Ci:2:008:0 s 80 06 0302 0409 00ff 255 <
880233739a80 1078448542 C Ci:2:008:0 0 26 = 01000101 15160500  
 0018 0300fc03 
880233739a80 1078448556 S Ci:2:008:0 s 80 06 0302 0409 00ff 255 <
880233739a80 1078448907 C Ci:2:008:0 0 52 = 34034d00 69006300 72006f00 
73006f00 66007400 20004c00 69006600 65004300

This starts with the same Set-Interface request and the same
unsuccessful class-specific request.  But the second class-specific
request also fails, and the Get-String-Descriptor returns the 26 bytes
of class-specific data!  The Get-String-Descriptor request is repeated,
and this time the device sends the correct 52-byte string descriptor.  
After that everything seems to return to normal.

I don't understand this at all.  There is no way that commit could
cause the driver to malfunction like this.  The only thing I can think
of is some sort of hardware problem, either in the computer or (less
likely) in the camera.

Can you try testing this on a different computer?

Alan Stern

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

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sarah Sharp]

On Wed, Aug 28, 2013 at 07:39:14PM +0200, Sedat Dilek wrote:
> On Wed, Aug 28, 2013 at 7:24 PM, Dmitry Kasatkin  
> wrote:
> Still noone answered me why "drivers/usb/host/xhci-ring.c" does NOT
> include  (dev_info_ratelimited() and other defines).
> I am expecting that... even I see...
> 
>   drivers/usb/host/.xhci-ring.o.cmd:715:  include/linux/device.h \
> 
> ...where I don't know why this happens.
> 
> ( For me this is a bit more important than """trimming""" my
> responses, I keep the history... )
> 
> - Sedat -
> 
> P.S.: List of includes in xhci-ring.c
> 
> $ grep ^'#include' -nr drivers/usb/host/xhci-ring.c
> 67:#include 
> 68:#include 
> 69:#include "xhci.h"
> 70:#include "xhci-trace.h"

Because a header that xhci-ring.c uses includes device.h instead.

drivers/usb/host/xhci/xhci-ring.c includes
drivers/usb/host/xhci.h which includes
include/linux/usb.h which includes
include/linux/device.h

All USB host controllers depend on including usb.h, so I don't think
there's a need for the driver to explicitly include device.h.

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

Re: [PATCH] USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700 Device Driver Support

[David Miller]

From: liujunliang_...@163.com
Date: Sat, 24 Aug 2013 19:26:00 +0800

> From: liujl 

Your proper name is not "liujl", please put something more reasonable
here and also in your Signoff.

Also, integrate Joe Perches's white space fixes into this patch as part
of your resubmission.

Thank you.
--
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: xhci-plat: Enable USB 2.0 hardware LPM support for platform xHCs

[Sarah Sharp]

On Mon, Aug 26, 2013 at 07:37:56PM +, Paul Zimmerman wrote:
> > From: Sarah Sharp [mailto:sarah.a.sh...@linux.intel.com]
> > Sent: Monday, August 26, 2013 12:14 PM
> > 
> > On Thu, Aug 22, 2013 at 05:11:49AM +, Paul Zimmerman wrote:
> > > > From: Julius Werner
> > > > Sent: Wednesday, August 21, 2013 9:22 PM
> > > >
> > > > > You need the USB 2.0 spec errata from 2011-11 that describes the 
> > > > > changes
> > > > > made for BESL as well.  It's in the USB2-LPM-Errata-final.pdf and
> > > > > USB2_LinkPowerMangement_ECN[final].pdf files in this zip file:
> > > > >
> > > > > http://www.usb.org/developers/docs/usb_20_070113.zip
> > > > >
> > > > > I agree though, it's all a confusing mess for documentation on USB 2.0
> > > > > Link PM.
> > > >
> > > > Thanks, I hadn't found that first one yet. Do you also have a link for
> > > > the updated XHCI specification or a separate erratum document
> > > > describing the PORTHLPMC register referenced in the BESL patches (they
> > > > don't exist on DWC3, but I'm still curious)?
> > >
> > > Just to set the record straight :)
> > >
> > > The PORTHLPMC registers do exist on DWC3, starting with the 1.90a version
> > > of the core or thereabouts. They only supported the HIRD flavor of LPM,
> > > though. Only fairly recently has support for BESL been added, around
> > > version 2.41a or so.
> > 
> > And the 2.41a version that supports BESL properly sets the BLC flag in
> > the USB 2.0 Protocol extended capabilities for all the USB 2.0 ports?
> > Has this functionality been well-tested?
> 
> In 2.41a it is described as an "early adopter" feature in the databook,
> and no mention is made of the BLC flag. So the answer there is "maybe".
> Starting with 2.50a it is a full-fledged feature and the databook does
> describe the BLC flag.

So the 2.41a has BESL support, but may not set the BLC flag.  What
happens if we use the HIRD encoding instead?  Will things break?  It
seems like we would need to disable USB 2.0 LPM on that host all
together, if it expects BESL encoding, but advertises HIRD encoding.

> So it may be safer to say that the feature is present starting with 2.50a.

Is there a way we can tell the difference between a 2.41a xHCI host and
a 2.50a host?  If so, we can add a quirk to disable LPM on the 2.41a
host.

> In 2.51a it has been well-tested in simulation. In actual hardware, it
> has only been briefly tested in an ad-hoc sort of way, since none of the
> standard drivers in the market support the feature yet, as far as we know.
> 
> Once the support is fully working in the Linux driver we can try testing
> it there.

Can you please test Julius' patch on the 2.41a, 2.50a, and 2.51a hosts?
Please test against usb-next, since that includes a fix for the BESL
patches.

I'm not going to merge this unless we know it's not going to break those
earlier host controllers.  Besides, at this point, it's too late to
include this patch in 3.12.  I already got bitten yesterday by trying to
push patches this late, and I'm not doing that again.

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

[PATCH 2/2] xhci: Fix warning introduced by disabling runtime PM.

[Sarah Sharp]

The 0day build server caught a new build warning that is triggered when
CONFIG_USB_DEFAULT_PERSIST is turned on:

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
for-usb-next
head:   0730d52a86919300a39a2be37f6c140997dfb82f
commit: c8476fb855434c733099079063990e5bfa7ecad6 [1/3] usb: xhci: Disable 
runtime PM suspend for quirky controllers
config: i386-randconfig-r6-0826 (attached as .config)

All warnings:

   drivers/usb/host/xhci.c: In function 'xhci_free_dev':
>> drivers/usb/host/xhci.c:3560:17: warning: unused variable 'dev' 
>> [-Wunused-variable]
 struct device *dev = hcd->self.controller;
^
   drivers/usb/host/xhci.c: In function 'xhci_alloc_dev':
>> drivers/usb/host/xhci.c:3648:17: warning: unused variable 'dev' 
>> [-Wunused-variable]
 struct device *dev = hcd->self.controller;
^

vim +/dev +3560 drivers/usb/host/xhci.c

  3554   * disabled.  Free any HC data structures associated with that device.
  3555   */
  3556  void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
  3557  {
  3558  struct xhci_hcd *xhci = hcd_to_xhci(hcd);
  3559  struct xhci_virt_device *virt_dev;
> 3560  struct device *dev = hcd->self.controller;
  3561  unsigned long flags;
  3562  u32 state;
  3563  int i, ret;
  3564
  3565  #ifndef CONFIG_USB_DEFAULT_PERSIST
  3566  /*
  3567   * We called pm_runtime_get_noresume when the device was 
attached.
  3568   * Decrement the counter here to allow controller to runtime 
suspend
  3569   * if no devices remain.
  3570   */
  3571  if (xhci->quirks & XHCI_RESET_ON_RESUME)
  3572  pm_runtime_put_noidle(dev);
  3573  #endif
  3574
...
  3641  /*
  3642   * Returns 0 if the xHC ran out of device slots, the Enable Slot command
  3643   * timed out, or allocating memory failed.  Returns 1 on success.
  3644   */
  3645  int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
  3646  {
  3647  struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> 3648  struct device *dev = hcd->self.controller;
  3649  unsigned long flags;
  3650  int timeleft;
  3651  int ret;

Fix this.

Signed-off-by: Sarah Sharp 
Cc: Shawn Nematbakhsh 
---
 drivers/usb/host/xhci.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 349d346..49b6edb 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3557,7 +3557,6 @@ void xhci_free_dev(struct usb_hcd *hcd, struct usb_device 
*udev)
 {
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_virt_device *virt_dev;
-   struct device *dev = hcd->self.controller;
unsigned long flags;
u32 state;
int i, ret;
@@ -3569,7 +3568,7 @@ void xhci_free_dev(struct usb_hcd *hcd, struct usb_device 
*udev)
 * if no devices remain.
 */
if (xhci->quirks & XHCI_RESET_ON_RESUME)
-   pm_runtime_put_noidle(dev);
+   pm_runtime_put_noidle(hcd->self.controller);
 #endif
 
ret = xhci_check_args(hcd, udev, NULL, 0, true, __func__);
@@ -3645,7 +3644,6 @@ static int xhci_reserve_host_control_ep_resources(struct 
xhci_hcd *xhci)
 int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
 {
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
-   struct device *dev = hcd->self.controller;
unsigned long flags;
int timeleft;
int ret;
@@ -3705,7 +3703,7 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device 
*udev)
 * suspend if there is a device attached.
 */
if (xhci->quirks & XHCI_RESET_ON_RESUME)
-   pm_runtime_get_noresume(dev);
+   pm_runtime_get_noresume(hcd->self.controller);
 #endif
 
/* Is this a LS or FS device under a HS hub? */
-- 
1.8.3.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

[Pull Request] xhci: Fix build breakage and new warnings.

[Sarah Sharp]

The following changes since commit 752e69555d107853043cb9405250c9387b26e708:

  Merge tag 'usb-for-v3.12-part2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next 
(2013-08-27 14:07:31 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
tags/for-usb-next-2013-08-27-15-07

for you to fetch changes up to e7ecf069d4730d5ec4cc91a531eb85c9604142bd:

  xhci: Fix warning introduced by disabling runtime PM. (2013-08-28 10:55:47 
-0700)


xhci: Fix build breakage and new warnings.

Hi Greg,

This first patch should fix the build breakage Sedat Dilek reported.
Apologizes for not including this patch before commit
0730d52a86919300a39a2be37f6c140997dfb82f "xhci:prevent "callbacks suppressed"
when debug is not enabled"

The second patch fixes a new build warning introduced by commit
c8476fb855434c733099079063990e5bfa7ecad6 "usb: xhci: Disable runtime PM suspend
for quirky controllers", which was caught by the 0day build system.

Sarah Sharp


Dmitry Kasatkin (1):
  dev-core: fix build break when DEBUG is enabled

Sarah Sharp (1):
  xhci: Fix warning introduced by disabling runtime PM.

 drivers/usb/host/xhci.c |6 ++
 include/linux/device.h  |   16 +---
 2 files changed, 15 insertions(+), 7 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] dev-core: fix build break when DEBUG is enabled

[Sarah Sharp]

From: Dmitry Kasatkin 

When DEBUG is defined, dev_dbg_ratelimited uses dynamic debug data
structures even when CONFIG_DYNAMIC_DEBUG is not defined.
It leads to build break.
For example, when I try to use dev_dbg_ratelimited in USB code and
CONFIG_USB_DEBUG is enabled, but CONFIG_DYNAMIC_DEBUG is not, I get:

  CC [M]  drivers/usb/host/xhci-ring.o
  drivers/usb/host/xhci-ring.c: In function ‘xhci_queue_intr_tx’:
  drivers/usb/host/xhci-ring.c:3059:3: error: implicit declaration of function 
‘DEFINE_DYNAMIC_DEBUG_METADATA’ [-Werror=implicit-function-declaration]
  drivers/usb/host/xhci-ring.c:3059:3: error: ‘descriptor’ undeclared (first 
use in this function)
  drivers/usb/host/xhci-ring.c:3059:3: note: each undeclared identifier is 
reported only once for each function it appears in
  drivers/usb/host/xhci-ring.c:3059:3: error: implicit declaration of function 
‘__dynamic_pr_debug’ [-Werror=implicit-function-declaration]
  drivers/usb/host/xhci-ring.c: In function ‘xhci_queue_isoc_tx_prepare’:
  drivers/usb/host/xhci-ring.c:3847:3: error: ‘descriptor’ undeclared (first 
use in this function)
  cc1: some warnings being treated as errors
  make[2]: *** [drivers/usb/host/xhci-ring.o] Error 1
  make[1]: *** [drivers/usb/host] Error 2
  make: *** [drivers/usb/] Error 2

This patch separates definition for CONFIG_DYNAMIC_DEBUG and DEBUG cases.

[Note, Sarah moved the comment above the macro to avoid checkpatch
warnings.]

Signed-off-by: Dmitry Kasatkin 
Signed-off-by: Sarah Sharp 
Acked-by: Greg Kroah-Hartman 
---
 include/linux/device.h | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index 22b546a..7d960d5 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1099,7 +1099,8 @@ do {  
\
dev_level_ratelimited(dev_notice, dev, fmt, ##__VA_ARGS__)
 #define dev_info_ratelimited(dev, fmt, ...)\
dev_level_ratelimited(dev_info, dev, fmt, ##__VA_ARGS__)
-#if defined(CONFIG_DYNAMIC_DEBUG) || defined(DEBUG)
+#if defined(CONFIG_DYNAMIC_DEBUG)
+/* descriptor check is first to prevent flooding with "callbacks suppressed" */
 #define dev_dbg_ratelimited(dev, fmt, ...) \
 do {   \
static DEFINE_RATELIMIT_STATE(_rs,  \
@@ -1108,8 +1109,17 @@ do { 
\
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT) &&\
__ratelimit(&_rs))  \
-   __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
-  ##__VA_ARGS__);  \
+   __dynamic_dev_dbg(&descriptor, dev, fmt,\
+ ##__VA_ARGS__);   \
+} while (0)
+#elif defined(DEBUG)
+#define dev_dbg_ratelimited(dev, fmt, ...) \
+do {   \
+   static DEFINE_RATELIMIT_STATE(_rs,  \
+ DEFAULT_RATELIMIT_INTERVAL,   \
+ DEFAULT_RATELIMIT_BURST); \
+   if (__ratelimit(&_rs))  \
+   dev_printk(KERN_DEBUG, dev, fmt, ##__VA_ARGS__);\
 } while (0)
 #else
 #define dev_dbg_ratelimited(dev, fmt, ...) \
-- 
1.8.3.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] usb: xhci-plat: Enable USB 2.0 hardware LPM support for platform xHCs

[Paul Zimmerman]

> From: Sarah Sharp [mailto:sarah.a.sh...@linux.intel.com]
> Sent: Wednesday, August 28, 2013 2:52 PM
> 
> On Mon, Aug 26, 2013 at 07:37:56PM +, Paul Zimmerman wrote:
> > > From: Sarah Sharp [mailto:sarah.a.sh...@linux.intel.com]
> > > Sent: Monday, August 26, 2013 12:14 PM
> > >
> > > On Thu, Aug 22, 2013 at 05:11:49AM +, Paul Zimmerman wrote:
> > > > > From: Julius Werner
> > > > > Sent: Wednesday, August 21, 2013 9:22 PM
> > > > >
> > > > > > You need the USB 2.0 spec errata from 2011-11 that describes the 
> > > > > > changes
> > > > > > made for BESL as well.  It's in the USB2-LPM-Errata-final.pdf and
> > > > > > USB2_LinkPowerMangement_ECN[final].pdf files in this zip file:
> > > > > >
> > > > > > http://www.usb.org/developers/docs/usb_20_070113.zip
> > > > > >
> > > > > > I agree though, it's all a confusing mess for documentation on USB 
> > > > > > 2.0
> > > > > > Link PM.
> > > > >
> > > > > Thanks, I hadn't found that first one yet. Do you also have a link for
> > > > > the updated XHCI specification or a separate erratum document
> > > > > describing the PORTHLPMC register referenced in the BESL patches (they
> > > > > don't exist on DWC3, but I'm still curious)?
> > > >
> > > > Just to set the record straight :)
> > > >
> > > > The PORTHLPMC registers do exist on DWC3, starting with the 1.90a 
> > > > version
> > > > of the core or thereabouts. They only supported the HIRD flavor of LPM,
> > > > though. Only fairly recently has support for BESL been added, around
> > > > version 2.41a or so.
> > >
> > > And the 2.41a version that supports BESL properly sets the BLC flag in
> > > the USB 2.0 Protocol extended capabilities for all the USB 2.0 ports?
> > > Has this functionality been well-tested?
> >
> > In 2.41a it is described as an "early adopter" feature in the databook,
> > and no mention is made of the BLC flag. So the answer there is "maybe".
> > Starting with 2.50a it is a full-fledged feature and the databook does
> > describe the BLC flag.
> 
> So the 2.41a has BESL support, but may not set the BLC flag.  What
> happens if we use the HIRD encoding instead?  Will things break?  It
> seems like we would need to disable USB 2.0 LPM on that host all
> together, if it expects BESL encoding, but advertises HIRD encoding.

I imagine things would break, but I don't know for sure. I don't have a
2.41a version of the core to test this with.

Maybe the LPM support should be disabled by default, and enabled with a
quirk? That seems safer to me.

> > So it may be safer to say that the feature is present starting with 2.50a.
> 
> Is there a way we can tell the difference between a 2.41a xHCI host and
> a 2.50a host?  If so, we can add a quirk to disable LPM on the 2.41a
> host.

Once you know it is a Synopsys core, there is a vendor-specific register
that shows the version. But that register is at offset 0xC120, which is
above the normal xHCI register space I believe, so we may not be able to
depend on it being accessible. And you have the problem of how to
determine if it is a Synopsys core to begin with.

So IMHO, having LPM disabled by default, and enabled with a quirk based
on the PCI Vendor/Product ID, or a DT attribute for platform devices,
would be the way to go.

> > In 2.51a it has been well-tested in simulation. In actual hardware, it
> > has only been briefly tested in an ad-hoc sort of way, since none of the
> > standard drivers in the market support the feature yet, as far as we know.
> >
> > Once the support is fully working in the Linux driver we can try testing
> > it there.
> 
> Can you please test Julius' patch on the 2.41a, 2.50a, and 2.51a hosts?
> Please test against usb-next, since that includes a fix for the BESL
> patches.

As I said, I don't have the 2.41a version available to test. I do have
2.50a and 2.60a available, so I can try those.

-- 
Paul

--
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,stable] net: usb: Add HP hs2434 device to ZLP exception table

[David Miller]

From: Rob Gardner 
Date: Sun, 25 Aug 2013 18:29:13 -0600

> From 018343ce2e679d97283fb51da25c43aa876d087a Mon Sep 17 00:00:00 2001
> From: Rob Gardner 
> Date: Sun, 25 Aug 2013 16:02:23 -0600
> Subject: [PATCH net,stable] net: usb: Add HP hs2434 device to ZLP exception 
> table
> 
> This patch adds another entry (HP hs2434 Mobile Broadband) to the list
> of exceptional devices that require a zero length packet in order to
> function properly. This list was added in commit 844e88f0. The hs2434
> is manufactured by Sierra Wireless, who also produces the MC7710,
> which the ZLP exception list was created for in the first place. So
> hopefully it is just this one producer's devices that will need this
> workaround.
> 
> Tested on a DM1-4310NR HP notebook, which does not function without this
> change.
> 
> Signed-off-by: Rob Gardner 

Applied and queued up for -tablt, thanks.

On the topic of dealing with detection of this issue, how harmful is the
workaround on chips that don't need it?  Will the driver not work in that
case?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Pull Request] xhci: Fix build breakage and new warnings.

[Greg Kroah-Hartman]

On Wed, Aug 28, 2013 at 03:15:14PM -0700, Sarah Sharp wrote:
> The following changes since commit 752e69555d107853043cb9405250c9387b26e708:
> 
>   Merge tag 'usb-for-v3.12-part2' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next 
> (2013-08-27 14:07:31 -0700)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
> tags/for-usb-next-2013-08-27-15-07

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: [patch] dma: cppi41: off by one in desc_to_chan()

[Greg Kroah-Hartman]

On Wed, Aug 28, 2013 at 01:48:44PM +0300, Dan Carpenter wrote:
> The test here should be ">=" instead of ">".  The cdd->chan_busy[] array
> has "ALLOC_DECS_NUM" elements.
> 
> Signed-off-by: Dan Carpenter 
> Acked-by: Vinod Koul 
> ---
> Resending to Greg and the USB people because Vinod says this goes
> through the USB tree.

Really?  Ok, that seems odd, but whatever...

--
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: xhci-plat: Enable USB 2.0 hardware LPM support for platform xHCs

[Julius Werner]

> So the 2.41a has BESL support, but may not set the BLC flag.  What
> happens if we use the HIRD encoding instead?  Will things break?  It
> seems like we would need to disable USB 2.0 LPM on that host all
> together, if it expects BESL encoding, but advertises HIRD encoding.

Wait a second, just for clarity: are you saying that BESL-capable
controllers do not support the old HIRD mechanism and thus just break
on non-BESL aware OSes? I would've assumed that they somehow notice if
software doesn't write to the new register and automatically fall back
to HIRD... it seems like a weird decision to break hardware backwards
compatibility like that (after all, it would mean that Linux 3.10 and
older would also break on LynxPoint systems right now).
--
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,stable] net: usb: Add HP hs2434 device to ZLP exception table

[Rob Gardner]

On Wed, 28 Aug 2013 18:23:32 -0400 (EDT)
David Miller  wrote:

> From: Rob Gardner 
> Date: Sun, 25 Aug 2013 18:29:13 -0600
> 
> > From 018343ce2e679d97283fb51da25c43aa876d087a Mon Sep 17 00:00:00 2001
> > From: Rob Gardner 
> > Date: Sun, 25 Aug 2013 16:02:23 -0600
> > Subject: [PATCH net,stable] net: usb: Add HP hs2434 device to ZLP exception 
> > table
> > 
> > This patch adds another entry (HP hs2434 Mobile Broadband) to the list
> > of exceptional devices that require a zero length packet in order to
> > function properly. This list was added in commit 844e88f0. The hs2434
> > is manufactured by Sierra Wireless, who also produces the MC7710,
> > which the ZLP exception list was created for in the first place. So
> > hopefully it is just this one producer's devices that will need this
> > workaround.
> > 
> > Tested on a DM1-4310NR HP notebook, which does not function without this
> > change.
> > 
> > Signed-off-by: Rob Gardner 
> 
> Applied and queued up for -tablt, thanks.
> 
> On the topic of dealing with detection of this issue, how harmful is the
> workaround on chips that don't need it?  Will the driver not work in that
> case?


Bjørn says it could have a minor performance impact, but should not
cause any loss of functionality. I don't think there's any hard data on
what the performance cost might be but I know he would eventually like
to get rid of the exception list and live with the possible performance
impact if it means functionality for more devices.


-- 
Rob Gardner 
--
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: acm gadget: Null termintate strings table

[Graham Williams]

The gadget strings table should be null terminated.
usb_gadget_get_string() loops through the table
expecting a null at the end of the list.

Signed-off-by: Graham Williams 
---
 drivers/usb/gadget/f_acm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/gadget/f_acm.c b/drivers/usb/gadget/f_acm.c
index 4b7e33e..ab1065a 100644
--- a/drivers/usb/gadget/f_acm.c
+++ b/drivers/usb/gadget/f_acm.c
@@ -285,6 +285,7 @@ static struct usb_string acm_string_defs[] = {
[ACM_CTRL_IDX].s = "CDC Abstract Control Model (ACM)",
[ACM_DATA_IDX].s = "CDC ACM Data",
[ACM_IAD_IDX ].s = "CDC Serial",
+   {  } /* end of list */
 };
 
 static struct usb_gadget_strings acm_string_table = {
-- 
1.8.0.1


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

Re: [PATCH net,stable] net: usb: Add HP hs2434 device to ZLP exception table

[David Miller]

From: Rob Gardner 
Date: Wed, 28 Aug 2013 17:18:12 -0600

> Bjørn says it could have a minor performance impact, but should not
> cause any loss of functionality. I don't think there's any hard data on
> what the performance cost might be but I know he would eventually like
> to get rid of the exception list and live with the possible performance
> impact if it means functionality for more devices.

Therefore I would recommend turning the workaround on by default and
have a white list.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net,stable] net: usb: Add HP hs2434 device to ZLP exception table

[Rob Gardner]

On Wed, 28 Aug 2013 20:01:11 -0400 (EDT)
David Miller  wrote:

> From: Rob Gardner 
> Date: Wed, 28 Aug 2013 17:18:12 -0600
> 
> > Bjørn says it could have a minor performance impact, but should not
> > cause any loss of functionality. I don't think there's any hard data on
> > what the performance cost might be but I know he would eventually like
> > to get rid of the exception list and live with the possible performance
> > impact if it means functionality for more devices.
> 
> Therefore I would recommend turning the workaround on by default and
> have a white list.

The exception list means "usb_device_id entries for specific devices
that are known to need the workaround." There are just two such entries.
There isn't even a separate list. So maybe we just have a nomenclature
problem, and we could simply be calling this a "white list" instead of
"exception list". The other possible meaning of whitelist (all devices
that *don't* need the workaround) is unthinkable, as that would be a huge
list and much more prone to be unmanageable than what we've got now.

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

Re: [RFC 3/3] EHCI: handle late isochronous submissions

[Ming Lei]

On Thu, Aug 29, 2013 at 12:23 AM, Alan Stern  wrote:
> On Wed, 28 Aug 2013, Ming Lei wrote:
>
>> Below is the approach I proposed(mentioned in another thread), which should 
>> be
>> simper than this one, any comments?
>>
>>  drivers/usb/host/ehci-sched.c |   53 
>> ++---
>>  drivers/usb/host/ehci.h   |1 +
>>  2 files changed, 51 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
>> index 83be03f..80ef95d 100644
>> --- a/drivers/usb/host/ehci-sched.c
>> +++ b/drivers/usb/host/ehci-sched.c
>> @@ -1370,6 +1370,33 @@ sitd_slot_ok (
>>   return 1;
>>  }
>>
>> +/* rebase in case of underun without ISO_ASAP together */
>> +static int iso_stream_rebase(struct ehci_hcd *ehci, struct urb *urb,
>> + struct ehci_iso_stream  *stream, u32 span, u32 period)
>> +{
>> + u32 i, end;
>> + u32 mod = ehci->periodic_size;
>> +
>> + if (ehci->last_base == -1)
>> + return 0;
>> +
>> + end = ((stream->next_uframe + span - period) >> 3) & (mod - 1);
>> + for (i = ehci->last_base; i != ehci->last_iso_frame;
>> + i = (i + 1) & (mod - 1)) {
>> + /* don't schedule URB which is behind base totally */
>> + if (end == i) {
>> + for (i = 0; i < urb->number_of_packets; i++) {
>> + urb->iso_frame_desc[i].length = 0;
>> + urb->iso_frame_desc[i].status = 0;
>> + }
>> + return 1;
>> + }
>> + if (((stream->next_uframe >> 3) & (mod - 1)) == i)
>> + ehci->last_iso_frame = i;
>> + }
>
> Why do you use a loop here?  This looks like a straightforward thing to
> test: Starting from last_base, which comes first: next_uframe or
> last_iso_frame?

OK, that is simper.

>
> It's not a very good idea to change iso_frame_desc[i].length.  HCDs
> aren't suppose to touch that field.  Also, why set the frame
> descriptor status to 0?  It should remain equal to -EXDEV, because the
> frame never gets sent over the bus.

Right.

>
> You must never alter ehci->last_iso_frame like this.  It violates the
> driver's invariants for time to run "backward".  After all, there may
> already be other TDs scheduled for the frames you are about to scan

No, no other TDs scheduled for the frames since the queue is empty
when iso_stream_rebase is running.


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

Re: [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO

[Chanwoo Choi]

Hi George,

You didn't modify this patchset about my comment on v1 patchset.
Please pay attention to comment.

On 08/29/2013 02:33 AM, George Cherian wrote:
> Add a generic USB VBUS/ID detection EXTCON driver. This driver expects
> the ID/VBUS pin are connected via GPIOs. This driver is tested on
> DRA7x board were the ID pin is routed via GPIOs. The driver supports
> both VBUS and ID pin configuration and ID pin only configuration.
> 
> Signed-off-by: George Cherian 
> ---
>  .../bindings/extcon/extcon-gpio-usbvid.txt |  20 ++
>  drivers/extcon/Kconfig |   6 +
>  drivers/extcon/Makefile|   1 +
>  drivers/extcon/extcon-gpio-usbvid.c| 286 
> +

You should keep following naming stlye. extcon-gpio-usbvid.c is wrong naming 
style.
- extcon-[device name].c
- extcon-gpio-usbvid.c -> extcon-dra7xx.c or etc.

Also, you should change the file name of extcon-gpio-usbvid.txt.

Finally, You used 'gpio_usbvid' prefix in extcon-gpio-usbvid.c.
It has caused the confusion that user would think extcon-gpio-usbvid.c driver
support all of extcon driver using gpio irq pin. So I'd like you to use
proper prefix including device name.

>  4 files changed, 313 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt
>  create mode 100644 drivers/extcon/extcon-gpio-usbvid.c
> 
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt 
> b/Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt
> new file mode 100644
> index 000..eea0741
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt
> @@ -0,0 +1,20 @@
> +EXTCON FOR USB VIA GPIO
> +
> +Required Properties:
> + - compatible : Should be "ti,gpio-usb-vid" for USB VBUS-ID detector
> + using gpios or "ti,gpio-usb-id" for USB ID pin detector
> + - gpios : phandle and args ID pin gpio and VBUS gpio.
> +The first gpio used  for ID pin detection
> +and the second used for VBUS detection.
> +ID pin gpio is mandatory and VBUS is optional
> +depending on implementation.
> +
> +Please refer to ../gpio/gpio.txt for details of the common GPIO bindings
> +
> +Example:
> +
> + gpio_usbvid_extcon1 {
> + compatible = "ti,gpio-usb-vid";
> + gpios = <&gpio1 1 0>,
> + <&gpio2 2 0>;
> + };
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index f1d54a3..8097398 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -64,4 +64,10 @@ config EXTCON_PALMAS
> Say Y here to enable support for USB peripheral and USB host
> detection by palmas usb.
>  
> +config EXTCON_GPIO_USBVID
> + tristate "Generic USB VBUS/ID detection using GPIO EXTCON support"
> + help
> +   Say Y here to enable support for USB VBUS/ID deetction by GPIO.
> +
> +

Remove blank line.

>  endif # MULTISTATE_SWITCH
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index e4fa8ba..0451f698 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_EXTCON_MAX77693)   += extcon-max77693.o
>  obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
>  obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
>  obj-$(CONFIG_EXTCON_PALMAS)  += extcon-palmas.o
> +obj-$(CONFIG_EXTCON_GPIO_USBVID) += extcon-gpio-usbvid.o
> diff --git a/drivers/extcon/extcon-gpio-usbvid.c 
> b/drivers/extcon/extcon-gpio-usbvid.c
> new file mode 100644
> index 000..e9bc2a97
> --- /dev/null
> +++ b/drivers/extcon/extcon-gpio-usbvid.c
> @@ -0,0 +1,286 @@
> +/*
> + * Generic  USB VBUS-ID pin detection driver
> + *
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * Author: George Cherian 
> + *
> + * Based on extcon-palmas.c
> + *
> + * Author: Kishon Vijay Abraham I 
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 

kthead.h, freezer.h headerfile is used in this file?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Order headerfile alphabetically.

> +
> +struct gpio_usbvid {
> + struct device *dev;
> +
> + struct extcon_dev edev;
> +
> + /*GPIO pin */

I commented previous your patch about this wrong coding style.
Why did not you fix this coding style?

> + int id_gpio;
> + int vbus_gpio;
> +
> + int id_irq;
> 

Re: [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO

[George Cherian]

Hi Chanwoo,

Thanks for the review and sorry for all the trivial mistakes.

On 8/29/2013 7:05 AM, Chanwoo Choi wrote:

Hi George,

You didn't modify this patchset about my comment on v1 patchset.
Please pay attention to comment.

On 08/29/2013 02:33 AM, George Cherian wrote:

Add a generic USB VBUS/ID detection EXTCON driver. This driver expects
the ID/VBUS pin are connected via GPIOs. This driver is tested on
DRA7x board were the ID pin is routed via GPIOs. The driver supports
both VBUS and ID pin configuration and ID pin only configuration.

Signed-off-by: George Cherian 
---
  .../bindings/extcon/extcon-gpio-usbvid.txt |  20 ++
  drivers/extcon/Kconfig |   6 +
  drivers/extcon/Makefile|   1 +
  drivers/extcon/extcon-gpio-usbvid.c| 286 +

You should keep following naming stlye. extcon-gpio-usbvid.c is wrong naming 
style.
- extcon-[device name].c
- extcon-gpio-usbvid.c -> extcon-dra7xx.c or etc.
Actually dra7xx is the SoC name and the USB VBUS/ID detection is not 
specific to SoC.
It uses gpios to detect the VBUS/ID change. So i thought it would be 
better to have generic
gpio based VBUS/ID detection rather than making dra7xx specific. Stephen 
Warren had this opinion

with patch v1.


Also, you should change the file name of extcon-gpio-usbvid.txt.

Finally, You used 'gpio_usbvid' prefix in extcon-gpio-usbvid.c.
It has caused the confusion that user would think extcon-gpio-usbvid.c driver
support all of extcon driver using gpio irq pin. So I'd like you to use
proper prefix including device name.
I meant to support all of extcon driver using gpio for USB VBUS/ID 
detection.



  4 files changed, 313 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt
  create mode 100644 drivers/extcon/extcon-gpio-usbvid.c

[snip]

index f1d54a3..8097398 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -64,4 +64,10 @@ config EXTCON_PALMAS
  Say Y here to enable support for USB peripheral and USB host
  detection by palmas usb.
  
+config EXTCON_GPIO_USBVID

+   tristate "Generic USB VBUS/ID detection using GPIO EXTCON support"
+   help
+ Say Y here to enable support for USB VBUS/ID deetction by GPIO.
+
+

Remove blank line.

okay

  endif # MULTISTATE_SWITCH

[snip]

diff --git a/drivers/extcon/extcon-gpio-usbvid.c 
b/drivers/extcon/extcon-gpio-usbvid.c
new file mode 100644
index 000..e9bc2a97
--- /dev/null
+++ b/drivers/extcon/extcon-gpio-usbvid.c
@@ -0,0 +1,286 @@
+/*
+ * Generic  USB VBUS-ID pin detection driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: George Cherian 
+ *
+ * Based on extcon-palmas.c
+ *
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 

kthead.h, freezer.h headerfile is used in this file?

okay

+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 

Order headerfile alphabetically.

okay



+
+struct gpio_usbvid {
+   struct device *dev;
+
+   struct extcon_dev edev;
+
+   /*GPIO pin */

I commented previous your patch about this wrong coding style.
Why did not you fix this coding style?

okay

+   int id_gpio;
+   int vbus_gpio;
+
+   int id_irq;
+   int vbus_irq;
+   int type;
+};
+
+static const char *dra7xx_extcon_cable[] = {
+   [0] = "USB",
+   [1] = "USB-HOST",
+   NULL,
+};
+
+static const int mutually_exclusive[] = {0x3, 0x0};
+
+/* Two types of support are provided.
+ * Systems which has
+ * 1) VBUS and ID pin connected via GPIO
+ * 2)  only ID pin connected via GPIO

Remove blank between '2)' and 'only'.

okay

+ *  For Case 1 both the gpios should be provided via DT
+ *  Always the first GPIO in dt is considered ID pin GPIO
+ */
+
+enum {
+   UNKNOWN = 0,
+   ID_DETECT,
+   VBUS_ID_DETECT,
+};
+
+#define ID_GND 0
+#define ID_FLOAT   1
+#define VBUS_OFF   0
+#define VBUS_ON1

I think you could only use two constant instead of four constant definition.

you mean only ID_GND and VBUS_OFF?

+
+

This blank line isn't necessary.


+static irqreturn_t id_irq_handler(int irq, void *data)
+{
+   struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *) data;

You should delete blank between ')' and 'data' as follwong:
- (struct gpio_usbvid *)data;

okay



+   int id_current;

Re: [RFC 3/3] EHCI: handle late isochronous submissions

[Ming Lei]

On Wed, 28 Aug 2013 12:23:31 -0400 (EDT)
Alan Stern  wrote:

> You must never alter ehci->last_iso_frame like this.  It violates the 
> driver's invariants for time to run "backward".  After all, there may 
> already be other TDs scheduled for the frames you are about to scan 
> again; they mustn't get scanned until the frame pointer has wrapped 
> around.
> 
> This last problem in particular means your proposal can't be accepted.

On Thu, Aug 29, 2013 at 8:43 AM, Ming Lei  wrote:
> No, no other TDs scheduled for the frames since the queue is empty
> when iso_stream_rebase is running.

The above isn't true, but no rescan on other TDs introduced:

- suppose URB0 is scheduled via stream0 when underrun without ISO_ASAP

- iso_stream_rebase() find that stream0->next_uframe is behind
  ehci->last_iso_frame but URB0 isn't completed before
  ehci->last_iso_frame, then adjust it as stream0->next_uframe >> 3,
  and record its old value as ehci->last_iso_frame'.

- when next ehci irq comes, scan_isoc() scans from stream0->next_uframe
to 'now', and the extra scan introduced by iso_stream_rebase() is from
stream0->next_uframe to ehci->last_iso_frame' - 1, during this period,
only TDs belonged to undrun URBs without ISO_ASAP will scanned, and no
other TDs scheduled in these frames at all.(ehci->last_iso_frame doesn't
affect schedule, only decides start point of the next scan)

So no sort of run 'backward' things, and URBs are always completed in
time order, aren't they?

Below patch is modified according to your comment.

 drivers/usb/host/ehci-sched.c |   55 ++---
 drivers/usb/host/ehci.h   |1 +
 2 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
index 83be03f..80da5fd 100644
--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -1370,6 +1370,35 @@ sitd_slot_ok (
return 1;
 }
 
+/* rebase in case of underun without ISO_ASAP together */
+static int iso_stream_rebase(struct ehci_hcd *ehci, struct urb *urb,
+   struct ehci_iso_stream  *stream, u32 span, u32 period)
+{
+   u32 start, size;
+   u32 mod = ehci->periodic_size;
+
+   if (ehci->last_base == -1)
+   return 0;
+
+   start = stream->next_uframe >> 3;
+   size = (ehci->last_iso_frame - ehci->last_base) & (mod - 1);
+
+   /* if the URB should have been started */
+   if (size > ((start - ehci->last_base) & (mod - 1))) {
+   /* if the URB should have been completed now */
+   size = (ehci->last_iso_frame - start) & (mod - 1);
+   if (size > ((span - period) & (mod - 1))) {
+   int i;
+   for (i = 0; i < urb->number_of_packets; i++)
+   urb->iso_frame_desc[i].status = -EXDEV;
+   return 1;
+   }
+   ehci->last_iso_frame = start & (mod - 1);
+   }
+
+   return 0;
+}
+
 /*
  * This scheduler plans almost as far into the future as it has actual
  * periodic schedule slots.  (Affected by TUNE_FLS, which defaults to
@@ -1409,7 +1438,9 @@ iso_stream_schedule (
 * (irq delays etc).  If there are, the behavior depends on
 * whether URB_ISO_ASAP is set.
 */
-   if (likely (!list_empty (&stream->td_list))) {
+   if (likely (!list_empty (&stream->td_list) ||
+   hcd_complete_in_progress(
+   ehci_to_hcd(ehci), urb))) {
 
/* Take the isochronous scheduling threshold into account */
if (ehci->i_thresh)
@@ -1417,6 +1448,14 @@ iso_stream_schedule (
else
next = (now + 2 + 7) & ~0x07;   /* full frame cache */
 
+   if (list_empty(&stream->td_list) &&
+   !(urb->transfer_flags & URB_ISO_ASAP))
+   if (iso_stream_rebase(ehci, urb, stream, span,
+   period)) {
+   status = 1;
+   goto fail;
+   }
+
/*
 * Use ehci->last_iso_frame as the base.  There can't be any
 * TDs scheduled for earlier than that.
@@ -1517,6 +1556,7 @@ iso_stream_schedule (
/* Make sure scan_isoc() sees these */
if (ehci->isoc_count == 0)
ehci->last_iso_frame = now >> 3;
+   ehci->last_base = -1;
return 0;
 
  fail:
@@ -1838,7 +1878,10 @@ static int itd_submit (struct ehci_hcd *ehci, struct urb 
*urb,
status = iso_stream_schedule(ehci, urb, stream);
if (likely (status == 0))
itd_link_urb (ehci, urb, ehci->periodic_size << 3, stream);
-   else
+   else if (status > 0) {
+   ehci_urb_done(ehci, urb, 0);
+   status = 0;
+   } else
usb_hcd_unlink_urb_from_ep(ehci_to_hcd(ehc

Re: [PATCH v3 3/3] ARM: dts: dra7-evm: Add extcon nodes for USB ID pin detection

[George Cherian]

On 8/28/2013 11:24 PM, Sergei Shtylyov wrote:

On 08/28/2013 09:33 PM, George Cherian wrote:


Add
-extcon nodes for USB ID pin detection.
-i2c nodes.
-pcf nodes to which USB ID pin is connected.



Signed-off-by: George Cherian 
---
  arch/arm/boot/dts/dra7-evm.dts | 50 
+-

  1 file changed, 49 insertions(+), 1 deletion(-)


diff --git a/arch/arm/boot/dts/dra7-evm.dts 
b/arch/arm/boot/dts/dra7-evm.dts

index acd3c09..8b0738a 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts

[...]

@@ -33,10 +44,47 @@
  };
  };

+&i2c1 {
+clock-frequency = <40>;
+
+gpio20: pcf8575@20 {


ePAPR was talking about the node naming, not about labelling. Back 
to the drawing board. ;-)



ha. :-/

+compatible = "ti,pcf8575";
+reg = <0x20>;
+n_latch = <0x4000>;
+gpio-controller;
+#gpio-cells = <2>;
+interrupt-parent = <&gpio6>;
+interrupts = <11 2>;
+interrupt-controller;
+#interrupt-cells = <2>;
+};
+
+gpio21: pcf8575@21 {
+compatible = "ti,pcf8575";
+reg = <0x21>;
+n_latch = <0x1408>;
+gpio-controller;
+#gpio-cells = <2>;
+interrupt-parent = <&pcf_20>;
+interrupts = <14 2>;
+interrupt-controller;
+#interrupt-cells = <2>;
+};
+
+};
+


WBR, Sergei




--
-George

--
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/4] usb: r8a66597-hcd: use platform_{get,set}_drvdata()

[Libo Chen]

On 2013/8/28 12:36, Greg KH wrote:
> On Tue, Aug 27, 2013 at 04:10:22PM +0800, Libo Chen wrote:
>>
>> Use the wrapper functions for getting and setting the driver data using
>> platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
>> so we can directly pass a struct platform_device.
>>
>> Signed-off-by: Libo Chen 
>> ---
>>  drivers/usb/host/r8a66597-hcd.c |4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> This patch doesn't apply to my tree :(

Hi Greg,

This patch based on mainline.
Do you mean this patch got a conflicted in 
"git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git"

I need to rebase on "usb.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