Hi Ed,
Thank you for the clear explanation.
As you probably have noticed, the last two entries of serial_pci_tbl[]
match PCI_ANY_ID for both vendor and device, respectively for serial ports
and modems. Therefore, any serial or modem PCI card is in
serial_pci_tbl[]! The associated entry in pci_boards[] is pbn_default
(=0). So, all "pbn_default" entries that match serial_pci_guess_board()
are marked as redundant!
Probably, the right way could be to replace the message "Redundant entry"
with something like:
"The settings of your serial card (vendor_id:dev_id) have been
successfully guessed. In order help developers add a proper entry for your
card, send this message along with the output of lspci -vv to
an_address_where_somebody_reads_your_messages@unlike_serial_pci_info_where_nobody_cares_about_you".
By the way, here is a patch that adds OXCB950 properly to
serial_pci_tbl[]. pbn_b0_bt_1_115200 has been used instead of
pbn_b0_1_115200, because the latter is identical to pbn_default, and the
effect should be the same since OXCB950 is single-port.
Another proposed change: why not create separate entries in pci_boards[]
for pbn_b0_1_115200 and pbn_default?
diff -ruN linux/drivers/char/serial.c linux-new/drivers/char/serial.c
--- linux/drivers/char/serial.c Fri Dec 21 18:41:54 2001
+++ linux-new/drivers/char/serial.c Fri Mar 1 09:43:42 2002
@@ -4658,6 +4658,9 @@
{ PCI_VENDOR_ID_OXSEMI, PCI_DEVICE_ID_OXSEMI_16PCI952,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_b0_2_115200 },
+ { PCI_VENDOR_ID_OXSEMI, PCI_DEVICE_ID_OXSEMI_OXCB950,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ pbn_b0_bt_1_115200 },
/* Digitan DS560-558, from [email protected] */
{ PCI_VENDOR_ID_ATT, PCI_DEVICE_ID_ATT_VENUS_MODEM,
diff -ruN linux/include/linux/pci_ids.h linux-new/include/linux/pci_ids.h
--- linux/include/linux/pci_ids.h Fri Dec 21 18:42:03 2001
+++ linux-new/include/linux/pci_ids.h Fri Mar 1 09:43:52 2002
@@ -1458,6 +1458,7 @@
#define PCI_DEVICE_ID_OXSEMI_12PCI840 0x8403
#define PCI_DEVICE_ID_OXSEMI_16PCI954 0x9501
#define PCI_DEVICE_ID_OXSEMI_16PCI952 0x950A
+#define PCI_DEVICE_ID_OXSEMI_OXCB950 0x950B
#define PCI_DEVICE_ID_OXSEMI_16PCI95N 0x9511
#define PCI_DEVICE_ID_OXSEMI_16PCI954PP 0x9513
Fabrizio Gennari
Philips Research Monza
via G.Casati 23, 20052 Monza (MI), Italy
tel. +39 039 2037816, fax +39 039 2037800
Ed Vance <[email protected]>
06/03/2002 01.56
To: Fabrizio Gennari/MOZ/RESEARCH/PHILIPS@EMEA1
"'Andrey Panin'" <[email protected]>
cc: "'Russell King'" <[email protected]>
"'linux-serial'" <[email protected]>
"'linux-kernel'" <[email protected]>
Subject: RE: Oxford Semiconductor's OXCB950 UART not recognized by serial. c
Classification:
Hi Fabrizio and Andrey,
About that function in serial.c, serial_pci_guess_board() ...
On Wed, Feb 20, 2002 at 7:14 AM, Fabrizio Gennari wrote:
> But, when not using serial_cb, the function serial_pci_guess_board
> in serial.c doesn't [recognize the 950 UART] (kernel 2.4.17 tested).
> The problem is that the card advertises 3 i/o memory regions and 2
> ports. If one replaces the line
>
> if (num_iomem <= 1 && num_port == 1) {
>
> with
>
> if (num_port >= 1) {
>
> in the function serial_pci_guess_board(), the card is detected and
> works perfectly. Only, when inserting it, the kernel displays the
> message:
>
> Redundant entry in serial pci_table. Please send the output of
> lspci -vv, this message (1415,950b,1415,0001)
> and the manufacturer and name of serial board or modem board
> to [email protected].
I have dug deeper and found that the "port type guessing" functionality
was broken when the driver was ported to the newer PCI interfaces. As
it is, the probe function in serial.c (serial_init_one()) is *never*
called for devices that do not already match an entry in the PCI id
table (serial_pci_tbl[]). The probe function is coded as if non-matching
devices would cause the probe to be called with a default table index of
zero (pbn_default). This does not happen, because pci_announce_device()
bypasses the probe call (pci.c:577) when the driver provides an id table
and pci_match_device() cannot find a match in the id table. (pci.c:574)
There is not much point in trying to guess the type of a port that has
already been identified. Devices that are not already in the table do
not cause the probe and guess functions to be called.
An older serial.c (rev 5.02 2000-08-09) checks each device against the
PCI id table and only attempts a guess if there were no matches.
At the very least, we could just rip out the guess function and not
change the requirement of already being in the table. Or an attempt
could be made to fix it to guess on devices that do not match the id
table, as it used to work. This would move the id scan back to serial.c
from the PCI subsystem.
Your opinions please. How should this be fixed? Is there a "right" way?
Best regards,
Ed Vance [email protected]