* [PATCH net v2 3/5] net: dsa: mt7530: fix CPU port VLAN not being reset to unaware
From: Daniel Golle @ 2026-05-14 14:04 UTC (permalink / raw)
To: Chester A. Unal, Daniel Golle, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, DENG Qingfang,
Florian Fainelli, Arınç ÜNAL, Sean Wang, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1778766629.git.daniel@makrotopia.org>
After a VLAN-aware bridge is destroyed, creating any VLAN-unaware
bridge loses all connectivity. The VID 0 VLAN table entry used by
VLAN-unaware ports in FALLBACK mode gets corrupted during VLAN-aware
operation: mt7530_hw_vlan_add() overwrites its EG_CON flag with
VTAG_EN and bridge teardown removes ports from its PORT_MEM.
The cleanup code that should restore it never runs because the current
port's dp->vlan_filtering flag is still true when checked (DSA updates
it only after the driver callback returns). Even when restored, the
deferred VLAN deletion events from the switchdev workqueue can corrupt
VID 0 again after the restoration.
Skip the current port in the all_user_ports_removed check, call
mt7530_setup_vlan0() to restore the VID 0 entry, and protect VID 0
from being modified by bridge VLAN operations in port_vlan_add and
port_vlan_del since it is managed exclusively by mt7530_setup_vlan0().
Remove the CPU port PCR and PVC register writes which were clobbering
PORT_VLAN mode and VLAN_ATTR with wrong values.
Fixes: 83163f7dca56 ("net: dsa: mediatek: add VLAN support for MT7530")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
v2: no changes
drivers/net/dsa/mt7530.c | 111 ++++++++++++++++++++++-----------------
1 file changed, 62 insertions(+), 49 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 4f657ef6aa65..752ba92b0851 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1623,6 +1623,49 @@ mt7530_port_bridge_join(struct dsa_switch *ds, int port,
return 0;
}
+static int
+mt7530_vlan_cmd(struct mt7530_priv *priv, enum mt7530_vlan_cmd cmd, u16 vid)
+{
+ struct mt7530_dummy_poll p;
+ u32 val;
+ int ret;
+
+ val = VTCR_BUSY | VTCR_FUNC(cmd) | vid;
+ mt7530_write(priv, MT7530_VTCR, val);
+
+ INIT_MT7530_DUMMY_POLL(&p, priv, MT7530_VTCR);
+ ret = readx_poll_timeout(_mt7530_read, &p, val,
+ !(val & VTCR_BUSY), 20, 20000);
+ if (ret < 0) {
+ dev_err(priv->dev, "poll timeout\n");
+ return ret;
+ }
+
+ val = mt7530_read(priv, MT7530_VTCR);
+ if (val & VTCR_INVALID) {
+ dev_err(priv->dev, "read VTCR invalid\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int
+mt7530_setup_vlan0(struct mt7530_priv *priv)
+{
+ u32 val;
+
+ /* Validate the entry with independent learning, keep the original
+ * ingress tag attribute.
+ */
+ val = IVL_MAC | EG_CON | PORT_MEM(MT7530_ALL_MEMBERS) | FID(FID_BRIDGED) |
+ VLAN_VALID;
+ mt7530_write(priv, MT7530_VAWD1, val);
+ mt7530_write(priv, MT7530_VAWD2, 0);
+
+ return mt7530_vlan_cmd(priv, MT7530_VTCR_WR_VID, 0);
+}
+
static void
mt7530_port_set_vlan_unaware(struct dsa_switch *ds, int port)
{
@@ -1648,6 +1691,8 @@ mt7530_port_set_vlan_unaware(struct dsa_switch *ds, int port)
G0_PORT_VID_DEF);
for (i = 0; i < priv->ds->num_ports; i++) {
+ if (i == port)
+ continue;
if (dsa_is_user_port(ds, i) &&
dsa_port_is_vlan_filtering(dsa_to_port(ds, i))) {
all_user_ports_removed = false;
@@ -1659,13 +1704,9 @@ mt7530_port_set_vlan_unaware(struct dsa_switch *ds, int port)
* the CPU port get out of VLAN filtering mode.
*/
if (all_user_ports_removed) {
- struct dsa_port *dp = dsa_to_port(ds, port);
- struct dsa_port *cpu_dp = dp->cpu_dp;
-
- mt7530_write(priv, MT7530_PCR_P(cpu_dp->index),
- PCR_MATRIX(dsa_user_ports(priv->ds)));
- mt7530_write(priv, MT7530_PVC_P(cpu_dp->index), PORT_SPEC_TAG
- | PVC_EG_TAG(MT7530_VLAN_EG_CONSISTENT));
+ mutex_lock(&priv->reg_mutex);
+ mt7530_setup_vlan0(priv);
+ mutex_unlock(&priv->reg_mutex);
}
}
@@ -1853,33 +1894,6 @@ mt7530_port_mdb_del(struct dsa_switch *ds, int port,
return ret;
}
-static int
-mt7530_vlan_cmd(struct mt7530_priv *priv, enum mt7530_vlan_cmd cmd, u16 vid)
-{
- struct mt7530_dummy_poll p;
- u32 val;
- int ret;
-
- val = VTCR_BUSY | VTCR_FUNC(cmd) | vid;
- mt7530_write(priv, MT7530_VTCR, val);
-
- INIT_MT7530_DUMMY_POLL(&p, priv, MT7530_VTCR);
- ret = readx_poll_timeout(_mt7530_read, &p, val,
- !(val & VTCR_BUSY), 20, 20000);
- if (ret < 0) {
- dev_err(priv->dev, "poll timeout\n");
- return ret;
- }
-
- val = mt7530_read(priv, MT7530_VTCR);
- if (val & VTCR_INVALID) {
- dev_err(priv->dev, "read VTCR invalid\n");
- return -EINVAL;
- }
-
- return 0;
-}
-
static int
mt7530_port_vlan_filtering(struct dsa_switch *ds, int port, bool vlan_filtering,
struct netlink_ext_ack *extack)
@@ -1984,21 +1998,6 @@ mt7530_hw_vlan_update(struct mt7530_priv *priv, u16 vid,
mt7530_vlan_cmd(priv, MT7530_VTCR_WR_VID, vid);
}
-static int
-mt7530_setup_vlan0(struct mt7530_priv *priv)
-{
- u32 val;
-
- /* Validate the entry with independent learning, keep the original
- * ingress tag attribute.
- */
- val = IVL_MAC | EG_CON | PORT_MEM(MT7530_ALL_MEMBERS) | FID(FID_BRIDGED) |
- VLAN_VALID;
- mt7530_write(priv, MT7530_VAWD1, val);
-
- return mt7530_vlan_cmd(priv, MT7530_VTCR_WR_VID, 0);
-}
-
static int
mt7530_port_vlan_add(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_vlan *vlan,
@@ -2011,9 +2010,18 @@ mt7530_port_vlan_add(struct dsa_switch *ds, int port,
mutex_lock(&priv->reg_mutex);
+ /* VID 0 is managed exclusively by mt7530_setup_vlan0() for
+ * VLAN-unaware bridge operation. Don't let the bridge overwrite
+ * its EG_CON flag with VTAG_EN and corrupt PORT_MEM.
+ */
+ if (vlan->vid == 0)
+ goto skip_vlan_table;
+
mt7530_hw_vlan_entry_init(&new_entry, port, untagged);
mt7530_hw_vlan_update(priv, vlan->vid, &new_entry, mt7530_hw_vlan_add);
+skip_vlan_table:
+
if (pvid) {
priv->ports[port].pvid = vlan->vid;
@@ -2053,10 +2061,15 @@ mt7530_port_vlan_del(struct dsa_switch *ds, int port,
mutex_lock(&priv->reg_mutex);
+ /* VID 0 is managed exclusively by mt7530_setup_vlan0(). */
+ if (vlan->vid == 0)
+ goto skip_vlan_table;
+
mt7530_hw_vlan_entry_init(&target_entry, port, 0);
mt7530_hw_vlan_update(priv, vlan->vid, &target_entry,
mt7530_hw_vlan_del);
+skip_vlan_table:
/* PVID is being restored to the default whenever the PVID port
* is being removed from the VLAN.
*/
--
2.54.0
^ permalink raw reply related
* [PATCH net v2 2/5] net: dsa: mt7530: preserve VLAN tags on trapped link-local frames
From: Daniel Golle @ 2026-05-14 14:04 UTC (permalink / raw)
To: Chester A. Unal, Daniel Golle, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, DENG Qingfang,
Florian Fainelli, Arınç ÜNAL, Sean Wang, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1778766629.git.daniel@makrotopia.org>
The BPC, RGAC1 and RGAC2 registers control the handling of link-local
frames with reserved MAC DAs (01:80:C2:00:00:0x). These frames are
correctly trapped to the CPU port, but the egress VLAN tag attribute was
set to MT7530_VLAN_EG_UNTAGGED which causes the switch to strip any
VLAN tags from trapped frames before they reach the CPU.
This causes VLAN-tagged link-local frames (STP BPDUs, LLDP, PTP Peer
Delay Requests) to arrive at the CPU without their VLAN tag, so they
are delivered to the base network interface instead of the VLAN
sub-interface. The DSA local_termination selftest confirms this: all
link-local protocol tests on VLAN upper interfaces fail.
Set the EG_TAG attribute to MT7530_VLAN_EG_DISABLED (system default)
so that the switch does not modify VLAN tags in trapped frames. This
way VLAN-tagged frames retain their original tag and are delivered to
the correct VLAN sub-interface, matching the behavior of non-trapped
frames which pass through without VLAN tag modification.
Fixes: 69ddba9d170b ("net: dsa: mt7530: fix handling of all link-local frames")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Acked-by: Chester A. Unal <chester.a.unal@arinc9.com>
---
v2: no changes
drivers/net/dsa/mt7530.c | 27 +++++++++++++++------------
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index cd311dfd3600..4f657ef6aa65 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1300,37 +1300,40 @@ static void mt7530_setup_port5(struct dsa_switch *ds, phy_interface_t interface)
static void
mt753x_trap_frames(struct mt7530_priv *priv)
{
- /* Trap 802.1X PAE frames and BPDUs to the CPU port(s) and egress them
- * VLAN-untagged.
+ /* Trap 802.1X PAE frames and BPDUs to the CPU port(s) and egress
+ * them with the EG_TAG attribute set to disabled (system default)
+ * so that any VLAN tags in the frame are not modified by the
+ * switch egress VLAN tag processing. This preserves VLAN tags
+ * for reception on VLAN sub-interfaces.
*/
mt7530_rmw(priv, MT753X_BPC,
PAE_BPDU_FR | PAE_EG_TAG_MASK | PAE_PORT_FW_MASK |
BPDU_EG_TAG_MASK | BPDU_PORT_FW_MASK,
- PAE_BPDU_FR | PAE_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
+ PAE_BPDU_FR | PAE_EG_TAG(MT7530_VLAN_EG_DISABLED) |
PAE_PORT_FW(TO_CPU_FW_CPU_ONLY) |
- BPDU_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
+ BPDU_EG_TAG(MT7530_VLAN_EG_DISABLED) |
TO_CPU_FW_CPU_ONLY);
- /* Trap frames with :01 and :02 MAC DAs to the CPU port(s) and egress
- * them VLAN-untagged.
+ /* Trap frames with :01 and :02 MAC DAs to the CPU port(s) and
+ * egress them with EG_TAG disabled.
*/
mt7530_rmw(priv, MT753X_RGAC1,
R02_BPDU_FR | R02_EG_TAG_MASK | R02_PORT_FW_MASK |
R01_BPDU_FR | R01_EG_TAG_MASK | R01_PORT_FW_MASK,
- R02_BPDU_FR | R02_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
+ R02_BPDU_FR | R02_EG_TAG(MT7530_VLAN_EG_DISABLED) |
R02_PORT_FW(TO_CPU_FW_CPU_ONLY) | R01_BPDU_FR |
- R01_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
+ R01_EG_TAG(MT7530_VLAN_EG_DISABLED) |
TO_CPU_FW_CPU_ONLY);
- /* Trap frames with :03 and :0E MAC DAs to the CPU port(s) and egress
- * them VLAN-untagged.
+ /* Trap frames with :03 and :0E MAC DAs to the CPU port(s) and
+ * egress them with EG_TAG disabled.
*/
mt7530_rmw(priv, MT753X_RGAC2,
R0E_BPDU_FR | R0E_EG_TAG_MASK | R0E_PORT_FW_MASK |
R03_BPDU_FR | R03_EG_TAG_MASK | R03_PORT_FW_MASK,
- R0E_BPDU_FR | R0E_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
+ R0E_BPDU_FR | R0E_EG_TAG(MT7530_VLAN_EG_DISABLED) |
R0E_PORT_FW(TO_CPU_FW_CPU_ONLY) | R03_BPDU_FR |
- R03_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
+ R03_EG_TAG(MT7530_VLAN_EG_DISABLED) |
TO_CPU_FW_CPU_ONLY);
}
--
2.54.0
^ permalink raw reply related
* [PATCH net v2 1/5] net: dsa: mt7530: fix FDB entries not aging out with short timeout
From: Daniel Golle @ 2026-05-14 14:04 UTC (permalink / raw)
To: Chester A. Unal, Daniel Golle, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, DENG Qingfang,
Florian Fainelli, Arınç ÜNAL, Sean Wang, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1778766629.git.daniel@makrotopia.org>
The DSA forwarding selftests bridge_vlan_aware.sh and
bridge_vlan_unaware.sh configure the bridge with ageing_time set to
LOW_AGEING_TIME (1000 centiseconds, i.e. 10 seconds) and then run
learning_test() in lib.sh, which expects a learned FDB entry to be
removed after ageing_time + 10 seconds. On MT7530/MT7531 the entry
persisted past the deadline and the "Found FDB record when should
not" assertion failed.
With msecs=10000, the algorithm in mt7530_set_ageing_time() finds
AGE_CNT=0 and AGE_UNIT=9 as the first exact match (starting the
search from tmp_age_count=0). The per-entry aging counter is
initialized to AGE_CNT when a MAC address is learned, so with
AGE_CNT=0 new entries start with a counter value of 0, which the
hardware treats as "already aged" and never removes, effectively
disabling aging.
Fix this by starting the search from tmp_age_count=1 to ensure
entries always have a non-zero initial aging counter. For a
10-second ageing time this yields AGE_CNT=1 and AGE_UNIT=4 instead:
the timer ticks every 5 seconds and entries are removed after 2
ticks.
Starting the search at AGE_CNT=1 raises the minimum representable
ageing time from 1 to 2 seconds. Without bounds, a stale ageing_time
of 1 second would now make the loop fall through without setting
age_count and age_unit, leaving them uninitialized when written to
the MT7530_AAC hardware register. Set ds->ageing_time_min and
ds->ageing_time_max so the DSA core validates the range before the
callback is invoked, and drop the now-redundant range check from
mt7530_set_ageing_time().
Fixes: ea6d5c924e39 ("net: dsa: mt7530: support setting ageing time")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
v2:
- Set ds->ageing_time_min = 2 * 1000 and
ds->ageing_time_max = (AGE_CNT_MAX + 1) * (AGE_UNIT_MAX + 1) * 1000
in mt7530_setup() and mt7531_setup_common() so the DSA core
rejects out-of-range values before calling the driver.
- Drop the now-redundant `if (secs < 1 || ...)` range check from
mt7530_set_ageing_time(); v1 left it in place and would have
written uninitialized age_count/age_unit to MT7530_AAC for
secs == 1 (loop falls through without ever finding a match
once tmp_age_count starts at 1).
- Reworked commit message to lead with the bridge_vlan_aware.sh /
bridge_vlan_unaware.sh learning_test() scenario that exposes
the bug, walk through the search-loop math for LOW_AGEING_TIME
(10 s), and document the new lower bound.
drivers/net/dsa/mt7530.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 44d670904ad8..cd311dfd3600 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1023,12 +1023,16 @@ mt7530_set_ageing_time(struct dsa_switch *ds, unsigned int msecs)
unsigned int age_count;
unsigned int age_unit;
- /* Applied timer is (AGE_CNT + 1) * (AGE_UNIT + 1) seconds */
- if (secs < 1 || secs > (AGE_CNT_MAX + 1) * (AGE_UNIT_MAX + 1))
- return -ERANGE;
-
- /* iterate through all possible age_count to find the closest pair */
- for (tmp_age_count = 0; tmp_age_count <= AGE_CNT_MAX; ++tmp_age_count) {
+ /* Applied timer is (AGE_CNT + 1) * (AGE_UNIT + 1) seconds.
+ * The DSA core has already validated the range using
+ * ds->ageing_time_min and ds->ageing_time_max.
+ *
+ * Iterate through all possible age_count values to find the closest
+ * pair. Start from 1 because the per-entry aging counter is
+ * initialized to AGE_CNT and a value of 0 means the entry will
+ * never be aged out.
+ */
+ for (tmp_age_count = 1; tmp_age_count <= AGE_CNT_MAX; ++tmp_age_count) {
unsigned int tmp_age_unit = secs / (tmp_age_count + 1) - 1;
if (tmp_age_unit <= AGE_UNIT_MAX) {
@@ -2428,6 +2432,8 @@ mt7530_setup(struct dsa_switch *ds)
ds->assisted_learning_on_cpu_port = true;
ds->mtu_enforcement_ingress = true;
+ ds->ageing_time_min = 2 * 1000;
+ ds->ageing_time_max = (AGE_CNT_MAX + 1) * (AGE_UNIT_MAX + 1) * 1000;
if (priv->id == ID_MT7530) {
regulator_set_voltage(priv->core_pwr, 1000000, 1000000);
@@ -2617,6 +2623,8 @@ mt7531_setup_common(struct dsa_switch *ds)
ds->assisted_learning_on_cpu_port = true;
ds->mtu_enforcement_ingress = true;
+ ds->ageing_time_min = 2 * 1000;
+ ds->ageing_time_max = (AGE_CNT_MAX + 1) * (AGE_UNIT_MAX + 1) * 1000;
mt753x_trap_frames(priv);
--
2.54.0
^ permalink raw reply related
* [PATCH net v2 0/5] net: dsa: mt7530: assorted fixes
From: Daniel Golle @ 2026-05-14 14:04 UTC (permalink / raw)
To: Chester A. Unal, Daniel Golle, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, DENG Qingfang,
Florian Fainelli, Arınç ÜNAL, Sean Wang, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
A batch of small, independent fixes for the MediaTek MT7530 family DSA
driver, addressing long-standing correctness issues that surface on
hardware with bridge VLAN filtering enabled, on link-local frame
reception, and during bridge join/leave transitions.
---
Changes since v1:
- rework patch 1/5 following up Paolo Abeni and Sashiko reviews
Daniel Golle (4):
net: dsa: mt7530: fix FDB entries not aging out with short timeout
net: dsa: mt7530: preserve VLAN tags on trapped link-local frames
net: dsa: mt7530: fix CPU port VLAN not being reset to unaware
net: dsa: mt7530: clear flood flags on bridge leave
Edward Parker (1):
net: dsa: mt7530: untag VLAN-aware bridge PVID
drivers/net/dsa/mt7530.c | 165 +++++++++++++++++++++++----------------
1 file changed, 98 insertions(+), 67 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH net-next v6 01/12] dt-bindings: net: airoha: Add EN7581 ethernet-ports properties
From: Rob Herring @ 2026-05-14 14:01 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Krzysztof Kozlowski, Conor Dooley, Christian Marangi,
Benjamin Larsson, linux-arm-kernel, linux-mediatek, netdev,
devicetree
In-Reply-To: <20260511-airoha-eth-multi-serdes-v6-1-c899462c4f75@kernel.org>
On Mon, May 11, 2026 at 12:49:27PM +0200, Lorenzo Bianconi wrote:
> EN7581 and AN7583 SoCs support connecting multiple external SerDes to GDM3
> or GDM4 ports via a hw arbiter that manages the traffic in a TDM manner.
> As a result multiple net_devices can connect to the same GDM{3,4} port
> and there is a theoretical "1:n" relation between GDM ports and
> net_devices.
> Introduce the ethernet-port property in order to model a given net_device
> that is connected via the external arbiter to the GDM{3,4} port (that
> is represented by the ethernet property. Please note GDM1 or GDM2 does not
> support the connection with the external arbiter and are represented
> by ethernet property.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> .../devicetree/bindings/net/airoha,en7581-eth.yaml | 64 +++++++++++++++++++++-
> 1 file changed, 63 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> index fbe2ddcdd909..642f300c0945 100644
> --- a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> +++ b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> @@ -130,6 +130,50 @@ patternProperties:
> maximum: 4
> description: GMAC port identifier
>
> + '#address-cells':
> + const: 1
blank line
> + '#size-cells':
> + const: 0
> +
> + allOf:
> + - if:
> + properties:
> + reg:
> + contains:
> + items:
> + - enum:
> + - 3
> + - 4
> + then:
> + properties:
> + '#address-cells':
> + const: 1
> + '#size-cells':
> + const: 0
Why do you have these twice? Drop this one.
> +
> + patternProperties:
> + "^ethernet-port@[0-5]$":
> + type: object
> + unevaluatedProperties: false
> + $ref: ethernet-controller.yaml#
> + description: External ethernet port ID available on the GDM port
> +
> + properties:
> + compatible:
> + const: airoha,eth-port
> +
> + reg:
> + maxItems: 1
Instead, 'maximum: 5'.
> + description: External ethernet port identifier
> +
> + required:
> + - reg
> + - compatible
> +
> + required:
> + - "#address-cells"
> + - "#size-cells"
> +
> required:
> - reg
> - compatible
> @@ -191,9 +235,27 @@ examples:
> #address-cells = <1>;
> #size-cells = <0>;
>
> - mac: ethernet@1 {
> + mac1: ethernet@1 {
Just drop unused labels.
> compatible = "airoha,eth-mac";
> reg = <1>;
> };
> +
> + mac4: ethernet@4 {
> + compatible = "airoha,eth-mac";
> + reg = <4>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet-port@0 {
> + compatible = "airoha,eth-port";
> + reg = <0>;
> + };
> +
> + ethernet-port@1 {
> + compatible = "airoha,eth-port";
> + reg = <1>;
> + };
> + };
> };
> };
>
> --
> 2.54.0
>
^ permalink raw reply
* [PATCH] ASoC: mediatek: mt8189: Fix probe resource cleanup
From: Cássio Gabriel @ 2026-05-14 13:52 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Matthias Brugger, AngeloGioacchino Del Regno, Cyril Chao
Cc: linux-sound, linux-kernel, linux-arm-kernel, linux-mediatek,
Cássio Gabriel
The MT8189 AFE probe assigns reserved memory with
of_reserved_mem_device_init(), but only releases that assignment from
.remove(). If probe fails after the reserved memory has been assigned,
the assignment record is left behind.
The probe path also uses pm_runtime_get_sync() without checking its
return value. If runtime resume fails, pm_runtime_get_sync() leaves the
usage count incremented and the driver continues initialization without
the device being resumed. Use pm_runtime_resume_and_get() so resume
errors abort probe without leaking a PM usage count.
Finally, component registration failure currently jumps to a label that
drops a runtime PM reference even though the temporary probe reference
was already released. Return the component registration error directly,
and do not drop an unmatched PM reference from .remove().
Fixes: 7eb153585598 ("ASoC: mediatek: mt8189: add platform driver")
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
---
sound/soc/mediatek/mt8189/mt8189-afe-pcm.c | 38 ++++++++++++++++++++++--------
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/sound/soc/mediatek/mt8189/mt8189-afe-pcm.c b/sound/soc/mediatek/mt8189/mt8189-afe-pcm.c
index 24b0c78815f6..77cf2b604f6c 100644
--- a/sound/soc/mediatek/mt8189/mt8189-afe-pcm.c
+++ b/sound/soc/mediatek/mt8189/mt8189-afe-pcm.c
@@ -2351,9 +2351,13 @@ static int mt8189_afe_runtime_resume(struct device *dev)
static int mt8189_afe_component_probe(struct snd_soc_component *component)
{
struct mtk_base_afe *afe = snd_soc_component_get_drvdata(component);
+ int ret;
/* enable clock for regcache get default value from hw */
- pm_runtime_get_sync(afe->dev);
+ ret = pm_runtime_resume_and_get(afe->dev);
+ if (ret)
+ return dev_err_probe(afe->dev, ret, "failed to resume device\n");
+
mtk_afe_add_sub_dai_control(component);
pm_runtime_put_sync(afe->dev);
@@ -2417,6 +2421,11 @@ static const struct reg_sequence mt8189_cg_patch[] = {
{ AUDIO_TOP_CON4, 0x361c },
};
+static void mt8189_afe_release_reserved_mem(void *data)
+{
+ of_reserved_mem_device_release(data);
+}
+
static int mt8189_afe_pcm_dev_probe(struct platform_device *pdev)
{
int ret, i;
@@ -2431,8 +2440,15 @@ static int mt8189_afe_pcm_dev_probe(struct platform_device *pdev)
return ret;
ret = of_reserved_mem_device_init(dev);
- if (ret)
+ if (ret) {
dev_warn(dev, "failed to assign memory region: %d\n", ret);
+ } else {
+ ret = devm_add_action_or_reset(dev,
+ mt8189_afe_release_reserved_mem,
+ dev);
+ if (ret)
+ return ret;
+ }
afe = devm_kzalloc(dev, sizeof(*afe), GFP_KERNEL);
if (!afe)
@@ -2533,18 +2549,22 @@ static int mt8189_afe_pcm_dev_probe(struct platform_device *pdev)
dev_pm_syscore_device(dev, true);
/* enable clock for regcache get default value from hw */
- pm_runtime_get_sync(dev);
+ ret = pm_runtime_resume_and_get(dev);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to resume device\n");
afe->regmap = devm_regmap_init_mmio(dev, afe->base_addr,
&mt8189_afe_regmap_config);
- if (IS_ERR(afe->regmap))
- return PTR_ERR(afe->regmap);
+ if (IS_ERR(afe->regmap)) {
+ ret = PTR_ERR(afe->regmap);
+ goto err_pm_put;
+ }
ret = regmap_register_patch(afe->regmap, mt8189_cg_patch,
ARRAY_SIZE(mt8189_cg_patch));
if (ret < 0) {
dev_err(dev, "Failed to apply cg patch\n");
- goto err_pm_disable;
+ goto err_pm_put;
}
regmap_read(afe->regmap, AFE_IRQ_MCU_EN, &tmp_reg);
@@ -2563,12 +2583,12 @@ static int mt8189_afe_pcm_dev_probe(struct platform_device *pdev)
afe->num_dai_drivers);
if (ret) {
dev_err(dev, "afe component err: %d\n", ret);
- goto err_pm_disable;
+ return ret;
}
return 0;
-err_pm_disable:
+err_pm_put:
pm_runtime_put_sync(dev);
return ret;
}
@@ -2578,14 +2598,12 @@ static void mt8189_afe_pcm_dev_remove(struct platform_device *pdev)
struct mtk_base_afe *afe = platform_get_drvdata(pdev);
struct device *dev = &pdev->dev;
- pm_runtime_put_sync(dev);
if (!pm_runtime_status_suspended(dev))
mt8189_afe_runtime_suspend(dev);
mt8189_afe_disable_main_clock(afe);
/* disable afe clock */
mt8189_afe_disable_reg_rw_clk(afe);
- of_reserved_mem_device_release(dev);
}
static const struct of_device_id mt8189_afe_pcm_dt_match[] = {
---
base-commit: eeecc92a9f1dd213dd52d9b8f42d155595b1d278
change-id: 20260512-asoc-mt8189-probe-cleanup-57d911861f86
Best regards,
--
Cássio Gabriel <cassiogabrielcontato@gmail.com>
^ permalink raw reply related
* Re: [PATCH v2 02/16] dt-bindings: iio: adc: mt6359: add mt6323 PMIC AUXADC
From: Krzysztof Kozlowski @ 2026-05-14 13:20 UTC (permalink / raw)
To: Roman Vivchar
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sen Chu, Sean Wang, Macpaul Lin,
Lee Jones, Srinivas Kandagatla, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, linux-iio, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-pm, Ben Grisdale
In-Reply-To: <20260512-mt6323-v2-2-3efcba579e88@protonmail.com>
On Tue, May 12, 2026 at 08:18:16AM +0300, Roman Vivchar wrote:
> The MediaTek mt6323 PMIC includes an AUXADC used for battery voltage,
> temperature, and other internal measurements.
>
> Add the devicetree binding documentation and the associated header file
> defining the ADC channel constants.
>
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> .../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 1 +
> .../dt-bindings/iio/adc/mediatek,mt6323-auxadc.h | 24 ++++++++++++++++++++++
> 2 files changed, 25 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 15/16] MAINTAINERS: add MediaTek mt6323 PMIC EFUSE driver maintainer
From: Krzysztof Kozlowski @ 2026-05-14 13:05 UTC (permalink / raw)
To: Roman Vivchar
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sen Chu, Sean Wang, Macpaul Lin,
Lee Jones, Srinivas Kandagatla, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, linux-iio, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-pm, Ben Grisdale
In-Reply-To: <20260514-spiritual-grouse-of-abracadabra-d91bc9@quoll>
On 14/05/2026 15:04, Krzysztof Kozlowski wrote:
> On Tue, May 12, 2026 at 08:18:29AM +0300, Roman Vivchar wrote:
>> Add myself as MediaTek mt6323 EFUSE driver maintainer.
>>
>> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
>> ---
>> MAINTAINERS | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 52249c301633..bf2e066f377d 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -16342,6 +16342,11 @@ M: Roman Vivchar <rva333@protonmail.com>
>> S: Odd Fixes
>> F: drivers/iio/adc/mt6323-auxadc.c
>>
>> +MEDIATEK PMIC EFUSE DRIVER
>> +M: Roman Vivchar <rva333@protonmail.com>
>> +S: Odd Fixes
>> +F: drivers/nvmem/mt6323-efuse.c
>
> I don't understand why this cannot be one maintainer entry.
> Really, these are just single drivers.
Heh, and now I see my comment on v1 which you did not implement.
SQUASHED. Please see git rebase and the meaning of squash.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 15/16] MAINTAINERS: add MediaTek mt6323 PMIC EFUSE driver maintainer
From: Krzysztof Kozlowski @ 2026-05-14 13:04 UTC (permalink / raw)
To: Roman Vivchar
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sen Chu, Sean Wang, Macpaul Lin,
Lee Jones, Srinivas Kandagatla, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, linux-iio, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-pm, Ben Grisdale
In-Reply-To: <20260512-mt6323-v2-15-3efcba579e88@protonmail.com>
On Tue, May 12, 2026 at 08:18:29AM +0300, Roman Vivchar wrote:
> Add myself as MediaTek mt6323 EFUSE driver maintainer.
>
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> MAINTAINERS | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 52249c301633..bf2e066f377d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16342,6 +16342,11 @@ M: Roman Vivchar <rva333@protonmail.com>
> S: Odd Fixes
> F: drivers/iio/adc/mt6323-auxadc.c
>
> +MEDIATEK PMIC EFUSE DRIVER
> +M: Roman Vivchar <rva333@protonmail.com>
> +S: Odd Fixes
> +F: drivers/nvmem/mt6323-efuse.c
I don't understand why this cannot be one maintainer entry.
Really, these are just single drivers.
> +
> MEDIATEK PMIC LED DRIVER
> M: Sen Chu <sen.chu@mediatek.com>
> M: Sean Wang <sean.wang@mediatek.com>
>
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v2 16/16] MAINTAINERS: add MediaTek mt6323 PMIC thermal driver maintainer
From: Krzysztof Kozlowski @ 2026-05-14 13:03 UTC (permalink / raw)
To: Roman Vivchar
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sen Chu, Sean Wang, Macpaul Lin,
Lee Jones, Srinivas Kandagatla, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, linux-iio, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-pm, Ben Grisdale
In-Reply-To: <20260512-mt6323-v2-16-3efcba579e88@protonmail.com>
On Tue, May 12, 2026 at 08:18:30AM +0300, Roman Vivchar wrote:
> Add myself as MediaTek mt6323 thermal driver maintainer.
>
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> MAINTAINERS | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bf2e066f377d..3001a713b083 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16355,6 +16355,11 @@ S: Maintained
> F: Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> F: drivers/leds/leds-mt6323.c
>
> +MEDIATEK PMIC THERMAL DRIVER
> +M: Roman Vivchar <rva333@protonmail.com>
> +S: Odd Fixes
Odd Fixes means driver is half-abandonded, so please explain in the
commit msg why you add yourself as maintainer but not really committed.
Such entry makes more sense for subsystems, but if individual driver has
odd-fixes stage, shouldn't we just remove this maintainer entry? If so,
why adding it in the first place?
> +F: drivers/thermal/mediatek/mtk_pmic_thermal.c
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 01/16] dt-bindings: iio: adc: mt6359: generalize description for mt63xx series
From: Krzysztof Kozlowski @ 2026-05-14 12:57 UTC (permalink / raw)
To: Roman Vivchar
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sen Chu, Sean Wang, Macpaul Lin,
Lee Jones, Srinivas Kandagatla, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, linux-iio, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-pm, Ben Grisdale
In-Reply-To: <20260512-mt6323-v2-1-3efcba579e88@protonmail.com>
On Tue, May 12, 2026 at 08:18:15AM +0300, Roman Vivchar wrote:
> Update binding title to the MT63xx, since the list of compatibles already
> includes mt6363 and mt6373 which don't belong to the mt6350 family.
>
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
> index 5d4ab701f51a..2e8857e104f5 100644
> --- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
> @@ -4,7 +4,7 @@
> $id: http://devicetree.org/schemas/iio/adc/mediatek,mt6359-auxadc.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: MediaTek MT6350 series PMIC AUXADC
> +title: MediaTek MT63xx series PMIC AUXADC
Honestly that's close to churn... Do it while adding new compatibles.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 8/8] PCI: rzg3s-host: Add 100 ms delay after link training
From: kernel test robot @ 2026-05-14 12:50 UTC (permalink / raw)
To: Hans Zhang, bhelgaas, lpieralisi, kwilczynski, mani, vigneshr,
jingoohan1, thomas.petazzoni, pali, ryder.lee, jianjun.wang,
claudiu.beznea.uj, mpillai
Cc: oe-kbuild-all, robh, s-vadapalli, linux-omap, linux-arm-kernel,
linux-mediatek, linux-renesas-soc, linux-pci, linux-kernel,
Hans Zhang
In-Reply-To: <20260506152346.166056-9-18255117159@163.com>
Hi Hans,
kernel test robot noticed the following build warnings:
[auto build test WARNING on a293ec25d59dd96309058c70df5a4dd0f889a1e4]
url: https://github.com/intel-lab-lkp/linux/commits/Hans-Zhang/PCI-Add-pcie_wait_after_link_train-helper/20260514-132815
base: a293ec25d59dd96309058c70df5a4dd0f889a1e4
patch link: https://lore.kernel.org/r/20260506152346.166056-9-18255117159%40163.com
patch subject: [PATCH v2 8/8] PCI: rzg3s-host: Add 100 ms delay after link training
config: x86_64-rhel-9.4 (https://download.01.org/0day-ci/archive/20260514/202605141445.2Ag4i8fZ-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260514/202605141445.2Ag4i8fZ-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605141445.2Ag4i8fZ-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from drivers/pci/hotplug/pciehp_ctrl.c:24:
drivers/pci/hotplug/../pci.h: In function 'pcie_wait_after_link_train':
drivers/pci/hotplug/../pci.h:73:17: error: implicit declaration of function 'msleep' [-Wimplicit-function-declaration]
73 | msleep(PCIE_RESET_CONFIG_WAIT_MS);
| ^~~~~~
In file included from drivers/pci/hotplug/pciehp.h:21,
from drivers/pci/hotplug/pciehp_ctrl.c:25:
include/linux/delay.h: At top level:
>> include/linux/delay.h:61:6: warning: conflicting types for 'msleep'; have 'void(unsigned int)'
61 | void msleep(unsigned int msecs);
| ^~~~~~
drivers/pci/hotplug/../pci.h:73:17: note: previous implicit declaration of 'msleep' with type 'void(unsigned int)'
73 | msleep(PCIE_RESET_CONFIG_WAIT_MS);
| ^~~~~~
vim +61 include/linux/delay.h
^1da177e4c3f41 Linus Torvalds 2005-04-16 56
f3f3149f35b919 Alok Kataria 2008-06-23 57 extern unsigned long lpj_fine;
^1da177e4c3f41 Linus Torvalds 2005-04-16 58 void calibrate_delay(void);
ad1a48301f659a Arnd Bergmann 2023-05-17 59 unsigned long calibrate_delay_is_known(void);
8496ecd0bed4c7 Valdis Kletnieks 2019-03-07 60 void __attribute__((weak)) calibration_delay_done(void);
^1da177e4c3f41 Linus Torvalds 2005-04-16 @61 void msleep(unsigned int msecs);
^1da177e4c3f41 Linus Torvalds 2005-04-16 62 unsigned long msleep_interruptible(unsigned int msecs);
e4779015fd5d2f SeongJae Park 2021-12-10 63 void usleep_range_state(unsigned long min, unsigned long max,
e4779015fd5d2f SeongJae Park 2021-12-10 64 unsigned int state);
e4779015fd5d2f SeongJae Park 2021-12-10 65
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 1/1] dt-bindings: remoteproc: mtk,scp: Allow multiple memory regions for MT8188
From: Krzysztof Kozlowski @ 2026-05-14 12:32 UTC (permalink / raw)
To: Arnab Layek
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek, robh,
krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
andersson, mathieu.poirier, linux-remoteproc,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20260514-poised-green-beagle-79cb9c@quoll>
On 14/05/2026 14:30, Krzysztof Kozlowski wrote:
> On Thu, May 14, 2026 at 07:45:33PM +0800, Arnab Layek wrote:
>> The MT8188 SCP requires support for 1-2 reserved memory regions, while
>> other MediaTek SoCs use only a single memory region.
>>
>> The schema uses a permissive base with restrictive conditionals:
>> 1) Base schema allows all devices minItems: 1, maxItems: 2
>> 2) Non-MT8188 devices (mt8183, mt8186, mt8192, mt8195, mt8195-dual) are
>> restricted to maxItems: 1, overriding the base
>> 3) MT8188 devices (mt8188, mt8188-dual) set minItems: 1 with item
>> descriptions, inheriting maxItems: 2 from base, making the second
>> L1TCM region optional
>>
>> This follows the same pattern as other MediaTek dt-bindings such as
>> mediatek,jpeg-encoder.yaml which uses conditional schemas to support
>> different numbers of iommus per device variant.
>>
>
> So I just reviewed v2, because it appeared in patchwork thread...
> because you just threaded v3 there.
>
> No, really, this was repeated also to Mediatek so many times.
>
> Implement v2 review.
>
Heh, and now I noticed that you just merged THREE versions in one thread
leading to complete mess in this entire thread.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/1] dt-bindings: remoteproc: mtk,scp: Allow multiple memory regions for MT8188
From: Krzysztof Kozlowski @ 2026-05-14 12:30 UTC (permalink / raw)
To: Arnab Layek
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek, robh,
krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
andersson, mathieu.poirier, linux-remoteproc,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20260514114533.174008-2-arnab.layek@mediatek.com>
On Thu, May 14, 2026 at 07:45:33PM +0800, Arnab Layek wrote:
> The MT8188 SCP requires support for 1-2 reserved memory regions, while
> other MediaTek SoCs use only a single memory region.
>
> The schema uses a permissive base with restrictive conditionals:
> 1) Base schema allows all devices minItems: 1, maxItems: 2
> 2) Non-MT8188 devices (mt8183, mt8186, mt8192, mt8195, mt8195-dual) are
> restricted to maxItems: 1, overriding the base
> 3) MT8188 devices (mt8188, mt8188-dual) set minItems: 1 with item
> descriptions, inheriting maxItems: 2 from base, making the second
> L1TCM region optional
>
> This follows the same pattern as other MediaTek dt-bindings such as
> mediatek,jpeg-encoder.yaml which uses conditional schemas to support
> different numbers of iommus per device variant.
>
So I just reviewed v2, because it appeared in patchwork thread...
because you just threaded v3 there.
No, really, this was repeated also to Mediatek so many times.
Implement v2 review.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/1] dt-bindings: remoteproc: mtk,scp: Allow multiple memory regions for MT8188
From: Krzysztof Kozlowski @ 2026-05-14 12:29 UTC (permalink / raw)
To: Arnab Layek
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-remoteproc, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20260511121004.2984149-2-arnab.layek@mediatek.com>
On Mon, May 11, 2026 at 08:10:04PM +0800, Arnab Layek wrote:
> The MT8188 SCP requires two reserved memory regions:
> 1. Main SCP SRAM memory region (required)
> 2. SCP L1TCM memory region (optional, for additional memory)
>
> Some other MediaTek SoCs only use a single memory region. This patch adds
Please do not use "This commit/patch/change", but imperative mood. See
longer explanation here:
https://elixir.bootlin.com/linux/v6.16/source/Documentation/process/submitting-patches.rst#L94
> a conditional schema using if/then to allow 1-2 memory regions
> specifically for mediatek,mt8188-scp and mediatek,mt8188-scp-dual
> compatibles, while keeping the default maxItems: 1 for other
> SoCs.
Stop explaining what you did. Explain WHY. Why second entry is optional?
Why are you changing existing binding? Was it working? Not? Why not? Why
yes?
>
> Each memory region is documented with descriptions to
> clarify their purpose, following the pattern used in other bindings.
Redundant. We can read the diff.
>
> Signed-off-by: Arnab Layek <arnab.layek@mediatek.com>
> ---
> .../bindings/remoteproc/mtk,scp.yaml | 21 +++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> index bdbb12118da4..df13be2026a6 100644
> --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> @@ -205,6 +205,27 @@ allOf:
> items:
> - const: cfg
> - const: l1tcm
> + - if:
> + properties:
> + compatible:
> + enum:
> + - mediatek,mt8188-scp
> + - mediatek,mt8188-scp-dual
> + then:
> + properties:
> + memory-region:
> + minItems: 1
> + items:
> + - description: Main SCP SRAM memory region
> + - description: Optional SCP L1TCM memory region
Conflicts top level.
> + patternProperties:
> + "^scp@[a-f0-9]+$":
> + properties:
> + memory-region:
> + minItems: 1
> + items:
> + - description: Main SCP SRAM memory region
> + - description: Optional SCP L1TCM memory region
>
> additionalProperties: false
>
> --
> 2.45.2
>
^ permalink raw reply
* Re: [PATCH v2 8/8] PCI: rzg3s-host: Add 100 ms delay after link training
From: kernel test robot @ 2026-05-14 12:19 UTC (permalink / raw)
To: Hans Zhang, bhelgaas, lpieralisi, kwilczynski, mani, vigneshr,
jingoohan1, thomas.petazzoni, pali, ryder.lee, jianjun.wang,
claudiu.beznea.uj, mpillai
Cc: llvm, oe-kbuild-all, robh, s-vadapalli, linux-omap,
linux-arm-kernel, linux-mediatek, linux-renesas-soc, linux-pci,
linux-kernel, Hans Zhang
In-Reply-To: <20260506152346.166056-9-18255117159@163.com>
Hi Hans,
kernel test robot noticed the following build errors:
[auto build test ERROR on a293ec25d59dd96309058c70df5a4dd0f889a1e4]
url: https://github.com/intel-lab-lkp/linux/commits/Hans-Zhang/PCI-Add-pcie_wait_after_link_train-helper/20260514-132815
base: a293ec25d59dd96309058c70df5a4dd0f889a1e4
patch link: https://lore.kernel.org/r/20260506152346.166056-9-18255117159%40163.com
patch subject: [PATCH v2 8/8] PCI: rzg3s-host: Add 100 ms delay after link training
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260514/202605141426.2RPW8nvf-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260514/202605141426.2RPW8nvf-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605141426.2RPW8nvf-lkp@intel.com/
All error/warnings (new ones prefixed by >>):
In file included from drivers/pci/access.c:8:
>> drivers/pci/pci.h:73:3: error: call to undeclared function 'msleep'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
73 | msleep(PCIE_RESET_CONFIG_WAIT_MS);
| ^
1 error generated.
--
In file included from drivers/pci/rebar.c:17:
>> drivers/pci/pci.h:73:3: error: call to undeclared function 'msleep'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
73 | msleep(PCIE_RESET_CONFIG_WAIT_MS);
| ^
>> drivers/pci/rebar.c:142:31: warning: implicit conversion from 'unsigned long long' to 'u32' (aka 'unsigned int') changes value from 140737488355328 to 0 [-Wconstant-conversion]
142 | if (size < 0 || size > ilog2(SZ_128T) - ilog2(PCI_REBAR_MIN_SIZE))
| ~~~~~~^~~~~~~~
include/linux/sizes.h:70:20: note: expanded from macro 'SZ_128T'
70 | #define SZ_128T _AC(0x800000000000, ULL)
| ^~~~~~~~~~~~~~~~~~~~~~~~
include/uapi/linux/const.h:21:18: note: expanded from macro '_AC'
21 | #define _AC(X,Y) __AC(X,Y)
| ^~~~~~~~~
include/uapi/linux/const.h:20:20: note: expanded from macro '__AC'
20 | #define __AC(X,Y) (X##Y)
| ^~~~
<scratch space>:37:1: note: expanded from here
37 | 0x800000000000ULL
| ^~~~~~~~~~~~~~~~~
include/linux/log2.h:162:14: note: expanded from macro 'ilog2'
162 | __ilog2_u32(n) : \
| ~~~~~~~~~~~ ^
1 warning and 1 error generated.
--
In file included from drivers/pci/msi/pcidev_msi.c:5:
>> drivers/pci/msi/../pci.h:73:3: error: call to undeclared function 'msleep'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
73 | msleep(PCIE_RESET_CONFIG_WAIT_MS);
| ^
1 error generated.
--
In file included from drivers/pci/pcie/portdrv.c:22:
>> drivers/pci/pcie/../pci.h:73:3: error: call to undeclared function 'msleep'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
73 | msleep(PCIE_RESET_CONFIG_WAIT_MS);
| ^
1 error generated.
vim +/msleep +73 drivers/pci/pci.h
62
63 /**
64 * pcie_wait_after_link_train - Wait 100 ms if link speed > 5 GT/s
65 * @max_link_speed: the maximum link speed (2 = 5.0 GT/s, 3 = 8.0 GT/s, ...)
66 *
67 * Must be called after Link training completes and before the first
68 * Configuration Request is sent.
69 */
70 static inline void pcie_wait_after_link_train(int max_link_speed)
71 {
72 if (max_link_speed > 2)
> 73 msleep(PCIE_RESET_CONFIG_WAIT_MS);
74 }
75
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v3 1/1] dt-bindings: remoteproc: mtk,scp: Allow multiple memory regions for MT8188
From: Arnab Layek @ 2026-05-14 11:45 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
Cc: arnab.layek, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, andersson, mathieu.poirier,
linux-remoteproc, Project_Global_Chrome_Upstream_Group
In-Reply-To: <20260514114533.174008-1-arnab.layek@mediatek.com>
The MT8188 SCP requires support for 1-2 reserved memory regions, while
other MediaTek SoCs use only a single memory region.
The schema uses a permissive base with restrictive conditionals:
1) Base schema allows all devices minItems: 1, maxItems: 2
2) Non-MT8188 devices (mt8183, mt8186, mt8192, mt8195, mt8195-dual) are
restricted to maxItems: 1, overriding the base
3) MT8188 devices (mt8188, mt8188-dual) set minItems: 1 with item
descriptions, inheriting maxItems: 2 from base, making the second
L1TCM region optional
This follows the same pattern as other MediaTek dt-bindings such as
mediatek,jpeg-encoder.yaml which uses conditional schemas to support
different numbers of iommus per device variant.
Signed-off-by: Arnab Layek <arnab.layek@mediatek.com>
---
.../bindings/remoteproc/mtk,scp.yaml | 45 ++++++++++++++++++-
1 file changed, 43 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
index bdbb12118da4..fca9b0675eae 100644
--- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
@@ -55,7 +55,8 @@ properties:
initializing SCP.
memory-region:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
cros-ec-rpmsg:
$ref: /schemas/embedded-controller/google,cros-ec.yaml
@@ -123,7 +124,8 @@ patternProperties:
initializing sub cores of multi-core SCP.
memory-region:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
cros-ec-rpmsg:
$ref: /schemas/embedded-controller/google,cros-ec.yaml
@@ -205,6 +207,45 @@ allOf:
items:
- const: cfg
- const: l1tcm
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt8183-scp
+ - mediatek,mt8186-scp
+ - mediatek,mt8192-scp
+ - mediatek,mt8195-scp
+ - mediatek,mt8195-scp-dual
+ then:
+ properties:
+ memory-region:
+ maxItems: 1
+ patternProperties:
+ "^scp@[a-f0-9]+$":
+ properties:
+ memory-region:
+ maxItems: 1
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt8188-scp
+ - mediatek,mt8188-scp-dual
+ then:
+ properties:
+ memory-region:
+ minItems: 1
+ items:
+ - description: Main SCP SRAM memory region
+ - description: Optional SCP L1TCM memory region
+ patternProperties:
+ "^scp@[a-f0-9]+$":
+ properties:
+ memory-region:
+ minItems: 1
+ items:
+ - description: Main SCP SRAM memory region
+ - description: Optional SCP L1TCM memory region
additionalProperties: false
--
2.45.2
^ permalink raw reply related
* Re: [PATCH] dt-bindings: PCI: mediatek-gen3: Allow memory-region for restricted DMA buffer
From: Manivannan Sadhasivam @ 2026-05-14 11:48 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Ryder Lee,
Lorenzo Pieralisi, Krzysztof Wilczyński, Rob Herring,
Bjorn Helgaas, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-pci, linux-mediatek, linux-kernel
In-Reply-To: <CAGXv+5GAaMQbaoUVr5zcwtHaofyXwHz03TxBe-QyWj_sNoQZsg@mail.gmail.com>
On Thu, May 14, 2026 at 03:54:29PM +0800, Chen-Yu Tsai wrote:
> On Thu, May 14, 2026 at 1:23 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
> >
> > On Fri, May 08, 2026 at 02:36:32PM +0800, Chen-Yu Tsai wrote:
> > > On some SoCs without an IOMMU behind the PCIe controller, the PCIe
> > > controller memory access could be limited to a small region by the
> > > firmware configuring a memory protection unit. This memory region
> > > must be assigned to the PCIe controller so that the OS knows to
> > > use that region. Otherwise PCIe devices would not work properly.
> > >
> >
> > So this means, the PCIe devices can only access a specific carveout memory
> > configured by MPU for DMA? If so, you should use 'dma-ranges' as suggested by
> > Rob.
> >
> > 'memory-region' also serves the purpose, but for PCI, we have the dedicated
> > 'dma-ranges' property.
>
> I think I need some sort of guide on writing the 'dma-ranges' property,
> because it is not working for me.
>
> I'm adding
>
> dma-ranges = <0x42000000 0 0x00000000 0 0xc0000000 0 0x4000000>;
>
So the device DMA address start from 0x0? Isn't it a 1:1 mapping?
dma-ranges = <0x42000000 0 0xc0000000 0 0xc0000000 0 0x4000000>;
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* [PATCH v3 0/1] dt-bindings: remoteproc: mtk,scp: Allow multiple memory regions for MT8188
From: Arnab Layek @ 2026-05-14 11:45 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
Cc: arnab.layek, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, andersson, mathieu.poirier,
linux-remoteproc, Project_Global_Chrome_Upstream_Group
In-Reply-To: <20260506133157.3283204-1-arnab.layek@mediatek.com>
This series updates the mtk,scp dt-binding schema to support MT8188's
requirement for two memory regions while maintaining backward
compatibility for other MediaTek SoCs.
The schema uses a permissive base with restrictive conditionals:
1) Base schema allows all devices minItems: 1, maxItems: 2
2) Non-MT8188 devices (mt8183, mt8186, mt8192, mt8195, mt8195-dual) are
restricted to maxItems: 1, overriding the base
3) MT8188 devices (mt8188, mt8188-dual) set minItems: 1 with item
descriptions, inheriting maxItems: 2 from base, making the second
L1TCM region optional
Changes in v3:
- Removed "Tested on..." line per Krzysztof's feedback (bindings cannot be tested)
- Added minItems: 1 to MT8188 conditional to make L1TCM region truly optional
- Clarified commit message to specifically reference mediatek,jpeg-encoder.yaml pattern
- Restructured schema per Conor's feedback: base allows maxItems: 2, conditionals restrict
- Added explicit restrictions for non-MT8188 devices (maxItems: 1)
- Added technical explanation of the permissive base + restrictive conditionals pattern
Changes in v2:
- Added conditional schema for MT8188 to allow 1-2 memory regions
- Added descriptions for each memory region
- Did not work: base maxItems: 1 conflicted with conditional trying to allow 2
Arnab Layek (1):
dt-bindings: remoteproc: mtk,scp: Allow multiple memory regions for
MT8188
.../bindings/remoteproc/mtk,scp.yaml | 45 ++++++++++++++++++-
1 file changed, 43 insertions(+), 2 deletions(-)
--
2.45.2
^ permalink raw reply
* [PATCH 3/4] arm64: dts: mediatek: mt8195-cherry: Fix names for EC controlled regulators
From: Chen-Yu Tsai @ 2026-05-14 10:12 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-mediatek, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260514101254.2749300-1-wenst@chromium.org>
The names currently given to the EC controlled regulators do not match
what is used in the hardware design.
Fix the names and the labels.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index ca2bb367ee68..538c46ada32b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -717,8 +717,8 @@ &mmc1 {
pinctrl-1 = <&mmc1_pins_default>;
sd-uhs-sdr50;
sd-uhs-sdr104;
- vmmc-supply = <&mt_pmic_vmch_ldo_reg>;
- vqmmc-supply = <&mt_pmic_vmc_ldo_reg>;
+ vmmc-supply = <&pp3000_sd>;
+ vqmmc-supply = <&pp3000_vmc_pmu>;
};
&mt6359codec {
@@ -1436,19 +1436,19 @@ i2c_tunnel: i2c-tunnel {
#size-cells = <0>;
};
- mt_pmic_vmc_ldo_reg: regulator@0 {
+ pp3000_vmc_pmu: regulator@0 {
compatible = "google,cros-ec-regulator";
reg = <0>;
- regulator-name = "mt_pmic_vmc_ldo";
+ regulator-name = "pp3000_vmc_pmu";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3600000>;
vin-supply = <&pp4200_z2>;
};
- mt_pmic_vmch_ldo_reg: regulator@1 {
+ pp3000_sd: regulator@1 {
compatible = "google,cros-ec-regulator";
reg = <1>;
- regulator-name = "mt_pmic_vmch_ldo";
+ regulator-name = "pp3000_sd";
regulator-min-microvolt = <2700000>;
regulator-max-microvolt = <3600000>;
vin-supply = <&pp4200_z2>;
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: mediatek: mt8195-cherry: Sort top level nodes correctly
From: Chen-Yu Tsai @ 2026-05-14 10:12 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-mediatek, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260514101254.2749300-1-wenst@chromium.org>
The thermistor device nodes were added before the vbus regulator and
reserved memory nodes, when they should be after them, based on
alphabetical order of the device node _name_.
Move them to the correct position. No functional changes intended.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
.../boot/dts/mediatek/mt8195-cherry.dtsi | 94 +++++++++----------
1 file changed, 47 insertions(+), 47 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index 538c46ada32b..ef7afc436aef 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -149,6 +149,53 @@ ppvar_sys: regulator-ppvar-sys {
regulator-boot-on;
};
+ usb_vbus: regulator-5v0-usb-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb-vbus";
+ enable-active-high;
+ regulator-always-on;
+ vin-supply = <&pp5000_s5>;
+ };
+
+ reserved_memory: reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ scp_mem: memory@50000000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x50000000 0 0x2900000>;
+ no-map;
+ };
+
+ adsp_mem: memory@60000000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x60000000 0 0xd80000>;
+ no-map;
+ };
+
+ afe_mem: memory@60d80000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x60d80000 0 0x100000>;
+ no-map;
+ };
+
+ adsp_device_mem: memory@60e80000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x60e80000 0 0x280000>;
+ no-map;
+ };
+ };
+
+ spk_amplifier: rt1019p {
+ compatible = "realtek,rt1019p";
+ label = "rt1019p";
+ #sound-dai-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rt1019p_pins_default>;
+ sdb-gpios = <&pio 100 GPIO_ACTIVE_HIGH>;
+ };
+
/* Murata NCP03WF104F05RL */
tboard_thermistor1: thermal-sensor-t1 {
compatible = "generic-adc-thermal";
@@ -219,53 +266,6 @@ tboard_thermistor2: thermal-sensor-t2 {
120000 51
125000 44>;
};
-
- usb_vbus: regulator-5v0-usb-vbus {
- compatible = "regulator-fixed";
- regulator-name = "usb-vbus";
- enable-active-high;
- regulator-always-on;
- vin-supply = <&pp5000_s5>;
- };
-
- reserved_memory: reserved-memory {
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
-
- scp_mem: memory@50000000 {
- compatible = "shared-dma-pool";
- reg = <0 0x50000000 0 0x2900000>;
- no-map;
- };
-
- adsp_mem: memory@60000000 {
- compatible = "shared-dma-pool";
- reg = <0 0x60000000 0 0xd80000>;
- no-map;
- };
-
- afe_mem: memory@60d80000 {
- compatible = "shared-dma-pool";
- reg = <0 0x60d80000 0 0x100000>;
- no-map;
- };
-
- adsp_device_mem: memory@60e80000 {
- compatible = "shared-dma-pool";
- reg = <0 0x60e80000 0 0x280000>;
- no-map;
- };
- };
-
- spk_amplifier: rt1019p {
- compatible = "realtek,rt1019p";
- label = "rt1019p";
- #sound-dai-cells = <0>;
- pinctrl-names = "default";
- pinctrl-0 = <&rt1019p_pins_default>;
- sdb-gpios = <&pio 100 GPIO_ACTIVE_HIGH>;
- };
};
&adsp {
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH 2/4] arm64: dts: mediatek: mt8192-asurada: Add (BT|WIFI)_KILL_1V8_L GPIO line names
From: Chen-Yu Tsai @ 2026-05-14 10:12 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-mediatek, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260514101254.2749300-1-wenst@chromium.org>
GPIO lines 59 and 61 are named BT_KILL_1V8_L and WIFI_KILL_1V8_L in the
hardware design. Add them to the gpio-line-names property to make the
names available to users and developers.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
index 3c8b4c2f6f23..b7387075cb87 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
@@ -727,9 +727,9 @@ &pio {
"SD_DATA1",
"",
"",
+ "BT_KILL_1V8_L",
"",
- "",
- "",
+ "WIFI_KILL_1V8_L",
"",
"PCIE_WAKE_ODL",
"PCIE_RST_L",
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH 1/4] arm64: dts: mediatek: mt8192-asurada: Fix SPI-NOR flash compatible
From: Chen-Yu Tsai @ 2026-05-14 10:12 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-mediatek, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260514101254.2749300-1-wenst@chromium.org>
For JEDEC compatible SPI NOR chips, there should be a single generic
"jedec,spi-nor" compatible.
Drop the model-specific compatible from the flash node.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
index 84b89b317890..3c8b4c2f6f23 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
@@ -631,7 +631,7 @@ &nor_flash {
assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D6_D8>;
flash@0 {
- compatible = "winbond,w25q64jwm", "jedec,spi-nor";
+ compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <52000000>;
spi-rx-bus-width = <2>;
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH 0/4] arm64: dts: mediatek: random Chromebook cleanups
From: Chen-Yu Tsai @ 2026-05-14 10:12 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-mediatek, devicetree, linux-arm-kernel,
linux-kernel
Hi,
Here are some random DT cleanups that are not directly related to other
topics I'm working on, but came up when checking for warnings.
The regulator related changes overlap with my other "Regulator cleanup
for Chromebooks" series [1].
Please have a look.
Thanks
ChenYu
[1] https://lore.kernel.org/all/20260505101408.1796563-1-wenst@chromium.org/
Chen-Yu Tsai (4):
arm64: dts: mediatek: mt8192-asurada: Fix SPI-NOR flash compatible
arm64: dts: mediatek: mt8192-asurada: Add (BT|WIFI)_KILL_1V8_L GPIO
line names
arm64: dts: mediatek: mt8195-cherry: Fix names for EC controlled
regulators
arm64: dts: mediatek: mt8195-cherry: Sort top level nodes correctly
.../boot/dts/mediatek/mt8192-asurada.dtsi | 6 +-
.../boot/dts/mediatek/mt8195-cherry.dtsi | 106 +++++++++---------
2 files changed, 56 insertions(+), 56 deletions(-)
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply
* [PATCH v4 6/6] regulator: mt6359: Add proper ldo_vcn33_[12] regulators
From: Chen-Yu Tsai @ 2026-05-14 9:15 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, devicetree
In-Reply-To: <20260514091520.2718987-1-wenst@chromium.org>
The ldo_vcn33_[12]_wifi and ldo_vcn33_[12]_bt are just two regulator
outputs instead of four. The wifi and bt parts refer to separate enable
bits that are OR-ed together to affect the actual regulator output. The
separate bits allow the wifi and bt stacks to enable their power without
coordination between them. These have been deprecated in favor of proper
nodes matching the output.
Add proper ldo_vcn33_[12] regulators to replace the existing ones. The
enable status is synced to just one of the two enable bits, and the
other is forced off. This makes the handling in other bits simpler.
The existing *_(bt|wifi) regulators are converted to no-op regulators
that are fed from their new respective ldo_vcn33_[12] regulator. This
allows existing device trees to continue to work.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v3:
- Fixed index off-by-one in error message in mt6359_sync_vcn33_setting()
(Sashiko)
- Added check of return value from mt6359_sync_vcn33_setting() (Sashiko)
Changes since v1:
- Instead of dropping one regulator from each output, add a new one for
each output; the existing *_(bt|wifi) ones are then supplied from the
new one
---
drivers/regulator/mt6359-regulator.c | 184 +++++++++++++++++----
include/linux/regulator/mt6359-regulator.h | 10 +-
2 files changed, 159 insertions(+), 35 deletions(-)
diff --git a/drivers/regulator/mt6359-regulator.c b/drivers/regulator/mt6359-regulator.c
index 46cafe93b24e..af0e0339fbdd 100644
--- a/drivers/regulator/mt6359-regulator.c
+++ b/drivers/regulator/mt6359-regulator.c
@@ -166,6 +166,20 @@ struct mt6359_regulator_info {
.qi = BIT(0), \
}
+#define MT6359_LDO_NOOP(match, _name, supply) \
+[MT6359_ID_##_name] = { \
+ .desc = { \
+ .name = #_name, \
+ .supply_name = supply, \
+ .of_match = of_match_ptr(match), \
+ .regulators_node = of_match_ptr("regulators"), \
+ .ops = &mt6359_noop_ops, \
+ .type = REGULATOR_VOLTAGE, \
+ .id = MT6359_ID_##_name, \
+ .owner = THIS_MODULE, \
+ }, \
+}
+
static const unsigned int vsim1_voltages[] = {
0, 0, 0, 1700000, 1800000, 0, 0, 0, 2700000, 0, 0, 3000000, 3100000,
};
@@ -475,6 +489,9 @@ static const struct regulator_ops mt6359p_vemc_ops = {
.get_status = mt6359_get_status,
};
+/* Used for backward-compatible placeholder regulators */
+static const struct regulator_ops mt6359_noop_ops = {};
+
/* The array is indexed by id(MT6359_ID_XXX) */
static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_BUCK("buck_vs1", VS1, "vsys-vs1", 800000, 2200000, 12500,
@@ -596,18 +613,12 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_DA_VCN13_B_EN_ADDR, MT6359_RG_VCN13_VOSEL_ADDR,
MT6359_RG_VCN13_VOSEL_MASK << MT6359_RG_VCN13_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, "vsys-ldo1", vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_1", VCN33_1, "vsys-ldo1", vcn33_voltages,
MT6359_RG_LDO_VCN33_1_EN_0_ADDR,
MT6359_RG_LDO_VCN33_1_EN_0_SHIFT,
MT6359_DA_VCN33_1_B_EN_ADDR, MT6359_RG_VCN33_1_VOSEL_ADDR,
MT6359_RG_VCN33_1_VOSEL_MASK <<
MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, "vsys-ldo1", vcn33_voltages,
- MT6359_RG_LDO_VCN33_1_EN_1_ADDR,
- MT6359_RG_LDO_VCN33_1_EN_1_SHIFT,
- MT6359_DA_VCN33_1_B_EN_ADDR, MT6359_RG_VCN33_1_VOSEL_ADDR,
- MT6359_RG_VCN33_1_VOSEL_MASK <<
- MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
MT6359_REG_FIXED("ldo_vaux18", VAUX18, "vsys-ldo2", MT6359_RG_LDO_VAUX18_EN_ADDR,
MT6359_DA_VAUX18_B_EN_ADDR, 1800000),
MT6359_LDO_LINEAR("ldo_vsram_others", VSRAM_OTHERS, "vs2-ldo1", 500000, 1293750,
@@ -644,18 +655,12 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_DA_VEMC_B_EN_ADDR, MT6359_RG_VEMC_VOSEL_ADDR,
MT6359_RG_VEMC_VOSEL_MASK << MT6359_RG_VEMC_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_2_bt", VCN33_2_BT, "vsys-ldo1", vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_2", VCN33_2, "vsys-ldo1", vcn33_voltages,
MT6359_RG_LDO_VCN33_2_EN_0_ADDR,
MT6359_RG_LDO_VCN33_2_EN_0_SHIFT,
MT6359_DA_VCN33_2_B_EN_ADDR, MT6359_RG_VCN33_2_VOSEL_ADDR,
MT6359_RG_VCN33_2_VOSEL_MASK <<
MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_2_wifi", VCN33_2_WIFI, "vsys-ldo1", vcn33_voltages,
- MT6359_RG_LDO_VCN33_2_EN_1_ADDR,
- MT6359_RG_LDO_VCN33_2_EN_1_SHIFT,
- MT6359_DA_VCN33_2_B_EN_ADDR, MT6359_RG_VCN33_2_VOSEL_ADDR,
- MT6359_RG_VCN33_2_VOSEL_MASK <<
- MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
MT6359_LDO("ldo_va12", VA12, "vs2-ldo2", va12_voltages,
MT6359_RG_LDO_VA12_EN_ADDR, MT6359_RG_LDO_VA12_EN_SHIFT,
MT6359_DA_VA12_B_EN_ADDR, MT6359_RG_VA12_VOSEL_ADDR,
@@ -711,6 +716,11 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_SHIFT),
+ /* Placeholders for DT backward compatibility */
+ MT6359_LDO_NOOP("ldo_vcn33_1_bt", VCN33_1_BT, "LDO_VCN33_1"),
+ MT6359_LDO_NOOP("ldo_vcn33_1_wifi", VCN33_1_WIFI, "LDO_VCN33_1"),
+ MT6359_LDO_NOOP("ldo_vcn33_2_bt", VCN33_2_BT, "LDO_VCN33_2"),
+ MT6359_LDO_NOOP("ldo_vcn33_2_wifi", VCN33_2_WIFI, "LDO_VCN33_2"),
};
static const struct mt6359_regulator_info mt6359p_regulators[] = {
@@ -835,18 +845,12 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359P_DA_VCN13_B_EN_ADDR, MT6359P_RG_VCN13_VOSEL_ADDR,
MT6359_RG_VCN13_VOSEL_MASK << MT6359_RG_VCN13_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, "vsys-ldo1", vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_1", VCN33_1, "vsys-ldo1", vcn33_voltages,
MT6359P_RG_LDO_VCN33_1_EN_0_ADDR,
MT6359_RG_LDO_VCN33_1_EN_0_SHIFT,
MT6359P_DA_VCN33_1_B_EN_ADDR, MT6359P_RG_VCN33_1_VOSEL_ADDR,
MT6359_RG_VCN33_1_VOSEL_MASK <<
MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, "vsys-ldo1", vcn33_voltages,
- MT6359P_RG_LDO_VCN33_1_EN_1_ADDR,
- MT6359P_RG_LDO_VCN33_1_EN_1_SHIFT,
- MT6359P_DA_VCN33_1_B_EN_ADDR, MT6359P_RG_VCN33_1_VOSEL_ADDR,
- MT6359_RG_VCN33_1_VOSEL_MASK <<
- MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
MT6359_REG_FIXED("ldo_vaux18", VAUX18, "vsys-ldo2", MT6359P_RG_LDO_VAUX18_EN_ADDR,
MT6359P_DA_VAUX18_B_EN_ADDR, 1800000),
MT6359_LDO_LINEAR("ldo_vsram_others", VSRAM_OTHERS, "vs2-ldo1", 500000, 1293750,
@@ -885,18 +889,12 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359P_RG_LDO_VEMC_VOSEL_0_ADDR,
MT6359P_RG_LDO_VEMC_VOSEL_0_MASK <<
MT6359P_RG_LDO_VEMC_VOSEL_0_SHIFT),
- MT6359_LDO("ldo_vcn33_2_bt", VCN33_2_BT, "vsys-ldo1", vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_2", VCN33_2, "vsys-ldo1", vcn33_voltages,
MT6359P_RG_LDO_VCN33_2_EN_0_ADDR,
MT6359P_RG_LDO_VCN33_2_EN_0_SHIFT,
MT6359P_DA_VCN33_2_B_EN_ADDR, MT6359P_RG_VCN33_2_VOSEL_ADDR,
MT6359_RG_VCN33_2_VOSEL_MASK <<
MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_2_wifi", VCN33_2_WIFI, "vsys-ldo1", vcn33_voltages,
- MT6359P_RG_LDO_VCN33_2_EN_1_ADDR,
- MT6359_RG_LDO_VCN33_2_EN_1_SHIFT,
- MT6359P_DA_VCN33_2_B_EN_ADDR, MT6359P_RG_VCN33_2_VOSEL_ADDR,
- MT6359_RG_VCN33_2_VOSEL_MASK <<
- MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
MT6359_LDO("ldo_va12", VA12, "vs2-ldo2", va12_voltages,
MT6359P_RG_LDO_VA12_EN_ADDR, MT6359P_RG_LDO_VA12_EN_SHIFT,
MT6359P_DA_VA12_B_EN_ADDR, MT6359P_RG_VA12_VOSEL_ADDR,
@@ -951,27 +949,119 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359P_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_SHIFT),
+ /* Placeholders for DT backward compatibility */
+ MT6359_LDO_NOOP("ldo_vcn33_1_bt", VCN33_1_BT, "LDO_VCN33_1"),
+ MT6359_LDO_NOOP("ldo_vcn33_1_wifi", VCN33_1_WIFI, "LDO_VCN33_1"),
+ MT6359_LDO_NOOP("ldo_vcn33_2_bt", VCN33_2_BT, "LDO_VCN33_2"),
+ MT6359_LDO_NOOP("ldo_vcn33_2_wifi", VCN33_2_WIFI, "LDO_VCN33_2"),
+};
+
+struct mt6359_vcn33_regs {
+ u32 wifi_en_reg;
+ u32 wifi_en_mask;
+ u32 bt_en_reg;
+ u32 bt_en_mask;
+};
+
+static const struct mt6359_vcn33_regs vcn33_regs[][2] = {
+ { /* MT6359 */
+ {
+ .wifi_en_reg = MT6359_RG_LDO_VCN33_1_EN_1_ADDR,
+ .wifi_en_mask = BIT(MT6359_RG_LDO_VCN33_1_EN_1_SHIFT),
+ .bt_en_reg = MT6359_RG_LDO_VCN33_1_EN_0_ADDR,
+ .bt_en_mask = BIT(MT6359_RG_LDO_VCN33_1_EN_0_SHIFT),
+ }, {
+ .wifi_en_reg = MT6359_RG_LDO_VCN33_2_EN_1_ADDR,
+ .wifi_en_mask = BIT(MT6359_RG_LDO_VCN33_2_EN_1_SHIFT),
+ .bt_en_reg = MT6359_RG_LDO_VCN33_2_EN_0_ADDR,
+ .bt_en_mask = BIT(MT6359_RG_LDO_VCN33_2_EN_0_SHIFT),
+ }
+ }, { /* MT6359P */
+ {
+ .wifi_en_reg = MT6359P_RG_LDO_VCN33_1_EN_1_ADDR,
+ .wifi_en_mask = BIT(MT6359P_RG_LDO_VCN33_1_EN_1_SHIFT),
+ .bt_en_reg = MT6359P_RG_LDO_VCN33_1_EN_0_ADDR,
+ .bt_en_mask = BIT(MT6359_RG_LDO_VCN33_1_EN_0_SHIFT),
+ }, {
+ .wifi_en_reg = MT6359P_RG_LDO_VCN33_2_EN_1_ADDR,
+ .wifi_en_mask = BIT(MT6359_RG_LDO_VCN33_2_EN_1_SHIFT),
+ .bt_en_reg = MT6359P_RG_LDO_VCN33_2_EN_0_ADDR,
+ .bt_en_mask = BIT(MT6359P_RG_LDO_VCN33_2_EN_0_SHIFT),
+ }
+ }
};
+static int mt6359_sync_vcn33_setting(struct device *dev, unsigned int idx)
+{
+ struct mt6397_chip *mt6397 = dev_get_drvdata(dev->parent);
+ unsigned int val;
+ int ret;
+
+ /*
+ * VCN33_[12]_WIFI and VCN33_[12]_BT are two separate enable bits for
+ * the same regulator. They share the same voltage setting and output
+ * pin. Instead of having two potentially conflicting regulators, just
+ * have one regulator. Sync the two enable bits and only use one in
+ * the regulator device.
+ */
+ for (unsigned int i = 0; i < ARRAY_SIZE(vcn33_regs[0]); i++) {
+ u32 bt_en_mask = vcn33_regs[idx][i].bt_en_mask;
+ u32 wifi_en_mask = vcn33_regs[idx][i].wifi_en_mask;
+
+ ret = regmap_read(mt6397->regmap, vcn33_regs[idx][i].wifi_en_reg, &val);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to read VCN33_%u_WIFI setting\n",
+ i + 1);
+
+ if (!(val & wifi_en_mask))
+ continue;
+
+ /* Sync VCN33_[12]_WIFI enable status to VCN33_[12]_BT */
+ ret = regmap_update_bits(mt6397->regmap, vcn33_regs[idx][i].bt_en_reg,
+ bt_en_mask, bt_en_mask);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to sync VCN33_%u_WIFI setting to VCN33_%u_BT\n",
+ i + 1, i + 1);
+
+ /* Disable VCN33_[12]_WIFI */
+ ret = regmap_update_bits(mt6397->regmap, vcn33_regs[idx][i].wifi_en_reg,
+ wifi_en_mask, 0);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to disable VCN33_%u_WIFI\n", i + 1);
+ }
+
+ return 0;
+}
+
static int mt6359_regulator_probe(struct platform_device *pdev)
{
struct mt6397_chip *mt6397 = dev_get_drvdata(pdev->dev.parent);
struct regulator_config config = {};
struct regulator_dev *rdev;
const struct mt6359_regulator_info *mt6359_info;
- const char *vio18_name;
+ const char *vio18_name, *vcn33_1_name, *vcn33_2_name;
int i, hw_ver, ret;
ret = regmap_read(mt6397->regmap, MT6359P_HWCID, &hw_ver);
if (ret)
return ret;
- if (hw_ver >= MT6359P_CHIP_VER)
+ if (hw_ver >= MT6359P_CHIP_VER) {
mt6359_info = mt6359p_regulators;
- else
+ ret = mt6359_sync_vcn33_setting(&pdev->dev, 1);
+ if (ret)
+ return ret;
+ } else {
mt6359_info = mt6359_regulators;
+ ret = mt6359_sync_vcn33_setting(&pdev->dev, 0);
+ if (ret)
+ return ret;
+ }
vio18_name = mt6359_info[MT6359_ID_VIO18].desc.name;
+ vcn33_1_name = mt6359_info[MT6359_ID_VCN33_1].desc.name;
+ vcn33_2_name = mt6359_info[MT6359_ID_VCN33_2].desc.name;
config.dev = mt6397->dev;
config.regmap = mt6397->regmap;
@@ -993,6 +1083,30 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
desc = _desc;
}
+ /* Use vcn33_1's actual name as supply_name for vcn33_1_(bt|wifi) */
+ if ((i == MT6359_ID_VCN33_1_BT || i == MT6359_ID_VCN33_1_WIFI) &&
+ strcmp(desc->supply_name, vcn33_1_name) != 0) {
+ _desc = devm_kzalloc(&pdev->dev, sizeof(*_desc), GFP_KERNEL);
+ if (!_desc)
+ return -ENOMEM;
+
+ memcpy(_desc, desc, sizeof(*_desc));
+ _desc->supply_name = vcn33_1_name;
+ desc = _desc;
+ }
+
+ /* Use vcn33_2's actual name as supply_name for vcn33_2_(bt|wifi) */
+ if ((i == MT6359_ID_VCN33_2_BT || i == MT6359_ID_VCN33_2_WIFI) &&
+ strcmp(desc->supply_name, vcn33_2_name) != 0) {
+ _desc = devm_kzalloc(&pdev->dev, sizeof(*_desc), GFP_KERNEL);
+ if (!_desc)
+ return -ENOMEM;
+
+ memcpy(_desc, desc, sizeof(*_desc));
+ _desc->supply_name = vcn33_2_name;
+ desc = _desc;
+ }
+
rdev = devm_regulator_register(&pdev->dev, desc, &config);
if (IS_ERR(rdev)) {
dev_err(&pdev->dev, "failed to register %s\n", mt6359_info->desc.name);
@@ -1002,6 +1116,14 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
/* Save vio18 name for vbbck */
if (i == MT6359_ID_VIO18)
vio18_name = rdev_get_name(rdev);
+
+ /* Save vcn33_1 name for vbbck */
+ if (i == MT6359_ID_VCN33_1)
+ vcn33_1_name = rdev_get_name(rdev);
+
+ /* Save vcn33_2 name for vbbck */
+ if (i == MT6359_ID_VCN33_2)
+ vcn33_2_name = rdev_get_name(rdev);
}
return 0;
diff --git a/include/linux/regulator/mt6359-regulator.h b/include/linux/regulator/mt6359-regulator.h
index 6d6e5a58f482..ce2cd0fc9d95 100644
--- a/include/linux/regulator/mt6359-regulator.h
+++ b/include/linux/regulator/mt6359-regulator.h
@@ -29,8 +29,7 @@ enum {
MT6359_ID_VCN18,
MT6359_ID_VFE28,
MT6359_ID_VCN13,
- MT6359_ID_VCN33_1_BT,
- MT6359_ID_VCN33_1_WIFI,
+ MT6359_ID_VCN33_1,
MT6359_ID_VAUX18,
MT6359_ID_VSRAM_OTHERS,
MT6359_ID_VEFUSE,
@@ -39,8 +38,7 @@ enum {
MT6359_ID_VBIF28,
MT6359_ID_VIO28,
MT6359_ID_VEMC,
- MT6359_ID_VCN33_2_BT,
- MT6359_ID_VCN33_2_WIFI,
+ MT6359_ID_VCN33_2,
MT6359_ID_VA12,
MT6359_ID_VA09,
MT6359_ID_VRF18,
@@ -51,6 +49,10 @@ enum {
MT6359_ID_VSRAM_PROC1,
MT6359_ID_VSIM2,
MT6359_ID_VSRAM_OTHERS_SSHUB,
+ MT6359_ID_VCN33_1_BT,
+ MT6359_ID_VCN33_1_WIFI,
+ MT6359_ID_VCN33_2_BT,
+ MT6359_ID_VCN33_2_WIFI,
MT6359_ID_RG_MAX,
};
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
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