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;
Message-ID: <4d08b849-3e79-7c82-803c-51c251344c7a@gmail.com>
Date:   Mon, 27 Jun 2022 17:46:10 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: [PATCH v2] net: ocelot: fix wrong time_after usage
Content-Language: en-US
To:     =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= <clement.leger@bootlin.com>,
        Vladimir Oltean <vladimir.oltean@nxp.com>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        Claudiu Manoil <claudiu.manoil@nxp.com>,
        "alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
        "UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <YoeMW+/KGk8VpbED@lunn.ch>
 <20220520213115.7832-1-paskripkin@gmail.com> <YojvUsJ090H/wfEk@lunn.ch>
 <20220521162108.bact3sn4z2yuysdt@skbuf> <20220624171429.4b3f7c0a@fixe.home>
From:   Pavel Skripkin <paskripkin@gmail.com>
In-Reply-To: <20220624171429.4b3f7c0a@fixe.home>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 6/24/22 18:14, Clément Léger wrote:
> So I actually tested and added logging to see if the CH_SAFE
> register bits are set for the channel on the first iteration. From
> what I could test (iperf3 with huge/non huge packets, TCP/UDP), it
> always return true on the first try. So since I think Pavel solution
> is ok to go with.
> 
> However, since ocelot_fdma_wait_chan_safe() is also called in the napi
> poll function of this driver, I don't think sleeping is allowed (softirq
> context) and thus I would suggest using the readx_poll_timeout_atomic()
> function instead.
> 
> Regarding the delay to wait between each read, I don't have any
> information about that possible value, the datasheet only says "wait
> for the bit to be set" so I guess we'll have to live with an
> approximate value.
> 

Thank you for testing!

I will update update v3 with _atomic variant


Thanks,
--Pavel Skripkin