Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Stephen,

On Fri, Nov 4, 2016 at 8:49 PM, Stephen Boyd  wrote:
> On 11/02, Geert Uytterhoeven wrote:
>> On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd  wrote:
>> >
>> > Would the pull requests for clk also have dts changes at the base
>> > of the tree? Perhaps clk side can just ack the clk patches and
>>
>> Yes they would: this is moving functionality from platform code to DT.
>> Without the DT updates, it will break bisection (except for R-Car Gen2,
>> where we have fallback code to handle old DTBs).
>>
>> > then have it all routed through arm-soc? The only worry I have is
>> > if we need to make some sort of change in clk side that conflicts
>> > with these changes. I don't usually like taking dts changes
>> > through clk tree, so I'd like to avoid that if possible.
>>
>> Everything could go through arm-soc only with your Acked-by.
>> However, there are new clock drivers pending on this series.
>> Either they have to go through arm-soc, too, or this series would
>> be pulled into the clk tree with these new clock drivers.
>>
>> > Part E could happen anytime after everything else happens, so
>> > that doesn't seem like a concern.
>>
>> Part E can indeed by postponed.
>> But if parts A-D are applied together, there's no reason to postpone part E.
>>
>> > Part C could also be made to
>> > only call into the new reset drivers if the reset dts nodes are
>> > present? If that's done then we could merge clk patches anytime
>> > and remove the dead code and the node search at some later time
>> > when everything has settled?
>>
>> That would require adding more backwards compatibility code for
>> old DTBs, even for platform where we're not interested in maintaining
>> that. In addition, Part C depends on the header file for the reset driver
>> to compile the clock driver, even if you would add some DT detection,
>> and on the reset driver to link. So I'm afraid this is not feasible.
>
> TL;DR: Sounds fine, I'll be on the lookout for the PR.

Thank you very much!

> Longer version: Let me step back a bit and actually think about
> this longer than 2 minutes. From what I see
> rcar_rst_read_mode_pins() already returns -ENODEV if the nodes
> aren't present. Great.
>
> So clk tree could be given a pull for the clk patches, part C, on
> top of part A, the reset driver. If the rcar_rst_read_mode_pins()
> returns failure because the node is missing, we fall back to the
> old style of doing things. Some drivers already do that anyway,

For R-Car Gen2, we want to keep backwards compatibility for a while.
But not for the others, and I didn't want to add more code that was going
to be removed again soon.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Stephen Boyd]

On 11/02, Geert Uytterhoeven wrote:
> On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd  wrote:
> >
> > Would the pull requests for clk also have dts changes at the base
> > of the tree? Perhaps clk side can just ack the clk patches and
> 
> Yes they would: this is moving functionality from platform code to DT.
> Without the DT updates, it will break bisection (except for R-Car Gen2,
> where we have fallback code to handle old DTBs).
> 
> > then have it all routed through arm-soc? The only worry I have is
> > if we need to make some sort of change in clk side that conflicts
> > with these changes. I don't usually like taking dts changes
> > through clk tree, so I'd like to avoid that if possible.
> 
> Everything could go through arm-soc only with your Acked-by.
> However, there are new clock drivers pending on this series.
> Either they have to go through arm-soc, too, or this series would
> be pulled into the clk tree with these new clock drivers.
> 
> > Part E could happen anytime after everything else happens, so
> > that doesn't seem like a concern.
> 
> Part E can indeed by postponed.
> But if parts A-D are applied together, there's no reason to postpone part E.
> 
> > Part C could also be made to
> > only call into the new reset drivers if the reset dts nodes are
> > present? If that's done then we could merge clk patches anytime
> > and remove the dead code and the node search at some later time
> > when everything has settled?
> 
> That would require adding more backwards compatibility code for
> old DTBs, even for platform where we're not interested in maintaining
> that. In addition, Part C depends on the header file for the reset driver
> to compile the clock driver, even if you would add some DT detection,
> and on the reset driver to link. So I'm afraid this is not feasible.
> 

TL;DR: Sounds fine, I'll be on the lookout for the PR.

