- 15 Mar, 2023 26 commits
-
-
Elliot Berman authored
The maximum VMID for assign_mem is 63. Use a u64 to represent this bitmap instead of architecture-dependent "unsigned int" which varies in size on 32-bit and 64-bit platforms. Acked-by: Kalle Valo <kvalo@kernel.org> (ath10k) Tested-by:
Gokul krishna Krishnakumar <quic_gokukris@quicinc.com> Signed-off-by:
Elliot Berman <quic_eberman@quicinc.com> Reviewed-by:
Bjorn Andersson <andersson@kernel.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230213181832.3489174-1-quic_eberman@quicinc.com
-
Kathiravan T authored
Document the compatible for IPQ5332 SCM. Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Kathiravan T <quic_kathirav@quicinc.com> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230307062232.4889-8-quic_kathirav@quicinc.com
-
Poovendhan Selvaraj authored
Add the scm compatible string for IPQ9574 SoC Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Poovendhan Selvaraj <quic_poovendh@quicinc.com> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230216120012.28357-2-quic_poovendh@quicinc.com
-
Konrad Dybcio authored
It goes without saying that socname_rpmpds[] is the array of the RPM power domains associated with socname. Remove these comments. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230313-topic-rpmpd-v3-10-06a4f448ff90@linaro.org
-
Konrad Dybcio authored
The GPU core clock requires that both VDDGX and VDDMX domains are scaled at the same rate at the same time (well, MX just before GX but you get the idea). Set MX as parent of GX to take care of that. Suggested-by:
Bjorn Andersson <andersson@kernel.org> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230313-topic-rpmpd-v3-9-06a4f448ff90@linaro.org
-
Konrad Dybcio authored
In some cases (like with the GPU core clock on GMU-less SoCs) it's required that we scale more than one voltage domain. This can be achieved by linking them in a parent-child relationship. Add support for specifying a parent PD, similarly to what has been done in the RPMhPD driver. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230313-topic-rpmpd-v3-8-06a4f448ff90@linaro.org
-
Konrad Dybcio authored
Currently the whitespace between [DT_BINDING] = &struct is all over the place.. some SoC structs have a space, others have a tab, others have N tabs.. Make that a single tab for everybody to keep things coherent. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230313-topic-rpmpd-v3-7-06a4f448ff90@linaro.org
-
Konrad Dybcio authored
Now that we aren't bound by the preprocessor macros, improve the naming to be a bit less preprocessor-y and touch up some rpmpd.pd.name fields while at it. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230313-topic-rpmpd-v3-6-06a4f448ff90@linaro.org
-
Konrad Dybcio authored
Expand the struct definition macros to make things easier to see and maintain. Now that the macros are unnecessary, remove them. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230313-topic-rpmpd-v3-5-06a4f448ff90@linaro.org
-
Konrad Dybcio authored
It's rather obvious by the characteristic of these resources that they correspond to some voltage lines governed by RPM. Remove the "vdd" unnecessary prefix from them. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230313-topic-rpmpd-v3-4-06a4f448ff90@linaro.org
-
Konrad Dybcio authored
Up until now, we had 2 separate entries for VDD_LPI[CM]X and VDD_LPI_[CM]X which both pointed to the same RPM resource. Fix it. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230313-topic-rpmpd-v3-3-06a4f448ff90@linaro.org
-
Konrad Dybcio authored
Keep all definitions in one place in preparation for a cleanup to make things tidier. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230313-topic-rpmpd-v3-2-06a4f448ff90@linaro.org
-
Konrad Dybcio authored
Replace the SoC names with type+id_key (or type+id+..name..+key for fixed-key definitions) and remove duplicate entries. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230313-topic-rpmpd-v3-1-06a4f448ff90@linaro.org
-
David Wronek authored
Add Soc ID table entries for Qualcomm SM7150. Signed-off-by:
David Wronek <davidwronek@gmail.com> Signed-off-by:
Danila Tikhonov <danila@jiaxyga.com> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230305191745.386862-3-danila@jiaxyga.com
-
David Wronek authored
Add the ID for the Qualcomm SM7150 SoC. Signed-off-by:
David Wronek <davidwronek@gmail.com> Signed-off-by:
Danila Tikhonov <danila@jiaxyga.com> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230305191745.386862-2-danila@jiaxyga.com
-
Bhupesh Sharma authored
Add the ID for QRB4210 variant. Signed-off-by:
Bhupesh Sharma <bhupesh.sharma@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230315160151.2166861-3-bhupesh.sharma@linaro.org
-
Bhupesh Sharma authored
Add the ID for QRB4210 variant. Signed-off-by:
Bhupesh Sharma <bhupesh.sharma@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230315160151.2166861-2-bhupesh.sharma@linaro.org
-
Varadarajan Narayanan authored
Add SOC ID for Qualcomm IPQ9574, IPQ9570, IPQ9554, IPQ9550, IPQ9514 and IPQ9510 Signed-off-by:
Varadarajan Narayanan <quic_varada@quicinc.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Kathiravan T <quic_kathirav@quicinc.com> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/1678774414-14414-3-git-send-email-quic_varada@quicinc.com
-
Varadarajan Narayanan authored
Add SOC ID for Qualcomm IPQ9574, IPQ9570, IPQ9554, IPQ9550, IPQ9514 and IPQ9510 Signed-off-by:
Varadarajan Narayanan <quic_varada@quicinc.com> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Kathiravan T <quic_kathirav@quicinc.com> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/1678774414-14414-2-git-send-email-quic_varada@quicinc.com
-
Manivannan Sadhasivam authored
The platforms based on SDM845 SoC locks the access to EDAC registers in the bootloader. So probing the EDAC driver will result in a crash. Hence, disable the creation of EDAC platform device on all SDM845 devices. The issue has been observed on Lenovo Yoga C630 and DB845c. While at it, also sort the members of `struct qcom_llcc_config` to avoid any holes in-between. Cc: <stable@vger.kernel.org> # 5.10 Reported-by:
Steev Klimaszewski <steev@kali.org> Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230314080443.64635-15-manivannan.sadhasivam@linaro.org
-
Manivannan Sadhasivam authored
Not all Qcom platforms support IRQ mode for ECC handling. For those platforms, the current EDAC driver will not be probed due to missing ECC IRQ in devicetree. So add support for polling mode so that the EDAC driver can be used on all Qcom platforms supporting LLCC. The polling delay of 5000ms is chosen based on Qcom downstream/vendor driver. Reported-by:
Luca Weiss <luca.weiss@fairphone.com> Tested-by:
Luca Weiss <luca.weiss@fairphone.com> Tested-by: Steev Klimaszewski <steev@kali.org> # Thinkpad X13s Tested-by: Andrew Halaney <ahalaney@redhat.com> # sa8540p-ride Reviewed-by:
Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230314080443.64635-14-manivannan.sadhasivam@linaro.org
-
Manivannan Sadhasivam authored
The Qualcomm LLCC/EDAC drivers were using a fixed register stride for accessing the (Control and Status Registers) CSRs of each LLCC bank. This stride only works for some SoCs like SDM845 for which driver support was initially added. But the later SoCs use different register stride that vary between the banks with holes in-between. So it is not possible to use a single register stride for accessing the CSRs of each bank. By doing so could result in a crash. For fixing this issue, let's obtain the base address of each LLCC bank from devicetree and get rid of the fixed stride. This also means, there is no need to rely on reg-names property and the base addresses can be obtained using the index. First index is LLCC bank 0 and last index is LLCC broadcast. If the SoC supports more than one bank, then those need to be defined in devicetree for index from 1..N-1. Reported-by:
Parikshit Pareek <quic_ppareek@quicinc.com> Tested-by:
Luca Weiss <luca.weiss@fairphone.com> Tested-by: Steev Klimaszewski <steev@kali.org> # Thinkpad X13s Tested-by: Andrew Halaney <ahalaney@redhat.com> # sa8540p-ride Reviewed-by:
Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230314080443.64635-13-manivannan.sadhasivam@linaro.org
-
Manivannan Sadhasivam authored
Register regions of the LLCC banks are located at different addresses. Currently, the binding just lists the LLCC0 base address and tries to cover all the banks using a single size. This is entirely wrong as there are other register regions that happen to lie inside the size covered by the binding such as the memory controller and holes. So this needs to be fixed by specifying the base address of individual LLCC banks. This approach will break the existing users of this binding as the register regions are split and the drivers now cannot use LLCC0 register region for accessing rest of the banks (which is wrong anyway). But considering the fact that the binding was wrong from the day one and also the device drivers going wrong by the binding, this breakage is acceptable. Reported-by:
Parikshit Pareek <quic_ppareek@quicinc.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230314080443.64635-3-manivannan.sadhasivam@linaro.org
-
Manivannan Sadhasivam authored
Both Rishabh and Sai have left Qualcomm, and there is no evidence of them maintaining with a new identity. So their entry needs to be removed. Listed Bjorn as the interim maintainer until someone volunteers to maintain this binding. Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230314080443.64635-2-manivannan.sadhasivam@linaro.org
-
Konrad Dybcio authored
Add the missing IDs for scuba and its QRB variant. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230314-topic-scuba_socinfo-v2-2-44fa1256aa6d@linaro.org
-
Konrad Dybcio authored
Add the missing IDs for scuba and its QRB variant. Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230314-topic-scuba_socinfo-v2-1-44fa1256aa6d@linaro.org
-
- 14 Mar, 2023 1 commit
-
-
Visweswara Tanuku authored
From QUP HW Version 3.10 and above the Tx and Rx fifo depth bits are increased to 23:16 bits from 21:16 bits in SE_HW_PARAM registers accomodating 256bytes of fifo depth. Updated geni_se_get_tx_fifo_depth and geni_se_get_rx_fifo_depth to retrieve right fifo depth based on QUP HW version. Signed-off-by:
Visweswara Tanuku <quic_vtanuku@quicinc.com> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230215050528.9507-1-quic_vtanuku@quicinc.com
-
- 13 Mar, 2023 8 commits
-
-
Konrad Dybcio authored
Add some missing PMICs based on the _SUBTYPE defines in include/soc/qcom/qcom-spmi-pmic.h Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230213215500.2131511-1-konrad.dybcio@linaro.org
-
Bartosz Golaszewski authored
Add SocInfo support for SA8775P. Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by:
Eric Chanudet <echanude@redhat.com> Tested-by: Eric Chanudet <echanude@redhat.com> # sa8775p-ride Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230209095753.447347-4-brgl@bgdev.pl
-
Bartosz Golaszewski authored
Add the SoC ID entry for SA8775P. Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Eric Chanudet <echanude@redhat.com> Tested-by:
Eric Chanudet <echanude@redhat.com> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230209095753.447347-3-brgl@bgdev.pl
-
Bartosz Golaszewski authored
Update max processor count to reflect the number of co-processors on SA8775P SoCs. Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by:
Eric Chanudet <echanude@redhat.com> Tested-by:
Eric Chanudet <echanude@redhat.com> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230209095753.447347-2-brgl@bgdev.pl
-
Krzysztof Kozlowski authored
The qcom,intents property is a list of pairs, thus it should be defined as uint32-matrix. Fixes: b2d7616e ("dt-bindings: soc: qcom: apr: add missing properties") Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230208101545.45711-5-krzysztof.kozlowski@linaro.org
-
Krzysztof Kozlowski authored
The QCOM_KRYO_L2_ACCESSORS can be compile tested only on ARM64 because it references asm/sysreg.h present only on ARM64. Mark the dependency correct, even though as a non-selectable option it does not have real effect. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230123202601.1296983-1-krzysztof.kozlowski@linaro.org
-
Rob Herring authored
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230310144724.1545153-1-robh@kernel.org
-
Krzysztof Kozlowski authored
The driver can be compile tested with !CONFIG_OF making certain data unused: drivers/soc/qcom/qcom_gsbi.c:117:34: error: ‘tcsr_dt_match’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230310214413.275054-1-krzysztof.kozlowski@linaro.org
-
- 05 Mar, 2023 5 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Commit aa47a7c2 ("lib/cpumask: deprecate nr_cpumask_bits") resulted in the cpumask operations potentially becoming hugely less efficient, because suddenly the cpumask was always considered to be variable-sized. The optimization was then later added back in a limited form by commit 6f9c07be ("lib/cpumask: add FORCE_NR_CPUS config option"), but that FORCE_NR_CPUS option is not useful in a generic kernel and more of a special case for embedded situations with fixed hardware. Instead, just re-introduce the optimization, with some changes. Instead of depending on CPUMASK_OFFSTACK being false, and then always using the full constant cpumask width, this introduces three different cpumask "sizes": - the exact size (nr_cpumask_bits) remains identical to nr_cpu_ids. This is used for situations where we should use the exact size. - the "small" size (small_cpumask_bits) is the NR_CPUS constant if it fits in a single word and the bitmap operations thus end up able to trigger the "small_const_nbits()" optimizations. This is used for the operations that have optimized single-word cases that get inlined, notably the bit find and scanning functions. - the "large" size (large_cpumask_bits) is the NR_CPUS constant if it is an sufficiently small constant that makes simple "copy" and "clear" operations more efficient. This is arbitrarily set at four words or less. As a an example of this situation, without this fixed size optimization, cpumask_clear() will generate code like movl nr_cpu_ids(%rip), %edx addq $63, %rdx shrq $3, %rdx andl $-8, %edx callq memset@PLT on x86-64, because it would calculate the "exact" number of longwords that need to be cleared. In contrast, with this patch, using a MAX_CPU of 64 (which is quite a reasonable value to use), the above becomes a single movq $0,cpumask instruction instead, because instead of caring to figure out exactly how many CPU's the system has, it just knows that the cpumask will be a single word and can just clear it all. Note that this does end up tightening the rules a bit from the original version in another way: operations that set bits in the cpumask are now limited to the actual nr_cpu_ids limit, whereas we used to do the nr_cpumask_bits thing almost everywhere in the cpumask code. But if you just clear bits, or scan for bits, we can use the simpler compile-time constants. In the process, remove 'cpumask_complement()' and 'for_each_cpu_not()' which were not useful, and which fundamentally have to be limited to 'nr_cpu_ids'. Better remove them now than have somebody introduce use of them later. Of course, on x86-64 with MAXSMP there is no sane small compile-time constant for the cpumask sizes, and we end up using the actual CPU bits, and will generate the above kind of horrors regardless. Please don't use MAXSMP unless you really expect to have machines with thousands of cores. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds authored
Pull crypto fix from Herbert Xu: "Fix a regression in the caam driver" * tag 'v6.3-p2' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: caam - Fix edesc/iv ordering mixup
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 updates from Thomas Gleixner: "A small set of updates for x86: - Return -EIO instead of success when the certificate buffer for SEV guests is not large enough - Allow STIPB to be enabled with legacy IBSR. Legacy IBRS is cleared on return to userspace for performance reasons, but the leaves user space vulnerable to cross-thread attacks which STIBP prevents. Update the documentation accordingly" * tag 'x86-urgent-2023-03-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: virt/sev-guest: Return -EIO if certificate buffer is not large enough Documentation/hw-vuln: Document the interaction between IBRS and STIBP x86/speculation: Allow enabling STIBP with legacy IBRS
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq updates from Thomas Gleixner: "A set of updates for the interrupt susbsystem: - Prevent possible NULL pointer derefences in irq_data_get_affinity_mask() and irq_domain_create_hierarchy() - Take the per device MSI lock before invoking code which relies on it being hold - Make sure that MSI descriptors are unreferenced before freeing them. This was overlooked when the platform MSI code was converted to use core infrastructure and results in a fals positive warning - Remove dead code in the MSI subsystem - Clarify the documentation for pci_msix_free_irq() - More kobj_type constification" * tag 'irq-urgent-2023-03-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: genirq/msi, platform-msi: Ensure that MSI descriptors are unreferenced genirq/msi: Drop dead domain name assignment irqdomain: Add missing NULL pointer check in irq_domain_create_hierarchy() genirq/irqdesc: Make kobj_type structures constant PCI/MSI: Clarify usage of pci_msix_free_irq() genirq/msi: Take the per-device MSI lock before validating the control structure genirq/ipi: Fix NULL pointer deref in irq_data_get_affinity_mask()
-