All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sinan Kaya <okaya@codeaurora.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	linux-acpi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Hanjun Guo <hanjun.guo@linaro.org>,
	Tomasz Nowicki <tn@semihalf.com>,
	Nate Watterson <nwatters@codeaurora.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH] ACPI/IORT: Fix iort_node_get_id() mapping entries indexing
Date: Sat, 7 Jan 2017 16:09:33 -0500	[thread overview]
Message-ID: <f089f31e-cc9e-291d-091e-00a10ba78cca@codeaurora.org> (raw)
In-Reply-To: <20170105182921.8167-1-lorenzo.pieralisi@arm.com>

On 1/5/2017 1:29 PM, Lorenzo Pieralisi wrote:
> Commit 618f535a6062 ("ACPI/IORT: Add single mapping function")
> introduced a function (iort_node_get_id()) to retrieve ids for IORT
> named components.
> 
> iort_node_get_id() takes an index as input to refer to a specific
> mapping entry in the mapping array to retrieve the id at a specific
> index provided the index is below the total mapping count; currently the
> index is used to retrieve the mapping value from the correct entry but
> not to dereference the correct entry while retrieving the mapping
> output_reference (ie IORT parent pointer), which consequently always
> resolves to the output_reference of the first entry in the mapping
> array.
> 
> Update the map array entry pointer computation in iort_node_get_id() to
> take into account the index value, fixing the issue.
> 
> Fixes: 618f535a6062 ("ACPI/IORT: Add single mapping function")
> Reported-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Sinan Kaya <okaya@codeaurora.org>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Nate Watterson <nwatters@codeaurora.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> ---
>  drivers/acpi/arm64/iort.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index e0d2e6e..ba156c5 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -333,7 +333,7 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
>  		return NULL;
>  
>  	map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
> -			   node->mapping_offset);
> +			   node->mapping_offset + index * sizeof(*map));

What does this give us that the previous code didn't do?

You are using map as a pointer and returning the offset of the first map entry above
and then accessing the map at the indexed offset with map[index]

The new code is using map as a plain pointer, calculating the pointer location with ACPI_ADD_PTR
instead and then collecting the output parameter with map->output_base.

>  
>  	/* Firmware bug! */
>  	if (!map->output_reference) {
> @@ -348,10 +348,10 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
>  	if (!(IORT_TYPE_MASK(parent->type) & type_mask))
>  		return NULL;
>  
> -	if (map[index].flags & ACPI_IORT_ID_SINGLE_MAPPING) {
> +	if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
>  		if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
>  		    node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
> -			*id_out = map[index].output_base;
> +			*id_out = map->output_base;

You are claiming that the existing code is collecting the output parameter from the first mapping.
I don't see this happening above.

What am I missing?

>  			return parent;
>  		}
>  	}
> 

If we are just doing a housekeeping, this is fine. I couldn't see an actual bug getting fixed.

-- 
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.

  parent reply	other threads:[~2017-01-07 21:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-05 18:29 [PATCH] ACPI/IORT: Fix iort_node_get_id() mapping entries indexing Lorenzo Pieralisi
2017-01-05 18:37 ` Sinan Kaya
2017-01-06  9:48   ` Lorenzo Pieralisi
2017-01-07 21:09 ` Sinan Kaya [this message]
2017-01-09  6:34   ` Hanjun Guo
2017-01-09  6:48     ` Hanjun Guo
2017-01-09 11:20     ` okaya
2017-01-09  8:01 ` Hanjun Guo

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=f089f31e-cc9e-291d-091e-00a10ba78cca@codeaurora.org \
    --to=okaya@codeaurora.org \
    --cc=hanjun.guo@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=nwatters@codeaurora.org \
    --cc=rjw@rjwysocki.net \
    --cc=tn@semihalf.com \
    /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.