summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-07-30arm64: dts: qcom: talos: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-2/+2
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 718cc7542a00 ("arm64: dts: qcom: qcs615: enable pcie") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-13-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8750: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-2/+2
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 19f1395333f8 ("arm64: dts: qcom: sm8750: Add PCIe PHY and controller node") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-12-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8650: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-4/+4
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-11-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8550: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-4/+4
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 7d1158c984d3 ("arm64: dts: qcom: sm8550: Add PCIe PHYs and controllers nodes") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-10-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8450: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-4/+4
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 7b09b1b47335 ("arm64: dts: qcom: sm8450: add PCIe0 RC device") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-9-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8350: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-4/+4
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 6daee40678a0 ("arm64: dts: qcom: sm8350: add PCIe devices") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-8-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8250: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-6/+6
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: e53bdfc00977 ("arm64: dts: qcom: sm8250: Add PCIe support") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-7-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8150: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-4/+4
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: a1c86c680533 ("arm64: dts: qcom: sm8150: Add PCIe nodes") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-6-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sdm845: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-32/+32
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 5c538e09cb19 ("arm64: dts: qcom: sdm845: Add first PCIe controller and PHY") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-5-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sc8180x: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-8/+8
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: d20b6c84f56a ("arm64: dts: qcom: sc8180x: Add PCIe instances") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-4-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sar2130p: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-4/+4
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: be9115bfe5bf ("arm64: dts: qcom: sar2130p: add support for SAR2130P") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-3-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: kodiak: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-4/+4
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: f8328b7549e1 ("arm64: dts: qcom: sc7280: Describe the first PCIe controller and PHY") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-2-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: kaanapali: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-2/+2
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 2eeb5767d53f ("arm64: dts: qcom: Introduce Kaanapali SoC") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-1-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8250-xiaomi-elish: correct the board IDDawid Wróbel1-1/+1
elish declares the same qcom,msm-id and qcom,board-id pair as sm8250-sony-xperia-edo.dtsi, so a bootloader choosing between appended device trees cannot tell the two boards apart. 0x10008 is Sony's value. The downstream device tree for this board, elish-sm8250-overlay.dts, uses qcom,board-id = <47 0>, i.e. platform type 0x2f. Fixes: a41b617530bf ("arm64: dts: qcom: sm8250: Add device tree for Xiaomi Mi Pad 5 Pro") Signed-off-by: Dawid Wróbel <me@dawidwrobel.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-elish-board-id-v1-1-92f99e9722ec@dawidwrobel.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: talos: Fix cpu6 1094.4MHz OPP frequency typoImran Shaik1-1/+1
opp-1094400000 in cpu6_opp_table has a typo in opp-hz, missing a trailing zero. Fix it to resolve the following OPP update failures: cpu cpu6: Voltage update failed freq=1094400 cpu cpu6: failed to update OPP for freq=1094400 Fixes: 44562f591890 ("arm64: dts: qcom: qcs615: Add OSM l3 interconnect provider node and CPU OPP tables to scale DDR/L3") Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-talos-cpu6-opp-fix-v1-1-f4886fdff13f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: glymur: Fix PDC IRQ mappingKonrad Dybcio1-3/+7
Some of the sub-ranges are inconsistent with HW docs. Fix them. They are valid for both Glymur and Mahua. Fixes: 41b6e8db400c ("arm64: dts: qcom: Introduce Glymur base dtsi") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260729-topic-glymur_pdc-v1-1-8747789e35aa@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: eliza-cqs-som: Add eUSB2 repeater suppliesKonrad Dybcio1-0/+5
Hardware works better when it's powered. Wire up the associated regulators. Fixes: 85a1eb421dfa ("arm64: dts: qcom: eliza: Add Eliza CQS SoM platform") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-topic-eliza_som_eusb2-v1-1-288bcda1fee2@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8650-hdk: add SPMI ADC channels and thermal nodesNeil Armstrong1-0/+277
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the other PMICS on the system. The thermal nodes are sorted by the sensor channel to be coherent with the system thermal nodes ordering. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260721-topic-sm8x50-adc5-gen3-v6-5-a507f4a1e537@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8650-qrd: add SPMI ADC channels and thermal nodesNeil Armstrong1-0/+277
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the other PMICS on the system. The thermal nodes are sorted by the sensor channel to be coherent with the system thermal nodes ordering. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260721-topic-sm8x50-adc5-gen3-v6-4-a507f4a1e537@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8550-hdk: add SPMI ADC channels and thermal nodesNeil Armstrong1-0/+277
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the other PMICS on the system. The thermal nodes are sorted by the sensor channel to be coherent with the system thermal nodes ordering. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260721-topic-sm8x50-adc5-gen3-v6-3-a507f4a1e537@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8550-qrd: add SPMI ADC channels and thermal nodesNeil Armstrong1-0/+277
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the other PMICS on the system. The thermal nodes are sorted by the sensor channel to be coherent with the system thermal nodes ordering. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260721-topic-sm8x50-adc5-gen3-v6-2-a507f4a1e537@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: pmk8550: add VADC nodeNeil Armstrong1-0/+30
Add the VADC node and the initial pmk8550 adc channels. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20260721-topic-sm8x50-adc5-gen3-v6-1-a507f4a1e537@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: hamoa-pmics: Add ADC supportAyyagari Ushasreevalli7-0/+164
Add ADC node and define channels for: - Die temperature for PMK8550, PM8550VE* and PMC8380* PMICs. - PM8550: Die temperature, VPH power, and system thermistors. Add io-channels and io-channel-names properties to the temp_alarm nodes so that they can get temperature reading from the ADC die_temp channels. Remove die_temp channel of PMC8380_6 for Purwa boards where this PMIC is not present. Signed-off-by: Ayyagari Ushasreevalli <aushasre@qti.qualcomm.com> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260728-adc5_gen3_dt-v4-4-355f0edece77@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: monaco-pmics: Add ADC support for PMM8620AUAyyagari Ushasreevalli1-0/+43
Add ADC nodes for PMM8620AU PMIC instances (SID 0 and SID 2) present on the Monaco platform. Each ADC node exposes the following ADC channels: - DIE_TEMP: PMIC die temperature channel - VPH_PWR: Battery/supply voltage channel Signed-off-by: Ayyagari Ushasreevalli <aushasre@qti.qualcomm.com> Tested-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260728-adc5_gen3_dt-v4-3-355f0edece77@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: lemans-pmics: Add ADC support for PMM8654auAyyagari Ushasreevalli1-0/+93
Add ADC nodes for the four PMM8654au PMICs (pmm8654au_0 through pmm8654au_3) on the Lemans platform. Each ADC node exposes the following ADC channels: - DIE_TEMP: PMIC die temperature channel - VPH_PWR: Battery/supply voltage channel Also add the io-channels and io-channel-names properties under the temp-alarm nodes so that they can get temperature reading from the ADC die_temp channels. Signed-off-by: Ayyagari Ushasreevalli <aushasre@qti.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260728-adc5_gen3_dt-v4-2-355f0edece77@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: Add header file for ADC5 Gen3 channel macrosJishnu Prakash1-0/+88
Add macro definitions for virtual channels (combination of ADC channel number and PMIC SID number), to be used in devicetree by clients of ADC5 GEN3 device and in the "reg" property of ADC channels. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260728-adc5_gen3_dt-v4-1-355f0edece77@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: glymur: Configure USB controllers are wakeup-capableKrishna Kurapati1-0/+5
All USB controller on Glymur are wakeup-capable device. Add wakeup-source property for each of them indicating the same. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260723-glymur-usb-fixes-v1-2-816357d5319c@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: glymur: Fix properties of usb_hs nodeKrishna Kurapati2-2/+5
The High-speed only controller is DRD capable. Hence move the dr_mode property to platform DTS and mark the controller as role switch capable. While at it, since its high-speed only controller, disable pipe clock requirement. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260723-glymur-usb-fixes-v1-1-816357d5319c@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: monaco: Fix CSI I2C controllers default bus frequencyHans de Goede1-6/+6
1 MHz is quite fast for an I2C bus and not necessarly reliable, change this to 400 KHz which is a more reasonable default. Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260723114844.63093-1-johannes.goede@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: arm: qcom: Add Asus Zenbook A16 (UX3607OA)Konrad Dybcio1-0/+1
UX3607OA is a variant of the Asus Zenbook A16 built on the Qualcomm Glymur platform. It comes with an 18-core X2 Elite Extreme SoC, 48GiB of RAM, NVMe storage, a 2880 x 1800 OLED screen, and the other typical Glymur platform capabilities. The hardware wiring is very different versus the 14" SKU. Add a compatible for this machine. [1] https://www.asus.com/us/laptops/for-home/zenbook/asus-zenbook-a16-ux3607/techspec/ Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260721-topic-a16_submission-v1-1-8ea213130d05@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm6125-xiaomi-ginkgo: Add vbus-supply in Type-C connectorBiswapriyo Nath1-0/+2
VBUS supply property was moved from pmi632 typec node to USB-C connector. This fixes the following warning in kernel message. pmic@2:typec@1500: supply vdd-vbus not found, using dummy regulator Fixes: c1da9374c3e0 ("arm64: dts: qcom: sm6125-xiaomi-ginkgo: Add PMI632 Type-C property") Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-ginkgo-vbus-typec-v1-1-d5ed0aa6b78b@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: x1e80100: Add deepest idle stateMaulik Shah1-3/+11
CPU subsystem deepest idle state can lead SoC to low power mode like CxPC (chip rail power collapse). SoC deepest low power mode requires the PDC interrupt controller to wake up the SoC as the GIC interrupt controller is on Cx (chip rail) and will not be functional to wake up the CPU. PDC monitors both direct SPI interrupts and GPIOs used as interrupts in SoC low power mode. Further all wake up capable interrupts gets routed via PDC to GIC when SoC is out of low power mode. The wake up capable GPIOs used as interrupts were by passing PDC on x1e with commit 602cb14e310a ("pinctrl: qcom: x1e80100: Bypass PDC wakeup parent for now") as a result CPU deepest idle state was not added so far. The blocker for enabling deepest idle state was GPIO IRQ wakeup support. The x1e80100 PDC can operate in two modes: pass-through mode (GPIO IRQs forwarded directly to GIC without latching at PDC) and secondary controller mode (PDC latches GPIO IRQs and sends them as level IRQs to GIC). All the SoCs on Linux so far worked in pass-through mode of PDC. On some x1e boards the firmware configures the PDC in secondary controller mode, which caused GPIO interrupt storms as the level latched at PDC gets never cleared. The secondary mode is originally a requirement for windows SW platforms (which could not work with all types of interrupts and require level interrupts for GPIOs). Initially shipped windows firmware did not have SCM interface to configure PDC back to pass-through mode if with such firmware Linux is booted up. PDC irqchip has got secondary mode and SCM interface support to configure PDC irqchip mode to pass-through mode on newer firmware where SCM interface is available and for older firmware on which SCM interface is not present PDC irqchip works in secondary irqchip mode [1]. Above mentioned commit is also reverted via [1]. With PDC now working on older firmware as well add the CPU deepest idle state domain_ss3. The newly added domain_ss3 state has entry/exit latencies of 2500 us. The shallower cluster_cl5 state had entry/exit latencies of 2200/4000 us which are higher than the deeper state. This create an inconsistency that would confuse the idle governor. Correct cluster_cl5 latencies to 2000 us each to match production configuration values. [1] https://lore.kernel.org/linux-arm-msm/20260707-hamoa_pdc_v3-v4-0-dfd1f4a3ae89@oss.qualcomm.com/#t Tested-by: Daniel J Blueman <daniel@quora.org> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260715-hamoa_pdc_v3-v5-1-00440cfaf711@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: ipq9574: enable the PCIe support on RDP454Kathiravan Thirumoorthy1-0/+80
Enable the PCIe0 (x1) and PCIe2 (x2) instances to connect QCN92xx Wi‑Fi cards. Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260714-pcie_move_to_new_binding-v1-5-6bb25887a0dc@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: ipq9574: Add PCIe bridge nodeKathiravan Thirumoorthy2-20/+69
The PCIe host bridge is connected to a single PCIe bridge for each controller instance. Hence, add a node to represent the bridge. While at it, to align with the newer style of binding, move the phys and perst to port node. Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260714-pcie_move_to_new_binding-v1-4-6bb25887a0dc@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: ipq5018: move PCIe phys and PERST# to port nodeKathiravan Thirumoorthy2-10/+10
To align with the newer style of binding, move the phys, PERST# to the port node. Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260714-pcie_move_to_new_binding-v1-3-6bb25887a0dc@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: ipq6018: move PCIe phys to port nodeKathiravan Thirumoorthy1-3/+2
To align with the newer style of binding, move the phys property to the port node. Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260714-pcie_move_to_new_binding-v1-2-6bb25887a0dc@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: ipq8074: move PCIe phys and PERST# to port nodeKathiravan Thirumoorthy3-12/+22
To align with the newer style of binding, move the phys, PERST# to the port node. Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260714-pcie_move_to_new_binding-v1-1-6bb25887a0dc@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: power: reset: qcom-pon: Add new compatible PMM8654AURakesh Kota1-6/+10
PMM8654AU is a distinct PMIC variant from PMM8650AU despite sharing the same PMIC subtype. PMM8654AU implements additional registers added to the "hlos" register address spaces, so add qcom,pmm8654au-pon as a fallback to qcom,pmk8350-pon to distinguish it from the baseline PMK8350 PON implementation. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260724-b4-add_pwrkey_and_resin-v6-1-41acc214d93a@oss.qualcomm.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-30zloop: set dma_alignment from the backing files for direct I/OKeith Busch1-10/+25
Direct I/O request's use pages handed to the backing files unchanged, so the backing's DMA alignment requirement applies. Track dio_mem_align and advertise it as the device's dma_alignment so we communicate proper limits and misaligned I/O is rejected here instead of reaching the backend. Reviewed-by: Hannes Reinecke <hare@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Link: https://patch.msgid.link/20260720201057.1862857-5-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-07-30loop: set dma_alignment from the backing file for direct I/OKeith Busch1-8/+38
Direct I/O user pages are forwarded to the backing file unchanged, so the backing's DMA alignment requirement applies to them. Track the backing's dio_mem_align and advertise it as the loop device's dma_alignment so we advertise proper limits and misaligned I/O is rejected here instead of being dispatched to the backend. Reviewed-by: Hannes Reinecke <hare@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Link: https://patch.msgid.link/20260720201057.1862857-4-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-07-30block: fix dio leak on metadata mapping errorKeith Busch1-2/+4
A failed integrity mapping holds a dio reference, so we need to go through the full bio ending in case there were previously submitted bio's in the sequence. Fixes: 2729a60bbfb92 ("block: don't silently ignore metadata for sync read/write") Reviewed-by: Hannes Reinecke <hare@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Link: https://patch.msgid.link/20260720201057.1862857-3-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-07-30block: use blkdev_iov_iter_get_pages status for errorsKeith Busch1-1/+1
blkdev_iov_iter_get_pages() can return various error values, including EIO, EFAULT, and ENOMEM. Set the actual reported status so user space can know why an operation failed. Reviewed-by: Hannes Reinecke <hare@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Link: https://patch.msgid.link/20260720201057.1862857-2-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-07-30power: supply: bq25630: Initialize hardware before exposing the power supplyLinmao Li1-7/+5
bq25630_setup() resets the device, disables the watchdog and programs the charge limits from the battery information. It runs at the end of bq25630_probe(), that is after the power supply has been registered, so the device is already exposed to the system while the hardware still holds its power-on defaults. power_supply_desc::init runs during registration, after the driver data and the fwnode are available and before the device is added. Use it for bq25630_setup() and drop the explicit call from bq25630_probe(). The callback is passed the power supply, so take the driver data from it and use it for the battery information as well: data->psy is only assigned once devm_power_supply_register() returns, which is after the callback has run. Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Reviewed-by: Waqar Hameed <waqar.hameed@axis.com> Link: https://patch.msgid.link/20260730011713.3332913-3-lilinmao@kylinos.cn Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-30power: supply: bq25630: Scope battery information to bq25630_setup()Linmao Li1-22/+26
data->batinfo is only used by bq25630_setup() to program the initial charge limits, but power_supply_get_battery_info() allocates it on psy->dev, so it stays around for the lifetime of the device. Nothing else in the driver uses it. Get the battery information in bq25630_setup(), just before it is read, and release it on every path out of that function. The driver data no longer has to carry the pointer. Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Reviewed-by: Waqar Hameed <waqar.hameed@axis.com> Link: https://patch.msgid.link/20260730011713.3332913-2-lilinmao@kylinos.cn Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-30clk: qcom: gcc-hawi: Add support for global clock controller on MailiTaniya Das1-0/+201
Add support for the global clock controller (GCC) on the Qualcomm Maili SoC by extending the Hawi global clock controller since Maili is identical to Hawi and has few additional clocks. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-maili_initial_clock-v4-4-ed52ade264f0@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: clock: qcom: Add Maili global clock controllerTaniya Das2-3/+29
Add device tree bindings for the global clock controller (GCC) on the Qualcomm Maili SoC by extending the existing Qualcomm Hawi GCC bindings, since the Maili GCC is identical to the Hawi GCC apart from a few additional clocks. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-maili_initial_clock-v4-3-ed52ade264f0@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: clock: qcom: Add Maili TCSR clock controllerTaniya Das1-13/+19
Add bindings documentation for TCSR clock controller on the Qualcomm Maili SoC. Maili is a derivative of the Hawi SoC and the tcsr clock controller is identical to that of Hawi. Therefore Maili uses the fallback compatible to reuse the Hawi tcsrcc driver. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-maili_initial_clock-v4-2-ed52ade264f0@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: clock: qcom-rpmhcc: Add RPMH clock controller for MailiTaniya Das1-30/+35
Document the RPMH clock controller for the Qualcomm Maili SoC. Maili SoC is a derivative of the Hawi SoC and the rpmh clock controller is identical to that of Hawi. Therefore Maili uses the fallback compatible to reuse the Hawi rpmhcc driver. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-maili_initial_clock-v4-1-ed52ade264f0@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-31md/raid10: free r10bio before ending master_bio in raid_end_bio_io() and ↵Chen Cheng1-4/+10
raid_end_discard_bio() origin flow: bio_endio(master_bio); /* may drop active_io to zero */ allow_barrier(conf); free_r10bio(r10_bio); /* reads conf->geo, returns to pool */ one scenario is: CPU A (softirq, raid_end_bio_io) CPU B (action_store) --> reshape ================================ =============================== bio_endio(master_bio) md_end_clone_io percpu_ref_put -> 0 wait_event wakeup, and, mddev_suspend return raid10_start_reshape: setup_geo(&conf->geo, new) ... mempool_destroy(old_pool) conf->r10bio_pool = new_pool allow_barrier(conf) free_r10bio(r10_bio) put_all_bios: for (i=0; i<conf->geo.raid_disks; i++) ==> old obj, new geo, OOB mempool_free(r10_bio, conf->r10bio_pool) ==> old-geometry obj freed into new pool so .. fix by reorder the flow: free_r10bio(r10_bio) bio_endio(master_bio) allow_barrier(conf) raid_end_discard_bio() is exactly the same. Signed-off-by: Chen Cheng <chencheng@fnnas.com> Link: https://patch.msgid.link/20260711100352.425177-4-chencheng@fnnas.com Signed-off-by: Yu Kuai <yukuai@fygo.io>
2026-07-31md/raid10: resize r10bio_pool for reshapeChen Cheng2-14/+34
When reshape grows raid_disks, the pool must also switch to new geometry object size , and allocate a new geometry size pool and replace the old. But not for shrinking reshape, because regular I/O can still use the prev geo for sectors that have not crossed reshape_progress yet. Signed-off-by: Chen Cheng <chencheng@fnnas.com> Link: https://patch.msgid.link/20260711100352.425177-3-chencheng@fnnas.com Signed-off-by: Yu Kuai <yukuai@fygo.io>
generated by cgit (git 2.54.0.dirty) at 2026-09-30 09:18:03 +0000