Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller

From: "Sven Peter" <sven@svenpeter.dev>
To: "Rob Herring" <robh@kernel.org>, "Hector Martin" <marcan@marcan.st>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
	"Mark Kettenis" <mark.kettenis@xs4all.nl>,
	krzysztof.kozlowski@linaro.org, "Arnd Bergmann" <arnd@arndb.de>,
	"Lee Jones" <lee@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Alyssa Rosenzweig" <alyssa@rosenzweig.io>,
	asahi@lists.linux.dev, "Bartosz Golaszewski" <brgl@bgdev.pl>,
	linux-arm-kernel@lists.infradead.org,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller
Date: Tue, 06 Sep 2022 19:40:18 +0200	[thread overview]
Message-ID: <0cbfd45e-4749-424e-8c28-362d9b4f435e@www.fastmail.com> (raw)
In-Reply-To: <20220906173535.GA734389-robh@kernel.org>

On Tue, Sep 6, 2022, at 19:35, Rob Herring wrote:
> On Wed, Sep 07, 2022 at 02:00:53AM +0900, Hector Martin wrote:
>> On 07/09/2022 01.10, Rob Herring wrote:
>> >> So at this point, I think it would make sense if I post a v2 with all
>> >> the updates so far (sorry, given the long drawn out discussions on
>> >> this, I've lost track of what changes have been made to the code, so
>> >> I won't include a detailed change log.)
>> > 
>> > As I said elsewhere, sub-nodes is probably the right choice here. I 
>> > think they need compatible strings in the child nodes, and addressing 
>> > has to be sorted out which it seems may also break OpenBSD.
>> 
>> So addressing only makes sense for GPIO, out of the nodes we have so far
>> - that's the only thing with two discrete instances whose access can be
>> entirely described by a single base key name, and which are otherwise
>> compatible.
>> 
>> Everything else is pretty much single-instance, and talks to multiple
>> keys, so there isn't one single "address" key that would make semantic
>> sense to use as the node address. 
>
> Unit-addresses are just the first address in 'reg'. So multiple 
> addresses or not doesn't really matter.
>
>> There are some indexed keys, but at a
>> deeper level (e.g. multiple battery cells part of the charge control
>> subsystem, multiple Type C ports as part of the AC/power input
>> subsystem, etc.). And in those cases, these subdevices are mostly
>> homogeneous and we would never need multiple nodes for them at the DT
>> level, they'd just be implicitly handled by those drivers.
>
> Type-C will be fun depending on how much of the muxing/altmode 
> details have to get exposed. 

Type-C is going to be a lot of "fun", but the SMC is not directly involved.

I still don't have a full picture but these boards have TPS6598x chips
which trigger the entire mess whenever a new mode was negotiated and the
"Apple Type-C PHY" contains the actual mux.

The SMC has a side channel to these TPS6598x chips as well but it seems
to only handle charging without having to communicate with whatever kernel
is running on the main processor.

Sven

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel