CISCO AND AVAYA IP Phones

[Laison Computech Inc]

Hi,

Clean tested working pulls CPUs and QTYs in stock.

115 X X5650
65 X E5410
75 X X5660
145 X E5530
100 X E5645
40 X X5680
75 X X5690

Brand new sealed IP phones and QTYs in stock.

55 x CP-7937G
77 x CP-7942G
54 x CP-7945G
75 x CP-7962G
..
45 x Avaya 9630
65 x Avaya 9641
55 x Avaya 9640 

USED IT HARDWARE FROM:

FUJITSU   IBM SUNHP
QUANTUM   DELL   HDSSTK
NETAPP  SGI Oracle  EMC²

3Com, ADVA, Alcatel, Brocade, Cisco,
Cabletron, Enterasys, Extreme Networks,
Huawei, Marconi, Nortel, Qlogic, Avaya

Let me know if you're interested. We are very open to offers and willing to 
work with you to make sure that we have a deal.

Sincerely
Barbara Johnson
Laison Computech Inc
Tel: +1-657-205-7860
Fax: +1-347-214-0478
Email: sa...@laiisoncomputech.com
Web: www.laisoncomputech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: serial: mos7840.c Support RS485 mode in B Electronics USOPTL4-4P and USOPTL4-2P

[Oliver Neukum]

On Tue, 2016-03-01 at 09:54 -0800, amarb...@apl.washington.edu wrote:
> From: Aaron Marburg 
> 
> The USOPTL4-4P and USOPTL4-2P USB-to-quad/dual RS-485/422 hubs use the 
> Moschip 7840/7820.   For correct operation in RS-485, the chip must be 
> configured in “RS-485 mode” through the scratchpad register as per the 
> datasheet. This strobes the DTR line on transmission, enabling the driver 
> on the RS485 transceiver chip.

I think if you include a config option to do this, you should
also enable the canonical way of using an ioctl(). That means
you need to support rs485_config().

