- 12 Feb, 2019 40 commits
-
-
Sebastian Andrzej Siewior authored
[ Upstream commit 6637401c ] Every user of user_insn() passes an user memory pointer to this macro. Add might_fault() to user_insn() so we can spot users which are using this macro in sections where page faulting is not allowed. [ bp: Space it out to make it more visible. ] Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Rik van Riel <riel@surriel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: kvm ML <kvm@vger.kernel.org> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20181128222035.2996-6-bigeasy@linutronix.deSigned-off-by:
Sasha Levin <sashal@kernel.org>
-
Lubomir Rintel authored
[ Upstream commit 1147e05a ] Marvell keeps their MMP2 datasheet secret, but there are good clues that TWSI2 is not on 0xd4025000 on that platform, not does it use IRQ 58. In fact, the IRQ 58 on MMP2 seems to be a signal processor: arch/arm/mach-mmp/irqs.h:#define IRQ_MMP2_MSP 58 I'm taking a somewhat educated guess that is probably a copy & paste error from PXA168 or PXA910 and that the real controller in fact hides at address 0xd4031000 and uses an interrupt line multiplexed via IRQ 17. I'm also copying some properties from TWSI1 that were missing or incorrect. Tested on a OLPC XO 1.75 machine, where the RTC is on TWSI2. Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Tested-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Mark Rutland authored
[ Upstream commit 6e803e2e ] The core ftrace code requires that when it is handed the PC of an instrumented function, this PC is the address of the instrumented instruction. This is necessary so that the core ftrace code can identify the specific instrumentation site. Since the instrumented function will be a BL, the address of the instrumented function is LR - 4 at entry to the ftrace code. This fixup is applied in the mcount_get_pc and mcount_get_pc0 helpers, which acquire the PC of the instrumented function. The mcount_get_lr helper is used to acquire the LR of the instrumented function, whose value does not require this adjustment, and cannot be adjusted to anything meaningful. No adjustment of this value is made on other architectures, including arm. However, arm64 adjusts this value by 4. This patch brings arm64 in line with other architectures and removes the adjustment of the LR value. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Torsten Duwe <duwe@suse.de> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Harald Freudenberger authored
[ Upstream commit be534791 ] There exist very few ap messages which need to have the 'special' flag enabled. This flag tells the firmware layer to do some pre- and maybe postprocessing. However, it may happen that this special flag is enabled but the firmware is unable to deal with this kind of message and thus returns with reply code 0x41. For example older firmware may not know the newest messages triggered by the zcrypt device driver and thus react with reject and the named reply code. Unfortunately this reply code is not known to the zcrypt error routines and thus default behavior is to switch the ap queue offline. This patch now makes the ap error routine aware of the reply code and so userspace is informed about the bad processing result but the queue is not switched to offline state any more. Signed-off-by:
Harald Freudenberger <freude@linux.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Arend van Spriel authored
[ Upstream commit ab2180a1 ] Since commit: ce2e6db5 ("brcmfmac: Add support for getting nvram contents from EFI variables") we have a device driver accessing the efivars API. Several functions in the efivars API assume __efivars is set, i.e., that they will be accessed only after efivars_register() has been called. However, the following NULL pointer access was reported calling efivar_entry_size() from the brcmfmac device driver: Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = 60bfa5f1 [00000008] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM ... Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) Workqueue: events request_firmware_work_func PC is at efivar_entry_size+0x28/0x90 LR is at brcmf_fw_complete_request+0x3f8/0x8d4 [brcmfmac] pc : [<c0c40718>] lr : [<bf2a3ef4>] psr: a00d0113 sp : ede7fe28 ip : ee983410 fp : c1787f30 r10: 00000000 r9 : 00000000 r8 : bf2b2258 r7 : ee983000 r6 : c1604c48 r5 : ede7fe88 r4 : edf337c0 r3 : 00000000 r2 : 00000000 r1 : ede7fe88 r0 : c17712c8 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: ad16804a DAC: 00000051 Disassembly showed that the local static variable __efivars is NULL, which is not entirely unexpected given that it is a non-EFI platform. So add a NULL pointer check to efivar_entry_size(), and to related functions while at it. In efivars_register() a couple of sanity checks are added as well. Reported-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Bhupesh Sharma <bhsharma@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Eric Snowberg <eric.snowberg@oracle.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Joe Perches <joe@perches.com> Cc: Julien Thierry <julien.thierry@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Nathan Chancellor <natechancellor@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Cc: Sedat Dilek <sedat.dilek@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: YiFei Zhu <zhuyifei1999@gmail.com> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20181129171230.18699-9-ard.biesheuvel@linaro.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Wei Wang authored
[ Upstream commit 964f4843 ] commit ff140fea ("Thermal: handle thermal zone device properly during system sleep") added PM hook to call thermal zone reset during sleep. However resetting thermal zone will also clear the passive state and thus cancel the polling queue which leads the passive cooling device state not being cleared properly after sleep. thermal_pm_notify => thermal_zone_device_reset set passive to 0 thermal_zone_trip_update will skip update passive as `old_target == instance->target'. monitor_thermal_zone => thermal_zone_device_set_polling will cancel tz->poll_queue, so the cooling device state will not be changed afterwards. Reported-by:
Kame Wang <kamewang@google.com> Signed-off-by:
Wei Wang <wvw@google.com> Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
-
Will Deacon authored
[ Upstream commit 1b57ec8c ] As of commit 6460d320 ("arm64: io: Ensure calls to delay routines are ordered against prior readX()"), MMIO reads smaller than 64 bits fail to compile under clang because we end up mixing 32-bit and 64-bit register operands for the same data processing instruction: ./include/asm-generic/io.h:695:9: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths] return readb(addr); ^ ./arch/arm64/include/asm/io.h:147:58: note: expanded from macro 'readb' ^ ./include/asm-generic/io.h:695:9: note: use constraint modifier "w" ./arch/arm64/include/asm/io.h:147:50: note: expanded from macro 'readb' ^ ./arch/arm64/include/asm/io.h:118:24: note: expanded from macro '__iormb' asm volatile("eor %0, %1, %1\n" \ ^ Fix the build by casting the macro argument to 'unsigned long' when used as an input to the inline asm. Reported-by:
Nick Desaulniers <nick.desaulniers@gmail.com> Reported-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Sean Paul authored
[ Upstream commit aa394b0d ] drm_atomic_helper_commit_duplicated_state() sets state->acquire_ctx to the context given in the argument and leaves it in state after it quits. The lifetime of state and context are not guaranteed to be the same, so we shouldn't leave that pointer hanging around. This patch resets the context to NULL to avoid any oopses. Changes in v2: - Added to the set Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181129150423.239081-1-sean@poorly.runSigned-off-by:
-
J. Bruce Fields authored
[ Upstream commit 62a063b8 ] Anatoly Trosinenko reports that this: 1) Checkout fresh master Linux branch (tested with commit e195ca6c) 2) Copy x84_64-config-4.14 to .config, then enable NFS server v4 and build 3) From `kvm-xfstests shell`: results in NULL dereference in locks_end_grace. Check that nfsd has been started before trying to end the grace period. Reported-by:
Anatoly Trosinenko <anatoly.trosinenko@gmail.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
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:
-
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:
-
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:
-
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:
-
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:
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:
-
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:
-
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:
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:
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:
-
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:
-
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:
-
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:
Anatolij Gustschin <agust@denx.de> Reviewed-by:
Moritz Fischer <mdf@kernel.org> Acked-by:
Alan Tull <atull@kernel.org> Signed-off-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:
-
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:
-
