On Tue, Apr 05, 2005 at 10:28:58AM +0530, [EMAIL PROTECTED] wrote:
> Hi Greg,
>
> Here I have some clarifications on usbserial driver, right now it is
> allowed to compile as individual modules and loaded as and when it is
> needed.
>
> Why can't we make this module as module and it should be l
On Mon, Apr 04, 2005 at 10:20:02PM -0700, David Brownell wrote:
> On Monday 04 April 2005 9:58 pm, [EMAIL PROTECTED] wrote:
>
> > Why can't we make this module as module and it should be like acm module
> > loaded as soon as device communication device connected to the system.
>
> A module alread
On Monday 04 April 2005 9:58 pm, [EMAIL PROTECTED] wrote:
> Why can't we make this module as module and it should be like acm module
> loaded as soon as device communication device connected to the system.
A module already _is_ a module ... I for one don't understand this
question.
That said, it
Hi Greg,
Here I have some clarifications on usbserial driver, right now it is
allowed to compile as individual modules and loaded as and when it is
needed.
Why can't we make this module as module and it should be like acm module
loaded as soon as device communication device connected to the sys
My guess is that this would be related to the new klist stuff
in the driver model code, if it's not in mainline... I've been
using CDC Ethernet links recently without problems, but I don't
know what hardware Carlos is using.
- Dave
On Monday 04 April 2005 5:48 pm, Andrew Morton wrote:
>
> Carlo
Carlos, could you please test 2.6.12-rc2, see if the bug has leaked into
mainline?
Thanks.
Begin forwarded message:
Date: Mon, 4 Apr 2005 20:27:21 +0200
From: Carlos Martin <[EMAIL PROTECTED]>
To: linux-kernel@vger.kernel.org
Subject: kernel BUG at fs/sysfs/symlink.c:87 on 2.6.12-rc1-mm4
Hi
I have some USB protocol questions about initial device setup.
I'm trying to write my own USB stack for an Atmel AT43USB355E microcontroller
(Atmel has a USB library but its binary only).
This chip has 3 Functional Endpoints and 2 Hub ports.
I noticed on device plug-in the GET_DESCRIPTOR contro
> > > I suppose if I told the kernel I want 40 bytes it'd give me 40, then 40
> > > and then 1, after which the cycle would restart.
> >
> > No, it should give you 40 bytes with an -EOVERFLOW error since the
> > device sent 64 bytes in that packet. Then probably 17 in the next.
>
> Hm, ok. But
On Mon, Apr 04, 2005 at 11:10:53AM -0700, Nishanth Aravamudan wrote:
> On Wed, Feb 02, 2005 at 11:03:09AM -0800, Nishanth Aravamudan wrote:
> > Hello,
> >
> > Description: Replace deprecated interruptible_sleep_on_timeout() with direct
> > wait-queue usage. Also replace some rather odd wait-queue
On Mon, 2005-04-04 at 14:06 -0700, David Brownell wrote:
> That's exactly as I described. 64 bytes in one packet, 17 in the next.
>
> You are NOT getting 81 bytes in one frame/packet!!
Ok, thanks for clarifying.
> > I suppose if I told the kernel I want 40 bytes it'd give me 40, then 40
> > an
On Monday 04 April 2005 1:39 pm, Johannes Berg wrote:
> On Mon, 2005-04-04 at 13:22 -0700, David Brownell wrote:
>
> > > If I pass a URB into the usb layer that has an 81 byte buffer, all those
> > > 81 bytes get filled!
> >
> > Probably the first 64 in one frame, then the last bytes in the next
On Mon, 2005-04-04 at 13:22 -0700, David Brownell wrote:
> > If I pass a URB into the usb layer that has an 81 byte buffer, all those
> > 81 bytes get filled!
>
> Probably the first 64 in one frame, then the last bytes in the next one
> that's polled. That's expected ... otherwise drivers would
On Monday 04 April 2005 1:12 pm, Johannes Berg wrote:
> If I pass a URB into the usb layer that has an 81 byte buffer, all those
> 81 bytes get filled!
Probably the first 64 in one frame, then the last bytes in the next one
that's polled. That's expected ... otherwise drivers would have some
ve
On Mon, 2005-04-04 at 15:31 -0400, Alan Stern wrote:
> For full-speed devices that's right. For low-speed devices the upper
> limit is 8, and for high-speed it's 1024.
Yeah, that's what I read from the spec too, thanks for confirming.
> What makes you think the value
> should be 81? Didn't
On Sunday 27 March 2005 4:31 pm, Andrew Morton wrote:
>
> http://bugme.osdl.org/show_bug.cgi?id=4408
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1209626496 (LWP 26124)]
> usb_reset (dev=0x0) at linux.c:671
> 671 ret = ioctl(dev->fd, IOCTL_USB_RESET, NULL
This defines a new quirk; please merge.
- Dave
This adds a quirk to the OHCI driver that lets it work with an old
Compaq implementation. It also removes some needless strings from
the non-debug version of the driver.
Signed-off-by: Chris Clayton <[EMAIL PROTECTED]>
Signed-off-by: David Brownell
thanks Dave,
In the mean time, if anyone else knows more on this, the input is welcome.
thx, Elmano
On Apr 4, 2005 12:39 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Monday 04 April 2005 9:02 am, Elmano Carvalho wrote:
> > I am trying to insert a usb-test module, provided with the
> >
Patch from bender647 ... it's not clear right now which zaurii are
telling which lies. ROM 1.32 on the sl5600 needs this patch.
I expect a few other zaurii will need similar patches, but it's
hard to say.
Please merge.
- Dave
Hmm, another case of a Zaurus ROM not telling the expected conformanc
On Mon, 4 Apr 2005, Johannes Berg wrote:
> On Fri, 2005-04-01 at 11:47 -0500, Alan Stern wrote:
>
> > There's a very simple explanation. In 2.6.10 and earlier the
> > wMaxPacketSize value is stored in native byte order, whereas in 2.6.11 and
> > later it's stored in little-endian byte order.
On Sunday 03 April 2005 7:36 am, Jayaprakash Shanmugam wrote:
> Hi All,
>
> I have a strange behavior here with my ISP 1561 PCI-USB card.
>
> 1) When I plug in our board (USB based), it works fine with OHCI (the
> PCI USB card has 2 OHCI and 1 EHCI core).
>
> 2) When I try to use the EHCI driv
On Sunday 03 April 2005 7:39 am, Jayaprakash Shanmugam wrote:
> Hi Group,
> Can any of you tell me how to find out the USB speed at which the
> device is operating on ?
usb_device->speed inside the kernel.
Or sysfs has the "speed" attribute.
---
Adding my responses to David's...
On Sun, 3 Apr 2005, Duncan Sands wrote:
> Suppose a driver has taken a reference to a usb device (usb_get_dev).
> Can the list of interfaces shift around underneath it?
Yes. Although if the driver is bound to one of those interfaces, the
configuration won't ch
On Monday 04 April 2005 11:38 am, Alan Stern wrote:
> On Sun, 3 Apr 2005, Duncan Sands wrote:
>
> > Using usb_reset_device in a probe method (or pretty much
> > anywhere for that matter) seems to run the risk of getting
> > into an infinite loop of connect/disconnect calls. ...
>
> Things general
On Sun, 3 Apr 2005, Jayaprakash Shanmugam wrote:
> Hi Group,
> Can any of you tell me how to find out the USB speed at which the
> device is operating on ? I can get it from the /proc/bus/usb/devices.
> I guess the information put up there is taken from the descriptors
> given by the device. B
On Sun, 3 Apr 2005, Duncan Sands wrote:
> Using usb_reset_device in a probe method (or pretty much
> anywhere for that matter) seems to run the risk of getting
> into an infinite loop of connect/disconnect calls. Suppose
> the reset fails. Then the device will be disconnected then
> reconnected.
On Wed, Feb 02, 2005 at 11:03:09AM -0800, Nishanth Aravamudan wrote:
> Hello,
>
> Description: Replace deprecated interruptible_sleep_on_timeout() with direct
> wait-queue usage. Also replace some rather odd wait-queue usage with the
> existent macros. Also adjusted the wake_up_interruptible() cal
Hi all,
I'm attaching a patch to fix status when using Siemens X65
mobile. This mobile use first byte instead of normal UART_STATE
byte.
Please apply.
Thanks!
[ps: please carbon copy to me because I'm not subcribed.]
--
Flávio Bruno Leitner <[EMAIL PROTECTED]>
[0EA2 7F40 4CF4 1E63 4AF6
On Monday 04 April 2005 10:02 am, Dale Farnsworth wrote:
> This patch avoids a null-pointer dereference and fixes a typo.
>
> Signed-off-by: Sylvain Munaut <[EMAIL PROTECTED]>
> Acked-by: Dale Farnsworth <[EMAIL PROTECTED]>
Acked-by: David Brownell <[EMAIL PROTECTED]>
> ---
> = drivers/usb
This patch avoids a null-pointer dereference and fixes a typo.
Signed-off-by: Sylvain Munaut <[EMAIL PROTECTED]>
Acked-by: Dale Farnsworth <[EMAIL PROTECTED]>
---
= drivers/usb/host/ohci-ppc-soc.c 1.2 vs edited =
--- 1.2/drivers/usb/host/ohci-ppc-soc.c 2005-03-08 05:43:18 +01:00
+++ edited
On Sunday 03 April 2005 8:33 am, Duncan Sands wrote:
> Suppose a driver has taken a reference to a usb device (usb_get_dev).
> Can the list of interfaces shift around underneath it? For example,
> suppose the configuration changes, changing the set of interfaces.
Yes, exactly. As of last year so
On Monday 04 April 2005 9:02 am, Elmano Carvalho wrote:
> I am trying to insert a usb-test module, provided with the
> LTP-20050207 testcase, in my kernel (ver. 2.6.10) to test my usb
> device.
I don't know what that is; we recommend folk use "usbtest":
http://www.linux-usb.org/usbtest/
Maybe
On Monday 04 April 2005 1:22 am, mike lee wrote:
> Hi all
> If i want to transfer data to/from my embedded linux board from/to
> external with usb. Could usb gadget driver with file back storage serve
> this purpose?
Yes, if the data can be modeled on the host side as block devices.
In terms o
Hello,
I am trying to insert a usb-test module, provided with the
LTP-20050207 testcase, in my kernel (ver. 2.6.10) to test my usb
device.
When I do a make in the kernel space, I get warnings about undefined
functions in the source code, but the .o files are created anyways.
Then when I run #in
您好！我公司可代开国内商品销售、国际国内运输业、广告服务业等发票，税务局验证后付款。欢迎合作！
联系人：欧阳先生
电话：13723459244
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real
Hi all
If i want to transfer data to/from my embedded linux board from/to
external with usb. Could usb gadget driver with file back storage serve
this purpose? Because i am in pre-product evaluation stage and i found
that there is no controller driver on my linux board, i don't want to
make a w
On Fri, 2005-04-01 at 11:47 -0500, Alan Stern wrote:
> There's a very simple explanation. In 2.6.10 and earlier the
> wMaxPacketSize value is stored in native byte order, whereas in 2.6.11 and
> later it's stored in little-endian byte order. So your code is getting
> the correct value under 2
36 matches
Mail list logo
