Re: static usb device configuration
On 13 December 2010 07:49, Emanuel Haupt eha...@freebsd.org wrote:
Is there any way I can make sure that the following device:
ugen1.3: product 0x6001 vendor 0x0403 at usbus1, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON
bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x
bDeviceSubClass = 0x
bDeviceProtocol = 0x
bMaxPacketSize0 = 0x0008
idVendor = 0x0403
idProduct = 0x6001
bcdDevice = 0x0400
iManufacturer = 0x no string
iProduct = 0x no string
iSerialNumber = 0x0003 Reader 195
bNumConfigurations = 0x0001
Is always registered as:
/dev/usb/1.3.0
You would be better making a symlink using devd rules, something like
notify 100 {
match system USB;
match subsystem DEVICE;
match typeATTACH;
match vendor 0x0403;
match product 0x6001;
action ln -s /dev/$cdev /dev/mydevice;
};
Andrew
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] USBdump patches
On 24 November 2010 11:19, Hans Petter Selasky hsela...@c2i.net wrote:
Hi,
Please find attached official usbdump patch from HPS trying to re-use as much
as possible of Weongyo's code which was committed not long ago. You need to
SVN up to the latest 9-current.
@@ -270,7 +122,7 @@
* The kernel needs to be able to verify an application's filter code.
* Otherwise, a bogus program could easily crash the system.
*/
-static int
+static uint8_t
usbpf_validate(const struct usbpf_insn *f, int len)
{
Not related to the patch as a whole, but changing the return code of a
yes/no function from int to uint8_t doesn't save anything and I think
is less readable.
Andrew
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] USBdump patches
On 24 November 2010 13:36, Jung-uk Kim j...@freebsd.org wrote: On Tuesday 23 November 2010 07:18 pm, Weongyo Jeong wrote: - BPF was normally for ethernet frames (most operations were based on mbuf including the machine filter and there were a lot of assumptions the input buffer is mbuf type. For example, handling BPF_LD|BPF_W|BPF_ABS). However the USB packet isn't like mbuf style that it's just a linear buffer. So the most important code or assumption wasn't compatible. BPF can deal with linear buffer just fine. For example, ng_bpf(4) does it. Please see sys/netgraph/ng_bpf.c. - Just making the patch for BPF code, it looked like a trick or a hack to me because I couldn't define what BPF should be. If you don't want to touch bpf.c for some reason, netgraph(4) (- ng_bpf) may be an alternate solution for you. - I could not define BPF exactly myself that what BPF should cover. I agreed with that BPF is for ethernet packet filtering but could not make sure myself that BPF could cover USB packets. BPF is a generic packet filter machine, i.e., bytecode is generic enough for any type of data stream. I agree that this is the best way forward, if it can be achieved. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] USBdump patches
On 24 November 2010 18:46, Weongyo Jeong weongyo.je...@gmail.com wrote: On Wed, Nov 24, 2010 at 01:59:47PM +1300, Andrew Thompson wrote: On 24 November 2010 13:36, Jung-uk Kim j...@freebsd.org wrote: On Tuesday 23 November 2010 07:18 pm, Weongyo Jeong wrote: - BPF was normally for ethernet frames (most operations were based on mbuf including the machine filter and there were a lot of assumptions the input buffer is mbuf type. For example, handling BPF_LD|BPF_W|BPF_ABS). However the USB packet isn't like mbuf style that it's just a linear buffer. So the most important code or assumption wasn't compatible. BPF can deal with linear buffer just fine. For example, ng_bpf(4) does it. Please see sys/netgraph/ng_bpf.c. - Just making the patch for BPF code, it looked like a trick or a hack to me because I couldn't define what BPF should be. If you don't want to touch bpf.c for some reason, netgraph(4) (- ng_bpf) may be an alternate solution for you. - I could not define BPF exactly myself that what BPF should cover. I agreed with that BPF is for ethernet packet filtering but could not make sure myself that BPF could cover USB packets. BPF is a generic packet filter machine, i.e., bytecode is generic enough for any type of data stream. I agree that this is the best way forward, if it can be achieved. Attached is what I really wanted to do. USB pf is greatly simplified and perfectly satisfy me. It'll fully benefit from changes of BPF code. I'll commit this version into HEAD if no objections. Looks good. Is this compatible with the wireshark pcap format? Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [CFR] add usb_sleepout.[ch]
On 31 October 2010 12:19, Weongyo Jeong weongyo.je...@gmail.com wrote: Hello USB guys, The following patch is to add a implementation, called `sleepout'. Please reviews. I'd like to commit it into HEAD if no objections. Adds `sleepout' prototype which is a comic combination of callout(9) and taskqueue(8) only for USB drivers to implement one step timer. In current USB drivers using callout(9) interface they all have two step execution flow as follows: 1. callout callback is fired by the interrupt context. Then it needs to pass it to USB process context because it could sleep(!) while callout(9) don't allow it. 2. In the USB process context it operates USB commands that most of times it'd be blocked at least 125 us (it'd be always true for USB) I think it is a good addition. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: FYI: USB 3.0 support and the XHCI driver is now fully committed to FreeBSD-current
On 6 October 2010 10:58, Mark Atkinson atkin...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/05/2010 11:39, Mark Atkinson wrote: On 10/05/2010 10:09, Mark Atkinson wrote: Root mount waiting for: usbus3 usbus0 [hang, waits forever...] Well reverting to r213377 exhibits similar behavior, so I guess this is not suspect. I'll keep reverting until I find the breakage. Wish I had kept his machine on a closer track with current: r212532: working r212553: fail r212541 seems to be the only likely candidate between these ranges. Maybe you could try before and after. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [panic] Race in IEEE802.11 layer towards device drivers
On 8 July 2010 07:13, Hans Petter Selasky hsela...@c2i.net wrote: Hi, When supplying wpa_supplicant.conf with incorrect passwords, but a valid SSID, I have seen kernel panics several times when using USB based WLAN dongles. When only supplying a valid password, no panic has been seen. How to reproduce: 1) configure invalid password 2) wpa_cli: reconfigure 3) configure valid password 4) wpa_cli: reconfigure 5) goto 1 The USB commands which are executed inside the newstate callback usually take very little time, but still not as little time as PCI read/writes. I've forced slower operation in the newstate callback, and can reproduce warning printouts from the IEEE802.11 layer in FreeBSD. Try to apply the following patch to your USB code: http://p4web.freebsd.org/@@180604?ac=10 In my opinion the deferring of all states to a single task is wrong. There should be at least one task per possible state, and the queuing mechanism should follow the last-queued is last executed rule. This is not the case with the task-queue mechanism in the kernel. This turned out to be refcounting of the ieee80211_node struct which was causing this panic. vap-iv_bss can be freed at any time so all users of it need to bump the refcount to use it safely. This patch should fix the panic in the rum driver. http://people.freebsd.org/~thompsa/rum_node_refcnt.diff There are other places where it is still an issue such as the ieee80211_tx_mgt_timeout callout which havnt been addressed yet, and of course all other ieee80211 drivers. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [panic] Race in IEEE802.11 layer towards device drivers
On 8 July 2010 07:13, Hans Petter Selasky hsela...@c2i.net wrote: Hi, When supplying wpa_supplicant.conf with incorrect passwords, but a valid SSID, I have seen kernel panics several times when using USB based WLAN dongles. When only supplying a valid password, no panic has been seen. How to reproduce: 1) configure invalid password 2) wpa_cli: reconfigure 3) configure valid password 4) wpa_cli: reconfigure 5) goto 1 The USB commands which are executed inside the newstate callback usually take very little time, but still not as little time as PCI read/writes. I've forced slower operation in the newstate callback, and can reproduce warning printouts from the IEEE802.11 layer in FreeBSD. Try to apply the following patch to your USB code: http://p4web.freebsd.org/@@180604?ac=10 In my opinion the deferring of all states to a single task is wrong. There should be at least one task per possible state, and the queuing mechanism should follow the last-queued is last executed rule. This is not the case with the task-queue mechanism in the kernel. You dont say why it should be this way, do you have an example of a problem this fixes? I think the single state thread is correct. The whole thing works on state transitions, you dont just set a state. Description of panics. I didn't have core dump enabled on this box, so please bear over with the following hand-written notes: 1) A vap-iv_bss == NULL, inside ratectl task in RUM driver. 2) A memcpy() fails inside the iee80211...newstate_cb() 3) This and similar printouts are seen: wlan0: ieee80211_new_state_locked: pending AUTH - ASSOC transition lost Can you see if you can get a core dump, or at least a DDB trace and the output from `show vap addr` Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/145184: GENERIC can't mount root from USB on Asus EEE
The following reply was made to PR usb/145184; it has been noted by GNATS. From: Andrew Thompson thom...@freebsd.org To: Gnats bug-follo...@freebsd.org Cc: Eir Nym eir...@gmail.com Subject: Re: usb/145184: GENERIC can't mount root from USB on Asus EEE Date: Tue, 30 Mar 2010 20:54:10 +1300 Kernel doesn't see any USB disks (HDD and flash) on boot. After reinsert flash disk, kernel see device, but can't mount root from it (doesn't list it as possible boot GEOM). This problem is only on my EEE. desktop computer bootup well. You can set kern.cam.boot_delay=4 in /boot/loader.conf in order to boot. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/145184: GENERIC can't mount root from USB on Asus EEE
On 30 March 2010 23:11, Arseny Nasokin eir...@gmail.com wrote: On 30 Mar 2010, at 08:00, Andrew Thompson thom...@freebsd.org wrote: The following reply was made to PR usb/145184; it has been noted by GNATS. From: Andrew Thompson thom...@freebsd.org To: Gnats bug-follo...@freebsd.org Cc: Eir Nym eir...@gmail.com Subject: Re: usb/145184: GENERIC can't mount root from USB on Asus EEE Date: Tue, 30 Mar 2010 20:54:10 +1300 Kernel doesn't see any USB disks (HDD and flash) on boot. After reinsert flash disk, kernel see device, but can't mount root from it (doesn't list it as possible boot GEOM). This problem is only on my EEE. desktop computer bootup well. You can set kern.cam.boot_delay=4 in /boot/loader.conf in order to boot. I've tried up set this value up to 10-15. This is not work. I also tryed put this option in defaults/loader.conf to test It may be in milliseconds, try 4000. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED]
On Tue, Jan 19, 2010 at 05:12:17PM +0800, Wilkinson, Alex wrote: 0n Thu, Jan 14, 2010 at 10:03:29PM +1300, Andrew Thompson wrote: On Thu, Jan 14, 2010 at 04:48:31PM +0800, Wilkinson, Alex wrote: 0n Thu, Jan 14, 2010 at 09:24:47AM +0100, Hans Petter Selasky wrote: I think Andrew made a fixed port which you can test. Can you please point me in the direction to this ? I'l update the tarball tomorrow and send it out. Got these errors: [FreeBSD 9.0-CURRENT #0 r202270: Thu Jan 14 11:20:04 WST 2010] === Building for webcamd-0.1.0 Warning: Object directory not changed from original /usr/ports/multimedia/webcamd/work/webcamd-0.1.0 cc -O2 -pipe -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/v4l-dvb/linux/drivers/media/video/gspca -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/v4l-dvb/linux/include -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/v4l-dvb/linux -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0 -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/dummy -DCONFIG_VIDEO_V4L1_COMPAT -DHAVE_WEBCAMD -include webcamd_global.h -O2 -Wall -Wno-pointer-sign -fvisibility=hidden -std=gnu99 -fstack-protector -c webcamd.c webcamd.c:37:23: error: video4bsd.h: No such file or directory webcamd.c:55: error: 'V4B_ALLOC_UNIT_MAX' undeclared here (not in a function) webcamd.c: In function 'main': webcamd.c:126: error: storage size of 'cmd' isn't known webcamd.c:176: error: 'V4B_DEVICES_MAX' undeclared (first use in this function) Do you have CFLAGS set in /etc/make.conf by chance? Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED]
On Tue, Jan 19, 2010 at 04:38:28PM +0100, Dag-Erling Sm??rgrav wrote: Hans Petter Selasky hsela...@c2i.net writes: Please check /etc/make.conf and replace any CFLAGS= with CFLAGS+= Bzzt, wrong. It will make no difference whatsoever; make.conf is included by sys.mk before the Makefile itself is read, so the Makefile overrides make.conf, not the other way around. I have tested this with CFLAGS=-g in /etc/make.conf /usr/ports/multimedia/webcamd# make -dA ... Global:CFLAGS = -g -I/usr/local/include ... (cd /usr/ports/multimedia/webcamd/work/webcamd-0.1.0; if ! /usr/bin/env SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local X11BASE=/usr/local MOTIFLIB=-L/usr/local/lib -lXm -lXp LIBDIR=/usr/lib CC=cc CFLAGS=-g -I/usr/local/include CXX=c++ CXXFLAGS=-g -I/usr/local/include MANPREFIX=/usr/local BSD_INSTALL_PROGRAM=install -s -o root -g wheel -m 555 BSD_INSTALL_SCRIPT=install -o root -g wheel -m 555 BSD_INSTALL_DATA=install -o root -g wheel -m 444 BSD_INSTALL_MAN=install -o root -g wheel -m 444 make -f M akefile all; then if [ x != x ] ; then echo === Compilation failed unexpectedly.; (echo ) | /usr/bin/fmt 75 79 ; fi; false; fi) ... Global:CFLAGS = -g So CFLAGS is being properly passed to the /usr/ports/multimedia/webcamd/work/webcamd-0.1.0/Makefile via the environment but its getting overridden and causing the reported build error. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED]
On Thu, Jan 14, 2010 at 04:48:31PM +0800, Wilkinson, Alex wrote: 0n Thu, Jan 14, 2010 at 09:24:47AM +0100, Hans Petter Selasky wrote: I think Andrew made a fixed port which you can test. Can you please point me in the direction to this ? I'l update the tarball tomorrow and send it out. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: FreeBSD - support for DisplayLink devices?
On Wed, Nov 18, 2009 at 10:47:19PM +0100, Hans Petter Selasky wrote: On Wednesday 18 November 2009 22:44:04 Torfinn Ingolfsen wrote: On Wed, 18 Nov 2009 22:32:23 +0100 Torfinn Ingolfsen torfinn.ingolf...@broadpark.no wrote: Today I got a UM-70[5] monitor made by Lilliput, this is what /var/log/messages says when I connectd it to my 7.2-stable machine: Oh, I forgot to tell the age of this -stable: ti...@kg-v2$ uname -a FreeBSD kg-v2.kg4.no 7.2-STABLE FreeBSD 7.2-STABLE #1: Fri Oct 30 19:46:58 CET 2009 r...@kg-v2.kg4.no:/usr/obj/usr/src/sys/V2 amd64 Is there are userland driver using libusb for your device? libdlo mentioned in the original email is a userland driver using libusb. It should just work. Note for FreeBSD 7 and below you will need to install the devel/libusb port. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: aue0 detected as ue0 on 8.0-RC2
On Tue, Nov 03, 2009 at 09:55:01AM -0800, Pyun YongHyeon wrote: On Tue, Nov 03, 2009 at 10:10:47AM +, Gavin Atkinson wrote: [freebsd-current cc'd, as that was where the thread started, but this Hmm, this looks like a serious bug, possibly in the new USB subsystem (HPS CC'd). I've got an axe(4) device, which also does the same: ugen7.3: vendor 0x0b95 at usbus7 axe0: vendor 0x0b95 product 0x7720, rev 2.00/0.01, addr 3 on usbus7 axe0: PHYADDR 0xe0:0x10 miibus1: MII bus on axe0 ukphy0: Generic IEEE 802.3u media interface PHY 16 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: USB Ethernet on axe0 ue0: Ethernet address: 00:50:b6:05:57:a7 ue0: link state changed to DOWN I'm not sure this is feature of new USB or bug. I don't have strong objections on current behavior but looks like I'm seeing Linux behavior. Traditionally all network interfaces used their own driver name. I think this change should be documented in UPDATING. I have added an UPDATING entry in 198859. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB polling
2009/7/11 Hans Petter Selasky hsela...@c2i.net: On Friday 10 July 2009 19:20:01 Andrew Thompson wrote: Hi, The one usb task that is still an issue for 8.0 is the polling support. The code needs to call into the host controller driver to check if the usb descriptor has been marked as done and call the completion callback. I am now traveling so cant look at it, if anyone wants to have a look it would be fantastic. This is needed for places where a usb keyboard is used and interrupts are disabled (root mount, DDB). Hi, Probably we can implement USB polling with minimal transfer support. That basically means: - no timeouts - no automatic clear-stall Only support for ukbd and umass. Shouldn't be too hard. Thats pretty much what we need, at least for 8.0. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
USB polling
Hi, The one usb task that is still an issue for 8.0 is the polling support. The code needs to call into the host controller driver to check if the usb descriptor has been marked as done and call the completion callback. I am now traveling so cant look at it, if anyone wants to have a look it would be fantastic. This is needed for places where a usb keyboard is used and interrupts are disabled (root mount, DDB). regards, Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
usb headers
Hi, Here is a patch that I want to get in, the changes are - Make usb_xfer opaque, the drivers can not grub around inside it - Reduce the number if headers needed for a usb driver, the common case is just usb.h and usbdi.h http://people.freebsd.org/~thompsa/usb_usbdi10.diff Any objections? Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB Video Class support
On Wed, Apr 01, 2009 at 08:33:33AM -0500, Engineering wrote: I have a driver based off ugen. Hans Petter helped me get started on it - it should be using his new stack It was built for a custom embedded application, so the functionality is limited to just what I needed to get it going. It works with 7 out of the 10 different Chinese cameras I have laying around :) I'm sure my coding style violates every FreeBSD standard, there is no documentation, and very few comments, but if someone wants it for a working framework to create a 'real' driver, they are welcome to it. You may want to run it past j...@freebsd.org (http://wiki.freebsd.org/HDTV) Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Proposed USB data buffer changes
Hi, I want the USB peripheral driver API to be solid before 8.0 so things dont bite us down the line. I have discussed this privately with Hans already and want to put it out for public consumption. With the new USB code the buffer management has been merged into the xfer structure and this dictates the layout of the usb drivers and how locking is performed. This uses a state machine (my attempt to show below) |- |- XFER -| -| | | | | - callback_fn - | | | | | - SETUP (copyin) -| | | | - COMPLETE (copyout) -| It can take an external buffer instead of the copyin/out but it doesnt really simplify things at all. The problems I see with this approach are 1. It is in contrast to other major operating systems, making porting drivers harder. Windows, Linux and oldUSB all use a URB style of data handling. 2. It greatly complicates locking as the xfer lock can not be dropped until the xfer is resubmitted. This requirement to hold the lock creates a big problem for get/put of data to another layer (eg TTY), to avoid lock order reversals the drivers are generally written to share the lock with the lower/upper layer (eg TTY). 3. In the general case data can not be directly queued on the xfer (must be picked up by the state machine callback). This limits the options for designing a driver and may require the driver to implement a queue. I think its vital that we separate out the data buffers from the xfer (its actually a pipe in usb speak). It should draw from the Linux API which is simple and I believe works quite well. The data buffer is represented as a usb URB which is allocated either at attach or on the fly and then queued on the xfer (pipe) for processing. An arbitrary number of URB buffers can be on the queue. As the buffer would only have a single reference it would not need explicit locking, the callback would not need the xfer lock to be held at all and this would make it _much_ easier to handoff the data without LOR. This reduction in locking means that the driver and the xfer do not need to share a lock either, something that is mandatory now. The xfer can have a private lock for enqueue/start/stop. Example functions could be, usb_alloc_urb - Creates a URB representing data and housekeeping, the data section can be allocated or passed in from say a mbuf. This can also perform the DMA foo. usb_submit_urb - Queues the URB on the usb pipe. I dont think this would take much work. The xfer callbacks would be changed to take a URB and a few changes to queuing. It was mentioned the reason for this approach was to preallocate and do DMA setup on attach but this can still easily be done with the above. Comments? cheers, Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usbdevs -v
On Sun, Mar 22, 2009 at 07:15:04AM -0600, M. Warner Losh wrote: So what's the new way to say usbdevs -v? usbconfig list doesn't list device IDs. And devinfo doesn't show a device unless it is attached to a driver. There is an open task on the todo to add usbdevs compat to usbconfig. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usbdevs -v
On Sun, Mar 22, 2009 at 03:17:15PM -0400, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans Petter Selasky wrote: On Sunday 22 March 2009, M. Warner Losh wrote: So what's the new way to say usbdevs -v? usbconfig list doesn't list device IDs. And devinfo doesn't show a device unless it is attached to a driver. usbconfig dump_device_desc | grep id Is this usbconfig interface planned to be the only remaining tool? Having only those difficult to remember long form commands makes this tool quite user unfriendly. In my own system, I'm going to have to implement a shell shim, to help me out. Doesn't this seem hard to remember, to anyone else? As I have already said on this thread there is an open task to implement usbdevs compat to usbconfig. Once this is done the problem is moot :) Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: libusb-1.x -- is it availiable on FreeBSD?
On Fri, Mar 20, 2009 at 02:43:04PM +0300, Lev Serebryakov wrote: Hello, Freebsd-usb. Some software (with Linux origins, of course), which I want to port, uses libusb1 (libusb-1.0). Is it availiable on FreeBSD? It seems, that `ports/devel/libusb' is something very different... Libusb 1.0 is not yet supported. ports/devel/libusb gives you libusb 0.1 (will be part of the base OS in 8.0). Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: openct port and USB2
On Wed, Mar 18, 2009 at 08:04:48PM -0400, Mike Tancsa wrote: At 05:40 PM 3/18/2009, Andrew Thompson wrote: On Wed, Mar 18, 2009 at 04:15:46PM -0400, Mike Tancsa wrote: Hi, I was trying to see if OpenCT and OpenSC work under the new USB regime, but openCT doesnt compile now. Are there any tricks to get it to compile and or work ? Can you try this patch. http://people.freebsd.org/~thompsa/openct.diff Thanks! It does build now. However, not all of the bits seem to be working just yet It should be working as of r190185, please try again. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: openct port and USB2
On Wed, Mar 18, 2009 at 04:15:46PM -0400, Mike Tancsa wrote: Hi, I was trying to see if OpenCT and OpenSC work under the new USB regime, but openCT doesnt compile now. Are there any tricks to get it to compile and or work ? Can you try this patch. http://people.freebsd.org/~thompsa/openct.diff Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
uscanner sane
Hi, I am looking into fixing sane-backends and see that the uscanner driver is not needed at all. I wonder if we should follow Linux on this and remove it in favour of libusb? uscanner is just a simple wrapper around a fifo anyway, it has no logic. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: openct port and USB2
On Wed, Mar 18, 2009 at 08:04:48PM -0400, Mike Tancsa wrote: At 05:40 PM 3/18/2009, Andrew Thompson wrote: On Wed, Mar 18, 2009 at 04:15:46PM -0400, Mike Tancsa wrote: Hi, I was trying to see if OpenCT and OpenSC work under the new USB regime, but openCT doesnt compile now. Are there any tricks to get it to compile and or work ? Can you try this patch. http://people.freebsd.org/~thompsa/openct.diff Thanks! It does build now. However, not all of the bits seem to be working just yet Thats odd, its working for me. 1[i7]# opensc-tool -l [opensc-tool] reader-pcsc.c:996:pcsc_detect_readers: returning with: No readers found No smart card readers found. % opensc-tool -l Readers known about: Nr.Driver Name 0 openct Aladdin eToken PRO 1 openct Aladdin eToken PRO 64k 0[i7]# ps -auxww | grep if root 64638 0.0 0.1 3328 1640 ?? Ss7:57PM 0:00.00 /usr/local/sbin/ifdhandler -H etoken64 usb (null)/usb//dev/usb//dev/ugen1.2 root4433 0.0 0.1 3352 1548 ?? Ss5:22PM 0:00.01 /usr/local/sbin/ifdhandler -H etoken usb (null)/usb//dev/usb//dev/ugen1.3 root4435 0.0 0.1 3352 1548 ?? Ss5:22PM 0:00.01 /usr/local/sbin/ifdhandler -H etoken64 usb (null)/usb//dev/usb//dev/ugen1.2 Does 'ldd /usr/local/sbin/ifdhandler' show it linked to /usr/lib/libusb.so.1 ? Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: problem with usb printer
On Sun, Mar 15, 2009 at 02:55:04AM +0100, Alexander Best wrote: i recompiled my kernel with the p4-files, but still nothing get's printed. this is what i get when attaching the device: ugen0.3: Samsung Electronics Co., Ltd. at usbus0 ulpt_probe:472: ulpt_attach:498: sc=0xc5a4c900 ulpt0: Samsung Electronics Co., Ltd. Samsung ML-1510_700, class 0/0, rev 1.10/1.00, addr 3 on usbus0 ulpt_attach:538: setting alternate config number: 0 ulpt0: using bi-directional mode and this when i try to print something: ulpt_reset:164: ulpt_write_callback:203: state=0x0 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x1 i also enabled debugging output in the cups config file, but that didn't reveal any errors. right now i'm trying to build a kernel with the old usb stack to see if the problem get's solved. if the problem then still exists cups must be causing the problems. unfortunately building the kernel with the old usb stack fails: /usr/src/sys/legacy/dev/usb/ehci.c:84:27: error: dev/usb/usbdi.h: No such file or directory You need to add makeoptionsWITH_LEGACY to your kernel config so it can find the old usb headers. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2 makes moused insane
On Tue, Mar 10, 2009 at 04:25:55PM +0100, Hans Petter Selasky wrote: On Tuesday 10 March 2009, Renato Botelho wrote: http://freebsd.pastebin.com/f2831347 Try this patch: http://perforce.freebsd.org/chv.cgi?CH=159001 A regular diff for those not familiar with the p4web interface. http://people.freebsd.org/~thompsa/usb_hid.diff Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Latest kernel breaks scanner
On Mon, Mar 09, 2009 at 07:39:31AM -0600, M. Warner Losh wrote: In message: 200903091404.34912.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Monday 09 March 2009, M. Warner Losh wrote: : In message: 200903091233.55089.hsela...@c2i.net : : Hans Petter Selasky hsela...@c2i.net writes: : : On Sunday 08 March 2009, Andrew Thompson wrote: : : On Sun, Mar 08, 2009 at 03:43:53PM -0600, M. Warner Losh wrote: : : In message: 20090308203157.gc30...@citylink.fud.org.nz : : : : Andrew Thompson thom...@freebsd.org writes: : : : On Sun, Mar 08, 2009 at 01:06:59PM -0600, M. Warner Losh wrote: : : : Sigh. Had a working system from Mar 4th. Upgraded now it : : : doesn't work. Scanner not found by xsane. : : : : : : Are you sure its not this? : : : : : : 20090227: : : :The /dev handling for the new USB stack has changed, a : : :buildworld/installworld is required for libusb20. : : : : Yes. Been there, done that. Also have the libmap.conf changes in : : place for old binaries that had worked for months before that. xsane : : used to just work in this setup, but now fails. Looks like some kind : : of mismatch in the ABI: : : : : found USB scanner (UNKNOWN vendor and product) at device : : /dev/uscanner0 : : : : Not sure what would have caused that. Before you spend too much time on : : this you may want to note that the integration patches for libusb into : : the ports build will likely be committed tomorrow. This will bump the ^^ : : port numbers so the affected ports rebuild, hopefully sane with DTRT : : after that. : : : : Maybe you need to chown or rm /dev/uscanner0 to enforce use of libusb : : backend? : : never had to do that before... : : Or recompile all of the sane backends. Probably an IOCTL on the uscanner0 is : broken, and the fallback to libusb backend will maybe solve your problem : temporarily if you rm /dev/uscanner0 . Can't do it. devel/libusb is broken. Been there tried that: Didn't work. I do know that it has *NEVER* found the device when I don't have uscanner loaded, even when ugen was loaded... : Actually that is another question: : : Should we remove ID's from uscanner.c which will work fine attaching through : the libusb backend ? Unlikely, given my experience that it appears to be required... Anyway, it is going to be at least a week before I can do anything on this again because the scanner is at home right now, and I'm in the airport waiting for my flight to AsiaBSDCon 2009... This is about to be fixed, see above. Hopefully everything is good on your return :) Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb touchpad not working properly on CURRENT with usb2
On Mon, Mar 09, 2009 at 04:19:51PM +0200, Boris Kotzev wrote: Try the following patch: http://perforce.freebsd.org/chv.cgi?CH=158916 Repeat with ums debugging turned on. I think I see what is wrong now. --HPS The touchpad is functioning properly now! Committed in r189583. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Latest kernel breaks scanner
On Sun, Mar 08, 2009 at 01:06:59PM -0600, M. Warner Losh wrote: Sigh. Had a working system from Mar 4th. Upgraded now it doesn't work. Scanner not found by xsane. Are you sure its not this? 20090227: The /dev handling for the new USB stack has changed, a buildworld/installworld is required for libusb20. Does usbconfig list your devices? Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Latest kernel breaks scanner
On Sun, Mar 08, 2009 at 03:43:53PM -0600, M. Warner Losh wrote: In message: 20090308203157.gc30...@citylink.fud.org.nz Andrew Thompson thom...@freebsd.org writes: : On Sun, Mar 08, 2009 at 01:06:59PM -0600, M. Warner Losh wrote: : Sigh. Had a working system from Mar 4th. Upgraded now it doesn't : work. Scanner not found by xsane. : : Are you sure its not this? : : 20090227: :The /dev handling for the new USB stack has changed, a :buildworld/installworld is required for libusb20. Yes. Been there, done that. Also have the libmap.conf changes in place for old binaries that had worked for months before that. xsane used to just work in this setup, but now fails. Looks like some kind of mismatch in the ABI: found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0 Not sure what would have caused that. Before you spend too much time on this you may want to note that the integration patches for libusb into the ports build will likely be committed tomorrow. This will bump the port numbers so the affected ports rebuild, hopefully sane with DTRT after that. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Low perfomance when read from usb flash drive
On Wed, Mar 04, 2009 at 10:01:36AM +0100, Hans Petter Selasky wrote: On Wednesday 04 March 2009, M. Warner Losh wrote: In message: 200903040922.48163.hsela...@c2i.net : I am looking at using FreeBSD in an embedded product. I have not : examined your ehci software, but I am aware of how Linux and other : OSes run the controller. : : Why are you taking an interrupt every uFrame SOF? : : If the transaction completes before 125us we take the interrupt before : 125us. The problem is that the interrupt delay becomes critical to : performance when the interrupt rate is close to the interrupt limitation. : : For example: : : Transferring 13Mbyte/sec at blocksize equal to 65536 bytes generates 600 : interrupts. Hence the Mass Storage state machine has three steps the : throughput is computed like (600/3)*65536 bytes. If we on the average : have to wait 0.5ms for an interrupt we loose throughput. Shouldn't you be using filters and such to make this less relevant? A filter runs on the order of 5us after the interrupt on fast machines, and 20us on slower (400MHz) ones. You can feed the pipeline better, and handle higher interrupt rates... Yes, that's one possibility. It looks like there is some timing slightly out of sync. I have an AMD box with the same symptoms. I will try to figure out what is causing it. If you do change to filters then this is much easier with taskqueues as it has a fast variant, otherwise you would need an intermediate step in order to signal the existing usb threading scheme. The taskqueue changeover will be happening soonish anyway. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
TODO
Hi, I have started a page to track USB tasks, please update with any items and feel free to work on any. Any discussion about the items should happen on the usb@ mailing list. http://wiki.freebsd.org/USBTODO cheers, Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2+umass: root mount fails
On Mon, Feb 16, 2009 at 01:53:36PM -0800, Marcel Moolenaar wrote: It appears that the root mount isn't serialized with USB discovery in the same way it was under USB1. It seems that this is not completly resolved with the root mount hold in r188907 as geom may not have tasted the partition tables when vfs_rootmount is woken. USB still needs to finish its bus probe earlier on the boot process. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: ums no longer loads on CURRENT
On Sun, Mar 01, 2009 at 07:20:03PM -0800, Garrett Cooper wrote: On Mar 1, 2009, at 6:36 PM, Sam Leffler wrote: Garrett Cooper wrote: deviceums# Mouse This is why you cannot kldload. Not sure about any functional regression. Sam Yeah, well that message was printed out by another process altogether while loading up the kernel after the ata subsystem was brought up, so something's getting confused and trying to kldload by accident... I was just reproducing the message. I'll provide more data to prove this claim when I can. I have traced this already but not looked into why, the process trying to (re)load ums is moused. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: ums no longer loads on CURRENT
On Sun, Mar 01, 2009 at 07:20:03PM -0800, Garrett Cooper wrote: On Mar 1, 2009, at 6:36 PM, Sam Leffler wrote: Garrett Cooper wrote: deviceums# Mouse This is why you cannot kldload. Not sure about any functional regression. Sam Yeah, well that message was printed out by another process altogether while loading up the kernel after the ata subsystem was brought up, so something's getting confused and trying to kldload by accident... I was just reproducing the message. I'll provide more data to prove this claim when I can. The warning should be gone in r189275 (tested locally). Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Current - USB2 - cups and u[n]lpt devices.
On Sat, Feb 28, 2009 at 11:57:33AM -0600, eculp wrote: Quoting Andrew Thompson thom...@freebsd.org: On Wed, Feb 25, 2009 at 06:10:37AM -0600, eculp wrote: I just rebooted my laptop that I have today's USB2 hopefully with the latest USB compatibility, if I understood the GENERIC kernel correctly. I'm using i386 version, up to date as of this morning. Ports are completely up to date. all etc/dev* stuff is as it was with USB1. From the dmesg I get: +ugen0.2: EPSON at usbus0 +ulpt0: USB2.0 Printer on usbus0 +ulpt0: using bi-directional mode +Symlink: ulpt0 - usb0.2.1.16 +Symlink: unlpt0 - usb0.2.1.17 With localhost:631 I see Unable to open device file /dev/ulpt0: Operation not permitted. Probably because, there ain't none. Is there something else that I need to do that I didn't do before? This isn't critical. I probably print only a few pages a week but I do want it to work when something is critical. Im working on a patch (from Rink) to create proper device nodes, should be ready shortly. I'm just curious. Has this patch been committed yet? Yes, it was yesterday. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB devfs patch
On Fri, Feb 27, 2009 at 08:43:11AM +0100, Hans Petter Selasky wrote:
Hi Andrew,
The patch has been updated thanks to feedback
http://people.freebsd.org/~thompsa/usb-cdevs2.diff
I cannot see that you have looked at the 11 issues I repored on the last
patch. Can you have a look at the following issues again:
Yes I have, 1, 2, 3, 6, 7 8 have all been fixed. For #10 use
http://fxr.watson.org
Andrew
Here is a list of comments and bugs.
The comments follow the diff from top to bottom.
1) There is a redundant setting of is_uref = 1 ?
- ? ? ? if (ploc-is_uref) {
+ ? ? ? if (cpd-is_uref) {
? ? ? ? ? ? ? ? /*
? ? ? ? ? ? ? ? ?* We are about to alter the bus-state. Apply the
? ? ? ? ? ? ? ? ?* required locks.
? ? ? ? ? ? ? ? ?*/
- ? ? ? ? ? ? ? sx_xlock(ploc-udev-default_sx + 1);
+ ? ? ? ? ? ? ? sx_xlock(cpd-udev-default_sx + 1);
? ? ? ? ? ? ? ? mtx_lock(Giant); ? ? ? /* XXX */
+ ? ? ? ? ? ? ? cpd-is_uref = 1;
? ? ? ? }
2) Should gid_t uid_t and mode_t be used?
+ ? ?uint8_t iface_index, uint32_t uid, uint32_t gid, uint16_t mode)
3) This comment should be:
/* Now, create the device itself and an alias */
/* Now, create the device */
Because the alias is not needed - right.
4) Probably you can just remove the src_path stuff:
+ ? ? ? /* XXX no longer needed */
+ ? ? ? strlcpy(ps-src_path, target, sizeof(ps-src_path));
+ ? ? ? ps-src_len = strlen(ps-src_path);
5) There is no reason to use 32-bit int, except for fflags?
uint16_t bus_index;
uint8_t dev_index;
uint8_t iface_index;
uint8_t ep_addr;
#define?EP_NO_ADDR 0xff /* instead of ep_addr = -1 */
?/*
+ * Private per-device information.
+ */
+struct usb2_cdev_privdata {
+ ? ? ? struct usb2_bus ? ? ? ? *bus;
+ ? ? ? struct usb2_device ? ? ?*udev;
+ ? ? ? struct usb2_interface ? *iface;
+ ? ? ? struct usb2_fifo ? ? ? ?*rxfifo;
+ ? ? ? struct usb2_fifo ? ? ? ?*txfifo;
+ ? ? ? int ? ? ? ? ? ? ? ? ? ? bus_index; ? ? ?/* bus index */
+ ? ? ? int ? ? ? ? ? ? ? ? ? ? dev_index; ? ? ?/* device index */
+ ? ? ? int ? ? ? ? ? ? ? ? ? ? iface_index; ? ?/* interface index */
+ ? ? ? int ? ? ? ? ? ? ? ? ? ? ep_addr; ? ? ? ?/* endpoint address */
+ ? ? ? uint8_t ? ? ? ? ? ? ? ? fifo_index; ? ? /* FIFO index */
+ ? ? ? uint8_t ? ? ? ? ? ? ? ? is_read; ? ? ? ?/* location has read access */
+ ? ? ? uint8_t ? ? ? ? ? ? ? ? is_write; ? ? ? /* location has write access
*/
+ ? ? ? uint8_t ? ? ? ? ? ? ? ? is_uref; ? ? ? ?/* USB refcount decr. needed
*/
+ ? ? ? uint8_t ? ? ? ? ? ? ? ? is_usbfs; ? ? ? /* USB-FS is active */
+ ? ? ? int ? ? ? ? ? ? ? ? ? ? fflags;
+};
For usb2_fs_privdata probably you are justified. I would have used
unsigned int for the fields that are unsigned. It has something to do with
range checks in the code not checking for values less than zero. Like:
if (fifo_index max)
ok;
else
failure;
With int's we have to think more:
if (fifo_index = 0 fifo_index max)
ok;
else
failure;
6) Some non-gcc compilers will complain unless you do 0-1 when the
destination variable is unsigned.
- ? ? ? usb2_free_pipe_data(udev, iface_index, 0 - 1);
+ ? ? ? usb2_free_pipe_data(udev, iface_index, -1);
7) Watch out!! Maybe using the word in and out is bad idea. If
this means read and write, then use rd and wr, because in USB
device mode the endpoint direction is exactly the opposide like in USB
host mode:
+ ? ? ? ? ? ? ? /* Fill in the endpoint bitmasks */
+ ? ? ? ? ? ? ? if (ed-bEndpointAddress UE_DIR_IN)
+ ? ? ? ? ? ? ? ? ? ? ? iface-ep_in_mask |=
+ ? ? ? ? ? ? ? ? ? ? ? ? ? 1 UE_GET_ADDR(ed-bEndpointAddress);
+ ? ? ? ? ? ? ? else
+ ? ? ? ? ? ? ? ? ? ? ? iface-ep_out_mask |=
+ ? ? ? ? ? ? ? ? ? ? ? ? ? 1 UE_GET_ADDR(ed-bEndpointAddress);
Use the the following macro for reference when computing if an
endpoint is read or write!
#define USB_GET_DATA_ISREAD(xfer) (((xfer)-flags_int.usb2_mode == \
? ? ? ? USB_MODE_DEVICE) ? ((xfer-endpoint UE_DIR_IN) ? 0 : 1) : \
? ? ? ? ((xfer-endpoint UE_DIR_IN) ? 1 : 0))
Change:
+ ? ? ? uint16_t ep_in_mask; ? ? ? ? ? ?/* bitmask of IN endpoints */
+ ? ? ? uint16_t ep_out_mask; ? ? ? ? ? /* bitmask of OUT endpoints */
Into:
+ ? ? ? uint16_t ep_rx_mask; ? ? ? ? ? ?/* bitmask of RX endpoints */
+ ? ? ? uint16_t ep_tx_mask; ? ? ? ? ? /* bitmask of TX endpoints */
8) The following won't work?? Freeing the cdevs have to be done in multiple
steps. Please keep the semantics of the usb2_fifo_free_wrap function.
When setting the configuration we have a cdev handle on EP0. If that
is closed during set_config we are recursivly killing our own handle!
Therefore there are some extra checks so that at some points we only
free non-EP0 handles, at some point only a specific interface and so
on.
+ ? ? ? usb2_cdev_free(udev);
? ? ? ? usb2_fifo_free_wrap(udev, iface_index, 0);
9) Regarding the device nodes, how about organising into sub-folders?
Before:
+ ? ? ? ? ? ? ? ? ? ? ?
Re: USB devfs patch
On Wed, Feb 25, 2009 at 06:03:30PM -0800, Andrew Thompson wrote: Hi, Below is a patch from Rink Springer to change the new USB stack to use devfs device nodes. I have tested this with a usb mouse and I am hoping people with other devices can test too, in particular scanners (sane app) and lpt ports. The patch has been updated thanks to feedback http://people.freebsd.org/~thompsa/usb-cdevs2.diff It now uses d_open instead of d_fdopen, uses an updated /dev layout, and of course bugfixes. I plan to commit tomorrow. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
USB devfs patch
Hi, Below is a patch from Rink Springer to change the new USB stack to use devfs device nodes. I have tested this with a usb mouse and I am hoping people with other devices can test too, in particular scanners (sane app) and lpt ports. This also removes the custom permissions from usb and usbconfig. http://people.freebsd.org/~thompsa/usb-cdevs.diff cheers, Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
HEADSUP: USB2 now fully default
Hi, As per my previous emails, the USB2 stack has been moved in permanently to sys/dev/usb. The temporary kernel device (and module) naming has been reverted, all the names are back to how they have been in previous releases (usb,ehci,ohci,ums,...). This means that if you are using a custom kernel and were using the USB2 stack via 'usb2_core' and friends then you will need to change these. Please see the GENERIC kernel for a further example. The only casualty is the 'ugen' option, this is now built in by default and no longer a kernel config entry. Please remove this. Also, all usb modules now live under sys/modules/usb. Please report any problems to the mailing list. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: CFR: usb switchover patches
On Mon, Feb 23, 2009 at 06:37:14PM -0500, Joe Marcus Clarke wrote: On Thu, 2009-02-19 at 19:37 -0800, Andrew Thompson wrote: Hi, I have put together a proposed set of changes for moving USB2 to its permanent location. The layout has some differences to how it is right now so I am looking for feedback. The changeover requires that the old usb stack be available until 8.0 is branched and moves it from sys/dev/usb to sys/legacy/dev/usb. The reason for this location is to reduce the changes in #includes (using -I compiler hacks). The patch doesnt show userland changes required for usbdevs and friends but they will be done. Some ports will break. Any that exist solely for the old usb stack can be marked broken (like udesc_dump). I dont know that the fallout will be like for the others, maybe portmgr would be interested in doing a build test. The change roughly goes svn move sys/dev/usb - sys/legacy/dev/usb svn move sys/dev/usb2 - sys/dev/usb (with fixups, see below) The headers for usb are no longer installed. This rebreaks hal as I attempt to build both backends. Can you make sure the old usb headers are also installed (/usr/include/dev/legacy/usb)? Without this, I will have to redo the hal build code. I was hoping I wouldnt have to do this as it breaks kdump since they both define the same typedefs. kdump builds its tables from trolling /usr/include. I will have a look at this. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: CFR: usb switchover patches
On Thu, Feb 19, 2009 at 07:37:40PM -0800, Andrew Thompson wrote: Hi, I have put together a proposed set of changes for moving USB2 to its permanent location. The layout has some differences to how it is right now so I am looking for feedback. The changeover requires that the old usb stack be available until 8.0 is branched and moves it from sys/dev/usb to sys/legacy/dev/usb. The reason for this location is to reduce the changes in #includes (using -I compiler hacks). The patch doesnt show userland changes required for usbdevs and friends but they will be done. Some ports will break. Any that exist solely for the old usb stack can be marked broken (like udesc_dump). I dont know that the fallout will be like for the others, maybe portmgr would be interested in doing a build test. The change roughly goes svn move sys/dev/usb - sys/legacy/dev/usb svn move sys/dev/usb2 - sys/dev/usb (with fixups, see below) I plan to do this tomorrow. The commit can not be done in one since it involves svn moves to/from the same location but it should only take a few mins. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2+umass: root mount fails
snip Whatever the solution may be (root_mount_hold/root_mount_rel, sync/async explore, ...), I will commit the patch from http://wiki.freebsd.org/USB for the moment so people can still boot. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2+umass: root mount fails
On Sat, Feb 21, 2009 at 04:08:39PM -0800, Andrew Thompson wrote: snip Whatever the solution may be (root_mount_hold/root_mount_rel, sync/async explore, ...), I will commit the patch from http://wiki.freebsd.org/USB for the moment so people can still boot. Scratch that, I used root_mount_hold (r188907). This is by no means final but just pushed through to help people boot since the stack is now default. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: CFR: usb switchover patches
On Thu, Feb 19, 2009 at 07:37:40PM -0800, Andrew Thompson wrote: Hi, I have put together a proposed set of changes for moving USB2 to its permanent location. The layout has some differences to how it is right now so I am looking for feedback. I should have said the attached patch was to illustrate the changes and I didnt expect anyone to test a build with them. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
CFR: usb switchover patches
Hi, I have put together a proposed set of changes for moving USB2 to its permanent location. The layout has some differences to how it is right now so I am looking for feedback. The changeover requires that the old usb stack be available until 8.0 is branched and moves it from sys/dev/usb to sys/legacy/dev/usb. The reason for this location is to reduce the changes in #includes (using -I compiler hacks). The patch doesnt show userland changes required for usbdevs and friends but they will be done. Some ports will break. Any that exist solely for the old usb stack can be marked broken (like udesc_dump). I dont know that the fallout will be like for the others, maybe portmgr would be interested in doing a build test. The change roughly goes svn move sys/dev/usb - sys/legacy/dev/usb svn move sys/dev/usb2 - sys/dev/usb (with fixups, see below) The patch for the build system can be viewed here, http://people.freebsd.org/~thompsa/usb_layout/usb_xover.diff Now the changes... For starters the '2' will be removed from the filenames but furthermore I want to flatten dev/usb2/core and dev/usb2/include into just dev/usb, keeping the peripheral drivers in their subdirs. Its hard to show with a diff so simply browse the layout here, http://people.freebsd.org/~thompsa/usb_layout/dev/ Please send any minor/nitpick changes to me privately, keeping any list replies to the overall changes. regards, Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: CFR: usb switchover patches
On Thu, Feb 19, 2009 at 10:46:21PM -0500, Joe Marcus Clarke wrote: Andrew Thompson wrote: Hi, I have put together a proposed set of changes for moving USB2 to its permanent location. The layout has some differences to how it is right now so I am looking for feedback. What about libusb20? Will this name change, or is this the final name (same question for the libusb20 functions)? I need to know for hal. Thanks. As far as I know libusb20 will not change at all. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2+umass: root mount fails
On Tue, Feb 17, 2009 at 08:54:24AM -0700, M. Warner Losh wrote: In message: 200902170856.11631.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Tuesday 17 February 2009, Marcel Moolenaar wrote: : But it looks like the old usb code didn't call it either... I think : old code enumerated right away during boot, while the new code defers : the enumeration until events can be processed... : : Yes, you're right. USB1 used the following: : : SYSINIT(usb_cold_explore, SI_SUB_CONFIGURE, SI_ORDER_MIDDLE, : usb_cold_explore, NULL); : : SI_SUB_CONFIGURE didn't complete before all USB busses : were enumerated. : : I would really prefer that first time USB enumeration is not synchronous. This : has to do with startup timing. It simply wastes a lot of time to wait for all : the busses to be probed in serial. Sure it works nice with a USB keyboard and : a USB mouse, but when you have a couple of USB HUBs and +8 devices connected, : it simply speeds up the boot time so that you reach the root prompt by the : time you would else have done the mount root mfs. : : If the mountroot code cannot find the disk, it should sleep and loop. I think this is a weak argument. I'm strongly in favor of the usb1 behavior here. I think its slightly more complex that adding a cold explore task. Most of the USB2 periperhel drivers defer a portion of their attach to a thread task, a change which needs to be reverted first. As others have said both the probe and attach must be synchronous. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2 apcupsd
On Mon, Feb 16, 2009 at 11:30:18AM +0100, Hans Petter Selasky wrote: On Monday 16 February 2009, Noriyoshi Kawano wrote: -LIBUSB_ETIMEDOUT The following patch to libusb20 should resolve your problem: http://perforce.freebsd.org/chv.cgi?CH=157783 And now in HEAD as at r188678. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB support in NDIS -- IFF_NEEDSGIANT?
On Mon, Feb 16, 2009 at 11:33:18AM +, Robert Watson wrote: Dear all: As you know, I've been gradually working to eliminate all non-MPSAFE network device driver infrastructure for 8.0, having removed non-MPSAFE network protocol infrastructure in 7.0. In reviewing remaining drivers using IFF_NEEDSGIANT, I spotted this in the NDIS code: 718 if_initname(ifp, device_get_name(dev), device_get_unit(dev)); 719 ifp-if_mtu = ETHERMTU; 720 ifp-if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; 721 if (sc-ndis_iftype == PNPBus) 722 ifp-if_flags |= IFF_NEEDSGIANT; 723 ifp-if_ioctl = ndis_ioctl; 724 ifp-if_start = ndis_start; 725 ifp-if_init = ndis_init; Having taken a glance, it looks like this was added specifically to support USB devices attached via NDIS. With the new USB code, are NDIS drivers still supported? And in the new world order, is this IFF_NEEDSGIANT still required? Can I simply remove it once the old USB code is on the way out the door? I had promised Weongyo that I would convert ndis to USB2 but have been a bit busy. Anyone else welcome to pick this up in the mean time. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: HEADSUP: USB2 now default in GENERIC kernels
On Sun, Feb 15, 2009 at 02:34:28PM -0800, Andrew Thompson wrote: Hi, The GENERIC kernels for all architectures now default to the new USB2 stack. No kernel config options or code have been removed so if a problem arises please report it and optionally revert to the old USB stack. IMPORTANT NOTES: 1. If you are loading USB kernel modules then ensure that these are also changed over, eg uftdi.ko - usb2_serial_ftdi.ko. You can not load oldUSB modules with the GENERIC kernels. 2. If you have a custom kernel that includes GENERIC as a base, you need to ensure that any additional usb devices that you specify are changed over. 3. The USB2 kernel options and module names are _temporary_. The next stage is to move the USB2 code into its permanent location in the source tree and at that point will take over the well established naming. (ie, usb, ehci, ohci, uftdi). There will be no changes going from FreeBSD 7.x - 8.0 4. Once (3) is complete the oldUSB code will still be usable until much closer to the 8.0 branch. 5. Some people have noted that the latest xorg 7.4 requires the hal daemon to enumerate the input devices. hal does not (yet) work with USB2 so if you find that the keyboard/mouse are not working in X then try adding the following line to the ServerLayout section in xorg.conf Option AllowEmptyInput off regards, Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: HEADSUP: USB2 now default in GENERIC kernels
On Tue, Feb 17, 2009 at 03:05:01AM +0900, Munehiro Matsuda wrote: ::5. Some people have noted that the latest xorg 7.4 requires the hal ::daemon to enumerate the input devices. hal does not (yet) work with USB2 ::so if you find that the keyboard/mouse are not working in X then try ::adding the following line to the ServerLayout section in xorg.conf :: :: Option AllowEmptyInput off Hi Andrew, As I wrote in other thread, the description in /usr/ports/UPDATING is wrong. It's not ServerLayout section, but shuold be ServerFlags section as follows: Section ServerFlags Option AllowEmptyInput off EndSection Actually if you look at xorg.conf(5) it can be either. I'll keep the same as the ports UPDATING file for consistency. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
HEADSUP: USB2 now default in GENERIC kernels
Hi, The GENERIC kernels for all architectures now default to the new USB2 stack. No kernel config options or code have been removed so if a problem arises please report it and optionally revert to the old USB stack. IMPORTANT NOTES: 1. If you are loading USB kernel modules then ensure that these are also changed over, eg uftdi.ko - usb2_serial_ftdi.ko. You can not load oldUSB modules with the GENERIC kernels. 2. If you have a custom kernel that includes GENERIC as a base, you need to ensure that any additional usb devices that you specify are changed over. 3. The USB2 kernel options and module names are _temporary_. The next stage is to move the USB2 code into its permanent location in the source tree and at that point will take over the well established naming. (ie, usb, ehci, ohci, uftdi). There will be no changes going from FreeBSD 7.x - 8.0 4. Once (3) is complete the oldUSB code will still be usable until much closer to the 8.0 branch. Please report any issues to the mailing lists. regards, Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2: [was: umass not detected correctly, axe not transmitting] AXE problems
On Thu, Feb 12, 2009 at 12:42:51PM +0900, Pyun YongHyeon wrote: I have the same USB controller and latest CURRENT works. axe0: ASIX Electronics AX88178, rev 2.00/0.01, addr 4 on usbus1 axe0: PHYADDR 0xe0:0x18 miibus2: MII bus on axe0 ciphy0: Cicada VSC8211 10/100/1000TX PHY PHY 24 on miibus2 ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ue0: USB Ethernet on axe0 ue0: Ethernet address: 00:90:cc:ef:b9:f6 ue0: link state changed to DOWN I manually loaded necessary kernel modules as my kernel does not have any USB device entries. The only regression since I tried USB2 axe(4) was failure of symbol resolving of link_elf in usb2_ethernet.ko module. Attached simple patch seems to fix that. To Hans, I think MODULE_DEPEND should come first before any reference to the module in usb2_ethernet.c. Since mii_phy_probe live in miibus(4) I added it too. Hans, I managed to track down Hiroharu's issue in axe(4). It seems Andrew removed link handling code that ensures correct state of established link in r188412. I believe we have to revert changes made in axe_cfg_mii_statchg() and axe_tick(). I have no idea what was happend in P4, you checked in the link handling code I submitted. Thanks for finding this Pyun, an unintentional breakage due to the code reshuffle. Have you committed the fix, I dont see it? Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Recent Changes to Rum driver - seems to have..
On Wed, Feb 11, 2009 at 10:00:45AM +0100, Hans Petter Selasky wrote: On Tuesday 10 February 2009, Thomas Sparrevohn wrote: Reintroduced panics when the device is used heavily - it also reports the needs callback in dmesg - Unless this is known I can post a dmesg Hi Thomas, Andrew Thompson decided to re-port the driver from USB1. I've tried to fix most of the bugs now. If the fixes are not in -current yet you can fetch if_rum*[ch] from: svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/i4b/src/sys/dev/usb2 Do you have a backtrace of the panics ? Sorry about the inconvenience. Please watch the mud slinging, there were very good reasons for changing the wlan code back to the USB1 state (bugs and all). Each regression will be investigated and fixed. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Future of udbp in USB2?
On Mon, Feb 09, 2009 at 11:20:42AM -0800, Garrett Cooper wrote: On Mon, Feb 9, 2009 at 12:16 AM, Hans Petter Selasky hsela...@c2i.net wrote: On Monday 09 February 2009, Garrett Cooper wrote: Hi Hans, I was just preparing to test out the usb2 changes and I noted that one option in my old kernel configfile didn't have an analog in the USB2 config file: udbp. I don't use the option, but I was just checking to see whether or not an analog does exist, or the support will be completely phased out when USB2 becomes the default for FreeBSD. Thanks, -Garrett Hi, The udbp module is now called misc_dbp and it still connects via netgraph. Other similar devices just emulate USB ethernet devices. --HPS Ok... is that going to be documented in the release notes for the new functionality? All the modules should go back to their original names as part of the removal/replacement process of oldusb-newusb. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Future of udbp in USB2?
On Mon, Feb 09, 2009 at 11:58:28AM -0800, Andrew Thompson wrote: On Mon, Feb 09, 2009 at 11:20:42AM -0800, Garrett Cooper wrote: On Mon, Feb 9, 2009 at 12:16 AM, Hans Petter Selasky hsela...@c2i.net wrote: On Monday 09 February 2009, Garrett Cooper wrote: Hi Hans, I was just preparing to test out the usb2 changes and I noted that one option in my old kernel configfile didn't have an analog in the USB2 config file: udbp. I don't use the option, but I was just checking to see whether or not an analog does exist, or the support will be completely phased out when USB2 becomes the default for FreeBSD. Thanks, -Garrett Hi, The udbp module is now called misc_dbp and it still connects via netgraph. Other similar devices just emulate USB ethernet devices. --HPS Ok... is that going to be documented in the release notes for the new functionality? All the modules should go back to their original names as part of the removal/replacement process of oldusb-newusb. I meant to say /will/. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: HEADSUP usb2/usb4bsd to become default in GENERIC
On Sun, Feb 08, 2009 at 06:48:39PM +0100, Remko Lodder wrote: On Sun, February 8, 2009 6:21 am, Alfred Perlstein wrote: * Maxim Sobolev sobo...@freebsd.org [090206 01:50] wrote: Alfred Perlstein wrote: - Update GENERIC to use usb2 device names. Wasn't there a plan to rename usb2 devices to match oldusb names (where applicable) once oldusb had been killed? I don't see it in the list. [snip] If a lot of people poke me about renaming it, we'll get it done, but I don't really believe in it. I would like to enfavor that it is being named usb at some point. We do not want to keep names like rcNG while at some point it's the defacto standard right? Also names like USB2 tell people that there might be a USB1 as well, which we no longer ship at some point. Please name it usb_*. In addition; there is a request from Warner (if I remember correctly); which I do share; there is a manual regeneration needed if you add something to usbdevs, please make sure that that goes automatically like usb1 does at the moment. I take it the stage (1) is to switch over GENERIC to the new usb2 code and will not involve renaming the config items. stage (2) moves the usb code around in svn and all USB2 kernel config items will assume their original names, ie. usb2_controller_echi - ehci. I think this is what Alfred was getting about with only changing it once. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [was: USB2 - umass problem] U3G modem unit number changes
On Wed, Feb 04, 2009 at 05:33:22PM +0100, Hans Petter Selasky wrote: Hi, On Wednesday 04 February 2009, M. Warner Losh wrote: Why the change? Because u3g2.c is attaching to an USB interface and not the whole USB device. This is to allow other drivers to hook on the other interfaces. u3g2 should claim the other interfaces in the one attachment and use the same tty semantics as oldusb u3g. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2 patches
On Sun, Feb 01, 2009 at 12:20:17PM +0100, Hans Petter Selasky wrote:
Hi Andrew,
We need to go through your patches together, to work out some issues.
1) A nit.
- if (usb2_proc_setup(ssc-sc_config_td, p_mtx, USB_PRI_MED)) {
- usb2_com_units_free(root_unit, sub_units);
- return (ENOMEM);
- }
+
+ error = usb2_proc_create(ssc-sc_tq, USB_PRI_MED, ucom);
+ if (error)
missing usb2_com_units_free()
thanks.
+ return (error);
+
2) Please explain why you think that usb2_proc_is_gone() can be removed.
- if (usb2_proc_is_gone(ssc-sc_config_td)) {
- DPRINTF(proc is gone\n);
- return; /* nothing to do */
- }
If the taskqueue system does not provide a teardown mechanism so that we
inside the callback can know if the taskqueue is being drained, then the
taskqueue cannot replace the original usb2_proc_xxx() ! Maybe this means we
need to extend the taskqueue system?
Possibly. Taskqueues will always complete the function callbacks before
freeing so you dont need to worry about resources disappearing under you.
The one reason would be to bail out of a long running task but,
- Are there any tasks that actually run a long time?
- If not, its easier just to wait on the drain
3)
In general avoid more than a few synchronous USB transfer inside
attach/detach. Always defer! Else there are corner cases where the device can
hang waiting for the transfer timeout 1-5 seconds for every USB transfer, and
that is unacceptable.
I disagree. It hugely simplifies drivers to know all the resources are
allocated after attach, you dont need to check for null pointers
throughout the code. If programming commands fail/timeout in the attach routine
then the driver needs to check this and abort the attach. You will wait
one or two timeouts max.
4)
int onoff = USB_TASK_ARG(task);
This won't work! You need to be able to handle N-phase here, where N goes to
+infinity! If the DTR pin was toggled we should also see a toggle in the
programming of the DTR pin, not just re-program the last state! If there is a
USB_TASK_ARG() it must be constant and that is where I start seeing problems,
or features missing in the taskqueue system.
It is also very important that you somehow freeze the configuration at the
moment a command is issued. For example in the WLAN drivers. If the command
is queued when the channel is 5 then we should program channel 5 and not
fetch the latest channel value from the softc! IMPORTANT!
This isnt correct. Take your example of WLAN drivers, the net80211 layer
will use ic_curchan for its logic so the driver needs to program the
chip to this value at all times. You can _not_ queue channel changes as
these will be out of sync. Tasks are very short lived and program the
chipset to the current state where it otherwise could not have been done
due to thread sleeping.
Also, net80211 will soon have its own thread so you can do things like
state/channel changes directly but in a sleepable context.
5) Many of your other changes are good!
Thanks!
Andrew
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2 patches
On Sun, Feb 01, 2009 at 07:22:15PM +0100, Hans Petter Selasky wrote:
Hi Andrew,
3)
In general avoid more than a few synchronous USB transfer inside
attach/detach. Always defer! Else there are corner cases where the device
can hang waiting for the transfer timeout 1-5 seconds for every USB
transfer, and that is unacceptable.
I disagree. It hugely simplifies drivers to know all the resources are
allocated after attach, you dont need to check for null pointers
throughout the code.
I think you misunderstand. The attach code that loads firmware, reads eeprom
and performs other configuration must be handed off to another thread, or in
your case a taskqueue, so that the USB attach thread can go on and do other
things.
The attach routine allocates resources and attaches the hardware. Things
like loading firmware and other configuration are done in the ifnet init
routine.
It is also very important that you somehow freeze the configuration at
the moment a command is issued. For example in the WLAN drivers. If the
command is queued when the channel is 5 then we should program channel 5
and not fetch the latest channel value from the softc! IMPORTANT!
This isnt correct. Take your example of WLAN drivers, the net80211 layer
will use ic_curchan for its logic so the driver needs to program the
chip to this value at all times. You can _not_ queue channel changes as
these will be out of sync.
Being a little off-sync is not the big problem. The big problem is if the
channel value is changing during execution of the code. For example, in the
beginning of the code the channel value is 5, then suddenly it becomes 6, and
the programming just ends up crazy!
xxx_set_channel()
{
hw_reg = array1[wlan-curchan];
write USB register;
hw_reg = array2[wlan-curchan];
write USB register;
}
The code should be,
xxx_set_channel()
{
ieee80211_channel c = wlan-curchan;
hw_reg = array1[c];
write USB register;
hw_reg = array2[c];
write USB register;
}
cheers,
Andrew
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2 patches
On Sun, Feb 01, 2009 at 08:01:05PM +0100, Hans Petter Selasky wrote:
Hi Andrew,
Regarding using taskqueues.
Yes - USB2 can use taskqueues, but I would very much like to have the
original
queueing mechanism intact.
Can you explain this further? What is t0 vs t1?
A taskqueue will execute tasks sequentially, why do you need to pass two
tasks in at a time?
How about:
struct task *
tasqueue_enqueue_pair(struct taskqueue *queue, struct task *t0, struct task
*t1);
Which does something similar to this:
void *
usb2_proc_msignal(struct usb2_process *up, void *_pm0, void *_pm1)
{
struct usb2_proc_msg *pm0 = _pm0;
struct usb2_proc_msg *pm1 = _pm1;
struct usb2_proc_msg *pm2;
uint32_t d;
uint8_t t;
mtx_assert(up-up_mtx, MA_OWNED);
t = 0;
if (pm0-pm_qentry.tqe_prev) {
t |= 1;
}
if (pm1-pm_qentry.tqe_prev) {
t |= 2;
}
if (t == 0) {
/*
* No entries are queued. Queue pm0 and use the existing
* message number.
*/
pm2 = pm0;
} else if (t == 1) {
/* Check if we need to increment the message number. */
if (pm0-pm_num == up-up_msg_num) {
up-up_msg_num++;
}
pm2 = pm1;
} else if (t == 2) {
/* Check if we need to increment the message number. */
if (pm1-pm_num == up-up_msg_num) {
up-up_msg_num++;
}
pm2 = pm0;
} else if (t == 3) {
/*
* Both entries are queued. Re-queue the entry closest to
* the end.
*/
d = (pm1-pm_num - pm0-pm_num);
/* Check sign after subtraction */
if (d 0x8000) {
pm2 = pm0;
} else {
pm2 = pm1;
}
TAILQ_REMOVE(up-up_qhead, pm2, pm_qentry);
} else {
pm2 = NULL; /* panic - should not happen */
}
DPRINTF( t=%u, num=%u\n, t, up-up_msg_num);
/* Put message last on queue */
pm2-pm_num = up-up_msg_num;
TAILQ_INSERT_TAIL(up-up_qhead, pm2, pm_qentry);
/* Check if we need to wakeup the USB process. */
if (up-up_msleep) {
up-up_msleep = 0; /* save cv_signal() calls */
usb2_cv_signal(up-up_cv);
}
return (pm2);
}
--HPS
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2 patches
On Sun, Feb 01, 2009 at 07:22:15PM +0100, Hans Petter Selasky wrote:
If you compare the old USB code with the new USB code for if_zyd for example
you see that there are dozens of error checks everywhere:
if (error != 0)
goto fail;
In the new USB code I've factored out all those checks into 3 lines of code
in
every driver:
if (usb2_config_td_is_gone(sc-sc_config_td)) {
goto error;
}
In your patch you remove all error checking! If the taskqueue system does not
have an API function that can tell if the taskqueue is being drained from
inside the taskqueue callback, the taskqueue system has to be modified! It
cannot replace the existing system like it is now!
Things are still a work in progress, if I have missed some error
checking then it can be fixed up.
Andrew
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2 patches
On Sun, Feb 01, 2009 at 08:31:55PM +0100, Hans Petter Selasky wrote:
On Sunday 01 February 2009, Andrew Thompson wrote:
On Sun, Feb 01, 2009 at 08:01:05PM +0100, Hans Petter Selasky wrote:
Hi Andrew,
Regarding using taskqueues.
Yes - USB2 can use taskqueues, but I would very much like to have the
original queueing mechanism intact.
Can you explain this further? What is t0 vs t1?
A taskqueue will execute tasks sequentially,
Hi Andrew,
I've looked in the taskqueue code:
if (task-ta_pending) {
task-ta_pending++;
TQ_UNLOCK(queue);
return 0;
}
Take the following for example. Now you changed it a little bit, but I see
similar issues where other commands are involved:
1) queue DTR on cmd
2) queue DTR off cmd
3) queue DTR on cmd
Using the taskqueue there is no guarantee that the last command queued is the
last command executed! That is dangerous! Because the existing taskqueue
enqueue will only increment the pending count and return, if the command/task
is already queued.
In the example above you can end up like this:
DTR on (pending = 2)
DTR off (pending = 1)
This is not correct. The queuing mechanism in USB2 guarantees that the last
queued command is last executed:
There are a few options,
- coalesce on a single task (on,off,on = on), the off never happened.
- drain the task first then resubmit
Those cover both scenarios, (1) you dont care about previous state or
(2) you do care so ensure the previous state has executed.
If for some reason those are not sufficient then the driver is free to
implement its own queue. The current implementation in usb is quite
clever but its important not to complicate the internals for situations
that dont happen in real life.
Andrew
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2 patches
On Sun, Feb 01, 2009 at 07:38:47PM +0100, Hans Petter Selasky wrote: On Sunday 01 February 2009, M. Warner Losh wrote: In message: 200902011922.16810.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : In your patch you remove all error checking! If the taskqueue system does : not have an API function that can tell if the taskqueue is being drained : from inside the taskqueue callback, the taskqueue system has to be : modified! It cannot replace the existing system like it is now! Why does the taskqueue system need to provide that? Why can't the driver set a dying flag in the softc to communicate this fact to the taskqueue tasks? That's also possible. Thomas already made a struct usb2_task I think, where this flag could be added. I have been thinking about this more. The main issue is usb requests timing out when the device is yanked, the udev structure should keep state on this and set it as detached before calling the device detach routine. This will allow usb requests that may be running in the taskqueue to abort gracefully and taskqueue should drain quite easily. If the device hasnt been yanked then it will have no issues draining as the queued tasks will happily run to completion. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
USB2 patches
Hi, I have several patches in my svn user branch that I would like to see committed to HEAD. Some of these change the usb2 core code so I am interested in feedback or shootdowns. I am right behind the change to USB2 and this is an effort to help. The patch can be found here, http://people.freebsd.org/~thompsa/usb_head1.diff 73 files changed, 9229 insertions(+), 13261 deletions(-) but its rather large so it may be easier to look at the various changes via the svn web interface. http://svn.freebsd.org/viewvc/base/user/thompsa/usb/ r187750 http://svn.freebsd.org/viewvc/base?view=revisionrevision=187750 Change over to using taskqueue(9) instead of hand rolled threads and the config_td system. This removes the config_td code and makes the API much simpler to use. r187751, r187752, r187753, r187754, r187755, r187756 http://svn.freebsd.org/viewvc/base?view=revisionrevision=187751 Change over to usb2_proc w/ taskqueues for the usb2/ethernet, usb2/serial and usb2/wlan code. r187965 http://svn.freebsd.org/viewvc/base?view=revisionrevision=187965 Move most of the ifnet logic into the usb2_ethernet module, this includes, - make all usb ethernet interfaces named ue%d - handle all threading in usb2_ethernet - provide default ioctl handler - handle mbuf rx - provide locked callbacks for init,start,stop,etc The drivers are not much more than data pushers now. regards, Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Giant on serial devices in USB2?
On Tue, Dec 23, 2008 at 07:56:21PM +0100, Hans Petter Selasky wrote: On Tuesday 23 December 2008, Ed Schouten wrote: Hello HPS, others, I was just running a grep on the USB2 code and saw the following: $ grep -r Giant sys/dev/usb2/serial | wc -l 70 WHat's the exact reason USB2 still uses Giant on TTY related drivers? Couldn't it just use the per-TTY mutex? If not, maybe it should create a custom system-wide mutex, instead of using Giant? Yours, Hi, I don't have all those USB devices at hand, so I simply cannot test if the driver still works without Giant. BTW: It should be trivial to remove Giant from the drivers. I think Andrew Thompson has already done some drivers Giant-free. Its just a mechanical change, it works fine for the couple of driver I have converted. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB4BSD release candidate number 3 - request for review
On Wed, Nov 05, 2008 at 12:05:47AM +0100, Lars Engels wrote: On Wed, Nov 05, 2008 at 12:04:02AM +0100, Lars Engels wrote: Now I just removed everything but usb2_core from the kernel config and load the modules manually. So far it runs pretty good. Mounting a umass device, removing it and doing an 'ls' on the mountpoint freezes the system, I thought this should not happen with the new stack? sysctl hw.usb2.uscanner.uscanner: 0 Could it be that this should be debug? And one last thing: # usbdevs -v usbdevs: no USB controllers found usbdevs does not work with it, there is a new usbconfig util that should do what you want. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
