Re: [PATCH] net: qualcomm: rmnet: clarify MAP command ACK behavior

[Simon Horman]

On Sat, May 23, 2026 at 11:03:46AM +0000, Hungyu Lin wrote:
> rmnet_map_command() only sends ACK responses for supported
> commands. Unsupported commands are dropped without sending
> a response.
> 
> Update the comment to reflect the current behavior.
> 
> Signed-off-by: Hungyu Lin <dennylin0707@xxxxxxxxx>
> ---
>  drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
> index add0f5ade2e6..c1c3d4fc7a99 100644
> --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
> +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
> @@ -69,8 +69,8 @@ static void rmnet_map_send_ack(struct sk_buff *skb,
>  	netif_tx_unlock(dev);
>  }
>  
> -/* Process MAP command frame and send N/ACK message as appropriate. Message cmd
> - * name is decoded here and appropriate handler is called.
> +/* Process MAP command frame and send ACK message for supported commands.
> + * Message cmd name is decoded here and the appropriate handler is called.
>   */
>  void rmnet_map_command(struct sk_buff *skb, struct rmnet_port *port)
>  {

There is an AI generated review of this patch available at
https://netdev-ai.bots.linux.dev/sashiko/

In brief, it suggests that the wording above may still be too broad
as the ACk is only sent when supported commands are successfully processed.
But I regard this as a nit-pick and I think the current wording is fine.


There is another AI generated review of this patch available
at https://sashiko.dev

In this case the review flags possible pre-existing issues in the code.
And I don't believe they effect this documentation change.


In summary, I think this patch is good in it's current form.
And that it's progress should not be effected by the AI-generated
reviews cited above.

Reviewed-by: Simon Horman <horms@xxxxxxxxxx>