* [PATCH v4 6/6] regulator: mt6359: Add proper ldo_vcn33_[12] regulators
From: Chen-Yu Tsai @ 2026-05-14 9:15 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, devicetree
In-Reply-To: <20260514091520.2718987-1-wenst@chromium.org>
The ldo_vcn33_[12]_wifi and ldo_vcn33_[12]_bt are just two regulator
outputs instead of four. The wifi and bt parts refer to separate enable
bits that are OR-ed together to affect the actual regulator output. The
separate bits allow the wifi and bt stacks to enable their power without
coordination between them. These have been deprecated in favor of proper
nodes matching the output.
Add proper ldo_vcn33_[12] regulators to replace the existing ones. The
enable status is synced to just one of the two enable bits, and the
other is forced off. This makes the handling in other bits simpler.
The existing *_(bt|wifi) regulators are converted to no-op regulators
that are fed from their new respective ldo_vcn33_[12] regulator. This
allows existing device trees to continue to work.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v3:
- Fixed index off-by-one in error message in mt6359_sync_vcn33_setting()
(Sashiko)
- Added check of return value from mt6359_sync_vcn33_setting() (Sashiko)
Changes since v1:
- Instead of dropping one regulator from each output, add a new one for
each output; the existing *_(bt|wifi) ones are then supplied from the
new one
---
drivers/regulator/mt6359-regulator.c | 184 +++++++++++++++++----
include/linux/regulator/mt6359-regulator.h | 10 +-
2 files changed, 159 insertions(+), 35 deletions(-)
diff --git a/drivers/regulator/mt6359-regulator.c b/drivers/regulator/mt6359-regulator.c
index 46cafe93b24e..af0e0339fbdd 100644
--- a/drivers/regulator/mt6359-regulator.c
+++ b/drivers/regulator/mt6359-regulator.c
@@ -166,6 +166,20 @@ struct mt6359_regulator_info {
.qi = BIT(0), \
}
+#define MT6359_LDO_NOOP(match, _name, supply) \
+[MT6359_ID_##_name] = { \
+ .desc = { \
+ .name = #_name, \
+ .supply_name = supply, \
+ .of_match = of_match_ptr(match), \
+ .regulators_node = of_match_ptr("regulators"), \
+ .ops = &mt6359_noop_ops, \
+ .type = REGULATOR_VOLTAGE, \
+ .id = MT6359_ID_##_name, \
+ .owner = THIS_MODULE, \
+ }, \
+}
+
static const unsigned int vsim1_voltages[] = {
0, 0, 0, 1700000, 1800000, 0, 0, 0, 2700000, 0, 0, 3000000, 3100000,
};
@@ -475,6 +489,9 @@ static const struct regulator_ops mt6359p_vemc_ops = {
.get_status = mt6359_get_status,
};
+/* Used for backward-compatible placeholder regulators */
+static const struct regulator_ops mt6359_noop_ops = {};
+
/* The array is indexed by id(MT6359_ID_XXX) */
static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_BUCK("buck_vs1", VS1, "vsys-vs1", 800000, 2200000, 12500,
@@ -596,18 +613,12 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_DA_VCN13_B_EN_ADDR, MT6359_RG_VCN13_VOSEL_ADDR,
MT6359_RG_VCN13_VOSEL_MASK << MT6359_RG_VCN13_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, "vsys-ldo1", vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_1", VCN33_1, "vsys-ldo1", vcn33_voltages,
MT6359_RG_LDO_VCN33_1_EN_0_ADDR,
MT6359_RG_LDO_VCN33_1_EN_0_SHIFT,
MT6359_DA_VCN33_1_B_EN_ADDR, MT6359_RG_VCN33_1_VOSEL_ADDR,
MT6359_RG_VCN33_1_VOSEL_MASK <<
MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, "vsys-ldo1", vcn33_voltages,
- MT6359_RG_LDO_VCN33_1_EN_1_ADDR,
- MT6359_RG_LDO_VCN33_1_EN_1_SHIFT,
- MT6359_DA_VCN33_1_B_EN_ADDR, MT6359_RG_VCN33_1_VOSEL_ADDR,
- MT6359_RG_VCN33_1_VOSEL_MASK <<
- MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
MT6359_REG_FIXED("ldo_vaux18", VAUX18, "vsys-ldo2", MT6359_RG_LDO_VAUX18_EN_ADDR,
MT6359_DA_VAUX18_B_EN_ADDR, 1800000),
MT6359_LDO_LINEAR("ldo_vsram_others", VSRAM_OTHERS, "vs2-ldo1", 500000, 1293750,
@@ -644,18 +655,12 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_DA_VEMC_B_EN_ADDR, MT6359_RG_VEMC_VOSEL_ADDR,
MT6359_RG_VEMC_VOSEL_MASK << MT6359_RG_VEMC_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_2_bt", VCN33_2_BT, "vsys-ldo1", vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_2", VCN33_2, "vsys-ldo1", vcn33_voltages,
MT6359_RG_LDO_VCN33_2_EN_0_ADDR,
MT6359_RG_LDO_VCN33_2_EN_0_SHIFT,
MT6359_DA_VCN33_2_B_EN_ADDR, MT6359_RG_VCN33_2_VOSEL_ADDR,
MT6359_RG_VCN33_2_VOSEL_MASK <<
MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_2_wifi", VCN33_2_WIFI, "vsys-ldo1", vcn33_voltages,
- MT6359_RG_LDO_VCN33_2_EN_1_ADDR,
- MT6359_RG_LDO_VCN33_2_EN_1_SHIFT,
- MT6359_DA_VCN33_2_B_EN_ADDR, MT6359_RG_VCN33_2_VOSEL_ADDR,
- MT6359_RG_VCN33_2_VOSEL_MASK <<
- MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
MT6359_LDO("ldo_va12", VA12, "vs2-ldo2", va12_voltages,
MT6359_RG_LDO_VA12_EN_ADDR, MT6359_RG_LDO_VA12_EN_SHIFT,
MT6359_DA_VA12_B_EN_ADDR, MT6359_RG_VA12_VOSEL_ADDR,
@@ -711,6 +716,11 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_SHIFT),
+ /* Placeholders for DT backward compatibility */
+ MT6359_LDO_NOOP("ldo_vcn33_1_bt", VCN33_1_BT, "LDO_VCN33_1"),
+ MT6359_LDO_NOOP("ldo_vcn33_1_wifi", VCN33_1_WIFI, "LDO_VCN33_1"),
+ MT6359_LDO_NOOP("ldo_vcn33_2_bt", VCN33_2_BT, "LDO_VCN33_2"),
+ MT6359_LDO_NOOP("ldo_vcn33_2_wifi", VCN33_2_WIFI, "LDO_VCN33_2"),
};
static const struct mt6359_regulator_info mt6359p_regulators[] = {
@@ -835,18 +845,12 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359P_DA_VCN13_B_EN_ADDR, MT6359P_RG_VCN13_VOSEL_ADDR,
MT6359_RG_VCN13_VOSEL_MASK << MT6359_RG_VCN13_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, "vsys-ldo1", vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_1", VCN33_1, "vsys-ldo1", vcn33_voltages,
MT6359P_RG_LDO_VCN33_1_EN_0_ADDR,
MT6359_RG_LDO_VCN33_1_EN_0_SHIFT,
MT6359P_DA_VCN33_1_B_EN_ADDR, MT6359P_RG_VCN33_1_VOSEL_ADDR,
MT6359_RG_VCN33_1_VOSEL_MASK <<
MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, "vsys-ldo1", vcn33_voltages,
- MT6359P_RG_LDO_VCN33_1_EN_1_ADDR,
- MT6359P_RG_LDO_VCN33_1_EN_1_SHIFT,
- MT6359P_DA_VCN33_1_B_EN_ADDR, MT6359P_RG_VCN33_1_VOSEL_ADDR,
- MT6359_RG_VCN33_1_VOSEL_MASK <<
- MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
MT6359_REG_FIXED("ldo_vaux18", VAUX18, "vsys-ldo2", MT6359P_RG_LDO_VAUX18_EN_ADDR,
MT6359P_DA_VAUX18_B_EN_ADDR, 1800000),
MT6359_LDO_LINEAR("ldo_vsram_others", VSRAM_OTHERS, "vs2-ldo1", 500000, 1293750,
@@ -885,18 +889,12 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359P_RG_LDO_VEMC_VOSEL_0_ADDR,
MT6359P_RG_LDO_VEMC_VOSEL_0_MASK <<
MT6359P_RG_LDO_VEMC_VOSEL_0_SHIFT),
- MT6359_LDO("ldo_vcn33_2_bt", VCN33_2_BT, "vsys-ldo1", vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_2", VCN33_2, "vsys-ldo1", vcn33_voltages,
MT6359P_RG_LDO_VCN33_2_EN_0_ADDR,
MT6359P_RG_LDO_VCN33_2_EN_0_SHIFT,
MT6359P_DA_VCN33_2_B_EN_ADDR, MT6359P_RG_VCN33_2_VOSEL_ADDR,
MT6359_RG_VCN33_2_VOSEL_MASK <<
MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_2_wifi", VCN33_2_WIFI, "vsys-ldo1", vcn33_voltages,
- MT6359P_RG_LDO_VCN33_2_EN_1_ADDR,
- MT6359_RG_LDO_VCN33_2_EN_1_SHIFT,
- MT6359P_DA_VCN33_2_B_EN_ADDR, MT6359P_RG_VCN33_2_VOSEL_ADDR,
- MT6359_RG_VCN33_2_VOSEL_MASK <<
- MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
MT6359_LDO("ldo_va12", VA12, "vs2-ldo2", va12_voltages,
MT6359P_RG_LDO_VA12_EN_ADDR, MT6359P_RG_LDO_VA12_EN_SHIFT,
MT6359P_DA_VA12_B_EN_ADDR, MT6359P_RG_VA12_VOSEL_ADDR,
@@ -951,27 +949,119 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359P_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_SHIFT),
+ /* Placeholders for DT backward compatibility */
+ MT6359_LDO_NOOP("ldo_vcn33_1_bt", VCN33_1_BT, "LDO_VCN33_1"),
+ MT6359_LDO_NOOP("ldo_vcn33_1_wifi", VCN33_1_WIFI, "LDO_VCN33_1"),
+ MT6359_LDO_NOOP("ldo_vcn33_2_bt", VCN33_2_BT, "LDO_VCN33_2"),
+ MT6359_LDO_NOOP("ldo_vcn33_2_wifi", VCN33_2_WIFI, "LDO_VCN33_2"),
+};
+
+struct mt6359_vcn33_regs {
+ u32 wifi_en_reg;
+ u32 wifi_en_mask;
+ u32 bt_en_reg;
+ u32 bt_en_mask;
+};
+
+static const struct mt6359_vcn33_regs vcn33_regs[][2] = {
+ { /* MT6359 */
+ {
+ .wifi_en_reg = MT6359_RG_LDO_VCN33_1_EN_1_ADDR,
+ .wifi_en_mask = BIT(MT6359_RG_LDO_VCN33_1_EN_1_SHIFT),
+ .bt_en_reg = MT6359_RG_LDO_VCN33_1_EN_0_ADDR,
+ .bt_en_mask = BIT(MT6359_RG_LDO_VCN33_1_EN_0_SHIFT),
+ }, {
+ .wifi_en_reg = MT6359_RG_LDO_VCN33_2_EN_1_ADDR,
+ .wifi_en_mask = BIT(MT6359_RG_LDO_VCN33_2_EN_1_SHIFT),
+ .bt_en_reg = MT6359_RG_LDO_VCN33_2_EN_0_ADDR,
+ .bt_en_mask = BIT(MT6359_RG_LDO_VCN33_2_EN_0_SHIFT),
+ }
+ }, { /* MT6359P */
+ {
+ .wifi_en_reg = MT6359P_RG_LDO_VCN33_1_EN_1_ADDR,
+ .wifi_en_mask = BIT(MT6359P_RG_LDO_VCN33_1_EN_1_SHIFT),
+ .bt_en_reg = MT6359P_RG_LDO_VCN33_1_EN_0_ADDR,
+ .bt_en_mask = BIT(MT6359_RG_LDO_VCN33_1_EN_0_SHIFT),
+ }, {
+ .wifi_en_reg = MT6359P_RG_LDO_VCN33_2_EN_1_ADDR,
+ .wifi_en_mask = BIT(MT6359_RG_LDO_VCN33_2_EN_1_SHIFT),
+ .bt_en_reg = MT6359P_RG_LDO_VCN33_2_EN_0_ADDR,
+ .bt_en_mask = BIT(MT6359P_RG_LDO_VCN33_2_EN_0_SHIFT),
+ }
+ }
};
+static int mt6359_sync_vcn33_setting(struct device *dev, unsigned int idx)
+{
+ struct mt6397_chip *mt6397 = dev_get_drvdata(dev->parent);
+ unsigned int val;
+ int ret;
+
+ /*
+ * VCN33_[12]_WIFI and VCN33_[12]_BT are two separate enable bits for
+ * the same regulator. They share the same voltage setting and output
+ * pin. Instead of having two potentially conflicting regulators, just
+ * have one regulator. Sync the two enable bits and only use one in
+ * the regulator device.
+ */
+ for (unsigned int i = 0; i < ARRAY_SIZE(vcn33_regs[0]); i++) {
+ u32 bt_en_mask = vcn33_regs[idx][i].bt_en_mask;
+ u32 wifi_en_mask = vcn33_regs[idx][i].wifi_en_mask;
+
+ ret = regmap_read(mt6397->regmap, vcn33_regs[idx][i].wifi_en_reg, &val);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to read VCN33_%u_WIFI setting\n",
+ i + 1);
+
+ if (!(val & wifi_en_mask))
+ continue;
+
+ /* Sync VCN33_[12]_WIFI enable status to VCN33_[12]_BT */
+ ret = regmap_update_bits(mt6397->regmap, vcn33_regs[idx][i].bt_en_reg,
+ bt_en_mask, bt_en_mask);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to sync VCN33_%u_WIFI setting to VCN33_%u_BT\n",
+ i + 1, i + 1);
+
+ /* Disable VCN33_[12]_WIFI */
+ ret = regmap_update_bits(mt6397->regmap, vcn33_regs[idx][i].wifi_en_reg,
+ wifi_en_mask, 0);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to disable VCN33_%u_WIFI\n", i + 1);
+ }
+
+ return 0;
+}
+
static int mt6359_regulator_probe(struct platform_device *pdev)
{
struct mt6397_chip *mt6397 = dev_get_drvdata(pdev->dev.parent);
struct regulator_config config = {};
struct regulator_dev *rdev;
const struct mt6359_regulator_info *mt6359_info;
- const char *vio18_name;
+ const char *vio18_name, *vcn33_1_name, *vcn33_2_name;
int i, hw_ver, ret;
ret = regmap_read(mt6397->regmap, MT6359P_HWCID, &hw_ver);
if (ret)
return ret;
- if (hw_ver >= MT6359P_CHIP_VER)
+ if (hw_ver >= MT6359P_CHIP_VER) {
mt6359_info = mt6359p_regulators;
- else
+ ret = mt6359_sync_vcn33_setting(&pdev->dev, 1);
+ if (ret)
+ return ret;
+ } else {
mt6359_info = mt6359_regulators;
+ ret = mt6359_sync_vcn33_setting(&pdev->dev, 0);
+ if (ret)
+ return ret;
+ }
vio18_name = mt6359_info[MT6359_ID_VIO18].desc.name;
+ vcn33_1_name = mt6359_info[MT6359_ID_VCN33_1].desc.name;
+ vcn33_2_name = mt6359_info[MT6359_ID_VCN33_2].desc.name;
config.dev = mt6397->dev;
config.regmap = mt6397->regmap;
@@ -993,6 +1083,30 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
desc = _desc;
}
+ /* Use vcn33_1's actual name as supply_name for vcn33_1_(bt|wifi) */
+ if ((i == MT6359_ID_VCN33_1_BT || i == MT6359_ID_VCN33_1_WIFI) &&
+ strcmp(desc->supply_name, vcn33_1_name) != 0) {
+ _desc = devm_kzalloc(&pdev->dev, sizeof(*_desc), GFP_KERNEL);
+ if (!_desc)
+ return -ENOMEM;
+
+ memcpy(_desc, desc, sizeof(*_desc));
+ _desc->supply_name = vcn33_1_name;
+ desc = _desc;
+ }
+
+ /* Use vcn33_2's actual name as supply_name for vcn33_2_(bt|wifi) */
+ if ((i == MT6359_ID_VCN33_2_BT || i == MT6359_ID_VCN33_2_WIFI) &&
+ strcmp(desc->supply_name, vcn33_2_name) != 0) {
+ _desc = devm_kzalloc(&pdev->dev, sizeof(*_desc), GFP_KERNEL);
+ if (!_desc)
+ return -ENOMEM;
+
+ memcpy(_desc, desc, sizeof(*_desc));
+ _desc->supply_name = vcn33_2_name;
+ desc = _desc;
+ }
+
rdev = devm_regulator_register(&pdev->dev, desc, &config);
if (IS_ERR(rdev)) {
dev_err(&pdev->dev, "failed to register %s\n", mt6359_info->desc.name);
@@ -1002,6 +1116,14 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
/* Save vio18 name for vbbck */
if (i == MT6359_ID_VIO18)
vio18_name = rdev_get_name(rdev);
+
+ /* Save vcn33_1 name for vbbck */
+ if (i == MT6359_ID_VCN33_1)
+ vcn33_1_name = rdev_get_name(rdev);
+
+ /* Save vcn33_2 name for vbbck */
+ if (i == MT6359_ID_VCN33_2)
+ vcn33_2_name = rdev_get_name(rdev);
}
return 0;
diff --git a/include/linux/regulator/mt6359-regulator.h b/include/linux/regulator/mt6359-regulator.h
index 6d6e5a58f482..ce2cd0fc9d95 100644
--- a/include/linux/regulator/mt6359-regulator.h
+++ b/include/linux/regulator/mt6359-regulator.h
@@ -29,8 +29,7 @@ enum {
MT6359_ID_VCN18,
MT6359_ID_VFE28,
MT6359_ID_VCN13,
- MT6359_ID_VCN33_1_BT,
- MT6359_ID_VCN33_1_WIFI,
+ MT6359_ID_VCN33_1,
MT6359_ID_VAUX18,
MT6359_ID_VSRAM_OTHERS,
MT6359_ID_VEFUSE,
@@ -39,8 +38,7 @@ enum {
MT6359_ID_VBIF28,
MT6359_ID_VIO28,
MT6359_ID_VEMC,
- MT6359_ID_VCN33_2_BT,
- MT6359_ID_VCN33_2_WIFI,
+ MT6359_ID_VCN33_2,
MT6359_ID_VA12,
MT6359_ID_VA09,
MT6359_ID_VRF18,
@@ -51,6 +49,10 @@ enum {
MT6359_ID_VSRAM_PROC1,
MT6359_ID_VSIM2,
MT6359_ID_VSRAM_OTHERS_SSHUB,
+ MT6359_ID_VCN33_1_BT,
+ MT6359_ID_VCN33_1_WIFI,
+ MT6359_ID_VCN33_2_BT,
+ MT6359_ID_VCN33_2_WIFI,
MT6359_ID_RG_MAX,
};
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v4 3/6] regulator: dt-bindings: mt6359: Deprecate bogus vcn33_[12]_* split regulators
From: Chen-Yu Tsai @ 2026-05-14 9:15 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, devicetree,
Krzysztof Kozlowski
In-Reply-To: <20260514091520.2718987-1-wenst@chromium.org>
vcn33_[12]_bt and vcn33_[12]_wifi refer to the same output. There are
two enable bits in the registers so that BT and WiFi drivers can toggle
them separately without any coordination. If either bit is set, then the
regulator output is enabled.
Deprecate the existing regulators, and add proper regulators matching
the outputs: vcn33_1 and vcn33_2.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes since v3:
- Added ending match to regex for deprecated vcn33_[12]_(bt|wifi) (Sashiko)
- Updated example to use proper vcn33_[12] nodes (Sashiko)
---
.../bindings/regulator/mt6359-regulator.yaml | 29 +++++++++----------
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
index ac925334ae83..e3c20412c8a7 100644
--- a/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
@@ -30,7 +30,7 @@ patternProperties:
$ref: regulator.yaml#
unevaluatedProperties: false
- "^ldo_vcn(18|13|33_1_bt|13_1_wifi|33_2_bt|33_2_wifi)$":
+ "^ldo_vcn(18|13|33_[12])$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
@@ -55,6 +55,15 @@ patternProperties:
$ref: regulator.yaml#
unevaluatedProperties: false
+ "^ldo_vcn33_[12]_(bt|wifi)$":
+ type: object
+ $ref: regulator.yaml#
+ description:
+ vcn33_[12]_(bt|wifi) are incorrect representations.
+ Use vcn33_[12] instead.
+ deprecated: true
+ unevaluatedProperties: false
+
additionalProperties: false
examples:
@@ -203,13 +212,8 @@ examples:
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <1300000>;
};
- mt6359_vcn33_1_bt_ldo_reg: ldo_vcn33_1_bt {
- regulator-name = "vcn33_1_bt";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <3500000>;
- };
- mt6359_vcn33_1_wifi_ldo_reg: ldo_vcn33_1_wifi {
- regulator-name = "vcn33_1_wifi";
+ mt6359_vcn33_1_bt_ldo_reg: ldo_vcn33_1 {
+ regulator-name = "vcn33_1";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <3500000>;
};
@@ -270,13 +274,8 @@ examples:
regulator-min-microvolt = <2500000>;
regulator-max-microvolt = <3300000>;
};
- mt6359_vcn33_2_bt_ldo_reg: ldo_vcn33_2_bt {
- regulator-name = "vcn33_2_bt";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <3500000>;
- };
- mt6359_vcn33_2_wifi_ldo_reg: ldo_vcn33_2_wifi {
- regulator-name = "vcn33_2_wifi";
+ mt6359_vcn33_2_bt_ldo_reg: ldo_vcn33_2 {
+ regulator-name = "vcn33_2";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <3500000>;
};
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v4 4/6] regulator: mt6359: const-ify regulator descriptions
From: Chen-Yu Tsai @ 2026-05-14 9:15 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, devicetree
In-Reply-To: <20260514091520.2718987-1-wenst@chromium.org>
The regulator descriptions and extended descriptions don't change at
runtime. The only reason they are not const is that the regulator
driver data is non-const.
Const-ify the descriptions and all references to them. For the driver
data, explicitly cast it to non-const void *.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/regulator/mt6359-regulator.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/regulator/mt6359-regulator.c b/drivers/regulator/mt6359-regulator.c
index c8a788858824..bcf9a476a34e 100644
--- a/drivers/regulator/mt6359-regulator.c
+++ b/drivers/regulator/mt6359-regulator.c
@@ -251,7 +251,7 @@ static int mt6359_get_status(struct regulator_dev *rdev)
{
int ret;
u32 regval;
- struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+ const struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
ret = regmap_read(rdev->regmap, info->status_reg, ®val);
if (ret != 0) {
@@ -267,7 +267,7 @@ static int mt6359_get_status(struct regulator_dev *rdev)
static unsigned int mt6359_regulator_get_mode(struct regulator_dev *rdev)
{
- struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+ const struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
int ret, regval;
ret = regmap_read(rdev->regmap, info->modeset_reg, ®val);
@@ -299,7 +299,7 @@ static unsigned int mt6359_regulator_get_mode(struct regulator_dev *rdev)
static int mt6359_regulator_set_mode(struct regulator_dev *rdev,
unsigned int mode)
{
- struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+ const struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
int ret = 0, val;
int curr_mode;
@@ -354,7 +354,7 @@ static int mt6359_regulator_set_mode(struct regulator_dev *rdev,
static int mt6359p_vemc_set_voltage_sel(struct regulator_dev *rdev,
u32 sel)
{
- struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+ const struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
int ret;
u32 val = 0;
@@ -393,7 +393,7 @@ static int mt6359p_vemc_set_voltage_sel(struct regulator_dev *rdev,
static int mt6359p_vemc_get_voltage_sel(struct regulator_dev *rdev)
{
- struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+ const struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
int ret;
u32 val = 0;
@@ -469,7 +469,7 @@ static const struct regulator_ops mt6359p_vemc_ops = {
};
/* The array is indexed by id(MT6359_ID_XXX) */
-static struct mt6359_regulator_info mt6359_regulators[] = {
+static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_BUCK("buck_vs1", VS1, 800000, 2200000, 12500,
MT6359_RG_BUCK_VS1_EN_ADDR,
MT6359_DA_VS1_EN_ADDR, MT6359_RG_BUCK_VS1_VOSEL_ADDR,
@@ -705,7 +705,7 @@ static struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_SHIFT),
};
-static struct mt6359_regulator_info mt6359p_regulators[] = {
+static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359_BUCK("buck_vs1", VS1, 800000, 2200000, 12500,
MT6359_RG_BUCK_VS1_EN_ADDR,
MT6359_DA_VS1_EN_ADDR, MT6359_RG_BUCK_VS1_VOSEL_ADDR,
@@ -950,7 +950,7 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
struct mt6397_chip *mt6397 = dev_get_drvdata(pdev->dev.parent);
struct regulator_config config = {};
struct regulator_dev *rdev;
- struct mt6359_regulator_info *mt6359_info;
+ const struct mt6359_regulator_info *mt6359_info;
int i, hw_ver, ret;
ret = regmap_read(mt6397->regmap, MT6359P_HWCID, &hw_ver);
@@ -965,7 +965,8 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
config.dev = mt6397->dev;
config.regmap = mt6397->regmap;
for (i = 0; i < MT6359_MAX_REGULATOR; i++, mt6359_info++) {
- config.driver_data = mt6359_info;
+ /* drop const here, but all uses in the driver are const */
+ config.driver_data = (void *)mt6359_info;
rdev = devm_regulator_register(&pdev->dev, &mt6359_info->desc, &config);
if (IS_ERR(rdev)) {
dev_err(&pdev->dev, "failed to register %s\n", mt6359_info->desc.name);
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v4 2/6] regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions
From: Chen-Yu Tsai @ 2026-05-14 9:15 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, devicetree,
Krzysztof Kozlowski
In-Reply-To: <20260514091520.2718987-1-wenst@chromium.org>
The name of the regulator should match what the board design specifies
for the power rail. There should be no limitations on what the name can
be, and they definitely don't always follow the PMIC's own names.
Drop the restrictions on regulator-name.
Fixes: 8771456635d5 ("dt-bindings: regulator: Add document for MT6359 regulator")
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
.../bindings/regulator/mt6359-regulator.yaml | 43 -------------------
1 file changed, 43 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
index fe4ac9350ba0..ac925334ae83 100644
--- a/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
@@ -18,84 +18,41 @@ patternProperties:
"^buck_v(s1|gpu11|modem|pu|core|s2|pa|proc2|proc1|core_sshub)$":
type: object
$ref: regulator.yaml#
-
- properties:
- regulator-name:
- pattern: "^v(s1|gpu11|modem|pu|core|s2|pa|proc2|proc1|core_sshub)$"
-
unevaluatedProperties: false
"^ldo_v(ibr|rf12|usb|camio|efuse|xo22)$":
type: object
$ref: regulator.yaml#
-
- properties:
- regulator-name:
- pattern: "^v(ibr|rf12|usb|camio|efuse|xo22)$"
-
unevaluatedProperties: false
"^ldo_v(rfck|emc|a12|a09|ufs|bbck)$":
type: object
$ref: regulator.yaml#
-
- properties:
- regulator-name:
- pattern: "^v(rfck|emc|a12|a09|ufs|bbck)$"
-
unevaluatedProperties: false
"^ldo_vcn(18|13|33_1_bt|13_1_wifi|33_2_bt|33_2_wifi)$":
type: object
$ref: regulator.yaml#
-
- properties:
- regulator-name:
- pattern: "^vcn(18|13|33_1_bt|13_1_wifi|33_2_bt|33_2_wifi)$"
-
unevaluatedProperties: false
"^ldo_vsram_(proc2|others|md|proc1|others_sshub)$":
type: object
$ref: regulator.yaml#
-
- properties:
- regulator-name:
- pattern: "^vsram_(proc2|others|md|proc1|others_sshub)$"
-
unevaluatedProperties: false
"^ldo_v(fe|bif|io)28$":
type: object
$ref: regulator.yaml#
-
- properties:
- regulator-name:
- pattern: "^v(fe|bif|io)28$"
-
unevaluatedProperties: false
"^ldo_v(aud|io|aux|rf|m)18$":
type: object
$ref: regulator.yaml#
-
- properties:
- regulator-name:
- pattern: "^v(aud|io|aux|rf|m)18$"
-
unevaluatedProperties: false
"^ldo_vsim[12]$":
type: object
$ref: regulator.yaml#
-
- properties:
- regulator-name:
- pattern: "^vsim[12]$"
-
- required:
- - regulator-name
-
unevaluatedProperties: false
additionalProperties: false
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v4 1/6] mfd: dt-bindings: mt6397: Add regulator supplies
From: Chen-Yu Tsai @ 2026-05-14 9:15 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, devicetree,
Krzysztof Kozlowski
In-Reply-To: <20260514091520.2718987-1-wenst@chromium.org>
On the MT6397 family each buck regulator has a separate supply. LDOs are
split into various groups with independent supplies. There is also a
supply for the regulator control logic.
Add descriptions for all of the supplies for the MT6359.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Lee, request from Mark:
Lee, this seems like mostly a regulator series - OK for me to apply this
patch and send you a tag for it?
Changes since v3:
- Dropped duplicate 'va09' from 'vsys-ldo2-supply' (Sashiko)
Changes since v2:
- Fix vsys-vsmps-supply property name
Changes since v1:
- Use regular expression to describe vcn33_* names
- Moved regulator supplies to top level PMIC node
- Moved changes to mfd binding
---
.../bindings/mfd/mediatek,mt6397.yaml | 50 +++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
index 05c121b0cb3d..ecdc77fafaf4 100644
--- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
@@ -225,12 +225,62 @@ properties:
description:
Pin controller
+ vsys-smps-supply:
+ description: Supply for regulator control logic
+
+patternProperties:
+ "^vsys-v[a-z]+[0-9]*-supply$":
+ description: Supplies for PMIC buck regulators
+ "^vs(ys|[12])-ldo[1-9]-supply$":
+ description: Supplies for PMIC LDO regulators
+
required:
- compatible
- regulators
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ "compatible":
+ contains:
+ const: mediatek,mt6359
+ then:
+ properties:
+ vsys-ldo1-supply:
+ description: Supply for LDOs vcn33_[12], vio28, vfe28, vibr
+ vsys-ldo2-supply:
+ description: Supply for LDOs vaux18, vbif28, vxo22, vrfck, vrfck_1,
+ vemc, vsim1, vsim2, vusb
+ vsys-vcore-supply:
+ description: Supply for buck regulator vcore
+ vsys-vgpu11-supply:
+ description: Supply for buck regulator vgpu11
+ vsys-vmodem-supply:
+ description: Supply for buck regulator vmodem
+ vsys-vpa-supply:
+ description: Supply for buck regulator vpa
+ vsys-vproc1-supply:
+ description: Supply for buck regulator vproc1
+ vsys-vproc2-supply:
+ description: Supply for buck regulator vproc2
+ vsys-vpu-supply:
+ description: Supply for buck regulator vpu
+ vsys-vs1-supply:
+ description: Supply for buck regulator vs1
+ vsys-vs2-supply:
+ description: Supply for buck regulator vs2
+ vs1-ldo1-supply:
+ description: Supply for LDOs vaud18, vcamio, vm18, vufs
+ vs1-ldo2-supply:
+ description: Supply for LDOs vcn18, vefuse, vio18, vrf18
+ vs2-ldo1-supply:
+ description:
+ Supply for LDOs vsram_proc1, vsram_proc2, vsram_others, vsram_md
+ vs2-ldo2-supply:
+ description: Supply for LDOs va09, va12, vcn13, vrf12
+
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* Re: [PATCH 5/5] arm_mpam: detect and enable MPAM-Fb PCC support
From: Ben Horgan @ 2026-05-14 9:10 UTC (permalink / raw)
To: Andre Przywara, Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla,
Catalin Marinas, Will Deacon, Rafael J . Wysocki, Len Brown,
James Morse, Reinette Chatre, Fenghua Yu
Cc: Jonathan Cameron, linux-acpi, linux-arm-kernel, linux-kernel
In-Reply-To: <81f8bea6-bcf3-4523-ae0e-3d45c32800cb@arm.com>
Hi Andre,
On 5/13/26 15:51, Andre Przywara wrote:
> Hi Ben,
>
> On 5/8/26 12:48, Ben Horgan wrote:
>> Hi Andre,
>>
>> On 4/29/26 15:13, Andre Przywara wrote:
>>> The Arm MPAM-Fb specification [1] describes a protocol to access MSC
>>> registers through a firmware interface. This requires a shared memory
>>> region to hold the message, and a mailbox to trigger the access.
>>> For ACPI this is wrapped as a PCC channel, described using existing
>>> ACPI abstractions.
>>>
>>> Add code to parse those PCC table descriptions associated with an MSC,
>>> and store the parsed information in the MSC struct.
>>> This will be used by the MPAM-Fb access wrapper code.
>>>
>>> [1] https://developer.arm.com/documentation/den0144/latest
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>> drivers/acpi/arm64/mpam.c | 2 ++
>>> drivers/resctrl/mpam_devices.c | 46 +++++++++++++++++++++++++++++++---
>>> 2 files changed, 45 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/acpi/arm64/mpam.c b/drivers/acpi/arm64/mpam.c
>>> index 99c2bdbb3314..edb4d10e8dc3 100644
>>> --- a/drivers/acpi/arm64/mpam.c
>>> +++ b/drivers/acpi/arm64/mpam.c
>>> @@ -341,6 +341,8 @@ static struct platform_device * __init acpi_mpam_parse_msc(struct acpi_mpam_msc_
>>> } else if (iface == MPAM_IFACE_PCC) {
>>> props[next_prop++] = PROPERTY_ENTRY_U32("pcc-channel",
>>> tbl_msc->base_address);
>>> + props[next_prop++] = PROPERTY_ENTRY_U32("msc-id",
>>> + tbl_msc->identifier);
>>> }
>>> acpi_mpam_parse_irqs(pdev, tbl_msc, res, &next_res);
>>> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
>>> index 62aa04cb6905..6f0d0959d3a4 100644
>>> --- a/drivers/resctrl/mpam_devices.c
>>> +++ b/drivers/resctrl/mpam_devices.c
>>> @@ -19,6 +19,7 @@
>>> #include <linux/irqdesc.h>
>>> #include <linux/list.h>
>>> #include <linux/lockdep.h>
>>> +#include <linux/mailbox_client.h>
>>> #include <linux/mutex.h>
>>> #include <linux/platform_device.h>
>>> #include <linux/printk.h>
>>> @@ -27,6 +28,9 @@
>>> #include <linux/types.h>
>>> #include <linux/workqueue.h>
>>> +#include <acpi/pcc.h>
>>> +#include <acpi/acpi_io.h>
>>> +
>>> #include "mpam_internal.h"
>>> #include "mpam_fb.h"
>>> @@ -1042,7 +1046,8 @@ static u64 mpam_msc_read_mbwu_l(struct mpam_msc *msc)
>>> mpam_mon_sel_lock_held(msc);
>>> - WARN_ON_ONCE((MSMON_MBWU_L + sizeof(u64)) > msc->mapped_hwpage_sz);
>>> + if (msc->iface == MPAM_IFACE_MMIO)
>>> + WARN_ON_ONCE((MSMON_MBWU_L + sizeof(u64)) > msc->mapped_hwpage_sz);
>>
>> This should be in a different patch.
>
> Which one, preferably? A separate one? Or patch 3/5, which adds the PCC access code?
> This one here is the patch that enables non-MMIO accesses, so I figured that's the place we should relax this check.
I thought this matched the WARN_ON_ONCE() changes in patch 3/5 but that patch just concentrates on the lower level so
I'm ok to keep it in this patch. I think you've missed a similar WARN_ON_ONCE() in mpam_msc_zero_mbwu_l() though.
>
>>
>>> WARN_ON_ONCE(!cpumask_test_cpu(smp_processor_id(), &msc->accessibility));
>>> mbwu_l_high2 = __mpam_read_reg(msc, MSMON_MBWU_L + 4);
>>> @@ -2042,10 +2047,15 @@ static void mpam_msc_drv_remove(struct platform_device *pdev)
>>> mpam_free_garbage();
>>> }
>>> +static void mpam_pcc_rx_callback(struct mbox_client *cl, void *msg)
>>> +{
>>> + /* TODO: wake up tasks blocked on this MSC's PCC channel */
>>> +}
>>> +
>>> static struct mpam_msc *do_mpam_msc_drv_probe(struct platform_device *pdev)
>>> {
>>> int err;
>>> - u32 tmp;
>>> + u32 pcc_subspace_id;
>>> struct mpam_msc *msc;
>>> struct resource *msc_res;
>>> struct device *dev = &pdev->dev;
>>> @@ -2090,7 +2100,8 @@ static struct mpam_msc *do_mpam_msc_drv_probe(struct platform_device *pdev)
>>> if (err)
>>> return ERR_PTR(err);
>>> - if (device_property_read_u32(&pdev->dev, "pcc-channel", &tmp))
>>> + if (device_property_read_u32(&pdev->dev, "pcc-channel",
>>> + &pcc_subspace_id))
>>> msc->iface = MPAM_IFACE_MMIO;
>>> else
>>> msc->iface = MPAM_IFACE_PCC;
>>> @@ -2106,6 +2117,35 @@ static struct mpam_msc *do_mpam_msc_drv_probe(struct platform_device *pdev)
>>> }
>>> msc->mapped_hwpage_sz = msc_res->end - msc_res->start;
>>> msc->mapped_hwpage = io;
>>> + } else if (msc->iface == MPAM_IFACE_PCC) {
>>> + u32 msc_id;
>>> +
>>> + msc->pcc_cl.dev = &pdev->dev;
>>> + msc->pcc_cl.rx_callback = mpam_pcc_rx_callback;
>>> + msc->pcc_cl.tx_block = false;
>>
>> How do we make sure that, for instance, a MON_SEL write has completed before we start reading
>> the associated counters? Is there an ordering guarantee?
>
> What is your concern here, exactly? To group all the accesses selected by one MON_SEL write, we have the mon_sel lock
> (now mutex) already. And on the mbox side I think we are safe because the PCC channel is exclusive, we have the per-
> channel mutex (pcc_chan_lock, in patch 3/5), and we wait for confirmation from the other end, even for writes. So as
That sounds like there is no problem then. I wasn't sure that we were waiting for confirmation of writes. We can assume
that the f/w end of the link processing the requests in the order it acknowledges them, right?
Is the waiting for confirmation of writes done by this bit of patch 3?
+ status = readl(chan->shmem + SCMI_MSG_HEADER_OFS);
+ if (FIELD_GET(MPAM_MSC_TOKEN_MASK, status) != token)
+ return -ETIMEDOUT;
> long as the MON_SEL write appears in program order before the counter read, all should be good, no? Am I missing something?
I expect that I'm the one who was missing something.
Thanks,
Ben
>
> Cheers,
> Andre
>
>>
>> Thanks,
>>
>> Ben
>>
>>> + msc->pcc_cl.tx_tout = 1000; /* 1s */
>>> + msc->pcc_cl.knows_txdone = false;
>>> +
>>> + if (device_property_read_u32(&pdev->dev, "msc-id", &msc_id)) {
>>> + pr_err("missing MPAM-Fb MSC identifier\n");
>>> + return ERR_PTR(-EINVAL);
>>> + }
>>> + msc->mpam_fb_msc_id = msc_id;
>>> +
>>> + msc->pcc_chan = pcc_mbox_request_channel(&msc->pcc_cl,
>>> + pcc_subspace_id);
>>> + if (IS_ERR(msc->pcc_chan)) {
>>> + pr_err("Failed to request MSC PCC channel\n");
>>> + return (void *)msc->pcc_chan;
>>> + }
>>> +
>>> + if (msc->pcc_chan->shmem_size < MPAM_FB_MAX_MSG_SIZE) {
>>> + pr_err("MPAM-Fb PCC channel size too small.\n");
>>> + pcc_mbox_free_channel(msc->pcc_chan);
>>> + return ERR_PTR(-ENOMEM);
>>> + }
>>> +
>>> + mutex_init(&msc->pcc_chan_lock);
>>> } else {
>>> return ERR_PTR(-EINVAL);
>>> }
>>
>
^ permalink raw reply
* Re: [PATCH v7 13/20] KVM: arm64: Apply dynamic guest counter reservations
From: James Clark @ 2026-05-14 9:10 UTC (permalink / raw)
To: Colton Lewis
Cc: alexandru.elisei, pbonzini, corbet, linux, catalin.marinas, will,
maz, oliver.upton, mizhang, joey.gouly, suzuki.poulose, yuzenghui,
mark.rutland, shuah, gankulkarni, linux-doc, linux-kernel,
linux-arm-kernel, kvmarm, linux-perf-users, linux-kselftest, kvm
In-Reply-To: <gsntzf23b6m2.fsf@coltonlewis-kvm.c.googlers.com>
On 13/05/2026 5:45 pm, Colton Lewis wrote:
> James Clark <james.clark@linaro.org> writes:
>
>> On 04/05/2026 10:18 pm, Colton Lewis wrote:
>>> Apply dynamic guest counter reservations by checking if the requested
>>> guest mask collides with any events the host has scheduled and calling
>>> pmu_perf_resched_update() with a hook that updates the mask of
>>> available counters in between schedule out and schedule in.
>
>>> Signed-off-by: Colton Lewis <coltonlewis@google.com>
>>> ---
>>> arch/arm64/kvm/pmu-direct.c | 69 ++++++++++++++++++++++++++++++++
>>> ++++
>>> include/linux/perf/arm_pmu.h | 1 +
>>> 2 files changed, 70 insertions(+)
>
>>> diff --git a/arch/arm64/kvm/pmu-direct.c b/arch/arm64/kvm/pmu-direct.c
>>> index 2252d3b905db9..14cc419dbafad 100644
>>> --- a/arch/arm64/kvm/pmu-direct.c
>>> +++ b/arch/arm64/kvm/pmu-direct.c
>>> @@ -100,6 +100,73 @@ u8 kvm_pmu_hpmn(struct kvm_vcpu *vcpu)
>>> return *host_data_ptr(nr_event_counters);
>>> }
>
>>> +/* Callback to update counter mask between perf scheduling */
>>> +static void kvm_pmu_update_mask(struct pmu *pmu, void *data)
>>> +{
>>> + struct arm_pmu *arm_pmu = to_arm_pmu(pmu);
>>> + unsigned long *new_mask = data;
>>> +
>>> + bitmap_copy(arm_pmu->cntr_mask, new_mask, ARMPMU_MAX_HWEVENTS);
>>> +}
>>> +
>>> +/**
>>> + * kvm_pmu_set_guest_counters() - Handle dynamic counter reservations
>>> + * @cpu_pmu: struct arm_pmu to potentially modify
>>> + * @guest_mask: new guest mask for the pmu
>>> + *
>>> + * Check if guest counters will interfere with current host events and
>>> + * call into perf_pmu_resched_update if a reschedule is required.
>>> + */
>>> +static void kvm_pmu_set_guest_counters(struct arm_pmu *cpu_pmu, u64
>>> guest_mask)
>>> +{
>>> + struct pmu_hw_events *cpuc = this_cpu_ptr(cpu_pmu->hw_events);
>>> + DECLARE_BITMAP(guest_bitmap, ARMPMU_MAX_HWEVENTS);
>>> + DECLARE_BITMAP(new_mask, ARMPMU_MAX_HWEVENTS);
>>> + bool need_resched = false;
>>> +
>>> + bitmap_from_arr64(guest_bitmap, &guest_mask, ARMPMU_MAX_HWEVENTS);
>>> + bitmap_copy(new_mask, cpu_pmu->hw_cntr_mask, ARMPMU_MAX_HWEVENTS);
>>> +
>>> + if (guest_mask) {
>>> + /* Subtract guest counters from available host mask */
>>> + bitmap_andnot(new_mask, new_mask, guest_bitmap,
>>> ARMPMU_MAX_HWEVENTS);
>>> +
>>> + /* Did we collide with an active host event? */
>>> + if (bitmap_intersects(cpuc->used_mask, guest_bitmap,
>>> ARMPMU_MAX_HWEVENTS)) {
>>> + int idx;
>>> +
>>> + need_resched = true;
>>> + cpuc->host_squeezed = true;
>>> +
>>> + /* Look for pinned events that are about to be preempted */
>>> + for_each_set_bit(idx, guest_bitmap, ARMPMU_MAX_HWEVENTS) {
>>> + if (test_bit(idx, cpuc->used_mask) && cpuc-
>>> >events[idx] &&
>>> + cpuc->events[idx]->attr.pinned) {
>>> + pr_warn_ratelimited("perf: Pinned host event
>>> squeezed out by KVM guest PMU partition\n");
>
>> Hi Colton,
>
>> I get "perf: Pinned host event squeezed out by KVM guest PMU partition"
>> even with arm_pmuv3.reserved_host_counters=3 for example. I would have
>> expected any non zero value to stop the warning.
>
>> I think armv8pmu_get_single_idx() needs to be changed to allocate from
>> the high end host counters first. A more complicated option would be
>> checking to see if there are any non-pinned counters in the host
>> reserved half when a new pinned counter is opened, then swapping the
>> places of the new pinned and existing non-pinned counters so pinned
>> always prefer being put into the host half. But it's probably not worth
>> doing that.
>
>> James
>
>
> I agree it makes the most sense to allocate from the top, but I'm happy
> the basic idea works.
>
Another thing I forgot to mention is that even with the ratelimited
warning, this spams the logs any time the host and guest are both using
the PMU and I'm not sure how useful that is.
>>> + break;
>>> + }
>>> + }
>>> + }
>>> + } else {
>>> + /*
>>> + * Restoring to hw_cntr_mask.
>>> + * Only resched if we previously squeezed an event.
>>> + */
>>> + if (cpuc->host_squeezed) {
>>> + need_resched = true;
>>> + cpuc->host_squeezed = false;
>>> + }
>>> + }
>>> +
>>> + if (need_resched) {
>>> + /* Collision: run full perf reschedule */
>>> + perf_pmu_resched_update(&cpu_pmu->pmu, kvm_pmu_update_mask,
>>> new_mask);
>>> + } else {
>>> + /* Host was never using guest counters anyway */
>>> + bitmap_copy(cpu_pmu->cntr_mask, new_mask, ARMPMU_MAX_HWEVENTS);
>>> + }
>>> +}
>>> +
>>> /**
>>> * kvm_pmu_host_counter_mask() - Compute bitmask of host-reserved
>>> counters
>>> * @pmu: Pointer to arm_pmu struct
>>> @@ -218,6 +285,7 @@ void kvm_pmu_load(struct kvm_vcpu *vcpu)
>
>>> pmu = vcpu->kvm->arch.arm_pmu;
>>> guest_counters = kvm_pmu_guest_counter_mask(pmu);
>>> + kvm_pmu_set_guest_counters(pmu, guest_counters);
>>> kvm_pmu_apply_event_filter(vcpu);
>
>>> for_each_set_bit(i, &guest_counters, ARMPMU_MAX_HWEVENTS) {
>>> @@ -319,5 +387,6 @@ void kvm_pmu_put(struct kvm_vcpu *vcpu)
>>> val = read_sysreg(pmintenset_el1);
>>> __vcpu_assign_sys_reg(vcpu, PMINTENSET_EL1, val & mask);
>
>>> + kvm_pmu_set_guest_counters(pmu, 0);
>>> preempt_enable();
>>> }
>>> diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
>>> index f7b000bb3eca8..63f88fec5e80f 100644
>>> --- a/include/linux/perf/arm_pmu.h
>>> +++ b/include/linux/perf/arm_pmu.h
>>> @@ -75,6 +75,7 @@ struct pmu_hw_events {
>
>>> /* Active events requesting branch records */
>>> unsigned int branch_users;
>>> + bool host_squeezed;
>>> };
>
>>> enum armpmu_attr_groups {
^ permalink raw reply
* Re: [PATCH net-next v4 09/13] net: lan966x: add PCIe FDMA support
From: Paolo Abeni @ 2026-05-14 9:05 UTC (permalink / raw)
To: Daniel Machon
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Horatiu Vultur, Steen Hegelund, UNGLinuxDriver,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Herve Codina, Arnd Bergmann,
Greg Kroah-Hartman, Mohsin Bashir, netdev, linux-kernel, bpf,
linux-arm-kernel
In-Reply-To: <20260509082720.503A6C2BCB2@smtp.kernel.org>
On 5/9/26 10:27 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 10 potential issue(s) to consider:
>> +static int lan966x_fdma_pci_napi_poll(struct napi_struct *napi, int weight)
>> +{
> [ ... ]
>> + /* Get all received skbs. */
>> + while (counter < weight) {
>> + if (!fdma_has_frames(fdma))
>> + break;
>> + /* Order DONE read before DCB/frame reads below. */
>> + dma_rmb();
>> + counter++;
>> + switch (lan966x_fdma_pci_rx_check_frame(rx, &src_port)) {
>> + case FDMA_PASS:
>> + break;
>> + case FDMA_ERROR:
>> + fdma_dcb_advance(fdma);
>> + goto allocate_new;
>> + }
>> + skb = lan966x_fdma_pci_rx_get_frame(rx, src_port);
>> + fdma_dcb_advance(fdma);
>> + if (!skb)
>> + goto allocate_new;
>
> If napi_alloc_skb() fails due to memory pressure, does branching to
> allocate_new prematurely break out of the processing loop? Since the hardware
> interrupt was already cleared, and napi_complete_done() is called below,
> will this cause the RX queue to stall permanently for the remaining
> unprocessed frames? Should the code drop the packet and continue instead?
I went over the series and sashiko feedback, and generally speaking the
series LGTM, but I think this one is real and should be addressed.
Also it would be very helpful if you could (for future series/revision)
reply to the (wrong) sashiko comments individually explaining with a few
words why the are off: decoding the context requires much more time for
whoever has not wrote the code itself.
I understand that dealing with AI feedback is a pain, but, paraphrasing
a great aphorisms creator, I can assure you that ours (maintainers) pain
is greater.
Thanks,
Paolo
^ permalink raw reply
* [PATCH v2 1/1] arm64: dts: s32g: add SAR ADC support for s32g2 and s32g3
From: Khristine Andreea Barbulescu @ 2026-05-14 8:26 UTC (permalink / raw)
To: Chester Lin, Matthias Brugger, Ghennadi Procopciuc, Frank Li,
Sascha Hauer, Fabio Estevam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Pengutronix Kernel Team, linux-arm-kernel, imx, devicetree,
linux-kernel, NXP S32 Linux, Christophe Lizzi, Alberto Ruiz,
Enric Balletbo
In-Reply-To: <20260514082639.1181240-1-khristineandreea.barbulescu@oss.nxp.com>
Add ADC0 and ADC1 for S32G2 and S32G3 SoCs.
Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
---
arch/arm64/boot/dts/freescale/s32g2.dtsi | 22 +++++++++++++++++++++-
arch/arm64/boot/dts/freescale/s32g3.dtsi | 22 +++++++++++++++++++++-
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/s32g2.dtsi b/arch/arm64/boot/dts/freescale/s32g2.dtsi
index 51d00dac12de..6f1952fbbcfe 100644
--- a/arch/arm64/boot/dts/freescale/s32g2.dtsi
+++ b/arch/arm64/boot/dts/freescale/s32g2.dtsi
@@ -3,7 +3,7 @@
* NXP S32G2 SoC family
*
* Copyright (c) 2021 SUSE LLC
- * Copyright 2017-2021, 2024-2025 NXP
+ * Copyright 2017-2021, 2024-2026 NXP
*/
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -554,6 +554,16 @@ i2c2: i2c@401ec000 {
status = "disabled";
};
+ adc0: adc@401f8000 {
+ compatible = "nxp,s32g2-sar-adc";
+ reg = <0x401f8000 0x1000>;
+ interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks 0x41>;
+ dmas = <&edma0 0 32>;
+ dma-names = "rx";
+ status = "disabled";
+ };
+
swt4: watchdog@40200000 {
compatible = "nxp,s32g2-swt";
reg = <0x40200000 0x1000>;
@@ -717,6 +727,16 @@ i2c4: i2c@402dc000 {
status = "disabled";
};
+ adc1: adc@402e8000 {
+ compatible = "nxp,s32g2-sar-adc";
+ reg = <0x402e8000 0x1000>;
+ interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks 0x41>;
+ dmas = <&edma1 1 32>;
+ dma-names = "rx";
+ status = "disabled";
+ };
+
usdhc0: mmc@402f0000 {
compatible = "nxp,s32g2-usdhc";
reg = <0x402f0000 0x1000>;
diff --git a/arch/arm64/boot/dts/freescale/s32g3.dtsi b/arch/arm64/boot/dts/freescale/s32g3.dtsi
index e314f3c7d61d..5cfb37c1216a 100644
--- a/arch/arm64/boot/dts/freescale/s32g3.dtsi
+++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
/*
- * Copyright 2021-2025 NXP
+ * Copyright 2021-2026 NXP
*
* Authors: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
* Ciprian Costea <ciprianmarian.costea@nxp.com>
@@ -617,6 +617,16 @@ i2c2: i2c@401ec000 {
status = "disabled";
};
+ adc0: adc@401f8000 {
+ compatible = "nxp,s32g3-sar-adc", "nxp,s32g2-sar-adc";
+ reg = <0x401f8000 0x1000>;
+ interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks 0x41>;
+ dmas = <&edma0 0 32>;
+ dma-names = "rx";
+ status = "disabled";
+ };
+
swt4: watchdog@40200000 {
compatible = "nxp,s32g3-swt", "nxp,s32g2-swt";
reg = <0x40200000 0x1000>;
@@ -792,6 +802,16 @@ i2c4: i2c@402dc000 {
status = "disabled";
};
+ adc1: adc@402e8000 {
+ compatible = "nxp,s32g3-sar-adc", "nxp,s32g2-sar-adc";
+ reg = <0x402e8000 0x1000>;
+ interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks 0x41>;
+ dmas = <&edma1 1 32>;
+ dma-names = "rx";
+ status = "disabled";
+ };
+
usdhc0: mmc@402f0000 {
compatible = "nxp,s32g3-usdhc",
"nxp,s32g2-usdhc";
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/1] add SAR ADC DTS support for S32G2/S32G3 SoCs
From: Khristine Andreea Barbulescu @ 2026-05-14 8:26 UTC (permalink / raw)
To: Chester Lin, Matthias Brugger, Ghennadi Procopciuc, Frank Li,
Sascha Hauer, Fabio Estevam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Pengutronix Kernel Team, linux-arm-kernel, imx, devicetree,
linux-kernel, NXP S32 Linux, Christophe Lizzi, Alberto Ruiz,
Enric Balletbo
This patchset aims to add one change to the S32G2/S32G3 dtsi support:
- Add SAR ADC dts support for S32G SoC based boards
v2 -> v1:
- drop 'vref' property from ADC nodes
- reorder 'adc1' node to maintain ascending
unit address order
Khristine Andreea Barbulescu (1):
arm64: dts: s32g: add SAR ADC support for s32g2 and s32g3
arch/arm64/boot/dts/freescale/s32g2.dtsi | 22 +++++++++++++++++++++-
arch/arm64/boot/dts/freescale/s32g3.dtsi | 22 +++++++++++++++++++++-
2 files changed, 42 insertions(+), 2 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v3 0/4] PCI: Add DOE support for endpoint
From: Manivannan Sadhasivam @ 2026-05-14 8:12 UTC (permalink / raw)
To: Aksh Garg
Cc: linux-pci, linux-doc, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <20260427051725.223704-1-a-garg7@ti.com>
On Mon, Apr 27, 2026 at 10:47:21AM +0530, Aksh Garg wrote:
> This patch series introduces the framework for supporting the Data
> Object Exchange (DOE) feature for PCIe endpoint devices. Please refer
> to the documentation added in patch 4 for details on the feature and
> implementation architecture.
>
> The implementation provides a common framework for all PCIe endpoint
> controllers, not specific to any particular SoC vendor.
>
> This patch series is the non-RFC version of the RFC series at
> https://lore.kernel.org/all/20260213123603.420941-1-a-garg7@ti.com/
>
> The changes since v1 are documented in the respective patch description.
>
Thanks for the work! I left some comments, but the series look good from the
initial look. Once you add the callers as I suggested, I'll do a more thorough
review.
- Mani
> Changes from v2 to v3:
> - Rebased on 7.1-rc1.
>
> v2: https://lore.kernel.org/all/20260401073022.215805-1-a-garg7@ti.com/
>
> Aksh Garg (4):
> PCI/DOE: Move common definitions to the header file
> PCI: endpoint: Add DOE mailbox support for endpoint functions
> PCI: endpoint: Add API for DOE initialization and setup in EPC core
> Documentation: PCI: Add documentation for DOE endpoint support
>
> Documentation/PCI/endpoint/index.rst | 1 +
> .../PCI/endpoint/pci-endpoint-doe.rst | 318 ++++++++++
> drivers/pci/doe.c | 11 -
> drivers/pci/endpoint/Kconfig | 14 +
> drivers/pci/endpoint/Makefile | 1 +
> drivers/pci/endpoint/pci-ep-doe.c | 552 ++++++++++++++++++
> drivers/pci/endpoint/pci-epc-core.c | 71 +++
> drivers/pci/pci.h | 47 ++
> include/linux/pci-doe.h | 8 +
> include/linux/pci-epc.h | 24 +
> 10 files changed, 1036 insertions(+), 11 deletions(-)
> create mode 100644 Documentation/PCI/endpoint/pci-endpoint-doe.rst
> create mode 100644 drivers/pci/endpoint/pci-ep-doe.c
>
> --
> 2.34.1
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v3 4/4] Documentation: PCI: Add documentation for DOE endpoint support
From: Manivannan Sadhasivam @ 2026-05-14 8:11 UTC (permalink / raw)
To: Aksh Garg
Cc: linux-pci, linux-doc, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <20260427051725.223704-5-a-garg7@ti.com>
On Mon, Apr 27, 2026 at 10:47:25AM +0530, Aksh Garg wrote:
> Document the architecture and implementation details for the Data Object
> Exchange (DOE) framework for PCIe Endpoint devices.
>
> Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> Signed-off-by: Aksh Garg <a-garg7@ti.com>
> ---
>
> Changes from v2 to v3:
> - Rebased on 7.1-rc1.
>
> Changes since v1:
> - Squashed the patches [1] and [2], and moved the documentation file
> to Documentation/PCI/endpoint/pci-endpoint-doe.rst to match the existing
> naming scheme, as suggested by Niklas Cassel
> - Updated the documentation as per the design and implementaion changes
> made to previous patches in this series:
> * Updated for static protocol array instead of dynamic registration
> * Documented asynchronous callback model
> * Updated request/response flow with new callback signature
> * Updated memory ownership: DOE core frees request, driver frees response
> * Updated initialization and cleanup sections for new APIs
>
> v2: https://lore.kernel.org/all/20260401073022.215805-5-a-garg7@ti.com/
> v1: [1] https://lore.kernel.org/all/20260213123603.420941-2-a-garg7@ti.com/
> [2] https://lore.kernel.org/all/20260213123603.420941-5-a-garg7@ti.com/
>
> Documentation/PCI/endpoint/index.rst | 1 +
> .../PCI/endpoint/pci-endpoint-doe.rst | 318 ++++++++++++++++++
> 2 files changed, 319 insertions(+)
> create mode 100644 Documentation/PCI/endpoint/pci-endpoint-doe.rst
>
> diff --git a/Documentation/PCI/endpoint/index.rst b/Documentation/PCI/endpoint/index.rst
> index dd1f62e731c9..7c03d5abd2ef 100644
> --- a/Documentation/PCI/endpoint/index.rst
> +++ b/Documentation/PCI/endpoint/index.rst
> @@ -9,6 +9,7 @@ PCI Endpoint Framework
>
> pci-endpoint
> pci-endpoint-cfs
> + pci-endpoint-doe
> pci-test-function
> pci-test-howto
> pci-ntb-function
> diff --git a/Documentation/PCI/endpoint/pci-endpoint-doe.rst b/Documentation/PCI/endpoint/pci-endpoint-doe.rst
> new file mode 100644
> index 000000000000..03b7a69516f3
> --- /dev/null
> +++ b/Documentation/PCI/endpoint/pci-endpoint-doe.rst
> @@ -0,0 +1,318 @@
> +.. SPDX-License-Identifier: GPL-2.0-only or MIT
> +
> +.. include:: <isonum.txt>
> +
> +=============================================
> +Data Object Exchange (DOE) for PCIe Endpoint
> +=============================================
> +
> +:Copyright: |copy| 2026 Texas Instruments Incorporated
> +:Author: Aksh Garg <a-garg7@ti.com>
> +:Co-Author: Siddharth Vadapalli <s-vadapalli@ti.com>
> +
> +Overview
> +========
> +
> +DOE (Data Object Exchange) is a standard PCIe extended capability feature
> +introduced in the Data Object Exchange (DOE) ECN for PCIe r5.0. It is an optional
> +mechanism for system firmware/software running on root complex (host) to perform
> +:ref:`data object <data-object-term>` exchanges with an endpoint function. Each
> +data object is uniquely identified by the Vendor ID of the vendor publishing the
> +data object definition and a Data Object Type value assigned by that vendor.
> +
> +Think of DOE as a sophisticated mailbox system built into PCIe. The root complex
> +can send structured requests to the endpoint device through DOE mailboxes, and
> +the endpoint device responds with appropriate data. DOE mailboxes are implemented
> +as PCIe Extended Capabilities in endpoint devices, allowing multiple mailboxes
> +per function, each potentially supporting different data object protocols.
> +
> +The DOE support for root complex devices has already been implemented in
> +``drivers/pci/doe.c``.
> +
> +How DOE Works
> +=============
> +
> +The DOE mailbox operates through a simple request-response model:
> +
> +1. **Host sends request**: The root complex writes a data object (vendor ID, type,
> + and payload) to the DOE write mailbox register (one DWORD at a time) of the
> + endpoint function's config space and sets the GO bit in the DOE Status register
> + to indicate that a request is ready for processing.
> +2. **Endpoint processes**: The endpoint function reads the request from DOE write
> + mailbox register, sets the BUSY bit in the DOE Status register, identifies the
> + protocol of the data object, and executes the appropriate handler.
> +3. **Endpoint responds**: The endpoint function writes the response data object to the
> + DOE read mailbox register (one DWORD at a time), and sets the READY bit in the DOE
> + Status register to indicate that the response is ready. If an error occurs during
> + request processing (such as unsupported protocol or handler failure), the endpoint
> + sets the ERROR bit in the DOE Status register instead of the READY bit.
> +4. **Host reads response**: The root complex retrieves the response data from the DOE read
> + mailbox register once the READY bit is set in the DOE Status register, and then writes
> + any value to this register to indicate a successful read. If the ERROR bit was set,
> + the root complex discards the response and performs error handling as needed.
> +
> +Each mailbox operates independently and can handle one transaction at a time. The
> +DOE specification supports data objects of size up to 256KB (2\ :sup:`18` dwords).
> +
> +For complete DOE capability details, refer to `PCI Express Base Specification Revision 7.0,
> +Section 6.30 - Data Object Exchange (DOE)`.
> +
> +Key Terminologies
> +=================
> +
> +.. _data-object-term:
> +
> +**Data Object**
> + A structured, vendor-defined, or standard-defined message exchanged between
> + root complex and endpoint function via DOE capability registers in configuration
> + space of the function.
> +
> +**Mailbox**
> + A DOE capability on the endpoint device, where each physical function can have
> + multiple mailboxes.
> +
> +**Protocol**
> + A specific type of DOE communication data object identified by a Vendor ID and Type.
> +
> +**Handler**
> + A function that processes DOE requests of a specific protocol and generates responses.
> +
> +Architecture of DOE Implementation for Endpoint
> +===============================================
> +
> +.. code-block:: text
> +
> + +------------------+
> + | |
> + | Root Complex |
> + | |
> + +--------^---------+
> + |
> + | Config space access
> + | over PCIe link
> + |
> + +----------v-----------+
> + | |
> + | PCIe Controller |
> + | as Endpoint |
> + | |
> + | +-----------------+ |
> + | | DOE Mailbox | |
> + | +-------^---------+ |
> + +----------|-----------+
> + +-----------|---------------------------------------------------------------+
> + | | +--------------------+ |
> + | +---------v--------+ Allocate | +--------------+ | |
> + | | |-------------------------------->| Request | | |
> + | | EP Controller | +--->| Buffer | | |
> + | | Driver | Free | | +--------------+ | |
> + | | |--------------------------+ | | | |
> + | +--------^---------+ | | | | |
> + | | | | | | |
> + | | | | | | |
> + | | pci_ep_doe_process_request() | | | | |
> + | | | | | | |
> + | +--------v---------+ Free | | | | |
> + | | |----------------------------+ | DDR | |
> + | | DOE EP Core |<----+ | | | |
> + | | (doe-ep.c) | | Discovery | | | |
> + | | |-----+ Protocol Handler | | | |
> + | +--------^---------+ | | | |
> + | | | | | |
> + | | protocol_handler() | | | |
> + | | | | | |
> + | +--------v---------+ | | | |
> + | | | | | +--------------+ | |
> + | | Protocol Handler | +----->| Response | | |
> + | | Module |-------------------------------->| Buffer | | |
> + | | (CMA/SPDM/Other) | Allocate | +--------------+ | |
> + | | | | | |
> + | +------------------+ | | |
> + | +--------------------+ |
> + +---------------------------------------------------------------------------+
> +
> +Initialization and Cleanup
> +--------------------------
> +
> +**Framework Initialization and DOE Setup**
> +
> +The EPC core provides the ``pci_epc_doe_setup(epc)`` API for centralized DOE
> +mailbox discovery and registration. The controller driver calls this API during
> +its probe sequence if DOE is supported.
> +
> +This API performs the following steps:
> +
> +1. Calls ``pci_ep_doe_init(epc)``, which initializes the xarray data structure
> + (a resizable array data structure defined in linux) named ``doe_mbs`` that
> + stores metadata of DOE mailboxes for the controller in ``struct pci_epc``.
> +2. Discovers all DOE capabilities in the endpoint function's configuration space
> + for each function. For each discovered DOE capability, calls
> + ``pci_ep_doe_add_mailbox(epc, func_no, cap_offset)`` to register the mailbox.
> +
> +Each DOE mailbox structure created by ``pci_ep_doe_add_mailbox()`` gets an
> +ordered workqueue allocated for processing DOE requests sequentially for that
> +mailbox, enabling concurrent request handling across different mailboxes. Each
> +mailbox is uniquely identified by the combination of physical function number
> +and capability offset for that controller.
> +
> +**Cleanup**
> +
> +The EPC core provides the ``pci_epc_doe_destroy(epc)`` API for centralized DOE
> +cleanup. The controller driver calls this API during its remove sequence
> +if DOE is supported.
> +
> +This API calls ``pci_ep_doe_destroy(epc)``, which destroys all registered
> +mailboxes, cancels any pending tasks, flushes and destroys the workqueues,
> +and frees all memory allocated to the mailboxes.
> +
As I mentioned in patch 3, we should call these APIs within the EPC core and not
sprinkle throughout the EPC drivers.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v3 3/4] PCI: endpoint: Add API for DOE initialization and setup in EPC core
From: Manivannan Sadhasivam @ 2026-05-14 8:08 UTC (permalink / raw)
To: Aksh Garg
Cc: linux-pci, linux-doc, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <20260427051725.223704-4-a-garg7@ti.com>
On Mon, Apr 27, 2026 at 10:47:24AM +0530, Aksh Garg wrote:
> Add pci_epc_setup_doe() API in EPC core driver to initialize and setup
> the DOE framework for an endpoint controller. The API discovers the DOE
> capabilities (extended capability ID 0x2E), and registers each discovered
> DOE mailbox for all the functions in the endpoint controller. This API
> should be invoked by the controller driver during probe based on the
> doe_capable feature.
>
> Add pci_epc_destroy_doe() API in EPC core driver for cleanup of DOE
> resources, which should be invoked by the controller driver during
> controller cleanup based on the doe_capable feature.
>
> Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> Signed-off-by: Aksh Garg <a-garg7@ti.com>
> ---
>
> Changes from v2 to v3:
> - Rebased on 7.1-rc1.
>
> Changes since v1:
> - New patch added to v2 (not present in v1)
>
> v2: https://lore.kernel.org/all/20260401073022.215805-4-a-garg7@ti.com/
>
> This patch is introduced based on the feedback provided by Manivannan
> Sadhasivam at [1].
>
Sweet! But I was expecting you to add atleast one EPC driver implementation to
make use of these APIs.
Also, why can't you call these APIs from the EPC core directly? Maybe during
pci_epc_init_notify() once the register accesses become valid.
- Mani
> [1]: https://lore.kernel.org/all/p57x6jleaim5w7t2k3v7tioujnaxuovfpj5euop5ogefvw23se@y5fw3che5p5d/
>
> drivers/pci/endpoint/pci-epc-core.c | 71 +++++++++++++++++++++++++++++
> include/linux/pci-epc.h | 21 +++++++++
> 2 files changed, 92 insertions(+)
>
> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> index 6c3c58185fc5..5a95a07b7d3a 100644
> --- a/drivers/pci/endpoint/pci-epc-core.c
> +++ b/drivers/pci/endpoint/pci-epc-core.c
> @@ -14,6 +14,8 @@
> #include <linux/pci-epf.h>
> #include <linux/pci-ep-cfs.h>
>
> +#include "../pci.h"
> +
> static const struct class pci_epc_class = {
> .name = "pci_epc",
> };
> @@ -548,6 +550,75 @@ void pci_epc_mem_unmap(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> }
> EXPORT_SYMBOL_GPL(pci_epc_mem_unmap);
>
> +/**
> + * pci_epc_doe_setup() - Setup and discover DOE mailboxes for all functions
> + * @epc: the EPC device on which DOE mailboxes has to be setup
> + *
> + * Discover DOE (Data Object Exchange) capabilities for all physical functions
> + * in the endpoint controller and register DOE mailboxes.
> + *
> + * This API should be called by the controller driver during initialization
> + * if DOE support is available (indicated by doe_capable in pci_epc_features).
> + *
> + * RETURNS: 0 on success, -errno on failure
> + */
> +int pci_epc_doe_setup(struct pci_epc *epc)
> +{
> + u16 cap_offset = 0;
> + u8 func_no;
> + int ret;
> +
> + if (!epc || !epc->ops || !epc->ops->find_ext_capability)
> + return -EINVAL;
> +
> + /* Initialize DOE framework for this controller */
> + ret = pci_ep_doe_init(epc);
> + if (ret)
> + return ret;
> +
> + /* Discover DOE capabilities for all functions */
> + for (func_no = 0; func_no < epc->max_functions; func_no++) {
> + while ((cap_offset = epc->ops->find_ext_capability(epc, func_no, 0,
> + cap_offset,
> + PCI_EXT_CAP_ID_DOE))) {
> + /* Register this DOE mailbox */
> + ret = pci_ep_doe_add_mailbox(epc, func_no, cap_offset);
> + if (ret) {
> + dev_err(&epc->dev,
> + "[pf%d:offset %x] failed to add DOE mailbox\n",
> + func_no, cap_offset);
> + }
> + }
> + }
> +
> + dev_dbg(&epc->dev, "DOE mailboxes setup complete\n");
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_epc_doe_setup);
> +
> +/**
> + * pci_epc_doe_destroy() - Destroy and cleanup DOE mailboxes
> + * @epc: the EPC device on which DOE mailboxes has to be destroyed
> + *
> + * Destroy all DOE mailboxes registered on this endpoint controller and
> + * free associated resources.
> + *
> + * This API should be called by the controller driver during controller cleanup
> + * if DOE support is available (indicated by doe_capable in pci_epc_features).
> + *
> + * RETURNS: 0 on success, -errno on failure
> + */
> +int pci_epc_doe_destroy(struct pci_epc *epc)
> +{
> + if (!epc)
> + return -EINVAL;
> +
> + pci_ep_doe_destroy(epc);
> + dev_dbg(&epc->dev, "DOE mailboxes destroyed\n");
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_epc_doe_destroy);
> +
> /**
> * pci_epc_clear_bar() - reset the BAR
> * @epc: the EPC device for which the BAR has to be cleared
> diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
> index dd26294c8175..7b0f258ef330 100644
> --- a/include/linux/pci-epc.h
> +++ b/include/linux/pci-epc.h
> @@ -84,6 +84,8 @@ struct pci_epc_map {
> * @start: ops to start the PCI link
> * @stop: ops to stop the PCI link
> * @get_features: ops to get the features supported by the EPC
> + * @find_ext_capability: ops to find extended capability offset for a function
> + * in endpoint controller
> * @owner: the module owner containing the ops
> */
> struct pci_epc_ops {
> @@ -115,6 +117,8 @@ struct pci_epc_ops {
> void (*stop)(struct pci_epc *epc);
> const struct pci_epc_features* (*get_features)(struct pci_epc *epc,
> u8 func_no, u8 vfunc_no);
> + u16 (*find_ext_capability)(struct pci_epc *epc, u8 func_no,
> + u8 vfunc_no, u16 start, u8 cap);
> struct module *owner;
> };
>
> @@ -270,6 +274,7 @@ struct pci_epc_bar_desc {
> * @msi_capable: indicate if the endpoint function has MSI capability
> * @msix_capable: indicate if the endpoint function has MSI-X capability
> * @intx_capable: indicate if the endpoint can raise INTx interrupts
> + * @doe_capable: indicate if the endpoint function has DOE capability
> * @bar: array specifying the hardware description for each BAR
> * @align: alignment size required for BAR buffer allocation
> */
> @@ -280,6 +285,7 @@ struct pci_epc_features {
> unsigned int msi_capable : 1;
> unsigned int msix_capable : 1;
> unsigned int intx_capable : 1;
> + unsigned int doe_capable : 1;
> struct pci_epc_bar_desc bar[PCI_STD_NUM_BARS];
> size_t align;
> };
> @@ -368,6 +374,21 @@ int pci_epc_mem_map(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> void pci_epc_mem_unmap(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> struct pci_epc_map *map);
>
> +#ifdef CONFIG_PCI_ENDPOINT_DOE
> +int pci_epc_doe_setup(struct pci_epc *epc);
> +int pci_epc_doe_destroy(struct pci_epc *epc);
> +#else
> +static inline int pci_epc_doe_setup(struct pci_epc *epc)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline int pci_epc_doe_destroy(struct pci_epc *epc)
> +{
> + return -EOPNOTSUPP;
> +}
> +#endif
> +
> #else
> static inline void pci_epc_init_notify(struct pci_epc *epc)
> {
> --
> 2.34.1
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 03/13] dma-pool: track decrypted atomic pools and select them via attrs
From: Mostafa Saleh @ 2026-05-14 8:06 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, Robin Murphy,
Marek Szyprowski, Will Deacon, Marc Zyngier, Steven Price,
Suzuki K Poulose, Catalin Marinas, Jiri Pirko, Jason Gunthorpe,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <yq5abjeia315.fsf@kernel.org>
On Thu, May 14, 2026 at 8:01 AM Aneesh Kumar K.V
<aneesh.kumar@kernel.org> wrote:
>
> Mostafa Saleh <smostafa@google.com> writes:
>
> ...
>
> >> struct page *dma_alloc_from_pool(struct device *dev, size_t size,
> >> - void **cpu_addr, gfp_t gfp,
> >> + void **cpu_addr, gfp_t gfp, unsigned long attrs,
> >> bool (*phys_addr_ok)(struct device *, phys_addr_t, size_t))
> >> {
> >> - struct gen_pool *pool = NULL;
> >> + struct dma_gen_pool *dma_pool = NULL;
> >> struct page *page;
> >> bool pool_found = false;
> >>
> >> - while ((pool = dma_guess_pool(pool, gfp))) {
> >> + while ((dma_pool = dma_guess_pool(dma_pool, gfp))) {
> >> +
> >> + if (dma_pool->unencrypted != !!(attrs & DMA_ATTR_CC_SHARED))
> >> + continue;
> >> +
> >
> > nit: If we fail to find a matching pool, a slightly misleading message
> > is printed as pool_found = false
> >
>
> The message printed is
>
> WARN(1, "Failed to get suitable pool for %s\n", dev_name(dev));
>
> That is correct, isn’t it? The kernel failed to find a pool with the
> correct encryption attribute. For example, the request was for an
> encrypted allocation from the pool, but no encrypted pool was available.
>
Sure, I’d prefer a clearer print in that case, especially since that’s new code:
“Only {encrypted/decrypted} pool found for a {encrypted/decrypted} alloction”
But no strong opinion.
Thanks,
Mostafa
> >
> >> pool_found = true;
> >> - page = __dma_alloc_from_pool(dev, size, pool, cpu_addr,
> >> + page = __dma_alloc_from_pool(dev, size, dma_pool->pool, cpu_addr,
> >> phys_addr_ok);
> >> if (page)
> >> return page;
> >> @@ -296,12 +345,14 @@ struct page *dma_alloc_from_pool(struct device *dev, size_t size,
>
> -aneesh
^ permalink raw reply
* Re: [PATCH v3 2/4] PCI: endpoint: Add DOE mailbox support for endpoint functions
From: Manivannan Sadhasivam @ 2026-05-14 8:03 UTC (permalink / raw)
To: Aksh Garg
Cc: linux-pci, linux-doc, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <20260427051725.223704-3-a-garg7@ti.com>
On Mon, Apr 27, 2026 at 10:47:23AM +0530, Aksh Garg wrote:
> DOE (Data Object Exchange) is a standard PCIe extended capability
> feature introduced in the Data Object Exchange (DOE) ECN for
> PCIe r5.0. It provides a communication mechanism primarily used for
> implementing PCIe security features such as device authentication, and
> secure link establishment. Think of DOE as a sophisticated mailbox
> system built into PCIe. The root complex can send structured requests
> to the endpoint device through DOE mailboxes, and the endpoint device
> responds with appropriate data.
>
> Add the DOE support for PCIe endpoint devices, enabling endpoint
> functions to process the DOE requests from the host. The implementation
> provides framework APIs for EPC core driver and controller drivers to
> register mailboxes, and request processing with workqueues ensuring
> sequential handling per mailbox, and parallel handling across mailboxes.
> The Discovery protocol is handled internally by the DOE core.
>
> This implementation complements the existing DOE implementation for
> root complex in drivers/pci/doe.c.
>
> Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> Signed-off-by: Aksh Garg <a-garg7@ti.com>
> ---
>
> Changes from v2 to v3:
> - Rebased on 7.1-rc1.
>
> Changes since v1:
> - Moved the DOE-EP core file to drivers/pci/endpoint/pci-ep-doe.c, and
> corresponding Kconfig and Makefile to match the existing naming scheme,
> as suggested by Niklas Cassel.
> - Renamed the config from PCI_DOE_EP to PCI_ENDPOINT_DOE
> - Moved the function declarations that need not be visible outside the
> PCI core to drivers/pci/pci.h instead to include/linux/pci-doe.h as
> suggested by Lukas Wunner
> - Converted from synchronous to asynchronous request processing:
> * Removed wait_for_completion() from pci_ep_doe_process_request()
> * Function returns immediately after queuing to workqueue, hence
> removed private data for completion in the task structure
> * Added completion callback as an additional argument to
> pci_ep_doe_process_request(), which takes the response and status
> parameters as arguments (along with other required arguments), hence
> removed task_status in the task structure
> * Created a typedef pci_ep_doe_complete_t for completion callback
> * Removed the pci_ep_doe_task_complete() function, as it would not be
> required anymore with these changes
> * Moved from INIT_WORK_ONSTACK() to INIT_WORK(), to initialize the work
> on heap instead of stack
> * signal_task_complete() now invokes the completion callback, once the
> protocol handler completes its task
> - Changed from dynamic xarray-based protocol registration to static array:
> * Removed the register/unregister protocol APIs
> * Replaced the dynamic xarray with static array of struct pci_doe_protocol
> * Added discovery protocol to static array, instead of treating it specially,
> hence removed the special handling for Discovery protocol in
> doe_ep_task_work()
> * Updated pci_ep_doe_handle_discovery() and pci_ep_doe_find_protocol()
> accordingly.
> - Memory Management:
> * DOE core frees request buffer in signal_task_complete()
> or during error handling
> * pci_ep_doe_process_request() defines response_pl and response_pl_sz
> as NULL and 0 respectively, whose pointer is passed to the protocol
> handler, hence removed the arguments void **response, size_t *response_sz
> to this function.
> - Task structure refactoring:
> * Response buffer: void **response_pl to void *response_pl
> * Response size: size_t *response_pl_sz to size_t response_pl_sz
> * Changed the completion callback to type pci_ep_doe_complete_t
> * Removed void *private and int task_status
> - Updated documentation comments of the functions according to the changes
>
> v2: https://lore.kernel.org/all/20260401073022.215805-3-a-garg7@ti.com/
> v1: https://lore.kernel.org/all/20260213123603.420941-4-a-garg7@ti.com/
>
> drivers/pci/endpoint/Kconfig | 14 +
> drivers/pci/endpoint/Makefile | 1 +
> drivers/pci/endpoint/pci-ep-doe.c | 552 ++++++++++++++++++++++++++++++
> drivers/pci/pci.h | 38 ++
> include/linux/pci-doe.h | 5 +
> include/linux/pci-epc.h | 3 +
> 6 files changed, 613 insertions(+)
> create mode 100644 drivers/pci/endpoint/pci-ep-doe.c
>
> diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig
> index 8dad291be8b8..15ae16aaa58f 100644
> --- a/drivers/pci/endpoint/Kconfig
> +++ b/drivers/pci/endpoint/Kconfig
> @@ -36,6 +36,20 @@ config PCI_ENDPOINT_MSI_DOORBELL
> doorbell. The RC can trigger doorbell in EP by writing data to a
> dedicated BAR, which the EP maps to the controller's message address.
>
> +config PCI_ENDPOINT_DOE
> + bool "PCI Endpoint Data Object Exchange (DOE) support"
> + depends on PCI_ENDPOINT
> + help
> + This enables support for Data Object Exchange (DOE) protocol
> + on PCI Endpoint controllers. It provides a communication
> + mechanism through mailboxes, primarily used for PCIe security
> + features.
> +
> + Say Y here if you want be able to communicate using PCIe DOE
> + mailboxes.
> +
> + If unsure, say N.
> +
> source "drivers/pci/endpoint/functions/Kconfig"
>
> endmenu
> diff --git a/drivers/pci/endpoint/Makefile b/drivers/pci/endpoint/Makefile
> index b4869d52053a..1fa176b6792b 100644
> --- a/drivers/pci/endpoint/Makefile
> +++ b/drivers/pci/endpoint/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_PCI_ENDPOINT_CONFIGFS) += pci-ep-cfs.o
> obj-$(CONFIG_PCI_ENDPOINT) += pci-epc-core.o pci-epf-core.o\
> pci-epc-mem.o functions/
> obj-$(CONFIG_PCI_ENDPOINT_MSI_DOORBELL) += pci-ep-msi.o
> +obj-$(CONFIG_PCI_ENDPOINT_DOE) += pci-ep-doe.o
> diff --git a/drivers/pci/endpoint/pci-ep-doe.c b/drivers/pci/endpoint/pci-ep-doe.c
> new file mode 100644
> index 000000000000..ded0290b15ed
> --- /dev/null
> +++ b/drivers/pci/endpoint/pci-ep-doe.c
> @@ -0,0 +1,552 @@
> +// SPDX-License-Identifier: GPL-2.0-only or MIT
> +/*
> + * Data Object Exchange for PCIe Endpoint
> + * PCIe r7.0, sec 6.30 DOE
> + *
> + * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com
> + * Aksh Garg <a-garg7@ti.com>
> + * Siddharth Vadapalli <s-vadapalli@ti.com>
> + */
> +
> +#define dev_fmt(fmt) "DOE EP: " fmt
> +
> +#include <linux/bitfield.h>
> +#include <linux/device.h>
> +#include <linux/pci.h>
> +#include <linux/pci-epc.h>
> +#include <linux/pci-doe.h>
> +#include <linux/slab.h>
> +#include <linux/workqueue.h>
> +#include <linux/xarray.h>
> +
> +#include "../pci.h"
> +
> +/* Forward declaration of discovery protocol handler */
> +static int pci_ep_doe_handle_discovery(const void *request, size_t request_sz,
> + void **response, size_t *response_sz);
> +
> +/**
> + * struct pci_doe_protocol - DOE protocol handler entry
> + * @vid: Vendor ID
> + * @type: Protocol type
> + * @handler: Handler function pointer
> + */
> +struct pci_doe_protocol {
> + u16 vid;
> + u8 type;
> + pci_doe_protocol_handler_t handler;
> +};
> +
> +/**
> + * struct pci_ep_doe_mb - State for a single DOE mailbox on EP
> + *
> + * This state is used to manage a single DOE mailbox capability on the
> + * endpoint side.
> + *
> + * @epc: PCI endpoint controller this mailbox belongs to
> + * @func_no: Physical function number of the function this mailbox belongs to
> + * @cap_offset: Capability offset
> + * @work_queue: Queue of work items
> + * @flags: Bit array of PCI_DOE_FLAG_* flags
> + */
> +struct pci_ep_doe_mb {
> + struct pci_epc *epc;
> + u8 func_no;
> + u16 cap_offset;
> + struct workqueue_struct *work_queue;
> + unsigned long flags;
> +};
> +
> +/**
> + * struct pci_ep_doe_task - Represents a single DOE request/response task
> + *
> + * @feat: DOE feature (vendor ID and type)
> + * @request_pl: Request payload
> + * @request_pl_sz: Size of request payload in bytes
> + * @response_pl: Response buffer
> + * @response_pl_sz: Size of response buffer in bytes
> + * @complete: Completion callback
> + * @work: Work structure for workqueue
> + * @doe_mb: DOE mailbox handling this task
> + */
> +struct pci_ep_doe_task {
> + struct pci_doe_feature feat;
> + const void *request_pl;
> + size_t request_pl_sz;
> + void *response_pl;
> + size_t response_pl_sz;
> + pci_ep_doe_complete_t complete;
> +
> + /* Initialized by pci_ep_doe_submit_task() */
> + struct work_struct work;
> + struct pci_ep_doe_mb *doe_mb;
> +};
> +
> +/*
> + * Global registry of protocol handlers.
> + * When a new DOE protocol, library is added, add an entry to this array.
> + */
> +static const struct pci_doe_protocol pci_doe_protocols[] = {
> + {
> + .vid = PCI_VENDOR_ID_PCI_SIG,
> + .type = PCI_DOE_FEATURE_DISCOVERY,
> + .handler = pci_ep_doe_handle_discovery,
> + },
> +};
> +
> +/*
> + * Combines function number and capability offset into a unique lookup key
> + * for storing/retrieving DOE mailboxes in an xarray.
> + */
> +#define PCI_DOE_MB_KEY(func, offset) \
> + (((unsigned long)(func) << 16) | (offset))
> +#define PCI_DOE_PROTOCOL_COUNT ARRAY_SIZE(pci_doe_protocols)
> +
> +/**
> + * pci_ep_doe_init() - Initialize the DOE framework for a controller in EP mode
> + * @epc: PCI endpoint controller
> + *
> + * Initialize the DOE framework data structures. This only initializes
> + * the xarray that will hold the mailboxes.
> + *
> + * RETURNS: 0 on success, -errno on failure
kernel-doc format to describe return value is 'Return:' or 'Returns:".
> + */
> +int pci_ep_doe_init(struct pci_epc *epc)
> +{
> + if (!epc)
> + return -EINVAL;
> +
> + xa_init(&epc->doe_mbs);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_ep_doe_init);
> +
> +/**
> + * pci_ep_doe_add_mailbox() - Add a DOE mailbox for a physical function
> + * @epc: PCI endpoint controller
> + * @func_no: Physical function number
> + * @cap_offset: Offset of the DOE capability
> + *
> + * Create and register a DOE mailbox for the specified physical function
> + * and capability offset.
> + *
> + * EPC core driver calls this for each DOE capability discovered in the config
> + * space of each endpoint function through an API. The API is invoked by the
> + * controller driver during initialization if DOE support is available.
> + *
> + * RETURNS: 0 on success, -errno on failure
> + */
> +int pci_ep_doe_add_mailbox(struct pci_epc *epc, u8 func_no, u16 cap_offset)
> +{
> + struct pci_ep_doe_mb *doe_mb;
> + unsigned long key;
> + int ret;
> +
> + if (!epc)
> + return -EINVAL;
> +
> + doe_mb = kzalloc_obj(*doe_mb, GFP_KERNEL);
> + if (!doe_mb)
> + return -ENOMEM;
> +
> + doe_mb->epc = epc;
> + doe_mb->func_no = func_no;
> + doe_mb->cap_offset = cap_offset;
> +
> + doe_mb->work_queue = alloc_ordered_workqueue("pci_ep_doe[%s:pf%d:offset%x]", 0,
> + dev_name(&epc->dev),
> + func_no, cap_offset);
> + if (!doe_mb->work_queue) {
> + dev_err(epc->dev.parent,
> + "[pf%d:offset%x] failed to allocate work queue\n",
> + func_no, cap_offset);
> + ret = -ENOMEM;
> + goto err_free;
> + }
> +
> + /* Add to xarray with composite key */
> + key = PCI_DOE_MB_KEY(func_no, cap_offset);
> + ret = xa_insert(&epc->doe_mbs, key, doe_mb, GFP_KERNEL);
> + if (ret) {
> + dev_err(epc->dev.parent,
> + "[pf%d:offset%x] failed to insert mailbox: %d\n",
> + func_no, cap_offset, ret);
> + goto err_destroy;
> + }
> +
> + dev_dbg(epc->dev.parent,
> + "DOE mailbox added: pf%d offset 0x%x\n",
> + func_no, cap_offset);
> +
> + return 0;
> +
> +err_destroy:
> + destroy_workqueue(doe_mb->work_queue);
> +err_free:
> + kfree(doe_mb);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(pci_ep_doe_add_mailbox);
> +
> +/**
> + * pci_ep_doe_cancel_tasks() - Cancel all pending tasks
> + * @doe_mb: DOE mailbox
> + *
> + * Cancel all pending tasks in the mailbox. Mark the mailbox as dead
> + * so no new tasks can be submitted.
> + */
> +static void pci_ep_doe_cancel_tasks(struct pci_ep_doe_mb *doe_mb)
> +{
> + if (!doe_mb)
> + return;
> +
> + /* Mark the mailbox as dead */
> + set_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags);
> +
> + /* Stop all pending work items from starting */
> + set_bit(PCI_DOE_FLAG_CANCEL, &doe_mb->flags);
> +}
> +
> +/**
> + * pci_ep_doe_get_mailbox() - Get DOE mailbox by function and offset
> + * @epc: PCI endpoint controller
> + * @func_no: Physical function number
> + * @cap_offset: Offset of the DOE capability
> + *
> + * Internal helper to look up a DOE mailbox by its function number and
> + * capability offset.
> + *
> + * RETURNS: Pointer to the mailbox or NULL if not found
> + */
> +static struct pci_ep_doe_mb *pci_ep_doe_get_mailbox(struct pci_epc *epc,
> + u8 func_no, u16 cap_offset)
> +{
> + unsigned long key;
> +
> + if (!epc)
> + return NULL;
> +
> + key = PCI_DOE_MB_KEY(func_no, cap_offset);
> + return xa_load(&epc->doe_mbs, key);
> +}
> +
> +/**
> + * pci_ep_doe_find_protocol() - Find protocol handler in static array
> + * @vendor: Vendor ID
> + * @type: Protocol type
> + *
> + * Look up a protocol handler in the static protocol array by matching vendor ID
> + * and protocol type.
> + *
> + * RETURNS: Handler function pointer or NULL if not found
> + */
> +static pci_doe_protocol_handler_t pci_ep_doe_find_protocol(u16 vendor, u8 type)
> +{
> + int i;
> +
> + /* Search static protocol array */
> + for (i = 0; i < PCI_DOE_PROTOCOL_COUNT; i++) {
> + if (pci_doe_protocols[i].vid == vendor &&
> + pci_doe_protocols[i].type == type)
> + return pci_doe_protocols[i].handler;
> + }
> +
> + return NULL;
> +}
> +
> +/**
> + * pci_ep_doe_handle_discovery() - Handle Discovery protocol request
> + * @request: Request payload
> + * @request_sz: Request size
> + * @response: Output pointer for response buffer
> + * @response_sz: Output pointer for response size
> + *
> + * Handle the DOE Discovery protocol. The request contains an index specifying
> + * which protocol to query. This function creates a response containing the
> + * vendor ID and protocol type for the requested index, along with the next
> + * index value for further discovery:
> + *
> + * - next_index = 0: Signals this is the last protocol supported
> + * - next_index = n (non-zero): Signals more protocols available,
> + * query index n next
> + *
> + * RETURNS: 0 on success, -errno on failure
> + */
> +static int pci_ep_doe_handle_discovery(const void *request, size_t request_sz,
> + void **response, size_t *response_sz)
> +{
> + struct pci_doe_protocol protocol;
> + u8 requested_index, next_index;
> + u32 *response_pl;
> + u32 request_pl;
> + u16 vendor;
> + u8 type;
> +
> + if (request_sz != sizeof(u32))
> + return -EINVAL;
> +
> + request_pl = *(u32 *)request;
> + requested_index = FIELD_GET(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX, request_pl);
> +
> + if (requested_index >= PCI_DOE_PROTOCOL_COUNT)
> + return -EINVAL;
> +
> + /* Get protocol from array at requested_index */
> + protocol = pci_doe_protocols[requested_index];
> + vendor = protocol.vid;
> + type = protocol.type;
> +
> + /* Calculate next index */
> + next_index = (requested_index + 1 < PCI_DOE_PROTOCOL_COUNT) ? requested_index + 1 : 0;
> +
> + response_pl = kzalloc_obj(*response_pl, GFP_KERNEL);
> + if (!response_pl)
> + return -ENOMEM;
> +
> + /* Build response */
> + *response_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_RSP_3_VID, vendor) |
> + FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_RSP_3_TYPE, type) |
> + FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_RSP_3_NEXT_INDEX, next_index);
> +
> + *response = response_pl;
> + *response_sz = sizeof(*response_pl);
> +
> + return 0;
> +}
> +
> +static void signal_task_complete(struct pci_ep_doe_task *task, int status)
> +{
> + kfree(task->request_pl);
> + task->complete(task->doe_mb->func_no, task->doe_mb->cap_offset, status,
> + task->feat.vid, task->feat.type,
> + task->response_pl, task->response_pl_sz);
> + kfree(task);
> +}
> +
> +/**
> + * doe_ep_task_work() - Work function for processing DOE EP tasks
> + * @work: Work structure
> + *
> + * Process a DOE request by calling the appropriate protocol handler.
> + */
> +static void doe_ep_task_work(struct work_struct *work)
> +{
> + struct pci_ep_doe_task *task = container_of(work, struct pci_ep_doe_task,
> + work);
> + struct pci_ep_doe_mb *doe_mb = task->doe_mb;
> + pci_doe_protocol_handler_t handler;
> + int rc;
> +
> + if (test_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags)) {
> + signal_task_complete(task, -EIO);
> + return;
> + }
> +
> + /* Check if request was aborted */
> + if (test_bit(PCI_DOE_FLAG_CANCEL, &doe_mb->flags)) {
> + signal_task_complete(task, -ECANCELED);
> + return;
> + }
> +
> + /* Find protocol handler in the array */
> + handler = pci_ep_doe_find_protocol(task->feat.vid, task->feat.type);
> + if (!handler) {
> + dev_warn(doe_mb->epc->dev.parent,
> + "[%d:%x] Unsupported protocol VID=%04x TYPE=%02x\n",
> + doe_mb->func_no, doe_mb->cap_offset,
> + task->feat.vid, task->feat.type);
> + signal_task_complete(task, -EOPNOTSUPP);
> + return;
> + }
> +
> + /* Call protocol handler */
> + rc = handler(task->request_pl, task->request_pl_sz,
> + &task->response_pl, &task->response_pl_sz);
> +
> + signal_task_complete(task, rc);
> +}
> +
> +/**
> + * pci_ep_doe_submit_task() - Submit a task to be processed
> + * @doe_mb: DOE mailbox
> + * @task: Task to submit
> + *
> + * Submit a DOE task to the workqueue for asynchronous processing.
> + *
> + * RETURNS: 0 on success, -errno on failure
> + */
> +static int pci_ep_doe_submit_task(struct pci_ep_doe_mb *doe_mb,
> + struct pci_ep_doe_task *task)
> +{
> + if (test_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags))
> + return -EIO;
> +
> + task->doe_mb = doe_mb;
> + INIT_WORK(&task->work, doe_ep_task_work);
> + queue_work(doe_mb->work_queue, &task->work);
> + return 0;
> +}
> +
> +/**
> + * pci_ep_doe_process_request() - Process DOE request on endpoint
> + * @epc: PCI endpoint controller
> + * @func_no: Physical function number
> + * @cap_offset: DOE capability offset
> + * @vendor: Vendor ID from request header
> + * @type: Protocol type from request header
> + * @request: Request payload in CPU-native format
> + * @request_sz: Size of request payload (bytes)
> + * @complete: Callback to invoke upon completion
> + *
> + * Asynchronously process a DOE request received on the endpoint. The request
> + * payload should not include the DOE header (vendor/type/length). The protocol
> + * handler will allocate the response buffer, which the caller (controller driver)
> + * must free after use.
> + *
> + * This function returns immediately after queuing the request. The completion
> + * callback will be invoked asynchronously from workqueue context once the
> + * request is processed. The callback receives the function number and capability
> + * offset to identify the mailbox, along with a status code (0 on success, -errno
> + * on failure), and other required arguments.
> + *
> + * As per DOE specification, a mailbox processes one request at a time.
> + * Therefore, this function will never be called concurrently for the same
> + * mailbox by different callers.
> + *
> + * The caller is responsible for the conversion of the received DOE request
> + * with le32_to_cpu() before calling this function.
> + * Similarly, it is responsible for converting the response payload with
> + * cpu_to_le32() before sending it back over the DOE mailbox.
> + *
> + * The caller is also responsible for ensuring that the request size
> + * is within the limits defined by PCI_DOE_MAX_LENGTH.
> + *
> + * RETURNS: 0 if the request was successfully queued, -errno on failure
> + */
> +int pci_ep_doe_process_request(struct pci_epc *epc, u8 func_no, u16 cap_offset,
> + u16 vendor, u8 type, const void *request, size_t request_sz,
> + pci_ep_doe_complete_t complete)
> +{
> + struct pci_ep_doe_mb *doe_mb;
> + struct pci_ep_doe_task *task;
> + int rc;
> +
> + doe_mb = pci_ep_doe_get_mailbox(epc, func_no, cap_offset);
> + if (!doe_mb) {
> + kfree(request);
> + return -ENODEV;
> + }
> +
> + task = kzalloc_obj(*task, GFP_KERNEL);
> + if (!task) {
> + kfree(request);
> + return -ENOMEM;
> + }
> +
> + task->feat.vid = vendor;
> + task->feat.type = type;
> + task->request_pl = request;
> + task->request_pl_sz = request_sz;
> + task->response_pl = NULL;
> + task->response_pl_sz = 0;
> + task->complete = complete;
> +
> + rc = pci_ep_doe_submit_task(doe_mb, task);
> + if (rc) {
> + kfree(request);
> + kfree(task);
> + return rc;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_ep_doe_process_request);
So who is supposed to call this API? EPC driver that receives the DOE interrupt?
But I don't see the any callers of this and below exported APIs in this series.
Either you should add the callers or limit this series just to adding the DOE
skeleton implementation with a clear follow-up.
But since you've limited the scope of this series to support only DOE Discovery
Data Object Protocol, it'd be good to add the EPC implementation to get the full
picture.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v14 10/44] arm64: RMI: Add support for SRO
From: Aneesh Kumar K.V @ 2026-05-14 8:01 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Steven Price, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Suzuki K Poulose, Zenghui Yu,
linux-arm-kernel, linux-kernel, Joey Gouly, Alexandru Elisei,
Christoffer Dall, Fuad Tabba, linux-coco, Ganapatrao Kulkarni,
Gavin Shan, Shanker Donthineni, Alper Gun, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <20260513131757.116630-11-steven.price@arm.com>
Steven Price <steven.price@arm.com> writes:
> +unsigned long rmi_sro_execute(struct rmi_sro_state *sro, gfp_t gfp)
> +{
> + unsigned long sro_handle;
> + struct arm_smccc_1_2_regs regs;
> + struct arm_smccc_1_2_regs *regs_in = &sro->regs;
> +
> + rmi_smccc_invoke(regs_in, ®s);
> +
> + sro_handle = regs.a1;
> +
> + while (RMI_RETURN_STATUS(regs.a0) == RMI_INCOMPLETE) {
> + bool can_cancel = RMI_RETURN_CAN_CANCEL(regs.a0);
> + int ret;
> +
> + switch (RMI_RETURN_MEMREQ(regs.a0)) {
> + case RMI_OP_MEM_REQ_NONE:
> + regs = (struct arm_smccc_1_2_regs){
> + SMC_RMI_OP_CONTINUE, sro_handle, 0
> + };
> + rmi_smccc_invoke(®s, ®s);
> + break;
> + case RMI_OP_MEM_REQ_DONATE:
> + ret = rmi_sro_donate(sro, sro_handle, regs.a2, ®s,
> + gfp);
> + break;
> + case RMI_OP_MEM_REQ_RECLAIM:
> + ret = rmi_sro_reclaim(sro, sro_handle, ®s);
> + break;
> + default:
> + ret = WARN_ON(1);
> + break;
> + }
> +
> + if (ret) {
> + if (can_cancel) {
> + /*
> + * FIXME: Handle cancelling properly!
> + *
> + * If the operation has failed due to memory
> + * allocation failure then the information on
> + * the memory allocation should be saved, so
> + * that the allocation can be repeated outside
> + * of any context which prevented the
> + * allocation.
> + */
> + }
> + if (WARN_ON(ret))
> + return ret;
> + }
> + }
> +
> + return regs.a0;
> +}
Can you also add support to return x1,x2 etc
This would help things like
static int rmi_rtt_dev_unmap(unsigned long rd_phys,
unsigned long base, unsigned long top,
unsigned long *out_ipa, unsigned long *out_desc,
unsigned long *rmi_ret)
{
unsigned long flags = RMI_ADDR_TYPE_SINGLE;
struct rmi_sro_state *sro __free(sro) =
rmi_sro_init(SMC_RMI_RTT_DEV_UNMAP, rd_phys, base, top, flags, NULL);
if (!sro)
return -ENOMEM;
*rmi_ret = rmi_sro_execute(sro);
if (*rmi_ret)
return 0;
*out_ipa = sro->regs.a1;
*out_desc = sro->regs.a2;
return 0;
}
-aneesh
^ permalink raw reply
* [PATCH net-next v2 0/2] Add ICSSG firmware stats related to HSR
From: MD Danish Anwar @ 2026-05-14 7:56 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, MD Danish Anwar,
Roger Quadros, Andrew Lunn, Meghana Malladi, Jacob Keller,
David Carlier, Vadim Fedorenko, Kevin Hao
Cc: netdev, linux-doc, linux-kernel, linux-arm-kernel,
Vladimir Oltean
This series adds HSR and LRE firmware PA statistics to the TI ICSSG
ethtool stats interface, and places static_assert() guards next to the
stat descriptor arrays to catch count mismatches at build time.
Patch 1 adds static_assert() immediately after each of
icssg_all_miig_stats[] and icssg_all_pa_stats[] in icssg_stats.h,
verifying that ICSSG_NUM_MIIG_STATS and ICSSG_NUM_PA_STATS stay in
sync with the actual array sizes.
Patch 2 adds ten new firmware counters for HSR forwarding-path drops,
host-egress-path drops, and LRE duplicate-detection, updates
icssg_ndo_get_stats64() to fold the relevant counters into rx_errors
and rx_dropped, bumps ICSSG_NUM_PA_STATS to 42 (caught immediately by
the static_assert from patch 1 if the constant is ever left behind),
and documents all new entries in icssg_prueth.rst.
Changes in v2:
- Drop the ARRAY_SIZE()-based macro approach from v1 (which caused
binary bloat by pulling the static const arrays into every TU via
icssg_prueth.h) as suggested by David Carlier <devnexen@gmail.com>
- Add static_assert() next to each array in icssg_stats.h instead,
keeping the numeric #defines and the original include graph. As
suggested by David Carlier <devnexen@gmail.com>
v1 https://lore.kernel.org/all/20260512060627.3781329-1-danishanwar@ti.com/
MD Danish Anwar (2):
net: ti: icssg: Add static_assert to guard stat array counts
net: ti: icssg: Add HSR and LRE PA statistics
.../device_drivers/ethernet/ti/icssg_prueth.rst | 10 ++++++++++
drivers/net/ethernet/ti/icssg/icssg_common.c | 7 +++++--
drivers/net/ethernet/ti/icssg/icssg_prueth.h | 2 +-
drivers/net/ethernet/ti/icssg/icssg_stats.h | 14 ++++++++++++++
drivers/net/ethernet/ti/icssg/icssg_switch_map.h | 10 ++++++++++
5 files changed, 40 insertions(+), 3 deletions(-)
base-commit: 18dc8e6d15d7a30888beec46a1e01ca0f98508fa
--
2.34.1
^ permalink raw reply
* [PATCH net-next v2 2/2] net: ti: icssg: Add HSR and LRE PA statistics
From: MD Danish Anwar @ 2026-05-14 7:56 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, MD Danish Anwar,
Roger Quadros, Andrew Lunn, Meghana Malladi, Jacob Keller,
David Carlier, Vadim Fedorenko, Kevin Hao
Cc: netdev, linux-doc, linux-kernel, linux-arm-kernel,
Vladimir Oltean
In-Reply-To: <20260514075605.850674-1-danishanwar@ti.com>
Add new firmware PA statistics counters for HSR and LRE to the ethtool
statistics exposed by the ICSSG driver.
New statistics added:
- FW_HSR_FWD_CHECK_FAIL_DROP: Packets dropped on the HSR forwarding path
- FW_HSR_HE_CHECK_FAIL_DROP: Packets dropped on the HSR host egress path
- FW_HSR_SKIP_HOST_DUP_DISCARD_FRAMES: Frames with duplicate discard
skipped
- FW_LRE_CNT_UNIQUE/DUPLICATE/MULTIPLE_RX: LRE duplicate detection
counters
- FW_LRE_CNT_RX/TX: LRE per-port frame counters
- FW_LRE_CNT_OWN_RX: Own HSR tagged frames received
- FW_LRE_CNT_ERRWRONGLAN: Frames with wrong LAN identifier (PRP)
Document the new HSR/LRE statistics in icssg_prueth.rst.
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
---
.../device_drivers/ethernet/ti/icssg_prueth.rst | 10 ++++++++++
drivers/net/ethernet/ti/icssg/icssg_common.c | 7 +++++--
drivers/net/ethernet/ti/icssg/icssg_prueth.h | 2 +-
drivers/net/ethernet/ti/icssg/icssg_stats.h | 10 ++++++++++
drivers/net/ethernet/ti/icssg/icssg_switch_map.h | 10 ++++++++++
5 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/Documentation/networking/device_drivers/ethernet/ti/icssg_prueth.rst b/Documentation/networking/device_drivers/ethernet/ti/icssg_prueth.rst
index da21ddf431bb..b0bda7327b2a 100644
--- a/Documentation/networking/device_drivers/ethernet/ti/icssg_prueth.rst
+++ b/Documentation/networking/device_drivers/ethernet/ti/icssg_prueth.rst
@@ -54,3 +54,13 @@ These statistics are as follows,
- ``FW_HOST_TX_PKT_CNT``: Number of valid packets copied by RTU0 to Tx queues
- ``FW_HOST_EGRESS_Q_PRE_OVERFLOW``: Host Egress Q (Pre-emptible) Overflow Counter
- ``FW_HOST_EGRESS_Q_EXP_OVERFLOW``: Host Egress Q (Pre-emptible) Overflow Counter
+ - ``FW_HSR_FWD_CHECK_FAIL_DROP``: Packets dropped on the HSR forwarding path due to failed checks
+ - ``FW_HSR_HE_CHECK_FAIL_DROP``: Packets dropped on the host egress path due to failed checks
+ - ``FW_HSR_SKIP_HOST_DUP_DISCARD_FRAMES``: Frames for which the host duplicate discard check was skipped
+ - ``FW_LRE_CNT_UNIQUE_RX``: Number of frames received with no duplicate detected
+ - ``FW_LRE_CNT_DUPLICATE_RX``: Number of frames received for which exactly one duplicate was detected
+ - ``FW_LRE_CNT_MULTIPLE_RX``: Number of frames received for which more than one duplicate was detected
+ - ``FW_LRE_CNT_RX``: Number of HSR/PRP tagged frames received
+ - ``FW_LRE_CNT_TX``: Number of HSR/PRP tagged frames sent
+ - ``FW_LRE_CNT_OWN_RX``: Number of HSR/PRP tagged frames received whose source MAC matches the node's own address
+ - ``FW_LRE_CNT_ERRWRONGLAN``: Number of frames received with a wrong LAN identifier, PRP only
diff --git a/drivers/net/ethernet/ti/icssg/icssg_common.c b/drivers/net/ethernet/ti/icssg/icssg_common.c
index a28a608f9bf4..e7a51a9eee24 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_common.c
+++ b/drivers/net/ethernet/ti/icssg/icssg_common.c
@@ -1633,7 +1633,8 @@ void icssg_ndo_get_stats64(struct net_device *ndev,
emac_get_stat_by_name(emac, "FW_RX_EOF_SHORT_FRMERR") +
emac_get_stat_by_name(emac, "FW_RX_B0_DROP_EARLY_EOF") +
emac_get_stat_by_name(emac, "FW_RX_EXP_FRAG_Q_DROP") +
- emac_get_stat_by_name(emac, "FW_RX_FIFO_OVERRUN");
+ emac_get_stat_by_name(emac, "FW_RX_FIFO_OVERRUN") +
+ emac_get_stat_by_name(emac, "FW_LRE_CNT_ERRWRONGLAN");
stats->rx_dropped = ndev->stats.rx_dropped +
emac_get_stat_by_name(emac, "FW_DROPPED_PKT") +
emac_get_stat_by_name(emac, "FW_INF_PORT_DISABLED") +
@@ -1643,7 +1644,9 @@ void icssg_ndo_get_stats64(struct net_device *ndev,
emac_get_stat_by_name(emac, "FW_INF_DROP_TAGGED") +
emac_get_stat_by_name(emac, "FW_INF_DROP_PRIOTAGGED") +
emac_get_stat_by_name(emac, "FW_INF_DROP_NOTAG") +
- emac_get_stat_by_name(emac, "FW_INF_DROP_NOTMEMBER");
+ emac_get_stat_by_name(emac, "FW_INF_DROP_NOTMEMBER") +
+ emac_get_stat_by_name(emac, "FW_HSR_FWD_CHECK_FAIL_DROP") +
+ emac_get_stat_by_name(emac, "FW_HSR_HE_CHECK_FAIL_DROP");
stats->tx_errors = ndev->stats.tx_errors;
stats->tx_dropped = ndev->stats.tx_dropped +
emac_get_stat_by_name(emac, "FW_RTU_PKT_DROP") +
diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.h b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
index df93d15c5b78..60a8aedd334b 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_prueth.h
+++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
@@ -57,7 +57,7 @@
#define ICSSG_MAX_RFLOWS 8 /* per slice */
-#define ICSSG_NUM_PA_STATS 32
+#define ICSSG_NUM_PA_STATS 42
#define ICSSG_NUM_MIIG_STATS 60
/* Number of ICSSG related stats */
#define ICSSG_NUM_STATS (ICSSG_NUM_MIIG_STATS + ICSSG_NUM_PA_STATS)
diff --git a/drivers/net/ethernet/ti/icssg/icssg_stats.h b/drivers/net/ethernet/ti/icssg/icssg_stats.h
index 6f4400d8a0f6..08b5ab6f93da 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_stats.h
+++ b/drivers/net/ethernet/ti/icssg/icssg_stats.h
@@ -201,6 +201,16 @@ static const struct icssg_pa_stats icssg_all_pa_stats[] = {
ICSSG_PA_STATS(FW_HOST_TX_PKT_CNT),
ICSSG_PA_STATS(FW_HOST_EGRESS_Q_PRE_OVERFLOW),
ICSSG_PA_STATS(FW_HOST_EGRESS_Q_EXP_OVERFLOW),
+ ICSSG_PA_STATS(FW_HSR_FWD_CHECK_FAIL_DROP),
+ ICSSG_PA_STATS(FW_HSR_HE_CHECK_FAIL_DROP),
+ ICSSG_PA_STATS(FW_HSR_SKIP_HOST_DUP_DISCARD_FRAMES),
+ ICSSG_PA_STATS(FW_LRE_CNT_UNIQUE_RX),
+ ICSSG_PA_STATS(FW_LRE_CNT_DUPLICATE_RX),
+ ICSSG_PA_STATS(FW_LRE_CNT_MULTIPLE_RX),
+ ICSSG_PA_STATS(FW_LRE_CNT_RX),
+ ICSSG_PA_STATS(FW_LRE_CNT_TX),
+ ICSSG_PA_STATS(FW_LRE_CNT_OWN_RX),
+ ICSSG_PA_STATS(FW_LRE_CNT_ERRWRONGLAN),
};
static_assert(ARRAY_SIZE(icssg_all_pa_stats) == ICSSG_NUM_PA_STATS);
diff --git a/drivers/net/ethernet/ti/icssg/icssg_switch_map.h b/drivers/net/ethernet/ti/icssg/icssg_switch_map.h
index 7e053b8af3ec..bd2d54dd7f45 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_switch_map.h
+++ b/drivers/net/ethernet/ti/icssg/icssg_switch_map.h
@@ -266,5 +266,15 @@
#define FW_HOST_TX_PKT_CNT 0x0250
#define FW_HOST_EGRESS_Q_PRE_OVERFLOW 0x0258
#define FW_HOST_EGRESS_Q_EXP_OVERFLOW 0x0260
+#define FW_HSR_FWD_CHECK_FAIL_DROP 0x0500
+#define FW_HSR_HE_CHECK_FAIL_DROP 0x0508
+#define FW_HSR_SKIP_HOST_DUP_DISCARD_FRAMES 0x0510
+#define FW_LRE_CNT_UNIQUE_RX 0x0518
+#define FW_LRE_CNT_DUPLICATE_RX 0x0520
+#define FW_LRE_CNT_MULTIPLE_RX 0x0528
+#define FW_LRE_CNT_RX 0x0530
+#define FW_LRE_CNT_TX 0x0538
+#define FW_LRE_CNT_OWN_RX 0x0540
+#define FW_LRE_CNT_ERRWRONGLAN 0x0548
#endif /* __NET_TI_ICSSG_SWITCH_MAP_H */
--
2.34.1
^ permalink raw reply related
* [PATCH net-next v2 1/2] net: ti: icssg: Add static_assert to guard stat array counts
From: MD Danish Anwar @ 2026-05-14 7:56 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, MD Danish Anwar,
Roger Quadros, Andrew Lunn, Meghana Malladi, Jacob Keller,
David Carlier, Vadim Fedorenko, Kevin Hao
Cc: netdev, linux-doc, linux-kernel, linux-arm-kernel,
Vladimir Oltean
In-Reply-To: <20260514075605.850674-1-danishanwar@ti.com>
Place static_assert() immediately after each of icssg_all_miig_stats[]
and icssg_all_pa_stats[] in icssg_stats.h to verify at build time that
ICSSG_NUM_MIIG_STATS and ICSSG_NUM_PA_STATS stay in sync with the
actual array sizes. This turns a silent miscount into a build error
should either the constant or the array be updated independently.
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
---
drivers/net/ethernet/ti/icssg/icssg_stats.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/ti/icssg/icssg_stats.h b/drivers/net/ethernet/ti/icssg/icssg_stats.h
index 5ec0b38e0c67..6f4400d8a0f6 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_stats.h
+++ b/drivers/net/ethernet/ti/icssg/icssg_stats.h
@@ -155,6 +155,8 @@ static const struct icssg_miig_stats icssg_all_miig_stats[] = {
ICSSG_MIIG_STATS(tx_bytes, true),
};
+static_assert(ARRAY_SIZE(icssg_all_miig_stats) == ICSSG_NUM_MIIG_STATS);
+
#define ICSSG_PA_STATS(field) \
{ \
#field, \
@@ -201,4 +203,6 @@ static const struct icssg_pa_stats icssg_all_pa_stats[] = {
ICSSG_PA_STATS(FW_HOST_EGRESS_Q_EXP_OVERFLOW),
};
+static_assert(ARRAY_SIZE(icssg_all_pa_stats) == ICSSG_NUM_PA_STATS);
+
#endif /* __NET_TI_ICSSG_STATS_H */
--
2.34.1
^ permalink raw reply related
* [PATCH v1 1/3] dt-bindings: display: rockchip: analogix-dp: Expose inherited properties
From: Damon Ding @ 2026-05-14 7:01 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260514070133.2275069-1-damon.ding@rock-chips.com>
Expose the inherited properties from the base analogix-dp schema
to satisfy unevaluatedProperties constraints.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
.../bindings/display/rockchip/rockchip,analogix-dp.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
index bb75d898a5c5..896ded87880f 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
@@ -50,6 +50,13 @@ properties:
aux-bus:
$ref: /schemas/display/dp-aux-bus.yaml#
+ reg: true
+ interrupts: true
+ phys: true
+ phy-names: true
+ force-hpd: true
+ ports: true
+
required:
- compatible
- clocks
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 09/11] m68k: stmark2: use ioport.h macros for resources
From: Angelo Dureghello @ 2026-05-14 7:20 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Greg Ungerer,
linux-m68k, linux-kernel, linux-stm32, linux-arm-kernel,
linux-iio
In-Reply-To: <agTcoVbImqMgfQy5@ashevche-desk.local>
Hi Andy,
On 13.05.2026 23:18, Andy Shevchenko wrote:
> On Wed, May 13, 2026 at 11:14:33AM +0200, Angelo Dureghello wrote:
>
> > Align also other resource declaration using DEFINE_RES_.
>
> DEFINE_RES_*()
>
> ...
>
> > static struct resource dspi_spi0_resource[] = {
> > - [0] = {
> > - .start = MCFDSPI_BASE0,
> > - .end = MCFDSPI_BASE0 + 0xFF,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - [1] = {
> > - .start = 12,
> > - .end = 13,
> > - .flags = IORESOURCE_DMA,
> > - },
> > - [2] = {
> > - .start = MCF_IRQ_DSPI0,
> > - .end = MCF_IRQ_DSPI0,
> > - .flags = IORESOURCE_IRQ,
> > - },
> > + DEFINE_RES_MEM(MCFDSPI_BASE0, 0x100),
> > + DEFINE_RES_DMA(12),
> > + DEFINE_RES_DMA(13),
> > + DEFINE_RES_IRQ(MCF_IRQ_DSPI0),
> > };
>
> This conversion drops hard indices, would it be a problem (for example,
> some code modifies the fields based on the [hard coded] index...)?
>
> If not, perhaps good to mention in the commit message and move IRQ to be the
> second one?
>
i can't see any directly-related code accessing these resources by index,
so would not change this if there isn't any risk.
Also i see DEFINE_RES_() stuff widely used in other arch, so thios make me
think accessing by index is something wrong.
> --
> With Best Regards,
> Andy Shevchenko
Regards,
angelo
>
>
^ permalink raw reply
* Re: [PATCH v2 08/11] m68k: stmark2: add mcf5441x DAC platform devices
From: Angelo Dureghello @ 2026-05-14 7:15 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Greg Ungerer,
linux-m68k, linux-kernel, linux-stm32, linux-arm-kernel,
linux-iio
In-Reply-To: <agTcEECgJvBydhe2@ashevche-desk.local>
Hi Andy,
On 13.05.2026 23:16, Andy Shevchenko wrote:
> On Wed, May 13, 2026 at 11:14:32AM +0200, Angelo Dureghello wrote:
>
> > Add mcf5441x DAC platform devices.
>
> ...
>
> > +static struct resource dac0_resource[] = {
> > + DEFINE_RES_MEM(MCFDAC_BASE0, 0x100),
> > +};
> > +
> > +static struct platform_device dac0_device = {
> > + .name = "mcf54415_dac",
> > + .id = 0,
> > + .num_resources = ARRAY_SIZE(dac0_resource),
> > + .resource = dac0_resource,
> > +};
>
> It can be
>
> static struct resource dac0_resource = DEFINE_RES_MEM(MCFDAC_BASE0, 0x100);
>
> static struct platform_device dac0_device = {
> .name = "mcf54415_dac",
> .id = 0,
> .num_resources = 1,
> .resource = &dac0_resource,
> };
>
> ...
>
> Same for the rest. But I haven't seen the followups and don't know if those
> structures are going to be expanded. The commit message doesn't say anything
> about that. So I assume my suggestion valid.
>
no. They are not going to be expanded, anyway, is there a real gain
using an hardcoded 1 there ?
Would not reissue a v3 for this honestly.
> --
> With Best Regards,
> Andy Shevchenko
>
>
Regards,
angelo
^ permalink raw reply
* [PATCH 1/2] arm64: dts: s32g: add PIT support for s32g2 and s32g3
From: Khristine Andreea Barbulescu @ 2026-05-14 7:06 UTC (permalink / raw)
To: Chester Lin, Matthias Brugger, Ghennadi Procopciuc, Frank Li,
Sascha Hauer, Fabio Estevam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Pengutronix Kernel Team, linux-arm-kernel, imx, devicetree,
linux-kernel, NXP S32 Linux, Christophe Lizzi, Alberto Ruiz,
Enric Balletbo
In-Reply-To: <20260514070605.996462-1-khristineandreea.barbulescu@oss.nxp.com>
Add PIT0 and PIT1 for S32G2 and S32G3 SoCs
Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
---
arch/arm64/boot/dts/freescale/s32g2.dtsi | 20 +++++++++++++++++++-
arch/arm64/boot/dts/freescale/s32g3.dtsi | 20 +++++++++++++++++++-
2 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/s32g2.dtsi b/arch/arm64/boot/dts/freescale/s32g2.dtsi
index 51d00dac12de..57ff97e44507 100644
--- a/arch/arm64/boot/dts/freescale/s32g2.dtsi
+++ b/arch/arm64/boot/dts/freescale/s32g2.dtsi
@@ -3,7 +3,7 @@
* NXP S32G2 SoC family
*
* Copyright (c) 2021 SUSE LLC
- * Copyright 2017-2021, 2024-2025 NXP
+ * Copyright 2017-2021, 2024-2026 NXP
*/
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -417,6 +417,15 @@ edma0: dma-controller@40144000 {
clock-names = "dmamux0", "dmamux1";
};
+ pit0: pit@40188000 {
+ compatible = "nxp,s32g2-pit";
+ reg = <0x40188000 0x3000>;
+ interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks 61>;
+ clock-names = "pit";
+ status = "disabled";
+ };
+
can0: can@401b4000 {
compatible = "nxp,s32g2-flexcan";
reg = <0x401b4000 0xa000>;
@@ -622,6 +631,15 @@ edma1: dma-controller@40244000 {
clock-names = "dmamux0", "dmamux1";
};
+ pit1: pit@40288000 {
+ compatible = "nxp,s32g2-pit";
+ reg = <0x40288000 0x3000>;
+ interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks 61>;
+ clock-names = "pit";
+ status = "disabled";
+ };
+
can2: can@402a8000 {
compatible = "nxp,s32g2-flexcan";
reg = <0x402a8000 0xa000>;
diff --git a/arch/arm64/boot/dts/freescale/s32g3.dtsi b/arch/arm64/boot/dts/freescale/s32g3.dtsi
index e314f3c7d61d..efe5398e1240 100644
--- a/arch/arm64/boot/dts/freescale/s32g3.dtsi
+++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
/*
- * Copyright 2021-2025 NXP
+ * Copyright 2021-2026 NXP
*
* Authors: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
* Ciprian Costea <ciprianmarian.costea@nxp.com>
@@ -475,6 +475,15 @@ edma0: dma-controller@40144000 {
clock-names = "dmamux0", "dmamux1";
};
+ pit0: pit@40188000 {
+ compatible = "nxp,s32g3-pit", "nxp,s32g2-pit";
+ reg = <0x40188000 0x3000>;
+ interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks 61>;
+ clock-names = "pit";
+ status = "disabled";
+ };
+
can0: can@401b4000 {
compatible = "nxp,s32g3-flexcan",
"nxp,s32g2-flexcan";
@@ -693,6 +702,15 @@ edma1: dma-controller@40244000 {
clock-names = "dmamux0", "dmamux1";
};
+ pit1: pit@40288000 {
+ compatible = "nxp,s32g3-pit", "nxp,s32g2-pit";
+ reg = <0x40288000 0x3000>;
+ interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks 61>;
+ clock-names = "pit";
+ status = "disabled";
+ };
+
can2: can@402a8000 {
compatible = "nxp,s32g3-flexcan",
"nxp,s32g2-flexcan";
--
2.34.1
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: timer: pit: add PIT node example for s32g2/3 platforms
From: Khristine Andreea Barbulescu @ 2026-05-14 7:06 UTC (permalink / raw)
To: Chester Lin, Matthias Brugger, Ghennadi Procopciuc, Frank Li,
Sascha Hauer, Fabio Estevam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Pengutronix Kernel Team, linux-arm-kernel, imx, devicetree,
linux-kernel, NXP S32 Linux, Christophe Lizzi, Alberto Ruiz,
Enric Balletbo
In-Reply-To: <20260514070605.996462-1-khristineandreea.barbulescu@oss.nxp.com>
Add devicetree binding example for the PIT timer as used on
NXP S32G2 and S32G3 platforms.
Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
---
.../devicetree/bindings/timer/fsl,vf610-pit.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml b/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
index 42e130654d58..8696696776b3 100644
--- a/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
+++ b/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
@@ -57,3 +57,11 @@ examples:
clocks = <&clks VF610_CLK_PIT>;
clock-names = "pit";
};
+
+ pit@40188000 {
+ compatible = "nxp,s32g2-pit";
+ reg = <0x40188000 0x3000>;
+ interrupts = <53 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks 61>;
+ clock-names = "pit";
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] add PIT DTS support for S32G2/S32G3 SoCs
From: Khristine Andreea Barbulescu @ 2026-05-14 7:06 UTC (permalink / raw)
To: Chester Lin, Matthias Brugger, Ghennadi Procopciuc, Frank Li,
Sascha Hauer, Fabio Estevam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Pengutronix Kernel Team, linux-arm-kernel, imx, devicetree,
linux-kernel, NXP S32 Linux, Christophe Lizzi, Alberto Ruiz,
Enric Balletbo
This patchset aims to add one change to the S32G2/S32G3 dtsi support:
- Add PIT dts support for S32G SoC based boards
Khristine Andreea Barbulescu (2):
arm64: dts: s32g: add PIT support for s32g2 and s32g3
dt-bindings: timer: pit: add PIT node example for s32g2/3 platforms
.../bindings/timer/fsl,vf610-pit.yaml | 8 ++++++++
arch/arm64/boot/dts/freescale/s32g2.dtsi | 20 ++++++++++++++++++-
arch/arm64/boot/dts/freescale/s32g3.dtsi | 20 ++++++++++++++++++-
3 files changed, 46 insertions(+), 2 deletions(-)
--
2.34.1
^ 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