From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: ATA ACPI (was Re: Linux 2.6.21-rc5) Date: Tue, 27 Mar 2007 14:48:18 -0400 Message-ID: <460966F2.4010307@garzik.org> References: <4608B0CA.1040005@garzik.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from srv5.dvmed.net ([207.36.208.214]:38234 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934161AbXC0SsV (ORCPT ); Tue, 27 Mar 2007 14:48:21 -0400 In-Reply-To: Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Linus Torvalds Cc: IDE/ATA development list , Linux Kernel Mailing List , Alan , Tejun Heo , Len Brown , Kristen Carlson Accardi Linus Torvalds wrote: > > On Tue, 27 Mar 2007, Jeff Garzik wrote: >> FWIW, I'm still leaning towards disabling libata ACPI support by default for >> 2.6.21. > > Hey, I'm not going to argue against anything that says "disable ACPI". Of > *course* it should be disabled if there aren't thousands of machines that > are in user hands that actually need it (and none that regress). It's required to access data at all (BIOS-supplied password [un]locks disk), in a small minority of configurations. It's strongly suggested for reliable suspend/resume, particularly on laptops, where libata ACPI support fixes some suspend/resume problems. Some BIOSen also want to apply drive+board-specific errata workarounds. That's OK, but ideally we should know about those in the kernel. "none that regress" is the problem though. Buggy tables, unexercised ACPI code paths, and in a few cases unexpected post-ACPI drive/controller behavior expose regressions. > Anybody want to send me a patch? Since everybody is OK with my plan, I'll send one today along with the rest of the post-vacation 2.6.21-rc bug fixes. Jeff