Eric Lee / smarc-fsl-linux-kernel

26 Jul, 2017

1 commit

25 Jul, 2017

2 commits

09 Jun, 2017

15 commits

08 Jun, 2017

4 commits

23 Feb, 2017

5 commits

20 Jan, 2017

5 commits

  • eca02f01b   Clearing FIFOs in RS485 emulation mode causes subsequent transmits to break ... Browse Code »

    commit 2bed8a8e70729f996af92042d3ad0f11870acc1f upstream.

    When in RS485 emulation mode, __do_stop_tx_rs485() calls
    serial8250_clear_fifos(). This not only clears the FIFOs, but also sets
    all bits in their control register (UART_FCR) to 0.

    One of the effects of this is the disabling of the FIFOs, which turns
    them into single-byte holding registers. The rest of the driver doesn't
    know this, which results in the lions share of characters passed into a
    write call to be dropped.

    (I can supply logic analyzer screenshots if necessary)

    This fix replaces the serial8250_clear_fifos() call to
    serial8250_clear_and_reinit_fifos() - this prevents the "dropped
    characters" issue from manifesting again while retaining the requirement
    of clearing the RX FIFO after transmission if the SER_RS485_RX_DURING_TX
    flag is disabled.

    Signed-off-by: Daniel Jedrychowski
    Signed-off-by: Greg Kroah-Hartman

    Daniel Jedrychowski
     
  • ef8ee4495   sysrq: attach sysrq handler correctly for 32-bit kernel ... Browse Code »

    commit 802c03881f29844af0252b6e22be5d2f65f93fd0 upstream.

    The sysrq input handler should be attached to the input device which has
    a left alt key.

    On 32-bit kernels, some input devices which has a left alt key cannot
    attach sysrq handler. Because the keybit bitmap in struct input_device_id
    for sysrq is not correctly initialized. KEY_LEFTALT is 56 which is
    greater than BITS_PER_LONG on 32-bit kernels.

    I found this problem when using a matrix keypad device which defines
    a KEY_LEFTALT (56) but doesn't have a KEY_O (24 == 56%32).

    Cc: Jiri Slaby
    Signed-off-by: Akinobu Mita
    Acked-by: Dmitry Torokhov
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Greg Kroah-Hartman

    Akinobu Mita
     
  • ba04d8699   tty/serial: atmel_serial: BUG: stop DMA from transmitting in stop_tx ... Browse Code »

    commit 89d8232411a85b9a6b12fd5da4d07d8a138a8e0c upstream.

    If we don't disable the transmitter in atmel_stop_tx, the DMA buffer
    continues to send data until it is emptied.
    This cause problems with the flow control (CTS is asserted and data are
    still sent).

    So, disabling the transmitter in atmel_stop_tx is a sane thing to do.

    Tested on at91sam9g35-cm(DMA)
    Tested for regressions on sama5d2-xplained(Fifo) and at91sam9g20ek(PDC)

    Signed-off-by: Richard Genoud
    Acked-by: Nicolas Ferre
    Signed-off-by: Greg Kroah-Hartman

    Richard Genoud
     
  • 2d789bd1f   tty/serial: atmel: RS485 half duplex w/DMA: enable RX after TX is done ... Browse Code »

    commit b389f173aaa1204d6dc1f299082a162eb0491545 upstream.

    When using RS485 in half duplex, RX should be enabled when TX is
    finished, and stopped when TX starts.

    Before commit 0058f0871efe7b01c6 ("tty/serial: atmel: fix RS485 half
    duplex with DMA"), RX was not disabled in atmel_start_tx() if the DMA
    was used. So, collisions could happened.

    But disabling RX in atmel_start_tx() uncovered another bug:
    RX was enabled again in the wrong place (in atmel_tx_dma) instead of
    being enabled when TX is finished (in atmel_complete_tx_dma), so the
    transmission simply stopped.

    This bug was not triggered before commit 0058f0871efe7b01c6
    ("tty/serial: atmel: fix RS485 half duplex with DMA") because RX was
    never disabled before.

    Moving atmel_start_rx() in atmel_complete_tx_dma() corrects the problem.

    Reported-by: Gil Weber
    Fixes: 0058f0871efe7b01c6
    Tested-by: Gil Weber
    Signed-off-by: Richard Genoud
    Acked-by: Alexandre Belloni
    Signed-off-by: Greg Kroah-Hartman

    Richard Genoud
     
  • 1f363639e   Revert "tty: serial: 8250: add CON_CONSDEV to flags" ... Browse Code »

    commit 6741f551a0b26479de2532ffa43a366747e6dbf3 upstream.

    This commit needs to be reverted because it prevents people from
    using the serial console as a secondary console with input being
    directed to tty0.

    IOW, if you boot with console=ttyS0 console=tty0 then all kernels
    prior to this commit will produce output on both ttyS0 and tty0
    but input will only be taken from tty0. With this patch the serial
    console will always be the primary console instead of tty0,
    potentially preventing people from getting into their machines in
    emergency situations.

    Fixes: d03516df8375 ("tty: serial: 8250: add CON_CONSDEV to flags")
    Signed-off-by: Herbert Xu
    Signed-off-by: Greg Kroah-Hartman

    Herbert Xu
     

09 Jan, 2017

2 commits

  • a0357979d   sc16is7xx: Drop bogus use of IRQF_ONESHOT ... Browse Code »

    commit 04da73803c05dc1150ccc31cbf93e8cd56679c09 upstream.

    The use of IRQF_ONESHOT when registering an interrupt handler with
    request_irq() is non-sensical.

    Not only that, it also prevents the handler from being threaded when it
    otherwise should be w/ IRQ_FORCED_THREADING is enabled. This causes the
    following deadlock observed by Sean Nyekjaer on -rt:

    Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
    [..]
    rt_spin_lock_slowlock from queue_kthread_work
    queue_kthread_work from sc16is7xx_irq
    sc16is7xx_irq [sc16is7xx] from handle_irq_event_percpu
    handle_irq_event_percpu from handle_irq_event
    handle_irq_event from handle_level_irq
    handle_level_irq from generic_handle_irq
    generic_handle_irq from mxc_gpio_irq_handler
    mxc_gpio_irq_handler from mx3_gpio_irq_handler
    mx3_gpio_irq_handler from generic_handle_irq
    generic_handle_irq from __handle_domain_irq
    __handle_domain_irq from gic_handle_irq
    gic_handle_irq from __irq_svc
    __irq_svc from rt_spin_unlock
    rt_spin_unlock from kthread_worker_fn
    kthread_worker_fn from kthread
    kthread from ret_from_fork

    Fixes: 9e6f4ca3e567 ("sc16is7xx: use kthread_worker for tx_work and irq")
    Reported-by: Sean Nyekjaer
    Signed-off-by: Josh Cartwright
    Cc: linux-rt-users@vger.kernel.org
    Cc: Jakub Kicinski
    Cc: linux-serial@vger.kernel.org
    Cc: Sebastian Andrzej Siewior
    Signed-off-by: Julia Cartwright
    Acked-by: Jakub Kicinski
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Greg Kroah-Hartman

    Josh Cartwright
     
  • fbb28e764   vt: fix Scroll Lock LED trigger name ... Browse Code »

    commit 31b5929d533f5183972cf57a7844b456ed996f3c upstream.

    There is a disagreement between drivers/tty/vt/keyboard.c and
    drivers/input/input-leds.c with regard to what is a Scroll Lock LED
    trigger name: input calls it "kbd-scrolllock", but vt calls it
    "kbd-scrollock" (two l's).
    This prevents Scroll Lock LED trigger from binding to this LED by default.

    Since it is a scroLL Lock LED, this interface was introduced only about a
    year ago and in an Internet search people seem to reference this trigger
    only to set it to this LED let's simply rename it to "kbd-scrolllock".

    Also, it looks like this was supposed to be changed before this code was
    merged: https://lkml.org/lkml/2015/6/9/697 but it was done only on
    the input side.

    Signed-off-by: Maciej S. Szmigiero
    Acked-by: Samuel Thibault
    Signed-off-by: Greg Kroah-Hartman

    Maciej S. Szmigiero
     

28 Oct, 2016

3 commits

  • d0f4bce2b   tty: serial_core: fix NULL struct tty pointer access in uart_write_wakeup ... Browse Code »

    Since commit 761ed4a94582ab29 ("tty: serial_core: convert uart_close to
    use tty_port_close"), the serial console is broken on various systems
    and typing "reboot" splats the following on the serial console:

    INIT: Sending p[ 427.863916] BUG: unable to handle kernel NULL pointer dereference at 00000000000001e0
    [ 427.885156] IP: [] tty_wakeup+0xc/0x70
    [ 427.898337] PGD 0 [ 427.902051]
    [ 427.907498] Oops: 0000 [#1] PREEMPT SMP
    [ 427.917635] Modules linked in: nfsv3 nfs_acl nfs fscache lockd
    sunrpc grace edd af_packet cpufreq_conservative cpufreq_userspace
    cpufreq_powersave fuse loop md_mod dm_mod joydev hid_generic usbhid
    ipmi_ssif ohci_pci ohci_hcd ehci_pci ehci_hcd e1000e ptp firewire_ohci
    edac_core pps_core tpm_infineon sp5100_tco firewire_core acpi_cpufreq
    serio_raw pcspkr fjes usbcore shpchp edac_mce_amd tpm_tis ipmi_si
    tpm_tis_core i2c_piix4 k10temp sg ipmi_msghandler tpm sr_mod button
    cdrom kvm_amd kvm irqbypass crc_itu_t ast ttm drm_kms_helper drm
    fb_sys_fops sysimgblt sysfillrect syscopyarea i2c_algo_bit scsi_dh_rdac
    scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw ata_generic pata_atiixp
    [ 428.054179] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc1-1.g73e3f23-default #1
    [ 428.072868] Hardware name: System manufacturer System Product Name/KGP(M)E-D16, BIOS 0902 12/03/2010
    [ 428.094755] task: ffffffffa2c0d500 task.stack: ffffffffa2c00000
    [ 428.109717] RIP: 0010:[] [] tty_wakeup+0xc/0x70
    [ 428.128407] RSP: 0018:ffff9a1a5fc03df8 EFLAGS: 00010086
    [ 428.142184] RAX: ffff9a1857258000 RBX: ffffffffa3050ea0 RCX: 0000000000000000
    [ 428.159649] RDX: 000000000000001b RSI: 0000000000000000 RDI: 0000000000000000
    [ 428.177109] RBP: ffff9a1a5fc03e08 R08: 0000000000000000 R09: 0000000000000000
    [ 428.194547] R10: 0000000000021c77 R11: 0000000000000000 R12: ffff9a1857258000
    [ 428.212002] R13: 0000000000000000 R14: 0000000000000020 R15: 0000000000000020
    [ 428.229481] FS: 0000000000000000(0000) GS:ffff9a1a5fc00000(0000) knlGS:0000000000000000
    [ 428.248938] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 428.263726] CR2: 00000000000001e0 CR3: 0000000390c06000 CR4: 00000000000006f0
    [ 428.281331] Stack:
    [ 428.288696] ffffffffa3050ea0 ffff9a1857258000 ffff9a1a5fc03e18 ffffffffa24e0ab1
    [ 428.307064] ffff9a1a5fc03e40 ffffffffa24e8865 ffffffffa3050ea0 00000000000000c2
    [ 428.325456] 0000000000000046 ffff9a1a5fc03e78 ffffffffa24e8a5f ffffffffa3050ea0
    [ 428.343905] Call Trace:
    [ 428.352319] [ 428.356216] [] uart_write_wakeup+0x21/0x30

    The problem is for console ports, the serial port is not shutdown and
    interrupts may fire after the struct tty is gone. Simply calling the
    tty_port helper tty_port_tty_wakeup instead of tty_wakeup directly will
    ensure there is a valid struct tty.

    Fixes: 761ed4a94582ab29 ("tty: serial_core: convert uart_close to use tty_port_close")
    Reported-by: Borislav Petkov
    Reported-by: Mike Galbraith
    Cc: Jiri Slaby
    Cc: Greg Kroah-Hartman
    Cc: linux-serial@vger.kernel.org
    Signed-off-by: Rob Herring
    Signed-off-by: Greg Kroah-Hartman

    Rob Herring
     
  • 4dda864d7   tty: serial_core: Fix serial console crash on port shutdown ... Browse Code »

    The port->console flag is always false, as uart_console() is called
    before the serial console has been registered.

    Hence for a serial port used as the console, uart_tty_port_shutdown()
    will still be called when userspace closes the port, powering it down.
    This may lead to a system lock up when the serial console driver writes
    to the serial port's registers.

    To fix this, move the setting of port->console after the call to
    uart_configure_port(), which registers the serial console.

    Fixes: 761ed4a94582ab29 ("tty: serial_core: convert uart_close to use tty_port_close")
    Reported-by: Niklas Söderlund
    Signed-off-by: Geert Uytterhoeven
    Acked-by: Rob Herring
    Tested-by: Mugunthan V N
    Tested-by: Niklas Söderlund
    [robh: rebased on tty-linus]
    Signed-off-by: Rob Herring
    Signed-off-by: Greg Kroah-Hartman

    Geert Uytterhoeven
     
  • 9bcffe757   tty/serial: at91: fix hardware handshake on Atmel platforms ... Browse Code »

    After commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management
    when hardware handshake is enabled"), the hardware handshake wasn't
    functional anymore on Atmel platforms (beside SAMA5D2).

    To understand why, one has to understand the flag ATMEL_US_USMODE_HWHS
    first:
    Before commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management
    when hardware handshake is enabled"), this flag was never set.
    Thus, the CTS/RTS where only handled by serial_core (and everything
    worked just fine).

    This commit introduced the use of the ATMEL_US_USMODE_HWHS flag,
    enabling it for all boards when the user space enables flow control.

    When the ATMEL_US_USMODE_HWHS is set, the Atmel USART controller
    handles a part of the flow control job:
    - disable the transmitter when the CTS pin gets high.
    - drive the RTS pin high when the DMA buffer transfer is completed or
    PDC RX buffer full or RX FIFO is beyond threshold. (depending on the
    controller version).

    NB: This feature is *not* mandatory for the flow control to work.
    (Nevertheless, it's very useful if low latencies are needed.)

    Now, the specifics of the ATMEL_US_USMODE_HWHS flag:

    - For platforms with DMAC and no FIFOs (sam9x25, sam9x35, sama5D3,
    sama5D4, sam9g15, sam9g25, sam9g35)* this feature simply doesn't work.
    ( source: https://lkml.org/lkml/2016/9/7/598 )
    Tested it on sam9g35, the RTS pins always stays up, even when RXEN=1
    or a new DMA transfer descriptor is set.
    => ATMEL_US_USMODE_HWHS must not be used for those platforms

    - For platforms with a PDC (sam926{0,1,3}, sam9g10, sam9g20, sam9g45,
    sam9g46)*, there's another kind of problem. Once the flag
    ATMEL_US_USMODE_HWHS is set, the RTS pin can't be driven anymore via
    RTSEN/RTSDIS in USART Control Register. The RTS pin can only be driven
    by enabling/disabling the receiver or setting RCR=RNCR=0 in the PDC
    (Receive (Next) Counter Register).
    => Doing this is beyond the scope of this patch and could add other
    bugs, so the original (and working) behaviour should be set for those
    platforms (meaning ATMEL_US_USMODE_HWHS flag should be unset).

    - For platforms with a FIFO (sama5d2)*, the RTS pin is driven according
    to the RX FIFO thresholds, and can be also driven by RTSEN/RTSDIS in
    USART Control Register. No problem here.
    (This was the use case of commit 1cf6e8fc8341 ("tty/serial: at91: fix
    RTS line management when hardware handshake is enabled"))
    NB: If the CTS pin declared as a GPIO in the DTS, (for instance
    cts-gpios = ), the transmitter will be
    disabled.
    => ATMEL_US_USMODE_HWHS flag can be set for this platform ONLY IF the
    CTS pin is not a GPIO.

    So, the only case when ATMEL_US_USMODE_HWHS can be enabled is when
    (atmel_use_fifo(port) &&
    !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS))

    Tested on all Atmel USART controller flavours:
    AT91SAM9G35-CM (DMAC flavour), AT91SAM9G20-EK (PDC flavour),
    SAMA5D2xplained (FIFO flavour).

    * the list may not be exhaustive

    Cc: #4.4+ (beware, missing atmel_port variable)
    Fixes: 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled")
    Signed-off-by: Richard Genoud
    Acked-by: Alexandre Belloni
    Acked-by: Cyrille Pitchen
    Acked-by: Uwe Kleine-König
    Acked-by: Nicolas Ferre
    Signed-off-by: Greg Kroah-Hartman

    Richard Genoud
     

27 Oct, 2016

3 commits