Re: Difference between run time and normal suspend
hi alan: 2015-01-06 8:39 GMT+08:00 vichy : > 2015-01-05 23:40 GMT+08:00 Alan Stern : >> On Mon, 5 Jan 2015, vichy wrote: >> >>> hi all: >>> after tracing and reading kernel usb source code about run time and >>> normal suspend. >>> 1. how could we check the rum time suspend is work on some device? >>> By plugging in devices and check whether >>> /sys/bus/usb/devices/.../power/ is empty or not? >> >> No. That directory will never be empty. >> >> You can check whether runtime suspend works by enabling it: >> >> echo auto >/sys/bus/usb/devices/.../power/control >> >> You can see whether the device has been suspended by looking at the >> runtime_status and runtime_suspended_time files in the .../power >> directory. >> I use keyboard, it should be default support runtime suspend, for testing runtime suspend like the attach log. insert related modules, change related suspend parameters. But I cannot see the keyboard go to suspend even I force autosuspend as 0. is there any other way to trigger runtime suspend immediately instead of waiting kernel judge it is idle for a while? appreciate your help in advance, #> lsmod Not tainted usbhid 21486 0 - Live 0xbe4a3000 hid_generic 954 0 - Live 0xbe49f000 hid 72898 2 usbhid,hid_generic, Live 0xbe487000 usb_storage 43962 0 - Live 0xbe473000 ehci_hcd 60249 0 - Live 0xbe45e000 xhci_hcd 92188 0 - Live 0xbe441000 usbcore 182850 4 usbhid,usb_storage,ehci_hcd,xhci_hcd, Live 0xbe404000 usb_common 1822 1 usbcore, Live 0xbe40 #> #> [0-57.0178] usb 6-1: new low-speed USB device number 3 using platform-ehci [0-57.1687] usb 6-1: New USB device found, idVendor=04ca, idProduct=002f [0-57.1752] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [0-57.1821] usb 6-1: Product: USB Multimedia Keyboard [0-57.1869] usb 6-1: Manufacturer: Lite-On Technology Corp. [0-57.2035] input: Lite-On Technology Corp. USB Multimedia Keyboard as /devices/fc1a.ehci/usb6/6-1/6-1:1.0/input/input0 [0-57.2152] hid-generic 0003:04CA:002F.0001: input: USB HID v1.10 Keyboard [Lite-On Technology Corp. USB Multimedia Keyboard] on usb-platform-1/input0 [0-57.2409] input: Lite-On Technology Corp. USB Multimedia Keyboard as /devices/fc1a.ehci/usb6/6-1/6-1:1.1/input/input1 [0-57.2522] hid-generic 0003:04CA:002F.0002: input: USB HID v1.10 Device [Lite-On Technology Corp. USB Multimedia Keyboard] on usb-platform-1/input1 #> #> cat /sys/bus/usb/devices/6-1/power/control on #> echo auto > /sys/bus/usb/devices/6-1/power/control #> echo 0 > /sys/bus/usb/devices/6-1/power/autosuspend #> cat /sys/bus/usb/devices/6-1/power/ active_duration runtime_active_time wakeup_count autosuspend runtime_status wakeup_expire_count autosuspend_delay_msruntime_suspended_time wakeup_last_time_ms connected_duration wakeup wakeup_max_time_ms control wakeup_abort_count wakeup_total_time_ms level wakeup_active persist wakeup_active_count #> cat /sys/bus/usb/devices/6-1/power/runtime_status active #> cat /sys/bus/usb/devices/6-1/power/runtime_suspended_time 0 #>
Re: qcserial: AT unsolicited response codes missing with Sierra Wireless MC7304
On Mon, Jan 05, 2015 at 10:12:33PM +0100, Reinhard Speyerer wrote:
> Johan Hovold wrote:
>
> > On Sat, Dec 27, 2014 at 10:54:09PM +0100, Reinhard Speyerer wrote:
> > > Reinhard Speyerer wrote:
> > > > Johan Hovold wrote:
> > > > > On Sun, Dec 21, 2014 at 11:25:45PM +0100, Reinhard Speyerer wrote:
> >
> > > With the qcserial.c patch below (for Linux kernel 3.16.3) I was able to
> > > verify that adding the send_setup code fixes the missing URCs for the
> > > MC7304. To avoid potential side effects for other ports of the MC7304
> > > the send_setup code is only used for the AT port (USB interface 3).
> >
> > Thanks for verifying this.
> >
> > After looking at this some more, and depending on whether you can find
> > out if the vendor driver sends these requests for all devices, I think
> > your original proposal of simply moving this device over to option might
> > be the best solution after all.
>
> Sorry,
> I don't know whether the vendor GobiSerial driver does this.
Ok, let's move the PID to option and if it turns out that more of these
devices require the modem-control signals (e.g. with more recent
firmware) we can consider moving it back after adding such support to
qcserial.
Bjørn, do you see any problems with this? Are there more interface
layouts for these devices out there perhaps (making options blacklisting
a bad fit)?
> > Perhaps you can use USB_DEVICE_AND_INTERFACE_INFO so you don't have to
> > blacklist so many interfaces explicitly (e.g. the AUDIO interfaces)?
> >
> Since the DM/DIAG interface uses bInterfaceSubClass/bInterfaceProtocol
> values which differ from the values for the NMEA and AT interfaces this
> seems to require two USB_DEVICE_AND_INTERFACE_INFO entries and might no
> longer work if the vendor decides to uses different value e.g. with newer
> firmware versions.
>
> My preference would be to use USB_DEVICE_INTERFACE_CLASS with 0xff instead:
>
> --- drivers/usb/serial/option.c-std 2014-08-04 00:25:02.0 +0200
> +++ drivers/usb/serial/option.c 2015-01-05 17:27:32.581915787 +0100
> @@ -236,2 +236,4 @@
>
> +#define SIERRA_VENDOR_ID 0x1199
> +
> #define CMOTECH_VENDOR_ID0x16d8
> @@ -503,3 +505,3 @@
>
> -#define MAX_BL_NUM 8
> +#define MAX_BL_NUM 11
> struct option_blacklist_info {
> @@ -579,2 +581,7 @@
>
> +static const struct option_blacklist_info sierra_mc73xx_blacklist = {
> + .sendsetup = BIT(0) | BIT(2),
> + .reserved = BIT(8) | BIT(10) | BIT(11),
> +};
> +
> static const struct usb_device_id option_ids[] = {
> @@ -1075,2 +1082,4 @@
> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */
> + { USB_DEVICE_INTERFACE_CLASS(SIERRA_VENDOR_ID, 0x68c0, 0xff),
> + .driver_info = (kernel_ulong_t)&sierra_mc73xx_blacklist }, /* MC73xx
> */
> { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
Looks good. Care to submit this as a proper patch (including removing
the PID from qcserial) so I can apply it?
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] renesas_usbhs: fix platform init error message
Hi Greet-san,
>
> Hi Shimoda-san,
>
> On Wed, Dec 24, 2014 at 11:02 AM, yoshihiro shimoda
> wrote:
> >> > > Er, OK. Could you update MAINTAINERS?
> >> > there is no entry for renesas driver in MAINTAINERS.
> >> > Shimoda-san, care to send a patch adding yourself or Morimoto-san as
> >> > maintainers for Renesas driver and pointing to my tree in kernel.org
> >> > ?
>
> > By the way, about a renesas_usbhs maintainer, I don't know clearly.
> > If I do as a renesas_usbhs maintainer:
> > - what should I do as the maintainer?
> > - I think I should check patches of renesas_usbhs
> > - And, do I just return ACK or NACK to the patches?
>
> As a maintainer, you review all patches for renesas_usbhs, and of these
> patches
> will have to go through you.
> There are three ways to achieve that:
> 1. You collect all accepted patches, and forward them to GregKH with your
> Signed-off-by added,
> 2. You collect all accepted ls -lpatches, publish them in a git tree, and
> ask GregKH to pull a branch or tag from your git tree,
> 3. You ack all accepted patches, so GregKH knows which patches to apply.
>
> Which way to choose depends on the volume of patches.
Thank you very much for the reply!
I understood what a maintainer should do.
So, I will submit a patch for MAINTAINERS file.
Best regards,
Yoshihiro Shimoda
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: qcserial: AT unsolicited response codes missing with Sierra Wireless MC7304
Johan Hovold writes:
> Ok, let's move the PID to option and if it turns out that more of these
> devices require the modem-control signals (e.g. with more recent
> firmware) we can consider moving it back after adding such support to
> qcserial.
>
> Bjørn, do you see any problems with this? Are there more interface
> layouts for these devices out there perhaps (making options blacklisting
> a bad fit)?
No, I don't see any problem. It seems like the reasonable thing to do.
I would have added these devices to the option driver in the first place
had I known about the setup requirements. Sorry for not catching that
earlier. And thanks to Reinhard for tracking this down.
There are plenty of different interface layouts for these devices, but
Sierra Wireless use consistent interface numbering for different
functions, so the blacklist_info should work fine regardless.
Note however that these devices also have multiple PID identities (and
possibly also different VIDs?). The other identities may or may not have
similar issues with the qcserial driver. I don't know. But some of these
identities are shared with other devices, which complicates matters a
bit.
>> @@ -503,3 +505,3 @@
>>
>> -#define MAX_BL_NUM 8
>> +#define MAX_BL_NUM 11
>> struct option_blacklist_info {
Completely unrelated question following... This hunk made me look at the
implementation. For the first time :-)
I wonder why the blacklist bit test is open coded this way. Wouldn't it
make more sense to drop the "loop over MAX_BL_NUM interfaces" and just
use test_bit() instead?
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net] r8152: support ndo_features_check
Support ndo_features_check to avoid:
- the transport offset is more than the hw limitation when using hw checksum.
- the skb->len of a GSO packet is more than the limitation.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2d1c77e..57ec23e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1897,6 +1897,22 @@ static void _rtl8152_set_rx_mode(struct net_device
*netdev)
netif_wake_queue(netdev);
}
+static netdev_features_t
+rtl8152_features_check(struct sk_buff *skb, struct net_device *dev,
+ netdev_features_t features)
+{
+ u32 mss = skb_shinfo(skb)->gso_size;
+ int max_offset = mss ? GTTCPHO_MAX : TCPHO_MAX;
+ int offset = skb_transport_offset(skb);
+
+ if ((mss || skb->ip_summed == CHECKSUM_PARTIAL) && offset > max_offset)
+ features &= ~(NETIF_F_ALL_CSUM | NETIF_F_GSO_MASK);
+ else if ((skb->len + sizeof(struct tx_desc)) > agg_buf_sz)
+ features &= ~NETIF_F_GSO_MASK;
+
+ return features;
+}
+
static netdev_tx_t rtl8152_start_xmit(struct sk_buff *skb,
struct net_device *netdev)
{
@@ -3706,6 +3722,7 @@ static const struct net_device_ops rtl8152_netdev_ops = {
.ndo_set_mac_address= rtl8152_set_mac_address,
.ndo_change_mtu = rtl8152_change_mtu,
.ndo_validate_addr = eth_validate_addr,
+ .ndo_features_check = rtl8152_features_check,
};
static void r8152b_get_version(struct r8152 *tp)
--
2.1.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: qcserial: AT unsolicited response codes missing with Sierra Wireless MC7304
On Tue, Jan 06, 2015 at 09:58:40AM +0100, Bjørn Mork wrote:
> Johan Hovold writes:
>
> > Ok, let's move the PID to option and if it turns out that more of these
> > devices require the modem-control signals (e.g. with more recent
> > firmware) we can consider moving it back after adding such support to
> > qcserial.
> >
> > Bjørn, do you see any problems with this? Are there more interface
> > layouts for these devices out there perhaps (making options blacklisting
> > a bad fit)?
>
> No, I don't see any problem. It seems like the reasonable thing to do.
> I would have added these devices to the option driver in the first place
> had I known about the setup requirements. Sorry for not catching that
> earlier. And thanks to Reinhard for tracking this down.
>
> There are plenty of different interface layouts for these devices, but
> Sierra Wireless use consistent interface numbering for different
> functions, so the blacklist_info should work fine regardless.
>
> Note however that these devices also have multiple PID identities (and
> possibly also different VIDs?). The other identities may or may not have
> similar issues with the qcserial driver. I don't know. But some of these
> identities are shared with other devices, which complicates matters a
> bit.
Yeah, this feels a bit like whack-a-mole.
Did anyone have a look at these "vendor" drivers and how they do it? (And
why aren't the vendors upstreaming...).
> >> @@ -503,3 +505,3 @@
> >>
> >> -#define MAX_BL_NUM 8
> >> +#define MAX_BL_NUM 11
> >> struct option_blacklist_info {
>
> Completely unrelated question following... This hunk made me look at the
> implementation. For the first time :-)
>
> I wonder why the blacklist bit test is open coded this way. Wouldn't it
> make more sense to drop the "loop over MAX_BL_NUM interfaces" and just
> use test_bit() instead?
Absolutely, the current implementation is completely retarded. That's
why I fixed it last Sunday when I looked at it. ;)
http://marc.info/?l=linux-usb&m=142039356820488&w=2
I figured I'd apply Reinhard's patch with a stable tag first, though.
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: phy: Restore deferred probing path
On Mon, Jan 05, 2015 at 12:33:51PM -0700, Stephen Warren wrote:
> On 12/23/2014 11:36 AM, Felipe Balbi wrote:
> >On Thu, Dec 04, 2014 at 01:06:07PM +0100, Thierry Reding wrote:
> >>From: Thierry Reding
> >>
> >>Commit 1290a958d48e ("usb: phy: propagate __of_usb_find_phy()'s error on
> >>failure") broke platforms that rely on deferred probing to order probing
> >>of PHY and host controller drivers. The reason is that the commit simply
> >>propagates errors from __of_usb_find_phy(), which returns -ENODEV if no
> >>PHY has been registered yet for a given device tree node. The only case
> >>in which -EPROBE_DEFER would now be returned is if try_module_get() did
> >>fail, which does not make sense.
> >>
> >>The correct thing to do is to return -EPROBE_DEFER if a PHY hasn't been
> >>registered yet. The only condition under which it makes sense to return
> >>-ENODEV is if the device tree node representing the PHY has been
> >>disabled (via the status property) because in that case the PHY will
> >>never be registered.
> >>
> >>This patch addresses the problem by making __of_usb_find_phy() return an
> >>appropriate error code while keeping in line with the above-mentioned
> >>commit to propagate error codes rather than overwriting them. At the
> >>same time the check for a valid PHY is decoupled from the check for the
> >>try_module_get() call and a separate error code is returned if the
> >>latter fails.
> >>
> >>Signed-off-by: Thierry Reding
> >
> >you forgot to add the magic "Fixes: foo bar" here, I'll add it this
> >time, but I've already sent my -rc2 pull request, so this will only show
> >up on -rc3.
>
> Presumably also add the following, since the patch fixes a regression in a
> previous kernel release:
>
> Cc: stable # v3.18
>
> ?
The offending commit was only merged in v3.19-rc1. That's also the
reason why I didn't deem it necessary to include the Fixes: line. Given
that the patch was posted prior to the merge window opening and that it
fixes a regression I had assumed it would be merged in the same pull-
request as the commit causing the regression.
Thierry
pgpZ8qt7I9bZj.pgp
Description: PGP signature
[patch] usb: gadget: gadgetfs: fix an oops in ep_write()
We try to free an ERR_PTR on this error path.
Fixes: b44be2462dbe ('usb: gadget: gadgetfs: Free memory allocated by
memdup_user()')
Signed-off-by: Dan Carpenter
diff --git a/drivers/usb/gadget/legacy/inode.c
b/drivers/usb/gadget/legacy/inode.c
index 0804861..db49ec4 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -441,6 +441,7 @@ ep_write (struct file *fd, const char __user *buf, size_t
len, loff_t *ptr)
kbuf = memdup_user(buf, len);
if (IS_ERR(kbuf)) {
value = PTR_ERR(kbuf);
+ kbuf = NULL;
goto free1;
}
--
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: kernel panic with USB3+DVB+ARM
Hi Greg Am 06.01.2015 um 02:54 schrieb Greg KH: > > Is that where the kernel panics show the problem happens? Without them, > there's nothing we can do to help out except randomly guess, sorry. well. at least xhci is contained in the call stack: > [] (crc32_be) from [] (dvb_dmx_crc32+0x10/0x18 [dvb_core]) > [] (dvb_dmx_crc32 [dvb_core]) from [] > (dvb_dmx_swfilter_section_copy_dump+0x254/0x268 [dvb_core]) > [] (dvb_dmx_swfilter_section_copy_dump [dvb_core]) from > [] (dvb_dmx_swfilter_packet+0x45c/0x564 [dvb_core]) > [] (dvb_dmx_swfilter_packet [dvb_core]) from [] > (dvb_dmx_swfilter+0xf4/0x164 [dvb_core]) > [] (dvb_dmx_swfilter [dvb_core]) from [] > (usb_urb_complete+0xbc/0xe4 [dvb_usb]) > [] (usb_urb_complete [dvb_usb]) from [] > (__usb_hcd_giveback_urb+0x5c/0xe8) > [] (__usb_hcd_giveback_urb) from [] > (xhci_irq+0x8d8/0x1e08) > [] (xhci_irq) from [] (handle_irq_event_percpu+0x78/0x140) > [] (handle_irq_event_percpu) from [] > (handle_irq_event+0x28/0x38) > [] (handle_irq_event) from [] > (handle_simple_irq+0x64/0xa8) > [] (handle_simple_irq) from [] > (generic_handle_irq+0x2c/0x3c) > [] (generic_handle_irq) from [] (handle_IRQ+0x38/0x84) > [] (handle_IRQ) from [] > (armada_370_xp_handle_msi_irq+0x9c/0xa0) > [] (armada_370_xp_handle_msi_irq) from [] > (armada_370_xp_handle_irq+0x5c/0x60) > [] (armada_370_xp_handle_irq) from [] > (__irq_svc+0x40/0x54) It's always the same stack, but different errors: kernelpanic0.log: Unhandled prefetch abort: unknown 25 (0x409) at 0xc02fc948 kernelpanic0.log: Internal error: : 409 [#1] ARM kernelpanic1.log: Unhandled prefetch abort: unknown 25 (0x409) at 0xc02fc948 kernelpanic1.log: Internal error: : 409 [#1] ARM kernelpanic2.log: Internal error: Oops: 815 [#1] ARM kernelpanic3.log: Unhandled prefetch abort: unknown 25 (0x409) at 0xc0301228 kernelpanic3.log: Internal error: : 409 [#1] ARM kernelpanic4.log: Unhandled prefetch abort: unknown 0 (0x000) at 0xc0301228 kernelpanic4.log: Internal error: : 0 [#1] ARM I added a printk to dvb_dmx_crc32() (see dvb.log). This probably introduced more problems, because irq code has to be fast? During recording through USB2 this code made the system not crash but it wasn't able to answer any request (SSH, HTTP, login from serial console ...) Is this info useful? I attached only one of the kernel panic logs. If you would like to see the others, please tell me. I am not sure if the dvb.log tells something of worth at all. Jan [ 57.646235] dvb_dmx_crc32(dvb_demux_feed e0d4b13c, src: e0d4b154, len 18 [ 57.688218] dvb_dmx_crc32(dvb_demux_feed e0d4d3b4, src: e0d4d3cc, len 97 [ 57.695163] dvb_dmx_crc32(dvb_demux_feed e0d4a000, src: e0d4a018, len 28 [ 57.702105] xhci_hcd :01:00.0: ERROR Unknown event condition, HC probably busted [ 57.709920] xhci_hcd :01:00.0: ERROR Unknown event condition, HC probably busted [ 57.717924] xhci_hcd :01:00.0: ERROR Unknown event condition, HC probably busted [ 57.725728] xhci_hcd :01:00.0: ERROR Unknown event condition, HC probably busted [ 57.748820] dvb_dmx_crc32(dvb_demux_feed e0d4d3b4, src: e0d4d3cc, len 97 [ 57.755715] dvb_dmx_crc32(dvb_demux_feed e0d4a000, src: e0d4a018, len 28 [ 57.762668] xhci_hcd :01:00.0: ERROR Unknown event condition, HC probably busted [ 57.770454] xhci_hcd :01:00.0: ERROR Unknown event condition, HC probably busted [ 57.782462] dvb_dmx_crc32(dvb_demux_feed e0d53b1c, src: e0d53b34, len 95 [ 57.789220] dvb_dmx_crc32(dvb_demux_feed e0d529e0, src: e0d529f8, len 95 [ 57.795992] dvb_dmx_crc32(dvb_demux_feed e0d518a4, src: e0d518bc, len 95 [ 57.809074] dvb_dmx_crc32(dvb_demux_feed e0d4d3b4, src: e0d4d3cc, len 97 [ 57.815970] dvb_dmx_crc32(dvb_demux_feed e0d4a000, src: e0d4a018, len 28 [ 57.822902] xhci_hcd :01:00.0: ERROR Unknown event condition, HC probably busted [ 57.830687] xhci_hcd :01:00.0: ERROR Unknown event condition, HC probably busted [ 57.839677] xhci_hcd :01:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13 [ 57.850079] xhci_hcd :01:00.0: Looking for event-dma 1e5e2250 trb-start 1e5e22c0 trb-end 1e5e22c0 seg-start 1e5e2000 seg-end 1e5e23f0 [ 57.865968] xhci_hcd :01:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13 [ 57.876364] xhci_hcd :01:00.0: Looking for event-dma 1e5e2260 trb-start 1e5e22c0 trb-end 1e5e22c0 seg-start 1e5e2000 seg-end 1e5e23f0 [ 57.892252] xhci_hcd :01:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13 [ 57.902647] xhci_hcd :01:00.0: Looking for event-dma 1e5e2270 trb-start 1e5e22c0 trb-end 1e5e22c0 seg-start 1e5e2000 seg-end 1e5e23f0 [ 57.918534] xhci_hcd :01:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 1 [ 57.928843] xhci_hcd :01:00.0: Looking for ev
Re: Difference between run time and normal suspend
hi all: 2015-01-06 16:06 GMT+08:00 vichy : > hi alan: > > 2015-01-06 8:39 GMT+08:00 vichy : >> 2015-01-05 23:40 GMT+08:00 Alan Stern : >>> On Mon, 5 Jan 2015, vichy wrote: >>> hi all: after tracing and reading kernel usb source code about run time and normal suspend. 1. how could we check the rum time suspend is work on some device? By plugging in devices and check whether /sys/bus/usb/devices/.../power/ is empty or not? >>> >>> No. That directory will never be empty. >>> >>> You can check whether runtime suspend works by enabling it: >>> >>> echo auto >/sys/bus/usb/devices/.../power/control >>> >>> You can see whether the device has been suspended by looking at the >>> runtime_status and runtime_suspended_time files in the .../power >>> directory. >>> > I use keyboard, it should be default support runtime suspend, for > testing runtime suspend like the attach log. > insert related modules, change related suspend parameters. > > But I cannot see the keyboard go to suspend even I force autosuspend as 0. > is there any other way to trigger runtime suspend immediately instead > of waiting kernel judge it is idle for a while? > I test the same keyboard on the NB is also not seeing autosuspend work. the kernel version of NB is 3.18 and my embedded system is 3.10 (I also attach usb descriptor of the keyboard I used in the mail) thanks for your help, liteon.keyboard.desc.txt.tar.bz2 Description: BZip2 compressed data
[PATCH 1/2 resend v2] USB: host: Remove hard-coded octeon platform information for ehci/ohci
Instead rely on device tree information for ehci and ohci.
This was suggested with
http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=1401358203-60225-4-git-send-email-alex.smith%40imgtec.com
"The device tree will *always* have correct ehci/ohci clock
configuration, so use it. This allows us to remove a big chunk of
platform configuration code from octeon-platform.c."
More or less I rebased that patch on Alan's work to remove ehci-octeon
and ohci-octeon drivers.
Cc: David Daney
Cc: Alex Smith
Cc: Alan Stern
Signed-off-by: Andreas Herrmann
Acked-by: Ralf Baechle
Tested-by: Aaro Koskinen
---
arch/mips/cavium-octeon/octeon-platform.c | 148 -
drivers/usb/host/ehci-platform.c |1 +
drivers/usb/host/ohci-platform.c |1 +
3 files changed, 64 insertions(+), 86 deletions(-)
diff --git a/arch/mips/cavium-octeon/octeon-platform.c
b/arch/mips/cavium-octeon/octeon-platform.c
index b67ddf0..eea60b6 100644
--- a/arch/mips/cavium-octeon/octeon-platform.c
+++ b/arch/mips/cavium-octeon/octeon-platform.c
@@ -77,7 +77,7 @@ static DEFINE_MUTEX(octeon2_usb_clocks_mutex);
static int octeon2_usb_clock_start_cnt;
-static void octeon2_usb_clocks_start(void)
+static void octeon2_usb_clocks_start(struct device *dev)
{
u64 div;
union cvmx_uctlx_if_ena if_ena;
@@ -86,6 +86,8 @@ static void octeon2_usb_clocks_start(void)
union cvmx_uctlx_uphy_portx_ctl_status port_ctl_status;
int i;
unsigned long io_clk_64_to_ns;
+ u32 clock_rate = 1200;
+ bool is_crystal_clock = false;
mutex_lock(&octeon2_usb_clocks_mutex);
@@ -96,6 +98,28 @@ static void octeon2_usb_clocks_start(void)
io_clk_64_to_ns = 640ull / octeon_get_io_clock_rate();
+ if (dev->of_node) {
+ struct device_node *uctl_node;
+ const char *clock_type;
+
+ uctl_node = of_get_parent(dev->of_node);
+ if (!uctl_node) {
+ dev_err(dev, "No UCTL device node\n");
+ goto exit;
+ }
+ i = of_property_read_u32(uctl_node,
+"refclk-frequency", &clock_rate);
+ if (i) {
+ dev_err(dev, "No UCTL \"refclk-frequency\"\n");
+ goto exit;
+ }
+ i = of_property_read_string(uctl_node,
+ "refclk-type", &clock_type);
+
+ if (!i && strcmp("crystal", clock_type) == 0)
+ is_crystal_clock = true;
+ }
+
/*
* Step 1: Wait for voltages stable. That surely happened
* before starting the kernel.
@@ -126,9 +150,22 @@ static void octeon2_usb_clocks_start(void)
cvmx_write_csr(CVMX_UCTLX_CLK_RST_CTL(0), clk_rst_ctl.u64);
/* 3b */
- /* 12MHz crystal. */
- clk_rst_ctl.s.p_refclk_sel = 0;
- clk_rst_ctl.s.p_refclk_div = 0;
+ clk_rst_ctl.s.p_refclk_sel = is_crystal_clock ? 0 : 1;
+ switch (clock_rate) {
+ default:
+ pr_err("Invalid UCTL clock rate of %u, using 1200
instead\n",
+ clock_rate);
+ /* Fall through */
+ case 1200:
+ clk_rst_ctl.s.p_refclk_div = 0;
+ break;
+ case 2400:
+ clk_rst_ctl.s.p_refclk_div = 1;
+ break;
+ case 4800:
+ clk_rst_ctl.s.p_refclk_div = 2;
+ break;
+ }
cvmx_write_csr(CVMX_UCTLX_CLK_RST_CTL(0), clk_rst_ctl.u64);
/* 3c */
@@ -259,7 +296,7 @@ static void octeon2_usb_clocks_stop(void)
static int octeon_ehci_power_on(struct platform_device *pdev)
{
- octeon2_usb_clocks_start();
+ octeon2_usb_clocks_start(&pdev->dev);
return 0;
}
@@ -277,11 +314,11 @@ static struct usb_ehci_pdata octeon_ehci_pdata = {
.power_off = octeon_ehci_power_off,
};
-static void __init octeon_ehci_hw_start(void)
+static void __init octeon_ehci_hw_start(struct device *dev)
{
union cvmx_uctlx_ehci_ctl ehci_ctl;
- octeon2_usb_clocks_start();
+ octeon2_usb_clocks_start(dev);
ehci_ctl.u64 = cvmx_read_csr(CVMX_UCTLX_EHCI_CTL(0));
/* Use 64-bit addressing. */
@@ -299,59 +336,28 @@ static u64 octeon_ehci_dma_mask = DMA_BIT_MASK(64);
static int __init octeon_ehci_device_init(void)
{
struct platform_device *pd;
+ struct device_node *ehci_node;
int ret = 0;
- struct resource usb_resources[] = {
- {
- .flags = IORESOURCE_MEM,
- }, {
- .flags = IORESOURCE_IRQ,
- }
- };
-
- /* Only Octeon2 has ehci/ohci */
- if (!OCTEON_IS_MODEL(OCTEON_CN63XX))
+ ehci_node = of_find_node_by_name(NULL, "ehci");
+ if (!ehci_node)
return 0;
[PATCH 2/2 resend v2] USB: host: Introduce flag to enable use of 64-bit dma_mask for ehci-platform
ehci-octeon driver used a 64-bit dma_mask. With removal of ehci-octeon
and usage of ehci-platform ehci dma_mask is now limited to 32 bits
(coerced in ehci_platform_probe).
Provide a flag in ehci platform data to allow use of 64 bits for
dma_mask.
Cc: David Daney
Cc: Alex Smith
Cc: Alan Stern
Signed-off-by: Andreas Herrmann
Tested-by: Aaro Koskinen
---
arch/mips/cavium-octeon/octeon-platform.c |4 +---
drivers/usb/host/ehci-platform.c |3 ++-
include/linux/usb/ehci_pdriver.h |1 +
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/mips/cavium-octeon/octeon-platform.c
b/arch/mips/cavium-octeon/octeon-platform.c
index eea60b6..12410a2 100644
--- a/arch/mips/cavium-octeon/octeon-platform.c
+++ b/arch/mips/cavium-octeon/octeon-platform.c
@@ -310,6 +310,7 @@ static struct usb_ehci_pdata octeon_ehci_pdata = {
#ifdef __BIG_ENDIAN
.big_endian_mmio= 1,
#endif
+ .dma_mask_64= 1,
.power_on = octeon_ehci_power_on,
.power_off = octeon_ehci_power_off,
};
@@ -331,8 +332,6 @@ static void __init octeon_ehci_hw_start(struct device *dev)
octeon2_usb_clocks_stop();
}
-static u64 octeon_ehci_dma_mask = DMA_BIT_MASK(64);
-
static int __init octeon_ehci_device_init(void)
{
struct platform_device *pd;
@@ -347,7 +346,6 @@ static int __init octeon_ehci_device_init(void)
if (!pd)
return 0;
- pd->dev.dma_mask = &octeon_ehci_dma_mask;
pd->dev.platform_data = &octeon_ehci_pdata;
octeon_ehci_hw_start(&pd->dev);
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 29b244c..75631b9 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -155,7 +155,8 @@ static int ehci_platform_probe(struct platform_device *dev)
if (!pdata)
pdata = &ehci_platform_defaults;
- err = dma_coerce_mask_and_coherent(&dev->dev, DMA_BIT_MASK(32));
+ err = dma_coerce_mask_and_coherent(&dev->dev,
+ pdata->dma_mask_64 ? DMA_BIT_MASK(64) : DMA_BIT_MASK(32));
if (err)
return err;
diff --git a/include/linux/usb/ehci_pdriver.h b/include/linux/usb/ehci_pdriver.h
index 7eb4dcd..f69529e 100644
--- a/include/linux/usb/ehci_pdriver.h
+++ b/include/linux/usb/ehci_pdriver.h
@@ -45,6 +45,7 @@ struct usb_ehci_pdata {
unsignedbig_endian_desc:1;
unsignedbig_endian_mmio:1;
unsignedno_io_watchdog:1;
+ unsigneddma_mask_64:1;
/* Turn on all power and clocks */
int (*power_on)(struct platform_device *pdev);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 resend v2] USB: host: Misc patches to remove hard-coded octeon platform information
On Tue, Jan 06, 2015 at 01:46:44PM +0100, Andreas Herrmann wrote: > This is a re-submission of patches 2 and 3 from > http://marc.info/?i=1415914590-31647-1-git-send-email-andreas.herrm...@caviumnetworks.com > (Only patch 1/3 made it into usb-next and meanwhile is in mainline.) > > Please apply. > > > Thanks, > > Andreas > > PS: It's v2 as with last submission I hit the merge window. > Patches are rebased to v3.19-rc2. > Only change is usage of a permanent link for the mail referenced > in commit message of patch 2/2. In fact I meant commit message of patch 1 of 2. Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2 resend v2] USB: host: Misc patches to remove hard-coded octeon platform information
This is a re-submission of patches 2 and 3 from http://marc.info/?i=1415914590-31647-1-git-send-email-andreas.herrm...@caviumnetworks.com (Only patch 1/3 made it into usb-next and meanwhile is in mainline.) Please apply. Thanks, Andreas PS: It's v2 as with last submission I hit the merge window. Patches are rebased to v3.19-rc2. Only change is usage of a permanent link for the mail referenced in commit message of patch 2/2. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] snd-usb-audio: Add support for Akai MPC Element MIDI controller
Paul Bonser wrote:
> This device incorrectly reports its bInterfaceClass as 255, when it
> should really be 1 (USB_CLASS_AUDIO).
>
> +++ b/sound/usb/quirks-table.h
> +{
> + /* Akai MPC Element */
> + USB_DEVICE(0x09e8, 0x0021),
> + .bInterfaceClass = USB_CLASS_AUDIO,
> +},
This is not a correct usb_device_id entry.
Show the output of "lsusb -v" for this device.
And read Documentation/SubmittingPatches.
Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] usb: atmel_usba_udc: Rework errata handling
Hello, Here is a set of patches porting existing at91sam9rl erratum handling to DT and adding new code to handle at91sam9g45/9x5 erratum. It also adds several compatible strings to differentiate those errata. These patches should be backported to 3.17 and 3.18 stable releases but they do not apply cleanly on those stable branches. I'll send a backport of this series once it is merged in mainline. Regards, Boris Changes since v1: - cache INT_ENB value to speedup INT_ENB read operations Boris Brezillon (5): usb: atmel_usba_udc: Rework at91sam9rl errata handling usb: atmel_usba_udc: Add at91sam9g45 and at91sam9x5 errata handling ARM: at91/dt: update udc compatible strings usb: atmel_usba_udc: Mask status with enabled irqs usb: gadget: atmel_usba: Cache INT_ENB register value .../devicetree/bindings/usb/atmel-usb.txt | 5 +- arch/arm/boot/dts/at91sam9g45.dtsi | 2 +- arch/arm/boot/dts/at91sam9x5.dtsi | 2 +- arch/arm/boot/dts/sama5d3.dtsi | 2 +- arch/arm/boot/dts/sama5d4.dtsi | 2 +- drivers/usb/gadget/udc/atmel_usba_udc.c| 146 + drivers/usb/gadget/udc/atmel_usba_udc.h| 9 ++ 7 files changed, 111 insertions(+), 57 deletions(-) -- 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 5/5] usb: gadget: atmel_usba: Cache INT_ENB register value
Cache INT_ENB register value in order to avoid uncached iomem access, and
thus improve access time to INT_ENB value.
Signed-off-by: Boris Brezillon
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 52 ++---
drivers/usb/gadget/udc/atmel_usba_udc.h | 2 ++
2 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index bc3a532..6dfe17b 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -316,6 +316,17 @@ static inline void usba_cleanup_debugfs(struct usba_udc
*udc)
}
#endif
+static inline u32 usba_int_enb_get(struct usba_udc *udc)
+{
+ return udc->int_enb_cache;
+}
+
+static inline void usba_int_enb_set(struct usba_udc *udc, u32 val)
+{
+ usba_writel(udc, INT_ENB, val);
+ udc->int_enb_cache = val;
+}
+
static int vbus_is_present(struct usba_udc *udc)
{
if (gpio_is_valid(udc->vbus_pin))
@@ -597,16 +608,14 @@ usba_ep_enable(struct usb_ep *_ep, const struct
usb_endpoint_descriptor *desc)
if (ep->can_dma) {
u32 ctrl;
- usba_writel(udc, INT_ENB,
- (usba_readl(udc, INT_ENB)
- | USBA_BF(EPT_INT, 1 << ep->index)
- | USBA_BF(DMA_INT, 1 << ep->index)));
+ usba_int_enb_set(udc, usba_int_enb_get(udc) |
+ USBA_BF(EPT_INT, 1 << ep->index) |
+ USBA_BF(DMA_INT, 1 << ep->index));
ctrl = USBA_AUTO_VALID | USBA_INTDIS_DMA;
usba_ep_writel(ep, CTL_ENB, ctrl);
} else {
- usba_writel(udc, INT_ENB,
- (usba_readl(udc, INT_ENB)
- | USBA_BF(EPT_INT, 1 << ep->index)));
+ usba_int_enb_set(udc, usba_int_enb_get(udc) |
+ USBA_BF(EPT_INT, 1 << ep->index));
}
spin_unlock_irqrestore(&udc->lock, flags);
@@ -614,7 +623,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct
usb_endpoint_descriptor *desc)
DBG(DBG_HW, "EPT_CFG%d after init: %#08lx\n", ep->index,
(unsigned long)usba_ep_readl(ep, CFG));
DBG(DBG_HW, "INT_ENB after init: %#08lx\n",
- (unsigned long)usba_readl(udc, INT_ENB));
+ (unsigned long)usba_int_enb_get(udc));
return 0;
}
@@ -650,9 +659,8 @@ static int usba_ep_disable(struct usb_ep *_ep)
usba_dma_readl(ep, STATUS);
}
usba_ep_writel(ep, CTL_DIS, USBA_EPT_ENABLE);
- usba_writel(udc, INT_ENB,
- usba_readl(udc, INT_ENB)
- & ~USBA_BF(EPT_INT, 1 << ep->index));
+ usba_int_enb_set(udc, usba_int_enb_get(udc) &
+ ~USBA_BF(EPT_INT, 1 << ep->index));
request_complete_list(ep, &req_list, -ESHUTDOWN);
@@ -1606,20 +1614,20 @@ static void usba_dma_irq(struct usba_udc *udc, struct
usba_ep *ep)
static irqreturn_t usba_udc_irq(int irq, void *devid)
{
struct usba_udc *udc = devid;
- u32 status;
+ u32 status, int_enb;
u32 dma_status;
u32 ep_status;
spin_lock(&udc->lock);
- status = usba_readl(udc, INT_STA) & usba_readl(udc, INT_ENB);
+ int_enb = usba_int_enb_get(udc);
+ status = usba_readl(udc, INT_STA) & int_enb;
DBG(DBG_INT, "irq, status=%#08x\n", status);
if (status & USBA_DET_SUSPEND) {
toggle_bias(udc, 0);
usba_writel(udc, INT_CLR, USBA_DET_SUSPEND);
- usba_writel(udc, INT_ENB,
- usba_readl(udc, INT_ENB) | USBA_WAKE_UP);
+ usba_int_enb_set(udc, int_enb | USBA_WAKE_UP);
udc->bias_pulse_needed = true;
DBG(DBG_BUS, "Suspend detected\n");
if (udc->gadget.speed != USB_SPEED_UNKNOWN
@@ -1633,8 +1641,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (status & USBA_WAKE_UP) {
toggle_bias(udc, 1);
usba_writel(udc, INT_CLR, USBA_WAKE_UP);
- usba_writel(udc, INT_ENB,
- usba_readl(udc, INT_ENB) & ~USBA_WAKE_UP);
+ usba_int_enb_set(udc, int_enb & ~USBA_WAKE_UP);
DBG(DBG_BUS, "Wake Up CPU detected\n");
}
@@ -1702,11 +1709,8 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
| USBA_BF(BK_NUMBER, USBA_BK_NUMBER_ONE)));
usba_ep_writel(ep0, CTL_ENB,
USBA_EPT_ENABLE | USBA_RX_SETUP);
- usba_writel(udc, INT_ENB,
- (usba_readl(udc, INT_ENB)
- | USBA_BF(EPT_INT, 1)
- | USBA_DET_SUSPEND
-
[PATCH v2 1/5] usb: atmel_usba_udc: Rework at91sam9rl errata handling
at91sam9rl SoC has an erratum forcing us to toggle the BIAS on USB
suspend/resume events.
This specific handling is only activated when CONFIG_ARCH_AT91SAM9RL is
set and this option is only set when building a non-DT kernel, which is
problematic since non-DT support for at91sam9rl SoC has been removed.
Rework the toggle_bias implementation to attach it to the "at91sam9rl-udc"
compatible string.
Add new compatible strings to avoid executing at91sam9rl erratum handling
on other SoCs.
Signed-off-by: Boris Brezillon
---
.../devicetree/bindings/usb/atmel-usb.txt | 5 +-
drivers/usb/gadget/udc/atmel_usba_udc.c| 78 --
drivers/usb/gadget/udc/atmel_usba_udc.h| 5 ++
3 files changed, 52 insertions(+), 36 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt
b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index bcc..38fee0f 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -51,7 +51,10 @@ usb1: gadget@fffa4000 {
Atmel High-Speed USB device controller
Required properties:
- - compatible: Should be "atmel,at91sam9rl-udc"
+ - compatible: Should be one of the following
+ "at91sam9rl-udc"
+ "at91sam9g45-udc"
+ "sama5d3-udc"
- reg: Address and length of the register set for the device
- interrupts: Should contain usba interrupt
- ep childnode: To specify the number of endpoints and their properties.
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index ce88237..36fd34b 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -8,6 +8,7 @@
* published by the Free Software Foundation.
*/
#include
+#include
#include
#include
#include
@@ -324,28 +325,12 @@ static int vbus_is_present(struct usba_udc *udc)
return 1;
}
-#if defined(CONFIG_ARCH_AT91SAM9RL)
-
-#include
-
-static void toggle_bias(int is_on)
-{
- unsigned int uckr = at91_pmc_read(AT91_CKGR_UCKR);
-
- if (is_on)
- at91_pmc_write(AT91_CKGR_UCKR, uckr | AT91_PMC_BIASEN);
- else
- at91_pmc_write(AT91_CKGR_UCKR, uckr & ~(AT91_PMC_BIASEN));
-}
-
-#else
-
-static void toggle_bias(int is_on)
+static void toggle_bias(struct usba_udc *udc, int is_on)
{
+ if (udc->errata && udc->errata->toggle_bias)
+ udc->errata->toggle_bias(udc, is_on);
}
-#endif /* CONFIG_ARCH_AT91SAM9RL */
-
static void next_fifo_transaction(struct usba_ep *ep, struct usba_request *req)
{
unsigned int transaction_len;
@@ -1620,7 +1605,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
DBG(DBG_INT, "irq, status=%#08x\n", status);
if (status & USBA_DET_SUSPEND) {
- toggle_bias(0);
+ toggle_bias(udc, 0);
usba_writel(udc, INT_CLR, USBA_DET_SUSPEND);
DBG(DBG_BUS, "Suspend detected\n");
if (udc->gadget.speed != USB_SPEED_UNKNOWN
@@ -1632,7 +1617,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
}
if (status & USBA_WAKE_UP) {
- toggle_bias(1);
+ toggle_bias(udc, 1);
usba_writel(udc, INT_CLR, USBA_WAKE_UP);
DBG(DBG_BUS, "Wake Up CPU detected\n");
}
@@ -1736,13 +1721,13 @@ static irqreturn_t usba_vbus_irq(int irq, void *devid)
vbus = vbus_is_present(udc);
if (vbus != udc->vbus_prev) {
if (vbus) {
- toggle_bias(1);
+ toggle_bias(udc, 1);
usba_writel(udc, CTRL, USBA_ENABLE_MASK);
usba_writel(udc, INT_ENB, USBA_END_OF_RESET);
} else {
udc->gadget.speed = USB_SPEED_UNKNOWN;
reset_all_endpoints(udc);
- toggle_bias(0);
+ toggle_bias(udc, 0);
usba_writel(udc, CTRL, USBA_DISABLE_MASK);
if (udc->driver->disconnect) {
spin_unlock(&udc->lock);
@@ -1788,7 +1773,7 @@ static int atmel_usba_start(struct usb_gadget *gadget,
/* If Vbus is present, enable the controller and wait for reset */
spin_lock_irqsave(&udc->lock, flags);
if (vbus_is_present(udc) && udc->vbus_prev == 0) {
- toggle_bias(1);
+ toggle_bias(udc, 1);
usba_writel(udc, CTRL, USBA_ENABLE_MASK);
usba_writel(udc, INT_ENB, USBA_END_OF_RESET);
}
@@ -1811,7 +1796,7 @@ static int atmel_usba_stop(struct usb_gadget *gadget)
spin_unlock_irqrestore(&udc->lock, flags);
/* This will also disable the DP pullup */
- toggle_bias(0);
+ toggle_bias(udc, 0);
usba_writel(udc, CTRL, USBA_DISABLE_MASK);
clk_disable_unprepare(udc->hclk);
@@
[PATCH v2 2/5] usb: atmel_usba_udc: Add at91sam9g45 and at91sam9x5 errata handling
at91sam9g45 and at91sam9x5 SoCs have an hardware bug forcing us to
generate a pulse on the BIAS signal on "USB end of reset” and
“USB end of resume" events.
Reported-by: Patrice VILCHEZ
Signed-off-by: Boris Brezillon
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 28 +++-
drivers/usb/gadget/udc/atmel_usba_udc.h | 2 ++
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 36fd34b..55c8dde 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -331,6 +331,17 @@ static void toggle_bias(struct usba_udc *udc, int is_on)
udc->errata->toggle_bias(udc, is_on);
}
+static void generate_bias_pulse(struct usba_udc *udc)
+{
+ if (!udc->bias_pulse_needed)
+ return;
+
+ if (udc->errata && udc->errata->pulse_bias)
+ udc->errata->pulse_bias(udc);
+
+ udc->bias_pulse_needed = false;
+}
+
static void next_fifo_transaction(struct usba_ep *ep, struct usba_request *req)
{
unsigned int transaction_len;
@@ -1607,6 +1618,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (status & USBA_DET_SUSPEND) {
toggle_bias(udc, 0);
usba_writel(udc, INT_CLR, USBA_DET_SUSPEND);
+ udc->bias_pulse_needed = true;
DBG(DBG_BUS, "Suspend detected\n");
if (udc->gadget.speed != USB_SPEED_UNKNOWN
&& udc->driver && udc->driver->suspend) {
@@ -1624,6 +1636,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (status & USBA_END_OF_RESUME) {
usba_writel(udc, INT_CLR, USBA_END_OF_RESUME);
+ generate_bias_pulse(udc);
DBG(DBG_BUS, "Resume detected\n");
if (udc->gadget.speed != USB_SPEED_UNKNOWN
&& udc->driver && udc->driver->resume) {
@@ -1659,6 +1672,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
struct usba_ep *ep0;
usba_writel(udc, INT_CLR, USBA_END_OF_RESET);
+ generate_bias_pulse(udc);
reset_all_endpoints(udc);
if (udc->gadget.speed != USB_SPEED_UNKNOWN && udc->driver) {
@@ -1818,13 +1832,25 @@ static void at91sam9rl_toggle_bias(struct usba_udc
*udc, int is_on)
at91_pmc_write(AT91_CKGR_UCKR, uckr & ~(AT91_PMC_BIASEN));
}
+static void at91sam9g45_pulse_bias(struct usba_udc *udc)
+{
+ unsigned int uckr = at91_pmc_read(AT91_CKGR_UCKR);
+
+ at91_pmc_write(AT91_CKGR_UCKR, uckr & ~(AT91_PMC_BIASEN));
+ at91_pmc_write(AT91_CKGR_UCKR, uckr | AT91_PMC_BIASEN);
+}
+
static const struct usba_udc_errata at91sam9rl_errata = {
.toggle_bias = at91sam9rl_toggle_bias,
};
+static const struct usba_udc_errata at91sam9g45_errata = {
+ .pulse_bias = at91sam9g45_pulse_bias,
+};
+
static const struct of_device_id atmel_udc_dt_ids[] = {
{ .compatible = "atmel,at91sam9rl-udc", .data = &at91sam9rl_errata },
- { .compatible = "atmel,at91sam9g45-udc" },
+ { .compatible = "atmel,at91sam9g45-udc", .data = &at91sam9g45_errata },
{ .compatible = "atmel,sama5d3-udc" },
{ /* sentinel */ }
};
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.h
b/drivers/usb/gadget/udc/atmel_usba_udc.h
index 456899e..72b3537 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.h
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.h
@@ -306,6 +306,7 @@ struct usba_request {
struct usba_udc_errata {
void (*toggle_bias)(struct usba_udc *udc, int is_on);
+ void (*pulse_bias)(struct usba_udc *udc);
};
struct usba_udc {
@@ -326,6 +327,7 @@ struct usba_udc {
struct clk *pclk;
struct clk *hclk;
struct usba_ep *usba_ep;
+ bool bias_pulse_needed;
u16 devstatus;
--
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 4/5] usb: atmel_usba_udc: Mask status with enabled irqs
Avoid interpreting useless status flags when we're not waiting for such
events by masking the status variable with the interrupt enabled register
value.
Reported-by: Patrice VILCHEZ
Signed-off-by: Boris Brezillon
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 55c8dde..bc3a532 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1612,12 +1612,14 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
spin_lock(&udc->lock);
- status = usba_readl(udc, INT_STA);
+ status = usba_readl(udc, INT_STA) & usba_readl(udc, INT_ENB);
DBG(DBG_INT, "irq, status=%#08x\n", status);
if (status & USBA_DET_SUSPEND) {
toggle_bias(udc, 0);
usba_writel(udc, INT_CLR, USBA_DET_SUSPEND);
+ usba_writel(udc, INT_ENB,
+ usba_readl(udc, INT_ENB) | USBA_WAKE_UP);
udc->bias_pulse_needed = true;
DBG(DBG_BUS, "Suspend detected\n");
if (udc->gadget.speed != USB_SPEED_UNKNOWN
@@ -1631,6 +1633,8 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (status & USBA_WAKE_UP) {
toggle_bias(udc, 1);
usba_writel(udc, INT_CLR, USBA_WAKE_UP);
+ usba_writel(udc, INT_ENB,
+ usba_readl(udc, INT_ENB) & ~USBA_WAKE_UP);
DBG(DBG_BUS, "Wake Up CPU detected\n");
}
--
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 3/5] ARM: at91/dt: update udc compatible strings
at91sam9g45, at91sam9x5 and sama5 SoCs should not use
"atmel,at91sam9rl-udc" for their USB device compatible property since
this compatible is attached to a specific hardware bug fix.
Signed-off-by: Boris Brezillon
---
arch/arm/boot/dts/at91sam9g45.dtsi | 2 +-
arch/arm/boot/dts/at91sam9x5.dtsi | 2 +-
arch/arm/boot/dts/sama5d3.dtsi | 2 +-
arch/arm/boot/dts/sama5d4.dtsi | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi
b/arch/arm/boot/dts/at91sam9g45.dtsi
index 2a8da8a..acd90eb 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -1144,7 +1144,7 @@
usb2: gadget@fff78000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "atmel,at91sam9rl-udc";
+ compatible = "atmel,at91sam9g45-udc";
reg = <0x0060 0x8
0xfff78000 0x400>;
interrupts = <27 IRQ_TYPE_LEVEL_HIGH 0>;
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi
b/arch/arm/boot/dts/at91sam9x5.dtsi
index bbb3ba6..d213147 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -1057,7 +1057,7 @@
usb2: gadget@f803c000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "atmel,at91sam9rl-udc";
+ compatible = "atmel,at91sam9g45-udc";
reg = <0x0050 0x8
0xf803c000 0x400>;
interrupts = <23 IRQ_TYPE_LEVEL_HIGH 0>;
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 5f4144d..2b407a4 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -1264,7 +1264,7 @@
usb0: gadget@0050 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "atmel,at91sam9rl-udc";
+ compatible = "atmel,sama5d3-udc";
reg = <0x0050 0x10
0xf803 0x4000>;
interrupts = <33 IRQ_TYPE_LEVEL_HIGH 2>;
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index 1b0f30c..52dce24 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -112,7 +112,7 @@
usb0: gadget@0040 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "atmel,at91sam9rl-udc";
+ compatible = "atmel,sama5d3-udc";
reg = <0x0040 0x10
0xfc02c000 0x4000>;
interrupts = <47 IRQ_TYPE_LEVEL_HIGH 2>;
--
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
USB 3.0 storage keep reconnecting after safely removed
Hi all, Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90791 My machine is Thinkpad Yoga with Onelink dock attached. Onelink dock is a USB 3.0 dock functioning as a USB 3.0 hub. This has two USB 3.0 ports in front. I connected a USB HDD enclosure to one of those ports. After use, I safely removed the storage device. But immediately that storage is connected. There is no such issue for laptop body's USB 3.0 ports or Onelink dock's USB 2.0 ports. I've tested in GNOME GUI and i3 CUI environment. In GNOME, I used gnome-disk utility. In i3, I echo'ed 1 to that USB 3.0 enclosure device's sysfs entry 'remove'. There is no difference. Using Onelink dock's USB 3.0 port: 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: logical disconnect <-- safely remove 1월 05 22:25:51 rapunzel kernel: hub 3-3:1.0: state 7 ports 4 chg 0010 evt 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: status 02b0, change , 5.0 Gb/s 1월 05 22:25:51 rapunzel kernel: usb 3-3.4: USB disconnect, device number 4 1월 05 22:25:51 rapunzel kernel: usb 3-3.4: unregistering device 1월 05 22:25:51 rapunzel kernel: hub 3-3:1.0: state 7 ports 4 chg evt 0010 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: reset change 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: warm reset change 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: status 0203, change 0031, 5.0 Gb/s 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: debounce total 100ms stable 100ms status 0x203 1월 05 22:25:51 rapunzel kernel: usb 3-3.4: new SuperSpeed USB device number 5 using xhci_hcd <-- reconnecting 1월 05 22:25:51 rapunzel kernel: usb 3-3.4: udev 5, busnum 3, minor = 260 1월 05 22:25:51 rapunzel kernel: usb-storage 3-3.4:1.0: USB Mass Storage device detected 1월 05 22:25:51 rapunzel kernel: scsi host5: usb-storage 3-3.4:1.0 1월 05 22:25:51 rapunzel kernel: hub 3-3:1.0: state 7 ports 4 chg evt 0010 1월 05 22:25:52 rapunzel kernel: scsi 5:0:0:0: Direct-Access Corsair Force 3 SSD 5.07 PQ: 0 ANSI: 0 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] 234441648 512-byte logical blocks: (120 GB/111 GiB) 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] Write Protect is off 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] Mode Sense: 03 00 00 00 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] No Caching mode page found 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] Assuming drive cache: write through 1월 05 22:25:52 rapunzel kernel: sdb: unknown partition table 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] Attached SCSI disk 1월 05 22:25:53 rapunzel kernel: BTRFS info (device sdb): disk space caching is enabled 1월 05 22:25:53 rapunzel kernel: BTRFS: bdev /dev/sdb errs: wr 0, rd 1, flush 0, corrupt 0, gen 0 Using laptop body's USB 3.0 port: 1월 05 22:28:23 rapunzel kernel: usb usb3-port1: logical disconnect 1월 05 22:28:23 rapunzel kernel: hub 3-0:1.0: state 7 ports 4 chg evt 0002 1월 05 22:28:23 rapunzel kernel: usb usb3-port1: status 0280, change 0001, 5.0 Gb/s 1월 05 22:28:23 rapunzel kernel: usb 3-1: USB disconnect, device number 7 1월 05 22:28:23 rapunzel kernel: usb 3-1: unregistering device 1월 05 22:28:24 rapunzel kernel: usb usb3-port1: debounce total 100ms stable 100ms status 0x2e0 1월 05 22:28:24 rapunzel kernel: hub 3-0:1.0: state 7 ports 4 chg 0002 evt 1월 05 22:28:24 rapunzel kernel: usb usb3-port1: status 02e0, change , 5.0 Gb/s Thanks, Taegil Jan 05 15:27:20 rapunzel kernel: usb 3-3.4: new SuperSpeed USB device number 71 using xhci_hcd Jan 05 15:27:20 rapunzel kernel: usb-storage 3-3.4:1.0: USB Mass Storage device detected Jan 05 15:27:20 rapunzel kernel: scsi host62: usb-storage 3-3.4:1.0 Jan 05 15:27:21 rapunzel kernel: scsi 62:0:0:0: Direct-Access Corsair Force 3 SSD 5.07 PQ: 0 ANSI: 0 Jan 05 15:27:21 rapunzel kernel: sd 62:0:0:0: [sdb] 234441648 512-byte logical blocks: (120 GB/111 GiB) Jan 05 15:27:21 rapunzel kernel: sd 62:0:0:0: [sdb] Write Protect is off Jan 05 15:27:21 rapunzel kernel: sd 62:0:0:0: [sdb] Mode Sense: 03 00 00 00 Jan 05 15:27:21 rapunzel kernel: sd 62:0:0:0: [sdb] No Caching mode page found Jan 05 15:27:21 rapunzel kernel: sd 62:0:0:0: [sdb] Assuming drive cache: write through Jan 05 15:27:21 rapunzel kernel: sdb: unknown partition table Jan 05 15:27:21 rapunzel kernel: sd 62:0:0:0: [sdb] Attached SCSI disk Jan 05 15:27:22 rapunzel kernel: BTRFS info (device sdb): disk space caching is enabled Jan 05 15:27:22 rapunzel kernel: BTRFS: bdev /dev/sdb errs: wr 0, rd 1, flush 0, corrupt 0, gen 0 Jan 05 15:27:35 rapunzel kernel: usb 3-3.4: USB disconnect, device number 71 Jan 05 15:27:35 rapunzel kernel: usb 3-3.4: new SuperSpeed USB device number 72 using xhci_hcd Jan 05 15:27:35 rapunzel kernel: usb-storage 3-3.4:1.0: USB Mass Storage device detected Jan 05 15:27:35 rapunzel kernel: scsi host63: usb-storage 3-3.4:1.0 Jan 05 15:27:36 rapunzel kernel: scsi 63:0:0:0: Direct-Access Corsair Force 3 SSD 5.07 PQ: 0 ANSI: 0 Jan 05 15:27:36 rapu
Re: Difference between run time and normal suspend
On Tue, 6 Jan 2015, vichy wrote: > The mouse will reconnect even I just kept it connected and not moving it. > is there any method or debug message we can tell what is going on to > make it resume? usbmon. My guess is that the mouse disconnects and reconnects all by itself after a few seconds of suspend. 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: Difference between run time and normal suspend
On Tue, 6 Jan 2015, vichy wrote: > I use keyboard, it should be default support runtime suspend, for > testing runtime suspend like the attach log. > insert related modules, change related suspend parameters. > > But I cannot see the keyboard go to suspend even I force autosuspend as 0. > is there any other way to trigger runtime suspend immediately instead > of waiting kernel judge it is idle for a while? There may be other reasons why the keyboard does not get suspended. For example, it may not support remote wakeup. What does "lsusb -v" show? And what does usbmon show? 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: Difference between run time and normal suspend
On Tue, 6 Jan 2015, vichy wrote: > > I use keyboard, it should be default support runtime suspend, for > > testing runtime suspend like the attach log. > > insert related modules, change related suspend parameters. > > > > But I cannot see the keyboard go to suspend even I force autosuspend as 0. > > is there any other way to trigger runtime suspend immediately instead > > of waiting kernel judge it is idle for a while? No. > I test the same keyboard on the NB is also not seeing autosuspend work. > the kernel version of NB is 3.18 and my embedded system is 3.10 > (I also attach usb descriptor of the keyboard I used in the mail) If you want to find out what's happening, add some debugging printk statements to autosuspend_check() in drivers/usb/core/driver.c. Maybe also to usb_runtime_suspend(). You might also want to enable CONFIG_PM_ADVANCED_DEBUG and see what the other runtime_* files in the .../power directory say. 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: Difference between run time and normal suspend
hi Alan: 2015-01-06 23:03 GMT+08:00 Alan Stern : > On Tue, 6 Jan 2015, vichy wrote: > >> I use keyboard, it should be default support runtime suspend, for >> testing runtime suspend like the attach log. >> insert related modules, change related suspend parameters. >> >> But I cannot see the keyboard go to suspend even I force autosuspend as 0. >> is there any other way to trigger runtime suspend immediately instead >> of waiting kernel judge it is idle for a while? > > There may be other reasons why the keyboard does not get suspended. > For example, it may not support remote wakeup. What does "lsusb -v" > show? And what does usbmon show? here is the output of lsusb and usbmon will be attach soon. BTW, 1. is there any other method to trigger runtime suspend instead of waiting device to be idle. such as echo xxx > , and it will directly call runtime suspend related function 2. why remote wake up feature of hid is related to runtime suspend? runtime suspend is kernel use to saving power and suspend/resume actively, right? 3. for host part, runtime suspend/resume is only doing port suspend/resume or both host and port going to suspend/resume? appreciate your kind help, liteon.keyboard.desc.txt.tar.bz2 Description: BZip2 compressed data
Re: [PATCH] snd-usb-audio: Add support for Akai MPC Element MIDI controller
On 01/06/2015 07:39 AM, Clemens Ladisch wrote:
> Paul Bonser wrote:
>> This device incorrectly reports its bInterfaceClass as 255, when it
>> should really be 1 (USB_CLASS_AUDIO).
>>
>> +++ b/sound/usb/quirks-table.h
>> +{
>> +/* Akai MPC Element */
>> +USB_DEVICE(0x09e8, 0x0021),
>> +.bInterfaceClass = USB_CLASS_AUDIO,
>> +},
>
> This is not a correct usb_device_id entry.
I based it on an existing entry in the same file:
/* KeithMcMillen Stringport */
{
USB_DEVICE(0x1f38, 0x0001),
.bInterfaceClass = USB_CLASS_AUDIO,
},
It built with no complaints and functioned as expected (showed up as a
MIDI device and sent/recived commands via ALSA MIDI whereas before it
didn't). The only interfaces it has are audio interfaces, so if this
overrides every interface, that's fine.
I'm sure it's possible that the Stringport entry is also incorrect, so
is there a different format that would be more proper to use?
>
> Show the output of "lsusb -v" for this device.
The device actually has two modes: a low power mode (where the LEDs are
lit up dimly or not at all), and a high power mode (where the LEDs have
their full functionality). In the low power mode, it gives a MaxPower of
100mA, and in the high power mode it gives 500mA. It's the high power
mode where the bInterfaceClass is set to 255. Everthing else, aside from
MaxPower is the same.
"Low power mode":
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0x09e8 AKAI Professional M.I. Corp.
idProduct 0x0021
bcdDevice1.12
iManufacturer 1
iProduct2
iSerial 4
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 120
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 0
iInterface 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 18
bInCollection 1
baInterfaceNr( 0) 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 3 MIDI Streaming
bInterfaceProtocol 0
iInterface 3
MIDIStreaming Interface Descriptor:
bLength 7
bDescriptorType36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 84
MIDIStreaming Interface Descriptor:
bLength 6
bDescriptorType36
bDescriptorSubtype 2 (MIDI_IN_JACK)
bJackType 1 Embedded
bJackID 1
iJack 6
MIDIStreaming Interface Descriptor:
bLength 6
bDescriptorType36
bDescriptorSubtype 2 (MIDI_IN_JACK)
bJackType 1 Embedded
bJackID 2
iJack 7
MIDIStreaming Interface Descriptor:
bLength 6
bDescriptorType36
bDescriptorSubtype 2 (MIDI_IN_JACK)
bJackType 1 Embedded
bJackID 3
iJack 8
MIDIStreaming Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype 3 (MIDI_OUT_JACK)
bJackType 1 Embedded
bJackID 4
bNrInputPins1
baSourceID( 0) 1
BaSourcePin( 0) 1
iJack 13
MIDIStreaming Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype 3 (MIDI_OUT_JACK)
bJackType 1 Embedded
bJackID 5
bNrInputPins1
baSourceID( 0) 2
BaSourcePin( 0) 1
iJack 14
MIDIStreaming Interface Descriptor:
bLength 9
bDescriptorType
Re: [PATCH] USB: cp210x: add IDs for CEL USB sticks and MeshWorks devices
On Tue, Jan 06, 2015 at 03:00:52PM +, Peterson, David wrote:
> From: David Peterson
>
> Added virtual com port VID/PID entries for CEL USB sticks and MeshWorks
> devices
>
> Signed-off-by: David Peterson
Applied, thanks.
Johan
> ---
> drivers/usb/serial/cp210x.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c index
> 6c4eb3c..a6db2fc 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -120,6 +120,9 @@ static const struct usb_device_id id_table[] = {
> { USB_DEVICE(0x10C4, 0x85F8) }, /* Virtenio Preon32 */
> { USB_DEVICE(0x10C4, 0x8664) }, /* AC-Services CAN-IF */
> { USB_DEVICE(0x10C4, 0x8665) }, /* AC-Services OBD-IF */
> + { USB_DEVICE(0x10C4, 0x8856) }, /* CEL EM357 ZigBee USB Stick - LR */
> + { USB_DEVICE(0x10C4, 0x8857) }, /* CEL EM357 ZigBee USB Stick */
> + { USB_DEVICE(0x10C4, 0x8977) }, /* CEL MeshWorks DevKit Device */
> { USB_DEVICE(0x10C4, 0x8875) }, /* CEL MeshConnect USB Stick */
> { USB_DEVICE(0x10C4, 0x88A4) }, /* MMB Networks ZigBee USB Device */
> { USB_DEVICE(0x10C4, 0x88A5) }, /* Planet Innovation Ingeni ZigBee USB
> Device */
--
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: [PATCHv2 1/2] usb: ohci-platform: add support for multiple phys per controller
On Thu, 11 Dec 2014 arun.ramamur...@broadcom.com wrote:
> From: Arun Ramamurthy
>
> Added support for cases where one controller is connected
> to multiple phys
Will this continue to work on systems that use only one PHY? What
about systems that don't use DT?
> diff --git a/drivers/usb/host/ohci-platform.c
> b/drivers/usb/host/ohci-platform.c
> index 4369299..eef82f1 100644
> --- a/drivers/usb/host/ohci-platform.c
> +++ b/drivers/usb/host/ohci-platform.c
> @@ -38,7 +38,8 @@
> struct ohci_platform_priv {
> struct clk *clks[OHCI_MAX_CLKS];
> struct reset_control *rst;
> - struct phy *phy;
> + struct phy *phys;
Is this supposed to be an array of phy _structures_ or an array of
_pointers_ to phy structures? The code says an array of structures,
which seems very suspicious. Why copy phy structures into your own
private array?
> + int num_phys;
> };
>
> static const char hcd_name[] = "ohci-platform";
> @@ -61,7 +62,7 @@ static int ohci_platform_power_on(struct platform_device
> *dev)
> {
> struct usb_hcd *hcd = platform_get_drvdata(dev);
> struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
> - int clk, ret;
> + int clk, ret, phy_num;
>
> for (clk = 0; clk < OHCI_MAX_CLKS && priv->clks[clk]; clk++) {
> ret = clk_prepare_enable(priv->clks[clk]);
> @@ -69,20 +70,28 @@ static int ohci_platform_power_on(struct platform_device
> *dev)
> goto err_disable_clks;
> }
>
> - if (priv->phy) {
> - ret = phy_init(priv->phy);
> - if (ret)
> - goto err_disable_clks;
> -
> - ret = phy_power_on(priv->phy);
> - if (ret)
> + for (phy_num = 0; phy_num < priv->num_phys; phy_num++) {
> + ret = phy_init(&priv->phys[phy_num]);
> + if (ret) {
> + if (phy_num == 0)
> + goto err_disable_clks;
> + else
> + goto err_exit_phy;
You don't need this "if" statement. Just goto err_exit_phy always; it
will do the right thing.
> + }
> + ret = phy_power_on(&priv->phys[phy_num]);
> + if (ret) {
> + phy_exit(&priv->phys[phy_num]);
> goto err_exit_phy;
> + }
> }
>
> return 0;
>
> err_exit_phy:
> - phy_exit(priv->phy);
> + while (--phy_num >= 0) {
> + phy_power_off(&priv->phys[phy_num]);
> + phy_exit(&priv->phys[phy_num]);
> + };
> err_disable_clks:
> while (--clk >= 0)
> clk_disable_unprepare(priv->clks[clk]);
> @@ -94,11 +103,11 @@ static void ohci_platform_power_off(struct
> platform_device *dev)
> {
> struct usb_hcd *hcd = platform_get_drvdata(dev);
> struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
> - int clk;
> + int clk, phy_num;
>
> - if (priv->phy) {
> - phy_power_off(priv->phy);
> - phy_exit(priv->phy);
> + for (phy_num = 0; phy_num < priv->num_phys; phy_num++) {
> + phy_power_off(&priv->phys[phy_num]);
> + phy_exit(&priv->phys[phy_num]);
> }
>
> for (clk = OHCI_MAX_CLKS - 1; clk >= 0; clk--)
> @@ -127,7 +136,9 @@ static int ohci_platform_probe(struct platform_device
> *dev)
> struct usb_ohci_pdata *pdata = dev_get_platdata(&dev->dev);
> struct ohci_platform_priv *priv;
> struct ohci_hcd *ohci;
> - int err, irq, clk = 0;
> + struct phy *temp_phy;
> + const char *phy_name;
> + int err, irq, phy_num, clk = 0;
>
> if (usb_disabled())
> return -ENODEV;
> @@ -175,12 +186,29 @@ static int ohci_platform_probe(struct platform_device
> *dev)
> if (of_property_read_bool(dev->dev.of_node, "big-endian"))
> ohci->flags |= OHCI_QUIRK_BE_MMIO | OHCI_QUIRK_BE_DESC;
>
> - priv->phy = devm_phy_get(&dev->dev, "usb");
> - if (IS_ERR(priv->phy)) {
> - err = PTR_ERR(priv->phy);
> - if (err == -EPROBE_DEFER)
> - goto err_put_hcd;
> - priv->phy = NULL;
> + priv->num_phys = of_count_phandle_with_args
> + (dev->dev.of_node, "phys", "#phy-cells");
It's things like this that make me question whether this patch will
work correctly. What about systems that don't use OF but do use
devm_phy_get()?
Also, the line break is at a strange place (just before the open paren
of a function call), and the indentation of the continuation line is
unusual.
> + if (priv->num_phys > 0) {
> + priv->phys = devm_kcalloc(&dev->dev, priv->num_phys,
> + sizeof(struct phy), GFP_KERNEL);
Here again the indentation is unusual. In this file, continuation
lines are indented by 2 tab stops beyond the statemen
[PATCH 0/4] ARM: mvebu: Enable XHCI on the A385-AP
Hi all,
This serie enables the Armada 385 AP XHCI controller.
Since the controller uses a GPIO-controlled VBUS, we used the
phy-generic driver, and made the needed additions to the xhci-plat
driver to retrieve a USB phy.
Unfortunately, some glitches were also found along the way, mostly
because of the probe deferring that was introduced by this phy
retrieval.
First, the commit 1290a958d48e ("usb: phy: propagate
__of_usb_find_phy()'s error on failure") introduced in 3.19 broke the
deferred probing for consumer drivers. The first patch attempts at
fixing this while keeping the original intention of the author, and
should probably go in as a fix for 3.19.
Then, since the introduction of the Armada 38x support in 3.16, the
driver was attempting to write into registers while the clock wasn't
enabled yet. This was working because the bootloader left it enabled,
but in the case of a deferred probing, the clock would have been
disabled by the error path of our driver, and this would fail. This
should go in 3.19 as well, and any stable kernel for 3.16+.
The two patches remaining are "regular" patches, and are aimed at
3.20. The last patch depend on my previous serie to introduce support
for the the A385 AP board.
Thanks,
Maxime
Maxime Ripard (4):
usb: phy: Fix deferred probing
usb: XHCI: platform: Move the Marvell quirks after the enabling the
clocks
usb: xhci: plat: Add USB phy support
ARM: mvebu: armada-385-ap: Enable USB3 port
arch/arm/boot/dts/armada-385-ap.dts | 28
drivers/usb/host/xhci-plat.c| 32 ++--
drivers/usb/host/xhci.h | 2 ++
drivers/usb/phy/phy.c | 6 +++---
4 files changed, 55 insertions(+), 13 deletions(-)
--
2.2.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 4/4] ARM: mvebu: armada-385-ap: Enable USB3 port
The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the
VBUS line. Enable the needed drivers to support this.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/armada-385-ap.dts | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/armada-385-ap.dts
b/arch/arm/boot/dts/armada-385-ap.dts
index ab88dc4be636..a9dea82ef34b 100644
--- a/arch/arm/boot/dts/armada-385-ap.dts
+++ b/arch/arm/boot/dts/armada-385-ap.dts
@@ -88,6 +88,13 @@
status = "okay";
};
+ pinctrl@18000 {
+ xhci0_vbus_pins: xhci0-vbus-pins {
+ marvell,pins = "mpp44";
+ marvell,function = "gpio";
+ };
+ };
+
ethernet@3 {
status = "okay";
phy = <&phy1>;
@@ -112,6 +119,11 @@
phy = <&phy0>;
phy-mode = "rgmii-id";
};
+
+ usb3@f {
+ status = "okay";
+ usb-phy = <&usb3_phy>;
+ };
};
pcie-controller {
@@ -137,4 +149,20 @@
};
};
};
+
+ usb3_phy: usb3_phy {
+ compatible = "usb-nop-xceiv";
+ vcc-supply = <®_xhci0_vbus>;
+ };
+
+ reg_xhci0_vbus: xhci0-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&xhci0_vbus_pins>;
+ regulator-name = "xhci0-vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ enable-active-high;
+ gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+ };
};
--
2.2.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 3/4] usb: xhci: plat: Add USB phy support
The Marvell Armada 385 AP needs a dumb phy in order to enable the USB3 VBUS.
Add a call to retrieve a USB PHY to XHCI plat in order to support this.
Signed-off-by: Maxime Ripard
---
drivers/usb/host/xhci-plat.c | 13 +
drivers/usb/host/xhci.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 34c2f6d3e5d0..284ab70f13a3 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -155,6 +156,18 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
xhci->shared_hcd->can_do_streams = 1;
+ xhci->phy = devm_usb_get_phy_by_phandle(&pdev->dev, "usb-phy", 0);
+ if (IS_ERR(xhci->phy)) {
+ ret = PTR_ERR(xhci->phy);
+ if (ret == -EPROBE_DEFER)
+ goto put_usb3_hcd;
+ xhci->phy = NULL;
+ } else {
+ ret = usb_phy_init(xhci->phy);
+ if (ret)
+ goto put_usb3_hcd;
+ }
+
ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
if (ret)
goto put_usb3_hcd;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index cc7c5bb7cbcf..d9468af2a8e4 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1474,6 +1474,8 @@ struct xhci_hcd {
struct msix_entry *msix_entries;
/* optional clock */
struct clk *clk;
+ /* optional phy */
+ struct usb_phy *phy;
/* data structures */
struct xhci_device_context_array *dcbaa;
struct xhci_ring*cmd_ring;
--
2.2.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 2/2 resend v2] USB: host: Introduce flag to enable use of 64-bit dma_mask for ehci-platform
On Tue, 6 Jan 2015, Andreas Herrmann wrote: > ehci-octeon driver used a 64-bit dma_mask. With removal of ehci-octeon > and usage of ehci-platform ehci dma_mask is now limited to 32 bits > (coerced in ehci_platform_probe). > > Provide a flag in ehci platform data to allow use of 64 bits for > dma_mask. > > Cc: David Daney > Cc: Alex Smith > Cc: Alan Stern > Signed-off-by: Andreas Herrmann > Tested-by: Aaro Koskinen Acked-by: Alan Stern Is something like this also needed for ohci-platform? Or are all OHCI implementations restricted to 32-bit DMA masks? 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 2/4] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks
The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada
375/38x XHCI controllers") extended the xhci-plat driver to support the Armada
375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
However, that quirk was run before the clock the controllers needs has been
enabled. This usually worked because the clock was first enabled by the
bootloader, and left as such until the driver is probe, where it tries to
access the MBUS configuration registers before enabling the clock.
Things get messy when EPROBE_DEFER is involved during the probe, since as part
of its error path, the driver will rightfully disable the clock. When the
driver will be reprobed, it will retry to access the MBUS registers, but this
time with the clock disabled, which hangs forever.
Fix this by running the quirks after the clock has been enabled by the driver.
Signed-off-by: Maxime Ripard
Cc: # v3.16+
---
drivers/usb/host/xhci-plat.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 08d402b15482..34c2f6d3e5d0 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -83,16 +83,6 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (irq < 0)
return -ENODEV;
-
- if (of_device_is_compatible(pdev->dev.of_node,
- "marvell,armada-375-xhci") ||
- of_device_is_compatible(pdev->dev.of_node,
- "marvell,armada-380-xhci")) {
- ret = xhci_mvebu_mbus_init_quirk(pdev);
- if (ret)
- return ret;
- }
-
/* Initialize dma_mask and coherent_dma_mask to 32-bits */
ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
if (ret)
@@ -127,6 +117,15 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_hcd;
}
+ if (of_device_is_compatible(pdev->dev.of_node,
+ "marvell,armada-375-xhci") ||
+ of_device_is_compatible(pdev->dev.of_node,
+ "marvell,armada-380-xhci")) {
+ ret = xhci_mvebu_mbus_init_quirk(pdev);
+ if (ret)
+ return ret;
+ }
+
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto disable_clk;
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] usb: phy: Fix deferred probing
Commit 1290a958d48e ("usb: phy: propagate __of_usb_find_phy()'s error on
failure") actually broke the deferred probing mechanism, since it now returns
EPROBE_DEFER only when the try_module_get call fails, but not when the phy
lookup does.
All the other similar functions seem to return ENODEV when try_module_get
fails, and the error code of either __usb_find_phy or __of_usb_find_phy
otherwise.
In order to have a consistent behaviour, and a meaningful EPROBE_DEFER, always
return EPROBE_DEFER when __(of_)usb_find_phy fails to look up the requested
phy, that will be propagated by the caller, and ENODEV if try_module_get fails.
Signed-off-by: Maxime Ripard
---
drivers/usb/phy/phy.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index b4066a001ba0..353c686498d4 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -34,7 +34,7 @@ static struct usb_phy *__usb_find_phy(struct list_head *list,
return phy;
}
- return ERR_PTR(-ENODEV);
+ return ERR_PTR(-EPROBE_DEFER);
}
static struct usb_phy *__usb_find_phy_dev(struct device *dev,
@@ -66,7 +66,7 @@ static struct usb_phy *__of_usb_find_phy(struct device_node
*node)
return phy;
}
- return ERR_PTR(-ENODEV);
+ return ERR_PTR(-EPROBE_DEFER);
}
static void devm_usb_phy_release(struct device *dev, void *res)
@@ -192,7 +192,7 @@ struct usb_phy *devm_usb_get_phy_by_phandle(struct device
*dev,
phy = __of_usb_find_phy(node);
if (IS_ERR(phy) || !try_module_get(phy->dev->driver->owner)) {
if (!IS_ERR(phy))
- phy = ERR_PTR(-EPROBE_DEFER);
+ phy = ERR_PTR(-ENODEV);
devres_free(ptr);
goto err1;
--
2.2.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: Difference between run time and normal suspend
On Tue, 6 Jan 2015, vichy wrote: > >> But I cannot see the keyboard go to suspend even I force autosuspend as 0. > >> is there any other way to trigger runtime suspend immediately instead > >> of waiting kernel judge it is idle for a while? > > > > There may be other reasons why the keyboard does not get suspended. > > For example, it may not support remote wakeup. What does "lsusb -v" > > show? And what does usbmon show? > here is the output of lsusb and usbmon will be attach soon. > BTW, > 1. is there any other method to trigger runtime suspend instead of > waiting device to be idle. > such as echo xxx > , and it will directly call runtime > suspend related function No, there isn't. > 2. why remote wake up feature of hid is related to runtime suspend? > runtime suspend is kernel use to saving power and suspend/resume > actively, right? That's true. But it wouldn't work very well if the keyboard went into runtime suspend and stayed that way even when you tried to type on it! If a keyboard doesn't support remote wakeup then we must not put it into runtime suspend. However, I see from the lsusb output that your keyboard _does_ support remote wakeup, so that isn't the reason. > 3. for host part, runtime suspend/resume is only doing port > suspend/resume or both host and port going to suspend/resume? Only the port. However, when _all_ the devices attached to the host controlluer go into runtime suspend, the controller itself will also be put into runtime suspend. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks
Dear Maxime Ripard,
On Tue, 6 Jan 2015 16:45:08 +0100, Maxime Ripard wrote:
> + if (of_device_is_compatible(pdev->dev.of_node,
> + "marvell,armada-375-xhci") ||
> + of_device_is_compatible(pdev->dev.of_node,
> + "marvell,armada-380-xhci")) {
> + ret = xhci_mvebu_mbus_init_quirk(pdev);
> + if (ret)
> + return ret;
> + }
So on error, you're leaking the struct usb_hcd now if I'm not mistaken.
When moving code around, the error handling should also be fixed. You
probably need "goto put_hcd;" instead of "return ret;".
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: PROBLEM: USB isochronous urb leak on EHCI driver
On Tue, 6 Jan 2015, Michael Tessier wrote: > > > That is interresting, however, I have an older kernel running an OHCI > > > driver which is able to handle 4 codecs. Same usb hardware (codecs and > > > hub), but older kernel on a different CPU, with much less power. This > > > makes me believe that there's a solution to make it work... > > > > Of course there is: Install an OHCI host controller and use it to drive > > your codecs. It should work fine. > > > > The periodic scheduling algorithm for OHCI is very different from the > > algorithm for EHCI. > > According to your knowledge, how much time would you think it takes to > change the EHCI driver with an OHCI one? I don't understand the question. > And can you tell if the OHCI driver > will work on my hardware given that the Host controller of the i.MX512 is > a USB2.0 host controller? (OHCI was implemented for USB 1.x from what I > understand) The OHCI driver works with OHCI hardware and the EHCI driver works with EHCI hardware. OHCI is USB-1.1 and EHCI is USB-2. They are not interchangeable. > I tried to do so several days ago with the built-in configurator > (I am using "ltib"), but the configurator does not allow selecting the > OHCI driver; I tried manually but it turned into compiler errors... It looks like the configurator is smart; it won't let you select the wrong driver for your hardware. 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: PROBLEM: USB isochronous urb leak on EHCI driver
> > > > Hi, > > > > > > > > I am dealing with a USB EHCI driver bug. Here is the info: > > > > > > > > My configuration: > > > > - > > > > > > > > Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host > > > > controller) Linux kernel: 2.6.31, using EHCI USB driver > > > > > > As mentioned by other people, the age of that kernel makes any bug report > > > completely irrelevant. It's hard to count the number of non-trivial > > > changes that have > been made to the isochronous code in ehci-hcd since > > > 2.6.31, but there have been quite a few. > > > > > > > Hub: 4-PORT USB 1.1 HUB (Texas Instruments PN: tusb2046b) > > > > Devices: 4 USB 1.1 audio codecs (Texas Instruments PN: pcm2901) > > > > > > > > Note: each codec is being used in R/W access, so with 4 codecs, I > > > > have > > > > 4 playback and 4 capture streams. > > > > > > > > My problem: > > > > --- > > > > > > > > I have usb urb leaks when connecting more than 1 codec to the USB > > > > 1.1 Hub. > > > > > > What do you mean by "urb leak"? Normally, people use the word "leak" > > > to refer to memory that is dynamically allocated and never deallocated, > > > but you seem to mean something else. > > > > You are right. What I mean by leak is the following: At application > > level, all my calls to "Read" or "Write" operation to the codec driver > > will return with the correct amount of bytes read/written, with a > > "choppy" sound. Then when looking at lower levels: > > > > snd_pcm_oss_write (pcm_oss.c) -> OK > > snd_pcm_lib_write (pcm_lib.c) -> OK > > usb_submit_urb (urb.c) -> FAIL with 3 codecs > > > > The "FAIL" here indicates that the total amount of bytes transferred > > does not correspond to what was expected. And indeed the sound is > > "choppy" when using more than a certain amount of bandwidth. However > > this amount of bandwidth is higher when connecting only 1 codec with > > different settings (48khz-stereo 16-bits instead of 32 khz-mono > > 16-bits).So at some point it looks like the bug is in the scheduler, only > > with several isochronous links. > > Agreed. > > > > The amount of bandwidth available is usually not as much of an issue > > > as the ability of the scheduling alogorithm to divide the bandwidth among > > > the streams. The algorithm is not very smart and it often runs into a > > > wall even when lots of physical bandwidth is still available. > > > > That is interresting, however, I have an older kernel running an OHCI > > driver which is able to handle 4 codecs. Same usb hardware (codecs and > > hub), but older kernel on a different CPU, with much less power. This > > makes me believe that there's a solution to make it work... > > Of course there is: Install an OHCI host controller and use it to drive your > codecs. It should work fine. > > The periodic scheduling algorithm for OHCI is very different from the > algorithm for EHCI. According to your knowledge, how much time would you think it takes to change the EHCI driver with an OHCI one? And can you tell if the OHCI driver will work on my hardware given that the Host controller of the i.MX512 is a USB2.0 host controller? (OHCI was implemented for USB 1.x from what I understand) I tried to do so several days ago with the built-in configurator (I am using "ltib"), but the configurator does not allow selecting the OHCI driver; I tried manually but it turned into compiler errors... > > > > How does your hardware connect the host controller to a full-speed > > > device? Is there an internal hub (Intel motherboards have used this > > > approach)? Is there a companion USB-1.1 controller (older motherboards > > > from Intel and other companys have used this approach)? Does the EHCI > > > controller have a built-in Transaction Translator (some SOC systems use > > > this approach)? > > > > The CPU is a Freescale i.MX512, with 3 USB 2.0 Host controllers. My > > hub is connected to the main CPU board with a standard USB cable, so > > it's easy to swap my 4-port hub from a USB 1.1 to a USB 2.0. My codecs > > are always the same: USB 1.1 Texas Instruments PN# pcm2901. I don't > > believe there's a built-in Transaction Translator. How can I check that? > > You can tell by seeing what shows up in the "lsusb -t" output when you plug > in the USB-1.1 hub. If the hub's parent is the EHCI controller then there > must be a built-in TT. > > Also, if you enable CONFIG_USB_DEBUG in your kernel then the dmesg log for > boot-up should say whether or not the controller has a built-in TT. > > > > > Question: > > > > - > > > > > > > > Before attempting to upgrade to an earlier kernel driver (this is > > > > > > "upgrade to an earlier kernel driver" is a contradiction in terms. > > > Moving to an earlier driver would be a _downgrade_. > > > > Sorry, I meant to say "newer"... > > > > > > a fairly big amount of work), I would really like to know if this > > > > problem would still be in t
RE: PROBLEM: USB isochronous urb leak on EHCI driver
> > If sound is ok when using only 1 codec and becomes choppy when adding
> > a second codec, then it means that this issue is still in the 3.x
> > kernel. This answer will tell me if it is worth working on using a newer
> > kernel or not.
> > I have to say that I'm not a linux expert, so I see the migration to a
> > newer kernel as a quite big amount of work...
>
> We have support for mx51 on the latest kernel. All you need to do is to
> describe your hardware on a device tree file. You can refer to
> arch/arm/boot/dts/imx51-babbage.dts as an example.
>
> Should be simple for you to make such test with the latest kernel.
I'll try to do so. My main concern is that even if it has been corrected
in the last kernel, I'm not free to just use the last kernel; our customers
already have units in their hands, and they bought us a "Form Fit & Function"
plattform. We have a huge bunch of documentation coming with each deliverable
(part of an ISO process, following IEEE software standards). So for the
company, migrating to the latest kernel is the last resort because of the
amount of work it would require. Thanks for the idea, I'll let you know.
Michael Tessier
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
RE: PROBLEM: USB isochronous urb leak on EHCI driver
> > > > That is interresting, however, I have an older kernel running an > > > > OHCI driver which is able to handle 4 codecs. Same usb hardware > > > > (codecs and hub), but older kernel on a different CPU, with much > > > > less power. This makes me believe that there's a solution to make it > > > > work... > > > > > > Of course there is: Install an OHCI host controller and use it to drive > > > your codecs. It should work fine. What do you mean by that? The host controller is embedded in the i.MX CPU... Changing the CPU is not really an option to me. Unless I am missing something? > > > > > > The periodic scheduling algorithm for OHCI is very different from the > > > algorithm for EHCI. > > > > According to your knowledge, how much time would you think it takes to > > change the EHCI driver with an OHCI one? > > I don't understand the question. > > > And can you tell if the OHCI driver > > will work on my hardware given that the Host controller of the i.MX512 > > is a USB2.0 host controller? (OHCI was implemented for USB 1.x from > > what I > > understand) > > The OHCI driver works with OHCI hardware and the EHCI driver works with EHCI > hardware. OHCI is USB-1.1 and EHCI is USB-2. They are not interchangeable. That was what I thought first... > > > I tried to do so several days ago with the built-in configurator (I am > > using "ltib"), but the configurator does not allow selecting the OHCI > > driver; I tried manually but it turned into compiler errors... > > It looks like the configurator is smart; it won't let you select the wrong > driver for your hardware. > > 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: kernel panic with USB3+DVB+ARM
On Tue, Jan 06, 2015 at 11:47:29AM +0100, JPT wrote: > Hi Greg > > Am 06.01.2015 um 02:54 schrieb Greg KH: > > > > Is that where the kernel panics show the problem happens? Without them, > > there's nothing we can do to help out except randomly guess, sorry. > > well. at least xhci is contained in the call stack: > > > [] (crc32_be) from [] (dvb_dmx_crc32+0x10/0x18 > > [dvb_core]) > > [] (dvb_dmx_crc32 [dvb_core]) from [] > > (dvb_dmx_swfilter_section_copy_dump+0x254/0x268 [dvb_core]) > > [] (dvb_dmx_swfilter_section_copy_dump [dvb_core]) from > > [] (dvb_dmx_swfilter_packet+0x45c/0x564 [dvb_core]) > > [] (dvb_dmx_swfilter_packet [dvb_core]) from [] > > (dvb_dmx_swfilter+0xf4/0x164 [dvb_core]) > > [] (dvb_dmx_swfilter [dvb_core]) from [] > > (usb_urb_complete+0xbc/0xe4 [dvb_usb]) > > [] (usb_urb_complete [dvb_usb]) from [] > > (__usb_hcd_giveback_urb+0x5c/0xe8) > > [] (__usb_hcd_giveback_urb) from [] > > (xhci_irq+0x8d8/0x1e08) > > [] (xhci_irq) from [] > > (handle_irq_event_percpu+0x78/0x140) > > [] (handle_irq_event_percpu) from [] > > (handle_irq_event+0x28/0x38) > > [] (handle_irq_event) from [] > > (handle_simple_irq+0x64/0xa8) > > [] (handle_simple_irq) from [] > > (generic_handle_irq+0x2c/0x3c) > > [] (generic_handle_irq) from [] (handle_IRQ+0x38/0x84) > > [] (handle_IRQ) from [] > > (armada_370_xp_handle_msi_irq+0x9c/0xa0) > > [] (armada_370_xp_handle_msi_irq) from [] > > (armada_370_xp_handle_irq+0x5c/0x60) > > [] (armada_370_xp_handle_irq) from [] > > (__irq_svc+0x40/0x54) > > > It's always the same stack, but different errors: > > kernelpanic0.log: Unhandled prefetch abort: unknown 25 (0x409) at 0xc02fc948 > kernelpanic0.log: Internal error: : 409 [#1] ARM > > kernelpanic1.log: Unhandled prefetch abort: unknown 25 (0x409) at 0xc02fc948 > kernelpanic1.log: Internal error: : 409 [#1] ARM > > kernelpanic2.log: Internal error: Oops: 815 [#1] ARM > > kernelpanic3.log: Unhandled prefetch abort: unknown 25 (0x409) at 0xc0301228 > kernelpanic3.log: Internal error: : 409 [#1] ARM > > kernelpanic4.log: Unhandled prefetch abort: unknown 0 (0x000) at 0xc0301228 > kernelpanic4.log: Internal error: : 0 [#1] ARM > > > I added a printk to dvb_dmx_crc32() (see dvb.log). This probably > introduced more problems, because irq code has to be fast? > During recording through USB2 this code made the system not crash but it > wasn't able to answer any request (SSH, HTTP, login from serial console ...) > > > Is this info useful? > I attached only one of the kernel panic logs. If you would like to see > the others, please tell me. > I am not sure if the dvb.log tells something of worth at all. > > > Jan > [ 57.646235] dvb_dmx_crc32(dvb_demux_feed e0d4b13c, src: e0d4b154, len 18 > [ 57.688218] dvb_dmx_crc32(dvb_demux_feed e0d4d3b4, src: e0d4d3cc, len 97 > [ 57.695163] dvb_dmx_crc32(dvb_demux_feed e0d4a000, src: e0d4a018, len 28 > [ 57.702105] xhci_hcd :01:00.0: ERROR Unknown event condition, HC > probably busted > [ 57.709920] xhci_hcd :01:00.0: ERROR Unknown event condition, HC > probably busted > [ 57.717924] xhci_hcd :01:00.0: ERROR Unknown event condition, HC > probably busted > [ 57.725728] xhci_hcd :01:00.0: ERROR Unknown event condition, HC > probably busted Those messages look kind of important, right? :) Perhaps something is wrong with your hardware, you are using the 3.17 kernel release, does this also happen on 3.18? Do you have any xhci patches in your tree for this specific ARM hardware? > [ 57.748820] dvb_dmx_crc32(dvb_demux_feed e0d4d3b4, src: e0d4d3cc, len 97 > [ 57.755715] dvb_dmx_crc32(dvb_demux_feed e0d4a000, src: e0d4a018, len 28 > [ 57.762668] xhci_hcd :01:00.0: ERROR Unknown event condition, HC > probably busted > [ 57.770454] xhci_hcd :01:00.0: ERROR Unknown event condition, HC > probably busted > [ 57.782462] dvb_dmx_crc32(dvb_demux_feed e0d53b1c, src: e0d53b34, len 95 > [ 57.789220] dvb_dmx_crc32(dvb_demux_feed e0d529e0, src: e0d529f8, len 95 > [ 57.795992] dvb_dmx_crc32(dvb_demux_feed e0d518a4, src: e0d518bc, len 95 > [ 57.809074] dvb_dmx_crc32(dvb_demux_feed e0d4d3b4, src: e0d4d3cc, len 97 > [ 57.815970] dvb_dmx_crc32(dvb_demux_feed e0d4a000, src: e0d4a018, len 28 > [ 57.822902] xhci_hcd :01:00.0: ERROR Unknown event condition, HC > probably busted > [ 57.830687] xhci_hcd :01:00.0: ERROR Unknown event condition, HC > probably busted > [ 57.839677] xhci_hcd :01:00.0: ERROR Transfer event TRB DMA ptr not > part of current TD ep_index 4 comp_code 13 > [ 57.850079] xhci_hcd :01:00.0: Looking for event-dma 1e5e2250 > trb-start 1e5e22c0 trb-end 1e5e22c0 seg-start > 1e5e2000 seg-end 1e5e23f0 > [ 57.865968] xhci_hcd :01:00.0: ERROR Transfer event TRB DMA ptr not > part of current TD ep_index 4 comp_code 13 > [ 57.876364] xhci_hcd :01:00.0: Looking for event-dma 1e5e2260 > trb-start 1e5e22c0 trb-end 000
RE: PROBLEM: USB isochronous urb leak on EHCI driver
On Tue, 6 Jan 2015, Michael Tessier wrote: > > > > > That is interresting, however, I have an older kernel running an > > > > > OHCI driver which is able to handle 4 codecs. Same usb hardware > > > > > (codecs and hub), but older kernel on a different CPU, with much > > > > > less power. This makes me believe that there's a solution to make it > > > > > work... > > > > > > > > Of course there is: Install an OHCI host controller and use it to drive > > > > your codecs. It should work fine. > > What do you mean by that? The host controller is embedded in the i.MX CPU... > Changing the CPU is not really an option to me. Unless I am missing > something? I didn't realize you were talking about an i.MX-based system. On a computer with a free PCI slot, it's easy to add an OHCI controller. iMX isn't as accomodating. If there's no way to add an extra USB controller to your system then the only choice is to upgrade the driver software. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] r8152: support ndo_features_check
From: Hayes Wang Date: Tue, 6 Jan 2015 17:41:58 +0800 > Support ndo_features_check to avoid: > - the transport offset is more than the hw limitation when using hw checksum. > - the skb->len of a GSO packet is more than the limitation. > > Signed-off-by: Hayes Wang Applied, 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: [PATCHv2 1/2] usb: ohci-platform: add support for multiple phys per controller
Thank you for the comments Alan
On 15-01-06 07:45 AM, Alan Stern wrote:
On Thu, 11 Dec 2014 arun.ramamur...@broadcom.com wrote:
From: Arun Ramamurthy
Added support for cases where one controller is connected
to multiple phys
Will this continue to work on systems that use only one PHY? What
about systems that don't use DT?
Yes, It should work on systems that use only one phy but I see now that
I have not accounted for the non DT case. I will rework the patch to
include that and address your other comments.
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index 4369299..eef82f1 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -38,7 +38,8 @@
struct ohci_platform_priv {
struct clk *clks[OHCI_MAX_CLKS];
struct reset_control *rst;
- struct phy *phy;
+ struct phy *phys;
Is this supposed to be an array of phy _structures_ or an array of
_pointers_ to phy structures? The code says an array of structures,
which seems very suspicious. Why copy phy structures into your own
private array?
+ int num_phys;
};
static const char hcd_name[] = "ohci-platform";
@@ -61,7 +62,7 @@ static int ohci_platform_power_on(struct platform_device *dev)
{
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
- int clk, ret;
+ int clk, ret, phy_num;
for (clk = 0; clk < OHCI_MAX_CLKS && priv->clks[clk]; clk++) {
ret = clk_prepare_enable(priv->clks[clk]);
@@ -69,20 +70,28 @@ static int ohci_platform_power_on(struct platform_device
*dev)
goto err_disable_clks;
}
- if (priv->phy) {
- ret = phy_init(priv->phy);
- if (ret)
- goto err_disable_clks;
-
- ret = phy_power_on(priv->phy);
- if (ret)
+ for (phy_num = 0; phy_num < priv->num_phys; phy_num++) {
+ ret = phy_init(&priv->phys[phy_num]);
+ if (ret) {
+ if (phy_num == 0)
+ goto err_disable_clks;
+ else
+ goto err_exit_phy;
You don't need this "if" statement. Just goto err_exit_phy always; it
will do the right thing.
+ }
+ ret = phy_power_on(&priv->phys[phy_num]);
+ if (ret) {
+ phy_exit(&priv->phys[phy_num]);
goto err_exit_phy;
+ }
}
return 0;
err_exit_phy:
- phy_exit(priv->phy);
+ while (--phy_num >= 0) {
+ phy_power_off(&priv->phys[phy_num]);
+ phy_exit(&priv->phys[phy_num]);
+ };
err_disable_clks:
while (--clk >= 0)
clk_disable_unprepare(priv->clks[clk]);
@@ -94,11 +103,11 @@ static void ohci_platform_power_off(struct platform_device
*dev)
{
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
- int clk;
+ int clk, phy_num;
- if (priv->phy) {
- phy_power_off(priv->phy);
- phy_exit(priv->phy);
+ for (phy_num = 0; phy_num < priv->num_phys; phy_num++) {
+ phy_power_off(&priv->phys[phy_num]);
+ phy_exit(&priv->phys[phy_num]);
}
for (clk = OHCI_MAX_CLKS - 1; clk >= 0; clk--)
@@ -127,7 +136,9 @@ static int ohci_platform_probe(struct platform_device *dev)
struct usb_ohci_pdata *pdata = dev_get_platdata(&dev->dev);
struct ohci_platform_priv *priv;
struct ohci_hcd *ohci;
- int err, irq, clk = 0;
+ struct phy *temp_phy;
+ const char *phy_name;
+ int err, irq, phy_num, clk = 0;
if (usb_disabled())
return -ENODEV;
@@ -175,12 +186,29 @@ static int ohci_platform_probe(struct platform_device
*dev)
if (of_property_read_bool(dev->dev.of_node, "big-endian"))
ohci->flags |= OHCI_QUIRK_BE_MMIO | OHCI_QUIRK_BE_DESC;
- priv->phy = devm_phy_get(&dev->dev, "usb");
- if (IS_ERR(priv->phy)) {
- err = PTR_ERR(priv->phy);
- if (err == -EPROBE_DEFER)
- goto err_put_hcd;
- priv->phy = NULL;
+ priv->num_phys = of_count_phandle_with_args
+ (dev->dev.of_node, "phys", "#phy-cells");
It's things like this that make me question whether this patch will
work correctly. What about systems that don't use OF but do use
devm_phy_get()?
Also, the line break is at a strange place (just before the open paren
of a function call), and the indentation of the continuation line is
unusual.
+ if (priv->num_phys > 0) {
+ priv->phys = devm_kcalloc(&dev->dev, priv->num_phys,
+
Re: [PATCH 3/4] usb: xhci: plat: Add USB phy support
Hello.
On 01/06/2015 06:45 PM, Maxime Ripard wrote:
The Marvell Armada 385 AP needs a dumb phy in order to enable the USB3 VBUS.
Add a call to retrieve a USB PHY to XHCI plat in order to support this.
Signed-off-by: Maxime Ripard
[...]
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index cc7c5bb7cbcf..d9468af2a8e4 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1474,6 +1474,8 @@ struct xhci_hcd {
struct msix_entry *msix_entries;
/* optional clock */
struct clk *clk;
+ /* optional phy */
+ struct usb_phy *phy;
Can't you reuse the one in 'struct usb_hcd'?
[...]
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Use memzero_explicit to clear local buffers
On Mon, Jan 05, 2015 at 10:36:37 +1100, Herbert Xu wrote: > On Sun, Jan 04, 2015 at 11:49:09PM +0100, Giel van Schijndel wrote: >> >>> sctx does not point to stack memory so this is bogus. >>> >>> Only stack memory cleared just before it goes out of scope needs >>> memzero_explicit. >> >> Is that because the compiler can't safely optimize memset(0) away for a >> variable with greater-than-local scope? > > Exactly. memzero_explicit is not a marker for sensitive data. > Its only purpose is to prevent the compiler from optimising away > zeroing that occurs at the end of a scope. Question: are you sure the compiler won't optimize the call to memset(0) way if it's immediately followed by kfree()? Because one of my changes concerns that situation. Another actually does change a stack-allocated buffer, I'll split that one off right away. -- Met vriendelijke groet, With kind regards, Giel van Schijndel -- "When all you have is a hammer, everything starts to look like a nail." -- Abraham Maslow signature.asc Description: Digital signature
[PATCH] usb: gadget: udc: avoid dereference before NULL check in ep_queue
Coverity: CID 1260069 Signed-off-by: John W. Linville --- drivers/usb/gadget/udc/bdc/bdc_ep.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/bdc/bdc_ep.c b/drivers/usb/gadget/udc/bdc/bdc_ep.c index ff67ceac77c4..d4fe8d769bd6 100644 --- a/drivers/usb/gadget/udc/bdc/bdc_ep.c +++ b/drivers/usb/gadget/udc/bdc/bdc_ep.c @@ -718,10 +718,11 @@ static int ep_queue(struct bdc_ep *ep, struct bdc_req *req) struct bdc *bdc; int ret = 0; - bdc = ep->bdc; if (!req || !ep || !ep->usb_ep.desc) return -EINVAL; + bdc = ep->bdc; + req->usb_req.actual = 0; req->usb_req.status = -EINPROGRESS; req->epnum = ep->ep_num; -- 2.1.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: kernel panic with USB3+DVB+ARM
Am 06.01.2015 um 18:38 schrieb Greg KH:
> On Tue, Jan 06, 2015 at 11:47:29AM +0100, JPT wrote:
>> Hi Greg
>>
>> Am 06.01.2015 um 02:54 schrieb Greg KH:
>>>
>>> Is that where the kernel panics show the problem happens? Without them,
>>> there's nothing we can do to help out except randomly guess, sorry.
>>
>> well. at least xhci is contained in the call stack:
>>
>>> [] (crc32_be) from [] (dvb_dmx_crc32+0x10/0x18
>>> [dvb_core])
>>> [] (dvb_dmx_crc32 [dvb_core]) from []
>>> (dvb_dmx_swfilter_section_copy_dump+0x254/0x268 [dvb_core])
>>> [] (dvb_dmx_swfilter_section_copy_dump [dvb_core]) from
>>> [] (dvb_dmx_swfilter_packet+0x45c/0x564 [dvb_core])
>>> [] (dvb_dmx_swfilter_packet [dvb_core]) from []
>>> (dvb_dmx_swfilter+0xf4/0x164 [dvb_core])
>>> [] (dvb_dmx_swfilter [dvb_core]) from []
>>> (usb_urb_complete+0xbc/0xe4 [dvb_usb])
>>> [] (usb_urb_complete [dvb_usb]) from []
>>> (__usb_hcd_giveback_urb+0x5c/0xe8)
>>> [] (__usb_hcd_giveback_urb) from []
>>> (xhci_irq+0x8d8/0x1e08)
>>> [] (xhci_irq) from []
>>> (handle_irq_event_percpu+0x78/0x140)
>>> [] (handle_irq_event_percpu) from []
>>> (handle_irq_event+0x28/0x38)
>>> [] (handle_irq_event) from []
>>> (handle_simple_irq+0x64/0xa8)
>>> [] (handle_simple_irq) from []
>>> (generic_handle_irq+0x2c/0x3c)
>>> [] (generic_handle_irq) from [] (handle_IRQ+0x38/0x84)
>>> [] (handle_IRQ) from []
>>> (armada_370_xp_handle_msi_irq+0x9c/0xa0)
>>> [] (armada_370_xp_handle_msi_irq) from []
>>> (armada_370_xp_handle_irq+0x5c/0x60)
>>> [] (armada_370_xp_handle_irq) from []
>>> (__irq_svc+0x40/0x54)
>>
>>
>> It's always the same stack, but different errors:
>>
>> kernelpanic0.log: Unhandled prefetch abort: unknown 25 (0x409) at 0xc02fc948
>> kernelpanic0.log: Internal error: : 409 [#1] ARM
>>
>> kernelpanic1.log: Unhandled prefetch abort: unknown 25 (0x409) at 0xc02fc948
>> kernelpanic1.log: Internal error: : 409 [#1] ARM
>>
>> kernelpanic2.log: Internal error: Oops: 815 [#1] ARM
>>
>> kernelpanic3.log: Unhandled prefetch abort: unknown 25 (0x409) at 0xc0301228
>> kernelpanic3.log: Internal error: : 409 [#1] ARM
>>
>> kernelpanic4.log: Unhandled prefetch abort: unknown 0 (0x000) at 0xc0301228
>> kernelpanic4.log: Internal error: : 0 [#1] ARM
>>
>>
>> I added a printk to dvb_dmx_crc32() (see dvb.log). This probably
>> introduced more problems, because irq code has to be fast?
>> During recording through USB2 this code made the system not crash but it
>> wasn't able to answer any request (SSH, HTTP, login from serial console ...)
>>
>>
>> Is this info useful?
>> I attached only one of the kernel panic logs. If you would like to see
>> the others, please tell me.
>> I am not sure if the dvb.log tells something of worth at all.
>>
>>
>> Jan
>
>> [ 57.646235] dvb_dmx_crc32(dvb_demux_feed e0d4b13c, src: e0d4b154, len 18
>> [ 57.688218] dvb_dmx_crc32(dvb_demux_feed e0d4d3b4, src: e0d4d3cc, len 97
>> [ 57.695163] dvb_dmx_crc32(dvb_demux_feed e0d4a000, src: e0d4a018, len 28
>> [ 57.702105] xhci_hcd :01:00.0: ERROR Unknown event condition, HC
>> probably busted
>> [ 57.709920] xhci_hcd :01:00.0: ERROR Unknown event condition, HC
>> probably busted
>> [ 57.717924] xhci_hcd :01:00.0: ERROR Unknown event condition, HC
>> probably busted
>> [ 57.725728] xhci_hcd :01:00.0: ERROR Unknown event condition, HC
>> probably busted
>
> Those messages look kind of important, right? :)
well yes. But I think I did not have them without the printk in
dvb_dmx_crc32().
> Perhaps something is wrong with your hardware, you are using the 3.17
> kernel release, does this also happen on 3.18?
yes, the captured logs are from:
kernelpanic0.log: 3.17.2-rn104-jpt9
kernelpanic1.log: 3.17.2-rn104-jpt10
kernelpanic2.log: 3.17.2-rn104-jpt10
kernelpanic3.log: 3.18.1-rn104-jpt1
kernelpanic4.log: 3.18.1-rn104-jpt1
> Do you have any xhci
> patches in your tree for this specific ARM hardware?
No. Not any.
Only patch is
.isoc = {
- .framesperurb = 32,
+ .framesperurb = 8,
.framesize = 2048,
.interval = 1,
}
in drivers/media/usb/dvb-usb/technisat-usb2.c
because else the driver would not have worked because of some
out-of-memory problems. Did not really understand. (where are those
buffers located?)
>> Unhandled prefetch abort: unknown 25 (0x409) at 0xc02fc948
>> Internal error: : 409 [#1] ARM
>
> I don't know enough about arm, but this looks like some odd hardware
> issue, and not a "normal" kernel oops report, right?
Well, I don't know. If you say so...
My knowledge dates back to MSDOS and ralph brown's interrupt list ;)
Haven't got any idea about how USB works, nor kernel panics/oops
I don't expect this code to be thoroughly tested on an arm system.
(especially DVB)
So the stack trace doesn't tell you anything useful?!
Is there anything else I can do to find out more?
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.or
Re: [PATCH] Use memzero_explicit to clear local buffers
On Tue, Jan 06, 2015 at 08:42:26PM +0100, Giel van Schijndel wrote: > > Question: are you sure the compiler won't optimize the call to memset(0) > way if it's immediately followed by kfree()? Yes it won't be optimised away. However, you could use kzfree. > Another actually does change a stack-allocated buffer, I'll split that > one off right away. OK. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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: qcserial/option: make AT URCs work for Sierra Wireless MC73xx
As has been discussed in the thread starting with
https://lkml.kernel.org/g/549748e9.d+sijzqu50f1r4lsal043...@arcor.de
Sierra Wireless MC73xx devices with USB VID/PID 0x1199:0x68c0 require the
option_send_setup() code to be used on the USB interface for the AT port
to make unsolicited response codes work correctly. Move these devices from
the qcserial driver where they have been added by commit
70a3615fc07c2330ed7c1e922f3c44f4a67c0762 ("usb: qcserial: add Sierra Wireless
MC73xx") to the option driver and add a MC73xx-specific blacklist
to ensure that
1. the sendsetup code is not used for the DIAG/DM and NMEA interfaces
2. the option driver does not attach to the QMI/network interfaces
Signed-off-by: Reinhard Speyerer
---
diff -uprN linux-3.19-rc3/drivers/usb/serial/option.c
linux-3.19-rc3-mc73xx-at-urcs/drivers/usb/serial/option.c
--- linux-3.19-rc3/drivers/usb/serial/option.c 2015-01-06 02:05:20.0
+0100
+++ linux-3.19-rc3-mc73xx-at-urcs/drivers/usb/serial/option.c 2015-01-06
20:17:31.875929978 +0100
@@ -234,6 +234,8 @@ static void option_instat_callback(struc
#define QUALCOMM_VENDOR_ID 0x05C6
+#define SIERRA_VENDOR_ID 0x1199
+
#define CMOTECH_VENDOR_ID 0x16d8
#define CMOTECH_PRODUCT_6001 0x6001
#define CMOTECH_PRODUCT_CMU_3000x6002
@@ -512,7 +514,7 @@ enum option_blacklist_reason {
OPTION_BLACKLIST_RESERVED_IF = 2
};
-#define MAX_BL_NUM 8
+#define MAX_BL_NUM 11
struct option_blacklist_info {
/* bitfield of interface numbers for OPTION_BLACKLIST_SENDSETUP */
const unsigned long sendsetup;
@@ -601,6 +603,11 @@ static const struct option_blacklist_inf
.reserved = BIT(1) | BIT(5),
};
+static const struct option_blacklist_info sierra_mc73xx_blacklist = {
+ .sendsetup = BIT(0) | BIT(2),
+ .reserved = BIT(8) | BIT(10) | BIT(11),
+};
+
static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
@@ -1098,6 +1105,8 @@ static const struct usb_device_id option
{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */
{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */
{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */
+ { USB_DEVICE_INTERFACE_CLASS(SIERRA_VENDOR_ID, 0x68c0, 0xff),
+ .driver_info = (kernel_ulong_t)&sierra_mc73xx_blacklist }, /* MC73xx
*/
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6003),
diff -uprN linux-3.19-rc3/drivers/usb/serial/qcserial.c
linux-3.19-rc3-mc73xx-at-urcs/drivers/usb/serial/qcserial.c
--- linux-3.19-rc3/drivers/usb/serial/qcserial.c2015-01-06
02:05:20.0 +0100
+++ linux-3.19-rc3-mc73xx-at-urcs/drivers/usb/serial/qcserial.c 2015-01-06
20:20:52.563922911 +0100
@@ -142,7 +142,6 @@ static const struct usb_device_id id_tab
{DEVICE_SWI(0x0f3d, 0x68a2)}, /* Sierra Wireless MC7700 */
{DEVICE_SWI(0x114f, 0x68a2)}, /* Sierra Wireless MC7750 */
{DEVICE_SWI(0x1199, 0x68a2)}, /* Sierra Wireless MC7710 */
- {DEVICE_SWI(0x1199, 0x68c0)}, /* Sierra Wireless MC73xx */
{DEVICE_SWI(0x1199, 0x901c)}, /* Sierra Wireless EM7700 */
{DEVICE_SWI(0x1199, 0x901f)}, /* Sierra Wireless EM7355 */
{DEVICE_SWI(0x1199, 0x9040)}, /* Sierra Wireless Modem */
--
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: [xhci_hcd] USB3 device unplug breaks system suspend
Just a short note that the issue remains with vanilla 3.18.1. Greets, Tobias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/30] usb: updates for dwc2 gadget driver
On 01/06/2015 05:47 PM, Dinh Nguyen wrote: > On 01/05/2015 01:16 PM, Paul Zimmerman wrote: >> Adding Dinh to CC. >> >> Robert, Dinh, I would like to have your tested-bys for this series, please. >> > > This patch series is producing this error on the SOCFPGA platform. I'll > try to bisect to a specific patch. > > root@socfpga_cyclone5:~# [ 47.929743] dwc2 ffb4.usb: new device is > low-speed > [ 63.873596] dwc2 ffb4.usb: new device is low-speed > [ 64.219220] dwc2 ffb4.usb: new device is low-speed > [ 64.421495] dwc2 ffb4.usb: new device is low-speed > [ 64.834505] dwc2 ffb4.usb: new device is high-speed > [ 69.899695] [ cut here ] > [ 69.904315] WARNING: CPU: 0 PID: 0 at drivers/usb/dwc2/gadget.c:1352 > s3c_hsotg_rx_data+0xc0/0xd4() > [ 69.913230] Modules linked in: g_mass_storage usb_f_mass_storage > libcomposite > [ 69.920385] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.19.0-rc1-00090-g4864f14 #4 > [ 69.927917] Hardware name: Altera SOCFPGA > [ 69.931936] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [ 69.939654] [] (show_stack) from [] > (dump_stack+0x74/0x90) > [ 69.946857] [] (dump_stack) from [] > (warn_slowpath_common+0x78/0xb4) > [ 69.954916] [] (warn_slowpath_common) from [] > (warn_slowpath_null+0x1c/0x24) > [ 69.963669] [] (warn_slowpath_null) from [] > (s3c_hsotg_rx_data+0xc0/0xd4) > [ 69.972162] [] (s3c_hsotg_rx_data) from [] > (s3c_hsotg_irq+0x454/0x520) > [ 69.980394] [] (s3c_hsotg_irq) from [] > (handle_irq_event_percpu+0x5c/0x1f4) > [ 69.989056] [] (handle_irq_event_percpu) from [] > (handle_irq_event+0x44/0x64) > [ 69.997892] [] (handle_irq_event) from [] > (handle_fasteoi_irq+0xa8/0x180) > [ 70.006382] [] (handle_fasteoi_irq) from [] > (generic_handle_irq+0x20/0x30) > [ 70.014958] [] (generic_handle_irq) from [] > (__handle_domain_irq+0x54/0xb4) > [ 70.023619] [] (__handle_domain_irq) from [] > (gic_handle_irq+0x20/0x5c) > [ 70.031937] [] (gic_handle_irq) from [] > (__irq_svc+0x40/0x54) > [ 70.039384] Exception stack(0xc0635f60 to 0xc0635fa8) > [ 70.044415] 5f60: c0635fb0 c001cee0 c066cca0 > c063c498 c046908c c066c4b2 > [ 70.052556] 5f80: c066cca0 0001 ef7fccc0 0100 > c0635fa8 c000f0fc c000f100 > [ 70.060694] 5fa0: 600f0013 > [ 70.064174] [] (__irq_svc) from [] > (arch_cpu_idle+0x30/0x3c) > [ 70.071545] [] (arch_cpu_idle) from [] > (cpu_startup_entry+0x138/0x224) > [ 70.079783] [] (cpu_startup_entry) from [] > (start_kernel+0x304/0x35c) > [ 70.087921] ---[ end trace 66b76f6dcbbda3bf ]--- > [ 79.911589] dwc2 ffb4.usb: new device is low-speed > > Dinh > It looks like this patch is producing the above error. usb: dwc2: gadget: manage ep0 state in software Manage ep0 state in software to add handling of status OUT stage. Just toggling hsotg->setup in s3c_hsotg_handle_outdone leaves it in wrong state in 2-stage control transfers. Moreover, don't call s3c_hsotg_handle_outdone both from SetupDone and OutDone. Only use one of them, as for a setup packet we get both. Signed-off-by: Mian Yousaf Kaukab Dinh -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/30] usb: updates for dwc2 gadget driver
On 01/05/2015 01:16 PM, Paul Zimmerman wrote: > Adding Dinh to CC. > > Robert, Dinh, I would like to have your tested-bys for this series, please. > This patch series is producing this error on the SOCFPGA platform. I'll try to bisect to a specific patch. root@socfpga_cyclone5:~# [ 47.929743] dwc2 ffb4.usb: new device is low-speed [ 63.873596] dwc2 ffb4.usb: new device is low-speed [ 64.219220] dwc2 ffb4.usb: new device is low-speed [ 64.421495] dwc2 ffb4.usb: new device is low-speed [ 64.834505] dwc2 ffb4.usb: new device is high-speed [ 69.899695] [ cut here ] [ 69.904315] WARNING: CPU: 0 PID: 0 at drivers/usb/dwc2/gadget.c:1352 s3c_hsotg_rx_data+0xc0/0xd4() [ 69.913230] Modules linked in: g_mass_storage usb_f_mass_storage libcomposite [ 69.920385] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-rc1-00090-g4864f14 #4 [ 69.927917] Hardware name: Altera SOCFPGA [ 69.931936] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 69.939654] [] (show_stack) from [] (dump_stack+0x74/0x90) [ 69.946857] [] (dump_stack) from [] (warn_slowpath_common+0x78/0xb4) [ 69.954916] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) [ 69.963669] [] (warn_slowpath_null) from [] (s3c_hsotg_rx_data+0xc0/0xd4) [ 69.972162] [] (s3c_hsotg_rx_data) from [] (s3c_hsotg_irq+0x454/0x520) [ 69.980394] [] (s3c_hsotg_irq) from [] (handle_irq_event_percpu+0x5c/0x1f4) [ 69.989056] [] (handle_irq_event_percpu) from [] (handle_irq_event+0x44/0x64) [ 69.997892] [] (handle_irq_event) from [] (handle_fasteoi_irq+0xa8/0x180) [ 70.006382] [] (handle_fasteoi_irq) from [] (generic_handle_irq+0x20/0x30) [ 70.014958] [] (generic_handle_irq) from [] (__handle_domain_irq+0x54/0xb4) [ 70.023619] [] (__handle_domain_irq) from [] (gic_handle_irq+0x20/0x5c) [ 70.031937] [] (gic_handle_irq) from [] (__irq_svc+0x40/0x54) [ 70.039384] Exception stack(0xc0635f60 to 0xc0635fa8) [ 70.044415] 5f60: c0635fb0 c001cee0 c066cca0 c063c498 c046908c c066c4b2 [ 70.052556] 5f80: c066cca0 0001 ef7fccc0 0100 c0635fa8 c000f0fc c000f100 [ 70.060694] 5fa0: 600f0013 [ 70.064174] [] (__irq_svc) from [] (arch_cpu_idle+0x30/0x3c) [ 70.071545] [] (arch_cpu_idle) from [] (cpu_startup_entry+0x138/0x224) [ 70.079783] [] (cpu_startup_entry) from [] (start_kernel+0x304/0x35c) [ 70.087921] ---[ end trace 66b76f6dcbbda3bf ]--- [ 79.911589] dwc2 ffb4.usb: new device is low-speed Dinh -- 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] x86: Added support for Japanese Surface Type Cover 3
Based on code for the US Surface Type Cover 3
from commit be3b16341d5cd8cf2a64fcc7a604a8efe6599ff0
("HID: add support for MS Surface Pro 3 Type Cover"):
Signed-off-by: Alan Wu
Tested-by: Karlis Dreizis
---
drivers/hid/hid-core.c | 4 +++-
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-microsoft.c | 2 ++
drivers/hid/usbhid/hid-quirks.c | 1 +
4 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index c3d0ac1..0cea5a0 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -704,7 +704,8 @@ static void hid_scan_collection(struct hid_parser *parser,
unsigned type)
hid->group = HID_GROUP_SENSOR_HUB;
if (hid->vendor == USB_VENDOR_ID_MICROSOFT &&
- hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3 &&
+ (hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3 ||
+hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3_JP) &&
hid->group == HID_GROUP_MULTITOUCH)
hid->group = HID_GROUP_GENERIC;
}
@@ -1860,6 +1861,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_3) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_3_JP) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN)
},
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 7460f34..95ee91b 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -653,6 +653,7 @@
#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
#define USB_DEVICE_ID_MS_TYPE_COVER_20x07a9
#define USB_DEVICE_ID_MS_TYPE_COVER_30x07dc
+#define USB_DEVICE_ID_MS_TYPE_COVER_3_JP 0x07dd
#define USB_VENDOR_ID_MOJO 0x8282
#define USB_DEVICE_ID_RETRO_ADAPTER0x3201
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index cacda43..fbaea6e 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -276,6 +276,8 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_DUPLICATE_USAGES },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_3),
.driver_data = MS_HIDINPUT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_3_JP),
+ .driver_data = MS_HIDINPUT },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_PRESENTER_8K_BT),
.driver_data = MS_PRESENTER },
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index dc89be9..6591b5d 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -80,6 +80,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28,
HID_QUIRK_NOGET },
{ 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 },
{ USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_NEXIO, USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE,
HID_QUIRK_NO_INIT_REPORTS },
--
2.1.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: [PATCH 1/4] usb: phy: Fix deferred probing
Hi,
On Tue, Jan 6, 2015 at 7:45 AM, Maxime Ripard
wrote:
> Commit 1290a958d48e ("usb: phy: propagate __of_usb_find_phy()'s error on
> failure") actually broke the deferred probing mechanism, since it now returns
> EPROBE_DEFER only when the try_module_get call fails, but not when the phy
> lookup does.
>
> All the other similar functions seem to return ENODEV when try_module_get
> fails, and the error code of either __usb_find_phy or __of_usb_find_phy
> otherwise.
>
> In order to have a consistent behaviour, and a meaningful EPROBE_DEFER, always
> return EPROBE_DEFER when __(of_)usb_find_phy fails to look up the requested
> phy, that will be propagated by the caller, and ENODEV if try_module_get
> fails.
>
Fixes: 1290a958d48e ("usb: phy: propagate __of_usb_find_phy()'s error
on failure")
> Signed-off-by: Maxime Ripard
This also fixes USB on tegra/trimslice here.
Tested-by: Olof Johansson
Given that the regression went in during 3.19 merge window, this
should go in as a fix during -rc, please.
-Olof
--
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
