From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD2A419C54F for ; Tue, 7 Jan 2025 18:28:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736274485; cv=none; b=q4yT1m+AXjhS+rOmgX/azCZCS0NXU1BQZuMyePdOQfHfw56FvVe9xfgOeI3LOpMJ/6lvEhxqenxf1zLYdux3EsqRaWmsbXGQYibRHIg7c5UJs9/gbP8fLva9BmidclUoBYRkHz9dEKP/Hb/0bpVZ6tN9vzXgJN88vJAtRBqdn1k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736274485; c=relaxed/simple; bh=xf3qBJ9dM+KyjkImmUMFvg+Yq3g+JgqNHQSj/Nh8+Pg=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=NZBWUBM4nJpSb/d1jAJZHfsRWuGxjuXbOTRgG8ycnmghic3urswfBLCq8JQ4LisYd9olM/A7TIdgkyePsAuOI33voRWDY74s1XoYIVFj6ANpS3agcTIR4+aFvFurFFVDCCERd4TWspvbueM10jFRLcHuHZ9CjwyMQMWmUQSYNDo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=ATQO8z9Q; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ATQO8z9Q" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736274479; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KoFNOzzjOpsum/rm1+qrKK5OefFe08iV+YSKMqnMeos=; b=ATQO8z9QfrgQM48PS+DC6b+VmeshB5ZUbVCLain+tpU+xMJ9np8vPmZLSDXt6DtnwGJLW+ YnrwQC5dj67Rl2EPAYEoYer/rJiF4Jzzjdv9b8lUd0ydF86ePSO2InYt8ZguSM7OxK3JFs AollriyGGtrKix5ErWWPew1SZBygOxM= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-452-nRcb3T9nPEq7NLCVNLnYRg-1; Tue, 07 Jan 2025 13:27:58 -0500 X-MC-Unique: nRcb3T9nPEq7NLCVNLnYRg-1 X-Mimecast-MFC-AGG-ID: nRcb3T9nPEq7NLCVNLnYRg Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4361fc2b2d6so49250605e9.3 for ; Tue, 07 Jan 2025 10:27:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736274477; x=1736879277; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KoFNOzzjOpsum/rm1+qrKK5OefFe08iV+YSKMqnMeos=; b=AZ1BP7CF6E1zORa0DudW/EdYuouIn/I8AUkNEeXvslzRIuWT+EZeIZBPO0Ng2rlvgl qNt/ucZIQMPTK6OAbFuceJdZanRH72G3Spm5ZPEqCw0rH/7uhToIZOpXwi2aEbTPmAWk uELSj41ElAlspMIMjXoJQpJmbf3rf3vjgMoB6N4tc2dGFh/FnSCP3ZhmJpOCQeyKcqvv T2X89FIDaPUNESrE8yUfWU7kFv9yazxriDCJDezFhQ3s48zoqYjnUFx4tSipVDVSDrSB MQF5jKnO0J2wrUU1ozUEYQwkllWB12mEhTzrsFin9qzZ7DRH0otNspKW0OsJ4AHTJ4n+ d2vA== X-Gm-Message-State: AOJu0YwNbpZjv/A4L+1jRgRllMGjL1e1ofyWBRRSgCYMgF4KShrMX258 BhR1RUCuEEtq9CHsUJgnq61hU1ji4TsAor+ySGE68d7pIbrRHJQJnCgNDNfbv62Qk1ugFVwkAlF fyE8PUAb0tPBCNJaHj+jpEA22x5QOU+0P7TOSz/GNbQHx/TwdzztwWmODnGijVw== X-Gm-Gg: ASbGnctI+FR1dZuOFT3STwWCIpWMsmes6n+TxI0xVe5/AjMyhL0pf7vCOLZjFbrNd8o kMMkaNHwAD7QocJ/foQS266Y7lD/3PiudQYe/pTCRInVkI3ttXNls3qYmRe4rJjkgeXMKEoIoJL G4a8Ewo6q+i+nG6xvWkvo7DPiN/VQIKwthxHJbAHFrsNCfj/X2ih/3a2N9pEkD86dXRMMNYc72W +VICkDN7xG6wEJbsANJzcBbHmfKTmZugxTrh+r9Bxy7bdtPhkLBaaAI2zqdbAYRbicTwmhAxNlZ YXrJZcyU X-Received: by 2002:a05:600c:1c0b:b0:435:9ed3:5688 with SMTP id 5b1f17b1804b1-43668646750mr570729005e9.18.1736274476963; Tue, 07 Jan 2025 10:27:56 -0800 (PST) X-Google-Smtp-Source: AGHT+IH/F4l7VI4VDRjy6QmIK4U6pdZNWV45Eu54IRB23uZDmpwLQvUEwYU50YAp9uyooOD3ts2jEQ== X-Received: by 2002:a05:600c:1c0b:b0:435:9ed3:5688 with SMTP id 5b1f17b1804b1-43668646750mr570728835e9.18.1736274476533; Tue, 07 Jan 2025 10:27:56 -0800 (PST) Received: from [192.168.88.253] (146-241-2-244.dyn.eolo.it. [146.241.2.244]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c89e1a1sm50411886f8f.69.2025.01.07.10.27.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jan 2025 10:27:55 -0800 (PST) Message-ID: <45fac9f0-b31a-495d-bd1b-ccf0fbe19653@redhat.com> Date: Tue, 7 Jan 2025 19:27:54 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Paolo Abeni Subject: Re: [PATCH net-next v3 2/3] net: ti: icssg-prueth: Add Multicast Filtering support for VLAN in MAC mode To: MD Danish Anwar , Jeongjun Park , Alexander Lobakin , Lukasz Majewski , Meghana Malladi , Diogo Ivo , Simon Horman , Jakub Kicinski , Eric Dumazet , "David S. Miller" , Andrew Lunn , Roger Quadros Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, srk@ti.com, Vignesh Raghavendra , Michal Swiatkowski , Larysa Zaremba References: <20250103092033.1533374-1-danishanwar@ti.com> <20250103092033.1533374-3-danishanwar@ti.com> <133b8da8-a2da-4bac-b0bb-7dcaebc219b9@redhat.com> <31a45fb4-acb6-4eb6-9ffb-ff1be798a064@ti.com> Content-Language: en-US In-Reply-To: <31a45fb4-acb6-4eb6-9ffb-ff1be798a064@ti.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, On 1/7/25 11:47 AM, MD Danish Anwar wrote: > On 07/01/25 3:12 pm, Paolo Abeni wrote: >> On 1/3/25 10:20 AM, MD Danish Anwar wrote: >>> Add multicast filtering support for VLAN interfaces in dual EMAC mode >>> for ICSSG driver. >>> >>> The driver uses vlan_for_each() API to get the list of available >>> vlans. The driver then sync mc addr of vlan interface with a locally >>> mainatined list emac->vlan_mcast_list[vid] using __hw_addr_sync_multiple() >>> API. >>> >>> The driver then calls the sync / unsync callbacks and based on whether >>> the ndev is vlan or not, driver passes appropriate vid to FDB helper >>> functions. >>> >>> This commit also exports __hw_addr_sync_multiple() in order to use it >>> from the ICSSG driver. >>> >>> Signed-off-by: MD Danish Anwar >>> --- >>> drivers/net/ethernet/ti/icssg/icssg_prueth.c | 67 ++++++++++++++++---- >>> drivers/net/ethernet/ti/icssg/icssg_prueth.h | 6 ++ >>> include/linux/netdevice.h | 3 + >>> net/core/dev_addr_lists.c | 7 +- >>> 4 files changed, 66 insertions(+), 17 deletions(-) >>> >>> diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.c b/drivers/net/ethernet/ti/icssg/icssg_prueth.c >>> index 1663941e59e3..ed8b5a3184d6 100644 >>> --- a/drivers/net/ethernet/ti/icssg/icssg_prueth.c >>> +++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.c >>> @@ -472,30 +472,44 @@ const struct icss_iep_clockops prueth_iep_clockops = { >>> >>> static int icssg_prueth_add_mcast(struct net_device *ndev, const u8 *addr) >>> { >>> - struct prueth_emac *emac = netdev_priv(ndev); >>> - int port_mask = BIT(emac->port_id); >>> + struct net_device *real_dev; >>> + struct prueth_emac *emac; >>> + int port_mask; >>> + u8 vlan_id; >>> >>> - port_mask |= icssg_fdb_lookup(emac, addr, 0); >>> - icssg_fdb_add_del(emac, addr, 0, port_mask, true); >>> - icssg_vtbl_modify(emac, 0, port_mask, port_mask, true); >>> + vlan_id = is_vlan_dev(ndev) ? vlan_dev_vlan_id(ndev) : PRUETH_DFLT_VLAN_MAC; >>> + real_dev = is_vlan_dev(ndev) ? vlan_dev_real_dev(ndev) : ndev; >>> + emac = netdev_priv(real_dev); >>> + >>> + port_mask = BIT(emac->port_id) | icssg_fdb_lookup(emac, addr, vlan_id); >>> + icssg_fdb_add_del(emac, addr, vlan_id, port_mask, true); >>> + icssg_vtbl_modify(emac, vlan_id, port_mask, port_mask, true); >>> >>> return 0; >>> } >>> >>> static int icssg_prueth_del_mcast(struct net_device *ndev, const u8 *addr) >>> { >>> - struct prueth_emac *emac = netdev_priv(ndev); >>> - int port_mask = BIT(emac->port_id); >>> + struct net_device *real_dev; >>> + struct prueth_emac *emac; >>> int other_port_mask; >>> + int port_mask; >>> + u8 vlan_id; >>> + >>> + vlan_id = is_vlan_dev(ndev) ? vlan_dev_vlan_id(ndev) : PRUETH_DFLT_VLAN_MAC; >>> + real_dev = is_vlan_dev(ndev) ? vlan_dev_real_dev(ndev) : ndev; >>> + emac = netdev_priv(real_dev); >>> >>> - other_port_mask = port_mask ^ icssg_fdb_lookup(emac, addr, 0); >>> + port_mask = BIT(emac->port_id); >>> + other_port_mask = port_mask ^ icssg_fdb_lookup(emac, addr, vlan_id); >>> >>> - icssg_fdb_add_del(emac, addr, 0, port_mask, false); >>> - icssg_vtbl_modify(emac, 0, port_mask, port_mask, false); >>> + icssg_fdb_add_del(emac, addr, vlan_id, port_mask, false); >>> + icssg_vtbl_modify(emac, vlan_id, port_mask, port_mask, false); >>> >>> if (other_port_mask) { >>> - icssg_fdb_add_del(emac, addr, 0, other_port_mask, true); >>> - icssg_vtbl_modify(emac, 0, other_port_mask, other_port_mask, true); >>> + icssg_fdb_add_del(emac, addr, vlan_id, other_port_mask, true); >>> + icssg_vtbl_modify(emac, vlan_id, other_port_mask, >>> + other_port_mask, true); >>> } >>> >>> return 0; >>> @@ -531,6 +545,25 @@ static int icssg_prueth_hsr_del_mcast(struct net_device *ndev, const u8 *addr) >>> return 0; >>> } >>> >>> +static int icssg_update_vlan_mcast(struct net_device *vdev, int vid, >>> + void *args) >>> +{ >>> + struct prueth_emac *emac = args; >>> + >>> + if (!vdev || !vid) >>> + return 0; >>> + >>> + netif_addr_lock_bh(vdev); >>> + __hw_addr_sync_multiple(&emac->vlan_mcast_list[vid], &vdev->mc, >>> + vdev->addr_len); >>> + netif_addr_unlock_bh(vdev); >> >> At this point, isn't emac->vlan_mcast_list[vid] == vdev->mc? >> >>> + >>> + __hw_addr_sync_dev(&emac->vlan_mcast_list[vid], vdev, >>> + icssg_prueth_add_mcast, icssg_prueth_del_mcast); >> >> If so, can this function be reduced to just: >> >> __dev_mc_sync(vdev, icssg_prueth_add_mcast, icssg_prueth_del_mcast); >> >> ? >> > > I don't know but for some reason __dev_mc_sync() doesn't work here. My > initial approach was to use __dev_mc_sync(vdev, sync, unsync) however it > didn't work. > > When I use __dev_mc_sync() and print the vlan_id in function > icssg_prueth_add_mcast(). It always prints vlan_id as 0 implying > __dev_mc_sync from here never gets called. Whereas when using > __hw_addr_sync_dev() I see the appropriate vlan_id in > icssg_prueth_add_mcast() It look like the above needs more investigation, right? is vlan_mcast_list[vid] different from vdev->mc? why? At very least you need to provide a clear explaination of the above. > Anyways, Even if I use __dev_mc_sync(), we will still need the export. I > am exporting __hw_addr_sync_multiple() not __hw_addr_sync_dev(). The API > being used by me `__hw_addr_sync_dev()` is already exported. I fear there is a misunderstanding. I'm suggesting dropping __hw_addr_sync_multiple() usage entirely. If that is not possible, a clear and complete explaination of the reason/root cause must be provided. Thanks, Paolo