Am Donnerstag, 17. Mai 2007 20:39 schrieb Pete Zaitcev:
I think we should remove those local_irq_save's, and leave just the
guarantee that it won't be re-entered (currently such a guarantee
is inherited from the Linux's interrupt handling, and we'll only
need to make it explicit if any HCDs
Soeren Sonnenburg napsal(a):
a regression (well I switched to slub) happens on boot...
...
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt :00:1d.3[D] - GSI 16 (level, low) - IRQ 16
PCI: Setting latency timer of device :00:1d.3 to 64
uhci_hcd
On Mon, 21 May 2007, Oliver Neukum wrote:
- what to do with devices with force feedback? (or PID devices in
general). The effect could have up to infinite duration (until it is
stopped by appropriate stop method), and we definitely absolutely
must not autosuspend a device that is
Dan Kruchinin napsal(a):
Hi.
There is a BUG message from SLUB during boot process:
--
May 21 05:39:10 midgard kernel: [ 31.177484] BUG: at
include/linux/slub_def.h:77 kmalloc_index()
May 21 05:39:10 midgard kernel: [ 31.178355] [c01062ca]
show_trace_log_lvl+0x1a/0x30
May 21 05:39:10
On Mon, 2007-05-21 at 10:09 +0200, Jiri Slaby wrote:
Soeren Sonnenburg napsal(a):
a regression (well I switched to slub) happens on boot...
BUG: at include/linux/slub_def.h:77 kmalloc_index()
[c0176448] get_slab+0x1c8/0x250
[...]
Could you try this patch:
I suddenly can no longer s2ram with 2.6.22-rc2, as this seems caused by
usb_hcd_pci_suspend I am CC'ing linux usb-devel.
I am attaching a dmesg and lspci.
Soeren
--
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.
Linux
Hello all,
is there a way to use libusb to talk directly to hcd drivers?
what I'm wondering to do is to develop an application similar to the
USBHSET tool from usb.org in order to test embedded host devices.
I think that keep adding lots of sysfs interfaces is not the better
way to do it since
Am Mittwoch, 16. Mai 2007 20:43 schrieb Hans Petter Selasky:
The lock that you are holding during submission is the same lock that is
protecting the callback. Actually you can end up calling the
__usbd_callback() prematurely in my new USB stack, but that is handled just
fine, through some
Am Mittwoch, 16. Mai 2007 16:30 schrieb Alan Stern:
On Wed, 16 May 2007, Oliver Neukum wrote:
Now consider cases where the driver does perform an identity check.
Combine this with a previous remark you made: Devices with the
reset_resume quirk are quite rare. Hence such drivers won't stand
Am Mittwoch, 16. Mai 2007 17:20 schrieb Alan Stern:
@@ -592,8 +604,21 @@ static int hid_get_class_descriptor(stru
int usbhid_open(struct hid_device *hid)
{
struct usbhid_device *usbhid = hid-driver_data;
+ int res;
- hid-open++;
+ mutex_lock(hid_open_mut);
+
Hi Oliver,
what about something like
int hidinput_has_ff(struct hid_device *hid)
{
struct hid_input *hidinput;
list_for_each_entry(hidinput, hid-inputs, list)
if (test_bit(EV_FF, hidinput-input-evbit))
Am Mittwoch, 16. Mai 2007 16:30 schrieb Alan Stern:
In other words, there's never any real reason for powerloss_resume and
reset_resume to do different things. So there's no reason to have two
separate methods.
BTW, with these changes it seems to me that everything is in place to
do
Am Mittwoch, 16. Mai 2007 15:07 schrieb Pete Zaitcev:
On Wed, 16 May 2007 07:37:04 +0200, Oliver Neukum [EMAIL PROTECTED] wrote:
+ /* Task context for reporting idleness */
+ struct work_struct idle_work;
This does not seem to be used anywhere.
Yes. Killed.
Thanks
On Sunday, May 20, 2007, Pete Zaitcev wrote:
On Fri, 18 May 2007 14:23:43 -0700, Mark Miesfeld [EMAIL PROTECTED] wrote:
There is a published errata for the PPC440EPX, USBH_23: EHCI and OHCI
Linux module contention.
So, you're set for the classic (and unsoluble) inter-module problem,
On Monday 21 May 2007, Felipe Balbi wrote:
Hello all,
is there a way to use libusb to talk directly to hcd drivers?
what I'm wondering to do is to develop an application similar to the
USBHSET tool from usb.org in order to test embedded host devices.
I think that keep adding lots of
On Monday 21 May 2007 13:37, Oliver Neukum wrote:
Am Mittwoch, 16. Mai 2007 20:43 schrieb Hans Petter Selasky:
The lock that you are holding during submission is the same lock that is
protecting the callback. Actually you can end up calling the
__usbd_callback() prematurely in my new USB
On Sunday, May 20, 2007, Pete Zaitcev wrote:
On Sun, 20 May 2007 21:55:58 -0700, David Brownell
[EMAIL PROTECTED] wrote:
If you're going to turn on the OHCI hardware, do it the
normal way; don't bypass its driver.
How exactly do you suggest we do this?
The problem is not quite
On Sunday, May 20, 2007, David Brownell
On Sunday 20 May 2007, Pete Zaitcev wrote:
On Fri, 18 May 2007 14:23:43 -0700, Mark Miesfeld [EMAIL PROTECTED]
wrote:
And this is the part which implements poking:
+++ b/drivers/usb/host/ohci-ppc-soc.c
@@ -20,6 +20,37 @@ #include
On Mon, 21 May 2007, Oliver Neukum wrote:
I don't like the way you combined the error handling in usb-skeleton
with the anchor stuff. Better to keep the two things in separate
patches.
Problems with the packaging or the code?
Just the packaging.
Alan Stern
Hi Soeren,
On 21/05/07, Soeren Sonnenburg [EMAIL PROTECTED] wrote:
I suddenly can no longer s2ram with 2.6.22-rc2, as this seems caused by
usb_hcd_pci_suspend I am CC'ing linux usb-devel.
I think, that it's a known bug
http://bugzilla.kernel.org/show_bug.cgi?id=8498
Please try this patch
On Mon, 21 May 2007, Oliver Neukum wrote:
reset_resume will happen only because of the quirk. But when it
happens during an autoresume, we cannot unbind the driver because we
don't own the device lock. So what do you want to do then?
This would need a separate thread.
On Mon, 21 May 2007, Oliver Neukum wrote:
Am Mittwoch, 16. Mai 2007 17:20 schrieb Alan Stern:
@@ -592,8 +604,21 @@ static int hid_get_class_descriptor(stru
int usbhid_open(struct hid_device *hid)
{
struct usbhid_device *usbhid = hid-driver_data;
+ int res;
-
Am Montag, 21. Mai 2007 17:15 schrieb Alan Stern:
On Mon, 21 May 2007, Oliver Neukum wrote:
How to avoid it? If the original driver fails, I see no alternative but to
yield to other drivers and usbfs.
Well, you don't really want to yield to other drivers and usbfs.
What else do you do
Am Montag, 21. Mai 2007 17:32 schrieb Alan Stern:
On Mon, 21 May 2007, Oliver Neukum wrote:
Am Mittwoch, 16. Mai 2007 17:20 schrieb Alan Stern:
Don't you need to do usb_autopm_get_interface() before hid_start_in()?
hid_start_in() takes the spinlock and checks for a suspension. In the
Am Montag, 21. Mai 2007 17:49 schrieb Oliver Neukum:
But this code runs whenever a process opens the device file. If the
device is suspended at that time, there might not be a remote wakeup
request pending. So you'd run into trouble unless you did an
autoresume before calling
On Mon, 21 May 2007, Oliver Neukum wrote:
Am Montag, 21. Mai 2007 17:15 schrieb Alan Stern:
On Mon, 21 May 2007, Oliver Neukum wrote:
How to avoid it? If the original driver fails, I see no alternative but to
yield to other drivers and usbfs.
Well, you don't really want to yield
On Mon, 21 May 2007, Oliver Neukum wrote:
I guess it's just a theoretical problem. The whole point of the
last_busy field is to prevent autosuspend too soon after any I/O. So
if an URB does complete and nevertheless the device is suspended a few
milliseconds later, then last_busy hasn't
Hello linux-usb-devel@lists.sourceforge.net,
We have received your request to join the aahome
group hosted by Yahoo! Groups, a free, easy-to-use community service.
This request will expire in 7 days.
TO BECOME A MEMBER OF THE GROUP:
1) Go to the Yahoo! Groups site by clicking on this link:
On Monday 21 May 2007, you wrote:
Hi David
Can you check the following patch that may be needed in hub.c
Prevent un-necessary enumeration of 3 times when device is not there.
Signed-off-by: Vikram Pandita [EMAIL PROTECTED]
Looks sane to me, but this would be better sent to
the linux-usb
On Mon, 21 May 2007, David Brownell wrote:
On Monday 21 May 2007, you wrote:
Hi David
Can you check the following patch that may be needed in hub.c
Prevent un-necessary enumeration of 3 times when device is not there.
Signed-off-by: Vikram Pandita [EMAIL PROTECTED]
Looks sane to
Dave:
Do we really need to call finish_port_resume() for root hubs? It
doesn't do much for them except to set the device state, which could
just as easily be done in hcd_bus_resume().
The same question applies to root hubs and __usb_port_suspend().
In fact, it would be very easy to change
Dave:
The situation with regard to start_frame is a mess. Although the name
and the documentation refer to frame numbers, for high speed devices
the value stored there is a microframe number instead.
Clearly anyone who's interested in the value will want to know the full
microframe number. But
On Monday 21 May 2007, Alan Stern wrote:
Dave:
The situation with regard to start_frame is a mess. Although the name
and the documentation refer to frame numbers, for high speed devices
the value stored there is a microframe number instead.
Clearly anyone who's interested in the value
Clearly anyone who's interested in the value will want to know the full
microframe number. But on the other hand, the value returned from
ehci_get_frame() actually _is_ a frame number, so there's no way for
drivers to learn the current microframe. Thus we have several related
problems:
On Mon, 2007-05-21 at 10:51 -0400, Alan Stern wrote:
On Sat, 19 May 2007, Greg KH wrote:
It turns out that the patch I originally wrote to fix this is in
conflict with one of Raphael's patches (make freezeable workqueues
singlethread) already added to 2.6.22-rc2. So here's an updated
On 5/21/07, Alan Stern [EMAIL PROTECTED] wrote:
Andrey, Soeren, and Avuton: Please try this patch with 2.6.22-rc2 or
later and see if it fixes your problems.
It does, I already synced the -rc1 patch that was at the bug link for myself.
Thanks
--
avuton
--
Anyone who quotes me in their sig is
-stable review patch. If anyone has any objections, please let us know.
-
From: Tejun Heo [EMAIL PROTECTED]
Currently, devt_attr for the dev file is freed immediately on device
removal, but if the dev sysfs file is open when a device is removed,
sysfs will access its
On Sat, 19 May 2007, Greg KH wrote:
On Sat, May 19, 2007 at 11:16:44AM -0400, Alan Stern wrote:
Greg:
The patch in $SUBJECT (already in your development tree) fixes a problem
with system suspend in 2.6.22-rc1, as described in
http://bugzilla.kernel.org/show_bug.cgi?id=8498
Am Montag, 21. Mai 2007 18:04 schrieb Alan Stern:
it. If the driver was working okay with the device before then it
should be kept, not replaced by some other driver which might not work
If the method fails, we know that the previous driver is not working.
No. We are discussing
Am Mittwoch, 16. Mai 2007 19:38 schrieb Alan Stern:
It doesn't save code. You need to check for the memory when you
allocate it, no matter when that is done.
Yes, but it is a difference doing it once at attach or doing it every time
you
start a transfer.
Above you said it
On Mon, 21 May 2007, David Brownell wrote:
On Monday 21 May 2007, Alan Stern wrote:
Dave:
The situation with regard to start_frame is a mess. Although the name
and the documentation refer to frame numbers, for high speed devices
the value stored there is a microframe number instead.
Am Mittwoch, 16. Mai 2007 16:41 schrieb David Brownell:
in that when you have
pre-allocated all buffers and all USB host controller descriptors, you will
never get in the situation of not being able to allocate transfer
descriptors
on the fly, like done on Linux.
That's not a
Am Mittwoch, 16. Mai 2007 19:33 schrieb Alan Stern:
All devices need to allocate some memory, even if they are not used. That
is
just the way it is. If you want to save memory, then USB has the advantage
that you can unplug the device and save resources.
Of course all devices need
On Mon, 21 May 2007, Oliver Neukum wrote:
No. We are discussing what to do when the method doesn't exist, not
what to do when it fails. In this situation we must assume the driver
was working fine and it simply can't cope with a device reset.
Ok, this narrowly put, my answer is:
-
Am Montag, 21.
Mai 2007 23:16 schrieben Sie:
On Mon, 21 May 2007, Oliver Neukum wrote:
No. We are discussing what to do when the method doesn't exist, not
what to do when it fails. In this situation we must assume the driver
was working fine and it simply can't cope with a device
On Monday 21 May 2007, Oliver Neukum wrote:
Am Mittwoch, 16. Mai 2007 16:41 schrieb David Brownell:
in that when you have
pre-allocated all buffers and all USB host controller descriptors, you
will
never get in the situation of not being able to allocate transfer
descriptors
On Mon, 21 May 2007, Oliver Neukum wrote:
Am Montag, 21.
Mai 2007 23:16 schrieben Sie:
On Mon, 21 May 2007, Oliver Neukum wrote:
No. We are discussing what to do when the method doesn't exist, not
what to do when it fails. In this situation we must assume the driver
was
Here is the patch to fix it.
From: Li Yang [EMAIL PROTECTED]
Date: Mon, 21 May 2007 13:08:57 +0800
Subject: [PATCH] ehci-fsl: fix cache coherency problem on system with large
memory
The patch fix bug http://bugzilla.kernel.org/show_bug.cgi?id=7482.
It sets USB snooping on 4G space for PowerPC
Looks like the error path had a copy-paste error. The normal exit path
uses correct URB already.
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -1004,7 +1004,7 @@ abort:
usblp-writebuf,
From: Alan Stern [mailto:[EMAIL PROTECTED]
On Mon, 21 May 2007, David Brownell wrote:
On Monday 21 May 2007, Vikram Pandita wrote:
---
diff -purN -X ./dontdiff a/drivers/usb/core/hub.c
b/drivers/usb/core/hub.c
--- a/drivers/usb/core/hub.c2007-05-13 14:24:43.0 +0530
+++
50 matches
Mail list logo
