On Fri, Apr 26, 2002 at 08:24:06PM -0500, Curran, Dominic wrote:
>
> Whats the state of the USB-Bluetooth driver ?
>
> I see that there are two sets of code:
> \bluetooth\hci_usb.c (Qualcomm Inc)
> and
> \usb\bluetooth.c (GKH)
>
> Is the hci_usb.c an enhanced version of bluetooth.c ?
>
>
Dear all,
Perhaps this is not the right place to ask, but I do wish
someone could help
Is there anyone in this milist who has a back-up of USB
UTMI 1.X specification? Could I ask to receive it? Intel
doesn't provide it anymore in its website except UTMI 2.0
and I couldn't find it in other si
Whats the state of the USB-Bluetooth driver ?
I see that there are two sets of code:
\bluetooth\hci_usb.c (Qualcomm Inc)
and
\usb\bluetooth.c (GKH)
Is the hci_usb.c an enhanced version of bluetooth.c ?
Is bluetooth.c to be end-of-life'd ?
Will both of these drivers work with the Bluetoo
# 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.569 -> 1.570
# drivers/usb/core/us
# 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.568 -> 1.569
# drivers/usb/core/us
# 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.567 -> 1.568
# drivers/usb/input/h
# 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.564 -> 1.565
# drivers/usb/net/usb
# 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.565 -> 1.566
# Documentation/usb/e
# 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.558 -> 1.558.1.1
# drivers/usb/media
This includes the changesets I sent out yesterday, with a few more
added.
Pull from: bk://linuxusb.bkbits.net/linus-2.5
Documentation/usb/ehci.txt | 15 +
drivers/usb/Config.help |8
drivers/usb/class/printer.c | 21 +
drivers/usb/core/Config.in | 11 -
drivers/usb/core/
On Thu, Apr 25, 2002 at 01:10:23PM -0700, David Brownell wrote:
> > > p.p.s. Driver-visible API change in 2.5.10: if you use
> > > fops, you MUST set num_minors ... listing in the
> > > /proc/bus/usb/drivers file happens even if there's
> > > no way the driver will be accessible. I th
On Sat, Apr 27, 2002 at 12:12:54AM +0200, Oliver Neukum wrote:
>
> What I do question is whether it is worth the trouble.
> You get a lot of trouble, like a completly new, unproven,
> supporting infrastructure for relatively little gain.
The people with 20 printers or scanners have something to
On Thu, Apr 25, 2002 at 10:50:30PM -0700, David Brownell wrote:
> This resends the "usb_make_path()" update (my net-0408 patch)
> to pegasus, so it reports the same bus info the other usb network
> drivers now return, and fixes a couple other bugs in ethtool support I
> happened to notice:
>
>
On Fri, Apr 26, 2002 at 11:22:26PM +0200, Vojtech Pavlik wrote:
> Hi!
>
> These two bk csets add another KVM switch which can't handle
> get_report() USB request to the HID driver blacklist. One is for 2.4,
> the other for 2.5.
Applied to both trees, thanks.
greg k-h
__
> Yes, I'm working around the current 16 device limit issue. Yes I push
> that limit out to 256, but that's a workable limit for today. If I
I agree. Unless you go for something more radical, you have gone
to the limit.
> wanted to abolish minor numbers all together, I could get an unlimited
Hi!
These two bk csets add another KVM switch which can't handle
get_report() USB request to the HID driver blacklist. One is for 2.4,
the other for 2.5.
Thanks.
--
Vojtech Pavlik
SuSE Labs
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to reposito
On Fri, Apr 26, 2002 at 06:54:37AM +0200, Oliver Neukum wrote:
> > > Devfs goes the whole way.
> > > Let's look at the basic function of major:minor combinations.
> > > You use them to assign names and permissions to a device.
> > > If minors become dynamic minors no longer have any function,
> >
On Fri, Apr 26, 2002 at 09:32:28AM -0700, David Brownell wrote:
> Can you merge this to Linus' tree?
>
> The patch cleans up the handling of connection checking to
> match the truth that it's effectively tristate (connected, not,
> and can't know) vs binary ("connected" and "can't know"
> as the
On Fri, Apr 26, 2002 at 10:13:31AM -0700, David Brownell wrote:
> Can you merge thispatch to Linus' tree?
>
> It mostly updates the description of the EHCI driver to point out
> that several non-NEC implementations are now expected to work,
> and that (high speed) ISO is supported.
Applied, than
Can you merge thispatch to Linus' tree?
It mostly updates the description of the EHCI driver to point out
that several non-NEC implementations are now expected to work,
and that (high speed) ISO is supported.
- Dave
doc-0426.patch
Description: Binary data
Can you merge this to Linus' tree?
The patch cleans up the handling of connection checking to
match the truth that it's effectively tristate (connected, not,
and can't know) vs binary ("connected" and "can't know"
as the same value, since it was OK to ifup). Since ethtool
supports the tristate s
21 matches
Mail list logo
