summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2019-09-04spi: spi-meson-spifc: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20190904135918.25352-17-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: meson-spicc: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20190904135918.25352-16-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: lp-8841: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-15-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: spi-geni-qcom: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-14-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: dw-mmio: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-13-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: coldfire-qspi: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-12-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: clps711x: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-11-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: octeon: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-10-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: cadence: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-9-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: bcm63xx-hsspi: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-8-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: bcm2835: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-7-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: bcm2835aux: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-6-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: spi-axi: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-5-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: ath79: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-4-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: a3700: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-3-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: altera: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-2-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04Merge tag 'usb-serial-5.4-rc1' of ↵Greg Kroah-Hartman
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next Johan writes: USB-serial updates for 5.4-rc1 Here are the USB-serial updates for 5.4-rc1, which this time is just a single commit adding support for the CBUS GPIOs on FT232H devices. This change has spent a week in linux-next with no reported issues. Signed-off-by: Johan Hovold <johan@kernel.org> * tag 'usb-serial-5.4-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: ftdi_sio: add support for FT232H CBUS gpios
2019-09-04bus: imx-weim: remove incorrect __init annotationsArnd Bergmann
The probe function is no longer __init, so anything it calls now must also be available at runtime, as Kbuild points out when building with clang-9: WARNING: vmlinux.o(.text+0x6e7040): Section mismatch in reference from the function weim_probe() to the function .init.text:imx_weim_gpr_setup() The function weim_probe() references the function __init imx_weim_gpr_setup(). This is often because weim_probe lacks a __init annotation or the annotation of imx_weim_gpr_setup is wrong. WARNING: vmlinux.o(.text+0x6e70f0): Section mismatch in reference from the function weim_probe() to the function .init.text:weim_timing_setup() The function weim_probe() references the function __init weim_timing_setup(). This is often because weim_probe lacks a __init annotation or the annotation of weim_timing_setup is wrong. Remove the remaining __init markings that are now wrong. Fixes: 4a92f07816ba ("bus: imx-weim: use module_platform_driver()") Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04fbdev: remove w90x900/nuc900 platform driversArnd Bergmann
The ARM w90x900 platform is getting removed, so this driver is obsolete. Link: https://lore.kernel.org/r/20190809202749.742267-10-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04spi: remove w90x900 driverArnd Bergmann
The ARM w90x900 platform is getting removed, so this driver is obsolete. Link: https://lore.kernel.org/r/20190809202749.742267-8-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04net: remove w90p910-ether driverArnd Bergmann
The ARM w90x900 platform is getting removed, so this driver is obsolete. Link: https://lore.kernel.org/r/20190809202749.742267-14-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04net: remove ks8695 driverArnd Bergmann
The platform is getting removed, so there are no remaining users of this driver. Link: https://lore.kernel.org/r/20190809202749.742267-6-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04drm/msm: remove unlikely() from WARN_ON() conditionsDenis Efremov
"unlikely(WARN_ON(x))" is excessive. WARN_ON() already uses unlikely() internally. Signed-off-by: Denis Efremov <efremov@linux.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: Joe Perches <joe@perches.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-arm-msm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-09-04firmware: Add Turris Mox rWTM firmware driverMarek Behún
This adds a driver to communicate with the firmware running on the secure processor of the Turris Mox router, enabling the kernel to retrieve true random numbers from the Entropy Bit Generator and to read some information burned into eFuses when device was manufactured: and to sign messages with the ECDSA private key burned into each Turris Mox device when manufacturing. This also adds support to read other information burned into eFuses: - serial number - board version - MAC addresses - RAM size - ECDSA public key (this is not read directly from eFuses, rather it is computed by the firmware as pair to the burned private key) The source code of the firmware is open source and can be found at https://gitlab.labs.nic.cz/turris/mox-boot-builder/tree/master/wtmi The firmware is also able to, on demand, sign messages with the burned ECDSA private key, but since Linux's akcipher API is not yet stable (and therefore not exposed to userspace via netlink), this functionality is not supported yet. Link: https://lore.kernel.org/r/20190822014318.19478-3-marek.behun@nic.cz Signed-off-by: Marek Behún <marek.behun@nic.cz> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04bus: moxtet: fix unsigned comparison to less than zeroColin Ian King
Currently the size_t variable res is being checked for an error failure however the unsigned variable is never less than zero so this test is always false. Fix this by making variable res ssize_t Link: https://lore.kernel.org/r/20190822010351.15660-2-marek.behun@nic.cz Addresses-Coverity: ("Unsigned compared against 0") Fixes: 5bc7f990cd98 ("bus: Add support for Moxtet bus") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Marek Behún <marek.behun@nic.cz> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04bus: moxtet: remove set but not used variable 'dummy'Jason Yan
Fixes gcc '-Wunused-but-set-variable' warning: drivers/bus/moxtet.c: In function moxtet_remove: drivers/bus/moxtet.c:822:6: warning: variable dummy set but not used [-Wunused-but-set-variable] Link: https://lore.kernel.org/r/20190822010351.15660-3-marek.behun@nic.cz Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Marek Behún <marek.behun@nic.cz> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'mvebu-dt64-5.4-2' of git://git.infradead.org/linux-mvebu into ↵Arnd Bergmann
arm/late mvebu dt64 for 5.4 (part 2) Add support for Turris Mox board (Armada 3720 SoC based) * tag 'mvebu-dt64-5.4-2' of git://git.infradead.org/linux-mvebu: (53 commits) arm64: dts: marvell: add DTS for Turris Mox dt-bindings: marvell: document Turris Mox compatible arm64: dts: marvell: armada-37xx: add SPI CS1 pinctrl arm64: dts: marvell: Add cpu clock node on Armada 7K/8K arm64: dts: marvell: Convert 7k/8k usb-phy properties to phy-supply arm64: dts: marvell: Add 7k/8k PHYs in PCIe nodes arm64: dts: marvell: Add 7k/8k PHYs in USB3 nodes arm64: dts: marvell: Add 7k/8k per-port PHYs in SATA nodes arm64: dts: marvell: Add CP110 COMPHY clocks arm64: dts: marvell: armada-37xx: add mailbox node dt-bindings: gpio: Document GPIOs via Moxtet bus drivers: gpio: Add support for GPIOs over Moxtet bus bus: moxtet: Add sysfs and debugfs documentation dt-bindings: bus: Document moxtet bus binding bus: Add support for Moxtet bus reset: Add support for resets provided by SCMI firmware: arm_scmi: Add RESET protocol in SCMI v2.0 dt-bindings: arm: Extend SCMI to support new reset protocol firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol firmware: arm_scmi: Add discovery of SCMI v2.0 performance fastchannels ... Link: https://lore.kernel.org/r/87h85two0r.fsf@FE-laptop Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'ti-k3-soc-for-v5.4' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux into arm/late Texas Instruments K3 SoC family changes for 5.4 - Typo fixes for gic-its unit addresses for both am654 and j721e - HW spinlock nodes added for both am654 and j721e - GPIO support for j721e - power-domain cells update for both am654 / j721e for exclusive only access * tag 'ti-k3-soc-for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux: arm64: dts: ti: k3-j721e-main: Fix gic-its node unit-address arm64: dts: ti: k3-am65-main: Fix gic-its node unit-address arm64: dts: ti: k3-j721e-main: Add hwspinlock node arm64: dts: ti: k3-am65-main: Add hwspinlock node arm64: dts: k3-j721e: Add gpio-keys on common processor board dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E arm64: dts: ti: k3-j721e-common-proc-board: Disable unused gpio modules arm64: dts: ti: k3-j721e: Add gpio nodes in wakeup domain arm64: dts: ti: k3-j721e: Add gpio nodes in main domain arm64: dts: ti: k3-j721e: Update the power domain cells arm64: dts: ti: k3-am654: Update the power domain cells soc: ti: ti_sci_pm_domains: Add support for exclusive and shared access dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared access firmware: ti_sci: Allow for device shared and exclusive requests Link: https://lore.kernel.org/r/b838d666-ab3b-7d41-67d4-09d606c732da@ti.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'omap-for-v5.4/ti-sysc-sgx-signed' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/late SoC glue layer changes for SGX on omap variants for v5.4 For a while we've had omap4 sgx glue layer defined in dts and probed with ti-sysc driver. This allows idling the sgx module for PM, and removes the need for custom platform glue layer code for any further driver changes. We first drop the unused legacy platform data for omap4 sgx. Then for omap5, we need add the missing clkctrl clock data so we can configure sgx. And we configure sgx for omap34xx, omap36xx and am3517. For am335x, we still have a dependency for rstctrl reset driver changes, so that will be added later on. Note that this branch is based on earlier ti-sysc branch for omap36xx glue layer quirk handling. * tag 'omap-for-v5.4/ti-sysc-sgx-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: dts: ARM: dts: Configure interconnect target module for am3517sgx ARM: dts: Configure interconnect target module for omap3 sgx ARM: dts: Configure sgx for omap5 clk: ti: add clkctrl data omap5 sgx ARM: OMAP2+: Drop legacy platform data for omap4 gpu Link: https://lore.kernel.org/r/pull-1567016893-318461@atomide.com-4 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'omap-for-v5.4/ti-sysc-part2-signed' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/late more ti-sysc driver changes for omap variants for v5.4 Few changes mostly to deal with sgx SoC glue quirk for omap36xx that is needed for the related sgx SoC glue dts branch. The other changes are to simplify sysc_check_one_child() sysc_check_children() to be void functions, and detect d2d module when debugging is enabled. * tag 'omap-for-v5.4/ti-sysc-part2-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: bus: ti-sysc: Detect d2d when debug is enabled bus: ti-sysc: Add module enable quirk for SGX on omap36xx bus: ti-sysc: Change return types of functions Link: https://lore.kernel.org/r/pull-1567016893-318461@atomide.com-2 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'omap-for-v5.4/ti-sysc-signed' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/late Driver changes for ti-sysc for v5.4 Few changes to prepare for using a reset driver for PRM rstctrl mostly to deal with the clocks for reset. Then few minor clean-up patches and SPDX license identifier changes, and add a MAINTAINERs file entry. * tag 'omap-for-v5.4/ti-sysc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: bus: ti-sysc: remove set but not used variable 'quirks' bus: ti-sysc: allow reset sharing across devices bus: ti-sysc: rework the reset handling bus: ti-sysc: re-order the clkdm control around reset handling bus: ti-sysc: Add missing kerneldoc comments bus: ti-sysc: Switch to SPDX license identifier dt-bindings: ti-sysc: Add SPDX license identifier MAINTAINERS: Add ti-sysc files under the OMAP2+ entry Link: https://lore.kernel.org/r/pull-1566599057-142651@atomide.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'davinci-for-v5.4/fbdev' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into arm/drivers This converts the da8xx fbdev driver to use GPIO backlight device and regulator devices. This will finally help get rid of legacy GPIO API calls and simplify DaVinci GPIO driver. * tag 'davinci-for-v5.4/fbdev' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci: fbdev: da8xx: use resource management for dma fbdev: da8xx-fb: drop a redundant if fbdev: da8xx-fb: use devm_platform_ioremap_resource() fbdev: da8xx: remove panel_power_ctrl() callback from platform data ARM: davinci: da850-evm: switch to using a fixed regulator for lcdc fbdev: da8xx: add support for a regulator ARM: davinci: da850-evm: model the backlight GPIO as an actual device Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04PCI: iproc: Propagate errors for optional PHYsThierry Reding
devm_phy_get() can fail for a number of reasons besides probe deferral. It can for example return -ENOMEM if it runs out of memory as it tries to allocate devres structures. Propagating only -EPROBE_DEFER is problematic because it results in these legitimately fatal errors being treated as "PHY not specified in DT". What we really want is to ignore the optional PHYs only if they have not been specified in DT. devm_phy_optional_get() is a function that exactly does what's required here, so use that instead. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: bcm-kernel-feedback-list@broadcom.com
2019-09-04PCI: histb: Propagate errors for optional regulatorsThierry Reding
regulator_get_optional() can fail for a number of reasons besides probe deferral. It can for example return -ENOMEM if it runs out of memory as it tries to allocate data structures. Propagating only -EPROBE_DEFER is problematic because it results in these legitimately fatal errors being treated as "regulator not specified in DT". What we really want is to ignore the optional regulators only if they have not been specified in DT. regulator_get_optional() returns -ENODEV in this case, so that's the special case that we need to handle. So we propagate all errors, except -ENODEV, so that real failures will still cause the driver to fail probe. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Cc: Shawn Guo <shawn.guo@linaro.org>
2019-09-04PCI: armada8x: Propagate errors for optional PHYsThierry Reding
devm_of_phy_get_by_index() can fail for a number of reasons besides probe deferral. It can for example return -ENOMEM if it runs out of memory as it tries to allocate devres structures. Propagating only -EPROBE_DEFER is problematic because it results in these legitimately fatal errors being treated as "PHY not specified in DT". What we really want is to ignore the optional PHYs only if they have not been specified in DT. devm_of_phy_get_by_index() returns -ENODEV in this case, so that's the special case that we need to handle. So we propagate all errors, except -ENODEV, so that real failures will still cause the driver to fail probe. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-09-04PCI: imx6: Propagate errors for optional regulatorsThierry Reding
regulator_get_optional() can fail for a number of reasons besides probe deferral. It can for example return -ENOMEM if it runs out of memory as it tries to allocate data structures. Propagating only -EPROBE_DEFER is problematic because it results in these legitimately fatal errors being treated as "regulator not specified in DT". What we really want is to ignore the optional regulators only if they have not been specified in DT. regulator_get_optional() returns -ENODEV in this case, so that's the special case that we need to handle. So we propagate all errors, except -ENODEV, so that real failures will still cause the driver to fail probe. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Cc: Richard Zhu <hongxing.zhu@nxp.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: kernel@pengutronix.de Cc: linux-imx@nxp.com
2019-09-04PCI: exynos: Propagate errors for optional PHYsThierry Reding
devm_of_phy_get() can fail for a number of reasons besides probe deferral. It can for example return -ENOMEM if it runs out of memory as it tries to allocate devres structures. Propagating only -EPROBE_DEFER is problematic because it results in these legitimately fatal errors being treated as "PHY not specified in DT". What we really want is to ignore the optional PHYs only if they have not been specified in DT. devm_of_phy_get() returns -ENODEV in this case, so that's the special case that we need to handle. So we propagate all errors, except -ENODEV, so that real failures will still cause the driver to fail probe. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: Krzysztof Kozlowski <krzk@kernel.org>
2019-09-04PCI: rockchip: Propagate errors for optional regulatorsThierry Reding
regulator_get_optional() can fail for a number of reasons besides probe deferral. It can for example return -ENOMEM if it runs out of memory as it tries to allocate data structures. Propagating only -EPROBE_DEFER is problematic because it results in these legitimately fatal errors being treated as "regulator not specified in DT". What we really want is to ignore the optional regulators only if they have not been specified in DT. regulator_get_optional() returns -ENODEV in this case, so that's the special case that we need to handle. So we propagate all errors, except -ENODEV, so that real failures will still cause the driver to fail probe. Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Shawn Lin <shawn.lin@rock-chips.com> Cc: Shawn Lin <shawn.lin@rock-chips.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: linux-rockchip@lists.infradead.org
2019-09-04kbuild: change *FLAGS_<basetarget>.o to take the path relative to $(obj)Masahiro Yamada
Kbuild provides per-file compiler flag addition/removal: CFLAGS_<basetarget>.o CFLAGS_REMOVE_<basetarget>.o AFLAGS_<basetarget>.o AFLAGS_REMOVE_<basetarget>.o CPPFLAGS_<basetarget>.lds HOSTCFLAGS_<basetarget>.o HOSTCXXFLAGS_<basetarget>.o The <basetarget> is the filename of the target with its directory and suffix stripped. This syntax comes into a trouble when two files with the same basename appear in one Makefile, for example: obj-y += foo.o obj-y += dir/foo.o CFLAGS_foo.o := <some-flags> Here, the <some-flags> applies to both foo.o and dir/foo.o The real world problem is: scripts/kconfig/util.c scripts/kconfig/lxdialog/util.c Both files are compiled into scripts/kconfig/mconf, but only the latter should be given with the ncurses flags. It is more sensible to use the relative path to the Makefile, like this: obj-y += foo.o CFLAGS_foo.o := <some-flags> obj-y += dir/foo.o CFLAGS_dir/foo.o := <other-flags> At first, I attempted to replace $(basetarget) with $*. The $* variable is replaced with the stem ('%') part in a pattern rule. This works with most of cases, but does not for explicit rules. For example, arch/ia64/lib/Makefile reuses rule_as_o_S in its own explicit rules, so $* will be empty, resulting in ignoring the per-file AFLAGS. I introduced a new variable, target-stem, which can be used also from explicit rules. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Marc Zyngier <maz@kernel.org>
2019-09-04Bluetooth: bpa10x: change return valueNavid Emamdoost
When returning from bpa10x_send_frame, it is necessary to propagate any potential errno returned from usb_submit_urb. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-09-04Bluetooth: hci_qca: disable irqs when spinlock is acquiredHarish Bandi
Looks like Deadlock is observed in hci_qca while performing stress and stability tests. Since same lock is getting acquired from qca_wq_awake_rx and hci_ibs_tx_idle_timeout seeing spinlock recursion, irqs should be disable while acquiring the spinlock always. Signed-off-by: Harish Bandi <c-hbandi@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-09-04Bluetooth: btrtl: Additional Realtek 8822CE Bluetooth devicesJian-Hong Pan
The ASUS X412FA laptop contains a Realtek RTL8822CE device with an associated BT chip using a USB ID of 04ca:4005. This ID is added to the driver. The /sys/kernel/debug/usb/devices portion for this device is: T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=04 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=4005 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204707 Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-09-04dm stats: use struct_size() helperGustavo A. R. Silva
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct dm_stat { ... struct dm_stat_shared stat_shared[0]; }; Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. So, replace the following form: sizeof(struct dm_stat) + (size_t)n_entries * sizeof(struct dm_stat_shared) with: struct_size(s, stat_shared, n_entries) This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2019-09-04pinctrl: qcom: sdm845: Fix UFS_RESET pinStephen Boyd
The UFS_RESET pin is the magical pin #150 now, not 153 per the sdm845_groups array declared in this file. Fix the order of pins so that UFS_RESET is 150 and the SDC pins follow after. Fixes: 53a5372ce326 ("pinctrl: qcom: sdm845: Expose ufs_reset as gpio") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20190830060227.12792-1-swboyd@chromium.org Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-09-04paride/pcd: need to check if cd->disk is null in pcd_detectzhengbin
If alloc_disk fails in pcd_init_units, cd->disk & pi are empty, we need to check if cd->disk is null in pcd_detect. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-09-04paride/pcd: need to set queue to NULL before put_diskzhengbin
In pcd_init_units, if blk_mq_init_sq_queue fails, need to set queue to NULL before put_disk, otherwise null-ptr-deref Read will occur. put_disk kobject_put disk_release blk_put_queue(disk->queue) Fixes: f0d176255401 ("paride/pcd: Fix potential NULL pointer dereference and mem leak") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-09-04paride/pf: need to set queue to NULL before put_diskzhengbin
In pf_init_units, if blk_mq_init_sq_queue fails, need to set queue to NULL before put_disk, otherwise null-ptr-deref Read will occur. put_disk kobject_put disk_release blk_put_queue(disk->queue) Fixes: 77218ddf46d8 ("paride: convert pf to blk-mq") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-09-04regulator: Defer init completion for a while after late_initcallMark Brown
The kernel has no way of knowing when we have finished instantiating drivers, between deferred probe and systems that build key drivers as modules we might be doing this long after userspace has booted. This has always been a bit of an issue with regulator_init_complete since it can power off hardware that's not had it's driver loaded which can result in user visible effects, the main case is powering off displays. Practically speaking it's not been an issue in real systems since most systems that use the regulator API are embedded and build in key drivers anyway but with Arm laptops coming on the market it's becoming more of an issue so let's do something about it. In the absence of any better idea just defer the powering off for 30s after late_initcall(), this is obviously a hack but it should mask the issue for now and it's no more arbitrary than late_initcall() itself. Ideally we'd have some heuristics to detect if we're on an affected system and tune or skip the delay appropriately, and there may be some need for a command line option to be added. Link: https://lore.kernel.org/r/20190904124250.25844-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Tested-by: Lee Jones <lee.jones@linaro.org> Cc: stable@vger.kernel.org
2019-09-04w1: add DS2501, DS2502, DS2505 EPROM device driverThomas Bogendoerfer
Add a 1-Wire slave driver to support DS250x EPROM deivces. This slave driver attaches the devices to the NVMEM subsystem for an easy in-kernel usage. Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Link: https://lore.kernel.org/r/20190831082623.15627-3-tbogendoerfer@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04w1: add 1-wire master driver for IP block found in SGI ASICsThomas Bogendoerfer
Starting with SGI Origin machines nearly every new SGI ASIC contains an 1-Wire master. They are used for attaching One-Wire prom devices, which contain information about part numbers, revision numbers, serial number etc. and MAC addresses for ethernet interfaces. This patch adds a master driver to support this IP block. It also adds an extra field dev_id to struct w1_bus_master, which could be in used in slave drivers for creating unique device names. Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Link: https://lore.kernel.org/r/20190831082623.15627-2-tbogendoerfer@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>