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
| ||
|
Date: Fri, 07 Jun 2019 07:12:42 +0200 From: Arend Van Spriel <arend.vanspriel@...adcom.com> To: Doug Anderson <dianders@...omium.org>, Adrian Hunter <adrian.hunter@...el.com> 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 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. So I want to disable device sleep and trigger retuning through debugfs or some other hack. Regards, Arend
Powered by blists - more mailing lists