aboutsummaryrefslogtreecommitdiff
path: root/drivers/tty
AgeCommit message (Collapse)AuthorFilesLines
2024-02-17tty: hvc-iucv: fix function pointer castsArnd Bergmann1-1/+5
clang warns about explicitly casting between incompatible function pointers: drivers/tty/hvc/hvc_iucv.c:1100:23: error: cast from 'void (*)(const void *)' to 'void (*)(struct device *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict] 1100 | priv->dev->release = (void (*)(struct device *)) kfree; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Add a separate function to handle this correctly. Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Jiri Slaby <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-17tty/vt: Corrected doc of vc_sanitize_unicode(), vc_translate_unicode()Roman Žilka1-4/+12
Corrected the doc of vc_sanitize_unicode() and vc_translate_unicode(), tightly coupled functions which parse UTF-8 byte sequences. 1. Desc. of @rescan corresponded to the meaning of the return value -1. Corrected + added "Return:" section. 2. Replaced the ambiguous "character" with "code point" or "byte". Signed-off-by: Roman Žilka <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06serial: mxs-auart: fix txJiri Slaby (SUSE)1-1/+4
Emil reports: After updating Linux on an i.MX28 board, serial communication over AUART broke. When I TX from the board and measure on the TX pin, it seems like the HW fifo is not emptied before the transmission is stopped. MXS performs weird things with stop_tx(). The driver makes it conditional on uart_tx_stopped(). So the driver needs special handling. Pass the brand new UART_TX_NOSTOP to uart_port_tx_flags() and handle the stop on its own. Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Reported-by: Emil Kronborg <[email protected]> Cc: stable <[email protected]> Fixes: 2d141e683e9a ("tty: serial: use uart_port_tx() helper") Closes: https://lore.kernel.org/all/miwgbnvy3hjpnricubg76ytpn7xoceehwahupy25bubbduu23s@om2lptpa26xw/ Tested-by: Stefan Wahren <[email protected]> Tested-by: Emil Kronborg <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06serial: 8250_pci1xxxx: partially revert off by one patchDan Carpenter1-1/+1
I was reviewing this code again and I realized I made a mistake here. It should have been > instead of >=. The subtract ensures that we don't go out of bounds. My patch meant that we don't read the last chunk of the buffer. Fixes: 86ee55e9bc7f ("serial: 8250_pci1xxxx: fix off by one in pci1xxxx_process_read_data()") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: decrypt magic constants in vc_is_control()Jiri Slaby (SUSE)1-3/+7
0x0d00ff81 and 0x0800f501 are bitmasks of ASCII characters. Spell them explicitly using BIT() + ASCII constants. GENMASK() is used for the 9-bit range in CTRL_ACTION. This also modifies the 'if' checking if the masks should be applied. >From a "random" ' ' to the actual size of the bitmasks' type. Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: use ASCII enum constants in vt_console_print()Jiri Slaby (SUSE)1-4/+5
There are still numbers used for ASCII characters in vt_console_print(). As we have an ASCII enum now, use the constant names from the enum instead. Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: use switch+case in the ESgetpars caseJiri Slaby (SUSE)1-4/+8
To be uniform in the 'c' handling, use switch-case (with ranges) even in the ESgetpars case in do_con_trol(). Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: use switch+case in the ESnonstd caseJiri Slaby (SUSE)1-6/+8
To be uniform in the 'c' handling, use switch-case (with ranges) even in the ESnonstd case in do_con_trol(). Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: add new helper for reseting vc parametersJiri Slaby (SUSE)1-6/+9
The code to reset the vc parameter parsing is repeated on two locations. Create a helper vc_reset_params() and use it on both of them. And instead of a 'for' loop to clear the array of parameters, use simpler memset(). Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: handle CSI+[ inside preexisting switch-caseJiri Slaby (SUSE)1-4/+3
In do_con_trol()'s ESsquare case, there is already a switch (c). It is preceded by an 'if (c == '[')'. Despite this 'if' handles a state transition and not a modifier, move it as one of the switch cases. This makes all the 'c' decision making more obvious there. Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: simplify ansi_control_string()Jiri Slaby (SUSE)1-5/+6
Given all the ANSI control states are sequential in the vc_ctl_state enum, we can define first/last constants and use them in ansi_control_string(). It makes the test simple and allows for removal of the 'if' (which was unnecessary at all -- the 'return' should have returned the 'if' content directly anyway). And remove the useless comment -- it's clear from the function prototype. Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: name, reflow and document enum vc_ctl_stateJiri Slaby (SUSE)1-17/+55
The enum for states is currently compact and undocumented. Put each definition on a separate line and document them all using kernel-doc. Document the same on the use sites. Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: move CSI ECMA handling to a separate functionJiri Slaby (SUSE)1-130/+139
Similar to previous moves, move also "CSI ..." (i.e. vc_priv == EPecma) handling to a separate function. This is the last large move of code out of do_con_trol(). And despite it is still 151 lines of code (down from 407!), it is now quite easy to folllow the transitions of the state machine in there. ESnonstd and ESpalette handling still can be moved away, but it won't improve that much. Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: move CSI DEC handling to a separate functionJiri Slaby (SUSE)1-31/+44
The handling of "CSI ? ..." (i.e. vc_priv == EPdec) can be easily moved out of do_con_trol() into a separate function. This again increases readability of do_con_trol(). Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: separate ESesc state handling into handle_esc()Jiri Slaby (SUSE)1-62/+72
Similar to the ASCII handling, the ESC handling can be easily moved away from do_con_trol(). So create a new handle_esc() for that. And add a comment with an example. Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: extract ascii handling to handle_ascii()Jiri Slaby (SUSE)1-21/+37
To make the do_con_trol() a bit more understandable, extract the ASCII handling (the switch-case) to a separate function. Other nested switch-cases will follow in the next patches. Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: accept u8 in do_con_trol() and vc_setGx()Jiri Slaby (SUSE)1-3/+3
These functions expect u8 as the control character. Switch the type from 'int' appropriately. The caller passing the value (do_con_write()) is fixed as well. Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: put cases on separate linesJiri Slaby (SUSE)1-4/+8
Some cases of the CSI switch are stuffed on one line. Put them all to a separate line as is dictated by the coding style (and for better readability). Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: rename setterm_command() to csi_RSB()Jiri Slaby (SUSE)1-4/+10
It follows naming of other similar functions. RSB stands here for Right Square Bracket as (obviously) ']' cannot be in the function name. Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: define an enum for CSI+] codesJiri Slaby (SUSE)1-11/+25
Decrypt the constant values by proper enum names. This time in setterm_command() (to be renamed to csi_RSB() in the next patches). Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: move CSI+n handling along to other ECMA CSIsJiri Slaby (SUSE)1-8/+6
CSIs without [<=>?] modifiers (ECMA) are handled in the switch-case below this DEC switch+case handler. So move this ECMA CSI+n there too as it fits there better. Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: remove unneeded assignment of EPecma to vc_privJiri Slaby (SUSE)1-3/+2
vc_data::vc_priv is _always_ assigned before the ESgetpars case is entered (in ESsquare). Therefore, there is no need to reset it when leaving the ESgetpars case. Note the state is set to ESnormal few lines above, so ESgetpars is entered only by the next CSI. Therefore, this obfuscation can be removed. Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: split DEC CSI+h/l handling into csi_DEC_hl()Jiri Slaby (SUSE)1-67/+77
The DEC and ECMA handling of CSI+h/l is needlessly complicated. Split these two, so that DEC is handled when the state is EPdec ('CSI ?' was seen) and ECMA is handled in the EPecma state (no '?'). Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: rename set_mode() to csi_hl()Jiri Slaby (SUSE)1-3/+3
It's how the other CSI handling functions are named, so unify to that. Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: define enums for CSI+h/l codesJiri Slaby (SUSE)1-12/+30
Decrypt the constant values by proper enum names. This time in set_mode(). Define two of them as DEC ('CSI ?') is about to be split away in the next patches. Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: vt: make rgb_from_256() slighly more comprehensibleJiri Slaby (SUSE)1-4/+7
* make the parameter unsigned, as it is expected to be unsigned, * make the computation easier to follow -- step-by-step, and * don't use 85 / 2 which is only a reduced form of 255 / 6 (by a factor 3). Unlike the former, the latter can be understood. Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06serial: core: make serial_base_bus_type constRicardo B. Marliere1-1/+1
Now that the driver core can properly handle constant struct bus_type, move the serial_base_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Suggested-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: "Ricardo B. Marliere" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06serdev: make serdev_bus_type constRicardo B. Marliere1-1/+1
Now that the driver core can properly handle constant struct bus_type, move the serdev_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Suggested-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: "Ricardo B. Marliere" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06tty: serial: samsung: Remove superfluous braces in macroSam Protsenko1-4/+4
Commit 59f37b7370ef ("tty: serial: samsung: Remove USI initialization") removes parameters from EXYNOS_COMMON_SERIAL_DRV_DATA() macro, but leaves unnecessary empty braces. Remove those to fix the style. No functional change. Signed-off-by: Sam Protsenko <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-06Revert "tty: serial: amba-pl011: Remove QDF2xxx workarounds"Konrad Dybcio1-0/+82
The original commit assumed this hardware is long rotting in the junkyards, but apparently Qualcomm is still using some of these old servers internally and the thing can still run upstream. Adding insult to injury, I apparently managed to overdelete code and broke non-QDF2xxx platforms [1]. Revert the removal to keep things going, at least for now. This reverts commit 196f34af2bf4c87ac4299a9775503d81b446980c. [1] https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Konrad Dybcio <[email protected]> Tested-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/20240201-topic-qdf24xx_is_back_apparently-v1-1-edb112a2ef90@linaro.org Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-02-04Merge 6.8-rc3 into tty-nextGreg Kroah-Hartman3-13/+46
We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27serial: max310x: prevent infinite while() loop in port startupHugo Villeneuve1-2/+18
If there is a problem after resetting a port, the do/while() loop that checks the default value of DIVLSB register may run forever and spam the I2C bus. Add a delay before each read of DIVLSB, and a maximum number of tries to prevent that situation from happening. Also fail probe if port reset is unsuccessful. Fixes: 10d8b34a4217 ("serial: max310x: Driver rework") Cc: [email protected] Signed-off-by: Hugo Villeneuve <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27serial: max310x: fail probe if clock crystal is unstableHugo Villeneuve1-3/+9
A stable clock is really required in order to use this UART, so log an error message and bail out if the chip reports that the clock is not stable. Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness") Cc: [email protected] Suggested-by: Jan Kundrát <[email protected]> Link: https://www.spinics.net/lists/linux-serial/msg35773.html Signed-off-by: Hugo Villeneuve <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27serial: max310x: improve crystal stable clock detectionHugo Villeneuve1-5/+16
Some people are seeing a warning similar to this when using a crystal: max310x 11-006c: clock is not stable yet The datasheet doesn't mention the maximum time to wait for the clock to be stable when using a crystal, and it seems that the 10ms delay in the driver is not always sufficient. Jan Kundrát reported that it took three tries (each separated by 10ms) to get a stable clock. Modify behavior to check stable clock ready bit multiple times (20), and waiting 10ms between each try. Note: the first draft of the driver originally used a 50ms delay, without checking the clock stable bit. Then a loop with 1000 retries was implemented, each time reading the clock stable bit. Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness") Cc: [email protected] Suggested-by: Jan Kundrát <[email protected]> Link: https://www.spinics.net/lists/linux-serial/msg35773.html Link: https://lore.kernel.org/all/[email protected]/raw Link: https://github.com/boundarydevices/linux/commit/e5dfe3e4a751392515d78051973190301a37ca9a Signed-off-by: Hugo Villeneuve <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27serial: max310x: set default value when reading clock ready bitHugo Villeneuve1-1/+1
If regmap_read() returns a non-zero value, the 'val' variable can be left uninitialized. Clear it before calling regmap_read() to make sure we properly detect the clock ready bit. Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness") Cc: [email protected] Signed-off-by: Hugo Villeneuve <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27serial: core: Fix atomicity violation in uart_tiocmgetGui-Dong Han1-1/+1
In uart_tiocmget(): result = uport->mctrl; uart_port_lock_irq(uport); result |= uport->ops->get_mctrl(uport); uart_port_unlock_irq(uport); ... return result; In uart_update_mctrl(): uart_port_lock_irqsave(port, &flags); ... port->mctrl = (old & ~clear) | set; ... port->ops->set_mctrl(port, port->mctrl); ... uart_port_unlock_irqrestore(port, flags); An atomicity violation is identified due to the concurrent execution of uart_tiocmget() and uart_update_mctrl(). After assigning result = uport->mctrl, the mctrl value may change in uart_update_mctrl(), leading to a mismatch between the value returned by uport->ops->get_mctrl(uport) and the mctrl value previously read. This can result in uart_tiocmget() returning an incorrect value. This possible bug is found by an experimental static analysis tool developed by our team, BassCheck[1]. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported when our tool analyzes the source code of Linux 5.17. To address this issue, it is suggested to move the line result = uport->mctrl inside the uart_port_lock block to ensure atomicity and prevent the mctrl value from being altered during the execution of uart_tiocmget(). With this patch applied, our tool no longer reports the bug, with the kernel configuration allyesconfig for x86_64. Due to the absence of the requisite hardware, we are unable to conduct runtime testing of the patch. Therefore, our verification is solely based on code logic analysis. [1] https://sites.google.com/view/basscheck/ Fixes: c5f4644e6c8b ("[PATCH] Serial: Adjust serial locking") Cc: [email protected] Signed-off-by: Gui-Dong Han <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27serial: 8250_pci1xxxx: fix off by one in pci1xxxx_process_read_data()Dan Carpenter1-2/+2
These > comparisons should be >= to prevent writing one element beyond the end of the rx_buff[] array. The rx_buff[] buffer has RX_BUF_SIZE elements. Fix the buffer overflow. Fixes: aba8290f368d ("8250: microchip: pci1xxxx: Add Burst mode reception support in uart driver for writing into FIFO") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/ZZ7vIfj7Jgh-pJn8@moroto Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27tty: serial: uartps: Add rs485 support to uartps driverManikanta Guntupalli1-4/+196
Add rs485 support to uartps driver. Use either rts-gpios or RTS to control RS485 phy as driver or a receiver. Signed-off-by: Manikanta Guntupalli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27tty: serial: uartps: Relocate cdns_uart_tx_empty to facilitate rs485Manikanta Guntupalli1-17/+19
Relocate cdns_uart_tx_empty function to avoid prototype statement in rs485 changes. Update return check with uart_tx_stopped() in cdns_uart_handle_tx(). Signed-off-by: Manikanta Guntupalli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-278250: microchip: Add 4 Mbps support in PCI1XXXX UARTRengarajan S2-5/+36
The current clock input is set to 62.5 MHz for supporting fractional divider, which enables generation of an acceptable baud rate from any frequency. With the current clock input the baud rate range is limited to 3.9 Mbps. Hence, the current range is extended to support 4 Mbps with Burst mode operation. Divisor calculation for a given baud rate is updated as the sampling rate is reduced from 16 to 8 for 4 Mbps. Signed-off-by: Rengarajan S <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-278250: microchip: pci1xxxx: Add Burst mode transmission support in uart ↵Rengarajan S1-0/+106
driver for reading from FIFO pci1xxxx_handle_irq reads the burst status and checks if the FIFO is empty and is ready to accept the incoming data. The handling is done in pci1xxxx_tx_burst where each transaction processes data in block of DWORDs, while any remaining bytes are processed individually, one byte at a time. Signed-off-by: Rengarajan S <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27serial: txx9: Add missing #include <asm/txx9/generic.h>Geert Uytterhoeven1-1/+2
drivers/tty/serial/serial_txx9.c:933:12: error: no previous prototype for ‘early_serial_txx9_setup’ [-Werror=missing-prototypes] 933 | int __init early_serial_txx9_setup(struct uart_port *port) | ^~~~~~~~~~~~~~~~~~~~~~~ This function is called from arch/mips/txx9/generic/setup.c, and does have a forward declaration in arch/mips/include/asm/txx9/generic.h. As the TXX9 serial driver does not support compile-testing, and thus can only be built on MIPS, fix this by including the MIPS-only header file. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/818be2380061c19fe65819f7b7f10ab6e7aaa082.1706040343.git.geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27tty: serial: amba-pl011: Remove QDF2xxx workaroundsKonrad Dybcio1-82/+0
This SoC family was destined for server use, featuring Qualcomm's very interesting Kryo cores (before "Kryo" became a marketing term for Arm cores with small modifications). It did however not leave the labs of Qualcomm and presumably some partners, nor was it ever productized. Remove the workarounds, as they are long obsolete. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27tty: serial: samsung: shrink memory footprint of ``struct s3c24xx_uart_info``Tudor Ambarus1-9/+9
Use u32 for the members of ``struct s3c24xx_uart_info`` that are used for register interactions. The purpose of these members becomes clearer. The greater benefit of this change is that it also reduces the memory footprint of the struct, allowing 64-bit architectures to use a single cacheline for the entire struct. struct s3c24xx_uart_info { const char * name; /* 0 8 */ enum s3c24xx_port_type type; /* 8 4 */ unsigned int port_type; /* 12 4 */ unsigned int fifosize; /* 16 4 */ u32 rx_fifomask; /* 20 4 */ u32 rx_fifoshift; /* 24 4 */ u32 rx_fifofull; /* 28 4 */ u32 tx_fifomask; /* 32 4 */ u32 tx_fifoshift; /* 36 4 */ u32 tx_fifofull; /* 40 4 */ u32 clksel_mask; /* 44 4 */ u32 clksel_shift; /* 48 4 */ u32 ucon_mask; /* 52 4 */ u8 def_clk_sel; /* 56 1 */ u8 num_clks; /* 57 1 */ u8 iotype; /* 58 1 */ bool has_divslot; /* 59 1 */ /* size: 64, cachelines: 1, members: 17 */ /* padding: 4 */ }; Reviewed-by: Sam Protsenko <[email protected]> Signed-off-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27tty: serial: samsung: change has_divslot type to boolTudor Ambarus1-7/+6
Since the driver was introduced the port features flags never extended. As we don't expect more flags soon that would bypass the first cacheline of ``struct s3c24xx_uart_info``, change the type of ``has_divslot`` to bool. Bitfields operations incur performance penalty when set or read as compared to direct types. Signed-off-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27tty: serial: samsung: shrink the clock selection to 8 clocksTudor Ambarus1-11/+11
<linux/serial_s3c.h> provides a clock selection pool of maximum 4 clocks. Update the driver to consider a pool selection of maximum 8 clocks. u8 is large enough to allow more clocks than are supported by the driver now, and not too big to cause spanning of ``struct s3c24xx_uart_info`` through 2 cachelines when compiled for arm64. The goal is to reduce the memory footprint of ``struct s3c24xx_uart_info``. Reviewed-by: Sam Protsenko <[email protected]> Signed-off-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27tty: serial: samsung: change return type for s3c24xx_serial_rx_fifocnt()Tudor Ambarus1-2/+2
Change the return type of the s3c24xx_serial_rx_fifocnt() method to ``unsigned int`` as the method only returns the fifo size and does not handle error codes. Reviewed-by: Sam Protsenko <[email protected]> Signed-off-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27tty: serial: samsung: return bool for s3c24xx_serial_console_txrdy()Tudor Ambarus1-3/+3
s3c24xx_serial_console_txrdy() returned just 0 or 1 to indicate whether the TX is empty or not. Change its return type to bool. Reviewed-by: Sam Protsenko <[email protected]> Signed-off-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27tty: serial: samsung: return bool for s3c24xx_serial_txempty_nofifo()Tudor Ambarus1-2/+2
s3c24xx_serial_txempty_nofifo() returned either 0 or BIT(2), which is counterintuitive. Make the method return bool, and return true when TX is empty and false otherwise. Reviewed-by: Sam Protsenko <[email protected]> Signed-off-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-01-27tty: serial: samsung: don't compare with zero an if (bitwise expression)Tudor Ambarus1-1/+1
The bitwise AND with the fifo mask is used to check if the fifo is empty or not, it doesn't care about the length, thus the comparison with zero is implicit. Rely on the implicit comparison instead. Reviewed-by: Sam Protsenko <[email protected]> Signed-off-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>