* [PATCH v5 2/2] arm64: dts: qcom: sdm670: add thermal zones and thermal devices
From: Richard Acayan @ 2026-03-30 16:52 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Amit Kucheria, Thara Gopinath, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, linux-arm-msm, devicetree,
linux-pm
Cc: Richard Acayan
In-Reply-To: <20260330165237.101045-1-mailingradian@gmail.com>
Add thermal zones to safeguard from overheating to high temperatures,
along with the thermal sensors (TSENS) and CPU frequency limits (LMh).
The temperatures are very high, but should still be safeguard for
devices that do not specify their own thermal zones.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
arch/arm64/boot/dts/qcom/sdm670.dtsi | 400 +++++++++++++++++++++++++++
1 file changed, 400 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm670.dtsi b/arch/arm64/boot/dts/qcom/sdm670.dtsi
index f115bc6e64f3..c5f7655421a3 100644
--- a/arch/arm64/boot/dts/qcom/sdm670.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm670.dtsi
@@ -20,6 +20,7 @@
#include <dt-bindings/phy/phy-qcom-qusb2.h>
#include <dt-bindings/power/qcom-rpmpd.h>
#include <dt-bindings/soc/qcom,rpmh-rsc.h>
+#include <dt-bindings/thermal/thermal.h>
/ {
interrupt-parent = <&intc>;
@@ -62,6 +63,7 @@ cpu0: cpu@0 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd0>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_0>;
l2_0: l2-cache {
compatible = "cache";
@@ -89,6 +91,7 @@ cpu1: cpu@100 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd1>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_100>;
l2_100: l2-cache {
compatible = "cache";
@@ -111,6 +114,7 @@ cpu2: cpu@200 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd2>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_200>;
l2_200: l2-cache {
compatible = "cache";
@@ -133,6 +137,7 @@ cpu3: cpu@300 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd3>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_300>;
l2_300: l2-cache {
compatible = "cache";
@@ -155,6 +160,7 @@ cpu4: cpu@400 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd4>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_400>;
l2_400: l2-cache {
compatible = "cache";
@@ -177,6 +183,7 @@ cpu5: cpu@500 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd5>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_500>;
l2_500: l2-cache {
compatible = "cache";
@@ -199,6 +206,7 @@ cpu6: cpu@600 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd6>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_600>;
l2_600: l2-cache {
compatible = "cache";
@@ -221,6 +229,7 @@ cpu7: cpu@700 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd7>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_700>;
l2_700: l2-cache {
compatible = "cache";
@@ -1408,6 +1417,8 @@ gpu: gpu@5000000 {
nvmem-cells = <&gpu_speed_bin>;
nvmem-cell-names = "speed_bin";
+ #cooling-cells = <2>;
+
status = "disabled";
gpu_zap_shader: zap-shader {
@@ -2100,6 +2111,28 @@ dispcc: clock-controller@af00000 {
#power-domain-cells = <1>;
};
+ tsens0: thermal-sensor@c263000 {
+ compatible = "qcom,sdm670-tsens", "qcom,tsens-v2";
+ reg = <0 0x0c263000 0 0x1000>,
+ <0 0x0c222000 0 0x1000>;
+ interrupts-extended = <&pdc 26 IRQ_TYPE_EDGE_RISING>,
+ <&pdc 28 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "uplow", "critical";
+ #thermal-sensor-cells = <1>;
+ #qcom,sensors = <13>;
+ };
+
+ tsens1: thermal-sensor@c265000 {
+ compatible = "qcom,sdm670-tsens", "qcom,tsens-v2";
+ reg = <0 0x0c265000 0 0x1000>,
+ <0 0x0c223000 0 0x1000>;
+ interrupts-extended = <&pdc 27 IRQ_TYPE_EDGE_RISING>,
+ <&pdc 29 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "uplow", "critical";
+ #thermal-sensor-cells = <1>;
+ #qcom,sensors = <8>;
+ };
+
apps_smmu: iommu@15000000 {
compatible = "qcom,sdm670-smmu-500", "qcom,smmu-500", "arm,mmu-500";
reg = <0 0x15000000 0 0x80000>;
@@ -2289,5 +2322,372 @@ cpufreq_hw: cpufreq@17d43000 {
#freq-domain-cells = <1>;
};
+
+ lmh_cluster1: lmh@17d70800 {
+ compatible = "qcom,sdm670-lmh", "qcom,sdm845-lmh";
+ reg = <0 0x17d70800 0 0x400>;
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ cpus = <&cpu6>;
+ qcom,lmh-temp-arm-millicelsius = <65000>;
+ qcom,lmh-temp-low-millicelsius = <94500>;
+ qcom,lmh-temp-high-millicelsius = <95000>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+ lmh_cluster0: lmh@17d78800 {
+ compatible = "qcom,sdm670-lmh", "qcom,sdm845-lmh";
+ reg = <0 0x17d78800 0 0x400>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ cpus = <&cpu0>;
+ qcom,lmh-temp-arm-millicelsius = <65000>;
+ qcom,lmh-temp-low-millicelsius = <94500>;
+ qcom,lmh-temp-high-millicelsius = <95000>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+ };
+
+ thermal-zones {
+ aoss0-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 0>;
+
+ trips {
+ aoss0_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu0-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 1>;
+
+ trips {
+ cpu0_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu1-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 2>;
+
+ trips {
+ cpu1_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu2-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 3>;
+
+ trips {
+ cpu2_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu3-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 4>;
+
+ trips {
+ cpu3_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cluster0-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 5>;
+
+ trips {
+ cluster0_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cluster1-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 6>;
+
+ trips {
+ cluster1_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu4-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 7>;
+
+ trips {
+ cpu4_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu5-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 8>;
+
+ trips {
+ cpu5_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu6-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 9>;
+
+ trips {
+ cpu6_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu7-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 10>;
+
+ trips {
+ cpu7_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ gpu0-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 11>;
+
+ cooling-maps {
+ map0 {
+ trip = <&gpu0_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
+ trips {
+ gpu0_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+
+ gpu0_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ gpu1-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 12>;
+
+ cooling-maps {
+ map0 {
+ trip = <&gpu1_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
+ trips {
+ gpu1_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+
+ gpu1_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ aoss1-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 0>;
+
+ trips {
+ aoss1_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ q6-modem-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 1>;
+
+ trips {
+ q6_modem_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ mem-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 2>;
+
+ trips {
+ mem_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ wlan-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 3>;
+
+ trips {
+ wlan_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ q6-hvx-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 4>;
+
+ trips {
+ q6_hvx_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ camera-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 5>;
+
+ trips {
+ camera_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ video-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 6>;
+
+ trips {
+ video_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ modem-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 7>;
+
+ trips {
+ modem_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
};
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 11/11] ASoC: msm8916-wcd-analog: add quirk for cajon 2.0
From: Richard Acayan @ 2026-03-30 17:15 UTC (permalink / raw)
To: Stephan Gerhold
Cc: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
Konrad Dybcio, linux-arm-msm, linux-sound, devicetree,
Nickolay Goppen, Wesley Cheng, Greg Kroah-Hartman, Johan Hovold,
Kees Cook, Charles Keepax, Kuninori Morimoto, Adam Skladowski,
Vladimir Lypak
In-Reply-To: <aalV5dBloD1BmwzZ@linaro.org>
On Thu, Mar 05, 2026 at 11:07:33AM +0100, Stephan Gerhold wrote:
> On Wed, Mar 04, 2026 at 02:58:15PM -0500, Richard Acayan wrote:
> > The codec version CAJON_2_0 on the Snapdragon 670 requires touching the
> > HPH test registers. Add the quirk so this driver can also support
> > SDM670.
> >
> > Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> > ---
> > sound/soc/codecs/msm8916-wcd-analog.c | 63 ++++++++++++++++++++++++++-
> > 1 file changed, 61 insertions(+), 2 deletions(-)
> >
>
> I think you need some more changes in this driver to support CAJON_2_0
> properly. Specifically, the initial register settings are different from
> what is currently in the driver (wcd_reg_defaults_2_0). There was a
> patch for this [1] (later [2]), but it doesn't look like it was
> merged/finished up.
(+CC: Adam, Vlad)
It looks like the codec part is mostly complete except for some trivial
changes (empty line after compatibles in dt-bindings, constant to use
BIT(n) macro). I can take the codec patches if it's okay with the other
submitters:
- [PATCH v3 2/8] ASoC: dt-bindings: pm8916-wcd-analog-codec: Document pm8950/pm8953 Adam Skladowski
- [PATCH v3 3/8] ASoC: msm8916-wcd-analog: add pm8950 codec Adam Skladowski
- [PATCH v3 4/8] ASoC: msm8916-wcd-analog: add pm8953 codec Adam Skladowski
- [PATCH v3 8/8] ASoC: msm8916-wcd-analog: add lineout output Adam Skladowski
Maybe all the WCD codec patches should be split off to a new series,
otherwise this series would expand to 15 patches.
> [2]: https://lore.kernel.org/linux-arm-msm/20240731-msm8953-msm8976-asoc-v3-4-163f23c3a28d@gmail.com/
^ permalink raw reply
* Re: [PATCH v2 11/11] ASoC: msm8916-wcd-analog: add quirk for cajon 2.0
From: Mark Brown @ 2026-03-30 17:22 UTC (permalink / raw)
To: Richard Acayan
Cc: Stephan Gerhold, Srinivas Kandagatla, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
Konrad Dybcio, linux-arm-msm, linux-sound, devicetree,
Nickolay Goppen, Wesley Cheng, Greg Kroah-Hartman, Johan Hovold,
Kees Cook, Charles Keepax, Kuninori Morimoto, Adam Skladowski,
Vladimir Lypak
In-Reply-To: <acqvm25ap4LTSB8j@rdacayan>
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
On Mon, Mar 30, 2026 at 01:15:07PM -0400, Richard Acayan wrote:
> It looks like the codec part is mostly complete except for some trivial
There were missing signoffs so I'd be surprised if anyone had reviewed
this, I certainly didn't. Looking at the thread I for this version
there's a bunch of high level negative review comments that you have so
far as I can tell ignored.
> changes (empty line after compatibles in dt-bindings, constant to use
> BIT(n) macro). I can take the codec patches if it's okay with the other
> submitters:
Given that it looks like the series consists entirely of ASoC changes
I'd be *really* surprised to see it going via another tree.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v5 2/4] iio: adc: ad4691: add initial driver for AD4691 family
From: Andy Shevchenko @ 2026-03-30 17:24 UTC (permalink / raw)
To: Sabau, Radu bogdan
Cc: Andy Shevchenko, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, David Lechner, Sa, Nuno, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Liam Girdwood, Mark Brown, Linus Walleij,
Bartosz Golaszewski, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB84143540CE505514E1CD84B4F752A@LV9PR03MB8414.namprd03.prod.outlook.com>
On Mon, Mar 30, 2026 at 5:20 PM Sabau, Radu bogdan
<Radu.Sabau@analog.com> wrote:
> > -----Original Message-----
> > From: Andy Shevchenko <andriy.shevchenko@intel.com>
> > Sent: Friday, March 27, 2026 1:36 PM
> > To: Sabau, Radu bogdan <Radu.Sabau@analog.com>
...
> > > +#include <linux/bitfield.h>
> > > +#include <linux/bitops.h>
> > > +#include <linux/cleanup.h>
> > > +#include <linux/delay.h>
> > > +#include <linux/device.h>
> >
> > Hmm... Is it used? Or perhaps you need only
> > dev_printk.h
> > device/devres.h
> > ?
> I have checked this out and it seems device.h doesn't actually need
> to be included anyway since spi.h directly includes device.h, and since
> this is a SPI driver that's never going away, it's covered. Will drop it!
No, this is the wrong justification. IWYU principle is about exact
match between what is used and included in a file (module). spi.h is
not dev_*() provider and may not be considered for that.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 net-next 5/5] net: pcs: pcs-mtk-lynxi: deprecate "mediatek,pnswap"
From: Frank Wunderlich @ 2026-03-30 17:52 UTC (permalink / raw)
To: Vladimir Oltean
Cc: netdev, devicetree, linux-kernel, linux-mediatek, Daniel Golle,
Horatiu Vultur, Bj√∏rn Mork, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Eric Woudstra, Alexander Couzens, Chester A. Unal, DENG Qingfang,
Sean Wang, Felix Fietkau
In-Reply-To: <20260326215404.krh6v3mmnqdlndli@skbuf>
Hi Vladimir
Thanks for the patch and sorry for my delay...i was away this weekend so i was not able to test.
traffic works again (but there is only read now) and this is the result of your debug prints:
root@bpi-r3:~# dmesg | grep SGMSYS_QPHY_WRAP_CTRL
[ 2.706963] SGMSYS_QPHY_WRAP_CTRL = 0x501, intending to write 0x500
[ 9.134081] SGMSYS_QPHY_WRAP_CTRL = 0x500, intending to write 0x500
R3/mt7986 has 2 MAC, and switch is on the first, so value will change, not sure why this is different.
i have not found SGMSYS_QPHY_WRAP_CTRL or something related with polarity in ethernet/mac-
(drivers/net/ethernet/mediatek/mtk_eth_soc.c) or switch-driver (drivers/net/dsa/mt7530{,-mdio}.c)
in case they manipulate this register too (of course they should not). Also looked into the pcs-handling
in both drivers, but see nothing related to polarity. And looked for possible duplicate register const
definition (other name for 0xec).
regards Frank
Am 26. März 2026 um 22:54 schrieb "Vladimir Oltean" <vladimir.oltean@nxp.com>:
>
> Hi Frank,
>
> On Tue, Mar 24, 2026 at 06:36:44AM +0000, Frank Wunderlich wrote:
>
> >
> > Hi,
> >
> > looks like this patch breaks BPI-R3 serdes between mt7986 SoC and mt7531 switch in 7.0 (6.19 is ok).
> > in ethtool i see only tx on mac but no rx. if i revert this patch i can ping through dsa-ports again.
> >
> > i did not completely understanding the code with the default-pol as it is now splitted between rx and tx.
> >
> > mt7986 and this board does not have mediatek,pnswap set, so the final regmap_update_bits writes val=0,
> > before there was only write to this register on invert mode...but i guess this should not break. Maybe some
> > kind of timing issue between mac and switch?
> >
> > maybe reverting this patch skips changes made here:
> > bde1ae2d52ab 2026-01-19 net: pcs: pcs-mtk-lynxi: pass SGMIISYS OF node to PCS
> >
> > I resend as last try was sending as html (option "always send as text" in webmailer seems to be ignored
> > somehow, had to choose "unformatted" in this response too).
> >
> > regards Frank
> >
> Sorry for the delay.
>
> If writing val=0 breaks the link, I'm curious
> (a) whether it still breaks if we don't write anything at all
> (b) what was the register value originally
>
> Could you please test the patch below and let me know what it prints,
> and whether traffic passes with it applied?
>
> -- >8 --
> diff --git a/drivers/net/pcs/pcs-mtk-lynxi.c b/drivers/net/pcs/pcs-mtk-lynxi.c
> index c12f8087af9b..5c5f45b93b82 100644
> --- a/drivers/net/pcs/pcs-mtk-lynxi.c
> +++ b/drivers/net/pcs/pcs-mtk-lynxi.c
> @@ -126,7 +126,7 @@ static int mtk_pcs_config_polarity(struct mtk_pcs_lynxi *mpcs,
> {
> struct fwnode_handle *fwnode = mpcs->fwnode, *pcs_fwnode;
> unsigned int pol, default_pol = PHY_POL_NORMAL;
> - unsigned int val = 0;
> + unsigned int val = 0, tmp;
> int ret;
>
> if (fwnode_property_read_bool(fwnode, "mediatek,pnswap"))
> @@ -153,8 +153,14 @@ static int mtk_pcs_config_polarity(struct mtk_pcs_lynxi *mpcs,
> if (pol == PHY_POL_INVERT)
> val |= SGMII_PN_SWAP_TX;
>
> - return regmap_update_bits(mpcs->regmap, SGMSYS_QPHY_WRAP_CTRL,
> - SGMII_PN_SWAP_RX | SGMII_PN_SWAP_TX, val);
> + ret = regmap_read(mpcs->regmap, SGMSYS_QPHY_WRAP_CTRL, &tmp);
> + if (ret)
> + return ret;
> +
> + pr_err("SGMSYS_QPHY_WRAP_CTRL = 0x%x, intending to write 0x%lx\n",
> + tmp, (tmp & ~(SGMII_PN_SWAP_RX | SGMII_PN_SWAP_TX)) | val);
> +
> + return 0;
> }
>
> static int mtk_pcs_lynxi_config(struct phylink_pcs *pcs, unsigned int neg_mode,
> -- >8 --
>
regards Frank
^ permalink raw reply
* Re: [PATCH v5 08/10] dmaengine: tegra: Use iommu-map for stream ID
From: Akhil R @ 2026-03-30 18:02 UTC (permalink / raw)
To: frank.li
Cc: Frank.Li, akhilrajeev, conor+dt, devicetree, dmaengine, jonathanh,
krzk+dt, ldewangan, linux-kernel, linux-tegra, p.zabel, robh,
thierry.reding, vkoul
In-Reply-To: <acqpHJM3eilwyMMy@lizhi-Precision-Tower-5810>
On Mon, 30 Mar 2026 12:47:24 -0400, Frank Li wrote:
> On Mon, Mar 30, 2026 at 08:14:54PM +0530, Akhil R wrote:
>> Use 'iommu-map', when provided, to get the stream ID to be programmed
>> for each channel. Iterate over the channels registered and configure
>> each channel device separately using of_dma_configure_id() to allow
>> it to use a separate IOMMU domain for the transfer. However, do this
>> in a second loop since the first loop populates the DMA device channels
>> list and async_device_register() registers the channels. Both are
>> prerequisites for using the channel device in the next loop.
>>
>> Channels will continue to use the same global stream ID if the
>> 'iommu-map' property is not present in the device tree.
>>
>> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>> ---
> ...
>>
>> + /*
>> + * Configure stream ID for each channel from the channels registered
>> + * above. This is done in a separate iteration to ensure that only
>> + * the channels available and registered for the DMA device are used.
>> + */
>> + list_for_each_entry(chan, &tdma->dma_dev.channels, device_node) {
>> + chdev = &chan->dev->device;
>> + tdc = to_tegra_dma_chan(chan);
>> +
>> + if (use_iommu_map) {
>> + chdev->bus = pdev->dev.bus;
>> + dma_coerce_mask_and_coherent(chdev, DMA_BIT_MASK(cdata->addr_bits));
>> +
>> + ret = of_dma_configure_id(chdev, pdev->dev.of_node,
>> + true, &tdc->id);
>> + if (ret)
>> + return dev_err_probe(chdev, ret,
>> + "Failed to configure IOMMU for channel %d", tdc->id);
>> +
>> + if (!tegra_dev_iommu_get_stream_id(chdev, &stream_id)) {
>> + dev_err(chdev, "Failed to get stream ID for channel %d\n",
>> + tdc->id);
>> + return -EINVAL;
>
> Can you check similar problem before post patch, here also can use
> return dev_err_probe()
I did notice that, but I thought dev_err_probe is to handle -EPROBE_DEFER
and we do not use it when we return a fixed value. It returns -EINVAL here
directly.
Best Regards,
Akhil
^ permalink raw reply
* Re: [PATCH v5 08/10] dmaengine: tegra: Use iommu-map for stream ID
From: Frank Li @ 2026-03-30 18:15 UTC (permalink / raw)
To: Akhil R
Cc: Frank.Li, conor+dt, devicetree, dmaengine, jonathanh, krzk+dt,
ldewangan, linux-kernel, linux-tegra, p.zabel, robh,
thierry.reding, vkoul
In-Reply-To: <20260330180240.29906-1-akhilrajeev@nvidia.com>
On Mon, Mar 30, 2026 at 11:32:40PM +0530, Akhil R wrote:
> On Mon, 30 Mar 2026 12:47:24 -0400, Frank Li wrote:
> > On Mon, Mar 30, 2026 at 08:14:54PM +0530, Akhil R wrote:
> >> Use 'iommu-map', when provided, to get the stream ID to be programmed
> >> for each channel. Iterate over the channels registered and configure
> >> each channel device separately using of_dma_configure_id() to allow
> >> it to use a separate IOMMU domain for the transfer. However, do this
> >> in a second loop since the first loop populates the DMA device channels
> >> list and async_device_register() registers the channels. Both are
> >> prerequisites for using the channel device in the next loop.
> >>
> >> Channels will continue to use the same global stream ID if the
> >> 'iommu-map' property is not present in the device tree.
> >>
> >> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> >> ---
> > ...
> >>
> >> + /*
> >> + * Configure stream ID for each channel from the channels registered
> >> + * above. This is done in a separate iteration to ensure that only
> >> + * the channels available and registered for the DMA device are used.
> >> + */
> >> + list_for_each_entry(chan, &tdma->dma_dev.channels, device_node) {
> >> + chdev = &chan->dev->device;
> >> + tdc = to_tegra_dma_chan(chan);
> >> +
> >> + if (use_iommu_map) {
> >> + chdev->bus = pdev->dev.bus;
> >> + dma_coerce_mask_and_coherent(chdev, DMA_BIT_MASK(cdata->addr_bits));
> >> +
> >> + ret = of_dma_configure_id(chdev, pdev->dev.of_node,
> >> + true, &tdc->id);
> >> + if (ret)
> >> + return dev_err_probe(chdev, ret,
> >> + "Failed to configure IOMMU for channel %d", tdc->id);
> >> +
> >> + if (!tegra_dev_iommu_get_stream_id(chdev, &stream_id)) {
> >> + dev_err(chdev, "Failed to get stream ID for channel %d\n",
> >> + tdc->id);
> >> + return -EINVAL;
> >
> > Can you check similar problem before post patch, here also can use
> > return dev_err_probe()
>
> I did notice that, but I thought dev_err_probe is to handle -EPROBE_DEFER
> and we do not use it when we return a fixed value. It returns -EINVAL here
> directly.
even that, still can use return dev_err_probe(chddev, -EINVAL, ...) to
short your code.
Frank
>
> Best Regards,
> Akhil
^ permalink raw reply
* Re: [PATCH v5 08/10] dmaengine: tegra: Use iommu-map for stream ID
From: Akhil R @ 2026-03-30 18:20 UTC (permalink / raw)
To: frank.li
Cc: Frank.Li, akhilrajeev, conor+dt, devicetree, dmaengine, jonathanh,
krzk+dt, ldewangan, linux-kernel, linux-tegra, p.zabel, robh,
thierry.reding, vkoul
In-Reply-To: <acq9z3-lqBHY78v3@lizhi-Precision-Tower-5810>
On Mon, 30 Mar 2026 14:15:43 -0400, Frank Li wrote:
> On Mon, Mar 30, 2026 at 11:32:40PM +0530, Akhil R wrote:
>> On Mon, 30 Mar 2026 12:47:24 -0400, Frank Li wrote:
>> > On Mon, Mar 30, 2026 at 08:14:54PM +0530, Akhil R wrote:
>> >> Use 'iommu-map', when provided, to get the stream ID to be programmed
>> >> for each channel. Iterate over the channels registered and configure
>> >> each channel device separately using of_dma_configure_id() to allow
>> >> it to use a separate IOMMU domain for the transfer. However, do this
>> >> in a second loop since the first loop populates the DMA device channels
>> >> list and async_device_register() registers the channels. Both are
>> >> prerequisites for using the channel device in the next loop.
>> >>
>> >> Channels will continue to use the same global stream ID if the
>> >> 'iommu-map' property is not present in the device tree.
>> >>
>> >> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>> >> ---
>> > ...
>> >>
>> >> + /*
>> >> + * Configure stream ID for each channel from the channels registered
>> >> + * above. This is done in a separate iteration to ensure that only
>> >> + * the channels available and registered for the DMA device are used.
>> >> + */
>> >> + list_for_each_entry(chan, &tdma->dma_dev.channels, device_node) {
>> >> + chdev = &chan->dev->device;
>> >> + tdc = to_tegra_dma_chan(chan);
>> >> +
>> >> + if (use_iommu_map) {
>> >> + chdev->bus = pdev->dev.bus;
>> >> + dma_coerce_mask_and_coherent(chdev, DMA_BIT_MASK(cdata->addr_bits));
>> >> +
>> >> + ret = of_dma_configure_id(chdev, pdev->dev.of_node,
>> >> + true, &tdc->id);
>> >> + if (ret)
>> >> + return dev_err_probe(chdev, ret,
>> >> + "Failed to configure IOMMU for channel %d", tdc->id);
>> >> +
>> >> + if (!tegra_dev_iommu_get_stream_id(chdev, &stream_id)) {
>> >> + dev_err(chdev, "Failed to get stream ID for channel %d\n",
>> >> + tdc->id);
>> >> + return -EINVAL;
>> >
>> > Can you check similar problem before post patch, here also can use
>> > return dev_err_probe()
>>
>> I did notice that, but I thought dev_err_probe is to handle -EPROBE_DEFER
>> and we do not use it when we return a fixed value. It returns -EINVAL here
>> directly.
>
> even that, still can use return dev_err_probe(chddev, -EINVAL, ...) to
> short your code.
I just saw in the dev_err_probe() description that it is not limited to
-EPROBE_DEFER. Thanks for pointing. I will update the patch.
Best Regards,
Akhil
^ permalink raw reply
* Re: [PATCH 2/3] hte: tegra194: Add Tegra264 GTE support
From: Dipen Patel @ 2026-03-30 18:35 UTC (permalink / raw)
To: Suneel Garapati, jonathanh, thierry.reding, krzk+dt, conor+dt,
amhetre, sheetal, kkarthik, timestamp, devicetree, linux-tegra,
linux-kernel, robh
In-Reply-To: <20260330170657.185854-3-suneelg@nvidia.com>
On 3/30/26 10:06 AM, Suneel Garapati wrote:
> Add AON-GTE mapping and LIC GTE instance support for the Tegra264.
> Move TSC clock parameters from macros to members of SoC data
> as values differ for Tegra264 chip.
>
> Signed-off-by: Suneel Garapati <suneelg@nvidia.com>
> ---
> drivers/hte/hte-tegra194.c | 133 +++++++++++++++++++++++++++++++++++--
> 1 file changed, 128 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hte/hte-tegra194.c b/drivers/hte/hte-tegra194.c
> index 690eb9be30fb..4a7702b32b24 100644
> --- a/drivers/hte/hte-tegra194.c
> +++ b/drivers/hte/hte-tegra194.c
> @@ -20,10 +20,11 @@
>
> #define HTE_SUSPEND 0
>
> -/* HTE source clock TSC is 31.25MHz */
> +/* HTE source clock TSC is 1GHz for T264 and 31.25MHz for others */
> #define HTE_TS_CLK_RATE_HZ 31250000ULL
> +#define HTE_TS_CLK_RATE_1G 1000000000ULL
> #define HTE_CLK_RATE_NS 32
> -#define HTE_TS_NS_SHIFT __builtin_ctz(HTE_CLK_RATE_NS)
> +#define HTE_CLK_RATE_NS_1G 1
>
> #define NV_AON_SLICE_INVALID -1
> #define NV_LINES_IN_SLICE 32
> @@ -120,6 +121,8 @@ struct tegra_hte_data {
> u32 slices;
> u32 map_sz;
> u32 sec_map_sz;
> + u64 tsc_clkrate_hz;
> + u32 tsc_clkrate_ns;
> const struct tegra_hte_line_mapped *map;
> const struct tegra_hte_line_mapped *sec_map;
> };
> @@ -317,6 +320,94 @@ static const struct tegra_hte_line_mapped tegra234_aon_gpio_sec_map[] = {
> [40] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
> };
>
> +static const struct tegra_hte_line_mapped tegra264_aon_gpio_map[] = {
> + /* gpio, slice, bit_index */
> + /* AA port */
> + [0] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
> + [1] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
> + [2] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
> + [3] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
> + [4] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
> + [5] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
> + [6] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
> + [7] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
> + /* BB port */
> + [8] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
> + [9] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
> + /* CC port */
> + [10] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
> + [11] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
> + [12] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
> + [13] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
> + [14] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
> + [15] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
> + [16] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
> + [17] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
> + /* DD port */
> + [18] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
> + [19] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
> + [20] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
> + [21] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
> + [22] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
> + [23] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
> + [24] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
> + [25] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
> + /* EE port */
> + [26] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
> + [27] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
> + [28] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
> + [29] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
> +};
> +
> +static const struct tegra_hte_line_mapped tegra264_aon_gpio_sec_map[] = {
> + /* gpio, slice, bit_index */
> + /* AA port */
> + [0] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
> + [1] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
> + [2] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
> + [3] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
> + [4] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
> + [5] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
> + [6] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
> + [7] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
> + /* BB port */
> + [8] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
> + [9] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
> + [10] = {NV_AON_SLICE_INVALID, 0},
> + [11] = {NV_AON_SLICE_INVALID, 0},
> + [12] = {NV_AON_SLICE_INVALID, 0},
> + [13] = {NV_AON_SLICE_INVALID, 0},
> + [14] = {NV_AON_SLICE_INVALID, 0},
> + [15] = {NV_AON_SLICE_INVALID, 0},
> + /* CC port */
> + [16] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
> + [17] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
> + [18] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
> + [19] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
> + [20] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
> + [21] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
> + [22] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
> + [23] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
> + /* DD port */
> + [24] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
> + [25] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
> + [26] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
> + [27] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
> + [28] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
> + [29] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
> + [30] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
> + [31] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
> + /* EE port */
> + [32] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
> + [33] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
> + [34] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
> + [35] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
> + [36] = {NV_AON_SLICE_INVALID, 0},
> + [37] = {NV_AON_SLICE_INVALID, 0},
> + [38] = {NV_AON_SLICE_INVALID, 0},
> + [39] = {NV_AON_SLICE_INVALID, 0},
> +};
> +
> static const struct tegra_hte_data t194_aon_hte = {
> .map_sz = ARRAY_SIZE(tegra194_aon_gpio_map),
> .map = tegra194_aon_gpio_map,
> @@ -324,6 +415,8 @@ static const struct tegra_hte_data t194_aon_hte = {
> .sec_map = tegra194_aon_gpio_sec_map,
> .type = HTE_TEGRA_TYPE_GPIO,
> .slices = 3,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS,
> };
>
> static const struct tegra_hte_data t234_aon_hte = {
> @@ -333,6 +426,19 @@ static const struct tegra_hte_data t234_aon_hte = {
> .sec_map = tegra234_aon_gpio_sec_map,
> .type = HTE_TEGRA_TYPE_GPIO,
> .slices = 3,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS,
> +};
> +
> +static const struct tegra_hte_data t264_aon_hte = {
> + .map_sz = ARRAY_SIZE(tegra264_aon_gpio_map),
> + .map = tegra264_aon_gpio_map,
> + .sec_map_sz = ARRAY_SIZE(tegra264_aon_gpio_sec_map),
> + .sec_map = tegra264_aon_gpio_sec_map,
> + .type = HTE_TEGRA_TYPE_GPIO,
> + .slices = 4,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_1G,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS_1G,
> };
>
> static const struct tegra_hte_data t194_lic_hte = {
> @@ -340,6 +446,8 @@ static const struct tegra_hte_data t194_lic_hte = {
> .map = NULL,
> .type = HTE_TEGRA_TYPE_LIC,
> .slices = 11,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS,
> };
>
> static const struct tegra_hte_data t234_lic_hte = {
> @@ -347,6 +455,17 @@ static const struct tegra_hte_data t234_lic_hte = {
> .map = NULL,
> .type = HTE_TEGRA_TYPE_LIC,
> .slices = 17,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS,
> +};
> +
> +static const struct tegra_hte_data t264_lic_hte = {
> + .map_sz = 0,
> + .map = NULL,
> + .type = HTE_TEGRA_TYPE_LIC,
> + .slices = 10,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_1G,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS_1G,
> };
>
> static inline u32 tegra_hte_readl(struct tegra_hte_soc *hte, u32 reg)
> @@ -574,12 +693,12 @@ static int tegra_hte_release(struct hte_chip *chip, struct hte_ts_desc *desc,
> static int tegra_hte_clk_src_info(struct hte_chip *chip,
> struct hte_clk_info *ci)
> {
> - (void)chip;
> + struct tegra_hte_soc *hte_dev = chip->data;
>
> if (!ci)
> return -EINVAL;
>
> - ci->hz = HTE_TS_CLK_RATE_HZ;
> + ci->hz = hte_dev->prov_data->tsc_clkrate_hz;
> ci->type = CLOCK_MONOTONIC;
>
> return 0;
> @@ -602,8 +721,10 @@ static void tegra_hte_read_fifo(struct tegra_hte_soc *gs)
> {
> u32 tsh, tsl, src, pv, cv, acv, slice, bit_index, line_id;
> u64 tsc;
> + u8 tsc_ns_shift;
> struct hte_ts_data el;
>
> + tsc_ns_shift = __builtin_ctz(gs->prov_data->tsc_clkrate_ns);
> while ((tegra_hte_readl(gs, HTE_TESTATUS) >>
> HTE_TESTATUS_OCCUPANCY_SHIFT) &
> HTE_TESTATUS_OCCUPANCY_MASK) {
> @@ -621,7 +742,7 @@ static void tegra_hte_read_fifo(struct tegra_hte_soc *gs)
> while (acv) {
> bit_index = __builtin_ctz(acv);
> line_id = bit_index + (slice << 5);
> - el.tsc = tsc << HTE_TS_NS_SHIFT;
> + el.tsc = tsc << tsc_ns_shift;
> el.raw_level = tegra_hte_get_level(gs, line_id);
> hte_push_ts_ns(gs->chip, line_id, &el);
> acv &= ~BIT(bit_index);
> @@ -656,6 +777,8 @@ static const struct of_device_id tegra_hte_of_match[] = {
> { .compatible = "nvidia,tegra194-gte-aon", .data = &t194_aon_hte},
> { .compatible = "nvidia,tegra234-gte-lic", .data = &t234_lic_hte},
> { .compatible = "nvidia,tegra234-gte-aon", .data = &t234_aon_hte},
> + { .compatible = "nvidia,tegra264-gte-lic", .data = &t264_lic_hte},
> + { .compatible = "nvidia,tegra264-gte-aon", .data = &t264_aon_hte},
> { }
> };
> MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
Acked-by: Dipen Patel <dipenp@nvidia.com>
Signed-off-by: Dipen Patel <dipenp@nvidia.com>
^ permalink raw reply
* Re: [PATCH v5 2/2] hwmon: Add support for TI INA4230 power monitor
From: Guenter Roeck @ 2026-03-30 18:39 UTC (permalink / raw)
To: Alexey Charkov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel
In-Reply-To: <20260330-ina4230-v5-2-eeb322d95b3a@flipper.net>
On 3/30/26 08:14, Alexey Charkov wrote:
> Add a driver for the TI INA4230, a 4-channel power monitor with I2C
> interface.
>
> The driver supports voltage, current, power and energy measurements, but
> skips the alert functionality in this initial implementation.
>
> Signed-off-by: Alexey Charkov <alchark@flipper.net>
Sashiko report is at
https://sashiko.dev/#/patchset/20260330-ina4230-v5-0-eeb322d95b3a%40flipper.net
Valid concerns, as far as I can see, are:
- There are various overflow issues. Please address, either by making sure that
the operations can not overflow, or that all parameters such as the shunt
resistor value or the interval are bound such that an overflow can not occur.
This includes implicit conversions. For example, the interval passed to
ina4230_interval_ms_to_conv_time() is int, but the parameter is actually long.
There is not even a signed check, meaning the resulting interval can be pretty
much anything.
- power is reported by the chip as unsigned value. Yet, it is converted via type
cast to int16_t.
- Please add a comment to the energy reading to confirm that regmap_noinc_read()
performs as expected.
- The definition of ina4230_curr_reg[] is wasteful. There is only an entry for
hwmon_curr_input. Why specify an unnecessary two-dimensional array ?
- The dummy channel 0 for voltage is not acceptable. Make it 0-based as expected
by the ABI. Yes, I know, but that is how the ABI was defined.
I can not comment on Saskiko's pm related feedback. PM is and has always been
a mystery to me, so I just assume that it is WAI and that there are no problems.
I do assume that you have tested the code thoroughly across suspend/resume cycles
to make sure that it works as intended.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 2/3] hte: tegra194: Add Tegra264 GTE support
From: Krzysztof Kozlowski @ 2026-03-30 18:39 UTC (permalink / raw)
To: Dipen Patel, Suneel Garapati, jonathanh, thierry.reding, krzk+dt,
conor+dt, amhetre, sheetal, kkarthik, timestamp, devicetree,
linux-tegra, linux-kernel, robh
In-Reply-To: <6bbff5d0-c75d-42ef-8877-de60e7113db4@nvidia.com>
On 30/03/2026 20:35, Dipen Patel wrote:
>> MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
Please kindly trim the replies from unnecessary context. It makes it
much easier to find new content.
> Acked-by: Dipen Patel <dipenp@nvidia.com>
> Signed-off-by: Dipen Patel <dipenp@nvidia.com>
What are you certifying here with SoB?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH net-next v2 0/4] net: dsa: mt7628 embedded switch initial support
From: Joris Vaisvila @ 2026-03-30 18:40 UTC (permalink / raw)
To: netdev
Cc: horms, pabeni, kuba, edumazet, davem, olteanv, Andrew Lunn,
devicetree, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joris Vaisvila
Hello,
This patch series adds initial support for the MediaTek MT7628 Embedded
Switch.
The driver implements the basic functionality required to operate the
switch using DSA. The hardware provides five internal Fast Ethernet user
ports and one Gigabit port connected internally to the CPU MAC.
Bridge offloading is not yet supported.
Tested on an MT7628NN-based board.
changes since v1:
- changed port 6 phy-mode to internal
- cleaned up tag_mt7628 rcv function and mask defines
- fixed sorting error in drivers/net/dsa/ Kconfig and Makefile
- fixed sorting error in net/dsa/ Kconfig and Makefile
- fixed mt7628_mii_read/write return values on error
Link: https://lore.kernel.org/netdev/20260326204413.3317584-1-joey@tinyisr.com/t/#u
Thanks,
Joris
Joris Vaisvila (4):
dt-bindings: net: dsa: add MT7628 ESW
net: phy: mediatek: add phy driver for MT7628 built-in Fast Ethernet
PHYs
net: dsa: initial MT7628 tagging driver
net: dsa: initial support for MT7628 embedded switch
.../bindings/net/dsa/mediatek,mt7628-esw.yaml | 101 +++
drivers/net/dsa/Kconfig | 8 +
drivers/net/dsa/Makefile | 1 +
drivers/net/dsa/mt7628.c | 627 ++++++++++++++++++
drivers/net/phy/mediatek/Kconfig | 10 +-
drivers/net/phy/mediatek/Makefile | 1 +
drivers/net/phy/mediatek/mtk-fe-soc.c | 50 ++
include/net/dsa.h | 2 +
net/dsa/Kconfig | 6 +
net/dsa/Makefile | 1 +
net/dsa/tag_mt7628.c | 89 +++
11 files changed, 895 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml
create mode 100644 drivers/net/dsa/mt7628.c
create mode 100644 drivers/net/phy/mediatek/mtk-fe-soc.c
create mode 100644 net/dsa/tag_mt7628.c
--
2.53.0
^ permalink raw reply
* [PATCH net-next v2 1/4] dt-bindings: net: dsa: add MT7628 ESW
From: Joris Vaisvila @ 2026-03-30 18:40 UTC (permalink / raw)
To: netdev
Cc: horms, pabeni, kuba, edumazet, davem, olteanv, Andrew Lunn,
devicetree, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joris Vaisvila
In-Reply-To: <20260330184017.766200-1-joey@tinyisr.com>
Add bindings for MT7628 SoC's Embedded Switch.
Signed-off-by: Joris Vaisvila <joey@tinyisr.com>
---
.../bindings/net/dsa/mediatek,mt7628-esw.yaml | 101 ++++++++++++++++++
1 file changed, 101 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml
diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml
new file mode 100644
index 000000000000..d6c66ab677d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/mediatek,mt7628-esw.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek MT7628 Embedded Ethernet Switch
+
+maintainers:
+ - Joris Vaisvila <joey@tinyisr.com>
+
+description:
+ The MT7628 SoC's built-in Ethernet Switch is a five port switch with
+ integrated 10/100 PHYs. The switch registers are directly mapped in the SoC's
+ memory. The switch has an internally connected 1G CPU port and 5 user ports
+ connected to the built-in Fast Ethernet PHYs.
+
+unevaluatedProperties: false
+
+allOf:
+ - $ref: dsa.yaml#/$defs/ethernet-ports
+
+properties:
+ compatible:
+ const: mediatek,mt7628-esw
+
+ reg:
+ maxItems: 1
+ description: MMIO address of the switch
+
+ resets:
+ items:
+ - description: Phandle of system reset controller with ESW reset index
+ - description: Phandle of system reset controller with EPHY reset index
+
+ reset-names:
+ items:
+ - const: esw
+ - const: ephy
+
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - resets
+ - reset-names
+
+examples:
+ - |
+ switch0: switch@10110000 {
+ reg = <0x10110000 0x8000>;
+
+ resets = <&sysc 23>, <&sysc 24>;
+ reset-names = "esw", "ephy";
+
+ compatible = "mediatek,mt7628-esw";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ phy-mode = "internal";
+ };
+
+ port@1 {
+ reg = <1>;
+ phy-mode = "internal";
+ };
+
+ port@2 {
+ reg = <2>;
+ phy-mode = "internal";
+ };
+
+ port@3 {
+ reg = <3>;
+ phy-mode = "internal";
+ };
+
+ port@4 {
+ reg = <4>;
+ phy-mode = "internal";
+ };
+
+ port@6 {
+ reg = <6>;
+ phy-mode = "internal";
+ ethernet = <ðernet>;
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v2 2/4] net: phy: mediatek: add phy driver for MT7628 built-in Fast Ethernet PHYs
From: Joris Vaisvila @ 2026-03-30 18:40 UTC (permalink / raw)
To: netdev
Cc: horms, pabeni, kuba, edumazet, davem, olteanv, Andrew Lunn,
devicetree, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joris Vaisvila
In-Reply-To: <20260330184017.766200-1-joey@tinyisr.com>
The Fast Ethernet PHYs present in the MT7628 SoCs require an
undocumented bit to be set before they can establish 100mbps links.
This commit adds the Kconfig option MEDIATEK_FE_SOC_PHY and the
corresponding driver mtk-fe-soc.c.
Signed-off-by: Joris Vaisvila <joey@tinyisr.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/phy/mediatek/Kconfig | 10 +++++-
drivers/net/phy/mediatek/Makefile | 1 +
drivers/net/phy/mediatek/mtk-fe-soc.c | 50 +++++++++++++++++++++++++++
3 files changed, 60 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/phy/mediatek/mtk-fe-soc.c
diff --git a/drivers/net/phy/mediatek/Kconfig b/drivers/net/phy/mediatek/Kconfig
index bb7dc876271e..b6a51f38c358 100644
--- a/drivers/net/phy/mediatek/Kconfig
+++ b/drivers/net/phy/mediatek/Kconfig
@@ -21,8 +21,16 @@ config MEDIATEK_GE_PHY
common operations with MediaTek SoC built-in Gigabit
Ethernet PHYs.
+config MEDIATEK_FE_SOC_PHY
+ tristate "MediaTek SoC Fast Ethernet PHYs"
+ help
+ Support for MediaTek MT7628 built-in Fast Ethernet PHYs.
+ This driver only sets an initialization bit required for the PHY
+ to establish 100 Mbps links. All other PHY operations are handled
+ by the kernel's generic PHY code.
+
config MEDIATEK_GE_SOC_PHY
- tristate "MediaTek SoC Ethernet PHYs"
+ tristate "MediaTek SoC Gigabit Ethernet PHYs"
depends on ARM64 || COMPILE_TEST
depends on ARCH_AIROHA || (ARCH_MEDIATEK && NVMEM_MTK_EFUSE) || \
COMPILE_TEST
diff --git a/drivers/net/phy/mediatek/Makefile b/drivers/net/phy/mediatek/Makefile
index ac57ecc799fc..6f9cacf7f906 100644
--- a/drivers/net/phy/mediatek/Makefile
+++ b/drivers/net/phy/mediatek/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_MEDIATEK_2P5GE_PHY) += mtk-2p5ge.o
+obj-$(CONFIG_MEDIATEK_FE_SOC_PHY) += mtk-fe-soc.o
obj-$(CONFIG_MEDIATEK_GE_PHY) += mtk-ge.o
obj-$(CONFIG_MEDIATEK_GE_SOC_PHY) += mtk-ge-soc.o
obj-$(CONFIG_MTK_NET_PHYLIB) += mtk-phy-lib.o
diff --git a/drivers/net/phy/mediatek/mtk-fe-soc.c b/drivers/net/phy/mediatek/mtk-fe-soc.c
new file mode 100644
index 000000000000..317944411fbe
--- /dev/null
+++ b/drivers/net/phy/mediatek/mtk-fe-soc.c
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Driver for MT7628 Embedded Switch internal Fast Ethernet PHYs
+ */
+#include <linux/module.h>
+#include <linux/phy.h>
+
+#define MTK_FPHY_ID_MT7628 0x03a29410
+#define MTK_EXT_PAGE_ACCESS 0x1f
+
+static int mt7628_phy_read_page(struct phy_device *phydev)
+{
+ return __phy_read(phydev, MTK_EXT_PAGE_ACCESS);
+}
+
+static int mt7628_phy_write_page(struct phy_device *phydev, int page)
+{
+ return __phy_write(phydev, MTK_EXT_PAGE_ACCESS, page);
+}
+
+static int mt7628_phy_config_init(struct phy_device *phydev)
+{
+ /*
+ * This undocumented bit is required for the PHYs to be able to
+ * establish 100mbps links.
+ */
+ return phy_write_paged(phydev, 0x8000, 30, BIT(13));
+}
+
+static struct phy_driver mtk_soc_fe_phy_driver[] = {
+ {
+ PHY_ID_MATCH_EXACT(MTK_FPHY_ID_MT7628),
+ .name = "MediaTek MT7628 PHY",
+ .config_init = mt7628_phy_config_init,
+ .read_page = mt7628_phy_read_page,
+ .write_page = mt7628_phy_write_page,
+ },
+};
+
+module_phy_driver(mtk_soc_fe_phy_driver);
+static const struct mdio_device_id __maybe_unused mtk_soc_fe_phy_tbl[] = {
+ { PHY_ID_MATCH_EXACT(MTK_FPHY_ID_MT7628) },
+ { }
+};
+
+MODULE_DESCRIPTION("MediaTek SoC Fast Ethernet PHY driver");
+MODULE_AUTHOR("Joris Vaisvila <joey@tinyisr.com>");
+MODULE_LICENSE("GPL");
+
+MODULE_DEVICE_TABLE(mdio, mtk_soc_fe_phy_tbl);
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v2 3/4] net: dsa: initial MT7628 tagging driver
From: Joris Vaisvila @ 2026-03-30 18:40 UTC (permalink / raw)
To: netdev
Cc: horms, pabeni, kuba, edumazet, davem, olteanv, Andrew Lunn,
devicetree, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joris Vaisvila
In-Reply-To: <20260330184017.766200-1-joey@tinyisr.com>
Add support for the MT7628 embedded switch's tag.
The MT7628 tag is merged with the VLAN TPID field when a VLAN is
appended by the switch hardware. It is not installed if the VLAN tag is
already there on ingress. Due to this hardware quirk the tag cannot be
trusted for port 0 if we don't know that the VLAN was added by the
hardware. As a workaround for this the switch is configured to always
append the port PVID tag even if the incoming packet is already tagged.
The tagging driver can then trust that the tag is always accurate and
the whole VLAN tag can be removed on ingress as it's only metadata for
the tagger.
On egress the MT7628 tag allows precise TX, but the correct VLAN tag
from tag_8021q is still appended or the switch will not forward the
packet.
Signed-off-by: Joris Vaisvila <joey@tinyisr.com>
---
include/net/dsa.h | 2 +
net/dsa/Kconfig | 6 +++
net/dsa/Makefile | 1 +
net/dsa/tag_mt7628.c | 89 ++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 98 insertions(+)
create mode 100644 net/dsa/tag_mt7628.c
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 6c17446f3dcc..e93f9356b5c3 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -58,6 +58,7 @@ struct tc_action;
#define DSA_TAG_PROTO_YT921X_VALUE 30
#define DSA_TAG_PROTO_MXL_GSW1XX_VALUE 31
#define DSA_TAG_PROTO_MXL862_VALUE 32
+#define DSA_TAG_PROTO_MT7628_VALUE 33
enum dsa_tag_protocol {
DSA_TAG_PROTO_NONE = DSA_TAG_PROTO_NONE_VALUE,
@@ -93,6 +94,7 @@ enum dsa_tag_protocol {
DSA_TAG_PROTO_YT921X = DSA_TAG_PROTO_YT921X_VALUE,
DSA_TAG_PROTO_MXL_GSW1XX = DSA_TAG_PROTO_MXL_GSW1XX_VALUE,
DSA_TAG_PROTO_MXL862 = DSA_TAG_PROTO_MXL862_VALUE,
+ DSA_TAG_PROTO_MT7628 = DSA_TAG_PROTO_MT7628_VALUE,
};
struct dsa_switch;
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index 5ed8c704636d..946f44f0b843 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -98,6 +98,12 @@ config NET_DSA_TAG_EDSA
Say Y or M if you want to enable support for tagging frames for the
Marvell switches which use EtherType DSA headers.
+config NET_DSA_TAG_MT7628
+ tristate "Tag driver for the MT7628 embedded switch"
+ help
+ Say Y or M if you want to enable support for tagging frames for the
+ switch embedded in the MT7628 SoC.
+
config NET_DSA_TAG_MTK
tristate "Tag driver for Mediatek switches"
help
diff --git a/net/dsa/Makefile b/net/dsa/Makefile
index bf7247759a64..a84f33f0963d 100644
--- a/net/dsa/Makefile
+++ b/net/dsa/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_NET_DSA_TAG_GSWIP) += tag_gswip.o
obj-$(CONFIG_NET_DSA_TAG_HELLCREEK) += tag_hellcreek.o
obj-$(CONFIG_NET_DSA_TAG_KSZ) += tag_ksz.o
obj-$(CONFIG_NET_DSA_TAG_LAN9303) += tag_lan9303.o
+obj-$(CONFIG_NET_DSA_TAG_MT7628) += tag_mt7628.o
obj-$(CONFIG_NET_DSA_TAG_MTK) += tag_mtk.o
obj-$(CONFIG_NET_DSA_TAG_MXL_862XX) += tag_mxl862xx.o
obj-$(CONFIG_NET_DSA_TAG_MXL_GSW1XX) += tag_mxl-gsw1xx.o
diff --git a/net/dsa/tag_mt7628.c b/net/dsa/tag_mt7628.c
new file mode 100644
index 000000000000..f0e346595f30
--- /dev/null
+++ b/net/dsa/tag_mt7628.c
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2026, Joris Vaisvila <joey@tinyisr.com>
+ * MT7628 switch tag support
+ */
+
+#include <linux/etherdevice.h>
+#include <linux/dsa/8021q.h>
+#include <net/dsa.h>
+
+#include "tag.h"
+
+/*
+ * The MT7628 tag is encoded in the VLAN TPID field.
+ * On TX the lower 6 bits encode the destination port bitmask.
+ * On RX the lower 3 bits encode the source port number.
+ *
+ * The switch hardware will not modify the TPID of an incoming packet if it is
+ * already VLAN tagged. To work around this the switch is configured to always
+ * append a tag_8021q standalone VLAN tag for each port. That means we can
+ * safely strip the outer VLAN tag after parsing it.
+ *
+ * A VLAN tag is constructed on egress to target the standalone VLAN and
+ * destination port.
+ */
+
+#define MT7628_TAG_NAME "mt7628"
+
+#define MT7628_TAG_TX_PORT GENMASK(5, 0)
+#define MT7628_TAG_RX_PORT GENMASK(2, 0)
+#define MT7628_TAG_LEN 4
+
+static struct sk_buff *mt7628_tag_xmit(struct sk_buff *skb,
+ struct net_device *dev)
+{
+ struct dsa_port *dp;
+ u16 xmit_vlan;
+ __be16 *tag;
+
+ dp = dsa_user_to_port(dev);
+ xmit_vlan = dsa_tag_8021q_standalone_vid(dp);
+
+ skb_push(skb, MT7628_TAG_LEN);
+ dsa_alloc_etype_header(skb, MT7628_TAG_LEN);
+
+ tag = dsa_etype_header_pos_tx(skb);
+
+ tag[0] = htons(ETH_P_8021Q |
+ FIELD_PREP(MT7628_TAG_TX_PORT,
+ dsa_xmit_port_mask(skb, dev)));
+ tag[1] = htons(xmit_vlan);
+
+ return skb;
+}
+
+static struct sk_buff *mt7628_tag_rcv(struct sk_buff *skb,
+ struct net_device *dev)
+{
+ __be16 *phdr;
+
+ if (unlikely(!pskb_may_pull(skb, MT7628_TAG_LEN)))
+ return NULL;
+
+ phdr = dsa_etype_header_pos_rx(skb);
+ skb->dev =
+ dsa_conduit_find_user(dev, 0,
+ FIELD_GET(MT7628_TAG_RX_PORT, ntohs(*phdr)));
+ if (!skb->dev)
+ return NULL;
+
+ skb_pull_rcsum(skb, MT7628_TAG_LEN);
+ dsa_strip_etype_header(skb, MT7628_TAG_LEN);
+ dsa_default_offload_fwd_mark(skb);
+ return skb;
+}
+
+static const struct dsa_device_ops mt7628_tag_ops = {
+ .name = MT7628_TAG_NAME,
+ .proto = DSA_TAG_PROTO_MT7628,
+ .xmit = mt7628_tag_xmit,
+ .rcv = mt7628_tag_rcv,
+ .needed_headroom = MT7628_TAG_LEN,
+};
+
+module_dsa_tag_driver(mt7628_tag_ops);
+
+MODULE_ALIAS_DSA_TAG_DRIVER(DSA_TAG_PROTO_MT7628, MT7628_TAG_NAME);
+MODULE_DESCRIPTION("DSA tag driver for MT7628 switch");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v2 4/4] net: dsa: initial support for MT7628 embedded switch
From: Joris Vaisvila @ 2026-03-30 18:40 UTC (permalink / raw)
To: netdev
Cc: horms, pabeni, kuba, edumazet, davem, olteanv, Andrew Lunn,
devicetree, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joris Vaisvila
In-Reply-To: <20260330184017.766200-1-joey@tinyisr.com>
Add support for the MT7628 embedded switch.
The switch has 5 built-in 100Mbps user ports (ports 0-4) and one 1Gbps
port that is internally attached to the SoCs CPU MAC and serves as the
CPU port.
The switch hardware has a very limited 16 entry VLAN table. Configuring
VLANs is the only way to control switch forwarding. Currently 6 entries
are used by tag_8021q to isolate the ports. Double tag feature is
enabled to force the switch to append the VLAN tag even if the incoming
packet is already tagged, this simulates VLAN-unaware functionality and
simplifies the tagger implementation.
Signed-off-by: Joris Vaisvila <joey@tinyisr.com>
---
drivers/net/dsa/Kconfig | 8 +
drivers/net/dsa/Makefile | 1 +
drivers/net/dsa/mt7628.c | 627 +++++++++++++++++++++++++++++++++++++++
3 files changed, 636 insertions(+)
create mode 100644 drivers/net/dsa/mt7628.c
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 39fb8ead16b5..defe74625cef 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -28,6 +28,14 @@ source "drivers/net/dsa/hirschmann/Kconfig"
source "drivers/net/dsa/lantiq/Kconfig"
+config NET_DSA_MT7628
+ tristate "MediaTek MT7628 Embedded Ethernet switch support"
+ select NET_DSA_TAG_MT7628
+ select MEDIATEK_FE_SOC_PHY
+ help
+ This enables support for the built-in Ethernet switch found
+ in the MT7628 SoC.
+
config NET_DSA_MT7530
tristate "MediaTek MT7530 and MT7531 Ethernet switch support"
select NET_DSA_TAG_MTK
diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index f5a463b87ec2..8d4461f2d437 100644
--- a/drivers/net/dsa/Makefile
+++ b/drivers/net/dsa/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_NET_DSA_KS8995) += ks8995.o
obj-$(CONFIG_NET_DSA_MT7530) += mt7530.o
obj-$(CONFIG_NET_DSA_MT7530_MDIO) += mt7530-mdio.o
obj-$(CONFIG_NET_DSA_MT7530_MMIO) += mt7530-mmio.o
+obj-$(CONFIG_NET_DSA_MT7628) += mt7628.o
obj-$(CONFIG_NET_DSA_MV88E6060) += mv88e6060.o
obj-$(CONFIG_NET_DSA_RZN1_A5PSW) += rzn1_a5psw.o
obj-$(CONFIG_NET_DSA_SMSC_LAN9303) += lan9303-core.o
diff --git a/drivers/net/dsa/mt7628.c b/drivers/net/dsa/mt7628.c
new file mode 100644
index 000000000000..36461b39ea4a
--- /dev/null
+++ b/drivers/net/dsa/mt7628.c
@@ -0,0 +1,627 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Mediatek MT7628 Embedded Switch (ESW) DSA driver
+ * Copyright (C) 2026 Joris Vaisvila <joey@tinyisr.com>
+ *
+ * Portions derived from OpenWRT esw_rt3050 driver:
+ * Copyright (C) 2009-2015 John Crispin <blogic@openwrt.org>
+ * Copyright (C) 2009-2015 Felix Fietkau <nbd@nbd.name>
+ * Copyright (C) 2013-2015 Michael Lee <igvtee@gmail.com>
+ * Copyright (C) 2016 Vittorio Gambaletta <openwrt@vittgam.net>
+ */
+
+#include <linux/platform_device.h>
+#include <linux/etherdevice.h>
+#include <linux/netdevice.h>
+#include <linux/dsa/8021q.h>
+#include <linux/if_bridge.h>
+#include <linux/module.h>
+#include <linux/mdio.h>
+#include <linux/of.h>
+#include <linux/of_mdio.h>
+#include <linux/of_net.h>
+#include <linux/kernel.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <net/dsa.h>
+
+#define MT7628_ESW_REG_IMR 0x04
+#define MT7628_ESW_REG_FCT0 0x08
+#define MT7628_ESW_REG_PFC1 0x14
+#define MT7628_ESW_REG_PVIDC(port) (0x40 + 4 * ((port) / 2))
+#define MT7628_ESW_REG_VLANI(vlan) (0x50 + 4 * ((vlan) / 2))
+#define MT7628_ESW_REG_VMSC(vlan) (0x70 + 4 * ((vlan) / 4))
+#define MT7628_ESW_REG_VUB(vlan) (0x100 + 4 * ((vlan) / 4))
+#define MT7628_ESW_REG_SOCPC 0x8c
+#define MT7628_ESW_REG_POC0 0x90
+#define MT7628_ESW_REG_POC2 0x98
+#define MT7628_ESW_REG_SGC 0x9c
+#define MT7628_ESW_REG_PCR0 0xc0
+#define MT7628_ESW_REG_PCR1 0xc4
+#define MT7628_ESW_REG_FPA2 0xc8
+#define MT7628_ESW_REG_FCT2 0xcc
+#define MT7628_ESW_REG_SGC2 0xe4
+
+#define MT7628_ESW_FCT0_DROP_SET_TH GENMASK(7, 0)
+#define MT7628_ESW_FCT0_DROP_RLS_TH GENMASK(15, 8)
+#define MT7628_ESW_FCT0_FC_SET_TH GENMASK(23, 16)
+#define MT7628_ESW_FCT0_FC_RLS_TH GENMASK(31, 24)
+
+#define MT7628_ESW_PFC1_EN_VLAN GENMASK(22, 16)
+
+#define MT7628_ESW_PVID_S 12
+#define MT7628_ESW_PVID_M GENMASK(11, 0)
+#define MT7628_ESW_PVID_SHIFT(port) \
+ (MT7628_ESW_PVID_S * ((port) % 2))
+#define MT7628_ESW_PVID_MASK(port) \
+ (MT7628_ESW_PVID_M << MT7628_ESW_PVID_SHIFT(port))
+#define MT7628_ESW_PVID_PREP(port, pvid) \
+ (((pvid) & MT7628_ESW_PVID_M) << MT7628_ESW_PVID_SHIFT(port))
+
+#define MT7628_ESW_VID_S 12
+#define MT7628_ESW_VID_M GENMASK(11, 0)
+#define MT7628_ESW_VID_SHIFT(vlan) \
+ (MT7628_ESW_VID_S * ((vlan) % 2))
+#define MT7628_ESW_VID_MASK(vlan) \
+ (MT7628_ESW_VID_M << MT7628_ESW_VID_SHIFT(vlan))
+#define MT7628_ESW_VID_PREP(vlan, vid) \
+ (((vid) & MT7628_ESW_VID_M) << MT7628_ESW_VID_SHIFT(vlan))
+
+#define MT7628_ESW_VMSC_S 8
+#define MT7628_ESW_VMSC_M GENMASK(7, 0)
+#define MT7628_ESW_VMSC_SHIFT(vlan) \
+ (MT7628_ESW_VMSC_S * ((vlan) % 4))
+#define MT7628_ESW_VMSC_MASK(vlan) \
+ (MT7628_ESW_VMSC_M << MT7628_ESW_VMSC_SHIFT(vlan))
+#define MT7628_ESW_VMSC_PREP(vlan, vmsc) \
+ (((vmsc) & MT7628_ESW_VMSC_M) << MT7628_ESW_VMSC_SHIFT(vlan))
+
+#define MT7628_ESW_VUB_S 7
+#define MT7628_ESW_VUB_M GENMASK(6, 0)
+#define MT7628_ESW_VUB_SHIFT(vlan) \
+ (MT7628_ESW_VUB_S * ((vlan) % 4))
+#define MT7628_ESW_VUB_MASK(vlan) \
+ (MT7628_ESW_VUB_M << MT7628_ESW_VUB_SHIFT(vlan))
+#define MT7628_ESW_VUB_PREP(vlan, vub) \
+ (((vub) & MT7628_ESW_VUB_M) << MT7628_ESW_VUB_SHIFT(vlan))
+
+#define MT7628_ESW_SOCPC_CRC_PADDING BIT(25)
+#define MT7628_ESW_SOCPC_DISBC2CPU GENMASK(22, 16)
+#define MT7628_ESW_SOCPC_DISMC2CPU GENMASK(14, 8)
+#define MT7628_ESW_SOCPC_DISUN2CPU GENMASK(6, 0)
+
+#define MT7628_ESW_POC0_PORT_DISABLE GENMASK(29, 23)
+
+#define MT7628_ESW_POC2_PER_VLAN_UNTAG_EN BIT(15)
+
+#define MT7628_ESW_SGC_AGING_INTERVAL GENMASK(3, 0)
+#define MT7628_ESW_BC_STORM_PROT GENMASK(5, 4)
+#define MT7628_ESW_PKT_MAX_LEN GENMASK(7, 6)
+#define MT7628_ESW_DIS_PKT_ABORT BIT(8)
+#define MT7628_ESW_ADDRESS_HASH_ALG GENMASK(10, 9)
+#define MT7628_ESW_DISABLE_TX_BACKOFF BIT(11)
+#define MT7628_ESW_BP_JAM_CNT GENMASK(15, 12)
+#define MT7628_ESW_DISMIIPORT_WASTX GENMASK(17, 16)
+#define MT7628_ESW_BP_MODE GENMASK(19, 18)
+#define MT7628_ESW_BISH_DIS BIT(20)
+#define MT7628_ESW_BISH_TH GENMASK(22, 21)
+#define MT7628_ESW_LED_FLASH_TIME GENMASK(24, 23)
+#define MT7628_ESW_RMC_RULE GENMASK(26, 25)
+#define MT7628_ESW_IP_MULT_RULE GENMASK(28, 27)
+#define MT7628_ESW_LEN_ERR_CHK BIT(29)
+#define MT7628_ESW_BKOFF_ALG BIT(30)
+
+#define MT7628_ESW_PCR0_WT_NWAY_DATA GENMASK(31, 16)
+#define MT7628_ESW_PCR0_RD_PHY_CMD BIT(14)
+#define MT7628_ESW_PCR0_WT_PHY_CMD BIT(13)
+#define MT7628_ESW_PCR0_CPU_PHY_REG GENMASK(12, 8)
+#define MT7628_ESW_PCR0_CPU_PHY_ADDR GENMASK(4, 0)
+
+#define MT7628_ESW_PCR1_RD_DATA GENMASK(31, 16)
+#define MT7628_ESW_PCR1_RD_DONE BIT(1)
+#define MT7628_ESW_PCR1_WT_DONE BIT(0)
+
+#define MT7628_ESW_FPA2_AP_EN BIT(29)
+#define MT7628_ESW_FPA2_EXT_PHY_ADDR_BASE GENMASK(28, 24)
+#define MT7628_ESW_FPA2_FORCE_RGMII_LINK1 BIT(13)
+#define MT7628_ESW_FPA2_FORCE_RGMII_EN1 BIT(11)
+
+#define MT7628_ESW_FCT2_MUST_DROP_RLS_TH GENMASK(17, 13)
+#define MT7628_ESW_FCT2_MUST_DROP_SET_TH GENMASK(12, 8)
+#define MT7628_ESW_FCT2_MC_PER_PORT_TH GENMASK(5, 0)
+
+#define MT7628_ESW_SGC2_SPECIAL_TAG_EN BIT(23)
+#define MT7628_ESW_SGC2_TX_CPU_TPID_BIT_MAP GENMASK(22, 16)
+#define MT7628_ESW_SGC2_DOUBLE_TAG_EN GENMASK(6, 0)
+
+#define MT7628_ESW_PORTS_NOCPU GENMASK(5, 0)
+#define MT7628_ESW_PORTS_CPU BIT(6)
+#define MT7628_ESW_PORTS_ALL GENMASK(6, 0)
+
+#define MT7628_ESW_NUM_PORTS 7
+#define MT7628_NUM_VLANS 16
+
+static const struct regmap_config mt7628_esw_regmap_cfg = {
+ .name = "mt7628-esw",
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .fast_io = true,
+ .reg_format_endian = REGMAP_ENDIAN_LITTLE,
+ .val_format_endian = REGMAP_ENDIAN_LITTLE,
+};
+
+struct mt7628_vlan {
+ bool active;
+ u8 members;
+ u8 untag;
+ u16 vid;
+};
+
+struct mt7628_esw {
+ void __iomem *base;
+ struct reset_control *rst_ephy;
+ struct reset_control *rst_esw;
+ struct regmap *regmap;
+ struct dsa_switch *ds;
+ u16 tag_8021q_pvid[MT7628_ESW_NUM_PORTS];
+ struct mt7628_vlan vlans[MT7628_NUM_VLANS];
+ struct device *dev;
+};
+
+static int mt7628_mii_read(struct mii_bus *bus, int port, int regnum)
+{
+ struct mt7628_esw *esw = bus->priv;
+ int ret;
+ u32 val;
+
+ ret = regmap_read_poll_timeout(esw->regmap, MT7628_ESW_REG_PCR1, val,
+ !(val & MT7628_ESW_PCR1_RD_DONE), 10,
+ 5000);
+ if (ret)
+ goto out;
+
+ ret = regmap_write(esw->regmap, MT7628_ESW_REG_PCR0,
+ FIELD_PREP(MT7628_ESW_PCR0_CPU_PHY_REG,
+ regnum) |
+ FIELD_PREP(MT7628_ESW_PCR0_CPU_PHY_ADDR,
+ port) | MT7628_ESW_PCR0_RD_PHY_CMD);
+ if (ret)
+ goto out;
+
+ ret = regmap_read_poll_timeout(esw->regmap, MT7628_ESW_REG_PCR1, val,
+ (val & MT7628_ESW_PCR1_RD_DONE), 10,
+ 5000);
+out:
+ if (ret) {
+ dev_err(&bus->dev, "read failed. MDIO timeout?\n");
+ return ret;
+ }
+ return FIELD_GET(MT7628_ESW_PCR1_RD_DATA, val);
+}
+
+static int mt7628_mii_write(struct mii_bus *bus, int port, int regnum, u16 dat)
+{
+ struct mt7628_esw *esw = bus->priv;
+ u32 val;
+ int ret;
+
+ ret = regmap_read_poll_timeout(esw->regmap, MT7628_ESW_REG_PCR1, val,
+ !(val & MT7628_ESW_PCR1_WT_DONE), 10,
+ 5000);
+ if (ret)
+ goto out;
+
+ ret = regmap_write(esw->regmap, MT7628_ESW_REG_PCR0,
+ FIELD_PREP(MT7628_ESW_PCR0_WT_NWAY_DATA, dat) |
+ FIELD_PREP(MT7628_ESW_PCR0_CPU_PHY_REG,
+ regnum) |
+ FIELD_PREP(MT7628_ESW_PCR0_CPU_PHY_ADDR,
+ port) | MT7628_ESW_PCR0_WT_PHY_CMD);
+ if (ret)
+ goto out;
+
+ ret = regmap_read_poll_timeout(esw->regmap, MT7628_ESW_REG_PCR1, val,
+ (val & MT7628_ESW_PCR1_WT_DONE), 10,
+ 5000);
+out:
+ if (ret) {
+ dev_err(&bus->dev, "write failed. MDIO timeout?\n");
+ return ret;
+ }
+ return 0;
+}
+
+static int mt7628_setup_internal_mdio(struct dsa_switch *ds)
+{
+ struct mt7628_esw *esw = ds->priv;
+ struct device_node *mdio;
+ struct mii_bus *bus;
+ int ret = 0;
+
+ mdio = of_get_available_child_by_name(ds->dev->of_node, "mdio");
+
+ bus = devm_mdiobus_alloc(esw->dev);
+ if (!bus) {
+ ret = -ENOMEM;
+ goto out_put_node;
+ }
+
+ bus->name = "MT7628 internal MDIO bus";
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%s-mii", dev_name(ds->dev));
+ bus->priv = esw;
+ bus->read = mt7628_mii_read;
+ bus->write = mt7628_mii_write;
+ bus->parent = esw->dev;
+ if (!mdio) {
+ ds->user_mii_bus = bus;
+ bus->phy_mask = ~ds->phys_mii_mask;
+ }
+
+ ret = devm_of_mdiobus_register(esw->dev, bus, mdio);
+
+out_put_node:
+ of_node_put(mdio);
+ return ret;
+}
+
+static void mt7628_switch_init(struct dsa_switch *ds)
+{
+ struct mt7628_esw *esw = ds->priv;
+
+ regmap_write(esw->regmap, MT7628_ESW_REG_FCT0,
+ FIELD_PREP(MT7628_ESW_FCT0_DROP_SET_TH, 0x50) |
+ FIELD_PREP(MT7628_ESW_FCT0_DROP_RLS_TH, 0x78) |
+ FIELD_PREP(MT7628_ESW_FCT0_FC_SET_TH, 0xa0) |
+ FIELD_PREP(MT7628_ESW_FCT0_FC_RLS_TH, 0xc8));
+
+ regmap_write(esw->regmap, MT7628_ESW_REG_FCT2,
+ FIELD_PREP(MT7628_ESW_FCT2_MC_PER_PORT_TH, 0xc) |
+ FIELD_PREP(MT7628_ESW_FCT2_MUST_DROP_SET_TH, 0x10) |
+ FIELD_PREP(MT7628_ESW_FCT2_MUST_DROP_RLS_TH, 0x12));
+
+ /*
+ * general switch configuration:
+ * 300s aging interval
+ * broadcast storm prevention disabled
+ * max packet length 1536 bytes
+ * disable collision 16 packet abort and late collision abort
+ * use xor48 for address hashing
+ * disable tx backoff
+ * 10 packet back pressure jam
+ * disable was_transmit
+ * jam until BP condition released
+ * 30ms LED flash
+ * rmc tb fault to all ports
+ * unmatched IGMP as broadcast
+ */
+ regmap_write(esw->regmap, MT7628_ESW_REG_SGC,
+ FIELD_PREP(MT7628_ESW_SGC_AGING_INTERVAL, 1) |
+ FIELD_PREP(MT7628_ESW_BC_STORM_PROT, 0) |
+ FIELD_PREP(MT7628_ESW_PKT_MAX_LEN, 0) |
+ MT7628_ESW_DIS_PKT_ABORT |
+ FIELD_PREP(MT7628_ESW_ADDRESS_HASH_ALG, 1) |
+ MT7628_ESW_DISABLE_TX_BACKOFF |
+ FIELD_PREP(MT7628_ESW_BP_JAM_CNT, 10) |
+ FIELD_PREP(MT7628_ESW_DISMIIPORT_WASTX, 0) |
+ FIELD_PREP(MT7628_ESW_BP_MODE, 0b10) |
+ FIELD_PREP(MT7628_ESW_LED_FLASH_TIME, 0) |
+ FIELD_PREP(MT7628_ESW_RMC_RULE, 0) |
+ FIELD_PREP(MT7628_ESW_IP_MULT_RULE, 0));
+
+ regmap_write(esw->regmap, MT7628_ESW_REG_SOCPC,
+ MT7628_ESW_SOCPC_CRC_PADDING |
+ FIELD_PREP(MT7628_ESW_SOCPC_DISUN2CPU,
+ MT7628_ESW_PORTS_CPU) |
+ FIELD_PREP(MT7628_ESW_SOCPC_DISMC2CPU,
+ MT7628_ESW_PORTS_CPU) |
+ FIELD_PREP(MT7628_ESW_SOCPC_DISBC2CPU,
+ MT7628_ESW_PORTS_CPU));
+
+ regmap_set_bits(esw->regmap, MT7628_ESW_REG_FPA2,
+ MT7628_ESW_FPA2_FORCE_RGMII_EN1 |
+ MT7628_ESW_FPA2_FORCE_RGMII_LINK1 |
+ MT7628_ESW_FPA2_AP_EN);
+
+ regmap_update_bits(esw->regmap, MT7628_ESW_REG_FPA2,
+ MT7628_ESW_FPA2_EXT_PHY_ADDR_BASE,
+ FIELD_PREP(MT7628_ESW_FPA2_EXT_PHY_ADDR_BASE, 31));
+
+ /* disable all interrupts */
+ regmap_write(esw->regmap, MT7628_ESW_REG_IMR, 0);
+
+ /* enable MT7628 DSA tag on CPU port */
+ regmap_write(esw->regmap, MT7628_ESW_REG_SGC2,
+ MT7628_ESW_SGC2_SPECIAL_TAG_EN |
+ FIELD_PREP(MT7628_ESW_SGC2_TX_CPU_TPID_BIT_MAP,
+ MT7628_ESW_PORTS_CPU));
+
+ /*
+ * Double tag feature allows switch to always append the port PVID VLAN tag
+ * regardless of if the incoming packet already has a VLAN tag.
+ * This is enabled to simulate VLAN unawareness.
+ */
+ regmap_set_bits(esw->regmap, MT7628_ESW_REG_SGC2,
+ FIELD_PREP(MT7628_ESW_SGC2_DOUBLE_TAG_EN,
+ MT7628_ESW_PORTS_NOCPU));
+
+ regmap_set_bits(esw->regmap, MT7628_ESW_REG_POC2,
+ MT7628_ESW_POC2_PER_VLAN_UNTAG_EN);
+
+ regmap_update_bits(esw->regmap, MT7628_ESW_REG_PFC1,
+ MT7628_ESW_PFC1_EN_VLAN,
+ FIELD_PREP(MT7628_ESW_PFC1_EN_VLAN,
+ MT7628_ESW_PORTS_ALL));
+}
+
+static void mt7628_esw_set_pvid(struct mt7628_esw *esw, unsigned int port,
+ unsigned int pvid)
+{
+ regmap_update_bits(esw->regmap, MT7628_ESW_REG_PVIDC(port),
+ MT7628_ESW_PVID_MASK(port),
+ MT7628_ESW_PVID_PREP(port, pvid));
+}
+
+static void mt7628_esw_set_vlan_id(struct mt7628_esw *esw, unsigned int vlan,
+ unsigned int vid)
+{
+ regmap_update_bits(esw->regmap, MT7628_ESW_REG_VLANI(vlan),
+ MT7628_ESW_VID_MASK(vlan),
+ MT7628_ESW_VID_PREP(vlan, vid));
+}
+
+static void mt7628_esw_set_vmsc(struct mt7628_esw *esw, unsigned int vlan,
+ unsigned int msc)
+{
+ regmap_update_bits(esw->regmap, MT7628_ESW_REG_VMSC(vlan),
+ MT7628_ESW_VMSC_MASK(vlan),
+ MT7628_ESW_VMSC_PREP(vlan, msc));
+}
+
+static void mt7628_esw_set_vub(struct mt7628_esw *esw, unsigned int vlan,
+ unsigned int vub)
+{
+ regmap_update_bits(esw->regmap, MT7628_ESW_REG_VUB(vlan),
+ MT7628_ESW_VUB_MASK(vlan),
+ MT7628_ESW_VUB_PREP(vlan, vub));
+}
+
+static void mt7628_vlan_sync(struct dsa_switch *ds)
+{
+ struct mt7628_esw *esw = ds->priv;
+ int i;
+
+ for (i = 0; i < MT7628_NUM_VLANS; i++) {
+ struct mt7628_vlan *vlan = &esw->vlans[i];
+
+ mt7628_esw_set_vmsc(esw, i, vlan->members);
+ mt7628_esw_set_vlan_id(esw, i, vlan->vid);
+ mt7628_esw_set_vub(esw, i, vlan->untag);
+ }
+
+ for (i = 0; i < ds->num_ports; i++)
+ mt7628_esw_set_pvid(esw, i, esw->tag_8021q_pvid[i]);
+}
+
+static int mt7628_setup(struct dsa_switch *ds)
+{
+ struct mt7628_esw *esw = ds->priv;
+ int ret;
+
+ reset_control_reset(esw->rst_esw);
+ usleep_range(1000, 2000);
+ reset_control_reset(esw->rst_ephy);
+ usleep_range(1000, 2000);
+ /*
+ * all MMIO reads hang if esw is not out of reset
+ * ephy needs extra time to get out of reset or it ends up misconfigured
+ */
+ mt7628_switch_init(ds);
+ rtnl_lock();
+ dsa_tag_8021q_register(ds, htons(ETH_P_8021Q));
+ rtnl_unlock();
+
+ ret = mt7628_setup_internal_mdio(ds);
+ return ret;
+}
+
+static int mt7628_port_enable(struct dsa_switch *ds, int port,
+ struct phy_device *phy)
+{
+ struct mt7628_esw *esw = ds->priv;
+
+ regmap_clear_bits(esw->regmap, MT7628_ESW_REG_POC0,
+ FIELD_PREP(MT7628_ESW_POC0_PORT_DISABLE, BIT(port)));
+ return 0;
+}
+
+static void mt7628_port_disable(struct dsa_switch *ds, int port)
+{
+ struct mt7628_esw *esw = ds->priv;
+
+ regmap_set_bits(esw->regmap, MT7628_ESW_REG_POC0,
+ FIELD_PREP(MT7628_ESW_POC0_PORT_DISABLE, BIT(port)));
+}
+
+static enum dsa_tag_protocol
+mt7628_get_tag_proto(struct dsa_switch *ds, int port, enum dsa_tag_protocol mp)
+{
+ return DSA_TAG_PROTO_MT7628;
+}
+
+static void mt7628_phylink_get_caps(struct dsa_switch *ds, int port,
+ struct phylink_config *config)
+{
+ switch (port) {
+ case 6:
+ config->mac_capabilities |= MAC_1000;
+ fallthrough;
+ case 0 ... 4:
+ config->mac_capabilities |= MAC_100 | MAC_10;
+ __set_bit(PHY_INTERFACE_MODE_INTERNAL,
+ config->supported_interfaces);
+ break;
+ default:
+ break; /* port 5 does not exist on MT7628 */
+ }
+}
+
+static int mt7628_dsa_8021q_vlan_add(struct dsa_switch *ds, int port,
+ u16 vid, u16 flags)
+{
+ struct mt7628_esw *esw = ds->priv;
+ struct mt7628_vlan *vlan = NULL;
+ int i;
+
+ for (i = 0; i < MT7628_NUM_VLANS; i++) {
+ struct mt7628_vlan *check_vlan = &esw->vlans[i];
+
+ if (!check_vlan->active && !vlan) {
+ vlan = check_vlan;
+ } else if (check_vlan->vid == vid) {
+ vlan = check_vlan;
+ break;
+ }
+ }
+
+ if (!vlan)
+ return -ENOSPC;
+
+ vlan->vid = vid;
+ vlan->active = true;
+ vlan->members |= BIT(port);
+
+ if (flags & BRIDGE_VLAN_INFO_PVID)
+ esw->tag_8021q_pvid[port] = vid;
+
+ if (flags & BRIDGE_VLAN_INFO_UNTAGGED)
+ vlan->untag |= BIT(port);
+
+ mt7628_vlan_sync(ds);
+ return 0;
+}
+
+static int mt7628_dsa_8021q_vlan_del(struct dsa_switch *ds, int port, u16 vid)
+{
+ struct mt7628_esw *esw = ds->priv;
+ struct mt7628_vlan *vlan = NULL;
+ int i;
+
+ for (i = 0; i < MT7628_NUM_VLANS; i++) {
+ struct mt7628_vlan *check_vlan = &esw->vlans[i];
+
+ if (!check_vlan->active || check_vlan->vid != vid)
+ continue;
+ vlan = check_vlan;
+ break;
+ }
+ if (!vlan)
+ return -ENOENT;
+
+ vlan->members &= ~BIT(port);
+ vlan->untag &= ~BIT(port);
+
+ if (!vlan->members)
+ vlan->active = false;
+
+ mt7628_vlan_sync(ds);
+ return 0;
+}
+
+static struct dsa_switch_ops mt7628_switch_ops = {
+ .get_tag_protocol = mt7628_get_tag_proto,
+ .setup = mt7628_setup,
+ .port_enable = mt7628_port_enable,
+ .port_disable = mt7628_port_disable,
+ .phylink_get_caps = mt7628_phylink_get_caps,
+ .tag_8021q_vlan_add = mt7628_dsa_8021q_vlan_add,
+ .tag_8021q_vlan_del = mt7628_dsa_8021q_vlan_del,
+};
+
+static int mt7628_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct mt7628_esw *esw;
+ struct dsa_switch *ds;
+
+ ds = devm_kzalloc(&pdev->dev, sizeof(*ds), GFP_KERNEL);
+ if (!ds)
+ return -ENOMEM;
+
+ esw = devm_kzalloc(&pdev->dev, sizeof(*esw), GFP_KERNEL);
+ if (!esw)
+ return -ENOMEM;
+
+ esw->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(esw->base))
+ return PTR_ERR(esw->base);
+
+ esw->regmap = devm_regmap_init_mmio(&pdev->dev, esw->base,
+ &mt7628_esw_regmap_cfg);
+ if (IS_ERR(esw->regmap))
+ return PTR_ERR(esw->regmap);
+
+ esw->rst_ephy = devm_reset_control_get_exclusive(&pdev->dev, "ephy");
+ if (IS_ERR(esw->rst_ephy))
+ return dev_err_probe(dev, PTR_ERR(esw->rst_ephy),
+ "failed to get EPHY reset\n");
+
+ esw->rst_esw = devm_reset_control_get_exclusive(&pdev->dev, "esw");
+ if (IS_ERR(esw->rst_esw))
+ return dev_err_probe(dev, PTR_ERR(esw->rst_esw),
+ "failed to get ESW reset\n");
+
+ ds->dev = dev;
+ ds->num_ports = MT7628_ESW_NUM_PORTS;
+ ds->ops = &mt7628_switch_ops;
+ ds->priv = esw;
+ esw->ds = ds;
+ esw->dev = dev;
+ dev_set_drvdata(dev, esw);
+
+ return dsa_register_switch(ds);
+}
+
+static void mt7628_remove(struct platform_device *pdev)
+{
+ struct mt7628_esw *esw = platform_get_drvdata(pdev);
+
+ if (!esw)
+ return;
+
+ dsa_unregister_switch(esw->ds);
+}
+
+static void mt7628_shutdown(struct platform_device *pdev)
+{
+ struct mt7628_esw *esw = platform_get_drvdata(pdev);
+
+ if (!esw)
+ return;
+
+ dsa_switch_shutdown(esw->ds);
+ dev_set_drvdata(&pdev->dev, NULL);
+}
+
+static const struct of_device_id mt7628_of_match[] = {
+ { .compatible = "mediatek,mt7628-esw" },
+ {}
+};
+
+MODULE_DEVICE_TABLE(of, mt7628_of_match);
+
+static struct platform_driver mt7628_driver = {
+ .driver = {
+ .name = "mt7628-esw",
+ .of_match_table = mt7628_of_match,
+ },
+ .probe = mt7628_probe,
+ .remove = mt7628_remove,
+ .shutdown = mt7628_shutdown,
+};
+
+module_platform_driver(mt7628_driver);
+
+MODULE_AUTHOR("Joris Vaisvila <joey@tinyisr.com>");
+MODULE_DESCRIPTION("Driver for Mediatek MT7628 embedded switch");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 1/2] dt-bindings: phy: qcom-edp: Add reference clock for sa8775p eDP PHY
From: Dmitry Baryshkov @ 2026-03-30 18:42 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Ritesh Kumar, robin.clark, lumag, abhinav.kumar, sean,
marijn.suijten, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt, quic_mahap, konradybcio, mani,
James.Bottomley, martin.petersen, vkoul, kishon,
cros-qcom-dts-watchers, linux-phy, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, linux-scsi, quic_vproddut
In-Reply-To: <acqGFwaVFQ3ZNmlR@baldur>
On Mon, Mar 30, 2026 at 09:28:40AM -0500, Bjorn Andersson wrote:
> On Wed, Mar 11, 2026 at 06:37:31PM +0530, Ritesh Kumar wrote:
> >
> > On 3/5/2026 12:27 AM, Bjorn Andersson wrote:
> > > On Wed, Jan 28, 2026 at 05:18:49PM +0530, Ritesh Kumar wrote:
> > > > The initial sa8775p eDP PHY binding contribution missed adding support for
> > > > voting on the eDP reference clock. This went unnoticed because the UFS PHY
> > > > driver happened to enable the same clock.
> > > > > After commit 77d2fa54a945 ("scsi: ufs: qcom : Refactor
> > > phy_power_on/off
> > > > calls"), the eDP reference clock is no longer kept enabled, which results
> > > > in the following PHY power-on failure:
> > > > > phy phy-aec2a00.phy.10: phy poweron failed --> -110
> > > > > To fix this, explicit voting for the eDP reference clock is
> > > required.
> > > > This patch adds the eDP reference clock for sa8775p eDP PHY and updates
> > > > the corresponding example node.
> > > > > Signed-off-by: Ritesh Kumar <quic_riteshk@quicinc.com>
> > >
> > > Is there any reason why you didn't follow up on this patch Ritesh?
> > > Looks like it's ready to be merged.
> >
> > I was waiting for patch to merge as there is no pending comments.
> >
>
> It's been two months now, if you want your patches to be merged please
> show that - ask the maintainer for a status update, ask a colleague to
> send a reviewed-by...
>
> Perhaps the maintainer lost track of your change?
>
> Perhaps it's not clear that the change "need" an Ack from e.g. Dmitry
> and then it should be merged by Vinod? Because you're changing two
> different subsystems but leave it up to the maintainers to figure out
> how to deal with this...
>
>
> Either way, show that you want this to be merged, don't just wait until
> the situation resolves itself.
For merging through linux-phy:
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Vinod, please pick it up through your tree.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 1/2] thermal/qcom/lmh: support SDM670 and its CPU clusters
From: Dmitry Baryshkov @ 2026-03-30 18:43 UTC (permalink / raw)
To: Richard Acayan
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Amit Kucheria, Thara Gopinath, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, linux-arm-msm, devicetree,
linux-pm
In-Reply-To: <20260330165237.101045-2-mailingradian@gmail.com>
On Mon, Mar 30, 2026 at 12:52:36PM -0400, Richard Acayan wrote:
> The LMh driver was made for Qualcomm SoCs with clusters of 4 CPUs, but
> some SoCs divide the CPUs into different sizes of clusters. In SDM670,
> the first 6 CPUs are in the little cluster and the next 2 are in the big
> cluster. Define the clusters in the match data and define the different
> cluster configuration for SDM670.
>
> Currently, this tolerates linking to any CPU in a given cluster.
>
> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> ---
> drivers/thermal/qcom/lmh.c | 54 ++++++++++++++++++++++++--------------
> 1 file changed, 34 insertions(+), 20 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 2/2] arm64: dts: qcom: sdm670: add thermal zones and thermal devices
From: Dmitry Baryshkov @ 2026-03-30 18:44 UTC (permalink / raw)
To: Richard Acayan
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Amit Kucheria, Thara Gopinath, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, linux-arm-msm, devicetree,
linux-pm
In-Reply-To: <20260330165237.101045-3-mailingradian@gmail.com>
On Mon, Mar 30, 2026 at 12:52:37PM -0400, Richard Acayan wrote:
> Add thermal zones to safeguard from overheating to high temperatures,
> along with the thermal sensors (TSENS) and CPU frequency limits (LMh).
> The temperatures are very high, but should still be safeguard for
> devices that do not specify their own thermal zones.
>
> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> ---
> arch/arm64/boot/dts/qcom/sdm670.dtsi | 400 +++++++++++++++++++++++++++
> 1 file changed, 400 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 3/5] pinctrl: qcom: add sdm670 lpi tlmm
From: Dmitry Baryshkov @ 2026-03-30 18:45 UTC (permalink / raw)
To: Richard Acayan
Cc: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
In-Reply-To: <20260330164707.87441-4-mailingradian@gmail.com>
On Mon, Mar 30, 2026 at 12:47:05PM -0400, Richard Acayan wrote:
> The Snapdragon 670 has an Low-Power Island (LPI) TLMM for configuring
> pins related to audio. Add the driver for this.
>
> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> drivers/pinctrl/qcom/Kconfig | 10 ++
> drivers/pinctrl/qcom/Makefile | 1 +
> .../pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c | 166 ++++++++++++++++++
> 3 files changed, 177 insertions(+)
> create mode 100644 drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 5/5] arm64: dts: qcom: sdm670-google: add reserved lpi gpios
From: Dmitry Baryshkov @ 2026-03-30 18:46 UTC (permalink / raw)
To: Richard Acayan
Cc: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
In-Reply-To: <20260330164707.87441-6-mailingradian@gmail.com>
On Mon, Mar 30, 2026 at 12:47:07PM -0400, Richard Acayan wrote:
> Some of the GPIOs are reserved for sensors since the ADSP also handles
> sensors on SDM670. Add the reserved GPIOs for the LPI pin controller.
>
> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
> index cf7b130ea0c4..b0da24fd1aee 100644
> --- a/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
> @@ -519,6 +519,10 @@ rmi4_f12: rmi4-f12@12 {
> };
> };
>
> +&lpi_tlmm {
> + gpio-reserved-ranges = <0 8>, <12 6>;
Could you possibly add a comment, what are these pins used for?
> +};
> +
> &mdss {
> status = "okay";
> };
> --
> 2.53.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] dt-bindings: display/msm: qcm2290-mdss: Fix missing ranges in example
From: Dmitry Baryshkov @ 2026-03-30 18:50 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Loic Poulain, Sumit Garg,
linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <177488647743.633011.6769674149013868210.b4-ty@kernel.org>
On Mon, Mar 30, 2026 at 11:01:21AM -0500, Bjorn Andersson wrote:
>
> On Wed, 25 Mar 2026 13:22:10 +0100, Krzysztof Kozlowski wrote:
> > Device node has children with MMIO addressing, so must have ranges:
> >
> > msm/qcom,qcm2290-mdss.example.dtb: display-subsystem@5e00000 (qcom,qcm2290-mdss): 'ranges' is a required property
> >
> >
>
> Applied, thanks!
>
> [1/1] dt-bindings: display/msm: qcm2290-mdss: Fix missing ranges in example
> commit: 88bdac5443e5269bb39c4968d5ee0becbffe3f82
Hmm? I don't really mind, but...
>
> Best regards,
> --
> Bjorn Andersson <andersson@kernel.org>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 07/22] ASoC: dt-bindings: renesas,rsnd: Add RZ/G3E support
From: Geert Uytterhoeven @ 2026-03-30 18:47 UTC (permalink / raw)
To: John Madieu
Cc: Krzysztof Kozlowski, Kuninori Morimoto, Vinod Koul, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Michael Turquette, Stephen Boyd,
Conor Dooley, Frank Li, Liam Girdwood, magnus.damm,
Thomas Gleixner, Jaroslav Kysela, Takashi Iwai, Philipp Zabel,
Claudiu.Beznea, Biju Das, Fabrizio Castro, Prabhakar Mahadev Lad,
John Madieu, linux-renesas-soc@vger.kernel.org,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
linux-sound@vger.kernel.org
In-Reply-To: <TY6PR01MB173775E9970A41ED3A7FFF1DAFF52A@TY6PR01MB17377.jpnprd01.prod.outlook.com>
Hi John,
On Mon, 30 Mar 2026 at 17:40, John Madieu <john.madieu.xa@bp.renesas.com> wrote:
> > From: Krzysztof Kozlowski <krzk@kernel.org>
> > > RZ/G3E has a different audio architecture from R-Car Gen2/Gen3/Gen4,
> > > with additional clocks and resets:
> > > - Per-SSI ADG clocks (adg.ssi.0-9)
> > > - SCU related clocks (scu, scu_x2, scu_supply)
> > > - SSIF supply clock
> > > - AUDMAC peri-peri clock
> > > - ADG clock
> > > - Additional resets for SCU, ADG, and AUDMAC peri-peri
> > >
> > > RZ/G3E has 5 DMA controllers that can all be used by audio peripherals.
> > > To allow the DMA core to distribute channels across all available
> > > controllers, increase the maximum number of DMA entries in DVC, SRC,
> > > and SSIU sub-nodes so that multiple providers can be listed with
> > > repeated channel names.
> > >
> > > Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> > > b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
> > > index e8a2acb92646..bc8885c4fa24 100644
> > > --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
> > > +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
> > > @@ -58,6 +58,7 @@ properties:
> > > - renesas,rcar_sound-gen2
> > > - renesas,rcar_sound-gen3
> > > - renesas,rcar_sound-gen4
> > > + - renesas,rcar_sound-r9a09g047 # RZ/G3E
> >
> > Do not use underscores in compatibles. Previously used wrong style is not
> > the excuse here, just like previously poor code, mistakes, bugs,
> > unreadable approches is not justification to repeat the same.
>
> Got it.
>
> > > reg:
> > > minItems: 1
> > > @@ -97,20 +98,22 @@ properties:
> > >
> > > resets:
> > > minItems: 1
> > > - maxItems: 11
> > > + maxItems: 14
> > >
> > > reset-names:
> > > minItems: 1
> > > - maxItems: 11
> > > + maxItems: 14
> > >
> > > clocks:
> > > description: References to SSI/SRC/MIX/CTU/DVC/AUDIO_CLK clocks.
> > > minItems: 1
> > > - maxItems: 31
> > > + maxItems: 47
> > >
> > > clock-names:
> > > description: List of necessary clock names.
> > > # details are defined below
> > > + minItems: 1
> > > + maxItems: 47
> > >
> > > # ports is below
> > > port:
> > > @@ -136,9 +139,17 @@ properties:
> > >
> > > properties:
> > > dmas:
> > > - maxItems: 1
> > > + description:
> > > + Must contain unique DMA specifiers, one per available
> > > + DMAC. On RZ/G3E, up to 5 for transmission.
> > > + minItems: 1
> > > + maxItems: 5
> > > dma-names:
> > > - const: tx
> > > + minItems: 1
> > > + maxItems: 5
> > > + items:
> > > + enum:
> > > + - tx
> >
> > Multiple levels, multiple if:then: (further) - I don't find this binding
> > manageable/readable. You should split it, with common binding defining
> > common part of hardware or interface if there is such.
>
> I as you suggested, I'll split it. Just to double check, should I fix
> any bug found in there (like existing compatible strings having underscore
> separators) ? Or should I just split and make sure only new SoC support is
> bug free ?
You cannot just change existing compatible values, as they are part
of the DT ABI.
When you split RZ/G3E off into a separate file, please drop the
"rcar"-part[*] in its compatible value, and move the SoC-specific part
right after the comma. Perhaps "renesas,r9a09g047-sound"?
[*] Disclaimer: I haven't read the RZ/G3E audio chapter yet.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] dt-bindings: display/msm: qcm2290-mdss: Fix missing ranges in example
From: Krzysztof Kozlowski @ 2026-03-30 18:55 UTC (permalink / raw)
To: Dmitry Baryshkov, Bjorn Andersson
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Loic Poulain, Sumit Garg,
linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <wsf7oet6r7d55i7f6cdwgor4cqu3hzgqcv3r6lmyfsoivzgzls@v5z7bbea6fxe>
On 30/03/2026 20:50, Dmitry Baryshkov wrote:
> On Mon, Mar 30, 2026 at 11:01:21AM -0500, Bjorn Andersson wrote:
>>
>> On Wed, 25 Mar 2026 13:22:10 +0100, Krzysztof Kozlowski wrote:
>>> Device node has children with MMIO addressing, so must have ranges:
>>>
>>> msm/qcom,qcm2290-mdss.example.dtb: display-subsystem@5e00000 (qcom,qcm2290-mdss): 'ranges' is a required property
>>>
>>>
>>
>> Applied, thanks!
>>
>> [1/1] dt-bindings: display/msm: qcm2290-mdss: Fix missing ranges in example
>> commit: 88bdac5443e5269bb39c4968d5ee0becbffe3f82
>
> Hmm? I don't really mind, but...
>
Please read changelog in original patch. I was also mentioning this on
msm IRC (although not towards you), so this is not done silently.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
From: Dmitry Baryshkov @ 2026-03-30 18:55 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: johannes.goede, Loic Poulain, vladimir.zapolskiy,
laurent.pinchart, kieran.bingham, robh, krzk+dt, andersson,
konradybcio, linux-media, linux-arm-msm, devicetree, linux-kernel,
mchehab
In-Reply-To: <0879e4c1-5381-4a70-9fb3-4af9b3bf6e48@kernel.org>
On Mon, Mar 30, 2026 at 03:11:58PM +0100, Bryan O'Donoghue wrote:
> On 30/03/2026 14:46, johannes.goede@oss.qualcomm.com wrote:
> > > > And then your CCMv1 or CCMv2 helper will get called with
> > > > the matching parameter-data.
> > > This leads to userspace having to know exact format for each hardware
> > > version, which is not nice. At the very least it should be possible to
> > > accept CCMv1 buffers and covert them to CCMv2 when required.
> > Yes, but a new ISP may also have a different pipeline altogether
> > with e.g. more then one preview/viewfinder output vs one viewfinder
> > output for current hw, etc.
>
> My scoping on HFI shows that the IQ structures between Kona and later
> versions have pretty stable data-structures.
>
> It might be worthwhile for the non-HFI version to implement those
> structures.
>
> I keep mentioning CDM. Its also possible to construct the buffer in the
> format the CDM would require and hand that from user-space into the kernel.
>
> That would save alot of overhead translating from one format to another.
>
> That's another reason I bring up CDM again and again. We probably don't want
> to fix to the wrong format for OPE, introduce the CDM and then find we have
> to map from one format to another for large and complex data over and over
> again for each frame or every N frames.
>
> TBH I think the CDM should happen for this system and in that vein is there
> any reason not to pack the data in the order the CDM will want ?
This sounds like the most horrible idea: letting userspace directly
program any registers in a way that is not visible to the kernel.
>
> So probably in fact IQ structs are not the right thing for OPE+IFE.
>
> ---
> bod
--
With best wishes
Dmitry
^ 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