On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > On Tue, 19 Nov 2013 11:30:15 +0000, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > > The UEFI spec pulls in portions of ACPI. I do not know the full extent > > of the interaction between the two, but I know that they are not > > completely decoupled. As you have pointed out we are not experienced > > with ACPI or UEFI, so I don't think we can make statements that one is > > perfectly fine without the other. > > Not actually. The UEFI spec does define how to pass ACPI, but it can > boot the system without any ACPI at all. Merging UEFI support should > pretty much be a non-issue. > > > > > I think that trying to shoe-horn ACPI-derived information into device > > > > tree is fundamentally the wrong approach. I don't think it encourages > > > > best practices, and I don't think it's beneficial to the long term > > > > health of Linux or the ecosystem as a whole. > > > > > > There are no known best practices with ACPI. It's a complete fumbling > > > around in the dark right now. We're complaining about reviewer bandwith > > > on DT -- do we have a single reviewer for ACPI on ARM that actually > > > knows what a good solution looks like? I don't think so. > > > > There are many people in the Linux community who have ACPI experience. > > They may not be active on the ARM side, but it's not fair to say there > > are no known best practices. I will agree that for the level of > > variation we're likely to expect we are pushing the boundaries. > > We are pushing a lot of boundaries and doing things on ACPI that have > never been done before. SPI, GPIOs, Clocks, Regulators, composite > devices, key-value properties. All brand new territory, and the Linux > world is driving a lot of it. This is a bit of a surprise and a significant concern. The whole point behind ACPI is that it's supposed to abstract away nearly all of that, and _not_ expose clocks, regulators and other things to the kernel. If we're going to expose it, then we might as well go all the way and do it with DT. Exposing all the low-level details of the platform is very much an embedded mindset today. Servers don't do it with DT, nor with ACPI today. So if you're going to build a platform for servers that is modelled after what's done successfully so far, then sticking to that basic concept seems like an appropriate thing to do. > > > So, until there's strong evidence that ACPI is actually going to be > > > a sane solution, in other words, until someone has shipped a system > > > that uses it (with Windows) and does it successfully without being > > > a hot mess, we shouldn't litter the kernel with it. > > > > Again, I'm not sure that we should rely on Windows as our saviour from > > insanity. A lot of the issues we are going to encounter are going to be > > in vendor-specific code (i.e. drivers), and I do not believe that is > > solved by having a single entity in charge of the general frameworks > > those are built upon. > > Personally, I think the issue of ACPI support should be taken on a > patch-by-patch basis. A lot of the things that need to be done are quite > discrete and fairly well contained. If the patches don't look that way > then push back on them. For the parts that look ready, go ahead and > merge it. Push back on the ones that don't. The additional abstractions that are now pushed onto us has impact for everybody, and will cause churn on a lot of drivers. Things such as moving to named resources, etc. While it's easy to say "let's take the patches one by one", that also means nobody keeps an eye on the bigger picture and whether the whole thing makes sense or not. So, I think we need both. Of course we're going to review patches as they're posted (the alternative doesn't make sense). But we also need to know what the end goal is. Nobody is presenting that today, and until we know how steep the slippery slope will get (based on what we can see so far), we shouldn't start down it. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
