Re: Sound Blaster USB X-Fi configuration problem
On 20.07.2013 05:44, Alan Stern wrote:
static int snd_usb_sb_x_fi_boot_quirk(struct usb_device *dev)
{
u16 buf = 1;
snd_printk(KERN_ERR X-Fi Surround 5.1 newer quirk\n);
snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
0, 0, buf, 2);
snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
0, 0, buf, 2);
if (buf == 0) {
snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0), 0x29,
USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_OTHER,
1, 2000, NULL, 0);
usb_reset_device(dev);
return -EAGAIN; //-ENODEV;
}
return 0;
}
This is the same as the Audigy function, except for the printk string
and the 2-byte buffer instead of the 1-byte buffer, right? Therefore I
suggest combining them into a single function. You can pass the string
and the buffer size as arguments.
There are the differences you mentioned (2 bytes buffer and printk
function, of course printk is for debugging only) but this is is not the
same as the Audigy since the message is sent twice (I am nor sure
whether it is necessary or not - Windows did that twice and so did I)
and a kind of reset is needed at the end in case of X-Fi
initialization (I made usb_reset_device(dev) but I am not sure whether
it is the only or optimal way - I have seen also other resets used in
other quirk functions). Without this reset card was not initialized
properly. This reset does not exist in case of Audigy quirk.
Sure, the 2 functions can be combined in one with some additional
arguments. I wonder only whether I should propose such solution - I have
no experience in kernel and drivers code, especially reading the
following in your message. But if you think I can do that I offer my
help. The only problem can be I do not have Audigy sound card to test it.
+ static int snd_usb_sb_x_fi_boot_quirk(struct usb_device *dev)
+ {
+u16 buf = 1;
+
+snd_printk(KERN_ERR X-Fi Surround 5.1 newer quirk\n);
+
+snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a,
+USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
+0, 0, buf, 2);
There's a serious problem here. It's present in most or all of the
quirk routines in this file, not just yours.
Namely, buffers used for USB transfers must not be allocated on the
stack; they must be allocated using kmalloc or a related function. The
reason is because some architectures are not capable of performing DMA
to addresses on the stack.
This is a good point which did not come to my mind due to lack of
experience. Fixing one or few functions seems reasonable easy, fixing
all in the whole file seems to be much more serious and responsible work.
Do you feel like fixing up all those routines? I suggest allocating
and deallocating a buffer in the function that calls the quirk
routines, and have it pass the buffer as an extra argument.
This is probably question to the community not just to me?
--
Best regards
Mariusz Grecki
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] TX throttling bug-fixing patch of AX88179_178A
From: Freddy Xin fre...@asix.com.tw Disable TSO and SG network features in reset() and bind() functions, and check the return value of skb_linearize() in tx_fixup() to prevent TX throttling. Signed-off-by: Freddy Xin fre...@asix.com.tw --- drivers/net/usb/ax88179_178a.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c index 1e3c302..eb71331 100644 --- a/drivers/net/usb/ax88179_178a.c +++ b/drivers/net/usb/ax88179_178a.c @@ -1029,7 +1029,7 @@ static int ax88179_bind(struct usbnet *dev, struct usb_interface *intf) dev-mii.supports_gmii = 1; dev-net-features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | - NETIF_F_RXCSUM | NETIF_F_SG | NETIF_F_TSO; + NETIF_F_RXCSUM; dev-net-hw_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM | NETIF_F_SG | NETIF_F_TSO; @@ -1173,7 +1173,9 @@ ax88179_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags) if (((skb-len + 8) % frame_size) == 0) tx_hdr2 |= 0x80008000; /* Enable padding */ - skb_linearize(skb); + if (skb_linearize(skb)) + return NULL; + headroom = skb_headroom(skb); tailroom = skb_tailroom(skb); @@ -1317,7 +1319,7 @@ static int ax88179_reset(struct usbnet *dev) 1, 1, tmp); dev-net-features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | - NETIF_F_RXCSUM | NETIF_F_SG | NETIF_F_TSO; + NETIF_F_RXCSUM; dev-net-hw_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM | NETIF_F_SG | NETIF_F_TSO; -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: udc: add gadget state kobject uevent
On Wed, Jul 17, 2013 at 10:36 AM, Peter Chen peter.c...@freescale.com wrote: On Mon, Jul 15, 2013 at 11:31:17PM -0700, Greg KH wrote: On Tue, Jul 16, 2013 at 11:49:07AM +0800, Rong Wang wrote: Hi Greg, The USB on our platform can change roles between HOST and GADGET, but it is not capable of OTG. That kind of sounds like the definition of OTG :) When the USB changes between roles the udev will run some scripts automatically according to the udev rules. What exactly does udev/userspace see when the roles change? And what can trigger the change in roles? The default role is GADGET, and we bind the g_mass_storage to the USB GADGET role. We should secure the back end file storage between the device and the host PC connecting to our device. We need to know when the GADGET is really connect to a host PC, then we can umount the file on the device and export it to the g_mass_storage. I thought you already get an event for this, otherwise no one would be able to properly deal with this. The question is since we default GADGET, so the g_mass_storage.ko is installed early but connecting to a host PC is randomly, But the udev has no idea when a host PC connects our device. So we consider it's reasonable to let the udev know the GADGET device state. Is there any alternative to our question? I thought we already export events for gadget device states, have you looked for them? I can't dig through the code at the moment, but this seems like a pretty common issue... If I understand correctly, what Rong wants is udev can be notified the udc state changes, like connect/disconnect event. Currently, we only export it to /sys. OK. Thanks for your share. And you develop a new utility rather than udev to monitor that file? And you probably create a work queue in your udc driver to do this work? Not yet, no one complains it, so I haven't added it. But, it is a useful user interface, Android has implemented similar functions at its gadget driver. 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: Sound Blaster USB X-Fi configuration problem
Alan Stern wrote: On Sat, 20 Jul 2013, Mariusz Grecki wrote: +u16 buf = 1; + +snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a, +USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER, +0, 0, buf, 2); There's a serious problem here. It's present in most or all of the quirk routines in this file, not just yours. Namely, buffers used for USB transfers must not be allocated on the stack; they must be allocated using kmalloc or a related function. This is what snd_usb_ctl_msg() does. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sound Blaster USB X-Fi configuration problem
On Sat, 20 Jul 2013, Clemens Ladisch wrote: Alan Stern wrote: On Sat, 20 Jul 2013, Mariusz Grecki wrote: + u16 buf = 1; + + snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a, + USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER, + 0, 0, buf, 2); There's a serious problem here. It's present in most or all of the quirk routines in this file, not just yours. Namely, buffers used for USB transfers must not be allocated on the stack; they must be allocated using kmalloc or a related function. This is what snd_usb_ctl_msg() does. Argh! I misread the code -- didn't see the snd_ prefix. :-( Never mind. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How should we handle isochronous underruns?
On Sat, 20 Jul 2013, Ming Lei wrote: No, we don't have to change every driver using isochronous URBs. Many of them set URB_ISO_ASAP on every URB -- in fact, AFAIK snd-usb-audio is the only one that has been fixed not to do this. OK, if you are sure just snd-usb-audio and very less drivers need the change, using the API only is correct way. I haven't checked in detail, but this seems very likely. But never mind. For a new API, how about void usb_new_iso_stream(struct usb_device *, struct usb_host_endpoint *); Does that look okay? Looks you missed one parameter of 'int on'. I don't understand. Why is another parameter needed? So do you only want to set streaming on and not streaming off? If so, that looks a bit weird, could you describe its usage? The new call doesn't turn streaming on or off. The driver does that by submitting URBs or not submitting them. The new call merely separates an old stream from a new one. It tells the HCD that the old stream (if any) is finished, so that any URBs submitted in the future will belong to a new stream. In particular, it tells the HCD that the next URB for this endpoint should be assigned to a time slot that will be visible to the hardware, instead of being assigned to the next time slot after the last packet of the previous URB (which has probably expired already). In short, it would simply tell the HCD to act as though the next URB has URB_ISO_ASAP set. For HCDs that act as though URB_ISO_ASAP was always set, the new call wouldn't do anything -- they would not need to implement it. (with extra overhead for every URB!) to fix a problem that ought to be In a normal system, the URB count won't be very much( 1000), and if you mean the overhead is from memory, I guess it won't cause real memory increase per URB for slab's sake. If you mean performance loss with set/get the single lockless/common variable, maybe we should focus on the big HCD lock, which might be the biggest bottle of USB protocol, :-) If you're talking about the hcd_urb_list_lock, note that it could easily be made hcd-specific. I haven't done that because the regions it protects are all very short, so there probably isn't very much contention. fixed by changing drivers. If only very less drivers need the change, I agree with you. Okay, good. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PROBLEM/BUG] mouse polling at only half rate on ohci_hcd
On Fri, 19 Jul 2013 sgtcapsl...@lavabit.com wrote: Can you provide usbmon traces showing what happens when the mouse is plugged in to an OHCI controller and when it is plugged in to an EHCI controller? Instructions are in Documentation/usb/usbmon.txt. Alan Stern Absolutely. Ahh, I'm not really sure if I should send them as attachments to this message or not, so I've decided to put them up on a paste site. Please let me know if you want them here instead. Here's that same mouse (Zowie EC1 eVo) plugged into a [native ehci] port on the board which hands it off to ohci: http://pastebin.com/auM1MavY And here it is when plugged into an external USB hub on one of the same ports, which causes it to use the ehci driver instead: http://pastebin.com/1r7BQSBw I think I see what's going on. The usbhid driver uses a single interrupt URB to receive data from the device. When the URB completes, it gets resubmitted to receive the next packet of data. The OHCI controller issues interrupts at frame boundaries, and it probably gets the information for upcoming interrupt transfers at the beginning of a frame. Thus, suppose some data is received during frame N. An interrupt occurs and the URB completes at the end of frame N. The usbhid driver processes the data and then resubmits the URB. By that time, however, it is already too late for the controller to handle it during frame N+1. It doesn't get handled until frame N+2. Since each frame is one millisecond, the maximum polling rate ends up being 500 Hz. With EHCI controllers, interrupts occur at the boundaries of microframes rather than frames. Thus, the usbhid driver gets the data and processes it after only 1/8 ms has elapsed, which leaves enough time to resubmit the URB before frame N+1 begins. This could be considered a bug in the usbhid driver. As far as I can see, the only way to fix it is to use two interrupts URBs rather than one. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sound Blaster USB X-Fi configuration problem
On Sat, 20 Jul 2013, Mariusz Grecki wrote: This is the same as the Audigy function, except for the printk string and the 2-byte buffer instead of the 1-byte buffer, right? Therefore I suggest combining them into a single function. You can pass the string and the buffer size as arguments. There are the differences you mentioned (2 bytes buffer and printk function, of course printk is for debugging only) but this is is not the same as the Audigy since the message is sent twice (I am nor sure whether it is necessary or not - Windows did that twice and so did I) You could try sending it once and see if it still works. and a kind of reset is needed at the end in case of X-Fi initialization (I made usb_reset_device(dev) but I am not sure whether it is the only or optimal way - I have seen also other resets used in Most likely it is the best way. other quirk functions). Without this reset card was not initialized properly. This reset does not exist in case of Audigy quirk. Adding a reset to the Audigy quirk probably won't hurt. But the only way to be sure is to try it with real hardware. Sure, the 2 functions can be combined in one with some additional arguments. I wonder only whether I should propose such solution - I have no experience in kernel and drivers code, especially reading the following in your message. But if you think I can do that I offer my help. The only problem can be I do not have Audigy sound card to test it. Under the circumstances, I guess we have to err on the safe side and keep the two functions separate. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] staging: dwc2: fix thinko in dwc2_hc_set_even_odd_frame()
From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Friday, July 19, 2013 1:00 PM On 07/19/2013 01:55 PM, Paul Zimmerman wrote: From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Thursday, July 18, 2013 11:01 PM ... I then wanted to try WiFi, so I plugged in a USB mouse/keyboard, and started X, trying to use GUI tools. Then I saw some issues. With just the USB mouse/keyboard attached (via a powered hub), and no WiFi device yet, they would work for a while, but pretty soon I kept seeing all USB devices just disappear; only the Linux Foundation 2.0 root hub would be left. Unplugging and replugging didn't fix this; I had to power-cycle. I wonder if there are issues with just USB interrupt transfers, which I assume both HID devices and the USB SD card plug/unplug notifications use?? Hi Stephen, Are you sure you added both of the new driver parameters to platform.c? I was seeing the same kind of hangs before I set .ahbcfg = 0x10. I'm afraid so. You can see the exact code I ran at: https://github.com/swarren/linux-rpi/commits/rpi_dev Yep, you're right. I can reproduce the issue under X. In my case I didn't see a problem until I connected a thumb drive and the WiFi dongle, though. I suspect the FIQ mods from the raspberrypi.org driver are needed to fix this. Hopefully we can get those folks on board pretty soon. I am still waiting for the SOBs from them so I can resubmit the scheduler patch, though. -- Paul -- 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 01/15] drivers: phy: add generic PHY framework
On Sat, Jul 20, 2013 at 08:49:32AM +0530, Kishon Vijay Abraham I wrote: Hi, On Saturday 20 July 2013 05:20 AM, Greg KH wrote: On Fri, Jul 19, 2013 at 12:06:01PM +0530, Kishon Vijay Abraham I wrote: Hi, On Friday 19 July 2013 11:59 AM, Greg KH wrote: On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote: Hi, On Friday 19 July 2013 11:13 AM, Greg KH wrote: On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote: + ret = dev_set_name(phy-dev, %s.%d, dev_name(dev), id); Your naming is odd, no phy anywhere in it? You rely on the sender to never send a duplicate name.id pair? Why not create your own ids based on the number of phys in the system, like almost all other classes and subsystems do? hmm.. some PHY drivers use the id they provide to perform some of their internal operation as in [1] (This is used only if a single PHY provider implements multiple PHYS). Probably I'll add an option like PLATFORM_DEVID_AUTO to give the PHY drivers an option to use auto id. [1] - http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html No, who cares about the id? No one outside of the phy core ever should, because you pass back the only pointer that they really do care about, if they need to do anything with the device. Use that, and then you can hmm.. ok. rip out all of the search for a phy by a string logic, as that's not Actually this is needed for non-dt boot case. In the case of dt boot, we use a phandle by which the controller can get a reference to the phy. But in the case of non-dt boot, the controller can get a reference to the phy only by label. I don't understand. They registered the phy, and got back a pointer to it. Why can't they save it in their local structure to use it again later if needed? They should never have to ask for the device, as the One is a *PHY provider* driver which is a driver for some PHY device. This will use phy_create to create the phy. The other is a *PHY consumer* driver which might be any controller driver (can be USB/SATA/PCIE). The PHY consumer will use phy_get to get a reference to the phy (by *phandle* in the case of dt boot and *label* in the case of non-dt boot). device id might be unknown if there are multiple devices in the system. I agree with you on the device id part. That need not be known to the PHY driver. How does a consumer know which label to use in a non-dt system if there are multiple PHYs in the system? That should be passed using platform data. Ick, don't pass strings around, pass pointers. If you have platform data you can get to, then put the pointer there, don't use a name. I don't think I understood you here :-s We wont have phy pointer when we create the device for the controller no?(it'll be done in board file). Probably I'm missing something. Why will you not have that pointer? You can't rely on the name as the device id will not match up, so you should be able to rely on the pointer being in the structure that the board sets up, right? Don't use names, especially as ids can, and will, change, that is going to cause big problems. Use pointers, this is C, we are supposed to be doing that :) thanks, greg k-h -- 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
Clock speed on RasPi?
Hi Stephen, With the mainline kernel, /proc/cpuinfo shows a bogoMips of ~460. The downstream raspberrypi.org kernel shows ~690. Changing the arm_freq setting in /boot/config.txt has no affect. Any idea why the difference? -- Paul -- 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: Clock speed on RasPi?
On Sat, Jul 20, 2013 at 10:04:16PM +, Paul Zimmerman wrote: Hi Stephen, With the mainline kernel, /proc/cpuinfo shows a bogoMips of ~460. The downstream raspberrypi.org kernel shows ~690. Changing the arm_freq setting in /boot/config.txt has no affect. Any idea why the difference? You really are worried about bogoMips? The calculation of it has recently changed in mainline, so that might be what you are seeing here. Otherwise, what does it matter? It's a fake number anyway :) greg k-h -- 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: Clock speed on RasPi?
From: Greg KH [mailto:g...@kroah.com] Sent: Saturday, July 20, 2013 3:11 PM On Sat, Jul 20, 2013 at 10:04:16PM +, Paul Zimmerman wrote: Hi Stephen, With the mainline kernel, /proc/cpuinfo shows a bogoMips of ~460. The downstream raspberrypi.org kernel shows ~690. Changing the arm_freq setting in /boot/config.txt has no affect. Any idea why the difference? You really are worried about bogoMips? The calculation of it has recently changed in mainline, so that might be what you are seeing here. Otherwise, what does it matter? It's a fake number anyway :) Well, the Pi is rather lacking when it comes to performance. I was just wondering if the bogoMips value indicated some problem with the hardware setup in the mainline kernel, or with the new bootloader. But if the bogoMips calculation has changed since 3.6, that indeed could explain it. -- Paul -- 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/BUG] mouse polling at only half rate on ohci_hcd
On 07/20/2013 01:27 PM, Alan Stern wrote: I think I see what's going on. The usbhid driver uses a single interrupt URB to receive data from the device. When the URB completes, it gets resubmitted to receive the next packet of data. The OHCI controller issues interrupts at frame boundaries, and it probably gets the information for upcoming interrupt transfers at the beginning of a frame. Thus, suppose some data is received during frame N. An interrupt occurs and the URB completes at the end of frame N. The usbhid driver processes the data and then resubmits the URB. By that time, however, it is already too late for the controller to handle it during frame N+1. It doesn't get handled until frame N+2. Since each frame is one millisecond, the maximum polling rate ends up being 500 Hz. With EHCI controllers, interrupts occur at the boundaries of microframes rather than frames. Thus, the usbhid driver gets the data and processes it after only 1/8 ms has elapsed, which leaves enough time to resubmit the URB before frame N+1 begins. This could be considered a bug in the usbhid driver. As far as I can see, the only way to fix it is to use two interrupts URBs rather than one. Alan Stern Thanks a lot for taking time to diagnose this, I appreciate it! I think I understand the general gist of what you've said. I'd love to be able to try and solve this or to write a patch, but I'm afraid I've never really done any kernel-related hacking before, and I'm not too familiar with how USB works... I'm extremely interested in writing patches for Linux in the future, so I'll be researching this. So if anybody wants to write a patch, or even give some tips on what I might need to research to do this myself in the future (I don't know what an URB is, tbh), I'd appreciate it in either case. Regards! -- 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: Clock speed on RasPi?
From: Paul Zimmerman Sent: Saturday, July 20, 2013 3:25 PM From: Greg KH [mailto:g...@kroah.com] Sent: Saturday, July 20, 2013 3:11 PM On Sat, Jul 20, 2013 at 10:04:16PM +, Paul Zimmerman wrote: Hi Stephen, With the mainline kernel, /proc/cpuinfo shows a bogoMips of ~460. The downstream raspberrypi.org kernel shows ~690. Changing the arm_freq setting in /boot/config.txt has no affect. Any idea why the difference? You really are worried about bogoMips? The calculation of it has recently changed in mainline, so that might be what you are seeing here. Otherwise, what does it matter? It's a fake number anyway :) Well, the Pi is rather lacking when it comes to performance. I was just wondering if the bogoMips value indicated some problem with the hardware setup in the mainline kernel, or with the new bootloader. But if the bogoMips calculation has changed since 3.6, that indeed could explain it. Ah, never mind. With the downstream 3.6.11 kernel, the bogoMips value is the same as with mainline. So the difference must be due to the change in bogoMips calculation since the older kernels. Sorry for the noise. -- Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][usbutils] lsusb: port to hwdb
Most of the information in usb.ids is now contained in udev's hwdb. First
attempt to query hwdb before falling back on the old file.
This would allow distributions to no longer ship (most of) usb.ids by default,
but rather keep all the usb device information in only one place (the hwdb).
This patch introduces a dependency on libusb = 196.
Cc: systemd-de...@lists.freedesktop.org
---
Makefile.am | 5 +++--
configure.ac | 2 ++
names.c | 62 ++--
3 files changed, 65 insertions(+), 4 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 1e85a1e..70b9de9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -23,11 +23,12 @@ lsusb_SOURCES = \
usbmisc.c usbmisc.h
lsusb_CPPFLAGS = \
- $(AM_CPPFLAGS) $(LIBUSB_CFLAGS) \
+ $(AM_CPPFLAGS) $(LIBUSB_CFLAGS) $(UDEV_CFLAGS) \
-DDATADIR=\$(datadir)\
lsusb_LDADD = \
- $(LIBUSB_LIBS)
+ $(LIBUSB_LIBS) \
+ $(UDEV_LIBS)
if HAVE_ZLIB
lsusb_CPPFLAGS += -DHAVE_LIBZ
diff --git a/configure.ac b/configure.ac
index adfb4b6..b4b0880 100644
--- a/configure.ac
+++ b/configure.ac
@@ -26,6 +26,8 @@ AM_CONDITIONAL([INSTALL_USBIDS], [test x$enable_usbids !=
xno])
PKG_CHECK_MODULES(LIBUSB, libusb-1.0 = 1.0.0)
+PKG_CHECK_MODULES(UDEV, libudev = 196)
+
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([
Makefile
diff --git a/names.c b/names.c
index 12cbd60..4b59213 100644
--- a/names.c
+++ b/names.c
@@ -3,6 +3,7 @@
* names.c -- USB name database manipulation routines
*
* Copyright (C) 1999, 2000 Thomas Sailer (sai...@ife.ee.ethz.ch)
+ * Copyright (C) 2013 Tom Gundersen (t...@jklm.no)
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -34,6 +35,8 @@
#include stdio.h
#include ctype.h
+#include libudev.h
+
#ifdef HAVE_LIBZ
#include zlib.h
#defineusb_filegzFile
@@ -118,6 +121,8 @@ static unsigned int hashnum(unsigned int num)
/* -- */
+static struct udev *udev = NULL;
+static struct udev_hwdb *hwdb = NULL;
static struct vendor *vendors[HASHSZ] = { NULL, };
static struct product *products[HASHSZ] = { NULL, };
static struct class *classes[HASHSZ] = { NULL, };
@@ -187,9 +192,27 @@ const char *names_countrycode(unsigned int countrycode)
return names_genericstrtable(countrycodes, countrycode);
}
+static const char *hwdb_get(const char *modalias, const char *key)
+{
+ struct udev_list_entry *entry;
+
+ udev_list_entry_foreach(entry,
udev_hwdb_get_properties_list_entry(hwdb, modalias, 0))
+ if (strcmp(udev_list_entry_get_name(entry), key) == 0)
+ return udev_list_entry_get_value(entry);
+
+ return NULL;
+}
+
const char *names_vendor(u_int16_t vendorid)
{
struct vendor *v;
+ char modalias[64];
+ const char *name;
+
+ sprintf(modalias, usb:v%04X*, vendorid);
+ name = hwdb_get(modalias, ID_VENDOR_FROM_DATABASE);
+ if (name)
+ return name;
v = vendors[hashnum(vendorid)];
for (; v; v = v-next)
@@ -201,6 +224,13 @@ const char *names_vendor(u_int16_t vendorid)
const char *names_product(u_int16_t vendorid, u_int16_t productid)
{
struct product *p;
+ char modalias[64];
+ const char *name;
+
+ sprintf(modalias, usb:v%04Xp%04X*, vendorid, productid);
+ name = hwdb_get(modalias, ID_MODEL_FROM_DATABASE);
+ if (name)
+ return name;
p = products[hashnum((vendorid 16) | productid)];
for (; p; p = p-next)
@@ -212,6 +242,13 @@ const char *names_product(u_int16_t vendorid, u_int16_t
productid)
const char *names_class(u_int8_t classid)
{
struct class *c;
+ char modalias[64];
+ const char *name;
+
+ sprintf(modalias, usb:v*p*d*dc%02X*, classid);
+ name = hwdb_get(modalias, ID_USB_CLASS_FROM_DATABASE);
+ if (name)
+ return name;
c = classes[hashnum(classid)];
for (; c; c = c-next)
@@ -223,6 +260,13 @@ const char *names_class(u_int8_t classid)
const char *names_subclass(u_int8_t classid, u_int8_t subclassid)
{
struct subclass *s;
+ char modalias[64];
+ const char *name;
+
+ sprintf(modalias, usb:v*p*d*dc%02Xdsc%02X*, classid, subclassid);
+ name = hwdb_get(modalias, ID_USB_SUBCLASS_FROM_DATABASE);
+ if (name)
+ return name;
s = subclasses[hashnum((classid 8) | subclassid)];
for (; s; s = s-next)
@@ -234,6 +278,13 @@ const char *names_subclass(u_int8_t classid, u_int8_t
subclassid)
const char *names_protocol(u_int8_t classid, u_int8_t subclassid, u_int8_t
protocolid)
{
struct protocol *p;
+ char modalias[64];
+ const char *name;
+
+ sprintf(modalias,
Re: [PATCH][usbutils] lsusb: port to hwdb
On Sun, Jul 21, 2013 at 02:52:09AM +0200, Tom Gundersen wrote: Most of the information in usb.ids is now contained in udev's hwdb. First attempt to query hwdb before falling back on the old file. This would allow distributions to no longer ship (most of) usb.ids by default, but rather keep all the usb device information in only one place (the hwdb). This patch introduces a dependency on libusb = 196. Cc: systemd-de...@lists.freedesktop.org Very nice, thanks so much for doing this. I'll go apply it and push out a new version of usbutils soon with this in it. Can this mean I can drop the usb.ids file from the usbutils package? I can't remember where hwdb is generated from, does it rely on the usb.ids file for the initial creation? thanks, greg k-h -- 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 01/15] drivers: phy: add generic PHY framework
On Sat, 20 Jul 2013, Greg KH wrote: That should be passed using platform data. Ick, don't pass strings around, pass pointers. If you have platform data you can get to, then put the pointer there, don't use a name. I don't think I understood you here :-s We wont have phy pointer when we create the device for the controller no?(it'll be done in board file). Probably I'm missing something. Why will you not have that pointer? You can't rely on the name as the device id will not match up, so you should be able to rely on the pointer being in the structure that the board sets up, right? Don't use names, especially as ids can, and will, change, that is going to cause big problems. Use pointers, this is C, we are supposed to be doing that :) Kishon, I think what Greg means is this: The name you are using must be stored somewhere in a data structure constructed by the board file, right? Or at least, associated with some data structure somehow. Otherwise the platform code wouldn't know which PHY hardware corresponded to a particular name. Greg's suggestion is that you store the address of that data structure in the platform data instead of storing the name string. Have the consumer pass the data structure's address when it calls phy_create, instead of passing the name. Then you don't have to worry about two PHYs accidentally ending up with the same name or any other similar problems. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PROBLEM/BUG] mouse polling at only half rate on ohci_hcd
On Sat, 20 Jul 2013, sgtcapslock wrote: This could be considered a bug in the usbhid driver. As far as I can see, the only way to fix it is to use two interrupts URBs rather than one. Alan Stern Thanks a lot for taking time to diagnose this, I appreciate it! I think I understand the general gist of what you've said. I'd love to be able to try and solve this or to write a patch, but I'm afraid I've never really done any kernel-related hacking before, and I'm not too familiar with how USB works... I'm extremely interested in writing patches for Linux in the future, so I'll be researching this. So if anybody wants to write a patch, or even give some tips on what I might need to research to do this myself in the future (I don't know what an URB is, tbh), I'd appreciate it in either case. If you don't know anything about USB programming in the Linux kernel, you've got a ways to go before you can write patches. There are resources online that can help. For example, there's a chapter on USB programming in the Linux Device Drivers book (3rd edition), which is freely available. There are also some files in the Documentation directory of the kernel source that explain how to format and submit patches. I suggest you get in touch with Jiri Kosina, the maintainer of the usbhid driver about this. He ought to be able to help you get going and explain what needs to be changed. That's why I CC'ed him on the previous email. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote: On Sat, 20 Jul 2013, Greg KH wrote: That should be passed using platform data. Ick, don't pass strings around, pass pointers. If you have platform data you can get to, then put the pointer there, don't use a name. I don't think I understood you here :-s We wont have phy pointer when we create the device for the controller no?(it'll be done in board file). Probably I'm missing something. Why will you not have that pointer? You can't rely on the name as the device id will not match up, so you should be able to rely on the pointer being in the structure that the board sets up, right? Don't use names, especially as ids can, and will, change, that is going to cause big problems. Use pointers, this is C, we are supposed to be doing that :) Kishon, I think what Greg means is this: The name you are using must be stored somewhere in a data structure constructed by the board file, right? Or at least, associated with some data structure somehow. Otherwise the platform code wouldn't know which PHY hardware corresponded to a particular name. Greg's suggestion is that you store the address of that data structure in the platform data instead of storing the name string. Have the consumer pass the data structure's address when it calls phy_create, instead of passing the name. Then you don't have to worry about two PHYs accidentally ending up with the same name or any other similar problems. Close, but the issue is that whatever returns from phy_create() should then be used, no need to call any find functions, as you can just use the pointer that phy_create() returns. Much like all other class api functions in the kernel work. thanks, greg k-h -- 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
