linux-kernel - Re: [PATCH v2 3/3] brcmfmac: sdio: Disable auto-tuning around commands expected to fail

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ff0e7b7a-6a58-8bec-b182-944a8b64236d@intel.com>
Date:   Fri, 7 Jun 2019 15:38:43 +0300
From:   Adrian Hunter <adrian.hunter@...el.com>
To:     Arend Van Spriel <arend.vanspriel@...adcom.com>,
        Doug Anderson <dianders@...omium.org>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        Kalle Valo <kvalo@...eaurora.org>,
        brcm80211-dev-list.pdl@...adcom.com,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Double Lo <double.lo@...ress.com>,
        Brian Norris <briannorris@...omium.org>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        Naveen Gupta <naveen.gupta@...ress.com>,
        Madhan Mohan R <madhanmohan.r@...ress.com>,
        Matthias Kaehlcke <mka@...omium.org>,
        Wright Feng <wright.feng@...ress.com>,
        Chi-Hsien Lin <chi-hsien.lin@...ress.com>,
        netdev <netdev@...r.kernel.org>,
        brcm80211-dev-list <brcm80211-dev-list@...ress.com>,
        "David S. Miller" <davem@...emloft.net>,
        Franky Lin <franky.lin@...adcom.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        YueHaibing <yuehaibing@...wei.com>,
        Michael Trimarchi <michael@...rulasolutions.com>
Subject: Re: [PATCH v2 3/3] brcmfmac: sdio: Disable auto-tuning around
 commands expected to fail

On 7/06/19 8:12 AM, Arend Van Spriel wrote:
> On June 6, 2019 11:37:22 PM Doug Anderson <dianders@...omium.org> wrote:
>>
>> In the case of dw_mmc, which I'm most familiar with, we don't have any
>> sort of automated or timed-based retuning.  ...so we'll only re-tune
>> when we see the CRC error.  If I'm understanding things correctly then
>> that for dw_mmc my solution and yours behave the same.  That means the
>> difference is how we deal with other retuning requests, either ones
>> that come about because of an interrupt that the host controller
>> provided or because of a timer.  Did I get that right?
> 
> Right.
> 
>> ...and I guess the reason we have to deal specially with these cases
>> is because any time that SDIO card is "sleeping" we don't want to
>> retune because it won't work.  Right?  NOTE: the solution that would
>> come to my mind first to solve this would be to hold the retuning for
>> the whole time that the card was sleeping and then release it once the
>> card was awake again.  ...but I guess we don't truly need to do that
>> because tuning only happens as a side effect of sending a command to
>> the card and the only command we send to the card is the "wake up"
>> command.  That's why your solution to hold tuning while sending the
>> "wake up" command works, right?
> 
> Yup.
> 
>> ---
>>
>> OK, so assuming all the above is correct, I feel like we're actually
>> solving two problems and in fact I believe we actually need both our
>> approaches to solve everything correctly.  With just your patch in
>> place there's a problem because we will clobber any external retuning
>> requests that happened while we were waking up the card.  AKA, imagine
>> this:
>>
>> A) brcmf_sdio_kso_control(on=True) gets called; need_retune starts as 0
>>
>> B) We call sdio_retune_hold_now()
>>
>> C) A retuning timer goes off or the SD Host controller tells us to retune
>>
>> D) We get to the end of brcmf_sdio_kso_control() and clear the "retune
>> needed" since need_retune was 0 at the start.
>>
>> ...so we dropped the retuning request from C), right?
>>
>>
>> What we truly need is:
>>
>> 1. CRC errors shouldn't trigger a retuning request when we're in
>> brcmf_sdio_kso_control()
>>
>> 2. A separate patch that holds any retuning requests while the SDIO
>> card is off.  This patch _shouldn't_ do any clearing of retuning
>> requests, just defer them.
>>
>>
>> Does that make sense to you?  If so, I can try to code it up...
> 
> FWIW it does make sense to me. However, I am still not sure if our sdio
> hardware supports retuning. Have to track down an asic designer who can tell
> or dive into vhdl myself.

The card supports re-tuning if is handles CMD19, which it does.  It is not
the card that does any tuning, only the host.  The card just helps by
providing a known data pattern in response to CMD19.  It can be that a card
provides good enough signals that the host should not need to re-tune.  I
don't know if that can be affected by the board design though.