Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'

[Joe Rayhawk]

On Fri, Apr 19, 2013 at 02:18:24PM -0400, Alan Stern wrote:
> On Fri, 19 Apr 2013, Clemens Ladisch wrote:
> > Alan Stern wrote:
> > > + next = uhci->frame_number + 2;
> > >
> > > That 2 is the minimum latency, in frames (one frame per ms).
> > 
> > One frame worked fine with the old driver.  What is the reason for
> > this regression?
> 
> Perhaps that was a mistake.  Joe, you can try changing the 2 above to a 
> 1 to see if it fixes the problem.

Hey, that worked great! Audio's coming through continuously, now.

root@richardiv:~# uname -a; cat /sys/kernel/debug/usb/usbmon/4u & perl -e 
'print pack "H*", "00FF" x 2048' | aplay --period-size=48 -r 44100 -f S16_LE 
-c2 -D hw:1,0; kill %1
Linux richardiv 3.9.0-rc7-nextframe #8 SMP Fri Apr 19 16:29:37 PDT 2013 x86_64 
GNU/Linux
[1] 4598
Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
880154aba440 3793290194 S Co:4:005:0 s 01 0b 0001 0001  0
880154aba440 3793292190 C Co:4:005:0 0 0
8801515a20c0 3793292289 S Co:4:005:0 s 22 01 0100 0001 0003 3 = 44ac00
8801515a20c0 3793293167 C Co:4:005:0 0 3 >
8801515a20c0 3793293206 S Ci:4:005:0 s a2 81 0100 0001 0003 3 <
8801515a20c0 3793294188 C Ci:4:005:0 0 3 = 44ac00
880142054dc0 3793294216 S Zo:4:005:1 -115:1:0 1 -18:0:176 176 =  
      
8801420541c0 3793294221 S Zo:4:005:1 -115:1:0 1 -18:0:176 176 =  
      
880142054dc0 3793305177 C Zo:4:005:1 0:1:362330:0 1 0:0:176 176 >
880142054dc0 3793305202 S Zo:4:005:1 -115:1:362330 1 -18:0:176 176 = 
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801420541c0 3793306165 C Zo:4:005:1 0:1:362331:0 1 0:0:176 176 >
8801420541c0 3793306186 S Zo:4:005:1 -115:1:362331 1 -18:0:176 176 = 
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880142054dc0 3793307191 C Zo:4:005:1 0:1:362332:0 1 0:0:176 176 >
880142054dc0 3793307208 S Zo:4:005:1 -115:1:362332 1 -18:0:176 176 = 
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801420541c0 3793308190 C Zo:4:005:1 0:1:362333:0 1 0:0:176 176 >
8801420541c0 3793308203 S Zo:4:005:1 -115:1:362333 1 -18:0:176 176 = 
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880142054dc0 3793309191 C Zo:4:005:1 0:1:362334:0 1 0:0:176 176 >
880142054dc0 3793309209 S Zo:4:005:1 -115:1:362334 1 -18:0:176 176 = 
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801420541c0 3793310194 C Zo:4:005:1 0:1:362335:0 1 0:0:176 176 >
8801420541c0 3793310211 S Zo:4:005:1 -115:1:362335 1 -18:0:176 176 = 
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880142054dc0 3793311192 C Zo:4:005:1 0:1:362336:0 1 0:0:176 176 >
880142054dc0 3793311211 S Zo:4:005:1 -115:1:362336 1 -18:0:176 176 = 
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801420541c0 3793312194 C Zo:4:005:1 0:1:362337:0 1 0:0:176 176 >
8801420541c0 3793312212 S Zo:4:005:1 -115:1:362337 1 -18:0:180 180 = 
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880142054dc0 3793313172 C Zo:4:005:1 0:1:362338:0 1 0:0:176 176 >
880142054dc0 3793313188 S Zo:4:005:1 -115:1:362338 1 -18:0:176 176 = 
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801420541c0 3793314192 C Zo:4:005:1 0:1:362339:0 1 0:0:180 180 >
8801420541c0 3793314209 S Zo:4:005:1 -115:1:362339 1 -18:0:176 176 = 
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880142054dc0 3793315192 C Zo:4:005:1 0:1:362340:0 1 0:0:176 176 >
880142054dc0 3793315210 S Zo:4:005:1 -115:1:362340 1 -18:0:176 176 = 
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801420541c0 3793316192 C Zo:4:005:1 0:1:362341:0 1 0:0:176 176 >
8801420541c0 3793316209 S Zo:4:005:1 -115:1:362341 1 -18:0:176 176 = 
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880142054dc0 3793317196 C Zo:4:005:1 0:1:362342:0 1 0:0:176 176 >
880142054dc0 3793317207 S Zo:4:005:1 -115:1:362342 1 -18:0:176 176 = 
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801420541c0 3793318191 C Zo:4:005:1 0:1:362343:0 1 0:0:176 176 >
8801420541c0 3793318209 S Zo:4:005:1 -115:1:362343 1 -18:0:176 176 = 
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880142054dc0 3793319193 C Zo:4:005:1 0:1:362344:0 1 0:0:176 176 >
880142054dc0 3793319211 S Zo:4:005:1 -115:1:362344 1 -18:0:176 176 = 
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801420541c0 3793320191 C Zo:4:005:1 0:1:362345:0 1 0:0:176 176 >
8801420541c0 3793320208 S Zo:4:005:1 -115:1:362345 1 -18:0:176 176 = 
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880142054dc0 379332119

Re: [PATCH net,stable 0/3] qmi_wwan: working around 3 serious firmware bugs

[Dan Williams]

On Fri, 2013-04-19 at 17:51 -0400, David Miller wrote:
> From: Bjørn Mork 
> Date: Fri, 19 Apr 2013 00:57:08 +0200
> 
> > This series adds workarounds for 3 different firmware bugs, each
> > preventing the affected devices from working at all. I therefore
> > humbly request that these fixes go to stable-3.8 (if still
> > maintained) and 3.9 (either via net if still possible, or via
> > stable if not).
> > 
> > All 3 workarounds are applied to all devices supported by the driver.
> > Adding quirks for specific devices was considered as an alternative,
> > but was rejected because we have too little information about the
> > exact distribution of the buggy firmwares. All we know is that the
> > same bug shows up in devices from at least 3 different, and presumably
> > independent, vendors.
> > 
> > The workarounds have instead been designed to automatically apply
> > when necessary, and to have as little impact as possible on unaffected
> > devices.  The series has been tested on a number of devices both with
> > and without these bugs.
> > 
> > The series should apply cleanly to net/master, net-next/master and
> > stable/linux-3.8.y
> 
> Series applied and queued up for -stable, thanks!

You're fast :)  But in any case:

Tested-by: Dan Williams 

Tested on Gobi 1K (known not to exhibit the raw-ip bug), Novatel E362,
and Pantech UML290.

Dan


--
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 v4 0/4] Add USB support to R8A7778/BOCK-W

[Sergei Shtylyov]

Hello.

On 04/20/2013 02:07 AM, Sergei Shtylyov wrote:


Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130416' tag and the R8A7779/Marzen patchset I've posted.


   Sorry, it's against 'renesas-next-20130419' tag now.

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

[PATCH v4 3/3] ARM: shmobile: BOCK-W: add USB support

[Sergei Shtylyov]

Register the USB PHY device from bockw_init(), passing the platform  data to it.
Set machine's init_late() method to r8a7778_init_late() in order for [EO]HCI to
get registered too...

The patch has been tested on the BOCK-W board.

Signed-off-by: Sergei Shtylyov 

---
Changes since version 3:
- removed initializer for 'usb_phy_platform_data' letting it be set to all 0s;
- refreshed the patch.

Changes since version 2:
- refreshed the patch.

Changes since the original posting:
- removed initializer for no longer existing field in 'usb_phy_platform_data',
  modified the comment to the 'ferrite_bead' field initializer.

 arch/arm/mach-shmobile/board-bockw.c |4 
 1 file changed, 4 insertions(+)

Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -54,6 +54,8 @@ static struct resource smsc911x_resource
DEFINE_RES_IRQ(irq_pin(0)), /* IRQ 0 */
 };
 
+static struct rcar_phy_platform_data usb_phy_platform_data;
+
 static const struct pinctrl_map bockw_pinctrl_map[] = {
/* SCIF0 */
PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a7778",
@@ -71,6 +73,7 @@ static void __init bockw_init(void)
r8a7778_clock_init();
r8a7778_init_irq_extpin(1);
r8a7778_add_standard_devices();
+   r8a7778_add_usb_phy_device(&usb_phy_platform_data);
 
pinctrl_register_mappings(bockw_pinctrl_map,
  ARRAY_SIZE(bockw_pinctrl_map));
@@ -111,4 +114,5 @@ DT_MACHINE_START(BOCKW_DT, "bockw")
.init_machine   = bockw_init,
.init_time  = shmobile_timer_init,
.dt_compat  = bockw_boards_compat_dt,
+   .init_late  = r8a7778_init_late,
 MACHINE_END
--
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 v4 2/3] ARM: shmobile: r8a7778: add USB support

[Sergei Shtylyov]

Add USB clock and EHCI, OHCI, and USB PHY platform devices for R8A7778 SoC;  add
a function to register PHY device with board-specific platform data and register
EHCI and OHCI platfrom devices from the init_late() board method.

Also,  don't forget to enable CONFIG_ARCH_HAS_[EO]HCI options for R8A7778 SoC in
Kconfig...

The patch has been tested on the BOCK-W board.

Signed-off-by: Sergei Shtylyov 

---
Changes since version 3:
- resolved reject in the 'clock-r8a7778.c' file, refreshed the patch.

Changes since version 2:
- refreshed the patch.

Changes since the original posting:
- resolved rejects in the 'clock-r8a7778.c' file;
- lowercased the SoC name in the subject.

 arch/arm/mach-shmobile/Kconfig|2 
 arch/arm/mach-shmobile/clock-r8a7778.c|4 
 arch/arm/mach-shmobile/include/mach/r8a7778.h |3 
 arch/arm/mach-shmobile/setup-r8a7778.c|  108 ++
 4 files changed, 117 insertions(+)

Index: renesas/arch/arm/mach-shmobile/Kconfig
===
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -41,6 +41,8 @@ config ARCH_R8A7778
select CPU_V7
select SH_CLK_CPG
select ARM_GIC
+   select USB_ARCH_HAS_EHCI
+   select USB_ARCH_HAS_OHCI
 
 config ARCH_R8A7779
bool "R-Car H1 (R8A77790)"
Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -105,6 +105,7 @@ static struct clk *main_clks[] = {
 enum {
MSTP323, MSTP322, MSTP321,
MSTP114,
+   MSTP100,
MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
MSTP016, MSTP015,
MSTP_NR };
@@ -114,6 +115,7 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP322] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 22, 0), /* SDHI1 */
[MSTP321] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 21, 0), /* SDHI2 */
[MSTP114] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 14, 0), /* Ether */
+   [MSTP100] = SH_CLK_MSTP32(&p_clk, MSTPCR1,  0, 0), /* USB0/1 */
[MSTP026] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 26, 0), /* SCIF0 */
[MSTP025] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 25, 0), /* SCIF1 */
[MSTP024] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 24, 0), /* SCIF2 */
@@ -130,6 +132,8 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP322]), /* SDHI1 */
CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP321]), /* SDHI2 */
CLKDEV_DEV_ID("sh-eth", &mstp_clks[MSTP114]), /* Ether */
+   CLKDEV_DEV_ID("ehci-platform", &mstp_clks[MSTP100]), /* USB EHCI 
port0/1 */
+   CLKDEV_DEV_ID("ohci-platform", &mstp_clks[MSTP100]), /* USB OHCI 
port0/1 */
CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -20,10 +20,13 @@
 
 #include 
 #include 
