* Re: [PATCH net-next 1/4] dt-bindings: net: dsa: add MT7628 ESW
From: Joris Vaisvila @ 2026-03-27 15:35 UTC (permalink / raw)
To: Daniel Golle
Cc: netdev, horms, pabeni, kuba, edumazet, davem, olteanv,
Andrew Lunn, devicetree, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <acZqvZfYXR_4sMlT@makrotopia.org>
On Fri, Mar 27, 2026 at 11:32:13AM +0000, Daniel Golle wrote:
> > [...]
> > On the hardware I'm testing on, it works fine with the port set to
> > "internal" or "rgmii". Would it make more sense to set "internal" then?
>
> "internal" then. It's a single-die SoC, the switch sharing the same
> memory space, clocking domain, ... with all the rest of the SoC makes
> it very unlikely that RGMII would be used as an on-die connection
> type. (unlike eg. MT7621 or MT7623A which are using multiple dies in
> the same package, and actually RGMII or TRGMII to connect the
> MDIO-managed switch part to the main SoC, see "MCM" / "multi-chip
> module" in the mt7530 driver...)
Makes sense, will change CPU port to internal in v2.
Thanks,
Joris
^ permalink raw reply
* RE: [PATCH net-next 2/5] dpll: zl3073x: use FIELD_MODIFY() for clear-and-set patterns
From: Prathosh.Satish @ 2026-03-27 15:35 UTC (permalink / raw)
To: ivecera, netdev
Cc: arkadiusz.kubalewski, jiri, mschmidt, poros, horms,
vadim.fedorenko, linux-kernel, conor+dt, krzk+dt, robh,
devicetree, pvaanane
In-Reply-To: <20260319174826.7623-3-ivecera@redhat.com>
Reviewed-by: prathosh.satish@microchip.com
-----Original Message-----
From: Ivan Vecera <ivecera@redhat.com>
Sent: Thursday, March 19, 2026 5:48 PM
To: netdev@vger.kernel.org
Cc: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>; Jiri Pirko <jiri@resnulli.us>; Michal Schmidt <mschmidt@redhat.com>; Petr Oros <poros@redhat.com>; Prathosh Satish - M66066 <Prathosh.Satish@microchip.com>; Simon Horman <horms@kernel.org>; Vadim Fedorenko <vadim.fedorenko@linux.dev>; linux-kernel@vger.kernel.org; Conor Dooley <conor+dt@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Rob Herring <robh@kernel.org>; devicetree@vger.kernel.org; Pasi Vaananen <pvaanane@redhat.com>
Subject: [PATCH net-next 2/5] dpll: zl3073x: use FIELD_MODIFY() for clear-and-set patterns
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
Replace open-coded clear-and-set bitfield operations with FIELD_MODIFY().
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/dpll/zl3073x/chan.h | 17 ++++++----------- drivers/dpll/zl3073x/core.c | 3 +-- drivers/dpll/zl3073x/flash.c | 3 +--
3 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/dpll/zl3073x/chan.h b/drivers/dpll/zl3073x/chan.h index e0f02d3432086..481da2133202b 100644
--- a/drivers/dpll/zl3073x/chan.h
+++ b/drivers/dpll/zl3073x/chan.h
@@ -66,8 +66,7 @@ static inline u8 zl3073x_chan_ref_get(const struct zl3073x_chan *chan)
*/
static inline void zl3073x_chan_mode_set(struct zl3073x_chan *chan, u8 mode) {
- chan->mode_refsel &= ~ZL_DPLL_MODE_REFSEL_MODE;
- chan->mode_refsel |= FIELD_PREP(ZL_DPLL_MODE_REFSEL_MODE, mode);
+ FIELD_MODIFY(ZL_DPLL_MODE_REFSEL_MODE, &chan->mode_refsel,
+ mode);
}
/**
@@ -77,8 +76,7 @@ static inline void zl3073x_chan_mode_set(struct zl3073x_chan *chan, u8 mode)
*/
static inline void zl3073x_chan_ref_set(struct zl3073x_chan *chan, u8 ref) {
- chan->mode_refsel &= ~ZL_DPLL_MODE_REFSEL_REF;
- chan->mode_refsel |= FIELD_PREP(ZL_DPLL_MODE_REFSEL_REF, ref);
+ FIELD_MODIFY(ZL_DPLL_MODE_REFSEL_REF, &chan->mode_refsel, ref);
}
/**
@@ -110,13 +108,10 @@ zl3073x_chan_ref_prio_set(struct zl3073x_chan *chan, u8 ref, u8 prio) {
u8 *val = &chan->ref_prio[ref / 2];
- if (!(ref & 1)) {
- *val &= ~ZL_DPLL_REF_PRIO_REF_P;
- *val |= FIELD_PREP(ZL_DPLL_REF_PRIO_REF_P, prio);
- } else {
- *val &= ~ZL_DPLL_REF_PRIO_REF_N;
- *val |= FIELD_PREP(ZL_DPLL_REF_PRIO_REF_N, prio);
- }
+ if (!(ref & 1))
+ FIELD_MODIFY(ZL_DPLL_REF_PRIO_REF_P, val, prio);
+ else
+ FIELD_MODIFY(ZL_DPLL_REF_PRIO_REF_N, val, prio);
}
/**
diff --git a/drivers/dpll/zl3073x/core.c b/drivers/dpll/zl3073x/core.c index 6363002d48d46..7eebfc1ad1019 100644
--- a/drivers/dpll/zl3073x/core.c
+++ b/drivers/dpll/zl3073x/core.c
@@ -743,8 +743,7 @@ int zl3073x_dev_phase_avg_factor_set(struct zl3073x_dev *zldev, u8 factor)
value = (factor + 1) & 0x0f;
/* Update phase measurement control register */
- dpll_meas_ctrl &= ~ZL_DPLL_MEAS_CTRL_AVG_FACTOR;
- dpll_meas_ctrl |= FIELD_PREP(ZL_DPLL_MEAS_CTRL_AVG_FACTOR, value);
+ FIELD_MODIFY(ZL_DPLL_MEAS_CTRL_AVG_FACTOR, &dpll_meas_ctrl,
+ value);
rc = zl3073x_write_u8(zldev, ZL_REG_DPLL_MEAS_CTRL, dpll_meas_ctrl);
if (rc)
return rc;
diff --git a/drivers/dpll/zl3073x/flash.c b/drivers/dpll/zl3073x/flash.c index 83452a77e3e98..f85535c8ad246 100644
--- a/drivers/dpll/zl3073x/flash.c
+++ b/drivers/dpll/zl3073x/flash.c
@@ -194,8 +194,7 @@ zl3073x_flash_cmd_wait(struct zl3073x_dev *zldev, u32 operation,
if (rc)
return rc;
- value &= ~ZL_WRITE_FLASH_OP;
- value |= FIELD_PREP(ZL_WRITE_FLASH_OP, operation);
+ FIELD_MODIFY(ZL_WRITE_FLASH_OP, &value, operation);
rc = zl3073x_write_u8(zldev, ZL_REG_WRITE_FLASH, value);
if (rc)
--
2.52.0
^ permalink raw reply
* RE: [PATCH net-next 3/5] dpll: zl3073x: add ref sync and output clock type helpers
From: Prathosh.Satish @ 2026-03-27 15:35 UTC (permalink / raw)
To: ivecera, netdev
Cc: arkadiusz.kubalewski, jiri, mschmidt, poros, horms,
vadim.fedorenko, linux-kernel, conor+dt, krzk+dt, robh,
devicetree, pvaanane
In-Reply-To: <20260319174826.7623-4-ivecera@redhat.com>
Reviewed-by: prathosh.satish@microchip.com
-----Original Message-----
From: Ivan Vecera <ivecera@redhat.com>
Sent: Thursday, March 19, 2026 5:48 PM
To: netdev@vger.kernel.org
Cc: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>; Jiri Pirko <jiri@resnulli.us>; Michal Schmidt <mschmidt@redhat.com>; Petr Oros <poros@redhat.com>; Prathosh Satish - M66066 <Prathosh.Satish@microchip.com>; Simon Horman <horms@kernel.org>; Vadim Fedorenko <vadim.fedorenko@linux.dev>; linux-kernel@vger.kernel.org; Conor Dooley <conor+dt@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Rob Herring <robh@kernel.org>; devicetree@vger.kernel.org; Pasi Vaananen <pvaanane@redhat.com>
Subject: [PATCH net-next 3/5] dpll: zl3073x: add ref sync and output clock type helpers
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
Add ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR and ZL_REF_SYNC_CTRL_PAIR register definitions.
Add inline helpers to get and set the sync control mode and sync pair fields of the reference sync control register:
zl3073x_ref_sync_mode_get/set() - ZL_REF_SYNC_CTRL_MODE field
zl3073x_ref_sync_pair_get/set() - ZL_REF_SYNC_CTRL_PAIR field
Add inline helpers to get and set the clock type field of the output mode register:
zl3073x_out_clock_type_get/set() - ZL_OUTPUT_MODE_CLOCK_TYPE field
Convert existing esync callbacks to use the new helpers.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/dpll/zl3073x/dpll.c | 24 ++++++++----------- drivers/dpll/zl3073x/out.h | 22 ++++++++++++++++++ drivers/dpll/zl3073x/ref.h | 46 +++++++++++++++++++++++++++++++++++++
drivers/dpll/zl3073x/regs.h | 2 ++
4 files changed, 80 insertions(+), 14 deletions(-)
diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c index 79ef62d69a32d..276f0a92db0b1 100644
--- a/drivers/dpll/zl3073x/dpll.c
+++ b/drivers/dpll/zl3073x/dpll.c
@@ -137,7 +137,7 @@ zl3073x_dpll_input_pin_esync_get(const struct dpll_pin *dpll_pin,
esync->range = esync_freq_ranges;
esync->range_num = ARRAY_SIZE(esync_freq_ranges);
- switch (FIELD_GET(ZL_REF_SYNC_CTRL_MODE, ref->sync_ctrl)) {
+ switch (zl3073x_ref_sync_mode_get(ref)) {
case ZL_REF_SYNC_CTRL_MODE_50_50_ESYNC_25_75:
esync->freq = ref->esync_n_div == ZL_REF_ESYNC_DIV_1HZ ? 1 : 0;
esync->pulse = 25;
@@ -173,8 +173,7 @@ zl3073x_dpll_input_pin_esync_set(const struct dpll_pin *dpll_pin,
else
sync_mode = ZL_REF_SYNC_CTRL_MODE_50_50_ESYNC_25_75;
- ref.sync_ctrl &= ~ZL_REF_SYNC_CTRL_MODE;
- ref.sync_ctrl |= FIELD_PREP(ZL_REF_SYNC_CTRL_MODE, sync_mode);
+ zl3073x_ref_sync_mode_set(&ref, sync_mode);
if (freq) {
/* 1 Hz is only supported frequency now */ @@ -578,7 +577,7 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
const struct zl3073x_synth *synth;
const struct zl3073x_out *out;
u32 synth_freq, out_freq;
- u8 clock_type, out_id;
+ u8 out_id;
out_id = zl3073x_output_pin_out_get(pin->id);
out = zl3073x_out_state_get(zldev, out_id); @@ -601,8 +600,7 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
esync->range = esync_freq_ranges;
esync->range_num = ARRAY_SIZE(esync_freq_ranges);
- clock_type = FIELD_GET(ZL_OUTPUT_MODE_CLOCK_TYPE, out->mode);
- if (clock_type != ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC) {
+ if (zl3073x_out_clock_type_get(out) !=
+ ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC) {
/* No need to read esync data if it is not enabled */
esync->freq = 0;
esync->pulse = 0;
@@ -635,8 +633,8 @@ zl3073x_dpll_output_pin_esync_set(const struct dpll_pin *dpll_pin,
struct zl3073x_dpll_pin *pin = pin_priv;
const struct zl3073x_synth *synth;
struct zl3073x_out out;
- u8 clock_type, out_id;
u32 synth_freq;
+ u8 out_id;
out_id = zl3073x_output_pin_out_get(pin->id);
out = *zl3073x_out_state_get(zldev, out_id); @@ -648,15 +646,13 @@ zl3073x_dpll_output_pin_esync_set(const struct dpll_pin *dpll_pin,
if (zl3073x_out_is_ndiv(&out))
return -EOPNOTSUPP;
- /* Select clock type */
+ /* Update clock type in output mode */
if (freq)
- clock_type = ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC;
+ zl3073x_out_clock_type_set(&out,
+
+ ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC);
else
- clock_type = ZL_OUTPUT_MODE_CLOCK_TYPE_NORMAL;
-
- /* Update clock type in output mode */
- out.mode &= ~ZL_OUTPUT_MODE_CLOCK_TYPE;
- out.mode |= FIELD_PREP(ZL_OUTPUT_MODE_CLOCK_TYPE, clock_type);
+ zl3073x_out_clock_type_set(&out,
+
+ ZL_OUTPUT_MODE_CLOCK_TYPE_NORMAL);
/* If esync is being disabled just write mailbox and finish */
if (!freq)
diff --git a/drivers/dpll/zl3073x/out.h b/drivers/dpll/zl3073x/out.h index edf40432bba5f..660889c57bffa 100644
--- a/drivers/dpll/zl3073x/out.h
+++ b/drivers/dpll/zl3073x/out.h
@@ -42,6 +42,28 @@ const struct zl3073x_out *zl3073x_out_state_get(struct zl3073x_dev *zldev, int zl3073x_out_state_set(struct zl3073x_dev *zldev, u8 index,
const struct zl3073x_out *out);
+/**
+ * zl3073x_out_clock_type_get - get output clock type
+ * @out: pointer to out state
+ *
+ * Return: clock type of given output (ZL_OUTPUT_MODE_CLOCK_TYPE_*) */
+static inline u8 zl3073x_out_clock_type_get(const struct zl3073x_out
+*out) {
+ return FIELD_GET(ZL_OUTPUT_MODE_CLOCK_TYPE, out->mode); }
+
+/**
+ * zl3073x_out_clock_type_set - set output clock type
+ * @out: pointer to out state
+ * @type: clock type (ZL_OUTPUT_MODE_CLOCK_TYPE_*) */ static inline
+void zl3073x_out_clock_type_set(struct zl3073x_out *out, u8 type) {
+ FIELD_MODIFY(ZL_OUTPUT_MODE_CLOCK_TYPE, &out->mode, type); }
+
/**
* zl3073x_out_signal_format_get - get output signal format
* @out: pointer to out state
diff --git a/drivers/dpll/zl3073x/ref.h b/drivers/dpll/zl3073x/ref.h index 06d8d4d97ea26..09fab97a71d7e 100644
--- a/drivers/dpll/zl3073x/ref.h
+++ b/drivers/dpll/zl3073x/ref.h
@@ -106,6 +106,52 @@ zl3073x_ref_freq_set(struct zl3073x_ref *ref, u32 freq)
return 0;
}
+/**
+ * zl3073x_ref_sync_mode_get - get sync control mode
+ * @ref: pointer to ref state
+ *
+ * Return: sync control mode (ZL_REF_SYNC_CTRL_MODE_*) */ static
+inline u8 zl3073x_ref_sync_mode_get(const struct zl3073x_ref *ref) {
+ return FIELD_GET(ZL_REF_SYNC_CTRL_MODE, ref->sync_ctrl); }
+
+/**
+ * zl3073x_ref_sync_mode_set - set sync control mode
+ * @ref: pointer to ref state
+ * @mode: sync control mode (ZL_REF_SYNC_CTRL_MODE_*) */ static inline
+void zl3073x_ref_sync_mode_set(struct zl3073x_ref *ref, u8 mode) {
+ FIELD_MODIFY(ZL_REF_SYNC_CTRL_MODE, &ref->sync_ctrl, mode); }
+
+/**
+ * zl3073x_ref_sync_pair_get - get sync pair reference index
+ * @ref: pointer to ref state
+ *
+ * Return: paired reference index
+ */
+static inline u8
+zl3073x_ref_sync_pair_get(const struct zl3073x_ref *ref) {
+ return FIELD_GET(ZL_REF_SYNC_CTRL_PAIR, ref->sync_ctrl); }
+
+/**
+ * zl3073x_ref_sync_pair_set - set sync pair reference index
+ * @ref: pointer to ref state
+ * @pair: paired reference index
+ */
+static inline void
+zl3073x_ref_sync_pair_set(struct zl3073x_ref *ref, u8 pair) {
+ FIELD_MODIFY(ZL_REF_SYNC_CTRL_PAIR, &ref->sync_ctrl, pair); }
+
/**
* zl3073x_ref_is_diff - check if the given input reference is differential
* @ref: pointer to ref state
diff --git a/drivers/dpll/zl3073x/regs.h b/drivers/dpll/zl3073x/regs.h index 5ae50cb761a97..d425dc67250fe 100644
--- a/drivers/dpll/zl3073x/regs.h
+++ b/drivers/dpll/zl3073x/regs.h
@@ -213,7 +213,9 @@
#define ZL_REG_REF_SYNC_CTRL ZL_REG(10, 0x2e, 1)
#define ZL_REF_SYNC_CTRL_MODE GENMASK(2, 0)
#define ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR_OFF 0
+#define ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR 1
#define ZL_REF_SYNC_CTRL_MODE_50_50_ESYNC_25_75 2
+#define ZL_REF_SYNC_CTRL_PAIR GENMASK(7, 4)
#define ZL_REG_REF_ESYNC_DIV ZL_REG(10, 0x30, 4)
#define ZL_REF_ESYNC_DIV_1HZ 0
--
2.52.0
^ permalink raw reply
* Re: [PATCH v1 3/3] arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: use rc-khadas keymap
From: neil.armstrong @ 2026-03-27 15:34 UTC (permalink / raw)
To: Nick Xie, khilman, martin.blumenstingl, jbrunet
Cc: krzk+dt, robh, conor+dt, linux-amlogic, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260327093016.722095-4-nick@khadas.com>
On 3/27/26 10:30, Nick Xie wrote:
> The Khadas VIM1S board has an onboard IR receiver.
> Configure the default keymap to "rc-khadas" to support the official
> Khadas IR remote control.
>
> Signed-off-by: Nick Xie <nick@khadas.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
> index 7314e0ab81da3..99d5df71b9cd4 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
> @@ -242,6 +242,7 @@ &ir {
> status = "okay";
> pinctrl-0 = <&remote_pins>;
> pinctrl-names = "default";
> + linux,rc-map-name = "rc-khadas";
> };
>
> &pwm_ef {
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: enable HYM8563 RTC
From: neil.armstrong @ 2026-03-27 15:34 UTC (permalink / raw)
To: Nick Xie, khilman, martin.blumenstingl, jbrunet
Cc: krzk+dt, robh, conor+dt, linux-amlogic, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260327093016.722095-3-nick@khadas.com>
On 3/27/26 10:30, Nick Xie wrote:
> The Khadas VIM1S board has an on-board Haoyu Micro HYM8563 Real Time
> Clock (RTC) connected to the I2C1 bus.
>
> Enable the I2C1 controller and add the RTC child node to support
> hardware clock persistence.
>
> Signed-off-by: Nick Xie <nick@khadas.com>
> ---
> .../dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
> index 792ab45c4c944..7314e0ab81da3 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
> @@ -20,6 +20,8 @@ aliases {
> mmc0 = &emmc; /* eMMC */
> mmc1 = &sd; /* SD card */
> mmc2 = &sdio; /* SDIO */
> + rtc0 = &rtc;
> + rtc1 = &vrtc;
> serial0 = &uart_b;
> };
>
> @@ -223,6 +225,19 @@ ðmac {
> phy-mode = "rmii";
> };
>
> +&i2c1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pins2>;
> + clock-frequency = <100000>;
> +
> + rtc: rtc@51 {
> + compatible = "haoyu,hym8563";
> + reg = <0x51>;
> + #clock-cells = <0>;
> + };
> +};
> +
> &ir {
> status = "okay";
> pinctrl-0 = <&remote_pins>;
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v1 1/3] arm64: dts: amlogic: meson-s4: add VRTC node
From: neil.armstrong @ 2026-03-27 15:34 UTC (permalink / raw)
To: Nick Xie, khilman, martin.blumenstingl, jbrunet
Cc: krzk+dt, robh, conor+dt, linux-amlogic, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260327093016.722095-2-nick@khadas.com>
On 3/27/26 10:30, Nick Xie wrote:
> Add the Virtual RTC (VRTC) controller node to the Meson S4 SoC dtsi.
>
> Signed-off-by: Nick Xie <nick@khadas.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-s4.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
> index 936a5c1353d15..2a6fbd5308362 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
> @@ -59,6 +59,11 @@ psci {
> method = "smc";
> };
>
> + vrtc: rtc@fe010288 {
> + compatible = "amlogic,meson-vrtc";
> + reg = <0x0 0xfe010288 0x0 0x4>;
> + };
> +
> xtal: xtal-clk {
> compatible = "fixed-clock";
> clock-frequency = <24000000>;
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* RE: [PATCH net-next 4/5] dt-bindings: dpll: add ref-sync-sources property
From: Prathosh.Satish @ 2026-03-27 15:33 UTC (permalink / raw)
To: ivecera, netdev
Cc: arkadiusz.kubalewski, jiri, mschmidt, poros, horms,
vadim.fedorenko, linux-kernel, conor+dt, krzk+dt, robh,
devicetree, pvaanane
In-Reply-To: <20260319174826.7623-5-ivecera@redhat.com>
Reviewed-by: prathosh.satish@microchip.com
-----Original Message-----
From: Ivan Vecera <ivecera@redhat.com>
Sent: Thursday, March 19, 2026 5:48 PM
To: netdev@vger.kernel.org
Cc: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>; Jiri Pirko <jiri@resnulli.us>; Michal Schmidt <mschmidt@redhat.com>; Petr Oros <poros@redhat.com>; Prathosh Satish - M66066 <Prathosh.Satish@microchip.com>; Simon Horman <horms@kernel.org>; Vadim Fedorenko <vadim.fedorenko@linux.dev>; linux-kernel@vger.kernel.org; Conor Dooley <conor+dt@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Rob Herring <robh@kernel.org>; devicetree@vger.kernel.org; Pasi Vaananen <pvaanane@redhat.com>
Subject: [PATCH net-next 4/5] dt-bindings: dpll: add ref-sync-sources property
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
Add ref-sync-sources phandle-array property to the dpll-pin schema allowing board designers to declare which input pins can serve as sync sources in a Reference-Sync pair. A Ref-Sync pair consists of a clock reference and a low-frequency sync signal where the DPLL locks to the clock but phase-aligns to the sync reference.
Update both examples in the Microchip ZL3073x binding to demonstrate the new property with a 1 PPS sync source paired to a clock source.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
.../devicetree/bindings/dpll/dpll-pin.yaml | 11 +++++++
.../bindings/dpll/microchip,zl30731.yaml | 30 ++++++++++++++-----
2 files changed, 34 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/dpll/dpll-pin.yaml b/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
index 51db93b77306f..7084f102e274c 100644
--- a/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
+++ b/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
@@ -36,6 +36,17 @@ properties:
description: String exposed as the pin board label
$ref: /schemas/types.yaml#/definitions/string
+ ref-sync-sources:
+ description: |
+ List of phandles to input pins that can serve as the sync source
+ in a Reference-Sync pair with this pin acting as the clock source.
+ A Ref-Sync pair consists of a clock reference and a low-frequency
+ sync signal. The DPLL locks to the clock reference but
+ phase-aligns to the sync reference.
+ Only valid for input pins. Each referenced pin must be a
+ different input pin on the same device.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+
supported-frequencies-hz:
description: List of supported frequencies for this pin, expressed in Hz.
diff --git a/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml b/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml
index 17747f754b845..fa5a8f8e390cd 100644
--- a/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml
+++ b/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml
@@ -52,11 +52,19 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- pin@0 { /* REF0P */
+ sync0: pin@0 { /* REF0P - 1 PPS sync source */
reg = <0>;
connection-type = "ext";
- label = "Input 0";
- supported-frequencies-hz = /bits/ 64 <1 1000>;
+ label = "SMA1";
+ supported-frequencies-hz = /bits/ 64 <1>;
+ };
+
+ pin@1 { /* REF0N - clock source, can pair with sync0 */
+ reg = <1>;
+ connection-type = "ext";
+ label = "SMA2";
+ supported-frequencies-hz = /bits/ 64 <10000 10000000>;
+ ref-sync-sources = <&sync0>;
};
};
@@ -90,11 +98,19 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- pin@0 { /* REF0P */
+ sync1: pin@0 { /* REF0P - 1 PPS sync source */
reg = <0>;
- connection-type = "ext";
- label = "Input 0";
- supported-frequencies-hz = /bits/ 64 <1 1000>;
+ connection-type = "gnss";
+ label = "GNSS_1PPS_IN";
+ supported-frequencies-hz = /bits/ 64 <1>;
+ };
+
+ pin@1 { /* REF0N - clock source */
+ reg = <1>;
+ connection-type = "gnss";
+ label = "GNSS_10M_IN";
+ supported-frequencies-hz = /bits/ 64 <10000000>;
+ ref-sync-sources = <&sync1>;
};
};
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Neil Armstrong @ 2026-03-27 15:28 UTC (permalink / raw)
To: Bryan O'Donoghue, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <da3ed78d-fb5e-4820-95d6-527d540cf03e@linaro.org>
Le 27/03/2026 à 15:38, Bryan O'Donoghue a écrit :
> On 27/03/2026 10:07, Konrad Dybcio wrote:
>> On 3/26/26 2:04 AM, Bryan O'Donoghue wrote:
>>> Add a base schema initially compatible with x1e80100 to describe MIPI CSI2
>>> PHY devices.
>>>
>>> The hardware can support both CPHY, DPHY and a special split-mode DPHY. We
>>> capture those modes as:
>>>
>>> - PHY_QCOM_CSI2_MODE_DPHY
>>> - PHY_QCOM_CSI2_MODE_CPHY
>>> - PHY_QCOM_CSI2_MODE_SPLIT_DPHY
>> Does the_PHY_ DT node need to be aware about this upfront?
>
> Yeah that's a fair question.
>
> The standard model is to pass the mode via binding right now. You _could_ configure it @ run time in principle.
>
> And you could even conceive of a sensor hardware that might find value in that - but IMO it's a 100% hypothetical use-case - you'd basically need an FPGA that could output CPHY, DPHY or for some reason SPLIT_MODE DPHY.
>
> But that's a pretty off the wall use-case to hypothesize. Split-mode OTOH is a board-level physical reality which => a DT description not a runtime choice.
>
>> If we have some sideband signal (e.g. the sensor driver specifically
>> requesting C-PHY mode), we can simply throw all this complexity into
>> phy_mode + phy_configure_opts, all at runtime
>
> Like I say its conceivable but IMO not a real thing and unless your sensor is an FPGA not possible to support in real hardware.
>
>> Further, the combo/split mode may possibly be selected through
>> aggregation of requests.
>>
>> The question remains whether the sensor should have a direct connection to
>> the PHY itself (i.e. phys = <&csiphyN> or of_graph straight into the PHY)
>> or whether it's going to be translated by the camss node (which would be
>> the one holding a PHY reference) - there's probably surface for adding such
>> negotiation logic in both places
>
> To be frankly honest you can make an argument for it either way. However my honestly held position is analysing other upstream implementations connecting to the PHY means we can't make the PHY device a drivers/phy device - it would have to be a V4L2 device and then for me the question is why is that even required ?
This is plain wrong, DT definition is different from software implementation, you can do whatever you want if you describe HW accurately.
The CSIPHYs are not tied to a single "consumer" block, they can be connected to different consumers at runtime, which is not something classic PHY devices are designed for. So they are de facto a media element in the dynamic camera pipeline.
>
> The model we have right now, right or wrong is sensor endpoint to controller. Similarly the <&phy MODE_GOES_HERE> is a pattern Rob Herring suggested and IMO is a consistent pattern we should aim for upstream. We see it in latest Rockchip, Cadence.
This doesn’t properly describe the data path, we got out of this classic scheme when implementing the whole USB-C complex on qualcomm SoCs where we had to describe the data flow within all the USB/DSP/DP/PHYs elements, and we have a link between the DP controller and the Combo PHY acting as a DRM bridge.
And actually Rob Herring asked use to define the complete data flow, it was a strong requirement. I don't see why we wouldn't here.
Looking at other vendors and sticking to this is wrong, we need to solve how to describe the Qualcomm CAMSS complex with accurate representation of the data flow and hw components interconnections. The choice of kernel API to access an HW element is irrelevant in the discussion.
Starting refactoring the DT representation of CAMSS is good, starting with PHY is weird since I don't see what it does solve we can't solve already,
but you need to take in account how the CSIPHYs are connected to other HW blocks. Simply adding a "phys =" reference from CAMSS node doesn't reflect
at all which HW element will consume the PHY, and what are the link parameters between the consumer and the PHY and between the PHY and the Sensor.
Those are the whole meaning of the port/endpoint links, where we can define multiple endpoints for a same connection to, for example, define multiple sensors on a same PHY for the split-mode.
Neil
>
>
>> Note this is a question and I'm not aware of all the possible combinations
>>
>> Konrad
>
^ permalink raw reply
* RE: [PATCH net-next 0/5] dpll: zl3073x: add ref-sync pair support
From: Prathosh.Satish @ 2026-03-27 15:28 UTC (permalink / raw)
To: ivecera, netdev
Cc: arkadiusz.kubalewski, jiri, mschmidt, poros, horms,
vadim.fedorenko, linux-kernel, conor+dt, krzk+dt, robh,
devicetree, pvaanane
In-Reply-To: <20260319174826.7623-1-ivecera@redhat.com>
Reviewed-by: prathosh.satish@microchip.com
-----Original Message-----
From: Ivan Vecera <ivecera@redhat.com>
Sent: Thursday, March 19, 2026 5:48 PM
To: netdev@vger.kernel.org
Cc: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>; Jiri Pirko <jiri@resnulli.us>; Michal Schmidt <mschmidt@redhat.com>; Petr Oros <poros@redhat.com>; Prathosh Satish - M66066 <Prathosh.Satish@microchip.com>; Simon Horman <horms@kernel.org>; Vadim Fedorenko <vadim.fedorenko@linux.dev>; linux-kernel@vger.kernel.org; Conor Dooley <conor+dt@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Rob Herring <robh@kernel.org>; devicetree@vger.kernel.org; Pasi Vaananen <pvaanane@redhat.com>
Subject: [PATCH net-next 0/5] dpll: zl3073x: add ref-sync pair support
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
This series adds Reference-Sync pair support to the ZL3073x DPLL driver.
A Ref-Sync pair consists of a clock reference and a low-frequency sync signal (e.g. 1 PPS) where the DPLL locks to the clock reference but phase-aligns to the sync reference.
Patches 1-3 are preparatory cleanups and helper additions:
- Clean up esync get/set callbacks with early returns and use the
zl3073x_out_is_ndiv() helper
- Convert open-coded clear-and-set bitfield patterns to FIELD_MODIFY()
- Add ref sync control and output clock type accessor helpers
Patch 4 adds the 'ref-sync-sources' phandle-array property to the dpll-pin device tree binding schema and updates the ZL3073x binding examples.
Patch 5 implements the driver support:
- ref_sync_get/set callbacks with frequency validation
- Automatic sync source exclusion from reference selection
- Device tree based ref-sync pair registration
Tested and verified on Microchip EDS2 (pcb8385) development board.
Ivan Vecera (5):
dpll: zl3073x: clean up esync get/set and use zl3073x_out_is_ndiv()
dpll: zl3073x: use FIELD_MODIFY() for clear-and-set patterns
dpll: zl3073x: add ref sync and output clock type helpers
dt-bindings: dpll: add ref-sync-sources property
dpll: zl3073x: add ref-sync pair support
.../devicetree/bindings/dpll/dpll-pin.yaml | 11 +
.../bindings/dpll/microchip,zl30731.yaml | 30 +-
drivers/dpll/zl3073x/chan.h | 17 +-
drivers/dpll/zl3073x/core.c | 3 +-
drivers/dpll/zl3073x/dpll.c | 295 ++++++++++++++----
drivers/dpll/zl3073x/flash.c | 3 +-
drivers/dpll/zl3073x/out.h | 22 ++
drivers/dpll/zl3073x/ref.h | 46 +++
drivers/dpll/zl3073x/regs.h | 2 +
9 files changed, 348 insertions(+), 81 deletions(-)
--
2.52.0
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: tegra: transformers: add connector node
From: Svyatoslav Ryhel @ 2026-03-27 15:28 UTC (permalink / raw)
To: Thierry Reding
Cc: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Thierry Reding, Jonathan Hunter, dri-devel,
devicetree, linux-tegra, linux-kernel
In-Reply-To: <acafk7munaGrCTK3@orome>
27 березня 2026 р. 17:18:42 GMT+02:00, Thierry Reding <thierry.reding@kernel.org> пише:
>On Mon, Feb 23, 2026 at 08:55:00AM +0200, Svyatoslav Ryhel wrote:
>> All ASUS Transformers have micro-HDMI connector directly available. After
>> Tegra HDMI got bridge/connector support, we should use connector framework
>> for proper HW description.
>>
>> Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # ASUS TF T30
>> Tested-by: Robert Eckelmann <longnoserob@gmail.com> # ASUS TF101 T20
>> Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # ASUS TF201 T30
>> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>> ---
>> .../boot/dts/nvidia/tegra30-asus-tf600t.dts | 21 +++++++++++++++++--
>> 1 file changed, 19 insertions(+), 2 deletions(-)
>
>Two things about you commit messages that I have to fixup every time:
>
> 1. caps after the subject prefix
Prefix ends with ':' which does not imply using of capital letter as '.' '!' or '?' do. Linux documentation does not regulate this.
Even more, examples use lower case
[PATCH 001/123] subsystem: summary phrase
> 2. wrap commit message at 72 characters
>
The body of the explanation, line wrapped at 75 columns, which will be copied to the permanent changelog to describe this patch.
The commit message is wrapped by 75 characters, as linux documentation requests.
>Both patches applied, thanks.
>
>Thierry
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: eliza: Add thermal sensors
From: Abel Vesa @ 2026-03-27 15:28 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260327101225.382493-2-krzysztof.kozlowski@oss.qualcomm.com>
On 26-03-27 11:12:26, Krzysztof Kozlowski wrote:
> Add TSENS thermal sensors to Qualcomm Eliza SoC among with thermal
> zones. The TSENS is compatible with previous generations.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v5 4/5] arm64: dts: qcom: x1-crd: Add Embedded controller node
From: Abel Vesa @ 2026-03-27 15:24 UTC (permalink / raw)
To: Anvesh Jain P
Cc: Sibi Sankar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, linux-arm-msm, devicetree,
linux-kernel, platform-driver-x86, Dmitry Baryshkov,
Konrad Dybcio
In-Reply-To: <20260317-add-driver-for-ec-v5-4-38d11f524856@oss.qualcomm.com>
On 26-03-17 17:57:58, Anvesh Jain P wrote:
> From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>
> Add embedded controller node for Hamoa/Purwa CRDs which adds fan control,
> temperature sensors, access to EC internal state changes and suspend
> entry/exit notifications to the EC.
>
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
> Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v5 3/5] arm64: dts: qcom: glymur-crd: Add Embedded controller node
From: Abel Vesa @ 2026-03-27 15:23 UTC (permalink / raw)
To: Anvesh Jain P
Cc: Sibi Sankar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, linux-arm-msm, devicetree,
linux-kernel, platform-driver-x86, Dmitry Baryshkov,
Konrad Dybcio
In-Reply-To: <20260317-add-driver-for-ec-v5-3-38d11f524856@oss.qualcomm.com>
On 26-03-17 17:57:57, Anvesh Jain P wrote:
> From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>
> Add embedded controller node for Glymur CRDs which adds fan control,
> temperature sensors, access to EC state changes through SCI events
> and suspend entry/exit notifications to the EC.
>
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
> Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: hamoa-iot-som: Add firmware-name to QUPv3 nodes
From: Abel Vesa @ 2026-03-27 15:21 UTC (permalink / raw)
To: Xueyao An
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260327085318.2771771-1-xueyao.an@oss.qualcomm.com>
On 26-03-27 16:53:17, Xueyao An wrote:
> Traditionally, firmware loading for Serial Engines (SE) in the QUP hardware
> of Qualcomm SoCs has been managed by TrustZone (TZ). While this approach
> ensures secure SE assignment and access control, it limits flexibility for
> developers who need to enable various protocols on different SEs.
>
> Add the firmware-name property to QUPv3 nodes in the device tree to enable
> firmware loading from the Linux environment. Handle SE assignments and
> access control permissions directly within Linux, removing the dependency
> on TrustZone.
>
> Signed-off-by: Xueyao An <xueyao.an@oss.qualcomm.com>
Hopefully, there is a DT binding schema update that goes with this...
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v3 01/11] arm64: dts: qcom: x1e80100: Add CAMCC block definition
From: Abel Vesa @ 2026-03-27 15:19 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Vladimir Zapolskiy, Konrad Dybcio
In-Reply-To: <20260326-x1e-camss-csi2-phy-dtsi-v3-1-1d5a9306116a@linaro.org>
On 26-03-26 10:27:38, Bryan O'Donoghue wrote:
> Add the CAMCC block for x1e80100. The x1e80100 CAMCC block is an iteration
> of previous CAMCC blocks with the exception of having two required
> power-domains not just one.
Nit: maybe we should be using Hamoa instead of x1e80100 ...
>
> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 0/4] ARM: tegra: lg-x3: add missing nodes
From: Svyatoslav Ryhel @ 2026-03-27 15:18 UTC (permalink / raw)
To: Thierry Reding
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Thierry Reding, Jonathan Hunter, Jonas Schwöbel, devicetree,
linux-tegra, linux-kernel
In-Reply-To: <acacdUaXVNIKHT2O@orome>
27 березня 2026 р. 17:05:34 GMT+02:00, Thierry Reding <thierry.reding@kernel.org> пише:
>On Mon, Jan 26, 2026 at 12:10:14PM +0200, Svyatoslav Ryhel wrote:
>> With the recent kernel updates, Tegra30-based LG smartphones now support
>> several additional features, including an RGB-DSI bridge, DSI panels,
>> MUIC, a charger, a battery temperature sensor, OTG mode, and capacitive
>> buttons on the P895. Add required nodes to device trees.
>>
>> ---
>> Changes in v2:
>> - fixed dw9714 and tx13d100vm0eaa nodes
>> - added video device pipes graph
>>
>> Regarding CHECK_DTBS output in v2:
>> - nvidia,tegra30-pcie, nvidia,tegra30-gmi, nvidia,tegra30-kbc,
>> nvidia,tegra20-kbc, nvidia,tegra30-ahub are not documented yet
>> - nvidia,tegra30-vi was adjusted and applied, change did not apper yet
>> (https://lore.kernel.org/lkml/176860988748.1688420.11717122647073678.b4-ty@nvidia.com/)
>> - st,m24c08 appers undocumented though it seems to be different from
>> st,24c08, at least they google as separate devices. atmel,24c08 is not
>> documented, though it is widey used in linux device trees and is
>> supported by driver. Here is one of examples:
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/allwinner/sun7i-a20-linutronix-testbox-v2.dts?h=next-20260123#n33
>> - onnn,mt9m114 does not have 'orientation' property, though it should
>> include it since it is generic for camera devices
>> - ti,lp8720 and maxim,max77663 have txt documentation and are not yet
>> converted to DT schema
>> - backlight in panel nodes was not added since lm3533 has no DT support
>> - missing '#io-channel-cells' in ti,tsc2007 addressed in
>> https://lore.kernel.org/lkml/20260122193549.29858-2-clamor95@gmail.com/
>> - missing dsi controller properties of ssd2825 addressed in
>> https://lore.kernel.org/lkml/20260123073411.7736-2-clamor95@gmail.com/
>> - missing '#io-channel-cells' in generic-adc-thermal was proposed in but rejected
>> https://lore.kernel.org/lkml/20250310075638.6979-2-clamor95@gmail.com/
>> ---
>>
>> Svyatoslav Ryhel (4):
>> ARM: tegra: lg-x3: add panel and bridge nodes
>> ARM: tegra: lg-x3: add USB and power related nodes
>> ARM: tegra: lg-x3: add node for capacitive buttons
>> ARM: tegra: lg-x3: complete video device graph
>>
>> arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts | 39 +++
>> arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 79 +++++
>> arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 328 ++++++++++++++++++-
>> 3 files changed, 429 insertions(+), 17 deletions(-)
>
>Patches 1-3 applied. Patch 4 has checkpatch has checkpatch warnings:
>
> WARNING: DT compatible string "st,m24c08" appears un-documented -- check ./Documentation/devicetree/bindings/
> #255: FILE: arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi:1243:
> + compatible = "st,m24c08", "atmel,24c08";
>
>So I've left it out for now.
>
st,m24c08 appers undocumented though it seems to be different from
st,24c08 (in schema) at least they google as separate devices. atmel,24c08 is not
documented, though it is widey used in linux device trees and is
supported by driver. Here is one of examples:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/allwinner/sun7i-a20-linutronix-testbox-v2.dts?h=next-20260123#n33
I assume patch 4 should be fine and most likely schema needs to be adjusted to cover this compatible (since it exists and is used).
>Thierry
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: tegra: transformers: add connector node
From: Thierry Reding @ 2026-03-27 15:18 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Thierry Reding, Jonathan Hunter, dri-devel,
devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260223065500.13357-3-clamor95@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 857 bytes --]
On Mon, Feb 23, 2026 at 08:55:00AM +0200, Svyatoslav Ryhel wrote:
> All ASUS Transformers have micro-HDMI connector directly available. After
> Tegra HDMI got bridge/connector support, we should use connector framework
> for proper HW description.
>
> Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # ASUS TF T30
> Tested-by: Robert Eckelmann <longnoserob@gmail.com> # ASUS TF101 T20
> Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # ASUS TF201 T30
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../boot/dts/nvidia/tegra30-asus-tf600t.dts | 21 +++++++++++++++++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
Two things about you commit messages that I have to fixup every time:
1. caps after the subject prefix
2. wrap commit message at 72 characters
Both patches applied, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
From: Luca Ceresoli @ 2026-03-27 15:17 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Jonas Karlman,
Jernej Skrabec, Liu Ying, Rob Herring, Saravana Kannan,
Kory Maincent (TI.com), Hervé Codina, Hui Pu, Ian Ray,
Thomas Petazzoni, dri-devel, imx, linux-arm-kernel, linux-kernel,
devicetree, Adam Ford, Alexander Stein, Anson Huang,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Joao Paulo Goncalves,
Josua Mayer, Kieran Bingham, Marco Felsch, Martyn Welch,
Oleksij Rempel, Peng Fan, Philippe Schenker, Richard Hu,
Shengjiu Wang, Stefan Eichenberger, Vitor Soares
In-Reply-To: <20260326082843.GB2670326@killaraus.ideasonboard.com>
Hi Laurent,
On Thu Mar 26, 2026 at 9:28 AM CET, Laurent Pinchart wrote:
>> Many dts files for imx8mp-based boards in the kernel have such a connector
>> described and linked to port@1, so a connector is added by the
>> display-connector driver along with a bridge wrapping it. Sadly some of
>> those dts files don't have the connector described. Adding it would solve
>> the problem easily, but this would break existing devices which do not
>> update the dtb when upgrading to a newer kernel.
>
> I think this series should also fix the in-tree dts files, to pave the
> way for removing the workaround.
Fixing all dts files can surely be done, but it won't allow removing the
workaround. Any devices shipped with a dtb without the connector and
upgrading their kernel later on but not the dtb will fail as soon as they
upgrade to a kernel with patch 8 but with this workaround removed.
That said, do you still think it's worth adding the hdmi-connector node to
all dtbs missing it?
It should be fairly simple and IIRC it would involve a couple dozen drivers
at most based on my initial research. However for most of them I have no
way to know which type of connector is installed, would it be OK if we
describe type A when the type is unknown, just like
dw_hdmi_connector_create() does right now programmatically [0]?
[0] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2601
Also, if such a change is to be done, I'd definitely do it as a separate
series, to avoid adding more stuff to this series in-flight.
>> --- a/drivers/gpu/drm/bridge/imx/Kconfig
>> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
>> @@ -25,6 +25,23 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
>> Choose this to enable support for the internal HDMI encoder found
>> on the i.MX8MP SoC.
>>
>> +config DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP
>> + bool "Support device tree blobs without an hdmi-connector node"
>> + default y
>
> Can't we enable the workaround unconditionally ? Distributions will need
> to enable this option anyway as they can't know what device they will
> boot on. I fear a configuration option will confuse users and waste time
> on debugging.
Sure, good point.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v9 2/9] lib: vsprintf: export simple_strntoull() in a safe prototype
From: Rodrigo Alencar @ 2026-03-27 15:17 UTC (permalink / raw)
To: Andy Shevchenko, Rodrigo Alencar
Cc: Petr Mladek, rodrigo.alencar, linux-kernel, linux-iio, devicetree,
linux-doc, Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Steven Rostedt, Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <acZaGUV0MwuHNDru@ashevche-desk.local>
On 26/03/27 12:21PM, Andy Shevchenko wrote:
> On Fri, Mar 27, 2026 at 10:11:56AM +0000, Rodrigo Alencar wrote:
> > On 26/03/27 11:17AM, Andy Shevchenko wrote:
> > > On Fri, Mar 27, 2026 at 09:45:17AM +0100, Petr Mladek wrote:
> > > > On Fri 2026-03-20 16:27:27, Rodrigo Alencar via B4 Relay wrote:
>
> ...
>
> > > > > +extern ssize_t __must_check simple_strntoull(const char *startp, const char **endp,
> > > > > + unsigned int base, size_t max_chars,
> > > > > + unsigned long long *res);
> > > >
> > > > Sigh, naming is hard. I personally find it a bit confusing that the
> > > > name is too similar to the unsafe API.
> > > >
> > > > IMHO, the semantic of the new API is closer to kstrtoull().
> > > > It just limits the size, so I would call it kstrntoull().
> > >
> > > It's not. kstrto*() quite strict about the input, this one is actually relaxed
> > > variant, so I wouldn't mix these two groups.
> > >
> > > > Also I would use int as the return parameter, see below.
>
> ...
>
> > > TBH, I am skeptical about this approach. My main objection is max_chars
> > > parameter. If we want to limit the input strictly to the given number of
> > > characters, we have to copy the string and then just use kstrto*() in a normal
> > > way. The whole idea of that parameter is to be able to parse the fractional
> > > part of the float number as 'iiiii.fffff', where 'i' is for integer part, and
> > > 'f' for the fractional. Since we have *endp, we may simply check that.
> >
> > A max_chars would not be only useful for that. It can prevent out-of-bounds
> > reads when the input isn't NUL-terminated (like buffers, file chunks,
> > network packets, memory-mapped data, ....). Even if there is a NUL later in
> > memory, a regular strtoull() function may consume characters that are outside
> > the field one intends to parse.
>
> Okay, but is it the current case or just an attempt to solve the problem that
> doesn't exist (yet)?
The current case can be seen as such. Copying the string and use regular ksrto*()
requires an unecessary scan of string from the user side, which is something that
_parse_integer_limit() already does, mostly because it checks for digits and stops
at any non-digit character. In the IIO case, we also want control over the consumed
characters because there are weird terminations like "dB", so having an implementation
like this ends up with a cleaner sequence of steps.
> > > In case if we want to parse only, say, 6 digits and input is longer there are
> > > a few options (in my personal preferences, the first is the better):
> > > - consider the input invalid
> > > - parse it as is up to the maximum and then do ceil() or floor() on top of that
> > > - copy only necessary amount of the (sub)string and parse that.
> >
> > Yes, my use case is the fixed point parsing, but I suppose we are implementing
> > things here for reuse.
>
> Yes, I'm full for reuse, but I want to have it balanced between complexity,
> existing use cases and possible reuse in the future.
Not seeing complexity here as in this case I am just exposing something
that already exists! No need for a completely different implementation.
I just want to get an agreement on the naming and interface prototype.
Bringing back the discussion again just because I suppose Petr havent even
seen the v8 of this patch series. If kstrtox.h is the right place for this,
kstrntoull() sounds like ideal. Specially because simple_strto*() is already
labeled as unsafe and kstrnto*() != kstrto*().
> > Also, the default behavior of the previous fixed point
> > parsing in IIO is flooring the result, which leads to the same result as
> > ignoring further digits.
>
> Correct, I also lean to implying floor() (as you can read below).
>
> > > The problem with precision is that we need to also consider floor() or ceil()
> > > and I don't think this should be burden of the library as it's individual
> > > preference of each of the callers (users). At least for the starter, we will
> > > see if it's only one approach is used, we may incorporate it into the library
> > > code.
> > >
> > > The easiest way out is to just consider the input invalid if it overflows the
> > > given type (s32 or s64).
> > >
> > > But we need to have an agreement what will be the representation of the
> > > fixed-width float numbers in the kernel? Currently IIO uses
> > > struct float // name is crafted for simplicity
> > > {
> > > int integer;
> > > int fraction;
> > > }
> >
> > Yes, but to represent things like that, an assumption is made to the precision that
> > "fraction" carries.
>
> Correct.
>
> > > This parser wants AFAIU to have at the end of the day something like
> > >
> > > struct float
> > > {
> > > s64 integer;
> > > s64 fraction;
> > > }
> > >
> > > but also wants to have the fraction part be limited in some cases to s32
> > > or so:
> > >
> > > struct float
> > > {
> > > s64 integer;
> > > s32 fraction; // precision may be lost if input is longer
> > > }
> > >
> > > Maybe we want to have kstrtof32() and kstrtof64() for these two cases?
> > >
> > > With that we will always consider the fraction part as 32- or 64-bit,
> > > imply floor() on the fraction for the sake of simplicity and require
> > > it to be NUL-terminated with possible trailing '\n'.
> >
> > I think this is a good idea, but calling it float or fixed point itself
> > is a bit confusing as float often refers to the IEEE 754 standard and
> > fixed point types is often expressed in Q-format.
>
> Yeah... I am lack of better naming.
decimals is the name, but they are often represented as:
DECIMAL = INT * 10^X + FRAC
in a single 64-bit number, which would be fine for my end use case.
However IIO decimal fixed point parsing is out there for quite some time a
lot of drivers use that. The interface often relies on breaking parsed values
into an integer array (for standard attributes int val and int val2 are expected).
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v3 02/11] arm64: dts: qcom: x1e80100: Add CCI definitions
From: Abel Vesa @ 2026-03-27 15:16 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Vladimir Zapolskiy
In-Reply-To: <20260326-x1e-camss-csi2-phy-dtsi-v3-2-1d5a9306116a@linaro.org>
On 26-03-26 10:27:39, Bryan O'Donoghue wrote:
> Add in two CCI buses.
>
> One bus has two CCI bus master pinouts:
> cci_i2c_sda0 = gpio101
> cci_i2c_scl0 = gpio102
>
> cci_i2c_sda1 = gpio103
> cci_i2c_scl1 = gpio104
>
> The second bus has two CCI bus master pinouts:
> cci_i2c_sda2 = gpio105
> cci_i2c_scl2 = gpio106
>
> aon_cci_i2c_sda3 = gpio235
> aon_cci_i2c_scl3 = gpio236
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: qcom: Add the Lenovo IdeaCentre Mini X
From: Luca Weiss @ 2026-03-27 15:07 UTC (permalink / raw)
To: Bjorn Andersson, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260325-ideacentre-v1-2-768b66aaef30@oss.qualcomm.com>
Hi Bjorn,
On Wed Mar 25, 2026 at 11:34 PM CET, Bjorn Andersson wrote:
> The Lenovo IdeaCentre Mini X (Snapdragon) Desktop is a Hamoa-based
> ultracompact desktop PC. It provides HDMI, DisplayPort, USB Type-C
> display outputs, 5 additional USB ports, Ethernet, dual NVME slots,
> headphone jack, WiFi, and Bluetooth.
>
> Introduce a DeviceTree describing this device.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> .../qcom/hamoa-lenovo-ideacentre-mini-01q8x10.dts | 1199 ++++++++++++++++++++
> 2 files changed, 1200 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index d69e5f3132c4fd3fbf1ac90e83adf6af6b104a93..fbbec696ac161af42c18acc344a228ba461f65a7 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_QCOM) += hamoa-iot-evk.dtb
> hamoa-iot-evk-el2-dtbs := hamoa-iot-evk.dtb x1-el2.dtbo
>
> dtb-$(CONFIG_ARCH_QCOM) += hamoa-iot-evk-el2.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += hamoa-lenovo-ideacentre-mini-01q8x10.dtb
> dtb-$(CONFIG_ARCH_QCOM) += ipq5018-rdp432-c2.dtb
> dtb-$(CONFIG_ARCH_QCOM) += ipq5018-tplink-archer-ax55-v1.dtb
> dtb-$(CONFIG_ARCH_QCOM) += ipq5332-rdp441.dtb
> diff --git a/arch/arm64/boot/dts/qcom/hamoa-lenovo-ideacentre-mini-01q8x10.dts b/arch/arm64/boot/dts/qcom/hamoa-lenovo-ideacentre-mini-01q8x10.dts
> new file mode 100644
> index 0000000000000000000000000000000000000000..cc90cb58a9c17ad166dd641d9bbc03b7df5686a6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/hamoa-lenovo-ideacentre-mini-01q8x10.dts
> @@ -0,0 +1,1199 @@
<snip>
> +&remoteproc_cdsp {
> + firmware-name = "qcom/x1e80100/LENOVO/91B6/qccdsp8380.mbn",
> + "qcom/x1e80100/LENOVO/91B6/cdsp_dtbs.elf";
> +
> + status = "okay";
> +};
> +
> +&smb2360_0 {
> + status = "okay";
> +};
> +
> +&smb2360_0 {
> + status = "okay";
> +};
You have this smb2360_0 node enabled twice.
I checked this AI review thingy to see what it's saying , and while most
suggestions are probably kinda useless, it did spot that bit, which I
thought you may want to fix in v2.
https://sashiko.dev/#/patchset/20260325-ideacentre-v1-0-768b66aaef30%40oss.qualcomm.com?patch=10329
> This isn't a bug, but the smb2360_0 node is defined twice. Can the duplicate
> be removed?
Regards
Luca
^ permalink raw reply
* Re: [PATCH v2 0/4] ARM: tegra: lg-x3: add missing nodes
From: Thierry Reding @ 2026-03-27 15:05 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Thierry Reding, Jonathan Hunter, Jonas Schwöbel, devicetree,
linux-tegra, linux-kernel
In-Reply-To: <20260126101018.24450-1-clamor95@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2820 bytes --]
On Mon, Jan 26, 2026 at 12:10:14PM +0200, Svyatoslav Ryhel wrote:
> With the recent kernel updates, Tegra30-based LG smartphones now support
> several additional features, including an RGB-DSI bridge, DSI panels,
> MUIC, a charger, a battery temperature sensor, OTG mode, and capacitive
> buttons on the P895. Add required nodes to device trees.
>
> ---
> Changes in v2:
> - fixed dw9714 and tx13d100vm0eaa nodes
> - added video device pipes graph
>
> Regarding CHECK_DTBS output in v2:
> - nvidia,tegra30-pcie, nvidia,tegra30-gmi, nvidia,tegra30-kbc,
> nvidia,tegra20-kbc, nvidia,tegra30-ahub are not documented yet
> - nvidia,tegra30-vi was adjusted and applied, change did not apper yet
> (https://lore.kernel.org/lkml/176860988748.1688420.11717122647073678.b4-ty@nvidia.com/)
> - st,m24c08 appers undocumented though it seems to be different from
> st,24c08, at least they google as separate devices. atmel,24c08 is not
> documented, though it is widey used in linux device trees and is
> supported by driver. Here is one of examples:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/allwinner/sun7i-a20-linutronix-testbox-v2.dts?h=next-20260123#n33
> - onnn,mt9m114 does not have 'orientation' property, though it should
> include it since it is generic for camera devices
> - ti,lp8720 and maxim,max77663 have txt documentation and are not yet
> converted to DT schema
> - backlight in panel nodes was not added since lm3533 has no DT support
> - missing '#io-channel-cells' in ti,tsc2007 addressed in
> https://lore.kernel.org/lkml/20260122193549.29858-2-clamor95@gmail.com/
> - missing dsi controller properties of ssd2825 addressed in
> https://lore.kernel.org/lkml/20260123073411.7736-2-clamor95@gmail.com/
> - missing '#io-channel-cells' in generic-adc-thermal was proposed in but rejected
> https://lore.kernel.org/lkml/20250310075638.6979-2-clamor95@gmail.com/
> ---
>
> Svyatoslav Ryhel (4):
> ARM: tegra: lg-x3: add panel and bridge nodes
> ARM: tegra: lg-x3: add USB and power related nodes
> ARM: tegra: lg-x3: add node for capacitive buttons
> ARM: tegra: lg-x3: complete video device graph
>
> arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts | 39 +++
> arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 79 +++++
> arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 328 ++++++++++++++++++-
> 3 files changed, 429 insertions(+), 17 deletions(-)
Patches 1-3 applied. Patch 4 has checkpatch has checkpatch warnings:
WARNING: DT compatible string "st,m24c08" appears un-documented -- check ./Documentation/devicetree/bindings/
#255: FILE: arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi:1243:
+ compatible = "st,m24c08", "atmel,24c08";
So I've left it out for now.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Marek Vasut @ 2026-03-27 14:55 UTC (permalink / raw)
To: Bastien Curutchet, Vladimir Oltean, Fidelio Lawson
Cc: Woojung Huh, UNGLinuxDriver, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Maxime Chevallier,
netdev, devicetree, linux-kernel, Fidelio Lawson
In-Reply-To: <2848158c-a807-4d26-be87-248d4107c5b4@bootlin.com>
On 3/27/26 3:47 PM, Bastien Curutchet wrote:
Hello Bastien,
>> FYI, the driver is in a restructuring process. The ksz88xx_switch_ops
>> will be split out of the common ksz_switch_ops. This will conflict with
>> your series, so you should rebase on top of that much larger set.
>> You can coordinate with Bastien Curutchet to see what is the status:
>> https://lore.kernel.org/netdev/20260313153849.qkfzv5c2u6fepjku@skbuf
>
> Indeed, I'm currently polishing a first iteration for it. I'll send it
> ASAP.
I would argue that this low-loss cable errata is a bugfix, so maybe that
should have a priority over restructuring ?
^ permalink raw reply
* Re: [PATCH 3/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Bastien Curutchet @ 2026-03-27 14:47 UTC (permalink / raw)
To: Vladimir Oltean, Fidelio Lawson
Cc: Woojung Huh, UNGLinuxDriver, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Maxime Chevallier,
netdev, devicetree, linux-kernel, Fidelio Lawson
In-Reply-To: <20260326094211.hdaf4tz7lbjyjznn@skbuf>
Hi Vladimir, Hi Fidelio
On 3/26/26 10:42 AM, Vladimir Oltean wrote:
> On Thu, Mar 26, 2026 at 10:10:23AM +0100, Fidelio Lawson wrote:
>> Implement the "Module 3: Equalizer fix for short cables" erratum from
>> Microchip document DS80000687C for KSZ87xx switches.
>>
>> The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
>> where the PHY receiver equalizer may amplify high-amplitude signals
>> excessively, resulting in internal distortion and link establishment
>> failures.
>>
>> Depending on the selected workaround (1 or 2), the driver writes a
>> specific value to the indirect PHY register
>> using the 6E/6F/A0 indirect access mechanism.
>>
>> The errata fix is applied during global switch initialization when
>> enabled via device tree.
>>
>> Signed-off-by: Fidelio Lawson <fidelio.lawson@exotec.com>
>> ---
>> drivers/net/dsa/microchip/ksz8.c | 46 ++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 46 insertions(+)
>>
>> diff --git a/drivers/net/dsa/microchip/ksz8.c b/drivers/net/dsa/microchip/ksz8.c
>> index 78b42cf50ce2..b6f3a1ce85fc 100644
>> --- a/drivers/net/dsa/microchip/ksz8.c
>> +++ b/drivers/net/dsa/microchip/ksz8.c
>> @@ -1901,6 +1901,41 @@ void ksz8_phylink_mac_link_up(struct phylink_config *config,
>> ksz8_phy_port_link_up(dev, port, duplex, tx_pause, rx_pause);
>> }
>>
>> +static int ksz8_handle_module3_errata(struct ksz_device *dev)
>> +{
>> + int ret = 0;
>
> "ret" does not need to be zero-initialized. It is unconditionally
> overwritten by ksz_write8().
>
> And please sort lines with variable declarations in decreasing line
> length order. Netdev calls this "reverse Christmas tree" ordering and is
> the preferred coding style.
>
>> + const u16 *regs = dev->info->regs;
>> + u16 indir_reg = 0x0000;
>> + u8 indir_val = 0x00;
>> +
>> + switch (dev->low_loss_wa_mode) {
>> + case KSZ_LOW_LOSS_WA_1:
>> + indir_reg = 0x3C;
>> + indir_val = 0x15;
>> + break;
>> + case KSZ_LOW_LOSS_WA_2:
>> + indir_reg = 0x4C;
>> + indir_val = 0x40;
>
> Do the 3c and 4c registers have any associated documentation? Do we know
> what they are or what they do? We should have some macros for them,
> instead of magic numbers.
>
>> + break;
>> + default:
>> + break;
>
> Is it expected that in the default case (no workaround), the code flow
> writes indir_val = 0x00 to indir_reg = 0x0000? Or would it be better to
> just exit early without making any change?
>
>> + }
>> +
>> + mutex_lock(&dev->alu_mutex);
>> +
>> + ret = ksz_write8(dev, regs[REG_IND_CTRL_0], 0xA0);
>> +
>> + if (!ret)
>> + ret = ksz_write8(dev, 0x6F, indir_reg);
>> +
>> + if (!ret)
>> + ret = ksz_write8(dev, regs[REG_IND_BYTE], indir_val);
>
> Is this sequence better suited for ksz8_ind_write8()? Perhaps wrapped in
> another layer similar to ksz8_pme_write8(), once we know what the magic
> numbers represent in terms of indirect table?
>
>> +
>> + mutex_unlock(&dev->alu_mutex);
>> +
>> + return ret;
>> +}
>> +
>> static int ksz8_handle_global_errata(struct dsa_switch *ds)
>> {
>> struct ksz_device *dev = ds->priv;
>> @@ -1915,6 +1950,17 @@ static int ksz8_handle_global_errata(struct dsa_switch *ds)
>> if (dev->info->ksz87xx_eee_link_erratum)
>> ret = ksz8_ind_write8(dev, TABLE_EEE, REG_IND_EEE_GLOB2_HI, 0);
>>
>> + /* KSZ87xx Errata DS80000687C.
>> + * Module 3: Equalizer fix for short cables
>> + * The receiver of the embedded PHYs is tuned by default
>> + * to support long cable length applications.
>> + * Because of this, the equalizer in the PHY may amplify
>> + * high amplitude receiver signals to the point that
>> + * the signal is distorted internally
>> + */
>> + if (!ret && dev->low_loss_wa_enable && ksz_is_ksz87xx(dev))
>> + ret = ksz8_handle_module3_errata(dev);
>> +
>> return ret;
>> }
>>
>>
>> --
>> 2.53.0
>>
>
> FYI, the driver is in a restructuring process. The ksz88xx_switch_ops
> will be split out of the common ksz_switch_ops. This will conflict with
> your series, so you should rebase on top of that much larger set.
> You can coordinate with Bastien Curutchet to see what is the status:
> https://lore.kernel.org/netdev/20260313153849.qkfzv5c2u6fepjku@skbuf
Indeed, I'm currently polishing a first iteration for it. I'll send it
ASAP.
Best regards,
Bastien
^ permalink raw reply
* Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
From: Luca Ceresoli @ 2026-03-27 14:46 UTC (permalink / raw)
To: Liu Ying, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Saravana Kannan
Cc: Kory Maincent (TI.com), Hervé Codina, Hui Pu, Ian Ray,
Thomas Petazzoni, dri-devel, imx, linux-arm-kernel, linux-kernel,
devicetree, Adam Ford, Alexander Stein, Anson Huang,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Joao Paulo Goncalves,
Josua Mayer, Kieran Bingham, Marco Felsch, Martyn Welch,
Oleksij Rempel, Peng Fan, Philippe Schenker, Richard Hu,
Shengjiu Wang, Stefan Eichenberger, Vitor Soares
In-Reply-To: <544112ab-8ca0-4622-b680-233457198e3e@nxp.com>
Hello Liu,
On Thu Mar 26, 2026 at 9:15 AM CET, Liu Ying wrote:
> Hi Luca,
>
> On Fri, Mar 20, 2026 at 11:46:18AM +0100, Luca Ceresoli wrote:
>> The imx8mp-hdmi-tx one of many drivers based on dw-hdmi. dw-hdmi in turn
>> can operate in two different modes, depending on the platform data as set
>> by the driver:
>>
>> A. hdmi->plat_data->output_port = 0:
>> the HDMI output (port@1) in device tree is not used [0]
>>
>> B. hdmi->plat_data->output_port = 1:
>> the HDMI output (port@1) is parsed to find the next bridge
>>
>> The imx8mp-hdmi-tx driver falls in case A. This implies next_bridge will
>> always be NULL, and so dw_hdmi_bridge_attach() [1] will always fail if
>> called with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
>>
>> In fact case A assumes that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set and
>> in that case it adds the connector programmatically at bridge attach time.
>>
>> Support for DRM_BRIDGE_ATTACH_NO_CONNECTOR is implemented by dw-hdmi.c in
>> case B. So, in preparation to support DRM_BRIDGE_ATTACH_NO_CONNECTOR in
>> imx8mp-hdmi-tx, move to case B by setting hdmi->plat_data->output_port = 1.
>>
>> However this change requires that port@1 is connected to a "next
>> bridge" DT node, typically the HDMI connector, because dw-hdmi won't add
>> the connector when using DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>>
>> Many dts files for imx8mp-based boards in the kernel have such a connector
>> described and linked to port@1, so a connector is added by the
>> display-connector driver along with a bridge wrapping it. Sadly some of
>
> Hmm, display-connector driver is a bridge driver so it cannot add a connector.
> I assume that you mean a connector will be added by the bridge connector
> driver.
Indeed, rewording as:
Many dts files for imx8mp-based boards in the kernel have such a
connector described and linked to port@1, so the pipeline will be fully
attached up to a display-connector and a drm_connector added by the
bridge-connector.
>> --- a/drivers/gpu/drm/bridge/imx/Kconfig
>> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
>> @@ -25,6 +25,23 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
>> Choose this to enable support for the internal HDMI encoder found
>> on the i.MX8MP SoC.
>>
>> +config DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP
>> + bool "Support device tree blobs without an hdmi-connector node"
>> + default y
>
> depends on DRM_IMX_LCDIF ?
If the imx hdmi-tx is not enabled then HDMI won't work anyway, so users are
not affected and the overlay is not needed. Am I missing something?
>> + err = of_overlay_fdt_apply(dtbo_start, dtbo_size, &ovcs_id, NULL);
>> + if (err)
>> + return err;
>> +
>> + hdmi_conn = of_find_node_by_name(NULL, "fixup-hdmi-connector");
>
> Do you really need to find the node, since the overlay was just applied?
That was to ensure the node is present and error out if it isn't. But
thinking again about it after your question I don't see how it could be
missing if the overlay was successfully applied.
Removing this check in v2, which makes this function a lot simpler!
>> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
>> new file mode 100644
>> index 000000000000..ee718ca1b11b
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
>> @@ -0,0 +1,38 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * DTS overlay adding an hdmi-connector node to boards using the imx8mp hdmi_tx
>> + *
>> + * Copyright (C) 2026 GE HealthCare
>> + * Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
>> + */
>> +
>> +/dts-v1/;
>> +/plugin/;
>> +
>> +&{/} {
>
> I see build warnings(W=1):
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:25.8-37.4: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0: node has a unit name, but no reg or ranges property
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:26.16-36.5: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000: node has a unit name, but no reg or ranges property
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:27.18-35.6: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000/hdmi@32fd8000: node has a unit name, but no reg or ranges property
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:29.13-33.8: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000/hdmi@32fd8000/ports/port@1: node has a unit name, but no reg or ranges property
AFAIK the device tree checkes just can't work on overlays. The tools just
cannot know on which base tree the overlay can be applied, so they cannot
know the existing properties. That might change in the future, but for now
my understanding is that it is OK to have overlays which produce such
harmless warnings, at least for driver-specific overlays like the tilcdc
one [0] which is already in linux-next since a few weeks.
[0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=0ff223d991477fa4677dcb0f1fb00065847e2212
> Here is a patch to suppress them:
>
> --- a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
> @@ -10,6 +10,9 @@
> /plugin/;
>
> &{/} {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> fixup-hdmi-connector {
> compatible = "hdmi-connector";
> label = "HDMI";
> @@ -23,10 +26,25 @@ fixup_hdmi_connector_in: endpoint {
> };
>
> soc@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0x0 0x3e000000>;
> +
> bus@32c00000 {
> + reg = <0x32c00000 0x400000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> hdmi@32fd8000 {
> + reg = <0x32fd8000 0x7eff>;
> +
> ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> port@1 {
> + reg = <1>;
> +
> hdmi_tx_out: endpoint {
> remote-endpoint = <&fixup_hdmi_connector_in>;
> };
Thanks for taking time to look into how to get rid of the warnings.
However the sheer amount of lines added, by just duplicating lines already
in the base tree and no added value, reinforces my opinion that we should
keep the overlay as simple as it is.
Also, what if one of the property values that your diff is duplicating from
the base tree turns out being wrong in the base tree and gets fixed later
there? The wrong value would be re-added by the overlay unless someone goes
hunting all the duplicated lines around.
Based on this, do you think we really need to get rid of those warnings?
Side note: this discussion made me think about what would happen if
DRM_IMX8MP_DW_HDMI_BRIDGE is enabled on a non-imx8mp board (as for
distribution kernels as mentioned by Laurent). I think it makes sense to
add a check that /soc@0/compatible matches "fsl,imx8mp-soc" and not apply
the overlay otherwise. I'll look into that for v2.
>> + fixup-hdmi-connector {
>> + compatible = "hdmi-connector";
>> + label = "HDMI";
>> + type = "a";
>
> What if a board uses another type?
For boards affected by this patch, currently the connector is created by
dw_hdmi_connector_create() which hardcodes type A [0], so there would be no
difference.
OTOH how can a common module know the specific connector?
Boards with a different connector should describe the connector in the
device tree, if they need to instantiate the exact type.
[0] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2601
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ 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