Hi,
This is an attempt to move the hcd_urb_list_lock to struct usb_hcd.
The lock is taken on functions that try to add/delete/use urb against a
given hcd. I have not seen any association of an urb with multiple hcds.
Hence I thought this can be moved within usb_hcd. This should help
reduce conte
On Fri, 25 Jan 2008, David Brownell wrote:
> On Friday 25 January 2008, Greg KH wrote:
> > Right now we use a "fake" vendor and product id for root hubs in the
> > kernel. However, I'm happy to announce that the Linux Foundation has
> > joined the USB-IF and gotten an "official" usb vendor id ass
On Fri, Jan 25, 2008 at 09:44:32PM +0100, Oliver Neukum wrote:
> Am Freitag, 25. Januar 2008 17:58:56 schrieben Sie:
> > Right now we use a "fake" vendor and product id for root hubs in the
> > kernel. However, I'm happy to announce that the Linux Foundation has
> > joined the USB-IF and gotten an
On Friday 25 January 2008, Greg KH wrote:
> >
> > The ones NetChip gave me are allocated by me, and stored in
> > the usb.ids file. That's probably not the answer you're after
> > (and you'll have 2^12 times as many to worry about), but I
> > do think they should be listed that way.
>
> In readi
On Fri, Jan 25, 2008 at 11:02:24AM -0800, David Brownell wrote:
> On Friday 25 January 2008, Greg KH wrote:
> > Right now we use a "fake" vendor and product id for root hubs in the
> > kernel. However, I'm happy to announce that the Linux Foundation has
> > joined the USB-IF and gotten an "officia
ACKed-by: Matthew Dharm <[EMAIL PROTECTED]>
Matt
On Fri, Jan 25, 2008 at 11:12:21AM -0600, James Bottomley wrote:
> On Thu, 2008-01-24 at 09:21 -0800, Greg KH wrote:
> > On Thu, Jan 24, 2008 at 06:07:00PM +0100, Stefan Richter wrote:
> > > Greg KH wrote:
> > > > I just am worried that we are
> >
On Friday 25 January 2008, Greg KH wrote:
> Right now we use a "fake" vendor and product id for root hubs in the
> kernel. However, I'm happy to announce that the Linux Foundation has
> joined the USB-IF and gotten an "official" usb vendor id assigned to it.
>
> I'm still working on setting up th
FYI, this is a patch that will be sent out in the next round to Linus
for inclusion in 2.6.25.
If anyone has any objections about it, please let me know.
thanks,
greg k-h
From: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Subject: USB: mark USB drivers as being GPL only
Over two years ago,
On Thu, 2008-01-24 at 09:21 -0800, Greg KH wrote:
> On Thu, Jan 24, 2008 at 06:07:00PM +0100, Stefan Richter wrote:
> > Greg KH wrote:
> > > I just am worried that we are
> > > now suddenly keeping access from the last sector for devices that
> > > currently did work just fine.
> >
> > This new wo
On Fri, 25 Jan 2008, Pandita, Vikram wrote:
> usb_kill_urb() ensures that URB is unlinked and callback is called.
>
> My question is, what happens to the URB that is already scheduled by
> underlying HCD and getting processed, and usb_kill_urb() is called?
It's the same as when usb_unlink_urb()
We have actually determined the problem with our board...
and it was much simplier than expected.
a) some initialization code was doing the wrong thing
to some configuration space registers
b) the root 8548 PCI registers were being overwritten
by some process that disabled memory accesses for
usb_kill_urb() ensures that URB is unlinked and callback is called.
My question is, what happens to the URB that is already scheduled by underlying
HCD and getting processed, and usb_kill_urb() is called?
What will be returned by completion handler for such an URB if it was bulk IN
and bulk O
Am Freitag, 25. Januar 2008 17:58:56 schrieben Sie:
> Right now we use a "fake" vendor and product id for root hubs in the
> kernel. However, I'm happy to announce that the Linux Foundation has
> joined the USB-IF and gotten an "official" usb vendor id assigned to it.
>
> I'm still working on set
Am Dienstag, 22. Januar 2008 19:36:45 schrieben Sie:
> > I guess so, because what I'm trying to do is merely just to expose some
> > of the device's (interrupt) endpoints as separate character device files
> > under /dev. The "real" communication is thus moved to a user space app /
> > lib which ha
> On Fri, 25 Jan 2008 08:34:00 -0800 (PST) [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9815
>
>Summary: Unable to mount ipod
>Product: Other
>Version: 2.5
> KernelVersion: 2.6.24
> Platform: All
> OS/Version: Linu
> On Fri, 25 Jan 2008 07:16:49 -0800 (PST) [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9813
>
>Summary: usb mouse broken on X20 (intermittent)
>Product: Drivers
>Version: 2.5
> KernelVersion: 2.6.24
> Platform: All
>
Right now we use a "fake" vendor and product id for root hubs in the
kernel. However, I'm happy to announce that the Linux Foundation has
joined the USB-IF and gotten an "official" usb vendor id assigned to it.
I'm still working on setting up the infrastructure for how to assign
product ids out o
Hi all,
I have a report here of a device in the wild that is using a USB vendor
id of 0x. From everything I can tell, this _could_ be a valid
vendor id, but I'm pretty sure that it isn't :)
Here's the bug report, does anyone have an idea of what we should do
here?
At first glance, we should
On Thu, 24 Jan 2008, David Brownell wrote:
> Some of the "EHCI ports reset forever" problems may be explained by
> code paths which wrongly flagged resets as complete. This removes
> two such paths; the ehci_hub_status_data() path should be the only one
> to have an effect, since it was already p
On Friday 25 January 2008, Alan Stern wrote:
> On Thu, 24 Jan 2008, David Brownell wrote:
>
> > Some of the "EHCI ports reset forever" problems may be explained by
> > code paths which wrongly flagged resets as complete. This removes
> > two such paths; the ehci_hub_status_data() path should be t
20 matches
Mail list logo
