linux-stable.git/drivers/tty/serial/8250, branch linux-5.18.y

tty: 8250: Add support for Brainboxes PX cards.

2022-08-17T12:42:23+00:00

[ Upstream commit ef5a03a26c87a760bc3d86b5af7b773e82f8b1b7 ]

Add support for some of the Brainboxes PCIe (PX) range of
serial cards, including the PX-101, PX-235/PX-246,
PX-203/PX-257, PX-260/PX-701, PX-310, PX-313,
PX-320/PX-324/PX-376/PX-387, PX-335/PX-346, PX-368, PX-420,
PX-803 and PX-846.

Signed-off-by: Cameron Williams 
Cc: stable 
Link: https://lore.kernel.org/r/AM5PR0202MB2564669252BDC59BF55A6E87C4879@AM5PR0202MB2564.eurprd02.prod.outlook.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

serial: 8250: Add proper clock handling for OxSemi PCIe devices

2022-08-17T12:42:23+00:00

[ Upstream commit 366f6c955d4d1a5125ffcd6875ead26a3c7a2a1c ]

Oxford Semiconductor PCIe (Tornado) 950 serial port devices are driven
by a fixed 62.5MHz clock input derived from the 100MHz PCI Express clock.

We currently drive the device using its default oversampling rate of 16
and the clock prescaler disabled, consequently yielding the baud base of
3906250.  This base is inadequate for some of the high-speed baud rates
such as 460800bps, for which the closest rate possible can be obtained
by dividing the baud base by 8, yielding the baud rate of 488281.25bps,
which is off by 5.9638%.  This is enough for data communication to break
with the remote end talking actual 460800bps, where missed stop bits
have been observed.

We can do better however, by taking advantage of a reduced oversampling
rate, which can be set to any integer value from 4 to 16 inclusive by
programming the TCR register, and by using the clock prescaler, which
can be set to any value from 1 to 63.875 in increments of 0.125 in the
CPR/CPR2 register pair.  The prescaler has to be explicitly enabled
though by setting bit 7 in the MCR or otherwise it is bypassed (in the
enhanced mode that we enable) as if the value of 1 was used.

Make use of these features then as follows:

- Set the baud base to 15625000, reflecting the minimum oversampling
  rate of 4 with the clock prescaler and divisor both set to 1.

- Override the `set_mctrl' and set the MCR shadow there so as to have
  MCR[7] always set and have the 8250 core propagate these settings.

- Override the `get_divisor' handler and determine a good combination of
  parameters by using a lookup table with predetermined value pairs of
  the oversampling rate and the clock prescaler and finding a pair that
  divides the input clock such that the quotient, when rounded to the
  nearest integer, deviates the least from the exact result.  Calculate
  the clock divisor accordingly.

  Scale the resulting oversampling rate (only by powers of two) if
  possible so as to maximise it, reducing the divisor accordingly, and
  avoid a divisor overflow for very low baud rates by scaling the
  oversampling rate and/or the prescaler even if that causes some
  accuracy loss.

  Also handle the historic spd_cust feature so as to allow one to set
  all the three parameters manually to arbitrary values, by keeping the
  low 16 bits for the divisor and then putting TCR in bits 19:16 and
  CPR/CPR2 in bits 28:20, sanitising the bit pattern supplied such as
  to clamp CPR/CPR2 values between 0.000 and 0.875 inclusive to 33.875.
  This preserves compatibility with any existing setups, that is where
  requesting a custom divisor that only has any bits set among the low
  16 the oversampling rate of 16 and the clock prescaler of 33.875 will
  be used as with the original 8250.

  Finally abuse the `frac' argument to store the determined bit patterns
  for the TCR, CPR and CPR2 registers.

- Override the `set_divisor' handler so as to set the TCR, CPR and CPR2
  registers from the `frac' value supplied.  Set the divisor as usual.

With the baud base set to 15625000 and the unsigned 16-bit UART_DIV_MAX
limitation imposed by `serial8250_get_baud_rate' standard baud rates
below 300bps become unavailable in the regular way, e.g. the rate of
200bps requires the baud base to be divided by 78125 and that is beyond
the unsigned 16-bit range.  The historic spd_cust feature can still be
used to obtain such rates if so required.

See Documentation/tty/device_drivers/oxsemi-tornado.rst for more details.

Signed-off-by: Maciej W. Rozycki 
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204181519450.9383@angie.orcam.me.uk
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

serial: 8250: Fold EndRun device support into OxSemi Tornado code

2022-08-17T12:42:22+00:00

[ Upstream commit 1f32c65bad24b9787d3e52843de375430e3df822 ]

