On 04/20/2017 04:54 PM, Rob Herring wrote: > On Mon, Apr 17, 2017 at 09:29:37PM +0200, Hauke Mehrtens 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. >> >> Signed-off-by: Hauke Mehrtens <hauke@xxxxxxxxxx> >> --- >> .../devicetree/bindings/reset/lantiq,rcu-reset.txt | 43 ++++ >> arch/mips/lantiq/xway/reset.c | 68 ------ >> drivers/reset/Kconfig | 6 + >> drivers/reset/Makefile | 1 + >> drivers/reset/reset-lantiq-rcu.c | 231 +++++++++++++++++++++ >> 5 files changed, 281 insertions(+), 68 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/reset/lantiq,rcu-reset.txt >> create mode 100644 drivers/reset/reset-lantiq-rcu.c >> >> diff --git a/Documentation/devicetree/bindings/reset/lantiq,rcu-reset.txt b/Documentation/devicetree/bindings/reset/lantiq,rcu-reset.txt >> new file mode 100644 >> index 000000000000..7f097d16bbb7 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/reset/lantiq,rcu-reset.txt >> @@ -0,0 +1,43 @@ >> +Lantiq XWAY SoC RCU reset controller binding >> +============================================ >> + >> +This binding describes a reset-controller found on the RCU module on Lantiq >> +XWAY SoCs. >> + >> + >> +------------------------------------------------------------------------------- >> +Required properties (controller (parent) node): >> +- compatible : Should be "lantiq,rcu-reset" >> +- lantiq,rcu-syscon : A phandle to the RCU syscon, the reset register >> + offset and the status register offset. >> +- #reset-cells : Specifies the number of cells needed to encode the >> + reset line, should be 1. >> + >> +Optional properties: >> +- reset-status : The request status bit. For some bits the request bit >> + and the status bit are different. This is depending >> + on the SoC. If the reset-status bit does not match >> + the reset-request bit, put the reset number into the >> + reset-request property and the status bit at the same >> + index into the reset-status property. If no >> + reset-request bit is given here, the driver assume >> + status and request bit are the same. >> +- reset-request : The reset request bit, to map it to the reset-status >> + bit. > > These should either be implied by SoC specific compatible or be made > part of the reset cells. In the latter case, you still need the SoC > specific compatible. Currently the reset framework only supports a single reset cell to my knowledge, but I haven't looked into the details, I could extend it to make it support two. The SoC which needs this has two reset control register sets and the bits are specific for each register set. Would a specific compatible string for each register set ok? > >> +------------------------------------------------------------------------------- >> +Example for the reset-controllers on the xRX200 SoCs: >> + rcu_reset0: rcu_reset { >> + compatible = "lantiq,rcu-reset"; >> + lantiq,rcu-syscon = <&rcu0 0x10 0x14>; >> + #reset-cells = <1>; >> + reset-request = <31>, <29>, <21>, <19>, <16>, <12>; >> + reset-status = <30>, <28>, <16>, <25>, <5>, <24>; >> + }; >> + >> + rcu_reset1: rcu_reset { >> + compatible = "lantiq,rcu-reset"; > > These 2 blocks are identical? Given different registers sizes, I'd say > not. So they should have different compatible strings. I will remove the second one. > >> + lantiq,rcu-syscon = <&rcu0 0x48 0x24>; >> + #reset-cells = <1>; >> + }; -- 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