Hi, Greg:
I looked at RMK's UART infrastructure and it seemed a little too
fine-grained to me. It does not seem like a good match for things
like edgeport and keyspan. So, my enthusiasm about "us" has diminished.
Also, remember what kind of pain in the butt was the coexistence
of usb-storage and
Remove the silly trailing backslash.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
--- linux-2.6.17-rc2/drivers/usb/serial/pl2303.c2006-04-23
21:06:18.0 -0700
+++ linux-2.6.17-rc2-lem/drivers/usb/serial/pl2303.c2006-05-22
21:31:15.0 -0700
@@ -599,7 +599,7 @@ static
Add a couple of supported devices into the help message.
It's a long story... I promised this comment changed to a user long ago,
so I'd like to have that promise kept. In reality though, nobody is
likely to read this anyway.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
--- linux-2.6.17-rc2/d
I'm going to throw schedule_work away, it's retarded. But for starters,
let's have it encapsulated.
Also, generic and whiteheat were both calling usb_serial_port_softint
and scheduled work. Only one was necessary.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
---
The double-calling looks like
Clean up the unicode handling in io_edgeport. Make get_string size-limited.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
---
Al & Peter, I'd like you to take a look and let me know if you have
any objections. Thanks.
-- Pete
diff -urp -X dontdiff linux-2.6.17-rc2/drivers/usb/serial/io_edgepo
On Mon, May 22, 2006 at 02:44:03PM -0700, Greg KH wrote:
> On Mon, May 22, 2006 at 04:30:48PM +0200, Frank Gevaerts wrote:
> > Hi,
> >
> > We are having problems with the usb-serial ipaq driver in 2.6.16 (debian
> > backports 2.6.16-1-686, but also reproducible with self-compiled
> > kernel.org k
On Mon, May 22, 2006 at 04:30:48PM +0200, Frank Gevaerts wrote:
> Hi,
>
> We are having problems with the usb-serial ipaq driver in 2.6.16 (debian
> backports 2.6.16-1-686, but also reproducible with self-compiled
> kernel.org kernel)
>
> Sometimes, we get the following on disconnect:
Can you
Hi!
> > https://bugzilla.novell.com/show_bug.cgi?id=173420
>
> >From Comment #30 at the above url: "The Linux ACPI code seems to
> actively prevent the fan from running and that worries me."
>
> I saw that as well, and found the following recipe would work around
> the problem:
>
> 1. Set the t
Sanjoy Mahajan wrote:
> That seems likely, thanks for the pointer: Besides the ACPI sleep
> hangs, this machine (TP 600X) has fan troubles upon S3 resume. The
> problems don't do harm (the damn fan keeps turning on when it
> shouldn't), but that's probably chance. Various patches that I tested
>
> This sounds like the problem Daniel had on his Samsung P35 recently.
> He could fix it by getting rid of some asus_unhide_smbus stuff or the
> otherway around, adding asus_unhide_smbus quirks in the S3 resume code.
>
> This thread was recently posted on lkml:
> Re: [patch] smbus unhiding kills t
Greg:
This patch (as693b) makes the usbtest driver report errors in the
isochronous bulk transfer tests instead of always returning 0. As an
arbitrary cutoff, an error is returned if more than 10% of the packet
transfers fail. It also stops a test immediately upon receiving an URB
submission
On Mon, 22 May 2006, Matthew Dharm wrote:
> > Also, what is the value of MAX_SCHEDULE_TIMEOUT, and is it a sane value?
>
> Now that I think about it some more, why use MAX_SCHEDULE_TIMEOUT at all?
> You're imposing a timeout where none existed before...
MAX_SCHEDULE_TIMEOUT is a magic value for
On Mon, May 22, 2006 at 10:20:58AM -0700, Matthew Dharm wrote:
> On Mon, May 22, 2006 at 10:53:40AM -0400, Alan Stern wrote:
> > On Mon, 22 May 2006, Franck Bui-Huu wrote:
> >
> > > and use completion timeout instead.
> > >
> > > Signed-off-by: Franck Bui-Huu <[EMAIL PROTECTED]>
> >
> > This loo
On Mon, May 22, 2006 at 10:53:40AM -0400, Alan Stern wrote:
> On Mon, 22 May 2006, Franck Bui-Huu wrote:
>
> > and use completion timeout instead.
> >
> > Signed-off-by: Franck Bui-Huu <[EMAIL PROTECTED]>
>
> This looks okay to me, although you might as go ahead and use
> wait_for_completion_in
Begin forwarded message:
Date: Mon, 22 May 2006 05:19:36 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 6596] New: kernel bug at unloading pl2303
http://bugzilla.kernel.org/show_bug.cgi?id=6596
Summary: kernel bug at unloading pl2303
Kernel Versio
Greg:
This patch (as693) makes the usbtest driver report errors in the
isochronous bulk transfer tests instead of always returning 0. As an
arbitrary cutoff, an error is returned if more than 10% of the packet
transfers fail.
For a test harness, it's especially important to report when errors
Greg:
This patch (as692) fixes a few memory leaks in some unimportant error
pathways of the gadgetfs driver.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
---
Index: usb-2.6/drivers/usb/gadget/inode.c
===
--- usb-2.6
Greg:
This patch (as691) fixes a few errors in the AIO interface for the
gadgetfs driver. Now requests will complete properly instead of hanging.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
---
Index: usb-2.6/drivers/usb/gadget/inode.c
==
On Monday 22 May 2006 4:31 am, Ethan Du wrote:
> 1. why should device pass a MAC address to Host through "Ethernet Networking
> Functional Descriptor"? Can usenet.c decide one by itself?
It's better if MAC addresses don't need local/probabalistic allocation.
> 2. EEM doesn't have specific desc
hi folks,
I'm running a 2.6.16.16 kernel on a small Via Epia Nano N 1E board
with a "Luke" processor.
Running a bridge over one on-board ethernet interface (via-rhine) and a
USB-to-ethernet adaptor D-Link DUB-E100 (with asix AX88772 chip, drivers:
usbnet + asix), I occasionally get an oops l
Hi Folks!
I am actually saerching a performance dececrease after I updated our
2.6.10-rc2 application.
The kernel runs on a i.MX arch (ARM9).
Until now we use this kernel with the isp116x ohci emulation driver.
After loading the ohci-hcd module prism2-usb and p80211 modules from
linux-wlan-ng a
> Hi Subhash,
> Thanks for ur comments,
> My PHY chip is SMSC USB3300 chip which is ULPI Compliant,
> I have gone through the pin diagram of this Chip, There is a pin - 9
> in this chip which is the RESET pin for this chip, But i dont see any
> external reset button facility for this purpose.
>
> I
On Mon, 22 May 2006, Tilman Schmidt wrote:
> Working on improving the error handling of a USB driver, I would
> like to be able to trigger some of the most common error conditions
> at will. A prime candidate is "endpoint stalled" (-EPIPE), which
> occurs frequently enough with the device in quest
On Mon, 22 May 2006, Franck Bui-Huu wrote:
> and use completion timeout instead.
>
> Signed-off-by: Franck Bui-Huu <[EMAIL PROTECTED]>
This looks okay to me, although you might as go ahead and use
wait_for_completion_interruptible_timeout so that the time spent waiting
will be properly account
On Mon, 22 May 2006, Phil Dibowitz wrote:
> > - New flag MAX_SECTORS_128 in include/linux/usb_usual.h
> > - Sets max_sectors per request of queue to 128 sectors if
> >flag is set in drivers/usb/storage/scsiglue.c
>
> Cool - unfortunately, this part of the code isn't up to me alone to
> acce
Hi,
We are having problems with the usb-serial ipaq driver in 2.6.16 (debian
backports 2.6.16-1-686, but also reproducible with self-compiled
kernel.org kernel)
Sometimes, we get the following on disconnect:
Unable to handle kernel paging request at virtual address 723d4ec3
printing eip:
b01ea
Working on improving the error handling of a USB driver, I would
like to be able to trigger some of the most common error conditions
at will. A prime candidate is "endpoint stalled" (-EPIPE), which
occurs frequently enough with the device in question to be annoying,
but too rarely to properly test
Hi, all:
I am trying to write a EEM usb function driver myself. But I get
confused. Hope someone can help.
EEM specification doesn't declare any specific descriptor, comparing to
CDC Ethernet, which uses an "Union Function Descriptor" and an "Ethernet
Networking Functional Descriptor". I
[EMAIL PROTECTED] wrote:
> On Mon, 22 May 2006 00:48:31 -0700
> Phil Dibowitz <[EMAIL PROTECTED]> wrote:
>
>> Is there still desire for that? If so, I can whip up a patch, or perhaps
>> Benjamin would prefer to do it.
>
> I don't prefer it, because as I am not familiar with it,
> it takes me rea
and use completion timeout instead.
Signed-off-by: Franck Bui-Huu <[EMAIL PROTECTED]>
---
drivers/usb/storage/transport.c | 34 ++
1 files changed, 6 insertions(+), 28 deletions(-)
c35738d918f56fbb725b29c8098cee819e33a83d
drivers/usb/storage/transport.c | 34
On Mon, 22 May 2006 00:48:31 -0700
Phil Dibowitz <[EMAIL PROTECTED]> wrote:
>
> Is there still desire for that? If so, I can whip up a patch, or perhaps
> Benjamin would prefer to do it.
I don't prefer it, because as I am not familiar with it,
it takes me really a lot of time.
> Personally,
[EMAIL PROTECTED] wrote:
> Hello,
>
> The last patch I'have sent to you changes the following
Hmm - I never got it, sorry.
> - New device entry for unusual_dev.h with rev id 0x0103 instead of
>0x-0x and with the new flag
Awesome.
> - New flag MAX_SECTORS_128 in include/linux/usb
Hello,
The last patch I'have sent to you changes the following
- New device entry for unusual_dev.h with rev id 0x0103 instead of
0x-0x and with the new flag
- New flag MAX_SECTORS_128 in include/linux/usb_usual.h
- Sets max_sectors per request of queue to 128 sectors if
flag i
33 matches
Mail list logo