The EndRun PTP/1588 dual serial port device is based on the Oxford
Semiconductor OXPCIe952 UART device with the PCI vendor:device ID set
for EndRun Technologies and uses the same sequence to determine the
number of ports available.  Despite that we have duplicate code
specific to the EndRun device.

Remove redundant code then and factor out OxSemi Tornado device
detection.

Signed-off-by: Maciej W. Rozycki 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204181516220.9383@angie.orcam.me.uk
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

serial: 8250_bcm2835aux: Add missing clk_disable_unprepare()

2022-08-17T12:42:12+00:00

[ Upstream commit b9f1736e475dba0d6da48fdcb831248ab1597886 ]

The error path when get clock frequency fails in bcm2835aux_serial
driver does not correctly disable the clock.

This flaw was found using a static analysis tool "Hulk Robot", which
reported the following warning when analyzing linux-next/master:

    drivers/tty/serial/8250/8250_bcm2835aux.c:
    warning: clk_disable_unprepare_missing.cocci

The cocci script checks for the existence of clk_disable_unprepare()
paired with clk_prepare_enable().

Add the missing clk_disable_unprepare() to the error path.

Fixes: fcc446c8aa63 ("serial: 8250_bcm2835aux: Add ACPI support")
Reported-by: Hulk Robot 
Reviewed-by: Florian Fainelli 
Signed-off-by: Guo Mengqi 
Link: https://lore.kernel.org/r/20220715023312.37808-1-guomengqi3@huawei.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

serial: 8250_bcm7271: Save/restore RTS in suspend/resume

2022-08-17T12:42:06+00:00

[ Upstream commit 3182efd036c1b955403d131258234896cbd9fbeb ]

Commit 9cabe26e65a8 ("serial: 8250_bcm7271: UART errors after resuming
from S2") prevented an early enabling of RTS during resume, but it did
not actively restore the RTS state after resume.

Fixes: 9cabe26e65a8 ("serial: 8250_bcm7271: UART errors after resuming from S2")
Signed-off-by: Doug Berger 
Signed-off-by: Florian Fainelli 
Link: https://lore.kernel.org/r/20220714031316.404918-1-f.fainelli@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

serial: 8250_fsl: Don't report FE, PE and OE twice

2022-08-17T12:42:04+00:00

[ Upstream commit 9d3aaceb73acadf134596a2f8db9c451c1332d3d ]

Some Freescale 8250 implementations have the problem that a single long
break results in one irq per character frame time. The code in
fsl8250_handle_irq() that is supposed to handle that uses the BI bit in
lsr_saved_flags to detect such a situation and then skip the second
received character. However it also stores other error bits and so after
a single frame error the character received in the next irq handling is
passed to the upper layer with a frame error, too.

So after a spike on the data line (which is correctly recognized as a
frame error) the following valid character is thrown away, because the
driver reports a frame error for that one, too.

To weaken this problem restrict saving LSR to only the BI bit.

Note however that the handling is still broken:

 - lsr_saved_flags is updated using orig_lsr which is the LSR content
   for the first received char, but there might be more in the FIFO, so
   a character is thrown away that is received later and not necessarily
   the one following the break.
 - The doubled break might be the 2nd and 3rd char in the FIFO, so the
   workaround doesn't catch these, because serial8250_rx_chars() doesn't
   handle the workaround.
 - lsr_saved_flags might have set UART_LSR_BI at the entry of
   fsl8250_handle_irq() which doesn't originate from
   fsl8250_handle_irq()'s "up->lsr_saved_flags |= orig_lsr &
   UART_LSR_BI;" but from e.g. from serial8250_tx_empty().
 - For a long or a short break this isn't about two characters, but more
   or only a single one.

Fixes: 9deaa53ac7fa ("serial: add irq handler for Freescale 16550 errata.")
Acked-by: Ilpo Järvinen 
Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/20220704085119.55900-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

serial: 8250: Export ICR access helpers for internal use

2022-08-17T12:41:59+00:00

[ Upstream commit cb5a40e3143bc64437858b337273fd63cc42e9c2 ]

Make ICR access helpers available outside 8250_port.c, however retain
them as ordinary static functions so as not to regress code generation.

This is because `serial_icr_write' is currently automatically inlined by
GCC, however `serial_icr_read' is not.  Making them both static inline
would grow code produced, e.g.:

$ i386-linux-gnu-size --format=gnu 8250_port-{old,new}.o
      text       data        bss      total filename
     15065       3378          0      18443 8250_port-old.o
     15289       3378          0      18667 8250_port-new.o

and:

$ riscv64-linux-gnu-size --format=gnu 8250_port-{old,new}.o
      text       data        bss      total filename
     16980       5306          0      22286 8250_port-old.o
     17124       5306          0      22430 8250_port-new.o

while making them external would needlessly add a new module interface
and lose the benefit from `serial_icr_write' getting inlined outside
8250_port.o.

Signed-off-by: Maciej W. Rozycki 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204181517500.9383@angie.orcam.me.uk
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

serial: 8250: Fix PM usage_count for console handover

2022-07-22T08:21:58+00:00

commit f9b11229b79c0fb2100b5bb4628a101b1d37fbf6 upstream.

When console is enabled, univ8250_console_setup() calls
serial8250_console_setup() before .dev is set to uart_port. Therefore,
it will not call pm_runtime_get_sync(). Later, when the actual driver
is going to take over univ8250_console_exit() is called. As .dev is
already set, serial8250_console_exit() makes pm_runtime_put_sync() call
with usage count being zero triggering PM usage count warning
(extra debug for univ8250_console_setup(), univ8250_console_exit(), and
serial8250_register_ports()):

[    0.068987] univ8250_console_setup ttyS0 nodev
[    0.499670] printk: console [ttyS0] enabled
[    0.717955] printk: console [ttyS0] printing thread started
[    1.960163] serial8250_register_ports assigned dev for ttyS0
[    1.976830] printk: console [ttyS0] disabled
[    1.976888] printk: console [ttyS0] printing thread stopped
[    1.977073] univ8250_console_exit ttyS0 usage:0
[    1.977075] serial8250 serial8250: Runtime PM usage count underflow!
[    1.977429] dw-apb-uart.6: ttyS0 at MMIO 0x4010006000 (irq = 33, base_baud = 115200) is a 16550A
[    1.977812] univ8250_console_setup ttyS0 usage:2
[    1.978167] printk: console [ttyS0] printing thread started
[    1.978203] printk: console [ttyS0] enabled

To fix the issue, call pm_runtime_get_sync() in
serial8250_register_ports() as soon as .dev is set for an uart_port
if it has console enabled.

This problem became apparent only recently because 82586a721595 ("PM:
runtime: Avoid device usage count underflows") added the warning
printout. I confirmed this problem also occurs with v5.18 (w/o the
warning printout, obviously).

Fixes: bedb404e91bb ("serial: 8250_port: Don't use power management for kernel console")
Cc: stable 
Tested-by: Tony Lindgren 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Tony Lindgren 
Signed-off-by: Ilpo Järvinen 
Link: https://lore.kernel.org/r/b4f428e9-491f-daf2-2232-819928dc276e@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

serial: 8250: fix return error code in serial8250_request_std_resource()

2022-07-22T08:21:57+00:00

commit 6e690d54cfa802f939cefbd2fa2c91bd0b8bd1b6 upstream.

If port->mapbase = NULL in serial8250_request_std_resource() , it need
return a error code instead of 0. If uart_set_info() fail to request new
regions by serial8250_request_std_resource() but the return value of
serial8250_request_std_resource() is 0, The system incorrectly considers
that the resource application is successful and does not attempt to
restore the old setting. A null pointer reference is triggered when the
port resource is later invoked.

Signed-off-by: Yi Yang 
Cc: stable 
Link: https://lore.kernel.org/r/20220628083515.64138-1-yiyang13@huawei.com
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Store to lsr_save_flags after lsr read

2022-06-22T12:28:08+00:00

commit be03b0651ffd8bab69dfd574c6818b446c0753ce upstream.

Not all LSR register flags are preserved across reads. Therefore, LSR
readers must store the non-preserved bits into lsr_save_flags.

This fix was initially mixed into feature commit f6f586102add ("serial:
8250: Handle UART without interrupt on TEMT using em485"). However,
that feature change had a flaw and it was reverted to make room for
simpler approach providing the same feature. The embedded fix got
reverted with the feature change.

Re-add the lsr_save_flags fix and properly mark it's a fix.

Link: https://lore.kernel.org/all/1d6c31d-d194-9e6a-ddf9-5f29af829f3@linux.intel.com/T/#m1737eef986bd20cf19593e344cebd7b0244945fc
Fixes: e490c9144cfa ("tty: Add software emulated RS485 support for 8250")
Cc: stable 
Acked-by: Uwe Kleine-König 
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Ilpo Järvinen 
Link: https://lore.kernel.org/r/f4d774be-1437-a550-8334-19d8722ab98c@linux.intel.com
Signed-off-by: Greg Kroah-Hartman