Longer version: Let me step back a bit and actually think about
this longer than 2 minutes. From what I see
rcar_rst_read_mode_pins() already returns -ENODEV if the nodes
aren't present. Great.

So clk tree could be given a pull for the clk patches, part C, on
top of part A, the reset driver. If the rcar_rst_read_mode_pins()
returns failure because the node is missing, we fall back to the
old style of doing things. Some drivers already do that anyway,
so this looks to be replacing things like 

if (rcar_rst_read_mode_pins())
return;

with

if (rcar_rst_read_mode_pins() != -ENODEV)
return;


Then in arm-soc tree, the dts patches are merged. That causes us
to do some duplicate work reading the pins twice in mach-shmobile
and in the new reset driver. That's duplicate/wasteful, but it
works. Finally, everything is merged together into a tagged
release. The mach-shmobile changes can happen anytime after that
(part D). Again we're left with dead code in the clk driver (part
E) until the dependency merges, but that's ok. Once part D merges
we can get rid of the dead code in part E and any backwards
compatibility we don't want to maintain.

In summary, it's all feasible to do this and most people wouldn't
have had to know about the dependency chain but it's not fast by
any means. Instead we merge everything in one shot and get it
over with now.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Stephen,

Thanks for your answers!

On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd  wrote:
> On 10/31, Geert Uytterhoeven wrote:
>> Hi Mike, Stephen, Arnd, Olof, Kevin,
>>
>> Is the merge strategy [see # below] OK for you?
>> Thanks a lot!
>>
>> On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman  wrote:
>> > On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
>> >> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
>> >>  wrote:
>> >> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> >> > state of the mode pins either by a call from the platform code, or
>> >> > directly by using a hardcoded register access. This is a bit messy, and
>> >> > creates a dependency between driver and platform code.
>> >> >
>> >> > This patch series converts the various Renesas R-Car clock drivers
>> >> > and support code from reading the mode pin states using a hardcoded
>> >> > register access to using a new minimalistic R-Car RST driver.
>> >> >
>> >> > All R-Car clock drivers will rely on the presence in DT of a device node
>> >> > for the RST module.  Backwards compatibility with old DTBs is retained
>> >> > only for R-Car Gen2, which has fallback code using its own private copy
>> >> > of rcar_gen2_read_mode_pins().
>> >> >
>> >> > After this, there is still one remaining user of
>> >> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
>> >> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
>> >> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
>> >> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
>> >> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>> >> >
>> >> > This series consists of 5 parts:
>> >> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>> >> >  driver,
>> >> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>> >> >  files,
>> >> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>> >> >  RST driver,
>> >> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
>> >> >  from the platform code,
>> >> >   E. Patches 21-23 remove dead code from the clock drivers.
>> >> >
>> >> > As is usually the case with moving functionality from platform code to
>> >> > DT, there are lots of hard dependencies:
>> >> >   - The DT updates in Part B can be merged as soon as the DT bindings in
>> >> > Part A have been approved,
>> >> >   - The clock driver updates in Part C depend functionally on the driver
>> >> > code in Part A, and on the DT updates in Part B,
>> >> >   - The board code cleanups in Part D depend on the clock driver updates
>> >> > in Part C,
>> >> >   - The block driver cleanups in part E depend on the board code
>> >> > cleanups in part D.
>> >> >
>> >> > Hence to maintain the required lockstep between SoC driver, clock
>> >> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
>> >> > all patches in a single branch against v4.9-rc1, and send pull requests
>> >> > to both Mike/Stephen (clock) and Simon (rest).
>> >> >
>> >> > ***
>> >>
>> >> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
>> >> > approach above?
>> >>
>> >> Is this OK for you?
>>
>> #
>>
>> (link to the full series at
>>  https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)
>
> Would the pull requests for clk also have dts changes at the base
> of the tree? Perhaps clk side can just ack the clk patches and

Yes they would: this is moving functionality from platform code to DT.
Without the DT updates, it will break bisection (except for R-Car Gen2,
where we have fallback code to handle old DTBs).

> then have it all routed through arm-soc? The only worry I have is
> if we need to make some sort of change in clk side that conflicts
> with these changes. I don't usually like taking dts changes
> through clk tree, so I'd like to avoid that if possible.

Everything could go through arm-soc only with your Acked-by.
However, there are new clock drivers pending on this series.
Either they have to go through arm-soc, too, or this series would
be pulled into the clk tree with these new clock drivers.

> Part E could happen anytime after everything else happens, so
> that doesn't seem like a concern.

Part E can indeed by postponed.
But if parts A-D are applied together, there's no reason to postpone part E.

> Part C could also be made to
> only call into the new reset drivers if the reset dts nodes are
> present? If that's done then we could merge clk patches anytime
> and remove the dead code and the node search at some later time
> when everything has settled?

That would require adding more backwards compatibility code for
old DTBs, even for platform where we're not interested in maintaining
that. In addition, Part C depends on the header file for the 

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Stephen Boyd]

