* Re: [PATCH 1/2] dt-bindings: pwm: add Axiado AX3000 PWM
From: Petar Stepanovic @ 2026-06-23 8:17 UTC (permalink / raw)
To: Krzysztof Kozlowski, Akhila Kavi, Prasad Bolisetty,
Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah
Cc: linux-pwm, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <c4f3875c-4f39-44bf-857f-10c50a2ca6f4@kernel.org>
On 6/22/2026 2:50 PM, Krzysztof Kozlowski wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On 18/06/2026 14:26, Petar Stepanovic wrote:
>> +
>> +description:
>> + The Axiado PWM controller found on AX3000 and AX3005 SoCs.
>> +
>> +allOf:
>> + - $ref: pwm.yaml#
>> +
>> +properties:
>> + compatible:
>> + const: axiado,ax3000-pwm
> Description mentions AX3005, but there is no ax3005 compatible here.
> This is confusing.
Thank you for the review.
I will address all your comments in the next version.
Regards,
Petar
^ permalink raw reply
* [PATCH v4 3/4] mfd: mt6397-core: add mt6323 AUXADC support
From: Roman Vivchar via B4 Relay @ 2026-06-23 8:16 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: <20260623-mt6323-adc-v4-0-299680ad3194@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 v4 0/4] AUXADC driver for the MediaTek mt6323 PMIC
From: Roman Vivchar via B4 Relay @ 2026-06-23 8:16 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, Conor Dooley,
Andy Shevchenko
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.
[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 in v4:
- dt-bindings: Drop separate driver mention from the commit message (Conor)
- AUXADC driver: Break one more time 'regmap_read_poll_timeout' on logical boundaries (Andy)
- Link to v3: https://patch.msgid.link/20260616-mt6323-adc-v3-0-1c27c588185d@protonmail.com
Changes in v3:
- AUXADC driver:
- Add comment for channels table about voltage and channel IDs (Jonathan)
- Add comment for mutex in the 'mt6323_auxadc' struct (Jonathan)
- Break 'regmap_read_poll_timeout' on logical boundaries (Andy)
- Switch to 'guard' from 'scoped_guard' (Andy)
- Link to v2: https://patch.msgid.link/20260609-mt6323-adc-v2-0-aa93a22309f9@protonmail.com
Changes in v2:
- AUXADC driver:
- Drop channel type from the MTK_PMIC_IIO_CHAN macro (Nuno)
- Drop kerneldoc for the mt6323_auxadc struct (Nuno)
- Add channel release to save power (Sashiko, Jonathan)
- Drop 'reg' variable in the mt6323_auxadc_read (Jonathan)
- Sort variables in the mt6323_auxadc_probe (Jonathan)
- Maintainers:
- Drop linux-mediatek list (Andy)
- Split between dt-bindings and driver to avoid missing file (Nuno)
- Link to v1: https://patch.msgid.link/20260602-mt6323-adc-v1-0-68ec737508ee@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 | 7 +
arch/arm/boot/dts/mediatek/mt6323.dtsi | 5 +
drivers/iio/adc/Kconfig | 11 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/mt6323-auxadc.c | 314 +++++++++++++++++++++
drivers/mfd/mt6397-core.c | 3 +
.../dt-bindings/iio/adc/mediatek,mt6323-auxadc.h | 24 ++
8 files changed, 367 insertions(+), 1 deletion(-)
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260525-mt6323-adc-3befce36cbf2
Best regards,
--
Roman Vivchar <rva333@protonmail.com>
^ permalink raw reply
* [PATCH v4 1/4] dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADC
From: Roman Vivchar via B4 Relay @ 2026-06-23 8:16 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, Conor Dooley
In-Reply-To: <20260623-mt6323-adc-v4-0-299680ad3194@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The MediaTek mt6323 PMIC includes an AUXADC used for battery voltage,
temperature, and other internal measurements. The IP block is not
register-compatible with mt6359.
Add the devicetree binding documentation and the associated header file
defining the ADC channel constants.
Also change the description to 'MT6350 series and similar' because
the binding already includes more than mt635x series PMICs.
Finally, add the MAINTAINERS entry for the header with ADC constants.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
.../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 3 ++-
MAINTAINERS | 6 ++++++
.../dt-bindings/iio/adc/mediatek,mt6323-auxadc.h | 24 ++++++++++++++++++++++
3 files changed, 32 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/MAINTAINERS b/MAINTAINERS
index d1cc0e12fe1f..2551c8cd9e9d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16256,6 +16256,12 @@ 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
+S: Maintained
+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/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 v4 4/4] ARM: dts: mediatek: mt6323: add AUXADC support
From: Roman Vivchar via B4 Relay @ 2026-06-23 8:16 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: <20260623-mt6323-adc-v4-0-299680ad3194@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
* [PATCH v4 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: Roman Vivchar via B4 Relay @ 2026-06-23 8:16 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, Andy Shevchenko
In-Reply-To: <20260623-mt6323-adc-v4-0-299680ad3194@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>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
---
MAINTAINERS | 1 +
drivers/iio/adc/Kconfig | 11 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/mt6323-auxadc.c | 314 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 327 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2551c8cd9e9d..fb40128451dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16260,6 +16260,7 @@ MEDIATEK MT6323 PMIC AUXADC DRIVER
M: Roman Vivchar <rva333@protonmail.com>
L: linux-iio@vger.kernel.org
S: Maintained
+F: drivers/iio/adc/mt6323-auxadc.c
F: include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
MEDIATEK MT6735 CLOCK & RESET DRIVERS
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..c450fb6f09cb
--- /dev/null
+++ b/drivers/iio/adc/mt6323-auxadc.c
@@ -0,0 +1,314 @@
+// 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 MTK_PMIC_IIO_CHAN(_name, _chan, _addr) \
+{ \
+ .type = IIO_VOLTAGE, \
+ .indexed = 1, \
+ .channel = _chan, \
+ .address = _addr, \
+ .datasheet_name = __stringify(_name), \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_SCALE), \
+}
+
+/*
+ * AUXADC reports everything in mV, including temperature and
+ * current channels. Channel macros are mapped such that their
+ * ID matches their respective hardware bit position in CON22.
+ */
+static const struct iio_chan_spec mt6323_auxadc_channels[] = {
+ MTK_PMIC_IIO_CHAN(baton2, MT6323_AUXADC_BATON2, MT6323_AUXADC_ADC6),
+ MTK_PMIC_IIO_CHAN(ch6, MT6323_AUXADC_CH6, MT6323_AUXADC_ADC11),
+ MTK_PMIC_IIO_CHAN(bat_temp, MT6323_AUXADC_BAT_TEMP, MT6323_AUXADC_ADC5),
+ MTK_PMIC_IIO_CHAN(chip_temp, MT6323_AUXADC_CHIP_TEMP, MT6323_AUXADC_ADC4),
+ MTK_PMIC_IIO_CHAN(vcdt, MT6323_AUXADC_VCDT, MT6323_AUXADC_ADC2),
+ MTK_PMIC_IIO_CHAN(baton1, MT6323_AUXADC_BATON1, MT6323_AUXADC_ADC3),
+ MTK_PMIC_IIO_CHAN(isense, MT6323_AUXADC_ISENSE, MT6323_AUXADC_ADC1),
+ MTK_PMIC_IIO_CHAN(batsns, MT6323_AUXADC_BATSNS, MT6323_AUXADC_ADC0),
+ MTK_PMIC_IIO_CHAN(accdet, MT6323_AUXADC_ACCDET, MT6323_AUXADC_ADC7),
+};
+
+/*
+ * 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;
+ /* AUXADC doesn't support reading multiple channels simultaneously. */
+ 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;
+
+ return regmap_set_bits(map, MT6323_AUXADC_CON22, BIT(channel));
+}
+
+static int mt6323_auxadc_release(struct mt6323_auxadc *auxadc,
+ unsigned long channel)
+{
+ struct regmap *map = auxadc->regmap;
+ int ret;
+
+ ret = regmap_clear_bits(map, MT6323_AUXADC_CON22, BIT(channel));
+ if (ret)
+ return ret;
+
+ return regmap_clear_bits(map, MT6323_AUXADC_CON11, AUXADC_CON11_VBUF_EN);
+}
+
+static int mt6323_auxadc_read(struct mt6323_auxadc *auxadc,
+ const struct iio_chan_spec *chan, int *out)
+{
+ struct regmap *map = auxadc->regmap;
+ u32 val;
+ int ret;
+
+ ret = regmap_read_poll_timeout(map, chan->address,
+ 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: {
+ 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 (mt6323_auxadc_release(auxadc, chan->channel))
+ dev_err(&indio_dev->dev,
+ "failed to release channel %d\n", chan->channel);
+
+ 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 regmap *regmap;
+ struct iio_dev *iio;
+ 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
* [RFC PATCH] KVM: arm64: Set irqfd->producer to enable vLPI routing updates
From: leixiang @ 2026-06-23 8:14 UTC (permalink / raw)
To: maz
Cc: oupton, seanjc, pbonzini, kvmarm, kvm, linux-arm-kernel,
linux-kernel, leixiang
In-Reply-To: <20260622075103.35164-1-leixiang@kylinos.cn>
ARM64's kvm_arch_irq_bypass_add_producer() never sets irqfd->producer,
so kvm_irq_routing_update() never calls the ARM64 routing hook. That
hook unmaps the vLPI and falls back to software injection when an
irqfd's MSI routing changes; with it dead, the vLPI stays bound to the
old translation.
Set irqfd->producer once kvm_vgic_v4_set_forwarding() succeeds and
clear it in del_producer(), under irqfds.lock; the only reader,
kvm_irq_routing_update(), takes that lock. set_forwarding() may sleep,
so it runs outside the lock and the pointer is published only on
success, needing no error cleanup.
Sent as RFC: the unmap-on-reroute path has been dormant.
Fixes: 2412405b3141 ("KVM: arm/arm64: register irq bypass consumer on ARM/ARM64")
Signed-off-by: leixiang <leixiang@kylinos.cn>
---
A review of the x86/powerpc producer-nullify patch pointed out that
ARM64 never sets irqfd->producer, so kvm_arch_update_irqfd_routing()
is dead. This RFC fills that gap; set_forwarding() may sleep and so
can't run under irqfds.lock like the x86 path, hence the locking is
what I'd most like reviewed.
arch/arm64/kvm/arm.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 50adfff75be8..6f1e4f526719 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -2935,6 +2935,7 @@ int kvm_arch_irq_bypass_add_producer(struct irq_bypass_consumer *cons,
struct kvm_kernel_irqfd *irqfd =
container_of(cons, struct kvm_kernel_irqfd, consumer);
struct kvm_kernel_irq_routing_entry *irq_entry = &irqfd->irq_entry;
+ int ret;
/*
* The only thing we have a chance of directly-injecting is LPIs. Maybe
@@ -2943,8 +2944,16 @@ int kvm_arch_irq_bypass_add_producer(struct irq_bypass_consumer *cons,
if (irq_entry->type != KVM_IRQ_ROUTING_MSI)
return 0;
- return kvm_vgic_v4_set_forwarding(irqfd->kvm, prod->irq,
- &irqfd->irq_entry);
+ ret = kvm_vgic_v4_set_forwarding(irqfd->kvm, prod->irq,
+ &irqfd->irq_entry);
+ if (ret)
+ return ret;
+
+ spin_lock_irq(&irqfd->kvm->irqfds.lock);
+ irqfd->producer = prod;
+ spin_unlock_irq(&irqfd->kvm->irqfds.lock);
+
+ return 0;
}
void kvm_arch_irq_bypass_del_producer(struct irq_bypass_consumer *cons,
@@ -2957,6 +2966,10 @@ void kvm_arch_irq_bypass_del_producer(struct irq_bypass_consumer *cons,
if (irq_entry->type != KVM_IRQ_ROUTING_MSI)
return;
+ spin_lock_irq(&irqfd->kvm->irqfds.lock);
+ irqfd->producer = NULL;
+ spin_unlock_irq(&irqfd->kvm->irqfds.lock);
+
kvm_vgic_v4_unset_forwarding(irqfd->kvm, prod->irq);
}
--
2.45.0
^ permalink raw reply related
* Re: [PATCH 1/2] pinctrl: mediatek: Restore PINCTRL_MT8189 to tristate
From: AngeloGioacchino Del Regno @ 2026-06-23 8:06 UTC (permalink / raw)
To: Justin Yeh, Sean Wang, Linus Walleij, Matthias Brugger
Cc: Project_Global_Chrome_Upstream_Group, linux-mediatek, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260529100308.51271-2-justin.yeh@mediatek.com>
On 5/29/26 12:02, Justin Yeh wrote:
> Under the GKI + vendor_dlkm model, vendor-specific pinctrl cannot be
> built into the GKI vmlinux. Upstream's recent switch of PINCTRL_MT8189
> to bool prevents building as a loadable module, which breaks DDK module
> usage. Restore tristate so MT8189 pinctrl can be packaged as a kernel
> module in vendor_dlkm.
>
> Signed-off-by: Justin Yeh <justin.yeh@mediatek.com>
The MODULE_LICENSE change shall come before this one.
Besides - since there's no problem in having the pinctrl drivers as module for
MT8189, I imagine that this is analogously true for all (or most of) the others.
Looks like getting those to build as modules is trivial, too - so, can you at
this point please do the same for all of the MediaTek pinctrl drivers that are
trivial to enable as tristate?
P.S.: After reordering the commits, this one is
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Thanks,
Angelo
> ---
> drivers/pinctrl/mediatek/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
> index 4819617d9368..a75434e7e989 100644
> --- a/drivers/pinctrl/mediatek/Kconfig
> +++ b/drivers/pinctrl/mediatek/Kconfig
> @@ -270,7 +270,7 @@ config PINCTRL_MT8188
> map specific eint which doesn't have real gpio pin.
>
> config PINCTRL_MT8189
> - bool "MediaTek MT8189 pin control"
> + tristate "MediaTek MT8189 pin control"
> depends on OF
> depends on ARM64 || COMPILE_TEST
> default ARM64 && ARCH_MEDIATEK
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: mediatek: mt8189: Add MODULE_LICENSE declaration
From: AngeloGioacchino Del Regno @ 2026-06-23 8:06 UTC (permalink / raw)
To: Justin Yeh, Sean Wang, Linus Walleij, Matthias Brugger
Cc: Project_Global_Chrome_Upstream_Group, linux-mediatek, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260529100308.51271-3-justin.yeh@mediatek.com>
On 5/29/26 12:02, Justin Yeh wrote:
> Add missing MODULE_LICENSE("GPL v2") macro to fix modpost error during
> kernel module build. The license identifier matches the SPDX header
> (GPL-2.0) at the top of the file.
>
> This fixes the following build error:
> ERROR: modpost: missing MODULE_LICENSE() in pinctrl-mt8189.o
>
> Signed-off-by: Justin Yeh <justin.yeh@mediatek.com>
Please, do this for all MediaTek pinctrl drivers.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH 0/2] pmdomain: mediatek: Enable module support for mtk-scpsys
From: AngeloGioacchino Del Regno @ 2026-06-23 8:06 UTC (permalink / raw)
To: Justin Yeh, Ulf Hansson, Matthias Brugger
Cc: Project_Global_Chrome_Upstream_Group, linux-pm, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260603051200.1163226-1-justin.yeh@mediatek.com>
On 6/3/26 07:11, Justin Yeh wrote:
> This series enables the MTK_SCPSYS driver to be built as a loadable
> module for GKI (Generic Kernel Image) compliance.
>
> This series depends on the following patches currently under review:
> - soc: mediatek: Allow MTK_INFRACFG to be built as module
> - soc: mediatek: mtk-infracfg: Export symbols for DDK modules
>
> The MTK_SCPSYS driver depends on MTK_INFRACFG being available as a
> module, which is enabled by these prerequisite patches.
>
> Patch 1 converts the Kconfig option from bool to tristate, allowing
> the driver to be built as either built-in or as a module.
>
> Patch 2 adds MODULE_DESCRIPTION() and converts to module_platform_driver()
> to complete the modularization and silence modpost warnings.
>
> Together these changes allow the MediaTek SCPSYS power domain driver
> to support modern Android GKI/vendor_dlkm module loading requirements
> while maintaining backward compatibility with the traditional built-in
> configuration.
>
The mtk-scpsys driver should disappear, really.
This is something that was rewritten entirely and is called mtk-pm-domains now.
This driver still contains support for some very old SoCs that were not migrated
to the new mtk-pm-domains driver, but seriously, the strategy here should be to
migrate those and let the mtk-scpsys driver be there just as a legacy one to not
break the ABI for older devicetrees.
Converting this as a module is probably a bad idea, because this one didn't get
any real update for years now, and I'm not sure what is going to break by doing
so - neither I have any way of testing it.
I can say Reviewed-by if you can test booting MT2701, MT2712, MT7622, MT7623A
(all of them, really) on a build that has this driver as module and check that
all functionality is ok... but I guess you may also have difficulties in doing
that (do you even have access to old devices with those SoCs?).
Cheers,
Angelo
> Justin Yeh (2):
> pmdomain: mediatek: Convert MTK_SCPSYS to tristate
> pmdomain: mediatek: Add MODULE_DESCRIPTION to mtk-scpsys
>
> drivers/pmdomain/mediatek/Kconfig | 2 +-
> drivers/pmdomain/mediatek/mtk-scpsys.c | 5 ++++-
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 2/2] soc: mediatek: mtk-infracfg: Export symbols for DDK modules
From: AngeloGioacchino Del Regno @ 2026-06-23 8:06 UTC (permalink / raw)
To: Justin Yeh, Matthias Brugger
Cc: Project_Global_Chrome_Upstream_Group, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260529101613.55697-3-justin.yeh@mediatek.com>
On 5/29/26 12:16, Justin Yeh wrote:
> Export mtk_infracfg functions to allow other DDK modules (like
> mtk-scpsys) to use bus protection APIs.
>
> Changes:
> - Add EXPORT_SYMBOL_GPL for set/clear bus_protection and init functions
> - Remove static and __init qualifiers from mtk_infracfg_init
> - Add mtk_infracfg_init() declaration to header
> - Remove postcore_initcall, let dependent modules call init explicitly
> - Add #include <linux/module.h> for export macros
> - Add MODULE_LICENSE("GPL") metadata
>
> This allows mtk-infracfg to be built as a DDK module (.ko) and its
> functions to be used by other modules like mtk-scpsys for power domain
> management.
>
> Signed-off-by: Justin Yeh <justin.yeh@mediatek.com>
> ---
> drivers/soc/mediatek/mtk-infracfg.c | 9 +++++++--
> include/linux/soc/mediatek/infracfg.h | 1 +
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-infracfg.c b/drivers/soc/mediatek/mtk-infracfg.c
> index 2acf19676af2..8a88805468cc 100644
> --- a/drivers/soc/mediatek/mtk-infracfg.c
> +++ b/drivers/soc/mediatek/mtk-infracfg.c
> @@ -7,6 +7,7 @@
> #include <linux/jiffies.h>
> #include <linux/regmap.h>
> #include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> #include <linux/soc/mediatek/infracfg.h>
> #include <asm/processor.h>
>
> @@ -43,6 +44,7 @@ int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask,
>
> return ret;
> }
> +EXPORT_SYMBOL_GPL(mtk_infracfg_set_bus_protection);
>
> /**
> * mtk_infracfg_clear_bus_protection - disable bus protection
> @@ -73,8 +75,9 @@ int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask,
>
> return ret;
> }
> +EXPORT_SYMBOL_GPL(mtk_infracfg_clear_bus_protection);
Those two are ok, but I'd prefer to use namespaces (EXPORT_SYMBOL_NS_GPL) and to
import the namespace in the relevant drivers.
>
> -static int __init mtk_infracfg_init(void)
> +int mtk_infracfg_init(void)
> {
> struct regmap *infracfg;
>
> @@ -90,4 +93,6 @@ static int __init mtk_infracfg_init(void)
> MT8192_INFRA_CTRL_DISABLE_MFG2ACP);
> return 0;
> }
> -postcore_initcall(mtk_infracfg_init);
> +EXPORT_SYMBOL_GPL(mtk_infracfg_init);
Sorry, but that makes little sense.
Check the mtk_infracfg_init() function: if you avoid the postcore_initcall() there,
what's going to happen with MT8192?! :-)
Cheers,
Angelo
> +
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/soc/mediatek/infracfg.h b/include/linux/soc/mediatek/infracfg.h
> index 9956e18c5ffa..847431a7b967 100644
> --- a/include/linux/soc/mediatek/infracfg.h
> +++ b/include/linux/soc/mediatek/infracfg.h
> @@ -454,4 +454,5 @@ int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask,
> bool reg_update);
> int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask,
> bool reg_update);
> +int mtk_infracfg_init(void);
> #endif /* __SOC_MEDIATEK_INFRACFG_H */
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: David Hildenbrand (Arm) @ 2026-06-23 8:02 UTC (permalink / raw)
To: Hongru Zhang
Cc: akpm, baohua, bhe, chentao, chrisl, jack, kasong, kunwu.chan,
liam, lianux.mm, linux-arm-kernel, linux-kernel, linux-mm,
linux-riscv, linux-s390, linuxppc-dev, liyangouwen1, ljs,
loongarch, mhocko, nphamcs, nzzhao, pfalcato, rppt, shikemeng,
surenb, vbabka, wanglian, willy, youngjun.park
In-Reply-To: <20260623075805.466317-1-zhanghongru@xiaomi.com>
On 6/23/26 09:58, Hongru Zhang wrote:
>> On 5/20/26 23:15, Matthew Wilcox wrote:
>>>
>>> all of the applications i run are either single threaded or don't fork.
>>> what multithreaded applications call fork?
>>
>> Traditionally the problem was random libraries using fork+execve to launch other
>> programs ... instead of using alternatives like posix_spwan (some use cases
>> require more work done before execve and cannot yet switch to that). I'd hope
>> that that is less of a problem on Android.
>>
>> I assume Android zygote might be multi threaded? Maybe sshd as well? Systemd?
>> But I'd be surprised if there are really performance implications.
>>
>> Not sure about webbroswers .... I think most of them switched to fork servers,
>> where I would assume fork servers would be single-threaded.
>>
>> So, yeah, getting a clear understanding how this ends up being a problem on
>> Android would be great.
>
> Barry asked me to share observations on fork() usage across Android
> applications.
>
> I wrote a BPF-based tracing tool (kprobe on copy_process, checking
> CLONE_VM to distinguish process creation from thread creation) and ran
> it against the top 200 Android applications in the China market during
> normal usage scenarios.
>
> Results:
> - 82 out of 200 apps (41%) call fork() during normal operation
Crazy. Thanks for these numbers.
> - Among these, some call fork() from multiple threads
>
> These are not zygote forks — they are fork() calls initiated by app
> threads at runtime. Examples by category:
>
> Browsers: com.quark.browser, com.UCMobile, com.xunlei.browser
> Shopping: com.taobao.taobao, com.tmall.wireless, com.achievo.vipshop
> Video: com.youku.phone, com.qiyi.video, com.hunantv.imgo.activity
> Social/IM: com.alibaba.android.rimet, com.ss.android.lark
> News: com.ss.android.article.news, com.ss.android.article.lite
> Navigation: com.autonavi.minimap, com.sdu.didi.psnger
> Finance: com.eg.android.AlipayGphone, com.chinamworld.main
I know that especially browser usually use fork servers: a tiny
(single-threaded) process just to create new child processes. Any information
regarding the apps above that use fork() on small vs. large processes?
>
> This confirms that fork() is widely used in real-world multi-threaded
> Android applications.
Above you write "some call fork() from multiple threads". Any further
information on that?
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Hongru Zhang @ 2026-06-23 7:58 UTC (permalink / raw)
To: david
Cc: akpm, baohua, bhe, chentao, chrisl, jack, kasong, kunwu.chan,
liam, lianux.mm, linux-arm-kernel, linux-kernel, linux-mm,
linux-riscv, linux-s390, linuxppc-dev, liyangouwen1, ljs,
loongarch, mhocko, nphamcs, nzzhao, pfalcato, rppt, shikemeng,
surenb, vbabka, wanglian, willy, youngjun.park, zhanghongru06
In-Reply-To: <3be9475b-0e8a-4df8-a130-4262f993973d@kernel.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2922 bytes --]
> On 5/20/26 23:15, Matthew Wilcox wrote:
> > On Thu, May 21, 2026 at 05:14:20AM +0800, Barry Song wrote:
> >> My understanding is that we should not blame applications here. This is 2026:
> >> there are basically only two kinds of applications — single-threaded and
> >> multi-threaded — and single-threaded applications are nearly extinct.
> >
> > all of the applications i run are either single threaded or don't fork.
> > what multithreaded applications call fork?
>
> Traditionally the problem was random libraries using fork+execve to launch other
> programs ... instead of using alternatives like posix_spwan (some use cases
> require more work done before execve and cannot yet switch to that). I'd hope
> that that is less of a problem on Android.
>
> I assume Android zygote might be multi threaded? Maybe sshd as well? Systemd?
> But I'd be surprised if there are really performance implications.
>
> Not sure about webbroswers .... I think most of them switched to fork servers,
> where I would assume fork servers would be single-threaded.
>
> So, yeah, getting a clear understanding how this ends up being a problem on
> Android would be great.
Barry asked me to share observations on fork() usage across Android
applications.
I wrote a BPF-based tracing tool (kprobe on copy_process, checking
CLONE_VM to distinguish process creation from thread creation) and ran
it against the top 200 Android applications in the China market during
normal usage scenarios.
Results:
- 82 out of 200 apps (41%) call fork() during normal operation
- Among these, some call fork() from multiple threads
These are not zygote forks — they are fork() calls initiated by app
threads at runtime. Examples by category:
Browsers: com.quark.browser, com.UCMobile, com.xunlei.browser
Shopping: com.taobao.taobao, com.tmall.wireless, com.achievo.vipshop
Video: com.youku.phone, com.qiyi.video, com.hunantv.imgo.activity
Social/IM: com.alibaba.android.rimet, com.ss.android.lark
News: com.ss.android.article.news, com.ss.android.article.lite
Navigation: com.autonavi.minimap, com.sdu.didi.psnger
Finance: com.eg.android.AlipayGphone, com.chinamworld.main
This confirms that fork() is widely used in real-world multi-threaded
Android applications. Since dup_mmap() needs to acquire
vma_start_write() for every VMA, holding the VMA lock across I/O
would risk blocking fork() for unpredictable durations in these 82
applications.
Tracing tool (two equivalent implementations):
bpftrace: https://gist.github.com/zhr250/bf4384202d598bb4cda71cb9902f15ab
libbpf-bootstrap: https://gist.github.com/zhr250/76189bdf51bdc8818500e4c8917c6493
Analysis results (top 200 apps):
https://gist.github.com/zhr250/06f51092c84a49c602a55ac3d186e9ce
Hongru
^ permalink raw reply
* Re: [PATCH] arm64: mm: Defer read-only remap of data/bss linear alias
From: Kevin Brodsky @ 2026-06-23 7:53 UTC (permalink / raw)
To: Ard Biesheuvel, Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, Catalin Marinas, Will Deacon, Fuad Tabba
In-Reply-To: <2d27eaa8-3324-48b3-97b0-aecf63639c18@app.fastmail.com>
On 22/06/2026 18:42, Ard Biesheuvel wrote:
>> It would also be good to explain why we can't do this in
>> mark_linear_text_alias_ro() (presumably because this is too early). I do
>> agree that honouring rodata=off is a good thing, though.
>>
> I didn't consider that tbh - I'll check whether that is a more suitable
> location. But generally, I think doing it later rather than earlier is
> fine because it reduces the likelihood of hidden issues such as the one
> being addressed by this patch, and I don't think doing this very early
> makes a meaningful difference in terms of robustness.
That makes sense, probably not worth the hassle of checking if
mark_linear_text_alias_ro() would work.
>> BTW, if only kvm_arm_init() needs to read the data/bss via the linear
>> map, maybe we can still unmap it later?
>>
> Yes, it is still my intent to bring back the patches that unmap this alias
> entirely, including some additional tweaks for the fixmap PTE level table
> that I dropped after an earlier revision. But that will be 7.3 material,
> whereas this fixes a regression due to the changes that were pulled for 7.2.
Sounds good.
- Kevin
^ permalink raw reply
* [PATCH net v2 0/2] net: stmmac: dwmac-spacemit: Fix wrong macro definition
From: Inochi Amaoto @ 2026-06-23 7:46 UTC (permalink / raw)
To: Inochi Amaoto, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Yixun Lan, Russell King (Oracle)
Cc: netdev, linux-stm32, linux-arm-kernel, linux-riscv, spacemit,
linux-kernel, Yixun Lan, Longbin Li
Fix Wrong macro definition of the Spacemit K3.
Changed from v1:
- https://lore.kernel.org/netdev/20260618064143.1102179-1-inochiama@gmail.com
1. Separate the patch into two patches
2. Use the right macro name for the LPI interrupt.
Inochi Amaoto (2):
net: stmmac: dwmac-spacemit: Fix wrong phy interface definition
net: stmmac: dwmac-spacemit: Fix wrong irq definition
.../net/ethernet/stmicro/stmmac/dwmac-spacemit.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH net v2 1/2] net: stmmac: dwmac-spacemit: Fix wrong phy interface definition
From: Inochi Amaoto @ 2026-06-23 7:46 UTC (permalink / raw)
To: Inochi Amaoto, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Yixun Lan, Russell King (Oracle)
Cc: netdev, linux-stm32, linux-arm-kernel, linux-riscv, spacemit,
linux-kernel, Yixun Lan, Longbin Li
In-Reply-To: <20260623074637.503864-1-inochiama@gmail.com>
The current MII interface register definition from the vendor is wrong,
use the right number for the macro. Also, correct the interface mask
in spacemit_set_phy_intf_sel() so it can update the register with the
right number
Fixes: 30f0ba420ed3 ("net: stmmac: Add glue layer for Spacemit K3 SoC")
Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
index 223754cc5c79..3bfb6d49be6c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
@@ -18,8 +18,10 @@
#include "stmmac_platform.h"
/* ctrl register bits */
-#define CTRL_PHY_INTF_RGMII BIT(3)
-#define CTRL_PHY_INTF_MII BIT(4)
+#define CTRL_PHY_INTF_MODE GENMASK(4, 3)
+#define CTRL_PHY_INTF_RMII FIELD_PREP(CTRL_PHY_INTF_MODE, 0)
+#define CTRL_PHY_INTF_RGMII FIELD_PREP(CTRL_PHY_INTF_MODE, 1)
+#define CTRL_PHY_INTF_MII FIELD_PREP(CTRL_PHY_INTF_MODE, 3)
#define CTRL_WAKE_IRQ_EN BIT(9)
#define CTRL_PHY_IRQ_EN BIT(12)
@@ -118,7 +120,7 @@ static void spacemit_get_interfaces(struct stmmac_priv *priv, void *bsp_priv,
static int spacemit_set_phy_intf_sel(void *bsp_priv, u8 phy_intf_sel)
{
- unsigned int mask = CTRL_PHY_INTF_MII | CTRL_PHY_INTF_RGMII;
+ unsigned int mask = CTRL_PHY_INTF_MODE;
struct spacmit_dwmac *dwmac = bsp_priv;
unsigned int val = 0;
@@ -128,6 +130,7 @@ static int spacemit_set_phy_intf_sel(void *bsp_priv, u8 phy_intf_sel)
break;
case PHY_INTF_SEL_RMII:
+ val = CTRL_PHY_INTF_RMII;
break;
case PHY_INTF_SEL_RGMII:
--
2.54.0
^ permalink raw reply related
* [PATCH net v2 2/2] net: stmmac: dwmac-spacemit: Fix wrong irq definition
From: Inochi Amaoto @ 2026-06-23 7:46 UTC (permalink / raw)
To: Inochi Amaoto, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Yixun Lan, Russell King (Oracle)
Cc: netdev, linux-stm32, linux-arm-kernel, linux-riscv, spacemit,
linux-kernel, Yixun Lan, Longbin Li
In-Reply-To: <20260623074637.503864-1-inochiama@gmail.com>
The current irq definition of the wake irq and the lpi irq
is wrong, replace them with the right number and name.
Fixes: 30f0ba420ed3 ("net: stmmac: Add glue layer for Spacemit K3 SoC")
Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
index 3bfb6d49be6c..322bdf167a4a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
@@ -22,8 +22,8 @@
#define CTRL_PHY_INTF_RMII FIELD_PREP(CTRL_PHY_INTF_MODE, 0)
#define CTRL_PHY_INTF_RGMII FIELD_PREP(CTRL_PHY_INTF_MODE, 1)
#define CTRL_PHY_INTF_MII FIELD_PREP(CTRL_PHY_INTF_MODE, 3)
-#define CTRL_WAKE_IRQ_EN BIT(9)
-#define CTRL_PHY_IRQ_EN BIT(12)
+#define CTRL_LPI_IRQ_EN BIT(9)
+#define CTRL_WAKE_IRQ_EN BIT(12)
/* dline register bits */
#define RGMII_RX_DLINE_EN BIT(0)
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 0/5] KVM: arm64: nv: Implement nested stage-2 reverse map
From: Itaru Kitayama @ 2026-06-23 7:46 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: linux-arm-kernel, kvmarm, linux-kernel, Marc Zyngier,
Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon
In-Reply-To: <20260510145338.322962-1-weilin.chang@arm.com>
Hi Wei-Lin,
On Sun, May 10, 2026 at 03:53:33PM +0100, Wei-Lin Chang wrote:
> Hi,
>
> This is v3 of optimizing the shadow s2 mmu unmapping during MMU
> notifiers.
>
> Two new preparatory patches are added, one reduces a hole in kvm_s2_mmu
> and another refactors the code a bit during s2 faults. Other changes are
> listed below.
>
> * Changes from v2 [1]:
>
> - Removed "polluted" teminology.
>
> - Use xa_{mk, to}_value() when storing and retriving values from maple
> trees.
>
> - Avoid using the 63rd bit in maple tree values so that xa_{mk, to}_value()
> does not lose us a bit.
>
> - Added reverse map removal during TLBI handling.
>
> - Other suggested refactorings.
>
> Thanks!
>
> [1]: https://lore.kernel.org/kvmarm/20260411125024.3735989-1-weilin.chang@arm.com/
>
> Wei-Lin Chang (5):
> KVM: arm64: Use a variable for the canonical GPA in kvm_s2_fault_map()
> KVM: arm64: Move shadow_pt_debugfs_dentry to reduce holes in
> kvm_s2_mmu
> KVM: arm64: nv: Avoid full shadow s2 unmap
> KVM: arm64: nv: Remove reverse map entries during TLBI handling
> KVM: arm64: nv: Create nested IPA direct map to speed up reverse map
> removal
>
> arch/arm64/include/asm/kvm_host.h | 17 +-
> arch/arm64/include/asm/kvm_nested.h | 6 +
> arch/arm64/kvm/mmu.c | 43 +++--
> arch/arm64/kvm/nested.c | 238 +++++++++++++++++++++++++++-
> arch/arm64/kvm/sys_regs.c | 3 +
> 5 files changed, 290 insertions(+), 17 deletions(-)
While investigating the long VM teardown time on QEMU in the nested shadow
stage 2 selftest, I instrumented a few functions with bpftrace.
The same kselftest workload produced the following counts:
Without this series (today's kvmarm/fixes):
kvm_nested_s2_unmap: 12
kvm_pgtable_stage2_unmap: 8,388,623
kvm_tlb_flush_vmid_range: 8,388,623
exit_vmid_context: 8,388,639
With this series:
kvm_nested_s2_unmap: 12
kvm_pgtable_stage2_unmap: 18
kvm_tlb_flush_vmid_range: 18
exit_vmid_context: 34
The bpftrace script used was:
#!/usr/bin/env bpftrace
fentry:kvm_nested_s2_unmap
{
@nested = count();
}
fentry:kvm_pgtable_stage2_unmap
{
@pgunmap = count();
}
fentry:kvm_tlb_flush_vmid_range
{
@flush = count();
}
fentry:exit_vmid_context
{
@exit = count();
}
END
{
print(@nested);
print(@pgunmap);
print(@flush);
print(@exit);
}
Is this consistent with what you evaluated during the development?
I wonder if this is good for nested guest boot paths too.
Thanks,
Itaru.
>
> --
> 2.43.0
>
^ permalink raw reply
* [PATCH 4/4] mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled interrupt
From: ziniu.wang_1 @ 2026-06-23 7:35 UTC (permalink / raw)
To: adrian.hunter, ulf.hansson, haibo.chen
Cc: Frank.Li, s.hauer, kernel, festevam, imx, linux-mmc, s32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260623073515.2658205-1-ziniu.wang_1@oss.nxp.com>
From: Luke Wang <ziniu.wang_1@nxp.com>
When using WIFI out-of-band wakeup, an "irq xxx: nobody cared" warning
occurs. This happens because the usdhc interrupt is not disabled during
system suspend when device_may_wakeup() returns false.
The sequence of events leading to this issue:
1. System enters suspend without disabling usdhc interrupt
(because device_may_wakeup() returns false for usdhc device)
2. WIFI out-of-band wakeup triggers system resume via GPIO interrupt
3. WIFI sends a Card interrupt before usdhc has fully resumed
4. usdhc is still in runtime suspend state and cannot handle the
interrupt properly
5. The unhandled interrupt triggers "nobody cared" warning
Fix this by unconditionally disabling the usdhc interrupt during suspend
and re-enabling it during resume, regardless of the wakeup capability.
This ensures no interrupts are processed during the suspend/resume
transition.
Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic")
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
---
drivers/mmc/host/sdhci-esdhc-imx.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index a3688c94cf58..9afb74cac559 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -2076,9 +2076,10 @@ static int sdhci_esdhc_suspend(struct device *dev)
if (mmc_card_keep_power(host->mmc) && esdhc_is_usdhc(imx_data))
sdhc_esdhc_tuning_save(host);
+ /* The irqs of imx are not shared. It is safe to disable */
+ disable_irq(host->irq);
+
if (device_may_wakeup(dev)) {
- /* The irqs of imx are not shared. It is safe to disable */
- disable_irq(host->irq);
ret = sdhci_enable_irq_wakeups(host);
if (!ret)
dev_warn(dev, "Failed to enable irq wakeup\n");
@@ -2127,10 +2128,10 @@ static int sdhci_esdhc_resume(struct device *dev)
/* re-initialize hw state in case it's lost in low power mode */
sdhci_esdhc_imx_hwinit(host);
- if (host->irq_wake_enabled) {
+ if (host->irq_wake_enabled)
sdhci_disable_irq_wakeups(host);
- enable_irq(host->irq);
- }
+
+ enable_irq(host->irq);
/*
* restore the saved tuning delay value for the device which keep
--
2.34.1
^ permalink raw reply related
* [PATCH 2/4] mmc: sdhci-esdhc-imx: restore DLL override for DDR modes on resume
From: ziniu.wang_1 @ 2026-06-23 7:35 UTC (permalink / raw)
To: adrian.hunter, ulf.hansson, haibo.chen
Cc: Frank.Li, s.hauer, kernel, festevam, imx, linux-mmc, s32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260623073515.2658205-1-ziniu.wang_1@oss.nxp.com>
From: Luke Wang <ziniu.wang_1@nxp.com>
sdhci_esdhc_imx_hwinit() unconditionally clears ESDHC_DLL_CTRL by
writing zero. For SDIO devices that keep power during system suspend
and operate in DDR mode, the card remains in DDR timing while the host
DLL override configuration is lost.
Extract the DLL override setup from esdhc_set_uhs_signaling() into
a helper esdhc_set_dll_override(), and call it on the resume path
when the card kept power and is using a DDR timing mode.
Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic")
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
---
drivers/mmc/host/sdhci-esdhc-imx.c | 38 ++++++++++++++++++++++--------
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index 6526d65538de..a944351dbcdf 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -1349,6 +1349,23 @@ static int esdhc_change_pinstate(struct sdhci_host *host,
return pinctrl_select_state(imx_data->pinctrl, pinctrl);
}
+static void esdhc_set_dll_override(struct sdhci_host *host)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
+ struct esdhc_platform_data *boarddata = &imx_data->boarddata;
+ u32 v;
+
+ if (!boarddata->delay_line)
+ return;
+
+ v = boarddata->delay_line << ESDHC_DLL_OVERRIDE_VAL_SHIFT |
+ (1 << ESDHC_DLL_OVERRIDE_EN_SHIFT);
+ if (is_imx53_esdhc(imx_data))
+ v <<= 1;
+ writel(v, host->ioaddr + ESDHC_DLL_CTRL);
+}
+
/*
* For HS400 eMMC, there is a data_strobe line. This signal is generated
* by the device and used for data output and CRC status response output
@@ -1425,15 +1442,7 @@ static void esdhc_set_uhs_signaling(struct sdhci_host *host, unsigned timing)
m |= ESDHC_MIX_CTRL_DDREN;
writel(m, host->ioaddr + ESDHC_MIX_CTRL);
imx_data->is_ddr = 1;
- if (boarddata->delay_line) {
- u32 v;
- v = boarddata->delay_line <<
- ESDHC_DLL_OVERRIDE_VAL_SHIFT |
- (1 << ESDHC_DLL_OVERRIDE_EN_SHIFT);
- if (is_imx53_esdhc(imx_data))
- v <<= 1;
- writel(v, host->ioaddr + ESDHC_DLL_CTRL);
- }
+ esdhc_set_dll_override(host);
break;
case MMC_TIMING_MMC_HS400:
m |= ESDHC_MIX_CTRL_DDREN | ESDHC_MIX_CTRL_HS400_EN;
@@ -2123,9 +2132,18 @@ static int sdhci_esdhc_resume(struct device *dev)
* restore the saved tuning delay value for the device which keep
* power during system PM.
*/
- if (mmc_card_keep_power(host->mmc) && esdhc_is_usdhc(imx_data))
+ if (mmc_card_keep_power(host->mmc) && esdhc_is_usdhc(imx_data)) {
sdhc_esdhc_tuning_restore(host);
+ /*
+ * Restore DLL override for DDR modes. hwinit unconditionally
+ * clears ESDHC_DLL_CTRL, but the card is still in DDR mode.
+ */
+ if (host->timing == MMC_TIMING_UHS_DDR50 ||
+ host->timing == MMC_TIMING_MMC_DDR52)
+ esdhc_set_dll_override(host);
+ }
+
pm_runtime_put_autosuspend(dev);
return ret;
--
2.34.1
^ permalink raw reply related
* [PATCH 1/4] mmc: sdhci-esdhc-imx: remove unnecessary mmc_card_wake_sdio_irq check for tuning save/restore
From: ziniu.wang_1 @ 2026-06-23 7:35 UTC (permalink / raw)
To: adrian.hunter, ulf.hansson, haibo.chen
Cc: Frank.Li, s.hauer, kernel, festevam, imx, linux-mmc, s32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260623073515.2658205-1-ziniu.wang_1@oss.nxp.com>
From: Luke Wang <ziniu.wang_1@nxp.com>
The tuning save/restore during system PM is conditioned on
mmc_card_wake_sdio_irq(), but this check is unrelated to whether
tuning values need to be preserved. The actual requirement is that
the card keeps power during suspend and the controller is a uSDHC.
SDIO devices using out-of-band GPIO wakeup maintain power during
suspend but do not set the SDIO IRQ wake flag. In this case the
tuning delay values are not saved/restored.
Remove the unnecessary mmc_card_wake_sdio_irq() condition from both
the suspend save and resume restore paths.
Fixes: c63d25cdc59a ("mmc: sdhci-esdhc-imx: Save tuning value when card stays powered in suspend")
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
---
drivers/mmc/host/sdhci-esdhc-imx.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index 18ecddd6df6f..6526d65538de 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -2064,8 +2064,7 @@ static int sdhci_esdhc_suspend(struct device *dev)
* to save the tuning delay value just in case the usdhc
* lost power during system PM.
*/
- if (mmc_card_keep_power(host->mmc) && mmc_card_wake_sdio_irq(host->mmc) &&
- esdhc_is_usdhc(imx_data))
+ if (mmc_card_keep_power(host->mmc) && esdhc_is_usdhc(imx_data))
sdhc_esdhc_tuning_save(host);
if (device_may_wakeup(dev)) {
@@ -2124,8 +2123,7 @@ static int sdhci_esdhc_resume(struct device *dev)
* restore the saved tuning delay value for the device which keep
* power during system PM.
*/
- if (mmc_card_keep_power(host->mmc) && mmc_card_wake_sdio_irq(host->mmc) &&
- esdhc_is_usdhc(imx_data))
+ if (mmc_card_keep_power(host->mmc) && esdhc_is_usdhc(imx_data))
sdhc_esdhc_tuning_restore(host);
pm_runtime_put_autosuspend(dev);
--
2.34.1
^ permalink raw reply related
* [PATCH 0/4] mmc: sdhci-esdhc-imx: fix SDIO suspend/resume issues
From: ziniu.wang_1 @ 2026-06-23 7:35 UTC (permalink / raw)
To: adrian.hunter, ulf.hansson, haibo.chen
Cc: Frank.Li, s.hauer, kernel, festevam, imx, linux-mmc, s32,
linux-arm-kernel, linux-kernel
From: Luke Wang <ziniu.wang_1@nxp.com>
This series fixes several issues with SDIO devices that keep power
during system suspend on i.MX platforms.
Patch 1 removes unnecessary mmc_card_wake_sdio_irq() check from tuning
save/restore paths.
Patch 2 restores DLL override configuration for DDR modes on resume,
which is lost when sdhci_esdhc_imx_hwinit() clears ESDHC_DLL_CTRL.
Patch 3 restores pinctrl before pm_runtime_force_resume() to ensure
proper pin configuration before DDR_EN is set, avoiding CRC errors.
Patch 4 unconditionally disables usdhc interrupt during suspend to
prevent "irq xxx: nobody cared" warnings during resume.
Luke Wang (4):
mmc: sdhci-esdhc-imx: remove unnecessary mmc_card_wake_sdio_irq check
for tuning save/restore
mmc: sdhci-esdhc-imx: restore DLL override for DDR modes on resume
mmc: sdhci-esdhc-imx: restore pinctrl before restoring ios timing on
resume
mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled
interrupt
drivers/mmc/host/sdhci-esdhc-imx.c | 57 ++++++++++++++++++++----------
1 file changed, 39 insertions(+), 18 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v2] dt-bindings: clock: Replace bouncing emails
From: Krzysztof Kozlowski @ 2026-06-23 7:30 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sylwester Nawrocki, Chanwoo Choi, Peter Griffin, Alim Akhtar,
Barnabas Czeman, Tomasz Figa, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-samsung-soc, linux-arm-kernel
Cc: Krzysztof Kozlowski
Replace permanently bouncing email addresses (550 5.1.1 Recipient address
rejected) of Adam Skladowski, Chanho Park, Anusha Rao and Sireesh
Kodali. There are no new messages from them via other email addresses,
so drop them permanently. Add Alim Akhtar to Samsung ExynosAutov9 SoC
clocks, because he looks at other Samsung clock hardware and drivers.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Stephen, can you take this directly?
Changes in v2:
1. Also Anusha Rao.
---
Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml | 2 --
Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml | 1 -
Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml | 1 -
.../devicetree/bindings/clock/samsung,exynosautov9-clock.yaml | 2 +-
4 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
index fc0360554f68..9f2b970bfb48 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
@@ -7,8 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller on MSM8937, MSM8940, MSM8953 and SDM439
maintainers:
- - Adam Skladowski <a_skl39@protonmail.com>
- - Sireesh Kodali <sireeshkodali@protonmail.com>
- Barnabas Czeman <barnabas.czeman@mainlining.org>
description: |
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
index 5b128fa841aa..1337bd87fddd 100644
--- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
@@ -8,7 +8,6 @@ title: Qualcomm Global Clock & Reset Controller on IPQ9574
maintainers:
- Bjorn Andersson <andersson@kernel.org>
- - Anusha Rao <quic_anusha@quicinc.com>
description: |
Qualcomm global clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml
index 7ff4ff3587ca..a35bbc7b1924 100644
--- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml
@@ -8,7 +8,6 @@ title: Qualcomm Networking Sub System Clock & Reset Controller on IPQ9574 and IP
maintainers:
- Bjorn Andersson <andersson@kernel.org>
- - Anusha Rao <quic_anusha@quicinc.com>
description: |
Qualcomm networking sub system clock control module provides the clocks,
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
index e9d17d48b4f3..3dcdfa7a8792 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos Auto v9 SoC clock controller
maintainers:
- - Chanho Park <chanho61.park@samsung.com>
+ - Alim Akhtar <alim.akhtar@samsung.com>
- Chanwoo Choi <cw00.choi@samsung.com>
- Krzysztof Kozlowski <krzk@kernel.org>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
--
2.53.0
^ permalink raw reply related
* [PATCH] ARM: OMAP2+: Fix a reference leak bug in omap_hwmod_fix_mpu_rt_idx()
From: Haoxiang Li @ 2026-06-23 7:25 UTC (permalink / raw)
To: paul, aaro.koskinen, andreas, khilman, rogerq, tony, linux
Cc: linux-omap, linux-arm-kernel, linux-kernel, Haoxiang Li, stable
omap_hwmod_fix_mpu_rt_idx() gets the first child node with
of_get_next_child(), which returns a node with its reference count
incremented. The function uses the child node to translate the MPU
runtime register resource, but never drops the reference afterwards.
Add the missing of_node_put() after of_address_to_resource().
Fixes: 1dbcb97c656e ("ARM: OMAP2+: Fix module address for modules using mpu_rt_idx")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
---
arch/arm/mach-omap2/omap_hwmod.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 974107ff18b4..1d7677ca3802 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2176,6 +2176,7 @@ static void omap_hwmod_fix_mpu_rt_idx(struct omap_hwmod *oh,
if (error)
pr_err("%s: error mapping mpu_rt_idx: %i\n",
__func__, error);
+ of_node_put(child);
}
/**
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v5 1/1] arm64: dts: add tqma9596la-mba95xxca
From: Alexander Stein @ 2026-06-23 7:14 UTC (permalink / raw)
To: Frank Li
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Markus Niebel, imx,
linux-arm-kernel, devicetree, linux-kernel, linux,
linux-renesas-soc
In-Reply-To: <ajVN4nbmOW-D_Ec9@SMW015318>
[-- Attachment #1: Type: text/plain, Size: 4206 bytes --]
Am Freitag, 19. Juni 2026, 16:10:42 CEST schrieb Frank Li:
> On Fri, Jun 19, 2026 at 01:24:30PM +0200, Alexander Stein wrote:
> > From: Markus Niebel <Markus.Niebel@ew.tq-group.com>
> >
> > This adds support for TQMa95xxLA modules, designed to be soldered
> > on a carrier board. MBa95xxCA is a carrier reference board / starter kit
> > design.
> >
> > There is a common device tree for all variants with e.g. reduced
> > CPU core / feature count.
> >
> > Enable the external accessible PCIe controllers as host,
> > add clocking and reset GPIO. While at it, add hogs for GPIO
> > lines from the M.2 slots until M.2 connector driver is available.
> >
> > Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
> > Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> > ---
> > Changes in v5:
> > * Limit LPSPI4 max frequency
> > * Replace PCIe M2 Key-E GPIO hogs with dedicated connector node
> > * Fix PCIe clock configuration
> >
> > Changes in v4:
> > * Fix LPSPI4 pad muxing and control
> >
> > Changes in v3:
> > * Moved reserved-memory to board-lebel
> > * Remove VPU reserved memory (unused for now)
> > * Fix typo in connector comment
> >
> > Changes in v2:
> > * removed useless regulator
> > * added USB PD source configuration
> > * Removed unused uart-has-rtscts properties (unused by LPUART)
> > * Fixed RTS/CTS pullups in pinctrl
> > * Added thermalzone on module
> >
> > arch/arm64/boot/dts/freescale/Makefile | 1 +
> > .../freescale/imx95-tqma9596la-mba95xxca.dts | 963 ++++++++++++++++++
> > .../boot/dts/freescale/imx95-tqma9596la.dtsi | 278 +++++
> > 3 files changed, 1242 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts
> > create mode 100644 arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> > index 8ddaab127ab9c..43e1dc51b11d7 100644
> > --- a/arch/arm64/boot/dts/freescale/Makefile
> > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > @@ -649,6 +649,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-frdm-pro.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx95-aquila-clover.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx95-aquila-dev.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
> > +dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596la-mba95xxca.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596sa-mb-smarc-2.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx95-var-dart-sonata.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-nonwifi-dahlia.dtb
> ...
> > +
> > + ptn5110: usb-typec@50 {
> > + compatible = "nxp,ptn5110", "tcpci";
> > + reg = <0x50>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_typec>;
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + typec_con: connector {
> > + compatible = "usb-c-connector";
> > + label = "X9";
> > + power-role = "source";
> > + data-role = "dual";
> > + source-pdos = <PDO_FIXED(5000, 500, PDO_FIXED_USB_COMM)>;
> > + self-powered;
> > +
> > + port {
> > + typec_con_hs: endpoint {
> > + remote-endpoint = <&typec_hs>;
> > + };
> > + };
> > + };
> > + };
> > +
> > + sensor_mb: temperature-sensor@1e {
>
> please order by hex address value
Ah, thanks for the catch.
> > + compatible = "nxp,se97b", "jedec,jc-42.4-temp";
> > + reg = <0x1e>;
> > + };
> > +
> ...
> > + m2-keye-dev_bt-wake-hog {
> > + gpio-hog;
> > + gpios = <4 GPIO_ACTIVE_LOW>;
> > + input;
> > + line-name = "M2_KEYE_DEV_BT_WAKE#";
> > + };
>
> Now Key E connector already be upstreamed.
>
> Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml,
> which already define these gpios.
Thanks for the hint. But these two wake signals are vendor specific
pins 40 and 42 on key-e. In this case these are for the default module
JODY-W3 module.
Thanks and best regards,
Alexander
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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