[PATCH 6/7] memory: renesas-rpc-if: Pass device instead of rpcif to rpcif_*()

Miquel Raynal miquel.raynal at bootlin.com
Thu Jun 30 01:58:51 PDT 2022


Hi Krzysztof,

krzysztof.kozlowski at linaro.org wrote on Thu, 30 Jun 2022 10:46:51 +0200:

> On 30/06/2022 09:25, Miquel Raynal wrote:
> > Hi Krzysztof,
> > 
> > geert+renesas at glider.be wrote on Mon, 27 Jun 2022 17:31:13 +0200:
> >   
> >> Most rpcif_*() API functions do not need access to any other fields in
> >> the rpcif structure than the device pointer.  Simplify dependencies by
> >> passing the device pointer instead.
> >>
> >> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> >> ---
> >>  drivers/memory/renesas-rpc-if.c | 32 ++++++++++++++++----------------
> >>  drivers/mtd/hyperbus/rpc-if.c   | 18 +++++++++---------  
> > 
> > [...]
> >   
> >> diff --git a/drivers/mtd/hyperbus/rpc-if.c b/drivers/mtd/hyperbus/rpc-if.c
> >> index d00d302434030b20..41734e337ac00e40 100644
> >> --- a/drivers/mtd/hyperbus/rpc-if.c
> >> +++ b/drivers/mtd/hyperbus/rpc-if.c
> >> @@ -56,7 +56,7 @@ static void rpcif_hb_prepare_read(struct rpcif *rpc, void *to,
> >>  	op.data.nbytes = len;
> >>  	op.data.buf.in = to;
> >>  
> >> -	rpcif_prepare(rpc, &op, NULL, NULL);
> >> +	rpcif_prepare(rpc->dev, &op, NULL, NULL);
> >>  }
> >>  
> >>  static void rpcif_hb_prepare_write(struct rpcif *rpc, unsigned long to,
> >> @@ -70,7 +70,7 @@ static void rpcif_hb_prepare_write(struct rpcif *rpc, unsigned long to,
> >>  	op.data.nbytes = len;
> >>  	op.data.buf.out = from;
> >>  
> >> -	rpcif_prepare(rpc, &op, NULL, NULL);
> >> +	rpcif_prepare(rpc->dev, &op, NULL, NULL);
> >>  }
> >>  
> >>  static u16 rpcif_hb_read16(struct hyperbus_device *hbdev, unsigned long addr)
> >> @@ -81,7 +81,7 @@ static u16 rpcif_hb_read16(struct hyperbus_device *hbdev, unsigned long addr)
> >>  
> >>  	rpcif_hb_prepare_read(&hyperbus->rpc, &data, addr, 2);
> >>  
> >> -	rpcif_manual_xfer(&hyperbus->rpc);
> >> +	rpcif_manual_xfer(hyperbus->rpc.dev);
> >>  
> >>  	return data.x[0];
> >>  }
> >> @@ -94,7 +94,7 @@ static void rpcif_hb_write16(struct hyperbus_device *hbdev, unsigned long addr,
> >>  
> >>  	rpcif_hb_prepare_write(&hyperbus->rpc, addr, &data, 2);
> >>  
> >> -	rpcif_manual_xfer(&hyperbus->rpc);
> >> +	rpcif_manual_xfer(hyperbus->rpc.dev);
> >>  }
> >>  
> >>  static void rpcif_hb_copy_from(struct hyperbus_device *hbdev, void *to,
> >> @@ -105,7 +105,7 @@ static void rpcif_hb_copy_from(struct hyperbus_device *hbdev, void *to,
> >>  
> >>  	rpcif_hb_prepare_read(&hyperbus->rpc, to, from, len);
> >>  
> >> -	rpcif_dirmap_read(&hyperbus->rpc, from, len, to);
> >> +	rpcif_dirmap_read(hyperbus->rpc.dev, from, len, to);
> >>  }
> >>  
> >>  static const struct hyperbus_ops rpcif_hb_ops = {
> >> @@ -130,9 +130,9 @@ static int rpcif_hb_probe(struct platform_device *pdev)
> >>  
> >>  	platform_set_drvdata(pdev, hyperbus);
> >>  
> >> -	rpcif_enable_rpm(&hyperbus->rpc);
> >> +	rpcif_enable_rpm(hyperbus->rpc.dev);
> >>  
> >> -	error = rpcif_hw_init(&hyperbus->rpc, true);
> >> +	error = rpcif_hw_init(hyperbus->rpc.dev, true);
> >>  	if (error)
> >>  		goto out_disable_rpm;
> >>  
> >> @@ -150,7 +150,7 @@ static int rpcif_hb_probe(struct platform_device *pdev)
> >>  	return 0;
> >>  
> >>  out_disable_rpm:
> >> -	rpcif_disable_rpm(&hyperbus->rpc);
> >> +	rpcif_disable_rpm(hyperbus->rpc.dev);
> >>  	return error;
> >>  }  
> > 
> > This will only apply on top of mtd/next, because that
> > rpcif_disable_rpm() balance call was very recently contributed by Geert:
> > https://lore.kernel.org/linux-mtd/f3070e1af480cb252ae183d479a593dbbf947685.1655457790.git.geert+renesas@glider.be/
> > 
> > So we need to first share an immutable tag on the current mtd/next
> > branch. Richard, that is my vacation gift for you :)  
> 
> I don't want entire mtd/next. I could take Renesas hyperbus specific
> commits.

I applied this patch a week ago and did not remembered there was a
possibly conflicting series aside.

> Another solution is me to rebase on some rcX, if that commit
> was sent as fix for current cycle.

Unfortunately, no.

> The third option is to simply resolve a conflict - which should looks
> pretty easy and compile-testable. In that case the commit should be
> rebased on my v5.19-rc1.

I believe it should work. As this is mostly a cleanup, you can also
wait 5.20-rc1.

Thanks,
Miquèl



More information about the linux-mtd mailing list