On Monday 02 August 2004 09:36, Alan Stern wrote:
>
> My main point: There's no need to use locktree() in hub_events() or
> usb_reset_device(). (Although your latest changes didn't actually add
> locktree to usb_reset_device, there was a comment about doing it.)
I guess you didn't like my exam
Thanks David.
Many times I couldn't think out the reason why,but simply find some ways to
avoid it:-(
In this case,I found if compile g_ether.o as module. So when this message
appear, simply ifconfig usb0 down, then rmmod/insmod is ok.So my driver had
to detect usb plug in and unplug action, use
On Tue, Aug 03, 2004 at 02:43:34AM +, David Brownell wrote:
> On Monday 02 August 2004 15:48, Dale Farnsworth wrote:
> > This 3-part patch adds support for the big-endian OHCI implementations
> > found on IBM's stb04xxx and Freescale's MPC52xx processors.
>
> Looks like it should be OK; did yo
I thought I'd send this around for some comments. This
file is just for some of the folk writing OTG drivers
for their hardware ... normal USB (or Gadget) driver
writers won't need it, only folk twiddling bits in chip
registers to implement HNP and SRP will use this.
It encapsulates what may be ca
On Monday 02 August 2004 20:10, Greg KH wrote:
> >
> > Whoops, wrong tree wrong patch ... sorry!
>
> Hm, want me to revert it then?
Not if you fixed that goof already ... thanks!
- Dave
---
This SF.Net email is sponsored by OSTG. Have you
On Monday 02 August 2004 10:53, Jon Neal wrote:
> David -
>
> I finally got back to the RNDIS problem we were having with our board (PPC
> with net2280). The problem was actually in net2280.c little endian
> conversion of the last n bytes (less than 4) in read_fifo.
Your patch makes sense to me;
On Mon, Aug 02, 2004 at 07:10:53PM -0700, David Brownell wrote:
> On Monday 02 August 2004 16:23, Greg KH wrote:
>
> > > + retval = -EPROTO;
> >
> > Don't you mean for this to be "result"?
>
> Whoops, wrong tree wrong patch ... sorry!
Hm, want me to revert it then?
> > Sheesh,
On Monday 02 August 2004 15:48, Dale Farnsworth wrote:
> This 3-part patch adds support for the big-endian OHCI implementations
> found on IBM's stb04xxx and Freescale's MPC52xx processors.
Looks like it should be OK; did you re-test on x86?
I can wish such patches weren't needed, but this looks
On Monday 02 August 2004 14:22, Todd Fischer wrote:
> My understanding is that if I want to support USB OTG, I need 3 hardware
> specific pieces: USB host support (subset), USB device support, and a few
> routines that allow the hardware to switch host/device roles as specified in
> the USB OTG sp
On Monday 02 August 2004 16:23, Greg KH wrote:
> > + retval = -EPROTO;
>
> Don't you mean for this to be "result"?
Whoops, wrong tree wrong patch ... sorry!
> Sheesh, doesn't anyone actually build the patches they send me? :)
You have been assimilated into discc ... :)
---
On Mon, Aug 02, 2004 at 09:00:54PM +0200, Luis Miguel Garc?a Mancebo wrote:
> Hello,
>
> I have a nforce2 motherboard. I have to report that recent changes in usb
> code make my board don't work at all.
>
> In 2.6.7-mm7, I just reverted the bk-usb.patch and the things started to
> w
On Monday 02 August 2004 11:28 am, Norbert Preining wrote:
> Hi Andrew, hi list!
>
> I tried 2.6.8-rc2-mm2 and I still don't get it to work properly for me.
> The last kernel which really worked was 2.6.7-mm5. I experience the
> following problems:
>
> - USB deadlocking
> USB is still deadlocky
On Mon, Aug 02, 2004 at 03:06:33PM -0700, David Brownell wrote:
> I noticed the HID driver had some potential misbehavior ...
Applied, thanks.
greg k-h
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITMa
On Mon, Aug 02, 2004 at 03:18:02PM -0700, David Brownell wrote:
> --- 1.64/drivers/usb/core/message.c Wed Jun 30 06:48:12 2004
> +++ edited/drivers/usb/core/message.c Wed Jul 14 12:05:11 2004
> @@ -577,8 +577,13 @@
> USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
>
On Monday 02 August 2004 23:04, Alan Stern wrote:
> On Mon, 2 Aug 2004, Duncan Sands wrote:
>
> > > I don't think people will stand for making ->serialize into an rwsem.
> >
> > Why is that? It seems natural.
> >
> > Duncan.
>
> This discussion seems dreadfully familiar. If you go look throug
This 3-part patch adds support for the big-endian OHCI implementations
found on IBM's stb04xxx and Freescale's MPC52xx processors.
Patch 1 Removes byteswapped OHCI constants in preparation for
dynamically handling endianness.
Patch 2 Adds support for big-endian OHCI controllers.
T
This 3-part patch adds support for the big-endian OHCI implementations
found on IBM's stb04xxx and Freescale's MPC52xx processors.
Patch 1 Removes byteswapped OHCI constants in preparation for
dynamically handling endianness.
Patch 2 Adds support for big-endian OHCI controllers.
T
This 3-part patch adds support for the big-endian OHCI implementations
found on IBM's stb04xxx and Freescale's MPC52xx processors.
Patch 1 Removes byteswapped OHCI constants in preparation for
dynamically handling endianness.
Patch 2 Adds support for big-endian OHCI controllers.
T
I've had different versions of this floating around for a while;
basically, the goal is to be more robust against devices that
misbehave by returning garbage descriptors in certain cases.
- Dave
Add an extra check when fetching descriptors: the type must be
correct. This guards against different
I noticed the HID driver had some potential misbehavior ...
- Dave
Bugfix handling for HID devices at high speed (interrupt interval encoding
is log2 not linear), and for interrupt OUT transfers (use the interval
the hardware actually supports).
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
On Sun, Aug 01, 2004 at 05:39:12PM -0700, Matthew Dharm wrote:
> In theory, this is the fix we need to make Genesys Logic devices work.
> This patch started life as as343, which was created based on some
> information which a user finally coaxed out of Genesys Logic. Limited
> end-user testing giv
On Sat, Jul 31, 2004 at 03:00:07PM -0700, Matthew Dharm wrote:
> This patch is originally from Christoph Hellwig.
>
> This patch coverts from Scsi_Foo typefs to struct scsi_cmnd, and moved from
> the SCSI data direction constants to the DMA ones.
>
> It also switches to the proper (or so they tel
On Sun, Aug 01, 2004 at 05:20:03PM -0700, Matthew Dharm wrote:
> This patch started life as as294. All I did was to regenerate it to apply
> cleanly against current kernels.
>
> This just adds a couple of lines to the debugging output with some useful
> information, and removes some lines that no
Hi Greg,
On Monday 02 August 2004 21:59, Greg KH wrote:
> On Thu, Jul 29, 2004 at 06:35:26PM +0200, Duncan Sands wrote:
> > +static int start_wait_urb(struct usb_device *dev, struct urb *urb, int timeout,
> > int* actual_length)
>
> Hm, with the exception of these two lines:
>
> > + u
On Mon, Aug 02, 2004 at 10:48:38PM +0200, Duncan Sands wrote:
> Hi Oliver,
>
> > An rwsem, never ever can solve a race condition, Rwsems are _only_
> > a performance due to concurrence issue.
>
> in this case it is only a performance issue.
Great, then do not do it, we'll handle "performance" is
Hi,
I am trying to figure out what has to be done to support the USB host subset
for OTG host.
The hardware I am using does not follow any of the host hardware standards
like ehci, ohci, or uhci. The only USB host driver that doesn't use one of
these three is the SL811 driver. It includes two C
On Mon, Aug 02, 2004 at 12:05:27AM +0200, Photon Software (Marko R?der) wrote:
> Hi,
>
> can anyone tell me how to determine the device (/dev/sdX) to mount a specific
> usb hard disk? At moment I only have the output from /proc/bus/usb/devices
> where I can have a look, whether the specific hard
On Mon, 2 Aug 2004, Duncan Sands wrote:
> > I don't think people will stand for making ->serialize into an rwsem.
>
> Why is that? It seems natural.
>
> Duncan.
This discussion seems dreadfully familiar. If you go look through the
excessively long thread starting with
http://marc.theaimsgro
Hi Oliver,
> An rwsem, never ever can solve a race condition, Rwsems are _only_
> a performance due to concurrence issue.
in this case it is only a performance issue.
All the best,
Duncan.
---
This SF.Net email is sponsored by OSTG. Have you
On Mon, 2 Aug 2004, Brad Campbell wrote:
> You remember that file I had that can consistently lockup my device?
>
> Turns out it has something to do with the cable length and capacitance between the
> chip and the drive!
<...>
> GL-811 -> Mini-Centronics-Male -> Mini-Centronics-Female -> PCB ->
> I don't think people will stand for making ->serialize into an rwsem.
Why is that? It seems natural.
Duncan.
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past
Am Montag, 2. August 2004 21:35 schrieb Alan Stern:
> > that was my impression too. A better (but more intrusive) way of handling
> > dev->serialize
> > would be to turn it into a r/w semaphore. In that case usbfs would need to take
> > an additional
> > lock in a few places (a spinlock would s
On Mon, Aug 02, 2004 at 01:40:23PM +0200, Duncan Sands wrote:
> After the storm, silence... Does this mean that everyone is now happy with these
> patches? That's hard to believe...
I want to like them, really I do... :)
How about we straighten out the start_wait_urb() stuff I just posted in
a
On Fri, Jul 30, 2004 at 10:41:23AM +0200, Duncan Sands wrote:
> >
> > Hm, I don't see how this fixes anything. If we hold the semaphore, the
> > urb will complete eventually, and then the semaphore will be released,
> > and any one blocking on it will wake up, right?
>
> But no-one else can do a
On Mon, Aug 02, 2004 at 01:43:41PM +0200, Florian Echtler wrote:
> --- linux-2.6.7/drivers/usb/misc/idmouse.c1970-01-01 01:00:00.0 +0100
> +++ linux/drivers/usb/misc/idmouse.c 2004-07-30 14:26:15.0 +0200
> @@ -0,0 +1,457 @@
> +// Siemens ID Mouse driver v0.3
> +// authors: Flor
On Thu, Jul 29, 2004 at 06:35:26PM +0200, Duncan Sands wrote:
> +static int start_wait_urb(struct usb_device *dev, struct urb *urb, int timeout,
> int* actual_length)
Hm, with the exception of these two lines:
> + up(&dev->serialize);
> + wait_for_completion(&done);
> +
On Mon, 2 Aug 2004, Duncan Sands wrote:
> > My impression was that people would be happy to have nothing more than the
> > part that drops the lock after issuing an URB and reacquires it later.
>
> that was my impression too. A better (but more intrusive) way of handling
> dev->serialize
> wou
Greg:
This morning I did a "bk pull" and was surprised to find that not only
were the patches I had submitted several weeks back not yet applied, some
earlier patches which had been accepted and merged were no longer present!
This is worse than the Red Queen's race!
What would you like me to do
On Mon, 2 Aug 2004, Photon Software (Marko Röder) wrote:
> It's not the problem for _me_ to find the proper device to mount. Need this
> information for an app that should determine whether the device is plugged or
> not and if plugged it should have a closer look at the files on it.
>
> @/proc
David -
I finally got back to the RNDIS problem we were having with our board (PPC
with net2280). The problem was actually in net2280.c little endian
conversion of the last n bytes (less than 4) in read_fifo. We are still
running the net2280 in PIO mode. I spent a lot of time trying to get dma
On Mon, 2 Aug 2004, Photon Software (Marko Röder) wrote:
> The problem is that system log (/var/log/messages) can only be accessed by
> root and so my tool can't get this information. I also already had a closer
> look at the /proc/scsi directory but there I cannot determine the
> manufacturer
Hi David!
On Mon, 02 Aug 2004, David Brownell wrote:
> > - USB deadlocking
> > USB is still deadlocky, quite often process hang in D+ state.
>
> So what does alt-sysrq-t show you about those processes?
Ok, I will write it down next time ;-) It happens during the boot
process, but I will try to
On Monday 02 August 2004 09:28, Norbert Preining wrote:
> - USB deadlocking
> USB is still deadlocky, quite often process hang in D+ state.
So what does alt-sysrq-t show you about those processes?
How do you reproduce these hangs? I'm guesssing that
And does 2.6.8-rc (without the MM patch) act
David:
Your reply to my last message was so far off-base with respect to the
ideas I had intended to convey, I can only assume there's been a serious
communications failure. I'll do my best to clarify things below and show
where you went astray.
My main point: There's no need to use locktree
Hi Andrew, hi list!
I tried 2.6.8-rc2-mm2 and I still don't get it to work properly for me.
The last kernel which really worked was 2.6.7-mm5. I experience the
following problems:
- USB deadlocking
USB is still deadlocky, quite often process hang in D+ state.
Is there something similar to usb
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> > +static int idmouse_release(struct inode *inode, struct file *file)
> You should be taking disconnect_sem here instead. Think about it:
> you are competing with an open. What happens there?
Hmm, you're right, but dev->sem is IMHO still needed to pr
> It cannot be solved at all. You have to open the device _before_ you
> determine configuration. Anything else is an unfixable race condition
> However, if you've correctly claimed an interface, usbfs can react with
> ENODEV.
Right, except that it doesn't right now, and changing that would break
Am Montag, 2. August 2004 17:14 schrieb Alan Stern:
> There is indeed a problem, but it's not solved so easily.
>
> Consider this instead:
>
> (A) User process uses libusb or /proc/bus/usb/devices or whatever
> to determine what the configuration is and what interfaces exist.
>
>
Hi Alan,
On Monday 02 August 2004 17:14, Alan Stern wrote:
> On Mon, 2 Aug 2004, Duncan Sands wrote:
>
> > After the storm, silence... Does this mean that everyone is now happy with these
> > patches? That's hard to believe...
>
> My impression was that people would be happy to have nothing m
IFrame tag in HTML message
Note to Tech Support: Look on the TCP MailScanner 1 in /var/spool/MailScann=
er/quarantine/20040802 (message i72FL0Wj019655).
--=20
TCP Postmaster
--=_NextPart_001_001C_01C0CA80.6B015D10--
--=_NextPart_000_001B_01C0CA80.6B015D10
Content-Type: text/plain;
On Mon, 2 Aug 2004, Duncan Sands wrote:
> After the storm, silence... Does this mean that everyone is now happy with these
> patches? That's hard to believe...
My impression was that people would be happy to have nothing more than the
part that drops the lock after issuing an URB and reacquir
Am Montag, 2. August 2004 14:25 schrieb Florian Echtler:
> > > + } else do {
> > > +
> > > + // create a new image and check for success
> > > + result = idmouse_create_image (dev);
> > > + if (result)
> > > + break;
> > > +
>
On Mon, 2 Aug 2004, Photon Software (Marko [iso-8859-15] Röder) wrote:
> Hi,
>
> can anyone tell me how to determine the device (/dev/sdX) to mount a specific
> usb hard disk? At moment I only have the output from /proc/bus/usb/devices
> where I can have a look, whether the specific hard disk i
> +// prevent races between open() and disconnect()
> +static DECLARE_MUTEX(disconnect_sem);
> +static int idmouse_release(struct inode *inode, struct file *file)
> +{
> + dev = (struct usb_idmouse *) file->private_data;
> + if (dev == NULL)
> + return -ENODEV;
> + // lock
On Sunday 01 August 2004 20:52, [EMAIL PROTECTED] wrote:
> if you plug off usb cable then plug it on, after about 3 times or more,
> following message appear,then if you want usb work, you had to reboot
> lubbock, Anyone had any idea? Thanks
>
> rndis_msg_parser: unknown RNDIS Message Type 0x02000
On Monday 02 August 2004 00:19, Dwaine Garden wrote:
> I'm looking for some hints on how to code the change to configuration #2.
The easy "works right now" solution is to write the bConfigurationValue
device attribute in sysfs.
There's also been some discussion about adding a new driver method
to
On Sat, 31 Jul 2004, Sven-Olof Klasson wrote:
> I applied these patches on a clean 2.6.7 tree. With these patches the camera
> is sometimes recognized by Linux. It does not allways work. Below is a example
> where Linux recognized the camera on the 4th attempt.
It beats me what could be going on
Hi SAW
(B
(Bif not find these print message,iso interrupt is not happen.
(B
(Bprintk("bstat =%x hp->itl1_len=%d\n",bstat,hp->itl1_len);
(Bor
(Bprintk("bstat =%x hp->itl0_len=%d\n",bstat,hp->itl0_len);
(Bin isp116x.c[hc_interrupt]
(B
(BAnd you know many printk massage disturb isoc transfer.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> > + } else do {
> > +
> > + // create a new image and check for success
> > + result = idmouse_create_image (dev);
> > + if (result)
> > + break;
> > +
> > +
> + } else do {
> +
> + // create a new image and check for success
> + result = idmouse_create_image (dev);
> + if (result)
> + break;
> +
> + // increment our usage count for the drive
> This patch adds a new usb-misc driver for the fingerprint sensor
> that can be found in the Siemens ID Mouse USB. 'cat /dev/idmouseX'
> yields a 225x288 greyscale PNM with the fingerprint information.
>
> It may be considered controversial that it outputs a PNM instead
> of raw data, but I hold
An error was detected while processing the enclosed message. A list of
the affected recipient follows. This list is in a special format that
allows software like LISTSERV to automatically take action on incorrect
addresses; you can safely ignore the numeric codes.
--> Error description:
Error-f
This patch adds a new usb-misc driver for the fingerprint sensor
that can be found in the Siemens ID Mouse USB. 'cat /dev/idmouseX'
yields a 225x288 greyscale PNM with the fingerprint information.
It may be considered controversial that it outputs a PNM instead
of raw data, but I hold the opinion
After the storm, silence... Does this mean that everyone is now happy with these
patches? That's hard to believe...
> > So, what does happen if a disconnect happens while your sparkling new
> > static start_wait_urb sits in wait_for_completion()? How exactly is this
> > different?
>
> in that
Hi Rudolf,
thanx for this hint. I found this article to it
http://www.mail-archive.com/[EMAIL PROTECTED]/msg19522.h
tml. So i included in pwc-if.c in pwc_isoc_handler of the PWC driver for my
linux webcam the following lines:
handler_end:
if (awake)
wake_up_interruptible(&
Hi adsynori:
I'm very glad to received your reply!
>Hi eyou
>
>First
>How do you escape from this problem? I want to know.
>>USB HC dev alloc 1152 bytes
>>hub.c: USB new device connect on bus1/2, assigned device number 2
>>usb_control/bu
> It's kinda too long to list stones I turned over between hid, ohci,
> and devio. But if my count disbalance hypothesis is true, then pampering
> over this in usb-ohci is not feasible. The perpetrator has to be found
> and exterminated. The code is pretty nasty though. It might be easier
> to give
We are trying to get our device to use another configuration other than
the default configuration. We are trying to get the audio over usb
working on the device. The third endpoint does not appear active if we
use configuration #1, it's only active if configuration #2 and higher is
used.
Al
68 matches
Mail list logo
