public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
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

  parent reply	other threads:[~2015-10-09 10:56 UTC|newest]

Thread overview: 57+ 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 ` [PATCH v2 01/22] arm64: Make the CPU information more clear 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 ` [PATCH v2 03/22] arm64: Move cpu feature detection code 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 ` [PATCH v2 05/22] arm64: Move /proc/cpuinfo handling code Suzuki K. Poulose
2015-10-05 17:01 ` [PATCH v2 06/22] arm64: sys_reg: Define System register encoding Suzuki K. Poulose
2015-10-07 16:36   ` Catalin Marinas
2015-10-07 17:03     ` Suzuki K. Poulose
2015-10-08 14:43       ` Catalin Marinas
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-07 17:16   ` Catalin Marinas
2015-10-08  9:55     ` Suzuki K. Poulose
2015-10-08 15:03       ` Catalin Marinas
2015-10-09 13:00         ` Suzuki K. Poulose
2015-10-12 17:01         ` Suzuki K. Poulose
2015-10-12 17:21           ` Mark Rutland
2015-10-13  9:40             ` Catalin Marinas
2015-10-09 10:56       ` Suzuki K. Poulose [this message]
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 ` [PATCH v2 09/22] arm64: Read system wide CPUID value 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:02 ` [PATCH v2 11/22] arm64: Populate cpuinfo after notify_cpu_starting Suzuki K. Poulose
2015-10-08 10:15   ` Catalin Marinas
2015-10-08 10:46     ` 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-06  4:41   ` kbuild test robot
2015-10-06 11:09     ` Suzuki K. Poulose
2015-10-08 11:08   ` Catalin Marinas
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 ` [PATCH v2 14/22] arm64: Cleanup HWCAP handling Suzuki K. Poulose
2015-10-08 11:10   ` Catalin Marinas
2015-10-08 11:17     ` Russell King - ARM Linux
2015-10-08 13:00       ` Catalin Marinas
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 ` [PATCH v2 16/22] arm64/debug: Make use of the system wide safe value Suzuki K. Poulose
2015-10-08 11:11   ` Catalin Marinas
2015-10-08 11:56     ` Suzuki K. Poulose
2015-10-08 15:08       ` Catalin Marinas
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-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 ` [PATCH v2 19/22] arm64: cpufeature: Track the user visible fields 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 ` [PATCH v2 21/22] arm64: cpuinfo: Expose MIDR_EL1 and REVIDR_EL1 to sysfs Suzuki K. Poulose
2015-10-06  9:09   ` Russell King - ARM Linux
2015-10-06 10:18     ` Steve Capper
2015-10-06 10:25       ` Mark Rutland
2015-10-06 10:29         ` Steve Capper
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

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$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox