On Thu, Jun 01, 2006 at 12:36:45PM +0200, Milan Svoboda wrote:
> > > From: Milan Svoboda <[EMAIL PROTECTED]>
> > >
> > > This patch adds support for pxa2xx_udc. This driver then will be
> > > usable on ixp4xx platform.
> >
> > Great work!
> >
> > One thought: if adding ixp4xx support to pxa2xx_
Lennert Buytenhek <[EMAIL PROTECTED]>
05/29/2006 11:09 AM
To: Milan Svoboda <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED],
linux-usb-devel@lists.sourceforge.net
Subject:Re: [PATCH] ixp4xx: Add platform specific device -
pxa2xx_udc
On Mon, May 29, 2006 at 1
On Thu, Jun 01, 2006 at 12:42:45AM +0200, Frank Gevaerts wrote:
> This patch fixes several problems in the ipaq.c driver with connecting
> and disconnecting pocketpc devices:
> * The read urb stayed active if the connect failed, causing nullpointer
> dereferences later on.
> * If a write failed
Greg KH wrote:
Not correct or needed at all. What needs to happen is the airprime
driver should be changed to handle bigger buffer sizes in it, not to
mess with the usb-serial core.
Yes, that sounds much more sensible.
I've been working with Ken on getting this driver to work better
(meani
On Wed, May 31, 2006 at 01:25:41PM -0700, Jeremy Fitzhardinge wrote:
> People using 1xEV-DO devices report that usb-serial must be changed to
> allow an increased buffer size in order to get good throughput a full
> data-rate.
>
> There's a page at
> http://www.junxion.com/opensource/linux_high
On Wed, May 31, 2006 at 11:42:19AM -0400, Stuart MacDonald wrote:
> Attached patch fixes spurious errors during firmware load. Please
> apply to 2.6.16.20 and 2.6.17.
>
> Signed-off-by: Stuart MacDonald <[EMAIL PROTECTED]>
>
> ..Stu
>
> --- linux-2.6.16/drivers/usb/serial/whiteheat.c 2006-
On Mon, May 29, 2006 at 10:34:33AM +, Milan Svoboda wrote:
> From: Milan Svoboda <[EMAIL PROTECTED]>
>
> This patch adds support for pxa2xx_udc. This driver then will be
> usable on ixp4xx platform.
Great work!
One thought: if adding ixp4xx support to pxa2xx_udc, shouldn't we
rename pxa2xx_
Hi,
On Tue, Apr 25, 2006 at 08:36:45AM +0200, Veldeman, Jan wrote:
> In some cases the irq may not be requested by usb_add_hcd. E.g. the
> interrupt is shared among different parts of the same driver, and by
> having only 1 handler which calls the others, helps in making the
> driver cleaner.
>
On Fri, 26 May 2006, Daniel Drake wrote:
> 2.6.16 introduces USB power budgeting in the Linux kernel, and since then, a
> fair number of users have observed that some of their devices no longer work
> in
> unpowered hubs (this is not a bug, the devices claim that they need more than
> 100mA).
>
Jonatan Antoni wrote:
Hello,
we are using an AT91RM9200 microcomputer as a usb-gadget.
If our target is connected to a host and the usb-link is in use by e.g.
g_ether, it goes into a kernel oops in some
cases.
I have reconstructed the following case:
- establish the usb-connection between the
Looks good to me. Greg, please apply.
Matt
Signed-off-by: Matthew Dharm <[EMAIL PROTECTED]>
On Wed, May 24, 2006 at 04:57:28PM +0200, Franck Bui-Huu wrote:
>
> This patch uses completion timeout instead of a timer to implement
> a timeout when submitting an URB.
>
> It also put the task in in
Alan Stern wrote:
> On Wed, 24 May 2006, Franck Bui-Huu wrote:
>
>> and use completion timeout instead. It also put the task
>> in interruptible state instead of an uninterruptible one
>> while waiting for the completion.
>
> Don't make the email content a continuation of the subject line. When
On Wed, 24 May 2006, Franck Bui-Huu wrote:
> and use completion timeout instead. It also put the task
> in interruptible state instead of an uninterruptible one
> while waiting for the completion.
Don't make the email content a continuation of the subject line. When
your patch is accepted the co
On Wednesday 24 May 2006 12:50 am, Jonatan Antoni wrote:
> I have reconstructed the following case:
> - establish the usb-connection between the target and a windows host
> - do "modprobe g_ether" on the target
> - do "ifconfig usb0 192.168.1.2 up" on the target
> - test the connection with e.g. pi
On Tue, May 23, 2006 at 12:04:59AM +0200, Frank Gevaerts wrote:
> 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
> > > backp
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
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
[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
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
[EMAIL PROTECTED] wrote:
> Hello Phil,
>
> Please let me know if you'll apply the patch.
>
> Benjamin
>
Sorry for the late reply. Your use of the flags makes perfect sense...
though I don't believe I saw a response from you regarding:
"You're mis understanding me - I don't care about the te
Pete Zaitcev wrote:
> Excuse me! This was not part of the deal. Here's what you proposed
> originally:
...
> Neither of the above tries to bust MAX_USBFS_BUFFER_SIZE. Why don't
> you just come clean with your real aim?
Sorry, I didn't mean any offense- and the MAX_USBFS_BUFFER_SIZE change
certain
On Thu, 18 May 2006 11:40:01 -0700, Micah Dowty <[EMAIL PROTECTED]> wrote:
> 3. Isochronous transfers had a higher arbitrary buffer size
> limit than bulk/interrupt transfers. Isochronous transfers
> now use MAX_USBFS_BUFFER_SIZE, which has been raised to 32K.
Excuse me! This was not part
On Thu, May 18, 2006 at 11:40:01AM -0700, Micah Dowty wrote:
> (Sorry for the duplicate- I should know better than to try
> sending patches from Outlook... This should fix the word
> wrapping.)
Thanks, that fixed the wrapping, but my other comments remain the same.
greg k-h
Am Sonntag, 14. Mai 2006 16:11 schrieb [EMAIL PROTECTED]:
> + if ((fhdr->id) == cpu_to_be16(0x8001)) {
> + unsigned char marker[] = { 0x00, 0xff, 0x00, 0xFF };
> + RingQueue_Enqueue(&uvd->dp, marker, 4);
> + totaldata +
Am Sonntag, 14. Mai 2006 16:11 schrieb [EMAIL PROTECTED]:
> +static int __init qcm_init(void)
> +{
> + struct usbvideo_cb cbTbl;
> +
> + info(DRIVER_DESC " " DRIVER_VERSION);
> + memset(&cbTbl, 0, sizeof(cbTbl));
> +
> + cbTbl.probe = qcm_probe;
> + cbTbl.setupOnOpen =
Am Montag, 15. Mai 2006 01:19 schrieb Jaya Kumar:
> On 5/15/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > Building this data structure on the stack is a shooting offense.
>
> I completely agree with you (except for the shooting part :-). I'll
> make the corrections. In my defense, I copied that
On 5/15/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
Building this data structure on the stack is a shooting offense.
I completely agree with you (except for the shooting part :-). I'll
make the corrections. In my defense, I copied that from the konicawc
code.
drivers/usb/media/konicawc.c
921
Am Sonntag, 14. Mai 2006 16:11 schrieb [EMAIL PROTECTED]:
> +static int qcm_setup_on_open(struct uvd *uvd)
> +{
> + qcm_sensor_set_gains(uvd, uvd->vpic.hue,
> + uvd->vpic.colour, uvd->vpic.contrast);
> + qcm_sensor_set_exposure(uvd, uvd->vpic.brightness);
Am Sonntag, 14. Mai 2006 16:11 schrieb [EMAIL PROTECTED]:
> + if (cam->scratch)
> + kfree(cam->scratch);
You can do that unconditionally.
Regards
Oliver
On 5/15/06, Jaya Kumar <[EMAIL PROTECTED]> wrote:
drivers/usb/media % egrep "urb->status.*=" *.c
konicawc.c:urb->status = 0;
se401.c:urb->status=0;
stv680.c: urb->status = 0;
usbvideo.c: urb->status = 0;
w9968cf.c: urb->status = 0;
I guess since usb_submit_urb a
On 5/15/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
Am Montag, 15. Mai 2006 10:49 schrieb [EMAIL PROTECTED]:
> +urb->status = 0;
> +urb->actual_length = 0;
These are not needed. Indeed you should never write to those fields.
Regards
Oliver
I see. Good point. I ought
Am Montag, 15. Mai 2006 10:49 schrieb [EMAIL PROTECTED]:
> + struct qcm *cam = (struct qcm *) uvd->user_data;
> +
> + cam->width = camera_sizes[cam->size].width;
> + cam->height = camera_sizes[cam->size].height;
> + uvd->videosize = VIDEOSIZE(cam->width, cam->height);
> +
Am Montag, 15. Mai 2006 14:50 schrieb Jaya Kumar:
> On 5/15/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > Am Montag, 15. Mai 2006 10:49 schrieb [EMAIL PROTECTED]:
> > > +urb->status = 0;
> > > +urb->actual_length = 0;
> >
> > These are not needed. Indeed you should never write to those fields.
>
Am Montag, 15. Mai 2006 10:49 schrieb [EMAIL PROTECTED]:
> +static void qcm_setup_input_int(struct qcm *cam, struct uvd *uvd)
> +{
This should report errors.
Regards
Oliver
---
Using Tomcat but need to do more? Need to
Am Montag, 15. Mai 2006 10:49 schrieb [EMAIL PROTECTED]:
> + urb->status = 0;
> + urb->actual_length = 0;
These are not needed. Indeed you should never write to those fields.
Regards
Oliver
---
Using Tomcat
On 5/15/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
Am Sonntag, 14. Mai 2006 16:11 schrieb [EMAIL PROTECTED]:
> +static int qcm_setup_on_open(struct uvd *uvd)
> +{
> +qcm_sensor_set_gains(uvd, uvd->vpic.hue,
> +uvd->vpic.colour, uvd->vpic.contrast);
> +qcm_sensor_set_exposure(uvd, uvd->vpic.brig
Am Sonntag, 14. Mai 2006 16:11 schrieb [EMAIL PROTECTED]:
> + qcm_setup_input_int(cam, uvd);
> + uvd->streaming = 1;
> + uvd->curframe = -1;
> + qcm_camera_on(uvd);
This is a race condition with the URB for the interrupt endpoint. You must
set the "streaming" flag before yo
Am Sonntag, 14. Mai 2006 16:11 schrieb [EMAIL PROTECTED]:
> + struct regval {
> + u16 reg;
> + u8 val;
> + };
> + /* this table is derived from the
> + qc-usb-messenger code */
> + struct regval regval_table[] = {
> + { STV_IS
On Fri, May 05, 2006 at 02:43:03PM -0400, Alan Stern wrote:
> Greg:
>
> Here's a question for you.
>
> The current 2.6.17-rc driver handles FSBR rather poorly. For most
> purposes it doesn't matter. But under certain kinds of load, like with a
> Bluetooth adapter attached, it can increase power
Hello Phil,
Please let me know if you'll apply the patch.
Benjamin
---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM Web
On Mon, 1 May 2006, Pete Zaitcev wrote:
> On Mon, 24 Apr 2006 11:55:51 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]>
> wrote:
>
> > Before submitting the patch, it seemed like a good idea to check with you
> > and make sure it doesn't cause any problems. I'd appreciate it if you
> > could try i
On Mon, 24 Apr 2006 11:55:51 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> Before submitting the patch, it seemed like a good idea to check with you
> and make sure it doesn't cause any problems. I'd appreciate it if you
> could try it out and let me know what happens. The patch is base
On Sat, 29 Apr 2006 [EMAIL PROTECTED] wrote:
> > We keep hitting these, so I'm wondering if it would be wise
> > to create a unified flag with only 32KB limit. I understand that
> > this would limit the performance more than the 64KB limit which
> > Benjamin used. But perhaps it's something accept
> +static int max_sectors_init (struct us_data *us);
> +
> /* The entries in this table, except for final ones here
> * (USB_MASS_STORAGE_CLASS and the empty entry), correspond,
> * line for line with the entries of us_unsuaul_dev_list[].
> @@ -1071,6 +1073,12 @@ static void * storage_probe(s
On Sat, 29 Apr 2006 21:54:15 +0200, [EMAIL PROTECTED] wrote:
> --- linux-2.6.16/drivers/usb/storage/scsiglue.c 2006-04-29
> 20:59:46.0 +0200
> +++ linux-2.6.16patched/drivers/usb/storage/scsiglue.c2006-04-29
> 20:01:36.0 +0200
> @@ -122,6 +122,13 @@
>
On Sat, 29 Apr 2006 21:54:15 +0200, [EMAIL PROTECTED] wrote:
> +++ linux-2.6.16patched/drivers/usb/storage/scsiglue.c2006-04-29
> 20:01:36.0 +0200
> @@ -122,6 +122,13 @@
> sdev->request_queue->max_sectors > 64)
> blk_queue_max_sectors(sdev->requ
Okay,
I have tried to make a new patch now.
Changes :
- 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
- New device entry for unusual_dev.h with rev id 0x0103 instead
[EMAIL PROTECTED] wrote:
>
>
> Sorry, I wrote this email 3 days ago, but I used the wrong email address :(
No worries. But please use "reply-to-all" so the list is CC'd.
> > I have a few concerns about your patch:
>
> > 1. What makes you think it needs US_FL_FIX_CAPACITY and
> > US_FL_IGN
Alan,
I can confirm that this patch gives us the expected performance from our
USB device.
Regards,
--Chris
-Original Message-
From: Alan Stern [mailto:[EMAIL PROTECTED]
Sent: Monday, April 24, 2006 1:12 PM
To: Pete Zaitcev
Cc: [EMAIL PROTECTED]; Frantz, Chris; linux-usb-devel@lists.
On Mon, 24 Apr 2006, Pete Zaitcev wrote:
> On Mon, 24 Apr 2006 11:55:51 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]>
> wrote:
>
> > Before submitting the patch, it seemed like a good idea to check with you
> > and make sure it doesn't cause any problems. I'd appreciate it if you
> > could try
On Mon, 24 Apr 2006 11:55:51 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> Before submitting the patch, it seemed like a good idea to check with you
> and make sure it doesn't cause any problems. I'd appreciate it if you
> could try it out and let me know what happens. The patch is base
> I have a few concerns about your patch:
> 1. What makes you think it needs US_FL_FIX_CAPACITY and
> US_FL_IGNORE_RESIDUE?
US_FL_FIX_CAPACITY : It didn't work without it, BUT I have opened the disk as
"physical disc"
with Hex Workshop under win xp now, which says the last sector is 3
On Wed, 2006-04-19 at 12:50 -0700, Greg KH wrote:
> On Wed, Apr 19, 2006 at 01:33:52PM +0200, Nicolas Boichat wrote:
> > - dprintk("appletouch: incomplete data package.\n");
> > + dprintk("appletouch: incomplete data package (first byte: %d,
> > length: %d).\n", dev->data[0], d
On Wed, Apr 19, 2006 at 01:33:52PM +0200, Nicolas Boichat wrote:
> - dprintk("appletouch: incomplete data package.\n");
> + dprintk("appletouch: incomplete data package (first byte: %d,
> length: %d).\n", dev->data[0], dev->urb->actual_length);
This line is a bit long, ple
On Tue, Apr 18, 2006 at 05:17:51PM +0200, Stelian Pop wrote:
> Le mardi 18 avril 2006 ?? 21:25 +0900, YOSHIFUJI Hideaki / a
> ??crit :
> > In article <[EMAIL PROTECTED]> (at Tue, 18 Apr 2006 13:07:11 +0200),
> > Nicolas Boichat <[EMAIL PROTECTED]> says:
> >
> > > @@ -147,13 +164,22 @
On Wed, Apr 19, 2006 at 02:15:32AM +0200, [EMAIL PROTECTED] wrote:
> There are some problems with compatibility of the OTi's cable with plain
> PL2303 cable, as noticed by Werner Tuchan ([EMAIL PROTECTED]). Although it is
> claimed on some web pages that the cable is based on pl2303 chip, it turn
There are some problems with compatibility of the OTi's cable with plain PL2303
cable, as noticed by Werner Tuchan ([EMAIL PROTECTED]). Although it is claimed
on some web pages that the cable is based on pl2303 chip, it turned out that it
uses a familiar chip - OTi-6858 - USB To RS232 Bridge Con
In article <[EMAIL PROTECTED]> (at Tue, 18 Apr 2006 13:07:11 +0200), Nicolas
Boichat <[EMAIL PROTECTED]> says:
> @@ -147,13 +164,22 @@ MODULE_PARM_DESC(debug, "Activate debugg
> /* Checks if the device a Geyser 2 (ANSI, ISO, JIS) */
> static inline int atp_is_geyser_2(struct atp *dev)
> {
> -
Le mardi 18 avril 2006 à 21:25 +0900, YOSHIFUJI Hideaki / 吉藤英明 a
écrit :
> In article <[EMAIL PROTECTED]> (at Tue, 18 Apr 2006 13:07:11 +0200), Nicolas
> Boichat <[EMAIL PROTECTED]> says:
>
> > @@ -147,13 +164,22 @@ MODULE_PARM_DESC(debug, "Activate debugg
> > /* Checks if the device a Geyser 2
On Tue, Apr 04, 2006 at 04:22:32PM -0700, Matt Porter wrote:
> This adds in the KPC650 ID to the airprime driver. It also adds the
> ability for the buffer size to be overridden from a driver before
> calling usb_serial_probe() and sets this to 2KB in the airprime wrapper.
> The reason for this is
On Mon, Apr 03, 2006 at 08:11:32PM -0700, Andrew Morton wrote:
> Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, Apr 04, 2006 at 02:00:24AM +0200, Hansjoerg Lipp wrote:
> > > The following series of patches contains updates to the Siemens Gigaset
> > > drivers suggested by various reviewers on l
Greg KH <[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 04, 2006 at 02:00:24AM +0200, Hansjoerg Lipp wrote:
> > The following series of patches contains updates to the Siemens Gigaset
> > drivers suggested by various reviewers on lkml. These should go into
> > 2.6.17 if at all possible. Please apply in
On Tue, Apr 04, 2006 at 02:00:24AM +0200, Hansjoerg Lipp wrote:
> The following series of patches contains updates to the Siemens Gigaset
> drivers suggested by various reviewers on lkml. These should go into
> 2.6.17 if at all possible. Please apply in order.
Hm, the big merge window for 2.6.17 i
On Sunday 02 April 2006 11:20 am, David Brownell wrote:
> This resolves some version skew issues with the AT91 USB support.
... but this version includes a few other fixups to the OHCI code,
so please use it instead.
AT91: the two USB drivers (OHCI, UDC) got out of sync with various
usbcore and
On Wed, Mar 29, 2006 at 09:49:51AM +0200, Guennadi Liakhovetski wrote:
> On Thu, 23 Mar 2006, Alan Stern wrote:
>
> >I tried it with my net2280 card. Everything seems to work just as well
> >with the patch installed as without it.
>
> Great, thanks for testing!
>
> Greg, as far as I understood
On Thu, 23 Mar 2006, Alan Stern wrote:
I tried it with my net2280 card. Everything seems to work just as well
with the patch installed as without it.
Great, thanks for testing!
Greg, as far as I understood from your 2.6.16 git-pull
(http://marc.theaimsgroup.com/?l=linux-kernel&m=11428957872
Alan Stern schrieb:
On Mon, 20 Mar 2006, Willi Mann wrote:
http://wserver.wm1.at/~willi/kernel/kern.log.gz
Currently, I can only reproduce the bug if my mouse and my keyboard are
plugged differently as to the last "boot". I'm not sure if that's always
the case. However, the log shows the -7
On Mon, 20 Mar 2006, Willi Mann wrote:
> http://wserver.wm1.at/~willi/kernel/kern.log.gz
>
> Currently, I can only reproduce the bug if my mouse and my keyboard are
> plugged differently as to the last "boot". I'm not sure if that's always
> the case. However, the log shows the -71 error also w
On Tuesday, 21. March 2006 08:16, Vojtech Pavlik wrote:
> On Mon, Mar 20, 2006 at 11:59:24PM +0100, Bernhard Rosenkraenzer wrote:
> > Add some quirks to make a Shuttle PN-31 remote control work.
>
> Can you send me the #define DEBUG output from hid-core and hid-input?
> I'm quite curious how much b
On Sun, 19 Mar 2006, Guennadi Liakhovetski wrote:
> > Your email client did something wierd with this patch and it can not be
> > applied at all. Care to resend it?
>
> Ouch, sorry... Please, try now. This pine should be better configured. At
> least until now it behaved.
I tried it with my ne
On Mon, Mar 20, 2006 at 11:59:24PM +0100, Bernhard Rosenkraenzer wrote:
> Add some quirks to make a Shuttle PN-31 remote control work.
>
> Shuttle PN31 remote controls are supposed to act as a USB keyboard and mouse,
> but they (in particular the mouse part) don't follow the standards.
>
> 5 qui
On Mon, 20 Mar 2006, Willi Mann wrote:
> Currently, I can only reproduce the bug if my mouse and my keyboard are
> plugged differently as to the last "boot". I'm not sure if that's always
> the case. However, the log shows the -71 error also when the keyboard
> worked (maybe it's from the mouse
Alan Stern schrieb:
On Mon, 20 Mar 2006, Willi Mann wrote:
http://wserver.wm1.at/~willi/kernel/kern.log.gz
I tried to retrieve this file, but your server says I don't have
permission.
Sorry, works now.
Willi
---
This SF.Net email is
On Mon, 20 Mar 2006, Willi Mann wrote:
> http://wserver.wm1.at/~willi/kernel/kern.log.gz
I tried to retrieve this file, but your server says I don't have
permission.
Alan Stern
---
This SF.Net email is sponsored by xPML, a groundbreaking sc
The debugging output from uhci-hcd is overwriting other useful information
in the kernel's log buffer. Let's try getting rid of it and see what
shows up. This patch will remove all that clutter.
Alan Stern
http://wserver.wm1.at/~willi/kernel/kern.log.gz
Currently, I can only reproduce
On Fri, 17 Mar 2006, Greg KH wrote:
> On Fri, Mar 17, 2006 at 02:28:05PM +0100, Guennadi Liakhovetski wrote:
> > Hello all
> >
> > Below is a patch to gadgets/net2280.[ch] which adds support for the
> > net2282 controller. The original code was kindly provided by PLX
> > Technology, I just merg
On Sat, Mar 11, 2006 at 11:29:02AM +, Craig Shelley wrote:
> Hi,
>
> This patch adds a new device ID to the cp2101 driver, and also fixes a
> bug identified by Eric Enright:
> > On line 168 it kmalloc()s some memory, memset()s
> > it, and /then/ checks to see if kmalloc() returned a valid poin
On Fri, Mar 17, 2006 at 02:28:05PM +0100, Guennadi Liakhovetski wrote:
> Hello all
>
> Below is a patch to gadgets/net2280.[ch] which adds support for the
> net2282 controller. The original code was kindly provided by PLX
> Technology, I just merged it with the current net2280 driver in the
> k
On Tue, 2006-03-14 at 23:04 +0100, Oliver Neukum wrote:
> > What Paul needs to track is the refcount for acm->dev. It should be
> > incremented and decremented appropriately -- which means that acm->dev had
> > better not be NULL when acm_tty_unregister runs.
>
> The devices's control interface
Am Dienstag, 14. März 2006 22:47 schrieb Alan Stern:
> On Tue, 14 Mar 2006, Oliver Neukum wrote:
>
> > Am Dienstag, 14. März 2006 22:24 schrieb Alan Stern:
> > > On Tue, 14 Mar 2006, Alan Stern wrote:
> > >
> > > > > > acm_tty_close tty=cd254af8 filp=ce96511c acm=ce24eca0
> > > > > > acm_tty_clos
On Tue, 14 Mar 2006, Oliver Neukum wrote:
> Am Dienstag, 14. März 2006 22:24 schrieb Alan Stern:
> > On Tue, 14 Mar 2006, Alan Stern wrote:
> >
> > > > > acm_tty_close tty=cd254af8 filp=ce96511c acm=ce24eca0
> > > > > acm_tty_close acm->used=1 acm->dev=
> > > > atm_tty_close called from t
On Tue, 2006-03-14 at 16:18 -0500, Alan Stern wrote:
> The disconnect routine shouldn't need to set acm->dev to NULL. The fact
> that the first disconnect has already occurred can be detected by the fact
> that acm = usb_get_intfdata(intf) will itself be NULL.
>
> Will everything work if you sim
Am Dienstag, 14. März 2006 22:24 schrieb Alan Stern:
> On Tue, 14 Mar 2006, Alan Stern wrote:
>
> > > > acm_tty_close tty=cd254af8 filp=ce96511c acm=ce24eca0
> > > > acm_tty_close acm->used=1 acm->dev=
> > > atm_tty_close called from tty_io.c:release_dev()
> > > acm->used=1 on entry, decre
On Tue, 14 Mar 2006, Alan Stern wrote:
> > > acm_tty_close tty=cd254af8 filp=ce96511c acm=ce24eca0
> > > acm_tty_close acm->used=1 acm->dev=
> > atm_tty_close called from tty_io.c:release_dev()
> > acm->used=1 on entry, decrements to zero == final close
> > acm->dev is NULL (unplugged) so
On Tue, 14 Mar 2006, Paul Fulghum wrote:
> > usb 1-2: USB disconnect, address 6
> Unplug detected
>
> > acm_disconnect intf=ce99f720 acm=ce24eca0 usb_dev=ce24f4b8
> > acm_disconnect acm->used=1 acm->dev=ce24f4b8 acm->tty=cd254af8
> acm_disconnect
> acm->used is 1 (tty open, defer acm_tty_unregist
Am Dienstag, 14. März 2006 20:29 schrieb Paul Fulghum:
> > acm_disconnect intf=cefb6760 acm= usb_dev=ce24f4b8
> acm_disconnect, no interface data so do nothing (why no data?)
That's the second (data) interface. It is disconnected anyway,
so we ignore it. This is necessary to handle disconn
On Tue, 2006-03-14 at 10:40 -0800, Greg KH wrote:
> Well, we have a "used" count that is trying to handle the cleanup
> properly for us when we have the port open yet it is gone already. But
> it really would be easier to reference count the whole thing, but I'll
> wait for what you find out with
On Tue, Mar 14, 2006 at 12:07:54PM -0600, Paul Fulghum wrote:
> On Tue, 2006-03-14 at 09:05 -0800, Greg KH wrote:
> > Ah, wait, that's the issue right there. You need to increment the
> > reference count of the object on open and then decrement it on close.
> > That way the last close will drop th
On Tue, 2006-03-14 at 09:05 -0800, Greg KH wrote:
> Ah, wait, that's the issue right there. You need to increment the
> reference count of the object on open and then decrement it on close.
> That way the last close will drop the last reference, and you do that
> _after_ the tty cleanup.
acm_prob
On Tue, Mar 14, 2006 at 09:58:52AM -0600, Paul Fulghum wrote:
> On Tue, 2006-03-14 at 10:42 -0500, Alan Stern wrote:
> > Psul, the best way to approach a problem like this is by massive debugging
> > printks.
>
> That's what I have been doing, and I just posted another
> such patch for Bob to tes
On Tue, 2006-03-14 at 10:42 -0500, Alan Stern wrote:
> Psul, the best way to approach a problem like this is by massive debugging
> printks.
That's what I have been doing, and I just posted another
such patch for Bob to test. I don't have any of the
equipment to test this myself, so I am relying
On Mon, 13 Mar 2006, Paul Fulghum wrote:
> Pete Zaitcev wrote:
> > On Mon, 13 Mar 2006 16:31:35 -0600, Paul Fulghum <[EMAIL PROTECTED]> wrote:
> >
> >
> > sysfs_remove_link(&class_dev->kobj, "device");
> > sysfs_remove_link(&class_dev->dev->kobj, class_name);
> >
> >
>
Pete Zaitcev wrote:
On Mon, 13 Mar 2006 16:31:35 -0600, Paul Fulghum <[EMAIL PROTECTED]> wrote:
sysfs_remove_link(&class_dev->kobj, "device");
sysfs_remove_link(&class_dev->dev->kobj, class_name);
The second one is probably where it dies. We only hold the int
On Mon, Mar 13, 2006 at 03:01:45PM -0800, Pete Zaitcev wrote:
> On Mon, 13 Mar 2006 16:31:35 -0600, Paul Fulghum <[EMAIL PROTECTED]> wrote:
>
> > >>> sysfs_remove_link(&class_dev->kobj, "device");
> > >>> sysfs_remove_link(&class_dev->dev->kobj, class_name);
>
> The second one is
On Mon, 13 Mar 2006 16:31:35 -0600, Paul Fulghum <[EMAIL PROTECTED]> wrote:
> >>> sysfs_remove_link(&class_dev->kobj, "device");
> >>> sysfs_remove_link(&class_dev->dev->kobj, class_name);
The second one is probably where it dies. We only hold the interface,
but not the device
1 - 100 of 6113 matches
Mail list logo