+#include 
 
 extern void r8a7778_add_standard_devices(void);
 extern void r8a7778_add_standard_devices_dt(void);
 extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7778_init_late(void);
 extern void r8a7778_init_delay(void);
 extern void r8a7778_init_irq(void);
 extern void r8a7778_init_irq_dt(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -29,6 +29,12 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -88,6 +94,99 @@ static struct sh_timer_config sh_tmu1_pl
&sh_tmu##idx##_platform_data,   \
sizeof(sh_tmu##idx##_platform_data))
 
+/* USB PHY */
+static struct resource usb_phy_resources[] = {
+   DEFINE_RES_MEM(0xffe70800, 0x100),
+   DEFINE_RES_MEM(0xffe76000, 0x100),
+};
+
+void __init r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+   platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+ usb_phy_resources,
+ ARRAY_SIZE(usb_phy_resources),
+ pdata, sizeof(*pdata));
+}
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+   if (!phy)
+   re

[PATCH v4 1/3] rcar-phy: add R8A7778 support

[Sergei Shtylyov]

The driver currently only supports R8A7779 SoC. Compared to it, R8A7778 USB-PHY
has extra register range containing two high-speed signal quality characteristic
control registers which should be set up  during USB-PHY  startup depending on
whether a ferrite bead is in use or not.  So, we now handle an optional second
memory range in the driver's probe method, add the 'ferrite_bead' field to the
driver's platform data, and add an extra (optional) step to the USB-PHY startup
routine which sets up the extended registers.

Also mark in the driver's Kconfig section  that R8A7778 is  now supported and
generally clarify that section, uppercasing the word "phy", while at it... 

The patch has been tested on the Marzen and BOCK-W boards.

Signed-off-by: Sergei Shtylyov 
Acked-by: Felipe Balbi 

---
Changes since version 3:
- removed stray debugging printk() call.

Changes since version 2:
- moved 'ferrite_bead' bitfield to the start of 'struct rcar_phy_platform_data'
  which allowed to cut the size of the structure from 8 bytes back to 4;
- added a comment about only 2 USB ports on R8A7778'
- added an ACK from Felipe Balbi.

Changes since the original posting:
- made the necessary changes atop of the R8A7779/Marzen pathset version 4.

 drivers/usb/phy/Kconfig  |8 
 drivers/usb/phy/rcar-phy.c   |   37 +++--
 include/linux/usb/rcar-phy.h |4 +++-
 3 files changed, 38 insertions(+), 11 deletions(-)

Index: renesas/drivers/usb/phy/Kconfig
===
--- renesas.orig/drivers/usb/phy/Kconfig
+++ renesas/drivers/usb/phy/Kconfig
@@ -55,13 +55,13 @@ config MV_U3D_PHY
  SoC.
 
 config USB_RCAR_PHY
-   tristate "Renesas R-Car USB phy support"
+   tristate "Renesas R-Car USB PHY support"
depends on USB || USB_GADGET
select USB_OTG_UTILS
help
- Say Y here to add support for the Renesas R-Car USB phy driver.
- This chip is typically used as USB phy for USB host, gadget.
- This driver supports: R8A7779
+ Say Y here to add support for the Renesas R-Car USB common PHY driver.
+ This device is typically used as USB PHY for USB host, gadget.
+ This driver supports R8A7778 and R8A7779.
 
  To compile this driver as a module, choose M here: the
  module will be called rcar-phy.
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -26,15 +26,21 @@
 #define USBOH0 0x1C
 #define USBCTL00x58
 
+/* High-speed signal quality characteristic control registers (R8A7778 only) */
+#define HSQCTL10x24
+#define HSQCTL20x28
+
 /* USBPCTRL0 */
-#define OVC2   (1 << 10) /* Switches the OVC input pin for port 2: */
+#define OVC2   (1 << 10) /* (R8A7779 only) */
+   /* Switches the OVC input pin for port 2: */
/* 1: USB_OVC2, 0: OVC2 */
 #define OVC1_VBUS1 (1 << 9) /* Switches the OVC input pin for port 1: */
/* 1: USB_OVC1, 0: OVC1/VBUS1   */
/* Function mode: set to 0  */
 #define OVC0   (1 << 8) /* Switches the OVC input pin for port 0: */
/* 1: USB_OVC0 pin, 0: OVC0 */
-#define OVC2_ACT   (1 << 6) /* Host mode: OVC2 polarity:   */
+#define OVC2_ACT   (1 << 6) /* (R8A7779 only)  */
+   /* Host mode: OVC2 polarity:*/
/* 1: active-high, 0: active-low*/
 #define PENC   (1 << 4) /* Function mode: output level of PENC1 pin: */
/* 1: high, 0: low  */
@@ -59,6 +65,7 @@ struct rcar_usb_phy_priv {
spinlock_t lock;
 
void __iomem *reg0;
+   void __iomem *reg1;
int counter;
 };
 
