From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arend Van Spriel Subject: Re: [PATCH 1/3] brcmfmac: re-enable command decode in sdio_aos for BRCM 4354 Date: Mon, 20 May 2019 10:09:39 +0200 Message-ID: References: <20190517225420.176893-1-dianders@chromium.org> <20190517225420.176893-2-dianders@chromium.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20190517225420.176893-2-dianders@chromium.org> Content-Language: en-US Sender: netdev-owner@vger.kernel.org To: Douglas Anderson , Ulf Hansson , Kalle Valo , Adrian Hunter Cc: linux-rockchip@lists.infradead.org, Double Lo , briannorris@chromium.org, Madhan Mohan R , mka@chromium.org, Wright Feng , Chi-Hsien Lin , brcm80211-dev-list.pdl@broadcom.com, Franky Lin , netdev@vger.kernel.org, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, Hante Meuleman , Naveen Gupta , brcm80211-dev-list@cypress.com, YueHaibing , "David S. Miller" List-Id: linux-rockchip.vger.kernel.org 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