linux-stable.git/drivers/tty/serial, branch linux-4.8.y Linux kernel stable tree sc16is7xx: Drop bogus use of IRQF_ONESHOT 2017-01-09T07:21:56+00:00 Josh Cartwright joshc@ni.com 2016-10-13T15:44:33+00:00 47090341ec97222f47c9ac7dc35b587b85bf1d0d 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 <sean.nyekjaer@prevas.dk> Signed-off-by: Josh Cartwright <joshc@ni.com> Cc: linux-rt-users@vger.kernel.org Cc: Jakub Kicinski <moorray3@wp.pl> Cc: linux-serial@vger.kernel.org Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Julia Cartwright <julia@ni.com> Acked-by: Jakub Kicinski <kubakici@wp.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <sean.nyekjaer@prevas.dk>
Signed-off-by: Josh Cartwright <joshc@ni.com>
Cc: linux-rt-users@vger.kernel.org
Cc: Jakub Kicinski <moorray3@wp.pl>
Cc: linux-serial@vger.kernel.org
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Julia Cartwright <julia@ni.com>
Acked-by: Jakub Kicinski <kubakici@wp.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty/serial: at91: fix hardware handshake on Atmel platforms 2016-11-18T09:51:49+00:00 Richard Genoud richard.genoud@gmail.com 2016-10-27T16:04:06+00:00 920a85ba43063ee9a3f244afa8fed19b3d9fd5dc commit 9bcffe7575b721d7b6d9b3090fe18809d9806e78 upstream. 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 = <&pioA PIN_PB31 GPIO_ACTIVE_LOW>), 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 Fixes: 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled") Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [nicolas.ferre@atmel.com: adapt to 4.4.x kernel for stable by adding the atmel_port variable declaration which was missing] Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 9bcffe7575b721d7b6d9b3090fe18809d9806e78 upstream.

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 = <&pioA PIN_PB31 GPIO_ACTIVE_LOW>), 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

Fixes: 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled")
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[nicolas.ferre@atmel.com: adapt to 4.4.x kernel for stable by adding
the atmel_port variable declaration which was missing]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: 8250_port: fix runtime PM use in __do_stop_tx_rs485() 2016-10-22T10:40:21+00:00 Andy Shevchenko andriy.shevchenko@linux.intel.com 2016-08-31T16:46:55+00:00 ddd80608530423ccd49a3d2ebdd3a4bd6331e7fa commit b3965767d86cf4534dfe1affbde0453d3224ed7f upstream. There are calls to serial8250_rpm_{get|put}() in __do_stop_tx_rs485() that are certainly placed in a wrong location. I dunno how it had been tested with runtime PM enabled because it is obvious "sleep in atomic context" error. Besides that serial8250_rpm_get() is called immediately after an IO just happened. It implies that the device is already powered on, see implementation of serial8250_em485_rts_after_send() and serial8250_clear_fifos() for the details. There is no bug have been seen due to, as I can guess, use of auto suspend mode when scheduled transaction to suspend is invoked quite lately than it's needed for a few writes to the port. It might be possible to trigger a warning if stop_tx_timer fires when device is suspended. Refactor the code to use runtime PM only in case of timer function. Fixes: 0c66940d584d ("tty/serial/8250: fix RS485 half-duplex RX") Cc: "Matwey V. Kornilov" <matwey@sai.msu.ru> Tested-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit b3965767d86cf4534dfe1affbde0453d3224ed7f upstream.

There are calls to serial8250_rpm_{get|put}() in __do_stop_tx_rs485() that are
certainly placed in a wrong location. I dunno how it had been tested with
runtime PM enabled because it is obvious "sleep in atomic context" error.

Besides that serial8250_rpm_get() is called immediately after an IO just
happened. It implies that the device is already powered on, see implementation
of serial8250_em485_rts_after_send() and serial8250_clear_fifos() for the
details.

There is no bug have been seen due to, as I can guess, use of auto suspend mode
when scheduled transaction to suspend is invoked quite lately than it's needed
for a few writes to the port. It might be possible to trigger a warning if
stop_tx_timer fires when device is suspended.

Refactor the code to use runtime PM only in case of timer function.

Fixes: 0c66940d584d ("tty/serial/8250: fix RS485 half-duplex RX")
Cc: "Matwey V. Kornilov" <matwey@sai.msu.ru>
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: 8250_dw: Check the data->pclk when get apb_pclk 2016-10-22T10:40:21+00:00 Kefeng Wang wangkefeng.wang@huawei.com 2016-08-24T08:33:33+00:00 80ece27ef25dc905fa0b00706757998a642e0d14 commit e16b46f190a22587898b331f9d58583b0b166c9a upstream. It should check the data->pclk, not data->clk when get apb_pclk. Fixes: c8ed99d4f6a8("serial: 8250_dw: Add support for deferred probing") Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e16b46f190a22587898b331f9d58583b0b166c9a upstream.

It should check the data->pclk, not data->clk when get apb_pclk.

