Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 18 Apr 2023 02:08:15 +0200
From:   Andrew Lunn <andrew@lunn.ch>
To:     Shmuel Hazan <shmuel.h@siklu.com>
Cc:     Russell King <linux@armlinux.org.uk>,
        Marcin Wojtas <mw@semihalf.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Richard Cochran <richardcochran@gmail.com>,
        horatiu.vultur@microchip.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] net: mvpp2: tai: add refcount for ptp worker
Message-ID: <2315ea01-650b-4eb0-afc9-f3f9880c0736@lunn.ch>
References: <20230417160151.1617256-1-shmuel.h@siklu.com>
 <20230417160151.1617256-2-shmuel.h@siklu.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230417160151.1617256-2-shmuel.h@siklu.com>
Precedence: bulk

On Mon, Apr 17, 2023 at 07:01:49PM +0300, Shmuel Hazan wrote:
> In some configurations, a single TAI can be responsible for multiple
> mvpp2 interfaces. However, the mvpp2 driver will call mvpp22_tai_stop
> and mvpp22_tai_start per interface RX timestamp disable/enable.
> 
> As a result, disabling timestamping for one interface would stop the
> worker and corrupt the other interface's RX timestamps.
> 
> This commit solves the issue by introducing a simpler ref count for each
> TAI instance.

This is version 2, so you should add that to the subject line.  You
should also indicate what changed since the previous version.

Please read https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

You have added Fixes: tags, so you think this is a fix for stable? You
then should indicate this on the Subject line.
 
> Fixes: ce3497e2072e ("net: mvpp2: ptp: add support for receive timestamping")
> Signed-off-by: Shmuel Hazan <shmuel.h@siklu.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew