[PATCH net 0/2] Modify multicast entry handling in ALE table

[PATCH net 0/2] Modify multicast entry handling in ALE table

[Chintan Vankar]

This series updates how multicast entries are being added/deleted in the
ALE table by setting/resetting CPSW MAC port's bit to the port_mask.

This series is based on commit '7d6ba706ae5e' of 'origin/main' branch of
Linux-net repo.

Chintan Vankar (2):
  net: ethernet: ti: am65-cpsw-nuss: Update port_mask while adding
    multicast entry
  net: ethernet: ti: cpsw_ale: Update multicast entry handling in ALE
    Table

 drivers/net/ethernet/ti/am65-cpsw-nuss.c | 2 +-
 drivers/net/ethernet/ti/cpsw_ale.c       | 9 ++++-----
 2 files changed, 5 insertions(+), 6 deletions(-)

-- 
2.34.1

[PATCH net 1/2] net: ethernet: ti: am65-cpsw-nuss: Update port_mask while adding multicast entry

[Chintan Vankar]

Multicast entry rules are mainly evaluated for receiving traffic and do not
require MAC ports to be explicitly associated with them. However, setting
associated MAC port's bit to the port_mask of the ALE entry ensures
technical correctness and helps maintaining ALE entries linked to MAC
ports.

Signed-off-by: Chintan Vankar <c-vankar@ti.com>
---
 drivers/net/ethernet/ti/am65-cpsw-nuss.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index 5924db6be3fe..967918050433 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -391,7 +391,7 @@ static void am65_cpsw_nuss_ndo_slave_set_rx_mode(struct net_device *ndev)
 	cpsw_ale_set_allmulti(common->ale,
 			      ndev->flags & IFF_ALLMULTI, port->port_id);
 
-	port_mask = ALE_PORT_HOST;
+	port_mask = BIT(port->port_id) | ALE_PORT_HOST;
 	/* Clear all mcast from ALE */
 	cpsw_ale_flush_multicast(common->ale, port_mask, -1);
 
-- 
2.34.1

Re: [PATCH net 1/2] net: ethernet: ti: am65-cpsw-nuss: Update port_mask while adding multicast entry

[Siddharth Vadapalli]

On Thu, 2026-02-05 at 12:39 +0530, Chintan Vankar wrote:
> Multicast entry rules are mainly evaluated for receiving traffic and do not
> require MAC ports to be explicitly associated with them. However, setting
> associated MAC port's bit to the port_mask of the ALE entry ensures
> technical correctness and helps maintaining ALE entries linked to MAC
> ports.
> 
> Signed-off-by: Chintan Vankar <c-vankar@ti.com>
> ---
>  drivers/net/ethernet/ti/am65-cpsw-nuss.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> index 5924db6be3fe..967918050433 100644
> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> @@ -391,7 +391,7 @@ static void am65_cpsw_nuss_ndo_slave_set_rx_mode(struct net_device *ndev)
>  	cpsw_ale_set_allmulti(common->ale,
>  			      ndev->flags & IFF_ALLMULTI, port->port_id);
>  
> -	port_mask = ALE_PORT_HOST;
> +	port_mask = BIT(port->port_id) | ALE_PORT_HOST;

Since the port_mask setup above is passed to 'cpsw_ale_flush_multicast()'
below, wouldn't it temporarily cause the forwarded multicast traffic to be
dropped?

>  	/* Clear all mcast from ALE */
>  	cpsw_ale_flush_multicast(common->ale, port_mask, -1);
> 
> 

The code in the driver following the above function call is:

	if (!netdev_mc_empty(ndev)) {
		struct netdev_hw_addr *ha;

		/* program multicast address list into ALE register */
		netdev_for_each_mc_addr(ha, ndev) {
			cpsw_ale_add_mcast(common->ale, ha->addr,
					   port_mask, 0, 0, 0);
		}
	}

