* [PATCH v3 8/8] clk: sunxi-ng: sun6i-rtc: add a733 support
From: Jerome Brunet @ 2026-07-02 8:10 UTC (permalink / raw)
To: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard
Cc: linux-rtc, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk, Jerome Brunet
In-Reply-To: <20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com>
Add support for the sun60i a733 CCU RTC.
Compared to the a523, this SoC has a different input oscillator divider
which auto-detects the oscillator rate and select a divider to provide
a fixed 32768Hz clock. It also provides several phy reference clocks
with dedicated clock gates.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/sunxi-ng/ccu-sun6i-rtc.c | 73 ++++++++++++++++++++++++++++++++++--
drivers/clk/sunxi-ng/ccu-sun6i-rtc.h | 2 +-
2 files changed, 71 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
index 25dd87e78eb7..6b71bbd80255 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
@@ -44,9 +44,13 @@
#define DCXO_CTRL_REG 0x160
#define DCXO_CTRL_CLK16M_RC_EN BIT(0)
+#define DCXO_GATING_REG 0x16c
+
struct sun6i_rtc_match_data {
bool have_ext_osc32k : 1;
bool have_iosc_calibration : 1;
+ bool have_dcxo_status : 1;
+ bool have_phy_ref_gates : 1;
bool rtc_32k_single_parent : 1;
const struct clk_parent_data *osc32k_fanout_parents;
u8 osc32k_fanout_nparents;
@@ -213,7 +217,12 @@ static struct ccu_mux osc32k_clk = {
},
};
-/* This falls back to the global name for fwnodes without a named reference. */
+/*
+ * This falls back to the global name for fwnodes without a named reference.
+ * NOTE: osc24M name might be misleading the oscillator could also be a 26MHz
+ * or a 19.2MHz one starting with the a733. The original name is kept anyway
+ * in case anything is relying on it.
+ */
static const struct clk_parent_data osc24M[] = {
{ .fw_name = "hosc", .name = "osc24M" }
};
@@ -227,8 +236,28 @@ static struct clk_fixed_factor osc24M_32k_div_clk = {
0),
};
-static SUNXI_CCU_GATE_HW(osc24M_32k_clk, "osc24M-32k", &osc24M_32k_div_clk.hw,
- LOSC_OUT_GATING_REG, BIT(16), 0);
+static struct clk_div_table osc24M_32k_div_a733_table[] = {
+ { .val = 0, .div = 732 },
+ { .val = 1, .div = 586 },
+ { .val = 2, .div = 793 },
+ { .val = 3, .div = 732 },
+ { /* Sentinel */ },
+};
+
+static struct ccu_div osc24M_32k_div_a733_clk = {
+ .enable = BIT(1),
+ .div = _SUNXI_CCU_DIV_TABLE(14, 2, osc24M_32k_div_a733_table),
+ .common = {
+ .reg = DCXO_CTRL_REG,
+ .hw.init = CLK_HW_INIT_PARENTS_DATA("osc24M-32k-div",
+ osc24M,
+ &ccu_rodiv_ops,
+ 0),
+ },
+};
+
+static SUNXI_CCU_GATE(osc24M_32k_clk, "osc24M-32k", "osc24M-32k-div",
+ LOSC_OUT_GATING_REG, BIT(16), 0);
static const struct clk_hw *rtc_32k_parents[] = {
&osc32k_clk.common.hw,
@@ -267,6 +296,15 @@ static struct ccu_mux osc32k_fanout_clk = {
},
};
+static SUNXI_CCU_GATE_FW(hosc_serdes1_clk, "hosc-serdes1", "hosc",
+ DCXO_GATING_REG, BIT(5), 0);
+static SUNXI_CCU_GATE_FW(hosc_serdes0_clk, "hosc-serdes0", "hosc",
+ DCXO_GATING_REG, BIT(4), 0);
+static SUNXI_CCU_GATE_FW(hosc_hdmi_clk, "hosc-hdmi", "hosc",
+ DCXO_GATING_REG, BIT(1), 0);
+static SUNXI_CCU_GATE_FW(hosc_ufs_clk, "hosc-ufs", "hosc",
+ DCXO_GATING_REG, BIT(0), 0);
+
static struct ccu_common *sun6i_rtc_ccu_clks[] = {
&iosc_clk,
&iosc_32k_clk,
@@ -275,6 +313,11 @@ static struct ccu_common *sun6i_rtc_ccu_clks[] = {
&osc24M_32k_clk.common,
&rtc_32k_clk.common,
&osc32k_fanout_clk.common,
+ &osc24M_32k_div_a733_clk.common,
+ &hosc_serdes1_clk.common,
+ &hosc_serdes0_clk.common,
+ &hosc_hdmi_clk.common,
+ &hosc_ufs_clk.common,
};
static struct clk_hw_onecell_data sun6i_rtc_ccu_hw_clks = {
@@ -288,6 +331,10 @@ static struct clk_hw_onecell_data sun6i_rtc_ccu_hw_clks = {
[CLK_OSC24M_32K] = &osc24M_32k_clk.common.hw,
[CLK_RTC_32K] = &rtc_32k_clk.common.hw,
[CLK_OSC24M_32K_DIV] = &osc24M_32k_div_clk.hw,
+ [CLK_HOSC_UFS] = &hosc_ufs_clk.common.hw,
+ [CLK_HOSC_HDMI] = &hosc_hdmi_clk.common.hw,
+ [CLK_HOSC_SERDES0] = &hosc_serdes0_clk.common.hw,
+ [CLK_HOSC_SERDES1] = &hosc_serdes1_clk.common.hw,
},
};
@@ -330,6 +377,15 @@ static const struct sun6i_rtc_match_data sun55i_a523_rtc_ccu_data = {
.osc32k_fanout_nparents = ARRAY_SIZE(sun50i_r329_osc32k_fanout_parents),
};
+static const struct sun6i_rtc_match_data sun60i_a733_rtc_ccu_data = {
+ .have_ext_osc32k = true,
+ .have_iosc_calibration = true,
+ .have_dcxo_status = true,
+ .have_phy_ref_gates = true,
+ .osc32k_fanout_parents = sun50i_r329_osc32k_fanout_parents,
+ .osc32k_fanout_nparents = ARRAY_SIZE(sun50i_r329_osc32k_fanout_parents),
+};
+
static const struct of_device_id sun6i_rtc_ccu_match[] = {
{
.compatible = "allwinner,sun50i-h616-rtc",
@@ -343,6 +399,10 @@ static const struct of_device_id sun6i_rtc_ccu_match[] = {
.compatible = "allwinner,sun55i-a523-rtc",
.data = &sun55i_a523_rtc_ccu_data,
},
+ {
+ .compatible = "allwinner,sun60i-a733-rtc",
+ .data = &sun60i_a733_rtc_ccu_data,
+ },
{},
};
MODULE_DEVICE_TABLE(of, sun6i_rtc_ccu_match);
@@ -375,6 +435,13 @@ int sun6i_rtc_ccu_probe(struct device *dev, void __iomem *reg)
osc32k_fanout_init_data.parent_data = data->osc32k_fanout_parents;
osc32k_fanout_init_data.num_parents = data->osc32k_fanout_nparents;
+ if (data->have_dcxo_status)
+ sun6i_rtc_ccu_hw_clks.hws[CLK_OSC24M_32K_DIV] =
+ &osc24M_32k_div_a733_clk.common.hw;
+
+ if (!data->have_phy_ref_gates)
+ sun6i_rtc_ccu_hw_clks.num = CLK_OSC24M_32K_DIV + 1;
+
return devm_sunxi_ccu_probe(dev, reg, &sun6i_rtc_ccu_desc);
}
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
index ab7b92b47f59..4f4f4cb00f1d 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
@@ -11,6 +11,6 @@
#define CLK_RTC_32K 6
#define CLK_OSC24M_32K_DIV 7
-#define CLK_NUMBER (CLK_OSC24M_32K_DIV + 1)
+#define CLK_NUMBER (CLK_HOSC_SERDES1 + 1)
#endif /* _CCU_SUN6I_RTC_H */
--
2.47.3
^ permalink raw reply related
* [PATCH v3 6/8] clk: sunxi-ng: div: add read-only operation support
From: Jerome Brunet @ 2026-07-02 8:10 UTC (permalink / raw)
To: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard
Cc: linux-rtc, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk, Jerome Brunet
In-Reply-To: <20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com>
Add support for sunxi-ng read-only dividers. This will be
useful to the a733 oscillator detection logic.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/sunxi-ng/ccu_div.c | 42 ++++++++++++++++++++++++++++++++++++++++++
drivers/clk/sunxi-ng/ccu_div.h | 1 +
drivers/clk/sunxi-ng/ccu_mux.c | 3 ++-
drivers/clk/sunxi-ng/ccu_mux.h | 4 ++++
4 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu_div.c b/drivers/clk/sunxi-ng/ccu_div.c
index 62d680ccb524..d1c8c7baa12d 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -84,6 +84,36 @@ static int ccu_div_determine_rate(struct clk_hw *hw,
req, ccu_div_determine_rate_helper, cd);
}
+static int ccu_rodiv_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ struct ccu_div *cd = hw_to_ccu_div(hw);
+ unsigned long val;
+ u32 reg;
+ int ret;
+
+ reg = readl(cd->common.base + cd->common.reg);
+ val = reg >> cd->div.shift;
+ val &= (1 << cd->div.width) - 1;
+
+ req->rate = ccu_mux_helper_unapply_prediv(&cd->common, &cd->mux, -1,
+ req->rate);
+
+ if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
+ req->rate *= cd->fixed_post_div;
+
+ ret = divider_ro_determine_rate(hw, req, cd->div.table,
+ cd->div.width, cd->div.flags, val);
+
+ if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
+ req->rate /= cd->fixed_post_div;
+
+ req->rate = ccu_mux_helper_apply_prediv(&cd->common, &cd->mux, -1,
+ req->rate);
+
+ return ret;
+}
+
static int ccu_div_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
@@ -143,3 +173,15 @@ const struct clk_ops ccu_div_ops = {
.set_rate = ccu_div_set_rate,
};
EXPORT_SYMBOL_NS_GPL(ccu_div_ops, "SUNXI_CCU");
+
+const struct clk_ops ccu_rodiv_ops = {
+ .disable = ccu_div_disable,
+ .enable = ccu_div_enable,
+ .is_enabled = ccu_div_is_enabled,
+
+ .get_parent = ccu_div_get_parent,
+
+ .determine_rate = ccu_rodiv_determine_rate,
+ .recalc_rate = ccu_div_recalc_rate,
+};
+EXPORT_SYMBOL_NS_GPL(ccu_rodiv_ops, "SUNXI_CCU");
diff --git a/drivers/clk/sunxi-ng/ccu_div.h b/drivers/clk/sunxi-ng/ccu_div.h
index be00b3277e97..a30a92780a05 100644
--- a/drivers/clk/sunxi-ng/ccu_div.h
+++ b/drivers/clk/sunxi-ng/ccu_div.h
@@ -300,5 +300,6 @@ static inline struct ccu_div *hw_to_ccu_div(struct clk_hw *hw)
}
extern const struct clk_ops ccu_div_ops;
+extern const struct clk_ops ccu_rodiv_ops;
#endif /* _CCU_DIV_H_ */
diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index 766f27cff748..e2d6833a6d33 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -68,13 +68,14 @@ unsigned long ccu_mux_helper_apply_prediv(struct ccu_common *common,
}
EXPORT_SYMBOL_NS_GPL(ccu_mux_helper_apply_prediv, "SUNXI_CCU");
-static unsigned long ccu_mux_helper_unapply_prediv(struct ccu_common *common,
+unsigned long ccu_mux_helper_unapply_prediv(struct ccu_common *common,
struct ccu_mux_internal *cm,
int parent_index,
unsigned long parent_rate)
{
return parent_rate * ccu_mux_get_prediv(common, cm, parent_index);
}
+EXPORT_SYMBOL_NS_GPL(ccu_mux_helper_unapply_prediv, "SUNXI_CCU");
int ccu_mux_helper_determine_rate(struct ccu_common *common,
struct ccu_mux_internal *cm,
diff --git a/drivers/clk/sunxi-ng/ccu_mux.h b/drivers/clk/sunxi-ng/ccu_mux.h
index c94a4bde5d01..272a2c36a8f2 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.h
+++ b/drivers/clk/sunxi-ng/ccu_mux.h
@@ -134,6 +134,10 @@ unsigned long ccu_mux_helper_apply_prediv(struct ccu_common *common,
struct ccu_mux_internal *cm,
int parent_index,
unsigned long parent_rate);
+unsigned long ccu_mux_helper_unapply_prediv(struct ccu_common *common,
+ struct ccu_mux_internal *cm,
+ int parent_index,
+ unsigned long parent_rate);
int ccu_mux_helper_determine_rate(struct ccu_common *common,
struct ccu_mux_internal *cm,
struct clk_rate_request *req,
--
2.47.3
^ permalink raw reply related
* [PATCH v3 7/8] clk: sunxi-ng: sun6i-rtc: split main oscillator div and gate.
From: Jerome Brunet @ 2026-07-02 8:10 UTC (permalink / raw)
To: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard
Cc: linux-rtc, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk, Jerome Brunet
In-Reply-To: <20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com>
On the a733 the "osc24M-32k" clock has the same gate bits as the previously
supported SoC but a different divider implementation.
Instead of a fixed 750 divider, the divider is selected based on the
rate of the oscillator. It can be seen as a simple read-only divider.
To easily replace the divider part depending the SoC, split the divider
and gate into two separate clock entities.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/sunxi-ng/ccu-sun6i-rtc.c | 20 +++++++++++---------
drivers/clk/sunxi-ng/ccu-sun6i-rtc.h | 3 ++-
2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
index b24c8b196e66..25dd87e78eb7 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
@@ -218,17 +218,18 @@ static const struct clk_parent_data osc24M[] = {
{ .fw_name = "hosc", .name = "osc24M" }
};
-static struct ccu_gate osc24M_32k_clk = {
- .enable = BIT(16),
- .common = {
- .reg = LOSC_OUT_GATING_REG,
- .prediv = 750,
- .features = CCU_FEATURE_ALL_PREDIV,
- .hw.init = CLK_HW_INIT_PARENTS_DATA("osc24M-32k", osc24M,
- &ccu_gate_ops, 0),
- },
+static struct clk_fixed_factor osc24M_32k_div_clk = {
+ .mult = 1,
+ .div = 750,
+ .hw.init = CLK_HW_INIT_PARENTS_DATA("osc24M-32k-div",
+ osc24M,
+ &clk_fixed_factor_ops,
+ 0),
};
+static SUNXI_CCU_GATE_HW(osc24M_32k_clk, "osc24M-32k", &osc24M_32k_div_clk.hw,
+ LOSC_OUT_GATING_REG, BIT(16), 0);
+
static const struct clk_hw *rtc_32k_parents[] = {
&osc32k_clk.common.hw,
&osc24M_32k_clk.common.hw
@@ -286,6 +287,7 @@ static struct clk_hw_onecell_data sun6i_rtc_ccu_hw_clks = {
[CLK_EXT_OSC32K_GATE] = &ext_osc32k_gate_clk.common.hw,
[CLK_OSC24M_32K] = &osc24M_32k_clk.common.hw,
[CLK_RTC_32K] = &rtc_32k_clk.common.hw,
+ [CLK_OSC24M_32K_DIV] = &osc24M_32k_div_clk.hw,
},
};
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
index 9ae821fc2599..ab7b92b47f59 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
@@ -9,7 +9,8 @@
#define CLK_EXT_OSC32K_GATE 4
#define CLK_OSC24M_32K 5
#define CLK_RTC_32K 6
+#define CLK_OSC24M_32K_DIV 7
-#define CLK_NUMBER (CLK_RTC_32K + 1)
+#define CLK_NUMBER (CLK_OSC24M_32K_DIV + 1)
#endif /* _CCU_SUN6I_RTC_H */
--
2.47.3
^ permalink raw reply related
* [PATCH v3 4/8] clk: sunxi-ng: sun6i-rtc: clean up DT usage
From: Jerome Brunet @ 2026-07-02 8:10 UTC (permalink / raw)
To: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard
Cc: linux-rtc, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk, Jerome Brunet
In-Reply-To: <20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com>
With sun6i-rtc compatible devices, the "ext-osc32k" clock input
is optional for the devices that support this input (r329 and onward).
Probably preparing for older SoC support, the driver does something funny
when parsing DT. It check if "ext-osc32k" is present in the clock-names and
if it is not, it uses the first clock as "ext-osc32k". This clock will
actually be the rtc bus clock so what the driver does is wrong.
At the moment, the driver does not support the older SoCs that would have
an external 32k clock provided on index #0 so just remove this quirk.
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/sunxi-ng/ccu-sun6i-rtc.c | 23 +++--------------------
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
index f6bfeba009e8..0f528bfaed00 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
@@ -191,10 +191,8 @@ static struct ccu_common iosc_32k_clk = {
CLK_GET_RATE_NOCACHE),
};
-static const struct clk_hw *ext_osc32k[] = { NULL }; /* updated during probe */
-
-static SUNXI_CCU_GATE_HWS(ext_osc32k_gate_clk, "ext-osc32k-gate",
- ext_osc32k, 0x0, BIT(4), 0);
+static SUNXI_CCU_GATE_FW(ext_osc32k_gate_clk, "ext-osc32k-gate",
+ "ext-osc32k", 0x0, BIT(4), 0);
static const struct clk_hw *osc32k_parents[] = {
&iosc_32k_clk.hw,
@@ -352,7 +350,6 @@ MODULE_DEVICE_TABLE(of, sun6i_rtc_ccu_match);
int sun6i_rtc_ccu_probe(struct device *dev, void __iomem *reg)
{
const struct sun6i_rtc_match_data *data;
- struct clk *ext_osc32k_clk = NULL;
const struct of_device_id *match;
/* This driver is only used for newer variants of the hardware. */
@@ -363,21 +360,7 @@ int sun6i_rtc_ccu_probe(struct device *dev, void __iomem *reg)
data = match->data;
have_iosc_calibration = data->have_iosc_calibration;
- if (data->have_ext_osc32k) {
- const char *fw_name;
-
- /* ext-osc32k was the only input clock in the old binding. */
- fw_name = of_property_present(dev->of_node, "clock-names")
- ? "ext-osc32k" : NULL;
- ext_osc32k_clk = devm_clk_get_optional(dev, fw_name);
- if (IS_ERR(ext_osc32k_clk))
- return PTR_ERR(ext_osc32k_clk);
- }
-
- if (ext_osc32k_clk) {
- /* Link ext-osc32k-gate to its parent. */
- *ext_osc32k = __clk_get_hw(ext_osc32k_clk);
- } else {
+ if (!data->have_ext_osc32k) {
/* ext-osc32k-gate is an orphan, so do not register it. */
sun6i_rtc_ccu_hw_clks.hws[CLK_EXT_OSC32K_GATE] = NULL;
osc32k_init_data.num_parents = 1;
--
2.47.3
^ permalink raw reply related
* [PATCH v3 3/8] clk: sunxi-ng: fix ccu probe clock unregister on error
From: Jerome Brunet @ 2026-07-02 8:10 UTC (permalink / raw)
To: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard
Cc: linux-rtc, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk, Sashiko, Jerome Brunet
In-Reply-To: <20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com>
When registering clocks with sunxi_ccu_probe(), the number of ccu_clocks
and the number of hw clocks might be different, eventhough they usually are
the same.
If they are different, it could lead to out-of-bound access or registered
clock left behind on error.
Use a different variable when iterating on hw clocks so every registered
clock, and only those, gets unregistered on error.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/r/20260629131254.7E34C1F00A3A@smtp.kernel.org
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/sunxi-ng/ccu_common.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu_common.c b/drivers/clk/sunxi-ng/ccu_common.c
index 1c083b4d0b7e..43d8eca6abee 100644
--- a/drivers/clk/sunxi-ng/ccu_common.c
+++ b/drivers/clk/sunxi-ng/ccu_common.c
@@ -114,7 +114,7 @@ static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device *dev,
const struct sunxi_ccu_desc *desc)
{
struct ccu_reset *reset;
- int i, ret;
+ int i, j, ret;
ccu->desc = desc;
@@ -130,8 +130,8 @@ static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device *dev,
cclk->lock = &ccu->lock;
}
- for (i = 0; i < desc->hw_clks->num ; i++) {
- struct clk_hw *hw = desc->hw_clks->hws[i];
+ for (j = 0; j < desc->hw_clks->num ; j++) {
+ struct clk_hw *hw = desc->hw_clks->hws[j];
const char *name;
if (!hw)
@@ -143,7 +143,7 @@ static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device *dev,
else
ret = of_clk_hw_register(node, hw);
if (ret) {
- pr_err("Couldn't register clock %d - %s\n", i, name);
+ pr_err("Couldn't register clock %d - %s\n", j, name);
goto err_clk_unreg;
}
}
@@ -186,8 +186,8 @@ static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device *dev,
err_del_provider:
of_clk_del_provider(node);
err_clk_unreg:
- while (--i >= 0) {
- struct clk_hw *hw = desc->hw_clks->hws[i];
+ while (--j >= 0) {
+ struct clk_hw *hw = desc->hw_clks->hws[j];
if (!hw)
continue;
--
2.47.3
^ permalink raw reply related
* [PATCH v3 2/8] dt-bindings: rtc: sun6i: add sun60i-a733 support
From: Jerome Brunet @ 2026-07-02 8:10 UTC (permalink / raw)
To: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard
Cc: linux-rtc, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk, Jerome Brunet
In-Reply-To: <20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com>
Add a new rtc compatible for the sun60i-a733 SoC and new IDs for the
peripheral oscillator clock gates of this SoC.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 1 +
include/dt-bindings/clock/sun6i-rtc.h | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
index 959a012c626f..f2b91186ed37 100644
--- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
@@ -33,6 +33,7 @@ properties:
- enum:
- allwinner,sun20i-d1-rtc
- allwinner,sun55i-a523-rtc
+ - allwinner,sun60i-a733-rtc
- const: allwinner,sun50i-r329-rtc
reg:
diff --git a/include/dt-bindings/clock/sun6i-rtc.h b/include/dt-bindings/clock/sun6i-rtc.h
index 3bd3aa3d57ce..5132a393ca4b 100644
--- a/include/dt-bindings/clock/sun6i-rtc.h
+++ b/include/dt-bindings/clock/sun6i-rtc.h
@@ -6,5 +6,9 @@
#define CLK_OSC32K 0
#define CLK_OSC32K_FANOUT 1
#define CLK_IOSC 2
+#define CLK_HOSC_UFS 8
+#define CLK_HOSC_HDMI 9
+#define CLK_HOSC_SERDES0 10
+#define CLK_HOSC_SERDES1 11
#endif /* _DT_BINDINGS_CLK_SUN6I_RTC_H_ */
--
2.47.3
^ permalink raw reply related
* [PATCH v3 1/8] dt-bindings: rtc: sun6i: no clock-output-names on h616/r329
From: Jerome Brunet @ 2026-07-02 8:10 UTC (permalink / raw)
To: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard
Cc: linux-rtc, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk, Sashiko, Jerome Brunet
In-Reply-To: <20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com>
On h616 and r329 chips, clock output names are never defined through DT and
are not meant to be. Just disallow the property for those chips.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: http://lore.kernel.org/r/20260629125305.0DF981F000E9@smtp.kernel.org
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
.../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
index 9df5cdb6f63f..959a012c626f 100644
--- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
@@ -175,6 +175,18 @@ allOf:
interrupts:
minItems: 2
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - allwinner,sun50i-h616-rtc
+ - allwinner,sun50i-r329-rtc
+
+ then:
+ properties:
+ clock-output-names: false
+
required:
- "#clock-cells"
- compatible
--
2.47.3
^ permalink raw reply related
* [PATCH v3 0/8] clk: sun6i-rtc: Add support for Allwinner A733 SoC
From: Jerome Brunet @ 2026-07-02 8:09 UTC (permalink / raw)
To: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard
Cc: linux-rtc, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk, Sashiko, Jerome Brunet
Add support for the Allwinner A733 RTC and its internal Clock Control
Unit (CCU). Reuse the rtc-sun6i rtc driver while introducing a new
SoC-specific RTC CCU driver to handle the hardware's evolved clock
structure.
The A733 implementation supports hardware detection of three external
crystal frequencies (19.2MHz, 24MHz and 26MHz), which is represented in
the driver via read-only divider operations. Implement logic to derive a
normalized 32kHz reference from these DCXO sources using fixed
pre-dividers. Additionally, provide several new DCXO gate clocks for
peripherals, including SerDes, HDMI, and UFS.
This was tested on a Raxda Cubie A7A.
Changes in v3:
- Disallow clock-output-names DT property for h616/r329 chips
- Fix ccu probe helper to properly unregister clocks on error
- Implement .determine_rate for ccu divider RO ops
- Drop unused DCXO_CTRL_REG_EN define
- Link to v2: https://patch.msgid.link/20260629-a733-rtc-v2-0-7b72112784f8@baylibre.com
Changes in v2:
* Changed DT bindings as suggested. Those have changed significantly
since v1 so I did not pick up Rob's review trailer
* Support added in the existing RTC CCU driver rather than a separate driver
* Added DT parsing clean up of the existing driver
* Xtal detection exposed by RO divider rather than a MUX.
* Dropped conversion to aux device for now. This is not strictly related
the a733 support and will submitted again later on.
* Link to v1: https://lore.kernel.org/r/20260121-a733-rtc-v1-0-d359437f23a7@pigmoral.tech
---
Jerome Brunet (7):
dt-bindings: rtc: sun6i: no clock-output-names on h616/r329
dt-bindings: rtc: sun6i: add sun60i-a733 support
clk: sunxi-ng: fix ccu probe clock unregister on error
clk: sunxi-ng: sun6i-rtc: clean up DT usage
clk: sunxi-ng: div: add read-only operation support
clk: sunxi-ng: sun6i-rtc: split main oscillator div and gate.
clk: sunxi-ng: sun6i-rtc: add a733 support
Junhui Liu (1):
clk: sunxi-ng: sun6i-rtc: Add feature bit for IOSC calibration
.../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 13 +++
drivers/clk/sunxi-ng/ccu-sun6i-rtc.c | 123 +++++++++++++++------
drivers/clk/sunxi-ng/ccu-sun6i-rtc.h | 3 +-
drivers/clk/sunxi-ng/ccu_common.c | 12 +-
drivers/clk/sunxi-ng/ccu_common.h | 1 +
drivers/clk/sunxi-ng/ccu_div.c | 42 +++++++
drivers/clk/sunxi-ng/ccu_div.h | 1 +
drivers/clk/sunxi-ng/ccu_mux.c | 3 +-
drivers/clk/sunxi-ng/ccu_mux.h | 4 +
include/dt-bindings/clock/sun6i-rtc.h | 4 +
10 files changed, 163 insertions(+), 43 deletions(-)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20251226-a733-rtc-c5167df14e6e
Best regards,
--
Jerome
^ permalink raw reply
* Re: [PATCH 5/5] gpio: nomadik: drop "chip registered" log on probe success
From: Linus Walleij @ 2026-07-02 8:00 UTC (permalink / raw)
To: Théo Lebrun
Cc: Bartosz Golaszewski, Philipp Zabel, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, linux-arm-kernel, linux-gpio, linux-kernel
In-Reply-To: <20260701-gpio-nomadik-silent-v1-5-644d10316cef@bootlin.com>
On Wed, Jul 1, 2026 at 6:57 PM Théo Lebrun <theo.lebrun@bootlin.com> wrote:
> Successful driver probing should be silent. Drop unconditional
> dev_info() call that is done at nmk_gpio_probe() exit.
>
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
I actually don't generally agree, but you are using this driver more than
me now so let's go with your minimalist dmesg style for this driver.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: display: mediatek: Allow trigger-sources on relevant HW
From: Krzysztof Kozlowski @ 2026-07-02 7:59 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: chunkuang.hu, p.zabel, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, mcoquelin.stm32,
alexandre.torgue, matthias.bgg, andi.shyti, djakov, broonie,
jitao.shi, ck.hu, dri-devel, linux-mediatek, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel, justin.yeh,
jason-jh.lin, kernel
In-Reply-To: <20260701122043.19612-4-angelogioacchino.delregno@collabora.com>
On Wed, Jul 01, 2026 at 02:20:40PM +0200, AngeloGioacchino Del Regno wrote:
> Most of the MediaTek Display Controller hardware sub-IPs need a
> specific (and reserved to them) MuteX trigger.
>
> Since now MuteX is a trigger source, allow specifying trigger
> sources in all of the display IPs that support one.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/5] gpio: nomadik: use dev_err_probe()
From: Linus Walleij @ 2026-07-02 7:59 UTC (permalink / raw)
To: Théo Lebrun
Cc: Bartosz Golaszewski, Philipp Zabel, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, linux-arm-kernel, linux-gpio, linux-kernel
In-Reply-To: <20260701-gpio-nomadik-silent-v1-4-644d10316cef@bootlin.com>
On Wed, Jul 1, 2026 at 6:57 PM Théo Lebrun <theo.lebrun@bootlin.com> wrote:
> gpio-nomadik depends on a few resources. In one case the reset is taking
> time to show up leading to a boot log containing:
>
> [ 0.544230] nomadik-gpio 1400000.gpio: failed getting reset control: -EPROBE_DEFER
>
> Fix by replacing all dev_err() calls that might be made at probe with
> dev_err_probe().
>
> On nomadik platforms, the nmk_gpio_populate_chip() log calls might
> attach their reasons to the gpio or pinctrl device depending on boot
> order.
>
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/5] gpio: nomadik: drop duplicate probe error line
From: Linus Walleij @ 2026-07-02 7:59 UTC (permalink / raw)
To: Théo Lebrun
Cc: Bartosz Golaszewski, Philipp Zabel, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, linux-arm-kernel, linux-gpio, linux-kernel
In-Reply-To: <20260701-gpio-nomadik-silent-v1-3-644d10316cef@bootlin.com>
On Wed, Jul 1, 2026 at 6:57 PM Théo Lebrun <theo.lebrun@bootlin.com> wrote:
> Now that all error codepaths in nmk_gpio_populate_chip() log an error,
> drop dev_err() call that is made on nmk_gpio_populate_chip() failure.
>
> Current boot log:
>
> [ 0.544230] nomadik-gpio 1400000.gpio: failed getting reset control: -EPROBE_DEFER
> [ 0.544274] nomadik-gpio 1400000.gpio: could not populate nmk chip struct
>
> The second line is always redundant (or is logged when we shouldn't log,
> like ioremap or alloc failures).
>
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/5] gpio: nomadik: add missing dev_err() call on chip populate failure
From: Linus Walleij @ 2026-07-02 7:58 UTC (permalink / raw)
To: Théo Lebrun
Cc: Bartosz Golaszewski, Philipp Zabel, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, linux-arm-kernel, linux-gpio, linux-kernel
In-Reply-To: <20260701-gpio-nomadik-silent-v1-2-644d10316cef@bootlin.com>
On Wed, Jul 1, 2026 at 6:57 PM Théo Lebrun <theo.lebrun@bootlin.com> wrote:
> All error paths of nmk_gpio_populate_chip() lead to logging errors but
> this one (ignoring the alloc or ioremap failures that must not log).
>
> Add the single missing dev_err() call.
>
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/5] gpio: nomadik: convert nmk_gpio_populate_chip() to goto cleanup
From: Linus Walleij @ 2026-07-02 7:58 UTC (permalink / raw)
To: Théo Lebrun
Cc: Bartosz Golaszewski, Philipp Zabel, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, linux-arm-kernel, linux-gpio, linux-kernel
In-Reply-To: <20260701-gpio-nomadik-silent-v1-1-644d10316cef@bootlin.com>
On Wed, Jul 1, 2026 at 6:57 PM Théo Lebrun <theo.lebrun@bootlin.com> wrote:
> Remove duplicate teardown code that is found in all error if
> statements. Replace by goto-based cleanup labels.
>
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: soc: mediatek: mutex: Improve title and description
From: Krzysztof Kozlowski @ 2026-07-02 7:52 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: chunkuang.hu, p.zabel, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, mcoquelin.stm32,
alexandre.torgue, matthias.bgg, andi.shyti, djakov, broonie,
jitao.shi, ck.hu, dri-devel, linux-mediatek, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel, justin.yeh,
jason-jh.lin, kernel
In-Reply-To: <20260701122043.19612-2-angelogioacchino.delregno@collabora.com>
On Wed, Jul 01, 2026 at 02:20:38PM +0200, AngeloGioacchino Del Regno wrote:
> Improve both the title and the description of this hardware to
> disambiguate its functionality from a hardware mutex and/or from
> a hwspinlock.
>
> Though in datasheets this is called "DISP_MUTEX", the meaning is
> is "Mute-X" (where "X" means "any hardware trigger signal") really
> as this is what this piece of hardware does: muting or unmuting of
> signals in each sub-IP of the display or other multimedia related
> controllers.
>
> Based on that, also clarify the description text, as to make sure
> that the information is actually accurate.
>
> While at it, also avoid forcing literal blocks in the description
> as there is nothing in there needing that (no ascii graph or other
> stuff that needs a literal block anyway), and add myself in the
> list of maintainers.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../bindings/soc/mediatek/mediatek,mutex.yaml | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: arm: altera: Add Agilex5 SoCDK TSN Config2 board board
From: Krzysztof Kozlowski @ 2026-07-02 7:16 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade
Cc: dinguyen, maxime.chevallier, rmk+kernel, krzk+dt, conor+dt, robh,
davem, edumazet, kuba, pabeni, andrew+netdev, devicetree,
linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <20260630133108.27244-2-muhammad.nazim.amirul.nazle.asmade@altera.com>
On Tue, Jun 30, 2026 at 06:31:06AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Add compatible string for the Intel SoCFPGA Agilex5 SoCDK TSN Config2
> board variant, which uses a dual-port TSN configuration where gmac1
> operates with different MAC-side (GMII) and PHY-side (RGMII) interface
> modes.
>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> ---
> Documentation/devicetree/bindings/arm/altera.yaml | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/4] firmware: raspberrypi: Add reboot mode support
From: Gregor Herburger @ 2026-07-02 7:50 UTC (permalink / raw)
To: Stefan Wahren
Cc: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
devicetree
In-Reply-To: <628b2768-80e6-4a7b-846f-d1124059f899@gmx.net>
Hi Stefan,
On Tue, Jun 30, 2026 at 11:57:49PM +0200, Stefan Wahren wrote:
> Hi Gregor,
>
> Am 30.06.26 um 22:59 schrieb Gregor Herburger:
> > +static int rpi_firmware_reboot_mode_write(struct reboot_mode_driver *reboot,
> > + unsigned int magic)
> > +{
> > + struct rpi_firmware *fw = container_of(reboot, struct rpi_firmware,
> > + reboot_mode);
> > + int ret = 0;
> > +
> > + if (magic)
> > + ret = rpi_firmware_property(fw, RPI_FIRMWARE_SET_REBOOT_FLAGS,
> > + &magic, sizeof(magic));
> I think it's more elegant to check for !magic and return 0 directly. So we
> can drop "ret".
> > +
> > + return ret;
> > +}
> > +
> > static int rpi_firmware_probe(struct platform_device *pdev)
> > {
> > struct device *dev = &pdev->dev;
> > struct rpi_firmware *fw;
> > + int ret;
> > /*
> > * Memory will be freed by rpi_firmware_delete() once all users have
> > @@ -306,6 +323,12 @@ static int rpi_firmware_probe(struct platform_device *pdev)
> > rpi_register_hwmon_driver(dev, fw);
> > rpi_register_clk_driver(dev);
> > + fw->reboot_mode.dev = dev;
> > + fw->reboot_mode.write = rpi_firmware_reboot_mode_write;
> > + ret = devm_reboot_mode_register(dev, &fw->reboot_mode);
> > + if (ret)
> > + dev_err(dev, "Failed to register reboot mode: %d\n", ret);
> I suggest to move all of this code into a function called
> rpi_register_reboot_mode() ?
>
Ok, will do. Will wait a bit for more feedback and add this to the next version.
--
Gregor Herburger
Linutronix GmbH | Bahnhofstrasse 3 | D-88690 Uhldingen-Mühlhofen
Phone: +49 7556 25 999 35; Fax.: +49 7556 25 999 99
Hinweise zum Datenschutz finden Sie hier (Informations on data privacy
can be found here): https://linutronix.de/legal/data-protection.php
Linutronix GmbH | Firmensitz (Registered Office): Uhldingen-Mühlhofen |
Registergericht (Registration Court): Amtsgericht Freiburg i.Br., HRB700
806 | Geschäftsführer (Managing Directors): Dr. Wilfried Wessner,
Katharina Kopp, Alexander Gieringer
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: can: rockchip: add rk3588v2 CAN-FD compatible
From: Krzysztof Kozlowski @ 2026-07-02 7:43 UTC (permalink / raw)
To: 1579567540
Cc: Marc Kleine-Budde, linux-can, Vincent Mailhol, kernel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <tencent_83A61C9A79199D04CC118A8026C435BFB907@qq.com>
On Wed, Jul 01, 2026 at 03:01:26PM +0800, 1579567540@qq.com wrote:
> From: luch00 <1579567540@qq.com>
>
> The RK3588 CAN-FD controller uses the same DT properties as the
> existing Rockchip CAN-FD blocks, so extend the current schema with a
DT properties have nothing to do here. Are you saying it is fully
compatible? Then express it properly with fallback.
> SoC-specific rockchip,rk3588v2-canfd compatible instead of creating a
> new binding file.
>
> Keep RK3588v2 as its own compatible rather than an rk3568v2 fallback.
Do not explain what you did. Explain WHY.
> Driver support uses separate match data and the RX FIFO count field
Driver is irrelevant here.
> layout differs from rk3568v2, so a dedicated compatible is the safer
> description.
>
> Signed-off-by: luch00 <1579567540@qq.com>
We do not take anonymous contributions.
> ---
> .../devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
> index a077c0330..aa31ec78e 100644
> --- a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
> +++ b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
> @@ -17,6 +17,7 @@ properties:
> compatible:
> oneOf:
> - const: rockchip,rk3568v2-canfd
> + - const: rockchip,rk3588v2-canfd
So that's just enum with previous entry
And why is this different from rk3588?
> - items:
> - const: rockchip,rk3568v3-canfd
> - const: rockchip,rk3568v2-canfd
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 01/19] ARM: use CONFIG_AEABI by default everywhere
From: Nicolas Ferre @ 2026-07-02 7:42 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel, soc
Cc: linux-kernel, Arnd Bergmann, Aaro Koskinen, Alexander Sverdlin,
Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
Claudiu Beznea, Daniel Mack, Ethan Nelson-Moore, Frank Li,
Gregory Clement, Haojian Zhuang, Jeremy J. Peper,
Kristoffer Ericson, Krzysztof Kozlowski, Linus Walleij,
Mark Brown, Marc Zyngier, Mike Rapoport, Patrice Chotard,
Ralph Siemsen, Robert Jarzmik, Russell King, Sascha Hauer,
Sebastian Hesselbarth, Stefan Agner, Stefan Wiehler,
Tony Lindgren, Vladimir Zapolskiy, Will Deacon, Linus Walleij
In-Reply-To: <20260701212353.2196041-2-arnd@kernel.org>
On 01/07/2026 at 23:23, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> On ARMv4 and ARMv5, the default is still to build for OABI, with
> CONFIG_AEABI disabled, even though distros and toolchains no longer
> support OABI as a target.
>
> Change the default to EABI for all architecture levels and change
> the defconfig entries as follows:
>
> - All machines that used to explicitly enable EABI can drop that line now
> - Machines that are likely to actually use old distros and had NWFPE
> enabled in combination with OABI (rpc, footrbridge, netwinder,
> assabet, neponset) explicitly turn it on now.
> - Machines that already had both EABI and NWFPE disabled in defconfig
> (at91_dt, collie, ep93xx, gemini, h3600, imx_v4_v5, integrator, jornada,
For at91_dt, EABI was explicitly enabled (see below)...
> moxart, multi_v4t, omap1) were likely not usable with either OABI or
> EABI and now use EABI instead implicitly, making it more likely that
> they could work.
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/Kconfig | 15 ++++++---------
> arch/arm/configs/am200epdkit_defconfig | 1 -
> arch/arm/configs/aspeed_g4_defconfig | 1 -
> arch/arm/configs/assabet_defconfig | 1 +
> arch/arm/configs/at91_dt_defconfig | 1 -
[..]
> diff --git a/arch/arm/configs/at91_dt_defconfig b/arch/arm/configs/at91_dt_defconfig
> index e331242dece7..320eb27a6a2e 100644
> --- a/arch/arm/configs/at91_dt_defconfig
> +++ b/arch/arm/configs/at91_dt_defconfig
> @@ -18,7 +18,6 @@ CONFIG_SOC_AT91SAM9=y
> CONFIG_SOC_SAM9X60=y
> CONFIG_SOC_SAM9X7=y
> # CONFIG_ATMEL_CLOCKSOURCE_PIT is not set
> -CONFIG_AEABI=y
> CONFIG_UACCESS_WITH_MEMCPY=y
> # CONFIG_ATAGS is not set
> CONFIG_ARM_APPENDED_DTB=y
As AEABI is by default to y:
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
[..]
Thanks, best regards,
Nicolas
^ permalink raw reply
* Re: [PATCH v2 0/6] KVM: arm64: ptdump: Shadow ptdump fixes
From: Wei-Lin Chang @ 2026-07-02 7:41 UTC (permalink / raw)
To: Itaru Kitayama
Cc: linux-arm-kernel, kvmarm, linux-kernel, Marc Zyngier,
Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Sebastian Ene
In-Reply-To: <akYLdEuPXEGIZx3E@sm-arm-grace07>
On Thu, Jul 02, 2026 at 03:55:48PM +0900, Itaru Kitayama wrote:
> Hi Wei-Lin,
> On Tue, Jun 30, 2026 at 01:09:59PM +0100, Wei-Lin Chang wrote:
> > Hi,
> >
> > This is v2 of fixing shadow ptdump debugfs files. Unfortunately I couldn't make
> > per mmu ptdump files work after all, mainly because there isn't a clean way to
> > locate the specific nested mmu for each ptdump file as the nested mmus could be
> > freed when the file gets opened. Therefore in this series a single file
> > "shadow_page_tables" is created that dumps all valid mmus' page table
> > information.
> >
> > An advantage of this is that this new ptdump file have a lifetime identical to
> > other ptdump files i.e. stage2_page_tables, ipa_range, etc., hence avoiding the
> > dentry UAF found last time [1].
> >
> > With this all ptdump files are only removed when the last kvm reference gets
> > dropped and kvm_destroy_vm_debugfs() is called, in their open(), show()
> > functions the nested mmu array and mmu->pgt are checked with mmu_lock held to
> > prevent UAF.
> >
> > Patch 1-2: Undo previous shadow ptdump implementation.
> > Patch 3: Fix a mmu->pgt UAF that happens when ptdump files are read after
> > mmu->pgt is freed.
> > Patch 4-5: Preparation for the shadow page table dump file.
> > Patch 6: Implementation of the shadow page table dump file.
> >
> > The fixes are tested with CONFIG_PROVE_LOCKING,
> > CONFIG_DEBUG_ATOMIC_SLEEP, and CONFIG_KASAN.
> >
> > Thanks!
>
> Running your shadow stage 2 kselftest with bpftrace shows me that __kvm_pgtable_stage2_init()
> for shadow stage 2 translation tables are built with ia_bits = 52 and
> start_level = 0, but the debugfs entry for the active shadow stage 2 tables prints
> out that's 3 levels. Is this fully expected?
Where is this level information you are seeing from? If it is
"stage2_level", that only reports the number of levels for the canonical
stage-2 (non nested). For nested mmus only the page tables are dumped in
nested/shadow_page_tables.
Thanks,
Wei-Lin Chang
>
> Thanks,
> Itaru.
>
> >
> > * Changes from v1 ([2]):
> >
> > - Move from per mmu ptdump files to one file that will dump all shadow page
> > tables.
> >
> > [1]: https://lore.kernel.org/kvmarm/ajty6I7ZqodP4ous@sm-arm-grace07/
> > [2]: https://lore.kernel.org/kvmarm/20260623142443.648972-1-weilin.chang@arm.com/
> >
> > Wei-Lin Chang (6):
> > KVM: arm64: ptdump: Remove shadow ptdump files
> > KVM: arm64: ptdump: Undo making the ptdump code mmu aware
> > KVM: arm64: ptdump: Fix UAF when mmu->pgt is freed
> > KVM: arm64: ptdump: Factor out initialization of
> > kvm_ptdump_guest_state
> > KVM: arm64: ptdump: Extract kvm_ptdump_guest_open() from canonical
> > ptdump path
> > KVM: arm64: ptdump: Introduce the shadow ptdump file
> >
> > arch/arm64/include/asm/kvm_host.h | 5 +-
> > arch/arm64/include/asm/kvm_mmu.h | 4 -
> > arch/arm64/kvm/nested.c | 18 +--
> > arch/arm64/kvm/ptdump.c | 185 ++++++++++++++++++++----------
> > 4 files changed, 135 insertions(+), 77 deletions(-)
> >
> > --
> > 2.43.0
> >
^ permalink raw reply
* Re: [PATCH v2 17/19] ARM: mark Cortex-M3/M4/M7 based boards as deprecated
From: Nicolas Ferre @ 2026-07-02 7:39 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel, soc
Cc: linux-kernel, Arnd Bergmann, Aaro Koskinen, Alexander Sverdlin,
Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
Claudiu Beznea, Daniel Mack, Ethan Nelson-Moore, Frank Li,
Gregory Clement, Haojian Zhuang, Jeremy J. Peper,
Kristoffer Ericson, Krzysztof Kozlowski, Linus Walleij,
Mark Brown, Marc Zyngier, Mike Rapoport, Patrice Chotard,
Ralph Siemsen, Robert Jarzmik, Russell King, Sascha Hauer,
Sebastian Hesselbarth, Stefan Agner, Stefan Wiehler,
Tony Lindgren, Vladimir Zapolskiy, Will Deacon
In-Reply-To: <20260701212353.2196041-18-arnd@kernel.org>
On 01/07/2026 at 23:23, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The Cortex-M3/M4/M7 cores were designed as a replacement for the earlier
> ARM7TDMI and ARM9TDMI microarchitectures used in older microcontrollers.
>
> At the moment, Linux can run these cores either when they are integrated
> into a larger SoC, or as standalone microcontrollers. While there was
> a lot of development work going into Cortex-M support from 2011 to 2016,
> this largely stopped when it became clear that Zephyr and other RTOS
> had taken over that market. To date, the only Cortex-M based based
> microcontroller boards supported upstream are reference implementations.
>
> Schedule these for removal after the next LTS kernel, so if any users
> remain that want to update their kernels, they can stay on that
> version for a few years before having to maintain the platform support
> out of tree.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/Kconfig | 8 ++++++--
> arch/arm/mach-at91/Kconfig | 4 +++-
> arch/arm/mach-imx/Kconfig | 4 +++-
> arch/arm/mach-stm32/Kconfig | 14 ++++++++------
> 4 files changed, 20 insertions(+), 10 deletions(-)
[..]
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index c5ef27e3cd8f..cb0e3ff8e0ca 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -15,13 +15,15 @@ menuconfig ARCH_AT91
>
> if ARCH_AT91
> config SOC_SAMV7
> - bool "SAM Cortex-M7 family" if ARM_SINGLE_ARMV7M
> + bool "SAM Cortex-M7 family (DEPRECATED)" if ARM_SINGLE_ARMV7M
> select COMMON_CLK_AT91
> select PINCTRL_AT91
> help
> Select this if you are using an SoC from Microchip's SAME7, SAMS7 or SAMV7
> families.
>
> + This platform is scheduled for removal in early 2027
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
> +
> config SOC_SAMA5D2
> bool "SAMA5D2 family"
> depends on ARCH_MULTI_V7
[..]
Thanks, regards,
Nicolas
^ permalink raw reply
* Re: [PATCH v4 net-next 1/2] dt-bindings: phy: cadence-torrent: Update property values to support 3 clocks
From: Krzysztof Kozlowski @ 2026-07-02 7:38 UTC (permalink / raw)
To: Gokul Praveen
Cc: conor+dt, devicetree, krzk+dt, linux-arm-kernel, linux-kernel,
linux-phy, neil.armstrong, nm, robh, sjakhade, kristo, vigneshr,
vkoul, yamonkar
In-Reply-To: <f40839d9-445e-4e48-ada9-97feb8e40584@ti.com>
On 02/07/2026 09:35, Gokul Praveen wrote:
> Hi Krzystof,
>
> On 02/07/26 11:53, Krzysztof Kozlowski wrote:
>> On Wed, Jul 01, 2026 at 07:54:56PM +0530, Gokul Praveen wrote:
>>> Update maxItems value of "clocks" property to 3 as description of
>>> this parameter already indicates 3 clocks(refclk,pll1_refclk(optional)
>>> and phy_en_refclk(optional)).
>> But what if description is wrong? You need to provide rationale why you
>> are doing it and you cannot use existing code alone as that rationale,
>> because as you pointed out - existing code is not fully correct.
>
> The description is correct because not all device may have 2 input
I do not see how you proved it in the commit msg.
> reference clocks , hence keeping the requirement of the 2nd reference
> clock(pll1_refclk) optional.
>
> Just as a note: phy_en_refclk is an output clock.
output clocks do not go to input clocks property.
>
> In those cases the multilink serdes configurations requiring 2 different
> input reference clocks will not work due to the limitation of having
> only 1 clock.
>
> However, when it comes to devices where 2 different input reference
> clocks are supported and a multilink serdes configuration is
> needed(where the links require separate reference clocks for each
> protocol so as to cater to the different clocking speed requirements of
> these links).
>
> Hence, in this case ,2 different input clocks are needed so as to cater
> to 2 different clock speeds.
>
> For eg: In the USXGMII+SGMII multilink serdes configuration which I had
> tested, it failed because
>
> USXGMII requires an input clock speed of 156.25 Mhz and SGMII protocol
> requires an input clock speed of 100 Mhz.
>
> But, since there was only one input clock(refclk) mentioned in the
> clocks and clock-name parameter , this multilink serdes configuration
> failed.
>
> Hence, to make it work, the pll1_refclk had to be added which provided a
> clock speed of 156.25 Mhz for USXGMI and the refclk provided
>
> a clock speed of 100 Mhz for SGMII.
>
>>> Update the maxItems and items value of "clock-names" property with multiple
>>> combination of clock-names possible since pll1_refclk and phy_en_refclk are
>>> optional clocks.
>> Why? You need to describe why you are doing this, not what you are
>> doing.
> Sure , Krzysztof, I will be careful about that and prioritize that in
> the commit message.
>>> Signed-off-by: Gokul Praveen <g-praveen@ti.com>
>>> ---
>>> .../bindings/phy/phy-cadence-torrent.yaml | 16 ++++++++++++----
>>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
>>> index 9af39b33646a..96c664d50629 100644
>>> --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
>>> +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
>>> @@ -34,7 +34,7 @@ properties:
>>>
>>> clocks:
>>> minItems: 1
>>> - maxItems: 2
>>> + maxItems: 3
>>> description:
>>> PHY input reference clocks - refclk (for PLL0) & pll1_refclk (for PLL1).
>>> pll1_refclk is optional and used for multi-protocol configurations requiring
>>> @@ -45,9 +45,17 @@ properties:
>>>
>>> clock-names:
>>> minItems: 1
>>> - items:
>>> - - const: refclk
>>> - - enum: [ pll1_refclk, phy_en_refclk ]
>>> + maxItems: 3
>> Drop
> Sure, i will do that Krzysztof.
>>> + oneOf:
>>> + - items:
>>> + - const: refclk
>>> + - items:
>>> + - const: refclk
>>> + - enum: [ pll1_refclk, phy_en_refclk ]
>> Drop these, pointless. You were supposed to grow existing syntax.
>>
>>> + - items:
>>> + - const: refclk
>>> + - const: pll1_refclk
>> So here is the enum.
>>
>>> + - const: phy_en_refclk
>> And this stays.
>>
>> You make changes which do not make the binding better and are not
>> explained in commit msg. Focus on WHY you are doing things and also
>> explain WHY you did such complicated syntax (if you insist on rewriting
>> correct code into something odd we do not expect).
>
> So, the reason I added the oneOf property is to support the following
> combinations because pll1_refclk and phy_en_refclk are optional clocks.
> With the earlier enum , only either of pll1_refclk or phy_en_refclk
>
> can be used and both cannot be used at the same time.
>
> Combination 1: refclk
>
> Combination 2 : refclk, pll1_refclk
>
> Combination 3: reclk, phy_en_refclk
>
> Combination 4: refclk, pll1_refclk, phy_en_refclk
>
>
> Please feel free to suggest any alternative solution to support these
> combinations .
I already did. Read the feedback carefully.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 01/16] media: sun6i-csi: bridge: Use V4L2 subdev active state
From: arash golgol @ 2026-07-02 7:38 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: linux-media, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-staging, Mauro Carvalho Chehab, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Greg Kroah-Hartman,
Laurent Pinchart, Nicolas Dufresne
In-Reply-To: <20260518102451.417971-2-paulk@sys-base.io>
Hi Paul,
On Mon, May 18, 2026 at 1:55 PM Paul Kocialkowski <paulk@sys-base.io> wrote:
>
> From: Arash Golgol <arash.golgol@gmail.com>
>
> Use the V4L2 subdev active state API to store the active format.
> This simplifies the driver not only by dropping the bridge mbus_format
> field, but it also allows dropping the bridge lock, replaced with
> the state lock.
>
> Previously, capture accessed bridge private state directly. After
> moving to framework-managed state, resolve the format through the
> subdev pad API.
>
> The sun6i-csi-bridge hardware does not perform any format conversion.
> Enforce identical formats on the sink and source pads in the set_fmt()
> and init_state() callbacks.
>
> Signed-off-by: Arash Golgol <arash.golgol@gmail.com>
> Reviewed-by: Paul Kocialkowski <paulk@sys-base.io>
> Tested-by: Paul Kocialkowski <paulk@sys-base.io>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
I noticed this series didn't make it into the v7.2 merge window.
Is there anything still pending on my side before it can be picked up,
or is it just a matter of timing for the next cycle?
Happy to help however I can.
> ---
> .../sunxi/sun6i-csi/sun6i_csi_bridge.c | 155 ++++++++----------
> .../sunxi/sun6i-csi/sun6i_csi_bridge.h | 9 -
> .../sunxi/sun6i-csi/sun6i_csi_capture.c | 27 ++-
> 3 files changed, 86 insertions(+), 105 deletions(-)
>
> diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_bridge.c b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_bridge.c
> index d006d9dd0170..43a85bcc2ba2 100644
> --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_bridge.c
> +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_bridge.c
> @@ -13,26 +13,6 @@
> #include "sun6i_csi_bridge.h"
> #include "sun6i_csi_reg.h"
>
> -/* Helpers */
> -
> -void sun6i_csi_bridge_dimensions(struct sun6i_csi_device *csi_dev,
> - unsigned int *width, unsigned int *height)
> -{
> - if (width)
> - *width = csi_dev->bridge.mbus_format.width;
> - if (height)
> - *height = csi_dev->bridge.mbus_format.height;
> -}
> -
> -void sun6i_csi_bridge_format(struct sun6i_csi_device *csi_dev,
> - u32 *mbus_code, u32 *field)
> -{
> - if (mbus_code)
> - *mbus_code = csi_dev->bridge.mbus_format.code;
> - if (field)
> - *field = csi_dev->bridge.mbus_format.field;
> -}
> -
> /* Format */
>
> static const struct sun6i_csi_bridge_format sun6i_csi_bridge_formats[] = {
> @@ -226,7 +206,8 @@ static void sun6i_csi_bridge_disable(struct sun6i_csi_device *csi_dev)
> }
>
> static void
> -sun6i_csi_bridge_configure_parallel(struct sun6i_csi_device *csi_dev)
> +sun6i_csi_bridge_configure_parallel(struct sun6i_csi_device *csi_dev,
> + const struct v4l2_mbus_framefmt *mbus_format)
> {
> struct device *dev = csi_dev->dev;
> struct regmap *regmap = csi_dev->regmap;
> @@ -234,11 +215,9 @@ sun6i_csi_bridge_configure_parallel(struct sun6i_csi_device *csi_dev)
> &csi_dev->bridge.source_parallel.endpoint;
> unsigned char bus_width = endpoint->bus.parallel.bus_width;
> unsigned int flags = endpoint->bus.parallel.flags;
> - u32 field;
> + u32 field = mbus_format->field;
> u32 value = SUN6I_CSI_IF_CFG_IF_CSI;
>
> - sun6i_csi_bridge_format(csi_dev, NULL, &field);
> -
> if (field == V4L2_FIELD_INTERLACED ||
> field == V4L2_FIELD_INTERLACED_TB ||
> field == V4L2_FIELD_INTERLACED_BT)
> @@ -317,13 +296,12 @@ sun6i_csi_bridge_configure_parallel(struct sun6i_csi_device *csi_dev)
> }
>
> static void
> -sun6i_csi_bridge_configure_mipi_csi2(struct sun6i_csi_device *csi_dev)
> +sun6i_csi_bridge_configure_mipi_csi2(struct sun6i_csi_device *csi_dev,
> + const struct v4l2_mbus_framefmt *mbus_format)
> {
> struct regmap *regmap = csi_dev->regmap;
> u32 value = SUN6I_CSI_IF_CFG_IF_MIPI;
> - u32 field;
> -
> - sun6i_csi_bridge_format(csi_dev, NULL, &field);
> + u32 field = mbus_format->field;
>
> if (field == V4L2_FIELD_INTERLACED ||
> field == V4L2_FIELD_INTERLACED_TB ||
> @@ -335,19 +313,20 @@ sun6i_csi_bridge_configure_mipi_csi2(struct sun6i_csi_device *csi_dev)
> regmap_write(regmap, SUN6I_CSI_IF_CFG_REG, value);
> }
>
> -static void sun6i_csi_bridge_configure_format(struct sun6i_csi_device *csi_dev)
> +static void
> +sun6i_csi_bridge_configure_format(struct sun6i_csi_device *csi_dev,
> + const struct v4l2_mbus_framefmt *mbus_format)
> {
> struct regmap *regmap = csi_dev->regmap;
> bool capture_streaming = csi_dev->capture.state.streaming;
> const struct sun6i_csi_bridge_format *bridge_format;
> const struct sun6i_csi_capture_format *capture_format;
> - u32 mbus_code, field, pixelformat;
> + u32 pixelformat;
> + u32 field = mbus_format->field;
> u8 input_format, input_yuv_seq, output_format;
> u32 value = 0;
>
> - sun6i_csi_bridge_format(csi_dev, &mbus_code, &field);
> -
> - bridge_format = sun6i_csi_bridge_format_find(mbus_code);
> + bridge_format = sun6i_csi_bridge_format_find(mbus_format->code);
> if (WARN_ON(!bridge_format))
> return;
>
> @@ -391,16 +370,17 @@ static void sun6i_csi_bridge_configure_format(struct sun6i_csi_device *csi_dev)
> }
>
> static void sun6i_csi_bridge_configure(struct sun6i_csi_device *csi_dev,
> - struct sun6i_csi_bridge_source *source)
> + struct sun6i_csi_bridge_source *source,
> + const struct v4l2_mbus_framefmt *mbus_format)
> {
> struct sun6i_csi_bridge *bridge = &csi_dev->bridge;
>
> if (source == &bridge->source_parallel)
> - sun6i_csi_bridge_configure_parallel(csi_dev);
> + sun6i_csi_bridge_configure_parallel(csi_dev, mbus_format);
> else
> - sun6i_csi_bridge_configure_mipi_csi2(csi_dev);
> + sun6i_csi_bridge_configure_mipi_csi2(csi_dev, mbus_format);
>
> - sun6i_csi_bridge_configure_format(csi_dev);
> + sun6i_csi_bridge_configure_format(csi_dev, mbus_format);
> }
>
> /* V4L2 Subdev */
> @@ -415,6 +395,8 @@ static int sun6i_csi_bridge_s_stream(struct v4l2_subdev *subdev, int on)
> struct sun6i_csi_bridge_source *source;
> struct v4l2_subdev *source_subdev;
> struct media_pad *remote_pad;
> + struct v4l2_subdev_state *state;
> + const struct v4l2_mbus_framefmt *mbus_format;
> int ret;
>
> /* Source */
> @@ -433,6 +415,10 @@ static int sun6i_csi_bridge_s_stream(struct v4l2_subdev *subdev, int on)
> else
> source = &bridge->source_mipi_csi2;
>
> + /* Active State */
> +
> + state = v4l2_subdev_lock_and_get_active_state(subdev);
> +
> if (!on) {
> v4l2_subdev_call(source_subdev, video, s_stream, 0);
> ret = 0;
> @@ -443,7 +429,7 @@ static int sun6i_csi_bridge_s_stream(struct v4l2_subdev *subdev, int on)
>
> ret = pm_runtime_resume_and_get(dev);
> if (ret < 0)
> - return ret;
> + goto unlock;
>
> /* Clear */
>
> @@ -451,7 +437,9 @@ static int sun6i_csi_bridge_s_stream(struct v4l2_subdev *subdev, int on)
>
> /* Configure */
>
> - sun6i_csi_bridge_configure(csi_dev, source);
> + mbus_format = v4l2_subdev_state_get_format(state,
> + SUN6I_CSI_BRIDGE_PAD_SINK);
> + sun6i_csi_bridge_configure(csi_dev, source, mbus_format);
>
> if (capture_streaming)
> sun6i_csi_capture_configure(csi_dev);
> @@ -472,7 +460,8 @@ static int sun6i_csi_bridge_s_stream(struct v4l2_subdev *subdev, int on)
> if (ret && ret != -ENOIOCTLCMD)
> goto disable;
>
> - return 0;
> + ret = 0;
> + goto unlock;
>
> disable:
> if (capture_streaming)
> @@ -482,6 +471,8 @@ static int sun6i_csi_bridge_s_stream(struct v4l2_subdev *subdev, int on)
>
> pm_runtime_put(dev);
>
> +unlock:
> + v4l2_subdev_unlock_state(state);
> return ret;
> }
>
> @@ -504,21 +495,23 @@ sun6i_csi_bridge_mbus_format_prepare(struct v4l2_mbus_framefmt *mbus_format)
> static int sun6i_csi_bridge_init_state(struct v4l2_subdev *subdev,
> struct v4l2_subdev_state *state)
> {
> - struct sun6i_csi_device *csi_dev = v4l2_get_subdevdata(subdev);
> - unsigned int pad = SUN6I_CSI_BRIDGE_PAD_SINK;
> - struct v4l2_mbus_framefmt *mbus_format =
> - v4l2_subdev_state_get_format(state, pad);
> - struct mutex *lock = &csi_dev->bridge.lock;
> + unsigned int pad;
>
> - mutex_lock(lock);
> + /*
> + * This subdev does not perform format conversion,
> + * initialize both pads identically.
> + */
> + for (pad = 0; pad < subdev->entity.num_pads; pad++) {
> + struct v4l2_mbus_framefmt *mbus_format;
>
> - mbus_format->code = sun6i_csi_bridge_formats[0].mbus_code;
> - mbus_format->width = 1280;
> - mbus_format->height = 720;
> + mbus_format = v4l2_subdev_state_get_format(state, pad);
>
> - sun6i_csi_bridge_mbus_format_prepare(mbus_format);
> + mbus_format->code = sun6i_csi_bridge_formats[0].mbus_code;
> + mbus_format->width = 1280;
> + mbus_format->height = 720;
>
> - mutex_unlock(lock);
> + sun6i_csi_bridge_mbus_format_prepare(mbus_format);
> + }
>
> return 0;
> }
> @@ -536,53 +529,32 @@ sun6i_csi_bridge_enum_mbus_code(struct v4l2_subdev *subdev,
> return 0;
> }
>
> -static int sun6i_csi_bridge_get_fmt(struct v4l2_subdev *subdev,
> - struct v4l2_subdev_state *state,
> - struct v4l2_subdev_format *format)
> -{
> - struct sun6i_csi_device *csi_dev = v4l2_get_subdevdata(subdev);
> - struct v4l2_mbus_framefmt *mbus_format = &format->format;
> - struct mutex *lock = &csi_dev->bridge.lock;
> -
> - mutex_lock(lock);
> -
> - if (format->which == V4L2_SUBDEV_FORMAT_TRY)
> - *mbus_format = *v4l2_subdev_state_get_format(state,
> - format->pad);
> - else
> - *mbus_format = csi_dev->bridge.mbus_format;
> -
> - mutex_unlock(lock);
> -
> - return 0;
> -}
> -
> static int sun6i_csi_bridge_set_fmt(struct v4l2_subdev *subdev,
> struct v4l2_subdev_state *state,
> struct v4l2_subdev_format *format)
> {
> - struct sun6i_csi_device *csi_dev = v4l2_get_subdevdata(subdev);
> - struct v4l2_mbus_framefmt *mbus_format = &format->format;
> - struct mutex *lock = &csi_dev->bridge.lock;
> + struct v4l2_mbus_framefmt *fmt;
>
> - mutex_lock(lock);
> + /* The format on the source pad always matches the sink pad. */
> + if (format->pad != SUN6I_CSI_BRIDGE_PAD_SINK)
> + return v4l2_subdev_get_fmt(subdev, state, format);
>
> - sun6i_csi_bridge_mbus_format_prepare(mbus_format);
> + sun6i_csi_bridge_mbus_format_prepare(&format->format);
>
> - if (format->which == V4L2_SUBDEV_FORMAT_TRY)
> - *v4l2_subdev_state_get_format(state, format->pad) =
> - *mbus_format;
> - else
> - csi_dev->bridge.mbus_format = *mbus_format;
> + /* Set the format on the sink pad. */
> + fmt = v4l2_subdev_state_get_format(state, format->pad);
> + *fmt = format->format;
>
> - mutex_unlock(lock);
> + /* Propagate the format to the source pad. */
> + fmt = v4l2_subdev_state_get_format(state, SUN6I_CSI_BRIDGE_PAD_SOURCE);
> + *fmt = format->format;
>
> return 0;
> }
>
> static const struct v4l2_subdev_pad_ops sun6i_csi_bridge_pad_ops = {
> .enum_mbus_code = sun6i_csi_bridge_enum_mbus_code,
> - .get_fmt = sun6i_csi_bridge_get_fmt,
> + .get_fmt = v4l2_subdev_get_fmt,
> .set_fmt = sun6i_csi_bridge_set_fmt,
> };
>
> @@ -780,8 +752,6 @@ int sun6i_csi_bridge_setup(struct sun6i_csi_device *csi_dev)
> };
> int ret;
>
> - mutex_init(&bridge->lock);
> -
> /* V4L2 Subdev */
>
> v4l2_subdev_init(subdev, &sun6i_csi_bridge_subdev_ops);
> @@ -809,6 +779,12 @@ int sun6i_csi_bridge_setup(struct sun6i_csi_device *csi_dev)
> if (ret < 0)
> return ret;
>
> + /* V4L2 Subdev finalize */
> +
> + ret = v4l2_subdev_init_finalize(subdev);
> + if (ret < 0)
> + goto error_media_entity;
> +
> /* V4L2 Subdev */
>
> if (csi_dev->isp_available)
> @@ -818,7 +794,7 @@ int sun6i_csi_bridge_setup(struct sun6i_csi_device *csi_dev)
>
> if (ret) {
> dev_err(dev, "failed to register v4l2 subdev: %d\n", ret);
> - goto error_media_entity;
> + goto error_subdev_finalize;
> }
>
> /* V4L2 Async */
> @@ -852,6 +828,9 @@ int sun6i_csi_bridge_setup(struct sun6i_csi_device *csi_dev)
> else
> v4l2_device_unregister_subdev(subdev);
>
> +error_subdev_finalize:
> + v4l2_subdev_cleanup(subdev);
> +
> error_media_entity:
> media_entity_cleanup(&subdev->entity);
>
> @@ -868,5 +847,7 @@ void sun6i_csi_bridge_cleanup(struct sun6i_csi_device *csi_dev)
>
> v4l2_device_unregister_subdev(subdev);
>
> + v4l2_subdev_cleanup(subdev);
> +
> media_entity_cleanup(&subdev->entity);
> }
> diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_bridge.h b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_bridge.h
> index 44653b38f722..a5b0a6f064dd 100644
> --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_bridge.h
> +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_bridge.h
> @@ -42,20 +42,11 @@ struct sun6i_csi_bridge {
> struct v4l2_subdev subdev;
> struct v4l2_async_notifier notifier;
> struct media_pad pads[2];
> - struct v4l2_mbus_framefmt mbus_format;
> - struct mutex lock; /* Mbus format lock. */
>
> struct sun6i_csi_bridge_source source_parallel;
> struct sun6i_csi_bridge_source source_mipi_csi2;
> };
>
> -/* Helpers */
> -
> -void sun6i_csi_bridge_dimensions(struct sun6i_csi_device *csi_dev,
> - unsigned int *width, unsigned int *height);
> -void sun6i_csi_bridge_format(struct sun6i_csi_device *csi_dev,
> - u32 *mbus_code, u32 *field);
> -
> /* Format */
>
> const struct sun6i_csi_bridge_format *
> diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_capture.c b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_capture.c
> index 65879f4802c0..d90abba21309 100644
> --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_capture.c
> +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_capture.c
> @@ -888,14 +888,19 @@ static int sun6i_csi_capture_link_validate(struct media_link *link)
> media_entity_to_video_device(link->sink->entity);
> struct sun6i_csi_device *csi_dev = video_get_drvdata(video_dev);
> struct v4l2_device *v4l2_dev = csi_dev->v4l2_dev;
> + struct v4l2_subdev *src_subdev =
> + media_entity_to_v4l2_subdev(link->source->entity);
> const struct sun6i_csi_capture_format *capture_format;
> const struct sun6i_csi_bridge_format *bridge_format;
> unsigned int capture_width, capture_height;
> - unsigned int bridge_width, bridge_height;
> const struct v4l2_format_info *format_info;
> + struct v4l2_subdev_format src_fmt = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + .pad = link->source->index
> + };
> u32 pixelformat, capture_field;
> - u32 mbus_code, bridge_field;
> bool match;
> + int ret;
>
> sun6i_csi_capture_dimensions(csi_dev, &capture_width, &capture_height);
>
> @@ -904,19 +909,22 @@ static int sun6i_csi_capture_link_validate(struct media_link *link)
> if (WARN_ON(!capture_format))
> return -EINVAL;
>
> - sun6i_csi_bridge_dimensions(csi_dev, &bridge_width, &bridge_height);
> + /* Resolve csi bridge format. */
> + ret = v4l2_subdev_call(src_subdev, pad, get_fmt, NULL, &src_fmt);
> + if (ret)
> + return ret;
>
> - sun6i_csi_bridge_format(csi_dev, &mbus_code, &bridge_field);
> - bridge_format = sun6i_csi_bridge_format_find(mbus_code);
> + bridge_format = sun6i_csi_bridge_format_find(src_fmt.format.code);
> if (WARN_ON(!bridge_format))
> return -EINVAL;
>
> /* No cropping/scaling is supported. */
> - if (capture_width != bridge_width || capture_height != bridge_height) {
> + if (capture_width != src_fmt.format.width ||
> + capture_height != src_fmt.format.height) {
> v4l2_err(v4l2_dev,
> "invalid input/output dimensions: %ux%u/%ux%u\n",
> - bridge_width, bridge_height, capture_width,
> - capture_height);
> + src_fmt.format.width, src_fmt.format.height,
> + capture_width, capture_height);
> return -EINVAL;
> }
>
> @@ -947,7 +955,8 @@ static int sun6i_csi_capture_link_validate(struct media_link *link)
> /* With raw input mode, we need a 1:1 match between input and output. */
> if (bridge_format->input_format == SUN6I_CSI_INPUT_FMT_RAW ||
> capture_format->input_format_raw) {
> - match = sun6i_csi_capture_format_match(pixelformat, mbus_code);
> + match = sun6i_csi_capture_format_match(pixelformat,
> + src_fmt.format.code);
> if (!match)
> goto invalid;
> }
> --
> 2.54.0
>
--
Regards,
Arash Golgol
^ permalink raw reply
* Re: [PATCH v4 net-next 1/2] dt-bindings: phy: cadence-torrent: Update property values to support 3 clocks
From: Gokul Praveen @ 2026-07-02 7:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: conor+dt, devicetree, krzk+dt, linux-arm-kernel, linux-kernel,
linux-phy, neil.armstrong, nm, robh, sjakhade, kristo, vigneshr,
vkoul, yamonkar, Gokul Praveen
In-Reply-To: <20260702-vigilant-tody-of-inquire-ffbede@quoll>
Hi Krzystof,
On 02/07/26 11:53, Krzysztof Kozlowski wrote:
> On Wed, Jul 01, 2026 at 07:54:56PM +0530, Gokul Praveen wrote:
>> Update maxItems value of "clocks" property to 3 as description of
>> this parameter already indicates 3 clocks(refclk,pll1_refclk(optional)
>> and phy_en_refclk(optional)).
> But what if description is wrong? You need to provide rationale why you
> are doing it and you cannot use existing code alone as that rationale,
> because as you pointed out - existing code is not fully correct.
The description is correct because not all device may have 2 input
reference clocks , hence keeping the requirement of the 2nd reference
clock(pll1_refclk) optional.
Just as a note: phy_en_refclk is an output clock.
In those cases the multilink serdes configurations requiring 2 different
input reference clocks will not work due to the limitation of having
only 1 clock.
However, when it comes to devices where 2 different input reference
clocks are supported and a multilink serdes configuration is
needed(where the links require separate reference clocks for each
protocol so as to cater to the different clocking speed requirements of
these links).
Hence, in this case ,2 different input clocks are needed so as to cater
to 2 different clock speeds.
For eg: In the USXGMII+SGMII multilink serdes configuration which I had
tested, it failed because
USXGMII requires an input clock speed of 156.25 Mhz and SGMII protocol
requires an input clock speed of 100 Mhz.
But, since there was only one input clock(refclk) mentioned in the
clocks and clock-name parameter , this multilink serdes configuration
failed.
Hence, to make it work, the pll1_refclk had to be added which provided a
clock speed of 156.25 Mhz for USXGMI and the refclk provided
a clock speed of 100 Mhz for SGMII.
>> Update the maxItems and items value of "clock-names" property with multiple
>> combination of clock-names possible since pll1_refclk and phy_en_refclk are
>> optional clocks.
> Why? You need to describe why you are doing this, not what you are
> doing.
Sure , Krzysztof, I will be careful about that and prioritize that in
the commit message.
>> Signed-off-by: Gokul Praveen <g-praveen@ti.com>
>> ---
>> .../bindings/phy/phy-cadence-torrent.yaml | 16 ++++++++++++----
>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
>> index 9af39b33646a..96c664d50629 100644
>> --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
>> +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
>> @@ -34,7 +34,7 @@ properties:
>>
>> clocks:
>> minItems: 1
>> - maxItems: 2
>> + maxItems: 3
>> description:
>> PHY input reference clocks - refclk (for PLL0) & pll1_refclk (for PLL1).
>> pll1_refclk is optional and used for multi-protocol configurations requiring
>> @@ -45,9 +45,17 @@ properties:
>>
>> clock-names:
>> minItems: 1
>> - items:
>> - - const: refclk
>> - - enum: [ pll1_refclk, phy_en_refclk ]
>> + maxItems: 3
> Drop
Sure, i will do that Krzysztof.
>> + oneOf:
>> + - items:
>> + - const: refclk
>> + - items:
>> + - const: refclk
>> + - enum: [ pll1_refclk, phy_en_refclk ]
> Drop these, pointless. You were supposed to grow existing syntax.
>
>> + - items:
>> + - const: refclk
>> + - const: pll1_refclk
> So here is the enum.
>
>> + - const: phy_en_refclk
> And this stays.
>
> You make changes which do not make the binding better and are not
> explained in commit msg. Focus on WHY you are doing things and also
> explain WHY you did such complicated syntax (if you insist on rewriting
> correct code into something odd we do not expect).
So, the reason I added the oneOf property is to support the following
combinations because pll1_refclk and phy_en_refclk are optional clocks.
With the earlier enum , only either of pll1_refclk or phy_en_refclk
can be used and both cannot be used at the same time.
Combination 1: refclk
Combination 2 : refclk, pll1_refclk
Combination 3: reclk, phy_en_refclk
Combination 4: refclk, pll1_refclk, phy_en_refclk
Please feel free to suggest any alternative solution to support these
combinations .
>
> Best regards,
> Krzysztof
>
>
^ permalink raw reply
* Re: [PATCH v2 1/5] arm64: dts: lx2160a: transition to device-specific SerDes compatible strings
From: Ioana Ciornei @ 2026-07-02 7:35 UTC (permalink / raw)
To: Frank Li
Cc: Frank.Li, robh, krzk+dt, conor+dt, devicetree, vladimir.oltean,
linux-arm-kernel, linux-kernel, imx
In-Reply-To: <akUjt5OPiO5cJ1D9@SMW015318>
On Wed, Jul 01, 2026 at 09:27:03AM -0500, Frank Li wrote:
> On Wed, Jul 01, 2026 at 04:11:33PM +0300, Ioana Ciornei wrote:
> > From: Vladimir Oltean <vladimir.oltean@nxp.com>
> >
> > Align to the modern fsl,lynx-28g.yaml binding, where the SoC and SerDes
> > instance is present in the compatible string, to allow reliable per-lane
> > capability detection and per-lane customization of electrical properties.
> >
> > The modern bindings are backward-incompatible with old kernels, due
> > to the consumer phandles being either in one form or in another, as
> > explained here:
> > https://lore.kernel.org/lkml/20250930140735.mvo3jii7wgmzh2bs@skbuf/
> >
> > One of the major differences between the LX2160A and LX2162A is the
> > SerDes. So far, LX2162A has used fsl-lx2160a-rev2.dtsi, but we need to
> > split that up even further, and derive a fsl-lx2162a.dtsi which
> > overrides the SerDes properties.
> >
> > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
> > ---
> > Changes in v2:
> > - Enable serdes_1 on all board DTs that has consumers for it.
> > - Use the proper name for serdes_3 in fsl-lx2162a.dtsi.
> > - Remove paragraph from commit message which mentioned some consumer
> > changes that are no longer needed nor part of the commit.
> > ---
> > .../freescale/fsl-lx2160a-clearfog-itx.dtsi | 4 +
> > .../dts/freescale/fsl-lx2160a-half-twins.dts | 4 +
> > .../boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 +
> > .../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 150 +++++++++++++++++-
> > .../dts/freescale/fsl-lx2162a-clearfog.dts | 6 +-
> > .../boot/dts/freescale/fsl-lx2162a-qds.dts | 2 +-
> > .../arm64/boot/dts/freescale/fsl-lx2162a.dtsi | 24 +++
> > 7 files changed, 190 insertions(+), 4 deletions(-)
> > create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
> >
> ...
> >
> > +&serdes_1 {
> > + status = "okay";
> > +};
> > +
>
> Can you try keep alphabet order? may old file is not ordersed, but try
> best, at least should before &uart0
Sure, will move it.
>
> > &uart1 {
> > status = "okay";
> > };
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > index 1d73abffa6b7..a687eb3e3190 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>
> Please split chips dtsi and boards dts to two patch.
Ok, I will split the serdes_1 explicit enable into a prep patch.
>
> > @@ -621,17 +621,163 @@ soc: soc {
> > ranges;
> > dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
> >
> > + /* Note on the interpretation of SerDes lane numbering from
> > + * LX2160ARM lane mappings for RCW[SRDS_PRTCL_S1]:
> > + * The letters (A-H) correspond to logical lane numbers in the
> > + * SerDes register map (lane A's registers start with LNAGCR0),
> > + * while the numbers (0-7) correspond to physical lanes as
> > + * routed to pins. SerDes block #1 is flipped in the LX2160A
> > + * floorplan (logical lane A goes to physical lane 7's pins),
> > + * while SerDes blocks #2 and #3 are not. The lanes below are
> > + * listed right to left when looking at that table.
> > + * Both the numbers and the letters are according to the logical
> > + * numbering scheme, and do not account for the flipping.
> > + */
> ...
> > + compatible = "fsl,lx2160a-serdes3";
> > + reg = <0x0 0x1ec0000 0x0 0x1e30>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + status = "disabled";
>
> status should be last property
Ok, will move it.
>
> > + #phy-cells = <1>;
> > +
> > + serdes_3_lane_a: phy@0 {
> > + reg = <0>;
> > + #phy-cells = <0>;
> > + };
> > +
> ...
> > +
> > +#include "fsl-lx2160a-rev2.dtsi"
> > +
> > +&serdes_1 {
> > + compatible = "fsl,lx2162a-serdes1", "fsl,lynx-28g";
> > +
> > + /delete-node/ phy@0;
> > + /delete-node/ phy@1;
> > + /delete-node/ phy@2;
> > + /delete-node/ phy@3;
>
> Now, do not perfer delete-node. if ver2 is not include phy@0, ...
>
> create ver2 files, let ver2 include it. Now most people like A + B, not
> A - B.
>
I am not sure I follow what you say about the ver2 files - are you
referring to -rev2 or LX2162A?
The LX2162A is a version of the LX2160A SoC, also known as "LX2-Lite".
And the main difference is that the LX2162A does not have the 3rd SerDes
block and only 4 SerDes lanes on the first block.
The delete-node is reflecting exactly how the SoCs came about, the
LX2162A is a smaller version of the LX2160A (which came first) and not
the other way around.
I feel like it's unnecessary churn but let me know if you feel strongly
about this.
Thanks,
Ioana
^ 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