USB 3.0 Isochronous audio

[Russel Hughes]

Hi,

Does anyone know when isochronous audio will be implemented for
USB 3.0 in Linux? I have asked Intel who make the NUC device I use and
they are not interested and on Ubuntu forums got no reply. I have an
Audiolab MDAC which cannot be used with USB 3.0 because of this, I
have to route the audio via HDMI and out of the TV optical to get
sound. USB is better as there is an elasticity buffer on the DAC which
means that jitter is lower, I am a sad hi- fi nerd as you will of
guessed. I cannot program but I work with hardware and have access to
a USB 2.0 bus analyser, I will check if it has been updated to 3.0, so
if anyone wants help looking for lost data packets etc, I may be able
to help. Thanks in advance!

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

Re: [PATCH 1/3] [SCSI] Fix abort state memory problem

[Hannes Reinecke]

On 03/28/2014 06:49 PM, James Bottomley wrote:
 The abort state is being stored persistently across commands, meaning if the
 command times out a second time, the error handler thinks an abort is still
 pending.  Fix this by properly resetting the abort flag after the abort is
 finished.
 
 Signed-off-by: James Bottomley jbottom...@parallels.com
 ---
  drivers/scsi/scsi_error.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
 index 771c16b..b9f3b07 100644
 --- a/drivers/scsi/scsi_error.c
 +++ b/drivers/scsi/scsi_error.c
 @@ -869,10 +869,13 @@ static int scsi_try_bus_device_reset(struct scsi_cmnd 
 *scmd)
  
  static int scsi_try_to_abort_cmd(struct scsi_host_template *hostt, struct 
 scsi_cmnd *scmd)
  {
 - if (!hostt-eh_abort_handler)
 - return FAILED;
 + int retval = FAILED;
 +
 + if (hostt-eh_abort_handler)
 + retval = hostt-eh_abort_handler(scmd);
  
 - return hostt-eh_abort_handler(scmd);
 + scmd-eh_eflags = ~SCSI_EH_ABORT_SCHEDULED;
 + return retval;
  }
  
  static void scsi_abort_eh_cmnd(struct scsi_cmnd *scmd)
 
Hmm. No, I don't think this is correct.

SCSI_EH_ABORT_SCHEDULED signifies whether scmd_eh_abort_handler()
needs to run. As such it needs to be reset when the workqueue item
is triggered.

Can you try with this instead?

diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 771c16b..9694803 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -120,6 +120,8 @@ scmd_eh_abort_handler(struct work_struct *work)
struct scsi_device *sdev = scmd-device;
int rtn;

+   scmd-eh_eflags = ~SCSI_EH_ABORT_SCHEDULED;
+
if (scsi_host_eh_past_deadline(sdev-host)) {
SCSI_LOG_ERROR_RECOVERY(3,
scmd_printk(KERN_INFO, scmd,


Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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/3] [SCSI] Fix spurious request sense in error handling

[Hannes Reinecke]

On 03/28/2014 06:50 PM, James Bottomley wrote:
 We unconditionally execute scsi_eh_get_sense() to make sure all failed
 commands that should have sense attached, do.  However, the routine forgets
 that some commands, because of the way they fail, will not have any sense code
 ... we should not bother them with a REQUEST_SENSE command.  Fix this by
 testing to see if we actually got a CHECK_CONDITION return and skip asking for
 sense if we don't.
 
 Tested-by: Alan Stern st...@rowland.harvard.edu
 Signed-off-by: James Bottomley jbottom...@parallels.com
Acked-by: Hannes Reinecke h...@suse.de

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] [SCSI] Fix command result state propagation

[Hannes Reinecke]

On 03/28/2014 06:51 PM, James Bottomley wrote:
 From: Alan Stern st...@rowland.harvard.edu
 
 We're seeing a case where the contents of scmd-result isn't being reset after
 a SCSI command encounters an error, is resubmitted, times out and then gets
 handled.  The error handler acts on the stale result of the previous error
 instead of the timeout.  Fix this by properly zeroing the scmd-status before
 the command is resubmitted.
 
 Signed-off-by: Alan Stern st...@rowland.harvard.edu
 Signed-off-by: James Bottomley jbottom...@parallels.com

grin

Acked-by: Hannes Reinecke h...@suse.de

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Fix USB deadlock caused by SCSI error handling

[Hannes Reinecke]

On 03/28/2014 08:29 PM, Alan Stern wrote:
 On Fri, 28 Mar 2014, James Bottomley wrote:
 
 This is a set of three patches we agreed to a while ago to eliminate a
 USB deadlock.  I did rewrite the first patch, if it could be reviewed
 and tested.
 
 I tested all three patches under the same conditions as before, and 
 they all worked correctly.
 
 In the revised patch 1, the meaning of SCSI_EH_ABORT_SCHEDULED isn't
 entirely clear.  This boils down to two questions, which I don't 
 know the answers to:
 
   What should happen in scmd_eh_abort_handler() if
   scsi_host_eh_past_deadline() returns true and thereby
   prevents scsi_try_to_abort_cmd() from being called?
   The flag wouldn't get cleared then.
 
Ah. Correct. But that's due to the first patch being incorrect.
Cf my response to the original first patch.

   What should happen if some other pathway manages to call
   scsi_try_to_abort_cmd() while scmd-abort_work is still
   sitting on the work queue?  The command would be aborted
   and the flag would be cleared, but the queued work would
   remain.  Can this ever happen?
 
Not that I could see.
A command abort is only ever triggered by the request timeout from
the block layer. And the timer is _not_ rearmed once the timeout
function (here: scsi_times_out()) is called.
Hence I fail to see how it can be called concurrently.

 Maybe scmd_eh_abort_handler() should check the flag before doing
 anything.  Is there any sort of sychronization to prevent the same
 incarnation of a command from being aborted twice (or by two different
 threads at the same time)?  If there is, it isn't obvious.
 
See above. scsi_times_out() will only ever called once.
What can happen, though, is that _theoretically_ the LLDD might
decide to call -done() on a timed out command when
scsi_eh_abort_handler() is still pending.


 (Also, what's going on at the start of scsi_abort_command()?  Contrary
 to what one might expect, the first part of the function _cancels_ a
 scheduled abort.  And it does so without clearing the
 SCSI_EH_ABORT_SCHEDULED flag.)
 
The original idea was this:

SCSI_EH_ABORT_SCHEDULED is sticky _per command_.
Point is, any command abort is only ever send for a timed-out
command. And the main problem for a timed-out command is that we
simply _do not_ know what happened for that command. So _if_ a
command timed out, _and_ we've send an abort, _and_ the command
times out _again_ we'll be running into an endless loop between
timeout and aborting, and never returning the command at all.

So to prevent this we should set a marker on that command telling it
to _not_ try to abort the command again.
Which is what 'SCSI_EH_ABORT_SCHEDULED' was meant for:

- A command times out, sets 'SCSI_EH_ABORT_SCHEDULED'
- abort _succeeds_
- The same command times out a second time, notifies
  that SCSI_EH_ABORT_SCHEDULED is set, and doesn't call
  scsi_eh_abort_command() but rather escalates directly.

_However_, I do feel that we've gotten the wrong track with all of
this. In you original mail you stated:

 Basically, usb-storage deadlocks when the SCSI error handler
 invokes the eh_device_reset_handler callback while a command
 is running.  The command has timed out and will never complete
 normally, because the device's firmware has crashed.  But
 usb-storage's device-reset routine waits for the current command
 to finish, which brings everything to a standstill.

Question now to you as the USB god:

A command abort is only _ever_ send after a command timeout.
And the main idea of the command abort is to remove any context
the LLDD or the target might have. So by the time the command
abort returns SUCCESS we _expect_ the firmware to have cleared that
command. If for some reason the firmware isn't capable of doing so,
it should return FAILED.

So:
- Has the command timeout fired?
- If so, why hasn't it returned FAILED?
- If it had returned SUCCESS, why did the device_reset_handler
  wait for the command to complete?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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 01/11] usb: chipidea: usb OTG fsm initialization.

[Peter Chen]

On Sun, Mar 30, 2014 at 08:20:03PM +0800, Li Jun wrote:
 This patch adds OTG fsm related initialization when do otg init,
 add a seperate file for OTG fsm related utilities.
 
 Signed-off-by: Li Jun b47...@freescale.com
 ---
  drivers/usb/chipidea/Makefile  |1 +
  drivers/usb/chipidea/ci.h  |   16 +++
  drivers/usb/chipidea/otg.c |3 +-
  drivers/usb/chipidea/otg_fsm.c |   60 
 
  drivers/usb/chipidea/otg_fsm.h |   29 +++
  5 files changed, 108 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
 index 480bd4d..2f099c7 100644
 --- a/drivers/usb/chipidea/Makefile
 +++ b/drivers/usb/chipidea/Makefile
 @@ -6,6 +6,7 @@ ci_hdrc-y := core.o otg.o
  ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC)   += udc.o
  ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST)  += host.o
  ci_hdrc-$(CONFIG_USB_CHIPIDEA_DEBUG) += debug.o
 +ci_hdrc-$(CONFIG_USB_OTG_FSM)+= otg_fsm.o
  
  # Glue/Bridge layers go here
  
 diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
 index 7ae8cb6..0bd16f6 100644
 --- a/drivers/usb/chipidea/ci.h
 +++ b/drivers/usb/chipidea/ci.h
 @@ -17,6 +17,7 @@
  #include linux/irqreturn.h
  #include linux/usb.h
  #include linux/usb/gadget.h
 +#include linux/usb/otg-fsm.h
  
  
 /**
   * DEFINE
 @@ -174,6 +175,7 @@ struct ci_hdrc {
   struct ci_role_driver   *roles[CI_ROLE_END];
   enum ci_rolerole;
   boolis_otg;
 + struct otg_fsm  fsm;
   struct work_struct  work;
   struct workqueue_struct *wq;
  
 @@ -319,6 +321,20 @@ static inline u32 hw_test_and_write(struct ci_hdrc *ci, 
 enum ci_hw_regs reg,
   return (val  mask)  __ffs(mask);
  }
  
 +/**
 + * ci_otg_is_fsm_mode: runtime check if otg controller
 + * is in otg fsm mode.
 + */
 +static inline bool ci_otg_is_fsm_mode(struct ci_hdrc *ci)
 +{
 +#ifdef CONFIG_USB_OTG_FSM
 + return ci-is_otg  ci-roles[CI_ROLE_HOST] 
 + ci-roles[CI_ROLE_GADGET];
 +#else
 + return false;
 +#endif
 +}
 +
  u32 hw_read_intr_enable(struct ci_hdrc *ci);
  
  u32 hw_read_intr_status(struct ci_hdrc *ci);
 diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
 index c694340..b278cd9 100644
 --- a/drivers/usb/chipidea/otg.c
 +++ b/drivers/usb/chipidea/otg.c
 @@ -22,6 +22,7 @@
  #include ci.h
  #include bits.h
  #include otg.h
 +#include otg_fsm.h
  
  /**
   * hw_read_otgsc returns otgsc register bits value.
 @@ -116,7 +117,7 @@ int ci_hdrc_otg_init(struct ci_hdrc *ci)
   return -ENODEV;
   }
  
 - return 0;
 + return ci_hdrc_otg_fsm_init(ci);


How about below change:

+   if (ci_otg_is_fsm_mode(ci))
+   return ci_hdrc_otg_fsm_init(ci);

In that case, the user doesn't need to look into ci_hdrc_otg_fsm_init.

  }
  
  /**
 diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
 new file mode 100644
 index 000..35748a9
 --- /dev/null
 +++ b/drivers/usb/chipidea/otg_fsm.c
 @@ -0,0 +1,60 @@
 +/*
 + * otg_fsm.c - ChipIdea USB IP core OTG FSM driver
 + *
 + * Copyright (C) 2014 Freescale Semiconductor, Inc.
 + *
 + * Author: Jun Li
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +/*
 + * This file mainly handles OTG fsm, it includes OTG fsm operations
 + * for HNP and SRP.
 + */
 +
 +#include linux/usb/otg.h
 +#include linux/usb/gadget.h
 +#include linux/usb/chipidea.h
 +
 +#include ci.h
 +#include bits.h
 +#include otg.h
 +#include otg_fsm.h
 +
 +int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
 +{
 + if (!ci_otg_is_fsm_mode(ci))
 + return 0;

The above code doesn't need if checking ci_otg_is_fsm_mode before.

 +
 + ci-transceiver-otg = devm_kzalloc(ci-dev,
 + sizeof(struct usb_otg), GFP_KERNEL);
 + if (!ci-transceiver-otg) {
 + dev_err(ci-dev,
 + Failed to allocate usb_otg structure for ci hdrc otg!\n);
 + return -ENOMEM;
 + }
 +
 + ci-fsm.power_up = 1;
 + ci-fsm.id = hw_read_otgsc(ci, OTGSC_ID);
 + ci-fsm.otg = ci-transceiver-otg;
 + ci-fsm.otg-phy = ci-transceiver;
 + ci-fsm.otg-gadget = ci-gadget;
 + ci-transceiver-state = OTG_STATE_UNDEFINED;
 +
 + mutex_init(ci-fsm.lock);
 +
 + /* Enable A vbus valid irq */
 + hw_write_otgsc(ci, OTGSC_AVVIE, OTGSC_AVVIE);
 +
 + if (ci-fsm.id) {
 + ci-fsm.b_ssend_srp =
 + hw_read_otgsc(ci, OTGSC_BSV) ? 0 : 1;
 + ci-fsm.b_sess_vld =
 + hw_read_otgsc(ci, OTGSC_BSV) ? 1 : 0;
 + }
 +
 + return 0;
 +}
 diff --git 

Re: [PATCH v5 05/11] usb: chipidea: add OTG fsm operation functions implemenation.

[Peter Chen]

