Re: [PATCH 0/2] usb: exynos: Fix compatible strings used for device

[Vivek Gautam]

On Thu, Dec 27, 2012 at 4:28 AM, Sylwester Nawrocki
sylvester.nawro...@gmail.com wrote:
 On 12/24/2012 09:13 AM, Vivek Gautam wrote:

 These two changes look good to me.  For both of them:

 Reviewed-by: Doug Andersondiand...@chromium.org


 Well, I have another idea. Yes, I know, specific chip name should be
 used.

 But

 you know the specific chip name in compatible can cause another
 confusion
 on other SoC which has same IP. So I think, we need to consider to use
 common name or any specific name not chip in compatible for IP/driver
 like
 following?

 - { .compatible = samsung,exynos-dwc3 },
 + { .compatible = samsung,synopsis-dwc3 },

 Or if any version or something, how about following?

 + { .compatible = samsung,dwc-v3 },

 Well, yes the newer SoCs with same IP using the chip name can cause some
 confusion, but won't it be fine that -
 Newer parts using the same core can claim compatibility by
 including the older string in the compatible list - as quoted by Grant
 Likely

 Or, can we try another option, using multiple compatible strings for
 SoC specific
 in of_match_table, so that we don't create any confusion by using same
 compatible for newer SoCs also. Like,

 - { .compatible = samsung,exynos-dwc3 },
 + { .compatible = samsung,exynos5250-dwc3 },
 + { .compatible =new SoC using same IP  },


 Yes, why not just use an SoC name where given IP first appeared ? I believe
 IP revision numbers are not always well documented. Also when an IP is
 instantiated multiple times in specific SoC, its revision number might not
 be sufficient to determine the system integration details for each instance.
 I think having version for some devices and SoC name for others just adds
 to the confusion. Thus using specific chip name in the compatible property
 seems more clear to me.


Ping !!


-- 
Thanks  Regards
Vivek
--
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] CDC_NCM adding support IFF_NOARP for infineon modem platform

[Bjørn Mork]

David Miller da...@davemloft.net writes:
 From: Dan Williams d...@redhat.com
 
 IFF_NOARP is already done for other WWAN devices (sierra_net, hso,
 cdc-ether, cdc-phonet, lg-vl600, etc) so there is some precedent.  Some
 drivers (phonet, hso) set *both* POINTTOPOINT and NOARP.  Is that
 redundant, and should all WWAN drivers be moved to only POINTTOPOINT?
 
 (aside: usbnet has FLAG_POINTTOPOINT, but that's nothing to do with
 IFF_POINTTOPOINT, it only controls whether the interface is named usbX
 or ethX.  Confusing.)

 I can't answer any of your questions unless you tell me what the
 real limitation of these devices is.

 For the second time, is the problem that these devices cannot
 support broadcast packets properly?

The main problem is that these devices don't support ethernet.  They
support IP (v4 and _maybe_ v6) with an ethernet header.  Many of them
will do ARP (and IPv6 ND) as well to complete the picture, but some of
them don't and that's what these drivers try to deal with.

Note that most of the devices will run a DHCP server, so there is some
sort of IP broadcast support.  Whether that qualifies as proper ethernet
broadcast support is another question...

These devices are attempting to bridge an IP-only point-to-point
interface and an ethernet over USB interface, with the intention to make
the point-to-point interface look like ethernet to applications and
users. This is of course always going to be imperfect.  But I believe
that we should aim to help the firmware achive this goal when writing
drivers instead of working against it.  Setting IFF_NOARP and not
IFF_POINTTOPOINT is one way to do that.



Bjørn
--
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

[RFC PATCH 6/7] ARM: dts: omap: Add omap-usb2 dt data

[Kishon Vijay Abraham I]

Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
connected to ocp2scp, omap-usb2 dt data is added as a child node
of ocp2scp.

Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/boot/dts/omap4.dtsi |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 7bbf1fb..b7e2ba3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -438,6 +438,10 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
+   usb2phy@4a0ad080 {
+   compatible = ti,omap-usb2;
+   reg = 0x4a0ad080 0x58;
+   };
};
 
timer1: timer@4a318000 {
-- 
1.7.9.5

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

[RFC PATCH 5/7] ARM: dts: omap: Add usb_otg and glue data

[Kishon Vijay Abraham I]

Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-board.dts file.
The dt data specifies among others the interface type (ULPI or UTMI), mode
which is mostly OTG, power that specifies the amount of power this can supply
when in host mode.

Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/boot/dts/omap3-beagle-xm.dts |6 ++
 arch/arm/boot/dts/omap3-evm.dts   |6 ++
 arch/arm/boot/dts/omap3-overo.dtsi|6 ++
 arch/arm/boot/dts/omap3.dtsi  |   11 +++
 arch/arm/boot/dts/omap4-panda.dts |6 ++
 arch/arm/boot/dts/omap4-sdp.dts   |6 ++
 arch/arm/boot/dts/omap4.dtsi  |   12 
 7 files changed, 53 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3705a81..cb07583 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -107,3 +107,9 @@
 */
ti,pulldowns = 0x03a1c4;
 };
+
+usb_otg_hs {
+   interface_type = 0;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..afb9ba9 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -59,3 +59,9 @@
 twl_gpio {
ti,use-leds;
 };
+
+usb_otg_hs {
+   interface_type = 0;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
b/arch/arm/boot/dts/omap3-overo.dtsi
index 89808ce..4b3d157 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -55,3 +55,9 @@
 twl_gpio {
ti,use-leds;
 };
+
+usb_otg_hs {
+   interface_type = 0;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..8d03736 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,16 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+   usb_otg_hs: usb_otg_hs@480ab000 {
+   compatible = ti,omap3-musb;
+   reg = 0x480ab000 0x1000;
+   interrupts = 0 92 0x4, 0 93 0x4;
+   interrupt-names = mc, dma;
+   ti,hwmods = usb_otg_hs;
+   multipoint = 1;
+   num_eps = 16;
+   ram_bits = 12;
+   };
};
 };
diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..612c9bb 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -206,3 +206,9 @@
 twl_usb_comparator {
usb-supply = vusb;
 };
+
+usb_otg_hs {
+   interface_type = 1;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..582d7ee 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -428,3 +428,9 @@
 twl_usb_comparator {
usb-supply = vusb;
 };
+
+usb_otg_hs {
+   interface_type = 1;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..7bbf1fb 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,17 @@
ti,hwmods = timer11;
ti,timer-pwm;
};
+
+   usb_otg_hs: usb_otg_hs@4a0ab000 {
+   compatible = ti,omap4-musb;
+   reg = 0x4a0ab000 0x7ff;
+   interrupts = 0 92 0x4, 0 93 0x4;
+   interrupt-names = mc, dma;
+   ti,hwmods = usb_otg_hs;
+   multipoint = 1;
+   num_eps = 16;
+   ram_bits = 12;
+   ti,has_mailbox;
+   };
};
 };
-- 
1.7.9.5

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

[RFC PATCH 3/7] ARM: OMAP2: MUSB: Specify omap4 has mailbox

[Kishon Vijay Abraham I]

Added has_mailbox to the musb platform data to specify that omap uses
an external mailbox (in control module) to communicate with the musb
core during device connect and disconnect.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/mach-omap2/usb-musb.c |3 +++
 include/linux/usb/musb.h   |2 ++
 2 files changed, 5 insertions(+)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 7b33b37..9d27e3f 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,6 +85,9 @@ void __init usb_musb_init(struct omap_musb_board_data 
*musb_board_data)
musb_plat.mode = board_data-mode;
musb_plat.extvbus = board_data-extvbus;
 
+   if (cpu_is_omap44xx())
+   musb_plat.has_mailbox = true;
+
if (soc_is_am35xx()) {
oh_name = am35x_otg_hs;
name = musb-am35x;
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index eb50525..053c268 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -99,6 +99,8 @@ struct musb_hdrc_platform_data {
/* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
u8  mode;
 
+   u8  has_mailbox:1;
+
/* for clk_get() */
const char  *clock;
 
-- 
1.7.9.5

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

[RFC PATCH 2/7] ARM: OMAP: devices: create device for usb part of control module

[Kishon Vijay Abraham I]

A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mailbox.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/mach-omap2/devices.c |   50 +
 1 file changed, 50 insertions(+)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5e304d0..a761faf4 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -20,6 +20,7 @@
 #include linux/pinctrl/machine.h
 #include linux/platform_data/omap4-keypad.h
 #include linux/platform_data/omap_ocp2scp.h
+#include linux/usb/omap_control_usb.h
 
 #include asm/mach-types.h
 #include asm/mach/map.h
@@ -254,6 +255,54 @@ static inline void omap_init_camera(void)
 #endif
 }
 
+#if (defined(CONFIG_OMAP_CONTROL_USB) || \
+   defined(CONFIG_OMAP_CONTROL_USB_MODULE))
+
+static struct omap_control_usb_platform_data omap4_control_usb_pdata = {
+   .has_mailbox = true,
+};
+
+struct resource omap4_control_usb_res[] = {
+   {
+   .name   = control_dev_conf,
+   .start  = 0x4a002300,
+   .end= 0x4a002303,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .name   = otghs_control,
+   .start  = 0x4a00233c,
+   .end= 0x4a00233f,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device omap4_control_usb = {
+   .name   = omap-control-usb,
+   .id = -1,
+   .dev = {
+   .platform_data = omap4_control_usb_pdata,
+   },
+   .num_resources = 2,
+   .resource = omap4_control_usb_res,
+};
+
+static inline void __init omap_init_control_usb(void)
+{
+   int ret = 0;
+
+   if (cpu_is_omap44xx()) {
+   ret = platform_device_register(omap4_control_usb);
+   if (ret)
+   pr_err(Error registering omap_control_usb device: %d\n
+   , ret);
+   }
+}
+
+#else
+static inline void omap_init_control_usb(void) { }
+#endif /* CONFIG_OMAP_CONTROL_USB */
+
 int __init omap4_keyboard_init(struct omap4_keypad_platform_data
*sdp4430_keypad_data, struct omap_board_data *bdata)
 {
@@ -721,6 +770,7 @@ static int __init omap2_init_devices(void)
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
+   omap_init_control_usb();
omap_init_dmic();
omap_init_mcpdm();
omap_init_mcspi();
-- 
1.7.9.5

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

[RFC PATCH 0/7] usb: musb: add driver for control module

[Kishon Vijay Abraham I]

Added a new driver for the usb part of control module. This has an API
to power on the USB2 phy and an API to write to the mailbox depending on
whether MUSB has to act in host mode or in device mode.

Writing to control module registers for doing the above task which was
previously done in omap glue and in omap-usb2 phy is removed.

Also added the dt data to get MUSB working in OMAP platforms.
This series has patches for both drivers and ARCH folders, so If it has to
be split I'll do it.

This series was developed on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv

Did basic enumeration testing in omap4 beagle, omap4 sdp and omap3 beagle.

Kishon Vijay Abraham I (7):
  drivers: usb: phy: add a new driver for usb part of control module
  ARM: OMAP: devices: create device for usb part of control module
  ARM: OMAP2: MUSB: Specify omap4 has mailbox
  drivers: usb: start using the control module driver
  ARM: dts: omap: Add usb_otg and glue data
  ARM: dts: omap: Add omap-usb2 dt data
  ARM: dts: omap: Add omap control usb data

 Documentation/devicetree/bindings/usb/omap-usb.txt |   25 ++-
 Documentation/devicetree/bindings/usb/usb-phy.txt  |7 +-
 arch/arm/boot/dts/omap3-beagle-xm.dts  |6 +
 arch/arm/boot/dts/omap3-evm.dts|6 +
 arch/arm/boot/dts/omap3-overo.dtsi |6 +
 arch/arm/boot/dts/omap3.dtsi   |   11 ++
 arch/arm/boot/dts/omap4-panda.dts  |6 +
 arch/arm/boot/dts/omap4-sdp.dts|6 +
 arch/arm/boot/dts/omap4.dtsi   |   24 +++
 arch/arm/mach-omap2/devices.c  |   50 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   13 --
 arch/arm/mach-omap2/usb-musb.c |3 +
 drivers/usb/musb/Kconfig   |1 +
 drivers/usb/musb/omap2430.c|   64 +++---
 drivers/usb/musb/omap2430.h|9 -
 drivers/usb/phy/Kconfig|   10 +
 drivers/usb/phy/Makefile   |1 +
 drivers/usb/phy/omap-control-usb.c |  204 
 drivers/usb/phy/omap-usb2.c|   38 +---
 include/linux/usb/musb.h   |2 +
 include/linux/usb/omap_control_usb.h   |   73 +++
 include/linux/usb/omap_usb.h   |4 +-
 22 files changed, 469 insertions(+), 100 deletions(-)
 create mode 100644 drivers/usb/phy/omap-control-usb.c
 create mode 100644 include/linux/usb/omap_control_usb.h

-- 
1.7.9.5

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

[RFC PATCH 7/7] ARM: dts: omap: Add omap control usb data

[Kishon Vijay Abraham I]

Add omap control usb data in omap4 device tree file. This will have the
register address of registers to power on the PHY and to write to
mailbox.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/boot/dts/omap4.dtsi |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index b7e2ba3..5d770be 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -545,5 +545,13 @@
ram_bits = 12;
ti,has_mailbox;
};
+
+   omap_control_usb@4a002300 {
+   compatible = ti,omap-control-usb;
+   reg = 0x4a002300 0x4,
+ 0x4a00233c 0x4;
+   reg-names = control_dev_conf, otghs_control;
+   ti,has_mailbox;
+   };
};
 };
-- 
1.7.9.5

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

[RFC PATCH 4/7] drivers: usb: start using the control module driver

[Kishon Vijay Abraham I]

Start using the control module driver for powering on the PHY and for
writing to the mailbox instead of writing to the control module
registers on their own.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |4 ++
 Documentation/devicetree/bindings/usb/usb-phy.txt  |7 +--
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   13 
 drivers/usb/musb/Kconfig   |1 +
 drivers/usb/musb/omap2430.c|   64 
 drivers/usb/musb/omap2430.h|9 ---
 drivers/usb/phy/Kconfig|1 +
 drivers/usb/phy/omap-usb2.c|   38 +++-
 include/linux/usb/omap_usb.h   |4 +-
 9 files changed, 42 insertions(+), 99 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index d58dae3..3f0152b 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -3,6 +3,9 @@ OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
 OMAP MUSB GLUE
  - compatible : Should be ti,omap4-musb or ti,omap3-musb
  - ti,hwmods : must be usb_otg_hs
+ - ti,has_mailbox : to specify that omap uses an external mailbox
+   (in control module) to communicate with the musb core during device connect
+   and disconnect.
  - multipoint : Should be 1 indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
  - num_eps : Specifies the number of endpoints. This is also a
@@ -20,6 +23,7 @@ SOC specific device node entry
 usb_otg_hs: usb_otg_hs@4a0ab000 {
compatible = ti,omap4-musb;
ti,hwmods = usb_otg_hs;
+   ti,has_mailbox;
multipoint = 1;
num_eps = 16;
ram_bits = 12;
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt 
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 80d4148..ee14cb7 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -4,14 +4,11 @@ OMAP USB2 PHY
 
 Required properties:
  - compatible: Should be ti,omap-usb2
- - reg : Address and length of the register set for the device. Also
-add the address of control module dev conf register until a driver for
-control module is added
+ - reg : Address and length of the register set for the device.
 
 This is usually a subnode of ocp2scp to which it is connected.
 
 usb2phy@4a0ad080 {
compatible = ti,omap-usb2;
-   reg = 0x4a0ad080 0x58,
- 0x4a002300 0x4;
+   reg = 0x4a0ad080 0x58;
 };
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 129d508..103f4ba 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2698,13 +2698,6 @@ static struct resource omap44xx_usb_phy_and_pll_addrs[] 
= {
.end= 0x4a0ae000,
.flags  = IORESOURCE_MEM,
},
-   {
-   /* XXX: Remove this once control module driver is in place */
-   .name   = ctrl_dev,
-   .start  = 0x4a002300,
-   .end= 0x4a002303,
-   .flags  = IORESOURCE_MEM,
-   },
{ }
 };
 
@@ -6152,12 +6145,6 @@ static struct omap_hwmod_addr_space 
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab7ff,
.flags  = ADDR_TYPE_RT
},
-   {
-   /* XXX: Remove this once control module driver is in place */
-   .pa_start   = 0x4a00233c,
-   .pa_end = 0x4a00233f,
-   .flags  = ADDR_TYPE_RT
-   },
{ }
 };
 
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 23a0b7f..de6e5ce 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -11,6 +11,7 @@ config USB_MUSB_HDRC
select NOP_USB_XCEIV if (SOC_TI81XX || SOC_AM33XX)
select TWL4030_USB if MACH_OMAP_3430SDP
select TWL6030_USB if MACH_OMAP_4430SDP || MACH_OMAP4_PANDA
+   select OMAP_CONTROL_USB if MACH_OMAP_4430SDP || MACH_OMAP4_PANDA
select USB_OTG_UTILS
help
  Say Y here if your system has a dual role high speed USB
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index da00af4..3e7ceef 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -37,6 +37,7 @@
 #include linux/err.h
 #include linux/delay.h
 #include linux/usb/musb-omap.h
+#include linux/usb/omap_control_usb.h
 
 #include musb_core.h
 #include omap2430.h
@@ -46,7 +47,7 @@ struct omap2430_glue {
struct platform_device  *musb;
enum omap_musb_vbus_id_status status;
struct work_struct  omap_musb_mailbox_work;
-   u32 __iomem 

[RFC PATCH 1/7] drivers: usb: phy: add a new driver for usb part of control module

[Kishon Vijay Abraham I]

Added a new driver for the usb part of control module. This has an API
to power on the USB2 phy and an API to write to the mailbox depending on
whether MUSB has to act in host mode or in device mode.

Writing to control module registers for doing the above task which was
previously done in omap glue and in omap-usb2 phy will be removed.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |   21 +-
 drivers/usb/phy/Kconfig|9 +
 drivers/usb/phy/Makefile   |1 +
 drivers/usb/phy/omap-control-usb.c |  204 
 include/linux/usb/omap_control_usb.h   |   73 +++
 5 files changed, 307 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/phy/omap-control-usb.c
 create mode 100644 include/linux/usb/omap_control_usb.h

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..d58dae3 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP GLUE
+OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
 
 OMAP MUSB GLUE
  - compatible : Should be ti,omap4-musb or ti,omap3-musb
@@ -31,3 +31,22 @@ Board specific device node entry
mode = 3;
power = 50;
 };
+
+OMAP CONTROL USB
+
+Required properties:
+ - compatible: Should be ti,omap-control-usb
+ - reg : Address and length of the register set for the device. It contains
+   the address of control_dev_conf and otghs_control.
+ - reg-names: The names of the register addresses corresponding to the 
registers
+   filled in reg.
+ - ti,has_mailbox: This is used to specify if the platform uses mailbox in
+   control module.
+
+omap_control_usb@4a002300 {
+   compatible = ti,omap-control-usb;
+   reg = 0x4a002300 0x4,
+ 0x4a00233c 0x4;
+   reg-names = control_dev_conf, otghs_control;
+   ti,has_mailbox;
+};
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 5de6e7f..a7277ee 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -14,6 +14,15 @@ config OMAP_USB2
  The USB OTG controller communicates with the comparator using this
  driver.
 
+config OMAP_CONTROL_USB
+   tristate OMAP CONTROL USB Driver
+   depends on ARCH_OMAP2PLUS
+   help
+ Enable this to add support for the USB part present in the control
+ module. This driver has API to power on the PHY and to write to the
+ mailbox. The mailbox is present only in omap4 and the register to
+ power on the PHY is present in omap4 and omap5.
+
 config USB_ISP1301
tristate NXP ISP1301 USB transceiver support
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 1a579a8..0dea4d2 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -5,6 +5,7 @@
 ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
 
 obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o
+obj-$(CONFIG_OMAP_CONTROL_USB) += omap-control-usb.o
 obj-$(CONFIG_USB_ISP1301)  += isp1301.o
 obj-$(CONFIG_MV_U3D_PHY)   += mv_u3d_phy.o
 obj-$(CONFIG_USB_EHCI_TEGRA)   += tegra_usb_phy.o
diff --git a/drivers/usb/phy/omap-control-usb.c 
b/drivers/usb/phy/omap-control-usb.c
new file mode 100644
index 000..bed41a9
--- /dev/null
+++ b/drivers/usb/phy/omap-control-usb.c
@@ -0,0 +1,204 @@
+/*
+ * omap-control-usb.c - The USB part of control module.
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/err.h
+#include linux/io.h
+#include linux/usb/omap_control_usb.h
+
+static struct omap_control_usb *control_usb;
+
+/**
+ * get_omap_control_dev - returns the device pointer for this control device
+ *
+ * This API should be called to get the device pointer for this control
+ * module device. This device pointer should be passed to all other API's
+ * in this driver.
+ *
+ * To be used by PHY driver and glue driver
+ */
+struct device *get_omap_control_dev(void)
+{
+   if (!control_usb)
+   return ERR_PTR(-ENODEV);
+
+   return control_usb-dev;
+}
+EXPORT_SYMBOL_GPL(get_omap_control_dev);
+
+/**
+ * 

[PATCH net] net: qmi_wwan: add TP-LINK HSUPA Modem MA180

[Bjørn Mork]

The driver description files gives these names to the vendor specific
functions on this modem:

 Diagnostics VID_2357PID_0201MI_00
 NMEAVID_2357PID_0201MI_01
 Modem   VID_2357PID_0201MI_03
 Networkcard VID_2357PID_0201MI_04

The Networkcard function has been verified to support these QMI
services:
ctl (1.3)
wds (1.3)
dms (1.2)
nas (1.0)

Reported-by: Thomas Schäfer tschae...@t-online.de
Signed-off-by: Bjørn Mork bj...@mork.no
---
 drivers/net/usb/qmi_wwan.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 6a1ca50..c434108 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -459,6 +459,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x68a2, 19)},   /* Sierra Wireless MC7710 in 
QMI mode */
{QMI_FIXED_INTF(0x1199, 0x901c, 8)},/* Sierra Wireless EM7700 */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
(Alcatel One Touch L100V LTE) */
+   {QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
 
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
-- 
1.7.10.4

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

Re: TP-LINK HSUPA Modem MA180 2357:0201

[Bjørn Mork]

Thomas Schäfer tschae...@t-online.de writes:

 Here are all infos about this device. I think I catched the relevant data.

 Switching to modem/network-mode works with 

 eject /dev/sr0

 It works with option 
 /dev/ttyUSB2 has accepted at-commands

 and qmi_wwan (in testcase with interface 1 instead of 0)

 I was able get an IPv4- connection via qmi-interface.

 I was not able to get online via IPv6.

 qmi-version-infos are also inside the attachment.


 This is, what windows says about this device:

 Diagnostics USB\VID_2357PID_0201MI_00\637BC1CE00
 NMEAUSB\VID_2357PID_0201MI_01\637BC1CE01

 Modem   USB\VID_2357PID_0201MI_03\637BC1CE03
 Networkcard USB\VID_2357PID_0201MI_04\637BC1CE04


 mmc 
 USBSTOR\CDROMVEN_TP-LINKPROD_MMC_STORAGEREV_2.31\77ED6A6108630770103305650


 Labels at the housing:

 MA180
 FCC ID: T7MA180V2
 IC: 8853-MA180V1


 Windows-software at the stick is identical to 
 http://www.tp-link.com.de/Resources/software/MA180_V1_Easy_Setup_Assistant.zip
 (same md5)

Thanks a lot for the extra-ordinary complete and detailed report.  I've
just submitted the two patches this ends up as.  Given the amount of
work you put into collection all the info, you could have submitted
those patches yourself to save you some of the work :-)


Bjørn
--
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 RESEND usb-linus] USB: option: add TP-LINK HSUPA Modem MA180

[Bjørn Mork]

The driver description files gives these names to the vendor specific
functions on this modem:

 Diagnostics VID_2357PID_0201MI_00
 NMEAVID_2357PID_0201MI_01
 Modem   VID_2357PID_0201MI_03
 Networkcard VID_2357PID_0201MI_04

Reported-by: Thomas Schäfer tschae...@t-online.de
Signed-off-by: Bjørn Mork bj...@mork.no
---
Resending due to an address typo.  Sorry for the duplicates.


 drivers/usb/serial/option.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 478adcf..ae598a6 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -449,6 +449,10 @@ static void option_instat_callback(struct urb *urb);
 #define PETATEL_VENDOR_ID  0x1ff4
 #define PETATEL_PRODUCT_NP10T  0x600e
 
+/* TP-LINK Incorporated products */
+#define TPLINK_VENDOR_ID   0x2357
+#define TPLINK_PRODUCT_MA180   0x0201
+
 /* some devices interfaces need special handling due to a number of reasons */
 enum option_blacklist_reason {
OPTION_BLACKLIST_NONE = 0,
@@ -1311,6 +1315,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 
MEDIATEK_PRODUCT_DC_4COM2, 0xff, 0x00, 0x00) },
{ USB_DEVICE(CELLIENT_VENDOR_ID, CELLIENT_PRODUCT_MEN200) },
{ USB_DEVICE(PETATEL_VENDOR_ID, PETATEL_PRODUCT_NP10T) },
+   { USB_DEVICE(TPLINK_VENDOR_ID, TPLINK_PRODUCT_MA180),
+ .driver_info = (kernel_ulong_t)net_intf4_blacklist },
{ } /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, option_ids);
-- 
1.7.10.4

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

Re: [PATCH] HID: add support for Sony RF receiver with USB product id 0x0374

[Antonio Ospite]

On Tue, 15 Jan 2013 12:43:48 +0900
Fernando Luis Vázquez Cao  fernando...@lab.ntt.co.jp wrote:

Hi Fernando,

 Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
 a RF receiver, multi-interface USB device 054c:0374, that is used to connect
 a wireless keyboard and a wireless mouse.
 
 The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not
 seem to be generating any pointer events. The problem is that the mouse 
 pointer
 is wrongly declared as a constant non-data variable in the report descriptor
 (see lsusb and usbhid-dump output below), with the consenquence that it is

typo: consequence

 ignored by the HID code.
 
 Add this device to the have-special-driver list and fix up the report
 descriptor in the Sony-specific driver which happens to already have a fixup
 for a similar firmware bug.
 
 # lsusb -vd 054C:0374
 Bus 003 Device 002: ID 054c:0374 Sony Corp.
 Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   2.00
   bDeviceClass0 (Defined at Interface level)
   bDeviceSubClass 0
   bDeviceProtocol 0
   bMaxPacketSize0 8
   idVendor   0x054c Sony Corp.
   idProduct  0x0374
   iSerial 0
 [...]
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber1
   bAlternateSetting   0
   bNumEndpoints   1
   bInterfaceClass 3 Human Interface Device
   bInterfaceSubClass  1 Boot Interface Subclass
   bInterfaceProtocol  2 Mouse
   iInterface  2 RF Receiver
 [...]
   Report Descriptor: (length is 100)
 Item(Global): Usage Page, data= [ 0x01 ] 1
 Generic Desktop Controls
 Item(Local ): Usage, data= [ 0x30 ] 48
 Direction-X
 Item(Local ): Usage, data= [ 0x31 ] 49
 Direction-Y
 Item(Global): Report Count, data= [ 0x02 ] 2
 Item(Global): Report Size, data= [ 0x08 ] 8
 Item(Global): Logical Minimum, data= [ 0x81 ] 129
 Item(Global): Logical Maximum, data= [ 0x7f ] 127
 Item(Main  ): Input, data= [ 0x07 ] 7
 Constant Variable Relative No_Wrap Linear
 Preferred_State No_Null_Position Non_Volatile 
 Bitfield
 
 # sudo usbhid-dump
 
 003:002:001:DESCRIPTOR 1357910009.758544
  05 01 09 02 A1 01 05 01 09 02 A1 02 85 01 09 01
  A1 00 05 09 19 01 29 05 95 05 75 01 15 00 25 01
  81 02 75 03 95 01 81 01 05 01 09 30 09 31 95 02
  75 08 15 81 25 7F 81 07 A1 02 85 01 09 38 35 00
  45 00 15 81 25 7F 95 01 75 08 81 06 C0 A1 02 85
  01 05 0C 15 81 25 7F 95 01 75 08 0A 38 02 81 06
  C0 C0 C0 C0
 
 Cc: linux-in...@vger.kernel.org
 Cc: linux-usb@vger.kernel.org
 Cc: linux-ker...@vger.kernel.org
 Signed-off-by: Fernando Luis Vazquez Cao ferna...@oss.ntt.co.jp
 ---
 
 diff -urNp linux-3.8-rc3-orig/drivers/hid/hid-core.c 
 linux-3.8-rc3/drivers/hid/hid-core.c
 --- linux-3.8-rc3-orig/drivers/hid/hid-core.c 2013-01-13 20:54:36.846952518 
 +0900
 +++ linux-3.8-rc3/drivers/hid/hid-core.c  2013-01-13 18:21:19.901347327 
 +0900
 @@ -1697,6 +1697,7 @@ static const struct hid_device_id hid_ha
   { HID_USB_DEVICE(USB_VENDOR_ID_SONY, 
 USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER) },
   { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, 
 USB_DEVICE_ID_SONY_PS3_CONTROLLER) },
   { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE) 
 },
 + { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGP_MOUSE) 
 },
   { HID_USB_DEVICE(USB_VENDOR_ID_SUNPLUS, USB_DEVICE_ID_SUNPLUS_WDESKTOP) 
 },
   { HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb300) },
   { HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb304) },
 diff -urNp linux-3.8-rc3-orig/drivers/hid/hid-ids.h 
 linux-3.8-rc3/drivers/hid/hid-ids.h
 --- linux-3.8-rc3-orig/drivers/hid/hid-ids.h  2013-01-13 20:54:36.850952537 
 +0900
 +++ linux-3.8-rc3/drivers/hid/hid-ids.h   2013-01-13 18:21:19.901347327 
 +0900
 @@ -706,6 +706,7 @@
  
  #define USB_VENDOR_ID_SONY   0x054c
  #define USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE0x024b
 +#define USB_DEVICE_ID_SONY_VAIO_VGP_MOUSE0x0374
  #define USB_DEVICE_ID_SONY_PS3_BDREMOTE  0x0306
  #define USB_DEVICE_ID_SONY_PS3_CONTROLLER0x0268
  #define USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER 0x042f
 diff -urNp linux-3.8-rc3-orig/drivers/hid/hid-sony.c 
 linux-3.8-rc3/drivers/hid/hid-sony.c
 --- linux-3.8-rc3-orig/drivers/hid/hid-sony.c 2012-12-11 12:30:57.0 
 +0900
 +++ linux-3.8-rc3/drivers/hid/hid-sony.c  2013-01-13 18:21:19.901347327 
 +0900
 @@ -44,19 +44,21 @@ static __u8 *sony_report_fixup(struct hi
   struct sony_sc *sc = hid_get_drvdata(hdev);
  
   if ((sc-quirks  VAIO_RDESC_CONSTANT) 
 - *rsize = 56  

Re: [PATCH] HID: add support for Sony RF receiver with USB product id 0x0374

[Fernando Luis Vazquez Cao]

Hi Antonio,

On 2013/01/15 18:36, Antonio Ospite wrote:

On Tue, 15 Jan 2013 12:43:48 +0900 Fernando Luis Vázquez Cao  
fernando...@lab.ntt.co.jp wrote:

diff -urNp linux-3.8-rc3-orig/drivers/hid/hid-sony.c 
linux-3.8-rc3/drivers/hid/hid-sony.c
--- linux-3.8-rc3-orig/drivers/hid/hid-sony.c   2012-12-11 12:30:57.0 
+0900
+++ linux-3.8-rc3/drivers/hid/hid-sony.c2013-01-13 18:21:19.901347327 
+0900
@@ -44,19 +44,21 @@ static __u8 *sony_report_fixup(struct hi
struct sony_sc *sc = hid_get_drvdata(hdev);
  
  	if ((sc-quirks  VAIO_RDESC_CONSTANT) 

-   *rsize = 56  rdesc[54] == 0x81  rdesc[55] == 0x07) 
{
-   hid_info(hdev, Fixing up Sony Vaio VGX report descriptor\n);
+   *rsize = 56  rdesc[54] == 0x81  rdesc[55] == 0x07) {
+   hid_info(hdev,
+Fixing up Sony RF Receiver report descriptor\n);

Changing the message does make sense, but try to avoid mixing
functional changes with style changes (I am referring to the change of
indentation here).


Oops, that was unintended. I will be replying to this email with an 
updated version.


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

[PATCH 2/6] arm: mvebu: Enable USB controllers on Armada 370 evaluation board

[Ezequiel Garcia]

Cc: Lior Amsalem al...@marvell.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
 arch/arm/boot/dts/armada-370-db.dts |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts 
b/arch/arm/boot/dts/armada-370-db.dts
index 8e66a7c..3d93902 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -74,5 +74,13 @@
status = disabled;
/* No CD or WP GPIOs */
};
+
+   usb@d005 {
+   status = okay;
+   };
+
+   usb@d0051000 {
+   status = okay;
+   };
};
 };
-- 
1.7.8.6

--
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 4/6] arm: mvebu: Enable USB controllers on Armada XP evaluation board

[Ezequiel Garcia]

Cc: Lior Amsalem al...@marvell.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
 arch/arm/boot/dts/armada-xp-db.dts |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-db.dts 
b/arch/arm/boot/dts/armada-xp-db.dts
index c7035c5..c84e1fe 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -97,5 +97,17 @@
status = okay;
/* No CD or WP GPIOs */
};
+
+   usb@d005 {
+   status = okay;
+   };
+
+   usb@d0051000 {
+   status = okay;
+   };
+
+   usb@d0052000 {
+   status = okay;
+   };
};
 };
-- 
1.7.8.6

--
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 5/6] arm: mvebu: Enable USB controllers on Armada XP OpenBlocks AX3-4 board

[Ezequiel Garcia]

Cc: Lior Amsalem al...@marvell.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts 
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index b24644f..55f5b6f 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -127,5 +127,14 @@
nr-ports = 2;
status = okay;
};
+   usb@d005 {
+   status = okay;
+   };
+   usb@d0051000 {
+   status = okay;
+   };
+   usb@d0052000 {
+   status = okay;
+   };
};
 };
-- 
1.7.8.6

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

[PATCH 1/6] arm: mvebu: Add support for USB host controllers in Armada 370/XP

[Ezequiel Garcia]

The Armada 370 and Armada XP SoC has an Orion EHCI USB controller.
This patch adds support for this controller in Armada 370
and Armada XP SoC common device tree files.

Cc: Lior Amsalem al...@marvell.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
 arch/arm/boot/dts/armada-370-xp.dtsi |   15 +++
 arch/arm/boot/dts/armada-370.dtsi|9 +
 arch/arm/boot/dts/armada-xp.dtsi |   17 +
 arch/arm/mach-mvebu/Kconfig  |1 +
 4 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 28276fe..fa025c4 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -145,6 +145,21 @@
clocks = gateclk 17;
status = disabled;
};
+
+   usb@d005 {
+   compatible = marvell,orion-ehci;
+   reg = 0xd005 0x500;
+   interrupts = 45;
+   status = disabled;
+   };
+
+   usb@d0051000 {
+   compatible = marvell,orion-ehci;
+   reg = 0xd0051000 0x500;
+   interrupts = 46;
+   status = disabled;
+   };
+
};
 };
 
diff --git a/arch/arm/boot/dts/armada-370.dtsi 
b/arch/arm/boot/dts/armada-370.dtsi
index 88f9bab..8188d13 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -144,5 +144,14 @@
dmacap,memset;
};
};
+
+   usb@d005 {
+   clocks = coreclk 0;
+   };
+
+   usb@d0051000 {
+   clocks = coreclk 0;
+   };
+
};
 };
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 390ba98..1443949 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -134,5 +134,22 @@
dmacap,memset;
};
};
+
+   usb@d005 {
+   clocks = gateclk 18;
+   };
+
+   usb@d0051000 {
+   clocks = gateclk 19;
+   };
+
+   usb@d0052000 {
+   compatible = marvell,orion-ehci;
+   reg = 0xd0052000 0x500;
+   interrupts = 47;
+   clocks = gateclk 20;
+   status = disabled;
+   };
+
};
 };
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 440b13e..5e4fcde 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -24,6 +24,7 @@ config MACH_ARMADA_370_XP
select HAVE_SMP
select CACHE_L2X0
select CPU_PJ4B
+   select USB_ARCH_HAS_EHCI if USB_SUPPORT
 
 config MACH_ARMADA_370
bool Marvell Armada 370 boards
-- 
1.7.8.6

--
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 6/6] arm: mvebu: Update defconfig to select USB support

[Ezequiel Garcia]

Cc: Lior Amsalem al...@marvell.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
 arch/arm/configs/mvebu_defconfig |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index c3c6326..f8d0183 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -42,7 +42,10 @@ CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_DW=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIO_SYSFS=y
-# CONFIG_USB_SUPPORT is not set
+CONFIG_USB_SUPPORT=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_ROOT_HUB_TT=y
 CONFIG_MMC=y
 CONFIG_MMC_MVSDIO=y
 CONFIG_RTC_CLASS=y
-- 
1.7.8.6

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

[PATCH 0/6] arm: mvebu: Add support for USB host controllers in Armada 370/XP

[Ezequiel Garcia]

Hi,

This small patch set enables USB support on Armada 370 and Armada XP platforms.
It's based on Jason Cooper's mvebu/dt branch.

Any comments or feedback are welcome.

Ezequiel Garcia (6):
 arm: mvebu: Add support for USB host controllers in Armada 370/XP
 arm: mvebu: Enable USB controllers on Armada 370 evaluation board
 arm: mvebu: Enable USB controllers on Armada 370 Mirabox board
 arm: mvebu: Enable USB controllers on Armada XP evaluation board
 arm: mvebu: Enable USB controllers on Armada XP OpenBlocks AX3-4 board
 arm: mvebu: Update defconfig to select USB support

 arch/arm/boot/dts/armada-370-db.dts  |8 
 arch/arm/boot/dts/armada-370-mirabox.dts |8 
 arch/arm/boot/dts/armada-370-xp.dtsi |   15 +++
 arch/arm/boot/dts/armada-370.dtsi|9 +
 arch/arm/boot/dts/armada-xp-db.dts   |   12 
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |9 +
 arch/arm/boot/dts/armada-xp.dtsi |   17 +
 arch/arm/configs/mvebu_defconfig |5 -
 arch/arm/mach-mvebu/Kconfig  |1 +
 9 files changed, 83 insertions(+), 1 deletions(-)
 
Thanks!

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: phy: remove unused APIs from Tegra PHY.

[Venu Byravarasu]

As tegra_usb_phy_clk_disable/enable() are not being
used, removing them.

Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com
---
 drivers/usb/phy/tegra_usb_phy.c   |   13 -
 include/linux/usb/tegra_usb_phy.h |4 
 2 files changed, 0 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/phy/tegra_usb_phy.c b/drivers/usb/phy/tegra_usb_phy.c
index 2d3cae9..3059384 100644
--- a/drivers/usb/phy/tegra_usb_phy.c
+++ b/drivers/usb/phy/tegra_usb_phy.c
@@ -825,16 +825,3 @@ void tegra_ehci_phy_restore_end(struct tegra_usb_phy *phy)
 }
 EXPORT_SYMBOL_GPL(tegra_ehci_phy_restore_end);
 
-void tegra_usb_phy_clk_disable(struct tegra_usb_phy *phy)
-{
-   if (!phy_is_ulpi(phy))
-   utmi_phy_clk_disable(phy);
-}
-EXPORT_SYMBOL_GPL(tegra_usb_phy_clk_disable);
-
-void tegra_usb_phy_clk_enable(struct tegra_usb_phy *phy)
-{
-   if (!phy_is_ulpi(phy))
-   utmi_phy_clk_enable(phy);
-}
-EXPORT_SYMBOL_GPL(tegra_usb_phy_clk_enable);
diff --git a/include/linux/usb/tegra_usb_phy.h 
b/include/linux/usb/tegra_usb_phy.h
index 176b1ca..34e6355 100644
--- a/include/linux/usb/tegra_usb_phy.h
+++ b/include/linux/usb/tegra_usb_phy.h
@@ -64,10 +64,6 @@ struct tegra_usb_phy {
 struct tegra_usb_phy *tegra_usb_phy_open(struct device *dev, int instance,
void __iomem *regs, void *config, enum tegra_usb_phy_mode phy_mode);
 
-void tegra_usb_phy_clk_disable(struct tegra_usb_phy *phy);
-
-void tegra_usb_phy_clk_enable(struct tegra_usb_phy *phy);
-
 void tegra_usb_phy_preresume(struct tegra_usb_phy *phy);
 
 void tegra_usb_phy_postresume(struct tegra_usb_phy *phy);
-- 
1.7.0.4

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

Re: [PATCH 1/6] arm: mvebu: Add support for USB host controllers in Armada 370/XP

[Florian Fainelli]

Hello Ezequiel,

Le 01/15/13 10:54, Ezequiel Garcia a écrit :

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 440b13e..5e4fcde 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -24,6 +24,7 @@ config MACH_ARMADA_370_XP
select HAVE_SMP
select CACHE_L2X0
select CPU_PJ4B
+   select USB_ARCH_HAS_EHCI if USB_SUPPORT


I do not think this is actually required because ARCH_MVEBU selects 
PLAT_ORION and in drivers/usb/host/Kconfig, USB_ARCH_HAS_EHCI is default 
y if PLAT_ORION. Having USB_ARCH_HAS_EHCI without USB_SUPPORT enabled is 
pretty harmless.

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

[PATCH] usb: dwc3: Remove dwc3 dependency on host AND gadget.

[Vivek Gautam]

DWC3 controller curretly depends on USB  USB_GADGET.
Some hardware may like to use only host feature on dwc3,
or only gadget feature.
So, removing this dependency of USB_DWC3 on USB and USB_GADGET.
Adding the mode of operaiton of DWC3 also here
HOST/GADGET/DUAL_ROLE based on which features are enabled.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
CC: Doug Anderson diand...@chromium.org
---

This patch is outcome of discussion happened on:
[PATCH RFC] usb: dwc3: Remove dwc3 dependency on gadget
http://comments.gmane.org/gmane.linux.ports.arm.omap/91328

Changes from RFC:
- Making both HOST as well as GADGET optional for dwc3.
- Adding mode of working of DWC3 controller here:
  HOST/GADGET/DUAL_ROLE
- Build gadget related features for debugfs in dwc3_debugfs_init()
  only with USB_DWC3_GADGET or USB_DWC3_DUAL_ROLE.

 drivers/usb/dwc3/Kconfig   |   31 +--
 drivers/usb/dwc3/Makefile  |   10 --
 drivers/usb/dwc3/core.h|   16 +++-
 drivers/usb/dwc3/debugfs.c |2 ++
 4 files changed, 54 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index f6a6e07..418d058 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -1,6 +1,6 @@
-config USB_DWC3
+menuconfig USB_DWC3
tristate DesignWare USB3 DRD Core Support
-   depends on (USB  USB_GADGET)
+   depends on (USB || USB_GADGET)
select USB_OTG_UTILS
select USB_XHCI_PLATFORM if USB_SUPPORT  USB_XHCI_HCD
help
@@ -12,6 +12,33 @@ config USB_DWC3
 
 if USB_DWC3
 
+choice
+   bool DWC3 mode of working
+   default USB_DWC3_DUAL_ROLE
+
+config USB_DWC3_HOST
+   bool Host only mode
+   depends on USB
+   help
+ Select this when you want to use DWC3 in host mode only,
+ thereby the gadget feature will be regressed.
+
+config USB_DWC3_GADGET
+   bool Gadget only mode
+   depends on USB_GADGET
+   help
+ Select this when you want to use DWC3 in gadget mode only,
+ thereby the host feature will be regressed.
+
+config USB_DWC3_DUAL_ROLE
+   bool Dual role mode
+   depends on (USB  USB_GADGET)
+   help
+ This is the default mode of working of DWC3 controller where
+ both host and gadget features are enabled.
+
+endchoice
+
 config USB_DWC3_DEBUG
bool Enable Debugging Messages
help
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 4502648..0c7ac92 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -4,8 +4,14 @@ ccflags-$(CONFIG_USB_DWC3_VERBOSE) += -DVERBOSE_DEBUG
 obj-$(CONFIG_USB_DWC3) += dwc3.o
 
 dwc3-y := core.o
-dwc3-y += host.o
-dwc3-y += gadget.o ep0.o
+
+ifneq ($(filter y,$(CONFIG_USB_DWC3_HOST) $(CONFIG_USB_DWC3_DUAL_ROLE)),)
+   dwc3-y  += host.o
+endif
+
+ifneq ($(filter y,$(CONFIG_USB_DWC3_GADGET) $(CONFIG_USB_DWC3_DUAL_ROLE)),)
+   dwc3-y  += gadget.o ep0.o
+endif
 
 ifneq ($(CONFIG_DEBUG_FS),)
dwc3-y  += debugfs.o
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 5f79d9f..829b11b 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -864,10 +864,24 @@ union dwc3_event {
 void dwc3_set_mode(struct dwc3 *dwc, u32 mode);
 int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc);
 
+#if defined CONFIG_USB_DWC3_HOST || defined CONFIG_USB_DWC3_DUAL_ROLE
 int dwc3_host_init(struct dwc3 *dwc);
 void dwc3_host_exit(struct dwc3 *dwc);
-
+#else
+static inline int dwc3_host_init(struct dwc3 *dwc)
+{ return 0; }
+static inline void dwc3_host_exit(struct dwc3 *dwc)
+{ }
+#endif
+
+#if defined CONFIG_USB_DWC3_GADGET || defined CONFIG_USB_DWC3_DUAL_ROLE
 int dwc3_gadget_init(struct dwc3 *dwc);
 void dwc3_gadget_exit(struct dwc3 *dwc);
+#else
+static inline int dwc3_gadget_init(struct dwc3 *dwc)
+{ return 0; }
+static inline void dwc3_gadget_exit(struct dwc3 *dwc)
+{ }
+#endif
 
 #endif /* __DRIVERS_USB_DWC3_CORE_H */
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index d4a30f1..fc0af8b 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -673,6 +673,7 @@ int __devinit dwc3_debugfs_init(struct dwc3 *dwc)
goto err1;
}
 
