- 13 May, 2021 40 commits
-
-
Jiri Slaby authored
capi have many pr_debugs in tty_operations hooks to print only a functions name. We have better debugging aids in the kernel many years now. So remove these useless pr_debugs. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Karsten Keil <isdn@linux-pingi.de> Cc: netdev@vger.kernel.org Link: https://lore.kernel.org/r/20210505091928.22010-34-jslaby@suse.czSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiri Slaby authored
break_ctl and set_ldisc are optional tty_operations hooks. Given capi does nothing useful in them, just remove these. Signed-off-by:
-
Jiri Slaby authored
tty_operations::set_termios is optional. If it doesn't exist, nothing is called. So remove almost¹ empty set_termios implementations. ¹ capi had an useless pr_debug in it. Signed-off-by:
Anton Ivanov <anton.ivanov@cambridgegreys.com> Link: https://lore.kernel.org/r/20210505091928.22010-32-jslaby@suse.czSigned-off-by:
-
Jiri Slaby authored
tty_operations::flush_buffer is optional. If it doesn't exist, nothing is called. So remove almost¹ empty flush_buffer implementations. ¹ capi had an useless pr_debug in it. Signed-off-by:
-
Jiri Slaby authored
ntty_chars_in_buffer is overly complicated. Simplify it by inverting the condition. Side FIXME: how can dc or port be NULL here? Signed-off-by:
-
Jiri Slaby authored
tty_operations::chars_in_buffer is another hook which is expected to return values >= 0. So make it explicit by the return type too -- use unsigned int. Signed-off-by:
David Sterba <dsterba@suse.com> Cc: Jeff Dike <jdike@addtoit.com> Cc: Richard Weinberger <richard@nod.at> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Cc: Jens Taprogge <jens.taprogge@taprogge.org> Cc: Karsten Keil <isdn@linux-pingi.de> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: David Lin <dtwlin@gmail.com> Cc: Johan Hovold <johan@kernel.org> Cc: Alex Elder <elder@kernel.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Oliver Neukum <oneukum@suse.com> Cc: Felipe Balbi <balbi@kernel.org> Cc: Mathias Nyman <mathias.nyman@intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Link: https://lore.kernel.org/r/20210505091928.22010-27-jslaby@suse.czSigned-off-by:
-
Jiri Slaby authored
The only user of tty_ops::chars_in_buffer is tty_chars_in_buffer. And it considers tty_ops::chars_in_buffer optional. In case it's NULL, zero is returned. So remove all those chars_in_buffer from tty_ops which return zero. (Zero means such driver doesn't buffer.) Signed-off-by:
-
Jiri Slaby authored
tty_buffer_space_avail returns values >= 0, so make it clear by the return type. Signed-off-by:
-
Jiri Slaby authored
Line disciplines expect a positive value or zero returned from tty->ops->write_room (invoked by tty_write_room). So make this assumption explicit by using unsigned int as a return value. Both of tty->ops->write_room and tty_write_room. Signed-off-by:
Laurentiu Tudor <laurentiu.tudor@nxp.com> Acked-by:
Alex Elder <elder@linaro.org> Acked-by: Max Filippov <jcmvbkbc@gmail.com> # xtensa Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: Helge Deller <deller@gmx.de> Cc: Jeff Dike <jdike@addtoit.com> Cc: Richard Weinberger <richard@nod.at> Cc: Chris Zankel <chris@zankel.net> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Cc: Jens Taprogge <jens.taprogge@taprogge.org> Cc: Karsten Keil <isdn@linux-pingi.de> Cc: Scott Branden <scott.branden@broadcom.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: David Lin <dtwlin@gmail.com> Cc: Johan Hovold <johan@kernel.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Oliver Neukum <oneukum@suse.com> Cc: Felipe Balbi <balbi@kernel.org> Cc: Mathias Nyman <mathias.nyman@intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Link: https://lore.kernel.org/r/20210505091928.22010-23-jslaby@suse.czSigned-off-by:
-
Jiri Slaby authored
Don't access tty->ops->write_room directly, use tty_write_room helper instead. Signed-off-by:
-
Jiri Slaby authored
Use the classic failpath handling using gotos in st_core_init. That way, tty_unregister_ldisc needs not be repeated on two places. Signed-off-by:
-
Jiri Slaby authored
Now that noone checks the return value of tty_unregister_ldisc, make the function return 'void'. Signed-off-by:
-
Jiri Slaby authored
tty_unregister_ldisc now returns 0 = success. No need to check the return value. In fact, the users only warned if an error occured and didn't do anything useful anyway -- the ldisc module was unloaded in any case. Signed-off-by:
-
Jiri Slaby authored
The refcount is checked only in tty_unregister_ldisc and EBUSY returned if it is nonzero. But none of the tty_unregister_ldisc callers act anyhow if this (or any other) error is returned. So remove tty_ldisc_ops::refcount completely and make tty_unregister_ldisc return 'void' in the next patches. That means we assume tty_unregister_ldisc is not called while the ldisc might be in use. That relies on try_module_get in get_ldops and module_put in put_ldops. Signed-off-by:
-
Jiri Slaby authored
Make tty_unregister_ldisc symmetric to tty_register_ldisc by accepting struct tty_ldisc_ops as a parameter instead of ldisc number. This avoids checking of the ldisc number bounds in tty_unregister_ldisc. Signed-off-by:
-
Jiri Slaby authored
Use the classic failpath handling using gotos in gsm_init. That way, tty_unregister_ldisc needs not be repeated on two places. Signed-off-by:
-
Jiri Slaby authored
There is no reason to pass the ldisc number to tty_register_ldisc separately. Just set it in the already defined tty_ldisc_ops in all the ldiscs. This simplifies tty_register_ldisc a bit too (no need to set the num member there). Signed-off-by:
-
Jiri Slaby authored
Group the ctrl members under a single struct called ctrl. The new struct contains 'pgrp', 'session', 'pktstatus', and 'packet'. 'pktstatus' and 'packet' used to be bits in a bitfield. The struct also contains the lock protecting them to share the same cache line. Note that commit c545b66c (tty: Serialize tcflow() with other tty flow control changes) added a padding to the original bitfield. It was for the bitfield to occupy a whole 64b word to avoid interferring stores on Alpha (cannot we evaporate this arch with weird implications to C code yet?). But it doesn't work as expected as the padding (tty_struct::ctrl_unused) is aligned to a 8B boundary too and occupies some bytes from the next word. So make it reliable by: 1) setting __aligned of the struct -- that aligns the start, and 2) making 'unsigned long unused[0]' as the last member of the struct -- pads the end. Add a kerneldoc comment for this grouped members. Signed-off-by:
-
Jiri Slaby authored
Group the flow flags under a single struct called flow. The new struct contains 'stopped' and 'tco_stopped' bools which used to be bits in a bitfield. The struct also contains the lock protecting them to potentially share the same cache line. Note that commit c545b66c (tty: Serialize tcflow() with other tty flow control changes) added a padding to the original bitfield. It was for the bitfield to occupy a whole 64b word to avoid interferring stores on Alpha (cannot we evaporate this arch with weird implications to C code yet?). But it doesn't work as expected as the padding (tty_struct::unused) is aligned to a 8B boundary too and occupies some bytes from the next word. So make it reliable by: 1) setting __aligned of the struct -- that aligns the start, and 2) making 'unsigned long unused[0]' as the last member of the struct -- pads the end. This is also the perfect time to start the documentation of tty_struct where all this lives. So we start by documenting what these bools actually serve for. And why we do all the alignment dances. Only the few up-to-date information from the Theodore's comment made it into this new Kerneldoc comment. Signed-off-by:
-
Jiri Slaby authored
Char pointer (cp) passed to tty_ldisc_ops::receive_buf{,2} is const. There is no reason for flag pointer (fp) not to be too. So switch it in the definition and all uses. Signed-off-by: -
Jiri Slaby authored
A return at the end of a void-returning function is superfluous. Get rid of it. Signed-off-by:
-
Jiri Slaby authored
Handle !TTY_NORMAL as a short path and 'continue' the loop. Do the rest as a normal code flow. This decreases the indentation level by one and makes the code flow more understandable. IOW, we avoid if (cond) { LONG CODE; } else single_line(); by if (!cond) { single_line(); continue; } LONG CODE; While at it, invert also the 'if (!test_bit) A else B' into 'if (test_bit) B else A'. Signed-off-by: -
Jiri Slaby authored
It might be confusing for readers: there are three distinct dereferences and increments of 'cp' in n_tty_receive_buf_standard. Do it on a single place, along with/before the 'fp' dereference. Signed-off-by:
-
Jiri Slaby authored
After the previous patch, noone cares about the return value of n_tty_receive_char_special. ldata->lnext is checked instead. So switch return type of n_tty_receive_char_special to void. Signed-off-by:
-
Jiri Slaby authored
Move lnext handling from __receive_buf to n_tty_receive_buf_standard. It simplifies the handling as it needs not fetching 'flag' and decrement 'count' in __receive_buf. Instead, all this is left up to the loop in n_tty_receive_buf_standard which already does that. This way, no need to repeat the action when n_tty_receive_char_special returns true -- ldata->lnext is set there in that case, so the 'if (ldata->lnext)' check is sufficient. The next patch will switch n_tty_receive_char_special to return 'void'. The result is much simplified code flow. Signed-off-by:
-
Jiri Slaby authored
After the previous cleanup patches, parmrk_dbl parameter is always true -- I_PARMRK is checked only in n_tty_receive_char now. So remove parmrk_dbl completely. Signed-off-by:
-
Jiri Slaby authored
After the previous patches, n_tty_receive_buf_standard and n_tty_receive_buf_fast differ only in handling of tty line and input controls. Unlike n_tty_receive_buf_fast, n_tty_receive_buf_standard handles them all (I_ISTRIP, I_IUCLC, L_IEXTEN, L_EXTPROC, and I_PARMRK). So remove n_tty_receive_buf_fast and let n_tty_receive_buf_standard do the handling. Actually most of the tests are only moved from __receive_buf to n_tty_receive_buf_standard. Again, the code duplication is not worth the theoretical speedup. Signed-off-by:
-
Jiri Slaby authored
n_tty_receive_char_fast is a copy of n_tty_receive_char with one exception: PARMRK is not doubled in the former. Unify these two and double PARMRK depending on a newly added parameter (bool parmrk_dbl). I don't think the theoretical speedup is worth the code duplication. Which is directly connected with maintenance burden. Signed-off-by:
-
Jiri Slaby authored
The wrapper was meant as an optimization in commits eb3e4668 (n_tty: Un-inline slow-path n_tty_receive_char()) and e60d27c4 (n_tty: Factor LNEXT processing from per-char i/o path). But the current compiler (gcc 10) inlines it anyway (as expected). Actually, I'm not sure it ever didn't. It would need to be marked with the noinline attribute. So remove this useless wrapper. And if we ever introduce something similar, we need confirming numbers first. Signed-off-by:
-
Jiri Slaby authored
Noone stepped up in the past two years since it was marked as BROKEN by commit c7084edc (tty: mark Siemens R3964 line discipline as BROKEN). Remove the line discipline for good. Three remarks: * we remove also the uapi header (as noone is able to use that interface anyway) * we do *not* remove the N_R3964 constant definition from tty.h, so it remains reserved. * in_interrupt() check is now removed from vt's con_put_char. Noone else calls tty_operations::put_char from interrupt context. Signed-off-by:
-
Dan Carpenter authored
This loop ends on -1 so the error message will never be printed. Fixes: 4bcf59a5 ("serial: 8250: 8250_omap: Account for data in flight during DMA teardown") Reviewed-by:
Alexander Sverdlin <alexander.sverdlin@gmail.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/YIpd+kOpXKMpEXPf@mwandaSigned-off-by:
-
Christophe JAILLET authored
This fixes the following checkpatch.pl warnings: WARNING: Missing a blank line after declarations WARNING: braces {} are not necessary for any arm of this statement Reviewed-by:Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/257ffd691b4a062ad017333c9430d69da6dbd29a.1619594713.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Christophe JAILLET authored
Use 'hlist_for_each_entry' instead of hand writing it. This saves a few lines of code. The comment about warning generated by some gcc version is also removed. The way 'hlist_for_each_entry' is written should prevent such a warning to be emitted. Reviewed-by:
-
Colin Ian King authored
The variable id being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Since id is just being used in a for-loop inside a local scope, move the declaration of id to that scope. Reviewed-by:
Kevin Hilman <khilman@baylibre.com> Reviewed-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
Colin Ian King <colin.king@canonical.com> Addresses-Coverity: ("Unused value") Link: https://lore.kernel.org/r/20210426101106.9122-1-colin.king@canonical.comSigned-off-by:
-
Jim Quinlan authored
Our SoC's have always had a NS16650A UART core and older SoC's would have a compatible string of: 'compatible = ""ns16550a"' and use the 8250_of driver. Our newer SoC's have added enhancements to the base core to add support for DMA and accurate high speed baud rates and use this newer 8250_bcm7271 driver. The Device Tree node for our enhanced UARTs has a compatible string of: 'compatible = "brcm,bcm7271-uart", "ns16550a"''. With both drivers running and the link order setup so that the 8250_bcm7217 driver is initialized before the 8250_of driver, we should bind the 8250_bcm7271 driver to the enhanced UART, or for upstream kernels that don't have the 8250_bcm7271 driver, we bind to the 8250_of driver. The problem is that when both the 8250_of and 8250_bcm7271 drivers were running, occasionally the 8250_of driver would be bound to the enhanced UART instead of the 8250_bcm7271 driver. This was happening because we use SCMI based clocks which come up late in initialization and cause probe DEFER's when the two drivers get their clocks. Occasionally the SCMI clock would become ready between the 8250_bcm7271 probe and the 8250_of probe and the 8250_of driver would be bound. To fix this we decided to config only our 8250_bcm7271 driver and added "ns16665a0" to the compatible string so the driver would work on our older system. This commit has of_platform_serial_probe() check specifically for the "brcm,bcm7271-uart" and whether its companion driver is enabled. If it is the case, and the clock provider is not ready, we want to make sure that when the 8250_bcm7271.c driver returns EPROBE_DEFER, we are not getting the UART registered via 8250_of.c. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Jim Quinlan <jim2101024@gmail.com> Signed-off-by:
Al Cooper <alcooperx@gmail.com> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20210423183206.3917725-1-f.fainelli@gmail.comSigned-off-by:
-
Colin Ian King authored
The variable line being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Reviewed-by:
Jiri Slaby <jirislaby@kernel.org> Signed-off-by:
-
Zhen Lei authored
When there is more than one serial port present, the property 'label' allows a custom name to be used for briefly describe the usage or position of each serial port. Without this "label" property, many dtbs_check warnings similar to the following are reported: arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dt.yaml: \ serial@ffd74000: Additional properties are not allowed ('label' was unexpected) From schema: Documentation/devicetree/bindings/serial/pl011.yaml Reviewed-by:Rob Herring <robh@kernel.org> Signed-off-by:
Zhen Lei <thunder.leizhen@huawei.com> Link: https://lore.kernel.org/r/20210506132049.1513-3-thunder.leizhen@huawei.comSigned-off-by:
-
Zhen Lei authored
The /schemas/serial.yaml from dt-schema only has the property $nodename, whereas the kernel-defined /schemas/serial/serial.yaml contains more useful properties, support for more complex application scenarios. For example: 1) The property "current-speed" in fsl-lx2160a.dtsi 2) The subnode "bluetooth" in hi3660-hikey960.dts Reviewed-by:
-
Zev Weiss authored
Previously this driver's use of devm_ioremap_resource() led to duplicated calls to __release_region() when unbinding it (one from serial8250_release_std_resource() and one from devres_release_all()), the second of which resulted in a warning message: # echo 1e787000.serial > /sys/bus/platform/drivers/aspeed-vuart/unbind [33091.774200] Trying to free nonexistent resource <000000001e787000-000000001e78703f> With this change the driver uses the generic serial8250 code's UPF_IOREMAP to take care of the register mapping automatically instead of doing its own devm_ioremap_resource(), thus avoiding the duplicate __release_region() on unbind. In doing this we eliminate vuart->regs, since it merely duplicates vuart->port->port.membase, which we now use for our I/O accesses. Reported-by:
Andrew Jeffery <andrew@aj.id.au> Signed-off-by:
Zev Weiss <zev@bewilderbeest.net> Link: https://lore.kernel.org/r/20210510014231.647-4-zev@bewilderbeest.netSigned-off-by:
-
Zev Weiss authored
Previously this had only been initialized if we hit the throttling path in aspeed_vuart_handle_irq(); moving it to the probe function is a slight consistency improvement and avoids redundant reinitialization in the interrupt handler. It also serves as preparation for converting the driver's I/O accesses to use port->port.membase instead of its own vuart->regs. Signed-off-by:
-
