On Thursday 08 January 2004 07:01, Bernd wrote:
Im mostly worried about having more than a single device with address 0.
You can't do this as long as another device gets initialized.
Therefor I thought disabling/enabling the port would be better, but I'm
wrong as the result is be the same.
On Wednesday 07 January 2004 17:08, Bernd Walter wrote:
I don't think it IS a dumb device, there is a USB spec called DFU which
covers it and the hosts job is to do the reenumeration.
Sparing a transistor to offload the work to the host were its also
way more complex to do is dump.
If this
On Wed, Jan 07, 2004 at 05:34:05PM +1030, Daniel O'Connor wrote:
On Wednesday 07 January 2004 17:08, Bernd Walter wrote:
I don't think it IS a dumb device, there is a USB spec called DFU which
covers it and the hosts job is to do the reenumeration.
Sparing a transistor to offload the
On Wednesday 07 January 2004 09:07, Bernd Walter wrote:
On Wed, Jan 07, 2004 at 05:34:05PM +1030, Daniel O'Connor wrote:
On Wednesday 07 January 2004 17:08, Bernd Walter wrote:
I don't think it IS a dumb device, there is a USB spec called DFU
which covers it and the hosts job is to do
On Wednesday 07 January 2004 18:37, Bernd Walter wrote:
If this is part of the Spec, then the spec is dump too.
Err yes, this IS USB we're talking about here :)
Reead your spec - it's not part of USB itself.
umass, ulpt, etc are extensions.
It is even that a mass storage device doesn't
On Wednesday 07 January 2004 20:34, Daan Vreeken [PA4DAN] wrote:
Reead your spec - it's not part of USB itself.
As long as there are a lot of usefull devices that use the DFU spec, to me
it seems no more than logicle to implement it in FreeBSD, no matter how
dumb the system may sound :)
On Wed, Jan 07, 2004 at 11:04:37AM +0100, Daan Vreeken [PA4DAN] wrote:
For the device this means having to switch the ROM image with the RAM image
which is impossible while running in the specific processor. Thus the
processor tells it's core to map RAM into code-space and resets itself.
On Tuesday 06 January 2004 18:47, Bernd Walter wrote:
When setting a USB device to configuration number USB_UNCONFIG_NO (i.e.
0), the device goes into an unconfigured state with an invalid
dev-cdesc. How does one then leave this unconfigured state and
reconfigure the device to accept
On Wed, Jan 07, 2004 at 04:05:15PM +1030, Daniel O'Connor wrote:
On Tuesday 06 January 2004 18:47, Bernd Walter wrote:
When setting a USB device to configuration number USB_UNCONFIG_NO (i.e.
0), the device goes into an unconfigured state with an invalid
dev-cdesc. How does one then leave
On Wednesday 07 January 2004 16:35, Bernd Walter wrote:
There are certainly situations where you want to reenumerate the USB
devices, for example there are a number of devices which have no real
firmware - they expect to be programmed by the PC then reset and
reenumerated after being
On Wed, Jan 07, 2004 at 04:44:46PM +1030, Daniel O'Connor wrote:
On Wednesday 07 January 2004 16:35, Bernd Walter wrote:
Bad device - it would have been so easy add an single transitor to do
this automaticaly.
Nevertheless USB_UNCONFIG_NO can't help you here.
What you need to do is
Hi
I've just finished a patch to alleviate several panics in the ugen driver
(related to devfs issues and setting a USB device's configuration to
USB_UNCONFIG_NO). I'm about to submit to freebsd-current@, but I need to
clarify something first.
When setting a USB device to configuration number
12 matches
Mail list logo