+#if defined CONFIG_USB_DWC3_GADGET || defined CONFIG_USB_DWC3_DUAL_ROLE
file = debugfs_create_file(mode, S_IRUGO | S_IWUSR, root,
dwc, dwc3_mode_fops);
if (!file) {
@@ -693,6 +694,7 @@ int __devinit dwc3_debugfs_init(struct dwc3 *dwc)
ret = -ENOMEM;
goto err1;
}
+#endif
 
return 0;
 
-- 
1.7.6.5

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

[PATCH v2] HID: add support for Sony RF receiver with USB product id 0x0374

[Fernando Luis Vázquez Cao]

Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
a RF receiver, multi-interface USB device 054c:0374, that is used to connect
a wireless keyboard and a wireless mouse.

The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not
seem to be generating any pointer events. The problem is that the mouse pointer
is wrongly declared as a constant non-data variable in the report descriptor
(see lsusb and usbhid-dump output below), with the consequence that it is
ignored by the HID code.

Add this device to the have-special-driver list and fix up the report
descriptor in the Sony-specific driver which happens to already have a fixup
for a similar firmware bug.

# lsusb -vd 054C:0374
Bus 003 Device 002: ID 054c:0374 Sony Corp.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x054c Sony Corp.
  idProduct  0x0374
  iSerial 0
[...]
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  1 Boot Interface Subclass
  bInterfaceProtocol  2 Mouse
  iInterface  2 RF Receiver
[...]
  Report Descriptor: (length is 100)
[...]
Item(Global): Usage Page, data= [ 0x01 ] 1
Generic Desktop Controls
Item(Local ): Usage, data= [ 0x30 ] 48
Direction-X
Item(Local ): Usage, data= [ 0x31 ] 49
Direction-Y
Item(Global): Report Count, data= [ 0x02 ] 2
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Logical Minimum, data= [ 0x81 ] 129
Item(Global): Logical Maximum, data= [ 0x7f ] 127
Item(Main  ): Input, data= [ 0x07 ] 7
Constant Variable Relative No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile 
Bitfield

# usbhid-dump
003:002:001:DESCRIPTOR 1357910009.758544
 05 01 09 02 A1 01 05 01 09 02 A1 02 85 01 09 01
 A1 00 05 09 19 01 29 05 95 05 75 01 15 00 25 01
 81 02 75 03 95 01 81 01 05 01 09 30 09 31 95 02
 75 08 15 81 25 7F 81 07 A1 02 85 01 09 38 35 00
 45 00 15 81 25 7F 95 01 75 08 81 06 C0 A1 02 85
 01 05 0C 15 81 25 7F 95 01 75 08 0A 38 02 81 06
 C0 C0 C0 C0

Cc: linux-in...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Fernando Luis Vazquez Cao ferna...@oss.ntt.co.jp
---

diff -urNp linux-3.8-rc3-orig/drivers/hid/hid-core.c 
linux-3.8-rc3/drivers/hid/hid-core.c
--- linux-3.8-rc3-orig/drivers/hid/hid-core.c   2013-01-10 11:59:55.0 
+0900
+++ linux-3.8-rc3/drivers/hid/hid-core.c2013-01-15 19:32:22.189574034 
+0900
@@ -1697,6 +1697,7 @@ static const struct hid_device_id hid_ha
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, 
USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, 
USB_DEVICE_ID_SONY_PS3_CONTROLLER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE) 
},
+   { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGP_MOUSE) 
},
{ HID_USB_DEVICE(USB_VENDOR_ID_SUNPLUS, USB_DEVICE_ID_SUNPLUS_WDESKTOP) 
},
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb300) },
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb304) },
diff -urNp linux-3.8-rc3-orig/drivers/hid/hid-ids.h 
linux-3.8-rc3/drivers/hid/hid-ids.h
--- linux-3.8-rc3-orig/drivers/hid/hid-ids.h2013-01-10 11:59:55.0 
+0900
+++ linux-3.8-rc3/drivers/hid/hid-ids.h 2013-01-15 19:32:22.189574034 +0900
@@ -706,6 +706,7 @@
 
 #define USB_VENDOR_ID_SONY 0x054c
 #define USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE  0x024b
+#define USB_DEVICE_ID_SONY_VAIO_VGP_MOUSE  0x0374
 #define USB_DEVICE_ID_SONY_PS3_BDREMOTE0x0306
 #define USB_DEVICE_ID_SONY_PS3_CONTROLLER  0x0268
 #define USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER   0x042f
diff -urNp linux-3.8-rc3-orig/drivers/hid/hid-sony.c 
linux-3.8-rc3/drivers/hid/hid-sony.c
--- linux-3.8-rc3-orig/drivers/hid/hid-sony.c   2013-01-10 11:59:55.0 
+0900
+++ linux-3.8-rc3/drivers/hid/hid-sony.c2013-01-15 19:35:57.858683185 
+0900
@@ -45,7 +45,7 @@ static __u8 *sony_report_fixup(struct hi
 
if ((sc-quirks  VAIO_RDESC_CONSTANT) 
*rsize = 56  rdesc[54] == 0x81  rdesc[55] == 0x07) 
{
-   hid_info(hdev, Fixing up Sony Vaio VGX report descriptor\n);
+   hid_info(hdev, Fixing up Sony RF Receiver report 
descriptor\n);
rdesc[55] = 0x06;
}
 
@@ -217,6 +217,8 @@ static 

Re: [PATCH 1/6] arm: mvebu: Add support for USB host controllers in Armada 370/XP

[Ezequiel Garcia]

Hi Florian,

On 01/15/2013 07:23 AM, Florian Fainelli wrote:
 Le 01/15/13 10:54, Ezequiel Garcia a écrit :
 diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
 index 440b13e..5e4fcde 100644
 --- a/arch/arm/mach-mvebu/Kconfig
 +++ b/arch/arm/mach-mvebu/Kconfig
 @@ -24,6 +24,7 @@ config MACH_ARMADA_370_XP
   select HAVE_SMP
   select CACHE_L2X0
   select CPU_PJ4B
 +select USB_ARCH_HAS_EHCI if USB_SUPPORT
 
 I do not think this is actually required because ARCH_MVEBU selects 
 PLAT_ORION and in drivers/usb/host/Kconfig, USB_ARCH_HAS_EHCI is default y if 
 PLAT_ORION. Having USB_ARCH_HAS_EHCI without USB_SUPPORT enabled is pretty 
 harmless.

Yes, you're right, this is not needed.

Nice catch and thanks for the review,

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: close blocks, if FIFO full on gagdet serial

[Petr Masek]

Hi Felipe,
thank you for advice.

I've looked at your patch and it makes quite sense to me. But 
surprisingly, it doesn't help. So I've done a small investigation and 
I've added printk into gs_flush_chars and discovered, that it is never 
called.


I suppose, that calling tcflush(fd, TCOFLUSH) should lead to calling 
this function, but it does not. I'm not experienced in kernel 
architecture, so I'm limited in further investigation. But if you'll 
have some other clues, I'd gladly try them.


I'm also not sure about the when this timeout occurs. You mention that 
it is in gs_start_tx, but I've found it only in gs_close:


if (gs_buf_data_avail(port-port_write_buf)  0  gser) {
spin_unlock_irq(port-port_lock);
wait_event_interruptible_timeout(port-drain_wait,
gs_writes_finished(port),
GS_CLOSE_TIMEOUT * HZ);
spin_lock_irq(port-port_lock);
gser = port-port_usb;
}

Where GS_CLOSE_TIMEOUT is set to 15.

Personally, I've set GS_CLOSE_TIMEOUT to 0 and it suits perfectly for 
me. By the way, don't you think, taht 15 seconds is soo long timeout for 
flushing 8k buffer over usb? Even ordinary serial port set to 9600bd 
should transfer this amount of data twice. Would not 1s or even less do 
the job as well?


Nevertheless, I guess, that we should discover, where the problem lies 
and proper flushing should be added.


thanks and best regards

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

Re: [PATCH v2 1/4] ARM i.MX6: use reserved bit for mxs phy clock gate

[Shawn Guo]

On Tue, Jan 15, 2013 at 02:08:34PM +0800, Peter Chen wrote:
 For mxs-phy user i.mx6q, the PHY's clock is controlled by
 hardware automatically, the software only needs to enable it
 at probe, disable it at remove. During the runtime,
 we don't need to control it. So for the usbphy clk policy:
 
 - Keep refcount for usbphy as clk framework needs to know if
 it is off or on.

Just checked the reference manual, it seems that not only bit 6
(EN_USB_CLKS) but also bit 12 (POWER) are controlled by USB hardware.
If this is true, I think that PLL3 and PLL7 are really designed for
USB PHY use only.  Do you actually see other real users of these two
PLLs on imx6q besides USB PHY?  If not, we can just provide a dummy
clock to mxs-phy driver on imx6q, and keep real clocks usbphy1 and
usbphy2 there for platform init function to enable them if USB support
is built in.  Then, we can save all these dirty hacks.  Thoughts?

Shawn

 - Use reserved bit, in that case, clk_enable/disable will
 only update refcount, but without any hardware effects.
 
 Signed-off-by: Peter Chen peter.c...@freescale.com
 ---
 Changes for v2:
 - Use reserved bit for usb phy clk control
 
  arch/arm/mach-imx/clk-imx6q.c |   10 --
  1 files changed, 8 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
 index 7f2c10c..85dcc89 100644
 --- a/arch/arm/mach-imx/clk-imx6q.c
 +++ b/arch/arm/mach-imx/clk-imx6q.c
 @@ -208,8 +208,14 @@ int __init mx6q_clocks_init(void)
   clk[pll7_usb_host] = imx_clk_pllv3(IMX_PLLV3_USB,   
 pll7_usb_host,osc, base + 0x20, 0x3);
   clk[pll8_mlb]  = imx_clk_pllv3(IMX_PLLV3_MLB,   pll8_mlb, 
 osc, base + 0xd0, 0x0);
  
 - clk[usbphy1] = imx_clk_gate(usbphy1, pll3_usb_otg, base + 0x10, 6);
 - clk[usbphy2] = imx_clk_gate(usbphy2, pll7_usb_host, base + 0x20, 6);
 + /*
 +  * Bit 20 is the reserved and read-only bit, we do this only for:
 +  * - Do nothing for usbphy clk_enable/disable
 +  * - Keep refcount when do usbphy clk_enable/disable, in that case,
 +  * the clk framework can know the USB phy clk is on or off
 +  */
 + clk[usbphy1] = imx_clk_gate(usbphy1, pll3_usb_otg, base + 0x10, 20);
 + clk[usbphy2] = imx_clk_gate(usbphy2, pll7_usb_host, base + 0x20, 
 20);
  
   clk[sata_ref] = imx_clk_fixed_factor(sata_ref, pll6_enet, 1, 5);
   clk[pcie_ref] = imx_clk_fixed_factor(pcie_ref, pll6_enet, 1, 4);
 -- 
 1.7.0.4
 
 

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

Re: [PATCH 06/30] usb/gadget: add some infracture to register/unregister functions

[Sebastian Andrzej Siewior]

* Andrzej Pietrasiewicz | 2013-01-03 16:37:45 [+0100]:

Hello Sebastian,
Hello Andrzej,

On Sunday, December 23, 2012 9:10 PM Sebastian Andrzej Siewior wrote:

 Subject: [PATCH 06/30] usb/gadget: add some infracture to
 register/unregister functions
 
 This patch provides an infrastructure to register  unregister a USB
 function. This allows to turn a function into a module and avoid the
 '#include f_.*.c' magic and we get a clear API / cut between the bare
 gadget and its functions.
 The concept is simple:
 Each function defines the DECLARE_USB_FUNCTION_INIT macro whith an unique
 name of the function and two allocation functions.
 - one to create an instance. The instance holds the current
 configuration
   set. In case there are two usb_configudations with one function there
 will
   be one instance and two usb_functions
 - one to create an function from the instance.
 

This naming scheme seems confusing when compared with the
object-oriented (OO) parlance. In OO there is a class which
can be instantiated in many instances. It is exactly the opposite
here: there is one instance for which many functions can be created.

The idea of having this instance struct is not bad itself.
As far as I understand it there are usb_function_drivers, which are
used to keep the information about currently loaded modules which
implement usb functions. Then there are usb_function_instances,
which are used to actually cause a module implementing a usb function
to load, e.g. so that configfs has something to operate on before
usb_functions are created. And then there are usb_functions
which do the usb stuff proper and can be created in many instances per
each usb_function_driver.

I would call the structure in question usb_function_module.
Or even better: usb_function_pool - you get usb_functions from it.
Please see inline for what it looks like.

Not sure I can agree here. It is not what we use usb_function for.
That thing that comes out of try_get_usb_function_instance, the
usb_function_instance, is an instance which matches what I read here [0].
Yes, it is a specific USB function, with the same configuration.
usb_function is something we use in usb_configuration and those two
are not the same. In order not to confuse those two I just picked
something else. try_get_usb_function_instance() returnes severel kinds
of objects so it does not match pool in OO language. If you look at
skb_pool you expect a skb and always a skb and each skb has the same
capabilities. This is simple not true here.
I think in OO language try_get_usb_function_instance() would match a
fabric and usb_get_function() would match the pool.

[0] http://en.wikipedia.org/wiki/Instance_%28computer_science%29

 +#define DECLARE_USB_FUNCTION(_name, _inst_alloc, _func_alloc)   
 \
 +static struct usb_function_driver _name ## usb_func = { \
 +.name = __stringify(_name), \
 +.mod  = THIS_MODULE,\
 +.alloc_inst = _inst_alloc,  \
 +.alloc_func = _func_alloc,  \
 +};  \
 +MODULE_ALIAS(usbfunc:__stringify(_name));
 +
 +#define DECLARE_USB_FUNCTION_INIT(_name, _inst_alloc, _func_alloc)  \
 +DECLARE_USB_FUNCTION(_name, _inst_alloc, _func_alloc)   \
 +static int __init _name ## mod_init(void)   \
 +{   \
 +return usb_function_register(_name ## usb_func);   \
 +}   \
 +static void __exit _name ## mod_exit(void)  \
 +{   \
 +usb_function_unregister(_name ## usb_func);\
 +}   \
 +module_init(_name ## mod_init); \
 +module_exit(_name ## mod_exit)
 +

I don't understand splitting the macro in two. The latter macro is
to be used in modules and this is what you recommend, and it calls
the first macro. So the first macro should be used in places other
than modules, but the very reason of this patch is to make f_.c
files modules. Code clarity improvements because of this are
disputable; I find this split rather confusing.
Can you give an example situation where the first macro
must be called without the second macro?

Since you found it, I skip this :)

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

Re: [RFC PATCH 2/7] ARM: OMAP: devices: create device for usb part of control module

[Sergei Shtylyov]

Hello.

On 15-01-2013 12:42, Kishon Vijay Abraham I wrote:


A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mailbox.



Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
  arch/arm/mach-omap2/devices.c |   50 +
  1 file changed, 50 insertions(+)



diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5e304d0..a761faf4 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c

[...]

@@ -254,6 +255,54 @@ static inline void omap_init_camera(void)
  #endif
  }

+#if (defined(CONFIG_OMAP_CONTROL_USB) || \
+   defined(CONFIG_OMAP_CONTROL_USB_MODULE))


   () around || not needed, and you're indenting the second line too much.


+static inline void __init omap_init_control_usb(void)
+{
+   int ret = 0;


   Initializer not needed.


+
+   if (cpu_is_omap44xx()) {
+   ret = platform_device_register(omap4_control_usb);
+   if (ret)
+   pr_err(Error registering omap_control_usb device: %d\n
+   , ret);


   Please leave the comma on the previous line.

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] CDC_NCM adding support IFF_NOARP for infineon modem platform

[Wei Shuai]

yes. usbnet has FLAG_POINTTOPOINT, but that's nothing to do with
IFF_POINTTOPOINT. At least we should do something to handle
relationship of these flags rather than only have different names.
or new flag FLAG_NOARP could be introduced to corresponding to IFF_NOARP.

2013/1/15 Dan Williams d...@redhat.com:
 On Sat, 2013-01-12 at 15:35 -0800, David Miller wrote:
 From: Wei Shuai cpuw...@gmail.com
 Date: Sat, 12 Jan 2013 19:34:39 +0800

  Infineon(now Intel) HSPA Modem platform NCM cannot support ARP. so I
  introduce a flag CDC_NCM_DRIVER_DATA_NOARP which is defined in
  driver_info:data. so later on, if more such buggy devices are found,
  they could use same flag to handle.

 Is it no able to do ARP or, the more likely case, does broadcast
 not work at all?

 If it's the latter, IFF_NOARP is just making over the real problem.

 I'm not applying this, no hardware device should set IFF_NOARP.
 You probably really want IFF_POINTOPOINT or similar.

 IFF_NOARP is already done for other WWAN devices (sierra_net, hso,
 cdc-ether, cdc-phonet, lg-vl600, etc) so there is some precedent.  Some
 drivers (phonet, hso) set *both* POINTTOPOINT and NOARP.  Is that
 redundant, and should all WWAN drivers be moved to only POINTTOPOINT?

 (aside: usbnet has FLAG_POINTTOPOINT, but that's nothing to do with
 IFF_POINTTOPOINT, it only controls whether the interface is named usbX
 or ethX.  Confusing.)

 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

[PATCH v4 0/4] Enable ehci, ohci and dwc3 devices on exynos5250

[Vivek Gautam]

Changes from v3:
 - Clubbed together arch enable patches for ehci/ohci and dwc3:
   [PATCH v3 0/2] Enable ehci and ohci devices for exynos5250, and
   [PATCH v3] ARM: Exynos5250: Enabling dwc3-exynos driver
 - Dropped OF_DEV_AUXDATA entry in mach-exysno5-dt since we don't
   need it.
 - Splitted the patch ARM: Exynos5250: Enabling dwc3-exynos drive
   into clock patch and device enabling patch.
 - Rebased on top of 'for-next' of linux-samsung tree.

Vivek Gautam (4):
  ARM: Exynos5250: Enabling ehci-s5p driver
  ARM: Exynos5250: Enabling ohci-exynos driver
  ARM: Exynos5250: Add clock information for dwc3-exynos
  ARM: Exynos5250: Enabling dwc3-exynos driver

 .../devicetree/bindings/usb/exynos-usb.txt |   54 
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |4 ++
 arch/arm/boot/dts/exynos5250.dtsi  |   18 +++
 arch/arm/mach-exynos/Kconfig   |1 +
 arch/arm/mach-exynos/clock-exynos5.c   |   24 +
 5 files changed, 101 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt

-- 
1.7.6.5

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

[PATCH v4 1/4] ARM: Exynos5250: Enabling ehci-s5p driver

[Vivek Gautam]

Adding EHCI device tree node for Exynos5250 along with
the device base adress and gpio line for vbus.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
 .../devicetree/bindings/usb/exynos-usb.txt |   25 
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |4 +++
 arch/arm/boot/dts/exynos5250.dtsi  |6 
 3 files changed, 35 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
new file mode 100644
index 000..e8bbb47
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -0,0 +1,25 @@
+Samsung Exynos SoC USB controller
+
+The USB devices interface with USB controllers on Exynos SOCs.
+The device node has following properties.
+
+EHCI
+Required properties:
+ - compatible: should be samsung,exynos4210-ehci for USB 2.0
+   EHCI controller in host mode.
+ - reg: physical base address of the controller and length of memory mapped
+   region.
+ - interrupts: interrupt number to the cpu.
+
+Optional properties:
+ - samsung,vbus-gpio:  if present, specifies the GPIO that
+   needs to be pulled up for the bus to be powered.
+
+Example:
+
+   usb@1211 {
+   compatible = samsung,exynos4210-ehci;
+   reg = 0x1211 0x100;
+   interrupts = 0 71 0;
+   samsung,vbus-gpio = gpx2 6 1 3 3;
+   };
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 942d576..7363e14 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -204,4 +204,8 @@
samsung,mfc-r = 0x4300 0x80;
samsung,mfc-l = 0x5100 0x80;
};
+
+   usb@1211 {
+   samsung,vbus-gpio = gpx2 6 1 3 3;
+   };
 };
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 30485de..2cbe53e 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -275,6 +275,12 @@
#size-cells = 0;
};
 
