From owner-freebsd-arch@FreeBSD.ORG Tue Jan 6 06:21:47 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E061C1E; Tue, 6 Jan 2015 06:21:47 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 27F4F293C; Tue, 6 Jan 2015 06:21:46 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-233-252.lns20.per1.internode.on.net [121.45.233.252]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t066Lfai003080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 5 Jan 2015 22:21:44 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54AB7EEF.9030505@freebsd.org> Date: Tue, 06 Jan 2015 14:21:35 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Hans Petter Selasky , John Baldwin , arch@freebsd.org Subject: Re: devctl(8): A device control utility References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54AAF07B.7030601@selasky.org> <54AAF60A.9070609@FreeBSD.org> <54AAFAEB.2090505@selasky.org> In-Reply-To: <54AAFAEB.2090505@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 06:21:47 -0000 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" > >