Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1628653 > unrolled thread
| Started by | Sinan Kaya <okaya@codeaurora.org> |
|---|---|
| First post | 2017-04-22 00:30 +0200 |
| Last post | 2017-04-22 00:50 +0200 |
| Articles | 4 — 2 participants |
Back to article view | Back to linux.kernel
[PATCH] ACPI / GED: use late init to allow other drivers init Sinan Kaya <okaya@codeaurora.org> - 2017-04-22 00:30 +0200
Re: [PATCH] ACPI / GED: use late init to allow other drivers init Sinan Kaya <okaya@codeaurora.org> - 2017-04-22 00:50 +0200
Re: [PATCH] ACPI / GED: use late init to allow other drivers init Sinan Kaya <okaya@codeaurora.org> - 2017-04-22 00:50 +0200
Re: [PATCH] ACPI / GED: use late init to allow other drivers init "Rafael J. Wysocki" <rafael@kernel.org> - 2017-04-22 00:50 +0200
| From | Sinan Kaya <okaya@codeaurora.org> |
|---|---|
| Date | 2017-04-22 00:30 +0200 |
| Subject | [PATCH] ACPI / GED: use late init to allow other drivers init |
| Message-ID | <tyPdU-31Y-5@gated-at.bofh.it> |
GED driver is currently set up as a platform driver. On modern operating
systems, most of the drivers are compiled as kernel modules. It is possible
that a GED interrupt event is received and the driver such as GHES/GPIO/I2C
to service it is not available yet. To accommodate this use case, delay
GED driver load to the late init phase.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/acpi/evged.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/evged.c b/drivers/acpi/evged.c
index 46f0603..30e638b 100644
--- a/drivers/acpi/evged.c
+++ b/drivers/acpi/evged.c
@@ -151,4 +151,10 @@ static int ged_probe(struct platform_device *pdev)
.acpi_match_table = ACPI_PTR(ged_acpi_ids),
},
};
-builtin_platform_driver(ged_driver);
+
+static __init int ged_init(void)
+{
+ return platform_driver_register(&ged_driver);
+}
+
+late_initcall(ged_init);
--
1.9.1
[toc] | [next] | [standalone]
| From | Sinan Kaya <okaya@codeaurora.org> |
|---|---|
| Date | 2017-04-22 00:50 +0200 |
| Message-ID | <tyPxf-38u-1@gated-at.bofh.it> |
| In reply to | #1628653 |
On 4/21/2017 6:43 PM, Rafael J. Wysocki wrote: >> +late_initcall(ged_init); > Does this fix the problem? > > What about if the module in question is loaded after running late_initcalls? This fixed the issue for me where I had dependencies for QUP I2C driver and GHES drivers. Both of them are modules and get probed via normal module execution path. However, I'm open to improvements. Do you have a better suggestion? I can try to add some _DEP stuff if it is present, but I remember Linux doesn't like _DEP stuff too much. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
[toc] | [prev] | [next] | [standalone]
| From | Sinan Kaya <okaya@codeaurora.org> |
|---|---|
| Date | 2017-04-22 00:50 +0200 |
| Message-ID | <tyPxf-38u-13@gated-at.bofh.it> |
| In reply to | #1628659 |
On 4/21/2017 6:48 PM, Sinan Kaya wrote: > On 4/21/2017 6:43 PM, Rafael J. Wysocki wrote: >>> +late_initcall(ged_init); >> Does this fix the problem? >> >> What about if the module in question is loaded after running late_initcalls? > > This fixed the issue for me where I had dependencies for QUP I2C driver and GHES > drivers. Both of them are modules and get probed via normal module execution path. > > However, I'm open to improvements. Do you have a better suggestion? I can try > to add some _DEP stuff if it is present, but I remember Linux doesn't like _DEP > stuff too much. > I forgot to mention that GED driver is a built-in module. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2017-04-22 00:50 +0200 |
| Message-ID | <tyPxf-38u-3@gated-at.bofh.it> |
| In reply to | #1628653 |
On Sat, Apr 22, 2017 at 12:28 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
> GED driver is currently set up as a platform driver. On modern operating
> systems, most of the drivers are compiled as kernel modules. It is possible
> that a GED interrupt event is received and the driver such as GHES/GPIO/I2C
> to service it is not available yet. To accommodate this use case, delay
> GED driver load to the late init phase.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/acpi/evged.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/evged.c b/drivers/acpi/evged.c
> index 46f0603..30e638b 100644
> --- a/drivers/acpi/evged.c
> +++ b/drivers/acpi/evged.c
> @@ -151,4 +151,10 @@ static int ged_probe(struct platform_device *pdev)
> .acpi_match_table = ACPI_PTR(ged_acpi_ids),
> },
> };
> -builtin_platform_driver(ged_driver);
> +
> +static __init int ged_init(void)
> +{
> + return platform_driver_register(&ged_driver);
> +}
> +
> +late_initcall(ged_init);
Does this fix the problem?
What about if the module in question is loaded after running late_initcalls?
Thanks,
Rafael
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web