The maximum baud rate depends on the sampling rate.
HSCIF has a variable sampling rate and sets s->sampling_rate to zero,
hence use the minimum sampling rate of 8.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For low bit rates, the for-loop that reduces the divider returned by
sci_scbrr_calc() and picks the clock select value may terminate without
finding suitable values, leading to out-of-range divider and clock
select values.
sci_baud_calc_hscif() doesn't suffer from this problem, as it correctly
uses clamp().

Since there are only two relevant differences between HSCIF and other
variants w.r.t. bit rate configuration (fixed vs. variable sample rate,
and an additional factor of two), sci_scbrr_calc() and
sci_baud_calc_hscif() can be merged, fixing the issue with out-of-range
values.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When assuming D = 0.5 and F = 0, maximizing the receive margin M is
equivalent to maximizing the sample rate N.

Hence there's no need to calculate the receive margin, as we can obtain
the same result by iterating over all possible sample rates in reverse
order, and skipping parameter sets that don't provide a lower bit rate
error.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The algorithm to find the best parameters for the requested bit rate
calculates the relative bit rate error, using "(br * scrate) / 1000".
For small "br * scrate", this has two problems:
  - The quotient may be zero, leading to a division by zero error,
  - This may introduce a large rounding error.
Switch from relative to absolute bit rate error calculation to fix this.

The default baud rate generator values can be removed, as there will
always be one set of values that gives the smallest absolute error.

Print the best set of values when debugging.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If bps >= 1048576, the multiplication of the predivider and "bps" will
overflow, and both br and err will contain bogus values.
Skip the current and all higher clock select predividers when overflow
is detected.  Simplify the calculations using intermediates while we're
at it.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move the -1 offset of br to the assignment to *brr, so br cannot become
negative anymore, and update the clamp() call. Now all unsigned values
in sci_baud_calc_hscif() can become unsigned.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Transfer clock cleanup handling to the core device management code.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Blindly writing the default configuration value into the SCSCR register
may change the clock selection bits, breaking the serial console if the
current driver settings differ from the default settings.

Keep the current clock selection bits to prevent this from happening
on e.g. r8a7791/koelsch when support for the BRG will be added.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

As F is assumed to be zero in the receive margin formula, frame_len is
not used. Remove it, together with the sci_baud_calc_frame_len() helper
function.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>

Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

sci_port.sampling_rate is always non-zero, except for HSCIF, which uses
sci_baud_calc_hscif() instead of sci_scbrr_calc().
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

As no platform defines an interface clock the SCI driver always falls
back to a clock named "peripheral_clk".
  - On SH platforms that clock is the base clock for the SCI functional
    clock and has the same frequency,
  - On ARM platforms that clock doesn't exist, and clk_get() will return
    the default clock for the device.
We can thus make the functional clock mandatory and drop the interface
clock.

EPROBE_DEFER is handled for clocks that may be referenced from DT (i.e.
"fck", and the deprecated "sci_ick").

Cc: devicetree@vger.kernel.org
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>
[geert: Handle EPROBE_DEFER, reformat description, break long comment line]
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NRob Herring <robh@kernel.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

An spi_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The implementation of mux_console_device() is very similar to
uart_console_device(). Setting .data field in mux_console then we can
convert to use uart_console_device().
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NHelge Deller <deller@gmx.de>

The UART_DUMMY_DR_RX status bit is equal to (1 << 16), so a u16 is too small
to hold that value.  The result is that UART_DUMMY_DR_RX is never passed
to uart_insert_char().  This means that we're always accepting characters,
even when CREAD (in termios) is not set.
Signed-off-by: NTimur Tabi <timur@codeaurora.org>
Reviewed-by: NDave Martin <Dave.Martin@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 9119fba0.

This commit prevents from sending "big" file using Bluetooth.
When sending a lot of data quickly through the Bluetooth interface, and
after a variable amount of data sent, transfer fails with error:
    kernel: [  415.247453] Bluetooth: hci0 hardware error 0x00

Found on T100TA.

