Greg KH wrote:
> On Wed, Jul 24, 2002 at 01:55:58PM -0700, David Brownell wrote:
>
>>... it'd be better if it included usb_bus->bus_name too, as done
>>in usb_make_path(), since two different busses can easily have
>>similar hub trees. "%s-%s:%d" then, since this format string
>>can't use "/" li
On Wed, Jul 24, 2002 at 11:08:17PM +0200, Oliver Neukum wrote:
>
> > > USBDEVFS_DISCONNECT - generic idea
> > > USBDEVFS_CONNECT - likewise
> > > USBDEVFS_RESET - likewise
> > > USBDEVFS_GETDRIVER - unless made superfluous
> >
> > If you turn these not into ioctls, yes. ioctls will not be in dri
> > USBDEVFS_DISCONNECT - generic idea
> > USBDEVFS_CONNECT - likewise
> > USBDEVFS_RESET - likewise
> > USBDEVFS_GETDRIVER - unless made superfluous
>
> If you turn these not into ioctls, yes. ioctls will not be in driverfs.
How are things done in driverfs?
Regards
Oli
On Wed, Jul 24, 2002 at 01:55:58PM -0700, David Brownell wrote:
> ... it'd be better if it included usb_bus->bus_name too, as done
> in usb_make_path(), since two different busses can easily have
> similar hub trees. "%s-%s:%d" then, since this format string
> can't use "/" like hid-core (effecti
> # [PATCH] USB: changed the interface name to be a bit more unique.
> #
> # This is needed as long as we have the directory of symlinks in the bus
> # subdir in driverfs to point to the unique interfaces.
> #
> #
Actually ...
> - sprintf
Adam Polkosnik wrote:
>
> Hi everybody,
> just a couple of extra IDs for Canon USB Scanners
>
>
>
>
> --- /usr/src/linux-2.4.18-5/drivers/usb/scanner.hMon Jun 10 15:38:15 2002
> +++ /usr/src/linux/drivers/usb/sca
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.693 -> 1.694
# drivers/usb/core/us
(this tree includes some changesets from the last round I sent that
haven't ended up in your tree yet, I only listed the new ones below)
Pull from: http://linuxusb.bkbits.net/linus-2.5
drivers/usb/core/usb.c|5 +++--
drivers/usb/net/rtl8150.c | 11 +--
2 files changed, 8 in
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.694 -> 1.695
# drivers/usb/net/rtl
Hi everybody,
just a couple of extra IDs for Canon USB Scanners
--- /usr/src/linux-2.4.18-5/drivers/usb/scanner.h Mon Jun 10 15:38:15 2002
+++ /usr/src/linux/drivers/usb/scanner.hFri Jul 19 23:23:50 2002
@@ -90,9 +90,12 @@
{ USB_DEVICE(0x06bd, 0x2097) }, /* SnapScan e26 */
Greg KH wrote:
> On Fri, Jul 19, 2002 at 02:24:39PM -0700, David Brownell wrote:
>
>>Such stuff could be layered at first, too. Though I suspect
>>that a clean treatment of transfer buffers would lead to one
>>new_urb() call for control, another for bulk/interrupt, and one
>>more for ISO. Event
Greg KH wrote:
> On Sat, Jul 20, 2002 at 06:15:46PM -0700, David Brownell wrote:
>
>>Part 1:
>>
>> - HCDs remove special (a) "can't queue" and (b) "only one packet"
>>limitations for interrupt transfers (*)
>
>
> Is this _really_ needed? Do any drivers do anything special right now
> to w
On Sat, Jul 20, 2002 at 06:15:46PM -0700, David Brownell wrote:
> Part 1:
>
> - HCDs remove special (a) "can't queue" and (b) "only one packet"
> limitations for interrupt transfers (*)
Is this _really_ needed? Do any drivers do anything special right now
to work around this? If this is
On Fri, Jul 19, 2002 at 02:24:39PM -0700, David Brownell wrote:
>
> Such stuff could be layered at first, too. Though I suspect
> that a clean treatment of transfer buffers would lead to one
> new_urb() call for control, another for bulk/interrupt, and one
> more for ISO. Eventually, a "pipe-fr
On Tue, Jul 23, 2002 at 09:52:37AM +0200, Oliver Neukum wrote:
> Am Montag, 22. Juli 2002 20:51 schrieb David Brownell:
> > Greg KH wrote:
> > > On Sat, Jul 20, 2002 at 10:16:48PM +0200, Oliver Neukum wrote:
> > >>>Does anyone/anything use this file? The driverfs changes kind of
> > >>> make this
On Tue, Jul 23, 2002 at 06:54:47AM -0700, David Brownell wrote:
>
> It's my understanding that "driverfs" isn't supposed to replace
> "usbfs".
exactly.
greg k-h
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://t
On Mon, Jul 22, 2002 at 11:51:24AM -0700, David Brownell wrote:
> >>So what else can go into driverfs ?
>
> I'd rather know what _should_ go into it ... :)
Device specific information. Driver specific information. Basically
all the crap in /proc that doesn't deal with processes :)
> Well, it
On Mon, Jul 22, 2002 at 11:06:20PM -0700, Petko Manolov wrote:
> Hi Greg,
>
> This patch adds one more device to the list and removes redundant check in
> probe(); It is bulky because i've run the thing through indent long
> time ago. Oh, and the usual limitation to GPL v2 only...
Applie
Soewono Effendi wrote:
> Hi Johann,
>
> thanks for your reply.
> Surelly I understand what the codes
>
Sorry, I missed the point of the question.
My guess would be that uhci_hub_status_data should return len, perhaps ?
This variable is computed, but not used, apparently. It would make sense
Hi Johann,
thanks for your reply.
Surelly I understand what the codes
> > return !!*buf;
literally mean.
What I would like to know is, what does it suppose to do in context of USB layer.
If one follows the USB codes, then one will see that this "uhci_hub_status_data"
will be called by
Soewono Effendi wrote:
> Hi all,
>
>
> I'm just curious if there is any particular reason to use the following code
>
> return !!*buf;
>
> instead of the simple
>
> return (int) *buf;
>
This would be a trick to return 0 or 1.
Take for example *buf equal to 3.
!*buf -> !3 -> !
Hi,
I'm trying to put a system together with video capture using a usb
device. I am using the usbvision-0.3.3-test1 driver and I have tried
both the Belkin USBview II and Hauppauge WinTV USB grabbers but without
success. With the Belkin, the driver recognizes the device ok and begins
initiali
Hi all,
I'm just curious if there is any particular reason to use the following code
return !!*buf;
instead of the simple
return (int) *buf;
in function "uhci_hub_status_data", file: usb/host/uhci-hub.c
static int uhci_hub_status_data(struct usb_hcd *hcd, char *buf)
{
23 matches
Mail list logo
