| Message ID | 20180125143639.9969-2-jgross@suse.com (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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]. > > [1]: https://lkml.org/lkml/2018/1/17/834 Maybe I'm a bit slow today, but care to explain what exactly you mean? -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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]. >> >> [1]: https://lkml.org/lkml/2018/1/17/834 > > 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]. >>> >>> [1]: https://lkml.org/lkml/2018/1/17/834 >> >> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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*/
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(-)