From: Lorenzo Bianconi <lorenzo@kernel.org>
To: 陈耀明 <cc201008@gmail.com>
Cc: netdev@vger.kernel.org, horms@kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH net] net: airoha: Keep UPDMEM egress MAC in sync for offloaded IPv6 flows
Date: Tue, 13 Oct 2026 09:36:08 +0200 [thread overview]
Message-ID: <as3faB96PFSnC-qP@lore-desk> (raw)
In-Reply-To: <CAPZ+gd_1JsNyhQbEAWiE1stom+T_jgvt4F2=tb68YoSvPCnFag@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]
> Ooo, the new patch should be a dedicated leaf lock inside
> airoha_ppe_init_upd_mem().
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> @@ -416,6 +416,19 @@
> dsa_port);
>
> smac_id = port->id;
> + /*
> + * Routed IPv6 entries resolve the egress source MAC
> + * through the UPDMEM table indexed by smac_id. The
> + * egress netdev can legally carry a different address
> + * than the GDM port itself: on PON setups the
> + * authentication MAC lives on the pon device while
> + * each service VLAN routes with its own address. Keep
> + * the table entry in sync with the source address this
> + * flow is actually going to use.
Is the issue occurring just with PON or are you able to trigger the issue even
in the upstream codebase? I guess you should not post a fix for some code that
is not upstream yet. Moreover, in the PON setup, I guess the approach is still
broken if the user change the device mac address.
> + */
> + if (type >= PPE_PKT_TYPE_IPV6_ROUTE_3T)
> + airoha_ppe_init_upd_mem(dev,
> + data->eth.h_source);
> }
> }
>
> @@ -1529,10 +1542,21 @@
>
> void airoha_ppe_init_upd_mem(struct airoha_gdm_dev *dev, const u8 *addr)
> {
> + static DEFINE_MUTEX(updmem_lock);
> +
> struct airoha_gdm_port *port = dev->port;
> struct airoha_eth *eth = dev->eth;
> u32 val;
>
> + /*
> + * Routed IPv6 entries resolve the egress source MAC through the
> + * UPDMEM table indexed by smac_id; the ndo_open/ndo_set_mac_address
> + * writers hold flow_offload_mutex (QoS paths re-lock via
> + * airoha_set_macaddr()), so this lock also serializes the leaf
> + * against them.
> + */
> + mutex_lock(&updmem_lock);
This is only required adding the above configuration since in the current
codebase airoha_ppe_init_upd_mem() is always running holding RTNL.
Regards,
Lorenzo
> +
> val = (addr[2] << 24) | (addr[3] << 16) | (addr[4] << 8) | addr[5];
> airoha_fe_wr(eth, REG_UPDMEM_DATA(0), val);
> airoha_fe_wr(eth, REG_UPDMEM_CTRL(0),
> @@ -1545,6 +1569,8 @@
> FIELD_PREP(PPE_UPDMEM_ADDR_MASK, port->id) |
> FIELD_PREP(PPE_UPDMEM_OFFSET_MASK, 1) |
> PPE_UPDMEM_WR_MASK | PPE_UPDMEM_REQ_MASK);
> +
> + mutex_unlock(&updmem_lock);
> }
>
> struct airoha_ppe_dev *airoha_ppe_get_dev(struct device *dev)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-10-13 7:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAPZ+gd9d1P+xDSrxxZkGJr32zjubP=KfQegeGkWykKGvEH0=oA@mail.gmail.com>
2026-10-12 7:10 ` [PATCH net] net: airoha: Keep UPDMEM egress MAC in sync for offloaded IPv6 flows 陈耀明
2026-10-12 15:56 ` Lorenzo Bianconi
2026-10-12 17:09 ` 陈耀明
2026-10-13 7:36 ` Lorenzo Bianconi [this message]
2026-10-13 15:28 ` 陈耀明
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=as3faB96PFSnC-qP@lore-desk \
--to=lorenzo@kernel.org \
--cc=cc201008@gmail.com \
--cc=horms@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.