Fixes: c8ed99d4f6a8("serial: 8250_dw: Add support for deferred probing")
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
BUG: atmel_serial: Interrupts not disabled on close 2016-10-22T10:40:21+00:00 Richard Genoud richard.genoud@gmail.com 2016-09-12T13:34:41+00:00 307475da695a7adcbd5bb40a3b238c7f6e1d9d52 commit 0ae9fdefb6c37237d826d6195e27810ffcc0b6e0 upstream. Since commit 18dfef9c7f87 ("serial: atmel: convert to irq handling provided mctrl-gpio"), interrupts from GPIOs are not disabled any more when the serial port is closed, leading to an oops when the one of the input pin is toggled (CTS/DSR/DCD/RNG). This is only the case if those pins are used as GPIOs, i.e. declared like that: usart1: serial@f8020000 { /* CTS and DTS will be handled by GPIO */ status = "okay"; rts-gpios = <&pioB 17 GPIO_ACTIVE_LOW>; cts-gpios = <&pioB 16 GPIO_ACTIVE_LOW>; dtr-gpios = <&pioB 14 GPIO_ACTIVE_LOW>; dsr-gpios = <&pioC 31 GPIO_ACTIVE_LOW>; rng-gpios = <&pioB 12 GPIO_ACTIVE_LOW>; dcd-gpios = <&pioB 15 GPIO_ACTIVE_LOW>; }; That's because modem interrupts used to be freed in atmel_shutdown(). After commit 18dfef9c7f87 ("serial: atmel: convert to irq handling provided mctrl-gpio"), this code was just removed. Calling atmel_disable_ms() disables the interrupts and everything works fine again. Tested on at91sam9g35-cm (This patch doesn't apply on -stable kernels, fixes for 4.4 and 4.7 will be sent after this one is applied.) Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Fixes: 18dfef9c7f87 ("serial: atmel: convert to irq handling provided mctrl-gpio") Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 0ae9fdefb6c37237d826d6195e27810ffcc0b6e0 upstream.

