Re: [PATCH v12 0/7] PHY framework
On Saturday 28 September 2013 06:07 AM, Greg KH wrote: On Fri, Sep 27, 2013 at 11:53:24AM +0530, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. If the PHY driver has to send notification on connect/disconnect, the PHY driver should make use of the extcon framework. Using this susbsystem to use extcon framwork will have to be analysed. You can find this patch series @ git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing I'll create a new branch *next* once this patch series is finalized. All the PHY driver development that depends on PHY framework can be based on this branch. Did USB enumeration testing in panda and beagle after applying [1] (needed for non-dt) All now applied to my usb-next branch. Thanks for redoing this many times and sticking with it. Thanks :-) -Kishon -- 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] Memory mapping for USBFS
On Sat, Sep 28, 2013 at 4:39 AM, Ming Lei tom.leim...@gmail.com wrote: On Sat, Sep 28, 2013 at 10:29 AM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 28 Sep 2013, Ming Lei wrote: On Wed, Sep 25, 2013 at 3:12 AM, Markus Rechberger mrechber...@gmail.com wrote: This patch adds memory mapping support to USBFS for isochronous and bulk data transfers, it allows to pre-allocate usb transfer buffers. The CPU usage decreases 1-2% on my 1.3ghz U7300 notebook when transferring 20mbyte/sec, it should be more interesting to see those statistics on embedded systems where copying data is more expensive. Given USB3 is becoming popular and throughput is increased much, zero copy should be charming. And another approach is to use direct I/O method(SG DMA to pages allocated to user space directly), which should be more flexible, and user don't need to use mmap/munmap, so should be easier to use. At least, wrt. usb mass storage test, both CPU utilization and throughput can be improved with direct I/O. For zero-copy to work, on many systems the pages have to be allocated in the first 4 GB of physical memory. How can the userspace program It depends if device can DMA to/from 4GB above physical memory. make sure this will happen? That can't be guaranteed but we can handle it with page bounce, just like block device. Actually I observed both throughput and cpu utilization can be improved with the 4GB of DMA limit on either 32bit arch or 64bit arch, wrt. direct I/O over usb mass storage block device. I didn't look into the sg API in detail yet, but isn't it doing a copy_to_user still? The current patch only takes care about the transfer_buffer, another one would focus on pre-allocating and re-using the URBs. This is a similar way as it happens on MacOSX. Markus Thanks, -- Ming Lei -- 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] Regression fix revert: Bluetooth: Add missing reset_resume dev_pm_ops
Many btusb devices have 2 modes, a hid mode and a bluetooth hci mode. These
devices default to hid mode for BIOS use. This means that after having been
reset they will revert to HID mode, and are no longer usable as a HCI.
Therefor it is a very bad idea to just blindly make reset_resume point to
the regular resume handler. Note that the btusb driver has no clue how to
switch these devices from hid to hci mode, this is done in userspace through
udev rules, so the proper way to deal with this is to not have a reset-resume
handler and instead let the usb-system re-enumerate the device, and re-run
the udev rules.
I must also note, that the commit message for the commit causing this
problem has a very weak motivation for the change:
Add missing reset_resume dev_pm_ops. Missing reset_resume results in the
following message after power management device test. This change sets
reset_resume to btusb_resume().
[ 2506.936134] btusb 1-1.5:1.0: no reset_resume for driver btusb?
[ 2506.936137] btusb 1-1.5:1.1: no reset_resume for driver btusb?
Making a change solely to silence a warning while also changing important
behavior (normal resume handling versus re-enumeration) requires a commit
message with a proper explanation why it is safe to do so, which clearly lacks
here, and unsurprisingly it turns out to not be safe to make this change.
Reverting the commit in question fixes bt no longer working on my Dell
E6430 after a suspend/resume, and I believe it likely also fixes the
following bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=988481
https://bugzilla.redhat.com/show_bug.cgi?id=1010649
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1213239
This reverts commit 502f769662978a2fe99d0caed5e53e3006107381.
Cc: Shuah Khan shuah...@samsung.com
Cc: Gustavo Padovan gustavo.pado...@collabora.co.uk
Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/bluetooth/btusb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 8e16f0a..d0b3d90 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1623,7 +1623,6 @@ static struct usb_driver btusb_driver = {
#ifdef CONFIG_PM
.suspend= btusb_suspend,
.resume = btusb_resume,
- .reset_resume = btusb_resume,
#endif
.id_table = btusb_table,
.supports_autosuspend = 1,
--
1.8.3.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] Memory mapping for USBFS
On Sat, 28 Sep 2013, Ming Lei wrote: On Sat, Sep 28, 2013 at 10:29 AM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 28 Sep 2013, Ming Lei wrote: On Wed, Sep 25, 2013 at 3:12 AM, Markus Rechberger mrechber...@gmail.com wrote: This patch adds memory mapping support to USBFS for isochronous and bulk data transfers, it allows to pre-allocate usb transfer buffers. The CPU usage decreases 1-2% on my 1.3ghz U7300 notebook when transferring 20mbyte/sec, it should be more interesting to see those statistics on embedded systems where copying data is more expensive. Given USB3 is becoming popular and throughput is increased much, zero copy should be charming. And another approach is to use direct I/O method(SG DMA to pages allocated to user space directly), which should be more flexible, and user don't need to use mmap/munmap, so should be easier to use. At least, wrt. usb mass storage test, both CPU utilization and throughput can be improved with direct I/O. For zero-copy to work, on many systems the pages have to be allocated in the first 4 GB of physical memory. How can the userspace program It depends if device can DMA to/from 4GB above physical memory. Very few non-xHCI controllers can do DMA above the 4 GB limit. make sure this will happen? That can't be guaranteed but we can handle it with page bounce, just like block device. Obviously. But if we have to bounce the pages, it isn't zero-copy any more. Actually I observed both throughput and cpu utilization can be improved with the 4GB of DMA limit on either 32bit arch or 64bit arch, wrt. direct I/O over usb mass storage block device. This may depend more on the host controller capabilities than on the CPU architecture. 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] Memory mapping for USBFS
On Sat, 28 Sep 2013, Markus Rechberger wrote: Actually I observed both throughput and cpu utilization can be improved with the 4GB of DMA limit on either 32bit arch or 64bit arch, wrt. direct I/O over usb mass storage block device. I didn't look into the sg API in detail yet, but isn't it doing a copy_to_user still? SG has nothing to do with moving data to or from userspace. The copy_to_user takes place in usbfs, not in the SG code. See copy_urb_data_to_user() in devio.c. 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] Memory mapping for USBFS
On Sat, Sep 28, 2013 at 3:45 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 28 Sep 2013, Markus Rechberger wrote: Actually I observed both throughput and cpu utilization can be improved with the 4GB of DMA limit on either 32bit arch or 64bit arch, wrt. direct I/O over usb mass storage block device. I didn't look into the sg API in detail yet, but isn't it doing a copy_to_user still? SG has nothing to do with moving data to or from userspace. The copy_to_user takes place in usbfs, not in the SG code. See copy_urb_data_to_user() in devio.c. that's what I thought about. How about the initial patch, is it okay so far? There's a settopbox manufacturer who pushed it to his next firmware release so we can do some additional performance measuring as well. My next step would be to eliminate the kmallocs/kfrees for the single urbs (just by allocating the urbs with the same mechanism and passing the returned pointer to SUBMIT_URB). Markus -- 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] Memory mapping for USBFS
On Sat, Sep 28, 2013 at 9:38 PM, Alan Stern st...@rowland.harvard.edu wrote: Very few non-xHCI controllers can do DMA above the 4 GB limit. Yes, but I am wondering non-xHCI need this kind of zero copy optimization, since very few user space drivers complain or care performance or cpu utilization when devices attach to non xHCI. make sure this will happen? actually That can't be guaranteed but we can handle it with page bounce, just like block device. Obviously. But if we have to bounce the pages, it isn't zero-copy any more. Suppose the optimization is mainly for xHCI, there should be no such problem. The problem only exists when non-xHCI is used and system has more than 4GB memory, which looks not a mainstream configuration. I propose the idea only for comparing the two approaches, and each one has its own advantage and disadvantage, maybe the two can coexist. mmap approach: - interface is a bit complicated, each URB need usbfs to allocate one buffer - not easy to scale well if the buffer need to be very big for obtaining good performance direct i/o approach: - interface is simple, maybe passing O_DIRECT to open() should be enough - if HCD can't DMA to 4GB above memory, part of 4GB above pages need to be bounced. Actually I observed both throughput and cpu utilization can be improved with the 4GB of DMA limit on either 32bit arch or 64bit arch, wrt. direct I/O over usb mass storage block device. This may depend more on the host controller capabilities than on the CPU architecture. Yes, but for most cases, more than 4GB ram is seldom used in 32bit CPU. Thanks, -- Ming Lei -- 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] Memory mapping for USBFS
On Sat, 28 Sep 2013, Markus Rechberger wrote: How about the initial patch, is it okay so far? I haven't had time to look through it yet. There's a settopbox manufacturer who pushed it to his next firmware release so we can do some additional performance measuring as well. My next step would be to eliminate the kmallocs/kfrees for the single urbs (just by allocating the urbs with the same mechanism and passing the returned pointer to SUBMIT_URB). The time spent allocating and freeing URBs is probably pretty small. 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] Memory mapping for USBFS
On Sat, Sep 28, 2013 at 5:17 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 28 Sep 2013, Markus Rechberger wrote: How about the initial patch, is it okay so far? I haven't had time to look through it yet. There's a settopbox manufacturer who pushed it to his next firmware release so we can do some additional performance measuring as well. My next step would be to eliminate the kmallocs/kfrees for the single urbs (just by allocating the urbs with the same mechanism and passing the returned pointer to SUBMIT_URB). The time spent allocating and freeing URBs is probably pretty small. pre-allocating should at least solve those issues: http://support.sundtek.com/index.php/topic,1097.msg7780.html#msg7780 but now when looking closer SG support can disable the support for shared memory support for bulk transfers. It should be possible to turn off SG Support in favor of pre-allocating the buffers (or preallocate the buffers for SG). This problem happened several times on Sheevaplug ARM systems from Marvell. Markus 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] Memory mapping for USBFS
On Sat, 28 Sep 2013, Markus Rechberger wrote: My next step would be to eliminate the kmallocs/kfrees for the single urbs (just by allocating the urbs with the same mechanism and passing the returned pointer to SUBMIT_URB). The time spent allocating and freeing URBs is probably pretty small. pre-allocating should at least solve those issues: http://support.sundtek.com/index.php/topic,1097.msg7780.html#msg7780 As far as I can tell, that bug report isn't related to URB allocation. It looks like the failure occurred when allocating memory for the transfer buffer, not when allocating memory for the URB. but now when looking closer SG support can disable the support for shared memory support for bulk transfers. I don't know what you're talking about. What has shared memory got to do with SG or anything else we are discussing? It should be possible to turn off SG Support in favor of pre-allocating the buffers (or preallocate the buffers for SG). Only if the buffer can be allocated as a single contiguous region of memory, in which case SG wouldn't be needed anyway. This problem happened several times on Sheevaplug ARM systems from Marvell. I don't see what difference the platform or architecture would make. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: OHCI: Check the overrides pointer for NULL in ohci_init_driver()
A series of commit starting at
50a97e059b USB: OHCI: make ohci-exynos a separate driver
and ending at
b8ad5c3706 USB: OHCI: make ohci-pxa27x a separate driver
introduced the concept of separate OHCI drivers for particular
controllers. Respective drivers need to call ohci_init_driver() to
initialize hc_driver struct with generic data and to certain extent
with platform specific overrides through ohci_driver_overrides struct
passed as second argument to this function. However the code does not
check if the ohci_driver_overrides struct pointer is non-NULL, which
leads for a NULL pointer dereference for drivers that do not need any
overrides.
This patch fixes the problem by dereferencing the passed pointer to
ohci_driver_overrides struct only if it is non-NULL.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
drivers/usb/host/ohci-hcd.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 21d937a..8ada13f 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1161,10 +1161,12 @@ void ohci_init_driver(struct hc_driver *drv,
/* Copy the generic table to drv and then apply the overrides */
*drv = ohci_hc_driver;
- drv-product_desc = over-product_desc;
- drv-hcd_priv_size += over-extra_priv_size;
- if (over-reset)
- drv-reset = over-reset;
+ if (over) {
+ drv-product_desc = over-product_desc;
+ drv-hcd_priv_size += over-extra_priv_size;
+ if (over-reset)
+ drv-reset = over-reset;
+ }
}
EXPORT_SYMBOL_GPL(ohci_init_driver);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH: Ignore card reader interface on Huawei E1750
Hi,
my Huawei 3G modem has an embedded Smart Card reader which causes trouble when
the modem is being detected (a bunch of warn (ttyUSBx): open blocked by
driver for more than 7 seconds! in messages.log). This trivial patch corrects
the problem for me. The modem identifies itself as 12d1:1406 Huawei
Technologies Co., Ltd. E1750 in lsusb although the description on the body
says Model E173u-1
Signed-off-by: Michal Malý madcatxs...@prifuk.cz
---
From 23a299737cb1d986e5e5829d61e048f5cf2c01bf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michal=20Mal=C3=BD?= madcatxs...@prifuk.cz
Date: Sat, 28 Sep 2013 18:15:28 +0200
Subject: [PATCH] Ignore card reader interface on Huawei E1750 (PID 1406)
---
drivers/usb/serial/option.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 1cf6f12..80a7104 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -81,6 +81,7 @@ static void option_instat_callback(struct urb *urb);
#define HUAWEI_VENDOR_ID 0x12D1
#define HUAWEI_PRODUCT_E1730x140C
+#define HUAWEI_PRODUCT_E1750 0x1406
#define HUAWEI_PRODUCT_K4505 0x1464
#define HUAWEI_PRODUCT_K3765 0x1465
#define HUAWEI_PRODUCT_K4605 0x14C6
@@ -567,6 +568,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1c23,
USB_CLASS_COMM, 0x02, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E173,
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t) net_intf1_blacklist },
+ { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1750,
0xff, 0xff, 0xff),
+ .driver_info = (kernel_ulong_t) net_intf2_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1441,
USB_CLASS_COMM, 0x02, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1442,
USB_CLASS_COMM, 0x02, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4505,
0xff, 0xff, 0xff),
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cannot shutdown power use from built in webcam in thinkpad T530 questions]
On Mon, Sep 23, 2013 at 10:21:23AM +0200, Oleksij Rempel wrote: Understood, just making sure this was still potentially useful considering what I found out since my last message. Which version of powertop are you actually using? None of current The latest, i.e. 2.4. versions would show you Watt usage for devices. Sure it does :) Summary: 3182.2 wakeups/second, 82.5 GPU ops/seconds, 0.0 VFS ops/sec and 33.5% Power est. Usage Events/sCategory Description 9.82 W100.0% Device USB device: Yubico Yubike 2.67 W 4.1 ms/s 43.2Process/usr/bin/pulseaudio --sta 2.58 W100.0% Device USB device: Integrated Ca 2.35 W100.0% Device USB device: BCM20702A0 (B 2.32 W 32.9% Device Display backlight 1.39 W100.0% Device Radio device: btusb 343 mW100.0% Device Radio device: thinkpad_ac Now, I've found those values to be often wrong or questionable. you can use watch grep . * instead and check fallowing fields: runtime_suspended_time - suspend time. If it is growing device is suspended runtime_active_kids - if not zero, some program use it control - if on then autosuspend is disabled. Understood. Thanks, Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ -- 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] Memory mapping for USBFS
On Sat, Sep 28, 2013 at 7:43 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 28 Sep 2013, Markus Rechberger wrote: My next step would be to eliminate the kmallocs/kfrees for the single urbs (just by allocating the urbs with the same mechanism and passing the returned pointer to SUBMIT_URB). The time spent allocating and freeing URBs is probably pretty small. pre-allocating should at least solve those issues: http://support.sundtek.com/index.php/topic,1097.msg7780.html#msg7780 As far as I can tell, that bug report isn't related to URB allocation. It looks like the failure occurred when allocating memory for the transfer buffer, not when allocating memory for the URB. That's what I mean, URB pre-allocation would just be for having it complete (the same is available on MacOSX), if it's not wanted I don't mind either. At the time the bugreport was made in our forum we were allocating around 15k buffers, it happened during runtime so it worked for some time and then stopped with those allocation problems. I hope the SG transfer does not introduce any latency issues we have some usb chipsets which are very picky about latency issues on embedded systems. We got it work by tuning the transfer size, if the timings are not met the device will just disable the transfer. Unfortunately it will take a second to detect that by the driver and re-enabling the transfer which means that it will corrupt the data. I do not have a good feeling about pushing SG transfers into the kernel by modifying the legacy mode without having any experience with it. While the idea behind SG transfers is definitely ok but who knows how it will perform with such devices. but now when looking closer SG support can disable the support for shared memory support for bulk transfers. I don't know what you're talking about. What has shared memory got to do with SG or anything else we are discussing? sorry I probably picked the wrong words for that. It should be possible to turn off SG Support in favor of pre-allocating the buffers (or preallocate the buffers for SG). Only if the buffer can be allocated as a single contiguous region of memory, in which case SG wouldn't be needed anyway. This problem happened several times on Sheevaplug ARM systems from Marvell. I don't see what difference the platform or architecture would make. 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: Cannot shutdown power use from built in webcam in thinkpad T530 questions]
Am 28.09.2013 20:08, schrieb Marc MERLIN:
On Mon, Sep 23, 2013 at 10:21:23AM +0200, Oleksij Rempel wrote:
Understood, just making sure this was still potentially useful considering
what I found out since my last message.
Which version of powertop are you actually using? None of current
The latest, i.e. 2.4.
versions would show you Watt usage for devices.
Sure it does :)
Summary: 3182.2 wakeups/second, 82.5 GPU ops/seconds, 0.0 VFS ops/sec and
33.5%
Power est. Usage Events/sCategory Description
9.82 W100.0% Device USB device: Yubico
Yubike
2.67 W 4.1 ms/s 43.2Process/usr/bin/pulseaudio
--sta
2.58 W100.0% Device USB device: Integrated
Ca
2.35 W100.0% Device USB device: BCM20702A0
(B
2.32 W 32.9% Device Display backlight
1.39 W100.0% Device Radio device: btusb
343 mW100.0% Device Radio device:
thinkpad_ac
ah ok, i see, you right. In usb.cpp:
double usbdevice::power_usage(struct result_bundle *result, struct
parameter_bundle *bundle)
{
double power;
double factor;
double util;
if (rootport || !cached_valid)
return 0.0;
power = 0;
factor = get_parameter_value(index, bundle);
util = get_result_value(r_index, result);
power += util * factor / 100.0;
return power;
}
but, if i understand it correctly, this values are not provided by usb.
If you start powertop --calibrate it will switch on/off some devices
and measure global power usage.
--
Regards,
Oleksij
--
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 v1] USBNET: fix handling padding packet
From: Ming Lei ming@canonical.com Date: Mon, 23 Sep 2013 20:59:35 +0800 Commit 638c5115a7949(USBNET: support DMA SG) introduces DMA SG if the usb host controller is capable of building packet from discontinuous buffers, but missed handling padding packet when building DMA SG. This patch attachs the pre-allocated padding packet at the end of the sg list, so padding packet can be sent to device if drivers require that. Reported-by: David Laight david.lai...@aculab.com Acked-by: Oliver Neukum oli...@neukum.org Signed-off-by: Ming Lei ming@canonical.com Applied, thanks. I still think the suggestion to disable scatter gather for devices with the padding issue was the most sane approach to solve this. I guess people like supporting complicated crap and excess code for things that pretty much do not exist, or at best are not prominent enough to cater for at all. -- 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] Memory mapping for USBFS
On Sat, Sep 28, 2013 at 8:52 PM, Markus Rechberger mrechber...@gmail.com wrote: On Sat, Sep 28, 2013 at 8:28 PM, Markus Rechberger mrechber...@gmail.com wrote: On Sat, Sep 28, 2013 at 7:43 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 28 Sep 2013, Markus Rechberger wrote: My next step would be to eliminate the kmallocs/kfrees for the single urbs (just by allocating the urbs with the same mechanism and passing the returned pointer to SUBMIT_URB). The time spent allocating and freeing URBs is probably pretty small. pre-allocating should at least solve those issues: http://support.sundtek.com/index.php/topic,1097.msg7780.html#msg7780 As far as I can tell, that bug report isn't related to URB allocation. It looks like the failure occurred when allocating memory for the transfer buffer, not when allocating memory for the URB. That's what I mean, URB pre-allocation would just be for having it complete (the same is available on MacOSX), if it's not wanted I don't mind either. At the time the bugreport was made in our forum we were allocating around 15k buffers, it happened during runtime so it worked for some time and then stopped with those allocation problems. I hope the SG transfer does not introduce any latency issues we have some usb chipsets which are very picky about latency issues on embedded systems. We got it work by tuning the transfer size, if the timings are not met the device will just disable the transfer. Unfortunately it will take a second to detect that by the driver and re-enabling the transfer which means that it will corrupt the data. I do not have a good feeling about pushing SG transfers into the kernel by modifying the legacy mode without having any experience with it. While the idea behind SG transfers is definitely ok but who knows how it will perform with such devices. I put together a few reports: http://support.sundtek.com/index.php/topic,350.0.html http://support.sundtek.com/index.php/topic,1097.msg7780.html#msg7780 http://support.sundtek.com/index.php/topic,411.msg2153.html#msg2153 http://support.sundtek.com/index.php/topic,531.msg2956.html#msg2956 http://support.sundtek.com/index.php/topic,364.msg1829.html#msg1829 to follow up I know why it doesn't happen anymore because customers are using a kernel module which does optimized transfers and pre-allocated the URBs and transfer buffer in kernelspace, the interface just copies the datastream to our actual driver which sits in userspace. Goal is to get rid of that kernel module which is working around that allocation bug. Allan, Greg, can we add another IOCTL for telling USBFS to not use SG transfers (it also allocates 15k buffers and will lead to the same problem)? The old behavior was already broke, the SG transfers won't improve the situation in that case either. Those Sheevaplugs have 128mb memory, regular routers and NAS systems don't necessarily have more either. they are all about page allocation failure when submitting the URB packet (I agree that it's probably mostly about the 15-16k allocation problem here). They only came up a few times between 2010 - (late) 2012 (we were also able to reproduce this on our Sheevaplug occasionally since we do stronger testing with it I guess). Not sure if that problem still happens, at least it didn't pop up in our forum this year. Markus but now when looking closer SG support can disable the support for shared memory support for bulk transfers. I don't know what you're talking about. What has shared memory got to do with SG or anything else we are discussing? sorry I probably picked the wrong words for that. It should be possible to turn off SG Support in favor of pre-allocating the buffers (or preallocate the buffers for SG). Only if the buffer can be allocated as a single contiguous region of memory, in which case SG wouldn't be needed anyway. This problem happened several times on Sheevaplug ARM systems from Marvell. I don't see what difference the platform or architecture would make. 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: EHCI bus glue driver works for storage, fails for a WiFi module
Dear Alan, I don't know. Did you run all these tests on the same computer? Yes, it is a single board computer, see image here: http://rhombus-tech.net/allwinner_a10/hacking_the_mele_a1000/A10_device_a1000_inside.jpg WLAN Adapter is left at the bottom. What happens if you back-port your glue driver to the vendor's kernel? I have now 200 lines of code which are (almost) identical. They work in vendor's kernel and fail in mainline. This isn't surprising. The errors you are getting are hardware errors, not protocol errors. They could be caused by excessive noise in the USB data lines. Or there could be some sort of timing issue. I've noticed there is ehci-timer.c now. It wasn't present at 3.4 times. The main clock of the SoC I'm working on is running at 24Mhz. There are no hstimers implemented. Do you think it can be the problem? A have tested several other USB devices: keyboard and Ethernet adapter. They worked. I'm not sure whether these test are clean since I connect them to the USB ports which are behind on-board 4-port USB hub. The hub is connected to the first USB host controller. The wifi module however is connected to the second USB host controller directly. Do you have any ideas how can I troubleshoot this issue further? Is there any chance of regression in EHCI stack? Best regards, Arokux -- 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: EHCI bus glue driver works for storage, fails for a WiFi module
On Sun, 29 Sep 2013, Arokux X wrote: What happens if you back-port your glue driver to the vendor's kernel? I have now 200 lines of code which are (almost) identical. They work in vendor's kernel and fail in mainline. This indicates that the problem isn't in your glue driver, but is somewhere else in the kernel. This isn't surprising. The errors you are getting are hardware errors, not protocol errors. They could be caused by excessive noise in the USB data lines. Or there could be some sort of timing issue. I've noticed there is ehci-timer.c now. It wasn't present at 3.4 times. The main clock of the SoC I'm working on is running at 24Mhz. There are no hstimers implemented. Do you think it can be the problem? I tend to doubt it. In the traces you posted, almost every transfer worked. Only a few of them got errors. If timers were a problem then none of the transfers would have worked. A have tested several other USB devices: keyboard and Ethernet adapter. They worked. I'm not sure whether these test are clean since I connect them to the USB ports which are behind on-board 4-port USB hub. The hub is connected to the first USB host controller. The wifi module however is connected to the second USB host controller directly. Do you have any ideas how can I troubleshoot this issue further? Is there any chance of regression in EHCI stack? There's always a chance of a regression. Can you try connecting the WiFi module to a regular PC? Maybe that will provide some new ideas. In your traces, the working case had about 200 us between each URB completion and the following submission, whereas the non-working case had much less time -- around 20 us. Maybe in the new kernel, the bulk transfers occur too rapidly for the WiFi module to handle. Or maybe the problem lies in the EHCI hardware. Have you checked for errata? 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] USB: OHCI: Check the overrides pointer for NULL in ohci_init_driver()
On Sat, 28 Sep 2013, Tomasz Figa wrote:
A series of commit starting at
50a97e059b USB: OHCI: make ohci-exynos a separate driver
and ending at
b8ad5c3706 USB: OHCI: make ohci-pxa27x a separate driver
introduced the concept of separate OHCI drivers for particular
controllers. Respective drivers need to call ohci_init_driver() to
initialize hc_driver struct with generic data and to certain extent
with platform specific overrides through ohci_driver_overrides struct
passed as second argument to this function. However the code does not
check if the ohci_driver_overrides struct pointer is non-NULL, which
leads for a NULL pointer dereference for drivers that do not need any
overrides.
This patch fixes the problem by dereferencing the passed pointer to
ohci_driver_overrides struct only if it is non-NULL.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
drivers/usb/host/ohci-hcd.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 21d937a..8ada13f 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1161,10 +1161,12 @@ void ohci_init_driver(struct hc_driver *drv,
/* Copy the generic table to drv and then apply the overrides */
*drv = ohci_hc_driver;
- drv-product_desc = over-product_desc;
- drv-hcd_priv_size += over-extra_priv_size;
- if (over-reset)
- drv-reset = over-reset;
+ if (over) {
+ drv-product_desc = over-product_desc;
+ drv-hcd_priv_size += over-extra_priv_size;
+ if (over-reset)
+ drv-reset = over-reset;
+ }
}
EXPORT_SYMBOL_GPL(ohci_init_driver);
You were scooped by Kevin Hilman:
http://marc.info/?l=linux-usbm=138029463906143w=2
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] Memory mapping for USBFS
On Sat, 28 Sep 2013, Markus Rechberger wrote: I hope the SG transfer does not introduce any latency issues we have some usb chipsets which are very picky about latency issues on embedded systems. The latency for SG transfers should be smaller than for non-SG. We got it work by tuning the transfer size, if the timings are not met the device will just disable the transfer. Unfortunately it will take a second to detect that by the driver and re-enabling the transfer which means that it will corrupt the data. I do not have a good feeling about pushing SG transfers into the kernel by modifying the legacy mode without having any experience with it. While the idea behind SG transfers is definitely ok but who knows how it will perform with such devices. The way to fix latency problems is by submitting multiple URBs, enough to make sure the I/O queue never empties out. 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] Memory mapping for USBFS
On Sat, 28 Sep 2013, Markus Rechberger wrote: I put together a few reports: http://support.sundtek.com/index.php/topic,350.0.html http://support.sundtek.com/index.php/topic,1097.msg7780.html#msg7780 http://support.sundtek.com/index.php/topic,411.msg2153.html#msg2153 http://support.sundtek.com/index.php/topic,531.msg2956.html#msg2956 http://support.sundtek.com/index.php/topic,364.msg1829.html#msg1829 they are all about page allocation failure when submitting the URB packet (I agree that it's probably mostly about the 15-16k allocation problem here). They only came up a few times between 2010 - (late) 2012 (we were also able to reproduce this on our Sheevaplug occasionally since we do stronger testing with it I guess). Not sure if that problem still happens, at least it didn't pop up in our forum this year. Do these problems occur with your new patch installed? That's what matters now. 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] Memory mapping for USBFS
On Sun, 29 Sep 2013, Markus Rechberger wrote: to follow up I know why it doesn't happen anymore because customers are using a kernel module which does optimized transfers and pre-allocated the URBs and transfer buffer in kernelspace, the interface just copies the datastream to our actual driver which sits in userspace. Goal is to get rid of that kernel module which is working around that allocation bug. Allan, Greg, can we add another IOCTL for telling USBFS to not use SG transfers (it also allocates 15k buffers and will lead to the same problem)? The old behavior was already broke, the SG transfers won't improve the situation in that case either. Then how will not using SG make the situation any better? You'll just be back with the old, broken behavior. Those Sheevaplugs have 128mb memory, regular routers and NAS systems don't necessarily have more either. If you're trying to do big I/O transfers with large buffers in a highly memory constrained system, you're already in trouble. Fiddling around with the kernel won't help. In fact, you might find the best answer is to do lots of small transfers (i.e., 8 KB or even 4 KB). 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
