On Wed, Jan 14, 2015 at 3:04 PM, Hanjun Guo <hanjun.guo@xxxxxxxxxx> wrote: > Hi, > > This is the v7 of ACPI core patches for ARM64 based on ACPI 5.1 Hi Catalin and Will, I'll get right to the point: Can we please have this series queued up for v3.20? I really think we've hit the point where it is more valuable to merge it (or at least prepare to merge it) rather than keeping it out of mainline. First, I think we've agreed that the patches themselves are fine. The remaining objections are based on maturity and whether or not we can handle long term support. At this point, for all of the items on Al's ACPI todo list, we've either got solutions for the problems, or solid plans on how it is going to get solved (I'll go through each item one by one at the end of this email). I won't claim that list is exhaustive though. Please shout if there are new issues that need to be added. Second, real platforms using ACPI are showing up in various places. Platforms are available from both APM and AMD. Huawei have spoken up with test results that the patches boot on their unreleased platform (Huawei needs GICv3 extensions, but otherwise it works). The commercial products that are being built right now are being built around these patches. Fedora Rawhide has picked them up also. Continuing to keep the patches out I think is having the opposite effect from what is desired. Catalin, you've told me a few times that saying "no" is the only leverage you have to keeping crap drivers out of the kernel until things mature, and by extension influence how firmware gets implemented. However, as far as drivers are concerned, there is nothing stopping maintainers from picking up ACPI drivers for ARM hardware regardless of whether or not the core ARM code is merged. If a driver depends on CONFIG_ACPI, and if the code seems to look good, there is nothing preventing it from being merged. There are already ARM related ACPI patches going into mainline. For example: https://lkml.org/lkml/2014/12/25/120 Instead, keeping these patches out means that hardware is getting developed and tested against Fedora, early access RHEL and Linaro kernels. It means that we're abdicating on any influence mainline has over how those platforms are developed. The longer these patches stay out of mainline, the greater the potential for delta between what is in the vendor kernels and what we accept into mainline. The other concern may be keeping crap out of the core ARM code, but I really don't think that will be an issue. The two of you still have complete control over arch/arm64 and I fully expect crap code will be aggressively NAKed whether or not it is ACPI related. All that merging this series does is lays down a foundation of functionality on the stuff we are pretty confident is correct. It keeps the delta between mainline and the development code small and restricted to only the bits that are still in flux. Finally, keeping them out has the practical effect of causing extra work to continually rebase them, while potentially running into new conflicts and bugs, for little if any real benefit. Whereas getting them into linux-next starts giving us some feedback on conflicts with other things that are being queued up for mainline. Not to mention reviewer fatigue having to go over the same set of patches again and again. Right now we're at -rc4. We'll be at -rc5 this weekend, and quite possibly have a new merge window right at the start of Connect. Queuing these patches up now isn't even a 100% commitment for you to ask Linus to pull them. We can have further discussions at Connect. If you're still not satisfied then drop them out again for another cycle. However, if they aren't queued up now, then we're looking at mid-June before they show up in a mainline kernel release. As promised earlier, I said that I'd go through the todo list items. Here they are with discussion: 1. Define how Aarch64 OS identifies itself to firmware - We've pretty much settled on dropping the _OSI interface entirely, which is trivial to do. All of the current platforms can adapt to this. There are still some discussions around _OSC, but given that this is the first release there isn't anything for the platform to differentiate on regarding features. This isn't going to affect current platforms, but rather will be important with the release of the next version of the ACPI spec. It shouldn't affect our ability to merge core support 2. Linux must choose DT booting by default when offered both ACPI and * Status: DONE, but being revisited for possible algorithmic change 3. Linux UEFI/ACPI testing tools must be made available * Done. We're implementing more tests of course, but that is expected. 4. Set clear expectations for those providing ACPI for use with Linux * We have a document that covers what we know so far, and will continue to expand it. Also talking with the SBBR folks to move relevant requirements into the SBBR doc. 5. Platform support patches need verification and review * ACPI core works on at least the Foundation model, Juno, APM Mustang, and AMD Seattle * There still are driver patches being discussed. See Al's summary for details * As I argued above, the state of driver patches isn't going to be 6. How does the kernel handle_DSD usage? While important, these issues are separate from whether or not to merge the core aarch64 code. This work was defined and driven by Intel for their embedded platforms, and it is already in mainline. Keeping aarch64 support out isn't going to prevent drivers using it from being merged. I don't think this should be a reason for blocking this series. 7. Why is ACPI required? I hope I've addressed this[1], but discussion continues. [1] http://www.spinics.net/lists/arm-kernel/msg389955.html -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
