All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zheng, Lv" <lv.zheng@intel.com>
To: "Zheng, Lv" <lv.zheng@intel.com>,
	Aleksey Makarov <aleksey.makarov@linaro.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Cc: "linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Russell King <linux@arm.linux.org.uk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	Graeme Gregory <graeme.gregory@linaro.org>,
	Al Stone <ahs3@redhat.com>,
	Christopher Covington <cov@codeaurora.org>,
	Len Brown <lenb@kernel.org>
Subject: RE: [PATCH v3 1/5] ACPI: change __init to __ref for early_acpi_os_unmap_memory()
Date: Wed, 17 Feb 2016 02:51:51 +0000	[thread overview]
Message-ID: <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>

Hi,

> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@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,
> 
> > -----Original Message-----
> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> > owner@vger.kernel.org] On Behalf Of Aleksey Makarov
> > Sent: Tuesday, February 16, 2016 2:05 AM
> > To: linux-acpi@vger.kernel.org
> > Cc: linux-serial@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> > kernel@lists.infradead.org; Aleksey Makarov <aleksey.makarov@linaro.org>;
> > Russell King <linux@arm.linux.org.uk>; Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org>; Rafael J . Wysocki <rjw@rjwysocki.net>; Leif
> > Lindholm <leif.lindholm@linaro.org>; Graeme Gregory
> > <graeme.gregory@linaro.org>; Al Stone <ahs3@redhat.com>; Christopher
> > Covington <cov@codeaurora.org>; Len Brown <lenb@kernel.org>
> > 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
> 
> >
> > Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
> > ---
> >  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)
> > +/*
> > + * 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)
> >  {
> >  	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@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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: lv.zheng@intel.com (Zheng, Lv)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for early_acpi_os_unmap_memory()
Date: Wed, 17 Feb 2016 02:51:51 +0000	[thread overview]
Message-ID: <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>

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,
> 
> > -----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 <aleksey.makarov@linaro.org>;
> > Russell King <linux@arm.linux.org.uk>; Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org>; Rafael J . Wysocki <rjw@rjwysocki.net>; Leif
> > Lindholm <leif.lindholm@linaro.org>; Graeme Gregory
> > <graeme.gregory@linaro.org>; Al Stone <ahs3@redhat.com>; Christopher
> > Covington <cov@codeaurora.org>; Len Brown <lenb@kernel.org>
> > 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
> 
> >
> > Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
> > ---
> >  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)
> > +/*
> > + * 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)
> >  {
> >  	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

  reply	other threads:[~2016-02-17  2:51 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-15 18:05 [PATCH v3 0/5] ACPI: parse the SPCR table Aleksey Makarov
2016-02-15 18:05 ` Aleksey Makarov
2016-02-15 18:05 ` [PATCH v3 1/5] ACPI: change __init to __ref for early_acpi_os_unmap_memory() Aleksey Makarov
2016-02-15 18:05   ` Aleksey Makarov
2016-02-17  2:44   ` Zheng, Lv
2016-02-17  2:44     ` Zheng, Lv
2016-02-17  2:44     ` Zheng, Lv
2016-02-17  2:51     ` Zheng, Lv [this message]
2016-02-17  2:51       ` Zheng, Lv
2016-02-17  2:51       ` Zheng, Lv
2016-02-17 13:08       ` Aleksey Makarov
2016-02-17 13:08         ` Aleksey Makarov
2016-02-17 13:08         ` Aleksey Makarov
2016-02-18  3:36         ` Zheng, Lv
2016-02-18  3:36           ` Zheng, Lv
2016-02-18  3:36           ` Zheng, Lv
2016-02-18 22:03           ` Peter Hurley
2016-02-18 22:03             ` Peter Hurley
2016-02-18 22:03             ` Peter Hurley
2016-02-19  2:58             ` Zheng, Lv
2016-02-19  2:58               ` Zheng, Lv
2016-02-19  2:58               ` Zheng, Lv
2016-02-19 11:02               ` Aleksey Makarov
2016-02-19 11:02                 ` Aleksey Makarov
2016-02-19 11:02                 ` Aleksey Makarov
2016-02-22  2:24                 ` Zheng, Lv
2016-02-22  2:24                   ` Zheng, Lv
2016-02-22  2:24                   ` Zheng, Lv
2016-02-22 14:58                   ` Aleksey Makarov
2016-02-22 14:58                     ` Aleksey Makarov
2016-02-22 14:58                     ` Aleksey Makarov
2016-02-23  0:19                     ` Zheng, Lv
2016-02-23  0:19                       ` Zheng, Lv
2016-02-23  0:19                       ` Zheng, Lv
2016-02-26  6:39                     ` Zheng, Lv
2016-02-26  6:39                       ` Zheng, Lv
2016-02-26  6:39                       ` Zheng, Lv
2016-02-26 10:33                       ` Aleksey Makarov
2016-02-26 10:33                         ` Aleksey Makarov
2016-02-26 10:33                         ` Aleksey Makarov
2016-02-19 10:42             ` Aleksey Makarov
2016-02-19 10:42               ` Aleksey Makarov
2016-02-19 10:42               ` Aleksey Makarov
2016-02-19 15:25               ` Peter Hurley
2016-02-19 15:25                 ` Peter Hurley
2016-02-19 15:25                 ` Peter Hurley
2016-02-19 17:20                 ` Christopher Covington
2016-02-19 17:20                   ` Christopher Covington
2016-02-19 17:20                   ` Christopher Covington
2016-02-22  5:37                   ` Peter Hurley
2016-02-22  5:37                     ` Peter Hurley
2016-02-22  5:37                     ` Peter Hurley
2016-02-22 14:43                   ` Aleksey Makarov
2016-02-22 14:43                     ` Aleksey Makarov
2016-02-22 14:43                     ` Aleksey Makarov
2016-02-22 14:35                 ` Aleksey Makarov
2016-02-22 14:35                   ` Aleksey Makarov
2016-02-22 14:35                   ` Aleksey Makarov
2016-03-01 15:24                   ` Peter Hurley
2016-03-01 15:24                     ` Peter Hurley
2016-03-01 15:24                     ` Peter Hurley
2016-02-15 18:05 ` [PATCH v3 2/5] ACPI: parse SPCR and enable matching console Aleksey Makarov
2016-02-15 18:05   ` Aleksey Makarov
2016-02-18 22:19   ` Peter Hurley
2016-02-18 22:19     ` Peter Hurley
2016-02-19 10:47     ` Aleksey Makarov
2016-02-19 10:47       ` Aleksey Makarov
2016-02-19 16:13       ` Peter Hurley
2016-02-19 16:13         ` Peter Hurley
2016-02-21  9:42   ` Yury Norov
2016-02-21  9:42     ` Yury Norov
2016-02-21  9:42     ` Yury Norov
2016-02-22 15:03     ` Aleksey Makarov
2016-02-22 15:03       ` Aleksey Makarov
2016-02-15 18:05 ` [PATCH v3 3/5] ACPI: enable ACPI_SPCR_TABLE on ARM64 Aleksey Makarov
2016-02-15 18:05   ` Aleksey Makarov
2016-02-15 18:05 ` [PATCH v3 4/5] ACPI: add definition of DBG2 subtypes Aleksey Makarov
2016-02-15 18:05   ` Aleksey Makarov
2016-02-15 18:05 ` [PATCH v3 5/5] serial: pl011: use SPCR to setup 32-bit access Aleksey Makarov
2016-02-15 18:05   ` Aleksey Makarov
2016-02-16 19:11 ` [PATCH v3 0/5] ACPI: parse the SPCR table Mark Salter
2016-02-16 19:11   ` Mark Salter
2016-02-17  2:36 ` Christopher Covington
2016-02-17  2:36   ` Christopher Covington
2016-02-18 21:15 ` Jeremy Linton
2016-02-18 21:15   ` Jeremy Linton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com \
    --to=lv.zheng@intel.com \
    --cc=ahs3@redhat.com \
    --cc=aleksey.makarov@linaro.org \
    --cc=cov@codeaurora.org \
    --cc=graeme.gregory@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=leif.lindholm@linaro.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=rjw@rjwysocki.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.