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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 20 May 2019 10:09:39 +0200 From: Arend Van Spriel <arend.vanspriel@...adcom.com> To: Douglas Anderson <dianders@...omium.org>, Ulf Hansson <ulf.hansson@...aro.org>, Kalle Valo <kvalo@...eaurora.org>, Adrian Hunter <adrian.hunter@...el.com> Cc: linux-rockchip@...ts.infradead.org, Double Lo <double.lo@...ress.com>, briannorris@...omium.org, Madhan Mohan R <madhanmohan.r@...ress.com>, mka@...omium.org, Wright Feng <wright.feng@...ress.com>, Chi-Hsien Lin <chi-hsien.lin@...ress.com>, brcm80211-dev-list.pdl@...adcom.com, Franky Lin <franky.lin@...adcom.com>, netdev@...r.kernel.org, linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org, Hante Meuleman <hante.meuleman@...adcom.com>, Naveen Gupta <naveen.gupta@...ress.com>, brcm80211-dev-list@...ress.com, YueHaibing <yuehaibing@...wei.com>, "David S. Miller" <davem@...emloft.net> Subject: Re: [PATCH 1/3] brcmfmac: re-enable command decode in sdio_aos for BRCM 4354 On 5/18/2019 12:54 AM, Douglas Anderson wrote: > In commit 29f6589140a1 ("brcmfmac: disable command decode in > sdio_aos") we disabled something called "command decode in sdio_aos" > for a whole bunch of Broadcom SDIO WiFi parts. > > After that patch landed I find that my kernel log on > rk3288-veyron-minnie and rk3288-veyron-speedy is filled with: > brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110 > > This seems to happen every time the Broadcom WiFi transitions out of > sleep mode. Reverting the part of the commit that affects the WiFi on > my boards fixes the problem for me, so that's what this patch does. This sounds very similar to the issue we had during integration of wifi on rk3288 chromebooks years ago. > Note that, in general, the justification in the original commit seemed > a little weak. It looked like someone was testing on a SD card > controller that would sometimes die if there were CRC errors on the > bus. This used to happen back in early days of dw_mmc (the controller > on my boards), but we fixed it. Disabling a feature on all boards > just because one SD card controller is broken seems bad. ...so > instead of just this patch possibly the right thing to do is to fully > revert the original commit. I am leaning towards a full revert, but let's wait for more background info. Regards, Arend
Powered by blists - more mailing lists