+   usb@1211 {
+   compatible = samsung,exynos4210-ehci;
+   reg = 0x1211 0x100;
+   interrupts = 0 71 0;
+   };
+
amba {
#address-cells = 1;
#size-cells = 1;
-- 
1.7.6.5

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

[PATCH v4 2/4] ARM: Exynos5250: Enabling ohci-exynos driver

[Vivek Gautam]

Adding OHCI device tree node for Exynos5250 along with
the device base address.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
 .../devicetree/bindings/usb/exynos-usb.txt |   15 +++
 arch/arm/boot/dts/exynos5250.dtsi  |6 ++
 2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index e8bbb47..f66fcdd 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -23,3 +23,18 @@ Example:
interrupts = 0 71 0;
samsung,vbus-gpio = gpx2 6 1 3 3;
};
+
+OHCI
+Required properties:
+ - compatible: should be samsung,exynos4210-ohci for USB 2.0
+   OHCI companion controller in host mode.
+ - reg: physical base address of the controller and length of memory mapped
+   region.
+ - interrupts: interrupt number to the cpu.
+
+Example:
+   usb@1212 {
+   compatible = samsung,exynos4210-ohci;
+   reg = 0x1212 0x100;
+   interrupts = 0 71 0;
+   };
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 2cbe53e..ebb0907 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -281,6 +281,12 @@
interrupts = 0 71 0;
};
 
+   usb@1212 {
+   compatible = samsung,exynos4210-ohci;
+   reg = 0x1212 0x100;
+   interrupts = 0 71 0;
+   };
+
amba {
#address-cells = 1;
#size-cells = 1;
-- 
1.7.6.5

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

[PATCH v4 3/4] ARM: Exynos5250: Add clock information for dwc3-exynos

[Vivek Gautam]

Adding necessary device clock to exynos5 needed for
the DWC3 controller.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 arch/arm/mach-exynos/clock-exynos5.c |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos/clock-exynos5.c 
b/arch/arm/mach-exynos/clock-exynos5.c
index 0208c3a..13af020 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -757,6 +757,11 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_fsys_ctrl ,
.ctrlbit= (1  18),
}, {
+   .name   = usbdrd30,
+   .parent = exynos5_clk_aclk_200.clk,
+   .enable = exynos5_clk_ip_fsys_ctrl,
+   .ctrlbit= (1  19),
+   }, {
.name   = usbotg,
.enable = exynos5_clk_ip_fsys_ctrl,
.ctrlbit= (1  7),
@@ -1035,6 +1040,16 @@ static struct clksrc_sources exynos5_clkset_group = {
.nr_sources = ARRAY_SIZE(exynos5_clkset_group_list),
 };
 
+struct clk *exynos5_clkset_usbdrd30_list[] = {
+   [0] = exynos5_clk_mout_mpll.clk,
+   [1] = exynos5_clk_mout_cpll.clk,
+};
+
+struct clksrc_sources exynos5_clkset_usbdrd30 = {
+   .sources= exynos5_clkset_usbdrd30_list,
+   .nr_sources = ARRAY_SIZE(exynos5_clkset_usbdrd30_list),
+};
+
 /* Possible clock sources for aclk_266_gscl_sub Mux */
 static struct clk *clk_src_gscl_266_list[] = {
[0] = clk_ext_xtal_mux,
@@ -1329,6 +1344,15 @@ static struct clksrc_clk exynos5_clksrcs[] = {
.parent = exynos5_clk_mout_cpll.clk,
},
.reg_div = { .reg = EXYNOS5_CLKDIV_GEN, .shift = 4, .size = 3 },
+   }, {
+   .clk= {
+   .name   = sclk_usbdrd30,
+   .enable = exynos5_clksrc_mask_fsys_ctrl,
+   .ctrlbit= (1  28),
+   },
+   .sources = exynos5_clkset_usbdrd30,
+   .reg_src = { .reg = EXYNOS5_CLKSRC_FSYS, .shift = 28, .size = 1 
},
+   .reg_div = { .reg = EXYNOS5_CLKDIV_FSYS0, .shift = 24, .size = 
4 },
},
 };
 
-- 
1.7.6.5

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

[PATCH v4 4/4] ARM: Exynos5250: Enabling dwc3-exynos driver

[Vivek Gautam]

Adding DWC3 device tree node for Exynos5250 needed to
parse device tree data.
Also enabling XHCI support on exynos5250.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 .../devicetree/bindings/usb/exynos-usb.txt |   14 ++
 arch/arm/boot/dts/exynos5250.dtsi  |6 ++
 arch/arm/mach-exynos/Kconfig   |1 +
 3 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index f66fcdd..d660410 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -38,3 +38,17 @@ Example:
reg = 0x1212 0x100;
interrupts = 0 71 0;
};
+
+DWC3
+Required properties:
+ - compatible: should be samsung,exynos5250-dwc3 for USB 3.0 DWC3 controller.
+ - reg: physical base address of the controller and length of memory mapped
+   region.
+ - interrupts: interrupt number to the cpu.
+
+Example:
+   usb@1200 {
+   compatible = samsung,exynos5250-dwc3;
+   reg = 0x1200 0x1;
+   interrupts = 0 72 0;
+   };
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index ebb0907..a747524 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -275,6 +275,12 @@
#size-cells = 0;
};
 
+   usb@1200 {
+   compatible = samsung,exynos5250-dwc3;
+   reg = 0x1200 0x1;
+   interrupts = 0 72 0;
+   };
+
usb@1211 {
compatible = samsung,exynos4210-ehci;
reg = 0x1211 0x100;
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index d26c9f9..e62fd20 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -428,6 +428,7 @@ config MACH_EXYNOS5_DT
depends on ARCH_EXYNOS5
select ARM_AMBA
select USE_OF
+   select USB_ARCH_HAS_XHCI
help
  Machine support for Samsung EXYNOS5 machine with device tree enabled.
  Select this if a fdt blob is available for the EXYNOS5 SoC based 
board.
-- 
1.7.6.5

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

Re: [RFC PATCH 1/7] drivers: usb: phy: add a new driver for usb part of control module

[Arnd Bergmann]

On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
 +OMAP CONTROL USB
 +
 +Required properties:
 + - compatible: Should be ti,omap-control-usb
 + - reg : Address and length of the register set for the device. It contains
 +   the address of control_dev_conf and otghs_control.
 + - reg-names: The names of the register addresses corresponding to the 
 registers
 +   filled in reg.
 + - ti,has_mailbox: This is used to specify if the platform uses mailbox in
 +   control module.

I wonder whether we need to have a phandle here to connect the control device
to the actual usb device. What happens if you have multiple instances of
each?

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

Re: [RFC PATCH 0/7] usb: musb: add driver for control module

[Arnd Bergmann]

On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
 Added a new driver for the usb part of control module. This has an API
 to power on the USB2 phy and an API to write to the mailbox depending on
 whether MUSB has to act in host mode or in device mode.
 
 Writing to control module registers for doing the above task which was
 previously done in omap glue and in omap-usb2 phy is removed.
 
 Also added the dt data to get MUSB working in OMAP platforms.
 This series has patches for both drivers and ARCH folders, so If it has to
 be split I'll do it.
 

The series looks good to me, I just had a minor comment on one patch.

One a somewhat related topic, I wonder whether there are any plans
on your side to change this driver to support multiple bus glues
to be built for one kernel image. With a multiplatform kernel, we
may need all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance.

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

Re: [PATCH 2/6] arm: mvebu: Enable USB controllers on Armada 370 evaluation board

[Ezequiel Garcia]

Hi Arnd,

On 01/15/2013 10:07 AM, Arnd Bergmann wrote:
 On Tuesday 15 January 2013, Ezequiel Garcia wrote:
 Cc: Lior Amsalem al...@marvell.com
 Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
 Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
 Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
 
 The patches look good, but when you have four trivial patches
 doing the same thing in different files, and you decide that it's
 not worth writing a changelog for them, they should probably
 go into a single patch.


Mmm... maybe you're right and such splitting is excessive.
It seemed tidier this way, enabling each board on a different patch.

I can squash them on a v2, if you want me to.

Thanks for reviewing!

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 1/7] drivers: usb: phy: add a new driver for usb part of control module

[kishon]

Hi Arnd,

On Tuesday 15 January 2013 07:06 PM, Arnd Bergmann wrote:

On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:

+OMAP CONTROL USB
+
+Required properties:
+ - compatible: Should be ti,omap-control-usb
+ - reg : Address and length of the register set for the device. It contains
+   the address of control_dev_conf and otghs_control.
+ - reg-names: The names of the register addresses corresponding to the 
registers
+   filled in reg.
+ - ti,has_mailbox: This is used to specify if the platform uses mailbox in
+   control module.


I wonder whether we need to have a phandle here to connect the control device
to the actual usb device. What happens if you have multiple instances of
each?


Good point :-). Currently, none of the OMAP platforms have multiple 
control modules and it doesn't seem to be in the future (AFAIK). While 
it might be simpler to support multiple control devices with phandle, it 
might face the same complications as faced by the USB PHY framework for 
non-dt boot.


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

Re: [RFC PATCH 2/7] ARM: OMAP: devices: create device for usb part of control module

[kishon]

On Tuesday 15 January 2013 06:23 PM, Sergei Shtylyov wrote:

Hello.

On 15-01-2013 12:42, Kishon Vijay Abraham I wrote:


A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mailbox.



Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
  arch/arm/mach-omap2/devices.c |   50
+
  1 file changed, 50 insertions(+)



diff --git a/arch/arm/mach-omap2/devices.c
b/arch/arm/mach-omap2/devices.c
index 5e304d0..a761faf4 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c

[...]

@@ -254,6 +255,54 @@ static inline void omap_init_camera(void)
  #endif
  }

+#if (defined(CONFIG_OMAP_CONTROL_USB) || \
+defined(CONFIG_OMAP_CONTROL_USB_MODULE))


() around || not needed, and you're indenting the second line too much.


+static inline void __init omap_init_control_usb(void)
+{
+int ret = 0;


Initializer not needed.


+
+if (cpu_is_omap44xx()) {
+ret = platform_device_register(omap4_control_usb);
+if (ret)
+pr_err(Error registering omap_control_usb device: %d\n
+, ret);


Please leave the comma on the previous line.


Sure. I'll fix it.

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

Re: [RFC PATCH 0/7] usb: musb: add driver for control module

[kishon]

Hi Arnd,

On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote:

On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:

Added a new driver for the usb part of control module. This has an API
to power on the USB2 phy and an API to write to the mailbox depending on
whether MUSB has to act in host mode or in device mode.

Writing to control module registers for doing the above task which was
previously done in omap glue and in omap-usb2 phy is removed.

Also added the dt data to get MUSB working in OMAP platforms.
This series has patches for both drivers and ARCH folders, so If it has to
be split I'll do it.



The series looks good to me, I just had a minor comment on one patch.

One a somewhat related topic, I wonder whether there are any plans
on your side to change this driver to support multiple bus glues
to be built for one kernel image. With a multiplatform kernel, we
may need all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance.


We don't have plans as of now. I actually don't expect any changes in 
the driver other than the Kconfig changes. Anyways the probe of glue's 
other than the platform it's running won't get called. right Felipe?


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

Re: [RFC PATCH 1/7] drivers: usb: phy: add a new driver for usb part of control module

[Arnd Bergmann]

On Tuesday 15 January 2013, kishon wrote:
 Good point :-). Currently, none of the OMAP platforms have multiple 
 control modules and it doesn't seem to be in the future (AFAIK). While 
 it might be simpler to support multiple control devices with phandle, it 
 might face the same complications as faced by the USB PHY framework for 
 non-dt boot.
 

Maybe you can put the phandle into the binding then but don't use it
until hardware actually requires it. If anything needs it, then we
can always change the code later, but it's harder to change the
binding.

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

Re: [RFC PATCH 0/7] usb: musb: add driver for control module

[Felipe Balbi]

Hi,

On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote:
 Hi Arnd,
 
 On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote:
 On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
 Added a new driver for the usb part of control module. This has an API
 to power on the USB2 phy and an API to write to the mailbox depending on
 whether MUSB has to act in host mode or in device mode.
 
 Writing to control module registers for doing the above task which was
 previously done in omap glue and in omap-usb2 phy is removed.
 
 Also added the dt data to get MUSB working in OMAP platforms.
 This series has patches for both drivers and ARCH folders, so If it has to
 be split I'll do it.
 
 
 The series looks good to me, I just had a minor comment on one patch.
 
 One a somewhat related topic, I wonder whether there are any plans
 on your side to change this driver to support multiple bus glues
 to be built for one kernel image. With a multiplatform kernel, we
 may need all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance.
 
 We don't have plans as of now. I actually don't expect any changes in
 the driver other than the Kconfig changes. Anyways the probe of
 glue's other than the platform it's running won't get called. right
 Felipe?

AFAICT there's nothing preventing those from being built together as
long as you don't use DMA (yeah, that's a touchy subject still with
MUSB).

If there are any build breaks, please report them so bus glue owners can
fix. I see that at least the davinci folks need to work a bit

$ git grep -e mach\/ drivers/usb/musb/
drivers/usb/musb/da8xx.c:#include mach/da8xx.h
drivers/usb/musb/davinci.c:#include mach/cputype.h
drivers/usb/musb/davinci.c:#include mach/hardware.h

I'm adding Ravi B to the loop here for those.

-- 
balbi


signature.asc
Description: Digital signature

Re: When and how is the probe() function called?

[Felipe Balbi]

Hi,

On Tue, Jan 15, 2013 at 04:09:42PM +0100, stl wrote:
 Hello all,
 I want to write a usb driver for our usb controller.
 I aim to use it as device-side driver, so if I well understood
 as a gadget driver.
 Is gadget driver really what I need?

you need to write a UDC driver just like musb, dwc3, s3c_hsotg,
omap_udc, etc.

 I have dug into the code, and I really don't understand how the
 probe() function is called?

it depends on the underlying bus, if you're using the platform_bus_type,
probe will be called when you have a platform_device and a
platform_driver with the same name.

 Because I read in the documentation that the probe function is called
 by the usb caore when it thinks it has a struct usb_interface that
 this driver can handle.

that's for the host side.

 (Linux Device Driver 3rd edition)
 However, the only way to tell the system that the usb port is
 attached is to receive an interrupt.
 So the attached interrupt ISR needs to tell the system that
 something is attached to the system.
 But what is the generic core function to do this?
 Am I entirely wrong?

you just mixed a few concepts, that's all ;-)

Try to figure out how to write a platform_driver and a platform_device,
there are countless examples in the kernel ;-)

-- 
balbi


signature.asc
Description: Digital signature

Re: Clarifications on some usb driver terms

[Felipe Balbi]

Hi,

On Tue, Jan 15, 2013 at 04:18:00PM +0100, stl wrote:
 Hello all,
 I need some clarifications concerning the terms used in the linux usb
 documentation
 for usb driver:
 
 Firstly, what is the difference between:
 - device driver
 - chipset driver
 - interface driver
 - gadget driver
 ?

device driver != gadget driver.

gadget driver is the peripheral side implementation (or emulation) of a
USB class like NCM, MSC, UASP, etc.

device driver is the piece of SW that talks directly to the underlying
controller and reads/writes from/to its registers to make I/O happen.

 If I well understood, device driver is the same that gadget driver.
 
 Secondly, I am writing a device-side usb driver for uClinux for our
 own specific
 USB controller.
 
 Should I use usb_register() or platform_driver_register() to register
 the driver during
 boot?

you need a platform_driver

 What is the difference between these two functions?

a usb_driver (the structure) represents a real USB device connected to a
real USB Host (uhci, ohci, ehci, xhci, etc) port, like a memory card
reader, a webcam, etc.

platform_driver (the structure) represents an IP inside a SoC.

-- 
balbi


signature.asc
Description: Digital signature

RE: [PATCH 06/30] usb/gadget: add some infracture to register/unregister functions

[Andrzej Pietrasiewicz]

On Tuesday, January 15, 2013 1:03 PM Sebastian Andrzej Siewior wrote:

snip

 usb_function_driver.
 
 I would call the structure in question usb_function_module.
 Or even better: usb_function_pool - you get usb_functions from it.
 Please see inline for what it looks like.
 
 Not sure I can agree here. It is not what we use usb_function for.
 That thing that comes out of try_get_usb_function_instance, the
 usb_function_instance, is an instance which matches what I read here [0].
 Yes, it is a specific USB function, with the same configuration.

So it looks like the usb_function_instance is in fact a usb function's
_configuration_ instance?

 usb_function is something we use in usb_configuration and those two
 are not the same.

Yet, the first thing that comes to my mind after I think of a usb function
instance (no underscores here intentionally) is an instance
of a struct usb_function. This is confusing me. It took me a long while
until I understood what is going on here. Would you mind finding a
better name for it?

In order not to confuse those two I just picked
 something else. try_get_usb_function_instance() returnes severel kinds of
 objects so it does not match pool in OO language. If you look at
 skb_pool you expect a skb and always a skb and each skb has the same
 capabilities. This is simple not true here.
 I think in OO language try_get_usb_function_instance() would match a
 fabric and usb_get_function() would match the pool.
 

I meant to call the _struct_ usb_function_instance a usb_function_pool.
This in fact is consistent with what you say above: in OO language
you could call a factory method on behalf of some object (or perhaps,
a class). In C we pass this object explicitly as there is no this
pointer. So to the usb_get_function() factory method is called on
behalf of some object which is passed as an argument. And I suggest
calling this argument a usb_function_pool:

/* pool below is the this */
struct usb_function *usb_get_function(struct usb_function_pool *pool);

so the usb_get_function method is called on behalf of some pool.

I am not insisting on pool. But for the reasons given above I
would like the struct usb_function_instance (and its dependent
names) to be called differently.

AP


--
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] HID: add support for Sony RF receiver with USB product id 0x0374

[Jiri Kosina]

On Tue, 15 Jan 2013, Fernando Luis Vázquez Cao wrote:

 Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
 a RF receiver, multi-interface USB device 054c:0374, that is used to connect
 a wireless keyboard and a wireless mouse.
 
 The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not
 seem to be generating any pointer events. The problem is that the mouse 
 pointer
 is wrongly declared as a constant non-data variable in the report descriptor
 (see lsusb and usbhid-dump output below), with the consequence that it is
 ignored by the HID code.
 
 Add this device to the have-special-driver list and fix up the report
 descriptor in the Sony-specific driver which happens to already have a fixup
 for a similar firmware bug.

Applied, thanks.

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

RE: [RFC PATCH 0/7] usb: musb: add driver for control module

[B, Ravi]

 Hi,
 
 On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote:
  Hi Arnd,
  
  On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote:
  On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
  Added a new driver for the usb part of control module. 
 This has an 
  API to power on the USB2 phy and an API to write to the mailbox 
  depending on whether MUSB has to act in host mode or in 
 device mode.
  
  Writing to control module registers for doing the above 
 task which 
  was previously done in omap glue and in omap-usb2 phy is removed.
  
  Also added the dt data to get MUSB working in OMAP platforms.
  This series has patches for both drivers and ARCH 
 folders, so If it 
  has to be split I'll do it.
  
  
  The series looks good to me, I just had a minor comment on 
 one patch.
  
  One a somewhat related topic, I wonder whether there are 
 any plans on 
  your side to change this driver to support multiple bus 
 glues to be 
  built for one kernel image. With a multiplatform kernel, 
 we may need 
  all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance.
  
  We don't have plans as of now. I actually don't expect any 
 changes in 
  the driver other than the Kconfig changes. Anyways the 
 probe of glue's 
  other than the platform it's running won't get called. right Felipe?

If understand correctly the control module driver used to configure the 
respective usb phy of SoC to respective usb modes using the common set of 
control module APIs. What if, if control module interface (register defintions) 
varies b/w different revision or spin of same type of SoCs, if usbphy type is 
changed. In this case whether the single instance of control module driver is 
good enough to cater of all cpu types of same SoC series ? 
Whether cpu_is_xxx() can be used to differentiate b/w different cpu types in CM 
driver?

 
 AFAICT there's nothing preventing those from being built 
 together as long as you don't use DMA (yeah, that's a touchy 
 subject still with MUSB).
 
 If there are any build breaks, please report them so bus glue 
 owners can fix. I see that at least the davinci folks need to 
 work a bit
 
 $ git grep -e mach\/ drivers/usb/musb/ 
 drivers/usb/musb/da8xx.c:#include mach/da8xx.h 
 drivers/usb/musb/davinci.c:#include mach/cputype.h 
 drivers/usb/musb/davinci.c:#include mach/hardware.h
 
 I'm adding Ravi B to the loop here for those.
 
 --
 balbi
 --
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

[Linus Torvalds]

