On Tue, Sep 06, 2022 at 10:28:25PM +0900, Hector Martin wrote: > Ultimately, we're working with a reverse engineered platform here, and > DTs will inevitaby be incremental. But in this particular case, of > hardware that has no known useful purpose to an OS, I don't see the > point in gratuitously describing it. And besides, the way we set things > up, forward-compatible DT upgrades are trivial, and no actual user on > this platform is going to be stuck with an old DT and newer software (if > their software supports the platform properly, and that takes more than > the relatively trivial DT upgrade stuff anyway). I'm a lot more > interested in getting bindings upstreamed ASAP (so we can start > guaranteeing no backwards-compat breaks, which is important to avoid > outright breakage) than I am in trying to be exhaustive up front with > device instances. It's perfectly fine to say that users have to upgrade > both their DTs and kernels to get newer hardware support, on these > platforms. It's also a very common process for SoCs - almost no one writes the DT first and then writes the drivers. You always see on the mailing list series of patches that add a driver for some bit of hardware, along with patches adding the DT binding and the DT description. I don't think you're doing anything different here to what is common practice within the mainline kernel community with this approach. The exception to that is when adding a driver for feature X in a SoC, it's common to add all instances of X to the dtsi with ``status = "disabled"'' and only enable the appropriate blocks on platforms that need it. So, for example, if a SoC has three network interfaces, all of them identical, when adding a network driver and the bindings for the network hardware, one would add all three to the SoC description whether or not the platform one was working with makes use of them. It means that one has to think about how to support all instances of the hardware on the platform and design the binding to allow that flexibility, rather than having to augment the binding later. In the case of gpio-macsmc, how would we later add support for the slave PMU GPIOs, given that these use keys "gpXX" rather than "gPxx"? How do we tell the gpio-macsmc code to use a different set of keys? Should DT describe the key "prefix" (in other words "gp" vs "gP"), or should it describe it some other way. What if Apple decides to instantiate another GPIO controller in a later platform with a different prefix, could that be accomodated without breaking any solution we come up today? Maybe the solution to this would be to describe the key prefix in DT as that's effectively its "reg". Or maybe we use "reg" to describe it somehow (which is value of the key, which seems to have an "address" like quality to it?) We don't have to implement code for this now, we just need to get a reasonably correct DT binding for the gpio controller. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
