Hi, I'd like to know why the patch didn't get included in the 2.6.5 is
it the lack of time or anything else ?
Thanks,
Antoine REVERSAT aka Crevetor
Le jeu 18/03/2004 à 00:08, David Brownell a écrit :
Olaf Hering wrote:
On Wed, Mar 17, David Brownell wrote:
Actually what's needed is a
areversat wrote:
Hi, I'd like to know why the patch didn't get included in the 2.6.5 is
it the lack of time or anything else ?
Nobody confirmed that it actually did the right thing...
But I was going to dig it up and forward it to Greg
for the 2.6.6-pre patches (and 2.6.5-mm), since it
looks
If you want me to i can test it tonight to see if it does correct the
problem for which i initially posted. I'll let you know if it does.
Bye
Le lun 05/04/2004 à 20:40, David Brownell a écrit :
areversat wrote:
Hi, I'd like to know why the patch didn't get included in the 2.6.5 is
it the lack
areversat wrote:
This patch is still required as far as i know. The eciadsl driver
doesn't work with the 2.6.4 kernel without that patch. I don't think
anybody has tested it with the 2.6.5rc1 kernel. If this is needed i can
do it next week-end (not sooner).
Actually what's needed is a _correct_
On Wed, Mar 17, David Brownell wrote:
areversat wrote:
This patch is still required as far as i know. The eciadsl driver
doesn't work with the 2.6.4 kernel without that patch. I don't think
anybody has tested it with the 2.6.5rc1 kernel. If this is needed i can
do it next week-end (not
On Wed, Feb 18, don wrote:
On Wed, Feb 18, 2004 at 01:22:36PM -0800, David Brownell wrote:
areversat wrote:
I'd like to know how this usb patch is going ? Is there still a lot to
do or will it be ready for 2.6.4 ? We'd like to know.
It'd sure help if someone submitted a patch with
This patch is still required as far as i know. The eciadsl driver
doesn't work with the 2.6.4 kernel without that patch. I don't think
anybody has tested it with the 2.6.5rc1 kernel. If this is needed i can
do it next week-end (not sooner).
Antoine REVERSAT aka Crevetor
Le mar 16/03/2004 à 21:56,
I'd like to know how this usb patch is going ? Is there still a lot to
do or will it be ready for 2.6.4 ? We'd like to know.
Thanks
Antoine REVERSAT
Le sam 27/12/2003 à 23:35, David Brownell a écrit :
To be clear: I won't be integrating this, and my recommendation is
that Duncan handle this
areversat wrote:
I'd like to know how this usb patch is going ? Is there still a lot to
do or will it be ready for 2.6.4 ? We'd like to know.
It'd sure help if someone submitted a patch with those revisions...
---
SF.Net is sponsored by: Speed
On Wed, Feb 18, 2004 at 01:22:36PM -0800, David Brownell wrote:
areversat wrote:
I'd like to know how this usb patch is going ? Is there still a lot to
do or will it be ready for 2.6.4 ? We'd like to know.
It'd sure help if someone submitted a patch with those revisions...
I'm a bit
Having usb_driver_release_interface call disconnect runs the risk of
infinite disconnect loops if the disconnect() method calls
usb_driver_release_interface.
I've been dealing with this by patching device drivers, but it would be better if the
core took care if it. Since
Duncan Sands wrote:
Hi Dave, I guess the same check is needed in usb_driver_release_interface,
in case someone claims and releases an interface before it has been
device_add()ed. This leads to the following behaviour though: if in your
probe() method you claim and release another interface that
On Friday 09 January 2004 02:10, David Brownell wrote:
Duncan Sands wrote:
Thanks a lot. This is extremely problematic then: in
usb_set_configuration, an interface's device structure will not be
completely initialized until we do device_add (intf-dev);
...
What to do?
Hmm, good
On Sat, 10 Jan 2004, Duncan Sands wrote:
Hi Dave, I guess the same check is needed in usb_driver_release_interface,
in case someone claims and releases an interface before it has been
device_add()ed. This leads to the following behaviour though: if in your
probe() method you claim and
Hmm, good catch! Looks to me like usb_driver_claim_interface() will
need to check whether the device has been added yet. Something like
this should do it:
intf-dev.driver = driver-driver;
intf-dev.driver_data = priv;
if (!list_empty (intf-dev.bus_list))
I'll give this a whirl; drivers/usb/class/{audio,cdc-acm}.c also
need changes, but this is a good start.
Yes, I forgot about them.
Ciao,
Duncan.
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software
Duncan Sands wrote:
Hi Dave, I had another look at this bit:
Also I'd revert the change to create the driverfs interface files
after all the probes succeed;
my patch doesn't create the driverfs interface files after all probes
succeeds, it creates each one after the associated probe has
Any idea where the usb interface's device's kobject's name is setup?
I'm talking about kobject_name(intf-dev-kobj).
Thanks,
Duncan.
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration
On Thu, 8 Jan 2004, Duncan Sands wrote:
Any idea where the usb interface's device's kobject's name is setup?
I'm talking about kobject_name(intf-dev-kobj).
Well, the device's kobject's name is set in
drivers/base/core.c:device_add() by this line of code:
Well, the device's kobject's name is set in
drivers/base/core.c:device_add() by this line of code:
kobject_set_name(dev-kobj,dev-bus_id);
device_add(), in turn, is called by usb_set_configuration (or maybe in
your version of the code it's device_register(), which calls
device_add()).
Duncan Sands wrote:
Thanks a lot. This is extremely problematic then: in usb_set_configuration,
an interface's device structure will not be completely initialized until we do
device_add (intf-dev);
...
What to do?
Hmm, good catch! Looks to me like usb_driver_claim_interface() will
need
On Monday 05 January 2004 16:42, David Brownell wrote:
Duncan Sands wrote:
Hi Dave, the obvious thing to do (once intf-driver is thrown away)
is to call device_release_driver in usb_driver_release_interface.
The usb_driver_release_interface() call could reasonably
become just an inline
On Tue, 6 Jan 2004, Duncan Sands wrote:
On Monday 05 January 2004 16:42, David Brownell wrote:
There are a lot of is it null? tests that are just pointless
code bloat. It's not a big deal, but getting rid of such stuff
needs to start somewhere.
Hi Dave, I don't much buy the code bloat
Hi Dave, I don't much buy the code bloat argument. For me it's
like this: these routines are called from device drivers.
case (1): these tests may prevent a device driver from screwing
the USB subsystem/other drivers. In this case they should stay.
case (2): these tests only
On Tue, 6 Jan 2004, Duncan Sands wrote:
Hi Alan, if you check out the patch you will see that I concluded that all the
tests in question fell into case (2) and removed them. I think we both
agree about case (2). I guess there is some confusion about case (1).
If the result of not testing is
Hi Dave, I don't much buy the code bloat argument. For me it's
like this: these routines are called from device drivers.
case (1): these tests may prevent a device driver from screwing
the USB subsystem/other drivers. In this case they should stay.
case (2): these tests only protect device
I'm seen too many cases of code like this (from core/hcd.c:hcd_alloc_dev):
if (!udev || udev-hcpriv)
return -EINVAL;
if (!udev-bus || !udev-bus-hcpriv)
return -ENODEV;
with no explanation or comment about whether those tests are _ever_
supposed to
Hi Dave,
It reads well. Presumably you tested with usbfs and the ALSA sound
driver?
I have never managed to get my only usb sound device working. So I can't
test if sound goes in and out OK. But I can connect/disconnect without Oops.
I tested usbfs of course. It shouldn't be applied
Hi Dave, I had another look at this bit:
Also I'd revert the change to create the driverfs interface files
after all the probes succeed;
my patch doesn't create the driverfs interface files after all probes
succeeds, it creates each one after the associated probe has succeeded.
This is the
Duncan Sands wrote:
Drivers without code like that can be easily patched, even
before usb_interface.driver is removed.
I should mention that indeed there is no big problem fixing
the drivers. But is it the way we want to go?
I think so, yes. Do you have an alternative approach to suggest?
Duncan Sands wrote:
Hi Dave, the obvious thing to do (once intf-driver is thrown away)
is to call device_release_driver in usb_driver_release_interface.
The usb_driver_release_interface() call could reasonably
become just an inline function (without those null checks)
doing exactly that.
Why
Sorry i'm late responding to this mail but i had a chat with benoit
about this patch and we were wondering why it wasn't good since the
exact same code is used to initialize interval for INTERRUPT URBs could
you explain us why ? Thanks
Antoine REVERSAT aka Crevetor
Le sam 27/12/2003 à 21:06, David
areversat wrote:
Sorry i'm late responding to this mail but i had a chat with benoit
about this patch and we were wondering why it wasn't good since the
exact same code is used to initialize interval for INTERRUPT URBs could
you explain us why ? Thanks
Read the USB spec about how the bInterval
If you need to have disconnect() called in all cases, feel free
to get rid of usb_interface.driver ...
How about this? While I was at it, I changed some -1L's into NULL
in ALSA's USB audio driver because they didn't please me :)
Duncan.
= drivers/usb/core/devices.c 1.22 vs edited =
If you need to have disconnect() called in all cases, feel free
to get rid of usb_interface.driver ... it needs to go someday,
and I'd guess that's making trouble for you.
I can't see the CDC (ACM, Ethernet) or audio (ALSA, OSS) drivers
getting into trouble with that any time soon, but those
Hi Dave, the obvious thing to do (once intf-driver is thrown away)
is to call device_release_driver in usb_driver_release_interface.
The usb_driver_release_interface() call could reasonably
become just an inline function (without those null checks)
doing exactly that.
Why drop the checks?
Drivers without code like that can be easily patched, even
before usb_interface.driver is removed.
I should mention that indeed there is no big problem fixing
the drivers. But is it the way we want to go?
Ciao,
Duncan.
---
This SF.net
Hi Duncan,
If you need to have disconnect() called in all cases, feel free
to get rid of usb_interface.driver ...
Hi Dave, the obvious thing to do (once intf-driver is thrown away)
is to call device_release_driver in usb_driver_release_interface.
The usb_driver_release_interface() call could
Hi Dave,
...
usb_set_configuration. Can you please tell me - how (and where) is
a driver's disconnect method called? I ask because in some situations
Disconnection is only triggered through the driver model, somewhere
in the device_del() and/or device_release_driver() paths. That's
a
Hi Duncan,
If you need to have disconnect() called in all cases, feel free
to get rid of usb_interface.driver ... it needs to go someday,
and I'd guess that's making trouble for you.
I'm happy to get rid of it... but I don't really want my usbfs fix to
change behaviour for other drivers.
When I
- That epnum_to_ep_desc() result shouldn't be used without a bit
more locking; else the config could change from under usbfs.
...
I cc'd Duncan Sands, who's got a devio.c patch in the works that'll
fix a bunch of such stuff.
Hi Dave, I'm sorry that my patch is slow in coming - I'm
Duncan Sands wrote:
- That epnum_to_ep_desc() result shouldn't be used without a bit
more locking; else the config could change from under usbfs.
...
I cc'd Duncan Sands, who's got a devio.c patch in the works that'll
fix a bunch of such stuff.
Hi Dave, I'm sorry that my patch is slow in
areversat wrote:
Here is a patch that fixes the following problem : interval of iso urbs
doesn't get set. This big is still appearing in the 2.6.O kernel.
It would be good to fix it as we (the eciadsl programmers) use iso
packets and it causes the driver not to work unless you patch your
kernel.
43 matches
Mail list logo
