Re: reading data at 500Hz

2015-12-05 Thread Greg KH
On Fri, Dec 04, 2015 at 12:46:14PM +, Jose Colmenares wrote: > Hi, > > I'm using a USB Inertial Measurement Unit that theoretically produces > data at 500Hz. According to the timestamps on the data, indeed the > data is being produced at 500Hz. But I'm getting it in burst, with an > "efective"

Re: [PATCH net,stable] net: cdc_mbim: add "NDP to end" quirk for Huawei E3372

2015-12-05 Thread David Miller
From: Bjørn Mork Date: Sat, 5 Dec 2015 13:01:50 +0100 > The Huawei E3372 (12d1:157d) needs this quirk in MBIM mode > as well. Allow this by forcing the NTB to contain only a > single NDP, and add a device specific entry for this ID. > > Due to the way Huawei use device IDs, this might be applie

Re: Infrastructure for zerocopy I/O

2015-12-05 Thread Steinar H. Gunderson
On Sat, Dec 05, 2015 at 05:12:03PM -0500, Alan Stern wrote: > To tell the truth, I'm not sure whether it would be a problem or not. > That's why I said it "may" not be a good idea. Fair enough. >>> You don't really need to do it earlier. An unnecessary calculation of >>> num_sgs won't hurt. >>

Re: [PATCH V7 1/1] usb:serial: Add Fintek F81532/534 driver

2015-12-05 Thread kbuild test robot
Hi Peter, [auto build test ERROR on usb/usb-testing] [also build test ERROR on v4.4-rc3 next-20151203] url: https://github.com/0day-ci/linux/commits/Peter-Hung/usb-serial-Add-Fintek-F81532-534-driver/20151202-152239 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-t

Re: [PATCH net,stable] net: cdc_mbim: add "NDP to end" quirk for Huawei E3372

2015-12-05 Thread Mrkiko Rs
Unfortunately I found a typo: spefication should be specification. Sorry. Inviato da iPhone > Il giorno 05/dic/2015, alle ore 13:02, "Bjørn Mork" ha > scritto: > > The Huawei E3372 (12d1:157d) needs this quirk in MBIM mode > as well. Allow this by forcing the NTB to contain only a > single NDP,

Re: [PATCH net,stable] net: cdc_mbim: add "NDP to end" quirk for Huawei E3372

2015-12-05 Thread Enrico Mioso
Hello guys. I am sorry the way my feature is actually implemented is limiting MUX performances in mbim case, even with good devices. When I developed it, I also probably tought this wasn't affecting MBIM devices. Thank you Bjorn, great work in handling it. Thank you for all of you; Thank you for

Re: kernel panic while in interrupt handler

2015-12-05 Thread Enrico Mioso
Thank you very much Peter. In case I'll try. thank you. Enrico -- 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: Infrastructure for zerocopy I/O

2015-12-05 Thread Alan Stern
On Sat, 5 Dec 2015, Steinar H. Gunderson wrote: > On Sat, Dec 05, 2015 at 12:36:51PM -0500, Alan Stern wrote: > > I meant that this "if" statement should test only uurb_start. If the > > test succeeds, a nested "if" statement should test buffer_length and > > return an error if it is too big. >

Re: [PATCH] Add support for usbfs zerocopy.

2015-12-05 Thread kbuild test robot
Hi Steinar, [auto build test WARNING on usb/usb-testing] [also build test WARNING on v4.4-rc3 next-20151203] url: https://github.com/0day-ci/linux/commits/Steinar-H-Gunderson/Add-support-for-usbfs-zerocopy/20151206-034258 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git

[linux-review:Steinar-H-Gunderson/Add-support-for-usbfs-zerocopy/20151206-034258] 9ec62035b2d12a9526ac8327b43ca2891f206eec BUILD DONE

2015-12-05 Thread kbuild test robot
https://github.com/0day-ci/linux Steinar-H-Gunderson/Add-support-for-usbfs-zerocopy/20151206-034258 9ec62035b2d12a9526ac8327b43ca2891f206eec Infrastructure for zerocopy I/O drivers/usb/core/devio.c:1617:2: note: in expansion of macro 'if' drivers/usb/core/devio.c:1617:37: warning: comparison be

Re: [PATCH] Add support for usbfs zerocopy.

2015-12-05 Thread kbuild test robot
Hi Steinar, [auto build test WARNING on usb/usb-testing] [also build test WARNING on v4.4-rc3 next-20151203] url: https://github.com/0day-ci/linux/commits/Steinar-H-Gunderson/Add-support-for-usbfs-zerocopy/20151206-034258 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git

