| Message ID | 1542007730-47284-9-git-send-email-chi-hsien.lin@cypress.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Kalle Valo |
| Headers | show |
| Series | brcmfmac: chip related changes | expand |
On 11/12/2018 8:30 AM, Chi-Hsien Lin wrote: > From: Wright Feng <wright.feng@cypress.com> > > AOS is a part of the SDIOD core that becomes active when the rest of > SDIOD is sleeping to keep SDIO bus alive responding to reduced set of > commands. > > Transaction between AOS and SDIOD is not protected, and if cmd 52 is > received in AOS and in the middle of response state changed from AOS to > SDIOD, response is corrupted and it causes to SDIO Host controller to > hang. > > Command decode for below chips are disabled in this commit: > - 4339 > - 4345 > - 4354 > - 4373 Already have my review tag so this is fine as is. > Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> > Signed-off-by: Wright Feng <wright.feng@cypress.com> > Signed-off-by: Double Lo <double.lo@cypress.com> > Signed-off-by: Madhan Mohan R <madhanmohan.r@cypress.com> > Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> > --- > drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-)
On 11/12/2018 8:30 AM, Chi-Hsien Lin wrote: > From: Wright Feng <wright.feng@cypress.com> > > AOS is a part of the SDIOD core that becomes active when the rest of > SDIOD is sleeping to keep SDIO bus alive responding to reduced set of > commands. > > Transaction between AOS and SDIOD is not protected, and if cmd 52 is > received in AOS and in the middle of response state changed from AOS to > SDIOD, response is corrupted and it causes to SDIO Host controller to > hang. Just one question. The above sound pretty generic so does it apply to any SDIO chip with AOS logic? Regards, Arend
On 2018/11/12 下午 06:33, Arend van Spriel wrote: > On 11/12/2018 8:30 AM, Chi-Hsien Lin wrote: >> From: Wright Feng <wright.feng@cypress.com> >> >> AOS is a part of the SDIOD core that becomes active when the rest of >> SDIOD is sleeping to keep SDIO bus alive responding to reduced set of >> commands. >> >> Transaction between AOS and SDIOD is not protected, and if cmd 52 is >> received in AOS and in the middle of response state changed from AOS to >> SDIOD, response is corrupted and it causes to SDIO Host controller to >> hang. > > Just one question. The above sound pretty generic so does it apply to > any SDIO chip with AOS logic? > We found this issue when verifying SR feature with some SDIO cards(what we had), not sure whether every SDIO card has same problem. So we only change those chip's wake-up mechanism to noCmdDecode mode and let SDIOD_AOS just generates a wake-up request without responding. -Wright > Regards, > Arend > > >
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c index e1708e297d07..e5f487b37c5a 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c @@ -3354,7 +3354,11 @@ static int brcmf_sdio_download_firmware(struct brcmf_sdio *bus, static bool brcmf_sdio_aos_no_decode(struct brcmf_sdio *bus) { - if (bus->ci->chip == CY_CC_43012_CHIP_ID) + if (bus->ci->chip == CY_CC_43012_CHIP_ID || + bus->ci->chip == CY_CC_4373_CHIP_ID || + bus->ci->chip == BRCM_CC_4339_CHIP_ID || + bus->ci->chip == BRCM_CC_4345_CHIP_ID || + bus->ci->chip == BRCM_CC_4354_CHIP_ID) return true; else return false;