Greg,
You are right ( of course ), but using the buffer given by the usb-serial
seems to bo logic as I said.
By this way I don't create unnecessary buffer. But in bulk transfer, the
buffer_size can be greater than
The value given by the endpoint. The usb lowlevel will split the bulk
tranfsert.
So
On Tue, Jul 31, 2007 at 07:13:08AM +0200, Alain Degreffe wrote:
> Well I try to follow pl2303
>
> wMaxPacketSize 0x0040 1x 64 bytes is the size retuned by the endpoint
> (I just plug my own pl2303 to check the value)
>
> line / code
>
> 330 priv->buf = pl2303_buf_alloc(PL230
OOps I just see now the usage of
port->bulk_out_size that of course is limited to 64 bytes in this case...
Sorry for the noise.
Alain
Line 377: count = pl2303_buf_get(priv->buf,
port->write_urb->transfer_buffer,
port->bulk_out_size);
-Message d'origine-
De : [EMAIL PROTECTED]
[mailt
On Mon, Jul 30, 2007 at 02:00:25PM -0700, Pete Zaitcev wrote:
> On Mon, 30 Jul 2007 13:07:02 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Mon, Jul 30, 2007 at 12:58:57PM -0700, Pete Zaitcev wrote:
>
> > > Oliver converted CmdUrbs into an atomic with commit
> > > 96c706ed1c46470598d785124b2a7fb
Well I try to follow pl2303
wMaxPacketSize 0x0040 1x 64 bytes is the size retuned by the endpoint
(I just plug my own pl2303 to check the value)
line / code
330 priv->buf = pl2303_buf_alloc(PL2303_BUF_SIZE); where
PL2303_BUF_SIZE = 1024 !
377 count = pl2303_buf_get
On Monday 30 July 2007, Alan Stern wrote:
> +static inline int usb_urb_dir_in(struct urb *urb)
> +{
> + return (urb->transfer_flags & URB_DIR_MASK) != URB_DIR_OUT;
> +}
Clearer would be: == URB_DIR_IN ... or does that generate bad code?
On Monday 30 July 2007, Alan Stern wrote:
> /* power of two? */
> - while (temp > urb->interval)
> - temp >>= 1;
> - urb->interval = temp;
> + while (max > urb->interval)
> + max >>= 1;
> +
On Mon, 30 Jul 2007, Kostas Peletidis wrote:
> Hi all,
>
> I would like to report a problem I have noticed since linux-2.6.22 that
> most likely has to do with the USB subsystem.
>
> I have tried both kernel versions 2.6.22 and 2.6.22.1(configured with
> make oldconfig) and in both cases whene
On Mon, 30 Jul 2007 17:06:16 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> --- usb-2.6.orig/drivers/usb/core/urb.c
> +++ usb-2.6/drivers/usb/core/urb.c
> @@ -309,7 +309,21 @@ int usb_submit_urb(struct urb *urb, gfp_
> xfertype = usb_endpoint_type(&ep->desc);
> - is_out = usb_pipeo
Signed-off-by: Matthew Dharm <[EMAIL PROTECTED]>
On Tue, Jul 31, 2007 at 12:28:22AM +0200, Adrian Bunk wrote:
> The Coverity checker spotted that we have already oops'ed if "us"
> was NULL.
>
> Since "us" can't be NULL in the only caller this patch removes the
> NULL check.
>
> Signed-off-by: Ad
On Mon, 30 Jul 2007 18:09:23 -0400 (EDT)
Alan Stern <[EMAIL PROTECTED]> wrote:
> On Mon, 30 Jul 2007, Gabriel C wrote:
>
> > A. Kalten wrote:
> > [ added usb peoples to CC ]
> > > Hello,
> > >
> > > To send a fax using an external usb modem, I do the following:
> > >
> > > modprobe uhci-hcd
> >
On Mon, Jul 30, 2007 at 06:04:06PM +0200, [EMAIL PROTECTED] wrote:
> Greg,
>
> It is a problem because I use the pre-allocated buffer given by the layer
> usb-serial. Of course, I can create a new urb structure with a bigger
> buffer but I just suggest that using the buffer stored in the
> usb_se
On Mon, Jul 30, 2007 at 07:04:51AM +0200, [EMAIL PROTECTED] wrote:
> Hi Greg,
>
>
>
> After a new complete reading of my code against usb-serial.c, I finally
> found ( I hope ) my problem.
>
> In usb-serial.c, when bulk_in/out buffers are initialized, each buffer size
> are the same as the wM
Did you change any USB-related compile options between the two builds?
Do you have usb device suspend enabled?
Can you tell (via top) where the 100% CPU usage is coming from (i.e. df,
usb-storage thread, syswait, etc)?
Matt
On Mon, Jul 30, 2007 at 11:24:27PM +0100, Kostas Peletidis wrote:
> Hi
The Coverity checker spotted that we have already oops'ed if "us"
was NULL.
Since "us" can't be NULL in the only caller this patch removes the
NULL check.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
--- linux-2.6.23-rc1-mm1/drivers/usb/storage/shuttle_usbat.c.old
2007-07-30 16:56:
Hi all,
I would like to report a problem I have noticed since linux-2.6.22 that
most likely has to do with the USB subsystem.
I have tried both kernel versions 2.6.22 and 2.6.22.1(configured with
make oldconfig) and in both cases whenever I plug in a fairly
large(500GB) MyBook usb2 hard disk d
On Mon, 30 Jul 2007 17:04:37 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> @@ -1149,10 +1148,6 @@ int usb_hcd_unlink_urb (struct urb *urb,
> return -EINVAL;
> if (!urb->dev || !urb->dev->bus)
> return -ENODEV;
> - ep = (usb_pipein(urb->pipe) ? urb->dev->
On Sun, Jul 29, 2007 at 05:31:12PM -0400, Robert P. J. Day wrote:
>
> i think someone higher up the food chain might want to handle what
> appear to be typoes here:
>
> $ grep -r SAFE_SERIAL *
> drivers/usb/serial/safe_serial.c:#if defined(CONFIG_USBD_SAFE_SERIAL_VENDOR)
> && !defined(CONFIG_U
On Sun, Jul 29, 2007 at 08:00:01PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 27 Jul 2007, Alan Stern wrote:
> >
> > I don't think it's a refcounting problem. My guess is that the
> > underlying cause is the bug in your urb->status removal patch for
> > usb_start_wait_urb() -- the one I fixed
From: David Brownell <[EMAIL PROTECTED]>
This removes complaints about the gadget stack which are generated by
the currrent "sparse": it doesn't like the fact that zero is the null
pointer. (Last I checked, C guarantees that's correct ...)
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Signe
From: Adam Kropelin <[EMAIL PROTECTED]>
Fix serious regression on non-EPiC edgeport usb-serial devices. Baud
rate and MCR/LCR registers are not being written on these models due
to apparent copy-n-paste errors introduced with EPiC support.
Failure reported by Nick Pasich <[EMAIL PROTECTED]>.
Sig
From: David Brownell <[EMAIL PROTECTED]>
Remove some more dead code from the pxa2xx_udc driver: support
for a no-longer-undocumented hardware "test mode". Newer chips
made this the default, evidently as the best workaround for deep
silicon bugs. The interest was that this seemed to be the only
From: Milinevsky Dmitry <[EMAIL PROTECTED]>
This short patch allows NIKON D50 to be mounted as UMS[unusual device]
on Linux niam 2.6.22-rc7-cfs-v18 #2 PREEMPT Tue Jul 3 22:35:53 EEST
2007 i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel
GNU/Linux,
some previous kernels...
lsusb -v
Bus 00
From: Adrian Bunk <[EMAIL PROTECTED]>
This patch makes three needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Cc: Kevin Lloyd <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/serial/sierra.c |7 ---
1 files change
From: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Acked-by: Pete Zaitcev <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/serial/mct_u232.c | 54
drivers/usb/serial/mct_u232.h |2 +
From: Oliver Neukum <[EMAIL PROTECTED]>
Clearly there's a bug in
drivers/usb/serial/usb-serial.c:usb_serial_put(). It shouldn't call
kref_put() while holding a spinlock.
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/serial
From: Alan Cox <[EMAIL PROTECTED]>
- The outbreak of acute bracketitus has been cured
- The belief that brackets should have spaces everywhere likewise
- Various other coding style tweaks
- Use baud rates not Bfoo in the speed setup switch
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by
From: Alan Cox <[EMAIL PROTECTED]>
I've also enabled the commented out support for 7200, 14400, 55854,
127117 and 3686400 baud as you can now set such rates in the kernel.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/serial/cp2
From: Alan Stern <[EMAIL PROTECTED]>
This patch (as941) fixes a bug recently added to the USB synchronous
API. The status of a completed URB must be preserved separately
across a completion callback. Also, the actual_length value isn't
available until after the URB has fully completed.
Signed-o
From: David Brownell <[EMAIL PROTECTED]>
Update the scatterlist logic so that PIO options are also disabled
when an IOMMU may have coalesced pages during dma_map_sg() ... it's
not just HIGHMEM that can make trouble supporting both PIO and DMA
based host controller drivers.
There also seems to be
From: Oliver Neukum <[EMAIL PROTECTED]>
Am Montag 23 Juli 2007 schrieb Adrian Bunk:
> Commit ec22559e0b7a05283a3413bda5d177e42c950e23 added the following
> function to drivers/usb/serial/usb-serial.c:
>
[..]
>
> The Coverity checker spotted the inconsequent NULL checking for "serial".
>
> Looking
From: Oliver Neukum <[EMAIL PROTECTED]>
another quirky scanner.
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/core/quirks.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/core/quirks.c
From: Johann Felix Soden <[EMAIL PROTECTED]>
This patch adds CanoScan N1240U/LiDE30 (Scanner) to the list of quirky USB
devices.
Signed-off-by: Johann Felix Soden <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/core/quirks.c |2 ++
1 files changed, 2
From: Oliver Neukum <[EMAIL PROTECTED]>
The number of quirky devices seems to be large.
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/core/quirks.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --g
From: Randy Dunlap <[EMAIL PROTECTED]>
Add kernel-doc entries in for:
Warning(linux-2.6.22-git12//include/linux/usb.h:162): No description found for
parameter 'intf_assoc'
Warning(linux-2.6.22-git12//include/linux/usb.h:268): No description found for
parameter 'intf_assoc[USB_MAXIADS]'
Signed
From: Oliver Neukum <[EMAIL PROTECTED]>
our list of devices which cannot be suspended keeps growing.
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/core/quirks.c | 10 ++
1 files changed, 10 insertions(+), 0 deleti
From: Jeremy Katz <[EMAIL PROTECTED]>
The Blackberry Pearl can run in two modes; a usb-storage only mode
and a mode that allows access via mass storage and to its database.
The berry_charge module will set the device to dual mode and thus we
should ignore its native mode if that module is built
S
From: Juergen Beisert <[EMAIL PROTECTED]>
Trivial patch to build the IOWARRIOR when it is selected in Kconfig.
Signed-off-by: Juergen Beisert <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/Makefile |1 +
1 files changed, 1 insertions(+), 0 deletions
On Mon, 30 Jul 2007, Gabriel C wrote:
> A. Kalten wrote:
> [ added usb peoples to CC ]
> > Hello,
> >
> > To send a fax using an external usb modem, I do the following:
> >
> > modprobe uhci-hcd
> > modprobe cdc-acm
> > mount -t usbfs none /proc/bus/usb
> >
> > Then I send the fax.
> >
> > How
Here are some USB fixes against your 2.6.23-rc1 git tree.
They do the following:
- usb core fix that you ran into with your broken usb-storage
device
- tty fixes (one fix included a big coding style cleanup by Alan
Cox, which dominates the diffstat of this serie
A. Kalten wrote:
[ added usb peoples to CC ]
> Hello,
>
> To send a fax using an external usb modem, I do the following:
>
> modprobe uhci-hcd
> modprobe cdc-acm
> mount -t usbfs none /proc/bus/usb
>
> Then I send the fax.
>
> However, when I attempt to unload the modules by reversing
> the abo
This patch (as949) changes the usbmon driver to use the new urb->ep
field rather than urb->pipe.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
cc: Pete Zaitcev <[EMAIL PROTECTED]>
---
Index: usb-2.6/drivers/usb/mon/mon_bin.c
===
---
This patch (as948) removes most of the references to urb->pipe from
the usbfs routines in devio.c. The one tricky aspect is in
snoop_urb(), which can be called before the URB is submitted and which
uses usb_urb_dir_in(). For this to work properly, the URB's direction
flag must be set manually in
This patch (as947) changes the device initialization and enumeration
code in hub.c; now udev->devnum will be set to 0 while the device is
being accessed at address 0. Until now this wasn't needed because the
address value was passed as part of urb->pipe; without that field the
device address must
This patch (as946) eliminates many of the uses of urb->pipe in
usbcore. Unfortunately there will have to be a significant API
change, affecting all USB drivers, before we can remove it entirely.
This patch contents itself with changing only the interface to
usb_buffer_map_sg() and friends: The pip
This patch (as945) adds a bit to urb->transfer_flags for recording the
direction of the URB. The bit is set/cleared automatically in
usb_submit_urb() so drivers don't have to worry about it (although as
a result, it isn't valid until the URB has been submitted). Inline
routines are added for easi
This patch (as944) adds an explicit "enabled" field to the
usb_host_endpoint structure and uses it in place of the current
mechanism. This is merely a time-space tradeoff; it makes checking
whether URBs may be submitted to an endpoint simpler. The existing
mechanism is efficient when converting u
This patch (as943) prepares the way for eliminating urb->pipe by
introducing an endpoint pointer into struct urb. For now urb->ep
is set by usb_submit_urb() from the pipe value; eventually drivers
will set it themselves and we will remove urb->pipe completely.
The patch also adds new inline routi
It seems to happen quite often that trying to make one change ends up
requiring changes to a whole bunch of other things first. That's my
situation now.
Ultimately I want to remove references to urb->status from the HCDs and
usbcore. This turned out to be complicated by the need to unlink URBs
On Mon, 30 Jul 2007 13:07:02 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 30, 2007 at 12:58:57PM -0700, Pete Zaitcev wrote:
> > Oliver converted CmdUrbs into an atomic with commit
> > 96c706ed1c46470598d785124b2a7fb233b27dab .
> > It seems like a waste to do for a long forgotten debuggi
Sehr geehrte Damen und Herren,
in dem E-Mail mit dem Betreff '[linux-usb-devel] You've received a postcard
from a Mate!'
(gesendet am Mon, 30 Jul 2007 16:26:52 -0400) mit der angegebenen
Absenderadresse '"hallmark.com" <[EMAIL PROTECTED]>' wurde der
Virus 'Email.Phishing.RB-1222' gefunden.
Aus di
On Mon, Jul 30, 2007 at 12:58:57PM -0700, Pete Zaitcev wrote:
> Oliver converted CmdUrbs into an atomic with commit
> 96c706ed1c46470598d785124b2a7fb233b27dab .
> It seems like a waste to do for a long forgotten debugging aid.
> Let's just remove it altogether.
Nah, as someone who has had to debug
Oliver converted CmdUrbs into an atomic with commit
96c706ed1c46470598d785124b2a7fb233b27dab .
It seems like a waste to do for a long forgotten debugging aid.
Let's just remove it altogether.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
diff --git a/drivers/usb/serial/io_edgeport.c b/drivers/u
On Sun, Jul 29, 2007 at 11:03:29AM -0400, Adam Kropelin wrote:
> Fix serious regression on non-EPiC edgeport usb-serial devices. Baud
> rate and MCR/LCR registers are not being written on these models due
> to apparent copy-n-paste errors introduced with EPiC support.
>
> Failure reported by Nic
This removes complaints about the gadget stack which are generated by
the currrent "sparse": it doesn't like the fact that zero is the null
pointer. (Last I checked, C guarantees that's correct ...)
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/usb/gadget/config.c |2 +-
On Thursday 26 July 2007, Srinivas rao wrote:
> Now I need a linux application for 4 or more bulk endpoints because my
> device
> controller supports 6bulk endpoints.
Why would you "need" that?
> Please any one suggest me for multiple endpoints application.
Composite devices of course.
This is a note to let you know that I've just added the patch titled
Subject: USB: fix BUG: sleeping function called from invalid context at
/home/jeremy/hg/xen/paravirt/linux/drivers/usb/core/urb.c:524, in_atomic():1,
irqs_disabled():0
to my gregkh-2.6 tree. Its filename is
usb-f
This is a note to let you know that I've just added the patch titled
Subject: USB: Fix a bug in usb_start_wait_urb
to my gregkh-2.6 tree. Its filename is
usb-fix-a-bug-in-usb_start_wait_urb.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gre
On Mon, Jul 23, 2007 at 08:19:10PM +0200, Hermann Kneissel wrote:
>
> This patch contains two fixes submitted by Ondrej Palkovsky:
> - the 'ACK' packet is sent after the transfer of the USB packet is
> completed, i.e. in the write_callback function. Because the close
> function sends the 'abort'
On Monday 30 July 2007, Oliver Neukum wrote:
>
> > But -- never actually having had both a highspeed USB sniffer *AND*
> > hardware exhibiting this problem in the same place -- I've not been
> > able to test that theory.
>
> The hub in question is light and small. Give me your address and I'll
>
On Mon, 30 Jul 2007, Alex Chiang wrote:
> Hello,
>
> How are ports numbered/ordered in the case of an EHCI controller
> with a companion controller?
>
> Example: N_PORTS = 6
>
> AND
> N_CC = 2
> N_PCC = 3
>
> ORPORTROUTE[] = 1,1,1,2,2,2
>
> Would give a routing co
On Mon, 30 Jul 2007, Felipe Balbi wrote:
> On 7/30/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> > On Mon, 30 Jul 2007, Felipe Balbi wrote:
> > Lucio's problem is that the device has _already_ disconnected.
> > Getting an additional disconnect interrupt won't make any difference.
>
> yeah... off co
On Mon, 30 Jul 2007 17:29:56 +0200, Lucio Crusca <[EMAIL PROTECTED]> wrote:
> The only solution I've found in such cases is to unplug and replug the
> dongle (even a few reboot cycles aren't enough). However that solution is
> not acceptable for me, since the systems should run unattended.
> Do y
On Mon, 30 Jul 2007, Gabriel C wrote:
> Hi,
>
> I noticed the following warnings with a randconfig (
> http://194.231.229.228/git-current/randconfig-auto-34 ):
>
> ...
>
> CC [M] drivers/usb/gadget/dummy_hcd.o
> drivers/usb/gadget/dummy_hcd.c:37:1: warning: "DEBUG" redefined
> : warning: thi
Hello,
How are ports numbered/ordered in the case of an EHCI controller
with a companion controller?
Example: N_PORTS = 6
AND
N_CC = 2
N_PCC = 3
ORPORTROUTE[] = 1,1,1,2,2,2
Would give a routing configuration of:
EHCI port 1 = OHCI1 port 1 (not 2 or 3)
EHCI p
On Monday 30 July 2007, Boris Losev wrote:
> I've got the APC Back-UPS CS 650 and Debian Etch with the kernel
> 2.6.18-4-686. I've tried to connect my UPS to PC via USB cable and got
> the errors:
>
> usb 2-1: new low speed USB device using ohci_hcd and address 14
> usb 2-1: device not accepting
On Mon, 30 Jul 2007, Boris Losev wrote:
> Hi All!
>
>
> I've got the APC Back-UPS CS 650 and Debian Etch with the kernel
> 2.6.18-4-686. I've tried to connect my UPS to PC via USB cable and got
> the errors:
>
> usb 2-1: new low speed USB device using ohci_hcd and address 14
> usb 2-1: device
Hi,
I noticed the following warnings with a randconfig (
http://194.231.229.228/git-current/randconfig-auto-34 ):
...
CC [M] drivers/usb/gadget/dummy_hcd.o
drivers/usb/gadget/dummy_hcd.c:37:1: warning: "DEBUG" redefined
: warning: this is the location of the previous definition
CC driv
On Monday 30 July 2007, Alan Stern wrote:
> > Maybe if he echo'es correctly on sysfs, he could achieve this...
>
> Nope. You cannot turn off the USB bus power on the computer's USB
> ports no matter what you do; the hardware doesn't permit it.
It does on some systems. Rarely on PCs though.
On 7/30/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Mon, 30 Jul 2007, Felipe Balbi wrote:
> Lucio's problem is that the device has _already_ disconnected.
> Getting an additional disconnect interrupt won't make any difference.
yeah... off course :-p
>
> > Maybe if he echo'es correctly on sysfs
Hi All!
I've got the APC Back-UPS CS 650 and Debian Etch with the kernel
2.6.18-4-686. I've tried to connect my UPS to PC via USB cable and got
the errors:
usb 2-1: new low speed USB device using ohci_hcd and address 14
usb 2-1: device not accepting address 14, error -71
usb 2-1: new low speed
To Andrzej Zaborowski: thanks for testing. According to your log, the
problems started when async_wrap_skb() ran out of space to store the
wrapped frame, because my driver allocated a buffer that was too small.
The attached version should fix that by allocating 2048 bytes for the
wrapped buffer.
-
On Mon, 30 Jul 2007, Felipe Balbi wrote:
> Hi,
>
> On 7/30/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> > On Mon, 30 Jul 2007, Lucio Crusca wrote:
> > There is no way to simulate unplug/replug from software for devices
> > attached directly to the computer. However it is possible for devices
> >
Hi,
On 7/30/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Mon, 30 Jul 2007, Lucio Crusca wrote:
> There is no way to simulate unplug/replug from software for devices
> attached directly to the computer. However it is possible for devices
> plugged into some brands of hub. See this web page:
Wo
On Mon, Jul 30, 2007 at 05:21:08PM +0200, GW wrote:
> PCI quirk to unhide SMBus on Compaq Deskpro EP 401963-001 (PCA# 010174)
> motherboard with i810 chipset.
>
> Signed-off-by: GW <[EMAIL PROTECTED]>
Hm, can I get more of a "real name" for this please?
thanks,
greg k-h
--
Greg,
It is a problem because I use the pre-allocated buffer given by the layer
usb-serial.
Of course, I can create a new urb structure with a bigger buffer but I just
suggest that
using the buffer stored in the usb_serial_device seems to be logic and like
a said, other driver use it without chec
On Mon, 30 Jul 2007, Lucio Crusca wrote:
> Hello *,
>
> I have a problem with bluetooth USB dongles.
>
> Scenario: a number of unattended systems have a USB bluetooth dongle that
> send files to nearby bluetooth devices. The systems are built on top of
> Debian GNU/Linux Etch i386 and use obexf
I know the 2.6.23 merge window is already closed, but the previous
version of the driver allocates insufficient space for a possible TX
frame. Andrzej Zaborowski sent me a log in which an IrDA wrapping
overflow occurs, with max expected frame at 512 bytes, so more is needed.
---
On Mon, 30 Jul 2007, Rajesh Srinivasan wrote:
> Hi,
>
> Have anyone come across this problem? Can you give me any pointers.. in
> file_storage, vfs_read (during READ-10) returns 0 bytes read. No Errors,
> but No datas read either.
That's normal behavior when a read encounters end-of-file.
Hi,
Have anyone come across this problem? Can you give me any pointers.. in
file_storage, vfs_read (during READ-10) returns 0 bytes read. No Errors,
but No datas read either.
Thanks & Regards
Rajesh
*** Aricent-Private ***
"DISCLAIMER: This messa
Hi Lucio,
On 7/30/07, Lucio Crusca <[EMAIL PROTECTED]> wrote:
> Hello *,
>
> I have a problem with bluetooth USB dongles.
>
> Scenario: a number of unattended systems have a USB bluetooth dongle that
> send files to nearby bluetooth devices. The systems are built on top of
> Debian GNU/Linux Etch
Hello *,
I have a problem with bluetooth USB dongles.
Scenario: a number of unattended systems have a USB bluetooth dongle that
send files to nearby bluetooth devices. The systems are built on top of
Debian GNU/Linux Etch i386 and use obexftp 0.19 to send files.
Sometimes it happens that someth
Am Montag 30 Juli 2007 schrieb Paulo da Silva:
> Oliver Neukum escreveu:
> > ...
>
> > Please get a stack trace with the t variety of the alt-sysrq you use to
> > reboot
> > and post that.
> >
> >
>
>
> I read the sysrq.txt and saw that 't' sends the output to the console!
> As I said, I don
PCI quirk to unhide SMBus on Compaq Deskpro EP 401963-001 (PCA# 010174)
motherboard with i810 chipset.
Signed-off-by: GW <[EMAIL PROTECTED]>
---
Patch is for kernel source 2.6.21 with Debian patches.
Seems to work fine with no conflicts.
Motherboard identification based on host bridge device i
Oliver Neukum escreveu:
> ...
> Please get a stack trace with the t variety of the alt-sysrq you use to reboot
> and post that.
>
>
I read the sysrq.txt and saw that 't' sends the output to the console!
As I said, I don't have any echo from what I type.
1. The keyboard freezes or seems to fre
On Mon, Jul 30, 2007 at 07:10:55AM +0200, [EMAIL PROTECTED] wrote:
> Hi Greg,
>
> After a new complete reading of my code against usb-serial.c, I finally
> found ( I hope ) my problem.
> In usb-serial.c, when bulk_in/out buffers are initialized, each ?buffer size
> are the same as the wMaxPacketSi
On Monday, 30. July 2007, Jiri Kosina wrote:
> On Fri, 27 Jul 2007, Christian Lamparter wrote:
>
> > Some of ASUS' notebooks (e.g G Series) include a tiny oled display, which
> > is
> > attached to an internal USB bus. Unfortunatly the device reports a wrong
> > DeviceDescriptor and is therefore
On Fri, 27 Jul 2007, Christian Lamparter wrote:
> Some of ASUS' notebooks (e.g G Series) include a tiny oled display, which is
> attached to an internal USB bus. Unfortunatly the device reports a wrong
> DeviceDescriptor and is therefore identified as a HID device...
Hi Christian,
I have slight
Mon, 30 Jul 2007 14:41:45 +0500:
Herbal- \/ 1 A G R A - a Natural cure for imp0tence.
Do you have any Problem in Getting & Maintaining Erection??
Get rock hard in just 15 mins with Herbal- \/ 1 A G R A -
http://hvhokarkajan.blogspot.com/
Unlike Vi g r a or Cia li s, Herbal-V has No Side Ef
No need to split.
This is just what I need :-)
Thanks a lot.
Alain
-Message d'origine-
De : Oliver Neukum [mailto:[EMAIL PROTECTED]
Envoyé : lundi 30 juillet 2007 14:18
À : [EMAIL PROTECTED]
Cc : linux-usb-devel@lists.sourceforge.net
Objet : Re: [linux-usb-devel] usb-serial.c question
Am Montag 30 Juli 2007 schrieb [EMAIL PROTECTED]:
> This is quite dangerous :-)
>
> You can't apply a user requested buffer_size to interrupt_buffer !
>
> The API should only apply the buffer size to bulk buffers...
Right you are. What about this? Or do you need split sizes
for input and output?
This is quite dangerous :-)
You can't apply a user requested buffer_size to interrupt_buffer !
The API should only apply the buffer size to bulk buffers...
Alain
-Message d'origine-
De : Oliver Neukum [mailto:[EMAIL PROTECTED]
Envoyé : lundi 30 juillet 2007 12:45
À : linux-usb-devel@li
Am Samstag 28 Juli 2007 schrieb David Brownell:
> On Friday 27 July 2007, Alan Stern wrote:
> > In my experience this sort of thing tends to be caused by low-level
> > hardware communications errors. Noise in the USB data lines or a
> > missing handshake packet, stuff like that. Not much extra d
Am Montag 30 Juli 2007 schrieb [EMAIL PROTECTED]:
> Hi Greg,
>
> After a new complete reading of my code against usb-serial.c, I finally
> found ( I hope ) my problem.
> In usb-serial.c, when bulk_in/out buffers are initialized, each buffer size
> are the same as the wMaxPacketSize given by the e
Fix typo in safe_serial.c to match the actual CONFIG variable.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/drivers/usb/serial/safe_serial.c b/drivers/usb/serial/safe_serial.c
index 86899d5..51669b7 100644
--- a/drivers/usb/serial/safe_serial.c
+++ b/drivers/usb/serial/s
Hi,
another quirky scanner.
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
---
--- a/drivers/usb/core/quirks.c 2007-07-30 12:04:44.0 +0200
+++ b/drivers/usb/core/quirks.c 2007-07-30 12:05:21.0 +0200
@@ -52,6 +52,8 @@ static const struct us
On Wed, 25 Jul 2007, Phil Dibowitz wrote:
> This patch adds the entire range of Logitech's ProductIDs that are reserved
> for their Harmony remotes. The in-kernel HID driver can't do anything with
> these, and now there is a GPL user-space application that can handle them:
> http://www.sf.net/pr
Forget this :-)
All my problem came from the usage of a buffer inialized by usb-serial.c that
is too small for my module.. So I was writing or reading outside the memory
allocation dedicated to the urb structure
Alain
-Message d'origine-
De : Oliver Neukum [mailto:[EMAIL PROTECTED
On Tue, 17 Jul 2007, Greg KH wrote:
> > autosuspend for USB HID devices remains problematic as far as mice and
> > keyboards are concerned. While I am working on a grand solution,
> > here's a minimalist patch that works for those devices not continously
> > in use. It'll work for joystick and
On Mon, 30 Jul 2007, Petko Manolov wrote:
> On Sun, 29 Jul 2007, Oliver Neukum wrote:
>
> > [...]
> > pegasus == NULL there would be a kernel bug. Silently ignoring
> > it, like the code now wants to do is bad. As the oops has never been
> > reported, I figure turning it into an explicit debugg
1 - 100 of 105 matches
Mail list logo