[ Added Tejun to the discussion, since he's the async go-to-guy ]

On Mon, Jan 14, 2013 at 10:23 PM, Ming Lei ming@canonical.com wrote:

 But I have another idea to address the problem, and let module code call
 async_synchronize_full() only if the module requires that explicitly, so how
 about the below draft patch?

No way.

This kind of let's just let drivers tell us when they used async
helpers is basically *asking* for buggy code. In fact, just to prove
how bad it is, YOU SCREWED IT UP YOURSELF.

Because it's not just sd.c that uses async_schedule(), and would need
the async synchronize. It's floppy.c, it's generic scsi scanning (so
scsi tapes etc), and it's libata-core.c.

This kind of let's randomly encourage people to write subtly buggy
code that has magical timing dependencies, so that the developer won't
likely even see it because he has fast disks etc code is totally
unacceptable. And this code was *designed* to be that kind of buggy.

No, if we set a flag like this, then it needs to be set
*automatically*, so that a module cannot screw this up by mistake.

It could be as simple as having a per-thread flag that gets set by the
__async_schedule() function, and gets cleared by fork. Then the module
code could do something like

   /* before calling the module -init function */
   current-used_async = 0;
   ...
   if (current-used_async)
  async_synchronize_full();

or whatever.

Tejun, comments? You can see the whole thread on lkml, but the basic
problem is that the module loading doing the unconditional
async_synchronize_full() has caused problems, because we have

 - load module A
   - module A does per-controller async discovery of its devices (eg
scsi or ata probing)
   - in the async thread, it initializes somethign that needs another
module B (in this case the default IO scheduler module)
  - modprobe for B loads the IO scheduler module successfully
  at the end of the module load, it does
async_synchronize_full() to make sure load_module won't return before
the module is ready
  *DEADLOCK*, because the async_synchronize_full() thing
actually waits for not the module B async code (it didn't have any),
but for the module *A* async code, which is waiting for module B to
finish.

Now, I'll happily argue that we shouldn't have this kind of load
modules from random context behavior in the kernel, and I think the
block layer is to blame for doing the IO scheduler load at an insane
time. So don't do that then would be the best solution. Sadly, we
don't even have a good way to notice that we're doing it, so hacky
workaround that at least doesn't require driver authors to care is
likely the second-best workaround.

But the hacky workaround absolutely needs to be *automatic*. Because
the driver writers need to get this subtle untestable thing right is
*not* acceptable. That's the patch that Ming Lei did, and I refuse to
have that kind of fragile crap in the kernel.

  Linus
--
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: How to assign a device to the companion

[makuda]

Alan Stern stern@... writes:

 
 On Fri, 17 Dec 2010, Alessio Sangalli wrote:
 
  On 12/17/2010 07:42 AM, Alan Stern wrote:
  
   Anyway, you can force individual root-hub ports to be dedicated to the
   companion controller by using sysfs.  For example, let's say you wanted
   port 4 on bus 1 always to run at full or low speed.  You would do it
   by:
  
 # echo 4/sys/bus/usb/devices/usb1/../companion
  
  Ok the problem is that in earlier versions of the kernel this was 
  something like:
  
  /sys/class/usb_host/usb_hostXXX/companion
 



Hi, very silly question. What is exacly the meaning of double dot in the path 
here

# echo 4/sys/bus/usb/devices/usb1/../companion

I used to treat .. as a parent directory but here it does not have sense for 
me, but I'm rather newcomer in linux ...






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

Re: [PATCH] usb: phy: remove unused APIs from Tegra PHY.

[Stephen Warren]

On 01/15/2013 03:19 AM, Venu Byravarasu wrote:
 As tegra_usb_phy_clk_disable/enable() are not being
 used, removing them.

Greg, Felipe,

Again if I may, I'll take this through the Tegra tree. I think the next
set of patches that Venu posts should actually expose the dependencies
between his USB patches and the Tegra clock framework rework, which are
why I want to do this.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: phy: remove unused APIs from Tegra PHY.

[Greg KH]

On Tue, Jan 15, 2013 at 11:04:51AM -0700, Stephen Warren wrote:
 On 01/15/2013 03:19 AM, Venu Byravarasu wrote:
  As tegra_usb_phy_clk_disable/enable() are not being
  used, removing them.
 
 Greg, Felipe,
 
 Again if I may, I'll take this through the Tegra tree. I think the next
 set of patches that Venu posts should actually expose the dependencies
 between his USB patches and the Tegra clock framework rework, which are
 why I want to do this.

I'll let Felipe judge these, as they are in his area, it's up to him.

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

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

[Linus Torvalds]

On Tue, Jan 15, 2013 at 9:36 AM, Linus Torvalds
torva...@linux-foundation.org wrote:

 This kind of let's randomly encourage people to write subtly buggy
 code that has magical timing dependencies, so that the developer won't
 likely even see it because he has fast disks etc code is totally
 unacceptable. And this code was *designed* to be that kind of buggy.

Btw, we could *possibly* do this the other way around. Wait for all
async work by default, but then have a really hacky way to turn that
off for modules that explicitly don't want it, because they know they
can be loaded in async context, and they don't do any async work
themselves. Then we could make the IO schedulers set that flag (I
know I'm loaded from async space, and I know I'm not myself doing any
async init)

Quite frankly, I'd still much rather prefer the automated approach -
or even better, just avoiding the load modules in async context
entirely. But at least the I can put a huge comment about why I don't
want to be waited on would be much more acceptable than the I need
to explicitly tell the world that it needs to wait on me.

So Ming Lei's patch was easily subtly buggy by mistake (showing that
by the fact that it was indeed buggy), while the opposite model where
you have to explicitly ask people not to wait for you could still be
very buggy, but at least now it needs to explicitly do extra work in
order to be buggy.

So if an interface is fragile, it should aim to be fragile in the
right way - making the fragility explicit, so that people can grep for
it, and people can add comments to the particular code that marks it
fragile. The default behavior should be the robust one.

And if would be lovely to add a warning to the people loaded a module
from async context case, so that we'd *see* this.

Tejun, is there a good way for code to see I'm running in async
context? Then we could do something like

WARN_ON_ONCE(wait  system_state == SYSTEM_RUNNING  in_async_thread());

in kernel/kmod.c (__request_module()). That should at least warn about
this whole issue happening.

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

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

[Alan Stern]

On Tue, 15 Jan 2013, Linus Torvalds wrote:

 Tejun, comments? You can see the whole thread on lkml, but the basic
 problem is that the module loading doing the unconditional
 async_synchronize_full() has caused problems, because we have
 
  - load module A
- module A does per-controller async discovery of its devices (eg
 scsi or ata probing)
- in the async thread, it initializes somethign that needs another
 module B (in this case the default IO scheduler module)
   - modprobe for B loads the IO scheduler module successfully
   at the end of the module load, it does
 async_synchronize_full() to make sure load_module won't return before
 the module is ready
   *DEADLOCK*, because the async_synchronize_full() thing
 actually waits for not the module B async code (it didn't have any),
 but for the module *A* async code, which is waiting for module B to
 finish.
 
 Now, I'll happily argue that we shouldn't have this kind of load
 modules from random context behavior in the kernel, and I think the
 block layer is to blame for doing the IO scheduler load at an insane
 time. So don't do that then would be the best solution.

It may not be so easy.  When the SCSI async thread probes the new disk, 
it has to do I/O.  So it needs to use a scheduler.

But maybe it could use a built-in trivial scheduler until the proper 
one is loaded.  Then the loading could be asynchronous.

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: How to assign a device to the companion

[Alan Stern]

On Tue, 15 Jan 2013, makuda wrote:

 Alan Stern stern@... writes:
 
  
  On Fri, 17 Dec 2010, Alessio Sangalli wrote:
  
   On 12/17/2010 07:42 AM, Alan Stern wrote:
   
Anyway, you can force individual root-hub ports to be dedicated to the
companion controller by using sysfs.  For example, let's say you wanted
port 4 on bus 1 always to run at full or low speed.  You would do it
by:
   
# echo 4/sys/bus/usb/devices/usb1/../companion
   
   Ok the problem is that in earlier versions of the kernel this was 
   something like:
   
   /sys/class/usb_host/usb_hostXXX/companion
  
 
 
 
 Hi, very silly question. What is exacly the meaning of double dot in the path 
 here
 
 # echo 4/sys/bus/usb/devices/usb1/../companion
 
 I used to treat .. as a parent directory but here it does not have sense for 
 me, but I'm rather newcomer in linux ...

That's what it means: the parent directory.  It isn't the same as 
/sys/bus/usb/devices/companion, though, because the usb1 entry is a 
symbolic link.

Alan Stern

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

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

[Tejun Heo]

Hello, Linus.

On Tue, Jan 15, 2013 at 09:36:57AM -0800, Linus Torvalds wrote:
 Tejun, comments? You can see the whole thread on lkml, but the basic
 problem is that the module loading doing the unconditional
 async_synchronize_full() has caused problems, because we have
 
  - load module A
- module A does per-controller async discovery of its devices (eg
 scsi or ata probing)
- in the async thread, it initializes somethign that needs another
 module B (in this case the default IO scheduler module)
   - modprobe for B loads the IO scheduler module successfully
   at the end of the module load, it does
 async_synchronize_full() to make sure load_module won't return before
 the module is ready
   *DEADLOCK*, because the async_synchronize_full() thing
 actually waits for not the module B async code (it didn't have any),
 but for the module *A* async code, which is waiting for module B to
 finish.

I think the root problem here, apart from request_module() from block
- which is a bit nasty but making that part completely async would too
be quite nasty albeit in a different way - is that
async_synchronize_full() is way too indescriminate.  It's something
only suitable for things like the end of system init.

I'm wondering whether what we need is a rudimentray nesting like the
following.

finished_loading()
{
blah blah;

cookie = async_current_cookie();

do init calls;

async_synchronize_upto(cookie);

blah blah;
}

The nesting here would be an approximation as the dependency recorded
here is chronological.  I *suspect* this should be safe unless the
module is doing something weird.  Need to think more about it.  One
way or the other, I think what we need is some form of scoping for
flushing async ops.

BTW, the current synchronization is broken - cookie isn't transferred
to running-domain in queueing order but __lowest_in_progress()
assumes that.  I think I broke that while converting it to workqueue.

Anyways, working on it.

Thanks.

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

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

[Tejun Heo]

Hello, Alan.

On Tue, Jan 15, 2013 at 01:20:58PM -0500, Alan Stern wrote:
 It may not be so easy.  When the SCSI async thread probes the new disk, 
 it has to do I/O.  So it needs to use a scheduler.
 
 But maybe it could use a built-in trivial scheduler until the proper 
 one is loaded.  Then the loading could be asynchronous.

It can be done.  Noop is always built-in and block IO can do IOs with
noop.  The problem here is that request_module() is done synchronously
during evelator_init().  We can punt that to a work item so that the
elevator is switched on load completion.  There are some nastiness
involved tho - if module probing returns before elevator switch
happens, the userland can observe elevator being switched after some
indetermined short period of time, which can, for example, break
scripts adjusting elevator knobs and etc...

I *think* it'll be best to allow scoped synchronization of async ops.
Looking into it.

Thanks.

-- 
tejun
--
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: Clarifications on some usb driver terms

[stl]

Hi,
I had a look on some extracts of your book I think I will buy it
because it seems to correspond
to what  I am looking for. Thanks for the link!

However, it has been done on a 2.6.34 kernel, but I am at the moment
working on a uClinux 2.6.19.

The registration function platform_driver_probe() seems to be what I need,
but unfortunately don't exist on my kernel version..
I have seen in UDC drivers (in /drivers/usb/gadget) that
platform_driver_register() is used instead of
platform_driver_probe().
What is the equivalent for the kernel 2.6.19?

Because the USB controller (hardware) embedded in my final system will
be unique,
so I don't need to probe at all. My driver must be registrered at boot time,
and my hardware controller configured once.

Thanks in advance for your help.



2013/1/15 Rajaram R rajaram.officem...@gmail.com:
 Hi

 Did you had a chance to look at my book

 http://www.amazon.com/Bootstrap-Yourself-Linux-USB-Stack-Validate/dp/1435457862

 I hope that helps..

 Rajaram

 On Tue, Jan 15, 2013 at 8:48 PM, stl st.lamber...@gmail.com wrote:

 Hello all,
 I need some clarifications concerning the terms used in the linux usb
 documentation
 for usb driver:

 Firstly, what is the difference between:
 - device driver
 - chipset driver
 - interface driver
 - gadget driver
 ?

 If I well understood, device driver is the same that gadget driver.

 Secondly, I am writing a device-side usb driver for uClinux for our
 own specific
 USB controller.

 Should I use usb_register() or platform_driver_register() to register
 the driver during
 boot?
 What is the difference between these two functions?

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


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

Re: Clarifications on some usb driver terms

[Peter Stuge]

stl wrote:
 I am at the moment working on a uClinux 2.6.19.

Don't do that. Work on the absolutely latest source code. If you work
on anything else it is impossible for you to get any help with any
issues, and you will have to spend a lot of extra time to make your
finished work possible to include in the upstream kernel. Upstream
inclusion is important, so it is wise to minimize the number of
obstacles that you create for yourself.


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

Re: [PATCH 0/6] arm: mvebu: Add support for USB host controllers in Armada 370/XP

[Florian Fainelli]

Hello Ezequiel,

On Tuesday 15 January 2013 06:59:57 Ezequiel Garcia wrote:
 Hi,
 
 This small patch set enables USB support on Armada 370 and Armada XP 
 platforms.
 It's based on Jason Cooper's mvebu/dt branch.
 
 Any comments or feedback are welcome.

I successfully tested this serie on a Marvell RD-A370-A1 and a DB-MV784MP-GP:

Tested-by: Florian Fainelli flor...@openwrt.org

Thanks!

 
 Ezequiel Garcia (6):
  arm: mvebu: Add support for USB host controllers in Armada 370/XP
  arm: mvebu: Enable USB controllers on Armada 370 evaluation board
  arm: mvebu: Enable USB controllers on Armada 370 Mirabox board
  arm: mvebu: Enable USB controllers on Armada XP evaluation board
  arm: mvebu: Enable USB controllers on Armada XP OpenBlocks AX3-4 board
  arm: mvebu: Update defconfig to select USB support
 
  arch/arm/boot/dts/armada-370-db.dts  |8 
  arch/arm/boot/dts/armada-370-mirabox.dts |8 
  arch/arm/boot/dts/armada-370-xp.dtsi |   15 +++
  arch/arm/boot/dts/armada-370.dtsi|9 +
  arch/arm/boot/dts/armada-xp-db.dts   |   12 
  arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |9 +
  arch/arm/boot/dts/armada-xp.dtsi |   17 +
  arch/arm/configs/mvebu_defconfig |5 -
  arch/arm/mach-mvebu/Kconfig  |1 +
  9 files changed, 83 insertions(+), 1 deletions(-)
  
 Thanks!
 
 
-- 
Florian
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

[Linus Torvalds]

On Tue, Jan 15, 2013 at 10:32 AM, Tejun Heo t...@kernel.org wrote:

 I think the root problem here, apart from request_module() from block
 - which is a bit nasty but making that part completely async would too
 be quite nasty albeit in a different way - is that
 async_synchronize_full() is way too indescriminate.  It's something
 only suitable for things like the end of system init.

 I'm wondering whether what we need is a rudimentray nesting like the
 following.

I think that is a good solution if it works, but look out: we need to
synchronize across *all* domains, not just the default one.  The sd.c
code, for example, uses its own scsi_sd_probe_domain for example,
and we *do* want to synchronize with it.

Can you do that with your suggested interface (ie it would have to be
a *global* sequence number).

   Linus
--
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 v9] usb_8dev: Add support for USB2CAN interface from 8 devices

[Marc Kleine-Budde]

On 01/14/2013 09:59 PM, Oliver Hartkopp wrote:
 Hi Bernd,
 
 On 16.12.2012 08:01, Bernd Krumboeck wrote:
 
 Add device driver for USB2CAN interface from 8 devices 
 (http://www.8devices.com).

 changes since v8:
 * remove all sysfs files

 changes since v7:
 * add sysfs documentation
 * fix minor styling issue
 * fixed can state for passive mode
 * changed handling for crc errors

 changes since v6:
 * changed some variable types to big endian equivalent
 * small cleanups

 changes since v5:
 * unlock mutex on error

 changes since v4:
 * removed FSF address
 * renamed struct usb_8dev
 * removed unused variable free_slots
 * replaced some _to_cpu functions with pointer equivalent
 * fix return value for usb_8dev_set_mode
 * handle can errors with separate function
 * fix overrun error handling
 * rewrite error handling for usb_8dev_start_xmit
 * fix urb submit in usb_8dev_start
 * various small fixes

 Signed-off-by: Bernd Krumboeck krumbo...@universalnet.at
 Acked-by: Wolfgang Grandegger w...@grandegger.com
 
 
 Tested-by: Oliver Hartkopp socket...@hartkopp.net
 
 Fortunately i got my adapter today ...
 
 [   52.984254] usb 2-1.4: new full-speed USB device number 6 using ehci-pci
 [   53.078690] usb 2-1.4: New USB device found, idVendor=0483, idProduct=1234
 [   53.078698] usb 2-1.4: New USB device strings: Mfr=1, Product=2, 
 SerialNumber=3
 [   53.078703] usb 2-1.4: Product: USB2CAN converter
 [   53.078707] usb 2-1.4: Manufacturer: edevices
 [   53.078711] usb 2-1.4: SerialNumber: ED000212
 [   53.111990] usb_8dev 2-1.4:1.0 can2: firmware: 1.4, hardware: 255.255
 [   53.112090] usbcore: registered new interface driver usb_8dev
 
 Looks good :-)
 
 When detaching the device from the CAN bus when sending/receiving CAN traffic
 i got these dmesg infos:
 
 [  960.047130] usb_8dev 2-1.4:1.0 can2: Unknown status/error message (0)
 [  976.544343] usb_8dev 2-1.4:1.0 can2: Unknown status/error message (0)
 
 Did you check these kind of 'unfriendly user' tests?
 
 E.g. pulling the USB under receive load brings this output:
 
 [ 1343.786427] usb_8dev 2-1.4:1.0 can2: Rx URB aborted (-32)
 [ 1343.786640] usb_8dev 2-1.4:1.0 can2: Rx URB aborted (-32)
 
 (..) another 344 of these URB aborted messages
 
 [ 1343.872620] usb_8dev 2-1.4:1.0 can2: Rx URB aborted (-32)
 [ 1343.872867] usb_8dev 2-1.4:1.0 can2: Rx URB aborted (-32)
 [ 1343.873124] usb_8dev 2-1.4:1.0 can2: Rx URB aborted (-32)
 [ 1343.873269] usb 2-1.4: USB disconnect, device number 6
 [ 1343.873363] usb_8dev 2-1.4:1.0 can2: Rx URB aborted (-32)
 [ 1343.875259] usb_8dev 2-1.4:1.0 can2: device disconnected
 [ 1343.875366] usb_8dev 2-1.4:1.0 can2: sending command message failed
 [ 1343.875371] usb_8dev 2-1.4:1.0 can2: couldn't stop device
 
 
 Tomorrow i will do some more testing.
 
 The LED handling of the device is really fine:
 
 - interface down - red
 - interface up - green
 - interface error passive - green blinking
 
 Regards,
 Oliver

What do you suggest? Add the driver or fix the errors first?

Marc
-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: usb device removed from sysfs before input children devices

[Karl Relton]

On Wed, 2013-01-09 at 19:27 +, Karl Relton wrote:
 On coming out of suspend my usb bluetooth adaptor is being reset by the
 system.
 
 In linux 3.7 the usb devices are being removed from the sysfs tree
 first, and then the various 'child' devices (like my bluetooth mouse 
 keyboard related devices) afterwards. This is causing the udev events
 for the input devices to have 'orphaned' sysfs paths in the udev events.
 
 This in turn means the Xorg evdev driver does not recognise the events,
 and so doesn't see the removal of the input devices.
 
 This has been picked by some downstream distributions, e.g. see this
 thread by Google Chrome developers:
 
 http://code.google.com/p/chromium-os/issues/detail?id=33813
 
 Back on linux 3.2 this was not the case. The usb adaptor was reset, but
 device removal was orderly: first the input devices (will full paths in
 the udev events), then the usb devices walking up the tree.
 
 
 To illustrate the issue, here is the output of 'udevadm monitor' in 3.7:
 
 udevadm monitor
 monitor will print the received events for:
 KERNEL - the kernel uevent
 KERNEL[2203.173080] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/rfkill2 
 (rfkill)
 KERNEL[2203.173148] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0 (bluetooth)
 KERNEL[2203.173420] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0 (usb)
 KERNEL[2203.173451] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.1 (usb)
 KERNEL[2203.173475] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.2 (usb)
 KERNEL[2203.173693] remove   /devices/pci:00/:00:1a.0/usb3/3-2 (usb)
 KERNEL[2213.152339] remove   /hci0/hci0:46/input14/mouse2 (input)
 KERNEL[2213.160374] remove   /hci0/hci0:46/input14/event10 (input)
 KERNEL[2213.168366] remove   /hci0/hci0:46/input14 (input)
 KERNEL[2213.169058] remove   /hci0/hci0:46/0005:050D:0031.0005/hidraw/hidraw0 
 (hidraw)
 KERNEL[2213.169198] remove   /hci0/hci0:46/0005:050D:0031.0005 (hid)
 KERNEL[2213.169242] remove   /hci0/hci0:46 (bluetooth)
 KERNEL[2218.176527] remove   /hci0/hci0:49/input13/event11 (input)
 KERNEL[2218.180403] remove   /hci0/hci0:49/input13 (input)
 KERNEL[2218.180481] remove   /hci0/hci0:49/0005:05AC:0256.0004/hidraw/hidraw1 
 (hidraw)
 KERNEL[2218.180538] remove   /hci0/hci0:49/0005:05AC:0256.0004 (hid)
 KERNEL[2218.182005] remove   /hci0/hci0:49 (bluetooth)
 
 See how the usb devices are moved first, and then the input/bluetooth related 
 stuff
 with path-heads removed (paths are now /hci0/... instead of /devices/...)
 
 
 Here is the equiv sequence back in 3.2:
 
 KERNEL[158.378301] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/input11/mouse2
  (input)
 KERNEL[158.388283] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/input11/event11
  (input)
 KERNEL[158.409885] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/input11
  (input)
 KERNEL[158.411565] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/0005:050D:0031.0002/hidraw/hidraw1
  (hidraw)
 KERNEL[158.411598] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/0005:050D:0031.0002
  (hid)
 KERNEL[158.411621] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49 
 (bluetooth)
 KERNEL[158.436894] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46/input10/event10
  (input)
 KERNEL[158.452211] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46/input10
  (input)
 KERNEL[158.452628] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46/0005:05AC:0256.0001/hidraw/hidraw0
  (hidraw)
 KERNEL[158.452662] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46/0005:05AC:0256.0001
  (hid)
 KERNEL[158.452752] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46 
 (bluetooth)
 KERNEL[158.629847] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/rfkill2 
 (rfkill)
 KERNEL[158.629920] remove   
 /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0 (bluetooth)
 KERNEL[158.635562] remove   /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.0 
 (usb)
 KERNEL[158.635701] remove   /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.1 
 (usb)
 KERNEL[158.635807] remove   /devices/pci:00/:00:1a.0/usb3/3-2/3-2:1.2 
 (usb)
 KERNEL[158.637238] remove   /devices/pci:00/:00:1a.0/usb3/3-2 (usb)
 
 
 The end result (for the user) is that even when the bluetooth
 mouse/keyboard is re-added, Xorg ignores it - thinking it is some hoax
 duplicate device. The keyboard/mouse is then non-operational.
 

Instrumenting the code suggests that the issue arises in a race between:

hidp_session() in bluetooth/hidp/core.c

and

hci_unregister_dev() in bluetooth/hci_core.c

Re: [PATCH v9] usb_8dev: Add support for USB2CAN interface from 8 devices

[Oliver Hartkopp]

On 15.01.2013 21:23, Marc Kleine-Budde wrote:

 On 01/14/2013 09:59 PM, Oliver Hartkopp wrote:


 
 What do you suggest? Add the driver or fix the errors first?


Hm.

We're currently at 3.8-rc3 - so waiting for reactions from Bernd makes more
sense to me.

That's better than sending a pull request that includes fixes for brand new
drivers %-)

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

Re: [PATCH v9] usb_8dev: Add support for USB2CAN interface from 8 devices

[Marc Kleine-Budde]

On 01/15/2013 09:30 PM, Oliver Hartkopp wrote:
 On 15.01.2013 21:23, Marc Kleine-Budde wrote:
 
 On 01/14/2013 09:59 PM, Oliver Hartkopp wrote:
 
 

 What do you suggest? Add the driver or fix the errors first?
 
 
 Hm.
 
 We're currently at 3.8-rc3 - so waiting for reactions from Bernd makes more
 sense to me.

okay

 That's better than sending a pull request that includes fixes for brand new
 drivers %-)

