| Message ID | 20221027181337.8651-3-afd@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | TI-Nspire cleanups | expand |
On 27/10/2022 14:13, Andrew Davis wrote: > Writing this bit can be handled by the syscon-reboot driver. > Add this node to DT. > > Signed-off-by: Andrew Davis <afd@ti.com> > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > Tested-by: Fabian Vogt <fabian@ritter-vogt.de> > Reviewed-by: Fabian Vogt <fabian@ritter-vogt.de> > --- > arch/arm/boot/dts/nspire.dtsi | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi > index bb240e6a3a6f..48fbc9d533c3 100644 > --- a/arch/arm/boot/dts/nspire.dtsi > +++ b/arch/arm/boot/dts/nspire.dtsi > @@ -172,7 +172,14 @@ rtc: rtc@90090000 { > }; > > misc: misc@900a0000 { > + compatible = "ti,nspire-misc", "syscon", "simple-mfd"; You have syscon and simple-mfd, but bindings in patch #1 say only syscon. Best regards, Krzysztof
On 10/27/22 2:33 PM, Krzysztof Kozlowski wrote: > On 27/10/2022 14:13, Andrew Davis wrote: >> Writing this bit can be handled by the syscon-reboot driver. >> Add this node to DT. >> >> Signed-off-by: Andrew Davis <afd@ti.com> >> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> >> Tested-by: Fabian Vogt <fabian@ritter-vogt.de> >> Reviewed-by: Fabian Vogt <fabian@ritter-vogt.de> >> --- >> arch/arm/boot/dts/nspire.dtsi | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi >> index bb240e6a3a6f..48fbc9d533c3 100644 >> --- a/arch/arm/boot/dts/nspire.dtsi >> +++ b/arch/arm/boot/dts/nspire.dtsi >> @@ -172,7 +172,14 @@ rtc: rtc@90090000 { >> }; >> >> misc: misc@900a0000 { >> + compatible = "ti,nspire-misc", "syscon", "simple-mfd"; > > You have syscon and simple-mfd, but bindings in patch #1 say only syscon. > I'm not following, are you just saying my wording in the patch message just wasn't complete? Or are you saying something more about nodes that are both syscon and simple-mfd? In that case, having both syscon and simple-mfd seems rather common, looks like you added the rule for it[0]. Thinking on this, they almost represent the same thing. simple-mfd says "my child nodes should be considered devices", why do we need that? Couldn't we simply state that "syscon" node's children are always devices, I mean what else could they be, syscon is an MFD after all (and lives in drivers/mfd/). "syscon" often just says, others can use the registers within this node, so as a different option, make "syscon" a property of "simple-mfd" nodes. I'm seeing all these examples of devices that should have been children of the "syscon" device, but instead use regmap = <&x>; syscon = <&x>; or similar and put the device node out somewhere random. And in those cases, wouldn't it have been more correct to use the normal "reg" and "regions" to define the registers belonging to the child node/device?.. Thanks, Andrew [0] https://lore.kernel.org/all/20220817142246.828762-5-krzysztof.kozlowski@linaro.org/ > > Best regards, > Krzysztof >
On 27/10/2022 17:07, Andrew Davis wrote: > On 10/27/22 2:33 PM, Krzysztof Kozlowski wrote: >> On 27/10/2022 14:13, Andrew Davis wrote: >>> Writing this bit can be handled by the syscon-reboot driver. >>> Add this node to DT. >>> >>> Signed-off-by: Andrew Davis <afd@ti.com> >>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> >>> Tested-by: Fabian Vogt <fabian@ritter-vogt.de> >>> Reviewed-by: Fabian Vogt <fabian@ritter-vogt.de> >>> --- >>> arch/arm/boot/dts/nspire.dtsi | 7 +++++++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi >>> index bb240e6a3a6f..48fbc9d533c3 100644 >>> --- a/arch/arm/boot/dts/nspire.dtsi >>> +++ b/arch/arm/boot/dts/nspire.dtsi >>> @@ -172,7 +172,14 @@ rtc: rtc@90090000 { >>> }; >>> >>> misc: misc@900a0000 { >>> + compatible = "ti,nspire-misc", "syscon", "simple-mfd"; >> >> You have syscon and simple-mfd, but bindings in patch #1 say only syscon. >> > > I'm not following, are you just saying my wording in the patch message just > wasn't complete? Your binding patch adds nspire compatible to the list of two items, so you have two items in total - nspire followed by syscon. What you implemented here is different. > > Or are you saying something more about nodes that are both syscon and simple-mfd? > In that case, having both syscon and simple-mfd seems rather common, looks like > you added the rule for it[0]. > > Thinking on this, they almost represent the same thing. simple-mfd says "my child > nodes should be considered devices", why do we need that? Couldn't we simply state > that "syscon" node's children are always devices, I mean what else could they be, > syscon is an MFD after all (and lives in drivers/mfd/). No, syscon is not an MFD. Syscon means system controller and alone it does not have children. > > "syscon" often just says, others can use the registers within this node, so as a > different option, make "syscon" a property of "simple-mfd" nodes. I'm seeing all > these examples of devices that should have been children of the "syscon" device, > but instead use > > regmap = <&x>; > syscon = <&x>; > > or similar and put the device node out somewhere random. And in those cases, > wouldn't it have been more correct to use the normal "reg" and "regions" to > define the registers belonging to the child node/device?.. Sorry, I do not follow. How this is even related to your patch? Your bindings say A, DTS say B. A != B. This needs fixing. Unless you are asking me what your device is in general. This I don't really know, but if you want to use it as regmap provider for system registers and as a parent of syscon-based reboot device, then your device is syscon and simple-mfd. With a specific compatible. Was this your question? Best regards, Krzysztof
On 10/27/22 4:27 PM, Krzysztof Kozlowski wrote: > On 27/10/2022 17:07, Andrew Davis wrote: >> On 10/27/22 2:33 PM, Krzysztof Kozlowski wrote: >>> On 27/10/2022 14:13, Andrew Davis wrote: >>>> Writing this bit can be handled by the syscon-reboot driver. >>>> Add this node to DT. >>>> >>>> Signed-off-by: Andrew Davis <afd@ti.com> >>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> >>>> Tested-by: Fabian Vogt <fabian@ritter-vogt.de> >>>> Reviewed-by: Fabian Vogt <fabian@ritter-vogt.de> >>>> --- >>>> arch/arm/boot/dts/nspire.dtsi | 7 +++++++ >>>> 1 file changed, 7 insertions(+) >>>> >>>> diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi >>>> index bb240e6a3a6f..48fbc9d533c3 100644 >>>> --- a/arch/arm/boot/dts/nspire.dtsi >>>> +++ b/arch/arm/boot/dts/nspire.dtsi >>>> @@ -172,7 +172,14 @@ rtc: rtc@90090000 { >>>> }; >>>> >>>> misc: misc@900a0000 { >>>> + compatible = "ti,nspire-misc", "syscon", "simple-mfd"; >>> >>> You have syscon and simple-mfd, but bindings in patch #1 say only syscon. >>> >> >> I'm not following, are you just saying my wording in the patch message just >> wasn't complete? > > Your binding patch adds nspire compatible to the list of two items, so > you have two items in total - nspire followed by syscon. > > What you implemented here is different. > Is there a list of three items I can add this compatible? If instead you mean I should go make a new binding, just say so :) >> >> Or are you saying something more about nodes that are both syscon and simple-mfd? >> In that case, having both syscon and simple-mfd seems rather common, looks like >> you added the rule for it[0]. >> >> Thinking on this, they almost represent the same thing. simple-mfd says "my child >> nodes should be considered devices", why do we need that? Couldn't we simply state >> that "syscon" node's children are always devices, I mean what else could they be, >> syscon is an MFD after all (and lives in drivers/mfd/). > > No, syscon is not an MFD. Syscon means system controller and alone it > does not have children. > The binding lives in devicetree/bindings/*mfd*/, it is mentioned as one in devicetree/bindings/mfd/mfd.txt. If it is not an MFD then the bindings are giving out mixed signals here.. >> >> "syscon" often just says, others can use the registers within this node, so as a >> different option, make "syscon" a property of "simple-mfd" nodes. I'm seeing all >> these examples of devices that should have been children of the "syscon" device, >> but instead use >> >> regmap = <&x>; >> syscon = <&x>; >> >> or similar and put the device node out somewhere random. And in those cases, >> wouldn't it have been more correct to use the normal "reg" and "regions" to >> define the registers belonging to the child node/device?.. > > Sorry, I do not follow. How this is even related to your patch? > > Your bindings say A, DTS say B. A != B. This needs fixing. > I said it was compatible with "syscon", not that it is incompatible with "simple-mfd" devices. What I've done here gives no dtbs_check warnings and "devicetree/bindings/mfd/mfd.txt" explicitly allows what I am doing. Unless we do not consider the old bindings valid? If so, would you like me to convert mfd.txt to yaml, just let me know. > Unless you are asking me what your device is in general. This I don't > really know, but if you want to use it as regmap provider for system > registers and as a parent of syscon-based reboot device, then your > device is syscon and simple-mfd. With a specific compatible. Was this > your question? > Yes, I would like to use it as a regmap provider, my question here is a much more general one: why do I need to specify that in device tree? That is not a hardware description, my hardware is not "regmap" hardware. This "syscon" stuff feels like a bodge to make the Linux drivers and bus frameworks interact the way we want. I know at this point this has little to do with this series, but I'd like to just think this out for a moment. The latest Devicetree Specification talks about "simple-bus" as a special compatible that communicates that child nodes with compatible strings need probed also. ("simple-mfd" seems to be used the same way but without needing a "ranges" property..) Both of these are properties of a node, not something a device is "compatible" with. "compatibles" are also supposed to be listed "from most specific to most general", so which is more specific, "simple-mfd" or "syscon", etc.. Seems like Rob might agree[0], these are not really compatibles. We cant fix history, but for new nodes, instead of growing the problem and forcing these to be overloaded compatibles, we allow these to become new standard node properties. For instance: main_conf: syscon@43000000 { compatible = "ti,j721e-system-controller"; reg = <0x0 0x43000000 0x0 0x20000>; simple-bus; syscon; ... }; Thoughts? Thanks, Andrew [0] https://lore.kernel.org/all/CAL_JsqKiUcO76bo1GoepWM1TusJWoty_BRy2hFSgtEVMqtrvvQ@mail.gmail.com/ > Best regards, > Krzysztof >
On Mon, Oct 31, 2022 at 09:30:45AM -0500, Andrew Davis wrote: > On 10/27/22 4:27 PM, Krzysztof Kozlowski wrote: > > On 27/10/2022 17:07, Andrew Davis wrote: > > > On 10/27/22 2:33 PM, Krzysztof Kozlowski wrote: > > > > On 27/10/2022 14:13, Andrew Davis wrote: > > > > > Writing this bit can be handled by the syscon-reboot driver. > > > > > Add this node to DT. > > > > > > > > > > Signed-off-by: Andrew Davis <afd@ti.com> > > > > > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > > > > > Tested-by: Fabian Vogt <fabian@ritter-vogt.de> > > > > > Reviewed-by: Fabian Vogt <fabian@ritter-vogt.de> > > > > > --- > > > > > arch/arm/boot/dts/nspire.dtsi | 7 +++++++ > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > > diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi > > > > > index bb240e6a3a6f..48fbc9d533c3 100644 > > > > > --- a/arch/arm/boot/dts/nspire.dtsi > > > > > +++ b/arch/arm/boot/dts/nspire.dtsi > > > > > @@ -172,7 +172,14 @@ rtc: rtc@90090000 { > > > > > }; > > > > > misc: misc@900a0000 { > > > > > + compatible = "ti,nspire-misc", "syscon", "simple-mfd"; > > > > > > > > You have syscon and simple-mfd, but bindings in patch #1 say only syscon. > > > > > > > > > > I'm not following, are you just saying my wording in the patch message just > > > wasn't complete? > > > > Your binding patch adds nspire compatible to the list of two items, so > > you have two items in total - nspire followed by syscon. > > > > What you implemented here is different. > > > > Is there a list of three items I can add this compatible? If instead you > mean I should go make a new binding, just say so :) An MFD should define its own schema file. The original intent of syscon.yaml was for just single nodes with 'syscon' (and a specific compatible). Adding in simple-mfd was probably a mistake. Certainly we need to rework the schema as you should get a warning in this case. > > > Or are you saying something more about nodes that are both syscon and simple-mfd? > > > In that case, having both syscon and simple-mfd seems rather common, looks like > > > you added the rule for it[0]. > > > > > > Thinking on this, they almost represent the same thing. simple-mfd says "my child > > > nodes should be considered devices", why do we need that? Couldn't we simply state > > > that "syscon" node's children are always devices, I mean what else could they be, > > > syscon is an MFD after all (and lives in drivers/mfd/). > > > > No, syscon is not an MFD. Syscon means system controller and alone it > > does not have children. > > > > The binding lives in devicetree/bindings/*mfd*/, it is mentioned as one > in devicetree/bindings/mfd/mfd.txt. If it is not an MFD then the bindings > are giving out mixed signals here.. > > > > > > > "syscon" often just says, others can use the registers within this node, so as a > > > different option, make "syscon" a property of "simple-mfd" nodes. I'm seeing all > > > these examples of devices that should have been children of the "syscon" device, > > > but instead use > > > > > > regmap = <&x>; > > > syscon = <&x>; > > > > > > or similar and put the device node out somewhere random. And in those cases, > > > wouldn't it have been more correct to use the normal "reg" and "regions" to > > > define the registers belonging to the child node/device?.. > > > > Sorry, I do not follow. How this is even related to your patch? > > > > Your bindings say A, DTS say B. A != B. This needs fixing. > > > > I said it was compatible with "syscon", not that it is incompatible > with "simple-mfd" devices. > > What I've done here gives no dtbs_check warnings and > "devicetree/bindings/mfd/mfd.txt" explicitly allows what I am doing. > Unless we do not consider the old bindings valid? Only that the example is not because it doesn't have a specific compatible. What needs to be clarified is that MFDs must define all the child nodes whether they are 'simple' or not. > If so, would you > like me to convert mfd.txt to yaml, just let me know. No, because I don't think there is anything to define as a schema. > > Unless you are asking me what your device is in general. This I don't > > really know, but if you want to use it as regmap provider for system > > registers and as a parent of syscon-based reboot device, then your > > device is syscon and simple-mfd. With a specific compatible. Was this > > your question? > > > > Yes, I would like to use it as a regmap provider, my question here is > a much more general one: why do I need to specify that in device tree? > That is not a hardware description, my hardware is not "regmap" hardware. > This "syscon" stuff feels like a bodge to make the Linux drivers and bus > frameworks interact the way we want. Bingo! It's a hint for create a regmap. We could just have a compatible list in the kernel for compatibles needing a regmap. Maybe that list would be too long though. So call it h/w description for this h/w is referenced by other places. > I know at this point this has little to do with this series, but I'd like > to just think this out for a moment. The latest Devicetree Specification > talks about "simple-bus" as a special compatible that communicates that > child nodes with compatible strings need probed also. ("simple-mfd" seems > to be used the same way but without needing a "ranges" property..) Yes, both cases are saying there is no dependency or setup of the parent needs. If the child nodes depend on the regmap, then it's not a 'simple-mfd' IMO. Therefore 'syscon' together with 'simple-mfd' is wrong unless it's other nodes that need the regmap. The schema can't really check that. > Both of these are properties of a node, not something a device is "compatible" > with. "compatibles" are also supposed to be listed "from most specific to > most general", so which is more specific, "simple-mfd" or "syscon", etc.. I would say 'syscon' is more specific if I have to pick. It implies some registers exist. 'simple-mfd' should mean there are no parent resources (...the children depend on). We've probably got enough of a mixture of the order, it wouldn't be worth the effort to try to enforce the order here. > Seems like Rob might agree[0], these are not really compatibles. We cant fix > history, but for new nodes, instead of growing the problem and forcing these to > be overloaded compatibles, we allow these to become new standard node properties. > > For instance: > > main_conf: syscon@43000000 { > compatible = "ti,j721e-system-controller"; > reg = <0x0 0x43000000 0x0 0x20000>; > > simple-bus; > syscon; Umm, no. This ship already sailed and we don't need a 2nd way to do things. Rob
On 10/31/22 12:14 PM, Rob Herring wrote: > On Mon, Oct 31, 2022 at 09:30:45AM -0500, Andrew Davis wrote: >> On 10/27/22 4:27 PM, Krzysztof Kozlowski wrote: >>> On 27/10/2022 17:07, Andrew Davis wrote: >>>> On 10/27/22 2:33 PM, Krzysztof Kozlowski wrote: >>>>> On 27/10/2022 14:13, Andrew Davis wrote: >>>>>> Writing this bit can be handled by the syscon-reboot driver. >>>>>> Add this node to DT. >>>>>> >>>>>> Signed-off-by: Andrew Davis <afd@ti.com> >>>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> >>>>>> Tested-by: Fabian Vogt <fabian@ritter-vogt.de> >>>>>> Reviewed-by: Fabian Vogt <fabian@ritter-vogt.de> >>>>>> --- >>>>>> arch/arm/boot/dts/nspire.dtsi | 7 +++++++ >>>>>> 1 file changed, 7 insertions(+) >>>>>> >>>>>> diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi >>>>>> index bb240e6a3a6f..48fbc9d533c3 100644 >>>>>> --- a/arch/arm/boot/dts/nspire.dtsi >>>>>> +++ b/arch/arm/boot/dts/nspire.dtsi >>>>>> @@ -172,7 +172,14 @@ rtc: rtc@90090000 { >>>>>> }; >>>>>> misc: misc@900a0000 { >>>>>> + compatible = "ti,nspire-misc", "syscon", "simple-mfd"; >>>>> >>>>> You have syscon and simple-mfd, but bindings in patch #1 say only syscon. >>>>> >>>> >>>> I'm not following, are you just saying my wording in the patch message just >>>> wasn't complete? >>> >>> Your binding patch adds nspire compatible to the list of two items, so >>> you have two items in total - nspire followed by syscon. >>> >>> What you implemented here is different. >>> >> >> Is there a list of three items I can add this compatible? If instead you >> mean I should go make a new binding, just say so :) > > An MFD should define its own schema file. > > The original intent of syscon.yaml was for just single nodes with > 'syscon' (and a specific compatible). Adding in simple-mfd was probably > a mistake. Certainly we need to rework the schema as you should get a > warning in this case. > >>>> Or are you saying something more about nodes that are both syscon and simple-mfd? >>>> In that case, having both syscon and simple-mfd seems rather common, looks like >>>> you added the rule for it[0]. >>>> >>>> Thinking on this, they almost represent the same thing. simple-mfd says "my child >>>> nodes should be considered devices", why do we need that? Couldn't we simply state >>>> that "syscon" node's children are always devices, I mean what else could they be, >>>> syscon is an MFD after all (and lives in drivers/mfd/). >>> >>> No, syscon is not an MFD. Syscon means system controller and alone it >>> does not have children. >>> >> >> The binding lives in devicetree/bindings/*mfd*/, it is mentioned as one >> in devicetree/bindings/mfd/mfd.txt. If it is not an MFD then the bindings >> are giving out mixed signals here.. >> >>>> >>>> "syscon" often just says, others can use the registers within this node, so as a >>>> different option, make "syscon" a property of "simple-mfd" nodes. I'm seeing all >>>> these examples of devices that should have been children of the "syscon" device, >>>> but instead use >>>> >>>> regmap = <&x>; >>>> syscon = <&x>; >>>> >>>> or similar and put the device node out somewhere random. And in those cases, >>>> wouldn't it have been more correct to use the normal "reg" and "regions" to >>>> define the registers belonging to the child node/device?.. >>> >>> Sorry, I do not follow. How this is even related to your patch? >>> >>> Your bindings say A, DTS say B. A != B. This needs fixing. >>> >> >> I said it was compatible with "syscon", not that it is incompatible >> with "simple-mfd" devices. >> >> What I've done here gives no dtbs_check warnings and >> "devicetree/bindings/mfd/mfd.txt" explicitly allows what I am doing. >> Unless we do not consider the old bindings valid? > > Only that the example is not because it doesn't have a specific > compatible. > > What needs to be clarified is that MFDs must define all the child nodes > whether they are 'simple' or not. > >> If so, would you >> like me to convert mfd.txt to yaml, just let me know. > > No, because I don't think there is anything to define as a schema. > It would allow for simple register regions to be 'simple-mfd' without needing a whole new binding document for each. Same as we already have with 'syscon.yaml'. Making every simple MMIO space create a new binding document is not reasonable. Neither is defining all nodes up front in that binding, we don't expect that for top level nodes or 'simple-bus', why should we for 'simple-mfd'? My point with mfd.txt is that this *was allowed*, and there are already a large number of users of the existing style. > >>> Unless you are asking me what your device is in general. This I don't >>> really know, but if you want to use it as regmap provider for system >>> registers and as a parent of syscon-based reboot device, then your >>> device is syscon and simple-mfd. With a specific compatible. Was this >>> your question? >>> >> >> Yes, I would like to use it as a regmap provider, my question here is >> a much more general one: why do I need to specify that in device tree? >> That is not a hardware description, my hardware is not "regmap" hardware. >> This "syscon" stuff feels like a bodge to make the Linux drivers and bus >> frameworks interact the way we want. > > Bingo! It's a hint for create a regmap. We could just have a compatible > list in the kernel for compatibles needing a regmap. Maybe that list > would be too long though. So call it h/w description for this h/w is > referenced by other places. > > >> I know at this point this has little to do with this series, but I'd like >> to just think this out for a moment. The latest Devicetree Specification >> talks about "simple-bus" as a special compatible that communicates that >> child nodes with compatible strings need probed also. ("simple-mfd" seems >> to be used the same way but without needing a "ranges" property..) > > Yes, both cases are saying there is no dependency or setup of the parent > needs. If the child nodes depend on the regmap, then it's not a > 'simple-mfd' IMO. Therefore 'syscon' together with 'simple-mfd' is wrong > unless it's other nodes that need the regmap. The schema can't really > check that. > 'syscon' also provides for reusing the same single register by multiple users, such as bit-mapped registers. It also allows re-using the existing simple syscon device compatibles. Again because people do not like writing bindings for simple nodes. Andrew >> Both of these are properties of a node, not something a device is "compatible" >> with. "compatibles" are also supposed to be listed "from most specific to >> most general", so which is more specific, "simple-mfd" or "syscon", etc.. > > I would say 'syscon' is more specific if I have to pick. It implies some > registers exist. 'simple-mfd' should mean there are no parent resources > (...the children depend on). > > We've probably got enough of a mixture of the order, it wouldn't be > worth the effort to try to enforce the order here. > >> Seems like Rob might agree[0], these are not really compatibles. We cant fix >> history, but for new nodes, instead of growing the problem and forcing these to >> be overloaded compatibles, we allow these to become new standard node properties. >> >> For instance: >> >> main_conf: syscon@43000000 { >> compatible = "ti,j721e-system-controller"; >> reg = <0x0 0x43000000 0x0 0x20000>; >> >> simple-bus; >> syscon; > > Umm, no. This ship already sailed and we don't need a 2nd way to do > things. > > Rob
diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi index bb240e6a3a6f..48fbc9d533c3 100644 --- a/arch/arm/boot/dts/nspire.dtsi +++ b/arch/arm/boot/dts/nspire.dtsi @@ -172,7 +172,14 @@ rtc: rtc@90090000 { }; misc: misc@900a0000 { + compatible = "ti,nspire-misc", "syscon", "simple-mfd"; reg = <0x900a0000 0x1000>; + + reboot { + compatible = "syscon-reboot"; + offset = <0x08>; + value = <0x02>; + }; }; pwr: pwr@900b0000 {