- 12 Feb, 2019 40 commits
-
-
Yangtao Li authored
[ Upstream commit 1861a7f0 ] 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_brcmstb() doesn't do that, so fix it. [treding: slightly rewrite to avoid inline comparison] Fixes: d52fad26 ("soc: add stubs for brcmstb SoC's") Signed-off-by:
Yangtao Li <tiny.windzz@gmail.com> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Young Xiao authored
[ Upstream commit a11f6ca9 ] __vdc_tx_trigger should only loop on EAGAIN a finite number of times. See commit adddc32d ("sunvnet: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN") for detail. Signed-off-by:
Young Xiao <YangX92@hotmail.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
YueHaibing authored
[ Upstream commit 4e3c7c00 ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c:260:7: warning: variable 'err' set but not used [-Wunused-but-set-variable] 'err' should be returned while set MPI_DEINIT state fails in hw_atl_utils_soft_reset. Fixes: cce96d18 ("net: aquantia: Regression on reset with 1.x firmware") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Will Deacon authored
[ Upstream commit 6460d320 ] A relatively standard idiom for ensuring that a pair of MMIO writes to a device arrive at that device with a specified minimum delay between them is as follows: writel_relaxed(42, dev_base + CTL1); readl(dev_base + CTL1); udelay(10); writel_relaxed(42, dev_base + CTL2); the intention being that the read-back from the device will push the prior write to CTL1, and the udelay will hold up the write to CTL1 until at least 10us have elapsed. Unfortunately, on arm64 where the underlying delay loop is implemented as a read of the architected counter, the CPU does not guarantee ordering from the readl() to the delay loop and therefore the delay loop could in theory be speculated and not provide the desired interval between the two writes. Fix this in a similar manner to PowerPC by introducing a dummy control dependency on the output of readX() which, combined with the ISB in the read of the architected counter, guarantees that a subsequent delay loop can not be executed until the readX() has returned its result. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Simon Horman authored
[ Upstream commit 5eb316e6 ] Add support for the IIC code for the r8a77990 (R-Car E3). It is not considered compatible with existing fallback bindings due to the documented absence of automatic transmission registers. These registers are currently not used by the driver and thus the provides the same behaviour for "renesas,iic-r8a77990" and "renesas,rcar-gen3-iic". The point of declaring incompatibility is to allow for automatic transmission register support to be added to "renesas,iic-r8a77990" and "renesas,rcar-gen3-iic" in future. Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Tiezhu Yang authored
[ Upstream commit f6176473 ] When call f2fs_acl_create_masq() failed, the caller f2fs_acl_create() should return -EIO instead of -ENOMEM, this patch makes it consistent with posix_acl_create() which has been fixed in commit beaf226b ("posix_acl: don't ignore return value of posix_acl_create_masq()"). Fixes: 83dfe53c ("f2fs: fix reference leaks in f2fs_acl_create") Signed-off-by:
Tiezhu Yang <kernelpatch@126.com> Reviewed-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Sheng Yong authored
[ Upstream commit 2866fb16 ] The following race could lead to inconsistent SIT bitmap: Task A Task B ====== ====== f2fs_write_checkpoint block_operations f2fs_lock_all down_write(node_change) down_write(node_write) ... sync ... up_write(node_change) f2fs_file_write_iter set_inode_flag(FI_NO_PREALLOC) ...... f2fs_write_begin(index=0, has inline data) prepare_write_begin __do_map_lock(AIO) => down_read(node_change) f2fs_convert_inline_page => update SIT __do_map_lock(AIO) => up_read(node_change) f2fs_flush_sit_entries <= inconsistent SIT finish write checkpoint sudden-power-off If SPO occurs after checkpoint is finished, SIT bitmap will be set incorrectly. Signed-off-by:
Sheng Yong <shengyong1@huawei.com> Reviewed-by:
-
Yunlei He authored
[ Upstream commit b61ac5b7 ] This patch move dir data flush to write checkpoint process, by doing this, it may reduce some time for dir fsync. pre: -f2fs_do_sync_file enter -file_write_and_wait_range <- flush & wait -write_checkpoint -do_checkpoint <- wait all -f2fs_do_sync_file exit now: -f2fs_do_sync_file enter -write_checkpoint -block_operations <- flush dir & no wait -do_checkpoint <- wait all -f2fs_do_sync_file exit Signed-off-by:
Yunlei He <heyunlei@huawei.com> Signed-off-by:
-
Michael Straube authored
[ Upstream commit 64c4c4ca ] Add a test for successful call to cdev_alloc() to avoid potential null dereference. Issue reported by smatch. Signed-off-by:
Michael Straube <straube.linux@gmail.com> Fixes: 874bcba6 ("staging: pi433: New driver") Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit b413b1ab ] Since SPCR 1.04 [1] the baud rate of 0 means a preconfigured state of UART. Assume firmware or bootloader configures console correctly. [1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-tableSigned-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Prarit Bhargava <prarit@redhat.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit 2912289a ] The v4l2_dv_timings_cap struct is used to do sanity checks when setting and enumerating DV timings, ensuring that only valid timings as per the HW capabilities are allowed. However, many drivers just filled in 0 for the minimum width, height or pixelclock frequency. This can cause timings with e.g. 0 as width and height to be accepted, which will in turn lead to a potential division by zero. Fill in proper values are minimum boundaries. 640x350 was chosen since it is the smallest resolution in v4l2-dv-timings.h. Same for 13 MHz as the lowest pixelclock frequency (it's slightly below the minimum of 13.5 MHz in the v4l2-dv-timings.h header). Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 7f6232e6 ] Various 2-in-1's use KIOX010A and KIOX020A as HIDs for 2 KXCJ91008 accelerometers. The KIOX010A HID is for the one in the base and the KIOX020A for the accelerometer in the keyboard. Since userspace does not have a way yet to deal with (or ignore) the accelerometer in the keyboard, this commit just adds the KIOX010A HID for now so that display rotation will work. Related: https://github.com/hadess/iio-sensor-proxy/issues/166Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Martin Blumenstingl authored
[ Upstream commit 50314f98 ] Before this patch we are registering the internal clocks (for example on Meson8b, where the SAR ADC IP block implements the divider and gate clocks) with the following names: - /soc/cbus@c1100000/adc@8680#adc_div - /soc/cbus@c1100000/adc@8680#adc_en This is bad because the common clock framework uses the clock to create a directory in <debugfs>/clk. With such name, the directory creation (silently) fails and the debugfs entry ends up being created at the debugfs root. With this change, the new clock names are: - c1108680.adc#adc_div - c1108680.adc#adc_en This matches the clock naming scheme used in the PWM, Ethernet and MMC drivers. It also fixes the problem with debugfs. The idea is shamelessly taken from commit b96e9eb6 ("pwm: meson: Fix mux clock names"). Fixes: 3921db46 ("iio: Convert to using %pOF instead of full_name") Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
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:
-
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:
Richard Cochran <richardcochran@gmail.com> 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:
Gao Xiang <gaoxiang25@huawei.com> 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:
-
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:
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:
-
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:
-
