summaryrefslogtreecommitdiffstats
path: root/drivers/xen (unfollow)
Commit message (Collapse)AuthorFilesLines
2020-03-25soc: fsl: qe: ucc_slow: remove 0 assignment for kzalloc'ed structureLi Yang1-7/+0
Not necessary to set to 0 for the kzalloc'ed area so remove these assignements. Signed-off-by: Li Yang <leoyang.li@nxp.com>
2020-03-25soc: fsl: qe: fix sparse warnings for ucc_fast.cLi Yang1-3/+3
Fixes the following sparse warnings: drivers/soc/fsl/qe/ucc_fast.c:218:22: warning: incorrect type in assignment (different base types) drivers/soc/fsl/qe/ucc_fast.c:218:22: expected unsigned int [noderef] [usertype] <asn:2> *p_ucce drivers/soc/fsl/qe/ucc_fast.c:218:22: got restricted __be32 [noderef] <asn:2> * drivers/soc/fsl/qe/ucc_fast.c:219:22: warning: incorrect type in assignment (different base types) drivers/soc/fsl/qe/ucc_fast.c:219:22: expected unsigned int [noderef] [usertype] <asn:2> *p_uccm drivers/soc/fsl/qe/ucc_fast.c:219:22: got restricted __be32 [noderef] <asn:2> * Signed-off-by: Li Yang <leoyang.li@nxp.com> Reviewed-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
2020-03-25soc: fsl: qe: fix sparse warnings for qe_ic.cLi Yang1-1/+1
Fixes the following sparse warnings: drivers/soc/fsl/qe/qe_ic.c:253:32: warning: incorrect type in argument 1 (different base types) drivers/soc/fsl/qe/qe_ic.c:253:32: expected restricted __be32 [noderef] [usertype] <asn:2> *base drivers/soc/fsl/qe/qe_ic.c:253:32: got unsigned int [noderef] [usertype] <asn:2> *regs drivers/soc/fsl/qe/qe_ic.c:254:26: warning: incorrect type in argument 1 (different base types) drivers/soc/fsl/qe/qe_ic.c:254:26: expected restricted __be32 [noderef] [usertype] <asn:2> *base drivers/soc/fsl/qe/qe_ic.c:254:26: got unsigned int [noderef] [usertype] <asn:2> *regs drivers/soc/fsl/qe/qe_ic.c:269:32: warning: incorrect type in argument 1 (different base types) drivers/soc/fsl/qe/qe_ic.c:269:32: expected restricted __be32 [noderef] [usertype] <asn:2> *base drivers/soc/fsl/qe/qe_ic.c:269:32: got unsigned int [noderef] [usertype] <asn:2> *regs drivers/soc/fsl/qe/qe_ic.c:270:26: warning: incorrect type in argument 1 (different base types) drivers/soc/fsl/qe/qe_ic.c:270:26: expected restricted __be32 [noderef] [usertype] <asn:2> *base drivers/soc/fsl/qe/qe_ic.c:270:26: got unsigned int [noderef] [usertype] <asn:2> *regs drivers/soc/fsl/qe/qe_ic.c:341:31: warning: incorrect type in argument 1 (different base types) drivers/soc/fsl/qe/qe_ic.c:341:31: expected restricted __be32 [noderef] [usertype] <asn:2> *base drivers/soc/fsl/qe/qe_ic.c:341:31: got unsigned int [noderef] [usertype] <asn:2> *regs drivers/soc/fsl/qe/qe_ic.c:357:31: warning: incorrect type in argument 1 (different base types) drivers/soc/fsl/qe/qe_ic.c:357:31: expected restricted __be32 [noderef] [usertype] <asn:2> *base drivers/soc/fsl/qe/qe_ic.c:357:31: got unsigned int [noderef] [usertype] <asn:2> *regs drivers/soc/fsl/qe/qe_ic.c:450:26: warning: incorrect type in argument 1 (different base types) drivers/soc/fsl/qe/qe_ic.c:450:26: expected restricted __be32 [noderef] [usertype] <asn:2> *base drivers/soc/fsl/qe/qe_ic.c:450:26: got unsigned int [noderef] [usertype] <asn:2> *regs Signed-off-by: Li Yang <leoyang.li@nxp.com> Reviewed-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
2020-03-25soc: fsl: qe: fix sparse warnings for ucc.cLi Yang1-1/+1
Fixes the following sparse warnings: drivers/soc/fsl/qe/ucc.c:637:20: warning: incorrect type in assignment (different address spaces) drivers/soc/fsl/qe/ucc.c:637:20: expected struct qe_mux *qe_mux_reg drivers/soc/fsl/qe/ucc.c:637:20: got struct qe_mux [noderef] <asn:2> * drivers/soc/fsl/qe/ucc.c:652:9: warning: incorrect type in argument 1 (different address spaces) drivers/soc/fsl/qe/ucc.c:652:9: expected void const volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc.c:652:9: got restricted __be32 * drivers/soc/fsl/qe/ucc.c:652:9: warning: incorrect type in argument 2 (different address spaces) drivers/soc/fsl/qe/ucc.c:652:9: expected void volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc.c:652:9: got restricted __be32 * Signed-off-by: Li Yang <leoyang.li@nxp.com> Reviewed-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
2020-03-25soc: fsl: qe: fix sparse warning for qe_common.cLi Yang1-1/+1
Fixes the following sparse warning: drivers/soc/fsl/qe/qe_common.c:75:48: warning: incorrect type in argument 2 (different base types) drivers/soc/fsl/qe/qe_common.c:75:48: expected restricted __be32 const [usertype] *addr drivers/soc/fsl/qe/qe_common.c:75:48: got unsigned int * Signed-off-by: Li Yang <leoyang.li@nxp.com> Reviewed-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
2020-03-25soc: fsl: qe: fix sparse warnings for qe.cLi Yang1-2/+2
Fixes the following sparse warnings: drivers/soc/fsl/qe/qe.c:426:9: warning: cast to restricted __be32 drivers/soc/fsl/qe/qe.c:528:41: warning: incorrect type in assignment (different base types) drivers/soc/fsl/qe/qe.c:528:41: expected unsigned long long static [addressable] [toplevel] [usertype] extended_modes drivers/soc/fsl/qe/qe.c:528:41: got restricted __be64 const [usertype] extended_modes Signed-off-by: Li Yang <leoyang.li@nxp.com>
2020-03-16soc: qcom: Fix QCOM_APR dependenciesBjorn Andersson1-0/+1
QCOM_APR selects QCOM_PDR_HELPERS, which in turn selects QCOM_QMI_HELPERS, which depends on NET. So ensure that APR's dependencies are met by making it depend on NET as well. Fixes: 834735662602 ("soc: qcom: apr: Add avs/audio tracking functionality") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-16soc: qcom: pdr: Avoid uninitialized use of found in pdr_indication_cbNathan Chancellor1-1/+1
Clang warns: ../drivers/soc/qcom/pdr_interface.c:316:2: warning: variable 'found' is used uninitialized whenever 'for' loop exits because its condition is false [-Wsometimes-uninitialized] list_for_each_entry(pds, &pdr->lookups, node) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../include/linux/list.h:624:7: note: expanded from macro 'list_for_each_entry' &pos->member != (head); ^~~~~~~~~~~~~~~~~~~~~~ ../drivers/soc/qcom/pdr_interface.c:325:7: note: uninitialized use occurs here if (!found) ^~~~~ ../drivers/soc/qcom/pdr_interface.c:316:2: note: remove the condition if it is always true list_for_each_entry(pds, &pdr->lookups, node) { ^ ../include/linux/list.h:624:7: note: expanded from macro 'list_for_each_entry' &pos->member != (head); ^ ../drivers/soc/qcom/pdr_interface.c:309:12: note: initialize the variable 'found' to silence this warning bool found; ^ = 0 1 warning generated. Initialize found to false to fix this warning. Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers") Link: https://github.com/ClangBuiltLinux/linux/issues/933 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Link: https://lore.kernel.org/r/20200316204855.15611-1-natechancellor@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-16soc: imx: drop COMPILE_TEST for IMX_SCU_SOCPeng Fan1-1/+1
With COMPILE_TEST, there will be build error, because IMX_SCU might be set to n, so drop COMPILE_TEST. Suggested-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-03-16firmware: imx: add COMPILE_TEST for IMX_SCU driverAnson Huang1-1/+1
Add COMPILE_TEST support to IMX_SCU driver for better compile testing coverage. Any driver depending on IMX_SCU shouldn't have COMPILE_TEST though. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-03-16soc: imx: gpc: fix power up sequencingLucas Stach1-11/+13
Currently we wait only until the PGC inverts the isolation setting before disabling the peripheral clocks. This doesn't ensure that the reset is properly propagated through the peripheral devices in the power domain. Wait until the PGC signals that the power up request is done and wait a bit for resets to propagate before disabling the clocks. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-03-16soc: imx: increase build coverage for imx8m soc driverPeng Fan4-2/+11
The soc-imx8.c driver is actually for i.MX8M family, so rename it to soc-imx8m.c. Use CONFIG_SOC_IMX8M as build gate, not CONFIG_ARCH_MXC, to control whether build this driver, also make it possible for compile test. Default set it to y for ARCH_MXC && ARM64 Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-03-15soc: qcom: apr: Add avs/audio tracking functionalitySibi Sankar3-9/+116
Use PDR helper functions to track the protection domains that the apr services are dependent upon on SDM845 SoC, specifically the "avs/audio" service running on ADSP Q6. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200312120842.21991-4-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-15dt-bindings: soc: qcom: apr: Add protection domain bindingsSibi Sankar1-0/+50
Qualcomm SoCs (starting with MSM8998) allow for multiple protection domains (PDs) to run on the same Q6 sub-system. This allows for services like AVS AUDIO to have their own separate address space and crash/recover without disrupting the other PDs running on the same Q6 ADSP. Add "qcom,protection-domain" bindings to capture the dependencies between the APR service and the PD on which the apr service runs. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200312120842.21991-3-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-15soc: qcom: Introduce Protection Domain Restart helpersSibi Sankar6-0/+1171
Qualcomm SoCs (starting with MSM8998) allow for multiple protection domains to run on the same Q6 sub-system. This allows for services like ATH10K WLAN FW to have their own separate address space and crash/recover without disrupting the modem and other PDs running on the same sub-system. The PDR helpers introduces an abstraction that allows for tracking/controlling the life cycle of protection domains running on various Q6 sub-systems. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200312120842.21991-2-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-12devicetree: bindings: firmware: add ipq806x to qcom_scmAnsuel Smith1-0/+1
Add ipq806x to compatible list in qcom_scm Documentation Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20200311130918.753-2-ansuelsmth@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-11memory: tegra: Correct debugfs clk rate-range on Tegra124Dmitry Osipenko1-0/+5
Correctly set clk rate-range if number of available timings is zero. This fixes noisy "invalid range [4294967295, 0]" error messages during boot. Fixes: 6b9acd935546 ("memory: tegra: Refashion EMC debugfs interface on Tegra124") Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-03-11memory: tegra: Correct debugfs clk rate-range on Tegra30Dmitry Osipenko1-0/+5
Correctly set clk rate-range if number of available timings is zero. This fixes noisy "invalid range [4294967295, 0]" error messages during boot. Fixes: 8cee32b40040 ("memory: tegra: Implement EMC debugfs interface on Tegra30") Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-03-11memory: tegra: Correct debugfs clk rate-range on Tegra20Dmitry Osipenko1-0/+5
Correctly set clk rate-range if number of available timings is zero. This fixes noisy "invalid range [4294967295, 0]" error messages during boot. Fixes: 8209eefa3d37 ("memory: tegra: Implement EMC debugfs interface on Tegra20") Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-03-10firmware: imx: scu-pd: add power domain for I2C and INTMUX in CM40 SSJoakim Zhang1-0/+4
Add power domain for I2C and INTMUX in CM40 SS. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-03-09soc: qcom: socinfo: Use seq_putc() if possibleStephen Boyd1-1/+1
This is a single character that we're printing out. Use seq_putc() for that to simplify the code. Cc: Vaishali Thakkar <vaishali.thakkar@linaro.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200309185123.65265-1-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-09drivers: qcom: rpmh-rsc: Use rcuidle tracepoints for rpmhStephen Boyd1-1/+1
This tracepoint is hit now that we call into the rpmh code from the cpu idle path. Let's move this to be an rcuidle tracepoint so that we avoid the RCU idle splat below ============================= WARNING: suspicious RCU usage 5.4.10 #68 Tainted: G S ----------------------------- drivers/soc/qcom/trace-rpmh.h:72 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 2, debug_locks = 1 RCU used illegally from extended quiescent state! 5 locks held by swapper/2/0: #0: ffffff81745d6ee8 (&(&genpd->slock)->rlock){+.+.}, at: genpd_lock_spin+0x1c/0x2c #1: ffffff81745da6e8 (&(&genpd->slock)->rlock/1){....}, at: genpd_lock_nested_spin+0x24/0x34 #2: ffffff8174f2ca20 (&(&genpd->slock)->rlock/2){....}, at: genpd_lock_nested_spin+0x24/0x34 #3: ffffff8174f2c300 (&(&drv->client.cache_lock)->rlock){....}, at: rpmh_flush+0x48/0x24c #4: ffffff8174f2c150 (&(&tcs->lock)->rlock){+.+.}, at: rpmh_rsc_write_ctrl_data+0x74/0x270 stack backtrace: CPU: 2 PID: 0 Comm: swapper/2 Tainted: G S 5.4.10 #68 Call trace: dump_backtrace+0x0/0x174 show_stack+0x20/0x2c dump_stack+0xc8/0x124 lockdep_rcu_suspicious+0xe4/0x104 __tcs_buffer_write+0x230/0x2d0 rpmh_rsc_write_ctrl_data+0x210/0x270 rpmh_flush+0x84/0x24c rpmh_domain_power_off+0x78/0x98 _genpd_power_off+0x40/0xc0 genpd_power_off+0x168/0x208 genpd_power_off+0x1e0/0x208 genpd_power_off+0x1e0/0x208 genpd_runtime_suspend+0x1ac/0x220 __rpm_callback+0x70/0xfc rpm_callback+0x34/0x8c rpm_suspend+0x218/0x4a4 __pm_runtime_suspend+0x88/0xac psci_enter_domain_idle_state+0x3c/0xb4 cpuidle_enter_state+0xb8/0x284 cpuidle_enter+0x38/0x4c call_cpuidle+0x3c/0x68 do_idle+0x194/0x260 cpu_startup_entry+0x24/0x28 secondary_start_kernel+0x150/0x15c Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Fixes: a65a397f2451 ("cpuidle: psci: Add support for PM domains by using genpd") Reported-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200115013751.249588-1-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-09bus: ti-sysc: Fix quirk flags for lcdc on am335xTony Lindgren1-1/+2
Commit adb72394e2ab ("ARM: OMAP2+: Drop legacy platform data for am3 lcdc") dropped legacy platform data but we never added the quirks for SWSUP_SIDLE and SWSUP_MSTANDBY for lcdc for ti-sysc driver. This breaks suspend/resume. Let's fix the issue by enabling the same quirks for ti-sysc driver as we had earlier with platform data. Fixes: adb72394e2ab ("ARM: OMAP2+: Drop legacy platform data for am3 lcdc") Fixes: 23731eac9848 ("bus: ti-sysc: Detect devices on am335x when DEBUG is enabled") Reported-by: Keerthy <j-keerthy@ti.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Tested-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04bus: ti-sysc: Add support for PRUSS SYSC typeSuman Anna2-0/+29
The PRU-ICSS present on AM33xx/AM43xx/AM57xx has a very unique SYSCFG register. The register follows the OMAP4-style SYSC_TYPE3 for Master Standby and Slave Idle, but also has two additional unique fields - STANDBY_INIT and SUB_MWAIT. The STANDBY_INIT is a control bit that is used to initiate a Standby sequence (when set) and trigger a MStandby request to the SoC's PRCM module. This same bit is also used to enable the OCP master ports (when cleared) to allow the PRU cores to access any peripherals or memory beyond the PRU subsystem. The SUB_MWAIT is a ready status field for the external access. Add support for this SYSC type. The STANDBY_INIT has to be set during suspend, without which it results in a hang in the resume sequence on AM33xx/AM43xx boards and requires a board reset to come out of the hang. Any PRU applications requiring external access are supposed to clear the STANDBY_INIT bit. Note that the PRUSS context is lost during a suspend sequence because the PRUSS module is reset and/or disabled. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> [tony@atomide.com: updated quirk define number and to use -ENODEV] Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04dt-bindings: bus: ti-sysc: Add support for PRUSS SYSC typeRoger Quadros2-0/+5
The PRUSS module has a SYSCFG which is unique. The SYSCFG has two additional unique fields called STANDBY_INIT and SUB_MWAIT in addition to regular IDLE_MODE and STANDBY_MODE fields. Add the bindings for this new sysc type. Cc: Rob Herring <robh+dt@kernel.org> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04bus: ti-sysc: Detect EDMA and set quirk flags for tptcTony Lindgren1-0/+5
In order to probe EDMA with ti-sysc interconnect target module and with device tree data, we need to properly detect EDMA and set the flags for SYSC_QUIRK_SWSUP_SIDLE | SYSC_QUIRK_SWSUP_MSTANDBY for tptc. We have these flags currently set for am4 and dra7, but not for am335x. Let's set them for all the SoCs as the tptc module should behave the same for all of them. It's likely that am335x was never tested to idle EDMA tptc. Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04soc: qcom: Do not depend on ARCH_QCOM for QMI helpersManivannan Sadhasivam1-1/+0
QMI helpers are not always used by Qualcomm platforms. One of the exceptions is the external modems available in near future. Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: linux-arm-msm@vger.kernel.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20200220095854.4804-17-manivannan.sadhasivam@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-03bus: ti-sysc: Fix wrong offset for display subsystem reset quirkTony Lindgren1-4/+4
Commit 7324a7a0d5e2 ("bus: ti-sysc: Implement display subsystem reset quirk") added support for DSS reset, but is using dispc offset also for DSS also registers as reported by Tomi Valkeinen <tomi.valkeinen@ti.com>. Also, we're not using dispc_offset for dispc IRQSTATUS register so let's fix that too. Fixes: 7324a7a0d5e2 ("bus: ti-sysc: Implement display subsystem reset quirk") Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-03dt-bindings: power: Fix dt_binding_check errorJianxin Pan1-1/+1
Missing ';' in the end of secure-monitor example node. Fixes: 165b5fb294e8 ("dt-bindings: power: add Amlogic secure power domains bindings") Reported-by: Rob Herring <robh+dt@kernel.org> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/1583164448-83438-1-git-send-email-jianxin.pan@amlogic.com
2020-03-01Linux 5.6-rc4v5.6-rc4Linus Torvalds1-1/+1
2020-03-01KVM: VMX: check descriptor table exits on instruction emulationOliver Upton1-0/+15
KVM emulates UMIP on hardware that doesn't support it by setting the 'descriptor table exiting' VM-execution control and performing instruction emulation. When running nested, this emulation is broken as KVM refuses to emulate L2 instructions by default. Correct this regression by allowing the emulation of descriptor table instructions if L1 hasn't requested 'descriptor table exiting'. Fixes: 07721feee46b ("KVM: nVMX: Don't emulate instructions in guest mode") Reported-by: Jan Kiszka <jan.kiszka@web.de> Cc: stable@vger.kernel.org Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Jim Mattson <jmattson@google.com> Signed-off-by: Oliver Upton <oupton@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-29ext4: potential crash on allocation error in ext4_alloc_flex_bg_array()Dan Carpenter1-3/+3
If sbi->s_flex_groups_allocated is zero and the first allocation fails then this code will crash. The problem is that "i--" will set "i" to -1 but when we compare "i >= sbi->s_flex_groups_allocated" then the -1 is type promoted to unsigned and becomes UINT_MAX. Since UINT_MAX is more than zero, the condition is true so we call kvfree(new_groups[-1]). The loop will carry on freeing invalid memory until it crashes. Fixes: 7c990728b99e ("ext4: fix potential race between s_flex_groups online resizing and access") Reviewed-by: Suraj Jitindar Singh <surajjs@amazon.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable@kernel.org Link: https://lore.kernel.org/r/20200228092142.7irbc44yaz3by7nb@kili.mountain Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-02-29macintosh: therm_windtunnel: fix regression when instantiating devicesWolfram Sang1-21/+31
Removing attach_adapter from this driver caused a regression for at least some machines. Those machines had the sensors described in their DT, too, so they didn't need manual creation of the sensor devices. The old code worked, though, because manual creation came first. Creation of DT devices then failed later and caused error logs, but the sensors worked nonetheless because of the manually created devices. When removing attach_adaper, manual creation now comes later and loses the race. The sensor devices were already registered via DT, yet with another binding, so the driver could not be bound to it. This fix refactors the code to remove the race and only manually creates devices if there are no DT nodes present. Also, the DT binding is updated to match both, the DT and manually created devices. Because we don't know which device creation will be used at runtime, the code to start the kthread is moved to do_probe() which will be called by both methods. Fixes: 3e7bed52719d ("macintosh: therm_windtunnel: drop using attach_adapter") Link: https://bugzilla.kernel.org/show_bug.cgi?id=201723 Reported-by: Erhard Furtner <erhard_f@mailbox.org> Tested-by: Erhard Furtner <erhard_f@mailbox.org> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org # v4.19+
2020-02-29jbd2: fix data races at struct journal_headQian Cai1-4/+4
journal_head::b_transaction and journal_head::b_next_transaction could be accessed concurrently as noticed by KCSAN, LTP: starting fsync04 /dev/zero: Can't open blockdev EXT4-fs (loop0): mounting ext3 file system using the ext4 subsystem EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null) ================================================================== BUG: KCSAN: data-race in __jbd2_journal_refile_buffer [jbd2] / jbd2_write_access_granted [jbd2] write to 0xffff99f9b1bd0e30 of 8 bytes by task 25721 on cpu 70: __jbd2_journal_refile_buffer+0xdd/0x210 [jbd2] __jbd2_journal_refile_buffer at fs/jbd2/transaction.c:2569 jbd2_journal_commit_transaction+0x2d15/0x3f20 [jbd2] (inlined by) jbd2_journal_commit_transaction at fs/jbd2/commit.c:1034 kjournald2+0x13b/0x450 [jbd2] kthread+0x1cd/0x1f0 ret_from_fork+0x27/0x50 read to 0xffff99f9b1bd0e30 of 8 bytes by task 25724 on cpu 68: jbd2_write_access_granted+0x1b2/0x250 [jbd2] jbd2_write_access_granted at fs/jbd2/transaction.c:1155 jbd2_journal_get_write_access+0x2c/0x60 [jbd2] __ext4_journal_get_write_access+0x50/0x90 [ext4] ext4_mb_mark_diskspace_used+0x158/0x620 [ext4] ext4_mb_new_blocks+0x54f/0xca0 [ext4] ext4_ind_map_blocks+0xc79/0x1b40 [ext4] ext4_map_blocks+0x3b4/0x950 [ext4] _ext4_get_block+0xfc/0x270 [ext4] ext4_get_block+0x3b/0x50 [ext4] __block_write_begin_int+0x22e/0xae0 __block_write_begin+0x39/0x50 ext4_write_begin+0x388/0xb50 [ext4] generic_perform_write+0x15d/0x290 ext4_buffered_write_iter+0x11f/0x210 [ext4] ext4_file_write_iter+0xce/0x9e0 [ext4] new_sync_write+0x29c/0x3b0 __vfs_write+0x92/0xa0 vfs_write+0x103/0x260 ksys_write+0x9d/0x130 __x64_sys_write+0x4c/0x60 do_syscall_64+0x91/0xb05 entry_SYSCALL_64_after_hwframe+0x49/0xbe 5 locks held by fsync04/25724: #0: ffff99f9911093f8 (sb_writers#13){.+.+}, at: vfs_write+0x21c/0x260 #1: ffff99f9db4c0348 (&sb->s_type->i_mutex_key#15){+.+.}, at: ext4_buffered_write_iter+0x65/0x210 [ext4] #2: ffff99f5e7dfcf58 (jbd2_handle){++++}, at: start_this_handle+0x1c1/0x9d0 [jbd2] #3: ffff99f9db4c0168 (&ei->i_data_sem){++++}, at: ext4_map_blocks+0x176/0x950 [ext4] #4: ffffffff99086b40 (rcu_read_lock){....}, at: jbd2_write_access_granted+0x4e/0x250 [jbd2] irq event stamp: 1407125 hardirqs last enabled at (1407125): [<ffffffff980da9b7>] __find_get_block+0x107/0x790 hardirqs last disabled at (1407124): [<ffffffff980da8f9>] __find_get_block+0x49/0x790 softirqs last enabled at (1405528): [<ffffffff98a0034c>] __do_softirq+0x34c/0x57c softirqs last disabled at (1405521): [<ffffffff97cc67a2>] irq_exit+0xa2/0xc0 Reported by Kernel Concurrency Sanitizer on: CPU: 68 PID: 25724 Comm: fsync04 Tainted: G L 5.6.0-rc2-next-20200221+ #7 Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019 The plain reads are outside of jh->b_state_lock critical section which result in data races. Fix them by adding pairs of READ|WRITE_ONCE(). Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Qian Cai <cai@lca.pw> Link: https://lore.kernel.org/r/20200222043111.2227-1-cai@lca.pw Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-02-29soc: amlogic: fix compile failure with MESON_SECURE_PM_DOMAINS & !MESON_SMJianxin Pan1-1/+1
When MESON_SECURE_PM_DOMAINS & !MESON_SM, there will be compile failure: .../meson-secure-pwrc.o: In function `meson_secure_pwrc_on': .../meson-secure-pwrc.c:76: undefined reference to `meson_sm_call' Fix this by adding depends on MESON_SM for MESON_SECURE_PM_DOMAINS. Fixes: b3dde5013e13 ("soc: amlogic: Add support for Secure power domains controller") Reported-by: Stephen Rothwell<sfr@canb.auug.org.au> Reported-by: patchwork-bot+linux-amlogic<patchwork-bot+linux-amlogic@kernel.org> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Stephen Rothwell<sfr@canb.auug.org.au> Link: https://lore.kernel.org/r/1581955933-69832-1-git-send-email-jianxin.pan@amlogic.com
2020-02-28tee: tee_shm_op_mmap(): use TEE_SHM_USER_MAPPEDJens Wiklander1-1/+1
tee_shm_op_mmap() uses the TEE_SHM_USER_MAPPED flag instead of the TEE_SHM_REGISTER flag to tell if a shared memory object is originating from registered user space memory. Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2020-02-28tee: remove redundant teedev in struct tee_shmJens Wiklander2-8/+3
The ctx element in struct tee_shm is always valid. So remove the now redundant teedev element. Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2020-02-28tee: don't assign shm id for private shmsJens Wiklander2-14/+20
Private shared memory object must not be referenced from user space. To guarantee that, don't assign an id to shared memory objects which are driver private. Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2020-02-28tee: remove unused tee_shm_priv_alloc()Jens Wiklander2-43/+2
tee_shm_priv_alloc() isn't useful in the current state and it's also not not used so remove it. Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2020-02-28tee: remove linked list of struct tee_shmJens Wiklander3-15/+1
Removes list_shm from struct tee_context since the linked list isn't used any longer. Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2020-02-28kvm: x86: Limit the number of "kvm: disabled by bios" messagesErwan Velu1-2/+2
In older version of systemd(219), at boot time, udevadm is called with : /usr/bin/udevadm trigger --type=devices --action=add" This program generates an echo "add" in /sys/devices/system/cpu/cpu<x>/uevent, leading to the "kvm: disabled by bios" message in case of your Bios disabled the virtualization extensions. On a modern system running up to 256 CPU threads, this pollutes the Kernel logs. This patch offers to ratelimit this message to avoid any userspace program triggering this uevent printing this message too often. This patch is only a workaround but greatly reduce the pollution without breaking the current behavior of printing a message if some try to instantiate KVM on a system that doesn't support it. Note that recent versions of systemd (>239) do not have trigger this behavior. This patch will be useful at least for some using older systemd with recent Kernels. Signed-off-by: Erwan Velu <e.velu@criteo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-28KVM: x86: avoid useless copy of cpufreq policyPaolo Bonzini1-5/+5
struct cpufreq_policy is quite big and it is not a good idea to allocate one on the stack. Just use cpufreq_cpu_get and cpufreq_cpu_put which is even simpler. Reported-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-28KVM: allow disabling -WerrorPaolo Bonzini2-1/+14
Restrict -Werror to well-tested configurations and allow disabling it via Kconfig. Reported-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-28KVM: x86: allow compiling as non-module with W=1Valdis Klētnieks2-0/+4
Compile error with CONFIG_KVM_INTEL=y and W=1: CC arch/x86/kvm/vmx/vmx.o arch/x86/kvm/vmx/vmx.c:68:32: error: 'vmx_cpu_id' defined but not used [-Werror=unused-const-variable=] 68 | static const struct x86_cpu_id vmx_cpu_id[] = { | ^~~~~~~~~~ cc1: all warnings being treated as errors When building with =y, the MODULE_DEVICE_TABLE macro doesn't generate a reference to the structure (or any code at all). This makes W=1 compiles unhappy. Wrap both in a #ifdef to avoid the issue. Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu> [Do the same for CONFIG_KVM_AMD. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-28KVM: Pre-allocate 1 cpumask variable per cpu for both pv tlb and pv ipisWanpeng Li1-12/+21
Nick Desaulniers Reported: When building with: $ make CC=clang arch/x86/ CFLAGS=-Wframe-larger-than=1000 The following warning is observed: arch/x86/kernel/kvm.c:494:13: warning: stack frame size of 1064 bytes in function 'kvm_send_ipi_mask_allbutself' [-Wframe-larger-than=] static void kvm_send_ipi_mask_allbutself(const struct cpumask *mask, int vector) ^ Debugging with: https://github.com/ClangBuiltLinux/frame-larger-than via: $ python3 frame_larger_than.py arch/x86/kernel/kvm.o \ kvm_send_ipi_mask_allbutself points to the stack allocated `struct cpumask newmask` in `kvm_send_ipi_mask_allbutself`. The size of a `struct cpumask` is potentially large, as it's CONFIG_NR_CPUS divided by BITS_PER_LONG for the target architecture. CONFIG_NR_CPUS for X86_64 can be as high as 8192, making a single instance of a `struct cpumask` 1024 B. This patch fixes it by pre-allocate 1 cpumask variable per cpu and use it for both pv tlb and pv ipis.. Reported-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Wanpeng Li <wanpengli@tencent.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-28KVM: Introduce pv check helpersWanpeng Li1-10/+24
Introduce some pv check helpers for consistency. Suggested-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Wanpeng Li <wanpengli@tencent.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-28KVM: let declaration of kvm_get_running_vcpus match implementationChristian Borntraeger1-1/+1
Sparse notices that declaration and implementation do not match: arch/s390/kvm/../../../virt/kvm/kvm_main.c:4435:17: warning: incorrect type in return expression (different address spaces) arch/s390/kvm/../../../virt/kvm/kvm_main.c:4435:17: expected struct kvm_vcpu [noderef] <asn:3> ** arch/s390/kvm/../../../virt/kvm/kvm_main.c:4435:17: got struct kvm_vcpu *[noderef] <asn:3> * Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-28KVM: SVM: allocate AVIC data structures based on kvm_amd module parameterPaolo Bonzini1-1/+2
Even if APICv is disabled at startup, the backing page and ir_list need to be initialized in case they are needed later. The only case in which this can be skipped is for userspace irqchip, and that must be done because avic_init_backing_page dereferences vcpu->arch.apic (which is NULL for userspace irqchip). Tested-by: rmuncrief@humanavance.com Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=206579 Reviewed-by: Miaohe Lin <linmiaohe@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-28bus: hisi_lpc: Fixup IO ports addresses to avoid use-after-free in host removalJohn Garry1-2/+25
Some released ACPI FW for Huawei boards describes incorrect the port IO address range for child devices, in that it tells us the IO port max range is 0x3fff for each child device, which is not correct. The address range should be [e4:e8) or similar. With this incorrect upper range, the child device IO port resources overlap. As such, the kernel thinks that the LPC host serial device is a child of the IPMI device: root@(none)$ more /proc/ioports [...] 00ffc0e3-00ffffff : hisi-lpc-ipmi.0.auto 00ffc0e3-00ffc0e3 : ipmi_si 00ffc0e4-00ffc0e4 : ipmi_si 00ffc0e5-00ffc0e5 : ipmi_si 00ffc2f7-00ffffff : serial8250.1.auto 00ffc2f7-00ffc2fe : serial root@(none)$ They should both be siblings. Note that these are logical PIO addresses, which have a direct mapping from the FW IO port ranges. This shows up as a real issue when we enable CONFIG_KASAN and CONFIG_DEBUG_TEST_DRIVER_REMOVE - we see use-after-free warnings in the host removal path: ================================================================== BUG: KASAN: use-after-free in release_resource+0x38/0xc8 Read of size 8 at addr ffff0026accdbc38 by task swapper/0/1 CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc6-00001-g68e186e77b5c-dirty #1593 Hardware name: Huawei Taishan 2180 /D03, BIOS Hisilicon D03 IT20 Nemo 2.0 RC0 03/30/2018 Call trace: dump_backtrace+0x0/0x290 show_stack+0x14/0x20 dump_stack+0xf0/0x14c print_address_description.isra.9+0x6c/0x3b8 __kasan_report+0x12c/0x23c kasan_report+0xc/0x18 __asan_load8+0x94/0xb8 release_resource+0x38/0xc8 platform_device_del.part.10+0x80/0xe0 platform_device_unregister+0x20/0x38 hisi_lpc_acpi_remove_subdev+0x10/0x20 device_for_each_child+0xc8/0x128 hisi_lpc_acpi_remove+0x4c/0xa8 hisi_lpc_remove+0xbc/0xc0 platform_drv_remove+0x3c/0x68 really_probe+0x174/0x548 driver_probe_device+0x7c/0x148 device_driver_attach+0x94/0xa0 __driver_attach+0xa4/0x110 bus_for_each_dev+0xe8/0x158 driver_attach+0x30/0x40 bus_add_driver+0x234/0x2f0 driver_register+0xbc/0x1d0 __platform_driver_register+0x7c/0x88 hisi_lpc_driver_init+0x18/0x20 do_one_initcall+0xb4/0x258 kernel_init_freeable+0x248/0x2c0 kernel_init+0x10/0x118 ret_from_fork+0x10/0x1c ... The issue here is that the kernel created an incorrect parent-child resource dependency between two devices, and references the false parent node when deleting the second child device, when it had been deleted already. Fix up the child device resources from FW to create proper IO port resource relationships for broken FW. With this, the IO port layout looks more healthy: root@(none)$ more /proc/ioports [...] 00ffc0e3-00ffc0e7 : hisi-lpc-ipmi.0.auto 00ffc0e3-00ffc0e3 : ipmi_si 00ffc0e4-00ffc0e4 : ipmi_si 00ffc0e5-00ffc0e5 : ipmi_si 00ffc2f7-00ffc2ff : serial8250.1.auto 00ffc2f7-00ffc2fe : serial Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
2020-02-27MAINTAINERS: Correct Cadence PCI driver pathLukas Bulwahn1-1/+1
de80f95ccb9c ("PCI: cadence: Move all files to per-device cadence directory") moved files of the PCI cadence drivers, but did not update the MAINTAINERS entry. Since then, ./scripts/get_maintainer.pl --self-test complains: warning: no file matches F: drivers/pci/controller/pcie-cadence* Repair the MAINTAINERS entry. Link: https://lore.kernel.org/r/20200221185402.4703-1-lukas.bulwahn@gmail.com Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-21 11:56:04 +0100