* Re: [PATCH 4/4] ASoC: dt-bindings: qcom,sm8250: Add Ayaneo Pocket S2 sound card
From: Krzysztof Kozlowski @ 2026-06-11 9:04 UTC (permalink / raw)
To: Neil Armstrong
Cc: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, kancy2333, linux-sound,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260610-topic-sm8650-ayaneo-pocket-s2-wsa2-fix-v1-4-18bb19c5ca22@linaro.org>
On Wed, Jun 10, 2026 at 09:41:48AM +0200, Neil Armstrong wrote:
> Document the bindings for the sound card on the Ayaneo Pocket S2
> which uses the special speaker connection incompatible with
> the default SM8650 sound card.
>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
> Documentation/devicetree/bindings/sound/qcom,sm8250.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Please organize the patch documenting the compatible (DT bindings)
before the patch using that compatible.
See also: https://elixir.bootlin.com/linux/v6.14-rc6/source/Documentation/devicetree/bindings/submitting-patches.rst#L46
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: Add SD Card support for Glymur SoC
From: Konrad Dybcio @ 2026-06-11 9:04 UTC (permalink / raw)
To: Monish Chunara, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Nitin Rawat, Pradeep Pragallapati, Komal Bajaj, Sachin,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260610111508.3941207-4-mchunara@oss.qualcomm.com>
On 6/10/26 1:15 PM, Monish Chunara wrote:
> From: Monish Chunara <monish.chunara@oss.qualcomm.com>
>
> Add support for SD card on Glymur SoC and enable the required pinctrl
> configurations.
>
> Co-developed-by: Sachin <ssachin@qti.qualcomm.com>
> Signed-off-by: Sachin <ssachin@qti.qualcomm.com>
Firstname Lastname?
> Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/glymur.dtsi | 91 ++++++++++++++++++++++++++++
> 1 file changed, 91 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> index 20b49af7298e..0989fe39e7ef 100644
> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
> @@ -3927,6 +3927,57 @@ lpass_ag_noc: interconnect@7e40000 {
> #interconnect-cells = <2>;
> };
>
> + sdhc_2: mmc@8804000 {
> + compatible = "qcom,glymur-sdhci", "qcom,sdhci-msm-v5";
> +
> + reg = <0x0 0x08804000 0x0 0x1000>;
nit: Let's drop the \n above
> +
> + interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "hc_irq",
> + "pwr_irq";
> +
> + clocks = <&gcc GCC_SDCC2_AHB_CLK>,
> + <&gcc GCC_SDCC2_APPS_CLK>,
> + <&rpmhcc RPMH_CXO_CLK>;
> + clock-names = "iface",
> + "core",
> + "xo";
> +
> + iommus = <&apps_smmu 0xd00 0>;
'0x0' for the second value as it's a mask, please
> + qcom,dll-config = <0x0007442c>;
> + qcom,ddr-config = <0x80040868>;
> +
> + power-domains = <&rpmhpd RPMHPD_CX>;
> + operating-points-v2 = <&sdhc2_opp_table>;
> +
> + interconnects = <&aggre3_noc MASTER_SDCC_2 QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&hsc_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &config_noc SLAVE_SDCC_2 QCOM_ICC_TAG_ACTIVE_ONLY>;
> + interconnect-names = "sdhc-ddr",
> + "cpu-sdhc";
> +
> + bus-width = <4>;
> + dma-coherent;
> +
> + status = "disabled";
> +
> + sdhc2_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-100000000 {
> + opp-hz = /bits/ 64 <100000000>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + };
The SDC doc says this should be 50 MHz> +
> + opp-202000000 {
> + opp-hz = /bits/ 64 <202000000>;
> + required-opps = <&rpmhpd_opp_svs_l1>;
And that this should be opp_nom
But the clock plan doc has info that corresponds with the content of
your patch, please check which one is correct and file a request for
fixing the wrong one
Konrad
^ permalink raw reply
* Re: [PATCH v5 2/2] mfd: arizona: Convert GPIO IRQ handling to descriptors
From: Charles Keepax @ 2026-06-11 9:03 UTC (permalink / raw)
To: Lee Jones
Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, patches, linux-kernel,
linux-gpio, devicetree, Bartosz Golaszewski
In-Reply-To: <20260611082000.GL4151951@google.com>
On Thu, Jun 11, 2026 at 09:20:00AM +0100, Lee Jones wrote:
> On Wed, 27 May 2026, Linus Walleij wrote:
> > - gpio_get_value_cansleep(arizona->pdata.irq_gpio)) {
> > + gpiod_get_value_cansleep(arizona->irq_gpiod)) {
>
> [Severity: High]
> Does this incorrectly check the logical value of the GPIO instead of the raw
> physical state?
>
> The legacy gpio_get_value_cansleep() returned the raw physical state of the
> pin. The new gpiod_get_value_cansleep() returns the logical state, which
> incorporates the ACTIVE_LOW flag from the devicetree or software node.
>
> Because the IRQ trigger flags describe physical voltage transitions, comparing
> these physical flags against a logical value might be incorrect. For example,
> if a user defines irq-gpios with GPIO_ACTIVE_LOW for a falling edge interrupt,
> a physically low line becomes logically 1, causing the polling condition
> !gpiod_get_value_cansleep() to evaluate to 0, which fails to poll when the
> interrupt is active.
>
> Conversely, when the line is idle, it evaluates to 1, causing the IRQ handler
> to poll infinitely.
>
> Should this use gpiod_get_raw_value_cansleep() to preserve the original
> physical semantics?
Hmm.. yeah that is a good spot we should probably use the
raw_value version here as we presumably can't trust that the
device trees specify the ACTIVE_LOW/HIGH flags correctly.
> [Severity: High]
> This is a pre-existing issue, but can this loop forever if the GPIO read
> returns a negative error code?
>
> gpiod_get_value_cansleep() (and its legacy predecessor) can return a negative
> error code (e.g., -EIO) if reading the GPIO state fails over the bus. Since
> negative values are non-zero, this evaluates to true for IRQF_TRIGGER_RISING,
> setting poll = true and causing an infinite loop in the IRQ handler thread if
> the read continues to fail.
>
> Conversely, for IRQF_TRIGGER_FALLING, !(-EIO) evaluates to false, which
> immediately aborts the poll.
>
> Could the return value be stored in an integer and explicitly checked for
> negative errors before evaluating it as a boolean?
This is also fair, although given this feature is only really
supporting some quite old things that have been doing this for
ages I would be inclined to not stress too much about this.
Thanks,
Charles
^ permalink raw reply
* [PATCH v2 3/3] regulator: qcom-refgen: add support for the IPQ9650 SoC
From: Kathiravan Thirumoorthy @ 2026-06-11 9:03 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, devicetree, Kathiravan Thirumoorthy
In-Reply-To: <20260611-ipq9650_refgen-v2-0-d96a91d5b99e@oss.qualcomm.com>
IPQ9650 SoC has 2 REFGEN blocks providing the reference current to the
PCIe and USB, UNIPHY PHYs. For the other SoCs, clocks for this block is
enabled on power up but that's not the case for IPQ9650 and we have to
enable those clocks explicitly to bring up the PHYs properly.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
drivers/regulator/qcom-refgen-regulator.c | 89 +++++++++++++++++++++++++++++--
1 file changed, 85 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/qcom-refgen-regulator.c b/drivers/regulator/qcom-refgen-regulator.c
index 6a3795469927..e8821f159ff1 100644
--- a/drivers/regulator/qcom-refgen-regulator.c
+++ b/drivers/regulator/qcom-refgen-regulator.c
@@ -3,6 +3,7 @@
// Copyright (c) 2023, Linaro Limited
#include <linux/bitfield.h>
+#include <linux/clk.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
@@ -16,6 +17,10 @@
#define REFGEN_BIAS_EN_ENABLE 0x7
#define REFGEN_BIAS_EN_DISABLE 0x6
+#define REFGEN_REG_REFGEN_STATUS 0xC
+#define REFGEN_STATUS_OUT_MASK BIT(3)
+ #define REFGEN_STATUS_OUT_ENABLE 0x8
+
#define REFGEN_REG_BG_CTRL 0x14
#define REFGEN_BG_CTRL_MASK GENMASK(2, 1)
#define REFGEN_BG_CTRL_ENABLE 0x3
@@ -25,6 +30,16 @@
#define REFGEN_PWRDWN_CTRL5_MASK BIT(0)
#define REFGEN_PWRDWN_CTRL5_ENABLE 0x1
+struct qcom_refgen_regulator_data {
+ const struct regulator_desc *rdesc;
+ bool has_clocks;
+};
+
+struct qcom_refgen_drvdata {
+ struct clk_bulk_data *clks;
+ int num_clks;
+};
+
static int qcom_sdm845_refgen_enable(struct regulator_dev *rdev)
{
regmap_update_bits(rdev->regmap, REFGEN_REG_BG_CTRL, REFGEN_BG_CTRL_MASK,
@@ -62,6 +77,42 @@ static int qcom_sdm845_refgen_is_enabled(struct regulator_dev *rdev)
return 1;
}
+static int qcom_ipq9650_refgen_enable(struct regulator_dev *rdev)
+{
+ struct qcom_refgen_drvdata *drvdata = rdev_get_drvdata(rdev);
+ int ret;
+
+ ret = clk_bulk_prepare_enable(drvdata->num_clks, drvdata->clks);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int qcom_ipq9650_refgen_disable(struct regulator_dev *rdev)
+{
+ struct qcom_refgen_drvdata *drvdata = rdev_get_drvdata(rdev);
+
+ clk_bulk_disable_unprepare(drvdata->num_clks, drvdata->clks);
+
+ return 0;
+}
+
+static const struct regulator_desc ipq9650_refgen_desc = {
+ .enable_reg = REFGEN_REG_REFGEN_STATUS,
+ .enable_mask = REFGEN_STATUS_OUT_MASK,
+ .enable_val = REFGEN_STATUS_OUT_ENABLE,
+ .enable_time = 5,
+ .name = "refgen",
+ .owner = THIS_MODULE,
+ .type = REGULATOR_CURRENT,
+ .ops = &(const struct regulator_ops) {
+ .enable = qcom_ipq9650_refgen_enable,
+ .disable = qcom_ipq9650_refgen_disable,
+ .is_enabled = regulator_is_enabled_regmap,
+ },
+};
+
static const struct regulator_desc sdm845_refgen_desc = {
.enable_time = 5,
.name = "refgen",
@@ -90,6 +141,19 @@ static const struct regulator_desc sm8250_refgen_desc = {
},
};
+static const struct qcom_refgen_regulator_data ipq9650_data = {
+ .rdesc = &ipq9650_refgen_desc,
+ .has_clocks = true,
+};
+
+static const struct qcom_refgen_regulator_data sdm845_data = {
+ .rdesc = &sdm845_refgen_desc,
+};
+
+static const struct qcom_refgen_regulator_data sm8250_data = {
+ .rdesc = &sm8250_refgen_desc,
+};
+
static const struct regmap_config qcom_refgen_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
@@ -98,6 +162,8 @@ static const struct regmap_config qcom_refgen_regmap_config = {
static int qcom_refgen_probe(struct platform_device *pdev)
{
+ const struct qcom_refgen_regulator_data *data;
+ struct qcom_refgen_drvdata *drvdata = NULL;
struct regulator_init_data *init_data;
struct regulator_config config = {};
const struct regulator_desc *rdesc;
@@ -106,10 +172,23 @@ static int qcom_refgen_probe(struct platform_device *pdev)
struct regmap *regmap;
void __iomem *base;
- rdesc = of_device_get_match_data(dev);
- if (!rdesc)
+ data = of_device_get_match_data(dev);
+ if (!data)
return -ENODATA;
+ if (data->has_clocks) {
+ drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata)
+ return -ENOMEM;
+
+ drvdata->num_clks = devm_clk_bulk_get_all(dev, &drvdata->clks);
+ if (drvdata->num_clks < 0)
+ return dev_err_probe(dev, drvdata->num_clks,
+ "failed to get clocks\n");
+ }
+
+ rdesc = data->rdesc;
+
base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
return PTR_ERR(base);
@@ -126,6 +205,7 @@ static int qcom_refgen_probe(struct platform_device *pdev)
config.init_data = init_data;
config.of_node = dev->of_node;
config.regmap = regmap;
+ config.driver_data = drvdata;
rdev = devm_regulator_register(dev, rdesc, &config);
if (IS_ERR(rdev))
@@ -135,8 +215,9 @@ static int qcom_refgen_probe(struct platform_device *pdev)
}
static const struct of_device_id qcom_refgen_match_table[] = {
- { .compatible = "qcom,sdm845-refgen-regulator", .data = &sdm845_refgen_desc },
- { .compatible = "qcom,sm8250-refgen-regulator", .data = &sm8250_refgen_desc },
+ { .compatible = "qcom,ipq9650-refgen-regulator", .data = &ipq9650_data },
+ { .compatible = "qcom,sdm845-refgen-regulator", .data = &sdm845_data },
+ { .compatible = "qcom,sm8250-refgen-regulator", .data = &sm8250_data },
{ }
};
MODULE_DEVICE_TABLE(of, qcom_refgen_match_table);
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/3] regulator: dt-bindings: qcom,sdm845-refgen-regulator: Document IPQ9650
From: Kathiravan Thirumoorthy @ 2026-06-11 9:03 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, devicetree, Kathiravan Thirumoorthy
In-Reply-To: <20260611-ipq9650_refgen-v2-0-d96a91d5b99e@oss.qualcomm.com>
IPQ9650 has two REFGEN blocks which provide reference current to the PCIe,
USB and UNIPHY PHYs. Unlike other supported platforms, IPQ9650 requires the
REFGEN clocks to be enabled explicitly.
Document the IPQ9650 compatible and the required clocks for it.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
.../regulator/qcom,sdm845-refgen-regulator.yaml | 25 ++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
index 40f9223d4c27..2016dd7a0bdd 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
@@ -16,6 +16,20 @@ description:
allOf:
- $ref: regulator.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,ipq9650-refgen-regulator
+ then:
+ required:
+ - clocks
+ - clock-names
+ else:
+ properties:
+ clocks: false
+ clock-names: false
+
properties:
compatible:
oneOf:
@@ -29,6 +43,7 @@ properties:
- items:
- enum:
+ - qcom,ipq9650-refgen-regulator
- qcom,qcs8300-refgen-regulator
- qcom,sa8775p-refgen-regulator
- qcom,sc7280-refgen-regulator
@@ -45,6 +60,16 @@ properties:
reg:
maxItems: 1
+ clocks:
+ items:
+ - description: Core reference clock
+ - description: AHB interface clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: hclk
+
required:
- compatible
- reg
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/3] regulator: qcom-refgen: correct the regulator type to CURRENT
From: Kathiravan Thirumoorthy @ 2026-06-11 9:03 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, devicetree, Kathiravan Thirumoorthy,
stable
In-Reply-To: <20260611-ipq9650_refgen-v2-0-d96a91d5b99e@oss.qualcomm.com>
As per the REFGEN IP team, this block supplies the reference current to
the PHYs in the SoC. So, correct the regulator type to REGULATOR_CURRENT
to match with the HW behavior.
Fixes: 7cbfbe237960 ("regulator: Introduce Qualcomm REFGEN regulator driver")
Cc: stable@vger.kernel.org
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
drivers/regulator/qcom-refgen-regulator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/qcom-refgen-regulator.c b/drivers/regulator/qcom-refgen-regulator.c
index 299ac3c8c3bc..6a3795469927 100644
--- a/drivers/regulator/qcom-refgen-regulator.c
+++ b/drivers/regulator/qcom-refgen-regulator.c
@@ -66,7 +66,7 @@ static const struct regulator_desc sdm845_refgen_desc = {
.enable_time = 5,
.name = "refgen",
.owner = THIS_MODULE,
- .type = REGULATOR_VOLTAGE,
+ .type = REGULATOR_CURRENT,
.ops = &(const struct regulator_ops) {
.enable = qcom_sdm845_refgen_enable,
.disable = qcom_sdm845_refgen_disable,
@@ -82,7 +82,7 @@ static const struct regulator_desc sm8250_refgen_desc = {
.enable_time = 5,
.name = "refgen",
.owner = THIS_MODULE,
- .type = REGULATOR_VOLTAGE,
+ .type = REGULATOR_CURRENT,
.ops = &(const struct regulator_ops) {
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/3] Add support for the REFGEN in the IPQ9650 SoC
From: Kathiravan Thirumoorthy @ 2026-06-11 9:03 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, devicetree, Kathiravan Thirumoorthy,
stable
IPQ9650 SoC has 2 REFGEN blocks providing the reference current to
the PCIe and USB, UNIPHY PHYs. For the other SoCs, clocks for this block
is enabled on power up but that's not the case for IPQ9650 and we have
to explicitly enable those clocks.
Document the same and add support for it.
Correct the regulator type to REGULATOR_CURRENT, as the REFGEN block
supplies the reference current to PHYs in the SoC, per the REFGEN IP
team, aligning it with the hardware behavior.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
Changes in v2:
- New patch 1/3 - change the regulator type to align with HW behavior
- Add the constraints for clock and clock-names property in the binding
- Read the REFGEN_STATUS register to find out the regulator is enabled
- Dropped the unused slab.h
- Link to v1: https://patch.msgid.link/20260602-ipq9650_refgen-v1-0-55e2afa5ff64@oss.qualcomm.com
To: Liam Girdwood <lgirdwood@gmail.com>
To: Mark Brown <broonie@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Konrad Dybcio <konradybcio@kernel.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Kathiravan Thirumoorthy (3):
regulator: qcom-refgen: correct the regulator type to CURRENT
regulator: dt-bindings: qcom,sdm845-refgen-regulator: Document IPQ9650
regulator: qcom-refgen: add support for the IPQ9650 SoC
.../regulator/qcom,sdm845-refgen-regulator.yaml | 25 ++++++
drivers/regulator/qcom-refgen-regulator.c | 93 ++++++++++++++++++++--
2 files changed, 112 insertions(+), 6 deletions(-)
---
base-commit: abe651837cb394f76d738a7a747322fca3bf17ba
change-id: 20260520-ipq9650_refgen-196b570d8bc0
Best regards,
--
Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pinctrl: qcom,pmic-gpio: Document PMG1110 GPIO support
From: Krzysztof Kozlowski @ 2026-06-11 9:02 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Bjorn Andersson, Linus Walleij, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, David Collins,
Subbaraman Narayanamurthy, Kamal Wadhwa, kernel, linux-gpio,
devicetree, linux-kernel
In-Reply-To: <20260610-pmg1110-gpio-v1-1-a9c50cd8b5d9@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 12:05:46AM -0700, Fenglin Wu wrote:
> Update the binding documentation to include the compatible string for
> PMG1110 PMIC which is used on Maili platform.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 3/6] dt-bindings: sound: qcom,q6dsp-lpass-ports: add Audio IF clocks
From: Krzysztof Kozlowski @ 2026-06-11 8:59 UTC (permalink / raw)
To: Prasad Kumpatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
Srinivas Kandagatla
Cc: linux-arm-msm, linux-sound, devicetree, linux-kernel
In-Reply-To: <20260610154517.134570-4-prasad.kumpatla@oss.qualcomm.com>
On 10/06/2026 17:45, Prasad Kumpatla wrote:
> Add the LPASS Audio IF clock IDs used by newer backend interfaces.
>
> Platforms using Audio IF module backends request the interface bit
> clocks through q6prm. Add the Audio IF IBIT and EBIT IDs to the binding
> header so these clocks can be referenced from device trees.
>
> Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
> ---
> .../sound/qcom,q6dsp-lpass-ports.h | 57 +++++++++++++++++++
> 1 file changed, 57 insertions(+)
>
> diff --git a/include/dt-bindings/sound/qcom,q6dsp-lpass-ports.h b/include/dt-bindings/sound/qcom,q6dsp-lpass-ports.h
> index 45850f2d4..bc860fcbf 100644
> --- a/include/dt-bindings/sound/qcom,q6dsp-lpass-ports.h
> +++ b/include/dt-bindings/sound/qcom,q6dsp-lpass-ports.h
> @@ -233,6 +233,63 @@
> /* Clock ID for RX CORE MCLK2 2X MCLK */
> #define LPASS_CLK_ID_RX_CORE_MCLK2_2X_MCLK 70
>
> +/** Clock ID of the Audio Intf 0 internal bit clock (IBIT). */
> +#define LPASS_CLK_ID_AUD_INTF0_IBIT 71
Missing indent
> +/** Clock ID of the Audio Intf 0 external bit clock (EBIT). */
This is not kerneldoc. Please do not introduce your own style.
> +#define LPASS_CLK_ID_AUD_INTF0_EBIT 72
Why everything has "AUD" middle prefix? What is Audio IF and how does it
differ from Audio on this device? IOW, Why Audio has to be specified? Is
there non-Audio block?
> +/** Clock ID of the Audio Intf 1 internal bit clock (IBIT). */
All these comments are pointless - you repeat the define name. Explain
once what is ibit, ebit etc, not every time.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 5/5] ARM: dts: stm32: reorder mdma1 node in stm32mp15*-scmi.dts
From: Amelie Delaunay @ 2026-06-11 8:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue
Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel,
Amelie Delaunay
In-Reply-To: <20260611-node_reordering-v1-0-7e519f2cb456@foss.st.com>
In the ST board DTS files, the &label entries must be ordered
alphanumerically.
The nodes became misordered when mlahb was replaced by m4_rproc.
Move mdma1 to the right place to avoid future misordering.
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
---
arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts | 8 ++++----
arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts | 8 ++++----
arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts | 8 ++++----
arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts | 8 ++++----
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts b/arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts
index 847b360f02fc..53e40e2f776b 100644
--- a/arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts
+++ b/arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts
@@ -51,10 +51,6 @@ &iwdg2 {
clocks = <&rcc IWDG2>, <&scmi_clk CK_SCMI_LSI>;
};
-&mdma1 {
- resets = <&scmi_reset RST_SCMI_MDMA>;
-};
-
&m4_rproc {
/delete-property/ st,syscfg-holdboot;
resets = <&scmi_reset RST_SCMI_MCU>,
@@ -62,6 +58,10 @@ &m4_rproc {
reset-names = "mcu_rst", "hold_boot";
};
+&mdma1 {
+ resets = <&scmi_reset RST_SCMI_MDMA>;
+};
+
&optee {
interrupt-parent = <&intc>;
interrupts = <GIC_PPI 15 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
diff --git a/arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts b/arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts
index 43280289759d..0790ed426ebc 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts
@@ -57,10 +57,6 @@ &iwdg2 {
clocks = <&rcc IWDG2>, <&scmi_clk CK_SCMI_LSI>;
};
-&mdma1 {
- resets = <&scmi_reset RST_SCMI_MDMA>;
-};
-
&m4_rproc {
/delete-property/ st,syscfg-holdboot;
resets = <&scmi_reset RST_SCMI_MCU>,
@@ -68,6 +64,10 @@ &m4_rproc {
reset-names = "mcu_rst", "hold_boot";
};
+&mdma1 {
+ resets = <&scmi_reset RST_SCMI_MDMA>;
+};
+
&optee {
interrupt-parent = <&intc>;
interrupts = <GIC_PPI 15 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
diff --git a/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts b/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts
index 6f27d794d270..0a3894aff4ae 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts
@@ -56,10 +56,6 @@ &iwdg2 {
clocks = <&rcc IWDG2>, <&scmi_clk CK_SCMI_LSI>;
};
-&mdma1 {
- resets = <&scmi_reset RST_SCMI_MDMA>;
-};
-
&m4_rproc {
/delete-property/ st,syscfg-holdboot;
resets = <&scmi_reset RST_SCMI_MCU>,
@@ -67,6 +63,10 @@ &m4_rproc {
reset-names = "mcu_rst", "hold_boot";
};
+&mdma1 {
+ resets = <&scmi_reset RST_SCMI_MDMA>;
+};
+
&optee {
interrupt-parent = <&intc>;
interrupts = <GIC_PPI 15 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
diff --git a/arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts b/arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts
index 6ae391bffee5..c2b6efb1cbb7 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts
@@ -61,10 +61,6 @@ &m_can1 {
clocks = <&scmi_clk CK_SCMI_HSE>, <&rcc FDCAN_K>;
};
-&mdma1 {
- resets = <&scmi_reset RST_SCMI_MDMA>;
-};
-
&m4_rproc {
/delete-property/ st,syscfg-holdboot;
resets = <&scmi_reset RST_SCMI_MCU>,
@@ -72,6 +68,10 @@ &m4_rproc {
reset-names = "mcu_rst", "hold_boot";
};
+&mdma1 {
+ resets = <&scmi_reset RST_SCMI_MDMA>;
+};
+
&optee {
interrupt-parent = <&intc>;
interrupts = <GIC_PPI 15 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
--
2.43.0
^ permalink raw reply related
* [PATCH 4/5] ARM: dts: stm32: reorder cs_cti_trace node in stm32mp157c-ev1.dts
From: Amelie Delaunay @ 2026-06-11 8:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue
Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel,
Amelie Delaunay
In-Reply-To: <20260611-node_reordering-v1-0-7e519f2cb456@foss.st.com>
In the ST board DTS files, the &label entries must be ordered
alphanumerically.
The nodes became misordered when Coresight support was added.
Move cs_cti_trace to the right place to avoid future misordering.
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
---
arch/arm/boot/dts/st/stm32mp157c-ev1.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/st/stm32mp157c-ev1.dts b/arch/arm/boot/dts/st/stm32mp157c-ev1.dts
index 0e65a1862eb5..eaab09e1755f 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-ev1.dts
@@ -81,15 +81,15 @@ &cec {
status = "okay";
};
-&cs_cti_trace {
+&cs_cti_cpu0 {
status = "okay";
};
-&cs_cti_cpu0 {
+&cs_cti_cpu1 {
status = "okay";
};
-&cs_cti_cpu1 {
+&cs_cti_trace {
status = "okay";
};
--
2.43.0
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: stm32: reorder cs_cti_trace node in stm32mp15xx-dkx.dtsi
From: Amelie Delaunay @ 2026-06-11 8:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue
Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel,
Amelie Delaunay
In-Reply-To: <20260611-node_reordering-v1-0-7e519f2cb456@foss.st.com>
In the ST board DTS files, the &label entries must be ordered
alphanumerically.
The nodes became misordered when Coresight support was added.
Move cs_cti_trace to the right place to avoid future misordering.
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
---
arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi b/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi
index 599ea07bdb19..956509cef321 100644
--- a/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi
@@ -155,15 +155,15 @@ &crc1 {
status = "okay";
};
-&cs_cti_trace {
+&cs_cti_cpu0 {
status = "okay";
};
-&cs_cti_cpu0 {
+&cs_cti_cpu1 {
status = "okay";
};
-&cs_cti_cpu1 {
+&cs_cti_trace {
status = "okay";
};
--
2.43.0
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: stm32: reorder cs_cti_trace node in stm32mp135f-dk.dts
From: Amelie Delaunay @ 2026-06-11 8:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue
Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel,
Amelie Delaunay
In-Reply-To: <20260611-node_reordering-v1-0-7e519f2cb456@foss.st.com>
In the ST board DTS files, the &label entries must be ordered
alphanumerically.
The nodes became misordered when Coresight support was added.
Move cs_cti_trace to the right place to avoid future misordering.
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
---
arch/arm/boot/dts/st/stm32mp135f-dk.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/st/stm32mp135f-dk.dts b/arch/arm/boot/dts/st/stm32mp135f-dk.dts
index 6022e73f58af..bc3050a9bec5 100644
--- a/arch/arm/boot/dts/st/stm32mp135f-dk.dts
+++ b/arch/arm/boot/dts/st/stm32mp135f-dk.dts
@@ -190,11 +190,11 @@ &cryp {
status = "okay";
};
-&cs_cti_trace {
+&cs_cti_cpu0 {
status = "okay";
};
-&cs_cti_cpu0 {
+&cs_cti_trace {
status = "okay";
};
--
2.43.0
^ permalink raw reply related
* [PATCH 1/5] arm64: dts: st: reorder ommanager node in stm32mp257f-ev1.dts
From: Amelie Delaunay @ 2026-06-11 8:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue
Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel,
Amelie Delaunay
In-Reply-To: <20260611-node_reordering-v1-0-7e519f2cb456@foss.st.com>
In the ST board DTS files, the &label entries must be ordered
alphanumerically.
The nodes became misordered when &ommanager and &lptimer3 were added
simultaneouly. After that, <dc and &lvds used the &lptimers position
as a reference.
Move ommanager at the right place to avoid future misordering.
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
---
arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 56 +++++++++++++++---------------
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
index 14e033f365e3..f044331b8b55 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
@@ -307,34 +307,6 @@ &i2c8 {
/delete-property/dma-names;
};
-&ommanager {
- memory-region = <&mm_ospi1>;
- memory-region-names = "ospi1";
- pinctrl-0 = <&ospi_port1_clk_pins_a
- &ospi_port1_io03_pins_a
- &ospi_port1_cs0_pins_a>;
- pinctrl-1 = <&ospi_port1_clk_sleep_pins_a
- &ospi_port1_io03_sleep_pins_a
- &ospi_port1_cs0_sleep_pins_a>;
- pinctrl-names = "default", "sleep";
- status = "okay";
-
- spi@0 {
- #address-cells = <1>;
- #size-cells = <0>;
- memory-region = <&mm_ospi1>;
- status = "okay";
-
- flash0: flash@0 {
- compatible = "jedec,spi-nor";
- reg = <0>;
- spi-rx-bus-width = <4>;
- spi-tx-bus-width = <4>;
- spi-max-frequency = <50000000>;
- };
- };
-};
-
/* use LPTIMER with tick broadcast for suspend mode */
&lptimer3 {
status = "okay";
@@ -374,6 +346,34 @@ lvds_out0: endpoint {
};
};
+&ommanager {
+ memory-region = <&mm_ospi1>;
+ memory-region-names = "ospi1";
+ pinctrl-0 = <&ospi_port1_clk_pins_a
+ &ospi_port1_io03_pins_a
+ &ospi_port1_cs0_pins_a>;
+ pinctrl-1 = <&ospi_port1_clk_sleep_pins_a
+ &ospi_port1_io03_sleep_pins_a
+ &ospi_port1_cs0_sleep_pins_a>;
+ pinctrl-names = "default", "sleep";
+ status = "okay";
+
+ spi@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ memory-region = <&mm_ospi1>;
+ status = "okay";
+
+ flash0: flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
+ spi-max-frequency = <50000000>;
+ };
+ };
+};
+
&pcie_ep {
pinctrl-names = "default", "init";
pinctrl-0 = <&pcie_pins_a>;
--
2.43.0
^ permalink raw reply related
* [PATCH 0/5] ARM/arm64: dts: st: fix node ordering in ST board device trees
From: Amelie Delaunay @ 2026-06-11 8:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue
Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel,
Amelie Delaunay
In the ST board DTS files, &label entries must be ordered
alphanumerically.
Over time, several nodes ended up out of order as a side effect of
adding new features or refactoring existing ones.
This series restores the correct alphanumeric ordering across
all ST board DTS files, with no functional change.
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
---
Amelie Delaunay (5):
arm64: dts: st: reorder ommanager node in stm32mp257f-ev1.dts
ARM: dts: stm32: reorder cs_cti_trace node in stm32mp135f-dk.dts
ARM: dts: stm32: reorder cs_cti_trace node in stm32mp15xx-dkx.dtsi
ARM: dts: stm32: reorder cs_cti_trace node in stm32mp157c-ev1.dts
ARM: dts: stm32: reorder mdma1 node in stm32mp15*-scmi.dts
arch/arm/boot/dts/st/stm32mp135f-dk.dts | 4 +-
arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts | 8 ++--
arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts | 8 ++--
arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts | 8 ++--
arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts | 8 ++--
arch/arm/boot/dts/st/stm32mp157c-ev1.dts | 6 +--
arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi | 6 +--
arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 56 +++++++++++++--------------
8 files changed, 52 insertions(+), 52 deletions(-)
---
base-commit: fba4a31a7f3b6b29b01c83180f83e7ed4c398738
change-id: 20260611-node_reordering-4b9b132b007f
Best regards,
--
Amelie Delaunay <amelie.delaunay@foss.st.com>
^ permalink raw reply
* Re: [PATCH 1/4] arm64: dts: qcom: glymur-crd: Update VREG l2b_e0 and l9b_e0 voltage for SD-card
From: Konrad Dybcio @ 2026-06-11 8:58 UTC (permalink / raw)
To: Monish Chunara, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Nitin Rawat, Pradeep Pragallapati, Komal Bajaj, Sachin,
linux-arm-msm, devicetree, linux-kernel, Kamal Wadhwa
In-Reply-To: <20260610111508.3941207-2-mchunara@oss.qualcomm.com>
On 6/10/26 1:15 PM, Monish Chunara wrote:
> From: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
>
> SD cards may need 1.8v VDDIO also to be supported, to accommodate this
> requirement reduce the min voltage to 1.8v for `vreg_l2b_e0` which
> supplies to VDDIO pin of SD card.
>
> NOTE - Since this SD card is the only client on this regulator, this
> change should not have any side effect on any other clients.
> moreover, SD card driver takes care to explicitly vote for the
> regulator voltage based on the SD card detection sequence.
>
> Also for stable operation of the SD card increase VDD voltage
> supplied by `vreg_l9b_e0` to 2.96v.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 08/16] Revert "dt-bindings: usb: mediatek,mtk-xhci: Add port for SuperSpeed EP"
From: Bartosz Golaszewski @ 2026-06-11 8:57 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Alan Stern, linux-acpi, driver-core, linux-pm, linux-usb,
devicetree, linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam, Bartosz Golaszewski, Greg Kroah-Hartman,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
In-Reply-To: <20260610084053.2059858-9-wenst@chromium.org>
On Wed, 10 Jun 2026 10:40:42 +0200, Chen-Yu Tsai <wenst@chromium.org> said:
> This reverts commit 454a1e3cd36c113341d7b71e8e691c6e47ab4a8a.
>
> mtk-xhci handles both USB 2.0 High Speed (HS) and USB 3.x SuperSpeed
> (SS) host connections. And there are USB 2.0 only mtk-xhci blocks.
> The SSUSB controller handles the device or gadget mode. Saying that
> SSUSB handles the HS portion is wrong.
>
> Fixes: 454a1e3cd36c ("dt-bindings: usb: mediatek,mtk-xhci: Add port for SuperSpeed EP")
> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Maybe put it in the front of the series?
Bart
^ permalink raw reply
* Re: [PATCH] dt-bindings: soc: qcom: qcom,pmic-glink: Add Maili compatible string
From: Krzysztof Kozlowski @ 2026-06-11 8:55 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, David Collins,
Subbaraman Narayanamurthy, Kamal Wadhwa, kernel, devicetree,
linux-kernel
In-Reply-To: <20260610-maili-pmic-glink-v1-1-a6ba02d6deba@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 12:10:13AM -0700, Fenglin Wu wrote:
> Maili is a mobile platform that is compatible with Hawi and Kaanapali
> platform with respect to pmic-glink support. Add Maili compatible string
> with Kaanapali as a fallback.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: shikra: Add BAM-DMUX support
From: Stephan Gerhold @ 2026-06-11 8:55 UTC (permalink / raw)
To: Vishnu Santhosh
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
bjorn.andersson, chris.lew
In-Reply-To: <20260611-qcom-shikra-dts-bam-dmux-v1-1-43d0b43d41ef@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 02:11:59PM +0530, Vishnu Santhosh wrote:
> Add required nodes to enable the upstream BAM-DMUX WWAN driver on
> Qualcomm Shikra SoC.
>
> The SMSM (Shared Memory State Machine) node provides the power
> control signaling between the AP and modem for BAM-DMUX. The
> BAM DMA controller node describes the A2 modem BAM hardware as a
> standard DMA controller. The BAM-DMUX node references the DMA
> channels and the pc/pc-ack interrupt lines from the modem SMSM
> entry for power control signaling.
>
> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
I'm quite surprised to see this 15+ years(?) old hardware block being
brought back to a new SoC. Is Shikra not using IPA?
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 51 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index a4334d99c1f35ee851ca8266ec37d4a200a07ee5..3e59d5f6323c0d857f376316faa26c503e67f6bc 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -17,6 +17,23 @@ / {
> #address-cells = <2>;
> #size-cells = <2>;
>
> + bam_dmux: bam-dmux {
> + compatible = "qcom,bam-dmux";
> +
> + interrupts-extended = <&modem_smsm 1 IRQ_TYPE_EDGE_BOTH>,
> + <&modem_smsm 11 IRQ_TYPE_EDGE_BOTH>;
> + interrupt-names = "pc",
> + "pc-ack";
> +
> + qcom,smem-states = <&apps_smsm 1>,
> + <&apps_smsm 11>;
> + qcom,smem-state-names = "pc",
> + "pc-ack";
> +
> + dmas = <&bam_dmux_dma 4>, <&bam_dmux_dma 5>;
> + dma-names = "tx", "rx";
> + };
This should be a child node of the modem remoteproc. See msm8916.dtsi
for example.
> +
> clocks {
> xo_board: xo-board {
> compatible = "fixed-clock";
> @@ -314,6 +331,28 @@ lmcu_dtb_mem: lmcu-dtb@b4702000 {
> };
> };
>
> + smsm {
> + compatible = "qcom,smsm";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mboxes = <0>, <&apcs_glb 13>;
> +
> + apps_smsm: apps@0 {
> + reg = <0>;
> + #qcom,smem-state-cells = <1>;
> + };
> +
> + modem_smsm: modem@1 {
> + reg = <1>;
> + interrupts = <GIC_SPI 69 IRQ_TYPE_EDGE_RISING 0>;
> +
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> + };
> +
> soc: soc@0 {
> compatible = "simple-bus";
>
> @@ -640,6 +679,18 @@ &clk_virt SLAVE_QUP_CORE_0 RPM_ALWAYS_TAG>,
> };
> };
>
> + bam_dmux_dma: dma-controller@6044000 {
> + compatible = "qcom,bam-v1.7.0";
> + reg = <0x0 0x06044000 0x0 0x19000>;
> + interrupts = <GIC_SPI 74 IRQ_TYPE_EDGE_RISING 0>;
> + #dma-cells = <1>;
> + qcom,ee = <0>;
> +
> + num-channels = <6>;
> + qcom,num-ees = <1>;
> + qcom,powered-remotely;
> + };
> +
> sram@c11e000 {
> compatible = "qcom,shikra-imem", "mmio-sram";
> reg = <0x0 0x0c11e000 0x0 0x1000>;
>
> ---
> base-commit: ba3e43a9e601636f5edb54e259a74f96ca3b8fd8
> change-id: 20260603-qcom-shikra-dts-bam-dmux-7fdcbb6fb662
> prerequisite-message-id: <20260527-shikra-dt-v4-0-b5ca1fa0b392@oss.qualcomm.com>
> prerequisite-patch-id: 3a689e8dda5fd2755b689d94d095806b3f2e6eed
> prerequisite-patch-id: 2acc300a68ed8c5364fb5f2f7d28fc0d56ab07bf
> prerequisite-patch-id: 2357cac636e019eaf14d6a493a1c72bca56fe405
> prerequisite-patch-id: 2885f299e711582da312ca9d13983d296a3dd5dc
> prerequisite-patch-id: 91af5f3c01e766a53ce8de69aa21847a2d6bbbf8
>
If the DT isn't merged yet, you can also just squash that into the
existing series that adds the modem remoteproc.
Thanks,
Stephan
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: qcom,spmi-pmic: Document PMG1110
From: Krzysztof Kozlowski @ 2026-06-11 8:54 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stephen Boyd, David Collins,
Subbaraman Narayanamurthy, Kamal Wadhwa, kernel, devicetree,
linux-kernel
In-Reply-To: <20260609-pmg1110-v1-1-6604d0adc907@oss.qualcomm.com>
On Tue, Jun 09, 2026 at 11:49:59PM -0700, Fenglin Wu wrote:
> Add compatible string for PMG1110 which is used on Maili platform.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: spmi: glymur-spmi-pmic-arb: Add compatible for Qualcomm Maili SoC
From: Krzysztof Kozlowski @ 2026-06-11 8:53 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-kernel, devicetree
In-Reply-To: <20260609-maili-spmi-binding-v1-1-80fc4b6bb80f@oss.qualcomm.com>
On Tue, Jun 09, 2026 at 11:29:24PM -0700, Fenglin Wu wrote:
> The PMIC arbiter in the Qualcomm Maili SoC is version v8.5, which
> is the same with Hawi and compatible with Glymur. Hence, add a string
> for "qcom,maili-spmi-pmic-arb" as a compatible entry for
> "qcom,glymur-spmi-pmic-arb".
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/spmi/qcom,glymur-spmi-pmic-arb.yaml | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 2/3] clk: qcom: camcc-glymur: Add camera clock controller driver
From: Konrad Dybcio @ 2026-06-11 8:51 UTC (permalink / raw)
To: Bryan O'Donoghue, Jagadeesh Kona, Bjorn Andersson,
Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Taniya Das
In-Reply-To: <639c94f9-6f62-4502-ad7e-5ae60f5f6d02@kernel.org>
On 5/25/26 9:49 AM, Bryan O'Donoghue wrote:
> On 25/05/2026 08:06, Jagadeesh Kona wrote:
>>> That's not in your overview letter so generally I'd advise to include things like "did X because Y" - "didn't do Q because Z" anyway, how does it make a difference if the values are static ?
>>>
>>> They are no less magic numbers that way.
>>>
>>> What exactly is the resistance to defining the bits ?
>>>
>>> I'll state again - when a vendor is submitting something upstream where that vendor 100% controls their own documentation - there's no reason at all to be presenting magic hex numbers - even more the case with generated code.
>>>
>>> Just update the script to enumerate the bit fields, I honestly don't get the aversion.
>>>
>> Hi Bryan,
>>
>> There’s no standard interface for these bits, and bit definitions/fields vary across PLL types.
>> So, common macros aren’t feasible and would need redefinitions per controller. Since these bits
>> are not reused elsewhere
>
> - Asking for named bits not common macros
> - Reuse isn't why you name a bit
>
> , IMO directly using values from the hardware documentation keeps the
>> implementation simpler, avoids unnecessary abstraction, and makes debugging—through direct
>> comparison with the hardware spec easier.
>
> How are hex values in upstream code easier to debug ?
>
> Without the spec you can't change or understand hex values in upstream code, which is the whole point I'm making here.
I get the 'understanding' part, but regarding change, as I said
previously, these must remain as-is - any difference for a PLL
impacts every single clock downstream of it. Some of them also
correspond to specific electrical properties, just like with PHY
init sequences. The existing values are a result of tuning and
silicon validation across presumably many, many chip units.
There may be updates (very rarely post the chip going into
production), but I'd assume these would go through the same
testing procedures
Konrad
^ permalink raw reply
* Re: [PATCH] dt-bindings: power: qcom,rpmpd: document RPMh power domain for Maili
From: Krzysztof Kozlowski @ 2026-06-11 8:47 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, devicetree, linux-kernel
In-Reply-To: <20260609-maili-rpmhpd-v1-1-c8f976377726@oss.qualcomm.com>
On Tue, Jun 09, 2026 at 10:43:31PM -0700, Fenglin Wu wrote:
> Qualcomm Maili SoC has exactly the same RPMh power domains as Qualcomm
> Hawi SoC. Add "qcom,maili-rpmhpd" string as a compatible entry for
> "qcom,hawi-rpmhpd".
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v10] PCI: mediatek: Add support for EcoNet EN7528 SoC
From: sashiko-bot @ 2026-06-11 8:47 UTC (permalink / raw)
To: Caleb James DeLisle; +Cc: conor+dt, devicetree, linux-pci, robh
In-Reply-To: <20260611082329.243515-1-cjd@cjdns.fr>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
New issues:
- [High] Premature loop termination in `mtk_pcie_retrain` prevents remaining root ports from being retrained.
- [Low] Calling `dev_err_probe()` on a child device from the parent's probe context.
Pre-existing issues:
- [High] IRQ domains are leaked and leave dangling pointers when a PCIe port fails to start up.
- [High] The PCIe port startup callbacks sleep while executing in the atomic noirq system resume phase.
- [High] The `resource_size(mem)` parameter is silently truncated on 64-bit platforms because `fls()` only accepts a 32-bit unsigned int.
--
commit f0ee2a994c044496f2233db60f4bbc71d16d530c
Author: Caleb James DeLisle <cjd@cjdns.fr>
Date: Thu Jun 11 08:23:28 2026 +0000
PCI: mediatek: Add support for EcoNet EN7528 SoC
Add support for the PCIe present on the EcoNet EN7528 (and EN751221) SoCs.
These SoCs have a mix of Gen1 and Gen2 capable ports, but the Gen2 ports
require re-training after startup.
Co-developed-by: Ahmed Naseef <naseefkm@gmail.com>
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 6d0ee089ca74b..f4963af0d6085 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
[ ... ]
> @@ -750,6 +761,134 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
> return 0;
> }
>
> +static int mtk_pcie_startup_port_en7528(struct mtk_pcie_port *port)
> +{
> + struct mtk_pcie *pcie = port->pcie;
> + struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
[ ... ]
> + /* Assert all reset signals */
> + writel(0, port->base + PCIE_RST_CTRL);
> +
> + /*
> + * Enable PCIe link down reset, if link status changed from link up to
> + * link down, this will reset MAC control registers and configuration
> + * space.
> + */
> + writel(PCIE_LINKDOWN_RST_EN, port->base + PCIE_RST_CTRL);
> +
> + msleep(PCIE_T_PVPERL_MS);
[Severity: High]
This is a pre-existing issue in the driver's power management design, but
will adding msleep() here cause a "scheduling while atomic" BUG?
The driver's PM ops configure mtk_pcie_resume_noirq() to run during the
system resume_noirq phase, which executes with local hardware interrupts
disabled.
Since mtk_pcie_resume_noirq() unconditionally calls mtk_pcie_enable_port(),
which then invokes this startup callback, will calling sleepable functions
like msleep() and regmap_read_poll_timeout() here trigger a panic during
system resume?
> +
> + /* De-assert PHY, PE, PIPE, MAC and configuration reset */
> + val = readl(port->base + PCIE_RST_CTRL);
> + val |= PCIE_PHY_RSTB | PCIE_PERSTB | PCIE_PIPE_SRSTB |
> + PCIE_MAC_SRSTB | PCIE_CRSTB;
> + writel(val, port->base + PCIE_RST_CTRL);
> +
> + writel(PCIE_CLASS_CODE | PCIE_REVISION_ID,
> + port->base + PCIE_CONF_REV_CLASS);
> + writel(EN7528_HOST_MODE, port->base);
> +
> + link_mask = (port->slot == 0) ? EN7528_RC0_LINKUP : EN7528_RC1_LINKUP;
> +
> + /* 100ms timeout value should be enough for Gen1/2 training */
> + err = regmap_read_poll_timeout(pcie->cfg, EN7528_LINKUP_REG, val,
> + !!(val & link_mask), 20,
> + PCI_PM_D3COLD_WAIT * USEC_PER_MSEC);
> + if (err) {
> + dev_err(pcie->dev, "EN7528: port%d link timeout\n", port->slot);
> + return -ETIMEDOUT;
[Severity: High]
This is a pre-existing issue, but does returning an error here leak IRQ
domains?
When this function returns -ETIMEDOUT for an empty slot, the caller
mtk_pcie_enable_port() executes its error path and calls
mtk_pcie_port_free().
However, mtk_pcie_port_free() frees the port struct using devm_kfree(), but
it never tears down the IRQ domains using irq_domain_remove(). Does this
permanently leak the IRQ domains on every empty slot timeout and leave their
domain->host_data pointers dangling to the freed port struct?
> + }
> +
> + /* Activate INTx interrupts */
> + val = readl(port->base + PCIE_INT_MASK);
> + val &= ~INTX_MASK;
> + writel(val, port->base + PCIE_INT_MASK);
> +
> + if (IS_ENABLED(CONFIG_PCI_MSI))
> + mtk_pcie_enable_msi(port);
> +
> + /* Set AHB to PCIe translation windows */
> + val = lower_32_bits(mem->start) |
> + AHB2PCIE_SIZE(fls(resource_size(mem)));
[Severity: High]
This is a pre-existing issue, but is resource_size(mem) silently truncated
here on 64-bit platforms?
The resource_size(mem) function returns a resource_size_t, which is a 64-bit
integer on 64-bit architectures. Since fls() only accepts a 32-bit unsigned
int, if the resource size is 4GB (0x100000000) or larger, will the lower 32
bits evaluate to zero or be truncated, causing fls() to return an
incorrectly small value and misconfiguring the inbound translation window?
> + writel(val, port->base + PCIE_AHB_TRANS_BASE0_L);
[ ... ]
> +static int mtk_pcie_retrain(struct device *dev, struct pci_host_bridge *host)
> +{
> + struct pci_dev *rp;
> + int ret = -ENOENT;
> + u16 lnksta = 0;
> + u32 speed;
> +
> + /* Should already have been warned about during startup_port */
> + if (!IS_BUILTIN(CONFIG_PCIE_MEDIATEK))
> + return 0;
> +
> + guard(rwsem_read)(&pci_bus_sem);
> +
> + for_each_pci_bridge(rp, host->bus) {
> + if (pci_pcie_type(rp) != PCI_EXP_TYPE_ROOT_PORT)
> + continue;
> +
> +#if IS_BUILTIN(CONFIG_PCIE_MEDIATEK)
> + ret = pcie_retrain_link(rp, true);
> +#endif
> +
> + if (ret)
> + return dev_err_probe(&rp->dev, ret,
> + "failed to retrain port\n");
[Severity: High]
Does returning early here prevent the remaining root ports on the bus from
being retrained?
If pcie_retrain_link() fails for any port (for example, due to a timeout on
an empty slot), this aborts the loop. Since mtk_pcie_probe() intentionally
ignores the return value of mtk_pcie_retrain(), the early return doesn't
propagate the error but causes subsequent ports to be permanently stuck at
Gen1 speeds.
Should this instead log the error and continue to the next port?
[Severity: Low]
Additionally, is it correct to call dev_err_probe() on the root port
(rp->dev) here?
Since this function executes as part of the parent host controller's probe
sequence (mtk_pcie_probe()), the root port is not the device actively
probing. Will calling dev_err_probe() on a device that is not currently
probing print a misleading message (like 'probe of <device> failed')?
Should standard pci_err(rp, ...) be used instead?
> +
> + pcie_capability_read_word(rp, PCI_EXP_LNKSTA, &lnksta);
> + speed = lnksta & PCI_EXP_LNKSTA_CLS;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611082329.243515-1-cjd@cjdns.fr?part=1
^ permalink raw reply
* Re: (subset) [PATCH v4 1/2] dt-bindings: mfd: st,stmpe: Add missing properties for PWM subnode
From: Lee Jones @ 2026-06-11 8:46 UTC (permalink / raw)
To: lee, ukleinek, robh, krzk+dt, conor+dt, mcoquelin.stm32,
alexandre.torgue, linusw, Manish Baing
Cc: linux-pwm, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, Conor Dooley
In-Reply-To: <20260523173251.72540-2-manishbaing2789@gmail.com>
On Sat, 23 May 2026 17:32:50 +0000, Manish Baing wrote:
> The st,stmpe-pwm binding is already covered by the MFD schema in
> Documentation/devicetree/bindings/mfd/st,stmpe.yaml. However, the
> PWM subnode was missing a 'required' properties block. This allowed
> Device Tree nodes to pass validation even if the 'compatible'
> string was omitted. This omission could lead to probe failures
> at runtime.
>
> [...]
Applied, thanks!
[1/2] dt-bindings: mfd: st,stmpe: Add missing properties for PWM subnode
commit: b07f7904e0523170856876e4412be852377d492a
--
Lee Jones [李琼斯]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox