| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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>
|
|
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
|
|
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
...
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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>
|
|
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
|
|
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
|
|
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
|
|
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>
|
|
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>
|
|
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
|
|
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
|
|
No need to indirect iounmap for arm64.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
There is no reason to print warnings when balloon page allocation fails,
as they are expected and can be handled gracefully. Since VMware
balloon now uses balloon-compaction infrastructure, and suppressed these
warnings before, it is also beneficial to suppress these warnings to
keep the same behavior that the balloon had before.
Cc: Jason Wang <jasowang@redhat.com>
Signed-off-by: Nadav Amit <namit@vmware.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
|
|
This reverts commit 7f466032dc ("vhost: access vq metadata through
kernel virtual address"). The commit caused a bunch of issues, and
while commit 73f628ec9e ("vhost: disable metadata prefetch
optimization") disabled the optimization it's not nice to keep lots of
dead code around.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
|
|
It is unnecessary to use ret variable to return the error
code, just return the error code directly.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
|
|
This change lowers ring buffer reclaim threshold from 1/2*queue to budget
for better performance. According to our test with qemu + dpdk, packet
dropping happens when the guest is not able to provide free buffer in
avail ring timely with default 1/2*queue. The value in the patch has been
tested and does show better performance.
Test setup: iperf3 to generate packets to guest (total 30mins, pps 400k, UDP)
avg packets drop before: 2842
avg packets drop after: 360(-87.3%)
Further, current code suffers from a starvation problem: the amount of
work done by try_fill_recv is not bounded by the budget parameter, thus
(with large queues) once in a while userspace gets blocked for a long
time while queue is being refilled. Trigger refills earlier to make sure
the amount of work to do is limited.
Signed-off-by: jiangkidd <jiangkidd@hotmail.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
|
|
Since vhost_exceeds_weight() was introduced, callers need to specify
the packet weight and byte weight in vhost_dev_init(). Note that, the
packet weight isn't counted in this patch to keep the original behavior
unchanged.
Fixes: e82b9b0727ff ("vhost: introduce vhost_exceeds_weight()")
Cc: stable@vger.kernel.org
Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
|
|
Since below commit, callers need to specify the iov_limit in
vhost_dev_init() explicitly.
Fixes: b46a0bf78ad7 ("vhost: fix OOB in get_rx_bufs()")
Cc: stable@vger.kernel.org
Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
|
|
Debug messages are inconsistently used in the error handlers. Some lack
an error message, some are called regardless of the return status,
messages for the same error are at different locations in the code
depending on the error code. This happens esp. near put_device() calls.
Make those debug messages more consistent. Additionally, unify the error
messages to have the same terms for the same operations of the device.
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-5-rrichter@marvell.com
|
|
It is confusing to name return variables mixedly "status",
"err" or "ret". I just changed them all to "ret", by personal
preference, to lower cognitive stress.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190716115854.12098-1-linus.walleij@linaro.org
|
|
It is confusing to name return variables mixedly "status",
"err" or "ret". I just changed them all to "ret", by personal
preference, to lower cognitive stress.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190716091145.8235-1-linus.walleij@linaro.org
|
