Thread (33 messages) 33 messages, 7 authors, 2016-03-01

[PATCH v3 1/5] ACPI: change __init to __ref for early_acpi_os_unmap_memory()

From: Zheng, Lv <hidden>
Date: 2016-02-17 02:51:59
Also in: linux-acpi, linux-serial, lkml

Hi,
From: linux-acpi-owner at vger.kernel.org [mailto:linux-acpi-
owner at vger.kernel.org] On Behalf Of Zheng, Lv
Subject: RE: [PATCH v3 1/5] ACPI: change __init to __ref for
early_acpi_os_unmap_memory()

Hi,
quoted
-----Original Message-----
From: linux-acpi-owner at vger.kernel.org [mailto:linux-acpi-
owner at vger.kernel.org] On Behalf Of Aleksey Makarov
Sent: Tuesday, February 16, 2016 2:05 AM
To: linux-acpi at vger.kernel.org
Cc: linux-serial at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
kernel at lists.infradead.org; Aleksey Makarov [off-list ref];
Russell King [off-list ref]; Greg Kroah-Hartman
[off-list ref]; Rafael J . Wysocki [off-list ref]; Leif
Lindholm [off-list ref]; Graeme Gregory
[off-list ref]; Al Stone [off-list ref]; Christopher
Covington [off-list ref]; Len Brown [off-list ref]
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
early_acpi_os_unmap_memory()

early_acpi_os_unmap_memory() is marked as __init because it calls
__acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is not set.

acpi_gbl_permanent_mmap is set in __init acpi_early_init()
so it is safe to call early_acpi_os_unmap_memory() from anywhere

We need this function to be non-__init because we need access to
some tables at unpredictable time--it may be before or after
acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port Console
Redirection) table is needed each time a new console is registered.
It can be quite early (console_initcall) or when a module is inserted.
When this table accessed before acpi_gbl_permanent_mmap is set,
the pointer should be unmapped.  This is exactly what this function
does.
[Lv Zheng]
Why don't you use another API instead of early_acpi_os_unmap_memory() in
case you want to unmap things in any cases.
acpi_os_unmap_memory() should be the one to match this purpose.
It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
And in fact early_acpi_os_unmap_memory() should be removed.
[Lv Zheng] 
One more thing is:
If you can't switch your driver to use acpi_os_unmap_memory() instead of early_acpi_os_unmap_memory(),
then it implies that your driver does have a defect.

There is an early bootup requirement in Linux.
Maps acquired during the early stage should be freed by the driver during the early stage.
And the driver should re-acquire the memory map after booting.

This is because, during early bootup stage, there are only limited slots available for drivers to map memory.
So by changing __init to __ref here, you probably will hide many such defects.
And solving issues in this way doesn't seem to be an improvement.

Thanks and best regards
-Lv
Thanks and best regards
-Lv
quoted
Signed-off-by: Aleksey Makarov <redacted>
---
 drivers/acpi/osl.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 67da6fb..8a552cd 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void *virt,
acpi_size size)
 }
 EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);

-void __init early_acpi_os_unmap_memory(void __iomem *virt, acpi_size
size)
quoted
+/*
+ * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
+ * so it is safe to call early_acpi_os_unmap_memory() from anywhere
+ */
+void __ref early_acpi_os_unmap_memory(void __iomem *virt, acpi_size
size)
quoted
 {
 	if (!acpi_gbl_permanent_mmap)
 		__acpi_unmap_table(virt, size);
--
2.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help