MIME-Version: 1.0
References: <20190220103047.8960-1-zajec5@gmail.com> <CACna6rwwDN6svzWMGbxYXDp5CN8C=A=fV224QcfoLcACQQgLDA@mail.gmail.com>
 <92e8bf1e-3be9-96f2-93e9-ac504a609929@broadcom.com>
In-Reply-To: <92e8bf1e-3be9-96f2-93e9-ac504a609929@broadcom.com>
From:   =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= <zajec5@gmail.com>
Date:   Thu, 21 Feb 2019 10:27:53 +0100
Message-ID: <CACna6rxXJWwysJTauSKAb6rLeaXi1CBZSGcFNA5Nxn0ncQnG4Q@mail.gmail.com>
Subject: Re: [PATCH wireless-drivers-next] brcmfmac: add basic validation of
 shared RAM address
To:     Arend Van Spriel <arend.vanspriel@broadcom.com>
Cc:     Kalle Valo <kvalo@codeaurora.org>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
        "open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER" 
        <brcm80211-dev-list.pdl@broadcom.com>,
        "open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
        <brcm80211-dev-list.pdl@broadcom.com>," 
        <brcm80211-dev-list@cypress.com>,
        =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= <rafal@milecki.pl>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Thu, 21 Feb 2019 at 09:59, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 2/21/2019 9:01 AM, Rafa=C5=82 Mi=C5=82ecki wrote:
> > On Wed, 20 Feb 2019 at 11:31, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com=
> wrote:
> >> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
> >>
> >> While experimenting with firmware loading I ended up in a state of
> >> firmware reporting shared RAM address 0x04000001. It was causing:
> >> [   94.448015] Unable to handle kernel paging request at virtual addre=
ss cd680001
> >> due to reading out of the mapped memory.
> >>
> >> This patch adds some basic validation to avoid kernel crashes due to t=
he
> >> unexpected firmware behavior.
> >
> > For a reference for the further hackers. That has been caused by a
> > BCMA_CORE_SYS_MEM core on my BCM4366/4 not being up.
>
> Thanks, Rafa=C5=82
>
> Does that happen all the time or in some specific scenario. Anyway, it
> seems like we need to add a check in brcmf_chip_sysmem_ramsize() and
> bringup the core if needed. Although, I am curious in what the state the
> other cores are at that time. Might need a chip-wide reset.

It happens after brcmf_pcie_reset_device() which is probably a 100%
expected case ;)

Normally brcmfmac does not call brcmf_pcie_reset_device() between
brcmf_chip_sysmem_ramsize() and the brcmf_pcie_download_fw_nvram() so
it was only my hacking that caused that issue for me.

--=20
Rafa=C5=82