* Re: [PATCH] dt-bindings: Consolidate "sram" property definition
From: Heiko Stuebner @ 2026-06-02 15:06 UTC (permalink / raw)
To: Liu Ying, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Rob Clark, Sean Paul,
Konrad Dybcio, Akhil P Oommen, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Marijn Suijten, Vinod Koul, Nas Chung, Jackson Lee,
Mauro Carvalho Chehab, Mirela Rabulea, Detlev Casanova,
Ezequiel Garcia, Hugues Fruchet, Alain Volmat, Maxime Coquelin,
Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, MD Danish Anwar, Roger Quadros,
Parvathi Pudi, Mohan Reddy Putluru, Bjorn Andersson,
Mathieu Poirier, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Michal Simek, Mark Brown, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Lorenzo Bianconi,
Felix Fietkau, Andrew F. Davis, Hussain Khaja, Suman Anna,
Ben Levinsky, Tanmay Shah, Erwan Leray, Fabrice Gasnier,
Rob Herring (Arm)
Cc: Roger Quadros, dri-devel, devicetree, imx, linux-arm-kernel,
linux-kernel, linux-arm-msm, freedreno, dmaengine, linux-media,
linux-rockchip, linux-stm32, netdev, linux-remoteproc,
linux-amlogic, linux-spi, linux-mediatek
In-Reply-To: <20260511165942.2774868-1-robh@kernel.org>
Am Montag, 11. Mai 2026, 18:59:36 Mitteleuropäische Sommerzeit schrieb Rob Herring (Arm):
> The "sram" property has become a de facto standard property, so create a
> common schema for it and drop all the duplicated definitions.
>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
> ---
> .../bindings/media/rockchip,vdec.yaml | 5 ++--
Acked-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [Linux-stm32] [PATCH] dt-bindings: Consolidate "sram" property definition
From: Amelie Delaunay @ 2026-06-02 14:29 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: devicetree, imx, linux-arm-msm, linux-remoteproc, linux-kernel,
dri-devel, linux-spi, linux-rockchip, linux-mediatek, netdev,
dmaengine, linux-amlogic, linux-media, freedreno, linux-stm32,
linux-arm-kernel, Roger Quadros, Liu Ying, Philipp Zabel,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Clark,
Sean Paul, Konrad Dybcio, Akhil P Oommen, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, Vinod Koul,
Nas Chung, Jackson Lee, Mauro Carvalho Chehab, Mirela Rabulea,
Detlev Casanova, Ezequiel Garcia, Heiko Stuebner, Hugues Fruchet,
Alain Volmat, Maxime Coquelin, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
MD Danish Anwar, Roger Quadros, Parvathi Pudi,
Mohan Reddy Putluru, Bjorn Andersson, Mathieu Poirier,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Michal Simek, Mark Brown, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Lorenzo Bianconi,
Felix Fietkau, Andrew F. Davis, Hussain Khaja, Suman Anna,
Ben Levinsky, Tanmay Shah, Erwan Leray, Fabrice Gasnier
In-Reply-To: <20260511165942.2774868-1-robh@kernel.org>
On 5/11/26 18:59, Rob Herring (Arm) wrote:
> The "sram" property has become a de facto standard property, so create a
> common schema for it and drop all the duplicated definitions.
>
> Signed-off-by: Rob Herring (Arm)<robh@kernel.org>
> ---
> .../devicetree/bindings/spi/st,stm32-spi.yaml | 10 +++----
Acked-by: Amelie Delaunay <amelie.delaunay@foss.st.com> #st,stm32-spi.yaml
^ permalink raw reply
* Re: [PATCH] dt-bindings: Consolidate "sram" property definition
From: Alain Volmat @ 2026-06-02 13:03 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Liu Ying, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Rob Clark, Sean Paul,
Konrad Dybcio, Akhil P Oommen, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Marijn Suijten, Vinod Koul, Nas Chung, Jackson Lee,
Mauro Carvalho Chehab, Mirela Rabulea, Detlev Casanova,
Ezequiel Garcia, Heiko Stuebner, Hugues Fruchet, Maxime Coquelin,
Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, MD Danish Anwar, Roger Quadros,
Parvathi Pudi, Mohan Reddy Putluru, Bjorn Andersson,
Mathieu Poirier, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Michal Simek, Mark Brown, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Lorenzo Bianconi,
Felix Fietkau, Andrew F. Davis, Hussain Khaja, Suman Anna,
Ben Levinsky, Tanmay Shah, Erwan Leray, Fabrice Gasnier,
Roger Quadros, dri-devel, devicetree, imx, linux-arm-kernel,
linux-kernel, linux-arm-msm, freedreno, dmaengine, linux-media,
linux-rockchip, linux-stm32, netdev, linux-remoteproc,
linux-amlogic, linux-spi, linux-mediatek
In-Reply-To: <20260511165942.2774868-1-robh@kernel.org>
On Mon, May 11, 2026 at 11:59:36AM -0500, Rob Herring (Arm) wrote:
> The "sram" property has become a de facto standard property, so create a
> common schema for it and drop all the duplicated definitions.
>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
> ---
>
> .../bindings/media/st,stm32-dcmi.yaml | 6 ++---
Acked-by: Alain Volmat <alain.volmat@foss.st.com>
^ permalink raw reply
* [PATCH 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: Roman Vivchar via B4 Relay @ 2026-06-02 12:46 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar
In-Reply-To: <20260602-mt6323-adc-v1-0-68ec737508ee@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The mt6323 AUXADC is a 15-bit ADC used for system monitoring. This driver
provides support for reading various channels including battery and
charger voltages, battery and chip temperature, current sensing and
accessory detection.
Add a driver for the AUXADC found in the MediaTek mt6323 PMIC.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
MAINTAINERS | 8 ++
drivers/iio/adc/Kconfig | 11 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/mt6323-auxadc.c | 299 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 319 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d1cc0e12fe1f..c9ad2417a3ef 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16256,6 +16256,14 @@ S: Maintained
F: Documentation/devicetree/bindings/mmc/mtk-sd.yaml
F: drivers/mmc/host/mtk-sd.c
+MEDIATEK MT6323 PMIC AUXADC DRIVER
+M: Roman Vivchar <rva333@protonmail.com>
+L: linux-iio@vger.kernel.org
+L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: drivers/iio/adc/mt6323-auxadc.c
+F: include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
+
MEDIATEK MT6735 CLOCK & RESET DRIVERS
M: Yassine Oudjana <y.oudjana@protonmail.com>
L: linux-clk@vger.kernel.org
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 60038ae8dfc4..a03614b46041 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -1137,6 +1137,17 @@ config MCP3911
This driver can also be built as a module. If so, the module will be
called mcp3911.
+config MEDIATEK_MT6323_AUXADC
+ tristate "MediaTek MT6323 PMIC AUXADC driver"
+ depends on MFD_MT6397
+ help
+ Say yes here to enable support for MediaTek MT6323 PMIC Auxiliary ADC.
+ This driver provides multiple channels for system monitoring,
+ such as battery voltage, PMIC temperature, and others.
+
+ This driver can also be built as a module. If so, the module will be
+ called mt6323-auxadc.
+
config MEDIATEK_MT6359_AUXADC
tristate "MediaTek MT6359 PMIC AUXADC driver"
depends on MFD_MT6397
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index c76550415ff1..58161750d6e3 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -99,6 +99,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
obj-$(CONFIG_MCP3422) += mcp3422.o
obj-$(CONFIG_MCP3564) += mcp3564.o
obj-$(CONFIG_MCP3911) += mcp3911.o
+obj-$(CONFIG_MEDIATEK_MT6323_AUXADC) += mt6323-auxadc.o
obj-$(CONFIG_MEDIATEK_MT6359_AUXADC) += mt6359-auxadc.o
obj-$(CONFIG_MEDIATEK_MT6360_ADC) += mt6360-adc.o
obj-$(CONFIG_MEDIATEK_MT6370_ADC) += mt6370-adc.o
diff --git a/drivers/iio/adc/mt6323-auxadc.c b/drivers/iio/adc/mt6323-auxadc.c
new file mode 100644
index 000000000000..da6c11a5079c
--- /dev/null
+++ b/drivers/iio/adc/mt6323-auxadc.c
@@ -0,0 +1,299 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2026 Roman Vivchar <rva333@protonmail.com>
+ *
+ * Based on drivers/iio/adc/mt6359-auxadc.c
+ */
+
+#include <linux/array_size.h>
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/cleanup.h>
+#include <linux/delay.h>
+#include <linux/iio/iio.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/stringify.h>
+#include <linux/time.h>
+#include <linux/types.h>
+
+#include <linux/mfd/mt6323/registers.h>
+
+#include <dt-bindings/iio/adc/mediatek,mt6323-auxadc.h>
+
+#define AUXADC_STRUP_CON10_RSTB_SEL BIT(7)
+#define AUXADC_STRUP_CON10_RSTB_SW BIT(5)
+
+#define AUXADC_TOP_CKPDN2_CTL_CK BIT(5)
+
+#define AUXADC_TRIM_CH2_MASK GENMASK(11, 10)
+#define AUXADC_TRIM_CH4_MASK GENMASK(9, 8)
+#define AUXADC_TRIM_CH5_MASK GENMASK(5, 4)
+#define AUXADC_TRIM_CH6_MASK GENMASK(3, 2)
+
+#define AUXADC_CON27_VREF18_ENB_MD BIT(15)
+#define AUXADC_CON27_MD_STATUS BIT(0)
+
+#define AUXADC_CON19_GPS_STATUS BIT(1)
+
+#define AUXADC_CON26_VREF18_SELB BIT(1)
+#define AUXADC_CON26_DECI_GDLY_SEL BIT(0)
+
+#define AUXADC_CON11_VBUF_EN BIT(4)
+
+#define AUXADC_CON19_DECI_GDLY_MASK GENMASK(15, 14)
+#define AUXADC_ADC19_BUSY_MASK GENMASK(15, 1)
+#define AUXADC_READY_MASK BIT(15)
+#define AUXADC_DATA_MASK GENMASK(14, 0)
+
+#define AUXADC_CON9_OSR_MASK GENMASK(12, 10)
+#define AUXADC_DEFAULT_OSR 3
+
+#define AUXADC_LOW_CHANNEL_MASK GENMASK(9, 0)
+#define AUXADC_AUDIO_CHANNEL_MASK GENMASK(8, 0)
+
+#define MTK_PMIC_IIO_CHAN(_name, _chan, _addr, _ch_type) \
+{ \
+ .type = _ch_type, \
+ .indexed = 1, \
+ .channel = _chan, \
+ .address = _addr, \
+ .datasheet_name = __stringify(_name), \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_SCALE), \
+}
+
+static const struct iio_chan_spec mt6323_auxadc_channels[] = {
+ MTK_PMIC_IIO_CHAN(baton2, MT6323_AUXADC_BATON2, MT6323_AUXADC_ADC6, IIO_VOLTAGE),
+ MTK_PMIC_IIO_CHAN(ch6, MT6323_AUXADC_CH6, MT6323_AUXADC_ADC11, IIO_VOLTAGE),
+ MTK_PMIC_IIO_CHAN(bat_temp, MT6323_AUXADC_BAT_TEMP, MT6323_AUXADC_ADC5, IIO_VOLTAGE),
+ MTK_PMIC_IIO_CHAN(chip_temp, MT6323_AUXADC_CHIP_TEMP, MT6323_AUXADC_ADC4, IIO_VOLTAGE),
+ MTK_PMIC_IIO_CHAN(vcdt, MT6323_AUXADC_VCDT, MT6323_AUXADC_ADC2, IIO_VOLTAGE),
+ MTK_PMIC_IIO_CHAN(baton1, MT6323_AUXADC_BATON1, MT6323_AUXADC_ADC3, IIO_VOLTAGE),
+ MTK_PMIC_IIO_CHAN(isense, MT6323_AUXADC_ISENSE, MT6323_AUXADC_ADC1, IIO_VOLTAGE),
+ MTK_PMIC_IIO_CHAN(batsns, MT6323_AUXADC_BATSNS, MT6323_AUXADC_ADC0, IIO_VOLTAGE),
+ MTK_PMIC_IIO_CHAN(accdet, MT6323_AUXADC_ACCDET, MT6323_AUXADC_ADC7, IIO_VOLTAGE),
+};
+
+/**
+ * struct mt6323_auxadc - Main driver structure
+ * @regmap: Regmap from PWRAP
+ * @lock: Mutex to serialize AUXADC reading vs configuration
+ *
+ * The MediaTek MT6323 (as well as a lot of other PMICs) has the following hierarchy:
+ * PMIC AUXADC <- PMIC MFD <- SoC PWRAP (wrapper for PWRAP FSM)
+ *
+ * Therefore, PWRAP regmap should be obtained using dev->parent->parent.
+ */
+struct mt6323_auxadc {
+ struct regmap *regmap;
+ struct mutex lock;
+};
+
+static int mt6323_auxadc_prepare_channel(struct mt6323_auxadc *auxadc)
+{
+ struct regmap *map = auxadc->regmap;
+ u32 val;
+ int ret;
+
+ ret = regmap_read(map, MT6323_AUXADC_CON19, &val);
+ if (ret)
+ return ret;
+
+ /* The ADC is idle. */
+ if (!(val & AUXADC_CON19_DECI_GDLY_MASK))
+ return 0;
+
+ ret = regmap_read_poll_timeout(map, MT6323_AUXADC_ADC19, val,
+ !(val & AUXADC_ADC19_BUSY_MASK),
+ 10, 500);
+ if (ret)
+ return ret;
+
+ return regmap_clear_bits(map, MT6323_AUXADC_CON19,
+ AUXADC_CON19_DECI_GDLY_MASK);
+}
+
+static int mt6323_auxadc_request(struct mt6323_auxadc *auxadc,
+ unsigned long channel)
+{
+ struct regmap *map = auxadc->regmap;
+ int ret;
+
+ ret = regmap_set_bits(map, MT6323_AUXADC_CON11, AUXADC_CON11_VBUF_EN);
+ if (ret)
+ return ret;
+
+ ret = regmap_clear_bits(map, MT6323_AUXADC_CON22, BIT(channel));
+ if (ret)
+ return ret;
+
+ return regmap_set_bits(map, MT6323_AUXADC_CON22, BIT(channel));
+}
+
+static int mt6323_auxadc_read(struct mt6323_auxadc *auxadc,
+ const struct iio_chan_spec *chan, int *out)
+{
+ struct regmap *map = auxadc->regmap;
+ u32 reg = chan->address;
+ u32 val;
+ int ret;
+
+ ret = regmap_read_poll_timeout(map, reg, val, (val & AUXADC_READY_MASK),
+ 1 * USEC_PER_MSEC, 100 * USEC_PER_MSEC);
+ if (ret)
+ return ret;
+
+ *out = FIELD_GET(AUXADC_DATA_MASK, val);
+
+ return 0;
+}
+
+static int mt6323_auxadc_read_raw(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan,
+ int *val, int *val2, long mask)
+{
+ struct mt6323_auxadc *auxadc = iio_priv(indio_dev);
+ int ret, mult;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_SCALE:
+ if (chan->channel == MT6323_AUXADC_ISENSE ||
+ chan->channel == MT6323_AUXADC_BATSNS)
+ mult = 4;
+ else
+ mult = 1;
+
+ /* 1800mV full range with 15-bit resolution. */
+ *val = mult * 1800;
+ *val2 = 15;
+
+ return IIO_VAL_FRACTIONAL_LOG2;
+ case IIO_CHAN_INFO_RAW:
+ scoped_guard(mutex, &auxadc->lock) {
+ ret = mt6323_auxadc_prepare_channel(auxadc);
+ if (ret)
+ return ret;
+
+ ret = mt6323_auxadc_request(auxadc, chan->channel);
+ if (ret)
+ return ret;
+
+ /* Hardware limitation: the AUXADC needs a delay to become ready. */
+ fsleep(300);
+
+ ret = mt6323_auxadc_read(auxadc, chan, val);
+ if (ret)
+ return ret;
+ }
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int mt6323_auxadc_init(struct mt6323_auxadc *auxadc)
+{
+ struct regmap *map = auxadc->regmap;
+ int ret;
+
+ ret = regmap_set_bits(map, MT6323_STRUP_CON10,
+ AUXADC_STRUP_CON10_RSTB_SW |
+ AUXADC_STRUP_CON10_RSTB_SEL);
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(map, MT6323_TOP_CKPDN2, AUXADC_TOP_CKPDN2_CTL_CK);
+ if (ret)
+ return ret;
+
+ ret = regmap_update_bits(map, MT6323_AUXADC_CON10,
+ AUXADC_TRIM_CH2_MASK | AUXADC_TRIM_CH4_MASK |
+ AUXADC_TRIM_CH5_MASK | AUXADC_TRIM_CH6_MASK,
+ FIELD_PREP(AUXADC_TRIM_CH2_MASK, 1) |
+ FIELD_PREP(AUXADC_TRIM_CH4_MASK, 1) |
+ FIELD_PREP(AUXADC_TRIM_CH5_MASK, 1) |
+ FIELD_PREP(AUXADC_TRIM_CH6_MASK, 1));
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(map, MT6323_AUXADC_CON27,
+ AUXADC_CON27_VREF18_ENB_MD |
+ AUXADC_CON27_MD_STATUS);
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(map, MT6323_AUXADC_CON19, AUXADC_CON19_GPS_STATUS);
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(map, MT6323_AUXADC_CON26,
+ AUXADC_CON26_VREF18_SELB |
+ AUXADC_CON26_DECI_GDLY_SEL);
+ if (ret)
+ return ret;
+
+ return regmap_update_bits(map, MT6323_AUXADC_CON9, AUXADC_CON9_OSR_MASK,
+ FIELD_PREP(AUXADC_CON9_OSR_MASK, AUXADC_DEFAULT_OSR));
+}
+
+static const struct iio_info mt6323_auxadc_iio_info = {
+ .read_raw = mt6323_auxadc_read_raw,
+};
+
+static int mt6323_auxadc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct mt6323_auxadc *auxadc;
+ struct iio_dev *iio;
+ struct regmap *regmap;
+ int ret;
+
+ regmap = dev_get_regmap(dev->parent->parent, NULL);
+ if (!regmap)
+ return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
+
+ iio = devm_iio_device_alloc(dev, sizeof(*auxadc));
+ if (!iio)
+ return -ENOMEM;
+
+ auxadc = iio_priv(iio);
+ auxadc->regmap = regmap;
+
+ ret = devm_mutex_init(dev, &auxadc->lock);
+ if (ret)
+ return ret;
+
+ ret = mt6323_auxadc_init(auxadc);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to initialize auxadc\n");
+
+ iio->name = "mt6323-auxadc";
+ iio->info = &mt6323_auxadc_iio_info;
+ iio->modes = INDIO_DIRECT_MODE;
+ iio->channels = mt6323_auxadc_channels;
+ iio->num_channels = ARRAY_SIZE(mt6323_auxadc_channels);
+
+ return devm_iio_device_register(dev, iio);
+}
+
+static const struct of_device_id mt6323_auxadc_of_match[] = {
+ { .compatible = "mediatek,mt6323-auxadc" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, mt6323_auxadc_of_match);
+
+static struct platform_driver mt6323_auxadc_driver = {
+ .driver = {
+ .name = "mt6323-auxadc",
+ .of_match_table = mt6323_auxadc_of_match,
+ },
+ .probe = mt6323_auxadc_probe,
+};
+module_platform_driver(mt6323_auxadc_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MediaTek MT6323 PMIC AUXADC Driver");
--
2.54.0
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADC
From: Roman Vivchar via B4 Relay @ 2026-06-02 12:46 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar
In-Reply-To: <20260602-mt6323-adc-v1-0-68ec737508ee@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The MediaTek mt6323 PMIC includes an AUXADC used for battery voltage,
temperature, and other internal measurements.
Add the devicetree binding documentation and the associated header file
defining the ADC channel constants.
Also change the description to the 'MT6350 series and similar' because
the binding already includes more than mt635x series PMICs.
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
.../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 3 ++-
.../dt-bindings/iio/adc/mediatek,mt6323-auxadc.h | 24 ++++++++++++++++++++++
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
index 5d4ab701f51a..852eb7336a5a 100644
--- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/adc/mediatek,mt6359-auxadc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek MT6350 series PMIC AUXADC
+title: MediaTek MT6350 series and similar PMIC AUXADC
maintainers:
- AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
@@ -19,6 +19,7 @@ description:
properties:
compatible:
enum:
+ - mediatek,mt6323-auxadc
- mediatek,mt6357-auxadc
- mediatek,mt6358-auxadc
- mediatek,mt6359-auxadc
diff --git a/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h b/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
new file mode 100644
index 000000000000..6ee9a9ecffc1
--- /dev/null
+++ b/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+#ifndef _DT_BINDINGS_MEDIATEK_MT6323_AUXADC_H
+#define _DT_BINDINGS_MEDIATEK_MT6323_AUXADC_H
+
+#define MT6323_AUXADC_BATON2 0
+#define MT6323_AUXADC_CH6 1
+#define MT6323_AUXADC_BAT_TEMP 2
+#define MT6323_AUXADC_CHIP_TEMP 3
+#define MT6323_AUXADC_VCDT 4
+#define MT6323_AUXADC_BATON1 5
+#define MT6323_AUXADC_ISENSE 6
+#define MT6323_AUXADC_BATSNS 7
+#define MT6323_AUXADC_ACCDET 8
+#define MT6323_AUXADC_AUDIO0 9
+#define MT6323_AUXADC_AUDIO1 10
+#define MT6323_AUXADC_AUDIO2 11
+#define MT6323_AUXADC_AUDIO3 12
+#define MT6323_AUXADC_AUDIO4 13
+#define MT6323_AUXADC_AUDIO5 14
+#define MT6323_AUXADC_AUDIO6 15
+#define MT6323_AUXADC_AUDIO7 16
+
+#endif
--
2.54.0
^ permalink raw reply related
* [PATCH 3/4] mfd: mt6397-core: add mt6323 AUXADC support
From: Roman Vivchar via B4 Relay @ 2026-06-02 12:46 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar
In-Reply-To: <20260602-mt6323-adc-v1-0-68ec737508ee@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The mt6323 PMIC includes an AUXADC. Register the AUXADC in the mt6323
devices array to allow the corresponding driver to probe using compatible
string.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
drivers/mfd/mt6397-core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index 3e58d0764c7e..013b0857fb54 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -125,6 +125,9 @@ static const struct resource mt6323_pwrc_resources[] = {
static const struct mfd_cell mt6323_devs[] = {
{
+ .name = "mt6323-auxadc",
+ .of_compatible = "mediatek,mt6323-auxadc",
+ }, {
.name = "mt6323-rtc",
.num_resources = ARRAY_SIZE(mt6323_rtc_resources),
.resources = mt6323_rtc_resources,
--
2.54.0
^ permalink raw reply related
* [PATCH 0/4] AUXADC driver for the MediaTek mt6323 PMIC
From: Roman Vivchar via B4 Relay @ 2026-06-02 12:46 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar
This series adds support for the 15-bit AUXADC hardware block found on
the MediaTek mt6323 PMIC.
The previous version of the series for all AUXADC, EFUSE and thermal
drivers was split after Krzysztof's comment [1].
Tested on the MediaTek mt6572 and mt8163 SoCs (Ben), both paired with a
mt6323.
The other parts (EFUSE and thermal) will probably be sent next week.
[1]: https://lore.kernel.org/linux-mediatek/20260504-mt6323-v1-0-799b58b355ff@protonmail.com/T/#med30fad67a090be35f549231336b2dec295233f6
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
Changes after split:
- dt-bindings: Change 'MT63xx' to 'MT6350 series and similar' (Jonathan)
- AUXADC driver:
- Add missing headers (Andy)
- Fix AUXADC_TRIM_CH* values (Andy)
- Rename masks to include their register name (Jonathan)
- Fix formatting (Andy, Jonathan)
- Replace channel address with actual register value (Jonathan), align the table
- Replace IIO_TEMP with IIO_VOLTAGE, since the actual output is still mV, not mC
- Rename constants to match their registers (Jonathan)
- Remove 'if/else if/else' in the mt6323_auxadc_read_raw (Andy)
- Add comments for fsleep, ADC range and resolution (Andy, Jonathan)
- Remove useless error messages (Andy)
- Maintainers:
- Explicitly include mt6323 in the name (Jonathan)
- Squash with AUXADC driver commit (Krzysztof)
- Set status back to 'Maintained'
- Link to a previous series: https://patch.msgid.link/20260512-mt6323-v2-0-3efcba579e88@protonmail.com
---
Roman Vivchar (4):
dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADC
iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
mfd: mt6397-core: add mt6323 AUXADC support
ARM: dts: mediatek: mt6323: add AUXADC support
.../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 3 +-
MAINTAINERS | 8 +
arch/arm/boot/dts/mediatek/mt6323.dtsi | 5 +
drivers/iio/adc/Kconfig | 11 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/mt6323-auxadc.c | 299 +++++++++++++++++++++
drivers/mfd/mt6397-core.c | 3 +
.../dt-bindings/iio/adc/mediatek,mt6323-auxadc.h | 24 ++
8 files changed, 353 insertions(+), 1 deletion(-)
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260525-mt6323-adc-3befce36cbf2
Best regards,
--
Roman Vivchar <rva333@protonmail.com>
^ permalink raw reply
* [PATCH 4/4] ARM: dts: mediatek: mt6323: add AUXADC support
From: Roman Vivchar via B4 Relay @ 2026-06-02 12:46 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar
In-Reply-To: <20260602-mt6323-adc-v1-0-68ec737508ee@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
Add the devicetree node for the mt6323 AUXADC.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
arch/arm/boot/dts/mediatek/mt6323.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/mt6323.dtsi b/arch/arm/boot/dts/mediatek/mt6323.dtsi
index c230c865116d..c070f4b0936c 100644
--- a/arch/arm/boot/dts/mediatek/mt6323.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt6323.dtsi
@@ -14,6 +14,11 @@ pmic: mt6323 {
interrupt-controller;
#interrupt-cells = <2>;
+ mt6323_adc: adc {
+ compatible = "mediatek,mt6323-auxadc";
+ #io-channel-cells = <1>;
+ };
+
mt6323_leds: leds {
compatible = "mediatek,mt6323-led";
#address-cells = <1>;
--
2.54.0
^ permalink raw reply related
* Re: [PATCHv2] ASoC: mediatek: mt2701: fix snprintf bounds
From: Mark Brown @ 2026-06-01 14:00 UTC (permalink / raw)
To: linux-sound, Rosen Penev
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Matthias Brugger,
AngeloGioacchino Del Regno, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260522014515.719973-1-rosenp@gmail.com>
On Thu, 21 May 2026 18:45:15 -0700, Rosen Penev wrote:
> ASoC: mediatek: mt2701: fix snprintf bounds
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
Thanks!
[1/1] ASoC: mediatek: mt2701: fix snprintf bounds
https://git.kernel.org/broonie/sound/c/6c52e58dbdae
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* RE: [External Mail] Re: [PATCH 00/11] net: wwan: t9xx: Add MediaTek T9XX WWAN driver
From: Wu. JackBB (GSM) @ 2026-06-02 10:58 UTC (permalink / raw)
To: Jakub Kicinski, Jack Wu via B4 Relay
Cc: Loic Poulain, Sergey Ryazanov, Johannes Berg, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Wen-Zhi Huang,
Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <20260601173401.2c892526@kernel.org>
Hi Jakub,
> On Fri, 29 May 2026 18:31:39 +0800 Jack Wu via B4 Relay wrote:
> > 43 files changed, 14761 insertions(+)
>
> Please try to cut this down to ~5kLoC for the initial submission.
> Whatever the absolute minimum sensible chunk of code is.
>
> Each patch must build cleanly with W=1
We've already reduced this significantly from the original 41k LoC
down to ~14.7k by stripping out non-essential features such as
exception handling, memory logging, devlink, statistics, debug
tracing, and others.
We even removed some arguably necessary features (PM, mdlog,
throughput optimizations) that we plan to submit as follow-up
series.
Note that the line count may slightly increase in v2, as we plan
to add missing kdoc comments based on review feedback.
For reference, the t7xx driver (two generations older, simpler HW)
had an initial submission of ~11.3k LoC [1]. The t9xx hardware is
more complex, so we believe being in a similar range is reasonable.
We'd like to keep the driver functional and reviewable in its
current scope. Do you have any suggestions on how we could further
reduce the size while maintaining a working initial submission?
[1] https://patchwork.kernel.org/project/netdevbpf/cover/20220506181310.2183829-1-ricardo.martinez@linux.intel.com/
Thanks.
================================================================================================================================================================
This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
================================================================================================================================================================
^ permalink raw reply
* RE: [External Mail] Re: [PATCH 00/11] net: wwan: t9xx: Add MediaTek T9XX WWAN driver
From: Wu. JackBB (GSM) @ 2026-06-02 9:28 UTC (permalink / raw)
To: Loic Poulain
Cc: Sergey Ryazanov, Johannes Berg, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Wen-Zhi Huang,
Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <CAFEp6-0ntknHnpsj99YUHpD8R5SMDHf8Upn+yaED-A-sxonscw@mail.gmail.com>
Hi Loic,
>
> Hi Jack,
>
> On Fri, May 29, 2026 at 12:31 PM Jack Wu via B4 Relay
> <devnull+jackbb_wu.compal.com@kernel.org> wrote:
> >
> > T9XX is the PCIe host device driver for MediaTek's
> > t900 modem. The driver uses the WWAN framework
> > infrastructure to create the following control ports
> > and network interfaces for data transactions.
> > * /dev/wwan0at0 - Interface that supports AT commands.
> > * /dev/wwan0mbim0 - Interface conforming to the MBIM
> > protocol.
> > * wwan0-X - Primary network interface for IP traffic.
> >
> > The main blocks in the T9XX driver are:
> > * HW layer - Abstracts the hardware bus operations for
> > the device, and provides generic interfaces for the
> > transaction layer to get the device's information and
> > control the device's behavior. It includes:
> >
> > * PCIe - Implements probe, removal and interrupt
> > handling.
> > * MHCCIF (Modem Host Cross-Core Interface) - Provides
> > interrupt channels for bidirectional event
> > notification such as handshake and port enumeration.
> >
> > * Transaction layer - Implements data transactions for
> > the control plane and the data plane. It includes:
> >
> > * DPMAIF (Data Plane Modem AP Interface) - Controls
> > the hardware that provides uplink and downlink
> > queues for the data path. The data exchange takes
> > place using circular buffers to share data buffer
> > addresses and metadata to describe the packets.
> > * CLDMA (Cross Layer DMA) - Manages the hardware
> > used by the port layer to send control messages to
> > the device using MediaTek's CCCI (Cross-Core
> > Communication Interface) protocol.
> > * TX Services - Dispatch packets from the port layer
> > to the device.
> > * RX Services - Dispatch packets to the port layer
> > when receiving packets from the device.
> >
> > * Port layer - Provides control plane and data plane
> > interfaces to userspace. It includes:
> >
> > * Control Plane - Provides device node interfaces
> > for controlling data transactions.
> > * Data Plane - Provides network link interfaces
> > wwanX (0, 1, 2...) for IP data transactions.
> >
> > * Core logic - Contains the core logic to keep the
> > device working. It includes:
> >
> > * FSM (Finite State Machine) - Monitors the state
> > of the device, and notifies each module when the
> > state changes.
> >
> > The compilation of the T9XX driver is enabled by the
> > CONFIG_MTK_T9XX and CONFIG_MTK_T9XX_PCI config option
> > which depends on CONFIG_WWAN.
>
> Can you specify which userspace counterpart you need (e.g., a
> ModemManager version or a link to the relevant patch series)?
>
The driver is agnostic to the userspace application. We verified
functionality using ModemManager v1.23.4 and v1.25.95, and both
work out of the box.
>
> >
> > ---
> > Jack Wu (11):
> > net: wwan: t9xx: Add PCIe core
> > net: wwan: t9xx: Add control plane transaction layer
> > net: wwan: t9xx: Add control DMA interface
> > net: wwan: t9xx: Add control port
> > net: wwan: t9xx: Add FSM thread
> > net: wwan: t9xx: Add AT & MBIM WWAN ports
> > net: wwan: t9xx: Introduce data plane hardware
> > net: wwan: t9xx: Add data plane transaction layer
> > net: wwan: t9xx: Introduce WWAN interface
> > net: wwan: t9xx: Add power management support
> > net: wwan: t9xx: Add maintainers and documentation
> >
> > .../networking/device_drivers/wwan/t9xx.rst | 48 +
> > MAINTAINERS | 10 +
> > drivers/net/wwan/Kconfig | 17 +
> > drivers/net/wwan/Makefile | 1 +
> > drivers/net/wwan/t9xx/Makefile | 16 +
> > drivers/net/wwan/t9xx/mtk_ctrl_plane.c | 95 +
> > drivers/net/wwan/t9xx/mtk_ctrl_plane.h | 88 +
> > drivers/net/wwan/t9xx/mtk_data_plane.c | 104 +
> > drivers/net/wwan/t9xx/mtk_data_plane.h | 105 +
> > drivers/net/wwan/t9xx/mtk_dev.c | 55 +
> > drivers/net/wwan/t9xx/mtk_dev.h | 114 +
> > drivers/net/wwan/t9xx/mtk_fsm.c | 931 +++++++
> > drivers/net/wwan/t9xx/mtk_fsm.h | 140 +
> > drivers/net/wwan/t9xx/mtk_port.c | 967 +++++++
> > drivers/net/wwan/t9xx/mtk_port.h | 176 ++
> > drivers/net/wwan/t9xx/mtk_port_io.c | 576 +++++
> > drivers/net/wwan/t9xx/mtk_port_io.h | 41 +
> > drivers/net/wwan/t9xx/mtk_utility.h | 33 +
> > drivers/net/wwan/t9xx/mtk_wwan.c | 475 ++++
> > drivers/net/wwan/t9xx/mtk_wwan.h | 17 +
> > drivers/net/wwan/t9xx/pcie/Makefile | 19 +
> > drivers/net/wwan/t9xx/pcie/mtk_cldma.c | 1527 +++++++++++
> > drivers/net/wwan/t9xx/pcie/mtk_cldma.h | 176 ++
> > drivers/net/wwan/t9xx/pcie/mtk_cldma_drv.c | 373 +++
> > drivers/net/wwan/t9xx/pcie/mtk_cldma_drv.h | 174 ++
> > drivers/net/wwan/t9xx/pcie/mtk_cldma_drv_m9xx.c | 177 ++
> > drivers/net/wwan/t9xx/pcie/mtk_cldma_drv_m9xx.h | 101 +
> > drivers/net/wwan/t9xx/pcie/mtk_ctrl_cfg_m9xx.c | 55 +
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif.c | 2714 ++++++++++++++++++++
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif.h | 16 +
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif_drv.c | 1586 ++++++++++++
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif_drv.h | 268 ++
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif_drv_m9xx.c | 687 +++++
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif_reg.h | 387 +++
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif_reg_m9xx.h | 37 +
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif_ring.c | 168 ++
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif_ring.h | 161 ++
> > drivers/net/wwan/t9xx/pcie/mtk_pci.c | 1067 ++++++++
> > drivers/net/wwan/t9xx/pcie/mtk_pci.h | 219 ++
> > drivers/net/wwan/t9xx/pcie/mtk_pci_drv_m9xx.c | 70 +
> > drivers/net/wwan/t9xx/pcie/mtk_pci_reg.h | 72 +
> > drivers/net/wwan/t9xx/pcie/mtk_trans_ctrl.c | 593 +++++
> > drivers/net/wwan/t9xx/pcie/mtk_trans_ctrl.h | 105 +
> > 43 files changed, 14761 insertions(+)
> > ---
> > base-commit: eb3f4b7426cfd2b79d65b7d37155480b32259a11
> > change-id: 20260529-t9xx_driver_v1-1744f8af7739
> >
> > Best regards,
> > --
> > Jack Wu <jackbb_wu@compal.com>
================================================================================================================================================================
This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
================================================================================================================================================================
^ permalink raw reply
* [PATCH net 2/2] net: ethernet: mtk_eth_soc: Fix use-after-free in metadata dst teardown
From: Lorenzo Bianconi @ 2026-06-02 9:21 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Felix Fietkau, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Florian Westphal, linux-arm-kernel, linux-mediatek, netdev,
Lorenzo Bianconi
In-Reply-To: <20260602-airoha-mtk-metadata-uaf-fix-v1-0-3aaa99d83351@kernel.org>
mtk_free_dev() calls metadata_dst_free() which frees the metadata_dst
with kfree() immediately, bypassing the RCU grace period.
In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from
the skb to the metadata_dst. This function requires RCU read-side
protection and the dst must remain valid until all RCU readers complete.
Since metadata_dst_free() calls kfree() directly, a use-after-free can
occur if any skb still holds a noref pointer to the dst when the driver
tears it down.
Replace metadata_dst_free() with dst_release() which properly goes
through the refcount path: when the refcount drops to zero, it schedules
the actual free via call_rcu_hurry(), ensuring all RCU readers have
completed before the memory is freed.
Fixes: 2d7605a72906 ("net: ethernet: mtk_eth_soc: enable hardware DSA untagging")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8d225bc9f063..7d771168b990 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -4491,7 +4491,7 @@ static int mtk_free_dev(struct mtk_eth *eth)
for (i = 0; i < ARRAY_SIZE(eth->dsa_meta); i++) {
if (!eth->dsa_meta[i])
break;
- metadata_dst_free(eth->dsa_meta[i]);
+ dst_release(ð->dsa_meta[i]->dst);
}
return 0;
--
2.54.0
^ permalink raw reply related
* [PATCH net 1/2] net: airoha: Fix use-after-free in metadata dst teardown
From: Lorenzo Bianconi @ 2026-06-02 9:21 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Felix Fietkau, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Florian Westphal, linux-arm-kernel, linux-mediatek, netdev,
Lorenzo Bianconi
In-Reply-To: <20260602-airoha-mtk-metadata-uaf-fix-v1-0-3aaa99d83351@kernel.org>
airoha_metadata_dst_free() runs metadata_dst_free() which frees the
metadata_dst with kfree() immediately, bypassing the RCU grace period.
In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from
the skb to the metadata_dst. This function requires RCU read-side
protection and the dst must remain valid until all RCU readers complete.
Since metadata_dst_free() calls kfree() directly, an use-after-free can
occur if any skb still holds a noref pointer to the dst when the driver
tears it down.
Replace metadata_dst_free() with dst_release() which properly goes
through the refcount path: when the refcount drops to zero, it schedules
the actual free via call_rcu_hurry(), ensuring all RCU readers have
completed before the memory is freed.
Fixes: af3cf757d5c9 ("net: airoha: Move DSA tag in DMA descriptor")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index cecd66251dba..eab6a98d62b9 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2936,7 +2936,7 @@ static void airoha_metadata_dst_free(struct airoha_gdm_port *port)
if (!port->dsa_meta[i])
continue;
- metadata_dst_free(port->dsa_meta[i]);
+ dst_release(&port->dsa_meta[i]->dst);
}
}
--
2.54.0
^ permalink raw reply related
* [PATCH net 0/2] Fix use-after-free in metadata dst teardown in airoha_eth and mtk_eth_soc drivers
From: Lorenzo Bianconi @ 2026-06-02 9:21 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Felix Fietkau, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Florian Westphal, linux-arm-kernel, linux-mediatek, netdev,
Lorenzo Bianconi
airoha_metadata_dst_free() and mtk_free_dev() call metadata_dst_free()
which frees the metadata_dst with kfree() immediately, bypassing the RCU
grace period.
Replace metadata_dst_free() with dst_release() which properly goes
through the refcount path and runs call_rcu_hurry() if refcount goes to
zero.
---
Lorenzo Bianconi (2):
net: airoha: Fix use-after-free in metadata dst teardown
net: ethernet: mtk_eth_soc: Fix use-after-free in metadata dst teardown
drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
---
base-commit: 3522b21fd7e1863d0734537737bd59f1b90d0190
change-id: 20260602-airoha-mtk-metadata-uaf-fix-eb03badb1a94
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: PCI: mediatek-gen3: Allow memory-region for restricted DMA buffer
From: Chen-Yu Tsai @ 2026-06-02 7:02 UTC (permalink / raw)
To: Rob Herring
Cc: Manivannan Sadhasivam, Matthias Brugger,
AngeloGioacchino Del Regno, Ryder Lee, Lorenzo Pieralisi,
Krzysztof Wilczyński, Bjorn Helgaas, Krzysztof Kozlowski,
Conor Dooley, devicetree, linux-pci, linux-mediatek, linux-kernel
In-Reply-To: <20260601214836.GA37779-robh@kernel.org>
On Tue, Jun 2, 2026 at 5:48 AM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, May 19, 2026 at 12:51:49PM +0530, Manivannan Sadhasivam wrote:
> > On Mon, May 18, 2026 at 05:02:11PM +0800, Chen-Yu Tsai wrote:
> > > On Fri, May 15, 2026 at 8:34 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > >
> > > > On Fri, May 15, 2026 at 05:16:19PM +0800, Chen-Yu Tsai wrote:
> > > > > On Thu, May 14, 2026 at 7:48 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > >
> > > > > > On Thu, May 14, 2026 at 03:54:29PM +0800, Chen-Yu Tsai wrote:
> > > > > > > On Thu, May 14, 2026 at 1:23 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > > > >
> > > > > > > > On Fri, May 08, 2026 at 02:36:32PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > > On some SoCs without an IOMMU behind the PCIe controller, the PCIe
> > > > > > > > > controller memory access could be limited to a small region by the
> > > > > > > > > firmware configuring a memory protection unit. This memory region
> > > > > > > > > must be assigned to the PCIe controller so that the OS knows to
> > > > > > > > > use that region. Otherwise PCIe devices would not work properly.
> > > > > > > > >
> > > > > > > >
> > > > > > > > So this means, the PCIe devices can only access a specific carveout memory
> > > > > > > > configured by MPU for DMA? If so, you should use 'dma-ranges' as suggested by
> > > > > > > > Rob.
> > > > > > > >
> > > > > > > > 'memory-region' also serves the purpose, but for PCI, we have the dedicated
> > > > > > > > 'dma-ranges' property.
> > > > > > >
> > > > > > > I think I need some sort of guide on writing the 'dma-ranges' property,
> > > > > > > because it is not working for me.
> > > > > > >
> > > > > > > I'm adding
> > > > > > >
> > > > > > > dma-ranges = <0x42000000 0 0x00000000 0 0xc0000000 0 0x4000000>;
> > > > > > >
> > > > > >
> > > > > > So the device DMA address start from 0x0? Isn't it a 1:1 mapping?
> > > > >
> > > > > I actually don't know. But
> > > > >
> > > > > > dma-ranges = <0x42000000 0 0xc0000000 0 0xc0000000 0 0x4000000>;
> > > > >
> > > > > this didn't work either.
> > > >
> > > >
> > > > Hmm. Can you print the DMA address programmed to the device? i.e., the address
> > > > returned by dma_map_single() in the driver.
> > >
> > > On a working system still using the restricted-dma-pool memory region,
> > > it gives something like 0x00000000c0009000, so indeed it is 1:1 mapping?
> >
> > It has to be 1:1 mapping.
> >
> > > These are for the RX/TX descriptors [1][2].
> > >
> > > When using dma-ranges, the failure is from dma_alloc_coherent() [3][4],
> > > which is the descriptor ring. On a working system, this is something
> > > like 0x00000000c0c9d000, so again 1:1.
> > >
> > > [1] https://elixir.bootlin.com/linux/v7.0.8/source/drivers/net/wireless/realtek/rtw88/pci.c#L221
> > > [2] https://elixir.bootlin.com/linux/v7.0.8/source/drivers/net/wireless/realtek/rtw88/pci.c#L829
> > > [3] https://elixir.bootlin.com/linux/v7.0.8/source/drivers/net/wireless/realtek/rtw88/pci.c#L192
> > > [4] https://elixir.bootlin.com/linux/v7.0.8/source/drivers/net/wireless/realtek/rtw88/pci.c#L265
> > >
> > > > Also, using prefetchable flag is not correct for DMA memory. You should use:
> > > >
> > > > dma-ranges = <0x02000000 0 0xc0000000 0 0xc0000000 0 0x4000000>;
> > >
> > > This didn't work either. What exactly is supposed to handle dma-ranges?
> > > I see some code parsing it in the PCI core, but it just saves it to a list.
> > >
> >
> > I think the failure is due to marking the memory as 'reserved' in DT. With
> > 'dma-ranges', the allocator will only ensure that the allocated memory stays
> > within this limit. But the allocator itself will not use this property to
> > allocate from the reserved region.
>
> So the region should not be reserved. Reserved generally means the OS
> shouldn't use the region (though maybe a specific driver/device can). It
> should just be a CMA area I think.
No. The whole reason for this is that we want an isolated piece of memory
for PCIe so that PCIe transfers cannot corrupt memory used by other parts
of the system. Normally the IOMMU provides the isolation. On this platform
there is no IOMMU for the PCIe controller.
System memory isolation as setup by the firmware already restricts the
PCIe controller to only be able to use this region. And we absolutely do
not want any other part of the system, be it kernel, DMA buffers, or
userspace, to use it.
And also, if it is not reserved, the kernel is free to put "other" reserved
regions, such as the default CMA region or the software IO TLB region in
this piece of memory.
So I believe using memory-region is the way to go. The memory needs to be
reserved, and assigned to just the PCIe controller.
Thanks
ChenYu
^ permalink raw reply
* Re: Possible UaF bug in netdevice teardown path
From: Lorenzo Bianconi @ 2026-06-02 6:52 UTC (permalink / raw)
To: Florian Westphal
Cc: Tony Nguyen, Przemek Kitszel, Felix Fietkau, Saeed Mahameed,
Leon Romanovsky, Tariq Toukan, Mark Bloch, netdev, linux-mediatek,
intel-wired-lan
In-Reply-To: <ah1NJMrJ5rEkQlJG@strlen.de>
[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]
On Jun 01, Florian Westphal wrote:
> Another sashiko drive-by report. TL;DR, do you need to apply this
> pattern in your driver?
>
> - metadata_dst_free(priv->md);
> + dst_release(&priv->md->dst);
>
> Affects:
> drivers/net/ethernet/airoha/airoha_eth.c
> drivers/net/ethernet/intel/ice/ice_eswitch.c
> drivers/net/ethernet/mediatek/mtk_eth_soc.c
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c
>
> Long version:
> https://sashiko.dev/#/patchset/20260527135751.1031891-1-tristmd%40gmail.com
>
> This isn't a bug introduced by this patch, but looking at this fix, do
> other callers of metadata_dst_free() suffer from the same use-after-free
> vulnerability?
> In drivers like ice_eswitch and mlx5 MACsec, a metadata_dst is allocated
> and references are taken on it via dst_hold() when packets are processed
> (for example, via skb_dst_set()).
> However, on their teardown paths, these drivers call metadata_dst_free(),
> which unconditionally frees the memory without checking the reference count.
> If packets holding these references are queued (like in a netem qdisc)
> during teardown, does the memory get freed prematurely, causing a
> use-after-free when the networking stack eventually calls dst_release()
> on the dequeued packets?
Hi Florian,
For airoha_eth and mtk_eth_soc I think the issue is less severe since we
destroy the metadata after running unregister_netdev() (that executes
synchronize_net()), but I guess it is better to fix the problem. I will post a
fix for them.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] wifi: mt76: mt7996: fix reading zeroed info->control.flags after mt76_tx_status_skb_add()
From: lorenzo @ 2026-06-02 6:43 UTC (permalink / raw)
To: Roy Luo
Cc: Ryder Lee, Shayne Chen (陳軒丞), nbd@nbd.name,
Roy-CH Luo, Chui-hao Chiu (邱垂浩),
AngeloGioacchino Del Regno, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, Sean Wang,
Bo Jiao (焦波), linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAHoxoj+N3AtJgFD8vGP+uDpj6anKMgPBtZGejLDgAz0ZyisSHg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]
On Jun 01, Roy Luo wrote:
> > > I mean the link_id is only corresponds to one specific flags bit of
> > > mac80211_tx_control_flags. But there are other bits that aren't
> > > handled. Wouldn't u32 flags make it more cleaner?
> >
> > Yes, I got your point, but my concern is if we need to sync link_id between
> > mt7996_tx_prepare_skb() and mt7996_mac_write_txwi(). If so, I guess it is
> > much better to pass link_id explicitly to mt7996_mac_write_txwi() since it
> > does not just depended on mac80211_tx_control_flags and I think we should
> > not duplicate the logic in mt7996_mac_write_txwi(). Got my point?
> > If in the future (not required now) we need to pass mac80211_tx_control_flags
> > to mt7996_mac_write_txwi(), we will do it easily.
> >
> > Regards,
> > Lorenzo
> >
> > >
> > > Ryder
> > >
> > >
>
> Lorenzo,
Hi Roy,
>
> I got your point and IIUC the problem being addressed in this patch is that
> the link id assignment has unnecessary duplicated logic across different
> places. However, the commit tile "fix reading zeroed info->control.flags"
> seems a bit misleading to me - this patch does not fully address the problem
> where the info->control.flags is cleared by memset in tx path when its
> value might still be referenced, the field is still zeroed after
> mt76_tx_status_skb_add() and whoever reads it afterward would get
> incorrect value. With this patch, we avoid using the incorrect value for
> link id, but the root cause remains.
This patch is actually fixing both of the issues since now do not have any
leftover access to info->control.flags after running mt76_tx_status_skb_add()
in the mt7996 tx path and it is not required (according to the current mt7996
codebase) to pass the flags cached value to mt7996_mac_write_txwi(). However,
if in the future this will be necessary, I am completely fine with that.
Regards,
Lorenzo
>
> The issue that Ryder tries to address in
> https://lore.kernel.org/all/5ecac6a9b7d29526e8438dea105b58f5487c93aa.1778521232.git.ryder.lee@mediatek.com/
> concerns the overlapping use of info->control and info->status in tx path,
> and it remains valid even with this link id fix applied. We have to be
> cautious when dealing with info->control in mt7996 tx path until the issue
> is fully resolved.
>
> Regards,
> Roy
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] wifi: mt76: transform aspm_conf for pci_disable_link_state
From: Jiajia Liu @ 2026-06-02 5:43 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Jiajia Liu
From: Jiajia Liu <liujiajia@kylinos.cn>
commit b478e162f227 ("PCI/ASPM: Consolidate link state defines") changed
PCIE_LINK_STATE_L0S (1) to (BIT(0) | BIT(1)). PCI_EXP_LNKCTL_ASPM_L0S (1)
and PCI_EXP_LNKCTL_ASPM_L1 (2) are no longer matched with
PCIE_LINK_STATE_L0S (3) and PCIE_LINK_STATE_L1 (4).
On the platform enabling ASPM L0s and L1, mt76_pci_disable_aspm is not able
to disable L1. Fix this by transforming aspm_conf to pcie link state.
Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
---
drivers/net/wireless/mediatek/mt76/pci.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/pci.c b/drivers/net/wireless/mediatek/mt76/pci.c
index 833923ab2483..11fe62aa8113 100644
--- a/drivers/net/wireless/mediatek/mt76/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/pci.c
@@ -30,8 +30,14 @@ void mt76_pci_disable_aspm(struct pci_dev *pdev)
if (IS_ENABLED(CONFIG_PCIEASPM)) {
int err;
+ int state = 0;
- err = pci_disable_link_state(pdev, aspm_conf);
+ if (aspm_conf & PCI_EXP_LNKCTL_ASPM_L0S)
+ state |= PCIE_LINK_STATE_L0S;
+ if (aspm_conf & PCI_EXP_LNKCTL_ASPM_L1)
+ state |= PCIE_LINK_STATE_L1;
+
+ err = pci_disable_link_state(pdev, state);
if (!err)
return;
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 00/11] net: wwan: t9xx: Add MediaTek T9XX WWAN driver
From: Jakub Kicinski @ 2026-06-02 0:34 UTC (permalink / raw)
To: Jack Wu via B4 Relay
Cc: jackbb_wu, Loic Poulain, Sergey Ryazanov, Johannes Berg,
Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, linux-doc
In-Reply-To: <20260529-t9xx_driver_v1-v1-0-bdbfe2c01e57@compal.com>
On Fri, 29 May 2026 18:31:39 +0800 Jack Wu via B4 Relay wrote:
> 43 files changed, 14761 insertions(+)
Please try to cut this down to ~5kLoC for the initial submission.
Whatever the absolute minimum sensible chunk of code is.
Each patch must build cleanly with W=1
^ permalink raw reply
* Re: [PATCH net-next v8 01/10] dt-bindings: net: airoha: Add GDM port ethernet child node
From: Rob Herring (Arm) @ 2026-06-01 23:11 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Eric Dumazet, Benjamin Larsson, Krzysztof Kozlowski, devicetree,
Andrew Lunn, linux-arm-kernel, netdev, linux-mediatek,
Paolo Abeni, Jakub Kicinski, Conor Dooley, David S. Miller,
Christian Marangi
In-Reply-To: <20260519-airoha-eth-multi-serdes-v8-1-6bd70e329df6@kernel.org>
On Tue, 19 May 2026 10:57:44 +0200, Lorenzo Bianconi wrote:
> EN7581 and AN7583 SoCs support connecting multiple external SerDes to GDM3
> or GDM4 ports via a hw arbiter that manages the traffic in a TDM manner.
> As a result multiple net_devices can connect to the same GDM{3,4} port
> and there is a theoretical "1:n" relation between GDM ports and
> net_devices.
> Introduce the ethernet node child of a specific GDM port in order to model
> a given net_device that is connected via the external arbiter to the
> GDM{3,4} port. This new ethernet node is defined by the "airoha,eth-port"
> compatible string. Please note GDM1 and GDM2 does not support the
> connection with the external arbiter and they are represented by an
> ethernet node defined by the "airoha,eth-mac" compatible string.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> .../devicetree/bindings/net/airoha,en7581-eth.yaml | 56 +++++++++++++++++++++-
> 1 file changed, 55 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: PCI: mediatek-gen3: Allow memory-region for restricted DMA buffer
From: Rob Herring @ 2026-06-01 21:48 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Chen-Yu Tsai, Matthias Brugger, AngeloGioacchino Del Regno,
Ryder Lee, Lorenzo Pieralisi, Krzysztof Wilczyński,
Bjorn Helgaas, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-pci, linux-mediatek, linux-kernel
In-Reply-To: <rphuqwucr2r6gsgrkzkpzy7fn4qa7q4afzbwtzae53dtudmush@kxtzdoq426uz>
On Tue, May 19, 2026 at 12:51:49PM +0530, Manivannan Sadhasivam wrote:
> On Mon, May 18, 2026 at 05:02:11PM +0800, Chen-Yu Tsai wrote:
> > On Fri, May 15, 2026 at 8:34 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > >
> > > On Fri, May 15, 2026 at 05:16:19PM +0800, Chen-Yu Tsai wrote:
> > > > On Thu, May 14, 2026 at 7:48 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > >
> > > > > On Thu, May 14, 2026 at 03:54:29PM +0800, Chen-Yu Tsai wrote:
> > > > > > On Thu, May 14, 2026 at 1:23 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > > >
> > > > > > > On Fri, May 08, 2026 at 02:36:32PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > On some SoCs without an IOMMU behind the PCIe controller, the PCIe
> > > > > > > > controller memory access could be limited to a small region by the
> > > > > > > > firmware configuring a memory protection unit. This memory region
> > > > > > > > must be assigned to the PCIe controller so that the OS knows to
> > > > > > > > use that region. Otherwise PCIe devices would not work properly.
> > > > > > > >
> > > > > > >
> > > > > > > So this means, the PCIe devices can only access a specific carveout memory
> > > > > > > configured by MPU for DMA? If so, you should use 'dma-ranges' as suggested by
> > > > > > > Rob.
> > > > > > >
> > > > > > > 'memory-region' also serves the purpose, but for PCI, we have the dedicated
> > > > > > > 'dma-ranges' property.
> > > > > >
> > > > > > I think I need some sort of guide on writing the 'dma-ranges' property,
> > > > > > because it is not working for me.
> > > > > >
> > > > > > I'm adding
> > > > > >
> > > > > > dma-ranges = <0x42000000 0 0x00000000 0 0xc0000000 0 0x4000000>;
> > > > > >
> > > > >
> > > > > So the device DMA address start from 0x0? Isn't it a 1:1 mapping?
> > > >
> > > > I actually don't know. But
> > > >
> > > > > dma-ranges = <0x42000000 0 0xc0000000 0 0xc0000000 0 0x4000000>;
> > > >
> > > > this didn't work either.
> > >
> > >
> > > Hmm. Can you print the DMA address programmed to the device? i.e., the address
> > > returned by dma_map_single() in the driver.
> >
> > On a working system still using the restricted-dma-pool memory region,
> > it gives something like 0x00000000c0009000, so indeed it is 1:1 mapping?
>
> It has to be 1:1 mapping.
>
> > These are for the RX/TX descriptors [1][2].
> >
> > When using dma-ranges, the failure is from dma_alloc_coherent() [3][4],
> > which is the descriptor ring. On a working system, this is something
> > like 0x00000000c0c9d000, so again 1:1.
> >
> > [1] https://elixir.bootlin.com/linux/v7.0.8/source/drivers/net/wireless/realtek/rtw88/pci.c#L221
> > [2] https://elixir.bootlin.com/linux/v7.0.8/source/drivers/net/wireless/realtek/rtw88/pci.c#L829
> > [3] https://elixir.bootlin.com/linux/v7.0.8/source/drivers/net/wireless/realtek/rtw88/pci.c#L192
> > [4] https://elixir.bootlin.com/linux/v7.0.8/source/drivers/net/wireless/realtek/rtw88/pci.c#L265
> >
> > > Also, using prefetchable flag is not correct for DMA memory. You should use:
> > >
> > > dma-ranges = <0x02000000 0 0xc0000000 0 0xc0000000 0 0x4000000>;
> >
> > This didn't work either. What exactly is supposed to handle dma-ranges?
> > I see some code parsing it in the PCI core, but it just saves it to a list.
> >
>
> I think the failure is due to marking the memory as 'reserved' in DT. With
> 'dma-ranges', the allocator will only ensure that the allocated memory stays
> within this limit. But the allocator itself will not use this property to
> allocate from the reserved region.
So the region should not be reserved. Reserved generally means the OS
shouldn't use the region (though maybe a specific driver/device can). It
should just be a CMA area I think.
Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: pinctrl: mediatek: mt6795: document the slew-rate property
From: Luca Leonardo Scorcia @ 2026-06-01 19:26 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-mediatek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Sean Wang,
linux-gpio, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <CAD++jL=oF_43jwV830p42yOke_tZb-MKomp9fVoQ5EtnQHGzNA@mail.gmail.com>
Hi!
> Do you know that value for the SoC to you can express it like
> this and translate it in the driver?
Unfortunately the data sheet I have doesn't say anything more - just
"Normal slew" or "Slower slew", and I don't have a scope to measure
it. All I know is that it flips a single bit in a configuration
register.
I found this missing property while working on the Xiaomi Mi Smart
Clock x04g (mt8167). I ported the current pinctrl driver for
mt8516/mt8167 to the paris platform driver (adding support for slew
rate and r1r0 pullups in the process) but the stock device tree sets a
slower slew rate for the speaker amp. Without this patch it would
trigger a dts error.
Thanks!
--
Luca
^ permalink raw reply
* Re: [PATCH v2 3/4] regulator: Add driver for MediaTek MT6328 PMIC regulators
From: Mark Brown @ 2026-06-01 18:41 UTC (permalink / raw)
To: y.oudjana
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Flora Fu, Alexandre Mergnat,
Liam Girdwood, Dmitry Torokhov, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-input
In-Reply-To: <20260531-mt6735-pwrap-mt6328-pmic-v2-3-dac37bf92894@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]
On Sun, May 31, 2026 at 11:10:44AM +0200, Yassine Oudjana via B4 Relay wrote:
> @@ -0,0 +1,500 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * MediaTek MT6328 regulator driver
> + * Based on MT6323 driver.
> + *
> + * Copyright (c) 2016 MediaTek Inc.
> + * Copyright (c) 2022 Yassine Oudjana <y.oudjana@protonmail.com>
> + */
Please make the entire comment a C++ one so things look more
intentional.
> +static const unsigned int ldo_volt_table3[] = {
> + 0, 0, 0, 1800000, 1900000, 2000000, 2100000, 2200000
> +};
Use linear_min_sel for the first three values.
> +static const struct linear_range ldo_volt_range1[] = {
> + REGULATOR_LINEAR_RANGE(700000, 0, 0x7f, 6250)
> +};
If there's just one range there's no need for a lookup table, use
regulator_map_voltage_linar().
> +static int mt6328_get_status(struct regulator_dev *rdev)
> +{
> + int ret;
> + u32 regval;
> + struct mt6328_regulator_info *info = rdev_get_drvdata(rdev);
> +
> + ret = regmap_read(rdev->regmap, info->desc.enable_reg, ®val);
> + if (ret != 0) {
> + dev_err(&rdev->dev, "Failed to get enable reg: %d\n", ret);
> + return ret;
> + }
> +
> + return (regval & info->qi) ? REGULATOR_STATUS_ON : REGULATOR_STATUS_OFF;
> +}
get_status() should report the actual status of the regulator, not what
was configured. If the device can't report this just omit the
operation.
> + if (mt6328_regulators[i].vselctrl_reg) {
> + if (regmap_read(mt6328->regmap,
> + mt6328_regulators[i].vselctrl_reg,
> + ®val) < 0) {
> + dev_err(&pdev->dev,
> + "Failed to read buck ctrl\n");
> + return -EIO;
Better to return the actual error.
> + rdev = devm_regulator_register(&pdev->dev,
> + &mt6328_regulators[i].desc, &config);
> + if (IS_ERR(rdev)) {
> + dev_err(&pdev->dev, "failed to register %s\n",
> + mt6328_regulators[i].desc.name);
> + return PTR_ERR(rdev);
dev_err_probe().
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net v3 2/2] af_unix: Add test for SCM_INQ on partial read
From: Kuniyuki Iwashima @ 2026-06-01 18:35 UTC (permalink / raw)
To: jianyu.li
Cc: davem, edumazet, kuba, pabeni, horms, willemb, netdev,
linux-kernel, linux-mediatek, black-ch.chen, ivan.tseng
In-Reply-To: <20260601113640.231897-3-jianyu.li@mediatek.com>
On Mon, Jun 1, 2026 at 4:37 AM <jianyu.li@mediatek.com> wrote:
>
> From: Jianyu Li <jianyu.li@mediatek.com>
>
> Add test to verify that when a skb is partially consumed,
> unix_inq_len() return correct remaining byte count.
>
> Before:
>
> # RUN scm_inq.stream.partial_read ...
> # scm_inq.c:165:partial_read:Expected remain (512) == *(int *)CMSG_DATA(cmsg) (768)
> # partial_read: Test terminated by assertion
> # FAIL scm_inq.stream.partial_read
> not ok 2 scm_inq.stream.partial_read
>
> After:
>
> # RUN scm_inq.stream.partial_read ...
> # OK scm_inq.stream.partial_read
> ok 2 scm_inq.stream.partial_read
>
> Signed-off-by: Jianyu Li <jianyu.li@mediatek.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
^ permalink raw reply
* Re: [PATCH net v3 1/2] af_unix: Fix inq_len update problem in partial read
From: Kuniyuki Iwashima @ 2026-06-01 18:34 UTC (permalink / raw)
To: jianyu.li
Cc: davem, edumazet, kuba, pabeni, horms, willemb, netdev,
linux-kernel, linux-mediatek, black-ch.chen, ivan.tseng
In-Reply-To: <20260601113640.231897-2-jianyu.li@mediatek.com>
On Mon, Jun 1, 2026 at 4:37 AM <jianyu.li@mediatek.com> wrote:
>
> From: Jianyu Li <jianyu.li@mediatek.com>
>
> Currently inq_len is updated only when the whole skb is consumed.
> If only part of the data is read, following SIOCINQ query would
> get value greater than what actually left.
>
> This change update inq_len timely in unix_stream_read_generic(),
> and adjust unix_stream_read_skb() accordingly to prevent
> repetitive update.
>
> Fixes: f4e1fb04c123 ("af_unix: Use cached value for SOCK_STREAM in unix_inq_len().")
> Signed-off-by: Jianyu Li <jianyu.li@mediatek.com>
> ---
> v2: Improve lock usage in unix_stream_read_generic()
For future submissions, since this patch has no change
since v2, you could carry my tag from v2.
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Thanks !
^ 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