All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Zhang <william.zhang@broadcom.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Broadcom Kernel List <bcm-kernel-feedback-list@broadcom.com>,
	Linux MTD List <linux-mtd@lists.infradead.org>,
	f.fainelli@gmail.com, rafal@milecki.pl, kursad.oney@broadcom.com,
	joel.peshkin@broadcom.com, computersforpeace@gmail.com,
	anand.gore@broadcom.com, dregan@mail.com,
	kamal.dasu@broadcom.com, tomer.yacoby@broadcom.com,
	dan.beygelman@broadcom.com,
	Frieder Schrempf <frieder.schrempf@kontron.de>,
	linux-kernel@vger.kernel.org,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Richard Weinberger <richard@nod.at>,
	Boris Brezillon <bbrezillon@kernel.org>,
	Kamal Dasu <kdasu.kdev@gmail.com>
Subject: Re: [PATCH v3 5/5] mtd: rawnand: brcmnand: Fix mtd oobsize
Date: Tue, 4 Jul 2023 17:50:28 -0700	[thread overview]
Message-ID: <c09a72df-c49f-75e9-e95e-4e19fe10a278@broadcom.com> (raw)
In-Reply-To: <20230704173047.395e445e@xps-13>


[-- Attachment #1.1: Type: text/plain, Size: 3130 bytes --]

Hi Miquel,

On 07/04/2023 08:30 AM, Miquel Raynal wrote:
> Hi William,
> 
> william.zhang@broadcom.com wrote on Tue, 27 Jun 2023 12:37:38 -0700:
> 
>> brcmnand controller can only access the flash spare area up to certain
>> bytes based on the ECC level. It can be less than the actual flash spare
>> area size. For example, for many NAND chip supporting ECC BCH-8, it has
>> 226 bytes spare area. But controller can only uses 218 bytes. So brcmand
>> driver overrides the mtd oobsize with the controller's accessible spare
>> area size. When the nand base driver utilizes the nand_device object, it
>> resets the oobsize back to the actual flash spare aprea size from
>> nand_memory_organization structure and controller may not able to access
>> all the oob area as mtd advises.
>>
>> This change fixes the issue by overriding the oobsize in the
>> nand_memory_organization structure to the controller's accessible spare
>> area size.
> 
> I am clearly not a big fan of this solution. memorg should be and
> remain a read only object. Can you please find another solution?
> 
I was debating on this too but I don't see option because there is no 
other hooks after nanddev_init to set the mtd->oobsize as far as I can 
see and I see there were similar fixes for other controller drivers 
after the nand device object init was committed, for example:
Fixes: 629a442cad5f ("mtd: rawnand: Fill memorg during detection")

I will think through this again but I am open to any suggestion.

>>
>> Fixes: a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object")
>> Signed-off-by: William Zhang <william.zhang@broadcom.com>
>>
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>>   drivers/mtd/nand/raw/brcmnand/brcmnand.c | 7 +++++--
>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
>> index 407bf79cbaf4..39c7f547db1f 100644
>> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
>> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
>> @@ -2647,6 +2647,8 @@ static int brcmnand_setup_dev(struct brcmnand_host *host)
>>   	struct nand_chip *chip = &host->chip;
>>   	const struct nand_ecc_props *requirements =
>>   		nanddev_get_ecc_requirements(&chip->base);
>> +	struct nand_memory_organization *memorg =
>> +		nanddev_get_memorg(&chip->base);
>>   	struct brcmnand_controller *ctrl = host->ctrl;
>>   	struct brcmnand_cfg *cfg = &host->hwcfg;
>>   	char msg[128];
>> @@ -2668,10 +2670,11 @@ static int brcmnand_setup_dev(struct brcmnand_host *host)
>>   	if (cfg->spare_area_size > ctrl->max_oob)
>>   		cfg->spare_area_size = ctrl->max_oob;
>>   	/*
>> -	 * Set oobsize to be consistent with controller's spare_area_size, as
>> -	 * the rest is inaccessible.
>> +	 * Set mtd and memorg oobsize to be consistent with controller's
>> +	 * spare_area_size, as the rest is inaccessible.
>>   	 */
>>   	mtd->oobsize = cfg->spare_area_size * (mtd->writesize >> FC_SHIFT);
>> +	memorg->oobsize = mtd->oobsize;
>>   
>>   	cfg->device_size = mtd->size;
>>   	cfg->block_size = mtd->erasesize;
> 
> 
> Thanks,
> Miquèl
> 

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4212 bytes --]

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: William Zhang <william.zhang@broadcom.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Broadcom Kernel List <bcm-kernel-feedback-list@broadcom.com>,
	Linux MTD List <linux-mtd@lists.infradead.org>,
	f.fainelli@gmail.com, rafal@milecki.pl, kursad.oney@broadcom.com,
	joel.peshkin@broadcom.com, computersforpeace@gmail.com,
	anand.gore@broadcom.com, dregan@mail.com,
	kamal.dasu@broadcom.com, tomer.yacoby@broadcom.com,
	dan.beygelman@broadcom.com,
	Frieder Schrempf <frieder.schrempf@kontron.de>,
	linux-kernel@vger.kernel.org,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Richard Weinberger <richard@nod.at>,
	Boris Brezillon <bbrezillon@kernel.org>,
	Kamal Dasu <kdasu.kdev@gmail.com>
Subject: Re: [PATCH v3 5/5] mtd: rawnand: brcmnand: Fix mtd oobsize
Date: Tue, 4 Jul 2023 17:50:28 -0700	[thread overview]
Message-ID: <c09a72df-c49f-75e9-e95e-4e19fe10a278@broadcom.com> (raw)
In-Reply-To: <20230704173047.395e445e@xps-13>

[-- Attachment #1: Type: text/plain, Size: 3130 bytes --]

Hi Miquel,

On 07/04/2023 08:30 AM, Miquel Raynal wrote:
> Hi William,
> 
> william.zhang@broadcom.com wrote on Tue, 27 Jun 2023 12:37:38 -0700:
> 
>> brcmnand controller can only access the flash spare area up to certain
>> bytes based on the ECC level. It can be less than the actual flash spare
>> area size. For example, for many NAND chip supporting ECC BCH-8, it has
>> 226 bytes spare area. But controller can only uses 218 bytes. So brcmand
>> driver overrides the mtd oobsize with the controller's accessible spare
>> area size. When the nand base driver utilizes the nand_device object, it
>> resets the oobsize back to the actual flash spare aprea size from
>> nand_memory_organization structure and controller may not able to access
>> all the oob area as mtd advises.
>>
>> This change fixes the issue by overriding the oobsize in the
>> nand_memory_organization structure to the controller's accessible spare
>> area size.
> 
> I am clearly not a big fan of this solution. memorg should be and
> remain a read only object. Can you please find another solution?
> 
I was debating on this too but I don't see option because there is no 
other hooks after nanddev_init to set the mtd->oobsize as far as I can 
see and I see there were similar fixes for other controller drivers 
after the nand device object init was committed, for example:
Fixes: 629a442cad5f ("mtd: rawnand: Fill memorg during detection")

I will think through this again but I am open to any suggestion.

>>
>> Fixes: a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object")
>> Signed-off-by: William Zhang <william.zhang@broadcom.com>
>>
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>>   drivers/mtd/nand/raw/brcmnand/brcmnand.c | 7 +++++--
>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
>> index 407bf79cbaf4..39c7f547db1f 100644
>> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
>> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
>> @@ -2647,6 +2647,8 @@ static int brcmnand_setup_dev(struct brcmnand_host *host)
>>   	struct nand_chip *chip = &host->chip;
>>   	const struct nand_ecc_props *requirements =
>>   		nanddev_get_ecc_requirements(&chip->base);
>> +	struct nand_memory_organization *memorg =
>> +		nanddev_get_memorg(&chip->base);
>>   	struct brcmnand_controller *ctrl = host->ctrl;
>>   	struct brcmnand_cfg *cfg = &host->hwcfg;
>>   	char msg[128];
>> @@ -2668,10 +2670,11 @@ static int brcmnand_setup_dev(struct brcmnand_host *host)
>>   	if (cfg->spare_area_size > ctrl->max_oob)
>>   		cfg->spare_area_size = ctrl->max_oob;
>>   	/*
>> -	 * Set oobsize to be consistent with controller's spare_area_size, as
>> -	 * the rest is inaccessible.
>> +	 * Set mtd and memorg oobsize to be consistent with controller's
>> +	 * spare_area_size, as the rest is inaccessible.
>>   	 */
>>   	mtd->oobsize = cfg->spare_area_size * (mtd->writesize >> FC_SHIFT);
>> +	memorg->oobsize = mtd->oobsize;
>>   
>>   	cfg->device_size = mtd->size;
>>   	cfg->block_size = mtd->erasesize;
> 
> 
> Thanks,
> Miquèl
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4212 bytes --]

  reply	other threads:[~2023-07-05  0:50 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-27 19:37 [PATCH v3 0/5] mtd: rawnand: brcmnand: driver and doc updates William Zhang
2023-06-27 19:37 ` William Zhang
2023-06-27 19:37 ` [PATCH v3 1/5] mtd: rawnand: brcmnand: Fix ECC level field setting for v7.2 controller William Zhang
2023-06-27 19:37   ` William Zhang
2023-07-04 15:18   ` Miquel Raynal
2023-07-04 15:18     ` Miquel Raynal
2023-06-27 19:37 ` [PATCH v3 2/5] mtd: rawnand: brcmnand: Fix potential false time out warning William Zhang
2023-06-27 19:37   ` William Zhang
2023-07-04 15:21   ` Miquel Raynal
2023-07-04 15:21     ` Miquel Raynal
2023-06-27 19:37 ` [PATCH v3 3/5] mtd: rawnand: brcmnand: Fix crash during the panic_write William Zhang
2023-06-27 19:37   ` William Zhang
2023-07-04 15:23   ` Miquel Raynal
2023-07-04 15:23     ` Miquel Raynal
2023-07-04 15:26   ` Miquel Raynal
2023-07-04 15:26     ` Miquel Raynal
2023-07-05  0:40     ` William Zhang
2023-07-05  0:40       ` William Zhang
2023-07-05  7:09       ` Miquel Raynal
2023-07-05  7:09         ` Miquel Raynal
2023-06-27 19:37 ` [PATCH v3 4/5] mtd: rawnand: brcmnand: Fix potential out-of-bounds access in oob write William Zhang
2023-06-27 19:37   ` William Zhang
2023-07-04 15:28   ` Miquel Raynal
2023-07-04 15:28     ` Miquel Raynal
2023-07-05  0:43     ` William Zhang
2023-07-05  0:43       ` William Zhang
2023-06-27 19:37 ` [PATCH v3 5/5] mtd: rawnand: brcmnand: Fix mtd oobsize William Zhang
2023-06-27 19:37   ` William Zhang
2023-07-04 15:30   ` Miquel Raynal
2023-07-04 15:30     ` Miquel Raynal
2023-07-05  0:50     ` William Zhang [this message]
2023-07-05  0:50       ` William Zhang
2023-07-05  7:11       ` Miquel Raynal
2023-07-05  7:11         ` Miquel Raynal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c09a72df-c49f-75e9-e95e-4e19fe10a278@broadcom.com \
    --to=william.zhang@broadcom.com \
    --cc=anand.gore@broadcom.com \
    --cc=bbrezillon@kernel.org \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=computersforpeace@gmail.com \
    --cc=dan.beygelman@broadcom.com \
    --cc=dregan@mail.com \
    --cc=f.fainelli@gmail.com \
    --cc=frieder.schrempf@kontron.de \
    --cc=joel.peshkin@broadcom.com \
    --cc=kamal.dasu@broadcom.com \
    --cc=kdasu.kdev@gmail.com \
    --cc=kursad.oney@broadcom.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=rafal@milecki.pl \
    --cc=richard@nod.at \
    --cc=tomer.yacoby@broadcom.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.