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 because the
PCI device is grabbed by the serial driver.
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?
We know how to attain the goal by patching 8250_pci.c but doing this will
quickly generate chaos. We know to detect the condition in the custom
driver. The fix would be trivial if we could break the tie with the
serial driver.
Thanks - Jacques
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 the relevant pci check into the serial driver
proper by submitting it to Russell King. That way the serial driver can
skip the PCI devices that turn out to be modems
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 want to do it
> properly you need to get the relevant pci check into the serial driver
> proper by submitting it to Russell King. That way the serial driver can
> skip the PCI devices that turn out to be modems
>
Thank you very much.
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.
This is my very last question: is there a script able to do that? Google
quotes their existence but no link found. Or a doc showing how to code
that in a program?
Many many thanks - Jacques
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 accomplished if the serial driver was
compiled as a module. Then have your driver grab all the PCI devices
it wants, and they shouldn't be grabbed by the serial driver when it
loads. If you can't get your driver to load before the serial driver
for whatever reason, unloading the serial driver should give up the
devices it had claimed.
..Stu
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 serial driver.
> As a result, it is not possible to load the special driver because the
> PCI device is grabbed by the serial driver.
>
> 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?
I have a patch around somewhere that provides a way to do this from
userspace and sysfs, but it's racy and not really acceptable in it's
current form. Search the lkml archives for details and the patch if you
are interested.
But that would require you to rebuild your kernel :)
And yes, we are working on adding this support for mainline, still
working on it...
thanks,
greg k-h
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 serial device such as an other modem, or
a serial scanner, the kernel ought again to be recompiled according to
the new hardware configuration.
-and at each kernel upgrade, often automatic in large organizations,
the kernel must again be tailored to the configuration.
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 spend some time on the hot unplug solution.
>
> I think what you want might be accomplished if the serial driver was
> compiled as a module. Then have your driver grab all the PCI devices
> it wants, and they shouldn't be grabbed by the serial driver when it
> loads. If you can't get your driver to load before the serial driver
> for whatever reason, unloading the serial driver should give up the
> devices it had claimed.
>
> ..Stu
>
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 area, look for 5457
I am an experimental physicist, not a computer expert. If this kind of
algorithm could be implemented in the mainlin 8250_pci.c , then I would
dream of looking for an /etc/config file containing such a list, whose
objects would be skipped by the serial driver.
Sorry to repeat myself, but avoiding the need for the users to
recompile a kernel should be the first worry when implementing a solution.
Thanks - Jacques
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 area, look for 5457
We can use PCI quirk here. Patch attached.
> I am an experimental physicist, not a computer expert. If this kind of
> algorithm could be implemented in the mainlin 8250_pci.c , then I would
> dream of looking for an /etc/config file containing such a list, whose
> objects would be skipped by the serial driver.
> Sorry to repeat myself, but avoiding the need for the users to
> recompile a kernel should be the first worry when implementing a solution.
It's not a reason to fill kernel code with ugly kludges :)
--
Andrey Panin | Linux and UNIX system administrator
[email protected] | PGP key: wwwkeys.pgp.net
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-wired in the routine.
> > To locate the patched area, look for 5457
>
> We can use PCI quirk here. Patch attached.
I haven't seen any mail in this thread which provides the complete
PCI ID information for these cards. Can someone oblige please, with:
lspci -vv
for the relevant card.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On 080, 03 21, 2005 at 08:22:28AM +0000, 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 lmodem driver, has
> > > modified and then it works for the chips hard-wired in the routine.
> > > To locate the patched area, look for 5457
> >
> > We can use PCI quirk here. Patch attached.
>
> I haven't seen any mail in this thread which provides the complete
> PCI ID information for these cards.
I took them from the patched 8250_pci.c file in Jacques' previous mail:
/*
* pci devices with appropriate class declared, but known as
* non modems or serial
*/
static struct pci_device_id __devinitdata non_serial_pci_tbl[] = {
{ PCI_VENDOR_ID_AL, PCI_DEVICE_ID_AL_M5451,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ PCI_VENDOR_ID_AL, 0x5457,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ PCI_VENDOR_ID_AL, 0x5459,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0, }
};
--
Andrey Panin | Linux and UNIX system administrator
[email protected] | PGP key: wwwkeys.pgp.net
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 rather than static, so that the
next such device could be added without having to recompile?
Jacques
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- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
Latency: 64
Interrupt: pin A routed to IRQ 10
Region 0: Memory at f4101000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at 1000 [size=256]
Capabilities: <available only to root>
and here is the corresponding /proc/pci
Bus 0, device 15, function 0:
Class 0703: PCI device 10b9:5459 (rev 0).
IRQ 10.
Master Capable. Latency=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 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-wired in the routine.
> > > To locate the patched area, look for 5457
> >
> > We can use PCI quirk here. Patch attached.
>
> I haven't seen any mail in this thread which provides the complete
> PCI ID information for these cards.Can someone oblige please, with:
>
> lspci -vv
>
> for the relevant card.
>
> --
> Russell King
> Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
> maintainer of:2.6 Serial core
>
[email protected]
>>>> Currently at TECHNION <<<<
PHONE: Technion=+(972)(0)(4)829.36.63
CERN=+(41)(22)767.73.85
FAX: Technion=+(972)(0)(4)829.39.01
CERN=+(41)(22)767.31.00
HOME: Haifa=+(972)(4)825.29.04
GSM portable: +(972)(0)544.29.36.63
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 seems to be growing evidence that 8250_pci should not claim the
"modem" class, but should match any such cards which do look like
serial ports by vendor/device IDs. The problem is that dropping the
modem class id match could leave a fair number of people in the lurch,
but I'm game to try it and see.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
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 of 8250_pci which handles modem
> class become a loadable module?
> We could then load the "linmodem" driver first, which would not disturb
> use of true modems.
No, that's not a reliable solution.
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 specific one.
I've been mentioning this need for over a year now (for a different
scenario) and it hasn't particularly been going anywhere. However,
your case boosts the reason why we need this functionality.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
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 then load the "linmodem" driver first, which would not disturb
use of true modems.
My suggestion is very likely going to reveal the depth of my ignorance
about kernel architecture, I guess.
Jacques
On Mon, 21 Mar 2005, Russell King wrote:
> 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 seems to be growing evidence that 8250_pci should not claim the
> "modem" class, but should match any such cards which do look like
> serial ports by vendor/device IDs.The problem is that dropping the
> modem class id match could leave a fair number of people in the lurch,
> but I'm game to try it and see.
>
> --
> Russell King
> Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
> maintainer of:2.6 Serial core
>
[email protected]
>>>> Currently at TECHNION <<<<
PHONE: Technion=+(972)(0)(4)829.36.63
CERN=+(41)(22)767.73.85
FAX: Technion=+(972)(0)(4)829.39.01
CERN=+(41)(22)767.31.00
HOME: Haifa=+(972)(4)825.29.04
GSM portable: +(972)(0)544.29.36.63
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 specific one.
Absolutely agreed. This is what I dreamt of when starting this thread.
My job is done now. The ball is in your hands.
I shall now become mute but shall read further.
If you ever need a real test you will always be welcome to send it to
me since I have a case hardware.
Thanks to all of you. Cheers. Jacques