(CC Andy Shevchenko)
Hi again,
OK, got it:
7d8905d064058f4b65057e0101588f362f288bc0 is the first bad commit
commit 7d8905d064058f4b65057e0101588f362f288bc0
Author: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
Date: Mon Jul 24 20:28:32 2017 +0300
serial: 8250_pci: Enable device after we check black list
If the board we are guessing has been listed in black list we don't need
to enable it twice. The associated driver, if any, will take care about
proper initialization.
To achieve this we split out two helper functions, i.e.
serial_pci_is_class_communication() and serial_pci_is_blacklisted() which will
be called before pcim_enable_device(). We can do this since PCI specification
requires class, device and vendor ID registers to be always present in the
configuration space.
As an example what happens before this patch applied
(These are some debug prints, don't search for them in kernel sources):
serial 0000:00:04.1: Mapped GSI28 to IRQ28
serial 0000:00:04.2: Mapped GSI29 to IRQ29
serial 0000:00:04.3: Mapped GSI54 to IRQ54
8250_mid 0000:00:04.1: Mapped GSI28 to IRQ28
8250_mid 0000:00:04.2: Mapped GSI29 to IRQ29
8250_mid 0000:00:04.3: Mapped GSI54 to IRQ54
After we will have just last three lines out of above.
8250_mid 0000:00:04.1: Mapped GSI28 to IRQ28
8250_mid 0000:00:04.2: Mapped GSI29 to IRQ29
8250_mid 0000:00:04.3: Mapped GSI54 to IRQ54
While here, correct a value of error code mentioned in the comment of
serial_pci_guess_board().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Andy, this commit causes BrainBoxes 4100 multiport serial card to get
incorrect IRQ assigned since 4.14
here's card lspci entry:
02:00.0 0702: 135a:4100 (rev 02)
Subsystem: 135a:0443
Flags: fast devsel, IRQ 18
Memory at f7d02000 (32-bit, non-prefetchable) [size=128]
I/O ports at e000 [size=128]
I/O ports at e080 [size=64]
I/O ports at e0c0 [size=16]
Memory at f7d01000 (32-bit, non-prefetchable) [size=128]
Memory at f7d00000 (32-bit, non-prefetchable) [size=128]
Capabilities: [50] MSI: Enable- Count=1/4 Maskable- 64bit+
Capabilities: [78] Power Management version 3
Capabilities: [80] Express Legacy Endpoint, MSI 01
Capabilities: [100] Virtual Channel
Capabilities: [800] Advanced Error Reporting
after the commit, it gets IRQ 11 and doesn't work anymore..
any idea why could that be? I'm not sure I'm reading blacklist
definition correctly, but it seems to me it's not listed there..
would you mind having a look at it?
If I could be of any assistance, please let me know..
cheers
nik
On Thu, Feb 01, 2018 at 10:44:50AM +0100, Nikola Ciprich wrote:
>
> Hello Sebastian,
>
> > By no means I suggest to use polling and be done with it.
> > So the patch I sent fixes the list_add issue with auto-probing. That is
> > good. However it seems autoprobing did not find the right IRQ for the
> > device. This seems to be the only problem because it works (or pretends
> > to work) with polling.
> > I have no idea how to fix autoprobing. If you dig the old irq numbers
> > then they should work with 4.14. The other way might be to figure out
> > why the driver does not set proper irq numbers.
>
> OK, I suppose git bisect will be my friend here again :)
>
> I'l report when I find the culprit..
>
> thanks a lot for your help so far guys!
>
> nik
>
>
> >
> > > BR
> > >
> > > nik
> >
> > Sebastian
> >
>
> --
> -------------------------------------
> Ing. Nikola CIPRICH
> LinuxBox.cz, s.r.o.
> 28.rijna 168, 709 00 Ostrava
>
> tel.: +420 591 166 214
> fax: +420 596 621 273
> mobil: +420 777 093 799
> www.linuxbox.cz
>
> mobil servis: +420 737 238 656
> email servis: servis@xxxxxxxxxxx
> -------------------------------------
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28.rijna 168, 709 00 Ostrava
tel.: +420 591 166 214
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@xxxxxxxxxxx
-------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