On 10/31, Geert Uytterhoeven wrote:
> Hi Mike, Stephen, Arnd, Olof, Kevin,
> 
> Is the merge strategy [see # below] OK for you?
> Thanks a lot!
> 
> On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman  wrote:
> > On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
> >> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
> >>  wrote:
> >> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> >> > state of the mode pins either by a call from the platform code, or
> >> > directly by using a hardcoded register access. This is a bit messy, and
> >> > creates a dependency between driver and platform code.
> >> >
> >> > This patch series converts the various Renesas R-Car clock drivers
> >> > and support code from reading the mode pin states using a hardcoded
> >> > register access to using a new minimalistic R-Car RST driver.
> >> >
> >> > All R-Car clock drivers will rely on the presence in DT of a device node
> >> > for the RST module.  Backwards compatibility with old DTBs is retained
> >> > only for R-Car Gen2, which has fallback code using its own private copy
> >> > of rcar_gen2_read_mode_pins().
> >> >
> >> > After this, there is still one remaining user of
> >> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
> >> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> >> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> >> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> >> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> >> >
> >> > This series consists of 5 parts:
> >> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> >> >  driver,
> >> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> >> >  files,
> >> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
> >> >  RST driver,
> >> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
> >> >  from the platform code,
> >> >   E. Patches 21-23 remove dead code from the clock drivers.
> >> >
> >> > As is usually the case with moving functionality from platform code to
> >> > DT, there are lots of hard dependencies:
> >> >   - The DT updates in Part B can be merged as soon as the DT bindings in
> >> > Part A have been approved,
> >> >   - The clock driver updates in Part C depend functionally on the driver
> >> > code in Part A, and on the DT updates in Part B,
> >> >   - The board code cleanups in Part D depend on the clock driver updates
> >> > in Part C,
> >> >   - The block driver cleanups in part E depend on the board code
> >> > cleanups in part D.
> >> >
> >> > Hence to maintain the required lockstep between SoC driver, clock
> >> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
> >> > all patches in a single branch against v4.9-rc1, and send pull requests
> >> > to both Mike/Stephen (clock) and Simon (rest).
> >> >
> >> > ***
> >>
> >> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
> >> > approach above?
> >>
> >> Is this OK for you?
> 
> #
> 
> (link to the full series at
>  https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)

Would the pull requests for clk also have dts changes at the base
of the tree? Perhaps clk side can just ack the clk patches and
then have it all routed through arm-soc? The only worry I have is
if we need to make some sort of change in clk side that conflicts
with these changes. I don't usually like taking dts changes
through clk tree, so I'd like to avoid that if possible.

Part E could happen anytime after everything else happens, so
that doesn't seem like a concern. Part C could also be made to
only call into the new reset drivers if the reset dts nodes are
present? If that's done then we could merge clk patches anytime
and remove the dead code and the node search at some later time
when everything has settled?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Simon Horman]