On Sun, Mar 30, 2014 at 08:20:07PM +0800, Li Jun wrote:
 Add OTG HNP and SRP operation functions implementation:
 - charge vbus
 - drive vbus
 - connection signaling
 - drive sof
 - start data pulse
 - add fsm timer
 - delete fsm timer
 - start host
 - start gadget
 
 Signed-off-by: Li Jun b47...@freescale.com
 ---
  drivers/usb/chipidea/bits.h|9 ++
  drivers/usb/chipidea/ci.h  |1 +
  drivers/usb/chipidea/otg_fsm.c |  191 
 
  drivers/usb/chipidea/otg_fsm.h |   25 ++
  4 files changed, 226 insertions(+)
 
 diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
 index 83d06c1..44882c8 100644
 --- a/drivers/usb/chipidea/bits.h
 +++ b/drivers/usb/chipidea/bits.h
 @@ -44,9 +44,14 @@
  #define DEVICEADDR_USBADR (0x7FUL  25)
  
  /* PORTSC */
 +#define PORTSC_CCSBIT(0)
 +#define PORTSC_CSCBIT(1)
 +#define PORTSC_PECBIT(3)
 +#define PORTSC_OCCBIT(5)
  #define PORTSC_FPRBIT(6)
  #define PORTSC_SUSP   BIT(7)
  #define PORTSC_HSPBIT(9)
 +#define PORTSC_PP BIT(12)
  #define PORTSC_PTC(0x0FUL  16)
  #define PORTSC_PHCD(d) ((d) ? BIT(22) : BIT(23))
  /* PTS and PTW for non lpm version only */
 @@ -56,6 +61,9 @@
  #define PORTSC_PTWBIT(28)
  #define PORTSC_STSBIT(29)
  
 +#define PORTSC_W1C_BITS  \
 + (PORTSC_CSC | PORTSC_PEC | PORTSC_OCC)
 +
  /* DEVLC */
  #define DEVLC_PFSCBIT(23)
  #define DEVLC_PSPD(0x03UL  25)
 @@ -72,6 +80,7 @@
  
  /* OTGSC */
  #define OTGSC_IDPU BIT(5)
 +#define OTGSC_HADP BIT(6)
  #define OTGSC_ID   BIT(8)
  #define OTGSC_AVV  BIT(9)
  #define OTGSC_ASV  BIT(10)
 diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
 index 0bd16f6..344e435 100644
 --- a/drivers/usb/chipidea/ci.h
 +++ b/drivers/usb/chipidea/ci.h
 @@ -176,6 +176,7 @@ struct ci_hdrc {
   enum ci_rolerole;
   boolis_otg;
   struct otg_fsm  fsm;
 + struct ci_otg_fsm_timer_list*fsm_timer;
   struct work_struct  work;
   struct workqueue_struct *wq;
  
 diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
 index 35748a9..2fc395c 100644
 --- a/drivers/usb/chipidea/otg_fsm.c
 +++ b/drivers/usb/chipidea/otg_fsm.c
 @@ -18,12 +18,202 @@
  #include linux/usb/otg.h
  #include linux/usb/gadget.h
  #include linux/usb/chipidea.h
 +#include linux/regulator/consumer.h
  
  #include ci.h
  #include bits.h
  #include otg.h
  #include otg_fsm.h
  
 +/*
 + * Add timer to active timer list
 + */
 +static void ci_otg_add_timer(struct ci_hdrc *ci, enum ci_otg_fsm_timer_index 
 t)
 +{
 + struct ci_otg_fsm_timer *tmp_timer;
 + struct ci_otg_fsm_timer *timer = ci-fsm_timer-timer_list[t];
 + struct list_head *active_timers = ci-fsm_timer-active_timers;
 +
 + if (t = NUM_CI_OTG_FSM_TIMERS)
 + return;
 +
 + /*
 +  * Check if the timer is already in the active list,
 +  * if so update timer count
 +  */
 + list_for_each_entry(tmp_timer, active_timers, list)
 + if (tmp_timer == timer) {
 + timer-count = timer-expires;
 + return;
 + }
 +
 + timer-count = timer-expires;
 + list_add_tail(timer-list, active_timers);
 +
 + /* Enable 1ms irq */
 + if (!(hw_read_otgsc(ci, OTGSC_1MSIE)))
 + hw_write_otgsc(ci, OTGSC_1MSIE, OTGSC_1MSIE);
 +}
 +
 +/*
 + * Remove timer from active timer list
 + */
 +static void ci_otg_del_timer(struct ci_hdrc *ci, enum ci_otg_fsm_timer_index 
 t)
 +{
 + struct ci_otg_fsm_timer *tmp_timer, *del_tmp;
 + struct ci_otg_fsm_timer *timer = ci-fsm_timer-timer_list[t];
 + struct list_head *active_timers = ci-fsm_timer-active_timers;
 +
 + if (t = NUM_CI_OTG_FSM_TIMERS)
 + return;
 +
 + list_for_each_entry_safe(tmp_timer, del_tmp, active_timers, list)
 + if (tmp_timer == timer)
 + list_del(timer-list);
 +
 + /* Disable 1ms irq if there is no any active timer */
 + if (list_empty(active_timers))
 + hw_write_otgsc(ci, OTGSC_1MSIE, 0);
 +}
 +
 +/* -*/
 +/* Operations that will be called from OTG Finite State Machine */
 +/* -*/
 +static void ci_otg_fsm_add_timer(struct otg_fsm *fsm, enum otg_fsm_timer t)
 +{
 + struct ci_hdrc  *ci = container_of(fsm, struct ci_hdrc, fsm);
 +
 + if (t  NUM_OTG_FSM_TIMERS)
 + ci_otg_add_timer(ci, t);
 + return;
 +}
 +
 +static void ci_otg_fsm_del_timer(struct otg_fsm *fsm, enum otg_fsm_timer t)
 +{
 + struct ci_hdrc  *ci = container_of(fsm, struct ci_hdrc, fsm);
 +
 + if (t  

Re: [PATCH v5 06/11] usb: chipidea: OTG fsm timers initialization.

[Peter Chen]

On Sun, Mar 30, 2014 at 08:20:08PM +0800, Li Jun wrote:
 From: Li Jun b47...@freescale.com
 
 This patch adds OTG fsm timers initialization, which use controller's 1ms
 interrupt as timeout counter, also adds some local timers which are not
 in otg_fsm_timer list.
 
 Signed-off-by: Li Jun b47...@freescale.com
 ---
  drivers/usb/chipidea/bits.h|1 +
  drivers/usb/chipidea/otg_fsm.c |  188 
 
  drivers/usb/chipidea/otg_fsm.h |   46 ++
  3 files changed, 235 insertions(+)
 
 diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
 index 44882c8..ca57e3d 100644
 --- a/drivers/usb/chipidea/bits.h
 +++ b/drivers/usb/chipidea/bits.h
 @@ -81,6 +81,7 @@
  /* OTGSC */
  #define OTGSC_IDPU BIT(5)
  #define OTGSC_HADP BIT(6)
 +#define OTGSC_HABA BIT(7)
  #define OTGSC_ID   BIT(8)
  #define OTGSC_AVV  BIT(9)
  #define OTGSC_ASV  BIT(10)
 diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
 index 2fc395c..d49bbdd 100644
 --- a/drivers/usb/chipidea/otg_fsm.c
 +++ b/drivers/usb/chipidea/otg_fsm.c
 @@ -25,6 +25,22 @@
  #include otg.h
  #include otg_fsm.h
  
 +static struct ci_otg_fsm_timer *otg_timer_initializer
 +(struct ci_hdrc *ci, void (*function)(void *, unsigned long),
 + unsigned long expires, unsigned long data)
 +{
 + struct ci_otg_fsm_timer *timer;
 +
 + timer = devm_kzalloc(ci-dev, sizeof(struct ci_otg_fsm_timer),
 + GFP_KERNEL);
 + if (!timer)
 + return NULL;
 + timer-function = function;
 + timer-expires = expires;
 + timer-data = data;
 + return timer;
 +}
 +
  /*
   * Add timer to active timer list
   */
 @@ -76,6 +92,161 @@ static void ci_otg_del_timer(struct ci_hdrc *ci, enum 
 ci_otg_fsm_timer_index t)
   hw_write_otgsc(ci, OTGSC_1MSIE, 0);
  }
  
 +/* The timeout callback function to set time out bit */
 +static void set_tmout(void *ptr, unsigned long indicator)
 +{
 + *(int *)indicator = 1;
 +}
 +
 +static void set_tmout_and_fsm(void *ptr, unsigned long indicator)
 +{
 + struct ci_hdrc *ci = (struct ci_hdrc *)ptr;
 +
 + set_tmout(ci, indicator);
 +
 + disable_irq_nosync(ci-irq);
 + queue_work(ci-wq, ci-work);
 +}
 +
 +static void a_wait_vfall_tmout_func(void *ptr, unsigned long indicator)
 +{
 + struct ci_hdrc *ci = (struct ci_hdrc *)ptr;
 +
 + set_tmout(ci, indicator);
 + /* Clear exsiting DP irq */
 + hw_write_otgsc(ci, OTGSC_DPIS, OTGSC_DPIS);
 + /* Enable data pulse irq */
 + hw_write_otgsc(ci, OTGSC_DPIE, OTGSC_DPIE);
 + disable_irq_nosync(ci-irq);
 + queue_work(ci-wq, ci-work);
 +}
 +
 +static void b_ase0_brst_tmout_func(void *ptr, unsigned long indicator)
 +{
 + struct ci_hdrc *ci = (struct ci_hdrc *)ptr;
 +
 + set_tmout(ci, indicator);
 + if (!hw_read_otgsc(ci, OTGSC_BSVIS))
 + ci-fsm.b_sess_vld = 0;
 +
 + disable_irq_nosync(ci-irq);
 + queue_work(ci-wq, ci-work);
 +}
 +
 +static void b_ssend_srp_tmout_func(void *ptr, unsigned long indicator)
 +{
 + struct ci_hdrc *ci = (struct ci_hdrc *)ptr;
 +
 + set_tmout(ci, indicator);
 +
 + /* only vbus fall below B_sess_vld in b_idle state */
 + if (ci-transceiver-state == OTG_STATE_B_IDLE) {
 + disable_irq_nosync(ci-irq);
 + queue_work(ci-wq, ci-work);
 + }
 +}
 +
 +static void b_sess_vld_tmout_func(void *ptr, unsigned long indicator)
 +{
 + struct ci_hdrc *ci = (struct ci_hdrc *)ptr;
 +
 + /* Check if A detached */
 + if (!(hw_read_otgsc(ci, OTGSC_BSV))) {
 + ci-fsm.b_sess_vld = 0;
 + ci_otg_add_timer(ci, B_SSEND_SRP);
 + disable_irq_nosync(ci-irq);
 + queue_work(ci-wq, ci-work);
 + }
 +}
 +
 +static void b_data_pulse_end(void *ptr, unsigned long indicator)
 +{
 + struct ci_hdrc *ci = (struct ci_hdrc *)ptr;
 +
 + ci-fsm.b_srp_done = 1;
 + ci-fsm.b_bus_req = 0;
 + if (ci-fsm.power_up)
 + ci-fsm.power_up = 0;
 +
 + hw_write_otgsc(ci, OTGSC_HABA, 0);
 +
 + disable_irq_nosync(ci-irq);
 + queue_work(ci-wq, ci-work);
 +}
 +
 +/* Initialize timers */
 +static int ci_otg_init_timers(struct ci_hdrc *ci)
 +{
 + struct otg_fsm *fsm = ci-fsm;
 +
 + /* FSM used timers */
 + ci-fsm_timer-timer_list[A_WAIT_VRISE] =
 + otg_timer_initializer(ci, set_tmout_and_fsm, TA_WAIT_VRISE,
 + (unsigned long)fsm-a_wait_vrise_tmout);
 + if (ci-fsm_timer-timer_list[A_WAIT_VRISE] == NULL)
 + return -ENOMEM;
 +
 + ci-fsm_timer-timer_list[A_WAIT_VFALL] =
 + otg_timer_initializer(ci, a_wait_vfall_tmout_func,
 + TA_WAIT_VFALL, (unsigned long)fsm-a_wait_vfall_tmout);
 + if (ci-fsm_timer-timer_list[A_WAIT_VFALL] == NULL)
 + return -ENOMEM;
 +
 + ci-fsm_timer-timer_list[A_WAIT_BCON] =
 + 

Re: [PATCH v5 07/11] usb: chipidea: OTG HNP and SRP fsm implementation.

[Peter Chen]

On Sun, Mar 30, 2014 at 08:20:09PM +0800, Li Jun wrote:
 From: Li Jun b47...@freescale.com
 
 USB OTG interrupt handling and fsm transitions according to USB OTG
 and EH 2.0.
 
 Signed-off-by: Li Jun b47...@freescale.com
 ---
  drivers/usb/chipidea/core.c|8 +-
  drivers/usb/chipidea/otg.c |9 +-
  drivers/usb/chipidea/otg_fsm.c |  236 
 
  drivers/usb/chipidea/otg_fsm.h |   18 +++
  drivers/usb/chipidea/udc.c |6 +
  5 files changed, 273 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
 index ff38cf3..6544149 100644
 --- a/drivers/usb/chipidea/core.c
 +++ b/drivers/usb/chipidea/core.c
 @@ -42,7 +42,6 @@
   * - Not Supported: 15  16 (ISO)
   *
   * TODO List
 - * - OTG
   * - Interrupt Traffic
   * - GET_STATUS(device) - always reports 0
   * - Gadget API (majority of optional features)
 @@ -74,6 +73,7 @@
  #include host.h
  #include debug.h
  #include otg.h
 +#include otg_fsm.h
  
  /* Controller register map */
  static const u8 ci_regs_nolpm[] = {
 @@ -412,8 +412,12 @@ static irqreturn_t ci_irq(int irq, void *data)
   irqreturn_t ret = IRQ_NONE;
   u32 otgsc = 0;
  
 - if (ci-is_otg)
 + if (ci-is_otg) {
   otgsc = hw_read_otgsc(ci, ~0);
 + ret = ci_otg_fsm_irq(ci);
 + if (ret == IRQ_HANDLED)
 + return ret;
 + }
  
   /*
* Handle id change interrupt, it indicates device/host function
 diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
 index b278cd9..5169640 100644
 --- a/drivers/usb/chipidea/otg.c
 +++ b/drivers/usb/chipidea/otg.c
 @@ -11,8 +11,8 @@
   */
  
  /*
 - * This file mainly handles otgsc register, it may include OTG operation
 - * in the future.
 + * This file mainly handles otgsc register, OTG fsm operations for HNP and 
 SRP
 + * are also included.
   */
  
  #include linux/usb/otg.h
 @@ -91,6 +91,11 @@ static void ci_otg_work(struct work_struct *work)
  {
   struct ci_hdrc *ci = container_of(work, struct ci_hdrc, work);
  
 + if (!ci_otg_fsm_work(ci)) {
 + enable_irq(ci-irq);
 + return;
 + }
 +
   if (ci-id_event) {
   ci-id_event = false;
   ci_handle_id_switch(ci);
 diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
 index d49bbdd..8e30fc64 100644
 --- a/drivers/usb/chipidea/otg_fsm.c
 +++ b/drivers/usb/chipidea/otg_fsm.c
 @@ -13,6 +13,10 @@
  /*
   * This file mainly handles OTG fsm, it includes OTG fsm operations
   * for HNP and SRP.
 + *
 + * TODO List
 + * - ADP
 + * - OTG test device
   */
  
  #include linux/usb/otg.h
 @@ -92,6 +96,33 @@ static void ci_otg_del_timer(struct ci_hdrc *ci, enum 
 ci_otg_fsm_timer_index t)
   hw_write_otgsc(ci, OTGSC_1MSIE, 0);
  }
  
 +/*
 + * Reduce timer count by 1, and find timeout conditions.
 + * Called by otg 1ms timer interrupt
 + */
 +static inline int ci_otg_tick_timer(struct ci_hdrc *ci)
 +{
 + struct ci_otg_fsm_timer *tmp_timer, *del_tmp;
 + struct list_head *active_timers = ci-fsm_timer-active_timers;
 + int expired = 0;
 +
 + list_for_each_entry_safe(tmp_timer, del_tmp, active_timers, list) {
 + tmp_timer-count--;
 + /* check if timer expires */
 + if (!tmp_timer-count) {
 + list_del(tmp_timer-list);
 + tmp_timer-function(ci, tmp_timer-data);
 + expired = 1;
 + }
 + }
 +
 + /* disable 1ms irq if there is no any timer active */
 + if ((expired == 1)  list_empty(active_timers))
 + hw_write_otgsc(ci, OTGSC_1MSIE, 0);
 +
 + return expired;
 +}
 +
  /* The timeout callback function to set time out bit */
  static void set_tmout(void *ptr, unsigned long indicator)
  {
 @@ -385,6 +416,209 @@ static struct otg_fsm_ops ci_otg_ops = {
   .start_gadget = ci_otg_start_gadget,
  };
  
 +int ci_otg_fsm_work(struct ci_hdrc *ci)
 +{
 + if (!ci-transceiver-otg)
 + return -ENODEV;
 +
 + /*
 +  * Don't do fsm transition for B device
 +  * when there is no gadget class driver
 +  */
 + if (ci-fsm.id  !(ci-driver) 
 + ci-transceiver-state  OTG_STATE_A_IDLE)

Why the third condition is needed?

 + return 0;
 +
 + if (otg_statemachine(ci-fsm)) {
 + if (ci-transceiver-state == OTG_STATE_A_IDLE) {
 + if (ci-fsm.id)
 + /* A idle to B idle */
 + otg_statemachine(ci-fsm);
 + else if ((ci-id_event) || (ci-fsm.power_up)) {
 + ci-id_event = false;
 + /* A idle to A wait vrise */
 + otg_statemachine(ci-fsm);
 + ci-fsm.power_up = false;
 + }
 + }
 + }
 + return 0;
 +}
 +
 +/*
 + * 

Re: What to use for usb transfer from gadget to host?

[tzippy]

 I am familiar with USB on the host side, but not the gadget side.
 What's the best/easiest way to implement a simple 2 endpoints
 communication with high data rates?
 During my search I came across functionfs, gadgetfs, configfs and
 libusbg. Can you recommend one of them that suits my needs?
 Thank you so much!

Can anybody help out here?
Thanks!

regards,
tzippy

On Fri, Mar 21, 2014 at 9:07 AM,  tzi...@me.com wrote:
 On Fri, Mar 21, 2014 at 4:58 AM, Pratyush Anand pratyush.an...@st.com wrote:
 How is your image sensor driver implemented?
 If it is in v4l2 framework, then you can send your data to USB host
 using uvc framework. See: drivers/usb/gadget/webcam.c

 The above would be be the standard way of doing such application.

 Regards
 Pratyush

 Actually I have developed my own kernel module since the application
 of the video
 sensor is very specific.
 I would just need a fast way for image data to be transfered to the host.

 regards,
 tzippy



 I am familiar with USB on the host side, but not the gadget side.
 What's the best/easiest way to implement a simple 2 endpoints
 communication with high data rates?
 During my search I came across functionfs, gadgetfs, configfs and
 libusbg. Can you recommend one of them that suits my needs?
 Thank you so much!
 --
 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: [PATCH] USB: serial: ftdi_sio: add id for Brainboxes serial cards

[Johan Hovold]

On Sat, Mar 29, 2014 at 08:55:11PM +, Michele Baldessari wrote:
 Custom VID/PIDs for Brainboxes cards as reported in
 https://bugzilla.redhat.com/show_bug.cgi?id=1071914

Thanks for including the remaining PIDs from the report.

There was a duplicate entry in the device-id table below, but I'll fix
that here (and also sort the defines numerically) before sending it to
Greg.

Thanks again,
Johan

 Signed-off-by: Michele Baldessari mich...@acksyn.org
 ---
  drivers/usb/serial/ftdi_sio.c | 34 ++
  drivers/usb/serial/ftdi_sio_ids.h | 38 ++
  2 files changed, 72 insertions(+)
 
 diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
 index 44ab12986805..ccfa3c55212c 100644
 --- a/drivers/usb/serial/ftdi_sio.c
 +++ b/drivers/usb/serial/ftdi_sio.c
 @@ -909,6 +909,40 @@ static const struct usb_device_id id_table_combined[] = {
   { USB_DEVICE(FTDI_VID, FTDI_Z3X_PID) },
   /* Cressi Devices */
   { USB_DEVICE(FTDI_VID, FTDI_CRESSI_PID) },
 + /* Brainbox Devices */
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_VX_001_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_VX_001_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_VX_012_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_VX_023_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_VX_034_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_101_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_257_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_313_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_324_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_357_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_160_1_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_160_2_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_160_3_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_160_4_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_160_5_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_160_6_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_160_7_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_160_8_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_279_1_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_279_2_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_279_3_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_279_4_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_346_1_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_346_2_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_606_1_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_606_2_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_606_3_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_701_1_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_701_2_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_1_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_2_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_3_PID) },
 + { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_4_PID) },
   { } /* Terminating entry */
  };
  
 diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
 b/drivers/usb/serial/ftdi_sio_ids.h
 index e599fbfcde5f..84d351e70f9c 100644
 --- a/drivers/usb/serial/ftdi_sio_ids.h
 +++ b/drivers/usb/serial/ftdi_sio_ids.h
 @@ -1326,3 +1326,41 @@
   * Manufacturer: Cressi
   */
  #define FTDI_CRESSI_PID  0x87d0
 +
 +/*
 + * Product: Brainboxes devices
 + * Manufacturer: Brainboxes
 + */
 +#define BRAINBOXES_VID   0x05d1
 +#define BRAINBOXES_VX_001_PID0x1001 /* VX-001 ExpressCard 1 
 Port RS232 */
 +#define BRAINBOXES_VX_012_PID0x1002 /* VX-012 ExpressCard 2 
 Port RS232 */
 +#define BRAINBOXES_VX_023_PID0x1003 /* VX-023 ExpressCard 1 
 Port RS422/485 */
 +#define BRAINBOXES_VX_034_PID0x1004 /* VX-034 ExpressCard 2 
 Port RS422/485 */
 +#define BRAINBOXES_US_101_PID0x1011 /* US-101 1xRS232 */
 +#define BRAINBOXES_US_257_PID0x5001 /* US-257 2xRS232 1Mbaud 
 */
 +#define BRAINBOXES_US_313_PID0x6001 /* US-313 2xRS422/485 
 1Mbaud */
 +#define BRAINBOXES_US_324_PID0x1013 /* US-324 1xRS422/485 
 1Mbaud */
 +#define BRAINBOXES_US_357_PID0x7001 /* US_357 
 1xRS232/422/485 */
 +#define BRAINBOXES_US_160_1_PID  0x9001 /* US-160 16xRS232 
 1Mbaud Port 1 and 2 */
 +#define BRAINBOXES_US_160_2_PID  0x9002 /* US-160 16xRS232 
 1Mbaud Port 3 and 4 */
 +#define BRAINBOXES_US_160_3_PID  0x9003 /* US-160 16xRS232 
 1Mbaud Port 5 and 6 */
 +#define BRAINBOXES_US_160_4_PID  0x9004 /* US-160 16xRS232 
 1Mbaud Port 7 and 8 */
 +#define BRAINBOXES_US_160_5_PID  0x9005 /* US-160 16xRS232 
 1Mbaud Port 9 and 10 */
 

[PATCH] USB: serial: ftdi_sio: add id for Brainboxes serial cards

[Johan Hovold]

From: Michele Baldessari mich...@acksyn.org

Custom VID/PIDs for Brainboxes cards as reported in
https://bugzilla.redhat.com/show_bug.cgi?id=1071914

Signed-off-by: Michele Baldessari mich...@acksyn.org
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
 drivers/usb/serial/ftdi_sio.c | 33 +
 drivers/usb/serial/ftdi_sio_ids.h | 37 +
 2 files changed, 70 insertions(+)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 44ab12986805..7c6e1dedeb06 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -909,6 +909,39 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(FTDI_VID, FTDI_Z3X_PID) },
/* Cressi Devices */
{ USB_DEVICE(FTDI_VID, FTDI_CRESSI_PID) },
+   /* Brainboxes Devices */
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_VX_001_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_VX_012_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_VX_023_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_VX_034_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_101_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_160_1_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_160_2_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_160_3_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_160_4_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_160_5_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_160_6_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_160_7_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_160_8_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_257_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_279_1_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_279_2_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_279_3_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_279_4_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_313_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_324_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_346_1_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_346_2_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_357_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_606_1_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_606_2_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_606_3_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_701_1_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_701_2_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_1_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_2_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_3_PID) },
+   { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_4_PID) },
{ } /* Terminating entry */
 };
 
diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
b/drivers/usb/serial/ftdi_sio_ids.h
index e599fbfcde5f..993c93df6874 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1326,3 +1326,40 @@
  * Manufacturer: Cressi
  */
 #define FTDI_CRESSI_PID0x87d0
+
+/*
+ * Brainboxes devices
+ */
+#define BRAINBOXES_VID 0x05d1
+#define BRAINBOXES_VX_001_PID  0x1001 /* VX-001 ExpressCard 1 Port 
RS232 */
+#define BRAINBOXES_VX_012_PID  0x1002 /* VX-012 ExpressCard 2 Port 
RS232 */
+#define BRAINBOXES_VX_023_PID  0x1003 /* VX-023 ExpressCard 1 Port 
RS422/485 */
+#define BRAINBOXES_VX_034_PID  0x1004 /* VX-034 ExpressCard 2 Port 
RS422/485 */
+#define BRAINBOXES_US_101_PID  0x1011 /* US-101 1xRS232 */
+#define BRAINBOXES_US_324_PID  0x1013 /* US-324 1xRS422/485 1Mbaud */
+#define BRAINBOXES_US_606_1_PID0x2001 /* US-606 6 Port RS232 
Serial Port 1 and 2 */
+#define BRAINBOXES_US_606_2_PID0x2002 /* US-606 6 Port RS232 
Serial Port 3 and 4 */
+#define BRAINBOXES_US_606_3_PID0x2003 /* US-606 6 Port RS232 
Serial Port 4 and 6 */
+#define BRAINBOXES_US_701_1_PID0x2011 /* US-701 4xRS232 1Mbaud 
Port 1 and 2 */
+#define BRAINBOXES_US_701_2_PID0x2012 /* US-701 4xRS422 1Mbaud 
Port 3 and 4 */
+#define BRAINBOXES_US_279_1_PID0x2021 /* US-279 8xRS422 1Mbaud 
Port 1 and 2 */
+#define BRAINBOXES_US_279_2_PID0x2022 /* US-279 8xRS422 1Mbaud 
Port 3 and 4 */
+#define BRAINBOXES_US_279_3_PID0x2023 /* US-279 8xRS422 1Mbaud 
Port 5 and 6 */
+#define BRAINBOXES_US_279_4_PID0x2024 /* US-279 8xRS422 1Mbaud 
Port 7 and 8 */
+#define BRAINBOXES_US_346_1_PID0x3011 /* US-346 4xRS422/485 
1Mbaud Port 1 and 2 */
+#define BRAINBOXES_US_346_2_PID0x3012 /* US-346 4xRS422/485 

Re: [PATCH 1/1] usb: option driver, add support for Telit UE910v2

[Johan Hovold]