So we do add back the multicast entries for the same 'port_mask' that we
removed earlier during cpsw_ale_flush_multicast(), but, there is a delay
between flushing the entries in cpsw_ale_flush_multicast() and adding them
back via cpsw_ale_add_mcast(). During that period, the multicast traffic on
the forwarding path between MAC Ports will be momentarily dropped. Please
clarify if that isn't the case.

Regards,
Siddharth.

Re: [PATCH net 1/2] net: ethernet: ti: am65-cpsw-nuss: Update port_mask while adding multicast entry

[Chintan Vankar]

Hello Siddharth

On 05/02/26 13:45, Siddharth Vadapalli wrote:
> On Thu, 2026-02-05 at 12:39 +0530, Chintan Vankar wrote:
>> Multicast entry rules are mainly evaluated for receiving traffic and do not
>> require MAC ports to be explicitly associated with them. However, setting
>> associated MAC port's bit to the port_mask of the ALE entry ensures
>> technical correctness and helps maintaining ALE entries linked to MAC
>> ports.
>>
>> Signed-off-by: Chintan Vankar <c-vankar@ti.com>
>> ---
>>   drivers/net/ethernet/ti/am65-cpsw-nuss.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
>> index 5924db6be3fe..967918050433 100644
>> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
>> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
>> @@ -391,7 +391,7 @@ static void am65_cpsw_nuss_ndo_slave_set_rx_mode(struct net_device *ndev)
>>   	cpsw_ale_set_allmulti(common->ale,
>>   			      ndev->flags & IFF_ALLMULTI, port->port_id);
>>   
>> -	port_mask = ALE_PORT_HOST;
>> +	port_mask = BIT(port->port_id) | ALE_PORT_HOST;
> 
> Since the port_mask setup above is passed to 'cpsw_ale_flush_multicast()'
> below, wouldn't it temporarily cause the forwarded multicast traffic to be
> dropped?
> 
>>   	/* Clear all mcast from ALE */
>>   	cpsw_ale_flush_multicast(common->ale, port_mask, -1);
>>
>>
> 
> The code in the driver following the above function call is:
> 
> 	if (!netdev_mc_empty(ndev)) {
> 		struct netdev_hw_addr *ha;
> 
> 		/* program multicast address list into ALE register */
> 		netdev_for_each_mc_addr(ha, ndev) {
> 			cpsw_ale_add_mcast(common->ale, ha->addr,
> 					   port_mask, 0, 0, 0);
> 		}
> 	}
> 
> So we do add back the multicast entries for the same 'port_mask' that we
> removed earlier during cpsw_ale_flush_multicast(), but, there is a delay
> between flushing the entries in cpsw_ale_flush_multicast() and adding them
> back via cpsw_ale_add_mcast(). During that period, the multicast traffic on
> the forwarding path between MAC Ports will be momentarily dropped. Please
> clarify if that isn't the case.
> 

When "cpsw_ale_flush_multicast()" is called, it only deletes entries
where the resulting port_mask becomes "0x0" or "ALE_PORT_HOST" (as per
the function implementation "cpsw_ale_flush_multicast()" in cpsw_ale.c).

For multicast entries shared across multiple ports, the function only
clears the specific port's bit from the port_mask without deleting the
entry itself. This prevents any traffic disruption for other active
ports.

Regards,
Chintan.

> Regards,
> Siddharth.

Re: [PATCH net 1/2] net: ethernet: ti: am65-cpsw-nuss: Update port_mask while adding multicast entry

[Siddharth Vadapalli]

