From: Suzuki.Poulose@arm.com (Suzuki K. Poulose)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 07/22] arm64: Keep track of CPU feature registers
Date: Fri, 9 Oct 2015 11:56:14 +0100 [thread overview]
Message-ID: <56179D4E.9030403@arm.com> (raw)
In-Reply-To: <56163D7F.4000003@arm.com>
On 08/10/15 10:55, Suzuki K. Poulose wrote:
> On 07/10/15 18:16, Catalin Marinas wrote:
>> On Mon, Oct 05, 2015 at 06:01:56PM +0100, Suzuki K. Poulose wrote:
>>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>>> index 1ae8b24..d42ad90 100644
>>> --- a/arch/arm64/kernel/cpufeature.c
>>> +++ b/arch/arm64/kernel/cpufeature.c
>>> @@ -58,8 +58,442 @@ static void update_mixed_endian_el0_support(struct cpuinfo_arm64 *info)
>>> mixed_endian_el0 &= id_aa64mmfr0_mixed_endian_el0(info->reg_id_aa64mmfr0);
>>> + * sys_reg() encoding.
>>> + *
>>> + * We track only the following space:
>>> + * Op0 = 3, Op1 = 0, CRn = 0, CRm = [1 - 7], Op2 = [0 - 7]
>>> + * Op0 = 3, Op1 = 3, CRn = 0, CRm = 0, Op2 = { 1, 7 } (CTR, DCZID)
>>> + * Op0 = 3, Op1 = 3, CRn = 14, CRm = 0, Op2 = 0 (CNTFRQ)
>>> + *
>>> + * The space (3, 0, 0, {1-7}, {0-7}) is arranged in a 2D array op1_0,
>>> + * indexed by CRm and Op2. Since not all CRm's have fully allocated Op2's
>>> + * arm64_reg_table[CRm-1].n indicates the largest Op2 tracked for CRm.
>>> + *
>>> + * Since we have limited number of entries with Op1 = 3, we use linear search
>>> + * to find the reg.
>>> + *
>>> + */
>>> +static struct arm64_ftr_reg* get_arm64_sys_reg(u32 sys_id)
>>> +{
>>> + int i;
>>> + u8 op2, crn, crm;
>>> + u8 op1 = sys_reg_Op1(sys_id);
>>> +
>>> + if (sys_reg_Op0(sys_id) != 3)
>>> + return NULL;
>>> + switch (op1) {
>>> + case 0:
>>> +
>>> + crm = sys_reg_CRm(sys_id);
>>> + op2 = sys_reg_Op2(sys_id);
>>> + crn = sys_reg_CRn(sys_id);
>>> + if (crn || !crm || crm > 7)
>>> + return NULL;
>>> + if (op2 < op1_0[crm - 1].n &&
>>> + op1_0[crm - 1].regs[op2].sys_id == sys_id)
>>> + return &op1_0[crm - 1].regs[op2];
>>> + return NULL;
>>> + case 3:
>>> + for (i = 0; i < ARRAY_SIZE(op1_3); i++)
>>> + if (op1_3[i].sys_id == sys_id)
>>> + return &op1_3[i];
>>> + }
>>> + return NULL;
>>> +}
>>
>> For this function, do we ever expect to be called with an invalid
>> sys_id? You could add a BUG_ON(!ret) here.
>>
>
> It could be called for an id which Reserved RAZ in the id range, we
> plan to emulate. i.e, (3, 0, 0, [0-7], [0-7]).
> See emulate_sys_reg(u32 id, u64 *valp) in Patch 20/22.
> Since we don't track them, we return NULL here..
> We could BUG_ON() all the other cases (e.g, MIDR and the other
> classes).
>
> Thanks for pointing that out.
Actually, the error handling is left to the users of the function.
We do a BUG_ON() in the caller. e.g, init/update_cpu_ftr_reg can't
accept a NULL and BUGs. While the emulate_sys_reg() issues the call
only for the emualted feature registers(excluding MIDR/REVIDR etc),
so a NULL is perfectly acceptable for them.
Thanks
Suzuki
WARNING: multiple messages have this Message-ID (diff)
From: "Suzuki K. Poulose" <Suzuki.Poulose@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
Vladimir.Murzin@arm.com, steve.capper@linaro.org,
ard.biesheuvel@linaro.org, marc.zyngier@arm.com,
will.deacon@arm.com, linux-kernel@vger.kernel.org,
edward.nevill@linaro.org, aph@redhat.com, james.morse@arm.com,
andre.przywara@arm.com, dave.martin@arm.com
Subject: Re: [PATCH v2 07/22] arm64: Keep track of CPU feature registers
Date: Fri, 9 Oct 2015 11:56:14 +0100 [thread overview]
Message-ID: <56179D4E.9030403@arm.com> (raw)
In-Reply-To: <56163D7F.4000003@arm.com>
On 08/10/15 10:55, Suzuki K. Poulose wrote:
> On 07/10/15 18:16, Catalin Marinas wrote:
>> On Mon, Oct 05, 2015 at 06:01:56PM +0100, Suzuki K. Poulose wrote:
>>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>>> index 1ae8b24..d42ad90 100644
>>> --- a/arch/arm64/kernel/cpufeature.c
>>> +++ b/arch/arm64/kernel/cpufeature.c
>>> @@ -58,8 +58,442 @@ static void update_mixed_endian_el0_support(struct cpuinfo_arm64 *info)
>>> mixed_endian_el0 &= id_aa64mmfr0_mixed_endian_el0(info->reg_id_aa64mmfr0);
>>> + * sys_reg() encoding.
>>> + *
>>> + * We track only the following space:
>>> + * Op0 = 3, Op1 = 0, CRn = 0, CRm = [1 - 7], Op2 = [0 - 7]
>>> + * Op0 = 3, Op1 = 3, CRn = 0, CRm = 0, Op2 = { 1, 7 } (CTR, DCZID)
>>> + * Op0 = 3, Op1 = 3, CRn = 14, CRm = 0, Op2 = 0 (CNTFRQ)
>>> + *
>>> + * The space (3, 0, 0, {1-7}, {0-7}) is arranged in a 2D array op1_0,
>>> + * indexed by CRm and Op2. Since not all CRm's have fully allocated Op2's
>>> + * arm64_reg_table[CRm-1].n indicates the largest Op2 tracked for CRm.
>>> + *
>>> + * Since we have limited number of entries with Op1 = 3, we use linear search
>>> + * to find the reg.
>>> + *
>>> + */
>>> +static struct arm64_ftr_reg* get_arm64_sys_reg(u32 sys_id)
>>> +{
>>> + int i;
>>> + u8 op2, crn, crm;
>>> + u8 op1 = sys_reg_Op1(sys_id);
>>> +
>>> + if (sys_reg_Op0(sys_id) != 3)
>>> + return NULL;
>>> + switch (op1) {
>>> + case 0:
>>> +
>>> + crm = sys_reg_CRm(sys_id);
>>> + op2 = sys_reg_Op2(sys_id);
>>> + crn = sys_reg_CRn(sys_id);
>>> + if (crn || !crm || crm > 7)
>>> + return NULL;
>>> + if (op2 < op1_0[crm - 1].n &&
>>> + op1_0[crm - 1].regs[op2].sys_id == sys_id)
>>> + return &op1_0[crm - 1].regs[op2];
>>> + return NULL;
>>> + case 3:
>>> + for (i = 0; i < ARRAY_SIZE(op1_3); i++)
>>> + if (op1_3[i].sys_id == sys_id)
>>> + return &op1_3[i];
>>> + }
>>> + return NULL;
>>> +}
>>
>> For this function, do we ever expect to be called with an invalid
>> sys_id? You could add a BUG_ON(!ret) here.
>>
>
> It could be called for an id which Reserved RAZ in the id range, we
> plan to emulate. i.e, (3, 0, 0, [0-7], [0-7]).
> See emulate_sys_reg(u32 id, u64 *valp) in Patch 20/22.
> Since we don't track them, we return NULL here..
> We could BUG_ON() all the other cases (e.g, MIDR and the other
> classes).
>
> Thanks for pointing that out.
Actually, the error handling is left to the users of the function.
We do a BUG_ON() in the caller. e.g, init/update_cpu_ftr_reg can't
accept a NULL and BUGs. While the emulate_sys_reg() issues the call
only for the emualted feature registers(excluding MIDR/REVIDR etc),
so a NULL is perfectly acceptable for them.
Thanks
Suzuki
next prev parent reply other threads:[~2015-10-09 10:56 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-05 17:01 [PATCH v2 00/22] arm64: Consolidate CPU feature handling Suzuki K. Poulose
2015-10-05 17:01 ` Suzuki K. Poulose
2015-10-05 17:01 ` [PATCH v2 01/22] arm64: Make the CPU information more clear Suzuki K. Poulose
2015-10-05 17:01 ` Suzuki K. Poulose
2015-10-05 17:01 ` [PATCH v2 02/22] arm64: Delay ELF HWCAP initialisation until all CPUs are up Suzuki K. Poulose
2015-10-05 17:01 ` Suzuki K. Poulose
2015-10-05 17:01 ` [PATCH v2 03/22] arm64: Move cpu feature detection code Suzuki K. Poulose
2015-10-05 17:01 ` Suzuki K. Poulose
2015-10-05 17:01 ` [PATCH v2 04/22] arm64: Move mixed endian support detection Suzuki K. Poulose
2015-10-05 17:01 ` Suzuki K. Poulose
2015-10-05 17:01 ` [PATCH v2 05/22] arm64: Move /proc/cpuinfo handling code Suzuki K. Poulose
2015-10-05 17:01 ` Suzuki K. Poulose
2015-10-05 17:01 ` [PATCH v2 06/22] arm64: sys_reg: Define System register encoding Suzuki K. Poulose
2015-10-05 17:01 ` Suzuki K. Poulose
2015-10-07 16:36 ` Catalin Marinas
2015-10-07 16:36 ` Catalin Marinas
2015-10-07 17:03 ` Suzuki K. Poulose
2015-10-07 17:03 ` Suzuki K. Poulose
2015-10-08 14:43 ` Catalin Marinas
2015-10-08 14:43 ` Catalin Marinas
2015-10-08 16:13 ` Suzuki K. Poulose
2015-10-08 16:13 ` Suzuki K. Poulose
2015-10-05 17:01 ` [PATCH v2 07/22] arm64: Keep track of CPU feature registers Suzuki K. Poulose
2015-10-05 17:01 ` Suzuki K. Poulose
2015-10-07 17:16 ` Catalin Marinas
2015-10-07 17:16 ` Catalin Marinas
2015-10-08 9:55 ` Suzuki K. Poulose
2015-10-08 9:55 ` Suzuki K. Poulose
2015-10-08 15:03 ` Catalin Marinas
2015-10-08 15:03 ` Catalin Marinas
2015-10-09 13:00 ` Suzuki K. Poulose
2015-10-09 13:00 ` Suzuki K. Poulose
2015-10-12 17:01 ` Suzuki K. Poulose
2015-10-12 17:01 ` Suzuki K. Poulose
2015-10-12 17:21 ` Mark Rutland
2015-10-12 17:21 ` Mark Rutland
2015-10-13 9:40 ` Catalin Marinas
2015-10-13 9:40 ` Catalin Marinas
2015-10-09 10:56 ` Suzuki K. Poulose [this message]
2015-10-09 10:56 ` Suzuki K. Poulose
2015-10-09 14:16 ` Catalin Marinas
2015-10-09 14:16 ` Catalin Marinas
2015-10-05 17:01 ` [PATCH v2 08/22] arm64: Consolidate CPU Sanity check to CPU Feature infrastructure Suzuki K. Poulose
2015-10-05 17:01 ` Suzuki K. Poulose
2015-10-05 17:01 ` [PATCH v2 09/22] arm64: Read system wide CPUID value Suzuki K. Poulose
2015-10-05 17:01 ` Suzuki K. Poulose
2015-10-05 17:01 ` [PATCH v2 10/22] arm64: Cleanup mixed endian support detection Suzuki K. Poulose
2015-10-05 17:01 ` Suzuki K. Poulose
2015-10-05 17:02 ` [PATCH v2 11/22] arm64: Populate cpuinfo after notify_cpu_starting Suzuki K. Poulose
2015-10-05 17:02 ` Suzuki K. Poulose
2015-10-08 10:15 ` Catalin Marinas
2015-10-08 10:15 ` Catalin Marinas
2015-10-08 10:46 ` Suzuki K. Poulose
2015-10-08 10:46 ` Suzuki K. Poulose
2015-10-09 15:01 ` Suzuki K. Poulose
2015-10-09 15:01 ` Suzuki K. Poulose
2015-10-05 17:02 ` [PATCH v2 12/22] arm64: Delay cpu feature checks Suzuki K. Poulose
2015-10-05 17:02 ` Suzuki K. Poulose
2015-10-06 4:41 ` kbuild test robot
2015-10-06 4:41 ` kbuild test robot
2015-10-06 11:09 ` Suzuki K. Poulose
2015-10-06 11:09 ` Suzuki K. Poulose
2015-10-08 11:08 ` Catalin Marinas
2015-10-08 11:08 ` Catalin Marinas
2015-10-13 10:12 ` Suzuki K. Poulose
2015-10-13 10:12 ` Suzuki K. Poulose
2015-10-05 17:02 ` [PATCH v2 13/22] arm64: Make use of system wide capability checks Suzuki K. Poulose
2015-10-05 17:02 ` Suzuki K. Poulose
2015-10-05 17:02 ` [PATCH v2 14/22] arm64: Cleanup HWCAP handling Suzuki K. Poulose
2015-10-05 17:02 ` Suzuki K. Poulose
2015-10-08 11:10 ` Catalin Marinas
2015-10-08 11:10 ` Catalin Marinas
2015-10-08 11:17 ` Russell King - ARM Linux
2015-10-08 11:17 ` Russell King - ARM Linux
2015-10-08 13:00 ` Catalin Marinas
2015-10-08 13:00 ` Catalin Marinas
2015-10-08 14:54 ` Edward Nevill
2015-10-08 14:54 ` Edward Nevill
2015-10-05 17:02 ` [PATCH v2 15/22] arm64: Move FP/ASIMD hwcap handling to common code Suzuki K. Poulose
2015-10-05 17:02 ` Suzuki K. Poulose
2015-10-05 17:02 ` [PATCH v2 16/22] arm64/debug: Make use of the system wide safe value Suzuki K. Poulose
2015-10-05 17:02 ` Suzuki K. Poulose
2015-10-08 11:11 ` Catalin Marinas
2015-10-08 11:11 ` Catalin Marinas
2015-10-08 11:56 ` Suzuki K. Poulose
2015-10-08 11:56 ` Suzuki K. Poulose
2015-10-08 15:08 ` Catalin Marinas
2015-10-08 15:08 ` Catalin Marinas
2015-10-08 15:57 ` Suzuki K. Poulose
2015-10-08 15:57 ` Suzuki K. Poulose
2015-10-05 17:02 ` [PATCH v2 17/22] arm64/kvm: Make use of the system wide safe values Suzuki K. Poulose
2015-10-05 17:02 ` Suzuki K. Poulose
2015-10-05 17:02 ` Suzuki K. Poulose
2015-10-10 15:17 ` Christoffer Dall
2015-10-10 15:17 ` Christoffer Dall
2015-10-10 15:17 ` Christoffer Dall
2015-10-05 17:02 ` [PATCH v2 18/22] arm64: Add helper to decode register from instruction Suzuki K. Poulose
2015-10-05 17:02 ` Suzuki K. Poulose
2015-10-05 17:02 ` [PATCH v2 19/22] arm64: cpufeature: Track the user visible fields Suzuki K. Poulose
2015-10-05 17:02 ` Suzuki K. Poulose
2015-10-05 17:02 ` [PATCH v2 20/22] arm64: Expose feature registers by emulating MRS Suzuki K. Poulose
2015-10-05 17:02 ` Suzuki K. Poulose
2015-10-05 17:02 ` [PATCH v2 21/22] arm64: cpuinfo: Expose MIDR_EL1 and REVIDR_EL1 to sysfs Suzuki K. Poulose
2015-10-05 17:02 ` Suzuki K. Poulose
2015-10-06 9:09 ` Russell King - ARM Linux
2015-10-06 9:09 ` Russell King - ARM Linux
2015-10-06 10:18 ` Steve Capper
2015-10-06 10:18 ` Steve Capper
2015-10-06 10:25 ` Mark Rutland
2015-10-06 10:25 ` Mark Rutland
2015-10-06 10:29 ` Steve Capper
2015-10-06 10:29 ` Steve Capper
2015-10-06 19:16 ` Russell King - ARM Linux
2015-10-06 19:16 ` Russell King - ARM Linux
2015-10-05 17:02 ` [PATCH v2 22/22] arm64: feature registers: Documentation Suzuki K. Poulose
2015-10-05 17:02 ` Suzuki K. Poulose
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=56179D4E.9030403@arm.com \
--to=suzuki.poulose@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.