On Mon, 2017-07-03 at 23:30 +0200, Hauke Mehrtens wrote:
> On 07/03/2017 09:51 AM, Andy Shevchenko wrote:
> > On Mon, Jul 3, 2017 at 1:40 AM, Hauke Mehrtens <hauke@xxxxxxxxxx> wrote:
> >> From: Martin Blumenstingl <martin.blumenstingl@xxxxxxxxxxxxxx>
> >>
> >> The reset controllers (on xRX200 and newer SoCs have two of them) are
> >> provided by the RCU module. This was initially implemented as a simple
> >> reset controller. However, the RCU module provides more functionality
> >> (ethernet GPHYs, USB PHY, etc.), which makes it a MFD device.
> >> The old reset controller driver implementation from
> >> arch/mips/lantiq/xway/reset.c did not honor this fact.
> >>
> >> For some devices the request and the status bits are different.
> >
> >> +Required properties:
> >> +- compatible : Should be one of
> >> + "lantiq,danube-reset"
> >> + "lantiq,xrx200-reset"
> >> +- offset-set : Offset of the reset set register
> >> +- offset-status : Offset of the reset status register
> >
> > Just one side comment (I'm fine with either choice, just for your
> > information). Recently I have reviewed at24 patch which adds a
> > property for getting MAC offset and my reseach ends up with the naming
> > pattern mac-offset (as many others are doing this way). So, perhaps in
> > your case it might make sense to do that way? Anyway, it's a matter of
> > a (bit of a) chaos in DT bindings, whatever you decide users will live
> > with.
> >
> I put the offset first to group them better together, but I have no
> problem in reversing the order, then it is in a more natural speaking form.
Either way, I would like to see an Acked-by from the device tree
maintainers for the bindings. Given that,
Acked-by: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx>
to merge this driver through the mips tree, since a git merge with
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git drivers/reset-2
is conflict free.
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
