On Tue, Oct 26, 2021 at 10:38 PM Hector Martin <marcan@xxxxxxxxx> wrote: > > On 27/10/2021 03.25, Rob Herring wrote: > > On Mon, Oct 25, 2021 at 11:47:12PM +0900, Hector Martin wrote: > >> + compatible: > >> + items: > >> + - enum: > >> + - apple,t8103-pmgr > >> + - apple,t8103-minipmgr > >> + - const: apple,pmgr > >> + - const: syscon > >> + - const: simple-mfd > > > > > > 'simple-mfd' means 'there's nothing in this node that any of the child > > nodes depend on'. You should be somewhat certain as dropping it later > > creates compatibility issues. > > Hmm, I see simple-mfd turns this into a bus which I guess allows child > nodes to be probed without the parent node doing anything special (then > we use syscon_node_to_regmap to get the syscon instantiated). Do you > have a example use case for doing this without simple-mfd? Drivers calling of_platform_populate or devm_of_platform_populate. That of course does mean you need a driver. We could probably make the syscon driver call these if needed. > At this point I can't think of anything we'd need from the parent node, > especially if we end up using this syscon strictly for pwrstate subnodes > (which seems likely at this point). One thing that comes to mind is > telling the PMP (a coprocessor in charge of power metrics/management) > about some domains being turned on/off, which is apparently a thing, but > that wouldn't even be in this node; that'd have to be a phandle property > in the child nodes referencing a PMP/coprocessor node elsewhere (none of > which is implemented right now, and which should be backwards compatible > once it is). > > If it turns out we do have a dep of some sort in the end, could we just > have the child node driver return -EPROBE_DEFER until the parent is > probed and has made whatever service available? That would allow us to > keep simple-mfd, right? That would have saved you, but deferred probe is now a fallback to fw_devlink and it makes sure parent driver probes first. That works unless there isn't a parent driver which is often the case for simple-bus[1]. I think you are okay since 'syscon' means there is a driver. > If it works for you, I'll also just squash the two bindings into one > commit for the next spin, since there is a direct dependency at this > point and it should make things easier. Otherwise, I can just swap the > order if you prefer it that way. Just swapping seems like less work, but either way. Rob [1] https://lore.kernel.org/all/CAL_JsqJcsqjJBe8aULYYMkFtx8OTj2wHANZ=83VMMyJ=AEgReg@xxxxxxxxxxxxxx/
