All of lore.kernel.org
 help / color / mirror / Atom feed
From: robin.murphy@arm.com (Robin Murphy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] clocksource/arm_arch_timer: Enable and verify MMIO access
Date: Fri, 29 Jan 2016 19:44:59 +0000	[thread overview]
Message-ID: <56ABC13B.9080500@arm.com> (raw)
In-Reply-To: <20160129183051.GO12841@codeaurora.org>

On 29/01/16 18:30, Stephen Boyd wrote:
> On 01/29, Robin Murphy wrote:
>> So far, we have been blindly assuming that if a memory-mapped timer
>> frame exists, then we have access to it. Whilst it's the firmware's
>> job to give us non-secure access to frames in the first place, we
>> should not rely on it always being generous enough to also configure
>> CNTACR if it's not even using those frames itself.
>
> Hm, that first sentence is sort of misleading. We've been blindly
> assuming that the firmware has configured CNTACR to have the
> correct bits set for virtual/physical access. We've always relied
> on status = "disabled" to figure out if we can access an entire
> frame or not.

Yeah, now that I read it back that sentence is nonsense for anything 
other than the very specific ideas of "frame" and "exists" that were 
passing through my head at some point last week - how about this instead?

"So far, we have been blindly assuming that having access to a 
memory-mapped timer frame implies that the individual elements of that 
frame are already enabled."

>>
>> Explicitly enable feature-level access per-frame, and verify that the
>> access we want is really implemented before trying to make use of it.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>>   drivers/clocksource/arm_arch_timer.c | 39 ++++++++++++++++++++++++++++--------
>>   1 file changed, 31 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>> index c64d543..c88485d 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -765,20 +772,34 @@ static void __init arch_timer_mem_init(struct device_node *np)
>>   	 */
>>   	for_each_available_child_of_node(np, frame) {
>>   		int n;
>> +		u32 cntacr;
>>
>>   		if (of_property_read_u32(frame, "frame-number", &n)) {
>>   			pr_err("arch_timer: Missing frame-number\n");
>> -			of_node_put(best_frame);
>>   			of_node_put(frame);
>> -			return;
>> +			goto out;
>>   		}
>>
>> -		if (cnttidr & CNTTIDR_VIRT(n)) {
>> +		/* Try enabling everything, and see what sticks */
>> +		cntacr = CNTACR_RFRQ | CNTACR_RWPT | CNTACR_RPCT |
>> +			 CNTACR_RWVT | CNTACR_RVOFF | CNTACR_RVCT;
>> +		writel_relaxed(cntacr, cntctlbase + CNTACR(n));
>> +		cntacr = readl_relaxed(cntctlbase + CNTACR(n));
>> +
>> +		if (~cntacr & CNTACR_RFRQ)
>> +			continue;
>
> Do we need this check? If we can't read the frequency we fall
> back to looking for the DT property, so it shouldn't matter if we
> can't read the hardware there.

I was really just playing safe to start with. If we don't have cause to 
care about the difference between not having access vs. not having a 
frequency programmed then I'd agree it can probably go.

>> +
>> +		if ((cnttidr & CNTTIDR_VIRT(n)) &&
>> +		    !(~cntacr & (CNTACR_RWVT | CNTACR_RVCT))) {
>>   			of_node_put(best_frame);
>>   			best_frame = frame;
>>   			arch_timer_mem_use_virtual = true;
>>   			break;
>>   		}
>> +
>> +		if (~cntacr & (CNTACR_RWPT | CNTACR_RPCT))
>> +			continue;
>> +
>>   		of_node_put(best_frame);
>>   		best_frame = of_node_get(frame);
>>   	}
>
> Otherwise the patch looks fine and passes some light testing on
> qcom devices.

Great, thanks. The Trusted Firmware guys' warning shot has gone upstream 
already, if it helps:

https://github.com/ARM-software/arm-trusted-firmware/commit/01fc3f7300e86b0b672977133c3028d638d0c672

> BTW, I'd like to add this patch on top so that we get some info
> in /proc/iomem about which frame region is in use.

It's about time I educated myself on what all the resource stuff really 
means, but superficially it seems reasonable, and it certainly makes the 
expected "2a830000-2a83ffff : arch_mem_timer" show up on my Juno.

Thanks,
Robin.

> ---8<---
> From: Stephen Boyd <sboyd@codeaurora.org>
> Subject: [PATCH] clocksource/arm_arch_timer: Map frame with
>   of_io_request_and_map()
>
> Let's use the of_io_request_and_map() API so that the frame
> region is protected and shows up in /proc/iomem.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>   drivers/clocksource/arm_arch_timer.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index c88485d489bf..59a08fd4f76a 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -804,7 +804,8 @@ static void __init arch_timer_mem_init(struct device_node *np)
>   		best_frame = of_node_get(frame);
>   	}
>
> -	base = arch_counter_base = of_iomap(best_frame, 0);
> +	base = arch_counter_base = of_io_request_and_map(best_frame, 0,
> +							 "arch_mem_timer");
>   	if (!base) {
>   		pr_err("arch_timer: Can't map frame's registers\n");
>   		goto out;
>

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: mark.rutland@arm.com, tglx@linutronix.de,
	daniel.lezcano@linaro.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] clocksource/arm_arch_timer: Enable and verify MMIO access
Date: Fri, 29 Jan 2016 19:44:59 +0000	[thread overview]
Message-ID: <56ABC13B.9080500@arm.com> (raw)
In-Reply-To: <20160129183051.GO12841@codeaurora.org>

On 29/01/16 18:30, Stephen Boyd wrote:
> On 01/29, Robin Murphy wrote:
>> So far, we have been blindly assuming that if a memory-mapped timer
>> frame exists, then we have access to it. Whilst it's the firmware's
>> job to give us non-secure access to frames in the first place, we
>> should not rely on it always being generous enough to also configure
>> CNTACR if it's not even using those frames itself.
>
> Hm, that first sentence is sort of misleading. We've been blindly
> assuming that the firmware has configured CNTACR to have the
> correct bits set for virtual/physical access. We've always relied
> on status = "disabled" to figure out if we can access an entire
> frame or not.

Yeah, now that I read it back that sentence is nonsense for anything 
other than the very specific ideas of "frame" and "exists" that were 
passing through my head at some point last week - how about this instead?

"So far, we have been blindly assuming that having access to a 
memory-mapped timer frame implies that the individual elements of that 
frame are already enabled."

>>
>> Explicitly enable feature-level access per-frame, and verify that the
>> access we want is really implemented before trying to make use of it.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>>   drivers/clocksource/arm_arch_timer.c | 39 ++++++++++++++++++++++++++++--------
>>   1 file changed, 31 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>> index c64d543..c88485d 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -765,20 +772,34 @@ static void __init arch_timer_mem_init(struct device_node *np)
>>   	 */
>>   	for_each_available_child_of_node(np, frame) {
>>   		int n;
>> +		u32 cntacr;
>>
>>   		if (of_property_read_u32(frame, "frame-number", &n)) {
>>   			pr_err("arch_timer: Missing frame-number\n");
>> -			of_node_put(best_frame);
>>   			of_node_put(frame);
>> -			return;
>> +			goto out;
>>   		}
>>
>> -		if (cnttidr & CNTTIDR_VIRT(n)) {
>> +		/* Try enabling everything, and see what sticks */
>> +		cntacr = CNTACR_RFRQ | CNTACR_RWPT | CNTACR_RPCT |
>> +			 CNTACR_RWVT | CNTACR_RVOFF | CNTACR_RVCT;
>> +		writel_relaxed(cntacr, cntctlbase + CNTACR(n));
>> +		cntacr = readl_relaxed(cntctlbase + CNTACR(n));
>> +
>> +		if (~cntacr & CNTACR_RFRQ)
>> +			continue;
>
> Do we need this check? If we can't read the frequency we fall
> back to looking for the DT property, so it shouldn't matter if we
> can't read the hardware there.

I was really just playing safe to start with. If we don't have cause to 
care about the difference between not having access vs. not having a 
frequency programmed then I'd agree it can probably go.

>> +
>> +		if ((cnttidr & CNTTIDR_VIRT(n)) &&
>> +		    !(~cntacr & (CNTACR_RWVT | CNTACR_RVCT))) {
>>   			of_node_put(best_frame);
>>   			best_frame = frame;
>>   			arch_timer_mem_use_virtual = true;
>>   			break;
>>   		}
>> +
>> +		if (~cntacr & (CNTACR_RWPT | CNTACR_RPCT))
>> +			continue;
>> +
>>   		of_node_put(best_frame);
>>   		best_frame = of_node_get(frame);
>>   	}
>
> Otherwise the patch looks fine and passes some light testing on
> qcom devices.

Great, thanks. The Trusted Firmware guys' warning shot has gone upstream 
already, if it helps:

https://github.com/ARM-software/arm-trusted-firmware/commit/01fc3f7300e86b0b672977133c3028d638d0c672

> BTW, I'd like to add this patch on top so that we get some info
> in /proc/iomem about which frame region is in use.

It's about time I educated myself on what all the resource stuff really 
means, but superficially it seems reasonable, and it certainly makes the 
expected "2a830000-2a83ffff : arch_mem_timer" show up on my Juno.

Thanks,
Robin.

> ---8<---
> From: Stephen Boyd <sboyd@codeaurora.org>
> Subject: [PATCH] clocksource/arm_arch_timer: Map frame with
>   of_io_request_and_map()
>
> Let's use the of_io_request_and_map() API so that the frame
> region is protected and shows up in /proc/iomem.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>   drivers/clocksource/arm_arch_timer.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index c88485d489bf..59a08fd4f76a 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -804,7 +804,8 @@ static void __init arch_timer_mem_init(struct device_node *np)
>   		best_frame = of_node_get(frame);
>   	}
>
> -	base = arch_counter_base = of_iomap(best_frame, 0);
> +	base = arch_counter_base = of_io_request_and_map(best_frame, 0,
> +							 "arch_mem_timer");
>   	if (!base) {
>   		pr_err("arch_timer: Can't map frame's registers\n");
>   		goto out;
>

  reply	other threads:[~2016-01-29 19:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-29 14:57 [PATCH] clocksource/arm_arch_timer: Enable and verify MMIO access Robin Murphy
2016-01-29 14:57 ` Robin Murphy
2016-01-29 18:30 ` Stephen Boyd
2016-01-29 18:30   ` Stephen Boyd
2016-01-29 19:44   ` Robin Murphy [this message]
2016-01-29 19:44     ` Robin Murphy
2016-01-29 20:04     ` Stephen Boyd
2016-01-29 20:04       ` Stephen Boyd

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=56ABC13B.9080500@arm.com \
    --to=robin.murphy@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.