Re: [V6 PATCH 01/16] usb: phy: mv_usb2: add PHY driver for marvell usb2 controller
Hi, On Wednesday 06 February 2013 12:53 PM, Chao Xie wrote: The PHY is seperated from usb controller. The usb controller used in marvell pxa168/pxa910/mmp2 are same, but PHY initialization may be different. the usb controller can support udc/otg/ehci, and for each of the mode, it need PHY to initialized before use the controller. Direclty writing the phy driver will make the usb controller driver to be simple and portable. The PHY driver will be used by marvell udc/otg/ehci. Signed-off-by: Chao Xie chao@marvell.com --- drivers/usb/phy/Kconfig |7 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/mv_usb2_phy.c| 454 ++ include/linux/platform_data/mv_usb.h |9 +- include/linux/usb/mv_usb2.h | 43 5 files changed, 511 insertions(+), 3 deletions(-) create mode 100644 drivers/usb/phy/mv_usb2_phy.c create mode 100644 include/linux/usb/mv_usb2.h diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 65217a5..5479760 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -73,3 +73,10 @@ config SAMSUNG_USBPHY help Enable this to support Samsung USB phy controller for samsung SoCs. + +config MV_USB2_PHY + tristate Marvell USB 2.0 PHY Driver + depends on USB || USB_GADGET + help + Enable this to support Marvell USB 2.0 phy driver for Marvell + SoC. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index b13faa1..3835316 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -12,3 +12,4 @@ obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o obj-$(CONFIG_USB_RCAR_PHY)+= rcar-phy.o obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o +obj-$(CONFIG_MV_USB2_PHY) += mv_usb2_phy.o diff --git a/drivers/usb/phy/mv_usb2_phy.c b/drivers/usb/phy/mv_usb2_phy.c new file mode 100644 index 000..c2bccae --- /dev/null +++ b/drivers/usb/phy/mv_usb2_phy.c @@ -0,0 +1,454 @@ +/* + * Copyright (C) 2010 Google, Inc. + * + * Author: + * Chao Xie xiechao.m...@gmail.com + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * 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/resource.h +#include linux/delay.h +#include linux/slab.h +#include linux/of.h +#include linux/of_device.h +#include linux/io.h +#include linux/err.h +#include linux/clk.h +#include linux/export.h +#include linux/module.h +#include linux/platform_device.h +#include linux/platform_data/mv_usb.h +#include linux/usb/mv_usb2.h + +/* phy regs */ +#define UTMI_REVISION 0x0 +#define UTMI_CTRL 0x4 +#define UTMI_PLL 0x8 +#define UTMI_TX0xc +#define UTMI_RX0x10 +#define UTMI_IVREF 0x14 +#define UTMI_T00x18 +#define UTMI_T10x1c +#define UTMI_T20x20 +#define UTMI_T30x24 +#define UTMI_T40x28 +#define UTMI_T50x2c +#define UTMI_RESERVE 0x30 +#define UTMI_USB_INT 0x34 +#define UTMI_DBG_CTL 0x38 +#define UTMI_OTG_ADDON 0x3c + +/* For UTMICTRL Register */ +#define UTMI_CTRL_USB_CLK_EN(1 31) +/* pxa168 */ +#define UTMI_CTRL_SUSPEND_SET1 (1 30) +#define UTMI_CTRL_SUSPEND_SET2 (1 29) +#define UTMI_CTRL_RXBUF_PDWN(1 24) +#define UTMI_CTRL_TXBUF_PDWN(1 11) + +#define UTMI_CTRL_INPKT_DELAY_SHIFT 30 +#define UTMI_CTRL_INPKT_DELAY_SOF_SHIFT28 +#define UTMI_CTRL_PU_REF_SHIFT 20 +#define UTMI_CTRL_ARC_PULLDN_SHIFT 12 +#define UTMI_CTRL_PLL_PWR_UP_SHIFT 1 +#define UTMI_CTRL_PWR_UP_SHIFT 0 + +/* For UTMI_PLL Register */ +#define UTMI_PLL_PLLCALI12_SHIFT 29 +#define UTMI_PLL_PLLCALI12_MASK(0x3 29) + +#define UTMI_PLL_PLLVDD18_SHIFT27 +#define UTMI_PLL_PLLVDD18_MASK (0x3 27) + +#define UTMI_PLL_PLLVDD12_SHIFT25 +#define UTMI_PLL_PLLVDD12_MASK (0x3 25) + +#define UTMI_PLL_CLK_BLK_EN_SHIFT 24 +#define CLK_BLK_EN (0x1 24) +#define PLL_READY (0x1 23) +#define KVCO_EXT(0x1 22) +#define VCOCAL_START
Re: [V6 PATCH 01/16] usb: phy: mv_usb2: add PHY driver for marvell usb2 controller
On Wed, Feb 6, 2013 at 4:10 PM, kishon kis...@ti.com wrote: Hi, On Wednesday 06 February 2013 12:53 PM, Chao Xie wrote: The PHY is seperated from usb controller. The usb controller used in marvell pxa168/pxa910/mmp2 are same, but PHY initialization may be different. the usb controller can support udc/otg/ehci, and for each of the mode, it need PHY to initialized before use the controller. Direclty writing the phy driver will make the usb controller driver to be simple and portable. The PHY driver will be used by marvell udc/otg/ehci. Signed-off-by: Chao Xie chao@marvell.com --- drivers/usb/phy/Kconfig |7 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/mv_usb2_phy.c| 454 ++ include/linux/platform_data/mv_usb.h |9 +- include/linux/usb/mv_usb2.h | 43 5 files changed, 511 insertions(+), 3 deletions(-) create mode 100644 drivers/usb/phy/mv_usb2_phy.c create mode 100644 include/linux/usb/mv_usb2.h diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 65217a5..5479760 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -73,3 +73,10 @@ config SAMSUNG_USBPHY help Enable this to support Samsung USB phy controller for samsung SoCs. + +config MV_USB2_PHY + tristate Marvell USB 2.0 PHY Driver + depends on USB || USB_GADGET + help + Enable this to support Marvell USB 2.0 phy driver for Marvell + SoC. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index b13faa1..3835316 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -12,3 +12,4 @@ obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o obj-$(CONFIG_USB_RCAR_PHY)+= rcar-phy.o obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o +obj-$(CONFIG_MV_USB2_PHY) += mv_usb2_phy.o diff --git a/drivers/usb/phy/mv_usb2_phy.c b/drivers/usb/phy/mv_usb2_phy.c new file mode 100644 index 000..c2bccae --- /dev/null +++ b/drivers/usb/phy/mv_usb2_phy.c @@ -0,0 +1,454 @@ +/* + * Copyright (C) 2010 Google, Inc. + * + * Author: + * Chao Xie xiechao.m...@gmail.com + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * 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/resource.h +#include linux/delay.h +#include linux/slab.h +#include linux/of.h +#include linux/of_device.h +#include linux/io.h +#include linux/err.h +#include linux/clk.h +#include linux/export.h +#include linux/module.h +#include linux/platform_device.h +#include linux/platform_data/mv_usb.h +#include linux/usb/mv_usb2.h + +/* phy regs */ +#define UTMI_REVISION 0x0 +#define UTMI_CTRL 0x4 +#define UTMI_PLL 0x8 +#define UTMI_TX0xc +#define UTMI_RX0x10 +#define UTMI_IVREF 0x14 +#define UTMI_T00x18 +#define UTMI_T10x1c +#define UTMI_T20x20 +#define UTMI_T30x24 +#define UTMI_T40x28 +#define UTMI_T50x2c +#define UTMI_RESERVE 0x30 +#define UTMI_USB_INT 0x34 +#define UTMI_DBG_CTL 0x38 +#define UTMI_OTG_ADDON 0x3c + +/* For UTMICTRL Register */ +#define UTMI_CTRL_USB_CLK_EN(1 31) +/* pxa168 */ +#define UTMI_CTRL_SUSPEND_SET1 (1 30) +#define UTMI_CTRL_SUSPEND_SET2 (1 29) +#define UTMI_CTRL_RXBUF_PDWN(1 24) +#define UTMI_CTRL_TXBUF_PDWN(1 11) + +#define UTMI_CTRL_INPKT_DELAY_SHIFT 30 +#define UTMI_CTRL_INPKT_DELAY_SOF_SHIFT28 +#define UTMI_CTRL_PU_REF_SHIFT 20 +#define UTMI_CTRL_ARC_PULLDN_SHIFT 12 +#define UTMI_CTRL_PLL_PWR_UP_SHIFT 1 +#define UTMI_CTRL_PWR_UP_SHIFT 0 + +/* For UTMI_PLL Register */ +#define UTMI_PLL_PLLCALI12_SHIFT 29 +#define UTMI_PLL_PLLCALI12_MASK(0x3 29) + +#define UTMI_PLL_PLLVDD18_SHIFT27 +#define UTMI_PLL_PLLVDD18_MASK (0x3 27) + +#define UTMI_PLL_PLLVDD12_SHIFT25 +#define UTMI_PLL_PLLVDD12_MASK (0x3 25) + +#define UTMI_PLL_CLK_BLK_EN_SHIFT 24 +#define CLK_BLK_EN
Re: [PATCH] usb: otg: use try_module_get in all usb_get_phy functions and add missing module_put
On Fri, Feb 01, 2013 at 10:48:30PM +0100, Marc Kleine-Budde wrote:
In patch 5d3c28b usb: otg: add device tree support to otg library
devm_usb_get_phy_by_phandle() was added. It uses try_module_get() to lock the
phy driver in memory. The corresponding module_put() is missing in that patch.
This patch adds try_module_get() to usb_get_phy() and usb_get_phy_dev().
Further the missing module_put() is added to usb_put_phy().
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
---
Kishon, does this look ok for you ?
Hello,
this patch applies to Greg's usb-next tree. I hope the module counter is now
consistent.
Marc
drivers/usb/otg/otg.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index e181439..2bd03d2 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -130,7 +130,7 @@ struct usb_phy *usb_get_phy(enum usb_phy_type type)
spin_lock_irqsave(phy_lock, flags);
phy = __usb_find_phy(phy_list, type);
- if (IS_ERR(phy)) {
+ if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
pr_err(unable to find transceiver of type %s\n,
usb_phy_type_string(type));
goto err0;
@@ -228,7 +228,7 @@ struct usb_phy *usb_get_phy_dev(struct device *dev, u8
index)
spin_lock_irqsave(phy_lock, flags);
phy = __usb_find_phy_dev(dev, phy_bind_list, index);
- if (IS_ERR(phy)) {
+ if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
pr_err(unable to find transceiver\n);
goto err0;
}
@@ -301,8 +301,12 @@ EXPORT_SYMBOL(devm_usb_put_phy);
*/
void usb_put_phy(struct usb_phy *x)
{
- if (x)
+ if (x) {
+ struct module *owner = x-dev-driver-owner;
+
put_device(x-dev);
+ module_put(owner);
+ }
}
EXPORT_SYMBOL(usb_put_phy);
--
1.7.10.4
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: otg: use try_module_get in all usb_get_phy functions and add missing module_put
On Wednesday 06 February 2013 01:58 PM, Felipe Balbi wrote:
On Fri, Feb 01, 2013 at 10:48:30PM +0100, Marc Kleine-Budde wrote:
In patch 5d3c28b usb: otg: add device tree support to otg library
devm_usb_get_phy_by_phandle() was added. It uses try_module_get() to lock the
phy driver in memory. The corresponding module_put() is missing in that patch.
This patch adds try_module_get() to usb_get_phy() and usb_get_phy_dev().
Further the missing module_put() is added to usb_put_phy().
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
---
Kishon, does this look ok for you ?
yes Felipe.
Reviewed-by: Kishon Vijay Abraham I kis...@ti.com
Thanks
Kishon
Hello,
this patch applies to Greg's usb-next tree. I hope the module counter is now
consistent.
Marc
drivers/usb/otg/otg.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index e181439..2bd03d2 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -130,7 +130,7 @@ struct usb_phy *usb_get_phy(enum usb_phy_type type)
spin_lock_irqsave(phy_lock, flags);
phy = __usb_find_phy(phy_list, type);
- if (IS_ERR(phy)) {
+ if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
pr_err(unable to find transceiver of type %s\n,
usb_phy_type_string(type));
goto err0;
@@ -228,7 +228,7 @@ struct usb_phy *usb_get_phy_dev(struct device *dev, u8
index)
spin_lock_irqsave(phy_lock, flags);
phy = __usb_find_phy_dev(dev, phy_bind_list, index);
- if (IS_ERR(phy)) {
+ if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
pr_err(unable to find transceiver\n);
goto err0;
}
@@ -301,8 +301,12 @@ EXPORT_SYMBOL(devm_usb_put_phy);
*/
void usb_put_phy(struct usb_phy *x)
{
- if (x)
+ if (x) {
+ struct module *owner = x-dev-driver-owner;
+
put_device(x-dev);
+ module_put(owner);
+ }
}
EXPORT_SYMBOL(usb_put_phy);
--
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] usb: otg: use try_module_get in all usb_get_phy functions and add missing module_put
On Fri, Feb 01, 2013 at 10:48:30PM +0100, Marc Kleine-Budde wrote:
In patch 5d3c28b usb: otg: add device tree support to otg library
devm_usb_get_phy_by_phandle() was added. It uses try_module_get() to lock the
phy driver in memory. The corresponding module_put() is missing in that patch.
This patch adds try_module_get() to usb_get_phy() and usb_get_phy_dev().
Further the missing module_put() is added to usb_put_phy().
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
Acked-by: Felipe Balbi ba...@ti.com
---
Hello,
this patch applies to Greg's usb-next tree. I hope the module counter is now
consistent.
Marc
drivers/usb/otg/otg.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index e181439..2bd03d2 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -130,7 +130,7 @@ struct usb_phy *usb_get_phy(enum usb_phy_type type)
spin_lock_irqsave(phy_lock, flags);
phy = __usb_find_phy(phy_list, type);
- if (IS_ERR(phy)) {
+ if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
pr_err(unable to find transceiver of type %s\n,
usb_phy_type_string(type));
goto err0;
@@ -228,7 +228,7 @@ struct usb_phy *usb_get_phy_dev(struct device *dev, u8
index)
spin_lock_irqsave(phy_lock, flags);
phy = __usb_find_phy_dev(dev, phy_bind_list, index);
- if (IS_ERR(phy)) {
+ if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
pr_err(unable to find transceiver\n);
goto err0;
}
@@ -301,8 +301,12 @@ EXPORT_SYMBOL(devm_usb_put_phy);
*/
void usb_put_phy(struct usb_phy *x)
{
- if (x)
+ if (x) {
+ struct module *owner = x-dev-driver-owner;
+
put_device(x-dev);
+ module_put(owner);
+ }
}
EXPORT_SYMBOL(usb_put_phy);
--
1.7.10.4
--
balbi
signature.asc
Description: Digital signature
[PATCH] usb: gadget: make usb functions to load before gadget driver
The current ordering in makefile makes gadget drivers to be loaded before usb functions making usb_get_function_instance() to fail when the modules are *built-in* the kernel. Changed the ordering here so that USB functions are loaded before gadget drivers. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- drivers/usb/gadget/Makefile | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 97a13c3..82fb225 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -35,6 +35,12 @@ mv_udc-y := mv_udc_core.o obj-$(CONFIG_USB_FUSB300) += fusb300_udc.o obj-$(CONFIG_USB_MV_U3D) += mv_u3d_core.o +# USB Functions +obj-$(CONFIG_USB_F_ACM)+= f_acm.o +f_ss_lb-y := f_loopback.o f_sourcesink.o +obj-$(CONFIG_USB_F_SS_LB) += f_ss_lb.o +obj-$(CONFIG_USB_U_SERIAL) += u_serial.o + # # USB gadget drivers # @@ -74,9 +80,3 @@ obj-$(CONFIG_USB_G_WEBCAM)+= g_webcam.o obj-$(CONFIG_USB_G_NCM)+= g_ncm.o obj-$(CONFIG_USB_G_ACM_MS) += g_acm_ms.o obj-$(CONFIG_USB_GADGET_TARGET)+= tcm_usb_gadget.o - -# USB Functions -obj-$(CONFIG_USB_F_ACM)+= f_acm.o -f_ss_lb-y := f_loopback.o f_sourcesink.o -obj-$(CONFIG_USB_F_SS_LB) += f_ss_lb.o -obj-$(CONFIG_USB_U_SERIAL) += u_serial.o -- 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] usb: gadget: imx_udc: make it depend on BROKEN
On Wednesday 06 February 2013, Felipe Balbi wrote: that driver hasn't been maintained for quite some time, at least since e08300043e (ARM: imx: dynamically allocate imx_udc device). Because of that, and because driver doesn't even compile with allyesconfig and allmodconfig, we're making it depend on BROKEN. Reported-by: Arnd Bergmann a...@arndb.de Signed-off-by: Felipe Balbi ba...@ti.com Acked-by: Arnd Bergmann a...@arndb.de Thanks for taking care of 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 09/13] mfd: omap-usb-host: Add device tree support and binding information
On 02/05/2013 06:11 PM, Mark Rutland wrote: [...] + +- single_ulpi_bypass: Must be present if the controller contains a single + ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1 Again it would be nicer to have '-' rather than '_' here. It might be worth prefixing this ti,. Is prefixing with ti really required? how does it better? I thought single-ulpi-bypass sounded rather generic, but it probably is specific enough as-is. I don't know enough about USB hardware to have strong feelings either way. Yes, it is specific to the TI silicon. I'll leave it as it is then. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe 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 03/13] MIPS: BCM63XX: move code touching the USB private register
Hi,
(don't send me mails directly or I'll miss them, keep linux-usb in Cc)
On Tue, Feb 05, 2013 at 04:46:17PM +0100, Florian Fainelli wrote:
Hello Felipe,
On 01/29/2013 12:05 PM, Florian Fainelli wrote:
Hello Felipe,
On 01/29/2013 08:37 AM, Felipe Balbi wrote:
Ok, but then I won't be able to use the generic OHCI and EHCI
platform drivers
because they are not yet aware of clocks, PHY slave device etc... For
now I
would like to stick with that since this is also very BCM63xx centric.
Would that be ok with you?
sure, but we need to see a move towards making all of this generic and,
perhaps more importantly (at least to me), compilable on all arches so
we can make proper use of linux-next and Fengguang's build systems.
After checking a bit more what is being done with other PHY / host
drivers, it seems like my concerns about ehci-platform not yet being
aware of USB PHYs is not much of an issue. My only remaining concern now
is, how can I model the bcm63xx_select_pullup() function within the USB
PHY layer? Would it be acceptable to (ab)use usb_set_phy_{power,suspend}
to do that, or would you prefer a new set of operations like
usb_set_phy_pullup() being added?
I did not get an answer regarding these two questions, what do you think?
so your pullups are really controlled by the PHY ? In that case, we
would have to add some new function pointers to the phy structure to
handle that, but make sure that your only way to control pullups is
directly at the PHY layer.
--
balbi
signature.asc
Description: Digital signature
[PATCH 1/1]linux-usb: fix the product IDs to be little endian in initializers.c
From: fangxiaozhi huana...@huawei.com
1. The idProduct is little endian, so make the product ID's value to be little
endian. Make no break on big endian processors.
Signed-off-by: fangxiaozhi huana...@huawei.com
diff -uprN linux-3.8-rc6_orig/drivers/usb/storage/initializers.c
linux-3.8-rc6/drivers/usb/storage/initializers.c
--- linux-3.8-rc6_orig/drivers/usb/storage/initializers.c 2013-02-06
14:48:51.564355283 +0800
+++ linux-3.8-rc6/drivers/usb/storage/initializers.c2013-02-06
15:11:40.925434289 +0800
@@ -152,12 +152,15 @@ static int usb_stor_huawei_dongles_pid(s
* means the dongle in the single port mode,
* and a switch command is required to be sent. */
if (idesc idesc-bInterfaceNumber == 0) {
- if ((idProduct == 0x1001)
- || (idProduct == 0x1003)
- || (idProduct == 0x1004)
- || (idProduct = 0x1401 idProduct = 0x1500)
- || (idProduct = 0x1505 idProduct = 0x1600)
- || (idProduct = 0x1c02 idProduct = 0x2202)) {
+ if ((idProduct == cpu_to_le16(0x1001))
+ || (idProduct == cpu_to_le16(0x1003))
+ || (idProduct == cpu_to_le16(0x1004))
+ || (idProduct = cpu_to_le16(0x1401)
+idProduct = cpu_to_le16(0x1500))
+ || (idProduct = cpu_to_le16(0x1505)
+idProduct = cpu_to_le16(0x1600))
+ || (idProduct = cpu_to_le16(0x1c02)
+idProduct = cpu_to_le16(0x2202))) {
return 1;
}
}
@@ -169,7 +172,7 @@ int usb_stor_huawei_init(struct us_data
int result = 0;
if (usb_stor_huawei_dongles_pid(us)) {
- if (us-pusb_dev-descriptor.idProduct = 0x1446)
+ if (us-pusb_dev-descriptor.idProduct = cpu_to_le16(0x1446))
result = usb_stor_huawei_scsi_init(us);
else
result = usb_stor_huawei_feature_init(us);
--
To unsubscribe from this list: send the line unsubscribe 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 00/30] USB: omap-ehci: Move PHY management to PHY driver
On 02/05/2013 07:17 PM, Tony Lindgren wrote: * Greg KH gre...@linuxfoundation.org [130205 09:00]: On Tue, Feb 05, 2013 at 01:28:51PM +0200, Roger Quadros wrote: Hi Tony Greg, What's the best way to get these patches in? All patches have been acked by respective maintainers. If Tony can Ack the arch/arm/mach-omap2 stuff then should I send a pull request directly to Greg? or the other way round? Tony, fyi, these patches should not interfere with the dw3c/musb stuff sent by Felipe Kishon. I'm fine with Tony just taking them all if he wants to. OK. Roger, can you please do me a pull request with these against v3.8-rc6? Tony, Since this depends on [1] and [2] which are both in linux-next, should I base it on linux-next? Another option is to defer this to 3.10 merge window, along with the DT adaptation for OMAP USB Host. cheers, -roger [1] [PATCH v9 00/20] OMAP USB Host cleanup https://lkml.org/lkml/2013/1/23/155 [2] [PATCH v2 0/6] USB: Add support for multiple PHYs of same type https://lkml.org/lkml/2013/1/24/876 -- To unsubscribe from this list: send the line unsubscribe 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 specify an OMAP clock in device tree?
On Tuesday 05 February 2013 08:22 PM, Roger Quadros wrote: Doesn't look very elegant to me, but I wouldn't mind if there is no better option. Even then, we can't rely on the device name as its index can change based on where it is Well, thats what I said in the first mail, that *if* you are able to fix the device name, *then* we could use clkdev the way its used in non-DT case. But then you came back saying 'Fixing the device name doesn't really solve the problem.' :) located in the dts file. e.g. in the beginning it may be named phy.8, and if a device node is added before it, it will get changed to phy.9 If you provide a phandle to the PHY node in the board node, for which you need to add the clk alias, you can always extract the device (using of_find_device_by_node() ) and hence its name, so it doesn't matter if its phy.8 or phy.9. -- To unsubscribe from this list: send the line unsubscribe 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: [V6 PATCH 01/16] usb: phy: mv_usb2: add PHY driver for marvell usb2 controller
Hi, On Wednesday 06 February 2013 01:48 PM, Chao Xie wrote: On Wed, Feb 6, 2013 at 4:10 PM, kishon kis...@ti.com wrote: Hi, On Wednesday 06 February 2013 12:53 PM, Chao Xie wrote: The PHY is seperated from usb controller. The usb controller used in marvell pxa168/pxa910/mmp2 are same, but PHY initialization may be different. the usb controller can support udc/otg/ehci, and for each of the mode, it need PHY to initialized before use the controller. Direclty writing the phy driver will make the usb controller driver to be simple and portable. The PHY driver will be used by marvell udc/otg/ehci. Signed-off-by: Chao Xie chao@marvell.com --- drivers/usb/phy/Kconfig |7 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/mv_usb2_phy.c| 454 ++ include/linux/platform_data/mv_usb.h |9 +- include/linux/usb/mv_usb2.h | 43 5 files changed, 511 insertions(+), 3 deletions(-) create mode 100644 drivers/usb/phy/mv_usb2_phy.c create mode 100644 include/linux/usb/mv_usb2.h diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 65217a5..5479760 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -73,3 +73,10 @@ config SAMSUNG_USBPHY help Enable this to support Samsung USB phy controller for samsung SoCs. + +config MV_USB2_PHY + tristate Marvell USB 2.0 PHY Driver + depends on USB || USB_GADGET + help + Enable this to support Marvell USB 2.0 phy driver for Marvell + SoC. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index b13faa1..3835316 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -12,3 +12,4 @@ obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o obj-$(CONFIG_USB_RCAR_PHY)+= rcar-phy.o obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o +obj-$(CONFIG_MV_USB2_PHY) += mv_usb2_phy.o diff --git a/drivers/usb/phy/mv_usb2_phy.c b/drivers/usb/phy/mv_usb2_phy.c new file mode 100644 index 000..c2bccae --- /dev/null +++ b/drivers/usb/phy/mv_usb2_phy.c @@ -0,0 +1,454 @@ +/* + * Copyright (C) 2010 Google, Inc. + * + * Author: + * Chao Xie xiechao.m...@gmail.com + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * 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/resource.h +#include linux/delay.h +#include linux/slab.h +#include linux/of.h +#include linux/of_device.h +#include linux/io.h +#include linux/err.h +#include linux/clk.h +#include linux/export.h +#include linux/module.h +#include linux/platform_device.h +#include linux/platform_data/mv_usb.h +#include linux/usb/mv_usb2.h + +/* phy regs */ +#define UTMI_REVISION 0x0 +#define UTMI_CTRL 0x4 +#define UTMI_PLL 0x8 +#define UTMI_TX0xc +#define UTMI_RX0x10 +#define UTMI_IVREF 0x14 +#define UTMI_T00x18 +#define UTMI_T10x1c +#define UTMI_T20x20 +#define UTMI_T30x24 +#define UTMI_T40x28 +#define UTMI_T50x2c +#define UTMI_RESERVE 0x30 +#define UTMI_USB_INT 0x34 +#define UTMI_DBG_CTL 0x38 +#define UTMI_OTG_ADDON 0x3c + +/* For UTMICTRL Register */ +#define UTMI_CTRL_USB_CLK_EN(1 31) +/* pxa168 */ +#define UTMI_CTRL_SUSPEND_SET1 (1 30) +#define UTMI_CTRL_SUSPEND_SET2 (1 29) +#define UTMI_CTRL_RXBUF_PDWN(1 24) +#define UTMI_CTRL_TXBUF_PDWN(1 11) + +#define UTMI_CTRL_INPKT_DELAY_SHIFT 30 +#define UTMI_CTRL_INPKT_DELAY_SOF_SHIFT28 +#define UTMI_CTRL_PU_REF_SHIFT 20 +#define UTMI_CTRL_ARC_PULLDN_SHIFT 12 +#define UTMI_CTRL_PLL_PWR_UP_SHIFT 1 +#define UTMI_CTRL_PWR_UP_SHIFT 0 + +/* For UTMI_PLL Register */ +#define UTMI_PLL_PLLCALI12_SHIFT 29 +#define UTMI_PLL_PLLCALI12_MASK(0x3 29) + +#define UTMI_PLL_PLLVDD18_SHIFT27 +#define UTMI_PLL_PLLVDD18_MASK (0x3 27) + +#define UTMI_PLL_PLLVDD12_SHIFT25 +#define UTMI_PLL_PLLVDD12_MASK (0x3 25) + +#define UTMI_PLL_CLK_BLK_EN_SHIFT 24 +#define CLK_BLK_EN (0x1 24) +#define PLL_READY
Re: how to specify an OMAP clock in device tree?
On 02/06/2013 12:21 PM, Rajendra Nayak wrote: On Tuesday 05 February 2013 08:22 PM, Roger Quadros wrote: Doesn't look very elegant to me, but I wouldn't mind if there is no better option. Even then, we can't rely on the device name as its index can change based on where it is Well, thats what I said in the first mail, that *if* you are able to fix the device name, *then* we could use clkdev the way its used in non-DT case. But then you came back saying 'Fixing the device name doesn't really solve the problem.' :) It does, yes, but depending on fixed device names is not so great for DT, is it? Doesn't solve the problem in the right sense :) located in the dts file. e.g. in the beginning it may be named phy.8, and if a device node is added before it, it will get changed to phy.9 If you provide a phandle to the PHY node in the board node, for which you need to add the clk alias, you can always extract the device (using of_find_device_by_node() ) and hence its name, so it doesn't matter if its phy.8 or phy.9. Right, I'll come up with something on these lines. Thanks for the suggestions :). cheers, -roger -- To unsubscribe from this list: send the line unsubscribe 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 1/2] usb: gadget: let gadgets control pullup on their own
This is useful on gadgets that depend on userland
daemons to function properly. We can delay connection
to the host until userland is ready.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/composite.c | 3 ++-
drivers/usb/gadget/udc-core.c | 26 --
include/linux/usb/composite.h | 4
include/linux/usb/gadget.h | 3 +++
4 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 7c821de..790ccf2 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1784,8 +1784,9 @@ int usb_composite_probe(struct usb_composite_driver
*driver)
driver-name = composite;
driver-gadget_driver = composite_driver_template;
- gadget_driver = driver-gadget_driver;
+ gadget_driver = driver-gadget_driver;
+ gadget_driver-controls_pullups = driver-controls_pullups;
gadget_driver-function = (char *) driver-name;
gadget_driver-driver.name = driver-name;
gadget_driver-max_speed = driver-max_speed;
diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
index 8a1eeb2..c0f4fca 100644
--- a/drivers/usb/gadget/udc-core.c
+++ b/drivers/usb/gadget/udc-core.c
@@ -235,7 +235,18 @@ static void usb_gadget_remove_driver(struct usb_udc *udc)
kobject_uevent(udc-dev.kobj, KOBJ_CHANGE);
- usb_gadget_disconnect(udc-gadget);
+ /*
+* NOTICE: if gadget driver wants to control
+* pullup, it needs to make sure that when
+* user tries to rmmod the gadget driver, it
+* will disconnect the pullups before returning
+* from its -unbind() method.
+*
+* We are truly trusting the gadget driver here.
+*/
+ if (!udc-driver-controls_pullups)
+ usb_gadget_disconnect(udc-gadget);
+
udc-driver-disconnect(udc-gadget);
udc-driver-unbind(udc-gadget);
usb_gadget_udc_stop(udc-gadget, udc-driver);
@@ -300,7 +311,18 @@ static int udc_bind_to_driver(struct usb_udc *udc, struct
usb_gadget_driver *dri
driver-unbind(udc-gadget);
goto err1;
}
- usb_gadget_connect(udc-gadget);
+
+ /*
+* NOTICE: if gadget driver wants to control
+* pullups, it needs to make sure its calls
+* to usb_function_activate() and
+* usb_function_deactivate() are balanced,
+* otherwise gadget_driver will never enumerate.
+*
+* We are truly trusting the gadget driver here.
+*/
+ if (!driver-controls_pullups)
+ usb_gadget_connect(udc-gadget);
kobject_uevent(udc-dev.kobj, KOBJ_CHANGE);
return 0;
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 3c671c1..7ae797c 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -157,6 +157,7 @@ struct usb_function {
int (*get_status)(struct usb_function *);
int (*func_suspend)(struct usb_function *,
u8 suspend_opt);
+
/* private: */
/* internals */
struct list_headlist;
@@ -279,6 +280,8 @@ enum {
* @max_speed: Highest speed the driver supports.
* @needs_serial: set to 1 if the gadget needs userspace to provide
* a serial number. If one is not provided, warning will be printed.
+ * @controls_pullups: this driver will control pullup and udc-core shouldn't
+ * enable it by default
* @bind: (REQUIRED) Used to allocate resources that are shared across the
* whole device, such as string IDs, and add its configurations using
* @usb_add_config(). This may fail by returning a negative errno
@@ -308,6 +311,7 @@ struct usb_composite_driver {
struct usb_gadget_strings **strings;
enum usb_device_speed max_speed;
unsignedneeds_serial:1;
+ unsignedcontrols_pullups:1;
int (*bind)(struct usb_composite_dev *cdev);
int (*unbind)(struct usb_composite_dev *);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 32b734d..87971fa 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -774,6 +774,7 @@ static inline int usb_gadget_disconnect(struct usb_gadget
*gadget)
* @suspend: Invoked on USB suspend. May be called in_interrupt.
* @resume: Invoked on USB resume. May be called in_interrupt.
* @driver: Driver model state for this driver.
+ * @controls_pullups: tells udc-core to not enable pullups by default
*
* Devices are disabled till a gadget driver successfully bind()s, which
* means the driver will handle setup() requests needed to enumerate (and
@@ -833,6 +834,8 @@ struct usb_gadget_driver {
/* FIXME support safe rmmod */
Re: [PATCH 3/5] ARM: OMAP2: MUSB: Specify omap4 has mailbox
On Wed, Feb 06, 2013 at 01:22:31PM +0200, Felipe Balbi wrote: there's a little more to it. When running allmodconfig, CONFIG_ARCH_MULTIPLATFORM is set but none of the other ARCHes (ARCH_OMAP, ARCH_AT91, ARCH_VERSATILE, etc) are set, so it turned out that the driver wasn't even included on my build test. Russell, is this expected (the MULTIPLATFORM thing) ? Just so I fix my build test scripts to use another defconfig instead of allmod and allyes. Don't know. Most of that logic is sitting in arm-soc. Nothing obvious stands out as to why that's happening. The first thing to check is which of the CONFIG_ARCH_MULTI_* options are set. It should be ARCH_MULTI_V7 and ARCH_MULTI_V6_V7. This should then allow ARCH_OMAP2PLUS to be set. However, I've said this before, and I'll say it again: if you want to use the all* targets, it's better to seed the configuration so that you end up with the platform you're targetting selected. I've always done this with the build system, and even before it when I've wanted to use the all* targets, because generally I want that behaviour, but I want it for a particular platform. -- To unsubscribe from this list: send the line unsubscribe 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: MUSB regression in linux next at least for pandboard
Hi Tony, On Fri, Oct 5, 2012 at 9:57 PM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [121004 18:41]: Also on the EHCI port, I've seen issues where unplugging the cable hangs kernel with an infinite loop. But that happens only occasionally, sorry does not seem to happen right now so no output to paste here. Or maybe this issue has already been fixed? Looks like the system eventually recovers from the EHCI issue after about fivew minutes or so of spamming the logs. It seems the ehci-omap errors are: [62934.201538] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 31 [62934.201660] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes [62934.201873] ehci-omap ehci-omap.0: reused qh ea5632c0 schedule More data below. Is this issue fixed ? Actually we too are getting very similar issue with samsung exynos5250 hardware. With latest 'usb-next' kernel and supporting arch patches, when i use following test scenerio: Connect a USB 2.0 external hub to USB 2.0 port, and connect mice or keyboard enumeration and functionality is fine but once disconnecting the HID we get to see the error log: hid-generic 0003:04B3:3025.0002: can't reset device, s5p-ehci-1.3/input0, status -71 When i tried to enable CONFIG_USB_DEBUG, get the following log: hub 1-1:1.0: state 7 ports 7 chg evt 0008 hub 1-1:1.0: port 3, status 0301, change 0001, 1.5 Mb/s hub 1-1:1.0: debounce: port 3: total 100ms stable 100ms status 0x301 usb 1-1.3: new low-speed USB device number 5 using s5p-ehci usb 1-1.3: skipped 1 descriptor after interface usb 1-1.3: default language 0x0409 usb 1-1.3: udev 5, busnum 1, minor = 4 usb 1-1.3: New USB device found, idVendor=04b3, idProduct=3025 usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.3: Product: USB NetVista Full Width Keyboard usb 1-1.3: Manufacturer: CHICONY usb 1-1.3: usb_probe_device usb 1-1.3: configuration #1 chosen from 1 choice usb 1-1.3: adding 1-1.3:1.0 (config #1, interface 0) usbhid 1-1.3:1.0: usb_probe_interface usbhid 1-1.3:1.0: usb_probe_interface - got id input: CHICONY USB NetVista Full Width Keyboard as /devices/s5p-ehci/usb1/1-1/1-1.3/1-1.3:1.0/input/input1 usb 1-1.3: link qh8-0e01/c193f140 start 2 [1/2 us] hid-generic 0003:04B3:3025.0002: input: USB HID v1.10 Keyboard [CHICONY USB NetVista Full Width Keyboard] on usb-s5p-ehci-1.3/input0 hub 1-1:1.0: state 7 ports 7 chg evt 0008 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 1 usb 1-1.3: unlink qh8-0e01/c193f140 start 2 [1/2 us] s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 1 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 2 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 3 hub 1-1:1.0: state 7 ports 7 chg evt 0008 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 4 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 5 hub 1-1:1.0: port 3, status 0100, change 0001, 12 Mb/s s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 6 usb 1-1.3: USB disconnect, device number 5 usb 1-1.3: unregistering device usb 1-1.3: unregistering interface 1-1.3:1.0 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 7 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 8 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 9 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 10 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 11 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 12 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 13 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 14 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 15 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 16 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 17 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 18 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 19 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 20 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 21 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 22 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 23 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 24 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 25 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 26 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 27 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 28 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 29 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 30 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 31 s5p-ehci s5p-ehci: devpath 1.3 ep0out 3strikes usb 1-1: clear tt buffer port 3, a5 ep0 t00080248 hid-generic 0003:04B3:3025.0002: can't reset device, s5p-ehci-1.3/input0, status -71 Similar log as you get on ehci-omap ;-) Sorry i might have missed some information to put here. Your help will be very much useful. Thanks in advance :-) ... [62927.200012] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 19 [62927.215606] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 25 [62927.220092] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 22 [62927.225738] ehci-omap ehci-omap.0:
Re: [PATCH 2/5] ARM: OMAP: devices: create device for usb part of control module
Hello.
On 06-02-2013 9:58, 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
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/devices.c | 45 +
1 file changed, 45 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 626f3ea..6cda103 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -20,6 +20,7 @@
[...]
@@ -254,6 +255,49 @@ static inline void omap_init_camera(void)
[...]
+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,
Either align = or not, not both at once.
+};
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] ARM: OMAP4: remove control module address space from PHY and OTG
Now that we have a separate driver for the control module,
stop populating the control module device data in other modules
(PHY and OTG) device info.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 793f54a..624a7e8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2702,13 +2702,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,
- },
{ }
};
@@ -6156,12 +6149,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
- },
{ }
};
--
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
[PATCH v2 2/5] ARM: OMAP: devices: create device for usb part of control module
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
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/devices.c | 45 +
1 file changed, 45 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 626f3ea..6cda103 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,49 @@ static inline void omap_init_camera(void)
#endif
}
+#if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
+static struct omap_control_usb_platform_data omap4_control_usb_pdata = {
+ .type = 1,
+};
+
+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)
+{
+ if (!cpu_is_omap44xx())
+ return;
+
+ if (platform_device_register(omap4_control_usb))
+ pr_err(Error registering omap_control_usb device\n);
+}
+
+#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 +765,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.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
[PATCH v2 4/5] ARM: OMAP: USB: Add phy binding information
This is w.r.t the changes in PHY library to support adding and getting multiple PHYs of the same type. In the new design, the binding information between the PHY and the USB controller should be specified in the platform specific initialization code. So it's been done here for OMAP platforms. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/board-2430sdp.c |2 ++ arch/arm/mach-omap2/board-3430sdp.c |2 ++ arch/arm/mach-omap2/board-4430sdp.c |2 ++ arch/arm/mach-omap2/board-cm-t35.c |2 ++ arch/arm/mach-omap2/board-devkit8000.c |2 ++ arch/arm/mach-omap2/board-igep0020.c |2 ++ arch/arm/mach-omap2/board-ldp.c |2 ++ arch/arm/mach-omap2/board-omap3beagle.c |2 ++ arch/arm/mach-omap2/board-omap3evm.c |2 ++ arch/arm/mach-omap2/board-omap3logic.c |2 ++ arch/arm/mach-omap2/board-omap3pandora.c |2 ++ arch/arm/mach-omap2/board-omap3stalker.c |2 ++ arch/arm/mach-omap2/board-omap3touchbook.c |2 ++ arch/arm/mach-omap2/board-omap4panda.c |2 ++ arch/arm/mach-omap2/board-overo.c|2 ++ arch/arm/mach-omap2/board-rm680.c|2 ++ arch/arm/mach-omap2/board-zoom-peripherals.c |2 ++ 17 files changed, 34 insertions(+) diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index 4815ea6..1337f2c 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -27,6 +27,7 @@ #include linux/clk.h #include linux/io.h #include linux/gpio.h +#include linux/usb/phy.h #include asm/mach-types.h #include asm/mach/arch.h @@ -263,6 +264,7 @@ static void __init omap_2430sdp_init(void) omap_hsmmc_init(mmc); omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA | OMAP_PULL_UP); + usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); board_smc91x_init(); diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index bb73afc..8a2e242 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -25,6 +25,7 @@ #include linux/gpio.h #include linux/mmc/host.h #include linux/platform_data/spi-omap2-mcspi.h +#include linux/usb/phy.h #include asm/mach-types.h #include asm/mach/arch.h @@ -579,6 +580,7 @@ static void __init omap_3430sdp_init(void) omap_ads7846_init(1, gpio_pendown, 310, NULL); omap_serial_init(); omap_sdrc_init(hyb18m512160af6_sdrc_params, NULL); + usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); board_smc91x_init(); board_flash_init(sdp_flash_partitions, chip_sel_3430, 0); diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 1cc6696..8e8efcc 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -28,6 +28,7 @@ #include linux/leds_pwm.h #include linux/platform_data/omap4-keypad.h #include linux/usb/musb.h +#include linux/usb/phy.h #include asm/hardware/gic.h #include asm/mach-types.h @@ -696,6 +697,7 @@ static void __init omap_4430sdp_init(void) omap4_sdp4430_wifi_init(); omap4_twl6030_hsmmc_init(mmc); + usb_bind_phy(musb-hdrc.0.auto, 0, omap-usb2.1.auto); usb_musb_init(musb_board_data); status = omap_ethernet_init(); diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index b3102c2..f1172f2 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -30,6 +30,7 @@ #include linux/regulator/fixed.h #include linux/regulator/machine.h #include linux/mmc/host.h +#include linux/usb/phy.h #include linux/spi/spi.h #include linux/spi/tdo24m.h @@ -724,6 +725,7 @@ static void __init cm_t3x_common_init(void) cm_t35_init_display(); omap_twl4030_audio_init(cm-t3x); + usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); cm_t35_init_usbh(); cm_t35_init_camera(); diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c index 12865af..77cade52 100644 --- a/arch/arm/mach-omap2/board-devkit8000.c +++ b/arch/arm/mach-omap2/board-devkit8000.c @@ -29,6 +29,7 @@ #include linux/mtd/partitions.h #include linux/mtd/nand.h #include linux/mmc/host.h +#include linux/usb/phy.h #include linux/regulator/machine.h #include linux/i2c/twl.h @@ -622,6 +623,7 @@ static void __init devkit8000_init(void) omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL); + usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); usbhs_init(usbhs_bdata); board_nand_init(devkit8000_nand_partitions, diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c index 0f24cb8..15e5881
[PATCH v2 5/5] usb: omap_control_usb: fix compile warning
From: Felipe Balbi ba...@ti.com
When CONFIG_OMAP_CONTROL_USB isn't enabled,
there's a compile warning stating that a
particular function isn't a prototype.
Fix it.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
include/linux/usb/omap_control_usb.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/usb/omap_control_usb.h
b/include/linux/usb/omap_control_usb.h
index f306db7..27b5b8c 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -70,7 +70,7 @@ extern void omap_control_usb3_phy_power(struct device *dev,
bool on);
extern void omap_control_usb_set_mode(struct device *dev,
enum omap_control_usb_mode mode);
#else
-static inline struct device *omap_get_control_dev()
+static inline struct device *omap_get_control_dev(void)
{
return ERR_PTR(-ENODEV);
}
--
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
[PATCH v2 0/5] ARM: OMAP: arm part of usb patches
Hi Greg, Here is the patch series that includes the arch/arm part to get MUSB working in OMAP platforms. As discussed in the other mail thread with Tony, this patch series should go into usb-next. This patch series also contains a patch by Felipe to fix compilation warning in usb-next when CONFIG_OMAP_CONTROL_USB is not set. Changes from v1: Fixed alignment in omap4_control_usb as suggested by Sergei. Boot tested panda board. Felipe Balbi (1): usb: omap_control_usb: fix compile warning Kishon Vijay Abraham I (4): ARM: OMAP4: remove control module address space from PHY and OTG ARM: OMAP: devices: create device for usb part of control module ARM: OMAP2: MUSB: Specify omap4 has mailbox ARM: OMAP: USB: Add phy binding information arch/arm/mach-omap2/board-2430sdp.c |2 ++ arch/arm/mach-omap2/board-3430sdp.c |2 ++ arch/arm/mach-omap2/board-4430sdp.c |2 ++ arch/arm/mach-omap2/board-cm-t35.c |2 ++ arch/arm/mach-omap2/board-devkit8000.c |2 ++ arch/arm/mach-omap2/board-igep0020.c |2 ++ arch/arm/mach-omap2/board-ldp.c |2 ++ arch/arm/mach-omap2/board-omap3beagle.c |2 ++ arch/arm/mach-omap2/board-omap3evm.c |2 ++ arch/arm/mach-omap2/board-omap3logic.c |2 ++ arch/arm/mach-omap2/board-omap3pandora.c |2 ++ arch/arm/mach-omap2/board-omap3stalker.c |2 ++ arch/arm/mach-omap2/board-omap3touchbook.c |2 ++ arch/arm/mach-omap2/board-omap4panda.c |2 ++ arch/arm/mach-omap2/board-overo.c|2 ++ arch/arm/mach-omap2/board-rm680.c|2 ++ arch/arm/mach-omap2/board-zoom-peripherals.c |2 ++ arch/arm/mach-omap2/devices.c| 45 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 arch/arm/mach-omap2/usb-musb.c |3 ++ include/linux/usb/musb.h |2 ++ include/linux/usb/omap_control_usb.h |2 +- 22 files changed, 85 insertions(+), 14 deletions(-) -- 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: MUSB regression in linux next at least for pandboard
Hi, On Wed, Feb 06, 2013 at 05:27:52PM +0530, Vivek Gautam wrote: Hi Tony, On Fri, Oct 5, 2012 at 9:57 PM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [121004 18:41]: Also on the EHCI port, I've seen issues where unplugging the cable hangs kernel with an infinite loop. But that happens only occasionally, sorry does not seem to happen right now so no output to paste here. Or maybe this issue has already been fixed? Looks like the system eventually recovers from the EHCI issue after about fivew minutes or so of spamming the logs. It seems the ehci-omap errors are: [62934.201538] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 31 [62934.201660] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes [62934.201873] ehci-omap ehci-omap.0: reused qh ea5632c0 schedule More data below. Is this issue fixed ? Actually we too are getting very similar issue with samsung exynos5250 hardware. With latest 'usb-next' kernel and supporting arch patches, when i use following test scenerio: Connect a USB 2.0 external hub to USB 2.0 port, and connect mice or keyboard enumeration and functionality is fine but once disconnecting the HID we get to see the error log: hid-generic 0003:04B3:3025.0002: can't reset device, s5p-ehci-1.3/input0, status -71 When i tried to enable CONFIG_USB_DEBUG, get the following log: looks like it's not OMAP-specific. Alan any tips ? (keeping logs below) hub 1-1:1.0: state 7 ports 7 chg evt 0008 hub 1-1:1.0: port 3, status 0301, change 0001, 1.5 Mb/s hub 1-1:1.0: debounce: port 3: total 100ms stable 100ms status 0x301 usb 1-1.3: new low-speed USB device number 5 using s5p-ehci usb 1-1.3: skipped 1 descriptor after interface usb 1-1.3: default language 0x0409 usb 1-1.3: udev 5, busnum 1, minor = 4 usb 1-1.3: New USB device found, idVendor=04b3, idProduct=3025 usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.3: Product: USB NetVista Full Width Keyboard usb 1-1.3: Manufacturer: CHICONY usb 1-1.3: usb_probe_device usb 1-1.3: configuration #1 chosen from 1 choice usb 1-1.3: adding 1-1.3:1.0 (config #1, interface 0) usbhid 1-1.3:1.0: usb_probe_interface usbhid 1-1.3:1.0: usb_probe_interface - got id input: CHICONY USB NetVista Full Width Keyboard as /devices/s5p-ehci/usb1/1-1/1-1.3/1-1.3:1.0/input/input1 usb 1-1.3: link qh8-0e01/c193f140 start 2 [1/2 us] hid-generic 0003:04B3:3025.0002: input: USB HID v1.10 Keyboard [CHICONY USB NetVista Full Width Keyboard] on usb-s5p-ehci-1.3/input0 hub 1-1:1.0: state 7 ports 7 chg evt 0008 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 1 usb 1-1.3: unlink qh8-0e01/c193f140 start 2 [1/2 us] s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 1 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 2 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 3 hub 1-1:1.0: state 7 ports 7 chg evt 0008 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 4 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 5 hub 1-1:1.0: port 3, status 0100, change 0001, 12 Mb/s s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 6 usb 1-1.3: USB disconnect, device number 5 usb 1-1.3: unregistering device usb 1-1.3: unregistering interface 1-1.3:1.0 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 7 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 8 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 9 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 10 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 11 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 12 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 13 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 14 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 15 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 16 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 17 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 18 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 19 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 20 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 21 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 22 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 23 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 24 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 25 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 26 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 27 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 28 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 29 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 30 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 31 s5p-ehci s5p-ehci: devpath 1.3 ep0out 3strikes usb 1-1: clear tt buffer port 3, a5 ep0 t00080248 hid-generic 0003:04B3:3025.0002: can't reset device, s5p-ehci-1.3/input0, status -71 Similar log as you get on ehci-omap ;-) Sorry i might have missed some information to put here. Your help will be very much useful. Thanks in advance :-) ...
Re: [V6 PATCH 01/16] usb: phy: mv_usb2: add PHY driver for marvell usb2 controller
Hi,
I have a few comments on the devicetree binding and the way it's parsed.
I note many are similar to those I commented on for the mv_udc and ehci-mv
devicetree code.
On Wed, Feb 06, 2013 at 07:23:36AM +, Chao Xie wrote:
The PHY is seperated from usb controller.
The usb controller used in marvell pxa168/pxa910/mmp2 are same,
but PHY initialization may be different.
the usb controller can support udc/otg/ehci, and for each of
the mode, it need PHY to initialized before use the controller.
Direclty writing the phy driver will make the usb controller
driver to be simple and portable.
The PHY driver will be used by marvell udc/otg/ehci.
Signed-off-by: Chao Xie chao@marvell.com
---
drivers/usb/phy/Kconfig |7 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/mv_usb2_phy.c| 454
++
include/linux/platform_data/mv_usb.h |9 +-
include/linux/usb/mv_usb2.h | 43
5 files changed, 511 insertions(+), 3 deletions(-)
create mode 100644 drivers/usb/phy/mv_usb2_phy.c
create mode 100644 include/linux/usb/mv_usb2.h
[...]
+static struct of_device_id usb_phy_dt_ids[] = {
+ { .compatible = mrvl,pxa168-usb-phy, .data = (void *)PXA168_USB},
+ { .compatible = mrvl,pxa910-usb-phy, .data = (void *)PXA910_USB},
+ { .compatible = mrvl,mmp2-usb-phy,.data = (void *)MMP2_USB},
+ {}
+};
+MODULE_DEVICE_TABLE(of, usb_phy_dt_ids);
The binding (including these compatible string) needs to be documented.
+
+static int usb_phy_parse_dt(struct platform_device *pdev,
+ struct mv_usb2_phy *mv_phy)
+{
+ struct device_node *np = pdev-dev.of_node;
+ const struct of_device_id *of_id =
+ of_match_device(usb_phy_dt_ids, pdev-dev);
+ unsigned int clks_num;
+ int i, ret;
+ const char *clk_name;
+
+ if (!np)
+ return 1;
An actual error code please.
-ENODEV? -EINVAL?
+
+ clks_num = of_property_count_strings(np, clocks);
+ if (clks_num 0) {
+ dev_err(pdev-dev, failed to get clock number\n);
+ return clks_num;
+ }
The common clock bindings use clocks as a list of phandle and clock-specifier
pairs. It seems bad to reuse that name in a different sense for this binding.
I'd recommend you use the common clock binding. There doesn't seem to be an
of_clk_count, but it should be a relatively simple addition, and it'd make this
code clearer and more consistent with other drivers.
See Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+ mv_phy-clks = devm_kzalloc(pdev-dev,
+ sizeof(struct clk *) * clks_num, GFP_KERNEL);
+ if (mv_phy-clks == NULL) {
+ dev_err(pdev-dev,
+ failed to allocate mempory for clocks);
s/mempory/memory/
+ return -ENOMEM;
+ }
+
+ for (i = 0; i clks_num; i++) {
+ ret = of_property_read_string_index(np, clocks, i,
+ clk_name);
+ if (ret) {
+ dev_err(pdev-dev, failed to read clocks\n);
+ return ret;
+ }
+ mv_phy-clks[i] = devm_clk_get(pdev-dev, clk_name);
+ if (IS_ERR(mv_phy-clks[i])) {
+ dev_err(pdev-dev, failed to get clock %s\n,
+ clk_name);
+ return PTR_ERR(mv_phy-clks[i]);
+ }
+ }
+
+ mv_phy-clks_num = clks_num;
+ mv_phy-type = (enum mv_usb2_phy_type)(of_id-data);
+
+ return 0;
+}
There's probably a need for something like devm_of_clk_get to make it easier to
write of-backed drivers.
+
+static int usb_phy_probe(struct platform_device *pdev)
+{
+ struct mv_usb2_phy *mv_phy;
+ struct resource *r;
+ int ret, i;
+
+ mv_phy = devm_kzalloc(pdev-dev, sizeof(*mv_phy), GFP_KERNEL);
+ if (mv_phy == NULL) {
+ dev_err(pdev-dev, failed to allocate memory\n);
+ return -ENOMEM;
+ }
+ mutex_init(mv_phy-phy_lock);
+
+ ret = usb_phy_parse_dt(pdev, mv_phy);
+ /* no CONFIG_OF */
+ if (ret 0) {
Reorganise this so you test for pdev-dev.of_node, and based of that you either
call usb_phy_parse_dt or do this stuff in the block below. That way you don't
need
the positive return code from usb_phy_parse_dt.
+ struct mv_usb_phy_platform_data *pdata
+ = pdev-dev.platform_data;
+ const struct platform_device_id *id
+ = platform_get_device_id(pdev);
+
+ if (pdata == NULL || id == NULL) {
+ dev_err(pdev-dev,
+ missing platform_data or id_entry\n);
+ return -ENODEV;
+
[PATCH 5/8] ARM: dts: omap5: Add ocp2scp data
Add ocp2scp data node in omap5 device tree file. The information for
the node added here can be found @
Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index c937500..230b779 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -504,5 +504,13 @@
reg-names = control_dev_conf, phy_power_usb;
ti,type = 2;
};
+
+ ocp2scp {
+ compatible = ti,omap-ocp2scp;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = ocp2scp1;
+ };
};
};
--
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
[PATCH 8/8] ARM: dts: omap5: add dwc3 core dt data
Add dwc3 core dt data as a subnode to dwc3 omap glue data in omap5 dt
data file. The information for the entered data node is available @
Documentation/devicetree/bindings/usb/dwc3.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index c4eb2ec..24dd69f 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -514,6 +514,13 @@
#size-cells = 1;
utmi-mode = 2;
ranges;
+ dwc3@4a03 {
+ compatible = synopsys,dwc3;
+ reg = 0x4a03 0x1000;
+ interrupts = 0 92 4;
+ usb-phy = usb2_phy, usb3_phy;
+ tx-fifo-resize;
+ };
};
ocp2scp {
--
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
[PATCH 7/8] ARM: dts: omap5: add dwc3 omap dt data
Add dwc3 omap glue data to the omap5 dt data file. The information about
the dt node added here is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index bd73257..c4eb2ec 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -505,6 +505,17 @@
ti,type = 2;
};
+ omap_dwc3@4a02 {
+ compatible = ti,dwc3;
+ ti,hwmods = usb_otg_ss;
+ reg = 0x4a02 0x1000;
+ interrupts = 0 93 4;
+ #address-cells = 1;
+ #size-cells = 1;
+ utmi-mode = 2;
+ ranges;
+ };
+
ocp2scp {
compatible = ti,omap-ocp2scp;
#address-cells = 1;
--
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
[PATCH 1/8] ARM: dts: omap: Add omap control usb data
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. The information about this data node is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
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 739bb79..ffc7352 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,13 @@
ti,hwmods = timer11;
ti,timer-pwm;
};
+
+ omap_control_usb: omap-control-usb@4a002300 {
+ compatible = ti,omap-control-usb;
+ reg = 0x4a002300 0x4,
+ 0x4a00233c 0x4;
+ reg-names = control_dev_conf, otghs_control;
+ ti,type = 1;
+ };
};
};
--
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
[PATCH 2/8] ARM: dts: omap: Add omap-usb2 dt data
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. The information about this data node is availabe @
Documentation/devicetree/bindings/usb/usb-phy.txt
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index ffc7352..c829d7e 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -438,6 +438,11 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
+ usb2_phy: usb2phy@4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58;
+ ctrl-module = omap_control_usb;
+ };
};
timer1: timer@4a318000 {
--
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
[PATCH 6/8] ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data
Add omap-usb3 and omap-usb2 data node in omap5 device tree file.
The information for the node added here is available @
Documentation/devicetree/bindings/usb/usb-phy.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 230b779..bd73257 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -511,6 +511,20 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp1;
+ usb2_phy: usb2phy@4a084000 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a084000 0x7c;
+ ctrl-module = omap_control_usb;
+ };
+
+ usb3_phy: usb3phy@4a084400 {
+ compatible = ti,omap-usb3;
+ reg = 0x4a084400 0x80,
+ 0x4a084800 0x64,
+ 0x4a084c00 0x40;
+ reg-names = phy_rx, phy_tx, pll_ctrl;
+ ctrl-module = omap_control_usb;
+ };
};
};
};
--
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
[PATCH 3/8] ARM: dts: omap: Add usb_otg and glue data
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.
The information about usb otg node is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt |1 +
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 | 12
arch/arm/boot/dts/omap4-panda.dts |6 ++
arch/arm/boot/dts/omap4-sdp.dts|6 ++
arch/arm/boot/dts/omap4.dtsi | 13 +
arch/arm/boot/dts/twl4030.dtsi |2 +-
9 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..4688265 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -15,6 +15,7 @@ OMAP MUSB GLUE
represents PERIPHERAL.
- power : Should be 50. This signifies the controller can supply upto
100mA when operating in host mode.
+ - usb-phy : the phandle for the PHY device
SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
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..b6472f7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,17 @@
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;
+ usb-phy = usb2_phy;
+ 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 c829d7e..5171739 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -542,5 +542,18 @@
reg-names = control_dev_conf, otghs_control;
ti,type = 1;
};
+
+ 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;
+ usb-phy = usb2_phy;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits
[PATCH 4/8] ARM: dts: omap5: Add omap control usb data
Add omap control usb data in omap5 device tree file. This will have the
register address of registers to power on the USB2 PHY and USB3 PHY. The
information for the node added here is available in
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 790bb2a..c937500 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -496,5 +496,13 @@
hw-caps-ll-interface;
hw-caps-temp-alert;
};
+
+ omap_control_usb: omap-control-usb@4a002300 {
+ compatible = ti,omap-control-usb;
+ reg = 0x4a002300 0x4,
+ 0x4a002370 0x4;
+ reg-names = control_dev_conf, phy_power_usb;
+ ti,type = 2;
+ };
};
};
--
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
[PATCH 0/8] ARM: dts: omap: Add dts data for USB
Hi Benoit, Here are the dt data patches to get usb device functional in OMAP platforms. This series applies cleanly in both for_3.9/dts and 3.8-rc6. All the patches deal with modifying arch/arm/boot except one which modifies Documentation/../usb/omap-usb.txt Kishon Vijay Abraham I (8): ARM: dts: omap: Add omap control usb data ARM: dts: omap: Add omap-usb2 dt data ARM: dts: omap: Add usb_otg and glue data ARM: dts: omap5: Add omap control usb data ARM: dts: omap5: Add ocp2scp data ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data ARM: dts: omap5: add dwc3 omap dt data ARM: dts: omap5: add dwc3 core dt data Documentation/devicetree/bindings/usb/omap-usb.txt |1 + 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 | 12 + arch/arm/boot/dts/omap4-panda.dts |6 +++ arch/arm/boot/dts/omap4-sdp.dts|6 +++ arch/arm/boot/dts/omap4.dtsi | 26 +++ arch/arm/boot/dts/omap5.dtsi | 48 arch/arm/boot/dts/twl4030.dtsi |2 +- 10 files changed, 118 insertions(+), 1 deletion(-) -- 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: MUSB regression in linux next at least for pandboard
On 02/06/2013 03:51 PM, Felipe Balbi wrote: Hi, On Wed, Feb 06, 2013 at 05:27:52PM +0530, Vivek Gautam wrote: Hi Tony, On Fri, Oct 5, 2012 at 9:57 PM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [121004 18:41]: Also on the EHCI port, I've seen issues where unplugging the cable hangs kernel with an infinite loop. But that happens only occasionally, sorry does not seem to happen right now so no output to paste here. Or maybe this issue has already been fixed? Looks like the system eventually recovers from the EHCI issue after about fivew minutes or so of spamming the logs. It seems the ehci-omap errors are: [62934.201538] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 31 [62934.201660] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes [62934.201873] ehci-omap ehci-omap.0: reused qh ea5632c0 schedule More data below. Is this issue fixed ? Actually we too are getting very similar issue with samsung exynos5250 hardware. With latest 'usb-next' kernel and supporting arch patches, when i use following test scenerio: Connect a USB 2.0 external hub to USB 2.0 port, and connect mice or keyboard enumeration and functionality is fine but once disconnecting the HID we get to see the error log: hid-generic 0003:04B3:3025.0002: can't reset device, s5p-ehci-1.3/input0, status -71 When i tried to enable CONFIG_USB_DEBUG, get the following log: looks like it's not OMAP-specific. Alan any tips ? I can't reproduce the problem on Panda, but I can on Beagle with a slightly different behaviour. 1) connecting/disconnecting device directly to the beagleboard's USB port works fine. 2) If I connect a USB Hub to the port and connect a device to it after the hub has autosuspended, the device is never detected. doing lsusb after that triggers the detection and produces a lot of transaction errors. Beagle log is below, before and after 'lsusb' I suppose this doesn't affect Panda because it has a hub connected immediately below the root hub that never suspends (as ethernet is hardwired to it). So there must be some problem in the hub drivers. cheers, -roger root@beagleboard:~# [ 62.666595] usb usb1: usb wakeup-resume [ 62.670684] usb usb1: usb auto-resume [ 62.674591] ehci-omap ehci-omap.0: resume root hub [ 62.679687] hub 1-0:1.0: hub_resume [ 62.683471] ehci-omap ehci-omap.0: GetStatus port:2 status 001803 0 ACK POWER sig=j CSC CONNECT [ 62.692779] hub 1-0:1.0: port 2: status 0501 change 0001 [ 62.772460] hub 1-0:1.0: state 7 ports 3 chg 0004 evt [ 62.778533] hub 1-0:1.0: port 2, status 0501, change , 480 Mb/s [ 62.849182] ehci-omap ehci-omap.0: port 2 reset complete, port enabled [ 62.856109] ehci-omap ehci-omap.0: GetStatus port:2 status 001005 0 ACK POWER sig=se0 PE CONNECT [ 62.929931] usb 1-2: new high-speed USB device number 4 using ehci-omap [ 62.998352] ehci-omap ehci-omap.0: port 2 reset complete, port enabled [ 63.005279] ehci-omap ehci-omap.0: GetStatus port:2 status 001005 0 ACK POWER sig=se0 PE CONNECT [ 63.107635] usb 1-2: udev 4, busnum 1, minor = 3 [ 63.112548] usb 1-2: New USB device found, idVendor=0409, idProduct=005a [ 63.119720] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 63.128936] usb 1-2: usb_probe_device [ 63.132812] usb 1-2: configuration #1 chosen from 1 choice [ 63.139160] usb 1-2: adding 1-2:1.0 (config #1, interface 0) [ 63.145629] hub 1-2:1.0: usb_probe_interface [ 63.150146] hub 1-2:1.0: usb_probe_interface - got id [ 63.155578] hub 1-2:1.0: USB hub found [ 63.200195] hub 1-2:1.0: 4 ports detected [ 63.204467] hub 1-2:1.0: standalone hub [ 63.208679] hub 1-2:1.0: ganged power switching [ 63.213470] hub 1-2:1.0: global over-current protection [ 63.219055] hub 1-2:1.0: Single TT [ 63.222747] hub 1-2:1.0: TT requires at most 16 FS bit times (1332 ns) [ 63.229644] hub 1-2:1.0: Port indicators are supported [ 63.235137] hub 1-2:1.0: power on to power good time: 0ms [ 63.242584] hub 1-2:1.0: local power source is good [ 63.247955] hub 1-2:1.0: no over-current condition exists [ 63.254852] hub 1-2:1.0: enabling power on all ports [ 63.357482] usb 1-2: link qh256-0001/cf68f6c0 start 1 [1/0 us] [ 63.364044] hub 1-2:1.0: state 7 ports 4 chg evt [ 63.370086] hub 1-2:1.0: hub_suspend [ 63.374023] usb 1-2: unlink qh256-0001/cf68f6c0 start 1 [1/0 us] [ 63.384948] usb 1-2: usb auto-suspend, wakeup 1 [ 63.410217] hub 1-0:1.0: hub_suspend [ 63.414062] usb usb1: bus auto-suspend, wakeup 1 [ 63.419036] ehci-omap ehci-omap.0: suspend root hub root@beagleboard:~# root@beagleboard:~# lsusb [ 80.925262] usb usb1: usb auto-resume [ 80.929351] ehci-omap ehci-omap.0: resume root hub [ 80.934539] hub 1-0:1.0: hub_resume [ 80.938323] hub 1-0:1.0: port 2: status 0507 change [ 80.945373] hub 1-0:1.0: state 7 ports 3 chg evt [ 80.952026] hub 1-0:1.0: hub_suspend [ 80.956024] usb
[PATCH] net: cdc_ncm: add another Huawei vendor specific device
Adding a new vendor specific class/subclass/protocol combination
for CDC NCM devices based on information from a GPLed out-of-tree
driver from Huawei.
Signed-off-by: Bjørn Mork bj...@mork.no
---
drivers/net/usb/cdc_ncm.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 9197b2c..00d3b2d 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1215,6 +1215,9 @@ static const struct usb_device_id cdc_devs[] = {
{ USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x46),
.driver_info = (unsigned long)wwan_info,
},
+ { USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x76),
+ .driver_info = (unsigned long)wwan_info,
+ },
/* Infineon(now Intel) HSPA Modem platform */
{ USB_DEVICE_AND_INTERFACE_INFO(0x1519, 0x0443,
--
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
[PATCH] net: qmi_wwan: add more Huawei devices, including E320
Adding new class/subclass/protocol combinations based on the GPLed
out-of-tree Huawei driver. One of these has already appeared on a
device labelled as E320.
Signed-off-by: Bjørn Mork bj...@mork.no
---
drivers/net/usb/qmi_wwan.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 2ca7f8e..c8e05e2 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -351,6 +351,10 @@ static const struct usb_device_id products[] = {
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,
USB_CLASS_VENDOR_SPEC, 1, 57),
.driver_info= (unsigned long)qmi_wwan_info,
},
+ { /* HUAWEI_INTERFACE_NDIS_CONTROL_QUALCOMM */
+ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,
USB_CLASS_VENDOR_SPEC, 0x01, 0x69),
+ .driver_info= (unsigned long)qmi_wwan_info,
+ },
/* 2. Combined interface devices matching on class+protocol */
{ /* Huawei E367 and possibly others in Windows mode */
@@ -361,6 +365,14 @@ static const struct usb_device_id products[] = {
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,
USB_CLASS_VENDOR_SPEC, 1, 17),
.driver_info= (unsigned long)qmi_wwan_info,
},
+ { /* HUAWEI_NDIS_SINGLE_INTERFACE_VDF */
+ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,
USB_CLASS_VENDOR_SPEC, 0x01, 0x37),
+ .driver_info= (unsigned long)qmi_wwan_info,
+ },
+ { /* HUAWEI_INTERFACE_NDIS_HW_QUALCOMM */
+ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,
USB_CLASS_VENDOR_SPEC, 0x01, 0x67),
+ .driver_info= (unsigned long)qmi_wwan_info,
+ },
{ /* Pantech UML290, P4200 and more */
USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC,
0xf0, 0xff),
.driver_info= (unsigned long)qmi_wwan_info,
--
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: MUSB regression in linux next at least for pandboard
Hi, On Wed, Feb 06, 2013 at 05:03:36PM +0200, Roger Quadros wrote: On 02/06/2013 03:51 PM, Felipe Balbi wrote: Hi, On Wed, Feb 06, 2013 at 05:27:52PM +0530, Vivek Gautam wrote: Hi Tony, On Fri, Oct 5, 2012 at 9:57 PM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [121004 18:41]: Also on the EHCI port, I've seen issues where unplugging the cable hangs kernel with an infinite loop. But that happens only occasionally, sorry does not seem to happen right now so no output to paste here. Or maybe this issue has already been fixed? Looks like the system eventually recovers from the EHCI issue after about fivew minutes or so of spamming the logs. It seems the ehci-omap errors are: [62934.201538] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 31 [62934.201660] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes [62934.201873] ehci-omap ehci-omap.0: reused qh ea5632c0 schedule More data below. Is this issue fixed ? Actually we too are getting very similar issue with samsung exynos5250 hardware. With latest 'usb-next' kernel and supporting arch patches, when i use following test scenerio: Connect a USB 2.0 external hub to USB 2.0 port, and connect mice or keyboard enumeration and functionality is fine but once disconnecting the HID we get to see the error log: hid-generic 0003:04B3:3025.0002: can't reset device, s5p-ehci-1.3/input0, status -71 When i tried to enable CONFIG_USB_DEBUG, get the following log: looks like it's not OMAP-specific. Alan any tips ? I can't reproduce the problem on Panda, but I can on Beagle with a slightly different behaviour. 1) connecting/disconnecting device directly to the beagleboard's USB port works fine. 2) If I connect a USB Hub to the port and connect a device to it after the hub has autosuspended, the device is never detected. doing lsusb after that triggers the detection and produces a lot of transaction errors. Beagle log is below, before and after 'lsusb' I suppose this doesn't affect Panda because it has a hub connected immediately below the root hub that never suspends (as ethernet is hardwired to it). Roger, try changing hub's autosuspend delay to something greater than 30ms and see if it helps. There was a discussion lately about that. -- balbi signature.asc Description: Digital signature
Re: Linux USB file storage gadget with new UDC
On Wed, 6 Feb 2013, victor yeo wrote:
Hi,
Thanks, i added in UDC driver to call bulk_in_complete for every
request over a bulk in ep, now the gadget driver is able to process
the SCSI Inquiry command. When it comes to SCSI Read Format Capacities
command, the gadget driver gives attention condition error in
check_command() in the code snippet below, and the command is not
processed by do_read_format_capacities().
if (curlun curlun-unit_attention_data != SS_NO_SENSE
fsg-cmnd[0] != INQUIRY
fsg-cmnd[0] != REQUEST_SENSE) {
curlun-sense_data = curlun-unit_attention_data;
curlun-unit_attention_data = SS_NO_SENSE;
return -EINVAL;
}
Besides the code snippet, the only place that sets unit_attention data
to SS_NO_SENSE is in handle_exception(). How is UDC driver able to
overcome this problem?
What problem? This all sounds perfectly normal.
Maybe you should post the kernel debugging log.
The problem is READ FORMAT CAPACITIES command is not processed, and no
reply is sent back in response to the command.
What do you mean by no reply is sent back? Doesn't the CSW packet
get sent by send_status?
Not processing the command is normal if curlun-unit_attention_data is
set to something other than SS_NO_SENSE. Note that the code above
changes curlun-unit_attention_data back to SS_NO_SENSE, so if the host
sends the same command again then it should work the second time.
the kernel log does not show any error that is related to SCSI commands.
Please post it anyway. It still may contain useful information even
though it doesn't contain any errors.
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: MUSB regression in linux next at least for pandboard
On Wed, 6 Feb 2013, Felipe Balbi wrote:
I can't reproduce the problem on Panda, but I can on Beagle with a slightly
different behaviour.
1) connecting/disconnecting device directly to the beagleboard's USB port
works fine.
2) If I connect a USB Hub to the port and connect a device to it after the
hub has
autosuspended, the device is never detected.
doing lsusb after that triggers the detection and produces a lot of
transaction errors.
Beagle log is below, before and after 'lsusb'
I suppose this doesn't affect Panda because it has a hub connected
immediately below the
root hub that never suspends (as ethernet is hardwired to it).
Roger, try changing hub's autosuspend delay to something greater than
30ms and see if it helps. There was a discussion lately about that.
There also were some patches to address this problem recently merged by
Greg KH (they are in Linus's current git, added after 3.8-rc6 was
released):
da0aa7169b97d90f4af39a9dc84d58bbe19d7e78 USB: add
usb_hcd_{start,end}_port_resume
f292e7f9fb0e4bec68bbd83443407d6bb7922d36 USB: EHCI: notify usbcore about port
resumes
ee74290b7853db9d5fd64db70e5c175241c59fba USB: EHCI: fix timer bug affecting
port resume
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb host: Faraday FUSBH200 HCD driver.
On Wed, 6 Feb 2013, Yuan-Hsin Chen wrote: From: Yuan-Hsin Chen yhc...@faraday-tech.com USB2.0 HCD driver for Faraday FUSBH200 In what way is this driver different from the existing ehci-hcd driver? It looks like almost all of the code is identical. We don't need to have two copies of the same code in the kernel. 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: [regression] external HDD in USB3 enclosure cannot be dynamically removed (Re: Linux 3.7.5)
On Wed, 6 Feb 2013, Paul Volkov wrote: Hello. Jonathan Nieder wrote about forwarding info about USB 3.0 disconnect issue to relevant people: http://www.spinics.net/lists/linux-usb/msg78853.html Summary of the problem: block devices belonging to USB 3.0 external drives do not disappear from /dev after physical disconnect and there's no message about the disconnect in system log. Since we cannot see the continuation of the topic in this list, I'm wondering if it's being looked into or not. The USB-3 maintainer is currently busy (LinuxConf-Au and aftermath). No doubt she will look into this problem when she returns. 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: MUSB regression in linux next at least for pandboard
On Wed, 6 Feb 2013, Felipe Balbi wrote: Hi, On Wed, Feb 06, 2013 at 05:27:52PM +0530, Vivek Gautam wrote: Hi Tony, On Fri, Oct 5, 2012 at 9:57 PM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [121004 18:41]: Also on the EHCI port, I've seen issues where unplugging the cable hangs kernel with an infinite loop. But that happens only occasionally, sorry does not seem to happen right now so no output to paste here. Or maybe this issue has already been fixed? Looks like the system eventually recovers from the EHCI issue after about fivew minutes or so of spamming the logs. It seems the ehci-omap errors are: [62934.201538] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 31 [62934.201660] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes [62934.201873] ehci-omap ehci-omap.0: reused qh ea5632c0 schedule More data below. Is this issue fixed ? Actually we too are getting very similar issue with samsung exynos5250 hardware. With latest 'usb-next' kernel and supporting arch patches, when i use following test scenerio: Connect a USB 2.0 external hub to USB 2.0 port, and connect mice or keyboard enumeration and functionality is fine but once disconnecting the HID we get to see the error log: hid-generic 0003:04B3:3025.0002: can't reset device, s5p-ehci-1.3/input0, status -71 When i tried to enable CONFIG_USB_DEBUG, get the following log: looks like it's not OMAP-specific. Alan any tips ? It could be a problem with the hub the keyboard is plugged into. Or something going on with the hub driver. I'll try doing the same thing on my system. (keeping logs below) ... s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 1 usb 1-1.3: unlink qh8-0e01/c193f140 start 2 [1/2 us] s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 1 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 2 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 3 hub 1-1:1.0: state 7 ports 7 chg evt 0008 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 4 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 5 hub 1-1:1.0: port 3, status 0100, change 0001, 12 Mb/s s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 6 usb 1-1.3: USB disconnect, device number 5 usb 1-1.3: unregistering device usb 1-1.3: unregistering interface 1-1.3:1.0 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 7 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 8 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 9 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 10 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 11 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 12 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 13 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 14 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 15 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 16 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 17 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 18 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 19 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 20 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 21 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 22 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 23 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 24 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 25 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 26 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 27 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 28 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 29 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 30 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 31 s5p-ehci s5p-ehci: devpath 1.3 ep0out 3strikes usb 1-1: clear tt buffer port 3, a5 ep0 t00080248 hid-generic 0003:04B3:3025.0002: can't reset device, s5p-ehci-1.3/input0, status -71 Note that most of these are debug messages, so they wouldn't normally appear. (BTW: timestamps would be nice -- CONFIG_PRINTK_TIME.) Similar log as you get on ehci-omap ;-) Sorry i might have missed some information to put here. Your help will be very much useful. Thanks in advance :-) ... [62927.200012] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 19 [62927.215606] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 25 [62927.220092] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 22 [62927.225738] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes A certain amount of this is normal when an HID device is unplugged. It should stop after 250 ms, however, when the hub notifies the host that a cable has been unplugged. (Unless the hub driver is busy doing something else at the time...) ... After waiting for several minutes, it stops, and dmesg shows: # dmesg | grep -i omap This grep will drop the important information. Alan Stern -- To unsubscribe from
Re: [RFC/PATCH 1/2] usb: gadget: let gadgets control pullup on their own
On Wed, Feb 06, 2013 at 10:45:13AM -0500, Alan Stern wrote: On Wed, 6 Feb 2013, Felipe Balbi wrote: This is useful on gadgets that depend on userland daemons to function properly. We can delay connection to the host until userland is ready. --- a/drivers/usb/gadget/udc-core.c +++ b/drivers/usb/gadget/udc-core.c @@ -235,7 +235,18 @@ static void usb_gadget_remove_driver(struct usb_udc *udc) kobject_uevent(udc-dev.kobj, KOBJ_CHANGE); - usb_gadget_disconnect(udc-gadget); + /* +* NOTICE: if gadget driver wants to control +* pullup, it needs to make sure that when +* user tries to rmmod the gadget driver, it +* will disconnect the pullups before returning +* from its -unbind() method. +* +* We are truly trusting the gadget driver here. +*/ + if (!udc-driver-controls_pullups) + usb_gadget_disconnect(udc-gadget); Even though you trust the gadget driver about when to enable the pullup, doesn't it make sense to disable the pullup whenever the gadget driver is removed, regardless? Maybe, but we don't know what sort of trickery userland has. Also, I wanted to use this as a way to catch 'non-compliant' gadget drivers which say they will control pullup but don't. Maybe a warning if pullup is still connected ?!? -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb host: Faraday FUSBH200 HCD driver.
On Wed, Feb 06, 2013 at 07:24:01PM +0800, Yuan-Hsin Chen wrote: From: Yuan-Hsin Chen yhc...@faraday-tech.com USB2.0 HCD driver for Faraday FUSBH200 Signed-off-by: Yuan-Hsin Chen yhc...@faraday-tech.com just use ehci-platform.c and avoid the duplication -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 00/30] USB: omap-ehci: Move PHY management to PHY driver
* Roger Quadros rog...@ti.com [130206 01:53]: On 02/05/2013 07:17 PM, Tony Lindgren wrote: * Greg KH gre...@linuxfoundation.org [130205 09:00]: On Tue, Feb 05, 2013 at 01:28:51PM +0200, Roger Quadros wrote: Hi Tony Greg, What's the best way to get these patches in? All patches have been acked by respective maintainers. If Tony can Ack the arch/arm/mach-omap2 stuff then should I send a pull request directly to Greg? or the other way round? Tony, fyi, these patches should not interfere with the dw3c/musb stuff sent by Felipe Kishon. I'm fine with Tony just taking them all if he wants to. OK. Roger, can you please do me a pull request with these against v3.8-rc6? Tony, Since this depends on [1] and [2] which are both in linux-next, should I base it on linux-next? Maybe you can base it on some commit in Greg's USB tree? Just check with Greg that whatever you use as a base is an immutable commit and OK to use as a base. Another option is to defer this to 3.10 merge window, along with the DT adaptation for OMAP USB Host. Once you have a branch ready that builds and boots, let's see how badly that conflicts with other branches we have queued up. If it's trivial only, then maybe Greg can pick up the patches. If not, we can still try to merge it in later on during the merge window as it would be nice to get USB to usable point with DT. Regards, Tony [1] [PATCH v9 00/20] OMAP USB Host cleanup https://lkml.org/lkml/2013/1/23/155 [2] [PATCH v2 0/6] USB: Add support for multiple PHYs of same type https://lkml.org/lkml/2013/1/24/876 -- To unsubscribe from this list: send the line unsubscribe 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/1]linux-usb: fix the product IDs to be little endian in initializers.c
On Wed, Feb 06, 2013 at 05:24:12PM +0800, fangxiaozhi 00110321 wrote:
From: fangxiaozhi huana...@huawei.com
1. The idProduct is little endian, so make the product ID's value to be
little endian. Make no break on big endian processors.
Signed-off-by: fangxiaozhi huana...@huawei.com
diff -uprN linux-3.8-rc6_orig/drivers/usb/storage/initializers.c
linux-3.8-rc6/drivers/usb/storage/initializers.c
--- linux-3.8-rc6_orig/drivers/usb/storage/initializers.c 2013-02-06
14:48:51.564355283 +0800
+++ linux-3.8-rc6/drivers/usb/storage/initializers.c 2013-02-06
15:11:40.925434289 +0800
@@ -152,12 +152,15 @@ static int usb_stor_huawei_dongles_pid(s
* means the dongle in the single port mode,
* and a switch command is required to be sent. */
if (idesc idesc-bInterfaceNumber == 0) {
- if ((idProduct == 0x1001)
- || (idProduct == 0x1003)
- || (idProduct == 0x1004)
- || (idProduct = 0x1401 idProduct = 0x1500)
- || (idProduct = 0x1505 idProduct = 0x1600)
- || (idProduct = 0x1c02 idProduct = 0x2202)) {
+ if ((idProduct == cpu_to_le16(0x1001))
No, this doesn't fix the sparse warning, and is way too complex (and
doesn't really work well either.)
Please do the conversion on the value when you assign it to idProduct
and then you will be fine.
Please run sparse on your patch to ensure you got it right, if you would
have done so here, it would have been pretty obvious.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/30] USB: omap-ehci: Move PHY management to PHY driver
On Wed, Feb 06, 2013 at 09:11:54AM -0800, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [130206 01:53]: On 02/05/2013 07:17 PM, Tony Lindgren wrote: * Greg KH gre...@linuxfoundation.org [130205 09:00]: On Tue, Feb 05, 2013 at 01:28:51PM +0200, Roger Quadros wrote: Hi Tony Greg, What's the best way to get these patches in? All patches have been acked by respective maintainers. If Tony can Ack the arch/arm/mach-omap2 stuff then should I send a pull request directly to Greg? or the other way round? Tony, fyi, these patches should not interfere with the dw3c/musb stuff sent by Felipe Kishon. I'm fine with Tony just taking them all if he wants to. OK. Roger, can you please do me a pull request with these against v3.8-rc6? Tony, Since this depends on [1] and [2] which are both in linux-next, should I base it on linux-next? Maybe you can base it on some commit in Greg's USB tree? Just check with Greg that whatever you use as a base is an immutable commit and OK to use as a base. My public git trees should always be immutable and can be used as a base. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] qmi_wwan, cdc-ether: add ADU960S
It advertises a standard CDC-ETHER interface, which actually should be
driven by qmi_wwan.
Signed-off-by: Dan Williams d...@redhat.com
---
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 3f3d12d..cc6d0c1 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -615,6 +615,13 @@ static const struct usb_device_id products [] = {
.driver_info = 0,
},
+/* AnyDATA ADU960S - handled by qmi_wwan */
+{
+ USB_DEVICE_AND_INTERFACE_INFO(0x16d5, 0x650a, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+ .driver_info = 0,
+},
+
/*
* WHITELIST!!!
*
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 6a1ca50..2b5ea32 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(0x16d5, 0x650a, 8)},/* AnyDATA ADU960S */
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v2] usbnet: allow status interrupt URB to always be active
Some drivers (ex sierra_net) need the status interrupt URB
active even when the device is closed, because they receive
custom indications from firmware. Allow sub-drivers to set
a flag that submits the status interrupt URB on probe and
keeps the URB alive over device open/close. The URB is still
killed/re-submitted for suspend/resume, as before.
Signed-off-by: Dan Williams d...@redhat.com
---
Note: unchanged from previous version, but rebased.
drivers/net/usb/usbnet.c | 43 +++
include/linux/usb/usbnet.h | 3 +++
2 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 5e33606..5019cc7 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -206,13 +206,13 @@ static void intr_complete (struct urb *urb)
break;
}
- if (!netif_running (dev-net))
- return;
-
- status = usb_submit_urb (urb, GFP_ATOMIC);
- if (status != 0)
- netif_err(dev, timer, dev-net,
- intr resubmit -- %d\n, status);
+ if (dev-driver_info-flags FLAG_INTR_ALWAYS ||
+ netif_running(dev-net)) {
+ status = usb_submit_urb(urb, GFP_ATOMIC);
+ if (status != 0)
+ netif_err(dev, timer, dev-net,
+ intr resubmit -- %d\n, status);
+ }
}
static int init_status (struct usbnet *dev, struct usb_interface *intf)
@@ -725,7 +725,8 @@ int usbnet_stop (struct net_device *net)
if (!(info-flags FLAG_AVOID_UNLINK_URBS))
usbnet_terminate_urbs(dev);
- usb_kill_urb(dev-interrupt);
+ if (!(info-flags FLAG_INTR_ALWAYS))
+ usb_kill_urb(dev-interrupt);
usbnet_purge_paused_rxq(dev);
@@ -786,7 +787,7 @@ int usbnet_open (struct net_device *net)
}
/* start any status interrupt transfer */
- if (dev-interrupt) {
+ if (dev-interrupt !(info-flags FLAG_INTR_ALWAYS)) {
retval = usb_submit_urb (dev-interrupt, GFP_KERNEL);
if (retval 0) {
netif_err(dev, ifup, dev-net,
@@ -1496,6 +1497,15 @@ usbnet_probe (struct usb_interface *udev, const struct
usb_device_id *prod)
if (status 0)
goto out3;
+ /* Submit status interrupt URB immediately if sub-driver wants */
+ if (dev-interrupt (info-flags FLAG_INTR_ALWAYS)) {
+ status = usb_submit_urb(dev-interrupt, GFP_KERNEL);
+ if (status 0) {
+ dev_err(udev-dev, intr submit %d\n, status);
+ goto out4;
+ }
+ }
+
if (!dev-rx_urb_size)
dev-rx_urb_size = dev-hard_mtu;
dev-maxpacket = usb_maxpacket (dev-udev, dev-out, 1);
@@ -1507,7 +1517,7 @@ usbnet_probe (struct usb_interface *udev, const struct
usb_device_id *prod)
status = register_netdev (net);
if (status)
- goto out4;
+ goto out5;
netif_info(dev, probe, dev-net,
register '%s' at usb-%s-%s, %s, %pM\n,
udev-dev.driver-name,
@@ -1525,6 +1535,8 @@ usbnet_probe (struct usb_interface *udev, const struct
usb_device_id *prod)
return 0;
+out5:
+ usb_kill_urb(dev-interrupt);
out4:
usb_free_urb(dev-interrupt);
out3:
@@ -1586,8 +1598,15 @@ int usbnet_resume (struct usb_interface *intf)
if (!--dev-suspend_count) {
/* resume interrupt URBs */
- if (dev-interrupt test_bit(EVENT_DEV_OPEN, dev-flags))
- usb_submit_urb(dev-interrupt, GFP_NOIO);
+ if (dev-interrupt
+ (dev-driver_info-flags FLAG_INTR_ALWAYS ||
+ test_bit(EVENT_DEV_OPEN, dev-flags))) {
+ retval = usb_submit_urb(dev-interrupt, GFP_NOIO);
+ if (retval 0) {
+ netif_err(dev, ifup, dev-net,
+ intr submit %d\n, retval);
+ }
+ }
spin_lock_irq(dev-txq.lock);
while ((res = usb_get_from_anchor(dev-deferred))) {
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index 0de078d..b0f17f6 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -111,6 +111,9 @@ struct driver_info {
#define FLAG_MULTI_PACKET 0x2000
#define FLAG_RX_ASSEMBLE 0x4000 /* rx packets may span 1 frames */
+/* Indicates that the interrupt URB should not depend on netdev open/close */
+#define FLAG_INTR_ALWAYS 0x8000
+
/* init device ... can sleep, or cause probe() failure */
int (*bind)(struct usbnet *, struct usb_interface *);
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body
[PATCH 2/2 v2] sierra_net: fix issues with SYNC/RESTART messages and interrupt pipe setup
As part of the initialization sequence, the driver sends a SYNC message
via the control pipe to the firmware, which appears to request a
firmware restart. The firmware responds with an indication via the
interrupt pipe set up by usbnet. If the driver does not receive a
RESTART indication within a certain amount of time, it will periodically
send additional SYNC messages until it receives the RESTART indication.
Unfortunately, the interrupt URB is only submitted while the netdev
is open, which is usually not the case during initialization, and thus
the firmware's RESTART indication is lost. So the driver continues
sending SYNC messages, and eventually the firmware crashes when it
receives too many. This leads to a wedged netdev.
To ensure the firmware's RESTART indications can be received by the
driver, request that usbnet keep the interrupt URB active via
FLAG_INTR_ALWAYS.
Second, move the code that sends the SYNC message out of the
bind() hook and after usbnet_probe() to ensure the interrupt URB
is set up before trying to use it.
Signed-off-by: Dan Williams d...@redhat.com
---
drivers/net/usb/sierra_net.c | 33 ++---
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index 18dd425..185ffec 100644
--- a/drivers/net/usb/sierra_net.c
+++ b/drivers/net/usb/sierra_net.c
@@ -427,6 +427,13 @@ static void sierra_net_dosync(struct usbnet *dev)
dev_dbg(dev-udev-dev, %s, __func__);
+ /* The SIERRA_NET_HIP_MSYNC_ID command appears to request that the
+* firmware restart itself. After restarting, the modem will respond
+* with the SIERRA_NET_HIP_RESTART_ID indication. The driver continues
+* sending MSYNC commands every few seconds until it receives the
+* RESTART event from the firmware
+*/
+
/* tell modem we are ready */
status = sierra_net_send_sync(dev);
if (status 0)
@@ -709,6 +716,9 @@ static int sierra_net_bind(struct usbnet *dev, struct
usb_interface *intf)
/* set context index initially to 0 - prepares tx hdr template */
sierra_net_set_ctx_index(priv, 0);
+ /* prepare sync message template */
+ memcpy(priv-sync_msg, sync_tmplate, sizeof(priv-sync_msg));
+
/* decrease the rx_urb_size and max_tx_size to 4k on USB 1.1 */
dev-rx_urb_size = SIERRA_NET_RX_URB_SIZE;
if (dev-udev-speed != USB_SPEED_HIGH)
@@ -744,11 +754,6 @@ static int sierra_net_bind(struct usbnet *dev, struct
usb_interface *intf)
kfree(priv);
return -ENODEV;
}
- /* prepare sync message from template */
- memcpy(priv-sync_msg, sync_tmplate, sizeof(priv-sync_msg));
-
- /* initiate the sync sequence */
- sierra_net_dosync(dev);
return 0;
}
@@ -905,7 +910,7 @@ static struct sk_buff *sierra_net_tx_fixup(struct usbnet
*dev,
static const struct driver_info sierra_net_info_direct_ip = {
.description = Sierra Wireless USB-to-WWAN Modem,
- .flags = FLAG_WWAN | FLAG_SEND_ZLP,
+ .flags = FLAG_WWAN | FLAG_SEND_ZLP | FLAG_INTR_ALWAYS,
.bind = sierra_net_bind,
.unbind = sierra_net_unbind,
.status = sierra_net_status,
@@ -913,6 +918,20 @@ static const struct driver_info sierra_net_info_direct_ip
= {
.tx_fixup = sierra_net_tx_fixup,
};
+static int
+sierra_net_probe (struct usb_interface *udev, const struct usb_device_id *prod)
+{
+ int ret;
+
+ ret = usbnet_probe (udev, prod);
+ if (ret == 0) {
+ /* Interrupt URB now set up; initiate sync sequence */
+ sierra_net_dosync(usb_get_intfdata(udev));
+ }
+
+ return ret;
+}
+
#define DIRECT_IP_DEVICE(vend, prod) \
{USB_DEVICE_INTERFACE_NUMBER(vend, prod, 7), \
.driver_info = (unsigned long)sierra_net_info_direct_ip}, \
@@ -935,7 +954,7 @@ MODULE_DEVICE_TABLE(usb, products);
static struct usb_driver sierra_net_driver = {
.name = sierra_net,
.id_table = products,
- .probe = usbnet_probe,
+ .probe = sierra_net_probe,
.disconnect = usbnet_disconnect,
.suspend = usbnet_suspend,
.resume = usbnet_resume,
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe 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: bugreport upstream: 0bda:819a RTL8188CUS WLAN doesn't work out of the box
On 01/26/2013 04:07 PM, Xose Vazquez Perez wrote:
Thomas Rosenkranz wrote:
0bda:819a RTL8188CUS WLAN doesn't work out of the box in downstream
and upstreamkernel
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1102179
This should go to linux-wirel...@vger.kernel.org
Try:
# modprobe rtl8192cu
# echo 0bda 819a /sys/bus/usb/drivers/rtl8192cu/new_id
# dmesg (see output)
Please install the attached patch, and retry the above method. I fixed the probe
function to get rid of the oops. If the device is really foreign, the process
that writes new_id will not finish until the device is unplugged; however, the
rest of the system is chugging along.
If 0bda:819a works with rtl8192cu, let me know, and I'll update the USB device
table.
Larry
From 2bd60bf2a4b91c9ae4e552568c4b76e238fc01a9 Mon Sep 17 00:00:00 2001
From: Larry Finger larry.fin...@lwfinger.net
Date: Wed, 6 Feb 2013 12:41:36 -0600
Subject: [PATCH V2] rtlwifi: rtl8192cu: Fix NULL dereference BUG when using
new_id
To: linvi...@tuxdriver.com
Cc: net...@vger.kernel.org
When the new_id entry in /sysfs is used for a foreign USB device, rtlwifi
BUGS with a NULL pointer dereference because the per-driver configuration
data is not available. The probe function has been restructured as
suggested by Ben Hutchings bhutchi...@solarflare.com.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
Cc: Stable sta...@vger.kernel.org
---
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 8 +++-
drivers/net/wireless/rtlwifi/usb.c | 5 +++--
drivers/net/wireless/rtlwifi/usb.h | 3 ++-
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
index d9e659f..577c0dc 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -363,9 +363,15 @@ static struct usb_device_id rtl8192c_usb_ids[] = {
MODULE_DEVICE_TABLE(usb, rtl8192c_usb_ids);
+static int rtl8192cu_probe(struct usb_interface *intf,
+ const struct usb_device_id *id)
+{
+ return rtl_usb_probe(intf, id, rtl92cu_hal_cfg);
+}
+
static struct usb_driver rtl8192cu_driver = {
.name = rtl8192cu,
- .probe = rtl_usb_probe,
+ .probe = rtl8192cu_probe,
.disconnect = rtl_usb_disconnect,
.id_table = rtl8192c_usb_ids,
diff --git a/drivers/net/wireless/rtlwifi/usb.c b/drivers/net/wireless/rtlwifi/usb.c
index d42bbe2..476eaef 100644
--- a/drivers/net/wireless/rtlwifi/usb.c
+++ b/drivers/net/wireless/rtlwifi/usb.c
@@ -937,7 +937,8 @@ static struct rtl_intf_ops rtl_usb_ops = {
};
int rtl_usb_probe(struct usb_interface *intf,
- const struct usb_device_id *id)
+ const struct usb_device_id *id,
+ struct rtl_hal_cfg *rtl_hal_cfg)
{
int err;
struct ieee80211_hw *hw = NULL;
@@ -972,7 +973,7 @@ int rtl_usb_probe(struct usb_interface *intf,
usb_set_intfdata(intf, hw);
/* init cfg intf_ops */
rtlpriv-rtlhal.interface = INTF_USB;
- rtlpriv-cfg = (struct rtl_hal_cfg *)(id-driver_info);
+ rtlpriv-cfg = rtl_hal_cfg;
rtlpriv-intf_ops = rtl_usb_ops;
rtl_dbgp_flag_init(hw);
/* Init IO handler */
diff --git a/drivers/net/wireless/rtlwifi/usb.h b/drivers/net/wireless/rtlwifi/usb.h
index 5235136..fb986f9 100644
--- a/drivers/net/wireless/rtlwifi/usb.h
+++ b/drivers/net/wireless/rtlwifi/usb.h
@@ -157,7 +157,8 @@ struct rtl_usb_priv {
int rtl_usb_probe(struct usb_interface *intf,
- const struct usb_device_id *id);
+ const struct usb_device_id *id,
+ struct rtl_hal_cfg *rtl92cu_hal_cfg);
void rtl_usb_disconnect(struct usb_interface *intf);
int rtl_usb_suspend(struct usb_interface *pusb_intf, pm_message_t message);
int rtl_usb_resume(struct usb_interface *pusb_intf);
--
1.8.1
Re: [PATCH] qmi_wwan, cdc-ether: add ADU960S
Dan Williams d...@redhat.com writes:
It advertises a standard CDC-ETHER interface, which actually should be
driven by qmi_wwan.
Signed-off-by: Dan Williams d...@redhat.com
---
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 3f3d12d..cc6d0c1 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -615,6 +615,13 @@ static const struct usb_device_idproducts [] = {
.driver_info = 0,
},
+/* AnyDATA ADU960S - handled by qmi_wwan */
+{
+ USB_DEVICE_AND_INTERFACE_INFO(0x16d5, 0x650a, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+ .driver_info = 0,
+},
+
/*
* WHITELIST!!!
*
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 6a1ca50..2b5ea32 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(0x16d5, 0x650a, 8)},/* AnyDATA ADU960S */
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
Just thinking
Maybe we should use USB_DEVICE_AND_INTERFACE_INFO() in qmi_wwan as well
for these devices? The only reason we match on interface number for
most devices in that driver is because those devices use ff/ff/ff for
multiple different functions. When the function is uniquely identified
using class/subclass/protocol as here, then I believe it makes more
sense to use those values. And it creates a symmetry between the
cdc_ether and the qmi_wwan entries, making the connection between them
clearer.
Not to mention that such symmetry prevents us from ending up with no
driver supporting the device if some firmware upgrade happened to change
the interface number..
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
Re: [PATCH 2/2 v2] sierra_net: fix issues with SYNC/RESTART messages and interrupt pipe setup
On Wednesday 06 February 2013 12:42:56 Dan Williams wrote: As part of the initialization sequence, the driver sends a SYNC message via the control pipe to the firmware, which appears to request a firmware restart. The firmware responds with an indication via the interrupt pipe set up by usbnet. If the driver does not receive a RESTART indication within a certain amount of time, it will periodically send additional SYNC messages until it receives the RESTART indication. Unfortunately, the interrupt URB is only submitted while the netdev is open, which is usually not the case during initialization, and thus the firmware's RESTART indication is lost. So the driver continues sending SYNC messages, and eventually the firmware crashes when it receives too many. This leads to a wedged netdev. If I understand this correctly we should stop the interrupt pipe once RESTART has been recieved. I am afraid this patch is a bit inefficient. 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 1/2 v2] usbnet: allow status interrupt URB to always be active
On Wednesday 06 February 2013 12:36:38 Dan Williams wrote: Some drivers (ex sierra_net) need the status interrupt URB active even when the device is closed, because they receive custom indications from firmware. Allow sub-drivers to set a flag that submits the status interrupt URB on probe and keeps the URB alive over device open/close. The URB is still killed/re-submitted for suspend/resume, as before. Given your description in the later patch, which uses this feature, it seems to me that we can be more efficient if we include infrastructure to determine whether the interrupt URB is still needed under some circumstances. Could we put this on hold until we are clear on the requirements of the protocol? 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: usbip-utils USBIP_VERSION
Alexander Zubkov gr...@msu.ru writes:
Hi.
I was trying to bring together Linux Windows usbip and faced a
problem with currently published on SourceForge windows driver and
tools. usbip.exe -l host is saying:
usbip err: ... (usbip_recv_op_common) recv op_common, -1
...
Debugging and tcpdumping showed that problem lies in that Windows side
thinks it speaks 0x0106 version of the protocol and Linux side think
it is 0x0111. Git tree of Linux shows that its define in
drivers/staging/usbip/userspace/configure.ac USBIP_VERSION was
changing 0x0106 - 0x0100 - 0x0111 without obvious (to me at least)
reasons.
So Linux-side rejects connections because of protocol
mistmatch. Currently, I have recompiled usbip-utils on Linux system
with fixed version and it became speaking to Windows now. But I have
not tested devices yet.
I think this should be fixed somehow in usbip-utils - by downgrading
version, or accepting other compatible versions.
Looks like you are right. The USBIP_VERSION changes look like they were
unintentional. The first one, commit e9837bbb3 (staging: usbip:
userspace tools v1.0.0) states:
Nothing significant has changed so compatibility with windows has
_not_ been broken.
Which is clearly not true with this diff:
--- a/drivers/staging/usbip/userspace/configure.ac
+++ b/drivers/staging/usbip/userspace/configure.ac
@@ -1,8 +1,8 @@
dnl Process this file with autoconf to produce a configure script.
AC_PREREQ(2.59)
-AC_INIT([usbip], [0.1.8], [usbip-de...@lists.sourceforge.net])
-AC_DEFINE([USBIP_VERSION], [0x000106], [numeric version number])
+AC_INIT([usbip], [1.0.0], [usbip-de...@lists.sourceforge.net])
+AC_DEFINE([USBIP_VERSION], [0x0100], [binary-coded decimal version number])
CURRENT=0
REVISION=1
combined with code like this, using USBIP_VERSION from config.h:
if (op_common.version != USBIP_VERSION) {
err(version mismatch, %d %d, op_common.version,
USBIP_VERSION);
goto err;
}
I believe the commit message clearly shows that this breakage was not
intended and that the USBIP_VERSION should be reverted to 0x000106
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
Re: [PATCH] net: cdc_ncm: add another Huawei vendor specific device
From: Bjørn Mork bj...@mork.no Date: Wed, 6 Feb 2013 16:21:53 +0100 Adding a new vendor specific class/subclass/protocol combination for CDC NCM devices based on information from a GPLed out-of-tree driver from Huawei. Signed-off-by: Bjørn Mork bj...@mork.no Applied. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 v2] sierra_net: fix issues with SYNC/RESTART messages and interrupt pipe setup
Dan Williams d...@redhat.com writes: As part of the initialization sequence, the driver sends a SYNC message via the control pipe to the firmware, which appears to request a firmware restart. The firmware responds with an indication via the interrupt pipe set up by usbnet. If the driver does not receive a RESTART indication within a certain amount of time, it will periodically send additional SYNC messages until it receives the RESTART indication. Unfortunately, the interrupt URB is only submitted while the netdev is open, which is usually not the case during initialization, and thus the firmware's RESTART indication is lost. So the driver continues sending SYNC messages, and eventually the firmware crashes when it receives too many. This leads to a wedged netdev. To ensure the firmware's RESTART indications can be received by the driver, request that usbnet keep the interrupt URB active via FLAG_INTR_ALWAYS. Second, move the code that sends the SYNC message out of the bind() hook and after usbnet_probe() to ensure the interrupt URB is set up before trying to use it. Given this description I am wondering if you couldn't just move the whole SYNC thing to a new reset() hook, using some private flag to make sure it only runs once? Does it really need to start at probe time? 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
Re: [REVERT][v3.x.y] EHCI: Update qTD next pointer in QH overlay region during unlink
On 02/04/2013 05:04 PM, Alan Stern wrote: On Fri, 1 Feb 2013, Joseph Salisbury wrote: Hi Alan, There is a tar file[0] attached to the bug report[1]. The tar file contains a few examples of failed and successful recording attempts while collecting usbmon traces. There is a readme.txt file available after extracting the files. The bug reporter states that only the first recording after boot fails. Subsequent recordings succeed will succeed. Thanks again for reviewing this, Alan. Just let me know if you would like any additional data or testing. Thanks, Joe [0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088733/+attachment/3510887/+files/usbmon-1088733.tar.gz [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088733 I have replied to the original report at bugs.launchpad.net with a diagnostic patch. Maybe it will help indicate what's going wrong. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi Alan, The bug reporter collected some data[0] using your diagnostic patch. Thanks again for all your help. Joe [0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088733/+attachment/3516533/+files/usbmon-diag-1088733.tar.gz -- To unsubscribe from this list: send the line unsubscribe 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: bugreport upstream: 0bda:819a RTL8188CUS WLAN doesn't work out of the box
On 02/06/2013 02:03 PM, Thomas Rosenkranz wrote: Sorry for aksing back. 1. You mean I should get the kernel clean of the realtek driver first to prevent a crash during patching? Cause unplugging is no option for a onboard device. 2. I have no idea what to do with the patching file and couldn't find any good instructions with google. man patch doesn't make me smarter at all Put the patch in the directory where the arch, block, crypto, drivers, and so forth directories are located. Then run the command patch -p1 0001-..patch After that, run make followed by sudo make modules_install install. If your distro is reasonable, that will give you a new entry in your boot menu. Larry -- To unsubscribe from this list: send the line unsubscribe 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: [V6 PATCH 01/16] usb: phy: mv_usb2: add PHY driver for marvell usb2 controller
On Wed, Feb 6, 2013 at 10:42 PM, Mark Rutland mark.rutl...@arm.com wrote:
Hi,
I have a few comments on the devicetree binding and the way it's parsed.
I note many are similar to those I commented on for the mv_udc and ehci-mv
devicetree code.
On Wed, Feb 06, 2013 at 07:23:36AM +, Chao Xie wrote:
The PHY is seperated from usb controller.
The usb controller used in marvell pxa168/pxa910/mmp2 are same,
but PHY initialization may be different.
the usb controller can support udc/otg/ehci, and for each of
the mode, it need PHY to initialized before use the controller.
Direclty writing the phy driver will make the usb controller
driver to be simple and portable.
The PHY driver will be used by marvell udc/otg/ehci.
Signed-off-by: Chao Xie chao@marvell.com
---
drivers/usb/phy/Kconfig |7 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/mv_usb2_phy.c| 454
++
include/linux/platform_data/mv_usb.h |9 +-
include/linux/usb/mv_usb2.h | 43
5 files changed, 511 insertions(+), 3 deletions(-)
create mode 100644 drivers/usb/phy/mv_usb2_phy.c
create mode 100644 include/linux/usb/mv_usb2.h
[...]
+static struct of_device_id usb_phy_dt_ids[] = {
+ { .compatible = mrvl,pxa168-usb-phy, .data = (void *)PXA168_USB},
+ { .compatible = mrvl,pxa910-usb-phy, .data = (void *)PXA910_USB},
+ { .compatible = mrvl,mmp2-usb-phy,.data = (void *)MMP2_USB},
+ {}
+};
+MODULE_DEVICE_TABLE(of, usb_phy_dt_ids);
The binding (including these compatible string) needs to be documented.
+
+static int usb_phy_parse_dt(struct platform_device *pdev,
+ struct mv_usb2_phy *mv_phy)
+{
+ struct device_node *np = pdev-dev.of_node;
+ const struct of_device_id *of_id =
+ of_match_device(usb_phy_dt_ids, pdev-dev);
+ unsigned int clks_num;
+ int i, ret;
+ const char *clk_name;
+
+ if (!np)
+ return 1;
An actual error code please.
-ENODEV? -EINVAL?
+
+ clks_num = of_property_count_strings(np, clocks);
+ if (clks_num 0) {
+ dev_err(pdev-dev, failed to get clock number\n);
+ return clks_num;
+ }
The common clock bindings use clocks as a list of phandle and
clock-specifier
pairs. It seems bad to reuse that name in a different sense for this binding.
I'd recommend you use the common clock binding. There doesn't seem to be an
of_clk_count, but it should be a relatively simple addition, and it'd make
this
code clearer and more consistent with other drivers.
See Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+ mv_phy-clks = devm_kzalloc(pdev-dev,
+ sizeof(struct clk *) * clks_num, GFP_KERNEL);
+ if (mv_phy-clks == NULL) {
+ dev_err(pdev-dev,
+ failed to allocate mempory for clocks);
s/mempory/memory/
+ return -ENOMEM;
+ }
+
+ for (i = 0; i clks_num; i++) {
+ ret = of_property_read_string_index(np, clocks, i,
+ clk_name);
+ if (ret) {
+ dev_err(pdev-dev, failed to read clocks\n);
+ return ret;
+ }
+ mv_phy-clks[i] = devm_clk_get(pdev-dev, clk_name);
+ if (IS_ERR(mv_phy-clks[i])) {
+ dev_err(pdev-dev, failed to get clock %s\n,
+ clk_name);
+ return PTR_ERR(mv_phy-clks[i]);
+ }
+ }
+
+ mv_phy-clks_num = clks_num;
+ mv_phy-type = (enum mv_usb2_phy_type)(of_id-data);
+
+ return 0;
+}
There's probably a need for something like devm_of_clk_get to make it easier
to
write of-backed drivers.
+
+static int usb_phy_probe(struct platform_device *pdev)
+{
+ struct mv_usb2_phy *mv_phy;
+ struct resource *r;
+ int ret, i;
+
+ mv_phy = devm_kzalloc(pdev-dev, sizeof(*mv_phy), GFP_KERNEL);
+ if (mv_phy == NULL) {
+ dev_err(pdev-dev, failed to allocate memory\n);
+ return -ENOMEM;
+ }
+ mutex_init(mv_phy-phy_lock);
+
+ ret = usb_phy_parse_dt(pdev, mv_phy);
+ /* no CONFIG_OF */
+ if (ret 0) {
Reorganise this so you test for pdev-dev.of_node, and based of that you
either
call usb_phy_parse_dt or do this stuff in the block below. That way you don't
need
the positive return code from usb_phy_parse_dt.
+ struct mv_usb_phy_platform_data *pdata
+ = pdev-dev.platform_data;
+ const struct platform_device_id *id
+ = platform_get_device_id(pdev);
+
+ if (pdata == NULL || id == NULL) {
+ dev_err(pdev-dev,
+
Re: [V6 PATCH 01/16] usb: phy: mv_usb2: add PHY driver for marvell usb2 controller
On Wed, Feb 6, 2013 at 6:35 PM, kishon kis...@ti.com wrote: Hi, On Wednesday 06 February 2013 01:48 PM, Chao Xie wrote: On Wed, Feb 6, 2013 at 4:10 PM, kishon kis...@ti.com wrote: Hi, On Wednesday 06 February 2013 12:53 PM, Chao Xie wrote: The PHY is seperated from usb controller. The usb controller used in marvell pxa168/pxa910/mmp2 are same, but PHY initialization may be different. the usb controller can support udc/otg/ehci, and for each of the mode, it need PHY to initialized before use the controller. Direclty writing the phy driver will make the usb controller driver to be simple and portable. The PHY driver will be used by marvell udc/otg/ehci. Signed-off-by: Chao Xie chao@marvell.com --- drivers/usb/phy/Kconfig |7 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/mv_usb2_phy.c| 454 ++ include/linux/platform_data/mv_usb.h |9 +- include/linux/usb/mv_usb2.h | 43 5 files changed, 511 insertions(+), 3 deletions(-) create mode 100644 drivers/usb/phy/mv_usb2_phy.c create mode 100644 include/linux/usb/mv_usb2.h diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 65217a5..5479760 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -73,3 +73,10 @@ config SAMSUNG_USBPHY help Enable this to support Samsung USB phy controller for samsung SoCs. + +config MV_USB2_PHY + tristate Marvell USB 2.0 PHY Driver + depends on USB || USB_GADGET + help + Enable this to support Marvell USB 2.0 phy driver for Marvell + SoC. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index b13faa1..3835316 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -12,3 +12,4 @@ obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o obj-$(CONFIG_USB_RCAR_PHY)+= rcar-phy.o obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o +obj-$(CONFIG_MV_USB2_PHY) += mv_usb2_phy.o diff --git a/drivers/usb/phy/mv_usb2_phy.c b/drivers/usb/phy/mv_usb2_phy.c new file mode 100644 index 000..c2bccae --- /dev/null +++ b/drivers/usb/phy/mv_usb2_phy.c @@ -0,0 +1,454 @@ +/* + * Copyright (C) 2010 Google, Inc. + * + * Author: + * Chao Xie xiechao.m...@gmail.com + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * 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/resource.h +#include linux/delay.h +#include linux/slab.h +#include linux/of.h +#include linux/of_device.h +#include linux/io.h +#include linux/err.h +#include linux/clk.h +#include linux/export.h +#include linux/module.h +#include linux/platform_device.h +#include linux/platform_data/mv_usb.h +#include linux/usb/mv_usb2.h + +/* phy regs */ +#define UTMI_REVISION 0x0 +#define UTMI_CTRL 0x4 +#define UTMI_PLL 0x8 +#define UTMI_TX0xc +#define UTMI_RX0x10 +#define UTMI_IVREF 0x14 +#define UTMI_T00x18 +#define UTMI_T10x1c +#define UTMI_T20x20 +#define UTMI_T30x24 +#define UTMI_T40x28 +#define UTMI_T50x2c +#define UTMI_RESERVE 0x30 +#define UTMI_USB_INT 0x34 +#define UTMI_DBG_CTL 0x38 +#define UTMI_OTG_ADDON 0x3c + +/* For UTMICTRL Register */ +#define UTMI_CTRL_USB_CLK_EN(1 31) +/* pxa168 */ +#define UTMI_CTRL_SUSPEND_SET1 (1 30) +#define UTMI_CTRL_SUSPEND_SET2 (1 29) +#define UTMI_CTRL_RXBUF_PDWN(1 24) +#define UTMI_CTRL_TXBUF_PDWN(1 11) + +#define UTMI_CTRL_INPKT_DELAY_SHIFT 30 +#define UTMI_CTRL_INPKT_DELAY_SOF_SHIFT28 +#define UTMI_CTRL_PU_REF_SHIFT 20 +#define UTMI_CTRL_ARC_PULLDN_SHIFT 12 +#define UTMI_CTRL_PLL_PWR_UP_SHIFT 1 +#define UTMI_CTRL_PWR_UP_SHIFT 0 + +/* For UTMI_PLL Register */ +#define UTMI_PLL_PLLCALI12_SHIFT 29 +#define UTMI_PLL_PLLCALI12_MASK(0x3 29) + +#define UTMI_PLL_PLLVDD18_SHIFT27 +#define UTMI_PLL_PLLVDD18_MASK (0x3 27) + +#define UTMI_PLL_PLLVDD12_SHIFT25 +#define
Re: [PATCH] usb host: Faraday FUSBH200 HCD driver.
On Thu, Feb 7, 2013 at 12:38 AM, Felipe Balbi ba...@ti.com wrote: On Wed, Feb 06, 2013 at 07:24:01PM +0800, Yuan-Hsin Chen wrote: From: Yuan-Hsin Chen yhc...@faraday-tech.com USB2.0 HCD driver for Faraday FUSBH200 Signed-off-by: Yuan-Hsin Chen yhc...@faraday-tech.com just use ehci-platform.c and avoid the duplication -- balbi Thanks for your advice. I will modify and re-submit it later. Yuan-Hsin -- To unsubscribe from this list: send the line unsubscribe 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, resubmit] ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver
From: Freddy Xin fre...@asix.com.tw This is a resubmission. Fixed the issue that the default MTU is not 1500. Added ax88179_change_mtu function and enabled the hardware jumbo frame function to support an MTU higher than 1500. Fixed indentation and empty line coding style errors. The _nopm version usb functions were added to access register in suspend and resume functions. Serveral variables allocted dynamically were removed and replaced by stack variables. ax88179_get_eeprom were modified from asix_get_eeprom in asix_common. This patch adds a driver for ASIX's AX88179 family of USB 3.0/2.0 to gigabit ethernet adapters. It's based on the AX88xxx driver but the usb commands used to access registers for AX88179 are completely different. This driver had been verified on x86 system with AX88179/AX88178A and Sitcomm LN-032 USB dongles. Signed-off-by: Freddy Xin fre...@asix.com.tw --- drivers/net/usb/Kconfig| 18 + drivers/net/usb/Makefile |1 + drivers/net/usb/ax88179_178a.c | 1398 3 files changed, 1417 insertions(+) create mode 100644 drivers/net/usb/ax88179_178a.c diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig index ef97621..75af401 100644 --- a/drivers/net/usb/Kconfig +++ b/drivers/net/usb/Kconfig @@ -158,6 +158,24 @@ config USB_NET_AX8817X This driver creates an interface named ethX, where X depends on what other networking devices you have in use. +config USB_NET_AX88179_178A + tristate ASIX AX88179/178A USB 3.0/2.0 to Gigabit Ethernet + depends on USB_USBNET + select CRC32 + select PHYLIB + default y + help + This option adds support for ASIX AX88179 based USB 3.0/2.0 + to Gigabit Ethernet adapters. + + This driver should work with at least the following devices: + * ASIX AX88179 + * ASIX AX88178A + * Sitcomm LN-032 + + This driver creates an interface named ethX, where X depends on + what other networking devices you have in use. + config USB_NET_CDCETHER tristate CDC Ethernet support (smart devices such as cable modems) depends on USB_USBNET diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile index 4786913..119b06c 100644 --- a/drivers/net/usb/Makefile +++ b/drivers/net/usb/Makefile @@ -9,6 +9,7 @@ obj-$(CONFIG_USB_RTL8150) += rtl8150.o obj-$(CONFIG_USB_HSO) += hso.o obj-$(CONFIG_USB_NET_AX8817X) += asix.o asix-y := asix_devices.o asix_common.o ax88172a.o +obj-$(CONFIG_USB_NET_AX88179_178A) += ax88179_178a.o obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o obj-$(CONFIG_USB_NET_CDC_EEM) += cdc_eem.o obj-$(CONFIG_USB_NET_DM9601) += dm9601.o diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c new file mode 100644 index 000..6862e47 --- /dev/null +++ b/drivers/net/usb/ax88179_178a.c @@ -0,0 +1,1398 @@ +/* + * ASIX AX88179/178A USB 3.0/2.0 to Gigabit Ethernet Devices + * + * Copyright (C) 2011-2013 ASIX + * + * 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. + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + */ + +#include linux/module.h +#include linux/etherdevice.h +#include linux/mii.h +#include linux/usb.h +#include linux/crc32.h +#include linux/usb/usbnet.h + +#define AX88179_PHY_ID 0x03 +#define AX_EEPROM_LEN 0x100 +#define AX88179_EEPROM_MAGIC 0x17900b95 +#define AX_MCAST_FLTSIZE 8 +#define AX_MAX_MCAST 64 +#define AX_INT_PPLS_LINK BIT(0) +#define AX_RXHDR_L4_TYPE_UDP 1 +#define AX_RXHDR_L4_TYPE_TCP 4 +#define AX_ACCESS_MAC 0x01 +#define AX_ACCESS_PHY 0x02 +#define AX_ACCESS_EEPROM 0x04 +#define AX_ACCESS_EFUS 0x05 +#define AX_PAUSE_WATERLVL_HIGH 0x54 +#define AX_PAUSE_WATERLVL_LOW 0x55 + +#define PHYSICAL_LINK_STATUS 0x02 + #define AX_USB_SS 0x04 + #define AX_USB_HS 0x02 + +#define GENERAL_STATUS 0x03 +/* Check AX88179 version. UA1:Bit2 = 0, UA2:Bit2 = 1 */ + #define AX_SECLD0x04 + +#define
Re: [PATCH, resubmit] ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver
On Thu, 7 Feb 2013 12:36:34 +0800
Freddy Xin fre...@asix.com.tw wrote:
+struct {unsigned char ctrl, timer_l, timer_h, size, ifg; }
+AX88179_BULKIN_SIZE[] = {
+ {7, 0x4f, 0,0x12, 0xff},
+ {7, 0xf0, 1,0x15, 0xff},
+ {7, 0xae, 7,0x18, 0xff},
+ {7, 0xcc, 0x4c, 0x18, 8},
+};
Better to make it static, const, and add a couple
of line breaks.
static const struct {
unsigned char ctrl, timer_l, timer_h, size, ifg;
} AX88179_BULKIN_SIZE[] = {
{7, 0x4f, 0,0x12, 0xff},
{7, 0xf0, 1,0x15, 0xff},
{7, 0xae, 7,0x18, 0xff},
{7, 0xcc, 0x4c, 0x18, 8},
};
--
To unsubscribe from this list: send the line unsubscribe 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, resubmit] ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver
On Thu, 7 Feb 2013 12:36:34 +0800
Freddy Xin fre...@asix.com.tw wrote:
+static struct ethtool_ops ax88179_ethtool_ops = {
+ .get_link = ethtool_op_get_link,
+ .get_msglevel = usbnet_get_msglevel,
+ .set_msglevel = usbnet_set_msglevel,
+ .get_wol= ax88179_get_wol,
+ .set_wol= ax88179_set_wol,
+ .get_eeprom_len = ax88179_get_eeprom_len,
+ .get_eeprom = ax88179_get_eeprom,
+ .get_settings = ax88179_get_settings,
+ .set_settings = ax88179_set_settings,
+ .nway_reset = usbnet_nway_reset,
+};
+
ethtool_ops should always be const
--
To unsubscribe from this list: send the line unsubscribe 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: [V6 PATCH 01/16] usb: phy: mv_usb2: add PHY driver for marvell usb2 controller
Hi, On Thursday 07 February 2013 07:56 AM, Chao Xie wrote: On Wed, Feb 6, 2013 at 6:35 PM, kishon kis...@ti.com wrote: Hi, On Wednesday 06 February 2013 01:48 PM, Chao Xie wrote: On Wed, Feb 6, 2013 at 4:10 PM, kishon kis...@ti.com wrote: Hi, On Wednesday 06 February 2013 12:53 PM, Chao Xie wrote: The PHY is seperated from usb controller. The usb controller used in marvell pxa168/pxa910/mmp2 are same, but PHY initialization may be different. the usb controller can support udc/otg/ehci, and for each of the mode, it need PHY to initialized before use the controller. Direclty writing the phy driver will make the usb controller driver to be simple and portable. The PHY driver will be used by marvell udc/otg/ehci. Signed-off-by: Chao Xie chao@marvell.com --- drivers/usb/phy/Kconfig |7 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/mv_usb2_phy.c| 454 ++ include/linux/platform_data/mv_usb.h |9 +- include/linux/usb/mv_usb2.h | 43 5 files changed, 511 insertions(+), 3 deletions(-) create mode 100644 drivers/usb/phy/mv_usb2_phy.c create mode 100644 include/linux/usb/mv_usb2.h diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 65217a5..5479760 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -73,3 +73,10 @@ config SAMSUNG_USBPHY help Enable this to support Samsung USB phy controller for samsung SoCs. + +config MV_USB2_PHY + tristate Marvell USB 2.0 PHY Driver + depends on USB || USB_GADGET + help + Enable this to support Marvell USB 2.0 phy driver for Marvell + SoC. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index b13faa1..3835316 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -12,3 +12,4 @@ obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o obj-$(CONFIG_USB_RCAR_PHY)+= rcar-phy.o obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o +obj-$(CONFIG_MV_USB2_PHY) += mv_usb2_phy.o diff --git a/drivers/usb/phy/mv_usb2_phy.c b/drivers/usb/phy/mv_usb2_phy.c new file mode 100644 index 000..c2bccae --- /dev/null +++ b/drivers/usb/phy/mv_usb2_phy.c @@ -0,0 +1,454 @@ +/* + * Copyright (C) 2010 Google, Inc. + * + * Author: + * Chao Xie xiechao.m...@gmail.com + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * 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/resource.h +#include linux/delay.h +#include linux/slab.h +#include linux/of.h +#include linux/of_device.h +#include linux/io.h +#include linux/err.h +#include linux/clk.h +#include linux/export.h +#include linux/module.h +#include linux/platform_device.h +#include linux/platform_data/mv_usb.h +#include linux/usb/mv_usb2.h + +/* phy regs */ +#define UTMI_REVISION 0x0 +#define UTMI_CTRL 0x4 +#define UTMI_PLL 0x8 +#define UTMI_TX0xc +#define UTMI_RX0x10 +#define UTMI_IVREF 0x14 +#define UTMI_T00x18 +#define UTMI_T10x1c +#define UTMI_T20x20 +#define UTMI_T30x24 +#define UTMI_T40x28 +#define UTMI_T50x2c +#define UTMI_RESERVE 0x30 +#define UTMI_USB_INT 0x34 +#define UTMI_DBG_CTL 0x38 +#define UTMI_OTG_ADDON 0x3c + +/* For UTMICTRL Register */ +#define UTMI_CTRL_USB_CLK_EN(1 31) +/* pxa168 */ +#define UTMI_CTRL_SUSPEND_SET1 (1 30) +#define UTMI_CTRL_SUSPEND_SET2 (1 29) +#define UTMI_CTRL_RXBUF_PDWN(1 24) +#define UTMI_CTRL_TXBUF_PDWN(1 11) + +#define UTMI_CTRL_INPKT_DELAY_SHIFT 30 +#define UTMI_CTRL_INPKT_DELAY_SOF_SHIFT28 +#define UTMI_CTRL_PU_REF_SHIFT 20 +#define UTMI_CTRL_ARC_PULLDN_SHIFT 12 +#define UTMI_CTRL_PLL_PWR_UP_SHIFT 1 +#define UTMI_CTRL_PWR_UP_SHIFT 0 + +/* For UTMI_PLL Register */ +#define UTMI_PLL_PLLCALI12_SHIFT 29 +#define UTMI_PLL_PLLCALI12_MASK(0x3 29) + +#define UTMI_PLL_PLLVDD18_SHIFT27 +#define UTMI_PLL_PLLVDD18_MASK (0x3 27) + +#define UTMI_PLL_PLLVDD12_SHIFT25 +#define UTMI_PLL_PLLVDD12_MASK (0x3 25)
Re: [PATCH 3/8] ARM: dts: omap: Add usb_otg and glue data
[]...
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..4688265 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -15,6 +15,7 @@ OMAP MUSB GLUE
represents PERIPHERAL.
- power : Should be 50. This signifies the controller can supply upto
100mA when operating in host mode.
+ - usb-phy : the phandle for the PHY device
SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
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..b6472f7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,17 @@
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;
+ usb-phy = usb2_phy;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
Where are these bindings documented? The general convention is to use
a '-' for property names and not '_'
+ };
};
};
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 c829d7e..5171739 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -542,5 +542,18 @@
reg-names = control_dev_conf, otghs_control;
ti,type = 1;
};
+
+ 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;
+ usb-phy = usb2_phy;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ ti,has-mailbox;
+ };
};
};
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index ed0bc95..398d2c3 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -67,7 +67,7 @@
#interrupt-cells = 1;
};
- twl4030-usb {
+ usb2_phy: twl4030-usb {
compatible = ti,twl4030-usb;
interrupts = 10, 4;
usb1v5-supply = vusb1v5;
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] ARM: dts: omap: Add usb_otg and glue data
Hi,
On Thursday 07 February 2013 11:51 AM, Rajendra Nayak wrote:
[]...
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..4688265 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -15,6 +15,7 @@ OMAP MUSB GLUE
represents PERIPHERAL.
- power : Should be 50. This signifies the controller can supply
upto
100mA when operating in host mode.
+ - usb-phy : the phandle for the PHY device
SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
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..b6472f7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,17 @@
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;
+usb-phy = usb2_phy;
+multipoint = 1;
+num_eps = 16;
+ram_bits = 12;
Where are these bindings documented? The general convention is to use
a '-' for property names and not '_'
It's documented in Documentation/devicetree/bindings/usb/omap-usb.txt
Actually the documentation and the drivers got merged with this binding
long back.
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, resubmit] ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver
On 02/07/2013 01:46 PM, Stephen Hemminger wrote:
On Thu, 7 Feb 2013 12:36:34 +0800
Freddy Xin fre...@asix.com.tw wrote:
+static struct ethtool_ops ax88179_ethtool_ops = {
+ .get_link = ethtool_op_get_link,
+ .get_msglevel = usbnet_get_msglevel,
+ .set_msglevel = usbnet_set_msglevel,
+ .get_wol= ax88179_get_wol,
+ .set_wol= ax88179_set_wol,
+ .get_eeprom_len = ax88179_get_eeprom_len,
+ .get_eeprom = ax88179_get_eeprom,
+ .get_settings = ax88179_get_settings,
+ .set_settings = ax88179_set_settings,
+ .nway_reset = usbnet_nway_reset,
+};
+
ethtool_ops should always be const
Thank you, Stephen. I will fix these errors.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1]linux-usb: fix the idProduct value to be compatible with current CPU in initializers.c
From: fangxiaozhi huana...@huawei.com
1. The idProduct is little endian, so make sure its value to be compatible with
the current CPU. Make no break on big endian processors.
Signed-off-by: fangxiaozhi huana...@huawei.com
diff -uprN linux-3.8-rc6_orig/drivers/usb/storage/initializers.c
linux-3.8-rc6/drivers/usb/storage/initializers.c
--- linux-3.8-rc6_orig/drivers/usb/storage/initializers.c 2013-02-06
14:48:51.564355283 +0800
+++ linux-3.8-rc6/drivers/usb/storage/initializers.c2013-02-07
15:29:59.929482630 +0800
@@ -147,7 +147,7 @@ static int usb_stor_huawei_dongles_pid(s
int idProduct;
idesc = us-pusb_intf-cur_altsetting-desc;
- idProduct = us-pusb_dev-descriptor.idProduct;
+ idProduct = le16_to_cpu(us-pusb_dev-descriptor.idProduct);
/* The first port is CDROM,
* means the dongle in the single port mode,
* and a switch command is required to be sent. */
@@ -169,7 +169,7 @@ int usb_stor_huawei_init(struct us_data
int result = 0;
if (usb_stor_huawei_dongles_pid(us)) {
- if (us-pusb_dev-descriptor.idProduct = 0x1446)
+ if (le16_to_cpu(us-pusb_dev-descriptor.idProduct) = 0x1446)
result = usb_stor_huawei_scsi_init(us);
else
result = usb_stor_huawei_feature_init(us);
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
