From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88065C31E5B for ; Mon, 17 Jun 2019 18:47:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 512092084D for ; Mon, 17 Jun 2019 18:47:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="SAnZ3X0d" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728476AbfFQSrS (ORCPT ); Mon, 17 Jun 2019 14:47:18 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:45203 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727317AbfFQSrR (ORCPT ); Mon, 17 Jun 2019 14:47:17 -0400 Received: by mail-io1-f66.google.com with SMTP id e3so23460660ioc.12 for ; Mon, 17 Jun 2019 11:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N++lS1o+MDz9+i4mzKncc0qVpXXpsoR+Jo3R2g+KlCo=; b=SAnZ3X0db+ry3DfdGKhXmDVRB1ay1ZXQyzAHIfdFfY354qGzD+/MI11JpexYGS29uJ j/eWkJnZhvOuHS/+zRUH8o7WpVEbUQkgyLS8HmbtOP1YHy+H+Pbb/FMLh460HskPqysH pUl3dQYa5lFFHCpPM7xu1Tgu8PXg+wPzShMxM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N++lS1o+MDz9+i4mzKncc0qVpXXpsoR+Jo3R2g+KlCo=; b=iJIXOi7YnuV9MksWo4XKijH8tJhEgT0JKnKptVrwJhpeYyrhFh10NzneBZ9X7PNDGw 1cfk6PnJ4y3fA285MH3BQTz1E/lo1e6Z5uE73RR76sRHXTBS8g7bsRsv1YAS46H5mIux xqXaIcEg1/RasVUkuVEU4EFBPireRvv1vdzDMhUeuaySVpYIsYOBQ0XKLr0jpPwI4QBb /X/0mOStQ1Vn37l1UCKCvYx7ff2hre/nf2lveDPg+oe2MaKOtdf7AGuaBCsHUNs1sccJ x8SROi8ABolMQ6q+S09OJBYK5yYFyyEFHXCl8GRotXf06NWalKIrecUVBtpXVWjZlFzx mMFg== X-Gm-Message-State: APjAAAVXV1JLW2fjx8/UMnKfIpFwNvwxW+XTnIE3ZeGr6FBzBaeK23SD lvuYDhchC7S0a7S7yJFzqqSS46X8738= X-Google-Smtp-Source: APXvYqw6byYZADq/e4f5nKHM8Kn6Wu4+kMxyqtfGyLkIDWvBFXbUjy9toJR4stA6IAtiBv1/dzAgMA== X-Received: by 2002:a5d:97d8:: with SMTP id k24mr3849596ios.84.1560797236315; Mon, 17 Jun 2019 11:47:16 -0700 (PDT) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com. [209.85.166.46]) by smtp.gmail.com with ESMTPSA id b20sm10330165ios.44.2019.06.17.11.47.13 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jun 2019 11:47:15 -0700 (PDT) Received: by mail-io1-f46.google.com with SMTP id r185so17610838iod.6 for ; Mon, 17 Jun 2019 11:47:13 -0700 (PDT) X-Received: by 2002:a5e:db0a:: with SMTP id q10mr77753iop.168.1560797232212; Mon, 17 Jun 2019 11:47:12 -0700 (PDT) MIME-Version: 1.0 References: <20190617175653.21756-1-dianders@chromium.org> In-Reply-To: From: Doug Anderson Date: Mon, 17 Jun 2019 11:46:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 0/5] brcmfmac: sdio: Deal better w/ transmission errors related to idle To: Ulf Hansson Cc: Kalle Valo , Adrian Hunter , Arend van Spriel , brcm80211-dev-list.pdl@broadcom.com, "open list:ARM/Rockchip SoC..." , Double Lo , Brian Norris , linux-wireless , Naveen Gupta , Madhan Mohan R , Matthias Kaehlcke , Wright Feng , Chi-Hsien Lin , netdev , brcm80211-dev-list , YueHaibing , Allison Randal , Thomas Gleixner , Hante Meuleman , Greg Kroah-Hartman , =?UTF-8?Q?Niklas_S=C3=B6derlund?= , Ritesh Harjani , Michael Trimarchi , Wolfram Sang , Franky Lin , Ondrej Jirman , Jiong Wu , "David S. Miller" , "linux-mmc@vger.kernel.org" , Linux Kernel Mailing List , Avri Altman Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Mon, Jun 17, 2019 at 11:39 AM Ulf Hansson wrote: > > On Mon, 17 Jun 2019 at 19:57, Douglas Anderson wrote: > > > > This series attempts to deal better with the expected transmission > > errors related to the idle states (handled by the Always-On-Subsystem > > or AOS) on the SDIO-based WiFi on rk3288-veyron-minnie, > > rk3288-veyron-speedy, and rk3288-veyron-mickey. > > > > Some details about those errors can be found in > > , but to summarize it here: if we try to > > send the wakeup command to the WiFi card at the same time it has > > decided to wake up itself then it will behave badly on the SDIO bus. > > This can cause timeouts or CRC errors. > > > > When I tested on 4.19 and 4.20 these CRC errors can be seen to cause > > re-tuning. Since I am currently developing on 4.19 this was the > > original problem I attempted to solve. > > > > On mainline it turns out that you don't see the retuning errors but > > you see tons of spam about timeouts trying to wakeup from sleep. I > > tracked down the commit that was causing that and have partially > > reverted it here. I have no real knowledge about Broadcom WiFi, but > > the commit that was causing problems sounds (from the descriptioin) to > > be a hack commit penalizing all Broadcom WiFi users because of a bug > > in a Cypress SD controller. I will let others comment if this is > > truly the case and, if so, what the right solution should be. > > > > For v3 of this series I have added 2 patches to the end of the series > > to address errors that would show up on systems with these same SDIO > > WiFi cards when used on controllers that do periodic retuning. These > > systems need an extra fix to prevent the retuning from happening when > > the card is asleep. > > > > I believe v5 of this series is all ready to go assuming Kalle Valo is > > good with it. I've added after-the-cut notes to patches awaiting his > > Ack and have added other tags collected so far. > > > > Changes in v5: > > - Add missing sdio_retune_crc_enable() in comments (Ulf). > > - /s/reneable/re-enable (Ulf). > > - Remove leftover prototypes: mmc_expect_errors_begin() / end() (Ulf). > > - Rewording of "sleep command" in commit message (Arend). > > > > Changes in v4: > > - Moved to SDIO API only (Adrian, Ulf). > > - Renamed to make it less generic, now retune_crc_disable (Ulf). > > - Function header makes it clear host must be claimed (Ulf). > > - No more WARN_ON (Ulf). > > - Adjust to API rename (Adrian, Ulf). > > - Moved retune hold/release to SDIO API (Adrian). > > - Adjust to API rename (Adrian). > > > > Changes in v3: > > - Took out the spinlock since I believe this is all in one context. > > - Expect errors for all of brcmf_sdio_kso_control() (Adrian). > > - ("mmc: core: Export mmc_retune_hold_now() mmc_retune_release()") new for v3. > > - ("brcmfmac: sdio: Don't tune while the card is off") new for v3. > > > > Changes in v2: > > - A full revert, not just a partial one (Arend). ...with explicit Cc. > > - Updated commit message to clarify based on discussion of v1. > > > > Douglas Anderson (5): > > Revert "brcmfmac: disable command decode in sdio_aos" > > mmc: core: API to temporarily disable retuning for SDIO CRC errors > > brcmfmac: sdio: Disable auto-tuning around commands expected to fail > > mmc: core: Add sdio_retune_hold_now() and sdio_retune_release() > > brcmfmac: sdio: Don't tune while the card is off > > > > drivers/mmc/core/core.c | 5 +- > > drivers/mmc/core/sdio_io.c | 77 +++++++++++++++++++ > > .../broadcom/brcm80211/brcmfmac/sdio.c | 17 ++-- > > include/linux/mmc/host.h | 1 + > > include/linux/mmc/sdio_func.h | 6 ++ > > 5 files changed, 99 insertions(+), 7 deletions(-) > > > > -- > > 2.22.0.410.gd8fdbe21b5-goog > > > > Applied for fixes, thanks! > > Some minor changes: > 1) Dropped the a few "commit notes", that was more related to version > and practical information about the series. > 2) Dropped fixes tags for patch 2->5, but instead put a stable tag > targeted for v4.18+. OK, sounds good. Thanks! :-) I guess when I see the # v4.18+ in the commit message it makes me believe that the problem only existed on 4.18+, but maybe that's just me reading too much into it. ;-) In any case, presumably anyone who had these problems on earlier kernels already has solved them with local patches. -Doug