Re: [PATCH v2 4.19.y-cip 0/7] Add RPC-IF driver for RZ/G2x SoC's

Lad Prabhakar

Hi Nobuhiro,

-----Original Message-----
From: nobuhiro1.iwamatsu@... <nobuhiro1.iwamatsu@...>
Sent: 25 November 2020 06:48
To: pavel@...; Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; Biju Das <biju.das.jz@...>
Subject: RE: [PATCH v2 4.19.y-cip 0/7] Add RPC-IF driver for RZ/G2x SoC's


-----Original Message-----
From: Pavel Machek [mailto:pavel@...]
Sent: Wednesday, November 25, 2020 4:49 AM
To: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
<nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Biju Das
Subject: Re: [PATCH v2 4.19.y-cip 0/7] Add RPC-IF driver for RZ/G2x SoC's


This patch series adds SPI driver for the Renesas RPC-IF.
Alongside relevant changes for spi-mem have been also
backported. This enables accessing SPI flash chip connected
to RPC-IF on RZ/G2x boards.

We currently only aim to backport just the driver hence there
are no changes to dts/i files. The driver has been tested on
RZ/G2{EM} with all the required dts/i changes [1].
Okay, that was quick.

What is your plan, merge dts changes soon? Or is the driver useful
even without the dts changes?

Changes for v2:
* Patches {1, 3, 4}/7 unchanged
* Patch 2/7
* Fixed reference leak for OF node in rpcif_probe()
* Fixed overwriting return value in error path of rpcif_manual_xfer()
* Replaced C++ style comment with C style
* Replaced tab with a space between struct and struct name
* Fixed a typo in commit message (s/absract/abstract)
* Patch 5/7
* Fixed reference leak in spi_mem_access_start for PM
* Patch 6/7
* Return early in spi_mem_dirmap_dirmap_{read/write}
* Patch 7/7
* Replaced C++ style comment with C style
* Used __maybe_unused for rpcif_spi_{suspend,resume} and dropped
CONFIG_PM_SLEEP ifdef checks
* Elaborated the description for SPI_RPCIF config
* Dropped the label err_put_ctlr from rpc_spi_probe()
I don't see any problems with this series.
Thank you for the review.

Thanks for the changes; they are probably good (I have yet to take
close look), but I wonder if we should wait until they hit next or
mainline? If upstream maintainer disagrees, we would get divergence...
These patch series contain fixes for issues in the patch itself, so we need to
separate them and post them mainline or subsystem tree.
So I think we have to wait for those patches to be merged.
Agreed will repost the series once the fixes hit linux-next.


Best regards,

Join to automatically receive all group messages.