On Thu, 3 May 2007, Greg KH wrote:
> > Here's a list of the patches I have submitted which haven't been applied:
> Yeah, can you resend all of these to me? Due to the number of times
> some of these patches were updated, I wanted to make sure that I had the
> correct ones.
I'll send them off-li
Am Donnerstag, 3. Mai 2007 09:05 schrieb Greg KH:
> So, can everyone check their patch queues with what I have applied from
> you already, and resend anything that I've missed (and I'm pretty sure
> I've missed something from all of you...)
This patch fixes a problem reported with consecutive read
On Thu, May 03, 2007 at 10:31:18AM -0400, Alan Stern wrote:
> On Thu, 3 May 2007, Greg KH wrote:
>
> > Hi all,
> >
> > I've tried to apply all of the pending USB patches that everyone has
> > sent me, but I know I missed a lot, due to odd mis-merges,and me not
> > wanting to take some of the auto
On Thu, 3 May 2007, Greg KH wrote:
> Hi all,
>
> I've tried to apply all of the pending USB patches that everyone has
> sent me, but I know I missed a lot, due to odd mis-merges,and me not
> wanting to take some of the auto-suspend stuff just yet.
>
> So, can everyone check their patch queues wi
Hi all,
I've tried to apply all of the pending USB patches that everyone has
sent me, but I know I missed a lot, due to odd mis-merges,and me not
wanting to take some of the auto-suspend stuff just yet.
So, can everyone check their patch queues with what I have applied from
you already, and resen
Dell supplied me with the following test:
#include
#include
#include
#include
#include
main(int argc,char*argv[])
{
struct usbdevfs_hub_portinfo hubPortInfo = {0};
struct usbdevfs_ioctl command = {0};
command.ifno = 0;
command.ioctl_code = USBDEVFS_HUB_PORTINFO;
command.data = (voi
Hi all,
I've applied all of the usb patches that I can find in my patch queue,
so if you've sent me something and I haven't responded back to it,
please rediff it against the latest tree and resend it.
thanks,
greg k-h
---
This SF.net email i
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
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 right
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
Olaf Hering wrote:
On Wed, Mar 17, David Brownell wrote:
Actually what's needed is a _correct_ patch ... that's been
the holdup all along. All endpoint transfer intervals use
a log2 encoding, except full/low speed interrupt transfers.
The attached patch should be correct.
zero size patch? I lo
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 (
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_ pat
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,
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 p
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 c
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
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
On Mon, Dec 29, 2003 at 12:49:46PM -0800, David Brownell wrote:
> David Brownell wrote:
> >This patch is needed to make high bandwidth ISO streams behave,
> >but could resolve some other scanning glitches. Current users
> >of periodic transfers (interrupt transfer modes for hubs, mice,
> >and keyb
On Mon, Dec 29, 2003 at 12:34:09PM -0800, David Brownell wrote:
> David Brownell wrote:
> >This is minor "obvious" fixes plus two tweaks to help later
> >patches:
> >
> > - Interrupt QH has a link to the device, needed to implement
> > schedule trees (like OHCI does today) that are TT-aware
>
Duncan Sands wrote:
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 usb_d
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 usb_driver_release_interf
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 ha
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 rel
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?
>
> H
> 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))
>
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
> 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
> devi
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:
kobject_set_name(&dev->ko
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 Manage
> It's still not right though ... the "registering..."
> messages are all emitted before the first registration
> gets done by device_add. That would definitely be
> noticed ... the probe() messages will seem to appear
> out of sequence!
OK - I will fix that. By the way, the Oops this change
fix
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 succeed
> 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 Confi
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 sa
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 witho
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
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 drive
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
> > 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 test
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 c
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 j
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 fiel
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
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 dro
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?
Rega
> >>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 ==
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 re
> 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 em
> > 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
> 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
John Heil wrote:
Attached is a version of David's 'ehci update: 3/3, highspeed iso rewrite'
patch that is slightly modified to apply to Andrew Morton's 2.6.0-mm
versions of the 2.6.0 kernel:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0/
The original ehci-1228c.patch has a r
Attached is a version of David's 'ehci update: 3/3, highspeed iso rewrite'
patch that is slightly modified to apply to Andrew Morton's 2.6.0-mm
versions of the 2.6.0 kernel:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0/
The original ehci-1228c.patch has a rejected hunk.
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
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'
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 c
>- 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
David Brownell wrote:
This patch is needed to make high bandwidth ISO streams behave,
but could resolve some other scanning glitches. Current users
of periodic transfers (interrupt transfer modes for hubs, mice,
and keyboards) shouldn't even notice this change.
It makes the periodic schedule scan
David Brownell wrote:
This is minor "obvious" fixes plus two tweaks to help later
patches:
- Interrupt QH has a link to the device, needed to implement
schedule trees (like OHCI does today) that are TT-aware
(essential for most keyboards and mice).
- Export the macros that do high b
This is an updated version of a patch submitted to me from
Michal Sojka <[EMAIL PROTECTED]>, basically providing a
much-needed rewrite of the highspeed ISO support. I updated
the scheduling and made it a closer match to how OHCI works;
and also tested it a bunch.
So far it seems most of the reques
This is minor "obvious" fixes plus two tweaks to help later
patches:
- Interrupt QH has a link to the device, needed to implement
schedule trees (like OHCI does today) that are TT-aware
(essential for most keyboards and mice).
- Export the macros that do high bandwidth packetsize st
This patch is needed to make high bandwidth ISO streams behave,
but could resolve some other scanning glitches. Current users
of periodic transfers (interrupt transfer modes for hubs, mice,
and keyboards) shouldn't even notice this change.
It makes the periodic schedule scan handle cases where a g
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.
Lo
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.
#original patch by
The following patch was created by Benoit PAPILLAULT
(http://benoit.papillault.free.fr).
It corrects the following bug : it initializes the value of interval for
iso urb otherwise it would be 0 and would
produce an error.
This bug only shows up with our driver (eciadsl, http://eciadsl.flashtux.org
64 matches
Mail list logo
