On Sun, Sep 22, 2013 at 5:59 PM, Tejun Heo <tj@xxxxxxxxxx> wrote:
> On Sun, Sep 22, 2013 at 03:56:35AM +0200, Patrik Jakobsson wrote:
>> Where REGS_PER_GTF is defined as 7 which is correct according to ACPI specs.
>> Since I'm getting a length of 8 I started digging in the ACPI code and found
>> that the length is rounded up to acpi_size (u32 or u64 depending on arch). I
>> cannot find any commits that recently touched this though I didn't really dig
>> through it all.
>
> It means your bios is buggy.
I must be confusing the actual buffer length with the allocated buffer
length. It is
not entirely clear what is what in the ACPI-CA code. What I don't understand is
how a simple "Return (GTF0)" where GTF0 is 56 bits gets padded to 64 bits by
the firmware. Maybe the iasl disassembly is lying to me.
>> I've disassembled the SSDT for the "SataAhci" and everything looks ok. That
>> code returns a 56 bit buffer. I also tried calling the _GTF method manually
>> which returned the following (padded to 8 bytes by the ACPI code ofc).
>>
>> {0x10, 0x03, 0x00, 0x00, 0x00, 0xa0, 0xef, 0x00}
>>
>> Doing a quick google search gives me a few of these _GTF length errors dating
>> back to at least 2011. What's going on here? Is this a known error?
>
> Failing to execute _GTF is usally fine to the point where I sometimes
> wonder why we bother with it at all. The above command is SET
> FEATURES / Enable SATA Feature / DIPM, which enables device side link
> powersaving and is a weird thing to do from _GTF anyway as host side
> needs configuration too. You can properly configure it using libata
> link PM.
Thanks for the info. I tested "fixing up" the code to let the _GTF slide through
and I couldn't see it make any difference whatsoever. As you say, we can safely
ignore this.
Cheers
Patrik
>
> Thanks.
>
> --
> tejun
--
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
