Re: [PATCH v2 1/4] mtd: rawnand: Add destructive operation

Re: [PATCH v2 1/4] mtd: rawnand: Add destructive operation

[Miquel Raynal]

Hello,

dregan@mail.com wrote on Thu, 12 Oct 2023 02:40:35 +0200:

The author should be Boris as well (git commit --amend --author=...)

> Erase and program operations need the write protect (wp) pin to be
> de-asserted to take effect. Add the concept of destructive
> operation and pass the information to exec_op() so controllers know
> when they should de-assert this pin without having to decode
> the command opcode.
> 
> Created by Boris Brezillon.

This can go away.

> 
> https://github.com/bbrezillon/linux/commit/e612e1f2c69a33ac5f2c91d13669f0f172d58717

This as well.

> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>

Please use Boris' kernel.org e-mail for the authorship and SoB

> Signed-off-by: David Regan <dregan@mail.com>
> 
> ---
> 
> Changes in v2: gave credit to Boris Brezillon
> ---
>  drivers/mtd/nand/raw/nand_base.c | 6 ++++--
>  include/linux/mtd/rawnand.h      | 9 +++++++++
>  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index d4b55155aeae..47cc2c35153b 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -1494,7 +1494,8 @@ static int nand_exec_prog_page_op(struct nand_chip *chip, unsigned int page,
>  			    NAND_COMMON_TIMING_NS(conf, tWB_max)),
>  		NAND_OP_WAIT_RDY(NAND_COMMON_TIMING_MS(conf, tPROG_max), 0),
>  	};
> -	struct nand_operation op = NAND_OPERATION(chip->cur_cs, instrs);
> +	struct nand_operation op = NAND_DESTRUCTIVE_OPERATION(chip->cur_cs,
> +							      instrs);
>  	int naddrs = nand_fill_column_cycles(chip, addrs, offset_in_page);
> 
>  	if (naddrs < 0)
> @@ -1917,7 +1918,8 @@ int nand_erase_op(struct nand_chip *chip, unsigned int eraseblock)
>  			NAND_OP_WAIT_RDY(NAND_COMMON_TIMING_MS(conf, tBERS_max),
>  					 0),
>  		};
> -		struct nand_operation op = NAND_OPERATION(chip->cur_cs, instrs);
> +		struct nand_operation op = NAND_DESTRUCTIVE_OPERATION(chip->cur_cs,
> +								      instrs);
> 
>  		if (chip->options & NAND_ROW_ADDR_3)
>  			instrs[1].ctx.addr.naddrs++;
> diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
> index 90a141ba2a5a..31aceda8616c 100644
> --- a/include/linux/mtd/rawnand.h
> +++ b/include/linux/mtd/rawnand.h
> @@ -1008,6 +1008,7 @@ struct nand_op_parser {
>   */
>  struct nand_operation {
>  	unsigned int cs;
> +	bool deassert_wp;
>  	const struct nand_op_instr *instrs;
>  	unsigned int ninstrs;
>  };
> @@ -1019,6 +1020,14 @@ struct nand_operation {
>  		.ninstrs = ARRAY_SIZE(_instrs),			\
>  	}
> 
> +#define NAND_DESTRUCTIVE_OPERATION(_cs, _instrs)		\
> +	{							\
> +		.cs = _cs,					\
> +		.deassert_wp = true,				\
> +		.instrs = _instrs,				\
> +		.ninstrs = ARRAY_SIZE(_instrs),			\
> +	}
> +
>  int nand_op_parser_exec_op(struct nand_chip *chip,
>  			   const struct nand_op_parser *parser,
>  			   const struct nand_operation *op, bool check_only);
> --
> 2.37.3
> 
> 


Thanks,
Miquèl

Re: [PATCH v2 1/4] mtd: rawnand: Add destructive operation

[Miquel Raynal]

Hello,

dregan@mail.com wrote on Thu, 12 Oct 2023 19:36:11 +0200:

> Hi Miquel,
> 
> > Sent: Thursday, October 12, 2023 at 12:06 AM
> > From: "Miquel Raynal" <miquel.raynal@bootlin.com>
> > To: dregan@mail.com
> > Cc: bcm-kernel-feedback-list@broadcom.com, linux-mtd@lists.infradead.org, f.fainelli@gmail.com, rafal@milecki.pl, joel.peshkin@broadcom.com, computersforpeace@gmail.com, dan.beygelman@broadcom.com, william.zhang@broadcom.com, frieder.schrempf@kontron.de, linux-kernel@vger.kernel.org, vigneshr@ti.com, richard@nod.at, bbrezillon@kernel.org, kdasu.kdev@gmail.com, "JaimeLiao" <jaimeliao.tw@gmail.com>, "Arseniy Krasnov" <AVKrasnov@sberdevices.ru>, "Adam Borowski" <kilobyte@angband.pl>
> > Subject: Re: [PATCH v2 1/4] mtd: rawnand: Add destructive operation
> >
> > Hello,
> > 
> > dregan@mail.com wrote on Thu, 12 Oct 2023 02:40:35 +0200:
> > 
> > The author should be Boris as well (git commit --amend --author=...)  
> 
> I will attempt to change the author but git seems to be
> somewhat limited in what I can accomplish when it comes to
> changing emails, sending in the name of someone else etc.
> 
> >   
> > > Erase and program operations need the write protect (wp) pin to be
> > > de-asserted to take effect. Add the concept of destructive
> > > operation and pass the information to exec_op() so controllers know
> > > when they should de-assert this pin without having to decode
> > > the command opcode.
> > > 
> > > Created by Boris Brezillon.  
> > 
> > This can go away.  
> 
> Will remove.
> 
> >   
> > > 
> > > https://github.com/bbrezillon/linux/commit/e612e1f2c69a33ac5f2c91d13669f0f172d58717  
> > 
> > This as well.  
> 
> Will also remove.
> 
> >   
> > > Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>  
> > 
> > Please use Boris' kernel.org e-mail for the authorship and SoB  
> 
> I don't know what Boris' kernel.org email address?
> Is it @bootlin? Collabora still shows up as email when
> I do the list of maintainers. I did some searching
> but couldn't really find anything conclusive.

It's in .mailmap: bbrezillon@kernel.org

> > > Signed-off-by: David Regan <dregan@mail.com>  
> 
> Do I still keep this SOB or should I change it to something else?

You need both SoB: his then yours.

Thanks,
Miquèl

Re: [PATCH v2 1/4] mtd: rawnand: Add destructive operation

[Miquel Raynal]

Hi David,

dregan@mail.com wrote on Tue, 17 Oct 2023 08:19:07 +0200:

> Hi Miquèl,
> 
> ...
> 
> > > > Please use Boris' kernel.org e-mail for the authorship and SoB    
> > >   
> 
> ...
> 
> > 
> > It's in .mailmap: bbrezillon@kernel.org
> >   
> > > > > Signed-off-by: David Regan <dregan@mail.com>    
> > > 
> > > Do I still keep this SOB or should I change it to something else?  
> > 
> > You need both SoB: his then yours.
> > 
> > Thanks,
> > Miquèl
> >   
> 
> Thank you very much for the information!
> 
> I believe I have the git sendmail issues resolved, and I may be sending
> the next patch series via a Broadcom email. In this case should I send
> the series as v3 even though it may not link to my previous messages?
> (Although hopefully the messages will stay together as a group.)

Yes, please.

Thanks,
Miquèl