Signed-off-by: Phil Dibowitz <[EMAIL PROTECTED]>
Original Message
Subject: [PATCH] unusual_devs update for Sony P990i phone
Date: Wed, 31 Jan 2007 10:57:55 -0500 (EST)
From: Alan Stern <[EMAIL PROTECTED]>
To: Greg KH <[EMAIL PROTECTED]>, Phil Dibowitz <[EMAIL PROTECTED]>
CC: Soer
Alan Stern rowland.harvard.edu> writes:
> In fact, it's possible that these problems are caused by bad USB cable
> connections. They certainly could result in intermittent disconnects.
We tried two factory new cables that came with the two Palm 700p devices.
Also, once I modified the kernel (as
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> > timer whenever there is any activity, and when the timer expires you know
> > the device has been idle long enough that you should suspend it. That's
> > exactly how the autosuspend infrastructure works.
>
> This would call mod_timer() for every comp
Am Mittwoch, 31. Januar 2007 20:35 schrieb Alan Stern:
> On Wed, 31 Jan 2007, Oliver Neukum wrote:
>
> > > > + if (sdkp->capacity % 63 || sdkp->capacity % 255)
> > > > + --sdkp->capacity;
> > >
> > > This is a strange computation. You avoid decrementing the ca
Am Mittwoch, 31. Januar 2007 20:25 schrieb Alan Stern:
> > How do I find out whether the device is idle?
> > The mouse is not idle if it has been moved (or buttons clicked)
> > To find out whether it has been moved the device must not be suspended.
> > At which point in time then should I check? Ar
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> > > + if (sdkp->capacity % 63 || sdkp->capacity % 255)
> > > + --sdkp->capacity;
> >
> > This is a strange computation. You avoid decrementing the capacity iff it
> > is already divisible both by 63 and by 255. Maybe you really
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> > > Furthermore that work should be queued only if pm_usage_cnt==0,
> > > which cannot be allowed if the device isn't idle.
> >
> > Isn't that what you want? Surely you aren't trying to start an
> > autosuspend timer while the device is busy?
>
> How
Hi,
Purchase your medication from our site because it costs less.
http://www.vodrx*.com - Remove "*" to make the link working!
--
their rucksacks onto their backs and walked out without a word to her.
Well, have a lovely time, said Mrs. Weasley, and behave yourselves,
she called after the twi
Am Mittwoch, 31. Januar 2007 17:44 schrieb Pavel Machek:
> You should have /proc/acpi/battery/*/state ; it shows current power
> consumption.
Yes, that works. Cool :-)
Regards
Oliver
-
Take Surveys. E
Am Mittwoch, 31. Januar 2007 17:55 schrieb Jiri Kosina:
> A first example that comes to mind - suppose that you have two keyboards,
> at least one of them being HID. Now when the timer expires, the HID
> keyboard will be suspended. Then when you hit a capslock/numlock/...
> (basically anything c
Am Mittwoch, 31. Januar 2007 18:07 schrieb Alan Stern:
> On Wed, 31 Jan 2007, Oliver Neukum wrote:
>
> > Am Mittwoch, 31. Januar 2007 17:11 schrieb Alan Stern:
> >
> > > This looks more complicated than it should be. In particular, the
> > > addition of a new "idle" timer should not be needed.
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> Am Mittwoch, 31. Januar 2007 17:11 schrieb Alan Stern:
>
> > This looks more complicated than it should be. In particular, the
> > addition of a new "idle" timer should not be needed.
> >
> > We already have an autosuspend timer: the one embedded in
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> In fact it should do this to all devices which are HID, claimed by the
> input layer and support remote wakeup.
>From a quick look, in addition to Alan's comments, it seems to me that you
don't handle a case in which the hid driver decides to send an
On Tue, 30 Jan 2007, Dominik Brodowski wrote:
> > There may not be anything we can do about a rogue BIOS, other than to
> > avoid suspending the controller at all.
> >
> > Just to make sure, try this: In ehci-hub.c, near the end of
> > ehci_bus_suspend(), print out the value returned by ehci_h
Hi!
> this preliminary patch should suspend your mouse, if it supports remote
> wakeup. In fact it should do this to all devices which are HID, claimed by
> the input layer and support remote wakeup.
>
> It works for me with my mouse. I've tested letting it autosuspend and
> resume. It survives g
Am Mittwoch, 31. Januar 2007 17:22 schrieb Alan Stern:
> On Wed, 31 Jan 2007, Oliver Neukum wrote:
> If some other device ends up needing this in the future, what makes you
> think the heuristic you have chosen will be appropriate?
I've checked my disks and asked for counterexamples.
If you have
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> Hi,
>
> could you please test this with your storage device. It tries to implement
> a heuristics which will work with both versions of the firmware.
>
> Regards
> Oliver
If some other device ends up needing this in the future, wha
Am Mittwoch, 31. Januar 2007 17:11 schrieb Alan Stern:
> This looks more complicated than it should be. In particular, the
> addition of a new "idle" timer should not be needed.
>
> We already have an autosuspend timer: the one embedded in the autosuspend
> delayed_work struct inside struct usb
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> Hi,
>
> this preliminary patch should suspend your mouse, if it supports remote
> wakeup. In fact it should do this to all devices which are HID, claimed by
> the input layer and support remote wakeup.
>
> It works for me with my mouse. I've tested let
Hi,
this preliminary patch should suspend your mouse, if it supports remote
wakeup. In fact it should do this to all devices which are HID, claimed by
the input layer and support remote wakeup.
It works for me with my mouse. I've tested letting it autosuspend and
resume. It survives going to a te
Am Mittwoch, 31. Januar 2007 16:47 schrieb Jiri Kosina:
> On Wed, 31 Jan 2007, Oliver Neukum wrote:
>
> > this preliminary patch should suspend your mouse, if it supports remote
> > wakeup. In fact it should do this to all devices which are HID, claimed
> > by the input layer and support remote
Hi,
could you please test this with your storage device. It tries to implement
a heuristics which will work with both versions of the firmware.
Regards
Oliver
--- a/drivers/usb/storage/unusual_devs.h2007-01-31 14:48:08.0
+0100
+++ b/drivers/usb/stora
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> this preliminary patch should suspend your mouse, if it supports remote
> wakeup. In fact it should do this to all devices which are HID, claimed
> by the input layer and support remote wakeup.
Thanks for the patch; you probably made some trivial mist
Am Mittwoch, 31. Januar 2007 15:12 schrieb Jiri Kosina:
> On Wed, 31 Jan 2007, Oliver Neukum wrote:
>
> > Yes, it is broken. Hiddev allows multiple openings of the same device.
> > You cannot just mix IO requests of different readers. You are allowing a
> > second process to delay IO completion
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> Yes, it is broken. Hiddev allows multiple openings of the same device.
> You cannot just mix IO requests of different readers. You are allowing a
> second process to delay IO completion of the first process.
It is questionable whether this is worth fi
Am Mittwoch, 31. Januar 2007 14:47 schrieb Jiri Kosina:
> On Wed, 31 Jan 2007, Oliver Neukum wrote:
>
> > > coming from the URB submission which happened later - either the flags
> > > are cleared, or wake_up() will eventually happen (you are right that
> > > it might possibly be wake_up() corre
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> > coming from the URB submission which happened later - either the flags
> > are cleared, or wake_up() will eventually happen (you are right that
> > it might possibly be wake_up() corresponding to submission of URB
> > submitted later, but does that
Am Mittwoch, 31. Januar 2007 14:18 schrieb Jiri Kosina:
> > > with both the flags unset (if a timeout doesn't happen sooner, which is
> > > OK). If this "final" wake_up() is called before the usbhid_wait_io() is
> > > called, this is also OK, because then the condition will evaluate to true
> >
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> > Every URB submission (both ctrl and out) is paired with wake_up() in its
> > completion handler. Before the wake_up() is issued, the HID_CTRL_RUNNING
> > or HID_OUT_RUNNING flag is cleared. As this is a "1:1 pairing", it's
> > guaranteed that there
Hi,
this preliminary patch should suspend your mouse, if it supports remote
wakeup. In fact it should do this to all devices which are HID, claimed by
the input layer and support remote wakeup.
It works for me with my mouse. I've tested letting it autosuspend and
resume. It survives going to a te
On Wed, 2007-01-31 at 19:18 +0800, Dave Liu wrote:
> > In asix.c, there are three register read/write functions:
> asix_read_cmd,
> > asix_write_cmd, and asix_write_cmd_async. With a recent patch,
> > asix_write_cmd_async() was tweaked to wrap the params to the wValue,
> > wIndex and wLength for t
On Tue, 2007-01-30 at 17:38 -0800, Greg KH wrote:
> On Tue, Jan 30, 2007 at 06:33:43PM -0500, Rick Scott wrote:
> > On Tue, 2007-01-30 at 05:05 -0500, Chris Frey wrote:
> > > On Mon, Jan 29, 2007 at 05:21:39PM -0800, Greg KH wrote:
> > > > Also, would it make sense to provide a userspace "pipe" to
Am Mittwoch, 31. Januar 2007 12:37 schrieb Jiri Kosina:
> On Wed, 31 Jan 2007, Oliver Neukum wrote:
>
> > in hiddev_ioctl() IO is submitted with usbhid_submit_report() and waited
> > for with usbhid_wait_io(), which uses the following condition:
> > if (!wait_event_timeout(hid->wait, (!test_b
On Tue, 2007-01-30 at 19:24 -0500, Chris Frey wrote:
> On Tue, Jan 30, 2007 at 06:33:43PM -0500, Rick Scott wrote:
> > In the end, I would like to be able to
> > "cat > to retrieve my pin, similarly to set new entries. In other
> > words, treat the various databases like a filesystem that you coul
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> in hiddev_ioctl() IO is submitted with usbhid_submit_report() and waited
> for with usbhid_wait_io(), which uses the following condition:
> if (!wait_event_timeout(hid->wait, (!test_bit(HID_CTRL_RUNNING,
> &usbhid->iofl) &&
>
On Wed, 2007-01-31 at 00:05 -0500, David Hollis wrote:
> All,
> I'm trying to get any/all endian issues worked out of the asix driver so
> I can be certain that it works on any platform but due to lack of access
> to any big-endian hardware and lack of expertise with endian-issues, I
> need some he
Hello,
I did the IP forwarding test for USB->Ethernet 1 direction as below.
USB--->TSEC1 IP forwarding:
PowerPC LINKSYS USB200M Generator/Capturer
+-+ +-+ +-+
|USB port |<| AX88172+RTL8201 |<-|PORT1
Am Mittwoch, 31. Januar 2007 11:36 schrieb Jiri Kosina:
> On Wed, 31 Jan 2007, Oliver Neukum wrote:
>
> > > > currently hid-core's suspend() method only kills the input URB and
> > > > leaves the output URB alone. I am afraid this is incorrect. I've
> > > > done a patch, but I am looking for a s
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> > > currently hid-core's suspend() method only kills the input URB and
> > > leaves the output URB alone. I am afraid this is incorrect. I've
> > > done a patch, but I am looking for a solution regarding resumption.
> > > It seems to me that it might
Am Montag, 29. Januar 2007 14:59 schrieb Jiri Kosina:
> On Mon, 29 Jan 2007, Oliver Neukum wrote:
>
> > currently hid-core's suspend() method only kills the input URB and
> > leaves the output URB alone. I am afraid this is incorrect. I've done a
> > patch, but I am looking for a solution regard
Hi,
in hiddev_ioctl() IO is submitted with usbhid_submit_report() and
waited for with usbhid_wait_io(), which uses the following condition:
if (!wait_event_timeout(hid->wait, (!test_bit(HID_CTRL_RUNNING,
&usbhid->iofl) &&
!test_bit(HID_OUT_RUNNING,
On Tue, 2007-01-30 at 13:08 -0500, Alan Stern wrote:
> On Sat, 27 Jan 2007, Soeren Sonnenburg wrote:
[P990 mass storage trouble]
> > Now I am clueless what could have gone wrong (as I *think* this was all
> > working at some point at least before firmware updates) and what the
> > difference betwe
42 matches
Mail list logo
