From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 May 2015 23:41:04 +0200 (CEST) Received: from mail-gw2-out.broadcom.com ([216.31.210.63]:31007 "EHLO mail-gw2-out.broadcom.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S27007717AbbE2VlCeykVy (ORCPT ); Fri, 29 May 2015 23:41:02 +0200 X-IronPort-AV: E=Sophos;i="5.13,519,1427785200"; d="scan'208";a="66170919" Received: from irvexchcas08.broadcom.com (HELO IRVEXCHCAS08.corp.ad.broadcom.com) ([10.9.208.57]) by mail-gw2-out.broadcom.com with ESMTP; 29 May 2015 14:52:17 -0700 Received: from IRVEXCHSMTP2.corp.ad.broadcom.com (10.9.207.52) by IRVEXCHCAS08.corp.ad.broadcom.com (10.9.208.57) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 29 May 2015 14:40:51 -0700 Received: from mail-sj1-12.sj.broadcom.com (10.10.10.20) by IRVEXCHSMTP2.corp.ad.broadcom.com (10.9.207.52) with Microsoft SMTP Server id 14.3.235.1; Fri, 29 May 2015 14:40:51 -0700 Received: from [10.176.128.60] (xl-bun-02.bun.broadcom.com [10.176.128.60]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 6FE7D27A82; Fri, 29 May 2015 14:40:51 -0700 (PDT) Message-ID: <5568DCE2.1060206@broadcom.com> Date: Fri, 29 May 2015 23:40:50 +0200 From: Arend van Spriel User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.24) Gecko/20111103 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: Hauke Mehrtens CC: Subject: Re: [PATCH V2] mips: bcm47xx: allow retrieval of complete nvram contents References: <1432214843-16057-1-git-send-email-arend@broadcom.com> <55687EDA.9070909@hauke-m.de> <55689A67.9070904@broadcom.com> <5568AF66.3070403@broadcom.com> <5568B391.6050402@hauke-m.de> <5568B969.6020502@broadcom.com> <5568BCD9.8090002@hauke-m.de> In-Reply-To: <5568BCD9.8090002@hauke-m.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 47734 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: arend@broadcom.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips On 05/29/15 21:24, Hauke Mehrtens wrote: > > > On 05/29/2015 09:09 PM, Arend van Spriel wrote: >> On 05/29/15 20:44, Hauke Mehrtens wrote: >>> >>> >>> On 05/29/2015 08:26 PM, Arend van Spriel wrote: >>>> On 05/29/15 18:57, Arend van Spriel wrote: >>>>> On 05/29/15 16:59, Hauke Mehrtens wrote: >>>>>> >>>>>> >>>>>> On 05/21/2015 03:27 PM, Arend van Spriel wrote: >>>>>>> From: Hante Meuleman >>>>>>> >>>>>>> Host platforms such as routers supported by OpenWrt can >>>>>>> support NVRAM reading directly from internal NVRAM store. >>>>>>> The brcmfmac for one requires the complete nvram contents >>>>>>> to select what needs to be sent to wireless device. >>>>>>> >>>>>>> Reviewed-by: Arend Van Spriel >>>>>>> Reviewed-by: Franky (Zhenhui) Lin >>>>>>> Reviewed-by: Pieter-Paul Giesberts >>>>>>> Reviewed-by: Daniel (Deognyoun) Kim >>>>>>> Signed-off-by: Hante Meuleman >>>>>>> Signed-off-by: Arend van Spriel >>>>>>> --- >>>>>>> Change log: >>>>>>> ----------- >>>>>>> V2: - correct header length for nvram_find_and_copy(). >>>>>>> - get rid of 'NVRAM_SPACE - 2' magic. >>>>>>> --- >>>>>>> arch/mips/bcm47xx/nvram.c | 61 >>>>>>> ++++++++++++++++++++++++++++++++----------- >>>>>>> include/linux/bcm47xx_nvram.h | 15 +++++++++++ >>>>>>> 2 files changed, 61 insertions(+), 15 deletions(-) >>>>>>> >>>>>>> diff --git a/arch/mips/bcm47xx/nvram.c b/arch/mips/bcm47xx/nvram.c >>>>>>> index 95d028c..f4f62d3 100644 >>>>>>> --- a/arch/mips/bcm47xx/nvram.c >>>>>>> +++ b/arch/mips/bcm47xx/nvram.c >>>>>>> @@ -94,17 +94,22 @@ static int nvram_find_and_copy(void __iomem >>>>>>> *iobase, u32 lim) >>>>>>> return -ENXIO; >>>>>>> >>>>>>> found: >>>>>>> - if (header->len> size) >>>>>>> - pr_err("The nvram size accoridng to the header seems to be bigger >>>>>>> than the partition on flash\n"); >>>>>>> - if (header->len> NVRAM_SPACE) >>>>>>> - pr_err("nvram on flash (%i bytes) is bigger than the reserved space >>>>>>> in memory, will just copy the first %i bytes\n", >>>>>>> - header->len, NVRAM_SPACE - 1); >>>>>>> - >>>>>>> src = (u32 *)header; >>>>>>> dst = (u32 *)nvram_buf; >>>>>>> for (i = 0; i< sizeof(struct nvram_header); i += 4) >>>>>>> *dst++ = __raw_readl(src++); >>>>>>> - for (; i< header->len&& i< NVRAM_SPACE&& i< size; i += 4) >>>>>>> + header = (struct nvram_header *)nvram_buf; >>>>>>> + if (header->len> size) { >>>>>>> + pr_err("The nvram size according to the header seems to be bigger >>>>>>> than the partition on flash\n"); >>>>>> >>>>>> Thanks for fixing a typo. ;-) >>>>>> >>>>>>> + header->len = size; >>>>>> >>>>>> I haven't seen this error case, I just added it to be save. >>>>> >>>>> It does seem an unlikely error case. At least it would probably been >>>>> noticed during production writing the content to flash. >>>>> >>>>>>> + } >>>>>>> + if (header->len>= NVRAM_SPACE) { >>>>>>> + pr_err("nvram on flash (%i bytes) is bigger than the reserved space >>>>>>> in memory, will just copy the first %i bytes\n", >>>>>>> + header->len, NVRAM_SPACE - 1); >>>>>>> + header->len = NVRAM_SPACE - 1; >>>>>>> + } >>>>>> >>>>>> After fixing the length the header is better, but it also contains a >>>>>> CRC, which is still wrong, but we ignore it and I do not think we have >>>>>> to check. >>>>>> >>>>>> I still think that the best approach would be to remove the nvram >>>>>> header >>>>>> and add a extra variable storing the actual size of the nvram buf. I >>>>>> also think this would make some of this code easier. >>>>> >>>>> Let's do that then. >>>> >>>> Hi Hauke, >>>> >>>> Forgot to ask. What is the reason for using the fixed nvram space. Could >>>> we allocate it using vzalloc()? >>> >>> On mips this is needed very early in the boot process at least for the >>> older SoCs using ssb. In this state we can not allocate memory. >> >> I suspected that, but wanted to be sure. >> > > We tried to use some kind of allocation mechanism, because the nvram > partitions of different devices have different sizes. The older devices > mostly have small partitions and the newer ons bigger. With the arm SoCs > we do not need the nvram so early and can use some normal allocation > mechanism. Yes, but that means that static buffer sits there doing nothing or could that be put under Kconfig and only be used for the devices needing early access. Regards, Arend From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-gw2-out.broadcom.com ([216.31.210.63]:31007 "EHLO mail-gw2-out.broadcom.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S27007717AbbE2VlCeykVy (ORCPT ); Fri, 29 May 2015 23:41:02 +0200 Message-ID: <5568DCE2.1060206@broadcom.com> Date: Fri, 29 May 2015 23:40:50 +0200 From: Arend van Spriel MIME-Version: 1.0 Subject: Re: [PATCH V2] mips: bcm47xx: allow retrieval of complete nvram contents References: <1432214843-16057-1-git-send-email-arend@broadcom.com> <55687EDA.9070909@hauke-m.de> <55689A67.9070904@broadcom.com> <5568AF66.3070403@broadcom.com> <5568B391.6050402@hauke-m.de> <5568B969.6020502@broadcom.com> <5568BCD9.8090002@hauke-m.de> In-Reply-To: <5568BCD9.8090002@hauke-m.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: Hauke Mehrtens Cc: linux-mips@linux-mips.org Message-ID: <20150529214050.T6DUoxjouMyKI8mNRwObc_GPXl2DRL0EtcDARLZnCFY@z> On 05/29/15 21:24, Hauke Mehrtens wrote: > > > On 05/29/2015 09:09 PM, Arend van Spriel wrote: >> On 05/29/15 20:44, Hauke Mehrtens wrote: >>> >>> >>> On 05/29/2015 08:26 PM, Arend van Spriel wrote: >>>> On 05/29/15 18:57, Arend van Spriel wrote: >>>>> On 05/29/15 16:59, Hauke Mehrtens wrote: >>>>>> >>>>>> >>>>>> On 05/21/2015 03:27 PM, Arend van Spriel wrote: >>>>>>> From: Hante Meuleman >>>>>>> >>>>>>> Host platforms such as routers supported by OpenWrt can >>>>>>> support NVRAM reading directly from internal NVRAM store. >>>>>>> The brcmfmac for one requires the complete nvram contents >>>>>>> to select what needs to be sent to wireless device. >>>>>>> >>>>>>> Reviewed-by: Arend Van Spriel >>>>>>> Reviewed-by: Franky (Zhenhui) Lin >>>>>>> Reviewed-by: Pieter-Paul Giesberts >>>>>>> Reviewed-by: Daniel (Deognyoun) Kim >>>>>>> Signed-off-by: Hante Meuleman >>>>>>> Signed-off-by: Arend van Spriel >>>>>>> --- >>>>>>> Change log: >>>>>>> ----------- >>>>>>> V2: - correct header length for nvram_find_and_copy(). >>>>>>> - get rid of 'NVRAM_SPACE - 2' magic. >>>>>>> --- >>>>>>> arch/mips/bcm47xx/nvram.c | 61 >>>>>>> ++++++++++++++++++++++++++++++++----------- >>>>>>> include/linux/bcm47xx_nvram.h | 15 +++++++++++ >>>>>>> 2 files changed, 61 insertions(+), 15 deletions(-) >>>>>>> >>>>>>> diff --git a/arch/mips/bcm47xx/nvram.c b/arch/mips/bcm47xx/nvram.c >>>>>>> index 95d028c..f4f62d3 100644 >>>>>>> --- a/arch/mips/bcm47xx/nvram.c >>>>>>> +++ b/arch/mips/bcm47xx/nvram.c >>>>>>> @@ -94,17 +94,22 @@ static int nvram_find_and_copy(void __iomem >>>>>>> *iobase, u32 lim) >>>>>>> return -ENXIO; >>>>>>> >>>>>>> found: >>>>>>> - if (header->len> size) >>>>>>> - pr_err("The nvram size accoridng to the header seems to be bigger >>>>>>> than the partition on flash\n"); >>>>>>> - if (header->len> NVRAM_SPACE) >>>>>>> - pr_err("nvram on flash (%i bytes) is bigger than the reserved space >>>>>>> in memory, will just copy the first %i bytes\n", >>>>>>> - header->len, NVRAM_SPACE - 1); >>>>>>> - >>>>>>> src = (u32 *)header; >>>>>>> dst = (u32 *)nvram_buf; >>>>>>> for (i = 0; i< sizeof(struct nvram_header); i += 4) >>>>>>> *dst++ = __raw_readl(src++); >>>>>>> - for (; i< header->len&& i< NVRAM_SPACE&& i< size; i += 4) >>>>>>> + header = (struct nvram_header *)nvram_buf; >>>>>>> + if (header->len> size) { >>>>>>> + pr_err("The nvram size according to the header seems to be bigger >>>>>>> than the partition on flash\n"); >>>>>> >>>>>> Thanks for fixing a typo. ;-) >>>>>> >>>>>>> + header->len = size; >>>>>> >>>>>> I haven't seen this error case, I just added it to be save. >>>>> >>>>> It does seem an unlikely error case. At least it would probably been >>>>> noticed during production writing the content to flash. >>>>> >>>>>>> + } >>>>>>> + if (header->len>= NVRAM_SPACE) { >>>>>>> + pr_err("nvram on flash (%i bytes) is bigger than the reserved space >>>>>>> in memory, will just copy the first %i bytes\n", >>>>>>> + header->len, NVRAM_SPACE - 1); >>>>>>> + header->len = NVRAM_SPACE - 1; >>>>>>> + } >>>>>> >>>>>> After fixing the length the header is better, but it also contains a >>>>>> CRC, which is still wrong, but we ignore it and I do not think we have >>>>>> to check. >>>>>> >>>>>> I still think that the best approach would be to remove the nvram >>>>>> header >>>>>> and add a extra variable storing the actual size of the nvram buf. I >>>>>> also think this would make some of this code easier. >>>>> >>>>> Let's do that then. >>>> >>>> Hi Hauke, >>>> >>>> Forgot to ask. What is the reason for using the fixed nvram space. Could >>>> we allocate it using vzalloc()? >>> >>> On mips this is needed very early in the boot process at least for the >>> older SoCs using ssb. In this state we can not allocate memory. >> >> I suspected that, but wanted to be sure. >> > > We tried to use some kind of allocation mechanism, because the nvram > partitions of different devices have different sizes. The older devices > mostly have small partitions and the newer ons bigger. With the arm SoCs > we do not need the nvram so early and can use some normal allocation > mechanism. Yes, but that means that static buffer sits there doing nothing or could that be put under Kconfig and only be used for the devices needing early access. Regards, Arend