[PATCH v2 2/4] usb: otg: twl4030: use devres API for regulator get and request irq
Used devres APIs devm_request_threaded_irq and devm_regulator_get for
requesting irq and for getting regulator respectively.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/otg/twl4030-usb.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 04b732e2..5b20bb4 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -470,7 +470,7 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
/* Initialize 3.1V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB3V1_DEV_GRP);
- twl->usb3v1 = regulator_get(twl->dev, "usb3v1");
+ twl->usb3v1 = devm_regulator_get(twl->dev, "usb3v1");
if (IS_ERR(twl->usb3v1))
return -ENODEV;
@@ -479,18 +479,18 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
/* Initialize 1.5V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V5_DEV_GRP);
- twl->usb1v5 = regulator_get(twl->dev, "usb1v5");
+ twl->usb1v5 = devm_regulator_get(twl->dev, "usb1v5");
if (IS_ERR(twl->usb1v5))
- goto fail1;
+ return -ENODEV;
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V5_TYPE);
/* Initialize 1.8V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V8_DEV_GRP);
- twl->usb1v8 = regulator_get(twl->dev, "usb1v8");
+ twl->usb1v8 = devm_regulator_get(twl->dev, "usb1v8");
if (IS_ERR(twl->usb1v8))
- goto fail2;
+ return -ENODEV;
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V8_TYPE);
@@ -499,14 +499,6 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
TWL4030_PM_MASTER_PROTECT_KEY);
return 0;
-
-fail2:
- regulator_put(twl->usb1v5);
- twl->usb1v5 = NULL;
-fail1:
- regulator_put(twl->usb3v1);
- twl->usb3v1 = NULL;
- return -ENODEV;
}
static ssize_t twl4030_usb_vbus_show(struct device *dev,
@@ -695,9 +687,9 @@ static int twl4030_usb_probe(struct platform_device *pdev)
* need both handles, otherwise just one suffices.
*/
twl->irq_enabled = true;
- status = request_threaded_irq(twl->irq, NULL, twl4030_usb_irq,
- IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING |
- IRQF_ONESHOT, "twl4030_usb", twl);
+ status = devm_request_threaded_irq(twl->dev, twl->irq, NULL,
+ twl4030_usb_irq, IRQF_TRIGGER_FALLING |
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT, "twl4030_usb", twl);
if (status < 0) {
dev_dbg(&pdev->dev, "can't get IRQ %d, err %d\n",
twl->irq, status);
@@ -716,7 +708,6 @@ static int __exit twl4030_usb_remove(struct platform_device
*pdev)
int val;
cancel_delayed_work(&twl->id_workaround_work);
- free_irq(twl->irq, twl);
device_remove_file(twl->dev, &dev_attr_vbus);
/* set transceiver mode to power on defaults */
@@ -738,9 +729,6 @@ static int __exit twl4030_usb_remove(struct platform_device
*pdev)
if (!twl->asleep)
twl4030_phy_power(twl, 0);
- regulator_put(twl->usb1v5);
- regulator_put(twl->usb1v8);
- regulator_put(twl->usb3v1);
return 0;
}
--
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/4] usb: otg: twl4030: fix cold plug on OMAP3
Having twl4030_usb_phy_init() (detects if a cable is connected before
twl4030 is probed) in twl4030 probe makes cable connect events to be
missed by musb glue, since it gets loaded after twl4030. Having
twl4030_usb_phy_init as a usb_phy ops lets twl4030_usb_phy_init to be
called when glue is ready.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/otg/twl4030-usb.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 5b20bb4..4040124 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -565,8 +565,9 @@ static void twl4030_id_workaround_work(struct work_struct
*work)
}
}
-static void twl4030_usb_phy_init(struct twl4030_usb *twl)
+static int twl4030_usb_phy_init(struct usb_phy *phy)
{
+ struct twl4030_usb *twl = phy_to_twl(phy);
enum omap_musb_vbus_id_status status;
/*
@@ -581,6 +582,7 @@ static void twl4030_usb_phy_init(struct twl4030_usb *twl)
omap_musb_mailbox(twl->linkstat);
sysfs_notify(&twl->dev->kobj, NULL, "vbus");
+ return 0;
}
static int twl4030_set_suspend(struct usb_phy *x, int suspend)
@@ -657,6 +659,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl->phy.otg= otg;
twl->phy.type = USB_PHY_TYPE_USB2;
twl->phy.set_suspend= twl4030_set_suspend;
+ twl->phy.init = twl4030_usb_phy_init;
otg->phy= &twl->phy;
otg->set_host = twl4030_set_host;
@@ -696,8 +699,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
return status;
}
- twl4030_usb_phy_init(twl);
-
dev_info(&pdev->dev, "Initialized TWL4030 USB module\n");
return 0;
}
--
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 3/4] usb: musb: omap: add usb_phy_init in omap2430_musb_init
Some PHYs load too early (twl4030) making omap glue to miss cable connect events if the board is booted with cable connected. So adding usb_phy_init in omap2430_musb_init lets PHYs to report events once glue is ready. Signed-off-by: Kishon Vijay Abraham I --- drivers/usb/musb/omap2430.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 6071484..8876741 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -391,6 +391,8 @@ static int omap2430_musb_init(struct musb *musb) if (glue->status != OMAP_MUSB_UNKNOWN) omap_musb_set_mailbox(glue); + usb_phy_init(musb->xceiv); + pm_runtime_put_noidle(musb->controller); return 0; -- 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 1/4] usb: musb: omap: remove the check before calling otg_set_vbus
No functional change. otg_set_vbus is already protected so removed the
check before calling otg_set_vbus.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/musb/omap2430.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 29014c0..6071484 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -174,8 +174,7 @@ static void omap2430_musb_set_vbus(struct musb *musb, int
is_on)
}
}
- if (otg->set_vbus)
- otg_set_vbus(otg, 1);
+ otg_set_vbus(otg, 1);
} else {
musb->is_active = 1;
otg->default_a = 1;
@@ -297,10 +296,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
}
omap2430_musb_set_vbus(musb, 0);
- if (data->interface_type == MUSB_INTERFACE_UTMI) {
- if (musb->xceiv->otg->set_vbus)
- otg_set_vbus(musb->xceiv->otg, 0);
- }
+ if (data->interface_type == MUSB_INTERFACE_UTMI)
+ otg_set_vbus(musb->xceiv->otg, 0);
omap_control_usb_set_mode(glue->control_otghs,
USB_MODE_DISCONNECT);
break;
--
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/4] usb: musb/otg: cleanup and fixes
This series has some misc cleanup and fixes. The fix solves the cold plug issue in omap3 which some have reported. Developed these patches on fixes-for-v3.9-rc3 after applying http://www.spinics.net/lists/linux-usb/msg81563.html (Grazvydas Ignotas patch series) Tested for g_zero enumeration in pandaboard and beagleboard in both cold plug and hot plug case. Any kind of testing for this series is welcome. Changes from v1: * removed *usb: musb: omap: remove the check before calling otg_set_vbus* a similar patch is already merged. Kishon Vijay Abraham I (4): usb: musb: omap: remove the check before calling otg_set_vbus usb: otg: twl4030: use devres API for regulator get and request irq usb: musb: omap: add usb_phy_init in omap2430_musb_init usb: otg: twl4030: fix cold plug on OMAP3 drivers/usb/musb/omap2430.c | 11 +-- drivers/usb/otg/twl4030-usb.c | 35 --- 2 files changed, 17 insertions(+), 29 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
[PATCH 14/14] usb: udc-core: add judgement logic for usb_gadget_connect
- If there is no vbus control to indicate connection.
and disconnect, we can pullup dp when we load gadget module.
- If we have vbus control logic, the dp is better pull up
when there is a vbus session.
Signed-off-by: Peter Chen
---
drivers/usb/gadget/udc-core.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
index 4d90bdf..4b56f7c 100644
--- a/drivers/usb/gadget/udc-core.c
+++ b/drivers/usb/gadget/udc-core.c
@@ -278,7 +278,10 @@ static int udc_bind_to_driver(struct usb_udc *udc, struct
usb_gadget_driver *dri
driver->unbind(gadget);
goto err1;
}
- usb_gadget_connect(gadget);
+ if (!gadget->ops->vbus_session ||
+ (gadget->ops->vbus_session
+ && gadget->vbus_active))
+ usb_gadget_connect(gadget);
kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE);
return 0;
@@ -384,7 +387,10 @@ static ssize_t usb_udc_softconn_store(struct device *dev,
if (sysfs_streq(buf, "connect")) {
usb_gadget_udc_start(gadget, udc->driver);
- usb_gadget_connect(gadget);
+ if (!gadget->ops->vbus_session ||
+ (gadget->ops->vbus_session
+ && gadget->vbus_active))
+ usb_gadget_connect(gadget);
} else if (sysfs_streq(buf, "disconnect")) {
usb_gadget_disconnect(gadget);
usb_gadget_udc_stop(gadget, udc->driver);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/14] usb: udc-core: small cleanup for udc->gadget
:s/udc->gadget/gadget
Signed-off-by: Peter Chen
---
drivers/usb/gadget/udc-core.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
index 2a9cd36..4d90bdf 100644
--- a/drivers/usb/gadget/udc-core.c
+++ b/drivers/usb/gadget/udc-core.c
@@ -262,6 +262,7 @@ EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
static int udc_bind_to_driver(struct usb_udc *udc, struct usb_gadget_driver
*driver)
{
int ret;
+ struct usb_gadget *gadget = udc->gadget;
dev_dbg(&udc->dev, "registering UDC driver [%s]\n",
driver->function);
@@ -269,15 +270,15 @@ static int udc_bind_to_driver(struct usb_udc *udc, struct
usb_gadget_driver *dri
udc->driver = driver;
udc->dev.driver = &driver->driver;
- ret = driver->bind(udc->gadget, driver);
+ ret = driver->bind(gadget, driver);
if (ret)
goto err1;
- ret = usb_gadget_udc_start(udc->gadget, driver);
+ ret = usb_gadget_udc_start(gadget, driver);
if (ret) {
- driver->unbind(udc->gadget);
+ driver->unbind(gadget);
goto err1;
}
- usb_gadget_connect(udc->gadget);
+ usb_gadget_connect(gadget);
kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE);
return 0;
@@ -379,13 +380,14 @@ static ssize_t usb_udc_softconn_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t n)
{
struct usb_udc *udc = container_of(dev, struct usb_udc, dev);
+ struct usb_gadget *gadget = udc->gadget;
if (sysfs_streq(buf, "connect")) {
- usb_gadget_udc_start(udc->gadget, udc->driver);
- usb_gadget_connect(udc->gadget);
+ usb_gadget_udc_start(gadget, udc->driver);
+ usb_gadget_connect(gadget);
} else if (sysfs_streq(buf, "disconnect")) {
- usb_gadget_disconnect(udc->gadget);
- usb_gadget_udc_stop(udc->gadget, udc->driver);
+ usb_gadget_disconnect(gadget);
+ usb_gadget_udc_stop(gadget, udc->driver);
} else {
dev_err(dev, "unsupported command '%s'\n", buf);
return -EINVAL;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/14] usb: s3c2410_udc: using common vbus_active
Using common vbus_active to indicate vbus status
CC: Ben Dooks
Signed-off-by: Peter Chen
---
drivers/usb/gadget/s3c2410_udc.c |6 +++---
drivers/usb/gadget/s3c2410_udc.h |1 -
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/s3c2410_udc.c b/drivers/usb/gadget/s3c2410_udc.c
index fc07b43..ae7a7e3 100644
--- a/drivers/usb/gadget/s3c2410_udc.c
+++ b/drivers/usb/gadget/s3c2410_udc.c
@@ -1494,7 +1494,7 @@ static int s3c2410_udc_vbus_session(struct usb_gadget
*gadget, int is_active)
dprintk(DEBUG_NORMAL, "%s()\n", __func__);
- udc->vbus = (is_active != 0);
+ gadget->vbus_active = (is_active != 0);
s3c2410_udc_set_pullup(udc, is_active);
return 0;
}
@@ -1520,7 +1520,7 @@ static irqreturn_t s3c2410_udc_vbus_irq(int irq, void
*_dev)
if (udc_info->vbus_pin_inverted)
value = !value;
- if (value != dev->vbus)
+ if (value != &dev->gadget.vbus)
s3c2410_udc_vbus_session(&dev->gadget, value);
return IRQ_HANDLED;
@@ -1887,7 +1887,7 @@ static int s3c2410_udc_probe(struct platform_device *pdev)
dev_dbg(dev, "got irq %i\n", irq);
} else {
- udc->vbus = 1;
+ udc->gadget.vbus = 1;
}
if (udc_info && !udc_info->udc_command &&
diff --git a/drivers/usb/gadget/s3c2410_udc.h b/drivers/usb/gadget/s3c2410_udc.h
index 93bf225..ca5ad98 100644
--- a/drivers/usb/gadget/s3c2410_udc.h
+++ b/drivers/usb/gadget/s3c2410_udc.h
@@ -92,7 +92,6 @@ struct s3c2410_udc {
unsignedreq_std : 1;
unsignedreq_config : 1;
unsignedreq_pending : 1;
- u8 vbus;
struct dentry *regs_info;
};
#define to_s3c2410(g) (container_of((g), struct s3c2410_udc, gadget))
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/14] usb: pxa27x_udc: using common vbus_active
Using common vbus_active to indicate vbus status
CC: Eric Miao
Signed-off-by: Peter Chen
---
drivers/usb/gadget/pxa27x_udc.c |8
drivers/usb/gadget/pxa27x_udc.h |1 -
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/pxa27x_udc.c b/drivers/usb/gadget/pxa27x_udc.c
index f7d2579..de997c5 100644
--- a/drivers/usb/gadget/pxa27x_udc.c
+++ b/drivers/usb/gadget/pxa27x_udc.c
@@ -1574,7 +1574,7 @@ static int should_enable_udc(struct pxa_udc *udc)
int put_on;
put_on = ((udc->pullup_on) && (udc->driver));
- put_on &= ((udc->vbus_sensed) || (IS_ERR_OR_NULL(udc->transceiver)));
+ put_on &= ((udc->gadget.vbus_active) ||
(IS_ERR_OR_NULL(udc->transceiver)));
return put_on;
}
@@ -1595,7 +1595,7 @@ static int should_disable_udc(struct pxa_udc *udc)
int put_off;
put_off = ((!udc->pullup_on) || (!udc->driver));
- put_off |= ((!udc->vbus_sensed) && (!IS_ERR_OR_NULL(udc->transceiver)));
+ put_off |= ((!udc->gadget.vbus_active) &&
(!IS_ERR_OR_NULL(udc->transceiver)));
return put_off;
}
@@ -1640,7 +1640,7 @@ static int pxa_udc_vbus_session(struct usb_gadget
*_gadget, int is_active)
{
struct pxa_udc *udc = to_gadget_udc(_gadget);
- udc->vbus_sensed = is_active;
+ _gadget->vbus_active = is_active;
if (should_enable_udc(udc))
udc_enable(udc);
if (should_disable_udc(udc))
@@ -2465,7 +2465,7 @@ static int __init pxa_udc_probe(struct platform_device
*pdev)
device_initialize(&udc->gadget.dev);
udc->gadget.dev.parent = &pdev->dev;
udc->gadget.dev.dma_mask = NULL;
- udc->vbus_sensed = 0;
+ udc->gadget.vbus_active = 0;
the_controller = udc;
platform_set_drvdata(pdev, udc);
diff --git a/drivers/usb/gadget/pxa27x_udc.h b/drivers/usb/gadget/pxa27x_udc.h
index 28f2b53..184bf45 100644
--- a/drivers/usb/gadget/pxa27x_udc.h
+++ b/drivers/usb/gadget/pxa27x_udc.h
@@ -458,7 +458,6 @@ struct pxa_udc {
unsignedenabled:1;
unsignedpullup_on:1;
unsignedpullup_resume:1;
- unsignedvbus_sensed:1;
unsignedconfig:2;
unsignedlast_interface:3;
unsignedlast_alternate:3;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/14] usb: udc-core: introduce vbus_active for struct usb_gadget
If there is an vbus session event for udc driver, let the
udc core know vbus's status.
Signed-off-by: Peter Chen
---
include/linux/usb/gadget.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 2e297e8..7e373a2 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -531,6 +531,7 @@ struct usb_gadget {
unsignedb_hnp_enable:1;
unsigneda_hnp_support:1;
unsigneda_alt_hnp_support:1;
+ unsignedvbus_active:1;
const char *name;
struct device dev;
unsignedout_epnum;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/14] usb: pxa25x_udc: using common vbus_active
Using common vbus_active to indicate vbus status
CC: Eric Miao
Signed-off-by: Peter Chen
---
drivers/usb/gadget/pxa25x_udc.c |6 +++---
drivers/usb/gadget/pxa25x_udc.h |1 -
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/pxa25x_udc.c b/drivers/usb/gadget/pxa25x_udc.c
index 2bbcdce..1007546 100644
--- a/drivers/usb/gadget/pxa25x_udc.c
+++ b/drivers/usb/gadget/pxa25x_udc.c
@@ -926,7 +926,7 @@ static void udc_disable(struct pxa25x_udc *);
*/
static int pullup(struct pxa25x_udc *udc)
{
- int is_active = udc->vbus && udc->pullup && !udc->suspended;
+ int is_active = udc->gadget.vbus_active && udc->pullup &&
!udc->suspended;
DMSG("%s\n", is_active ? "active" : "inactive");
if (is_active) {
if (!udc->active) {
@@ -959,7 +959,7 @@ static int pxa25x_udc_vbus_session(struct usb_gadget
*_gadget, int is_active)
struct pxa25x_udc *udc;
udc = container_of(_gadget, struct pxa25x_udc, gadget);
- udc->vbus = is_active;
+ udc->gadget.vbus_active = is_active;
DMSG("vbus %s\n", is_active ? "supplied" : "inactive");
pullup(udc);
return 0;
@@ -2152,7 +2152,7 @@ static int __init pxa25x_udc_probe(struct platform_device
*pdev)
udc_disable(dev);
udc_reinit(dev);
- dev->vbus = 0;
+ dev->gadget.vbus_active = 0;
/* irq setup after old hardware state is cleaned up */
retval = request_irq(irq, pxa25x_udc_irq,
diff --git a/drivers/usb/gadget/pxa25x_udc.h b/drivers/usb/gadget/pxa25x_udc.h
index 3fe5931..3039992 100644
--- a/drivers/usb/gadget/pxa25x_udc.h
+++ b/drivers/usb/gadget/pxa25x_udc.h
@@ -103,7 +103,6 @@ struct pxa25x_udc {
enum ep0_state ep0state;
struct udc_statsstats;
unsignedgot_irq : 1,
- vbus : 1,
pullup : 1,
has_cfr : 1,
req_pending : 1,
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/14] usb: pch_udc: using common vbus_active
Using common vbus_active to indicate vbus status
CC: Felipe Balbi
Signed-off-by: Peter Chen
---
drivers/usb/gadget/pch_udc.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/pch_udc.c b/drivers/usb/gadget/pch_udc.c
index a787a8e..f49d0d2 100644
--- a/drivers/usb/gadget/pch_udc.c
+++ b/drivers/usb/gadget/pch_udc.c
@@ -333,7 +333,6 @@ struct pch_vbus_gpio_data {
* @registered:driver regsitered with system
* @suspended: driver in suspended state
* @connected: gadget driver associated
- * @vbus_session: required vbus_session state
* @set_cfg_not_acked: pending acknowledgement 4 setup
* @waiting_zlp_ack: pending acknowledgement 4 ZLP
* @data_requests: DMA pool for data requests
@@ -361,7 +360,6 @@ struct pch_udc_dev {
registered:1,
suspended:1,
connected:1,
- vbus_session:1,
set_cfg_not_acked:1,
waiting_zlp_ack:1;
struct pci_pool *data_requests;
@@ -614,7 +612,7 @@ static inline void pch_udc_vbus_session(struct pch_udc_dev
*dev,
{
if (is_active) {
pch_udc_reconnect(dev);
- dev->vbus_session = 1;
+ dev->gadget.vbus_active = 1;
} else {
if (dev->driver && dev->driver->disconnect) {
spin_unlock(&dev->lock);
@@ -622,7 +620,7 @@ static inline void pch_udc_vbus_session(struct pch_udc_dev
*dev,
spin_lock(&dev->lock);
}
pch_udc_set_disconnect(dev);
- dev->vbus_session = 0;
+ dev->gadget.vbus_active = 0;
}
}
@@ -2745,7 +2743,7 @@ static void pch_udc_dev_isr(struct pch_udc_dev *dev, u32
dev_intr)
}
vbus = pch_vbus_gpio_get_value(dev);
- if ((dev->vbus_session == 0)
+ if ((dev->gadget.vbus_active == 0)
&& (vbus != 1)) {
if (dev->driver && dev->driver->disconnect) {
spin_unlock(&dev->lock);
@@ -2753,7 +2751,7 @@ static void pch_udc_dev_isr(struct pch_udc_dev *dev, u32
dev_intr)
spin_lock(&dev->lock);
}
pch_udc_reconnect(dev);
- } else if ((dev->vbus_session == 0)
+ } else if ((dev->gadget.vbus_active == 0)
&& (vbus == 1)
&& !dev->vbus_gpio.intr)
schedule_work(&dev->vbus_gpio.irq_work_fall);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/14] usb: mv_udc: using common vbus_active
Using common vbus_active to indicate vbus status
CC: Chao Xie
Signed-off-by: Peter Chen
---
drivers/usb/gadget/mv_udc.h |1 -
drivers/usb/gadget/mv_udc_core.c | 14 +++---
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/mv_udc.h b/drivers/usb/gadget/mv_udc.h
index 9073436..6d848b4 100644
--- a/drivers/usb/gadget/mv_udc.h
+++ b/drivers/usb/gadget/mv_udc.h
@@ -206,7 +206,6 @@ struct mv_udc {
int errors;
unsignedsoftconnect:1,
- vbus_active:1,
remote_wakeup:1,
softconnected:1,
force_fs:1,
diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c
index c8cf959..91a1b0d 100644
--- a/drivers/usb/gadget/mv_udc_core.c
+++ b/drivers/usb/gadget/mv_udc_core.c
@@ -1204,12 +1204,12 @@ static int mv_udc_vbus_session(struct usb_gadget
*gadget, int is_active)
udc = container_of(gadget, struct mv_udc, gadget);
spin_lock_irqsave(&udc->lock, flags);
- udc->vbus_active = (is_active != 0);
+ gadget->vbus_active = (is_active != 0);
dev_dbg(&udc->dev->dev, "%s: softconnect %d, vbus_active %d\n",
- __func__, udc->softconnect, udc->vbus_active);
+ __func__, udc->softconnect, gadget->vbus_active);
- if (udc->driver && udc->softconnect && udc->vbus_active) {
+ if (udc->driver && udc->softconnect && gadget->vbus_active) {
retval = mv_udc_enable(udc);
if (retval == 0) {
/* Clock is disabled, need re-init registers */
@@ -1244,9 +1244,9 @@ static int mv_udc_pullup(struct usb_gadget *gadget, int
is_on)
udc->softconnect = (is_on != 0);
dev_dbg(&udc->dev->dev, "%s: softconnect %d, vbus_active %d\n",
- __func__, udc->softconnect, udc->vbus_active);
+ __func__, udc->softconnect, gadget->vbus_active);
- if (udc->driver && udc->softconnect && udc->vbus_active) {
+ if (udc->driver && udc->softconnect && gadget->vbus_active) {
retval = mv_udc_enable(udc);
if (retval == 0) {
/* Clock is disabled, need re-init registers */
@@ -1254,7 +1254,7 @@ static int mv_udc_pullup(struct usb_gadget *gadget, int
is_on)
ep0_reset(udc);
udc_start(udc);
}
- } else if (udc->driver && udc->vbus_active) {
+ } else if (udc->driver && gadget->vbus_active) {
/* stop all the transfer in queue*/
stop_activity(udc, udc->driver);
udc_stop(udc);
@@ -2356,7 +2356,7 @@ static int mv_udc_probe(struct platform_device *pdev)
if (udc->clock_gating)
mv_udc_disable_internal(udc);
else
- udc->vbus_active = 1;
+ udc->gadget.vbus_active = 1;
retval = usb_add_gadget_udc(&pdev->dev, &udc->gadget);
if (retval)
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/14] usb: omap_udc: using common vbus_active
Using common vbus_active to indicate vbus status
CC: Felipe Balbi
Signed-off-by: Peter Chen
---
drivers/usb/gadget/omap_udc.c |4 ++--
drivers/usb/gadget/omap_udc.h |1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/omap_udc.c b/drivers/usb/gadget/omap_udc.c
index 06be85c..2d0cf7f 100644
--- a/drivers/usb/gadget/omap_udc.c
+++ b/drivers/usb/gadget/omap_udc.c
@@ -1186,7 +1186,7 @@ omap_set_selfpowered(struct usb_gadget *gadget, int
is_selfpowered)
static int can_pullup(struct omap_udc *udc)
{
- return udc->driver && udc->softconnect && udc->vbus_active;
+ return udc->driver && udc->softconnect && udc->gadget.vbus_active;
}
static void pullup_enable(struct omap_udc *udc)
@@ -1253,7 +1253,7 @@ static int omap_vbus_session(struct usb_gadget *gadget,
int is_active)
udc = container_of(gadget, struct omap_udc, gadget);
spin_lock_irqsave(&udc->lock, flags);
VDBG("VBUS %s\n", is_active ? "on" : "off");
- udc->vbus_active = (is_active != 0);
+ gadget->vbus_active = (is_active != 0);
if (cpu_is_omap15xx()) {
/* "software" detect, ignored if !VBUS_MODE_1510 */
l = omap_readl(FUNC_MUX_CTRL_0);
diff --git a/drivers/usb/gadget/omap_udc.h b/drivers/usb/gadget/omap_udc.h
index cfadeb5..62cdb9d 100644
--- a/drivers/usb/gadget/omap_udc.h
+++ b/drivers/usb/gadget/omap_udc.h
@@ -166,7 +166,6 @@ struct omap_udc {
struct usb_phy *transceiver;
struct list_headiso;
unsignedsoftconnect:1;
- unsignedvbus_active:1;
unsignedep0_pending:1;
unsignedep0_in:1;
unsignedep0_set_config:1;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/14] usb: lpc32xx_udc: using common vbus_active
Using common vbus_active to indicate vbus status
CC: Felipe Balbi
Signed-off-by: Peter Chen
---
drivers/usb/gadget/lpc32xx_udc.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/gadget/lpc32xx_udc.c b/drivers/usb/gadget/lpc32xx_udc.c
index aa04089..13270a9 100644
--- a/drivers/usb/gadget/lpc32xx_udc.c
+++ b/drivers/usb/gadget/lpc32xx_udc.c
@@ -2550,6 +2550,7 @@ static int lpc32xx_vbus_session(struct usb_gadget
*gadget, int is_active)
spin_lock_irqsave(&udc->lock, flags);
+ gadget->vbus_active = is_active;
/* Doesn't need lock */
if (udc->driver) {
udc_clk_set(udc, 1);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/14] usb: mv_u3d_core: using common vbus_active
Using common vbus_active to indicate vbus status
CC: Yu Xu
Signed-off-by: Peter Chen
---
drivers/usb/gadget/mv_u3d.h |1 -
drivers/usb/gadget/mv_u3d_core.c | 14 +++---
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/mv_u3d.h b/drivers/usb/gadget/mv_u3d.h
index e32a787..16a6955 100644
--- a/drivers/usb/gadget/mv_u3d.h
+++ b/drivers/usb/gadget/mv_u3d.h
@@ -274,7 +274,6 @@ struct mv_u3d {
unsigned interrors;
unsignedsoftconnect:1;
- unsignedvbus_active:1; /* vbus is active or not */
unsignedremote_wakeup:1; /* support remote wakeup */
unsignedclock_gating:1; /* clock gating or not */
unsignedactive:1; /* udc is active or not */
diff --git a/drivers/usb/gadget/mv_u3d_core.c b/drivers/usb/gadget/mv_u3d_core.c
index b5cea27..95236db 100644
--- a/drivers/usb/gadget/mv_u3d_core.c
+++ b/drivers/usb/gadget/mv_u3d_core.c
@@ -1159,15 +1159,15 @@ static int mv_u3d_vbus_session(struct usb_gadget
*gadget, int is_active)
spin_lock_irqsave(&u3d->lock, flags);
- u3d->vbus_active = (is_active != 0);
+ u3d->gadget.vbus_active = (is_active != 0);
dev_dbg(u3d->dev, "%s: softconnect %d, vbus_active %d\n",
- __func__, u3d->softconnect, u3d->vbus_active);
+ __func__, u3d->softconnect, u3d->gadget.vbus_active);
/*
* 1. external VBUS detect: we can disable/enable clock on demand.
* 2. UDC VBUS detect: we have to enable clock all the time.
* 3. No VBUS detect: we have to enable clock all the time.
*/
- if (u3d->driver && u3d->softconnect && u3d->vbus_active) {
+ if (u3d->driver && u3d->softconnect && u3d->gadget.vbus_active) {
retval = mv_u3d_enable(u3d);
if (retval == 0) {
/*
@@ -1218,9 +1218,9 @@ static int mv_u3d_pullup(struct usb_gadget *gadget, int
is_on)
spin_lock_irqsave(&u3d->lock, flags);
dev_dbg(u3d->dev, "%s: softconnect %d, vbus_active %d\n",
- __func__, u3d->softconnect, u3d->vbus_active);
+ __func__, u3d->softconnect, u3d->gadget.vbus_active);
u3d->softconnect = (is_on != 0);
- if (u3d->driver && u3d->softconnect && u3d->vbus_active) {
+ if (u3d->driver && u3d->softconnect && u3d->gadget.vbus_active) {
retval = mv_u3d_enable(u3d);
if (retval == 0) {
/*
@@ -1231,7 +1231,7 @@ static int mv_u3d_pullup(struct usb_gadget *gadget, int
is_on)
mv_u3d_ep0_reset(u3d);
mv_u3d_controller_start(u3d);
}
- } else if (u3d->driver && u3d->vbus_active) {
+ } else if (u3d->driver && u3d->gadget.vbus_active) {
/* stop all the transfer in queue*/
mv_u3d_stop_activity(u3d, u3d->driver);
mv_u3d_controller_stop(u3d);
@@ -1976,7 +1976,7 @@ static int mv_u3d_probe(struct platform_device *dev)
}
if (!u3d->clock_gating)
- u3d->vbus_active = 1;
+ u3d->gadget.vbus_active = 1;
/* enable usb3 controller vbus detection */
u3d->vbus_valid_detect = 1;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/14] usb: fsl_udc_core: using common vbus_active
Using common vbus_active to indicate vbus status
CC: Li Yang
Signed-off-by: Peter Chen
---
drivers/usb/gadget/fsl_udc_core.c |4 ++--
drivers/usb/gadget/fsl_usb2_udc.h |1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index 04d5fef..c343bbf 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -1195,7 +1195,7 @@ static int fsl_wakeup(struct usb_gadget *gadget)
static int can_pullup(struct fsl_udc *udc)
{
- return udc->driver && udc->softconnect && udc->vbus_active;
+ return udc->driver && udc->softconnect && udc->gadget.vbus_active;
}
/* Notify controller that VBUS is powered, Called by whatever
@@ -1208,7 +1208,7 @@ static int fsl_vbus_session(struct usb_gadget *gadget,
int is_active)
udc = container_of(gadget, struct fsl_udc, gadget);
spin_lock_irqsave(&udc->lock, flags);
VDBG("VBUS %s", is_active ? "on" : "off");
- udc->vbus_active = (is_active != 0);
+ udc->gadget.vbus_active = (is_active != 0);
if (can_pullup(udc))
fsl_writel((fsl_readl(&dr_regs->usbcmd) | USB_CMD_RUN_STOP),
&dr_regs->usbcmd);
diff --git a/drivers/usb/gadget/fsl_usb2_udc.h
b/drivers/usb/gadget/fsl_usb2_udc.h
index c6703bb..f17ce58 100644
--- a/drivers/usb/gadget/fsl_usb2_udc.h
+++ b/drivers/usb/gadget/fsl_usb2_udc.h
@@ -483,7 +483,6 @@ struct fsl_udc {
spinlock_t lock;
struct usb_phy *transceiver;
unsigned softconnect:1;
- unsigned vbus_active:1;
unsigned stopped:1;
unsigned remote_wakeup:1;
unsigned already_stopped:1;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/14] usb: at91_udc: using common vbus_active
Using common vbus_active to indicate vbus status
CC: Felipe Balbi
Signed-off-by: Peter Chen
---
drivers/usb/gadget/at91_udc.c | 16
drivers/usb/gadget/at91_udc.h |1 -
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
index 45dd292..9508d40 100644
--- a/drivers/usb/gadget/at91_udc.c
+++ b/drivers/usb/gadget/at91_udc.c
@@ -173,9 +173,9 @@ static int proc_udc_show(struct seq_file *s, void *unused)
seq_printf(s, "%s: version %s\n", driver_name, DRIVER_VERSION);
seq_printf(s, "vbus %s, pullup %s, %s powered%s, gadget %s\n\n",
- udc->vbus ? "present" : "off",
+ udc->gadget.vbus_active ? "present" : "off",
udc->enabled
- ? (udc->vbus ? "active" : "enabled")
+ ? (udc->gadget.vbus_active ? "active" : "enabled")
: "disabled",
udc->selfpowered ? "self" : "VBUS",
udc->suspended ? ", suspended" : "",
@@ -209,7 +209,7 @@ static int proc_udc_show(struct seq_file *s, void *unused)
proc_irq_show(s, "imr ", at91_udp_read(udc, AT91_UDP_IMR));
proc_irq_show(s, "isr ", at91_udp_read(udc, AT91_UDP_ISR));
- if (udc->enabled && udc->vbus) {
+ if (udc->enabled && udc->gadget.vbus_active) {
proc_ep_show(s, &udc->ep[0]);
list_for_each_entry (ep, &udc->gadget.ep_list, ep.ep_list) {
if (ep->ep.desc)
@@ -892,7 +892,7 @@ static void pullup(struct at91_udc *udc, int is_on)
{
int active = !udc->board.pullup_active_low;
- if (!udc->enabled || !udc->vbus)
+ if (!udc->enabled || !udc->gadget.vbus_active)
is_on = 0;
DBG("%sactive\n", is_on ? "" : "in");
@@ -944,7 +944,7 @@ static int at91_vbus_session(struct usb_gadget *gadget, int
is_active)
/* VDBG("vbus %s\n", is_active ? "on" : "off"); */
spin_lock_irqsave(&udc->lock, flags);
- udc->vbus = (is_active != 0);
+ gadget->vbus_active = (is_active != 0);
if (udc->driver)
pullup(udc, is_active);
else
@@ -1586,7 +1586,7 @@ static struct at91_udc controller = {
static void at91_vbus_update(struct at91_udc *udc, unsigned value)
{
value ^= udc->board.vbus_active_low;
- if (value != udc->vbus)
+ if (value != udc->gadget.vbus_active)
at91_vbus_session(&udc->gadget, value);
}
@@ -1817,7 +1817,7 @@ static int at91udc_probe(struct platform_device *pdev)
* Get the initial state of VBUS - we cannot expect
* a pending interrupt.
*/
- udc->vbus = gpio_get_value_cansleep(udc->board.vbus_pin) ^
+ udc->gadget.vbus_active =
gpio_get_value_cansleep(udc->board.vbus_pin) ^
udc->board.vbus_active_low;
if (udc->board.vbus_polled) {
@@ -1837,7 +1837,7 @@ static int at91udc_probe(struct platform_device *pdev)
}
} else {
DBG("no VBUS detection, assuming always-on\n");
- udc->vbus = 1;
+ udc->gadget.vbus_active = 1;
}
retval = usb_add_gadget_udc(dev, &udc->gadget);
if (retval)
diff --git a/drivers/usb/gadget/at91_udc.h b/drivers/usb/gadget/at91_udc.h
index e647d1c..6f8c7a4 100644
--- a/drivers/usb/gadget/at91_udc.h
+++ b/drivers/usb/gadget/at91_udc.h
@@ -115,7 +115,6 @@ struct at91_udc {
struct usb_gadget gadget;
struct at91_ep ep[NUM_ENDPOINTS];
struct usb_gadget_driver*driver;
- unsignedvbus:1;
unsignedenabled:1;
unsignedclocked:1;
unsignedsuspended:1;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/14] usb: chipidea: using common vbus_active
Using common vbus_active to indicate vbus status
CC: Alexander Shishkin
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/ci.h |2 --
drivers/usb/chipidea/udc.c |6 +++---
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index e25d126..e4c1f63 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -126,7 +126,6 @@ struct hw_bank {
* @suspended: suspended by host
* @test_mode: the selected test mode
* @platdata: platform specific information supplied by parent device
- * @vbus_active: is VBUS active
* @transceiver: pointer to USB PHY, if any
* @hcd: pointer to usb_hcd for ehci host driver
*/
@@ -160,7 +159,6 @@ struct ci13xxx {
u8 test_mode;
struct ci13xxx_platform_data*platdata;
- int vbus_active;
/* FIXME: some day, we'll not use global phy */
boolglobal_phy;
struct usb_phy *transceiver;
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 2f45bba..78e8bac 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1383,7 +1383,7 @@ static int ci13xxx_vbus_session(struct usb_gadget
*_gadget, int is_active)
return -EOPNOTSUPP;
spin_lock_irqsave(&ci->lock, flags);
- ci->vbus_active = is_active;
+ _gadget->vbus_active = is_active;
if (ci->driver)
gadget_ready = 1;
spin_unlock_irqrestore(&ci->lock, flags);
@@ -1566,7 +1566,7 @@ static int ci13xxx_start(struct usb_gadget *gadget,
ci->driver = driver;
pm_runtime_get_sync(&ci->gadget.dev);
if (ci->platdata->flags & CI13XXX_PULLUP_ON_VBUS) {
- if (ci->vbus_active) {
+ if (gadget->vbus_active) {
if (ci->platdata->flags & CI13XXX_REGS_SHARED) {
hw_device_reset(ci, USBMODE_CM_DC);
hw_enable_vbus_intr(ci);
@@ -1598,7 +1598,7 @@ static int ci13xxx_stop(struct usb_gadget *gadget,
spin_lock_irqsave(&ci->lock, flags);
if (!(ci->platdata->flags & CI13XXX_PULLUP_ON_VBUS) ||
- ci->vbus_active) {
+ gadget->vbus_active) {
hw_device_state(ci, 0);
if (ci->platdata->notify_event)
ci->platdata->notify_event(ci,
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/14] Add vbus status to udc-core
Vbus event is a common event for gadget, this patchset move vbus status from individual driver private data to common struct usb_gadget, after that, the udc core can know vbus status well. The last patch uses this vbus_active to determine if we can pullup dp when load gadget module. CC: Alexander Shishkin CC: Jean-Christophe PLAGNIOL-VILLARD CC: Li Yang CC: Roland Stigge CC: Yu Xu CC: Chao Xie CC: Eric Miao CC: Ben Dooks CC: Felipe Balbi Peter Chen (14): usb: udc-core: introduce vbus_active for struct usb_gadget usb: chipidea: using common vbus_active usb: at91_udc: using common vbus_active usb: fsl_udc_core: using common vbus_active usb: lpc32xx_udc: using common vbus_active usb: mv_u3d_core: using common vbus_active usb: mv_udc: using common vbus_active usb: omap_udc: using common vbus_active usb: pch_udc: using common vbus_active usb: pxa25x_udc: using common vbus_active usb: pxa27x_udc: using common vbus_active usb: s3c2410_udc: using common vbus_active usb: udc-core: small cleanup for udc->gadget usb: udc-core: add judgement logic for usb_gadget_connect drivers/usb/chipidea/ci.h |2 -- drivers/usb/chipidea/udc.c|6 +++--- drivers/usb/gadget/at91_udc.c | 16 drivers/usb/gadget/at91_udc.h |1 - drivers/usb/gadget/fsl_udc_core.c |4 ++-- drivers/usb/gadget/fsl_usb2_udc.h |1 - drivers/usb/gadget/lpc32xx_udc.c |1 + drivers/usb/gadget/mv_u3d.h |1 - drivers/usb/gadget/mv_u3d_core.c | 14 +++--- drivers/usb/gadget/mv_udc.h |1 - drivers/usb/gadget/mv_udc_core.c | 14 +++--- drivers/usb/gadget/omap_udc.c |4 ++-- drivers/usb/gadget/omap_udc.h |1 - drivers/usb/gadget/pch_udc.c | 10 -- drivers/usb/gadget/pxa25x_udc.c |6 +++--- drivers/usb/gadget/pxa25x_udc.h |1 - drivers/usb/gadget/pxa27x_udc.c |8 drivers/usb/gadget/pxa27x_udc.h |1 - drivers/usb/gadget/s3c2410_udc.c |6 +++--- drivers/usb/gadget/s3c2410_udc.h |1 - drivers/usb/gadget/udc-core.c | 24 include/linux/usb/gadget.h|1 + 22 files changed, 61 insertions(+), 63 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] usb: musb: omap: always glue have the correct vbus/id status
On Thursday 14 March 2013 03:29 AM, Grazvydas Ignotas wrote: On Wed, Mar 13, 2013 at 10:47 AM, Kishon Vijay Abraham I wrote: In the case where omap glue is loaded and musb core is not, glue->status wont have a valid status if the phy drivers call omap_musb_mailbox. So fixed the conditions here. There already seems to be another patch named "usb: musb: omap2430: fix omap_musb_mailbox glue check again" on it's way to mainline that does mostly the same as first part of this patch. Oh yeah. Missed that. 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 v2] USB: ehci-s5p: Fix phy reset
On 14 March 2013 05:29, Alexander Graf wrote:
> On my Exynos 5 based Arndale system, I need to pull the reset line down
> and then let it go up again to actually perform a reset. Without that
> reset, I can't find any USB hubs on my bus, rendering the USB controller
> useless.
>
> We also only need to reset the line after the phy node has been found.
> This way we don't accidently reserve the vbus GPIO pin, but later on
> defer the creation of our controller, because the phy device tree node
> hasn't been probed yet.
>
> This patch implements the above logic, making EHCI and OHCI work on
> Arndale systems for me.
>
> Signed-off-by: Alexander Graf
> CC: Vivek Gautam
> CC: Jingoo Han
> CC: Alan Stern
> CC: Kukjin Kim
> CC: Felipe Balbi
> CC: Greg Kroah-Hartman
> CC: Doug Anderson
>
> ---
>
> v1 -> v2:
>
> - remove gpio_free call
> - move reset logic after phy node search
>
> diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
> index 20ebf6a..b29b2b8 100644
> --- a/drivers/usb/host/ehci-s5p.c
> +++ b/drivers/usb/host/ehci-s5p.c
> @@ -103,9 +103,14 @@ static void s5p_setup_vbus_gpio(struct platform_device
> *pdev)
> if (!gpio_is_valid(gpio))
> return;
>
> - err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "ehci_vbus_gpio");
> - if (err)
> + /* reset pulls the line down, then up again */
> + err = gpio_request_one(gpio, GPIOF_OUT_INIT_LOW, "ehci_vbus_gpio");
> + if (err) {
> dev_err(&pdev->dev, "can't request ehci vbus gpio %d", gpio);
> + return;
> + }
> + mdelay(1);
> + __gpio_set_value(gpio, 1);
> }
>
> static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
> @@ -131,8 +136,6 @@ static int s5p_ehci_probe(struct platform_device *pdev)
> if (!pdev->dev.coherent_dma_mask)
> pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>
> - s5p_setup_vbus_gpio(pdev);
> -
> s5p_ehci = devm_kzalloc(&pdev->dev, sizeof(struct s5p_ehci_hcd),
> GFP_KERNEL);
> if (!s5p_ehci)
> @@ -152,6 +155,8 @@ static int s5p_ehci_probe(struct platform_device *pdev)
> s5p_ehci->otg = phy->otg;
> }
>
> + s5p_setup_vbus_gpio(pdev);
> +
> s5p_ehci->dev = &pdev->dev;
>
> hcd = usb_create_hcd(&s5p_ehci_hc_driver, &pdev->dev,
Hi Alexander,
This change, though it works for Exynos5250 based Arndale board, does
not actually seem correct. On Arndale board, the on-board 4-port usb
hub is self powered and hence the vbus 'enable' gpio line from
Exynos5250 SoC is instead used as a "reset" signal for the on-board
usb hub (and not as the vbus enable signal).
Whereas, the driver uses the gpio used in 's5p_setup_vbus_gpio'
function as just a mechanism to enable vbus for downstream devices. So
the driver should not be modified as above to handle the board
specific behavior.
Instead, what needs to be done is, remove the "samsung,vbus-gpio"
property from the usb2.0 node in dts files (this property is optional)
for Arndale board. Then, during the machine_init, perform the reset
sequencing as required.
Ideally, the reset sequencing for the on-board AX88760 usb hub should
have been handled in the driver for this device. I have not checked if
there is a driver for this in the kernel.
Thanks,
Thomas.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: usb-skeleton.c: fix blocked forever in skel_read
On Wed, Mar 13, 2013 at 11:15 PM, Oliver Neukum wrote: > On Wednesday 13 March 2013 23:02:32 Ming Lei wrote: >> On Wed, Mar 13, 2013 at 10:55 PM, Oliver Neukum wrote: >> > >> > But it will be run when the next read() call is made. The question is what >> > happens >> >> When next read() is called, looks it won't be reached if >> 'ongoing_read' is set, and >> it needn't run without ongoing URBs. > > If ongoing_read is not set, IO may be started and its completion would > not be waited for, as the IO that had been started, but wasn't waited > for due to an interrupt, has completed. OK, got it, so how about INIT_COMPLETION(&dev->bulk_in_completion) in case of !ongoing_read? That means replacing 'if (!dev->processed_urb)' with INIT_COMPLETION(&dev->bulk_in_completion). Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] USB: ehci-s5p: Fix phy reset
Alexander, On Wed, Mar 13, 2013 at 4:59 PM, Alexander Graf wrote: > On my Exynos 5 based Arndale system, I need to pull the reset line down > and then let it go up again to actually perform a reset. Without that > reset, I can't find any USB hubs on my bus, rendering the USB controller > useless. > > We also only need to reset the line after the phy node has been found. > This way we don't accidently reserve the vbus GPIO pin, but later on > defer the creation of our controller, because the phy device tree node > hasn't been probed yet. > > This patch implements the above logic, making EHCI and OHCI work on > Arndale systems for me. > > Signed-off-by: Alexander Graf > CC: Vivek Gautam > CC: Jingoo Han > CC: Alan Stern > CC: Kukjin Kim > CC: Felipe Balbi > CC: Greg Kroah-Hartman > CC: Doug Anderson > > --- > > v1 -> v2: > > - remove gpio_free call > - move reset logic after phy node search Seems fine to me. I guess the earlier problem you wrote about was the probe failure, then? I think that the reason I don't tend to get the probe failure is that I've got my device tree ordered differently so that the phy gets initted in a different order. I'll send up the devm_ patch atop this. Reviewed-by: Doug Anderson Thanks! :) -Doug -- 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] usb: xhci: fix build warning
/home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c: In
function ‘handle_port_status’:
/home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c:1580:
warning: ‘hcd’ may be used uninitialized in this function
Signed-off-by: Peter Chen
---
drivers/usb/host/xhci-ring.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 8828754..17dace0 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1588,6 +1588,8 @@ static void handle_port_status(struct xhci_hcd *xhci,
__le32 __iomem **port_array;
bool bogus_port_status = false;
+ /* Find the right roothub. */
+ hcd = xhci_to_hcd(xhci);
/* Port status change events always have a successful completion code */
if (GET_COMP_CODE(le32_to_cpu(event->generic.field[2])) !=
COMP_SUCCESS) {
xhci_warn(xhci, "WARN: xHC returned failed port status
event\n");
@@ -1629,8 +1631,6 @@ static void handle_port_status(struct xhci_hcd *xhci,
* into the index into the ports on the correct split roothub, and the
* correct bus_state structure.
*/
- /* Find the right roothub. */
- hcd = xhci_to_hcd(xhci);
if ((major_revision == 0x03) != (hcd->speed == HCD_USB3))
hcd = xhci->shared_hcd;
bus_state = &xhci->bus_state[hcd_index(hcd)];
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resend] usb: gadget: u_serial: fix typo which cause build warning
Hi Sergei, On 3/13/2013 21:35, Sergei Shtylyov wrote: Hello. On 13-03-2013 11:57, Bo Shen wrote: fix typo error in commit ea0e6276 cause the following build warning Pleas ealso specify that commit's summary line in parens (or however you like). Thanks for you information. With Felipe's hint, I have sent out v2 version (http://article.gmane.org/gmane.linux.usb.general/82260) with commit id and subject. Please check it, if any other suggestion will appreciate. warning: "pr_vdebug" redefined Signed-off-by: Bo Shen WBR, Sergei Best Regards, Bo Shen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] usb: phy: add R-Car USB phy driver
Hi Sergei Thank you for pointing it > >> 0x === > >> EHCI > >> -- > >> 0x0094 PHY > >> 0x009C PHY > >> -- > >> EHCI > >> 0x0400 == > >> ... > >> 0x0800 -- > >> PHY > >> 0x0900 -- > >> > >> This driver couldn't probe if it used "request_mem_region()" > > Fair enough. I must say, though. That's a peculiar register mapping ;-) > > > > Not peculiar enough to not be able to overcome it. Those registers > at 0x009[4C] > are not really PHY related, they control EHCI internal buffering. They > probably shouldn't > have been a part of this driver even... I'm not sure what is the best solution. But current rcar_usb_phy is expecting above (strange) mapping, and initialize method is came from datasheet Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] USB: ehci-s5p: Fix phy reset
On my Exynos 5 based Arndale system, I need to pull the reset line down
and then let it go up again to actually perform a reset. Without that
reset, I can't find any USB hubs on my bus, rendering the USB controller
useless.
We also only need to reset the line after the phy node has been found.
This way we don't accidently reserve the vbus GPIO pin, but later on
defer the creation of our controller, because the phy device tree node
hasn't been probed yet.
This patch implements the above logic, making EHCI and OHCI work on
Arndale systems for me.
Signed-off-by: Alexander Graf
CC: Vivek Gautam
CC: Jingoo Han
CC: Alan Stern
CC: Kukjin Kim
CC: Felipe Balbi
CC: Greg Kroah-Hartman
CC: Doug Anderson
---
v1 -> v2:
- remove gpio_free call
- move reset logic after phy node search
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 20ebf6a..b29b2b8 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -103,9 +103,14 @@ static void s5p_setup_vbus_gpio(struct platform_device
*pdev)
if (!gpio_is_valid(gpio))
return;
- err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "ehci_vbus_gpio");
- if (err)
+ /* reset pulls the line down, then up again */
+ err = gpio_request_one(gpio, GPIOF_OUT_INIT_LOW, "ehci_vbus_gpio");
+ if (err) {
dev_err(&pdev->dev, "can't request ehci vbus gpio %d", gpio);
+ return;
+ }
+ mdelay(1);
+ __gpio_set_value(gpio, 1);
}
static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
@@ -131,8 +136,6 @@ static int s5p_ehci_probe(struct platform_device *pdev)
if (!pdev->dev.coherent_dma_mask)
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
- s5p_setup_vbus_gpio(pdev);
-
s5p_ehci = devm_kzalloc(&pdev->dev, sizeof(struct s5p_ehci_hcd),
GFP_KERNEL);
if (!s5p_ehci)
@@ -152,6 +155,8 @@ static int s5p_ehci_probe(struct platform_device *pdev)
s5p_ehci->otg = phy->otg;
}
+ s5p_setup_vbus_gpio(pdev);
+
s5p_ehci->dev = &pdev->dev;
hcd = usb_create_hcd(&s5p_ehci_hc_driver, &pdev->dev,
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ehci-s5p: Fix phy reset
On 13.03.2013, at 18:59, Doug Anderson wrote: > Alexander, > > On Wed, Mar 13, 2013 at 10:45 AM, Alexander Graf wrote: >> + gpio_free(gpio); >>> >>> Freeing the gpio is a little on the iffy side since you actually care >>> about keeping the value. Perhaps you can change this to >>> devm_gpio_request_one() and avoid the free? I was about to submit a >>> patch to do just that (since otherwise you run into trouble if you >>> ever defer the probe) but then ran across your patch. >> >> I could also just return it when the function exits and only free it when we >> exit the probe function with a negative value. The reason I put it in here >> was that on probe deferral, the pin simply gets blocked. >> >> However, I could probably also just completely take the gpio_free() out of >> this patch and resubmit, as it should be pretty much unrelated. Then you can >> patch it properly. > > Sure, if you want to resubmit without the gpio_free() I'll submit a > new patch atop yours with the change to devm and people can see if > they like it... Hrm. So when I remove the gpio_free() again, I can't find the USB hub anymore. If I however postpone the whole reset procedure until after the potential deferral, it works (see patch below). Any idea what is going on here? Alex diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c index f692f70..b29b2b8 100644 --- a/drivers/usb/host/ehci-s5p.c +++ b/drivers/usb/host/ehci-s5p.c @@ -136,8 +136,6 @@ static int s5p_ehci_probe(struct platform_device *pdev) if (!pdev->dev.coherent_dma_mask) pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); - s5p_setup_vbus_gpio(pdev); - s5p_ehci = devm_kzalloc(&pdev->dev, sizeof(struct s5p_ehci_hcd), GFP_KERNEL); if (!s5p_ehci) @@ -157,6 +155,8 @@ static int s5p_ehci_probe(struct platform_device *pdev) s5p_ehci->otg = phy->otg; } + s5p_setup_vbus_gpio(pdev); + s5p_ehci->dev = &pdev->dev; hcd = usb_create_hcd(&s5p_ehci_hc_driver, &pdev->dev,-- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] usb: phy: add R-Car USB phy driver
Hi Sergei
Thank you for pointing it
> > + /* set platform specific port settings */
> > + iowrite32(0x, (reg0 + USBPCTRL0));
>
> This register contains completely board specific setting,
> hard-coding it to 0 is wrong.
> Shouldn't you have passed its value as platform data instead?
(snip)
> > + iowrite32(0x00ff0040, (reg0 + EIIBC1));
> > + iowrite32(0x00ff0040, (reg1 + EIIBC1));
> > +
> > + iowrite32(0x0001, (reg0 + EIIBC2));
> > + iowrite32(0x0001, (reg1 + EIIBC2));
>
> Why write each of these register twice, at different bases? The USB
> section of
> the R-Car H1 manual doesn't seem to mention that they are dual mapped...
(snip)
> > + if (priv->counter-- == 1) { /* last user */
> > + iowrite32(0x, (reg0 + USBPCTRL0));
>
> Why change this register at all at shutdown?
Sorry, I didn't mention about these settings value on this patch.
This driver is using the fixed value for particular applications at this point,
because of prototype driver at that point.
This means it should use platform/chip specific callback function
Best regards
---
Kuninori Morimoto
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: Make USB persist default configurable
Commit 9214d1d8 set the USB persist flag as a default for all devices. This might be desirable for some distributions, but it certainly has its trade-offs... most importantly, it can significantly increase system resume time, because the kernel blocks on resuming (and sometimes resetting) USB devices before it unfreezes userspace. This patch introduces a new config option CONFIG_USB_DEFAULT_PERSIST, which allows distributions to make this decision on their own without the need to carry a custom patch or revert the kernel's setting in userspace. Signed-off-by: Julius Werner --- drivers/usb/core/Kconfig | 14 ++ drivers/usb/core/quirks.c | 16 +--- 2 files changed, 19 insertions(+), 11 deletions(-) diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig index f70c1a1..dfc1360 100644 --- a/drivers/usb/core/Kconfig +++ b/drivers/usb/core/Kconfig @@ -27,6 +27,20 @@ config USB_ANNOUNCE_NEW_DEVICES comment "Miscellaneous USB options" depends on USB +config USB_DEFAULT_PERSIST + bool "Enable USB persist by default" + depends on USB + default y + help + Say N here if you don't want USB power session persistance + enabled by default. This will make suspended USB devices that + lose power get reenumerated as if they had been unplugged, + but may reduce your system's resume time and eliminates any + chance of file system corruption by confusing two devices with + the same vendor and product ID. The persist feature can still + be enabled for individual devices through the power/persist + sysfs node. See Documentation/usb/persist.txt for more info. + config USB_DYNAMIC_MINORS bool "Dynamic USB minor allocation" depends on USB diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c index 3113c1d..ab5638d 100644 --- a/drivers/usb/core/quirks.c +++ b/drivers/usb/core/quirks.c @@ -201,20 +201,14 @@ void usb_detect_quirks(struct usb_device *udev) dev_dbg(&udev->dev, "USB quirks for this device: %x\n", udev->quirks); - /* For the present, all devices default to USB-PERSIST enabled */ -#if 0 /* was: #ifdef CONFIG_PM */ - /* Hubs are automatically enabled for USB-PERSIST */ - if (udev->descriptor.bDeviceClass == USB_CLASS_HUB) +#ifdef CONFIG_USB_DEFAULT_PERSIST + if (!(udev->quirks & USB_QUIRK_RESET)) udev->persist_enabled = 1; - #else - /* In the absence of PM, we can safely enable USB-PERSIST -* for all devices. It will affect things like hub resets -* and EMF-related port disables. -*/ - if (!(udev->quirks & USB_QUIRK_RESET)) + /* Hubs are automatically enabled for USB-PERSIST */ + if (udev->descriptor.bDeviceClass == USB_CLASS_HUB) udev->persist_enabled = 1; -#endif /* CONFIG_PM */ +#endif /* CONFIG_USB_DEFAULT_PERSIST */ } void usb_detect_interface_quirks(struct usb_device *udev) -- 1.7.12.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 resend 0/5] USB: fixes for 3.9-rc
On Wed, Mar 13, 2013 at 11:14:35PM +0100, Johan Hovold wrote: > On Wed, Feb 27, 2013 at 01:52:25PM +0100, Johan Hovold wrote: > > Johan Hovold (5): > > USB: cdc-acm: fix device unregistration > > USB: ftdi_sio: fix use after free in TIOCMIWAIT > > USB: garmin_gps: fix memory leak on disconnect > > USB: io_ti: fix get_icount for two port adapters > > USB: serial: fix interface refcounting > > Greg, I noticed you haven't picked these up yet. I think they should go > into v3.9-rc. Ugh, you are right, sorry about that, I missed them in my first-pass of my "to-apply" queue. I'll pick them up soon and will get them into 3.9-final. thanks for the reminder, greg "my to-apply mbox is 1108 emails big" 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 v3] usb: phy: add R-Car USB phy driver
Hello. On 09/11/2012 08:51 AM, Felipe Balbi wrote: On Mon, Sep 10, 2012 at 06:46:50PM -0700, Kuninori Morimoto wrote: Hi Felipe Thank you for checking this patch +/* USBH common register */ +#define USBPCTRL0 0x0800 +#define USBPCTRL1 0x0804 +#define USBST 0x0808 +#define USBEH0 0x080C +#define USBOH0 0x081C +#define USBCTL00x0858 +#define EIIBC1 0x0094 +#define EIIBC2 0x009C (snip) + reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0)); + reg1 = devm_ioremap_nocache(dev, res1->start, resource_size(res1)); please use devm_request_and_ioremap(). Sorry about this, but I would like to keep devm_ioremap_nocache() here, because this Renesas R-Car PHY address has strange mapping. Some registers of this PHY address are mapped to crevice of USB EHCI/OHCI register area. like this 0x === EHCI -- 0x0094 PHY 0x009C PHY -- EHCI 0x0400 == ... 0x0800 -- PHY 0x0900 -- This driver couldn't probe if it used "request_mem_region()" Fair enough. I must say, though. That's a peculiar register mapping ;-) Not peculiar enough to not be able to overcome it. Those registers at 0x009[4C] are not really PHY related, they control EHCI internal buffering. They probably shouldn't have been a part of this driver even... WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH resend 0/5] USB: fixes for 3.9-rc
On Wed, Feb 27, 2013 at 01:52:25PM +0100, Johan Hovold wrote: > Johan Hovold (5): > USB: cdc-acm: fix device unregistration > USB: ftdi_sio: fix use after free in TIOCMIWAIT > USB: garmin_gps: fix memory leak on disconnect > USB: io_ti: fix get_icount for two port adapters > USB: serial: fix interface refcounting Greg, I noticed you haven't picked these up yet. I think they should go into v3.9-rc. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] usb: musb/otg: cleanup and fixes
On Wed, Mar 13, 2013 at 10:47 AM, Kishon Vijay Abraham I wrote: > This series has some misc cleanup and fixes. The fix solves the cold > plug issue in omap3 which some have reported. Developed these patches on > Linux 3.9-rc2 after applying > http://www.spinics.net/lists/linux-usb/msg81563.html > (Grazvydas Ignotas patch series) > > Tested for g_zero enumeration in pandaboard and beagleboard in both > cold plug and hot plug case. Any kind of testing for this series is welcome. > > Kishon Vijay Abraham I (5): > usb: musb: omap: remove the check before calling otg_set_vbus > usb: musb: omap: always glue have the correct vbus/id status > usb: otg: twl4030: use devres API for regulator get and request irq > usb: musb: omap: add usb_phy_init in omap2430_musb_init > usb: otg: twl4030: fix cold plug on OMAP3 Looks and works good for me on pandora. Tested-by: Grazvydas Ignotas > drivers/usb/musb/omap2430.c | 22 ++ > drivers/usb/otg/twl4030-usb.c | 35 --- > 2 files changed, 22 insertions(+), 35 deletions(-) > > -- > 1.7.10.4 > -- Gražvydas -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] usb: musb: omap: always glue have the correct vbus/id status
On Wed, Mar 13, 2013 at 10:47 AM, Kishon Vijay Abraham I wrote:
> In the case where omap glue is loaded and musb core is not, glue->status
> wont have a valid status if the phy drivers call omap_musb_mailbox. So
> fixed the conditions here.
There already seems to be another patch named "usb: musb: omap2430:
fix omap_musb_mailbox glue check again" on it's way to mainline that
does mostly the same as first part of this patch.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/usb/musb/omap2430.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index 78bfc50..28a0220 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -236,13 +236,10 @@ void omap_musb_mailbox(enum omap_musb_vbus_id_status
> status)
> {
> struct omap2430_glue*glue = _glue;
>
> - if (glue && glue_to_musb(glue)) {
> - glue->status = status;
> - } else {
> - pr_err("%s: musb core is not yet ready\n", __func__);
> + if (!glue)
> return;
> - }
>
> + glue->status = status;
> schedule_work(&glue->omap_musb_mailbox_work);
> }
> EXPORT_SYMBOL_GPL(omap_musb_mailbox);
> @@ -307,7 +304,9 @@ static void omap_musb_mailbox_work(struct work_struct
> *mailbox_work)
> {
> struct omap2430_glue *glue = container_of(mailbox_work,
> struct omap2430_glue, omap_musb_mailbox_work);
> - omap_musb_set_mailbox(glue);
> +
> + if (glue_to_musb(glue))
> + omap_musb_set_mailbox(glue);
> }
>
> static irqreturn_t omap2430_musb_interrupt(int irq, void *__hci)
> --
> 1.7.10.4
>
--
Gražvydas
--
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
[GIT PATCH] USB fixes for 3.9-rc2
The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8: Linux 3.9-rc1 (2013-03-03 15:11:05 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.9-rc2 for you to fetch changes up to 27b351c5546008c640b3e65152f60ca74b3706f1: USB: quatech2: only write to the tty if the port is open. (2013-03-13 12:32:47 -0700) USB fixes for 3.9-rc2 Here are a number of tiny USB fixes and new USB device ids for your 3.9 tree. The "largest" one here is a revert of a usb-storage patch that turned out to be incorrect, breaking existing users, which is never a good thing. Everything else is pretty simple and small Signed-off-by: Greg Kroah-Hartman Aaro Koskinen (2): usb: musb: omap2430: fix omap_musb_mailbox glue check again usb: musb: omap2430: fix sparse warning Alan Stern (2): USB: EHCI: work around silicon bug in Intel's EHCI controllers USB: EHCI: don't check DMA values in QH overlays Andrew Morton (1): usb: dwc3: ep0: fix sparc64 build Arnd Bergmann (1): usb: gadget: fix omap_udc build errors Bill Pemberton (1): USB: quatech2: only write to the tty if the port is open. Bjørn Mork (3): USB: option: add Huawei E5331 USB: storage: in-kernel modeswitching is deprecated USB: storage: fix Huawei mode switching regression Christian Schmiedl (1): USB: added support for Cinterion's products AH6 and PLS8 Dan Carpenter (2): usb: gadget: f_uac1: silence an info leak warning usb: gadget: u_uac1: NULL dereference on error path Dan Williams (2): qcaux: add Franklin U600 qcserial: bind to DM/DIAG port on Gobi 1K devices Dave Tubbs (2): usb: Correction to c67x00 TD data length mask usb: c67x00 RetryCnt value in c67x00 TD should be 3 Felipe Balbi (15): usb: dwc3: core: don't forget to free coherent memory usb: dwc3: omap: fix a typo on of_device_id usb: dwc3: glue layers shouldn't know about the core IP usb: dwc3: gadget: remove unnecessary code usb: chipidea: register debugging sysfs on our device usb: gadget: pxa27x: fix gadget->dev registration usb: gadget: s3c2410: fix gadget->dev registration usb: gadget: pxa25x: fix gadget->dev registration usb: gadget: imx_udc: fix gadget->dev registration usb: gadget: s3c2410: fix build breakage usb: musb: remove all 'select' from Kconfig usb: musb: fix compile warning usb: Makefile: fix drivers/usb/phy/ Makefile entry usb: gadget: pxa25x: fix disconnect reporting usb: musb: core: fix possible build error with randconfig Greg Kroah-Hartman (2): Merge tag 'fixes-for-v3.9-rc2' of git://git.kernel.org/.../balbi/usb into usb-linus Merge tag 'fixes-for-v3.9-rc3' of git://git.kernel.org/.../balbi/usb into usb-linus Kishon Vijay Abraham I (1): usb: gadget: make usb functions to load before gadget driver Marc Kleine-Budde (1): usb: otg: use try_module_get in all usb_get_phy functions and add missing module_put Matwey V. Kornilov (1): usb: cp210x new Vendor/Device IDs Maxin B. John (1): tools: usb: ffs-test: Fix build failure Nishanth Menon (1): usb: gadget: composite: fix kernel-doc warnings Oliver Neukum (1): USB: cdc-wdm: fix buffer overflow Peter Ujfalusi (1): usb: musb: correct Kconfig in order to avoid non compilable selection Sachin Kamat (3): usb: phy: samsung: Convert to devm_ioremap_resource() usb: phy: omap-usb3: Convert to devm_ioremap_resource() usb: phy: omap-control-usb: Convert to devm_ioremap_resource() Steve Conklin (1): usb: serial: Add Rigblaster Advantage to device table drivers/usb/Makefile | 2 +- drivers/usb/c67x00/c67x00-sched.c | 4 +- drivers/usb/chipidea/udc.c | 6 +- drivers/usb/class/cdc-wdm.c| 23 - drivers/usb/dwc3/core.c| 1 + drivers/usb/dwc3/dwc3-exynos.c | 2 - drivers/usb/dwc3/dwc3-omap.c | 8 +- drivers/usb/dwc3/dwc3-pci.c| 2 - drivers/usb/dwc3/ep0.c | 7 +- drivers/usb/dwc3/gadget.c | 3 - drivers/usb/gadget/Makefile| 12 +-- drivers/usb/gadget/composite.c | 5 +- drivers/usb/gadget/f_uac1.c| 1 + drivers/usb/gadget/imx_udc.c | 20 ++-- drivers/usb/gadget/omap_udc.c | 3 +- drivers/usb/gadget/pxa25x_udc.c| 24 +++-- drivers/usb/gadget/pxa27x_udc.c| 18 ++-- drivers/usb/gadget/s3c2410_udc.c | 28 +++--- drivers/usb/gadget/u_uac1.c| 3 + drivers/usb/host/ehci-hcd.c| 6 +- drivers/usb/host/ehci-q.c | 36 +-- drivers/usb/musb/Kconfig | 5 - drivers/usb/musb/musb_core.c | 6 -- drivers/usb/musb/omap2430.c| 12 ++- drivers/usb/otg/otg.c
Re: [PATCH v6] usb: phy: add R-Car USB phy driver
Hello.
On 11/01/2012 05:03 AM, Kuninori Morimoto wrote:
Sorry for the late feedback but I'm studying this driver just now
(in order to port it to R-Car M1A).
diff --git a/drivers/usb/phy/rcar-phy.c b/drivers/usb/phy/rcar-phy.c
new file mode 100644
index 000..792f505
--- /dev/null
+++ b/drivers/usb/phy/rcar-phy.c
@@ -0,0 +1,220 @@
+/*
+ * Renesas R-Car USB phy driver
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Kuninori Morimoto
[...]
+/*
+ * USB initial/install operation.
+ *
+ * This function setup USB phy.
+ * The used value and setting order came from
+ * [USB :: Initial setting] on datasheet.
+ */
+static int rcar_usb_phy_init(struct usb_phy *phy)
+{
[...]
+ /* set platform specific port settings */
+ iowrite32(0x, (reg0 + USBPCTRL0));
This register contains completely board specific setting,
hard-coding it to 0 is wrong.
Shouldn't you have passed its value as platform data instead?
+
+ /*
+* EHCI IP internal buffer setting
+* EHCI IP internal buffer enable
+*
+* These are recommended value of a datasheet
+* see [USB :: EHCI internal buffer setting]
+*/
+ iowrite32(0x00ff0040, (reg0 + EIIBC1));
+ iowrite32(0x00ff0040, (reg1 + EIIBC1));
+
+ iowrite32(0x0001, (reg0 + EIIBC2));
+ iowrite32(0x0001, (reg1 + EIIBC2));
Why write each of these register twice, at different bases? The USB
section of
the R-Car H1 manual doesn't seem to mention that they are dual mapped...
[...]
+static void rcar_usb_phy_shutdown(struct usb_phy *phy)
+{
+ struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
+ void __iomem *reg0 = priv->reg0;
+ unsigned long flags;
+
+ spin_lock_irqsave(&priv->lock, flags);
+
+ if (priv->counter-- == 1) { /* last user */
+ iowrite32(0x, (reg0 + USBPCTRL0));
Why change this register at all at shutdown?
+ iowrite32(0x, (reg0 + USBPCTRL1));
+ }
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] TTY: port hangup and close fixes
On Thu, 2013-03-07 at 15:55 +0100, Johan Hovold wrote: > These patches against 3.9-rc1 fix a few issues with tty-port hangup and > close. > > The first and fifth patch are essentially clean ups. > > The second and third patch fix the fact that DTR could get raised > (rather than dropped) at hangup if there are blocked opens. [ Note that > the second patch has been separated into its own patch and that the > third patch is new in v3 of this series. ] > > The fourth patch makes sure DTR is dropped also on hangup and that DTR > is only dropped for initialised ports (where it could have been raised > in the first place). > > The sixth and final patch, makes sure no tty callbacks are made from > tty_port_close_start when the port has not been initialised (successfully > opened). This was previously only done for wait_until_sent but there's > no reason to call flush_buffer or to honour port drain delay either. > The latter could cause a failed open to stall for up to two seconds. > > As a side-effect, these patches also fix an issue in USB-serial where we > could get tty-port callbacks on an uninitialised port after having hung > up and unregistered a device after disconnect. > > Johan > > > v3: > - amend series with fix of DTR sometimes being raised on hang-up > - do not lower DTR on hangup if port tty is gone > - make sure tty in call to shutdown is refcounted > - use cflag-macros throughout Other than the comments for patch 3/6, this series looks good. Thanks again for your work on this. Please cc: me on the USB serial core changes as well, if you don't mind. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/6] TTY: fix DTR being raised on hang up
On Thu, 2013-03-07 at 15:55 +0100, Johan Hovold wrote:
> Make sure to check ASYNC_INITIALISED before raising DTR when waking up
> from blocked open in tty_port_block_til_ready.
>
> Currently DTR could get raised at hang up as a blocked process would
> raise DTR unconditionally before checking for hang up and returning.
>
> Signed-off-by: Johan Hovold
> ---
> drivers/tty/tty_port.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
> index 3de5918..52f1066 100644
> --- a/drivers/tty/tty_port.c
> +++ b/drivers/tty/tty_port.c
> @@ -355,7 +355,7 @@ int tty_port_block_til_ready(struct tty_port *port,
>
> while (1) {
> /* Indicate we are open */
> - if (tty->termios.c_cflag & CBAUD)
> + if (C_BAUD(tty) && test_bit(ASYNCB_INITIALIZED, &port->flags))
> tty_port_raise_dtr_rts(port);
>
> prepare_to_wait(&port->open_wait, &wait, TASK_INTERRUPTIBLE);
This is ok, but there are 6 other *_block_til_ready() functions:
This one doesn't use DTR/RTS so can be ignored:
./drivers/staging/sb105x/sb_pci_mp.c:static int mp_block_til_ready(struct file
*filp, struct sb_uart_state *state)
This one is so scary you should probably leave it alone:
./drivers/tty/serial/crisv10.c:block_til_ready(struct tty_struct *tty, struct
file * filp,
These will need the same change (although be careful: some use
ASYNC_INITIALIZED rather than ASYNCB_INITIALIZED).
./drivers/tty/synclinkmp.c:static int block_til_ready(struct tty_struct *tty,
struct file *filp,
./drivers/tty/synclink_gt.c:static int block_til_ready(struct tty_struct *tty,
struct file *filp,
./drivers/tty/synclink.c:static int block_til_ready(struct tty_struct *tty,
struct file * filp,
./net/irda/ircomm/ircomm_tty.c:static int ircomm_tty_block_til_ready(struct
ircomm_tty_cb *self,
Please be sure to Cc: David Miller on changes to
net/irda.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Mouse Disconnect Kernel-3.7/3.8
On Wed, 13 Mar 2013 16:45:35 +0100 (CET) Jiri Kosina wrote: > > Do you have USB autosuspend enabled on that device? > The CONFIG_USB_SUSPEND, which controls USB autosuspend, is not available to me during kernel configuration because I do not enable "Run-time PM core functionality" (PM_RUNTIME). Based on this, I would assume that USB autosuspend is not enabled. Frank Peters -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Problem with linux-3.7.7 (Stern - d01875f11f05f76fc471cec94d701201c1b34389)
On Mon, 11 Mar 2013, Adrian Bassett wrote: > I have applied this new patch to an otherwise un-modified 3.8.2 tree: > > Hunk #1 succeeded at 1298 (offset -18 lines). > patch unexpectedly ends in middle of line > > So far I have not been able to trigger a hanging suspend/resume so it rather > looks as if the problem has indeed been fixed. I will run with it for now > and report if there are any issues. Any issues in the last couple of days? If not, I'd like to go ahead and submit this for inclusion in the next round of stable kernels. 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 1/1] USB: Added quirk to recognize GE0301 3G modem as an interface.
manoj.i...@canonical.com writes: > +/* Reported by Timo Aaltonen */ > +UNUSUAL_DEV( 0x0af0, 0x7011, 0x, 0x, > + "Option", > + "Mass Storage", > + USB_SC_DEVICE, USB_PR_DEVICE, option_ms_init, > + 0 ), > + > /* Reported by F. Aben > * This device (wrongly) has a vendor-specific device descriptor. > * The entry is needed so usb-storage can bind to it's mass-storage This device is already supported by the default usb_modeswitch configuration: bjorn@nemi:~$ tar zxOvf /usr/share/usb_modeswitch/configPack.tar.gz 0af0:7011 0af0:7011 # Option HSO device TargetClass=0xff MessageContent="55534243785634120100860100" NoDriverLoading=1 Install the usb-modeswitch package and you're done. No need to patch the kernel for this. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] USB: Added quirk to recognize GE0301 3G modem as an interface.
From: Manoj Iyer Signed-off-by: Manoj Iyer Reported-by: Timo Aaltonen Original-author: Timo Aaltonen BugLink: http://bugs.launchpad.net/bugs/348861 --- drivers/usb/storage/unusual_devs.h |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h index 72923b5..f31a6f9 100644 --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -1169,6 +1169,13 @@ UNUSUAL_DEV( 0x0af0, 0x6971, 0x, 0x, USB_SC_DEVICE, USB_PR_DEVICE, option_ms_init, 0), +/* Reported by Timo Aaltonen */ +UNUSUAL_DEV( 0x0af0, 0x7011, 0x, 0x, + "Option", + "Mass Storage", + USB_SC_DEVICE, USB_PR_DEVICE, option_ms_init, + 0 ), + /* Reported by F. Aben * This device (wrongly) has a vendor-specific device descriptor. * The entry is needed so usb-storage can bind to it's mass-storage -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1] USB: Added quirk to recognize GE0301 3G modem as an interface.
From: Manoj Iyer This patch enables GE0301 3G modem as an interface, the patch has been part of the Ubuntu kernel for a while but I forgot to upstream. Test details can be found in the bug http://bugs.launchpad.net/bugs/348861 Please consider this patch for upstream. Manoj Iyer (1): USB: Added quirk to recognize GE0301 3G modem as an interface. drivers/usb/storage/unusual_devs.h |7 +++ 1 file changed, 7 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [usb-storage] Re: usb3.0 device recognized as usb2.1
On Wed, Mar 13, 2013 at 09:33:01AM +0100, Richard Genoud wrote: > 2013/2/14 Richard Genoud : > > 2013/2/12 Sarah Sharp : > >> On Sun, Feb 03, 2013 at 09:52:42PM -0500, Alan Stern wrote: > >>> On Sun, 3 Feb 2013, Richard Genoud wrote: > >>> > >>> > [previously] > >>> > I tried to use this device : usb3.0 HDD dock ( > >>> > http://www.icydock.com/goods.php?id=130 ) based on JMicron JMS539 > >>> > chipset. > >>> > It's always recognized as an usb2.1 device instead of USB3. > >>> > My USB3 controller is based on VIA VL800 B3. > >>> > Same controller and same device on windows7 is also recognized as > >>> > USB2.1. > >>> > [/previously] > > epilogue for this story: > An hardware reviewer kindly tried his usb dock with a HDD instead of a > SSD. (on windows) > It was also recognized as an USB2. > http://www.zeden.net/actu/19403-test-Icy-Dock-EZ-DOCK-MB881U3-1SA#comment_36566 > (french inside !) > So, it seems to be a hard conception problem. > => I bought another sata/USB3 device (with no HUB, no IDE) and it's > working perfectly. > > Thanks for the support. Thanks for the update! Sarah Sharp -- 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: ehci-s5p: Fix phy reset
Alexander, On Wed, Mar 13, 2013 at 10:45 AM, Alexander Graf wrote: > >>> + gpio_free(gpio); >> >> Freeing the gpio is a little on the iffy side since you actually care >> about keeping the value. Perhaps you can change this to >> devm_gpio_request_one() and avoid the free? I was about to submit a >> patch to do just that (since otherwise you run into trouble if you >> ever defer the probe) but then ran across your patch. > > I could also just return it when the function exits and only free it when we > exit the probe function with a negative value. The reason I put it in here > was that on probe deferral, the pin simply gets blocked. > > However, I could probably also just completely take the gpio_free() out of > this patch and resubmit, as it should be pretty much unrelated. Then you can > patch it properly. Sure, if you want to resubmit without the gpio_free() I'll submit a new patch atop yours with the change to devm and people can see if they like it... -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: since linux kernel 3.8 Apple Cinema Display's usb hub spits errors randomly at boot.
On Wed, 13 Mar 2013, Jenya Y wrote:
> Here how it went.
> I did fresh rebuild of 3.8.2 kernel with my previous settings (where all of
> the mentioned flags were set as 'm') restarted to check the errors - they
> were
> there (-71). Then I went back and applied your patch and this time I got
> something else
> __
> Mar 13 13:33:10 Y8 kernel: usb 1-2.2: can't set config #1, error -19
> Mar 13 13:33:10 Y8 dbus-daemon[231]: dbus[231]: [system] Activating via
> systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
> Mar 13 13:33:10 Y8 kernel: usb 1-2.2: USB disconnect, device number 3
> Mar 13 13:33:10 Y8 kernel: usb 2-1: USB disconnect, device number 2
> Mar 13 13:33:10 Y8 kernel: usb 2-2: USB disconnect, device number 3
> Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: hub_port_status failed (err = -19)
> Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: cannot disable port 2 (err = -19)
> Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: cannot reset port 2 (err = -19)
> Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: cannot disable port 2 (err = -19)
> Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: cannot reset port 2 (err = -19)
> Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: cannot disable port 2 (err = -19)
> Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: cannot reset port 2 (err = -19)
> Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: cannot disable port 2 (err = -19)
> Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: unable to enumerate USB device on
> port
> 2
> Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: cannot disable port 2 (err = -19)
> Mar 13 13:33:10 Y8 kernel: usb 4-1: USB disconnect, device number 2
> Mar 13 13:33:10 Y8 kernel: usb 4-1.3: new full-speed USB device number 3
> using
> uhci_hcd
> Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot reset port 3 (err = -19)
> Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot disable port 3 (err = -19)
> Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot reset port 3 (err = -19)
> Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot disable port 3 (err = -19)
> Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot reset port 3 (err = -19)
> Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot disable port 3 (err = -19)
> Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot reset port 3 (err = -19)
> Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot disable port 3 (err = -19)
> Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: unable to enumerate USB device on
> port
> 3
> Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot disable port 3 (err = -19)
> ___
>
> Not sure if it's better or worse but that's where we are right now. :)
> So I'm back to 3.9 where everything works beatifully (well, almost)
Okay. We don't need to see all those -19 errors. The patch below
(applied on top of the previous patch) will eliminate them.
> I think I should mention that one thing has chnaged in my installation. I've
> updated my systemd to 198, but it had no negative effects on 3.9
>
> Let me know if I should try something else.
>
> PS I have friend who accidentally also had usb issues with 3.8.2 on nvidia
> chipsets and I took the liberty to send him your patch. It worked for
> himthought It cheer you up a little :)
Good to know. :-)
Alan Stern
Index: 3.8/drivers/usb/core/hub.c
===
--- 3.8.orig/drivers/usb/core/hub.c
+++ 3.8/drivers/usb/core/hub.c
@@ -905,11 +905,8 @@ static int hub_usb3_port_disable(struct
return -EINVAL;
ret = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_SS_DISABLED);
- if (ret) {
- dev_err(hub->intfdev, "cannot disable port %d (err = %d)\n",
- port1, ret);
+ if (ret)
return ret;
- }
/* Wait for the link to enter the disabled state. */
for (total_time = 0; ; total_time += HUB_DEBOUNCE_STEP) {
@@ -946,7 +943,7 @@ static int hub_port_disable(struct usb_h
ret = clear_port_feature(hdev, port1,
USB_PORT_FEAT_ENABLE);
}
- if (ret)
+ if (ret && ret != -ENODEV)
dev_err(hub->intfdev, "cannot disable port %d (err = %d)\n",
port1, ret);
return ret;
@@ -2679,14 +2676,16 @@ static int hub_port_reset(struct usb_hub
status = set_port_feature(hub->hdev, port1, (warm ?
USB_PORT_FEAT_BH_PORT_RESET :
USB_PORT_FEAT_RESET));
- if (status) {
+ if (status == -ENODEV) {
+ ; /* The hub is gone */
+ } else if (status) {
dev_err(hub->intfdev,
"cannot %sreset port %d (err = %d)\n",
warm ? "warm " : "", port1, status);
Re: [PATCH] USB: ehci-s5p: Fix phy reset
On 13.03.2013, at 18:28, Doug Anderson wrote:
> Alexander,
>
> On Tue, Mar 12, 2013 at 6:09 PM, Alexander Graf wrote:
>> - err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "ehci_vbus_gpio");
>> - if (err)
>> + /* reset pulls the line down, then up again */
>> + err = gpio_request_one(gpio, GPIOF_OUT_INIT_LOW, "ehci_vbus_gpio");
>> + if (err) {
>>dev_err(&pdev->dev, "can't request ehci vbus gpio %d", gpio);
>> + return;
>> + }
>> + mdelay(1);
>> + __gpio_set_value(gpio, 1);
>> + gpio_free(gpio);
>
> Freeing the gpio is a little on the iffy side since you actually care
> about keeping the value. Perhaps you can change this to
> devm_gpio_request_one() and avoid the free? I was about to submit a
> patch to do just that (since otherwise you run into trouble if you
> ever defer the probe) but then ran across your patch.
I could also just return it when the function exits and only free it when we
exit the probe function with a negative value. The reason I put it in here was
that on probe deferral, the pin simply gets blocked.
However, I could probably also just completely take the gpio_free() out of this
patch and resubmit, as it should be pretty much unrelated. Then you can patch
it properly.
Alex
>
> Thanks!
>
> -Doug
--
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: ehci-s5p: Fix phy reset
Alexander,
On Tue, Mar 12, 2013 at 6:09 PM, Alexander Graf wrote:
> - err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "ehci_vbus_gpio");
> - if (err)
> + /* reset pulls the line down, then up again */
> + err = gpio_request_one(gpio, GPIOF_OUT_INIT_LOW, "ehci_vbus_gpio");
> + if (err) {
> dev_err(&pdev->dev, "can't request ehci vbus gpio %d", gpio);
> + return;
> + }
> + mdelay(1);
> + __gpio_set_value(gpio, 1);
> + gpio_free(gpio);
Freeing the gpio is a little on the iffy side since you actually care
about keeping the value. Perhaps you can change this to
devm_gpio_request_one() and avoid the free? I was about to submit a
patch to do just that (since otherwise you run into trouble if you
ever defer the probe) but then ran across your patch.
Thanks!
-Doug
--
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 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
* Roger Quadros [130313 09:40]: > On 03/13/2013 06:24 PM, Tony Lindgren wrote: > > * Roger Quadros [130313 06:46]: > >> On 03/12/2013 06:40 PM, Tony Lindgren wrote: > >>> * Roger Quadros [130312 04:47]: > Hi Tony, > > These patches provide the SoC side code required to support > the changes in the OMAP USB Host drivers done in [1], [2] & [3]. > >>> ... > >>> > arch/arm/mach-omap2/board-3430sdp.c| 97 > +++- > arch/arm/mach-omap2/board-3630sdp.c| 100 > +++- > arch/arm/mach-omap2/board-am3517crane.c| 95 > +-- > arch/arm/mach-omap2/board-am3517evm.c | 66 ++- > arch/arm/mach-omap2/board-cm-t35.c | 95 > ++- > arch/arm/mach-omap2/board-cm-t3517.c | 97 > +++- > arch/arm/mach-omap2/board-devkit8000.c | 20 ++-- > arch/arm/mach-omap2/board-generic.c| 67 +++ > arch/arm/mach-omap2/board-igep0020.c | 112 > --- > arch/arm/mach-omap2/board-omap3beagle.c| 93 > +-- > arch/arm/mach-omap2/board-omap3evm.c | 62 -- > arch/arm/mach-omap2/board-omap3pandora.c | 52 +++-- > arch/arm/mach-omap2/board-omap3stalker.c | 52 +++- > arch/arm/mach-omap2/board-omap3touchbook.c | 62 +- > arch/arm/mach-omap2/board-omap4panda.c | 122 > ++-- > arch/arm/mach-omap2/board-overo.c | 54 - > arch/arm/mach-omap2/board-zoom.c | 56 - > >>> > >>> Can't you have some mach-omap2/ehci-common.c that takes care > >>> of the initializiation to avoid this much addition to the > >>> board-*.c files? You may be able to have just a common function > >>> to do it and pass few parameters? > >> > >> Since we moved reset and power handling for the USB PHYs from omap-echi > >> driver into the USB PHY driver we need to define the regulator data > >> for RESET and Power line of each PHY. So most of the code added is just > >> regulator data for the PHY rather than omap-ehci. > > > > It seems that you're now repeating minor variations of the same PHY > > over and over again though. > > Yes it is the vcc and reset regulator data for the PHY that > is getting repeated with variations in the GPIO number. > > > > >> Instead of a common function, I can implement some macros that make it > >> easier to define the regulators for the PHY in the board files. > >> Does this sound OK? > >> > >> Personally I don't like such macros because it hides the implementation > >> and is difficult to read/debug. > > > > I'd prefer a common function to initialize the PHY though as it sounds > > like using macros would just allocate similar PHY many times which seems > > unnecessary. > > > OK, so we want to create the regulator data at runtime to save some memory? > I'll come up with something. Or I guess you can have just one instance that gets filled in by some PHY platform init function. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] net: cdc_ncm, cdc_mbim: allow user to prefer NCM for backwards compatibility
Bjørn Mork writes: > +#if IS_ENABLED(CONFIG_USB_NET_CDC_MBIM) > +static bool prefer_mbim = true; > +#else > +static bool prefer_mbim; > +#endif > +module_param(prefer_mbim, bool, S_IRUGO | S_IWUSR); > +MODULE_PARM_DESC(prefer_mbim, "Prefer MBIM on NCM/MBIM backwards compatible > functions"); So, noone wanting to comment on this? I am not sure how to interpret that. If I liked the solution myself I would just have taken it as an unanimous ack, but I don't... Please, if your gut feeling is that this is the most stupid thing you've ever seen, then just say so. I can take it :) 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 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
On 03/13/2013 06:24 PM, Tony Lindgren wrote: > * Roger Quadros [130313 06:46]: >> On 03/12/2013 06:40 PM, Tony Lindgren wrote: >>> * Roger Quadros [130312 04:47]: Hi Tony, These patches provide the SoC side code required to support the changes in the OMAP USB Host drivers done in [1], [2] & [3]. >>> ... >>> arch/arm/mach-omap2/board-3430sdp.c| 97 +++- arch/arm/mach-omap2/board-3630sdp.c| 100 +++- arch/arm/mach-omap2/board-am3517crane.c| 95 +-- arch/arm/mach-omap2/board-am3517evm.c | 66 ++- arch/arm/mach-omap2/board-cm-t35.c | 95 ++- arch/arm/mach-omap2/board-cm-t3517.c | 97 +++- arch/arm/mach-omap2/board-devkit8000.c | 20 ++-- arch/arm/mach-omap2/board-generic.c| 67 +++ arch/arm/mach-omap2/board-igep0020.c | 112 --- arch/arm/mach-omap2/board-omap3beagle.c| 93 +-- arch/arm/mach-omap2/board-omap3evm.c | 62 -- arch/arm/mach-omap2/board-omap3pandora.c | 52 +++-- arch/arm/mach-omap2/board-omap3stalker.c | 52 +++- arch/arm/mach-omap2/board-omap3touchbook.c | 62 +- arch/arm/mach-omap2/board-omap4panda.c | 122 ++-- arch/arm/mach-omap2/board-overo.c | 54 - arch/arm/mach-omap2/board-zoom.c | 56 - >>> >>> Can't you have some mach-omap2/ehci-common.c that takes care >>> of the initializiation to avoid this much addition to the >>> board-*.c files? You may be able to have just a common function >>> to do it and pass few parameters? >> >> Since we moved reset and power handling for the USB PHYs from omap-echi >> driver into the USB PHY driver we need to define the regulator data >> for RESET and Power line of each PHY. So most of the code added is just >> regulator data for the PHY rather than omap-ehci. > > It seems that you're now repeating minor variations of the same PHY > over and over again though. Yes it is the vcc and reset regulator data for the PHY that is getting repeated with variations in the GPIO number. > >> Instead of a common function, I can implement some macros that make it >> easier to define the regulators for the PHY in the board files. >> Does this sound OK? >> >> Personally I don't like such macros because it hides the implementation >> and is difficult to read/debug. > > I'd prefer a common function to initialize the PHY though as it sounds > like using macros would just allocate similar PHY many times which seems > unnecessary. > OK, so we want to create the regulator data at runtime to save some memory? I'll come up with something. 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 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
* Roger Quadros [130313 06:46]: > On 03/12/2013 06:40 PM, Tony Lindgren wrote: > > * Roger Quadros [130312 04:47]: > >> Hi Tony, > >> > >> These patches provide the SoC side code required to support > >> the changes in the OMAP USB Host drivers done in [1], [2] & [3]. > > ... > > > >> arch/arm/mach-omap2/board-3430sdp.c| 97 +++- > >> arch/arm/mach-omap2/board-3630sdp.c| 100 +++- > >> arch/arm/mach-omap2/board-am3517crane.c| 95 +-- > >> arch/arm/mach-omap2/board-am3517evm.c | 66 ++- > >> arch/arm/mach-omap2/board-cm-t35.c | 95 ++- > >> arch/arm/mach-omap2/board-cm-t3517.c | 97 +++- > >> arch/arm/mach-omap2/board-devkit8000.c | 20 ++-- > >> arch/arm/mach-omap2/board-generic.c| 67 +++ > >> arch/arm/mach-omap2/board-igep0020.c | 112 > >> --- > >> arch/arm/mach-omap2/board-omap3beagle.c| 93 +-- > >> arch/arm/mach-omap2/board-omap3evm.c | 62 -- > >> arch/arm/mach-omap2/board-omap3pandora.c | 52 +++-- > >> arch/arm/mach-omap2/board-omap3stalker.c | 52 +++- > >> arch/arm/mach-omap2/board-omap3touchbook.c | 62 +- > >> arch/arm/mach-omap2/board-omap4panda.c | 122 > >> ++-- > >> arch/arm/mach-omap2/board-overo.c | 54 - > >> arch/arm/mach-omap2/board-zoom.c | 56 - > > > > Can't you have some mach-omap2/ehci-common.c that takes care > > of the initializiation to avoid this much addition to the > > board-*.c files? You may be able to have just a common function > > to do it and pass few parameters? > > Since we moved reset and power handling for the USB PHYs from omap-echi > driver into the USB PHY driver we need to define the regulator data > for RESET and Power line of each PHY. So most of the code added is just > regulator data for the PHY rather than omap-ehci. It seems that you're now repeating minor variations of the same PHY over and over again though. > Instead of a common function, I can implement some macros that make it > easier to define the regulators for the PHY in the board files. > Does this sound OK? > > Personally I don't like such macros because it hides the implementation > and is difficult to read/debug. I'd prefer a common function to initialize the PHY though as it sounds like using macros would just allocate similar PHY many times which seems unnecessary. Regards, Tony -- 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/8] usb: phy: nop: Add some parameters to platform data
On 03/13/2013 04:17 PM, Peter Ujfalusi wrote: > On 03/12/2013 04:20 PM, Roger Quadros wrote: >> Adding Peter to the loop. I faintly remember him mentioning this issue before >> for beagle. We really need the deferred probe mechanism or we need to resort >> to device registering order. > > Yes, BeagleBoard is a good example. Long story short: we have external > dependency and the correct way to handle that is via deferred probe. Sure. > As of now we are not ready to kill the legacy support but over time we should > move as much as we can to DT only mode. I was assuming you're already on DT only :) Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH] qcserial: bind to DM/DIAG port on Gobi 1K devices
On Wed, Mar 13, 2013 at 10:38:46AM -0500, Dan Williams wrote: > On Wed, 2013-03-13 at 08:11 -0700, Greg KH wrote: > > On Wed, Mar 13, 2013 at 09:58:18AM -0500, Dan Williams wrote: > > > Turns out we just need altsetting 1 and then we can talk to it. > > > > > > Signed-off-by: Dan Williams > > > > Should this go to the -stable releases as well? > > Yeah, likely. Want a resubmit? No need to, I'll add it by hand when I apply it. 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 1/8] usb: phy: nop: Add some parameters to platform data
On 03/13/2013 05:17 PM, Peter Ujfalusi wrote: > On 03/12/2013 04:20 PM, Roger Quadros wrote: >> Adding Peter to the loop. I faintly remember him mentioning this issue before >> for beagle. We really need the deferred probe mechanism or we need to resort >> to device registering order. > > Yes, BeagleBoard is a good example. Long story short: we have external > dependency and the correct way to handle that is via deferred probe. > > As of now we are not ready to kill the legacy support but over time we should > move as much as we can to DT only mode. > >> The first user for needs_vcc flag will be the beagleboard file. I just didn't >> implement it in this patch [1]. >> >> On second thoughts, since [1] does work on beagleboard without requiring the >> needs_vcc flag, I think we can just live without it. > > The BeagleBoard works because the bootloader happen to enable the PWM > generator which is used as a GPIO for the external HUB enable port. As soon as > the bootloader stops doing this we are going to be in trouble. > Wasn't it the LED A out GPO from PMIC that is used to enable the HUB? Just cross checking so I haven't missed anything. I will resend the board support patch for beagle implementing needs_vcc flag for the deferred probe mechanism. Thanks. 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: USB Mouse Disconnect Kernel-3.7/3.8
On Mon, 11 Mar 2013, Frank Peters wrote: > When I boot my x64 Linux system to the console a continuous series > of "USB disconnect/reconnect" messages appears in the kernel log. > The disconnect/reconnect messages concern the USB mouse: > > usb 1-1.3: USB disconnect, device number N > usb 1-1.3: new low-speed USB device number N+1 using ehci-pci > input: Microsoft Microsoft Basic Optical Mouse v2.0 as > /devices/pci:00/:00:1a.0 usb1/1-1/1-1.3/1-1.3:1.0/input/input5 > hid-generic 0003:045E:00CB.0006: input: USB HID v1.11 Mouse [Microsoft > Microsoft Basic Optical Mouse v2.0 ] on usb-:00:1a.0-1.3/input0 > > > These "USB disconnect/reconnect" messages will repeat roughly every 40 seconds > with the device number "N" increasing to "N+1" each time. > > The interesting thing about this behavior is that I can stop the messages, > and presumably the disconnects, by starting the General Purpose Mouse (gpm) > server: > > gpm -m /dev/input/mice -t imps2 > > If I then terminate the gpm server, the USB disconnect/reconnect messages > will start to occur once again. > > The USB disconnects also stop when I start the graphical X server. > > It would seem that if nothing is "grabbing" the USB mouse (i.e. gpm or X) > then the kernel somehow automatically disconnects it. > > My system has the USB built in to the kernel (no modules). > > The motherboard I use is Intel DP55KG which has the P55 Express > chipset to control the USB. > > I've seen this behavior on the current kernel-3.8.x and also > on the previous kernel-3.7. I have not tested anything earlier. > > Please CC to frank.pet...@comcast.net as I am not subscribed to > the list. [ adding linux-usb@ to CC ] Do you have USB autosuspend enabled on that device? -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qcserial: bind to DM/DIAG port on Gobi 1K devices
On Wed, 2013-03-13 at 08:11 -0700, Greg KH wrote: > On Wed, Mar 13, 2013 at 09:58:18AM -0500, Dan Williams wrote: > > Turns out we just need altsetting 1 and then we can talk to it. > > > > Signed-off-by: Dan Williams > > Should this go to the -stable releases as well? Yeah, likely. Want a resubmit? Dan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net,stable-3.8] net: qmi_wwan: set correct altsetting for Gobi 1K devices
From: Dan Williams
Date: Wed, 13 Mar 2013 08:43:36 -0500
> On Wed, 2013-03-13 at 13:25 +0100, Bjørn Mork wrote:
>> commit bd877e4 ("net: qmi_wwan: use a single bind function for
>> all device types") made Gobi 1K devices fail probing.
>>
>> Using the number of endpoints in the default altsetting to decide
>> whether the function use one or two interfaces is wrong. Other
>> altsettings may provide more endpoints.
>>
>> With Gobi 1K devices, USB interface #3's altsetting is 0 by default, but
>> altsetting 0 only provides one interrupt endpoint and is not sufficent
>> for QMI. Altsetting 1 provides all 3 endpoints required for qmi_wwan
>> and works with QMI. Gobi 1K layout for intf#3 is:
>>
>> Interface Descriptor: 255/255/255
>> bInterfaceNumber3
>> bAlternateSetting 0
>> Endpoint Descriptor: Interrupt IN
>> Interface Descriptor: 255/255/255
>> bInterfaceNumber3
>> bAlternateSetting 1
>> Endpoint Descriptor: Interrupt IN
>> Endpoint Descriptor: Bulk IN
>> Endpoint Descriptor: Bulk OUT
>>
>> Prior to commit bd877e4, we would call usbnet_get_endpoints
>> before giving up finding enough endpoints. Removing the early
>> endpoint number test and the strict functional descriptor
>> requirement allow qmi_wwan_bind to continue until
>> usbnet_get_endpoints has made the final attempt to collect
>> endpoints. This restores the behaviour from before commit
>> bd877e4 without losing the added benefit of using a single bind
>> function.
>>
>> The driver has always required a CDC Union functional descriptor
>> for two-interface functions. Using the existence of this
>> descriptor to detect two-interface functions is the logically
>> correct method.
>>
>> Reported-by: Dan Williams
>> Signed-off-by: Bjørn Mork
>
> Works on my UML290, Gobi3K, Gobi1K, Gobi2K, and E362.
>
> Tested-by: Dan Williams
Applied and queued up for -stable.
--
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/8] usb: phy: nop: Add some parameters to platform data
On 03/12/2013 04:20 PM, Roger Quadros wrote: > Adding Peter to the loop. I faintly remember him mentioning this issue before > for beagle. We really need the deferred probe mechanism or we need to resort > to device registering order. Yes, BeagleBoard is a good example. Long story short: we have external dependency and the correct way to handle that is via deferred probe. As of now we are not ready to kill the legacy support but over time we should move as much as we can to DT only mode. > The first user for needs_vcc flag will be the beagleboard file. I just didn't > implement it in this patch [1]. > > On second thoughts, since [1] does work on beagleboard without requiring the > needs_vcc flag, I think we can just live without it. The BeagleBoard works because the bootloader happen to enable the PWM generator which is used as a GPIO for the external HUB enable port. As soon as the bootloader stops doing this we are going to be in trouble. > > Felipe, Peter, what do you think? > > cheers, > -roger > > [1] https://lkml.org/lkml/2013/3/12/244 > -- Péter -- 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: usb-skeleton.c: fix blocked forever in skel_read
On Wednesday 13 March 2013 23:02:32 Ming Lei wrote: > On Wed, Mar 13, 2013 at 10:55 PM, Oliver Neukum wrote: > > > > But it will be run when the next read() call is made. The question is what > > happens > > When next read() is called, looks it won't be reached if > 'ongoing_read' is set, and > it needn't run without ongoing URBs. If ongoing_read is not set, IO may be started and its completion would not be waited for, as the IO that had been started, but wasn't waited for due to an interrupt, has completed. 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] qcserial: bind to DM/DIAG port on Gobi 1K devices
On Wed, Mar 13, 2013 at 09:58:18AM -0500, Dan Williams wrote: > Turns out we just need altsetting 1 and then we can talk to it. > > Signed-off-by: Dan Williams Should this go to the -stable releases as well? 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] USB: usb-skeleton.c: fix blocked forever in skel_read
On Wed, Mar 13, 2013 at 10:55 PM, Oliver Neukum wrote: > > But it will be run when the next read() call is made. The question is what > happens When next read() is called, looks it won't be reached if 'ongoing_read' is set, and it needn't run without ongoing URBs. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] qcserial: bind to DM/DIAG port on Gobi 1K devices
Turns out we just need altsetting 1 and then we can talk to it.
Signed-off-by: Dan Williams
---
diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 2466254..59b32b7 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -197,12 +197,15 @@ static int qcprobe(struct usb_serial *serial, const
struct usb_device_id *id)
if (is_gobi1k) {
/* Gobi 1K USB layout:
-* 0: serial port (doesn't respond)
+* 0: DM/DIAG (use libqcdm from ModemManager for communication)
* 1: serial port (doesn't respond)
* 2: AT-capable modem port
* 3: QMI/net
*/
- if (ifnum == 2)
+ if (ifnum == 0) {
+ dev_dbg(dev, "Gobi 1K DM/DIAG interface found\n");
+ altsetting = 1;
+ } else if (ifnum == 2)
dev_dbg(dev, "Modem port found\n");
else
altsetting = -1;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: usb-skeleton.c: fix blocked forever in skel_read
On Wednesday 13 March 2013 22:42:37 Ming Lei wrote: > On Wed, Mar 13, 2013 at 10:36 PM, Oliver Neukum wrote: > > On Wednesday 13 March 2013 22:22:53 Du Xing wrote: > >> From: Du Xing duxing2...@gmail.com > >> > >> In skel_read,the reader blocked in wait_for_completion before submit bulk > >> in urb. > >> Using processed_urb is totally unnecessary, remove it can fix the bug. > > > > The processed_urb is intended for the case that the interruptible wait in > > skel_read was interrupted. So the diagnosis is good, but the fix is dubious. > > If skel_read is interrupted, the function will exit, so this code won't be run > under the situation. But it will be run when the next read() call is made. The question is what happens to the counter in the struct completion. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: usb-skeleton.c: fix blocked forever in skel_read
On Wed, Mar 13, 2013 at 10:36 PM, Oliver Neukum wrote: > On Wednesday 13 March 2013 22:22:53 Du Xing wrote: >> From: Du Xing duxing2...@gmail.com >> >> In skel_read,the reader blocked in wait_for_completion before submit bulk in >> urb. >> Using processed_urb is totally unnecessary, remove it can fix the bug. > > The processed_urb is intended for the case that the interruptible wait in > skel_read was interrupted. So the diagnosis is good, but the fix is dubious. If skel_read is interrupted, the function will exit, so this code won't be run under the situation. Looks the patch is fine. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: usb-skeleton.c: fix blocked forever in skel_read
On Wednesday 13 March 2013 22:22:53 Du Xing wrote: > From: Du Xing duxing2...@gmail.com > > In skel_read,the reader blocked in wait_for_completion before submit bulk in > urb. > Using processed_urb is totally unnecessary, remove it can fix the bug. The processed_urb is intended for the case that the interruptible wait in skel_read was interrupted. So the diagnosis is good, but the fix is dubious. 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: Isochronous transfer error on USB3
2013/3/12 jean-philippe francois : > 2013/3/12 jean-philippe francois : >> 2013/3/12 Sarah Sharp : >>> On Mon, Mar 11, 2013 at 01:21:48PM +0100, jean-philippe francois wrote: Hi, The company I work for is doing USB cameras, for which I wrote the drivers (out of tree). >>> >>> Kernel driver or userspace driver? >>> >> Kernel driver. >> Raw camera data are transferred using isochronous transfer, which work fine when used on USB2 EHCI. However when plugging the camera on an USB3 port, xhci spits the following messages on URB submission : [ 1704.989785] xhci_hcd :01:00.0: ERROR Transfer event TRB DMA ptr not part of current TD >>> >>> Does the device work properly, despite the error messages? I see that >>> there are transfer errors in the log file, along with those messages. >>> Are those expected? >>> >> >> The completion handler for the submitteds urb is never called, so I would say >> no transfer is hapenning. After these error messages, nothing happens. >> The urb are not completed, so they are not restarted. >> When stopping the transfer, the HC dies. >> > > Sometimes the completion handler is called, but transfer are never > restarted anyway. > Attached is the interrupt routine code, and the relevant part of the log. > > Individual iso frame transfer are completed, actual_length field is > Ok, but status is -EPROTO. > > USB3 host is an asmedia ASM1042. Update : I have been able to test this on an intel XHCI, and it works fine, except for some difference in the treatment of short iso packet in the EHCI and XHCI path. On the ASM1042, it also work when the endpoint descriptor is set to 3x1000, bInterval = 2. But it does not with a iso endpoint descriptor of 3x1000, bInterval = 1. >>> >>> Do you know if this is a 1.0 xHCI host? E.g. when you enable >>> CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING, do you see lines >>> like this during driver initialization: >>> >>> CAPLENGTH AND HCIVERSION 0x180: >>> >>> If you see that line start with 0x100, it's a 1.0 xHCI host. If starts >>> with 0x096, it's a 0.96 host; 0x095 would be a 0.95 host. >>> >> >> It is a 0.96 host. : >> 0x960020 (CAPLENGTH AND HCIVERSION) >> >>> I ask because I have a todo list entry to fix short packet handling on >>> xHCI 1.0 hosts: >>> >>> "On Intel Lynx Point xHCI, when you plug in a HS USB webcam, the log >>> will fill with the error message: >>> >>> ERROR Transfer event TRB DMA ptr not part of current TD >>> >>> However, the video looks fine, and there is no impact on the driver >>> behavior. >>> >>> This is caused by a change between the xHCI 0.96 and the xHCI 1.0 spec. >>> The change describes in section 4.10.1.1 how the xHCI host controller >>> should handle short transfers that happen on a TD comprised of more than >>> one TRB chained together. The 0.96 spec says that the host will only >>> send one event with a short completion code for the TD. The 1.0 spec >>> says if the short packet happened on a TRB that wasn't the last TRB in >>> the TD, then we will get two events with short completions (one for the >>> short TRB and one for the last TRB with the IOC flag set). The 1.0 spec >>> says that the xHCI driver shall not consider the TD to be done until the >>> second event is received. >>> >> >> I don't think it is the same issue here, because no transfer happens or is >> considered complete, and we are at the beginning of the frame, so there >> should >> be no short transfer. >> >> What is the meaning of "Endpoint 0x82 not halted, refusing to reset" >> The failed isochronous urb should happen on this endpoint. >> >> Thank you for your interest. >> >> Jean-Philippe François >>> The current xHCI driver behavior finishes the TD when it receives the >>> first short event. Then when it receives the second event, it prints the >>> warning message. >>> >>> This also appeared under the xHCI 1.0 host in Intel Panther Point xHCI, >>> but it was mistaken for a known hardware bug, the spurious successful >>> event bug. The work-around that was put into the driver masks this xHCI >>> driver bug. >>> >>> Impact on the driver is minimal for this bug. >>> >>> The easy fix is just to change the XHCI_SPURIOUS_SUCCESS quirk to be >>> applied for all 1.0 xHCI hosts. However, that doesn't solve the race >>> condition that exists when the endpoint is stopped before the second >>> event TRB is received. >>> >>> The harder fix is to either add an event data TRB after the chained TD >>> (and stop using ISP and IOC flags), or make the xHCI ring handling code >>> wait for the second event completion for xHCI 1.0 hosts." >>> >>> Sarah Sharp -- 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 13/13] USB: ehci-omap: Get rid of omap_ehci_init()
On Wed, 13 Mar 2013, Roger Quadros wrote: > As it does almost nothing, get rid of omap_ehci_init() > and move the ehci->caps initialization part into probe(). > > Also remove the outdated TODO list from header. > > Signed-off-by: Roger Quadros > CC: Alan Stern Acked-by: 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 v3 12/13] USB: ehci-omap: Fix detection in HSIC mode
On Wed, 13 Mar 2013, Roger Quadros wrote: > Move PHY initialization until after EHCI initialization is > complete, instead of initializing the PHYs first, shutting > them down again, and then initializing them a second time. > > This fixes HSIC device detection. > > Signed-off-by: Roger Quadros > CC: Alan Stern Acked-by: 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: ehci-s5p: Fix phy reset
On Wed, 13 Mar 2013, Alexander Graf wrote:
> On my Exynos 5 based Arndale system, I need to pull the reset line down
> and then let it go up again to actually perform a reset. Without that
> reset, I can't find any USB hubs on my bus, rendering the USB controller
> useless.
>
> So this patch implements the above logic, making EHCI and OHCI work on
> Arndale systems for me.
>
> Signed-off-by: Alexander Graf
> CC: Vivek Gautam
> CC: Jingoo Han
> CC: Alan Stern
> CC: Kukjin Kim
> CC: Felipe Balbi
> CC: Greg Kroah-Hartman
>
> ---
>
> As this affects 3.9, this patch should definitely be considered for inclusion
> there.
> ---
> drivers/usb/host/ehci-s5p.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
> index 20ebf6a..c6d67e4 100644
> --- a/drivers/usb/host/ehci-s5p.c
> +++ b/drivers/usb/host/ehci-s5p.c
> @@ -103,9 +103,15 @@ static void s5p_setup_vbus_gpio(struct platform_device
> *pdev)
> if (!gpio_is_valid(gpio))
> return;
>
> - err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "ehci_vbus_gpio");
> - if (err)
> + /* reset pulls the line down, then up again */
> + err = gpio_request_one(gpio, GPIOF_OUT_INIT_LOW, "ehci_vbus_gpio");
> + if (err) {
> dev_err(&pdev->dev, "can't request ehci vbus gpio %d", gpio);
> + return;
> + }
> + mdelay(1);
> + __gpio_set_value(gpio, 1);
> + gpio_free(gpio);
> }
>
> static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
Acked-by: 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
[PATCH] USB: usb-skeleton.c: fix blocked forever in skel_read
From: Du Xing duxing2...@gmail.com
In skel_read,the reader blocked in wait_for_completion before submit bulk in
urb.
Using processed_urb is totally unnecessary, remove it can fix the bug.
---
Signed-off-by: Du Xing duxing2...@gmail.com
---
diff --git a/drivers/usb/usb-skeleton.c b/drivers/usb/usb-skeleton.c
index ce31017..14e4889 100644
--- a/drivers/usb/usb-skeleton.c
+++ b/drivers/usb/usb-skeleton.c
@@ -61,7 +61,6 @@ struct usb_skel {
__u8bulk_out_endpointAddr; /* the address of the
bulk out endpoint */
int errors; /* the last request
tanked */
boolongoing_read; /* a read is going on */
- boolprocessed_urb; /* indicates we haven't
processed the urb */
spinlock_t err_lock; /* lock for errors */
struct kref kref;
struct mutexio_mutex; /* synchronize I/O with
disconnect */
@@ -269,17 +268,6 @@ retry:
* we must finish now
*/
dev->bulk_in_copied = 0;
- dev->processed_urb = 1;
- }
-
- if (!dev->processed_urb) {
- /*
-* the URB hasn't been processed
-* do it now
-*/
- wait_for_completion(&dev->bulk_in_completion);
- dev->bulk_in_copied = 0;
- dev->processed_urb = 1;
}
/* errors must be reported */
---
--
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: quatech2: only write to the tty if the port is open.
Hello. On 13-03-2013 17:50, Bill Pemberton wrote: The commit 2e124b4a390ca85325fae75764bef92f0547fa25 removed the checks Please also specify that commit's summary line in parens (or however you like). that prevented qt2_process_read_urb() from trying to put chars into ttys that weren't actually opened. This resulted in 'tty is NULL' warnings from flush_to_ldisc() when the device was used. The devices use just one read urb for all ports. As a result qt2_process_read_urb() may be called with the current port set to a port number that has not been opened. Add a check if the port is open before calling tty_flip_buffer_push(). Signed-off-by: Bill Pemberton 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
PROBLEM: since linux kernel 3.8 Apple Cinema Display's usb hub spits errors randomly at boot.
-- Forwarded Message -- Not sure if it's better or worse but that's where we are right now. :) So I'm back to 3.9 where everything works beautifully (well, almost) I think I should mention that one thing has chnaged in my installation. I've updated my systemd to 198, but it had no negative effects on 3.9 Let me know if I should try something else. PS I have a friend who accidentally also had usb issues with 3.8.2 on nvidia chipsets and I took the liberty to send him your patch. It worked for himthought it will cheer you up a little :) // Jenya - I think I should try to rebuild the 3.9 kernel with all the 'trouble' settings and see what happens. I'm just curious... - I did it and the errors were also there in 3.9 rc2 and as you said, it looks like it is my particular configuration then. What was required for them to dissappear was to set (additionally to your USB EHCI suggestions) CONFIG_USB to 'y'. Maybe it was obvious, but I wanted to make sure. // Jenya -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: quatech2: only write to the tty if the port is open.
The commit 2e124b4a390ca85325fae75764bef92f0547fa25 removed the checks that prevented qt2_process_read_urb() from trying to put chars into ttys that weren't actually opened. This resulted in 'tty is NULL' warnings from flush_to_ldisc() when the device was used. The devices use just one read urb for all ports. As a result qt2_process_read_urb() may be called with the current port set to a port number that has not been opened. Add a check if the port is open before calling tty_flip_buffer_push(). Signed-off-by: Bill Pemberton --- drivers/usb/serial/quatech2.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/quatech2.c b/drivers/usb/serial/quatech2.c index 00e6c9b..d643a4d 100644 --- a/drivers/usb/serial/quatech2.c +++ b/drivers/usb/serial/quatech2.c @@ -661,7 +661,9 @@ void qt2_process_read_urb(struct urb *urb) __func__); break; } - tty_flip_buffer_push(&port->port); + + if (port_priv->is_open) + tty_flip_buffer_push(&port->port); newport = *(ch + 3); @@ -704,7 +706,8 @@ void qt2_process_read_urb(struct urb *urb) tty_insert_flip_string(&port->port, ch, 1); } - tty_flip_buffer_push(&port->port); + if (port_priv->is_open) + tty_flip_buffer_push(&port->port); } static void qt2_write_bulk_callback(struct urb *urb) -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net,stable-3.8] net: qmi_wwan: set correct altsetting for Gobi 1K devices
On Wed, 2013-03-13 at 13:25 +0100, Bjørn Mork wrote:
> commit bd877e4 ("net: qmi_wwan: use a single bind function for
> all device types") made Gobi 1K devices fail probing.
>
> Using the number of endpoints in the default altsetting to decide
> whether the function use one or two interfaces is wrong. Other
> altsettings may provide more endpoints.
>
> With Gobi 1K devices, USB interface #3's altsetting is 0 by default, but
> altsetting 0 only provides one interrupt endpoint and is not sufficent
> for QMI. Altsetting 1 provides all 3 endpoints required for qmi_wwan
> and works with QMI. Gobi 1K layout for intf#3 is:
>
> Interface Descriptor: 255/255/255
> bInterfaceNumber3
> bAlternateSetting 0
> Endpoint Descriptor: Interrupt IN
> Interface Descriptor: 255/255/255
> bInterfaceNumber3
> bAlternateSetting 1
> Endpoint Descriptor: Interrupt IN
> Endpoint Descriptor: Bulk IN
> Endpoint Descriptor: Bulk OUT
>
> Prior to commit bd877e4, we would call usbnet_get_endpoints
> before giving up finding enough endpoints. Removing the early
> endpoint number test and the strict functional descriptor
> requirement allow qmi_wwan_bind to continue until
> usbnet_get_endpoints has made the final attempt to collect
> endpoints. This restores the behaviour from before commit
> bd877e4 without losing the added benefit of using a single bind
> function.
>
> The driver has always required a CDC Union functional descriptor
> for two-interface functions. Using the existence of this
> descriptor to detect two-interface functions is the logically
> correct method.
>
> Reported-by: Dan Williams
> Signed-off-by: Bjørn Mork
Works on my UML290, Gobi3K, Gobi1K, Gobi2K, and E362.
Tested-by: Dan Williams
>
> ---
> Dan,
>
> could you test this on a Gobi 1K device? It should fix the problem,
> but I'd like to verify my assumptions for once :)
>
> This needs to go to stable-3.8 as well.
>
>
> Bjørn
>
>
> drivers/net/usb/qmi_wwan.c | 49
> +++-
> 1 file changed, 16 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index efb5c7c..968d5d5 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -139,16 +139,9 @@ static int qmi_wwan_bind(struct usbnet *dev, struct
> usb_interface *intf)
>
> BUILD_BUG_ON((sizeof(((struct usbnet *)0)->data) < sizeof(struct
> qmi_wwan_state)));
>
> - /* control and data is shared? */
> - if (intf->cur_altsetting->desc.bNumEndpoints == 3) {
> - info->control = intf;
> - info->data = intf;
> - goto shared;
> - }
> -
> - /* else require a single interrupt status endpoint on control intf */
> - if (intf->cur_altsetting->desc.bNumEndpoints != 1)
> - goto err;
> + /* set up initial state */
> + info->control = intf;
> + info->data = intf;
>
> /* and a number of CDC descriptors */
> while (len > 3) {
> @@ -207,25 +200,14 @@ next_desc:
> buf += h->bLength;
> }
>
> - /* did we find all the required ones? */
> - if (!(found & (1 << USB_CDC_HEADER_TYPE)) ||
> - !(found & (1 << USB_CDC_UNION_TYPE))) {
> - dev_err(&intf->dev, "CDC functional descriptors missing\n");
> - goto err;
> - }
> -
> - /* verify CDC Union */
> - if (desc->bInterfaceNumber != cdc_union->bMasterInterface0) {
> - dev_err(&intf->dev, "bogus CDC Union: master=%u\n",
> cdc_union->bMasterInterface0);
> - goto err;
> - }
> -
> - /* need to save these for unbind */
> - info->control = intf;
> - info->data = usb_ifnum_to_if(dev->udev, cdc_union->bSlaveInterface0);
> - if (!info->data) {
> - dev_err(&intf->dev, "bogus CDC Union: slave=%u\n",
> cdc_union->bSlaveInterface0);
> - goto err;
> + /* Use separate control and data interfaces if we found a CDC Union */
> + if (cdc_union) {
> + info->data = usb_ifnum_to_if(dev->udev,
> cdc_union->bSlaveInterface0);
> + if (desc->bInterfaceNumber != cdc_union->bMasterInterface0 ||
> !info->data) {
> + dev_err(&intf->dev, "bogus CDC Union: master=%u,
> slave=%u\n",
> + cdc_union->bMasterInterface0,
> cdc_union->bSlaveInterface0);
> + goto err;
> + }
> }
>
> /* errors aren't fatal - we can live with the dynamic address */
> @@ -235,11 +217,12 @@ next_desc:
> }
>
> /* claim data interface and set it up */
> - status = usb_driver_claim_interface(driver, info->data, dev);
> - if (status < 0)
> - goto err;
> + if (info->control != info->data) {
> + status = usb_driver_claim_interface(driver, info->data, dev);
> + if (status < 0)
> + goto err;
Re: [PATCH 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
On 03/12/2013 06:40 PM, Tony Lindgren wrote: > * Roger Quadros [130312 04:47]: >> Hi Tony, >> >> These patches provide the SoC side code required to support >> the changes in the OMAP USB Host drivers done in [1], [2] & [3]. > ... > >> arch/arm/mach-omap2/board-3430sdp.c| 97 +++- >> arch/arm/mach-omap2/board-3630sdp.c| 100 +++- >> arch/arm/mach-omap2/board-am3517crane.c| 95 +-- >> arch/arm/mach-omap2/board-am3517evm.c | 66 ++- >> arch/arm/mach-omap2/board-cm-t35.c | 95 ++- >> arch/arm/mach-omap2/board-cm-t3517.c | 97 +++- >> arch/arm/mach-omap2/board-devkit8000.c | 20 ++-- >> arch/arm/mach-omap2/board-generic.c| 67 +++ >> arch/arm/mach-omap2/board-igep0020.c | 112 >> --- >> arch/arm/mach-omap2/board-omap3beagle.c| 93 +-- >> arch/arm/mach-omap2/board-omap3evm.c | 62 -- >> arch/arm/mach-omap2/board-omap3pandora.c | 52 +++-- >> arch/arm/mach-omap2/board-omap3stalker.c | 52 +++- >> arch/arm/mach-omap2/board-omap3touchbook.c | 62 +- >> arch/arm/mach-omap2/board-omap4panda.c | 122 >> ++-- >> arch/arm/mach-omap2/board-overo.c | 54 - >> arch/arm/mach-omap2/board-zoom.c | 56 - > > Can't you have some mach-omap2/ehci-common.c that takes care > of the initializiation to avoid this much addition to the > board-*.c files? You may be able to have just a common function > to do it and pass few parameters? Since we moved reset and power handling for the USB PHYs from omap-echi driver into the USB PHY driver we need to define the regulator data for RESET and Power line of each PHY. So most of the code added is just regulator data for the PHY rather than omap-ehci. Instead of a common function, I can implement some macros that make it easier to define the regulators for the PHY in the board files. Does this sound OK? Personally I don't like such macros because it hides the implementation and is difficult to read/debug. 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: [Resend] usb: gadget: u_serial: fix typo which cause build warning
Hello. On 13-03-2013 11:57, Bo Shen wrote: fix typo error in commit ea0e6276 cause the following build warning Pleas ealso specify that commit's summary line in parens (or however you like). warning: "pr_vdebug" redefined Signed-off-by: Bo Shen WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cdc-wdm: fix buffer overflow
Hello. On 12-03-2013 17:52, oli...@neukum.org wrote: From: Oliver Neukum The buffer for responses must not overflow. If this would happen, set a flag, drop the data and return an error after user space has read all remaining data. Signed-off-by: Oliver Neukum Are different email addresses in the From: line and the signoff intentional? CC: sta...@kernel.org 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 13/13] USB: ehci-omap: Get rid of omap_ehci_init()
As it does almost nothing, get rid of omap_ehci_init()
and move the ehci->caps initialization part into probe().
Also remove the outdated TODO list from header.
Signed-off-by: Roger Quadros
CC: Alan Stern
---
drivers/usb/host/ehci-omap.c | 21 +
1 files changed, 1 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 755b428..5de3e43 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -29,12 +29,6 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
- * TODO (last updated Feb 27, 2010):
- * - add kernel-doc
- * - enable AUTOIDLE
- * - add suspend/resume
- * - add HSIC and TLL support
- * - convert to use hwmod and runtime PM
*/
#include
@@ -87,26 +81,12 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
return __raw_readl(base + reg);
}
-static int omap_ehci_init(struct usb_hcd *hcd)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- int rc;
-
- /* we know this is the memory we want, no need to ioremap again */
- ehci->caps = hcd->regs;
-
- rc = ehci_setup(hcd);
-
- return rc;
-}
-
/* configure so an HC device and id are always provided */
/* always called with process context; sleeping is OK */
static struct hc_driver __read_mostly ehci_omap_hc_driver;
static const struct ehci_driver_overrides ehci_omap_overrides __initdata = {
- .reset = omap_ehci_init,
.extra_priv_size = sizeof(struct omap_hcd),
};
@@ -179,6 +159,7 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
hcd->regs = regs;
+ hcd_to_ehci(hcd)->caps = regs;
omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
omap->nports = pdata->nports;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 12/13] USB: ehci-omap: Fix detection in HSIC mode
Move PHY initialization until after EHCI initialization is
complete, instead of initializing the PHYs first, shutting
them down again, and then initializing them a second time.
This fixes HSIC device detection.
Signed-off-by: Roger Quadros
CC: Alan Stern
---
drivers/usb/host/ehci-omap.c | 32 +++-
1 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1ba1df8..755b428 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -90,26 +90,13 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
static int omap_ehci_init(struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- struct omap_hcd *omap = (struct omap_hcd *)ehci->priv;
- int rc, i;
-
- /* Hold PHYs in reset while initializing EHCI controller */
- for (i = 0; i < omap->nports; i++) {
- if (omap->phy[i])
- usb_phy_shutdown(omap->phy[i]);
- }
+ int rc;
/* we know this is the memory we want, no need to ioremap again */
ehci->caps = hcd->regs;
rc = ehci_setup(hcd);
- /* Bring PHYs out of reset */
- for (i = 0; i < omap->nports; i++) {
- if (omap->phy[i])
- usb_phy_init(omap->phy[i]);
- }
-
return rc;
}
@@ -219,9 +206,6 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
}
omap->phy[i] = phy;
- usb_phy_init(omap->phy[i]);
- /* bring PHY out of suspend */
- usb_phy_set_suspend(omap->phy[i], 0);
}
pm_runtime_enable(dev);
@@ -245,6 +229,20 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
goto err_pm_runtime;
}
+ /*
+* Bring PHYs out of reset.
+* Even though HSIC mode is a PHY-less mode, the reset
+* line exists between the chips and can be modelled
+* as a PHY device for reset control.
+*/
+ for (i = 0; i < omap->nports; i++) {
+ if (!omap->phy[i])
+ continue;
+
+ usb_phy_init(omap->phy[i]);
+ /* bring PHY out of suspend */
+ usb_phy_set_suspend(omap->phy[i], 0);
+ }
return 0;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: phy: rename all phy drivers to phy-$name.c
On Wed, Mar 13, 2013 at 06:01:13PM +0530, Venu Byravarasu wrote: > > -Original Message- > > From: Felipe Balbi [mailto:ba...@ti.com] > > Sent: Friday, March 08, 2013 1:08 PM > > To: Venu Byravarasu > > Cc: Stephen Warren; Felipe Balbi; Linux USB Mailing List; Greg KH; linux- > > te...@vger.kernel.org; s.ha...@pengutronix.de; sachin.ka...@linaro.org; > > aletes@gmail.com; gautam.vi...@samsung.com; > > kuninori.morimoto...@renesas.com; p.pan...@samsung.com; > > sti...@antcom.de; t...@atomide.com; y...@marvell.com > > Subject: Re: [PATCH] usb: phy: rename all phy drivers to phy-$name.c > > > > * PGP Signed by an unknown key > > > > On Fri, Mar 08, 2013 at 12:51:13PM +0530, Venu Byravarasu wrote: > > > > -Original Message- > > > > From: linux-tegra-ow...@vger.kernel.org [mailto:linux-tegra- > > > > ow...@vger.kernel.org] On Behalf Of Stephen Warren > > > > Sent: Friday, March 08, 2013 2:07 AM > > > > To: Felipe Balbi; Venu Byravarasu > > > > Cc: Linux USB Mailing List; Greg KH; linux-te...@vger.kernel.org; > > > > s.ha...@pengutronix.de; sachin.ka...@linaro.org; > > aletes@gmail.com; > > > > gautam.vi...@samsung.com; kuninori.morimoto...@renesas.com; > > > > p.pan...@samsung.com; sti...@antcom.de; t...@atomide.com; > > > > y...@marvell.com > > > > Subject: Re: [PATCH] usb: phy: rename all phy drivers to phy-$name.c > > > > > > > > On 03/07/2013 08:45 AM, Felipe Balbi wrote: > > > > > this will make sure that we have sensible names > > > > > for all phy drivers. Current situation was already > > > > > quite bad with too generic names being used. > > > > > > > > Is phy-$name specific enough? There are other types of PHY such as > > > > Ethernet, etc. What about phy-usb-$name? > > > > > > > > Venu, please comment on what conflicts, if any, this will cause with the > > > > patches you'll be sending to clean up the Tegra USB/PHY drivers. Thanks. > > > > > > As this is just a name change, it should not cause any big issues, other > > > than > > porting > > > all changes on top of this new file. > > > > > > Felipe, > > > When can we expect these changes getting merged into linux-next? > > > > After -rc2 is tagged, I will have everything I need to start my -next > > branch. From that point on it should be in linux-next ;-) > > As your change is not yet merged, can you plz exclude Tegra USB PHY > driver renaming alone from your patch, as my patches are almost ready > on top of current linux-next code base? > If you are OK, I can push the renaming patch as part of my last patch, > so that manual merge on top of new file can be avoided and your target > of changing file names also will be served. git can handle the rename just fine. Besides the merge conflicts will be easy to solve. I don't think it's necessary to drop the patch from my tree. -- balbi signature.asc Description: Digital signature
RE: [PATCH] usb: phy: rename all phy drivers to phy-$name.c
> -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Friday, March 08, 2013 1:08 PM > To: Venu Byravarasu > Cc: Stephen Warren; Felipe Balbi; Linux USB Mailing List; Greg KH; linux- > te...@vger.kernel.org; s.ha...@pengutronix.de; sachin.ka...@linaro.org; > aletes@gmail.com; gautam.vi...@samsung.com; > kuninori.morimoto...@renesas.com; p.pan...@samsung.com; > sti...@antcom.de; t...@atomide.com; y...@marvell.com > Subject: Re: [PATCH] usb: phy: rename all phy drivers to phy-$name.c > > * PGP Signed by an unknown key > > On Fri, Mar 08, 2013 at 12:51:13PM +0530, Venu Byravarasu wrote: > > > -Original Message- > > > From: linux-tegra-ow...@vger.kernel.org [mailto:linux-tegra- > > > ow...@vger.kernel.org] On Behalf Of Stephen Warren > > > Sent: Friday, March 08, 2013 2:07 AM > > > To: Felipe Balbi; Venu Byravarasu > > > Cc: Linux USB Mailing List; Greg KH; linux-te...@vger.kernel.org; > > > s.ha...@pengutronix.de; sachin.ka...@linaro.org; > aletes@gmail.com; > > > gautam.vi...@samsung.com; kuninori.morimoto...@renesas.com; > > > p.pan...@samsung.com; sti...@antcom.de; t...@atomide.com; > > > y...@marvell.com > > > Subject: Re: [PATCH] usb: phy: rename all phy drivers to phy-$name.c > > > > > > On 03/07/2013 08:45 AM, Felipe Balbi wrote: > > > > this will make sure that we have sensible names > > > > for all phy drivers. Current situation was already > > > > quite bad with too generic names being used. > > > > > > Is phy-$name specific enough? There are other types of PHY such as > > > Ethernet, etc. What about phy-usb-$name? > > > > > > Venu, please comment on what conflicts, if any, this will cause with the > > > patches you'll be sending to clean up the Tegra USB/PHY drivers. Thanks. > > > > As this is just a name change, it should not cause any big issues, other > > than > porting > > all changes on top of this new file. > > > > Felipe, > > When can we expect these changes getting merged into linux-next? > > After -rc2 is tagged, I will have everything I need to start my -next > branch. From that point on it should be in linux-next ;-) As your change is not yet merged, can you plz exclude Tegra USB PHY driver renaming alone from your patch, as my patches are almost ready on top of current linux-next code base? If you are OK, I can push the renaming patch as part of my last patch, so that manual merge on top of new file can be avoided and your target of changing file names also will be served. > > -- > balbi > > * Unknown Key > * 0x35CAA444 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net,stable-3.8] net: qmi_wwan: set correct altsetting for Gobi 1K devices
commit bd877e4 ("net: qmi_wwan: use a single bind function for
all device types") made Gobi 1K devices fail probing.
Using the number of endpoints in the default altsetting to decide
whether the function use one or two interfaces is wrong. Other
altsettings may provide more endpoints.
With Gobi 1K devices, USB interface #3's altsetting is 0 by default, but
altsetting 0 only provides one interrupt endpoint and is not sufficent
for QMI. Altsetting 1 provides all 3 endpoints required for qmi_wwan
and works with QMI. Gobi 1K layout for intf#3 is:
Interface Descriptor: 255/255/255
bInterfaceNumber3
bAlternateSetting 0
Endpoint Descriptor: Interrupt IN
Interface Descriptor: 255/255/255
bInterfaceNumber3
bAlternateSetting 1
Endpoint Descriptor: Interrupt IN
Endpoint Descriptor: Bulk IN
Endpoint Descriptor: Bulk OUT
Prior to commit bd877e4, we would call usbnet_get_endpoints
before giving up finding enough endpoints. Removing the early
endpoint number test and the strict functional descriptor
requirement allow qmi_wwan_bind to continue until
usbnet_get_endpoints has made the final attempt to collect
endpoints. This restores the behaviour from before commit
bd877e4 without losing the added benefit of using a single bind
function.
The driver has always required a CDC Union functional descriptor
for two-interface functions. Using the existence of this
descriptor to detect two-interface functions is the logically
correct method.
Reported-by: Dan Williams
Signed-off-by: Bjørn Mork
---
Dan,
could you test this on a Gobi 1K device? It should fix the problem,
but I'd like to verify my assumptions for once :)
This needs to go to stable-3.8 as well.
Bjørn
drivers/net/usb/qmi_wwan.c | 49 +++-
1 file changed, 16 insertions(+), 33 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index efb5c7c..968d5d5 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -139,16 +139,9 @@ static int qmi_wwan_bind(struct usbnet *dev, struct
usb_interface *intf)
BUILD_BUG_ON((sizeof(((struct usbnet *)0)->data) < sizeof(struct
qmi_wwan_state)));
- /* control and data is shared? */
- if (intf->cur_altsetting->desc.bNumEndpoints == 3) {
- info->control = intf;
- info->data = intf;
- goto shared;
- }
-
- /* else require a single interrupt status endpoint on control intf */
- if (intf->cur_altsetting->desc.bNumEndpoints != 1)
- goto err;
+ /* set up initial state */
+ info->control = intf;
+ info->data = intf;
/* and a number of CDC descriptors */
while (len > 3) {
@@ -207,25 +200,14 @@ next_desc:
buf += h->bLength;
}
- /* did we find all the required ones? */
- if (!(found & (1 << USB_CDC_HEADER_TYPE)) ||
- !(found & (1 << USB_CDC_UNION_TYPE))) {
- dev_err(&intf->dev, "CDC functional descriptors missing\n");
- goto err;
- }
-
- /* verify CDC Union */
- if (desc->bInterfaceNumber != cdc_union->bMasterInterface0) {
- dev_err(&intf->dev, "bogus CDC Union: master=%u\n",
cdc_union->bMasterInterface0);
- goto err;
- }
-
- /* need to save these for unbind */
- info->control = intf;
- info->data = usb_ifnum_to_if(dev->udev, cdc_union->bSlaveInterface0);
- if (!info->data) {
- dev_err(&intf->dev, "bogus CDC Union: slave=%u\n",
cdc_union->bSlaveInterface0);
- goto err;
+ /* Use separate control and data interfaces if we found a CDC Union */
+ if (cdc_union) {
+ info->data = usb_ifnum_to_if(dev->udev,
cdc_union->bSlaveInterface0);
+ if (desc->bInterfaceNumber != cdc_union->bMasterInterface0 ||
!info->data) {
+ dev_err(&intf->dev, "bogus CDC Union: master=%u,
slave=%u\n",
+ cdc_union->bMasterInterface0,
cdc_union->bSlaveInterface0);
+ goto err;
+ }
}
/* errors aren't fatal - we can live with the dynamic address */
@@ -235,11 +217,12 @@ next_desc:
}
/* claim data interface and set it up */
- status = usb_driver_claim_interface(driver, info->data, dev);
- if (status < 0)
- goto err;
+ if (info->control != info->data) {
+ status = usb_driver_claim_interface(driver, info->data, dev);
+ if (status < 0)
+ goto err;
+ }
-shared:
status = qmi_wwan_register_subdriver(dev);
if (status < 0 && info->control != info->data) {
usb_set_intfdata(info->data, NULL);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to m
Re: PROBLEM: since linux kernel 3.8 Apple Cinema Display's usb hub spits errors randomly at boot.
On Tuesday 12 March 2013 13:29:17 Alan Stern wrote: > On Tue, 12 Mar 2013, Jenya Y wrote: > > > I'll try to work out a patch in the next few days. Can you recreate > > > the arrangement where all the errors occurred, in order to test the > > > patch when it is ready? > > > > > > Alan Stern > > > > Absolutely, I'd be glad to help. > > > > Just tell me what kernel should I use to apply your patch and I'll > > prepare the env to test it. > > Here is a patch for you to test. It should apply to any of the 3.8.y > kernels. > > Alan Stern > Alan, I'm a bit late with my report, sorry. Here how it went. I did fresh rebuild of 3.8.2 kernel with my previous settings (where all of the mentioned flags were set as 'm') restarted to check the errors - they were there (-71). Then I went back and applied your patch and this time I got something else __ Mar 13 13:33:10 Y8 kernel: usb 1-2.2: can't set config #1, error -19 Mar 13 13:33:10 Y8 dbus-daemon[231]: dbus[231]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service' Mar 13 13:33:10 Y8 kernel: usb 1-2.2: USB disconnect, device number 3 Mar 13 13:33:10 Y8 kernel: usb 2-1: USB disconnect, device number 2 Mar 13 13:33:10 Y8 kernel: usb 2-2: USB disconnect, device number 3 Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: hub_port_status failed (err = -19) Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: cannot disable port 2 (err = -19) Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: cannot reset port 2 (err = -19) Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: cannot disable port 2 (err = -19) Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: cannot reset port 2 (err = -19) Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: cannot disable port 2 (err = -19) Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: cannot reset port 2 (err = -19) Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: cannot disable port 2 (err = -19) Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: unable to enumerate USB device on port 2 Mar 13 13:33:10 Y8 kernel: hub 2-2:1.0: cannot disable port 2 (err = -19) Mar 13 13:33:10 Y8 kernel: usb 4-1: USB disconnect, device number 2 Mar 13 13:33:10 Y8 kernel: usb 4-1.3: new full-speed USB device number 3 using uhci_hcd Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot reset port 3 (err = -19) Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot disable port 3 (err = -19) Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot reset port 3 (err = -19) Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot disable port 3 (err = -19) Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot reset port 3 (err = -19) Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot disable port 3 (err = -19) Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot reset port 3 (err = -19) Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot disable port 3 (err = -19) Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: unable to enumerate USB device on port 3 Mar 13 13:33:10 Y8 kernel: hub 4-1:1.0: cannot disable port 3 (err = -19) ___ Not sure if it's better or worse but that's where we are right now. :) So I'm back to 3.9 where everything works beatifully (well, almost) I think I should mention that one thing has chnaged in my installation. I've updated my systemd to 198, but it had no negative effects on 3.9 Let me know if I should try something else. PS I have friend who accidentally also had usb issues with 3.8.2 on nvidia chipsets and I took the liberty to send him your patch. It worked for himthought It cheer you up a little :) // Jenya -- 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 12/12] USB: ehci-omap: Fix detection in HSIC mode
On 03/12/2013 06:07 PM, Alan Stern wrote:
> On Tue, 12 Mar 2013, Roger Quadros wrote:
>
>> The HSIC devices need to be kept in reset while the EHCI controller
>> is being initialized and only brought out of reset after the
>> initialization is complete, else HSIC devices will not be detected.
>
> This is not a great description of what the patch does. You should say
> that it moves PHY initialization until after EHCI initialization is
> complete, instead of initializing the PHYs first, shutting them down
> again, and then initializing them a second time.
>
Okay will update the description.
>> Also remove outdated TODO list from header.
>>
>> Signed-off-by: Roger Quadros
>> CC: Alan Stern
>> ---
>> drivers/usb/host/ehci-omap.c | 38 +++---
>> 1 files changed, 15 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
>> index 1ba1df8..dc2de47 100644
>> --- a/drivers/usb/host/ehci-omap.c
>> +++ b/drivers/usb/host/ehci-omap.c
>> @@ -29,12 +29,6 @@
>> * along with this program; if not, write to the Free Software
>> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
>> *
>> - * TODO (last updated Feb 27, 2010):
>> - * - add kernel-doc
>> - * - enable AUTOIDLE
>> - * - add suspend/resume
>> - * - add HSIC and TLL support
>> - * - convert to use hwmod and runtime PM
>> */
>>
>> #include
>> @@ -90,26 +84,13 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
>> static int omap_ehci_init(struct usb_hcd *hcd)
>> {
>> struct ehci_hcd *ehci = hcd_to_ehci(hcd);
>> -struct omap_hcd *omap = (struct omap_hcd *)ehci->priv;
>> -int rc, i;
>> -
>> -/* Hold PHYs in reset while initializing EHCI controller */
>> -for (i = 0; i < omap->nports; i++) {
>> -if (omap->phy[i])
>> -usb_phy_shutdown(omap->phy[i]);
>> -}
>> +int rc;
>>
>> /* we know this is the memory we want, no need to ioremap again */
>> ehci->caps = hcd->regs;
>>
>> rc = ehci_setup(hcd);
>>
>> -/* Bring PHYs out of reset */
>> -for (i = 0; i < omap->nports; i++) {
>> -if (omap->phy[i])
>> -usb_phy_init(omap->phy[i]);
>> -}
>> -
>> return rc;
>> }
>
> Now that there's almost nothing left of this function, you can get rid
> of it completely. Move the assignment to ehci->caps into
> ehci_hcd_omap_probe() and remove the init entry in the overrides
> structure.
Right. Sounds good.
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 v6 0/2] Adding USB 3.0 DRD-phy support for exynos5250
On Wed, Mar 13, 2013 at 03:41:15PM +0530, Vivek Gautam wrote: > Hi Felipe, > > > On Wed, Feb 27, 2013 at 8:13 PM, Vivek Gautam > wrote: > > Based on 'usb-next' > > > > Changes from v5: > > - Squashed the following change from Felipe in this patch-set: > >[PATCH] usb: phy: samsung: let it be built as a module > > - Using EXPORT_SYMBOL_GPL() to export symbols in "samsung-usbphy.c" > >to allow module builds of these samsung PHY drivers. > > > > Vivek Gautam (2): > > usb: phy: samsung: Common out the generic stuff > > usb: phy: samsung: Add PHY support for USB 3.0 controller > > > > I am rebasing this pach-set on top of your PHY driver changes in > 'testing' branch of your tree. > I took first 194 patches ;) from top of testing branch (i could find > these on top of 3.9 rc2 merge), > and applied the same on 'usb-next' branch in my development tree in > order to test further. > > I shall be posting these rebased patch-set, so that it will be easier > for you to merge the changes in. > Is there something you want to point out to me while i do this ? nothing to point out as of now :-) Thanks a lot. -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 0/2] Adding USB 3.0 DRD-phy support for exynos5250
Hi Felipe, On Wed, Feb 27, 2013 at 8:13 PM, Vivek Gautam wrote: > Based on 'usb-next' > > Changes from v5: > - Squashed the following change from Felipe in this patch-set: >[PATCH] usb: phy: samsung: let it be built as a module > - Using EXPORT_SYMBOL_GPL() to export symbols in "samsung-usbphy.c" >to allow module builds of these samsung PHY drivers. > > Vivek Gautam (2): > usb: phy: samsung: Common out the generic stuff > usb: phy: samsung: Add PHY support for USB 3.0 controller > I am rebasing this pach-set on top of your PHY driver changes in 'testing' branch of your tree. I took first 194 patches ;) from top of testing branch (i could find these on top of 3.9 rc2 merge), and applied the same on 'usb-next' branch in my development tree in order to test further. I shall be posting these rebased patch-set, so that it will be easier for you to merge the changes in. Is there something you want to point out to me while i do this ? > drivers/usb/phy/Kconfig | 25 +- > drivers/usb/phy/Makefile |2 + > drivers/usb/phy/samsung-usb2phy.c | 511 ++ > drivers/usb/phy/samsung-usb3phy.c | 349 ++ > drivers/usb/phy/samsung-usbphy.c | 722 > + > drivers/usb/phy/samsung-usbphy.h | 328 + > 6 files changed, 1224 insertions(+), 713 deletions(-) > create mode 100644 drivers/usb/phy/samsung-usb2phy.c > create mode 100644 drivers/usb/phy/samsung-usb3phy.c > create mode 100644 drivers/usb/phy/samsung-usbphy.h > > -- > 1.7.6.5 > > ___ > devicetree-discuss mailing list > devicetree-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss -- Thanks & Regards Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/usb/gadget: beautify code, delete unused code
Hello Felipe Balbi: I have communicate with related member of net2272 and net2280. net2272 and net2280 belong to PLX Tech Corporation. they say: "PLX is not longer maintain these drivers". (it means: they can not help us to test this patch). please see the FWD mail at the bottom for more details. next: I want to broadcast our test demand within linux-ker...@vger.kernel.org. is it suitable to do it ? if it is suitable: the next work flow is: I will write a [Cooperation] patch. and then send it to you (just reply this mail) to get a check. and send to linux-ker...@vger.kernel.org, after pass checking. is it ok ? thanks. 原始消息 主题: Case 00015189: [Consult] about net2280 and net2272 driver for Linux 日期: Wed, 13 Mar 2013 09:28:16 + (GMT) 发件人: Chen Lucas 收件人: gang.c...@asianux.com Dear Chen, PLX is not longer maintain these drivers. Thank you, Chen Lucas PLX Technology Inc Your comment: excuse me to bother you. I am a developer of Linux public kernel (upstream kernel). does PLX Techology still maintain net2280 and net2272 drivers under Linux ? we find an issue about net2280 and net2272 drivers for Linux public kernel. and we have found root cause, but have no related hardware to have a test. if these drivers are still maintained: could you provide information of related members (e.g. e-mail) ? can we fix the issue with the aid of them (mainly for a test). thanks. Related information: Linux public kernel: link:http://en.wikipedia.org/wiki/Linux_kernel summary: an open source operating system. Linux kernel mailing list: link:http://vger.kernel.org/ summary: include most of important members (e.g. Linus Torvalds) the main mail list is linux-ker...@vger.kernel.org usb related mail list is linux-usb@vger.kernel.org net2280 and net2272 issue: first mail: http://www.spinics.net/lists/linux-usb/msg80878.html root cause: http://www.spinics.net/lists/linux-usb/msg81071.html need test: http://www.spinics.net/lists/linux-usb/msg81599.html last mail: http://www.spinics.net/lists/linux-usb/msg81600.html Regards -- 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/9] USB: add devicetree helpers for determining dr_mode and phy_type
On Mon, Feb 04, 2013 at 02:24:29PM +0100, Sascha Hauer wrote:
> From: Michael Grzeschik
>
> This adds two little devicetree helper functions for determining the
> dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
> the devicetree.
>
> Signed-off-by: Michael Grzeschik
> Signed-off-by: Marc Kleine-Budde
> Signed-off-by: Sascha Hauer
> ---
> drivers/usb/phy/Makefile |1 +
> drivers/usb/phy/of.c | 47
> ++
> drivers/usb/usb-common.c | 36 +++
> include/linux/usb/of.h | 27 ++
> include/linux/usb/otg.h |7 +++
> include/linux/usb/phy.h |9 +
> 6 files changed, 127 insertions(+)
> create mode 100644 drivers/usb/phy/of.c
> create mode 100644 include/linux/usb/of.h
>
> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> index 9fa6327..e1be1e8 100644
> --- a/drivers/usb/phy/Makefile
> +++ b/drivers/usb/phy/Makefile
> @@ -5,6 +5,7 @@
> ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
>
> obj-$(CONFIG_USB_OTG_UTILS) += phy.o
> +obj-$(CONFIG_OF) += of.o
> obj-$(CONFIG_OMAP_USB2) += omap-usb2.o
> obj-$(CONFIG_OMAP_USB3) += omap-usb3.o
> obj-$(CONFIG_OMAP_CONTROL_USB) += omap-control-usb.o
> diff --git a/drivers/usb/phy/of.c b/drivers/usb/phy/of.c
> new file mode 100644
> index 000..e6f3b74
> --- /dev/null
> +++ b/drivers/usb/phy/of.c
> @@ -0,0 +1,47 @@
> +/*
> + * USB of helper code
> + *
> + * 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static const char *usbphy_modes[] = {
> + [USBPHY_INTERFACE_MODE_UNKNOWN] = "",
> + [USBPHY_INTERFACE_MODE_UTMI]= "utmi",
> + [USBPHY_INTERFACE_MODE_UTMIW] = "utmi_wide",
> + [USBPHY_INTERFACE_MODE_ULPI]= "ulpi",
> + [USBPHY_INTERFACE_MODE_SERIAL] = "serial",
> + [USBPHY_INTERFACE_MODE_HSIC]= "hsic",
> +};
> +
> +/**
> + * of_usb_get_phy_mode - Get phy mode for given device_node
> + * @np: Pointer to the given device_node
> + *
> + * The function gets phy interface string from property 'phy_type',
> + * and returns the correspondig enum usb_phy_interface
> + */
> +enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np)
> +{
> + const char *phy_type;
> + int err, i;
> +
> + err = of_property_read_string(np, "phy_type", &phy_type);
> + if (err < 0)
> + return USBPHY_INTERFACE_MODE_UNKNOWN;
> +
> + for (i = 0; i < ARRAY_SIZE(usbphy_modes); i++)
> + if (!strcmp(phy_type, usbphy_modes[i]))
> + return i;
> +
> + return USBPHY_INTERFACE_MODE_UNKNOWN;
> +}
> +EXPORT_SYMBOL_GPL(of_usb_get_phy_mode);
> diff --git a/drivers/usb/usb-common.c b/drivers/usb/usb-common.c
> index d29503e..ad4d87d 100644
> --- a/drivers/usb/usb-common.c
> +++ b/drivers/usb/usb-common.c
> @@ -14,6 +14,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> const char *usb_speed_string(enum usb_device_speed speed)
> {
> @@ -32,4 +35,37 @@ const char *usb_speed_string(enum usb_device_speed speed)
> }
> EXPORT_SYMBOL_GPL(usb_speed_string);
>
> +#ifdef CONFIG_OF
> +static const char *usb_dr_modes[] = {
> + [USB_DR_MODE_UNKNOWN] = "",
> + [USB_DR_MODE_HOST] = "host",
> + [USB_DR_MODE_PERIPHERAL]= "peripheral",
> + [USB_DR_MODE_OTG] = "otg",
> +};
> +
> +/**
> + * of_usb_get_dr_mode - Get dual role mode for given device_node
> + * @np: Pointer to the given device_node
> + *
> + * The function gets phy interface string from property 'dr_mode',
> + * and returns the correspondig enum usb_dr_mode
> + */
> +enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np)
> +{
> + const char *dr_mode;
> + int err, i;
> +
> + err = of_property_read_string(np, "dr_mode", &dr_mode);
> + if (err < 0)
> + return USB_DR_MODE_UNKNOWN;
> +
> + for (i = 0; i < ARRAY_SIZE(usb_dr_modes); i++)
> + if (!strcmp(dr_mode, usb_dr_modes[i]))
> + return i;
> +
> + return USB_DR_MODE_UNKNOWN;
> +}
> +EXPORT_SYMBOL_GPL(of_usb_get_dr_mode);
> +#endif
> +
> MODULE_LICENSE("GPL");
> diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
> new file mode 100644
> index 000..4681a20
> --- /dev/null
> +++ b/include/linux/usb/of.h
> @@ -0,0 +1,27 @@
> +/*
> + * OF helpers for usb devices.
> + *
> + * This file is released under the GPLv2
> + */
> +
> +#ifndef __LINUX_USB_OF_H
> +#define __LINUX_USB_OF_H
> +
> +#include
Hi Michael,
When I use allmodconfig to build all usb module, I meet below
error. After ch
Re: [PATCH] usb: dwc3: Set DWC3 context's mode based on selected mode.
On Wed, Mar 13, 2013 at 2:44 PM, Felipe Balbi wrote: > On Wed, Mar 13, 2013 at 02:42:22PM +0530, Vivek Gautam wrote: >> Hi Balbi, >> >> >> On Sat, Mar 2, 2013 at 6:55 PM, Vivek Gautam >> wrote: >> > Now that machines may select the mode of working of DWC3 (HOST only, >> > GADGET only or DUAL_ROLE), lets set DWC3 mode based on that >> > rather than fixing it to whatever DWC3 hardware says. >> > This way we can skip initializing Gadget/Host in case >> > we are using Host-only/Gadget-only mode respectively. >> > >> >> Hope this patch if fine, and mainlinable ? > > yes, it's in my testing branch, you will receive mail soon > Sure, thanks. > -- > balbi -- Thanks & Regards Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: Set DWC3 context's mode based on selected mode.
On Wed, Mar 13, 2013 at 02:42:22PM +0530, Vivek Gautam wrote: > Hi Balbi, > > > On Sat, Mar 2, 2013 at 6:55 PM, Vivek Gautam wrote: > > Now that machines may select the mode of working of DWC3 (HOST only, > > GADGET only or DUAL_ROLE), lets set DWC3 mode based on that > > rather than fixing it to whatever DWC3 hardware says. > > This way we can skip initializing Gadget/Host in case > > we are using Host-only/Gadget-only mode respectively. > > > > Hope this patch if fine, and mainlinable ? yes, it's in my testing branch, you will receive mail soon -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: dwc3: Set DWC3 context's mode based on selected mode.
Hi Balbi,
On Sat, Mar 2, 2013 at 6:55 PM, Vivek Gautam wrote:
> Now that machines may select the mode of working of DWC3 (HOST only,
> GADGET only or DUAL_ROLE), lets set DWC3 mode based on that
> rather than fixing it to whatever DWC3 hardware says.
> This way we can skip initializing Gadget/Host in case
> we are using Host-only/Gadget-only mode respectively.
>
Hope this patch if fine, and mainlinable ?
> Signed-off-by: Vivek Gautam
> ---
>
> Changes from RFC patch "usb: dwc3: Set GCTL.PrtCapDir based on selected mode"
> - Setting the mode in dwc3 context structure based on
>selected mode in machine, rather than programming PrtCapDir
>
> drivers/usb/dwc3/core.c |7 ++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 79f335f..be0672f 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -478,7 +478,12 @@ static int dwc3_probe(struct platform_device *pdev)
> goto err1;
> }
>
> - mode = DWC3_MODE(dwc->hwparams.hwparams0);
> + if (IS_ENABLED(CONFIG_USB_DWC3_HOST))
> + mode = DWC3_MODE_HOST;
> + else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
> + mode = DWC3_MODE_DEVICE;
> + else
> + mode = DWC3_MODE_DRD;
>
> switch (mode) {
> case DWC3_MODE_DEVICE:
> --
> 1.7.6.5
>
> --
> 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/
--
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] ARM: dts: omap: Add dts data for USB
Benoit, Will you be queuing this patch series? Thanks Kishon On Thursday 07 March 2013 07:05 PM, Kishon Vijay Abraham I wrote: Hi Benoit, Here are the dt data patches to get usb device functional in OMAP platforms. All the patches deal with modifying arch/arm/boot except one which modifies Documentation/../usb/omap-usb.txt Changes from v2: * squashed the dt data for dwc3-omap with dwc3 core into a single patch. Changes from v1: Patch *ARM: dts: omap: Add usb_otg and glue data* has some properties with names that has "_". It's replaced with a "-" here. This patch is developed on Linux 3.9-rc1. Kishon Vijay Abraham I (7): 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 and 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(-) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v2] usb: gadget: u_serial: fix typo which cause build warning
fix typo error introduced by commit ea0e6276 (usb: gadget: add
multiple definition guards) which causes the following build warning:
warning: "pr_vdebug" redefined
Signed-off-by: Bo Shen
---
Change in v2:
reword commit message which make it more explicitly with commit id and subject
---
drivers/usb/gadget/u_serial.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/u_serial.c b/drivers/usb/gadget/u_serial.c
index c5034d9..b369292 100644
--- a/drivers/usb/gadget/u_serial.c
+++ b/drivers/usb/gadget/u_serial.c
@@ -136,7 +136,7 @@ static struct portmaster {
pr_debug(fmt, ##arg)
#endif /* pr_vdebug */
#else
-#ifndef pr_vdebig
+#ifndef pr_vdebug
#define pr_vdebug(fmt, arg...) \
({ if (0) pr_debug(fmt, ##arg); })
#endif /* pr_vdebug */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] usb: musb/otg: cleanup and fixes
This series has some misc cleanup and fixes. The fix solves the cold plug issue in omap3 which some have reported. Developed these patches on Linux 3.9-rc2 after applying http://www.spinics.net/lists/linux-usb/msg81563.html (Grazvydas Ignotas patch series) Tested for g_zero enumeration in pandaboard and beagleboard in both cold plug and hot plug case. Any kind of testing for this series is welcome. Kishon Vijay Abraham I (5): usb: musb: omap: remove the check before calling otg_set_vbus usb: musb: omap: always glue have the correct vbus/id status usb: otg: twl4030: use devres API for regulator get and request irq usb: musb: omap: add usb_phy_init in omap2430_musb_init usb: otg: twl4030: fix cold plug on OMAP3 drivers/usb/musb/omap2430.c | 22 ++ drivers/usb/otg/twl4030-usb.c | 35 --- 2 files changed, 22 insertions(+), 35 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
[PATCH 3/5] usb: otg: twl4030: use devres API for regulator get and request irq
Used devres APIs devm_request_threaded_irq and devm_regulator_get for
requesting irq and for getting regulator respectively.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/otg/twl4030-usb.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 04b732e2..5b20bb4 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -470,7 +470,7 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
/* Initialize 3.1V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB3V1_DEV_GRP);
- twl->usb3v1 = regulator_get(twl->dev, "usb3v1");
+ twl->usb3v1 = devm_regulator_get(twl->dev, "usb3v1");
if (IS_ERR(twl->usb3v1))
return -ENODEV;
@@ -479,18 +479,18 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
/* Initialize 1.5V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V5_DEV_GRP);
- twl->usb1v5 = regulator_get(twl->dev, "usb1v5");
+ twl->usb1v5 = devm_regulator_get(twl->dev, "usb1v5");
if (IS_ERR(twl->usb1v5))
- goto fail1;
+ return -ENODEV;
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V5_TYPE);
/* Initialize 1.8V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V8_DEV_GRP);
- twl->usb1v8 = regulator_get(twl->dev, "usb1v8");
+ twl->usb1v8 = devm_regulator_get(twl->dev, "usb1v8");
if (IS_ERR(twl->usb1v8))
- goto fail2;
+ return -ENODEV;
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V8_TYPE);
@@ -499,14 +499,6 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
TWL4030_PM_MASTER_PROTECT_KEY);
return 0;
-
-fail2:
- regulator_put(twl->usb1v5);
- twl->usb1v5 = NULL;
-fail1:
- regulator_put(twl->usb3v1);
- twl->usb3v1 = NULL;
- return -ENODEV;
}
static ssize_t twl4030_usb_vbus_show(struct device *dev,
@@ -695,9 +687,9 @@ static int twl4030_usb_probe(struct platform_device *pdev)
* need both handles, otherwise just one suffices.
*/
twl->irq_enabled = true;
- status = request_threaded_irq(twl->irq, NULL, twl4030_usb_irq,
- IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING |
- IRQF_ONESHOT, "twl4030_usb", twl);
+ status = devm_request_threaded_irq(twl->dev, twl->irq, NULL,
+ twl4030_usb_irq, IRQF_TRIGGER_FALLING |
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT, "twl4030_usb", twl);
if (status < 0) {
dev_dbg(&pdev->dev, "can't get IRQ %d, err %d\n",
twl->irq, status);
@@ -716,7 +708,6 @@ static int __exit twl4030_usb_remove(struct platform_device
*pdev)
int val;
cancel_delayed_work(&twl->id_workaround_work);
- free_irq(twl->irq, twl);
device_remove_file(twl->dev, &dev_attr_vbus);
/* set transceiver mode to power on defaults */
@@ -738,9 +729,6 @@ static int __exit twl4030_usb_remove(struct platform_device
*pdev)
if (!twl->asleep)
twl4030_phy_power(twl, 0);
- regulator_put(twl->usb1v5);
- regulator_put(twl->usb1v8);
- regulator_put(twl->usb3v1);
return 0;
}
--
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 4/5] usb: musb: omap: add usb_phy_init in omap2430_musb_init
Some PHYs load too early (twl4030) making omap glue to miss cable connect events if the board is booted with cable connected. So adding usb_phy_init in omap2430_musb_init lets PHYs to report events once glue is ready. Signed-off-by: Kishon Vijay Abraham I --- drivers/usb/musb/omap2430.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 28a0220..0786495 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -386,6 +386,8 @@ static int omap2430_musb_init(struct musb *musb) if (glue->status != OMAP_MUSB_UNKNOWN) omap_musb_set_mailbox(glue); + usb_phy_init(musb->xceiv); + pm_runtime_put_noidle(musb->controller); return 0; -- 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/5] usb: musb: omap: remove the check before calling otg_set_vbus
No functional change. otg_set_vbus is already protected so removed the
check before calling otg_set_vbus.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/musb/omap2430.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 558c1d6..78bfc50 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -174,8 +174,7 @@ static void omap2430_musb_set_vbus(struct musb *musb, int
is_on)
}
}
- if (otg->set_vbus)
- otg_set_vbus(otg, 1);
+ otg_set_vbus(otg, 1);
} else {
musb->is_active = 1;
otg->default_a = 1;
@@ -293,10 +292,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
}
omap2430_musb_set_vbus(musb, 0);
- if (data->interface_type == MUSB_INTERFACE_UTMI) {
- if (musb->xceiv->otg->set_vbus)
- otg_set_vbus(musb->xceiv->otg, 0);
- }
+ if (data->interface_type == MUSB_INTERFACE_UTMI)
+ otg_set_vbus(musb->xceiv->otg, 0);
omap_control_usb_set_mode(glue->control_otghs,
USB_MODE_DISCONNECT);
break;
--
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
