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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/09/2022 20.22, Linus Walleij wrote:
> On Tue, Sep 6, 2022 at 11:31 AM Mark Kettenis <mark.kettenis@xxxxxxxxx> wrote:
> 
>> Another argument for having sub-nodes is that the firmware actually
>> exposes *two* GPIO controllers.  For now we only support the "master"
>> PMU GPIOs, but there also is a "slave" PMU GPIO controller that uses a
>> separate set of SMC "keys".  We currently don't need any of the pins
>> on the "slave", so we don't expose it in the DT yet.
> 
> That sounds backward, like we don't expose device X as DT node
> because $OS doesn't use it yet. DT should just expose (by nodes or
> other ways) all hardware that exist or at least all hardware we know
> about no matter what $OS is using.

How so? The are piles and piles of unused hardware not exposed in the
DT, and piles and piles of hardware that will be used but we haven't
figured out how to do it yet, so it's not exposed. For example, we know
there are like 8 or so UARTs, but we don't define them in the DT because
they are not connected to anything on any existing device and we don't
need them. Apple does the same thing in their DTs (only used hardware is
defined).

I don't really see the point of exposing a GPIO controller when we don't
actually do anything with the pins yet, and might never do so. Having
drivers bind and stay unused just increases the amount of code running
without any ultimate purpose, so why do it? It's not like any other OS
would use the hardware either - GPIOs are only useful if they are
referenced in the DT for something, and we don't have anything that
would reference these.

For SMC in particular, there's a huge amount of functionality we don't
have drivers for yet, and I don't see the point of trying to conjure up
DT bindings for it until someone writes a driver (and has a reason to do
so) :)

> FWIW I think nodes makes most sense because no doubt for example
> the RTC is a separate hardware unit somewhere, and so is the
> GPIO. The fact that it is hidden behind a software abstraction doesn't
> change the fact that the HW definitely has these discrete units.

The RTC and the GPIO happen to be part of the same physical IC (PMU),
but yes, I agree.

- Hector



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux