aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/wireguard (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2021-05-13n_gsm: use goto-failpaths in gsm_initJiri Slaby1-5/+9
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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-16-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13tty: set tty_ldisc_ops::num staticallyJiri Slaby20-23/+41
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 <jslaby@suse.cz> Cc: William Hubbs <w.d.hubbs@gmail.com> Cc: Chris Brannon <chris@the-brannons.com> Cc: Kirk Reiser <kirk@reisers.ca> Cc: Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Wolfgang Grandegger <wg@grandegger.com> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: Andreas Koensgen <ajk@comnets.uni-bremen.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Rodolfo Giometti <giometti@enneenne.com> Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Link: https://lore.kernel.org/r/20210505091928.22010-15-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13tty: cumulate and document tty_struct::ctrl* membersJiri Slaby7-122/+130
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 c545b66c6922b (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 <jslaby@suse.cz> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: netdev@vger.kernel.org Link: https://lore.kernel.org/r/20210505091928.22010-14-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13tty: cumulate and document tty_struct::flow* membersJiri Slaby22-77/+83
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 c545b66c6922b (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 <jslaby@suse.cz> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: "Maciej W. Rozycki" <macro@orcam.me.uk> Link: https://lore.kernel.org/r/20210505091928.22010-13-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13tty: make fp of tty_ldisc_ops::receive_buf{,2} constJiri Slaby21-36/+39
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 <jslaby@suse.cz> Cc: William Hubbs <w.d.hubbs@gmail.com> Cc: Chris Brannon <chris@the-brannons.com> Cc: Kirk Reiser <kirk@reisers.ca> Cc: Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Wolfgang Grandegger <wg@grandegger.com> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: Andreas Koensgen <ajk@comnets.uni-bremen.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com> Link: https://lore.kernel.org/r/20210505091928.22010-12-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13n_tty: remove superfluous return from n_tty_receive_signal_charJiri Slaby1-1/+0
A return at the end of a void-returning function is superfluous. Get rid of it. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-11-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13n_tty: invert TTY_NORMAL condition in n_tty_receive_buf_standardJiri Slaby1-14/+17
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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-10-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13n_tty: do only one cp dereference in n_tty_receive_buf_standardJiri Slaby1-4/+4
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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-9-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13n_tty: make n_tty_receive_char_special return voidJiri Slaby1-16/+11
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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-8-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13n_tty: move lnext handlingJiri Slaby1-15/+8
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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-7-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13n_tty: drop parmrk_dbl from n_tty_receive_charJiri Slaby1-5/+4
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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-6-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13n_tty: drop n_tty_receive_buf_fastJiri Slaby1-33/+3
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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-5-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13n_tty: remove n_tty_receive_char_fastJiri Slaby1-26/+6
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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-4-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13n_tty: remove n_tty_receive_char wrapperJiri Slaby1-7/+2
The wrapper was meant as an optimization in commits eb3e4668bd9e (n_tty: Un-inline slow-path n_tty_receive_char()) and e60d27c4d8b3 (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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-3-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13tty: remove broken r3964 line disciplineJiri Slaby7-1574/+0
Noone stepped up in the past two years since it was marked as BROKEN by commit c7084edc3f6d (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: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-2-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: 8250_omap: fix a timeout loop conditionDan Carpenter1-1/+1
This loop ends on -1 so the error message will never be printed. Fixes: 4bcf59a5dea0 ("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@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: 8250: Add an empty line and remove some useless {}Christophe JAILLET1-2/+3
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.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: 8250: Use 'hlist_for_each_entry' to simplify codeChristophe JAILLET1-14/+4
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/14024ddeb2b3a8c5b0138b5ba5083f54d00164a9.1619594713.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: meson: remove redundant initialization of variable idColin Ian King1-1/+2
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.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: 8250: of: Check for CONFIG_SERIAL_8250_BCM7271Jim Quinlan1-0/+4
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.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: qcom_geni_serial: redundant initialization to variable lineColin Ian King1-1/+1
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: Colin Ian King <colin.king@canonical.com> Addresses-Coverity: ("Unused value") Link: https://lore.kernel.org/r/20210423081317.318352-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13dt-bindings: serial: Add label property in serial.yamlZhen Lei1-0/+2
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.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13dt-bindings: serial: Change to reference the kernel-defined serial.yamlZhen Lei10-14/+13
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: Rob Herring <robh@kernel.org> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Link: https://lore.kernel.org/r/20210506132049.1513-2-thunder.leizhen@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: 8250_aspeed_vuart: use UPF_IOREMAP to set up register mappingZev Weiss1-8/+3
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.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: 8250_aspeed_vuart: initialize vuart->port in aspeed_vuart_probe()Zev Weiss1-3/+2
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: Zev Weiss <zev@bewilderbeest.net> Link: https://lore.kernel.org/r/20210510014231.647-3-zev@bewilderbeest.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: 8250_aspeed_vuart: factor out aspeed_vuart_{read, write}b() helper functionsZev Weiss1-14/+24
This is a small prepatory step for changing the way this driver does its I/O accesses. Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Zev Weiss <zev@bewilderbeest.net> Link: https://lore.kernel.org/r/20210510014231.647-2-zev@bewilderbeest.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13tty: serial: samsung_tty: remove set but not used variablesTian Tao1-2/+1
The value of 'ret' is not used which reported by svace, so just return instead of break. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Link: https://lore.kernel.org/r/1619484575-26098-1-git-send-email-tiantao6@hisilicon.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: fsl_lpuart: disable DMA for console and fix sysrqMichael Walle1-0/+6
SYSRQ doesn't work with DMA. This is because there is no error indication whether a symbol had a framing error or not. Actually, this is not completely correct, there is a bit in the data register which is set in this case, but we'd have to read change the DMA access to 16 bit and we'd need to post process the data, thus make the DMA pointless in the first place. Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20210512141255.18277-10-michael@walle.cc Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: fsl_lpuart: add loopback supportMichael Walle1-2/+34
The LPUART can loop the RX and TX signal. Add support for it. Please note, this was only tested on the 32 bit version of the LPUART. Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20210512141255.18277-9-michael@walle.cc Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: fsl_lpuart: remove manual RTSCTS control from 8-bit LPUARTMichael Walle1-27/+1
The LPUART doesn't have the ability to control the RTS or CTS line manually. Instead it will set it automatically when data is send or handle it when data is received. Thus drop the wrong code in set_mctrl. For the 32 bit version this was already done in the commit 2b30efe2e88a ("tty: serial: lpuart: Remove unnecessary code from set_mctrl"). Keep the 8-bit version in sync and remove it there, too. Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20210512141255.18277-8-michael@walle.cc Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: fsl_lpuart: remove RTSCTS handling from get_mctrl()Michael Walle1-11/+1
The wrong code in set_mctrl() was already removed in commit 2b30efe2e88a ("tty: serial: lpuart: Remove unnecessary code from set_mctrl"), but the code in get_mctrl() wasn't removed. It will not return the state of the RTS or CTS line but whether automatic flow control is enabled, which is wrong for the get_mctrl(). Thus remove it. Fixes: 2b30efe2e88a ("tty: serial: lpuart: Remove unnecessary code from set_mctrl") Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20210512141255.18277-7-michael@walle.cc Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: fsl_lpuart: handle break and make sysrq workMichael Walle1-8/+24
Although there is already sysrq characters handling, a break condition was never detected. Add support for it. The LPUART can't distinguish between a framing error and a break condition. We assume it is a break if the received data is all zero. Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20210512141255.18277-6-michael@walle.cc Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: fsl_lpuart: split sysrq handlingMichael Walle1-6/+6
Instead of uart_handle_sysrq_char() use uart_prepare_sysrq_char() and uart_unlock_and_check_sysrq(). This will call handle_sysrq() without holding the port lock, which in turn let us drop the spin_trylock hack. Suggested-by: Johan Hovold <johan@kernel.org> Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20210512141255.18277-5-michael@walle.cc Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: fsl_lpuart: don't restore interrupt state in ISRMichael Walle1-14/+8
>From commit 75f4e830fa9c ("serial: do not restore interrupt state in sysrq helper"): Since commit 81e2073c175b ("genirq: Disable interrupts for force threaded handlers") interrupt handlers that are not explicitly requested as threaded are always called with interrupts disabled and there is no need to save the interrupt state when taking the port lock. Apply this also to fsl_lpuart in prepartion for sysrq handling with uart_unlock_and_check_sysrq(). Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20210512141255.18277-4-michael@walle.cc Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: fsl_lpuart: use UARTDATA_MASK macroMichael Walle1-2/+2
Use the corresponding macro instead of the magic number. While at it, drop the useless cast to "unsigned char". Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20210512141255.18277-3-michael@walle.cc Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: fsl_lpuart: don't modify arbitrary data on lpuart32Michael Walle1-1/+1
lpuart_rx_dma_startup() is used for both the 8 bit and the 32 bit version of the LPUART. Modify the UARTCR only for the 8 bit version. Fixes: f4eef224a09f ("serial: fsl_lpuart: add sysrq support when using dma") Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20210512141255.18277-2-michael@walle.cc Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13tty: serial: fsl_lpuart: fix the potential risk of division or modulo by zeroSherry Sun1-0/+3
We should be very careful about the register values that will be used for division or modulo operations, althrough the possibility that the UARTBAUD register value is zero is very low, but we had better to deal with the "bad data" of hardware in advance to avoid division or modulo by zero leading to undefined kernel behavior. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Link: https://lore.kernel.org/r/20210427021226.27468-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13dt-bindings: serial: snps-dw-apb-uart: add description for rk3568Liang Chen1-0/+1
add "rockchip,rk3568-uart", "snps,dw-apb-uart" for uart nodes on a rk3568 platform to snps-dw-apb-uart.yaml. Signed-off-by: Liang Chen <cl@rock-chips.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210429081151.17558-3-cl@rock-chips.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-09Linux 5.13-rc1Linus Torvalds1-2/+2
2021-05-09fbmem: fix horribly incorrect placement of __maybe_unusedLinus Torvalds1-1/+1
Commit b9d79e4ca4ff ("fbmem: Mark proc_fb_seq_ops as __maybe_unused") places the '__maybe_unused' in an entirely incorrect location between the "struct" keyword and the structure name. It's a wonder that gcc accepts that silently, but clang quite reasonably warns about it: drivers/video/fbdev/core/fbmem.c:736:21: warning: attribute declaration must precede definition [-Wignored-attributes] static const struct __maybe_unused seq_operations proc_fb_seq_ops = { ^ Fix it. Cc: Guenter Roeck <linux@roeck-us.net> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-05-08Revert "bio: limit bio max size"Jens Axboe4-21/+3
This reverts commit cd2c7545ae1beac3b6aae033c7f31193b3255946. Alex reports that the commit causes corruption with LUKS on ext4. Revert it for now so that this can be investigated properly. Link: https://lore.kernel.org/linux-block/1620493841.bxdq8r5haw.none@localhost/ Reported-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-05-08drm/i915/display: fix compiler warning about array overrunLinus Torvalds1-1/+12
intel_dp_check_mst_status() uses a 14-byte array to read the DPRX Event Status Indicator data, but then passes that buffer at offset 10 off as an argument to drm_dp_channel_eq_ok(). End result: there are only 4 bytes remaining of the buffer, yet drm_dp_channel_eq_ok() wants a 6-byte buffer. gcc-11 correctly warns about this case: drivers/gpu/drm/i915/display/intel_dp.c: In function ‘intel_dp_check_mst_status’: drivers/gpu/drm/i915/display/intel_dp.c:3491:22: warning: ‘drm_dp_channel_eq_ok’ reading 6 bytes from a region of size 4 [-Wstringop-overread] 3491 | !drm_dp_channel_eq_ok(&esi[10], intel_dp->lane_count)) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/display/intel_dp.c:3491:22: note: referencing argument 1 of type ‘const u8 *’ {aka ‘const unsigned char *’} In file included from drivers/gpu/drm/i915/display/intel_dp.c:38: include/drm/drm_dp_helper.h:1466:6: note: in a call to function ‘drm_dp_channel_eq_ok’ 1466 | bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE], | ^~~~~~~~~~~~~~~~~~~~ 6:14 elapsed This commit just extends the original array by 2 zero-initialized bytes, avoiding the warning. There may be some underlying bug in here that caused this confusion, but this is at least no worse than the existing situation that could use random data off the stack. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-05-08smb3: if max_channels set to more than one channel request multichannelSteve French1-0/+3
Mounting with "multichannel" is obviously implied if user requested more than one channel on mount (ie mount parm max_channels>1). Currently both have to be specified. Fix that so that if max_channels is greater than 1 on mount, enable multichannel rather than silently falling back to non-multichannel. Signed-off-by: Steve French <stfrench@microsoft.com> Reviewed-By: Tom Talpey <tom@talpey.com> Cc: <stable@vger.kernel.org> # v5.11+ Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
2021-05-08smb3: do not attempt multichannel to server which does not support itSteve French1-0/+6
We were ignoring CAP_MULTI_CHANNEL in the server response - if the server doesn't support multichannel we should not be attempting it. See MS-SMB2 section 3.2.5.2 Reviewed-by: Shyam Prasad N <sprasad@microsoft.com> Reviewed-By: Tom Talpey <tom@talpey.com> Cc: <stable@vger.kernel.org> # v5.8+ Signed-off-by: Steve French <stfrench@microsoft.com>
2021-05-08smb3: when mounting with multichannel include it in requested capabilitiesSteve French1-0/+5
In the SMB3/SMB3.1.1 negotiate protocol request, we are supposed to advertise CAP_MULTICHANNEL capability when establishing multiple channels has been requested by the user doing the mount. See MS-SMB2 sections 2.2.3 and 3.2.5.2 Without setting it there is some risk that multichannel could fail if the server interpreted the field strictly. Reviewed-By: Tom Talpey <tom@talpey.com> Reviewed-by: Shyam Prasad N <sprasad@microsoft.com> Cc: <stable@vger.kernel.org> # v5.8+ Signed-off-by: Steve French <stfrench@microsoft.com>
2021-05-09linux/kconfig.h: replace IF_ENABLED() with PTR_IF() in <linux/kernel.h>Masahiro Yamada3-6/+5
<linux/kconfig.h> is included from all the kernel-space source files, including C, assembly, linker scripts. It is intended to contain a minimal set of macros to evaluate CONFIG options. IF_ENABLED() is an intruder here because (x ? y : z) is C code, which should not be included from assembly files or linker scripts. Also, <linux/kconfig.h> is no longer self-contained because NULL is defined in <linux/stddef.h>. Move IF_ENABLED() out to <linux/kernel.h> as PTR_IF(). PTF_IF() takes the general boolean expression instead of a CONFIG option so that it fits better in <linux/kernel.h>. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org>
2021-05-07atm: firestream: Use fallthrough pseudo-keywordWei Ming Chen1-0/+1
Add pseudo-keyword macro fallthrough[1] [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Wei Ming Chen <jj251510319013@gmail.com> Link: https://lore.kernel.org/r/20210507123843.10602-1-jj251510319013@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-05-07net: stmmac: Do not enable RX FIFO overflow interruptsYannick Vignon2-18/+3
The RX FIFO overflows when the system is not able to process all received packets and they start accumulating (first in the DMA queue in memory, then in the FIFO). An interrupt is then raised for each overflowing packet and handled in stmmac_interrupt(). This is counter-productive, since it brings the system (or more likely, one CPU core) to its knees to process the FIFO overflow interrupts. stmmac_interrupt() handles overflow interrupts by writing the rx tail ptr into the corresponding hardware register (according to the MAC spec, this has the effect of restarting the MAC DMA). However, without freeing any rx descriptors, the DMA stops right away, and another overflow interrupt is raised as the FIFO overflows again. Since the DMA is already restarted at the end of stmmac_rx_refill() after freeing descriptors, disabling FIFO overflow interrupts and the corresponding handling code has no side effect, and eliminates the interrupt storm when the RX FIFO overflows. Signed-off-by: Yannick Vignon <yannick.vignon@nxp.com> Link: https://lore.kernel.org/r/20210506143312.20784-1-yannick.vignon@oss.nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-05-07mptcp: fix splat when closing unaccepted socketPaolo Abeni1-2/+1
If userspace exits before calling accept() on a listener that had at least one new connection ready, we get: Attempt to release TCP socket in state 8 This happens because the mptcp socket gets cloned when the TCP connection is ready, but the socket is never exposed to userspace. The client additionally sends a DATA_FIN, which brings connection into CLOSE_WAIT state. This in turn prevents the orphan+state reset fixup in mptcp_sock_destruct() from doing its job. Fixes: 3721b9b64676b ("mptcp: Track received DATA_FIN sequence number and add related helpers") Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/185 Tested-by: Florian Westphal <fw@strlen.de> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Link: https://lore.kernel.org/r/20210507001638.225468-1-mathew.j.martineau@linux.intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-05-07i40e: Remove LLDP frame filtersArkadiusz Kubalewski3-44/+0
Remove filters from being setup in case of software DCB and allow the LLDP frames to be properly transmitted to the wire. It is not possible to transmit the LLDP frame out of the port, if they are filtered by control VSI. This prohibits software LLDP agent properly communicate its DCB capabilities to the neighbors. Fixes: 4b208eaa8078 ("i40e: Add init and default config of software based DCB") Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Tested-by: Imam Hassan Reza Biswas <imam.hassan.reza.biswas@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.