Hi Conor, Thanks for your feedback. On 2024-06-10 17:03:49 +0100, Conor Dooley wrote: > On Mon, Jun 10, 2024 at 01:31:23PM +0200, Niklas Söderlund wrote: > > Document support for the VIN module in the Renesas V4M (r8a779h0) SoC. > > > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@xxxxxxxxxxxx> > > Reviewed-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx> > > --- > > Documentation/devicetree/bindings/media/renesas,vin.yaml | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml > > index 5539d0f8e74d..168cb02f8abe 100644 > > --- a/Documentation/devicetree/bindings/media/renesas,vin.yaml > > +++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml > > @@ -54,6 +54,7 @@ properties: > > - renesas,vin-r8a77995 # R-Car D3 > > - renesas,vin-r8a779a0 # R-Car V3U > > - renesas,vin-r8a779g0 # R-Car V4H > > + - renesas,vin-r8a779h0 # R-Car V4M > > Your driver patch suggests that this is compatible with the g variant. Currently it is. But that not always be true, I tried to outline this in to cover letter. The V4M capture pipeline is similar to the other Gen4 SoC supported upstream already V4H. Currently all futures supported for VIN on V4M are also supported by V4H and the driver code can be shared. But as done for other R-Car IP bindings a new dedicated binding for V4M is created. This have proved prudent in the past where quirks are found even within the same generation as more advance use-cases are enabled. -- Kind Regards, Niklas Söderlund