On Tue, Jul 02, 2002 at 12:14:27AM -0700, David Brownell wrote:
> >And hopefully most of these hotplug calls will get merged together into
> >the driverfs core soon, and we remember to pay attention to the return
> >value there :)
>
> How would driverfs do that -- a new bus level callback to
> fi
==
±z¦³¿ì¤½«Ç§Y±NªÅ¥X¶Ü¡H
==
§Ú̱Mªù´£¨Ñ°Ó¥Î¿ì¤½«Ç¤§¯²¸îªA°È¡I
§ÚÌ«D±`Ä@·N¬°±z§ä¨ì·sªº©Ð«È¡A±z¤£·|¬°¤F©Ð«È·hÂ÷«á¦³¼Æ¤ë
ªºªÅ«Î´Á¡A¦Ó·l¥¢¤F±z¤£¤Öªº¯²ª÷¦¬¤J¡A½Ð±z´£¦§
>>Talk about really badly named flags ... that's
>>"DISABLE SHORT PACKET DISABLE" (SPD is a UHCI flag),
>>a double negative: short packets are enabled.
>
>
> SPD = Short Packet Detect. Take a look at section 3.2.2 in the UHCI
> specs.
>
> So it would be "Disable Short Packet Detect".
>
> How
On Tue, Jul 02, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> Duncan Sands wrote:
> > On my windows box a certain URB is sent down with
> > transfer flags = 3 = 2 + 1. The 1 means
> > USBD_SHORT_TRANSFER_OK. In the linux usb.h
> > I see that 1 means USB_DISABLE_SPD which sounds
> > like sett
On Tue, Jul 02, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > While I agree some of the locking can be made simpler, it can't be
> > reduced to 1 lock.
>
> Could you elaborate? It works for OHCI and EHCI, so on
> first principles, the same should be true for UHCI. (*)
> I'm not saying tha
> While I agree some of the locking can be made simpler, it can't be
> reduced to 1 lock.
Could you elaborate? It works for OHCI and EHCI, so on
first principles, the same should be true for UHCI. (*)
I'm not saying that some parts of the current drivers don't
assume multiple locks, only that i
Duncan Sands wrote:
> On my windows box a certain URB is sent down with
> transfer flags = 3 = 2 + 1. The 1 means
> USBD_SHORT_TRANSFER_OK. In the linux usb.h
> I see that 1 means USB_DISABLE_SPD which sounds
> like setting it means short transfers are NOT ok. Are these
> flags the opposite of
Hi,
here is the new one which includes suggestions made,
at least so I hope.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
==
On Mon, Jul 01, 2002, Clemens Ladisch <[EMAIL PROTECTED]> wrote:
> In Linux 2.4.18 with usb-uhci (v1.275), the following code will create
> a TD with wrong toggle bit:
>
> urb->pipe = rcvbulkpipe( ... );
> urb->dev = dev;
> usb_submit_urb(urb);
>
> /* optionally:
On Mon, Jul 01, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > - Given the basic similarities between all that hardware (the only
> > "big" thing that needs to differ much is scanning the HC lists
> > to collect finished transactions), I think both UHCIs can very
> > likely be trimmed d
On my windows box a certain URB is sent down with
transfer flags = 3 = 2 + 1. The 1 means
USBD_SHORT_TRANSFER_OK. In the linux usb.h
I see that 1 means USB_DISABLE_SPD which sounds
like setting it means short transfers are NOT ok. Are these
flags the opposite of each other or do they mean the
s
On Mon, Jul 01, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 27, 2002 at 10:22:58AM -0700, David Brownell wrote:
> > When trying to figure out why the "uhci-hcd" driver was so
> > much bigger than "usb-uhci-hcd" I noticed that most of it
> > was the /proc/driver/uhci support, and that if
Once more, with patch! :)
David Brownell wrote:
> The patch is a small resync against the 2.5 code, which:
>
> - fixes an oops-on-unplug for usb 2.0 hubs
> - makes the hub driver pass the right polling interval
> - merges some comment updates (some FIXMEs are gone)
> - gets rid of a duplicated
The patch is a small resync against the 2.5 code, which:
- fixes an oops-on-unplug for usb 2.0 hubs
- makes the hub driver pass the right polling interval
- merges some comment updates (some FIXMEs are gone)
- gets rid of a duplicated error check
There are still driver features that are 2.5-only
Oliver Neukum wrote:
> this is the first version of the patch to fix module unload races.
> It should fix all bugs David identified and a few more.
>
> To do so it has to get the BKL at a few places more, but it holds
> it for shorter amounts of time.
Sweet! That's the way we've been doing it m
>>That is, the helpers shouldn't drop BKL in some cases but
>>not others. If BKL is held on entry, it should be held on
>>exit too...
>
> Oh, now I understand. I completely agree. In fact the patch
> should do that. The BKL is dropped inside the function, but
> always reacquired. Do you see a bu
Am Dienstag, 2. Juli 2002 18:23 schrieben Sie:
> >>I'd rather not see such helpers _change_ the "BKL held" assertion;
> >>better to keep that as an invariant during these routines.
> >
> > For 2.4 of course sure. But why for 2.5 ? After all reducing BKL
> > is one of the overall goals.
>
> That is
>>I'd rather not see such helpers _change_ the "BKL held" assertion;
>>better to keep that as an invariant during these routines.
>
>
> For 2.4 of course sure. But why for 2.5 ? After all reducing BKL
> is one of the overall goals.
That is, the helpers shouldn't drop BKL in some cases but
not o
Am Dienstag, 2. Juli 2002 17:14 schrieb David Brownell:
> > I've read them. They are, let's say, as yet inconclusive.
> > Anyway, the problem is not limited to 2.5; 2.4 is affected as well.
>
> So the question is how to deal with the current BKL usage,
> which is purely to address rmmod issues. I
> I've read them. They are, let's say, as yet inconclusive.
> Anyway, the problem is not limited to 2.5; 2.4 is affected as well.
So the question is how to deal with the current BKL usage,
which is purely to address rmmod issues. I don't think
that preventing rmmod is desirable.
> For now all
Oliver Neukum wrote:
> Hi,
>
> is this really needed ?
Yes, there need to be some hooks whereby user mode code
can affect driver binding. There are cases where user
mode drivers are preferred, and there have also been
cases where the wrong kernel mode driver kicked in.
>case USBDEVFS_
I forgot to mention that only one of the BAPs run Bluetooth over USB,
the other one runs over a UART interface. (Both modules are CSR
however.)
The original setup looked like this:
(USB)(UART)
PC -- eth -- BAP1 -- bluetooth -- BAP2
where BAP1 acts as a bridge. So,
Hi,
this is the first version of the patch to fix module unload races.
It should fix all bugs David identified and a few more.
To do so it has to get the BKL at a few places more, but it holds
it for shorter amounts of time.
If you want to tell me that I did something terribly wrong,
please do
Pedro Lopez-Cabanillas wrote:
> El Lun 01 Jul 2002 19:24, Clemens Ladisch escribió:
> > The submit call before the unlink will toggle the D0/D1 bit in
> > dev->toggle[]. The call after the unlink will then use the toggled bit
> > although the TD of the unlinked URB hasn't been completed successful
David Brownell wrote:
> > The submit call before the unlink will toggle the D0/D1 bit in
> > dev->toggle[]. The call after the unlink will then use the toggled bit
> > although the TD of the unlinked URB hasn't been completed successfully.
> > Consequently, the next packet to be received will be l
Greg KH wrote:
>
> It's up to the device driver to detect that the error was one that is
> recoverable, and to fix it. As you found out, the bluetooth.c driver
> does not do that :(
Would sending a usb_clear_halt do the trick?
> I'd be interested as to why the stall happens, any ideas about th
On Mon, 1 Jul 2002 23:45:34 -0700
"Greg KH" <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 28, 2002 at 04:47:57PM +0200, Soewono Effendi wrote:
> >
> > And I think there must be some locking to protect
> > if (driver->owner)
> > __MOD_INC_USE_COUNT(driver->owner);
> > and
> >
> > The goal is just to minimize the kernel locking time as much as
> > possible, with the cost of size, I admit that.
>
> Why do you think that the BKL or any lock is needed around the test and
> set functions?
>
> I agree module unloading is extreemly racy, but take a look at the
> current thre
> And hopefully most of these hotplug calls will get merged together into
> the driverfs core soon, and we remember to pay attention to the return
> value there :)
How would driverfs do that -- a new bus level callback to
fill out the environment and argv for hotplug events? Each
bus framework n
29 matches
Mail list logo
