Alan Stern wrote:
Sure. uhci_irq() in drivers/usb/host/uhci-hcd.c receives the interrupt
and sets uhci->resume_detect to 1. Then hc_state_transitions() in the
same file sees uhci->resume_detect and calls wakeup_hc() to restart the
controller.
The first thing
to prove is that the interrupt never
> > The new bco msc (binary code only, mass storage committee) compliance
> > test should check for this violation. I expect it won't unless someone
> > volunteers to help it (e.g. by making pass thru to USB from the Linux
> > command line easy).
>
> Use libusb. Remember to unload usb-storage fi
On Fri, Apr 23, 2004 at 09:17:26AM +1000, Herbert Xu wrote:
> Hi:
>
> I've received the following report which indicates that the Sony Clie needs
> the US_FL_FIX_INQUIRY flag set.
>
> http://bugs.debian.org/243650
Applied, thanks.
greg k-h
-
On Tue, May 04, 2004 at 05:25:39PM -0400, Alan Stern wrote:
> On Tue, 4 May 2004, Greg KH wrote:
>
> > Send all pending patches that you have generated for this to me. I'll
> > apply them to the tree.
>
> This is the only one. Only one aspect of it is notable: The CPiA USB
> driver calls usb_dr
On Mon, May 03, 2004 at 03:30:34PM -0400, Alan Stern wrote:
> Greg:
>
> This patch imports the changes that David Brownell has made to the
> device-reset functions in his gadget-2.6 tree. Once these ongoing
> troubling questions about locking are settled, I'll add support for the
> "descriptors c
On Mon, May 03, 2004 at 03:32:38PM -0400, Alan Stern wrote:
> Greg:
>
> This patch allocates a temporary array from the heap instead of from the
> kernel's stack in usb_set_configuration(). It also updates a few
> comments. Please apply.
Applied, thanks.
greg k-h
---
On Mon, May 03, 2004 at 09:24:46PM +0200, Daniel Ritz wrote:
> hi
>
> this is the second version of the patch to add support for eGalax Touchkit USB
> touchscreen. changes since last patch:
> - fixed the bug in open, found by oliver neukum
> - renamed driver from touchkit.c to touchkitusb.c (since
On Mon, May 03, 2004 at 05:35:59PM +0200, [EMAIL PROTECTED] wrote:
> Hi,
> below is a trivial patch which fixes the PXA gadget define
> in drivers/linux/usb/gadget/gadget_chips.h
>
> Everywhere CONFIG_USB_GADGET_PXA2XX is used, except in that file, which
> bites obviously ...
>
> The patch is aga
On Tue, May 04, 2004 at 10:05:45AM -0400, Alan Stern wrote:
> On 4 May 2004, Rajesh Kumble Nayak wrote:
>
> > The Above patch work fine for Sony Hc-85
> > I shall post the dmesg entry soon.
> >
> > With many thanks
> > Rajesh
>
> Greg and Pete, here's the patch. It's possible that this entry co
On Tue, Apr 27, 2004 at 07:32:58PM -0700, John Tyner wrote:
> Attached is a patch that removes the vicam firmware from the kernel
> source and moves it out to userspace to be loaded by the hotplug system.
>
> It works for me. More testing would be ideal, but I think it's ready to
> be applied.
>
On Wed, Apr 14, 2004 at 08:22:17PM +1000, Herbert Xu wrote:
> Hi:
>
> The current code is applying the maxusage limit to GUSAGE/SUSAGE. This
> is incorrect as the number of values is stored in field->report_count,
> not field->maxusage. The USB phone from www.virbiage.com is one device
> where r
On Mon, May 03, 2004 at 05:40:27PM +0200, [EMAIL PROTECTED] wrote:
> Hi,
> g_serial.ko can't be load as module because "debug" is only
> defined if G_SERIAL_DEBUG is defined, but "debug" is referenced
> in MODULE_PARM().
>
> The patch below against 2.6.6-rc3 should fix that.
Applied, thanks.
gr
Wouldn't a plain old atomic "BUSY" bitflag work better? If it's
set, usbcore would reject urbs with -EAGAIN ... from all
contexts, including the many that can't acquire semaphores!
I thought (and I might be confused with other OSes here) that there was a
way to attempt to acquire a semaphore fro
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
> My guess is that if people actually tried,
> they could find this bug on many other
> devices. usb-storage makes it easy because
> the time window during which the bug can be
> triggered (ie. from CBW to CSW, which includes
> the media-access time) is kinda large.
Indeed, media-access may incl
The original message was received at Wed, 5 May 2004 22:12:13 +0200
from adsl-64-171-193-148.dsl.lsan03.pacbell.net [64.171.193.148]
- The following addresses had permanent fatal errors -
<[EMAIL PROTECTED]>
(reason: 550 Unacceptable content)
- Transcript of session follows
> > Usb-storage in particular needs this,
> > because a number of storage devices can't
> > handle ordinary USB requests (like
> > GET_DESCRIPTOR) while processing a SCSI
> > command. It's not clear whether or not this
> > is in violation of the USB spec, but that's
> > the way they are. Hotplug
This disconnect() issue is a parallel of the open()/disconnect() issue.
In both cases, there's state that must linger after disconnect() returns,
and be cleaned up later. ...
Leaving that aside for the moment, you're arguing that usb_reset_device()
should be allowed to block until after the d
On Wed, May 05, 2004 at 01:02:59PM -0600, Pat LaVarre wrote:
> > > Usb-storage in particular needs this,
> > > because a number of storage devices can't
> > > handle ordinary USB requests (like
> > > GET_DESCRIPTOR) while processing a SCSI
> > > command. It's not clear whether or not this
> > > is
On Wed, May 05, 2004 at 11:36:00AM -0700, David Brownell wrote:
> Matthew Dharm wrote:
> >On Wed, May 05, 2004 at 12:23:35PM -0400, Alan Stern wrote:
>
> >>I hereby invite comments from other USB developers...
> >>
> >>We are discussing the possibility of adding a semaphore to struct
> >>usb_devic
On Wed, 5 May 2004, David Brownell wrote:
> Alan Stern wrote:
> > I'm about ready to give up on device reset during probe.
>
> Preventing it would need a per-interface state flag, FWIW;
> easily set by usbcore during probe(). Somewhat parallel to
> the flag I suggested be held during SET_CONFIGU
Alan Stern wrote:
You're saying that usb_reset_device() doesn't really need to lock the hub?
Doesn't this contradict what you wrote earlier:
If various things changed, it wouldn't need to. And the
last suspend patch I posted did actually change one of them:
to use the top-down (from the root)
Matthew Dharm wrote:
On Wed, May 05, 2004 at 12:23:35PM -0400, Alan Stern wrote:
I hereby invite comments from other USB developers...
We are discussing the possibility of adding a semaphore to struct
usb_device. This semaphore would be acquired by usbfs (and maybe other
parts of usbcore too) be
On Wed, 5 May 2004, David Brownell wrote:
> >>This disconnect() issue is a parallel of the open()/disconnect() issue.
> >>In both cases, there's state that must linger after disconnect() returns,
> >>and be cleaned up later. In one case it's what close() accesses, and it's
> >>associated with a u
I'm only going to respond to a few points here, because this discussion is
getting a little out of hand...
On Wed, 5 May 2004, David Brownell wrote:
> > The big question is how to make device resets work. It's pretty clear
> > that usb_reset_device(udev) needs to lock both the parent hub and u
Alan Stern wrote:
I'm about ready to give up on device reset during probe.
Preventing it would need a per-interface state flag, FWIW;
easily set by usbcore during probe(). Somewhat parallel to
the flag I suggested be held during SET_CONFIGURATION...
(That is, there are kinds of locks that don't in
On Wed, May 05, 2004 at 12:23:35PM -0400, Alan Stern wrote:
> On Wed, 5 May 2004, Matthew Dharm wrote:
>
> > On Wed, May 05, 2004 at 10:10:09AM -0400, Alan Stern wrote:
> > >
> > > Another possibility is to put the lock in usb.c:usb_stor_control_thread()
> > > at the point where the protocol han
Hi. This is the qmail-send program at free.fr.
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]>:
fermeture definitive de cette boite aux lettres, contactez moi pour + d'infos
--- Be
On Wed, 5 May 2004 [EMAIL PROTECTED] wrote:
> Alan Stern <[EMAIL PROTECTED]>@lists.sourceforge.net wrote:
> >
> >No. The controller notifies the driver by an interrupt and the driver
> >starts the controller. However, connection status detection works even
> >when the controller is halted. In f
On Wed, 5 May 2004, Matthew Dharm wrote:
> On Wed, May 05, 2004 at 10:10:09AM -0400, Alan Stern wrote:
> >
> > Another possibility is to put the lock in usb.c:usb_stor_control_thread()
> > at the point where the protocol handler is called. Then you wouldn't need
> > to lock it a second time du
On Wed, May 05, 2004 at 10:10:09AM -0400, Alan Stern wrote:
> On Mon, 3 May 2004, Matthew Dharm wrote:
>
> > > > Or the lock could be moved to where the transport is invoked, instead of
> > > > putting it in every transport.
>
> Another possibility is to put the lock in usb.c:usb_stor_control_thr
Hasjim Williams wrote:
The Viper Embedded Linux Developer Kit is based around an XScale
device, so it needs to use an Embedded USB Host Controller. The
Philips ISP1161A1 is such an example. An Embedded USB Host controller
is not the same thing as a standard desktop OHCI controller. They have
si
Alan Stern <[EMAIL PROTECTED]>@lists.sourceforge.net wrote:
... snip ...
>> >No, it is normal. When no devices are attached the driver halts the
>> >controller to reduce PCI utilization and avoid DMA activity, thereby
>> >permitting improved power management.
>> >
>> Then is it safe to assume,
Alan Stern wrote:
...
One or the other task will lock the hub first. Simple case: khubd
wins, driver's top-down lock acquisition will first block (because it
can't get past khubd) and then later fail (the device is gone, though
that task has an old device pointer that it's still got to release).
> Sorry im not an expert in this.., i have to install an update
> of the kernel? the only thing i want is that my device which
> will have usb conection, works on linux. I have Suse 9.0
> I have to program the driver?
> Thanks again!
>
>
> De: Shilpi
> Fecha: 05/05/04 13:45:36
> Para
And I would find it acceptable
to use hubdev->serialize to protect the links at the inner nodes if only I
could see how to also get usb_reset_device() working reliably. And
useable from within probe().
I think usb_reset_device(dev) would just need to call locktree(dev),
then fail cleanly on -
The original message was received at Wed, 5 May 2004 16:26:47 +0200
from [209.194.189.10]
- The following addresses had permanent fatal errors -
<[EMAIL PROTECTED]>
(reason: 550 5.1.1 <[EMAIL PROTECTED]>... User unknown)
- Transcript of session follows -
... while talkin
On Mon, 3 May 2004, Matthew Dharm wrote:
> > > Or the lock could be moved to where the transport is invoked, instead of
> > > putting it in every transport.
Another possibility is to put the lock in usb.c:usb_stor_control_thread()
at the point where the protocol handler is called. Then you woul
On Tue, 4 May 2004, Fulko Hew wrote:
> >The initialization code probably has changed since 2.4; it may well be the
> >source of your problem. Which driver are you using with 2.4: uhci or
> >usb-uhci?
> >
> I think its usb-uhci, as per lsmod report. Was that the correct way to
> determine it?
Ye
I'm about ready to give up on device reset during probe.
Consider this. There are three different paths that can call a driver's
probe():
1. Newly attached device is configured by usb_new_device().
Both the device and its parent hub are locked.
2. New configuration is install
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients failed.
[EMAIL PROTECTED]
Reporting-MTA: dns;fe-imc02.de.bosch.com
Received-From-MTA: dns;fez8121.de.bosch.com
Arrival-Date: Wed, 5 May 2004 15:30:53 +0200
Final-Recipient: rfc822;[EMA
> The good news is that there are several drivers for the Philips
> ISP1161A1. I'm not sure which version the Viper Embedded Linux Dev Kit
> uses, but you might want to check the following URLs:
The VIPER kernel has the Roman Weissgaerber's 0.9.5 driver, I was never
able to get the BDL one to wor
Waterford 5 May 2004
Hello,
Im doing an electronic project and i will need an USB-HID
driver for my device. It is easy to make it? Where I can find
help?
Thanks.
Waterford Institute of Technology
Tamar Aanen
---
This SF.Net e
Christopher,
I assume you're talking about the following dev board:
http://www.arcom.com/products/icp/dev_kits/Linux/Java_VIPER.htm
The Viper Embedded Linux Developer Kit is based around an XScale
device, so it needs to use an Embedded USB Host Controller. The
Philips ISP1161A1 is such an examp
Hi. This is the qmail-send program at tsi-gmbh.de.
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, no mailbox here by that name. vpopmail (#5.1.1)
--- Below this line is a
Alan Stern wrote:
> You might want to merge the patch below, which alters a couple of
> apparent typos.
Applied, thanks.
Clemens
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market...
On Tuesday 04 May 2004 04:04 pm, Greg KH wrote:
> On Sun, Apr 25, 2004 at 04:48:07PM -0500, Dmitry Torokhov wrote:
> >
> > No, I am still getting the oops.. hmm.. it seems a little bit different,
> > but still in the hiddev. I investigated further and the oops only happens
> > if I yank a HID dev
47 matches
Mail list logo
