On Mon, Feb 19, 2018 at 10:16 PM, Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> wrote:
> On Mon, 2018-02-19 at 17:24 +1030, Joel Stanley wrote:
>> This describes the reset controller present in the LPC address space.
>>
>> Signed-off-by: Joel Stanley <joel@xxxxxxxxx>
>> ---
>> .../devicetree/bindings/mfd/aspeed-lpc.txt | 21 +++++++++++++++++++++
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
>> index 514d82ced95b..721a2b1eb40f 100644
>> --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
>> +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
>> @@ -135,3 +135,24 @@ lhc: lhc@20 {
>> compatible = "aspeed,ast2500-lhc";
>> reg = <0x20 0x24 0x48 0x8>;
>> };
>> +
>> +LPC reset control
>> +-----------------
>> +
>> +The UARTs present in the ASPEED SoC can have their resets tied to the reset
>> +state of the LPC bus. Some systems may chose to modify this configuration.
>> +
>> +Required properties:
>> +
>> + - comaptible: "aspeed,ast2500-lpc-reset" or
>
> "compatible"
>
>> + "aspeed,ast2400-lpc-reset"
>> + - reg: offset and length of the IP in the LHC memory region
>> + - #reset-controller indacates the number of reset cells excepted
>
> "indicates", "expected"
Oops, thanks.
>
>> +
>> +Example:
>> +
>> +lpc_reset: reset-controller@18 {
>> + compatible = "aspeed,ast2500-lpc-reset";
>> + reg = <0x18 0x4>;
>> + #reset-cells = <1>;
>> +};
>
> Should this mention or indicate in the example that the reset-controller
> node must be child of (a subnode of) the lpc node?
This is indicated by the layout of the binding document. The "LPC
reset control" heading is below a "Host Node Children" heading.
>
> 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
