Date:   Thu, 31 Jan 2019 18:26:48 -0800
From:   Brian Norris <briannorris@chromium.org>
To:     yhchuang@realtek.com
Cc:     kvalo@codeaurora.org, Larry.Finger@lwfinger.net,
        tehuang@realtek.com, sgruszka@redhat.com,
        linux-wireless@vger.kernel.org
Subject: Re: [PATCH 07/24] rtw88: 8822c: update efuse table as released
Message-ID: <20190201022647.GA125494@google.com>
References: <1548937297-14660-1-git-send-email-yhchuang@realtek.com>
 <1548937297-14660-8-git-send-email-yhchuang@realtek.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1548937297-14660-8-git-send-email-yhchuang@realtek.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Hi,

On Thu, Jan 31, 2019 at 08:21:20PM +0800, yhchuang@realtek.com wrote:
> From: Yan-Hsuan Chuang <yhchuang@realtek.com>
> 
> Update efuse table layout as the document released.
> From the newest released document, 8822c has RFE type 1 and type 2.
> Without adding RFE 1 and 2 the user's efuse-programed chips will failed
> to pass the chip info check and cannot power on hardware.
> And 8822c has only 512 bytes for physical efuse.
> 
> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
> ---
>  drivers/net/wireless/realtek/rtw88/rtw8822c.c | 12 ++----
>  drivers/net/wireless/realtek/rtw88/rtw8822c.h | 53 ++++++++++++++-------------
>  2 files changed, 31 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/rtw8822c.c b/drivers/net/wireless/realtek/rtw88/rtw8822c.c
> index 71f2af0..5c06e32 100644
> --- a/drivers/net/wireless/realtek/rtw88/rtw8822c.c
> +++ b/drivers/net/wireless/realtek/rtw88/rtw8822c.c

> @@ -1137,7 +1133,7 @@ struct rtw_chip_info rtw8822c_hw_spec = {
>  	.tx_buf_desc_sz = 16,
>  	.rx_pkt_desc_sz = 24,
>  	.rx_buf_desc_sz = 8,
> -	.phy_efuse_size = 1024,
> +	.phy_efuse_size = 512,

I realized that technically, I'm blaming your memory errors (writing
past the phy efuse buffer) on the original patchset, when you really
create the error here, when you shrink phy_efuse_size.

Regardless, the original series should be fixed to do better bounds
checking or to stop accessing a fixed value beyond 512 anyway.

Brian

>  	.log_efuse_size = 768,
>  	.ptct_efuse_size = 124,
>  	.txff_size = 262144,