1. 07 11月, 2014 2 次提交
    • A
      serial: 8250_pci: Check mapping in pci_ni8430_init · 5d14bba9
      Aaron Sierra 提交于
      Check the return value of ioremap_nocache to make sure we got a
      valid mapping.
      Signed-off-by: NAaron Sierra <asierra@xes-inc.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5d14bba9
    • A
      serial: 8250_pci: Handle devices mapped above 4 GiB · 398a9db6
      Aaron Sierra 提交于
      Several init/setup functions passed the PCI BAR resource start address
      to ioremap_nocache() via an unsigned long. This caused address truncation
      for a 32-bit device mapped above 4 GiB (i.e. the CPU interacts with the
      device via a translated address), which resulted in a kernel panic.
      
      This patch replaces all of the instances of intermediate variable use
      with pci_ioremap_bar() to ensure the full resource_size_t start address
      is used and that ioremap_nocache() is still called.
      
      The kernel panic (Exar XR17V358 PCIe device on a Freescale P2020 SBC):
      
      Machine check in kernel mode.
      Caused by (from MCSR=10008): Bus - Read Data Bus Error
      Oops: Machine check, sig: 7 [#1]
      SMP NR_CPUS=2 X-ES P2020
      Modules linked in:
      CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.14.15-xes_r2-00002-g560e401 #978
      task: bf850000 ti: bffee000 task.ti: bf84c000
      NIP: 80318e10 LR: 80319ecc CTR: 80318dfc
      REGS: bffeff10 TRAP: 0204   Not tainted  (3.14.15-xes_r2-00002-g560e401)
      MSR: 00021000 <CE,ME>  CR: 20adbe42  XER: 00000000
      DEAR: c1058001 ESR: 00000000
      GPR00: 00000000 bf84db30 bf850000 80cb4af8 00000001 00000000 80000007 80000000
      GPR08: bf837c9c c1058001 00000001 00000000 80000007 00000000 80002a10 00000000
      GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 80cb0000 80c72dc4
      GPR24: 80cb4900 fffffffe 00029000 00000001 bf8c11e8 ffffffea 80c72ce4 80cb4af8
      NIP [80318e10] mem_serial_in+0x14/0x28
      LR [80319ecc] serial8250_config_port+0x160/0xe38
      Call Trace:
      [bf84db30] [80319d94] serial8250_config_port+0x28/0xe38 (unreliable)
      [bf84db60] [80315e3c] uart_add_one_port+0x148/0x3a4
      [bf84dbf0] [8031bf40] serial8250_register_8250_port+0x2dc/0x3c8
      [bf84dc20] [8032111c] pciserial_init_ports+0xd4/0x1c0
      [bf84dd50] [803212f8] pciserial_init_one+0xf0/0x224
      [bf84dd90] [802d8ff4] local_pci_probe+0x34/0x8c
      [bf84dda0] [802d92c8] pci_device_probe+0x84/0xa0
      [bf84ddc0] [80329ee0] driver_probe_device+0xac/0x26c
      [bf84dde0] [8032a15c] __driver_attach+0xbc/0xc0
      [bf84de00] [80328388] bus_for_each_dev+0x90/0xcc
      [bf84de30] [80329cd0] driver_attach+0x24/0x34
      [bf84de40] [80328e28] bus_add_driver+0x104/0x1fc
      [bf84de60] [8032a8c8] driver_register+0x70/0x138
      [bf84de70] [802d93c0] __pci_register_driver+0x48/0x58
      [bf84de80] [8077e0e4] serial_pci_driver_init+0x24/0x34
      [bf84de90] [80002228] do_one_initcall+0x34/0x1b0
      [bf84df00] [80764294] kernel_init_freeable+0x138/0x1e8
      [bf84df30] [80002a24] kernel_init+0x14/0x108
      [bf84df40] [8000ef94] ret_from_kernel_thread+0x5c/0x64
      Instruction dump:
      800800c4 7d290214 39290001 7c0004ac 7ca049ae 7c0004ac 4e800020 88030035
      81230008 7c840030 7d292214 7c0004ac <88690000> 0c030000 4c00012c 5463063e
      ---[ end trace e3c16443b5d573c6 ]---
      Signed-off-by: NAaron Sierra <asierra@xes-inc.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      398a9db6
  2. 06 11月, 2014 1 次提交
  3. 29 9月, 2014 2 次提交
  4. 11 9月, 2014 2 次提交
  5. 18 7月, 2014 1 次提交
  6. 29 5月, 2014 2 次提交
  7. 09 3月, 2014 2 次提交
  8. 14 2月, 2014 1 次提交
    • D
      serial: 8250_pci: unbreak last serial ports on NetMos 9865 cards · 333c085e
      Dmitry Eremin-Solenikov 提交于
      Aparently 9865 uses standard BAR encoding scheme (unlike 99xx cards).
      Current pci_netmos_9900_setup() uses wrong BAR indices for the 9865 PCI
      device, function 2. Using standard BAR indices makes all 6 ports work
      for me. Thus disable the NetMos 9900 quirk for NetMos 9865 pci device.
      
      For the reference, here is the relevant part of lspci for my device:
      
      02:07.0 Serial controller: MosChip Semiconductor Technology Ltd. PCI
      9865 Multi-I/O Controller (prog-if 02 [16550])
      	Subsystem: Device a000:1000
      	Flags: bus master, medium devsel, latency 32, IRQ 17
      	I/O ports at ac00 [size=8]
      	Memory at fcfff000 (32-bit, non-prefetchable) [size=4K]
      	Memory at fcffe000 (32-bit, non-prefetchable) [size=4K]
      	Capabilities: [48] Power Management version 2
      	Kernel driver in use: serial
      
      02:07.1 Serial controller: MosChip Semiconductor Technology Ltd. PCI
      9865 Multi-I/O Controller (prog-if 02 [16550])
      	Subsystem: Device a000:1000
      	Flags: bus master, medium devsel, latency 32, IRQ 18
      	I/O ports at a800 [size=8]
      	Memory at fcffd000 (32-bit, non-prefetchable) [size=4K]
      	Memory at fcffc000 (32-bit, non-prefetchable) [size=4K]
      	Capabilities: [48] Power Management version 2
      	Kernel driver in use: serial
      
      02:07.2 Communication controller: MosChip Semiconductor Technology Ltd.
      PCI 9865 Multi-I/O Controller
      	Subsystem: Device a000:3004
      	Flags: bus master, medium devsel, latency 32, IRQ 19
      	I/O ports at a400 [size=8]
      	I/O ports at a000 [size=8]
      	I/O ports at 9c00 [size=8]
      	I/O ports at 9800 [size=8]
      	Memory at fcffb000 (32-bit, non-prefetchable) [size=4K]
      	Capabilities: [48] Power Management version 2
      	Kernel driver in use: serial
      Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      333c085e
  9. 08 1月, 2014 1 次提交
  10. 20 12月, 2013 2 次提交
  11. 09 12月, 2013 1 次提交
  12. 20 10月, 2013 1 次提交
  13. 18 10月, 2013 1 次提交
  14. 01 10月, 2013 1 次提交
  15. 28 9月, 2013 1 次提交
  16. 27 9月, 2013 1 次提交
  17. 27 7月, 2013 3 次提交
  18. 01 7月, 2013 1 次提交
  19. 16 3月, 2013 1 次提交
    • W
      serial: 8250_pci: Add WCH CH352 quirk to avoid Xscale detection · 8b5c913f
      Wang YanQing 提交于
      The code in 8250.c for detecting ARM/XScale UARTs says:
      
        * Try writing and reading the UART_IER_UUE bit (b6).
        * If it works, this is probably one of the Xscale platform's
        * internal UARTs.
      
      If the above passes, it then goes on to:
      
           * It's an Xscale.
           * We'll leave the UART_IER_UUE bit set to 1 (enabled).
      
      However, the CH352 uses the UART_IER_UUE as the LOWPOWER function,
      so it is readable and writable.  According to the datasheet:
      
          "LOWPOWER:When the bit is 1, close the internal benchmark
           clock of serial port to set into low-power status.
      
      So it essentially gets mis-detected as Xscale, and gets
      powered down in the process.  The device in question where
      this was seen is listed by lspci as:
      
       Serial controller: Device 4348:3253 (rev 10) (prog-if 02 [16550])
      
      Re-using the 353 quirk which just sets flags to fixed and type
      to 16550 is suitable for fixing the 352 as well.
      Signed-off-by: NWang YanQing <udknight@gmail.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8b5c913f
  20. 12 3月, 2013 2 次提交
    • W
      serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller · 8d2f8cd4
      Wang YanQing 提交于
      01:08.0 Communication controller: NetMos Technology PCI 9835 Multi-I/O Controller (rev 01)
      	Subsystem: Device [1000:0012]
      	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 20
      	Region 0: I/O ports at e050 [size=8]
      	Region 1: I/O ports at e040 [size=8]
      	Region 2: I/O ports at e030 [size=8]
      	Region 3: I/O ports at e020 [size=8]
      	Region 4: I/O ports at e010 [size=8]
      	Region 5: I/O ports at e000 [size=16]
      Signed-off-by: NWang YanQing <udknight@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8d2f8cd4
    • S
      Fix 4 port and add support for 8 port 'Unknown' PCI serial port cards · d13402a4
      Scott Ashcroft 提交于
      I've managed to find an 8 port version of the card 4 port card which was discussed here:
      
      http://marc.info/?l=linux-serial&m=120760744205314&w=2
      
      Looking back at that thread there were two issues in the original patch.
      
      1) The I/O ports for the UARTs are within BAR2 not BAR0. This can been seen in the original post.
      2) A serial quirk isn't needed as these cards have no memory in BAR0 which makes pci_plx9050_init just return.
      
      This patch fixes the 4 port support to use BAR2, removes the bogus quirk and adds support for the 8 port card.
      
      $ lspci -vvv -n -s 00:08.0
      00:08.0 0780: 10b5:9050 (rev 01)
      	Subsystem: 10b5:1588
      	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 17
      	Region 1: I/O ports at ff00 [size=128]
      	Region 2: I/O ports at fe00 [size=64]
      	Region 3: I/O ports at fd00 [size=8]
      	Capabilities: <access denied>
      	Kernel driver in use: serial
      
      $ dmesg | grep 0000:00:08.0:
      [    0.083320] pci 0000:00:08.0: [10b5:9050] type 0 class 0x000780
      [    0.083355] pci 0000:00:08.0: reg 14: [io  0xff00-0xff7f]
      [    0.083369] pci 0000:00:08.0: reg 18: [io  0xfe00-0xfe3f]
      [    0.083382] pci 0000:00:08.0: reg 1c: [io  0xfd00-0xfd07]
      [    0.083460] pci 0000:00:08.0: PME# supported from D0 D3hot
      [    1.212867] 0000:00:08.0: ttyS4 at I/O 0xfe00 (irq = 17) is a 16550A
      [    1.233073] 0000:00:08.0: ttyS5 at I/O 0xfe08 (irq = 17) is a 16550A
      [    1.253270] 0000:00:08.0: ttyS6 at I/O 0xfe10 (irq = 17) is a 16550A
      [    1.273468] 0000:00:08.0: ttyS7 at I/O 0xfe18 (irq = 17) is a 16550A
      [    1.293666] 0000:00:08.0: ttyS8 at I/O 0xfe20 (irq = 17) is a 16550A
      [    1.313863] 0000:00:08.0: ttyS9 at I/O 0xfe28 (irq = 17) is a 16550A
      [    1.334061] 0000:00:08.0: ttyS10 at I/O 0xfe30 (irq = 17) is a 16550A
      [    1.354258] 0000:00:08.0: ttyS11 at I/O 0xfe38 (irq = 17) is a 16550A
      Signed-off-by: NScott Ashcroft <scott.ashcroft@talk21.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d13402a4
  21. 30 1月, 2013 1 次提交
  22. 18 1月, 2013 1 次提交
  23. 16 1月, 2013 4 次提交
  24. 22 11月, 2012 5 次提交