On Sun, May 12, 2002 at 03:28:49PM -0400, Johannes Erdfelt wrote:
I've tested with uhci and usb-ohci with no adverse effects.
Looks good. I have a follow-on patch to yours that I'll send in a bit
after more testing. But I did have one question:
diff -ur
Here's a follow up patch to be applied on top of your previous patch.
Much of the confusion for me (and probably others) was the fact that we
had to modify reference counts of devices and then free them up when we
were finished with them. Why make the driver authors have to figure out
the count
On Sun, May 12, 2002 at 11:34:12PM -0700, Greg KH wrote:
-_static int uhci_free_dev (struct usb_device *usb_dev)
-{
- uhci_t *s;
-
-
- if(!usb_dev || !usb_dev-bus || !usb_dev-bus-hcpriv)
- return -EINVAL;
-
- s=(uhci_t*) usb_dev-bus-hcpriv;
-
On Mon, May 13, 2002 at 11:15:42AM +0200, Georg Acher wrote:
On Sun, May 12, 2002 at 11:34:12PM -0700, Greg KH wrote:
-_static int uhci_free_dev (struct usb_device *usb_dev)
-{
- uhci_t *s;
-
-
- if(!usb_dev || !usb_dev-bus || !usb_dev-bus-hcpriv)
- return
should device drivers call usb_get_dev() like some
currently do (storage, some network, and the usbvideo core)? Does this
protect something from happening that I don't see?
I think earlier on, when the whole stack was less well developed,
device drivers doing that refcounting were
On Mon, May 13, 2002, Greg KH [EMAIL PROTECTED] wrote:
Here's a follow up patch to be applied on top of your previous patch.
Much of the confusion for me (and probably others) was the fact that we
had to modify reference counts of devices and then free them up when we
were finished with
On Mon, May 13, 2002 at 11:31:17AM -0400, Johannes Erdfelt wrote:
On Mon, May 13, 2002, Greg KH [EMAIL PROTECTED] wrote:
Here's a follow up patch to be applied on top of your previous patch.
Much of the confusion for me (and probably others) was the fact that we
had to modify reference
On Mon, May 13, 2002 at 03:50:15AM -0700, David Brownell wrote:
should device drivers call usb_get_dev() like some
currently do (storage, some network, and the usbvideo core)? Does this
protect something from happening that I don't see?
I think earlier on, when the whole stack was
On Mon, May 13, 2002, Georg Acher [EMAIL PROTECTED] wrote:
On Sun, May 12, 2002 at 11:34:12PM -0700, Greg KH wrote:
-_static int uhci_free_dev (struct usb_device *usb_dev)
-{
- uhci_t *s;
-
-
- if(!usb_dev || !usb_dev-bus || !usb_dev-bus-hcpriv)
- return
On Mon, May 13, 2002, Greg KH [EMAIL PROTECTED] wrote:
On Mon, May 13, 2002 at 11:31:17AM -0400, Johannes Erdfelt wrote:
Now when the last person calls usb_put_dev() or usb_free_dev() the
structure is cleaned up. This allows the different host controller
drivers to implement their
On Mon, May 13, 2002, Greg KH [EMAIL PROTECTED] wrote:
On Mon, May 13, 2002 at 12:19:48PM -0400, Johannes Erdfelt wrote:
So what you wrote above Now when the last person calls
usb_put_dev()... was also describing the changes relative to David's
original method of doing reference
should device drivers call usb_get_dev() like some
currently do (storage, some network, and the usbvideo core)? Does this
protect something from happening that I don't see?
I think earlier on, when the whole stack was less well developed,
device drivers doing that
On Mon, May 13, 2002 at 12:26:55PM -0700, David Brownell wrote:
See my previous response to Johannes about
what Documentation/CodingStyle says.
You quoted if another thread can find your data structure,
and you don't have a reference count on it you almost
certainly have a bug. But
Johannes, in one note you said
I don't think anyone was arguing how the proper way to their write their
host controller driver is, but rather what the proper coding convention
is in the kernel.
but then you later contradicted yourself by responding to Greg:
So can the
allocate() and
See my previous response to Johannes about
what Documentation/CodingStyle says.
You quoted if another thread can find your data structure,
and you don't have a reference count on it you almost
certainly have a bug. But see above -- the count does
not need to be
On Mon, May 13, 2002, David Brownell [EMAIL PROTECTED] wrote:
Johannes, in one note you said
I don't think anyone was arguing how the proper way to their write their
host controller driver is, but rather what the proper coding convention
is in the kernel.
but then you later
On Mon, May 13, 2002 at 03:51:54PM -0700, David Brownell wrote:
See my previous response to Johannes about
what Documentation/CodingStyle says.
You quoted if another thread can find your data structure,
and you don't have a reference count on it you almost
certainly have
On Mon, May 13, 2002, David Brownell [EMAIL PROTECTED] wrote:
See my previous response to Johannes about
what Documentation/CodingStyle says.
You quoted if another thread can find your data structure,
and you don't have a reference count on it you almost
certainly have a
How about this. Given mine and Johannes's patches, do you see any
problems in the code? Does it break anything?
Yes, as I noted separately. Move the deallocate() call and
it'll behave though.
- Dave
___
Have big pipes?
We _have_ that protection because only device drivers that
claim an interface, perhaps via probe(), are allowed to use
that device. To repeat: the protection doesn't need to be
explicit in the driver programming interfaces.
On the other hand, usbdevfs doesn't necessarily bother to
On Mon, May 13, 2002, David Brownell [EMAIL PROTECTED] wrote:
We _have_ that protection because only device drivers that
claim an interface, perhaps via probe(), are allowed to use
that device. To repeat: the protection doesn't need to be
explicit in the driver programming
except inside usbcore, wouldn't exactly a
lead weight ... :)
- Dave
- Original Message -
From: Johannes Erdfelt [EMAIL PROTECTED]
To: David Brownell [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, May 13, 2002 5:34 PM
Subject: Re: [linux-usb-devel] Re: [patch] 2.5.15 USB device
22 matches
Mail list logo