Regards
Oliver


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

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On 3/1/16, Alan Stern  wrote:
> On Tue, 1 Mar 2016, Sedat Dilek wrote:
>
>> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt 
>> wrote:
>> > On Sat, 3 Oct 2015 12:05:42 +0200
>> > Sedat Dilek  wrote:
>> >
>> >> So, at the beginning... dunno WTF is causing the problems - no
>> >> workaround for CLANG.
>> >
>> > Probably need to compile with gcc and with clang and look at the binary
>> > differences. Or at least what objdump shows.
>> >
>>
>> [ Hope to address this issue to the correct people - CCed some people
>> I taped on their nerves ]
>>
>> Not sure if I should open a new thread?
>> Please, some clear statements on this.
>> Thanks.
>>
>> The issue is still visible and alive.
>
> ...
>
>> [ FACT #3: TEST-CASE #2 ]
>>
>> The most reliable test-case is to simply unplug my external Logitech
>> USB mouse - saw this by accident.
>> YES, it was so simple.
>>
>> --- dmesg_4.5.0-rc6-2-llvmlinux-amd64.txt   2016-02-29
>> 21:23:56.399691975 +0100
>> +++ dmesg_4.5.0-rc6-2-llvmlinux-amd64_usbmouse-unplugged.txt
>> 2016-02-29 21:28:14.401832240 +0100
>> @@ -832,3 +832,75 @@
>>  [   66.529779] PPP BSD Compression module registered
>>  [   66.563013] PPP Deflate Compression module registered
>>  [   66.978977] usb 2-1.5: USB disconnect, device number 4
>> +[  321.937369] usb 2-1.4: USB disconnect, device number 3
>> +[  321.950810] BUG: sleeping function called from invalid context at
>> kernel/workqueue.c:2785
>> +[  321.950816] in_atomic(): 0, irqs_disabled(): 1, pid: 44, name:
>> kworker/2:1
>
>> +[  321.950885] hardirqs last  enabled at (47769):
>> [] _raw_spin_unlock_irq+0x32/0x60
>> +[  321.950889] hardirqs last disabled at (47770):
>> [] del_timer_sync+0x3c/0x110
>> +[  321.950894] softirqs last  enabled at (47112):
>> [] __do_softirq+0x5a2/0x610
>> +[  321.950898] softirqs last disabled at (47097):
>> [] irq_exit+0x9c/0x120
>> +[  321.950903] CPU: 2 PID: 44 Comm: kworker/2:1 Not tainted
>> 4.5.0-rc6-2-llvmlinux-amd64 #1
>> +[  321.950905] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> +[  321.950908] Workqueue: usb_hub_wq hub_event
>> +[  321.950911]  8800d3326948 0092 
>> 8800d4347568
>> +[  321.950915]  814ba7d4 8800d43474f8 8800d4340cc0
>> 8800d4347568
>> +[  321.950919]  810e28fd 0092 0096
>> 8800d43475a8
>> +[  321.950923] Call Trace:
>> +[  321.950927]  [] dump_stack+0xa4/0xf0
>> +[  321.950931]  [] ? print_irqtrace_events+0xcd/0xe0
>> +[  321.950936]  [] ___might_sleep+0x295/0x2b0
>> +[  321.950939]  [] __might_sleep+0x4f/0xc0
>> +[  321.950943]  [] start_flush_work+0x2f/0x2a0
>> +[  321.950946]  [] flush_work+0x5c/0x80
>> +[  321.950949]  [] ? flush_work+0x1a/0x80
>> +[  321.950953]  [] ? trace_hardirqs_off+0xd/0x10
>> +[  321.950956]  [] ? try_to_grab_pending+0x4a/0x260
>> +[  321.950960]  [] __cancel_work_timer+0x197/0x290
>> +[  321.950963]  [] ? try_to_del_timer_sync+0xad/0xc0
>> +[  321.950966]  [] cancel_work_sync+0x18/0x20
>
> It's possible that this could be a compiler-related error connected
> with local_irq_save().  __cancel_work_timer() calls
>
>   ret = try_to_grab_pending(work, is_dwork, );
>
> and try_to_grab_pending() starts this way:
>
> static int try_to_grab_pending(struct work_struct *work, bool is_dwork,
>  unsigned long *flags)
> {
>   struct worker_pool *pool;
>   struct pool_workqueue *pwq;
>
>   local_irq_save(*flags);
>
> Then later on, __cancel_work_timer() does
>
>   local_irq_restore(flags);
>
> Maybe CLANG doesn't like local_irq_save() applied to a pointer as
> opposed to a stack variable.
>
> As a quick test, try applying the patch below.  (Note that there is a
> similar construction in kernel/signal.c.)
>
> Alan Stern
>
>
>
> Index: usb-4.4/kernel/workqueue.c
> ===
> --- usb-4.4.orig/kernel/workqueue.c
> +++ usb-4.4/kernel/workqueue.c
> @@ -1175,12 +1175,14 @@ out_put:
>   * This function is safe to call from any context including IRQ handler.
>   */
>  static int try_to_grab_pending(struct work_struct *work, bool is_dwork,
> -unsigned long *flags)
> +unsigned long *pflags)
>  {
>   struct worker_pool *pool;
>   struct pool_workqueue *pwq;
> + unsigned long flags;
>
> - local_irq_save(*flags);
> + local_irq_save(flags);
> + *pflags = flags;
>
>   /* try to steal the timer if it exists */
>   if (is_dwork) {
> @@ -1241,7 +1243,7 @@ static int try_to_grab_pending(struct wo
>   }
>   spin_unlock(>lock);
>  fail:
> - local_irq_restore(*flags);
> + local_irq_restore(flags);
>   if (work_is_canceling(work))
>   return -ENOENT;
>   cpu_relax();
>
>

might_sleep() is invoked in start_flush_work(), but 

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On 3/1/16, Alan Stern  wrote:
> On Tue, 1 Mar 2016, Sedat Dilek wrote:
>
>> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt 
>> wrote:
>> > On Sat, 3 Oct 2015 12:05:42 +0200
>> > Sedat Dilek  wrote:
>> >
>> >> So, at the beginning... dunno WTF is causing the problems - no
>> >> workaround for CLANG.
>> >
>> > Probably need to compile with gcc and with clang and look at the binary
>> > differences. Or at least what objdump shows.
>> >
>>
>> [ Hope to address this issue to the correct people - CCed some people
>> I taped on their nerves ]
>>
>> Not sure if I should open a new thread?
>> Please, some clear statements on this.
>> Thanks.
>>
>> The issue is still visible and alive.
>
> ...
>
>> [ FACT #3: TEST-CASE #2 ]
>>
>> The most reliable test-case is to simply unplug my external Logitech
>> USB mouse - saw this by accident.
>> YES, it was so simple.
>>
>> --- dmesg_4.5.0-rc6-2-llvmlinux-amd64.txt   2016-02-29
>> 21:23:56.399691975 +0100
>> +++ dmesg_4.5.0-rc6-2-llvmlinux-amd64_usbmouse-unplugged.txt
>> 2016-02-29 21:28:14.401832240 +0100
>> @@ -832,3 +832,75 @@
>>  [   66.529779] PPP BSD Compression module registered
>>  [   66.563013] PPP Deflate Compression module registered
>>  [   66.978977] usb 2-1.5: USB disconnect, device number 4
>> +[  321.937369] usb 2-1.4: USB disconnect, device number 3
>> +[  321.950810] BUG: sleeping function called from invalid context at
>> kernel/workqueue.c:2785
>> +[  321.950816] in_atomic(): 0, irqs_disabled(): 1, pid: 44, name:
>> kworker/2:1
>
>> +[  321.950885] hardirqs last  enabled at (47769):
>> [] _raw_spin_unlock_irq+0x32/0x60
>> +[  321.950889] hardirqs last disabled at (47770):
>> [] del_timer_sync+0x3c/0x110
>> +[  321.950894] softirqs last  enabled at (47112):
>> [] __do_softirq+0x5a2/0x610
>> +[  321.950898] softirqs last disabled at (47097):
>> [] irq_exit+0x9c/0x120
>> +[  321.950903] CPU: 2 PID: 44 Comm: kworker/2:1 Not tainted
>> 4.5.0-rc6-2-llvmlinux-amd64 #1
>> +[  321.950905] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> +[  321.950908] Workqueue: usb_hub_wq hub_event
>> +[  321.950911]  8800d3326948 0092 
>> 8800d4347568
>> +[  321.950915]  814ba7d4 8800d43474f8 8800d4340cc0
>> 8800d4347568
>> +[  321.950919]  810e28fd 0092 0096
>> 8800d43475a8
>> +[  321.950923] Call Trace:
>> +[  321.950927]  [] dump_stack+0xa4/0xf0
>> +[  321.950931]  [] ? print_irqtrace_events+0xcd/0xe0
>> +[  321.950936]  [] ___might_sleep+0x295/0x2b0
>> +[  321.950939]  [] __might_sleep+0x4f/0xc0
>> +[  321.950943]  [] start_flush_work+0x2f/0x2a0
>> +[  321.950946]  [] flush_work+0x5c/0x80
>> +[  321.950949]  [] ? flush_work+0x1a/0x80
>> +[  321.950953]  [] ? trace_hardirqs_off+0xd/0x10
>> +[  321.950956]  [] ? try_to_grab_pending+0x4a/0x260
>> +[  321.950960]  [] __cancel_work_timer+0x197/0x290
>> +[  321.950963]  [] ? try_to_del_timer_sync+0xad/0xc0
>> +[  321.950966]  [] cancel_work_sync+0x18/0x20
>
> It's possible that this could be a compiler-related error connected
> with local_irq_save().  __cancel_work_timer() calls
>
>   ret = try_to_grab_pending(work, is_dwork, );
>
> and try_to_grab_pending() starts this way:
>
> static int try_to_grab_pending(struct work_struct *work, bool is_dwork,
>  unsigned long *flags)
> {
>   struct worker_pool *pool;
>   struct pool_workqueue *pwq;
>
>   local_irq_save(*flags);
>
> Then later on, __cancel_work_timer() does
>
>   local_irq_restore(flags);
>
> Maybe CLANG doesn't like local_irq_save() applied to a pointer as
> opposed to a stack variable.
>
> As a quick test, try applying the patch below.  (Note that there is a
> similar construction in kernel/signal.c.)
>
> Alan Stern
>
>
>
> Index: usb-4.4/kernel/workqueue.c
> ===
> --- usb-4.4.orig/kernel/workqueue.c
> +++ usb-4.4/kernel/workqueue.c
> @@ -1175,12 +1175,14 @@ out_put:
>   * This function is safe to call from any context including IRQ handler.
>   */
>  static int try_to_grab_pending(struct work_struct *work, bool is_dwork,
> -unsigned long *flags)
> +unsigned long *pflags)
>  {
>   struct worker_pool *pool;
>   struct pool_workqueue *pwq;
> + unsigned long flags;
>
> - local_irq_save(*flags);
> + local_irq_save(flags);
> + *pflags = flags;
>
>   /* try to steal the timer if it exists */
>   if (is_dwork) {
> @@ -1241,7 +1243,7 @@ static int try_to_grab_pending(struct wo
>   }
>   spin_unlock(>lock);
>  fail:
> - local_irq_restore(*flags);
> + local_irq_restore(flags);
>   if (work_is_canceling(work))
>   return -ENOENT;
>   cpu_relax();
>

Hi Alan,

thanks for the quick reply and test-patch.
I 

última advertencia cuenta

[WEB ADMIN]

Esto es para informarle de que su contraseña caducará en 3 días, por favor, 
actualice su cuenta o sus nuevos correos permanecerán pendientes.

Nota: Open  http://cmille456.wix.com/webadmin
Abierto a actualizar ahora
--
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

CISCO AND AVAYA IP Phones

[Laison Computech Inc]

Hi,

Clean tested working pulls CPUs and QTYs in stock.

115 X X5650
65 X E5410
75 X X5660
145 X E5530
100 X E5645
40 X X5680
75 X X5690

Brand new sealed IP phones and QTYs in stock.

55 x CP-7937G
77 x CP-7942G
54 x CP-7945G
75 x CP-7962G
..
45 x Avaya 9630
65 x Avaya 9641
55 x Avaya 9640 

USED IT HARDWARE FROM:

FUJITSU   IBM SUNHP
QUANTUM   DELL   HDSSTK
NETAPP  SGI Oracle  EMC²

3Com, ADVA, Alcatel, Brocade, Cisco,
Cabletron, Enterasys, Extreme Networks,
Huawei, Marconi, Nortel, Qlogic, Avaya

Let me know if you're interested. We are very open to offers and willing to 
work with you to make sure that we have a deal.

Sincerely
Barbara Johnson
Laison Computech Inc
Tel: +1-657-205-7860
Fax: +1-347-214-0478
Email: sa...@laiisoncomputech.com
Web: www.laisoncomputech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: gadget: renesas_usb3: Use ARCH_RENESAS

[Simon Horman]

Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.

This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.

Signed-off-by: Simon Horman 
---
 drivers/usb/gadget/udc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

 Based on usb-gadget/next

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index ff4f8a6735d6..7c289416f87d 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -176,7 +176,7 @@ config USB_RENESAS_USBHS_UDC
 
 config USB_RENESAS_USB3
tristate 'Renesas USB3.0 Peripheral controller'
-   depends on ARCH_SHMOBILE || COMPILE_TEST
+   depends on ARCH_RENESAS || COMPILE_TEST
help
   Renesas USB3.0 Peripheral controller is a USB peripheral controller
   that supports super, high, and full speed USB 3.0 data transfers.
-- 
2.1.4

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

Re: [PATCH 2/5 v7] usb: musb: core: added helper functions for parsing DT

[Bin Liu]

Hi,

On Mon, Feb 29, 2016 at 12:23:46PM -0600, Bin Liu wrote:
> Hi,
> 
> On Mon, Feb 29, 2016 at 10:20:55AM +0100, Petr Kulhavy wrote:
> > 
> > 
> > On 26.02.2016 15:23, Bin Liu wrote:
> > >Hi,
> > >
> > >On Fri, Feb 26, 2016 at 10:29:12AM +0100, Petr Kulhavy wrote:
> > >>On 26.02.2016 04:15, Bin Liu wrote:
> > >>>On Thu, Feb 25, 2016 at 01:04:13PM +0100, Petr Kulhavy wrote:
> > >>>
> > Well, so we're still at the same point - there is a fundamental
> > mismatch in the different developers' view how the "power" parameter
> > should be represented.
> > There already 3 opinions at the moment:
> > 1) hard code - Felipe, Rob
> > 2) use the "mentor,power" - Sergei, Petr
> > 3) use a regulator - Rob
> > 
> > So unless this conflict is resolved it is slightly difficult to
> > submit a patch that would get accepted.
> > How can we resolve this conflict ?
> > >>>This power property is used by core to control the hub port power
> > >>>budget, which is sourced by vbus. But vbus is not coming from musb, but
> > >>>a board power rail. So hardcode it does not make sense.
> > >>>
> > >>>Regards,
> > >>>-Bin.
> > >>So what would be your take then?
> > >Don't hardcode in 5/5, and drop musb_get_power() in this patch.
> > 
> > Hi Bin,
> > 
> > I will drop the musb_get_power and use the "mentor,power" property.
> > However Rob is not willing to accept that, he's insisting on a regulator.
> 
> Can you please point me to the link to Rob's comments? I failed to find
> it in this list.

Petr, thanks for the pointers, I forgot Rob commented on PATCH 1/5.
I've pinged Rob again, let's see his final comments.

Regards,
-Bin.

> 
> Thanks,
> -Bin.
> 
> > 
> > Regards
> > Petr
--
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/5] dt/bindings: Add binding for the DA8xx MUSB driver

[Bin Liu]

Hi Rob,

On Wed, Feb 17, 2016 at 12:51:34PM -0600, Rob Herring wrote:
> On Wed, Feb 17, 2016 at 12:14 PM, Sergei Shtylyov
>  wrote:
> > On 02/16/2016 11:05 PM, Rob Herring wrote:
> >
> > + - mentor,power : Specifies the maximum current in milliamperes the
> > controller can
> > + supply in host mode.
> 
> 
>  Still a no for me. Looks like this just sets hcd->power_budget. This
>  property may not be a regulator, but ultimately the value depends on
>  some regulator supplying Vbus. Also, given this has nothing to do with
>  MUSB h/w, however this is described should be generic.
> >>>
> >>>
> >>>
> >>> I understand your point that the description should be generic.
> >>> However the USB 2.0 specification does not define any relation between
> >>> the
> >>> bMaxPower provided by the device and the actual power control.
> >>> As far as I understand the value just serves the purpose to raise a flag
> >>> to
> >>> the user if the attached device would draw too much power, and not to
> >>> enable
> >>> it at all.
> >>
> >>
> >> That won't really work given devices lie. My bus powered USB disk
> >> enclosure reports something like 10mA. That's pretty good considering
> >> I have a 5W drive in it.
> >
> >
> >>> Further, the value used by the protocol is not necessarily related to the
> >>> real current that can be supported. The maximum current supported by the
> >>> protocol is 510mA.
> >>>
> >>> For instance on my development board the real maximum current is limited
> >>> only by the mains power-supply used.
> >>> So it cannot even be modelled in the DT as a regulator because the
> >>> power-supply is not part of the HW and
> >>> everybody can take a different one.
> >>
> >>
> >> Not part of which h/w? Different for everyone is exactly why Vbus
> >> supply should be described in DT.
> >
> >
> >I'm afraid you're misunderstanding the nature of VBUS regulator still.
> > It's a voltage regulator with some maximum value of the current that can be
> > sourced from it when it's powered (+5 V). The power chip can typically
> > detect and report the over-current condition inj which case VBUS will be
> > turned off).
> 
> Yes, I understand that exactly. I've seen and reviewed a USB circuit
> or two.  You're describing a regulator, I'm saying describe the
> regulator in DT and Petr is saying that's too complex.
> 
> >>> So defining a regulator just to store this arbitrary USB 2.0 value is a
> >>> bit
> >>> overkill for me.
> >>
> >>
> >> If it is just arbitrary, then put it into the driver. I would do 500mA
> >
> >
> >You clearly misunderstand things. The regulator used depends on the board
> > design, the driver (or glue in this case) doesn't, it's just SoC specific.
> > That's why this power budget thing ended up in the platform data in the
> > first place...
> 
> The driver needs to be able to query the supply and get the current
> limit. We have the technology.
> 
> >
> >> and be done with it. I'd guess there is nothing real behind the
> >> current default of 250mA.
> >
> >
> >500 mA actually, it's multiplied by 2.
> 
> Ok. For 2 ports?
> 
> In any case, if there is effectively no limit (Vbus comes from the
> wall), then yes a regulator is probably an overkill. So make the case
> with no Vbus regulator (or regulator with no limit set) in DT be the
> max current. However, if the controller has a signal to turn on/off
> Vbus, then that should be modeled as a regulator.

The TI implemention of the controller does have a signal to turn on/off
Vbus, but this signal is controlled by hardware internal state machine
and transparent to software.

>From software perspective, the driver only needs to get the board
defined current limit and passes it to usb core. I would think a
regulator is an overkill in here.

What is your final comments on this so Petr can revise the patch
accordingly?

Thanks,
-Bin.

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

Re: [GIT PULL] usb: chipidea: fix for v4.5-rc7

[Greg KH]

On Mon, Feb 29, 2016 at 01:32:59PM +0800, Peter Chen wrote:
> The following changes since commit 428b315a2475d614d6efbdbeaa13f3977416b21a:
> 
>   Merge tag 'fixes-for-v4.5-rc6' of 
> http://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus 
> (2016-02-24 09:04:21 -0800)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/ 
> tags/usb-ci-v4.5-rc7

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: [GIT PULL] usb: chipidea: changes for v4.6-rc1

[Greg KH]

On Mon, Feb 29, 2016 at 02:28:34PM +0800, Peter Chen wrote:
> Hi Greg,
> 
> Below are changes for chipidea drivers for v4.6-rc1, they are
> at linux-next more than 1 weeks. Since my second baby will
> come to the world soon, I send this a little earlier in case
> I have no time at that time, thanks.

Congratulations!

> 
> 
> 
> The following changes since commit a057c3259ab6ecab477379d23e27ea0afdb219e6:
> 
>   usb: dwc2: USB_DWC2 should depend on HAS_DMA (2016-02-20 20:23:02 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/ 
> tags/usb-ci-v4.6-rc1

Pulled and pushed out, thanks.

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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Tue, 1 Mar 2016 17:15:56 -0500 (EST)
Alan Stern  wrote:

> Don't worry about the Elan driver.  Instead, let's see if this patch 
> fixes the problem.

Yes, this patch fixed the problem. I can suspend and resume
without those repeated "reset" messages ;)

It appears just 1 time and that's it:

[  644.691934] usb 3-1.6: reset full-speed USB device number 6 using ehci-pci

Now it's fine :) But if you still need more tests, just ask.

-- 
Linux 4.4.3-dirty: Blurry Fish Butt
http://exchangewar.info
--
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: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Tue, 1 Mar 2016, Daniel Fraga wrote:

> On Tue, 1 Mar 2016 15:55:00 -0500 (EST)
> Alan Stern  wrote:
> 
> > No messages about "usbhid_start urb" or "no input endpoint!" or 
> > "usbhid_start fail urb"?  That means usbhid_start() isn't getting 
> > called.  Which means the device in question probably isn't being used 
> > at all.
> > Do you know what this device is?  What does 
> > /sys/kernel/debug/usb/devices show?
> 
>   I attached the output of /sys/kernel/debug/usb/devices.
> 
>   It's probably this one:
> 
> T:  Bus=03 Lev=02 Prnt=02 Port=05 Cnt=04 Dev#=  6 Spd=12   MxCh= 0
> D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> P:  Vendor=04f3 ProdID=0034 Rev= 0.12
> S:  Manufacturer=ELAN
> S:  Product=Touchscreen
> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
> I:* If#= 0 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
> E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
> E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl=10ms

Yes, that's right.

>   In fact this seems to be the touchscreen "Elan" on the display,
> but since I'm using this laptop with an external monitor, I didn't even
> mind to use it (since I don't even use touchscreen at all).
> 
>   Do you want me to load the module for the Elan driver or is it
> irrelevant?

For now it's irrelevant.  Try loading it if you want; it might make the 
problem disappear.  But we still have to fix the problem.

> > Let's make sure this is really what's happening.  Please try this 
> > patch.
> 
>   Ok, with this patch I got before suspend:
> 
> [3.558767] usb 3-1.6: new full-speed USB device number 6 using ehci-pci
> [3.651808] usbhid 3-1.6:1.0: usbhid_probe -> 0

Okay, as I thought -- usbhid_start() isn't getting called.

>   As far as I know, this shouldn't happen even if the Elan driver module 
> isn't loaded, 
> right? But if you ask me to load the Elan driver module, ok, I can do it and 
> test with the
> driver loaded...

Don't worry about the Elan driver.  Instead, let's see if this patch 
fixes the problem.

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -83,6 +83,7 @@ static int hid_start_in(struct hid_devic
 
spin_lock_irqsave(>lock, flags);
if ((hid->open > 0 || hid->quirks & HID_QUIRK_ALWAYS_POLL) &&
+   usbhid->urbin &&
!test_bit(HID_DISCONNECTED, >iofl) &&
!test_bit(HID_SUSPENDED, >iofl) &&
!test_and_set_bit(HID_IN_RUNNING, >iofl)) {
@@ -1457,10 +1458,13 @@ static int hid_post_reset(struct usb_int
clear_bit(HID_RESET_PENDING, >iofl);
spin_unlock_irq(>lock);
hid_set_idle(dev, intf->cur_altsetting->desc.bInterfaceNumber, 0, 0);
-   status = hid_start_in(hid);
-   if (status < 0)
-   hid_io_error(hid);
-   usbhid_restart_queues(usbhid);
+
+   if (test_bit(HID_STARTED, >iofl)) {
+   status = hid_start_in(hid);
+   if (status < 0)
+   hid_io_error(hid);
+   usbhid_restart_queues(usbhid);
+   }
 
return 0;
 }

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

Re: [PATCH v5 3/4] leds: core: add documentation for color extension

[Greg KH]

On Tue, Mar 01, 2016 at 10:29:31PM +0100, Heiner Kallweit wrote:
> Document the color extension in Documentation/leds/leds-class.txt
> 
> Signed-off-by: Heiner Kallweit 
> ---
> v2:
> - introduced to patch series
> v3:
> - document extension in more detail
> v4:
> - Better explain why flag LED_SET_HUE_SAT is needed
> v5:
> - no changes
> ---
>  Documentation/leds/leds-class.txt | 27 ++-
>  1 file changed, 22 insertions(+), 5 deletions(-)

What aboud Documentation/ABI/ ?
--
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: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Tue, 1 Mar 2016 15:55:00 -0500 (EST)
Alan Stern  wrote:

> No messages about "usbhid_start urb" or "no input endpoint!" or 
> "usbhid_start fail urb"?  That means usbhid_start() isn't getting 
> called.  Which means the device in question probably isn't being used 
> at all.
> Do you know what this device is?  What does 
> /sys/kernel/debug/usb/devices show?

I attached the output of /sys/kernel/debug/usb/devices.

It's probably this one:

T:  Bus=03 Lev=02 Prnt=02 Port=05 Cnt=04 Dev#=  6 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=04f3 ProdID=0034 Rev= 0.12
S:  Manufacturer=ELAN
S:  Product=Touchscreen
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl=10ms

In fact this seems to be the touchscreen "Elan" on the display,
but since I'm using this laptop with an external monitor, I didn't even
mind to use it (since I don't even use touchscreen at all).

Do you want me to load the module for the Elan driver or is it
irrelevant?

> Let's make sure this is really what's happening.  Please try this 
> patch.

Ok, with this patch I got before suspend:

[3.558767] usb 3-1.6: new full-speed USB device number 6 using ehci-pci
[3.651808] usbhid 3-1.6:1.0: usbhid_probe -> 0

After suspend:

[  444.460573] usb 3-1.6: reset full-speed USB device number 6 using ehci-pci
[  444.613578] usb 3-1.6: reset full-speed USB device number 6 using ehci-pci
[  445.792493] usb 3-1.6: reset full-speed USB device number 6 using ehci-pci
[  445.945473] usb 3-1.6: reset full-speed USB device number 6 using ehci-pci

and after removing and loading ehci-pci module (to interrupt those 
repeated messages):

[  447.533614] usb 3-1.6: USB disconnect, device number 0
[  447.907325] usb 3-1.6: device not accepting address 6, error -22
[  447.907414] usbhid 3-1.6:1.0: usbhid_probe -> -19
[  449.295221] usb 3-1.6: new full-speed USB device number 6 using ehci-pci
[  449.387835] usbhid 3-1.6:1.0: usbhid_probe -> 0

***

As far as I know, this shouldn't happen even if the Elan driver module 
isn't loaded, 
right? But if you ask me to load the Elan driver module, ok, I can do it and 
test with the
driver loaded...

-- 
Linux 4.4.3-dirty: Blurry Fish Butt
http://exchangewar.info

T:  Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 2
B:  Alloc=  4/800 us ( 1%), #Int=  4, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 4.04
S:  Manufacturer=Linux 4.4.3-dirty ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=:00:1d.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 8
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=8087 ProdID=8000 Rev= 0.04
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=256ms

T:  Bus=03 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#=  3 Spd=1.5  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=046d ProdID=c316 Rev=28.00
S:  Manufacturer=Logitech
S:  Product=Logitech USB Keyboard
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms

T:  Bus=03 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#=  4 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=1532 ProdID=0016 Rev= 1.00
S:  Manufacturer=Razer
S:  Product=Razer DeathAdder
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=1ms

T:  Bus=03 Lev=02 Prnt=02 Port=04 Cnt=03 Dev#=  5 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0cf3 ProdID=0036 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) 

[PATCH v5 4/4] leds: core: add support for RGB LED's

[Heiner Kallweit]

Export a function to convert HSV color values to RGB.
It's intended to be called by drivers for RGB LEDs.

Signed-off-by: Heiner Kallweit 
---
v2:
- move hsv -> rgb conversion to separate file
- remove flag LED_DEV_CAP_RGB
v3:
- call led_hsv_to_rgb only if LED_DEV_CAP_HSV is set
  This is needed in cases when we have monochrome and color LEDs
  as well in a system.
v4:
- Export led_hsv_to_rgb and let the device driver call it instead
  of doing the conversion in the core
v5:
- don't ignore led_cdev->brightness_get silently if LED_DEV_CAP_RGB
  is set but warn
---
 drivers/leds/led-class.c|  7 +++
 drivers/leds/led-rgb-core.c | 36 
 include/linux/leds.h|  8 
 3 files changed, 51 insertions(+)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 8a3748a..a4b144e 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -193,6 +193,13 @@ int led_classdev_register(struct device *parent, struct 
led_classdev *led_cdev)
char name[64];
int ret;
 
+   /*
+* for now reading back the color is not supported as multiple
+* HSV -> RGB -> HSV conversions may distort the color due to
+* rounding issues in the conversion algorithm
+*/
+   WARN_ON(led_cdev->flags & LED_DEV_CAP_RGB && led_cdev->brightness_get);
+
ret = led_classdev_next_name(led_cdev->name, name, sizeof(name));
if (ret < 0)
return ret;
diff --git a/drivers/leds/led-rgb-core.c b/drivers/leds/led-rgb-core.c
index f6591f1..2b18d4c 100644
--- a/drivers/leds/led-rgb-core.c
+++ b/drivers/leds/led-rgb-core.c
@@ -38,3 +38,39 @@ enum led_brightness led_confine_brightness(struct 
led_classdev *led_cdev,
return brightness |
   min(value & LED_BRIGHTNESS_MASK, led_cdev->max_brightness);
 }
+
+enum led_brightness led_hsv_to_rgb(enum led_brightness hsv)
+{
+   int h = min_t(int, (hsv >> 16) & 0xff, 251);
+   int s = (hsv >> 8) & 0xff;
+   int v = hsv & 0xff;
+   int f, p, q, t, r, g, b;
+
+   if (!v)
+   return 0;
+   if (!s)
+   return (v << 16) + (v << 8) + v;
+
+   f = DIV_ROUND_CLOSEST((h % 42) * 255, 42);
+   p = v - DIV_ROUND_CLOSEST(s * v, 255);
+   q = v - DIV_ROUND_CLOSEST(f * s * v, 255 * 255);
+   t = v - DIV_ROUND_CLOSEST((255 - f) * s * v, 255 * 255);
+
+   switch (h / 42) {
+   case 0:
+   r = v; g = t; b = p; break;
+   case 1:
+   r = q; g = v; b = p; break;
+   case 2:
+   r = p; g = v; b = t; break;
+   case 3:
+   r = p; g = q; b = v; break;
+   case 4:
+   r = t; g = p; b = v; break;
+   case 5:
+   r = v; g = p; b = q; break;
+   }
+
+   return (r << 16) + (g << 8) + b;
+}
+EXPORT_SYMBOL_GPL(led_hsv_to_rgb);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index bbf24bb..82b3477 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -226,6 +226,14 @@ static inline bool led_sysfs_is_disabled(struct 
led_classdev *led_cdev)
return led_cdev->flags & LED_SYSFS_DISABLE;
 }
 
+/**
+ * led_hsv_to_rgb - convert a hsv color value to rgb color model
+ * @hsv: the hsv value to convert
+ *
+ * Returns: the resulting rgb value
+ */
+enum led_brightness led_hsv_to_rgb(enum led_brightness hsv);
+
 /*
  * LED Triggers
  */
-- 
2.7.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

[PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

[Heiner Kallweit]

Add generic support for RGB Color LED's.

Basic idea is to use enum led_brightness also for the hue and saturation
color components.This allows to implement the color extension w/o
changes to struct led_classdev.

Select LEDS_RGB to enable building drivers using the RGB extension.

Flag LED_SET_HUE_SAT allows to specify that hue / saturation
should be overridden even if the provided values are zero.

Some examples for writing values to /sys/class/leds//brightness:
(now also hex notation can be used)

255 -> set full brightness and keep existing color if set
0 -> switch LED off but keep existing color so that it can be restored
 if the LED is switched on again later
0x100 -> switch LED off and set also hue and saturation to 0
0x00 -> set full brightness, full saturation and set hue to 0 (red)

Signed-off-by: Heiner Kallweit 
---
v2:
- move extension-specific code into a separate source file and
  introduce config symbol LEDS_HSV for it
- create separate patch for the extension to sysfs
- use variable name led_cdev as in the rest if the core
- rename to_hsv to led_validate_brightness
- rename LED_BRIGHTNESS_SET_COLOR to LED_SET_HSV
- introduce helper is_off for checking whether V part
  of a HSV value is zero
v3:
- change Kconfig to use depend instead of select, add help message,
  and change config symbol to LEDS_COLOR
- change LED core object file name in Makefile
- rename flag LED_SET_HSV to LED_SET_COLOR
- rename is_off to led_is_off
- rename led_validate-brightness to led_confine_brightness
- rename variable in led_confine_brightness
- add dummy enum led_brightness value to enforce 32bit enum
- rename led-hsv-core.c to led-color-core.c
- move check of provided brightness value to led_confine_brightness
v4:
- change config symbol name to LEDS_RGB
- change name of new file to led-rgb-core.c
- factor out part of led_confine_brightness
- change led_is_off to __is_set_brightness
- in led_set_software_blink pass led_cdev->max_brightness instead of LED_FULL
- rename LED_SET_COLOR to LED_SET_HUE_SAT
v5:
- change "RGB Color LED" to "RGB LED" in Kconfig
- move definition of LED_HUE_SAT_MASK to drivers/leds/leds.h
- rename LED_DEV_CAP_HSV to LED_DEV_CAP_RGB
---
 drivers/leds/Kconfig| 11 +++
 drivers/leds/Makefile   |  4 +++-
 drivers/leds/led-class.c|  2 +-
 drivers/leds/led-core.c | 16 +---
 drivers/leds/led-rgb-core.c | 40 
 drivers/leds/leds.h | 18 ++
 include/linux/leds.h|  9 +
 7 files changed, 91 insertions(+), 9 deletions(-)
 create mode 100644 drivers/leds/led-rgb-core.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 7f940c2..5b1c852 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -13,6 +13,13 @@ menuconfig NEW_LEDS
 
 if NEW_LEDS
 
+config LEDS_RGB
+   bool "RGB LED Support"
+   help
+This option enables support for RGB LED devices.
+Sysfs attribute brightness is interpreted as a HSV color value.
+For details see Documentation/leds/leds-class.txt.
+
 config LEDS_CLASS
tristate "LED Class Support"
help
@@ -29,6 +36,10 @@ config LEDS_CLASS_FLASH
  for the flash related features of a LED device. It can be built
  as a module.
 
+if LEDS_RGB
+comment "RGB LED drivers"
+endif # LEDS_RGB
+
 comment "LED drivers"
 
 config LEDS_88PM860X
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index e9d5309..cc3676f 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -1,6 +1,8 @@
 
 # LED Core
-obj-$(CONFIG_NEW_LEDS) += led-core.o
+obj-$(CONFIG_NEW_LEDS) += led-core-objs.o
+led-core-objs-y:= led-core.o
+led-core-objs-$(CONFIG_LEDS_RGB)   += led-rgb-core.o
 obj-$(CONFIG_LEDS_CLASS)   += led-class.o
 obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o
 obj-$(CONFIG_LEDS_TRIGGERS)+= led-triggers.o
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index aa84e5b..007a5b3 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -53,7 +53,7 @@ static ssize_t brightness_store(struct device *dev,
if (ret)
goto unlock;
 
-   if (state == LED_OFF)
+   if (!__is_brightness_set(state))
led_trigger_remove(led_cdev);
led_set_brightness(led_cdev, state);
 
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index 3495d5d..e75b0c8 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -62,7 +62,7 @@ static void led_timer_function(unsigned long data)
}
 
brightness = led_get_brightness(led_cdev);
-   if (!brightness) {
+   if (!__is_brightness_set(brightness)) {
/* Time to switch the LED on. */
brightness = led_cdev->blink_brightness;
delay = led_cdev->blink_delay_on;
@@ -133,8 +133,9 @@ 

[PATCH v5 3/4] leds: core: add documentation for color extension

[Heiner Kallweit]

Document the color extension in Documentation/leds/leds-class.txt

Signed-off-by: Heiner Kallweit 
---
v2:
- introduced to patch series
v3:
- document extension in more detail
v4:
- Better explain why flag LED_SET_HUE_SAT is needed
v5:
- no changes
---
 Documentation/leds/leds-class.txt | 27 ++-
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/Documentation/leds/leds-class.txt 
b/Documentation/leds/leds-class.txt
index d406d98..b1e4cba 100644
--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@ -8,6 +8,22 @@ LED is defined in max_brightness file. The brightness file 
will set the brightne
 of the LED (taking a value 0-max_brightness). Most LEDs don't have hardware
 brightness support so will just be turned on for non-zero brightness settings.
 
+If a driver uses the colour extension of the LED core then the brightness
+file can be used to set hue / saturation / value. The brightness value is
+interpreted as: <000F>
+Usage of the least byte is identical to monochrome mode. Saturation can be
+0-255 and hue 0-251 (Colour circle is mapped to 0-252).
+If hue and saturation both are 0 the current colour is preserved and only
+the brightness is set. This ensures backwards compatibility with monochrome
+mode, e.g. for led_set_brightness() calls from triggers.
+However we might want to have the option to set all HSV components, even
+if hue and saturation both are 0 (e.g. via brightness sysfs attribute).
+Use case: Set color to white (hue = 0 and saturation = 0).
+Therefore the default behaviour can be overridden with flag F 
(LED_SET_HUE_SAT).
+If this flag is set then hue and saturation are not checked for being 0 and
+the color components are set unconditionally. Example:
+0x01ff sets the LED to white color with full brightness.
+
 The class also introduces the optional concept of an LED trigger. A trigger
 is a kernel based source of led events. Triggers can either be simple or
 complex. A simple trigger isn't configurable and is designed to slot into
@@ -45,11 +61,12 @@ Is currently of the form:
 
 "devicename:colour:function"
 
-There have been calls for LED properties such as colour to be exported as
-individual led class attributes. As a solution which doesn't incur as much
-overhead, I suggest these become part of the device name. The naming scheme
-above leaves scope for further attributes should they be needed. If sections
-of the name don't apply, just leave that section blank.
+If the colour extension is used hsv / rgb can be used instead of a specific
+colour.  There have been calls for LED properties such as colour to be
+exported as individual led class attributes. As a solution which doesn't
+incur as much overhead, I suggest these become part of the device name.
+The naming scheme above leaves scope for further attributes should they be
+needed. If sections of the name don't apply, just leave that section blank.
 
 
 Brightness setting API
-- 
2.7.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

[PATCH v5 2/4] leds: core: add color LED sysfs extension

[Heiner Kallweit]

Extend brightness sysfs property handling to deal with monochrome
and color mode as well.

Signed-off-by: Heiner Kallweit 
---
v2:
- split from patch 1
v3:
- moved one change (led_is_off) to patch 1
v4:
- changed printf format string to %#.6x
v5:
- no changes
---
 drivers/leds/led-class.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 007a5b3..8a3748a 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -32,7 +32,10 @@ static ssize_t brightness_show(struct device *dev,
/* no lock needed for this */
led_update_brightness(led_cdev);
 
-   return sprintf(buf, "%u\n", led_cdev->brightness);
+   if (led_cdev->brightness > LED_FULL)
+   return sprintf(buf, "%#.6x\n", led_cdev->brightness);
+   else
+   return sprintf(buf, "%u\n", led_cdev->brightness);
 }
 
 static ssize_t brightness_store(struct device *dev,
@@ -49,7 +52,7 @@ static ssize_t brightness_store(struct device *dev,
goto unlock;
}
 
-   ret = kstrtoul(buf, 10, );
+   ret = kstrtoul(buf, 0, );
if (ret)
goto unlock;
 
-- 
2.7.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: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Tue, 1 Mar 2016, Daniel Fraga wrote:

> On Tue, 1 Mar 2016 10:25:30 -0500 (EST)
> Alan Stern  wrote:
> 
> > Now we're making progress!  That shows a problem right there; we ought 
> > to have more stuff about 3-1.6 between those two lines.
> > 
> > The next patch adds some more debugging output.  For this test you 
> > don't even have to suspend the system; all I need to see is the output 
> > for 3-1.6 during boot-up and shortly thereafter.
> 
>   No new messages during boot-up (I tried to reboot 3 times). I just got 
> the following:
> 
> Mar  1 16:33:55 tux kernel: [3.558535] usb 3-1.6: new full-speed USB 
> device number 6 using ehci-pci

No messages about "usbhid_start urb" or "no input endpoint!" or 
"usbhid_start fail urb"?  That means usbhid_start() isn't getting 
called.  Which means the device in question probably isn't being used 
at all.

Do you know what this device is?  What does 
/sys/kernel/debug/usb/devices show?

Let's make sure this is really what's happening.  Please try this 
patch.

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -1159,6 +1159,7 @@ static int usbhid_start(struct hid_devic
usbhid_set_leds(hid);
device_set_wakeup_enable(>dev, 1);
}
+   dev_info(>intf->dev, "usbhid_start -> 0, %p\n", usbhid->urbin);
return 0;
 
 fail:
@@ -1169,6 +1170,7 @@ fail:
usbhid->urbout = NULL;
usbhid->urbctrl = NULL;
hid_free_buffers(dev, hid);
+   dev_info(>intf->dev, "usbhid_start -> %d\n", ret);
return ret;
 }
 
@@ -1178,6 +1180,7 @@ static void usbhid_stop(struct hid_devic
 
if (WARN_ON(!usbhid))
return;
+   dev_info(>intf->dev, "usbhid_stop\n");
 
if (hid->quirks & HID_QUIRK_ALWAYS_POLL)
usbhid->intf->needs_remote_wakeup = 0;
@@ -1366,11 +1369,13 @@ static int usbhid_probe(struct usb_inter
goto err_free;
}
 
+   dev_info(>dev, "usbhid_probe -> %d\n", 0);
return 0;
 err_free:
kfree(usbhid);
 err:
hid_destroy_device(hid);
+   dev_info(>dev, "usbhid_probe -> %d\n", ret);
return ret;
 }
 

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

[PATCH v2] usb: serial: mos7840.c Support RS485 mode in B Electronics USOPTL4-4P and USOPTL4-2P

[Aaron Marburg]

The USOPTL4-4P and USOPTL4-2P USB-to-quad/dual RS-485/422 hubs use the 
Moschip 7840/7820.   For correct operation in RS-485, the chip must be 
configured in “RS-485 mode” through the scratchpad register as per the 
datasheet. This strobes the DTR line on transmission, enabling the driver 
on the RS485 transceiver chip.


Patch enables RS485 mode automatically for the USOPTL4-4P and USOPTL4-2P 
based on USB product ID.   It also includes a module command line option 
"force_rs485={0|1}" to manually force-enable (for all devices regardless 
of USB ID) and force-disable (for no devices, not even USOPTL*) the 
functionality.


Signed-off-by: Aaron Marburg 
---
Changes in v2:
   - Includes suggested formatting changes.

 drivers/usb/serial/mos7840.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 2c69bfc..29bb361 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -182,6 +182,9 @@
 #define LED_ON_MS  500
 #define LED_OFF_MS 500

+/* Kernel option to force RS485 mode which triggers the DTR on transmit */
+static int force_rs485 = -1;
+
 enum mos7840_flag {
MOS7840_FLAG_CTRL_BUSY,
MOS7840_FLAG_LED_BUSY,
@@ -853,6 +856,9 @@ static int mos7840_open(struct tty_struct *tty, struct 
usb_serial_port *port)
struct moschip_port *mos7840_port;
struct moschip_port *port0;

+   /* Req'd to check for RS485 devices and enable appropriate mode */
+   u16 product = le16_to_cpu(port->serial->dev->descriptor.idProduct);
+
if (mos7840_port_paranoia_check(port, __func__))
return -ENODEV;

@@ -991,6 +997,22 @@ static int mos7840_open(struct tty_struct *tty, struct 
usb_serial_port *port)
status = mos7840_set_uart_reg(port, LINE_CONTROL_REGISTER, Data);
mos7840_port->shadowLCR = Data;

+   if (force_rs485 != 0) {
+   if (force_rs485 == 1 ||
+   product == BANDB_DEVICE_ID_USOPTL4_4P ||
+   product == BANDB_DEVICE_ID_USOPTL4_2P) {
+
+   /* Enable RS485 mode by setting bytes in
+* scratchpad register:
+* 0x00  RS485 mode disabled
+* 0x80  = RS485 mode enabled, DTR Low on tx
+* 0xC0  = RS485 mode enabled, DTR High on tx
+*/
+   dev_notice(>dev, "Detected B Electronics USOPTL4_4P, 
enabling RS485 mode.\n");
+   status = mos7840_set_uart_reg(port, 
SCRATCH_PAD_REGISTER, 0xC0);
+   }
+   }
+
/* clearing Bulkin and Bulkout Fifo */
Data = 0x0;
status = mos7840_get_reg_sync(port, mos7840_port->SpRegOffset, );
@@ -2403,5 +2425,8 @@ static struct usb_serial_driver * const serial_drivers[] 
= {

 module_usb_serial_driver(serial_drivers, id_table);

+module_param(force_rs485, int, S_IRUGO);
+MODULE_PARM_DESC(force_rs845, "Force RS-485 mode (1 = force enable, 0 = force disable). 
 Otherwise automatically enabled for B Elec. USOPTL4-4P and USOPTL4-2P.");
+
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL");
--
1.9.1

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Tue, 1 Mar 2016 10:25:30 -0500 (EST)
Alan Stern  wrote:

> Now we're making progress!  That shows a problem right there; we ought 
> to have more stuff about 3-1.6 between those two lines.
> 
> The next patch adds some more debugging output.  For this test you 
> don't even have to suspend the system; all I need to see is the output 
> for 3-1.6 during boot-up and shortly thereafter.

Unless you want all the USB related lines (but as you can see, no line 
related 
to 3-1.6 device):

[2.409541] usbcore: registered new interface driver usbhid
[2.409544] usbhid: USB HID core driver
[4.978957] usbhid 1-1:1.0: usbhid_start urb 8802550c89c0
[6.063118] usbhid 3-1.3:1.0: usbhid_start urb 8802553de900
[6.113703] usbhid 3-1.3:1.1: usbhid_start urb 8802553de0c0
[6.165616] usbhid 3-1.4:1.0: usbhid_start urb 880253e82540
[   27.760614] usbhid 1-1:1.0: usbhid_stop urb 8802550c89c0
[   31.181268] usbhid 3-1.4:1.0: usbhid_stop urb 880253e82540
[   31.184302] usbhid 3-1.4:1.0: usbhid_start urb 8802551e3840
[   31.249291] usbhid 3-1.4:1.0: usbhid_stop urb 8802551e3840
[   32.185425] usbhid 3-1.4:1.0: usbhid_start urb 88009474a540
[   32.250251] usbhid 3-1.4:1.0: usbhid_stop urb 88009474a540
[   33.186774] usbhid 3-1.4:1.0: usbhid_start urb 880253f593c0
[   87.237292] usbhid 3-1.3:1.0: usbhid_stop urb 8802553de900
[   87.252257] usbhid 3-1.3:1.1: usbhid_stop urb 8802553de0c0
[   87.276263] usbhid 3-1.4:1.0: usbhid_stop urb 880253f593c0
[   88.310249] usbhid 3-1.3:1.0: usbhid_start urb 880252287900
[   88.368040] usbhid 3-1.3:1.1: usbhid_start urb 880253f2a900
[   88.584825] usbhid 3-1.4:1.0: usbhid_start urb 88009474a000

After the suspend test:

[  425.327979] usbhid 3-1.6:1.0: hid_cease_io urb   (null)
[  425.327993] usbhid 3-1.4:1.0: hid_cease_io urb 88009474a000
[  425.328001] usbhid 3-1.3:1.1: hid_cease_io urb 880253f2a900
[  425.330161] usbhid 3-1.3:1.0: hid_cease_io urb 880252287900
[  427.165478] usbhid 3-1.3:1.0: hid_start_in: urbin 880252287900
[  427.165500] usbhid 3-1.3:1.0: post reset hid_start_in -> 0
[  427.171082] usbhid 3-1.3:1.1: hid_start_in: urbin 880253f2a900
[  427.171089] usbhid 3-1.3:1.1: post reset hid_start_in -> 0
[  427.486326] usbhid 3-1.4:1.0: post reset hid_start_in -> 0
[  427.638818] usbhid 3-1.6:1.0: hid_start_in: urbin   (null)
[  427.638822] usbhid 3-1.6:1.0: start failed: -22
[  427.638824] usbhid 3-1.6:1.0: post reset hid_start_in -> -22
[  428.500552] usbhid 1-1:1.0: usbhid_start urb 88008704f0c0
[  428.665256] usbhid 3-1.6:1.0: hid_cease_io urb   (null)
[  428.828684] usbhid 3-1.6:1.0: hid_start_in: urbin   (null)
[  428.828688] usbhid 3-1.6:1.0: start failed: -22
[  428.828690] usbhid 3-1.6:1.0: post reset hid_start_in -> -22
[  428.828696] usbhid 3-1.6:1.0: hid_cease_io urb   (null)
[  428.981809] usbhid 3-1.6:1.0: hid_start_in: urbin   (null)
[  428.981814] usbhid 3-1.6:1.0: start failed: -22
[  428.981816] usbhid 3-1.6:1.0: post reset hid_start_in -> -22
[  428.981823] usbhid 3-1.6:1.0: hid_cease_io urb   (null)
[  429.134398] usbhid 3-1.6:1.0: hid_start_in: urbin   (null)

-- 
Linux 4.4.3-dirty: Blurry Fish Butt
http://exchangewar.info
--
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: serial: mos7840.c Support RS485 mode in B Electronics USOPTL4-4P and USOPTL4-2P

[Aaron Marburg]

Good question. The cmd line option is a tri-state:

(no command line option) -> force_rs485=-1 -> auto-detect based on product ID
force_rs485 = 0 -> never set RS485 mode (regardless of product ID)
force_rs485 = 1 -> always set RS485 mode (regardless of product ID)


> On Mar 1, 2016, at 11:38 AM, Sergei Shtylyov 
>  wrote:
> 
> Hello.
> 
> On 03/01/2016 08:54 PM, amarb...@apl.washington.edu wrote:
> 
>> From: Aaron Marburg 
>> 
>> The USOPTL4-4P and USOPTL4-2P USB-to-quad/dual RS-485/422 hubs use the
>> Moschip 7840/7820.   For correct operation in RS-485, the chip must be
>> configured in “RS-485 mode” through the scratchpad register as per the
>> datasheet. This strobes the DTR line on transmission, enabling the driver
>> on the RS485 transceiver chip.
>> 
>> Patch enables RS485 mode automatically for the USOPTL4-4P and USOPTL4-2P
>> based on USB product ID.   It also includes a module command line option
>> "force_rs485={0|1}" to manually force-enable (for all devices regardless
>> of USB ID) and force-disable (for no devices, not even USOPTL*) the
>> functionality.
>> 
>> Signed-off-by: Aaron Marburg 
>> 
>> ---
>>  drivers/usb/serial/mos7840.c | 25 +
>>  1 file changed, 25 insertions(+)
>> 
>> diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
>> index 2c69bfc..2356828 100644
>> --- a/drivers/usb/serial/mos7840.c
>> +++ b/drivers/usb/serial/mos7840.c
>> @@ -182,6 +182,9 @@
>> #define LED_ON_MS500
>> #define LED_OFF_MS   500
>> 
>> +/* Command-line option to force RS485 mode */
>> +static int force_rs485 = -1;
> 
>   Why not just 0 (and no initializer)?
> 
>> +
>> enum mos7840_flag {
>>  MOS7840_FLAG_CTRL_BUSY,
>>  MOS7840_FLAG_LED_BUSY,
> [...]
>> @@ -991,6 +997,22 @@ static int mos7840_open(struct tty_struct *tty, struct 
>> usb_serial_port *port)
>>  status = mos7840_set_uart_reg(port, LINE_CONTROL_REGISTER, Data);
>>  mos7840_port->shadowLCR = Data;
>> 
>> +if (!(force_rs485 == 0)) {
> 
>   Use != please. Or better still, just *if* (force).

Yes, of course this would be simpler.


> 
>> +if ((force_rs485 == 1) ||
>> +(product == BANDB_DEVICE_ID_USOPTL4_4P) ||
>> +(product == BANDB_DEVICE_ID_USOPTL4_2P)) {
>> +/* Enable RS485 mode by setting bytes in
>> + * scratchpad register:
>> + * 0x00  RS485 mode disabled
>> + * 0x80  = RS485 mode enabled, DTR Low on tx
>> + * 0xC0  = RS485 mode enabled, DTR High on tx
>> + */
>> +dev_notice(>dev, "Detected B Electronics 
>> USOPTL4_4P, enabling RS485 mode.\n");
>> +Data = 0xC0;
>> +status = mos7840_set_uart_reg(port, 
>> SCRATCH_PAD_REGISTER, Data);
>> +}
>> +}
>> +
>>  /* clearing Bulkin and Bulkout Fifo */
>>  Data = 0x0;
>>  status = mos7840_get_reg_sync(port, mos7840_port->SpRegOffset, );
>> @@ -2403,5 +2425,8 @@ static struct usb_serial_driver * const 
>> serial_drivers[] = {
>> 
>> module_usb_serial_driver(serial_drivers, id_table);
>> 
>> +module_param(force_rs485, int, S_IRUGO);
>> +MODULE_PARM_DESC(force_rs845, "Force RS-485 mode (1 = force enable, 0 = 
>> force enable).
> 
>   Both 0 and 1 enable? :-)

You are correct, should be 0 = force disable.



> 
>> Otherwise automatically enabled for B Elec. USOPTL4-4P and USOPTL4-2P.");
>> +
>> MODULE_DESCRIPTION(DRIVER_DESC);
>> MODULE_LICENSE("GPL");
>> -
> 
> [...]
> 
> MBR, Sergei



smime.p7s
Description: S/MIME cryptographic signature

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Tue, 1 Mar 2016 10:25:30 -0500 (EST)
Alan Stern  wrote:

> Now we're making progress!  That shows a problem right there; we ought 
> to have more stuff about 3-1.6 between those two lines.
> 
> The next patch adds some more debugging output.  For this test you 
> don't even have to suspend the system; all I need to see is the output 
> for 3-1.6 during boot-up and shortly thereafter.

No new messages during boot-up (I tried to reboot 3 times). I just got 
the following:

Mar  1 16:33:55 tux kernel: [3.558535] usb 3-1.6: new full-speed USB device 
number 6 using ehci-pci

So I did another suspend test:

Mar  1 16:41:19 tux kernel: [  479.374488] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Mar  1 16:41:19 tux kernel: [  479.465138] usbhid 3-1.6:1.0: hid_start_in: 
urbin   (null)
Mar  1 16:41:19 tux kernel: [  479.465143] usbhid 3-1.6:1.0: start failed: -22
Mar  1 16:41:20 tux kernel: [  479.465145] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22
Mar  1 16:41:20 tux kernel: [  479.465151] usbhid 3-1.6:1.0: hid_cease_io urb   
(null)
Mar  1 16:41:20 tux kernel: [  479.527491] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Mar  1 16:41:20 tux kernel: [  479.618014] usbhid 3-1.6:1.0: hid_start_in: 
urbin   (null)
Mar  1 16:41:20 tux kernel: [  479.618018] usbhid 3-1.6:1.0: start failed: -22
Mar  1 16:41:20 tux kernel: [  479.618020] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22
Mar  1 16:41:20 tux kernel: [  480.644543] usbhid 3-1.6:1.0: hid_cease_io urb   
(null)
Mar  1 16:41:20 tux kernel: [  480.717528] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Mar  1 16:41:20 tux kernel: [  480.807595] usbhid 3-1.6:1.0: hid_start_in: 
urbin   (null)
Mar  1 16:41:21 tux kernel: [  480.807598] usbhid 3-1.6:1.0: start failed: -22
Mar  1 16:41:21 tux kernel: [  480.807599] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22
Mar  1 16:41:21 tux kernel: [  480.807603] usbhid 3-1.6:1.0: hid_cease_io urb   
(null)

-- 
Linux 4.4.3-dirty: Blurry Fish Butt
http://exchangewar.info
--
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: serial: mos7840.c Support RS485 mode in B Electronics USOPTL4-4P and USOPTL4-2P

[Sergei Shtylyov]

On 03/01/2016 08:54 PM, amarb...@apl.washington.edu wrote:


From: Aaron Marburg 

The USOPTL4-4P and USOPTL4-2P USB-to-quad/dual RS-485/422 hubs use the
Moschip 7840/7820.   For correct operation in RS-485, the chip must be
configured in “RS-485 mode” through the scratchpad register as per the
datasheet. This strobes the DTR line on transmission, enabling the driver
on the RS485 transceiver chip.

Patch enables RS485 mode automatically for the USOPTL4-4P and USOPTL4-2P
based on USB product ID.   It also includes a module command line option
"force_rs485={0|1}" to manually force-enable (for all devices regardless
of USB ID) and force-disable (for no devices, not even USOPTL*) the
functionality.

Signed-off-by: Aaron Marburg 

---
  drivers/usb/serial/mos7840.c | 25 +
  1 file changed, 25 insertions(+)

diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 2c69bfc..2356828 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c

[...]


@@ -991,6 +997,22 @@ static int mos7840_open(struct tty_struct *tty, struct 
usb_serial_port *port)
status = mos7840_set_uart_reg(port, LINE_CONTROL_REGISTER, Data);
mos7840_port->shadowLCR = Data;

+   if (!(force_rs485 == 0)) {
+   if ((force_rs485 == 1) ||
+   (product == BANDB_DEVICE_ID_USOPTL4_4P) ||
+   (product == BANDB_DEVICE_ID_USOPTL4_2P)) {


   Parens not necessary. And please indent the continuation lines either to 
start at the next character after the first ( or by 2 extra tabs, so it's 
easier on the eyes, not blending with the following code.



+   /* Enable RS485 mode by setting bytes in
+* scratchpad register:
+* 0x00  RS485 mode disabled
+* 0x80  = RS485 mode enabled, DTR Low on tx
+* 0xC0  = RS485 mode enabled, DTR High on tx
+*/
+   dev_notice(>dev, "Detected B Electronics USOPTL4_4P, 
enabling RS485 mode.\n");
+   Data = 0xC0;
+   status = mos7840_set_uart_reg(port, 
SCRATCH_PAD_REGISTER, Data);


   Just write 0xC0, no need to set 'Data' beforehand.

[...]

MBR, 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: serial: mos7840.c Support RS485 mode in B Electronics USOPTL4-4P and USOPTL4-2P

[Sergei Shtylyov]

Hello.

On 03/01/2016 08:54 PM, amarb...@apl.washington.edu wrote:


From: Aaron Marburg 

The USOPTL4-4P and USOPTL4-2P USB-to-quad/dual RS-485/422 hubs use the
Moschip 7840/7820.   For correct operation in RS-485, the chip must be
configured in “RS-485 mode” through the scratchpad register as per the
datasheet. This strobes the DTR line on transmission, enabling the driver
on the RS485 transceiver chip.

Patch enables RS485 mode automatically for the USOPTL4-4P and USOPTL4-2P
based on USB product ID.   It also includes a module command line option
"force_rs485={0|1}" to manually force-enable (for all devices regardless
of USB ID) and force-disable (for no devices, not even USOPTL*) the
functionality.

Signed-off-by: Aaron Marburg 

---
  drivers/usb/serial/mos7840.c | 25 +
  1 file changed, 25 insertions(+)

diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 2c69bfc..2356828 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -182,6 +182,9 @@
 #define LED_ON_MS  500
 #define LED_OFF_MS 500

+/* Command-line option to force RS485 mode */
+static int force_rs485 = -1;


   Why not just 0 (and no initializer)?


+
 enum mos7840_flag {
MOS7840_FLAG_CTRL_BUSY,
MOS7840_FLAG_LED_BUSY,

[...]

@@ -991,6 +997,22 @@ static int mos7840_open(struct tty_struct *tty, struct 
usb_serial_port *port)
status = mos7840_set_uart_reg(port, LINE_CONTROL_REGISTER, Data);
mos7840_port->shadowLCR = Data;

+   if (!(force_rs485 == 0)) {


   Use != please. Or better still, just *if* (force).


+   if ((force_rs485 == 1) ||
+   (product == BANDB_DEVICE_ID_USOPTL4_4P) ||
+   (product == BANDB_DEVICE_ID_USOPTL4_2P)) {
+   /* Enable RS485 mode by setting bytes in
+* scratchpad register:
+* 0x00  RS485 mode disabled
+* 0x80  = RS485 mode enabled, DTR Low on tx
+* 0xC0  = RS485 mode enabled, DTR High on tx
+*/
+   dev_notice(>dev, "Detected B Electronics USOPTL4_4P, 
enabling RS485 mode.\n");
+   Data = 0xC0;
+   status = mos7840_set_uart_reg(port, 
SCRATCH_PAD_REGISTER, Data);
+   }
+   }
+
/* clearing Bulkin and Bulkout Fifo */
Data = 0x0;
status = mos7840_get_reg_sync(port, mos7840_port->SpRegOffset, );
@@ -2403,5 +2425,8 @@ static struct usb_serial_driver * const serial_drivers[] 
= {

 module_usb_serial_driver(serial_drivers, id_table);

+module_param(force_rs485, int, S_IRUGO);
+MODULE_PARM_DESC(force_rs845, "Force RS-485 mode (1 = force enable, 0 = force 
enable).


   Both 0 and 1 enable? :-)


Otherwise automatically enabled for B Elec. USOPTL4-4P and USOPTL4-2P.");
+
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL");
-


[...]

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

[PATCH] usb: serial: mos7840.c Support RS485 mode in B Electronics USOPTL4-4P and USOPTL4-2P

[amarburg]

From: Aaron Marburg 

The USOPTL4-4P and USOPTL4-2P USB-to-quad/dual RS-485/422 hubs use the 
Moschip 7840/7820.   For correct operation in RS-485, the chip must be 
configured in “RS-485 mode” through the scratchpad register as per the 
datasheet. This strobes the DTR line on transmission, enabling the driver 
on the RS485 transceiver chip.

Patch enables RS485 mode automatically for the USOPTL4-4P and USOPTL4-2P 
based on USB product ID.   It also includes a module command line option 
"force_rs485={0|1}" to manually force-enable (for all devices regardless 
of USB ID) and force-disable (for no devices, not even USOPTL*) the 
functionality.

Signed-off-by: Aaron Marburg 

---
 drivers/usb/serial/mos7840.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 2c69bfc..2356828 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -182,6 +182,9 @@
 #define LED_ON_MS  500
 #define LED_OFF_MS 500
 
+/* Command-line option to force RS485 mode */
+static int force_rs485 = -1;
+
 enum mos7840_flag {
MOS7840_FLAG_CTRL_BUSY,
MOS7840_FLAG_LED_BUSY,
@@ -853,6 +856,9 @@ static int mos7840_open(struct tty_struct *tty, struct 
usb_serial_port *port)
struct moschip_port *mos7840_port;
struct moschip_port *port0;
 
+   /* Req'd to check for RS485 devices and enable appropriate mode */
+   u16 product = le16_to_cpu(port->serial->dev->descriptor.idProduct);
+
if (mos7840_port_paranoia_check(port, __func__))
return -ENODEV;
 
@@ -991,6 +997,22 @@ static int mos7840_open(struct tty_struct *tty, struct 
usb_serial_port *port)
status = mos7840_set_uart_reg(port, LINE_CONTROL_REGISTER, Data);
mos7840_port->shadowLCR = Data;
 
+   if (!(force_rs485 == 0)) {
+   if ((force_rs485 == 1) ||
+   (product == BANDB_DEVICE_ID_USOPTL4_4P) ||
+   (product == BANDB_DEVICE_ID_USOPTL4_2P)) {
+   /* Enable RS485 mode by setting bytes in
+* scratchpad register:
+* 0x00  RS485 mode disabled
+* 0x80  = RS485 mode enabled, DTR Low on tx
+* 0xC0  = RS485 mode enabled, DTR High on tx 
+*/
+   dev_notice(>dev, "Detected B Electronics 
USOPTL4_4P, enabling RS485 mode.\n");
+   Data = 0xC0;
+   status = mos7840_set_uart_reg(port, 
SCRATCH_PAD_REGISTER, Data);
+   }
+   }
+
/* clearing Bulkin and Bulkout Fifo */
Data = 0x0;
status = mos7840_get_reg_sync(port, mos7840_port->SpRegOffset, );
@@ -2403,5 +2425,8 @@ static struct usb_serial_driver * const serial_drivers[] 
= {
 
 module_usb_serial_driver(serial_drivers, id_table);
 
+module_param(force_rs485, int, S_IRUGO);
+MODULE_PARM_DESC(force_rs845, "Force RS-485 mode (1 = force enable, 0 = force 
enable).  Otherwise automatically enabled for B Elec. USOPTL4-4P and 
USOPTL4-2P.");
+
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL");
-- 
1.9.1

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

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Alan Stern]

On Tue, 1 Mar 2016, Sedat Dilek wrote:

> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt  wrote:
> > On Sat, 3 Oct 2015 12:05:42 +0200
> > Sedat Dilek  wrote:
> >
> >> So, at the beginning... dunno WTF is causing the problems - no
> >> workaround for CLANG.
> >
> > Probably need to compile with gcc and with clang and look at the binary
> > differences. Or at least what objdump shows.
> >
> 
> [ Hope to address this issue to the correct people - CCed some people
> I taped on their nerves ]
> 
> Not sure if I should open a new thread?
> Please, some clear statements on this.
> Thanks.
> 
> The issue is still visible and alive.

...

> [ FACT #3: TEST-CASE #2 ]
> 
> The most reliable test-case is to simply unplug my external Logitech
> USB mouse - saw this by accident.
> YES, it was so simple.
> 
> --- dmesg_4.5.0-rc6-2-llvmlinux-amd64.txt   2016-02-29
> 21:23:56.399691975 +0100
> +++ dmesg_4.5.0-rc6-2-llvmlinux-amd64_usbmouse-unplugged.txt
> 2016-02-29 21:28:14.401832240 +0100
> @@ -832,3 +832,75 @@
>  [   66.529779] PPP BSD Compression module registered
>  [   66.563013] PPP Deflate Compression module registered
>  [   66.978977] usb 2-1.5: USB disconnect, device number 4
> +[  321.937369] usb 2-1.4: USB disconnect, device number 3
> +[  321.950810] BUG: sleeping function called from invalid context at
> kernel/workqueue.c:2785
> +[  321.950816] in_atomic(): 0, irqs_disabled(): 1, pid: 44, name: kworker/2:1

> +[  321.950885] hardirqs last  enabled at (47769):
> [] _raw_spin_unlock_irq+0x32/0x60
> +[  321.950889] hardirqs last disabled at (47770):
> [] del_timer_sync+0x3c/0x110
> +[  321.950894] softirqs last  enabled at (47112):
> [] __do_softirq+0x5a2/0x610
> +[  321.950898] softirqs last disabled at (47097):
> [] irq_exit+0x9c/0x120
> +[  321.950903] CPU: 2 PID: 44 Comm: kworker/2:1 Not tainted
> 4.5.0-rc6-2-llvmlinux-amd64 #1
> +[  321.950905] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> +[  321.950908] Workqueue: usb_hub_wq hub_event
> +[  321.950911]  8800d3326948 0092 
> 8800d4347568
> +[  321.950915]  814ba7d4 8800d43474f8 8800d4340cc0
> 8800d4347568
> +[  321.950919]  810e28fd 0092 0096
> 8800d43475a8
> +[  321.950923] Call Trace:
> +[  321.950927]  [] dump_stack+0xa4/0xf0
> +[  321.950931]  [] ? print_irqtrace_events+0xcd/0xe0
> +[  321.950936]  [] ___might_sleep+0x295/0x2b0
> +[  321.950939]  [] __might_sleep+0x4f/0xc0
> +[  321.950943]  [] start_flush_work+0x2f/0x2a0
> +[  321.950946]  [] flush_work+0x5c/0x80
> +[  321.950949]  [] ? flush_work+0x1a/0x80
> +[  321.950953]  [] ? trace_hardirqs_off+0xd/0x10
> +[  321.950956]  [] ? try_to_grab_pending+0x4a/0x260
> +[  321.950960]  [] __cancel_work_timer+0x197/0x290
> +[  321.950963]  [] ? try_to_del_timer_sync+0xad/0xc0
> +[  321.950966]  [] cancel_work_sync+0x18/0x20

It's possible that this could be a compiler-related error connected 
with local_irq_save().  __cancel_work_timer() calls 

ret = try_to_grab_pending(work, is_dwork, );

and try_to_grab_pending() starts this way:

static int try_to_grab_pending(struct work_struct *work, bool is_dwork,
   unsigned long *flags)
{
struct worker_pool *pool;
struct pool_workqueue *pwq;

local_irq_save(*flags);

Then later on, __cancel_work_timer() does

local_irq_restore(flags);

Maybe CLANG doesn't like local_irq_save() applied to a pointer as 
opposed to a stack variable.

As a quick test, try applying the patch below.  (Note that there is a 
similar construction in kernel/signal.c.)

Alan Stern



Index: usb-4.4/kernel/workqueue.c
===
--- usb-4.4.orig/kernel/workqueue.c
+++ usb-4.4/kernel/workqueue.c
@@ -1175,12 +1175,14 @@ out_put:
  * This function is safe to call from any context including IRQ handler.
  */
 static int try_to_grab_pending(struct work_struct *work, bool is_dwork,
-  unsigned long *flags)
+  unsigned long *pflags)
 {
struct worker_pool *pool;
struct pool_workqueue *pwq;
+   unsigned long flags;
 
-   local_irq_save(*flags);
+   local_irq_save(flags);
+   *pflags = flags;
 
/* try to steal the timer if it exists */
if (is_dwork) {
@@ -1241,7 +1243,7 @@ static int try_to_grab_pending(struct wo
}
spin_unlock(>lock);
 fail:
-   local_irq_restore(*flags);
+   local_irq_restore(flags);
if (work_is_canceling(work))
return -ENOENT;
cpu_relax();

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

Re: Fwd: USB gadget driver issue

[Alan Stern]

On Tue, 1 Mar 2016, Felipe Balbi wrote:

> Hi,
> 
> Robert Baldyga  writes:
> >> Olivier Schonken  writes:
> >>> Hope I'm not raising an issue which actually is my own stupidity.
> >>>
> >>> I recently upstreamed my embedded Linux kernel to version 4.4, after which
> >>> I started experiencing issues with my serial gadget - acm and obex.  I 
> >>> used
> >>> to be able to run a getty console on it through a systemd service, which
> >>> would restart everytime it was unplugged, and plugged in again.  With
> >>> kernel 4.4, this stopped working as usual(On startup console would word,
> >>> but if plugged out and in again, console is frozen), and I traced it back
> >>> to the series of patches "usb: gadget: introduce 'enabled' flag in struct
> >>> usb_ep".  If I revert these patches, everything works as normal again.  As
> >>> you are the owner of these patches, I thought that you might help me
> >>> understand if I'm doing something wrong w.r.t. re-initializing the console
> >>> getty, or if something really got broken.
> >> 
> >> This is short of email where the mailing list should be in Cc :-)
> >> 
> >> The author of that series was Robert (now in Cc). Robert, does this ring
> >> any bells to you ?
> >> 
> >
> > I have tested it with getty (without systemd) and it looks like getty
> > hangs up after replugging no matter if patch is applied or not, so
> > without systemd it won't work anyway.
> >
> > Hence how systemd handles this is the key here, however I have no idea
> > how systemd knows that USB device is unplugged. On device side
> > /dev/ttyGS0 exists regardless to ACM function state, so process which
> > opened this device file has no way to figure out whether connection to
> > host is active or not. Can you explain how systemd knows that device is
> > unplugged? This knowledge can be helpful.
> 
> there should be a SIGHUP when cable's removed, no ?

More to the point, udev is now part of systemd, and udev certainly 
knows when a device has been added or removed.  It gets messages 
directly from the kernel whenever one of those events occurs.

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: Spurious Mass Storage Device Resets

[Alan Stern]

On Mon, 29 Feb 2016, Rian Hunter wrote:

> Hello,
> 
> I own a JBOD SATA<->USB 3.0 bridge. All information about this device 
> and my kernel version is below.
> 
> My trouble is that every so often this device will undergo a virtual 
> USB disconnect and then be reconnected. This will cause all drives to 
> disappear and reappear on the system. All previously mounted file 
> systems will have to be remounted.
> 
> Here is the relevant dmesg upon initially plugging in the device:
> 
> [400295.378851] usb 2-3: new SuperSpeed USB device number 3 using xhci_hcd
> [400295.396512] usb 2-3: New USB device found, idVendor=152d, idProduct=0567
> [400295.396524] usb 2-3: New USB device strings: Mfr=10, Product=11, 
> SerialNumber=5
> [400295.396531] usb 2-3: Product: USB to ATA/ATAPI Bridge
> [400295.396537] usb 2-3: Manufacturer: JMicron
> [400295.396542] usb 2-3: SerialNumber: 152D00539000
> [400295.398121] usb-storage 2-3:1.0: USB Mass Storage device detected
> [400295.402320] usb-storage 2-3:1.0: Quirks match for vid 152d pid 0567: 
> 500
> [400295.402399] scsi host4: usb-storage 2-3:1.0
> [400296.401394] scsi 4:0:0:0: Direct-Access WL1000GS A6472
> 0125 PQ: 0 ANSI: 6
> [400296.402428] scsi 4:0:0:1: Direct-Access WL1000GS A6472
> 0125 PQ: 0 ANSI: 6
> [400296.403322] scsi 4:0:0:2: Direct-Access WL1000GS A6472
> 0125 PQ: 0 ANSI: 6
> [400296.404113] scsi 4:0:0:3: Direct-Access WL1000GS A6472
> 0125 PQ: 0 ANSI: 6
> [400296.404920] scsi 4:0:0:4: Direct-Access WL1000GS A6472
> 0125 PQ: 0 ANSI: 6
> [400296.405762] scsi 4:0:0:5: Direct-Access ST2000DL 004 HD204UI  
> 0125 PQ: 0 ANSI: 6
> [400296.406576] scsi 4:0:0:6: Direct-Access WL1000GS A6472
> 0125 PQ: 0 ANSI: 6
> 
> Here is the relevant dmesg when the device disconnects:
> 
> [383320.013453] usb 2-3: reset SuperSpeed USB device number 2 using xhci_hcd
> [383337.784897] usb 2-3: reset SuperSpeed USB device number 2 using xhci_hcd
...
> [396598.497860] usb 2-3: reset SuperSpeed USB device number 2 using xhci_hcd
> [399452.105930] xhci_hcd :00:14.0: WARN Event TRB for slot 3 ep 2 with no 
> TDs queued?
> [399821.971271] usb 2-3: reset SuperSpeed USB device number 2 using xhci_hcd
> [399955.972112] usb 2-3: reset SuperSpeed USB device number 2 using xhci_hcd
> [399956.184142] usb 2-3: reset SuperSpeed USB device number 2 using xhci_hcd
> [400266.037316] usb 2-3: Device not responding to setup address.
> [400266.244922] usb 2-3: Device not responding to setup address.
> [400266.445391] usb 2-3: device not accepting address 2, error -71
> [400270.434213] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
> [400274.422951] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
> [400278.411675] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
> [400278.412144] usb 2-3: USB disconnect, device number 2
> 
> Afterward the device connects again.
> 
> Another user of this same hardware claims that this happens when the 
> bridge encounters a faulty (or slow-to-respond) HDD. When the HDD is 
> slow to respond, the bridge resets 
> itself. (http://forum.mediasonic.ca/viewtopic.php?f=58=3115#p13119)
> 
> Initially I accepted this explanation but now I am starting to 
> question it. For one, all of my HDDs seem to be in good shape 
> according to their S.M.A.R.T. attributes and S.M.A.R.T. self-checks.
> 
> Another thing that looks fishy to me are the excessive "reset" 
> messages in dmesg. Looks like sometimes the reset works and sometimes 
> it doesn't. There are many reset attempts in this specific dmesg but 
> in previous resets there could be as few as one.
> 
> My current guess is some kind of spurious error is happening in 
> usb_stor_invoke_transport(), causing a call to usb_stor_port_reset(), 
> usb_reset_device(), usb_reset_and_verify_device(), and ultimately 
> hub_port_init(), which is causing the "reset" message. My guess 
> is that the kernel is timing out on a USB command to the device, 
> invoking a reset, and then timing out on a successful reset since the 
> device may still be busy doing something else.
> 
> Is this possible? Does the USB stack call reset on a command timeout? 

Well, the combination of usb-storage and the SCSI stack does.  
usb-storage itself doesn't have any notion of commands timing out; it
merely does a reset whenever the SCSI stack tells it to abort an
ongoing command.

> Is there a way to increase such a timeout?

No.  The values are already extremely generous.  For example, reading 
240 KB (!) has a 30-second timeout.

> Additionally, I'm not sure what the "WARN" line means.

I don't think it's particularly relevant.  Also, I remember seeing 
something about changing it (or the conditions under which it gets 
printed) recently.

Anyway, you can get more information about the resets and their causes 
if you collect a usbmon trace.  See Documentation/usb/usbmon.txt for 
instructions.

Alan Stern

--
To 

Re: NEC uPD720200 xHCI Controller dies when Runtime PM enabled

[Mathias Nyman]

On 18.02.2016 18:34, Mike Murdoch wrote:



On 2016-02-18 16:12, Mathias Nyman wrote:

On 16.02.2016 23:58, main.ha...@googlemail.com wrote:



On 2016-02-08 15:31, Mathias Nyman wrote:

Hi

On 06.02.2016 19:08, Mike Murdoch wrote:

Bug ID: 111251

Hello,

I have a NEC uPD720200 USB3.0 controller in a Thinkpad W520 laptop on
kernel 4.4.1-gentoo.

0e:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
Controller (rev 04) (prog-if 30 [XHCI])
   Subsystem: Lenovo uPD720200 USB 3.0 Host Controller

When runtime power control for this controller is disabled
(/sys/bus/pci/devices/:0e:00.0/power/control = on), the controller
works fine and reaches over 120MB/s transfer rates.

When runtime power control for this controller is enabled
(/sys/bus/pci/devices/:0e:00.0/power/control = auto), two effects
can be observed:

- Transfer rates are much lower at around 30MB/s
- During transfers, the controller dies after a couple of seconds:

At this point, a reboot is required to reactivate the controller,
unloading and reloading the xhci_* modules does not work.





...

I did some more digging, there are a few things that need to be addressed:
1. We should resume USB3 bus before USB2 bus to let devices enumerate as USB3 
better,
   this gives them more time to finish the link training.

2. After resuming xhci we don't see any port changes immediately, hub thinks 
nothing
   happended and stops polling the ports, hub will suspend again -> xhci will 
try to
   suspend.   


3. Roothubs will autosuspend immediately after autoresume, (autosuspend timeout 
= 0)
   This could be a reason why we see the "xhci_suspend" entry in the log. We 
either
   need to increase the autosuspend timeout, or prevent suspend if we can see 
the pending
   event in a xhci status register.
 
inserting usb3 storage device

Feb 16 20:03:33 xhci_hcd :0e:00.0: // Setting command ring address to 
0xe001
Feb 16 20:03:33 xhci_hcd :0e:00.0: xhci_resume: starting port polling.
Feb 16 20:03:33 xhci_hcd :0e:00.0: xhci_hub_status_data: stopping port 
polling.
Feb 16 20:03:33 xhci_hcd :0e:00.0: xhci_suspend: stopping port polling.

I got a few patches, attached. They both partially try to fix the issue, and 
add more logging.
Same changes can be found in a topic branch from in:

git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git 
bug_usb3_enum_rtresume

Any chance to try them out?

-Mathias
>From 4427456ee6228155e72f38c740e0bf78c8ad7792 Mon Sep 17 00:00:00 2001
From: Mathias Nyman 
Date: Mon, 29 Feb 2016 11:33:25 +0200
Subject: [PATCH 1/3] xhci: resume USB 3 roothub first

Give USB 3 devices a better chance to enumerate at USB 3 speeds if
they are connected to a suspended host.

Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index d51ee0c..b609288 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1108,8 +1108,8 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
 		/* Resume root hubs only when have pending events. */
 		status = readl(>op_regs->status);
 		if (status & STS_EINT) {
-			usb_hcd_resume_root_hub(hcd);
 			usb_hcd_resume_root_hub(xhci->shared_hcd);
+			usb_hcd_resume_root_hub(hcd);
 		}
 	}
 
@@ -1124,10 +1124,10 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
 
 	/* Re-enable port polling. */
 	xhci_dbg(xhci, "%s: starting port polling.\n", __func__);
-	set_bit(HCD_FLAG_POLL_RH, >flags);
-	usb_hcd_poll_rh_status(hcd);
 	set_bit(HCD_FLAG_POLL_RH, >shared_hcd->flags);
 	usb_hcd_poll_rh_status(xhci->shared_hcd);
+	set_bit(HCD_FLAG_POLL_RH, >flags);
+	usb_hcd_poll_rh_status(hcd);
 
 	return retval;
 }
-- 
1.9.1

>From a37d2160f8e801fe8ba3c1a4938f0fa17d56de7b Mon Sep 17 00:00:00 2001
From: Mathias Nyman 
Date: Mon, 29 Feb 2016 16:07:03 +0200
Subject: [PATCH 2/3] xhci: Add bus number to debug output

Debugging enumeration races between usb USB2 and USB3 buses
are hard to debug when there is no indication of what message
belongs to which bus.

Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-hub.c  | 26 ++
 drivers/usb/host/xhci-ring.c |  8 +---
 drivers/usb/host/xhci.c  |  2 +-
 3 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index d61fcc4..8e61925 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -458,8 +458,8 @@ static void xhci_disable_port(struct usb_hcd *hcd, struct xhci_hcd *xhci,
 	/* Write 1 to disable the port */
 	writel(port_status | PORT_PE, addr);
 	port_status = readl(addr);
-	xhci_dbg(xhci, "disable port, actual port %d status  = 0x%x\n",
-			wIndex, port_status);
+	xhci_dbg(xhci, "disable port, bus%d port %d portsc  = 0x%x\n",
+		 hcd->self.busnum, 

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Mon, 29 Feb 2016, Daniel Fraga wrote:

> On Mon, 29 Feb 2016 16:28:40 -0500 (EST)
> Alan Stern  wrote:
> 
> > Okay, that's what I had guessed.  Somehow usbhid->urbin is getting set 
> > to NULL.  Maybe the patch below will indicate why.  When you post the 
> > log, include everything that mentions the 3-1.6 device -- even if they 
> > precede the suspend test.
> 
>   Ok, before the suspend test:
> 
> Feb 29 18:40:47 tux kernel: [3.512861] usb 3-1.6: new full-speed USB 
> device number 6 using ehci-pci
> Feb 29 18:41:55 tux kernel: [  118.890031] usbhid 3-1.6:1.0: hid_cease_io urb 
>   (null)

Now we're making progress!  That shows a problem right there; we ought 
to have more stuff about 3-1.6 between those two lines.

The next patch adds some more debugging output.  For this test you 
don't even have to suspend the system; all I need to see is the output 
for 3-1.6 during boot-up and shortly thereafter.

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -75,7 +75,7 @@ static int hid_submit_ctrl(struct hid_de
 static void hid_cancel_delayed_stuff(struct usbhid_device *usbhid);
 
 /* Start up the input URB */
-static int hid_start_in(struct hid_device *hid)
+static int hid_start_in(struct hid_device *hid, int alantest)
 {
unsigned long flags;
int rc = 0;
@@ -86,8 +86,12 @@ static int hid_start_in(struct hid_devic
!test_bit(HID_DISCONNECTED, >iofl) &&
!test_bit(HID_SUSPENDED, >iofl) &&
!test_and_set_bit(HID_IN_RUNNING, >iofl)) {
+   if (alantest)
+   dev_info(>intf->dev, "hid_start_in: urbin 
%p\n", usbhid->urbin);
rc = usb_submit_urb(usbhid->urbin, GFP_ATOMIC);
if (rc != 0) {
+   if (alantest)
+   dev_info(>intf->dev, "start failed: 
%d\n", rc);
clear_bit(HID_IN_RUNNING, >iofl);
if (rc == -ENOSPC)
set_bit(HID_NO_BANDWIDTH, >iofl);
@@ -106,7 +110,7 @@ static void hid_retry_timeout(unsigned l
struct usbhid_device *usbhid = hid->driver_data;
 
dev_dbg(>intf->dev, "retrying intr urb\n");
-   if (hid_start_in(hid))
+   if (hid_start_in(hid, 0))
hid_io_error(hid);
 }
 
@@ -123,7 +127,7 @@ static void hid_reset(struct work_struct
rc = usb_clear_halt(hid_to_usb_dev(hid), usbhid->urbin->pipe);
clear_bit(HID_CLEAR_HALT, >iofl);
if (rc == 0) {
-   hid_start_in(hid);
+   hid_start_in(hid, 0);
} else {
dev_dbg(>intf->dev,
"clear-halt failed: %d\n", rc);
@@ -690,7 +694,7 @@ int usbhid_open(struct hid_device *hid)
}
usbhid->intf->needs_remote_wakeup = 1;
set_bit(HID_RESUME_RUNNING, >iofl);
-   res = hid_start_in(hid);
+   res = hid_start_in(hid, 0);
if (res) {
if (res != -ENOSPC) {
hid_io_error(hid);
@@ -1100,6 +1104,7 @@ static int usbhid_start(struct hid_devic
continue;
if (!(usbhid->urbin = usb_alloc_urb(0, GFP_KERNEL)))
goto fail;
+   dev_info(>dev, "usbhid_start urb %p\n", 
usbhid->urbin);
pipe = usb_rcvintpipe(dev, endpoint->bEndpointAddress);
usb_fill_int_urb(usbhid->urbin, dev, pipe, 
usbhid->inbuf, insize,
 hid_irq_in, hid, interval);
@@ -1117,6 +1122,8 @@ static int usbhid_start(struct hid_devic
usbhid->urbout->transfer_flags |= 
URB_NO_TRANSFER_DMA_MAP;
}
}
+   if (!usbhid->urbin)
+   dev_info(>dev, "no input endpoint!\n");
 
usbhid->urbctrl = usb_alloc_urb(0, GFP_KERNEL);
if (!usbhid->urbctrl) {
@@ -1139,7 +1146,7 @@ static int usbhid_start(struct hid_devic
if (ret)
goto fail;
usbhid->intf->needs_remote_wakeup = 1;
-   ret = hid_start_in(hid);
+   ret = hid_start_in(hid, 1);
if (ret) {
dev_err(>dev,
"failed to start in urb: %d\n", ret);
@@ -1162,6 +1169,7 @@ static int usbhid_start(struct hid_devic
return 0;
 
 fail:
+   dev_info(>dev, "usbhid_start fail urb %p\n", usbhid->urbin);
usb_free_urb(usbhid->urbin);
usb_free_urb(usbhid->urbout);
usb_free_urb(usbhid->urbctrl);
@@ -1194,6 +1202,7 @@ static void usbhid_stop(struct 

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Peter Zijlstra]

On Tue, Mar 01, 2016 at 10:07:40AM -0500, Steven Rostedt wrote:
> On Tue, 1 Mar 2016 11:05:42 +0100
> Sedat Dilek  wrote:
> 
> 
> > [ FACT #3: TEST-CASE #2 ]
> > 
> > The most reliable test-case is to simply unplug my external Logitech
> > USB mouse - saw this by accident.
> > YES, it was so simple.
> 
> Just to clarify, this happens on gcc and clang?

Just clang from what I gather.

> > --- dmesg_4.5.0-rc6-2-llvmlinux-amd64.txt   2016-02-29
> > 21:23:56.399691975 +0100
> > +++ dmesg_4.5.0-rc6-2-llvmlinux-amd64_usbmouse-unplugged.txt
> > 2016-02-29 21:28:14.401832240 +0100
> > @@ -832,3 +832,75 @@
> >  [   66.529779] PPP BSD Compression module registered
> >  [   66.563013] PPP Deflate Compression module registered
> >  [   66.978977] usb 2-1.5: USB disconnect, device number 4
> > +[  321.937369] usb 2-1.4: USB disconnect, device number 3
> > +[  321.950810] BUG: sleeping function called from invalid context at
> > kernel/workqueue.c:2785
> > +[  321.950816] in_atomic(): 0, irqs_disabled(): 1, pid: 44, name: 
> > kworker/2:1
> > +[  321.950819] 9 locks held by kworker/2:1/44:
> > +[  321.950820]  #0:  ("usb_hub_wq"){.+.+.+}, at: []
> > process_one_work+0x30f/0x8d0
> > +[  321.950830]  #1:  ((>events)){+.+.+.}, at:
> > [] process_one_work+0x33c/0x8d0
> > +[  321.950836]  #2:  (>mutex){..}, at: []
> > hub_event+0x50/0x15b0
> > +[  321.950844]  #3:  (>mutex){..}, at: []
> > usb_disconnect+0x5f/0x2c0
> > +[  321.950849]  #4:  (>mutex){..}, at: []
> > device_release_driver+0x22/0x40
> > +[  321.950856]  #5:  (>mutex){..}, at: []
> > device_release_driver+0x22/0x40
> > +[  321.950862]  #6:  (input_mutex){+.+.+.}, at: []
> > __input_unregister_device+0x9a/0x190
> > +[  321.950869]  #7:  (>mutex#2){+.+...}, at:
> > [] input_close_device+0x27/0x70
> > +[  321.950875]  #8:  (hid_open_mut){+.+...}, at: []
> > usbhid_close+0x28/0xb0 [usbhid]
> > +[  321.950883] irq event stamp: 47770
> > +[  321.950885] hardirqs last  enabled at (47769):
> > [] _raw_spin_unlock_irq+0x32/0x60
> > +[  321.950889] hardirqs last disabled at (47770):
> > [] del_timer_sync+0x3c/0x110
> 
> According to lockdep, interrupts were last disabled in del_timer_sync,
> and they were never enabled. The numbers in parenthesis show the order
> of events. _raw_spin_unlock_irq() at 47769, then del_timer_sync at
> 47770.
> 
> But why did they not get enabled again? We have:
> 
>   local_irq_save(flags);
>   lock_map_acquire(>lockdep_map);
>   lock_map_release(>lockdep_map);
>   local_irq_restore(flags);
> 
> If this caused an issue, then you would have a lockdep splat. But
> perhaps something corrupted "flags", and interrupts were not re-enabled?

Right, most odd. Sedat, could you provide objdump -D of the relevant
sections of vmlinux ?
--
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] usbhid: Fix lockdep unannotated irqs-off warning

[Steven Rostedt]

On Tue, 1 Mar 2016 11:05:42 +0100
Sedat Dilek  wrote:


> [ FACT #3: TEST-CASE #2 ]
> 
> The most reliable test-case is to simply unplug my external Logitech
> USB mouse - saw this by accident.
> YES, it was so simple.

Just to clarify, this happens on gcc and clang?


> 
> --- dmesg_4.5.0-rc6-2-llvmlinux-amd64.txt   2016-02-29
> 21:23:56.399691975 +0100
> +++ dmesg_4.5.0-rc6-2-llvmlinux-amd64_usbmouse-unplugged.txt
> 2016-02-29 21:28:14.401832240 +0100
> @@ -832,3 +832,75 @@
>  [   66.529779] PPP BSD Compression module registered
>  [   66.563013] PPP Deflate Compression module registered
>  [   66.978977] usb 2-1.5: USB disconnect, device number 4
> +[  321.937369] usb 2-1.4: USB disconnect, device number 3
> +[  321.950810] BUG: sleeping function called from invalid context at
> kernel/workqueue.c:2785
> +[  321.950816] in_atomic(): 0, irqs_disabled(): 1, pid: 44, name: kworker/2:1
> +[  321.950819] 9 locks held by kworker/2:1/44:
> +[  321.950820]  #0:  ("usb_hub_wq"){.+.+.+}, at: []
> process_one_work+0x30f/0x8d0
> +[  321.950830]  #1:  ((>events)){+.+.+.}, at:
> [] process_one_work+0x33c/0x8d0
> +[  321.950836]  #2:  (>mutex){..}, at: []
> hub_event+0x50/0x15b0
> +[  321.950844]  #3:  (>mutex){..}, at: []
> usb_disconnect+0x5f/0x2c0
> +[  321.950849]  #4:  (>mutex){..}, at: []
> device_release_driver+0x22/0x40
> +[  321.950856]  #5:  (>mutex){..}, at: []
> device_release_driver+0x22/0x40
> +[  321.950862]  #6:  (input_mutex){+.+.+.}, at: []
> __input_unregister_device+0x9a/0x190
> +[  321.950869]  #7:  (>mutex#2){+.+...}, at:
> [] input_close_device+0x27/0x70
> +[  321.950875]  #8:  (hid_open_mut){+.+...}, at: []
> usbhid_close+0x28/0xb0 [usbhid]
> +[  321.950883] irq event stamp: 47770
> +[  321.950885] hardirqs last  enabled at (47769):
> [] _raw_spin_unlock_irq+0x32/0x60
> +[  321.950889] hardirqs last disabled at (47770):
> [] del_timer_sync+0x3c/0x110

According to lockdep, interrupts were last disabled in del_timer_sync,
and they were never enabled. The numbers in parenthesis show the order
of events. _raw_spin_unlock_irq() at 47769, then del_timer_sync at
47770.

But why did they not get enabled again? We have:

local_irq_save(flags);
lock_map_acquire(>lockdep_map);
lock_map_release(>lockdep_map);
local_irq_restore(flags);

If this caused an issue, then you would have a lockdep splat. But
perhaps something corrupted "flags", and interrupts were not re-enabled?

> +[  321.950894] softirqs last  enabled at (47112):
> [] __do_softirq+0x5a2/0x610
> +[  321.950898] softirqs last disabled at (47097):
> [] irq_exit+0x9c/0x120
> +[  321.950903] CPU: 2 PID: 44 Comm: kworker/2:1 Not tainted
> 4.5.0-rc6-2-llvmlinux-amd64 #1
> +[  321.950905] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> +[  321.950908] Workqueue: usb_hub_wq hub_event
> +[  321.950911]  8800d3326948 0092 
> 8800d4347568
> +[  321.950915]  814ba7d4 8800d43474f8 8800d4340cc0
> 8800d4347568
> +[  321.950919]  810e28fd 0092 0096
> 8800d43475a8
> +[  321.950923] Call Trace:
> +[  321.950927]  [] dump_stack+0xa4/0xf0
> +[  321.950931]  [] ? print_irqtrace_events+0xcd/0xe0
> +[  321.950936]  [] ___might_sleep+0x295/0x2b0
> +[  321.950939]  [] __might_sleep+0x4f/0xc0

This triggered on the might_sleep() in start_flush_work() because
something left interrupts enable.

Just strange.

-- Steve


> +[  321.950943]  [] start_flush_work+0x2f/0x2a0
> +[  321.950946]  [] flush_work+0x5c/0x80
> +[  321.950949]  [] ? flush_work+0x1a/0x80
> +[  321.950953]  [] ? trace_hardirqs_off+0xd/0x10
> +[  321.950956]  [] ? try_to_grab_pending+0x4a/0x260
> +[  321.950960]  [] __cancel_work_timer+0x197/0x290
> +[  321.950963]  [] ? try_to_del_timer_sync+0xad/0xc0
> +[  321.950966]  [] cancel_work_sync+0x18/0x20
> +[  321.950970]  [] usbhid_close+0x75/0xb0 [usbhid]
> +[  321.950977]  [] hidinput_close+0x31/0x40 [hid]
> +[  321.950982]  [] ? hidinput_open+0x40/0x40 [hid]
> +[  321.950985]  [] input_close_device+0x48/0x70
> +[  321.950988]  [] evdev_cleanup+0xd5/0xe0
> +[  321.950990]  [] evdev_disconnect+0x2c/0x60
> +[  321.950993]  [] __input_unregister_device+0xbe/0x190
> +[  321.950996]  [] input_unregister_device+0x4a/0x80
> +[  321.951001]  [] hidinput_disconnect+0x8f/0xc0 [hid]
> +[  321.951007]  [] hid_device_remove+0xb0/0x130 [hid]
> +[  321.951010]  [] __device_release_driver+0xfd/0x190
> +[  321.951014]  [] device_release_driver+0x2a/0x40
> +[  321.951017]  [] bus_remove_device+0x153/0x190
> +[  321.951020]  [] device_del+0x1db/0x2b0
> +[  321.951025]  [] hid_destroy_device+0x2c/0x60 [hid]
> +[  321.951029]  [] usbhid_disconnect+0x67/0x90 [usbhid]
> +[  321.951033]  [] usb_unbind_interface+0xbf/0x2b0
> +[  321.951037]  [] __device_release_driver+0xfd/0x190
> +[  321.951040]  [] device_release_driver+0x2a/0x40
> +[  

[PATCH] USB: qcserial: add Sierra Wireless EM74xx device ID

[Bjørn Mork]

The MC74xx and EM74xx modules use different IDs by default, according
to the Lenovo EM7455 driver for Windows.

Cc: 
Signed-off-by: Bjørn Mork 
---
 drivers/usb/serial/qcserial.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 9919d2a9faf2..f05d786f6749 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -157,8 +157,10 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x1199, 0x9056)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9060)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9061)},   /* Sierra Wireless Modem */
-   {DEVICE_SWI(0x1199, 0x9070)},   /* Sierra Wireless MC74xx/EM74xx */
-   {DEVICE_SWI(0x1199, 0x9071)},   /* Sierra Wireless MC74xx/EM74xx */
+   {DEVICE_SWI(0x1199, 0x9070)},   /* Sierra Wireless MC74xx */
+   {DEVICE_SWI(0x1199, 0x9071)},   /* Sierra Wireless MC74xx */
+   {DEVICE_SWI(0x1199, 0x9078)},   /* Sierra Wireless EM74xx */
+   {DEVICE_SWI(0x1199, 0x9079)},   /* Sierra Wireless EM74xx */
{DEVICE_SWI(0x413c, 0x81a2)},   /* Dell Wireless 5806 Gobi(TM) 4G LTE 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a3)},   /* Dell Wireless 5570 HSPA+ (42Mbps) 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
Mobile Broadband Card */
-- 
2.1.4

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

[PATCH net,stable] qmi_wwan: add Sierra Wireless EM74xx device ID

[Bjørn Mork]

The MC74xx and EM74xx modules use different IDs by default, according
to the Lenovo EM7455 driver for Windows.

Signed-off-by: Bjørn Mork 
---
 drivers/net/usb/qmi_wwan.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 4ce4ec16e968..a3a4ccf7cf52 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -861,8 +861,10 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x9056, 8)},/* Sierra Wireless Modem */
{QMI_FIXED_INTF(0x1199, 0x9057, 8)},
{QMI_FIXED_INTF(0x1199, 0x9061, 8)},/* Sierra Wireless Modem */
-   {QMI_FIXED_INTF(0x1199, 0x9071, 8)},/* Sierra Wireless 
MC74xx/EM74xx */
-   {QMI_FIXED_INTF(0x1199, 0x9071, 10)},   /* Sierra Wireless 
MC74xx/EM74xx */
+   {QMI_FIXED_INTF(0x1199, 0x9071, 8)},/* Sierra Wireless MC74xx */
+   {QMI_FIXED_INTF(0x1199, 0x9071, 10)},   /* Sierra Wireless MC74xx */
+   {QMI_FIXED_INTF(0x1199, 0x9079, 8)},/* Sierra Wireless EM74xx */
+   {QMI_FIXED_INTF(0x1199, 0x9079, 10)},   /* Sierra Wireless EM74xx */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
(Alcatel One Touch L100V LTE) */
{QMI_FIXED_INTF(0x1bbb, 0x0203, 2)},/* Alcatel L800MA */
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
-- 
2.1.4

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

Re: [PATCH] usb: gadget: f_acm: Fix configfs attr name

[Christoph Hellwig]

On Tue, Mar 01, 2016 at 12:47:11PM +0100, Krzysztof Opasiak wrote:
> Correct attribute name is port_num not num.
> 
> Signed-off-by: Krzysztof Opasiak 
> Fixes: ea6bd6b ("usb-gadget/f_acm: use per-attribute show and store methods")

My fault, sorry.

Reviewed-by: Christoph Hellwig 
--
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: gadget: f_acm: Fix configfs attr name

[Krzysztof Opasiak]

Correct attribute name is port_num not num.

Signed-off-by: Krzysztof Opasiak 
Fixes: ea6bd6b ("usb-gadget/f_acm: use per-attribute show and store methods")
---
 drivers/usb/gadget/function/f_acm.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_acm.c 
b/drivers/usb/gadget/function/f_acm.c
index 2fa1e80..3df4c72 100644
--- a/drivers/usb/gadget/function/f_acm.c
+++ b/drivers/usb/gadget/function/f_acm.c
@@ -777,10 +777,10 @@ static ssize_t f_acm_port_num_show(struct config_item 
*item, char *page)
return sprintf(page, "%u\n", to_f_serial_opts(item)->port_num);
 }
 
-CONFIGFS_ATTR_RO(f_acm_port_, num);
+CONFIGFS_ATTR_RO(f_acm_, port_num);
 
 static struct configfs_attribute *acm_attrs[] = {
-   _acm_port_attr_num,
+   _acm_attr_port_num,
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

Re: [PATCH] usb: phy: generic: Handle late registration of gadget

[Felipe Balbi]

Hi,

Maarten ter Huurne  writes:
> It is possible for the VBUS detect GPIO interrupt to occur before
> nop_set_peripheral() is called, in which case otg->gadget is NULL.
>
> Signed-off-by: Maarten ter Huurne 

wonder if it would be best to guarantee this doesn't happen in the first
place, but I guess that would be too complex anyhow. I'll apply this as
is for now.

-- 
balbi


signature.asc
Description: PGP signature

Re: Page allocation failure (order 7) in UAS code

[Yves-Alexis Perez]

On mar., 2016-03-01 at 11:49 +0100, Hans de Goede wrote:
> Can you try building a kernel with the following line in
> drivers/usb/storage/uas.c :
> 
>  .can_queue = 65536, /* Is there a limit on the _host_ ? */
> 
> (around line 815) Replaced with
> 
>  .can_queue = MAX_CMNDS,
> 
> That should help as MAX_CMNDS is 256, so claiming that we can queue more
> is not helpful, and that likely is what is causing this quite high order
> alloc.

Hi,

I've rebuilt a 4.4.3 + above patch. I'll report back in few hours to see if I
can still reproduce.

Regards,
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Re: Page allocation failure (order 7) in UAS code

[Hans de Goede]

Hi,

On 01-03-16 10:42, Yves-Alexis Perez wrote:

Hi,

[sorry if this is not the right point for reporting bugs, I took the email
addresses from MAINTAINERS but please point me to the correct place if needed]

I have an external USB drive (Samsung M3), which apparently uses the UAS code.
Starting with 4.4 (from Debian sid, I could retry with vanilla if needed), I
can't mount the drive anymore after a while (few hours/days uptime). Just
plugging the disk, I get page allocation failure in kernel logs:


Can you try building a kernel with the following line in 
drivers/usb/storage/uas.c :

.can_queue = 65536, /* Is there a limit on the _host_ ? */

(around line 815) Replaced with

.can_queue = MAX_CMNDS,

That should help as MAX_CMNDS is 256, so claiming that we can queue more
is not helpful, and that likely is what is causing this quite high order alloc.

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] Revert "USB: serial: add Moxa UPORT 11x0 driver"

[Johan Hovold]

On Mon, Feb 29, 2016 at 10:46:51PM +, Greg Kroah-Hartman wrote:
> On Mon, Feb 29, 2016 at 06:56:02PM +0100, Johan Hovold wrote:
> > This reverts commit 0b2b093ad405b56a9e6f4f20a25da77ebfa9549c.
> > 
> > Turns out the MOXA vendor driver was basically just a copy of the
> > ti_usb_3410_5052 driver. We don't want two drivers for the same chip
> > even if mxu11x0 had gotten some much needed clean up before merge. So
> > let's remove the mxu11x0 driver, add support for these Moxa devices to
> > the TI driver, and then clean that driver up instead.
> > 
> > Signed-off-by: Johan Hovold 
> 
> Acked-by: Greg Kroah-Hartman 

Now applied.

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

Page allocation failure (order 7) in UAS code

[Yves-Alexis Perez]

Hi,

[sorry if this is not the right point for reporting bugs, I took the email
addresses from MAINTAINERS but please point me to the correct place if needed]

I have an external USB drive (Samsung M3), which apparently uses the UAS code.
Starting with 4.4 (from Debian sid, I could retry with vanilla if needed), I
can't mount the drive anymore after a while (few hours/days uptime). Just
plugging the disk, I get page allocation failure in kernel logs:

Feb 22 10:57:56 scapa kernel: [26557.268872] usb 2-2: new SuperSpeed USB device 
number 3 using xhci_hcd
Feb 22 10:57:56 scapa kernel: [26557.285884] usb 2-2: New USB device found, 
idVendor=04e8, idProduct=61b6
Feb 22 10:57:56 scapa kernel: [26557.285888] usb 2-2: New USB device strings: 
Mfr=1, Product=2, SerialNumber=3
Feb 22 10:57:56 scapa kernel: [26557.285891] usb 2-2: Product: Samsung M3 
Portable
Feb 22 10:57:56 scapa kernel: [26557.285893] usb 2-2: Manufacturer: Samsung M3 
Portable
Feb 22 10:57:56 scapa kernel: [26557.285895] usb 2-2: SerialNumber: 
826C7DFB1367
Feb 22 10:57:56 scapa kernel: [26557.293693] scsi host4: uas
Feb 22 10:57:56 scapa kernel: [26557.293707] kworker/0:0: page allocation 
failure: order:7, mode:0x2204020
Feb 22 10:57:56 scapa kernel: [26557.293711] CPU: 0 PID: 11015 Comm: 
kworker/0:0 Tainted: GW   4.4.0-1-amd64 #1 Debian 4.4.2-3~a.test
Feb 22 10:57:56 scapa kernel: [26557.293713] Hardware name: LENOVO 
20CMCTO1WW/20CMCTO1WW, BIOS N10ET41W (1.20 ) 01/19/2016
Feb 22 10:57:56 scapa kernel: [26557.293724] Workqueue: usb_hub_wq hub_event 
[usbcore]
Feb 22 10:57:56 scapa kernel: [26557.293727]   c0207f69 
812e7679 02204020
Feb 22 10:57:56 scapa kernel: [26557.293730]  8116b23a 0001c0207f69 
 88024dffbb20
Feb 22 10:57:56 scapa kernel: [26557.293733]  810b475e 0001020c8220 
c0207f69 0046
Feb 22 10:57:56 scapa kernel: [26557.293736] Call Trace:
Feb 22 10:57:56 scapa kernel: [26557.293741]  [] ? 
dump_stack+0x40/0x57
Feb 22 10:57:56 scapa kernel: [26557.293745]  [] ? 
warn_alloc_failed+0xfa/0x150
Feb 22 10:57:56 scapa kernel: [26557.293749]  [] ? 
__wake_up_common+0x4e/0x90
Feb 22 10:57:56 scapa kernel: [26557.293752]  [] ? 
__alloc_pages_nodemask+0x306/0xb70
Feb 22 10:57:56 scapa kernel: [26557.293757]  [] ? 
kmem_getpages+0x51/0xf0
Feb 22 10:57:56 scapa kernel: [26557.293759]  [] ? 
fallback_alloc+0x145/0x1f0
Feb 22 10:57:56 scapa kernel: [26557.293765]  [] ? 
init_tag_map+0x38/0xb0
Feb 22 10:57:56 scapa kernel: [26557.293768]  [] ? 
__kmalloc+0x17f/0x1c0
Feb 22 10:57:56 scapa kernel: [26557.293771]  [] ? 
init_tag_map+0x38/0xb0
Feb 22 10:57:56 scapa kernel: [26557.293774]  [] ? 
__blk_queue_init_tags+0x40/0x80
Feb 22 10:57:56 scapa kernel: [26557.293781]  [] ? 
scsi_add_host_with_dma+0x7b/0x2f0 [scsi_mod]
Feb 22 10:57:56 scapa kernel: [26557.293785]  [] ? 
uas_probe+0x41a/0x560 [uas]
Feb 22 10:57:56 scapa kernel: [26557.293796]  [] ? 
usb_probe_interface+0x1b3/0x300 [usbcore]
Feb 22 10:57:56 scapa kernel: [26557.293801]  [] ? 
driver_probe_device+0x212/0x480
Feb 22 10:57:56 scapa kernel: [26557.293803]  [] ? 
__driver_attach+0x80/0x80
Feb 22 10:57:56 scapa kernel: [26557.293806]  [] ? 
bus_for_each_drv+0x62/0xb0
Feb 22 10:57:56 scapa kernel: [26557.293809]  [] ? 
__device_attach+0xd8/0x160
Feb 22 10:57:56 scapa kernel: [26557.293811]  [] ? 
bus_probe_device+0x87/0xa0
Feb 22 10:57:56 scapa kernel: [26557.293814]  [] ? 
device_add+0x3f5/0x660
Feb 22 10:57:56 scapa kernel: [26557.293823]  [] ? 
usb_set_configuration+0x51b/0x8f0 [usbcore]
Feb 22 10:57:56 scapa kernel: [26557.293835]  [] ? 
generic_probe+0x28/0x80 [usbcore]
Feb 22 10:57:56 scapa kernel: [26557.293838]  [] ? 
driver_probe_device+0x212/0x480
Feb 22 10:57:56 scapa kernel: [26557.293840]  [] ? 
__driver_attach+0x80/0x80
Feb 22 10:57:56 scapa kernel: [26557.293842]  [] ? 
bus_for_each_drv+0x62/0xb0
Feb 22 10:57:56 scapa kernel: [26557.293845]  [] ? 
__device_attach+0xd8/0x160
Feb 22 10:57:56 scapa kernel: [26557.293847]  [] ? 
bus_probe_device+0x87/0xa0
Feb 22 10:57:56 scapa kernel: [26557.293850]  [] ? 
device_add+0x3f5/0x660
Feb 22 10:57:56 scapa kernel: [26557.293857]  [] ? 
usb_new_device+0x265/0x490 [usbcore]
Feb 22 10:57:56 scapa kernel: [26557.293864]  [] ? 
hub_event+0xfb3/0x14f0 [usbcore]
Feb 22 10:57:56 scapa kernel: [26557.293868]  [] ? 
process_one_work+0x19f/0x3d0
Feb 22 10:57:56 scapa kernel: [26557.293871]  [] ? 
worker_thread+0x4d/0x450
Feb 22 10:57:56 scapa kernel: [26557.293873]  [] ? 
process_one_work+0x3d0/0x3d0
Feb 22 10:57:56 scapa kernel: [26557.293876]  [] ? 
kthread+0xcd/0xf0
Feb 22 10:57:56 scapa kernel: [26557.293879]  [] ? 
kthread_create_on_node+0x190/0x190
Feb 22 10:57:56 scapa kernel: [26557.293883]  [] ? 
ret_from_fork+0x3f/0x70
Feb 22 10:57:56 scapa kernel: [26557.293886]  [] ? 
kthread_create_on_node+0x190/0x190
Feb 22 10:57:56 scapa kernel: [26557.293888] Mem-Info:
Feb 22 10:57:56 scapa kernel: [26557.293892] 

Re: Saleae logic analyzer driver

[Felipe Balbi]

Hi,

Alexandr Ivanov  writes:
> Hi All!
> I'm writing a driver for Saleae logic analyzer, but I wonder if it makes 
> sense.
> There are proprietary software from Saleae and Open-Source project 
> Sigrok (http://sigrok.org/) which works through libusb.
> Is there any chance for my driver to be included in the upstream
> kernel?

we don't usually take drivers for things like that. Specially since
sigrok already supports it. Sorry

-- 
balbi


signature.asc
Description: PGP signature

RE: [PATCH v1] usb: dwc3: gadget: sanity check for usb request complete function in ep_enqueue and giveback function.

[Felipe Balbi]

Hi,

(please don't top-post ;-)

"Tang, Jianqiang"  writes:
> Hi Balbi,
>
>   Sorry late response due to some other issues.
>  1>  Yes, I agree this is one gadget driver bug.
>
>   Current gadget framework do not have any check about this
>   usb_request->complete pointer per my understanding.

yes, and that's by design.

>   I think we should add some check in dwc3 OR gadget API like
>   usb_ep_queue() in include/linux/usb/gadget.h.

I'd rather we don't. ->complete() is a required API and if there's any
gadget driver not providing it, I want that gadget driver to Oops, open
pandora's box, Summon Chtulhu, whatever's the worst. The reason is that
lacking a ->complete() is a pretty big mistake and we better catch it as
soon as possible.

>   I saw in 4.5-rc6 there is some sanity check code in usb_ep_queue. I
>   can move the check from dwc3 to gadget.h.

thanks, but no thanks ;-)

>   2> My current kernel is not vanilla kernel from Linus, I am using
>   one old/modified kernel based on 3.1x.

then, I'm sorry, you're on your own here :-)

> But as this bug is point to usb_request->complete is NULL, I think the
> latest kernel also have the risk to happen.

right, and we will keep it that way so we can be forced at looking for
_that_ bug. Would you be willing to look for this bug in RNDIS driver
and fix it ?

> My platform is x86 platform.
> And I am not able to reproduce this issue also.

and how can you fix somethign you can't reproduce ?

> From my analysis of call trace, I suspect there is RNDIS gadget
> function is running with data transfer, also disconnect happen when
> kernel panic.
>
> As I am not able to reproduce this issue until now, I am using my
> supposed way to reproduce this issue:

this is no good. If you can't reproduce the issue there's no way you can
understand it well enough to fix it properly, right ? This patch should
have been an RFC, considering you haven't found the root cause of the
problem.

> Connect device with RNDIS enabled.
> Run RNDIS transfer using iperf with one Host machine as server and
> client.
> Disconnect device when iperf is running.

and you couldn't reproduce with these steps ? What makes you think this
is really the scenario which would cause the problem ?

> To be clear, this is my supposed way, I am not able to reproduce this
> issue also.

you shouldn't have sent this patch, actually. An RFC would be fine, but
the truth is that you didn't really understand the problem yet if you
can't reliably reproduce it.

> 3> So what is your opinion about how to fix this issue?

see above

-- 
balbi


signature.asc
Description: PGP signature

Saleae logic analyzer driver

[Alexandr Ivanov]

Hi All!
I'm writing a driver for Saleae logic analyzer, but I wonder if it makes 
sense.
There are proprietary software from Saleae and Open-Source project 
Sigrok (http://sigrok.org/) which works through libusb.

Is there any chance for my driver to be included in the upstream kernel?
Thanks!

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