Since commit 18dfef9c7f87 ("serial: atmel: convert to irq handling
provided mctrl-gpio"), interrupts from GPIOs are not disabled any more
when the serial port is closed, leading to an oops when the one of the
input pin is toggled (CTS/DSR/DCD/RNG).

This is only the case if those pins are used as GPIOs, i.e. declared
like that:
usart1: serial@f8020000 {
        /* CTS and DTS will be handled by GPIO */
        status = "okay";
        rts-gpios = <&pioB 17 GPIO_ACTIVE_LOW>;
        cts-gpios = <&pioB 16 GPIO_ACTIVE_LOW>;
        dtr-gpios = <&pioB 14 GPIO_ACTIVE_LOW>;
        dsr-gpios = <&pioC 31 GPIO_ACTIVE_LOW>;
        rng-gpios = <&pioB 12 GPIO_ACTIVE_LOW>;
        dcd-gpios = <&pioB 15 GPIO_ACTIVE_LOW>;
};

That's because modem interrupts used to be freed in atmel_shutdown().
After commit 18dfef9c7f87 ("serial: atmel: convert to irq handling
provided mctrl-gpio"), this code was just removed.
Calling atmel_disable_ms() disables the interrupts and everything works
fine again.

Tested on at91sam9g35-cm

(This patch doesn't apply on -stable kernels, fixes for 4.4 and 4.7 will
be sent after this one is applied.)

Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Fixes: 18dfef9c7f87 ("serial: atmel: convert to irq handling provided mctrl-gpio")
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: imx: Fix DCD reading 2016-10-22T10:40:21+00:00 Sascha Hauer s.hauer@pengutronix.de 2016-09-26T13:55:31+00:00 40995fa3a240916c64a2946fb8a05431fc3c2bbf commit 4b75f80003617fe35771a9e27022e8fbd6a41875 upstream. The USR2_DCDIN bit is tested for in register usr1. As the name suggests the usr2 register should be used instead. This fixes reading the Carrier detect status. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Fixes: 90ebc4838666 ("serial: imx: repair and complete handshaking") Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 4b75f80003617fe35771a9e27022e8fbd6a41875 upstream.

The USR2_DCDIN bit is tested for in register usr1. As the name
suggests the usr2 register should be used instead. This fixes
reading the Carrier detect status.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Fixes: 90ebc4838666 ("serial: imx: repair and complete handshaking")
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: 8250: added acces i/o products quad and octal serial cards 2016-08-31T14:28:26+00:00 Jimi Damon jdamon@accesio.com 2016-07-21T00:00:40+00:00 c8d192428f52f244130b84650ad616df09f2b1e1 Added devices ids for acces i/o products quad and octal serial cards that make use of existing Pericom PI7C9X7954 and PI7C9X7958 configurations . Signed-off-by: Jimi Damon <jdamon@accesio.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Added devices ids for acces i/o products quad and octal serial cards
that make use of existing Pericom PI7C9X7954 and PI7C9X7958
configurations .

Signed-off-by: Jimi Damon <jdamon@accesio.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: 8250_mid: fix divide error bug if baud rate is 0 2016-08-31T13:49:26+00:00 Andy Shevchenko andriy.shevchenko@linux.intel.com 2016-07-01T14:21:49+00:00 47b34d2ef266e2c283b514d65c8963c2ccd42474 Since the commit c1a67b48f6a5 ("serial: 8250_pci: replace switch-case by formula for Intel MID"), the 8250 driver crashes in the byt_set_termios() function with a divide error. This is caused by the fact that a baud rate of 0 (B0) is not handled properly. Fix it by falling back to B9600 in this case. Reported-by: "Mendez Salinas, Fernando" <fernando.mendez.salinas@intel.com> Fixes: c1a67b48f6a5 ("serial: 8250_pci: replace switch-case by formula for Intel MID") Cc: stable@vger.kernel.org Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Since the commit c1a67b48f6a5 ("serial: 8250_pci: replace switch-case by
formula for Intel MID"), the 8250 driver crashes in the byt_set_termios()
function with a divide error. This is caused by the fact that a baud rate of 0
(B0) is not handled properly. Fix it by falling back to B9600 in this case.

Reported-by: "Mendez Salinas, Fernando" <fernando.mendez.salinas@intel.com>
Fixes: c1a67b48f6a5 ("serial: 8250_pci: replace switch-case by formula for Intel MID")
Cc: stable@vger.kernel.org
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "tty/serial/8250: use mctrl_gpio helpers" 2016-08-31T13:36:01+00:00 Andy Shevchenko andriy.shevchenko@linux.intel.com 2016-08-16T12:06:54+00:00 5db4f7f80d165fc9725f356e99feec409e446baa Serial console is broken in v4.8-rcX. Mika and I independently bisected down to commit 4ef03d328769 ("tty/serial/8250: use mctrl_gpio helpers"). Since neither author nor anyone else didn't propose a solution we better revert it for now. This reverts commit 4ef03d328769eddbfeca1f1c958fdb181a69c341. Link: https://lkml.kernel.org/r/20160809130229.GN1729@lahna.fi.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Serial console is broken in v4.8-rcX. Mika and I independently bisected down to
commit 4ef03d328769 ("tty/serial/8250: use mctrl_gpio helpers").

Since neither author nor anyone else didn't propose a solution we better revert
it for now.

This reverts commit 4ef03d328769eddbfeca1f1c958fdb181a69c341.

Link: https://lkml.kernel.org/r/20160809130229.GN1729@lahna.fi.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8250/fintek: rename IRQ_MODE macro 2016-08-18T16:16:13+00:00 Arnd Bergmann arnd@arndb.de 2016-08-10T21:54:13+00:00 87a713c8ffca33d8e497a8b6c02034332bd80394 A bugfix for the fintek driver required defining some macros, but one of them clashes with a system header on ARM: drivers/tty/serial/8250/8250_fintek.c:34:0: error: "IRQ_MODE" redefined [-Werror] #define IRQ_MODE 0x70 In file included from /git/arm-soc/arch/arm/include/asm/ptrace.h:13:0, from /git/arm-soc/arch/arm/include/asm/irqflags.h:6, from /git/arm-soc/include/linux/irqflags.h:15, from /git/arm-soc/arch/arm/include/asm/bitops.h:27, from /git/arm-soc/include/linux/bitops.h:36, from /git/arm-soc/include/linux/kernel.h:10, from /git/arm-soc/include/linux/list.h:8, from /git/arm-soc/include/linux/module.h:9, from /git/arm-soc/drivers/tty/serial/8250/8250_fintek.c:11: arch/arm/include/uapi/asm/ptrace.h:55:0: note: this is the location of the previous definition This renames the newly introduced 'IRQ_MODE' macro to FINTEK_IRQ_MODE. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 4da22f1418cb ("serial: 8250_fintek: fix the mismatched IRQ mode") Link: https://patchwork.kernel.org/patch/9200119/ Acked-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com> Acked-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
A bugfix for the fintek driver required defining some macros, but
one of them clashes with a system header on ARM:

drivers/tty/serial/8250/8250_fintek.c:34:0: error: "IRQ_MODE" redefined [-Werror]
 #define IRQ_MODE 0x70

In file included from /git/arm-soc/arch/arm/include/asm/ptrace.h:13:0,
                 from /git/arm-soc/arch/arm/include/asm/irqflags.h:6,
                 from /git/arm-soc/include/linux/irqflags.h:15,
                 from /git/arm-soc/arch/arm/include/asm/bitops.h:27,
                 from /git/arm-soc/include/linux/bitops.h:36,
                 from /git/arm-soc/include/linux/kernel.h:10,
                 from /git/arm-soc/include/linux/list.h:8,
                 from /git/arm-soc/include/linux/module.h:9,
                 from /git/arm-soc/drivers/tty/serial/8250/8250_fintek.c:11:
arch/arm/include/uapi/asm/ptrace.h:55:0: note: this is the location of the previous definition

This renames the newly introduced 'IRQ_MODE' macro to FINTEK_IRQ_MODE.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 4da22f1418cb ("serial: 8250_fintek: fix the mismatched IRQ mode")
Link: https://patchwork.kernel.org/patch/9200119/
Acked-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com>
Acked-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>