On 05/02/26 5:05 PM, Chintan Vankar wrote:
> Hello Siddharth
> 
> On 05/02/26 13:45, Siddharth Vadapalli wrote:
>> On Thu, 2026-02-05 at 12:39 +0530, Chintan Vankar wrote:
>>> Multicast entry rules are mainly evaluated for receiving traffic and 
>>> do not
>>> require MAC ports to be explicitly associated with them. However, 
>>> setting
>>> associated MAC port's bit to the port_mask of the ALE entry ensures
>>> technical correctness and helps maintaining ALE entries linked to MAC
>>> ports.
>>>
>>> Signed-off-by: Chintan Vankar <c-vankar@ti.com>
>>> ---
>>>   drivers/net/ethernet/ti/am65-cpsw-nuss.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ 
>>> ethernet/ti/am65-cpsw-nuss.c
>>> index 5924db6be3fe..967918050433 100644
>>> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
>>> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
>>> @@ -391,7 +391,7 @@ static void 
>>> am65_cpsw_nuss_ndo_slave_set_rx_mode(struct net_device *ndev)
>>>       cpsw_ale_set_allmulti(common->ale,
>>>                     ndev->flags & IFF_ALLMULTI, port->port_id);
>>> -    port_mask = ALE_PORT_HOST;
>>> +    port_mask = BIT(port->port_id) | ALE_PORT_HOST;
>>
>> Since the port_mask setup above is passed to 'cpsw_ale_flush_multicast()'
>> below, wouldn't it temporarily cause the forwarded multicast traffic 
>> to be
>> dropped?
>>
>>>       /* Clear all mcast from ALE */
>>>       cpsw_ale_flush_multicast(common->ale, port_mask, -1);
>>>
>>>
>>
>> The code in the driver following the above function call is:
>>
>>     if (!netdev_mc_empty(ndev)) {
>>         struct netdev_hw_addr *ha;
>>
>>         /* program multicast address list into ALE register */
>>         netdev_for_each_mc_addr(ha, ndev) {
>>             cpsw_ale_add_mcast(common->ale, ha->addr,
>>                        port_mask, 0, 0, 0);
>>         }
>>     }
>>
>> So we do add back the multicast entries for the same 'port_mask' that we
>> removed earlier during cpsw_ale_flush_multicast(), but, there is a delay
>> between flushing the entries in cpsw_ale_flush_multicast() and adding 
>> them
>> back via cpsw_ale_add_mcast(). During that period, the multicast 
>> traffic on
>> the forwarding path between MAC Ports will be momentarily dropped. Please
>> clarify if that isn't the case.
>>
> 
> When "cpsw_ale_flush_multicast()" is called, it only deletes entries
> where the resulting port_mask becomes "0x0" or "ALE_PORT_HOST" (as per
> the function implementation "cpsw_ale_flush_multicast()" in cpsw_ale.c).
> 
> For multicast entries shared across multiple ports, the function only
> clears the specific port's bit from the port_mask without deleting the
> entry itself. This prevents any traffic disruption for other active
> ports.

Consider two MAC Ports P1 and P2. P1 belongs to multicast group M1 and 
M2, while P2 belongs only to multicast group M2.

If M1 is deleted from the interface for P1, it will trigger the 
execution of 'am65_cpsw_nuss_ndo_slave_set_rx_mode()' function.
In the function, we have:

	port_mask = BIT(port->port_id) | ALE_PORT_HOST;
	cpsw_ale_flush_multicast(common->ale, port_mask, -1);

	=> At this point, M2 would have also been removed in addition
	   to M1 for P1. As a result, Multicast traffic M2 from P2 to
	   P1 is dropped.

	if (!netdev_mc_empty(ndev)) {
		struct netdev_hw_addr *ha;

		/* program multicast address list into ALE register */
		netdev_for_each_mc_addr(ha, ndev) {
		cpsw_ale_add_mcast(common->ale, ha->addr,
				   port_mask, 0, 0, 0);
		}
	}

	=> We are adding back M2 to P1 above, but since it is not
	   instantaneous, it will take time for the Multicast traffic
	   M2 to be forwarded from P2 to P1.

Please let me know if I have overlooked something.

Regards,
Siddharth.

Re: [PATCH net 1/2] net: ethernet: ti: am65-cpsw-nuss: Update port_mask while adding multicast entry

[Chintan Vankar]

Hello Siddharth,

