On Friday, May 01, 2015 03:32:29 AM Rafael J. Wysocki wrote: > On Thursday, April 30, 2015 11:10:25 AM Darren Hart wrote: > > On Wed, Apr 22, 2015 at 04:12:24PM +0200, Kast Bernd wrote: > > > acpi_os_get_physical_address will be needed by an acpi driver (asus-wmi.c). > > > Additionally it could be used by dell-laptop.c instead of directly calling virt_to_phys. > > > > > > acpi_os_get_physical_address gets exported and ACPI_FUTURE_USAGE is removed > > > > > > > Hrm, well... this doesn't get rid of virt_to_phys, it just wraps it really. I'm > > not sure that makes this any more acceptable than the original from Felipe - but > > that's not my call. > > Use virt_to_phys() if you need to. > > This one is in case ACPICA needs to get the virtual-to-physical mapping (hence > ACPI_FUTURE_USAGE). More to the point, the reason why virt_to_phys() needs to be used in patch [2/2] seems to be a nasty hack in the ASUS AML that pretty much expects us to provide the physical address as an argument. And I don't really understand the Matthew's comment regarding limiting operation regions to system memory. This is about a specific operation region (which BTW only seems to be used as a means to access system memory at the location pointed to by the arg) in that particular method. Matthew? -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
