[<prev] [next>] [day] [month] [year] [list]
Message-ID: <8720224d-76f4-c620-9e3f-91605d6fa1e3@cogentembedded.com>
Date: Tue, 16 Apr 2019 11:02:10 +0300
From: Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To: masonccyang@...c.com.tw
Cc: bbrezillon@...nel.org, broonie@...nel.org,
devicetree@...r.kernel.org,
Geert Uytterhoeven <geert+renesas@...der.be>,
Simon Horman <horms@...ge.net.au>, juliensu@...c.com.tw,
lee.jones@...aro.org, linux-kernel@...r.kernel.org,
linux-renesas-soc@...r.kernel.org, linux-spi@...r.kernel.org,
marek.vasut@...il.com, mark.rutland@....com, robh+dt@...nel.org
Subject: Re: [PATCH v10 3/3] dt-bindings: mfd: Document Renesas R-Car Gen3
RPC-IF controller bindings
On 16.04.2019 4:06, masonccyang@...c.com.tw wrote:
> > > Document the bindings used by the Renesas R-Car Gen3 RPC-IF MFD controller.
> > >
> > > Signed-off-by: Mason Yang <masonccyang@...c.com.tw>
> > > ---
> > > .../devicetree/bindings/mfd/mfd-renesas-rpc.txt | 37 +++++++++
> > +++++++++++++
> > > 1 file changed, 37 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/mfd/mfd-
> > renesas-rpc.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/mfd/mfd-renesas-
> > rpc.txt b/Documentation/devicetree/bindings/mfd/mfd-renesas-rpc.txt
> > > new file mode 100644
> > > index 0000000..bfb3d29
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mfd/mfd-renesas-rpc.txt
> > > @@ -0,0 +1,37 @@
> > > +Renesas R-Car Gen3 RPC-IF MFD controller Device Tree Bindings
> > > +-------------------------------------------------------------
> > > +
> > > +Required properties:
> > > +- compatible: should be an SoC-specific compatible value, followed by
> > > + "renesas,rcar-gen3-rpc" as a fallback.
> > > + supported SoC-specific values are:
> > > + "renesas,r8a77995-rpc" (R-Car D3)
> > > +- reg: should contain 2 entries, one for the base address of rpc-
> > if registers,
> > > + and one for the direct mapping area
> > > +- reg-names: should contain "regs", and "dirmap"
> >
> > The device tree describes the hardware, not the driver. Why did you remove
> > the "wbuf" area?
>
> I don't think we should describe the hardware that driver did not implement it
> because there are still many RPC registers we don't use them.
I have to repeat: we describe the hardware, not the driver capabilities.
> best regards,
> Mason
MBR, Sergei
Powered by blists - more mailing lists