Re: Bug in split transactions on Raspberry Pi
Alan Stern wrote: > the device's embedded hub ACKs the packets from the PC and not the > packets from the RPi. > > What other differences could there be? Timing? Power levels? Yes, both good candidates. Can you measure VUSB? As for timing, the host controller will send SOF more or less regularly, if too irregular then that could cause problems for the device. Does your analyzer provide precise timestamps? //Peter -- 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] Add support for usbfs zerocopy.
Steinar H. Gunderson wrote: > > Our interface for zero copy reads/writes is O_DIRECT, and that requires > > not special memory allocation, just proper alignment. > > But that assumes you are using I/O using read()/write(). There's no way you > can shoehorn USB isochronous reads into the read() interface, O_DIRECT or not. How about aio? //Peter -- 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] Add support for usbfs zerocopy.
Markus Rechberger wrote: > just improve that sloppy situation Dude I don't care who you are, your attitude sucks, and flushes any merit you have down the drain. It makes you look super bad. :) > we're at 3 months now Right, so chill out, watch a movie, go to a party, go to several, have some fun, enjoy life - and frohes neues Jahr! This is a piece of software that is improving by people working together. Let it take the time it takes. > Don't expect anyone else seriously testing this interface aside of me > and Steinar. That's a silly comment. You may think you know, but you have no idea. As Greg said you are not the one having to maintain it. If I were you I would be happy that it is getting added so smoothly! I know that I am happy that this is getting added so smoothly! You may know that I was the maintainer of libusb for some time, and I think it's fantastic to have an opportunity to cut through all the layers and get a performance boost. You may think it's lame that it's taking longer on this platform than on others, but well, that's just how it is. Cheer up! New year, new opportunities. //Peter -- 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: reading data at 500Hz
Jose Colmenares wrote: > 128000 bytes per second for a 1000Hz frequency (which the device > can give). 128000 bytes per second is a lot less than the 480 Mbps > that USB 2 gives. That's what's killing me. I don't think you have written that you have a particular latency requirement, but Greg seems to assume that you want to approach zero latency, which indeed USB is not at all capable of. USB is a high throughput and (relatively) high latency bus. Exactly how high throughput and how high latency depends completely on what protocol the USB device implements. USB offers a wide range of communications building blocks, and each device implements some particular protocol with a combination of them. Many devices unfortunately implement very inefficient protocols. Greg's advice to drive this device from userspace is very good - take a look at libserialport for a good start: http://sigrok.org/wiki/Libserialport https://github.com/martinling/libserialport //Peter -- 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 while in interrupt handler
Hi Enrico, Enrico Mioso wrote: > In case I am able, I'll provide more hints. There are a few ways to get the kernel oops output off the computer without copying off the screen; netconsole, a USB debug device, and last but not least photographing the computer screen. One problem with using a USB debug device is of course that an oops in the USB subsystem may stop a USB debug device from functioning. I would suggest trying netconsole with the builtin network port. //Peter -- 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: [Linux USB] enable/disable individual ports
Alan Stern wrote: > > > > It does print out a message, though not a big one. Would you like it > > > > to do something more specific? A more verbose "usage" message, > > > > perhaps? > > > > > > That's a good idea, and additionally I think it would be important to > > > print (much) more information if the ioctl() fails. > > > > I agree. > > What more is there to print? If the ioctl fails, all the program gets > back from the kernel is an error code, which it already prints out. I > wouldn't mind adding something else, if anybody can suggest what it > might be. Information about possible reasons for failure, in particular that this operation may simply not be supported by the hardware. Ideally even have a special case for that, with overly clear text, if it is indeed possible to determine from the error code that this is the cause. //Peter -- 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: [Linux USB] enable/disable individual ports
Alan Stern wrote: > It does print out a message, though not a big one. Would you like it > to do something more specific? A more verbose "usage" message, > perhaps? That's a good idea, and additionally I think it would be important to print (much) more information if the ioctl() fails. > For convenience, the source code is included below. Please keep in mind that the rest of usbutils is generally quite portable while this new utility is not, so if it is included it should probably not be built unless for Linux host systems. //Peter -- 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: Not enough host controller resources for new device state
Patrick Shirkey wrote: > > if the kernel does have support for xHCI, we assume that > > the user will prefer xHCI over EHCI if the motherboard has xHCI. > > Obviously the solution above should suffice for my purposes but out > of interest is it viable to make the switch accessible to run time > configuration? I don't think it makes sense to expose the port routing to user space, but I think it would make sense to route ports to the EHCI HC(s) when xhci-hcd is unbound, and vice versa. I'm not sure what the best implementation for this would be. Would it be possible for ehci-hcd to call into xhci-hcd code, even if xhci-hcd is not currently bound anywhere? One possibility is to add code to both drivers which gets called on unbind and which routes ports to the respective other controller type, but that doesn't really seem like a great solution. It would be nicer to have a single entry point for the (re)routing. Alan, what are your thoughts on that? //Peter -- 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: Not enough host controller resources for new device state
Patrick Shirkey wrote: > I have read various forum posts and some of the archive from this list > about the following error message: > > Not enough host controller resources for new device state > > Some people have had success with disabling XHCI at the BIOS level. > > That seems to be an unnecessary work around to me given we are progressing > towards USB4 in the not too distant future. > > Is there a definitive explanation other than "no one had time/resources to > work on this issue yet" why we cannot have more than 30 odd devices > connected with XHCI enabled? Yes. The xHCI standard (not USB 3, but the standard that SuperSpeed capable hardware on the PC side - host controllers - implement) introduced an allowance for host controllers to support a significantly smaller number of attached devices than described in the USB 2.0 spec. Some non-EHCI high speed capable host controllers in embedded systems are known to have such aribtrary limitations too, but the Intel xHCI implementation was the first I encountered in desktop/laptop hardware. Did hardware vendors decide in the standards bodies that users will now have to choose between SuperSpeed and 127 possible devices? > I am available to assist with debugging this issue if there is a way to > make it work. You essentially have to educate yourself on silicon level (ie. what hardware IP is being used in which consumer products) to sustain a dependency on 127 possible devices per bus. I guess you'll find that there are only very few xHCI IPs out there, probably just three or four. I wouldn't be surprised if they all have the same, or similar, limitations. //Peter -- 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: Not enough host controller resources for new device state
Patrick Shirkey wrote: > > You essentially have to educate yourself on silicon level (ie. what > > hardware IP is being used in which consumer products) to sustain a > > dependency on 127 possible devices per bus. > > > > I guess you'll find that there are only very few xHCI IPs out there, > > probably just three or four. I wouldn't be surprised if they all have > > the same, or similar, limitations. > > Is there anything I can do at the system level to avoid disabling xHCI at > the BIOS level? Unfortunately not. The number of supported devices is now very much hardwired in the host controller hardware. Each connected device requires its own set of registers in xHCI, so when there is a limit it is a hard limit. //Peter -- 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
Alan Stern wrote: > if we can directly map the user-provided buffer for DMA. Given a memory buffer either kernel or userspace has to apply the hardware constraints to find out what part if any is usable for DMA. I think it's fine to push this task to userspace - as long as userspace has a way to take care of it. That means userspace must be able to perform an allocation according to the constraints. I don't think this is currently possible. Is that correct? The kernel could certainly do the allocation and hand the buffer to userspace. Wiping the buffer once upon allocation is a reasonable cost, because this allocation should be long-lived. > On the other hand, adding an API that allows users to allocate low > memory and then hiding it in the USB subsystem doesn't seem like a > good idea. Unless another generic API already supports the neccessary constraints then what other options are there? //Peter -- 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: USB Device needs to be unplugged and plugged in to work
Jose Colmenares wrote: > If the computer starts, and the IMU is already plugged in, I have > to unplug it and plug it again. This is unacceptable because the > IMU will be used in a robot, so we cannot just unplug it every time > the robot starts. In a prototype you could work around this problem with custom hardware to control VBUS in the IMU USB connection, which to the device looks like the cable has been disconnected. TI TPS20xxC power switches (e.g. TPS2051C and TPS2065C) are designed for USB, are frequently used in PCs, and work just fine. But please provide the debugging information already asked for in this thread, so that the software problem may be resolved for the future. Thanks //Peter -- 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: Resetting USB modems and USB to serial converters increases ttyUSBXX counter
Krzysztof Opasiak wrote: >> There's still a bit of a race condition here, isn't there? >> >> Is there any good way to deal with that? >> >> Yes, there is a race condition. If the program closes the device node >> before the device is plugged in again, the ttyUSB number won't change; >> otherwise it will. No, there is no good way to deal with this. > > You may use device authorization. I think that's a good way. Thanks Krzysztof! //Peter -- 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: Resetting USB modems and USB to serial converters increases ttyUSBXX counter
Greg KH wrote: > Userspace still has the port open, so the number is not reused until > userspace closes the device node. Fix your userspace programs to > properly listen to the hangup signal to know to release the device node > and you should be fine. There's still a bit of a race condition here, isn't there? Is there any good way to deal with that? //Peter -- 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: Resetting USB modems and USB to serial converters increases ttyUSBXX counter
Hello, Bin Liu wrote: > >> >There's still a bit of a race condition here, isn't there? > >> > > >> >Is there any good way to deal with that? > >> > >> What race condition are you seeing here? > > > > USB cable is unplugged > > Assuming /dev/ttyUSB0 is opened by process ATM. > > > Process is sent SIGHUP > > USB cable is quickly replugged > > /dev/ttyUSB0 is still open, so /dev/ttyUSB1 is created. > > > Process closes port > > Process closes /dev/ttyUSB0. Right - this is the race condition I'm talking about. I know that the kernel will reuse ttyUSB0 *next time* because then, the process has closed it. My question is about dealing with the race condition between replug and close on the first unplug-replug cycle. The kernel could take the stance that it will not try to second-guess the outside world, but another alternative is to defer the new device until the old has been closed, or perhaps a timeout. //Peter -- 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: Resetting USB modems and USB to serial converters increases ttyUSBXX counter
Greg K-H wrote: > >> Userspace still has the port open, so the number is not reused until > >> userspace closes the device node. Fix your userspace programs to > >> properly listen to the hangup signal to know to release the device > >node > >> and you should be fine. > > > >There's still a bit of a race condition here, isn't there? > > > >Is there any good way to deal with that? > > What race condition are you seeing here? USB cable is unplugged Process is sent SIGHUP USB cable is quickly replugged Process closes port //Peter -- 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: Enumerating the USB device more than the capability of Host in the Linux Platform
Mathias Nyman wrote: > it's possible that the failing "0" returned by xhci_alloc_dev() is > not properly propageated/translated through usb core, the used usb > libarary and whatever other userspace components on top. Does any userspace API receive notification of this failure? I don't think so. I don't think there will be any netlink message from the kernel nor from udev following this failure, there would only be one later if the device is allocated successfully. Am I wrong? Thanks //Peter -- 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] dummy_hcd: replace timeval with timespec64
WEN Pingbo wrote:
> +++ b/drivers/usb/gadget/udc/dummy_hcd.c
> @@ -833,10 +833,10 @@ static const struct usb_ep_ops dummy_ep_ops = {
> /* there are both host and device side versions of this call ... */
> static int dummy_g_get_frame(struct usb_gadget *_gadget)
> {
> - struct timeval tv;
> + struct timespec64 tv;
tv is very often used for timeval structs.
I suggest also changing the variable name, for example to ts, to
avoid some possible confusion.
//Peter
--
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: lsusb -v freezes kernel on Acer ES1-111M
Roland, Roland Weber wrote: > Assuming that this kernel does freeze, I will start to 'bisect' the > differences in the kernel configurations Thank you very much for doing this work. You are one of the many open source heroes and heroines. //Peter -- 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: Likely issue with ch341 kernel-module/driver
Johan Hovold wrote:
I started in the morning to build the driver from the source provided
by the vendor, but it was written in the times of kernel-version 2.4,
and I got hopelessly stuck.
The vendor driver is only for 2.4? Peter?
http://www.wch.cn/download/CH341SER_LINUX_ZIP.html
http://www.wch.cn/downfile/177
The vendor driver version 1.2 readme.txt from 2014-10-10 says:
Current Driver support versions of linux kernel range from 2.6.25 to 3.13.x
It didn't build immediately against the kernel I had at hand, but with
a small touchup (patch attached) it built fine against a 3.10 kernel.
Also, as per
http://lxr.free-electrons.com/source/drivers/usb/serial/ch341.c?v=3.16,
the particular serial-USB-adapter device is added into the id_table,
so seems supported as per say.
That id was added by 82078234d402 (USB: serial: ch341: New VID/PID for
CH341 USB-serial) in 2008, which claims that the driver supports both
old and new devices.
My hardware has that same VID/PID, but there is a version request
sent to the device and my version number is quite a bit higher (20-30)
than what is mentioned in the in-tree driver comments; I guess the
protocol grew with newer versions of the device, but VID/PID weren't
updated. I'm sure it's possible to have a backwards-compatible
driver, but the vendor driver differs enough from the in-tree driver
that I can't be confident that simply doing what the vendor driver
does will work also on older versions of the device.
###
usb 2-2: device not accepting address 8, error -71
###
This still looks like a hardware issue to me. Specifically, this happens
before the ch341 driver is even involved.
I haven't seen any messages like this with my hardware.
//Peter
--- ch34x.c.orig2014-04-14 10:38:44.0 +0200
+++ ch34x.c 2015-06-15 19:26:39.0 +0200
@@ -10,11 +10,7 @@
// Support linux kernel version 2.6.25 and later
//
-#include linux/version.h
-#ifndef KERNEL_VERSION
-#defineKERNEL_VERSION(ver, rel, seq) ((ver 16) | (rel 8) |
(seq))
-#endif
-
+#include generated/uapi/linux/version.h
#include linux/kernel.h
#include linux/errno.h
#include linux/init.h
@@ -380,7 +376,7 @@
unsigned char reg_value = 0;
unsigned short value = 0;
unsigned short index = 0;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, __func__, port-number);
#else
dbg_ch34x(%s - port:%d, __func__, port-port_number);
@@ -405,7 +401,7 @@
return;
cflag = termios-c_cflag;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s (%d) cflag=0x%x\n, __func__, port-number, cflag);
#else
dbg_ch34x(%s (%d) cflag=0x%x\n, __func__, port-port_number, cflag);
@@ -515,7 +511,7 @@
/*unsigned int msr;*/
unsigned int retval;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, __func__, port-number);
#else
dbg_ch34x(%s - port:%d, __func__, port-port_number);
@@ -561,7 +557,7 @@
long timeout;
wait_queue_t wait;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, __func__, port-number);
#else
dbg_ch34x(%s - port:%d, __func__, port-port_number);
@@ -636,7 +632,7 @@
struct usb_serial *serial = port-serial;
int retval;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, __func__, port-number );
#else
dbg_ch34x(%s - port:%d, __func__, port-port_number );
@@ -710,7 +706,7 @@
/*unsigned int mcr = priv-line_control;*/
u8 control;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, __func__, port-number);
#else
dbg_ch34x(%s - port:%d, __func__, port-port_number);
@@ -743,7 +739,7 @@
unsigned int status;
unsigned int changed;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s -port:%d, __func__, port-number);
#else
dbg_ch34x(%s -port:%d, __func__, port-port_number);
@@ -793,7 +789,7 @@
{
//struct usb_serial_port *port = tty-driver_data;
#endif
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, cmd=0x%04x, __func__, port-number, cmd);
#else
dbg_ch34x(%s - port:%d, cmd=0x%04x, __func__, port-port_number, cmd);
@@ -802,7 +798,7 @@
{
// Note here
case TIOCMIWAIT:
-#if(LINUX_VERSION_CODE
Re: Likely issue with ch341 kernel-module/driver
Johan Hovold wrote: On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote: .. garbage characters transmitted from embedded-device .. It seems that there is some issue with the driver. Why do think it's a driver issue? I can confirm similar issues with the in-tree driver and my hardware. Any chance this can be made to work? Ajay, please try building the vendor driver. That works well for me. Any upgrade that might solve the issue? There is no upgrade. Someone needs to spend a day or so on adding functionality from the vendor driver to the in-tree driver, in a backwards-compatible way. Looks like a hardware issue, I'm afraid. When I got garbage from the in-tree driver it was indeed a driver issue. //Peter -- 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: g_serial hangs on write when the cable is disconnected
Greg KH wrote: int fd = open(/dev/ttyGS0, O_RDWR | O_NONBLOCK); This line discipline is very different from the traditional tty line discipline .. this is a character device, with a very specific line discipline that works in a very specific way and assumes you know exactly how to talk to it and communicate with it properly. If the character device is called tty* then I think it is appropriate to expect that it (by default) behaves like a traditional tty device. How the kernel implements this device internally (ldisc or no) shouldn't matter to the user, and if it does I'd consider that a bug. (Sadly unfixable, because public API.) = Rather than defending unexpected behavior, why not admit that the name was poorly chosen and point to the device-specific requirements? Thanks //Peter -- 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] Fix data loss in cdc-acm
Sven Brauch wrote: I don't make any other changes to the default settings. To be honest, I'm not sure in which mode it is operating then (I was assuming raw, but I might be wrong?). You should explicitly set a mode if you need a particular mode, otherwise the port might be in another mode. This sets raw. Add error checking. struct termios t; tcgetattr(fd, t); cfmakeraw(t); cfsetspeed(t, B115200); tcsetattr(fd, 0, t); //Peter -- 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 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 1
Mathias Nyman wrote: +++ b/drivers/usb/host/xhci-ring.c @@ -82,7 +82,7 @@ dma_addr_t xhci_trb_virt_to_dma(struct xhci_segment *seg, return 0; /* offset in TRBs */ segment_offset = trb - seg-trbs; - if (segment_offset TRBS_PER_SEGMENT) + if (segment_offset TRBS_PER_SEGMENT - 1) Maybe change the comparison to = rather than add the extra - 1? //Peter -- 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] FTDI CBUS GPIO support
Stefan Agner wrote: libftdi requires to detach the kernel driver to get access to the device Control transfers ought to be possible without a detach. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in
Re: Patch Request of option.c module to support Olicard-300 (2020:4000)
Joe wrote: I'm considering the idea of posting without that tag for now, so that you can evaluate/add my patch as soon as possible. However... will it be possible, in case, to correct my previous subbmitted patch to add the Suggested-by tag? No, that's not possible. Once a commit has been included into the repository that commit can not be changed. I recommend to wait until you either get a response or get tired of waiting. //Peter -- 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: ZLP sending request from gadget
Felipe Balbi wrote: On Mon, Apr 27, 2015 at 10:57:24AM +0530, Anjana V Kumar wrote: But we see that the serial gadget driver does not set req-zero. But others like u_ether and f_massstorage are setting the same. Is there any specific reason why this is not done in gadget serial ? maybe a bug ? No idea off the top of my head. The protocol may simply not require any ZLP. //Peter pgpEVcvdRo5yc.pgp Description: PGP signature
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
Juergen Gross wrote: Do you have another feeling about the probability of a need to do usb 3? If it is already on the horizon I wouldn't want to do the user space backend now and the kernel one next year. :-) One year is pretty long in kernel time. //Peter -- 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: Request for comments
Hello Joao, Joao Pinto wrote: This new feature basically is to turn the relationship between driver and hardware IP more transparent, making the software more robust. This is an important matter already today, and will only become more important in the future. a) The hardware has the capability of supplying to the driver the IP version and crucial features that it support or not b) The driver would read the hardware capability features and work without hick-ups even if the developer has configured him (e.g. menuconfig during build process) to do some specific thing that is not supported by the current connected hardware Once the driver supports auto-detecting these features, I think that the manual configuration shall be removed. c) If the driver is configured to do something that the connected hardware is not capable of doing, it simply logs a message to kernel log and automatically disables it trying to work has fluid as possible How the driver reacts in this situation is a matter of policy, which should probably not be specific to any one driver, but should probably be set at a slightly higher level, perhaps even by the person configuring/building the kernel. d) If the hardware does not have the capability of supplying information of this type to the driver, than it should work according to the configuration Hm? Can you be more specific? If it is *possible* for the combination of hardware+driver to work according to the configuration, why would the driver ever do anything else? In your opinion this feature would be a value-added to a new driver / existent driver? In general I feel strongly that hardware and drivers must stay close to each other, but some of the things you described are not completely clear to me, so it is difficult to give specific feedback. Can you provide more details? Thanks //Peter -- 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: default/target product id /vendor id for usb devices
temp sha wrote: Look closely in the kernel output and you'll see that no ids change, but that the old device has disconnected and a new device has connected. sorry I could not get it completely. what is this new device/ old device ? A USB device as seen by the kernel is a software concept according to the USB specification and is really unrelated to physical objects. Many physical objects which connect via USB only ever appear in one way, the same way every time, but many also change how they appear, depending on a number of different factors, including being told by software such as a Windows driver or usb_modeswitch to change their appearance and behavior. USB is not a serial port with power. It is a highly structured bus, much more similar to a network. there is only one device USB dongle. changing usb mode can change the product id as well ? does it mean product id is related with usb's mode of operation rather than actual physical h/w. Sure. The physical object is irrelevant to software. What matters is how the object appears and behaves via USB. This is the definition of a USB product. Most of the time it is actually adhered to by vendors. if yes then what about default and target vendor ids seen in the usb_modeswitch help cmd? does this also depend on mode of operation sometimes ? I tried to explain that in the previous email: looking into the help I found 0x1446 is default product id wheres 0x1506 is the target product id. but could not get the idea behind this concept. The USB modem normally appears as a storage device with the Windows software, so that Windows users can easily install it. By this I mean that the storage device is a virtual CD with a Windows driver stored on it. The driver needs to tell the modem to switch from appearing as a storage device to appearing as an actual modem. usb_modeswitch does that. A USB device can not change descriptors (with vid+pid) and behavior on the fly, so the device then disconnects from the host, changes its behavior and reconnects with different descriptors and different behavior. Only then can the kernel modem driver use the modem. //Peter -- 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: default/target product id /vendor id for usb devices
temp sha wrote: Yes running usb_modeswitch manually works, but once mode switch is done product id is getting changed from 0x1446 to 0x1506. Look closely in the kernel output and you'll see that no ids change, but that the old device has disconnected and a new device has connected. looking into the help I found 0x1446 is default product id wheres 0x1506 is the target product id. but could not get the idea behind this concept. The USB modem normally appears as a storage device with the Windows software, so that Windows users can easily install it. The driver needs to tell the modem to switch from appearing as a storage device to appearing as an actual modem. usb_modeswitch does that. Yes I do have hotplug but I am trying alternative ways also. eg as I said skipping usb-storage loading initially by adding the product id in the unusual_devs.h and giving opportunity to probe option driver first. That does not work. The modem needs to be instructed by software to switch modes. as there are two product ids for usb devices I am bit confused which once need to be used in unusual_devs.h and the driver option. Now you know that what usb_modeswitch calls target device is the actual modem. That's the only device that matters for the modem driver. One could of course argue that the kernel should do modeswitching. But sometimes it's preferable to have access to the storage device. //Peter -- 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: Unable to reap urb after receiving signal using usbfs.
Dave Mielke wrote: Under what circumstances should usbfs code, after having received a signal, expect to not be able to reap a URB, and how should it interpret this situation? I would expect ioctl(fd, IOCTL_USBFS_REAPURBNDELAY, urb) to either return -1 with errno = ENODEV, or to return 0 with urb-status = ESHUTDOWN. In this situation, though, wouldn't the URB still be reapable with its status set to -ENOENT? Yes, I think so. 518: if (as-status 0 as-bulk_addr as-status != -ECONNRESET 519: as-status != -ENOENT) 520: cancel_bulk_urbs(ps, as-bulk_addr); Whatever this code is for, it looks like it's specifically not being executed if the error is -ENOENT. What happens if you ioctl(fd, IOCTL_USBFS_DISCARDURB, ) instead of REAP? //Peter -- 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: Unable to reap urb after receiving signal using usbfs.
Dave Mielke wrote: [quoted lines by Peter Stuge on 2015/02/11 at 15:57 +0100] I would expect ioctl(fd, IOCTL_USBFS_REAPURBNDELAY, urb) to either return -1 with errno = ENODEV, or to return 0 with urb-status = ESHUTDOWN. I just reverified. It's definitely returning -1 with EAGAIN. That seems like a kernel bug to me. What happens if you ioctl(fd, IOCTL_USBFS_DISCARDURB, ) instead of REAP? If I give it the address of the urb I'm expecting, it returns 0, That's good. So the code path for discarding the URB has no bug. and then the non-blocking reap changes to returning -1 with ENOENT. ..which also makes sense, because the urb was just discarded. But I don't believe you should have to discard the URB when the device disappears. //Peter -- 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: dwc3/xHCI max connection limit
Bin Liu wrote: I have a ARM SoC which has a dwc3 drd controller, to validate if there is a limit of max device connections, I connected multiple hubs, then keyboards and mice. When plugged in the 32th device, xHCI shows the following message and the numeration failed. Not enough host controller resources for new device state. can't set config #1, error -12 Then plugging in more keyboards or mice, this message always happened. But then MSC devices were still enumerated correctly at this point. So it seems the issue is only related to interrupt transfers? I am trying to understand if this is hardware or xHCI driver limitation. Anyone has any pointers how to debug this issue? I don't know if it is the reason for what you experience above, but xHCI allows for host controller hardware to limit the number of devices that can successfully be attached - which IMO permits xHCI host controllers to be generally incompatible with the USB specification. http://marc.info/?l=linux-usbm=139654353325844 //Peter -- 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: usb_debug serial driver protocol
Greg KH wrote: I've found that screen can leave usb serial ports in an odd state, it's not unique to this specific device, I blame the screen command :) I think that's a lame excuse to not investigate a potential bug. It would obviously be helpful if someone who experienced this problem provided all the details. I think it's bug in screen as minicom and other serial programs seem to work just fine. Next time I run into it, I'll try to write something up... Ah, I meant a potential bug in the kernel. Userspace should not really be able to cause odd things - right? :) //Peter -- 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: usb_debug serial driver protocol
Greg KH wrote: Is that some kind of initialization protocol I have to handle? If yes, where do I find information about it? The protocol should be part of the USB specification. USB debug class devices use no protocol, just transfers of 1-8 bytes, used in arbitrary ways by the various device users. I've found that screen can leave usb serial ports in an odd state, it's not unique to this specific device, I blame the screen command :) I think that's a lame excuse to not investigate a potential bug. It would obviously be helpful if someone who experienced this problem provided all the details. //Peter -- 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] Added PIDs for Actisense USB Devices
Mark Glover wrote: From: Mark Glover m...@actisense.com Signed-off-by: Mark Glover m...@actisense.com There's an extraneous leading whitespace on the Signed-off-by line. +#define CHETCO_SEASWITCH_PID 0xA549 /* SeaSwitch USB Apadter */ The typo remains. Apadter here ^ //Peter -- 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] Added PIDs for Actisense USB Devices Signed-off-by: Mark Glover m...@actisense.com
Please update your commit message to leave one blank line between the commit message summary and the rest of the message. (This avoids your signed-off-by ending up in the email subject.) Mark Glover wrote: +++ b/drivers/usb/serial/ftdi_sio_ids.h .. +#define CHETCO_SEAGAUGE_PID 0xA548 /* SeaGauge USB Adapter */ +#define CHETCO_SEAGAUGE__PID 0xA549 /* SeaSwitch USG Apadter */ Please make the macro name match the product name. Also note typo^ here. //Peter -- 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: Learning USB Programming on Linux
Hi Ivo, ivo welch wrote: thank you, greg. if linux-usb is the wrong starter, can you recommend some pointers to good starter documentation and books about writing user-space USB programs? (is it really read the linux kernel source??) I've held a workshop on how to make your own USB device a few times. The material is available at http://cbs.stuge.se/ The workshop uses the 13 EUR LPC-P1343 microcontroller board from Olimex. The code also runs on any other LPC1343 board, but the buttons and LEDs used in the example might be missing then. LPC1343 is a very small Cortex-M3 microcontroller, not suitable for Linux and not comparable with the DaVinci SoC on the BeagleBone. My material will thus teach you nothing about how to implement a USB device using Linux on more powerful hardware, but it *will* show you a minimal working example of the most important USB primitives; control requests and interrupt transfers. I've also given a talk with an overview of USB basics. slides: https://events.ccc.de/congress/2010/Fahrplan/events/4234.en.html mp4: http://cdn.media.ccc.de/congress/2010/mp4-h264-HQ/27c3-4234-en-usb_and_libusb.mp4 webm: http://cdn.media.ccc.de/congress/2010/webm/27c3-4234-en-usb_and_libusb.webm html5: https://media.ccc.de/browse/congress/2010/27c3-4234-en-usb_and_libusb.html flash: https://youtu.be/uBBE2gihv5I Email me off-list if something is unclear. //Peter -- 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: [GIT PULL] USB driver fixes for 3.18-rc7
Linus Torvalds wrote: I seem to get this problem possibly more commonly at boot these days: usb 1-6: device descriptor read/64, error -71 xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1. usb 1-6: hub failed to enable device, error -22 Since my upgrade to 98e8d2e0 from something a bit older I also get -71 error messages on boot and on resume, however this is older hardware with only ehci-pci. In my case some of the descriptors coming back from the device are bogus when the device is first seen. The device then disconnects, and when it is seen again by the kernel, nearly one second later, the descriptors are fine and there are no errors. vid/pid change from hardware ODM to OEM, suggesting that my device simply isn't ready when Linux first talks with it. //Peter -- 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: musb: core: Disable the Interrupts till BABBLE is fully handled
Felipe Balbi wrote: A babble only occurs when the device side tries to move data without the host asking for anything. It also occurs if the device moves more than packet_size bytes. Not really helping, I know… hmm, why would the device move more than wMaxPacketSize at a time ? Some devices are buggy. That's certainly babble :-) Certainly! But musb shouldn't fall over or lock up because of it, should it? //Peter pgpIA7n8PbrzV.pgp Description: PGP signature
Re: Question r/e zero byte bulk transfer on musb gadget (causes kernel panic)
Breton M. Saunders wrote: Are zero length transfers from a device to the PC on a bulk endpoint sensible? I don't see how they could be. If the device has no data to send it responds with a NAK handshake. If the device has data to send it responds with the data. //Peter -- 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: cdc-acm: add device id for GW Instek AFG-2225
Oliver Neukum wrote: Then I guess I'll take no further action in kernel space. I for one would like the kernel messages to be less prominent, if they stay at all. Since descriptors are not always correct, it's not so useful for the kernel to output such loud messages. //Peter -- 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: TI Tiva Launchpad Luminary ICDI Bug
Moritz wrote: With a recent Update from Kernel 3.16.14-1-x86_64 to linux-3.17.1-1-x86_64 my machine isn't able anymore to recognise my TI Tiva Lauchpad. lsusb normally has the following entry: Bus 004 Device 010: ID 1cbe:00fd Luminary Micro Inc. In-Circuit Debug Interface It vanishes with 3.17. I downgraded to 3.16 and it works again. Please tell us more about your machine, in particular which USB host controller it has. It would also be helpful if you could try to reproduce the problem with the actual upstream 3.17.1 kernel, instead of whatever modifications your distribution includes. It's unfortunately impossible to say much about this problem without more information from you. //Peter pgpgJxfvabiPK.pgp Description: PGP signature
Re: unfixable usb porthole
Gene, Gene Heskett wrote: I think the point they were trying to make is that the device packager, who may not be the chip vendor, can put, if there is room in its flashrom, a short commend that would, on plugging it in, cause the machine to silently go out on the net and become part of a spam bot, or install a keylogger Please spend a bit of time studying that 1.1 spec you have, or actually I would recommend that you download the 2.0 spec instead: http://www.usb.org/developers/docs/usb_20_070113.zip Spend most of your time with chapters 5, 8 and 9. Then spend time studying the EHCI spec. It teaches how the host controller is programmed by the operating system. It should become clear that what you describe just isn't possible. Not everything that is published (on internet or elsewhere) is actually correct. What needs to be fixed? The procedure to update that firmware. if when it is plugged in, it goes out and installs a keylogger, now that is harming the user goes out is not an established term in USB. I'm afraid you're not making any sense. //Peter -- 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: unfixable usb porthole
Gene Heskett wrote: There is no paywall for USB specs. I last looked about a year ago. The only link google could find You should look on usb.org under Developer Documentation instead of on google.com. //Peter -- 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: gadget serial driver - configuration value
Anjana V Kumar wrote: I am using 3.10 kernel. The issue is that the set_configuration(2) is stalled, while the set_configuration(1) passes with the USB hardware I am using. What USB hardware are you using? Why not look into the actual problem with SET_CONFIGURATION? You may discover things that would only become apparent once you have shipped devices, without a chance to solve the problem. The question was, can we set all the three configuration values of CDC ACM, CDC OBEX, and generic serial to 1? Try it out. Windows likes to cache descriptors, and will most certainly not like if a descriptor suddenly changes unexpectedly, so that may be the reason for distinct bConfigurationValue numbers, even though they do not strictly have to be distinct as the code is written. It does makes sense to use different values. You should investigate the problem with your USB hardware. //Peter -- 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: musb + full speed device (2)
Hi, Your kernel is ancient. You should either ask your kernel supplier for support or switch to using a current upstream kernel if you want help here. I can just give some general libusb advice. Pedro Erencia wrote: we are having a curious behaviour with the USB OTG throughput on a DM3730. Specifically, we get a much greater throughput with high cpu loads. .. A test program runs that retrieves data from the board with libusb bulk transfers. Does the program use the async libusb API to ensure that multiple transfers are submitted at any given time? If not, and it is calling libusb_bulk_transfer() in a loop, then the USB controller will be idle a lot, until Linux has scheduled the libusb program, until the program has looped around and submitted another transfer. By submitting multiple transfers at once you ensure that the host controller hardware will work independently of whatever else is going on in the system. It's like with all DMA. You need to prepare buffers ahead of time. //Peter -- 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: musb + full speed device (2)
Pedro Erencia wrote: Unfortunately we cannot change the linux kernel, we are tied to the BSP supplied. :( Then unfortunately you cannot get any help from the community, but are tied also to the BSP supplier for your support. :( We are currently doing synchronous bulk transfers but we also tested the suggested approach and the results were the same. Ok. //Peter -- 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: ftdi_sio input hang with FT230X at high baud rate, binary data
Eric Smith wrote: could use some advice on how I might go about debugging the problem if it is in the ftdi_sio driver. As a data point you could compare the userspace approach with libftdi1. //Peter -- 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: usbfs could not found
Hi Niyazi, Niyazi Sırt wrote: I had kernel-3.4.52, libusb-0.1.12 and usbutils-0.71 on my centos and lsusb command was working properly. After I upgraded kernel-3.14.9 and also upgraded libusb-static-1.0.9, libusb-1.0.9, libusb-devel-1.0.9 and usbutils-006 rpm packages, lsusb command stopped working and I started getting an output like this: libusb: 0.00 error [op_init] could not find usbfs unable to initialize libusb: -99 Ouch. Sorry to hear about that. I know that there is no CONFIG_USB_DEVICEFS parameter in kernel parameters newer than 3.5 kernels. So what should I do? Should I compile the kernel with new parameters or write codes for libusb-1.0. Can you offer a solution? What is your hotplug/udev situation like? udevd is supposed to create /dev/bus/usb/*/* which libusb-1.0.9 finds. Maybe your centos udev is too old to create those? Note: I have compiled kernel-3.14.9 so I put kernel parameters about usb config below: This looks fine, although there are some unneccessary modules. //Peter -- 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: DMA over USB
Raghavendra wrote: I have a query regarding DMA(Direct Memory Access) for the usb devices. USB devices never do DMA. As far as Linux is concerned, how the DMA action being taking place for USB devices. It doesn't take place. As per my understanding, the USB host controller is taking care of the DMA operations. That's correct. When an URB is submitted by host software the host controller asks the device for data, and when data arrives from the device the host controller writes the data into memory using DMA. But I require a little more insight into it. I recommend to study chapters 5 and 8 of the USB 2.0 specification: http://www.usb.org/developers/docs/usb_20_070113.zip Further more, if it is possible for the USB devices, then can this support be also extended towards low-end protocols such as I2C or SPI? Not in the general case. It is possible to develop an I²C or SPI bus master which is capable of DMA toward the host memory, and to create a protocol on top of I²C or SPI which allows devices to remote control the DMA engine in the master, but I'd say that's quite an artificial case. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: f_fs: OS descriptors support
Andrzej Pietrasiewicz wrote:
+++ b/include/uapi/linux/usb/functionfs.h
@@ -33,6 +32,42 @@ struct usb_endpoint_descriptor_no_audio {
..
+/* MS OS Extended Compatibility Descriptor header */
+struct usb_ext_compat_desc_header {
+ struct usb_os_desc_header header;
+ __u8bCount;
+ __u8Reserved;
+} __attribute__((packed));
+
+struct usb_ext_compat_desc {
+ __u8bFirstInterfaceNumber;
+ __u8Reserved1;
+ __u8CompatibleID[8];
+ __u8SubCompatibleID[8];
+ __u8Reserved2[6];
+};
Shouldn't usb_ext_compat_desc be packed too, like all the others?
//Peter
--
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][RFC] USB: zerocopy support for usbfs
Thank you very much for working on this, Stefan. Alan Stern wrote: Also, many host controllers cannot handle arbitrary alignment. It would be best to require that the buffer start at a page boundary. This requires a bit of negotiation with userspace, maybe per-URB but it seems better to negotiate per-claim or even per-open. What about large control transfers? Using a global module parameter to control the use of zerocopy (for anything other than debugging or testing) is a bad idea. I agree. If you think people will have a reason for avoiding zerocopy then you should make it possible to decide for each URB, by adding a new flag to struct usbdevfs_urb. People might want to use zerocopy always, but have buffers in userspace which make that impossible with the given hardware. It's important that the kernel gives userspace enough information about the constraints, if userspace wants zerocopy. People will want to use zerocopy with isochronous transfers as well as bulk. Implementing that isn't going to be quite so easy; it will be necessary for the user to set up a memory mapping. In fact, once that's done the same mechanism could be used for bulk transfers too. Indeed I think userspace wants to be involved in choosing memory also with bulk, in order to ensure that zerocopy will always work when userspace cares about that. Is it enough to expose the DMA mask of the host controller? //Peter -- 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][RFC] USB: zerocopy support for usbfs
Alan Stern wrote: Also, many host controllers cannot handle arbitrary alignment. It would be best to require that the buffer start at a page boundary. This requires a bit of negotiation with userspace, maybe per-URB but I don't follow. What negotiation is needed? All that needs to happen is the user program submits a transfer where the buffer is aligned on a page boundary. The negotiation needed would be for userspace to learn what alignment is required, so that it can make sure to provide only such buffers. But see below on mmap.. it seems better to negotiate per-claim or even per-open. What about large control transfers? The kernel doesn't support scatter-gather for control transfers, only bulk. That could possibly change, right, and then it would be nice to have zerocopy for free there as well? It's important that the kernel gives userspace enough information about the constraints, if userspace wants zerocopy. I don't know of any way for the kernel to give userspace any information about constraints of this sort. Do you? I don't know of any at the moment, no. It might be done through an ioctl into usbfs, but if sysfs already has all neccessary information then no ioctl is needed. Anyway... Indeed I think userspace wants to be involved in choosing memory also with bulk, in order to ensure that zerocopy will always work when userspace cares about that. Is it enough to expose the DMA mask of the host controller? It doesn't need to be exposed, since the mmap(2) call would be handled by the kernel's USB stack (and besides, the user program can't request that the mapped memory be located in any particular physical address region). Since alignment isn't the only issue I don't think there's a way to avoid it. I was just hoping to be able to avoid allocating zerocopy buffers with mmap(). Furthermore, the DMA mask already is exposed in sysfs. For example, the DMA mask for the host controller on bus 2 is given in /sys/bus/usb/devices/usb2/../dma_mask_bits. I realize that this doesn't help much, since userspace can't get the physical address for its virtual addresses anyway. //Peter -- 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] usb/ftdi_sio: Add support for setting CBUS pins on FT232H
Philipp Hachtmann wrote: This patch adds a sysfs attribute cbus which allows to set the four CBUS pins on the FT232H. I think this should be implemented with the gpio subsystem instead. //Peter -- 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-next 8/8] net: cdc_ncm: document the sysfs API
Bjørn Mork wrote: +++ b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm @@ -0,0 +1,143 @@ +What:/sys/class/net/iface/cdc_ncm/min_tx_pkt +Date:May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork bj...@mork.no +Description: + The driver will pad frames longer than this to tx_max, ^^ longer or shorter? +What:/sys/class/net/iface/cdc_ncm/rx_max +Date:May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork bj...@mork.no +Description: + The maximum NCM Transfer Block (NTB) size for RX. + Cannot exceed the maximum value supported by the + device. Must allow at least one max sized datagram + plus headers. + + The actual limits are device dependent. See + dwNtbInMaxSize. + + Note: Some devices will silently ignore changes to + this value, resulting in oversized NTBs and + corresponding framing errors. That behavior makes the setting only so-so useful. Could the driver know which devices do this, or is it inconsistent even across individual devices which are otherwise indistinguishable? +What:/sys/class/net/iface/cdc_ncm/tx_timer_usecs +Date:May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork bj...@mork.no +Description: + Datagram aggregation timeout in µs. The driver will + wait up to 3 times this timeout for more datagrams to + aggregate before transmitting a NTB frame. ^ an NTB frame might be better since N sounds like enn. + + Valid range: 5 to 400 + + Set to 0 to disable aggregation. + +The following read only attributes all represent fields of the read-only? //Peter -- 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-next v2 00/12] cdc_ncm: add buffer tuning and stats using ethtool
Bjørn Mork wrote: Just make doubly sure that you will be ok, for a long time, with using the ethtool coalescing interface for configuring this because you'll really be stuck with this forever. Yes, I am painfull aware of that. So I was hoping someone would jump at this and say something like That's not the way to do it. Use the foo interface instead. It's made for stuff like this. sysfs? //Peter -- 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: About gadget configfs
Hi Peter, Peter Chen wrote: The step at the board: root@freescale ~$ modprobe libcomposite I guess this step is unneccessary, and that all neccessary modules are loaded automatically on demand. root@freescale ~$ mount none /sys/kernel/config/ -t configfs root@freescale ~$ mkdir /sys/kernel/config/usb_gadget/g1 root@freescale ~$ cd /sys/kernel/config/usb_gadget/g1/ root@freescale /sys/kernel/config/usb_gadget/g1$ echo 0x15a2 idVendor root@freescale /sys/kernel/config/usb_gadget/g1$ echo 0x0054 idProduct root@freescale /sys/kernel/config/usb_gadget/g1$ mkdir strings/0x409 root@freescale /sys/kernel/config/usb_gadget/g1$ echo 123456ABCDEF strings/0x409/serialnumber root@freescale /sys/kernel/config/usb_gadget/g1$ echo Freescale strings/0x409/manufacturer root@freescale /sys/kernel/config/usb_gadget/g1$ echo FSL i.mx6q sabreSD Board strings/0x409/product I guess you also did a mkdir configs/c.1 step here? root@freescale /sys/kernel/config/usb_gadget/g1$ echo 5 configs/c.1/MaxPower root@freescale /sys/kernel/config/usb_gadget/g1$ mkdir functions/mass_storage.1 Number of LUNs=8 Mass Storage Function, version: 2009/09/11 LUN: removable file: (no medium) root@freescale /sys/kernel/config/usb_gadget/g1$ echo /dev/mmcblk0p1 functions/mass_storage.1/lun.0/file root@freescale /sys/kernel/config/usb_gadget/g1$ mkdir functions/gser.1 root@freescale /sys/kernel/config/usb_gadget/g1$ cat functions/gser.1/port_num 0 So far so good! You've created two functions in the gadget, following gadget_configfs.txt up to and including section 3. Section 4. comes next, which wasn't included in your list of commands. Associating the functions with their configurations ln -s functions/name.instance name configs/name.number I assume that this results in having only a single configuration with two interfaces. - Why mass storage has been chosen at PC, but not gserial? Probably because the host (PC) doesn't have a driver for gserial with your chosen vid+pid. - Is it possible both two configurations can be seen at PC? If possible, how to do? Both configurations *are* seen by the host - but only one configuration of a USB device can be selected at any one time. If you want both functions available simultaneously then they must be two different interfaces within a single configuration. I believe the symlink described in gadget_configfs.txt section 4. accomplishes that. - How to choose gserial? I tried to remove the configuration of mass storage, but both of configurations have been removed I guess that you will need to add your vid+pid to the host driver. root@freescale /sys/kernel/config/usb_gadget/g1$ rm -rf configs/c.2/mass_storage.1/ Where does configs/c.2 come from? It wasn't mentioned before in your steps? Best regards //Peter -- 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: Error while assigning device slot ID
The USB bus specification says that 255 devices can be connected to the host, but that doesn't mean the xHCI host controller has all the internal resources to support that. To me that sounds like such xHCI HCs can not be considered USB compliant. :\ //Peter -- 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: Problems identifying USB devices persistentely
Hola Alejandro, Alejandro Exojo wrote: But it seems to be failing quite a lot for me, at least on some kernel versions. I was expecting that `udevadm info --query=path` or `lsusb -t` would report exactly the same across reboots if the devices are the same ones, plugged to the same physical ports. Does that make sense? I understand the expectation, but I don't think Linux meets it. The difference in your logs is the usbX bus number, which really can not persist beyond the lifetime of that bus. Think of a laptop with a CardBus slot. CardBus is just PCI. If you plug a USB host card into that laptop, which number will the new usbX bus have? What if that same card is plugged in during boot? What if the card is unplugged? The usbX goes away. And then the card is plugged back in. A new usbX comes in. X is only valid for the lifetime of that bus. For soldered-on buses like in the chipset this means until reboot. I think your best chance is to filter out the usbX bus name yourself. E.g. match on the DEVPATH prefix /devices/pci:00/:00:1d.7/ and on the suffix -4.1:1.0/usbmisc/pcanusb* That will always match the same pcanusb device plugged into the same physical port, as long as chipset or firmware (BIOS upgrade) does not remap PCI devices and/or device functions. While hardware might support such remapping, in particular if the hardware is virtualized, as is increasingly the case, devfns changing is rare. But you do need to coordinate this with whoever is your BIOS engineer if you want actual reliability. //Peter -- 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: MAX3421E: device giving NAKs forever?
David Mosberger wrote: I couldn't figure out how to force UHCI onto an EHCI chip I suggested removing the ehci_hcd driver. Did that work? but I did find I had some old IOGEAR USB 1.1 extenders (USB-over-CAT5 cable) and with those, the device does switch into full-speed mode on my computer: It might not be comparable. [ 886.371122] usb 1-1.3.1.1.4.2: USB disconnect, device number 15 [ 950.960459] usb 1-1.2: new full-speed USB device number 16 using ehci-pci Looks like it's still using the ehci driver. You could use an FX2 data logger like the Logic or any of the 15 USD boards off eBay (the Logic does nothing more than they do) together with http://sigrok.org/ and the libsigrokdecode USB protocol decoder for protocol analysis. It's obviously not a Beagle 480 but could be more than sufficient for full speed. //Peter -- 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: MAX3421E: device giving NAKs forever?
David Mosberger wrote: I couldn't figure out how to force UHCI onto an EHCI chip I suggested removing the ehci_hcd driver. Did that work? Nope. UHCI was loaded but it didn't recognize any UHCI-compatible chips so I was left without any USB devices (not even keyboard). Hmmm. Did you unload ehci_hcd after it had been loaded once, or boot a kernel which didn't include ehci_hcd in the first place? You might need to do the latter. lspci should show the UHCI companion controllers on the PCI bus. (OHCI is also allowed by the EHCI spec, so maybe this is it? Check lspci. Then include ohci_hcd instead.) but I did find I had some old IOGEAR USB 1.1 extenders (USB-over-CAT5 cable) and with those, the device does switch into full-speed mode on my computer: It might not be comparable. I just need proof that the devices can be operated properly with full-speed transactions only. As long as it does that, I should be fine. I'm afraid that it will be more complicated than that. I would make sure to try many different full-speed host controllers. Connecting to the root port of an EHCI controller connects directly to the companion controller for that port, when no ehci_hcd was present in the system since boot. //Peter -- 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: MAX3421E: device giving NAKs forever?
Alan Stern wrote: lspci should show the UHCI companion controllers on the PCI bus. Peter, David's computer doesn't have any UHCI controllers. Everything is handled by EHCI, through a hub on the motherboard. This is the standard design for current Intel systems. Thanks, I understand. I wouldn't use a system like that for this test, just to be sure. //Peter -- 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: MAX3421E Linux driver?
David Mosberger wrote: +++ b/drivers/usb/host/Kconfig @@ -4,6 +4,16 @@ comment USB Host Controller Drivers depends on USB +config USB_MAX3421_HCD + tristate MAX3421 HCD (USB-over-SPI) support + depends on USB + help + The Maxim MAX3421E Host Controller Interface supports + standard USB 1.1 high-speed hardware. I'd suggest supports USB 2.0-compliant full-speed devices instead. And before you assume that high-speed devices (flash drives, wlan, etc) don't work correctly because of something your driver does I would strongly recommend to perform the same tests using another full-speed HC, e.g. by using uhci_hcd as the only hcd, disabling ehci_hcd, on EHCI hardware. I've seen high-speed-capable devices work quite poorly at full-speed; who cares about correctness when there is performance? //Peter -- 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: USB Serial constantly polling
Luke-Jr wrote: And this is the way that the USB protocol works, a device can not send data to the host unless it is asked for it. So the host always has to ask for it. I'm aware of that - but wouldn't it be possible to just ask less often to reduce the bandwidth load? It depends on the device hardware. Some USB devices by design (or perhaps lack thereof) silently discard incoming data if no request is pending. It's easy to see why devices do this when considering the increased complexity of device firmware to queue responses on a bulk-in endpoint after processing a command on a bulk-out endpoint. It's obviously much better for everybody involved to use control transfers instead, but meh who cares about such details, too difficult, let's go shopping. As was already mentioned, the FTDI protocol is exceptionally poorly designed in that not only is there in-band overhead for every data transfer but the protocol also implements its own in-band signalling as opposed to using the signalling primitives already present in the lower layers of USB. This translates to wasted resources throughout the entire system; bus time, CPU time, power consumption. Greg's point about the host controller still stands. What is the issue? It seems that the host controller IP fires interrupts too frequently. Ie. based on the number of transfers as opposed to e.g. bus utilization. At first glance that may not seem like a very important distinction but there is, as always, quite a significant difference between that-seems-ok-lets-ship-it technology and something well-understood. I suppose the controller might be able to delay the URBs such that they just start taking longer; is that what you expect should happen? An efficient HC design would at a minimum coalesce interrupts for things that occur $close_enough to each other, making use of knowledge about the schedule for the bus. As far as I know, this isn't a CPU-load issue. Then can you investigate and report back on what *is* the issue? Too high interrupt load is also a kind of CPU-load issue, even if it doesn't show in top output. //Peter -- 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: USB keyboard occasional key stuck
Clinton Sprain wrote: I noticed your examples are both fn combos. I'm seeing something like this and it seems specifically related to the fn key. Reproducible on a Macbook (3,1) and a Lenovo Yoga 13. Sequence is simple: Press key Press fn Release key Release fn The key will be 'stuck' until you press another key. It seems to only apply to keys that are part of a fn combo Fn is handled by the embedded controller (H8 as per Intel reference design in case of Macbook or Thinkpad) which has its own closed firmware which is rarely perfectly bug-free. //Peter -- 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: USB/IP
konst...@ngs.ru wrote: If so, which linux distro is worth being chosen for building and testing that custom kernel and, especially, usbip, in particular, and does distro really matter? It depends on how much value add the distribution has around the kernel. The well-known distributions all use an initrd to bring userland up and they also have more or less distribution-specific bootloader management methods. If you want to run your own kernel you have to make sure that it is configured and installed to fit what your distribution expects in terms of bootloader and initrd, unless you want to break free from the distribution's expectations and assumptions and manage more things manually. All of this isn't always so well documented by distributions. Maybe start by exploring the kernel make menuconfig for a day or two. //Peter -- 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 and other woes
Sarah Sharp wrote: Yes, this is a slight race condition, and we should wait for the successful event. However, we have not seen any issues with this race condition. I'm glad that you say that having the race is wrong (we should) and I guess that we should wait for the sake of correctness? Which means that the controller is obeying the rules, and the software is wrong. I think your mindset isn't helpful here. I think his mindset is helpful for xHCI users in the future. Software will never be perfect. I think software can be perfect. It just takes well-defined scope and desire for perfection. But let's ignore perfect and stay at correct, because it doesn't make sense for many businesses to invest in perfection. David mentioned that his company is investing in xHCI correctness, and you seem to principally agree with correctness since you write that we shouldn't settle for having a race. side_note The questions to ask when discovering a bug are: 1. What is the impact of this bug? Is it user-visible? 2. How many customers are impacted by this bug? 3. What is the software complexity of fixing this bug? 4. What are the chances of the fix causing other issues? 2. sounds like you reduce humans to business entities customers which I don't think is cool, but I do realize that most kernel work is completely business-driven. Users are other humans and when I work on software I want those other humans to have the best possible software I can give them, not just the best possible software I can give them without causing (or exposing?) other issues. That seems like sweeping dust under the carpet. :) My fault in libusb is that I naïvely expected other open source developers to share the desire for correctness, when in fact many developers don't care about correctness at all, much less perfection. In this case, the bug has been worked around (not perfectly), but we've had no customer reports that this is an issue. Maybe perfection could be expressed as pre-empting any and all issues. Again - not economical. Much more about what we leave behind for those who come after us, than about what we can profit from today. /side_node So fixing this race condition is a really low priority for me If fixing the race requires larger architectural changes doesn't that suggest that the software model for the hardware interface is still (perhaps just a little) incorrect, and should be fixed? //Peter -- 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: [RFT 1/2] xhci 1.0: Limit arbitrarily-aligned scatter gather.
Sarah, Sarah Sharp wrote: I'm simply trying to see how much of a priority it is to fix this. I really want to re-architect the code and do this right, and it will take some time. Awesome! I think wanting to do it right is very close to desire for perfection, or at the very least correctness. :) I do appreciate having to prioritize. //Peter -- 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: XHCI Host Controller on Intel Panther Point with CDC/ACM dead after massive NAK
Hi Andreas, Kasberger Andreas wrote: XHCI Host Controller on Intel Panther Point with CDC/ACM dead after massive NAK PCH 82HM76 (PantherPoint) chipset connect with a Renesas RX621 How to reproduce : No Reader on device /dev/ttyACM0 connected Writer will send in endless loop always same command : echo readhik/dev/ttyACM0 Function: Renesas RX621 will receive command, put into a internal queue and it is waiting for reader. As long reader is comming it will stored in the queue. If command has reached time out the command will removed from queue. If queue is full every command will be answered with NAK The response will be nearly always with NAK because nobody will read from /dev/ttyACM0 After some time ( between seconds and several hours ) the host controller will not send anything to the device connected on Renesas RX621. We proven this with a analyzer directly on the bus. Other devices connect to host controller are still alive and working. I'm sorry, but this protocol design is rather broken use of USB. That said, the HC must certainly be more robust in dealing with it. On the protocol design: First, using CDC-ACM means sacrificing all structured communication offered by the USB packet bus and settling for such primitive use of USB is not a decision that should be made lightly. Almost all applications can benefit quite significantly both in end-user usability and in ease of implementation from an application-specific protocol which takes advantage of what USB offers. Application-specific or vendor-specific are often frowned upon in other contexts but if the protocol is documented publically then it is a great way to take advantage of all that USB offers, and it is explicitly supported by the specification. Use bDeviceClass or bInterfaceClass 0xff. But more importantly, regardless of the application protocol, with USB it is the absolute and complete responsibility of the host-side software to communicate with the device only *exactly* in the way that the device supports. You mention device-side buffering and that the device at some point can't accept anything more from the host. With USB this means that you must ensure that the host will know when it must not send more. The USB way to do this, were you using an application-specific protocol instead of serial port simulation, would be to stall the endpoint. Unfortunately CDC-ACM doesn't allow doing that. So you have to include some kind of in-band signalling for this. :\ This is just one reason why ACM is a poor choice for when you need structured communication. //Peter -- 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 v3] tools: usb: aio example applications
Robert Baldyga wrote:
v3:
..
+++ b/tools/usb/aio_multibuff/host_app/Makefile
@@ -0,0 +1,13 @@
+CC = gcc
+LIBUSB_CFLAGS = $(shell pkg-config --cflags libusb-1.0)
+LIBUSB_LIBS = $(shell pkg-config --libs libusb-1.0)
+WARNINGS = -Wall -Wextra
+CFLAGS = $(LIBUSB_CFLAGS) $(WARNINGS)
+LDFLAGS = $(LIBUSB_LIBS)
+
+all: test
+%: %.c
+ $(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS)
+
+clean:
+ $(RM) test
Nice!
+++ b/tools/usb/aio_multibuff/host_app/test.c
..
+ cnt = libusb_get_device_list(state-ctx, list);
+ if (cnt 0) {
+ printf(no devices found\n);
+ goto error1;
+ }
..
+error1:
+ libusb_free_device_list(list, 1);
+ libusb_exit(state-ctx);
+ return 1;
+}
The above tries to free uninitialized memory in the error path.
+ for (i = 0; i cnt; ++i) {
+ libusb_device *dev = list[i];
+ struct libusb_device_descriptor desc;
+ if (libusb_get_device_descriptor(dev, desc)) {
+ printf(unable to get device descriptor\n);
+ goto error1;
+ }
+ if (desc.idVendor == VENDOR desc.idProduct == PRODUCT) {
+ state-found = dev;
+ break;
+ }
+ }
+
+ if (state-found) {
...
+ } else {
+ printf(no devices found\n);
+ goto error1;
+ }
A matter of taste, but I would reverse the if () condition to avoid
the extra indent level for when a device has been found.
I find that makes it more clear what part of the code handles errors
and what part is the expected common case.
A few other things in the same code:
+ if (state-found) {
+ printf(found device\n);
+
+ printf(open device: );
+ if (libusb_open(state-found, state-handle)) {
+ printf(ERROR\n);
+ goto error1;
+ }
+ printf(DONE\n);
+
+ if (libusb_kernel_driver_active(state-handle, 0)) {
+ printf(device busy.. detaching\n);
+ if (libusb_detach_kernel_driver(state-handle, 0)) {
+ printf(unable do deatch device\n);
Typo deatch
+ goto error2;
+ }
+ state-attached = 1;
+ } else
+ printf(device free from kernel\n);
This isn't completely accurate, in two ways. First, it's only the
interface and not the entire device which is claimed/detached.
Second, it could be either another userspace program (via the
usbfs kernel driver) or it could be a kernel driver which has
claimed the interface.
libusb_detach_kernel_driver() makes it so that no kernel driver
(usbfs or other) is attached to the interface.
libusb_claim_interface() then makes the usbfs kernel driver attach
the interface.
+
+ if (libusb_claim_interface(state-handle, 0)) {
+ printf(failed to claim interface\n);
+ goto error3;
+ }
+ } else {
I still recommend the open/claim/detach logic to be:
libusb_open()
if (libusb_claim_interface() != LIBUSB_SUCCESS) {
ret = libusb_detach_kernel_driver();
if (ret != LIBUSB_SUCCESS) {
printf(unable to detach kernel driver: %s\n, libusb_error_name(ret));
goto ..
}
ret = libusb_claim_interface();
if ( != LIBUSB_SUCCESS) {
printf(cannot claim interface: %s\n, libusb_error_name(ret));
goto ..
}
}
If you prefer to be more conservative then don't use libusb_error_name()
which was only introduced in late 2011 and released in 2012.
//Peter
--
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 RFC 1/1] usb: Tell xhci when usb data might be misaligned
David Laight wrote: Where's the 8k coming from? My memory, I meant 16k :-( No problem. But what about that alignment? It seems that userspace needs to start caring about alignment with xhci, right? //Peter -- 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: MAX3421E Linux driver?
David Mosberger wrote: The Maxim MAX3421E is the other option, but it has no Linux driver. You could look at http://arduino.cc/en/Main/ArduinoBoardADK for a reference that might even work. //Peter -- 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: MAX3421E Linux driver?
David Mosberger wrote: David Mosberger wrote: The Maxim MAX3421E is the other option, but it has no Linux driver. You could look at http://arduino.cc/en/Main/ArduinoBoardADK for a reference that might even work. We are aware of Arduino but the point of our project is to be able to use normal Linux USB drivers. As far as I know, Arduino has it's own (limited) USB stack. Perhaps I'm missing something? Sorry, I absolutely did not suggest that you actually use the Arduino for anything, but the ADK code might actually work and could serve as a reference for driving the MAX. //Peter -- 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] tools: usb: aio example applications
Nice to have a complete kernel+userspace example. Thanks!
Robert Baldyga wrote:
+++ b/tools/usb/aio_multibuff/host_app/test.c
@@ -0,0 +1,122 @@
+#include libusb-1.0/libusb.h
Please don't do this.
Please always #include libusb.h and call some combination of:
pkg-config --cflags libusb-1.0
pkg-config --libs libusb-1.0
in the host application Makefile to get the correct compiler and
linker flags.
This allows your example Makefile to compile the application
correctly across all platforms supported by libusb, and perhaps even
more importantly it allows the host application to be cross-compiled
simply by setting PKG_CONFIG_LIBDIR appropriately for the
cross-compile toolchain.
Using pkg-config solves a whole bunch of problems - but it only works
if it's actually used, so please do. ;)
+int test_init(struct test_state *state) {
+ int ret, i;
+ ssize_t cnt;
+
+ state-found = NULL;
+ state-ctx = NULL;
+ state-handle = NULL;
+ state-attached = 0;
+
+ libusb_init(state-ctx);
Please check the return value. Suggest:
if (libusb_init(state-ctx) != LIBUSB_SUCCESS) {
..
Also, create an exit path for the case that libusb returns an error
in test_init() so that your example demonstrates how to properly free
all libusb resources.
The current flow makes errors bubble up to main() which does a
return 1; and will leak if the code is copypasted into a larger
program as opposed to being used as a standalone example.
But I may be exaggerating this problem if nobody copypastes.. ;)
+ if(libusb_kernel_driver_active(state-handle ,0)) {
+ printf(device busy.. deatching\n);
typo, detaching, but..
+ libusb_detach_kernel_driver(state-handle, 0);
+ state-attached = 1;
+ }
+ else
+ printf(device free from kernel\n);
+
+ if(ret = libusb_claim_interface(state-handle, 0)) {
+ printf(failed to claim interface\n);
+ return 1;
+ }
..this construct is unneccessarily racy. I suggest to directly call
_claim_interface() after libusb_open() and on failure then call
_detach_kernel_driver() and after that _claim_interface() a second
time.
If the second claim also fails then give up, clean up, tell user to
sort it out and exit.
+ else {
+ printf(no devices found\n);
+ libusb_free_device_list(state-list, 1);
+ libusb_exit(state-ctx);
+ return 1;
+ }
+ return 0;
+}
+
+/*
+ * test_exit - cleanup test program
+ */
+
+void test_exit(struct test_state *state) {
+ if(state-attached == 1)
+ libusb_attach_kernel_driver(state-handle, 0);
+ libusb_close(state-handle);
+ libusb_free_device_list(state-list, 1);
+ libusb_exit(state-ctx);
+}
I would call libusb_free_device_list() within test_init() *after*
having called libusb_open() on the device. There's no real reason
to keep the device list within struct test_state.
//Peter
--
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: Announcing libusb-1.0.18 (as well as libusbx-1.0.18 *FINAL*)
Hi all, I've removed the libusbx-devel list since Pete Batard banned[1] me after I wrote that I considered the libusbx code to have a bug[2]. Pete Batard wrote: It is my great pleasure The hostile fork[3] is a success; you can now call libusbx libusb, since Nathan Hjelm removed me from the libusb project on SourceForge. Nathan had worked on hotplug functionality in libusb but after review and feedback (like with many of Pete's proposals) there didn't seem to be understanding or perhaps agreement with the issues, and I wasn't able to help bring the work into maintainable form before patience ran out. I completely understand that Nathan decided to switch to working on libusbx. I do however not think that it was appropriate to give an ultimatum and remove me from the SF project, even if I wasn't responding to emails, even for quite some time. I think the decent move would have been to work on libusbx under the name of libusbx. But we're past that. I sent an email to libusb-devel in response to those events and got a private reply from Nathan saying this ends now, I am the sole libusb maintainer and I have welcomed libusbx's developers back into libusb. and If you continue to be negative on the libusb-devel list I will perma-ban you. and since I guess that this email will be considered negative I guess that I might be banned from libusb-devel soon enough. I'll of course continue reading both libusb and libusbx lists, but since Pete and Nathan have made it clear that they don't think I can contribute to what they do I'll continue to work on my own. the long awaited merging back of libusbx with libusb! Pete's rhetoric is, as always, excellent propaganda. .. The only difference between them is that a bunch of strings, which bear no impact on either the compilation or the API (95% of them being in comments) say libusbx on one side and libusb on the other. What has in fact happened is that libusbx developers have taken control of the libusb project on SourceForge and, as Pete describes, have now simply renamed libusbx to libusb. That's of course not a merge. I'm not going to fight a PR war and even if I tried I'd likely lose. I'm not a native speaker, not determined to express myself with hostility and no longer willing to fall down the pyramid of debate[4]. What I *will* however do is continue to work with the libusb.org code, website and community, as I have for more than 10 years. It doesn't show much, libusb.git hasn't seen commits for a long time and I have many unreplied emails, but I am still here and work is still ongoing, if slowly. There are changes coming to the git repo as well as some kind of release looming. I haven't spent much time on libusb.org lately but that doesn't make it dead. the many bug fixes and new features of libusbx, into libusb It's true that libusbx has bug fixes and new features which aren't yet in the libusb.org code but it's also true that the libusbx code has technical issues caused by bad implementations and bad design, both of which I don't want to include in the libusb.org git and which I work on removing from libusb.org code in cases where it already exists. I disagree with quite many developers because I am very critical of code, my own as well as that of others, because I think there's more than enough bad software in the world already and that the reason to spend spare time on open source is to make software as good as we possibly can. Everybody doesn't agree with that - and that's fine. With this release however, we had to make some adjustments to our URLs (mostly because the person in charge of the original domain wasn't interested in helping the project move forward) Nathan wrote that he'd prefer if I gave away the libusb.org domain name but that it didn't really matter much. I indeed do not want to help the libusbx project move forward, which Pete makes sound as if I have refused to support libusb. I stopped wanting to help move libusbx forward when I was banned from the list and nobody said a word in protest. (Maybe because Pete suggested that he wouldn't care if anyone complained about censorship.[1] again) The SF events didn't help bring me around. Please make sure you update your tracking of the project as required. If you want unfinished new features and some poor design choices then yes, follow libusbx to the new domain name. If you prefer a carefully, albeit slowly, maintained codebase then you can remain confident with the libusb.org website and code. If you are affected by any bugs then please get in touch. The next release of libusb.org code (whatever that will mean) will be API and ABI compatible with libusbx code since I still consider compatibility more important than fixing libusbx's API mistakes. I've had less motivation for libusb after having dealt with Pete's propaganda within the libusb project, the hostile fork he has led and the tireless slander, ad-hominems and name calling which I guess might
Re: Not enough resource for old configuration after USB bus reset
Soar Hung wrote: We ported the Linux and related drivers to our embedded system(a customized board), and using TUSB7340 as our host controller. We also write a usb interface driver for the tested device, the enumeration and bulk in/out transfers work fine. But we encounter problem .. Does anybody has the same experience or some guide and would kindly share with us? It's basically impossible for anyone to help you in any way unless you either share the complete and full kernel source code that you are using, or reproduce the error with a combination of hardware and software that others who will do the debugging also have access to. //Peter -- 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: config x has an invalid interface number: y but max is z
Alan Stern wrote: Should we just drop those warnings? No opinion. I think they should stay. OK, but how about demoting them to debug messages instead of warnings? If you want to make that change, I don't mind. I prefer that they stay visible by default, because it increases the likelyhood that someone will actually notice them. Clearly the people who stand to benefit from these messages aren't actively looking to find problems with their USB device. //Peter -- 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: prevent overlapping access by usb-storage and usbfs
Greg KH wrote: Ok, given that this is due to really broken hardware, and the use case is quite rare, and the patch doesn't really solve the problem, I'll drop it from my queue. No protest against dropping the patch - but just a note that in the libusb community we are really big fans of the way (some?) BSD systems allow both a kernel driver *and* userspace to open a device at the same time - doing locking when the interfaces is actually being used by someone. For USB storage this would mean that unless a filesystem has been mounted or dd is running on the block device, usbfs could claim the storage interface *while* the block device exists. It is understood that this may well require quite a bit of surgery in the kernel, but it's certainly a spiffy solution! //Peter -- 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: prevent overlapping access by usb-storage and usbfs
Greg KH wrote: allow both a kernel driver *and* userspace to open a device at the same time - doing locking when the interfaces is actually being used by someone. For USB storage this would mean that unless a filesystem has been mounted or dd is running on the block device, usbfs could claim the storage interface *while* the block device exists. It's also ripe for problems and data loss, Hm? How so? Note actually being used - as soon as the block device is in use, of course noone else can go claim that interface. //Peter -- 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: prevent overlapping access by usb-storage and usbfs
Greg KH wrote: Ah, ok, that's a bit better, but then we need to figure out some way to push being used down to a large majority of drivers, which we really don't have. And of course not just for storage; allow *all* the classes. I don't know how much effort it would be for storage - is a block device unaware that it has been mounted? I mean: does the kernel only keep a single link from the filesystem to the block device, and nothing the other way around? Sounds like a lot of work for little gain :) Sure - is understood. It's probably particularly unimportant for storage vs. other classes, but it does seem ideal to defer access exclusion until the latest time possible. A very accurate model. I agree only achievable with a lot of work. //Peter -- 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: prevent overlapping access by usb-storage and usbfs
Alan Stern wrote: I don't know how much effort it would be for storage - is a block device unaware that it has been mounted? Those are two separate issues. Firstly, usb-storage is not a block device drivers; it is a USB driver. You're of course right, the knowledge needs to travel across several drivers. Secondly, the block driver (not device) is not aware when any of the filesystems in any of the partitions has been mounted. But it is aware of when the device file is open. Nod, that answers my thought. Thanks for clarification. I mean: does the kernel only keep a single link from the filesystem to the block device, and nothing the other way around? A block device can contain many filesystems: one in each partition. I guess I have userspace bias; by block device I meant one major+minor combination, ie. either full device or partition. //Peter -- 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: Clarifications on some usb driver terms
stl wrote: I am at the moment working on a uClinux 2.6.19. Don't do that. Work on the absolutely latest source code. If you work on anything else it is impossible for you to get any help with any issues, and you will have to spend a lot of extra time to make your finished work possible to include in the upstream kernel. Upstream inclusion is important, so it is wise to minimize the number of obstacles that you create for yourself. //Peter -- 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] CDC_NCM adding support IFF_NOARP for infineon modem platform
David Miller wrote: should all WWAN drivers be moved to only POINTTOPOINT? I can't answer any of your questions unless you tell me what the real limitation of these devices is. It's rather about the network than any given devices, right? //Peter -- 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: Linux USB file storage gadget with new UDC
victor wrote: please remove these sort of footers when you send emails to a public mailing list ;-) The footer is auto-inserted by the company email system. I am sorry about it. Talk to your company about how it is impossible for you to contribute to an open source project on a public mailing list while claiming that everything you send is confidential. //Peter -- 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: usb bus monitoring
Tilman wrote: I am in the process of writing firmware for an USB device based on an 8051 core. What device is that? Is it a Cypress FX2 or an SiLabs C8051? I am testing it against linux kernel driver. Depending on the device it may be worth exploring also the libusb alternative, allowing you to work only in userspace. The urb eventually times out. Via debug FS I can see that the urb is indeed submitted. I suspect the firmware to be responsible for this. That's quite likely. I would like to exclude the linux test driver owever, That doesn't make a lot of sense - if you take the driver away then there is nothing that will talk to your device, so there will be no traffic. and wonder if there is a cheap way to monitor what is happening on the USB bus itself. usbmon in debugfs is as good as it gets with no dedicated hardware bus analyzer. //Peter -- 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: [Suggestion] drivers/usb/core: for u16, use stack allocation instead of kmalloc
Chen Gang wrote:
it is better to let u16 status instead of u16 *status = kmalloc
..
940 int usb_get_status(struct usb_device *dev, int type, int target, void
*data)
941 {
942 int ret;
943 u16 *status = kmalloc(sizeof(*status), GFP_KERNEL);
944
945 if (!status)
946 return -ENOMEM;
947
948 ret = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
949 USB_REQ_GET_STATUS, USB_DIR_IN | type, 0, target, status,
950 sizeof(*status), USB_CTRL_GET_TIMEOUT);
951
952 *(u16 *)data = *status;
953 kfree(status);
954 return ret;
955 }
956 EXPORT_SYMBOL_GPL(usb_get_status);
Maybe you can send a patch with a proposed improvement?
Best regards
//Peter
--
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: autodetect USB MTP device characteristics without libusb_open()
Linus Walleij wrote: Windows requests the 0xee string descriptor from *every* device, unless the same vid and pid has been seen before on the system. I had no clue about that... have you seen this from USB traces? I didn't look at traces, but Microsoft documents it, and testing shows their documentation to match reality. http://msdn.microsoft.com/en-us/library/windows/hardware/ff537430(v=vs.85).aspx The 0xee string is read starting from Windows XP. I have seen devices crash when 0xee is requested, but it might be that we're clearing the stall in the wrong way when it's not there. I'm not saying that devices will not crash. I'm saying that it is completely expected that lots of devices will crash, and that the only solution is to do what Microsoft does; remember when devices have already been queried for the MOD and never do it again. I was certainly under the impression that Windows does not do this for devices it has seen before... Yes, that is what I am confirming. Quoting myself: unless the same vid and pid has been seen before on the system. Microsoft also describes it on their page which I linked to above. We could do it for all devices but it might be that we're doing something wrong with libusb so that several devices crash when doing this. Nothing that can be done to a USB device from userspace (I'd say even from the kernel) is legitimate reason for a device to crash. USB firmware however seems very difficult to write for many vendors, and plenty of devices crash for all sorts of reasons even though they should not. Windows works around this by never quering the same device more than once. I'd treat the Microsoft page as the canonical documentation. Currently we do it like this: It's fine, but I would call libusb_get_string_descriptor() instead of libusb_get_descriptor() for a bit more clarity. I have some vague indications that their DRM system for USB mass storage is also using the special 0xee descriptor to identify devices with such capabilities, but I have no clue as to how this actually works. (You can see this from the above code: we need to check that the returned descriptor actually start with MTP, it *could* say something else...) If you read the MS documentation (it's a little labyrinth:ey so you'll have to click around a bit) they might have a list of the handful device types which use a MOD to guide Windows to the correct driver. There is one, but I'm not sure on exactly what page. Starting with Windows 8 they even have WinUSB as one device type, meaning that a USB device can use a MOD to get WinUSB.sys bound to it automatically on attach, and userspace applications which use libusb-1.0 can access the device without the user needing to replace the driver. It's very nice that plug and play has arrived also to Windows, it sure took a while to get there. End result: A given device only ever crashes exactly once on a given Windows system. Yep this is as far as I've understood as well. But now you're contradicting the first paragraph of your mail, so which one is it? Hm, I don't think so? So I could mimic this by starting to cache away any successfully initiated MTP devices in some /var/libmtp file and just OK them the next time they are plugged in. You'll have to cache *every* device, so that you do not make a given device crash more than once, like Windows. Hm, need to figure out how to do this then... Before asking for 0xee make sure that the same device has not been seen by the program in a previous invocation. 1. create device identifier (suggest like the MS r) 2. search for identifier in cache 3. if found, do not send 0xee request but use information from cache 4. if not found, write identifier with empty information to cache 5. get 0xee string and perform device/vendor control request 6. if successful response, update information in cache 7. if device crashes, tell user to reconnect device When the device crashes on reading the 0xee string and no other automated method is available to match the device against libmtp the only remaining option to make the device functional that I can think of is a whitelist. //Peter -- 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: ftdi_sio: VID and PID for Newport Agilis motor driver
Martin Teichmann wrote:
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -192,6 +192,7 @@ static struct usb_device_id id_table_combined [] = {
{ USB_DEVICE(FTDI_VID, FTDI_OPENDCC_THROTTLE_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GATEWAY_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GBM_PID) },
+{ USB_DEVICE(NEWPORT_VID, NEWPORT_AGILIS_PID) },
Please fix your added line so that it aligns correctly with nearby code.
//Peter
--
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: autodetect USB MTP device characteristics without libusb_open()
Linus Walleij wrote: If you insert any kind of device into a Windows machine, and Windows does not find a .inf file for it, it will be probed for the OS descriptor. I think it avoids anything with != 3 endpoints of the right type though. And basically that is how MTP devices just work on Windows, as far as I can tell. Please see my previous description of how this works, in this thread. Windows requests the 0xee string descriptor from *every* device, unless the same vid and pid has been seen before on the system. it turns out that users want MTP devices to just work just like they just work on Windows. IMHO there's no other way to accomplish that other than to implement Microsoft's extension to USB; always request the 0xee string descriptor if the vidpid has not been seen before. It would mean that Linux systems must start keeping track of every device that a system has seen. It's atrocious. But I don't think there's another way. Of course, it could be part of a non-core package, so that only when the MTP software is installed will there be some database. For most (I'm not sure I dare say all) other devices, it would add no value on Linux. So there are devices that crash if you ask for descriptor 0xEE. The way Windows gets around it is *probably* by using some of the heuristics above, like making sure that there is an interface with 3 endpoints and so on. I don't know for sure :-( When a vidpid is attached which has never been seen on the system, Windows adds lots of values to the registry saying it has now seen this device, and then asks for the 0xee string descriptor. When a vidpid is attached which *has* been seen on this system (Windows looks for those values) the string descriptor is not requested. End result: A given device only ever crashes exactly once on a given Windows system. But they have this concept of an .inf file, so the first time you insert an alien device, you are asked for an .inf file with some driver information. Then you can bind that VID+PID to a specific driver, and then they will not look further the next time the same device is plugged in again. They will just load the driver given from the .inf file. Note that everything in the .inf gets stored in the registry. Noone looks at the .inf again, once the driver has been installed. So I could mimic this by starting to cache away any successfully initiated MTP devices in some /var/libmtp file and just OK them the next time they are plugged in. You'll have to cache *every* device, so that you do not make a given device crash more than once, like Windows. //Peter -- 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: usb to parallel cable not recognized
Rolf Leggewie wrote: Recently, I was given a usb-to-parallel adapter cable but the latest mainline kernel does not recognize it. I can't find any identifying information on the cable itself. Please let me know what information I can provide to get this supported. The cable doesn't enumerate correctly, there's not much Linux can do about this unfortunately. Does the cable work with any other operating system on any other computer? Does it work on every USB port on that computer? Did you try a few different ports on the computer where it does not work? //Peter -- 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: Device detected as Digitalcamera (PTP?) instead of Portable Device (MTP?) - MS_COMP_MTP - WinXP
Karl Krach wrote: Thanks a lot. It seams that the Android [1] has the 'Microsoft OS Descriptors' implemented while Meego has not. Porting from the Android code don't seems to be straightforward for me - do you know a better solution? Reimplement them? It shouldn't be terribly much work - it's one string descriptor and one type vendor recipient device control request. According Brett [2] the 'Microsoft OS Descriptors' are required to get MTP running on WinXP. They also say, that they are only requested if using 'Vendor Class Codes' - otherwise PHP is used. I don't know about that. Please let me know if you do some tests though. Note that you'll need to clean your registry, or bump vidpid, or change USB port, each time you unplug/replug the device while testing. //Peter -- 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: autodetect USB MTP device characteristics without libusb_open()
Bjørn Mork wrote: The problem appear when you ask a device which is not MTP for that descriptor, some of them just die, so I cannot do that. Really? You ask for a string descriptor and the device dies? Won't those devices also die if they are connected to a Windows system? Yes, but only once. Windows stores an entry in the registry for every device plugged into the system, and the MOD will only be requested the very first time a given device is attached, *or* if the device returned a MOD for a previous request. So the user unplugs and replugs (or reboots) and then the device works. //Peter -- 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: autodetect USB MTP device characteristics without libusb_open()
Linus Walleij wrote: - some devices bug out on libusb_open() Please send me a debug log from when this happens. Exact steps are at http://libusb.org/wiki/debug I'll see what I can dig up. Mostly this has come from upstream, Alessio do you have something at hand for these color calibration crashes you've been seeing? Alessio Treglia wrote: Sorry but no, I don't. Can someone please provide the requested debug log, so that I can see what is actually going on when this problem is experienced? Thanks //Peter -- 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: Device detected as Digitalcamera (PTP?) instead of Portable Device (MTP?) - MS_COMP_MTP - WinXP
Karl Krach wrote: How to be detected as USB\MS_COMP_MTP? Microsoft OS Descriptors http://msdn.microsoft.com/en-us/library/windows/hardware/gg463179.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/ff537430%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/windows/hardware/gg463179.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/ff553624%28v=vs.85%29.aspx //Peter -- 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: autodetect USB MTP device characteristics without libusb_open()
Hej Linus! Linus Walleij wrote: - some devices bug out on libusb_open() Please send me a debug log from when this happens. Exact steps are at http://libusb.org/wiki/debug I have added code like below to libmtp to instead inspect sysfs *before* starting any libusb-based business. .. - Is this a good idea? It's a horrible hack and I don't think it's a very good idea. I understand that you have some real broken devices to deal with, but let's just make libusb work for you instead. Also, look into scanf() and friends, they are highly underrated! :) - What is the scary business that libusb_open() does that makes a lot of substandard USB devices totally freak out? I can only confirm that opening does not talk to the device. Enumeration can. But really, I need to see the debug log, and usbmon output from when this happens would certainly also be nice. Linus Walleij wrote: you cannot open a session to an MTP device in say a udev script, then close it and open another session later Maybe don't do that. Open the session in the udev-driven program, and do not close it. Find a way to tell libmtp that a session is already open, and only OpenSession when one isn't. It isn't pretty, but.. //Peter -- 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 controller CS5536 hard disk disconnects
Miguel Dardenne wrote: I get a USB disconnect of my external USB HDD about once per day. Did you already ask PC Engines? They might recognize the problem. Either 5536 or the driver may still be the problem, but I think it would be interesting to ping the vendor. If you'd rather collect more data first then you could compare with a different operating system running on the same hardware. //Peter -- 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: PPC Serial over Host USB
Avner Flesch wrote: 3.5 is end-of-life, but it should work for your testing for now. OK - what version do you recommend? Always use the latest version. What am I missing? A host controller driver for your hardware. //Peter -- 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: host to host usb transfer
Marek Floriańczyk wrote: If I say to them log into something like raspberry (without even a screen) prepare postgresql database dump, load database and so on... then I'm already lost, no one will do it. That is the approach of providing no administrative tool at all. I don't think anyone suggested that this is what you should do. What I came up with instead is that I prepare two applications. One will be running on linux box constantly, and other will have gui and can be run either on windows or on linux. In that gui application technician will be able to load database dump, files, configurations and send it to Linux box by usb cable. Why limit yourself to USB, when your piece of hardware is not actually a USB device? (You could of course work on *making* the rpi into a USB device, if using libusb in the host application is very important for you.) Now, I have some experience with libusb and if this usb bridge cable allows me to talk to other computer as If I was talking to a regular usb device, then I don't see why this would not work. Or correct me if I'm wrong. You are wrong. USB makes a quite significant distinction between host and device. It is simply not possible to talk to a host as if you were talking to a device. While a TCP/IP based administrative tool is one good and very common approach, USB does make enumeration easier for simple applications. I understand the appeal, but again, don't limit yourself. For configuring an embedded device I would either choose TCP/IP (most likely over SSH) or indeed USB, but if USB then I would make very sure that the embedded Linux device *is* a USB device. http://www.raspberrypi.org/phpBB3/viewtopic.php?t=8089p=97007 Explains that even if the software part would work, the rpi USB port is actually permanently wired to an ethernet chip. You lose. Look for an alternative platform which does what you want, instead of trying to design complicated software layers to compensate for what is essentially broken (for your purpose) hardware. //Peter -- 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