On 05/02/26 20:31, Siddharth Vadapalli wrote:
> On 05/02/26 5:05 PM, Chintan Vankar wrote:
>> Hello Siddharth
>>
>> On 05/02/26 13:45, Siddharth Vadapalli wrote:
>>> On Thu, 2026-02-05 at 12:39 +0530, Chintan Vankar wrote:
>>>> Multicast entry rules are mainly evaluated for receiving traffic and 
>>>> do not
>>>> require MAC ports to be explicitly associated with them. However, 
>>>> setting
>>>> associated MAC port's bit to the port_mask of the ALE entry ensures
>>>> technical correctness and helps maintaining ALE entries linked to MAC
>>>> ports.
>>>>
>>>> Signed-off-by: Chintan Vankar <c-vankar@ti.com>
>>>> ---
>>>>   drivers/net/ethernet/ti/am65-cpsw-nuss.c | 2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ 
>>>> ethernet/ti/am65-cpsw-nuss.c
>>>> index 5924db6be3fe..967918050433 100644
>>>> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
>>>> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
>>>> @@ -391,7 +391,7 @@ static void 
>>>> am65_cpsw_nuss_ndo_slave_set_rx_mode(struct net_device *ndev)
>>>>       cpsw_ale_set_allmulti(common->ale,
>>>>                     ndev->flags & IFF_ALLMULTI, port->port_id);
>>>> -    port_mask = ALE_PORT_HOST;
>>>> +    port_mask = BIT(port->port_id) | ALE_PORT_HOST;
>>>
>>> Since the port_mask setup above is passed to 
>>> 'cpsw_ale_flush_multicast()'
>>> below, wouldn't it temporarily cause the forwarded multicast traffic 
>>> to be
>>> dropped?
>>>
>>>>       /* Clear all mcast from ALE */
>>>>       cpsw_ale_flush_multicast(common->ale, port_mask, -1);
>>>>
>>>>
>>>
>>> The code in the driver following the above function call is:
>>>
>>>     if (!netdev_mc_empty(ndev)) {
>>>         struct netdev_hw_addr *ha;
>>>
>>>         /* program multicast address list into ALE register */
>>>         netdev_for_each_mc_addr(ha, ndev) {
>>>             cpsw_ale_add_mcast(common->ale, ha->addr,
>>>                        port_mask, 0, 0, 0);
>>>         }
>>>     }
>>>
>>> So we do add back the multicast entries for the same 'port_mask' that we
>>> removed earlier during cpsw_ale_flush_multicast(), but, there is a delay
>>> between flushing the entries in cpsw_ale_flush_multicast() and adding 
>>> them
>>> back via cpsw_ale_add_mcast(). During that period, the multicast 
>>> traffic on
>>> the forwarding path between MAC Ports will be momentarily dropped. 
>>> Please
>>> clarify if that isn't the case.
>>>
>>
>> When "cpsw_ale_flush_multicast()" is called, it only deletes entries
>> where the resulting port_mask becomes "0x0" or "ALE_PORT_HOST" (as per
>> the function implementation "cpsw_ale_flush_multicast()" in cpsw_ale.c).
>>
>> For multicast entries shared across multiple ports, the function only
>> clears the specific port's bit from the port_mask without deleting the
>> entry itself. This prevents any traffic disruption for other active
>> ports.
> 
> Consider two MAC Ports P1 and P2. P1 belongs to multicast group M1 and 
> M2, while P2 belongs only to multicast group M2.
> 
> If M1 is deleted from the interface for P1, it will trigger the 
> execution of 'am65_cpsw_nuss_ndo_slave_set_rx_mode()' function.
> In the function, we have:
> 
>      port_mask = BIT(port->port_id) | ALE_PORT_HOST;
>      cpsw_ale_flush_multicast(common->ale, port_mask, -1);
> 
>      => At this point, M2 would have also been removed in addition
>         to M1 for P1. As a result, Multicast traffic M2 from P2 to
>         P1 is dropped.