Re: [PATCH] Add support for usbfs zerocopy.

2015-12-05 Thread kbuild test robot
Hi Steinar, [auto build test WARNING on usb/usb-testing] [also build test WARNING on v4.4-rc3 next-20151203] url: https://github.com/0day-ci/linux/commits/Steinar-H-Gunderson/Add-support-for-usbfs-zerocopy/20151206-034258 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git

Re: [PATCH] Add support for usbfs zerocopy.

2015-12-05 Thread kbuild test robot
Hi Steinar, [auto build test WARNING on usb/usb-testing] [also build test WARNING on v4.4-rc3 next-20151203] url: https://github.com/0day-ci/linux/commits/Steinar-H-Gunderson/Add-support-for-usbfs-zerocopy/20151206-034258 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git

Re: Infrastructure for zerocopy I/O

2015-12-05 Thread Steinar H. Gunderson
On Sat, Dec 05, 2015 at 12:36:51PM -0500, Alan Stern wrote: > I meant that this "if" statement should test only uurb_start. If the > test succeeds, a nested "if" statement should test buffer_length and > return an error if it is too big. > > That's as opposed to the way you have it now, where i

Re: Infrastructure for zerocopy I/O

2015-12-05 Thread Alan Stern
On Sat, 5 Dec 2015, Steinar H. Gunderson wrote: > > (Yes, I did.) On further thought, testing uurb_start is sufficient. > > If uurb->buffer_length then turns out to be too big, the function > > should return an error (or rather, an ERR_PTR) and the URB submission > > should fail. > > I don't und

Re: Infrastructure for zerocopy I/O

2015-12-05 Thread Steinar H. Gunderson
On Wed, Dec 02, 2015 at 10:54:52AM -0500, Alan Stern wrote: > Well, it's partly a matter of taste. But there's also a race: This > code adds usbm to ps->memory_list (making it available to URB > submissions running on other CPUs) before usbm has been completely > initialized (vm_start isn't set

Re: [PATCH v6 1/4] gadget: Introduce the usb charger framework

2015-12-05 Thread Sebastian Reichel
Hi, On Mon, Nov 16, 2015 at 02:33:31PM +0800, Baolin Wang wrote: > +static ssize_t cur_limit_show(struct device *dev, > + struct device_attribute *attr, > + char *buf) > +{ > + struct usb_charger *uchger = dev_to_uchger(dev); > + > + retu

Re: [PATCH v4] USB: serial: add Moxa UPORT 11x0 driver

2015-12-05 Thread Johan Hovold
On Wed, Nov 11, 2015 at 10:35:47AM +0100, Mathieu OTHACEHE wrote: > Add a driver which supports : > > - UPort 1110 : 1 port RS-232 USB to Serial Hub. > - UPort 1130 : 1 port RS-422/485 USB to Serial Hub. > - UPort 1130I : 1 port RS-422/485 USB to Serial Hub with Isolation. > - UPort 1150 : 1 po

[PATCH 1/2] USB: bcma: make helper creating platform dev more generic

2015-12-05 Thread Rafał Miłecki
Having "bool ohci" argument in bcma_hcd_create_pdev function limited it to support two cases only (OHCI and EHCI) and put too much logic in it. Lets make caller pass all required data. This adds few extra arguments to the function call but will allow us to reuse this code and handle more cases in t

[PATCH 2/2] USB: bcma: separate code initializing USB 2.0 core

2015-12-05 Thread Rafał Miłecki
This splits one big probing function into two smaller ones. The main one is now responsible for the generic stuff: allocating memory & enabling power using GPIO. The new one contains code that is specific to the USB 2.0 bcma core. This will allow adding support for the USB 3.0 bcma core (handling X

[PATCH net,stable] net: cdc_mbim: add "NDP to end" quirk for Huawei E3372

2015-12-05 Thread Bjørn Mork
The Huawei E3372 (12d1:157d) needs this quirk in MBIM mode as well. Allow this by forcing the NTB to contain only a single NDP, and add a device specific entry for this ID. Due to the way Huawei use device IDs, this might be applied to other modems as well. It is assumed that those modems will be

(4.3.0) r8152: deadlock related to runtime suspend?

2015-12-05 Thread Peter Wu
Hi, I rarely use a Realtek USB 3.0 Gigabit Ethernet adapter (vid/pid 0bda:8153), but when I did last night, it resulted in a lockup of processes doing networking ("ip link", "ping", "ethtool", ...). A (few) minute(s) before that event, I noticed that there was no network connectivity (ping hung)