lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 14 Jun 2019 19:51:31 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Jon Hunter <jonathanh@...dia.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Joseph Lo <josephl@...dia.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Peter De Schrijver <pdeschrijver@...dia.com>
Cc:     linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 6/6] clocksource/drivers/tegra: Restore base address
 before cleanup

14.06.2019 18:48, Jon Hunter пишет:
> 
> On 10/06/2019 17:44, Dmitry Osipenko wrote:
>> We're adjusting the timer's base for each per-CPU timer to point to the
>> actual start of the timer since device-tree defines a compound registers
>> range that includes all of the timers. In this case the original base
>> need to be restore before calling iounmap to unmap the proper address.
>>
>> Signed-off-by: Dmitry Osipenko <digetx@...il.com>
>> ---
>>  drivers/clocksource/timer-tegra.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/clocksource/timer-tegra.c b/drivers/clocksource/timer-tegra.c
>> index 2a428fdf702f..7be91db98bd7 100644
>> --- a/drivers/clocksource/timer-tegra.c
>> +++ b/drivers/clocksource/timer-tegra.c
>> @@ -345,6 +345,8 @@ static int __init tegra_init_timer(struct device_node *np, bool tegra20,
>>  			irq_dispose_mapping(cpu_to->clkevt.irq);
>>  		}
>>  	}
>> +
>> +	to->of_base.base = timer_reg_base;
>>  out:
>>  	timer_of_cleanup(to);
> 
> So what you are saying is that because we don't know which CPU executes
> the tegra_init_timer() function, then it is necessary to restore the
> base. IOW if it is not CPU0, then the base will be updated and hence,
> need to be restored. Correct?

We know what the CPU is, it is always CPU0. What we don't know is what TIMER is
assigned for CPU0. On Tegra210 it is TIMER10, for other Tegra's it is TIMER0.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