Hi Pete,
I've had no response from Vojtech at all. I did a resend last week,
but no response from that yet. Will follow up once I'm back at home
(am now attending Linux Audio Conference).
Thanks for caring!
Martin
On Fri, Apr 30, 2004 at 12:47:53PM -0700, Pete Zaitcev wrote:
> On Fri, 16 Apr 200
see
http://www.newhousenews.com/archive/francis042904.html
best regards
Wolfgang Mües
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and
Hi. This is the qmail-send program at server2.co.uk.ru.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[EMAIL PROTECTED]>:
Sorry, virus found in your message :(
--- Below this line is a copy of the
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
[EMAIL PROTECTED]
This message has been rejected because it has
a potentially e
VIRUS ALERT
Our content checker found
virus: W32/[EMAIL PROTECTED]
in email presumably from you (<[EMAIL PROTECTED]>), to the following recipient:
-> [EMAIL PROTECTED]
Please check your system for viruses,
or ask your system administrator to do so.
Delivery of the email was stopped!
For yo
On Sat, May 01, 2004 at 09:27:37AM +0100, Martin Habets wrote:
> Hi Pete,
>
> I've had no response from Vojtech at all. I did a resend last week,
> but no response from that yet. Will follow up once I'm back at home
> (am now attending Linux Audio Conference).
I'm fine with the patch, (and sorry
Please apply.
Jürgen
Add device names for LEGO USB Tower to documentation.
--- linux-2.6.6-rc3/Documentation/devices.txt 2004-04-28 03:35:43.0 +0200
+++ linux-2.6.6-rc3-legousbtower-0.95/Documentation/devices.txt 2004-05-01
16:46:42.0 +0200
@@ -2535,7 +2535,9 @@
On Fri, 30 Apr 2004, Pete Zaitcev wrote:
> On Fri, 30 Apr 2004 23:09:31 -0400 (EDT)
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > It may be that we're making ->serialize do too much. For example, my
> > recent change to devices.c uses it to prevent topology changes while
> > traversing the tree,
On Sat, May 01, 2004 at 10:34:49AM +0200, Wolfgang M?es wrote:
> see
>
> http://www.newhousenews.com/archive/francis042904.html
Alan Stern's in it too :)
greg k-h
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest
On Sat, May 01, 2004 at 04:53:38PM +0200, Juergen Stuber wrote:
> The following message is a courtesy copy of an article
> that has been posted to gmane.linux.usb.devel as well.
>
> Please apply.
Heh, it's already in my tree, and in the version on linux-usb.org. I'll
send in a kernel update for
Am Samstag, 1. Mai 2004 17:15 schrieb Alan Stern:
> Instead they can be used by the hub driver to ensure that only one thing
> happens on a hub at any time. When suspending or resetting a port, the
> rule should be to acquire the serialize lock on the child first, then on
> its parent hub. That m
On Fri, Apr 30, 2004 at 06:32:14PM -0700, Pete Zaitcev wrote:
> On Fri, 30 Apr 2004 16:34:48 -0500
> <[EMAIL PROTECTED]> wrote:
>
> > Here's the patch (for 2.4) if you're curious.
>
> Do you want me to include all relevant transport types, or you want
> to do it yourself?
Or the lock could be mo
a first version of a USB HID driver for eGalax touchscreens called Touchkit.
this touchscreen is found for example in Xenarc 700TSV monitor.
comments?
thanks
-daniel
--- 1.18/drivers/usb/input/Makefile Mon Mar 22 15:32:15 2004
+++ edited/drivers/usb/input/Makefile Sun Apr 25 16:18:58 2004
> + if (usb_submit_urb(touchkit->irq, GFP_ATOMIC))
> + return -EIO;
must also decrease the counter
Regards
Oliver
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ev
Am Freitag, 30. April 2004 00:11 schrieb David Brownell:
> + /* see 7.1.7.6 */
> + status = set_port_feature(hubdev, port, USB_PORT_FEAT_SUSPEND);
> + if (status)
> + dev_dbg(&hub->intf->dev,
> + "can't suspend port %d, status %d\n",
> +
On Sat, May 01, Greg KH wrote:
> On Sat, May 01, 2004 at 04:53:38PM +0200, Juergen Stuber wrote:
> > The following message is a courtesy copy of an article
> > that has been posted to gmane.linux.usb.devel as well.
> >
> > Please apply.
>
> Heh, it's already in my tree, and in the version on li
On Sat, 1 May 2004, Oliver Neukum wrote:
> Am Samstag, 1. Mai 2004 17:15 schrieb Alan Stern:
> > Instead they can be used by the hub driver to ensure that only one thing
> > happens on a hub at any time. When suspending or resetting a port, the
> > rule should be to acquire the serialize lock on
Now I see what you meant. Yes, that's messy -- driver model core doesn't
seem to have a way for bus-specific additional constraints to be applied
when it does probe() ... unless you count the bus match() method, which
could grab the lock but then there'd be no way to release it.
Yeech. I don't k
Oliver Neukum wrote:
Am Freitag, 30. April 2004 00:11 schrieb David Brownell:
+ /* see 7.1.7.6 */
+ status = set_port_feature(hubdev, port, USB_PORT_FEAT_SUSPEND);
+ if (status)
+ dev_dbg(&hub->intf->dev,
+ "can't suspend port %d, status %d\n",
On Sat, 1 May 2004, David Brownell wrote:
> What'd be the downside of not fixing it in that way ... what kinds of
> code would break if we just said dev->serialize might not always be
> held during probe() or remove()? I suspect not much...
Pretty much anything that depends on dev->serialize at
Alan Stern wrote:
I like the way this idea is leading. We can have a global topology
semaphore protect all the children[] arrays and also the driver-model
lists, since the two data structure views should always be consistent.
Then the ->serialize locks won't be needed for tree traversal.
Which
Alan Stern wrote:
It's a tricky problem, and I haven't figured out all the ramifications
yet...
Me either. That means we haven't hit on the
right simplifications yet ... :)
That's not what I had in mind. Suppose we want to suspend hub B. Then
first we have to go through all of B's children a
Alan Stern wrote:
On Sat, 1 May 2004, David Brownell wrote:
What'd be the downside of not fixing it in that way ... what kinds of
code would break if we just said dev->serialize might not always be
held during probe() or remove()? I suspect not much...
Pretty much anything that depends on dev-
And change __inline__ to inline and get rid of an unused function
while at it.
devio.c | 35 +--
1 files changed, 5 insertions(+), 30 deletions(-)
diff -Nru a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
--- a/drivers/usb/core/devio.c Fri Apr 30 23:36:2
On Sun, May 02, 2004 at 12:15:25AM +0200, Duncan Sands wrote:
> And change __inline__ to inline and get rid of an unused function
> while at it.
Applied, thanks.
greg k-h
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the h
On Fri, Apr 30, 2004 at 11:04:24AM +0200, Duncan Sands wrote:
> On Tuesday 27 April 2004 10:58, Oliver Neukum wrote:
> > Am Dienstag, 27. April 2004 00:14 schrieb Greg KH:
> > > On Mon, Apr 26, 2004 at 04:05:17PM +0200, Duncan Sands wrote:
> > > > diff -Nru a/drivers/usb/core/devio.c b/drivers/usb/
On Thu, Apr 29, 2004 at 05:25:01PM -0700, David Brownell wrote:
> Here's what's in my tree to make dummy_hcd do suspend and
> wakeup correctly ... that is, making its emulated root hub
> and gadget work more like real ones.
>
> It's easier to do this for fake hardware than the real stuff.
> But re
On Sat, 1 May 2004, David Brownell wrote:
> Alan Stern wrote:
>
> > That's not what I had in mind. Suppose we want to suspend hub B. Then
> > first we have to go through all of B's children and suspend them. While
> > that's happening, another child could be connected to B. It would then be
On Sat, 1 May 2004, David Brownell wrote:
> Alan Stern wrote:
>
> > I like the way this idea is leading. We can have a global topology
> > semaphore protect all the children[] arrays and also the driver-model
> > lists, since the two data structure views should always be consistent.
> > Then t
Am Samstag, 1. Mai 2004 22:32 schrieb David Brownell:
> Thanks for the feedback. I need remote wakeup to work, so I
> suspect I'll be filing rough spots off this for a while.
>
> (Like adding new HCD operations to suspend/resume root hubs,
> resolving some of the FIXMEs ... :)
Another thing I did
On Sat, 1 May 2004, David Brownell wrote:
> >>What'd be the downside of not fixing it in that way ... what kinds of
> >>code would break if we just said dev->serialize might not always be
> >>held during probe() or remove()? I suspect not much...
> >
> >
> > Pretty much anything that depends on
31 matches
Mail list logo
