On Wednesday 07 June 2006 6:11 am, Franck Bui-Huu wrote:
> When closing the device, the driver acquires/release twice the
> port lock before/after waiting for the data to be completely
> sent. Therefore it will dead lock.
>
> This patch fixes it and also uses the generic scheduler services
> for w
> > > My concern here is that can I still believe that fixing ALLOC_FLAGS
> > > would solve the issue. I may be asking a basic question here, sorry.
On the 2.4 kernels, ALLOC_FLAGS was a gross and ugly hack
to avoid passing SLAB_KERNEL everywhere (i.e. inappropriately).
The 2.6 kernels have a _
On Sunday 28 May 2006 11:22 am, Bryan O'Donoghue wrote:
> Greetings list.
>
> I hate for my first posting here to be a question, however.
>
> Would the list have an objection were I to submit a patch to Das U-Boot
> the Embedded Bootloader which used VendorID 0x0525 and ProductID 0xa4a6
Assig
On Monday 29 May 2006 6:29 am, Rodolfo Giometti wrote:
> + .suspend = ohci_au1xxx_suspend,
> + .resume = ohci_au1xxx_resume,
You shouldn't add both the PCI glue calls (those above) *AND*
the platform bus glue calls:
> + .suspend= ohci_hcd_au1xx
On Wednesday 31 May 2006 1:33 am, Rafał Bilski wrote:
> Please consider using pci_choose_state() for translation
> from message.event to pci_power_t.
I think this is wrong, and that pci_choose_state() is so
broken in its current form that it's not worth considering.
You should fix that pci call t
And here are comments on the other (larger/less-obvious/more-intrusive)
patches in that batch. The directions are IMO good, but these changes
are hardly bite-sized and I think it'd be easier to not-break things
if these got rolled out in smaller (and more reviewable) chunks.
- Dave
On Monday 12
On Monday 12 June 2006 12:19 pm, Alan Stern wrote:
> Greg:
>
> This patch (as717) gets rid of the recursion we've always had in the
> suspend and resume routines. Now suspending a hub won't automatically
> suspend all the child devices first, and resuming a hub won't
> automatically resume all
> error:
> - usb_buffer_free(dev->udev, writesize, buf, urb->transfer_dma);
> + if (buf)
> + usb_buffer_free(dev->udev, writesize, buf, urb->transfer_dma);
> usb_free_urb(urb);
I think that's the wrong policy ... whatever code handles that call should
be able to handle
I'll hold back on comments about some of these till later,
but several of them look good.
- Dave
On Monday 12 June 2006 12:15 pm, Alan Stern wrote:
> 1. Change the disconnect checking in devio.c (the usbfs code) so
> that it will detect cases where the device has been unregistered
>
Hi Russell,
I'm working on the port of the USB-Serial layer to the Serial Core [1],
and turns out that most of the USB-Serial drivers does need to sleep in
set_termios(), break_ctl(), get_mctrl() and set_mctrl() calls (which are
not allowed to sleep according to the documentation).
I took a l
On Tue, 13 Jun 2006, David Brownell wrote:
> On Tuesday 13 June 2006 11:08 am, Alan Stern wrote:
> > > > This works okay with external hubs that are polled only 4 times per
> > > > second
> > > > and with edge-triggered status interrupts (like UHCI and, I assume,
> > > > EHCI).
> > > > But wit
On Tuesday 13 June 2006 11:08 am, Alan Stern wrote:
> > > This works okay with external hubs that are polled only 4 times per second
> > > and with edge-triggered status interrupts (like UHCI and, I assume,
> > > EHCI).
> > > But with level-triggered interrupts it will fail badly. Khubd will
>
David Brownell wrote:
> So to summarize all that discussion ... no disconnect race in usbnet.
> Right?
Yep, unregister_netdev ensures that the case I suggested does not happen.
Daniel
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the
On Tue, 13 Jun 2006, David Brownell wrote:
> > But the Gadget API doesn't provide any simple way to specify time
> > limits for ISO submissions. If the gadget driver wants to send 100
> > packets at roughly 1-ms intervals, it can't tell the controller driver to
> > forget about a packet that d
On Tue, 13 Jun 2006, David Brownell wrote:
> On Monday 05 June 2006 12:54 pm, Alan Stern wrote:
> > Dave:
> >
> > I just realized there is another problem connected with level-triggered
> > root-hub status interrupts. It probably hasn't affected your tests but
> > the potential is there.
> >
>
On Tue, 13 Jun 2006, David Brownell wrote:
> > What I mean is:
> >
> > echo -n 2 >/sys/.../4-2/4-2:1.0/power/state
> >
> > does nothing, while
> >
> > echo -n 2 >/sys/.../4-2/power/state
> >
> > calls all the interface drivers' suspend methods and then suspends the
> > device itself.
On Friday 19 May 2006 2:22 pm, Alan Stern wrote:
> However it does point out a weak area of the Gadget API. Typically ISO
> transfers involve time-sensitive data. That is, if a transfer fails you
> prefer to ignore the failure rather than spending time to fix it.
And for ISO, the hardware is
On Monday 05 June 2006 12:54 pm, Alan Stern wrote:
> Dave:
>
> I just realized there is another problem connected with level-triggered
> root-hub status interrupts. It probably hasn't affected your tests but
> the potential is there.
>
> Two routines in the hub driver can cause port-change event
> > > while a request directed at an interface does nothing (but
> > > returns 0).
> >
> > That seems odd. For example, how is the _device_ ever going to
> > be able to suspend, if the interfaces always stay active???
> >
> > There needs to be some mechanism whereby the interface drivers
> > g
This should change no behavior.
- Dave
This removes extraneous whitespace from the Ethernet/RNDIS gadget driver.
It's all space-at-EOL, spaces-before-tabs, or tabs-then-spaces.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26/drivers/usb/gadget/ether.c
==
On Tuesday 13 June 2006 9:12 am, Johannes Berg wrote:
> On Sat, 2006-06-10 at 13:28 +, Pavel Machek wrote:
>
> > I do not think we support remote wakeup these days. Code may be there,
> > but as noone ever uses it... perhaps it needs some fixing.
>
> Works fine with bluetooth on my powerbook,
This is one of several patches that reduce some of the usb-related clutter
in the toplevel include/linux directory. Presumably you have some GIT magic
that can be used to avoid losing history for such header files?
- Dave
This moves to to reduce some of the
clutter of usb header files.
Signed
More unclutterance.
Move to and remove some
redundant includes.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/usb/input/touchkitusb.c
===
--- linux-2.6.orig/drivers/usb/input/touchkitusb.c 2006-04-17 20
Another patch to unclutter include/linux/*h ... this one affecting the
declarations for some board-specific controller data.
- Dave
This moves header files for controller-specific platform data
from to to start reducing
some clutter.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26
On Tue, 13 Jun 2006, David Brownell wrote:
> > Interesting you should bring this up. As part of my autosuspend
> > development, I decided it would simplify things if devices and their
> > interfaces were always suspended together.
>
> And for such discussions, the canonical example is a USB sp
On Thursday 08 June 2006 11:52 pm, naveen kumar wrote:
> Right now I am tyring to call ehci_hub_suspend call
> directly from another module using EXPORT_SYMBOL, but
There are lots of reasons that driver-internal symbols
do not get exported. In this case, you really can't
guarantee the correct sy
So to summarize all that discussion ... no disconnect race in usbnet.
Right?
- Dave
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
> http://bugzilla.kernel.org/show_bug.cgi?id=6661
Trivial low-priority patch attached.
In a rare and all-but-unused path, the EHCI driver could reuse a variable
in a way that'd make trouble. Specifically, if the first root hub port
gets an overcurrent event (rare) during a remote wakeup scenario
On Friday 09 June 2006 7:36 am, Alan Stern wrote:
> On Thu, 8 Jun 2006, David Brownell wrote:
>
> > Agreed that with USB at least we know some good things to do which
> > we have not yet done ... like autosuspending devices, and thereby
> > reducing VBUS consumption by factors on the order of 100.
On Sat, 2006-06-10 at 13:28 +, Pavel Machek wrote:
> I do not think we support remote wakeup these days. Code may be there,
> but as noone ever uses it... perhaps it needs some fixing.
Works fine with bluetooth on my powerbook, but then again, I can't turn
it *off* which is rather annoying, b
Hello,
I've submitted an entry for unusualdevs.h to fix some I/O error on
Motorola V3x.
Is there someone who can tell me if this entry will compare in the next
kernel release?
Regards,
Davide Perini
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor
On Tue, 13 Jun 2006, Rainer Becker wrote:
> Alan Stern schrieb:
> > On Fri, 2 Jun 2006, Rainer Becker wrote:
> >
> >>> I'm getting a little confused. Is "the problem" that you have so many
> >>> messages in the log and it takes a long time, or is "the problem" that
> >>> the
> >>> port cannot
On Mon, 12 Jun 2006, Greg KH wrote:
> On Mon, Jun 12, 2006 at 03:16:31PM -0400, Alan Stern wrote:
> > Greg:
> >
> > This patch (as712) fixes the usb-skeleton example driver so that it won't
> > try to submit URBs after skel_disconnect() has returned. This could cause
> > errors, if the driver wa
On Mon, 12 Jun 2006, Greg KH wrote:
> One comment thought:
>
> > @@ -516,14 +756,14 @@ static int usb_uevent(struct device *dev
> > /* driver is often null here; dev_dbg() would oops */
> > pr_debug ("usb %s: uevent\n", dev->bus_id);
> >
> > - /* Must check driver_data here, as on rem
regression.
Begin forwarded message:
Date: Tue, 13 Jun 2006 06:24:40 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bug 6684] New: USB mouse stops working after disconnecting and
reconnecting
http://bugzilla.kernel.org/show_bug.cgi?id=6684
Summary: USB mouse stops
Hello,
I've submitted an entry for unusualdevs.h to fix some I/O error on
Motorola V3x.
Is there someone who can tell me if this entry will compare in the next
kernel release?
Regards,
Davide Perini
___
linux-usb-devel@lists.sourceforge.net
To unsub
H Y W I . P K- H o l l y w o o d I n t e r m e d i a t e, Inc.
We Strongly believe in this companies Performance, with its 5th stright day of
climb
Watch what happens next
See Hot NEWS Just released
today was a prelude
S Y M B O L : H-Y-W-I.PK
Current Price: $ 1.01
7 Day Projected : $ 4.50
Th
Greg KH <[EMAIL PROTECTED]> writes:
> On Thu, Jun 08, 2006 at 09:16:17AM +0400, Sergei Organov wrote:
>> Hi Luiz,
>>
>> "Luiz Fernando N. Capitulino" <[EMAIL PROTECTED]> writes:
>> > Hi Sergei,
>> [...]
>> > I said 'current design' because the generic code could be merged
>> > with usbserial co
Hi all,
I have the isp116x-hcd driver running on my ixp425 platform under kernel
2.6.14. The driver seems to be loading and initializing the USB HC
device properly. However as soon as a plug a mouse or any other similar
device i get " device descriptor read/64, error -32 " followed by "
devic
39 matches
Mail list logo
