Re: [PATCH] libata_acpi: A different strategy for using ACPI information

2007-07-04 Thread Alan Cox
> Looks fairly reasonable to me. However, I suspect any use of _GTM is > somewhat dangerous (at least after the resume) unless we use the _STM > and _GTF methods in the proper sequence when resuming. (Is that in the > -mm tree now?) Yes - and we only use it in these drivers to check for cable e

Re: [PATCH] libata_acpi: A different strategy for using ACPI information

2007-07-03 Thread Tejun Heo
Alan Cox wrote: > Lots of BIOSen simply return the BIOS set modes via the ACPI methods and > pass back the values you give it across suspend/resume. Thus instead of > trying to do clever stuff with this data we instead use it as a way to > take a sneak peak at cable type information when viable. Th

Re: [PATCH] libata_acpi: A different strategy for using ACPI information

2007-07-03 Thread Robert Hancock
Alan Cox wrote: Lots of BIOSen simply return the BIOS set modes via the ACPI methods and pass back the values you give it across suspend/resume. Thus instead of trying to do clever stuff with this data we instead use it as a way to take a sneak peak at cable type information when viable. This sho

[PATCH] libata_acpi: A different strategy for using ACPI information

2007-07-03 Thread Alan Cox
Lots of BIOSen simply return the BIOS set modes via the ACPI methods and pass back the values you give it across suspend/resume. Thus instead of trying to do clever stuff with this data we instead use it as a way to take a sneak peak at cable type information when viable. This should help us catch