:)

Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v9] usb_8dev: Add support for USB2CAN interface from 8 devices

[Bernd Krumböck]

Hi Oliver!

 Hi Bernd,

 On 16.12.2012 08:01, Bernd Krumboeck wrote:

 Add device driver for USB2CAN interface from 8 devices
 (http://www.8devices.com).

 changes since v8:
 * remove all sysfs files

 changes since v7:
 * add sysfs documentation
 * fix minor styling issue
 * fixed can state for passive mode
 * changed handling for crc errors

 changes since v6:
 * changed some variable types to big endian equivalent
 * small cleanups

 changes since v5:
 * unlock mutex on error

 changes since v4:
 * removed FSF address
 * renamed struct usb_8dev
 * removed unused variable free_slots
 * replaced some _to_cpu functions with pointer equivalent
 * fix return value for usb_8dev_set_mode
 * handle can errors with separate function
 * fix overrun error handling
 * rewrite error handling for usb_8dev_start_xmit
 * fix urb submit in usb_8dev_start
 * various small fixes

 Signed-off-by: Bernd Krumboeck krumbo...@universalnet.at
 Acked-by: Wolfgang Grandegger w...@grandegger.com


 Tested-by: Oliver Hartkopp socket...@hartkopp.net

 Fortunately i got my adapter today ...

 [   52.984254] usb 2-1.4: new full-speed USB device number 6 using
 ehci-pci
 [   53.078690] usb 2-1.4: New USB device found, idVendor=0483,
 idProduct=1234
 [   53.078698] usb 2-1.4: New USB device strings: Mfr=1, Product=2,
 SerialNumber=3
 [   53.078703] usb 2-1.4: Product: USB2CAN converter
 [   53.078707] usb 2-1.4: Manufacturer: edevices
 [   53.078711] usb 2-1.4: SerialNumber: ED000212
 [   53.111990] usb_8dev 2-1.4:1.0 can2: firmware: 1.4, hardware: 255.255
 [   53.112090] usbcore: registered new interface driver usb_8dev

 Looks good :-)

:-)

 When detaching the device from the CAN bus when sending/receiving CAN
 traffic
 i got these dmesg infos:

 [  960.047130] usb_8dev 2-1.4:1.0 can2: Unknown status/error message (0)
 [  976.544343] usb_8dev 2-1.4:1.0 can2: Unknown status/error message (0)

 Did you check these kind of 'unfriendly user' tests?

Not really. At least I don't know what the driver should do. Let me know
if you have some suggestions.

 E.g. pulling the USB under receive load brings this output:

 [ 1343.786427] usb_8dev 2-1.4:1.0 can2: Rx URB aborted (-32)
 [ 1343.786640] usb_8dev 2-1.4:1.0 can2: Rx URB aborted (-32)

 (..) another 344 of these URB aborted messages

a bit much...

Maybe we should suppress this messages?

 [ 1343.872620] usb_8dev 2-1.4:1.0 can2: Rx URB aborted (-32)
 [ 1343.872867] usb_8dev 2-1.4:1.0 can2: Rx URB aborted (-32)
 [ 1343.873124] usb_8dev 2-1.4:1.0 can2: Rx URB aborted (-32)
 [ 1343.873269] usb 2-1.4: USB disconnect, device number 6
 [ 1343.873363] usb_8dev 2-1.4:1.0 can2: Rx URB aborted (-32)
 [ 1343.875259] usb_8dev 2-1.4:1.0 can2: device disconnected
 [ 1343.875366] usb_8dev 2-1.4:1.0 can2: sending command message failed
 [ 1343.875371] usb_8dev 2-1.4:1.0 can2: couldn't stop device


 Tomorrow i will do some more testing.

Thanks!

 The LED handling of the device is really fine:

 - interface down - red
 - interface up - green
 - interface error passive - green blinking

 Regards,
 Oliver


regards,
Bernd

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

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

[Tejun Heo]

Hello, Linus

Will continue on another reply but this one is relevant so...

On Tue, Jan 15, 2013 at 10:18:45AM -0800, Linus Torvalds wrote:
 Tejun, is there a good way for code to see I'm running in async
 context? Then we could do something like

Almost.  With a bit of modification we can ask whether current is a
kworker, reach struct worker_struct via kthread_data() if so and then
test worker-current_func against the async workfn.

Thanks.

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

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

[Tejun Heo]

cc'ing Arjan.  Arjan, the original thread can be read from

  http://thread.gmane.org/gmane.linux.kernel/1420814

Hello, again.

On Tue, Jan 15, 2013 at 12:18:01PM -0800, Linus Torvalds wrote:
 I think that is a good solution if it works, but look out: we need to
 synchronize across *all* domains, not just the default one.  The sd.c
 code, for example, uses its own scsi_sd_probe_domain for example,
 and we *do* want to synchronize with it.
 
 Can you do that with your suggested interface (ie it would have to be
 a *global* sequence number).

So, I've been thinking about it for a while now and it looks like
async is cutting too many corners to implement any sane stackable
flushing scheme on top.  There simply isn't much information to
determine who should wait for what.

I've thought of two workarounds.  Both suck.

A. Try to detect deadlock conditions from synchronize().  If deadlock
   condition involving other async jobs are detected, whine about it
   and then skip.  Ignore deadlock condition on self (should solve
   this particular case).

   Detecting deadlock condition isn't difficult if there are only
   global synchronizations; unfortunately, fragmented dependencies via
   domain-local synchronization makes this non-trivial.

   We can still do ignore-self thing mostly trivially tho.  This will
   at least work around the problem at hand.

B. The ranged synchronization I first suggested.  The problem with
   this is that it's a common practice for a given async job to try to
   flush anything which comes before it.  This can introduce spurious
   synchronization dependencies which can then lead to deadlocks.

   These conditions can be detected and ignored, at least only
   considering global synchronizations.  The problem here is that
   those deadlock conditions will occur under normal usage and thus
   should be ignored silently, which basically makes synchronization
   silently ignore and finish successfully even if there are
   legitimate deadlocks which should be investigated.

For now, I'm gonna implement simple I'm not gonna wait for myself
self-deadlock avoidance.  If this needs any more sophistication, I
think we better reimplement it so that we can explicitly match up and
track who's gonna wait for what instead of throwing everything into a
single cookie space and then try to work back from there.

Thanks.

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

Re: [PATCH 5/6] arm: mvebu: Enable USB controllers on Armada XP OpenBlocks AX3-4 board

[Nobuhiro Iwamatsu]

Hi,



On Tue, Jan 15, 2013 at 6:54 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
 Cc: Lior Amsalem al...@marvell.com
 Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
 Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
 Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
 ---
  arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |9 +
  1 files changed, 9 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts 
 b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
 index b24644f..55f5b6f 100644
 --- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
 +++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
 @@ -127,5 +127,14 @@
 nr-ports = 2;
 status = okay;
 };
 +   usb@d005 {
 +   status = okay;
 +   };
 +   usb@d0051000 {
 +   status = okay;
 +   };
 +   usb@d0052000 {
 +   status = okay;
 +   };
USB2 of openblocks-ax3-4 is used as Mini-PCIE.
I think this is unnecessary.

 };
  };
 --
 1.7.8.6


Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

[Arjan van de Ven]

For now, I'm gonna implement simple I'm not gonna wait for myself
self-deadlock avoidance.  If this needs any more sophistication, I
think we better reimplement it so that we can explicitly match up and
track who's gonna wait for what instead of throwing everything into a
single cookie space and then try to work back from there.


async fundamentally had the concept of a monotonic increasing number,
and that you could always wait for everyone before me.
then people (like me) wanted exceptions to what everyone means ;-(
I'm ok with going back to a single space and simplify the world.

the case with (usb) module loading is fun...
people expect the device to be there (since frankly, it's hard to do 
otherwise)..
... but it's also really hard due to the nature of USB.. USB is async in nature,
even independent of the kernel async stuff.
Example: Load ehci.ko ... the actual use devices don't show up for some time.


the module wait case is tricky, and I wonder if there's deadlocks lurking even 
without async.
(btw there is a similar situation at the end of the normal kernel boot versus 
things like asynchronous
driver initializing... but we skip that in the case of an initrd is used to 
bypass a very similar deadlock.
this is even without async in use.. typical hard case is the PS/2 mouse 
probing)

at some point in the past we had the concept of request a module but don't wait for 
it,
and I wonder if that is what should have been used here.

Doing a range wait, with the start of the range being taken at the start of 
module loading
is a bit of a hack, but it'll work for the userspace expected semantics of all 
async stuff of
the *loaded module* be done, independent of all other modules/async stuff.
It's not as deadlocky as one might think, but it's not going to be efficient to 
implement.

not self-deadlocking likely solves most practical cases though




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

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

[Tejun Heo]

Hello, Arjan.

On Tue, Jan 15, 2013 at 04:25:54PM -0800, Arjan van de Ven wrote:
 async fundamentally had the concept of a monotonic increasing number,
 and that you could always wait for everyone before me.
 then people (like me) wanted exceptions to what everyone means ;-(
 I'm ok with going back to a single space and simplify the world.

If we want (or need) finer grained operation, we'll probably have to
head the other direction, so that we can definitively tell that an
async operation belongs to domains system, module load A and B, so
that each waiter knows what to wait for.

The current domain implementation is somewhere inbetween.  It's not
completely simplistic system and at the same time not developed enough
to do properly stacked flushing.

 the module wait case is tricky, and I wonder if there's deadlocks
 lurking even without async.

I don't think so.  It's really an async job waiting for itself.
Working around just this case is mostly trivial (working on patches
now) but it really is putting kludges on top of shaky foundation.
Maybe this is the extent of complexity that we need to go given the
rather limited use cases of async.  Let's hope so.  I think we'll have
to reimplement synchronization scheme if we have to go further.

 at some point in the past we had the concept of request a module
 but don't wait for it, and I wonder if that is what should have
 been used here.

We actually want to wait for it as it creates a userland visible
behavior difference otherwise.  It's just that async's way of waiting
is too ham-fisted to be used properly in more complex scenarios.

Thanks.

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

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

[Linus Torvalds]

On Tue, Jan 15, 2013 at 3:50 PM, Tejun Heo t...@kernel.org wrote:

 For now, I'm gonna implement simple I'm not gonna wait for myself
 self-deadlock avoidance.

You can't really do that. Or rather, it won't *help*.

The thing is, the module loading in particular is not necessarily
happening in the same context as what *started* the module loading. A
module loader will request the module from user space, and then later
user space - through possibly a totally unrelated process - will
finish it. So there is no myself. There's not even necessarily any
relationship that the kernel even knows about, because the module
loading request can have gone from usermode_helper over something like
dbus to systemd.

See?

There's a reason I asked for a warning for this. Or the let's flag
the current thread if it ever started anything asynchronous. Because
it's complicated.

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

Re: usb serial driver: private data already deallocated when release function is called

[Tilman]

Greg KH greg@... writes:
  Btw. are there repositories that would be suitable to make
  highly experimental
  code available ? 
 
 Yes, that is what drivers/staging/ is for, why not submit your driver
 for inclusion there?
The driver is not even close from being finished... 


 Ugh, the whitehead driver was not a good role model.
Well,maybe, but it is the only driver for an eazy-usb chip, isn't it ?

  You should look at
 the changes that have gone into that driver over the past few releases,
 and make the same kind of changes to your driver.  That would be an easy
 way to bring it up to modern standards, and fix the tty port issue at
 the same time.
I got the driver working to the extend it was working before. The issue was a
pointer dereferencing issue in the allocation routine. Thanks for the advice.

Tilman


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

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

[Linus Torvalds]

On Tue, Jan 15, 2013 at 4:36 PM, Linus Torvalds
torva...@linux-foundation.org wrote:

 There's a reason I asked for a warning for this. Or the let's flag
 the current thread if it ever started anything asynchronous. Because
 it's complicated.

Btw, the sequence counter (that is *not* taking anything else into
account) is good enough in practice, exactly because the common case
for module loading is actually that nothing in the module init
sequence is done asynchronously.

Yes, device discovery (particularly for block devices) is often
asynchronous. But the modules it then asks to load usually wouldn't
be. So if we just have the flag did this thread ever even start async
work over the module init sequence, we can just avoid the async
serialization entirely for that case, and it breaks the deadlock chain
nicely in practice.

Only of a block device does async work and then wants to load another
module that does more async work in its init routine would it then
break. But at that point, I'll happily just put my foot down and tell
people they are crazy, and Let's not do that kind of crap.

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

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

[Tejun Heo]

On Tue, Jan 15, 2013 at 04:36:34PM -0800, Linus Torvalds wrote:
 The thing is, the module loading in particular is not necessarily
 happening in the same context as what *started* the module loading. A
 module loader will request the module from user space, and then later
 user space - through possibly a totally unrelated process - will
 finish it. So there is no myself. There's not even necessarily any
 relationship that the kernel even knows about, because the module
 loading request can have gone from usermode_helper over something like
 dbus to systemd.
 
 See?

Right.  Gees, there's even no way to link them.

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

Re: usb serial driver: private data already deallocated when release function is called

[Greg KH]

On Wed, Jan 16, 2013 at 12:37:43AM +, Tilman wrote:
 
 Greg KH greg@... writes:
   Btw. are there repositories that would be suitable to make
   highly experimental
   code available ? 
  
  Yes, that is what drivers/staging/ is for, why not submit your driver
  for inclusion there?
 The driver is not even close from being finished... 

That doesn't matter :)

  Ugh, the whitehead driver was not a good role model.
 Well,maybe, but it is the only driver for an eazy-usb chip, isn't it ?

No, keyspan also works for those chips, but the chip shouldn't matter
here, it's how the protocol works for the firmware in the device that
matters.

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

Re: [PATCH v2 1/4] ARM i.MX6: use reserved bit for mxs phy clock gate

[Peter Chen]

On Tue, Jan 15, 2013 at 07:33:16PM +0800, Shawn Guo wrote:
 On Tue, Jan 15, 2013 at 02:08:34PM +0800, Peter Chen wrote:
  For mxs-phy user i.mx6q, the PHY's clock is controlled by
  hardware automatically, the software only needs to enable it
  at probe, disable it at remove. During the runtime,
  we don't need to control it. So for the usbphy clk policy:
  
  - Keep refcount for usbphy as clk framework needs to know if
  it is off or on.
 
 Just checked the reference manual, it seems that not only bit 6
 (EN_USB_CLKS) but also bit 12 (POWER) are controlled by USB hardware.
 If this is true, I think that PLL3 and PLL7 are really designed for
 USB PHY use only.  Do you actually see other real users of these two
 PLLs on imx6q besides USB PHY?  If not, we can just provide a dummy
 clock to mxs-phy driver on imx6q, and keep real clocks usbphy1 and
 usbphy2 there for platform init function to enable them if USB support
 is built in.  Then, we can save all these dirty hacks.  Thoughts?
It was my v1 patch did.

I send the v2 patch due to below reasons,
There are other PLL3 users, it is better keep refcount
to all its children, or the user will be confused when the
PLL3 goes to disable, but the usb otg part is still used

For PLL7, we can do it, and let the PLL7 be out of clock framework
management.

But I still think keep usbphy as PLL child is better solution,
in that case, the clock maintainer can know the real clock usage.

 
 Shawn
 
  - Use reserved bit, in that case, clk_enable/disable will
  only update refcount, but without any hardware effects.
  
  Signed-off-by: Peter Chen peter.c...@freescale.com
  ---
  Changes for v2:
  - Use reserved bit for usb phy clk control
  
   arch/arm/mach-imx/clk-imx6q.c |   10 --
   1 files changed, 8 insertions(+), 2 deletions(-)
  
  diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
  index 7f2c10c..85dcc89 100644
  --- a/arch/arm/mach-imx/clk-imx6q.c
  +++ b/arch/arm/mach-imx/clk-imx6q.c
  @@ -208,8 +208,14 @@ int __init mx6q_clocks_init(void)
  clk[pll7_usb_host] = imx_clk_pllv3(IMX_PLLV3_USB,   
  pll7_usb_host,osc, base + 0x20, 0x3);
  clk[pll8_mlb]  = imx_clk_pllv3(IMX_PLLV3_MLB,   pll8_mlb, 
  osc, base + 0xd0, 0x0);
   
  -   clk[usbphy1] = imx_clk_gate(usbphy1, pll3_usb_otg, base + 0x10, 6);
  -   clk[usbphy2] = imx_clk_gate(usbphy2, pll7_usb_host, base + 0x20, 6);
  +   /*
  +* Bit 20 is the reserved and read-only bit, we do this only for:
  +* - Do nothing for usbphy clk_enable/disable
  +* - Keep refcount when do usbphy clk_enable/disable, in that case,
  +* the clk framework can know the USB phy clk is on or off
  +*/
  +   clk[usbphy1] = imx_clk_gate(usbphy1, pll3_usb_otg, base + 0x10, 20);
  +   clk[usbphy2] = imx_clk_gate(usbphy2, pll7_usb_host, base + 0x20, 
  20);
   
  clk[sata_ref] = imx_clk_fixed_factor(sata_ref, pll6_enet, 1, 5);
  clk[pcie_ref] = imx_clk_fixed_factor(pcie_ref, pll6_enet, 1, 4);
  -- 
  1.7.0.4
  
  

-- 

Best Regards,
Peter Chen

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

Re: linux-3.7.1: kmemleak reports in comm usb-storage?

[Martin Mokrejs]

Alan Stern wrote:
 On Sun, 13 Jan 2013, Martin Mokrejs wrote:
 
 Don't worry about what kmemleak says when the drives are plugged in.  
 See what it says when all the USB drives are unplugged.  That's what 
 matters.

 Now it is the only one drive connected. If I disconnect it kmemleak won't 
 change like it
 did not today for many hours when all the drives were unplugged. I thought 
 you want
 me to plug it in back and unplug several times. ;)
 
 I did want you to plug it in and unplug it several times.  But pay 
 attention only to what kmemleak says when the drive is unplugged.

I did not retry yet but I got the same kmemleak reported again. And,
after quitting my seamonkey I realized system is uncovering another kmemleak.
So, I am, attaching a diff to a previous stage. I can assure you that those
new lines are not related to any new USB device being plugged in or out 
meanwhile.

 
 So, did I answer your question now?
 
 I can't tell.  I don't really understand what you are doing.

I think you wanted to say:

cp -p /sys/kernel/debug/kmemleak /tmp/kmemleak.0
# plugin USB drive
cp -p /sys/kernel/debug/kmemleak /tmp/kmemleak.1
# unplug the drive
cp -p /sys/kernel/debug/kmemleak /tmp/kmemleak.2

And if kmemleak.1 and kmemleak.2 differ then report, otherwise not.

I haven't realized the kmemleak being different when the drive was just plugged 
in,
the new items always popped up just after unplug. My uncertainty was whether 
there
is some delay in updating the file, and whether I can be sure it is up-to-date, 
always.

I think those new items attached show yet another system path so I hope it will
help you. Those about tty could be related to the fact that i tried to do

# less /sys/kernel/debug/kmemleak

and it somehow blocked. cancel;ling that and using cat command was not much 
helpful.
After some seconds it got through and gave me the output but less would have 
probably
succeeded as well.

Please let me know whether I should report the kmemleaks elsewhere.

Martin
--- /tmp/kmemleak   2013-01-12 19:34:43.0 +0100
+++ /sys/kernel/debug/kmemleak  2013-01-09 21:19:19.800324883 +0100
@@ -1,5 +1,5 @@
 unreferenced object 0x88040b1c5230 (size 256):
-  comm swapper/0, pid 1, jiffies 4294937570 (age 256523.410s)
+  comm swapper/0, pid 1, jiffies 4294937570 (age 540111.170s)
   hex dump (first 32 bytes):
 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .N..
 ff ff ff ff ff ff ff ff 38 3f 5d 82 ff ff ff ff  8?].
@@ -21,7 +21,7 @@
 [81305cb1] driver_register+0x8c/0x106
 [81281c6d] __pci_register_driver+0x5a/0x5e
 unreferenced object 0x88034b2fe578 (size 16):
-  comm usb-storage, pid 5508, jiffies 4302958885 (age 176310.350s)
+  comm usb-storage, pid 5508, jiffies 4302958885 (age 459898.040s)
   hex dump (first 16 bytes):
 01 00 00 00 01 00 00 00 58 1b 6d d2 03 88 ff ff  X.m.
   backtrace:
@@ -42,7 +42,7 @@
 [815da6ac] ret_from_fork+0x7c/0xb0
 [] 0x
 unreferenced object 0x88034b2fee10 (size 16):
-  comm usb-storage, pid 5508, jiffies 4302958885 (age 176310.350s)
+  comm usb-storage, pid 5508, jiffies 4302958885 (age 459898.040s)
   hex dump (first 16 bytes):
 01 00 00 00 01 00 00 00 58 1b 6d d2 03 88 ff ff  X.m.
   backtrace:
@@ -63,7 +63,7 @@
 [815da6ac] ret_from_fork+0x7c/0xb0
 [] 0x
 unreferenced object 0x88034b2fe488 (size 16):
-  comm usb-storage, pid 5508, jiffies 4302958886 (age 176310.360s)
+  comm usb-storage, pid 5508, jiffies 4302958886 (age 459898.040s)
   hex dump (first 16 bytes):
 01 00 00 00 01 00 00 00 58 1b 6d d2 03 88 ff ff  X.m.
   backtrace:
@@ -84,7 +84,7 @@
 [815da6ac] ret_from_fork+0x7c/0xb0
 [] 0x
 unreferenced object 0x88034b2fe528 (size 16):
