Oxford Semiconductor's OXCB950 UART not recognized by serial. c

Oxford Semiconductor's OXCB950 UART not recognized by serial. c

Post by Ed Vanc » Thu, 07 Mar 2002 10:00:13



Hi Fabrizio and Andrey,

About that function in serial.c, serial_pci_guess_board() ...


> 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


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,

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Oxford Semiconductor's OXCB950 UART not recognized by serial. c

Post by fabrizio.genn.. » Thu, 07 Mar 2002 18:20:12


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
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

        {       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 },


        {       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

 #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


06/03/2002 01.56






        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() ...


> 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


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,

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Oxford Semiconductor's OXCB950 UART not recognized by serial. c

Post by Ed Vanc » Fri, 08 Mar 2002 05:00:15



> 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[]!

Yes I saw that, but it would not probe my ST16C654 based
card unless there was a specific table entry for it. That's
why I thought something in there was broken. I will try again
with an OX16C954 based card. Maybe my 654 card is weird.

Quote:> 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!

Yes. Assuming an unknown card can get probed, the code that
calls serial_pci_guess_board is definitely broken. At least,
the test for "no matching specific list entry" is broken.
Do you know of any valid reason for the driver to message
about devices that were found in the specific list entries,
regardless of what the guess function detects?

Quote:> 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 to help developers add
> a proper entry for your card, send this message along with

If the settings were successfully guessed, why do we need a
proper entry? Shouldn't the specific id portion of the list
contain only devices that cannot be successfully guessed?
In essence, shouldn't all "single bare UART interface"
serial and modem cards work *without* an id table entry?
That's what the older driver version does.

> the output of lspci -vv to an_address_where_somebody_reads_

> about_you".

If we must log a message, shouldn't it be PCI id and class
info about cards that did not match and could not be guessed.
I think we are not supposed to do that because another driver
may yet attach the device. (Somebody please correct me if
that's not right.)

Quote:> 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?

I already have your patch. Thanks. Yes, the "no matching
specific list entry" test is broken.

I have been porting the known patches to 2.4.19-pre2 and
breaking them down to single ideas, and will start submitting
them shortly. Everything will be on linux-serial for comment.

Best regards,
Ed Vance

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. Oxford Semiconductor's OXCB950 UART not recognized by serial.c

We have 32-bit CardBus cards with OXCB950 CardBus (PCI ID 1415:950b) UART
chips on them (OXCB950 is the CardBus version of 16C950) . The module
serial_cb in the pcmcia-cs package recognizes them correctly. But, when
not using serial_cb, the function serial_pci_guess_board in serial.c
doesn't (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

And this is the output of lspci -vv, only the part relevant to the Oxford
card:

03:00.0 Serial controller: Oxford Semiconductor Ltd CardBus Device
(prog-if 06 [16950])
        Subsystem: Oxford Semiconductor Ltd: Unknown device 0001
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 11
        Region 0: I/O ports at 4800 [size=8]
        Region 1: Memory at 10c00000 (32-bit, non-prefetchable) [size=4K]
        Region 2: I/O ports at 4810 [size=16]
        Region 3: Memory at 10c01000 (32-bit, non-prefetchable) [size=4K]
        Region 4: Memory at 10c02000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [40] Power Management version 1
                Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA
PME(D0+,D1-,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Fabrizio Gennari
Philips Research Monza
via G.Casati 23, 20052 Monza (MI), Italy
tel. +39 039 2037816, fax +39 039 2037800
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. nroff won't bold

3. OXCB950 support (was RE: Oxford Semiconductor's OXCB950 UART not recognized by serial. c)

4. all ports other than httpd(80) slow, why?

5. Oxford Semiconductor's OXCB950 UART not recognized by serial. c

6. This news group is invited to a Secret online book ! All Ages Welcome!

7. NEED HELP> Linux will not boot to x with my AGP vid card...more inside

8. PCI-Printerport Oxford-Semiconductors

9. Problem to use a Oxford semiconductor Intelligent DUAL Channe l UA RT (OX16PCI952)

10. Using an Oxford Semiconductor 840 Parport

11. Problem to use a Oxford semiconductor Intelligent DUAL Channe l UA RT (OX16PCI952)

12. PCI device ID Oxford 952 UART