- 20 Sep, 2018 4 commits
-
-
Michal Simek authored
For IPs which have alias algorightm all the time using that alias and minor number. It means serial20 alias ends up as ttyPS20. If alias is not setup for probed IP instance the first unused position is used but that needs to be checked if it is really empty because another instance doesn't need to be probed at that time. of_alias_get_alias_list() fills alias bitmap which exactly shows which ID is free. If alias pointing to different not compatible IP, it is free to use. cdns_get_id() call is placed below structure allocation to simplify error path. Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michal Simek authored
The function travels the lookup table to record alias ids for the given device match structures and alias stem. This function will be used by serial drivers to check if requested alias is allocated or free to use. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/tty/serial/pmac_zilog.c: In function 'pmz_receive_chars': drivers/tty/serial/pmac_zilog.c:222:30: warning: variable 'error' set but not used [-Wunused-but-set-variable] Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Laura Abbott authored
After 2dd45316 ("kgdboc: Fix restrict error"), kgdboc_option_setup is now only used when built in, resulting in a warning when compiled as a module: drivers/tty/serial/kgdboc.c:134:12: warning: 'kgdboc_option_setup' defined but not used [-Wunused-function] static int kgdboc_option_setup(char *opt) ^~~~~~~~~~~~~~~~~~~ Move the function under the appropriate ifdef for builtin only. Fixes: 2dd45316 ("kgdboc: Fix restrict error") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Laura Abbott <labbott@redhat.com> Signed-off-by:
-
- 18 Sep, 2018 36 commits
-
-
Jiri Slaby authored
When we leak some tty buffer, warn about that. For that we need to account the memory used also in the tty_buffer_free_all function. On other locations, the accounting is handled correctly. Note that we do not account the free list, as that was accounted in tty_buffer_free before put on the free list. I have been using this patch for ages, so let's see if anybody else encounters any issues. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Tobin C. Harding authored
Currently there are a bunch of kernel-doc function comments that have a line of whitespace after the comment and before the function they comment - this is incorrect, there should be no whitespace here. Remove incorrect whitespace between comment and associated function. Signed-off-by:
Tobin C. Harding <me@tobin.cc> Signed-off-by:
-
Phil Elwell authored
The SC16IS752 has an Enhanced Feature Register which is aliased at the same address as the Interrupt Identification Register; accessing it requires that a magic value is written to the Line Configuration Register. If an interrupt is raised while the EFR is mapped in then the ISR won't be able to access the IIR, leading to the "Unexpected interrupt" error messages. Avoid the problem by claiming a mutex around accesses to the EFR register, also claiming the mutex in the interrupt handler work item (this is equivalent to disabling interrupts to interlock against a non-threaded interrupt handler). See: https://github.com/raspberrypi/linux/issues/2529Signed-off-by:
Phil Elwell <phil@raspberrypi.org> Signed-off-by:
-
Phil Elwell authored
The SC16IS752 is a dual-channel device. The two channels are largely independent, but the IRQ signals are wired together as an open-drain, active low signal which will be driven low while either of the channels requires attention, which can be for significant periods of time until operations complete and the interrupt can be acknowledged. In that respect it is should be treated as a true level-sensitive IRQ. The kernel, however, needs to be able to exit interrupt context in order to use I2C or SPI to access the device registers (which may involve sleeping). Therefore the interrupt needs to be masked out or paused in some way. The usual way to manage sleeping from within an interrupt handler is to use a threaded interrupt handler - a regular interrupt routine does the minimum amount of work needed to triage the interrupt before waking the interrupt service thread. If the threaded IRQ is marked as IRQF_ONESHOT the kernel will automatically mask out the interrupt until the thread runs to completion. The sc16is7xx driver used to use a threaded IRQ, but a patch switched to using a kthread_worker in order to set realtime priorities on the handler thread and for other optimisations. The end result is non-threaded IRQ that schedules some work then returns IRQ_HANDLED, making the kernel think that all IRQ processing has completed. The work-around to prevent a constant stream of interrupts is to mark the interrupt as edge-sensitive rather than level-sensitive, but interpreting an active-low source as a falling-edge source requires care to prevent a total cessation of interrupts. Whereas an edge-triggering source will generate a new edge for every interrupt condition a level-triggering source will keep the signal at the interrupting level until it no longer requires attention; in other words, the host won't see another edge until all interrupt conditions are cleared. It is therefore vital that the interrupt handler does not exit with an outstanding interrupt condition, otherwise the kernel will not receive another interrupt unless some other operation causes the interrupt state on the device to be cleared. The existing sc16is7xx driver has a very simple interrupt "thread" (kthread_work job) that processes interrupts on each channel in turn until there are no more. If both channels are active and the first channel starts interrupting while the handler for the second channel is running then it will not be detected and an IRQ stall ensues. This could be handled easily if there was a shared IRQ status register, or a convenient way to determine if the IRQ had been deasserted for any length of time, but both appear to be lacking. Avoid this problem (or at least make it much less likely to happen) by reducing the granularity of per-channel interrupt processing to one condition per iteration, only exiting the overall loop when both channels are no longer interrupting. Signed-off-by:
-
Marek Vasut authored
The 8250 FIFOs indeed need to be cleared after stopping transmission in RS485 mode without SER_RS485_RX_DURING_TX flag set. But there are two problems with the approach taken by the previous patch from Fixes tag. First, serial8250_clear_fifos() should clear fifos, but what it really does is it enables the FIFOs unconditionally if present, clears them and then sets the FCR register to zero, which effectively disables the FIFOs. In case the FIFO is disabled, enabling it and clearing it makes no sense and in fact can trigger misbehavior of the 8250 core. Moreover, the FCR register may contain other FIFO configuration bits which may not be writable unconditionally and writing them incorrectly can trigger misbehavior of the 8250 core too. (ie. AM335x UART swallows the first byte and retransmits the last byte twice because of this FCR write). Second, serial8250_clear_and_reinit_fifos() completely reloads the FCR, but what really has to happen at the end of the RS485 transmission is clearing of the FIFOs and nothing else. This patch repairs serial8250_clear_fifos() so that it really only clears the FIFOs by operating on FCR[2:1] bits and leaves all the other bits alone. It also undoes serial8250_clear_and_reinit_fifos() from __do_stop_tx_rs485() as serial8250_clear_fifos() is sufficient. Signed-off-by:
Marek Vasut <marex@denx.de> Fixes: 2bed8a8e ("Clearing FIFOs in RS485 emulation mode causes subsequent transmits to break") Cc: Daniel Jedrychowski <avistel@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable <stable@vger.kernel.org> # let it bake a bit before merging Signed-off-by:
-
Rob Herring authored
In preparation to remove the node name pointer from struct device_node, convert printf users to use the %pOFn format specifier. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linux-serial@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by:
-
John Garry authored
In commit c58caaab ("serial: 8250: of: Defer probe on missing IRQ"), a check was added for the UART driver being probed prior to the parent IRQ controller. Unfortunately this breaks certain boards which have no interrupt support, like Huawei D03. Indeed, the 8250 DT bindings state that interrupts should be supported - not must. To fix, switch from irq_of_parse_and_map() to of_irq_get(), which does relay whether the IRQ host controller domain is not ready, i.e. defer probe, instead of assuming it. Fixes: c58caaab ("serial: 8250: of: Defer probe on missing IRQ") Signed-off-by:
John Garry <john.garry@huawei.com> Reviewed-by:
Alexander Sverdlin <alexander.sverdlin@nokia.com> Tested-by:
-
Douglas Anderson authored
If you've got the "console" serial port setup to use just as a UART (AKA there is no "console=ttyMSMX" on the kernel command line) then certain initialization is skipped. When userspace later tries to do something with the port then things go boom (specifically, on my system, some sort of exception hit that caused the system to reboot itself w/ no error messages). Let's cleanup / refactor the init so that we always run the same init code regardless of whether we're using the console. To make this work, we make rely on qcom_geni_serial_pm doing its job to turn resources on. For the record, here is a trace of the order of things (after this patch) when console= is specified on the command line and we have an agetty on the port: qcom_geni_serial_pm: 4 (undefined) => 0 (on) qcom_geni_console_setup qcom_geni_serial_port_setup qcom_geni_serial_console_write qcom_geni_serial_startup qcom_geni_serial_start_tx ...and here is the order of things (after this patch) when console= is _NOT_ specified on the command line and we have an agetty port: qcom_geni_serial_pm: 4 => 0 qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_port_setup qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_start_tx Fixes: c4f52879 ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
-
Geert Uytterhoeven authored
With gcc 4.1.2: drivers/tty/serial/qcom_geni_serial.c: In function ‘qcom_geni_serial_probe’: drivers/tty/serial/qcom_geni_serial.c:1261: warning: ‘drv’ may be used uninitialized in this function Indeed, if dev.of_node is NULL, drv will be used uninitialized, and dereferenced in uart_add_one_port(). However, as this driver supports DT only, dev.of_node will always be valid. Hence remove the useless check for dev.of_node, killing the warning as a side effect. Fixes: 8a8a66a1 ("tty: serial: qcom_geni_serial: Add support for flow control") Signed-off-by:Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Anton Vasilyev authored
On the error path of mxs_auart_request_gpio_irq() is performed backward iterating with index i of enum type. Underline enum type may be unsigned char. In this case check (--i >= 0) will be always true and error handling goes into infinite loop. The patch changes the check so that it is valid for signed and unsigned types. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Anton Vasilyev <vasilyev@ispras.ru> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Baolin Wang authored
Make the macros' definition and code have the same correct indentation. Signed-off-by:
Baolin Wang <baolin.wang@linaro.org> Acked-by:
Chunyan Zhang <chunyan.zhang@spreadtrum.com> Signed-off-by:
-
Baolin Wang authored
The register offset value should be 'unsigned int' type. Moreover, prefer 'unsigned int' to bare use of 'unsigned'. Signed-off-by:
-
Baolin Wang authored
The devm_ioremap_resource() will valid the resources, thus remove the unnecessary resource validation in the driver. Signed-off-by:
-
Baolin Wang authored
Define readable macros instead of magic number to make code more readable. Signed-off-by:
-
Baolin Wang authored
Remove the unused reg_backup structure. Signed-off-by:
-
Lokesh Vutla authored
Allow 8250 omap serial driver to be used for K3 platforms. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Nishanth Menon <nm@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Acked-by:
Vignesh R <vigneshr@ti.com> Signed-off-by:
-
Marek Szyprowski authored
Ensure that the baud clock is also enabled for UART register writes in driver resume. On Exynos5433 SoC this is needed to avoid external abort issue. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Chris Brandt authored
Since the register offsets are different for RZ/A2 SCIF, we need to declare a separate string for it. Signed-off-by:
Chris Brandt <chris.brandt@renesas.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Geert Uytterhoeven authored
This reverts commit 2d4dd0da. This broke earlycon on all Renesas ARM platforms using a SCIF port for the serial console (R-Car, RZ/A1, RZ/G1, RZ/G2 SoCs), due to an incorrect value of port->regshift. Signed-off-by:
-
Geert Uytterhoeven authored
This reverts commit 7acece71. Signed-off-by:
-
Anson Huang authored
On some i.MX SoCs' low power mode, such as i.MX7D's LPSR(low power state retention), UART iomux settings will be lost, need to add pinctrl sleep/default mode switch during suspend/resume to make sure UART iomux settings are correct after resume. Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Acked-by:
-
Anson Huang authored
In noirq suspend/resume stage with no_console_suspend enabled, imx_uart_console_write() may be called to print out log_buf message by printk(), so there will be race condition between imx_uart_console_write() and imx_uart_save/restore_context(), need to add lock to protect the registers save/restore operations. Signed-off-by:
-
jun qian authored
Before the program enters the uart ISR, the local interrupt has been disabled by the system, so it's not appropriate to use spin_lock_irqsave interface in the ISR. Signed-off-by:
jun qian <hangdianqj@163.com> Reviewed-by:
Barry Song <21cnbao@gmail.com> Signed-off-by:
-
Shubhrajyoti Datta authored
Driver console functions are using pointer to static array with fixed size. There can be only one serial console at the time which is found by register_console(). register_console() is filling cons->index to port->line value. Signed-off-by:
Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Signed-off-by:
-
Shubhrajyoti Datta authored
register_console is called twice once from uart_add_one_port -> uart_configure_port remove the double call Signed-off-by:
-
Shubhrajyoti Datta authored
Move uart register to probe. This is in preparation of removing the hardcoding of number of uarts. Signed-off-by:
-
Shubhrajyoti Datta authored
At probe the uartlite is getting configured. Enable the clocks before assiging uart and disable after probe is done. Signed-off-by:
-
Sebastian Andrzej Siewior authored
The printk() in serial8250_interrupt() was once hidden behind a debug macro in commit f4f653e9 ("serial: 8250, disable "too much work" messages") and reverted back in commit 12de375e ("Revert "serial: 8250, disable "too much work" messages""). This was introduced first in 0.99.13k with the "serial" driver itself (and called pass_number with a limit of 64 and no print). In 1.1.13 it was renamed to pass_counter and the printk was behind #if 0. In 1.1.94 the limit of 64 was increased to 256 and hidden behind RS_ISR_PASS_LIMIT. With this change the #if 0 turned into #if 1. It slowly become what we have today with a loop limit of 512. Usually, that printk isn't hit. However on KVM with a busy UART and overloaded host it might happen. It is also likely with threaded interrupts and a task which preempts the interrupt handler. If the UART has (legitimate) work to do and we break out of the loop, nothing changes: the interrupt is most likely already pending in the interrupt controller and we end up in the handler anyway. This printk is hardly helping. Older kernels also had a comment saying that a bad configuration might lead to this but I don't see how that should happen because a wrongly configured interrupt number would let the handler leave "early" with IRQ_NONE and the spurious detected will handle that (weill since 2.6.11, before that we had no spurious detector). In that case, we would never loop that often here. This loop looks like an optimisation in order to pull the bytes from the FIFO which were received while we were already here instead of waiting for the interrupt. This might have been a good idea while the CPUs were slow and FIFOs small. There are other serial driver in tree, like the amba-pl*, which also have this kind of a loop but without the printk (and were based on this driver). Remove the printk which might trigger in otherwise valid situtations. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Laura Abbott authored
There's an error when compiled with restrict: drivers/tty/serial/kgdboc.c: In function ‘configure_kgdboc’: drivers/tty/serial/kgdboc.c:137:2: error: ‘strcpy’ source argument is the same as destination [-Werror=restrict] strcpy(config, opt); ^~~~~~~~~~~~~~~~~~~ As the error implies, this is from trying to use config as both source and destination. Drop the call to the function where config is the argument since nothing else happens in the function. Signed-off-by:
Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by:
-
He Zhe authored
pr_* is preferred according to scripts/checkpatch.pl. Cc: jason.wessel@windriver.com Cc: gregkh@linuxfoundation.org Cc: jslaby@suse.com Signed-off-by:
He Zhe <zhe.he@windriver.com> Acked-by:
-
He Zhe authored
kgdboc_option_setup does not check input argument before passing it to strlen. The argument would be a NULL pointer if "ekgdboc", without its value, is set in command line and thus cause the following panic. PANIC: early exception 0xe3 IP 10:ffffffff8fbbb620 error 0 cr2 0x0 [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.18-rc8+ #1 [ 0.000000] RIP: 0010:strlen+0x0/0x20 ... [ 0.000000] Call Trace [ 0.000000] ? kgdboc_option_setup+0x9/0xa0 [ 0.000000] ? kgdboc_early_init+0x6/0x1b [ 0.000000] ? do_early_param+0x4d/0x82 [ 0.000000] ? parse_args+0x212/0x330 [ 0.000000] ? rdinit_setup+0x26/0x26 [ 0.000000] ? parse_early_options+0x20/0x23 [ 0.000000] ? rdinit_setup+0x26/0x26 [ 0.000000] ? parse_early_param+0x2d/0x39 [ 0.000000] ? setup_arch+0x2f7/0xbf4 [ 0.000000] ? start_kernel+0x5e/0x4c2 [ 0.000000] ? load_ucode_bsp+0x113/0x12f [ 0.000000] ? secondary_startup_64+0xa5/0xb0 This patch adds a check to prevent the panic. Cc: stable@vger.kernel.org Cc: jason.wessel@windriver.com Cc: gregkh@linuxfoundation.org Cc: jslaby@suse.com Signed-off-by:
-
Michal Simek authored
Enable automatic flow control which should ensure that there is no mainteinance in connection for zcu100 BT case. Signed-off-by:
Nava kishore Manne <navam@xilinx.com> Signed-off-by:
-
Michal Simek authored
Record port ID in device data structure to be have it connected to certain instance. Signed-off-by:
-
Michal Simek authored
Every instance is registering own struct console and struct uart_driver with minor number which corresponds to alias ID (or 0 now) and with 1 uart port. The same alias ID is saved to tty_driver->name_base which is key field for creating ttyPSX name. Because name_base and minor number are setup already there is no need to setup any port->line number because 0 is the right value. Unfortunately this driver is setting up major number to 0 for using dynamic assignment and kernel is allocating different major numbers for every instance instead of using the same major and different minor number. ~# ls -la /dev/ttyPS* crw------- 1 root root 252, 0 Jan 1 03:36 /dev/ttyPS0 crw--w---- 1 root root 253, 1 Jan 1 00:00 /dev/ttyPS1 When major number is not 0. For example 252 then major/minor combinations are in expected form ~# ls -la /dev/ttyPS* crw------- 1 root root 252, 0 Jan 1 04:04 /dev/ttyPS0 crw--w---- 1 root root 252, 1 Jan 1 00:00 /dev/ttyPS1 Driver is not freeing struct cdns_uart_console in case that instance is not used as console. The reason is that console is incorrectly unregistred and "console [0] disabled" message will be shown. Signed-off-by:
-
Michal Simek authored
Change logic how console_port is setup by using CON_ENABLED flag instead of index. There will be unique cdns_uart_console() structures that's why code can't use id for console_port assignment. Signed-off-by:
-
Michal Simek authored
This is preparation step for dynamic port allocation without CDNS_UART_NR_PORTS macro. Fill the structure only once at probe. Signed-off-by:
-
