linux-kernel - Re: [PATCH 10/20] clocksource/drivers/vf-pit: Encapsulate the macros

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <daa0bea0-780d-4ed6-ab6b-16437fa270af@linaro.org>
Date: Mon, 28 Jul 2025 10:35:53 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Ghennadi Procopciuc <ghennadi.procopciuc@....nxp.com>, tglx@...utronix.de
Cc: S32@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/20] clocksource/drivers/vf-pit: Encapsulate the macros

On 07/07/2025 14:03, Ghennadi Procopciuc wrote:
> On 7/5/2025 7:01 PM, Daniel Lezcano wrote:
>> Pass the base address to the macro, so we can use the macro with
>> multiple instances of the timer because we deal with different base
>> address. At the same time, change writes to the register to the
>> existing corresponding functions.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@...aro.org>
>> ---
>>   drivers/clocksource/timer-vf-pit.c | 35 ++++++++++++++++--------------
>>   1 file changed, 19 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/clocksource/timer-vf-pit.c b/drivers/clocksource/timer-vf-pit.c
>> index 066d0d2600f4..9c5e06506c26 100644
>> --- a/drivers/clocksource/timer-vf-pit.c
>> +++ b/drivers/clocksource/timer-vf-pit.c
>> @@ -16,18 +16,21 @@
>>   #define PITMCR		0x00
>>   #define PIT0_OFFSET	0x100
>>   #define PIT_CH(n)       (PIT0_OFFSET + 0x10 * (n))
>> -#define PITLDVAL	0x00
>> +
>>   #define PITCVAL		0x04
>> -#define PITTCTRL	0x08
>> -#define PITTFLG		0x0c
> 
> The registers PITLDVAL, PITCVAL, PITTCTRL, and PITTFLG refer to individual PIT channels rather than global PIT registers. Shouldn't this distinction be reflected in their naming? I would suggest prefixing them with PIT_CH_ to improve clarity and indicate their per-channel scope.

Reasonably, I would like to keep them as is otherwise it would be out of 
the scope of these changes which are aiming to set the scene for 
multiple PITs support. If the naming convention has to be changed, that 
could be addressed later in a separate series.

-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog