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"
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
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.
>>
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
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,
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
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
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.
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
22 matches
Mail list logo