Hi,
I am trying to do an USB serial transfer from Host(UHCI) to the PDA without
any serial converters i.e I have the regular USB cable.
The idea is to use serial interface instead of network interface.
I need a driver for the same, which should be able to do OUT transfers.
Do we alr
This will not work.
On Mon, 21 Jan 2002, weiwu wrote:
> My kernel is linux 2.2.14,so I copy all of USB of 2.4.4 to it.
> I am using modules now,so I load the following:usbcore.o m8xxhci.o ,
> but i donn't know the next what can I do.How to run M8xxhci.c?
>
>
>)îÆëuëÞX¬¶Ë(º· ~àzwN§²æìr¸
This is against 2.5.3-pre2 and fixes:
- wrong return value from async unlink (in hcd layer)
- expectation that CONFIG_DEBUG_SLAB is set (ehci-hcd)
Simple stuff, as you can see.
- Dave
hcd-0120.patch
Description: Binary data
On Fri, Jan 18, 2002 at 06:26:01PM -0800, Stephen J. Gowdy wrote:
> Hi Greg et al,
> I've now added a 2.5_todo.php that is linked from the first page.
> I'll remove the .html and .sh files if there are no objections by
> tomorrow.
Thanks a lot for doing this. I'll tweak it this week (add
On Sun, Jan 20, 2002 at 05:37:01PM -0800, David Brownell wrote:
> > I'd say to switch them in hcd.c, as the manufacturer of the USB card
> > shows up in the Product line with the hcd code,
>
> PCI actually stores "manufacturer plus product name", and if
> you configure the kernel without PCI name
My kernel is linux 2.2.14,so I copy all of USB of 2.4.4 to it.
I am using modules now,so I load the following:usbcore.o m8xxhci.o ,
but i donn't know the next what can I do.How to run M8xxhci.c?
%{±ºÆÝz÷¥+-²Ê.Ç¢¸ ëS¢éì¹» ®&ÞºÇ
éZ²×è®gâzWZ¶m¦Ïÿ+-²Ê.Ç¢¸ ë+-³ùb²Ø§~å{±ºÆÝz÷¥
> I'd say to switch them in hcd.c, as the manufacturer of the USB card
> shows up in the Product line with the hcd code,
PCI actually stores "manufacturer plus product name", and if
you configure the kernel without PCI names (or don't have a
name for that vendor/product) it'll be a cryptic pair o
Greg KH wrote:
>
> With the recent lists of what people are going to be wanting to do in
> the 2.5 kernel happening right now on the linux-kernel mailing list, I
> remembered that I had wanted to summarise our own thread on the same
> topic:
> http://marc.theaimsgroup.com/?t=100656721
On Sun, Jan 20, 2002 at 04:55:12PM -0800, David Brownell wrote:
> > One other comment, it looks like you got the "Product=" and
> > "Manufacturer=" lines in /proc/bus/usb/devices backwards :)
>
> It agrees with the EHCI driver ... that's handled in "hcd.c",
> function rh_string().
>
> Manufact
> With all of the patches that I just sent, I tried out the driver and it
> didn't work :)
Could you send me your integrated patch (off-list) and I'll see
what's up? The original works quite nicely for me ... :)
I'll send you an update with some other cleanup and the fix
for that "unlink from i
On Sun, Jan 20, 2002 at 04:28:58PM -0800, David Brownell wrote:
> Great, thanks -- sorry about needing those other patches.
No problem. The urb_t one, I understand due to it only being in my
tree, and not Linus's yet. The Makefile one is no biggie, and the PMAC
one I figured you just didn't rea
Can't hurt, but the second patch segment will conflict
since the USB_ST_* is gone in 2.5 (obvious fix).
Assuming the "usb-ohci" goes away in 2.5.4 (?) then
the patch I'll send you for "ohci-hcd" will suffice.
- Dave
- Original Message -
From: "Greg KH" <[EMAIL PROTECTED]>
To: "David B
On Sun, Jan 20, 2002 at 01:32:48PM -0800, David Brownell wrote:
> This fixes the problem Stuart reported, where interrupt urbs
> couldn't be unlinked from their completion handlers, and it
> also makes OHCI return the correct status code for async
> unlink requests (-EINPROGRESS not zero).
Should
Here's a patch I just added to my 2.5 tree that syncs the hcd core code
with the same changes that were made in 2.4.15-pre2 to the other hcd
drivers.
Let me know if you object to these changes.
thanks,
greg k-h
diff -Nru a/drivers/usb/hcd.c b/drivers/usb/hcd.c
--- a/drivers/usb/hcd.c Sun Jan
On Fri, Jan 18, 2002 at 04:35:27PM -0800, David Brownell wrote:
> This patch is against 2.5.2-pre11 but it should work
> fine against the current 2.5.3-pre stuff too.
>
> It adds the "ohci-hcd" driver, which should replace
> the "usb-ohci" driver ... preferably in the 2.5.4 series
> rather than b
On Sat, Jan 19, 2002 at 07:20:14PM -0500, Johannes Erdfelt wrote:
> This fixes 2 bugs with the data toggle in uhci.c which was causing
> reduced performance.
>
> The patch is relative to 2.4.18-pre4.
Looks good, thanks. I added this to both the 2.4 and 2.5 trees.
greg k-h
Great, thanks -- sorry about needing those other patches.
- Dave
- Original Message -
From: "Greg KH" <[EMAIL PROTECTED]>
To: "David Brownell" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, January 20, 2002 4:18 PM
Subject: Re: PATCH: ohci-hcd (for 2.5)
> On Fri, Jan 18, 2
On Fri, Jan 18, 2002 at 04:35:27PM -0800, David Brownell wrote:
> This patch is against 2.5.2-pre11 but it should work
> fine against the current 2.5.3-pre stuff too.
And finally here's a drivers/usb/Makefile change to build the ohci-hcd
driver properly.
thanks,
greg k-h
diff -Nru a/drivers/us
On Fri, Jan 18, 2002 at 04:35:27PM -0800, David Brownell wrote:
> This patch is against 2.5.2-pre11 but it should work
> fine against the current 2.5.3-pre stuff too.
And here's a patch that adds the PMAC changes that went into the
2.4.18-pre2 of usb-ohci.c to the ohci-hcd driver.
thanks,
greg
On Fri, Jan 18, 2002 at 04:35:27PM -0800, David Brownell wrote:
> This patch is against 2.5.2-pre11 but it should work
> fine against the current 2.5.3-pre stuff too.
Here's a patch that is needed due to the removal of urb_t in my tree.
thanks,
greg k-h
diff -Nru a/drivers/usb/hcd/ohci-dbg.c
On Fri, Jan 18, 2002 at 04:35:27PM -0800, David Brownell wrote:
> This patch is against 2.5.2-pre11 but it should work
> fine against the current 2.5.3-pre stuff too.
Added to my tree, but there's a few patches I needed to also add to get
it to build properly in my tree. Will send in next messag
> > The module subsystem provides _two_ entirely different APIs
> > for checking for unloadability. Either it checks for the module usage
> > count or it calls a function the module provides itself.
> > Thus a solution that requires by design that the usage count be used is
> > broken.
>
> Oh, yo
> > > > BKL is not a realistic option here. Which would leave this as some
> > > > usbcore role, except that it doesn't explicitly know which module makes
> > > > each request.
> > >
> > > It could be included into usb_unlink_urb() which is called under BKL
> > > from disconnect().
> >
> > From k
This fixes the problem Stuart reported, where interrupt urbs
couldn't be unlinked from their completion handlers, and it
also makes OHCI return the correct status code for async
unlink requests (-EINPROGRESS not zero).
- Dave
ohci-0120.patch
Description: Binary data
> > > BKL is not a realistic option here. Which would leave this as some
> > > usbcore role, except that it doesn't explicitly know which module makes
> > > each request.
> >
> > It could be included into usb_unlink_urb() which is called under BKL
> > from disconnect().
>
> From khubd disconnect
> > > Or in other words, if the guard is against unloading the completion
> > > handler, which is a part of the driver, the code to do it cannot be in
> > > the completion handler.
> > > It has to be in another module or must be under the big kernel lock.
> >
> > I'd been more thinking about havin
Probably it doesn't like SLAB_POISON in your configuration.
As a workaround, in "ehci-hcd.c" try changing the #ifdef that
turns on SLAB_POISON to be #ifdef CONFIG_DEBUG_SLAB.
Or just enable that in your config.
- Dave
- Original Message -
From: "Oliver Neukum" <[EMAIL PROTECTED]>
To:
Hi,
I get a kernel panic (illegal operand) with the following call sequence
kmem_cache_grow <- kmalloc <- pci_pool_create <- ehci_mem_init
Regards
Oliver
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https:/
> > Or in other words, if the guard is against unloading the completion
> > handler, which is a part of the driver, the code to do it cannot be in
> > the completion handler.
> > It has to be in another module or must be under the big kernel lock.
>
> I'd been more thinking about having the disco
29 matches
Mail list logo
