[PATCH v2 1/1] usb: chipidea: debug: add low power mode check before print registers
Since the required clock to access registers is gated off in low power mode,
add ci->in_lpm check before try to dump registers value.
Signed-off-by: Li Jun
---
drivers/usb/chipidea/debug.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
index 268e423..a367cee 100644
--- a/drivers/usb/chipidea/debug.c
+++ b/drivers/usb/chipidea/debug.c
@@ -339,6 +339,11 @@ static int ci_registers_show(struct seq_file *s, void
*unused)
if (!ci)
return 0;
+ if (ci->in_lpm) {
+ seq_printf(s, "Can't dump registers value in low power mode\n");
+ return 0;
+ }
+
/* -- Registers - */
tmp_reg = hw_read_intr_enable(ci);
seq_printf(s, "USBINTR reg: %08x\n", tmp_reg);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: Fix warnings in chaoskey driver
On Thu, 2015-03-26 at 16:49 -0700, kei...@keithp.com wrote: > > >> drivers/usb/misc/chaoskey.c:117:30: sparse: incorrect type in > assignment (different base types) > >drivers/usb/misc/chaoskey.c:117:30:expected int [signed] size > >drivers/usb/misc/chaoskey.c:117:30:got restricted __le16 > [usertype] wMaxPacketSize > > Switched the code to using the USB descriptor accessor functions. Hi, this fixes an endianness bug. So it should still be merged late in the cycle. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need a phy function to enable / disable usb squelch detection
Hi,
On 27-03-15 02:21, Peter Chen wrote:
Hi Kishon,
I've been debugging why some devices do not work with the musb otg
controller found on Allwinner SoC-s, and the conclusion is not good, the
Android kernel does a poke to the phy before releasing the usb reset.
Now you did not want me to introduce any sunxi specific / private phy
functions in my initial patch-series for adding sunxi support, but in this case
I do
not really see an alternative, as this is a very platform specific hack to work
around an issue with the phy-s squelch detection which causes it to see a
squelch when reset is released switching it to high speed mode when a lo
speed device is connected, after which things fall apart.
The nofity_connect API at struct usb_phy may satisfy your requirement,
it will be called after bus rest has finished.
Thanks for the suggestion, but that is too late, I try to write a patch
set for this tonight (my sunxi musb work is a spare time project), as
I think that will make the discussion easier.
What I need is a way to disable squelch detection on the phy before clearing
the root port reset bit in the musb controller, currently we have this:
drivers/usb/musb/musb_virthub.c: void musb_port_reset()
if (do_reset) {
...
} else {
dev_dbg(musb->controller, "root port reset stopped\n");
musb_writeb(mbase, MUSB_POWER, power & ~MUSB_POWER_RESET);
...
}
In order to work around the phy bug I need to do this (I got this from
the Allwinner android kernel sources and it seems the only way):
if (do_reset) {
...
} else {
dev_dbg(musb->controller, "root port reset stopped\n");
musb_platform_pre_reset_end();
musb_writeb(mbase, MUSB_POWER, power & ~MUSB_POWER_RESET);
musb_platform_post_reset_end();
...
}
Notice the 2 new musb_platform_... calls, these are to be empty stubs for
all platforms except sunxi, where they need to call into the phy driver.
All in all I really believe this is so specific that a platform specific
phy callback is best, so that is what I'll do for the first version of
my patchset for this,
Regards,
Hans
--
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: Errata for Freescale root-hub TT?
On Wed, Mar 25, 2015 at 10:11:27AM -0400, Alan Stern wrote: > On Wed, 25 Mar 2015, Peter Chen wrote: > > > > > How do you know the frame has filled already at that time? The software > > > > makes sure it fills frame in time before next time frame? > > > > > > I'm not sure I understand the question. > > > > > > The USB analyzer log showed something like this (this is a rough > > > approximation because I didn't keep the original analyzer output file): > > > > > > Timestamp Transaction > > > s.mmm uuu > > > --- > > > 0.000 000 SOF > > > 0.000 030 Isoc OUT > > > 0.000 091 Isoc OUT > > > 0.000 162 Isoc OUT > > > 0.000 224 Isoc OUT > > > 0.001 000 SOF > > > > > > In this example, there are 4 OUT transfers taking about 290 us and then > > > nothing else for the rest of the frame. > > > > > > I also know, from looking at the "periodic" file in the EHCI debugfs > > > directory, that each frame was linked to 8 siTDs: > > > > > > siTD OUT, Smask = 0x01, Cmask = 0x00, transfer length = 64 > > > siTD OUT, Smask = 0x01, Cmask = 0x00, transfer length = 64 > > > siTD OUT, Smask = 0x02, Cmask = 0x00, transfer length = 64 > > > siTD OUT, Smask = 0x02, Cmask = 0x00, transfer length = 64 > > > siTD IN, Smask = 0x04, Cmask = 0x70, transfer length = 64 > > > siTD IN, Smask = 0x04, Cmask = 0x70, transfer length = 64 > > > siTD IN, Smask = 0x08, Cmask = 0xe0, transfer length = 64 > > > siTD IN, Smask = 0x08, Cmask = 0xe0, transfer length = 64 > > > > > > > I did not debug too many for Host ISOC, I just want to make sure the > > siTD is ready before the controller read it? > > Yes, all the siTDs were ready before the controller read them. I know > because it worked perfectly when I used a high-speed hub instead of a > full-speed hub. > > > Does it fail at the beginning or running several cycles? > > The isochronous streams did not all start at the same time. First one > isoc-OUT stream started, then the second stream, then the third stream, > then the fourth stream. After that, the isoc-IN streams started, one > by one. > > The controller worked okay up until the time the isoc-IN streams began. > Before that, it transmitted the OUT packets correctly. After the > isoc-IN streams started, the controller sometimes transmitted only the > four OUT packets (like in the example above), sometimes a mixture of > OUT and IN packets, and sometimes only one or two IN packets. The > behavior was very erratic. > Hi Alan, I tried to your case today, but it seems full speed hub with siTD has some problems with latest greg's next tree, I use UAC2 with configfs for audio device, high speed hub works ok. The commands: aplay -D hw:1,0 audio32k16M.wav arecord -Dhw:1 -r 32000 -c 1 -f S16_LE -d 20 file_32.wav The corresponding failure logs: [ 81.542848] ci_hdrc ci_hdrc.0: iso sched full bd7d5100 [ 81.542884] usb 1-1.2: cannot submit urb 0, error -28: not enough bandwidth [ 355.078938] ci_hdrc ci_hdrc.0: iso sched full bd49cc00 [ 355.078969] usb 1-1.2: cannot submit urb 0, error -28: not enough bandwidth -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Doc: usb: gadget-testing: fix the parameter for capture channel mask
Fix the UAC2 parameter capture channel mask Signed-off-by: Peter Chen --- Documentation/usb/gadget-testing.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index f45b2bf..7769eee 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -629,7 +629,7 @@ Function-specific configfs interface The function name to use when creating the function directory is "uac2". The uac2 function provides these attributes in its function directory: - chmask - capture channel mask + c_chmask - capture channel mask c_srate - capture sampling rate c_ssize - capture sample size (bytes) p_chmask - playback channel mask -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb: gadget: hid: Fix static variable usage
If we have multiple instances of hid function, each of
them may have different report descriptor, also their
length may be different.
Currently we are using static hidg_desc varable which
is being filled in hidg_bind(). Then we send its content
to host in hidg_setup() function. This content may
have been already overwriten if another instance
has executed hidg_bind().
Signed-off-by: Krzysztof Opasiak
---
drivers/usb/gadget/function/f_hid.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/function/f_hid.c
b/drivers/usb/gadget/function/f_hid.c
index a2612fb..eeb2dc2 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -437,12 +437,20 @@ static int hidg_setup(struct usb_function *f,
| USB_REQ_GET_DESCRIPTOR):
switch (value >> 8) {
case HID_DT_HID:
+ {
+ struct hid_descriptor hidg_desc_copy = hidg_desc;
+
VDBG(cdev, "USB_REQ_GET_DESCRIPTOR: HID\n");
+ hidg_desc_copy.desc[0].bDescriptorType = HID_DT_REPORT;
+ hidg_desc_copy.desc[0].wDescriptorLength =
+ cpu_to_le16(hidg->report_desc_length);
+
length = min_t(unsigned short, length,
- hidg_desc.bLength);
- memcpy(req->buf, &hidg_desc, length);
+ hidg_desc_copy.bLength);
+ memcpy(req->buf, &hidg_desc_copy, length);
goto respond;
break;
+ }
case HID_DT_REPORT:
VDBG(cdev, "USB_REQ_GET_DESCRIPTOR: REPORT\n");
length = min_t(unsigned short, length,
@@ -632,6 +640,10 @@ static int hidg_bind(struct usb_configuration *c, struct
usb_function *f)
hidg_fs_in_ep_desc.wMaxPacketSize = cpu_to_le16(hidg->report_length);
hidg_hs_out_ep_desc.wMaxPacketSize = cpu_to_le16(hidg->report_length);
hidg_fs_out_ep_desc.wMaxPacketSize = cpu_to_le16(hidg->report_length);
+ /*
+* We can use hidg_desc struct here but we should not relay
+* that its content won't change after returning from this function.
+*/
hidg_desc.desc[0].bDescriptorType = HID_DT_REPORT;
hidg_desc.desc[0].wDescriptorLength =
cpu_to_le16(hidg->report_desc_length);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: hid: Fix static variable usage
On Thu, Mar 26, 2015 at 7:51 PM, Sergei Shtylyov wrote: > Hello. > > On 03/26/2015 06:03 PM, Krzysztof Opasiak wrote: > >> If we have multiple instances of hid function, each of >> them may have different report descriptor, also their >> length may be different. > > >> Currently we are using static hidg_desc varable which >> is being filled in hidg_bind(). Then we send its content >> to host in hidg_setup() function. This content may >> have been already overwriten if another instance >> has executed hidg_bind(). > > >> Signed-off-by: Krzysztof Opasiak >> --- >> drivers/usb/gadget/function/f_hid.c | 13 +++-- >> 1 file changed, 11 insertions(+), 2 deletions(-) > > >> diff --git a/drivers/usb/gadget/function/f_hid.c >> b/drivers/usb/gadget/function/f_hid.c >> index a2612fb..e3fb9ec 100644 >> --- a/drivers/usb/gadget/function/f_hid.c >> +++ b/drivers/usb/gadget/function/f_hid.c > > [...] >> >> @@ -632,6 +639,8 @@ static int hidg_bind(struct usb_configuration *c, >> struct usb_function *f) >> hidg_fs_in_ep_desc.wMaxPacketSize = >> cpu_to_le16(hidg->report_length); >> hidg_hs_out_ep_desc.wMaxPacketSize = >> cpu_to_le16(hidg->report_length); >> hidg_fs_out_ep_desc.wMaxPacketSize = >> cpu_to_le16(hidg->report_length); >> + /* We can use hidg_desc struct here but we should not relay >> + that its content won't change after returning */ > > >The preferred multi-line comment style is: > > /* > * bla > * bla > */ > I have fixed this in v2, thank you for this remark. Best regards, Krzysztof Opasiak -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] usb: chipidea: debug: add low power mode check before print registers
On Fri, Mar 27, 2015 at 03:06:27PM +0800, Li Jun wrote:
> Since the required clock to access registers is gated off in low power mode,
> add ci->in_lpm check before try to dump registers value.
>
> Signed-off-by: Li Jun
> ---
> drivers/usb/chipidea/debug.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
> index 268e423..a367cee 100644
> --- a/drivers/usb/chipidea/debug.c
> +++ b/drivers/usb/chipidea/debug.c
> @@ -339,6 +339,11 @@ static int ci_registers_show(struct seq_file *s, void
> *unused)
> if (!ci)
> return 0;
>
> + if (ci->in_lpm) {
> + seq_printf(s, "Can't dump registers value in low power mode\n");
> + return 0;
> + }
> +
> /* -- Registers - */
> tmp_reg = hw_read_intr_enable(ci);
> seq_printf(s, "USBINTR reg: %08x\n", tmp_reg);
> --
> 1.9.1
>
Why not just return error code, it will show warning message too.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] usb: chipidea: debug: add low power mode check before print registers
On Fri, Mar 27, 2015 at 05:07:59PM +0800, Peter Chen wrote:
> On Fri, Mar 27, 2015 at 03:06:27PM +0800, Li Jun wrote:
> > Since the required clock to access registers is gated off in low power mode,
> > add ci->in_lpm check before try to dump registers value.
> >
> > Signed-off-by: Li Jun
> > ---
> > drivers/usb/chipidea/debug.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
> > index 268e423..a367cee 100644
> > --- a/drivers/usb/chipidea/debug.c
> > +++ b/drivers/usb/chipidea/debug.c
> > @@ -339,6 +339,11 @@ static int ci_registers_show(struct seq_file *s, void
> > *unused)
> > if (!ci)
> > return 0;
> >
> > + if (ci->in_lpm) {
> > + seq_printf(s, "Can't dump registers value in low power mode\n");
> > + return 0;
> > + }
> > +
> > /* -- Registers - */
> > tmp_reg = hw_read_intr_enable(ci);
> > seq_printf(s, "USBINTR reg: %08x\n", tmp_reg);
> > --
> > 1.9.1
> >
>
> Why not just return error code, it will show warning message too.
>
Since this is debug only purpose code, compare just say this operation is not
allowed, I thought a specific message to tell debugger usb is in low power mode
may be more readable, if you prefer a simple return with -EPERM, I am also glad
take it:)
Li Jun
> --
>
> Best Regards,
> Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/1] usb: chipidea: debug: add low power mode check before print registers
Since the required clock to access registers is gated off in low power mode, add ci->in_lpm check before try to dump registers value. Signed-off-by: Li Jun --- drivers/usb/chipidea/debug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c index 268e423..dfb05ed 100644 --- a/drivers/usb/chipidea/debug.c +++ b/drivers/usb/chipidea/debug.c @@ -336,8 +336,8 @@ static int ci_registers_show(struct seq_file *s, void *unused) struct ci_hdrc *ci = s->private; u32 tmp_reg; - if (!ci) - return 0; + if (!ci || ci->in_lpm) + return -EPERM; /* -- Registers - */ tmp_reg = hw_read_intr_enable(ci); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usbhid: more mice with ALWAYS_POLL
During a stress test these mice kept dropping and reappearing
in runlevel 1 as opposed to 5.
Signed-off-by: Oliver Neukum
---
drivers/hid/hid-ids.h | 4
drivers/hid/usbhid/hid-quirks.c | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 7fe5590..7631bca 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -595,6 +595,10 @@
#define USB_DEVICE_ID_LOGITECH_HARMONY_FIRST 0xc110
#define USB_DEVICE_ID_LOGITECH_HARMONY_LAST 0xc14f
#define USB_DEVICE_ID_LOGITECH_HARMONY_PS3 0x0306
+#define USB_DEVICE_ID_LOGITECH_MOUSE_4D22 0x4d22
+#define USB_DEVICE_ID_LOGITECH_MOUSE_C01A 0xc01a
+#define USB_DEVICE_ID_LOGITECH_MOUSE_C05A 0xc05a
+#define USB_DEVICE_ID_LOGITECH_MOUSE_C06A 0xc06a
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD_CORD 0xc20a
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD 0xc211
#define USB_DEVICE_ID_LOGITECH_EXTREME_3D 0xc215
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 4e3ae9f..38cfe3b 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -80,7 +80,11 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28,
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE,
HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_4D22,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077,
HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C01A,
HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C05A,
HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C06A,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3_JP,
HID_QUIRK_NO_INIT_REPORTS },
--
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: Errata for Freescale root-hub TT?
On Fri, 27 Mar 2015, Peter Chen wrote: > Hi Alan, > > I tried to your case today, but it seems full speed hub with siTD > has some problems with latest greg's next tree, I use UAC2 with > configfs for audio device, high speed hub works ok. > > The commands: > aplay -D hw:1,0 audio32k16M.wav > arecord -Dhw:1 -r 32000 -c 1 -f S16_LE -d 20 file_32.wav > > The corresponding failure logs: > [ 81.542848] ci_hdrc ci_hdrc.0: iso sched full bd7d5100 > [ 81.542884] usb 1-1.2: cannot submit urb 0, error -28: not enough > bandwidth > [ 355.078938] ci_hdrc ci_hdrc.0: iso sched full bd49cc00 > [ 355.078969] usb 1-1.2: cannot submit urb 0, error -28: not enough > bandwidth That's strange. Can you please post the /sys/kernel/debug/usb/devices file (with the UAC2 gadget plugged in), and also collect a usbmon trace of the test? Thanks, 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] usbhid: typo in device ID
The device ID was wrong. Signed-off-by: Oliver Neukum CC: sta...@vger.kernel.org --- drivers/hid/hid-ids.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index 9c47867..559d31c 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -586,7 +586,7 @@ #define USB_VENDOR_ID_LOGITECH 0x046d #define USB_DEVICE_ID_LOGITECH_AUDIOHUB 0x0a0e #define USB_DEVICE_ID_LOGITECH_T6510xb00c -#define USB_DEVICE_ID_LOGITECH_C0770xc007 +#define USB_DEVICE_ID_LOGITECH_C0770xc077 #define USB_DEVICE_ID_LOGITECH_RECEIVER0xc101 #define USB_DEVICE_ID_LOGITECH_HARMONY_FIRST 0xc110 #define USB_DEVICE_ID_LOGITECH_HARMONY_LAST 0xc14f -- 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
[PATCH] usbhid: yet another mouse with ALWAYS_POLL
The device exists with two device IDs instead of one as previously
believed.
Signed-off-by: Oliver Neukum
---
drivers/hid/hid-ids.h | 3 ++-
drivers/hid/usbhid/hid-quirks.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 7631bca..fca19f0 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -460,7 +460,8 @@
#define USB_DEVICE_ID_UGCI_FIGHTING0x0030
#define USB_VENDOR_ID_HP 0x03f0
-#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE 0x0a4a
+#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A 0x0a4a
+#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A 0x0b4a
#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE 0x134a
#define USB_VENDOR_ID_HUION0x256c
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 38cfe3b..6c56834 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -78,7 +78,8 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28,
HID_QUIRK_NOGET },
- { USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE,
HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_HP,
USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A, HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_HP,
USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_4D22,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077,
HID_QUIRK_ALWAYS_POLL },
--
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
[GIT PULL] USB-serial fixes for v4.0-rc6
Hi Greg, Here are a few new device ids including a minor probe-logic clean up for 4.0-rc6. Thanks, Johan The following changes since commit 06e5801b8cb3fc057d88cb4dc03c0b64b2744cda: Linux 4.0-rc4 (2015-03-15 17:38:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git tags/usb-serial-4.0-rc6 for you to fetch changes up to b229a0f840f774d29d8fedbf5deb344ca36b7f1a: USB: ftdi_sio: Use jtag quirk for SNAP Connect E10 (2015-03-25 15:32:53 +0100) USB-serial fixes for v4.0-rc6 Here are a few new device IDs. Signed-off-by: Johan Hovold Doug Goldstein (2): USB: ftdi_sio: Added custom PID for Synapse Wireless product USB: ftdi_sio: Use jtag quirk for SNAP Connect E10 Nathaniel W Filardo (1): USB: keyspan_pda: add new device id drivers/usb/serial/ftdi_sio.c | 9 +++-- drivers/usb/serial/ftdi_sio_ids.h | 6 ++ drivers/usb/serial/keyspan_pda.c | 3 +++ 3 files changed, 16 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V9 02/10] USB: f81232: implement RX bulk-in EP
On Tue, Mar 17, 2015 at 05:48:20PM +0800, Peter Hung wrote:
> The F81232 bulk-in is RX data + LSR channel, data format is
> [LSR+Data][LSR+Data]. , We had implemented in f81232_process_read_urb().
>
> Signed-off-by: Peter Hung
> static void f81232_process_read_urb(struct urb *urb)
> {
> struct usb_serial_port *port = urb->context;
> - struct f81232_private *priv = usb_get_serial_port_data(port);
> unsigned char *data = urb->transfer_buffer;
> - char tty_flag = TTY_NORMAL;
> - unsigned long flags;
> - u8 line_status;
> - int i;
> + char tty_flag;
> + unsigned int i;
> + u8 lsr;
>
> - /* update line status */
> - spin_lock_irqsave(&priv->lock, flags);
> - line_status = priv->modem_status;
> - priv->modem_status &= ~UART_STATE_TRANSIENT_MASK;
> - spin_unlock_irqrestore(&priv->lock, flags);
> + /* It's had 1-byte packet on open, the data is current LSR. but
> + * in this situation, the byte useless for open.
> + */
I'll change this comment to
/*
* When opening the port we get a 1-byte packet with the current LSR,
* which we discard.
*/
before applying. Let me know if I managed to get it wrong.
>
> - if (!urb->actual_length)
> + if ((urb->actual_length < 2) || (urb->actual_length % 2))
> return;
I'll apply the whole series now. Thanks again for fixing up this driver!
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: f81232: fix some minor style issues
Fix some really minor coding-style issues.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/f81232.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 68016e7a86f7..972f5a5fe577 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -32,14 +32,14 @@ static const struct usb_device_id id_table[] = {
MODULE_DEVICE_TABLE(usb, id_table);
/* Maximum baudrate for F81232 */
-#define F81232_MAX_BAUDRATE115200
+#define F81232_MAX_BAUDRATE115200
/* USB Control EP parameter */
-#define F81232_REGISTER_REQUEST0xa0
+#define F81232_REGISTER_REQUEST0xa0
#define F81232_GET_REGISTER0xc0
#define F81232_SET_REGISTER0x40
-#define SERIAL_BASE_ADDRESS0x0120
+#define SERIAL_BASE_ADDRESS0x0120
#define RECEIVE_BUFFER_REGISTER(0x00 + SERIAL_BASE_ADDRESS)
#define INTERRUPT_ENABLE_REGISTER (0x01 + SERIAL_BASE_ADDRESS)
#define FIFO_CONTROL_REGISTER (0x02 + SERIAL_BASE_ADDRESS)
@@ -349,7 +349,8 @@ static void f81232_break_ctl(struct tty_struct *tty, int
break_state)
static void f81232_set_baudrate(struct usb_serial_port *port, speed_t baudrate)
{
u8 lcr;
- int divisor, status = 0;
+ int divisor;
+ int status = 0;
divisor = calc_baud_divisor(baudrate);
@@ -666,7 +667,7 @@ static struct usb_serial_driver f81232_device = {
.bulk_out_size =256,
.open = f81232_open,
.close =f81232_close,
- .dtr_rts = f81232_dtr_rts,
+ .dtr_rts = f81232_dtr_rts,
.carrier_raised = f81232_carrier_raised,
.ioctl =f81232_ioctl,
.break_ctl =f81232_break_ctl,
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: serial: fix re-ordering of tx data
From: Philip Oberstaller
When a single thread is sending out data over the gadget serial port,
gs_start_tx() will be called both from the sender context and from the
write completion. Since the port lock is released before the packet is
queued, the order in which the URBs are submitted is not guaranteed.
E.g.
sending thread completion (interrupt)
gs_write()
LOCK
gs_write_complete()
LOCK (wait)
gs_start_tx()
req1 = list_entry(pool->next)
UNLOCK
LOCK (acquired)
gs_start_tx()
req2 = list_entry(pool->next)
UNLOCK
usb_ep_queue(req2)
usb_ep_queue(req1)
I.e., req2 is submitted before req1 but it contains the data that
comes after req1.
To reproduce, use SMP with sending thread and completion pinned to
different CPUs, or use PREEMPT_RT, and add the following delay just
before the call to usb_ep_queue():
if (port->write_started > 0 && !list_empty(pool))
udelay(1000);
To work around this problem, make sure that only one thread is running
through the gs_start_tx() loop with an extra flag write_busy. Since
gs_start_tx() is always called with the port lock held, no further
synchronisation is needed. The original caller will continue through
the loop when the request was successfully submitted.
Signed-off-by: Philip Oberstaller
Signed-off-by: Arnout Vandecappelle (Essensium/Mind)
---
drivers/usb/gadget/function/u_serial.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index 89179ab..7ee05793 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -113,6 +113,7 @@ struct gs_port {
int write_allocated;
struct gs_buf port_write_buf;
wait_queue_head_t drain_wait; /* wait while writes drain */
+ boolwrite_busy;
/* REVISIT this state ... */
struct usb_cdc_line_coding port_line_coding;/* 8-N-1 etc */
@@ -363,7 +364,7 @@ __acquires(&port->port_lock)
int status = 0;
booldo_tty_wake = false;
- while (!list_empty(pool)) {
+ while (!port->write_busy && !list_empty(pool)) {
struct usb_request *req;
int len;
@@ -393,9 +394,11 @@ __acquires(&port->port_lock)
* NOTE that we may keep sending data for a while after
* the TTY closed (dev->ioport->port_tty is NULL).
*/
+ port->write_busy = true;
spin_unlock(&port->port_lock);
status = usb_ep_queue(in, req, GFP_ATOMIC);
spin_lock(&port->port_lock);
+ port->write_busy = false;
if (status) {
pr_debug("%s: %s %s err %d\n",
--
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
[PATCH] usb: pass flags parameter to gpiod_get functions
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Currently this parameter is made optional with the help of a cpp trick.
To allow dropping this hack convert callers to explictly pass a value
for flags.
Signed-off-by: Uwe Kleine-König
---
drivers/usb/gadget/udc/pxa27x_udc.c | 2 +-
drivers/usb/phy/phy-generic.c | 6 --
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/pxa27x_udc.c
b/drivers/usb/gadget/udc/pxa27x_udc.c
index 6a855fc9bd84..b0d4d1ef5aab 100644
--- a/drivers/usb/gadget/udc/pxa27x_udc.c
+++ b/drivers/usb/gadget/udc/pxa27x_udc.c
@@ -2434,7 +2434,7 @@ static int pxa_udc_probe(struct platform_device *pdev)
}
udc->udc_command = mach->udc_command;
} else {
- udc->gpiod = devm_gpiod_get(&pdev->dev, NULL);
+ udc->gpiod = devm_gpiod_get(&pdev->dev, NULL, GPIOD_ASIS);
}
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index 70be50b734b2..3a48c14c3163 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -220,11 +220,13 @@ int usb_phy_gen_create_phy(struct device *dev, struct
usb_phy_generic *nop,
clk_rate = 0;
needs_vcc = of_property_read_bool(node, "vcc-supply");
- nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset");
+ nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset",
+ GPIOD_ASIS);
err = PTR_ERR_OR_ZERO(nop->gpiod_reset);
if (!err) {
nop->gpiod_vbus = devm_gpiod_get_optional(dev,
-"vbus-detect");
+"vbus-detect",
+GPIOD_ASIS);
err = PTR_ERR_OR_ZERO(nop->gpiod_vbus);
}
} else if (pdata) {
--
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] usb: pass flags parameter to gpiod_get functions
On Fri, Mar 27, 2015 at 08:30:42PM +0100, Uwe Kleine-König wrote: > Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) > which appeared in v3.17-rc1, the gpiod_get* functions take an additional > parameter that allows to specify direction and initial value for output. > > Currently this parameter is made optional with the help of a cpp trick. > To allow dropping this hack convert callers to explictly pass a value > for flags. > > Signed-off-by: Uwe Kleine-König Looks good to me: Acked-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: pass flags parameter to gpiod_get functions
Felipe Balbi writes: > Looks good to me: > > Acked-by: Felipe Balbi Same for me: Acked-by: Robert Jarzmik Cheers. -- Robert -- 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: pass flags parameter to gpiod_get functions
On 03/28/2015 04:30 AM, Uwe Kleine-König wrote:
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Currently this parameter is made optional with the help of a cpp trick.
To allow dropping this hack convert callers to explictly pass a value
for flags.
Signed-off-by: Uwe Kleine-König
---
drivers/usb/gadget/udc/pxa27x_udc.c | 2 +-
drivers/usb/phy/phy-generic.c | 6 --
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/pxa27x_udc.c
b/drivers/usb/gadget/udc/pxa27x_udc.c
index 6a855fc9bd84..b0d4d1ef5aab 100644
--- a/drivers/usb/gadget/udc/pxa27x_udc.c
+++ b/drivers/usb/gadget/udc/pxa27x_udc.c
@@ -2434,7 +2434,7 @@ static int pxa_udc_probe(struct platform_device *pdev)
}
udc->udc_command = mach->udc_command;
} else {
- udc->gpiod = devm_gpiod_get(&pdev->dev, NULL);
+ udc->gpiod = devm_gpiod_get(&pdev->dev, NULL, GPIOD_ASIS);
}
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index 70be50b734b2..3a48c14c3163 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -220,11 +220,13 @@ int usb_phy_gen_create_phy(struct device *dev, struct
usb_phy_generic *nop,
clk_rate = 0;
needs_vcc = of_property_read_bool(node, "vcc-supply");
- nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset");
+ nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset",
+ GPIOD_ASIS);
err = PTR_ERR_OR_ZERO(nop->gpiod_reset);
if (!err) {
nop->gpiod_vbus = devm_gpiod_get_optional(dev,
-"vbus-detect");
+"vbus-detect",
+GPIOD_ASIS);
err = PTR_ERR_OR_ZERO(nop->gpiod_vbus);
Looks good, but can't we also merge the call to gpiod_direction to avoid
using GPIOD_ASIS? The golden rule is that a direction should not remain
in an unknown state after being requested.
This would also require adding a flag to the alternative calls to
gpio_request_one(). At first sight it seems to be doable, but I don't
know these drivers well enough to have an informed opinion.
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
--
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
