- 28 Jan, 2024 40 commits
-
-
Tudor Ambarus authored
The comment brings no benefit as we can already see from the method's name, ``s3c24xx_serial_pm``, that it deals with power management. Drop the superfluous comment. Reviewed-by:
Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by:
Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/r/20240119104526.1221243-12-tudor.ambarus@linaro.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tudor Ambarus authored
Move open brace '{' following function definition on the next line. Reviewed-by: -
Tudor Ambarus authored
Braces {} are not necessary for single statement blocks. Remove braces on single statement block. Reviewed-by: -
Tudor Ambarus authored
All registers of the IP have 32 bits. Use u32 variables when reading or writing from/to the registers. The purpose of those variables becomes clearer. Reviewed-by:
-
Tudor Ambarus authored
samsung_tty.c uses u32 and relies on <linux/console.h> to include <linux/types.h>. Explicitly include <linux/types.h>. We shall aim to have the driver self contained. Reviewed-by:
-
Tudor Ambarus authored
Sorting headers alphabetically helps locating duplicates, and makes it easier to figure out where to insert new headers. Reviewed-by:
-
Tudor Ambarus authored
The entire bus (PERIC) on which the GS101 serial resides only allows 32-bit register accesses. The reg-io-width dt property is disallowed for the "google,gs101-uart" compatible and instead the iotype is inferred from the compatible. Always set UPIO_MEM32 iotype for the gs101 earlycon. Reviewed-by:
Peter Griffin <peter.griffin@linaro.org> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
Tudor Ambarus authored
GS101's Connectivity Peripheral blocks (peric0/1 blocks) which include the I3C and USI (I2C, SPI, UART) only allow 32-bit register accesses. Instead of specifying the reg-io-width = 4 everywhere, for each node, the requirement should be deduced from the compatible. Infer UPIO_MEM32 iotype from the "google,gs101-uart" compatible. Update the uart info name to be GS101 specific in order to differentiate from the other exynos platforms. All the other settings are not changed. exynos_fifoszdt_serial_drv_data was replaced by gs101_serial_drv_data because the iotype restriction is gs101 specific and there was no other user of exynos_fifoszdt_serial_drv_data. Reviewed-by:
-
Tudor Ambarus authored
GS101's Connectivity Peripheral blocks (peric0/1 blocks) which include the I3C and USI (I2C, SPI, UART) only allow 32-bit register accesses. If using 8-bit register accesses, a SError Interrupt is raised causing the system unusable. Instead of specifying the reg-io-width = 4 everywhere, for each node, the requirement should be deduced from the compatible. Prepare the samsung tty driver to allow IO types different than UPIO_MEM. ``struct uart_port::iotype`` is an unsigned char where all its 8 bits are exposed to uapi. We can't make NULL checks on it to verify if it's set, thus always set it from the driver's data. Use u8 for the ``iotype`` member of ``struct s3c24xx_uart_info`` to emphasize that the iotype is an 8 bit mask. Reviewed-by:
-
Tudor Ambarus authored
All gs101 serial ports are restricted to 32-bit register accesses. This requirement will be inferred from the compatible. Do not allow the reg-io-width property for the google,gs101-uart compatible. Suggested-by:
-
Tudor Ambarus authored
The core expects for tx_empty() either TIOCSER_TEMT when the tx is empty or 0 otherwise. s3c24xx_serial_txempty_nofifo() might return 0x4, and at least uart_get_lsr_info() tries to clear exactly TIOCSER_TEMT (BIT(1)). Fix tx_empty() to return TIOCSER_TEMT. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Hugo Villeneuve authored
Fix indentation and add line after do/while() block. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20240118152213.2644269-18-hugo@hugovil.comSigned-off-by:
-
Hugo Villeneuve authored
Add comments about I2C slave address structure, and reformat to improve readability. Also reformat some comments according to kernel coding style. Reviewed-by:
-
Hugo Villeneuve authored
Fixes the following checkpatch warnings: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' With this change, the affected functions now match the prototypes in struct gpio_chip. Reviewed-by: -
Hugo Villeneuve authored
Simplify driver by defining a common function to handle the power control of all variants. Reviewed-by:
-
Hugo Villeneuve authored
Simplify driver by defining a common function to handle the detection of all variants. Reviewed-by:
-
Hugo Villeneuve authored
GENMASK() is preferred when defining bitmasks. Of all the masks changed, only MAX310x_REV_MASK is actually used. No functional change. Reviewed-by:
-
Hugo Villeneuve authored
Replace dev_err() with dev_err_probe(). This helps in simplifing code and standardizing the error output. Reviewed-by:
-
Hugo Villeneuve authored
Allows to simplify code by removing the break statement in the default switch/case in some functions. Suggested-by:
-
Hugo Villeneuve authored
Simplify error handling and only call uart_remove_one_port() if line bit is set, instead of having to manually set s->p[i].port.dev to NULL. Reviewed-by:
-
Hugo Villeneuve authored
Use a separate regmap name for each port so they can each have their own debugfs entry, allowing to access each port registers independently. For example, a four channels/ports device like the MAX14830 will have four entries in its regmap debugfs: $ find /sys/kernel/debug/regmap -type d | grep spi0.0 /sys/kernel/debug/regmap/spi0.0-port0 /sys/kernel/debug/regmap/spi0.0-port1 /sys/kernel/debug/regmap/spi0.0-port2 /sys/kernel/debug/regmap/spi0.0-port3 Cc: Jan Kundrát <jan.kundrat@cesnet.cz> Link: https://lore.kernel.org/all/77f101f1-897d-4e6d-a8fd-27b818caf768@cesnet.cz/Reviewed-by:
-
Hugo Villeneuve authored
Add macro to hold the maximum number of UART ports per IC/device. Reviewed-by:
Jan Kundrát <jan.kundrat@cesnet.cz> Tested-by:
-
Hugo Villeneuve authored
Running pahole shows that there are some holes within the max310x_devtype structure. Remove holes and optimize alignment by reorganizing structure members. This can also lead to data structure size reduction for some CPUs. On 64-bit CPU (arm64): Before: /* size: 40, cachelines: 1, members: 6 */ /* sum members: 34, holes: 2, sum holes: 6 */ /* last cacheline: 40 bytes */ After: /* size: 40, cachelines: 1, members: 6 */ /* padding: 6 */ /* last cacheline: 40 bytes */ On 32-bit CPU (i386): Before: /* size: 32, cachelines: 1, members: 6 */ /* sum members: 26, holes: 2, sum holes: 6 */ /* last cacheline: 32 bytes */ After: /* size: 24, cachelines: 1, members: 8 */ /* padding: 2 */ /* last cacheline: 24 bytes */ Suggested-by: -
Hugo Villeneuve authored
Replace g with q. Helpful when grepping thru source code or logs for "request" keyword. Fixes: f6544418 ("serial: New serial driver MAX310X") Reviewed-by:
-
Hugo Villeneuve authored
Use preferred spi_get_device_match_data() instead of device_get_match_data() and spi_get_device_id() to get the driver match data. Suggested-by:
-
Hugo Villeneuve authored
Use preferred i2c_get_match_data() instead of device_get_match_data() to get the driver match data. Suggested-by:
-
Hugo Villeneuve authored
This allows to instantiate a max14830 I2C device from userspace. Helpful when testing driver with i2c-stub. Reviewed-by:
-
Hugo Villeneuve authored
When trying to instantiate a max14830 device from userspace: echo max14830 0x60 > /sys/bus/i2c/devices/i2c-2/new_device we get the following error: Unable to handle kernel NULL pointer dereference at virtual address... ... Call trace: max310x_i2c_probe+0x48/0x170 [max310x] i2c_device_probe+0x150/0x2a0 ... Add check for validity of devtype to prevent the error, and abort probe with a meaningful error message. Fixes: 2e1f2d9a ("serial: max310x: implement I2C support") Cc: stable@vger.kernel.org Reviewed-by: -
Valentin Caron authored
Since STM32MP25, FIFO size could vary regarding the STM32MPxx version. So we get this size from "hwcfgr1" register and compute threshold values corresponding to the ratio given by reference manual. As STM32MP1x, STM32MP25 and STM32H7 share the same compatible and STM32H7 doesn't have a register to get FIFO size, we force FIFO size to 16 in case of zero read from hwcfgr1 register. Signed-off-by:
Valentin Caron <valentin.caron@foss.st.com> Link: https://lore.kernel.org/r/20240112095300.2004878-5-valentin.caron@foss.st.comSigned-off-by:
-
Valentin Caron authored
USART has registers above 0xff offset, so extend variable type to u16. And change UNDEF_REG to 0xffff. Signed-off-by:
-
Valentin Caron authored
STM32MP25x got 9 instances of U(S)ART. So extend STM32_MAX_PORTS to 9, in order to handle all instances. Signed-off-by:
-
Valentin Caron authored
In the case of high USART input clock and low baud rate, BRR value is not enough to get correct baud rate. So here we use USART prescaler to divide USART input clock to get the correct baud rate. PRESC register is only available since stm32h7. Signed-off-by:
-
Lukas Bulwahn authored
The config HW_CONSOLE is always identical to the config VT and is not visible in the kernel's build menuconfig. So, CONFIG_HW_CONSOLE is redundant. Replace all references to CONFIG_HW_CONSOLE with CONFIG_VT and remove CONFIG_HW_CONSOLE. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
-
Douglas Anderson authored
As of commit d7402513 ("arm64: smp: IPI_CPU_STOP and IPI_CPU_CRASH_STOP should try for NMI"), if we've got pseudo-NMI enabled then we'll use it to stop CPUs at panic time. This is nice, but it does mean that there's a pretty good chance that we'll end up stopping a CPU while it holds the port lock for the console UART. Specifically, I see a CPU get stopped while holding the port lock nearly 100% of the time on my sc7180-trogdor based Chromebook by enabling the "buddy" hardlockup detector and then doing: sysctl -w kernel.hardlockup_all_cpu_backtrace=1 sysctl -w kernel.hardlockup_panic=1 echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT UART drivers are _supposed_ to handle this case OK and this is why UART drivers check "oops_in_progress" and only do a "trylock" in that case. However, before we enabled pseudo-NMI to stop CPUs it wasn't a very well-tested situation. Now that we're testing the situation a lot, it can be seen that the Qualcomm GENI UART driver is pretty broken. Specifically, when I run my test case and look at the console output I just see a bunch of garbled output like: [ 201.069084] NMI backtrace[ 201.069084] NM[ 201.069087] CPU: 6 PID: 10296 Comm: dnsproxyd Not tainted 6.7.0-06265-gb13e8c0ede12 #1 01112b9f14923cbd0b[ 201.069090] Hardware name: Google Lazor ([ 201.069092] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DI[ 201.069095] pc : smp_call_function_man[ 201.069099] That's obviously not so great. This happens because each call to the console driver exits after the data has been written to the FIFO but before it's actually been flushed out of the serial port. When we have multiple calls into the console one after the other then (if we can't get the lock) each call tells the UART to throw away any data in the FIFO that hadn't been transferred yet. I've posted up a patch to change the arm64 core to avoid this situation most of the time [1] much like x86 seems to do, but even if that patch lands the GENI driver should still be fixed. >From testing, it appears that we can just delete the cancel/abort in the case where we weren't able to get the UART lock and the output looks good. It makes sense that we'd be able to do this since that means we'll just call into __qcom_geni_serial_console_write() and __qcom_geni_serial_console_write() looks much like qcom_geni_serial_poll_put_char() but with a loop. However, it seems safest to poll the FIFO and make sure it's empty before our transfer. This should reliably make sure that we're not interrupting/clobbering any existing transfers. As part of this change, we'll also avoid re-setting up a TX at the end of the console write function if we weren't able to get the lock, since accessing "port->tx_remaining" without the lock is not safe. This is only needed to re-start userspace initiated transfers. [1] https://lore.kernel.org/r/20231207170251.1.Id4817adef610302554b8aa42b090d57270dc119c@changeidSigned-off-by:
Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20240112150307.2.Idb1553d1d22123c377f31eacb4486432f6c9ac8d@changeidSigned-off-by:
-
Douglas Anderson authored
According to the docs I have, bit 21 of the status register is asserted when the FIFO is _not_ empty. Add the definition. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240112150307.1.I7dc0993c1e758a1efedd651e7e1670deb1b430fb@changeidSigned-off-by:
-
Geert Uytterhoeven authored
If CONFIG_SERIAL_8250_HP300=y and CONFIG_SERIAL_8250_CONSOLE=y (e.g. m68k/allyesconfig): drivers/tty/serial/8250/8250_hp300.c:91:12: error: no previous prototype for ‘hp300_setup_serial_console’ [-Werror=missing-prototypes] 91 | int __init hp300_setup_serial_console(void) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ Fix this by moving the existing prototype in arch/m68k/hp300/config.c to <linux/serial_8250.h>, so it is visible to both caller and implementor. While at it, provide a dummy in case CONFIG_SERIAL_8250_CONSOLE is not enabled, to reduce #ifdef clutter in the caller. Exposed by commit 0fcb7085 ("Makefile.extrawarn: turn on missing-prototypes globally"). Signed-off-by: -
Roman Žilka authored
vc_translate_unicode() and vc_sanitize_unicode() parse input to the UTF-8-enabled console, marking invalid byte sequences and producing Unicode codepoints. The current algorithm follows ancient Unicode and may accept invalid byte sequences, pass on non-existent codepoints and reject valid sequences. The patch restores the functions' compliance with modern Unicode (v15.1 [1] + many previous versions) as well as RFC 3629 [2]. 1. Codepoint space is limited to 0x10FFFF. 2. "Noncharacters", such as U+FFFE, U+FFFF, are no longer invalid in Unicode and will be accepted. Another option was to complete the set of noncharacters (used to be just those two, now there's more) and preserve the rejection step. This is indeed what Unicode suggests ([1] chap. 23.7) (not requires), but most codepoints are !iswprint(), so selecting just the noncharacters seemed arbitrary and futile (and unnecessary). This is not a security patch. I'm not aware of any present security implications of the old code. [1] https://www.unicode.org/versions/Unicode15.1.0 [2] https://datatracker.ietf.org/doc/html/rfc3629Signed-off-by:
Roman Žilka <roman.zilka@gmail.com> Link: https://lore.kernel.org/r/598ab459-6ba9-4a17-b4a1-08f26a356fc0@gmail.comSigned-off-by:
-
Lizhe authored
In linflex_config_port() the member variable type will be assigned again. Remove redundant uart type assignment from linflex_probe(). Signed-off-by:
Lizhe <sensor1010@163.com> Link: https://lore.kernel.org/r/20240112133923.190852-1-sensor1010@163.comSigned-off-by:
-
Francesco Dolcini authored
receive_buf() is called from ttyport_receive_buf() that expects values ">= 0" from serdev_controller_receive_buf(), change its return type from ssize_t to size_t. The need for this clean-up was noticed while fixing a warning, see commit 94d05394 ("Bluetooth: btnxpuart: fix recv_buf() return value"). Changing the callback prototype to return an unsigned seems the best way to document the API and ensure that is properly used. GNSS drivers implementation of serdev receive_buf() callback return directly the return value of gnss_insert_raw(). gnss_insert_raw() returns a signed int, however this is not an issue since the value returned is always positive, because of the kfifo_in() implementation. gnss_insert_raw() could be changed to return also an unsigned, however this is not implemented here as request by the GNSS maintainer Johan Hovold. Suggested-by:
Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/all/087be419-ec6b-47ad-851a-5e1e3ea5cfcc@kernel.org/Signed-off-by:
Francesco Dolcini <francesco.dolcini@toradex.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> #for-iio Reviewed-by:
Johan Hovold <johan@kernel.org> Reviewed-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Alex Elder <elder@linaro.org> Acked-by: Maximilian Luz <luzmaximilian@gmail.com> # for platform/surface Acked-by:
Lee Jones <lee@kernel.org> Acked-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20240122180551.34429-1-francesco@dolcini.itSigned-off-by:
-
Jiri Slaby (SUSE) authored
Now, that the console kernel-doc is in better shape, include it in the tty/ docs. It's not supernice, but it is what it is. At least for the beginning. Signed-off-by:
-
