Date: Tue, 06 Jan 2015 14:21:35 +0800 From: Julian Elischer <julian@freebsd.org> To: Hans Petter Selasky <hps@selasky.org>, John Baldwin <jhb@FreeBSD.org>, arch@freebsd.org Subject: Re: devctl(8): A device control utility Message-ID: <54AB7EEF.9030505@freebsd.org> In-Reply-To: <54AAFAEB.2090505@selasky.org> References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54AAF07B.7030601@selasky.org> <54AAF60A.9070609@FreeBSD.org> <54AAFAEB.2090505@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/6/15 4:58 AM, Hans Petter Selasky wrote: > On 01/05/15 21:37, John Baldwin wrote: >> On 1/5/15 3:13 PM, Hans Petter Selasky wrote: >>> On 01/05/15 21:01, John Baldwin wrote: >>>> The devctl(8) utility is then a thin wrapper around libdevctl (and >>>> does not >>>> yet have a manpage). >>>> >>>> Do folks have any feedback? >>> >>> Hi, >>> >>> In the USB area attach and detach must be synchronized to the USB >>> stack >>> and "usbconfig -d X.Y set_config Z" or "usbconfig -d X.Y reset" >>> should >>> be used to avoid races attaching and detaching drivers! >> >> I think this points to one or more missing bus methods so that the bus >> can hook into device_probe_and_attach() to reset a device as needed. >> (e.g. if you had bus_probe_started / bus_probe_finished and possibly >> similar methods for attach. PCI could use a bus_attach_finished() >> callback so that it could clean up any dangling resources and possibly >> power down on a failed attach the way it does in bus_child_detached as >> well). > > Hi, > > USB has its own threads to allocate/free devices. Another problem is > how to atomically get a reference count across multiple layers like > PCI and USB. It doesn't allow probe/attach when called from outside > these threads. > > What happens if one instance of "devctl detach" detaches the USB PCI > controller and another detaches a USB device, child of the USB PCI > controller? > >> >> Also, 'devctl detach' is a bit racy anyway as a subsequent kldload of >> any driver on the bus will rescan the bus and try to attach any >> unattached device. 'devctl disable' does not have this race, but it >> currently matches 'hint.foo.0.disabled' and doesn't let you try an >> alternate driver. I consider attach/detach a bit more low-level while >> enable/disable are probably more end-user friendly. For the case of >> letting a device rebid after loading a new driver, a new 'reprobe' >> ioctl/command might be best rather than requiring an explicit >> 'detach/attach'. > > Is it a problem if devctl access is protected by a single SX lock > and only can access PCI devices? I already use pciconf to twiddle registers etc for PCI devices. (well, I did at a previous employer).. are we duplicating any functionality here? > > --HPS > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54AB7EEF.9030505>