On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
> Hi Mike, Stephen,
> 
> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
>  wrote:
> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> > state of the mode pins either by a call from the platform code, or
> > directly by using a hardcoded register access. This is a bit messy, and
> > creates a dependency between driver and platform code.
> >
> > This patch series converts the various Renesas R-Car clock drivers
> > and support code from reading the mode pin states using a hardcoded
> > register access to using a new minimalistic R-Car RST driver.
> >
> > All R-Car clock drivers will rely on the presence in DT of a device node
> > for the RST module.  Backwards compatibility with old DTBs is retained
> > only for R-Car Gen2, which has fallback code using its own private copy
> > of rcar_gen2_read_mode_pins().
> >
> > After this, there is still one remaining user of
> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> >
> > This series consists of 5 parts:
> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> >  driver,
> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> >  files,
> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
> >  RST driver,
> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
> >  from the platform code,
> >   E. Patches 21-23 remove dead code from the clock drivers.
> >
> > As is usually the case with moving functionality from platform code to
> > DT, there are lots of hard dependencies:
> >   - The DT updates in Part B can be merged as soon as the DT bindings in
> > Part A have been approved,
> >   - The clock driver updates in Part C depend functionally on the driver
> > code in Part A, and on the DT updates in Part B,
> >   - The board code cleanups in Part D depend on the clock driver updates
> > in Part C,
> >   - The block driver cleanups in part E depend on the board code
> > cleanups in part D.
> >
> > Hence to maintain the required lockstep between SoC driver, clock
> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
> > all patches in a single branch against v4.9-rc1, and send pull requests
> > to both Mike/Stephen (clock) and Simon (rest).
> >
> > ***
> 
> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
> > approach above?
> 
> Is this OK for you?
> 
> I'd like to move forward with this, as this is a prerequisite for adding
> support for new SoCs (RZ/G) without adding more copies of
> rcar_gen2_read_mode_pins(), and removing that function from platform code
> for good.

This seems reasonable to me but likely the ARM SoC maintainers will want to
know about this plan before it is executed.

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Philipp Zabel]

 A. Hi Geert,

Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> Hi Philipp, Mike, Stephen, Simon, Magnus,
>   (see questions *** below!)
> 
> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> state of the mode pins either by a call from the platform code, or
> directly by using a hardcoded register access. This is a bit messy, and
> creates a dependency between driver and platform code.
> 
> This patch series converts the various Renesas R-Car clock drivers
> and support code from reading the mode pin states using a hardcoded
> register access to using a new minimalistic R-Car RST driver.
> 
> All R-Car clock drivers will rely on the presence in DT of a device node
> for the RST module.  Backwards compatibility with old DTBs is retained
> only for R-Car Gen2, which has fallback code using its own private copy
> of rcar_gen2_read_mode_pins().

I think you should add a binding doc even though the DT bindings are
still trivial.

> After this, there is still one remaining user of
> rcar_gen2_read_mode_pins() left in platform code. A patch series to
> remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> 
> This series consists of 5 parts:
>   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>  driver,
>   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>  files,
>   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>  RST driver,
>   D. Patches 18-20 remove passing mode pin state to the clock drivers
>  from the platform code,
>   E. Patches 21-23 remove dead code from the clock drivers.
> 
> As is usually the case with moving functionality from platform code to
> DT, there are lots of hard dependencies:
>   - The DT updates in Part B can be merged as soon as the DT bindings in
> Part A have been approved,
>   - The clock driver updates in Part C depend functionally on the driver
> code in Part A, and on the DT updates in Part B,
>   - The board code cleanups in Part D depend on the clock driver updates
> in Part C,
>   - The block driver cleanups in part E depend on the board code
> cleanups in part D.
> 
> Hence to maintain the required lockstep between SoC driver, clock
> drivers, shmobile platform code, and shmobile DT, I propose to queue up
> all patches in a single branch against v4.9-rc1, and send pull requests
> to both Mike/Stephen (clock) and Simon (rest).
> 
> ***
> 
>   - Philip: While this is a driver for a reset-controller, currently it
> doesn't provide any reset-controller functionality. Hence I added it
> to drivers/soc/renesas/. Is that OK for you?

Absolutely, as long as the driver isn't even a reset controller
provider, this is the right place.

regards
Philipp

[PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Philipp, Mike, Stephen, Simon, Magnus,
(see questions *** below!)

Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
state of the mode pins either by a call from the platform code, or
directly by using a hardcoded register access. This is a bit messy, and
creates a dependency between driver and platform code.

This patch series converts the various Renesas R-Car clock drivers
and support code from reading the mode pin states using a hardcoded
register access to using a new minimalistic R-Car RST driver.

All R-Car clock drivers will rely on the presence in DT of a device node
for the RST module.  Backwards compatibility with old DTBs is retained
only for R-Car Gen2, which has fallback code using its own private copy
of rcar_gen2_read_mode_pins().

After this, there is still one remaining user of
rcar_gen2_read_mode_pins() left in platform code. A patch series to
remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").

This series consists of 5 parts:
  A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
 driver,
  B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
 files,
  C. Patches 12-17 convert the clock drivers to call into the new R-Car
 RST driver,
  D. Patches 18-20 remove passing mode pin state to the clock drivers
 from the platform code,
  E. Patches 21-23 remove dead code from the clock drivers.

As is usually the case with moving functionality from platform code to
DT, there are lots of hard dependencies:
  - The DT updates in Part B can be merged as soon as the DT bindings in
Part A have been approved,
  - The clock driver updates in Part C depend functionally on the driver
code in Part A, and on the DT updates in Part B,
  - The board code cleanups in Part D depend on the clock driver updates
in Part C,
  - The block driver cleanups in part E depend on the board code
cleanups in part D.

Hence to maintain the required lockstep between SoC driver, clock
drivers, shmobile platform code, and shmobile DT, I propose to queue up
all patches in a single branch against v4.9-rc1, and send pull requests
to both Mike/Stephen (clock) and Simon (rest).

***

  - Philip: While this is a driver for a reset-controller, currently it
doesn't provide any reset-controller functionality. Hence I added it
to drivers/soc/renesas/. Is that OK for you?

  - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
approach above?

This series has evolved over time, cfr.:
  - "[PATCH/RFC v3 00/22] soc: renesas: Add R-Car RST driver for
obtaining mode pin state"
(http://www.spinics.net/lists/linux-renesas-soc/msg04289.html),
  - "[PATCH/RFC 00/11] ARM: shmobile: Let CPG use syscon for MD pin
values" (http://www.spinics.net/lists/linux-clk/msg01478.html),
  - "[PATCH 00/10] arm64: renesas: Obtain MD pin values using
syscon/regmap".
(http://www.spinics.net/lists/linux-sh/msg44757.html)

Changes compared to v3:
  - Add Acked-by, Reviewed-by,
  - Add support for R-Car V2H,
  - Add support for RZ/G1M and RZ/G1E,
  - Remove the initcall and the rcar_rst_base check in rcar_rst_init(),
as rcar_rst_init() is only used as a support function for
rcar_rst_read_mode_pins(),
  - Refer to rcar_rst_gen2 for R-Car Gen3 instead of providing an
identical copy,
  - Use our own private copy of rcar_gen2_read_mode_pins() instead of
the one in the R-Car Gen2 platform code, as the latter is planned to
be removed,
  - Rebase on top of "ARM: shmobile: rcar-gen2: Obtain extal frequency
from DT",

Changes compared to v2:
  - Use "renesas,-rst" instead of "renesas,rst-",
  - Drop "syscon" compatible value and "renesas,modemr" property, use a
real driver instead,
  - Add support for R-Car M1A, H1, and M3-W.

Changes compared to v1:
  - Add support for R-Car H3.

This patch series is against v4.9-rc1. When applying it to
renesas-devel-20161021-v4.9-rc1, there's a small conflict in
drivers/soc/renesas/Makefile (both sides added lines).

For your convenience, this series is also available in the
topic/rcar-rst-v4 branch of my renesas-drivers git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
This has been tested on r8a7778/bockw, r8a7779/marzen, r8a7791/koelsch,
r8a7795/salvator-x, and r8a7796/salvator-x.

Thanks!

Geert Uytterhoeven (23):
  reset: Add renesas,rst DT bindings
  soc: renesas: Add R-Car RST driver
  ARM: dts: r8a7778: Add device node for RESET/WDT module
  ARM: dts: r8a7779: Add device node for RESET/WDT module
  ARM: dts: r8a7790: Add device node for RST module
  ARM: dts: r8a7791: Add device node for RST module
  ARM: dts: r8a7792: Add device node for RST module
  ARM: dts: r8a7793: Add device node for RST