* [PATCH v3 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Daniel Golle @ 2026-04-19 12:05 UTC (permalink / raw)
To: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, Daniel Golle, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
Add compatible strings for MediaTek SoCs where the hardware random number
generator is accessed via a vendor-defined Secure Monitor Call (SMC)
rather than direct MMIO register access:
- mediatek,mt7981-rng
- mediatek,mt7987-rng
- mediatek,mt7988-rng
These variants require no reg, clocks, or clock-names properties since
the RNG hardware is managed by ARM Trusted Firmware-A.
Relax the $nodename pattern to also allow 'rng' in addition to the
existing 'rng@...' pattern.
Add a second example showing the minimal SMC variant binding.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
v3:
* drop not: in compatible conditional
* add reg/clocks/clock-names: false for mt7981-rng
* add else: requiring reg/clocks/clock-names for others
v2: express compatibilities with fallback
.../devicetree/bindings/rng/mtk-rng.yaml | 32 ++++++++++++++++---
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
index 7e8dc62e5d3a6..8fe6c209ab1e5 100644
--- a/Documentation/devicetree/bindings/rng/mtk-rng.yaml
+++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
@@ -11,12 +11,13 @@ maintainers:
properties:
$nodename:
- pattern: "^rng@[0-9a-f]+$"
+ pattern: "^rng(@[0-9a-f]+)?$"
compatible:
oneOf:
- enum:
- mediatek,mt7623-rng
+ - mediatek,mt7981-rng
- items:
- enum:
- mediatek,mt7622-rng
@@ -25,6 +26,11 @@ properties:
- mediatek,mt8365-rng
- mediatek,mt8516-rng
- const: mediatek,mt7623-rng
+ - items:
+ - enum:
+ - mediatek,mt7987-rng
+ - mediatek,mt7988-rng
+ - const: mediatek,mt7981-rng
reg:
maxItems: 1
@@ -38,9 +44,23 @@ properties:
required:
- compatible
- - reg
- - clocks
- - clock-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7981-rng
+ then:
+ properties:
+ reg: false
+ clocks: false
+ clock-names: false
+ else:
+ required:
+ - reg
+ - clocks
+ - clock-names
additionalProperties: false
@@ -53,3 +73,7 @@ examples:
clocks = <&infracfg CLK_INFRA_TRNG>;
clock-names = "rng";
};
+ - |
+ rng {
+ compatible = "mediatek,mt7981-rng";
+ };
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/2] hwrng: mtk - add support for hw access via SMCC
From: Daniel Golle @ 2026-04-19 12:05 UTC (permalink / raw)
To: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, Daniel Golle, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <585fc832e4e5d3656bd25ecee6bafb636993104a.1776600269.git.daniel@makrotopia.org>
Newer versions of ARM TrustedFirmware-A on MediaTek's ARMv8 SoCs no longer
allow accessing the TRNG from outside of the trusted firmware.
Instead, a vendor-defined custom Secure Monitor Call can be used to
acquire random bytes.
Add support for newer SoCs (MT7981, MT7987, MT7988).
As TF-A for the MT7986 may either follow the old or the new
convention, the best bet is to test if firmware blocks direct access
to the hwrng and if so, expect the SMCC interface to be usable.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
v3: unchanged
v2: unchanged
drivers/char/hw_random/mtk-rng.c | 127 ++++++++++++++++++++++++++-----
1 file changed, 106 insertions(+), 21 deletions(-)
diff --git a/drivers/char/hw_random/mtk-rng.c b/drivers/char/hw_random/mtk-rng.c
index 5808d09d12c45..8f5856b59ad66 100644
--- a/drivers/char/hw_random/mtk-rng.c
+++ b/drivers/char/hw_random/mtk-rng.c
@@ -3,6 +3,7 @@
* Driver for Mediatek Hardware Random Number Generator
*
* Copyright (C) 2017 Sean Wang <sean.wang@mediatek.com>
+ * Copyright (C) 2026 Daniel Golle <daniel@makrotopia.org>
*/
#define MTK_RNG_DEV KBUILD_MODNAME
@@ -17,6 +18,8 @@
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
+#include <linux/arm-smccc.h>
+#include <linux/soc/mediatek/mtk_sip_svc.h>
/* Runtime PM autosuspend timeout: */
#define RNG_AUTOSUSPEND_TIMEOUT 100
@@ -30,6 +33,11 @@
#define RNG_DATA 0x08
+/* Driver feature flags */
+#define MTK_RNG_SMC BIT(0)
+
+#define MTK_SIP_KERNEL_GET_RND MTK_SIP_SMC_CMD(0x550)
+
#define to_mtk_rng(p) container_of(p, struct mtk_rng, rng)
struct mtk_rng {
@@ -37,6 +45,7 @@ struct mtk_rng {
struct clk *clk;
struct hwrng rng;
struct device *dev;
+ unsigned long flags;
};
static int mtk_rng_init(struct hwrng *rng)
@@ -103,6 +112,56 @@ static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
return retval || !wait ? retval : -EIO;
}
+static int mtk_rng_read_smc(struct hwrng *rng, void *buf, size_t max,
+ bool wait)
+{
+ struct arm_smccc_res res;
+ int retval = 0;
+
+ while (max >= sizeof(u32)) {
+ arm_smccc_smc(MTK_SIP_KERNEL_GET_RND, 0, 0, 0, 0, 0, 0, 0,
+ &res);
+ if (res.a0)
+ break;
+
+ *(u32 *)buf = res.a1;
+ retval += sizeof(u32);
+ buf += sizeof(u32);
+ max -= sizeof(u32);
+ }
+
+ return retval || !wait ? retval : -EIO;
+}
+
+static bool mtk_rng_hw_accessible(struct mtk_rng *priv)
+{
+ u32 val;
+ int err;
+
+ err = clk_prepare_enable(priv->clk);
+ if (err)
+ return false;
+
+ val = readl(priv->base + RNG_CTRL);
+ val |= RNG_EN;
+ writel(val, priv->base + RNG_CTRL);
+
+ val = readl(priv->base + RNG_CTRL);
+
+ if (val & RNG_EN) {
+ /* HW is accessible, clean up: disable RNG and clock */
+ writel(val & ~RNG_EN, priv->base + RNG_CTRL);
+ clk_disable_unprepare(priv->clk);
+ return true;
+ }
+
+ /*
+ * If TF-A blocks direct access, the register reads back as 0.
+ * Leave the clock enabled as TF-A needs it.
+ */
+ return false;
+}
+
static int mtk_rng_probe(struct platform_device *pdev)
{
int ret;
@@ -114,23 +173,42 @@ static int mtk_rng_probe(struct platform_device *pdev)
priv->dev = &pdev->dev;
priv->rng.name = pdev->name;
-#ifndef CONFIG_PM
- priv->rng.init = mtk_rng_init;
- priv->rng.cleanup = mtk_rng_cleanup;
-#endif
- priv->rng.read = mtk_rng_read;
priv->rng.quality = 900;
-
- priv->clk = devm_clk_get(&pdev->dev, "rng");
- if (IS_ERR(priv->clk)) {
- ret = PTR_ERR(priv->clk);
- dev_err(&pdev->dev, "no clock for device: %d\n", ret);
- return ret;
+ priv->flags = (unsigned long)device_get_match_data(&pdev->dev);
+
+ if (!(priv->flags & MTK_RNG_SMC)) {
+ priv->clk = devm_clk_get(&pdev->dev, "rng");
+ if (IS_ERR(priv->clk)) {
+ ret = PTR_ERR(priv->clk);
+ dev_err(&pdev->dev, "no clock for device: %d\n", ret);
+ return ret;
+ }
+
+ priv->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(priv->base))
+ return PTR_ERR(priv->base);
+
+ if (IS_ENABLED(CONFIG_HAVE_ARM_SMCCC) &&
+ of_device_is_compatible(pdev->dev.of_node,
+ "mediatek,mt7986-rng") &&
+ !mtk_rng_hw_accessible(priv)) {
+ priv->flags |= MTK_RNG_SMC;
+ dev_info(&pdev->dev,
+ "HW RNG not MMIO accessible, using SMC\n");
+ }
}
- priv->base = devm_platform_ioremap_resource(pdev, 0);
- if (IS_ERR(priv->base))
- return PTR_ERR(priv->base);
+ if (priv->flags & MTK_RNG_SMC) {
+ if (!IS_ENABLED(CONFIG_HAVE_ARM_SMCCC))
+ return -ENODEV;
+ priv->rng.read = mtk_rng_read_smc;
+ } else {
+#ifndef CONFIG_PM
+ priv->rng.init = mtk_rng_init;
+ priv->rng.cleanup = mtk_rng_cleanup;
+#endif
+ priv->rng.read = mtk_rng_read;
+ }
ret = devm_hwrng_register(&pdev->dev, &priv->rng);
if (ret) {
@@ -139,12 +217,15 @@ static int mtk_rng_probe(struct platform_device *pdev)
return ret;
}
- dev_set_drvdata(&pdev->dev, priv);
- pm_runtime_set_autosuspend_delay(&pdev->dev, RNG_AUTOSUSPEND_TIMEOUT);
- pm_runtime_use_autosuspend(&pdev->dev);
- ret = devm_pm_runtime_enable(&pdev->dev);
- if (ret)
- return ret;
+ if (!(priv->flags & MTK_RNG_SMC)) {
+ dev_set_drvdata(&pdev->dev, priv);
+ pm_runtime_set_autosuspend_delay(&pdev->dev,
+ RNG_AUTOSUSPEND_TIMEOUT);
+ pm_runtime_use_autosuspend(&pdev->dev);
+ ret = devm_pm_runtime_enable(&pdev->dev);
+ if (ret)
+ return ret;
+ }
dev_info(&pdev->dev, "registered RNG driver\n");
@@ -181,8 +262,11 @@ static const struct dev_pm_ops mtk_rng_pm_ops = {
#endif /* CONFIG_PM */
static const struct of_device_id mtk_rng_match[] = {
- { .compatible = "mediatek,mt7986-rng" },
{ .compatible = "mediatek,mt7623-rng" },
+ { .compatible = "mediatek,mt7981-rng", .data = (void *)MTK_RNG_SMC },
+ { .compatible = "mediatek,mt7986-rng" },
+ { .compatible = "mediatek,mt7987-rng", .data = (void *)MTK_RNG_SMC },
+ { .compatible = "mediatek,mt7988-rng", .data = (void *)MTK_RNG_SMC },
{},
};
MODULE_DEVICE_TABLE(of, mtk_rng_match);
@@ -200,4 +284,5 @@ module_platform_driver(mtk_rng_driver);
MODULE_DESCRIPTION("Mediatek Random Number Generator Driver");
MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
+MODULE_AUTHOR("Daniel Golle <daniel@makrotopia.org>");
MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH 0/4] Add hstimer support for H616 and T113-S3
From: Michal Piekos @ 2026-04-19 12:46 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maxime Ripard
Cc: linux-kernel, devicetree, linux-arm-kernel, linux-sunxi,
Michal Piekos
Add support for Allwinner H616 high speed timer in sun5i hstimer driver
and describe corresponding nodes in dts for H616 and T113-S3.
H616 uses same model as existing driver except register shift compared
to older variants.
Added register layout abstraction in the driver, extended the binding
with new compatibles and wired up dts nodes for H616 and T113-S3 which
uses H616 as fallback compatible.
Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
Michal Piekos (4):
dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3
clocksource/drivers/sun5i: add H616 hstimer support
arm64: dts: allwinner: h616: add hstimer node
arm: dts: allwinner: t113s: add hstimer node
.../timer/allwinner,sun5i-a13-hstimer.yaml | 8 +++-
arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi | 12 +++++
arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 ++++
drivers/clocksource/timer-sun5i.c | 56 +++++++++++++++++++---
4 files changed, 78 insertions(+), 7 deletions(-)
---
base-commit: faeab166167f5787719eb8683661fd41a3bb1514
change-id: 20260413-h616-t113s-hstimer-62939948f91c
Best regards,
--
Michal Piekos <michal.piekos@mmpsystems.pl>
^ permalink raw reply
* [PATCH 2/4] clocksource/drivers/sun5i: add H616 hstimer support
From: Michal Piekos @ 2026-04-19 12:46 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maxime Ripard
Cc: linux-kernel, devicetree, linux-arm-kernel, linux-sunxi,
Michal Piekos
In-Reply-To: <20260419-h616-t113s-hstimer-v1-0-1af74ebef7c5@mmpsystems.pl>
H616 high speed timer differs from existing timer-sun5i by register base
offset.
Add selectable register layout structures.
Add H616 compatible string to OF match table.
Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
drivers/clocksource/timer-sun5i.c | 56 ++++++++++++++++++++++++++++++++++-----
1 file changed, 50 insertions(+), 6 deletions(-)
diff --git a/drivers/clocksource/timer-sun5i.c b/drivers/clocksource/timer-sun5i.c
index f827d3f98f60..125abc11c3c3 100644
--- a/drivers/clocksource/timer-sun5i.c
+++ b/drivers/clocksource/timer-sun5i.c
@@ -21,18 +21,52 @@
#define TIMER_IRQ_EN_REG 0x00
#define TIMER_IRQ_EN(val) BIT(val)
#define TIMER_IRQ_ST_REG 0x04
-#define TIMER_CTL_REG(val) (0x20 * (val) + 0x10)
#define TIMER_CTL_ENABLE BIT(0)
#define TIMER_CTL_RELOAD BIT(1)
-#define TIMER_CTL_CLK_PRES(val) (((val) & 0x7) << 4)
#define TIMER_CTL_ONESHOT BIT(7)
-#define TIMER_INTVAL_LO_REG(val) (0x20 * (val) + 0x14)
-#define TIMER_INTVAL_HI_REG(val) (0x20 * (val) + 0x18)
-#define TIMER_CNTVAL_LO_REG(val) (0x20 * (val) + 0x1c)
-#define TIMER_CNTVAL_HI_REG(val) (0x20 * (val) + 0x20)
+#define TIMER_CTL_CLK_PRES(val) (((val) & 0x7) << 4)
+#define TIMER_CTL_REG(val) \
+ (soc_base->stride * (val) + soc_base->ctl_base)
+#define TIMER_INTVAL_LO_REG(val) \
+ (soc_base->stride * (val) + soc_base->intval_lo_base)
+#define TIMER_INTVAL_HI_REG(val) \
+ (soc_base->stride * (val) + soc_base->intval_hi_base)
+#define TIMER_CNTVAL_LO_REG(val) \
+ (soc_base->stride * (val) + soc_base->cntval_lo_base)
+#define TIMER_CNTVAL_HI_REG(val) \
+ (soc_base->stride * (val) + soc_base->cntval_hi_base)
#define TIMER_SYNC_TICKS 3
+struct sunxi_timer_base {
+ u32 ctl_base;
+ u32 intval_lo_base;
+ u32 intval_hi_base;
+ u32 cntval_lo_base;
+ u32 cntval_hi_base;
+ u32 stride;
+};
+
+static const struct sunxi_timer_base sun5i_base = {
+ .ctl_base = 0x10,
+ .intval_lo_base = 0x14,
+ .intval_hi_base = 0x18,
+ .cntval_lo_base = 0x1c,
+ .cntval_hi_base = 0x20,
+ .stride = 0x20
+};
+
+static const struct sunxi_timer_base sun50i_base = {
+ .ctl_base = 0x20,
+ .intval_lo_base = 0x24,
+ .intval_hi_base = 0x28,
+ .cntval_lo_base = 0x2c,
+ .cntval_hi_base = 0x30,
+ .stride = 0x20
+};
+
+static const struct sunxi_timer_base *soc_base;
+
struct sun5i_timer {
void __iomem *base;
struct clk *clk;
@@ -238,6 +272,7 @@ static int sun5i_setup_clockevent(struct platform_device *pdev,
static int sun5i_timer_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
+ struct device_node *node = dev_of_node(&pdev->dev);
struct sun5i_timer *st;
struct reset_control *rstc;
void __iomem *timer_base;
@@ -251,6 +286,14 @@ static int sun5i_timer_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, st);
+ if (!node)
+ return -EINVAL;
+
+ if (of_device_is_compatible(node, "allwinner,sun50i-h616-hstimer"))
+ soc_base = &sun50i_base;
+ else
+ soc_base = &sun5i_base;
+
timer_base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(timer_base)) {
dev_err(dev, "Can't map registers\n");
@@ -314,6 +357,7 @@ static void sun5i_timer_remove(struct platform_device *pdev)
static const struct of_device_id sun5i_timer_of_match[] = {
{ .compatible = "allwinner,sun5i-a13-hstimer" },
{ .compatible = "allwinner,sun7i-a20-hstimer" },
+ { .compatible = "allwinner,sun50i-h616-hstimer" },
{},
};
MODULE_DEVICE_TABLE(of, sun5i_timer_of_match);
--
2.43.0
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3
From: Michal Piekos @ 2026-04-19 12:46 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maxime Ripard
Cc: linux-kernel, devicetree, linux-arm-kernel, linux-sunxi,
Michal Piekos
In-Reply-To: <20260419-h616-t113s-hstimer-v1-0-1af74ebef7c5@mmpsystems.pl>
H616 is compatible with the existing sun5i binding, but
require its own compatible string to differentiate register offsets.
T113-S3 uses same offsets as H616.
Add allwinner,sun50i-h616-hstimer
Add allwinner,sun8i-t113s-hstimer with fallback to
allwinner,sun50i-h616-hstimer
Extend schema condition for interrupts to cover H616 compatible variant.
Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
.../devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
index f1853daec2f9..bb60a85dc34b 100644
--- a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
+++ b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
@@ -15,9 +15,13 @@ properties:
oneOf:
- const: allwinner,sun5i-a13-hstimer
- const: allwinner,sun7i-a20-hstimer
+ - const: allwinner,sun50i-h616-hstimer
- items:
- const: allwinner,sun6i-a31-hstimer
- const: allwinner,sun7i-a20-hstimer
+ - items:
+ - const: allwinner,sun8i-t113s-hstimer
+ - const: allwinner,sun50i-h616-hstimer
reg:
maxItems: 1
@@ -45,7 +49,9 @@ required:
if:
properties:
compatible:
- const: allwinner,sun5i-a13-hstimer
+ enum:
+ - allwinner,sun5i-a13-hstimer
+ - allwinner,sun50i-h616-hstimer
then:
properties:
--
2.43.0
^ permalink raw reply related
* [PATCH 4/4] arm: dts: allwinner: t113s: add hstimer node
From: Michal Piekos @ 2026-04-19 12:46 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maxime Ripard
Cc: linux-kernel, devicetree, linux-arm-kernel, linux-sunxi,
Michal Piekos
In-Reply-To: <20260419-h616-t113s-hstimer-v1-0-1af74ebef7c5@mmpsystems.pl>
Describe high speed timer block on Allwinner T113-S3.
Tested on LCPI-PC-T113/F113:
- hstimer is registered as clocksource
- switching clocksource at runtime works
- after rating increase hstimer operates as a broadcast clockevent device
Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi b/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
index 424f4a2487e2..f811ae0924d6 100644
--- a/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
@@ -34,6 +34,18 @@ cpu1: cpu@1 {
};
};
+ soc {
+ hstimer@3008000 {
+ compatible = "allwinner,sun8i-t113s-hstimer",
+ "allwinner,sun50i-h616-hstimer";
+ reg = <0x03008000 0x1000>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_HSTIMER>;
+ resets = <&ccu RST_BUS_HSTIMER>;
+ };
+ };
+
gic: interrupt-controller@1c81000 {
compatible = "arm,gic-400";
reg = <0x03021000 0x1000>,
--
2.43.0
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: allwinner: h616: add hstimer node
From: Michal Piekos @ 2026-04-19 12:46 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maxime Ripard
Cc: linux-kernel, devicetree, linux-arm-kernel, linux-sunxi,
Michal Piekos
In-Reply-To: <20260419-h616-t113s-hstimer-v1-0-1af74ebef7c5@mmpsystems.pl>
Describe high speed timer block on Allwinner H616.
Tested on Orange Pi Zero 3:
- hstimer is registered as clocksource
- switching clocksource at runtime works
- after rating increase hstimer operates as a broadcast clockevent device
Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
index bf054869e78b..0713a17264ec 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
@@ -237,6 +237,15 @@ timer0: timer@3009000 {
clocks = <&osc24M>;
};
+ hstimer@3005000 {
+ compatible = "allwinner,sun50i-h616-hstimer";
+ reg = <0x03005000 0x1000>;
+ interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_HSTIMER>;
+ resets = <&ccu RST_BUS_HSTIMER>;
+ };
+
watchdog: watchdog@30090a0 {
compatible = "allwinner,sun50i-h616-wdt",
"allwinner,sun6i-a31-wdt";
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] phy: qualcomm: qmp-combo: update DP PHY PLL programming on Glymur
From: Dmitry Baryshkov @ 2026-04-19 13:18 UTC (permalink / raw)
To: Mahadevan P
Cc: Vinod Koul, Neil Armstrong, Wesley Cheng, Abel Vesa,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, linux-kernel, devicetree,
Ritesh Kumar
In-Reply-To: <20260419-glymur_dp-v1-1-ad1067a8e8ae@oss.qualcomm.com>
On Sun, 19 Apr 2026 at 13:16, Mahadevan P <mahadevan.p@oss.qualcomm.com> wrote:
>
> The existing DP PHY PLL and AUX configuration for the Glymur platform
> does not fully follow the Hardware Programming Guide requirements for
> DP over Type-C, which results in DP link bring-up failures.
>
> Update the DP PHY programming sequence and PLL-related register
> settings to align with the latest HPG recommendations. With this
> change, DP link training completes successfully on Glymur-based
> platforms.
>
> Fixes: d10736db98d2 ("phy: qualcomm: qmp-combo: Add DP offsets and settings for Glymur platforms")
> Signed-off-by: Ritesh Kumar <ritesh.kumar@oss.qualcomm.com>
> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
> ---
> Tested on a Glymur CRD platform with two DisplayPorts over USB Type-C:
> - Link training completes successfully
> - Display comes up at expected resolutions
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 213 +++++++++++++++------
> drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v8.h | 2 +
> 2 files changed, 154 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> index 93f1aa10d400..bb5e4091fd0c 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> @@ -283,8 +283,8 @@ static const unsigned int qmp_v8_n3_usb43dpphy_regs_layout[QPHY_LAYOUT_SIZE] = {
> [QPHY_DP_AON_TOGGLE_ENABLE] = QPHY_V8_PCS_AON_DP_AON_TOGGLE_ENABLE,
>
> [QPHY_COM_RESETSM_CNTRL] = QSERDES_V8_COM_RESETSM_CNTRL,
> - [QPHY_COM_C_READY_STATUS] = QSERDES_V8_COM_C_READY_STATUS,
> - [QPHY_COM_CMN_STATUS] = QSERDES_V8_COM_CMN_STATUS,
> + [QPHY_COM_C_READY_STATUS] = QSERDES_V8_COM_C_READY_STATUS_N3,
> + [QPHY_COM_CMN_STATUS] = QSERDES_V8_COM_CMN_STATUS_N3,
> [QPHY_COM_BIAS_EN_CLKBUFLR_EN] = QSERDES_V8_COM_BIAS_EN_CLKBUFLR_EN,
>
> [QPHY_DP_PHY_STATUS] = QSERDES_V8_DP_PHY_STATUS,
> @@ -1386,10 +1386,10 @@ static const struct qmp_phy_init_tbl qmp_v6_n4_dp_serdes_tbl[] = {
> };
>
> static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl[] = {
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE2_MODE0, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE2_MODE0, 0x02),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CP_CTRL_MODE0, 0x06),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_RCTRL_MODE1, 0x10),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_CCTRL_MODE1, 0x01),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_RCTRL_MODE0, 0x16),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_CCTRL_MODE0, 0x36),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CORECLK_DIV_MODE0, 0x0a),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DIV_FRAC_START1_MODE0, 0x00),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_INTEGLOOP_GAIN0_MODE0, 0x3f),
> @@ -1404,12 +1404,13 @@ static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl[] = {
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SYSCLK_BUF_ENABLE, 0x06),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_IVCO, 0x07),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SYSCLK_EN_SEL, 0x3b),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_RESETSM_CNTRL, 0x20),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP_EN, 0x00),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_VCO_TUNE_CTRL, 0x00),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_VCO_TUNE_MAP, 0x00),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CLK_SELECT, 0x30),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CORE_CLK_EN, 0x00),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CMN_CONFIG_1, 0x56),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CMN_CONFIG_1, 0x16),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SVS_MODE_CLK_SEL, 0x15),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CMN_MODE_CONTD1, 0x24),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DCC_CAL_1, 0x40),
> @@ -1445,26 +1446,26 @@ static const struct qmp_phy_init_tbl qmp_v6_n4_dp_tx_tbl[] = {
> };
>
> static const struct qmp_phy_init_tbl qmp_v8_n3p_dp_tx_tbl[] = {
> - QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TRANSMITTER_EN_CTRL, 0x3f),
> + QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TRANSMITTER_EN_CTRL, 0x1a),
> QMP_PHY_INIT_CFG(QSERDES_V8_LALB_VMODE_CTRL1, 0x40),
> QMP_PHY_INIT_CFG(QSERDES_V8_LALB_ANA_INTERFACE_SELECT1, 0x07),
> QMP_PHY_INIT_CFG(QSERDES_V8_LALB_ANA_INTERFACE_SELECT2, 0x18),
> QMP_PHY_INIT_CFG(QSERDES_V8_LALB_PCS_INTERFACE_SELECT1, 0x50),
> QMP_PHY_INIT_CFG(QSERDES_V8_LALB_LANE_MODE_1, 0x0d),
> - QMP_PHY_INIT_CFG(QSERDES_V8_LALB_CLKBUF_ENABLE, 0x07),
> - QMP_PHY_INIT_CFG(QSERDES_V8_LALB_RESET_TSYNC_EN_CTRL, 0x0a),
> + QMP_PHY_INIT_CFG(QSERDES_V8_LALB_CLKBUF_ENABLE, 0x87),
> + QMP_PHY_INIT_CFG(QSERDES_V8_LALB_RESET_TSYNC_EN_CTRL, 0x0f),
> QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX_LVL_UPDATE_CTRL, 0x0f),
> QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TRAN_DRVR_EMP_EN, 0x5f),
> - QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX0_EMP_POST1_LVL, 0x20),
> - QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX1_EMP_POST1_LVL, 0x20),
> + QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX0_EMP_POST1_LVL, 0x2b),
> + QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX1_EMP_POST1_LVL, 0x2b),
> QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX0_PRE1_EMPH, 0x20),
> QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX1_PRE1_EMPH, 0x20),
> QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX0_DRV_LVL, 0x00),
> QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX1_DRV_LVL, 0x00),
> - QMP_PHY_INIT_CFG(QSERDES_V8_LALB_HIGHZ_DRVR_EN, 0x30),
> + QMP_PHY_INIT_CFG(QSERDES_V8_LALB_HIGHZ_DRVR_EN, 0x3f),
> QMP_PHY_INIT_CFG(QSERDES_V8_LALB_LANE_MODE_2, 0x50),
> QMP_PHY_INIT_CFG(QSERDES_V8_LALB_LANE_MODE_3, 0x51),
> - QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX_DCC_ANA_CTRL2, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX_DCC_ANA_CTRL2, 0x0c),
> QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX0_RESTRIM_CAL_CTRL, 0x20),
> QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX1_RESTRIM_CAL_CTRL, 0x02),
> QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX0_RESTRIM_POST_CAL_OFFSET, 0x10),
> @@ -1589,11 +1590,12 @@ static const struct qmp_phy_init_tbl qmp_v6_n4_dp_serdes_tbl_hbr3[] = {
>
> static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_rbr[] = {
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_HSCLK_SEL_1, 0x05),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0x7a),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x02),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0x8d),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x27),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE1_MODE0, 0x83),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP1_MODE0, 0x37),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP2_MODE0, 0x04),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE2_MODE0, 0x02),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP1_MODE0, 0x1c),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP2_MODE0, 0x02),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DEC_START_MODE0, 0x54),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DIV_FRAC_START2_MODE0, 0x00),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DIV_FRAC_START3_MODE0, 0x06),
> @@ -1601,16 +1603,17 @@ static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_rbr[] = {
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_VCO_TUNE2_MODE0, 0x00),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_HSCLK_SEL_1, 0x05),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CMN_MODE_CONTD3, 0x07),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CLK_FWD_CONFIG_1, 0x30),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_IP_CTRL_AND_DP_SEL, 0xa4),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CLK_FWD_CONFIG_1, 0x3f),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_IP_CTRL_AND_DP_SEL, 0xa7),
> };
>
> static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_hbr[] = {
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_HSCLK_SEL_1, 0x04),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0x21),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x04),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0xf6),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x20),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE1_MODE0, 0x18),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP1_MODE0, 0x07),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE2_MODE0, 0x02),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP1_MODE0, 0x08),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP2_MODE0, 0x07),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DEC_START_MODE0, 0x46),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DIV_FRAC_START2_MODE0, 0x00),
> @@ -1627,7 +1630,8 @@ static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_hbr2[] = {
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_HSCLK_SEL_1, 0x03),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0xf6),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x20),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE1_MODE0, 0x0),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE1_MODE0, 0x18),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE2_MODE0, 0x02),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_RCTRL_MODE0, 0x16),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_CCTRL_MODE0, 0x36),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP1_MODE0, 0x10),
> @@ -1637,9 +1641,9 @@ static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_hbr2[] = {
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DIV_FRAC_START3_MODE0, 0x05),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_VCO_TUNE1_MODE0, 0xae),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_VCO_TUNE2_MODE0, 0x02),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_HSCLK_SEL_1, 0x00),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_IP_CTRL_AND_DP_SEL, 0xbf),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIAS_EN_CLKBUFLR_EN, 0x1c),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_HSCLK_SEL_1, 0x03),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_IP_CTRL_AND_DP_SEL, 0xab),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIAS_EN_CLKBUFLR_EN, 0x17),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_RESETSM_CNTRL, 0x20),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CMN_MODE_CONTD3, 0x03),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CLK_FWD_CONFIG_1, 0x3f),
> @@ -1647,8 +1651,8 @@ static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_hbr2[] = {
>
> static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_hbr3[] = {
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_HSCLK_SEL_1, 0x02),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0x63),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x0c),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0x14),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x25),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE1_MODE0, 0x5b),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE2_MODE0, 0x02),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CP_CTRL_MODE0, 0x06),
> @@ -1656,7 +1660,7 @@ static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_hbr3[] = {
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_CCTRL_MODE0, 0x36),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CORECLK_DIV_MODE0, 0x0a),
>
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP1_MODE0, 0x17),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP1_MODE0, 0x18),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP2_MODE0, 0x15),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DEC_START_MODE0, 0x4f),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DIV_FRAC_START1_MODE0, 0x00),
> @@ -1675,19 +1679,19 @@ static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_hbr3[] = {
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SYS_CLK_CTRL, 0x02),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SYSCLK_BUF_ENABLE, 0x06),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_IVCO, 0x07),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SYSCLK_EN_SEL, 0x04),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SYSCLK_EN_SEL, 0x3b),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_VCO_TUNE_CTRL, 0x00),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_VCO_TUNE_MAP, 0x00),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CLK_SELECT, 0x30),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CORE_CLK_EN, 0x00),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CMN_CONFIG_1, 0x16),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SVS_MODE_CLK_SEL, 0x15),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CLK_FWD_CONFIG_1, 0x30),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIAS_EN_CLKBUFLR_EN, 0x10),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CLK_FWD_CONFIG_1, 0x3f),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIAS_EN_CLKBUFLR_EN, 0x17),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CMN_MODE_CONTD3, 0x05),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CMN_MODE_CONTD1, 0x24),
> QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_HSCLK_SEL_1, 0x02),
> - QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_IP_CTRL_AND_DP_SEL, 0x84),
> + QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_IP_CTRL_AND_DP_SEL, 0x87),
> };
>
> static const struct qmp_phy_init_tbl sc8280xp_usb43dp_serdes_tbl[] = {
> @@ -3145,6 +3149,30 @@ static int qmp_combo_configure_dp_swing(struct qmp_combo *qmp)
> return 0;
> }
>
> +static bool qmp_v8_combo_configure_dp_mode(struct qmp_combo *qmp)
> +{
> + bool reverse = (qmp->orientation == TYPEC_ORIENTATION_REVERSE);
> + const struct phy_configure_opts_dp *dp_opts = &qmp->dp_opts;
> + u32 val;
> +
> + val = DP_PHY_PD_CTL_PWRDN | DP_PHY_PD_CTL_AUX_PWRDN |
> + DP_PHY_PD_CTL_LANE_0_1_PWRDN | DP_PHY_PD_CTL_LANE_2_3_PWRDN |
> + DP_PHY_PD_CTL_PLL_PWRDN | DP_PHY_PD_CTL_DP_CLAMP_EN;
> +
> + if (dp_opts->lanes == 1 || dp_opts->lanes == 2) {
> + if (reverse)
> + val &= ~DP_PHY_PD_CTL_LANE_2_3_PWRDN;
> + else
> + val &= ~DP_PHY_PD_CTL_LANE_0_1_PWRDN;
> + }
> +
> + writel(val, qmp->dp_dp_phy + QSERDES_DP_PHY_PD_CTL);
> +
> + writel(0x5c, qmp->dp_dp_phy + QSERDES_DP_PHY_MODE);
Are you saying that we don't need to write 0x4c here in case of the
reverse mode? Was that changed and why?
> +
> + return reverse;
> +}
> +
> static void qmp_v3_configure_dp_tx(struct qmp_combo *qmp)
> {
> const struct phy_configure_opts_dp *dp_opts = &qmp->dp_opts;
> @@ -3324,16 +3352,70 @@ static void qmp_v4_dp_aux_init(struct qmp_combo *qmp)
> qmp->dp_dp_phy + QSERDES_V4_DP_PHY_AUX_INTERRUPT_MASK);
> }
>
> +static int qmp_v8_helper_configure_dp_phy(struct qmp_combo *qmp)
> +{
> + const struct qmp_phy_cfg *cfg = qmp->cfg;
> + u32 status;
> + int ret;
> +
> + writel(0x0f, qmp->dp_dp_phy + QSERDES_DP_PHY_CFG_1);
> +
> + qmp_v8_combo_configure_dp_mode(qmp);
> +
> + writel(0x13, qmp->dp_dp_phy + QSERDES_DP_PHY_AUX_CFG1);
> + writel(0xa4, qmp->dp_dp_phy + QSERDES_DP_PHY_AUX_CFG2);
> +
> + writel(0x05, qmp->dp_dp_phy + QSERDES_V4_DP_PHY_TX0_TX1_LANE_CTL);
> + writel(0x05, qmp->dp_dp_phy + QSERDES_V4_DP_PHY_TX2_TX3_LANE_CTL);
> +
> + ret = qmp->cfg->configure_dp_clocks(qmp);
> + if (ret)
> + return ret;
> +
> + writel(0x01, qmp->dp_dp_phy + QSERDES_DP_PHY_CFG);
> + writel(0x05, qmp->dp_dp_phy + QSERDES_DP_PHY_CFG);
> + writel(0x01, qmp->dp_dp_phy + QSERDES_DP_PHY_CFG);
> + writel(0x09, qmp->dp_dp_phy + QSERDES_DP_PHY_CFG);
> +
> + writel(0x20, qmp->dp_serdes + cfg->regs[QPHY_COM_RESETSM_CNTRL]);
> +
> + if (readl_poll_timeout(qmp->dp_serdes + cfg->regs[QPHY_COM_C_READY_STATUS],
> + status,
> + ((status & BIT(0)) > 0),
> + 500,
> + 10000))
> + return -ETIMEDOUT;
> +
> + if (readl_poll_timeout(qmp->dp_serdes + cfg->regs[QPHY_COM_CMN_STATUS],
> + status,
> + ((status & BIT(0)) > 0),
> + 500,
> + 10000))
> + return -ETIMEDOUT;
> +
> + if (readl_poll_timeout(qmp->dp_serdes + cfg->regs[QPHY_COM_CMN_STATUS],
> + status,
> + ((status & BIT(1)) > 0),
> + 500,
> + 10000))
> + return -ETIMEDOUT;
> +
> + return 0;
> +}
> +
> static void qmp_v8_dp_aux_init(struct qmp_combo *qmp)
> {
> const struct qmp_phy_cfg *cfg = qmp->cfg;
>
> - writel(DP_PHY_PD_CTL_PWRDN | DP_PHY_PD_CTL_PSR_PWRDN | DP_PHY_PD_CTL_AUX_PWRDN |
> - DP_PHY_PD_CTL_PLL_PWRDN | DP_PHY_PD_CTL_DP_CLAMP_EN,
> - qmp->dp_dp_phy + QSERDES_DP_PHY_PD_CTL);
> + writel(0x3f, qmp->dp_serdes + QSERDES_V8_USB43_COM_CLK_FWD_CONFIG_1);
> +
> + writel(DP_PHY_PD_CTL_PWRDN | DP_PHY_PD_CTL_AUX_PWRDN |
> + DP_PHY_PD_CTL_LANE_0_1_PWRDN | DP_PHY_PD_CTL_LANE_2_3_PWRDN |
> + DP_PHY_PD_CTL_PLL_PWRDN | DP_PHY_PD_CTL_DP_CLAMP_EN,
> + qmp->dp_dp_phy + QSERDES_DP_PHY_PD_CTL);
No AUX_PWRDN? Why?
>
> /* Turn on BIAS current for PHY/PLL */
> - writel(0x1c, qmp->dp_serdes + cfg->regs[QPHY_COM_BIAS_EN_CLKBUFLR_EN]);
> + writel(0x17, qmp->dp_serdes + cfg->regs[QPHY_COM_BIAS_EN_CLKBUFLR_EN]);
>
> writel(0x00, qmp->dp_dp_phy + QSERDES_DP_PHY_AUX_CFG0);
> writel(0x13, qmp->dp_dp_phy + QSERDES_DP_PHY_AUX_CFG1);
> @@ -3361,8 +3443,8 @@ static void qmp_v4_configure_dp_tx(struct qmp_combo *qmp)
> writel(0x27, qmp->dp_tx + cfg->regs[QPHY_TX_TX_DRV_LVL]);
> writel(0x27, qmp->dp_tx2 + cfg->regs[QPHY_TX_TX_DRV_LVL]);
>
> - writel(0x20, qmp->dp_tx + cfg->regs[QPHY_TX_TX_EMP_POST1_LVL]);
> - writel(0x20, qmp->dp_tx2 + cfg->regs[QPHY_TX_TX_EMP_POST1_LVL]);
> + writel(0x2b, qmp->dp_tx + cfg->regs[QPHY_TX_TX_EMP_POST1_LVL]);
> + writel(0x2b, qmp->dp_tx2 + cfg->regs[QPHY_TX_TX_EMP_POST1_LVL]);
>
> qmp_combo_configure_dp_swing(qmp);
> }
> @@ -3370,48 +3452,41 @@ static void qmp_v4_configure_dp_tx(struct qmp_combo *qmp)
> static int qmp_v8_configure_dp_clocks(struct qmp_combo *qmp)
> {
> const struct phy_configure_opts_dp *dp_opts = &qmp->dp_opts;
> - u32 phy_vco_div;
> unsigned long pixel_freq;
> - const struct qmp_phy_cfg *cfg = qmp->cfg;
>
> switch (dp_opts->link_rate) {
> case 1620:
> - phy_vco_div = 0x4;
> pixel_freq = 1620000000UL / 2;
> break;
> case 2700:
> - phy_vco_div = 0x2;
> pixel_freq = 2700000000UL / 2;
> break;
> case 5400:
> - phy_vco_div = 0x4;
> pixel_freq = 5400000000UL / 4;
> break;
> case 8100:
> - phy_vco_div = 0x3;
> pixel_freq = 8100000000UL / 6;
> break;
> default:
> /* Other link rates aren't supported */
> return -EINVAL;
> }
> - writel(phy_vco_div, qmp->dp_dp_phy + cfg->regs[QPHY_DP_PHY_VCO_DIV]);
Hmm?
>
> /* disable core reset tsync */
> writel(0x09, qmp->dp_dp_phy + QSERDES_DP_PHY_CFG);
>
> - writel(0x04, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_AUXLESS_SETUP_CYC);
> - writel(0x08, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_AUXLESS_SILENCE_CYC);
> + writel(0x09, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_AUXLESS_SETUP_CYC);
> + writel(0x11, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_AUXLESS_SILENCE_CYC);
> writel(0x08, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_LFPS_CYC);
> - writel(0x11, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_LFPS_PERIOD);
> + writel(0x33, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_LFPS_PERIOD);
>
> writel(0x3e, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_TSYNC_OVRD);
> writel(0x05, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_TX2_TX3_LANE_CTL);
> writel(0x05, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_TX0_TX1_LANE_CTL);
> writel(0x01, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_AUXLESS_CFG1);
> - writel(0x11, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_LFPS_PERIOD);
> + writel(0x33, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_LFPS_PERIOD);
> writel(0x1f, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_LN0_DRV_LVL);
> - writel(0x1f, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_LN1_DRV_LVL);
> + writel(0x02, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_LN1_DRV_LVL);
>
> clk_set_rate(qmp->dp_link_hw.clk, dp_opts->link_rate * 100000);
> clk_set_rate(qmp->dp_pixel_hw.clk, pixel_freq);
> @@ -3558,7 +3633,7 @@ static int qmp_v8_configure_dp_phy(struct qmp_combo *qmp)
> u32 status;
> int ret;
>
> - ret = qmp_v456_configure_dp_phy(qmp);
> + ret = qmp_v8_helper_configure_dp_phy(qmp);
> if (ret < 0)
> return ret;
>
> @@ -3570,13 +3645,13 @@ static int qmp_v8_configure_dp_phy(struct qmp_combo *qmp)
> } else if (dp_opts->lanes == 2) {
> bias0_en = reverse ? 0x3f : 0x15;
> bias1_en = reverse ? 0x15 : 0x3f;
> - drvr0_en = 0x10;
> - drvr1_en = 0x10;
> + drvr0_en = 0x30;
> + drvr1_en = 0x30;
> } else {
> bias0_en = 0x3f;
> bias1_en = 0x3f;
> - drvr0_en = 0x34;
> - drvr1_en = 0x34;
> + drvr0_en = 0x30;
> + drvr1_en = 0x30;
> }
>
> writel(drvr0_en, qmp->dp_tx + cfg->regs[QPHY_TX_HIGHZ_DRVR_EN]);
> @@ -3584,6 +3659,14 @@ static int qmp_v8_configure_dp_phy(struct qmp_combo *qmp)
> writel(drvr1_en, qmp->dp_tx2 + cfg->regs[QPHY_TX_HIGHZ_DRVR_EN]);
> writel(bias1_en, qmp->dp_tx2 + cfg->regs[QPHY_TX_TRANSCEIVER_BIAS_EN]);
>
> + writel(0x03, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_TSYNC_OVRD);
> + writel(0x23, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_TSYNC_OVRD);
> + writel(0x22, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_TSYNC_OVRD);
> +
> + writel(0x0a, qmp->dp_tx + QSERDES_V8_LALB_RESET_TSYNC_EN_CTRL);
> + writel(0x0a, qmp->dp_tx2 + QSERDES_V8_LALB_RESET_TSYNC_EN_CTRL);
> +
> + writel(0x3e, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_TSYNC_OVRD);
> writel(0x08, qmp->dp_dp_phy + QSERDES_DP_PHY_CFG);
> udelay(100);
> writel(0x09, qmp->dp_dp_phy + QSERDES_DP_PHY_CFG);
> @@ -3591,16 +3674,24 @@ static int qmp_v8_configure_dp_phy(struct qmp_combo *qmp)
>
> if (readl_poll_timeout(qmp->dp_dp_phy + cfg->regs[QPHY_DP_PHY_STATUS],
> status,
> - ((status & BIT(1)) > 0),
> + ((status & BIT(0)) > 0),
> 500,
> 10000))
> return -ETIMEDOUT;
>
> - writel(0x00, qmp->dp_tx + cfg->regs[QPHY_TX_TX_DRV_LVL]);
> - writel(0x00, qmp->dp_tx2 + cfg->regs[QPHY_TX_TX_DRV_LVL]);
> + if (readl_poll_timeout(qmp->dp_serdes + cfg->regs[QPHY_COM_CMN_STATUS],
> + status,
> + ((status & BIT(0)) > 0),
> + 500,
> + 10000))
> + return -ETIMEDOUT;
>
> - writel(0x2b, qmp->dp_tx + cfg->regs[QPHY_TX_TX_EMP_POST1_LVL]);
> - writel(0x2b, qmp->dp_tx2 + cfg->regs[QPHY_TX_TX_EMP_POST1_LVL]);
> + if (readl_poll_timeout(qmp->dp_serdes + cfg->regs[QPHY_COM_CMN_STATUS],
> + status,
> + ((status & BIT(1)) > 0),
> + 500,
> + 10000))
> + return -ETIMEDOUT;
>
> return 0;
> }
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v8.h b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v8.h
> index d8ac4c4a2c31..b35b486cfa56 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v8.h
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v8.h
> @@ -71,5 +71,7 @@
> #define QSERDES_V8_COM_ADDITIONAL_MISC 0x1b4
> #define QSERDES_V8_COM_CMN_STATUS 0x2c8
> #define QSERDES_V8_COM_C_READY_STATUS 0x2f0
> +#define QSERDES_V8_COM_CMN_STATUS_N3 0x314
> +#define QSERDES_V8_COM_C_READY_STATUS_N3 0x33c
>
> #endif
>
> ---
> base-commit: 1c7cc4904160c6fc6377564140062d68a3dc93a0
> change-id: 20260414-glymur_dp-ffea83a75969
>
> Best regards,
> --
> Mahadevan P <mahadevan.p@oss.qualcomm.com>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 03/10] mfd: qcom_rpm: add msm8960 QDSS clock resource
From: Antony Kurniawan Soemardi @ 2026-04-19 13:02 UTC (permalink / raw)
To: Dmitry Baryshkov, Konrad Dybcio
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio,
Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta
In-Reply-To: <rnpbdbjlpx6wemeuzsm33njmnihhli6mvjzhwu4m64vpgbxait@7pnk2rdt2djk>
On 4/18/2026 11:11 PM, Dmitry Baryshkov wrote:
> On Thu, Apr 16, 2026 at 03:49:33PM +0200, Konrad Dybcio wrote:
>> On 4/15/26 5:20 PM, Antony Kurniawan Soemardi wrote:
>>> On 4/14/2026 3:07 PM, Konrad Dybcio wrote:
>>>> On 4/14/26 10:06 AM, Konrad Dybcio wrote:
>>>>> On 4/13/26 8:55 PM, Antony Kurniawan Soemardi via B4 Relay wrote:
>>>>>> From: Antony Kurniawan Soemardi <linux@smankusors.com>
>>>>>>
>>>>>> msm8960 uses the same clock descriptor as apq8064 but lacked the
>>>>>
>>>>> This doesn't quite seem to be the case, some fields differ and
>>>>> apq8064 additionally has:
>>>>>
>>>>> QCOM_RPM_PM8821_SMPS1
>>>>> QCOM_RPM_PM8821_SMPS2
>>>>> QCOM_RPM_PM8821_LDO1
>>>>> QCOM_RPM_VDDMIN_GPIO
>>>>
>>>> Ah hmm, the MFD driver seems to provide *all* RPM resources..
>>>
>>> What I meant by "clock descriptor" in the commit message was
>>> specifically the subset corresponding to RPM managed clocks. From what I
>>> can tell based on downstream code, msm8960 and apq8064 seem to share the
>>> same set of RPM clocks, even though the overall resource lists differ.
>>>
>>> Is that understanding correct?
>>
>> If that's struct msm_rpm_map_data on msm-3.x, then I see that 8x60 has:
>>
>> +MSM_RPM_MAP(PLL_4, PLL_4, 1),
>> +MSM_RPM_MAP(SMI_CLK, SMI_CLK, 1),
>>
>> While 8960 has:
>> -MSM_RPM_MAP(QDSS_CLK, QDSS_CLK, 1),
>
> You are comparing 8x60 to 8960, while it should be 8960 to 8064.
>
> I see that there are differences, but the QDSS is the same.
I'm looking at downstream code from my Sony Xperia SP (based on
android-msm-mako-3.4 for LG Nexus 4 / APQ8064). Both apq8064 and msm8960
uses the same clock-8960.c file in that tree, including the RPM clock
descriptions, so I assumed their RPM clock sets were identical.
That's why later commit 1da13533627d ("clk: qcom: clk-rpm: add msm8960
compatible") reuses rpm_clk_apq8064 for qcom,rpmcc-msm8960 compatible.
But the problem is rpm_clk_apq8064 includes QDSS, which is not yet
present on msm8960_rpm_resource_table, causing rpmcc init to fail, hence
this patch.
That said, I agree with Dmitry on the other email reply. I will update
the commit message to match with android-msm-mako-3.4 downstream code
instead of claiming both SoC has the same clock descriptions.
--
Thanks,
Antony K. S.
^ permalink raw reply
* Re: [PATCH 06/10] ARM: dts: qcom: msm8960: add SCM
From: Antony Kurniawan Soemardi @ 2026-04-19 13:19 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta
In-Reply-To: <d53f1499-0afc-43e5-bee9-ae76df3c6910@oss.qualcomm.com>
On 4/14/2026 4:46 PM, Konrad Dybcio wrote:
> On 4/13/26 8:55 PM, Antony Kurniawan Soemardi via B4 Relay wrote:
>> From: Antony Kurniawan Soemardi <linux@smankusors.com>
>>
>> Add the Secure Channel Manager firmware device node to the MSM8960
>> device tree. The SCM is required for secure communication between the
>> application processor and other subsystems.
>>
>> Tested-by: Rudraksha Gupta <guptarud@gmail.com>
>> Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
>> ---
>> arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
>> index 1d5e97b6aa4b..bc3fd55e524a 100644
>> --- a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
>> +++ b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
>> @@ -77,6 +77,15 @@ l2: l2-cache {
>> };
>> };
>>
>> + firmware {
>> + scm {
>> + compatible = "qcom,scm-msm8960", "qcom,scm";
>> +
>> + clocks = <&rpmcc RPM_DAYTONA_FABRIC_CLK>;
>
> I'm wondering if this should be an interconnect resource, but from a
> quick grepping, I think this is always supposed to be @ 64 MHz so
> perhaps not really
>
> (please tell me if you know more)
Unfortunately I don't know either, this was ported as is from
qcom-apq8064.dtsi.
--
Thanks,
Antony K. S.
^ permalink raw reply
* Re: [PATCH v2 3/3] misc: Remove old APDS990x driver
From: Jonathan Cameron @ 2026-04-19 13:33 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419083125.35572-4-clamor95@gmail.com>
On Sun, 19 Apr 2026 11:31:24 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> The Avago APDS9900/9901 ALS/Proximity sensor is now supported by tsl2772
> IIO driver so there is no need to keep this old implementation. Remove it.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> Documentation/misc-devices/apds990x.rst | 128 ---
Sashiko AI reviewing is now running on anything that hits linux-iio@vger.kernel.org
I'm slowly getting into the habit of checking out what it finds though
I'm 500+ emails behind so it might not be that thorough today :*
Anyhow, it caught an easy one here.
This file is referenced from Documentation/misc-devices/index.rst
so that needs an update as well.
There is the obvious point of ABI compatibility raised as well, but given
we don't seem to be getting much push back on that maybe that's not a significant
concern.
Jonathan
> drivers/misc/Kconfig | 10 -
> drivers/misc/Makefile | 1 -
> drivers/misc/apds990x.c | 1284 -----------------------
> include/linux/platform_data/apds990x.h | 65 --
> 5 files changed, 1488 deletions(-)
> delete mode 100644 Documentation/misc-devices/apds990x.rst
> delete mode 100644 drivers/misc/apds990x.c
> delete mode 100644 include/linux/platform_data/apds990x.h
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Jonathan Cameron @ 2026-04-19 13:37 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419083125.35572-3-clamor95@gmail.com>
On Sun, 19 Apr 2026 11:31:23 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
A Sashiko review comment makes me wonder about one thing below if the
register set does match. Maybe it's a bit more subtle than this
patch description suggests?
> just add the correct bindings and the appropriate LUX table derived from
> the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> index c8f15ba95267..8dab34bf00ca 100644
> --- a/drivers/iio/light/tsl2772.c
> +++ b/drivers/iio/light/tsl2772.c
> @@ -127,6 +127,7 @@ enum {
> tmd2672,
> tsl2772,
> tmd2772,
> + apds990x,
> apds9930,
> };
>
> @@ -221,6 +222,12 @@ static const struct tsl2772_lux tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> { 0, 0 },
> };
>
> +static const struct tsl2772_lux apds990x_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> + { 52000, 115960 },
> + { 36400, 73840 },
> + { 0, 0 },
> +};
> +
> static const struct tsl2772_lux apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> { 52000, 96824 },
> { 38792, 67132 },
> @@ -238,6 +245,7 @@ static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> [tmd2672] = tmd2x72_lux_table,
> [tsl2772] = tsl2x72_lux_table,
> [tmd2772] = tmd2x72_lux_table,
> + [apds990x] = apds990x_lux_table,
> [apds9930] = apds9930_lux_table,
> };
>
> @@ -289,6 +297,7 @@ static const int tsl2772_int_time_avail[][6] = {
> [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> + [apds990x] = { 0, 2720, 0, 2720, 0, 696000 },
> [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> };
>
> @@ -316,6 +325,7 @@ static const u8 device_channel_config[] = {
> [tmd2672] = PRX2,
> [tsl2772] = ALSPRX2,
> [tmd2772] = ALSPRX2,
> + [apds990x] = ALSPRX,
This is different from tsl2772?
> [apds9930] = ALSPRX2,
> };
^ permalink raw reply
* Re: [PATCH 08/10] ARM: dts: qcom: msm8960: add SMSM & SPS
From: Antony Kurniawan Soemardi @ 2026-04-19 13:41 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio,
Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta
In-Reply-To: <u7buljdmiu2kf5unlqs2jh5u24ymteyrfvbb2drc6ntsei2mqq@yuhjpchgpgh3>
On 4/18/2026 11:53 PM, Dmitry Baryshkov wrote:
> On Tue, Apr 14, 2026 at 01:55:35AM +0700, Antony Kurniawan Soemardi via B4 Relay wrote:
>> From: Antony Kurniawan Soemardi <linux@smankusors.com>
>>
>> Add the Shared Memory State Machine node to coordinate state transitions
>> between the Applications processor and the Riva subsystem.
>>
>> Tested-by: Rudraksha Gupta <guptarud@gmail.com>
>> Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
>> ---
>> arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 30 ++++++++++++++++++++++++++++++
>> 1 file changed, 30 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
>> index 218cf3158dfb..107c5613aa4a 100644
>> --- a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
>> +++ b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
>> @@ -109,6 +109,31 @@ smem {
>> hwlocks = <&sfpb_mutex 3>;
>> };
>>
>> + smsm {
>> + compatible = "qcom,smsm";
>> +
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + qcom,ipc-1 = <&l2cc 8 4>;
>> + qcom,ipc-2 = <&l2cc 8 14>;
>> + qcom,ipc-3 = <&l2cc 8 23>;
>> + qcom,ipc-4 = <&sps_sic_non_secure 0x4094 0>;
>> +
>> + apps_smsm: apps@0 {
>> + reg = <0>;
>> + #qcom,smem-state-cells = <1>;
>> + };
>> +
>> + wcnss_smsm: wcnss@3 {
>> + reg = <3>;
>> + interrupts = <GIC_SPI 204 IRQ_TYPE_EDGE_RISING>;
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + };
>
> Are there other SMSMs (modem, Q6, DSPS)? If so and if you are going to
> send another revision, could you please add those?
Yes there are. But I've intentionally left them out for now since
they're unrelated to this Wi-Fi enablement series and I currently have
no way to test them without bringing up the modem, audio, and/or video
subsystems first.
I think it's cleaner to keep this series focused on what's verifiable
today and handle the rest in a future separate series. What do you
think?
--
Thanks,
Antony K. S.
^ permalink raw reply
* Re: [PATCH v2 3/3] misc: Remove old APDS990x driver
From: Svyatoslav Ryhel @ 2026-04-19 13:41 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419143346.45ed78c2@jic23-huawei>
нд, 19 квіт. 2026 р. о 16:33 Jonathan Cameron <jic23@kernel.org> пише:
>
> On Sun, 19 Apr 2026 11:31:24 +0300
> Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > The Avago APDS9900/9901 ALS/Proximity sensor is now supported by tsl2772
> > IIO driver so there is no need to keep this old implementation. Remove it.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > Documentation/misc-devices/apds990x.rst | 128 ---
> Sashiko AI reviewing is now running on anything that hits linux-iio@vger.kernel.org
>
> I'm slowly getting into the habit of checking out what it finds though
> I'm 500+ emails behind so it might not be that thorough today :*
>
> Anyhow, it caught an easy one here.
>
> This file is referenced from Documentation/misc-devices/index.rst
> so that needs an update as well.
>
Good catch, index was not updated, I will do so in v3.
> There is the obvious point of ABI compatibility raised as well, but given
> we don't seem to be getting much push back on that maybe that's not a significant
> concern.
I did not found any ABI in the Documentation/ABI regarding this sensor
using grep, maybe you are more familiar?
>
> Jonathan
>
> > drivers/misc/Kconfig | 10 -
> > drivers/misc/Makefile | 1 -
> > drivers/misc/apds990x.c | 1284 -----------------------
> > include/linux/platform_data/apds990x.h | 65 --
> > 5 files changed, 1488 deletions(-)
> > delete mode 100644 Documentation/misc-devices/apds990x.rst
> > delete mode 100644 drivers/misc/apds990x.c
> > delete mode 100644 include/linux/platform_data/apds990x.h
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Svyatoslav Ryhel @ 2026-04-19 13:46 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419143751.11ec0b69@jic23-huawei>
нд, 19 квіт. 2026 р. о 16:38 Jonathan Cameron <jic23@kernel.org> пише:
>
> On Sun, 19 Apr 2026 11:31:23 +0300
> Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
>
> A Sashiko review comment makes me wonder about one thing below if the
> register set does match. Maybe it's a bit more subtle than this
> patch description suggests?
>
> > just add the correct bindings and the appropriate LUX table derived from
> > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > index c8f15ba95267..8dab34bf00ca 100644
> > --- a/drivers/iio/light/tsl2772.c
> > +++ b/drivers/iio/light/tsl2772.c
> > @@ -127,6 +127,7 @@ enum {
> > tmd2672,
> > tsl2772,
> > tmd2772,
> > + apds990x,
> > apds9930,
> > };
> >
> > @@ -221,6 +222,12 @@ static const struct tsl2772_lux tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > { 0, 0 },
> > };
> >
> > +static const struct tsl2772_lux apds990x_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > + { 52000, 115960 },
> > + { 36400, 73840 },
> > + { 0, 0 },
> > +};
> > +
> > static const struct tsl2772_lux apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > { 52000, 96824 },
> > { 38792, 67132 },
> > @@ -238,6 +245,7 @@ static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> > [tmd2672] = tmd2x72_lux_table,
> > [tsl2772] = tsl2x72_lux_table,
> > [tmd2772] = tmd2x72_lux_table,
> > + [apds990x] = apds990x_lux_table,
> > [apds9930] = apds9930_lux_table,
> > };
> >
> > @@ -289,6 +297,7 @@ static const int tsl2772_int_time_avail[][6] = {
> > [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> > [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > + [apds990x] = { 0, 2720, 0, 2720, 0, 696000 },
> > [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> > };
> >
> > @@ -316,6 +325,7 @@ static const u8 device_channel_config[] = {
> > [tmd2672] = PRX2,
> > [tsl2772] = ALSPRX2,
> > [tmd2772] = ALSPRX2,
> > + [apds990x] = ALSPRX,
>
> This is different from tsl2772?
yes, lux table is different and made according to datasheet,
tsl2772_int_time_avail differs, ALSPRX configuration assumes that
proximity sensor needs no calibration which is true for apds9900/1
while tsl2772 needs calibration, device ID is different 0x20/0x29 for
apds and 0x30 for tsl2772
>
> > [apds9930] = ALSPRX2,
> > };
>
^ permalink raw reply
* Re: [PATCH v2 3/4] staging: iio: magnetometer: Add QST QMC5883P driver
From: Hardik Phalet @ 2026-04-19 14:30 UTC (permalink / raw)
To: David Lechner, Hardik Phalet, Greg Kroah-Hartman
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Brigham Campbell, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-staging
In-Reply-To: <2d966423-52b5-4b8a-a4d1-0edcd93a841b@baylibre.com>
On Mon Apr 13, 2026 at 12:22 AM IST, David Lechner wrote:
> On 4/12/26 4:54 AM, Hardik Phalet wrote:
>> On Sat Apr 11, 2026 at 1:32 AM IST, David Lechner wrote:
>>> On 4/9/26 4:07 PM, Hardik Phalet wrote:
>>>
>>> This is a little bit much to review all in one patch. Could be nice
>>> to split out power management to a separate patch.
>>>
>
> ...
>
>>>> +static IIO_DEVICE_ATTR(downsampling_ratio, 0644, downsampling_ratio_show,
>>>> + downsampling_ratio_store, 0);
>>>> +static IIO_CONST_ATTR(downsampling_ratio_available, "1 2 4 8");
>>>
>>> As mentioned in the cover letter, we'd like to know more about what
>>> this actually does. If there is a good reason it doesn't fit with
>>> any existing filter attribute, then we'll need a patch to document
>>> the sysfs ABI as well.
>>>
>> In the device datasheet, OSR2("Down sampling ratio") is mentioned like this:
>> "Another filter is added for better noise performance; the depth can be
>> adjusted through OSR2". OSR2's defintion is called "down sampling ratio"
>> in a table. Nowhere else. I didn't know what attribute to map it to in
>> this case.
>>
> I wonder if there is an application note or something that explains it
> in more detail if the datasheet does not.
>
I could not find any mention of it, in an application note or otherwise.
I cannot confirm what this does, unless I get an oscilloscope and figure
it out.
> We could always omit the feature if no one knows what it actually does.
Yes that's what I am planning to do.
Regards,
Hardik
^ permalink raw reply
* [PATCH] arm64: dts: amlogic: add support for Amedia X98Q
From: christian.koever-draxl @ 2026-04-19 15:08 UTC (permalink / raw)
To: neil.armstrong, khilman
Cc: linux-amlogic, devicetree, linux-arm-kernel,
Christian Stefan Kövér-Draxl
From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
The X98Q is a TV box based on the Amlogic S4 (S905W2) SoC.
Add the device tree for this board and document the compatible string.
Supported features:
- 1GB/2GB RAM (via U-Boot memory fixup)
- 10/100 Ethernet (Internal PHY)
- eMMC and SD card storage
- PWM-based CPU voltage regulation
- UART (Serial console)
Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
---
- The Wi-Fi chip on this board is Amlogic W150S1. I have left the SDIO node enabled
but omitted the specific chip sub-node due to lack of mainline drivers (yet).
- The console uses uart_b at 921600 baud.
- Verified memory via /proc/device-tree; U-Boot patches the node to around 2GB if board supports more than 1GB.
- Tested on the 2GB RAM plus 16GB EMMC variant.
.../devicetree/bindings/arm/amlogic.yaml | 7 +
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 244 ++++++++++++++++++
3 files changed, 252 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index a885278bc4e2..82671d58d1da 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -254,6 +254,13 @@ properties:
- khadas,vim1s
- const: amlogic,s905y4
- const: amlogic,s4
+
+ - description: Boards with the Amlogic Meson S4 S905W2 SoC
+ items:
+ - enum:
+ - amediatech,x98q
+ - const: amlogic,s905w2
+ - const: amlogic,s4
- description: Boards with the Amlogic S6 S905X5 SoC
items:
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 15f9c817e502..6f0bdd5bdca2 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -86,6 +86,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-s4-s805x2-aq222.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905y4-khadas-vim1s.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905w2-x98q.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air-gbit.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-bananapi-m2-pro.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
new file mode 100644
index 000000000000..f2db01730a3d
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
@@ -0,0 +1,244 @@
+
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2026 Christian Stefan Köver-Draxl
+ */
+
+/dts-v1/;
+
+#include "meson-s4.dtsi"
+
+/ {
+ model = "Shenzhen Amedia X98Q";
+ compatible = "amediatech,x98q", "amlogic,s905w2", "amlogic,s4";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ mmc0 = &emmc; /* eMMC */
+ mmc1 = &sd; /* SD card */
+ mmc2 = &sdio; /* SDIO */
+ serial0 = &uart_b;
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x40000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 52 MiB reserved for ARM Trusted Firmware */
+ secmon_reserved: secmon@5000000 {
+ reg = <0x0 0x05000000 0x0 0x3400000>;
+ no-map;
+ };
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio GPIOB_9 GPIO_ACTIVE_LOW>;
+ };
+
+ sdio_32k: sdio-32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <&sdio_32k>;
+ clock-names = "ext_clock";
+ };
+
+ main_5v: regulator-main-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ sd_3v3: regulator-sd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "SD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio GPIOD_4 GPIO_ACTIVE_LOW>;
+ regulator-always-on;
+ };
+
+ vddio_sd: regulator-vddio-sd {
+ compatible = "regulator-gpio";
+ regulator-name = "VDDIO_SD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <1800000 1
+ 3300000 0>;
+ };
+
+ vddao_3v3: regulator-vddao-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&main_5v>;
+ regulator-always-on;
+ };
+
+ vddio_ao1v8: regulator-vddio-ao1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vddao_3v3>;
+ regulator-always-on;
+ };
+
+ /* SY8120B1ABC DC/DC Regulator. */
+ vddcpu: regulator-vddcpu {
+ compatible = "pwm-regulator";
+
+ regulator-name = "VDDCPU";
+ regulator-min-microvolt = <689000>;
+ regulator-max-microvolt = <1049000>;
+
+ vin-supply = <&main_5v>;
+
+ pwms = <&pwm_ij 1 1500 0>;
+ pwm-dutycycle-range = <100 0>;
+
+ regulator-boot-on;
+ regulator-always-on;
+ /* Voltage Duty-Cycle */
+ voltage-table = <1049000 0>,
+ <1039000 3>,
+ <1029000 6>,
+ <1019000 9>,
+ <1009000 12>,
+ <999000 14>,
+ <989000 17>,
+ <979000 20>,
+ <969000 23>,
+ <959000 26>,
+ <949000 29>,
+ <939000 31>,
+ <929000 34>,
+ <919000 37>,
+ <909000 40>,
+ <899000 43>,
+ <889000 45>,
+ <879000 48>,
+ <869000 51>,
+ <859000 54>,
+ <849000 56>,
+ <839000 59>,
+ <829000 62>,
+ <819000 65>,
+ <809000 68>,
+ <799000 70>,
+ <789000 73>,
+ <779000 76>,
+ <769000 79>,
+ <759000 81>,
+ <749000 84>,
+ <739000 87>,
+ <729000 89>,
+ <719000 92>,
+ <709000 95>,
+ <699000 98>,
+ <689000 100>;
+ };
+};
+
+&emmc {
+ status = "okay";
+ pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
+ pinctrl-1 = <&emmc_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_ao1v8>;
+};
+
+ðmac {
+ status = "okay";
+ phy-handle = <&internal_ephy>;
+ phy-mode = "rmii";
+};
+
+&ir {
+ status = "okay";
+ pinctrl-0 = <&remote_pins>;
+ pinctrl-names = "default";
+};
+
+&pwm_ef {
+ status = "okay";
+ pinctrl-0 = <&pwm_e_pins1>;
+ pinctrl-names = "default";
+};
+
+&pwm_ij {
+ status = "okay";
+};
+
+&sd {
+ status = "okay";
+ pinctrl-0 = <&sdcard_pins>;
+ pinctrl-1 = <&sdcard_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <50000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddao_3v3>;
+};
+
+&sdio {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-1 = <&sdio_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+
+ no-sd;
+ no-mmc;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_ao1v8>;
+};
+
+&uart_b {
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] arm64: dts: amlogic: add support for Amedia X98Q
From: Ferass El Hafidi @ 2026-04-19 15:19 UTC (permalink / raw)
To: linux-amlogic, christian.koever-draxl, neil.armstrong, khilman
Cc: linux-amlogic, devicetree, linux-arm-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260419150855.121136-1-christian.koever-draxl@student.uibk.ac.at>
Hi, some drive-by feedback
On Sun, 19 Apr 2026 15:08, christian.koever-draxl@student.uibk.ac.at wrote:
>From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
>The X98Q is a TV box based on the Amlogic S4 (S905W2) SoC.
>Add the device tree for this board and document the compatible string.
>
>Supported features:
>- 1GB/2GB RAM (via U-Boot memory fixup)
>- 10/100 Ethernet (Internal PHY)
>- eMMC and SD card storage
>- PWM-based CPU voltage regulation
>- UART (Serial console)
>
>Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>---
>- The Wi-Fi chip on this board is Amlogic W150S1. I have left the SDIO node enabled
> but omitted the specific chip sub-node due to lack of mainline drivers (yet).
>- The console uses uart_b at 921600 baud.
>- Verified memory via /proc/device-tree; U-Boot patches the node to around 2GB if board supports more than 1GB.
>- Tested on the 2GB RAM plus 16GB EMMC variant.
>
> .../devicetree/bindings/arm/amlogic.yaml | 7 +
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 244 ++++++++++++++++++
> 3 files changed, 252 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>
>diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
>index a885278bc4e2..82671d58d1da 100644
>--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
>+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
>@@ -254,6 +254,13 @@ properties:
> - khadas,vim1s
> - const: amlogic,s905y4
> - const: amlogic,s4
>+
>+ - description: Boards with the Amlogic Meson S4 S905W2 SoC
>+ items:
>+ - enum:
>+ - amediatech,x98q
>+ - const: amlogic,s905w2
>+ - const: amlogic,s4
>
> - description: Boards with the Amlogic S6 S905X5 SoC
> items:
It is better to send the dt-binding changes separate from the actual
DTS. The golden rule is one commit per change.
You can (and should) send both patches as part of a patch series.
>diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
>index 15f9c817e502..6f0bdd5bdca2 100644
>--- a/arch/arm64/boot/dts/amlogic/Makefile
>+++ b/arch/arm64/boot/dts/amlogic/Makefile
>@@ -86,6 +86,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-s4-s805x2-aq222.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905y4-khadas-vim1s.dtb
>+dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905w2-x98q.dtb
Keep this file in alphabetic order.
> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air-gbit.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-bananapi-m2-pro.dtb
>diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>new file mode 100644
>index 000000000000..f2db01730a3d
>--- /dev/null
>+++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>@@ -0,0 +1,244 @@
>+
>+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>+/*
>+ * Copyright (c) 2026 Christian Stefan Köver-Draxl
>+ */
Did you base this DTS on another DTS that is already upstream? This
looks a lot like
https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts?h=v7.1/arm64-dt
If so, then you should keep their copyright. Something like:
/*
* Copyright (c) 2026 Christian Stefan Köver-Draxl
* Based on <...>:
* - Copyright (c) <authors of the DTB this one is based on>
*/
Correct me if I'm wrong.
>+
>+/dts-v1/;
>+
>+#include "meson-s4.dtsi"
>+
>+/ {
>+ model = "Shenzhen Amedia X98Q";
Shouldn't this be
model = "Shenzhen Amediatech Technology Co., Ltd X98Q";
?
There are other Amediatech boards supported currently:
dts/amlogic/meson-g12a-x96-max.dts: model = "Shenzhen Amediatech Technology Co., Ltd X96 Max";
dts/amlogic/meson-sm1-x96-air-gbit.dts: model = "Shenzhen Amediatech Technology Co., Ltd X96 Air";
dts/amlogic/meson-sm1-x96-air.dts: model = "Shenzhen Amediatech Technology Co., Ltd X96 Air";
I think it might be preferable to use a similar model format for
consistency.
It is also the documented vendor prefix for amediatech. (see
Documentation/devicetree/bindings/vendor-prefixes.yaml)
>+ compatible = "amediatech,x98q", "amlogic,s905w2", "amlogic,s4";
>+ interrupt-parent = <&gic>;
>+ #address-cells = <2>;
>+ #size-cells = <2>;
>+
>+ aliases {
>+ mmc0 = &emmc; /* eMMC */
>+ mmc1 = &sd; /* SD card */
>+ mmc2 = &sdio; /* SDIO */
>+ serial0 = &uart_b;
>+ };
>+
>+ memory@0 {
>+ device_type = "memory";
>+ reg = <0x0 0x0 0x0 0x40000000>;
>+ };
>+
>+ reserved-memory {
>+ #address-cells = <2>;
>+ #size-cells = <2>;
>+ ranges;
>+
>+ /* 52 MiB reserved for ARM Trusted Firmware */
>+ secmon_reserved: secmon@5000000 {
>+ reg = <0x0 0x05000000 0x0 0x3400000>;
>+ no-map;
>+ };
>+ };
>+
>+ emmc_pwrseq: emmc-pwrseq {
>+ compatible = "mmc-pwrseq-emmc";
>+ reset-gpios = <&gpio GPIOB_9 GPIO_ACTIVE_LOW>;
>+ };
>+
>+ sdio_32k: sdio-32k {
>+ compatible = "pwm-clock";
>+ #clock-cells = <0>;
>+ clock-frequency = <32768>;
>+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
>+ };
>+
>+ sdio_pwrseq: sdio-pwrseq {
>+ compatible = "mmc-pwrseq-simple";
>+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
>+ clocks = <&sdio_32k>;
>+ clock-names = "ext_clock";
>+ };
>+
>+ main_5v: regulator-main-5v {
>+ compatible = "regulator-fixed";
>+ regulator-name = "5V";
>+ regulator-min-microvolt = <5000000>;
>+ regulator-max-microvolt = <5000000>;
>+ regulator-always-on;
>+ };
>+
>+ sd_3v3: regulator-sd-3v3 {
>+ compatible = "regulator-fixed";
>+ regulator-name = "SD_3V3";
>+ regulator-min-microvolt = <3300000>;
>+ regulator-max-microvolt = <3300000>;
>+ gpio = <&gpio GPIOD_4 GPIO_ACTIVE_LOW>;
>+ regulator-always-on;
>+ };
>+
>+ vddio_sd: regulator-vddio-sd {
>+ compatible = "regulator-gpio";
>+ regulator-name = "VDDIO_SD";
>+ regulator-min-microvolt = <1800000>;
>+ regulator-max-microvolt = <3300000>;
>+ gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
>+ gpios-states = <1>;
>+ states = <1800000 1
>+ 3300000 0>;
nit: keep this in one line.
>+ };
>+
>+ vddao_3v3: regulator-vddao-3v3 {
>+ compatible = "regulator-fixed";
>+ regulator-name = "VDDAO_3V3";
>+ regulator-min-microvolt = <3300000>;
>+ regulator-max-microvolt = <3300000>;
>+ vin-supply = <&main_5v>;
>+ regulator-always-on;
>+ };
>+
>+ vddio_ao1v8: regulator-vddio-ao1v8 {
>+ compatible = "regulator-fixed";
>+ regulator-name = "VDDIO_AO1V8";
>+ regulator-min-microvolt = <1800000>;
>+ regulator-max-microvolt = <1800000>;
>+ vin-supply = <&vddao_3v3>;
>+ regulator-always-on;
>+ };
>+
>+ /* SY8120B1ABC DC/DC Regulator. */
>+ vddcpu: regulator-vddcpu {
>+ compatible = "pwm-regulator";
>+
>+ regulator-name = "VDDCPU";
>+ regulator-min-microvolt = <689000>;
>+ regulator-max-microvolt = <1049000>;
>+
>+ vin-supply = <&main_5v>;
>+
>+ pwms = <&pwm_ij 1 1500 0>;
>+ pwm-dutycycle-range = <100 0>;
>+
>+ regulator-boot-on;
>+ regulator-always-on;
>+ /* Voltage Duty-Cycle */
>+ voltage-table = <1049000 0>,
>+ <1039000 3>,
>+ <1029000 6>,
>+ <1019000 9>,
>+ <1009000 12>,
>+ <999000 14>,
>+ <989000 17>,
>+ <979000 20>,
>+ <969000 23>,
>+ <959000 26>,
>+ <949000 29>,
>+ <939000 31>,
>+ <929000 34>,
>+ <919000 37>,
>+ <909000 40>,
>+ <899000 43>,
>+ <889000 45>,
>+ <879000 48>,
>+ <869000 51>,
>+ <859000 54>,
>+ <849000 56>,
>+ <839000 59>,
>+ <829000 62>,
>+ <819000 65>,
>+ <809000 68>,
>+ <799000 70>,
>+ <789000 73>,
>+ <779000 76>,
>+ <769000 79>,
>+ <759000 81>,
>+ <749000 84>,
>+ <739000 87>,
>+ <729000 89>,
>+ <719000 92>,
>+ <709000 95>,
>+ <699000 98>,
>+ <689000 100>;
>+ };
>+};
>+
>+&emmc {
>+ status = "okay";
>+ pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
>+ pinctrl-1 = <&emmc_clk_gate_pins>;
>+ pinctrl-names = "default", "clk-gate";
>+
>+ bus-width = <8>;
>+ cap-mmc-highspeed;
>+ mmc-ddr-1_8v;
>+ mmc-hs200-1_8v;
>+ max-frequency = <200000000>;
>+ non-removable;
>+ disable-wp;
>+
>+ mmc-pwrseq = <&emmc_pwrseq>;
>+ vmmc-supply = <&vddao_3v3>;
>+ vqmmc-supply = <&vddio_ao1v8>;
>+};
>+
>+ðmac {
>+ status = "okay";
>+ phy-handle = <&internal_ephy>;
>+ phy-mode = "rmii";
>+};
>+
>+&ir {
>+ status = "okay";
>+ pinctrl-0 = <&remote_pins>;
>+ pinctrl-names = "default";
>+};
>+
>+&pwm_ef {
>+ status = "okay";
>+ pinctrl-0 = <&pwm_e_pins1>;
>+ pinctrl-names = "default";
>+};
>+
>+&pwm_ij {
>+ status = "okay";
>+};
>+
>+&sd {
>+ status = "okay";
>+ pinctrl-0 = <&sdcard_pins>;
>+ pinctrl-1 = <&sdcard_clk_gate_pins>;
>+ pinctrl-names = "default", "clk-gate";
>+ bus-width = <4>;
>+ cap-sd-highspeed;
>+ max-frequency = <50000000>;
>+ disable-wp;
>+
>+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
>+
>+ vmmc-supply = <&vddao_3v3>;
>+ vqmmc-supply = <&vddao_3v3>;
>+};
>+
>+&sdio {
>+ status = "okay";
>+ pinctrl-0 = <&sdio_pins>;
>+ pinctrl-1 = <&sdio_clk_gate_pins>;
>+ pinctrl-names = "default", "clk-gate";
>+ #address-cells = <1>;
>+ #size-cells = <0>;
>+ bus-width = <4>;
>+ cap-sd-highspeed;
>+ sd-uhs-sdr50;
>+ sd-uhs-sdr104;
>+ max-frequency = <200000000>;
>+ non-removable;
>+ disable-wp;
>+
>+ no-sd;
>+ no-mmc;
>+ mmc-pwrseq = <&sdio_pwrseq>;
>+ vmmc-supply = <&vddao_3v3>;
>+ vqmmc-supply = <&vddio_ao1v8>;
>+};
I suppose that's the Wi-Fi module you're talking about. I would put a comment
above to specify that it is indeed Wi-Fi and not yet supported.
Something like:
/*
* Wireless SDIO Module (Amlogic W150S1)
* Note: There is no driver for this at the moment.
*/
>+
>+&uart_b {
>+ status = "okay";
>+};
>--
>2.53.0
--
Best regards,
Ferass
^ permalink raw reply
* Re: [PATCH] arm64: dts: amlogic: add support for Amedia X98Q
From: Ferass El Hafidi @ 2026-04-19 15:42 UTC (permalink / raw)
To: linux-amlogic, christian.koever-draxl, neil.armstrong, khilman
Cc: linux-amlogic, devicetree, linux-arm-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260419150855.121136-1-christian.koever-draxl@student.uibk.ac.at>
On Sun, 19 Apr 2026 15:08, christian.koever-draxl@student.uibk.ac.at wrote:
>From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
>The X98Q is a TV box based on the Amlogic S4 (S905W2) SoC.
>Add the device tree for this board and document the compatible string.
>
>Supported features:
>- 1GB/2GB RAM (via U-Boot memory fixup)
>- 10/100 Ethernet (Internal PHY)
>- eMMC and SD card storage
>- PWM-based CPU voltage regulation
>- UART (Serial console)
>
>Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>---
>- The Wi-Fi chip on this board is Amlogic W150S1. I have left the SDIO node enabled
> but omitted the specific chip sub-node due to lack of mainline drivers (yet).
>- The console uses uart_b at 921600 baud.
>- Verified memory via /proc/device-tree; U-Boot patches the node to around 2GB if board supports more than 1GB.
>- Tested on the 2GB RAM plus 16GB EMMC variant.
>
Also, I just noticed now, but you seem to be missing a lot of people in
your To/Cc. You should use get_maintainer.pl to get the list of
the people you should send your patch to.
(you can also use b4 (v0.14 is what I use) to make sending patches
properly much easier)
--
Best regards,
Ferass
^ permalink raw reply
* Re: [PATCH 2/2] iio: dac: mcp47feb02: add MCP48FEB02 SPI driver to MCP47FEB02 I2C driver
From: Jonathan Cameron @ 2026-04-19 16:16 UTC (permalink / raw)
To: Ariana Lazar
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron, Conor Dooley,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20260403-mcp47feb02-fix2-v1-2-da60c773550e@microchip.com>
On Fri, 3 Apr 2026 13:50:14 +0300
Ariana Lazar <ariana.lazar@microchip.com> wrote:
> This is the iio driver for Microchip MCP48FxBy1/2/4/8 series of
> buffered voltage output Digital-to-Analog Converters with nonvolatile or
> volatile memory on top of MCP47FEB02. The families support up to 8
> output channels and have 8-bit, 10-bit or 12-bit resolution.
>
> The MCP47FEB02 driver was split into three modules: mcp47feb02-core.c,
> mcp47feb02-i2c.c and mcp47feb02-spi.c in order to support both DAC families
> - I2C (MCP47F(E/V)BXX) and SPI (MCP48F(E/V)BXX).
Normal flow is to do a noop refactor for I2C + core split, then a follow
up patch to add anything new (SPI driver + any changes that are only needed
by SPI to the core module)
>
> Fixes: bf394cc80369 ("iio: dac: adding support for Microchip MCP47FEB02")
> Signed-off-by: Ariana Lazar <ariana.lazar@microchip.com>
> Link: https://lore.kernel.org/all/aY4yaVP2TQFRI1E4@smile.fi.intel.com/
> ---
> MAINTAINERS | 4 +
> drivers/iio/dac/Kconfig | 29 +-
> drivers/iio/dac/Makefile | 3 +
> drivers/iio/dac/mcp47feb02-core.c | 845 ++++++++++++++++++++++++++++++++++++++
> drivers/iio/dac/mcp47feb02-i2c.c | 145 +++++++
> drivers/iio/dac/mcp47feb02-spi.c | 145 +++++++
> drivers/iio/dac/mcp47feb02.h | 158 +++++++
Given the description I'm a bit lost on why there isn't a mass of code being
removed from mcp47feb02.c as it migrates to the core library.
Anyhow one thing I noticed whilst glancing through this.
> 7 files changed, 1328 insertions(+), 1 deletion(-)
> diff --git a/drivers/iio/dac/mcp47feb02-spi.c b/drivers/iio/dac/mcp47feb02-spi.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..82e99388ac75860d534d0f2cc05dcc6628d96f6b
> --- /dev/null
> +++ b/drivers/iio/dac/mcp47feb02-spi.c
> @@ -0,0 +1,145 @@
> +
> +static struct spi_driver mcp47feb02_spi_driver = {
> + .driver = {
> + .name = "mcp47feb02",
> + .of_match_table = mcp47feb02_of_spi_match,
As attempting to align = is already broken, that is pretty strong example
for why it is rarely worth the pain. I'd just use a single space before the =
in all cases.
> + .pm = pm_sleep_ptr(&mcp47feb02_pm_ops),
> + },
> + .probe = mcp47feb02_spi_probe,
> + .id_table = mcp47feb02_spi_id,
> +};
> +module_spi_driver(mcp47feb02_spi_driver);
^ permalink raw reply
* Re: [PATCH v2 3/3] misc: Remove old APDS990x driver
From: Jonathan Cameron @ 2026-04-19 16:22 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <CAPVz0n1qrSYr16zSSqRHuTWVkRfdC+c9w+mxAhtzgfHzL41XFw@mail.gmail.com>
On Sun, 19 Apr 2026 16:41:24 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> нд, 19 квіт. 2026 р. о 16:33 Jonathan Cameron <jic23@kernel.org> пише:
> >
> > On Sun, 19 Apr 2026 11:31:24 +0300
> > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > > The Avago APDS9900/9901 ALS/Proximity sensor is now supported by tsl2772
> > > IIO driver so there is no need to keep this old implementation. Remove it.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > > Documentation/misc-devices/apds990x.rst | 128 ---
> > Sashiko AI reviewing is now running on anything that hits linux-iio@vger.kernel.org
> >
> > I'm slowly getting into the habit of checking out what it finds though
> > I'm 500+ emails behind so it might not be that thorough today :*
> >
> > Anyhow, it caught an easy one here.
> >
> > This file is referenced from Documentation/misc-devices/index.rst
> > so that needs an update as well.
> >
>
> Good catch, index was not updated, I will do so in v3.
>
> > There is the obvious point of ABI compatibility raised as well, but given
> > we don't seem to be getting much push back on that maybe that's not a significant
> > concern.
>
> I did not found any ABI in the Documentation/ABI regarding this sensor
> using grep, maybe you are more familiar?
Doesn't matter if it's documented explicitly (many older drivers are not).
The question is whether anyone has supported parts and userspace code that
makes use of the sysfs files this driver provides.
Their userspace will be broken by dropping it. The lack of upstream users
makes this less critical but it can be argued it's still a possible regression.
Jonathan
>
> >
> > Jonathan
> >
> > > drivers/misc/Kconfig | 10 -
> > > drivers/misc/Makefile | 1 -
> > > drivers/misc/apds990x.c | 1284 -----------------------
> > > include/linux/platform_data/apds990x.h | 65 --
> > > 5 files changed, 1488 deletions(-)
> > > delete mode 100644 Documentation/misc-devices/apds990x.rst
> > > delete mode 100644 drivers/misc/apds990x.c
> > > delete mode 100644 include/linux/platform_data/apds990x.h
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Jonathan Cameron @ 2026-04-19 16:24 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <CAPVz0n1iB9iC+TFrGK5ajXjdk8-g8vzr4ZbXdvW5=F8iukanaA@mail.gmail.com>
On Sun, 19 Apr 2026 14:50:55 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> нд, 19 квіт. 2026 р. о 14:30 Jonathan Cameron <jic23@kernel.org> пише:
> >
> > On Sun, 19 Apr 2026 11:31:23 +0300
> > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
> > > just add the correct bindings and the appropriate LUX table derived from
> > > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > Hi Svyatoslav,
> >
> > Just one small thing.
> >
> > Experience has given me a strong aversion to the use of wildcards
> > in naming within drivers. They go wrong too often because companies
> > can seem to resist using similar names for very different parts.
> >
>
> Noted.
>
> > > ---
> > > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > > index c8f15ba95267..8dab34bf00ca 100644
> > > --- a/drivers/iio/light/tsl2772.c
> > > +++ b/drivers/iio/light/tsl2772.c
> > > @@ -127,6 +127,7 @@ enum {
> > > tmd2672,
> > > tsl2772,
> > > tmd2772,
> > > + apds990x,
> >
> > As above, just name this after one of the supported parts. apds9900
> > That doesn't stop you using it for multiple compatible devices.
> >
> > Same applies for all the uses of x as a wildcard.
> >
>
> If this is the only thing keeping you from picking this patchset may I
> resend with apds990x fixed right away?
No. I'm just one reviewer - others may need more time. You should wait
at least a few days before sending a new version unless I've specifically
requested a rushed version.
I only do that if I'm trying to get something in at the end of a kernel
cycle or there are dependencies on a patch from others. In this case, neither
applies so please take your time. I'd normally suggest approximately a week.
Thanks,
Jonathan
>
> > thanks,
> >
> > Jonathan
> >
> > > apds9930,
> > > };
> >
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Jonathan Cameron @ 2026-04-19 16:24 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <CAPVz0n048kPMAnGQpOk0_SPtQ+hz=-p6jdyRYPB5d+CD9i7_Cw@mail.gmail.com>
On Sun, 19 Apr 2026 16:46:25 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> нд, 19 квіт. 2026 р. о 16:38 Jonathan Cameron <jic23@kernel.org> пише:
> >
> > On Sun, 19 Apr 2026 11:31:23 +0300
> > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
> >
> > A Sashiko review comment makes me wonder about one thing below if the
> > register set does match. Maybe it's a bit more subtle than this
> > patch description suggests?
> >
> > > just add the correct bindings and the appropriate LUX table derived from
> > > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > > index c8f15ba95267..8dab34bf00ca 100644
> > > --- a/drivers/iio/light/tsl2772.c
> > > +++ b/drivers/iio/light/tsl2772.c
> > > @@ -127,6 +127,7 @@ enum {
> > > tmd2672,
> > > tsl2772,
> > > tmd2772,
> > > + apds990x,
> > > apds9930,
> > > };
> > >
> > > @@ -221,6 +222,12 @@ static const struct tsl2772_lux tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > { 0, 0 },
> > > };
> > >
> > > +static const struct tsl2772_lux apds990x_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > + { 52000, 115960 },
> > > + { 36400, 73840 },
> > > + { 0, 0 },
> > > +};
> > > +
> > > static const struct tsl2772_lux apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > { 52000, 96824 },
> > > { 38792, 67132 },
> > > @@ -238,6 +245,7 @@ static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> > > [tmd2672] = tmd2x72_lux_table,
> > > [tsl2772] = tsl2x72_lux_table,
> > > [tmd2772] = tmd2x72_lux_table,
> > > + [apds990x] = apds990x_lux_table,
> > > [apds9930] = apds9930_lux_table,
> > > };
> > >
> > > @@ -289,6 +297,7 @@ static const int tsl2772_int_time_avail[][6] = {
> > > [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> > > [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > > [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > > + [apds990x] = { 0, 2720, 0, 2720, 0, 696000 },
> > > [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> > > };
> > >
> > > @@ -316,6 +325,7 @@ static const u8 device_channel_config[] = {
> > > [tmd2672] = PRX2,
> > > [tsl2772] = ALSPRX2,
> > > [tmd2772] = ALSPRX2,
> > > + [apds990x] = ALSPRX,
> >
> > This is different from tsl2772?
>
> yes, lux table is different and made according to datasheet,
> tsl2772_int_time_avail differs, ALSPRX configuration assumes that
> proximity sensor needs no calibration which is true for apds9900/1
> while tsl2772 needs calibration, device ID is different 0x20/0x29 for
> apds and 0x30 for tsl2772
All makes sense but that means the patch description needs to be
more precise about what elements are compatible, or use vaguer wording
like 'similar to'.
Jonathan
>
> >
> > > [apds9930] = ALSPRX2,
> > > };
> >
>
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Svyatoslav Ryhel @ 2026-04-19 16:28 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419172458.375e7897@jic23-huawei>
нд, 19 квіт. 2026 р. о 19:25 Jonathan Cameron <jic23@kernel.org> пише:
>
> On Sun, 19 Apr 2026 16:46:25 +0300
> Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > нд, 19 квіт. 2026 р. о 16:38 Jonathan Cameron <jic23@kernel.org> пише:
> > >
> > > On Sun, 19 Apr 2026 11:31:23 +0300
> > > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > >
> > > > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
> > >
> > > A Sashiko review comment makes me wonder about one thing below if the
> > > register set does match. Maybe it's a bit more subtle than this
> > > patch description suggests?
> > >
> > > > just add the correct bindings and the appropriate LUX table derived from
> > > > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> > > >
> > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > ---
> > > > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > > > 1 file changed, 16 insertions(+)
> > > >
> > > > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > > > index c8f15ba95267..8dab34bf00ca 100644
> > > > --- a/drivers/iio/light/tsl2772.c
> > > > +++ b/drivers/iio/light/tsl2772.c
> > > > @@ -127,6 +127,7 @@ enum {
> > > > tmd2672,
> > > > tsl2772,
> > > > tmd2772,
> > > > + apds990x,
> > > > apds9930,
> > > > };
> > > >
> > > > @@ -221,6 +222,12 @@ static const struct tsl2772_lux tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > > { 0, 0 },
> > > > };
> > > >
> > > > +static const struct tsl2772_lux apds990x_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > > + { 52000, 115960 },
> > > > + { 36400, 73840 },
> > > > + { 0, 0 },
> > > > +};
> > > > +
> > > > static const struct tsl2772_lux apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > > { 52000, 96824 },
> > > > { 38792, 67132 },
> > > > @@ -238,6 +245,7 @@ static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> > > > [tmd2672] = tmd2x72_lux_table,
> > > > [tsl2772] = tsl2x72_lux_table,
> > > > [tmd2772] = tmd2x72_lux_table,
> > > > + [apds990x] = apds990x_lux_table,
> > > > [apds9930] = apds9930_lux_table,
> > > > };
> > > >
> > > > @@ -289,6 +297,7 @@ static const int tsl2772_int_time_avail[][6] = {
> > > > [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> > > > [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > > > [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > > > + [apds990x] = { 0, 2720, 0, 2720, 0, 696000 },
> > > > [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> > > > };
> > > >
> > > > @@ -316,6 +325,7 @@ static const u8 device_channel_config[] = {
> > > > [tmd2672] = PRX2,
> > > > [tsl2772] = ALSPRX2,
> > > > [tmd2772] = ALSPRX2,
> > > > + [apds990x] = ALSPRX,
> > >
> > > This is different from tsl2772?
> >
> > yes, lux table is different and made according to datasheet,
> > tsl2772_int_time_avail differs, ALSPRX configuration assumes that
> > proximity sensor needs no calibration which is true for apds9900/1
> > while tsl2772 needs calibration, device ID is different 0x20/0x29 for
> > apds and 0x30 for tsl2772
>
> All makes sense but that means the patch description needs to be
> more precise about what elements are compatible, or use vaguer wording
> like 'similar to'.
>
Fair, noted.
> Jonathan
>
> >
> > >
> > > > [apds9930] = ALSPRX2,
> > > > };
> > >
> >
>
^ permalink raw reply
* Re: [PATCH v8 2/2] iio: dac: ad5706r: Add support for AD5706R DAC
From: Jonathan Cameron @ 2026-04-19 16:41 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, Alexis Czezar Torreno, Lars-Peter Clausen,
Michael Hennerich, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-iio,
devicetree, linux-kernel
In-Reply-To: <aeJ2clUsHk-VTr0F@ashevche-desk.local>
On Fri, 17 Apr 2026 21:05:38 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Fri, Apr 17, 2026 at 01:56:24PM +0100, Jonathan Cameron wrote:
> > On Fri, 17 Apr 2026 11:35:12 +0300
> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > > On Fri, Apr 17, 2026 at 04:27:16PM +0800, Alexis Czezar Torreno wrote:
>
> ...
>
> > > > +#define AD5706R_DAC_RESOLUTION 16
> > > > +#define AD5706R_DAC_MAX_CODE GENMASK(15, 0)
> > >
> > > I know Jonathan asked for this, hence it's comment for him.
> > > I think that BIT() notation in a form of (BIT(16) - 1) is
> > > also appropriate here as it gives the relationship to the
> > > resolution of the given register / bitfield in HW.
> > >
> > > GENMASK() works for me, but it might require an additional
> > > operation to deduce the above.
> > >
> > > (Note, there is no request to change or resend for you, Alexis. It's just
> > > a remark to make Jonathan to think about which one suits better. He might
> > > change that whilst applying.)
> > >
> > I'm not against that form. It was more being against bare BIT(16) as that was
> > 1 greater than the maximum value it can take.
> > However making the relationship explicit would be even better.
> >
> > #define AD5705_DAC_MAX_CODE (BIT(AD5706R_DAC_RESOLUTION) - 1)
>
> While that's technically correct, I would still prefer an explicit number
With the resolution stated on the line above I'd slightly prefer the explicit coupling
that is lost with the number being repeated. Meh, I don't care that much.
>
> #define AD5705_DAC_MAX_CODE (BIT(16) - 1)
>
> Note, GENMASK() is also fine with me, this is really a minor difference.
>
> > I might tweak it when picking this up.
>
^ 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