It would seem that I have a modem (hardware based, not winmodem) of
PCI_CLASS_COMMUNICATION_OTHER. This, unfortunately, prevents it from
being automagically detected by the serial driver, which only looks for
devices of PCI_CLASS_COMMUNICATION_SERIAL.
I've fixed this here merely by adding an entry to the PCI table of
serial.c for PCI_CLASS_COMMUNICATION_OTHER. Is this the best way to fix
this? Is there some reason that this shouldn't be done in general? If
not, I'd like to see it fix in the kernel proper.
It should be noted that the modem is listed in serial.c's pci_boards,
perhaps it would be best for the serial driver to list PCI_ID_ANY for a
class, and only use pci_boards to further identify serial ports? Or
would this be too inefficient to correct for a few misguided hardware
makers?
Thanks
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
Steven Walter wrote:
>
> It would seem that I have a modem (hardware based, not winmodem) of
> PCI_CLASS_COMMUNICATION_OTHER. This, unfortunately, prevents it from
> being automagically detected by the serial driver, which only looks for
> devices of
>
> I've fixed this here merely by adding an entry to the PCI table of
> serial.c for PCI_CLASS_COMMUNICATION_OTHER. Is this the best way to fix
> this? Is there some reason that this shouldn't be done in general? If
> not, I'd like to see it fix in the kernel proper.
That won't work for a general rule, since winmodems list themselves as
'OTHER' too. Just add your PCI id above the
PCI_CLASS_COMMUNICATION_SERIAL.
Make sure you cc me and [email protected] on such a patch...
--
Jeff Garzik | The difference between America and England is that
Building 1024 | the English think 100 miles is a long distance and
MandrakeSoft | the Americans think 100 years is a long time.
| (random fortune)
> I've fixed this here merely by adding an entry to the PCI table of
> serial.c for PCI_CLASS_COMMUNICATION_OTHER. Is this the best way to fix
> this? Is there some reason that this shouldn't be done in general? If
> not, I'd like to see it fix in the kernel proper.
Most class other devices wont be 16x50 compatible.
> It should be noted that the modem is listed in serial.c's pci_boards,
> perhaps it would be best for the serial driver to list PCI_ID_ANY for a
> class, and only use pci_boards to further identify serial ports? Or
> would this be too inefficient to correct for a few misguided hardware
> makers?
Probably serial.c should look for class serial || (class_other && in table)
Alan Cox wrote:
>
> > I've fixed this here merely by adding an entry to the PCI table of
> > serial.c for PCI_CLASS_COMMUNICATION_OTHER. Is this the best way to fix
> > this? Is there some reason that this shouldn't be done in general? If
> > not, I'd like to see it fix in the kernel proper.
>
> Most class other devices wont be 16x50 compatible.
winmodems are class other
> > It should be noted that the modem is listed in serial.c's pci_boards,
> > perhaps it would be best for the serial driver to list PCI_ID_ANY for a
> > class, and only use pci_boards to further identify serial ports? Or
> > would this be too inefficient to correct for a few misguided hardware
> > makers?
>
> Probably serial.c should look for class serial || (class_other && in table)
no need to consider class other at all, since there are so many
exceptions. Build the serial.c pci table like
board 1
board 2
board 3
class 1
class 2
class 3
Special cases go before the classes. A 16x50 compatible class other is
definitely a special case...
On a side note, an outstanding to-do item for the serial driver is to
move its huge honkin' custom PCI table into the pci_device_id standard
table. The pci_device_id::driver_data member would then become an index
into the smaller custom PCI table.
--
Jeff Garzik | The difference between America and England is that
Building 1024 | the English think 100 miles is a long distance and
MandrakeSoft | the Americans think 100 years is a long time.
| (random fortune)