Re: [PATCH resend2] Input: usbtouchscreen - initialize eGalax devices
On Mon, Sep 03, 2012 at 01:33:50PM -0400, Forest Bond wrote:
From: Forest Bond forest.b...@rapidrollout.com
Certain eGalax devices expose an interface with class HID and protocol
None. Some work with usbhid and some work with usbtouchscreen, but
there is no easy way to differentiate. Sending an eGalax diagnostic
packet seems to kick them all into using the right protocol for
usbtouchscreen, so we can continue to bind them all there (as opposed to
handing some off to usbhid).
This fixes a regression for devices that were claimed by (and worked
with) usbhid prior to commit 139ebe8dc80dd74cb2ac9f5603d18fbf5cff049f
(Input: usbtouchscreen - fix eGalax HID ignoring), which made
usbtouchscreen claim them instead. With this patch they will still be
claimed by usbtouchscreen, but they will actually report events
usbtouchscreen can understand. Note that these devices will be limited
to the usbtouchscreen feature set so e.g. dual touch features are not
supported.
I have the distinct pleasure of needing to support devices of both types
and have tested accordingly.
Signed-off-by: Forest Bond forest.b...@rapidrollout.com
Applied, thank you Forest.
---
drivers/input/touchscreen/usbtouchscreen.c | 39
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/input/touchscreen/usbtouchscreen.c
b/drivers/input/touchscreen/usbtouchscreen.c
index e32709e..c5f4dc0 100644
--- a/drivers/input/touchscreen/usbtouchscreen.c
+++ b/drivers/input/touchscreen/usbtouchscreen.c
@@ -304,6 +304,44 @@ static int e2i_read_data(struct usbtouch_usb *dev,
unsigned char *pkt)
#define EGALAX_PKT_TYPE_REPT 0x80
#define EGALAX_PKT_TYPE_DIAG 0x0A
+static int egalax_init(struct usbtouch_usb *usbtouch)
+{
+ int ret, i;
+ unsigned char *buf;
+ struct usb_device *udev = interface_to_usbdev(usbtouch-interface);
+
+ /* An eGalax diagnostic packet kicks the device into using the right
+ * protocol. We send a check active packet. The response will be
+ * read later and ignored.
+ */
+
+ buf = kmalloc(3, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ buf[0] = EGALAX_PKT_TYPE_DIAG;
+ buf[1] = 1; /* length */
+ buf[2] = 'A'; /* command - check active */
+
+ for (i = 0; i 3; i++) {
+ ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+ 0,
+ USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ 0, 0, buf, 3,
+ USB_CTRL_SET_TIMEOUT);
+ if (ret = 0) {
+ ret = 0;
+ break;
+ }
+ if (ret != -EPIPE)
+ break;
+ }
+
+ kfree(buf);
+
+ return ret;
+}
+
static int egalax_read_data(struct usbtouch_usb *dev, unsigned char *pkt)
{
if ((pkt[0] EGALAX_PKT_TYPE_MASK) != EGALAX_PKT_TYPE_REPT)
@@ -1056,6 +1094,7 @@ static struct usbtouch_device_info usbtouch_dev_info[]
= {
.process_pkt= usbtouch_process_multi,
.get_pkt_len= egalax_get_pkt_len,
.read_data = egalax_read_data,
+ .init = egalax_init,
},
#endif
--
1.7.0.4
--
Dmitry
--
To unsubscribe from this list: send the line unsubscribe 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: FHCI: use list_move_tail instead of list_del/list_add_tail
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Using list_move_tail() instead of list_del() + list_add_tail().
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/usb/host/fhci-sched.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/fhci-sched.c b/drivers/usb/host/fhci-sched.c
index 2dc8a40..8f18538 100644
--- a/drivers/usb/host/fhci-sched.c
+++ b/drivers/usb/host/fhci-sched.c
@@ -261,8 +261,7 @@ static void move_head_to_tail(struct list_head *list)
struct list_head *node = list-next;
if (!list_empty(list)) {
- list_del(node);
- list_add_tail(node, list);
+ list_move_tail(node, list);
}
}
--
To unsubscribe from this list: send the line unsubscribe 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: add R-Car R8A7779 USB phy driver.
Hi,
On Wed, Sep 5, 2012 at 6:20 AM, Kuninori Morimoto
kuninori.morimoto...@renesas.com wrote:
Hi Abraham
Thank you for checking patch
+config USB_RCAR_PHY
+ tristate Renesas R-Car USB phy support
+ depends on (USB || USB_GADGET) ARCH_R8A7779
+ help
+ Say Y here to add support for the Renesas R-Car USB phy driver.
Just out of curiosity, which USB contoller will/is using this PHY?
EHCI/OHCI.
Now, I'm using ohci/ehci-platform.c
Thats a generic ehci driver. I was interested in the specific usb
controller that uses this phy. Anyways now I know its a host only
driver :-)
+ reg0 = ioremap_nocache(res0-start, resource_size(res0));
+ reg1 = ioremap_nocache(res1-start, resource_size(res1));
Instead use devm_ioremap_nocache?
will do in v2 patch
+ /* (1) USB-PHY standby release */
+ iowrite32(0x0001, (reg0 + USBPCTRL1));
Can we have some macros to define the above constant (and for the
constants used below)?
will do in v2 patch
+
+ /* (2) start USB-PHY internal PLL */
+ iowrite32(0x0003, (reg0 + USBPCTRL1));
No power management stuff added?? Dont we need to stop this PLL during
suspend??
(snip)
I see you are doing one time initialization of the phy during probe.
But I think this phy will be pointless without the usb controller.
Instead how about using the library functions like
usb_add_phy/usb_get_phy/usb_phy_init?
I'm not sure detail, but this usb_xxx_phy() is under otg.
Our system don't support it, but is it normal ?
Yeah. We are in the process of cleaning it up. Indeed it's normal in
the sense quite a few host only drivers use it (ehci-fsl.c,
ehci-msm.c, ehci-mv.c, ehci-tegra.c, ohci-omap.c).
Now, I'm using ehci/ohci-platform.
When I support this usb_xxx_phy(), do I need to customize these drivers ?
You can't change ehci-platform.c because thats a generic driver. But
you have to do those modifications in your controller specific file.
And, this is extra stuff, but I have 1 question.
it is ${LINUX}/driver/usb/Makefile's order.
obj-(xxx) += host/
...
obj-(xxx) += phy/
This means that usb phy driver probe function is called
after host driver probe function().
AFAIK, the order in Makefile will just determine the order in which in
the files are compiled and not the order in which the modules are
loaded/probed. The module loading/probing is dependent on which
*initcall* section you've added your module to and also based on
device creation.
However if two modules add themselves to the same *initcall* section,
the order in which the files are compiled determine the order in which
the modules are probed (I think this is what is happening in your
case).
Now, I'm using a technique which delays usb host driver registration,
but why phy driver is called after host driver ?
Does changing the order in Makefile helped you?
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: generic wireless mouse not working
On Tuesday 04 September 2012 20:01:33 Marco Biscaro wrote: Hello all, I've opened a bug report about a wireless mouse problem [1], and Greg Kroah-Hartman told me to post the link on this list. Could anyone take a look on the bug? The problem was originally reported in Launchpad [2], and there is a patch [3], proposed by draekko (the original downstream reporter, which is CC'd). Hi, we need a patch with a Signed-off-by line of the original autor as documented in Documentation/SubmittingPatches Thank you 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: [eBeam PATCH 2/2] input: misc: New USB eBeam input driver.
On Sunday 02 September 2012 00:52:03 Yann Cantin wrote:
Hi,
before we add yet another sysfs interface, we should ask whether calibration
isn't a problem that should be solved with a common API.
Regards
Oliver
+static ssize_t ebeam_calibrated_set(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t count)
+{
+ struct ebeam_device *ebeam = dev_get_drvdata(dev);
+ int err, c;
+
+ err = kstrtoint(buf, 10, c);
+ if (err)
+ return err;
+
+ if (c == 1) {
+ memcpy(ebeam-cursetting, ebeam-newsetting,
+ sizeof(struct ebeam_settings));
+ ebeam-calibrated = true;
+ ebeam_setup_input(ebeam, ebeam-input);
+ } else {
+ memcpy(ebeam-newsetting, ebeam-cursetting,
+ sizeof(struct ebeam_settings));
+ ebeam-calibrated = false;
+ ebeam_setup_input(ebeam, ebeam-input);
+ }
+
+ return count;
+}
+
+static DEVICE_ATTR(calibrated, S_IRUGO | S_IWUGO,
+ ebeam_calibrated_get, ebeam_calibrated_set);
+
+static struct attribute *ebeam_attrs[] = {
+ dev_attr_min_x.attr,
+ dev_attr_min_y.attr,
+ dev_attr_max_x.attr,
+ dev_attr_max_y.attr,
+ dev_attr_h1.attr,
+ dev_attr_h2.attr,
+ dev_attr_h3.attr,
+ dev_attr_h4.attr,
+ dev_attr_h5.attr,
+ dev_attr_h6.attr,
+ dev_attr_h7.attr,
+ dev_attr_h8.attr,
+ dev_attr_h9.attr,
+ dev_attr_calibrated.attr,
+ NULL
+};
+
--
- - -
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
16746 (AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
- - -
--
To unsubscribe from this list: send the line unsubscribe 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: add R-Car R8A7779 USB phy driver.
Hi Abraham EHCI/OHCI. Now, I'm using ohci/ehci-platform.c Thats a generic ehci driver. I was interested in the specific usb controller that uses this phy. Anyways now I know its a host only driver :-) (snip) Yeah. We are in the process of cleaning it up. Indeed it's normal in the sense quite a few host only drivers use it (ehci-fsl.c, ehci-msm.c, ehci-mv.c, ehci-tegra.c, ohci-omap.c). Now, I'm using ehci/ohci-platform. When I support this usb_xxx_phy(), do I need to customize these drivers ? You can't change ehci-platform.c because thats a generic driver. But you have to do those modifications in your controller specific file. OK. I see. However if two modules add themselves to the same *initcall* section, the order in which the files are compiled determine the order in which the modules are probed (I think this is what is happening in your case). Yes. exactly OK, I use subsys_initcall() for my phy 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 v3 0/5] usb: chipidea: fixes
Hello, this is a series fixes several problems in the chipidea udc driver. this applies to v3.6-rc4. These patches have been tested on mx28, mx53 and mx6q. Changes since v2: - reboase t v3.6-rc4 Changes since v1: - reworded patch description for fix setup of endpoint maxpacket size - added Acked-by and Reviewed-by - added cleanup dma_pool if udc_start() fails patch please review and consider to apply. regards, Marc -- To unsubscribe from this list: send the line unsubscribe 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 5/5] usb: chipidea: udc: don't stall endpoint if request list is empty in isr_tr_complete_low
From: Michael Grzeschik m.grzesc...@pengutronix.de
When attaching an imx28 or imx53 in USB gadget mode to a Windows host and
starting a rndis connection we see this message every 4-10 seconds:
g_ether gadget: high speed config #2: RNDIS
Analysis shows that each time this message is printed, the rndis connection is
re-establish due to a reset because of a stalled endpoint (ep 0, dir 1). The
endpoint is stalled because the reqeust complete bit on that endpoint is set,
but in isr_tr_complete_low() the endpoint request list (mEp-qh.queue) is
empty.
This patch removed this check, because the code doesn't take the following
situation into account:
The loop over all endpoints in isr_tr_complete_handler() will call ep_nuke() on
both ep0/dir0 and ep/dir1 in the first loop. Pending reqeusts will be flushed
and completed here. There seems to be a race condition, the request is nuked,
but the request complete bit will be set, too. The subsequent check (in
ep0/dir1's loop cycle) for endpoint request list (mEp-qh.queue) empty will
fail.
Both other mainline chipidea drivers (mv_udc_core.c and fsl_udc_core.c) don't
have this check.
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
---
drivers/usb/chipidea/udc.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 2d8b609..d214448 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -771,10 +771,7 @@ __acquires(mEp-lock)
{
struct ci13xxx_req *mReq, *mReqTemp;
struct ci13xxx_ep *mEpTemp = mEp;
- int uninitialized_var(retval);
-
- if (list_empty(mEp-qh.queue))
- return -EINVAL;
+ int retval = 0;
list_for_each_entry_safe(mReq, mReqTemp, mEp-qh.queue,
queue) {
--
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 v3 2/5] usb: chipidea: udc: add pullup fuction, needed by the uvc gadget
From: Michael Grzeschik m.grzesc...@pengutronix.de
Add function to physicaly enable or disable of pullup connection on the USB-D+
line. The uvc gaget will fail, if this function is not implemented.
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/usb/chipidea/udc.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 7801a3f..32ee870 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -78,8 +78,7 @@ static inline int ep_to_bit(struct ci13xxx *ci, int n)
}
/**
- * hw_device_state: enables/disables interrupts starts/stops device (execute
- * without interruption)
+ * hw_device_state: enables/disables interrupts (execute without interruption)
* @dma: 0 = disable, !0 = enable and set dma engine
*
* This function returns an error code
@@ -91,9 +90,7 @@ static int hw_device_state(struct ci13xxx *ci, u32 dma)
/* interrupt, error, port change, reset, sleep/suspend */
hw_write(ci, OP_USBINTR, ~0,
USBi_UI|USBi_UEI|USBi_PCI|USBi_URI|USBi_SLI);
- hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
} else {
- hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
hw_write(ci, OP_USBINTR, ~0, 0);
}
return 0;
@@ -1420,6 +1417,21 @@ static int ci13xxx_vbus_draw(struct usb_gadget *_gadget,
unsigned mA)
return -ENOTSUPP;
}
+/* Change Data+ pullup status
+ * this func is used by usb_gadget_connect/disconnet
+ */
+static int ci13xxx_pullup(struct usb_gadget *_gadget, int is_on)
+{
+ struct ci13xxx *ci = container_of(_gadget, struct ci13xxx, gadget);
+
+ if (is_on)
+ hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
+ else
+ hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
+
+ return 0;
+}
+
static int ci13xxx_start(struct usb_gadget *gadget,
struct usb_gadget_driver *driver);
static int ci13xxx_stop(struct usb_gadget *gadget,
@@ -1432,6 +1444,7 @@ static int ci13xxx_stop(struct usb_gadget *gadget,
static const struct usb_gadget_ops usb_gadget_ops = {
.vbus_session = ci13xxx_vbus_session,
.wakeup = ci13xxx_wakeup,
+ .pullup = ci13xxx_pullup,
.vbus_draw = ci13xxx_vbus_draw,
.udc_start = ci13xxx_start,
.udc_stop = ci13xxx_stop,
--
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 v3 4/5] usb: chipidea: cleanup dma_pool if udc_start() fails
If udc_start() fails the qh_pool dma-pool cannot be closed because
it's still in use. This patch factors out the dma_pool_free() loop
into destroy_eps() and calls it in the error path of udc_start(),
too.
Cc: Richard Zhao richard.z...@freescale.com
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
---
drivers/usb/chipidea/udc.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 3a755e5..2d8b609 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1503,6 +1503,17 @@ static int init_eps(struct ci13xxx *ci)
return retval;
}
+static void destroy_eps(struct ci13xxx *ci)
+{
+ int i;
+
+ for (i = 0; i ci-hw_ep_max; i++) {
+ struct ci13xxx_ep *mEp = ci-ci13xxx_ep[i];
+
+ dma_pool_free(ci-qh_pool, mEp-qh.ptr, mEp-qh.dma);
+ }
+}
+
/**
* ci13xxx_start: register a gadget driver
* @gadget: our gadget
@@ -1710,7 +1721,7 @@ static int udc_start(struct ci13xxx *ci)
if (ci-platdata-flags CI13XXX_REQUIRE_TRANSCEIVER) {
if (ci-transceiver == NULL) {
retval = -ENODEV;
- goto free_pools;
+ goto destroy_eps;
}
}
@@ -1761,6 +1772,8 @@ unreg_device:
put_transceiver:
if (!IS_ERR_OR_NULL(ci-transceiver) ci-global_phy)
usb_put_phy(ci-transceiver);
+destroy_eps:
+ destroy_eps(ci);
free_pools:
dma_pool_destroy(ci-td_pool);
free_qh_pool:
@@ -1775,18 +1788,12 @@ free_qh_pool:
*/
static void udc_stop(struct ci13xxx *ci)
{
- int i;
-
if (ci == NULL)
return;
usb_del_gadget_udc(ci-gadget);
- for (i = 0; i ci-hw_ep_max; i++) {
- struct ci13xxx_ep *mEp = ci-ci13xxx_ep[i];
-
- dma_pool_free(ci-qh_pool, mEp-qh.ptr, mEp-qh.dma);
- }
+ destroy_eps(ci);
dma_pool_destroy(ci-td_pool);
dma_pool_destroy(ci-qh_pool);
--
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 v3 1/5] usb: chipidea: udc: fix setup of endpoint maxpacket size
From: Michael Grzeschik m.grzesc...@pengutronix.de This patch changes the setup of the endpoint maxpacket size. All non control endpoints are initialized with an undefined ((unsigned short)~0) maxpacket size. The maxpacket size of Endpoint 0 will be kept at CTRL_PAYLOAD_MAX. Some gadget drivers check for the maxpacket size before they enable the endpoint, which leads to a wrong state in these drivers. Cc: sta...@vger.kernel.org Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de Signed-off-by: Marc Kleine-Budde m...@pengutronix.de Acked-by: Felipe Balbi ba...@ti.com --- changes since v1: - reworded patch description - Added Felipe's Ack drivers/usb/chipidea/udc.c |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c index c7a032a..7801a3f 100644 --- a/drivers/usb/chipidea/udc.c +++ b/drivers/usb/chipidea/udc.c @@ -1455,7 +1455,12 @@ static int init_eps(struct ci13xxx *ci) mEp-ep.name = mEp-name; mEp-ep.ops = usb_ep_ops; - mEp-ep.maxpacket = CTRL_PAYLOAD_MAX; + /* +* for ep0: maxP defined in desc, for other +* eps, maxP is set by epautoconfig() called +* by gadget layer +*/ + mEp-ep.maxpacket = (unsigned short)~0; INIT_LIST_HEAD(mEp-qh.queue); mEp-qh.ptr = dma_pool_alloc(ci-qh_pool, GFP_KERNEL, @@ -1475,6 +1480,7 @@ static int init_eps(struct ci13xxx *ci) else ci-ep0in = mEp; + mEp-ep.maxpacket = CTRL_PAYLOAD_MAX; continue; } -- 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] usb: phy: add R-Car USB phy driver
This patch adds Renesas R-Car USB phy driver.
It supports R8A7779 chip at this point.
R-Car has some USB controllers, but has only one phy-initializer.
So, this driver is counting users.
Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
v1 - v2
- enable usb_phy_xxx()
- used subsys_initcall()
drivers/usb/phy/Kconfig| 11 ++
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/rcar-phy.c | 241
3 files changed, 253 insertions(+)
create mode 100644 drivers/usb/phy/rcar-phy.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 2838adb..f55b6f6 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -23,3 +23,14 @@ config MV_U3D_PHY
help
Enable this to support Marvell USB 3.0 phy controller for Marvell
SoC.
+
+config USB_RCAR_PHY
+ tristate Renesas R-Car USB phy support
+ depends on (USB || USB_GADGET) ARCH_R8A7779
+ help
+ Say Y here to add support for the Renesas R-Car USB phy driver.
+ This chip is typically used as USB phy for USB host, gadget.
+ This driver supports: R8A7779
+
+ To compile this driver as a module, choose M here: the
+ module will be called rcar-phy.
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index cf38f08..9af83f0 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -6,3 +6,4 @@ ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
obj-$(CONFIG_USB_ISP1301) += isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
+obj-$(CONFIG_USB_RCAR_PHY) += rcar-phy.o
diff --git a/drivers/usb/phy/rcar-phy.c b/drivers/usb/phy/rcar-phy.c
new file mode 100644
index 000..2169a1a
--- /dev/null
+++ b/drivers/usb/phy/rcar-phy.c
@@ -0,0 +1,241 @@
+/*
+ * Renesas R-Car USB phy driver
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Kuninori Morimoto kuninori.morimoto...@renesas.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/io.h
+#include linux/usb/otg.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+#include linux/module.h
+
+/* 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
+
+#ifdef CONFIG_ARCH_SUPPORTS_BIG_ENDIAN
+# define PHY_ENDIAN BIG
+# define PHY_NO_SWAP 0x0003
+#else
+# define PHY_ENDIAN LITTLE
+# define PHY_NO_SWAP 0x
+#endif
+
+/* USBPCTRL1 */
+#define PHY_RST(1 2)
+#define PLL_ENB(1 1)
+#define PHY_ENB(1 0)
+
+/* USBST */
+#define ACT(1 31)
+#define PLL(1 30)
+
+struct rcar_usb_phy_priv {
+ struct usb_phy phy;
+ spinlock_t lock;
+
+ void __iomem *reg0;
+ void __iomem *reg1;
+ int counter;
+};
+
+#define usb_phy_to_priv(p) container_of(p, struct rcar_usb_phy_priv, phy)
+
+
+/*
+ * 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)
+{
+ struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
+ struct device *dev = phy-dev;
+ void __iomem *reg0 = priv-reg0;
+ void __iomem *reg1 = priv-reg1;
+ int i;
+ u32 val;
+ unsigned long flags;
+
+ / spin lock /
+ spin_lock_irqsave(priv-lock, flags);
+ if (0 == priv-counter) {
+
+ /**
+* USB phy start-up
+**/
+
+ /* (1) USB-PHY standby release */
+ iowrite32(PHY_ENB, (reg0 + USBPCTRL1));
+
+ /* (2) start USB-PHY internal PLL */
+ iowrite32(PHY_ENB | PLL_ENB, (reg0 + USBPCTRL1));
+
+ /* (3) USB module status check */
+ for (i = 0; i 1024; i++) {
+ udelay(10);
+ val = ioread32(reg0 + USBST);
+ if ((ACT | PLL) == val)
+ goto usb_module_is_working;
+ }
+ dev_err(dev, USB phy not ready\n);
+ return -EIO;
+
+usb_module_is_working:
+ /* (4) USB-PHY reset clear */
+ iowrite32(PHY_ENB | PLL_ENB | PHY_RST, (reg0 + USBPCTRL1));
+
+ /* set platform specific port settings */
+ iowrite32(0x, (reg0 + USBPCTRL0));
+
+ /**
+*
Re: [RFC PATCH V2 2/2] USB: Set usb port's DevicerRemovable according acpi information in EHCI
On 2012/9/5 0:15, Alan Stern wrote:
On Mon, 3 Sep 2012, Lan Tianyu wrote:
ACPI provide _PLD and _UPC aml methods to describe usb port
visibility and connectability. This patch is to use those information
to set usb port's DeviceRemovable.
Signed-off-by: Lan Tianyu tianyu@intel.com
---
v2: Set DeviceRemovable according acpi infomation in the hub_configure()
instead of calling get_hub_descriptor().
@@ -1566,6 +1566,25 @@ static int hub_configure(struct usb_hub *hub,
dev_err(hub-intfdev,
couldn't create port%d device.\n, i + 1);
+ if (hub_is_superspeed(hdev)) {
+ for (i = 1; i = hdev-maxchild; i++)
+ if (hub-ports[i - 1]-connect_type
+ == USB_PORT_CONNECT_TYPE_HARD_WIRED)
+ hub-descriptor-u.hs.DeviceRemovable[i/8]
+ |= 1 (i%8);
+ } else {
+ u16 port_removable = 0;
+
+ for (i = i; i = hdev-maxchild; i++)
+ if (hub-ports[i - 1]-connect_type
+ == USB_PORT_CONNECT_TYPE_HARD_WIRED)
+ port_removable |= 1 i;
+
+ memset(hub-descriptor-u.ss.DeviceRemovable,
+ (__force __u16) cpu_to_le16(port_removable),
+ sizeof(__u16));
Use put_unaligned_le16() instead of memset, if you're worried about
alignment.
This is copied from xhci_usb3_hub_descriptor().
struct usb_hub_descriptor {
__u8 bDescLength;
__u8 bDescriptorType;
__u8 bNbrPorts;
__le16 wHubCharacteristics;
__u8 bPwrOn2PwrGood;
__u8 bHubContrCurrent;
/* 2.0 and 3.0 hubs differ here */
union {
struct {
/* add 1 bit for hub status change; round to bytes */
__u8 DeviceRemovable[(USB_MAXCHILDREN + 1 + 7) / 8];
__u8 PortPwrCtrlMask[(USB_MAXCHILDREN + 1 + 7) / 8];
} __attribute__ ((packed)) hs;
struct {
__u8 bHubHdrDecLat;
__u16 wHubDelay;
__u16 DeviceRemovable;
} __attribute__ ((packed)) ss;
} u;
} __attribute__ ((packed));
The struct has been defined with __attribute__ ((packed)). So there is
no alignment problem. Or we can
hub-descriptor-u.ss.DeviceRemovable = (__force __u16)
cpu_to_le16(port_removable);
I think we also should define wHubDelay and DeviceRemovable as __le16
for ss since they are little-endian order, right?
This isn't right, because you overwrite information provided by the hub
with what ACPI says, even if ACPI doesn't say anything. You should
initialize port_removable to the original value of
u.ss.DeviceRemovable, not to 0.
OK. I get it.
Alan Stern
--
Best Regards
Tianyu Lan
linux kernel enabling team
--
To unsubscribe from this list: send the line unsubscribe 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: phy: add R-Car USB phy driver
On 09/05/2012 10:13 AM, Kuninori Morimoto wrote:
This patch adds Renesas R-Car USB phy driver.
It supports R8A7779 chip at this point.
R-Car has some USB controllers, but has only one phy-initializer.
So, this driver is counting users.
Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
v1 - v2
- enable usb_phy_xxx()
- used subsys_initcall()
drivers/usb/phy/Kconfig| 11 ++
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/rcar-phy.c | 241
3 files changed, 253 insertions(+)
create mode 100644 drivers/usb/phy/rcar-phy.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 2838adb..f55b6f6 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -23,3 +23,14 @@ config MV_U3D_PHY
help
Enable this to support Marvell USB 3.0 phy controller for Marvell
SoC.
+
+config USB_RCAR_PHY
+ tristate Renesas R-Car USB phy support
+ depends on (USB || USB_GADGET) ARCH_R8A7779
+ help
+ Say Y here to add support for the Renesas R-Car USB phy driver.
+ This chip is typically used as USB phy for USB host, gadget.
+ This driver supports: R8A7779
+
+ To compile this driver as a module, choose M here: the
+ module will be called rcar-phy.
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index cf38f08..9af83f0 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -6,3 +6,4 @@ ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
obj-$(CONFIG_USB_ISP1301)+= isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
+obj-$(CONFIG_USB_RCAR_PHY) += rcar-phy.o
diff --git a/drivers/usb/phy/rcar-phy.c b/drivers/usb/phy/rcar-phy.c
new file mode 100644
index 000..2169a1a
--- /dev/null
+++ b/drivers/usb/phy/rcar-phy.c
@@ -0,0 +1,241 @@
+/*
+ * Renesas R-Car USB phy driver
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Kuninori Morimoto kuninori.morimoto...@renesas.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/io.h
+#include linux/usb/otg.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+#include linux/module.h
+
+/* USBH common register */
+#define USBPCTRL00x0800
+#define USBPCTRL10x0804
+#define USBST0x0808
+#define USBEH0 0x080C
+#define USBOH0 0x081C
+#define USBCTL0 0x0858
+#define EIIBC1 0x0094
+#define EIIBC2 0x009C
+
+#ifdef CONFIG_ARCH_SUPPORTS_BIG_ENDIAN
+# define PHY_ENDIAN BIG
+# define PHY_NO_SWAP 0x0003
+#else
+# define PHY_ENDIAN LITTLE
+# define PHY_NO_SWAP 0x
+#endif
+
+/* USBPCTRL1 */
+#define PHY_RST (1 2)
+#define PLL_ENB (1 1)
+#define PHY_ENB (1 0)
+
+/* USBST */
+#define ACT (1 31)
+#define PLL (1 30)
+
+struct rcar_usb_phy_priv {
+ struct usb_phy phy;
+ spinlock_t lock;
+
+ void __iomem *reg0;
+ void __iomem *reg1;
+ int counter;
+};
+
+#define usb_phy_to_priv(p) container_of(p, struct rcar_usb_phy_priv, phy)
+
+
+/*
+ * 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)
+{
+ struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
+ struct device *dev = phy-dev;
+ void __iomem *reg0 = priv-reg0;
+ void __iomem *reg1 = priv-reg1;
+ int i;
+ u32 val;
+ unsigned long flags;
+
+ / spin lock /
+ spin_lock_irqsave(priv-lock, flags);
+ if (0 == priv-counter) {
+
+ /**
+ * USB phy start-up
+ **/
nitpick: unusual coding style
/*
* This is the preferred
* multi line style.
*/
+
+ /* (1) USB-PHY standby release */
+ iowrite32(PHY_ENB, (reg0 + USBPCTRL1));
+
+ /* (2) start USB-PHY internal PLL */
+ iowrite32(PHY_ENB | PLL_ENB, (reg0 + USBPCTRL1));
+
+ /* (3) USB module status check */
+ for (i = 0; i 1024; i++) {
+ udelay(10);
+ val = ioread32(reg0 + USBST);
+ if ((ACT | PLL) == val)
+ goto usb_module_is_working;
Don't use goto, unless in error handling.
+ }
+ dev_err(dev, USB phy not ready\n);
+ return -EIO;
You return with the spin_lock held.
+
+usb_module_is_working:
+ /* (4)
Re: [PATCH v2] usb: phy: add R-Car USB phy driver
Hi,
On Wed, Sep 5, 2012 at 2:01 PM, Marc Kleine-Budde m...@pengutronix.de wrote:
On 09/05/2012 10:13 AM, Kuninori Morimoto wrote:
This patch adds Renesas R-Car USB phy driver.
It supports R8A7779 chip at this point.
R-Car has some USB controllers, but has only one phy-initializer.
So, this driver is counting users.
Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
v1 - v2
- enable usb_phy_xxx()
- used subsys_initcall()
drivers/usb/phy/Kconfig| 11 ++
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/rcar-phy.c | 241
3 files changed, 253 insertions(+)
create mode 100644 drivers/usb/phy/rcar-phy.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 2838adb..f55b6f6 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -23,3 +23,14 @@ config MV_U3D_PHY
help
Enable this to support Marvell USB 3.0 phy controller for Marvell
SoC.
+
+config USB_RCAR_PHY
+ tristate Renesas R-Car USB phy support
+ depends on (USB || USB_GADGET) ARCH_R8A7779
+ help
+ Say Y here to add support for the Renesas R-Car USB phy driver.
+ This chip is typically used as USB phy for USB host, gadget.
+ This driver supports: R8A7779
+
+ To compile this driver as a module, choose M here: the
+ module will be called rcar-phy.
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index cf38f08..9af83f0 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -6,3 +6,4 @@ ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
obj-$(CONFIG_USB_ISP1301)+= isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
+obj-$(CONFIG_USB_RCAR_PHY) += rcar-phy.o
diff --git a/drivers/usb/phy/rcar-phy.c b/drivers/usb/phy/rcar-phy.c
new file mode 100644
index 000..2169a1a
--- /dev/null
+++ b/drivers/usb/phy/rcar-phy.c
@@ -0,0 +1,241 @@
+/*
+ * Renesas R-Car USB phy driver
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Kuninori Morimoto kuninori.morimoto...@renesas.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/io.h
+#include linux/usb/otg.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+#include linux/module.h
+
+/* USBH common register */
+#define USBPCTRL00x0800
+#define USBPCTRL10x0804
+#define USBST0x0808
+#define USBEH0 0x080C
+#define USBOH0 0x081C
+#define USBCTL0 0x0858
+#define EIIBC1 0x0094
+#define EIIBC2 0x009C
+
+#ifdef CONFIG_ARCH_SUPPORTS_BIG_ENDIAN
+# define PHY_ENDIAN BIG
+# define PHY_NO_SWAP 0x0003
+#else
+# define PHY_ENDIAN LITTLE
+# define PHY_NO_SWAP 0x
+#endif
+
+/* USBPCTRL1 */
+#define PHY_RST (1 2)
+#define PLL_ENB (1 1)
+#define PHY_ENB (1 0)
+
+/* USBST */
+#define ACT (1 31)
+#define PLL (1 30)
+
+struct rcar_usb_phy_priv {
+ struct usb_phy phy;
+ spinlock_t lock;
+
+ void __iomem *reg0;
+ void __iomem *reg1;
+ int counter;
+};
+
+#define usb_phy_to_priv(p) container_of(p, struct rcar_usb_phy_priv, phy)
+
+
+/*
+ * 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)
+{
+ struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
+ struct device *dev = phy-dev;
+ void __iomem *reg0 = priv-reg0;
+ void __iomem *reg1 = priv-reg1;
+ int i;
+ u32 val;
+ unsigned long flags;
+
+ / spin lock /
While at that, you can also remove the above comment and the *spin
unlocked* comment.
+ spin_lock_irqsave(priv-lock, flags);
+ if (0 == priv-counter) {
+
+ /**
+ * USB phy start-up
+ **/
nitpick: unusual coding style
/*
* This is the preferred
* multi line style.
*/
+
+ /* (1) USB-PHY standby release */
+ iowrite32(PHY_ENB, (reg0 + USBPCTRL1));
+
+ /* (2) start USB-PHY internal PLL */
+ iowrite32(PHY_ENB | PLL_ENB, (reg0 + USBPCTRL1));
+
+ /* (3) USB module status check */
+ for (i = 0; i 1024; i++) {
+ udelay(10);
+ val = ioread32(reg0 + USBST);
+ if ((ACT | PLL) == val)
+ goto usb_module_is_working;
Don't use goto, unless in error handling.
+ }
Re: [RFC] How to handle delays in isochronous transfers?
Alan Stern wrote: There are two possibilities to consider when an URB containing several packets of data is submitted: 1. The slots for the first few packets have already expired, but the remaining packets will be transferred okay. 2. The slots for all the packets in the URB have expired. In case 1 there is data loss but the queuing remains intact. In case 2 the queuing is broken. It sounds like you're saying that case 1 submissions should succeed (and return -EXDEV status for the statuses of the missed packets), whereas case 2 submissions should fail outright (say with an -EXDEV error, which is currently not used for URB submission). This wasn't exactly what I meant, but your proposal is turns out to be the only logical way of reporting errors when only some of the URB's packets fail. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] How to handle delays in isochronous transfers?
Alan Stern wrote: On Tue, 4 Sep 2012, Jassi Brar wrote: Second, people involved in real-time programming (such as audio or video) generally want to keep latency to a minimum. If we progress the h/w pointer of ALSA ring buffer at URB completion (and not at URB submission), I don't understand this comment. As far as I can tell, the relevant pointer already is being advanced during URB completion. It's advanced directly after submission. The queued data is double- buffered because the USB API lacks the ability to scatter/gather from a coherent buffer. this shouldn't affect the latency. How would this make any difference? The time between the application writing samples to the buffer and the samples actually being played by the device would not change. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: fsl_udc_core: remove mapped flag
Hello.
On 04-09-2012 21:24, Enrico Scholz wrote:
The 'mapped' flag in 'struct fsl_req' flag is redundant with checking
for 'req.dma != DMA_ADDR_INVALID' and it was also set to a wrong value
(see 2nd hunk of patch).
Replacing it in the way described above saves 60 bytes:
function old new delta
fsl_udc_irq 29522940 -12
ep0_prime_status 380 368 -12
done 448 432 -16
fsl_ep_queue 668 648 -20
and has same (or less) runtime costs like evaluating 'req-mapped'.
Signed-off-by: Enrico Scholz enrico.sch...@sigma-chemnitz.de
---
drivers/usb/gadget/fsl_udc_core.c | 10 ++
drivers/usb/gadget/fsl_usb2_udc.h | 1 -
2 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index 55c4a61..1282a11 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -195,14 +195,13 @@ static void done(struct fsl_ep *ep, struct fsl_req *req,
int status)
dma_pool_free(udc-td_pool, curr_td, curr_td-td_dma);
}
- if (req-mapped) {
+ if (req-req.dma != DMA_ADDR_INVALID) {
dma_unmap_single(ep-udc-gadget.dev.parent,
req-req.dma, req-req.length,
ep_is_in(ep)
? DMA_TO_DEVICE
: DMA_FROM_DEVICE);
req-req.dma = DMA_ADDR_INVALID;
- req-mapped = 0;
} else
dma_sync_single_for_cpu(ep-udc-gadget.dev.parent,
req-req.dma, req-req.length,
@@ -915,15 +914,12 @@ fsl_ep_queue(struct usb_ep *_ep, struct usb_request
*_req, gfp_t gfp_flags)
req-req.length, ep_is_in(ep)
? DMA_TO_DEVICE
: DMA_FROM_DEVICE);
- req-mapped = 1;
- } else {
+ } else
You should keep the { here, according to the Documentation/CodingStyle.
If one branch of the *if* statement uses {}, so should the other.
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: fsl_udc_core: remove mapped flag
Hi,
On Tue, Sep 04, 2012 at 07:24:59PM +0200, Enrico Scholz wrote:
The 'mapped' flag in 'struct fsl_req' flag is redundant with checking
for 'req.dma != DMA_ADDR_INVALID' and it was also set to a wrong value
you should not be using DMA_ADDR_INVALID anymore. Use the generic
map/unmap routines from udc-core.c
(see 2nd hunk of patch).
Replacing it in the way described above saves 60 bytes:
function old new delta
fsl_udc_irq 29522940 -12
ep0_prime_status 380 368 -12
done 448 432 -16
fsl_ep_queue 668 648 -20
and has same (or less) runtime costs like evaluating 'req-mapped'.
Signed-off-by: Enrico Scholz enrico.sch...@sigma-chemnitz.de
---
drivers/usb/gadget/fsl_udc_core.c | 10 ++
drivers/usb/gadget/fsl_usb2_udc.h | 1 -
2 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index 55c4a61..1282a11 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -195,14 +195,13 @@ static void done(struct fsl_ep *ep, struct fsl_req
*req, int status)
dma_pool_free(udc-td_pool, curr_td, curr_td-td_dma);
}
- if (req-mapped) {
+ if (req-req.dma != DMA_ADDR_INVALID) {
dma_unmap_single(ep-udc-gadget.dev.parent,
req-req.dma, req-req.length,
ep_is_in(ep)
? DMA_TO_DEVICE
: DMA_FROM_DEVICE);
req-req.dma = DMA_ADDR_INVALID;
- req-mapped = 0;
} else
dma_sync_single_for_cpu(ep-udc-gadget.dev.parent,
req-req.dma, req-req.length,
@@ -915,15 +914,12 @@ fsl_ep_queue(struct usb_ep *_ep, struct usb_request
*_req, gfp_t gfp_flags)
req-req.length, ep_is_in(ep)
? DMA_TO_DEVICE
: DMA_FROM_DEVICE);
- req-mapped = 1;
- } else {
+ } else
dma_sync_single_for_device(ep-udc-gadget.dev.parent,
req-req.dma, req-req.length,
ep_is_in(ep)
? DMA_TO_DEVICE
: DMA_FROM_DEVICE);
- req-mapped = 0;
- }
req-req.status = -EINPROGRESS;
req-req.actual = 0;
@@ -1306,7 +1302,6 @@ static int ep0_prime_status(struct fsl_udc *udc, int
direction)
req-req.dma = dma_map_single(ep-udc-gadget.dev.parent,
req-req.buf, req-req.length,
ep_is_in(ep) ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
- req-mapped = 1;
if (fsl_req_to_dtd(req, GFP_ATOMIC) == 0)
fsl_queue_td(ep, req);
@@ -1389,7 +1384,6 @@ static void ch9getstatus(struct fsl_udc *udc, u8
request_type, u16 value,
req-req.dma = dma_map_single(ep-udc-gadget.dev.parent,
req-req.buf, req-req.length,
ep_is_in(ep) ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
- req-mapped = 1;
/* prime the data phase */
if ((fsl_req_to_dtd(req, GFP_ATOMIC) == 0))
diff --git a/drivers/usb/gadget/fsl_usb2_udc.h
b/drivers/usb/gadget/fsl_usb2_udc.h
index fbd77ba..9aab166 100644
--- a/drivers/usb/gadget/fsl_usb2_udc.h
+++ b/drivers/usb/gadget/fsl_usb2_udc.h
@@ -436,7 +436,6 @@ struct fsl_req {
/* ep_queue() func will add
a request-queue into a udc_ep-queue 'd tail */
struct fsl_ep *ep;
- unsigned mapped:1;
struct ep_td_struct *head, *tail; /* For dTD List
cpu endian Virtual addr */
--
1.7.11.4
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH v2] usb: move phy driver from mach-tegra to drivers/usb
-Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Wednesday, September 05, 2012 3:19 AM To: ba...@ti.com Cc: Venu Byravarasu; ccr...@android.com; o...@lixom.net; li...@arm.linux.org.uk; st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; linux- te...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- u...@vger.kernel.org Subject: Re: [PATCH v2] usb: move phy driver from mach-tegra to drivers/usb On 08/31/2012 12:45 AM, Venu Byravarasu wrote: As part of this patch: 1. Moved existing tegra phy driver to drivers/USB directory. 2. Added standard USB phy driver APIs to tegra phy driver. Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com Felipe, Would it be possible to apply this patch to a topic branch, so that I can merge it into the Tegra tree? The reason is that I'd like to remove Tegra's devices.[ch] in kernel 3.7, but to do that, I need to move a tiny chunk of code out of that file somewhere else, and doing that relies on adding a #include to usb_phy.h/tegra_usb_phy.h, which is renamed in this patch. Alternatively, if you don't think it'll cause any merge conflicts with the USB PHY tree, I can just take this patch through the Tegra tree if you want. Venu, do you plan any other patches within the next couple weeks or so (i.e. before 3.6-rc6) that will depend on this patch? If so, taking it only through the Tegra tree might not work so well. Thanks Stephen for verifying the changes. I'm planning to push next patches, with tegra3 phy support added, very soon. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: move phy driver from mach-tegra to drivers/usb
Hi, On Wed, Sep 05, 2012 at 06:24:13PM +0530, Venu Byravarasu wrote: -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Wednesday, September 05, 2012 3:19 AM To: ba...@ti.com Cc: Venu Byravarasu; ccr...@android.com; o...@lixom.net; li...@arm.linux.org.uk; st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; linux- te...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- u...@vger.kernel.org Subject: Re: [PATCH v2] usb: move phy driver from mach-tegra to drivers/usb On 08/31/2012 12:45 AM, Venu Byravarasu wrote: As part of this patch: 1. Moved existing tegra phy driver to drivers/USB directory. 2. Added standard USB phy driver APIs to tegra phy driver. Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com Felipe, Would it be possible to apply this patch to a topic branch, so that I can merge it into the Tegra tree? The reason is that I'd like to remove Tegra's devices.[ch] in kernel 3.7, but to do that, I need to move a tiny chunk of code out of that file somewhere else, and doing that relies on adding a #include to usb_phy.h/tegra_usb_phy.h, which is renamed in this patch. Alternatively, if you don't think it'll cause any merge conflicts with the USB PHY tree, I can just take this patch through the Tegra tree if you want. Venu, do you plan any other patches within the next couple weeks or so (i.e. before 3.6-rc6) that will depend on this patch? If so, taking it only through the Tegra tree might not work so well. Thanks Stephen for verifying the changes. I'm planning to push next patches, with tegra3 phy support added, very soon. Unfortunately the patch didn't apply on my xceiv branch. Could you rebase on top of that ? thanks a lot -- balbi signature.asc Description: Digital signature
Re: usb: cdc-acm: remove duplicated include from cdc-acm.c
On Sunday 26 August 2012 09:44:45 Wei Yongjun wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn Remove duplicated include. Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Acked-by: Oliver Neukum oneu...@suse.de -- To unsubscribe from this list: send the line unsubscribe 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] xhci: Make handover code more robust
On Tue, Sep 04, 2012 at 03:40:56PM -0700, Sarah Sharp wrote: On Tue, Aug 14, 2012 at 04:44:49PM -0400, Matthew Garrett wrote: I've no idea what's causing the underlying problem, and xhci still doesn't actually *work* even with this, but the machine at least boots which will probably make further debugging easier. Is this an Ivy Bridge system? xHCI may not work because you're skipping the port switchover code just before the hc_init label. Of course, if the host controller continues to report all f's for register values, there's no point in trying to initialize the host at all... It's an SNB-E board with a series 7 chipset. The xHCI controller is an NEC. When it's in this failure state it doesn't seem like there's anything in the mmio BAR that's happy to talk to us, but I'll check the logs to see what xhci-hcd says. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe 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: move phy driver from mach-tegra to drivers/usb
Hi Felipe, -Original Message- From: Felipe Balbi [mailto:ba...@ti.com] Sent: Wednesday, September 05, 2012 6:22 PM To: Venu Byravarasu Cc: Stephen Warren; ba...@ti.com; ccr...@android.com; o...@lixom.net; li...@arm.linux.org.uk; st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; linux- te...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- u...@vger.kernel.org Subject: Re: [PATCH v2] usb: move phy driver from mach-tegra to drivers/usb * PGP Signed by an unknown key Hi, On Wed, Sep 05, 2012 at 06:24:13PM +0530, Venu Byravarasu wrote: -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Wednesday, September 05, 2012 3:19 AM To: ba...@ti.com Cc: Venu Byravarasu; ccr...@android.com; o...@lixom.net; li...@arm.linux.org.uk; st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; linux- te...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- u...@vger.kernel.org Subject: Re: [PATCH v2] usb: move phy driver from mach-tegra to drivers/usb On 08/31/2012 12:45 AM, Venu Byravarasu wrote: As part of this patch: 1. Moved existing tegra phy driver to drivers/USB directory. 2. Added standard USB phy driver APIs to tegra phy driver. Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com Felipe, Would it be possible to apply this patch to a topic branch, so that I can merge it into the Tegra tree? The reason is that I'd like to remove Tegra's devices.[ch] in kernel 3.7, but to do that, I need to move a tiny chunk of code out of that file somewhere else, and doing that relies on adding a #include to usb_phy.h/tegra_usb_phy.h, which is renamed in this patch. Alternatively, if you don't think it'll cause any merge conflicts with the USB PHY tree, I can just take this patch through the Tegra tree if you want. Venu, do you plan any other patches within the next couple weeks or so (i.e. before 3.6-rc6) that will depend on this patch? If so, taking it only through the Tegra tree might not work so well. Thanks Stephen for verifying the changes. I'm planning to push next patches, with tegra3 phy support added, very soon. Unfortunately the patch didn't apply on my xceiv branch. Could you rebase on top of that ? Rebased on to your branch and sent patch for your review. Plz review and merge. Thanks, Venu thanks a lot -- 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
Re: FTDI driver error from flowcontrol urb
On Wednesday, August 29, 2012 6:09:59 PM Greg KH wrote: On Sun, Aug 19, 2012 at 02:31:12PM +, Luke-Jr wrote: Also worth mentioning: the RMA replacement unit I have also exhibits this same problem, but neither of them do if I connect the same devices to an old Ubuntu netbook (2.6.32-41-generic). That's a big range of kernel releases between the working and non-working kernel. I do not think this is a regression. I am also experiencing problems with another (non-FTDI) USB device and libusb that does not exhibit on the netbook. The FTDI device also worked fine for months on these kernels 3.1.6, 3.2.2, 3.2.12, 3.4.0, 3.4.3, and 3.4.4. I am suspecting a hardware problem with this motherboard, but it would still be nice if Linux didn't go crazy and require a reboot to fix it (I can usually get around other hardware problems by doing a suspect-to-RAM or suspend-to-disk). Is there any way to get an idea of what USB chipsets are involved and try to figure out which one has a problem and how it manifests? Luke -- To unsubscribe from this list: send the line unsubscribe 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] USB: cdc-wdm: Extend and improve subdriver interface
On Tuesday 04 September 2012 17:32:17 Bjørn Mork wrote: No, that is perfectly all right. It seems to me that the API between usbnet and its subdrivers is not powerful enough to support CDC-NCM well. Maybe not. But I assume that any shortcomings found could be integrated in usbnet, if that is found to be the best solution. So what we are looking for is somehow for a usbnet minidriver to receive and submit single packet skbs and have usbnet handle all the logic related to packing and unpacking the multi-packet URBs. Should not be impossible. It is less trivial than it sounds, because protocols have specific requirements concerning alignment and stuff. I'll post code. 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: [RFC] How to handle delays in isochronous transfers?
On Wed, Sep 5, 2012 at 5:37 PM, Clemens Ladisch clem...@ladisch.de wrote: On Tue, 4 Sep 2012, Jassi Brar wrote: If we progress the h/w pointer of ALSA ring buffer at URB completion (and not at URB submission) this shouldn't affect the latency. How would this make any difference? The time between the application writing samples to the buffer and the samples actually being played by the device would not change. If we advance the pointer immediately after submission, the total time a sample spends in flight is ring-buffer + queue length. If we advance the pointer upon completion, the total time a sample spends in flight is ring-buffer. Or I am doped. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/11] chipidea/imx: add otg support and some bug fix
On 08/28/2012 09:03 AM, Richard Zhao wrote: The patch set is tested on imx6q_sabrelite board. The patch can also be found at https://github.com/riczhao/kernel-imx/commits/topics/usb-driver For test which merged platform patches: https://github.com/riczhao/kernel-imx/commits/topics/usb-test Changes since v1: - move usbmisc as the other patch series. - remove regulater_disable and old comments in ci13xxx_imx. Richard Zhao (11): USB: chipidea: imx: add pinctrl support USB: chipidea: delay 2ms before read ID status at probe time USB: chipidea: move OTGSC_IDIS clearing from ci_role_work to irq handler USB: chipidea: clear gadget struct at udc_start fail path USB: chipidea: don't let probe fail if otg controller start one role failed USB: mxs-phy: add basic otg support USB: chipidea: add vbus detect for udc USB: chipidea: convert to use devm_request_irq USB: chipidea: add -DDEBUG if CONFIG_USB_CHIPIDEA_DEBUG USB: chipidea: add set_vbus_power support USB: chipidea: re-order irq handling to avoid unhandled irq drivers/usb/chipidea/Makefile |2 ++ drivers/usb/chipidea/ci.h |1 + drivers/usb/chipidea/ci13xxx_imx.c | 51 +++- drivers/usb/chipidea/core.c| 36 +++-- drivers/usb/chipidea/host.c|8 ++ drivers/usb/chipidea/udc.c | 40 +++- drivers/usb/otg/mxs-phy.c | 21 +++ include/linux/usb/chipidea.h |2 ++ 8 files changed, 128 insertions(+), 33 deletions(-) Tested-by: Marc Kleine-Budde m...@pengutronix.de Can this series be applied? 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] xhci: Make handover code more robust
On Wed, Sep 05, 2012 at 02:21:52PM +0100, Matthew Garrett wrote: It's an SNB-E board with a series 7 chipset. The xHCI controller is an NEC. When it's in this failure state it doesn't seem like there's anything in the mmio BAR that's happy to talk to us, but I'll check the logs to see what xhci-hcd says. Host not halted after 16000 microseconds can't setup USB bus 5 deregistered Yeah, I think it's pretty solidly dead. I'll try to work out why it's so unenthusiastic about talking to us, but it still seems better in the short term to let the system survive rather than dying in quirk setup. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux 3.6-rc2, undefined reference to omap_musb_mailbox
Felipe,
That seems like what this patch of mine fixes (was about to send it when
I saw this on my mailbox).
It is not enough to just do a dependency; the patch fixes it by having
a helper that's always resident, and also making sure we don't drop
events.
Regards
-- Pantelis
On Aug 24, 2012, at 10:27 AM, Felipe Balbi wrote:
On Thu, Aug 23, 2012 at 10:38:59PM +0200, Peter Meerwald wrote:
On Mon, 20 Aug 2012, Felipe Balbi wrote:
On Mon, Aug 20, 2012 at 04:37:28PM +0530, ABRAHAM, KISHON VIJAY wrote:
Hi,
On Mon, Aug 20, 2012 at 3:56 PM, Felipe Balbi ba...@ti.com wrote:
On Mon, Aug 20, 2012 at 03:46:07PM +0530, ABRAHAM, KISHON VIJAY wrote:
Hi,
On Mon, Aug 20, 2012 at 3:24 PM, Felipe Balbi ba...@ti.com wrote:
On Mon, Aug 20, 2012 at 11:06:34AM +0530, ABRAHAM, KISHON VIJAY wrote:
Hi,
On Sat, Aug 18, 2012 at 9:34 PM, Peter Meerwald pme...@pmeerw.net
wrote:
3.6-rc2 fails to compile with
CONFIG_USB_MUSB_HDRC=m
CONFIG_USB_MUSB_OMAP2PLUS=m
LD init/built-in.o
drivers/built-in.o: In function `twl4030_usb_irq':
/home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:518:
undefined reference to `omap_musb_mailbox'
drivers/built-in.o: In function `twl4030_usb_phy_init':
/home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:540:
undefined reference to `omap_musb_mailbox'
Having TWL4030_USB as a module will get rid of this.
I'll see how this can be resolved when some modules are *built-in* and
some are made as *modules*.
EXPORT_SYMBOL_GPL() should sort that out, right ?
No :-( I already have EXPORT_SYMBOL_GPL() in omap2430.c.
I see you're missing an extern on the function prototype (on the
header). Not sure how modules.dep is generated, but maybe it needs the
extern there. Can you check it out ?
That isn't helping either.
oh, ok... twl4030-usb is built-in... now that makes sense. Since
twl4030-usb uses a symbol from omap2430, then it should depend on it,
otherwise this will always happen.
so add USB_MUSB_OMAP2PLUS to the depends of TWL4030_USB in
drivers/usb/otg/Kconfig?
correct ;-)
--
balbi
commit e191e7226099d90ba077719313d4964cf42834ca
Author: Pantelis Antoniou pa...@antoniou-consulting.com
Date: Fri Aug 10 13:07:43 2012 +
musb: Introduce mailbox helper
When MUSB_OMAP2 is compiled as a module while the musb mailbox callers are
not build fails. Introduce a helper to get around the problem.
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index f5ed3d7..6a868bc 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_USB_ATM) += atm/
obj-$(CONFIG_USB_SPEEDTOUCH) += atm/
obj-$(CONFIG_USB_MUSB_HDRC)+= musb/
+obj-$(CONFIG_USB_MUSB_OMAP2PLUS_MBOX_HELPER) += musb/
obj-$(CONFIG_USB_CHIPIDEA) += chipidea/
obj-$(CONFIG_USB_RENESAS_USBHS)+= renesas_usbhs/
obj-$(CONFIG_USB_GADGET) += gadget/
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 6259f0d..9201c3e 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -50,6 +50,7 @@ config USB_MUSB_TUSB6010
config USB_MUSB_OMAP2PLUS
tristate OMAP2430 and onwards
depends on ARCH_OMAP2PLUS
+ select USB_MUSB_OMAP2PLUS_MBOX_HELPER
config USB_MUSB_AM35X
tristate AM35x
@@ -69,6 +70,9 @@ config USB_MUSB_UX500
endchoice
+config USB_MUSB_OMAP2PLUS_MBOX_HELPER
+ bool
+
choice
prompt 'MUSB DMA mode'
default USB_UX500_DMA if USB_MUSB_UX500
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index 3b85871..9126fa2 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -12,6 +12,7 @@ musb_hdrc-$(CONFIG_DEBUG_FS) +=
musb_debugfs.o
# Hardware Glue Layer
obj-$(CONFIG_USB_MUSB_OMAP2PLUS) += omap2430.o
+obj-$(CONFIG_USB_MUSB_OMAP2PLUS_MBOX_HELPER) += omap2430_mboxhelper.o
obj-$(CONFIG_USB_MUSB_AM35X) += am35x.o
obj-$(CONFIG_USB_MUSB_DSPS)+= musb_dsps.o
obj-$(CONFIG_USB_MUSB_TUSB6010)+= tusb6010.o
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index d8c6aeb..920db04 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -228,7 +228,7 @@ static inline void omap2430_low_level_init(struct musb
*musb)
musb_writel(musb-mregs, OTG_FORCESTDBY, l);
}
-void omap_musb_mailbox(enum omap_musb_vbus_id_status status)
+static void omap_musb_mailbox_actual(enum omap_musb_vbus_id_status status)
{
struct omap2430_glue*glue = _glue;
struct musb *musb = glue_to_musb(glue);
@@ -241,7 +241,6 @@ void omap_musb_mailbox(enum omap_musb_vbus_id_status status)
schedule_work(glue-omap_musb_mailbox_work);
}
-EXPORT_SYMBOL_GPL(omap_musb_mailbox);
static void omap_musb_set_mailbox(struct omap2430_glue *glue)
{
@@ -441,6 +440,7 @@ static int omap2430_probe(struct platform_device *pdev)
struct
Re: [RFC PATCH V2 2/2] USB: Set usb port's DevicerRemovable according acpi information in EHCI
On Wed, 5 Sep 2012, Lan Tianyu wrote:
This is copied from xhci_usb3_hub_descriptor().
struct usb_hub_descriptor {
__u8 bDescLength;
__u8 bDescriptorType;
__u8 bNbrPorts;
__le16 wHubCharacteristics;
__u8 bPwrOn2PwrGood;
__u8 bHubContrCurrent;
/* 2.0 and 3.0 hubs differ here */
union {
struct {
/* add 1 bit for hub status change; round to bytes */
__u8 DeviceRemovable[(USB_MAXCHILDREN + 1 + 7) / 8];
__u8 PortPwrCtrlMask[(USB_MAXCHILDREN + 1 + 7) / 8];
} __attribute__ ((packed)) hs;
struct {
__u8 bHubHdrDecLat;
__u16 wHubDelay;
__u16 DeviceRemovable;
} __attribute__ ((packed)) ss;
} u;
} __attribute__ ((packed));
The struct has been defined with __attribute__ ((packed)). So there is
no alignment problem. Or we can
hub-descriptor-u.ss.DeviceRemovable = (__force __u16)
cpu_to_le16(port_removable);
I think we also should define wHubDelay and DeviceRemovable as __le16
for ss since they are little-endian order, right?
Yes. Ask Sarah about changing it.
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
Resend - xhci_hcd 0000:00:14.0: Timeout while waiting for address device command
I'm resending this message beacuse my original message didn't get to the list. Probably because of attachment size, so I'm compressing log files in attachment. Hi all! I have a problem with xhci and usb3 on my laptop. The problem is that after suspend/hibernate my usb3 ports seems to be dead or disconnected. I always see these two errors in logs: xhci_hcd :00:14.0: Timeout while waiting for address device command usb 3-3: device not accepting address 4, error -62 Major problem with this issue is that I have an integrated bluetooth devices connected to usb hub and after a suspend it gets disconnected and I can't enable bluetooth until I restart. First I thought that the problem was with my bluetooth device but if I connect any device to usb3 ports after suspend-resume cycle ports get disconnected and my device connected to usb3 port isn't working. By disconnected I mean it is completely shutdown and can't be seen in usb_devices command or in /sys/bus/usb/devices. If I disable USB3 support in BIOS then ehci is used instead xhci and then everything works normally. I can suspend/hibernate without any problem and without any errors in logs. So I'm blaming xhci driver for this behaviour. I tested couple of 3.x kernels and the behaviour is the same. Device also works on Win7 without any problems. I'm attaching dmesg logs with debug messages from xhci. I would gladly help to debug this deeper but I need some pointers from where to start and what is causing this behaviour. -- Best regards, Miroslav log_files.tar.bz2 Description: application/bzip
Re: [RFC] How to handle delays in isochronous transfers?
On Wed, 5 Sep 2012, Clemens Ladisch wrote: Alan Stern wrote: On Tue, 4 Sep 2012, Jassi Brar wrote: Second, people involved in real-time programming (such as audio or video) generally want to keep latency to a minimum. If we progress the h/w pointer of ALSA ring buffer at URB completion (and not at URB submission), I don't understand this comment. As far as I can tell, the relevant pointer already is being advanced during URB completion. It's advanced directly after submission. The queued data is double- buffered because the USB API lacks the ability to scatter/gather from a coherent buffer. Actually it does have this ability, but only to a limited extent. I don't remember what the restrictions are (and they probably aren't documented anywhere). Certainly the data for each packet has to be contiguous. There may be an assumption that the packets are stored in sequential increasing order in memory, and there may be a limitation on the distance between the starts of neighboring packets. I'm also not sure to what extent these restrictions could be relaxed. this shouldn't affect the latency. How would this make any difference? The time between the application writing samples to the buffer and the samples actually being played by the device would not change. This depends on how rapidly the program writes the samples. If they are written at about the same rate as they are played out then using a longer queue _will_ increase the latency, because the samples won't start playing until the queue is full. (I don't see how this is related to whether the buffer pointer is advanced at URB submission vs. URB completion, but never mind...) 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] musb: Kill __init from function that are called at other times as well.
Marking functions as __init or __devinit and calling them at other times
leads to predictable crashes (if you're lucky).
Remove them for now.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/usb/musb/musb_core.c| 16
drivers/usb/musb/musb_debugfs.c | 2 +-
drivers/usb/musb/musb_dma.h | 2 +-
drivers/usb/musb/musb_gadget.c | 6 +++---
drivers/usb/musb/musbhsdma.c| 2 +-
drivers/usb/musb/omap2430.c | 2 +-
6 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 26f1bef..215d2d5 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1160,7 +1160,7 @@ static struct musb_fifo_cfg __devinitdata mode_5_cfg[] = {
*
* returns negative errno or offset for next fifo.
*/
-static int __devinit
+static int
fifo_setup(struct musb *musb, struct musb_hw_ep *hw_ep,
const struct musb_fifo_cfg *cfg, u16 offset)
{
@@ -1235,7 +1235,7 @@ static struct musb_fifo_cfg __devinitdata ep0_cfg = {
.style = FIFO_RXTX, .maxpacket = 64,
};
-static int __devinit ep_config_from_table(struct musb *musb)
+static int ep_config_from_table(struct musb *musb)
{
const struct musb_fifo_cfg *cfg;
unsignedi, n;
@@ -1326,7 +1326,7 @@ done:
* ep_config_from_hw - when MUSB_C_DYNFIFO_DEF is false
* @param musb the controller
*/
-static int __devinit ep_config_from_hw(struct musb *musb)
+static int ep_config_from_hw(struct musb *musb)
{
u8 epnum = 0;
struct musb_hw_ep *hw_ep;
@@ -1373,7 +1373,7 @@ enum { MUSB_CONTROLLER_MHDRC, MUSB_CONTROLLER_HDRC, };
/* Initialize MUSB (M)HDRC part of the USB hardware subsystem;
* configure endpoints, or take their config from silicon
*/
-static int __devinit musb_core_init(u16 musb_type, struct musb *musb)
+static int musb_core_init(u16 musb_type, struct musb *musb)
{
u8 reg;
char *type;
@@ -1797,7 +1797,7 @@ static void musb_irq_work(struct work_struct *data)
* Init support
*/
-static struct musb *__devinit
+static struct musb *
allocate_instance(struct device *dev,
struct musb_hdrc_config *config, void __iomem *mbase)
{
@@ -1873,7 +1873,7 @@ static void musb_free(struct musb *musb)
* @mregs: virtual address of controller registers,
* not yet corrected for platform-specific offsets
*/
-static int __devinit
+static int
musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
{
int status;
@@ -2101,7 +2101,7 @@ fail0:
static u64 *orig_dma_mask;
#endif
-static int __devinit musb_probe(struct platform_device *pdev)
+static int musb_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
int irq = platform_get_irq_byname(pdev, mc);
@@ -2397,7 +2397,7 @@ static struct platform_driver musb_driver = {
/*-*/
-static int __init musb_init(void)
+static int /* __init */ musb_init(void)
{
if (usb_disabled())
return 0;
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 40a37c9..8f8597d 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -235,7 +235,7 @@ static const struct file_operations musb_test_mode_fops = {
.release= single_release,
};
-int __devinit musb_init_debugfs(struct musb *musb)
+int musb_init_debugfs(struct musb *musb)
{
struct dentry *root;
struct dentry *file;
diff --git a/drivers/usb/musb/musb_dma.h b/drivers/usb/musb/musb_dma.h
index 3a97c4e..69254c8 100644
--- a/drivers/usb/musb/musb_dma.h
+++ b/drivers/usb/musb/musb_dma.h
@@ -178,7 +178,7 @@ struct dma_controller {
extern void musb_dma_completion(struct musb *musb, u8 epnum, u8 transmit);
-extern struct dma_controller *__init
+extern struct dma_controller * /* __init */
dma_controller_create(struct musb *, void __iomem *);
extern void dma_controller_destroy(struct dma_controller *);
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index f7194cf..f3d9f4e 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1795,7 +1795,7 @@ static void musb_gadget_release(struct device *dev)
}
-static void __devinit
+static void
init_peripheral_ep(struct musb *musb, struct musb_ep *ep, u8 epnum, int is_in)
{
struct musb_hw_ep *hw_ep = musb-endpoints + epnum;
@@ -1832,7 +1832,7 @@ init_peripheral_ep(struct musb *musb, struct musb_ep *ep,
u8 epnum, int is_in)
* Initialize the endpoints exposed to peripheral drivers, with backlinks
* to the rest of the driver state.
*/
-static inline void __devinit musb_g_init_endpoints(struct musb *musb)
+static inline void musb_g_init_endpoints(struct musb *musb)
{
u8 epnum;
Re: [PATCH] xhci: Make handover code more robust
On Wed, Sep 05, 2012 at 02:21:52PM +0100, Matthew Garrett wrote: On Tue, Sep 04, 2012 at 03:40:56PM -0700, Sarah Sharp wrote: On Tue, Aug 14, 2012 at 04:44:49PM -0400, Matthew Garrett wrote: I've no idea what's causing the underlying problem, and xhci still doesn't actually *work* even with this, but the machine at least boots which will probably make further debugging easier. Is this an Ivy Bridge system? xHCI may not work because you're skipping the port switchover code just before the hc_init label. Of course, if the host controller continues to report all f's for register values, there's no point in trying to initialize the host at all... It's an SNB-E board with a series 7 chipset. The xHCI controller is an NEC. When it's in this failure state it doesn't seem like there's anything in the mmio BAR that's happy to talk to us, but I'll check the logs to see what xhci-hcd says. Hmm, yeah, that sounds like the host is pretty hosed then. I'll merge your patch, since it seems sensible to check the ranges anyway. 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: host: xhci: fix compilation error for non-PCI based stacks
On Wed, Sep 05, 2012 at 08:34:26AM +0300, Felipe Balbi wrote: From: Moiz Sonasath m-sonas...@ti.com For non PCI-based stacks, this function call usb_disable_xhci_ports(to_pci_dev(hcd-self.controller)); made from xhci_shutdown is not applicable. Ideally, we wouldn't have any PCI-specific code on a generic driver such as the xHCI stack, but it looks like we should just stub usb_disable_xhci_ports() out for non-PCI devices. Oops, sorry about breaking non-PCI builds! I've already gotten a different bug fix for the same commit that broke it, so I probably shouldn't have rushed to push it before I left for vacation. :( I'll queue this up to Greg today. 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: [eBeam PATCH 2/2] input: misc: New USB eBeam input driver.
Hi, Le 05/09/2012 09:29, Oliver Neukum a écrit : before we add yet another sysfs interface, we should ask whether calibration isn't a problem that should be solved with a common API. Short answer : no. ## Long answer (may be oot) : Existing calibration tools or procedures (in kernel modules or xorg) for absolute devices deals with hardware axis mostly matching system's ones (X screen mainly), modulo switching XY, inversion or simple tweaks. Plus you know from the beginning the ranges used, and all parameters are stable. eBeam device track an active stylus in his fov, usually on a whiteboard where a video-projector cast the computer screen. It then compute the stylus's position and send it to the kernel in his own fixed 2D cartesian coordinate system relative to the device. The device is by design mobile (you stuck it anywhere on the border of the projection plane for a session), his axis never match screen's ones, neither in range nor orientation. Even worse, due to projection artifact, the two coordinates systems (ebeam and screen) can even not be linearly correlated. Manufacturer's so-called drivers seems to use second order interpolations, i use an homography transformation (which is the right mathematical tool for the problem, and seems quicker) to transform between coordinates systems. Anyway, this need lot of parameters. As ebeams are the only devices to my knowledge that work that way, i don't think a common API can be common, unless we mean an in-kernel generic purpose calibration API for input devices (stellar away for me), or a userland one (where should it be in the stack ?). Sincerely, this look overkill. In the other hand, the actual ebeam module transformation feeding events subsys works very well and expose straight and usable data to userland (xorg evdev for now, and any program that can eat kernel's input data). ## I understand the sysfs interface is a problem. Eventually, in last resort, i can reduce it to 4 files : pass the 9 matrix parameters as one big string, removing min values. But i think this obfuscate the api for a marginal gain. -- Yann Cantin A4FEB47F -- -- To unsubscribe from this list: send the line unsubscribe 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: [eBeam PATCH 2/2] input: misc: New USB eBeam input driver.
On Wednesday 05 September 2012 21:58:06 Yann Cantin wrote: As ebeams are the only devices to my knowledge that work that way, i don't think a common API can be common, unless we mean an in-kernel generic purpose calibration API for input devices (stellar away for me), or a userland one (where should it be in the stack ?). Sincerely, this look overkill. In the other hand, the actual ebeam module transformation feeding events subsys works very well and expose straight and usable data to userland (xorg evdev for now, and any program that can eat kernel's input data). OK, I see the problem. You have no other choice. ## I understand the sysfs interface is a problem. Eventually, in last resort, i can reduce it to 4 files : pass the 9 matrix parameters as one big string, removing min values. But i think this obfuscate the api for a marginal gain. That would be wrong. The problem is a specific API. If it needs to be done at all, it better be done as cleanly as possible. 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
changing usbnet's API to better deal with cdc-ncm
Hi,
looking at cdc-ncm it seeems to me that cdc-ncm is forced to play
very dirty games because usbnet doesn't have a notion about aggregating
packets for a single transfer.
It seems to me that this can be fixed introducing a method for bundling,
which tells usbnet how packets have been aggregated. To have performance
usbnet strives to always keep at least two transfers in flight.
The code isn't complete and I need to get a device for testing, but to get
your opinion, I ask you to comment on what I have now.
Regards
Oliver
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 4cd582a..56ef743 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -135,9 +135,6 @@ struct cdc_ncm_ctx {
u16 connected;
};
-static void cdc_ncm_txpath_bh(unsigned long param);
-static void cdc_ncm_tx_timeout_start(struct cdc_ncm_ctx *ctx);
-static enum hrtimer_restart cdc_ncm_tx_timer_cb(struct hrtimer *hr_timer);
static struct usb_driver cdc_ncm_driver;
static void
@@ -464,10 +461,6 @@ static int cdc_ncm_bind(struct usbnet *dev, struct
usb_interface *intf)
if (ctx == NULL)
return -ENODEV;
- hrtimer_init(ctx-tx_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
- ctx-tx_timer.function = cdc_ncm_tx_timer_cb;
- ctx-bh.data = (unsigned long)ctx;
- ctx-bh.func = cdc_ncm_txpath_bh;
atomic_set(ctx-stop, 0);
spin_lock_init(ctx-mtx);
ctx-netdev = dev-net;
@@ -650,7 +643,7 @@ static void cdc_ncm_zero_fill(u8 *ptr, u32 first, u32 end,
u32 max)
memset(ptr + first, 0, end - first);
}
-static struct sk_buff *
+static int
cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct sk_buff *skb)
{
struct sk_buff *skb_out;
@@ -659,12 +652,7 @@ cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct
sk_buff *skb)
u32 last_offset;
u16 n = 0, index;
u8 ready2send = 0;
-
- /* if there is a remaining skb, it gets priority */
- if (skb != NULL)
- swap(skb, ctx-tx_rem_skb);
- else
- ready2send = 1;
+ u8 error = 0;
/*
* ++
@@ -690,7 +678,7 @@ cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct
sk_buff *skb)
dev_kfree_skb_any(skb);
ctx-netdev-stats.tx_dropped++;
}
- goto exit_no_skb;
+ return -EBUSY;
}
/* make room for NTH and NDP */
@@ -719,28 +707,15 @@ cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct
sk_buff *skb)
/* compute maximum buffer size */
rem = ctx-tx_max - offset;
- if (skb == NULL) {
- skb = ctx-tx_rem_skb;
- ctx-tx_rem_skb = NULL;
-
- /* check for end of skb */
- if (skb == NULL)
- break;
- }
-
if (skb-len rem) {
if (n == 0) {
/* won't fit, MTU problem? */
dev_kfree_skb_any(skb);
skb = NULL;
ctx-netdev-stats.tx_dropped++;
+ error = 1;
} else {
- /* no room for skb - store for later */
- if (ctx-tx_rem_skb != NULL) {
- dev_kfree_skb_any(ctx-tx_rem_skb);
- ctx-netdev-stats.tx_dropped++;
- }
- ctx-tx_rem_skb = skb;
+
skb = NULL;
ready2send = 1;
}
@@ -768,13 +743,6 @@ cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct
sk_buff *skb)
skb = NULL;
}
- /* free up any dangling skb */
- if (skb != NULL) {
- dev_kfree_skb_any(skb);
- skb = NULL;
- ctx-netdev-stats.tx_dropped++;
- }
-
ctx-tx_curr_frame_num = n;
if (n == 0) {
@@ -791,9 +759,7 @@ cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct
sk_buff *skb)
ctx-tx_curr_skb = skb_out;
ctx-tx_curr_offset = offset;
ctx-tx_curr_last_offset = last_offset;
- /* set the pending count */
- if (n CDC_NCM_RESTART_TIMER_DATAGRAM_CNT)
- ctx-tx_timer_pending = CDC_NCM_TIMER_PENDING_CNT;
+
goto exit_no_skb;
} else {
@@ -874,71 +840,37 @@ cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct
sk_buff *skb)
/* return skb */
ctx-tx_curr_skb = NULL;
ctx-netdev-stats.tx_packets += ctx-tx_curr_frame_num;
- return skb_out;
-exit_no_skb:
-
Re: [PATCH v2] staging/ccg: Allow to overwrite composite's setup function
On Mon, Aug 20, 2012 at 09:35:22AM +0200, Sebastian Andrzej Siewior wrote: I'm not going to swear here. The Android gadget includes composite.c from the main tree and overwrites functions. This would still work if I rename it and remove the const attribute but the problem rises again once we stop including composite.c and use it as a library function. Cc: de...@driverdev.osuosl.org Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- v1..v2: different overwrite hack Guys, it is getting difficult to keep up fixing Android code while hacking on composite. Is anyone against a copy of composite.c and friends in drivers/staging/ccg/ like it has been with transport.c or scsiglue.c for drivers/staging/keucr? I have no objection to doing this, as it will proabably make your life easier, right? So I'll drop this patch for now. 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: chipidea driver
On Fri, Aug 24, 2012 at 10:09:11AM +0800, Richard Zhao wrote: On Thu, Aug 23, 2012 at 06:57:03PM +0200, Marc Kleine-Budde wrote: Hello, Michael and I have a bunch of updates and improvement for the chipidea driver. They apply to Richard's tree: https://github.com/riczhao/kernel-imx/commits/topics/usb-driver What's the status of these patches? It would be fine if someone queues them for upstream. My patches is pending on Alex to review. The otg patch series was sent on Jul 12. I don't know whether Alex has been back from vacation, or what else I can do. otg patch: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/109020.html usbmisc: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111945.html Alex, what is going on with the pending chipidea patches? There seem to be a lot of them, and I haven't seen any response from you in quite some time. 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: Re: Re: 3.0 device attached to USB 3.0 hub port doesn't respond address device command after resume
On Tue, Aug 21, 2012 at 08:16:10PM +0800, Andiry Xu wrote: Just have one question - how do you add suspend/resume support for DWC USB 3 controller? Where can I find the source code? Is it reusing the suspend/resume code of xhci.c? If you look in drivers/usb/host/xhci-plat.c, you'll see that the xHCI platform driver reuses the standard xHCI bus suspend/resume hooks. So the DWC3 host should have USB device and USB bus suspend. If you're asking about host controller suspend, that would be specific to whatever bus the DWC3 host is attached to. If the DWC3 host is connected via PCI, then it will just use the standard xHCI PCI suspend hooks. I'm not sure if there's suspend support for other host buses. Felipe should be able to answer that question. 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: [BUG] - USB3 bluetooth device not working properly?
On Mon, Aug 27, 2012 at 02:09:53PM +0200, Miroslav Sabljic wrote: On 08/22/2012 05:39 PM, Miroslav Sabljic wrote: If the device is working properly on boot up and fails after suspend/resume, you can try the patch attached to see if it helps on the failure after system resume. Unfortunately it look like it doesn't change anything. Patched, rebuilt, installed and tested. Same errors apear after suspend. :( I tried to manually add some quirks for this device based on this http://permalink.gmane.org/gmane.linux.usb.general/48139. But with no results. At first I thought the bluetooth device isn't responding after a resume but yesterday I saw that any device connected to usb3 hub doesn't work after suspend/resume. Can someone please help me write some quirk for this device or maybe adapt an existing quirk? I'm actually wondering if you're hitting a bug that is fixed by a patch in my queue to send to Greg. Apparently, some BIOSes expect specific USB ports on the mobile Panther Point chipset to remain under the EHCI controller, even though they can be switched over to the xHCI host controller. Can you run this git command, compile a kernel, and see if it fixes your issue? git clone git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git -b for-usb-linus 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: XHCI: xhci-ring: Remove unused dma address calculation in inc_enq and inc_deq function
Hi Girish,
Sorry for taking a really long time to respond! This is a good idea,
but your patch doesn't apply any more. Can you update it against the
latest kernel and resend it?
Sarah Sharp
On Sun, May 13, 2012 at 08:59:02PM +0530, Girish Verma wrote:
In xhci-ring.c, function inc_enq and inc_deq calculate the dma address
of trb but never used.
Signed-off-by: Girish Verma gir...@circuitsutra.com
---
drivers/usb/host/xhci-ring.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 3d9422f..dcd67c1 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -146,7 +146,6 @@ static void next_trb(struct xhci_hcd *xhci,
static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring *ring)
{
union xhci_trb *next;
- unsigned long long addr;
ring-deq_updates++;
@@ -168,7 +167,6 @@ static void inc_deq(struct xhci_hcd *xhci, struct
xhci_ring *ring)
ring-dequeue = ring-deq_seg-trbs;
next = ring-dequeue;
}
- addr = (unsigned long long) xhci_trb_virt_to_dma(ring-deq_seg,
ring-dequeue);
}
/*
@@ -193,7 +191,6 @@ static void inc_enq(struct xhci_hcd *xhci, struct
xhci_ring *ring,
{
u32 chain;
union xhci_trb *next;
- unsigned long long addr;
chain = le32_to_cpu(ring-enqueue-generic.field[3]) TRB_CHAIN;
/* If this is not event ring, there is one less usable TRB */
@@ -245,7 +242,6 @@ static void inc_enq(struct xhci_hcd *xhci, struct
xhci_ring *ring,
ring-enqueue = ring-enq_seg-trbs;
next = ring-enqueue;
}
- addr = (unsigned long long) xhci_trb_virt_to_dma(ring-enq_seg,
ring-enqueue);
}
/*
--
--
To unsubscribe from this list: send the line unsubscribe 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: [GIT PULL] USB fixes for v3.6-rc4
On Thu, Aug 23, 2012 at 12:03:58PM +0300, Felipe Balbi wrote: Hi Greg, Here's my (hopefully) last set of fixes for v3.6-rc cycle. Let me know if you want me to change anything and I'll do so ASAP. cheers The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v3.6-rc4 for you to fetch changes up to 07dc6cb73678e5a2bdaed74774b9064d27b8da0d: usb: renesas_usbhs: fixup DMA transport data alignment (2012-08-23 11:05:40 +0300) (from the branch description for fixes local branch) usb: fixes for v3.6-rc4 Here's a rather big set of fixes for v3.6-rc4. There are some fixes for bugs which have been pending for a long time and only now were uncovered, like the musb and dwc3 patches. We have some remaining fixes for the ep-desc patch series from Ido, and a very important fix to u_ether which would cause 100% cpu utilization in eth_stop. All patches have been pending on linux-usb for a long time and shouldn't cause any further regressions. Ajay Kumar Gupta (3): usb: musb: Fix wrong config for am33xx and ti81xx usb: musb: am335x: fix pdev resource bug usb: musb: reorder runtime pm call Andrzej Pietrasiewicz (1): usb: gadget: add multiple definition guards Julia Lawall (1): usb: gadget: s3c-hsotg.c: fix error return code Kishon Vijay Abraham I (1): usb: dwc3: core: fix incorrect usage of resource pointer Kuninori Morimoto (3): usb: renesas_usbhs: mod_host: add missing .bus_suspend/resume usb: renesas_usbhs: fixup resume method for autonomy mode usb: renesas_usbhs: fixup DMA transport data alignment Michael Grzeschik (1): usb: gadget: u_ether: fix kworker 100% CPU issue with still used interfaces in eth_stop Pratyush Anand (1): usb: dwc3: ep0: correct cache sync issue in case of ep0_bounced Sebastian Andrzej Siewior (4): usb: gadget: dummy_hcd: fixup error probe path usb: gadget: dummy_hcd: add support for USB_DT_BOS on rh usb: gadget: at91udc: don't overwrite driver data usb: gadget: at91udc: Don't check for ep-ep.desc Sergei Shtylyov (2): usb: musb: tusb6010: fix error path in tusb_probe() usb: musb: musbhsdma: fix IRQ check yuzheng ma (1): usb: musb: host: fix for musb_start_urb Oops drivers/usb/dwc3/core.c | 9 ++-- drivers/usb/dwc3/ep0.c | 1 - drivers/usb/dwc3/gadget.c| 7 -- drivers/usb/gadget/at91_udc.c| 6 +- drivers/usb/gadget/dummy_hcd.c | 41 drivers/usb/gadget/f_fs.c| 4 drivers/usb/gadget/s3c-hsotg.c | 3 +++ drivers/usb/gadget/u_ether.c | 6 ++ drivers/usb/gadget/u_serial.c| 4 drivers/usb/musb/Kconfig | 4 ++-- drivers/usb/musb/musb_dsps.c | 19 + drivers/usb/musb/musb_host.c | 2 +- drivers/usb/musb/musbhsdma.c | 2 +- drivers/usb/musb/tusb6010.c | 2 +- drivers/usb/renesas_usbhs/common.c | 6 +++--- drivers/usb/renesas_usbhs/fifo.c | 4 ++-- drivers/usb/renesas_usbhs/mod_host.c | 8 +++ 17 files changed, 95 insertions(+), 33 deletions(-) Odd, my pull ended up with: Merge made by the 'recursive' strategy. drivers/usb/dwc3/core.c | 9 +++-- drivers/usb/dwc3/ep0.c | 1 - drivers/usb/dwc3/gadget.c| 7 +-- drivers/usb/gadget/at91_udc.c| 6 +- drivers/usb/gadget/dummy_hcd.c | 41 + drivers/usb/gadget/f_fs.c| 4 drivers/usb/gadget/s3c-hsotg.c | 3 +++ drivers/usb/gadget/u_serial.c| 4 drivers/usb/musb/musb_host.c | 2 +- drivers/usb/musb/musbhsdma.c | 2 +- drivers/usb/musb/tusb6010.c | 2 +- drivers/usb/renesas_usbhs/fifo.c | 4 ++-- 12 files changed, 66 insertions(+), 19 deletions(-) So something is missing here, right? Because of this, I've not pulled this now, what went wrong? 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/host: Cleanup unneccessary irq disable code
On Sat, Sep 01, 2012 at 09:39:56AM +, Liu, Chuansheng wrote: From: liu chuansheng chuansheng@intel.com Subject: [PATCH] USB/host: Cleanup unneccessary irq disable code Don't include the Subject: in the patch body again, that is pointless and requires me to hand-edit the file. Because the IRQF_DISABLED as the flag is now a NOOP and has been deprecated and in hardirq context the interrupt is disabled. so in usb/host code: Removing the usage of flag IRQF_DISABLED; Removing the calling local_irq save/restore actions in irq handler usb_hcd_irq(); Signed-off-by: liu chuansheng chuansheng@intel.com This patch is corrupted and can not be applied at all. Please fix your email client and try again. 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/host: Cleanup unneccessary irq disable code
This patch is corrupted and can not be applied at all. Please fix your email
client and try again.
greg k-h
I am very sorry to waste your time, resend it again.
From: liu chuansheng chuansheng@intel.com
Subject: [PATCH] USB/host: Cleanup unneccessary irq disable code
Because the IRQF_DISABLED as the flag is now a NOOP and has been
deprecated and in hardirq context the interrupt is disabled.
so in usb/host code:
Removing the usage of flag IRQF_DISABLED;
Removing the calling local_irq save/restore actions in irq
handler usb_hcd_irq();
Signed-off-by: liu chuansheng chuansheng@intel.com
---
drivers/usb/core/hcd.c | 15 ---
drivers/usb/host/ehci-ls1x.c |2 +-
drivers/usb/host/ohci-xls.c |2 +-
3 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index bc84106..f84ddea 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2153,15 +2153,8 @@ EXPORT_SYMBOL_GPL(usb_bus_start_enum);
irqreturn_t usb_hcd_irq (int irq, void *__hcd)
{
struct usb_hcd *hcd = __hcd;
- unsigned long flags;
irqreturn_t rc;
- /* IRQF_DISABLED doesn't work correctly with shared IRQs
-* when the first handler doesn't use it. So let's just
-* assume it's never used.
-*/
- local_irq_save(flags);
-
if (unlikely(HCD_DEAD(hcd) || !HCD_HW_ACCESSIBLE(hcd)))
rc = IRQ_NONE;
else if (hcd-driver-irq(hcd) == IRQ_NONE)
@@ -2169,7 +2162,6 @@ irqreturn_t usb_hcd_irq (int irq, void *__hcd)
else
rc = IRQ_HANDLED;
- local_irq_restore(flags);
return rc;
}
EXPORT_SYMBOL_GPL(usb_hcd_irq);
@@ -2358,13 +2350,6 @@ static int usb_hcd_request_irqs(struct usb_hcd *hcd,
if (hcd-driver-irq) {
- /* IRQF_DISABLED doesn't work as advertised when used together
-* with IRQF_SHARED. As usb_hcd_irq() will always disable
-* interrupts we can remove it here.
-*/
- if (irqflags IRQF_SHARED)
- irqflags = ~IRQF_DISABLED;
-
snprintf(hcd-irq_descr, sizeof(hcd-irq_descr), %s:usb%d,
hcd-driver-description, hcd-self.busnum);
retval = request_irq(irqnum, usb_hcd_irq, irqflags,
diff --git a/drivers/usb/host/ehci-ls1x.c b/drivers/usb/host/ehci-ls1x.c
index a283e59..425cb4a 100644
--- a/drivers/usb/host/ehci-ls1x.c
+++ b/drivers/usb/host/ehci-ls1x.c
@@ -119,7 +119,7 @@ static int ehci_hcd_ls1x_probe(struct platform_device *pdev)
goto err_release_region;
}
- ret = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
+ ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto err_iounmap;
diff --git a/drivers/usb/host/ohci-xls.c b/drivers/usb/host/ohci-xls.c
index 41e378f..84201cd 100644
--- a/drivers/usb/host/ohci-xls.c
+++ b/drivers/usb/host/ohci-xls.c
@@ -56,7 +56,7 @@ static int ohci_xls_probe_internal(const struct hc_driver
*driver,
goto err3;
}
- retval = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
+ retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (retval != 0)
goto err4;
return 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
[Pull Request] xHCI 3.6 bug fixes.
The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0: Linux 3.6-rc3 (2012-08-22 13:29:06 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-linus-2012-09-05 for you to fetch changes up to 296365781903226a3fb8758901eaeec09d2798e4: usb: host: xhci: fix compilation error for non-PCI based stacks (2012-09-05 12:26:11 -0700) xHCI 3.6 bug fixes. Hi Greg, Here's seven bugfixes for 3.6. All of them are marked for stable, and most are vendor-specific fixes. Details: - Commits 052c7f9 and 2963657 fix a couple stupid mistakes I made in a Intel xHCI bug fix patch I pushed just before I left for vacation. - Commits 29d2145 and a96874a fix issues with the Intel Panther Point EHCI to xHCI port switchover. - Commit 71c731a adds the work-around for the TI redriver dead port issue. - Commit 319acdf adds a fix for non-PCI xHCI platform drivers. - Commit e955a1c works around the UEFI issue with the xHCI host sometimes returning 0xff's in the MMIO on boot. Sarah Sharp Alexis R. Cortes (1): usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware Dan Carpenter (1): xhci: Fix a logical vs bitwise AND bug Keng-Yu Lin (1): Intel xhci: Only switch the switchable ports Manoj Iyer (1): xhci: Recognize USB 3.0 devices as superspeed at powerup Matthew Garrett (1): xhci: Make handover code more robust Moiz Sonasath (1): usb: host: xhci: fix compilation error for non-PCI based stacks Ruchika Kharwar (1): usb: host: xhci-plat: use ioremap_nocache drivers/usb/host/pci-quirks.c | 42 -- drivers/usb/host/pci-quirks.h |1 + drivers/usb/host/xhci-hub.c | 42 ++ drivers/usb/host/xhci-plat.c |2 +- drivers/usb/host/xhci.c | 123 - drivers/usb/host/xhci.h |6 ++ 6 files changed, 207 insertions(+), 9 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
[PATCH 3/7] xhci: Fix a logical vs bitwise AND bug
From: Dan Carpenter dan.carpen...@oracle.com
The intent was to test whether the flag was set.
This patch should be backported to stable kernels as old as 3.0, since
it fixes a bug in commit e95829f474f0db3a4d940cae1423783edd966027 xhci:
Switch PPT ports to EHCI on shutdown., which was marked for stable.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index c59d5b5..617b0a7 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -659,7 +659,7 @@ void xhci_shutdown(struct usb_hcd *hcd)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
- if (xhci-quirks XHCI_SPURIOUS_REBOOT)
+ if (xhci-quirks XHCI_SPURIOUS_REBOOT)
usb_disable_xhci_ports(to_pci_dev(hcd-self.controller));
spin_lock_irq(xhci-lock);
--
1.7.9
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] xhci: Recognize USB 3.0 devices as superspeed at powerup
From: Manoj Iyer manoj.i...@canonical.com On Intel Panther Point chipset USB 3.0 devices show up as high-speed devices on powerup, but after an s3 cycle they are correctly recognized as SuperSpeed. At powerup switch the port to xHCI so that USB 3.0 devices are correctly recognized. BugLink: http://bugs.launchpad.net/bugs/1000424 This patch should be backported to kernels as old as 3.0, that contain commit ID 69e848c2090aebba5698a1620604c7dccb448684 Intel xhci: Support EHCI/xHCI port switching. Signed-off-by: Manoj Iyer manoj.i...@canonical.com Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com Cc: sta...@vger.kernel.org --- drivers/usb/host/pci-quirks.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c index c5e9e4a..486e812 100644 --- a/drivers/usb/host/pci-quirks.c +++ b/drivers/usb/host/pci-quirks.c @@ -870,9 +870,10 @@ static void __devinit quirk_usb_handoff_xhci(struct pci_dev *pdev) /* Disable any BIOS SMIs and clear all SMI events*/ writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET); +hc_init: if (usb_is_intel_switchable_xhci(pdev)) usb_enable_xhci_ports(pdev); -hc_init: + op_reg_base = base + XHCI_HC_LENGTH(readl(base)); /* Wait for the host controller to be ready before writing any -- 1.7.9 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] usb: host: xhci: fix compilation error for non-PCI based stacks
From: Moiz Sonasath m-sonas...@ti.com
For non PCI-based stacks, this function call
usb_disable_xhci_ports(to_pci_dev(hcd-self.controller));
made from xhci_shutdown is not applicable.
Ideally, we wouldn't have any PCI-specific code on
a generic driver such as the xHCI stack, but it looks
like we should just stub usb_disable_xhci_ports() out
for non-PCI devices.
[ ba...@ti.com: slight improvement to commit log ]
This patch should be backported to kernels as old as 3.0, since the
commit it fixes (e95829f474f0db3a4d940cae1423783edd966027 xhci: Switch
PPT ports to EHCI on shutdown.) was marked for stable.
Signed-off-by: Moiz Sonasathm-sonas...@ti.com
Signed-off-by: Ruchika Kharwar ruch...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/pci-quirks.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h
index ef004a5..7f69a39 100644
--- a/drivers/usb/host/pci-quirks.h
+++ b/drivers/usb/host/pci-quirks.h
@@ -15,6 +15,7 @@ void usb_disable_xhci_ports(struct pci_dev *xhci_pdev);
static inline void usb_amd_quirk_pll_disable(void) {}
static inline void usb_amd_quirk_pll_enable(void) {}
static inline void usb_amd_dev_put(void) {}
+static inline void usb_disable_xhci_ports(struct pci_dev *xhci_pdev) {}
#endif /* CONFIG_PCI */
#endif /* __LINUX_USB_PCI_QUIRKS_H */
--
1.7.9
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] usb: host: xhci-plat: use ioremap_nocache
From: Ruchika Kharwar ruch...@ti.com
Use the ioremap_nocache variant of the ioremap API in
order to make sure our memory will be marked uncachable.
This patch should be backported to kernels as old as 3.4, that contain
the commit 3429e91a661e1f383aecc86c6bbcf65afb15c892 usb: host: xhci:
add platform driver support.
Signed-off-by: Ruchika Kharwar ruch...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-plat.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 689bc18..df90fe5 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -118,7 +118,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_hcd;
}
- hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
+ hcd-regs = ioremap_nocache(hcd-rsrc_start, hcd-rsrc_len);
if (!hcd-regs) {
dev_dbg(pdev-dev, error mapping memory\n);
ret = -EFAULT;
--
1.7.9
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
From: Alexis R. Cortes alexis.cor...@ti.com
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem dead to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 USB: When
hot reset for USB3 fails, try warm reset and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 usb: Add support for root hub
port status CAS. The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes alexis.cor...@ti.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-hub.c | 42 +++
drivers/usb/host/xhci.c | 121 +++
drivers/usb/host/xhci.h |6 ++
3 files changed, 169 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 74bfc86..d5eb357 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -493,11 +493,48 @@ static void xhci_hub_report_link_state(u32 *status, u32
status_reg)
* when this bit is set.
*/
pls |= USB_PORT_STAT_CONNECTION;
+ } else {
+ /*
+* If CAS bit isn't set but the Port is already at
+* Compliance Mode, fake a connection so the USB core
+* notices the Compliance state and resets the port.
+* This resolves an issue generated by the SN65LVPE502CP
+* in which sometimes the port enters compliance mode
+* caused by a delay on the host-device negotiation.
+*/
+ if (pls == USB_SS_PORT_LS_COMP_MOD)
+ pls |= USB_PORT_STAT_CONNECTION;
}
+
/* update status field */
*status |= pls;
}
+/*
+ * Function for Compliance Mode Quirk.
+ *
+ * This Function verifies if all xhc USB3 ports have entered U0, if so,
+ * the compliance mode timer is deleted. A port won't enter
+ * compliance mode if it has previously entered U0.
+ */
+void xhci_del_comp_mod_timer(struct xhci_hcd *xhci, u32 status, u16 wIndex)
+{
+ u32 all_ports_seen_u0 = ((1 xhci-num_usb3_ports)-1);
+ bool port_in_u0 = ((status PORT_PLS_MASK) == XDEV_U0);
+
+ if (!(xhci-quirks XHCI_COMP_MODE_QUIRK))
+ return;
+
+ if ((xhci-port_status_u0 != all_ports_seen_u0) port_in_u0) {
+ xhci-port_status_u0 |= 1 wIndex;
+ if (xhci-port_status_u0 == all_ports_seen_u0) {
+ del_timer_sync(xhci-comp_mode_recovery_timer);
+ xhci_dbg(xhci, All USB3 ports have entered U0
already!\n);
+ xhci_dbg(xhci, Compliance Mode Recovery Timer
Deleted.\n);
+ }
+ }
+}
+
int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
u16 wIndex, char *buf, u16 wLength)
{
@@ -651,6 +688,11 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
/* Update Port Link State for super speed ports*/
if (hcd-speed == HCD_USB3) {
xhci_hub_report_link_state(status, temp);
+ /*
+* Verify if all USB3 Ports Have entered U0 already.
+* Delete Compliance Mode Timer if so.
+
RE: [PATCH] USB/host: Cleanup unneccessary irq disable code
From: liu chuansheng chuansheng@intel.com
Subject: [PATCH] USB/host: Cleanup unneccessary irq disable code
Why is this in the patch?
Please resend it in a format that I do not have to manually edit the patch.
greg k-h
Thanks your teaching, resend again.
Because the IRQF_DISABLED as the flag is now a NOOP and has been
deprecated and in hardirq context the interrupt is disabled.
so in usb/host code:
Removing the usage of flag IRQF_DISABLED;
Removing the calling local_irq save/restore actions in irq
handler usb_hcd_irq();
Signed-off-by: liu chuansheng chuansheng@intel.com
---
drivers/usb/core/hcd.c | 15 ---
drivers/usb/host/ehci-ls1x.c |2 +-
drivers/usb/host/ohci-xls.c |2 +-
3 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index bc84106..f84ddea 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2153,15 +2153,8 @@ EXPORT_SYMBOL_GPL(usb_bus_start_enum);
irqreturn_t usb_hcd_irq (int irq, void *__hcd)
{
struct usb_hcd *hcd = __hcd;
- unsigned long flags;
irqreturn_t rc;
- /* IRQF_DISABLED doesn't work correctly with shared IRQs
-* when the first handler doesn't use it. So let's just
-* assume it's never used.
-*/
- local_irq_save(flags);
-
if (unlikely(HCD_DEAD(hcd) || !HCD_HW_ACCESSIBLE(hcd)))
rc = IRQ_NONE;
else if (hcd-driver-irq(hcd) == IRQ_NONE)
@@ -2169,7 +2162,6 @@ irqreturn_t usb_hcd_irq (int irq, void *__hcd)
else
rc = IRQ_HANDLED;
- local_irq_restore(flags);
return rc;
}
EXPORT_SYMBOL_GPL(usb_hcd_irq);
@@ -2358,13 +2350,6 @@ static int usb_hcd_request_irqs(struct usb_hcd *hcd,
if (hcd-driver-irq) {
- /* IRQF_DISABLED doesn't work as advertised when used together
-* with IRQF_SHARED. As usb_hcd_irq() will always disable
-* interrupts we can remove it here.
-*/
- if (irqflags IRQF_SHARED)
- irqflags = ~IRQF_DISABLED;
-
snprintf(hcd-irq_descr, sizeof(hcd-irq_descr), %s:usb%d,
hcd-driver-description, hcd-self.busnum);
retval = request_irq(irqnum, usb_hcd_irq, irqflags,
diff --git a/drivers/usb/host/ehci-ls1x.c b/drivers/usb/host/ehci-ls1x.c
index a283e59..425cb4a 100644
--- a/drivers/usb/host/ehci-ls1x.c
+++ b/drivers/usb/host/ehci-ls1x.c
@@ -119,7 +119,7 @@ static int ehci_hcd_ls1x_probe(struct platform_device *pdev)
goto err_release_region;
}
- ret = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
+ ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto err_iounmap;
diff --git a/drivers/usb/host/ohci-xls.c b/drivers/usb/host/ohci-xls.c
index 41e378f..84201cd 100644
--- a/drivers/usb/host/ohci-xls.c
+++ b/drivers/usb/host/ohci-xls.c
@@ -56,7 +56,7 @@ static int ohci_xls_probe_internal(const struct hc_driver
*driver,
goto err3;
}
- retval = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
+ retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (retval != 0)
goto err4;
return 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 RESEND] USB/host: Cleanup unneccessary irq disable code
Because the IRQF_DISABLED as the flag is now a NOOP and has been
deprecated and in hardirq context the interrupt is disabled.
so in usb/host code:
Removing the usage of flag IRQF_DISABLED;
Removing the calling local_irq save/restore actions in irq
handler usb_hcd_irq();
Signed-off-by: liu chuansheng chuansheng@intel.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/core/hcd.c | 15 ---
drivers/usb/host/ehci-ls1x.c |2 +-
drivers/usb/host/ohci-xls.c |2 +-
3 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index bc84106..f84ddea 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2153,15 +2153,8 @@ EXPORT_SYMBOL_GPL(usb_bus_start_enum);
irqreturn_t usb_hcd_irq (int irq, void *__hcd)
{
struct usb_hcd *hcd = __hcd;
- unsigned long flags;
irqreturn_t rc;
- /* IRQF_DISABLED doesn't work correctly with shared IRQs
-* when the first handler doesn't use it. So let's just
-* assume it's never used.
-*/
- local_irq_save(flags);
-
if (unlikely(HCD_DEAD(hcd) || !HCD_HW_ACCESSIBLE(hcd)))
rc = IRQ_NONE;
else if (hcd-driver-irq(hcd) == IRQ_NONE)
@@ -2169,7 +2162,6 @@ irqreturn_t usb_hcd_irq (int irq, void *__hcd)
else
rc = IRQ_HANDLED;
- local_irq_restore(flags);
return rc;
}
EXPORT_SYMBOL_GPL(usb_hcd_irq);
@@ -2358,13 +2350,6 @@ static int usb_hcd_request_irqs(struct usb_hcd *hcd,
if (hcd-driver-irq) {
- /* IRQF_DISABLED doesn't work as advertised when used together
-* with IRQF_SHARED. As usb_hcd_irq() will always disable
-* interrupts we can remove it here.
-*/
- if (irqflags IRQF_SHARED)
- irqflags = ~IRQF_DISABLED;
-
snprintf(hcd-irq_descr, sizeof(hcd-irq_descr), %s:usb%d,
hcd-driver-description, hcd-self.busnum);
retval = request_irq(irqnum, usb_hcd_irq, irqflags,
diff --git a/drivers/usb/host/ehci-ls1x.c b/drivers/usb/host/ehci-ls1x.c
index a283e59..425cb4a 100644
--- a/drivers/usb/host/ehci-ls1x.c
+++ b/drivers/usb/host/ehci-ls1x.c
@@ -119,7 +119,7 @@ static int ehci_hcd_ls1x_probe(struct platform_device *pdev)
goto err_release_region;
}
- ret = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
+ ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto err_iounmap;
diff --git a/drivers/usb/host/ohci-xls.c b/drivers/usb/host/ohci-xls.c
index 41e378f..84201cd 100644
--- a/drivers/usb/host/ohci-xls.c
+++ b/drivers/usb/host/ohci-xls.c
@@ -56,7 +56,7 @@ static int ohci_xls_probe_internal(const struct hc_driver
*driver,
goto err3;
}
- retval = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
+ retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (retval != 0)
goto err4;
return 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
A question on EHCI unlink code
Hi
I am debugging EHCI host system error (4.15.2.4) issue. The issue
happens during unlinking of URB from an interface driver. In our system
the device is always connected to the host. some interfaces are always
active (I/O can happen). Other interface's I/O depends on the user
space. if user opens the device node, we submit IN URB. This issue
happens when unlinking URB upon file close. This issue happens very rarely.
I have a doubt in unlink path of EHCI driver. Say if an endpoint has two
pending IN URB requests at the time of calling unlinking API.
(usb_kill_anchored_urbs API).
The QH's queue of this endpoint looks like this.
Qtd1 -- Qtd2 -- Dummy
EHCI driver kicks in the Async Advance Doorbell handshake after
manipulating the QH horizontal pointer in start_unlink_async() function.
EHCI driver wait for IAAD interrupt from the controller.
Say controller is working on Qtd1. Which means transfer overlay of this
QH has reference to Qtd2. controller generates IAAD interrupt (Qtd1 is
not completely finished. QH active pointer points to Qtd1). EHCI driver
finishes Qtd2 unlinking and points qtd1's next pointer to qtd'2 next
pointer and puts this QH back to asynchronous schedule.
My doubt is that software updated only QTD1 memory to point it to Qtd'2
next pointer i.e dummy. What about the QH's transfer overlay memory?
Would not the controller try to access the Qtd2 when QH is put back into
schedule.
To further clarify my question, I am copy pasting the qh_refresh() code
here. In the below code, if we enter first qtd may already be partially
processed case, should not we update qh-hw-hw_qtd_next and
qh-hw-hw_alt_next to reflect the current Qtd memory.
static void
qh_refresh (struct ehci_hcd *ehci, struct ehci_qh *qh)
{
struct ehci_qtd *qtd;
if (list_empty (qh-qtd_list))
qtd = qh-dummy;
else {
qtd = list_entry (qh-qtd_list.next,
struct ehci_qtd, qtd_list);
/* first qtd may already be partially processed */
if (cpu_to_hc32(ehci, qtd-qtd_dma) == qh-hw-hw_current)
qtd = NULL;
}
if (qtd)
qh_update (ehci, qh, qtd);
}
Thanks,
Pavan
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe 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: [balbi-usb:master 18/19] drivers/usb/musb/musb_core.c:357:21: error: 'struct usb_phy' has no member named 'state'
Sorry for the inconvenience caused. Will push a patch to fix this ASAP. Thanks, Venu -Original Message- From: Fengguang Wu [mailto:fengguang...@intel.com] Sent: Thursday, September 06, 2012 7:41 AM To: Venu Byravarasu Cc: kernel-janit...@vger.kernel.org; Felipe Balbi; linux- o...@vger.kernel.org; linux-usb@vger.kernel.org Subject: [balbi-usb:master 18/19] drivers/usb/musb/musb_core.c:357:21: error: 'struct usb_phy' has no member named 'state' Hi Venu, FYI, kernel build failed on tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master head: 8de3474a41642da9dfb38208844007a48f87abce commit: de4217d90fed1b1714a270ceb5d092f7314e8bda [18/19] usb: otg: Move phy interface to separate file. config: x86_64-allmodconfig (attached as .config) All related error/warning messages: drivers/usb/musb/musb_core.c: In function 'musb_otg_timer_func': drivers/usb/musb/musb_core.c:357:21: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:361:14: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:366:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:369:14: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:372:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c: In function 'musb_hnp_stop': drivers/usb/musb/musb_core.c:388:2: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:390:21: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:393:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:399:14: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:407:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c: In function 'musb_stage0_irq': drivers/usb/musb/musb_core.c:446:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:451:23: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:474:16: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:479:16: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:484:5: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:489:23: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:492:16: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:513:5: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:530:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:542:14: error: 'struct usb_phy' has no member named 'state' -- drivers/usb/musb/musb_gadget.c: In function 'musb_gadget_wakeup': drivers/usb/musb/musb_gadget.c:1630:21: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c:1670:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c: In function 'musb_gadget_start': drivers/usb/musb/musb_gadget.c:1952:13: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c: In function 'musb_gadget_stop': drivers/usb/musb/musb_gadget.c:2063:13: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c: In function 'musb_g_resume': drivers/usb/musb/musb_gadget.c:2096:21: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c:2109:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c: In function 'musb_g_suspend': drivers/usb/musb/musb_gadget.c:2122:21: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c:2125:15: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c:2139:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c: In function 'musb_g_disconnect': drivers/usb/musb/musb_gadget.c:2171:21: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c:2173:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c:2175:14: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c:2179:14: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c:2186:14: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c: In function 'musb_g_reset': drivers/usb/musb/musb_gadget.c:2242:14: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c:2245:14: error: 'struct usb_phy' has no member named 'state' -- drivers/usb/musb/musb_virthub.c: In function 'musb_port_suspend': drivers/usb/musb/musb_virthub.c:81:22: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_virthub.c:83:15: error:
[PATCH] usb: phy: fix build break
During phy interface separation from otg.h, as the enum usb_otg_state
was having multiple otg states info and removal of member 'state'
of this enum type from usb_phy struct did not generate any compilation
issues, I removed member state from struct usb_phy.
As this is causing build break in musb code, adding member 'state'
to usb_phy structure.
Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com
---
include/linux/usb/otg.h | 24
include/linux/usb/phy.h | 25 +
2 files changed, 25 insertions(+), 24 deletions(-)
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 65a2b6a..e8a5fe8 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -11,30 +11,6 @@
#include linux/usb/phy.h
-/* OTG defines lots of enumeration states before device reset */
-enum usb_otg_state {
- OTG_STATE_UNDEFINED = 0,
-
- /* single-role peripheral, and dual-role default-b */
- OTG_STATE_B_IDLE,
- OTG_STATE_B_SRP_INIT,
- OTG_STATE_B_PERIPHERAL,
-
- /* extra dual-role default-b states */
- OTG_STATE_B_WAIT_ACON,
- OTG_STATE_B_HOST,
-
- /* dual-role default-a */
- OTG_STATE_A_IDLE,
- OTG_STATE_A_WAIT_VRISE,
- OTG_STATE_A_WAIT_BCON,
- OTG_STATE_A_HOST,
- OTG_STATE_A_SUSPEND,
- OTG_STATE_A_PERIPHERAL,
- OTG_STATE_A_WAIT_VFALL,
- OTG_STATE_A_VBUS_ERR,
-};
-
struct usb_otg {
u8 default_a;
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 88fc160..06b5bae 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -26,6 +26,30 @@ enum usb_phy_type {
USB_PHY_TYPE_USB3,
};
+/* OTG defines lots of enumeration states before device reset */
+enum usb_otg_state {
+ OTG_STATE_UNDEFINED = 0,
+
+ /* single-role peripheral, and dual-role default-b */
+ OTG_STATE_B_IDLE,
+ OTG_STATE_B_SRP_INIT,
+ OTG_STATE_B_PERIPHERAL,
+
+ /* extra dual-role default-b states */
+ OTG_STATE_B_WAIT_ACON,
+ OTG_STATE_B_HOST,
+
+ /* dual-role default-a */
+ OTG_STATE_A_IDLE,
+ OTG_STATE_A_WAIT_VRISE,
+ OTG_STATE_A_WAIT_BCON,
+ OTG_STATE_A_HOST,
+ OTG_STATE_A_SUSPEND,
+ OTG_STATE_A_PERIPHERAL,
+ OTG_STATE_A_WAIT_VFALL,
+ OTG_STATE_A_VBUS_ERR,
+};
+
struct usb_phy;
struct usb_otg;
@@ -43,6 +67,7 @@ struct usb_phy {
unsigned int flags;
enum usb_phy_type type;
+ enum usb_otg_state state;
enum usb_phy_events last_event;
struct usb_otg *otg;
--
1.7.1.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: [balbi-usb:master 18/19] drivers/usb/musb/musb_core.c:357:21: error: 'struct usb_phy' has no member named 'state'
Hi Venu, On Thu, Sep 06, 2012 at 11:00:22AM +0530, Venu Byravarasu wrote: Hi Fengguang, My apologies for the inconvenience caused. During phy interface separation from otg.h, as the enum usb_otg_state was having multiple otg states info, I felt that should remain in otg.h. Also as removal of member 'state' of this enum type from usb_phy struct did not generate any compilation issues, I removed member state from struct usb_phy. Thank you for the quick fix! As this is causing build break in musb code, I pushed a patch to balbi's tree for fixing this. Also added you as a reviewer in the to list of the patch. Plz verify and let me know if you still see any issues. It should be fine if you already verified the patch with allmodconfig build test. When a commit tagged with Reported-by: Fengguang Wu fengguang...@intel.com is pushed to the git tree, the build system will auto retest it and send me the new success/failure results :-) Thanks, Fengguang -Original Message- From: Fengguang Wu [mailto:fengguang...@intel.com] Sent: Thursday, September 06, 2012 7:41 AM To: Venu Byravarasu Cc: kernel-janit...@vger.kernel.org; Felipe Balbi; linux- o...@vger.kernel.org; linux-usb@vger.kernel.org Subject: [balbi-usb:master 18/19] drivers/usb/musb/musb_core.c:357:21: error: 'struct usb_phy' has no member named 'state' Hi Venu, FYI, kernel build failed on tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master head: 8de3474a41642da9dfb38208844007a48f87abce commit: de4217d90fed1b1714a270ceb5d092f7314e8bda [18/19] usb: otg: Move phy interface to separate file. config: x86_64-allmodconfig (attached as .config) All related error/warning messages: drivers/usb/musb/musb_core.c: In function 'musb_otg_timer_func': drivers/usb/musb/musb_core.c:357:21: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:361:14: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:366:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:369:14: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:372:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c: In function 'musb_hnp_stop': drivers/usb/musb/musb_core.c:388:2: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:390:21: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:393:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:399:14: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:407:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c: In function 'musb_stage0_irq': drivers/usb/musb/musb_core.c:446:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:451:23: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:474:16: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:479:16: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:484:5: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:489:23: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:492:16: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:513:5: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:530:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_core.c:542:14: error: 'struct usb_phy' has no member named 'state' -- drivers/usb/musb/musb_gadget.c: In function 'musb_gadget_wakeup': drivers/usb/musb/musb_gadget.c:1630:21: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c:1670:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c: In function 'musb_gadget_start': drivers/usb/musb/musb_gadget.c:1952:13: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c: In function 'musb_gadget_stop': drivers/usb/musb/musb_gadget.c:2063:13: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c: In function 'musb_g_resume': drivers/usb/musb/musb_gadget.c:2096:21: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c:2109:3: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c: In function 'musb_g_suspend': drivers/usb/musb/musb_gadget.c:2122:21: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c:2125:15: error: 'struct usb_phy' has no member named 'state' drivers/usb/musb/musb_gadget.c:2139:3: error: 'struct usb_phy' has no member named 'state'
