From patchwork Fri Jan 29 20:20:10 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Elder X-Patchwork-Id: 373354 Delivered-To: patch@linaro.org Received: by 2002:a02:a60d:0:0:0:0:0 with SMTP id c13csp2519600jam; Fri, 29 Jan 2021 12:21:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJyQ5f0Irw4zphUp0ZOjQBbqvTm0Cb7znxj7PZ0XJIFH7ahpmf+rDr4nYehQo9DhMFNeLBxC X-Received: by 2002:a05:6402:ca9:: with SMTP id cn9mr7330733edb.208.1611951703749; Fri, 29 Jan 2021 12:21:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611951703; cv=none; d=google.com; s=arc-20160816; b=BP1fcEktOJehmDePGl4CpTQUWyT7Kfp5KoddgOtR7jlueUndivq/ab5PFlbdcB527i p66jgjL/AnMSMS20xcXJSF1QcFgeeisoucTjoySKBwkILy7LyUfHliHDPEuLIQr00MnS /48IqqWwWpPmUuFYzTDVRxb64+0vlYVHvRWto+g+hYkGf4hZNdU5d3oEi14NxNeNwTFH XCv9Y+haGXFOme32aPXbpFp/bUzfgNqix5XiC16boOqfohqGJwAyTTEq5ibtvup143se 3x7O5GoSrY98Dddg4tV7FS/p/QaqC+yESJ5+D3dWKkgJeZfT6f7rW2EXt0cp7srH27Aw 65Bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=nhvF9PGHPykZ//tfBqMwf6Wd6smJWeypfZ3nnpPqJhQ=; b=0Kas6aDq0kMPMmliUwEqxyfVffiVFtu/sYsochkYhLwkLxa5SUX6QWNjYl5Pb7B9dh AbvP136fIXUxtX03ZddxtkQEpqORZkVQs/NiGXaSXbToKx5efDmxfSeSNI8njLm1mZ9p NA+Bh5CSKENjK20jblaiSqYoYrFUzdorOzIA+iC5/AMTeg74Nnx5TlZ85Z05wvy0FFdo CoypjXdgKe/eAbAdJ3bRunZht0P65vBvFovV0CRB5nPPgRivCw5pNHD8ZutBaA6pNaVi JM1HiZSllkIJBuwQe7H6EzWXKD40tritFKtuo0MnVdYtPM1MPVuUfWbpNJKpW2ifYekr UM6A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=fY48G4XU; spf=pass (google.com: domain of netdev-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=netdev-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dk25si5652515edb.583.2021.01.29.12.21.43; Fri, 29 Jan 2021 12:21:43 -0800 (PST) Received-SPF: pass (google.com: domain of netdev-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=fY48G4XU; spf=pass (google.com: domain of netdev-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=netdev-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233255AbhA2UV2 (ORCPT + 7 others); Fri, 29 Jan 2021 15:21:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233058AbhA2UVE (ORCPT ); Fri, 29 Jan 2021 15:21:04 -0500 Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D08E1C0613D6 for ; Fri, 29 Jan 2021 12:20:23 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id x21so10621557iog.10 for ; Fri, 29 Jan 2021 12:20:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=nhvF9PGHPykZ//tfBqMwf6Wd6smJWeypfZ3nnpPqJhQ=; b=fY48G4XUV5nA1Y+/YfKCAmxGTbIzY1eBq12gOKgmMX/TRRTlJOCPTEJP7mxrHXjMcC 1g7mLeHtbLVN+YfBn2toqKqmuaU6gJ2jHMBhA+x98K7IZEQ24rdSywuQHXJMklO8jksr SCWzTKUOZXBSe2NRNakaEnaCoT8GHraA09/WsU1LZiiN3c2ThRGBWNxEdb2pWDDlkVHS o+Yeq8nY3KfR0/uNGHuWjPqrS2cZt+0LWTPPMKXDzlKS8AEI0LdI5TAes/dzccS+Jfgu /EppfHBb16FgcebKuQslOEZkzaJ4acp5sYygRhvkq9/MR5gxrDjbPfDYbre8aXH/1xYo HS3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=nhvF9PGHPykZ//tfBqMwf6Wd6smJWeypfZ3nnpPqJhQ=; b=d/RFRbIJqoIkJEVgVOhcvgKCU34hzhGvFQPbxUEexvpxCmMXJStUn5taVcc+vZeGni N8kk7+CjnSIxa3a1iQRyhSHNEsS4bWV/e70BNTQRP/RJpKxfvUpThoo6LTVRWx3eXtTx sdYBK/ucwDW+bjDW2xpJS6d3YMX/phzBI5U2O1WLoD1iWuw4qi+8JDQHEWuF66vAQ7G+ lFedyMO6jHc3/xugL/SnECw4i2hPfn7q2KHM3iMuBxIN1cTSHCuZ7BtidGuLo70b4PhM T80qTmSGSiAC9h83Xd6d7bxyAy1eqj2+PzYaHN7qBSS6R5Uwmy0peGB8dljXRNQ4R3GW K6AA== X-Gm-Message-State: AOAM531yFuch7Ds+ka6pAJA0h7tpjkhfjadHrBJl6grQEosvEbzwNU0t uabGpFgrk6AgA7gHdbFT8ObrOQ== X-Received: by 2002:a02:3844:: with SMTP id v4mr5042759jae.1.1611951623187; Fri, 29 Jan 2021 12:20:23 -0800 (PST) Received: from presto.localdomain (c-73-185-129-58.hsd1.mn.comcast.net. [73.185.129.58]) by smtp.gmail.com with ESMTPSA id h23sm4645738ila.15.2021.01.29.12.20.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Jan 2021 12:20:22 -0800 (PST) From: Alex Elder To: davem@davemloft.net, kuba@kernel.org Cc: elder@kernel.org, evgreen@chromium.org, bjorn.andersson@linaro.org, cpratapa@codeaurora.org, subashab@codeaurora.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH net-next 0/9] net: ipa: don't disable NAPI in suspend Date: Fri, 29 Jan 2021 14:20:10 -0600 Message-Id: <20210129202019.2099259-1-elder@linaro.org> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org A few weeks ago I suggested a change that added a flag to determine whether NAPI should be re-enabled on a channel when we're done polling. That change was questioned, and upon further investigation I realized the IPA suspend path was "doing it wrong." Currently (for newer hardware) the IPA driver suspends channels by issuing a STOP command. Part of the stop processing includes a "freeze" operation, which quiesces activity, disables the I/O completion interrupt, and disables NAPI. But disabling NAPI is only meant to be done when shutting down the channel; there is no need to disable it when a channel is being stopped for suspend. This series reworks the way channels are stopped, with the end result being that neither NAPI nor the I/O completion interrupt is disabled when a channel is suspended. The first patch fixes an error handling bug in the channel starting path. The second patch creates a helper function to encpasulate retrying channel stop commands. The third also creates helper functions, but in doing so it makes channel stop and start handling be consistent for both "regular" stop and suspend. The fourth patch open-codes the freeze and thaw functions as a first step toward reworking what they do (reordering and eliminating steps). The fifth patch makes the I/O completion interrupt get disabled *after* a channel is stopped. This eliminates a small race in which the interrupt condition could occur between disabling the interrupt and stopping the channel. Once stopped, the channel will generate no more I/O completion interrupts. The sixth and seventh patches arrange for the completion interrupt to be disabled only stopping a channel "for good", not when suspending. (The sixth patch just makes a small step to facilitate review; these two could be squashed together.) The 8th patch ensures a TX request--if initiated just before stopping the TX queue--is included when determining whether a a channel is quiesced for stop or suspend. And finally the last patch implements the ultimate objective, disabling NAPI *only* when "really" stopping a channel (not for suspend). Instead of disabling NAPI, a call to napi_synchronize() ensures everything's done before we suspend. -Alex Alex Elder (9): net: ipa: don't thaw channel if error starting net: ipa: introduce gsi_channel_stop_retry() net: ipa: introduce __gsi_channel_start() net: ipa: kill gsi_channel_freeze() and gsi_channel_thaw() net: ipa: disable IEOB interrupt after channel stop net: ipa: move completion interrupt enable/disable net: ipa: don't disable IEOB interrupt during suspend net: ipa: expand last transaction check net: ipa: don't disable NAPI in suspend drivers/net/ipa/gsi.c | 137 ++++++++++++++++++++++++++---------------- 1 file changed, 85 insertions(+), 52 deletions(-) -- 2.27.0