[PATCH v2 0/4] arm: renesas: Add reset control properties

[Simon Horman]

On Mon, Mar 20, 2017 at 10:31:50AM +0100, Geert Uytterhoeven wrote:
> Hi Simon, Shimoda-san,
> 
> On Mon, Mar 20, 2017 at 9:28 AM, Simon Horman <horms at verge.net.au> wrote:
> > On Thu, Mar 16, 2017 at 03:07:22PM +0100, Geert Uytterhoeven wrote:
> >> This patch series describes the reset control topology for on-SoC devices
> >> connected to the Renesas Clock Pulse Generator / Module Standby and
> >> Software Reset module on the R-Car H3 and M3-W, RZ/G1M, and RZ/G1E SoCs.
> >>
> >> Resets usually match the corresponding module clocks.  Exceptions are:
> >>   - The Display Unit has only 2 resets, one per channel pair, cfr.
> >>     "[PATCH v2] dt-bindings: drm: rcar-du: Document optional reset
> >>     properties" (http://www.spinics.net/lists/dri-devel/msg134637.html),
> >>   - The audio module has resets for the Serial Sound Interfaces only.
> >>     Adding resets and reset-names properties depends on a DT binding
> >>     update for renesas,rsnd (note: the DT binding documentation in
> >>     Documentation/devicetree/bindings/sound/renesas,rsnd.txt doesn't
> >>     even document clocks and clock-names?).
> >> Upon request from Laurent for the DU, and upon a DT bindings update
> >> for rcar_sound, the addition of resets (and reset-names) properties for
> >> these complex modules is postponed.
> >>
> >> Note that this patch series contains hardware description only.
> >> Actual reset policy is to be defined and implemented separately.
> >> Also, this is an optional feature, to be enabled explicitly using
> >> CONFIG_RESET_CONTROLLER=y.  When enabled, an on-SoC device can be reset
> >> easily using device_reset(), or by using the reset_control_*() API when
> >> more fine-grained control is desired.
> >>
> >> Possible use cases are (not exhaustive):
> >>   - Reset a device before use, to make sure it's in a predefined state, and
> >>     doesn't depend on earlier configuration by e.g. the boot loader,
> >>   - Reset a device after detecting an anomaly,
> >>   - Reset a device to verify suspend/resume is handled correctly by the
> >>     driver in case the device would be part of a power domain on a
> >>     different/future SoC.
> >>
> >> Dependencies and impact:
> >>   - The corresponding driver changes to the CGP/MSSR driver are already
> >>     present in v4.11-rc1.
> >>   - These patches have no impact as long as CONFIG_RESET_CONTROLLER=n.
> >>     However, if CONFIG_RESET_CONTROLLER=y and resets properties are
> >>     prsesent in DTS, the EHCI and OHCI drivers already deassert reset as
> >>     part of their initialization sequences, and put the devices back
> >>     into reset state in case initialization failed, or on unbind.
> >>     I'm not aware of other relevant drivers already using reset control.
> >
> > It appears that for arm64 defconfig CONFIG_RESET_CONTROLLER=y is true so
> > by default there will be a behavioural change on arm64. I'd like to
> > understand if it is a desirable (or at least not undesirable) change.
> 
> V1 of this patch series has been part of renesas-drivers since
> renesas-drivers-2017-01-24-v4.10-rc5, so I'd hope any negative impact would
> have been discovered by now.
> 
> Shimoda-san: Have you noticed any oddities w.r.t. USB?

Thanks for the extra information. With the above in mind I think its
reasonable to queue-up this series for v4.12 and I have done so.

If any oddities arise then we can revisit this.