- 12 Feb, 2019 40 commits
-
-
Alexander Duyck authored
[ Upstream commit c37d721c ] Move the async_synchronize_full call out of __device_release_driver and into driver_detach. The idea behind this is that the async_synchronize_full call will only guarantee that any existing async operations are flushed. This doesn't do anything to guarantee that a hotplug event that may occur while we are doing the release of the driver will not be asynchronously scheduled. By moving this into the driver_detach path we can avoid potential deadlocks as we aren't holding the device lock at this point and we should not have the driver we want to flush loaded so the flush will take care of any asynchronous events the driver we are detaching might have scheduled. Fixes: 765230b5 ("driver-core: add asynchronous probing support for drivers") Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
Alexander Duyck <alexander.h.duyck@linux.intel.com> Reviewed-by:
Luis Chamberlain <mcgrof@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Hoang Le authored
[ Upstream commit f5d6c3e5 ] When setting LINK tolerance, node timer interval will be calculated base on the LINK with lowest tolerance. But when calculated, the old node timer interval only updated if current setting value (tolerance/4) less than old ones regardless of number of links as well as links' lowest tolerance value. This caused to two cases missing if tolerance changed as following: Case 1: 1.1/ There is one link (L1) available in the system 1.2/ Set L1's tolerance from 1500ms => lower (i.e 500ms) 1.3/ Then, fallback to default (1500ms) or higher (i.e 2000ms) Expected: node timer interval is 1500/4=375ms after 1.3 Result: node timer interval will not being updated after changing tolerance at 1.3 since its value 1500/4=375ms is not less than 500/4=125ms at 1.2. Case 2: 2.1/ There are two links (L1, L2) available in the system 2.2/ L1 and L2 tolerance value are 2000ms as initial 2.3/ Set L2's tolerance from 2000ms => lower 1500ms 2.4/ Disable link L2 (bring down its bearer) Expected: node timer interval is 2000ms/4=500ms after 2.4 Result: node timer interval will not being updated after disabling L2 since its value 2000ms/4=500ms is still not less than 1500/4=375ms at 2.3 although L2 is already not available in the system. To fix this, we start the node interval calculation by initializing it to a value larger than any conceivable calculated value. This way, the link with the lowest tolerance will always determine the calculated value. Acked-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
Hoang Le <hoang.h.le@dektech.com.au> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Alex Deucher authored
[ Upstream commit de4aaab5 ] Adjust limits for newer polaris variants. v2: fix polaris11 kicker (Jerry) Reviewed-by:
Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Luca Ceresoli authored
[ Upstream commit 4f9d7225 ] The imx274 driver uses regmap and the build will fail without it. Fixes: drivers/media/i2c/imx274.c:142:21: error: variable ‘imx274_regmap_config’ has initializer but incomplete type static const struct regmap_config imx274_regmap_config = { ^~~~~~~~~~~~~ drivers/media/i2c/imx274.c:1869:19: error: implicit declaration of function ‘devm_regmap_init_i2c’ [-Werror=implicit-function-declaration] imx274->regmap = devm_regmap_init_i2c(client, &imx274_regmap_config); ^~~~~~~~~~~~~~~~~~~~ and others. Signed-off-by:
Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Chen-Yu Tsai authored
[ Upstream commit 6e6da203 ] All the audio interfaces on Allwinner SoCs need to change their module clocks during operation, to switch between support for 44.1 kHz and 48 kHz family sample rates. The clock rate for the module clocks is governed by their upstream audio PLL. The module clocks themselves only have a gate, and sometimes a divider or mux. Thus any rate changes need to be propagated upstream. Set the CLK_SET_RATE_PARENT flag for all audio module clocks to achieve this. Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
-
Chunfeng Yun authored
[ Upstream commit a0678e2e ] Fix the issue: device doesn't accept LGO_U1/U2: 1. set SW_U1/U2_ACCEPT_ENABLE to eanble controller to accept LGO_U1/U2 by default; 2. enable/disable controller to initiate requests for transition into U1/U2 by SW_U1/U2_REQUEST_ENABLE instead of SW_U1/U2_ACCEPT_ENABLE; Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit ce10a5b3 ] tk_core.seq is initialized open coded, but that misses to initialize the lockdep map when lockdep is enabled. Lockdep splats involving tk_core seq consequently lack a name and are hard to read. Use the proper initializer which takes care of the lockdep map initialization. [ tglx: Massaged changelog ] Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: peterz@infradead.org Cc: tj@kernel.org Cc: johannes.berg@intel.com Link: https://lkml.kernel.org/r/20181128234325.110011-12-bvanassche@acm.orgSigned-off-by:
-
Mathias Nyman authored
[ Upstream commit e8610894 ] When initializing a hub we want to give a USB3 port in link training the same debounce delay time before autosuspening the hub as already trained, connected enabled ports. USB3 ports won't reach the enabled state with "current connect status" and "connect status change" bits set until the USB3 link training finishes. Catching the port in link training (polling) and adding the debounce delay prevents unnecessary failed attempts to autosuspend the hub. Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Marek Szyprowski authored
[ Upstream commit 35a60541 ] Power down feature of DWC2 module integrated in Samsung SoCs doesn't work properly or needs some additional handling in PHY or SoC glue layer, so disable it for now. Without disabling power down, DWC2 causes random memory trashes and fails enumeration if there is no USB link to host on driver probe. Fixes: 03ea6d6e ("usb: dwc2: Enable power down") Acked-by:
Minas Harutyunyan <hminas@synopsys.com> Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Anurag Kumar Vulisha authored
[ Upstream commit b7a4fbe2 ] Availability of TRB's is calculated using dwc3_calc_trbs_left(), which determines total available TRB's based on the HWO bit set in a TRB. In the present code, __dwc3_prepare_one_trb() is called with a TRB which needs to be prepared for transfer. This __dwc3_prepare_one_trb() calls dwc3_calc_trbs_left() to determine total available TRBs and set IOC bit if the total available TRBs are zero. Since the present working TRB (which is passed as an argument to __dwc3_prepare_one_trb() ) doesn't yet have the HWO bit set before calling dwc3_calc_trbs_left(), there are chances that dwc3_calc_trbs_left() wrongly calculates this present working TRB as free(since the HWO bit is not yet set) and returns the total available TRBs as greater than zero (including the present working TRB). This could be a problem. This patch corrects the above mentioned problem in __dwc3_prepare_one_trb() by increementing the dep->trb_enqueue at the last (after preparing the TRB) instead of increementing at the start and setting the IOC bit only if the total available TRBs returned by dwc3_calc_trbs_left() is 1 . Since we are increementing the dep->trb_enqueue at the last, the present working TRB is also considered as available by dwc3_calc_trbs_left() and non zero value is returned . So, according to the modified logic, when the total available TRBs is equal to 1 that means the total available TRBs in the pool are 0. Signed-off-by:
Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com> Reviewed-by:
Thinh Nguyen <thinhn@synopsys.com> Tested-by:
Tejas Joglekar <tejas.joglekar@synopsys.com> Signed-off-by:
-
Max Filippov authored
[ Upstream commit f37598be ] Rename SPI controller node in the XTFPGA DTS to spi@... This fixes the following build warnings: arch/xtensa/boot/dts/kc705_nommu.dtb: Warning (spi_bus_bridge): /soc/spi-master@0d0a0000: node name for SPI buses should be 'spi' arch/xtensa/boot/dts/kc705_nommu.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' arch/xtensa/boot/dts/lx200mx.dtb: Warning (spi_bus_bridge): /soc/spi-master@0d0a0000: node name for SPI buses should be 'spi' arch/xtensa/boot/dts/lx200mx.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' arch/xtensa/boot/dts/kc705.dtb: Warning (spi_bus_bridge): /soc/spi-master@0d0a0000: node name for SPI buses should be 'spi' arch/xtensa/boot/dts/kc705.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' arch/xtensa/boot/dts/ml605.dtb: Warning (spi_bus_bridge): /soc/spi-master@0d0a0000: node name for SPI buses should be 'spi' arch/xtensa/boot/dts/ml605.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' arch/xtensa/boot/dts/lx60.dtb: Warning (spi_bus_bridge): /soc/spi-master@0d0a0000: node name for SPI buses should be 'spi' arch/xtensa/boot/dts/lx60.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
-
Zoran Markovic authored
[ Upstream commit 5b841bfa ] Function smack_key_permission() only issues smack requests for the following operations: - KEY_NEED_READ (issues MAY_READ) - KEY_NEED_WRITE (issues MAY_WRITE) - KEY_NEED_LINK (issues MAY_WRITE) - KEY_NEED_SETATTR (issues MAY_WRITE) A blank smack request is issued in all other cases, resulting in smack access being granted if there is any rule defined between subject and object, or denied with -EACCES otherwise. Request MAY_READ access for KEY_NEED_SEARCH and KEY_NEED_VIEW. Fix the logic in the unlikely case when both MAY_READ and MAY_WRITE are needed. Validate access permission field for valid contents. Signed-off-by:
Zoran Markovic <zmarkovic@sierrawireless.com> Signed-off-by:
Casey Schaufler <casey@schaufler-ca.com> Cc: Casey Schaufler <casey@schaufler-ca.com> Cc: James Morris <jmorris@namei.org> Cc: "Serge E. Hallyn" <serge@hallyn.com> Signed-off-by:
-
Alexey Khoroshilov authored
[ Upstream commit aa35dc3c ] If vpbe_set_default_output() or vpbe_set_default_mode() fails, vpbe_initialize() returns error code without releasing resources. The patch adds error handling for that case. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 79e89e36 ] Without CONFIG_HDMI, we get a link error for this driver: drivers/media/i2c/tda1997x.o: In function `tda1997x_parse_infoframe': tda1997x.c:(.text+0x2195): undefined reference to `hdmi_infoframe_unpack' tda1997x.c:(.text+0x21b6): undefined reference to `hdmi_infoframe_log' drivers/media/i2c/tda1997x.o: In function `tda1997x_log_infoframe': tda1997x.c:(.text.unlikely+0x13d3): undefined reference to `hdmi_infoframe_unpack' tda1997x.c:(.text.unlikely+0x1426): undefined reference to `hdmi_infoframe_log' All other drivers in this directory that use HDMI select CONFIG_HDMI, so do the same here: Fixes: 9ac0038d ("media: i2c: Add TDA1997x HDMI receiver driver") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
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:
-
Rob Herring authored
[ Upstream commit 8ef86955 ] The base aspeed-g5.dtsi already defines a '/memory@80000000' node, so '/memory' in the board files create a duplicate node. We're probably getting lucky that the bootloader fixes up the memory node that the kernel ends up using. Add the unit-address so it's merged with the base node. Found with DT json-schema checks. Cc: Joel Stanley <joel@jms.id.au> Cc: Andrew Jeffery <andrew@aj.id.au> Cc: devicetree@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-aspeed@lists.ozlabs.org Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
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:
-
Eric Anholt authored
[ Upstream commit 62d1a752 ] v3d_bo_get_pages() checks this to decide to map the imported buffer instead of the backing shmem file. The caller was about to set this value anyway, and there's no error path in between. Ideally we wouldn't even allocate the shmem file for our imports, but that's a more invasive fix. Signed-off-by:
Eric Anholt <eric@anholt.net> Fixes: 57692c94 ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+") Link: https://patchwork.freedesktop.org/patch/msgid/20181128230927.10951-3-eric@anholt.netAcked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Dave Emett <david.emett@broadcom.com> 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:
-
Lorenzo Bianconi authored
[ Upstream commit 6bf4a8e9 ] Fix IBI_R11 configuration on non-radar channels for mt76x0e driver. This patch improve system stability under heavy load. Moreover use IBI_R11 name and remove magic numbers for 0x212c register Fixes: 0c3b3abc9251 ("mt76x0: pci: add DFS support") Signed-off-by:
Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by:
Felix Fietkau <nbd@nbd.name> 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:
-
Thara Gopinath authored
[ Upstream commit 68000a0d ] Sysfs interface to update cooling device cur_state does not currently holding cooling device lock sometimes leading to stale values in cur_state if getting updated simultanelously from user space and thermal framework. Adding the proper locking code fixes this issue. Signed-off-by:
Thara Gopinath <thara.gopinath@linaro.org> Signed-off-by:
Zhang Rui <rui.zhang@intel.com> 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:
-
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:
-
Nicholas Mc Guire authored
[ Upstream commit 754a58db ] devm_kasprintf() may return NULL on failure of internal allocation thus the assignment to 'name' is not safe if unchecked. If NULL is passed in for name then perf_pmu_register() would not fail but rather silently jump to skip_type which is not the intent here. As perf_pmu_register() may also return -ENOMEM returning -ENOMEM in the (unlikely) failure case of devm_kasprintf() should be fine here as well. Acked-by:
Nicholas Mc Guire <hofrat@osadl.org> [will: reworded error message] 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:
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:
-
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:
-
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:
-
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 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:
-