The scenario you have described applies to switch mode operation.
However, the fix specifically addresses the issue with the MAC mode.
The fix ensures that in MAC mode, multicast entries are correctly
associated with the Host port and MAC mode, and it doesn't disrupt the
traffic as mentioned in the previous reply.

I believe I should be more clear with the issue and the fix. I will post
the next version with more clarity.

Regards,
Chintan.

> 
>      if (!netdev_mc_empty(ndev)) {
>          struct netdev_hw_addr *ha;
> 
>          /* program multicast address list into ALE register */
>          netdev_for_each_mc_addr(ha, ndev) {
>          cpsw_ale_add_mcast(common->ale, ha->addr,
>                     port_mask, 0, 0, 0);
>          }
>      }
> 
>      => We are adding back M2 to P1 above, but since it is not
>         instantaneous, it will take time for the Multicast traffic
>         M2 to be forwarded from P2 to P1.
> 
> Please let me know if I have overlooked something.
> 

The fix in the second patch is for the MAC mode of operation and it
won't disrupt traffic forwarding considering your scenario.

Regards,
Chintan.

> Regards,
> Siddharth.

Re: [PATCH net 1/2] net: ethernet: ti: am65-cpsw-nuss: Update port_mask while adding multicast entry

[Siddharth Vadapalli]

On Mon, 2026-02-16 at 23:45 +0530, Chintan Vankar wrote:
> Hello Siddharth,
> 
> On 05/02/26 20:31, Siddharth Vadapalli wrote:
> > On 05/02/26 5:05 PM, Chintan Vankar wrote:
> > > Hello Siddharth
> > > 
> > > On 05/02/26 13:45, Siddharth Vadapalli wrote:
> > > > On Thu, 2026-02-05 at 12:39 +0530, Chintan Vankar wrote:
> > > > > Multicast entry rules are mainly evaluated for receiving traffic and 
> > > > > do not
> > > > > require MAC ports to be explicitly associated with them. However, 
> > > > > setting
> > > > > associated MAC port's bit to the port_mask of the ALE entry ensures
> > > > > technical correctness and helps maintaining ALE entries linked to MAC
> > > > > ports.
> > > > > 
> > > > > Signed-off-by: Chintan Vankar <c-vankar@ti.com>
> > > > > ---
> > > > >   drivers/net/ethernet/ti/am65-cpsw-nuss.c | 2 +-
> > > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ 
> > > > > ethernet/ti/am65-cpsw-nuss.c
> > > > > index 5924db6be3fe..967918050433 100644
> > > > > --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> > > > > +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> > > > > @@ -391,7 +391,7 @@ static void 
> > > > > am65_cpsw_nuss_ndo_slave_set_rx_mode(struct net_device *ndev)
> > > > >       cpsw_ale_set_allmulti(common->ale,
> > > > >                     ndev->flags & IFF_ALLMULTI, port->port_id);
> > > > > -    port_mask = ALE_PORT_HOST;
> > > > > +    port_mask = BIT(port->port_id) | ALE_PORT_HOST;
> > > > 
> > > > Since the port_mask setup above is passed to 
> > > > 'cpsw_ale_flush_multicast()'
> > > > below, wouldn't it temporarily cause the forwarded multicast traffic 
> > > > to be
> > > > dropped?
> > > > 
> > > > >       /* Clear all mcast from ALE */
> > > > >       cpsw_ale_flush_multicast(common->ale, port_mask, -1);
> > > > > 
> > > > > 
> > > > 
> > > > The code in the driver following the above function call is:
> > > > 
> > > >     if (!netdev_mc_empty(ndev)) {
> > > >         struct netdev_hw_addr *ha;
> > > > 
> > > >         /* program multicast address list into ALE register */
> > > >         netdev_for_each_mc_addr(ha, ndev) {
> > > >             cpsw_ale_add_mcast(common->ale, ha->addr,
> > > >                        port_mask, 0, 0, 0);
> > > >         }
> > > >     }
> > > > 
> > > > So we do add back the multicast entries for the same 'port_mask' that we
> > > > removed earlier during cpsw_ale_flush_multicast(), but, there is a delay
> > > > between flushing the entries in cpsw_ale_flush_multicast() and adding 
> > > > them
> > > > back via cpsw_ale_add_mcast(). During that period, the multicast 
> > > > traffic on
> > > > the forwarding path between MAC Ports will be momentarily dropped. 
> > > > Please
> > > > clarify if that isn't the case.
> > > > 
> > > 
> > > When "cpsw_ale_flush_multicast()" is called, it only deletes entries
> > > where the resulting port_mask becomes "0x0" or "ALE_PORT_HOST" (as per
> > > the function implementation "cpsw_ale_flush_multicast()" in cpsw_ale.c).
> > > 
> > > For multicast entries shared across multiple ports, the function only
> > > clears the specific port's bit from the port_mask without deleting the
> > > entry itself. This prevents any traffic disruption for other active
> > > ports.
> > 
> > Consider two MAC Ports P1 and P2. P1 belongs to multicast group M1 and 
> > M2, while P2 belongs only to multicast group M2.
> > 
> > If M1 is deleted from the interface for P1, it will trigger the 
> > execution of 'am65_cpsw_nuss_ndo_slave_set_rx_mode()' function.
> > In the function, we have:
> > 
> >      port_mask = BIT(port->port_id) | ALE_PORT_HOST;
> >      cpsw_ale_flush_multicast(common->ale, port_mask, -1);
> > 
> >      => At this point, M2 would have also been removed in addition
> >         to M1 for P1. As a result, Multicast traffic M2 from P2 to
> >         P1 is dropped.
> 
> The scenario you have described applies to switch mode operation.
> However, the fix specifically addresses the issue with the MAC mode.
> The fix ensures that in MAC mode, multicast entries are correctly
> associated with the Host port and MAC mode, and it doesn't disrupt the
> traffic as mentioned in the previous reply.
> 
> I believe I should be more clear with the issue and the fix. I will post
> the next version with more clarity.

