Re: [PATCH v2 2/8] dt-bindings: arm: apple: Add apple,pmgr binding
From: Hector Martin <hidden>
Date: 2021-10-29 07:09:14
Also in:
linux-devicetree, linux-pm, linux-samsung-soc, linux-serial, lkml
On 27/10/2021 23.51, Krzysztof Kozlowski wrote:
On Wed, 27 Oct 2021 at 16:44, Rob Herring [off-list ref] wrote:quoted
On Tue, Oct 26, 2021 at 10:38 PM Hector Martin [off-list ref] wrote:quoted
On 27/10/2021 03.25, Rob Herring wrote:quoted
On Mon, Oct 25, 2021 at 11:47:12PM +0900, Hector Martin wrote:quoted
+ 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.Hi Hector, I thought I mentioned this with your v1, maybe the comment got lost. We have it for Exynos PMU: drivers/soc/samsung/exynos-pmu.c arch/arm/boot/dts/exynos-syscon-restart.dtsi (extending node from arch/arm/boot/dts/exynos5420.dtsi) Maybe you can base on that.
Ah, I remember the discrete power domains but I missed this syscon. I see this is mostly used for poweroff/reboot, which makes sense in this context. For pmgr though, the binding only describes the uniform power state registers, so I think I'm comfortable leaving it as a simple-mfd. Other pmgr sub-blocks will probably end up as separate nodes with different bindings anyway (e.g. whatever I do for the clock muxes, need to see how that ties in with audio which I think is the only consumer so far). If things get more complicated in future SoCs then we can change how we do it on those, of course :) -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel