diff mbox

[v5,01/17] Xen: ACPI: Hide UART used by Xen

Message ID 1457073455-11516-2-git-send-email-zhaoshenglong@huawei.com (mailing list archive)
State New, archived
Headers show

Commit Message

Shannon Zhao March 4, 2016, 6:37 a.m. UTC
From: Shannon Zhao <shannon.zhao@linaro.org>

ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
CC: linux-acpi@vger.kernel.org (open list:ACPI)
---
 drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

Comments

Stefano Stabellini March 4, 2016, 12:24 p.m. UTC | #1
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> CC: linux-acpi@vger.kernel.org (open list:ACPI)
> ---
>  drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 68 insertions(+)
> 
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 407a376..31d794c 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
>  DEFINE_MUTEX(acpi_device_lock);
>  LIST_HEAD(acpi_wakeup_device_list);
>  static DEFINE_MUTEX(acpi_hp_context_lock);
> +static u64 spcr_uart_addr;
>  
>  struct acpi_dep_data {
>  	struct list_head node;
> @@ -1453,6 +1454,47 @@ static int acpi_add_single_object(struct acpi_device **child,
>  	return 0;
>  }
>  
> +static acpi_status acpi_get_resource_fixed_memory32(struct acpi_resource *res,
> +						    void *context)
> +{
> +	struct acpi_resource_fixed_memory32 *fixed_memory32;
> +
> +	if (res->type != ACPI_RESOURCE_TYPE_FIXED_MEMORY32)
> +		return AE_OK;
> +
> +	fixed_memory32 = &res->data.fixed_memory32;

Should we call acpi_resource_to_address64 instead?
Aside from this the rest looks good.


> +	if (!fixed_memory32)
> +		return AE_OK;
> +
> +	*((u32 *)context) = fixed_memory32->address;
> +	return AE_CTRL_TERMINATE;
> +}
> +
> +static bool acpi_device_should_be_hidden(acpi_handle handle)
> +{
> +	acpi_status status;
> +	u32 addr = 0;
> +
> +	/* Check if it should ignore the UART device */
> +	if (spcr_uart_addr != 0) {
> +		if (!acpi_has_method(handle, METHOD_NAME__CRS))
> +			return false;
> +
> +		status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> +					     acpi_get_resource_fixed_memory32,
> +					     &addr);
> +		if (ACPI_FAILURE(status))
> +			return false;
> +
> +		if (addr == spcr_uart_addr) {
> +			printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
> +			return true;
> +		}
> +	}
> +
> +	return false;
> +}
> +
>  static int acpi_bus_type_and_status(acpi_handle handle, int *type,
>  				    unsigned long long *sta)
>  {
> @@ -1466,6 +1508,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
>  	switch (acpi_type) {
>  	case ACPI_TYPE_ANY:		/* for ACPI_ROOT_OBJECT */
>  	case ACPI_TYPE_DEVICE:
> +		if (acpi_device_should_be_hidden(handle))
> +			return -ENODEV;
> +
>  		*type = ACPI_BUS_TYPE_DEVICE;
>  		status = acpi_bus_get_status_handle(handle, sta);
>  		if (ACPI_FAILURE(status))
> @@ -1919,6 +1964,8 @@ static int acpi_bus_scan_fixed(void)
>  int __init acpi_scan_init(void)
>  {
>  	int result;
> +	acpi_status status;
> +	struct acpi_table_stao *stao_ptr;
>  
>  	acpi_pci_root_init();
>  	acpi_pci_link_init();
> @@ -1933,6 +1980,27 @@ int __init acpi_scan_init(void)
>  
>  	acpi_scan_add_handler(&generic_device_handler);
>  
> +	/* If there is STAO table, check whether it needs to ignore the UART
> +	 * device in SPCR table.
> +	 */
> +	status = acpi_get_table(ACPI_SIG_STAO, 0,
> +				(struct acpi_table_header **)&stao_ptr);
> +	if (ACPI_SUCCESS(status)) {
> +		if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> +			printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> +
> +		if (stao_ptr->ignore_uart) {
> +			struct acpi_table_spcr *spcr_ptr;
> +
> +			status = acpi_get_table(ACPI_SIG_SPCR, 0,
> +					(struct acpi_table_header **)&spcr_ptr);
> +			if (ACPI_SUCCESS(status))
> +				spcr_uart_addr = spcr_ptr->serial_port.address;
> +			else
> +				printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> +		}
> +	}
> +
>  	mutex_lock(&acpi_scan_lock);
>  	/*
>  	 * Enumerate devices in the ACPI namespace.
> -- 
> 2.0.4
> 
>
Shannon Zhao March 4, 2016, 3:56 p.m. UTC | #2
On 2016/3/4 20:24, Stefano Stabellini wrote:
> On Fri, 4 Mar 2016, Shannon Zhao wrote:
>> >From: Shannon Zhao<shannon.zhao@linaro.org>
>> >
>> >ACPI 6.0 introduces a new table STAO to list the devices which are used
>> >by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
>> >UART is used by Xen. So here it hides UART from Dom0.
>> >
>> >Signed-off-by: Shannon Zhao<shannon.zhao@linaro.org>
>> >---
>> >CC: "Rafael J. Wysocki"<rjw@rjwysocki.net>  (supporter:ACPI)
>> >CC: Len Brown<lenb@kernel.org>  (supporter:ACPI)
>> >CC:linux-acpi@vger.kernel.org  (open list:ACPI)
>> >---
>> >  drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >  1 file changed, 68 insertions(+)
>> >
>> >diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> >index 407a376..31d794c 100644
>> >--- a/drivers/acpi/scan.c
>> >+++ b/drivers/acpi/scan.c
>> >@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
>> >  DEFINE_MUTEX(acpi_device_lock);
>> >  LIST_HEAD(acpi_wakeup_device_list);
>> >  static DEFINE_MUTEX(acpi_hp_context_lock);
>> >+static u64 spcr_uart_addr;
>> >
>> >  struct acpi_dep_data {
>> >  	struct list_head node;
>> >@@ -1453,6 +1454,47 @@ static int acpi_add_single_object(struct acpi_device **child,
>> >  	return 0;
>> >  }
>> >
>> >+static acpi_status acpi_get_resource_fixed_memory32(struct acpi_resource *res,
>> >+						    void *context)
>> >+{
>> >+	struct acpi_resource_fixed_memory32 *fixed_memory32;
>> >+
>> >+	if (res->type != ACPI_RESOURCE_TYPE_FIXED_MEMORY32)
>> >+		return AE_OK;
>> >+
>> >+	fixed_memory32 = &res->data.fixed_memory32;
> Should we call acpi_resource_to_address64 instead?
> Aside from this the rest looks good.
>
You mean the resource type could be other types? like 
ACPI_RESOURCE_TYPE_ADDRESS64 or ACPI_RESOURCE_TYPE_ADDRESS32? So it 
needs to convert them to ACPI_RESOURCE_TYPE_ADDRESS64 firstly?

Thanks,
Stefano Stabellini March 4, 2016, 4:28 p.m. UTC | #3
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> On 2016/3/4 20:24, Stefano Stabellini wrote:
> > On Fri, 4 Mar 2016, Shannon Zhao wrote:
> > > >From: Shannon Zhao<shannon.zhao@linaro.org>
> > > >
> > > >ACPI 6.0 introduces a new table STAO to list the devices which are used
> > > >by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > > >UART is used by Xen. So here it hides UART from Dom0.
> > > >
> > > >Signed-off-by: Shannon Zhao<shannon.zhao@linaro.org>
> > > >---
> > > >CC: "Rafael J. Wysocki"<rjw@rjwysocki.net>  (supporter:ACPI)
> > > >CC: Len Brown<lenb@kernel.org>  (supporter:ACPI)
> > > >CC:linux-acpi@vger.kernel.org  (open list:ACPI)
> > > >---
> > > >  drivers/acpi/scan.c | 68
> > > +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > >  1 file changed, 68 insertions(+)
> > > >
> > > >diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > > >index 407a376..31d794c 100644
> > > >--- a/drivers/acpi/scan.c
> > > >+++ b/drivers/acpi/scan.c
> > > >@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> > > >  DEFINE_MUTEX(acpi_device_lock);
> > > >  LIST_HEAD(acpi_wakeup_device_list);
> > > >  static DEFINE_MUTEX(acpi_hp_context_lock);
> > > >+static u64 spcr_uart_addr;
> > > >
> > > >  struct acpi_dep_data {
> > > >  	struct list_head node;
> > > >@@ -1453,6 +1454,47 @@ static int acpi_add_single_object(struct
> > > acpi_device **child,
> > > >  	return 0;
> > > >  }
> > > >
> > > >+static acpi_status acpi_get_resource_fixed_memory32(struct acpi_resource
> > > *res,
> > > >+						    void *context)
> > > >+{
> > > >+	struct acpi_resource_fixed_memory32 *fixed_memory32;
> > > >+
> > > >+	if (res->type != ACPI_RESOURCE_TYPE_FIXED_MEMORY32)
> > > >+		return AE_OK;
> > > >+
> > > >+	fixed_memory32 = &res->data.fixed_memory32;
> > Should we call acpi_resource_to_address64 instead?
> > Aside from this the rest looks good.
> > 
> You mean the resource type could be other types? like
> ACPI_RESOURCE_TYPE_ADDRESS64 or ACPI_RESOURCE_TYPE_ADDRESS32? So it needs to
> convert them to ACPI_RESOURCE_TYPE_ADDRESS64 firstly?

I meant to ask whether we need to check for other types of resources, in
addition to ACPI_RESOURCE_TYPE_FIXED_MEMORY32.  So maybe call an
existing function that already does the check for us.
acpi_dev_resource_memory is actually what I meant to suggest.
diff mbox

Patch

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 407a376..31d794c 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@  static LIST_HEAD(acpi_scan_handlers_list);
 DEFINE_MUTEX(acpi_device_lock);
 LIST_HEAD(acpi_wakeup_device_list);
 static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
 
 struct acpi_dep_data {
 	struct list_head node;
@@ -1453,6 +1454,47 @@  static int acpi_add_single_object(struct acpi_device **child,
 	return 0;
 }
 
+static acpi_status acpi_get_resource_fixed_memory32(struct acpi_resource *res,
+						    void *context)
+{
+	struct acpi_resource_fixed_memory32 *fixed_memory32;
+
+	if (res->type != ACPI_RESOURCE_TYPE_FIXED_MEMORY32)
+		return AE_OK;
+
+	fixed_memory32 = &res->data.fixed_memory32;
+	if (!fixed_memory32)
+		return AE_OK;
+
+	*((u32 *)context) = fixed_memory32->address;
+	return AE_CTRL_TERMINATE;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+	acpi_status status;
+	u32 addr = 0;
+
+	/* Check if it should ignore the UART device */
+	if (spcr_uart_addr != 0) {
+		if (!acpi_has_method(handle, METHOD_NAME__CRS))
+			return false;
+
+		status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+					     acpi_get_resource_fixed_memory32,
+					     &addr);
+		if (ACPI_FAILURE(status))
+			return false;
+
+		if (addr == spcr_uart_addr) {
+			printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
+			return true;
+		}
+	}
+
+	return false;
+}
+
 static int acpi_bus_type_and_status(acpi_handle handle, int *type,
 				    unsigned long long *sta)
 {
@@ -1466,6 +1508,9 @@  static int acpi_bus_type_and_status(acpi_handle handle, int *type,
 	switch (acpi_type) {
 	case ACPI_TYPE_ANY:		/* for ACPI_ROOT_OBJECT */
 	case ACPI_TYPE_DEVICE:
+		if (acpi_device_should_be_hidden(handle))
+			return -ENODEV;
+
 		*type = ACPI_BUS_TYPE_DEVICE;
 		status = acpi_bus_get_status_handle(handle, sta);
 		if (ACPI_FAILURE(status))
@@ -1919,6 +1964,8 @@  static int acpi_bus_scan_fixed(void)
 int __init acpi_scan_init(void)
 {
 	int result;
+	acpi_status status;
+	struct acpi_table_stao *stao_ptr;
 
 	acpi_pci_root_init();
 	acpi_pci_link_init();
@@ -1933,6 +1980,27 @@  int __init acpi_scan_init(void)
 
 	acpi_scan_add_handler(&generic_device_handler);
 
+	/* If there is STAO table, check whether it needs to ignore the UART
+	 * device in SPCR table.
+	 */
+	status = acpi_get_table(ACPI_SIG_STAO, 0,
+				(struct acpi_table_header **)&stao_ptr);
+	if (ACPI_SUCCESS(status)) {
+		if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+			printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
+
+		if (stao_ptr->ignore_uart) {
+			struct acpi_table_spcr *spcr_ptr;
+
+			status = acpi_get_table(ACPI_SIG_SPCR, 0,
+					(struct acpi_table_header **)&spcr_ptr);
+			if (ACPI_SUCCESS(status))
+				spcr_uart_addr = spcr_ptr->serial_port.address;
+			else
+				printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
+		}
+	}
+
 	mutex_lock(&acpi_scan_lock);
 	/*
 	 * Enumerate devices in the ACPI namespace.