Re: [PATCH] usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller
On Wednesday 16 December 2015 02:26:26 Yoshihiro Shimoda wrote:
> Hi Arnd again,
>
> > From: Yoshihiro Shimoda
> > Sent: Wednesday, December 16, 2015 10:43 AM
> < snip >
> > > > +static void usb3_write(struct renesas_usb3 *usb3, u32 data, u32 offs)
> > > > +{
> > > > + iowrite32(data, usb3->reg + offs);
> > > > +}
> > > > +
> > > > +static u32 usb3_read(struct renesas_usb3 *usb3, u32 offs)
> > > > +{
> > > > + return ioread32(usb3->reg + offs);
> > > > +}
> > >
> > > I think using readl() is more common than ioread32() if the driver cannot
> > > use IORESOURCE_IO but only IORESOURCE_MEM.
> > >
> > > On ARM, the two are the same, but on some architectures ioread32 is more
> > > expensive, so using the former is preferred.
> >
> > I will use {read,write}l() instead of io{read,write}32().
> > Also I will change io{read,write}32_rep() functions too.
>
> Oops. If I used {read,write}sl() instead of io{read,write}32_rep(),
> build error happened in x86 environment.
>
> CC [M] drivers/usb/gadget/udc/renesas_usb3.o
> ./drivers/usb/gadget/udc/renesas_usb3.c: In function 'usb3_write_pipe':
> ./drivers/usb/gadget/udc/renesas_usb3.c:879:3: error: implicit declaration of
> function 'writesl' [-Werror=implicit-function-declaration]
>writesl(usb3->reg + fifo_reg, buf, len / 4);
>^
> ./drivers/usb/gadget/udc/renesas_usb3.c: In function 'usb3_read_pipe':
> ./drivers/usb/gadget/udc/renesas_usb3.c:923:3: error: implicit declaration of
> function 'readsl' [-Werror=implicit-function-declaration]
>readsl(usb3->reg + fifo_reg, buf, len / 4);
>
> So, I will keep to use io{read,write}32(_rep) functions.
Sounds ok. I actually thought we had added readsl to all architectures, but
apparently
we only changed some architectures that needed it in the past.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "usb: chipidea: usbmisc_imx: delete clock information"
Hi Maciej, On Tue, Dec 15, 2015 at 6:19 PM, Maciej S. Szmigiero wrote: > Can we now use this change for repairing the USB support on UDOO board? > > This seems to work fine if not 100% correct: > --- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi > +++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi > @@ -122,7 +122,10 @@ > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_usbh>; > vbus-supply = <®_usb_h1_vbus>; > - clocks = <&clks 201>; > + clocks = <&clks IMX6QDL_CLK_USBOH3>, > +<&clks IMX6QDL_CLK_USBOH3>, > +<&clks 201>; > + clock-names = "ipg", "ahb", "per"; > status = "okay"; Yes, just tested it and this makes USB to work again on Udoo board. As Peter is working on a solution for providing reset and clock to the USB hub, could you please help us debugging his proposal at http://www.spinics.net/lists/linux-usb/msg134171.html ? 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
[PATCH 0/2] net: usb: cdc_ncm: Adding support for two new Dell devices
This patch series add support in the cdc_ncm driver for two devices based on the same platform, that are different only for carrier customization. The devices do not have ARP capabilities. Daniele Palmas (2): net: usb: cdc_ncm: Adding Dell DW5812 LTE Verizon Mobile Broadband Card net: usb: cdc_ncm: Adding Dell DW5813 LTE AT&T Mobile Broadband Card drivers/net/usb/cdc_ncm.c | 14 ++ 1 file changed, 14 insertions(+) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] net: usb: cdc_ncm: Adding Dell DW5813 LTE AT&T Mobile Broadband Card
Dell DW5813 is a mobile broadband card with no ARP capabilities: the patch
makes this device to use wwan_noarp_info struct
Signed-off-by: Daniele Palmas
---
drivers/net/usb/cdc_ncm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 2c0257a..8e971a2 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1600,6 +1600,13 @@ static const struct usb_device_id cdc_devs[] = {
.driver_info = (unsigned long)&wwan_noarp_info,
},
+ /* DW5813 LTE AT&T Mobile Broadband Card */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x413c, 0x81bc,
+ USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&wwan_noarp_info,
+ },
+
/* Dell branded MBM devices like DW5550 */
{ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
| USB_DEVICE_ID_MATCH_VENDOR,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] net: usb: cdc_ncm: Adding Dell DW5812 LTE Verizon Mobile Broadband Card
Dell DW5812 is a mobile broadband card with no ARP capabilities: the patch
makes this device to use wwan_noarp_info struct
Signed-off-by: Daniele Palmas
---
drivers/net/usb/cdc_ncm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index b45e5ca..2c0257a 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1593,6 +1593,13 @@ static const struct usb_device_id cdc_devs[] = {
.driver_info = (unsigned long) &wwan_info,
},
+ /* DW5812 LTE Verizon Mobile Broadband Card */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x413c, 0x81bb,
+ USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&wwan_noarp_info,
+ },
+
/* Dell branded MBM devices like DW5550 */
{ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
| USB_DEVICE_ID_MATCH_VENDOR,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
Hi Peter,
On Wed, Dec 16, 2015 at 2:11 AM, Peter Chen wrote:
> Thanks, Fabio, but I am curious how things like that? The USBOH3 clock
> is not opened, the usb driver will hang when it tries to access
> registers. If this clock is always on, then, why the system will
> hang later?
I found the issue with your patch. You missed to add the pinctrl node.
With the change below USB is functional in Udoo:
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -22,6 +22,8 @@
usb_hub1 {
compatible = "generic-onboard-hub";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh>;
clocks = <&clks IMX6QDL_CLK_CKO>;
reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
reset-duration-us = <2>;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] reset: Add shared reset_control_[de]assert variants
On Mon, Dec 14, 2015 at 10:50:55AM +0100, Philipp Zabel wrote: > Am Montag, den 14.12.2015, 10:36 +0100 schrieb Maxime Ripard: > > Hi, > > > > On Fri, Dec 11, 2015 at 04:41:58PM +0100, Hans de Goede wrote: > > > diff --git a/include/linux/reset.h b/include/linux/reset.h > > > index c4c097d..1cca8ce 100644 > > > --- a/include/linux/reset.h > > > +++ b/include/linux/reset.h > > > @@ -11,6 +11,8 @@ int reset_control_reset(struct reset_control *rstc); > > > int reset_control_assert(struct reset_control *rstc); > > > int reset_control_deassert(struct reset_control *rstc); > > > int reset_control_status(struct reset_control *rstc); > > > +int reset_control_assert_shared(struct reset_control *rstc); > > > +int reset_control_deassert_shared(struct reset_control *rstc); > > > > Shouldn't that be handled in reset_control_get directly? > > This is about different expectations of the caller. > A driver calling reset_control_assert expects the reset line to be > asserted after the call. Is that behaviour documented explicitly somewhere? > A driver calling reset_control_assert_shared > just signals that it doesn't care about the state of the reset line > anymore. > We could just as well call the two new functions > reset_control_deassert_get and reset_control_deassert_put. What happens if you mix them? What happens if you have several drivers ignoring this API? The current default API totally allows to have several drivers getting the same reset line, and happily poking that reset line without any way for the others to A) know they're not the single users B) let them know their device has been reset. And not being able to tell at the consumer level if and when our device is going to be reset behind our back is a big issue. Because then, we simply have to expect it can be reset at any point in time, good luck writing a driver with that expectation. The reset framework should make sure that the shared case is an exception, and not the default case (and make sure that it cannot happen in the default case). Just like for any other framework with similar resources constraints. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[patch] USB: ipaq.c: fix a timeout loop
The code expects the loop to end with "retries" set to zero but, because
it is a post-op, it will end set to -1. I have fixed this by moving the
decrement inside the loop.
Fixes: 014aa2a3c32e ('USB: ipaq: minor ipaq_open() cleanup.')
Signed-off-by: Dan Carpenter
diff --git a/drivers/usb/serial/ipaq.c b/drivers/usb/serial/ipaq.c
index f51a5d5..ec1b8f2 100644
--- a/drivers/usb/serial/ipaq.c
+++ b/drivers/usb/serial/ipaq.c
@@ -531,7 +531,8 @@ static int ipaq_open(struct tty_struct *tty,
* through. Since this has a reasonably high failure rate, we retry
* several times.
*/
- while (retries--) {
+ while (retries) {
+ retries--;
result = usb_control_msg(serial->dev,
usb_sndctrlpipe(serial->dev, 0), 0x22, 0x21,
0x1, 0, NULL, 0, 100);
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] reset: Add shared reset_control_[de]assert variants
Hi Maxime, Am Mittwoch, den 16.12.2015, 11:29 +0100 schrieb Maxime Ripard: > On Mon, Dec 14, 2015 at 10:50:55AM +0100, Philipp Zabel wrote: > > Am Montag, den 14.12.2015, 10:36 +0100 schrieb Maxime Ripard: > > > Hi, > > > > > > On Fri, Dec 11, 2015 at 04:41:58PM +0100, Hans de Goede wrote: > > > > diff --git a/include/linux/reset.h b/include/linux/reset.h > > > > index c4c097d..1cca8ce 100644 > > > > --- a/include/linux/reset.h > > > > +++ b/include/linux/reset.h > > > > @@ -11,6 +11,8 @@ int reset_control_reset(struct reset_control *rstc); > > > > int reset_control_assert(struct reset_control *rstc); > > > > int reset_control_deassert(struct reset_control *rstc); > > > > int reset_control_status(struct reset_control *rstc); > > > > +int reset_control_assert_shared(struct reset_control *rstc); > > > > +int reset_control_deassert_shared(struct reset_control *rstc); > > > > > > Shouldn't that be handled in reset_control_get directly? I think I see your point now. Maybe we should add a flags parameter to reset_control_get and/or wrap it in two versions, reset_control_get_exclusive and reset_control_get_shared (or just add the _shared variant). Then reset_control_get(_exclusive) could return -EBUSY if a reset line is already in use. > > This is about different expectations of the caller. > > A driver calling reset_control_assert expects the reset line to be > > asserted after the call. > > Is that behaviour documented explicitly somewhere? /** * reset_control_assert - asserts the reset line * @rstc: reset controller */ Also, that expected behavior matches the function name, which I like. So I still welcome adding new API calls for the shared/refcounting variant. > > A driver calling reset_control_assert_shared > > just signals that it doesn't care about the state of the reset line > > anymore. > > We could just as well call the two new functions > > reset_control_deassert_get and reset_control_deassert_put. > > What happens if you mix them? What happens if you have several drivers > ignoring this API? The core should give useful error messages and disallow non-shared reset calls on shared lines. > The current default API totally allows to have several drivers getting > the same reset line, and happily poking that reset line without any > way for the others to A) know they're not the single users B) let them > know their device has been reset. That's why I'd like the WARN_ON and error return in reset_control_* when the reset_line reference count is > 1. > And not being able to tell at the consumer level if and when our > device is going to be reset behind our back is a big issue. Because > then, we simply have to expect it can be reset at any point in time, > good luck writing a driver with that expectation. Yes, that is unacceptable. > The reset framework should make sure that the shared case is an > exception, and not the default case (and make sure that it cannot > happen in the default case). Just like for any other framework with > similar resources constraints. regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PROBLEM] usb hub malformed packets causes null pointer dereference
Hello,
We verified the updated patch and everything seems to be ok. All 61 USB hub
testcases pass.
Regards,
/Alex
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Tuesday, December 15, 2015 10:54 PM
To: Cornea, Alexandru
Cc: linux-usb@vger.kernel.org; Maxim, Costel ; Moraru,
Cristina
Subject: RE: [PROBLEM] usb hub malformed packets causes null pointer dereference
On Tue, 15 Dec 2015, Alan Stern wrote:
> On Tue, 15 Dec 2015, Cornea, Alexandru wrote:
>
> > Hello,
> > Apologies for the late response.
> > We tried the patch, and although the system does not crash anymore, another
> > issue occurs.
> > Depending on platform (Gigabyte GXBT, Galileo board), the USB port that is
> > used for testing or all USB ports become blocked and cannot recognize new
> > devices. Also, soft shutdown / reboot seems to hang.
>
>
> I can't figure out the problem from this trace. Were there any other
> tasks blocked like this one?
>
> Please enable USB debugging (echo 'module usbcore =p'
> > /sys/kernel/debug/dynamic_debug/control), run the test again, and
> > post
> the resulting dmesg log.
Never mind, I found the mistake. An updated patch is below.
Alan Stern
Index: usb-4.3/drivers/usb/core/hub.c
===
--- usb-4.3.orig/drivers/usb/core/hub.c
+++ usb-4.3/drivers/usb/core/hub.c
@@ -1031,10 +1031,20 @@ static void hub_activate(struct usb_hub
unsigned delay;
/* Continue a partial initialization */
- if (type == HUB_INIT2)
- goto init2;
- if (type == HUB_INIT3)
+ if (type == HUB_INIT2 || type == HUB_INIT3) {
+ device_lock(hub->intfdev);
+
+ /* Was the hub disconnected while we were waiting? */
+ if (hub->disconnected) {
+ device_unlock(hub->intfdev);
+ kref_put(&hub->kref, hub_release);
+ return;
+ }
+ if (type == HUB_INIT2)
+ goto init2;
goto init3;
+ }
+ kref_get(&hub->kref);
/* The superspeed hub except for root hub has to use Hub Depth
* value as an offset into the route string to locate the bits @@
-1232,6 +1242,7 @@ static void hub_activate(struct usb_hub
queue_delayed_work(system_power_efficient_wq,
&hub->init_work,
msecs_to_jiffies(delay));
+ device_unlock(hub->intfdev);
return; /* Continues at init3: below */
} else {
msleep(delay);
@@ -1253,6 +1264,11 @@ static void hub_activate(struct usb_hub
/* Allow autosuspend if it was suppressed */
if (type <= HUB_INIT3)
usb_autopm_put_interface_async(to_usb_interface(hub->intfdev));
+
+ if (type == HUB_INIT2 || type == HUB_INIT3)
+ device_unlock(hub->intfdev);
+
+ kref_put(&hub->kref, hub_release);
}
/* Implement the continuations for the delays above */
--
To unsubscribe from this list: send the line "unsubscribe 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 BACKPORT] xhci:_don't_finish_a_TD_if_we_get_a_short_transfer_event_mid_TD
Hi,
This original patch was posted and applied to the 4.3-rcX kernel and tagged for
stable kernels.
http://marc.info/?l=linux-usb&m=144463835322214&w=2
But didn't to make it into the 4.1 and 3.14 kernels as it failed
to apply in it's original form.
A backport from Ben Hutchings was posted during the 3.2.73-rc1 review cycle and
will now apply.
Please consider for the next stable kernel release cycle.
Steve Bangert
From: Mathias Nyman
commit e210c422b6fdd2dc123bedc588f399aefd8bf9de upstream.
If the difference is big enough between the bytes asked and received
in a bulk transfer we can get a short transfer event pointing to a TRB in
the middle of the TD. We don't want to handle the TD yet as we will anyway
receive a new event for the last TRB in the TD.
Hold off from finishing the TD and removing it from the list until we
receive an event for the last TRB in the TD
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
Reported-by: Steve Bangert
Cc: # 4.1.x-
Cc: # 3.12.x-
---
drivers/usb/host/xhci-ring.c | 10 ++
1 file changed, 10 insertions(+)
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2187,6 +2187,10 @@ static int process_bulk_intr_td(struct x
EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)));
/* Fast path - was this the last TRB in the TD for this URB? */
if (event_trb == td->last_trb) {
+ if (td->urb_length_set && trb_comp_code == COMP_SHORT_TX)
+ return finish_td(xhci, td, event_trb, event, ep,
+ status, false);
+
if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) {
td->urb->actual_length =
td->urb->transfer_buffer_length -
@@ -2238,6 +2242,12 @@ static int process_bulk_intr_td(struct x
td->urb->actual_length +=
TRB_LEN(le32_to_cpu(cur_trb->generic.field[2]))
-
EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
+
+ if (trb_comp_code == COMP_SHORT_TX) {
+ xhci_dbg(xhci, "mid bulk/intr SP, wait for last TRB
event\n");
+ td->urb_length_set = true;
+ return 0;
+ }
}
return finish_td(xhci, td, event_trb, event, ep, status, false);
--
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PROBLEM] usb hub malformed packets causes null pointer dereference
On Wed, 16 Dec 2015, Cornea, Alexandru wrote: > Hello, > > We verified the updated patch and everything seems to be ok. All 61 USB > hub testcases pass. Thanks for testing. I will submit the patch. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: poweroff-issue with dwc2 on Felipe's testing/next branch
Hi, John Youn writes: > On 12/15/2015 3:49 PM, Heiko Stübner wrote: >> Hi, >> >> it seems the recent dwc2 additions to the testing/next branch [0] caused >> some interesting issue for me. >> >> Setting is a regular 4.4-rc3/4 (only with some display-stuff added), and the >> testing/next branch merged in. >> >> If I attach a single usb device everything still works fine, but once it >> is connected through a hub, like the following: >> >> root@localhost:~# lsusb -t >> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M >> |__ Port 1: Dev 2, If 0, Class=Video, Driver=, 480M >> |__ Port 1: Dev 2, If 1, Class=Video, Driver=, 480M >> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M >> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M >> |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, >> Driver=smsc95xx, 480M >> |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M >> >> I get strange results when powering off the device with the usb device >> still attached. >> >> On regular 4.4-rc3 >> root@localhost:~# poweroff >> ... >> reboot: Power down >> ~20sec delay before actual poweroff >> [that delay is only present with a usb hub in between, probably due to the >> big number of interrupts it creates] >> >> >> With testing/next the device cannot poweroff anymore and instead I get >> [ 40.117160] reboot: Power down >> [ 68.031372] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! >> [systemd-shutdow:1] >> [ 68.046575] Modules linked in: >> [ 68.053084] irq event stamp: 1654975 >> [ 68.060091] hardirqs last enabled at (1654974): [] >> __irq_svc+0x5c/0x78 >> [ 68.074935] hardirqs last disabled at (1654975): [] >> __irq_svc+0x48/0x78 >> [ 68.089666] softirqs last enabled at (1654846): [] >> __do_softirq+0x358/0x49c >> [ 68.105261] softirqs last disabled at (1654847): [] >> irq_exit+0x94/0xd4 >> [ 68.120027] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.4.0-rc4+ >> #2761 >> [ 68.133507] Hardware name: Rockchip (Device Tree) >> [ 68.142690] task: ee900d40 ti: ee902000 task.ti: ee902000 >> [ 68.153237] PC is at rcu_lockdep_current_cpu_online+0x6c/0x90 >> [ 68.164438] LR is at rcu_read_lock_held+0x38/0x58 >> [ 68.173683] pc : []lr : []psr: 00010113 >> [ 68.173683] sp : ee903be8 ip : ee903bf8 fp : ee903bf4 >> [ 68.195300] r10: c0b884f8 r9 : r8 : c0b884f8 >> [ 68.205429] r7 : bccc r6 : eed7f680 r5 : 0001 r4 : ee955800 >> [ 68.217938] r3 : ee902028 r2 : 000f r1 : c0b1891c r0 : 0001 >> [ 68.230482] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment >> none >> [ 68.244141] Control: 10c5387d Table: 2dae806a DAC: 0051 >> [ 68.255283] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.4.0-rc4+ >> #2761 >> [ 68.268720] Hardware name: Rockchip (Device Tree) >> [ 68.278165] [] (unwind_backtrace) from [] >> (show_stack+0x20/0x24) >> [ 68.293198] [] (show_stack) from [] >> (dump_stack+0x84/0xb8) >> [ 68.307285] [] (dump_stack) from [] >> (show_regs+0x1c/0x20) >> [ 68.321205] [] (show_regs) from [] >> (watchdog_timer_fn+0x1c8/0x250) >> [ 68.336579] [] (watchdog_timer_fn) from [] >> (__hrtimer_run_queues+0x2cc/0x55c) >> [ 68.353819] [] (__hrtimer_run_queues) from [] >> (hrtimer_interrupt+0xac/0x1f8) >> [ 68.370795] [] (hrtimer_interrupt) from [] >> (arch_timer_handler_phys+0x38/0x48) >> [ 68.388044] [] (arch_timer_handler_phys) from [] >> (handle_percpu_devid_irq+0x15c/0x314) >> [ 68.406687] [] (handle_percpu_devid_irq) from [] >> (generic_handle_irq+0x28/0x38) >> [ 68.424177] [] (generic_handle_irq) from [] >> (__handle_domain_irq+0x9c/0xc4) >> [ 68.440945] [] (__handle_domain_irq) from [] >> (gic_handle_irq+0x58/0x80) >> [ 68.457054] [] (gic_handle_irq) from [] >> (__irq_svc+0x58/0x78) >> [ 68.471405] Exception stack(0xee903b98 to 0xee903be0) >> [ 68.481288] 3b80: >> 0001 c0b1891c >> [ 68.497074] 3ba0: 000f ee902028 ee955800 0001 eed7f680 bccc >> c0b884f8 >> [ 68.512875] 3bc0: c0b884f8 ee903bf4 ee903bf8 ee903be8 c0094d00 c0095e98 >> 00010113 >> [ 68.528713] [] (__irq_svc) from [] >> (rcu_lockdep_current_cpu_online+0x6c/0x90) >> [ 68.545915] [] (rcu_lockdep_current_cpu_online) from >> [] (rcu_read_lock_held+0x38/0x58) >> [ 68.564535] [] (rcu_read_lock_held) from [] >> (run_rebalance_domains+0x114/0x3e4) >> [ 68.582013] [] (run_rebalance_domains) from [] >> (__do_softirq+0x1d8/0x49c) >> [ 68.598529] [] (__do_softirq) from [] >> (irq_exit+0x94/0xd4) >> [ 68.612591] [] (irq_exit) from [] >> (__handle_domain_irq+0xa0/0xc4) >> [ 68.808119] [] (__handle_domain_irq) from [] >> (gic_handle_irq+0x58/0x80) >> [ 69.004792] [] (gic_handle_irq) from [] >> (__irq_svc+0x58/0x78) >> [ 69.203767] Exception stack(0xee903d20 to 0xee903d68) >> [ 69.402232] 3d20: 0001 0010 c1
Re: [PATCH] usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller
Hi,
Arnd Bergmann writes:
>> +struct renesas_usb3;
>> +struct renesas_usb3_request {
>> +struct usb_request req;
>> +struct list_headqueue;
>> +};
>
> There is already a list_head in struct usb_request. Could you use that?
> (I don't know, just asking because this looks odd)
no, no. Don't do that. The list_head in usb_request is for use by the
gadget drivers and the gadget drivers only.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH v6 0/3] USB MIDI Gadget improvements and bug fixes
Hi Felipe Ferreri Tonello writes: > Hi all, > > On 01/12/15 18:30, Felipe F. Tonello wrote: >> Fixed all comments suggested by the linux-usb list. >> >> changes in v6: >> - Removed patches already applied in Balbi's tree >> - Cleanups on pre-allocation usb requrests patch >> - Fixed indentention on patch 1 >> - Added patch which fails set_alt if a failure happened while >>allocating usb requests >> >> changes in v5: >> - Use ep->enabled insetad of creating driver specific flag >> - Save MIDIStreaming interface id in driver data >> - define free_ep_req as static inline in header >> >> changes in v4: >> - pre-alocation of in requests. >> - more code clean up >> - fix memory leak on out requests >> - configure endpoints only when setting up MIDIStreaming interface >> >> Felipe F. Tonello (3): >> usb: gadget: f_midi: set altsettings only for MIDIStreaming interface >> usb: gadget: f_midi: fail if set_alt fails to allocate requests >> usb: gadget: f_midi: pre-allocate IN requests >> >> drivers/usb/gadget/function/f_midi.c | 175 >> +++ >> drivers/usb/gadget/legacy/gmidi.c| 2 +- >> 2 files changed, 135 insertions(+), 42 deletions(-) >> > > Ping? It should be in my testing/next now, I had to wait until Greg merged fixes to linus before applying. -- balbi signature.asc Description: PGP signature
Re: [PATCH 15/18] usb: dwc2: Improve handling of host and device hwparams
Hi John Youn writes: > On 12/10/2015 2:55 PM, Felipe Balbi wrote: >> >> Hi, >> >> John Youn writes: Interesting. You're getting a new parameter that's never been needed in the code before and (as far as I can tell) isn't used anywhere in your series. I presume this is in prep for a future patch that uses this? At the moment you're burning a decent delay to read this unused parameter (potentially up to 100ms), so hopefully there's a good use for it eventually... >>> >>> I'll remove this from this series. It will be used by the gadget but >>> those changes aren't ready to be submitted yet. >> >> so you're sending this series again ? Seems like I should drop all >> patches from my testing/next ? >> > > Yes I'll resend. You can drop them from your testing/next. all right, dropped the entire series. thanks -- balbi signature.asc Description: PGP signature
Re: [PATCH v2] usb: gadget: ether: Allow changing the MTU
Hi, Mike Looijmans writes: > Just a "ping" reminder, I'd like to inquire about the status of this > patch... in my testing/next -- balbi signature.asc Description: PGP signature
Re: [PATCH v3 0/3] usb: renesas_usbhs: More compat strings
Hi, Simon Horman writes: > Hi, > > this short series adds generic, and soc-specific r8a7792 and r8a7793 compat > strings to the Renesas USBHS driver. The intention is to provide a complete > set of compat strings for known R-Car SoCs. > > Changes since v2: > * Split documentation of SoC names into separate patch > * Use correct fallback compatibility string in example > > Changes since v1: > * Add R-Car Gen2 and Gen3 fallback compatibility strings rather than > a single compatibility string for all of R-Car. > > Simon Horman (3): > usb: renesas_usbhs: add SoC names to compatibility string > documentation > usb: renesas_usbhs: add fallback compatibility strings > usb: renesas_usbhs: add device tree support for r8a779[23] since patch 2 got a few comments, I'll wait a new series. While resending, please collect all Acks to ease my life a bit ;-) cheers -- balbi signature.asc Description: PGP signature
RE: [PATCH v2] usb: gadget: forbid queuing request to a disabled ep
Hi,
"Du, Changbin" writes:
>> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> index 3d583a1..b566a4b 100644
>> --- a/include/linux/usb/gadget.h
>> +++ b/include/linux/usb/gadget.h
>> @@ -402,6 +402,9 @@ static inline void usb_ep_free_request(struct usb_ep
>> *ep,
>> static inline int usb_ep_queue(struct usb_ep *ep,
>> struct usb_request *req, gfp_t gfp_flags)
>> {
>> +if (WARN_ON_ONCE(!ep->enabled))
>> +return -ESHUTDOWN;
>> +
>> return ep->ops->queue(ep, req, gfp_flags);
>> }
>>
>> --
>> 2.5.0
>
> With this patch, ep0 transfer breaks. it because the 'enabled' of ep0
> is not set. Ep0 is not enabled by usb_ep_enable, but in UDC driver. So
> there need another patch to set ep0's flag also.
yeah, we don't like regressions :-) So the fix should come before
$subject to avoid a regression.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH v2 1/1] USB: inode.c: fix unbalanced spin_lock in ep0_write
Hi, David Eccher writes: > Fix bad unlock balance: ep0_write enter with the locks locked from > inode.c:1769, hence it must exit with spinlock held to avoid double > unlock in dev_config. > > Signed-off-by: David Eccher which commit is this fixing ? Do we need this backported to stable kernels ? -- balbi signature.asc Description: PGP signature
Re: [PATCH v2 1/1] USB: inode.c: fix unbalanced spin_lock in ep0_write
Felipe Balbi writes: > Hi, > > David Eccher writes: >> Fix bad unlock balance: ep0_write enter with the locks locked from >> inode.c:1769, hence it must exit with spinlock held to avoid double >> unlock in dev_config. >> >> Signed-off-by: David Eccher > > which commit is this fixing ? Do we need this backported to stable > kernels ? oh, this has been like this since before git came to be. Nevermind. -- balbi signature.asc Description: PGP signature
Re: [PATCH] usb: dwc2: gadget: don't overwrite DCTL register on NAKEFF interrupts
Hi,
Gregory Herrero writes:
> When receiving GINTSTS_GINNAKEFF or GINTSTS_GOUTNAKEFF interrupt,
> DCTL will be overwritten with DCTL_CGOUTNAK or DCTL_CGNPINNAK values.
> Instead of overwriting it, write only needed bits.
>
> It could cause an issue if GINTSTS_GINNAKEFF or GINTSTS_GOUTNAKEFF
> interrupt is received after dwc2 disabled pullup by writing
> DCTL_SFTDISCON bit.
> Pullup will then be re-enabled whereas it should not.
>
> Signed-off-by: Gregory Herrero
John, are you okay with this patch ?
> ---
> drivers/usb/dwc2/gadget.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 0abf73c..311ce49 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -2585,7 +2585,7 @@ irq_retry:
> if (gintsts & GINTSTS_GOUTNAKEFF) {
> dev_info(hsotg->dev, "GOUTNakEff triggered\n");
>
> - dwc2_writel(DCTL_CGOUTNAK, hsotg->regs + DCTL);
> + __orr32(hsotg->regs + DCTL, DCTL_CGOUTNAK);
>
> dwc2_hsotg_dump(hsotg);
> }
> @@ -2593,7 +2593,7 @@ irq_retry:
> if (gintsts & GINTSTS_GINNAKEFF) {
> dev_info(hsotg->dev, "GINNakEff triggered\n");
>
> - dwc2_writel(DCTL_CGNPINNAK, hsotg->regs + DCTL);
> + __orr32(hsotg->regs + DCTL, DCTL_CGNPINNAK);
>
> dwc2_hsotg_dump(hsotg);
> }
> --
> 2.6.2
>
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH] usb: dwc2: fix transfer stop programming for out endpoint
Hi,
changbin...@intel.com writes:
> From: "Du, Changbin"
>
> To stop an out endpoint, software should set sets the Global OUT NAK,
> but not the Global Non-periodic IN NAK. This driver bug leads the out-ep
> failed be in disabled state with below error.
>
> dwc2_hsotg_ep_stop_xfr: timeout DOEPCTL.EPDisable
>
> Signed-off-by: Du, Changbin
John, is this patch okay to apply ?
> ---
> drivers/usb/dwc2/gadget.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 0abf73c..92a182f 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -2911,15 +2911,15 @@ static void dwc2_hsotg_ep_stop_xfr(struct dwc2_hsotg
> *hsotg,
> "%s: timeout DIEPINT.NAKEFF\n", __func__);
> } else {
> /* Clear any pending nak effect interrupt */
> - dwc2_writel(GINTSTS_GINNAKEFF, hsotg->regs + GINTSTS);
> + dwc2_writel(GINTSTS_GOUTNAKEFF, hsotg->regs + GINTSTS);
>
> - __orr32(hsotg->regs + DCTL, DCTL_SGNPINNAK);
> + __orr32(hsotg->regs + DCTL, DCTL_SGOUTNAK);
>
> /* Wait for global nak to take effect */
> if (dwc2_hsotg_wait_bit_set(hsotg, GINTSTS,
> - GINTSTS_GINNAKEFF, 100))
> + GINTSTS_GOUTNAKEFF, 100))
> dev_warn(hsotg->dev,
> - "%s: timeout GINTSTS.GINNAKEFF\n", __func__);
> + "%s: timeout GINTSTS.GOUTNAKEFF\n", __func__);
> }
>
> /* Disable ep */
> @@ -2944,7 +2944,7 @@ static void dwc2_hsotg_ep_stop_xfr(struct dwc2_hsotg
> *hsotg,
> /* TODO: Flush shared tx fifo */
> } else {
> /* Remove global NAKs */
> - __bic32(hsotg->regs + DCTL, DCTL_SGNPINNAK);
> + __bic32(hsotg->regs + DCTL, DCTL_SGOUTNAK);
> }
> }
>
> --
> 2.5.0
>
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH 0/2] net: usb: cdc_ncm: Adding support for two new Dell devices
On Wed, 2015-12-16 at 10:39 +0100, Daniele Palmas wrote: > This patch series add support in the cdc_ncm driver for two devices > based on the same platform, that are different only for carrier > customization. > > The devices do not have ARP capabilities. > > Daniele Palmas (2): > net: usb: cdc_ncm: Adding Dell DW5812 LTE Verizon Mobile Broadband > Card > net: usb: cdc_ncm: Adding Dell DW5813 LTE AT&T Mobile Broadband > Card Quite interesting; Google knows nothing about these devices that I can find. What platform are these based on? But in any case, since these blocks are almost identical to the DW5550 block, maybe update the comments to indicate that they need NOARP unlike the MBM platform that the 5550 is based on? Dan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: poweroff-issue with dwc2 on Felipe's testing/next branch
Hi, On Wed, Dec 16, 2015 at 7:35 AM, Felipe Balbi wrote: > > Hi, > > John Youn writes: >> On 12/15/2015 3:49 PM, Heiko Stübner wrote: >>> Hi, >>> >>> it seems the recent dwc2 additions to the testing/next branch [0] caused >>> some interesting issue for me. >>> >>> Setting is a regular 4.4-rc3/4 (only with some display-stuff added), and the >>> testing/next branch merged in. >>> >>> If I attach a single usb device everything still works fine, but once it >>> is connected through a hub, like the following: >>> >>> root@localhost:~# lsusb -t >>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M >>> |__ Port 1: Dev 2, If 0, Class=Video, Driver=, 480M >>> |__ Port 1: Dev 2, If 1, Class=Video, Driver=, 480M >>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M >>> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M >>> |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, >>> Driver=smsc95xx, 480M >>> |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, >>> 480M >>> >>> I get strange results when powering off the device with the usb device >>> still attached. >>> >>> On regular 4.4-rc3 >>> root@localhost:~# poweroff >>> ... >>> reboot: Power down >>> ~20sec delay before actual poweroff >>> [that delay is only present with a usb hub in between, probably due to the >>> big number of interrupts it creates] >>> >>> >>> With testing/next the device cannot poweroff anymore and instead I get >>> [ 40.117160] reboot: Power down >>> [ 68.031372] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! >>> [systemd-shutdow:1] >>> [ 68.046575] Modules linked in: >>> [ 68.053084] irq event stamp: 1654975 >>> [ 68.060091] hardirqs last enabled at (1654974): [] >>> __irq_svc+0x5c/0x78 >>> [ 68.074935] hardirqs last disabled at (1654975): [] >>> __irq_svc+0x48/0x78 >>> [ 68.089666] softirqs last enabled at (1654846): [] >>> __do_softirq+0x358/0x49c >>> [ 68.105261] softirqs last disabled at (1654847): [] >>> irq_exit+0x94/0xd4 >>> [ 68.120027] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.4.0-rc4+ >>> #2761 >>> [ 68.133507] Hardware name: Rockchip (Device Tree) >>> [ 68.142690] task: ee900d40 ti: ee902000 task.ti: ee902000 >>> [ 68.153237] PC is at rcu_lockdep_current_cpu_online+0x6c/0x90 >>> [ 68.164438] LR is at rcu_read_lock_held+0x38/0x58 >>> [ 68.173683] pc : []lr : []psr: 00010113 >>> [ 68.173683] sp : ee903be8 ip : ee903bf8 fp : ee903bf4 >>> [ 68.195300] r10: c0b884f8 r9 : r8 : c0b884f8 >>> [ 68.205429] r7 : bccc r6 : eed7f680 r5 : 0001 r4 : ee955800 >>> [ 68.217938] r3 : ee902028 r2 : 000f r1 : c0b1891c r0 : 0001 >>> [ 68.230482] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment >>> none >>> [ 68.244141] Control: 10c5387d Table: 2dae806a DAC: 0051 >>> [ 68.255283] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.4.0-rc4+ >>> #2761 >>> [ 68.268720] Hardware name: Rockchip (Device Tree) >>> [ 68.278165] [] (unwind_backtrace) from [] >>> (show_stack+0x20/0x24) >>> [ 68.293198] [] (show_stack) from [] >>> (dump_stack+0x84/0xb8) >>> [ 68.307285] [] (dump_stack) from [] >>> (show_regs+0x1c/0x20) >>> [ 68.321205] [] (show_regs) from [] >>> (watchdog_timer_fn+0x1c8/0x250) >>> [ 68.336579] [] (watchdog_timer_fn) from [] >>> (__hrtimer_run_queues+0x2cc/0x55c) >>> [ 68.353819] [] (__hrtimer_run_queues) from [] >>> (hrtimer_interrupt+0xac/0x1f8) >>> [ 68.370795] [] (hrtimer_interrupt) from [] >>> (arch_timer_handler_phys+0x38/0x48) >>> [ 68.388044] [] (arch_timer_handler_phys) from [] >>> (handle_percpu_devid_irq+0x15c/0x314) >>> [ 68.406687] [] (handle_percpu_devid_irq) from [] >>> (generic_handle_irq+0x28/0x38) >>> [ 68.424177] [] (generic_handle_irq) from [] >>> (__handle_domain_irq+0x9c/0xc4) >>> [ 68.440945] [] (__handle_domain_irq) from [] >>> (gic_handle_irq+0x58/0x80) >>> [ 68.457054] [] (gic_handle_irq) from [] >>> (__irq_svc+0x58/0x78) >>> [ 68.471405] Exception stack(0xee903b98 to 0xee903be0) >>> [ 68.481288] 3b80: >>> 0001 c0b1891c >>> [ 68.497074] 3ba0: 000f ee902028 ee955800 0001 eed7f680 bccc >>> c0b884f8 >>> [ 68.512875] 3bc0: c0b884f8 ee903bf4 ee903bf8 ee903be8 c0094d00 c0095e98 >>> 00010113 >>> [ 68.528713] [] (__irq_svc) from [] >>> (rcu_lockdep_current_cpu_online+0x6c/0x90) >>> [ 68.545915] [] (rcu_lockdep_current_cpu_online) from >>> [] (rcu_read_lock_held+0x38/0x58) >>> [ 68.564535] [] (rcu_read_lock_held) from [] >>> (run_rebalance_domains+0x114/0x3e4) >>> [ 68.582013] [] (run_rebalance_domains) from [] >>> (__do_softirq+0x1d8/0x49c) >>> [ 68.598529] [] (__do_softirq) from [] >>> (irq_exit+0x94/0xd4) >>> [ 68.612591] [] (irq_exit) from [] >>> (__handle_domain_irq+0xa0/0xc4) >>> [ 68.808119] [] (__handle_domain_irq) from [] >>> (gic_handle_irq+0x58/0x80) >>>
Re: poweroff-issue with dwc2 on Felipe's testing/next branch
Hi, Doug Anderson writes: it seems the recent dwc2 additions to the testing/next branch [0] caused some interesting issue for me. Setting is a regular 4.4-rc3/4 (only with some display-stuff added), and the testing/next branch merged in. If I attach a single usb device everything still works fine, but once it is connected through a hub, like the following: root@localhost:~# lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Video, Driver=, 480M |__ Port 1: Dev 2, If 1, Class=Video, Driver=, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M I get strange results when powering off the device with the usb device still attached. On regular 4.4-rc3 root@localhost:~# poweroff ... reboot: Power down ~20sec delay before actual poweroff [that delay is only present with a usb hub in between, probably due to the big number of interrupts it creates] With testing/next the device cannot poweroff anymore and instead I get [ 40.117160] reboot: Power down [ 68.031372] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [systemd-shutdow:1] [ 68.046575] Modules linked in: [ 68.053084] irq event stamp: 1654975 [ 68.060091] hardirqs last enabled at (1654974): [] __irq_svc+0x5c/0x78 [ 68.074935] hardirqs last disabled at (1654975): [] __irq_svc+0x48/0x78 [ 68.089666] softirqs last enabled at (1654846): [] __do_softirq+0x358/0x49c [ 68.105261] softirqs last disabled at (1654847): [] irq_exit+0x94/0xd4 [ 68.120027] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.4.0-rc4+ #2761 [ 68.133507] Hardware name: Rockchip (Device Tree) [ 68.142690] task: ee900d40 ti: ee902000 task.ti: ee902000 [ 68.153237] PC is at rcu_lockdep_current_cpu_online+0x6c/0x90 [ 68.164438] LR is at rcu_read_lock_held+0x38/0x58 [ 68.173683] pc : []lr : []psr: 00010113 [ 68.173683] sp : ee903be8 ip : ee903bf8 fp : ee903bf4 [ 68.195300] r10: c0b884f8 r9 : r8 : c0b884f8 [ 68.205429] r7 : bccc r6 : eed7f680 r5 : 0001 r4 : ee955800 [ 68.217938] r3 : ee902028 r2 : 000f r1 : c0b1891c r0 : 0001 [ 68.230482] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 68.244141] Control: 10c5387d Table: 2dae806a DAC: 0051 [ 68.255283] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.4.0-rc4+ #2761 [ 68.268720] Hardware name: Rockchip (Device Tree) [ 68.278165] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [ 68.293198] [] (show_stack) from [] (dump_stack+0x84/0xb8) [ 68.307285] [] (dump_stack) from [] (show_regs+0x1c/0x20) [ 68.321205] [] (show_regs) from [] (watchdog_timer_fn+0x1c8/0x250) [ 68.336579] [] (watchdog_timer_fn) from [] (__hrtimer_run_queues+0x2cc/0x55c) [ 68.353819] [] (__hrtimer_run_queues) from [] (hrtimer_interrupt+0xac/0x1f8) [ 68.370795] [] (hrtimer_interrupt) from [] (arch_timer_handler_phys+0x38/0x48) [ 68.388044] [] (arch_timer_handler_phys) from [] (handle_percpu_devid_irq+0x15c/0x314) [ 68.406687] [] (handle_percpu_devid_irq) from [] (generic_handle_irq+0x28/0x38) [ 68.424177] [] (generic_handle_irq) from [] (__handle_domain_irq+0x9c/0xc4) [ 68.440945] [] (__handle_domain_irq) from [] (gic_handle_irq+0x58/0x80) [ 68.457054] [] (gic_handle_irq) from [] (__irq_svc+0x58/0x78) [ 68.471405] Exception stack(0xee903b98 to 0xee903be0) [ 68.481288] 3b80: 0001 c0b1891c [ 68.497074] 3ba0: 000f ee902028 ee955800 0001 eed7f680 bccc c0b884f8 [ 68.512875] 3bc0: c0b884f8 ee903bf4 ee903bf8 ee903be8 c0094d00 c0095e98 00010113 [ 68.528713] [] (__irq_svc) from [] (rcu_lockdep_current_cpu_online+0x6c/0x90) [ 68.545915] [] (rcu_lockdep_current_cpu_online) from [] (rcu_read_lock_held+0x38/0x58) [ 68.564535] [] (rcu_read_lock_held) from [] (run_rebalance_domains+0x114/0x3e4) [ 68.582013] [] (run_rebalance_domains) from [] (__do_softirq+0x1d8/0x49c) [ 68.598529] [] (__do_softirq) from [] (irq_exit+0x94/0xd4) [ 68.612591] [] (irq_exit) from [] (__handle_domain_irq+0xa0/0xc4) [ 68.808119] [] (__handle_domain_irq) from [] (gic_handle_irq+0x58/0x80) [ 6
[PATCH v3] extcon: add Maxim MAX3355 driver
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition to sensing/controlling
Vbus, the chip also passes thru the ID signal from the USB OTG connector.
On some Renesas boards, this signal is just fed into the SoC thru a GPIO
pin -- there's no real OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd like to allow host or gadget
drivers to be loaded depending on the cable type, hence the need for the
MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
(however, we aren't currently interested in them), the OFFVBUS# signal is
controlled by the host controllers, there's also the SHDN# signal wired to
a GPIO, it should be driven high for the normal operation.
Signed-off-by: Sergei Shtylyov
---
Changes in version 3:
- reformatted the change log.
Changes in version 2:
- added the USB gadget cable support;
- added the remove() driver method which drives SHDN# GPIO low to save power;
- dropped vendor prefix from the ID GPIO property name;
- changed the GPIO property name suffix to "-gpios";
- switched to usign extcon_set_cable_state_() API;
- switched to using the gpiod/sleeping 'gpiolib' APIs;
- addded error messages to max3355_probe();
- added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
- renamed 'ret' variable to 'err' in max3355_probe();
- expanded the Kconfig entry help text;
- added vendor name to the patch summary, the bindings document, the Kconfig
entry, the driver heading comment, the module description, and the change log;
- fixed up and reformatted the change log.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
drivers/extcon/Kconfig |8
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 153
4 files changed, 183 insertions(+)
Index: renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+Maxim Integrated MAX3355 USB OTG chip
+-
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO
pin
+ connected to the MAX3355's SHDN# pin;
+- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the MAX3355's ID_OUT pin.
+
+Example (Koelsch board):
+
+ usb-otg {
+ compatible = "maxim,max3355";
+ maxim,shdn-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
+ id-gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>;
+ };
Index: renesas/drivers/extcon/Kconfig
===
--- renesas.orig/drivers/extcon/Kconfig
+++ renesas/drivers/extcon/Kconfig
@@ -52,6 +52,14 @@ config EXTCON_MAX14577
Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port accessory
detector and switch.
+config EXTCON_MAX3355
+ tristate "Maxim MAX3355 USB OTG EXTCON Support"
+ help
+ If you say yes here you get support for the USB OTG role detection by
+ MAX3355. The MAX3355 chip integrates a charge pump and comparators to
+ enable a system with an integrated USB OTG dual-role transceiver to
+ function as an USB OTG dual-role device.
+
config EXTCON_MAX77693
tristate "Maxim MAX77693 EXTCON Support"
depends on MFD_MAX77693 && INPUT
Index: renesas/drivers/extcon/Makefile
===
--- renesas.orig/drivers/extcon/Makefile
+++ renesas/drivers/extcon/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-a
obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_MAX14577) += extcon-max14577.o
+obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o
obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX77843) += extcon-max77843.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
Index: renesas/drivers/extcon/extcon-max3355.c
===
--- /dev/null
+++ renesas/drivers/extcon/extcon-max3355.c
@@ -0,0 +1,153 @@
+/*
+ * Maxim Integrated MAX3355 USB OTG chip extcon driver
+ *
+ * Copyright (C) 2014 Cogent Embedded, Inc.
+ * Author: Sergei Shtylyov
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied
[PATCH] USB: fix invalid memory access in hub_activate()
Commit 8520f38099cc ("USB: change hub initialization sleeps to
delayed_work") changed the hub_activate() routine to make part of it
run in a workqueue. However, the commit failed to take a reference to
the usb_hub structure or to lock the hub interface while doing so. As
a result, if a hub is plugged in and quickly unplugged before the work
routine can run, the routine will try to access memory that has been
deallocated. Or, if the hub is unplugged while the routine is
running, the memory may be deallocated while it is in active use.
This patch fixes the problem by taking a reference to the usb_hub at
the start of hub_activate() and releasing it at the end (when the work
is finished), and by locking the hub interface while the work routine
is running. It also adds a check at the start of the routine to see
if the hub has already been disconnected, in which nothing should be
done.
Signed-off-by: Alan Stern
Reported-by: Alexandru Cornea
Tested-by: Alexandru Cornea
Fixes: 8520f38099cc ("USB: change hub initialization sleeps to delayed_work")
CC:
[as1791]
drivers/usb/core/hub.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
Index: usb-4.3/drivers/usb/core/hub.c
===
--- usb-4.3.orig/drivers/usb/core/hub.c
+++ usb-4.3/drivers/usb/core/hub.c
@@ -1031,10 +1031,20 @@ static void hub_activate(struct usb_hub
unsigned delay;
/* Continue a partial initialization */
- if (type == HUB_INIT2)
- goto init2;
- if (type == HUB_INIT3)
+ if (type == HUB_INIT2 || type == HUB_INIT3) {
+ device_lock(hub->intfdev);
+
+ /* Was the hub disconnected while we were waiting? */
+ if (hub->disconnected) {
+ device_unlock(hub->intfdev);
+ kref_put(&hub->kref, hub_release);
+ return;
+ }
+ if (type == HUB_INIT2)
+ goto init2;
goto init3;
+ }
+ kref_get(&hub->kref);
/* The superspeed hub except for root hub has to use Hub Depth
* value as an offset into the route string to locate the bits
@@ -1232,6 +1242,7 @@ static void hub_activate(struct usb_hub
queue_delayed_work(system_power_efficient_wq,
&hub->init_work,
msecs_to_jiffies(delay));
+ device_unlock(hub->intfdev);
return; /* Continues at init3: below */
} else {
msleep(delay);
@@ -1253,6 +1264,11 @@ static void hub_activate(struct usb_hub
/* Allow autosuspend if it was suppressed */
if (type <= HUB_INIT3)
usb_autopm_put_interface_async(to_usb_interface(hub->intfdev));
+
+ if (type == HUB_INIT2 || type == HUB_INIT3)
+ device_unlock(hub->intfdev);
+
+ kref_put(&hub->kref, hub_release);
}
/* Implement the continuations for the delays above */
--
To unsubscribe from this list: send the line "unsubscribe 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: poweroff-issue with dwc2 on Felipe's testing/next branch
Hi, On Wed, Dec 16, 2015 at 9:36 AM, Doug Anderson wrote: > Hi, > > On Wed, Dec 16, 2015 at 7:35 AM, Felipe Balbi wrote: >> >> Hi, >> >> John Youn writes: >>> On 12/15/2015 3:49 PM, Heiko Stübner wrote: Hi, it seems the recent dwc2 additions to the testing/next branch [0] caused some interesting issue for me. Setting is a regular 4.4-rc3/4 (only with some display-stuff added), and the testing/next branch merged in. If I attach a single usb device everything still works fine, but once it is connected through a hub, like the following: root@localhost:~# lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Video, Driver=, 480M |__ Port 1: Dev 2, If 1, Class=Video, Driver=, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M I get strange results when powering off the device with the usb device still attached. On regular 4.4-rc3 root@localhost:~# poweroff ... reboot: Power down ~20sec delay before actual poweroff [that delay is only present with a usb hub in between, probably due to the big number of interrupts it creates] With testing/next the device cannot poweroff anymore and instead I get [ 40.117160] reboot: Power down [ 68.031372] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [systemd-shutdow:1] [ 68.046575] Modules linked in: [ 68.053084] irq event stamp: 1654975 [ 68.060091] hardirqs last enabled at (1654974): [] __irq_svc+0x5c/0x78 [ 68.074935] hardirqs last disabled at (1654975): [] __irq_svc+0x48/0x78 [ 68.089666] softirqs last enabled at (1654846): [] __do_softirq+0x358/0x49c [ 68.105261] softirqs last disabled at (1654847): [] irq_exit+0x94/0xd4 [ 68.120027] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.4.0-rc4+ #2761 [ 68.133507] Hardware name: Rockchip (Device Tree) [ 68.142690] task: ee900d40 ti: ee902000 task.ti: ee902000 [ 68.153237] PC is at rcu_lockdep_current_cpu_online+0x6c/0x90 [ 68.164438] LR is at rcu_read_lock_held+0x38/0x58 [ 68.173683] pc : []lr : []psr: 00010113 [ 68.173683] sp : ee903be8 ip : ee903bf8 fp : ee903bf4 [ 68.195300] r10: c0b884f8 r9 : r8 : c0b884f8 [ 68.205429] r7 : bccc r6 : eed7f680 r5 : 0001 r4 : ee955800 [ 68.217938] r3 : ee902028 r2 : 000f r1 : c0b1891c r0 : 0001 [ 68.230482] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 68.244141] Control: 10c5387d Table: 2dae806a DAC: 0051 [ 68.255283] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.4.0-rc4+ #2761 [ 68.268720] Hardware name: Rockchip (Device Tree) [ 68.278165] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [ 68.293198] [] (show_stack) from [] (dump_stack+0x84/0xb8) [ 68.307285] [] (dump_stack) from [] (show_regs+0x1c/0x20) [ 68.321205] [] (show_regs) from [] (watchdog_timer_fn+0x1c8/0x250) [ 68.336579] [] (watchdog_timer_fn) from [] (__hrtimer_run_queues+0x2cc/0x55c) [ 68.353819] [] (__hrtimer_run_queues) from [] (hrtimer_interrupt+0xac/0x1f8) [ 68.370795] [] (hrtimer_interrupt) from [] (arch_timer_handler_phys+0x38/0x48) [ 68.388044] [] (arch_timer_handler_phys) from [] (handle_percpu_devid_irq+0x15c/0x314) [ 68.406687] [] (handle_percpu_devid_irq) from [] (generic_handle_irq+0x28/0x38) [ 68.424177] [] (generic_handle_irq) from [] (__handle_domain_irq+0x9c/0xc4) [ 68.440945] [] (__handle_domain_irq) from [] (gic_handle_irq+0x58/0x80) [ 68.457054] [] (gic_handle_irq) from [] (__irq_svc+0x58/0x78) [ 68.471405] Exception stack(0xee903b98 to 0xee903be0) [ 68.481288] 3b80: 0001 c0b1891c [ 68.497074] 3ba0: 000f ee902028 ee955800 0001 eed7f680 bccc c0b884f8 [ 68.512875] 3bc0: c0b884f8 ee903bf4 ee903bf8 ee903be8 c0094d00 c0095e98 00010113 [ 68.528713] [] (__irq_svc) from [] (rcu_lockdep_current_cpu_online+0x6c/0x90) [ 68.545915] [] (rcu_lockdep_current_cpu_online) from [] (rcu_read_lock_held+0x38/0x58) [ 68.564535] [] (rcu_read_lock_held) from [] (run_rebalance_domains+0x114/0x3e4) [ 68.582013] [] (run_rebalance_domains) from [] (__do_softirq+0x1d8/0x49c) [ 68.598529] [] (__do_softirq) from [] (irq_
Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
Hi Fabio,
Hi Peter,
On 16.12.2015 11:11, Fabio Estevam wrote:
> Hi Peter,
>
> On Wed, Dec 16, 2015 at 2:11 AM, Peter Chen wrote:
>
>> Thanks, Fabio, but I am curious how things like that? The USBOH3 clock
>> is not opened, the usb driver will hang when it tries to access
>> registers. If this clock is always on, then, why the system will
>> hang later?
>
> I found the issue with your patch. You missed to add the pinctrl node.
>
> With the change below USB is functional in Udoo:
>
> --- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> @@ -22,6 +22,8 @@
>
> usb_hub1 {
> compatible = "generic-onboard-hub";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbh>;
> clocks = <&clks IMX6QDL_CLK_CKO>;
> reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
> reset-duration-us = <2>;
>
Thanks for your work, I didn't notice it previously (sorry).
I can confirm, too that with Peter's patches and the above change
the USB support works again on my UDOO DualLite board.
However, I noticed that when you have host USB support configured to be
build as modules then (due to its location under "if USB") it is only
possible to compile generic onboard USB HUB as module, too.
Then this module would need to be loaded before loading USB support
(or quickly after it), otherwise USB enumeration would time out after
few secs and loading it later wouldn't help.
Currently, this driver doesn't really need any USB host support and
is able to be compiled-in successfully regardless of USB host support
configuration with just small change to Makefile and Kconfig.
However I don't know if it is a design goal to not use USB host support
or just a current development status, but if it doesn't really need it
then it would be great if it could be selected to be build-in into kernel
regardless of host USB support setting.
Best regards,
Maciej Szmigiero
--
To unsubscribe from this list: send the line "unsubscribe 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 15/18] usb: dwc2: Improve handling of host and device hwparams
On 12/16/2015 8:08 AM, Felipe Balbi wrote: > > Hi > > John Youn writes: >> On 12/10/2015 2:55 PM, Felipe Balbi wrote: >>> >>> Hi, >>> >>> John Youn writes: > Interesting. You're getting a new parameter that's never been needed > in the code before and (as far as I can tell) isn't used anywhere in > your series. I presume this is in prep for a future patch that uses > this? > > At the moment you're burning a decent delay to read this unused > parameter (potentially up to 100ms), so hopefully there's a good use > for it eventually... I'll remove this from this series. It will be used by the gadget but those changes aren't ready to be submitted yet. >>> >>> so you're sending this series again ? Seems like I should drop all >>> patches from my testing/next ? >>> >> >> Yes I'll resend. You can drop them from your testing/next. > > all right, dropped the entire series. > > thanks > Thanks. I'm still tracking down some issues with this. Hopefully resend soon. Regards, John -- To unsubscribe from this list: send the line "unsubscribe 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: dwc2: fix transfer stop programming for out endpoint
On 12/16/2015 8:58 AM, Felipe Balbi wrote: > > Hi, > > changbin...@intel.com writes: >> From: "Du, Changbin" >> >> To stop an out endpoint, software should set sets the Global OUT NAK, >> but not the Global Non-periodic IN NAK. This driver bug leads the out-ep >> failed be in disabled state with below error. >> >> dwc2_hsotg_ep_stop_xfr: timeout DOEPCTL.EPDisable >> >> Signed-off-by: Du, Changbin > > John, is this patch okay to apply ? > Yes. Looks good to me. Acked-by: John Youn John -- To unsubscribe from this list: send the line "unsubscribe 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: dwc2: gadget: don't overwrite DCTL register on NAKEFF interrupts
On 12/16/2015 8:58 AM, Felipe Balbi wrote: > > Hi, > > Gregory Herrero writes: >> When receiving GINTSTS_GINNAKEFF or GINTSTS_GOUTNAKEFF interrupt, >> DCTL will be overwritten with DCTL_CGOUTNAK or DCTL_CGNPINNAK values. >> Instead of overwriting it, write only needed bits. >> >> It could cause an issue if GINTSTS_GINNAKEFF or GINTSTS_GOUTNAKEFF >> interrupt is received after dwc2 disabled pullup by writing >> DCTL_SFTDISCON bit. >> Pullup will then be re-enabled whereas it should not. >> >> Signed-off-by: Gregory Herrero > > John, are you okay with this patch ? > Acked-by: John Youn John -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
On Mon, Dec 14, 2015 at 3:35 AM, Arnd Bergmann wrote: > On Monday 14 December 2015 15:26:11 Peter Chen wrote: >> Hi all, >> >> There is a known issue that the USB code can't handle USB HUB's >> external pins well, in that case, it may cause some onboard >> USB HUBs can't work since their PHY's clock or reset pin needs to >> operate. >> >> The user reported this issue at below: >> http://www.spinics.net/lists/linux-usb/msg131502.html >> >> In this patch set, I add a generic onboard USB HUB driver to >> handle this problem, the external signals will be configured >> before usb controller's initialization, it much likes we did >> it at board code before. >> >> The user needs to add this generic hub node at dts to support it. >> >> @The udoo users, help to test please. > > I still think need to do this properly by representing the hub > device as a USB device, using power sequencing code like MMC does. I agree on doing it properly, but am not sure that pwrseq binding for MMC is proper. The pwrseq binding is fairly limited and working around the driver model IMO. Hubs may also need I2C setup which I don't think could be done generically other than some defined sequence of i2c transactions. The current project I'm working on needs to use I2C to configure the hub to use HSIC mode for example. I really think we need a pre-probe driver hook to handle this. That would allow device specific setup to live in the driver. Perhaps a more simple approach would be just forcing driver probe if a DT node is present. I'm not all that familiar with USB drivers, but presumably there is some setup before probe like setting the USB device address. We'd have to allow doing that later during probe. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
On Wednesday 16 December 2015 16:59:39 Rob Herring wrote: > On Mon, Dec 14, 2015 at 3:35 AM, Arnd Bergmann wrote: > > On Monday 14 December 2015 15:26:11 Peter Chen wrote: > > I agree on doing it properly, but am not sure that pwrseq binding for > MMC is proper. The pwrseq binding is fairly limited and working around > the driver model IMO. Hubs may also need I2C setup which I don't think > could be done generically other than some defined sequence of i2c > transactions. The current project I'm working on needs to use I2C to > configure the hub to use HSIC mode for example. I really think we need > a pre-probe driver hook to handle this. That would allow device > specific setup to live in the driver. > > Perhaps a more simple approach would be just forcing driver probe if a > DT node is present. I'm not all that familiar with USB drivers, but > presumably there is some setup before probe like setting the USB > device address. We'd have to allow doing that later during probe. Yes, good idea. I was also advocating that approach for MMC at some point, but the power sequencing made it in the end. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] extcon: add Maxim MAX3355 driver
2015-12-17 3:07 GMT+09:00 Sergei Shtylyov :
> Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
> enable a system with an integrated USB OTG dual-role transceiver to
> function as an USB OTG dual-role device. In addition to sensing/controlling
> Vbus, the chip also passes thru the ID signal from the USB OTG connector.
> On some Renesas boards, this signal is just fed into the SoC thru a GPIO
> pin -- there's no real OTG controller, only host and gadget USB controllers
> sharing the same USB bus; however, we'd like to allow host or gadget
> drivers to be loaded depending on the cable type, hence the need for the
> MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
> (however, we aren't currently interested in them), the OFFVBUS# signal is
> controlled by the host controllers, there's also the SHDN# signal wired to
> a GPIO, it should be driven high for the normal operation.
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> Changes in version 3:
> - reformatted the change log.
>
> Changes in version 2:
> - added the USB gadget cable support;
> - added the remove() driver method which drives SHDN# GPIO low to save power;
> - dropped vendor prefix from the ID GPIO property name;
> - changed the GPIO property name suffix to "-gpios";
> - switched to usign extcon_set_cable_state_() API;
> - switched to using the gpiod/sleeping 'gpiolib' APIs;
> - addded error messages to max3355_probe();
> - added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
> - renamed 'ret' variable to 'err' in max3355_probe();
> - expanded the Kconfig entry help text;
> - added vendor name to the patch summary, the bindings document, the Kconfig
> entry, the driver heading comment, the module description, and the change
> log;
> - fixed up and reformatted the change log.
>
> Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
> drivers/extcon/Kconfig |8
> drivers/extcon/Makefile |1
> drivers/extcon/extcon-max3355.c | 153
>
> 4 files changed, 183 insertions(+)
>
> Index: renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> ===
> --- /dev/null
> +++ renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> @@ -0,0 +1,21 @@
> +Maxim Integrated MAX3355 USB OTG chip
> +-
> +
> +MAX3355 integrates a charge pump and comparators to enable a system with an
> +integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
> +device.
> +
> +Required properties:
> +- compatible: should be "maxim,max3355";
> +- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO
> pin
> + connected to the MAX3355's SHDN# pin;
Could you add some indentation to the wrapped line for this property?
For readability.
> +- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
> + connected to the MAX3355's ID_OUT pin.
Ditto.
Why this property lacks the vendor prefix i(n comparison to shdn-gpios
which has the prefix)?
> +
> +Example (Koelsch board):
> +
> + usb-otg {
> + compatible = "maxim,max3355";
> + maxim,shdn-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
> + id-gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>;
> + };
> Index: renesas/drivers/extcon/Kconfig
> ===
> --- renesas.orig/drivers/extcon/Kconfig
> +++ renesas/drivers/extcon/Kconfig
> @@ -52,6 +52,14 @@ config EXTCON_MAX14577
> Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port
> accessory
> detector and switch.
>
> +config EXTCON_MAX3355
> + tristate "Maxim MAX3355 USB OTG EXTCON Support"
> + help
> + If you say yes here you get support for the USB OTG role detection
> by
> + MAX3355. The MAX3355 chip integrates a charge pump and comparators
> to
> + enable a system with an integrated USB OTG dual-role transceiver to
> + function as an USB OTG dual-role device.
> +
> config EXTCON_MAX77693
> tristate "Maxim MAX77693 EXTCON Support"
> depends on MFD_MAX77693 && INPUT
> Index: renesas/drivers/extcon/Makefile
> ===
> --- renesas.orig/drivers/extcon/Makefile
> +++ renesas/drivers/extcon/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-a
> obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
> obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
> obj-$(CONFIG_EXTCON_MAX14577) += extcon-max14577.o
> +obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o
> obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
> obj-$(CONFIG_EXTCON_MAX77843) += extcon-max77843.o
> obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> Index: renesas/drivers/extcon/extcon-max3355.c
> =
Re: [PATCH v3] extcon: add Maxim MAX3355 driver
Hi Sergei,
On 2015년 12월 17일 03:07, Sergei Shtylyov wrote:
> Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
> enable a system with an integrated USB OTG dual-role transceiver to
> function as an USB OTG dual-role device. In addition to sensing/controlling
> Vbus, the chip also passes thru the ID signal from the USB OTG connector.
> On some Renesas boards, this signal is just fed into the SoC thru a GPIO
> pin -- there's no real OTG controller, only host and gadget USB controllers
> sharing the same USB bus; however, we'd like to allow host or gadget
> drivers to be loaded depending on the cable type, hence the need for the
> MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
> (however, we aren't currently interested in them), the OFFVBUS# signal is
> controlled by the host controllers, there's also the SHDN# signal wired to
> a GPIO, it should be driven high for the normal operation.
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> Changes in version 3:
> - reformatted the change log.
>
> Changes in version 2:
> - added the USB gadget cable support;
> - added the remove() driver method which drives SHDN# GPIO low to save power;
> - dropped vendor prefix from the ID GPIO property name;
> - changed the GPIO property name suffix to "-gpios";
> - switched to usign extcon_set_cable_state_() API;
> - switched to using the gpiod/sleeping 'gpiolib' APIs;
> - addded error messages to max3355_probe();
> - added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
> - renamed 'ret' variable to 'err' in max3355_probe();
> - expanded the Kconfig entry help text;
> - added vendor name to the patch summary, the bindings document, the Kconfig
> entry, the driver heading comment, the module description, and the change
> log;
> - fixed up and reformatted the change log.
>
> Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
> drivers/extcon/Kconfig |8
> drivers/extcon/Makefile |1
> drivers/extcon/extcon-max3355.c | 153
>
> 4 files changed, 183 insertions(+)
>
> Index: renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> ===
> --- /dev/null
> +++ renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> @@ -0,0 +1,21 @@
> +Maxim Integrated MAX3355 USB OTG chip
> +-
> +
> +MAX3355 integrates a charge pump and comparators to enable a system with an
> +integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
> +device.
> +
> +Required properties:
> +- compatible: should be "maxim,max3355";
> +- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO
> pin
> + connected to the MAX3355's SHDN# pin;
> +- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
> + connected to the MAX3355's ID_OUT pin.
> +
> +Example (Koelsch board):
> +
> + usb-otg {
> + compatible = "maxim,max3355";
> + maxim,shdn-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
> + id-gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>;
> + };
> Index: renesas/drivers/extcon/Kconfig
> ===
> --- renesas.orig/drivers/extcon/Kconfig
> +++ renesas/drivers/extcon/Kconfig
> @@ -52,6 +52,14 @@ config EXTCON_MAX14577
> Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port accessory
> detector and switch.
>
> +config EXTCON_MAX3355
> + tristate "Maxim MAX3355 USB OTG EXTCON Support"
> + help
> + If you say yes here you get support for the USB OTG role detection by
> + MAX3355. The MAX3355 chip integrates a charge pump and comparators to
> + enable a system with an integrated USB OTG dual-role transceiver to
> + function as an USB OTG dual-role device.
> +
> config EXTCON_MAX77693
> tristate "Maxim MAX77693 EXTCON Support"
> depends on MFD_MAX77693 && INPUT
> Index: renesas/drivers/extcon/Makefile
> ===
> --- renesas.orig/drivers/extcon/Makefile
> +++ renesas/drivers/extcon/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA) += extcon-a
> obj-$(CONFIG_EXTCON_AXP288) += extcon-axp288.o
> obj-$(CONFIG_EXTCON_GPIO)+= extcon-gpio.o
> obj-$(CONFIG_EXTCON_MAX14577)+= extcon-max14577.o
> +obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o
> obj-$(CONFIG_EXTCON_MAX77693)+= extcon-max77693.o
> obj-$(CONFIG_EXTCON_MAX77843)+= extcon-max77843.o
> obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> Index: renesas/drivers/extcon/extcon-max3355.c
> ===
> --- /dev/null
> +++ renesas/drivers/extcon/extcon-max3355.c
> @@ -0,0 +1,153 @@
> +/*
> + * Maxim Integrated MAX3355 USB OTG chip extco
Re: [PATCH v3] extcon: add Maxim MAX3355 driver
Hi,
On 2015년 12월 17일 11:16, Chanwoo Choi wrote:
> Hi Sergei,
>
> On 2015년 12월 17일 03:07, Sergei Shtylyov wrote:
>> Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
>> enable a system with an integrated USB OTG dual-role transceiver to
>> function as an USB OTG dual-role device. In addition to sensing/controlling
>> Vbus, the chip also passes thru the ID signal from the USB OTG connector.
>> On some Renesas boards, this signal is just fed into the SoC thru a GPIO
>> pin -- there's no real OTG controller, only host and gadget USB controllers
>> sharing the same USB bus; however, we'd like to allow host or gadget
>> drivers to be loaded depending on the cable type, hence the need for the
>> MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
>> (however, we aren't currently interested in them), the OFFVBUS# signal is
>> controlled by the host controllers, there's also the SHDN# signal wired to
>> a GPIO, it should be driven high for the normal operation.
>>
>> Signed-off-by: Sergei Shtylyov
>>
>> ---
>> Changes in version 3:
>> - reformatted the change log.
>>
>> Changes in version 2:
>> - added the USB gadget cable support;
>> - added the remove() driver method which drives SHDN# GPIO low to save power;
>> - dropped vendor prefix from the ID GPIO property name;
>> - changed the GPIO property name suffix to "-gpios";
>> - switched to usign extcon_set_cable_state_() API;
>> - switched to using the gpiod/sleeping 'gpiolib' APIs;
>> - addded error messages to max3355_probe();
>> - added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
>> - renamed 'ret' variable to 'err' in max3355_probe();
>> - expanded the Kconfig entry help text;
>> - added vendor name to the patch summary, the bindings document, the Kconfig
>> entry, the driver heading comment, the module description, and the change
>> log;
>> - fixed up and reformatted the change log.
>>
>> Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
>> drivers/extcon/Kconfig |8
>> drivers/extcon/Makefile |1
>> drivers/extcon/extcon-max3355.c | 153
>>
>> 4 files changed, 183 insertions(+)
>>
[snip]
>> +return 0;
>> +}
>> +
>> +static int max3355_remove(struct platform_device *pdev)
>> +{
>> +struct max3355_data *data = platform_get_drvdata(pdev);
>> +
>> +gpiod_set_value_cansleep(data->shdn_gpiod, 0);
Don't need to handle the 'shdn' gpio on resume/suspend funtcion?
But, if the interrput of id gpio is used for wakeup source,
there is no reason to handle it for suspend mode.
[snip]
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
On Thu, Dec 17, 2015 at 12:13:07AM +0100, Arnd Bergmann wrote:
> On Wednesday 16 December 2015 16:59:39 Rob Herring wrote:
> > On Mon, Dec 14, 2015 at 3:35 AM, Arnd Bergmann wrote:
> > > On Monday 14 December 2015 15:26:11 Peter Chen wrote:
> >
> > I agree on doing it properly, but am not sure that pwrseq binding for
> > MMC is proper. The pwrseq binding is fairly limited and working around
> > the driver model IMO. Hubs may also need I2C setup which I don't think
> > could be done generically other than some defined sequence of i2c
> > transactions. The current project I'm working on needs to use I2C to
> > configure the hub to use HSIC mode for example. I really think we need
> > a pre-probe driver hook to handle this. That would allow device
> > specific setup to live in the driver.
> >
> > Perhaps a more simple approach would be just forcing driver probe if a
> > DT node is present. I'm not all that familiar with USB drivers, but
> > presumably there is some setup before probe like setting the USB
> > device address. We'd have to allow doing that later during probe.
>
> Yes, good idea. I was also advocating that approach for MMC at some
> point, but the power sequencing made it in the end.
>
Currently, my design is much like Rob proposal's. I will populate all
children device under HUB's node (controller = 1st level hub), and
each special onboard USB device needs a platform driver, it can be
probed according to compatible string, and at its probe, it can register
itself as usb device if needed, and handle properties described at
its node. Sample code like below:
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 8263fc1..7451f7d 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -590,6 +590,16 @@
&usbh1 {
vbus-supply = <®_usb_h1_vbus>;
status = "okay";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hub: usb2415@01 {
+ compatible = "generic-onboard-hub";
+ reg = <0x01>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ reset-duration-us = <10>;
+ };
};
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 5e32ce7..2107b12 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1334,6 +1335,20 @@ static int hub_post_reset(struct usb_interface *intf)
return 0;
}
+static int hub_of_children_register(struct usb_device *hdev)
+{
+ struct device *dev;
+
+ if (hdev->parent)
+ dev = &hdev->dev;
+ else
+ dev = bus_to_hcd(hdev->bus)->self.controller;
+ if (!dev->of_node)
+ return 0;
+
+ return of_platform_populate(dev->of_node, NULL, NULL, dev);
+}
+
static int hub_configure(struct usb_hub *hub,
struct usb_endpoint_descriptor *endpoint)
{
@@ -1701,6 +1716,7 @@ static int hub_probe(struct usb_interface *intf, const
struct usb_device_id *id)
struct usb_endpoint_descriptor *endpoint;
struct usb_device *hdev;
struct usb_hub *hub;
+ int ret;
desc = intf->cur_altsetting;
hdev = interface_to_usbdev(intf);
@@ -1820,6 +1836,12 @@ descriptor_error:
if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
hub->quirk_check_port_auto_suspend = 1;
+ ret = hub_of_children_register(hdev);
+ if (ret) {
+ dev_err(&hdev->dev, "Failed to register child device\n");
+ return ret;
+ }
+
if (hub_configure(hub, endpoint) >= 0)
return 0;
At onboard general usb hub driver:
static const struct of_device_id usb_hub_generic_dt_ids[] = {
{.compatible = "generic-onboard-hub"},
{ },
};
MODULE_DEVICE_TABLE(of, usb_hub_generic_dt_ids);
static struct platform_driver usb_hub_generic_driver = {
.probe = usb_hub_generic_probe,
.remove = usb_hub_generic_remove,
.driver = {
.name = "usb_hub_generic_onboard",
.of_match_table = usb_hub_generic_dt_ids,
},
};
static int __init usb_hub_generic_init(void)
{
return platform_driver_register(&usb_hub_generic_driver);
}
subsys_initcall(usb_hub_generic_init);
static void __exit usb_hub_generic_exit(void)
{
platform_driver_unregister(&usb_hub_generic_driver);
}
module_exit(usb_hub_generic_exit);
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
On Wed, Dec 16, 2015 at 09:05:35PM +0100, Maciej S. Szmigiero wrote:
> Hi Fabio,
> Hi Peter,
>
> On 16.12.2015 11:11, Fabio Estevam wrote:
> > Hi Peter,
> >
> > On Wed, Dec 16, 2015 at 2:11 AM, Peter Chen
> > wrote:
> >
> >> Thanks, Fabio, but I am curious how things like that? The USBOH3 clock
> >> is not opened, the usb driver will hang when it tries to access
> >> registers. If this clock is always on, then, why the system will
> >> hang later?
> >
> > I found the issue with your patch. You missed to add the pinctrl node.
> >
> > With the change below USB is functional in Udoo:
> >
> > --- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> > @@ -22,6 +22,8 @@
> >
> > usb_hub1 {
> > compatible = "generic-onboard-hub";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usbh>;
> > clocks = <&clks IMX6QDL_CLK_CKO>;
> > reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
> > reset-duration-us = <2>;
> >
>
> Thanks for your work, I didn't notice it previously (sorry).
>
> I can confirm, too that with Peter's patches and the above change
> the USB support works again on my UDOO DualLite board.
>
> However, I noticed that when you have host USB support configured to be
> build as modules then (due to its location under "if USB") it is only
> possible to compile generic onboard USB HUB as module, too.
>
> Then this module would need to be loaded before loading USB support
> (or quickly after it), otherwise USB enumeration would time out after
> few secs and loading it later wouldn't help.
Thanks for testing it, it maybe this hardware limitation.
The USB device should be back to work whenever do hardware reset,
otherwise, this reset is not clean.
>
> Currently, this driver doesn't really need any USB host support and
> is able to be compiled-in successfully regardless of USB host support
> configuration with just small change to Makefile and Kconfig.
>
> However I don't know if it is a design goal to not use USB host support
> or just a current development status, but if it doesn't really need it
> then it would be great if it could be selected to be build-in into kernel
> regardless of host USB support setting.
>
Yes, you are right, this driver is totally unrelated with ANY usb, but
it intends to handle general USB device which needs to have platform
control, and USB device is on the USB bus. Currently, if you are
USB stuff, you must depends of host or gadget support.
For this special hardware, you may have to define module load sequence
for your loadable support, it the current develop stage, maybe it can
be changed in future, I don't know when.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
