Subject: Re: [PATCH wireless-drivers-next] brcmfmac: add basic validation of
 shared RAM address
To:     =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= <zajec5@gmail.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>
References: <20190220103047.8960-1-zajec5@gmail.com>
 <CACna6rwwDN6svzWMGbxYXDp5CN8C=A=fV224QcfoLcACQQgLDA@mail.gmail.com>
 <92e8bf1e-3be9-96f2-93e9-ac504a609929@broadcom.com>
 <CACna6rxXJWwysJTauSKAb6rLeaXi1CBZSGcFNA5Nxn0ncQnG4Q@mail.gmail.com>
From:   Arend Van Spriel <arend.vanspriel@broadcom.com>
Message-ID: <48bb6db6-31c0-65e6-551f-69bbd056df93@broadcom.com>
Date:   Thu, 21 Feb 2019 11:30:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <CACna6rxXJWwysJTauSKAb6rLeaXi1CBZSGcFNA5Nxn0ncQnG4Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On 2/21/2019 10:27 AM, Rafał Miłecki wrote:
> On Thu, 21 Feb 2019 at 09:59, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 2/21/2019 9:01 AM, Rafał Miłecki wrote:
>>> On Wed, 20 Feb 2019 at 11:31, Rafał Miłecki <zajec5@gmail.com> wrote:
>>>> From: Rafał Miłecki <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 address cd680001
>>>> due to reading out of the mapped memory.
>>>>
>>>> This patch adds some basic validation to avoid kernel crashes due to the
>>>> 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ł
>>
>> 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 ;)

Did not check what that function exactly does, but could be expected.

> 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.

Ah. Can only wish you happy hacking then ;-)

Gr. AvS