Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2401847pxb; Fri, 29 Oct 2021 00:10:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxgheCJyCA0KqIqUFgHZtGlUIIY/nmYSB9t07oIq3eGkz2hP7KIXoBofS9Bmg8KrvGiJ9dw X-Received: by 2002:a17:902:f686:b0:140:3913:8342 with SMTP id l6-20020a170902f68600b0014039138342mr8348756plg.43.1635491441818; Fri, 29 Oct 2021 00:10:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635491441; cv=none; d=google.com; s=arc-20160816; b=wZiRObQT8pnjN41/k1yzipvETgInko5nxZLZ6B8hclKHFWacSHjDrFxsor2xMwKzhQ flN4p+5LTB9THrem8Yhp4C8YWchVEm+MhegR3R8vQqJPcECiFNRb9iVMFYRxWOFHb+PN 16NXeICb+CHAzMH6ozDoeSoIYKY9P4I8idXKwMLZgOC1R3JNz9/Ub+kXPEOV225b05s/ Xz3M+L0h77KDuEWuyDZT3PDx6VbcQ8iQjRB+Xw+W+ABwA1kp8qZ/3gltDWRrEQXtpA+i Djgtud+L+40LK1AEKESkw36tVgAREPT9NNJxhb4TWl4w3siwrLaD0I5fgAHRgU9QoBvd 976Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to; bh=QWDr8CG71q624CGfuaWaobOFzqVgbzxp/Yam+bISHRU=; b=he/0GLdc4fxuMU4C3BeoRqv9SOzqqyjki7QhtmfxvCRaY9SfxysXMDFxxLFdfQLuuH g7FjtGMbM4wT8BtNMbY9C7s7apC8jxgAWo00pTNO5gzvAg/R+XYljh17D+UiHeK2LoI8 dInBH4hRNHkhx3M3GXFqFUgQ/9OFS4si7AZnSpFClS6UcPM1RiFDn2ve+6yAAvC29KRT JLJjn4VnKHQYv4hU33dq0eKUoSjcf43LFwSd5YjFz9Wfx6ayJMn6hogHN9ccvRhdOExv 2Koy2bSnjiwVMMS4NWZUfRxt4G0ZJ1v65WM7wc9BDQMQrpcjiPcmjKYxTg9sFaEvISse Ef0Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=marcan.st Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 68si3129483pfe.367.2021.10.29.00.10.28; Fri, 29 Oct 2021 00:10:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=marcan.st Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232141AbhJ2HLk (ORCPT + 99 others); Fri, 29 Oct 2021 03:11:40 -0400 Received: from marcansoft.com ([212.63.210.85]:49316 "EHLO mail.marcansoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229464AbhJ2HLj (ORCPT ); Fri, 29 Oct 2021 03:11:39 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id 02A34424B9; Fri, 29 Oct 2021 07:09:04 +0000 (UTC) To: Krzysztof Kozlowski Cc: Rob Herring , linux-arm-kernel , Marc Zyngier , Arnd Bergmann , Linus Walleij , Alyssa Rosenzweig , Greg Kroah-Hartman , Mark Kettenis , Philipp Zabel , "Rafael J. Wysocki" , Johan Hovold , devicetree@vger.kernel.org, "open list:THERMAL" , "linux-kernel@vger.kernel.org" , linux-samsung-soc , "open list:SERIAL DRIVERS" , Mark Kettenis References: <20211025144718.157794-1-marcan@marcan.st> <20211025144718.157794-3-marcan@marcan.st> From: Hector Martin Subject: Re: [PATCH v2 2/8] dt-bindings: arm: apple: Add apple,pmgr binding Message-ID: <0614b9ba-79f8-afc5-793d-6d465df51bed@marcan.st> Date: Fri, 29 Oct 2021 16:09:02 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: es-ES Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 27/10/2021 23.51, Krzysztof Kozlowski wrote: > On Wed, 27 Oct 2021 at 16:44, Rob Herring wrote: >> >> On Tue, Oct 26, 2021 at 10:38 PM Hector Martin 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. >> > > 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