aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/tty
AgeCommit message (Collapse)Author
2024-05-13Merge branch 'v5.10/standard/preempt-rt/base' into ↵v5.10/standard/preempt-rt/ti-sdk-5.10/ti-j72xxBruce Ashfield
v5.10/standard/preempt-rt/ti-sdk-5.10/ti-j72xx Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> # Conflicts: # drivers/remoteproc/remoteproc_core.c
2024-05-13Merge branch 'v5.10/standard/base' into v5.10/standard/preempt-rt/basev5.10/standard/preempt-rt/baseBruce Ashfield
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
2024-05-13Merge tag 'v5.10.216' into v5.10/standard/basev5.10/standard/baseBruce Ashfield
This is the 5.10.216 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmYzofkACgkQONu9yGCS # aT7Y7xAAlqSfBkRxGTdr5zNV8YNB15e9BJqDWvkQMzk14SELcYG31A5txuseRqzV # B/2JvbLSMdejbJqsTfi2XVus/Vjv4bbxpztFuKEIGe/PcdQmzSyfwKAZGAOPYyvK # yw+T1uM+5Qr2UszKKt58FNARNjp6EizNtTPoOxfUxUeNBJlla1oZWP1p1Qj11MZx # e4Gz8sXWmfrxW6WB9DkSaDTAvUtwYYzoX72kD6bti1HB4DB1RtR7HH5p0noCZZq7 # oZqhq/bxTPF/Y1P990QkX+6GXo04cpSvjW6AzV9a2ZdR7nW6cxcLxxsm/ZGBm/vy # yDmdL3NUyn8ivcCEI/rngtdz/JpM4kP/2ULuWWSuoXMvC68jXBjhznfPawF+wKdH # A2raG7gWWAusmbhVUGj+ETMuFaTfeerc/xbrFS/BuNTbp4DC8yeCj+1wtcLV6p2L # CITj80vRZyZVWSDvTzGNJUWp7SdbF+q/APn+DTlfLz0AoEhDEk1mhveGMFbN49x4 # jTwq61ISWYjbBiHlDzDdeXcectG8k1zNrt77WdN7bq67OR+owUx4Pet01fDLBtrr # 3mzCrz0XkhqtdjUTDu/RFffNo4PrQ+rTQRUGQXLEw4qHQhmyqldP6luaOCwovDBb # SRI8XjOkxkOodo6q7cLEKIa049gqqe7jrHMhmClbhXkIZtIJjZQ= # =E79M # -----END PGP SIGNATURE----- # gpg: Signature made Thu 02 May 2024 10:23:53 AM EDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2024-05-13Merge tag 'v5.10.215' into v5.10/standard/baseBruce Ashfield
This is the 5.10.215 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmYaZdgACgkQONu9yGCS # aT4oMxAA0pATFAq8RN5f9CmYlMg5HqHgzZ8lJv8P0/reOINhUa+F5sJb1n+x+Ch4 # WQbmiFeZRzfsKZ2qKhIdNR0Lg+9JOr/DtYXdSBZ6InfSWrTAIrQ9fjl5Warkmcgg # O4WbgF5BVgU3vGFATgxLvnUZwhR1D7WK93oMDunzrT7+OqyncU3f1Uj53ZAu9030 # z18UNqnTxDLYH/CMGwAeRkaZqBev9gZ1HdgQWA27SVLqWQwZq0al81Cmlo+ECVmk # 5dF6V2pid4qfKGJjDDfx1NS0PVnoP68iK4By1SXyoFV9VBiSwp77nUUyDr7YsHsT # u8GpZHr9jZvSO5/xtKv20NPLejTPCRKc06CbkwpikDRtGOocBL8em0GuVqlf8hMs # KwDb6ZEzYhXZGPJHbJM+aRD1tq/KHw9X7TrldOszMQPr6lubBtscPbg1FCg3OlcC # HUrtub0i275x7TH0dJeRTD8TRE9jRmF+tl7KQytEJM3JRrquFjLyhDj+/VJnZkiB # lzj3FRf4zshzgz4+CAeqXO/8Lu8b3fGYmcW1acCmk7emjDcXUKojPj/Aig6T4l7P # oCWDY3+w1E6eiyE8BazxY1KUa/41ld0VJnlW5JWGRaDFTJwrk0h6/rvf9qImSckw # IGx24UezRyp6NS1op3Qm2iwHLr41pFRfKxNm9ppgH9iBPzOhe38= # =pkLL # -----END PGP SIGNATURE----- # gpg: Signature made Sat 13 Apr 2024 07:00:40 AM EDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2024-05-13Merge tag 'v5.10.214' into v5.10/standard/baseBruce Ashfield
Linux 5.10.214 # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAmYDTvYACgkQ3qZv95d3 # LNzsThAAux0/qplp4OIshaClYXCArws4ef+RdjPFzlgbftA82sb+le3uEdXRBGYx # W/igqdvTXBfKc4QjgArW+PgIfaGgnmgHzXTUDy2/UOkoJFPt73l3v5hKMQkG1NeE # sbZ5mwhPp7zE/ARsj3W223j86xLzW1um3NfHYmYm9nh28mHMMSzqSeeIN5YmBjtY # 7UpbYUjPDoJQEA4Jh8UVlW02lNpGg6DDcfv3oLknILEgoGIuXpohWEH2uWEhDVvq # hwJ3qgNkaGmBxz5USyL0nEB1lexm+BF6yNeX27Xwh9nBJgOegaZb8KyjNFlFUb0l # m7MJ6LquIh/bnmw8i8XcdbtRjv+eFhayLBUaBV5BLRT0AZq3jooGx4R1dA/VN6VO # r8QbNE10UGLAOMJRSj+w0WWGSdsHHHlljhnQrToRyYjbXkXbcBz/muhdbNYEJep4 # EX0boAW4Dl+gbSV6U1437eHrDVaffvt1yxKzZxkHAiH4zGHfcwTTALdAKc562Tw3 # HgBU3ng2itTtrXmLAzDin+kvKBMdqARBRtsyRFVW78KqLZddalnTHgMQyIhz9rUr # WmZ1CiMj2vii9SdwiB/0aHXcvVBVXPi0thLXDDoH71cJhYtmj7VaYGAPQs9KrRqw # 3oI61MqxtMh7pMNeZdgIS1SmkqF2kF2b/rTbKAVJz95/gxngKkw= # =ltnq # -----END PGP SIGNATURE----- # gpg: Signature made Tue 26 Mar 2024 06:40:54 PM EDT # gpg: using RSA key E27E5D8A3403A2EF66873BBCDEA66FF797772CDC # gpg: Can't check signature: No public key
2024-05-13Merge tag 'v5.10.213' into v5.10/standard/baseBruce Ashfield
Linux 5.10.213 # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAmX0mzQACgkQ3qZv95d3 # LNzcdBAAigKyWPiCYJn6oBg5mChWFopyZpLx0LKA7Svf6whFPO9jJBmmHLZ3A06r # hctOwavg4KEAyjGNhd2cUSvJ8LcfmWOfSjQ2UogV7L4lYvy0NU3hTxvaYvjX0fcG # W0pXzsqHUFHjvkq0qU6ma71PvwfZ0IPWV179iMSOiDbjRDVctDgV3PcvuSJvoMgN # mnP5egJ31OwN80EWrjiGx5QB8DKP2ew6fPEZO9OwtVjKYnP0MZ4F2WLPhLVTeEqU # iIynX6Ncua1fH8q2q0qM4WAxUPdoTI2mGWixjWJDAxagfJpK8PUUNuCEiuZfu2VG # d4JkQXddtvPrUUdhb0194Ywd2yBdyf89kxrTn+Ki9smzgXToxJWm5q6eFHrBOB/x # 3XYfv/Ijd5nrb0DR00QiS2sBiVKhOJRSFJKUr0NoaBaXWNlTAf/VJMLwcToUl+nC # OshS+pwdRfL/PevCkL3S80zoccU8EUlHEVimXnpLeD5UM7wOk4Lv4qsudHj2bV0/ # WqHldGEBJgqSVuWF+1FhVWcwV3zPfckK72HmpHi3eF27la3PhNIvbLfMg1PH1btb # RCg9tblI8XJAiiIfNcl+uUDYViiBIHgskI7m4Kfe2nOeFj9felw4rMiOxbT8hVG7 # iKMv5jTwMPeFEy+i+V4v3ZKOAMz6Ql+VW1Yj7yr9bSM7iLu4cJI= # =OBDX # -----END PGP SIGNATURE----- # gpg: Signature made Fri 15 Mar 2024 03:02:12 PM EDT # gpg: using RSA key E27E5D8A3403A2EF66873BBCDEA66FF797772CDC # gpg: Can't check signature: No public key
2024-05-13Merge tag 'v5.10.211' into v5.10/standard/baseBruce Ashfield
This is the 5.10.211 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmXhxzkACgkQONu9yGCS # aT4DvBAAqUYqPc5hcVwlnlgENJtD1zuGbojcq0ziyR4kThlzQVfNlIs62yYbaJEr # Zmmm80fcdXYrrzkZrFfP+PWovehCcgeLDrrX95JkC8rRfT6UnJeT2K1POD8U2X3Z # peeqMt+gktDhRwlC2tVNaXHHCJTVjBl0d37lMu+i0If2ulloXAigbXtUgOJAwbnD # cbf92Tz1YT9VMimvFPSaFv5Rntlih9betZPtz2wcToDYoRTtNhbouAmIhN6E03Ji # um/nzIQMw4RHWqfw26XdKMzE47u2EZLFqkNoH1fzErvEjt2vY7QK/CXjkadXtzEL # l2OQnzYL5rhkRwazyMivs6IM3p6yCtiYC5ySVS3Hwvx0Hv/TUNmlUxM9ycSqOAnm # 9/T8dzztw3JOJGvy/mZ6W5rlatIsR/XYvpBqNrGxZwU4wWf4Dv1snQcbE/eSoXmt # 8xCXFmp0b5DSnXHoqr+1HWTl9iuUWpgrjdqYU6FOngknTKGhWSQUNwbm9fGymGnl # hdPNxS+HSmllLTC/iMkbCXZhYsTiErv4HokyPDDPR9bMzZJNl5aXXBjBJaJibIWC # oEGjDI1yQ1FiDdHX4DM4JgtcEVZcsgkhDwwR2u+/S6kktvnR4KtE0a1Qs42DfPJO # EQneeW8vltxCAVEYIpmYPB16LpQYOPto7h167SIoOZhyg46JGQ8= # =jXCp # -----END PGP SIGNATURE----- # gpg: Signature made Fri 01 Mar 2024 07:16:57 AM EST # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2024-05-02serial: mxs-auart: add spinlock around changing cts stateEmil Kronborg
[ Upstream commit 54c4ec5f8c471b7c1137a1f769648549c423c026 ] The uart_handle_cts_change() function in serial_core expects the caller to hold uport->lock. For example, I have seen the below kernel splat, when the Bluetooth driver is loaded on an i.MX28 board. [ 85.119255] ------------[ cut here ]------------ [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec [ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs [ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1 [ 85.151396] Hardware name: Freescale MXS (Device Tree) [ 85.156679] Workqueue: hci0 hci_power_on [bluetooth] (...) [ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4 [ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210 (...) Cc: stable@vger.kernel.org Fixes: 4d90bb147ef6 ("serial: core: Document and assert lock requirements for irq helpers") Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Emil Kronborg <emil.kronborg@protonmail.com> Link: https://lore.kernel.org/r/20240320121530.11348-1-emil.kronborg@protonmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-02serial/pmac_zilog: Remove flawed mitigation for rx irq floodFinn Thain
commit 1be3226445362bfbf461c92a5bcdb1723f2e4907 upstream. The mitigation was intended to stop the irq completely. That may be better than a hard lock-up but it turns out that you get a crash anyway if you're using pmac_zilog as a serial console: ttyPZ0: pmz: rx irq flood ! BUG: spinlock recursion on CPU#0, swapper/0 That's because the pr_err() call in pmz_receive_chars() results in pmz_console_write() attempting to lock a spinlock already locked in pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal BUG splat. The spinlock in question is the one in struct uart_port. Even when it's not fatal, the serial port rx function ceases to work. Also, the iteration limit doesn't play nicely with QEMU, as can be seen in the bug report linked below. A web search for other reports of the error message "pmz: rx irq flood" didn't produce anything. So I don't think this code is needed any more. Remove it. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Aneesh Kumar K.V <aneesh.kumar@kernel.org> Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: stable@kernel.org Cc: linux-m68k@lists.linux-m68k.org Link: https://github.com/vivier/qemu-m68k/issues/44 Link: https://lore.kernel.org/all/1078874617.9746.36.camel@gaston/ Acked-by: Michael Ellerman <mpe@ellerman.id.au> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <stable@kernel.org> Signed-off-by: Finn Thain <fthain@linux-m68k.org> Link: https://lore.kernel.org/r/e853cf2c762f23101cd2ddec0cc0c2be0e72685f.1712568223.git.fthain@linux-m68k.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-13tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldiscThadeu Lima de Souza Cascardo
commit 67c37756898a5a6b2941a13ae7260c89b54e0d88 upstream. Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway. Require initial namespace CAP_NET_ADMIN to do that. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Link: https://lore.kernel.org/r/20230731185942.279611-1-cascardo@canonical.com Cc: Salvatore Bonaccorso <carnil@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-13serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFOHugo Villeneuve
commit dbf4ab821804df071c8b566d9813083125e6d97b upstream. The SC16IS7XX IC supports a burst mode to access the FIFOs where the initial register address is sent ($00), followed by all the FIFO data without having to resend the register address each time. In this mode, the IC doesn't increment the register address for each R/W byte. The regmap_raw_read() and regmap_raw_write() are functions which can perform IO over multiple registers. They are currently used to read/write from/to the FIFO, and although they operate correctly in this burst mode on the SPI bus, they would corrupt the regmap cache if it was not disabled manually. The reason is that when the R/W size is more than 1 byte, these functions assume that the register address is incremented and handle the cache accordingly. Convert FIFO R/W functions to use the regmap _noinc_ versions in order to remove the manual cache control which was a workaround when using the _raw_ versions. FIFO registers are properly declared as volatile so cache will not be used/updated for FIFO accesses. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: <stable@vger.kernel.org> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20231211171353.2901416-6-hugo@hugovil.com Cc: Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by: GONG, Ruiqi <gongruiqi1@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-13vt: fix unicode buffer corruption when deleting charactersNicolas Pitre
commit 1581dafaf0d34bc9c428a794a22110d7046d186d upstream. This is the same issue that was fixed for the VGA text buffer in commit 39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the buffer"). The cure is also the same i.e. replace memcpy() with memmove() due to the overlaping buffers. Signed-off-by: Nicolas Pitre <nico@fluxnic.net> Fixes: 81732c3b2fed ("tty vt: Fix line garbage in virtual console on command line edition") Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/sn184on2-3p0q-0qrq-0218-895349s4753o@syhkavp.arg Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-13tty: serial: fsl_lpuart: avoid idle preamble pending if CTS is enabledSherry Sun
commit 74cb7e0355fae9641f825afa389d3fba3b617714 upstream. If the remote uart device is not connected or not enabled after booting up, the CTS line is high by default. At this time, if we enable the flow control when opening the device(for example, using “stty -F /dev/ttyLP4 crtscts” command), there will be a pending idle preamble(first writing 0 and then writing 1 to UARTCTRL_TE will queue an idle preamble) that cannot be sent out, resulting in the uart port fail to close(waiting for TX empty), so the user space stty will have to wait for a long time or forever. This is an LPUART IP bug(idle preamble has higher priority than CTS), here add a workaround patch to enable TX CTS after enabling UARTCTRL_TE, so that the idle preamble does not get stuck due to CTS is deasserted. Fixes: 380c966c093e ("tty: serial: fsl_lpuart: add 32-bit register interface support") Cc: stable <stable@kernel.org> Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Link: https://lore.kernel.org/r/20240305015706.1050769-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-13serial: Lock console when calling into driver before registrationPeter Collingbourne
[ Upstream commit 801410b26a0e8b8a16f7915b2b55c9528b69ca87 ] During the handoff from earlycon to the real console driver, we have two separate drivers operating on the same device concurrently. In the case of the 8250 driver these concurrent accesses cause problems due to the driver's use of banked registers, controlled by LCR.DLAB. It is possible for the setup(), config_port(), pm() and set_mctrl() callbacks to set DLAB, which can cause the earlycon code that intends to access TX to instead access DLL, leading to missed output and corruption on the serial line due to unintended modifications to the baud rate. In particular, for setup() we have: univ8250_console_setup() -> serial8250_console_setup() -> uart_set_options() -> serial8250_set_termios() -> serial8250_do_set_termios() -> serial8250_do_set_divisor() For config_port() we have: serial8250_config_port() -> autoconfig() For pm() we have: serial8250_pm() -> serial8250_do_pm() -> serial8250_set_sleep() For set_mctrl() we have (for some devices): serial8250_set_mctrl() -> omap8250_set_mctrl() -> __omap8250_set_mctrl() To avoid such problems, let's make it so that the console is locked during pre-registration calls to these callbacks, which will prevent the earlycon driver from running concurrently. Remove the partial solution to this problem in the 8250 driver that locked the console only during autoconfig_irq(), as this would result in a deadlock with the new approach. The console continues to be locked during autoconfig_irq() because it can only be called through uart_configure_port(). Although this patch introduces more locking than strictly necessary (and in particular it also locks during the call to rs485_config() which is not affected by this issue as far as I can tell), it follows the principle that it is the responsibility of the generic console code to manage the earlycon handoff by ensuring that earlycon and real console driver code cannot run concurrently, and not the individual drivers. Signed-off-by: Peter Collingbourne <pcc@google.com> Reviewed-by: John Ogness <john.ogness@linutronix.de> Link: https://linux-review.googlesource.com/id/I7cf8124dcebf8618e6b2ee543fa5b25532de55d8 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240304214350.501253-1-pcc@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-13serial: max310x: fix NULL pointer dereference in I2C instantiationHugo Villeneuve
[ Upstream commit 0d27056c24efd3d63a03f3edfbcfc4827086b110 ] 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: 2e1f2d9a9bdb ("serial: max310x: implement I2C support") Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20240118152213.2644269-2-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-26serial: 8250_exar: Don't remove GPIO device on suspendAndy Shevchenko
[ Upstream commit 73b5a5c00be39e23b194bad10e1ea8bb73eee176 ] It seems a copy&paste mistake that suspend callback removes the GPIO device. There is no counterpart of this action, means once suspended there is no more GPIO device available untile full unbind-bind cycle is performed. Remove suspicious GPIO device removal in suspend. Fixes: d0aeaa83f0b0 ("serial: exar: split out the exar code from 8250_pci") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240219150627.2101198-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-26tty: serial: samsung: fix tx_empty() to return TIOCSER_TEMTTudor Ambarus
[ Upstream commit 314c2b399288f0058a8c5b6683292cbde5f1531b ] 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: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Link: https://lore.kernel.org/r/20240119104526.1221243-2-tudor.ambarus@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-26serial: max310x: fix syntax error in IRQ error messageHugo Villeneuve
[ Upstream commit 8ede8c6f474255b2213cccd7997b993272a8e2f9 ] Replace g with q. Helpful when grepping thru source code or logs for "request" keyword. Fixes: f65444187a66 ("serial: New serial driver MAX310X") Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20240118152213.2644269-6-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-26tty: vt: fix 20 vs 0x20 typo in EScsiignoreJiri Slaby (SUSE)
[ Upstream commit 0e6a92f67c8a94707f7bb27ac29e2bdf3e7c167d ] The if (c >= 20 && c <= 0x3f) test added in commit 7a99565f8732 is wrong. 20 is DC4 in ascii and it makes no sense to consider that as the bottom limit. Instead, it should be 0x20 as in the other test in the commit above. This is supposed to NOT change anything as we handle interesting 20-0x20 asciis far before this if. So for sakeness, change to 0x20 (which is SPACE). Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org> Fixes: 7a99565f8732 ("vt: ignore csi sequences with intermediate characters.") Cc: Martin Hostettler <textshell@uchuujin.de> Link: https://lore.kernel.org/all/ZaP45QY2WEsDqoxg@neutronstar.dyndns.org/ Tested-by: Helge Deller <deller@gmx.de> # parisc STI console Link: https://lore.kernel.org/r/20240122110401.7289-4-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-15serial: max310x: fix IO data corruption in batched operationsJan Kundrát
[ Upstream commit 3f42b142ea1171967e40e10e4b0241c0d6d28d41 ] After upgrading from 5.16 to 6.1, our board with a MAX14830 started producing lots of garbage data over UART. Bisection pointed out commit 285e76fc049c as the culprit. That patch tried to replace hand-written code which I added in 2b4bac48c1084 ("serial: max310x: Use batched reads when reasonably safe") with the generic regmap infrastructure for batched operations. Unfortunately, the `regmap_raw_read` and `regmap_raw_write` which were used are actually functions which perform IO over *multiple* registers. That's not what is needed for accessing these Tx/Rx FIFOs; the appropriate functions are the `_noinc_` versions, not the `_raw_` ones. Fix this regression by using `regmap_noinc_read()` and `regmap_noinc_write()` along with the necessary `regmap_config` setup; with this patch in place, our board communicates happily again. Since our board uses SPI for talking to this chip, the I2C part is completely untested. Fixes: 285e76fc049c ("serial: max310x: use regmap methods for SPI batch operations") Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Link: https://lore.kernel.org/r/79db8e82aadb0e174bc82b9996423c3503c8fb37.1680732084.git.jan.kundrat@cesnet.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-15serial: max310x: implement I2C supportCosmin Tanislav
[ Upstream commit 2e1f2d9a9bdbe12ee475c82a45ac46a278e8049a ] I2C implementation on this chip has a few key differences compared to SPI, as described in previous patches. * extended register space access needs no extra logic * slave address is used to select which UART to communicate with To accommodate these differences, add an I2C interface config, set the RevID register address and implement an empty method for setting the GlobalCommand register, since no special handling is needed for the extended register space. To handle the port-specific slave address, create an I2C dummy device for each port, except the base one (UART0), which is expected to be the one specified in firmware, and create a regmap for each I2C device. Add minimum and maximum slave addresses to each devtype for sanity checking. Also, use a separate regmap config with no write_flag_mask, since I2C has a R/W bit in its slave address, and set the max register to the address of the RevID register, since the extended register space needs no extra logic. Finally, add the I2C driver. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com> Link: https://lore.kernel.org/r/20220605144659.4169853-5-demonsingur@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 3f42b142ea11 ("serial: max310x: fix IO data corruption in batched operations") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-15serial: max310x: make accessing revision id interface-agnosticCosmin Tanislav
[ Upstream commit b3883ab5e95713e479f774ea68be275413e8e5b2 ] SPI can only use 5 address bits, since one bit is reserved for specifying R/W and 2 bits are used to specify the UART port. To access registers that have addresses past 0x1F, an extended register space can be enabled by writing to the GlobalCommand register (address 0x1F). I2C uses 8 address bits. The R/W bit is placed in the slave address, and so is the UART port. Because of this, registers that have addresses higher than 0x1F can be accessed normally. To access the RevID register, on SPI, 0xCE must be written to the 0x1F address to enable the extended register space, after which the RevID register is accessible at address 0x5. 0xCD must be written to the 0x1F address to disable the extended register space. On I2C, the RevID register is accessible at address 0x25. Create an interface config struct, and add a method for toggling the extended register space and a member for the RevId register address. Implement these for SPI. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com> Link: https://lore.kernel.org/r/20220605144659.4169853-4-demonsingur@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 3f42b142ea11 ("serial: max310x: fix IO data corruption in batched operations") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-15serial: max310x: Unprepare and disable clock in error pathAndy Shevchenko
[ Upstream commit 61acabaae5ba58b3c32e6e90d24c2c0827fd27a8 ] In one error case the clock may be left prepared and enabled. Unprepare and disable clock in that case to balance state of the hardware. Fixes: d4d6f03c4fb3 ("serial: max310x: Try to get crystal clock rate from property") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210625153733.12911-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-15serial: max310x: prevent infinite while() loop in port startupHugo Villeneuve
[ Upstream commit b35f8dbbce818b02c730dc85133dc7754266e084 ] 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: stable@vger.kernel.org Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20240116213001.3691629-5-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-15serial: max310x: use a separate regmap for each portCosmin Tanislav
[ Upstream commit 6ef281daf020592c219fa91780abc381c6c20db5 ] The driver currently does manual register manipulation in multiple places to talk to a specific UART port. In order to talk to a specific UART port over SPI, the bits U1 and U0 of the register address can be set, as explained in the Command byte configuration section of the datasheet. Make this more elegant by creating regmaps for each UART port and setting the read_flag_mask and write_flag_mask accordingly. All communcations regarding global registers are done on UART port 0, so replace the global regmap entirely with the port 0 regmap. Also, remove the 0x1f masks from reg_writeable(), reg_volatile() and reg_precious() methods, since setting the U1 and U0 bits of the register address happens inside the regmap core now. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com> Link: https://lore.kernel.org/r/20220605144659.4169853-3-demonsingur@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: b35f8dbbce81 ("serial: max310x: prevent infinite while() loop in port startup") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-15serial: max310x: use regmap methods for SPI batch operationsCosmin Tanislav
[ Upstream commit 285e76fc049c4d32c772eea9460a7ef28a193802 ] The SPI batch read/write operations can be implemented as simple regmap raw read and write, which will also try to do a gather write just as it is done here. Use the regmap raw read and write methods. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com> Link: https://lore.kernel.org/r/20220605144659.4169853-2-demonsingur@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: b35f8dbbce81 ("serial: max310x: prevent infinite while() loop in port startup") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-15serial: max310x: Make use of device propertiesAndy Shevchenko
[ Upstream commit c808fab604ca62cff19ee6b261211483830807aa ] Device property API allows to gather device resources from different sources, such as ACPI. Convert the drivers to unleash the power of device property API. Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201007084635.594991-1-andy.shevchenko@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: b35f8dbbce81 ("serial: max310x: prevent infinite while() loop in port startup") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-15serial: max310x: fail probe if clock crystal is unstableHugo Villeneuve
[ Upstream commit 8afa6c6decea37e7cb473d2c60473f37f46cea35 ] 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: stable@vger.kernel.org Suggested-by: Jan Kundrát <jan.kundrat@cesnet.cz> Link: https://www.spinics.net/lists/linux-serial/msg35773.html Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20240116213001.3691629-4-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-15serial: max310x: Try to get crystal clock rate from propertyAndy Shevchenko
[ Upstream commit d4d6f03c4fb3a91dadfe147b47edd40e4d7e4d36 ] In some configurations, mainly ACPI-based, the clock frequency of the device is supplied by very well established 'clock-frequency' property. Hence, try to get it from the property at last if no other providers are available. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210517172930.83353-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 8afa6c6decea ("serial: max310x: fail probe if clock crystal is unstable") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-15serial: max310x: Use devm_clk_get_optional() to get the input clockAndy Shevchenko
[ Upstream commit 974e454d6f96da0c0ab1b4115b92587dd9406f6a ] Simplify the code which fetches the input clock by using devm_clk_get_optional(). If no input clock is present devm_clk_get_optional() will return NULL instead of an error which matches the behavior of the old code. Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201007084635.594991-2-andy.shevchenko@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 8afa6c6decea ("serial: max310x: fail probe if clock crystal is unstable") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-01hvc/xen: prevent concurrent accesses to the shared ringRoger Pau Monne
[ Upstream commit 6214894f49a967c749ee6c07cb00f9cede748df4 ] The hvc machinery registers both a console and a tty device based on the hv ops provided by the specific implementation. Those two interfaces however have different locks, and there's no single locks that's shared between the tty and the console implementations, hence the driver needs to protect itself against concurrent accesses. Otherwise concurrent calls using the split interfaces are likely to corrupt the ring indexes, leaving the console unusable. Introduce a lock to xencons_info to serialize accesses to the shared ring. This is only required when using the shared memory console, concurrent accesses to the hypercall based console implementation are not an issue. Note the conditional logic in domU_read_console() is slightly modified so the notify_daemon() call can be done outside of the locked region: it's an hypercall and there's no need for it to be done with the lock held. Fixes: b536b4b96230 ('xen: use the hvc console infrastructure for Xen console') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20221130150919.13935-1-roger.pau@citrix.com Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-27Merge branch 'v5.10/standard/base' into ↵Bruce Ashfield
v5.10/standard/preempt-rt/ti-sdk-5.10/ti-j72xx Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> # Conflicts: # drivers/pci/controller/dwc/pcie-designware-ep.c
2024-02-27Merge branch 'v5.10/standard/base' into v5.10/standard/preempt-rt/baseBruce Ashfield
2024-02-26Merge tag 'v5.10.210' into v5.10/standard/baseBruce Ashfield
This is the 5.10.210 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmXYTLkACgkQONu9yGCS # aT4+fhAAqqR/Cvx53ZKMQ8GZTCudAZnr/Dz6kWYwxhhhIbQjDpCaf9mgsrEDaQS2 # ancSZjzYaOUIXq/IsthXxQIUhiZbuM3iuSEi7+odWgSYdkFyzuUt8MWLBGSaB5Er # ojn+APtq7vPXTSnp7uMwqMC3/BHCKkeYIjRVevhhHBKG5d3lzkV1xU8NcvMkLaly # CIRxpWXD3w2b7K0GEbb/zN1GQEHDCQcxjuaJoe/5FKGJkqd3T31eyiJTRumCCMcz # j8vkGkYmcMJpWf04iLgVA1p13I5/HGrXdEBI/GutN8IABIC3Cp42jW8phHYKW5ZM # a4R25LZG5buND1Ubpq+EDrYn3EaPek5XRki0w8ZAXfNa3rYc+N6mQjkzNSOzhJ/5 # VNsn3EAE1Dwtar5Z3ASe9ugDbh+0bgx85PbfaADK88V+qWb3DVr1TBWmDNu2vfVP # rv4I0EKu9r3vOE8aNMEBuhAVkIK3mEQUxwab6RKNrMby/5Uwa+ugrrUtQd8V+T1S # j6r6v7u7aZ8mhYO7d6WSvAKL85lCWGbs3WRIKCJZmDRyqWrWW9tVWRN9wrZ2QnRr # iaCQKk8P474P7/j1zwnmih8l4wS1oszveNziWwd0fi1Nn/WQYM+JKYQvpuQijmQ+ # J9jLyWo7a59zffIE6mzJdNwFy9hlw9X+VnJmExk/Q88Z7Bt5wPQ= # =laYd # -----END PGP SIGNATURE----- # gpg: Signature made Fri 23 Feb 2024 02:43:53 AM EST # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2024-02-23serial: 8250_exar: Set missing rs485_supported flagLino Sanfilippo
[ Upstream commit 0c2a5f471ce58bca8f8ab5fcb911aff91eaaa5eb ] The UART supports an auto-RTS mode in which the RTS pin is automatically activated during transmission. So mark this mode as being supported even if RTS is not controlled by the driver but the UART. Also the serial core expects now at least one of both modes rts-on-send or rts-after-send to be supported. This is since during sanitization unsupported flags are deleted from a RS485 configuration set by userspace. However if the configuration ends up with both flags unset, the core prints a warning since it considers such a configuration invalid (see uart_sanitize_serial_rs485()). Cc: <stable@vger.kernel.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> Link: https://lore.kernel.org/r/20240103061818.564-8-l.sanfilippo@kunbus.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23serial: 8250_exar: Fill in rs485_supportedIlpo Järvinen
[ Upstream commit 59c221f8e1269278161313048c71929c9950b2c4 ] Add information on supported serial_rs485 features. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220606100433.13793-8-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 0c2a5f471ce5 ("serial: 8250_exar: Set missing rs485_supported flag") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23serial: Add rs485_supported to uart_portIlpo Järvinen
[ Upstream commit 8925c31c1ac2f1e05da988581f2a70a2a8c4d638 ] Preparing to move serial_rs485 struct sanitization into serial core, each driver has to provide what fields/flags it supports. This information is pointed into by rs485_supported. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220606100433.13793-4-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 0c2a5f471ce5 ("serial: 8250_exar: Set missing rs485_supported flag") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23serial: max310x: improve crystal stable clock detectionHugo Villeneuve
commit 93cd256ab224c2519e7c4e5f58bb4f1ac2bf0965 upstream. 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: stable@vger.kernel.org Suggested-by: Jan Kundrát <jan.kundrat@cesnet.cz> Link: https://www.spinics.net/lists/linux-serial/msg35773.html Link: https://lore.kernel.org/all/20240110174015.6f20195fde08e5c9e64e5675@hugovil.com/raw Link: https://github.com/boundarydevices/linux/commit/e5dfe3e4a751392515d78051973190301a37ca9a Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20240116213001.3691629-3-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-23serial: max310x: set default value when reading clock ready bitHugo Villeneuve
commit 0419373333c2f2024966d36261fd82a453281e80 upstream. 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: stable@vger.kernel.org Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20240116213001.3691629-2-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-23tty: allow TIOCSLCKTRMIOS with CAP_CHECKPOINT_RESTOREAdrian Reber
[ Upstream commit e0f25b8992345aa5f113da2815f5add98738c611 ] The capability CAP_CHECKPOINT_RESTORE was introduced to allow non-root users to checkpoint and restore processes as non-root with CRIU. This change extends CAP_CHECKPOINT_RESTORE to enable the CRIU option '--shell-job' as non-root. CRIU's man-page describes the '--shell-job' option like this: Allow one to dump shell jobs. This implies the restored task will inherit session and process group ID from the criu itself. This option also allows to migrate a single external tty connection, to migrate applications like top. TIOCSLCKTRMIOS can only be done if the process has CAP_SYS_ADMIN and this change extends it to CAP_SYS_ADMIN or CAP_CHECKPOINT_RESTORE. With this change it is possible to checkpoint and restore processes which have a tty connection as non-root if CAP_CHECKPOINT_RESTORE is set. Acked-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Adrian Reber <areber@redhat.com> Acked-by: Andrei Vagin <avagin@gmail.com> Link: https://lore.kernel.org/r/20231208143656.1019-1-areber@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23serial: sc16is7xx: add check for unsupported SPI modes during probeHugo Villeneuve
[ Upstream commit 6d710b769c1f5f0d55c9ad9bb49b7dce009ec103 ] The original comment is confusing because it implies that variants other than the SC16IS762 supports other SPI modes beside SPI_MODE_0. Extract from datasheet: The SC16IS762 differs from the SC16IS752 in that it supports SPI clock speeds up to 15 Mbit/s instead of the 4 Mbit/s supported by the SC16IS752... In all other aspects, the SC16IS762 is functionally and electrically the same as the SC16IS752. The same is also true of the SC16IS760 variant versus the SC16IS740 and SC16IS750 variants. For all variants, only SPI mode 0 is supported. Change comment and abort probing if the specified SPI mode is not SPI_MODE_0. Fixes: 2c837a8a8f9f ("sc16is7xx: spi interface is added") Cc: <stable@vger.kernel.org> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20231221231823.2327894-3-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23serial: sc16is7xx: set safe default SPI clock frequencyHugo Villeneuve
[ Upstream commit 3ef79cd1412236d884ab0c46b4d1921380807b48 ] 15 MHz is supported only by 76x variants. If the SPI clock frequency is not specified, use a safe default clock value of 4 MHz that is supported by all variants. Also use HZ_PER_MHZ macro to improve readability. Fixes: 2c837a8a8f9f ("sc16is7xx: spi interface is added") Cc: <stable@vger.kernel.org> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20231221231823.2327894-4-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-20Merge branch 'v5.10/standard/base' into ↵Bruce Ashfield
v5.10/standard/preempt-rt/ti-sdk-5.10/ti-j72xx Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> # Conflicts: # arch/arm64/boot/dts/ti/k3-am65-main.dtsi
2024-02-20Merge branch 'v5.10/standard/base' into v5.10/standard/preempt-rt/baseBruce Ashfield
2024-02-20Merge tag 'v5.10.209' into v5.10/standard/baseBruce Ashfield
This is the 5.10.209 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmWy4soACgkQONu9yGCS # aT5VxA/8DwcU5ST4AJ4EOaaWHUU/HHMV2/bSOLDhVTEl4gEnaj3LeOz2bIrfzNgb # 9bHBYCtl3PFl+hZxY3wvC55o80SeIjskpU9rHvzQ36y8dd+uIfXjhLHPBHV7AO4m # Yu6+dEoaJqFpVgyBKn+YFg6x0w8m1sWX5tcrQRkcMt/REak91bqdf8l0JDz1Jd2d # uiCh3ssy9yNl7UTdPovzgK9IZ4zv0Kk13F9lXcsMEmjmB3awyaQlglBlCG0NEUKj # wRWzT4uKHHcW4sHg/UyEfVUnKQGZvf7/eOAXK2kEsBFSzcl+QLwZxWSmRDL81dzl # 1jjivPCQKtEPZqIZnDQuNvtijw5NNT/yJ5yRlJ7qmuCuBA/2VYqecEAVERhd6dYj # le6oMu3340G5Dyq43XhOtPf+Fm1HkuMtQ49oyK8k/nEZSFGDWlrJ//cuOWYjUbpo # d/fgCaLCxAm60KPiCnGdC7GQcIDJBbgjC3XDvxYGLA0ee+31XqhHDTlOkeHv+7oP # 3PwSssT/M4Ppwzb0Imna/qaCO7lKUbS4oQSLahbfGg+fyAKfM7N3No7raF+L4VIE # RACbvKrSfv2WuTncQBdd/kQ2kvhuGMD4L1WjXNFi2VQzI2JbEcYZcJWYXF5tvCNj # aotDJumjF0WtGWcEdKg8Cr2AArMm6dHmRS5VVIG+taWpiWIl5lc= # =iU8L # -----END PGP SIGNATURE----- # gpg: Signature made Thu 25 Jan 2024 05:38:02 PM EST # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2024-01-25serial: imx: Correct clock error message in function probe()Christoph Niedermaier
[ Upstream commit 3e189470cad27d41a3a9dc02649f965b7ed1c90f ] Correct the clock error message by changing the clock name. Fixes: 1e512d45332b ("serial: imx: add error messages when .probe fails") Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231224093209.2612-1-cniedermaier@dh-electronics.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-25usb: cdc-acm: return correct error code on unsupported breakOliver Neukum
[ Upstream commit 66aad7d8d3ec5a3a8ec2023841bcec2ded5f65c9 ] In ACM support for sending breaks to devices is optional. If a device says that it doenot support sending breaks, the host must respect that. Given the number of optional features providing tty operations for each combination is not practical and errors need to be returned dynamically if unsupported features are requested. In case a device does not support break, we want the tty layer to treat that like it treats drivers that statically cannot support sending a break. It ignores the inability and does nothing. This patch uses EOPNOTSUPP to indicate that. Signed-off-by: Oliver Neukum <oneukum@suse.com> Fixes: 9e98966c7bb94 ("tty: rework break handling") Link: https://lore.kernel.org/r/20231207132639.18250-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-25tty: use 'if' in send_break() instead of 'goto'Jiri Slaby (SUSE)
[ Upstream commit 24f2cd019946fc2e88e632d2e24a34c2cc3f2be4 ] Now, the "jumped-over" code is simple enough to be put inside an 'if'. Do so to make it 'goto'-less. Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20230919085156.1578-16-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 66aad7d8d3ec ("usb: cdc-acm: return correct error code on unsupported break") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-25tty: don't check for signal_pending() in send_break()Jiri Slaby (SUSE)
[ Upstream commit fd99392b643b824813df2edbaebe26a2136d31e6 ] msleep_interruptible() will check on its own. So no need to do the check in send_break() before calling the above. Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20230919085156.1578-15-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 66aad7d8d3ec ("usb: cdc-acm: return correct error code on unsupported break") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-25tty: early return from send_break() on TTY_DRIVER_HARDWARE_BREAKJiri Slaby (SUSE)
[ Upstream commit 66619686d187b4a6395316b7f39881e945dce4bc ] If the driver sets TTY_DRIVER_HARDWARE_BREAK, we leave ops->break_ctl() to the driver and return from send_break(). But we do it using a local variable and keep the code flowing through the end of the function. Instead, do 'return' immediately with the ops->break_ctl()'s return value. This way, we don't have to stuff the 'else' branch of the 'if' with the software break handling. And we can re-indent the function too. Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20230919085156.1578-14-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 66aad7d8d3ec ("usb: cdc-acm: return correct error code on unsupported break") Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-07-06 19:01:45 +0000