linux-kernel - Re: libata-acpi: allow _GTF on SATA, but disable on PATA for now

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 10 Mar 2007 22:14:14 -0500
From:	Len Brown <lenb@...nel.org>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	kristen.c.accardi@...el.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alan <alan@...rguk.ukuu.org.uk>,
	IDE/ATA development list <linux-ide@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: libata-acpi: allow _GTF on SATA, but disable on PATA for now

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@...el.com>
> > AuthorDate: Fri Mar 9 18:15:33 2007 -0500
> > Committer:  Len Brown <len.brown@...el.com>
> > 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@...el.com>
> >     Signed-off-by: Len Brown <len.brown@...el.com>
> > ---
> >  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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/