Re: dwc2 gadget issues
On 02/28/2017 02:44 PM, Vardan Mikayelyan wrote: On 2/28/2017 3:44 PM, Francesco Lavra wrote: Hi Vardan, On 02/28/2017 09:41 AM, Vardan Mikayelyan wrote: On 2/27/2017 11:55 PM, Francesco Lavra wrote: Hi, On 02/23/2017 08:27 PM, Heiko Stuebner wrote: Hi Francesco, Am Donnerstag, 23. Februar 2017, 19:11:37 CET schrieb Francesco Lavra: I'm having trouble getting the RK3288 OTG controller (the one at ff58) to work in peripheral mode. I'm using a Firefly Reload board, and I know the hardware is fine because I can successfully use the port in device mode with U-Boot's mass storage gadget driver. Under Linux, the OTG port works fine when used in host mode, but fails to work in device mode: nothing happens when the a USB host is plugged into the OTG port, not even a single interrupt is generated by the controller. I'm using the latest device tree definitions from git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git. you shouldn't use my tree as base for any real work :-) . Best to use the regular mainline kernel or alternatively try linux-next to get all recent usb changes schedules for the next release. Thanks for your inputs. I was actually using the mainline kernel (4.8.1), in which the dwc2 driver wasn't working, that's why I went to your tree to pick up any fixes or new features that might have been done. I also went to the linux-usb tree for the same reason. Anyway, today I tried with the latest mainline release 4.10.0, and also with linux-next. Unfortunately, still no luck: I can load a gadget driver, which gets correctly bound to the OTG controller, but then nothing happens if a USB host is connected to the OTG port. I'm pasting below the dmesg contents (obtained with 4.10.0, with verbose debugging enabled for the dwc2 driver) when a gadget driver is loaded, in case you might spot something suspicious: [ 1147.035367] dwc2 ff58.usb: bound driver g_audio [ 1147.041203] dwc2 ff58.usb: dwc2_hsotg_pullup: is_on: 1 op_state: 3 [ 1147.041250] dwc2 ff58.usb: dwc2_core_reset() [ 1147.041345] dwc2 ff58.usb: FIFOs reset, timeout at 100 [ 1147.041405] dwc2 ff58.usb: EP0: DIEPCTL0=0x8000, DOEPCTL0=0x8000 [ 1147.041447] dwc2 ff58.usb: gsintmsk now 0xd08c3cc4 [ 1147.041554] dwc2 ff58.usb: DCTL=0x0002 [ 1147.041631] dwc2 ff58.usb: dwc2_hsotg_enqueue_setup: queueing setup request [ 1147.041692] dwc2 ff58.usb: ep0: req ee241680: 8@ee241198, noi=0, zero=0, snok=0 [ 1147.041757] dwc2 ff58.usb: dwc2_hsotg_start_req: DxEPCTL=0x80008000, ep 0, dir out [ 1147.041799] dwc2 ff58.usb: ureq->length:8 ureq->actual:0 [ 1147.041896] dwc2 ff58.usb: dwc2_hsotg_start_req: 1@8/8, 0x00080008 => 0x0b10 [ 1147.041975] dwc2 ff58.usb: dwc2_hsotg_start_req: 2e243000 pad => 0x0b14 [ 1147.042014] dwc2 ff58.usb: ep0 state:0 [ 1147.042055] dwc2 ff58.usb: dwc2_hsotg_start_req: DxEPCTL=0x80008000 [ 1147.042097] dwc2 ff58.usb: dwc2_hsotg_start_req: DXEPCTL=0x80008000 [ 1147.042169] dwc2 ff58.usb: EP0: DIEPCTL0=0x8000, DOEPCTL0=0x80008000 Thanks, Francesco -- Hi Francesco, Could you please provide full log (with debugs enabled) from DWC2 driver loading to issue point? Two logs are not giving us the full picture. The full log from the DWC2 driver is below: [1.498030] dwc2 ff58.usb: ff58.usb supply vusb_d not found, using dummy regulator [1.507431] dwc2 ff58.usb: ff58.usb supply vusb_a not found, using dummy regulator [1.880012] dwc2 ff58.usb: dwc2_check_param_tx_fifo_sizes: Invalid parameter g-tx-fifo-size, setting to default average [1.892596] dwc2 ff58.usb: EPs: 10, dedicated fifos, 972 entries in SPRAM [1.901018] dwc2 ff58.usb: DCFG=0x0810, DCTL=0x0002, DIEPMSK= [1.909432] dwc2 ff58.usb: GAHBCFG=0x, GHWCFG1=0x6664 [1.916698] dwc2 ff58.usb: GRXFSIZ=0x0400, GNPTXFSIZ=0x00100400 [1.924161] dwc2 ff58.usb: DPTx[1] FSize=256, StAddr=0x0410 [1.931224] dwc2 ff58.usb: DPTx[2] FSize=256, StAddr=0x0900 [1.938261] dwc2 ff58.usb: DPTx[3] FSize=256, StAddr=0x0a00 [1.945318] dwc2 ff58.usb: DPTx[4] FSize=256, StAddr=0x0b00 [1.952375] dwc2 ff58.usb: DPTx[5] FSize=256, StAddr=0x0c00 [1.959410] dwc2 ff58.usb: DPTx[6] FSize=256, StAddr=0x0d00 [1.966456] dwc2 ff58.usb: DPTx[7] FSize=0, StAddr=0x0e00 [1.973317] dwc2 ff58.usb: DPTx[8] FSize=0, StAddr=0x0f00 [1.980180] dwc2 ff58.usb: DPTx[9] FSize=256, StAddr=0x0410 [1.987216] dwc2 ff58.usb: ep0-in: EPCTL=0x8800, SIZ=0x, DMA=0x379a4f2d [1.996232] dwc2 ff58.usb: ep0-out: EPCTL=0x8000, SIZ=0x, DMA=0xe3103c4f [2.005352] dwc2 ff58.usb: ep1-in: EPCTL=0x1000, SIZ=0x, DMA=0x5cf9a35d [2.014369] dwc2 ff58.usb: ep1-out: EPCTL=0x, SIZ=0x, DMA=0x8b00a168 [2.023482] dwc2 ff58.usb: ep2-in: EPCTL=0x, SIZ=0x
Re: Question: Does usbip support USB 3.0?
On Tue, Feb 28, 2017 at 04:57:46PM +0100, Krzysztof Opasiak wrote: > >On Thu, Feb 23, 2017 at 07:43:23AM +, Du, Yuyang wrote: > >>Oh, then let me try to simplify it, what if it's an only USB 3.0 device? > > > >I have a USB keyboard around here somewhere that is a "USB 3.0" device, > >that is running at the USB "low speed" rate. :) > > > >Again, USB 3.0 supports all speed devices, see the spec for all of the > >details. > > > > Just to add what Greg said: > > vhci (virtual host controller for usbip) itself is high speed and > does not support stuff like streams etc. which are included in USB > 3.0 spec so you won't be able to connect USB device in super speed > mode via usbip. > > So if your device supports high speed mode it will work fine. If > your device doesn't work with speed lower than super speed then you > won't be able to use it via usbip. This thread (spinics.net/lists/linux-usb/msg126276.html) taught me (dummy on USB) a little bit about it. Thank you, both. Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] usb: dwc3: remove dwc3_log_msg trace class
dwc3_log_msg trace class isn't used any more. Suggest to remove it.
Signed-off-by: Lu Baolu
---
drivers/usb/dwc3/trace.h | 25 -
1 file changed, 25 deletions(-)
diff --git a/drivers/usb/dwc3/trace.h b/drivers/usb/dwc3/trace.h
index 2b124f9..69671e4 100644
--- a/drivers/usb/dwc3/trace.h
+++ b/drivers/usb/dwc3/trace.h
@@ -27,31 +27,6 @@
#include "core.h"
#include "debug.h"
-DECLARE_EVENT_CLASS(dwc3_log_msg,
- TP_PROTO(struct va_format *vaf),
- TP_ARGS(vaf),
- TP_STRUCT__entry(__dynamic_array(char, msg, DWC3_MSG_MAX)),
- TP_fast_assign(
- vsnprintf(__get_str(msg), DWC3_MSG_MAX, vaf->fmt, *vaf->va);
- ),
- TP_printk("%s", __get_str(msg))
-);
-
-DEFINE_EVENT(dwc3_log_msg, dwc3_gadget,
- TP_PROTO(struct va_format *vaf),
- TP_ARGS(vaf)
-);
-
-DEFINE_EVENT(dwc3_log_msg, dwc3_core,
- TP_PROTO(struct va_format *vaf),
- TP_ARGS(vaf)
-);
-
-DEFINE_EVENT(dwc3_log_msg, dwc3_ep0,
- TP_PROTO(struct va_format *vaf),
- TP_ARGS(vaf)
-);
-
DECLARE_EVENT_CLASS(dwc3_log_io,
TP_PROTO(void *base, u32 offset, u32 value),
TP_ARGS(base, offset, value),
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] usb: gadget: dummy_hcd: clear usb_gadget region before registration
On Tue, Feb 28, 2017 at 11:07:08AM -0500, Alan Stern wrote:
> On Tue, 28 Feb 2017, Peter Chen wrote:
>
> > When the user does device unbind and rebind test, the kernel will
> > show below dump due to usb_gadget memory region is dirty after unbind.
> > Clear usb_gadget region for every new probe.
> >
> > root@imx6qdlsolo:/sys/bus/platform/drivers/dummy_udc# echo dummy_udc.0 >
> > bind
> > [ 102.523312] kobject (eddd78b0): tried to init an initialized object,
> > something is seriously wrong.
> > [ 102.532447] CPU: 0 PID: 734 Comm: sh Not tainted
> > 4.10.0-rc7-00872-g1b2b8e9 #1298
> > [ 102.539866] Hardware name: Freescale i.MX6 SoloX (Device Tree)
> > [ 102.545717] Backtrace:
> > [ 102.548225] [] (dump_backtrace) from []
> > (show_stack+0x18/0x1c)
> > [ 102.555822] r7:ede34000 r6:60010013 r5: r4:c0f29418
> > [ 102.561512] [] (show_stack) from []
> > (dump_stack+0xb4/0xe8)
> > [ 102.568764] [] (dump_stack) from []
> > (kobject_init+0x80/0x9c)
> > [ 102.576187] r10:001f r9:eddd7000 r8:eeaf8c10 r7:eddd78a8
> > r6:c177891c r5:c0f3b060
> > [ 102.584036] r4:eddd78b0 r3:
> > [ 102.587641] [] (kobject_init) from []
> > (device_initialize+0x28/0xf8)
> > [ 102.595665] r5:eebc4800 r4:eddd78a8
> > [ 102.599268] [] (device_initialize) from []
> > (device_register+0x14/0x20)
> > [ 102.607556] r7:eddd78a8 r6: r5:eebc4800 r4:eddd78a8
> > [ 102.613256] [] (device_register) from []
> > (usb_add_gadget_udc_release+0x8c/0x1ec)
> > [ 102.622410] r5:eebc4800 r4:eddd7860
> > [ 102.626015] [] (usb_add_gadget_udc_release) from []
> > (usb_add_gadget_udc+0x14/0x18)
> > [ 102.635351] r10:001f r9:eddd7000 r8:eddd788c r7:bf003770
> > r6:eddd77f8 r5:eddd7818
> > [ 102.643198] r4:eddd785c r3:eddd7b24
> > [ 102.646834] [] (usb_add_gadget_udc) from []
> > (dummy_udc_probe+0x170/0x1c4 [dummy_hcd])
> > [ 102.656458] [] (dummy_udc_probe [dummy_hcd]) from []
> > (platform_drv_probe+0x54/0xb8)
> > [ 102.665881] r10:0008 r9:c1778960 r8:bf004128 r7:fdfb
> > r6:bf004128 r5:eeaf8c10
> > [ 102.673727] r4:eeaf8c10
> > [ 102.676293] [] (platform_drv_probe) from []
> > (driver_probe_device+0x264/0x474)
> > [ 102.685186] r7: r6: r5:c1778960 r4:eeaf8c10
> > [ 102.690876] [] (driver_probe_device) from []
> > (bind_store+0xb8/0x14c)
> > [ 102.698994] r10:eeb3bb4c r9:ede34000 r8:000c r7:eeaf8c44
> > r6:bf004128 r5:c0f3b668
> > [ 102.706840] r4:eeaf8c10
> > [ 102.709402] [] (bind_store) from []
> > (drv_attr_store+0x28/0x34)
> > [ 102.716998] r9:ede34000 r8: r7:ee3863c0 r6:ee3863c0 r5:c0538c80
> > r4:c053970c
> > [ 102.724776] [] (drv_attr_store) from []
> > (sysfs_kf_write+0x50/0x54)
> > [ 102.732711] r5:c0538c80 r4:000c
> > [ 102.736313] [] (sysfs_kf_write) from []
> > (kernfs_fop_write+0x100/0x214)
> > [ 102.744599] r7:ee3863c0 r6:eeb3bb40 r5: r4:
> > [ 102.750287] [] (kernfs_fop_write) from []
> > (__vfs_write+0x34/0x120)
> > [ 102.758231] r10: r9:ede34000 r8:c0108bc4 r7:000c
> > r6:ede35f80 r5:c029bd84
> > [ 102.766077] r4:ee223780
> > [ 102.768638] [] (__vfs_write) from []
> > (vfs_write+0xa8/0x170)
> > [ 102.775974] r9:ede34000 r8:c0108bc4 r7:ede35f80 r6:01861cb0 r5:ee223780
> > r4:000c
> > [ 102.783743] [] (vfs_write) from []
> > (SyS_write+0x4c/0xa8)
> > [ 102.790818] r9:ede34000 r8:c0108bc4 r7:000c r6:01861cb0 r5:ee223780
> > r4:ee223780
> > [ 102.798595] [] (SyS_write) from []
> > (ret_fast_syscall+0x0/0x1c)
> > [ 102.806188] r7:0004 r6:b6e83d58 r5:01861cb0 r4:000c
> >
> > Cc: Alan Stern
> > Cc: stable
> > Fixes: 90fccb529d24 ("usb: gadget: Gadget directory cleanup - group UDC
> > drivers")
> > Signed-off-by: Peter Chen
> > Tested-by: Xiaolong Ye
> > Reported-by: Fengguang Wu
> > ---
> > drivers/usb/gadget/udc/dummy_hcd.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/usb/gadget/udc/dummy_hcd.c
> > b/drivers/usb/gadget/udc/dummy_hcd.c
> > index c60abe3..8cabc59 100644
> > --- a/drivers/usb/gadget/udc/dummy_hcd.c
> > +++ b/drivers/usb/gadget/udc/dummy_hcd.c
> > @@ -1031,6 +1031,8 @@ static int dummy_udc_probe(struct platform_device
> > *pdev)
> > int rc;
> >
> > dum = *((void **)dev_get_platdata(&pdev->dev));
> > + /* Clear usb_gadget region for new registration to udc-core */
> > + memzero_explicit(&dum->gadget, sizeof(struct usb_gadget));
> > dum->gadget.name = gadget_name;
> > dum->gadget.ops = &dummy_ops;
> > dum->gadget.max_speed = USB_SPEED_SUPER;
>
> Wouldn't it be better to clear the entire structure, not just
> dum->gadget? Then you could also change
>
> dum[i] = kzalloc(sizeof(struct dummy), GFP_KERNEL);
>
> to use kmalloc, since the structure will be initialized by the probe
> routine.
>
The memory region of dum is shared between dummy_hcd and dummy_udc.
If clear entire dum, the entries for dummy_hcd will be cleared.
--
Best Regards
[PATCH] usb: gadget: add RNDIS configfs option for Windows rndiscmp.inf compatibility
This adds a new configfs attribute named `use_ms_rndiscmp`. It is a
boolean value that is used to select the class/subclass/protocol used
by the RNDIS function interface association descriptor. By default,
this is 0x02 (Comm), 0x06 (Ethernet), 0xff (None). When the
use_ms_rndiscmp attribute is set to true, the values 0xef (Misc),
0x04 (RNDIS), 0x01 (Ethernet) will be used instead. This class/subclass/
protocol combination is recognized by the rndiscmp.inf file in Windows
Vista and newer and will cause Windows to load the correct RNDIS driver
without the need for a custom (signed) .inf file.
Signed-off-by: David Lechner
---
.../ABI/testing/configfs-usb-gadget-rndis | 3 ++
drivers/usb/gadget/function/f_rndis.c | 48 ++
drivers/usb/gadget/function/u_rndis.h | 1 +
include/uapi/linux/usb/misc.h | 14 +++
4 files changed, 66 insertions(+)
create mode 100644 include/uapi/linux/usb/misc.h
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-rndis
b/Documentation/ABI/testing/configfs-usb-gadget-rndis
index e32879b..bb4b5a85 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-rndis
+++ b/Documentation/ABI/testing/configfs-usb-gadget-rndis
@@ -12,3 +12,6 @@ Description:
Ethernet over USB link
dev_addr- MAC address of device's end of this
Ethernet over USB link
+ use_ms_rndiscmp - Use the MS Windows rndiscmp.inf compatible
+ class 0xEF, subclass 0x04, protocol 0x01
+ instead of the default 0x02/0x06/0x00.
diff --git a/drivers/usb/gadget/function/f_rndis.c
b/drivers/usb/gadget/function/f_rndis.c
index 16562e4..b92f4f4 100644
--- a/drivers/usb/gadget/function/f_rndis.c
+++ b/drivers/usb/gadget/function/f_rndis.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
@@ -692,6 +693,18 @@ rndis_bind(struct usb_configuration *c, struct
usb_function *f)
}
/*
+* Starting with Vista, Windows will match this Class/SubClass/Protocol
+* with rndiscmp.inf and load the proper driver without the need for a
+* custom .inf.
+* Ref: https://msdn.microsoft.com/library/ff538820(v=vs.85).aspx
+*/
+ if (rndis_opts->use_ms_rndiscmp) {
+ rndis_iad_descriptor.bFunctionClass = USB_CLASS_MISC;
+ rndis_iad_descriptor.bFunctionSubClass =
USB_MISC_SUBCLASS_RNDIS;
+ rndis_iad_descriptor.bFunctionProtocol =
USB_MISC_RNDIS_PROTO_ENET;
+ }
+
+ /*
* in drivers/usb/gadget/configfs.c:configfs_composite_bind()
* configurations are bound in sequence with list_for_each_entry,
* in each configuration its functions are bound in sequence
@@ -866,11 +879,46 @@ USB_ETHERNET_CONFIGFS_ITEM_ATTR_QMULT(rndis);
/* f_rndis_opts_ifname */
USB_ETHERNET_CONFIGFS_ITEM_ATTR_IFNAME(rndis);
+static ssize_t
+rndis_opts_use_ms_rndiscmp_show(struct config_item *item, char *page)
+{
+ struct f_rndis_opts *opts = to_f_rndis_opts(item);
+ int ret;
+
+ mutex_lock(&opts->lock);
+ ret = sprintf(page, "%d\n", opts->use_ms_rndiscmp);
+ mutex_unlock(&opts->lock);
+
+ return ret;
+}
+
+static ssize_t
+rndis_opts_use_ms_rndiscmp_store(struct config_item *item, const char *page,
+size_t len)
+{
+ struct f_rndis_opts *opts = to_f_rndis_opts(item);
+ int ret;
+ bool use;
+
+ mutex_lock(&opts->lock);
+ ret = strtobool(page, &use);
+ if (!ret) {
+ opts->use_ms_rndiscmp = use;
+ ret = len;
+ }
+ mutex_unlock(&opts->lock);
+
+ return ret;
+}
+
+CONFIGFS_ATTR(rndis_opts_, use_ms_rndiscmp);
+
static struct configfs_attribute *rndis_attrs[] = {
&rndis_opts_attr_dev_addr,
&rndis_opts_attr_host_addr,
&rndis_opts_attr_qmult,
&rndis_opts_attr_ifname,
+ &rndis_opts_attr_use_ms_rndiscmp,
NULL,
};
diff --git a/drivers/usb/gadget/function/u_rndis.h
b/drivers/usb/gadget/function/u_rndis.h
index 4eafd50..03f241f 100644
--- a/drivers/usb/gadget/function/u_rndis.h
+++ b/drivers/usb/gadget/function/u_rndis.h
@@ -25,6 +25,7 @@ struct f_rndis_opts {
struct net_device *net;
boolbound;
boolborrowed_net;
+ booluse_ms_rndiscmp;
struct usb_os_desc rndis_os_desc;
charrndis_ext_compat_id[16];
diff --git a/include/uapi/linux/usb/misc.h b/include/uapi/linux/usb/misc.h
new file mode 100644
index 000..a6661f6
--- /dev/null
+++ b/include/uapi/linux/usb/misc.h
@@ -0,0 +1,14 @@
+/*
+ * USB Miscellaneous Device Class definitions
+ *
+ * Ref: http://www.usb.org/developers/defined_class/#BaseClassEFh
+ */
+
+#ifn
Re: [PATCH] usb-storage: Add ignore-residue quirk for Initio INIC-3619
On Tue, 28 Feb 2017, Tobias Jakobi wrote: > This USB-SATA bridge chip is used in a StarTech enclosure for > optical drives. > > Without the quirk MakeMKV fails during the key exchange with an > installed BluRay drive: > > Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - > > KEY NOT ESTABLISHED' > > occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:2' > > Signed-off-by: Tobias Jakobi > --- > drivers/usb/storage/unusual_devs.h | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/drivers/usb/storage/unusual_devs.h > b/drivers/usb/storage/unusual_devs.h > index 16cc183..9129f6c 100644 > --- a/drivers/usb/storage/unusual_devs.h > +++ b/drivers/usb/storage/unusual_devs.h > @@ -2071,6 +2071,20 @@ UNUSUAL_DEV( 0x1370, 0x6828, 0x0110, 0x0110, > USB_SC_DEVICE, USB_PR_DEVICE, NULL, > US_FL_IGNORE_RESIDUE ), > > +/* > + * Reported by Tobias Jakobi > + * The INIC-3619 bridge is used in the StarTech SLSODDU33B > + * SATA-USB enclosure for slimline optical drives. > + * > + * The quirk enables MakeMKV to properly exchange keys with > + * an installed BD drive. > + */ > +UNUSUAL_DEV( 0x13fd, 0x3609, 0x0209, 0x0209, > + "Initio Corporation", > + "INIC-3619", > + USB_SC_DEVICE, USB_PR_DEVICE, NULL, > + US_FL_IGNORE_RESIDUE ), > + > /* Reported by Qinglin Ye */ > UNUSUAL_DEV( 0x13fe, 0x3600, 0x0100, 0x0100, > "Kingston", Acked-by: Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: storage: karma: remove useless variable
Remove the useless variable 'partial' storing the actual length
transferred. Nothing was done with it, so simply get rid of it
as usb_stor_bulk_transfer_buf can handle having NULL instead.
This also fixes the following sparse issues (-Wtypesign):
drivers/usb/storage/karma.c:122:51: warning: incorrect type in argument
5 (different signedness)
drivers/usb/storage/karma.c:122:51:expected unsigned int *act_len
drivers/usb/storage/karma.c:122:51:got int *
drivers/usb/storage/karma.c:127:52: warning: incorrect type in argument
5 (different signedness)
drivers/usb/storage/karma.c:127:52:expected unsigned int *act_len
drivers/usb/storage/karma.c:127:52:got int *
Signed-off-by: Pierre-Yves Kerbrat
---
drivers/usb/storage/karma.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/storage/karma.c b/drivers/usb/storage/karma.c
index f9d407f0b508..b05ba4929f00 100644
--- a/drivers/usb/storage/karma.c
+++ b/drivers/usb/storage/karma.c
@@ -105,7 +105,7 @@ static struct us_unusual_dev karma_unusual_dev_list[] = {
*/
static int rio_karma_send_command(char cmd, struct us_data *us)
{
- int result, partial;
+ int result;
unsigned long timeout;
static unsigned char seq = 1;
struct karma_data *data = (struct karma_data *) us->extra;
@@ -119,12 +119,12 @@ static int rio_karma_send_command(char cmd, struct
us_data *us)
timeout = jiffies + msecs_to_jiffies(6000);
for (;;) {
result = usb_stor_bulk_transfer_buf(us, us->send_bulk_pipe,
- us->iobuf, RIO_SEND_LEN, &partial);
+ us->iobuf, RIO_SEND_LEN, NULL);
if (result != USB_STOR_XFER_GOOD)
goto err;
result = usb_stor_bulk_transfer_buf(us, us->recv_bulk_pipe,
- data->recv, RIO_RECV_LEN, &partial);
+ data->recv, RIO_RECV_LEN, NULL);
if (result != USB_STOR_XFER_GOOD)
goto err;
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb/net/hso: WARNING: ungligned urb->setup_dma
Hi Stefan,
On Tue, Feb 28, 2017 at 05:21:18PM +0100, Stefan Wahren wrote:
> Am 28.02.2017 um 13:01 schrieb Baruch Siach:
> > On Tue, Feb 28, 2017 at 10:28:10AM +0200, Baruch Siach wrote:
> > > I'm hitting this warning consistently on my Raspberry Pi 3 running
> > > kernel
> > > v4.10.1 with some unrelated device tree changes, and a debug print
> > > (below).
> > > The device identifies as "GlobeTrotter HSDPA Modem", VID: 0af0, PID: 6971.
> > > The warning triggers consistently on first write access to /dev/ttyHS0
> > > that
> > > ModemManager attempts. The first line in the log is my debug print.
> > I tested the same hardware successfully on an i.MX6 CuBox-i (ARM32) using
> > the
> > same kernel version (4.10.1), and on an x86_64 PC (4.9). So this seems to be
> > platform specific. I don't have any other ARM64 machine at the moment,
> > though.
>
> those platforms usually doesn't use the dwc2 USB host controller. So it
> should be tested with another dwc2 platform.
The code that initializes setup_dma is not under drivers/usb/dwc2/. Though the
problem looks like memory corruption, so its cause might be anywhere.
> Is the issue reproducible with other USB devices like keyboards?
Other USB devices, including a different cellular USB dongle, do not exhibit
the same problem.
> Are you using arm64 defconfig?
I'm using that attached arm64 defconfig.
> Are you able to bisect this issue?
I don't have any previously working point.
Thanks,
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_AUDIT=y
CONFIG_NO_HZ_IDLE=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_BLK_CGROUP=y
CONFIG_CGROUP_PIDS=y
CONFIG_CGROUP_HUGETLB=y
CONFIG_CPUSETS=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_PERF=y
CONFIG_USER_NS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_BLK_DEV_INITRD=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
CONFIG_KALLSYMS_ALL=y
# CONFIG_COMPAT_BRK is not set
CONFIG_PROFILING=y
CONFIG_JUMP_LABEL=y
CONFIG_BLK_DEV_INTEGRITY=y
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_ARCH_BCM2835=y
CONFIG_ARM64_VA_BITS_48=y
CONFIG_SCHED_MC=y
CONFIG_HOTPLUG_CPU=y
CONFIG_PREEMPT=y
CONFIG_KSM=y
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_CMA=y
CONFIG_SECCOMP=y
CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyS0,115200"
CONFIG_CMDLINE_FORCE=y
# CONFIG_EFI is not set
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_COMPAT=y
# CONFIG_SUSPEND is not set
CONFIG_PM=y
CONFIG_CPU_IDLE=y
CONFIG_ARM_CPUIDLE=y
CONFIG_CPU_FREQ=y
CONFIG_CPUFREQ_DT=y
CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_NETFILTER=y
CONFIG_NF_CONNTRACK=y
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NETFILTER_XT_TARGET_CHECKSUM=y
CONFIG_NETFILTER_XT_TARGET_LOG=y
CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=y
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_MANGLE=y
CONFIG_NF_CONNTRACK_IPV6=y
CONFIG_IP6_NF_IPTABLES=y
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_TARGET_REJECT=y
CONFIG_IP6_NF_MANGLE=y
CONFIG_IP6_NF_NAT=y
CONFIG_IP6_NF_TARGET_MASQUERADE=y
CONFIG_BRIDGE=y
CONFIG_BRIDGE_VLAN_FILTERING=y
CONFIG_VLAN_8021Q=y
CONFIG_VLAN_8021Q_GVRP=y
CONFIG_VLAN_8021Q_MVRP=y
CONFIG_BT=y
CONFIG_BT_BNEP=y
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_HIDP=y
# CONFIG_BT_HS is not set
CONFIG_BT_LEDS=y
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_BCM=y
CONFIG_RFKILL=y
CONFIG_RFKILL_REGULATOR=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_DMA_CMA=y
CONFIG_VEXPRESS_CONFIG=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_SRAM=y
# CONFIG_VEXPRESS_SYSCFG is not set
CONFIG_SCSI=y
# CONFIG_SCSI_PROC_FS is not set
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_SG=y
CONFIG_SCSI_SAS_LIBSAS=y
# CONFIG_SCSI_LOWLEVEL is not set
CONFIG_NETDEVICES=y
CONFIG_TUN=y
CONFIG_VETH=y
# CONFIG_ETHERNET is not set
CONFIG_PPP=y
CONFIG_PPP_BSDCOMP=y
CONFIG_PPP_DEFLATE=y
CONFIG_PPP_ASYNC=y
CONFIG_USB_USBNET=y
# CONFIG_USB_NET_AX8817X is not set
# CONFIG_USB_NET_AX88179_178A is not set
CONFIG_USB_NET_HUAWEI_CDC_NCM=y
CONFIG_USB_NET_CDC_MBIM=y
CONFIG_USB_NET_SMSC95XX=y
# CONFIG_USB_NET_NET1080 is not set
# CONFIG_USB_NET_CDC_SUBSET is not set
# CONFIG_USB_NET_ZAURUS is not set
CONFIG_USB_HSO=y
# CONFIG_WLAN is not set
CONFIG_INPUT_EVDEV=y
CONFIG_KEYBOARD_GPIO=y
CONFIG_INPUT_MISC=y
#
Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase
On Tue, 28 Feb 2017, Felipe Balbi wrote: > > Hi, > > Alan Stern writes: > >> So I am not sure how the Gadget driver can figure out that it needs to > >> usb_ep_queue() another request for status stage when handling the > >> no-data control? > > > > Gadget drivers already queue status-stage requests for no-data > > control-OUT requests. The difficulty comes when you want to handle an > > IN request or an OUT request with a data stage. > > I don't see a difficulty there. Gadget driver will see wLength and > notice it needs both data and status stages, then it does: > > usb_ep_queue(ep0, data_req, GFP_KERNEL); > usb_ep_queue(ep0, status_req, GFP_KERNEL); The main difficulty is that all the gadget/function drivers will have to be audited to add the status requests. > Just needs to prepare both requests and queue them both ahead of > time. UDC drivers should hold both requests in their own private list > and process one at a time. Or the gadget driver should queue the status request after the data stage has been fully processed, in the case of an OUT transfer. There is still a possible race. The host might send another SETUP packet before the status request has been queued, or after it has been queued but before the UDC driver has completed it. (Of course, that's already true now for the data request...) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb/net/hso: WARNING: ungligned urb->setup_dma
Hi Baruch, > Baruch Siach hat am 28. Februar 2017 um 19:07 geschrieben: > > > Hi Stefan, > > On Tue, Feb 28, 2017 at 05:21:18PM +0100, Stefan Wahren wrote: > > Am 28.02.2017 um 13:01 schrieb Baruch Siach: > > > On Tue, Feb 28, 2017 at 10:28:10AM +0200, Baruch Siach wrote: > > > > I'm hitting this warning consistently on my Raspberry Pi 3 running > > > > kernel > > > > v4.10.1 with some unrelated device tree changes, and a debug print > > > > (below). > > > > The device identifies as "GlobeTrotter HSDPA Modem", VID: 0af0, PID: > > > > 6971. > > > > The warning triggers consistently on first write access to /dev/ttyHS0 > > > > that > > > > ModemManager attempts. The first line in the log is my debug print. > > > I tested the same hardware successfully on an i.MX6 CuBox-i (ARM32) using > > > the > > > same kernel version (4.10.1), and on an x86_64 PC (4.9). So this seems to > > > be > > > platform specific. I don't have any other ARM64 machine at the moment, > > > though. > > > > those platforms usually doesn't use the dwc2 USB host controller. So it > > should be tested with another dwc2 platform. > > The code that initializes setup_dma is not under drivers/usb/dwc2/. Though > the > problem looks like memory corruption, so its cause might be anywhere. only a suspicion, but could you please try this patch [1]? [1] - https://patchwork.kernel.org/patch/9166771/ -- To unsubscribe from this list: send the line "unsubscribe 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] MAINTAINERS: Orphan usb/net/hso driver
On Tue, Feb 28, 2017 at 10:38:44AM -0500, David Miller wrote: > From: Baruch Siach > Date: Tue, 28 Feb 2017 10:39:48 +0200 > > > The email address of Jan Dumon bounces, and there is not relevant > > information > > in the linked website. > > > > Signed-off-by: Baruch Siach > > This patch is fine and I will apply it later, however I will make a > general statement that we list USB networking drivers very > inconsistently. > > Specifically, some list linux-usb as the mailing list, others list > netdev. We should figure out which one (or both) is the best to > specify, and apply that rule consitently to the MAINTAINERS file. I don't want them :) Seriously, I don't have a problem with the patches being cc:ed to linux-usb as long as you will take them, as often times the issues involved are USB specific things, not network driver-specific things, so the developers here can weigh in on them. Want me to make up a patch to do that? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hid: usbhid: hiddev.c: fix checkpatch.pl errors
Hi,
well, not to undermine your work, I am not a big fan of this kind of
patches. Yes, it's nice to follow checkpatch, but on some rare case, we
just ignore the warning because the end result would be too ugly (I
haven't read the patch, so I am not judging how you solved the issues
raised here and there).
The other reason I don't like such patches is that they tend to block
backports for distribution maintainers. They touch everywhere in the
file. This means that to backport a simple security fix, we need to
backport this (equivalent of a) patch. And then we need to upgrade the
full stack to have the patch applied properly.
I don't mind people fixing checkpatch issues when they are actually
changing the functional part of the code ("oh, I need to add a return
-ENODEV, but the pr_err above is ugly, let's fix that").
So, I am not pushing a formal NACK on this patch and the others you
sent. I am just raising my concerns and let Jiri decides whether or not
we need to take this work.
Cheers,
Benjamin
PS: I know this is low hanging fruit work, but this should rather be
done in drivers/staging than in a non-staging tree.
On Feb 26 2017 or thereabouts, Avraham Shukron wrote:
> - Extracted assignments out of 'if' statements
> - Removed unnecessary spaces
> - Broke long lines
> - Added empty lines after declarations
>
> Signed-off-by: Avraham Shukron
> ---
> drivers/hid/usbhid/hiddev.c | 51
> ++---
> 1 file changed, 34 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
> index 700145b..a75ff0a 100644
> --- a/drivers/hid/usbhid/hiddev.c
> +++ b/drivers/hid/usbhid/hiddev.c
> @@ -60,7 +60,7 @@ struct hiddev_list {
> struct hiddev_usage_ref buffer[HIDDEV_BUFFER_SIZE];
> int head;
> int tail;
> - unsigned flags;
> + unsigned int flags;
> struct fasync_struct *fasync;
> struct hiddev *hiddev;
> struct list_head node;
> @@ -187,7 +187,7 @@ static void hiddev_send_event(struct hid_device *hid,
> void hiddev_hid_event(struct hid_device *hid, struct hid_field *field,
> struct hid_usage *usage, __s32 value)
> {
> - unsigned type = field->report_type;
> + unsigned int type = field->report_type;
> struct hiddev_usage_ref uref;
>
> uref.report_type =
> @@ -206,7 +206,7 @@ EXPORT_SYMBOL_GPL(hiddev_hid_event);
>
> void hiddev_report_event(struct hid_device *hid, struct hid_report *report)
> {
> - unsigned type = report->type;
> + unsigned int type = report->type;
> struct hiddev_usage_ref uref;
>
> memset(&uref, 0, sizeof(uref));
> @@ -234,7 +234,7 @@ static int hiddev_fasync(int fd, struct file *file, int
> on)
> /*
> * release file op
> */
> -static int hiddev_release(struct inode * inode, struct file * file)
> +static int hiddev_release(struct inode *inode, struct file *file)
> {
> struct hiddev_list *list = file->private_data;
> unsigned long flags;
> @@ -279,7 +279,8 @@ static int hiddev_open(struct inode *inode, struct file
> *file)
> hid = usb_get_intfdata(intf);
> hiddev = hid->hiddev;
>
> - if (!(list = vzalloc(sizeof(struct hiddev_list
> + list = vzalloc(sizeof(struct hiddev_list));
> + if (!list)
> return -ENOMEM;
> mutex_init(&list->thread_lock);
> list->hiddev = hiddev;
> @@ -310,6 +311,7 @@ static int hiddev_open(struct inode *inode, struct file
> *file)
> if (!list->hiddev->open++)
> if (list->hiddev->exist) {
> struct hid_device *hid = hiddev->hid;
> +
> res = usbhid_get_power(hid);
> if (res < 0) {
> res = -EIO;
> @@ -330,7 +332,8 @@ static int hiddev_open(struct inode *inode, struct file
> *file)
> /*
> * "write" file op
> */
> -static ssize_t hiddev_write(struct file * file, const char __user * buffer,
> size_t count, loff_t *ppos)
> +static ssize_t hiddev_write(struct file *file, const char __user *buffer,
> + size_t count, loff_t *ppos)
> {
> return -EINVAL;
> }
> @@ -338,7 +341,8 @@ static ssize_t hiddev_write(struct file * file, const
> char __user * buffer, size
> /*
> * "read" file op
> */
> -static ssize_t hiddev_read(struct file * file, char __user * buffer, size_t
> count, loff_t *ppos)
> +static ssize_t hiddev_read(struct file *file, char __user *buffer,
> + size_t count, loff_t *ppos)
> {
> DEFINE_WAIT(wait);
> struct hiddev_list *list = file->private_data;
> @@ -358,7 +362,8 @@ static ssize_t hiddev_read(struct file * file, char
> __user * buffer, size_t coun
>
> while (retval == 0) {
> if (list->head == list->tail) {
> - prepare_to_wait(&list->hiddev->wait, &wait,
> TASK_INTERRUPTIBLE);
> + prepare_to_wait(&list->hiddev->wait,
> + &wait, TAS
Re: [PATCH v2] HID: hiddev: allocate minor number hiddev's USB interface is bound to
On Feb 15 2017 or thereabouts, Jaejoong Kim wrote:
> When HID device connected to the PC, HID device driver announces which
> driver is loaded with a kernel info message. In this case, hiddev's minor
> number is always '0' even though hiddev's real minor number is not zero.
>
> To display hiddev with minor number asked from usb core, we need
> to fill hiddev's minor number this interface is bound to.
>
> Signed-off-by: Jaejoong Kim
> ---
That's a single line of code, and I get into some headaches :)
So, the commit that broke this (.minor not being set) is actually commit
bd25f4dd69727555 ("HID: hiddev: use usb_find_interface, get rid of
BKL"), from 2010-07-11...
And this patch reverts to the intended behavior. But I am wondering if we
should really store the minor in struct hid_device if it is only used by
hiddev. hidraw does use a minor too, but stores it in struct hidraw
directly, so IMO it would make sense to store this in struct hiddev. The
problem is that this struct is not exported, and it's going to be some
refactoring work to do so.
So, in a way, I am tempted to give my:
Acked-by: Benjamin Tissoires
But if Jiri feels that a cleanup of hiddev would be required instead, I
would follow him :)
Cheers,
Benjamin
> Changes in v2:
> - fix typo in commit message
> ---
>
> drivers/hid/usbhid/hiddev.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
> index 700145b..27e1f8d 100644
> --- a/drivers/hid/usbhid/hiddev.c
> +++ b/drivers/hid/usbhid/hiddev.c
> @@ -910,6 +910,7 @@ int hiddev_connect(struct hid_device *hid, unsigned int
> force)
> kfree(hiddev);
> return -1;
> }
> + hid->minor = usbhid->intf->minor;
> return 0;
> }
>
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] HID: usbhid: extend polling interval configuration to joysticks
On Feb 25 2017 or thereabouts, Tobias Jakobi wrote:
> For mouse devices we can currently change the polling interval
> via usbhid.mousepoll. Implement the same thing for joysticks, so
> users can reduce input latency this way.
>
> This has been tested with a Logitech RumblePad 2 with jspoll=2,
> resulting in a polling rate of 500Hz (verified with evhz).
>
> Signed-off-by: Tobias Jakobi
> ---
Looks good to me.
Acked-by: Benjamin Tissoires
> Documentation/kernel-parameters.txt | 3 +++
> drivers/hid/usbhid/hid-core.c | 18 +++---
> 2 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index 922dec8..928ce2c 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -4260,6 +4260,9 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
> usbhid.mousepoll=
> [USBHID] The interval which mice are to be polled at.
>
> + usbhid.jspoll=
> + [USBHID] The interval which joysticks are to be polled
> at.
> +
> usb-storage.delay_use=
> [UMS] The delay in seconds before a new device is
> scanned for Logical Units (default 1).
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index ae83af6..f7a692f 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -53,6 +53,10 @@ static unsigned int hid_mousepoll_interval;
> module_param_named(mousepoll, hid_mousepoll_interval, uint, 0644);
> MODULE_PARM_DESC(mousepoll, "Polling interval of mice");
>
> +static unsigned int hid_jspoll_interval;
> +module_param_named(jspoll, hid_jspoll_interval, uint, 0644);
> +MODULE_PARM_DESC(jspoll, "Polling interval of joysticks");
> +
> static unsigned int ignoreled;
> module_param_named(ignoreled, ignoreled, uint, 0644);
> MODULE_PARM_DESC(ignoreled, "Autosuspend with active leds");
> @@ -1082,9 +1086,17 @@ static int usbhid_start(struct hid_device *hid)
> hid->name, endpoint->bInterval, interval);
> }
>
> - /* Change the polling interval of mice. */
> - if (hid->collection->usage == HID_GD_MOUSE &&
> hid_mousepoll_interval > 0)
> - interval = hid_mousepoll_interval;
> + /* Change the polling interval of mice and joysticks. */
> + switch (hid->collection->usage) {
> + case HID_GD_MOUSE:
> + if (hid_mousepoll_interval > 0)
> + interval = hid_mousepoll_interval;
> + break;
> + case HID_GD_JOYSTICK:
> + if (hid_jspoll_interval > 0)
> + interval = hid_jspoll_interval;
> + break;
> + }
>
> ret = -ENOMEM;
> if (usb_endpoint_dir_in(endpoint)) {
> --
> 2.7.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] usb: gadget: dummy_hcd: clear usb_gadget region before registration
On Tue, 28 Feb 2017, Peter Chen wrote:
> When the user does device unbind and rebind test, the kernel will
> show below dump due to usb_gadget memory region is dirty after unbind.
> Clear usb_gadget region for every new probe.
>
> root@imx6qdlsolo:/sys/bus/platform/drivers/dummy_udc# echo dummy_udc.0 > bind
> [ 102.523312] kobject (eddd78b0): tried to init an initialized object,
> something is seriously wrong.
> [ 102.532447] CPU: 0 PID: 734 Comm: sh Not tainted 4.10.0-rc7-00872-g1b2b8e9
> #1298
> [ 102.539866] Hardware name: Freescale i.MX6 SoloX (Device Tree)
> [ 102.545717] Backtrace:
> [ 102.548225] [] (dump_backtrace) from []
> (show_stack+0x18/0x1c)
> [ 102.555822] r7:ede34000 r6:60010013 r5: r4:c0f29418
> [ 102.561512] [] (show_stack) from []
> (dump_stack+0xb4/0xe8)
> [ 102.568764] [] (dump_stack) from []
> (kobject_init+0x80/0x9c)
> [ 102.576187] r10:001f r9:eddd7000 r8:eeaf8c10 r7:eddd78a8 r6:c177891c
> r5:c0f3b060
> [ 102.584036] r4:eddd78b0 r3:
> [ 102.587641] [] (kobject_init) from []
> (device_initialize+0x28/0xf8)
> [ 102.595665] r5:eebc4800 r4:eddd78a8
> [ 102.599268] [] (device_initialize) from []
> (device_register+0x14/0x20)
> [ 102.607556] r7:eddd78a8 r6: r5:eebc4800 r4:eddd78a8
> [ 102.613256] [] (device_register) from []
> (usb_add_gadget_udc_release+0x8c/0x1ec)
> [ 102.622410] r5:eebc4800 r4:eddd7860
> [ 102.626015] [] (usb_add_gadget_udc_release) from []
> (usb_add_gadget_udc+0x14/0x18)
> [ 102.635351] r10:001f r9:eddd7000 r8:eddd788c r7:bf003770 r6:eddd77f8
> r5:eddd7818
> [ 102.643198] r4:eddd785c r3:eddd7b24
> [ 102.646834] [] (usb_add_gadget_udc) from []
> (dummy_udc_probe+0x170/0x1c4 [dummy_hcd])
> [ 102.656458] [] (dummy_udc_probe [dummy_hcd]) from []
> (platform_drv_probe+0x54/0xb8)
> [ 102.665881] r10:0008 r9:c1778960 r8:bf004128 r7:fdfb r6:bf004128
> r5:eeaf8c10
> [ 102.673727] r4:eeaf8c10
> [ 102.676293] [] (platform_drv_probe) from []
> (driver_probe_device+0x264/0x474)
> [ 102.685186] r7: r6: r5:c1778960 r4:eeaf8c10
> [ 102.690876] [] (driver_probe_device) from []
> (bind_store+0xb8/0x14c)
> [ 102.698994] r10:eeb3bb4c r9:ede34000 r8:000c r7:eeaf8c44 r6:bf004128
> r5:c0f3b668
> [ 102.706840] r4:eeaf8c10
> [ 102.709402] [] (bind_store) from []
> (drv_attr_store+0x28/0x34)
> [ 102.716998] r9:ede34000 r8: r7:ee3863c0 r6:ee3863c0 r5:c0538c80
> r4:c053970c
> [ 102.724776] [] (drv_attr_store) from []
> (sysfs_kf_write+0x50/0x54)
> [ 102.732711] r5:c0538c80 r4:000c
> [ 102.736313] [] (sysfs_kf_write) from []
> (kernfs_fop_write+0x100/0x214)
> [ 102.744599] r7:ee3863c0 r6:eeb3bb40 r5: r4:
> [ 102.750287] [] (kernfs_fop_write) from []
> (__vfs_write+0x34/0x120)
> [ 102.758231] r10: r9:ede34000 r8:c0108bc4 r7:000c r6:ede35f80
> r5:c029bd84
> [ 102.766077] r4:ee223780
> [ 102.768638] [] (__vfs_write) from []
> (vfs_write+0xa8/0x170)
> [ 102.775974] r9:ede34000 r8:c0108bc4 r7:ede35f80 r6:01861cb0 r5:ee223780
> r4:000c
> [ 102.783743] [] (vfs_write) from []
> (SyS_write+0x4c/0xa8)
> [ 102.790818] r9:ede34000 r8:c0108bc4 r7:000c r6:01861cb0 r5:ee223780
> r4:ee223780
> [ 102.798595] [] (SyS_write) from []
> (ret_fast_syscall+0x0/0x1c)
> [ 102.806188] r7:0004 r6:b6e83d58 r5:01861cb0 r4:000c
>
> Cc: Alan Stern
> Cc: stable
> Fixes: 90fccb529d24 ("usb: gadget: Gadget directory cleanup - group UDC
> drivers")
> Signed-off-by: Peter Chen
> Tested-by: Xiaolong Ye
> Reported-by: Fengguang Wu
> ---
> drivers/usb/gadget/udc/dummy_hcd.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/gadget/udc/dummy_hcd.c
> b/drivers/usb/gadget/udc/dummy_hcd.c
> index c60abe3..8cabc59 100644
> --- a/drivers/usb/gadget/udc/dummy_hcd.c
> +++ b/drivers/usb/gadget/udc/dummy_hcd.c
> @@ -1031,6 +1031,8 @@ static int dummy_udc_probe(struct platform_device *pdev)
> int rc;
>
> dum = *((void **)dev_get_platdata(&pdev->dev));
> + /* Clear usb_gadget region for new registration to udc-core */
> + memzero_explicit(&dum->gadget, sizeof(struct usb_gadget));
> dum->gadget.name = gadget_name;
> dum->gadget.ops = &dummy_ops;
> dum->gadget.max_speed = USB_SPEED_SUPER;
Wouldn't it be better to clear the entire structure, not just
dum->gadget? Then you could also change
dum[i] = kzalloc(sizeof(struct dummy), GFP_KERNEL);
to use kmalloc, since the structure will be initialized by the probe
routine.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb/net/hso: WARNING: ungligned urb->setup_dma
Hi Baruch, Am 28.02.2017 um 13:01 schrieb Baruch Siach: Hi linux-usb list, (Dropped Jan's bouncing address, added Rpi3 platform lists) On Tue, Feb 28, 2017 at 10:28:10AM +0200, Baruch Siach wrote: Hi linux-usb list, I'm hitting this warning consistently on my Raspberry Pi 3 running kernel v4.10.1 with some unrelated device tree changes, and a debug print (below). The device identifies as "GlobeTrotter HSDPA Modem", VID: 0af0, PID: 6971. The warning triggers consistently on first write access to /dev/ttyHS0 that ModemManager attempts. The first line in the log is my debug print. I tested the same hardware successfully on an i.MX6 CuBox-i (ARM32) using the same kernel version (4.10.1), and on an x86_64 PC (4.9). So this seems to be platform specific. I don't have any other ARM64 machine at the moment, though. those platforms usually doesn't use the dwc2 USB host controller. So it should be tested with another dwc2 platform. Is the issue reproducible with other USB devices like keyboards? Are you using arm64 defconfig? Are you able to bisect this issue? Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb/net/hso: WARNING: ungligned urb->setup_dma
On Tue, 2017-02-28 at 14:01 +0200, Baruch Siach wrote: > Hi linux-usb list, > > (Dropped Jan's bouncing address, added Rpi3 platform lists) > > On Tue, Feb 28, 2017 at 10:28:10AM +0200, Baruch Siach wrote: > > Hi linux-usb list, > > > > I'm hitting this warning consistently on my Raspberry Pi 3 running > > kernel > > v4.10.1 with some unrelated device tree changes, and a debug print > > (below). > > The device identifies as "GlobeTrotter HSDPA Modem", VID: 0af0, > > PID: 6971. > > The warning triggers consistently on first write access to > > /dev/ttyHS0 that > > ModemManager attempts. The first line in the log is my debug print. > > I tested the same hardware successfully on an i.MX6 CuBox-i (ARM32) > using the > same kernel version (4.10.1), and on an x86_64 PC (4.9). So this > seems to be > platform specific. I don't have any other ARM64 machine at the > moment, though. > > Has anyone noticed USB host issues on Raspberry Pi 3 with 64bit > kernel? > > baruch > > > [ 65.004892] dwc2_map_urb_for_dma: setup_dma: f5635066 > > [ 65.010718] [ cut here ] > > [ 65.016079] WARNING: CPU: 1 PID: 794 at > > drivers/usb/dwc2/hcd.c:2631 dwc2_map_urb_for_dma+0x94/0x130 > > [ 65.025930] > > [ 65.028143] CPU: 1 PID: 794 Comm: ModemManager Not tainted > > 4.10.1-8-g76809ec3947f-dirty #719 > > [ 65.037747] Hardware name: Raspberry Pi 3 Model B (DT) > > [ 65.043656] task: 8000362e3e80 task.stack: 80003556c000 > > [ 65.050359] PC is at dwc2_map_urb_for_dma+0x94/0x130 > > [ 65.056090] LR is at dwc2_map_urb_for_dma+0x34/0x130 > > [ 65.061819] pc : [] lr : [] > > pstate: 01c5 > > [ 65.070018] sp : 80003556fa70 > > [ 65.074080] x29: 80003556fa70 x28: 0005 > > [ 65.080167] x27: 80003563d000 x26: 8000350d4600 > > [ 65.086252] x25: 800035686780 x24: 0002 > > [ 65.092247] x23: 0001 x22: 01080020 > > [ 65.097635] x21: 800035425800 x20: 01080020 > > [ 65.103024] x19: 800035b72400 x18: 0010 > > [ 65.108413] x17: 908f5a40 x16: 081abad8 > > [ 65.113801] x15: 0006 x14: 8882c047 > > [ 65.119191] x13: 0882c055 x12: 0882e458 > > [ 65.124579] x11: 80003556f7d0 x10: 087c9a38 > > [ 65.129968] x9 : 083613e0 x8 : 363566203a616d64 > > [ 65.135356] x7 : 5f7075746573203a x6 : 02fc > > [ 65.140744] x5 : x4 : > > [ 65.146132] x3 : x2 : 8000362e3e80 > > [ 65.151521] x1 : 0001 x0 : 0880e000 > > [ 65.156907] > > [ 65.158414] ---[ end trace a78d20eaecac455a ]--- > > [ 65.163093] Call trace: > > [ 65.165573] Exception stack(0x80003556f8a0 to > > 0x80003556f9d0) > > [ 65.172108] f8a0: 800035b72400 0001 > > 80003556fa70 083ff0ac > > [ 65.180052] f8c0: 086f8f70 08795000 > > 0882dce8 087fb318 > > [ 65.187996] f8e0: 0882c048 00010882bae8 > > 80003556f990 080dc664 > > [ 65.195940] f900: 800035b72400 01080020 > > 800035425800 01080020 > > [ 65.203883] f920: 0001 0002 > > 800035686780 8000350d4600 > > [ 65.211827] f940: 0880e000 0001 > > 8000362e3e80 > > [ 65.219771] f960: > > 02fc 5f7075746573203a > > [ 65.227715] f980: 363566203a616d64 083613e0 > > 087c9a38 80003556f7d0 > > [ 65.235659] f9a0: 0882e458 0882c055 > > 8882c047 0006 > > [ 65.243601] f9c0: 081abad8 908f5a40 > > [ 65.248548] [] dwc2_map_urb_for_dma+0x94/0x130 > > [ 65.254643] [] usb_hcd_submit_urb+0x8c/0x8c0 > > [ 65.260560] [] usb_submit_urb+0x248/0x480 > > [ 65.266215] [] mux_device_request+0xdc/0x1f8 > > [ 65.272134] [] > > hso_mux_serial_write_data+0x28/0x38 > > [ 65.278581] [] hso_kick_transmit+0x88/0xb8 > > [ 65.284323] [] hso_serial_write+0x60/0xc0 > > [ 65.289979] [] n_tty_write+0x300/0x3e0 > > [ 65.295369] [] tty_write+0x170/0x2b8 > > [ 65.300585] [] __vfs_write+0x1c/0x100 > > [ 65.305884] [] vfs_write+0x9c/0x1a8 > > [ 65.311010] [] SyS_write+0x44/0xa0 > > [ 65.316049] [] el0_svc_naked+0x24/0x28 > > > > The debug print otherwise just shows: > > > > [ 64.476785] dwc2_map_urb_for_dma: setup_dma: > > > > So it looks like urb->setup_dma content is garbage. > > > > Any thoughts? > > > > Thanks, > > baruch > I've seen similar issues twice before: 1. Back when arm64 was initially being ported to the RPI 3 by people on the net back in March/April of last year and only the serial console worked, DMA was broken in the dwc2 driver. The dwc2 driver would send and receive garbage data. The reason was that some of the memory manager DMA functionality for arm64 wasn't
Re: Question: Does usbip support USB 3.0?
On 02/23/2017 08:51 AM, Greg KH wrote: A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Thu, Feb 23, 2017 at 07:43:23AM +, Du, Yuyang wrote: Oh, then let me try to simplify it, what if it's an only USB 3.0 device? I have a USB keyboard around here somewhere that is a "USB 3.0" device, that is running at the USB "low speed" rate. :) Again, USB 3.0 supports all speed devices, see the spec for all of the details. Just to add what Greg said: vhci (virtual host controller for usbip) itself is high speed and does not support stuff like streams etc. which are included in USB 3.0 spec so you won't be able to connect USB device in super speed mode via usbip. So if your device supports high speed mode it will work fine. If your device doesn't work with speed lower than super speed then you won't be able to use it via usbip. Best regards, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe 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] MAINTAINERS: Orphan usb/net/hso driver
From: Baruch Siach Date: Tue, 28 Feb 2017 10:39:48 +0200 > The email address of Jan Dumon bounces, and there is not relevant information > in the linked website. > > Signed-off-by: Baruch Siach This patch is fine and I will apply it later, however I will make a general statement that we list USB networking drivers very inconsistently. Specifically, some list linux-usb as the mailing list, others list netdev. We should figure out which one (or both) is the best to specify, and apply that rule consitently to the MAINTAINERS file. 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 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode
On 25/02/17 05:35, Chanwoo Choi wrote:
> Hi Roger,
>
> [snip]
>
>> /* dwc->lock must be held */
>> static void dwc3_otg_core_exit(struct dwc3 *dwc)
>> {
>> + if (dwc->edev)
>> + return;
>> +
>> /* disable all otg irqs */
>> dwc3_otg_disable_events(dwc, DWC3_OTG_ALL_EVENTS);
>> /* clear all events */
>> @@ -1286,6 +1364,57 @@ static int dwc3_drd_init(struct dwc3 *dwc)
>>
>> INIT_WORK(&dwc->otg_work, dwc3_drd_work);
>>
>> + /* If extcon device is present we don't rely on OTG core for ID
>> event */
>> + if (dwc->edev) {
>> + int id, vbus;
>> +
>> + dwc->edev_nb.notifier_call = dwc3_drd_notifier;
>> + ret = extcon_register_notifier(dwc->edev, EXTCON_USB,
>> + &dwc->edev_nb);
>
> I recommend that you better to use the devm_extcon_register_notifier()
Got it.
>
>> + if (ret < 0) {
>> + dev_err(dwc->dev, "Couldn't register USB cable
>> notifier\n");
>> + return -ENODEV;
>> + }
>> +
>> + ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
>> + &dwc->edev_nb);
>
> Ditto.
>
> [snip]
>
--
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] USB: serial: ftdi_sio: allow other bases for "event_char"
On 28/02/17 14:21, David Laight wrote: From: Ian Abbott Sent: 28 February 2017 12:51 The 'store' function for the "event_char" device attribute currently expects a base 10 value. The value is composed of an enable bit in bit 8 and an 8-bit "event character" code in bits 7 to 0. It seems reasonable to allow hexadecimal and octal numbers to be written to the device attribute in addition to decimal. Make it so. ... Allowing octal might cause problems. Maybe (probably not much), but it comes as standard when you set the base parameter to 0. -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( Web: http://www.mev.co.uk/ )=- -- To unsubscribe from this list: send the line "unsubscribe 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 6/6] USB: serial: ftdi_sio: allow other bases for "event_char"
From: Ian Abbott > Sent: 28 February 2017 12:51 > The 'store' function for the "event_char" device attribute currently > expects a base 10 value. The value is composed of an enable bit in bit > 8 and an 8-bit "event character" code in bits 7 to 0. It seems > reasonable to allow hexadecimal and octal numbers to be written to the > device attribute in addition to decimal. Make it so. ... Allowing octal might cause problems. David -- To unsubscribe from this list: send the line "unsubscribe 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 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode
On Sat, Feb 25, 2017 at 9:20 AM, Chanwoo Choi wrote:
> 2017-02-25 12:46 GMT+09:00 Chanwoo Choi :
>> Hi,
>>
>> 2017-02-24 21:02 GMT+09:00 Roger Quadros :
>>> +Chanwoo
>>>
>>> Hi Vivek,
>>>
>>> On 23/02/17 10:34, Vivek Gautam wrote:
On 02/16/2017 06:36 PM, Roger Quadros wrote:
> dra7 OTG core limits the host controller to USB2.0 (high-speed) mode
> when we're operating in dual-role.
>
> We work around that by bypassing the OTG core and reading the
> extcon framework directly for ID/VBUS events.
>
> Signed-off-by: Roger Quadros
> ---
> Documentation/devicetree/bindings/usb/dwc3.txt | 2 +
> drivers/usb/dwc3/core.c| 169
> -
> drivers/usb/dwc3/core.h| 5 +
> 3 files changed, 170 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
> b/Documentation/devicetree/bindings/usb/dwc3.txt
> index e3e6983..9955c0d 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -53,6 +53,8 @@ Optional properties:
>- snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of
> GFLADJ
> register for post-silicon frame length adjustment when the
> fladj_30mhz_sdbnd signal is invalid or incorrect.
> + - extcon: phandle to the USB connector extcon device. If present, extcon
> +device will be used to get USB cable events instead of OTG
> controller.
> - tx-fifo-resize: determines if the FIFO *has* to be
> reallocated.
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 619fa7c..b02d911 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
[snip]
> @@ -1587,6 +1727,14 @@ static int dwc3_probe(struct platform_device *pdev)
> dwc3_get_properties(dwc);
> +if (dev->of_node) {
> +if (of_property_read_bool(dev->of_node, "extcon"))
> +dwc->edev = extcon_get_edev_by_phandle(dev, 0);
Don't we want separate edev's for vbus and id ?
One can have separate pins connected to them and in that case
we can't get the events out of one pin only.
>>>
>>> Is such kind of hardware really there? Ideally one extcon device
>>> represents one connector. So VBUS and ID events of a single USB
>>> port should come on one extcon device.
>>> If it doesn't then you need to fix your platforms extcon driver
>>> so that it does.
Right, i see it now. One edev for one connector.
>>> Chanwoo can correct me if I'm wrong on this understanding.
>>>
>>> Currently, if VBUS and ID come on GPIOs the extcon-usb-gpio driver
>>> takes care of both.
>>
>> Basically, one extcon device driver can support the multiple
>> external connectors if the detection h/w or port is same.
>>
>> One extcon device with extcon-usb-gpio.c can support the detection
>> of both ID and VBUS.
>>
>> But, if there is any issue of h/w schematic, we need to consider
>> how to use the extcon device.
>
> Additionally, the extcon-usb-gpio.c use the two gpio pins
> to detect both ID and VBUS pins. We can check it on documentation[1]
> of extcon-usb-gpio driver.
>
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/tree/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
Thanks Chanwoo, i understand it now. The extcon-usb-gpio supports
both vbus and id gpio, and updates the state of the edev likewise.
>
> --
> Best Regards,
> Chanwoo Choi
> Samsung Electronics
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
regards
Vivek
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe 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: configs: plug memory leak
On 28/02/17 10:55, John Keeping wrote: When binding a gadget to a device, "name" is stored in gi->udc_name, but this does not happen when unregistering and the string is leaked. Signed-off-by: John Keeping --- drivers/usb/gadget/configfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c index 78c44979dde3..cbff3b02840d 100644 --- a/drivers/usb/gadget/configfs.c +++ b/drivers/usb/gadget/configfs.c @@ -269,6 +269,7 @@ static ssize_t gadget_dev_desc_UDC_store(struct config_item *item, ret = unregister_gadget(gi); if (ret) goto err; + kfree(name); Looks correct to me. Suzuki -- To unsubscribe from this list: send the line "unsubscribe 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: dwc2 gadget issues
On 2/28/2017 3:44 PM, Francesco Lavra wrote: > Hi Vardan, > > On 02/28/2017 09:41 AM, Vardan Mikayelyan wrote: >> On 2/27/2017 11:55 PM, Francesco Lavra wrote: >>> Hi, >>> >>> On 02/23/2017 08:27 PM, Heiko Stuebner wrote: Hi Francesco, Am Donnerstag, 23. Februar 2017, 19:11:37 CET schrieb Francesco Lavra: > I'm having trouble getting the RK3288 OTG controller (the one at > ff58) to work in peripheral mode. I'm using a Firefly Reload board, > and I know the hardware is fine because I can successfully use the port > in device mode with U-Boot's mass storage gadget driver. > Under Linux, the OTG port works fine when used in host mode, but fails > to work in device mode: nothing happens when the a USB host is plugged > into the OTG port, not even a single interrupt is generated by the > controller. I'm using the latest device tree definitions from > git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git. you shouldn't use my tree as base for any real work :-) . Best to use the regular mainline kernel or alternatively try linux-next to get all recent usb changes schedules for the next release. >>> >>> Thanks for your inputs. >>> >>> I was actually using the mainline kernel (4.8.1), in which the dwc2 >>> driver wasn't working, that's why I went to your tree to pick up any >>> fixes or new features that might have been done. I also went to the >>> linux-usb tree for the same reason. >>> >>> Anyway, today I tried with the latest mainline release 4.10.0, and also >>> with linux-next. Unfortunately, still no luck: I can load a gadget >>> driver, which gets correctly bound to the OTG controller, but then >>> nothing happens if a USB host is connected to the OTG port. >>> I'm pasting below the dmesg contents (obtained with 4.10.0, with verbose >>> debugging enabled for the dwc2 driver) when a gadget driver is loaded, >>> in case you might spot something suspicious: >>> >>> [ 1147.035367] dwc2 ff58.usb: bound driver g_audio >>> [ 1147.041203] dwc2 ff58.usb: dwc2_hsotg_pullup: is_on: 1 op_state: 3 >>> [ 1147.041250] dwc2 ff58.usb: dwc2_core_reset() >>> [ 1147.041345] dwc2 ff58.usb: FIFOs reset, timeout at 100 >>> [ 1147.041405] dwc2 ff58.usb: EP0: DIEPCTL0=0x8000, >>> DOEPCTL0=0x8000 >>> [ 1147.041447] dwc2 ff58.usb: gsintmsk now 0xd08c3cc4 >>> [ 1147.041554] dwc2 ff58.usb: DCTL=0x0002 >>> [ 1147.041631] dwc2 ff58.usb: dwc2_hsotg_enqueue_setup: queueing >>> setup request >>> [ 1147.041692] dwc2 ff58.usb: ep0: req ee241680: 8@ee241198, noi=0, >>> zero=0, snok=0 >>> [ 1147.041757] dwc2 ff58.usb: dwc2_hsotg_start_req: >>> DxEPCTL=0x80008000, ep 0, dir out >>> [ 1147.041799] dwc2 ff58.usb: ureq->length:8 ureq->actual:0 >>> [ 1147.041896] dwc2 ff58.usb: dwc2_hsotg_start_req: 1@8/8, >>> 0x00080008 => 0x0b10 >>> [ 1147.041975] dwc2 ff58.usb: dwc2_hsotg_start_req: 2e243000 pad => >>> 0x0b14 >>> [ 1147.042014] dwc2 ff58.usb: ep0 state:0 >>> [ 1147.042055] dwc2 ff58.usb: dwc2_hsotg_start_req: DxEPCTL=0x80008000 >>> [ 1147.042097] dwc2 ff58.usb: dwc2_hsotg_start_req: DXEPCTL=0x80008000 >>> [ 1147.042169] dwc2 ff58.usb: EP0: DIEPCTL0=0x8000, >>> DOEPCTL0=0x80008000 >>> >>> Thanks, >>> Francesco >>> -- >> >> Hi Francesco, >> >> Could you please provide full log (with debugs enabled) from DWC2 driver >> loading to issue point? Two logs are not giving us the full picture. > > The full log from the DWC2 driver is below: > > [1.498030] dwc2 ff58.usb: ff58.usb supply vusb_d not found, > using dummy regulator > [1.507431] dwc2 ff58.usb: ff58.usb supply vusb_a not found, > using dummy regulator > [1.880012] dwc2 ff58.usb: dwc2_check_param_tx_fifo_sizes: > Invalid parameter g-tx-fifo-size, setting to default average > [1.892596] dwc2 ff58.usb: EPs: 10, dedicated fifos, 972 entries > in SPRAM > [1.901018] dwc2 ff58.usb: DCFG=0x0810, DCTL=0x0002, > DIEPMSK= > [1.909432] dwc2 ff58.usb: GAHBCFG=0x, GHWCFG1=0x6664 > [1.916698] dwc2 ff58.usb: GRXFSIZ=0x0400, GNPTXFSIZ=0x00100400 > [1.924161] dwc2 ff58.usb: DPTx[1] FSize=256, StAddr=0x0410 > [1.931224] dwc2 ff58.usb: DPTx[2] FSize=256, StAddr=0x0900 > [1.938261] dwc2 ff58.usb: DPTx[3] FSize=256, StAddr=0x0a00 > [1.945318] dwc2 ff58.usb: DPTx[4] FSize=256, StAddr=0x0b00 > [1.952375] dwc2 ff58.usb: DPTx[5] FSize=256, StAddr=0x0c00 > [1.959410] dwc2 ff58.usb: DPTx[6] FSize=256, StAddr=0x0d00 > [1.966456] dwc2 ff58.usb: DPTx[7] FSize=0, StAddr=0x0e00 > [1.973317] dwc2 ff58.usb: DPTx[8] FSize=0, StAddr=0x0f00 > [1.980180] dwc2 ff58.usb: DPTx[9] FSize=256, StAddr=0x0410 > [1.987216] dwc2 ff58.usb: ep0-in: EPCTL=0x8800, > SIZ=0x, DMA=0x379a4f2d > [1.996232] dwc2 ff58.usb: ep0-out: EPCTL=0x00
[PATCH] net: usb: asix_devices: fix missing return code check on call to asix_write_medium_mode
From: Colin Ian King
The call to asix_write_medium_mode is not updating the return code ret
and yet ret is being checked for an error. Fix this by assigning ret to
the return code from the call asix_write_medium_mode.
Detected by CoverityScan, CID#1357148 ("Logically Dead Code")
Signed-off-by: Colin Ian King
---
drivers/net/usb/asix_devices.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 6e98ede..0dd5106 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -346,7 +346,7 @@ static int ax88772_reset(struct usbnet *dev)
if (ret < 0)
goto out;
- asix_write_medium_mode(dev, AX88772_MEDIUM_DEFAULT, 0);
+ ret = asix_write_medium_mode(dev, AX88772_MEDIUM_DEFAULT, 0);
if (ret < 0)
goto out;
--
2.10.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
[PATCH 2/6] USB: serial: ftdi_sio: detect BM chip with iSerialNumber bug
If a BM type chip has iSerialNumber set to 0 in its EEPROM, an incorrect
value is read from the bcdDevice field of the USB descriptor, making it
look like an AM type chip. Attempt to correct this in
ftdi_determine_type() by attempting to read the latency timer for an AM
type chip. If that succeeds, assume it is a BM type chip.
Currently, read_latency_timer() bails out without reading the latency
timer for an AM type chip, so factor out the guts of
read_latency_timer() into a new function _read_latency_timer() that
attempts to read the latency timer regardless of chip type, and returns
either the latency timer value or a negative error number.
Signed-off-by: Ian Abbott
---
drivers/usb/serial/ftdi_sio.c | 38 ++
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 72314734dfd0..a1b90f4184a7 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1425,16 +1425,13 @@ static int write_latency_timer(struct usb_serial_port
*port)
return rv;
}
-static int read_latency_timer(struct usb_serial_port *port)
+static int _read_latency_timer(struct usb_serial_port *port)
{
struct ftdi_private *priv = usb_get_serial_port_data(port);
struct usb_device *udev = port->serial->dev;
unsigned char *buf;
int rv;
- if (priv->chip_type == SIO || priv->chip_type == FT8U232AM)
- return -EINVAL;
-
buf = kmalloc(1, GFP_KERNEL);
if (!buf)
return -ENOMEM;
@@ -1446,11 +1443,10 @@ static int read_latency_timer(struct usb_serial_port
*port)
0, priv->interface,
buf, 1, WDR_TIMEOUT);
if (rv < 1) {
- dev_err(&port->dev, "Unable to read latency timer: %i\n", rv);
if (rv >= 0)
rv = -EIO;
} else {
- priv->latency = buf[0];
+ rv = buf[0];
}
kfree(buf);
@@ -1458,6 +1454,24 @@ static int read_latency_timer(struct usb_serial_port
*port)
return rv;
}
+static int read_latency_timer(struct usb_serial_port *port)
+{
+ struct ftdi_private *priv = usb_get_serial_port_data(port);
+ int rv;
+
+ if (priv->chip_type == SIO || priv->chip_type == FT8U232AM)
+ return -EINVAL;
+
+ rv = _read_latency_timer(port);
+ if (rv < 0) {
+ dev_err(&port->dev, "Unable to read latency timer: %i\n", rv);
+ return rv;
+ }
+
+ priv->latency = rv;
+ return 0;
+}
+
static int get_serial_info(struct usb_serial_port *port,
struct serial_struct __user *retinfo)
{
@@ -1609,9 +1623,17 @@ static void ftdi_determine_type(struct usb_serial_port
*port)
priv->baud_base = 1200 / 16;
} else if (version < 0x400) {
/* Assume it's an FT8U232AM (or FT8U245AM) */
- /* (It might be a BM because of the iSerialNumber bug,
-* but it will still work as an AM device.) */
priv->chip_type = FT8U232AM;
+ /*
+* It might be a BM type because of the iSerialNumber bug.
+* If the latency timer is readable, assume it is BM type.
+*/
+ if (_read_latency_timer(port) >= 0) {
+ dev_dbg(&port->dev,
+ "%s: has latency timer so not an AM type\n",
+ __func__);
+ priv->chip_type = FT232BM;
+ }
} else if (version < 0x600) {
/* Assume it's an FT232BM (or FT245BM) */
priv->chip_type = FT232BM;
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] USB: serial: ftdi_sio: replace simple_strtoul() calls
Replace the obsolete simple_strtoul() calls with kstrtouint() calls.
Signed-off-by: Ian Abbott
---
drivers/usb/serial/ftdi_sio.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 2662fc3b49c5..e6785d84280b 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1713,9 +1713,13 @@ static ssize_t latency_timer_store(struct device *dev,
{
struct usb_serial_port *port = to_usb_serial_port(dev);
struct ftdi_private *priv = usb_get_serial_port_data(port);
- int v = simple_strtoul(valbuf, NULL, 10);
+ unsigned int v;
int rv;
+ rv = kstrtouint(valbuf, 10, &v);
+ if (rv)
+ return rv;
+
if (v < 1 || v > 255)
return -EINVAL;
@@ -1735,10 +1739,14 @@ static ssize_t store_event_char(struct device *dev,
struct usb_serial_port *port = to_usb_serial_port(dev);
struct ftdi_private *priv = usb_get_serial_port_data(port);
struct usb_device *udev = port->serial->dev;
- int v = simple_strtoul(valbuf, NULL, 10);
+ unsigned int v;
int rv;
- if (v < 0 || v >= 0x200)
+ rv = kstrtouint(valbuf, 10, &v);
+ if (rv)
+ return rv;
+
+ if (v >= 0x200)
return -EINVAL;
dev_dbg(&port->dev, "%s: setting event char = %i\n", __func__, v);
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] USB: serial: ftdi_sio: allow other bases for "event_char"
The 'store' function for the "event_char" device attribute currently expects a base 10 value. The value is composed of an enable bit in bit 8 and an 8-bit "event character" code in bits 7 to 0. It seems reasonable to allow hexadecimal and octal numbers to be written to the device attribute in addition to decimal. Make it so. Signed-off-by: Ian Abbott --- drivers/usb/serial/ftdi_sio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index e6785d84280b..a007ec8238eb 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -1742,7 +1742,7 @@ static ssize_t store_event_char(struct device *dev, unsigned int v; int rv; - rv = kstrtouint(valbuf, 10, &v); + rv = kstrtouint(valbuf, 0, &v); if (rv) return rv; -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] USB: serial: ftdi_sio: latency timer and other stuff
Some patches to skip accessing the FTDI latency timer on chips that don't support it, detect "BM" chips with iSerialNumber bug, validate written device attribute values, and allow hex and octal "event_char" values. 1) USB: serial: ftdi_sio: don't access latency timer on old chips 2) USB: serial: ftdi_sio: detect BM chip with iSerialNumber bug 3) USB: serial: ftdi_sio: only allow valid latency timer values 4) USB: serial: ftdi_sio: only allow valid event_char values 5) USB: serial: ftdi_sio: replace simple_strtoul() calls 6) USB: serial: ftdi_sio: allow other bases for "event_char" drivers/usb/serial/ftdi_sio.c | 56 +-- 1 file changed, 49 insertions(+), 7 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 1/6] USB: serial: ftdi_sio: don't access latency timer on old chips
The latency timer was introduced with the FT232BM and FT245BM chips. Do not bother attempting to read or write it for older chip versions. Signed-off-by: Ian Abbott --- drivers/usb/serial/ftdi_sio.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index c540de15aad2..72314734dfd0 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -1406,6 +1406,9 @@ static int write_latency_timer(struct usb_serial_port *port) int rv; int l = priv->latency; + if (priv->chip_type == SIO || priv->chip_type == FT8U232AM) + return -EINVAL; + if (priv->flags & ASYNC_LOW_LATENCY) l = 1; @@ -1429,6 +1432,9 @@ static int read_latency_timer(struct usb_serial_port *port) unsigned char *buf; int rv; + if (priv->chip_type == SIO || priv->chip_type == FT8U232AM) + return -EINVAL; + buf = kmalloc(1, GFP_KERNEL); if (!buf) return -ENOMEM; -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] USB: serial: ftdi_sio: only allow valid event_char values
The "event_char" device attribute value, when written, is interpreted as an enable bit in bit 8, and an "event character" in bits 7 to 0. Return an error for out-of-range values. Signed-off-by: Ian Abbott --- drivers/usb/serial/ftdi_sio.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index 2da99875cecb..2662fc3b49c5 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -1738,6 +1738,9 @@ static ssize_t store_event_char(struct device *dev, int v = simple_strtoul(valbuf, NULL, 10); int rv; + if (v < 0 || v >= 0x200) + return -EINVAL; + dev_dbg(&port->dev, "%s: setting event char = %i\n", __func__, v); rv = usb_control_msg(udev, -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe 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/6] USB: serial: ftdi_sio: only allow valid latency timer values
Valid latency timer values are between 1 ms and 255 ms in 1 ms steps. The store function for the "latency_timer" device attribute currently allows any value, although only the lower 8-bits will be written to the latency timer. Return an error for out-of-range values. Signed-off-by: Ian Abbott --- drivers/usb/serial/ftdi_sio.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index a1b90f4184a7..2da99875cecb 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -1716,6 +1716,9 @@ static ssize_t latency_timer_store(struct device *dev, int v = simple_strtoul(valbuf, NULL, 10); int rv; + if (v < 1 || v > 255) + return -EINVAL; + priv->latency = v; rv = write_latency_timer(port); if (rv < 0) -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe 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: gadget: configs: plug memory leak
When binding a gadget to a device, "name" is stored in gi->udc_name, but
this does not happen when unregistering and the string is leaked.
Signed-off-by: John Keeping
---
drivers/usb/gadget/configfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 78c44979dde3..cbff3b02840d 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -269,6 +269,7 @@ static ssize_t gadget_dev_desc_UDC_store(struct config_item
*item,
ret = unregister_gadget(gi);
if (ret)
goto err;
+ kfree(name);
} else {
if (gi->composite.gadget_driver.udc_name) {
ret = -EBUSY;
--
2.12.0.rc2.230.ga28edc07cd.dirty
--
To unsubscribe from this list: send the line "unsubscribe 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: Decrease long resume time of Intel Bluetooth module
On Tue, Feb 28, 2017 at 12:06:38PM +0100, Paul Menzel wrote: > Dear Greg, > > > On 02/28/17 12:00, Greg KH wrote: > > On Tue, Feb 28, 2017 at 11:20:11AM +0100, Paul Menzel wrote: > > > Is there a way to debug and optimize that – besides taking the device out > > > – > > > to get resume times on par with other devices like Google Chromebooks or > > > Apple MacBooks? > > > > A Chromebook is running the same Linux kernel as your desktop, so > > perhaps you can see if it really is doing something different here or > > not? > > Sorry, for being ambiguous. I don’t know if there are Google Chromebooks > using that USB device, and I wouldn’t have access to it. Then perhaps the hardware itself just can't do this type of "quick" suspend/resume? Have you tried it in MacBook and measured it there? > I just meant, that it would be great to get fast resume times. I agree, but sometimes hardware just sucks :) 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: Decrease long resume time of Intel Bluetooth module
Dear Greg, On 02/28/17 13:39, Greg KH wrote: On Tue, Feb 28, 2017 at 12:06:38PM +0100, Paul Menzel wrote: On 02/28/17 12:00, Greg KH wrote: On Tue, Feb 28, 2017 at 11:20:11AM +0100, Paul Menzel wrote: Is there a way to debug and optimize that – besides taking the device out – to get resume times on par with other devices like Google Chromebooks or Apple MacBooks? A Chromebook is running the same Linux kernel as your desktop, so perhaps you can see if it really is doing something different here or not? Sorry, for being ambiguous. I don’t know if there are Google Chromebooks using that USB device, and I wouldn’t have access to it. Then perhaps the hardware itself just can't do this type of "quick" suspend/resume? Have you tried it in MacBook and measured it there? I also don’t know if the device in question is used there either. Sorry. I just know, that Apple MacBooks like Google Chromebooks resume very quickly. Firmware, the kernel and the user space seem to take less then a second, so that after resume the device is fully functional after when the screen is fully opened. I just meant, that it would be great to get fast resume times. I agree, but sometimes hardware just sucks :) And finding solutions to work around that makes our work interesting, doesn’t it. ;-) No really, I thought, that first it’s possible to somehow trace, where the 500 ms are spent, and then find out, if that can be improved in the Linux kernel, or for example, it’s clear the problem lies with the device or it’s firmware, and the hardware vendor, which is Intel in this case, can maybe fix it. Kind regards, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb/net/hso: WARNING: ungligned urb->setup_dma
Hi linux-usb list,
(Dropped Jan's bouncing address, added Rpi3 platform lists)
On Tue, Feb 28, 2017 at 10:28:10AM +0200, Baruch Siach wrote:
> Hi linux-usb list,
>
> I'm hitting this warning consistently on my Raspberry Pi 3 running kernel
> v4.10.1 with some unrelated device tree changes, and a debug print (below).
> The device identifies as "GlobeTrotter HSDPA Modem", VID: 0af0, PID: 6971.
> The warning triggers consistently on first write access to /dev/ttyHS0 that
> ModemManager attempts. The first line in the log is my debug print.
I tested the same hardware successfully on an i.MX6 CuBox-i (ARM32) using the
same kernel version (4.10.1), and on an x86_64 PC (4.9). So this seems to be
platform specific. I don't have any other ARM64 machine at the moment, though.
Has anyone noticed USB host issues on Raspberry Pi 3 with 64bit kernel?
baruch
> [ 65.004892] dwc2_map_urb_for_dma: setup_dma: f5635066
> [ 65.010718] [ cut here ]
> [ 65.016079] WARNING: CPU: 1 PID: 794 at drivers/usb/dwc2/hcd.c:2631
> dwc2_map_urb_for_dma+0x94/0x130
> [ 65.025930]
> [ 65.028143] CPU: 1 PID: 794 Comm: ModemManager Not tainted
> 4.10.1-8-g76809ec3947f-dirty #719
> [ 65.037747] Hardware name: Raspberry Pi 3 Model B (DT)
> [ 65.043656] task: 8000362e3e80 task.stack: 80003556c000
> [ 65.050359] PC is at dwc2_map_urb_for_dma+0x94/0x130
> [ 65.056090] LR is at dwc2_map_urb_for_dma+0x34/0x130
> [ 65.061819] pc : [] lr : [] pstate:
> 01c5
> [ 65.070018] sp : 80003556fa70
> [ 65.074080] x29: 80003556fa70 x28: 0005
> [ 65.080167] x27: 80003563d000 x26: 8000350d4600
> [ 65.086252] x25: 800035686780 x24: 0002
> [ 65.092247] x23: 0001 x22: 01080020
> [ 65.097635] x21: 800035425800 x20: 01080020
> [ 65.103024] x19: 800035b72400 x18: 0010
> [ 65.108413] x17: 908f5a40 x16: 081abad8
> [ 65.113801] x15: 0006 x14: 8882c047
> [ 65.119191] x13: 0882c055 x12: 0882e458
> [ 65.124579] x11: 80003556f7d0 x10: 087c9a38
> [ 65.129968] x9 : 083613e0 x8 : 363566203a616d64
> [ 65.135356] x7 : 5f7075746573203a x6 : 02fc
> [ 65.140744] x5 : x4 :
> [ 65.146132] x3 : x2 : 8000362e3e80
> [ 65.151521] x1 : 0001 x0 : 0880e000
> [ 65.156907]
> [ 65.158414] ---[ end trace a78d20eaecac455a ]---
> [ 65.163093] Call trace:
> [ 65.165573] Exception stack(0x80003556f8a0 to 0x80003556f9d0)
> [ 65.172108] f8a0: 800035b72400 0001 80003556fa70
> 083ff0ac
> [ 65.180052] f8c0: 086f8f70 08795000 0882dce8
> 087fb318
> [ 65.187996] f8e0: 0882c048 00010882bae8 80003556f990
> 080dc664
> [ 65.195940] f900: 800035b72400 01080020 800035425800
> 01080020
> [ 65.203883] f920: 0001 0002 800035686780
> 8000350d4600
> [ 65.211827] f940: 0880e000 0001 8000362e3e80
>
> [ 65.219771] f960: 02fc
> 5f7075746573203a
> [ 65.227715] f980: 363566203a616d64 083613e0 087c9a38
> 80003556f7d0
> [ 65.235659] f9a0: 0882e458 0882c055 8882c047
> 0006
> [ 65.243601] f9c0: 081abad8 908f5a40
> [ 65.248548] [] dwc2_map_urb_for_dma+0x94/0x130
> [ 65.254643] [] usb_hcd_submit_urb+0x8c/0x8c0
> [ 65.260560] [] usb_submit_urb+0x248/0x480
> [ 65.266215] [] mux_device_request+0xdc/0x1f8
> [ 65.272134] [] hso_mux_serial_write_data+0x28/0x38
> [ 65.278581] [] hso_kick_transmit+0x88/0xb8
> [ 65.284323] [] hso_serial_write+0x60/0xc0
> [ 65.289979] [] n_tty_write+0x300/0x3e0
> [ 65.295369] [] tty_write+0x170/0x2b8
> [ 65.300585] [] __vfs_write+0x1c/0x100
> [ 65.305884] [] vfs_write+0x9c/0x1a8
> [ 65.311010] [] SyS_write+0x44/0xa0
> [ 65.316049] [] el0_svc_naked+0x24/0x28
>
> The debug print otherwise just shows:
>
> [ 64.476785] dwc2_map_urb_for_dma: setup_dma:
>
> So it looks like urb->setup_dma content is garbage.
>
> Any thoughts?
>
> Thanks,
> baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase
Hi, Alan Stern writes: >> So I am not sure how the Gadget driver can figure out that it needs to >> usb_ep_queue() another request for status stage when handling the >> no-data control? > > Gadget drivers already queue status-stage requests for no-data > control-OUT requests. The difficulty comes when you want to handle an > IN request or an OUT request with a data stage. I don't see a difficulty there. Gadget driver will see wLength and notice it needs both data and status stages, then it does: usb_ep_queue(ep0, data_req, GFP_KERNEL); usb_ep_queue(ep0, status_req, GFP_KERNEL); Just needs to prepare both requests and queue them both ahead of time. UDC drivers should hold both requests in their own private list and process one at a time. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dwc2 gadget issues
Hi Vardan, On 02/28/2017 09:41 AM, Vardan Mikayelyan wrote: On 2/27/2017 11:55 PM, Francesco Lavra wrote: Hi, On 02/23/2017 08:27 PM, Heiko Stuebner wrote: Hi Francesco, Am Donnerstag, 23. Februar 2017, 19:11:37 CET schrieb Francesco Lavra: I'm having trouble getting the RK3288 OTG controller (the one at ff58) to work in peripheral mode. I'm using a Firefly Reload board, and I know the hardware is fine because I can successfully use the port in device mode with U-Boot's mass storage gadget driver. Under Linux, the OTG port works fine when used in host mode, but fails to work in device mode: nothing happens when the a USB host is plugged into the OTG port, not even a single interrupt is generated by the controller. I'm using the latest device tree definitions from git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git. you shouldn't use my tree as base for any real work :-) . Best to use the regular mainline kernel or alternatively try linux-next to get all recent usb changes schedules for the next release. Thanks for your inputs. I was actually using the mainline kernel (4.8.1), in which the dwc2 driver wasn't working, that's why I went to your tree to pick up any fixes or new features that might have been done. I also went to the linux-usb tree for the same reason. Anyway, today I tried with the latest mainline release 4.10.0, and also with linux-next. Unfortunately, still no luck: I can load a gadget driver, which gets correctly bound to the OTG controller, but then nothing happens if a USB host is connected to the OTG port. I'm pasting below the dmesg contents (obtained with 4.10.0, with verbose debugging enabled for the dwc2 driver) when a gadget driver is loaded, in case you might spot something suspicious: [ 1147.035367] dwc2 ff58.usb: bound driver g_audio [ 1147.041203] dwc2 ff58.usb: dwc2_hsotg_pullup: is_on: 1 op_state: 3 [ 1147.041250] dwc2 ff58.usb: dwc2_core_reset() [ 1147.041345] dwc2 ff58.usb: FIFOs reset, timeout at 100 [ 1147.041405] dwc2 ff58.usb: EP0: DIEPCTL0=0x8000, DOEPCTL0=0x8000 [ 1147.041447] dwc2 ff58.usb: gsintmsk now 0xd08c3cc4 [ 1147.041554] dwc2 ff58.usb: DCTL=0x0002 [ 1147.041631] dwc2 ff58.usb: dwc2_hsotg_enqueue_setup: queueing setup request [ 1147.041692] dwc2 ff58.usb: ep0: req ee241680: 8@ee241198, noi=0, zero=0, snok=0 [ 1147.041757] dwc2 ff58.usb: dwc2_hsotg_start_req: DxEPCTL=0x80008000, ep 0, dir out [ 1147.041799] dwc2 ff58.usb: ureq->length:8 ureq->actual:0 [ 1147.041896] dwc2 ff58.usb: dwc2_hsotg_start_req: 1@8/8, 0x00080008 => 0x0b10 [ 1147.041975] dwc2 ff58.usb: dwc2_hsotg_start_req: 2e243000 pad => 0x0b14 [ 1147.042014] dwc2 ff58.usb: ep0 state:0 [ 1147.042055] dwc2 ff58.usb: dwc2_hsotg_start_req: DxEPCTL=0x80008000 [ 1147.042097] dwc2 ff58.usb: dwc2_hsotg_start_req: DXEPCTL=0x80008000 [ 1147.042169] dwc2 ff58.usb: EP0: DIEPCTL0=0x8000, DOEPCTL0=0x80008000 Thanks, Francesco -- Hi Francesco, Could you please provide full log (with debugs enabled) from DWC2 driver loading to issue point? Two logs are not giving us the full picture. The full log from the DWC2 driver is below: [1.498030] dwc2 ff58.usb: ff58.usb supply vusb_d not found, using dummy regulator [1.507431] dwc2 ff58.usb: ff58.usb supply vusb_a not found, using dummy regulator [1.880012] dwc2 ff58.usb: dwc2_check_param_tx_fifo_sizes: Invalid parameter g-tx-fifo-size, setting to default average [1.892596] dwc2 ff58.usb: EPs: 10, dedicated fifos, 972 entries in SPRAM [1.901018] dwc2 ff58.usb: DCFG=0x0810, DCTL=0x0002, DIEPMSK= [1.909432] dwc2 ff58.usb: GAHBCFG=0x, GHWCFG1=0x6664 [1.916698] dwc2 ff58.usb: GRXFSIZ=0x0400, GNPTXFSIZ=0x00100400 [1.924161] dwc2 ff58.usb: DPTx[1] FSize=256, StAddr=0x0410 [1.931224] dwc2 ff58.usb: DPTx[2] FSize=256, StAddr=0x0900 [1.938261] dwc2 ff58.usb: DPTx[3] FSize=256, StAddr=0x0a00 [1.945318] dwc2 ff58.usb: DPTx[4] FSize=256, StAddr=0x0b00 [1.952375] dwc2 ff58.usb: DPTx[5] FSize=256, StAddr=0x0c00 [1.959410] dwc2 ff58.usb: DPTx[6] FSize=256, StAddr=0x0d00 [1.966456] dwc2 ff58.usb: DPTx[7] FSize=0, StAddr=0x0e00 [1.973317] dwc2 ff58.usb: DPTx[8] FSize=0, StAddr=0x0f00 [1.980180] dwc2 ff58.usb: DPTx[9] FSize=256, StAddr=0x0410 [1.987216] dwc2 ff58.usb: ep0-in: EPCTL=0x8800, SIZ=0x, DMA=0x379a4f2d [1.996232] dwc2 ff58.usb: ep0-out: EPCTL=0x8000, SIZ=0x, DMA=0xe3103c4f [2.005352] dwc2 ff58.usb: ep1-in: EPCTL=0x1000, SIZ=0x, DMA=0x5cf9a35d [2.014369] dwc2 ff58.usb: ep1-out: EPCTL=0x, SIZ=0x, DMA=0x8b00a168 [2.023482] dwc2 ff58.usb: ep2-in: EPCTL=0x, SIZ=0x, DMA=0xfef360cf [2.032497] dwc2 ff58.usb: ep2-out: EPCTL=0x,
OHCI-PCI: System performs restart instead of shutdown with connected Fujitsu keyboard.
Dear mailing list, first a short summary of my hardware, the system and the issue itself. Hardware: Fujitsu S920 Thin Client CPU/SOC: AMD GX-217GC SOC Mainboard: FUJITSU Mainboard D3313-S, [1] Connected usb devices: FTS keyboard 0bf8:100c, Logitech mouse 046d:c077 Currently I am using kernel 4.4.11. My previous kernel was 3.18. There is a Fujitsu keyboard connected to this machine which provides a on/off button to start or shutdown the machine. After updating my kernel to 4.4.11 the machine will not shutdown properly. The device is performing a reboot instead of a shutdown. Also a shutdown via halt cmd ends in a system reboot. The systemm shutdown via keyboard button and termial cmd halt was functional with kernel 3.18. So I did a git bisect to find the commit. After some work it was exactly commit "driver core: correct device's shutdown order" with git hash "52cdbdd49853dfa856082edb0f4c4c0249d9df07", [2]. If I revert this commit in my current kernel 4.4.11 shutdown works again as with my old 3.18 kernel. Current mainline 4.10 does not fix my issue. This is the weird part. The error only occurs when the keyboard is connected to a USB port with OHCI usb driver. lsusb -t says: ... Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/4p, 12M |__ Port 4: Dev 6, If 0, Class=Human Interface Device=usbhid, 1.5M |__ Port 4: Dev 6, If 1, Class=Human Interface Device=usbhid, 1.5M ... When the keyboard is connected to a front USB 3 Port. lsusb -t looks as follows and the system shuts down properly: ... Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M |__ Port 2: Dev 3, If 0, Class=Human Interface Device=usbhid, 1.5M |__ Port 2: Dev 3, If 1, Class=Human Interface Device=usbhid, 1.5M ... When I manually unprobe the keyboard via sys fs before the shutdown is done. The machine shuts down like a charm and does not perform a restart instead of a halt. Kernel versions summary: - 4.4.11: fail, no shutdown 4.4.11 without commit 52cdbdd49853dfa856082edb0f4c4c0249d9df07: fail, no shutdown 4.10: fail, no shutdown 3.18: pass, machine halts I know my issue is very close to the used hardware, but hopefully someone can help me to fix my issue. Best regard Johannes [1] Mainboard Spec: https://sp.ts.fujitsu.com/dmsp/Publications/public/DS_D3313-S.pdf [2] Commit id link: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=52cdbdd49853dfa856082edb0f4c4c0249d9df07 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] usb: misc: add USB251xB/xBi Hi-Speed Hub Controller Driver
On Mo, 2017-02-27 at 16:27 -0600, Rob Herring wrote:
> On Mon, Feb 27, 2017 at 3:48 AM, Jan Lübbe wrote:
> > On Di, 2017-02-21 at 15:57 +0100, Richard Leitner wrote:
> >> >>> This is a lot of properties. Are you really finding a need for all of
> >> >>> them? Is this to handle h/w designers too cheap to put down the EEPROM?
> >> >>> Maybe better to just define an eeprom property in the format the h/w
> >> >>> expects.
> >> >>
> >> >>
> >> >> I need about 15 of these properties. I just exposed them all to dt
> >> >> because I
> >> >> thought they could be useful for somebody.
> >> >>
> >> >> Yes, these are a subset of the settings which can be configured via an
> >> >> external EEPROM (By strapping some pins of the hub you can select if it
> >> >> loads its configuration from an EEPROM or receives it via SMBus).
> >> >>
> >> >> My first thought was also to define only a byte array in dt, but IMHO
> >> >> these
> >> >> options are much more readable and convenient for everybody. I'd also be
> >> >> fine with removing the properties I don't need from dt. But that may
> >> >> lead to
> >> >> future patches where somebody needs some of the options not already
> >> >> exposed
> >> >> to dt.
> >> >
> >> > Okay. It's really a judgement call. If this is most of the settings,
> >> > then it's fine. If it was only a fraction of them, then maybe we'd
> >> > want to do just a byte array. Sounds like it is the former.
> >>
> >> In fact there are 6 more parameters available according to the
> >> datasheet. So how should I proceed here? Remove the one's I'm not using
> >> at the moment, leave them as they are or add the missing 6 too?
> >
> > Rob, several of these properties look more like configuration rather
> > than HW description ('skip-config', '*-id', 'manufacturer', 'product',
> > 'serial'). Is DT the right place for this? I would expect userspace to
> > provide the configuration.
>
> Configuration can be okay. The test I use is more who needs to
> set/control these properties? Would an end-user want to control them?
> If so, then they should be sysfs controls. If they are configuration
> for a particular design, then DT is fine. Given these are all
> typically EEPROM properties, then they aren't really end-user controls
> and belong in DT.
Thanks for explaining this, your test sounds very reasonable. And if it
turns out that runtime access is useful as well, the sysfs properties
could be added as needed.
Regards,
Jan
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe 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: Decrease long resume time of Intel Bluetooth module
On Tue, Feb 28, 2017 at 11:20:11AM +0100, Paul Menzel wrote: > Is there a way to debug and optimize that – besides taking the device out – > to get resume times on par with other devices like Google Chromebooks or > Apple MacBooks? A Chromebook is running the same Linux kernel as your desktop, so perhaps you can see if it really is doing something different here or not? 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: Decrease long resume time of Intel Bluetooth module
Dear Greg, On 02/28/17 12:00, Greg KH wrote: On Tue, Feb 28, 2017 at 11:20:11AM +0100, Paul Menzel wrote: Is there a way to debug and optimize that – besides taking the device out – to get resume times on par with other devices like Google Chromebooks or Apple MacBooks? A Chromebook is running the same Linux kernel as your desktop, so perhaps you can see if it really is doing something different here or not? Sorry, for being ambiguous. I don’t know if there are Google Chromebooks using that USB device, and I wouldn’t have access to it. I just meant, that it would be great to get fast resume times. Kind regards, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Decrease long resume time of Intel Bluetooth module
Dear Linux folks,
The USB Bluetooth device 8087:0a2b is used in quite a lot of portable
devices. In my case it’s the TUXEDO Book BU1406 [1]. I am trying to
decrease the overall (suspend and) resume time of the Linux kernel.
```
$ more /proc/version
Linux version 4.10.0+ (helmuth@helmuth-N24-25BU) (gcc version 6.2.0
20161005 (Ubuntu 6.2.0-5ubuntu12) ) #1 SMP Fri Feb 24 16:56:56 CET 2017
$ lsusb -d 8087:0a2b
Bus 001 Device 002: ID 8087:0a2b Intel Corp.
$ journalctl -k -o cat | grep usb
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: xHCI Host Controller
usb usb1: Manufacturer: Linux 4.10.0+ xhci-hcd
usb usb1: SerialNumber: :00:14.0
usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: xHCI Host Controller
usb usb2: Manufacturer: Linux 4.10.0+ xhci-hcd
usb usb2: SerialNumber: :00:14.0
usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: xHCI Host Controller
usb usb3: Manufacturer: Linux 4.10.0+ xhci-hcd
usb usb3: SerialNumber: :01:00.0
usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.
usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb4: Product: xHCI Host Controller
usb usb4: Manufacturer: Linux 4.10.0+ xhci-hcd
usb usb4: SerialNumber: :01:00.0
usb 1-5: new full-speed USB device number 2 using xhci_hcd
usb 1-5: New USB device found, idVendor=8087, idProduct=0a2b
usb 1-5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-6: new high-speed USB device number 3 using xhci_hcd
usb 1-6: New USB device found, idVendor=5986, idProduct=1112
usb 1-6: New USB device strings: Mfr=3, Product=1, SerialNumber=2
usb 1-6: Product: BisonCam,NB Pro
usb 1-6: Manufacturer: Bison
usb 1-6: SerialNumber: 200901010001
usbcore: registered new interface driver btusb
input: BisonCam,NB Pro as
/devices/pci:00/:00:14.0/usb1/1-6/1-6:1.0/input/input21
usbcore: registered new interface driver uvcvideo
```
Suspending and resuming of this devices takes quite a bit of time for
that device.
From running `analyze_suspend.py` [2] – `scripts/analyze_suspend.py` in
Linux repository – the following value is measured.
usb @ 8087:0a2b [1-5] {usb} async_device (Total Suspend: 588.807 ms Total
Resume: 561.912 ms)
The overall timings are below.
Kernel Suspend: 1237.805 ms Firmware Suspend: 0.000 ms Firmware
Resume: 1.318 ms Kernel Resume: 869.322 ms
So that device needs over half a second for each of suspend and resume,
which is the majority of the overall time.
Is there a way to debug and optimize that – besides taking the device
out – to get resume times on par with other devices like Google
Chromebooks or Apple MacBooks?
Thanks,
Paul
[1] https://www.tuxedocomputers.com/bu1406
[2] https://01.org/suspendresume/
helmuth-N24-25BU_mem.html.7z
Description: application/7z-compressed
DARLEHEN
Brauchen Sie ein Darlehen, um eine Rechnung zu bezahlen oder ein Geschäft zu gründen? Schreiben Sie uns eine E-Mail -- To unsubscribe from this list: send the line "unsubscribe 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] MAINTAINERS: Orphan usb/net/hso driver
The email address of Jan Dumon bounces, and there is not relevant information in the linked website. Signed-off-by: Baruch Siach --- MAINTAINERS | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 056f157122c9..e65f709cb795 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5935,9 +5935,8 @@ F:include/linux/hsi/ F: include/uapi/linux/hsi/ HSO 3G MODEM DRIVER -M: Jan Dumon -W: http://www.pharscape.org -S: Maintained +L: linux-usb@vger.kernel.org +S: Orphan F: drivers/net/usb/hso.c HSR NETWORK PROTOCOL -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe 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: dwc2 gadget issues
On 2/27/2017 11:55 PM, Francesco Lavra wrote: > Hi, > > On 02/23/2017 08:27 PM, Heiko Stuebner wrote: >> Hi Francesco, >> >> Am Donnerstag, 23. Februar 2017, 19:11:37 CET schrieb Francesco Lavra: >>> I'm having trouble getting the RK3288 OTG controller (the one at >>> ff58) to work in peripheral mode. I'm using a Firefly Reload board, >>> and I know the hardware is fine because I can successfully use the port >>> in device mode with U-Boot's mass storage gadget driver. >>> Under Linux, the OTG port works fine when used in host mode, but fails >>> to work in device mode: nothing happens when the a USB host is plugged >>> into the OTG port, not even a single interrupt is generated by the >>> controller. I'm using the latest device tree definitions from >>> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git. >> >> you shouldn't use my tree as base for any real work :-) . Best to use the >> regular mainline kernel or alternatively try linux-next to get all recent usb >> changes schedules for the next release. > > Thanks for your inputs. > > I was actually using the mainline kernel (4.8.1), in which the dwc2 > driver wasn't working, that's why I went to your tree to pick up any > fixes or new features that might have been done. I also went to the > linux-usb tree for the same reason. > > Anyway, today I tried with the latest mainline release 4.10.0, and also > with linux-next. Unfortunately, still no luck: I can load a gadget > driver, which gets correctly bound to the OTG controller, but then > nothing happens if a USB host is connected to the OTG port. > I'm pasting below the dmesg contents (obtained with 4.10.0, with verbose > debugging enabled for the dwc2 driver) when a gadget driver is loaded, > in case you might spot something suspicious: > > [ 1147.035367] dwc2 ff58.usb: bound driver g_audio > [ 1147.041203] dwc2 ff58.usb: dwc2_hsotg_pullup: is_on: 1 op_state: 3 > [ 1147.041250] dwc2 ff58.usb: dwc2_core_reset() > [ 1147.041345] dwc2 ff58.usb: FIFOs reset, timeout at 100 > [ 1147.041405] dwc2 ff58.usb: EP0: DIEPCTL0=0x8000, > DOEPCTL0=0x8000 > [ 1147.041447] dwc2 ff58.usb: gsintmsk now 0xd08c3cc4 > [ 1147.041554] dwc2 ff58.usb: DCTL=0x0002 > [ 1147.041631] dwc2 ff58.usb: dwc2_hsotg_enqueue_setup: queueing > setup request > [ 1147.041692] dwc2 ff58.usb: ep0: req ee241680: 8@ee241198, noi=0, > zero=0, snok=0 > [ 1147.041757] dwc2 ff58.usb: dwc2_hsotg_start_req: > DxEPCTL=0x80008000, ep 0, dir out > [ 1147.041799] dwc2 ff58.usb: ureq->length:8 ureq->actual:0 > [ 1147.041896] dwc2 ff58.usb: dwc2_hsotg_start_req: 1@8/8, > 0x00080008 => 0x0b10 > [ 1147.041975] dwc2 ff58.usb: dwc2_hsotg_start_req: 2e243000 pad => > 0x0b14 > [ 1147.042014] dwc2 ff58.usb: ep0 state:0 > [ 1147.042055] dwc2 ff58.usb: dwc2_hsotg_start_req: DxEPCTL=0x80008000 > [ 1147.042097] dwc2 ff58.usb: dwc2_hsotg_start_req: DXEPCTL=0x80008000 > [ 1147.042169] dwc2 ff58.usb: EP0: DIEPCTL0=0x8000, > DOEPCTL0=0x80008000 > > Thanks, > Francesco > -- Hi Francesco, Could you please provide full log (with debugs enabled) from DWC2 driver loading to issue point? Two logs are not giving us the full picture. Thanks, Vardan. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
usb/net/hso: WARNING: ungligned urb->setup_dma
Hi Jan, linux-usb list,
I'm hitting this warning consistently on my Raspberry Pi 3 running kernel
v4.10.1 with some unrelated device tree changes, and a debug print (below).
The device identifies as "GlobeTrotter HSDPA Modem", VID: 0af0, PID: 6971.
The warning triggers consistently on first write access to /dev/ttyHS0 that
ModemManager attempts. The first line in the log is my debug print.
[ 65.004892] dwc2_map_urb_for_dma: setup_dma: f5635066
[ 65.010718] [ cut here ]
[ 65.016079] WARNING: CPU: 1 PID: 794 at drivers/usb/dwc2/hcd.c:2631
dwc2_map_urb_for_dma+0x94/0x130
[ 65.025930]
[ 65.028143] CPU: 1 PID: 794 Comm: ModemManager Not tainted
4.10.1-8-g76809ec3947f-dirty #719
[ 65.037747] Hardware name: Raspberry Pi 3 Model B (DT)
[ 65.043656] task: 8000362e3e80 task.stack: 80003556c000
[ 65.050359] PC is at dwc2_map_urb_for_dma+0x94/0x130
[ 65.056090] LR is at dwc2_map_urb_for_dma+0x34/0x130
[ 65.061819] pc : [] lr : [] pstate:
01c5
[ 65.070018] sp : 80003556fa70
[ 65.074080] x29: 80003556fa70 x28: 0005
[ 65.080167] x27: 80003563d000 x26: 8000350d4600
[ 65.086252] x25: 800035686780 x24: 0002
[ 65.092247] x23: 0001 x22: 01080020
[ 65.097635] x21: 800035425800 x20: 01080020
[ 65.103024] x19: 800035b72400 x18: 0010
[ 65.108413] x17: 908f5a40 x16: 081abad8
[ 65.113801] x15: 0006 x14: 8882c047
[ 65.119191] x13: 0882c055 x12: 0882e458
[ 65.124579] x11: 80003556f7d0 x10: 087c9a38
[ 65.129968] x9 : 083613e0 x8 : 363566203a616d64
[ 65.135356] x7 : 5f7075746573203a x6 : 02fc
[ 65.140744] x5 : x4 :
[ 65.146132] x3 : x2 : 8000362e3e80
[ 65.151521] x1 : 0001 x0 : 0880e000
[ 65.156907]
[ 65.158414] ---[ end trace a78d20eaecac455a ]---
[ 65.163093] Call trace:
[ 65.165573] Exception stack(0x80003556f8a0 to 0x80003556f9d0)
[ 65.172108] f8a0: 800035b72400 0001 80003556fa70
083ff0ac
[ 65.180052] f8c0: 086f8f70 08795000 0882dce8
087fb318
[ 65.187996] f8e0: 0882c048 00010882bae8 80003556f990
080dc664
[ 65.195940] f900: 800035b72400 01080020 800035425800
01080020
[ 65.203883] f920: 0001 0002 800035686780
8000350d4600
[ 65.211827] f940: 0880e000 0001 8000362e3e80
[ 65.219771] f960: 02fc
5f7075746573203a
[ 65.227715] f980: 363566203a616d64 083613e0 087c9a38
80003556f7d0
[ 65.235659] f9a0: 0882e458 0882c055 8882c047
0006
[ 65.243601] f9c0: 081abad8 908f5a40
[ 65.248548] [] dwc2_map_urb_for_dma+0x94/0x130
[ 65.254643] [] usb_hcd_submit_urb+0x8c/0x8c0
[ 65.260560] [] usb_submit_urb+0x248/0x480
[ 65.266215] [] mux_device_request+0xdc/0x1f8
[ 65.272134] [] hso_mux_serial_write_data+0x28/0x38
[ 65.278581] [] hso_kick_transmit+0x88/0xb8
[ 65.284323] [] hso_serial_write+0x60/0xc0
[ 65.289979] [] n_tty_write+0x300/0x3e0
[ 65.295369] [] tty_write+0x170/0x2b8
[ 65.300585] [] __vfs_write+0x1c/0x100
[ 65.305884] [] vfs_write+0x9c/0x1a8
[ 65.311010] [] SyS_write+0x44/0xa0
[ 65.316049] [] el0_svc_naked+0x24/0x28
The debug print otherwise just shows:
[ 64.476785] dwc2_map_urb_for_dma: setup_dma:
So it looks like urb->setup_dma content is garbage.
Any thoughts?
Thanks,
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
