Skip site navigation (1)Skip section navigation (2)
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>