aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-03-14libfdt: prefix header search paths with $(srctree)/Masahiro Yamada1-1/+1
Currently, the Kbuild core manipulates header search paths in a crazy way [1]. To fix this mess, I want all Makefiles to add explicit $(srctree)/ to the search paths in the srctree. Some Makefiles are already written in that way, but not all. The goal of this work is to make the notation consistent, and finally get rid of the gross hacks. Having whitespaces after -I does not matter since commit 48f6e3cf5bc6 ("kbuild: do not drop -I without parameter"). [1]: https://patchwork.kernel.org/patch/9632347/ Signed-off-by: Masahiro Yamada <[email protected]>
2019-03-14deb-pkg: generate correct build dependenciesRiku Voipio1-1/+3
bison/flex is now needed always for building for kconfig. Some build dependencies depend on kernel configuration, enable them as needed: - libelf-dev when UNWINDER_ORC is set - libssl-dev for SYSTEM_TRUSTED_KEYRING Since the libssl-dev is needed for extract_cert binary, denote with :native to install the libssl-dev for the build machines architecture, rather than for the architecture of the kernel being built. Tested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Riku Voipio <[email protected]> Reviewed-by: Ben Hutchings <[email protected]> Acked-by: maximilian attems <[email protected]> [masahiro.yamada: change 'flex' to 'flex | flex:native' ] Signed-off-by: Masahiro Yamada <[email protected]>
2019-03-13i2c: i2c-designware-platdrv: Always use a dynamic adapter numberHans de Goede1-4/+1
Before this commit the i2c-designware-platdrv assumes that if the pdev has an apci-companion it should use a dynamic adapter-nr and it sets adapter->nr to -1, otherwise it will use pdev->id as adapter->nr. There are 3 ways how platform_device-s to which i2c-designware-platdrv will bind can be instantiated: 1) Through of / devicetree 2) Through ACPI enumeration 3) Explicitly instantiated through platform_device_create + add 1) In case of devicetree-instantiation the drivers/of code always sets pdev->id to PLATFORM_DEVID_NONE, which is -1 so in this case both paths to set adapter->nr end up doing the same thing. 2) In case of ACPI instantiation the device will always have an ACPI-companion, so we are already using dynamic adapter-nrs. 3) There are 2 places manually instantiating a designware_i2c platform_dev: drivers/mfd/intel_quark_i2c_gpio.c drivers/mfd/intel-lpss.c In the intel_quark_i2c_gpio.c case pdev->id is always 0, so switching to dynamic adapter-nrs here could lead to the bus-number no longer being stable, but the quark X1000 only has 1 i2c-controller, which will also be assigned bus-number 0 when using dynamic adapter-nrs. In the intel-lpss.c case intel_lpss_probe() is called from either intel-lpss-acpi.c in which case there always is an ACPI-companion, or from intel-lpss-pci.c. In most cases devices handled by intel-lpss-pci.c also have an ACPI-companion, so we use a dynamic adapter-nr. But in some cases the ACPI-companion is missing and we would use pdev->id (allocated from intel_lpss_devid_ida). Devices which use the intel-lpss-pci.c code typically have many i2c busses, so using pdev->id in this case may lead to a bus-number conflict, triggering a WARN(id < 0, "couldn't get idr") in i2c-core-base.c causing an oops an the adapter registration to fail. So in this case using non dynamic adapter-nrs is actually undesirable. One machine on which this oops was triggering is the Apollo Lake based Acer TravelMate Spin B118. TL;DR: Switching to always using dynamic adapter-numbers does not make any difference in most cases and in the one case where it does make a difference the behavior change is desirable because the old behavior caused an oops. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1687065 Signed-off-by: Hans de Goede <[email protected]> Acked-by: Andy Shevchenko <[email protected]> Acked-by: Jarkko Nikula <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2019-03-13i2c: i2c-designware-platdrv: Cleanup setting of the adapter numberHans de Goede1-4/+6
i2c-designware-platdrv assumes that if the pdev has an apci-companion it should use a dynamic adapter-nr and otherwise it will use pdev->id as adapter-nr. Before this commit the setting of the adapter.nr was somewhat convoluted, in the acpi_companion case it was set from dw_i2c_acpi_configure, in the non acpi_companion case it was set from dw_i2c_set_fifo_size based on tx_fifo_depth not being set yet indicating that dw_i2c_acpi_configure was not executed. This cleans this up, directly setting the adapter-nr from dw_i2c_plat_probe for both cases. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: Jarkko Nikula <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2019-03-13Merge tag 'kconfig-v5.1' of ↵Linus Torvalds7-14/+44
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kconfig updates from Masahiro Yamada: - rename lexer and parse files - fix 'Save as' menu of xconfig * tag 'kconfig-v5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kconfig: fix 'Save As' menu of xconfig kconfig: rename zconf.y to parser.y kconfig: rename zconf.l to lexer.l
2019-03-13i2c: add extra check to safe DMA buffer helperWolfram Sang1-2/+7
Make sure we report 'no buffer' for 0-length messages. This can only happen if threshold is set to 0 which is kind of bogus but we should still handle this situation. Update the docs and add a debug message to educate callers of this function. Reported-by: Hsin-Yi Wang <[email protected]> Fixes: e94bc5d18be0 ("i2c: add helpers to ease DMA handling") Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Hsin-Yi Wang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2019-03-13Merge tag 'pwm/for-5.1-rc1' of ↵Linus Torvalds13-300/+474
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "The changes for this cycle are across the board. The bulk of it is cleanups, but there's also new device support in some drivers as well as more conversions to the atomic API" * tag 'pwm/for-5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (24 commits) pwm: atmel: Remove useless symbolic definitions pwm: bcm-kona: Update macros to remove braces around numbers pwm: imx27: Only enable the clocks once in .get_state() pwm: rcar: Improve calculation of divider pwm: rcar: Remove legacy APIs pwm: rcar: Use "atomic" API on rcar_pwm_resume() pwm: rcar: Add support "atomic" API pwm: atmel: Add support for SAM9X60's PWM controller pwm: atmel: Add PWM binding for SAM9X60 pwm: atmel: Rename objects of type atmel_pwm_data pwm: atmel: Add support for controllers with 32 bit counters pwm: atmel: Add struct atmel_pwm_data pwm: Add MediaTek MT8183 display PWM driver support pwm: hibvt: Add hi3559v100 support dt-bindings: pwm: hibvt: Add hi3559v100 support pwm: hibvt: Use individual struct per of-data pwm: imx: Signedness bug in imx_pwm_get_state() pwm: imx: Split into two drivers pwm: imx: Don't print an error on -EPROBE_DEFER pwm: imx: Set driver data earlier simplifying the end of ->probe() ...
2019-03-13Merge tag 'mailbox-v5.1' of ↵Linus Torvalds9-18/+903
git://git.linaro.org/landing-teams/working/fujitsu/integration Pull mailbox updates from Jassi Brar: - mailbox-test: support multiple controller instances - misc cleanup: IMX, STM32 and Tegra - new driver: ZynqMP IPI * tag 'mailbox-v5.1' of git://git.linaro.org/landing-teams/working/fujitsu/integration: mailbox: imx: keep MU irq working during suspend/resume dt-bindings: mailbox: Add Xilinx IPI Mailbox mailbox: ZynqMP IPI mailbox controller mailbox: stm32-ipcc: remove useless device_init_wakeup call mailbox: stm32-ipcc: do not enable wakeup source by default mailbox: mailbox-test: fix null pointer if no mmio mailbox: mailbox-test: fix debugfs in multi-instances mailbox: tegra-hsp: mark suspend function as __maybe_unused
2019-03-13Merge branch 'linus' of ↵Linus Torvalds6-28/+51
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "This fixes a bug in the newly added Exynos5433 AES code as well as an old one in the caam driver" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: caam - add missing put_device() call crypto: s5p-sss - fix AES support for Exynos5433
2019-03-13Merge branch 'for-5.1/md-post' of https://github.com/liu-song-6/linux into ↵Jens Axboe5-1/+72
for-5.1/block-post Pull MD fixes from Song. * 'for-5.1/md-post' of https://github.com/liu-song-6/linux: md: Fix failed allocation of md_register_thread It's wrong to add len to sector_nr in raid10 reshape twice raid5: set write hint for PPL
2019-03-13Merge tag 'libnvdimm-for-5.1' of ↵Linus Torvalds15-113/+273
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm Pull libnvdimm updates from Dan Williams: "The bulk of this has been in -next since before the merge window opened, with no known collisions / issues reported. The only detail worth noting, outside the summary below, is that the "libnvdimm-start-pad" topic has been truncated to just cleanups and small fixes. The full topic branch would have doubled down on hacks around the "section alignment" limitation of the core-mm, instead effort is now being spent to address that root issue in the memory hotplug implementation for v5.2. - Fix nfit-bus command submission regression - Support retrieval of short-ARS results if the ARS state is "requires continuation", and even if the "no_init_ars" module parameter is specified - Allow busy-polling of the kernel ARS state by allowing root to reset the exponential back-off timer - Filter potentially stale ARS results by tracking query-ARS relative to the previous start-ARS - Enhance dax_device alignment checks - Add support for the Hyper-V family of device-specific-methods (DSMs) - Add several fixes and workarounds for Hyper-V compatibility - Fix support to cache the dirty-shutdown-count at init" * tag 'libnvdimm-for-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: (25 commits) libnvdimm/namespace: Clean up holder_class_store() libnvdimm/of_pmem: Fix platform_no_drv_owner.cocci warnings acpi/nfit: Update NFIT flags error message libnvdimm/btt: Fix LBA masking during 'free list' population libnvdimm/btt: Remove unnecessary code in btt_freelist_init libnvdimm/pfn: Remove dax_label_reserve dax: Check the end of the block-device capacity with dax_direct_access() nfit/ars: Avoid stale ARS results nfit/ars: Allow root to busy-poll the ARS state machine nfit/ars: Introduce scrub_flags nfit/ars: Remove ars_start_flags nfit/ars: Attempt short-ARS even in the no_init_ars case nfit/ars: Attempt a short-ARS whenever the ARS state is idle at boot acpi/nfit: Require opt-in for read-only label configurations libnvdimm/pmem: Honor force_raw for legacy pmem regions libnvdimm/pfn: Account for PAGE_SIZE > info-block-size in nd_pfn_init() libnvdimm: Fix altmap reservation size calculation libnvdimm, pfn: Fix over-trim in trim_pfn_device() acpi/nfit: Fix bus command validation libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family ...
2019-03-13Merge tag 'fsdax-for-5.1' of ↵Linus Torvalds1-14/+11
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm Pull filesystem-dax updates from Dan Williams: - Fix handling of PMD-sized entries in the Xarray that lead to a crash scenario - Miscellaneous cleanups and small fixes * tag 'fsdax-for-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: dax: Flush partial PMDs correctly fs/dax: NIT fix comment regarding start/end vs range fs/dax: Convert to use vmf_error()
2019-03-13Merge tag 'upstream-5.1-rc1' of ↵Linus Torvalds5-7/+211
git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs Pull UBI and UBIFS updates from Richard Weinberger: - A new interface for UBI to deal better with read disturb - Reject unsupported ioctl flags in UBIFS (xfstests found it) * tag 'upstream-5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs: ubi: wl: Silence uninitialized variable warning ubifs: Reject unsupported ioctl flags explicitly ubi: Expose the bitrot interface ubi: Introduce in_pq()
2019-03-13regulator: wm8350: Convert to use regulator_set/get_current_limit_regmapAxel Lin1-70/+11
Use regulator_set/get_current_limit_regmap helpers to save some code. Signed-off-by: Axel Lin <[email protected]> Acked-by: Charles Keepax <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: wm831x-isink: Convert to use regulator_set/get_current_limit_regmapAxel Lin3-40/+9
Use regulator_set/get_current_limit_regmap helpers to save some code. Signed-off-by: Axel Lin <[email protected]> Acked-by: Charles Keepax <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: wm8350: Select maximum current in specific rangeAxel Lin1-1/+1
.set_current_limit callback should select the current closest to max_uA. Signed-off-by: Axel Lin <[email protected]> Acked-by: Charles Keepax <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: wm831x-isink: Select maximum current in specific rangeAxel Lin1-1/+1
.set_current_limit callback should select the current closest to max_uA. Signed-off-by: Axel Lin <[email protected]> Acked-by: Charles Keepax <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: wm831x ldo: Fix notifier mutex lock warningSteve Twiss1-0/+2
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: d1c6b4fe668b ("regulator: Add WM831x LDO support") Suggested-by: Adam Thomson <[email protected]> Signed-off-by: Steve Twiss <[email protected]> Acked-by: Charles Keepax <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: wm831x isink: Fix notifier mutex lock warningSteve Twiss1-0/+2
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: d4d6b722e780 ("regulator: Add WM831x ISINK support") Suggested-by: Adam Thomson <[email protected]> Signed-off-by: Steve Twiss <[email protected]> Acked-by: Charles Keepax <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: max14577: Get rid of match_init_data/match_of_node functionsAxel Lin1-55/+0
This driver has been converted to use regulator core's simplified DT parsing code. So the match_init_data/match_of_node functions are not necessary now, remove them. Signed-off-by: Axel Lin <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: da903x: don't build with clangArnd Bergmann1-0/+1
The da903x driver produces an annoying false-positive warning when built with clang: drivers/regulator/da903x.c:395:2: error: division by zero is undefined [-Werror,-Wdivision-by-zero] DA9030_LDO(13, 2100, 2100, 0, INVAL, 0, 0, RCTL11, 3), /* fixed @2.1V */ ^ ~ drivers/regulator/da903x.c:359:2: note: expanded from macro 'DA9030_LDO' DA903x_LDO(DA9030, _id, min, max, step, vreg, shift, nbits, ereg, ebit) ^ ~~~~ drivers/regulator/da903x.c:320:39: note: expanded from macro 'DA903x_LDO' .n_voltages = (step) ? ((max - min) / step + 1) : 1, \ ^ ~~~~ drivers/regulator/da903x.c:415:2: error: division by zero is undefined [-Werror,-Wdivision-by-zero] DA9034_LDO(5, 3100, 3100, 0, INVAL, 0, 0, OVER3, 7), /* fixed @3.1V */ ^ ~ drivers/regulator/da903x.c:356:2: note: expanded from macro 'DA9034_LDO' DA903x_LDO(DA9034, _id, min, max, step, vreg, shift, nbits, ereg, ebit) ^ ~~~~ drivers/regulator/da903x.c:320:39: note: expanded from macro 'DA903x_LDO' .n_voltages = (step) ? ((max - min) / step + 1) : 1, \ ^ ~~~~ I already reported this as a bug in clang, but it may take a while to fix it. As I have not been able to come up with any reasonable workaround, I would just disable compilation here. Link: https://bugs.llvm.org/show_bug.cgi?id=38789 Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: pv88060: Fix notifier mutex lock warningSteve Twiss1-0/+4
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: f307a7e9b7af ("regulator: pv88060: new regulator driver") Suggested-by: Adam Thomson <[email protected]> Signed-off-by: Steve Twiss <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: ltc3676: Fix notifier mutex lock warningSteve Twiss1-2/+8
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 37b918a034fe ("regulator: Add LTC3676 support") Suggested-by: Adam Thomson <[email protected]> Signed-off-by: Steve Twiss <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: ltc3589: Fix notifier mutex lock warningSteve Twiss1-2/+8
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 3eb2c7ecb7ea ("regulator: Add LTC3589 support") Suggested-by: Adam Thomson <[email protected]> Signed-off-by: Steve Twiss <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: lp8755: Fix notifier mutex lock warningSteve Twiss1-3/+12
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: b59320cc5a5e ("regulator: lp8755: new driver for LP8755") Suggested-by: Adam Thomson <[email protected]> Signed-off-by: Steve Twiss <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: da9211: Fix notifier mutex lock warningSteve Twiss1-0/+4
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 1028a37daa14 ("regulator: da9211: new regulator driver") Suggested-by: Adam Thomson <[email protected]> Signed-off-by: Steve Twiss <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: da9063: Fix notifier mutex lock warningSteve Twiss1-1/+4
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 69ca3e58d178 ("regulator: da9063: Add Dialog DA9063 voltage regulators support.") Suggested-by: Adam Thomson <[email protected]> Signed-off-by: Steve Twiss <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: wm831x: Fix notifier mutex lock warningSteve Twiss1-0/+4
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: e4ee831f949a ("regulator: Add WM831x DC-DC buck convertor support") Suggested-by: Adam Thomson <[email protected]> Signed-off-by: Steve Twiss <[email protected]> Acked-by: Charles Keepax <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: pv88090: Fix notifier mutex lock warningSteve Twiss1-0/+4
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: c90456e36d9c ("regulator: pv88090: new regulator driver") Suggested-by: Adam Thomson <[email protected]> Signed-off-by: Steve Twiss <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: pv88080: Fix notifier mutex lock warningSteve Twiss1-0/+4
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 99cf3af5e2d5 ("regulator: pv88080: new regulator driver") Suggested-by: Adam Thomson <[email protected]> Signed-off-by: Steve Twiss <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: da9062: Fix notifier mutex lock warningSteve Twiss1-0/+2
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 4068e5182ada ("regulator: da9062: DA9062 regulator driver") Suggested-by: Adam Thomson <[email protected]> Signed-off-by: Steve Twiss <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: da9055: Fix notifier mutex lock warningSteve Twiss1-0/+2
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: f6130be652d0 ("regulator: DA9055 regulator driver") Suggested-by: Adam Thomson <[email protected]> Signed-off-by: Steve Twiss <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: gpio: Constify regulator_opsAxel Lin1-2/+2
gpio_regulator_voltage_ops and gpio_regulator_current_ops should never change, make them const. Signed-off-by: Axel Lin <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13regulator: gpio: Convert to devm_regulator_registerAxel Lin1-14/+4
Use devm_regulator_register to simplify the code. Signed-off-by: Axel Lin <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-03-13tracing: kdb: Fix ftdump to not sleepDouglas Anderson4-7/+12
As reported back in 2016-11 [1], the "ftdump" kdb command triggers a BUG for "sleeping function called from invalid context". kdb's "ftdump" command wants to call ring_buffer_read_prepare() in atomic context. A very simple solution for this is to add allocation flags to ring_buffer_read_prepare() so kdb can call it without triggering the allocation error. This patch does that. Note that in the original email thread about this, it was suggested that perhaps the solution for kdb was to either preallocate the buffer ahead of time or create our own iterator. I'm hoping that this alternative of adding allocation flags to ring_buffer_read_prepare() can be considered since it means I don't need to duplicate more of the core trace code into "trace_kdb.c" (for either creating my own iterator or re-preparing a ring allocator whose memory was already allocated). NOTE: another option for kdb is to actually figure out how to make it reuse the existing ftrace_dump() function and totally eliminate the duplication. This sounds very appealing and actually works (the "sr z" command can be seen to properly dump the ftrace buffer). The downside here is that ftrace_dump() fully consumes the trace buffer. Unless that is changed I'd rather not use it because it means "ftdump | grep xyz" won't be very useful to search the ftrace buffer since it will throw away the whole trace on the first grep. A future patch to dump only the last few lines of the buffer will also be hard to implement. [1] https://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Reported-by: Brian Norris <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2019-03-13ALSA: hda - add more quirks for HP Z2 G4 and HP Z240Jaroslav Kysela2-2/+7
Apply the HP_MIC_NO_PRESENCE fixups for the more HP Z2 G4 and HP Z240 models. Reported-by: Jeff Burrell <[email protected]> Signed-off-by: Jaroslav Kysela <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2019-03-13ALSA: hda/realtek - Fixed Headset Mic JD not stableKailang Yang1-1/+28
It will be lose Mic JD state when Chrome OS boot and headset was plugged. Implement of reset combo jack JD. It will show normally. Fixes: e854747d7593 ("ALSA: hda/realtek - Enable headset button support for new codec") Signed-off-by: Kailang Yang <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2019-03-13ALSA: hda/realtek: Enable headset MIC of Acer TravelMate X514-51T with ALC255Jian-Hong Pan1-0/+12
The Acer TravelMate X514-51T with ALC255 cannot detect the headset MIC until ALC255_FIXUP_ACER_HEADSET_MIC quirk applied. Although, the internal DMIC uses another module - snd_soc_skl as the driver. We still need the NID 0x1a in the quirk to enable the headset MIC. Signed-off-by: Jian-Hong Pan <[email protected]> Signed-off-by: Kailang Yang <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2019-03-139p/net: fix memory leak in p9_client_createzhengbin1-1/+1
If msize is less than 4096, we should close and put trans, destroy tagpool, not just free client. This patch fixes that. Link: http://lkml.kernel.org/m/[email protected] Cc: [email protected] Fixes: 574d356b7a02 ("9p/net: put a lower bound on msize") Reported-by: Hulk Robot <[email protected]> Signed-off-by: zhengbin <[email protected]> Signed-off-by: Dominique Martinet <[email protected]>
2019-03-13ALSA: hda/tegra: avoid build error without CONFIG_PMArnd Bergmann1-8/+4
The #ifdef protection around the PM functions is wrong, leading to a failed reference in some configurations: sound/pci/hda/hda_tegra.c: In function 'hda_tegra_runtime_suspend': sound/pci/hda/hda_tegra.c:273:2: error: implicit declaration of function 'hda_tegra_disable_clocks'; did you mean 'hda_tegra_enable_clocks'? [-Werror=implicit-function-declaration] Better remove the #ifdefs entirely and rely on the compiler silently dropping unused functions marked __maybe_unused. Fixes: 707e0759f2f4 ("ALSA: hda/tegra: implement runtime suspend/resume") Acked-by: Thierry Reding <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2019-03-13ALSA: usx2y: Fix potential NULL pointer dereferenceAditya Pakki1-0/+5
usb_alloc_urb() can fail due to kmalloc failure and push the error upstream. Further this can cause a NULL pointer dereference in init_pipe_urbs(). This patch avoids such a scenario. Signed-off-by: Aditya Pakki <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2019-03-13ALSA: hda: Avoid NULL pointer dereference at snd_hdac_stream_start()Mariusz Ceier1-1/+4
For ca0132 codec, azx_dev->stream is NULL during firmware loading. Calling snd_hdac_get_stream_stripe_ctl unconditionally causes NULL pointer dereference in that function. Fixes: 9b6f7e7a296e ("ALSA: hda: program stripe bits for controller") Signed-off-by: Mariusz Ceier <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2019-03-13powerpc/64s: Include <asm/nmi.h> header file to fix a warningMathieu Malaterre1-0/+1
Make sure to include <asm/nmi.h> to provide the following prototype: hv_nmi_check_nonrecoverable. Remove the following warning treated as error (W=1): arch/powerpc/kernel/traps.c:393:6: error: no previous prototype for 'hv_nmi_check_nonrecoverable' Fixes: ccd477028a20 ("powerpc/64s: Fix HV NMI vs HV interrupt recoverability test") Signed-off-by: Mathieu Malaterre <[email protected]> Reviewed-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2019-03-13powerpc/powernv: Fix compile without CONFIG_TRACEPOINTSAlexey Kardashevskiy1-0/+1
The functions returns s64 but the return statement is missing. This adds the missing return statement. Fixes: 75d9fc7fd94e ("powerpc/powernv: move OPAL call wrapper tracing and interrupt handling to C") Signed-off-by: Alexey Kardashevskiy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2019-03-12f2fs: fix to avoid deadlock in f2fs_read_inline_dir()Chao Yu1-1/+7
As Jiqun Li reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202883 sometimes, dead lock when make system call SYS_getdents64 with fsync() is called by another process. monkey running on android9.0 1. task 9785 held sbi->cp_rwsem and waiting lock_page() 2. task 10349 held mm_sem and waiting sbi->cp_rwsem 3. task 9709 held lock_page() and waiting mm_sem so this is a dead lock scenario. task stack is show by crash tools as following crash_arm64> bt ffffffc03c354080 PID: 9785 TASK: ffffffc03c354080 CPU: 1 COMMAND: "RxIoScheduler-3" >> #7 [ffffffc01b50fac0] __lock_page at ffffff80081b11e8 crash-arm64> bt 10349 PID: 10349 TASK: ffffffc018b83080 CPU: 1 COMMAND: "BUGLY_ASYNC_UPL" >> #3 [ffffffc01f8cfa40] rwsem_down_read_failed at ffffff8008a93afc PC: 00000033 LR: 00000000 SP: 00000000 PSTATE: ffffffffffffffff crash-arm64> bt 9709 PID: 9709 TASK: ffffffc03e7f3080 CPU: 1 COMMAND: "IntentService[A" >> #3 [ffffffc001e67850] rwsem_down_read_failed at ffffff8008a93afc >> #8 [ffffffc001e67b80] el1_ia at ffffff8008084fc4 PC: ffffff8008274114 [compat_filldir64+120] LR: ffffff80083584d4 [f2fs_fill_dentries+448] SP: ffffffc001e67b80 PSTATE: 80400145 X29: ffffffc001e67b80 X28: 0000000000000000 X27: 000000000000001a X26: 00000000000093d7 X25: ffffffc070d52480 X24: 0000000000000008 X23: 0000000000000028 X22: 00000000d43dfd60 X21: ffffffc001e67e90 X20: 0000000000000011 X19: ffffff80093a4000 X18: 0000000000000000 X17: 0000000000000000 X16: 0000000000000000 X15: 0000000000000000 X14: ffffffffffffffff X13: 0000000000000008 X12: 0101010101010101 X11: 7f7f7f7f7f7f7f7f X10: 6a6a6a6a6a6a6a6a X9: 7f7f7f7f7f7f7f7f X8: 0000000080808000 X7: ffffff800827409c X6: 0000000080808000 X5: 0000000000000008 X4: 00000000000093d7 X3: 000000000000001a X2: 0000000000000011 X1: ffffffc070d52480 X0: 0000000000800238 >> #9 [ffffffc001e67be0] f2fs_fill_dentries at ffffff80083584d0 PC: 0000003c LR: 00000000 SP: 00000000 PSTATE: 000000d9 X12: f48a02ff X11: d4678960 X10: d43dfc00 X9: d4678ae4 X8: 00000058 X7: d4678994 X6: d43de800 X5: 000000d9 X4: d43dfc0c X3: d43dfc10 X2: d46799c8 X1: 00000000 X0: 00001068 Below potential deadlock will happen between three threads: Thread A Thread B Thread C - f2fs_do_sync_file - f2fs_write_checkpoint - down_write(&sbi->node_change) -- 1) - do_page_fault - down_write(&mm->mmap_sem) -- 2) - do_wp_page - f2fs_vm_page_mkwrite - getdents64 - f2fs_read_inline_dir - lock_page -- 3) - f2fs_sync_node_pages - lock_page -- 3) - __do_map_lock - down_read(&sbi->node_change) -- 1) - f2fs_fill_dentries - dir_emit - compat_filldir64 - do_page_fault - down_read(&mm->mmap_sem) -- 2) Since f2fs_readdir is protected by inode.i_rwsem, there should not be any updates in inode page, we're safe to lookup dents in inode page without its lock held, so taking off the lock to improve concurrency of readdir and avoid potential deadlock. Reported-by: Jiqun Li <[email protected]> Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
2019-03-12f2fs: fix to adapt small inline xattr space in __find_inline_xattr()Chao Yu1-3/+10
With below testcase, we will fail to find existed xattr entry: 1. mkfs.f2fs -O extra_attr -O flexible_inline_xattr /dev/zram0 2. mount -t f2fs -o inline_xattr_size=1 /dev/zram0 /mnt/f2fs/ 3. touch /mnt/f2fs/file 4. setfattr -n "user.name" -v 0 /mnt/f2fs/file 5. getfattr -n "user.name" /mnt/f2fs/file /mnt/f2fs/file: user.name: No such attribute The reason is for inode which has very small inline xattr size, __find_inline_xattr() will fail to traverse any entry due to first entry may not be loaded from xattr node yet, later, we may skip to check entire xattr datas in __find_xattr(), result in such wrong condition. This patch adds condition to check such case to avoid this issue. Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
2019-03-12f2fs: fix to do sanity check with inode.i_inline_xattr_sizeChao Yu3-4/+22
As Paul Bandha reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202709 When I run the poc on the mounted f2fs img I get a buffer overflow in read_inline_xattr due to there being no sanity check on the value of i_inline_xattr_size. I created the img by just modifying the value of i_inline_xattr_size in the inode: i_name [test1.txt] i_ext: fofs:0 blkaddr:0 len:0 i_extra_isize [0x 18 : 24] i_inline_xattr_size [0x ffff : 65535] i_addr[ofs] [0x 0 : 0] mkdir /mnt/f2fs mount ./f2fs1.img /mnt/f2fs gcc poc.c -o poc ./poc int main() { int y = syscall(SYS_listxattr, "/mnt/f2fs/test1.txt", NULL, 0); printf("ret %d", y); printf("errno: %d\n", errno); } BUG: KASAN: slab-out-of-bounds in read_inline_xattr+0x18f/0x260 Read of size 262140 at addr ffff88011035efd8 by task f2fs1poc/3263 CPU: 0 PID: 3263 Comm: f2fs1poc Not tainted 4.18.0-custom #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014 Call Trace: dump_stack+0x71/0xab print_address_description+0x83/0x250 kasan_report+0x213/0x350 memcpy+0x1f/0x50 read_inline_xattr+0x18f/0x260 read_all_xattrs+0xba/0x190 f2fs_listxattr+0x9d/0x3f0 listxattr+0xb2/0xd0 path_listxattr+0x93/0xe0 do_syscall_64+0x9d/0x220 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Let's add sanity check for inode.i_inline_xattr_size during f2fs_iget() to avoid this issue. Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
2019-03-12f2fs: give some messages for inline_xattr_sizeJaegeuk Kim1-6/+11
This patch adds some kernel messages when user sets wrong inline_xattr_size. Fixes: 500e0b28ecd3 ("f2fs: fix to check inline_xattr_size boundary correctly") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
2019-03-12f2fs: don't trigger read IO for beyond EOF pageChao Yu1-9/+8
In f2fs_mpage_readpages(), if page is beyond EOF, we should just zero out it, but previously, before checking previous mapping info, we missed to check filesize boundary, fix it. Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
2019-03-12f2fs: fix to add refcount once page is tagged PG_privateChao Yu6-23/+36
As Gao Xiang reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202749 f2fs may skip pageout() due to incorrect page reference count. The problem here is that MM defined the rule [1] very clearly that once page was set with PG_private flag, we should increment the refcount in that page, also main flows like pageout(), migrate_page() will assume there is one additional page reference count if page_has_private() returns true. But currently, f2fs won't add/del refcount when changing PG_private flag. Anyway, f2fs should follow MM's rule to make MM's related flows running as expected. [1] https://lore.kernel.org/lkml/[email protected]/ Reported-by: Gao Xiang <[email protected]> Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.