After reverting this commit, send works fine for any file size.
Signed-off-by: NFrederic Danis <frederic.danis@linux.intel.com>
Fixes: 9119fba0 (serial: 8250_dma: don't bother DMA with small transfers)
Cc: stable@vger.kernel.org
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The platforms that have this UART, but that don't have
separate PCI device for the DMA Engine, need to create the
HSU DMA Engine device separately.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

HSU (High Speed UART) DMA engine, like the name suggests, is
an integrated DMA engine for UART and UART alone. Therefore,
making the UART drivers responsible of selecting it and
removing the user selectable option for it. The UARTs with
this DMA engine can always select HSU_DMA when
SERIAL_8250_DMA option is enabled.
Suggested-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A recent patch to create common helper functions for modem control
lines created empty helper functions in a header file, but accidentally
did not mark them as 'static inline', which causes build errors:

drivers/tty/serial/mxs-auart.o: In function `mctrl_gpio_enable_ms':
mxs-auart.c:(.text+0x171c): multiple definition of `mctrl_gpio_enable_ms'
drivers/tty/serial/clps711x.o:clps711x.c:(.text+0x768): first defined here
drivers/tty/serial/mxs-auart.o: In function `mctrl_gpio_disable_ms':
mxs-auart.c:(.text+0x1720): multiple definition of `mctrl_gpio_disable_ms'
drivers/tty/serial/clps711x.o:clps711x.c:(.text+0x76c): first defined here

This adds the missing annotation, so the functions do not get placed
in each object file.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: ce59e48f ("serial: mctrl_gpio: implement interrupt handling")
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Intel MID UART quirks require already quite a bit of code
in 8250_pci.c. On new Intel platforms where it is used, the
integrated DMA engine no longer has its own PCI device, but
is instead configured from the UART's MMIO. That means we
will have to add even more code for handling just MID UARTs.

Instead of adding that to 8250_pci.c, splitting the support
of Intel MID UART into its own driver. Handling of the
integrated DMA engine becomes much simpler this way. Own
driver will also remove the need for things like specific
set_termios hooks for every board using this UART, and
simplify the handling of it in general.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for DT and command line based earlycon support for
lpuart and lpuart32 used on Freescale Vybrid and and QorIQ LS1021A
processors.
Signed-off-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We recently got rid of some modular code in this driver and also
got rid of the unused ".remove" function at the same time.  Thierry
noted that it was however possible to force the remove through the
bind/unbind interface.

Since this is a console device used on 2005 vintage 74xx based
powerpc embedded targets, and is essentially always used in
conjunction with SERIAL_MPSC_CONSOLE=y -- there is no sane reason
anyone would ever want to unbind the builtin driver and lose the
console.  So we just explicitly block bind/unbind operations and
prevent root from shooting themselves in the foot.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-serial@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a misplaced bracket in atmel_init_rs485 which sets
rs485-rx-during-tx and rs485-enabled-at-boot-time only if
rs485-rts-delay is set in of.

This is clearly a bug, so fix it by moving the bracket to the proper
place.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Elen Song <elen.song@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With the removal of tty_wait_until_sent_from_close(), tty drivers
no longer wait during open for parallel closes to complete (instead,
the tty core waits before calling the driver open() method). Thus,
the close_wait waitqueue is no longer used for waiting.

Remove struct tty_port::close_wait.
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since at least before 2.6.30, tty drivers that do not drop the tty lock
while closing cannot observe ASYNC_CLOSING set while holding the
tty lock; this includes the tty driver's open() and hangup() methods,
since the tty core calls these methods holding the tty lock.

For these drivers, waiting for ASYNC_CLOSING to clear while opening
is not required, since this condition cannot occur. Similarly, even
when the open() method drops and reacquires the tty lock after
blocking, ASYNC_CLOSING cannot be set (again, for drivers that
do not drop the tty lock while closing).

Now that tty port drivers no longer drop the tty lock while closing
(since 'tty: Remove tty_wait_until_sent_from_close()'), the same
conditions apply: waiting for ASYNC_CLOSING to clear while opening
is not required, nor is re-checking ASYNC_CLOSING after dropping and
reacquiring the tty lock while blocking (eg., in *_block_til_ready()).

Note: The ASYNC_CLOSING flag state is still maintained since several
bitrotting drivers use it for (dubious) other purposes.
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In the tegra UART driver there are three places where the RX DMA buffer
is handled and pushed up to the tty layer. In all three instances the
same functions are called and so instead of duplicating the code in three
places, move this code to a new helper function and use this new function.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The serial-tegra driver always uses DMA and hence the driver always
allocates DMA channels. Therefore, the test to see if the RX DMA channel
is initialised in tegra_uart_stop_rx() is unnecessary and so remove
the test and the code that corresponds to the case where the RX DMA
channel is not initialised. Please note that the call to
tegra_uart_stop_rx() should always be before the call to
tegra_uart_shutdown() which will uninitialise the RX DMA channel.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some functions in the serial-tegra driver have unnecessary return
statements at the end of a void function and so remove them.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 853a6997 ("serial: tegra: handle race condition on uart rx
side") attempted to fix a race condition between the RX end of
transmission interrupt and RX DMA completion callback. Despite this
fix there is still another case where these two paths can race and
result in duplicated data. The race condition is as follows:

1. DMA completion interrupt occurs and schedules tasklet to call DMA
   callback.
2. DMA callback for the UART driver starts to execute. This will copy
   the data from the DMA buffer and restart the DMA. This is done under
   uart port spinlock.
3. During the callback, UART interrupt is raised for end of receive. The
   UART ISR runs and waits to acquire port spinlock held by the DMA
   callback.
4. DMA callback gives up spinlock after copying the data, but before
   restarting DMA.
5. UART ISR acquires the spin lock and reads the same DMA buffer because
   DMA has not been restarted yet.

The release of the spinlock during the DMA callback was introduced by
commit 9b88748b ("tty: serial: tegra: drop uart_port->lock before
calling tty_flip_buffer_push()") to fix a spinlock lock-up issue when
calling tty_flip_buffer_push(). However, since then commit a9c3f68f
("tty: Fix low_latency BUG") migrated tty_flip_buffer_push() to always
use a workqueue, allowing tty_flip_buffer_push() to be called from
within atomic sections. Therefore, we can remove the unlocking of the
spinlock from the DMA callback and UART ISR and this will ensure that
the race condition no longer occurs.
Reported-by: NChristopher Freeman <cfreeman@nvidia.com>
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Clearing UART_MCR_RTS or UART_MCR_XONANY is unnecessary; these bits
are never set in the shadow mcr. The RTS clear is especially confusing.
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The same serial hardware is present on LS2080A which is arm64, and
LS1021A which is arm32, so don't limit the workaround to PPC.

Unlike PPC which uses arch/powerpc/kernel/legacy_serial.c, the ARM
targets use drivers/tty/serial/of_serial.c, so add the handle_irq
override check there as well.
Signed-off-by: NScott Wood <scottwood@freescale.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is no need to hardcode the MEN_Z135_MEM_SIZE. The MCB subsystem
already knowns the size which is located in the chameleon table.
MCB parse the chameleon table to get the resources of each IP and provide
the mcb_request_mem function to get those resources.

Use mcb_request_mem to get the resources. This function also takes care of
the memory region naming allocated by the driver for each of the instances.
Signed-off-by: NAndreas Werner <andy@wernerandy.de>
Acked-by: NJohannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Turning on KVM and LPAE support on top of a multi_v7_defconfig will
produce a compiler warning in the Atmel serial driver:
drivers/tty/serial/atmel_serial.c: In function 'atmel_verify_port':
drivers/tty/serial/atmel_serial.c:2299:6: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  if ((void *)port->mapbase != ser->iomem_base)
      ^

Fix that by using the cast on the right hand side instead, as similar
code already does in other drivers.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Acked-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This adds an entry to the uart_config table for PORT_RT2880
enabling rx/tx FIFOs.  The UART is actually a Palmchip BK-3103
which is found in several devices from Alchemy/RMI, Ralink, and
Sigma Designs.
Signed-off-by: NMans Rullgard <mans@mansr.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

UART controller is capable to perform transfers up to 4 Mbps.
Remove artificial 115.2 Kbps limitation.
Signed-off-by: NIvan T. Ivanov <ivan.ivanov@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add receive DMA support for UARTDM type of controllers.

Tested on APQ8064, which have UARTDM v1.3 and ADM DMA engine
and APQ8016, which have UARTDM v1.4 and BAM DMA engine.
Signed-off-by: NIvan T. Ivanov <ivan.ivanov@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add transmit DMA support for UARTDM type of controllers.

Tested on APQ8064, which have UARTDM v1.3 and ADM DMA engine
and APQ8016, which have UARTDM v1.4 and BAM DMA engine.
Signed-off-by: NIvan T. Ivanov <ivan.ivanov@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make function naming consistent across this driver.
Also rename msm_irq to msm_uart_irq. No functional changes.
Signed-off-by: NIvan T. Ivanov <ivan.ivanov@linaro.org>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Replaces (1 << x) with BIT(x) macro
Signed-off-by: NPramod Gurav <gpramod@codeaurora.org>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NIvan T. Ivanov <ivan.ivanov@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>