On Mon, Jan 07, 2019 at 10:55:28AM +0100, Gerhard Khüny wrote:
> On Mon, Jan 7, 2019 at 10:05 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, Jan 07, 2019 at 09:57:56AM +0100, Gerhard Khüny wrote:
> > > Hello,
> > >
> > > I have a question regarding the function
> > > serial_pci_is_class_communication() in 8250_pci:
> > >
> > > static int serial_pci_is_class_communication(struct pci_dev *dev) {
> > >
> > > /*
> > > * If it is not a communications device or the programming
> > > * interface is greater than 6, give up.
> > > */
> > > if ((((dev->class >> 8) != PCI_CLASS_COMMUNICATION_SERIAL) &&
> > > ((dev->class >> 8) != PCI_CLASS_COMMUNICATION_MULTISERIAL) &&
> > > ((dev->class >> 8) != PCI_CLASS_COMMUNICATION_MODEM)) ||
> > > (dev->class & 0xff) > 6)
> > > return -ENODEV;
> > >
> > > return 0;
> > >
> > > }
> > >
> > > We have implemented a serial interface in a FPGA. The existing driver
> > > 8250_pci is working perfect for us. Only the check using the function
> > > serial_pci_is_class_communication does not work since the PCI class is
> > > 0x05, subclass is 0x00 and programming interface is 0x00 for our
> > > device.
> >
> > Then fix your PCI device identifier structure :)
> >
> The problem is that the FPGA holds additional functionality (e.g. .
> RTC, Hex-switch,..). The device therefore is not a real serial device
> but it has implemented a serial interface.
Ok, then you need to add a pci id to the serial driver.
> > > My question is, if it is the intention to exclude PCI class memory
> > > devices implementing a serial driver? The comment in the code could
> > > say something different.
> >
> > If your device says it is a memory device and not a serial device, how
> > could the kernel "know" it is really a serial device?
> >
> Because the init function returns no error.
> Why not allow memory devices also?
Because the generic pci memory device class is not a serial device.
Again, please refer to the PCI specification for the details. You can
not have a generic class device suddenly be attached to a driver that is
not the same as that class device. For example, would you want your USB
keyboard driver to suddenly attach to all USB modem devices just because
one single vendor decided to implement keyboard functionality in a modem
device but lie about what the class type was?
Just add a new pci vendor/device id to the driver and you should be
fine. Or fix your pci device structure to not claim it is something
other than what it really is.
thanks,
greg k-h
