summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-05-30KVM: PPC: Book3S HV: XIVE: Fix page offset when clearing ESB pagesCédric Le Goater
Under XIVE, the ESB pages of an interrupt are used for interrupt management (EOI) and triggering. They are made available to guests through a mapping of the XIVE KVM device. When a device is passed-through, the passthru_irq helpers, kvmppc_xive_set_mapped() and kvmppc_xive_clr_mapped(), clear the ESB pages of the guest IRQ number being mapped and let the VM fault handler repopulate with the correct page. The ESB pages are mapped at offset 4 (KVM_XIVE_ESB_PAGE_OFFSET) in the KVM device mapping. Unfortunately, this offset was not taken into account when clearing the pages. This lead to issues with the passthrough devices for which the interrupts were not functional under some guest configuration (tg3 and single CPU) or in any configuration (e1000e adapter). Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-05-30KVM: PPC: Book3S HV: XIVE: Take the srcu read lock when accessing memslotsCédric Le Goater
According to Documentation/virtual/kvm/locking.txt, the srcu read lock should be taken when accessing the memslots of the VM. The XIVE KVM device needs to do so when configuring the page of the OS event queue of vCPU for a given priority and when marking the same page dirty before migration. This avoids warnings such as : [ 208.224882] ============================= [ 208.224884] WARNING: suspicious RCU usage [ 208.224889] 5.2.0-rc2-xive+ #47 Not tainted [ 208.224890] ----------------------------- [ 208.224894] ../include/linux/kvm_host.h:633 suspicious rcu_dereference_check() usage! [ 208.224896] other info that might help us debug this: [ 208.224898] rcu_scheduler_active = 2, debug_locks = 1 [ 208.224901] no locks held by qemu-system-ppc/3923. [ 208.224902] stack backtrace: [ 208.224907] CPU: 64 PID: 3923 Comm: qemu-system-ppc Kdump: loaded Not tainted 5.2.0-rc2-xive+ #47 [ 208.224909] Call Trace: [ 208.224918] [c000200cdd98fa30] [c000000000be1934] dump_stack+0xe8/0x164 (unreliable) [ 208.224924] [c000200cdd98fa80] [c0000000001aec80] lockdep_rcu_suspicious+0x110/0x180 [ 208.224935] [c000200cdd98fb00] [c0080000075933a0] gfn_to_memslot+0x1c8/0x200 [kvm] [ 208.224943] [c000200cdd98fb40] [c008000007599600] gfn_to_pfn+0x28/0x60 [kvm] [ 208.224951] [c000200cdd98fb70] [c008000007599658] gfn_to_page+0x20/0x40 [kvm] [ 208.224959] [c000200cdd98fb90] [c0080000075b495c] kvmppc_xive_native_set_attr+0x8b4/0x1480 [kvm] [ 208.224967] [c000200cdd98fca0] [c00800000759261c] kvm_device_ioctl_attr+0x64/0xb0 [kvm] [ 208.224974] [c000200cdd98fcf0] [c008000007592730] kvm_device_ioctl+0xc8/0x110 [kvm] [ 208.224979] [c000200cdd98fd10] [c000000000433a24] do_vfs_ioctl+0xd4/0xcd0 [ 208.224981] [c000200cdd98fdb0] [c000000000434724] ksys_ioctl+0x104/0x120 [ 208.224984] [c000200cdd98fe00] [c000000000434768] sys_ioctl+0x28/0x80 [ 208.224988] [c000200cdd98fe20] [c00000000000b888] system_call+0x5c/0x70 legoater@boss01:~$ Fixes: 13ce3297c576 ("KVM: PPC: Book3S HV: XIVE: Add controls for the EQ configuration") Fixes: e6714bd1671d ("KVM: PPC: Book3S HV: XIVE: Add a control to dirty the XIVE EQ pages") Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-05-30KVM: PPC: Book3S HV: XIVE: Do not clear IRQ data of passthrough interruptsCédric Le Goater
The passthrough interrupts are defined at the host level and their IRQ data should not be cleared unless specifically deconfigured (shutdown) by the host. They differ from the IPI interrupts which are allocated by the XIVE KVM device and reserved to the guest usage only. This fixes a host crash when destroying a VM in which a PCI adapter was passed-through. In this case, the interrupt is cleared and freed by the KVM device and then shutdown by vfio at the host level. [ 1007.360265] BUG: Kernel NULL pointer dereference at 0x00000d00 [ 1007.360285] Faulting instruction address: 0xc00000000009da34 [ 1007.360296] Oops: Kernel access of bad area, sig: 7 [#1] [ 1007.360303] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV [ 1007.360314] Modules linked in: vhost_net vhost iptable_mangle ipt_MASQUERADE iptable_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 tun bridge stp llc kvm_hv kvm xt_tcpudp iptable_filter squashfs fuse binfmt_misc vmx_crypto ib_iser rdma_cm iw_cm ib_cm libiscsi scsi_transport_iscsi nfsd ip_tables x_tables autofs4 btrfs zstd_decompress zstd_compress lzo_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq multipath mlx5_ib ib_uverbs ib_core crc32c_vpmsum mlx5_core [ 1007.360425] CPU: 9 PID: 15576 Comm: CPU 18/KVM Kdump: loaded Not tainted 5.1.0-gad7e7d0ef #4 [ 1007.360454] NIP: c00000000009da34 LR: c00000000009e50c CTR: c00000000009e5d0 [ 1007.360482] REGS: c000007f24ccf330 TRAP: 0300 Not tainted (5.1.0-gad7e7d0ef) [ 1007.360500] MSR: 900000000280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24002484 XER: 00000000 [ 1007.360532] CFAR: c00000000009da10 DAR: 0000000000000d00 DSISR: 00080000 IRQMASK: 1 [ 1007.360532] GPR00: c00000000009e62c c000007f24ccf5c0 c000000001510600 c000007fe7f947c0 [ 1007.360532] GPR04: 0000000000000d00 0000000000000000 0000000000000000 c000005eff02d200 [ 1007.360532] GPR08: 0000000000400000 0000000000000000 0000000000000000 fffffffffffffffd [ 1007.360532] GPR12: c00000000009e5d0 c000007fffff7b00 0000000000000031 000000012c345718 [ 1007.360532] GPR16: 0000000000000000 0000000000000008 0000000000418004 0000000000040100 [ 1007.360532] GPR20: 0000000000000000 0000000008430000 00000000003c0000 0000000000000027 [ 1007.360532] GPR24: 00000000000000ff 0000000000000000 00000000000000ff c000007faa90d98c [ 1007.360532] GPR28: c000007faa90da40 00000000000fe040 ffffffffffffffff c000007fe7f947c0 [ 1007.360689] NIP [c00000000009da34] xive_esb_read+0x34/0x120 [ 1007.360706] LR [c00000000009e50c] xive_do_source_set_mask.part.0+0x2c/0x50 [ 1007.360732] Call Trace: [ 1007.360738] [c000007f24ccf5c0] [c000000000a6383c] snooze_loop+0x15c/0x270 (unreliable) [ 1007.360775] [c000007f24ccf5f0] [c00000000009e62c] xive_irq_shutdown+0x5c/0xe0 [ 1007.360795] [c000007f24ccf630] [c00000000019e4a0] irq_shutdown+0x60/0xe0 [ 1007.360813] [c000007f24ccf660] [c000000000198c44] __free_irq+0x3a4/0x420 [ 1007.360831] [c000007f24ccf700] [c000000000198dc8] free_irq+0x78/0xe0 [ 1007.360849] [c000007f24ccf730] [c00000000096c5a8] vfio_msi_set_vector_signal+0xa8/0x350 [ 1007.360878] [c000007f24ccf7f0] [c00000000096c938] vfio_msi_set_block+0xe8/0x1e0 [ 1007.360899] [c000007f24ccf850] [c00000000096cae0] vfio_msi_disable+0xb0/0x110 [ 1007.360912] [c000007f24ccf8a0] [c00000000096cd04] vfio_pci_set_msi_trigger+0x1c4/0x3d0 [ 1007.360922] [c000007f24ccf910] [c00000000096d910] vfio_pci_set_irqs_ioctl+0xa0/0x170 [ 1007.360941] [c000007f24ccf930] [c00000000096b400] vfio_pci_disable+0x80/0x5e0 [ 1007.360963] [c000007f24ccfa10] [c00000000096b9bc] vfio_pci_release+0x5c/0x90 [ 1007.360991] [c000007f24ccfa40] [c000000000963a9c] vfio_device_fops_release+0x3c/0x70 [ 1007.361012] [c000007f24ccfa70] [c0000000003b5668] __fput+0xc8/0x2b0 [ 1007.361040] [c000007f24ccfac0] [c0000000001409b0] task_work_run+0x140/0x1b0 [ 1007.361059] [c000007f24ccfb20] [c000000000118f8c] do_exit+0x3ac/0xd00 [ 1007.361076] [c000007f24ccfc00] [c0000000001199b0] do_group_exit+0x60/0x100 [ 1007.361094] [c000007f24ccfc40] [c00000000012b514] get_signal+0x1a4/0x8f0 [ 1007.361112] [c000007f24ccfd30] [c000000000021cc8] do_notify_resume+0x1a8/0x430 [ 1007.361141] [c000007f24ccfe20] [c00000000000e444] ret_from_except_lite+0x70/0x74 [ 1007.361159] Instruction dump: [ 1007.361175] 38422c00 e9230000 712a0004 41820010 548a2036 7d442378 78840020 71290020 [ 1007.361194] 4082004c e9230010 7c892214 7c0004ac <e9240000> 0c090000 4c00012c 792a0022 Cc: stable@vger.kernel.org # v4.12+ Fixes: 5af50993850a ("KVM: PPC: Book3S HV: Native usage of the XIVE interrupt controller") Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-05-30KVM: PPC: Book3S HV: XIVE: Introduce a new mutex for the XIVE deviceCédric Le Goater
The XICS-on-XIVE KVM device needs to allocate XIVE event queues when a priority is used by the OS. This is referred as EQ provisioning and it is done under the hood when : 1. a CPU is hot-plugged in the VM 2. the "set-xive" is called at VM startup 3. sources are restored at VM restore The kvm->lock mutex is used to protect the different XIVE structures being modified but in some contexts, kvm->lock is taken under the vcpu->mutex which is not permitted by the KVM locking rules. Introduce a new mutex 'lock' for the KVM devices for them to synchronize accesses to the XIVE device structures. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-05-30drm/i915/gvt: Fix cmd length of VEB_DI_IECPGao, Fred
Fix the length value of VEB_DI_IECP. Fixes: be1da7070aea ("drm/i915/gvt: vGPU command scanner") Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Gao, Fred <fred.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-30drm/i915/gvt: refine ggtt range validationXiong Zhang
The vgpu ggtt range should be in vgpu aperture or hidden range. This patch enforce begin and end address check and guarantee both of them are in the valid range. For size=0, it will regress to vgpu_gmadr_is_valid(), will refine this usage in a later fix. Fixes: 2707e4446688 ("drm/i915/gvt: vGPU graphics memory virtualization") Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-30drm/i915/gvt: Fix vGPU CSFE_CHICKEN1_REG mmio handlerColin Xu
Enter failsafe if vgpu tries to change CSFE_CHICKEN1_REG setting which is controlled by host. Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-30drm/i915/gvt: Fix GFX_MODE handlingColin Xu
Enter failsafe if vgpu tries to change GFX_MODE controlled by host. Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-30drm/i915/gvt: Update force-to-nonpriv register whitelistColin Xu
Host prints below warning message when guest running some application: "gvt: vgpu(1) Invalid FORCE_NONPRIV write 2754 at 24f0". "gvt: vgpu(1) Invalid FORCE_NONPRIV write 28a0 at 24f0". Registers 0x2754 and 0x28a0 are required by guest so add to whitelist. Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-30drm/i915/gvt: Initialize intel_gvt_gtt_entry in stackTina Zhang
Stack struct intel_gvt_gtt_entry value needs to be initialized before being used, as the fields may contain garbage values. W/o this patch, set_ggtt_entry prints: ------------------------------------- 274.046840: set_ggtt_entry: vgpu1:set ggtt entry 0x9bed8000ffffe900 274.046846: set_ggtt_entry: vgpu1:set ggtt entry 0xe55df001 274.046852: set_ggtt_entry: vgpu1:set ggtt entry 0x9bed8000ffffe900 0x9bed8000 is the stack grabage. W/ this patch, set_ggtt_entry prints: ------------------------------------ 274.046840: set_ggtt_entry: vgpu1:set ggtt entry 0xffffe900 274.046846: set_ggtt_entry: vgpu1:set ggtt entry 0xe55df001 274.046852: set_ggtt_entry: vgpu1:set ggtt entry 0xffffe900 v2: - Initialize during declaration. (Zhenyu) Fixes: 7598e8700e9a ("drm/i915/gvt: Missed to cancel dma map for ggtt entries") Cc: stable@vger.kernel.org # v4.20+ Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Tina Zhang <tina.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-29ima: show rules with IMA_INMASK correctlyRoberto Sassu
Show the '^' character when a policy rule has flag IMA_INMASK. Fixes: 80eae209d63ac ("IMA: allow reading back the current IMA policy") Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> Cc: stable@vger.kernel.org Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2019-05-29evm: check hash algorithm passed to init_desc()Roberto Sassu
This patch prevents memory access beyond the evm_tfm array by checking the validity of the index (hash algorithm) passed to init_desc(). The hash algorithm can be arbitrarily set if the security.ima xattr type is not EVM_XATTR_HMAC. Fixes: 5feeb61183dde ("evm: Allow non-SHA1 digital signatures") Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> Cc: stable@vger.kernel.org Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2019-05-29arm64: dts: qcom: msm8998: Add rpmpd nodeSibi Sankar
Add the rpmpd node on the msm8998 and define the available levels. Reviewed-by: Jeffrey Hugo <jhugo@codeaurora.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> [bjorn: dropped use of level defines, to allow merging in parallel] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: qcs404: Add rpmpd nodeBjorn Andersson
Add the rpmpd node on the qcs404 and define the available levels. Reviewed-by: Jeffrey Hugo <jhugo@codeaurora.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> [sibis: fixup available levels] Signed-off-by: Sibi Sankar <sibis@codeaurora.org> [bjorn: dropped use of level defines, to allow merging in parallel] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: qcs404: Move lpass and q6 into socBjorn Andersson
Although we don't describe lpass and wcss with all the details needed to control them in a Trustzone-less environment, move them under soc in order to tidy up the structure and prepare for describing them fully. Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: qcs404: Fully describe the CDSPBjorn Andersson
Add all the properties needed to describe the CDSP for both the Trustzone and non-Trustzone based remoteproc case, allowing any child devices to be described once by just overriding the compatible to match the firmware available on the board. Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: qcs404: Add TCSR nodeBjorn Andersson
The bus halt registers in TCSR are referenced as a syscon device, add these so that we can reference them from the remoteproc nodes. Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: qcs404-evb: Mark CDSP clocks protectedBjorn Andersson
With the Trustzone based CDSP remoteproc driver these clocks are controlled elsewhere and as they are not enabled by anything in Linux the clock framework will turn them off during lateinit. This results in issues either to later start the CDSP, using the Trustzone interface, or if the CDSP is already running it will crash. Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: sdm845: Add PSCI cpuidle low power statesRaju P.L.S.S.S.N
Add device bindings for cpuidle states for cpu devices. Cc: <mkshah@codeaurora.org> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Raju P.L.S.S.S.N <rplsssn@codeaurora.org> [amit: rename the idle-states to more generic names and fixups] Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: msm8996: Add proper capacity scaling for the cpusAmit Kucheria
msm8996 features 4 cpus - 2 in each cluster. However, all cpus implement the same microarchitecture and the two clusters only differ in the maximum frequency attainable by the CPUs. Add capacity-dmips-mhz property to allow the topology code to determine the actual capacity by taking into account the highest frequency for each CPU. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Suggested-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: msm8996: Add PSCI cpuidle low power statesAmit Kucheria
Add device bindings for cpuidle states for cpu devices. msm8996 features 4 cpus - 2 in each cluster. However, all cpus implement the same microarchitecture and the two clusters only differ in the maximum frequency attainable by the CPUs. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: msm8916: Use more generic idle state namesAmit Kucheria
Instead of using Qualcomm-specific terminology, use generic node names for the idle states that are easier to understand. Move the description into the "idle-state-name" property. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: msm8916: Add entry-method property for the idle-states nodeAmit Kucheria
The idle-states binding documentation[1] mentions that the 'entry-method' property is required on 64-bit platforms and must be set to "psci". [1] Documentation/devicetree/bindings/arm/idle-states.txt (see idle-states node) Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: qcs404: Add turingcc nodeBjorn Andersson
Add a node describing the Turing Clock Controller of the QCS404. Given the default access restriction the node is left disabled. Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: qcs404: Add PSCI cpuidle low power statesNiklas Cassel
Add device bindings for cpuidle states for cpu devices. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org> [amit: rename the idle-states to more generic names and fixups] Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: sdm845: Add zap shader region for GPUJordan Crouse
Some Adreno GPU targets require a special zap shader to bring the GPU out of secure mode. Define a region to allocate and store the zap shader. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> [bjorn: Rebase ontop of recent reserved-memory patch] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: sdm845: Add gpu and gmu device nodesJordan Crouse
Add the nodes to describe the Adreno GPU and GMU devices for sdm845. Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> [bjorn: Added required gx power-domain] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: sdm845-mtp: Make USB1 peripheralBjorn Andersson
The MTP is a "mobile reference device", as such the default operation is to use fastboot to boot/flash software onto it and the common case is thereby that we boot with a USB cable connected downstream from a PC or a hub. And without support for the PMI8998 charger block VBUS will not be driven by the device. Switch to peripheral until we can enable OTG. Reviewed-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: qcs404-evb: increase s3 max voltageNiklas Cassel
Increase s3 max voltage in accordance to QCS404 CPR Fusing Guide Rev 6.0 Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: qcs404-evb: fix l3 min voltageNiklas Cassel
The current l3 min voltage level is not supported by the regulator (the voltage is not a multiple of the regulator step size), so a driver requesting this exact voltage would fail, see discussion in: https://patchwork.kernel.org/comment/22461199/ It was agreed upon to set a min voltage level that is a multiple of the regulator step size. There was actually a patch sent that did this: https://patchwork.kernel.org/patch/10819313/ However, the commit 331ab98f8c4a ("arm64: dts: qcom: qcs404: Fix voltages l3") that was applied is not identical to that patch. Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: pms405: Rename adc outputs as per schematicsAmit Kucheria
The adc outputs shouldn't contain information about their configuration e.g. 100K pull-up, but just reflect the name of the signal in the schematics. Making them labels also allows us to overwrite their configuration in board-specific DTs. Sort them by order as used in adc5_chans_rev2, while we're at it. Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: pms405: calibrate the VADC correctlyAmit Kucheria
Set the qcom,ratiometric property to make the VADC use the VDD reference (1.875V) and GND for channel calibration of the temperature channels instead of 1.25V. Allow a 200us delay between the AMUX configuration and ADC starting conversion using qcom,hw-settle-time as described in documentation. Fixes: 041b9a7b9fdb ("arm64: dts: pms405: Export PMIC temperature to thermal framework") Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: sdm845: Fix up CPU topologyAmit Kucheria
SDM845 implements ARM's Dynamiq architecture that allows the big and LITTLE cores to exist in a single cluster sharing the L3 cache. Fix the cpu-map to put all cpus into a single cluster. Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: qcom: qcs404-evb: Fix typoVinod Koul
Fix the typo "dreive-strength" and use correct property drive-strength Fixes: 7241ab944da3 ("arm64: dts: qcom: qcs404: Add sdcc1 node") Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29arm64: dts: msm8996: Add UFS PHY reset controllerEvan Green
Add the reset controller for the UFS controller, and wire it up so that the UFS PHY can initialize itself without relying on implicit sequencing between the two drivers. Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Evan Green <evgreen@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-05-29scsi: libsas: delete sas port if expander discover failedJason Yan
The sas_port(phy->port) allocated in sas_ex_discover_expander() will not be deleted when the expander failed to discover. This will cause resource leak and a further issue of kernel BUG like below: [159785.843156] port-2:17:29: trying to add phy phy-2:17:29 fails: it's already part of another port [159785.852144] ------------[ cut here ]------------ [159785.856833] kernel BUG at drivers/scsi/scsi_transport_sas.c:1086! [159785.863000] Internal error: Oops - BUG: 0 [#1] SMP [159785.867866] CPU: 39 PID: 16993 Comm: kworker/u96:2 Tainted: G W OE 4.19.25-vhulk1901.1.0.h111.aarch64 #1 [159785.878458] Hardware name: Huawei Technologies Co., Ltd. Hi1620EVBCS/Hi1620EVBCS, BIOS Hi1620 CS B070 1P TA 03/21/2019 [159785.889231] Workqueue: 0000:74:02.0_disco_q sas_discover_domain [159785.895224] pstate: 40c00009 (nZcv daif +PAN +UAO) [159785.900094] pc : sas_port_add_phy+0x188/0x1b8 [159785.904524] lr : sas_port_add_phy+0x188/0x1b8 [159785.908952] sp : ffff0001120e3b80 [159785.912341] x29: ffff0001120e3b80 x28: 0000000000000000 [159785.917727] x27: ffff802ade8f5400 x26: ffff0000681b7560 [159785.923111] x25: ffff802adf11a800 x24: ffff0000680e8000 [159785.928496] x23: ffff802ade8f5728 x22: ffff802ade8f5708 [159785.933880] x21: ffff802adea2db40 x20: ffff802ade8f5400 [159785.939264] x19: ffff802adea2d800 x18: 0000000000000010 [159785.944649] x17: 00000000821bf734 x16: ffff00006714faa0 [159785.950033] x15: ffff0000e8ab4ecf x14: 7261702079646165 [159785.955417] x13: 726c612073277469 x12: ffff00006887b830 [159785.960802] x11: ffff00006773eaa0 x10: 7968702079687020 [159785.966186] x9 : 0000000000002453 x8 : 726f702072656874 [159785.971570] x7 : 6f6e6120666f2074 x6 : ffff802bcfb21290 [159785.976955] x5 : ffff802bcfb21290 x4 : 0000000000000000 [159785.982339] x3 : ffff802bcfb298c8 x2 : 337752b234c2ab00 [159785.987723] x1 : 337752b234c2ab00 x0 : 0000000000000000 [159785.993108] Process kworker/u96:2 (pid: 16993, stack limit = 0x0000000072dae094) [159786.000576] Call trace: [159786.003097] sas_port_add_phy+0x188/0x1b8 [159786.007179] sas_ex_get_linkrate.isra.5+0x134/0x140 [159786.012130] sas_ex_discover_expander+0x128/0x408 [159786.016906] sas_ex_discover_dev+0x218/0x4c8 [159786.021249] sas_ex_discover_devices+0x9c/0x1a8 [159786.025852] sas_discover_root_expander+0x134/0x160 [159786.030802] sas_discover_domain+0x1b8/0x1e8 [159786.035148] process_one_work+0x1b4/0x3f8 [159786.039230] worker_thread+0x54/0x470 [159786.042967] kthread+0x134/0x138 [159786.046269] ret_from_fork+0x10/0x18 [159786.049918] Code: 91322300 f0004402 91178042 97fe4c9b (d4210000) [159786.056083] Modules linked in: hns3_enet_ut(OE) hclge(OE) hnae3(OE) hisi_sas_test_hw(OE) hisi_sas_test_main(OE) serdes(OE) [159786.067202] ---[ end trace 03622b9e2d99e196 ]--- [159786.071893] Kernel panic - not syncing: Fatal exception [159786.077190] SMP: stopping secondary CPUs [159786.081192] Kernel Offset: disabled [159786.084753] CPU features: 0x2,a2a00a38 Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver") Reported-by: Jian Luo <luojian5@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> CC: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-05-29scsi: libsas: only clear phy->in_shutdown after shutdown event doneJason Yan
When the event queue is full of phy up and down events and reached the threshold, we will queue a shutdown-event, and set phy->in_shutdown so that we will not queue a shutdown-event again. But before the shutdown-event can be executed, every phy-down event will clear phy->in_shutdown and a new shutdown-event will be queued. The queue will be full of these shutdown-events. Fix this by only clear phy->in_shutdown in sas_phye_shutdown(), that is after the first shutdown-event has been executed. Fixes: f12486e06ae8 ("scsi: libsas: shut down the PHY if events reached the threshold") Signed-off-by: Jason Yan <yanaijie@huawei.com> CC: John Garry <john.garry@huawei.com> CC: Johannes Thumshirn <jthumshirn@suse.de> CC: Ewan Milne <emilne@redhat.com> CC: Christoph Hellwig <hch@lst.de> CC: Tomas Henzl <thenzl@redhat.com> CC: Dan Williams <dan.j.williams@intel.com> CC: Hannes Reinecke <hare@suse.com> Reviewed-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-05-29scsi: scsi_dh_alua: Fix possible null-ptr-derefYueHaibing
If alloc_workqueue fails in alua_init, it should return -ENOMEM, otherwise it will trigger null-ptr-deref while unloading module which calls destroy_workqueue dereference wq->lock like this: BUG: KASAN: null-ptr-deref in __lock_acquire+0x6b4/0x1ee0 Read of size 8 at addr 0000000000000080 by task syz-executor.0/7045 CPU: 0 PID: 7045 Comm: syz-executor.0 Tainted: G C 5.1.0+ #28 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 Call Trace: dump_stack+0xa9/0x10e __kasan_report+0x171/0x18d ? __lock_acquire+0x6b4/0x1ee0 kasan_report+0xe/0x20 __lock_acquire+0x6b4/0x1ee0 lock_acquire+0xb4/0x1b0 __mutex_lock+0xd8/0xb90 drain_workqueue+0x25/0x290 destroy_workqueue+0x1f/0x3f0 __x64_sys_delete_module+0x244/0x330 do_syscall_64+0x72/0x2a0 entry_SYSCALL_64_after_hwframe+0x49/0xbe Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 03197b61c5ec ("scsi_dh_alua: Use workqueue for RTPG") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-05-29scsi: smartpqi: properly set both the DMA mask and the coherent DMA maskLianbo Jiang
When SME is enabled, the smartpqi driver won't work on the HP DL385 G10 machine, which causes the failure of kernel boot because it fails to allocate pqi error buffer. Please refer to the kernel log: .... [ 9.431749] usbcore: registered new interface driver uas [ 9.441524] Microsemi PQI Driver (v1.1.4-130) [ 9.442956] i40e 0000:04:00.0: fw 6.70.48768 api 1.7 nvm 10.2.5 [ 9.447237] smartpqi 0000:23:00.0: Microsemi Smart Family Controller found Starting dracut initqueue hook... [ OK ] Started Show Plymouth Boot Scre[ 9.471654] Broadcom NetXtreme-C/E driver bnxt_en v1.9.1 en. [ OK ] Started Forward Password Requests to Plymouth Directory Watch. [[0;[ 9.487108] smartpqi 0000:23:00.0: failed to allocate PQI error buffer .... [ 139.050544] dracut-initqueue[949]: Warning: dracut-initqueue timeout - starting timeout scripts [ 139.589779] dracut-initqueue[949]: Warning: dracut-initqueue timeout - starting timeout scripts Basically, the fact that the coherent DMA mask value wasn't set caused the driver to fall back to SWIOTLB when SME is active. For correct operation, lets call the dma_set_mask_and_coherent() to properly set the mask for both streaming and coherent, in order to inform the kernel about the devices DMA addressing capabilities. Signed-off-by: Lianbo Jiang <lijiang@redhat.com> Acked-by: Don Brace <don.brace@microsemi.com> Tested-by: Don Brace <don.brace@microsemi.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-05-29scsi: zfcp: fix to prevent port_remove with pure auto scan LUNs (only sdevs)Steffen Maier
When the user tries to remove a zfcp port via sysfs, we only rejected it if there are zfcp unit children under the port. With purely automatically scanned LUNs there are no zfcp units but only SCSI devices. In such cases, the port_remove erroneously continued. We close the port and this implicitly closes all LUNs under the port. The SCSI devices survive with their private zfcp_scsi_dev still holding a reference to the "removed" zfcp_port (still allocated but invisible in sysfs) [zfcp_get_port_by_wwpn in zfcp_scsi_slave_alloc]. This is not a problem as long as the fc_rport stays blocked. Once (auto) port scan brings back the removed port, we unblock its fc_rport again by design. However, there is no mechanism that would recover (open) the LUNs under the port (no "ersfs_3" without zfcp_unit [zfcp_erp_strategy_followup_success]). Any pending or new I/O to such LUN leads to repeated: Done: NEEDS_RETRY Result: hostbyte=DID_IMM_RETRY driverbyte=DRIVER_OK See also v4.10 commit 6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race with LUN recovery"). Even a manual LUN recovery (echo 0 > /sys/bus/scsi/devices/H:C:T:L/zfcp_failed) does not help, as the LUN links to the old "removed" port which remains to lack ZFCP_STATUS_COMMON_RUNNING [zfcp_erp_required_act]. The only workaround is to first ensure that the fc_rport is blocked (e.g. port_remove again in case it was re-discovered by (auto) port scan), then delete the SCSI devices, and finally re-discover by (auto) port scan. The port scan includes an fc_rport unblock, which in turn triggers a new scan on the scsi target to freshly get new pure auto scan LUNs. Fix this by rejecting port_remove also if there are SCSI devices (even without any zfcp_unit) under this port. Re-use mechanics from v3.7 commit d99b601b6338 ("[SCSI] zfcp: restore refcount check on port_remove"). However, we have to give up zfcp_sysfs_port_units_mutex earlier in unit_add to prevent a deadlock with scsi_host scan taking shost->scan_mutex first and then zfcp_sysfs_port_units_mutex now in our zfcp_scsi_slave_alloc(). Signed-off-by: Steffen Maier <maier@linux.ibm.com> Fixes: b62a8d9b45b9 ("[SCSI] zfcp: Use SCSI device data zfcp scsi dev instead of zfcp unit") Fixes: f8210e34887e ("[SCSI] zfcp: Allow midlayer to scan for LUNs when running in NPIV mode") Cc: <stable@vger.kernel.org> #2.6.37+ Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-05-29scsi: zfcp: fix missing zfcp_port reference put on -EBUSY from port_removeSteffen Maier
With this early return due to zfcp_unit child(ren), we don't use the zfcp_port reference from the earlier zfcp_get_port_by_wwpn() anymore and need to put it. Signed-off-by: Steffen Maier <maier@linux.ibm.com> Fixes: d99b601b6338 ("[SCSI] zfcp: restore refcount check on port_remove") Cc: <stable@vger.kernel.org> #3.7+ Reviewed-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-05-29scsi: libcxgbi: add a check for NULL pointer in cxgbi_check_route()Varun Prakash
ip_dev_find() can return NULL so add a check for NULL pointer. Signed-off-by: Varun Prakash <varun@chelsio.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-05-30Merge branch 'drm-fixes-5.2' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-fixes - Respin the Raven DMCU patch with the ifdef fixed - Fix for a clean display when loading the driver on Raven Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190529170347.3272-1-alexander.deucher@amd.com
2019-05-30Merge tag 'drm-misc-fixes-2019-05-29' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes qxl: Drop WARN when u/s tries to mmap a prime buffer (Gerd) Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20190529211833.GA195708@art_vandelay
2019-05-30Merge branch 'etnaviv/fixes' of https://git.pengutronix.de/git/lst/linux ↵Dave Airlie
into drm-fixes etnaviv core dump locking fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/1558966666.4039.4.camel@pengutronix.de
2019-05-29Merge tag 'docs-5.2-fixes2' of git://git.lwn.net/linuxLinus Torvalds
Pull documentation fixes from Jonathan Corbet: "The Sphinx 2.0 release contained a few incompatible API changes that broke our extensions and, thus, the documentation build in general. Who knew that those deprecation warnings it was outputting actually meant we should change something? This set of fixes makes the build work again with Sphinx 2.0 and eliminates the warnings for 1.8. As part of that, we also need a few fixes to the docs for places where the new Sphinx is more strict. It is a bit late in the cycle for this kind of change, but it does fix problems that people are experiencing now. There has been some talk of raising the minimum version of Sphinx we support. I don't want to do that abruptly, though, so these changes add some glue to continue to support versions back to 1.3. We will be adding some infrastructure soon to nudge users of old versions forward, with the idea of maybe increasing our minimum version (and removing this glue) sometime in the future" * tag 'docs-5.2-fixes2' of git://git.lwn.net/linux: drm/i915: Maintain consistent documentation subsection ordering scripts/sphinx-pre-install: make it handle Sphinx versions docs: Fix conf.py for Sphinx 2.0 docs: fix multiple doc build warnings in enumeration.rst lib/list_sort: fix kerneldoc build error docs: fix numaperf.rst and add it to the doc tree doc: Cope with the deprecation of AutoReporter doc: Cope with Sphinx logging deprecations
2019-05-29Merge branch 'net-phy-dp83867-add-some-fixes'David S. Miller
Max Uvarov says: ==================== net: phy: dp83867: add some fixes v3: use phy_modify_mmd() v2: fix minor comments by Heiner Kallweit and Florian Fainelli ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-29net: phy: dp83867: Set up RGMII TX delayMax Uvarov
PHY_INTERFACE_MODE_RGMII_RXID is less then TXID so code to set tx delay is never called. Fixes: 2a10154abcb75 ("net: phy: dp83867: Add TI dp83867 phy") Signed-off-by: Max Uvarov <muvarov@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-29net: phy: dp83867: do not call config_init twiceMax Uvarov
Phy state machine calls _config_init just after reset. Signed-off-by: Max Uvarov <muvarov@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-29net: phy: dp83867: increase SGMII autoneg timer durationMax Uvarov
After reset SGMII Autoneg timer is set to 2us (bits 6 and 5 are 01). That is not enough to finalize autonegatiation on some devices. Increase this timer duration to maximum supported 16ms. Signed-off-by: Max Uvarov <muvarov@gmail.com> Cc: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit (git 2.34.1) at 2025-09-23 08:18:38 +0000