Add a function to get the address of the RSDP table. Per default use a __weak annotated function being a nop.
Cc: stable@vger.kernel.org # 4.11 Signed-off-by: Juergen Gross jgross@suse.com --- drivers/acpi/osl.c | 10 +++++++++- include/linux/acpi.h | 2 ++ 2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index 3bb46cb24a99..2b77db914752 100644 --- a/drivers/acpi/osl.c +++ b/drivers/acpi/osl.c @@ -178,6 +178,11 @@ void acpi_os_vprintf(const char *fmt, va_list args) #endif }
+__weak acpi_physical_address acpi_arch_get_root_pointer(void) +{ + return 0; +} + #ifdef CONFIG_KEXEC static unsigned long acpi_rsdp; static int __init setup_acpi_rsdp(char *arg) @@ -189,12 +194,15 @@ early_param("acpi_rsdp", setup_acpi_rsdp);
acpi_physical_address __init acpi_os_get_root_pointer(void) { - acpi_physical_address pa = 0; + acpi_physical_address pa;
#ifdef CONFIG_KEXEC if (acpi_rsdp) return acpi_rsdp; #endif + pa = acpi_arch_get_root_pointer(); + if (pa) + return pa;
if (efi_enabled(EFI_CONFIG_TABLES)) { if (efi.acpi20 != EFI_INVALID_TABLE_ADDR) diff --git a/include/linux/acpi.h b/include/linux/acpi.h index dc1ebfeeb5ec..aa603cc5ad30 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -1266,4 +1266,6 @@ static inline int lpit_read_residency_count_address(u64 *address) } #endif
+acpi_physical_address acpi_arch_get_root_pointer(void); + #endif /*_LINUX_ACPI_H*/
On Thu, Jan 25, 2018 at 4:36 PM, Juergen Gross jgross@suse.com wrote:
Add a function to get the address of the RSDP table. Per default use a __weak annotated function being a nop.
The problem with weak functions that we can't have more than one implementation per kernel while we would like to built several code paths.
I have stumbled on the similar stuff and realize that.
Perhaps, one of the solution is to have an additional struct under x86_init to alternate ACPI related stuff.
On 26/01/18 19:08, Andy Shevchenko wrote:
On Thu, Jan 25, 2018 at 4:36 PM, Juergen Gross jgross@suse.com wrote:
Add a function to get the address of the RSDP table. Per default use a __weak annotated function being a nop.
The problem with weak functions that we can't have more than one implementation per kernel while we would like to built several code paths.
I have stumbled on the similar stuff and realize that.
Perhaps, one of the solution is to have an additional struct under x86_init to alternate ACPI related stuff.
I think we can go that route when another user of that interface is appearing.
Juergen
On Fri, Jan 26, 2018 at 8:21 PM, Juergen Gross jgross@suse.com wrote:
On 26/01/18 19:08, Andy Shevchenko wrote:
On Thu, Jan 25, 2018 at 4:36 PM, Juergen Gross jgross@suse.com wrote:
Add a function to get the address of the RSDP table. Per default use a __weak annotated function being a nop.
The problem with weak functions that we can't have more than one implementation per kernel while we would like to built several code paths.
I have stumbled on the similar stuff and realize that.
Perhaps, one of the solution is to have an additional struct under x86_init to alternate ACPI related stuff.
I think we can go that route when another user of that interface is appearing.
Why not to establish the struct? At least this route I would like to go with [1].
[1]: https://lkml.org/lkml/2018/1/17/834
On Sun, Jan 28, 2018 at 4:04 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Fri, Jan 26, 2018 at 8:21 PM, Juergen Gross jgross@suse.com wrote:
On 26/01/18 19:08, Andy Shevchenko wrote:
On Thu, Jan 25, 2018 at 4:36 PM, Juergen Gross jgross@suse.com wrote:
Add a function to get the address of the RSDP table. Per default use a __weak annotated function being a nop.
The problem with weak functions that we can't have more than one implementation per kernel while we would like to built several code paths.
I have stumbled on the similar stuff and realize that.
Perhaps, one of the solution is to have an additional struct under x86_init to alternate ACPI related stuff.
I think we can go that route when another user of that interface is appearing.
Why not to establish the struct? At least this route I would like to go with [1].
Maybe I'm a bit slow today, but care to explain what exactly you mean?
On Mon, Jan 29, 2018 at 5:02 AM, Rafael J. Wysocki rafael@kernel.org wrote:
On Sun, Jan 28, 2018 at 4:04 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Fri, Jan 26, 2018 at 8:21 PM, Juergen Gross jgross@suse.com wrote:
On 26/01/18 19:08, Andy Shevchenko wrote:
On Thu, Jan 25, 2018 at 4:36 PM, Juergen Gross jgross@suse.com wrote:
The problem with weak functions that we can't have more than one implementation per kernel while we would like to built several code paths.
I have stumbled on the similar stuff and realize that.
Perhaps, one of the solution is to have an additional struct under x86_init to alternate ACPI related stuff.
I think we can go that route when another user of that interface is appearing.
Why not to establish the struct? At least this route I would like to go with [1].
Maybe I'm a bit slow today, but care to explain what exactly you mean?
Instead of declaring function as __weak, establish a new struct for ACPI related stubs and incorporate it into x86_init.
That is my proposal. I think I would go this way in my case where I need to treat differently ACPI HW reduced initialization of legacy devices.
On Wed, Jan 31, 2018 at 4:43 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Jan 29, 2018 at 5:02 AM, Rafael J. Wysocki rafael@kernel.org wrote:
On Sun, Jan 28, 2018 at 4:04 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Fri, Jan 26, 2018 at 8:21 PM, Juergen Gross jgross@suse.com wrote:
On 26/01/18 19:08, Andy Shevchenko wrote:
On Thu, Jan 25, 2018 at 4:36 PM, Juergen Gross jgross@suse.com wrote:
The problem with weak functions that we can't have more than one implementation per kernel while we would like to built several code paths.
I have stumbled on the similar stuff and realize that.
Perhaps, one of the solution is to have an additional struct under x86_init to alternate ACPI related stuff.
I think we can go that route when another user of that interface is appearing.
Why not to establish the struct? At least this route I would like to go with [1].
Maybe I'm a bit slow today, but care to explain what exactly you mean?
Instead of declaring function as __weak, establish a new struct for ACPI related stubs and incorporate it into x86_init.
That is my proposal. I think I would go this way in my case where I need to treat differently ACPI HW reduced initialization of legacy devices.
IOW you'd like to have a set of ACPI init callbacks that could be defined by an arch, right?
On Thu, Feb 1, 2018 at 9:57 AM, Rafael J. Wysocki rafael@kernel.org wrote:
On Wed, Jan 31, 2018 at 4:43 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Jan 29, 2018 at 5:02 AM, Rafael J. Wysocki rafael@kernel.org wrote:
On Sun, Jan 28, 2018 at 4:04 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
Instead of declaring function as __weak, establish a new struct for ACPI related stubs and incorporate it into x86_init.
That is my proposal. I think I would go this way in my case where I need to treat differently ACPI HW reduced initialization of legacy devices.
IOW you'd like to have a set of ACPI init callbacks that could be defined by an arch, right?
Correct!
And since there is another potential user (Xen) for this approach I consider it a good chance to be chosen. Though I have no idea if Xen can do things differently.
On Thu, Feb 1, 2018 at 4:45 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Thu, Feb 1, 2018 at 9:57 AM, Rafael J. Wysocki rafael@kernel.org wrote:
On Wed, Jan 31, 2018 at 4:43 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Jan 29, 2018 at 5:02 AM, Rafael J. Wysocki rafael@kernel.org wrote:
On Sun, Jan 28, 2018 at 4:04 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
Instead of declaring function as __weak, establish a new struct for ACPI related stubs and incorporate it into x86_init.
That is my proposal. I think I would go this way in my case where I need to treat differently ACPI HW reduced initialization of legacy devices.
IOW you'd like to have a set of ACPI init callbacks that could be defined by an arch, right?
Correct!
OK
On Fri, Jan 26, 2018 at 7:08 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Thu, Jan 25, 2018 at 4:36 PM, Juergen Gross jgross@suse.com wrote:
Add a function to get the address of the RSDP table. Per default use a __weak annotated function being a nop.
The problem with weak functions that we can't have more than one implementation per kernel while we would like to built several code paths.
I have stumbled on the similar stuff and realize that.
Perhaps, one of the solution is to have an additional struct under x86_init to alternate ACPI related stuff.
I'm not sure if that really is a problem in this particular case.
Why would you want to use different RSDP retrieval functions for one arch?
Thanks, Rafael
On Mon, Jan 29, 2018 at 5:01 AM, Rafael J. Wysocki rafael@kernel.org wrote:
On Fri, Jan 26, 2018 at 7:08 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
I have stumbled on the similar stuff and realize that.
Perhaps, one of the solution is to have an additional struct under x86_init to alternate ACPI related stuff.
I'm not sure if that really is a problem in this particular case.
Why would you want to use different RSDP retrieval functions for one arch?
I was not clear. I'm talking about approach struct x86_init vs. __weak function. In my case it has nothing to do with RDSP, but with ACPI stubs.
linux-stable-mirror@lists.linaro.org
-
Andy Shevchenko -
Juergen Gross -
Rafael J. Wysocki