On Fri, Mar 28, 2014 at 05:08:56PM +0100, Daniele Palmas wrote:
 option driver, added VID/PID for Telit UE910v2 modem

Thanks for the patch. 

Could you also include the output of lsusb -vd 1bc7:1012 for reference?

 Signed-off-by: Daniele Palmas dnl...@gmail.com
 ---
  drivers/usb/serial/option.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
 index 68fc9fe..8811a5b 100644
 --- a/drivers/usb/serial/option.c
 +++ b/drivers/usb/serial/option.c
 @@ -244,6 +244,7 @@ static void option_instat_callback(struct urb *urb);
  #define TELIT_PRODUCT_CC864_SINGLE   0x1006
  #define TELIT_PRODUCT_DE910_DUAL 0x1010
  #define TELIT_PRODUCT_LE920  0x1200
 +#define TELIT_PRODUCT_UE910_V2   0x1012

Please try to keep the PIDs sorted (numerically).
 
  /* ZTE PRODUCTS */
  #define ZTE_VENDOR_ID0x19d2
 @@ -1043,6 +1044,7 @@ static const struct usb_device_id option_ids[] = {
   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_DE910_DUAL) },
   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920),
   .driver_info = (kernel_ulong_t)telit_le920_blacklist },
 + { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_UE910_V2) },
   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MF622, 0xff, 
 0xff, 0xff) }, /* ZTE WCDMA products */
   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0002, 0xff, 0xff, 
 0xff),
   .driver_info = (kernel_ulong_t)net_intf1_blacklist },

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

Re: [PATCH 2/2] USB: serial: add dell wwan card(413c:81a9)

[Bjørn Mork]

AceLan Kao acelan@canonical.com writes:

 [4.042629] usb 2-8.1: new full-speed USB device number 9 using xhci_hcd
[..]
 [4.095722] usb 2-8.1: not running at top speed; connect to a high speed 
 hub

This is a bit odd, isn't it?  Not related to the serial driver question, though.


[..]

 [4.096989] usb 2-8.1: config 1 has an invalid interface number: 12 but 
 max is 4
 [4.096993] usb 2-8.1: config 1 has an invalid interface number: 13 but 
 max is 4
 [4.096996] usb 2-8.1: config 1 has an invalid interface number: 13 but 
 max is 4
 [4.096998] usb 2-8.1: config 1 has no interface number 1
 [4.097000] usb 2-8.1: config 1 has no interface number 4

Yes, typical for how Sierra does this: Interface numbers 12 and 13 are
used for MBIM, leaving lots of holes in a 5 interface configuration.


 [4.099386] usb 2-8.1: New USB device found, idVendor=413c, idProduct=81a9
 [4.099390] usb 2-8.1: New USB device strings: Mfr=1, Product=2, 
 SerialNumber=3
 [4.099393] usb 2-8.1: Product: Dell Wireless 5808e 
 Gobi\xffe2\xff84\xffa2\xff84\xffa2 4G LTE Mobile 
 Broadband Card
 [4.099395] usb 2-8.1: Manufacturer: Sierra Wireless, Incorporated

[..]

 [4.364597] cdc_mbim 2-8.1:1.12: cdc-wdm0: USB WDM device
 [4.364764] cdc_mbim 2-8.1:1.12 wwan0: register 'cdc_mbim' at 
 usb-:00:14.0-8.1, CDC MBIM, 46:10:e8:c3:a2:02

So the MBIM driver leads the race, making this actually work in this
case.

But I don't think the sierra serial driver looks at class codes, and
it definitely does not blacklist interface 12 and 13, so it would
probably happily have bound to interface 13 if it won the race.

 [5.940610] usbcore: registered new interface driver usbserial
 [5.940628] usbcore: registered new interface driver usbserial_generic
 [5.940642] usbserial: USB Serial support registered for generic
 [5.942641] usbcore: registered new interface driver sierra
 [5.942655] usbserial: USB Serial support registered for Sierra USB modem
 [5.942682] sierra 2-8.1:1.2: Sierra USB modem converter detected

 [5.946191] usb 2-8.1: Sierra USB modem converter now attached to ttyUSB0
 [5.946214] sierra 2-8.1:1.3: Sierra USB modem converter detected
 [5.946577] usb 2-8.1: Sierra USB modem converter now attached to ttyUSB2
 [5.946593] sierra 2-8.1:1.0: Sierra USB modem converter detected
 [5.947277] usb 2-8.1: Sierra USB modem converter now attached to ttyUSB3

OK, this looks like it works without any 5 second timeout. Which I guess
means that the driver can be used, provided the entry is limited to
vendor specific interfaces and using the blacklist.

But is this the most correct driver?  I don't know... The pattern
using ff/ff/ff class interfaces for these functions is common to many
Qualcomm based Sierra Wireless devices:

  0:  QC Device Management
  2:  NMEA
  3:  Modem

Some of these have been added to qcserial, some to option and some are
probably somewhere else.

I have a couple of new devices in this cathegory on todo list already.
Maybe it's time for a serial minidriver explicitly for these devices,
moving them all there?  That would simplify the entries a lot.  


 Bus 002 Device 009: ID 413c:81a9 Dell Computer Corp. 
 Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   2.00
   bDeviceClass0 (Defined at Interface level)
   bDeviceSubClass 0 
   bDeviceProtocol 0 
   bMaxPacketSize064
   idVendor   0x413c Dell Computer Corp.
   idProduct  0x81a9 
   bcdDevice0.06
   iManufacturer   1 Sierra Wireless, Incorporated
   iProduct2 Dell Wireless 5808e Gobi™ 4G LTE Mobile Broadband 
 Card
   iSerial 3 
   bNumConfigurations  1
   Configuration Descriptor:
 bLength 9
 bDescriptorType 2
 wTotalLength  247
 bNumInterfaces  5
 bConfigurationValue 1
 iConfiguration  0 
 bmAttributes 0xe0
   Self Powered
   Remote Wakeup
 MaxPower  500mA
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber2
   bAlternateSetting   0
   bNumEndpoints   3
   bInterfaceClass   255 Vendor Specific Class
   bInterfaceSubClass  0 
   bInterfaceProtocol  0 


OK, so that's ff/00/00 instead of ff/ff/ff.  Something to be aware of if
we try to match on class.  For the record: The Sierra Wireless MC7710
has ff/ff/ff serial functions.

   ** UNRECOGNIZED:  05 24 00 10 01
   ** UNRECOGNIZED:  05 24 01 00 00
   ** UNRECOGNIZED:  04 24 02 02
   ** UNRECOGNIZED:  05 24 06 00 00

We are probably better off continuing to ignore these descriptors, but
they are somewhat typical to Qualcomm serial functions.  You'll
recognise typical CDC functional descriptors for an ACM fucntion:

 

Re: [PATCH 1/1] usb: option driver, add support for Telit UE910v2

[Daniele Palmas]

Hello Johan,

2014-03-31 10:58 GMT+02:00 Johan Hovold jhov...@gmail.com:
 On Fri, Mar 28, 2014 at 05:08:56PM +0100, Daniele Palmas wrote:
 option driver, added VID/PID for Telit UE910v2 modem

 Thanks for the patch.

 Could you also include the output of lsusb -vd 1bc7:1012 for reference?


Bus 002 Device 004: ID 1bc7:1012
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x1bc7
  idProduct  0x1012
  bcdDevice0.00
  iManufacturer   3 Telit Wireless Solutions
  iProduct2 Telit HS-USB Modem
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   92
bNumInterfaces  3
bConfigurationValue 1
iConfiguration  1 Telit Configuration
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   5
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   5
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85  EP 5 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7

Missing functionfs module parameters in /sys/module/g_ffs/parameters/

[tzippy]

Hello!
I am on a phyFLEX-i.MX 6 running kernel 3.0.35.
I want to set module parameters for idVendor, idProduct and iSerialNumber.
However, in /sys/module/g_ffs/parameters/ all I have is
bDeviceClass, bDeviceProtocol
and bDeviceSubClass.
The BSP is the latest Release PD13.2.2 (kernel 3.0.35) from Phytec
(http://www.phytec.com/wiki/index.php/PhyFLEX-i.MX6_Linux_BSP-PD13.2.2).
Can someone help out?
--
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

gadgetfs: usb.c not working on samsung nexus s(exynos SoC)

[Taras Iks]

Hello,

I changed usb.c and crossompiled it for samsung nexus s(exynos SoC).
arm-linux-gnueabi-gcc -static usb.c usbstring.c -lpthread

In the kernel I enable gadgetfs module with s3c-udc(s3c_udc_otg.c)

I can mount gadgetfs, but when I run the binary with verbose flag I
get following
output on device side:

/dev/gadget/s3c-udc ep0 configured
serial=adfczl3sdf39idgfo7tdsfv2ss6l3tarbfdfsdjs5m2uffusdflwmfgfs

** Thu Jan  1 00:38:19 1970
CONNECT high speed
DISCONNECT
CONNECT high speed
DISCONNECT
CONNECT high speed
DISCONNECT
CONNECT high speed
DISCONNECT
CONNECT high speed
DISCONNECT
CONNECT high speed

and on the Host:

[ 5453.889566] usb 2-1.5: device descriptor read/64, error 18
[ 5454.065627] usb 2-1.5: device descriptor read/64, error 18
[ 5454.241502] usb 2-1.5: new high-speed USB device number 4 using ehci-pci
[ 5454.313667] usb 2-1.5: device descriptor read/64, error 18
[ 5454.489593] usb 2-1.5: device descriptor read/64, error 18
[ 5454.665655] usb 2-1.5: new high-speed USB device number 5 using ehci-pci
[ 5454.686276] usb 2-1.5: device descriptor read/8, error -61
[ 5454.806488] usb 2-1.5: device descriptor read/8, error -61
[ 5454.981641] usb 2-1.5: new high-speed USB device number 6 using ehci-pci
[ 5455.014346] usb 2-1.5: device descriptor read/8, error -71
[ 5455.146450] usb 2-1.5: device descriptor read/8, error -71

If I sniff the communication with Wireshark, there is an error message:
malformed package

Please help! What could be the cause of this issue?
--
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 07/11] usb: chipidea: OTG HNP and SRP fsm implementation.

[Li Jun]

On Mon, Mar 31, 2014 at 03:24:35PM +0800, Peter Chen wrote:
 On Sun, Mar 30, 2014 at 08:20:09PM +0800, Li Jun wrote:
  From: Li Jun b47...@freescale.com
  
  USB OTG interrupt handling and fsm transitions according to USB OTG
  and EH 2.0.
  
  Signed-off-by: Li Jun b47...@freescale.com
  ---
   drivers/usb/chipidea/core.c|8 +-
   drivers/usb/chipidea/otg.c |9 +-
   drivers/usb/chipidea/otg_fsm.c |  236 
  
   drivers/usb/chipidea/otg_fsm.h |   18 +++
   drivers/usb/chipidea/udc.c |6 +
   5 files changed, 273 insertions(+), 4 deletions(-)
  
  diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
  index ff38cf3..6544149 100644
  --- a/drivers/usb/chipidea/core.c
  +++ b/drivers/usb/chipidea/core.c
  @@ -42,7 +42,6 @@
* - Not Supported: 15  16 (ISO)
*
* TODO List
  - * - OTG
* - Interrupt Traffic
* - GET_STATUS(device) - always reports 0
* - Gadget API (majority of optional features)
  @@ -74,6 +73,7 @@
   #include host.h
   #include debug.h
   #include otg.h
  +#include otg_fsm.h
   
   /* Controller register map */
   static const u8 ci_regs_nolpm[] = {
  @@ -412,8 +412,12 @@ static irqreturn_t ci_irq(int irq, void *data)
  irqreturn_t ret = IRQ_NONE;
  u32 otgsc = 0;
   
  -   if (ci-is_otg)
  +   if (ci-is_otg) {
  otgsc = hw_read_otgsc(ci, ~0);
  +   ret = ci_otg_fsm_irq(ci);
  +   if (ret == IRQ_HANDLED)
  +   return ret;
  +   }
   
  /*
   * Handle id change interrupt, it indicates device/host function
  diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
  index b278cd9..5169640 100644
  --- a/drivers/usb/chipidea/otg.c
  +++ b/drivers/usb/chipidea/otg.c
  @@ -11,8 +11,8 @@
*/
   
   /*
  - * This file mainly handles otgsc register, it may include OTG operation
  - * in the future.
  + * This file mainly handles otgsc register, OTG fsm operations for HNP and 
  SRP
  + * are also included.
*/
   
   #include linux/usb/otg.h
  @@ -91,6 +91,11 @@ static void ci_otg_work(struct work_struct *work)
   {
  struct ci_hdrc *ci = container_of(work, struct ci_hdrc, work);
   
  +   if (!ci_otg_fsm_work(ci)) {
  +   enable_irq(ci-irq);
  +   return;
  +   }
  +
  if (ci-id_event) {
  ci-id_event = false;
  ci_handle_id_switch(ci);
  diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
  index d49bbdd..8e30fc64 100644
  --- a/drivers/usb/chipidea/otg_fsm.c
  +++ b/drivers/usb/chipidea/otg_fsm.c
  @@ -13,6 +13,10 @@
   /*
* This file mainly handles OTG fsm, it includes OTG fsm operations
* for HNP and SRP.
  + *
  + * TODO List
  + * - ADP
  + * - OTG test device
*/
   
   #include linux/usb/otg.h
  @@ -92,6 +96,33 @@ static void ci_otg_del_timer(struct ci_hdrc *ci, enum 
  ci_otg_fsm_timer_index t)
  hw_write_otgsc(ci, OTGSC_1MSIE, 0);
   }
   
  +/*
  + * Reduce timer count by 1, and find timeout conditions.
  + * Called by otg 1ms timer interrupt
  + */
  +static inline int ci_otg_tick_timer(struct ci_hdrc *ci)
  +{
  +   struct ci_otg_fsm_timer *tmp_timer, *del_tmp;
  +   struct list_head *active_timers = ci-fsm_timer-active_timers;
  +   int expired = 0;
  +
  +   list_for_each_entry_safe(tmp_timer, del_tmp, active_timers, list) {
  +   tmp_timer-count--;
  +   /* check if timer expires */
  +   if (!tmp_timer-count) {
  +   list_del(tmp_timer-list);
  +   tmp_timer-function(ci, tmp_timer-data);
  +   expired = 1;
  +   }
  +   }
  +
  +   /* disable 1ms irq if there is no any timer active */
  +   if ((expired == 1)  list_empty(active_timers))
  +   hw_write_otgsc(ci, OTGSC_1MSIE, 0);
  +
  +   return expired;
  +}
  +
   /* The timeout callback function to set time out bit */
   static void set_tmout(void *ptr, unsigned long indicator)
   {
  @@ -385,6 +416,209 @@ static struct otg_fsm_ops ci_otg_ops = {
  .start_gadget = ci_otg_start_gadget,
   };
   
  +int ci_otg_fsm_work(struct ci_hdrc *ci)
  +{
  +   if (!ci-transceiver-otg)
  +   return -ENODEV;
  +
  +   /*
  +* Don't do fsm transition for B device
  +* when there is no gadget class driver
  +*/
  +   if (ci-fsm.id  !(ci-driver) 
  +   ci-transceiver-state  OTG_STATE_A_IDLE)
 
 Why the third condition is needed?
 

To make a_ state can be transfered to next state when micro-A plug is 
removed
(id is 1) while gadget driver is not enabled.

  +   return 0;
  +
  +   if (otg_statemachine(ci-fsm)) {
  +   if (ci-transceiver-state == OTG_STATE_A_IDLE) {
  +   if (ci-fsm.id)
  +   /* A idle to B idle */
  +   otg_statemachine(ci-fsm);
  +   else if ((ci-id_event) || (ci-fsm.power_up)) {
  +   ci-id_event = false;
  +

BUG: Kernel Panic: skb_over_panic with am335 - musb - ax88760

[Pascal Speck]

Hello List, 

i’m not very familiar with reporting Bugs, this is my first Try, so please
be indulgent to me, when I do something wrong. 
I hope, I’m thinking on all Information you need and I have the list.

I don’t really know if the problem is sourced on musb or the ASIX driver. 
The error is reproducible every time I start the system over NFS and I have
the possibility to debug into the kernel within KGDB, but at this moment I
don’t know the structure of musb networking, so I don’t know where to start
debugging.

Could someone please give me answer, if I’m right on this way telling the
bug or if I should try something else and provide more information.
I really need this working driver for a very time-critical project of one of
my customers and I’m willing to work on a fix if you tell me how.

I have the following Problem:
When booting the Linux Kernel with the following constellation:

AM335 -MUSB - AX88760 over NFS

I get the following Output:

[    0.00] Booting Linux on physical CPU 0x0 [    0.00] Initializing
cgroup subsys cpuset [    0.00] Initializing cgroup subsys cpu [   
0.00] Initializing cgroup subsys cpuacct [    0.00] Linux version
3.14.0-rc7+ (root@ThinkPad) (gcc version 4.7.3 (Buildroot 2013.11) ) #19 Sun
Mar 30 18:55:05 CEST 2014 [    0.00] CPU: ARMv7 Processor [413fc082]
revision 2 (ARMv7), cr=10c5387d [    0.00] CPU: PIPT / VIPT nonaliasing
data cache, VIPT aliasing instruction cache [    0.00] Machine model: TI
AM335x BeagleBone [    0.00] cma: CMA: reserved 16 MiB at 9f00 [   
0.00] Memory policy: Data cache writeback [    0.00] CPU: All CPU(s)
started in SVC mode.
[    0.00] AM335X ES2.0 (sgx neon )
[    0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total
pages: 130048 [    0.00] Kernel command line: console=ttyO0,115200n8
root=/dev/nfs rw nfsroot=192.168.30.235:/srv/root nolock rsize=4096
wsize=4096
ip=192.168.30.236:192.168.30.235:192.168.30.2:255.255.255.0:Xenon:eth1:off
kgdbwait kgdboc=ttyO0,115200 [    0.00] PID hash table entries: 2048
(order: 1, 8192 bytes) [    0.00] Dentry cache hash table entries: 65536
(order: 6, 262144 bytes) [    0.00] Inode-cache hash table entries:
32768 (order: 5, 131072 bytes) [    0.00] allocated 1048576 bytes of
page_cgroup [    0.00] please try 'cgroup_disable=memory' option if you
don't want memory cgroups [    0.00] Memory: 493272K/524288K available
(6076K kernel code, 391K rwdata, 1832K rodata, 191K init, 422K bss, 31016K
reserved, 0K highmem) [    0.00] Virtual kernel memory layout:
[    0.00] vector  : 0x - 0x1000   (   4 kB) [   
0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB) [   
0.00] vmalloc : 0xe080 - 0xff00   ( 488 MB) [   
0.00] lowmem  : 0xc000 - 0xe000   ( 512 MB) [   
0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB) [   
0.00]   .text : 0xc0008000 - 0xc07c14ac   (7910 kB) [   
0.00]   .init : 0xc07c2000 - 0xc07f1d24   ( 192 kB) [   
0.00]   .data : 0xc07f2000 - 0xc0853e60   ( 392 kB) [   
0.00]    .bss : 0xc0853e60 - 0xc08bd878   ( 423 kB) [    0.00]
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [    0.00]
NR_IRQS:16 nr_irqs:16 16 [    0.00] IRQ: Found an INTC at 0xfa20
(revision 5.0) with 128 interrupts [    0.00] Total of 128 interrupts on
1 active controller [    0.00] OMAP clockevent source: timer2 at
2400 Hz [    0.09] sched_clock: 32 bits at 24MHz, resolution 41ns,
wraps every 178956969942ns [    0.26] OMAP clocksource: timer1 at
2400 Hz [    0.000200] Console: colour dummy device 80x30 [    0.000226]
Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736) [    0.089555]
pid_max: default: 32768 minimum: 301 [    0.089684] Mount-cache hash table
entries: 512 [    0.095009] Initializing cgroup subsys memory [    0.095051]
Initializing cgroup subsys devices [    0.095061] Initializing cgroup subsys
freezer [    0.095069] Initializing cgroup subsys blkio [    0.095076]
Initializing cgroup subsys perf_event [    0.095163] CPU: Testing write
buffer coherency: ok [    0.095499] Setting up static identity map for
0x805bdbb0 - 0x805bdc08 [    0.096401] devtmpfs: initialized [    0.098173]
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3 [   
0.103513] omap_hwmod: tptc0 using broken dt data from edma [    0.103575]
omap_hwmod: tptc1 using broken dt data from edma [    0.103628] omap_hwmod:
tptc2 using broken dt data from edma [    0.107500] omap_hwmod: debugss:
_wait_target_disable failed [    0.161906] pinctrl core: initialized pinctrl
subsystem [    0.162233] regulator-dummy: no parameters [    0.163384] NET:
Registered protocol family 16 [    0.165227] DMA: preallocated 256 KiB pool
for atomic coherent allocations [    0.165779] cpuidle: using governor
ladder [    0.165790] cpuidle: using governor menu [    0.171572]
pinctrl-single 44e10800.pinmux: 

Re: CDC ACM problem

[Martin Åkerberg]

I have done some more testing now.

It seems there is no problem on newer kernels. The problem seems to
disappear somewhere around version 3.5.

And also, I was only seeing this problem on a computer with Intel QM77
chipset. With another older computer there was no problem even with
kernel version 3.2.

/Martin



2014-03-24 14:55 GMT+01:00 Martin Åkerberg martin.aakerb...@gmail.com:
 thanks for the response,

 I will try to reproduce the problem on the latest mainline kernel.

 Regards,

 Martin

 2014-03-22 13:21 GMT+01:00 Johan Hovold jhov...@gmail.com:
 On Thu, Mar 20, 2014 at 02:31:30PM +0100, Martin Åkerberg wrote:
 Hi Johan,

 You seem to be last contributor to cdc-acm driver in linux. I don't know if
 you are the correct person to ask, or if you have the time to answer, but
 if not, could you point me to the correct forum?

 The linux-usb list (added as CC) would be that forum.

 Anyway, I am implementing a CDC-ACM device in a Atmel XMEGA processor. I am
 interfacing this from a c-program on a Linux machine. Everything is working
 as expected when it comes to opening the /dev/ttyACM0, configuring the
 terminal, reading and sending data and closing the device. The problem
 occurs when I try to open and close the device repeatedly many times.

 As a test: With a simple c-program I open and close the device in an
 endless loop. Before every open and close I have a 100ms delay. I can see
 on my device that setup messages with control line signals is sent on every
 open and close, as expected.

 After about 50-500 cycles the open call fails. The message I can read in
 dmesg is:

 [xxx] xhci_hcd :00:14.0 ERROR no room on ep ring
 [xxx] cdc_acm 3-3:1.1: acm_submit_read_urb - usb_submit_urb failed: -12

 I read this as memory overflow regarding read urbs. I see in the kernel
 code that 16 read urbs are allocated everytime the port is opened. But
 these read urbs should be killed in the acm_port_shutdown function, which
 might get called via

 tty_port_close
tty_port_shutdown
 port-ops-shutdown

 I say might since it seems it doesn't happen in my case.

 Do you have any idea why this might be?

 Well, this appears to be a problem in the xhci-driver, and not directly
 related to cdc-acm. Specifically, the -ENOMEM (-12) above originates in
 the xhci-driver when it fails to enqueue the urb.

 [ The cdc-acm driver allocates its urbs on probe and releases them when
   the device is unbound. ]

 I don't see any of the kernel warnings from tty_port_close_start,

 The uname -r output is: 3.2.0.23-generic

 That is a fairly old kernel (and also a distro-kernel?). I'd suggest you
 try to reproduce this on a more recent mainline kernel such as v3.13.6
 (or v3.14-rc7).

 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

Discussion: Link Layer Test implementation strategy for Linux Embedded Host

[Pratyush Anand]

Hi Alan/Greg,

I was starting some work for running Lecroy USB Compliance Suite Link
Layer Tests with embedded xhci host, which runs Linux. I thought, its
wise to discuss my test strategy before I start implementing it,
as in long run I would like to push them to mainline.

These tests have been defined in USB 3.0 Link Layer Test
Specification.

For a xhci host's downstream port under test (PUT), Lecroy excersizer with 
USB Compliance Suite acts as Link Validation System (LVS).

Most of the link layer tests only expects link to be in U0. If a host
sends a setup packet, it is NAKed by LVS. However, there are some
tests which ask host to send some control command like Get Descriptor
etc.

To add support of these tests, I wanted to go as under:

1. Add a quirk flag for the root hub sysfs device node to prevent enumeration
   of a device.
2. Before a lecroy LVS device is connected to the root hub n, do something like
this.
echo 1   /sys/bus/usb/devices/usbn/avoid_enum_quirk
3. Now connect LVS device and run Link Layer tests from Lecroy USB
Compliance Suite.
4. To get back into normal working situation (to connect a general usb device
to root hub n), do following:
echo 0   /sys/bus/usb/devices/usbn/avoid_enum_quirk
5. Modify hub driver to prevent enumeration when a new device is connected and 
this flag is set.
 Create a new dummy device (VID, PID to be discussed with 
ssusbcomplia...@usb.org),
and call its driver (say lvstestdev). (Is there a way to call use
driver on the basis of name only?)
This lvstestdev implements further sys nodes/or some other
method like ioctl etc to allow an application to generate traffic
for some specific test case.
6. When this device is disconnected then the created dummy device is
destroyed. (Even a single test case may generate multiple
connection/disconnection from LVS)

Do, you think this flow would be correct, or there could be some
better approach?

Regards
Pratyush


--
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: CDC ACM problem

[Johan Hovold]

On Mon, Mar 31, 2014 at 01:04:52PM +0200, Martin Åkerberg wrote:
 I have done some more testing now.
 
 It seems there is no problem on newer kernels. The problem seems to
 disappear somewhere around version 3.5.
 
 And also, I was only seeing this problem on a computer with Intel QM77
 chipset. With another older computer there was no problem even with
 kernel version 3.2.

That's good. Thanks for reporting back.

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

Re: [PATCH 1/3] [SCSI] Fix abort state memory problem

[Alan Stern]

On Mon, 31 Mar 2014, Hannes Reinecke wrote:

 On 03/28/2014 06:49 PM, James Bottomley wrote:
  The abort state is being stored persistently across commands, meaning if the
  command times out a second time, the error handler thinks an abort is still
  pending.  Fix this by properly resetting the abort flag after the abort is
  finished.
  
  Signed-off-by: James Bottomley jbottom...@parallels.com
  ---
   drivers/scsi/scsi_error.c | 9 ++---
   1 file changed, 6 insertions(+), 3 deletions(-)
  
  diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
  index 771c16b..b9f3b07 100644
  --- a/drivers/scsi/scsi_error.c
  +++ b/drivers/scsi/scsi_error.c
  @@ -869,10 +869,13 @@ static int scsi_try_bus_device_reset(struct scsi_cmnd 
  *scmd)
   
   static int scsi_try_to_abort_cmd(struct scsi_host_template *hostt, struct 
  scsi_cmnd *scmd)
   {
  -   if (!hostt-eh_abort_handler)
  -   return FAILED;
  +   int retval = FAILED;
  +
  +   if (hostt-eh_abort_handler)
  +   retval = hostt-eh_abort_handler(scmd);
   
  -   return hostt-eh_abort_handler(scmd);
  +   scmd-eh_eflags = ~SCSI_EH_ABORT_SCHEDULED;
  +   return retval;
   }
   
   static void scsi_abort_eh_cmnd(struct scsi_cmnd *scmd)
  
 Hmm. No, I don't think this is correct.
 
 SCSI_EH_ABORT_SCHEDULED signifies whether scmd_eh_abort_handler()
 needs to run. As such it needs to be reset when the workqueue item
 is triggered.
 
 Can you try with this instead?
 
 diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
 index 771c16b..9694803 100644
 --- a/drivers/scsi/scsi_error.c
 +++ b/drivers/scsi/scsi_error.c
 @@ -120,6 +120,8 @@ scmd_eh_abort_handler(struct work_struct *work)
 struct scsi_device *sdev = scmd-device;
 int rtn;
 
 +   scmd-eh_eflags = ~SCSI_EH_ABORT_SCHEDULED;
 +
 if (scsi_host_eh_past_deadline(sdev-host)) {
 SCSI_LOG_ERROR_RECOVERY(3,
 scmd_printk(KERN_INFO, scmd,

This doesn't seem like a good idea either, because the flag is tested 
later on in scsi_decide_disposition().

Alan Stern

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

RE: [PATCH] USB:pl2303: add ids for Hewlett-Packard HP POS pole displays

[Sanders, Aaron]

I don't know why diff deletes:
 -#define HP_VENDOR_ID  0x03f0
 -#define HP_LD220_PRODUCT_ID   0x3524

and then adds them again.  I didn't touch those lines.  I suspect that it is 
due to the comment update above them.  

Thanks,
Aaron

-Original Message-
From: Johan Hovold [mailto:jhov...@gmail.com] 
Sent: Saturday, March 29, 2014 5:20 AM
To: Sanders, Aaron
Cc: Johan Hovold; linux-usb@vger.kernel.org
Subject: Re: [PATCH] USB:pl2303: add ids for Hewlett-Packard HP POS pole 
displays

On Fri, Mar 28, 2014 at 06:29:36PM +, Sanders, Aaron wrote:
 Add device ids to pl2303 for the Hewlett-Packard HP POS pole displays:
 LD960: 03f0:0B39
 LCM220: 03f0:3139
 LCM960: 03f0:3239
 
 Signed-off-by: Aaron Sanders aaron.sand...@hp.com
 
 diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c

That's better, but now the diff is messed up below.

Also, please add a space between USB: and pl2303: in your subject.

 index 3b5ba4f..4d70809 100644
 --- a/drivers/usb/serial/pl2303.c
 +++ b/drivers/usb/serial/pl2303.c
 @@ -82,6 +82,9 @@ static const struct usb_device_id id_table[] = {
   { USB_DEVICE(YCCABLE_VENDOR_ID, YCCABLE_PRODUCT_ID) },
   { USB_DEVICE(SUPERIAL_VENDOR_ID, SUPERIAL_PRODUCT_ID) },
   { USB_DEVICE(HP_VENDOR_ID, HP_LD220_PRODUCT_ID) },
 + { USB_DEVICE(HP_VENDOR_ID, HP_LD960_PRODUCT_ID) },
 + { USB_DEVICE(HP_VENDOR_ID, HP_LCM220_PRODUCT_ID) },
 + { USB_DEVICE(HP_VENDOR_ID, HP_LCM960_PRODUCT_ID) },
   { USB_DEVICE(CRESSI_VENDOR_ID, CRESSI_EDY_PRODUCT_ID) },
   { USB_DEVICE(ZEAGLE_VENDOR_ID, ZEAGLE_N2ITION3_PRODUCT_ID) },
   { USB_DEVICE(SONY_VENDOR_ID, SONY_QN3USB_PRODUCT_ID) }, diff --git 
 a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h index 
 c38b8c0..ec183d1 100644
 --- a/drivers/usb/serial/pl2303.h
 +++ b/drivers/usb/serial/pl2303.h
 @@ -121,9 +121,12 @@
  #define SUPERIAL_VENDOR_ID   0x5372
  #define SUPERIAL_PRODUCT_ID  0x2303
  
 -/* Hewlett-Packard LD220-HP POS Pole Display */
 -#define HP_VENDOR_ID 0x03f0
 -#define HP_LD220_PRODUCT_ID  0x3524
 +//* Hewlett-Packard POS Pole Displays */
 + #define HP_VENDOR_ID0x03f0
 + #define HP_LD220_PRODUCT_ID 0x3524
 + #define HP_LD960_PRODUCT_ID 0x0B39
 + #define HP_LCM220_PRODUCT_ID0x3139
 + #define HP_LCM960_PRODUCT_ID0x3239

Why are you modifying existing lines? The indentation was correct (none) and 
now there's also a stray '/' turning that comment into a c99 one (which we do 
not use).

You should run any submissions through scripts/checkpatch.pl which would at 
least have caught the c99-comment mistake.

  /* Cressi Edy (diving computer) PC interface */
  #define CRESSI_VENDOR_ID 0x04b8

Care to give it one more try?

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

Re: [PATCH] USB:pl2303: add ids for Hewlett-Packard HP POS pole displays

[Johan Hovold]

[ Please avoid top-posting. ]

On Mon, Mar 31, 2014 at 01:10:11PM +, Sanders, Aaron wrote:
 I don't know why diff deletes:
  -#define HP_VENDOR_ID0x03f0
  -#define HP_LD220_PRODUCT_ID 0x3524
 
 and then adds them again.  I didn't touch those lines.  I suspect that
 it is due to the comment update above them.  

Well, you or your editor did add that extra space at the beginning of
those lines (which git-diff reports).

Your original diff was correct (although not generated from the root).
Simply commit it to a git tree and run git format-patch and all should
be good.

Johan

 -Original Message-
 From: Johan Hovold [mailto:jhov...@gmail.com] 
 Sent: Saturday, March 29, 2014 5:20 AM
 To: Sanders, Aaron
 Cc: Johan Hovold; linux-usb@vger.kernel.org
 Subject: Re: [PATCH] USB:pl2303: add ids for Hewlett-Packard HP POS pole 
 displays
 
 On Fri, Mar 28, 2014 at 06:29:36PM +, Sanders, Aaron wrote:
  Add device ids to pl2303 for the Hewlett-Packard HP POS pole displays:
  LD960: 03f0:0B39
  LCM220: 03f0:3139
  LCM960: 03f0:3239
  
  Signed-off-by: Aaron Sanders aaron.sand...@hp.com
  
  diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
 
 That's better, but now the diff is messed up below.
 
 Also, please add a space between USB: and pl2303: in your subject.
 
  index 3b5ba4f..4d70809 100644
  --- a/drivers/usb/serial/pl2303.c
  +++ b/drivers/usb/serial/pl2303.c
  @@ -82,6 +82,9 @@ static const struct usb_device_id id_table[] = {
  { USB_DEVICE(YCCABLE_VENDOR_ID, YCCABLE_PRODUCT_ID) },
  { USB_DEVICE(SUPERIAL_VENDOR_ID, SUPERIAL_PRODUCT_ID) },
  { USB_DEVICE(HP_VENDOR_ID, HP_LD220_PRODUCT_ID) },
  +   { USB_DEVICE(HP_VENDOR_ID, HP_LD960_PRODUCT_ID) },
  +   { USB_DEVICE(HP_VENDOR_ID, HP_LCM220_PRODUCT_ID) },
  +   { USB_DEVICE(HP_VENDOR_ID, HP_LCM960_PRODUCT_ID) },
  { USB_DEVICE(CRESSI_VENDOR_ID, CRESSI_EDY_PRODUCT_ID) },
  { USB_DEVICE(ZEAGLE_VENDOR_ID, ZEAGLE_N2ITION3_PRODUCT_ID) },
  { USB_DEVICE(SONY_VENDOR_ID, SONY_QN3USB_PRODUCT_ID) }, diff --git 
  a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h index 
  c38b8c0..ec183d1 100644
  --- a/drivers/usb/serial/pl2303.h
  +++ b/drivers/usb/serial/pl2303.h
  @@ -121,9 +121,12 @@
   #define SUPERIAL_VENDOR_ID 0x5372
   #define SUPERIAL_PRODUCT_ID0x2303
   
  -/* Hewlett-Packard LD220-HP POS Pole Display */
  -#define HP_VENDOR_ID   0x03f0
  -#define HP_LD220_PRODUCT_ID0x3524
  +//* Hewlett-Packard POS Pole Displays */
  + #define HP_VENDOR_ID  0x03f0
  + #define HP_LD220_PRODUCT_ID   0x3524
  + #define HP_LD960_PRODUCT_ID   0x0B39
  + #define HP_LCM220_PRODUCT_ID  0x3139
  + #define HP_LCM960_PRODUCT_ID  0x3239
 
 Why are you modifying existing lines? The indentation was correct (none) and 
 now there's also a stray '/' turning that comment into a c99 one (which we do 
 not use).
 
 You should run any submissions through scripts/checkpatch.pl which would at 
 least have caught the c99-comment mistake.
 
   /* Cressi Edy (diving computer) PC interface */
   #define CRESSI_VENDOR_ID   0x04b8
 
 Care to give it one more try?
 
 Thanks,
 Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] USB:pl2303: add ids for Hewlett-Packard HP POS pole displays

[Sanders, Aaron]

 -Original Message-
 From: Johan Hovold [mailto:jhov...@gmail.com]
 Sent: Monday, March 31, 2014 8:16 AM
 To: Sanders, Aaron
 Cc: Johan Hovold; linux-usb@vger.kernel.org
 Subject: Re: [PATCH] USB:pl2303: add ids for Hewlett-Packard HP POS pole
 displays
 
 [ Please avoid top-posting. ]
 
 On Mon, Mar 31, 2014 at 01:10:11PM +, Sanders, Aaron wrote:
  I don't know why diff deletes:
   -#define HP_VENDOR_ID  0x03f0
   -#define HP_LD220_PRODUCT_ID   0x3524
 
  and then adds them again.  I didn't touch those lines.  I suspect that
  it is due to the comment update above them.
 
 Well, you or your editor did add that extra space at the beginning of those
 lines (which git-diff reports).
 
 Your original diff was correct (although not generated from the root).
 Simply commit it to a git tree and run git format-patch and all should be 
 good.

In the original submission I did not change the comment about the pole display. 
 I noticed in a revision that comment referred to only one of the poles.  I 
tried committing the change and comparing back to the tag, but I get it still 
removes the lines and adds them again.  

 
 Johan
 
  -Original Message-
  From: Johan Hovold [mailto:jhov...@gmail.com]
  Sent: Saturday, March 29, 2014 5:20 AM
  To: Sanders, Aaron
  Cc: Johan Hovold; linux-usb@vger.kernel.org
  Subject: Re: [PATCH] USB:pl2303: add ids for Hewlett-Packard HP POS
  pole displays
 
  On Fri, Mar 28, 2014 at 06:29:36PM +, Sanders, Aaron wrote:
   Add device ids to pl2303 for the Hewlett-Packard HP POS pole displays:
   LD960: 03f0:0B39
   LCM220: 03f0:3139
   LCM960: 03f0:3239
  
   Signed-off-by: Aaron Sanders aaron.sand...@hp.com
  
   diff --git a/drivers/usb/serial/pl2303.c
   b/drivers/usb/serial/pl2303.c
 
  That's better, but now the diff is messed up below.
 
  Also, please add a space between USB: and pl2303: in your subject.
 
   index 3b5ba4f..4d70809 100644
   --- a/drivers/usb/serial/pl2303.c
   +++ b/drivers/usb/serial/pl2303.c
   @@ -82,6 +82,9 @@ static const struct usb_device_id id_table[] = {
 { USB_DEVICE(YCCABLE_VENDOR_ID, YCCABLE_PRODUCT_ID) },
 { USB_DEVICE(SUPERIAL_VENDOR_ID, SUPERIAL_PRODUCT_ID) },
 { USB_DEVICE(HP_VENDOR_ID, HP_LD220_PRODUCT_ID) },
   + { USB_DEVICE(HP_VENDOR_ID, HP_LD960_PRODUCT_ID) },
   + { USB_DEVICE(HP_VENDOR_ID, HP_LCM220_PRODUCT_ID) },
   + { USB_DEVICE(HP_VENDOR_ID, HP_LCM960_PRODUCT_ID) },
 { USB_DEVICE(CRESSI_VENDOR_ID, CRESSI_EDY_PRODUCT_ID) },
 { USB_DEVICE(ZEAGLE_VENDOR_ID,
 ZEAGLE_N2ITION3_PRODUCT_ID) },
 { USB_DEVICE(SONY_VENDOR_ID, SONY_QN3USB_PRODUCT_ID) },
 diff --git
   a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h index
   c38b8c0..ec183d1 100644
   --- a/drivers/usb/serial/pl2303.h
   +++ b/drivers/usb/serial/pl2303.h
   @@ -121,9 +121,12 @@
#define SUPERIAL_VENDOR_ID   0x5372
#define SUPERIAL_PRODUCT_ID  0x2303
  
   -/* Hewlett-Packard LD220-HP POS Pole Display */
   -#define HP_VENDOR_ID 0x03f0
   -#define HP_LD220_PRODUCT_ID  0x3524
   +//* Hewlett-Packard POS Pole Displays */
   + #define HP_VENDOR_ID0x03f0
   + #define HP_LD220_PRODUCT_ID 0x3524
   + #define HP_LD960_PRODUCT_ID 0x0B39
   + #define HP_LCM220_PRODUCT_ID0x3139
   + #define HP_LCM960_PRODUCT_ID0x3239
 
  Why are you modifying existing lines? The indentation was correct (none)
 and now there's also a stray '/' turning that comment into a c99 one (which
 we do not use).
 
  You should run any submissions through scripts/checkpatch.pl which would
 at least have caught the c99-comment mistake.
 
/* Cressi Edy (diving computer) PC interface */
#define CRESSI_VENDOR_ID 0x04b8
 
  Care to give it one more try?
 
  Thanks,
  Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Fix USB deadlock caused by SCSI error handling

[Alan Stern]

On Mon, 31 Mar 2014, Hannes Reinecke wrote:

 On 03/28/2014 08:29 PM, Alan Stern wrote:
  On Fri, 28 Mar 2014, James Bottomley wrote:
  
  This is a set of three patches we agreed to a while ago to eliminate a
  USB deadlock.  I did rewrite the first patch, if it could be reviewed
  and tested.
  
  I tested all three patches under the same conditions as before, and 
  they all worked correctly.
  
  In the revised patch 1, the meaning of SCSI_EH_ABORT_SCHEDULED isn't
  entirely clear.  This boils down to two questions, which I don't 
  know the answers to:
  
  What should happen in scmd_eh_abort_handler() if
  scsi_host_eh_past_deadline() returns true and thereby
  prevents scsi_try_to_abort_cmd() from being called?
  The flag wouldn't get cleared then.
  
 Ah. Correct. But that's due to the first patch being incorrect.
 Cf my response to the original first patch.

See my response to your response.  :-)

  What should happen if some other pathway manages to call
  scsi_try_to_abort_cmd() while scmd-abort_work is still
  sitting on the work queue?  The command would be aborted
  and the flag would be cleared, but the queued work would
  remain.  Can this ever happen?
  
 Not that I could see.
 A command abort is only ever triggered by the request timeout from
 the block layer. And the timer is _not_ rearmed once the timeout
 function (here: scsi_times_out()) is called.
 Hence I fail to see how it can be called concurrently.

scsi_try_to_abort_cmd() is also called (via a different pathway) when a 
command sent by the error handler itself times out.  I haven't traced 
through all the different paths to make sure none of them can run 
concurrently.  But I'm willing to take your word for it.

  Maybe scmd_eh_abort_handler() should check the flag before doing
  anything.  Is there any sort of sychronization to prevent the same
  incarnation of a command from being aborted twice (or by two different
  threads at the same time)?  If there is, it isn't obvious.
  
 See above. scsi_times_out() will only ever called once.
 What can happen, though, is that _theoretically_ the LLDD might
 decide to call -done() on a timed out command when
 scsi_eh_abort_handler() is still pending.

That's okay.  We can expect the LLDD to have sufficient locking to
handle that sort of thing without confusion (usb-storage does, for
example).

  (Also, what's going on at the start of scsi_abort_command()?  Contrary
  to what one might expect, the first part of the function _cancels_ a
  scheduled abort.  And it does so without clearing the
  SCSI_EH_ABORT_SCHEDULED flag.)
  
 The original idea was this:
 
 SCSI_EH_ABORT_SCHEDULED is sticky _per command_.
 Point is, any command abort is only ever send for a timed-out
 command. And the main problem for a timed-out command is that we
 simply _do not_ know what happened for that command. So _if_ a
 command timed out, _and_ we've send an abort, _and_ the command
 times out _again_ we'll be running into an endless loop between
 timeout and aborting, and never returning the command at all.
 
 So to prevent this we should set a marker on that command telling it
 to _not_ try to abort the command again.

I disagree.  We _have_ to abort the command again -- how else can we
stop a running command?  To prevent the loop you described, we should
avoid _retrying_ the command after it is aborted the second time.

 Which is what 'SCSI_EH_ABORT_SCHEDULED' was meant for:
 
 - A command times out, sets 'SCSI_EH_ABORT_SCHEDULED'
 - abort _succeeds_
 - The same command times out a second time, notifies
   that SCSI_EH_ABORT_SCHEDULED is set, and doesn't call
   scsi_eh_abort_command() but rather escalates directly.

The proper time to escalate is after the command is aborted again, not
while the command is still running.  The only situation where you might
want to escalate while a command is still running would be if you were
unable to abort the command.

(Hmmm, maybe that's not true for SCSI devices in general.  It is true 
for USB mass-storage, however.  Perhaps the reset handlers in 
usb-storage should be changed so that they will automatically abort a 
running command before starting the reset.)

 _However_, I do feel that we've gotten the wrong track with all of
 this. In you original mail you stated:
 
  Basically, usb-storage deadlocks when the SCSI error handler
  invokes the eh_device_reset_handler callback while a command
  is running.  The command has timed out and will never complete
  normally, because the device's firmware has crashed.  But
  usb-storage's device-reset routine waits for the current command
  to finish, which brings everything to a standstill.
 
 Question now to you as the USB god:
 
 A command abort is only _ever_ send after a command timeout.
 And the main idea of the command abort is to remove any context
 the LLDD or the target might have. So by the time the command
 abort returns SUCCESS we _expect_ the firmware to have cleared that
 

Re: What to use for usb transfer from gadget to host?

[Alan Stern]

On Mon, 31 Mar 2014 tzi...@me.com wrote:

  I am familiar with USB on the host side, but not the gadget side.
  What's the best/easiest way to implement a simple 2 endpoints
  communication with high data rates?
  During my search I came across functionfs, gadgetfs, configfs and
  libusbg. Can you recommend one of them that suits my needs?
  Thank you so much!
 
 Can anybody help out here?
 Thanks!

I can't tell you much about the differences between these APIs.  The 
only one I have ever used is gadgetfs.

The one thing to keep in mind is that in order to achieve maximum
throughput, you definitely need to use an asynchronous API.

Alan Stern

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

Re: [PATCH] USB:pl2303: add ids for Hewlett-Packard HP POS pole displays

[Johan Hovold]

   I don't know why diff deletes:
-#define HP_VENDOR_ID0x03f0
-#define HP_LD220_PRODUCT_ID 0x3524
  
   and then adds them again.  I didn't touch those lines.  I suspect that
   it is due to the comment update above them.
  
  Well, you or your editor did add that extra space at the beginning of those
  lines (which git-diff reports).
  
  Your original diff was correct (although not generated from the root).
  Simply commit it to a git tree and run git format-patch and all should be 
  good.
 
 In the original submission I did not change the comment about the pole
 display.  I noticed in a revision that comment referred to only one of
 the poles.  I tried committing the change and comparing back to the
 tag, but I get it still removes the lines and adds them again.

That's right. The comment is wrong (the extra '/') and perhaps your
editor is insisting on the leading space (which causes the lines to
appear to be removed and added back again).

I can just fix this up here this time.

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

[PATCH] USB: pl2303: add ids for Hewlett-Packard HP POS pole displays

[Sanders, Aaron]

Add device ids to pl2303 for the Hewlett-Packard HP POS pole displays:
LD960: 03f0:0B39
LCM220: 03f0:3139
LCM960: 03f0:3239 

Signed-off-by: Aaron Sanders aaron.sand...@hp.com

diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 3b5ba4f..4d70809 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -82,6 +82,9 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(YCCABLE_VENDOR_ID, YCCABLE_PRODUCT_ID) },
{ USB_DEVICE(SUPERIAL_VENDOR_ID, SUPERIAL_PRODUCT_ID) },
{ USB_DEVICE(HP_VENDOR_ID, HP_LD220_PRODUCT_ID) },
+   { USB_DEVICE(HP_VENDOR_ID, HP_LD960_PRODUCT_ID) },
+   { USB_DEVICE(HP_VENDOR_ID, HP_LCM220_PRODUCT_ID) },
+   { USB_DEVICE(HP_VENDOR_ID, HP_LCM960_PRODUCT_ID) },
{ USB_DEVICE(CRESSI_VENDOR_ID, CRESSI_EDY_PRODUCT_ID) },
{ USB_DEVICE(ZEAGLE_VENDOR_ID, ZEAGLE_N2ITION3_PRODUCT_ID) },
{ USB_DEVICE(SONY_VENDOR_ID, SONY_QN3USB_PRODUCT_ID) },
diff --git a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h
index c38b8c0..0e4df59 100644
--- a/drivers/usb/serial/pl2303.h
+++ b/drivers/usb/serial/pl2303.h
@@ -121,9 +121,12 @@
 #define SUPERIAL_VENDOR_ID 0x5372
 #define SUPERIAL_PRODUCT_ID0x2303
 
-/* Hewlett-Packard LD220-HP POS Pole Display */
-#define HP_VENDOR_ID   0x03f0
-#define HP_LD220_PRODUCT_ID0x3524
+/* Hewlett-Packard POS Pole Displays */
+ #define HP_VENDOR_ID  0x03f0
+ #define HP_LD220_PRODUCT_ID   0x3524
+ #define HP_LD960_PRODUCT_ID   0x0B39
+ #define HP_LCM220_PRODUCT_ID  0x3139
+ #define HP_LCM960_PRODUCT_ID  0x3239
 
 /* Cressi Edy (diving computer) PC interface */
 #define CRESSI_VENDOR_ID   0x04b8
--
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: pl2303: add ids for Hewlett-Packard HP POS pole displays

[Johan Hovold]

On Mon, Mar 31, 2014 at 01:40:46PM +, Sanders, Aaron wrote:
 Add device ids to pl2303 for the Hewlett-Packard HP POS pole displays:
 LD960: 03f0:0B39
 LCM220: 03f0:3139
 LCM960: 03f0:3239 
 
 Signed-off-by: Aaron Sanders aaron.sand...@hp.com
 
 diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
 index 3b5ba4f..4d70809 100644
 --- a/drivers/usb/serial/pl2303.c
 +++ b/drivers/usb/serial/pl2303.c
 @@ -82,6 +82,9 @@ static const struct usb_device_id id_table[] = {
   { USB_DEVICE(YCCABLE_VENDOR_ID, YCCABLE_PRODUCT_ID) },
   { USB_DEVICE(SUPERIAL_VENDOR_ID, SUPERIAL_PRODUCT_ID) },
   { USB_DEVICE(HP_VENDOR_ID, HP_LD220_PRODUCT_ID) },
 + { USB_DEVICE(HP_VENDOR_ID, HP_LD960_PRODUCT_ID) },
 + { USB_DEVICE(HP_VENDOR_ID, HP_LCM220_PRODUCT_ID) },
 + { USB_DEVICE(HP_VENDOR_ID, HP_LCM960_PRODUCT_ID) },
   { USB_DEVICE(CRESSI_VENDOR_ID, CRESSI_EDY_PRODUCT_ID) },
   { USB_DEVICE(ZEAGLE_VENDOR_ID, ZEAGLE_N2ITION3_PRODUCT_ID) },
   { USB_DEVICE(SONY_VENDOR_ID, SONY_QN3USB_PRODUCT_ID) },
 diff --git a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h
 index c38b8c0..0e4df59 100644
 --- a/drivers/usb/serial/pl2303.h
 +++ b/drivers/usb/serial/pl2303.h
 @@ -121,9 +121,12 @@
  #define SUPERIAL_VENDOR_ID   0x5372
  #define SUPERIAL_PRODUCT_ID  0x2303
  
 -/* Hewlett-Packard LD220-HP POS Pole Display */
 -#define HP_VENDOR_ID 0x03f0
 -#define HP_LD220_PRODUCT_ID  0x3524
 +/* Hewlett-Packard POS Pole Displays */
 + #define HP_VENDOR_ID0x03f0
 + #define HP_LD220_PRODUCT_ID 0x3524
 + #define HP_LD960_PRODUCT_ID 0x0B39
 + #define HP_LCM220_PRODUCT_ID0x3139
 + #define HP_LCM960_PRODUCT_ID0x3239

Please fix you editor before submitting the same broken patch over and
over.

Your patch adds leading spaces which should not be there.

Johan

  
  /* Cressi Edy (diving computer) PC interface */
  #define CRESSI_VENDOR_ID 0x04b8
--
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: pl2303: add ids for Hewlett-Packard HP POS pole displays

[Johan Hovold]

From: Aaron Sanders aaron.sand...@hp.com

Add device ids to pl2303 for the Hewlett-Packard HP POS pole displays:

LD960: 03f0:0B39
LCM220: 03f0:3139
LCM960: 03f0:3239

[ Johan: fix indentation and sort PIDs numerically ]

Signed-off-by: Aaron Sanders aaron.sand...@hp.com
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
 drivers/usb/serial/pl2303.c | 3 +++
 drivers/usb/serial/pl2303.h | 5 -
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 2e22fc22c382..b3d5a35c0d4b 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -83,6 +83,9 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(YCCABLE_VENDOR_ID, YCCABLE_PRODUCT_ID) },
{ USB_DEVICE(SUPERIAL_VENDOR_ID, SUPERIAL_PRODUCT_ID) },
{ USB_DEVICE(HP_VENDOR_ID, HP_LD220_PRODUCT_ID) },
+   { USB_DEVICE(HP_VENDOR_ID, HP_LD960_PRODUCT_ID) },
+   { USB_DEVICE(HP_VENDOR_ID, HP_LCM220_PRODUCT_ID) },
+   { USB_DEVICE(HP_VENDOR_ID, HP_LCM960_PRODUCT_ID) },
{ USB_DEVICE(CRESSI_VENDOR_ID, CRESSI_EDY_PRODUCT_ID) },
{ USB_DEVICE(ZEAGLE_VENDOR_ID, ZEAGLE_N2ITION3_PRODUCT_ID) },
{ USB_DEVICE(SONY_VENDOR_ID, SONY_QN3USB_PRODUCT_ID) },
diff --git a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h
index c38b8c00c06f..42bc082896ac 100644
--- a/drivers/usb/serial/pl2303.h
+++ b/drivers/usb/serial/pl2303.h
@@ -121,8 +121,11 @@
 #define SUPERIAL_VENDOR_ID 0x5372
 #define SUPERIAL_PRODUCT_ID0x2303
 
-/* Hewlett-Packard LD220-HP POS Pole Display */
+/* Hewlett-Packard POS Pole Displays */
 #define HP_VENDOR_ID   0x03f0
+#define HP_LD960_PRODUCT_ID0x0b39
+#define HP_LCM220_PRODUCT_ID   0x3139
+#define HP_LCM960_PRODUCT_ID   0x3239
 #define HP_LD220_PRODUCT_ID0x3524
 
 /* Cressi Edy (diving computer) PC interface */
-- 
1.8.3.2

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

Re: [PATCH] USB: pl2303: add ids for Hewlett-Packard HP POS pole displays

[Johan Hovold]

On Mon, Mar 31, 2014 at 02:03:02PM +, Sanders, Aaron wrote:
  From: Aaron Sanders aaron.sand...@hp.com
  
  Add device ids to pl2303 for the Hewlett-Packard HP POS pole displays:
  
  LD960: 03f0:0B39
  LCM220: 03f0:3139
  LCM960: 03f0:3239
  
  [ Johan: fix indentation and sort PIDs numerically ]
 
 Thank you.  Next time I submit I will make sure that I will use simple
 text editor and git send-email.

Sounds good. Remember to run you patch through checkpatch.pl as well.

Thanks for the patch!

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

Re: [PATCH 0/3] Fix USB deadlock caused by SCSI error handling

[Hannes Reinecke]

On 03/31/2014 03:33 PM, Alan Stern wrote:
 On Mon, 31 Mar 2014, Hannes Reinecke wrote:
 
 On 03/28/2014 08:29 PM, Alan Stern wrote:
 On Fri, 28 Mar 2014, James Bottomley wrote:

 This is a set of three patches we agreed to a while ago to eliminate a
 USB deadlock.  I did rewrite the first patch, if it could be reviewed
 and tested.

 I tested all three patches under the same conditions as before, and 
 they all worked correctly.

 In the revised patch 1, the meaning of SCSI_EH_ABORT_SCHEDULED isn't
 entirely clear.  This boils down to two questions, which I don't 
 know the answers to:

 What should happen in scmd_eh_abort_handler() if
 scsi_host_eh_past_deadline() returns true and thereby
 prevents scsi_try_to_abort_cmd() from being called?
 The flag wouldn't get cleared then.

 Ah. Correct. But that's due to the first patch being incorrect.
 Cf my response to the original first patch.
 
 See my response to your response.  :-)
 
Okay, So I probably should refrain from issueing a response to
your response to my response lest infinite recursion happens :-)

 What should happen if some other pathway manages to call
 scsi_try_to_abort_cmd() while scmd-abort_work is still
 sitting on the work queue?  The command would be aborted
 and the flag would be cleared, but the queued work would
 remain.  Can this ever happen?

 Not that I could see.
 A command abort is only ever triggered by the request timeout from
 the block layer. And the timer is _not_ rearmed once the timeout
 function (here: scsi_times_out()) is called.
 Hence I fail to see how it can be called concurrently.
 
 scsi_try_to_abort_cmd() is also called (via a different pathway) when a 
 command sent by the error handler itself times out.  I haven't traced 
 through all the different paths to make sure none of them can run 
 concurrently.  But I'm willing to take your word for it.
 
Yes, but that's not calling scsi_abort_command(), but rather invokes
scsi_abort_eh_cmnd().

 Maybe scmd_eh_abort_handler() should check the flag before doing
 anything.  Is there any sort of sychronization to prevent the same
 incarnation of a command from being aborted twice (or by two different
 threads at the same time)?  If there is, it isn't obvious.

 See above. scsi_times_out() will only ever called once.
 What can happen, though, is that _theoretically_ the LLDD might
 decide to call -done() on a timed out command when
 scsi_eh_abort_handler() is still pending.
 
 That's okay.  We can expect the LLDD to have sufficient locking to
 handle that sort of thing without confusion (usb-storage does, for
 example).
 
 (Also, what's going on at the start of scsi_abort_command()?  Contrary
 to what one might expect, the first part of the function _cancels_ a
 scheduled abort.  And it does so without clearing the
 SCSI_EH_ABORT_SCHEDULED flag.)

 The original idea was this:

 SCSI_EH_ABORT_SCHEDULED is sticky _per command_.
 Point is, any command abort is only ever send for a timed-out
 command. And the main problem for a timed-out command is that we
 simply _do not_ know what happened for that command. So _if_ a
 command timed out, _and_ we've send an abort, _and_ the command
 times out _again_ we'll be running into an endless loop between
 timeout and aborting, and never returning the command at all.

 So to prevent this we should set a marker on that command telling it
 to _not_ try to abort the command again.
 
 I disagree.  We _have_ to abort the command again -- how else can we
 stop a running command?  To prevent the loop you described, we should
 avoid _retrying_ the command after it is aborted the second time.
 
The actual question is whether it's worth aborting the same command
a second time.
In principle any reset (like LUN reset etc) should clear the
command, too.
And the EH abort functionality is geared around this.
If, for some reason, the transport layer / device driver
requires a command abort to be send then sure, we need
to accommodate for that.

 Which is what 'SCSI_EH_ABORT_SCHEDULED' was meant for:

 - A command times out, sets 'SCSI_EH_ABORT_SCHEDULED'
 - abort _succeeds_
 - The same command times out a second time, notifies
   that SCSI_EH_ABORT_SCHEDULED is set, and doesn't call
   scsi_eh_abort_command() but rather escalates directly.
 
 The proper time to escalate is after the command is aborted again, not
 while the command is still running.  The only situation where you might
 want to escalate while a command is still running would be if you were
 unable to abort the command.
 
 (Hmmm, maybe that's not true for SCSI devices in general.  It is true 
 for USB mass-storage, however.  Perhaps the reset handlers in 
 usb-storage should be changed so that they will automatically abort a 
 running command before starting the reset.)
 
As said, yes, in principle you are right. We should be aborting the
command a second time, _and then_ starting the escalation.

So if the above reasoning is okay then this patch should 

Re: BUG: Kernel Panic: skb_over_panic with am335 - musb - ax88760

[Felipe Balbi]

Hi,

(please always keep linux-usb@vger.kernel.org in cc)

On Mon, Mar 31, 2014 at 11:05:23AM +0200, Iktek wrote:
 i’m not very familiar with reporting Bugs, this is my first Try, so please
 be indulgent to me, when I do something wrong. 
 
 I hope, I’m thinking on all Information you need and I have the right
 person.
 
  
 
 I don’t really know if the problem is sourced on musb or the ASIX driver. 
 
 The error is reproducible every time I start the system over NFS and I have
 the possibility to debug into the kernel within KGDB, but at this moment I
 don’t know the structure of musb networking, so I don’t know where to start
 debugging.
 
  
 
 Could you please give me a fast answer, if I’m right on this way telling you

if you want dedicated support you shouldn't be depending on a mailing
list giving you *free* advice.

 the bug or if I should try something else and provide more information.
 
 I really need this working driver for a very time-critical project of one of
 my customers and I’m willing to work on a fix if you tell me how.

what is your customer doing and why can't s/he use the internal ethernet
controller from AM335x ? There are two CPSW ports in that device.

 I have the following Problem:
 
 When booting the Linux Kernel with the following constellation:
 
  
 
 AM335 -MUSB - AX88760 over NFS
 
  
 
 I get the following Output:
 
  
 
 [0.00] Booting Linux on physical CPU 0x0
 
 [0.00] Initializing cgroup subsys cpuset
 
 [0.00] Initializing cgroup subsys cpu
 
 [0.00] Initializing cgroup subsys cpuacct
 
 [0.00] Linux version 3.14.0-rc7+ (root@ThinkPad) (gcc version 4.7.3
 (Buildroot 2013.11) ) #19 Sun Mar 30 18:55:05 CEST 2014
 
 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
 cr=10c5387d
 
 [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
 instruction cache
 
 [0.00] Machine model: TI AM335x BeagleBone
 
 [0.00] cma: CMA: reserved 16 MiB at 9f00
 
 [0.00] Memory policy: Data cache writeback
 
 [0.00] CPU: All CPU(s) started in SVC mode.
 
 [0.00] AM335X ES2.0 (sgx neon )
 
 [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total
 pages: 130048
 
 [0.00] Kernel command line: console=ttyO0,115200n8 root=/dev/nfs rw
 nfsroot=192.168.30.235:/srv/root nolock rsize=4096 wsize=4096
 ip=192.168.30.236:192.168.30.235:192.168.30.2:255.255.255.0:Xenon:eth1:off
 kgdbwait kgdboc=ttyO0,115200
 
 [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
 
 [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144
 bytes)
 
 [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072
 bytes)
 
 [0.00] allocated 1048576 bytes of page_cgroup
 
 [0.00] please try 'cgroup_disable=memory' option if you don't want
 memory cgroups
 
 [0.00] Memory: 493272K/524288K available (6076K kernel code, 391K
 rwdata, 1832K rodata, 191K init, 422K bss, 31016K reserved, 0K highmem)
 
 [0.00] Virtual kernel memory layout:
 
 [0.00] vector  : 0x - 0x1000   (   4 kB)
 
 [0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
 
 [0.00] vmalloc : 0xe080 - 0xff00   ( 488 MB)
 
 [0.00] lowmem  : 0xc000 - 0xe000   ( 512 MB)
 
 [0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
 
 [0.00]   .text : 0xc0008000 - 0xc07c14ac   (7910 kB)
 
 [0.00]   .init : 0xc07c2000 - 0xc07f1d24   ( 192 kB)
 
 [0.00]   .data : 0xc07f2000 - 0xc0853e60   ( 392 kB)
 
 [0.00].bss : 0xc0853e60 - 0xc08bd878   ( 423 kB)
 
 [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
 
 [0.00] NR_IRQS:16 nr_irqs:16 16
 
 [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128
 interrupts
 
 [0.00] Total of 128 interrupts on 1 active controller
 
 [0.00] OMAP clockevent source: timer2 at 2400 Hz
 
 [0.09] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
 178956969942ns
 
 [0.26] OMAP clocksource: timer1 at 2400 Hz
 
 [0.000200] Console: colour dummy device 80x30
 
 [0.000226] Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736)
 
 [0.089555] pid_max: default: 32768 minimum: 301
 
 [0.089684] Mount-cache hash table entries: 512
 
 [0.095009] Initializing cgroup subsys memory
 
 [0.095051] Initializing cgroup subsys devices
 
 [0.095061] Initializing cgroup subsys freezer
 
 [0.095069] Initializing cgroup subsys blkio
 
 [0.095076] Initializing cgroup subsys perf_event
 
 [0.095163] CPU: Testing write buffer coherency: ok
 
 [0.095499] Setting up static identity map for 0x805bdbb0 - 0x805bdc08
 
 [0.096401] devtmpfs: initialized
 
 [0.098173] VFP support v0.3: implementor 41 architecture 3 part 30
 variant c rev 3
 
 [0.103513] omap_hwmod: tptc0 using broken 

Re: [PATCH 0/3] Fix USB deadlock caused by SCSI error handling

[James Bottomley]

[lets split the thread]
On Mon, 2014-03-31 at 16:37 +0200, Hannes Reinecke wrote:
 On 03/31/2014 03:33 PM, Alan Stern wrote:
  On Mon, 31 Mar 2014, Hannes Reinecke wrote:
  On 03/28/2014 08:29 PM, Alan Stern wrote:
  On Fri, 28 Mar 2014, James Bottomley wrote:
  Maybe scmd_eh_abort_handler() should check the flag before doing
  anything.  Is there any sort of sychronization to prevent the same
  incarnation of a command from being aborted twice (or by two different
  threads at the same time)?  If there is, it isn't obvious.
 
  See above. scsi_times_out() will only ever called once.
  What can happen, though, is that _theoretically_ the LLDD might
  decide to call -done() on a timed out command when
  scsi_eh_abort_handler() is still pending.
  
  That's okay.  We can expect the LLDD to have sufficient locking to
  handle that sort of thing without confusion (usb-storage does, for
  example).
  
  (Also, what's going on at the start of scsi_abort_command()?  Contrary
  to what one might expect, the first part of the function _cancels_ a
  scheduled abort.  And it does so without clearing the
  SCSI_EH_ABORT_SCHEDULED flag.)
 
  The original idea was this:
 
  SCSI_EH_ABORT_SCHEDULED is sticky _per command_.
  Point is, any command abort is only ever send for a timed-out
  command. And the main problem for a timed-out command is that we
  simply _do not_ know what happened for that command. So _if_ a
  command timed out, _and_ we've send an abort, _and_ the command
  times out _again_ we'll be running into an endless loop between
  timeout and aborting, and never returning the command at all.
 
  So to prevent this we should set a marker on that command telling it
  to _not_ try to abort the command again.
  
  I disagree.  We _have_ to abort the command again -- how else can we
  stop a running command?  To prevent the loop you described, we should
  avoid _retrying_ the command after it is aborted the second time.
  
 The actual question is whether it's worth aborting the same command
 a second time.
 In principle any reset (like LUN reset etc) should clear the
 command, too.
 And the EH abort functionality is geared around this.
 If, for some reason, the transport layer / device driver
 requires a command abort to be send then sure, we need
 to accommodate for that.

We already discussed this (that was my first response too).  USB needs
all outstanding commands aborted before proceeding to reset.  I'm
starting to think the actual way to fix this is to reset the abort
scheduled only if we send something else, so this might be a better fix.

It doesn't matter if we finish a command with abort scheduled because
the command then gets freed and the flags cleaned.

We can take our time with this because the other two patches, which I
can send separately fix the current deadlock (we no longer send an
unaborted request sense before the reset), and it can go via rc fixes.

James

---

diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 771c16b..3cfd2bf 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -1007,6 +1007,12 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, 
unsigned char *cmnd,
const unsigned long stall_for = msecs_to_jiffies(100);
int rtn;
 
+   /*
+* We're sending another command we'll need to abort, so reset the
+* abort scheduled flag on the real command before we save its state
+*/
+   scmd-eh_eflags = ~SCSI_EH_ABORT_SCHEDULED;
+
 retry:
scsi_eh_prep_cmnd(scmd, ses, cmnd, cmnd_size, sense_bytes);
shost-eh_action = done;


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

USB 3.0 not working

[Carlos]

Hello,

Could you help me to make my usb 3.0 hdd work in Ubuntu 14? I've being
googling for days and I don't knwo what more to do. These are messages I'm
getting when I plug in the disk:

@ dmesg
[41440.463091] xhci_hcd :03:00.0: Stopped the command ring failed, maybe
the host is dead
[41440.463106] xhci_hcd :03:00.0: Abort command ring failed
[41440.463369] xhci_hcd :03:00.0: HC died; cleaning up
[41441.806293] NVRM: os_schedule: Attempted to yield the CPU while in atomic
or interrupt context
[41445.672992] xhci_hcd :03:00.0: Timeout while waiting for address
device command
[41445.673006] xhci_hcd :03:00.0: Abort the command ring, but the xHCI
is dead.
[41445.877137] usb 6-3: device not accepting address 2, error -108

@ lsusb -vv| more
Couldn't open device, some information will be missing
Couldn't open device, some information will be missing
Couldn't open device, some information will be missing
Couldn't open device, some information will be missing
Couldn't open device, some information will be missing
Couldn't open device, some information will be missing

Couldn't open device, some information will be missing
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Device Descriptor:
Couldn't open device, some information will be missing
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 3 
  bMaxPacketSize0 9
  idVendor   0x1d6b Linux Foundation
  idProduct  0x0003 3.0 root hub
  bcdDevice3.13
  iManufacturer   3 
  iProduct2 
  iSerial 1 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   31
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0004  1x 4 bytes
bInterval  12
bMaxBurst   0

My kernel:
 uname -r
3.13.0-19-generic

Please help, thank you so much,
Carlos

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

Re: USB 3.0 not working

[Greg KH]

On Mon, Mar 31, 2014 at 05:20:17PM +, Carlos wrote:
 Hello,
 
 Could you help me to make my usb 3.0 hdd work in Ubuntu 14?

If you have issues with a specific distro, it's best to ask them for
support, as they are almost always using a kernel that is not a
kernel.org release.

Best of luck,

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: Discussion: Link Layer Test implementation strategy for Linux Embedded Host

[Greg KH]

On Mon, Mar 31, 2014 at 05:14:31PM +0530, Pratyush Anand wrote:
 Hi Alan/Greg,
 
 I was starting some work for running Lecroy USB Compliance Suite Link
 Layer Tests with embedded xhci host, which runs Linux. I thought, its
 wise to discuss my test strategy before I start implementing it,
 as in long run I would like to push them to mainline.
 
 These tests have been defined in USB 3.0 Link Layer Test
 Specification.
 
 For a xhci host's downstream port under test (PUT), Lecroy excersizer with 
 USB Compliance Suite acts as Link Validation System (LVS).
 
 Most of the link layer tests only expects link to be in U0. If a host
 sends a setup packet, it is NAKed by LVS. However, there are some
 tests which ask host to send some control command like Get Descriptor
 etc.
 
 To add support of these tests, I wanted to go as under:
 
 1. Add a quirk flag for the root hub sysfs device node to prevent enumeration
of a device.
 2. Before a lecroy LVS device is connected to the root hub n, do something 
 like
 this.
 echo 1   /sys/bus/usb/devices/usbn/avoid_enum_quirk
 3. Now connect LVS device and run Link Layer tests from Lecroy USB
 Compliance Suite.
 4. To get back into normal working situation (to connect a general usb device
 to root hub n), do following:
 echo 0   /sys/bus/usb/devices/usbn/avoid_enum_quirk
 5. Modify hub driver to prevent enumeration when a new device is connected 
 and 
 this flag is set.
  Create a new dummy device (VID, PID to be discussed with 
 ssusbcomplia...@usb.org),
 and call its driver (say lvstestdev). (Is there a way to call use
 driver on the basis of name only?)
 This lvstestdev implements further sys nodes/or some other
 method like ioctl etc to allow an application to generate traffic
 for some specific test case.
 6. When this device is disconnected then the created dummy device is
 destroyed. (Even a single test case may generate multiple
 connection/disconnection from LVS)
 
 Do, you think this flow would be correct, or there could be some
 better approach?

I don't know, try it out and let us see how it works.

best of luck,

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: Missing functionfs module parameters in /sys/module/g_ffs/parameters/

[Greg KH]

On Mon, Mar 31, 2014 at 11:36:10AM +0200, tzi...@me.com wrote:
 Hello!
 I am on a phyFLEX-i.MX 6 running kernel 3.0.35.

That's _really_ old and unsupported.  Any chance you can use a kernel
that the community can actually help you out with (i.e. 3.14?)

If you are stuck at an old kernel release, please get support from the
vendor that provides you with that kernel.

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: USB 3.0 Isochronous audio

[Greg KH]

On Mon, Mar 31, 2014 at 08:44:00AM +0200, Russel Hughes wrote:
 Hi,
 
 Does anyone know when isochronous audio will be implemented for
 USB 3.0 in Linux?

What specific specification are you referring to that we do not already
support?

I can use a USB audio device just fine with a USB 3.0 host at the
moment, what exact driver are you having problems with?

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: USB 3.0 Isochronous audio

[Russel Hughes]

Hi,

 Thanks for replying.  I can use a some USB audio devices, ones based
around the Ti PCM2704 are fine, the DAC I want to use is called an
audiolab MDAC and as I said it has an elasticity buffer, this sits at
50% full and is rock solid, as it should do, on USB 2.0 devices under
Ubuntu 12.04 LTS fully patched ASRock 330 but not on the 12.04 LTS
fully patched Intel NUC, where it reaches a maximum of 20% is highly
erratic and drops out from time to time. The lsmod output is as
follows:


snd_usb_audio 146849  1
snd_usbmidi_lib29477  1 snd_usb_audio
hid_generic12540  0
snd_hda_codec_realtek80192  1
snd_hda_codec_hdmi 37463  1
coretemp   13596  0
kvm_intel 137928  0
kvm   452238  1 kvm_intel
ghash_clmulni_intel13259  0
aesni_intel55495  0
ablk_helper13597  1 aesni_intel
cryptd 20530  3 ghash_clmulni_intel,aesni_intel,ablk_helper
lrw13323  1 aesni_intel
aes_x86_64 17255  1 aesni_intel
xts12951  1 aesni_intel
gf128mul   14951  2 lrw,xts
snd_hda_intel  44339  5
snd_hda_codec 141761  3
snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel
snd_hwdep  13668  2 snd_usb_audio,snd_hda_codec
microcode  23075  0
snd_pcm   102477  4
snd_usb_audio,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_seq_midi   13324  0
snd_rawmidi30417  2 snd_usbmidi_lib,snd_seq_midi
snd_seq_midi_event 14899  1 snd_seq_midi
snd_seq61930  2 snd_seq_midi,snd_seq_midi_event
joydev 17613  0
rfcomm 47922  0
snd_timer  29989  2 snd_pcm,snd_seq
snd_seq_device 14497  3 snd_seq_midi,snd_rawmidi,snd_seq
bnep   18399  2
bluetooth 247324  10 rfcomm,bnep
nuvoton_cir17980  0
rc_core26422  1 nuvoton_cir
parport_pc 28284  1
ppdev  17113  0
i915  621562  3
snd69533  24
snd_usb_audio,snd_usbmidi_lib,snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
drm_kms_helper 49597  1 i915
mac_hid13253  0
drm   287796  4 i915,drm_kms_helper
i2c_algo_bit   13564  1 i915
lpc_ich17144  0
video  19652  1 i915
soundcore  12680  1 snd
snd_page_alloc 18798  2 snd_hda_intel,snd_pcm
mei45974  0
binfmt_misc17540  1
lp 17799  0
parport46562  3 parport_pc,ppdev,lp
hid_logitech   26634  0
ff_memless 13097  1 hid_logitech
usbhid 47346  1 hid_logitech
hid   105826  3 hid_generic,hid_logitech,usbhid
ahci   25879  2
libahci31636  1 ahci
e1000e202746  0



On 31 March 2014 22:02, Greg KH g...@kroah.com wrote:
 On Mon, Mar 31, 2014 at 08:44:00AM +0200, Russel Hughes wrote:
 Hi,

 Does anyone know when isochronous audio will be implemented for
 USB 3.0 in Linux?

 What specific specification are you referring to that we do not already
 support?

 I can use a USB audio device just fine with a USB 3.0 host at the
 moment, what exact driver are you having problems with?

 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: USB 3.0 Isochronous audio

[Felipe Balbi]

On Mon, Mar 31, 2014 at 10:17:20PM +0200, Russel Hughes wrote:
 Hi,
 
  Thanks for replying.  I can use a some USB audio devices, ones based
 around the Ti PCM2704 are fine, the DAC I want to use is called an
 audiolab MDAC and as I said it has an elasticity buffer, this sits at
 50% full and is rock solid, as it should do, on USB 2.0 devices under
 Ubuntu 12.04 LTS fully patched ASRock 330 but not on the 12.04 LTS
 fully patched Intel NUC, where it reaches a maximum of 20% is highly
 erratic and drops out from time to time. The lsmod output is as

you need to grab information of the error. lsusb alone doesn't provide a
lot of information (unless someone has dealt with the same error in a
NUC).

Can you describe the actual problem ? How can you trigger it ? What are
you doing when the problem arises ? Do you hear audio glitches or does
the device disconnect ? Do you have a crash ? Does the *same* device
work on other setups ?

Try to capture a usbmon trace of the failure, that's likely to help.

-- 
balbi


signature.asc
Description: Digital signature

Re: USB 3.0 Isochronous audio

[Greg KH]

On Mon, Mar 31, 2014 at 10:17:20PM +0200, Russel Hughes wrote:
 Hi,
 
  Thanks for replying.  I can use a some USB audio devices, ones based
 around the Ti PCM2704 are fine, the DAC I want to use is called an
 audiolab MDAC and as I said it has an elasticity buffer, this sits at
 50% full and is rock solid, as it should do, on USB 2.0 devices under
 Ubuntu 12.04 LTS fully patched ASRock 330 but not on the 12.04 LTS
 fully patched Intel NUC, where it reaches a maximum of 20% is highly
 erratic and drops out from time to time. The lsmod output is as
 follows:

I have no idea what kernel release Ubuntu is using, but I suggest, if
you have issues with that specific kernel, filing a bug with Ubuntu.
Otherwise, if you can run a kernel.org release, can you please try 3.14
and see if that changes anything or not?

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: USB 3.0 Isochronous audio

[Russel Hughes]

Playing any audio via spotify, youtube, BBC iplayer, XBMC causes the
problem. The problem is the audio glitches, its never crashed, as I
said the same device works flawlessly on a USB2.0 device amd has done
for about two years. Even with no music playing the buffer level
changes, the problem. I have seen this  which is interesting
https://forums.presonus.com/posts/list/33427.page   I will try and get
usbmon working tomorrow but it seems its a known Intel issue, I dont
know if you can manage a software workaround.

Errata
1. USB Isoch In Transfer Error Issue

Problem: If a USB full-speed inbound isochronous transaction with a
packet length 190 bytes or
greater is started near the end of a microframe the PCH may see more
than 189 bytes
in the next microframe.

Implication: If the PCH sees more than 189 bytes for a microframe an
error will be sent to software
and the isochronous transfer will be lost. If a single data packet is
lost no perceptible
impact for the end user is expected.

Note: Intel has only observed the issue in a synthetic test
environment where precise control
of packet scheduling is available, and has not observed this failure
in its compatibility
validation testing.

* Isochronous traffic is periodic and cannot be retried thus it is
considered good
practice for software to schedule isochronous transactions to start at
the beginning
of a microframe. Known software solutions follow this practice.
* To sensitize the system to the issue additional traffic such as
other isochronous
transactions or retries of asynchronous transactions would be required
to push the
inbound isochronous transaction to the end of the microframe.

Workaround: None.
Status: No Plan to Fix.

On 31 March 2014 22:32, Felipe Balbi ba...@ti.com wrote:
 On Mon, Mar 31, 2014 at 10:17:20PM +0200, Russel Hughes wrote:
 Hi,

  Thanks for replying.  I can use a some USB audio devices, ones based
 around the Ti PCM2704 are fine, the DAC I want to use is called an
 audiolab MDAC and as I said it has an elasticity buffer, this sits at
 50% full and is rock solid, as it should do, on USB 2.0 devices under
 Ubuntu 12.04 LTS fully patched ASRock 330 but not on the 12.04 LTS
 fully patched Intel NUC, where it reaches a maximum of 20% is highly
 erratic and drops out from time to time. The lsmod output is as

 you need to grab information of the error. lsusb alone doesn't provide a
 lot of information (unless someone has dealt with the same error in a
 NUC).

 Can you describe the actual problem ? How can you trigger it ? What are
 you doing when the problem arises ? Do you hear audio glitches or does
 the device disconnect ? Do you have a crash ? Does the *same* device
 work on other setups ?

 Try to capture a usbmon trace of the failure, that's likely to help.

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

Re: USB 3.0 Isochronous audio

[Russel Hughes]

OK sure. I guess there are plenty guides on how to do it out there but
if you have one you can recommend it would be good. Its not a disaster
if the system gets trashed but it would be nice if it didnt, I did ask
on Ubuntu forums but no one replied, thats why I am here!.

Thanks

Russel

On 31 March 2014 23:00, Greg KH g...@kroah.com wrote:
 On Mon, Mar 31, 2014 at 10:17:20PM +0200, Russel Hughes wrote:
 Hi,

  Thanks for replying.  I can use a some USB audio devices, ones based
 around the Ti PCM2704 are fine, the DAC I want to use is called an
 audiolab MDAC and as I said it has an elasticity buffer, this sits at
 50% full and is rock solid, as it should do, on USB 2.0 devices under
 Ubuntu 12.04 LTS fully patched ASRock 330 but not on the 12.04 LTS
 fully patched Intel NUC, where it reaches a maximum of 20% is highly
 erratic and drops out from time to time. The lsmod output is as
 follows:

 I have no idea what kernel release Ubuntu is using, but I suggest, if
 you have issues with that specific kernel, filing a bug with Ubuntu.
 Otherwise, if you can run a kernel.org release, can you please try 3.14
 and see if that changes anything or not?

 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: USB 3.0 Isochronous audio

[Felipe Balbi]

Hi,

(please don't top-post)

On Mon, Mar 31, 2014 at 11:08:58PM +0200, Russel Hughes wrote:
 Playing any audio via spotify, youtube, BBC iplayer, XBMC causes the
 problem. The problem is the audio glitches, its never crashed, as I
 said the same device works flawlessly on a USB2.0 device amd has done
 for about two years. Even with no music playing the buffer level
 changes, the problem. I have seen this  which is interesting
 https://forums.presonus.com/posts/list/33427.page   I will try and get
 usbmon working tomorrow but it seems its a known Intel issue, I dont

you really ought to use a kernel.org released kernel. v3.14 vanilla will
be the best, as Greg suggested.

 know if you can manage a software workaround.

more of a generic xhci limitation.

Matthias, do you know of any bugs/limitations WRT Isoch scheduling in
our current xhci driver ?

(keeping rest of message below for reference)

 Errata
 1. USB Isoch In Transfer Error Issue
 
 Problem: If a USB full-speed inbound isochronous transaction with a
 packet length 190 bytes or
 greater is started near the end of a microframe the PCH may see more
 than 189 bytes
 in the next microframe.
 
 Implication: If the PCH sees more than 189 bytes for a microframe an
 error will be sent to software
 and the isochronous transfer will be lost. If a single data packet is
 lost no perceptible
 impact for the end user is expected.
 
 Note: Intel has only observed the issue in a synthetic test
 environment where precise control
 of packet scheduling is available, and has not observed this failure
 in its compatibility
 validation testing.
 
 * Isochronous traffic is periodic and cannot be retried thus it is
 considered good
 practice for software to schedule isochronous transactions to start at
 the beginning
 of a microframe. Known software solutions follow this practice.
 * To sensitize the system to the issue additional traffic such as
 other isochronous
 transactions or retries of asynchronous transactions would be required
 to push the
 inbound isochronous transaction to the end of the microframe.
 
 Workaround: None.
 Status: No Plan to Fix.
 
 On 31 March 2014 22:32, Felipe Balbi ba...@ti.com wrote:
  On Mon, Mar 31, 2014 at 10:17:20PM +0200, Russel Hughes wrote:
  Hi,
 
   Thanks for replying.  I can use a some USB audio devices, ones based
  around the Ti PCM2704 are fine, the DAC I want to use is called an
  audiolab MDAC and as I said it has an elasticity buffer, this sits at
  50% full and is rock solid, as it should do, on USB 2.0 devices under
  Ubuntu 12.04 LTS fully patched ASRock 330 but not on the 12.04 LTS
  fully patched Intel NUC, where it reaches a maximum of 20% is highly
  erratic and drops out from time to time. The lsmod output is as
 
  you need to grab information of the error. lsusb alone doesn't provide a
  lot of information (unless someone has dealt with the same error in a
  NUC).
 
  Can you describe the actual problem ? How can you trigger it ? What are
  you doing when the problem arises ? Do you hear audio glitches or does
  the device disconnect ? Do you have a crash ? Does the *same* device
  work on other setups ?
 
  Try to capture a usbmon trace of the failure, that's likely to help.
 
  --
  balbi

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/9] pci-rcar-gen2: add devicetree support

[Sergei Shtylyov]

Hello.

On 03/30/2014 11:40 PM, Ben Dooks wrote:


Add OF match table for pci-rcar-gen2 driver for device tree support.

[...]



diff --git a/drivers/pci/host/pci-rcar-gen2.c
b/drivers/pci/host/pci-rcar-gen2.c
index fd3e3ab..1216784 100644
--- a/drivers/pci/host/pci-rcar-gen2.c
+++ b/drivers/pci/host/pci-rcar-gen2.c
@@ -16,6 +16,7 @@
  #include linux/kernel.h
  #include linux/module.h
  #include linux/pci.h
+#include linux/of_pci.h
  #include linux/platform_device.h
  #include linux/pm_runtime.h
  #include linux/sizes.h



Apologies all, there's a missing include of linux/of.h which should
have been added here



Have you ever re-posted this patch fixed? If not, it's not going to
be merged for 3.15 I guess...



I thought I did.



I don't see such repost in 'linux-sh'.



I can have a look a reposting it.



It doesn't apply to the current renesas.git devel branch. What tree
it was against?



 From my records it was against the -rc3 release of Horms' development
tree. I know Simon's tree has been closed for the board bits, but I
could re-send the rcar-pci code.


   Could you address my comments and re-send? Or if you don't have time, 
would you mind that I take this patch into my hands?


WBR, Sergei

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

Re: USB 3.0 Isochronous audio

[Greg KH]

A: No.
Q: Should I include quotations after my reply?


http://daringfireball.net/2007/07/on_top

On Mon, Mar 31, 2014 at 11:17:04PM +0200, Russel Hughes wrote:
 OK sure. I guess there are plenty guides on how to do it out there but
 if you have one you can recommend it would be good.

Do what?  Run a custom kernel?  There's a whole book out there that
describes how to do this called Linux Kernel in a Nutshell.  It's free
online if you want to just download it and use that.

Otherwise there are plenty of sites that should tell you how to build a
kernel and install it on Ubuntu, google is your friend...

good luck.

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

Re: [PATCH 5/9] ARM: shmbobile: r8a7790.dtsi: add pci0/1/2 nodes

[Sergei Shtylyov]

On 03/06/2014 09:01 PM, Ben Dooks wrote:

   s/shmbobile/shmobile/ in the subject.


Add nodes for USB PCI bridge devices.



Signed-off-by: Ben Dooks ben.do...@codethink.co.uk
Reviewed-by: Ian Molton ian.mol...@codethink.co.uk


WBR, Sergei

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

Re: [PATCH 0/3] Fix USB deadlock caused by SCSI error handling

[Alan Stern]

On Mon, 31 Mar 2014, Hannes Reinecke wrote:

  Ah. Correct. But that's due to the first patch being incorrect.
  Cf my response to the original first patch.
  
  See my response to your response.  :-)
  
 Okay, So I probably should refrain from issueing a response to
 your response to my response lest infinite recursion happens :-)

Indeed.

What should happen if some other pathway manages to call
scsi_try_to_abort_cmd() while scmd-abort_work is still
sitting on the work queue?  The command would be aborted
and the flag would be cleared, but the queued work would
remain.  Can this ever happen?
 
  Not that I could see.
  A command abort is only ever triggered by the request timeout from
  the block layer. And the timer is _not_ rearmed once the timeout
  function (here: scsi_times_out()) is called.
  Hence I fail to see how it can be called concurrently.
  
  scsi_try_to_abort_cmd() is also called (via a different pathway) when a 
  command sent by the error handler itself times out.  I haven't traced 
  through all the different paths to make sure none of them can run 
  concurrently.  But I'm willing to take your word for it.
  
 Yes, but that's not calling scsi_abort_command(), but rather invokes
 scsi_abort_eh_cmnd().

Sure.  But either way, we end up in scsi_try_to_abort_cmd(), which
calls the LLDD's abort handler.  Thus leading to the possibility of
aborting the same command more than once.

  The original idea was this:
 
  SCSI_EH_ABORT_SCHEDULED is sticky _per command_.
  Point is, any command abort is only ever send for a timed-out
  command. And the main problem for a timed-out command is that we
  simply _do not_ know what happened for that command. So _if_ a
  command timed out, _and_ we've send an abort, _and_ the command
  times out _again_ we'll be running into an endless loop between
  timeout and aborting, and never returning the command at all.
 
  So to prevent this we should set a marker on that command telling it
  to _not_ try to abort the command again.
  
  I disagree.  We _have_ to abort the command again -- how else can we
  stop a running command?  To prevent the loop you described, we should
  avoid _retrying_ the command after it is aborted the second time.
  
 The actual question is whether it's worth aborting the same command
 a second time.
 In principle any reset (like LUN reset etc) should clear the
 command, too.
 And the EH abort functionality is geared around this.
 If, for some reason, the transport layer / device driver
 requires a command abort to be send then sure, we need
 to accommodate for that.

As James mentioned, with USB a reset does not abort a running command.  
Instead it waits for the command to finish.  (However, this could be
changed in usb-storage, if required.)

 As said, yes, in principle you are right. We should be aborting the
 command a second time, _and then_ starting the escalation.
 
 So if the above reasoning is okay then this patch should be doing
 the trick:
 
 diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
 index 771c16b..0e72374 100644
 --- a/drivers/scsi/scsi_error.c
 +++ b/drivers/scsi/scsi_error.c
 @@ -189,6 +189,7 @@ scsi_abort_command(struct scsi_cmnd *scmd)
 /*
  * Retry after abort failed, escalate to next level.
  */
 +   scmd-eh_eflags = ~SCSI_EH_ABORT_SCHEDULED;
 SCSI_LOG_ERROR_RECOVERY(3,
 scmd_printk(KERN_INFO, scmd,
 scmd %p previous abort
 failed\n, scmd));
 
 (Beware of line
 breaks)
 
 Can you test with it?

I don't understand.  This doesn't solve the fundamental problem (namely 
that you escalate before aborting a running command).  All it does is 
clear the SCSI_EH_ABORT_SCHEDULED flag before escalating.

What's needed is something like a 2-bit abort counter.  
scsi_try_to_abort_cmd() should increment the counter each time it runs, 
and if scmd_eh_abort_handler() sees that the counter is too high, it 
should avoid its retry pathway.  _Then_ you can move on to something 
more drastic.

Alan Stern

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

Re: [PATCH 0/3] Fix USB deadlock caused by SCSI error handling

[Alan Stern]

On Mon, 31 Mar 2014, James Bottomley wrote:

  The actual question is whether it's worth aborting the same command
  a second time.
  In principle any reset (like LUN reset etc) should clear the
  command, too.
  And the EH abort functionality is geared around this.
  If, for some reason, the transport layer / device driver
  requires a command abort to be send then sure, we need
  to accommodate for that.
 
 We already discussed this (that was my first response too).  USB needs
 all outstanding commands aborted before proceeding to reset.  I'm
 starting to think the actual way to fix this is to reset the abort
 scheduled only if we send something else, so this might be a better fix.
 
 It doesn't matter if we finish a command with abort scheduled because
 the command then gets freed and the flags cleaned.
 
 We can take our time with this because the other two patches, which I
 can send separately fix the current deadlock (we no longer send an
 unaborted request sense before the reset), and it can go via rc fixes.
 
 James
 
 ---
 
 diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
 index 771c16b..3cfd2bf 100644
 --- a/drivers/scsi/scsi_error.c
 +++ b/drivers/scsi/scsi_error.c
 @@ -1007,6 +1007,12 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, 
 unsigned char *cmnd,
   const unsigned long stall_for = msecs_to_jiffies(100);
   int rtn;
  
 + /*
 +  * We're sending another command we'll need to abort, so reset the
 +  * abort scheduled flag on the real command before we save its state
 +  */
 + scmd-eh_eflags = ~SCSI_EH_ABORT_SCHEDULED;
 +
  retry:
   scsi_eh_prep_cmnd(scmd, ses, cmnd, cmnd_size, sense_bytes);
   shost-eh_action = done;

I don't know if Hannes will like this, but I don't think it is right.  
This is not the retry pathway that's causing problems; that pathway 
begins where scmd_eh_abort_handler() calls scsi_queue_insert().

Now, that call is already guarded by this test:

if (...  (++scmd-retries = scmd-allowed)) {

which would seem to prevent the infinite loop that Hannes was concerned 
about.  So maybe the 1/3 patch posted a couple of days ago is the best 
solution after all.

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: Discussion: Link Layer Test implementation strategy for Linux Embedded Host

[Alan Stern]

On Mon, 31 Mar 2014, Greg KH wrote:

 On Mon, Mar 31, 2014 at 05:14:31PM +0530, Pratyush Anand wrote:
  Hi Alan/Greg,
  
  I was starting some work for running Lecroy USB Compliance Suite Link
  Layer Tests with embedded xhci host, which runs Linux. I thought, its
  wise to discuss my test strategy before I start implementing it,
  as in long run I would like to push them to mainline.
  
  These tests have been defined in USB 3.0 Link Layer Test
  Specification.
  
  For a xhci host's downstream port under test (PUT), Lecroy excersizer with 
  USB Compliance Suite acts as Link Validation System (LVS).
  
  Most of the link layer tests only expects link to be in U0. If a host
  sends a setup packet, it is NAKed by LVS. However, there are some
  tests which ask host to send some control command like Get Descriptor
  etc.

How are you planning to support the tests that don't require sending 
any packets?  Can you use that same mechanism for the tests that do 
require a packet?

  To add support of these tests, I wanted to go as under:
  
  1. Add a quirk flag for the root hub sysfs device node to prevent 
  enumeration
 of a device.
  2. Before a lecroy LVS device is connected to the root hub n, do something 
  like
  this.
  echo 1   /sys/bus/usb/devices/usbn/avoid_enum_quirk
  3. Now connect LVS device and run Link Layer tests from Lecroy USB
  Compliance Suite.
  4. To get back into normal working situation (to connect a general usb 
  device
  to root hub n), do following:
  echo 0   /sys/bus/usb/devices/usbn/avoid_enum_quirk
  5. Modify hub driver to prevent enumeration when a new device is connected 
  and 
  this flag is set.
   Create a new dummy device (VID, PID to be discussed with 
  ssusbcomplia...@usb.org),
  and call its driver (say lvstestdev). (Is there a way to call use
  driver on the basis of name only?)

It could be done based on the VID PID combination, together with a 
vendor-specific class and protocol setting.

  This lvstestdev implements further sys nodes/or some other
  method like ioctl etc to allow an application to generate traffic
  for some specific test case.
  6. When this device is disconnected then the created dummy device is
  destroyed. (Even a single test case may generate multiple
  connection/disconnection from LVS)
  
  Do, you think this flow would be correct, or there could be some
  better approach?
 
 I don't know, try it out and let us see how it works.

There already is a vaguely similar test setup in ehci-hcd.  However, it 
requires the device to be enumerated, so it doesn't involve any changes 
to the USB core.

Does the test device respond to Get-Device-Descriptor requests?

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: problem with resume after s2ram

[Alan Stern]

On Mon, 31 Mar 2014, Peter Münster wrote:

 On Mon, Mar 31 2014, Alan Stern wrote:
 
  That's totally crazy.  With wakeup enabled, the commit should have had 
  no effect at all.
 
 Hi Alan,
 
 With 0aa2832dd0d9d860 kernel, the freeze happens only when something is
 connected to the rear port.
 
 But with later kernels (= 3.11), the freeze happens also without
 anything connected to the rear port.

So maybe we're talking about more than one bug.

I thought you had posted a log showing 3.12 working with no reversions
and everything plugged into the front, but my memory must be wrong.

 (See also here:
  https://bugzilla.novell.com/show_bug.cgi?id=868315#c12 )
 
 
  Here's another diagnostic patch to try (use it along with the first
  one).  Do the same test, i.e., only the keyboard in a rear port.  This
  patch effectively reverts commit 0aa2832dd0d9d860 and instead, prints
  out information showing what the commit would do.
 
 Please find attached 3 files:
 
 - messages-1.log: wake-up ok, but problem with nouveau or cpu.
   I guess, it was just bad luck and this has nothing to do with usb.
   I've had a similar lock-up already with 3.7 kernel.
 
 - messages-2.log: this time without X-server
 
 - messages-3.log: with X-server (and no lock-up this time)

These all seem to be basically the same, apart from the Nouveau issue.  
This suggests that the previous test (i.e., without the new diagnostic 
patch) would have worked if _nothing_ was plugged into a front port and 
the keyboard was plugged into the rear port.  Can you try that?

Also, I'd like to track down the problem when both devices are plugged
into front ports.  Can you try that as well, again without the new
diagnostic patch?  If the problem in this case is caused by a separate
bug then we may not learn anything, but it's worth a try.

  (By the way, the first diagnostic patch did provide interesting
  information.  Maybe you noticed: The frame values were _not_ changing!)
 
 Yes. I guess that means, that the usb-hub did not wake up?

So it seems.  This evidently is a problem in the hardware, and the
final fix will have to work around it.  Probably I'll end up adding
code to ohci-hcd that will cancel out the effect of 0aa2832dd0d9d860 on
all systems having that type of OHCI controller.  Please provide the
output from lspci -v -s 12.1 and lspci -v -n -s 12.1.

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: Discussion: Link Layer Test implementation strategy for Linux Embedded Host

[Pratyush Anand]

Hi Alan,


On Tue, Apr 1, 2014 at 4:19 AM, Alan Stern st...@rowland.harvard.edu wrote:
 On Mon, 31 Mar 2014, Greg KH wrote:

 On Mon, Mar 31, 2014 at 05:14:31PM +0530, Pratyush Anand wrote:
  Hi Alan/Greg,
 
  I was starting some work for running Lecroy USB Compliance Suite Link
  Layer Tests with embedded xhci host, which runs Linux. I thought, its
  wise to discuss my test strategy before I start implementing it,
  as in long run I would like to push them to mainline.
 
  These tests have been defined in USB 3.0 Link Layer Test
  Specification.
 
  For a xhci host's downstream port under test (PUT), Lecroy excersizer with
  USB Compliance Suite acts as Link Validation System (LVS).
 
  Most of the link layer tests only expects link to be in U0. If a host
  sends a setup packet, it is NAKed by LVS. However, there are some
  tests which ask host to send some control command like Get Descriptor
  etc.

 How are you planning to support the tests that don't require sending
 any packets?  Can you use that same mechanism for the tests that do
 require a packet?


Yes, same mechanism for the test that do not require a packet. In
fact, for those tests
nothing to be done in the driver. Once core has been stopped for
enumeration and link is in U0,
it is sufficient. All the link layer packets are responded by hardware
without any software intervention.

  To add support of these tests, I wanted to go as under:
 
  1. Add a quirk flag for the root hub sysfs device node to prevent 
  enumeration
 of a device.
  2. Before a lecroy LVS device is connected to the root hub n, do something 
  like
  this.
  echo 1   /sys/bus/usb/devices/usbn/avoid_enum_quirk
  3. Now connect LVS device and run Link Layer tests from Lecroy USB
  Compliance Suite.
  4. To get back into normal working situation (to connect a general usb 
  device
  to root hub n), do following:
  echo 0   /sys/bus/usb/devices/usbn/avoid_enum_quirk
  5. Modify hub driver to prevent enumeration when a new device is connected 
  and
  this flag is set.
   Create a new dummy device (VID, PID to be discussed with 
  ssusbcomplia...@usb.org),
  and call its driver (say lvstestdev). (Is there a way to call use
  driver on the basis of name only?)

 It could be done based on the VID PID combination, together with a
 vendor-specific class and protocol setting.


Only problem is that unlike Embedded Host High Speed Electrical Test
Procedure Specs V1.01
USB 3.0 Link Layer Test Specs  not defines VID, PIDs yet. May be
this specs need a bit more
maturity for embedded hosts. Anyway, at the moment let me go with the
implementation. I will
float RFCs when my host will be passing all tests.

  This lvstestdev implements further sys nodes/or some other
  method like ioctl etc to allow an application to generate traffic
  for some specific test case.
  6. When this device is disconnected then the created dummy device is
  destroyed. (Even a single test case may generate multiple
  connection/disconnection from LVS)
 
  Do, you think this flow would be correct, or there could be some
  better approach?

 I don't know, try it out and let us see how it works.

 There already is a vaguely similar test setup in ehci-hcd.  However, it
 requires the device to be enumerated, so it doesn't involve any changes
 to the USB core.


misc/ehset.c... EH Electrical Tests allows host to enumerate device
till Set Configuration.
Therefore , no change in core layer required.

 Does the test device respond to Get-Device-Descriptor requests?

Yes, Lecroy Compliance Suite device  prompts like Send Get Device
Descriptor from host. For, sure
it would be responding to that.

Regards
Pratyush


 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
--
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/ch341: Add parity support

[Karl Palsson]

I originally sent this to fr...@kingswood-consulting.co.uk who is listed as the
maintainer for this driver, but I haven't heard a reply, so I'm posting to the
list.  This is my first patch for a driver, so I've tried to follow the
existing style, but if there are any changes that should be made, please let me
know. (There is almost no debugging in this driver, so possibly I should remove
the debug I added?)

This was developed against 3.13.6 and 3.13.7, but has been rebased against
3.14.

--
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/ch341: Add parity support

[Karl Palsson]

Based on wireshark packet traces from a windows machine.

ch340 and ch341 both seem to support all parity modes, but only the ch341
appears to support variable data bits and variable stop bits, so those are left
unimplemented, as before.

Tested on a generic usb-rs485 dongle with the chip label scratched off, and
some Modbus/RTU devices that required various parity settings.

Signed-off-by: Karl Palsson ka...@tweak.net.au
---
 drivers/usb/serial/ch341.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
index 82371f6..afd2ec4 100644
--- a/drivers/usb/serial/ch341.c
+++ b/drivers/usb/serial/ch341.c
@@ -346,6 +346,7 @@ static void ch341_set_termios(struct tty_struct *tty,
struct ch341_private *priv = usb_get_serial_port_data(port);
unsigned baud_rate;
unsigned long flags;
+   unsigned int par_flags;
 
baud_rate = tty_get_baud_rate(tty);
 
@@ -366,9 +367,33 @@ static void ch341_set_termios(struct tty_struct *tty,
 
/* Unimplemented:
 * (cflag  CSIZE) : data bits [5, 8]
-* (cflag  PARENB) : parity {NONE, EVEN, ODD}
 * (cflag  CSTOPB) : stop bits [1, 2]
 */
+   /* CH340 doesn't appear to support variable stop bits or data bits */
+   if (C_PARENB(tty)) {
+   if (C_PARODD(tty)) {
+   if (tty-termios.c_cflag  CMSPAR) {
+   dev_dbg(port-dev, parity = mark\n);
+   par_flags = 0xeb;
+   } else {
+   dev_dbg(port-dev, parity = odd\n);
+   par_flags = 0xcb;
+   }
+   } else {
+   if (tty-termios.c_cflag  CMSPAR) {
+   dev_dbg(port-dev, parity = space\n);
+   par_flags = 0xfb;
+   } else {
+   dev_dbg(port-dev, parity = even\n);
+   par_flags = 0xdb;
+   }
+   }
+   } else {
+   dev_dbg(port-dev, parity = none\n);
+   par_flags = 0xc3;
+   }
+   ch341_control_out(port-serial-dev, 0x9a, 0x2518, par_flags);
+
 }
 
 static void ch341_break_ctl(struct tty_struct *tty, int break_state)
-- 
1.8.3.1

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

Re: Patch: usb/serial/ch341: Add parity support

[Greg KH]

On Mon, Mar 31, 2014 at 11:38:42PM +, Karl Palsson wrote:
 I originally sent this to fr...@kingswood-consulting.co.uk who is listed as 
 the
 maintainer for this driver, but I haven't heard a reply, so I'm posting to the
 list.

That's good, in the future, you can use the kernel script,
scripts/get_maintainer.pl to determine who to send a patch to, including
the mailing list.

 This is my first patch for a driver, so I've tried to follow the
 existing style, but if there are any changes that should be made, please let 
 me
 know. (There is almost no debugging in this driver, so possibly I should 
 remove
 the debug I added?)
 
 This was developed against 3.13.6 and 3.13.7, but has been rebased against
 3.14.

I'll look at it after 3.15-rc1 is out, thanks for the patch.

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

Re: [PATCH v2 0/3] Some update for USB OTG

[Peter Chen]

On Thu, Mar 13, 2014 at 03:25:19PM +0800, Li Jun wrote:
 From: Li Jun b47...@freescale.com
 
 Hi Felipe,
 
 Two for fsm, the other one is to delete CONFIG_USB_OTG_FSM
 since it is duplicated with CONFIG_USB_OTG, thanks.
 
 Change on v1:
 Remove {} for a single statement in patch:
 usb: phy-fsm: update OTG HNP state transition.
 
 Li Jun (1):
   usb: phy-fsm: update OTG HNP state transition
 
 Peter Chen (2):
   usb: phy: delete CONFIG_USB_OTG_FSM
   usb: phy-fsm: change | to || for condition OTG_STATE_A_WAIT_BCON
 at statemachine
 
  drivers/usb/phy/Kconfig   |   11 +--
  drivers/usb/phy/Makefile  |2 +-
  drivers/usb/phy/phy-fsm-usb.c |9 +
  3 files changed, 7 insertions(+), 15 deletions(-)
 
 -- 
 1.7.9.5
 
 

Hi Felipe,

Would you give some comments for this patchset please? For the
patch usb: phy: delete CONFIG_USB_OTG_FSM, I sent it more
than two months ago, I need to know your comments if it
can be accepted or not, we are working on OTG FSM patchset
for chipidea, and it is close to review process,
we need to know if we can use CONFIG_USB_OTG_FSM to cover OTG
(fsm) code, or just CONFIG_USB_OTG is ok, thanks.

-- 

Best Regards,
Peter Chen

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

Re: [PATCH v5 07/11] usb: chipidea: OTG HNP and SRP fsm implementation.

[Peter Chen]

On Mon, Mar 31, 2014 at 05:03:00PM +0800, Li Jun wrote:
 On Mon, Mar 31, 2014 at 03:24:35PM +0800, Peter Chen wrote:
  On Sun, Mar 30, 2014 at 08:20:09PM +0800, Li Jun wrote:
   From: Li Jun b47...@freescale.com
   
   USB OTG interrupt handling and fsm transitions according to USB OTG
   and EH 2.0.
   
   Signed-off-by: Li Jun b47...@freescale.com
   ---
drivers/usb/chipidea/core.c|8 +-
drivers/usb/chipidea/otg.c |9 +-
drivers/usb/chipidea/otg_fsm.c |  236 
   
drivers/usb/chipidea/otg_fsm.h |   18 +++
drivers/usb/chipidea/udc.c |6 +
5 files changed, 273 insertions(+), 4 deletions(-)
   
   diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
   index ff38cf3..6544149 100644
   --- a/drivers/usb/chipidea/core.c
   +++ b/drivers/usb/chipidea/core.c
   @@ -42,7 +42,6 @@
 * - Not Supported: 15  16 (ISO)
 *
 * TODO List
   - * - OTG
 * - Interrupt Traffic
 * - GET_STATUS(device) - always reports 0
 * - Gadget API (majority of optional features)
   @@ -74,6 +73,7 @@
#include host.h
#include debug.h
#include otg.h
   +#include otg_fsm.h

/* Controller register map */
static const u8 ci_regs_nolpm[] = {
   @@ -412,8 +412,12 @@ static irqreturn_t ci_irq(int irq, void *data)
 irqreturn_t ret = IRQ_NONE;
 u32 otgsc = 0;

   - if (ci-is_otg)
   + if (ci-is_otg) {
 otgsc = hw_read_otgsc(ci, ~0);
   + ret = ci_otg_fsm_irq(ci);
   + if (ret == IRQ_HANDLED)
   + return ret;
   + }

 /*
  * Handle id change interrupt, it indicates device/host function
   diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
   index b278cd9..5169640 100644
   --- a/drivers/usb/chipidea/otg.c
   +++ b/drivers/usb/chipidea/otg.c
   @@ -11,8 +11,8 @@
 */

/*
   - * This file mainly handles otgsc register, it may include OTG operation
   - * in the future.
   + * This file mainly handles otgsc register, OTG fsm operations for HNP 
   and SRP
   + * are also included.
 */

#include linux/usb/otg.h
   @@ -91,6 +91,11 @@ static void ci_otg_work(struct work_struct *work)
{
 struct ci_hdrc *ci = container_of(work, struct ci_hdrc, work);

   + if (!ci_otg_fsm_work(ci)) {
   + enable_irq(ci-irq);
   + return;
   + }
   +
 if (ci-id_event) {
 ci-id_event = false;
 ci_handle_id_switch(ci);
   diff --git a/drivers/usb/chipidea/otg_fsm.c 
   b/drivers/usb/chipidea/otg_fsm.c
   index d49bbdd..8e30fc64 100644
   --- a/drivers/usb/chipidea/otg_fsm.c
   +++ b/drivers/usb/chipidea/otg_fsm.c
   @@ -13,6 +13,10 @@
/*
 * This file mainly handles OTG fsm, it includes OTG fsm operations
 * for HNP and SRP.
   + *
   + * TODO List
   + * - ADP
   + * - OTG test device
 */

#include linux/usb/otg.h
   @@ -92,6 +96,33 @@ static void ci_otg_del_timer(struct ci_hdrc *ci, enum 
   ci_otg_fsm_timer_index t)
 hw_write_otgsc(ci, OTGSC_1MSIE, 0);
}

   +/*
   + * Reduce timer count by 1, and find timeout conditions.
   + * Called by otg 1ms timer interrupt
   + */
   +static inline int ci_otg_tick_timer(struct ci_hdrc *ci)
   +{
   + struct ci_otg_fsm_timer *tmp_timer, *del_tmp;
   + struct list_head *active_timers = ci-fsm_timer-active_timers;
   + int expired = 0;
   +
   + list_for_each_entry_safe(tmp_timer, del_tmp, active_timers, list) {
   + tmp_timer-count--;
   + /* check if timer expires */
   + if (!tmp_timer-count) {
   + list_del(tmp_timer-list);
   + tmp_timer-function(ci, tmp_timer-data);
   + expired = 1;
   + }
   + }
   +
   + /* disable 1ms irq if there is no any timer active */
   + if ((expired == 1)  list_empty(active_timers))
   + hw_write_otgsc(ci, OTGSC_1MSIE, 0);
   +
   + return expired;
   +}
   +
/* The timeout callback function to set time out bit */
static void set_tmout(void *ptr, unsigned long indicator)
{
   @@ -385,6 +416,209 @@ static struct otg_fsm_ops ci_otg_ops = {
 .start_gadget = ci_otg_start_gadget,
};

   +int ci_otg_fsm_work(struct ci_hdrc *ci)
   +{
   + if (!ci-transceiver-otg)
   + return -ENODEV;
   +
   + /*
   +  * Don't do fsm transition for B device
   +  * when there is no gadget class driver
   +  */
   + if (ci-fsm.id  !(ci-driver) 
   + ci-transceiver-state  OTG_STATE_A_IDLE)
  
  Why the third condition is needed?
  
 
 To make a_ state can be transfered to next state when micro-A plug is 
 removed
 (id is 1) while gadget driver is not enabled.
 
   + return 0;
   +
   + if (otg_statemachine(ci-fsm)) {
   + if (ci-transceiver-state == OTG_STATE_A_IDLE) {
   + if (ci-fsm.id)
   + /* A idle to B idle */
   + otg_statemachine(ci-fsm);
   + 

[PATCH v3] usb: host: Add HCD for MAX3421E chip.

[David Mosberger]

Final version of the driver.  This includes support for low-speed devices
connected via full-speed hubs.  I believe this patch incorporates all the
concrete suggestions that have been made on the mailing list.

Signed-off-by: David Mosberger dav...@egauge.net
---
 drivers/usb/Makefile   |1 +
 drivers/usb/host/Kconfig   |   11 +
 drivers/usb/host/Makefile  |1 +
 drivers/usb/host/max3421-hcd.c | 1886 
 4 files changed, 1899 insertions(+)
 create mode 100644 drivers/usb/host/max3421-hcd.c

diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 1ae2bf3..9bb6721 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_USB_IMX21_HCD)   += host/
 obj-$(CONFIG_USB_FSL_MPH_DR_OF)+= host/
 obj-$(CONFIG_USB_FUSBH200_HCD) += host/
 obj-$(CONFIG_USB_FOTG210_HCD)  += host/
+obj-$(CONFIG_USB_MAX3421_HCD)  += host/
 
 obj-$(CONFIG_USB_C67X00_HCD)   += c67x00/
 
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 3d9e540..e9cd7d8 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -343,6 +343,17 @@ config USB_FOTG210_HCD
  To compile this driver as a module, choose M here: the
  module will be called fotg210-hcd.
 
+config USB_MAX3421_HCD
+   tristate MAX3421 HCD (USB-over-SPI) support
+   depends on USB
+   ---help---
+ The Maxim MAX3421E chip supports standard USB 2.0-compliant
+ full-speed devices either in host or peripheral mode.  This
+ driver supports the host-mode of the MAX3421E only.
+
+ To compile this driver as a module, choose M here: the module will
+ be called max3421-hcd.
+
 config USB_OHCI_HCD
tristate OHCI HCD (USB 1.1) support
select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 7530468..ea2bec5 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -70,3 +70,4 @@ obj-$(CONFIG_USB_HCD_BCMA)+= bcma-hcd.o
 obj-$(CONFIG_USB_HCD_SSB)  += ssb-hcd.o
 obj-$(CONFIG_USB_FUSBH200_HCD) += fusbh200-hcd.o
 obj-$(CONFIG_USB_FOTG210_HCD)  += fotg210-hcd.o
+obj-$(CONFIG_USB_MAX3421_HCD)  += max3421-hcd.o
diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
new file mode 100644
index 000..d1263d0
--- /dev/null
+++ b/drivers/usb/host/max3421-hcd.c
@@ -0,0 +1,1886 @@
+/*
+ * MAX3421 Host Controller driver for USB.
+ *
+ * Author: David Mosberger-Tang dav...@egauge.net
+ *
+ * (C) Copyright 2014 David Mosberger-Tang dav...@egauge.net
+ *
+ * MAX3421 is a chip implementing a USB 2.0 Full-/Low-Speed host
+ * controller on a SPI bus.
+ *
+ * Based on:
+ * o MAX3421E datasheet
+ * http://datasheets.maximintegrated.com/en/ds/MAX3421E.pdf
+ * o MAX3421E Programming Guide
+ * http://www.hdl.co.jp/ftpdata/utl-001/AN3785.pdf
+ * o gadget/dummy_hcd.c
+ * For USB HCD implementation.
+ * o Arduino MAX3421 driver
+ *  https://github.com/felis/USB_Host_Shield_2.0/blob/master/Usb.cpp
+ *
+ * This file is licenced under the GPL v2.
+ *
+ * Important note on worst-case (full-speed) packet size constraints
+ * (See USB 2.0 Section 5.6.3 and following):
+ *
+ * - control:64 bytes
+ * - isochronous:  1023 bytes
+ * - interrupt:  64 bytes
+ * - bulk:   64 bytes
+ *
+ * Since the MAX3421 FIFO size is 64 bytes, we do not have to work about
+ * multi-FIFO writes/reads for a single USB packet *except* for isochronous
+ * transfers.  We don't support isochronous transfers at this time, so we
+ * just assume that a USB packet always fits into a single FIFO buffer.
+ *
+ * NOTE: The June 2006 version of MAX3421E Programming Guide
+ * (AN3785) has conflicting info for the RCVDAVIRQ bit:
+ *
+ * The description of RCVDAVIRQ says The CPU *must* clear
+ * this IRQ bit (by writing a 1 to it) before reading the
+ * RCVFIFO data.
+ *
+ * However, the earlier section on Programming BULK-IN
+ * Transfers says * that:
+ *
+ * After the CPU retrieves the data, it clears the
+ * RCVDAVIRQ bit.
+ *
+ * The December 2006 version has been corrected and it consistently
+ * states the second behavior is the correct one.
+ *
+ * Synchronous SPI transactions sleep so we can't perform any such
+ * transactions while holding a spin-lock (and/or while interrupts are
+ * masked).  To achieve this, all SPI transactions are issued from a
+ * single thread (max3421_spi_thread).
+ */
+
+#include linux/module.h
+#include linux/spi/spi.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+
+#define DRIVER_DESCMAX3421 USB Host-Controller Driver
+#define DRIVER_VERSION 1.0
+
+/* 11-bit counter that wraps around (USB 2.0 Section 8.3.3): */
+#define USB_MAX_FRAME_NUMBER   0x7ff
+#define USB_MAX_RETRIES3 /* # of retries before error is 
reported */
+
+/*
+ * Max. # of times we're willing to 

Re: [PATCH v2 0/3] Some update for USB OTG

[Felipe Balbi]

On Tue, Apr 01, 2014 at 08:36:58AM +0800, Peter Chen wrote:
 On Thu, Mar 13, 2014 at 03:25:19PM +0800, Li Jun wrote:
  From: Li Jun b47...@freescale.com
  
  Hi Felipe,
  
  Two for fsm, the other one is to delete CONFIG_USB_OTG_FSM
  since it is duplicated with CONFIG_USB_OTG, thanks.
  
  Change on v1:
  Remove {} for a single statement in patch:
  usb: phy-fsm: update OTG HNP state transition.
  
  Li Jun (1):
usb: phy-fsm: update OTG HNP state transition
  
  Peter Chen (2):
usb: phy: delete CONFIG_USB_OTG_FSM
usb: phy-fsm: change | to || for condition OTG_STATE_A_WAIT_BCON
  at statemachine
  
   drivers/usb/phy/Kconfig   |   11 +--
   drivers/usb/phy/Makefile  |2 +-
   drivers/usb/phy/phy-fsm-usb.c |9 +
   3 files changed, 7 insertions(+), 15 deletions(-)
  
  -- 
  1.7.9.5
  
  
 
 Hi Felipe,
 
 Would you give some comments for this patchset please? For the
 patch usb: phy: delete CONFIG_USB_OTG_FSM, I sent it more
 than two months ago, I need to know your comments if it
 can be accepted or not, we are working on OTG FSM patchset
 for chipidea, and it is close to review process,
 we need to know if we can use CONFIG_USB_OTG_FSM to cover OTG
 (fsm) code, or just CONFIG_USB_OTG is ok, thanks.

I know you've sent this a long time ago and I've been banging my head
ever since trying to decide if we should delete OTG FSM or not. On the
one hand the OTG is pretty generic and aparently everybody would benefit
from it but on the other hand we might have HW which implements the
state machine without much SW control - though I can't remind of any
good examples.

Also, I think most of that code should be agnostic of the PHY layer and
sit in usb-common.c. Quite frankly, OTG shouldn't depend on the PHY at
all, we could very well have implementations which need/have no SW
control over the PHY and still be fully OTG compliant.

cheers

ps: I'll get back to this after merge window closes.

-- 
balbi


signature.asc
Description: Digital signature

RE: [PATCH v2 0/3] Some update for USB OTG

[Peter Chen]

 
  
   Hi Felipe,
  
   Two for fsm, the other one is to delete CONFIG_USB_OTG_FSM since it
   is duplicated with CONFIG_USB_OTG, thanks.
  
   Change on v1:
   Remove {} for a single statement in patch:
   usb: phy-fsm: update OTG HNP state transition.
  
   Li Jun (1):
 usb: phy-fsm: update OTG HNP state transition
  
   Peter Chen (2):
 usb: phy: delete CONFIG_USB_OTG_FSM
 usb: phy-fsm: change | to || for condition
 OTG_STATE_A_WAIT_BCON
   at statemachine
  
drivers/usb/phy/Kconfig   |   11 +--
drivers/usb/phy/Makefile  |2 +-
drivers/usb/phy/phy-fsm-usb.c |9 +
3 files changed, 7 insertions(+), 15 deletions(-)
  
   --
   1.7.9.5
  
  
 
  Hi Felipe,
 
  Would you give some comments for this patchset please? For the patch
  usb: phy: delete CONFIG_USB_OTG_FSM, I sent it more than two months
  ago, I need to know your comments if it can be accepted or not, we are
  working on OTG FSM patchset for chipidea, and it is close to review
  process, we need to know if we can use CONFIG_USB_OTG_FSM to cover OTG
  (fsm) code, or just CONFIG_USB_OTG is ok, thanks.
 
 I know you've sent this a long time ago and I've been banging my head
 ever since trying to decide if we should delete OTG FSM or not. On the
 one hand the OTG is pretty generic and aparently everybody would benefit
 from it but on the other hand we might have HW which implements the state
 machine without much SW control - though I can't remind of any good
 examples.
 
 Also, I think most of that code should be agnostic of the PHY layer and
 sit in usb-common.c. Quite frankly, OTG shouldn't depend on the PHY at
 all, we could very well have implementations which need/have no SW
 control over the PHY and still be fully OTG compliant.
 
 
Thanks, I agreed with you too long time ago that otg should not be related to 
PHY.
One more thing, I think we should move out otg staff from phy/, and have a new
folder named otg, if you agree with it, I can do it.

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