@@ -78,6 +85,7 @@ static int rcar_usb_phy_init(struct usb_
struct device *dev = phy->dev;
struct rcar_phy_platform_data *pdata = dev->platform_data;
void __iomem *reg0 = priv->reg0;
+   void __iomem *reg1 = priv->reg1;
const u8 ovcn_act[] = { OVC0_ACT, OVC1_ACT, OVC2_ACT };
int i;
u32 val;
@@ -96,7 +104,16 @@ static int rcar_usb_phy_init(struct usb_
/* (2) start USB-PHY internal PLL */
iowrite32(PHY_ENB | PLL_ENB, (reg0 + USBPCTRL1));
 
-   /* (3) USB module status check */
+   /* (3) set USB-PHY in accord with the conditions of usage */
+   if (reg1) {
+   u32 hsqctl1 = pdata->ferrite_bead ? 0x41 : 0;
+   u32 hsqctl2 = pdata->ferrite_bead ? 0x0d : 7;
+
+   i

[PATCH v4 0/4] Add USB support to R8A7778/BOCK-W

[Sergei Shtylyov]

Hello.

   Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130416' tag and the R8A7779/Marzen patchset I've posted.
 It was created to add support of R8A7778/BOCK-W USB to the platform code and
the USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and
drivers/usb/phy/ subtrees.

[1/3] rcar-phy: add R8A7778 support
[2/3] ARM: shmobile: r8a7778: add USB support
[3/3] ARM: shmobile: BOCK-W: add USB support

The patch #4 (ARM: shmobile: BOCK-W: enable USB in defconfig) that has been
already merged, is not reposted.

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

[PATCH v5 9/9] rcar-phy: handle platform data

[Sergei Shtylyov]

Set the USBPCTRL0 register from the passed platform data in rcar_usb_phy_init();
don't reset it to 0 in  rcar_usb_phy_shutdown()  anymore as that does not make
sense.  Also, don't allow the driver's probe to succeed when the platform data
are not supplied with a device.

The patch has been tested on the Marzen and BOCK-W boards.

Signed-off-by: Sergei Shtylyov 
Acked-by: Kuninori Morimoto 
Acked-by: Simon Horman 

---
Changes since version 3:
- moved USBPCTRL0 register bit #define's from patch #7, removing the prefixes;
- implemented parsing of the platform data to set USBPCTRL0 register.

Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

 drivers/usb/phy/rcar-phy.c |   53 +++--
 1 file changed, 46 insertions(+), 7 deletions(-)

Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -1,8 +1,9 @@
 /*
  * Renesas R-Car USB phy driver
  *
- * Copyright (C) 2012 Renesas Solutions Corp.
+ * Copyright (C) 2012-2013 Renesas Solutions Corp.
  * Kuninori Morimoto 
+ * Copyright (C) 2013 Cogent Embedded, Inc.
  *
  * 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
@@ -11,10 +12,11 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /* REGS block */
 #define USBPCTRL0  0x00
@@ -24,6 +26,25 @@
 #define USBOH0 0x1C
 #define USBCTL00x58
 
+/* USBPCTRL0 */
+#define OVC2   (1 << 10) /* Switches the OVC input pin for port 2: */
+   /* 1: USB_OVC2, 0: OVC2 */
+#define OVC1_VBUS1 (1 << 9) /* Switches the OVC input pin for port 1: */
+   /* 1: USB_OVC1, 0: OVC1/VBUS1   */
+   /* Function mode: set to 0  */
+#define OVC0   (1 << 8) /* Switches the OVC input pin for port 0: */
+   /* 1: USB_OVC0 pin, 0: OVC0 */
+#define OVC2_ACT   (1 << 6) /* Host mode: OVC2 polarity:   */
+   /* 1: active-high, 0: active-low*/
+#define PENC   (1 << 4) /* Function mode: output level of PENC1 pin: */
+   /* 1: high, 0: low  */
+#define OVC0_ACT   (1 << 3) /* Host mode: OVC0 polarity:   */
+   /* 1: active-high, 0: active-low*/
+#define OVC1_ACT   (1 << 1) /* Host mode: OVC1 polarity:   */
+   /* 1: active-high, 0: active-low*/
+   /* Function mode: be sure to set to 1   */
+#define PORT1  (1 << 0) /* Selects port 1 mode:*/
+   /* 1: function, 0: host */
 /* USBPCTRL1 */
 #define PHY_RST(1 << 2)
 #define PLL_ENB(1 << 1)
@@ -55,7 +76,9 @@ static int rcar_usb_phy_init(struct usb_
 {
struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
struct device *dev = phy->dev;
+   struct rcar_phy_platform_data *pdata = dev->platform_data;
void __iomem *reg0 = priv->reg0;
+   const u8 ovcn_act[] = { OVC0_ACT, OVC1_ACT, OVC2_ACT };
int i;
u32 val;
unsigned long flags;
@@ -89,8 +112,21 @@ static int rcar_usb_phy_init(struct usb_
/* (4) USB-PHY reset clear */
iowrite32(PHY_ENB | PLL_ENB | PHY_RST, (reg0 + USBPCTRL1));
 
-   /* set platform specific port settings */
-   iowrite32(0x, (reg0 + USBPCTRL0));
+   /* Board specific port settings */
+   val = 0;
+   if (pdata->port1_func)
+   val |= PORT1;
+   if (pdata->penc1)
+   val |= PENC;
+   for (i = 0; i < 3; i++) {
+   /* OVCn bits follow each other in the right order */
+   if (pdata->ovc_pin[i].select_3_3v)
+   val |= OVC0 << i;
+   /* OVCn_ACT bits are spaced by irregular intervals */
+   if (pdata->ovc_pin[i].active_high)
+   val |= ovcn_act[i];
+   }
+   iowrite32(val, (reg0 + USBPCTRL0));
 
/*
 * Bus alignment settings
@@ -117,10 +153,8 @@ static void rcar_usb_phy_shutdown(struct
 
spin_lock_irqsave(&priv->lock, flags);
 
-   if (priv->counter-- == 1) { /* last user */
-   iowrite32(0x, (reg0 + USBPCTRL0));
+   if (priv->counter-- == 1)   /* last user */
iowrite32(0x, (reg0 + USBPCTRL1));
-   }
 
spin_unlock_irqrest

[PATCH v5 8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device

[Sergei Shtylyov]

Since we're now going to setup the USBPCTRL0 register using the USB PHY device's
platform data, we now need a way to pass those platform data from the board file
to the device which is situated in setup-r8a7779.c -- and what I'm suggesting is
r8a7779_add_usb_phy_device() that will register USB PHY platform device with the
passed platform data using platform_device_register_resndata() call; creating
this function envolves deletion of 'usb_phy_device' from r8a7779_devices_dt[],
so that it will no longer be registered for the generic R8A7779 machine (where
we can't provide the platform data anyway), hence EHCI/OHCI drivers will fail
to load as well.

For the Marzen board, this new function will be called from marzen_init() to
register the USB PHY device early enough.

Note that the board and the SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov 
Acked-by: Kuninori Morimoto 
Acked-by: Simon Horman 

---
Changes since version 4:
- refreshed the patch.

Changes since version 3:
- removed the initializer for 'usb_phy_platform_data';
- refreshed the 'board-marzen.c' file.

Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/board-marzen.c |3 +++
 arch/arm/mach-shmobile/include/mach/r8a7779.h |2 ++
 arch/arm/mach-shmobile/setup-r8a7779.c|   16 
 3 files changed, 13 insertions(+), 8 deletions(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -57,6 +57,8 @@ static struct regulator_consumer_supply 
REGULATOR_SUPPLY("vdd33a", "smsc911x"),
 };
 
+static struct rcar_phy_platform_data usb_phy_platform_data;
+
 /* SMSC LAN89218 */
 static struct resource smsc911x_resources[] = {
[0] = {
@@ -232,6 +234,7 @@ static void __init marzen_init(void)
r8a7779_init_irq_extpin(1); /* IRQ1 as individual interrupt */
 
r8a7779_add_standard_devices();
+   r8a7779_add_usb_phy_device(&usb_phy_platform_data);
platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
 
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct platform_device;
 
@@ -33,6 +34,7 @@ extern void r8a7779_add_early_devices(vo
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
 extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -397,13 +397,6 @@ static struct resource usb_phy_resources
},
 };
 
-static struct platform_device usb_phy_device = {
-   .name   = "rcar_usb_phy",
-   .id = -1,
-   .resource   = usb_phy_resources,
-   .num_resources  = ARRAY_SIZE(usb_phy_resources),
-};
-
 /* USB */
 static struct usb_phy *phy;
 
@@ -575,7 +568,6 @@ static struct platform_device *r8a7779_d
&scif5_device,
&tmu00_device,
&tmu01_device,
-   &usb_phy_device,
 };
 
 static struct platform_device *r8a7779_standard_devices[] __initdata = {
@@ -610,6 +602,14 @@ void __init r8a7779_add_ether_device(str
  pdata, sizeof(*pdata));
 }
 
+void __init r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+   platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+ usb_phy_resources,
+ ARRAY_SIZE(usb_phy_resources),
+ pdata, sizeof(*pdata));
+}
+
 /* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
 void __init __weak r8a7779_register_twd(void) { }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 7/9] rcar-phy: add platform data

[Sergei Shtylyov]

Currently the driver hard-codes USBPCTRL0 register to 0.  It is wrong since this
register contains board-specific USB ports configuration and so its value should
be somehow passed via the platform data.  Add  file with
the 'struct rcar_phy_platform_data' containing various bit fields describing
USB pin configuration.

Signed-off-by: Sergei Shtylyov 
Acked-by: Kuninori Morimoto 
Acked-by: Simon Horman 

---
Changes since version 3:
- moved USBPCTRL0 register bit #define's to patch #9;
- replaced USBPCTRL0 register value in the platform data structure by a set of
  bit fields describing the configuration of the board, rewrote changelog;

Changes since version 2:
- added #include ;
- added ACKs from Simon Horman and Kuninori Morimoto.

 include/linux/usb/rcar-phy.h |   26 ++
 1 file changed, 26 insertions(+)

Index: renesas/include/linux/usb/rcar-phy.h
===
--- /dev/null
+++ renesas/include/linux/usb/rcar-phy.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Cogent Embedded, Inc.
+ *
+ * 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.
+ */
+
+#ifndef __RCAR_PHY_H
+#define __RCAR_PHY_H
+
+#include 
+
+struct rcar_phy_platform_data {
+   bool port1_func:1;  /* true: port 1 used by function, false: host */
+   unsigned penc1:1;   /* Output of the PENC1 pin in function mode */
+   struct {/* Overcurrent pin control for ports 0..2 */
+   bool select_3_3v:1; /* true: USB_OVCn pin, false: OVCn pin */
+   /* Set to false on port 1 in function mode */
+   bool active_high:1; /* true: active  high, false: active low */
+   /* Set to true  on port 1 in function mode */
+   } ovc_pin[3];
+};
+
+#endif /* __RCAR_PHY_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 6/9] rcar-phy: correct base address

[Sergei Shtylyov]

The memory region that is used by the driver overlaps EHCI and OHCI  register
regions for absolutely no reason now  -- fix it  by adding offset of 0x800 to
the base address, changing the register #define's accordingly. This has extra
positive effect that we now can use devm_ioremap_resource()...

Note that the driver and the SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov 
Acked-by: Kuninori Morimoto 
Acked-by: Simon Horman 

---
Changes since version 4:
- refreshed the patch.

Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/setup-r8a7779.c |2 +-
 drivers/usb/phy/rcar-phy.c |   28 ++--
 2 files changed, 11 insertions(+), 19 deletions(-)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -391,7 +391,7 @@ static struct platform_device sata_devic
 /* USB PHY */
 static struct resource usb_phy_resources[] = {
[0] = {
-   .start  = 0xffe7,
+   .start  = 0xffe70800,
.end= 0xffe70900 - 1,
.flags  = IORESOURCE_MEM,
},
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -16,13 +16,13 @@
 #include 
 #include 
 
-/* USBH common register */
-#define USBPCTRL0  0x0800
-#define USBPCTRL1  0x0804
-#define USBST  0x0808
-#define USBEH0 0x080C
-#define USBOH0 0x081C
-#define USBCTL00x0858
+/* REGS block */
+#define USBPCTRL0  0x00
+#define USBPCTRL1  0x04
+#define USBST  0x08
+#define USBEH0 0x0C
+#define USBOH0 0x1C
+#define USBCTL00x58
 
 /* USBPCTRL1 */
 #define PHY_RST(1 << 2)
@@ -139,17 +139,9 @@ static int rcar_usb_phy_probe(struct pla
return -EINVAL;
}
 
-   /*
-* CAUTION
-*
-* Because this phy address is also mapped under OHCI/EHCI address area,
-* this driver can't use devm_request_and_ioremap(dev, res) here
-*/
-   reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0));
-   if (!reg0) {
-   dev_err(dev, "ioremap error\n");
-   return -ENOMEM;
-   }
+   reg0 = devm_ioremap_resource(dev, res0);
+   if (IS_ERR(reg0))
+   return PTR_ERR(reg0);
 
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv) {
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource

[Sergei Shtylyov]

Now that 'drivers/usb/phy/rcar-phy.c' doesn't require the second memory resource
anymore, we can remove it from the R8A7779's USB PHY platform device.

Signed-off-by: Sergei Shtylyov 
Acked-by: Kuninori Morimoto 
Acked-by: Simon Horman 

---
Changes since version 4:
- refreshed the patch.

Changes since version 3:
- lowercased the SoC name in the subject.

Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- new patch in this version, split from the previous one.

 arch/arm/mach-shmobile/setup-r8a7779.c |5 -
 1 file changed, 5 deletions(-)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -395,11 +395,6 @@ static struct resource usb_phy_resources
.end= 0xffe70900 - 1,
.flags  = IORESOURCE_MEM,
},
-   [1] = {
-   .start  = 0xfff7,
-   .end= 0xfff70900 - 1,
-   .flags  = IORESOURCE_MEM,
-   },
 };
 
 static struct platform_device usb_phy_device = {
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 4/9] rcar-phy: remove EHCI internal buffer setup

[Sergei Shtylyov]

Now that the EHCI internal  buffer setup is done by the platform code, we  can
remove  such code from this driver as it  never  really belonged here.  We also
no longer need the 2nd memory region now (2nd EHCI controller is simply missing
in e.g. R8A7778 SoC).

The patch has been tested on the Marzen and BOCK-W boards.

Signed-off-by: Sergei Shtylyov 
Acked-by: Kuninori Morimoto 
Acked-by: Simon Horman 

---
Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- split R8A7779 SoC file change to a separate patch.

 drivers/usb/phy/rcar-phy.c |   28 
 1 file changed, 4 insertions(+), 24 deletions(-)

Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -23,8 +23,6 @@
 #define USBEH0 0x080C
 #define USBOH0 0x081C
 #define USBCTL00x0858
-#define EIIBC1 0x0094
-#define EIIBC2 0x009C
 
 /* USBPCTRL1 */
 #define PHY_RST(1 << 2)
@@ -40,7 +38,6 @@ struct rcar_usb_phy_priv {
spinlock_t lock;
 
void __iomem *reg0;
-   void __iomem *reg1;
int counter;
 };
 
@@ -59,7 +56,6 @@ static int rcar_usb_phy_init(struct usb_
struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
struct device *dev = phy->dev;
void __iomem *reg0 = priv->reg0;
-   void __iomem *reg1 = priv->reg1;
int i;
u32 val;
unsigned long flags;
@@ -97,19 +93,6 @@ static int rcar_usb_phy_init(struct usb_
iowrite32(0x, (reg0 + USBPCTRL0));
 
/*
-* EHCI IP internal buffer setting
-* EHCI IP internal buffer enable
-*
-* These are recommended value of a datasheet
-* see [USB :: EHCI internal buffer setting]
-*/
-   iowrite32(0x00ff0040, (reg0 + EIIBC1));
-   iowrite32(0x00ff0040, (reg1 + EIIBC1));
-
-   iowrite32(0x0001, (reg0 + EIIBC2));
-   iowrite32(0x0001, (reg1 + EIIBC2));
-
-   /*
 * Bus alignment settings
 */
 
@@ -145,14 +128,13 @@ static void rcar_usb_phy_shutdown(struct
 static int rcar_usb_phy_probe(struct platform_device *pdev)
 {
struct rcar_usb_phy_priv *priv;
-   struct resource *res0, *res1;
+   struct resource *res0;
struct device *dev = &pdev->dev;
-   void __iomem *reg0, *reg1;
+   void __iomem *reg0;
int ret;
 
res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-   if (!res0 || !res1) {
+   if (!res0) {
dev_err(dev, "Not enough platform resources\n");
return -EINVAL;
}
@@ -164,8 +146,7 @@ static int rcar_usb_phy_probe(struct pla
 * this driver can't use devm_request_and_ioremap(dev, res) here
 */
reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0));
-   reg1 = devm_ioremap_nocache(dev, res1->start, resource_size(res1));
-   if (!reg0 || !reg1) {
+   if (!reg0) {
dev_err(dev, "ioremap error\n");
return -ENOMEM;
}
@@ -177,7 +158,6 @@ static int rcar_usb_phy_probe(struct pla
}
 
priv->reg0  = reg0;
-   priv->reg1  = reg1;
priv->counter   = 0;
priv->phy.dev   = dev;
priv->phy.label = dev_name(dev);
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer

[Sergei Shtylyov]

Setup the EHCI internal buffer (before EHCI driver has a chance to touch the
registers) using the pre_setup() method in 'struct usb_ehci_pdata'.

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov 
Acked-by: Kuninori Morimoto 
Acked-by: Simon Horman 

---
Changes since version 4:
- refreshed the patch.

Changes since version 3:
- lowercased the SoC name in the subject.

Changes since version 2:
- added #include ;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- changed from init() platform device method to pre_setup() as per the previous
  patch.

 arch/arm/mach-shmobile/setup-r8a7779.c |   16 
 1 file changed, 16 insertions(+)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -435,10 +436,25 @@ static void usb_power_off(struct platfor
pm_runtime_disable(&pdev->dev);
 }
 
+static int ehci_init_internal_buffer(struct usb_hcd *hcd)
+{
+   /*
+* Below are recommended values from the datasheet;
+* see [USB :: Setting of EHCI Internal Buffer].
+*/
+   /* EHCI IP internal buffer setting */
+   iowrite32(0x00ff0040, hcd->regs + 0x0094);
+   /* EHCI IP internal buffer enable */
+   iowrite32(0x0001, hcd->regs + 0x009C);
+
+   return 0;
+}
+
 static struct usb_ehci_pdata ehcix_pdata = {
.power_on   = usb_power_on,
.power_off  = usb_power_off,
.power_suspend  = usb_power_off,
+   .pre_setup  = ehci_init_internal_buffer,
 };
 
 static struct resource ehci0_resources[] = {
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/9] ehci-platform: add pre_setup() method to platform data

[Sergei Shtylyov]

Sometimes there is a need  to initialize some non-standard registers mapped to
the EHCI region before accessing the standard EHCI registers.  Add pre_setup()
method with 'struct usb_hcd *' parameter to be called just before ehci_setup()
to the 'ehci-platform'  driver's platform data for this purpose...

While at it, add the missing incomplete declaration of 'struct platform_device'
to ...

The patch has been tested on the Marzen and BOCK-W boards.

Suggested-by: Alan Stern 
Signed-off-by: Sergei Shtylyov 
Acked-by: Kuninori Morimoto 
Acked-by: Simon Horman 
Acked-by: Alan Stern 

---
Changes since version 3:
- added ACK from Alan Stern.

Changes since version 2:
- replaced #include with incomplete declarations of 'struct platform_device' and
  'struct usb_hcd';
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- changed init() method to pre_setup() with different parameters and call site.

 drivers/usb/host/ehci-platform.c |6 ++
 include/linux/usb/ehci_pdriver.h |4 
 2 files changed, 10 insertions(+)

Index: renesas/drivers/usb/host/ehci-platform.c
===
--- renesas.orig/drivers/usb/host/ehci-platform.c
+++ renesas/drivers/usb/host/ehci-platform.c
@@ -46,6 +46,12 @@ static int ehci_platform_reset(struct us
ehci->big_endian_desc = pdata->big_endian_desc;
ehci->big_endian_mmio = pdata->big_endian_mmio;
 
+   if (pdata->pre_setup) {
+   retval = pdata->pre_setup(hcd);
+   if (retval < 0)
+   return retval;
+   }
+
ehci->caps = hcd->regs + pdata->caps_offset;
retval = ehci_setup(hcd);
if (retval)
Index: renesas/include/linux/usb/ehci_pdriver.h
===
--- renesas.orig/include/linux/usb/ehci_pdriver.h
+++ renesas/include/linux/usb/ehci_pdriver.h
@@ -19,6 +19,9 @@
 #ifndef __USB_CORE_EHCI_PDRIVER_H
 #define __USB_CORE_EHCI_PDRIVER_H
 
+struct platform_device;
+struct usb_hcd;
+
 /**
  * struct usb_ehci_pdata - platform_data for generic ehci driver
  *
@@ -50,6 +53,7 @@ struct usb_ehci_pdata {
/* Turn on only VBUS suspend power and hotplug detection,
 * turn off everything else */
void (*power_suspend)(struct platform_device *pdev);
+   int (*pre_setup)(struct usb_hcd *hcd);
 };
 
 #endif /* __USB_CORE_EHCI_PDRIVER_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code

[Sergei Shtylyov]

USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
registered in the Marzen board file.  Move the data and code to their proper
place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[]
to 8a7779_standard_devices[] -- this seems legitimate since they are registered
from r8a7779_add_standard_devices() anyway.

Note that I'm deliberately changing the USB PHY platform device's 'id' field
from (previously just omitted) 0 to -1 as the device is a single of its kind.

Note also that the board and SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov 
Acked-by: Kuninori Morimoto 
Acked-by: Simon Horman 

---
Changes since version 4:
- resolved reject in the 'board-marzen.c' file, refreshed the patch.

Changes since version 3:
- refreshed the 'board-marzen.c' file.

Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/board-marzen.c |  178 -
 arch/arm/mach-shmobile/include/mach/r8a7779.h |1 
 arch/arm/mach-shmobile/setup-r8a7779.c|  185 +-
 3 files changed, 184 insertions(+), 180 deletions(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -37,10 +37,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -150,26 +146,6 @@ static struct platform_device hspi_devic
.num_resources  = ARRAY_SIZE(hspi_resources),
 };
 
-/* USB PHY */
-static struct resource usb_phy_resources[] = {
-   [0] = {
-   .start  = 0xffe7,
-   .end= 0xffe70900 - 1,
-   .flags  = IORESOURCE_MEM,
-   },
-   [1] = {
-   .start  = 0xfff7,
-   .end= 0xfff70900 - 1,
-   .flags  = IORESOURCE_MEM,
-   },
-};
-
-static struct platform_device usb_phy_device = {
-   .name   = "rcar_usb_phy",
-   .resource   = usb_phy_resources,
-   .num_resources  = ARRAY_SIZE(usb_phy_resources),
-};
-
 /* LEDS */
 static struct gpio_led marzen_leds[] = {
{
@@ -205,161 +181,9 @@ static struct platform_device *marzen_de
&sdhi0_device,
&thermal_device,
&hspi_device,
-   &usb_phy_device,
&leds_device,
 };
 
-/* USB */
-static struct usb_phy *phy;
-static int usb_power_on(struct platform_device *pdev)
-{
-   if (!phy)
-   return -EIO;
-
-   pm_runtime_enable(&pdev->dev);
-   pm_runtime_get_sync(&pdev->dev);
-
-   usb_phy_init(phy);
-
-   return 0;
-}
-
-static void usb_power_off(struct platform_device *pdev)
-{
-   if (!phy)
-   return;
-
-   usb_phy_shutdown(phy);
-
-   pm_runtime_put_sync(&pdev->dev);
-   pm_runtime_disable(&pdev->dev);
-}
-
-static struct usb_ehci_pdata ehcix_pdata = {
-   .power_on   = usb_power_on,
-   .power_off  = usb_power_off,
-   .power_suspend  = usb_power_off,
-};
-
-static struct resource ehci0_resources[] = {
-   [0] = {
-   .start  = 0xffe7,
-   .end= 0xffe70400 - 1,
-   .flags  = IORESOURCE_MEM,
-   },
-   [1] = {
-   .start  = gic_iid(0x4c),
-   .flags  = IORESOURCE_IRQ,
-   },
-};
-
-static struct platform_device ehci0_device = {
-   .name   = "ehci-platform",
-   .id = 0,
-   .dev= {
-   .dma_mask   = &ehci0_device.dev.coherent_dma_mask,
-   .coherent_dma_mask  = 0x,
-   .platform_data  = &ehcix_pdata,
-   },
-   .num_resources  = ARRAY_SIZE(ehci0_resources),
-   .resource   = ehci0_resources,
-};
-
-static struct resource ehci1_resources[] = {
-   [0] = {
-   .start  = 0xfff7,
-   .end= 0xfff70400 - 1,
-   .flags  = IORESOURCE_MEM,
-   },
-   [1] = {
-   .start  = gic_iid(0x4d),
-   .flags  = IORESOURCE_IRQ,
-   },
-};
-
-static struct platform_device ehci1_device = {
-   .name   = "ehci-platform",
-   .id = 1,
-   .dev= {
-   .dma_mask   = &ehci1_device.dev.coherent_dma_mask,
-   .coherent_dma_mask  = 0x,
-   .platform_data  = &ehcix_pdata,
-   },
-   .num_resources  = ARRAY_SIZE(ehci1_resources),
-   .resource   = ehci1_resources,
-};
-
-static struct usb_ohci_pdata ohcix_pdata = {
-   .power_on   = usb_power_on,
-   .power_off 

[PATCH v5 0/9] Reorganize R8A7779/Marzen USB code

[Sergei Shtylyov]

Hello.

   Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130419' tag.  It was created to fix the shortcomings in the
R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
to touch both subtrees). The patches were conceived with the complete
bisectability goal in mind.

[1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 
code
[2/9] ehci-platform: add pre_setup() method to platform data
[3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer
[4/9] rcar-phy: remove EHCI internal buffer setup
[5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource
[6/9] rcar-phy: correct base address
[7/9] rcar-phy: add platform data
[8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
[9/9] rcar-phy: handle platform data

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 net,stable 0/3] qmi_wwan: working around 3 serious firmware bugs

[David Miller]

From: Bjørn Mork 
Date: Fri, 19 Apr 2013 00:57:08 +0200

> This series adds workarounds for 3 different firmware bugs, each
> preventing the affected devices from working at all. I therefore
> humbly request that these fixes go to stable-3.8 (if still
> maintained) and 3.9 (either via net if still possible, or via
> stable if not).
> 
> All 3 workarounds are applied to all devices supported by the driver.
> Adding quirks for specific devices was considered as an alternative,
> but was rejected because we have too little information about the
> exact distribution of the buggy firmwares. All we know is that the
> same bug shows up in devices from at least 3 different, and presumably
> independent, vendors.
> 
> The workarounds have instead been designed to automatically apply
> when necessary, and to have as little impact as possible on unaffected
> devices.  The series has been tested on a number of devices both with
> and without these bugs.
> 
> The series should apply cleanly to net/master, net-next/master and
> stable/linux-3.8.y

Series applied and queued up for -stable, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig

[Sergei Shtylyov]

On 04/19/2013 06:14 AM, Simon Horman wrote:

On Fri, Apr 19, 2013 at 02:50:05AM +0400, Sergei Shtylyov wrote:

Hello.

On 04/18/2013 06:05 PM, Simon Horman wrote:


Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'.
Enable USB storage driver and SCSI disk driver that it needs as well...

Signed-off-by: Sergei Shtylyov 

I realise that this is not going to be useful until the rest
of the series has been merged. But regardless I have pre-emptively
queued it up for v3.11 in the defconfig-bockw branch.

---
  arch/arm/configs/bockw_defconfig |   11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

Index: renesas/arch/arm/configs/bockw_defconfig
===
--- renesas.orig/arch/arm/configs/bockw_defconfig
+++ renesas/arch/arm/configs/bockw_defconfig
@@ -48,6 +48,8 @@ CONFIG_DEVTMPFS_MOUNT=y
  # CONFIG_STANDALONE is not set
  # CONFIG_PREVENT_FIRMWARE_BUILD is not set
  # CONFIG_FW_LOADER is not set
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
  CONFIG_NETDEVICES=y
  # CONFIG_NET_CADENCE is not set
  # CONFIG_NET_VENDOR_BROADCOM is not set
@@ -71,7 +73,14 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6
  CONFIG_SERIAL_SH_SCI_CONSOLE=y
  # CONFIG_HW_RANDOM is not set
  # CONFIG_HWMON is not set
-# CONFIG_USB_SUPPORT is not set
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_HCD_PLATFORM=y
+CONFIG_USB_EHCI_HCD_PLATFORM=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_RCAR_PHY=y


Unfortunately, you've made a mistake in this last line of the patch:
you've truncated it to just "CONFIG_USB_RCAR". :-(
Will you correct it?

Sorry about that, I will fix it.


Sorry to say, but you fixed it the wrong way; now it's:

+CONFIG_USB_RCAR=y

instead of:

+CONFIG_USB_RCAR_PHY=y

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: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'

[Alan Stern]

On Fri, 19 Apr 2013, Clemens Ladisch wrote:

> Alan Stern wrote:
> > ...
> > This trace shows that the frame numbers do not increase sequentially:
> > 1057125, 1057126, 1057128, 1057129, 1053131, ...  This is because the
> > new driver is a little more conservative than the old driver,
> > requiring latencies to be larger than 1 ms.  You can see this
> > explicitly in one of the new lines added by the commit you found:
> >
> > +   next = uhci->frame_number + 2;
> >
> > That 2 is the minimum latency, in frames (one frame per ms).
> 
> One frame worked fine with the old driver.  What is the reason for
> this regression?

The semantics of URB_ISO_ASAP changed; now the driver interprets as
meaning "the earliest time that is certain to work".  Since I wasn't
sure that a 1-ms latency would always work, I increased the minimum to
2.

Perhaps that was a mistake.  Joe, you can try changing the 2 above to a 
1 to see if it fixes the problem.

> > Anyway, the solution is simple: The audio driver needs either to submit
> > buffers that are at least 2 ms long, or to use more than two buffers
> > (or both).
> 
> The audio driver already has the infrastructure to cope for hardware
> restrictions like this, it just needs to *know* about them.  How can
> it detect that it runs on the OHCI/UHCI drivers?

That is a very good question.  In fact, the audio driver shouldn't care 
about what kind of driver is used at the lower level; all it should 
care about are bounds on the latency.

The kernel's USB API doesn't provide this information, unfortunately.  
There should be a way for drivers to find out, for any USB device:

 A. The maximum delay time needed for starting a new isochronous
stream;

 B. The minimum advance time required for submitting a new URB
to an existing isochronous stream (i.e., the minimum pipeline
size);

 C. The maximum time into the future that isochronous URBs can be 
scheduled (the maximum pipeline size).

I don't think there's any way to add this information into all of the 
existing host controller drivers, though.

For now, the best approach is to be conservative.  I believe all the
existing USB host controller drivers will work okay if you assume the
following values:

A: 50 ms;

B: 2 ms;

C: 200 ms.

The audio driver probably doesn't care about A; you try to start a new 
stream and it gets going whenever the HCD chooses.  You may or may not 
care about C.  B is the important one for this discussion.

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: add device to a proper driver

[Greg KH]

On Fri, Apr 19, 2013 at 01:54:50AM +0700, Muhammad Safri 550257 Dzalfaiz wrote:
> Hi, I'm using this phone as modem (it works great) and after modprobe
> (and checked with dmesg) I was told to tell linux-usb@vger.kernel.org
> to add my device to a proper driver.
> 
> So here's my dmesg:
> 
> usb 1-1: new full-speed USB device number 4 using ohci_hcd
> usb 1-1: New USB device found, idVendor=1bbb, idProduct=011f
> usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-1: Product: USB MMC Storage
> usb 1-1: Manufacturer: TCT Holding Ltd.
> usb 1-1: SerialNumber: 0002
> Initializing USB Mass Storage driver...
> scsi1 : usb-storage 1-1:1.0
> usbcore: registered new interface driver usb-storage
> USB Mass Storage support registered.
> scsi 1:0:0:0: CD-ROMVirtual  CD-ROM   2.31 PQ: 0 ANSI: 2
> scsi 1:0:0:0: Attached scsi generic sg1 type 5
> sr0: scsi3-mmc drive: 0x/0x caddy
> cdrom: Uniform CD-ROM driver Revision: 3.20
> sr 1:0:0:0: Attached scsi CD-ROM sr0
> sr0: CDROM (ioctl) error, command: Xpwrite, Read disk info 51 00 00 00
> 00 00 00 00 02 00
> sr: Sense Key : Hardware Error [current]
> sr: Add. Sense: No additional sense information
> usb 1-1: USB disconnect, device number 4
> usb 1-1: new full-speed USB device number 5 using ohci_hcd
> usb 1-1: New USB device found, idVendor=1bbb, idProduct=0106
> usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> usb 1-1: Product: EVDO Modem
> usb 1-1: Manufacturer: TCT Holding Ltd.

Can you send us the output of 'lsusb -v' when this device is plugged in?

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: Linux USB file storage gadget with new UDC

[Alan Stern]

On Sat, 20 Apr 2013, victor yeo wrote:

> Hi,
> 
> >> When writing to USB gadget from Linux host, the SCSI_WRITE_10 command
> >> is sent out from the Linux host, but the USB gadget receives zero
> >> length packet. And after a long wait of 30 seconds, the Linux host
> >> resets the connection (-104). The usbmon trace and the UDC driver log
> >> are attached.
> >
> > The UDC log starts somewhere in the middle of the test, not at the
> > beginning.  It doesn't show what the gadget was doing when the error
> > started.
> 
> the linux log buffer fills up fast, and dmesg can only display so
> much. i will try again.

You can increase the log buffer size by building the kernel with a
larger value of CONFIG_LOG_BUF_SHIFT.  dmesg will display as much as 
you tell it to, using the -s option.

> Meanwhile, i observed SCSI_READ_10 command received but not processed
> by the gadget. The usbmon and UDC driver log are attached.
> 
> 55534243 ba00 0002 8a28 0020 0101  00
> 
> The SCSI_READ_10 command above is received by the UDC driver and
> passed to gadget driver.
> 
> g_file_storage gadget: bulk-out, length 31:
> : 55 53 42 43 ba 00 00 00 00 02 00 00 80 00 0a 28
> 0010: 00 00 00 20 01 00 00 01 00 00 00 00 f8 9e 33
> 
> I think it is printed in bulk_out_complete(). But gadget driver does
> not process it, no data is returned to the host, and (-104) is shown
> in usbmon trace.

Probably because the file_storage driver was already hung.  To find out 
what's going wrong, it's important to see the logs starting from 
_before_ the time when the first error occurs.

You should add some DBG lines to the fsg_main_thread routine so that 
you can see whether it gets hung in any of the calls to 
handle_exception, get_next_command, do_scsi_command, finish_reply, or 
send_status.

Alan Stern

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

Re: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code

[Sergei Shtylyov]

Hello.

On 04/19/2013 04:27 AM, Kuninori Morimoto wrote:


  I'm going to post R8A7778/BOCK-W series following this one, and
all the
patches in 1st series should additionally be tested on BOCK-W. Well, I
probably can hold up posting version 3 until I have the second
series verified.
  BTW, about R8A7778/BOCK-W, R-Car M1A user manual talks about a
ferrite
bead in 49.4.1 (3) Setting USB-PHY. Do you know for sure if it's
used or not
on BOCK-W board? PHY initialization seems to work with either
settings...

I can ask it to HW team if you want me.

 Yes, ask them please.

Now, I'm asking it to HW team
Please wait

According to HW team,
this setting is for some kind of USB compliance test (?).
So, in general, we can use "No ferrite bead".


   Thanks, I'll change it.

WBR, Sergei

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

Re: [PATCH] usb: storage: Convert US_DEBUGP to usb_stor_dbg

[Joe Perches]

On Fri, 2013-04-19 at 10:35 -0700, Greg Kroah-Hartman wrote:
> On Wed, Apr 17, 2013 at 08:00:55PM -0700, Joe Perches wrote:
> > Use a more current logging style with dev_printk
> > where possible.
[]
> With your other patch applied, this one seems to not apply to my tree:

I'll respin and resubmit.

--
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: storage: Convert US_DEBUGP to usb_stor_dbg

[Greg Kroah-Hartman]

On Wed, Apr 17, 2013 at 08:00:55PM -0700, Joe Perches wrote:
> Use a more current logging style with dev_printk
> where possible.
> 
> o Convert uses of US_DEBUGP to usb_stor_dbg
> o Add "struct us_data *" to usb_stor_dbg uses
> o usb_stor_dbg now uses struct device */dev_vprint_emit
> o Removed embedded function names
> o Coalesce formats
> o Remove trailing whitespace
> o Remove useless OOM messages
> o Remove useless function entry/exit logging
> o Convert some US_DEBUGP uses to dev_info and dev_dbg
> 
> $ size drivers/usb/storage/built-in.o*
>text  data bss dec hex filename
>  137787 55520   68584  261891   3ff03 
> drivers/usb/storage/built-in.o.debug.new
>  140782 55200   68904  264886   40ab6 
> drivers/usb/storage/built-in.o.debug.old
>  102709 54936   63784  221429   360f5 
> drivers/usb/storage/built-in.o.no_debug.new
>  101506 54568   63592  219666   35a12 
> drivers/usb/storage/built-in.o.no_debug.old
> 
> Increase in no_debug size is because some previously
> compiled-out US_DEBUGP are now dev_dbg and are compiled
> in and a couple of US_DEBUGP messages are now dev_info.

With your other patch applied, this one seems to not apply to my tree:

checking file drivers/usb/storage/alauda.c
checking file drivers/usb/storage/cypress_atacb.c
checking file drivers/usb/storage/datafab.c
checking file drivers/usb/storage/debug.c
Hunk #1 FAILED at 42.
Hunk #2 succeeded at 150 (offset 1 line).
Hunk #3 succeeded at 172 (offset 1 line).
1 out of 3 hunks FAILED
checking file drivers/usb/storage/debug.h
checking file drivers/usb/storage/ene_ub6250.c
checking file drivers/usb/storage/freecom.c
checking file drivers/usb/storage/initializers.c
checking file drivers/usb/storage/isd200.c
checking file drivers/usb/storage/jumpshot.c
checking file drivers/usb/storage/karma.c
checking file drivers/usb/storage/option_ms.c
checking file drivers/usb/storage/realtek_cr.c
checking file drivers/usb/storage/scsiglue.c
checking file drivers/usb/storage/sddr09.c
checking file drivers/usb/storage/sddr55.c
checking file drivers/usb/storage/shuttle_usbat.c
checking file drivers/usb/storage/sierra_ms.c
checking file drivers/usb/storage/transport.c
checking file drivers/usb/storage/usb.c

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

Re: [PATCH 1/7] USB: io_ti: fix TIOCGSERIAL

[Greg Kroah-Hartman]

On Thu, Apr 18, 2013 at 05:38:24PM +0200, Johan Hovold wrote:
> On Thu, Apr 18, 2013 at 05:33:17PM +0200, Johan Hovold wrote:
> > Fix regression introduced by commit f40d78155 ("USB: io_ti: kill custom
> > closing_wait implementation") which made TIOCGSERIAL return the wrong
> > value for closing_wait.
> > 
> > Cc: stable 
> 
> Oops, managed to use the old address there. Can you fix it up, Greg?

Yes, I will do that, even though my stable scripts end up checking for
both email addresses, as it's quite a common mistake.

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 4/9] usb/gadget: u_ether: construct with default values and add setters/getters

[Michal Nazarewicz]

On Thu, Apr 11 2013, Andrzej Pietrasiewicz wrote:
> When configfs support is added it will be possible to add an unconfigured
> interface to the system. This patch adds an interface to u_ether which
> makes it possible to create a struct eth_dev filled with default values,
> an interface which makes it possible to fill the struct with useful values,
> and an interface which makes it possible to read the values set.
>
> Signed-off-by: Andrzej Pietrasiewicz 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/usb/gadget/u_ether.c |  173 
> ++
>  drivers/usb/gadget/u_ether.h |  101 
>  2 files changed, 274 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/gadget/u_ether.c b/drivers/usb/gadget/u_ether.c
> index de9d84f..f9b17c8 100644
> --- a/drivers/usb/gadget/u_ether.c
> +++ b/drivers/usb/gadget/u_ether.c
> @@ -719,6 +719,24 @@ static int get_ether_addr(const char *str, u8 *dev_addr)
>   return 1;
>  }
>  
> +static int get_ether_addr_str(u8 dev_addr[ETH_ALEN], char *str, int len)
> +{
> + char *s;
> +
> + if (len < 16)

Shouldn't that be 18?

> + return -EINVAL;
> +
> + hex_dump_to_buffer(dev_addr, ETH_ALEN, 16, 1, str, 20, false);

Ditto.

> + s = str;
> + while (*s) {
> + if (*s == ' ')
> + *s = ':';
> + s++;
> + }
> +
> + return strlen(str);
> +}

static int get_ether_addr_str(u8 dev_addr[ETH_ALEN], char *str, int len)
{
if (len < 18)
return -EINVAL;
sprintf(str, "%02x:%02x:%02x:%02x:%02x:%02x",
dev_addr[0], dev_addr[1], dev_addr[2]
dev_addr[3], dev_addr[4], dev_addr[5]);
return 18;
}

Much shorter.   

> @@ -812,6 +830,161 @@ struct eth_dev *gether_setup_name(struct usb_gadget *g,
>  }
>  EXPORT_SYMBOL(gether_setup_name);
>  
> +struct net_device *gether_setup_name_default(const char *netname,
> +  u8 ethaddr[ETH_ALEN])
> +{
> + struct net_device   *net;
> + struct eth_dev  *dev;
> + int status;
> +
> + net = alloc_etherdev(sizeof(*dev));
> + if (!net)
> + return ERR_PTR(-ENOMEM);
> +
> + dev = netdev_priv(net);
> + spin_lock_init(&dev->lock);
> + spin_lock_init(&dev->req_lock);
> + INIT_WORK(&dev->work, eth_work);
> + INIT_LIST_HEAD(&dev->tx_reqs);
> + INIT_LIST_HEAD(&dev->rx_reqs);
> +
> + skb_queue_head_init(&dev->rx_frames);
> +
> + /* network device setup */
> + dev->net = net;
> + dev->qmult = QMULT_DEFAULT;
> + snprintf(net->name, sizeof(net->name), "%s%%d", netname);
> + dev->parent_dev = gadget_sysfs_root;
> +
> + eth_random_addr(net->dev_addr);
> + dev_warn(dev->parent_dev, "using random %s ethernet address\n", "self");
> + eth_random_addr(dev->host_mac);
> + dev_warn(dev->parent_dev, "using random %s ethernet address\n", "host");
> +
> + if (ethaddr)
> + memcpy(ethaddr, dev->host_mac, ETH_ALEN);
> +
> + net->netdev_ops = ð_netdev_ops;
> +
> + SET_ETHTOOL_OPS(net, &ops);
> +
> + SET_NETDEV_DEV(net, dev->parent_dev);
> + SET_NETDEV_DEVTYPE(net, &gadget_type);
> +
> + status = register_netdev(net);
> + if (status < 0) {
> + dev_dbg(dev->parent_dev, "register_netdev failed, %d\n",
> + status);
> + free_netdev(net);
> + dev = ERR_PTR(status);
> + } else {
> + INFO(dev, "MAC %pM\n", net->dev_addr);
> + INFO(dev, "HOST MAC %pM\n", dev->host_mac);
> +
> + /* two kinds of host-initiated state changes:
> +  *  - iff DATA transfer is active, carrier is "on"
> +  *  - tx queueing enabled if open *and* carrier is "on"
> +  */

Nitpick, but the comment should be:

+   /*
+* Two kinds of host-initiated state changes:
+*  - iff DATA transfer is active, carrier is "on"
+*  - tx queueing enabled if open *and* carrier is "on"
+*/

> + netif_carrier_off(net);
> + }
> +
> + return net;
> +}

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgpRT2F7AxHaK.pgp
Description: PGP signature

Re: [PATCH 2/9] usb/gadget: rndis: convert into module

[Michal Nazarewicz]

On Thu, Apr 11 2013, Andrzej Pietrasiewicz wrote:
> In order to convert to configfs the usb functions need to be converted
> to a new interface and compiled as modules. This patch creates an rndis
> module which will be used by the new functions. After all users of
> f_rndis are converted to the new interface, this module can be
> merged with f_rndis module.
>
> Signed-off-by: Andrzej Pietrasiewicz 
> Signed-off-by: Kyungmin Park 

Acked-by: Michal Nazarewicz 

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgp58uukHEqxc.pgp
Description: PGP signature

Re: [PATCH 1/9] usb/gadget: u_ether: convert into module

[Michal Nazarewicz]

On Thu, Apr 11 2013, Andrzej Pietrasiewicz wrote:
> @@ -85,3 +86,4 @@ obj-$(CONFIG_USB_G_WEBCAM)  += g_webcam.o
>  obj-$(CONFIG_USB_G_NCM)  += g_ncm.o
>  obj-$(CONFIG_USB_G_ACM_MS)   += g_acm_ms.o
>  obj-$(CONFIG_USB_GADGET_TARGET)  += tcm_usb_gadget.o
> +

If you gonna resend the patch, please drop this empty line from EOF.

> @@ -164,7 +177,8 @@ static int __init cdc_bind(struct usb_composite_dev *cdev)
>   }
>  
>   /* set up network link layer */
> - the_dev = gether_setup(cdev->gadget, hostaddr);
> + the_dev = gether_setup(cdev->gadget, dev_addr, host_addr, hostaddr,
> +qmult);

host_addr and hostaddr?  That's just confusing.  Same for other places.

>   if (IS_ERR(the_dev))
>   return PTR_ERR(the_dev);
>  

> @@ -73,6 +73,20 @@ struct gfs_ffs_obj {
>  
>  USB_GADGET_COMPOSITE_OPTIONS();
>  
> +static unsigned qmult = QMULT_DEFAULT;
> +module_param(qmult, uint, S_IRUGO|S_IWUSR);
> +MODULE_PARM_DESC(qmult, "queue length multiplier at high/super speed");
> +
> +/* initial value, changed by "ifconfig usb0 hw ether xx:xx:xx:xx:xx:xx" */
> +static char *dev_addr;
> +module_param(dev_addr, charp, S_IRUGO);
> +MODULE_PARM_DESC(dev_addr, "Device Ethernet Address");
> +
> +/* this address is invisible to ifconfig */
> +static char *host_addr;
> +module_param(host_addr, charp, S_IRUGO);
> +MODULE_PARM_DESC(host_addr, "Host Ethernet Address");
> +

So, since all of the modules have those, should that be defined in some
u_ether.h file instead?

>  static struct usb_device_descriptor gfs_dev_desc = {
>   .bLength= sizeof gfs_dev_desc,
>   .bDescriptorType= USB_DT_DEVICE,

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgpCmgQHUnLAW.pgp
Description: PGP signature

Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'

[Clemens Ladisch]

Alan Stern wrote:
> ...
> This trace shows that the frame numbers do not increase sequentially:
> 1057125, 1057126, 1057128, 1057129, 1053131, ...  This is because the
> new driver is a little more conservative than the old driver,
> requiring latencies to be larger than 1 ms.  You can see this
> explicitly in one of the new lines added by the commit you found:
>
> + next = uhci->frame_number + 2;
>
> That 2 is the minimum latency, in frames (one frame per ms).

One frame worked fine with the old driver.  What is the reason for
this regression?

> Anyway, the solution is simple: The audio driver needs either to submit
> buffers that are at least 2 ms long, or to use more than two buffers
> (or both).

The audio driver already has the infrastructure to cope for hardware
restrictions like this, it just needs to *know* about them.  How can
it detect that it runs on the OHCI/UHCI drivers?


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

Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'

[Alan Stern]

On Thu, 18 Apr 2013, Joe Rayhawk wrote:

> On Thu, Apr 18, 2013 at 12:42:00PM -0400, Alan Stern wrote:
> > On Wed, 17 Apr 2013, Joe Rayhawk wrote:
> > > Small buffer/period sizes on usb audio playback though UHCI works fine on 
> > > v3.7 but causes audio discontinuities/delays on v3.8 and v3.9-rc7.
> >
> > Can you provide a usbmon trace showing the problems?  And maybe also a 
> > similar trace made under a 3.7 kernel, where the problem doesn't occur?
> 
> root@richardiv:~# uname -a; cat /sys/kernel/debug/usb/usbmon/6u & perl -e 
> 'print pack "H*", "00FF" x 2048' | aplay --period-size=48 -r 44100 -f S16_LE 
> -c2 -D hw:1,0; kill %1
> Linux richardiv 3.7-trunk-amd64 #1 SMP Debian 3.7.1-1~experimental.1 x86_64 
> GNU/Linux
> [1] 4407
> Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo

I don't know exactly what that "--period-size=48" parameter is supposed
to accomplish.  The man page talks about time between interrupts, but
this doesn't seem to be related at all to what the usbmon trace shows.  
In this test, the audio driver ended up using two 1-ms buffers.

> 8801549cc780 288953559 S Zo:6:007:1 -115:1:0 1 -18:0:176 176 =  
>       
> 8801549cca80 288953569 S Zo:6:007:1 -115:1:0 1 -18:0:176 176 =  
>       

Here the pipeline is started by writing two buffers of zeros.

> 8801549cc780 288964489 C Zo:6:007:1 0:1:217621:0 1 0:0:176 176 >
> 8801549cc780 288964505 S Zo:6:007:1 -115:1:217621 1 -18:0:176 176 = 
> 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
> 8801549cca80 288965508 C Zo:6:007:1 0:1:217622:0 1 0:0:176 176 >
> 8801549cca80 288965527 S Zo:6:007:1 -115:1:217622 1 -18:0:176 176 = 
> 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff

In the remainder, each time a buffer completes, a new one is
submitted.  This implies a latency of less than 1 ms.  Evidently that
works okay on your system, but it won't work everywhere.

> 8801549cc780 288966486 C Zo:6:007:1 0:1:217623:0 1 0:0:176 176 >
> 8801549cc780 288966503 S Zo:6:007:1 -115:1:217623 1 -18:0:176 176 = 
> 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
> 8801549cca80 288967488 C Zo:6:007:1 0:1:217624:0 1 0:0:176 176 >
> 8801549cca80 288967507 S Zo:6:007:1 -115:1:217624 1 -18:0:176 176 = 
> 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
> 8801549cc780 288968508 C Zo:6:007:1 0:1:217625:0 1 0:0:176 176 >
> 8801549cc780 288968523 S Zo:6:007:1 -115:1:217625 1 -18:0:176 176 = 
> 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
> 8801549cca80 288969485 C Zo:6:007:1 0:1:217626:0 1 0:0:176 176 >
> 8801549cca80 288969499 S Zo:6:007:1 -115:1:217626 1 -18:0:176 176 = 
> 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
> 8801549cc780 288970507 C Zo:6:007:1 0:1:217627:0 1 0:0:176 176 >
> 8801549cc780 288970520 S Zo:6:007:1 -115:1:217627 1 -18:0:176 176 = 
> 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
> 8801549cca80 288971487 C Zo:6:007:1 0:1:217628:0 1 0:0:176 176 >
...

I won't include the whole log.  It's worth noticing that the URB
completion lines (the lines with "C") show no -EXDEV (-18) errors, and
the frame numbers increase sequentially (217623, 217624, 217625,
...).  This is consistent with the sound being produced correctly.

> root@richardiv:~# # Generated only opening and closing clicks
> 
> root@richardiv:~# uname -a; cat /sys/kernel/debug/usb/usbmon/4u & perl -e 
> 'print pack "H*", "00FF" x 2048' | aplay --period-size=48 -r 44100 -f S16_LE 
> -c2 -D hw:1,0; kill %1
> Linux richardiv 3.8-trunk-amd64 #1 SMP Debian 3.8-1~experimental.1 x86_64 
> GNU/Linux

> 880143c80d80 3864232940 C Zo:4:002:1 0:1:1057125:0 1 0:0:176 176 >
> 880143c80d80 3864232956 S Zo:4:002:1 -115:1:1057125 1 -18:0:176 176 = 
> 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
> 880143c80180 3864233934 C Zo:4:002:1 0:1:1057126:0 1 0:0:176 176 >
> 880143c80180 3864233955 S Zo:4:002:1 -115:1:1057126 1 -18:0:176 176 = 
> 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
> 880143c80d80 3864235913 C Zo:4:002:1 0:1:1057128:0 1 0:0:176 176 >
> 880143c80d80 3864235932 S Zo:4:002:1 -115:1:1057128 1 -18:0:176 176 = 
> 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
> 880143c80180 3864236910 C Zo:4:002:1 0:1:1057129:0 1 0:0:176 176 >
> 880143c80180 3864236927 S Zo:4:002:1 -115:1:1057129 1 -18:0:176 176 = 
> 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
> 880143c80d80 3864238939 C Zo:4:002:1 0:1:1057131:0 1 0:0:176 176 >
...

This trace shows that the frame numbers do not increase sequentially:
1057125, 1057126, 1057128, 1057129, 1053131, ...  This is because the
new driver is 

Re: Linux USB file storage gadget with new UDC

[Alan Stern]

On Fri, 19 Apr 2013, victor yeo wrote:

> When writing to USB gadget from Linux host, the SCSI_WRITE_10 command
> is sent out from the Linux host, but the USB gadget receives zero
> length packet. And after a long wait of 30 seconds, the Linux host
> resets the connection (-104). The usbmon trace and the UDC driver log
> are attached.

The UDC log starts somewhere in the middle of the test, not at the
beginning.  It doesn't show what the gadget was doing when the error
started.

> g_file_storage gadget: bulk-out, length 0:
> g_file_storage gadget: bulk_out_complete --> 0, 0/31
> 
> I think UDC driver receives the zero length packet on bulk out endpoint.

No.  The host does not send any zero-length packets.

The UDC driver thinks it received something on the bulk-out endpoint, 
but it is wrong.  No packet was received.

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

DWC3/xHCI host mode ethernet frame corruption on 3.8.5

[Ben Dooks]

We are using an OMAP5432 ES2.0 on a uEVM board with the dwc3 OtG block
configured for xHCI host mode. When connecting to another board with a 
similar block running in device mode with g_ether we re seeing

corrupted packets.

The ARP responses we get have an extra 2 bytes on the header, as shown
below and have 4 extra bytes on the end of the packet.

00:35:06.644708 ff:ff:d2:40:90:44 > 2e:00:ff:ff:ff:ff, ethertype Unknown 
(0xd3c

 0x:  0806 0001 0800 0604 0001 d240 9044 d3c0  ...@.D..
 0x0010:  c0a8 0101    c0a8 0103 dead  
 0x0020:  beef ..

From what I can see of the xHCI specification, the transfer
buffers should support unaligned data. From tracing through
xhci_urb_enqueue the buffer being passed is edb07042 (phys adb07042).

Unfortunately we do not have enough information about the dwc3 core
to work out if there is an problem with unaligned buffers, or if we
are missing some configuration of either the host or the otg block
to ensure that it properly handles the alignment issues.

We are currently assuming that the issue is to do with the xHCI
on the DWC3 as the gadget side works with a Intel laptop using a
NEC controller to provide a reliable network link between g_ether
and laptop's Linux cdc-ethernet.

The only other issue we had was the xhci_reset() code causing the
whole OtG block to fail, so we have currently remove the issue of
the CMD_RESET from the xhci-hcd driver to allow the system to keep
going. If this is the issue then we will need to find some other
way of resetting the entire block (currently the otg block is
initialised by the dwc3 driver before it instantiates a xHCI
platform device to handle the host side)

--
Ben Dooks   http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
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: Driver for PL-2303 HX not working

[Johan Hovold]

On Fri, Apr 19, 2013 at 02:26:48PM +0200, Karsten Malcher wrote:
> Hi Johan,
> Am 19.04.2013 11:04, schrieb Johan Hovold:
> >> This was a log with lost data.
> >> The logs seems to make politics. ;-)
> > Then the problem is most likely not in the driver as the characters are
> > being read back in the log you provided.
> 
> Stop - it's really possible that i send not enough bytes.
> Sometimes up to 6 Bytes will come back.
> 
> This time i send this string (3.2.0):
> "1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890\n"
> I get back the first 3 Bytes of it.
> Log is attached.

Was it really the same log? In the log below there is an error reported
but it looks like no data at all is returned:

> [ 1443.120415] 
> /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/generic.c:
>  usb_serial_generic_write - port 0
> [ 1443.120430] pl2303 ttyUSB0: usb_serial_generic_write_start - length = 101, 
> data = 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 
> 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 
> 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 
> 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 0a 

> [ 1443.122568] 
> /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/generic.c:
>  usb_serial_generic_read_bulk_callback - nonzero read bulk status received: 
> -84

Either way, the error is EILSEQ (-84) which usually indicates hardware
problems.

[...]

> There are 2 beasty questions left:
> 1. Why it works with PL2303H ?

Different device, different hardware.

> 2. Why i receive sometimes the first bytes?

Your particular device could be flakey and sometimes you're able to
read a few bytes.

> > Now that you have compiled your own kernel, you could run a git bisect
> > to learn if anything else has changed in the kernel (possibly
> > interacting with your test setup) which can explain why things
> > stopped working.
> 
> I learned much in kernel testing the last time ... :-)
> Maybe there is a HowTo for the bisect testing?

I don't have any good pointers at hand except for the git documentation
of git-bisect.
 
But perhaps you don't need to do a bisect. If the hardware is broken
then knowing which performance increase in the kernel pushed it over the
edge isn't really gonna be of much use as the driver is still working
with other HX-devices (I have one here).

If you still want to pursue this, you should try to reproduce the error
on a v3.8 kernel (look in the logs for errors from
usb_serial_generic_read_bulk_callback). Then you could try to reduce the
bulk-in and out buffer sizes in the driver (simply comment out those
fields in the pl2303_device struct) and perhaps also to reduce the
number of read and write urbs (I can tell you how later).

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: Driver for PL-2303 HX not working

[Karsten Malcher]

Hi Johan,

Am 19.04.2013 11:04, schrieb Johan Hovold:

This was a log with lost data.
The logs seems to make politics. ;-)

Then the problem is most likely not in the driver as the characters are
being read back in the log you provided.


Stop - it's really possible that i send not enough bytes.
Sometimes up to 6 Bytes will come back.

This time i send this string (3.2.0):
"1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890\n"
I get back the first 3 Bytes of it.
Log is attached.

Before closing the connection Perl sends a  'stty -aF /dev/ttyUSB0' and prints 
the result:

speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 16;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke


canonical-mode is not enabled and I get back 3 bytes - so data is not lost 
complete.
With cutecom it's -icanon also. So everything should be fine.

There are 2 beasty questions left:
1. Why it works with PL2303H ?
2. Why i receive sometimes the first bytes?



Now that you have compiled your own kernel, you could run a git bisect
to learn if anything else has changed in the kernel (possibly
interacting with your test setup) which can explain why things
stopped working.


I learned much in kernel testing the last time ... :-)
Maybe there is a HowTo for the bisect testing?


Your kernel is not configured to use dynamic debugging. You need to
enable CONFIG_DYNAMIC_DEBUG=y.


Oh - then i must compile again.
I found
   # CONFIG_DYNAMIC_DEBUG is not set
in .config.



Johan


Karsten

[ 1443.104346] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_install
[ 1443.104363] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_open - port 0
[ 1443.104366] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open -  port 0
[ 1443.104581] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x8:0x0  0
[ 1443.106606] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x9:0x0  0
[ 1443.106619] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios -  port 0
[ 1443.108584] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0  7 - 80 25 0 0 0 0 8
[ 1443.108594] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - data bits = 8
[ 1443.108603] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - baud requested = 9600
[ 1443.108611] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - baud set = 9600
[ 1443.108618] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - stop bits = 1
[ 1443.108625] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - parity = none
[ 1443.110595] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x21:0x20:0:0  7
[ 1443.112584] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0  7 - 80 25 0 0 0 0 8
[ 1443.114595] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x0:0x0  0
[ 1443.114605] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - submitting read urb
[ 1443.114627] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - submitting interrupt urb
[ 1443.116581] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: set_control_lines - value = 3, retval = 0
[ 1443.116821] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401
[ 1443.116832] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401
[ 1443.116841] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5401
[ 1443.116903] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401
[ 1443.116913] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401
[ 1443.116922

Re: [PATCH] usbatm: fix potential NULL pointer dereference

[Duncan Sands]

Signed-off-by: Duncan Sands 

On 19/04/13 04:18, Wei Yongjun wrote:

From: Wei Yongjun 

The dereference to 'instance' in the debug code should be moved
below the NULL test.

Signed-off-by: Wei Yongjun 
---
  drivers/usb/atm/usbatm.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/atm/usbatm.c b/drivers/usb/atm/usbatm.c
index 35f10bf..d3527dd 100644
--- a/drivers/usb/atm/usbatm.c
+++ b/drivers/usb/atm/usbatm.c
@@ -672,9 +672,6 @@ static int usbatm_atm_send(struct atm_vcc *vcc, struct 
sk_buff *skb)
struct usbatm_control *ctrl = UDSL_SKB(skb);
int err;

-   vdbg(&instance->usb_intf->dev, "%s called (skb 0x%p, len %u)", __func__,
-skb, skb->len);
-
/* racy disconnection check - fine */
if (!instance || instance->disconnected) {
  #ifdef DEBUG
@@ -684,6 +681,9 @@ static int usbatm_atm_send(struct atm_vcc *vcc, struct 
sk_buff *skb)
goto fail;
}

+   vdbg(&instance->usb_intf->dev, "%s called (skb 0x%p, len %u)", __func__,
+skb, skb->len);
+
if (vcc->qos.aal != ATM_AAL5) {
atm_rldbg(instance, "%s: unsupported ATM type %d!\n", __func__, 
vcc->qos.aal);
err = -EINVAL;



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

Re: [PATCH v3 0/6] Generic PHY Framework

[Sekhar Nori]

Hi Kishon,

On 3/20/2013 2:41 PM, Kishon Vijay Abraham I wrote:
> Added a generic PHY framework that provides a set of APIs for the PHY drivers
> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
> the PHY with or without using phandle. To obtain a reference to the PHY
> without using phandle, the platform specfic intialization code (say from board
> file) should have already called phy_bind with the binding information. The
> binding information consists of phy's device name, phy user device name and an
> index. The index is used when the same phy user binds to mulitple phys.
> 
> This framework will be of use only to devices that uses external PHY (PHY
> functionality is not embedded within the controller).

>From a top level what you are doing looks closely related to External
connector (extcon).

I understand a connector is not the same as a phy, but it will still be
useful to know why extcon framework (or some extension of it) will not
suffice your needs.

You can probably note it in the cover-letter so folks like me get their
answer.

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

Re: [PATCH v3 1/6] drivers: phy: add generic PHY framework

[Grant Likely]

On Tue, 16 Apr 2013 15:48:07 +0530, Kishon Vijay Abraham I  
wrote:
> On Tuesday 16 April 2013 01:20 AM, Grant Likely wrote:
> > On Mon, 15 Apr 2013 17:56:10 +0530, Kishon Vijay Abraham I  
> > wrote:
> >> On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
> >>> On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I 
> >>>  wrote:
> >> We have decided not to implement the PHY layer as a separate bus layer.
> >> The PHY provider can be part of any other bus. Making the PHY layer as a
> >> bus will make the PHY provider to be part of multiple buses which will
> >> lead to bad design. All we are trying to do here is keep the pool of PHY
> >> devices under PHY class in this layer and help any controller that wants
> >> to use the PHY to get it.
> >
> > If you're using a class, then you already have your list of registered
> > phy devices! :-) No need to create another global list that you need to
> > manage.
> 
> right. We already use _class_dev_iter_ for finding the phy device.
> .
> .
> +static struct phy *of_phy_lookup(struct device *dev, struct device_node 
> *node)
> +{
> + struct phy *phy;
> + struct class_dev_iter iter;
> +
> + class_dev_iter_init(&iter, phy_class, NULL, NULL);
> + while ((dev = class_dev_iter_next(&iter))) {
> + phy = container_of(dev, struct phy, dev);
> + if (node != phy->of_node)
> + continue;
> +
> + class_dev_iter_exit(&iter);
> + return phy;
> + }
> +
> + class_dev_iter_exit(&iter);
> + return ERR_PTR(-EPROBE_DEFER);
> +}
> .
> .
> 
> however we can't get rid of the other list (phy_bind_list) where we 
> maintain the phy binding information. It's used for the non-dt boot case.

Why? If you're using a class, then it is always there. Why would non-DT
and DT be different in this regard? (more below)

> >>> Since there is at most a 1:N relationship between host controllers and
> >>> PHYs, there shouldn't be any need for a separate structure to describe
> >>> binding. Put the inding data into the struct phy itself. Each host
> >>> controller can have a list of phys that it is bound to.
> >>
> >> No. Having the host controller to have a list of phys wont be a good
> >> idea IMHO. The host controller is just an IP and the PHY to which it
> >> will be connected can vary from board to board, platform to platform. So
> >> ideally this binding should come from platform initialization code/dt data.
> >
> > That is not what I mean. I mean the host controller instance should
> > contain a list of all the PHYs that are attached to it. There should not
> 
> Doesn't sound correct IMO. The host controller instance need not know 
> anything about the PHY instances that is connected to it. Think of it 
> similar to regulator, the controller wouldn't know which regulator it is 
> connected to, all it has to know is it just has a regulator connected to 
> it. It's up-to the regulator framework to give the controller the 
> correct regulator. It's similar here. It makes sense for me to keep a 
> list in the PHY framework in order for it to return the correct PHY (but 
> note that this list is not needed for dt boot).

With regulators and clocks it makes sense to have a global
registration place becase both implement an interconnected network
independent of the device that use them. (clocks depend on other clocks;
regulators depend on other regulators).

Phys are different. There is a 1:N relationship between host controllers
and phys, and you don't get a interconnected network of PHYs. Its a bad
idea to keep the binding data separate from the actual host controller
when there is nothing else that actually needs to use the data. It
creates a new set of data structures that need housekeeping to keep them
in sync with the actual device structures. It really is just a bad idea
and it becomes more difficult (in the non-DT case) to determine what
data is associated with a given host controller. You can't tell by
looking at the struct device.

Instead, for the non-DT case, do what we've always done for describing
connections. Put the phy reference into the host controllers
platform_data structure. That is what it is there for. That completely
eliminates the need to housekeep a new set of data structures.

g.
--
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: Driver for PL-2303 HX not working

[Johan Hovold]

On Fri, Apr 19, 2013 at 10:36:57AM +0200, Karsten Malcher wrote:
> Am 18.04.2013 12:56, schrieb Johan Hovold:
> >
> > Can you generate a log where bytes are actually lost? Nothing seemed to
> > get lost in the previous log you posted.
> 
> This was a log with lost data.
> The logs seems to make politics. ;-)

Then the problem is most likely not in the driver as the characters are
being read back in the log you provided.

Now that you have compiled your own kernel, you could run a git bisect
to learn if anything else has changed in the kernel (possibly
interacting with your test setup) which can explain why things
stopped working.

I would suggest that you convince yourself that your minimal test setup
is correct first, though. Perhaps using the same minimal program (init,
write, read) on a working pl2303 device if you have one.

> >> How can i enable the debugging in kernel 3.8.5?
> > Make sure debugfs is mounted:
> >
> > mount -t debugfs none /sys/kernel/debug
> >
> > and then enable debugging:
> >
> > echo "module usbserial +p">/sys/kernel/debug/dynamic_debug/control
> > echo "module pl2303 +p">/sys/kernel/debug/dynamic_debug/control
> >
> > Johan
> 
> Sorry - this does not work for me?
> 
> root@PC# mount -t debugfs none /sys/kernel/debug
> 
> root@PC# mount
> sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
> proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
> udev on /dev type devtmpfs 
> (rw,relatime,size=10240k,nr_inodes=1014924,mode=755)
> devpts on /dev/pts type devpts 
> (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
> tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=819796k,mode=755)
> /dev/disk/by-uuid/5166cbb1-8234-4127-bb0b-bbfda1658b68 on / type ext4 
> (rw,relatime,errors=remount-ro,data=ordered)
> tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
> tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1679740k)
> fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
> none on /sys/kernel/debug type debugfs (rw,relatime)
> 
> root@PC# echo "module usbserial +p" >/sys/kernel/debug/dynamic_debug/control
> bash: /sys/kernel/debug/dynamic_debug/control: Datei oder Verzeichnis nicht 
> gefunden

Your kernel is not configured to use dynamic debugging. You need to
enable CONFIG_DYNAMIC_DEBUG=y.

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: Driver for PL-2303 HX not working

[Johan Hovold]

On Fri, Apr 19, 2013 at 09:25:19AM +0200, Karsten Malcher wrote:
> Am 18.04.2013 11:35, schrieb Johan Hovold:
> >> I have used a little perl program that opens the port and send "Test"
> >> to the looped back device.
> >> The length of the log looks good.
> > Great. Now I can see what's going on. The only problem (?) is that
> > everything seems to be working. The write succeeds and the four bytes
> > are read back as they should by the driver.
> 
> But where the data has gone?
> With cutecom i can see that some of the first bytes are looped back.
> 
> It must be possible to read any binary (streamed) data.

Yes, but not in canonical mode as then the input is buffered by the
kernel tty-layer until certain characters are encountered.

> > The first thing that comes to mind that could prevent you from reading
> > the received data would be if the tty device is configured for canonical
> > input processing. Have you made sure this is not the case? Can you read
> > the data back if you add a newline to your test string (e.g. "test\n")?
> 
> Hmmn - i don't know which method is used by programs like cutecom or putty?

Unless it's configurable it should be non-canonical mode.

> But i know everything works fine before.
> In this programs every data is terminated with newline, but it does not work.

You mean that you updated your test program so that it writes "test\n"
but it still does not work?

> >> I use this script with a ch341 adapter and it works.
> > Hmmm. Did you remember to initialise the device (e.g. set the termios
> > flags)?
> 
> Here you can see what's initialized in Perl:
> 
> use Device::SerialPort 0.12;
> 
> $port->baudrate(9600)   || die "failed setting baudrate";
> $port->parity("none")|| die "failed setting parity";
> $port->databits(8)   || die "failed setting databits";
> $port->handshake("none") || die "failed setting handshake";
> $port->write_settings|| die "could not write settings";
> $port->lookclear || die "could not empty buffer";
> $port->read_char_time(0);# don't wait for each character
> $port->read_const_time(1000);# 1 second per unfulfilled "read" call
> my $STALL_DEFAULT = 1;# how many seconds to wait for new input

I don't use perl so can't help you there. Search for perl and icanon or
something.

You can use stty to determine if canonical-mode is enabled; the output
of 'stty -aF /dev/ttyUSB0' contains "icanon" if enabled and "-icanon"
otherwise. By default it is enabled. 

You should also make sure that VMIN and VTIME are initialised in
non-canonical mode. Specifically, if VMIN is greater than the number of
characters written by your test program over the loopback and VTIME is
0, read will block also in non-canonical mode.

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: Driver for PL-2303 HX not working

[Karsten Malcher]

Am 18.04.2013 12:56, schrieb Johan Hovold:


Can you generate a log where bytes are actually lost? Nothing seemed to
get lost in the previous log you posted.


This was a log with lost data.
The logs seems to make politics. ;-)


How can i enable the debugging in kernel 3.8.5?

Make sure debugfs is mounted:

mount -t debugfs none /sys/kernel/debug

and then enable debugging:

echo "module usbserial +p">/sys/kernel/debug/dynamic_debug/control
echo "module pl2303 +p">/sys/kernel/debug/dynamic_debug/control

Johan


Sorry - this does not work for me?

root@PC# mount -t debugfs none /sys/kernel/debug

root@PC# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1014924,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=819796k,mode=755)
/dev/disk/by-uuid/5166cbb1-8234-4127-bb0b-bbfda1658b68 on / type ext4 
(rw,relatime,errors=remount-ro,data=ordered)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1679740k)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
none on /sys/kernel/debug type debugfs (rw,relatime)

root@PC# echo "module usbserial +p" >/sys/kernel/debug/dynamic_debug/control
bash: /sys/kernel/debug/dynamic_debug/control: Datei oder Verzeichnis nicht 
gefunden

root@PC# ls -l /sys/kernel/debug
insgesamt 0
drwx-- 14 root root 0 Apr 19 10:27 .
drwxr-xr-x  6 root root 0 Apr 19 10:27 ..
drwxr-xr-x  2 root root 0 Apr 19 10:27 acpi
drwxr-xr-x 17 root root 0 Apr 19 10:27 bdi
drwxr-xr-x  2 root root 0 Apr 19 10:27 extfrag
-r--r--r--  1 root root 0 Apr 19 10:27 gpio
drwxr-xr-x  4 root root 0 Apr 19 10:27 hid
drwxr-xr-x  2 root root 0 Apr 19 10:27 kprobes
drwxr-xr-x  2 root root 0 Apr 19 10:27 kvm
drwxr-xr-x  2 root root 0 Apr 19 10:27 mce
drwxr-xr-x  2 root root 0 Apr 19 10:27 regmap
drwxr-xr-x  3 root root 0 Apr 19 10:27 regulator
-rw-r--r--  1 root root 0 Apr 19 10:27 sched_features
-r--r--r--  1 root root 0 Apr 19 10:27 suspend_stats
drwxr-xr-x  5 root root 0 Apr 19 10:27 tracing
drwxr-xr-x  2 root root 0 Apr 19 10:27 usb
-r--r--r--  1 root root 0 Apr 19 10:27 wakeup_sources
drwxr-xr-x  2 root root 0 Apr 19 10:27 x86

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

Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active

[Oliver Neukum]

On Thursday 18 April 2013 11:51:25 Ming Lei wrote:
> On Wed, Apr 17, 2013 at 2:55 PM, Oliver Neukum  wrote:
>
> > If we have a function for starting a status URB we want to use it whenever
> > it applies, that is also when we need to poll status for internal reason 
> > while
> > an interface is up.
> 
> For other non-sierra usbnet devices, when an interface is up, the status URB
> is scheduled in open() and needn't the API.

But that is the very point. This API is used from _within_ open.
We cannot make every open() use GFP_NOIO

> > You don't need to understand it any more than you need to understand
> > the rule for usb_submit_urb(). The rules are the very same. There is no
> > special effort here.
> 
> No, there isn't one rule for the corner case here, and the corner case should
> have existed in probe() or cancel queue with reset of all USB drivers, instead
> of usbnet only.

The same rule applies to usb_submit_urb(), too.
 
> Also the rule 3 is a bit obscure, maybe not correct, at least there are much
> GFP_KERNEL usages in kthread of usbnet. I am wondering if there are
> other usbnet specific memflags rules except for 1 & 6.
> 
> Strictly speaking, the rule 5 isn't correct, since it might trigger the corner
> case you mentioned, right?
> 
> I think we need to review the memflags part of usb_submit_urb() doc now.

Yes.

> +int usbnet_status_start(struct usbnet *dev, gfp_t mem_flags)
> +{
> +   int ret = 0;
> +
> +   WARN_ON_ONCE(dev->interrupt == NULL);
> +   if (dev->interrupt) {
> +   mutex_lock(&dev->interrupt_mutex);
> 
> 
> 
> +}
> 
> Obviously, the API can't be called in atomic context, and putting runtime PM
> inside is reasonable and correct.

Yes, but how is it relevant. What allows us to conclude that a driver does not 
want
runtime PM while a status URB is running?

> > I meant block suspend in the sense of disallowing it. Which is very 
> > problematic.
> > The CDC protocols generally support remote wakeup for status information,
> > so we need to be able to sleep while status is running to accomodate devices
> > which are intended to be always online.
> 
> At least now, for non-sierra drivers, it needn't the API to schedule status 
> URB
> which will be started in normal open() path, so won't power on device runtime
> unnecessarily. That is what I say the API shouldn't be for a general usage, 
> :-)

But many drivers, e.g. cdc-ether, cdc-ncm and cdc-mbim want to be able
to runtime suspend while the device is open.

Regards
Oliver

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

Re: Driver for PL-2303 HX not working

[Karsten Malcher]

Am 18.04.2013 11:35, schrieb Johan Hovold:

I have used a little perl program that opens the port and send "Test"
to the looped back device.
The length of the log looks good.

Great. Now I can see what's going on. The only problem (?) is that
everything seems to be working. The write succeeds and the four bytes
are read back as they should by the driver.


But where the data has gone?
With cutecom i can see that some of the first bytes are looped back.

It must be possible to read any binary (streamed) data.



The first thing that comes to mind that could prevent you from reading
the received data would be if the tty device is configured for canonical
input processing. Have you made sure this is not the case? Can you read
the data back if you add a newline to your test string (e.g. "test\n")?


Hmmn - i don't know which method is used by programs like cutecom or putty?
But i know everything works fine before.
In this programs every data is terminated with newline, but it does not work.

I use this script with a ch341 adapter and it works.

Hmmm. Did you remember to initialise the device (e.g. set the termios
flags)?


Here you can see what's initialized in Perl:

use Device::SerialPort 0.12;

$port->baudrate(9600)   || die "failed setting baudrate";
$port->parity("none")|| die "failed setting parity";
$port->databits(8)   || die "failed setting databits";
$port->handshake("none") || die "failed setting handshake";
$port->write_settings|| die "could not write settings";
$port->lookclear || die "could not empty buffer";
$port->read_char_time(0);# don't wait for each character
$port->read_const_time(1000);# 1 second per unfulfilled "read" call
my $STALL_DEFAULT = 1;# how many seconds to wait for new input


Cheers
Karsten



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