This patch removes the need for a workaround when unlinking
periodic urbs in their completion handlers, removing a FIXME.
Against 2.5.2-pre11 but it should work also against 2.5.2 final.
- Dave
hcd-0115.patch
Description: Binary data
Hi i was just inquiring into whether anyone had a chance to look at my
email containing info about the diamond data usb cdrw and had some input
they would like to share?
i really want to get my cdrw working under linux then i wont have to keep
windows on my machine anymore.
Regards,
Dylan
> > > There are hundreds of drivers, and three hcds. Surely it would be better
> > > to let the HCD do the relevant hoop jumping in these cases.
> >
> > They do. Apart from some massive (and it "really serioiusly"
> > appears to me, intentional) confusion on Oliver's part, I don't
> > see a probl
> refcounting is based on the fact that the object is freed when the count
> hits zero. It doesn't matter who drops the last reference, at that point
> nobody is using it.
Didn't we just have a similar discussion with respect to
usb_dec_dev_use(dev)
One of the issues is that really only t
I was just browsing, and I noticed that the linux-hfsplus project on
sourceforge has a system to automatically generate e-mail whenever someone
does a checkin.
I'd like to add this functionality to support at least the usb-storage
development module...
Any objections?
Matt
--
Matthew Dharm
> > Having refcount mechanisms doesn't help when the basic
> > problem is keeping pointers around after they've become
> > invalid (for whatever reason).
>
> It helps with the underlying problem of "when can I reference this".
But it's not sufficient. You're still DOA if you try to do what
Oliv
On Wed, Jan 16, 2002 at 01:22:20AM +, Alan Cox wrote:
>
> People are struggling to get the drivers right, and we haven't even got to
> the full party game of
>
> "I'm in my completion handler removing the urb while on cpu #2
>the irq handler might be running, cpu 3 someone is c
> Having refcount mechanisms doesn't help when the basic
> problem is keeping pointers around after they've become
> invalid (for whatever reason).
It helps with the underlying problem of "when can I reference this". You
always know that answer
o If someone passed it to me it is safe
o
> count" function does an automatic free when the count hits zero. Yes, it
> means that you need to manage the refcounts. But is that such a problem?
> If nothing else, doing explicitly will clear up the ambiguities.
I dont think its a big problem. When you are passed an urb its referenced
by t
> wakes the driver, but that can be solved by the driver setting a flag
> that indicates that the urb should be freed when the count reaches zero.
> The actual freeing is done as the HCD drops its reference.
refcounting is based on the fact that the object is freed when the count
hits zero. It do
On Wednesday 16 January 2002 01:33, Matthew Dharm wrote:
> hrm.. I know I shouldn't jump in to something like this late, but...
>
> I'm starting to agree with Alan Cox. The problem with Oliver's suggestion
> below (keep a reference to a submitted URB) is that I still don't know when
> it's safe t
hrm.. I know I shouldn't jump in to something like this late, but...
I'm starting to agree with Alan Cox. The problem with Oliver's suggestion
below (keep a reference to a submitted URB) is that I still don't know when
it's safe to free such a beast.
If we say that an URB is referenced by both
On Wednesday 16 January 2002 00:15, David Brownell wrote:
> > There are hundreds of drivers, and three hcds. Surely it would be better
> > to let the HCD do the relevant hoop jumping in these cases.
>
> They do. Apart from some massive (and it "really serioiusly"
> appears to me, intentional) con
Dear [EMAIL PROTECTED],
Would you like to send an Email Advertisement to
OVER 12,000,000 PEOPLE DAILY for FREE?
Do you have a product or service to sell?
Do you want an extra 100 orders per week?
NOTE: (If y
The problem I see is that Oliver has been trying to avoid
writing the line of code setting that pointer to zero when
it's no longer in use. The problems he's describing will
not show up when such lines exist in the driver.
Having refcount mechanisms doesn't help when the basic
problem is keeping
> There are hundreds of drivers, and three hcds. Surely it would be better
> to let the HCD do the relevant hoop jumping in these cases.
They do. Apart from some massive (and it "really serioiusly"
appears to me, intentional) confusion on Oliver's part, I don't
see a problem.
- Dave
___
> > I'm sure you can figure several of them out if you think about it for a
> > few minutes. (Hint: if you have a spinlock that protects access to
> > a pointer outside the completion handler, and that pointer is nulled
> > when its data is freed, what else might you need to do??)
>
> Using a s
> I'm sure you can figure several of them out if you think about it for a
> few minutes. (Hint: if you have a spinlock that protects access to
> a pointer outside the completion handler, and that pointer is nulled
> when its data is freed, what else might you need to do??)
Using a spinlock is
> > The amount of bugs and crap refcounting has removed elsewhere in the kernel
> > and more importantly the amount of "if I do X very occasionally [list of
> > weirdness]" things that just went away testify to its value.
>
> That sounds sensible. However is the urb counted as referenced during t
> The amount of bugs and crap refcounting has removed elsewhere in the kernel
> and more importantly the amount of "if I do X very occasionally [list of
> weirdness]" things that just went away testify to its value.
That sounds sensible. However is the urb counted as referenced during the
execut
> The rule of never unlinking an urb that can be freed from the
> completion handler is in all likelihood known to less than
> five people on earth. And it is very, very counterintuitive.
There are hundreds of drivers, and three hcds. Surely it would be better
to let the HCD do the relevant hoop
> And how is the comment in hcd.c on unlinking urbs and
> the validity of the pointers supposed to be understood.
I only see a FIXME that doesn't mention pointer validity ...
since pointer validity isn't the issue.
It does mention a need to remember some state, but I
realized recently that such
> You _cannot_ even in principle synchronize between a completion
> handler and process context. It's a one way street of communication.
> That race is unavoidable.
What about spinlocked data structures? And waitqueues?
And the various other constructs specifically designed for
achieving such sy
On Tuesday 15 January 2002 21:37, David Brownell wrote:
> > After further checking, I found that no HCD driver can cope
> > with unlinking an urb that can be freed from the completion
> > handler.
>
> Without any checking whatsoever, I'll say that no driver in
> the Linux kernel will cope with bei
On Tuesday 15 January 2002 21:21, David Brownell wrote:
> > > > I really doubt that this issue can be not exposed.
> > >
> > > And why is that? I just gave you an argument from first
> > > principles. You can't refute that by pointing to a bug in
> > > one current driver.
> >
> > Because all the
> After further checking, I found that no HCD driver can cope
> with unlinking an urb that can be freed from the completion
> handler.
Without any checking whatsoever, I'll say that no driver in
the Linux kernel will cope with being passed pointers to
memory that's been freed. In fact, most part
> > I really doubt that this issue can be not exposed.
>
> And why is that? I just gave you an argument from first
> principles. You can't refute that by pointing to a bug in
After further checking, I found that no HCD driver can cope
with unlinking an urb that can be freed from the completion
> > > I really doubt that this issue can be not exposed.
> >
> > And why is that? I just gave you an argument from first
> > principles. You can't refute that by pointing to a bug in
> > one current driver.
>
> Because all the HCD has is a pointer that may or may not be valid.
Drivers that don
> Tx interval
> is set to zero for one-shot mode (although it makes no difference if
> I set to the interval value from the endpoint).
I think that "one shot interrupts" are a UHCI-ism. Unlink the
urb in the completion handler, if you need it to complete only
one of its transfers.
> driv
> > I really doubt that this issue can be not exposed.
>
> And why is that? I just gave you an argument from first
> principles. You can't refute that by pointing to a bug in
Because all the HCD has is a pointer that may or may not be valid.
> one current driver:
> > If I may point you to the
> > > The problem is basically that the usbcore in case of an unlink has
> > > to wait while the hardware might be dealing with an urb and the
> > > completion handler is running.
> >
> > Classic urb-unlink issue inside the hcd, doesn't need
> > to be exposed outside. Any given URB is either goin
On Tuesday 15 January 2002 19:42, David Brownell wrote:
> > The problem is basically that the usbcore in case of an unlink has
> > to wait while the hardware might be dealing with an urb and the
> > completion handler is running.
>
> Classic urb-unlink issue inside the hcd, doesn't need
> to be ex
> The problem is basically that the usbcore in case of an unlink has
> to wait while the hardware might be dealing with an urb and the
> completion handler is running.
Classic urb-unlink issue inside the hcd, doesn't need
to be exposed outside. Any given URB is either going
to have completed nor
> In the usb_driver structure I've set an ioctl function. I know my
> driver loads and works, it is running the device just fine. For now, I
> manually look at /proc/bus/usb/devices to find the bus and device number my
> driver is at. Then I hardcode that into my app,
> open("/proc/bus/usb/
On Tue, Jan 15, 2002 at 12:49:05PM -0500, Steve Urquhart wrote:
> Hi,
>
> I'm having a problem trying to get my user mode application to ioctl my usb
> driver. In the usb_driver structure I've set an ioctl function. I know my
> driver loads and works, it is running the device just fine. For no
Hi,
I'm having a problem trying to get my user mode application to ioctl my usb
driver. In the usb_driver structure I've set an ioctl function. I know my
driver loads and works, it is running the device just fine. For now, I
manually look at /proc/bus/usb/devices to find the bus and device num
Hi,
this patch applies to 2.5.2-pre11 and uses modern module usage
counting and removes code dead in a V4L driver.
Regards
Oliver
--- dsbr100.c.alt Mon Jan 14 21:33:09 2002
+++ dsbr100.c Mon Jan 14 21:35:51 2002
@@ -101,6 +101,7 @@
static struct video_device u
Hi,
I'd like to request a minor number for the LEGO USB Tower driver.
The driver is currently beginning to become useable, and IMHO it
would become confusing if we continue with an unofficial number
for much longer.
I think a single minor number will be fine,
IMHO there will be very few people wh
Hi,
I'm working on a device driver which uses interrupt mode transfers in
both directions. The reception side is working happily, but I'm
having some problems with the transmission side. My understanding is
that the following pseudo-code is how I should attempt to use the USB
system (main s
Hello all,
I spent the whole weekend forcing a win2000 CD that was meant only
for Dell computers to install on my (very much non-Dell) compuer... great
fun ;-) It all paid off though. The usb sniffer worked perfectly.
To avoid clogging-up your inboxes with the logs I have put them on
Quoting Greg KH <[EMAIL PROTECTED]>:
> On Tue, Jan 15, 2002 at 12:17:49AM +0100, Bj|rn Augustsson wrote:
> You should copy the maintainer of the HID code too. He needs to aprove
> it.
OK, done.
> > * Changes the type of unit_exponent to be signed in a few places
> > (Including possibly use
Hi David,
I certainly don't argue for the sake of arguing. I see a real problem here.
> > Not from a driver standpoint. If a driver unlinks an urb, it needs
> > to be dead,
>
> As it will be -- after a delay to make sure the hardware finished.
>
> THINK!! It is NOT immediate. For synchronous u
42 matches
Mail list logo
