* [PATCH 0/4] nvmem: add support for the MediaTek mt6323 PMIC
From: Roman Vivchar via B4 Relay @ 2026-06-11 10:20 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Roman Vivchar
Cc: Andy Shevchenko, Jonathan Cameron, linux-pm, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
This series adds support for the EFUSE 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 after split:
- EFUSE driver:
- Remove 'linux/errno.h' header (Andy)
- Remove explicit cast to u16 in the 'mt6323_efuse_read' (Andy)
- Reword comment in the 'mt6323_efuse_read'
- Capitalize MediaTek in the module description
- Link to a previous series: https://patch.msgid.link/20260512-mt6323-v2-0-3efcba579e88@protonmail.com
---
Roman Vivchar (4):
dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE
nvmem: add mt6323 PMIC EFUSE driver
mfd: mt6397-core: add mt6323 EFUSE support
ARM: dts: mediatek: mt6323: add EFUSE support
.../devicetree/bindings/mfd/mediatek,mt6397.yaml | 21 ++++++
MAINTAINERS | 5 ++
arch/arm/boot/dts/mediatek/mt6323.dtsi | 4 +
drivers/mfd/mt6397-core.c | 3 +
drivers/nvmem/Kconfig | 11 +++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/mt6323-efuse.c | 85 ++++++++++++++++++++++
7 files changed, 131 insertions(+)
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260611-mt6323-nvmem-0c54a0f2fa9f
Best regards,
--
Roman Vivchar <rva333@protonmail.com>
^ permalink raw reply
* [PATCH 1/4] dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE
From: Roman Vivchar via B4 Relay @ 2026-06-11 10:20 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Roman Vivchar
Cc: Andy Shevchenko, Jonathan Cameron, linux-pm, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260611-mt6323-nvmem-v1-0-b5e1b9ce51f2@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The MediaTek mt6323 PMIC includes an EFUSE used for storing calibration
data.
Add the devicetree binding documentation for the MediaTek mt6323 EFUSE.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
.../devicetree/bindings/mfd/mediatek,mt6397.yaml | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
index 05c121b0cb3d..beaa67bf0df2 100644
--- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
@@ -145,6 +145,23 @@ properties:
required:
- compatible
+ efuse:
+ type: object
+ unevaluatedProperties: false
+ description:
+ The efuse is responsible for storing calibration data, such as thermal
+ sensor calibration.
+
+ properties:
+ compatible:
+ const: mediatek,mt6323-efuse
+
+ nvmem-layout:
+ $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
+
+ required:
+ - compatible
+
leds:
type: object
additionalProperties: false
@@ -243,6 +260,10 @@ examples:
interrupt-controller;
#interrupt-cells = <2>;
+ efuse {
+ compatible = "mediatek,mt6323-efuse";
+ };
+
leds {
compatible = "mediatek,mt6323-led";
#address-cells = <1>;
--
2.54.0
^ permalink raw reply related
* [PATCH 2/4] nvmem: add mt6323 PMIC EFUSE driver
From: Roman Vivchar via B4 Relay @ 2026-06-11 10:20 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Roman Vivchar
Cc: Andy Shevchenko, Jonathan Cameron, linux-pm, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260611-mt6323-nvmem-v1-0-b5e1b9ce51f2@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
Add support for the EFUSE controller found in the Mediatek MT6323 PMIC.
The MT6323 EFUSE stores 24 bytes of hardware-related data, such as
thermal sensor calibration values.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
MAINTAINERS | 5 +++
drivers/nvmem/Kconfig | 11 ++++++
drivers/nvmem/Makefile | 2 ++
drivers/nvmem/mt6323-efuse.c | 85 ++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 103 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d1cc0e12fe1f..910360f148c4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16256,6 +16256,11 @@ S: Maintained
F: Documentation/devicetree/bindings/mmc/mtk-sd.yaml
F: drivers/mmc/host/mtk-sd.c
+MEDIATEK MT6323 PMIC NVMEM DRIVER
+M: Roman Vivchar <rva333@protonmail.com>
+S: Maintained
+F: drivers/nvmem/mt6323-efuse.c
+
MEDIATEK MT6735 CLOCK & RESET DRIVERS
M: Yassine Oudjana <y.oudjana@protonmail.com>
L: linux-clk@vger.kernel.org
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 74ddbd0f79b0..db248a3c4e87 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -227,6 +227,17 @@ config NVMEM_MTK_EFUSE
This driver can also be built as a module. If so, the module
will be called efuse-mtk.
+config NVMEM_MT6323_EFUSE
+ tristate "Mediatek MT6323 PMIC EFUSE support"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ depends on MFD_MT6397
+ help
+ This is a driver to access hardware related data like sensor
+ calibration, etc.
+
+ This driver can also be built as a module. If so, the module
+ will be called efuse-mt6323.
+
config NVMEM_MXS_OCOTP
tristate "Freescale MXS On-Chip OTP Memory Support"
depends on ARCH_MXS || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 7252b8ec88d4..0e2b73f42b25 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -48,6 +48,8 @@ obj-$(CONFIG_NVMEM_MICROCHIP_OTPC) += nvmem-microchip-otpc.o
nvmem-microchip-otpc-y := microchip-otpc.o
obj-$(CONFIG_NVMEM_MTK_EFUSE) += nvmem_mtk-efuse.o
nvmem_mtk-efuse-y := mtk-efuse.o
+obj-$(CONFIG_NVMEM_MT6323_EFUSE) += nvmem_mt6323-efuse.o
+nvmem_mt6323-efuse-y := mt6323-efuse.o
obj-$(CONFIG_NVMEM_MXS_OCOTP) += nvmem-mxs-ocotp.o
nvmem-mxs-ocotp-y := mxs-ocotp.o
obj-$(CONFIG_NVMEM_NINTENDO_OTP) += nvmem-nintendo-otp.o
diff --git a/drivers/nvmem/mt6323-efuse.c b/drivers/nvmem/mt6323-efuse.c
new file mode 100644
index 000000000000..c6fbfd96ac04
--- /dev/null
+++ b/drivers/nvmem/mt6323-efuse.c
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2026 Roman Vivchar <rva333@protonmail.com>
+ */
+
+#include <linux/err.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+#include <linux/mfd/mt6323/registers.h>
+
+#define MT6323_EFUSE_DOUT_BASE MT6323_EFUSE_DOUT_0_15
+#define MT6323_EFUSE_SIZE 24
+
+static int mt6323_efuse_read(void *context, unsigned int offset, void *val,
+ size_t bytes)
+{
+ struct regmap *map = context;
+ u32 tmp;
+ u16 *buf = val;
+ int ret;
+
+ /*
+ * A manual loop using regmap_read is required because PWRAP is not
+ * a continuous MMIO space, but rather a FSM that doesn't implement the
+ * necessary read callback for the regmap_read_raw and regmap_read_bulk
+ * functions.
+ */
+ for (size_t i = 0; i < bytes; i += sizeof(*buf)) {
+ ret = regmap_read(map, MT6323_EFUSE_DOUT_BASE + offset + i, &tmp);
+ if (ret)
+ return ret;
+
+ *buf++ = tmp;
+ }
+
+ return 0;
+}
+
+static int mt6323_efuse_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct nvmem_config config = {
+ .name = "mt6323-efuse",
+ .stride = 2,
+ .word_size = 2,
+ .size = MT6323_EFUSE_SIZE,
+ .reg_read = mt6323_efuse_read,
+ };
+ struct nvmem_device *nvmem;
+ struct regmap *regmap;
+
+ /* efuse -> mfd -> pwrap */
+ regmap = dev_get_regmap(dev->parent->parent, NULL);
+ if (!regmap)
+ return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
+
+ config.dev = dev;
+ config.priv = regmap;
+
+ nvmem = devm_nvmem_register(dev, &config);
+ return PTR_ERR_OR_ZERO(nvmem);
+}
+
+static const struct of_device_id mt6323_efuse_of_match[] = {
+ { .compatible = "mediatek,mt6323-efuse" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, mt6323_efuse_of_match);
+
+static struct platform_driver mt6323_efuse_driver = {
+ .probe = mt6323_efuse_probe,
+ .driver = {
+ .name = "mt6323-efuse",
+ .of_match_table = mt6323_efuse_of_match,
+ },
+};
+module_platform_driver(mt6323_efuse_driver);
+
+MODULE_DESCRIPTION("MediaTek MT6323 PMIC EFUSE driver");
+MODULE_LICENSE("GPL");
--
2.54.0
^ permalink raw reply related
* [PATCH 3/4] mfd: mt6397-core: add mt6323 EFUSE support
From: Roman Vivchar via B4 Relay @ 2026-06-11 10:20 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Roman Vivchar
Cc: Andy Shevchenko, Jonathan Cameron, linux-pm, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260611-mt6323-nvmem-v1-0-b5e1b9ce51f2@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The mt6323 PMIC includes an EFUSE. Register the EFUSE 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..362737a1c4a9 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-efuse",
+ .of_compatible = "mediatek,mt6323-efuse",
+ }, {
.name = "mt6323-rtc",
.num_resources = ARRAY_SIZE(mt6323_rtc_resources),
.resources = mt6323_rtc_resources,
--
2.54.0
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: mediatek: mt6323: add EFUSE support
From: Roman Vivchar via B4 Relay @ 2026-06-11 10:20 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Roman Vivchar
Cc: Andy Shevchenko, Jonathan Cameron, linux-pm, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260611-mt6323-nvmem-v1-0-b5e1b9ce51f2@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
Add the devicetree node for the mt6323 efuse.
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 | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/mt6323.dtsi b/arch/arm/boot/dts/mediatek/mt6323.dtsi
index c230c865116d..807e000a7ff6 100644
--- a/arch/arm/boot/dts/mediatek/mt6323.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt6323.dtsi
@@ -14,6 +14,10 @@ pmic: mt6323 {
interrupt-controller;
#interrupt-cells = <2>;
+ efuse {
+ compatible = "mediatek,mt6323-efuse";
+ };
+
mt6323_leds: leds {
compatible = "mediatek,mt6323-led";
#address-cells = <1>;
--
2.54.0
^ permalink raw reply related
* Re: [net-next 1/9] net: ethernet: ravb: Remove gPTP control from WoL setup and restore
From: sashiko-bot @ 2026-06-11 10:26 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: wsa+renesas, devicetree, conor+dt, robh
In-Reply-To: <20260610102432.3538432-2-niklas.soderlund+renesas@ragnatech.se>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unchecked return value of ptp_clock_register() leads to a kernel panic in ravb_ptp_stop() on failure.
--
commit 4d5ada4dabf46fceeae07f219f72c4daaba09e17
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
net: ethernet: ravb: Remove gPTP control from WoL setup and restore
This commit removes the explicit stopping and starting of the gPTP clock
during Wake-on-LAN (WoL) setup and restore. This is because the ndev is
always closed and re-opened during system suspend and resume, which handles
the clock state automatically.
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index 5f88733094d0f..77c0645a1c4d3 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
[ ... ]
> @@ -3201,9 +3198,6 @@ static int ravb_wol_restore(struct net_device *ndev)
> if (error)
> return error;
>
> - if (priv->info->ccc_gac)
> - ravb_ptp_init(ndev, priv->pdev);
> -
[Severity: High]
This is a pre-existing issue, but since this patch involves the usage of
ravb_ptp_init() and ravb_ptp_stop(), does ravb_ptp_init() need to check
the return value of ptp_clock_register()?
In drivers/net/ethernet/renesas/ravb_ptp.c:ravb_ptp_init(), the return value
is assigned directly without using IS_ERR():
priv->ptp.clock = ptp_clock_register(&priv->ptp.info, &pdev->dev);
If ptp_clock_register() fails and returns an error pointer like
ERR_PTR(-ENOMEM), priv->ptp.clock will hold this error pointer instead of
a valid clock or NULL.
Later, when ravb_ptp_stop() is unconditionally called during teardown or
driver removal, it executes:
ptp_clock_unregister(priv->ptp.clock);
Could this cause a kernel panic when ptp_clock_unregister() dereferences
the error pointer (e.g., when locking the internal mutex via
ptp_vclock_in_use)?
> if (info->nc_queues)
> napi_enable(&priv->napi[RAVB_NC]);
> napi_enable(&priv->napi[RAVB_BE]);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610102432.3538432-2-niklas.soderlund+renesas@ragnatech.se?part=1
^ permalink raw reply
* Re: [net-next 2/9] net: ethernet: ravb: Move programming of gPTP timer interval
From: sashiko-bot @ 2026-06-11 10:26 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: wsa+renesas, conor+dt, robh, devicetree
In-Reply-To: <20260610102432.3538432-3-niklas.soderlund+renesas@ragnatech.se>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] The gPTP initialization sequence incorrectly waits on the GCCR_TCR field instead of GCCR_LTI after requesting a timer increment load.
Pre-existing issues:
- [High] ravb_ptp_init() assigns the result of ptp_clock_register() to priv->ptp.clock without an IS_ERR() check, leading to invalid pointer dereferences.
--
commit 105bd561296a957da9d4e09fecae37137d532c98
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
net: ethernet: ravb: Move programming of gPTP timer interval
This commit moves the programming of the gPTP timer interval into the gPTP
initialization function. This allows the programming to occur while holding
the gPTP registers lock.
> diff --git a/drivers/net/ethernet/renesas/ravb_ptp.c b/drivers/net/ethernet/renesas/ravb_ptp.c
> index 226c6c0ab945b..7c78f75cb284a 100644
> --- a/drivers/net/ethernet/renesas/ravb_ptp.c
> +++ b/drivers/net/ethernet/renesas/ravb_ptp.c
[ ... ]
> @@ -319,11 +319,20 @@ void ravb_ptp_init(struct net_device *ndev, struct platform_device *pdev)
[ ... ]
> spin_lock_irqsave(&priv->lock, flags);
> +
> + /* Set gPTP Timer Increment Value. */
> + ravb_write(ndev, priv->ptp.default_addend, GTI);
> +
> + /* Request GTI loading. */
> + ravb_modify(ndev, GCCR, GCCR_LTI, GCCR_LTI);
> +
> + /* Wait for GIT loading to complete. */
> ravb_wait(ndev, GCCR, GCCR_TCR, GCCR_TCR_NOREQ);
[Severity: Medium]
The commit message states the goal is to wait for the timer interval
programming to be acknowledged by the hardware. Does waiting on GCCR_TCR
achieve this?
The code requests the load by setting GCCR_LTI, but the wait immediately
follows on GCCR_TCR. Since GCCR_TCR is typically 0 at this stage, the wait
will return immediately instead of waiting for the hardware to clear GCCR_LTI.
Could the subsequent ravb_modify() on GCCR execute before the hardware
clears GCCR_LTI, potentially writing a 1 back to it and disrupting the
initialization sequence?
> +
> ravb_modify(ndev, GCCR, GCCR_TCSS, GCCR_TCSS_ADJGPTP);
> spin_unlock_irqrestore(&priv->lock, flags);
[Severity: High]
This is a pre-existing issue, but looking at the rest of ravb_ptp_init()
just below this lock:
priv->ptp.clock = ptp_clock_register(&priv->ptp.info, &pdev->dev);
}
Should there be an IS_ERR() check here?
If ptp_clock_register() fails, it returns an ERR_PTR. Because the driver
does not validate the return value, priv->ptp.clock would hold this error
pointer.
When the interface is brought down via ravb_ptp_stop(), or when a hardware
PTP interrupt occurs, this pointer is passed to ptp_clock_unregister() or
ptp_clock_event(). Since neither function checks for error pointers, would
this lead to a panic from an invalid pointer dereference?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610102432.3538432-3-niklas.soderlund+renesas@ragnatech.se?part=1
^ permalink raw reply
* Re: [net-next 8/9] dt-bindings: net: renesas,etheravb: Add optional gPTP phandle for Gen4
From: sashiko-bot @ 2026-06-11 10:26 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: robh, wsa+renesas, conor+dt, devicetree
In-Reply-To: <20260610102432.3538432-9-niklas.soderlund+renesas@ragnatech.se>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Introduction of a redundant vendor-specific devicetree property `renesas,gptp` instead of using standard generic properties.
--
commit 4c4c5b9d2738df48084bc14d69fc8572fafc601c
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
dt-bindings: net: renesas,etheravb: Add optional gPTP phandle for Gen4
This commit adds an optional renesas,gptp phandle property to the
renesas,etheravb device tree binding to reference an external gPTP clock
for Gen4 platforms. It updates both the properties list and the schema
conditions to ensure this property is restricted to the Gen4 hardware variant.
> diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> index 1e00ef5b3acda..7bc910ab3ae0f 100644
> --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> @@ -122,6 +122,13 @@ properties:
> Specify when the AVB_LINK signal is active-low instead of normal
> active-high.
>
> + renesas,gptp:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + A phandle to an external gPTP clock for Gen4 platforms. The property is
[Severity: Low]
Could this use the standard generic ptp-timer property from
ethernet-controller.yaml instead of introducing a vendor-specific
renesas,gptp phandle?
The renesas,etheravb.yaml binding explicitly inherits from
ethernet-controller.yaml, which already defines ptp-timer as a standard
phandle for referencing an IEEE 1588 PTP device.
Alternatively, if this external module is simply a CCF reference clock,
could it be added to the standard clocks property instead?
> + optional for backwards compatibility, but without it gPTP timestamps are
> + disabled as Gen4 have no gPTP as part of the RAVB module itself.
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610102432.3538432-9-niklas.soderlund+renesas@ragnatech.se?part=1
^ permalink raw reply
* [PATCH] of: property: Fix of_fwnode_get_reference_args() with negative index
From: Alban Bedel @ 2026-06-11 10:28 UTC (permalink / raw)
To: devicetree
Cc: Rob Herring, Saravana Kannan, driver-core, linux-kernel,
Alban Bedel, Tommaso Merciai
fwnode_property_get_reference_args() should return -ENOENT when an out
of bound index is passed. An issue arised with the OF backend because
the OF API use signed indexes while the fwnode API use unsigned ones.
When an index value greater the INT_MAX was passed to the OF backend
it got casted to a negative value and it returned -EINVAL instead of
-ENOENT. This patch add a check to of_fwnode_get_reference_args() to
catch negative index before they are passed to the OF API and return
-ENOENT right away.
This issue appeared when the following pattern was used in the LED
subsystem:
index = fwnode_property_match_string(fwnode, "led-names", name)
led_node = fwnode_find_reference(fwnode, "leds", index);
Unlike the same pattern with the OF API, this pattern implicitly cast
the signed return value of fwnode_property_match_string() to an
unsigned index leading to the above issue with the OF backend. It can
be argued that the return value of fwnode_property_match_string()
should be checked separately, but I think there is value in supporting
such simple and straight to the point patterns.
Link: https://lore.kernel.org/linux-leds/aimVRwJPhlGxsIUj@tom-desktop/T/#mc43cbf7e0599991b56dd0d9680714d28d145fbc8
Cc: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Signed-off-by: Alban Bedel <alban.bedel@lht.dlh.de>
---
drivers/of/property.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 136946f8b746f..eace2d1847b99 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1157,6 +1157,13 @@ of_fwnode_get_reference_args(const struct fwnode_handle *fwnode,
unsigned int i;
int ret;
+ /* This function should return -ENOENT for out of bound indexes,
+ * but the OF API uses signed indexes and consider negative indexes
+ * as invalid. Catch them here to correctly implement the fwnode API.
+ */
+ if ((int)index < 0)
+ return -ENOENT;
+
if (nargs_prop)
ret = of_parse_phandle_with_args(to_of_node(fwnode), prop,
nargs_prop, index, &of_args);
--
2.39.5
^ permalink raw reply related
* Re: [PATCH 1/4] dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE
From: sashiko-bot @ 2026-06-11 10:30 UTC (permalink / raw)
To: Roman Vivchar via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260611-mt6323-nvmem-v1-1-b5e1b9ce51f2@protonmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `efuse` subnode acts as an NVMEM provider but fails to reference the common NVMEM provider schema (`/schemas/nvmem/nvmem.yaml#`).
--
commit 6bc9ae8fe8f4cc07cc7210883f39574a57c6be49
Author: Roman Vivchar <rva333@protonmail.com>
dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE
This commit adds the device tree binding documentation for the MediaTek
mt6323 EFUSE, which is included in the mt6323 PMIC for storing calibration
data.
> diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
[ ... ]
> @@ -145,6 +145,23 @@ properties:
> required:
> - compatible
>
> + efuse:
> + type: object
> + unevaluatedProperties: false
[Severity: Low]
Does this subnode need a reference to the common NVMEM provider schema?
Because unevaluatedProperties is set to false, any standard NVMEM properties
such as read-only, #address-cells, or #size-cells will trigger schema
validation errors if added to a device tree. Including a reference to
/schemas/nvmem/nvmem.yaml# would allow these standard properties to pass
validation.
> + description:
> + The efuse is responsible for storing calibration data, such as thermal
> + sensor calibration.
> +
> + properties:
> + compatible:
> + const: mediatek,mt6323-efuse
> +
> + nvmem-layout:
> + $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
> +
> + required:
> + - compatible
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-mt6323-nvmem-v1-0-b5e1b9ce51f2@protonmail.com?part=1
^ permalink raw reply
* Re: [PATCH 2/4] nvmem: add mt6323 PMIC EFUSE driver
From: sashiko-bot @ 2026-06-11 10:34 UTC (permalink / raw)
To: Roman Vivchar via B4 Relay; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260611-mt6323-nvmem-v1-2-b5e1b9ce51f2@protonmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Blind dereference of `dev->parent->parent` can lead to a kernel panic if the device is not instantiated with the expected MFD hierarchy.
--
commit 227574270c722d2b535d72fadcf31ba55bc47f8e
Author: Roman Vivchar <rva333@protonmail.com>
nvmem: add mt6323 PMIC EFUSE driver
This commit adds support for the EFUSE controller found in the Mediatek
MT6323 PMIC. It introduces a new nvmem driver that reads 24 bytes of
hardware-related data using regmap over the PMIC wrapper.
> diff --git a/drivers/nvmem/mt6323-efuse.c b/drivers/nvmem/mt6323-efuse.c
> new file mode 100644
> index 0000000000000..c6fbfd96ac047
> --- /dev/null
> +++ b/drivers/nvmem/mt6323-efuse.c
[ ... ]
> +static int mt6323_efuse_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct nvmem_config config = {
> + .name = "mt6323-efuse",
> + .stride = 2,
> + .word_size = 2,
> + .size = MT6323_EFUSE_SIZE,
> + .reg_read = mt6323_efuse_read,
> + };
> + struct nvmem_device *nvmem;
> + struct regmap *regmap;
> +
> + /* efuse -> mfd -> pwrap */
> + regmap = dev_get_regmap(dev->parent->parent, NULL);
[Severity: High]
Is it possible for dev->parent to be NULL here?
Because the driver defines an of_match_table, it might be instantiated directly
by the OF core or bound manually via sysfs, bypassing the MFD subsystem.
If dev->parent is NULL, evaluating dev->parent->parent will cause an immediate
NULL pointer dereference. Furthermore, if dev->parent is valid but has no
parent, dev->parent->parent evaluates to NULL. Passing a NULL device pointer to
dev_get_regmap() causes a fatal NULL pointer dereference inside devres_find()
when it attempts to acquire the devres_lock.
Would it be safer to explicitly verify that both dev->parent and
dev->parent->parent are non-NULL before dereferencing them?
> + if (!regmap)
> + return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
> +
> + config.dev = dev;
> + config.priv = regmap;
> +
> + nvmem = devm_nvmem_register(dev, &config);
> + return PTR_ERR_OR_ZERO(nvmem);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-mt6323-nvmem-v1-0-b5e1b9ce51f2@protonmail.com?part=2
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: iio: flow: add Sensirion SLF3S liquid flow sensor
From: Wadim Mueller @ 2026-06-11 10:35 UTC (permalink / raw)
To: Krzysztof Kozlowski, Jonathan Cameron
Cc: Wadim Mueller, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Maxwell Doose,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20260607-quixotic-steel-puma-133410@quoll>
Hi Krzysztof, Jonathan,
for v4 I'd like to keep the three specific per-variant compatibles from
v3 (sensirion,slf3s-0600f / -1300f / -4000b) and no generic fallback,
since the flow scale differs per sub-type.
Krzysztof, is that ok for you?
Thanks,
Wadim
^ permalink raw reply
* Re: [PATCH v2 1/4] soc: qcom: rpmh: Allow non-child devices to issue write commands
From: Konrad Dybcio @ 2026-06-11 10:36 UTC (permalink / raw)
To: Fenglin Wu, Dmitry Baryshkov
Cc: linux-arm-msm, Bjorn Andersson, Konrad Dybcio, Linus Walleij,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, Maulik Shah, kernel, linux-kernel, linux-gpio,
devicetree
In-Reply-To: <837dc7e2-4db8-4a7d-a19f-e53ddbcc9cf6@oss.qualcomm.com>
On 6/9/26 3:28 AM, Fenglin Wu wrote:
>
> On 6/8/2026 5:21 AM, Dmitry Baryshkov wrote:
>> On Thu, Jun 04, 2026 at 10:02:43AM +0800, Fenglin Wu wrote:
>>> On 6/2/2026 3:29 PM, Fenglin Wu wrote:
>>>> On 6/1/2026 9:37 PM, Dmitry Baryshkov wrote:
>>>>> On Thu, May 28, 2026 at 06:05:35PM -0700, Fenglin Wu wrote:
>>>>>> Currently, the RPMH driver only allows child devices of the RPMH
>>>>>> controller to issue commands, as it assumes dev->parent points to the
>>>>>> RSC device.
>>>>>>
>>>>>> There is a possibility that certain devices which are not children of
>>>>>> the RPMH controller want to send commands for special control at the
>>>>>> RPMH side. For example, in PMH0101 PMICs, there are bidirectional
>>>>>> level shifter (LS) peripherals, and each LS works with a pair of PMIC
>>>>>> GPIOs. The control of the LS, which is combined with the GPIO
>>>>>> configuration, is handled by RPMH firmware for sharing the resource
>>>>>> between different subsystems. From a hardware point of view, the LS
>>>>>> functionality is tied to a pair of PMIC GPIOs, so its control is more
>>>>>> suitable to be added in the pinctrl-spmi-gpio driver by adding the
>>>>>> level-shifter function. However, the pinctrl-spmi-gpio device is a
>>>>>> child device of the SPMI controller, not the RPMH controller.
>>>>> This replicates the story of the PMIC regulators. There are two drivers,
>>>>> one SPMI and one RPMh. Why don't we add a separate, RPMh-based GPIO
>>>>> driver targeting only those paired GPIOs (and we don't even need to
>>>>> represent them as a pair, it might be just one pin).
>>>> Thanks for the suggestion.
>>>>
>>>> I agree that adding a separate, RPMh-based GPIO driver would be more
>>>> straightforward from RPMh control perspective. It makes the new device
>>>> as a child of the RSC device then it can naturally use the APIs for RPMh
>>>> commands. The main challenge here is, we need to make the level-shifter
>>>> mutually exclusive with other GPIO functions when the GPIO pairs are
>>>> used in level-shifter function, which means we need to write SPMI
>>>> commands to disable the associated GPIO modules. I am not sure if AOP
>>>> already handles this; as far as I know, AOP only manages the
>>>> BIDIR_LVL_SHIFTER module registers. Let me double check on this
>>>> internally, if the GPIO modules could be controlled along
>>>> with BIDIR_LVL_SHIFTER module registers at AOP side, and get back.
>>>>
>>> I checked on this internally, AOP only handles BIDIR_LVL_SHIFTER module
>>> registers, it doesn't disable the associated GPIO modules. Also, I still
>>> have no idea how could we make the "level-shifter" function to be mutually
>>> exclusive with other GPIO functions after moved it into a separate driver.
>>> Do you have further suggestions?
>> So, for my understanding, we still need to write SPMI registers to
>> configure the pins and only then AOP can handle the level shifter?
>>
>> I was thinking of using gpio-reserved-ranges to prevent those GPIOs from
>> being used by the normal SPMI driver.
>
> More background: "level-shifter" module is actually an independent hardware which is not part of the GPIO module. However, they are sharing the physical pins. Which means, from PMIC chip perspective, these pins can be configured to either a GPIO function or the "level-shifter" function. So in PMIC base dtsi file, for example, pmh0101.dtsi, these pins should not be restricted in the GPIO nodes in "gpio-reserved-ranges".
>
> Also, we need to make the GPIO modules are disabled when the "level-shifter" is enabled, to ensure that the "level-shifter" circuitry is not impacted by the GPIO modules internal circuitry. So it is supposed to write GPIO EN_CTL register (offset 0x46) to 0 through SPMI bus when the "level-shifter" is enabled.
>
> That's why we have the requirement to access both RPMh and SPMI bus in the same driver.
I was thinking about other ways to solve it.. maybe someting like:
&pmh0101_gpios {
pmh0101_ls_pins1_2: foo-bar {
pins = "gpio1", "gpio2";
// appropriate pinctrl config
};
};
&rpmh_rsc {
// should this be a gpio controller? a mux provider?
// is there another class that would better suit this?
rpmh_level_shifter: rpmh-foo-bar {
pinctrl-0 = <&>;
pinctrl-names = "default";
};
};
// but where would it make sense to describe?
// fixed-regulator or something akin to that?
&some_consumer {
someclass = <&rpmh_level_shifter 1>;
};
i.e. the "rpmh level shifter" driver would consume a reference to the
pins, configure them as necessary (just like any other pinctrl consumer)
upon request
Konrad
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: usb: dwc3: document snps,reinit-phy-on-resume
From: Konrad Dybcio @ 2026-06-11 10:37 UTC (permalink / raw)
To: Rob Herring, Dmitry Baryshkov
Cc: Oliver White, Greg Kroah-Hartman, Krzysztof Kozlowski,
Conor Dooley, Thinh Nguyen, Bjorn Andersson, Konrad Dybcio,
Felipe Balbi, linux-usb, devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <CAL_JsqJi62TqakY6f+BzmaWx0Cr5m5KZT-GnMeLvNYRDTH-r3g@mail.gmail.com>
On 6/9/26 12:00 AM, Rob Herring wrote:
> On Sat, Jun 6, 2026 at 6:21 AM Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>
>> On Fri, Jun 05, 2026 at 02:06:38PM -0500, Rob Herring wrote:
>>> On Tue, Jun 02, 2026 at 11:12:34AM +1200, Oliver White wrote:
>>>> Add the documentation for the 'snps,reinit-phy-on-resume' boolean
>>>> property. When set, the DWC3 core will perform a full phy_exit() +
>>>> phy_init() cycle on each USB2 PHY during the host-mode fast resume
>>>> path. This is needed on platforms where the USB2 PHY power domain
>>>> is gated during deep sleep even when device_may_wakeup is true.
>>>>
>>>> Signed-off-by: Oliver White <oliverjwhite07@gmail.com>
>>>> ---
>>>> .../devicetree/bindings/usb/snps,dwc3-common.yaml | 10 ++++++++++
>>>> 1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml
>>>> index 6c0b8b653824..d12f6ae81ab8 100644
>>>> --- a/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml
>>>> +++ b/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml
>>>> @@ -212,6 +212,16 @@ properties:
>>>> When set, run the SOF/ITP counter based on ref_clk.
>>>> type: boolean
>>>>
>>>> + snps,reinit-phy-on-resume:
>>>> + description:
>>>> + When set, the DWC3 will re-initialize the USB2 PHYs during the
>>>> + host-mode fast resume path (device_may_wakeup). Some platforms
>>>> + cut PHY power during deep sleep even when USB wake is enabled,
>>>> + and the standard PHY runtime PM resume is insufficient to restore
>>>> + the PHY register state. This quirk forces a full phy_exit() +
>>>> + phy_init() cycle on each USB2 PHY.
>>>> + type: boolean
>>>
>>> This should be implied from a platform specific compatible string.
>>
>> Platform as in the "root node compatible"?
>
> No, the SoC specific one in the node you are trying to add this property to.
Taking a step back, wouldn't this point to an issue in the PHY driver
itself?
Konrad
^ permalink raw reply
* Re: [PATCH] of: property: Fix of_fwnode_get_reference_args() with negative index
From: sashiko-bot @ 2026-06-11 10:39 UTC (permalink / raw)
To: Alban Bedel; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260611102806.2643869-1-alban.bedel@lht.dlh.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Integer overflow in the bounds check of `software_node_get_reference_args` allows out-of-bounds memory read and potential kernel panic.
--
commit c268eb898558d8f55476cb8562a12b6fa754123b
Author: Alban Bedel <alban.bedel@lht.dlh.de>
of: property: Fix of_fwnode_get_reference_args() with negative index
This commit catches negative index values that are implicitly cast to
unsigned in the fwnode API before they are passed to the OF backend.
It ensures out-of-bounds indices return -ENOENT instead of -EINVAL.
Link: https://lore.kernel.org/linux-leds/aimVRwJPhlGxsIUj@tom-desktop/T/#mc43cbf7e0599991b56dd0d9680714d28d145fbc8
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index 136946f8b746f..eace2d1847b99 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -1157,6 +1157,13 @@ of_fwnode_get_reference_args(const struct fwnode_handle *fwnode,
> unsigned int i;
> int ret;
>
> + /* This function should return -ENOENT for out of bound indexes,
> + * but the OF API uses signed indexes and consider negative indexes
> + * as invalid. Catch them here to correctly implement the fwnode API.
> + */
> + if ((int)index < 0)
> + return -ENOENT;
[Severity: High]
This is a pre-existing issue, but does this exact same implicit cast pattern
cause a regression in the software node backend?
Looking at software_node_get_reference_args() in drivers/base/swnode.c:
drivers/base/swnode.c:software_node_get_reference_args() {
...
if ((index + 1) * sizeof(*ref) > prop->length)
return -ENOENT;
ref_array = prop->pointer;
ref = &ref_array[index];
...
}
If index is 0xffffffff (from a -1 return value implicitly cast to unsigned),
index + 1 wraps around to 0. The check 0 * sizeof(*ref) evaluates as not
greater than prop->length, completely bypassing the bounds check.
Could this lead to an out-of-bounds array access when computing
&ref_array[index], causing a panic when dereferenced?
Should a similar check for negative indices be added to the swnode backend?
> +
> if (nargs_prop)
> ret = of_parse_phandle_with_args(to_of_node(fwnode), prop,
> nargs_prop, index, &of_args);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611102806.2643869-1-alban.bedel@lht.dlh.de?part=1
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: display: Add Solomon SSD1351 OLED controller
From: Krzysztof Kozlowski @ 2026-06-11 10:39 UTC (permalink / raw)
To: Amit Barzilai
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, javierm,
robh, krzk+dt, conor+dt, dri-devel, devicetree, linux-kernel
In-Reply-To: <20260610164428.180091-2-amit.barzilai22@gmail.com>
> +properties:
> + compatible:
> + enum:
> + - solomon,ssd1351
> +
> + solomon,width:
> + default: 128
> +
> + solomon,height:
> + default: 128
Drop both - deducible from the compatible.
> +
> + rotation: true
Either drop or reference panel-common (if this is a panel) or at least
reference that property:
$ref: /schemas/display/panel/panel-common.yaml#/properties/rotation
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + oled@0 {
> + compatible = "solomon,ssd1351";
> + reg = <0x0>;
> + reset-gpios = <&gpio2 7>;
> + dc-gpios = <&gpio2 8>;
Use proper defines for GPIO flags
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: qcom,usb-hs-phy: add qcom,vendor-init-seq
From: Konrad Dybcio @ 2026-06-11 10:39 UTC (permalink / raw)
To: Dmitry Baryshkov, github.com, me
Cc: linux-phy, devicetree, linux-arm-msm, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson
In-Reply-To: <46lrfwoahgzoudq3afnhv4kxqs4fwj3w7u2dnx6ns6soo6pxt2@qkqbelan2iwq>
On 6/4/26 1:02 AM, Dmitry Baryshkov wrote:
> On Wed, Jun 03, 2026 at 06:09:18PM +0200, me@herrie.org wrote:
>> On 2026-06-03 15:57, Dmitry Baryshkov wrote:
>>> On Wed, Jun 03, 2026 at 07:48:08AM +0200, Herman van Hazendonk wrote:
>>>> Add an optional "qcom,vendor-init-seq" property carrying raw ULPI
>>>> (address, value) pairs that are written after PHY reset.
>>>>
>>>> Unlike the existing "qcom,init-seq" property, the address field is
>>>> NOT offset by ULPI_EXT_VENDOR_SPECIFIC, so the new property can
>>>> reach the standard ULPI vendor register range (0x30-0x3f). MSM8x60-
>>>> class hardware needs this range to programme pre-emphasis, HS driver
>>>> slope and CDR auto-reset bits the legacy msm_otg driver used to set
>>>> via platform data.
>>>
>>> Are those register writes specific to the device or to the whole
>>> platform? In the latter case please extend the driver to write them.
>>
>> Looking at every MSM8x60 reference kernel I could find (Qualcomm's own
>> msm8x60 board, HP TouchPad / APQ8060, and some HTC/Saumsung MSM8660
>> devices), the writes split into two groups:
>>
>> Platform-level (same across all MSM8x60 hardware):
>> - reg 0x36 bits 1+2: CDR auto-reset disabled, SE1 gating disabled
>> - reg 0x32 bits [5:4]: pre-emphasis at 20%
>>
>> Board-specific:
>> - reg 0x32 bits [3:0]: HS driver slope — HP TouchPad uses 5, HTC
>> devices use 1. This clearly depends on board layout (trace length,
>> connector loading, etc.).
>>
>> So the platform-level writes should move unconditionally into the driver
>> behind a match-data flag for the MSM8x60-class compatible, and only the
>> HS driver slope value belongs in DT.
>
> Looks like it. Please hardcode the value for your platform in the driver
> (with the comment), meanwhile we can try looking up the actual values.
Do we have the values for a MTP/QRD (or whatever they used to be called
back then..), like we would usually put in there?
Konrad
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: brige: lt9611c: add port-select property for LT9611C
From: Krzysztof Kozlowski @ 2026-06-11 10:40 UTC (permalink / raw)
To: Mohit Dsor
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, dri-devel, devicetree, linux-kernel, boss,
qc-display-maintainer
In-Reply-To: <20260611-lt9611-b4-send-v1-1-42abbcd3bb1e@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 02:44:56AM +0530, Mohit Dsor wrote:
> Add a new optional `lontium,port-select` property to describe the DSI
> input port configuration for the LT9611C variant, which supports
> single-port (A or B) and dual-port (A+B) operation.
>
> This property allows explicitly selecting the active DSI input port(s):
> 0 = port A (default)
> 1 = port B
> 2 = ports A and B (dual-port)
>
> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
> ---
> .../devicetree/bindings/display/bridge/lontium,lt9611.yaml | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> index e0821a63d9d7..77220f893bf8 100644
> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> @@ -41,6 +41,17 @@ properties:
> vcc-supply:
> description: Regulator for 3.3V IO power.
>
> + lontium,port-select:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1, 2]
> + default: 0
> + description: |
> + Selects which DSI input port(s) the bridge uses. Only relevant for
> + the lontium,lt9611c compatible.
> + 0 = PORT_SELECT_A - single DSI port A (default)
> + 1 = PORT_SELECT_B - single DSI port B
> + 2 = PORT_SELECT_AB - dual DSI ports A and B
Why graph is not enough? Seems exactly duplicating the graph ports.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/8] x1e80100: Enable PDC wake GPIOs and deepest idle state
From: Konrad Dybcio @ 2026-06-11 10:41 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad,
Stephan Gerhold
In-Reply-To: <20260526-hamoa_pdc-v2-0-f6857af1ce91@oss.qualcomm.com>
On 5/26/26 12:54 PM, Maulik Shah wrote:
> There are two modes PDC irqchip can work in
> - pass through mode
> - secondary controller mode
>
> Secondary mode is supported depending on SoC using PDC HW Version v3.0
> or higher.
[...]
> base-commit: 550604d6c9b9efc8d068aff94dc301694a7afdee
> change-id: 20260522-hamoa_pdc-1517acc2dcd4
> prerequisite-message-id: <20260410184124.1068210-1-mukesh.ojha@oss.qualcomm.com>
> prerequisite-patch-id: 152df6e30f70eb1b45909ce2793bc4277554b7ff
> prerequisite-patch-id: 118bd4216e0386e7214133f53153684947fa8dd3
> prerequisite-patch-id: 1f2f272d8ad1f7930d462e6349bc49de815e1ba1
> prerequisite-patch-id: 3754ffdf536206353f74953fd6d39804ff7787d4
This does depend on the changes you made on the driver, but not on
the 30 bundled DT changes - let's just point to the actual dependencies
Konrad
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: iio: flow: add Sensirion SLF3S liquid flow sensor
From: Krzysztof Kozlowski @ 2026-06-11 10:42 UTC (permalink / raw)
To: Wadim Mueller, Jonathan Cameron
Cc: Krzysztof Kozlowski, Rob Herring, Conor Dooley, David Lechner,
Nuno Sá, Andy Shevchenko, Maxwell Doose, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260611-slf3s-v3-reply-compatibles-decision-wafgo01@gmail.com>
On 11/06/2026 12:35, Wadim Mueller wrote:
> Hi Krzysztof, Jonathan,
>
> for v4 I'd like to keep the three specific per-variant compatibles from
> v3 (sensirion,slf3s-0600f / -1300f / -4000b) and no generic fallback,
> since the flow scale differs per sub-type.
>
> Krzysztof, is that ok for you?
You should have a specific fallback (since we did not reach consensus on
more generic fallback). All your three variants are fully detectable.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 1/7] ASoC: dt-bindings: ES8389: Add members about HPF and clock
From: Krzysztof Kozlowski @ 2026-06-11 10:45 UTC (permalink / raw)
To: Zhang Yi; +Cc: linux-sound, broonie, devicetree, tiwai, robh, krzk+dt, conor+dt
In-Reply-To: <20260611031824.4628-2-zhangyi@everest-semi.com>
On Thu, Jun 11, 2026 at 11:18:18AM +0800, Zhang Yi wrote:
> Add members related to HPF and mclk_source
> The value of HPF is not dB, it is just the value of registers
> And add HPF settings to the example
>
> Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
> ---
> .../bindings/sound/everest,es8389.yaml | 23 +++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
So this is like third time you send the same.
You never responded to feedback, I don't see improvements and you keep
sending the same v1.
Version your patches correctly - read help of git format-patch or just
use b4.
NAK again because you just ignore us.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 3/7] ASoC: codecs: ES8389: Fix the issue about mclk_src
From: Krzysztof Kozlowski @ 2026-06-11 10:46 UTC (permalink / raw)
To: Zhang Yi; +Cc: linux-sound, broonie, devicetree, tiwai, robh, krzk+dt, conor+dt
In-Reply-To: <20260611031824.4628-4-zhangyi@everest-semi.com>
On Thu, Jun 11, 2026 at 11:18:20AM +0800, Zhang Yi wrote:
> Fix the issue with incorrect modifications to mclk_src
> When the system needs to be configured to use the MCLK from the SCLK pin,
> the code still sets the relevant registers to use the MCLK from the MCLK pin
> And setting `mclk_src` to `u8` is inappropriate,
> because the purpose of `mclk_src` is to determine whether to use SCLK as MCLK.
> Therefore, we will change the `mclk_src` member from `u8` to `bool`.
>
> Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
NAK, same comments as before. You just ignore feedback.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/8] irqchip/qcom-pdc: restructure version support
From: Konrad Dybcio @ 2026-06-11 10:48 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <20260526-hamoa_pdc-v2-1-f6857af1ce91@oss.qualcomm.com>
On 5/26/26 12:54 PM, Maulik Shah wrote:
> PDC irqchip updates IRQ_ENABLE and IRQ_CFG and for three different
> versions v2.7, v3.0 and v3.2. These registers are organized in H/W
> as below on various SoCs.
[...]
> +static const struct pdc_cfg pdc_cfg_v3_2 = {
> + .irq_enable = GENMASK(3, 3),
BIT(3)
[...]
> + pdc->base = ioremap(res.start, res_size);
Can we use devm_ioremap() here?
[...]
> if (of_device_is_compatible(node, "qcom,x1e80100-pdc")) {
> - pdc_prev_base = ioremap(res.start - PDC_DRV_SIZE, IRQ_ENABLE_BANK_MAX);
> - if (!pdc_prev_base) {
> + pdc->prev_base = ioremap(res.start - PDC_DRV_SIZE,
> + pdc->regs->irq_en_reg + IRQ_ENABLE_BANK_MAX);
likewise
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/8] irqchip/qcom-pdc: restructure version support
From: Konrad Dybcio @ 2026-06-11 10:50 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <20260526-hamoa_pdc-v2-1-f6857af1ce91@oss.qualcomm.com>
On 5/26/26 12:54 PM, Maulik Shah wrote:
> PDC irqchip updates IRQ_ENABLE and IRQ_CFG and for three different
> versions v2.7, v3.0 and v3.2. These registers are organized in H/W
> as below on various SoCs.
[...]
> +struct pdc_desc {
> + void __iomem *base;
> + void __iomem *prev_base;
> + u32 version;
> + const struct pdc_regs *regs;
> + const struct pdc_cfg *cfg;
"cfg" is a bit vague, perhaps irq_cfg_fields or something similar?
That said, "irq_cfg_fields" isn't very catchy, so if you have a better
name, go ahead
Konrad
^ permalink raw reply
* Re: [PATCH v1 1/7] ASoC: dt-bindings: ES8389: Add members about HPF and clock
From: Krzysztof Kozlowski @ 2026-06-11 10:51 UTC (permalink / raw)
To: Zhang Yi; +Cc: linux-sound, broonie, devicetree, tiwai, robh, krzk+dt, conor+dt
In-Reply-To: <20260611-mamba-of-legendary-anger-af76a9@quoll>
On 11/06/2026 12:45, Krzysztof Kozlowski wrote:
> On Thu, Jun 11, 2026 at 11:18:18AM +0800, Zhang Yi wrote:
>> Add members related to HPF and mclk_source
>> The value of HPF is not dB, it is just the value of registers
>> And add HPF settings to the example
>>
>> Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
>> ---
>> .../bindings/sound/everest,es8389.yaml | 23 +++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>
> So this is like third time you send the same.
>
> You never responded to feedback, I don't see improvements and you keep
> sending the same v1.
>
> Version your patches correctly - read help of git format-patch or just
> use b4.
>
> NAK again because you just ignore us.
This was v1:
https://lore.kernel.org/all/20260608083540.12581-1-zhangyi@everest-semi.com/
Then you send v2 calling it v1:
https://lore.kernel.org/all/20260609025605.16945-1-zhangyi@everest-semi.com/
Then you sent it again:
https://lore.kernel.org/all/20260609030623.17404-1-zhangyi@everest-semi.com/
And now you send v4 (??!?) calling it v1:
https://lore.kernel.org/all/20260611031824.4628-1-zhangyi@everest-semi.com/
All within three days. And in the same time you never responded to
actual feedback.
This is not acceptable. Please stop spamming the list with the same
version and respond to the feedback. I expect addressing EVERY email you
received with reviews.
Best regards,
Krzysztof
^ 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