- 12 Feb, 2019 40 commits
-
-
Nicholas Mc Guire authored
[ Upstream commit aad172b0 ] devm_kasprintf() may return NULL on failure of internal allocation thus the assignments to init.name are not safe if not checked. On error meson_sar_adc_clk_init() returns negative values so -ENOMEM in the (unlikely) failure case of devm_kasprintf() should be fine here. Signed-off-by:
Nicholas Mc Guire <hofrat@osadl.org> Fixes: 3adbf342 ("iio: adc: add a driver for the SAR ADC found in Amlogic Meson SoCs") Acked-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Tested-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Mathieu Malaterre authored
[ Upstream commit beba24ac ] When both `CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y` and `CONFIG_UBSAN=y` are set, link step typically produce numberous warnings about orphan section: + powerpc-linux-gnu-ld -EB -m elf32ppc -Bstatic --orphan-handling=warn --build-id --gc-sections -X -o .tmp_vmlinux1 -T ./arch/powerpc/kernel/vmlinux.lds --who le-archive built-in.a --no-whole-archive --start-group lib/lib.a --end-group powerpc-linux-gnu-ld: warning: orphan section `.data..Lubsan_data393' from `init/main.o' being placed in section `.data..Lubsan_data393'. powerpc-linux-gnu-ld: warning: orphan section `.data..Lubsan_data394' from `init/main.o' being placed in section `.data..Lubsan_data394'. ... powerpc-linux-gnu-ld: warning: orphan section `.data..Lubsan_type11' from `init/main.o' being placed in section `.data..Lubsan_type11'. powerpc-linux-gnu-ld: warning: orphan section `.data..Lubsan_type12' from `init/main.o' being placed in section `.data..Lubsan_type12'. ... This commit remove those warnings produced at W=1. Link: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg135407.htmlSuggested-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
Mathieu Malaterre <malat@debian.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit aeaebcc1 ] Clang warns: drivers/dma/xilinx/zynqmp_dma.c:166:4: warning: attribute 'aligned' is ignored, place it after "struct" to apply attribute to type declaration [-Wignored-attributes] }; __aligned(64) ^ ./include/linux/compiler_types.h:200:38: note: expanded from macro '__aligned' ^ 1 warning generated. As Nick pointed out in the previous version of this patch, the author likely intended for this struct to be 8-byte (64-bit) aligned, not 64-byte, which is the default. Remove the hanging __aligned attribute. Fixes: b0cc417c ("dmaengine: Add Xilinx zynqmp dma engine driver support") Reported-by:
Nick Desaulniers <ndesaulniers@google.com> Suggested-by:
Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
YueHaibing authored
[ Upstream commit aea0a897 ] Fix smatch warning: drivers/ptp/ptp_clock.c:298 ptp_clock_register() warn: passing zero to 'ERR_PTR' 'err' should be set while device_create_with_groups and pps_register_source fails Fixes: 85a66e55 ("ptp: create "pins" together with the rest of attributes") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Martin Blumenstingl authored
[ Upstream commit 0dad1ec6 ] We don't want the common clock framework to disable the "cpu_clk" if it's not used by any device. The cpufreq-dt driver does not enable the CPU clocks. However, even if it would we would still want the CPU clock to be enabled at all times because the CPU clock is also required even if we disable CPU frequency scaling on a specific board. The reason why we want the CPU clock to be enabled is a clock further up in the tree: Since commit 6f888e7bc7bd58 ("clk: meson: clk-pll: add enable bit") the sys_pll can be disabled. However, since the CPU clock is derived from sys_pll we don't want sys_pll to get disabled. The common clock framework takes care of that for us by enabling all parent clocks of our CPU clock when we mark the CPU clock with CLK_IS_CRITICAL. Until now this is not a problem yet because all clocks in the CPU clock's tree (including sys_pll) are read-only. However, once we allow modifications to the clocks in that tree we will need this. Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20181115224048.13511-4-martin.blumenstingl@googlemail.comSigned-off-by:
-
Martin Blumenstingl authored
[ Upstream commit a8662ead ] According to the public S805 datasheet HHI_SYS_CPU_CLK_CNTL1[29:20] is the register for the CPU scale_div clock. This matches the code in Amlogic's 3.10 GPL kernel sources: N = (aml_read_reg32(P_HHI_SYS_CPU_CLK_CNTL1) >> 20) & 0x3FF; This means that the divider register is 10 bit wide instead of 9 bits. So far this is not a problem since all u-boot versions I have seen are not using the cpu_scale_div clock at all (instead they are configuring the CPU clock to run off cpu_in_sel directly). The fixes tag points to the latest rework of the CPU clocks. However, even before the rework it was wrong. Commit 7a29a869 ("clk: meson: Add support for Meson clock controller") defines MESON_N_WIDTH as 9 (in drivers/clk/meson/clk-cpu.c). But since the old clk-cpu implementation this only carries the fixes tag for the CPU clock rewordk. Fixes: 251b6fd3 ("clk: meson: rework meson8b cpu clock") Signed-off-by:
-
Martin Blumenstingl authored
[ Upstream commit a5ac1ead ] The cpu_div3 clock (cpu_in divided by 3) generates a signal with a duty cycle of 33%. The CPU clock however requires a clock signal with a duty cycle of 50% to run stable. cpu_div3 was observed to be problematic when cycling through all available CPU frequencies (with additional patches on top of this one) while running "stress --cpu 4" in the background. This caused sporadic hangs where the whole system would fully lock up. Amlogic's 3.10 kernel code also does not use the cpu_div3 clock either when changing the CPU clock. Signed-off-by:
-
Gao Xiang authored
[ Upstream commit eef16878 ] It's better not to positively BUG_ON the kernel, however developers need a way to locate issues as soon as possible. DBG_BUGON is introduced and it could only crash when EROFS_FS_DEBUG (EROFS developping feature) is on. It is helpful for developers to find and solve bugs quickly by eng builds. Previously, DBG_BUGON is defined as ((void)0) if EROFS_FS_DEBUG is off, but some unused variable warnings as follows could occur: drivers/staging/erofs/unzip_vle.c: In function `init_alway:': drivers/staging/erofs/unzip_vle.c:61:33: warning: unused variable `work' [-Wunused-variable] struct z_erofs_vle_work *const work = ^~~~ Fix it to #define DBG_BUGON(x) ((void)(x)). Reviewed-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Gao Xiang <gaoxiang25@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Alexey Khoroshilov authored
[ Upstream commit 8ea0f2ba ] of_parse_phandle() returns the device node with refcount incremented. There are two nodes that are used temporary in mtk_vcodec_init_enc_pm(), but their refcounts are not decremented. The patch adds one of_node_put() and fixes returning error codes. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Akinobu Mita authored
[ Upstream commit c764da98 ] The video device release() callback for video-i2c driver frees the whole struct video_i2c_data. If there is no user left for the video device when video_unregister_device() is called, the release callback is executed. However, in video_i2c_remove() some fields (v4l2_dev, lock, and queue_lock) in struct video_i2c_data are still accessed after video_unregister_device() is called. This fixes the use after free by moving the code from video_i2c_remove() to the release() callback. Fixes: 5cebaac6 ("media: video-i2c: add video-i2c driver") Reviewed-by:
Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Sean Young authored
[ Upstream commit 8e782fcf ] If userspace has an open file descriptor on the rc input device or lirc device when rc_unregister_device() is called, then the rc close() is never called. This ensures that the receiver is turned off on the nuvoton-cir driver during shutdown. Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Yangtao Li authored
[ Upstream commit 9eb40fa2 ] of_find_node_by_path() acquires a reference to the node returned by it and that reference needs to be dropped by its caller. soc_is_tegra() doesn't do that, so fix it. Signed-off-by:
Yangtao Li <tiny.windzz@gmail.com> Acked-by:
Jon Hunter <jonathanh@nvidia.com> [treding: slightly rewrite to avoid inline comparison] Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Pu Wen authored
[ Upstream commit 4787eff3 ] The tool perf is useful for the performance analysis on the Hygon Dhyana platform. But right now there is no Hygon support for it to analyze the KVM guest os data. So add Hygon Dhyana support to it by checking vendor string to share the code path of AMD. Signed-off-by:
Pu Wen <puwen@hygon.cn> Acked-by:
Borislav Petkov <bp@suse.de> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1542008451-31735-1-git-send-email-puwen@hygon.cnSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Sami Tolvanen authored
[ Upstream commit 5818c683 ] If an ARM mapping symbol shares an address with a valid symbol, find_elf_symbol can currently return the mapping symbol instead, as the symbol is not validated. This can result in confusing warnings: WARNING: vmlinux.o(.text+0x18f4028): Section mismatch in reference from the function set_reset_devices() to the variable .init.text:$x.0 This change adds a call to is_valid_name to find_elf_symbol, similarly to how it's already used in find_elf_symbol2. Signed-off-by:
Sami Tolvanen <samitolvanen@google.com> Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Saeed Mahameed authored
[ Upstream commit 1e86ace4 ] Currently the cpu affinity hint mask for completion EQs is stored and read from the wrong place, since reading and storing is done from the same index, there is no actual issue with that, but internal irq_info for completion EQs stars at MLX5_EQ_VEC_COMP_BASE offset in irq_info array, this patch changes the code to use the correct offset to store and read the IRQ affinity hint. Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Reviewed-by:
Leon Romanovsky <leonro@mellanox.com> Reviewed-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
Stanislav Fomichev authored
[ Upstream commit 23499442 ] Since commit 88cda1c9 ("bpf: libbpf: Provide basic API support to specify BPF obj name"), libbpf unconditionally sets bpf_attr->name for maps. Pre v4.14 kernels don't know about map names and return an error about unexpected non-zero data. Retry sys_bpf without a map name to cover older kernels. v2 changes: * check for errno == EINVAL as suggested by Daniel Borkmann Signed-off-by:
Stanislav Fomichev <sdf@google.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Yogesh Mohan Marimuthu authored
[ Upstream commit 08e1c28d ] [why] phy_pix_clk is one of the variable used to check if one PLL can be shared with displays having common mode set configuration. As of now phy_pix_clock varialbe is calculated in function dc_validate_stream(). dc_validate_stream() function is called after clocks are assigned for the new display. Due to this during hotplug, when PLL sharing conditions are checked for new display phy_pix_clk variable will be 0 and for displays that are already enabled phy_pix_clk will have some value. Hence PLL will not be shared and if the display hardware doesn't have any more PLL to assign, mode set will fail due to resource unavailability. [how] Instead of only calculating the phy_pix_clk variable after the PLL is assigned for new display, this patch calculates phy_pix_clk also during the before assigning the PLL for new display. Signed-off-by:
Yogesh Mohan Marimuthu <yogesh.mohanmarimuthu@amd.com> Reviewed-by:
Harry Wentland <Harry.Wentland@amd.com> Acked-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Murton Liu authored
[ Upstream commit 8ce504b9 ] [why] Gamma was always being set as identity on SDR monitor, leading to no changes in gamma. This caused nightlight to not apply correctly. [how] Added a default gamma structure to compare against in the sdr case. Signed-off-by:
Murton Liu <murton.liu@amd.com> Reviewed-by:
Krunoslav Kovac <Krunoslav.Kovac@amd.com> Acked-by:
-
Nathan Chancellor authored
[ Upstream commit c10b26ab ] When building the kernel with Clang, the following section mismatch warnings appears: WARNING: vmlinux.o(.text+0x2d398): Section mismatch in reference from the function _setup() to the function .init.text:_setup_iclk_autoidle() The function _setup() references the function __init _setup_iclk_autoidle(). This is often because _setup lacks a __init annotation or the annotation of _setup_iclk_autoidle is wrong. WARNING: vmlinux.o(.text+0x2d3a0): Section mismatch in reference from the function _setup() to the function .init.text:_setup_reset() The function _setup() references the function __init _setup_reset(). This is often because _setup lacks a __init annotation or the annotation of _setup_reset is wrong. WARNING: vmlinux.o(.text+0x2d408): Section mismatch in reference from the function _setup() to the function .init.text:_setup_postsetup() The function _setup() references the function __init _setup_postsetup(). This is often because _setup lacks a __init annotation or the annotation of _setup_postsetup is wrong. _setup is used in omap_hwmod_allocate_module, which isn't marked __init and looks like it shouldn't be, meaning to fix these warnings, those functions must be moved out of the init section, which this patch does. Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Damian Kos authored
[ Upstream commit fa68d4f8 ] Some of the functions (like cdn_dp_dpcd_read, cdn_dp_get_edid_block) allow to read 64KiB, but the cdn_dp_mailbox_read_receive, that is used by them, can read only up to 255 bytes at once. Normally, it's not a big issue as DPCD or EDID reads won't (hopefully) exceed that value. The real issue here is the revocation list read during the HDCP authentication process. (problematic use case: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/gpu/drm/rockchip/cdn-dp-reg.c#1152) The list can reach 127*5+4 bytes (num devs * 5 bytes per ID/Bksv + 4 bytes of an additional info). In other words - CTSes with HDCP Repeater won't pass without this fix. Oh, and the driver will most likely stop working (best case scenario). Signed-off-by:
Damian Kos <dkos@cadence.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/1541518625-25984-1-git-send-email-dkos@cadence.comSigned-off-by:
-
Ben Dooks authored
[ Upstream commit 810eeb1f ] The smsc95xx driver already takes into account the NET_IP_ALIGN parameter when setting up the receive packet data, which means we do not need to worry about aligning the packets in the usbnet driver. Adding the EVENT_NO_IP_ALIGN means that the IPv4 header is now passed to the ip_rcv() routine with the start on an aligned address. Tested on Raspberry Pi B3. Signed-off-by:
Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by:
-
Renato Lui Geh authored
[ Upstream commit 336650c7 ] The ad7780 driver previously did not read the correct device output, as it read an outdated value set at initialization. It now updates its voltage on read. Signed-off-by:
Renato Lui Geh <renatogeh@gmail.com> Acked-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by:
-
Xiang Chen authored
[ Upstream commit 15bc43f3 ] Currently the time of SAS SSP connection is 1ms, which means the link connection will fail if no IO response after this period. For some disks handling large IO (such as 512k), 1ms is not enough, so change it to 5ms. Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Alan Brady authored
[ Upstream commit d5585b7b ] If a TX hang occurs, we attempt to recover by incrementally resetting. If we're starved for CPU time, it's possible the reset doesn't actually complete (or even fire) before another tx_timeout fires causing us to fly through the different resets without actually doing them. This adds a bit to set and check if a timeout recovery is already pending and, if so, bail out of tx_timeout. The bit will get cleared at the end of i40e_rebuild when reset is complete. Signed-off-by:
Alan Brady <alan.brady@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Brian Norris authored
[ Upstream commit 6ad16b78 ] EC_MKBP_EVENT_SENSOR_FIFO events can be triggered for a variety of reasons, and there are very few cases in which they should be treated as wakeup interrupts (particularly, when a certain MOTIONSENSE_MODULE_FLAG_* is set, but this is not even supported in the mainline cros_ec_sensor driver yet). Most of the time, they are benign sensor readings. In any case, the top-level cros_ec device doesn't know enough to determine that they should wake the system, and so it should not report the event. This would be the job of the cros_ec_sensors driver to parse. This patch adds checks to cros_ec_get_next_event() such that it doesn't signal 'wakeup' for events of type EC_MKBP_EVENT_SENSOR_FIFO. This patch is particularly relevant on devices like Scarlet (Rockchip RK3399 tablet, known as Acer Chromebook Tab 10), where the EC firmware reports sensor events much more frequently. This was causing /sys/power/wakeup_count to increase very frequently, often needlessly interrupting our ability to suspend the system. Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Benson Leung <bleung@chromium.org> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit b8ae30a7 ] With the new CONFIG_CC_OPTIMIZE_FOR_DEBUGGING option, we get a link error in the vboxguest driver, when that fails to optimize out the call to the compat handler: drivers/virt/vboxguest/vboxguest_core.o: In function `vbg_ioctl_hgcm_call': vboxguest_core.c:(.text+0x1f6e): undefined reference to `vbg_hgcm_call32' Another compile-time check documents better what we want and avoids the error. Acked-by:
Randy Dunlap <rdunlap@infradead.org> Tested-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Anatolij Gustschin authored
[ Upstream commit 187fade8 ] If mapping the CvP BAR fails, we still can configure the FPGA via PCI config space access. In this case the iomap pointer is NULL. On x86_64, passing NULL address to pci_iounmap() generates "Bad IO access at port 0x0" output with stack call trace. Fix it. Signed-off-by:
Anatolij Gustschin <agust@denx.de> Acked-by:
Alan Tull <atull@kernel.org> Signed-off-by:
-
Dexuan Cui authored
[ Upstream commit 4fcba780 ] The patch fixes: hv_kvp_daemon.c: In function 'kvp_set_ip_info': hv_kvp_daemon.c:1305:2: note: 'snprintf' output between 41 and 4136 bytes into a destination of size 4096 The "(unsigned int)str_len" is to avoid: hv_kvp_daemon.c:1309:30: warning: comparison of integer expressions of different signedness: 'int' and 'long unsigned int' [-Wsign-compare] Signed-off-by:
Dexuan Cui <decui@microsoft.com> Cc: K. Y. Srinivasan <kys@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Andreas Puhm authored
[ Upstream commit 68f60538 ] The probe function needs to verify the CvP enable bit in order to properly determine if FPGA Manager functionality can be safely enabled. Fixes: 34d1dc17 ("fpga manager: Add Altera CvP driver") Signed-off-by:
Andreas Puhm <puhm@oregano.at> Signed-off-by:
Moritz Fischer <mdf@kernel.org> Acked-by:
-
Matheus Tavares authored
[ Upstream commit b3a3eafe ] Previously, ad2s90_probe ignored the return code from spi_setup, not handling its possible failure. This patch makes ad2s90_probe check if the code is an error code and, if so, do the following: - Call dev_err with an appropriate error message. - Return the spi_setup's error code. Note: The 'return ret' statement could be out of the 'if' block, but this whole block will be moved up in the function in the patch: 'staging:iio:ad2s90: Move device registration to the end of probe'. Signed-off-by:
Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by:
-
Naftali Goldstein authored
[ Upstream commit 5c2dbebb ] If the association supports HE, HT/VHT rates will never be used for Tx and therefore there's no need to set the sgi-per-channel-width-support bits, so don't set them in this case. Fixes: 110b32f0 ("iwlwifi: mvm: rs: add basic implementation of the new RS API handlers") Signed-off-by:
Naftali Goldstein <naftali.goldstein@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Ioana Ciornei authored
[ Upstream commit 5500598a ] The fsl_mc_portal_allocate can fail when the requested MC portals are not yet probed by the fsl_mc_allocator. In this situation, the driver should defer the probe. Signed-off-by:
Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by:
-
Paul Burton authored
[ Upstream commit 5ec17af7 ] The Intel EG20T Platform Controller Hub used on the MIPS Boston development board supports prefetching memory to optimize DMA transfers. Unfortunately for unknown reasons this doesn't work well with some MIPS CPUs such as the P6600, particularly when using an I/O Coherence Unit (IOCU) to provide cache-coherent DMA. In these systems it is common for DMA data to be lost, resulting in broken access to EG20T devices such as the MMC or SATA controllers. Support for a DT property to configure the prefetching was added a while back by commit 549ce8f1 ("misc: pch_phub: Read prefetch value from device tree if passed") but we never added the DT snippet to make use of it. Add that now in order to disable the prefetching & fix DMA on the affected systems. Signed-off-by:
Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/21068/ Cc: linux-mips@linux-mips.org Signed-off-by:
-
Miroslav Lichvar authored
[ Upstream commit 83d0bdc7 ] If a gettime64 call fails, return the error and avoid copying data back to user. Cc: Richard Cochran <richardcochran@gmail.com> Cc: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
Miroslav Lichvar <mlichvar@redhat.com> Signed-off-by:
-
Andy Duan authored
[ Upstream commit 397bd921 ] Current driver only enable parity enable bit and never clear it when user set the termios. The fix clear the parity enable bit when PARENB flag is not set in termios->c_cflag. Cc: Lukas Wunner <lukas@wunner.de> Signed-off-by:
Andy Duan <fugang.duan@nxp.com> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Boris Brezillon authored
[ Upstream commit 0560054d ] For the YUV conversion to work properly, ->x_scaling[1] should never be set to VC4_SCALING_NONE, but vc4_get_scaling_mode() might return VC4_SCALING_NONE if the horizontal scaling ratio exactly matches the horizontal subsampling factor. Add a test to turn VC4_SCALING_NONE into VC4_SCALING_PPF when that happens. The old ->x_scaling[0] adjustment is dropped as I couldn't find any mention to this constraint in the spec and it's proven to be unnecessary (I tested various multi-planar YUV formats with scaling disabled, and all of them worked fine without this adjustment). Fixes: fc04023f ("drm/vc4: Add support for YUV planes.") Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20181109102633.32603-1-boris.brezillon@bootlin.comSigned-off-by:
-
Eric Biggers authored
[ Upstream commit 0a6a40c2 ] In the "aes-fixed-time" AES implementation, disable interrupts while accessing the S-box, in order to make cache-timing attacks more difficult. Previously it was possible for the CPU to be interrupted while the S-box was loaded into L1 cache, potentially evicting the cachelines and causing later table lookups to be time-variant. In tests I did on x86 and ARM, this doesn't affect performance significantly. Responsiveness is potentially a concern, but interrupts are only disabled for a single AES block. Note that even after this change, the implementation still isn't necessarily guaranteed to be constant-time; see https://cr.yp.to/antiforgery/cachetiming-20050414.pdf for a discussion of the many difficulties involved in writing truly constant-time AES software. But it's valuable to make such attacks more difficult. Reviewed-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Frank Rowand authored
[ Upstream commit 5b3f5c40 ] The previous commit, "of: overlay: add missing of_node_get() in __of_attach_node_sysfs" added a missing of_node_get() to __of_attach_node_sysfs(). This results in a refcount imbalance for nodes attached with dlpar_attach_node(). The calling sequence from dlpar_attach_node() to __of_attach_node_sysfs() is: dlpar_attach_node() of_attach_node() __of_attach_node_sysfs() For more detailed description of the node refcount, see commit 68baf692 ("powerpc/pseries: Fix of_node_put() underflow during DLPAR remove"). Tested-by:
Frank Rowand <frank.rowand@sony.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 53bb565f ] In the expression "word1 << 16", word1 starts as u16, but is promoted to a signed int, then sign-extended to resource_size_t, which is probably not what was intended. Cast to resource_size_t to avoid the sign extension. This fixes an identical issue as fixed by commit 0b2d7076 ("x86/PCI: Fix Broadcom CNB20LE unintended sign extension") back in 2014. Detected by CoverityScan, CID#138749, 138750 ("Unintended sign extension") Fixes: 3f6ea84a ("PCI: read memory ranges out of Broadcom CNB20LE host bridge") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Bjorn Helgaas <helgaas@kernel.org> Signed-off-by:
-
Bob Peterson authored
[ Upstream commit 216f0efd ] Before this patch, recovery would cause all callbacks to be delayed, put on a queue, and afterward they were all queued to the callback work queue. This patch does the same thing, but occasionally takes a break after 25 of them so it won't swamp the CPU at the expense of other RT processes like corosync. Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
David Teigland <teigland@redhat.com> Signed-off-by:
-
