Features Download
From: Grant Likely <grant.likely <at> secretlab.ca>
Subject: Re: ACPI vs DT at runtime
Newsgroups: gmane.linux.ports.arm.kernel
Date: Tuesday 19th November 2013 14:33:18 UTC (over 4 years ago)
On Mon, 18 Nov 2013 00:19:18 -0500, Jon Masters 
> > 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.
> It's going to be a messy thing to even attempt. Look, I wish we had a
> time machine and could have done this whole thing years ago, but I'm not
> sure it would have gone differently. ACPI is something a lot of people
> emotionally hate. In the Enterprise space myself and others *need* it
> (along with UEFI) to have a scalable solution that doesn't result in an
> onslaught of customer support calls, which a non-standards body backed
> moving target of DTB will do.

I think that sells our entire community short. The Linux kernel itself is
nowhere near standards body backed, and the userspace ABI is absolutely
stable. It's stable because we've made stability a priority. Linus and
others have been vocal about it, and maintainers have enforced it.
Suggesting the lack of a standards body means we're left with a moving
target is clearly not true.

As much as we hoped ARM ACPI support would be complete by now and merged
into the kernel, it isn't. I really can't fault (or expect) any hardware
vendor to ship only ACPI when support for it isn't in mainline.

As for DT, we discussed DT stability at length in Edinburgh. We've made
the commitment to support shipped hardware. If hardware ships with a DT
that boots on mainline, then we will not break it.

> And besides all of the big boys are going
> to be using ACPI whether it's liked much or not.

I have to call that statement out as over the line. It comes across as
attempting to shame maintainers into accepting ACPI, and further implies
that non-ACPI users are not "big boys" and therefore just playing
around. That is not okay.

The ACPI support patches must satisfy maintainers before they will be
accepted. This is normal and we've done this before. The current patches
raise serious concerns, but they're also generating constructive
feedback. If ACPI isn't there in time then we can support the hardware
with DT, whether it is provided by the firmware (preferred), or shipped
with the kernel.

CD: 3ms