-  comm usb-storage, pid 5508, jiffies 4302958886 (age 176310.360s)
+  comm usb-storage, pid 5508, jiffies 4302958886 (age 459898.060s)
   hex dump (first 16 bytes):
 01 00 00 00 01 00 00 00 c8 1e 6d d2 03 88 ff ff  ..m.
   backtrace:
@@ -105,7 +105,7 @@
 [815da6ac] ret_from_fork+0x7c/0xb0
 [] 0x
 unreferenced object 0x88034b2fe4b0 (size 16):
-  comm usb-storage, pid 5508, jiffies 4302958886 (age 176310.360s)
+  comm usb-storage, pid 5508, jiffies 4302958886 (age 459898.060s)
   hex dump (first 16 bytes):
 01 00 00 00 01 00 00 00 c8 1e 6d d2 03 88 ff ff  ..m.
   backtrace:
@@ -126,7 +126,7 @@
 [815da6ac] ret_from_fork+0x7c/0xb0
 [] 0x
 unreferenced object 0x88034b2fe460 (size 16):
-  comm usb-storage, pid 5508, jiffies 4302958886 (age 176310.380s)
+  comm usb-storage, pid 5508, jiffies 4302958886 (age 459898.060s)
   hex dump (first 16 bytes):
 01 00 00 00 01 00 00 00 c8 1e 6d d2 03 88 ff ff  ..m.
   backtrace:
@@ -147,7 +147,7 

Re: linux-3.7.1: kmemleak reports in comm usb-storage?

[Martin Mokrejs]

Martin Mokrejs wrote:
 Alan Stern wrote:
 On Sun, 13 Jan 2013, Martin Mokrejs wrote:

 Don't worry about what kmemleak says when the drives are plugged in.  
 See what it says when all the USB drives are unplugged.  That's what 
 matters.

 Now it is the only one drive connected. If I disconnect it kmemleak won't 
 change like it
 did not today for many hours when all the drives were unplugged. I thought 
 you want
 me to plug it in back and unplug several times. ;)

 I did want you to plug it in and unplug it several times.  But pay 
 attention only to what kmemleak says when the drive is unplugged.
 
 I did not retry yet but I got the same kmemleak reported again. And,
 after quitting my seamonkey I realized system is uncovering another kmemleak.
 So, I am, attaching a diff to a previous stage. I can assure you that those
 new lines are not related to any new USB device being plugged in or out 
 meanwhile.

A corresponding diff of dmesg output is attached. Note that the first kmemleak 
in there
happened just without any prior fiddling with a USB drive. For about two days I 
haven't
connected a drive. However, usb-storage might be in a wrong shape since several 
days
when it happened for the first time. Did you want me to reboot? ;-) I did not.

Martin
--- /tmp/dmesg.new  2013-01-12 20:18:14.0 +0100
+++ /tmp/dmesg.22013-01-16 02:33:34.0 +0100
@@ -1933,3 +1933,100 @@
 [257099.029790] hub 3-1:1.0: port 1, status 0100, change 0001, 12 Mb/s
 [257099.181584] hub 3-1:1.0: debounce: port 1: total 100ms stable 100ms status 
0x100
 [257855.985369] kmemleak: 14 new suspected memory leaks (see 
/sys/kernel/debug/kmemleak)
+[267293.258370] usb usb2: usb auto-resume
+[267293.258376] ehci_hcd :00:1d.0: resume root hub
+[267293.295290] hub 2-0:1.0: hub_resume
+[267293.295328] hub 2-0:1.0: port 1: status 0507 change 
+[267293.295422] usb 2-1: usb auto-resume
+[267293.296110] hub 2-0:1.0: state 7 ports 2 chg  evt 
+[267293.335231] ehci_hcd :00:1d.0: GetStatus port:1 status 001005 0  ACK 
POWER sig=se0 PE CONNECT
+[267293.355095] usb 2-1: finish resume
+[267293.355346] hub 2-1:1.0: hub_resume
+[267293.356336] ehci_hcd :00:1d.0: reused qh 88040aceac78 schedule
+[267293.356339] usb 2-1: link qh256-0001/88040aceac78 start 1 [1/0 us]
+[267293.356967] hub 2-1:1.0: state 7 ports 8 chg  evt 
+[267295.711589] hub 2-1:1.0: hub_suspend
+[267295.711597] usb 2-1: unlink qh256-0001/88040aceac78 start 1 [1/0 us]
+[267295.732900] usb 2-1: usb auto-suspend, wakeup 1
+[267297.748460] hub 2-0:1.0: hub_suspend
+[267297.748470] usb usb2: bus auto-suspend, wakeup 1
+[267297.748472] ehci_hcd :00:1d.0: suspend root hub
+[267310.610920] usb usb2: usb auto-resume
+[267310.610925] ehci_hcd :00:1d.0: resume root hub
+[267310.649159] hub 2-0:1.0: hub_resume
+[267310.649199] hub 2-0:1.0: port 1: status 0507 change 
+[267310.649278] usb 2-1: usb auto-resume
+[267310.650700] hub 2-0:1.0: state 7 ports 2 chg  evt 
+[267310.689142] ehci_hcd :00:1d.0: GetStatus port:1 status 001005 0  ACK 
POWER sig=se0 PE CONNECT
+[267310.709046] usb 2-1: finish resume
+[267310.709247] hub 2-1:1.0: hub_resume
+[267310.710248] ehci_hcd :00:1d.0: reused qh 88040aceac78 schedule
+[267310.710250] usb 2-1: link qh256-0001/88040aceac78 start 1 [1/0 us]
+[267310.710270] hub 2-1:1.0: state 7 ports 8 chg  evt 
+[267312.706389] hub 2-1:1.0: hub_suspend
+[267312.706398] usb 2-1: unlink qh256-0001/88040aceac78 start 1 [1/0 us]
+[267312.726266] usb 2-1: usb auto-suspend, wakeup 1
+[267314.742955] hub 2-0:1.0: hub_suspend
+[267314.742964] usb usb2: bus auto-suspend, wakeup 1
+[267314.742966] ehci_hcd :00:1d.0: suspend root hub
+[270107.716006] [sched_delayed] sched: RT throttling activated
+[272687.284828] traps: python2.7[23538] general protection ip:7fe8be5a5f08 
sp:7fff3c479b10 error:0 in libpython2.7.so.1.0[7fe8be495000+173000]
+[273262.853094] hub 4-1:1.0: state 7 ports 4 chg  evt 0002
+[273262.878070] hub 4-1:1.0: port 1, status 02a0, change 0041, 5.0 Gb/s
+[273262.878075] usb 4-1.1: USB disconnect, device number 6
+[273262.878077] usb 4-1.1: unregistering device
+[273262.878078] usb 4-1.1: unregistering interface 4-1.1:1.0
+[273262.884593] usb 4-1.1: usb_disable_device nuking all URBs
+[273262.884653] usb 4-1.1: Successful Endpoint Configure command
+[273263.056046] hub 4-1:1.0: debounce: port 1: total 100ms stable 100ms status 
0x2a0
+[273263.056062] usb 4-1: remote wakeup needed for autosuspend
+[277337.650821] kmemleak: 1 new suspected memory leaks (see 
/sys/kernel/debug/kmemleak)
+[279422.737427] r8169 :05:00.0 eth0: link down
+[306258.609520] r8169 :05:00.0 eth0: link up
+[306276.021745] r8169 :05:00.0 eth0: link down
+[306303.361392] r8169 :05:00.0 eth0: link up
+[306310.846349] r8169 :05:00.0 eth0: link down
+[306313.082271] r8169 :05:00.0 eth0: link up
+[311084.323583] r8169 :05:00.0 eth0: link down
+[311084.323593] 

Re: [PATCH v2 1/4] ARM i.MX6: use reserved bit for mxs phy clock gate

[Shawn Guo]

On Wed, Jan 16, 2013 at 09:18:46AM +0800, Peter Chen wrote:
 On Tue, Jan 15, 2013 at 07:33:16PM +0800, Shawn Guo wrote:
  On Tue, Jan 15, 2013 at 02:08:34PM +0800, Peter Chen wrote:
   For mxs-phy user i.mx6q, the PHY's clock is controlled by
   hardware automatically, the software only needs to enable it
   at probe, disable it at remove. During the runtime,
   we don't need to control it. So for the usbphy clk policy:
   
   - Keep refcount for usbphy as clk framework needs to know if
   it is off or on.
  
  Just checked the reference manual, it seems that not only bit 6
  (EN_USB_CLKS) but also bit 12 (POWER) are controlled by USB hardware.
  If this is true, I think that PLL3 and PLL7 are really designed for
  USB PHY use only.  Do you actually see other real users of these two
  PLLs on imx6q besides USB PHY?  If not, we can just provide a dummy
  clock to mxs-phy driver on imx6q, and keep real clocks usbphy1 and
  usbphy2 there for platform init function to enable them if USB support
  is built in.  Then, we can save all these dirty hacks.  Thoughts?
 It was my v1 patch did.
 
I thought it might be okay to access anatop for enabling the clock in
usb driver.  But I found it's just too ugly to do that when I look at
the code a little bit closer.  I prefer to keep clock driver unchanged
and just call clk_prepare_enable() at platform level to enable the
clock.  I really dislike the code accessing anatop for enabling the
clock.  That's the part different from you v1 patch.

 I send the v2 patch due to below reasons,
 There are other PLL3 users, it is better keep refcount
 to all its children, or the user will be confused when the
 PLL3 goes to disable, but the usb otg part is still used
 
This is the part I'm not sure how it works.  You said, the PLL will be
managed by hardware during USB suspend/resume.  I assume that it means
the PLL will be powered off when USB suspends and be powered on when
USB resumes.  If that's the case, how other users of the PLL work when
PLL is powered off by USB hardware.

Shawn

 For PLL7, we can do it, and let the PLL7 be out of clock framework
 management.
 
 But I still think keep usbphy as PLL child is better solution,
 in that case, the clock maintainer can know the real clock usage.
 

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

Re: [PATCH v5 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id

[Peter Chen]

On Tue, Jan 15, 2013 at 10:03:46PM +0800, Shawn Guo wrote:
 On Tue, Jan 15, 2013 at 10:29:33AM +0800, Peter Chen wrote:
  As mach/hardware.h is deleted, we need to use platform_device_id to
  differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
  already used pdata to differentiate runtime
  
  Meanwhile we update the platform code accordingly.
  
  Signed-off-by: Peter Chen peter.c...@freescale.com
  ---
   arch/arm/mach-imx/devices/devices-common.h|1 +
   arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c |   15 ---
   drivers/usb/gadget/fsl_mxc_udc.c  |   24 +---
   drivers/usb/gadget/fsl_udc_core.c |   42 
  +
   4 files changed, 45 insertions(+), 37 deletions(-)
 
 Since we are splitting the original patch anyway, it's a bit strange
 to me that you are mixing arch/arm/mach-imx and drivers/usb/gadget
 in this patch.  I'm fine with it, since I assume all the patches to
 go via USB tree anyway.
 
  
  diff --git a/arch/arm/mach-imx/devices/devices-common.h 
  b/arch/arm/mach-imx/devices/devices-common.h
  index 6277baf..9bd5777 100644
  --- a/arch/arm/mach-imx/devices/devices-common.h
  +++ b/arch/arm/mach-imx/devices/devices-common.h
  @@ -63,6 +63,7 @@ struct platform_device *__init imx_add_flexcan(
   
   #include linux/fsl_devices.h
   struct imx_fsl_usb2_udc_data {
  +   const char *devid;
  resource_size_t iobase;
  resource_size_t irq;
   };
  diff --git a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c 
  b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
  index 37e4439..fb527c7 100644
  --- a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
  +++ b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
  @@ -11,35 +11,36 @@
   #include ../hardware.h
   #include devices-common.h
   
  -#define imx_fsl_usb2_udc_data_entry_single(soc)
  \
  +#define imx_fsl_usb2_udc_data_entry_single(soc, _devid)
  \
  {   \
  +   .devid = _devid,\
  .iobase = soc ## _USB_OTG_BASE_ADDR,\
  .irq = soc ## _INT_USB_OTG, \
  }
   
   #ifdef CONFIG_SOC_IMX25
   const struct imx_fsl_usb2_udc_data imx25_fsl_usb2_udc_data __initconst =
  -   imx_fsl_usb2_udc_data_entry_single(MX25);
  +   imx_fsl_usb2_udc_data_entry_single(MX25, imx-udc-mx25);
   #endif /* ifdef CONFIG_SOC_IMX25 */
   
   #ifdef CONFIG_SOC_IMX27
   const struct imx_fsl_usb2_udc_data imx27_fsl_usb2_udc_data __initconst =
  -   imx_fsl_usb2_udc_data_entry_single(MX27);
  +   imx_fsl_usb2_udc_data_entry_single(MX27, imx-udc-mx27);
   #endif /* ifdef CONFIG_SOC_IMX27 */
   
   #ifdef CONFIG_SOC_IMX31
   const struct imx_fsl_usb2_udc_data imx31_fsl_usb2_udc_data __initconst =
  -   imx_fsl_usb2_udc_data_entry_single(MX31);
  +   imx_fsl_usb2_udc_data_entry_single(MX31, imx-udc-mx31);
   #endif /* ifdef CONFIG_SOC_IMX31 */
   
   #ifdef CONFIG_SOC_IMX35
   const struct imx_fsl_usb2_udc_data imx35_fsl_usb2_udc_data __initconst =
  -   imx_fsl_usb2_udc_data_entry_single(MX35);
  +   imx_fsl_usb2_udc_data_entry_single(MX35, imx-udc-mx35);
   #endif /* ifdef CONFIG_SOC_IMX35 */
   
   #ifdef CONFIG_SOC_IMX51
   const struct imx_fsl_usb2_udc_data imx51_fsl_usb2_udc_data __initconst =
  -   imx_fsl_usb2_udc_data_entry_single(MX51);
  +   imx_fsl_usb2_udc_data_entry_single(MX51, imx-udc-mx51);
   #endif
   
   struct platform_device *__init imx_add_fsl_usb2_udc(
  @@ -57,7 +58,7 @@ struct platform_device *__init imx_add_fsl_usb2_udc(
  .flags = IORESOURCE_IRQ,
  },
  };
  -   return imx_add_platform_device_dmamask(fsl-usb2-udc, -1,
  +   return imx_add_platform_device_dmamask(data-devid, -1,
  res, ARRAY_SIZE(res),
  pdata, sizeof(*pdata), DMA_BIT_MASK(32));
   }
 
 snip
 
  +static const struct platform_device_id fsl_udc_devtype[] = {
  +   {
  +   .name = imx-udc-mx25,
  +   }, {
  +   .name = imx-udc-mx27,
  +   }, {
  +   .name = imx-udc-mx31,
  +   }, {
  +   .name = imx-udc-mx35,
  +   }, {
  +   .name = imx-udc-mx51,
  +   }
  +};
 
 From what I understand balbi's comment, he dislikes this full list of
 device id.  Instead, he prefers to something like below.
 
 static const struct platform_device_id fsl_udc_devtype[] = {
   {
   .name = imx-udc-mx27,
   }, {
   .name = imx-udc-mx51,
   }
 };
 
 It basically tells that we are handling two type of devices here, one
 is imx-udc-mx27 type and the other is imx-udc-mx51 type, with mx25/31/35
 completely compatible with mx27 type.  We choose mx27 instead of mx25
 to define the type because mx27 Si came out earlier than mx25.  That
 said, we generally choose the earlies SoC name to define a particular
 version of IP block, since hardware 

Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used

[Linus Torvalds]

On Tue, Jan 15, 2013 at 6:52 PM, Tejun Heo t...@kernel.org wrote:

 It makes me feel dirty but makes the problem go away and I can't think
 of anything better, so here is the implementation of used async
 workaround.

Ok, people, can we get a tested-by (or Nope, doesn't work) from the
people who saw this?

That said, maybe we could just make the rule be that you can't pick a
default IO scheduler that is modular.

And I *would* like to see the warning we discussed. Maybe there are
other situations that can trigger this?

Because something like that

WARN_ON_ONCE(wait  i_am_async()  system_state == SYSTEM_RUNNING);

in kernel/kmod.c (__request_module()) still sounds like a good idea to
verify that this is the only thing that triggers it (of course, we'd
need to somehow avoid the warning for the known case with the known
workaround).

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

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

[Ming Lei]

On Wed, Jan 16, 2013 at 1:36 AM, Linus Torvalds
torva...@linux-foundation.org wrote:

 Because it's not just sd.c that uses async_schedule(), and would need
 the async synchronize. It's floppy.c, it's generic scsi scanning (so
 scsi tapes etc), and it's libata-core.c.

As discussed previously, only the module which will populate device
node for user space inside async func may require the synchronization,
so that the below

modprobe A
mount /dev/XXX /mnt

script can't be broken, and that should be the original bug report:

   https://bugzilla.kernel.org/attachment.cgi?id=20937

For other modules, looks the synchonization isn't needed, at least there
are lots of other async(work, kthread, ...) things which is scheduled in
driver probe() and no any synchronize is added after the module init()
completes inside loading module. Do we need to add that sync
for all async things inside loading module?

So looks only sd.c and floppy.c are to be synchronized suppose
some sync interfaces are introduced, doesn't it?


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

Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used

[Tejun Heo]

Hello, Linus.

On Tue, Jan 15, 2013 at 07:00:31PM -0800, Linus Torvalds wrote:
 That said, maybe we could just make the rule be that you can't pick a
 default IO scheduler that is modular.

This is definitely much more preferable but it would affect use case
where everything is built modular and the elevator is selected via
kernel param.  This is way outside the usual usage and we can warn
about the new behavior but it still is an observable behavior change.
Do you think this would be okay?

 And I *would* like to see the warning we discussed. Maybe there are
 other situations that can trigger this?
 
 Because something like that
 
 WARN_ON_ONCE(wait  i_am_async()  system_state == SYSTEM_RUNNING);
 
 in kernel/kmod.c (__request_module()) still sounds like a good idea to
 verify that this is the only thing that triggers it (of course, we'd
 need to somehow avoid the warning for the known case with the known
 workaround).

And then this warning can be added without introducing
request_module_but_dont_warn_about_being_called_from_async().

Thanks.

-- 
tejun
--
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] module, async: async_synchronize_full() on module init iff async is used

[Ming Lei]

On Wed, Jan 16, 2013 at 10:52 AM, Tejun Heo t...@kernel.org wrote:
 If the default iosched is built as module, the kernel may deadlock
 while trying to load the iosched module on device probe if the probing
 was running off async.  This is because async_synchronize_full() at
 the end of module init ends up waiting for the async job which
 initiated the module loading.

  async Amodprobe

  1. finds a device
  2. registers the block device
  3. request_module(default iosched)
 4. modprobe in userland
 5. load and init module
 6. async_synchronize_full()

 Async A waits for modprobe to finish in request_module() and modprobe
 waits for async A to finish in async_synchronize_full().

 Because there's no easy to track dependency once control goes out to
 userland, implementing properly nested flushing is difficult.  For
 now, make module init perform async_synchronize_full() iff module init
 has queued async jobs as suggested by Linus.

 This avoids the described deadlock because iosched module doesn't use
 async and thus wouldn't invoke async_synchronize_full().  This is
 hacky and incomplete.  It will deadlock if async module loading nests;
 however, this works around the known problem case and seems to be the
 best of bad options.

 For more details, please refer to the following thread.

   http://thread.gmane.org/gmane.linux.kernel/1420814

 Signed-off-by: Tejun Heo t...@kernel.org
 Reported-by: Alex Riesen raa.l...@gmail.com
 Cc: Linus Torvalds torva...@linux-foundation.org
 ---

Looks it does fix the deadlock problem on my Pandaboard,
also the scsi disk device node(/dev/sdX) comes just
after loading module of 'sd_mod'.

Tested-by: Ming Lei ming@canonical.com

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

Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used

[Linus Torvalds]

On Tue, Jan 15, 2013 at 7:25 PM, Tejun Heo t...@kernel.org wrote:
 Hello, Linus.

 On Tue, Jan 15, 2013 at 07:00:31PM -0800, Linus Torvalds wrote:
 That said, maybe we could just make the rule be that you can't pick a
 default IO scheduler that is modular.

 This is definitely much more preferable but it would affect use case
 where everything is built modular and the elevator is selected via
 kernel param.  This is way outside the usual usage and we can warn
 about the new behavior but it still is an observable behavior change.
 Do you think this would be okay?

I do want the same user-visible semantics, so it's not some one-liner.

The compiled-in elevator would be easy enough to handle in the Kconfig
file (maybe we do already, I didn't even bother to check). The real
problem is the chosen_elevator one, which is dynamic with the kernel
command line. And we could handle that one by just trying to load the
module early (but exactly _when_?) and then instead of looking things
up by name, just keep a pointer to the default elevator around.

But no, it's not just some trivial one-liner. Especially the question
about when to try to load the module that is given on the kernel
command line is not trivial. Do we require that the module is in the
initrd and loadable basically immediate at boot? Do we try again after
switching the root filesystem? Things like that..

 And then this warning can be added without introducing
 request_module_but_dont_warn_about_being_called_from_async().

I do agree that it would be much nicer that way.

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

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

[Alan Stern]

On Tue, 15 Jan 2013, Tejun Heo wrote:

 Hello, Arjan.
 
 On Tue, Jan 15, 2013 at 04:25:54PM -0800, Arjan van de Ven wrote:
  async fundamentally had the concept of a monotonic increasing number,
  and that you could always wait for everyone before me.
  then people (like me) wanted exceptions to what everyone means ;-(
  I'm ok with going back to a single space and simplify the world.
 
 If we want (or need) finer grained operation, we'll probably have to
 head the other direction, so that we can definitively tell that an
 async operation belongs to domains system, module load A and B, so
 that each waiter knows what to wait for.
 
 The current domain implementation is somewhere inbetween.  It's not
 completely simplistic system and at the same time not developed enough
 to do properly stacked flushing.

I like your idea of chronological synchronization: Insist that anybody
who wants to flush async jobs must get a cookie, and then only allow
them to wait for async jobs started after the cookie was issued.

I don't know if this is possible with the current implementation.  It 
would require changing every call to async_synchronize_*(), and in a 
nontrivial way.  But it might provide a proper solution to all these 
problems.

Can you think of any reasons why it wouldn't work in principle?  It 
would prevent code from doing wait until all currently-running async 
jobs have finished -- but arguably, nobody should be allowed to do 
that anyway.

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] module, async: async_synchronize_full() on module init iff async is used

[Rusty Russell]

Tejun Heo t...@kernel.org writes:
 --- a/kernel/module.c
 +++ b/kernel/module.c
 @@ -3058,8 +3064,25 @@ static int do_init_module(struct module
   blocking_notifier_call_chain(module_notify_list,
MODULE_STATE_LIVE, mod);
  
 - /* We need to finish all async code before the module init sequence is 
 done */
 - async_synchronize_full();

Linus put async_synchronize_full() here as a fix but beware: you can
start using the module before this call.  Normally the potential caller
is the one requesting the module load so it works, but if we get more
async stuff we may land in that hole.

Changing every caller of any async-initializing service is not going to
be pretty, but maybe put an async_cookie_t in struct module for
module_init to use, and sync it in try_module_get()?  Which would now
need a can_sleep flag... but the result would be more async.

Cheers,
Rusty.
--
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 3.8-rc1 - another regression on USB :-(

[Woody Suwalski]

Alan Stern wrote:

On Sat, 12 Jan 2013, Andreas Mohr wrote:


There's of course the EHCI vs. UHCI(/OHCI) duality
(EHCI host controller responsible for high speed transfers,
the other for 1.1 full speed, both serving the same port connectors).
So if the coordination between the two is a problem,
you might end up with merely full speed on a 2.0 port.

And with drivers builtin vs. module, the init sequence/timing
might possibly be affected - right?
Perhaps this got worsened by semi-recent driver init kernel changes?
(AFAIR the kernel was changed to init more things in parallel,
for faster bootup). So maybe that affected EHCI vs. UHCI coordination timing.

Another important change is that the EHCI driver is now split into two
modules.  That can slow down loading and affect the timing.

Alan Stern


My testcase is a live initramfs + squash root.
The boot logic is as stable as can be - unchanged since 2.6.2x kernels.
And it was working fine till 3.8-rc1.

The modules are insmoded in a fixed order:
usb-common, usbcore, xhci-hcd, ehci-hcd, uhci-hcd, ohci-hcd, usbhid, 
usb_storage,...


If all USB is built as modules - I get read errors from USB drives when 
accessing squash image, boot fails.
If usb-common and usbcore are built in, system seems to crawl with a 
very slow USB, but boots. That could be caused by timing between hcd 
modules.
If usb-common, usbcore and ehci-hcd are built-in, all works OK like 
before 3.8.
I was testing on machines  without xhci or ohci hardware, so these 
drivers probably are not playing any role.
I have retried initramfs with a 1s sleep between insmods to verify if it 
is timing - still the same read errors - so the main issue is _not_ timing.
The read errors problem is 100% reproducible for me, the blocks where 
read fails are not fixed - every (failed) boot errors start appearing in 
a bit different location.
Just selecting a differently - configured  kernel image makes the boot 
work, so it is not a problem of squash image, USB drive, squashfs driver.


Scratching my head loudly,
Woody

--
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] HID: add support for Sony RF receiver with USB product id 0x0374

[Fernando Luis Vazquez Cao]

Hi Jiri,

On 2013/01/16 01:02, Jiri Kosina wrote:

On Tue, 15 Jan 2013, Fernando Luis Vázquez Cao wrote:


Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
a RF receiver, multi-interface USB device 054c:0374, that is used to connect
a wireless keyboard and a wireless mouse.

The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not
seem to be generating any pointer events. The problem is that the mouse pointer
is wrongly declared as a constant non-data variable in the report descriptor
(see lsusb and usbhid-dump output below), with the consequence that it is
ignored by the HID code.

Add this device to the have-special-driver list and fix up the report
descriptor in the Sony-specific driver which happens to already have a fixup
for a similar firmware bug.

Applied, thanks.


Thank you.

I noticed that the patch was tagged for-3.9. Does this mean
that it is too late to get it merged during the current release
cycle?

If possible, I would like to get it backported to 3.7-stable (and
possibly 3.2 stable), since without it a whole family of Sony
desktop computers is unusable under Linux out of the box.
Should I do it myself or do you have a process in place for HID
stable patches?

Regards,
Fernando
--
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 1/4] ARM: Exynos5250: Enabling ehci-s5p driver

[Vivek Gautam]

On Tue, Jan 15, 2013 at 7:08 PM, Vivek Gautam gautam.vi...@samsung.com wrote:
 Adding EHCI device tree node for Exynos5250 along with
 the device base adress and gpio line for vbus.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Acked-by: Jingoo Han jg1@samsung.com
 Acked-by: Grant Likely grant.lik...@secretlab.ca
 ---
  .../devicetree/bindings/usb/exynos-usb.txt |   25 
 
  arch/arm/boot/dts/exynos5250-smdk5250.dts  |4 +++
  arch/arm/boot/dts/exynos5250.dtsi  |6 
  3 files changed, 35 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt

 diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
 b/Documentation/devicetree/bindings/usb/exynos-usb.txt
 new file mode 100644
 index 000..e8bbb47
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
 @@ -0,0 +1,25 @@
 +Samsung Exynos SoC USB controller
 +
 +The USB devices interface with USB controllers on Exynos SOCs.
 +The device node has following properties.
 +
 +EHCI
 +Required properties:
 + - compatible: should be samsung,exynos4210-ehci for USB 2.0
 +   EHCI controller in host mode.
 + - reg: physical base address of the controller and length of memory mapped
 +   region.
 + - interrupts: interrupt number to the cpu.
 +
 +Optional properties:
 + - samsung,vbus-gpio:  if present, specifies the GPIO that
 +   needs to be pulled up for the bus to be powered.
 +
 +Example:
 +
 +   usb@1211 {
 +   compatible = samsung,exynos4210-ehci;
 +   reg = 0x1211 0x100;
 +   interrupts = 0 71 0;
 +   samsung,vbus-gpio = gpx2 6 1 3 3;
 +   };
 diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
 b/arch/arm/boot/dts/exynos5250-smdk5250.dts
 index 942d576..7363e14 100644
 --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
 +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
 @@ -204,4 +204,8 @@
 samsung,mfc-r = 0x4300 0x80;
 samsung,mfc-l = 0x5100 0x80;
 };
 +
 +   usb@1211 {
 +   samsung,vbus-gpio = gpx2 6 1 3 3;
 +   };

Add required vbus gpio for snow board also here.

  };


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

[PATCH v5 1/4] ARM: Exynos5250: Enabling ehci-s5p driver

[Vivek Gautam]

Adding EHCI device tree node for Exynos5250 along with
the device base adress and gpio line for vbus.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---

Changes from v4:
 - Added gpio line for VBUS of USB2.0 on snow board.

 .../devicetree/bindings/usb/exynos-usb.txt |   25 
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |4 +++
 arch/arm/boot/dts/exynos5250-snow.dts  |4 +++
 arch/arm/boot/dts/exynos5250.dtsi  |6 
 4 files changed, 39 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
new file mode 100644
index 000..e8bbb47
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -0,0 +1,25 @@
+Samsung Exynos SoC USB controller
+
+The USB devices interface with USB controllers on Exynos SOCs.
+The device node has following properties.
+
+EHCI
+Required properties:
+ - compatible: should be samsung,exynos4210-ehci for USB 2.0
+   EHCI controller in host mode.
+ - reg: physical base address of the controller and length of memory mapped
+   region.
+ - interrupts: interrupt number to the cpu.
+
+Optional properties:
+ - samsung,vbus-gpio:  if present, specifies the GPIO that
+   needs to be pulled up for the bus to be powered.
+
+Example:
+
+   usb@1211 {
+   compatible = samsung,exynos4210-ehci;
+   reg = 0x1211 0x100;
+   interrupts = 0 71 0;
+   samsung,vbus-gpio = gpx2 6 1 3 3;
+   };
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 942d576..7363e14 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -204,4 +204,8 @@
samsung,mfc-r = 0x4300 0x80;
samsung,mfc-l = 0x5100 0x80;
};
+
+   usb@1211 {
+   samsung,vbus-gpio = gpx2 6 1 3 3;
+   };
 };
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index 17dd951..47b6b84 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -40,4 +40,8 @@
gpc4 5 2 3 0, gpc4 6 2 3 0;
};
};
+
+   usb@1211 {
+   samsung,vbus-gpio = gpx1 1 1 3 3;
+   };
 };
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 30485de..2cbe53e 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -275,6 +275,12 @@
#size-cells = 0;
};
 
+   usb@1211 {
+   compatible = samsung,exynos4210-ehci;
+   reg = 0x1211 0x100;
+   interrupts = 0 71 0;
+   };
+
amba {
#address-cells = 1;
#size-cells = 1;
-- 
1.7.6.5

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

Re: [RFC PATCH 0/7] usb: musb: add driver for control module

[kishon]

Hi Ravi,

On Tuesday 15 January 2013 09:36 PM, B, Ravi wrote:

Hi,

On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote:

Hi Arnd,

On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote:

On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:

Added a new driver for the usb part of control module.

This has an

API to power on the USB2 phy and an API to write to the mailbox
depending on whether MUSB has to act in host mode or in

device mode.


Writing to control module registers for doing the above

task which

was previously done in omap glue and in omap-usb2 phy is removed.

Also added the dt data to get MUSB working in OMAP platforms.
This series has patches for both drivers and ARCH

folders, so If it

has to be split I'll do it.



The series looks good to me, I just had a minor comment on

one patch.


One a somewhat related topic, I wonder whether there are

any plans on

your side to change this driver to support multiple bus

glues to be

built for one kernel image. With a multiplatform kernel,

we may need

all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance.


We don't have plans as of now. I actually don't expect any

changes in

the driver other than the Kconfig changes. Anyways the

probe of glue's

other than the platform it's running won't get called. right Felipe?


If understand correctly the control module driver used to configure the 
respective usb phy of SoC to respective usb modes using the common set of 
control module APIs.
What if, if control module interface (register defintions) varies b/w 
different revision or spin of same type of SoCs, if usbphy type is changed.
Well in that case, we can write to the registers based on the IP 
revision check (I think thats the common practice to do).


In this case whether the single instance of control module driver is 
good enough to cater of all cpu types of same SoC series ?
Of course. I don't see why we can't have the same driver to handle 
different versions of the same IP.
The only reason where we might need multiple instance is if the SoC have 
multiple control module which Arnd already pointed out.



Whether cpu_is_xxx() can be used to differentiate b/w different cpu types in CM 
driver?

Not needed at all IMHO. We can use revision register to differentiate.

Btw I think Felipe looped you for a different reason ;-)

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

Re: [PATCH v9] usb_8dev: Add support for USB2CAN interface from 8 devices

[Oliver Hartkopp]

On 15.01.2013 23:05, Bernd Krumböck wrote:

 [  960.047130] usb_8dev 2-1.4:1.0 can2: Unknown status/error message (0)
 [  976.544343] usb_8dev 2-1.4:1.0 can2: Unknown status/error message (0)

 Did you check these kind of 'unfriendly user' tests?
 
 Not really. At least I don't know what the driver should do. Let me know
 if you have some suggestions.
 


Pulling/reconnecting CAN and/or USB under heavy CAN load ;-)

 E.g. pulling the USB under receive load brings this output:

 [ 1343.786427] usb_8dev 2-1.4:1.0 can2: Rx URB aborted (-32)
 [ 1343.786640] usb_8dev 2-1.4:1.0 can2: Rx URB aborted (-32)

 (..) another 344 of these URB aborted messages
 
 a bit much...
 
 Maybe we should suppress this messages?
 


I did not had the time for tests yesterday.
But i will attach my full-load CAN generator today.

Regarding the USB abort messages, i'll try the same with my other USB adapters
and how they behave under these conditions.

I remember some tests for the PEAK USB mainlining ... let's see.

Regards,
Oliver

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

Re: [PATCH] usb: phy: remove unused APIs from Tegra PHY.

[Felipe Balbi]

Hi,

On Tue, Jan 15, 2013 at 11:04:51AM -0700, Stephen Warren wrote:
 On 01/15/2013 03:19 AM, Venu Byravarasu wrote:
  As tegra_usb_phy_clk_disable/enable() are not being
  used, removing them.
 
 Greg, Felipe,
 
 Again if I may, I'll take this through the Tegra tree. I think the next
 set of patches that Venu posts should actually expose the dependencies
 between his USB patches and the Tegra clock framework rework, which are
 why I want to do this.

that should be ok:

Acked-by: Felipe Balbi ba...@ti.com

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC PATCH 0/7] usb: musb: add driver for control module

[Felipe Balbi]

On Wed, Jan 16, 2013 at 11:31:32AM +0530, kishon wrote:
 Hi Ravi,
 
 On Tuesday 15 January 2013 09:36 PM, B, Ravi wrote:
 Hi,
 
 On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote:
 Hi Arnd,
 
 On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote:
 On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
 Added a new driver for the usb part of control module.
 This has an
 API to power on the USB2 phy and an API to write to the mailbox
 depending on whether MUSB has to act in host mode or in
 device mode.
 
 Writing to control module registers for doing the above
 task which
 was previously done in omap glue and in omap-usb2 phy is removed.
 
 Also added the dt data to get MUSB working in OMAP platforms.
 This series has patches for both drivers and ARCH
 folders, so If it
 has to be split I'll do it.
 
 
 The series looks good to me, I just had a minor comment on
 one patch.
 
 One a somewhat related topic, I wonder whether there are
 any plans on
 your side to change this driver to support multiple bus
 glues to be
 built for one kernel image. With a multiplatform kernel,
 we may need
 all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance.
 
 We don't have plans as of now. I actually don't expect any
 changes in
 the driver other than the Kconfig changes. Anyways the
 probe of glue's
 other than the platform it's running won't get called. right Felipe?
 
 If understand correctly the control module driver used to configure the 
 respective usb phy of SoC to respective usb modes using the common set of 
 control module APIs.
 What if, if control module interface (register defintions) varies b/w
 different revision or spin of same type of SoCs, if usbphy type is
 changed.
 Well in that case, we can write to the registers based on the IP
 revision check (I think thats the common practice to do).
 
 In this case whether the single instance of control module driver is
 good enough to cater of all cpu types of same SoC series ?
 Of course. I don't see why we can't have the same driver to handle
 different versions of the same IP.
 The only reason where we might need multiple instance is if the SoC
 have multiple control module which Arnd already pointed out.
 
 Whether cpu_is_xxx() can be used to differentiate b/w different cpu types in 
 CM driver?
 Not needed at all IMHO. We can use revision register to differentiate.
 
 Btw I think Felipe looped you for a different reason ;-)

right, it was to look at removing mach/* inclusion from all
davinci-link glue layers (they should be combined, btw).

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4 2/4] ARM: Exynos5250: Enabling ohci-exynos driver

[Tomasz Figa]

Hi Vivek,

On Tuesday 15 of January 2013 19:08:30 Vivek Gautam wrote:
 Adding OHCI device tree node for Exynos5250 along with
 the device base address.
 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Acked-by: Jingoo Han jg1@samsung.com
 Acked-by: Grant Likely grant.lik...@secretlab.ca
 ---
  .../devicetree/bindings/usb/exynos-usb.txt |   15
 +++ arch/arm/boot/dts/exynos5250.dtsi  |   
 6 ++ 2 files changed, 21 insertions(+), 0 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
 b/Documentation/devicetree/bindings/usb/exynos-usb.txt index
 e8bbb47..f66fcdd 100644
 --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
 +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
 @@ -23,3 +23,18 @@ Example:
   interrupts = 0 71 0;
   samsung,vbus-gpio = gpx2 6 1 3 3;
   };
 +
 +OHCI
 +Required properties:
 + - compatible: should be samsung,exynos4210-ohci for USB 2.0
 +   OHCI companion controller in host mode.
 + - reg: physical base address of the controller and length of memory
 mapped +   region.
 + - interrupts: interrupt number to the cpu.
 +
 +Example:
 + usb@1212 {
 + compatible = samsung,exynos4210-ohci;
 + reg = 0x1212 0x100;
 + interrupts = 0 71 0;
 + };
 diff --git a/arch/arm/boot/dts/exynos5250.dtsi
 b/arch/arm/boot/dts/exynos5250.dtsi index 2cbe53e..ebb0907 100644
 --- a/arch/arm/boot/dts/exynos5250.dtsi
 +++ b/arch/arm/boot/dts/exynos5250.dtsi
 @@ -281,6 +281,12 @@
   interrupts = 0 71 0;
   };
 
 + usb@1212 {
 + compatible = samsung,exynos4210-ohci;
 + reg = 0x1212 0x100;
 + interrupts = 0 71 0;

For Samsung platforms we decided per board enabling of nodes and so this 
node should also contain:

status = disabled;

while in dts file of board using ohci there would be an overriding entry:

usb@1212 {
status = okay;
};

I know that Exynos5250 has not been yet converted into this convention, 
but using it when adding new devices will simplify the process.

Best regards,
Tomasz

--
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 3/4] ARM: Exynos5250: Add clock information for dwc3-exynos

[Tomasz Figa]

Hi Vivek,

Don't you need also some clkdev lookup entry to make the clock available 
in the driver?

Best regards,
Tomasz

On Tuesday 15 of January 2013 19:08:31 Vivek Gautam wrote:
 Adding necessary device clock to exynos5 needed for
 the DWC3 controller.
 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
  arch/arm/mach-exynos/clock-exynos5.c |   24 
  1 files changed, 24 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-exynos/clock-exynos5.c
 b/arch/arm/mach-exynos/clock-exynos5.c index 0208c3a..13af020 100644
 --- a/arch/arm/mach-exynos/clock-exynos5.c
 +++ b/arch/arm/mach-exynos/clock-exynos5.c
 @@ -757,6 +757,11 @@ static struct clk exynos5_init_clocks_off[] = {
   .enable = exynos5_clk_ip_fsys_ctrl ,
   .ctrlbit= (1  18),
   }, {
 + .name   = usbdrd30,
 + .parent = exynos5_clk_aclk_200.clk,
 + .enable = exynos5_clk_ip_fsys_ctrl,
 + .ctrlbit= (1  19),
 + }, {
   .name   = usbotg,
   .enable = exynos5_clk_ip_fsys_ctrl,
   .ctrlbit= (1  7),
 @@ -1035,6 +1040,16 @@ static struct clksrc_sources exynos5_clkset_group
 = { .nr_sources   = ARRAY_SIZE(exynos5_clkset_group_list),
  };
 
 +struct clk *exynos5_clkset_usbdrd30_list[] = {
 + [0] = exynos5_clk_mout_mpll.clk,
 + [1] = exynos5_clk_mout_cpll.clk,
 +};
 +
 +struct clksrc_sources exynos5_clkset_usbdrd30 = {
 + .sources= exynos5_clkset_usbdrd30_list,
 + .nr_sources = ARRAY_SIZE(exynos5_clkset_usbdrd30_list),
 +};
 +
  /* Possible clock sources for aclk_266_gscl_sub Mux */
  static struct clk *clk_src_gscl_266_list[] = {
   [0] = clk_ext_xtal_mux,
 @@ -1329,6 +1344,15 @@ static struct clksrc_clk exynos5_clksrcs[] = {
   .parent = exynos5_clk_mout_cpll.clk,
   },
   .reg_div = { .reg = EXYNOS5_CLKDIV_GEN, .shift = 4, .size = 3 
},
 + }, {
 + .clk= {
 + .name   = sclk_usbdrd30,
 + .enable = exynos5_clksrc_mask_fsys_ctrl,
 + .ctrlbit= (1  28),
 + },
 + .sources = exynos5_clkset_usbdrd30,
 + .reg_src = { .reg = EXYNOS5_CLKSRC_FSYS, .shift = 28, .size = 
1 },
 + .reg_div = { .reg = EXYNOS5_CLKDIV_FSYS0, .shift = 24, .size = 
4 },
   },
  };
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/4] ARM: Exynos5250: Enabling dwc3-exynos driver

[Tomasz Figa]

Hi Vivek,

Same comment as for patch 2.

Best regards,
Tomasz

On Tuesday 15 of January 2013 19:08:32 Vivek Gautam wrote:
 Adding DWC3 device tree node for Exynos5250 needed to
 parse device tree data.
 Also enabling XHCI support on exynos5250.
 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
  .../devicetree/bindings/usb/exynos-usb.txt |   14
 ++ arch/arm/boot/dts/exynos5250.dtsi  |   
 6 ++ arch/arm/mach-exynos/Kconfig   |1 +
  3 files changed, 21 insertions(+), 0 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
 b/Documentation/devicetree/bindings/usb/exynos-usb.txt index
 f66fcdd..d660410 100644
 --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
 +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
 @@ -38,3 +38,17 @@ Example:
   reg = 0x1212 0x100;
   interrupts = 0 71 0;
   };
 +
 +DWC3
 +Required properties:
 + - compatible: should be samsung,exynos5250-dwc3 for USB 3.0 DWC3
 controller. + - reg: physical base address of the controller and length
 of memory mapped +   region.
 + - interrupts: interrupt number to the cpu.
 +
 +Example:
 + usb@1200 {
 + compatible = samsung,exynos5250-dwc3;
 + reg = 0x1200 0x1;
 + interrupts = 0 72 0;
 + };
 diff --git a/arch/arm/boot/dts/exynos5250.dtsi
 b/arch/arm/boot/dts/exynos5250.dtsi index ebb0907..a747524 100644
 --- a/arch/arm/boot/dts/exynos5250.dtsi
 +++ b/arch/arm/boot/dts/exynos5250.dtsi
 @@ -275,6 +275,12 @@
   #size-cells = 0;
   };
 
 + usb@1200 {
 + compatible = samsung,exynos5250-dwc3;
 + reg = 0x1200 0x1;
 + interrupts = 0 72 0;
 + };
 +
   usb@1211 {
   compatible = samsung,exynos4210-ehci;
   reg = 0x1211 0x100;
 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index d26c9f9..e62fd20 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -428,6 +428,7 @@ config MACH_EXYNOS5_DT
   depends on ARCH_EXYNOS5
   select ARM_AMBA
   select USE_OF
 + select USB_ARCH_HAS_XHCI
   help
 Machine support for Samsung EXYNOS5 machine with device tree
 enabled. Select this if a fdt blob is available for the EXYNOS5 SoC
 based board.
--
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