On Mon, 21 Mar 2005, Russell King wrote:
> What it comes back to is that we _need_ driver match priorities, so we
> can detect when a more specific driver for the device is loaded (iow
> one which matches by vendor+device rather than just class), unbind the
> existing driver, and bind the more
> On Mon, Mar 21, 2005 at 01:39:30PM +0200, Jacques Goldberg wrote:
> > Here is a modem which cannot be used because it is grabbed by the
> > serial driver:
> >
> > 00:0f.0 Modem: ALi Corporation SmartLink SmartPCI561 56K Modem (prog-if 00
> > [Gene
=64.
Non-prefetchable 32 bit memory at 0xf4101000 [0xf4101fff].
I/O at 0x1000 [0x10ff].
There are more such devices.
On Mon, 21 Mar 2005, Russell King wrote:
> On Mon, Mar 21, 2005 at 11:16:38AM +0300, Andrey Panin wrote:
> > On 078, 03 19, 2005 at 08:33:14PM +0200, Jacques Go
On Mon, 21 Mar 2005, Andrey Panin wrote:
> We can use PCI quirk here. Patch attached.
> It's not a reason to fill kernel code with ugly kludges :)
Sure. Thanks for the patch.
We just did not know about "quirk". This was the purpose of my call for
help.
Any idea how to make the table
On Mon, 21 Mar 2005, Andrey Panin wrote:
We can use PCI quirk here. Patch attached.
It's not a reason to fill kernel code with ugly kludges :)
Sure. Thanks for the patch.
We just did not know about quirk. This was the purpose of my call for
help.
Any idea how to make the table dynamic
[0xf4101fff].
I/O at 0x1000 [0x10ff].
There are more such devices.
On Mon, 21 Mar 2005, Russell King wrote:
On Mon, Mar 21, 2005 at 11:16:38AM +0300, Andrey Panin wrote:
On 078, 03 19, 2005 at 08:33:14PM +0200, Jacques Goldberg wrote:
That's really what is needed (mainline).
I
, Mar 21, 2005 at 01:39:30PM +0200, Jacques Goldberg wrote:
Here is a modem which cannot be used because it is grabbed by the
serial driver:
00:0f.0 Modem: ALi Corporation SmartLink SmartPCI561 56K Modem (prog-if 00
[Generic])
Ok, this is what I wanted to know.
There seems
On Mon, 21 Mar 2005, Russell King wrote:
What it comes back to is that we _need_ driver match priorities, so we
can detect when a more specific driver for the device is loaded (iow
one which matches by vendor+device rather than just class), unbind the
existing driver, and bind the more
.
Thanks again - Jacques
On Fri, 18 Mar 2005, Stuart MacDonald wrote:
> From: Jacques Goldberg
> > To be ugly or to never be up to date, that's the question.
> > We did patch 8250_pci.c but there is no way to build a
> > stable list of
> > the devices to
.
Thanks again - Jacques
On Fri, 18 Mar 2005, Stuart MacDonald wrote:
From: Jacques Goldberg
To be ugly or to never be up to date, that's the question.
We did patch 8250_pci.c but there is no way to build a
stable list of
the devices to be handled that way.
We will thus
On Fri, 18 Mar 2005, Alan Cox wrote:
> On Gwe, 2005-03-18 at 08:57, Jacques Goldberg wrote:
> >Question: is there a way, as of kernels 2.6.10 and above, to release the
> > device from the serial driver, without having to recompile the kernel?
>
> There is an ugly way (fake a
Not subscribing because this is a one time question.
Please Cc: to the reply address above , [EMAIL PROTECTED]
Several winmodem devices come with a hardware burnt-in identification
misleading the system to load the serial driver.
As a result, it is not possible to load the special driver
Not subscribing because this is a one time question.
Please Cc: to the reply address above , [EMAIL PROTECTED]
Several winmodem devices come with a hardware burnt-in identification
misleading the system to load the serial driver.
As a result, it is not possible to load the special driver
On Fri, 18 Mar 2005, Alan Cox wrote:
On Gwe, 2005-03-18 at 08:57, Jacques Goldberg wrote:
Question: is there a way, as of kernels 2.6.10 and above, to release the
device from the serial driver, without having to recompile the kernel?
There is an ugly way (fake a hot unplug 8)) butif you
14 matches
Mail list logo
