On Saturday 10 March 2007 06:30, Jeff Garzik wrote: > Linux Kernel Mailing List wrote: > > Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=df33c77e3981e71afc8727ee5c432ba1a1bba68c > > Commit: df33c77e3981e71afc8727ee5c432ba1a1bba68c > > Parent: 908e0a8a265fe8057604a9a30aec3f0be7bb5ebb > > Author: Kristen Accardi <kristen.c.accardi@xxxxxxxxx> > > AuthorDate: Fri Mar 9 18:15:33 2007 -0500 > > Committer: Len Brown <len.brown@xxxxxxxxx> > > CommitDate: Fri Mar 9 18:15:33 2007 -0500 > > > > libata-acpi: allow _GTF on SATA, but disable on PATA for now > > > > The ACPI specification states, and BIOS implementations depend on, > > _STM being called before _GTF. > > > > SATA does this, but PATA does not. So for now, simply > > prevent execution of _GTF on PATA devices. Longer term we > > should implement ACPI support for PATA devices in libata. > > > > Signed-off-by: Kristen Accardi <kristen.c.accardi@xxxxxxxxx> > > Signed-off-by: Len Brown <len.brown@xxxxxxxxx> > > --- > > drivers/ata/libata-acpi.c | 7 +++++++ > > 1 files changed, 7 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c > > index d14a48e..89aaf74 100644 > > --- a/drivers/ata/libata-acpi.c > > +++ b/drivers/ata/libata-acpi.c > > @@ -561,6 +561,13 @@ int ata_acpi_exec_tfs(struct ata_port *ap) > > > > if (noacpi) > > return 0; > > + /* > > + * TBD - implement PATA support. For now, > > + * we should not run GTF on PATA devices since some > > + * PATA require execution of GTM/STM before GTF. > > + */ > > + if (!(ap->cbl == ATA_CBL_SATA)) > > + return 0; > > > > for (ix = 0; ix < ATA_MAX_DEVICES; ix++) { > > if (!ata_dev_enabled(&ap->device[ix])) > > Grumble! > > This /really/ should have gone through me and linux-ide first. Back at you Jeff, This feature /really/ should have never gone upstream in the first place, as this failure was reported and isolated to git-libata-all.patch back in 2.6.20-rc6-mm3: http://bugzilla.kernel.org/show_bug.cgi?id=7907 It then went on to become the most widely reported "ACPI related" regression in the 2.6.21-rc series -- for which ACPI gets smeared. Thank you ATA... > Alan has been actively working on PATA ACPI, and we have been debugging > ACPI issues as well. PLEASE coordinate with the maintainer, when > touching code outside of drivers/acpi! And PLEASE coordinate with the maintainer when invoking methods that provoke errors in other sub-systems! Re: "debugging ACPI issues as well" What issues? Why haven't I see any mention of them on linux-acpi? Coordination and communication is a two-way street, Jeff. > AFAICS this patch went in with zero appearance on LKML or another > related list, until submission. This is /not/ how we do Linux development. I proudly take credit+blame for shipping Kristen's patch with no delay. It did appear on linux-acpi, as do all the patches I ship -- though I admit it was the same day it went upstream. I'm sorry I didn't CC linux-ide -- I'll get that part right next time. However, I believe that late -rc3 is _well_ past the time to be developing new code real-time in the upstream tree; and is instead time to shut the damn thing off and set sights on the next release. If you disagree with me, I'm not going to object when you send a better fix to Linus for 2.6.21-rc4. However, I do request that you first either start responding to bugzilla traffic, or delete your account from bugzilla so that people don't get the false impression that you're paying attention. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