Ok. Please include one or more 'Fixes' tag(s) as well when you post the v2
patch since you have marked this patch with the 'net' suffix implying that
it is a Fix and not a Feature.

Regards,
Siddharth.

[PATCH net 2/2] net: ethernet: ti: cpsw_ale: Update multicast entry handling in ALE Table

[Chintan Vankar]

The current implementation of multicast entry flushing marks all multicast
entries as free whenever any interface adds, deletes, or modifies
multicast entry. It then re-adds the entries, which disrupts existing
multicast connection for other interfaces associated with that entry.

Update multicast flushing API to handle above case by clearing out a bit
in port_mask for that specific interface.

Signed-off-by: Chintan Vankar <c-vankar@ti.com>
---
 drivers/net/ethernet/ti/cpsw_ale.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw_ale.c b/drivers/net/ethernet/ti/cpsw_ale.c
index fbe35af615a6..9632ad3741de 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.c
+++ b/drivers/net/ethernet/ti/cpsw_ale.c
@@ -455,14 +455,13 @@ static void cpsw_ale_flush_mcast(struct cpsw_ale *ale, u32 *ale_entry,
 				      ale->port_mask_bits);
 	if ((mask & port_mask) == 0)
 		return; /* ports dont intersect, not interested */
-	mask &= ~port_mask;
+	mask &= (~port_mask | ALE_PORT_HOST);
 
-	/* free if only remaining port is host port */
-	if (mask)
+	if (mask == 0x0 || mask == ALE_PORT_HOST)
+		cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_FREE);
+	else
 		cpsw_ale_set_port_mask(ale_entry, mask,
 				       ale->port_mask_bits);
-	else
-		cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_FREE);
 }
 
 int cpsw_ale_flush_multicast(struct cpsw_ale *ale, int port_mask, int vid)
-- 
2.34.1