[PATCH v2 3/4] hw/riscv: virt: fix syscon subnode paths
Conor.Dooley at microchip.com
Conor.Dooley at microchip.com
Mon Aug 8 23:26:09 PDT 2022
On 09/08/2022 00:10, Rob Herring wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Mon, Aug 8, 2022 at 4:10 PM <Conor.Dooley at microchip.com> wrote:
>>
>> On 08/08/2022 22:28, Jessica Clarke wrote:
>>> Moreover, what is the point of regmap in this
>>> case? Its existence suggests the point is for them to *not* be children
>>> of the syscon, otherwise you wouldn’t need an explicit phandle, you’d
>>> just look at the parent. Moving the nodes whilst keeping the property
>>> doesn’t make sense to me.
>>
>> That's how syscon bindings are constructed, makes it easier to follow
>> I suppose if they functions are children of the syscon node. Strictly
>> I think they don't need to be under the syscon itself, I think they can
>> also go at the top level - they just aren't valid under the /soc node
>> as it has been defined as a "simple-bus".
>>
>> It would appear that the original patch 0e404da007 ("riscv/virt: Add
>> syscon reboot and poweroff DT nodes") that added them put them at the
>> top level and it was in the refactor that they got moved to the soc bus.*
>> Maybe the solution would be to put them back at the top level?
>
> Perhaps.
>
> The other option is adding 'simple-mfd' to the 'test' node compatible.
> That would work for Linux. Not sure for FreeBSD.
Right, of course I was missing something in my understanding. The probe
flow on Linux came back to me on the bike this morning after reading this
and I felt like an idiot for missing that in the devicetrees I looked at!
@Jess, which does FreeBSD prefer? top level or add the extra compatible?
Thanks,
Conor.
More information about the linux-riscv
mailing list