On Wednesday 01 June 2005 11:42 pm, Greg KH wrote:
>
> Rumor has it that a certian big chip company has been working on Linux
> drivers to support this. Hopefully they will start showing up soon
> (hint, hint, hint...)
:)
> Want me to apply your patch? Can't hurt :)
Can't hurt; sure, go ahead
On Tue, May 31, 2005 at 04:47:58PM +0530, Annamalai Prakash (Tata Elxsi) wrote:
> Hi List,
>
> I am tring to communicate with my Bluetooth USB dongle (BT5000U
> from silicom Wave) through Linux USB Bluetooth TTY driver. I am using
> 2.4.19-rmk7-ds3 arm Kernel. I have
> USB support.
On Tue, May 31, 2005 at 10:21:11AM -0700, David Brownell wrote:
> Last week the "Wireless USB" spec was published. So naturally I was
> curious what would be involved in having Linux work with it, whenever
> hardware becomes available. This will be using low power short-range
> radios to get rid
位于沈阳的辽沈地区最大的军事爱国类网站--中盟网
现在正在招收斑竹和管理员，欢迎大家报名
同时欢迎本地区的各兄弟网站友情连接！！
政治家的休闲空间，军事爱好者的讨论平台，所有爱国者的家--中盟网！
欢迎访问 http://www.upocn.com
我们有最权威的、最准确的情报资料、全球卫星图片欢迎欣赏！
---
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Netwo
On Wednesday 01 June 2005 8:03 pm, [EMAIL PROTECTED] wrote:
> I read Documentation/SubmittingPatches and came up with the attached pach
> file.
> It's against the 2.6.12-rc5 tree. Is posting it here sufficient?
You skipped step 11 -- no "Signed-Off-By". Other than that, and the
lack of a patch
On Wed, 1 Jun 2005, David Brownell wrote:
On Wednesday 01 June 2005 7:12 pm, [EMAIL PROTECTED] wrote:
On Wed, 1 Jun 2005, David Brownell wrote:
And in fact, the real issue looks to be that it's only comparing ONE of the
GUIDs, not both ... :(
Try tweaking "usbnet.c" near line 2768 ... change o
On Wednesday 01 June 2005 7:12 pm, [EMAIL PROTECTED] wrote:
> On Wed, 1 Jun 2005, David Brownell wrote:
> > And in fact, the real issue looks to be that it's only comparing ONE of the
> > GUIDs, not both ... :(
> >
> > Try tweaking "usbnet.c" near line 2768 ... change one to "safe_guid",
> > they
On Wed, 1 Jun 2005, David Brownell wrote:
On Wednesday 01 June 2005 10:40 am, you wrote:
On Wed, 1 Jun 2005, David Brownell wrote:
On Wednesday 01 June 2005 9:03 am, [EMAIL PROTECTED] wrote:
May 31 23:48:30 localhost kernel: [4294746.062000] usbnet 3-1:1.0:
usb_probe_interface
May 31 23:48:
Hi all,
Technically, the readurb status is not nessecary, but I noticed that
it has potential to cause a problem later if not initialized. I have
not specifically seen a problem, I just set the readurb in good faith
to maybe alleviate problems in the future.
What do I need to do here? I'll sign
On Wed, Jun 01, 2005 at 08:20:07AM -0700, David Brownell wrote:
> On Tuesday 31 May 2005 5:12 pm, Adam Kropelin wrote:
> > ...
> >
> > Problem
> > After some period of time (minutes to hours), the BackUPS CS 650 and
> > BackUPS BR 800 models cease to respond to control transfers. Based on
> > HID
On Wed, Jun 01, 2005 at 03:35:08PM -0700, Nishanth Aravamudan wrote:
> The following patch addresses BugMe #4432.
>
> Description: Initialize status fields in the read and write urbs to
> prevent a race condition with open/read/close - open/write/close
> sequences.
>
> Signed-off-by: Adam Oldham
On 01.06.2005 [15:35:08 -0700], Nishanth Aravamudan wrote:
> The following patch addresses BugMe #4432.
>
> Description: Initialize status fields in the read and write urbs to
> prevent a race condition with open/read/close - open/write/close
> sequences.
>
> Signed-off-by: Adam Oldham <[EMAIL PR
diff -urNp linux-2.4.31/drivers/usb/storage/unusual_devs.h
linux-2.4.31-bzyk/drivers/usb/storage/unusual_devs.h
--- linux-2.4.31/drivers/usb/storage/unusual_devs.h Wed Nov 17 12:54:21 2004
+++ linux-2.4.31-bzyk/drivers/usb/storage/unusual_devs.hWed Jun 1
21:18:28 2005
@@ -255,6 +255,
The following patch addresses BugMe #4432.
Description: Initialize status fields in the read and write urbs to
prevent a race condition with open/read/close - open/write/close
sequences.
Signed-off-by: Adam Oldham <[EMAIL PROTECTED]>
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
diff -u
Am Mittwoch, 1. Juni 2005 22:29 schrieb Alan Stern:
> I'm not sure what more you would need beyond checking that dev.driver_data
> != NULL. If the device was physically disconnected then there's no
> problem -- once your driver's disconnect routine runs no other driver is
> allowed to bind to the
> > > On the other hand, remove methods typically do call dev_set_drvdata(dev,
> > > NULL). Thus a read-during-disconnect might very well end up with acecad
> > > == NULL, and so the check above is necessary.
> > >
> >
> > OK, consider this:
> >
> > CPU1:CPU2
>
On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
> On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> > Using a private semaphore for synchronization,
> > you can guarantee that dev.driver_data is NULL whenever your driver is
> > bound to the interface and the private data doesn't exist.
>
> BTW, you c
On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> Using a private semaphore for synchronization,
> you can guarantee that dev.driver_data is NULL whenever your driver is
> bound to the interface and the private data doesn't exist.
BTW, you can't use private semaphore... Well, you can as long as i
On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
> > > Right. In serio/gameport code we take a lock and then check if
> > > currently bound driver is still "us". This way we can detect if device
> > > was switched to alternate driver. If it still the same driver we asume
> > > that the data returned is
On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
>
> > On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> > > It's not so easy to synchronize operations on an attribute with driver
> > > operations if the driver doesn't own the attribute's kobject. In
On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
> On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> > It's not so easy to synchronize operations on an attribute with driver
> > operations if the driver doesn't own the attribute's kobject. In this
> > case there would have to be a single driver-wide s
Hi,
On Wed, 1 Jun 2005, Alan Stern wrote:
Going out on a limb, the most likely cause for this error is that the
device did not respond when asked for an ISO packet transfer.
Got it. Thank you. The problem was that one of the chips (the demodulator)
was not programmed correctly. I did not thou
On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> It's not so easy to synchronize operations on an attribute with driver
> operations if the driver doesn't own the attribute's kobject. In this
> case there would have to be a single driver-wide semaphore protecting
> intf->dev.driver_data for all
On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
> On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> > On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
> >
> > > > +static ssize_t show_tabletSize(struct device *dev, char *buf)
> > > > +{
> > > > + struct usb_acecad *acecad = dev_get_drvdata(dev);
> >
On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
>
> > > +static ssize_t show_tabletSize(struct device *dev, char *buf)
> > > +{
> > > + struct usb_acecad *acecad = dev_get_drvdata(dev);
> > > +
> > > + if (acecad == NULL)
> > > +
On Wednesday 01 June 2005 9:03 am, [EMAIL PROTECTED] wrote:
> May 31 23:48:30 localhost kernel: [4294746.062000] usbnet 3-1:1.0:
> usb_probe_interface
> May 31 23:48:30 localhost kernel: [4294746.062000] usbnet 3-1:1.0:
> usb_probe_interface - got id
> May 31 23:48:30 localhost kernel: [4294746.
On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
> > +static ssize_t show_tabletSize(struct device *dev, char *buf)
> > +{
> > + struct usb_acecad *acecad = dev_get_drvdata(dev);
> > +
> > + if (acecad == NULL)
> > + return 0;
>
> This check - is it really needed? Attributes a
On Wed, 1 Jun 2005, David Brownell wrote:
On Tuesday 31 May 2005 9:52 pm, [EMAIL PROTECTED] wrote:
On Tue, 31 May 2005, David Brownell wrote:
On Tuesday 31 May 2005 6:45 pm, [EMAIL PROTECTED] wrote:
May 31 17:42:15 localhost kernel: [4294985.357000] usb 3-1: unsupported MDLM
descriptors
An
Hi Edouard,
On 6/1/05, Edouard TISSERANT <[EMAIL PROTECTED]> wrote:
> Hi all.
>
> Patch should be now OK.
>
> It should fit to last Dimitry's requests.
>
Yes, it is much better now. I still have couple of concerns though:
> + acecad->dev.absmin[ABS_MISC] = 0;
> + acecad->dev.absmax
On Wednesday 01 June 2005 6:08 am, Patrick Boettcher wrote:
> Hi,
>
> On Tue, 31 May 2005, David Brownell wrote:
> >> However, I have a "new" problem. Since transfers are now taking place
> >> (URBs are submitted and received) every iso_frame_desc has status -71
> >> (-EPROTO) instead of being suc
On Tuesday 31 May 2005 9:52 pm, [EMAIL PROTECTED] wrote:
> On Tue, 31 May 2005, David Brownell wrote:
> > On Tuesday 31 May 2005 6:45 pm, [EMAIL PROTECTED] wrote:
> >> May 31 17:42:15 localhost kernel: [4294985.357000] usb 3-1: unsupported
> >> MDLM
> >> descriptors
> >
> > And with CONFIG_USB_DE
On Tuesday 31 May 2005 5:12 pm, Adam Kropelin wrote:
> ...
>
> Problem
> After some period of time (minutes to hours), the BackUPS CS 650 and
> BackUPS BR 800 models cease to respond to control transfers. Based on
> HID debug I can see that a control transfer is sent by apcupsd but a
> response ne
On Tue, 31 May 2005, Phil Dibowitz wrote:
> Oh, I CC'd the list but didn't include all the previous emails. The
> summary (though it can probably be pieced together from the above, I
> figure I should state it) is that the latest version of the firmware for
> the PL-3507 fixes the CAPACITY bug and
[I moved this thread to linux-usb-devel so that it would be more visible
to developers.]
On Mon, 30 May 2005, Heitzso wrote:
> Moving lots of very large 10G and 12G files back and forth
> from ubuntu (current) system to 3 SilverRiver (thermaltake)
> USB2 enclosures with new 300G WD caviar drives
On Tue, 31 May 2005, Glenn Maynard wrote:
> On Tue, May 31, 2005 at 04:33:21PM -0400, Alan Stern wrote:
> > -* are. However, according to the UHCI spec, Bit 7 of the port
> > +* are. However according to the UHCI spec, Bit 7 of the port
>
>
> > - /* Anything less than 2 or greater th
On Wed, 1 Jun 2005, Patrick Boettcher wrote:
> Hi,
>
> On Tue, 31 May 2005, David Brownell wrote:
> >> However, I have a "new" problem. Since transfers are now taking place
> >> (URBs are submitted and received) every iso_frame_desc has status -71
> >> (-EPROTO) instead of being successful
> >
>
gerard klaver wrote:
> For some info about the 0x93a 0x2460/0x2468 (pac207c from Pixart) see my
> page (pac20x SANE Vidcam backend, under development):
Gerard,
have you tried contacting Pixart - are they helpful or?
--
/Per Jessen, Zürich
--
On Tuesday 31 May 2005 9:17 pm, John Smith wrote:
> Hi,
>I want to know how usb gadgets work.
You've presumably read the kerneldoc and the overview webpage?
http://tali.admingilde.org/linux-docbook/gadget/
http://www.linux-usb.org/gadget/
The kerneldoc gives as detailed an overview as yo
On Tuesday 31 May 2005 9:18 pm, John Smith wrote:
> Hi,
>I have compiled Linux kernel to contain Serial Gadget Driver
> (CONFIG_USB_G_SERIAL)
>
>now, i dont have any devices in /dev that pertain to this driver.
>
>i want to run minicom on host side. i am using a dongle which
> convert
Hi,
On Tue, 31 May 2005, David Brownell wrote:
However, I have a "new" problem. Since transfers are now taking place
(URBs are submitted and received) every iso_frame_desc has status -71
(-EPROTO) instead of being successful
Was that _with_ the patch I pointed out to you?
Ehm, which patch?
On Tue, May 31, 2005 at 06:34:41PM -0700, Pete Zaitcev wrote:
> On Tue, 31 May 2005 20:12:53 -0400, Adam Kropelin <[EMAIL PROTECTED]> wrote:
>
> > Both users have tried different kernels up to and including 2.6.11.x, as
> > well as BIOS upgrades, etc.
>
> This looks like a perfect opportunity to
Anssi,
I had to put the card in to get the full output of lspci, and when I did
that...it worked! No config. Just worked. The one thing that I did
differently was not to disable the onboard USB in the BIOS when I put
the card in this time.
Thanks.
-Eric.
Anssi Hannula wrote:
Eric Berg
Hi,
Have a look at CDCEther protocol (TCP/IP over USB). That would give you a
better understanding and the inner working of Gadget Drivers.
http://www.qbik.ch/usb/devices/showdr.php?id=28
Regards
Arun
Date: Wed, 1 Jun 2005 09:47:50 +0530
From: John Smith <[EMAIL PROTECTED]>
Reply-To: John Smi
Am Mittwoch, 1. Juni 2005 10:37 schrieb lianwu pan:
> i read the usb error codecs in the Kernel Document
> it seems the code above is not about the urb status
> erroe.
>
> i am from china and may be my english is hard to
> understand .
> does anybody can tell me why the error come from ?
> does i
hi
i am a newer to the usb driver develop.
my custom driver go error in the urb complete
handle.
===
this is the urb configure
/*intlail the URB*/
urb->dev = dev->usb_dev;
urb->context = r_dev;
urb->pipe =
usb_rcvisocpipe(r_dev->usb_dev,r_dev->enp);
urb->interval = 1;
urb->transfer_flags = URB_IS
Hi all.
Patch should be now OK.
It should fit to last Dimitry's requests.
Here after is the mail of Stephane ( don't have time to translate it to
english ...)
Patch is attached to the mail.
Regards,
Edouard
---
Bonjour,
j'ai mis le driver à jour a
gerard klaver wrote:
> For some info about the 0x93a 0x2460/0x2468 (pac207c from Pixart) see my
> page (pac20x SANE Vidcam backend, under development):
>
> http://gkall.hobby.nl/pac20x.html
>
> its a single chip camera
Thanks Gerard,
I'll definitely have a look.
--
/Per Jessen, Zürich
47 matches
Mail list logo
