On Wed, Feb 20, 2002 at 05:18:49PM -0800, David Brownell wrote:
> This is minor cleanup; pulls #includes out of files
> that aren't intended to compile by themselves.
>
> It's against 2.5.5-pre1 but should work fine on
> the final 2.5.5 release.
Looks good, applied.
greg k-h
__
On Wed, Feb 20, 2002 at 09:09:41PM -0800, Jacek Pliszka wrote:
> On Wed, 20 Feb 2002, Greg KH wrote:
>
> > Why are you wading through html?
>
> Because it is faster than installing BK and getting the tree.
>
> All I usually need is a single file, this time ibmcam.c
Ah, that makes sense.
> > D
On Wed, 20 Feb 2002, Greg KH wrote:
> Why are you wading through html?
Because it is faster than installing BK and getting the tree.
All I usually need is a single file, this time ibmcam.c
> Does that work for you?
It is easier for me to run :
sed -e 's/ out
and the
> I'd say, get your own copy of BitKeeper, clone Greg's tree and work from
> there (locally), and pull changes from time to time into your repository.
> Should be very simple.
It is simple. The problem is that BK downloads the whole kernel tree.
While all I need is just a single ibmcam.c file ..
On Wed, Feb 20, 2002 at 05:49:30PM -0800, Jacek Pliszka wrote:
> Hi!
>
> Could somebody tell me whether there is an elegant way to get the
> source from this BitKeeper thing?
>
> Right now I have to download, remove HTML stuff (like <)
> and run through cut -c 16-
Why are you wading through htm
Just for the record, these don't compile.
Looks like they still expect 2.4 style s/g ...
I wouldn't know if they have other issues.
- Dave
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo
Quoting Jacek Pliszka <[EMAIL PROTECTED]>:
> Could somebody tell me whether there is an elegant way to get the
> source from this BitKeeper thing?
>
> Right now I have to download, remove HTML stuff (like <)
> and run through cut -c 16-
>
> This is nto very convenient but somehow I can not find
On Thu, Feb 21, 2002, Richard CHAN Shih-Ping <[EMAIL PROTECTED]> wrote:
> I was still seeing very slow scanning from 2.4.18-pre9 and and Epson.
> I was wondering whether all the fixes to the 2.5 uhci.c settle this
> issue? (Still can't quite get 2.5.5 vanilla to compile yet... :-((()
I'd suggest
Hi!
Could somebody tell me whether there is an elegant way to get the
source from this BitKeeper thing?
Right now I have to download, remove HTML stuff (like <)
and run through cut -c 16-
This is nto very convenient but somehow I can not find the
inteligent way to get the clean source.
BR,
Ja
This is minor cleanup; pulls #includes out of files
that aren't intended to compile by themselves.
It's against 2.5.5-pre1 but should work fine on
the final 2.5.5 release.
- Dave
drv-0217.patch
Description: Binary data
Hi Johannes and list,
I was still seeing very slow scanning from 2.4.18-pre9 and and Epson.
I was wondering whether all the fixes to the 2.5 uhci.c settle this
issue? (Still can't quite get 2.5.5 vanilla to compile yet... :-((()
Cheers!
Richard Chan
On Wed, 2002-02-20 at 14:23, Johannes Erdfel
On Wed, Feb 20, 2002 at 04:48:01PM -0800, Greg KH wrote:
>
> [EMAIL PROTECTED], 2002-02-20 15:49:58-08:00, [EMAIL PROTECTED]
> usb usb-uhci.c:
> - added usb_put_urb() and usb_get_urb() logic.
>
> drivers/usb/usb-uhci.c | 10 +-
> 1 files changed, 9 insertions(+), 1 deletion(-)
On Wed, Feb 20, 2002 at 04:48:01PM -0800, Greg KH wrote:
>
> [EMAIL PROTECTED], 2002-02-20 16:12:36-08:00, [EMAIL PROTECTED]
> usb vicam driver:
> - compile time fixes
>
> drivers/usb/vicam.c |2 ++
> 1 files changed, 2 insertions(+)
>
# This is a BitKeeper generated patch for the
On Wed, Feb 20, 2002 at 04:48:01PM -0800, Greg KH wrote:
>
> [EMAIL PROTECTED], 2002-02-20 16:11:57-08:00, [EMAIL PROTECTED]
> usb config.help:
> - removed an unneeded header. Thanks to Jeff Garzik for pointing this out.
>
> drivers/usb/hcd/Config.help |1 -
> 1 files changed, 1 de
On Wed, Feb 20, 2002 at 04:48:01PM -0800, Greg KH wrote:
>
> [EMAIL PROTECTED], 2002-02-20 16:00:37-08:00, [EMAIL PROTECTED]
> uhci.c didn't work well with USB storage. It would tend to stall
> relatively quickly and sometimes locked up the system. It usually only
> took me a couple of trie
On Wed, Feb 20, 2002 at 04:48:01PM -0800, Greg KH wrote:
>
> [EMAIL PROTECTED], 2002-02-20 15:54:14-08:00, [EMAIL PROTECTED]
> usb hub:
> - fix problem with us not delaying for any ammount of time after a new device
> has been powered up, as the USB spec indicates should happen.
>
Pull from: bk://linuxusb.bkbits.net/linus-2.5
drivers/usb/hcd/Config.help |1
drivers/usb/hub.c | 53
drivers/usb/ov511.c | 2762 +---
drivers/usb/ov511.h | 229 +--
drivers/usb/uhci.c | 227 ++-
drivers/usb
Given the discussion on INTR-OUT transfers, I thought it'd
be useful to write out my current thoughts on how we should
resolve this ... since it involves driver API changes as well as
changes to each of the host controller drivers.
Here's a quick writeup, including rationale and some sketches
of
> When the original urb is submitted, are you supposed to
> put 64 bytes in the urb, and then 36 bytes in the next urb
> (you as in the driver writer), or is this supposed to happen
> transparently inside the urb resubmission code?
Neither ...
> ie do I submit an URB with 100 bytes of data, or d
Oliver Neukum wrote (in response to me):
>
> > I've seen similar issues firsthand on an SMP box. I think the reported EIP
> > address tends to lie in non-USB parts of the kernel, such as various
> > network drivers, but I don't know if that's always the case. I just know
>
> Are they repeatabl
> It really recommend looking at the Linux Device Drivers book, as it
> might help you out.
Siegfried, in case you're not aware, the book can be found online at
http://www.xml.com/ldd/chapter/book/index.html.
-Chris
___
[EMAIL PROTECTED]
To unsubsc
Hi all,
Here's a small patch for 2.5.5 that enables the USB vicam driver to build
properly again.
thanks,
greg k-h
diff -Nru a/drivers/usb/vicam.c b/drivers/usb/vicam.c
--- a/drivers/usb/vicam.c Wed Feb 20 10:10:15 2002
+++ b/drivers/usb/vicam.c Wed Feb 20 10:10:15 2002
@@ -40,6 +
On Wed, Feb 20, 2002 at 06:40:43PM +0100, Wessler, Siegfried wrote:
> >
> > Does your device pass all of the usb tests on Windows?
>
> Yes. I previously tested with INTEL's USBCheck.exe Version 3.2 and passed
> all tests as compliant.
Good. Has your device survived a USB plugfest testing?
>
Hello Greg and list readers,
> -Ursprüngliche Nachricht-
> Von: Greg KH [mailto:[EMAIL PROTECTED]]
>
> Does your device pass all of the usb tests on Windows?
Yes. I previously tested with INTEL's USBCheck.exe Version 3.2 and passed
all tests as compliant.
> If it passes all of
> thos
On Wed, Feb 20, 2002 at 05:47:56PM +0100, Wessler, Siegfried wrote:
>
> If I hot plug one of these devices to a windows pc, everything runs fine.
Does your device pass all of the usb tests on Windows? Download a tool
from usb.org to test how compliant your device is. If it passes all of
those
random snippage...
> > I as well have noticed the only chipsets I have problems with are
the VIA
> > uhci chipsets. As I said previously, I know a "special" UHCI driver
was
> > released by Microsoft/VIA that corrected a lot of problems that were
being
> > had with VIA's chipset. I would persue
Hello,
sorry for that weird reference line ;-)
I developed a hardware USB device and ported that code to a device
controller either, which is placed on a self designed pc platform, where we
placed a device controller either (called "pc device" further on).
The device controller is an PDIUSBD12
On Wed, Feb 20, 2002, Matthew Fredrickson <[EMAIL PROTECTED]> wrote:
> > I've been getting similar reports from users of the ov511 driver: error
> > -84 (babble), error -110 (timeout), and truncated frames. The common
> > variable in all cases is a VIA chipset. I would try to track the problem
> uhci chipsets. As I said previously, I know a "special" UHCI driver was
> released by Microsoft/VIA that corrected a lot of problems that were being
> had with VIA's chipset. I would persue a fix for it myself, but I don't
The old VIA random bit stuff is covered in the Linux USB
> know enoug
> I've been getting similar reports from users of the ov511 driver: error
> -84 (babble), error -110 (timeout), and truncated frames. The common
> variable in all cases is a VIA chipset. I would try to track the problem
> down, but my host controllers are all either OHCI or Intel UHCI.
I as we
[EMAIL PROTECTED] wrote:
>hi,
>
>thanks for the reply. it is reassuring to know that i am not alone now let me see
>if i get this right:
>
>1) you assume that we are talking via chipset
> (correct: my mainboard is some MSI* based on VIA chips and i could find out but
>not while at work
31 matches
Mail list logo
