Bug 25102

Created attachment 40632 [details]
diff against 2.6.32 w/ hackset to solve/workaround the problem

Greetings, 

  Kernel does not properly configures WCH CH353L-based PCI-devices (4-serial/2-serial+parallel port cards) by generic configure procedure:
  
04:00.0 Serial controller: Device 4348:3453 (rev 10) (prog-if 02 [16550])
	Subsystem: Device 4348:3453
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 21
	Region 0: I/O ports at d030 [size=8]
	Region 1: I/O ports at d020 [size=8]
	Region 2: I/O ports at d010 [size=8]
	Region 3: I/O ports at d000 [size=16]
	Kernel driver in use: serial

[    0.506535] PCI: Scanning bus 0000:04
[    0.506543] pci 0000:04:00.0: found [4348:3453] class 000700 header type 00
[    0.506556] pci 0000:04:00.0: reg 10 io port: [0xd030-0xd037]
[    0.506562] pci 0000:04:00.0: reg 14 io port: [0xd020-0xd027]
[    0.506569] pci 0000:04:00.0: reg 18 io port: [0xd010-0xd017]
[    0.506575] pci 0000:04:00.0: reg 1c io port: [0xd000-0xd00f]
[    0.506594] pci 0000:04:00.0: calling quirk_resource_alignment+0x0/0x161
[    0.506637] PCI: Fixups for bus 0000:04

  actual detection:
[    2.116580] serial 0000:04:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
[    2.116657] 0000:04:00.0: ttyS1 at I/O 0xd030 (irq = 21) is a XScale
[    2.116741] 0000:04:00.0: ttyS2 at I/O 0xd020 (irq = 21) is a XScale
[    2.116824] 0000:04:00.0: ttyS3 at I/O 0xd010 (irq = 21) is a XScale

  should be like (actual detection w/ my patch applied):
[    2.109564] serial 0000:04:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
[    2.109633] 0000:04:00.0: ttyS5 at I/O 0xd030 (irq = 21) is a 16550A
[    2.109712] 0000:04:00.0: ttyS6 at I/O 0xd020 (irq = 21) is a 16550A
[    2.109790] 0000:04:00.0: ttyS7 at I/O 0xd010 (irq = 21) is a 16550A
[    2.109868] 0000:04:00.0: ttyS8 at I/O 0xd000 (irq = 21) is a 16550A

1. Does not detect 4-th port, because it has 16-byted i/o region instead of expected 8-byted.
  My patch solving that by registering specific attributes for CH353L-based boards (based on autodetection; I'm not sure that all these are 100%-correct, but device seems to works fine with them).

2. 16550A detect procedure incorrectly recognizes CH353's ports as "XScale" ones (because CH353 uses IER 6th bit too), so ports can't work properly even after setserial(8) correction.
  Unfortunately, I could only work that around, by commenting-out ambigous XScale-serial detection code, in order to let ports be recognized as 16550A-compatible (as it is).

Additional information:

Hardware (chip) specifications:
  http://wch-ic.com/download/list.asp?id=118
  http://wch-ic.com/download/list.asp?id=119

kernel fingerprint:
  Linux version 2.6.32-5-686 (Debian 2.6.32-29) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Fri Dec 10 16:12:40 UTC 2010

dmesgs (original & hacked):
  http://cloudwheel.c-tori.ru/wch353/dmesg.original
  http://cloudwheel.c-tori.ru/wch353/dmesg.hacked

NOTE: In original dmesg, it may seems that 4-th port was not configured because serial driver configured only for 4 post, but it's not - there is no error message like "Couldn't register serial port 0000:04:00.0: -28".

Kind regards.