- 13 May, 2021 34 commits
-
-
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 <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.czSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiri Slaby authored
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.czSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-10-jslaby@suse.czSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-9-jslaby@suse.czSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-8-jslaby@suse.czSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-7-jslaby@suse.czSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-6-jslaby@suse.czSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-5-jslaby@suse.czSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-4-jslaby@suse.czSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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 <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-3-jslaby@suse.czSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210505091928.22010-2-jslaby@suse.czSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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: 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.frSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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: Colin Ian King <colin.king@canonical.com> Addresses-Coverity: ("Unused value") Link: https://lore.kernel.org/r/20210423081317.318352-1-colin.king@canonical.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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: 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.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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: Zev Weiss <zev@bewilderbeest.net> Link: https://lore.kernel.org/r/20210510014231.647-3-zev@bewilderbeest.netSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Zev Weiss authored
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.netSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tian Tao authored
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.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michael Walle authored
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.ccSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michael Walle authored
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.ccSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michael Walle authored
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 2b30efe2 ("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.ccSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michael Walle authored
The wrong code in set_mctrl() was already removed in commit 2b30efe2 ("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: 2b30efe2 ("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.ccSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michael Walle authored
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.ccSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michael Walle authored
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.ccSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michael Walle authored
>From commit 75f4e830 ("serial: do not restore interrupt state in sysrq helper"): Since commit 81e2073c ("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.ccSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michael Walle authored
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.ccSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michael Walle authored
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: f4eef224 ("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.ccSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sherry Sun authored
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.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Liang Chen authored
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.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 09 May, 2021 6 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Commit b9d79e4c ("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>
-
git://anongit.freedesktop.org/drm/drmLinus Torvalds authored
Pull drm fixes from Dave Airlie: "Bit later than usual, I queued them all up on Friday then promptly forgot to write the pull request email. This is mainly amdgpu fixes, with some radeon/msm/fbdev and one i915 gvt fix thrown in. amdgpu: - MPO hang workaround - Fix for concurrent VM flushes on vega/navi - dcefclk is not adjustable on navi1x and newer - MST HPD debugfs fix - Suspend/resumes fixes - Register VGA clients late in case driver fails to load - Fix GEM leak in user framebuffer create - Add support for polaris12 with 32 bit memory interface - Fix duplicate cursor issue when using overlay - Fix corruption with tiled surfaces on VCN3 - Add BO size and stride check to fix BO size verification radeon: - Fix off-by-one in power state parsing - Fix possible memory leak in power state parsing msm: - NULL ptr dereference fix fbdev: - procfs disabled warning fix i915: - gvt: Fix a possible division by zero in vgpu display rate calculation" * tag 'drm-next-2021-05-10' of git://anongit.freedesktop.org/drm/drm: drm/amdgpu: Use device specific BO size & stride check. drm/amdgpu: Init GFX10_ADDR_CONFIG for VCN v3 in DPG mode. drm/amd/pm: initialize variable drm/radeon: Avoid power table parsing memory leaks drm/radeon: Fix off-by-one power_state index heap overwrite drm/amd/display: Fix two cursor duplication when using overlay drm/amdgpu: add new MC firmware for Polaris12 32bit ASIC fbmem: Mark proc_fb_seq_ops as __maybe_unused drm/msm/dpu: Delete bonkers code drm/i915/gvt: Prevent divided by zero when calculating refresh rate amdgpu: fix GEM obj leak in amdgpu_display_user_framebuffer_create drm/amdgpu: Register VGA clients after init can no longer fail drm/amdgpu: Handling of amdgpu_device_resume return value for graceful teardown drm/amdgpu: fix r initial values drm/amd/display: fix wrong statement in mst hpd debugfs amdgpu/pm: set pp_dpm_dcefclk to readonly on NAVI10 and newer gpus amdgpu/pm: Prevent force of DCEFCLK on NAVI10 and SIENNA_CICHLID drm/amdgpu: fix concurrent VM flushes on Vega/Navi v2 drm/amd/display: Reject non-zero src_y and src_x for video planes
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull block fix from Jens Axboe: "Turns out the bio max size change still has issues, so let's get it reverted for 5.13-rc1. We'll shake out the issues there and defer it to 5.14 instead" * tag 'block-5.13-2021-05-09' of git://git.kernel.dk/linux-block: Revert "bio: limit bio max size"
-
git://git.samba.org/sfrench/cifs-2.6Linus Torvalds authored
Pull cifs fixes from Steve French: "Three small SMB3 chmultichannel related changesets (also for stable) from the SMB3 test event this week. The other fixes are still in review/testing" * tag '5.13-rc-smb3-part3' of git://git.samba.org/sfrench/cifs-2.6: smb3: if max_channels set to more than one channel request multichannel smb3: do not attempt multichannel to server which does not support it smb3: when mounting with multichannel include it in requested capabilities
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull scheduler fixes from Thomas Gleixner: "A set of scheduler updates: - Prevent PSI state corruption when schedule() races with cgroup move. A recent commit combined two PSI callbacks to reduce the number of cgroup tree updates, but missed that schedule() can drop rq::lock for load balancing, which opens the race window for cgroup_move_task() which then observes half updated state. The fix is to solely use task::ps_flags instead of looking at the potentially mismatching scheduler state - Prevent an out-of-bounds access in uclamp caused bu a rounding division which can lead to an off-by-one error exceeding the buckets array size. - Prevent unfairness caused by missing load decay when a task is attached to a cfs runqueue. The old load of the task was attached to the runqueue and never removed. Fix it by enforcing the load update through the hierarchy for unthrottled run queue instances. - A documentation fix fot the 'sched_verbose' command line option" * tag 'sched-urgent-2021-05-09' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/fair: Fix unfairness caused by missing load decay sched: Fix out-of-bound access in uclamp psi: Fix psi state corruption when schedule() races with cgroup move sched,doc: sched_debug_verbose cmdline should be sched_verbose
-