summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
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-04firmware: turris-mox-rwtm: Add sysfs documentationMarek Behún
Add sysfs ABI documentation for the sysfs files created by the turris-mox-rwtm driver. Link: https://lore.kernel.org/r/20190822014318.19478-4-marek.behun@nic.cz Signed-off-by: Marek Behún <marek.behun@nic.cz> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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-04dt-bindings: firmware: Document cznic,turris-mox-rwtm bindingMarek Behún
This adds device tree binding documentation for the driver communicating with the rWTM firmware on Turris Mox. Link: https://lore.kernel.org/r/20190822014318.19478-2-marek.behun@nic.cz Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Rob Herring <robh@kernel.org> 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-04arm64: defconfig: Enable Qualcomm QUSB2 PHYLee Jones
Tested on the Lenovo Yoga C630 where this patch enables USB. Without it USB devices are not enumerated. Link: https://lore.kernel.org/r/20190903192625.14775-3-lee.jones@linaro.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04arm64: defconfig: Enable the EFI FramebufferLee Jones
Tested on the Lenovo Yoga C630 where this patch enables the framebuffer (screen/monitor). Without it the device appears not to boot. Link: https://lore.kernel.org/r/20190903192625.14775-2-lee.jones@linaro.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04arm64: defconfig: Enable Qualcomm GENI based I2C controllerLee Jones
Tested on the Lenovo Yoga C630 where this patch enables the keyboard, touchpad and touchscreen. Link: https://lore.kernel.org/r/20190903192625.14775-1-lee.jones@linaro.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'arm-soc/for-5.4/devicetree' of ↵Arnd Bergmann
https://github.com/Broadcom/stblinux into arm/dt This pull request contains Broadcom ARM-based SoCs Device Tree updates for 5.4, please pull the following: - Stefan does a bunch of preparatory work for supporting the Raspberry Pi 4in the next merge window correct register ranges (SPI, I2C, UART), define memory, HDMI and MMC properties at the board level * tag 'arm-soc/for-5.4/devicetree' of https://github.com/Broadcom/stblinux: ARM: dts: bcm283x: Enable HDMI at board level ARM: dts: bcm283x: Define memory at board level ARM: dts: bcm283x: Define MMC interfaces at board level ARM: bcm283x: Reduce register ranges for UART, SPI and I2C
2019-09-04Merge tag 'qcom-drivers-for-5.4' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/defconfig Qualcomm ARM Based Driver Updates for v5.4 * Add AOSS QMP support * Various fixups for Qualcomm SCM * Add socinfo driver * Add SoC serial number attribute and associated APIs * Add SM8150 and SC7180 support in Qualcomm SCM * Fixup max processor count in SMEM * tag 'qcom-drivers-for-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: soc: qcom: aoss: Add AOSS QMP support dt-bindings: soc: qcom: aoss: Add SM8150 and SC7180 support dt-bindings: firmware: scm: Add SM8150 and SC7180 support dt-bindings: firmware: scm: re-order compatible list soc: qcom: smem: Update max processor count soc: qcom: socinfo: Annotate switch cases with fall through soc: qcom: Extend AOSS QMP driver to support resources that are used to wake up the SoC. soc: qcom: socinfo: Expose image information soc: qcom: socinfo: Expose custom attributes soc: qcom: Add socinfo driver base: soc: Export soc_device_register/unregister APIs base: soc: Add serial_number attribute to soc firmware: qcom_scm: Cleanup code in qcom_scm_assign_mem() firmware: qcom_scm: Fix some typos in docs and printks firmware: qcom_scm: Use proper types for dma mappings Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'qcom-defconfig-for-5.4' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/defconfig Qualcomm ARM Based defconfig Updates for v5.4 * Add DRM_MSM to ARCH_QCOM defconfigs * tag 'qcom-defconfig-for-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: ARM: multi_v7_defconfig: Add DRM_MSM to defconfigs with ARCH_QCOM ARM: qcom_defconfig: Add DRM_MSM to defconfigs with ARCH_QCOM
2019-09-04Merge tag 'qcom-arm64-for-5.4' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt Qualcomm ARM64 Updates for v5.4 * Add Lenovo Miix 630, HP Envy x2, and Asus Novago TP370QL support * Assorted cleanups for SDM845 nodes * Add video nodes, cpu coefficients, adsp, csdp, and fastrpc nodes for SDM845 * Add coresight for MSM8996, SDM845, and MSM8998 * Misc cleanups on QCS404 and PMS405 * Update memory map for QCS404 * Add wifi rails, update WCSS clocks, and add ADS unit names on QCS404 * Add Longcheer and Samsung Galaxy A3U/A5U support * Add initial support for SM8150 and PM8150 * tag 'qcom-arm64-for-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (39 commits) arm64: dts: sdm845: Add parent clock for rpmhcc arm64: dts: qcom: sm8150: Add apps shared nodes arm64: dts: qcom: sm8150: Add reserved-memory regions arm64: dts: qcom: sm8150-mtp: Add regulators arm64: dts: qcom: sm8150-mtp: Add base dts file arm64: dts: qcom: pm8150l: Add base dts file arm64: dts: qcom: pm8150b: Add base dts file arm64: dts: qcom: pm8150: Add base dts file arm64: dts: qcom: sm8150: Add base dts file arm64: sdm845: add adsp and cdsp fastrpc nodes arm64: dts: sdm845: Add dynamic CPU power coefficients arm64: dts: qcom: qcs404: Update memory map to v3 arm64: dts: qcom: qcs404-evb: Mark WCSS clocks protected arm64: dts: qcom: Add device tree for Longcheer L8150 arm64: dts: qcom: Add device tree for Samsung Galaxy A3U/A5U dt-bindings: qcom: Document bindings for new MSM8916 devices dt-bindings: vendor-prefixes: Add Longcheer Technology Co., Ltd. arm64: dts: qcom: msm8996: Add Venus video codec DT node arm64: dts: qcom: Extend AOSS QMP node arm64: dts: qcom: msm8996: Add Coresight support ...
2019-09-04Merge tag 'qcom-arm64-defconfig-for-5.4' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/defconfig Qualcomm ARM64 Based defconfig Updates for v5.4 * Enable Qualcomm MSM8916 clock drivers * Add DRM_MSM to ARCH_QCOM defconfigs * Enable Qualcomm SM8150 clock and pinctrl drivers * tag 'qcom-arm64-defconfig-for-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: arm64: defconfig: Enable CPU clock drivers for Qualcomm msm8916 arm64: defconfig: Add DRM_MSM to defconfigs with ARCH_QCOM arm64: defconfig: Enable SM8150 GCC and pinctrl driver
2019-09-04Merge tag 'davinci-for-v5.4/dt' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into arm/dt Contains a patch to switch to more generic compatible for SPI NOR. This helps SPI NOR to work on newer board variants. * tag 'davinci-for-v5.4/dt' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci: ARM: dts: da850-evm: Use generic jedec, spi-nor for flash 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-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-04MAINTAINERS: Add Robert as a EDAC reviewerRobert Richter
I did some significant work with code in edac_mc.c and ghes_edac.c already, so I guess I can probably help out a bit as code reviewer here. Signed-off-by: Robert Richter <rrichter@marvell.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Tony Luck <tony.luck@intel.com> Link: https://lkml.kernel.org/r/20190902123216.9809-6-rrichter@marvell.com
2019-09-04KVM: selftests: Test invalid bits in kvm_valid_regs and kvm_dirty_regs on s390xThomas Huth
Now that we disallow invalid bits in kvm_valid_regs and kvm_dirty_regs on s390x, too, we should also check this condition in the selftests. The code has been taken from the x86-version of the sync_regs_test. Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Link: https://lore.kernel.org/lkml/20190904085200.29021-3-thuth@redhat.com/ Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2019-09-04KVM: s390: Disallow invalid bits in kvm_valid_regs and kvm_dirty_regsThomas Huth
If unknown bits are set in kvm_valid_regs or kvm_dirty_regs, this clearly indicates that something went wrong in the KVM userspace application. The x86 variant of KVM already contains a check for bad bits, so let's do the same on s390x now, too. Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Link: https://lore.kernel.org/lkml/20190904085200.29021-2-thuth@redhat.com/ Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2019-09-04Merge tag 'davinci-for-v5.4/soc' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into arm/soc This converts all DaVinci SoCs except DM365 to use new clocksource driver. DM365 conversion is still under debug and will be part of a future pull request. * tag 'davinci-for-v5.4/soc' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci: ARM: davinci: dm646x: Fix a typo in the comment ARM: davinci: dm646x: switch to using the clocksource driver ARM: davinci: dm644x: switch to using the clocksource driver ARM: davinci: dm355: switch to using the clocksource driver ARM: davinci: move timer definitions to davinci.h ARM: davinci: da830: switch to using the clocksource driver ARM: davinci: da850: switch to using the clocksource driver ARM: davinci: WARN_ON() if clk_get() fails ARM: davinci: enable the clocksource driver for DT mode Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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-04Merge tag 'arm-soc/for-5.4/defconfig-arm64' of ↵Arnd Bergmann
https://github.com/Broadcom/stblinux into arm/defconfig This pull request contains Broadcom ARM64-based SoCs defconfig updates for 5.4, please pull the following: - Nicolas enables the Raspberry Pi CPUFREQ driver in the ARM64 defconfig file * tag 'arm-soc/for-5.4/defconfig-arm64' of https://github.com/Broadcom/stblinux: arm64: defconfig: enable cpufreq support for RPi3
2019-09-04Merge tag 'arm-soc/for-5.4/defconfig' of ↵Arnd Bergmann
https://github.com/Broadcom/stblinux into arm/defconfig This pull request contains Broadcom ARM-based SoCs defconfig updates for 5.4, please pull the following: - Nicolas enables the Raspberry Pi CPUFREQ driver in both bcm2835_defconfig and multi_v7_defconfig * tag 'arm-soc/for-5.4/defconfig' of https://github.com/Broadcom/stblinux: ARM: defconfig: enable cpufreq driver for RPi
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-04ASoC: soc-core: add comment to jack at soc_remove_component()Kuninori Morimoto
Basically, driver which setups snd_soc_component_set_jack() need to release it by themselves. But, as framework level robustness, soc_remove_component() also releases it. To avoid code reader confuse, this patch makes it clarify. This patch makes it clarify. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/875zm8q5n8.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04ASoC: tegra: 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/20190904083909.18804-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04ASoC: sirf-audio: 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/20190904083412.18700-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04ASoC: ep93xx: 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/20190904082507.24300-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04ASoC: amd: 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/20190904074833.23572-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04Merge tag 'bitmain-soc-5.4' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/mani/linux-bitmain into arm/dt Bitmain SoC changes for v5.4: Most of the basic infrastructure is completed for BM1880 SoC except common clock support. We are still couple of patchset away from booting a distro from eMMC/SD with mainline. Below are the changes for this cycle: - Added Reset controller support to BM1880 SoC based on reset-simple driver. - Modified pinctrl memory map for BM1880 SoC. The initial pinctrl support included the PWM registers as a part of the pinctrl memory map. But this turned out to be useless as PWM registers are not handling any pin muxing at all. So removed the PWM registers from pinctrl memory map. * tag 'bitmain-soc-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/mani/linux-bitmain: arm64: dts: bitmain: Modify pin controller memory map arm64: dts: bitmain: Add reset controller support for BM1880 SoC Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'renesas-fixes-for-v5.3' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into arm/fixes Renesas ARM Based SoC Fixes for v5.3 * R-Car D3 (r8a77995) based Draak Board - Correct backlight regulator name in device tree * tag 'renesas-fixes-for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: arm64: dts: renesas: r8a77995: draak: Fix backlight regulator name Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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>
2019-09-04powerpc/tm: Fix restoring FP/VMX facility incorrectly on interruptsGustavo Romero
When in userspace and MSR FP=0 the hardware FP state is unrelated to the current process. This is extended for transactions where if tbegin is run with FP=0, the hardware checkpoint FP state will also be unrelated to the current process. Due to this, we need to ensure this hardware checkpoint is updated with the correct state before we enable FP for this process. Unfortunately we get this wrong when returning to a process from a hardware interrupt. A process that starts a transaction with FP=0 can take an interrupt. When the kernel returns back to that process, we change to FP=1 but with hardware checkpoint FP state not updated. If this transaction is then rolled back, the FP registers now contain the wrong state. The process looks like this: Userspace: Kernel Start userspace with MSR FP=0 TM=1 < ----- ... tbegin bne Hardware interrupt ---- > <do_IRQ...> .... ret_from_except restore_math() /* sees FP=0 */ restore_fp() tm_active_with_fp() /* sees FP=1 (Incorrect) */ load_fp_state() FP = 0 -> 1 < ----- Return to userspace with MSR TM=1 FP=1 with junk in the FP TM checkpoint TM rollback reads FP junk When returning from the hardware exception, tm_active_with_fp() is incorrectly making restore_fp() call load_fp_state() which is setting FP=1. The fix is to remove tm_active_with_fp(). tm_active_with_fp() is attempting to handle the case where FP state has been changed inside a transaction. In this case the checkpointed and transactional FP state is different and hence we must restore the FP state (ie. we can't do lazy FP restore inside a transaction that's used FP). It's safe to remove tm_active_with_fp() as this case is handled by restore_tm_state(). restore_tm_state() detects if FP has been using inside a transaction and will set load_fp and call restore_math() to ensure the FP state (checkpoint and transaction) is restored. This is a data integrity problem for the current process as the FP registers are corrupted. It's also a security problem as the FP registers from one process may be leaked to another. Similarly for VMX. A simple testcase to replicate this will be posted to tools/testing/selftests/powerpc/tm/tm-poison.c This fixes CVE-2019-15031. Fixes: a7771176b439 ("powerpc: Don't enable FP/Altivec if not checkpointed") Cc: stable@vger.kernel.org # 4.15+ Signed-off-by: Gustavo Romero <gromero@linux.ibm.com> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190904045529.23002-2-gromero@linux.vnet.ibm.com
2019-09-04powerpc/tm: Fix FP/VMX unavailable exceptions inside a transactionGustavo Romero
When we take an FP unavailable exception in a transaction we have to account for the hardware FP TM checkpointed registers being incorrect. In this case for this process we know the current and checkpointed FP registers must be the same (since FP wasn't used inside the transaction) hence in the thread_struct we copy the current FP registers to the checkpointed ones. This copy is done in tm_reclaim_thread(). We use thread->ckpt_regs.msr to determine if FP was on when in userspace. thread->ckpt_regs.msr represents the state of the MSR when exiting userspace. This is setup by check_if_tm_restore_required(). Unfortunatley there is an optimisation in giveup_all() which returns early if tsk->thread.regs->msr (via local variable `usermsr`) has FP=VEC=VSX=SPE=0. This optimisation means that check_if_tm_restore_required() is not called and hence thread->ckpt_regs.msr is not updated and will contain an old value. This can happen if due to load_fp=255 we start a userspace process with MSR FP=1 and then we are context switched out. In this case thread->ckpt_regs.msr will contain FP=1. If that same process is then context switched in and load_fp overflows, MSR will have FP=0. If that process now enters a transaction and does an FP instruction, the FP unavailable will not update thread->ckpt_regs.msr (the bug) and MSR FP=1 will be retained in thread->ckpt_regs.msr. tm_reclaim_thread() will then not perform the required memcpy and the checkpointed FP regs in the thread struct will contain the wrong values. The code path for this happening is: Userspace: Kernel Start userspace with MSR FP/VEC/VSX/SPE=0 TM=1 < ----- ... tbegin bne fp instruction FP unavailable ---- > fp_unavailable_tm() tm_reclaim_current() tm_reclaim_thread() giveup_all() return early since FP/VMX/VSX=0 /* ckpt MSR not updated (Incorrect) */ tm_reclaim() /* thread_struct ckpt FP regs contain junk (OK) */ /* Sees ckpt MSR FP=1 (Incorrect) */ no memcpy() performed /* thread_struct ckpt FP regs not fixed (Incorrect) */ tm_recheckpoint() /* Put junk in hardware checkpoint FP regs */ .... < ----- Return to userspace with MSR TM=1 FP=1 with junk in the FP TM checkpoint TM rollback reads FP junk This is a data integrity problem for the current process as the FP registers are corrupted. It's also a security problem as the FP registers from one process may be leaked to another. This patch moves up check_if_tm_restore_required() in giveup_all() to ensure thread->ckpt_regs.msr is updated correctly. A simple testcase to replicate this will be posted to tools/testing/selftests/powerpc/tm/tm-poison.c Similarly for VMX. This fixes CVE-2019-15030. Fixes: f48e91e87e67 ("powerpc/tm: Fix FP and VMX register corruption") Cc: stable@vger.kernel.org # 4.12+ Signed-off-by: Gustavo Romero <gromero@linux.vnet.ibm.com> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190904045529.23002-1-gromero@linux.vnet.ibm.com
2019-09-04can: add support of SAE J1939 protocolThe j1939 authors
SAE J1939 is the vehicle bus recommended practice used for communication and diagnostics among vehicle components. Originating in the car and heavy-duty truck industry in the United States, it is now widely used in other parts of the world. J1939, ISO 11783 and NMEA 2000 all share the same high level protocol. SAE J1939 can be considered the replacement for the older SAE J1708 and SAE J1587 specifications. Acked-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Bastian Stender <bst@pengutronix.de> Signed-off-by: Elenita Hinds <ecathinds@gmail.com> Signed-off-by: kbuild test robot <lkp@intel.com> Signed-off-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> Signed-off-by: Maxime Jayat <maxime.jayat@mobile-devices.fr> Signed-off-by: Robin van der Gracht <robin@protonic.nl> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2019-09-04arm64: remove __iounmapChristoph Hellwig
No need to indirect iounmap for arm64. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Will Deacon <will@kernel.org>
2019-09-04pcmcia/i82092: Refactored dprintk macro for dev_dbg().Adam Zerella
As suggested in https://kernelnewbies.org/KernelJanitors/Todo this patch replaces the outdated macro of DPRINTK for dev_dbg() To: Dominik Brodowski <linux@dominikbrodowski.net> To: Thomas Gleixner <tglx@linutronix.de> To: Adam Zerella <adam.zerella@gmail.com> To: linux-kernel@vger.kernel.org Signed-off-by: Adam Zerella <adam.zerella@gmail.com> Link: https://lore.kernel.org/r/20190825053513.13990-1-adam.zerella@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>