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
Great, Russell. Now we understand each other.
Actually some chip manufacturers are responsible for this mess. Some do
NOT burn a modem class flag in the hardware, others do.
Is it nonsense to imagine that the part of 8250_pci which handles modem
class become a loadable module?
We could
On Mon, Mar 21, 2005 at 10:57:21PM +0200, Jacques Goldberg wrote:
>
>Great, Russell. Now we understand each other.
>Actually some chip manufacturers are responsible for this mess. Some do
> NOT burn a modem class flag in the hardware, others do.
>Is it nonsense to imagine that the part
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
> [Generic])
Ok, this is what I wanted to know.
There seem
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
ric])
Subsystem: ARCHTEK TELECOM Corp: Unknown device 9100
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VG
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
On 080, 03 21, 2005 at 08:22:28AM +, 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 attach the file which Sasha, author or the l
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 attach the file which Sasha, author or the lmodem driver, has
> > modified and then it works for the chips hard-w
On 078, 03 19, 2005 at 08:33:14PM +0200, Jacques Goldberg wrote:
>
>Good news!
>That's really what is needed (mainline).
>I attach the file which Sasha, author or the lmodem driver, has
> modified and then it works for the chips hard-wired in the routine.
>To locate the patched are
Stuart,
Many thanks for this interesting approach.
A huge advantage is that it can be implemented as a script.
But:
-it still requires the Linux newcomer who wants his modem to work, to
recompile her/his kernel - something which frightens beginners.
-it implies that when adding a
On Fri, Mar 18, 2005 at 10:57:14AM +0200, Jacques Goldberg wrote:
>
> 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 s
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 spend some time on the hot unplug solution.
I think what you want might be accom
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 y
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)) but if you want to do it
properly you need to get th
14 matches
Mail list logo
