* [PATCH v4 6/9] arm64: Add helper to decode register from instruction
From: Suzuki K Poulose @ 2017-01-09 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483982912-27215-1-git-send-email-suzuki.poulose@arm.com>
Add a helper to extract the register field from a given
instruction.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/insn.h | 2 ++
arch/arm64/kernel/insn.c | 29 +++++++++++++++++++++++++++++
2 files changed, 31 insertions(+)
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index bc85366..aecc07e 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -332,6 +332,8 @@ bool aarch64_insn_is_branch(u32 insn);
u64 aarch64_insn_decode_immediate(enum aarch64_insn_imm_type type, u32 insn);
u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
u32 insn, u64 imm);
+u32 aarch64_insn_decode_register(enum aarch64_insn_register_type type,
+ u32 insn);
u32 aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr,
enum aarch64_insn_branch_type type);
u32 aarch64_insn_gen_comp_branch_imm(unsigned long pc, unsigned long addr,
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 94b62c1..1f44cf8 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -417,6 +417,35 @@ u32 __kprobes aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
return insn;
}
+u32 aarch64_insn_decode_register(enum aarch64_insn_register_type type,
+ u32 insn)
+{
+ int shift;
+
+ switch (type) {
+ case AARCH64_INSN_REGTYPE_RT:
+ case AARCH64_INSN_REGTYPE_RD:
+ shift = 0;
+ break;
+ case AARCH64_INSN_REGTYPE_RN:
+ shift = 5;
+ break;
+ case AARCH64_INSN_REGTYPE_RT2:
+ case AARCH64_INSN_REGTYPE_RA:
+ shift = 10;
+ break;
+ case AARCH64_INSN_REGTYPE_RM:
+ shift = 16;
+ break;
+ default:
+ pr_err("%s: unknown register type encoding %d\n", __func__,
+ type);
+ return 0;
+ }
+
+ return (insn >> shift) & GENMASK(4, 0);
+}
+
static u32 aarch64_insn_encode_register(enum aarch64_insn_register_type type,
u32 insn,
enum aarch64_insn_register reg)
--
2.7.4
^ permalink raw reply related
* [PATCH v4 7/9] arm64: cpufeature: Track user visible fields
From: Suzuki K Poulose @ 2017-01-09 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483982912-27215-1-git-send-email-suzuki.poulose@arm.com>
Track the user visible fields of a CPU feature register. This will be
used for exposing the value to the userspace. All the user visible
fields of a feature register will be passed on as it is, while the
others would be filled with their respective safe value.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Changes since V3:
- Mark ID_AA64ISAR0_EL1:RDM visible
Changes since V2:
- Mark DCZID_EL0 fields visible, as the register is already accessible
to EL0.
---
arch/arm64/include/asm/cpufeature.h | 11 +++
arch/arm64/kernel/cpufeature.c | 189 +++++++++++++++++++-----------------
arch/arm64/kernel/traps.c | 2 +-
3 files changed, 111 insertions(+), 91 deletions(-)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 10d5624..4ce82ed 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -55,8 +55,12 @@ enum ftr_type {
#define FTR_SIGNED true /* Value should be treated as signed */
#define FTR_UNSIGNED false /* Value should be treated as unsigned */
+#define FTR_VISIBLE true /* Feature visible to the user space */
+#define FTR_HIDDEN false /* Feature is hidden from the user */
+
struct arm64_ftr_bits {
bool sign; /* Value is signed ? */
+ bool visible;
bool strict; /* CPU Sanity check: strict matching required ? */
enum ftr_type type;
u8 shift;
@@ -72,7 +76,9 @@ struct arm64_ftr_bits {
struct arm64_ftr_reg {
const char *name;
u64 strict_mask;
+ u64 user_mask;
u64 sys_val;
+ u64 user_val;
const struct arm64_ftr_bits *ftr_bits;
};
@@ -172,6 +178,11 @@ static inline u64 arm64_ftr_mask(const struct arm64_ftr_bits *ftrp)
return (u64)GENMASK(ftrp->shift + ftrp->width - 1, ftrp->shift);
}
+static inline u64 arm64_ftr_reg_user_value(const struct arm64_ftr_reg *reg)
+{
+ return (reg->user_val | (reg->sys_val & reg->user_mask));
+}
+
static inline int __attribute_const__
cpuid_feature_extract_field(u64 features, int field, bool sign)
{
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index fb519e1..346faec 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -52,9 +52,10 @@ EXPORT_SYMBOL(cpu_hwcaps);
DEFINE_STATIC_KEY_ARRAY_FALSE(cpu_hwcap_keys, ARM64_NCAPS);
EXPORT_SYMBOL(cpu_hwcap_keys);
-#define __ARM64_FTR_BITS(SIGNED, STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL) \
+#define __ARM64_FTR_BITS(SIGNED, VISIBLE, STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL) \
{ \
.sign = SIGNED, \
+ .visible = VISIBLE, \
.strict = STRICT, \
.type = TYPE, \
.shift = SHIFT, \
@@ -63,12 +64,12 @@ EXPORT_SYMBOL(cpu_hwcap_keys);
}
/* Define a feature with unsigned values */
-#define ARM64_FTR_BITS(STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL) \
- __ARM64_FTR_BITS(FTR_UNSIGNED, STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL)
+#define ARM64_FTR_BITS(VISIBLE, STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL) \
+ __ARM64_FTR_BITS(FTR_UNSIGNED, VISIBLE, STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL)
/* Define a feature with a signed value */
-#define S_ARM64_FTR_BITS(STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL) \
- __ARM64_FTR_BITS(FTR_SIGNED, STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL)
+#define S_ARM64_FTR_BITS(VISIBLE, STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL) \
+ __ARM64_FTR_BITS(FTR_SIGNED, VISIBLE, STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL)
#define ARM64_FTR_END \
{ \
@@ -81,75 +82,75 @@ cpufeature_pan_not_uao(const struct arm64_cpu_capabilities *entry, int __unused)
static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64ISAR0_RDM_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_ATOMICS_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_CRC32_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA2_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA1_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_AES_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, ID_AA64ISAR0_RDM_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_ATOMICS_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_CRC32_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA2_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA1_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_AES_SHIFT, 4, 0),
ARM64_FTR_END,
};
static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64PFR0_GIC_SHIFT, 4, 0),
- S_ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
- S_ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_FP_SHIFT, 4, ID_AA64PFR0_FP_NI),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64PFR0_GIC_SHIFT, 4, 0),
+ S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
+ S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_FP_SHIFT, 4, ID_AA64PFR0_FP_NI),
/* Linux doesn't care about the EL3 */
- ARM64_FTR_BITS(FTR_NONSTRICT, FTR_EXACT, ID_AA64PFR0_EL3_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64PFR0_EL2_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64PFR0_EL1_SHIFT, 4, ID_AA64PFR0_EL1_64BIT_ONLY),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64PFR0_EL0_SHIFT, 4, ID_AA64PFR0_EL0_64BIT_ONLY),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT, ID_AA64PFR0_EL3_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64PFR0_EL2_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64PFR0_EL1_SHIFT, 4, ID_AA64PFR0_EL1_64BIT_ONLY),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64PFR0_EL0_SHIFT, 4, ID_AA64PFR0_EL0_64BIT_ONLY),
ARM64_FTR_END,
};
static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
- S_ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI),
- S_ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR0_BIGENDEL0_SHIFT, 4, 0),
+ S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI),
+ S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64MMFR0_BIGENDEL0_SHIFT, 4, 0),
/* Linux shouldn't care about secure memory */
- ARM64_FTR_BITS(FTR_NONSTRICT, FTR_EXACT, ID_AA64MMFR0_SNSMEM_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR0_BIGENDEL_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR0_ASID_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT, ID_AA64MMFR0_SNSMEM_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64MMFR0_BIGENDEL_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64MMFR0_ASID_SHIFT, 4, 0),
/*
* Differing PARange is fine as long as all peripherals and memory are mapped
* within the minimum PARange of all CPUs
*/
- ARM64_FTR_BITS(FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_PARANGE_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_PARANGE_SHIFT, 4, 0),
ARM64_FTR_END,
};
static const struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_PAN_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR1_LOR_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR1_HPD_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR1_VHE_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR1_VMIDBITS_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR1_HADBS_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_PAN_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64MMFR1_LOR_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64MMFR1_HPD_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64MMFR1_VHE_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64MMFR1_VMIDBITS_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64MMFR1_HADBS_SHIFT, 4, 0),
ARM64_FTR_END,
};
static const struct arm64_ftr_bits ftr_id_aa64mmfr2[] = {
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR2_LVA_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR2_IESB_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR2_LSM_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR2_UAO_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR2_CNP_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64MMFR2_LVA_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64MMFR2_IESB_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64MMFR2_LSM_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64MMFR2_UAO_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64MMFR2_CNP_SHIFT, 4, 0),
ARM64_FTR_END,
};
static const struct arm64_ftr_bits ftr_ctr[] = {
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 31, 1, 1), /* RAO */
- ARM64_FTR_BITS(FTR_STRICT, FTR_HIGHER_SAFE, 24, 4, 0), /* CWG */
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 20, 4, 0), /* ERG */
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 16, 4, 1), /* DminLine */
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, 31, 1, 1), /* RAO */
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_SAFE, 24, 4, 0), /* CWG */
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 20, 4, 0), /* ERG */
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 16, 4, 1), /* DminLine */
/*
* Linux can handle differing I-cache policies. Userspace JITs will
* make use of *minLine.
* If we have differing I-cache policies, report it as the weakest - AIVIVT.
*/
- ARM64_FTR_BITS(FTR_NONSTRICT, FTR_EXACT, 14, 2, ICACHE_POLICY_AIVIVT), /* L1Ip */
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 0, 4, 0), /* IminLine */
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_EXACT, 14, 2, ICACHE_POLICY_AIVIVT), /* L1Ip */
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 0, 4, 0), /* IminLine */
ARM64_FTR_END,
};
@@ -159,73 +160,73 @@ struct arm64_ftr_reg arm64_ftr_reg_ctrel0 = {
};
static const struct arm64_ftr_bits ftr_id_mmfr0[] = {
- S_ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 28, 4, 0xf), /* InnerShr */
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 24, 4, 0), /* FCSE */
- ARM64_FTR_BITS(FTR_NONSTRICT, FTR_LOWER_SAFE, 20, 4, 0), /* AuxReg */
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 16, 4, 0), /* TCM */
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 12, 4, 0), /* ShareLvl */
- S_ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 8, 4, 0xf), /* OuterShr */
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 4, 4, 0), /* PMSA */
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 0, 4, 0), /* VMSA */
+ S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 28, 4, 0xf), /* InnerShr */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 24, 4, 0), /* FCSE */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 20, 4, 0), /* AuxReg */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 16, 4, 0), /* TCM */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 12, 4, 0), /* ShareLvl */
+ S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 8, 4, 0xf), /* OuterShr */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 4, 4, 0), /* PMSA */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 0, 4, 0), /* VMSA */
ARM64_FTR_END,
};
static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 32, 32, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_CTX_CMPS_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_WRPS_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_BRPS_SHIFT, 4, 0),
- S_ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64DFR0_PMUVER_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64DFR0_TRACEVER_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x6),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 32, 32, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_CTX_CMPS_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_WRPS_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_BRPS_SHIFT, 4, 0),
+ S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_PMUVER_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_TRACEVER_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x6),
ARM64_FTR_END,
};
static const struct arm64_ftr_bits ftr_mvfr2[] = {
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 4, 4, 0), /* FPMisc */
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 0, 4, 0), /* SIMDMisc */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 4, 4, 0), /* FPMisc */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 0, 4, 0), /* SIMDMisc */
ARM64_FTR_END,
};
static const struct arm64_ftr_bits ftr_dczid[] = {
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 4, 1, 1), /* DZP */
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 0, 4, 0), /* BS */
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, 4, 1, 1), /* DZP */
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 0, 4, 0), /* BS */
ARM64_FTR_END,
};
static const struct arm64_ftr_bits ftr_id_isar5[] = {
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_ISAR5_RDM_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_ISAR5_CRC32_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_ISAR5_SHA2_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_ISAR5_SHA1_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_ISAR5_AES_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_ISAR5_SEVL_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_ISAR5_RDM_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_ISAR5_CRC32_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_ISAR5_SHA2_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_ISAR5_SHA1_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_ISAR5_AES_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_ISAR5_SEVL_SHIFT, 4, 0),
ARM64_FTR_END,
};
static const struct arm64_ftr_bits ftr_id_mmfr4[] = {
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 4, 4, 0), /* ac2 */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 4, 4, 0), /* ac2 */
ARM64_FTR_END,
};
static const struct arm64_ftr_bits ftr_id_pfr0[] = {
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 12, 4, 0), /* State3 */
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 8, 4, 0), /* State2 */
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 4, 4, 0), /* State1 */
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 0, 4, 0), /* State0 */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 12, 4, 0), /* State3 */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 8, 4, 0), /* State2 */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 4, 4, 0), /* State1 */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 0, 4, 0), /* State0 */
ARM64_FTR_END,
};
static const struct arm64_ftr_bits ftr_id_dfr0[] = {
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 28, 4, 0),
- S_ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 24, 4, 0xf), /* PerfMon */
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 20, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 16, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 12, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 8, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 4, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 0, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 28, 4, 0),
+ S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 24, 4, 0xf), /* PerfMon */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 20, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 16, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 12, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 8, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 4, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 0, 4, 0),
ARM64_FTR_END,
};
@@ -236,20 +237,20 @@ static const struct arm64_ftr_bits ftr_id_dfr0[] = {
* id_isar[0-4], id_mmfr[1-3], id_pfr1, mvfr[0-1]
*/
static const struct arm64_ftr_bits ftr_generic_32bits[] = {
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 28, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 24, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 20, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 16, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 12, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 8, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 4, 4, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 0, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 28, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 24, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 20, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 16, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 12, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 8, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 4, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 0, 4, 0),
ARM64_FTR_END,
};
/* Table for a single 32bit feature value */
static const struct arm64_ftr_bits ftr_single32[] = {
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 0, 32, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 0, 32, 0),
ARM64_FTR_END,
};
@@ -397,6 +398,7 @@ static void __init init_cpu_ftr_reg(u32 sys_reg, u64 new)
{
u64 val = 0;
u64 strict_mask = ~0x0ULL;
+ u64 user_mask = 0;
u64 valid_mask = 0;
const struct arm64_ftr_bits *ftrp;
@@ -413,12 +415,19 @@ static void __init init_cpu_ftr_reg(u32 sys_reg, u64 new)
valid_mask |= ftr_mask;
if (!ftrp->strict)
strict_mask &= ~ftr_mask;
+ if (ftrp->visible)
+ user_mask |= ftr_mask;
+ else
+ reg->user_val = arm64_ftr_set_value(ftrp,
+ reg->user_val,
+ ftrp->safe_val);
}
val &= valid_mask;
reg->sys_val = val;
reg->strict_mask = strict_mask;
+ reg->user_mask = user_mask;
}
void __init init_cpu_features(struct cpuinfo_arm64 *info)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 5b830be..8187229 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -496,7 +496,7 @@ static void ctr_read_handler(unsigned int esr, struct pt_regs *regs)
{
int rt = (esr & ESR_ELx_SYS64_ISS_RT_MASK) >> ESR_ELx_SYS64_ISS_RT_SHIFT;
- regs->regs[rt] = arm64_ftr_reg_ctrel0.sys_val;
+ regs->regs[rt] = arm64_ftr_reg_user_value(&arm64_ftr_reg_ctrel0);
regs->pc += 4;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v4 8/9] arm64: cpufeature: Expose CPUID registers by emulation
From: Suzuki K Poulose @ 2017-01-09 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483982912-27215-1-git-send-email-suzuki.poulose@arm.com>
This patch adds the hook for emulating MRS instruction to
export the 'user visible' value of supported system registers.
We emulate only the following id space for system registers:
Op0=3, Op1=0, CRn=0, CRm=[0, 4-7]
The rest will fall back to SIGILL. This capability is also
advertised via a new HWCAP_CPUID.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/sysreg.h | 4 ++
arch/arm64/include/uapi/asm/hwcap.h | 1 +
arch/arm64/kernel/cpufeature.c | 101 ++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/cpuinfo.c | 1 +
4 files changed, 107 insertions(+)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index cf43064..86a207a 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -264,6 +264,10 @@
#define ID_AA64MMFR0_TGRAN_SUPPORTED ID_AA64MMFR0_TGRAN64_SUPPORTED
#endif
+
+/* Safe value for MPIDR_EL1: Bit31:RES1, Bit30:U:0, Bit24:MT:0 */
+#define SYS_MPIDR_SAFE_VAL (1UL << 31)
+
#ifdef __ASSEMBLY__
.irp num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30
diff --git a/arch/arm64/include/uapi/asm/hwcap.h b/arch/arm64/include/uapi/asm/hwcap.h
index a739287..773c90b 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -30,5 +30,6 @@
#define HWCAP_ATOMICS (1 << 8)
#define HWCAP_FPHP (1 << 9)
#define HWCAP_ASIMDHP (1 << 10)
+#define HWCAP_CPUID (1 << 11)
#endif /* _UAPI__ASM_HWCAP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 346faec..6494f9b 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -29,6 +29,7 @@
#include <asm/mmu_context.h>
#include <asm/processor.h>
#include <asm/sysreg.h>
+#include <asm/traps.h>
#include <asm/virt.h>
unsigned long elf_hwcap __read_mostly;
@@ -932,6 +933,8 @@ static bool cpus_have_elf_hwcap(const struct arm64_cpu_capabilities *cap)
static void __init setup_elf_hwcaps(const struct arm64_cpu_capabilities *hwcaps)
{
+ /* We support emulation of accesses to CPU ID feature registers */
+ elf_hwcap |= HWCAP_CPUID;
for (; hwcaps->matches; hwcaps++)
if (hwcaps->matches(hwcaps, hwcaps->def_scope))
cap_set_elf_hwcap(hwcaps);
@@ -1119,3 +1122,101 @@ cpufeature_pan_not_uao(const struct arm64_cpu_capabilities *entry, int __unused)
{
return (cpus_have_const_cap(ARM64_HAS_PAN) && !cpus_have_const_cap(ARM64_HAS_UAO));
}
+
+/*
+ * We emulate only the following system register space.
+ * Op0 = 0x3, CRn = 0x0, Op1 = 0x0, CRm = [0, 4 - 7]
+ * See Table C5-6 System instruction encodings for System register accesses,
+ * ARMv8 ARM(ARM DDI 0487A.f) for more details.
+ */
+static inline bool __attribute_const__ is_emulated(u32 id)
+{
+ return (sys_reg_Op0(id) == 0x3 &&
+ sys_reg_CRn(id) == 0x0 &&
+ sys_reg_Op1(id) == 0x0 &&
+ (sys_reg_CRm(id) == 0 ||
+ ((sys_reg_CRm(id) >= 4) && (sys_reg_CRm(id) <= 7))));
+}
+
+/*
+ * With CRm == 0, reg should be one of :
+ * MIDR_EL1, MPIDR_EL1 or REVIDR_EL1.
+ */
+static inline int emulate_id_reg(u32 id, u64 *valp)
+{
+ switch (id) {
+ case SYS_MIDR_EL1:
+ *valp = read_cpuid_id();
+ break;
+ case SYS_MPIDR_EL1:
+ *valp = SYS_MPIDR_SAFE_VAL;
+ break;
+ case SYS_REVIDR_EL1:
+ /* IMPLEMENTATION DEFINED values are emulated with 0 */
+ *valp = 0;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int emulate_sys_reg(u32 id, u64 *valp)
+{
+ struct arm64_ftr_reg *regp;
+
+ if (!is_emulated(id))
+ return -EINVAL;
+
+ if (sys_reg_CRm(id) == 0)
+ return emulate_id_reg(id, valp);
+
+ regp = get_arm64_ftr_reg(id);
+ if (regp)
+ *valp = arm64_ftr_reg_user_value(regp);
+ else
+ /*
+ * The untracked registers are either IMPLEMENTATION DEFINED
+ * (e.g, ID_AFR0_EL1) or reserved RAZ.
+ */
+ *valp = 0;
+ return 0;
+}
+
+static int emulate_mrs(struct pt_regs *regs, u32 insn)
+{
+ int rc;
+ u32 sys_reg, dst;
+ u64 val;
+
+ /*
+ * sys_reg values are defined as used in mrs/msr instruction.
+ * shift the imm value to get the encoding.
+ */
+ sys_reg = (u32)aarch64_insn_decode_immediate(AARCH64_INSN_IMM_16, insn) << 5;
+ rc = emulate_sys_reg(sys_reg, &val);
+ if (!rc) {
+ dst = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RT, insn);
+ regs->user_regs.regs[dst] = val;
+ regs->pc += 4;
+ }
+
+ return rc;
+}
+
+static struct undef_hook mrs_hook = {
+ .instr_mask = 0xfff00000,
+ .instr_val = 0xd5300000,
+ .pstate_mask = COMPAT_PSR_MODE_MASK,
+ .pstate_val = PSR_MODE_EL0t,
+ .fn = emulate_mrs,
+};
+
+int __init enable_mrs_emulation(void)
+{
+ register_undef_hook(&mrs_hook);
+ return 0;
+}
+
+late_initcall(enable_mrs_emulation);
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 7b7be71..4d44edd 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -63,6 +63,7 @@ static const char *const hwcap_str[] = {
"atomics",
"fphp",
"asimdhp",
+ "cpuid",
NULL
};
--
2.7.4
^ permalink raw reply related
* [PATCH v4 9/9] arm64: Documentation - Expose CPU feature registers
From: Suzuki K Poulose @ 2017-01-09 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483982912-27215-1-git-send-email-suzuki.poulose@arm.com>
Documentation for the infrastructure to expose CPU feature
register by emulating MRS.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Dave Martin <dave.martin@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Changes since V3:
- Mark RES0 fields as hidden and remove the RAZ registers from the
exposed list, as RES0 fields are hidden.
- Removed obsolete references
Changes since V2:
- Include the sample program in the documentation
---
Documentation/arm64/cpu-feature-registers.txt | 240 ++++++++++++++++++++++++++
arch/arm64/kernel/cpufeature.c | 4 +
2 files changed, 244 insertions(+)
create mode 100644 Documentation/arm64/cpu-feature-registers.txt
diff --git a/Documentation/arm64/cpu-feature-registers.txt b/Documentation/arm64/cpu-feature-registers.txt
new file mode 100644
index 0000000..61ca21e
--- /dev/null
+++ b/Documentation/arm64/cpu-feature-registers.txt
@@ -0,0 +1,240 @@
+ ARM64 CPU Feature Registers
+ ===========================
+
+Author: Suzuki K Poulose <suzuki.poulose@arm.com>
+
+
+This file describes the ABI for exporting the AArch64 CPU ID/feature
+registers to userspace. The availability of this ABI is advertised
+via the HWCAP_CPUID in HWCAPs.
+
+1. Motivation
+---------------
+
+The ARM architecture defines a set of feature registers, which describe
+the capabilities of the CPU/system. Access to these system registers is
+restricted from EL0 and there is no reliable way for an application to
+extract this information to make better decisions at runtime. There is
+limited information available to the application via HWCAPs, however
+there are some issues with their usage.
+
+ a) Any change to the HWCAPs requires an update to userspace (e.g libc)
+ to detect the new changes, which can take a long time to appear in
+ distributions. Exposing the registers allows applications to get the
+ information without requiring updates to the toolchains.
+
+ b) Access to HWCAPs is sometimes limited (e.g prior to libc, or
+ when ld is initialised at startup time).
+
+ c) HWCAPs cannot represent non-boolean information effectively. The
+ architecture defines a canonical format for representing features
+ in the ID registers; this is well defined and is capable of
+ representing all valid architecture variations.
+
+
+2. Requirements
+-----------------
+
+ a) Safety :
+ Applications should be able to use the information provided by the
+ infrastructure to run safely across the system. This has greater
+ implications on a system with heterogeneous CPUs.
+ The infrastructure exports a value that is safe across all the
+ available CPU on the system.
+
+ e.g, If at least one CPU doesn't implement CRC32 instructions, while
+ others do, we should report that the CRC32 is not implemented.
+ Otherwise an application could crash when scheduled on the CPU
+ which doesn't support CRC32.
+
+ b) Security :
+ Applications should only be able to receive information that is
+ relevant to the normal operation in userspace. Hence, some of the
+ fields are masked out(i.e, made invisible) and their values are set to
+ indicate the feature is 'not supported'. See Section 4 for the list
+ of visible features. Also, the kernel may manipulate the fields
+ based on what it supports. e.g, If FP is not supported by the
+ kernel, the values could indicate that the FP is not available
+ (even when the CPU provides it).
+
+ c) Implementation Defined Features
+ The infrastructure doesn't expose any register which is
+ IMPLEMENTATION DEFINED as per ARMv8-A Architecture.
+
+ d) CPU Identification :
+ MIDR_EL1 is exposed to help identify the processor. On a
+ heterogeneous system, this could be racy (just like getcpu()). The
+ process could be migrated to another CPU by the time it uses the
+ register value, unless the CPU affinity is set. Hence, there is no
+ guarantee that the value reflects the processor that it is
+ currently executing on. The REVIDR is not exposed due to this
+ constraint, as REVIDR makes sense only in conjunction with the
+ MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
+ at:
+
+ /sys/devices/system/cpu/cpu$ID/regs/identification/
+ \- midr
+ \- revidr
+
+3. Implementation
+--------------------
+
+The infrastructure is built on the emulation of the 'MRS' instruction.
+Accessing a restricted system register from an application generates an
+exception and ends up in SIGILL being delivered to the process.
+The infrastructure hooks into the exception handler and emulates the
+operation if the source belongs to the supported system register space.
+
+The infrastructure emulates only the following system register space:
+ Op0=3, Op1=0, CRn=0, CRm=0,4,5,6,7
+
+(See Table C5-6 'System instruction encodings for non-Debug System
+register accesses' in ARMv8 ARM DDI 0487A.h, for the list of
+registers).
+
+The following rules are applied to the value returned by the
+infrastructure:
+
+ a) The value of an 'IMPLEMENTATION DEFINED' field is set to 0.
+ b) The value of a reserved field is populated with the reserved
+ value as defined by the architecture.
+ c) The value of a 'visible' field holds the system wide safe value
+ for the particular feature (except for MIDR_EL1, see section 4).
+ d) All other fields (i.e, invisible fields) are set to indicate
+ the feature is missing (as defined by the architecture).
+
+4. List of registers with visible features
+-------------------------------------------
+
+ 1) ID_AA64ISAR0_EL1 - Instruction Set Attribute Register 0
+ x--------------------------------------------------x
+ | Name | bits | visible |
+ |--------------------------------------------------|
+ | RES0 | [63-32] | n |
+ |--------------------------------------------------|
+ | RDM | [31-28] | y |
+ |--------------------------------------------------|
+ | ATOMICS | [23-20] | y |
+ |--------------------------------------------------|
+ | CRC32 | [19-16] | y |
+ |--------------------------------------------------|
+ | SHA2 | [15-12] | y |
+ |--------------------------------------------------|
+ | SHA1 | [11-8] | y |
+ |--------------------------------------------------|
+ | AES | [7-4] | y |
+ |--------------------------------------------------|
+ | RES0 | [3-0] | n |
+ x--------------------------------------------------x
+
+
+ 2) ID_AA64PFR0_EL1 - Processor Feature Register 0
+ x--------------------------------------------------x
+ | Name | bits | visible |
+ |--------------------------------------------------|
+ | RES0 | [63-28] | n |
+ |--------------------------------------------------|
+ | GIC | [27-24] | n |
+ |--------------------------------------------------|
+ | AdvSIMD | [23-20] | y |
+ |--------------------------------------------------|
+ | FP | [19-16] | y |
+ |--------------------------------------------------|
+ | EL3 | [15-12] | n |
+ |--------------------------------------------------|
+ | EL2 | [11-8] | n |
+ |--------------------------------------------------|
+ | EL1 | [7-4] | n |
+ |--------------------------------------------------|
+ | EL0 | [3-0] | n |
+ x--------------------------------------------------x
+
+
+ 3) MIDR_EL1 - Main ID Register
+ x--------------------------------------------------x
+ | Name | bits | visible |
+ |--------------------------------------------------|
+ | Implementer | [31-24] | y |
+ |--------------------------------------------------|
+ | Variant | [23-20] | y |
+ |--------------------------------------------------|
+ | Architecture | [19-16] | y |
+ |--------------------------------------------------|
+ | PartNum | [15-4] | y |
+ |--------------------------------------------------|
+ | Revision | [3-0] | y |
+ x--------------------------------------------------x
+
+ NOTE: The 'visible' fields of MIDR_EL1 will contain the value
+ as available on the CPU where it is fetched and is not a system
+ wide safe value.
+
+Appendix I: Example
+---------------------------
+
+/*
+ * Sample program to demonstrate the MRS emulation ABI.
+ *
+ * Copyright (C) 2015-2016, ARM Ltd
+ *
+ * Author: Suzuki K Poulose <suzuki.poulose@arm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/hwcap.h>
+#include <stdio.h>
+#include <sys/auxv.h>
+
+#define get_cpu_ftr(id) ({ \
+ unsigned long __val; \
+ asm("mrs %0, "#id : "=r" (__val)); \
+ printf("%-20s: 0x%016lx\n", #id, __val); \
+ })
+
+int main(void)
+{
+
+ if (!(getauxval(AT_HWCAP) & HWCAP_CPUID)) {
+ fputs("CPUID registers unavailable\n", stderr);
+ return 1;
+ }
+
+ get_cpu_ftr(ID_AA64ISAR0_EL1);
+ get_cpu_ftr(ID_AA64ISAR1_EL1);
+ get_cpu_ftr(ID_AA64MMFR0_EL1);
+ get_cpu_ftr(ID_AA64MMFR1_EL1);
+ get_cpu_ftr(ID_AA64PFR0_EL1);
+ get_cpu_ftr(ID_AA64PFR1_EL1);
+ get_cpu_ftr(ID_AA64DFR0_EL1);
+ get_cpu_ftr(ID_AA64DFR1_EL1);
+
+ get_cpu_ftr(MIDR_EL1);
+ get_cpu_ftr(MPIDR_EL1);
+ get_cpu_ftr(REVIDR_EL1);
+
+#if 0
+ /* Unexposed register access causes SIGILL */
+ get_cpu_ftr(ID_MMFR0_EL1);
+#endif
+
+ return 0;
+}
+
+
+
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 6494f9b..fa707e3 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -82,6 +82,10 @@ static bool __maybe_unused
cpufeature_pan_not_uao(const struct arm64_cpu_capabilities *entry, int __unused);
+/*
+ * NOTE: Any changes to the visibility of features should be kept in
+ * sync with the documentation of the CPU feature register ABI.
+ */
static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, ID_AA64ISAR0_RDM_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_ATOMICS_SHIFT, 4, 0),
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v4 2/2] net: stmmac: dwmac-meson8b: make the RGMII TX delay configurable
From: Martin Blumenstingl @ 2017-01-09 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCDZ_mqt8q2rG6zDy8ke5sX6L+4sVYOOhWUdO3apwFiRYw@mail.gmail.com>
Hi David,
On Sun, Dec 18, 2016 at 5:13 PM, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> On Sun, Dec 18, 2016 at 4:49 PM, David Miller <davem@davemloft.net> wrote:
>> From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> Date: Sat, 17 Dec 2016 19:21:19 +0100
>>
>>> Prior to this patch we were using a hardcoded RGMII TX clock delay of
>>> 2ns (= 1/4 cycle of the 125MHz RGMII TX clock). This value works for
>>> many boards, but unfortunately not for all (due to the way the actual
>>> circuit is designed, sometimes because the TX delay is enabled in the
>>> PHY, etc.). Making the TX delay on the MAC side configurable allows us
>>> to support all possible hardware combinations.
>>>
>>> This allows fixing a compatibility issue on some boards, where the
>>> RTL8211F PHY is configured to generate the TX delay. We can now turn
>>> off the TX delay in the MAC, because otherwise we would be applying the
>>> delay twice (which results in non-working TX traffic).
>>>
>>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>>> Tested-by: Neil Armstrong <narmstrong@baylibre.com>
>>
>> Is this really the safest thing to do?
>>
>> If you say the existing hard-coded setting of 1/4 cycle works on most
>> boards, and what you're trying to do is override it with an OF
>> property value for boards where the existing setting does not work,
>> then you _must_ use a default value that corresponds to what the
>> existing code does not when you don't see this new OF property.
> it's a bit more complicated in reality: 1/4 cycle works when the TX
> delay of the RTL8211F PHY is turned off (until recently it was always
> enabled for phy-mode RGMII).
>
>> So please retain the current behavior of the 1/4 cycle TX delay
>> setting when you don't see the amlogic,tx-delay-ns property.
>>
>> I really think you risk breaking existing boards by not doing so,
>> unless you can have this patch tested on every such board that exists
>> and I don't think you really can feasibly and rigorously do that.
> there's a patch in my follow-up series which adds the 2ns to the .dts
> for all RGMII based boards: [0] (and I would keep these even if we had
> a default value, just to make it explicit and thus easier to
> understand for other people).
> however, we can add the 2ns default back (I can do this if you want -
> Rob Herring was unhappy with the missing documentation of this default
> value [1] - so note to myself: take care of that as well). but then we
> have to decide when to apply this default value: only when we're in
> RGMII mode or also in any of the RGMII_*ID modes?
>
> please let me know how we should proceed
gentle ping - what is your opinion on this?
Regards,
Martin
^ permalink raw reply
* APM smmu implementation
From: Feng Kan @ 2017-01-09 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109105421.GA21398@arm.com>
On Mon, Jan 9, 2017 at 2:54 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Jan 06, 2017 at 03:21:34PM -0800, Feng Kan wrote:
>> The APM IOMMU implementation is mostly just the ARM SMMU 500 variant.
>> However, our internal bus is only 42 bits wide. Our IAS field is coded
>> as 48 bits, which cause IPA to truncated to 42 bits on the physical
>> bus. In order for our system to work with the arm-smmu.c, there needs
>> to be a way to force the ipa_size to 42. The current internal solution
>> is to use the cpuid, but that is quite ugly. I was thinking of using
>> the model
>
> Just so I understand, what are the UBS and OAS values on your part?
UBS/OAS/IAS are all default to 5.
>
>> as indication to right the ipa_size, but I am not too sure of the ACPI
>> side. Would it be okay to add an APM MMU500 variant? I would also
>> appreciated it if you guys have any alternate solutions.
>
> For this sort of implementation erratum, I think using the model field
> is the right thing to do. However, you'll need to get your model registered
> with IORT, so I've added Charles to cc since he maintains that document.
>
> Also, please add a device-tree property to override the IAS once you
> start writing patches.
>
> Will
^ permalink raw reply
* [PATCH v1.1] ARM: multi_v7_defconfig: Enable power sequence for Odroid U3
From: Krzysztof Kozlowski @ 2017-01-09 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d8ee24b1-9d6b-e76f-b5ef-71706efbf9e5@osg.samsung.com>
On Mon, Jan 9, 2017 at 6:24 PM, Javier Martinez Canillas
<javier@osg.samsung.com> wrote:
> Hello Krzysztof,
>
> I think it would had been clearer if the subject prefix was "[PATCH v1.1 4/4]" :)
Ah, yes.
>
> On 01/07/2017 06:16 AM, Krzysztof Kozlowski wrote:
>> Odroid U3 needs a power sequence for lan9730, if it was enabled by
>> bootloader. Also enable the USB3503 HSCI to USB2.0 driver (device
>> is present on Odroid U3).
>>
>> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>>
>> ---
>>
>
> Do you think that makes sense to also enable GPIO_SYS for debugging
> purposes as you do in patch 3/4?
I like the GPIO_SYSFS interface because it is easy to use. However
now, after your question, I found this:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/470154.html
ARM/ARM64: defconfig: drop GPIO_SYSFS on multiplatforms
... so instead I will drop it from exynos_defconfig.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v1.1] ARM: multi_v7_defconfig: Enable power sequence for Odroid U3
From: Javier Martinez Canillas @ 2017-01-09 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPdODg2gCXP-BCRhDZAc2+o1J7Ek9iLaYF7hn_R2mNiK3A@mail.gmail.com>
Hello Krzysztof,
On 01/09/2017 02:38 PM, Krzysztof Kozlowski wrote:
> On Mon, Jan 9, 2017 at 6:24 PM, Javier Martinez Canillas
> <javier@osg.samsung.com> wrote:
>> Hello Krzysztof,
>>
>> I think it would had been clearer if the subject prefix was "[PATCH v1.1 4/4]" :)
>
> Ah, yes.
>
>>
>> On 01/07/2017 06:16 AM, Krzysztof Kozlowski wrote:
>>> Odroid U3 needs a power sequence for lan9730, if it was enabled by
>>> bootloader. Also enable the USB3503 HSCI to USB2.0 driver (device
>>> is present on Odroid U3).
>>>
>>> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>>>
>>> ---
>>>
>>
>> Do you think that makes sense to also enable GPIO_SYS for debugging
>> purposes as you do in patch 3/4?
>
> I like the GPIO_SYSFS interface because it is easy to use. However
> now, after your question, I found this:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/470154.html
> ARM/ARM64: defconfig: drop GPIO_SYSFS on multiplatforms
>
> ... so instead I will drop it from exynos_defconfig.
>
Right, I forgot that using the GPIO sysfs interface is discouraged now and the
new chardev/ioctl based should be used instead. So it makes sense to drop it.
> Best regards,
> Krzysztof
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* APM smmu implementation
From: Feng Kan @ 2017-01-09 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109120300.GC21398@arm.com>
On Mon, Jan 9, 2017 at 4:03 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Jan 09, 2017 at 11:34:42AM +0000, Robin Murphy wrote:
>> On 06/01/17 23:21, Feng Kan wrote:
>> > The APM IOMMU implementation is mostly just the ARM SMMU 500 variant.
>>
>> "Mostly"? Have APM actually modified it (which I strongly doubt) or do
>> you mean it's simply been integrated with the upper address lines tied
>> off?
Yes, and that we only do stage 2 translation.
MMU-500 reports a 48-bit IAS because MMU-500 has 48-bit-wide slave
>> interfaces; that's all there is to it. Whether or not you use all of
>> those bits is up to you as a system integrator.
>
> That's a good point; MMU-500 doesn't appear to let you change the IAS
> anyway. That should also mean that UBS and OAS are unchanged.
>
>> > However, our internal bus is only 42 bits wide. Our IAS field is coded
>> > as 48 bits, which cause IPA to truncated to 42 bits on the physical
>> > bus. In order for our system to work with the arm-smmu.c, there needs
>> > to be a way to force the ipa_size to 42. The current internal solution
>> > is to use the cpuid, but that is quite ugly. I was thinking of using
>> > the model
>> > as indication to right the ipa_size, but I am not too sure of the ACPI
>> > side. Would it be okay to add an APM MMU500 variant? I would also
>> > appreciated it if you guys have any alternate solutions.
>>
>> This is something we've been axpecting to run into for a while now - the
>> appropriate solution is to use a "dma-ranges" property on the master
>> device(s) to describe that they have 42 bits of address wired up, from
>> which they will then inherit the appropriate DMA mask. The outstanding
>> issue which remains is that we're still missing some way of preventing
>> drivers simply clobbering that with a 64-bit mask later, but that's a
>> more general problem[1].
Thanks, I have thought about this as well. As you have stated, it
simply does not work for all at this point.
>
> I wonder if the driver is actually using IAS, OAS and UBS incorrectly.
> We're using them to parameterise the DMA aperture, which is then used
> to size the IOVA domain, but that's wrong because the IAS, OAS and UBS
> are upper bounds and we can still end up allocating unusable/unreachable
> addresses.
>
> So I do think that this should be fixed on the SMMU firmware node, rather
> than restricting the range of each master device.
I am more partial to the Will's idea, adding an override
attribute would be the simplest at this point.
>
> Will
^ permalink raw reply
* [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains
From: Rob Herring @ 2017-01-09 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104205536.15963-3-d-gerlach@ti.com>
On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
> Add a generic power domain implementation, TI SCI PM Domains, that
> will hook into the genpd framework and allow the TI SCI protocol to
> control device power states.
>
> Also, provide macros representing each device index as understood
> by TI SCI to be used in the device node power-domain references.
> These are identifiers for the K2G devices managed by the PMMC.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> v2->v3:
> Update k2g_pds node docs to show it should be a child of pmmc node.
> In early versions a phandle was used to point to pmmc and docs still
> incorrectly showed this.
>
> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 59 ++++++++++++++
> MAINTAINERS | 2 +
> include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++
> 3 files changed, 151 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> create mode 100644 include/dt-bindings/genpd/k2g.h
>
> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> new file mode 100644
> index 000000000000..4c9064e512cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> @@ -0,0 +1,59 @@
> +Texas Instruments TI-SCI Generic Power Domain
> +---------------------------------------------
> +
> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
> +responsible for controlling the state of the IPs that are present.
> +Communication between the host processor running an OS and the system
> +controller happens through a protocol known as TI-SCI [1]. This pm domain
> +implementation plugs into the generic pm domain framework and makes use of
> +the TI SCI protocol power on and off each device when needed.
> +
> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
> +PM Domain Node
> +==============
> +The PM domain node represents the global PM domain managed by the PMMC,
> +which in this case is the single implementation as documented by the generic
> +PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
> +Because this relies on the TI SCI protocol to communicate with the PMMC it
> +must be a child of the pmmc node.
> +
> +Required Properties:
> +--------------------
> +- compatible: should be "ti,sci-pm-domain"
> +- #power-domain-cells: Must be 0.
> +
> +Example (K2G):
> +-------------
> + pmmc: pmmc {
> + compatible = "ti,k2g-sci";
> + ...
> +
> + k2g_pds: k2g_pds {
> + compatible = "ti,sci-pm-domain";
> + #power-domain-cells = <0>;
> + };
> + };
> +
> +PM Domain Consumers
> +===================
> +Hardware blocks that require SCI control over their state must provide
> +a reference to the sci-pm-domain they are part of and a unique device
> +specific ID that identifies the device.
> +
> +Required Properties:
> +--------------------
> +- power-domains: phandle pointing to the corresponding PM domain node.
> +- ti,sci-id: index representing the device id to be passed oevr SCI to
> + be used for device control.
As I've already stated before, this goes in power-domain cells. When you
have a single thing (i.e. node) that controls multiple things, then you
you need to specify the ID for each of them in phandle args. This is how
irqs, gpio, clocks, *everything* in DT works.
Rob
^ permalink raw reply
* [PATCH] drm/exynos: constify exynos_drm_crtc_ops structures
From: Bhumika Goyal @ 2017-01-09 17:54 UTC (permalink / raw)
To: linux-arm-kernel
Declare exynos_drm_crtc_ops structures as const as they are only passed
as an argument to the function exynos_drm_crtc_create. This argument is
of type const struct exynos_drm_crtc_ops *, so exynos_drm_crtc_ops
structures having this property can be declared const.
Done using Coccinelle:
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct exynos_drm_crtc_ops i at p={...};
@ok@
position p;
identifier r.i;
@@
exynos_drm_crtc_create(...,&i at p,...)
@bad@
position p!={r.p,ok.p};
identifier r.i;
@@
i at p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
+const
struct exynos_drm_crtc_ops i;
File size before:
text data bss dec hex filename
5008 280 0 5288 14a8 exynos/exynos5433_drm_decon.o
File size after:
text data bss dec hex filename
5120 176 0 5296 14b0 exynos/exynos5433_drm_decon.o
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 6ca1f31..12b9bf0 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -470,7 +470,7 @@ static void decon_clear_channels(struct exynos_drm_crtc *crtc)
clk_disable_unprepare(ctx->clks[i]);
}
-static struct exynos_drm_crtc_ops decon_crtc_ops = {
+static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable = decon_enable,
.disable = decon_disable,
.enable_vblank = decon_enable_vblank,
--
1.9.1
^ permalink raw reply related
* APM smmu implementation
From: Robin Murphy @ 2017-01-09 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109120300.GC21398@arm.com>
On 09/01/17 12:03, Will Deacon wrote:
> On Mon, Jan 09, 2017 at 11:34:42AM +0000, Robin Murphy wrote:
>> On 06/01/17 23:21, Feng Kan wrote:
>>> The APM IOMMU implementation is mostly just the ARM SMMU 500 variant.
>>
>> "Mostly"? Have APM actually modified it (which I strongly doubt) or do
>> you mean it's simply been integrated with the upper address lines tied
>> off? MMU-500 reports a 48-bit IAS because MMU-500 has 48-bit-wide slave
>> interfaces; that's all there is to it. Whether or not you use all of
>> those bits is up to you as a system integrator.
>
> That's a good point; MMU-500 doesn't appear to let you change the IAS
> anyway. That should also mean that UBS and OAS are unchanged.
>
>>> However, our internal bus is only 42 bits wide. Our IAS field is coded
>>> as 48 bits, which cause IPA to truncated to 42 bits on the physical
>>> bus. In order for our system to work with the arm-smmu.c, there needs
>>> to be a way to force the ipa_size to 42. The current internal solution
>>> is to use the cpuid, but that is quite ugly. I was thinking of using
>>> the model
>>> as indication to right the ipa_size, but I am not too sure of the ACPI
>>> side. Would it be okay to add an APM MMU500 variant? I would also
>>> appreciated it if you guys have any alternate solutions.
>>
>> This is something we've been axpecting to run into for a while now - the
>> appropriate solution is to use a "dma-ranges" property on the master
>> device(s) to describe that they have 42 bits of address wired up, from
>> which they will then inherit the appropriate DMA mask. The outstanding
>> issue which remains is that we're still missing some way of preventing
>> drivers simply clobbering that with a 64-bit mask later, but that's a
>> more general problem[1].
>
> I wonder if the driver is actually using IAS, OAS and UBS incorrectly.
> We're using them to parameterise the DMA aperture, which is then used
> to size the IOVA domain, but that's wrong because the IAS, OAS and UBS
> are upper bounds and we can still end up allocating unusable/unreachable
> addresses.
It's not incorrect, it's simply all we know at that point. From inside
the SMMU, we can't tell how many of the bits we have are actually wired
up externally, which is why we always take the intersection of the DMA
aperture and the given device's DMA mask at the point of IOVA allocation.
You can reproduce much the same thing on your Juno if you fancy - just
make the HDLCD or PL330 driver set a DMA mask larger than the default 32
bits and the top 8 bits of the MMU-401's 40-bit input being tied off to
0 will become apparent (the only difference being there's not actually
anything at the master end they could be wired to either).
> So I do think that this should be fixed on the SMMU firmware node, rather
> than restricting the range of each master device.
In general, it's a per-master thing which "dma-ranges" is exactly the
correct tool to describe - a property on the SMMU would just be a weird
nonstandard shorthand for a very particular case (it breaks as soon as
you have some *more* limited, e.g. 32-bit, device in the same system).
The fact that every master in this case apparently has the same
capability is just happenstance.
Robin.
>
> Will
>
^ permalink raw reply
* [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains
From: Dave Gerlach @ 2017-01-09 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109175012.sg7eze7llqq7qevd@rob-hp-laptop>
Rob,
On 01/09/2017 11:50 AM, Rob Herring wrote:
> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>> Add a generic power domain implementation, TI SCI PM Domains, that
>> will hook into the genpd framework and allow the TI SCI protocol to
>> control device power states.
>>
>> Also, provide macros representing each device index as understood
>> by TI SCI to be used in the device node power-domain references.
>> These are identifiers for the K2G devices managed by the PMMC.
>>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>> ---
>> v2->v3:
>> Update k2g_pds node docs to show it should be a child of pmmc node.
>> In early versions a phandle was used to point to pmmc and docs still
>> incorrectly showed this.
>>
>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 59 ++++++++++++++
>> MAINTAINERS | 2 +
>> include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++
>> 3 files changed, 151 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>
>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>> new file mode 100644
>> index 000000000000..4c9064e512cb
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>> @@ -0,0 +1,59 @@
>> +Texas Instruments TI-SCI Generic Power Domain
>> +---------------------------------------------
>> +
>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
>> +responsible for controlling the state of the IPs that are present.
>> +Communication between the host processor running an OS and the system
>> +controller happens through a protocol known as TI-SCI [1]. This pm domain
>> +implementation plugs into the generic pm domain framework and makes use of
>> +the TI SCI protocol power on and off each device when needed.
>> +
>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>> +
>> +PM Domain Node
>> +==============
>> +The PM domain node represents the global PM domain managed by the PMMC,
>> +which in this case is the single implementation as documented by the generic
>> +PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
>> +Because this relies on the TI SCI protocol to communicate with the PMMC it
>> +must be a child of the pmmc node.
>> +
>> +Required Properties:
>> +--------------------
>> +- compatible: should be "ti,sci-pm-domain"
>> +- #power-domain-cells: Must be 0.
>> +
>> +Example (K2G):
>> +-------------
>> + pmmc: pmmc {
>> + compatible = "ti,k2g-sci";
>> + ...
>> +
>> + k2g_pds: k2g_pds {
>> + compatible = "ti,sci-pm-domain";
>> + #power-domain-cells = <0>;
>> + };
>> + };
>> +
>> +PM Domain Consumers
>> +===================
>> +Hardware blocks that require SCI control over their state must provide
>> +a reference to the sci-pm-domain they are part of and a unique device
>> +specific ID that identifies the device.
>> +
>> +Required Properties:
>> +--------------------
>> +- power-domains: phandle pointing to the corresponding PM domain node.
>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>> + be used for device control.
>
> As I've already stated before, this goes in power-domain cells. When you
> have a single thing (i.e. node) that controls multiple things, then you
> you need to specify the ID for each of them in phandle args. This is how
> irqs, gpio, clocks, *everything* in DT works.
You think the reasoning for doing it this way provided by both Ulf and
myself on v2 [1] is not valid then?
From Ulf:
To me, the TI SCI ID, is similar to a "conid" for any another "device
resource" (like clock, pinctrl, regulator etc) which we can describe
in DT and assign to a device node. The only difference here, is that
we don't have common API to fetch the resource (like clk_get(),
regulator_get()), but instead we fetches the device's resource from
SoC specific code, via genpd's device ->attach() callback.
From me:
Yes, you've pretty much hit it on the head. It is not an index into a
list of genpds but rather identifies the device *within* a single genpd.
It is a property specific to each device that resides in a ti-sci-genpd,
not a mapping describing which genpd the device belongs to. The generic
power domain binding is concerned with mapping the device to a specific
genpd, which is does fine for us, but we have a sub mapping for devices
that exist inside a genpd which, we must describe as well, hence the
ti,sci-id.
So to summarize, the genpd framework does interpret the phandle arg as
an index into multiple genpds, just as you've said other frameworks do,
but this is not what I am trying to do, we have multiple devices within
this *single* genpd, hence the need for the ti,sci-id property.
Regards,
Dave
[1] https://patchwork.kernel.org/patch/9385371/
>
> Rob
>
^ permalink raw reply
* [PATCH v7 1/8] MFD: add bindings for STM32 Timers driver
From: Rob Herring @ 2017-01-09 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483608344-9012-2-git-send-email-benjamin.gaignard@st.com>
On Thu, Jan 05, 2017 at 10:25:37AM +0100, Benjamin Gaignard wrote:
> Add bindings information for STM32 Timers
>
> version 6:
> - rename stm32-gtimer to stm32-timers
> - change compatible
> - add description about the IPs
>
> version 2:
> - rename stm32-mfd-timer to stm32-gptimer
> - only keep one compatible string
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../devicetree/bindings/mfd/stm32-timers.txt | 46 ++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v7 2/8] MFD: add STM32 Timers driver
From: Rob Herring @ 2017-01-09 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483608344-9012-3-git-send-email-benjamin.gaignard@st.com>
On Thu, Jan 05, 2017 at 10:25:38AM +0100, Benjamin Gaignard wrote:
> This hardware block could at used at same time for PWM generation
> and IIO timers.
> PWM and IIO timer configuration are mixed in the same registers
> so we need a multi fonction driver to be able to share those registers.
>
> version 7:
> - rebase on v4.10-rc2
>
> version 6:
> - rename files to stm32-timers
> - rename functions to stm32_timers_xxx
>
> version 5:
> - fix Lee comments about detect function
> - add missing dependency on REGMAP_MMIO
>
> version 4:
> - add a function to detect Auto Reload Register (ARR) size
> - rename the structure shared with other drivers
>
> version 2:
> - rename driver "stm32-gptimer" to be align with SoC documentation
> - only keep one compatible
> - use of_platform_populate() instead of devm_mfd_add_devices()
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../devicetree/bindings/mfd/stm32-timers.txt | 2 +-
> drivers/mfd/Kconfig | 11 +++
> drivers/mfd/Makefile | 2 +
> drivers/mfd/stm32-timers.c | 80 ++++++++++++++++++++++
> include/linux/mfd/stm32-timers.h | 71 +++++++++++++++++++
> 5 files changed, 165 insertions(+), 1 deletion(-)
> create mode 100644 drivers/mfd/stm32-timers.c
> create mode 100644 include/linux/mfd/stm32-timers.h
>
> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> index a73301d..897e7c2 100644
> --- a/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> +++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> @@ -12,7 +12,7 @@ Required parameters:
>
> - reg: Physical base address and length of the controller's
> registers.
> -- clock-names: Set to "int".
> +- clock-names: Set to "int".
This hunk should be dropped or moved to previous patch.
> - clocks: Phandle to the clock used by the timer module.
> For Clk properties, please refer to ../clock/clock-bindings.txt
>
^ permalink raw reply
* [PATCH v7 3/8] PWM: add pwm-stm32 DT bindings
From: Rob Herring @ 2017-01-09 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483608344-9012-4-git-send-email-benjamin.gaignard@st.com>
On Thu, Jan 05, 2017 at 10:25:39AM +0100, Benjamin Gaignard wrote:
> Define bindings for pwm-stm32
>
> version 6:
> - change st,breakinput parameter format to make it usuable on stm32f7 too.
>
> version 2:
> - use parameters instead of compatible of handle the hardware configuration
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v7 5/8] IIO: add bindings for STM32 timer trigger driver
From: Rob Herring @ 2017-01-09 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483608344-9012-6-git-send-email-benjamin.gaignard@st.com>
On Thu, Jan 05, 2017 at 10:25:41AM +0100, Benjamin Gaignard wrote:
> Define bindings for STM32 timer trigger
>
> version 4:
> - remove triggers enumeration from DT
> - add reg parameter
>
> version 3:
> - change file name
> - add cross reference with mfd bindings
>
> version 2:
> - only keep one compatible
> - add DT parameters to set lists of the triggers:
> one list describe the triggers created by the device
> another one give the triggers accepted by the device
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../bindings/iio/timer/stm32-timer-trigger.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt b/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
> new file mode 100644
> index 0000000..36a6c4a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
> @@ -0,0 +1,23 @@
> +STMicroelectronics STM32 Timers IIO timer bindings
> +
> +Must be a sub-node of an STM32 Timers device tree node.
> +See ../mfd/stm32-timers.txt for details about the parent node.
> +
> +Required parameters:
> +- compatible: Must be "st,stm32-timer-trigger".
> +- reg: Define triggers configuration of the hardware IP.
Valid values? Not sure this makes sense for use of reg. reg should be
how you address or id a device.
> +
> +Example:
> + timers at 40010000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + timer {
This would also need an unit address.
> + compatible = "st,stm32-timer-trigger";
> + reg = <0>;
> + };
> + };
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 0/4] ARM: exynos: Fix Odroid U3 USB/LAN when TFTP booting (power sequence)
From: Anand Moon @ 2017-01-09 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107085203.4431-1-krzk@kernel.org>
Hi Krzysztof,
On 7 January 2017 at 14:21, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> Hi,
>
> Thanks to Markus Reichl, I got an Odroid U3 to work with. Thanks to Peter
> Chen, we got a power sequence generic library which solves my long
> standing Odroid U3 problem - no LAN9730 if it was enabled by bootloader.
>
> My previous attempts for this can be found here [0].
>
> This patchset is based on Peter's v11 of power sequence [1].
> Patchset is available also on my Github [2].
>
> More detailed analysis is described in patch 2/4 ("ARM: dts: exynos: Fix
> LAN9730 on Odroid U3 after tftpboot").
>
>
[snip]
On which u-boot should this be tested.
On HK u-boot tftp boot is not supported.
----------------------------------------------------------
U-Boot 2010.12-00000-g9777ca6-dirty (Nov 26 2015 - 10:10:11) for Exynox4412
CPU: S5PC220 [Samsung SOC on SMP Platform Base on ARM CortexA9]
APLL = 1000MHz, MPLL = 800MHz
DRAM: 2 GiB
PMIC VERSION : 0x00, CHIP REV : 2
TrustZone Enabled BSP
BL1 version: 20121128
Checking Boot Mode ... SDMMC
MMC Device 0: 14804 MB
MMC Device 1 not found
*** Warning - using default environment
USB3503 NINT = OUTPUT LOW!
ModeKey Check... run normal_boot
No ethernet found.
Hit any key to stop autoboot: 0
Exynos4412 #
Exynos4412 #
Exynos4412 #
Exynos4412 # usb start
(Re)start USB...
USB0: Exynos4412-ehci: init hccr 12580000 and hcor 12580010 hc_length 16
usb: usb_refclk_enable is active low: NO
ProTIP: If usb doesn't work - try playing with 'usb_invert_clken' environment
USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
EHCI fail timeout STS_ASS set
USB device not accepting new address (error=80000000)
EHCI fail timeout STS_ASS set
1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
Exynos4412 #
Best Regards
-Anand
^ permalink raw reply
* Unhandled level 2 translation fault (11) at 0x000000b8, esr 0x92000046, rpi3 (aarch64)
From: Bas van Tiel @ 2017-01-09 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109151354.GC7593@e104818-lin.cambridge.arm.com>
> I defined STACKSIZE to the kernel's SIGSTKSZ (16384) and it seems to run
> fine, though I'll leave it longer/overnight (on a Juno board). With the
> 4K signal stack it was crashing shortly after start.
I tried the STACKSIZE of 16384 for both the RPI3 and the PINEA64 board
and still see the same behaviour of crashing. Sometimes the process
is also blocked for a long time before it crashes.
Setting the interval to 200 usec [5 Khz] will help to crash it faster.
To further isolate the issue I will create a kernel module (based on a
hrtimer) that will sent a periodic signal to the registered process
and execute the same sighandler logic to check if the problem is still
there.
regards
Bas
^ permalink raw reply
* [PATCH v2 3/4] dmaengine: pl330: Store pointer to slave device
From: Krzysztof Kozlowski @ 2017-01-09 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483970598-6191-4-git-send-email-m.szyprowski@samsung.com>
On Mon, Jan 9, 2017 at 4:03 PM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> Store the pointer to slave device, which requested our channel. It will be
> later used to implement runtime PM of PL330 DMA controller. Although
> DMA channels might be requested many times, each DMA peripheral channel is
> physically dedicated only for specific hardware, so there should be only
> one slave device for each channel.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/dma/pl330.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 3c80e71271a2..9c72f535739c 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -450,6 +450,7 @@ struct dma_pl330_chan {
>
> /* for runtime pm tracking */
> bool active;
> + struct device *slave;
> };
>
> struct pl330_dmac {
> @@ -2113,6 +2114,14 @@ static struct dma_chan *of_dma_pl330_xlate(struct of_phandle_args *dma_spec,
> if (chan_id >= pl330->num_peripherals)
> return NULL;
>
> + if (!pl330->peripherals[chan_id].slave)
> + pl330->peripherals[chan_id].slave = slave;
Following coding style, this should be inside {} because the other
branch has them. Beside that:
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
> + else if (pl330->peripherals[chan_id].slave != slave) {
> + dev_err(pl330->ddma.dev,
> + "Can't use same channel with multiple slave devices!\n");
> + return NULL;
> + }
> +
> return dma_get_slave_channel(&pl330->peripherals[chan_id].chan);
> }
>
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] arm64: Remove useless UAO IPI and describe how this gets enabled
From: James Morse @ 2017-01-09 18:14 UTC (permalink / raw)
To: linux-arm-kernel
Since its introduction, the UAO enable call was broken, and useless.
commit 2a6dcb2b5f3e ("arm64: cpufeature: Schedule enable() calls instead
of calling them via IPI"), fixed the framework so that these calls
are scheduled, so that they can modify PSTATE.
Now it is just useless. Remove it. UAO is enabled by the code patching
which causes get_user() and friends to use the 'ldtr' family of
instructions. This relies on the PSTATE.UAO bit being set to match
addr_limit, which we do in uao_thread_switch() called via __switch_to().
All that is needed to enable UAO is patch the code, and call schedule().
__apply_alternatives_multi_stop() calls stop_machine() when it modifies
the kernel text to enable the alternatives, (including the UAO code in
uao_thread_switch()). Once stop_machine() has finished __switch_to() is
called to reschedule the original task, this causes PSTATE.UAO to be set
appropriately. An explicit enable() call is not needed.
Reported-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
==
Sorry, I forgot about this cleanup after the last round of PAN fixes.
---
arch/arm64/include/asm/processor.h | 1 -
arch/arm64/kernel/cpufeature.c | 5 ++++-
arch/arm64/mm/fault.c | 14 --------------
3 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 60e34824e18c..b1bb3bc4f215 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -189,7 +189,6 @@ static inline void spin_lock_prefetch(const void *ptr)
#endif
int cpu_enable_pan(void *__unused);
-int cpu_enable_uao(void *__unused);
int cpu_enable_cache_maint_trap(void *__unused);
#endif /* __ASM_PROCESSOR_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c02504ea304b..584bd74e0cc1 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -797,7 +797,10 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
.sys_reg = SYS_ID_AA64MMFR2_EL1,
.field_pos = ID_AA64MMFR2_UAO_SHIFT,
.min_field_value = 1,
- .enable = cpu_enable_uao,
+ /*
+ * We rely on stop_machine() calling uao_thread_switch() to set
+ * UAO immediately after patching.
+ */
},
#endif /* CONFIG_ARM64_UAO */
#ifdef CONFIG_ARM64_PAN
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 0f8788374815..e9fd27daa0d1 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -685,17 +685,3 @@ int cpu_enable_pan(void *__unused)
return 0;
}
#endif /* CONFIG_ARM64_PAN */
-
-#ifdef CONFIG_ARM64_UAO
-/*
- * Kernel threads have fs=KERNEL_DS by default, and don't need to call
- * set_fs(), devtmpfs in particular relies on this behaviour.
- * We need to enable the feature at runtime (instead of adding it to
- * PSR_MODE_EL1h) as the feature may not be implemented by the cpu.
- */
-int cpu_enable_uao(void *__unused)
-{
- asm(SET_PSTATE_UAO(1));
- return 0;
-}
-#endif /* CONFIG_ARM64_UAO */
--
2.10.1
^ permalink raw reply related
* [PATCH v2 1/4] dmaengine: pl330: remove pdata based initialization
From: Krzysztof Kozlowski @ 2017-01-09 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483970598-6191-2-git-send-email-m.szyprowski@samsung.com>
On Mon, Jan 09, 2017 at 03:03:15PM +0100, Marek Szyprowski wrote:
> This driver is now used only on platforms which support device tree, so
> it is safe to remove legacy platform data based initialization code.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/dma/pl330.c | 30 ++++++++----------------------
> include/linux/amba/pl330.h | 35 -----------------------------------
Nope:
$ git grep pl330.h
arch/arm/plat-samsung/devs.c:#include <linux/amba/pl330.h>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 0/4] ARM: exynos: Fix Odroid U3 USB/LAN when TFTP booting (power sequence)
From: Krzysztof Kozlowski @ 2017-01-09 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANAwSgSEZvxHje65Kk13fvD9NZGB+iHCJtoGJdQrUdS42ei_WA@mail.gmail.com>
On Mon, Jan 09, 2017 at 11:34:48PM +0530, Anand Moon wrote:
> Hi Krzysztof,
>
> On 7 January 2017 at 14:21, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > Hi,
> >
> > Thanks to Markus Reichl, I got an Odroid U3 to work with. Thanks to Peter
> > Chen, we got a power sequence generic library which solves my long
> > standing Odroid U3 problem - no LAN9730 if it was enabled by bootloader.
> >
> > My previous attempts for this can be found here [0].
> >
> > This patchset is based on Peter's v11 of power sequence [1].
> > Patchset is available also on my Github [2].
> >
> > More detailed analysis is described in patch 2/4 ("ARM: dts: exynos: Fix
> > LAN9730 on Odroid U3 after tftpboot").
> >
> >
>
> [snip]
>
> On which u-boot should this be tested.
>
> On HK u-boot tftp boot is not supported.
... so you gave an answer: you cannot test it on HK. How many other
U-Boot flavors you know? :)
Best regards,
Krzysztof
> ----------------------------------------------------------
> U-Boot 2010.12-00000-g9777ca6-dirty (Nov 26 2015 - 10:10:11) for Exynox4412
>
>
> CPU: S5PC220 [Samsung SOC on SMP Platform Base on ARM CortexA9]
> APLL = 1000MHz, MPLL = 800MHz
> DRAM: 2 GiB
>
> PMIC VERSION : 0x00, CHIP REV : 2
> TrustZone Enabled BSP
> BL1 version: 20121128
>
>
> Checking Boot Mode ... SDMMC
> MMC Device 0: 14804 MB
> MMC Device 1 not found
> *** Warning - using default environment
>
> USB3503 NINT = OUTPUT LOW!
> ModeKey Check... run normal_boot
> No ethernet found.
> Hit any key to stop autoboot: 0
> Exynos4412 #
> Exynos4412 #
> Exynos4412 #
> Exynos4412 # usb start
> (Re)start USB...
> USB0: Exynos4412-ehci: init hccr 12580000 and hcor 12580010 hc_length 16
> usb: usb_refclk_enable is active low: NO
> ProTIP: If usb doesn't work - try playing with 'usb_invert_clken' environment
> USB EHCI 1.00
> scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
> EHCI fail timeout STS_ASS set
>
> USB device not accepting new address (error=80000000)
> EHCI fail timeout STS_ASS set
> 1 USB Device(s) found
> scanning usb for storage devices... 0 Storage Device(s) found
> scanning usb for ethernet devices... 0 Ethernet Device(s) found
> Exynos4412 #
>
> Best Regards
> -Anand
^ permalink raw reply
* [PATCH v2 11/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes
From: Cyrille Pitchen @ 2017-01-09 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1548507.knvAQkH9bK@tauon.atsec.com>
Hi Stephan,
Le 23/12/2016 ? 12:34, Stephan M?ller a ?crit :
> Am Donnerstag, 22. Dezember 2016, 17:38:00 CET schrieb Cyrille Pitchen:
>
> Hi Cyrille,
>
>> This patchs allows to combine the AES and SHA hardware accelerators on
>> some Atmel SoCs. Doing so, AES blocks are only written to/read from the
>> AES hardware. Those blocks are also transferred from the AES to the SHA
>> accelerator internally, without additionnal accesses to the system busses.
>>
>> Hence, the AES and SHA accelerators work in parallel to process all the
>> data blocks, instead of serializing the process by (de)crypting those
>> blocks first then authenticating them after like the generic
>> crypto/authenc.c driver does.
>>
>> Of course, both the AES and SHA hardware accelerators need to be available
>> before we can start to process the data blocks. Hence we use their crypto
>> request queue to synchronize both drivers.
>>
>> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
>> ---
>> drivers/crypto/Kconfig | 12 +
>> drivers/crypto/atmel-aes-regs.h | 16 ++
>> drivers/crypto/atmel-aes.c | 471
>> +++++++++++++++++++++++++++++++++++++++- drivers/crypto/atmel-authenc.h |
>> 64 ++++++
>> drivers/crypto/atmel-sha-regs.h | 14 ++
>> drivers/crypto/atmel-sha.c | 344 +++++++++++++++++++++++++++--
>> 6 files changed, 906 insertions(+), 15 deletions(-)
>> create mode 100644 drivers/crypto/atmel-authenc.h
>>
>> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
>> index 79564785ae30..719a868d8ea1 100644
>> --- a/drivers/crypto/Kconfig
>> +++ b/drivers/crypto/Kconfig
>> @@ -415,6 +415,18 @@ config CRYPTO_DEV_BFIN_CRC
>> Newer Blackfin processors have CRC hardware. Select this if you
>> want to use the Blackfin CRC module.
>>
>> +config CRYPTO_DEV_ATMEL_AUTHENC
>> + tristate "Support for Atmel IPSEC/SSL hw accelerator"
>> + depends on (ARCH_AT91 && HAS_DMA) || COMPILE_TEST
>> + select CRYPTO_AUTHENC
>> + select CRYPTO_DEV_ATMEL_AES
>> + select CRYPTO_DEV_ATMEL_SHA
>> + help
>> + Some Atmel processors can combine the AES and SHA hw accelerators
>> + to enhance support of IPSEC/SSL.
>> + Select this if you want to use the Atmel modules for
>> + authenc(hmac(shaX),Y(cbc)) algorithms.
>> +
>> config CRYPTO_DEV_ATMEL_AES
>> tristate "Support for Atmel AES hw accelerator"
>> depends on HAS_DMA
>> diff --git a/drivers/crypto/atmel-aes-regs.h
>> b/drivers/crypto/atmel-aes-regs.h index 0ec04407b533..7694679802b3 100644
>> --- a/drivers/crypto/atmel-aes-regs.h
>> +++ b/drivers/crypto/atmel-aes-regs.h
>> @@ -68,6 +68,22 @@
>> #define AES_CTRR 0x98
>> #define AES_GCMHR(x) (0x9c + ((x) * 0x04))
>>
>> +#define AES_EMR 0xb0
>> +#define AES_EMR_APEN BIT(0) /* Auto Padding Enable */
>> +#define AES_EMR_APM BIT(1) /* Auto Padding Mode */
>> +#define AES_EMR_APM_IPSEC 0x0
>> +#define AES_EMR_APM_SSL BIT(1)
>> +#define AES_EMR_PLIPEN BIT(4) /* PLIP Enable */
>> +#define AES_EMR_PLIPD BIT(5) /* PLIP Decipher */
>> +#define AES_EMR_PADLEN_MASK (0xFu << 8)
>> +#define AES_EMR_PADLEN_OFFSET 8
>> +#define AES_EMR_PADLEN(padlen) (((padlen) << AES_EMR_PADLEN_OFFSET) &\
>> + AES_EMR_PADLEN_MASK)
>> +#define AES_EMR_NHEAD_MASK (0xFu << 16)
>> +#define AES_EMR_NHEAD_OFFSET 16
>> +#define AES_EMR_NHEAD(nhead) (((nhead) << AES_EMR_NHEAD_OFFSET) &\
>> + AES_EMR_NHEAD_MASK)
>> +
>> #define AES_TWR(x) (0xc0 + ((x) * 0x04))
>> #define AES_ALPHAR(x) (0xd0 + ((x) * 0x04))
>>
>> diff --git a/drivers/crypto/atmel-aes.c b/drivers/crypto/atmel-aes.c
>> index 9fd2f63b8bc0..3c651e0c3113 100644
>> --- a/drivers/crypto/atmel-aes.c
>> +++ b/drivers/crypto/atmel-aes.c
>> @@ -41,6 +41,7 @@
>> #include <linux/platform_data/crypto-atmel.h>
>> #include <dt-bindings/dma/at91.h>
>> #include "atmel-aes-regs.h"
>> +#include "atmel-authenc.h"
>>
>> #define ATMEL_AES_PRIORITY 300
>>
>> @@ -78,6 +79,7 @@
>> #define AES_FLAGS_INIT BIT(2)
>> #define AES_FLAGS_BUSY BIT(3)
>> #define AES_FLAGS_DUMP_REG BIT(4)
>> +#define AES_FLAGS_OWN_SHA BIT(5)
>>
>> #define AES_FLAGS_PERSISTENT (AES_FLAGS_INIT | AES_FLAGS_BUSY)
>>
>> @@ -92,6 +94,7 @@ struct atmel_aes_caps {
>> bool has_ctr32;
>> bool has_gcm;
>> bool has_xts;
>> + bool has_authenc;
>> u32 max_burst_size;
>> };
>>
>> @@ -144,10 +147,31 @@ struct atmel_aes_xts_ctx {
>> u32 key2[AES_KEYSIZE_256 / sizeof(u32)];
>> };
>>
>> +#ifdef CONFIG_CRYPTO_DEV_ATMEL_AUTHENC
>> +struct atmel_aes_authenc_ctx {
>> + struct atmel_aes_base_ctx base;
>> + struct atmel_sha_authenc_ctx *auth;
>> +};
>> +#endif
>> +
>> struct atmel_aes_reqctx {
>> unsigned long mode;
>> };
>>
>> +#ifdef CONFIG_CRYPTO_DEV_ATMEL_AUTHENC
>> +struct atmel_aes_authenc_reqctx {
>> + struct atmel_aes_reqctx base;
>> +
>> + struct scatterlist src[2];
>> + struct scatterlist dst[2];
>> + size_t textlen;
>> + u32 digest[SHA512_DIGEST_SIZE / sizeof(u32)];
>> +
>> + /* auth_req MUST be place last. */
>> + struct ahash_request auth_req;
>> +};
>> +#endif
>> +
>> struct atmel_aes_dma {
>> struct dma_chan *chan;
>> struct scatterlist *sg;
>> @@ -291,6 +315,9 @@ static const char *atmel_aes_reg_name(u32 offset, char
>> *tmp, size_t sz) snprintf(tmp, sz, "GCMHR[%u]", (offset - AES_GCMHR(0)) >>
>> 2);
>> break;
>>
>> + case AES_EMR:
>> + return "EMR";
>> +
>> case AES_TWR(0):
>> case AES_TWR(1):
>> case AES_TWR(2):
>> @@ -463,8 +490,16 @@ static inline bool atmel_aes_is_encrypt(const struct
>> atmel_aes_dev *dd) return (dd->flags & AES_FLAGS_ENCRYPT);
>> }
>>
>> +#ifdef CONFIG_CRYPTO_DEV_ATMEL_AUTHENC
>> +static void atmel_aes_authenc_complete(struct atmel_aes_dev *dd, int err);
>> +#endif
>> +
>> static inline int atmel_aes_complete(struct atmel_aes_dev *dd, int err)
>> {
>> +#ifdef CONFIG_CRYPTO_DEV_ATMEL_AUTHENC
>> + atmel_aes_authenc_complete(dd, err);
>> +#endif
>> +
>> clk_disable(dd->iclk);
>> dd->flags &= ~AES_FLAGS_BUSY;
>>
>> @@ -1931,6 +1966,407 @@ static struct crypto_alg aes_xts_alg = {
>> }
>> };
>>
>> +#ifdef CONFIG_CRYPTO_DEV_ATMEL_AUTHENC
>> +/* authenc aead functions */
>> +
>> +static int atmel_aes_authenc_start(struct atmel_aes_dev *dd);
>> +static int atmel_aes_authenc_init(struct atmel_aes_dev *dd, int err,
>> + bool is_async);
>> +static int atmel_aes_authenc_transfer(struct atmel_aes_dev *dd, int err,
>> + bool is_async);
>> +static int atmel_aes_authenc_digest(struct atmel_aes_dev *dd);
>> +static int atmel_aes_authenc_final(struct atmel_aes_dev *dd, int err,
>> + bool is_async);
>> +
>> +static void atmel_aes_authenc_complete(struct atmel_aes_dev *dd, int err)
>> +{
>> + struct aead_request *req = aead_request_cast(dd->areq);
>> + struct atmel_aes_authenc_reqctx *rctx = aead_request_ctx(req);
>> +
>> + if (err && (dd->flags & AES_FLAGS_OWN_SHA))
>> + atmel_sha_authenc_abort(&rctx->auth_req);
>> + dd->flags &= ~AES_FLAGS_OWN_SHA;
>> +}
>> +
>> +static int atmel_aes_authenc_copy_assoc(struct aead_request *req)
>> +{
>> + size_t buflen, assoclen = req->assoclen;
>> + off_t skip = 0;
>> + u8 buf[256];
>> +
>> + while (assoclen) {
>> + buflen = min_t(size_t, assoclen, sizeof(buf));
>> +
>> + if (sg_pcopy_to_buffer(req->src, sg_nents(req->src),
>> + buf, buflen, skip) != buflen)
>> + return -EINVAL;
>> +
>> + if (sg_pcopy_from_buffer(req->dst, sg_nents(req->dst),
>> + buf, buflen, skip) != buflen)
>> + return -EINVAL;
>> +
>> + skip += buflen;
>> + assoclen -= buflen;
>> + }
>
> This seems to be a very expansive operation. Wouldn't it be easier, leaner and
> with one less memcpy to use the approach of crypto_authenc_copy_assoc?
>
> Instead of copying crypto_authenc_copy_assoc, what about carving the logic in
> crypto/authenc.c out into a generic aead helper code as we need to add that to
> other AEAD implementations?
Before writing this function, I checked how the crypto/authenc.c driver
handles the copy of the associated data, hence crypto_authenc_copy_assoc().
I have to admit I didn't perform any benchmark to compare the two
implementation but I just tried to understand how
crypto_authenc_copy_assoc() works. At the first look, this function seems
very simple but I guess all the black magic is hidden by the call of
crypto_skcipher_encrypt() on the default null transform, which is
implemented using the ecb(cipher_null) algorithm.
When I wrote my function I thought that this ecb(cipher_null) algorithm was
implemented by combining crypto_ecb_crypt() from crypto/ecb.c with
null_crypt() from crypto/crypto_null.c. Hence I thought there would be much
function call overhead to copy only few bytes but now checking again I
realize that the ecb(cipher_null) algorithm is directly implemented by
skcipher_null_crypt() still from crypto/crypto_null.c. So yes, maybe you're
right: it could be better to reuse what was done in
crypto_authenc_copy_assoc() from crypto/authenc.c.
This way we could need twice less memcpy() hence I agree with you.
>> +
>> + return 0;
>> +}
>> +
>> +static int atmel_aes_authenc_start(struct atmel_aes_dev *dd)
>> +{
>> + struct aead_request *req = aead_request_cast(dd->areq);
>> + struct atmel_aes_authenc_reqctx *rctx = aead_request_ctx(req);
>> + struct crypto_aead *tfm = crypto_aead_reqtfm(req);
>> + struct atmel_aes_authenc_ctx *ctx = crypto_aead_ctx(tfm);
>> + int err;
>> +
>> + atmel_aes_set_mode(dd, &rctx->base);
>> +
>> + err = atmel_aes_hw_init(dd);
>> + if (err)
>> + return atmel_aes_complete(dd, err);
>> +
>> + return atmel_sha_authenc_schedule(&rctx->auth_req, ctx->auth,
>> + atmel_aes_authenc_init, dd);
>> +}
>> +
>> +static int atmel_aes_authenc_init(struct atmel_aes_dev *dd, int err,
>> + bool is_async)
>> +{
>> + struct aead_request *req = aead_request_cast(dd->areq);
>> + struct atmel_aes_authenc_reqctx *rctx = aead_request_ctx(req);
>> +
>> + if (is_async)
>> + dd->is_async = true;
>> + if (err)
>> + return atmel_aes_complete(dd, err);
>> +
>> + /* If here, we've got the ownership of the SHA device. */
>> + dd->flags |= AES_FLAGS_OWN_SHA;
>> +
>> + /* Configure the SHA device. */
>> + return atmel_sha_authenc_init(&rctx->auth_req,
>> + req->src, req->assoclen,
>> + rctx->textlen,
>> + atmel_aes_authenc_transfer, dd);
>> +}
>> +
>> +static int atmel_aes_authenc_transfer(struct atmel_aes_dev *dd, int err,
>> + bool is_async)
>> +{
>> + struct aead_request *req = aead_request_cast(dd->areq);
>> + struct atmel_aes_authenc_reqctx *rctx = aead_request_ctx(req);
>> + bool enc = atmel_aes_is_encrypt(dd);
>> + struct scatterlist *src, *dst;
>> + u32 iv[AES_BLOCK_SIZE / sizeof(u32)];
>> + u32 emr;
>> +
>> + if (is_async)
>> + dd->is_async = true;
>> + if (err)
>> + return atmel_aes_complete(dd, err);
>> +
>> + /* Prepare src and dst scatter-lists to transfer cipher/plain texts. */
>> + src = scatterwalk_ffwd(rctx->src, req->src, req->assoclen);
>> + dst = src;
>> +
>> + if (req->src != req->dst) {
>> + err = atmel_aes_authenc_copy_assoc(req);
>> + if (err)
>> + return atmel_aes_complete(dd, err);
>> +
>> + dst = scatterwalk_ffwd(rctx->dst, req->dst, req->assoclen);
>> + }
>> +
>> + /* Configure the AES device. */
>> + memcpy(iv, req->iv, sizeof(iv));
>> +
>> + /*
>> + * Here we always set the 2nd parameter of atmel_aes_write_ctrl() to
>> + * 'true' even if the data transfer is actually performed by the CPU (so
>> + * not by the DMA) because we must force the AES_MR_SMOD bitfield to the
>> + * value AES_MR_SMOD_IDATAR0. Indeed, both AES_MR_SMOD and SHA_MR_SMOD
>> + * must be set to *_MR_SMOD_IDATAR0.
>> + */
>> + atmel_aes_write_ctrl(dd, true, iv);
>> + emr = AES_EMR_PLIPEN;
>> + if (!enc)
>> + emr |= AES_EMR_PLIPD;
>> + atmel_aes_write(dd, AES_EMR, emr);
>> +
>> + /* Transfer data. */
>> + return atmel_aes_dma_start(dd, src, dst, rctx->textlen,
>> + atmel_aes_authenc_digest);
>> +}
>> +
>> +static int atmel_aes_authenc_digest(struct atmel_aes_dev *dd)
>> +{
>> + struct aead_request *req = aead_request_cast(dd->areq);
>> + struct atmel_aes_authenc_reqctx *rctx = aead_request_ctx(req);
>> +
>> + /* atmel_sha_authenc_final() releases the SHA device. */
>> + dd->flags &= ~AES_FLAGS_OWN_SHA;
>> + return atmel_sha_authenc_final(&rctx->auth_req,
>> + rctx->digest, sizeof(rctx->digest),
>> + atmel_aes_authenc_final, dd);
>> +}
>> +
>> +static int atmel_aes_authenc_final(struct atmel_aes_dev *dd, int err,
>> + bool is_async)
>> +{
>> + struct aead_request *req = aead_request_cast(dd->areq);
>> + struct atmel_aes_authenc_reqctx *rctx = aead_request_ctx(req);
>> + struct crypto_aead *tfm = crypto_aead_reqtfm(req);
>> + bool enc = atmel_aes_is_encrypt(dd);
>> + u32 idigest[SHA512_DIGEST_SIZE / sizeof(u32)], *odigest = rctx->digest;
>> + u32 offs, authsize;
>> +
>> + if (is_async)
>> + dd->is_async = true;
>> + if (err)
>> + goto complete;
>> +
>> + offs = req->assoclen + rctx->textlen;
>> + authsize = crypto_aead_authsize(tfm);
>> + if (enc) {
>> + scatterwalk_map_and_copy(odigest, req->dst, offs, authsize, 1);
>> + } else {
>> + scatterwalk_map_and_copy(idigest, req->src, offs, authsize, 0);
>> + if (crypto_memneq(idigest, odigest, authsize))
>> + err = -EBADMSG;
>> + }
>> +
>> +complete:
>> + return atmel_aes_complete(dd, err);
>> +}
>> +
>> +static int atmel_aes_authenc_setkey(struct crypto_aead *tfm, const u8 *key,
>> + unsigned int keylen)
>> +{
>> + struct atmel_aes_authenc_ctx *ctx = crypto_aead_ctx(tfm);
>> + struct crypto_authenc_keys keys;
>> + u32 flags;
>> + int err;
>> +
>> + if (crypto_authenc_extractkeys(&keys, key, keylen) != 0)
>> + goto badkey;
>> +
>> + if (keys.enckeylen > sizeof(ctx->base.key))
>> + goto badkey;
>> +
>> + /* Save auth key. */
>> + flags = crypto_aead_get_flags(tfm);
>> + err = atmel_sha_authenc_setkey(ctx->auth,
>> + keys.authkey, keys.authkeylen,
>> + &flags);
>> + crypto_aead_set_flags(tfm, flags & CRYPTO_TFM_RES_MASK);
>> + if (err)
>> + return err;
>> +
>> + /* Save enc key. */
>> + ctx->base.keylen = keys.enckeylen;
>> + memcpy(ctx->base.key, keys.enckey, keys.enckeylen);
>
> memzero_explicit(keys) please
good point :)
>> +
>> + return 0;
>> +
>> +badkey:
>> + crypto_aead_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
>> + return -EINVAL;
>> +}
>> +
>> +static int atmel_aes_authenc_init_tfm(struct crypto_aead *tfm,
>> + unsigned long auth_mode)
>> +{
>> + struct atmel_aes_authenc_ctx *ctx = crypto_aead_ctx(tfm);
>> + unsigned int auth_reqsize = atmel_sha_authenc_get_reqsize();
>> +
>> + ctx->auth = atmel_sha_authenc_spawn(auth_mode);
>> + if (IS_ERR(ctx->auth))
>> + return PTR_ERR(ctx->auth);
>> +
>> + crypto_aead_set_reqsize(tfm, (sizeof(struct atmel_aes_authenc_reqctx) +
>> + auth_reqsize));
>> + ctx->base.start = atmel_aes_authenc_start;
>> +
>> + return 0;
>> +}
>> +
>> +static int atmel_aes_authenc_hmac_sha1_init_tfm(struct crypto_aead *tfm)
>> +{
>> + return atmel_aes_authenc_init_tfm(tfm, SHA_FLAGS_HMAC_SHA1);
>> +}
>> +
>> +static int atmel_aes_authenc_hmac_sha224_init_tfm(struct crypto_aead *tfm)
>> +{
>> + return atmel_aes_authenc_init_tfm(tfm, SHA_FLAGS_HMAC_SHA224);
>> +}
>> +
>> +static int atmel_aes_authenc_hmac_sha256_init_tfm(struct crypto_aead *tfm)
>> +{
>> + return atmel_aes_authenc_init_tfm(tfm, SHA_FLAGS_HMAC_SHA256);
>> +}
>> +
>> +static int atmel_aes_authenc_hmac_sha384_init_tfm(struct crypto_aead *tfm)
>> +{
>> + return atmel_aes_authenc_init_tfm(tfm, SHA_FLAGS_HMAC_SHA384);
>> +}
>> +
>> +static int atmel_aes_authenc_hmac_sha512_init_tfm(struct crypto_aead *tfm)
>> +{
>> + return atmel_aes_authenc_init_tfm(tfm, SHA_FLAGS_HMAC_SHA512);
>> +}
>> +
>> +static void atmel_aes_authenc_exit_tfm(struct crypto_aead *tfm)
>> +{
>> + struct atmel_aes_authenc_ctx *ctx = crypto_aead_ctx(tfm);
>> +
>> + atmel_sha_authenc_free(ctx->auth);
>> +}
>> +
>> +static int atmel_aes_authenc_crypt(struct aead_request *req,
>> + unsigned long mode)
>> +{
>> + struct atmel_aes_authenc_reqctx *rctx = aead_request_ctx(req);
>> + struct crypto_aead *tfm = crypto_aead_reqtfm(req);
>> + struct atmel_aes_base_ctx *ctx = crypto_aead_ctx(tfm);
>> + u32 authsize = crypto_aead_authsize(tfm);
>> + bool enc = (mode & AES_FLAGS_ENCRYPT);
>> + struct atmel_aes_dev *dd;
>> +
>> + /* Compute text length. */
>> + rctx->textlen = req->cryptlen - (enc ? 0 : authsize);
>
> Is there somewhere a check that authsize is always < req->cryptlen (at least
> it escaped me)? Note, this logic will be exposed to user space which may do
> funky things.
I thought those 2 sizes were always set by the kernel only but I admit I
didn't check my assumption. If you tell me they could be set directly from
the userspace, yes I agree with you, I need to add a test.
>> +
>> + /*
>> + * Currently, empty messages are not supported yet:
>> + * the SHA auto-padding can be used only on non-empty messages.
>> + * Hence a special case needs to be implemented for empty message.
>> + */
>> + if (!rctx->textlen && !req->assoclen)
>> + return -EINVAL;
>> +
>> + rctx->base.mode = mode;
>> + ctx->block_size = AES_BLOCK_SIZE;
>> +
>> + dd = atmel_aes_find_dev(ctx);
>> + if (!dd)
>> + return -ENODEV;
>> +
>> + return atmel_aes_handle_queue(dd, &req->base);
>
> Ciao
> Stephan
>
thanks for your review! :)
Best regards,
Cyrille
^ permalink raw reply
* [PATCH 0/4] ARM: exynos: Fix Odroid U3 USB/LAN when TFTP booting (power sequence)
From: Anand Moon @ 2017-01-09 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109181703.436gv7bq76xuv35q@kozik-lap>
Hi Krzysztof,
On 9 January 2017 at 23:47, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Mon, Jan 09, 2017 at 11:34:48PM +0530, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 7 January 2017 at 14:21, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> > Hi,
>> >
>> > Thanks to Markus Reichl, I got an Odroid U3 to work with. Thanks to Peter
>> > Chen, we got a power sequence generic library which solves my long
>> > standing Odroid U3 problem - no LAN9730 if it was enabled by bootloader.
>> >
>> > My previous attempts for this can be found here [0].
>> >
>> > This patchset is based on Peter's v11 of power sequence [1].
>> > Patchset is available also on my Github [2].
>> >
>> > More detailed analysis is described in patch 2/4 ("ARM: dts: exynos: Fix
>> > LAN9730 on Odroid U3 after tftpboot").
>> >
>> >
>>
>> [snip]
>>
>> On which u-boot should this be tested.
>>
>> On HK u-boot tftp boot is not supported.
>
> ... so you gave an answer: you cannot test it on HK. How many other
> U-Boot flavors you know? :)
>
u-boot mainline have tftp support enable, so I will try to test on this u-boot.
Best Regards
-Anand
> Best regards,
> Krzysztof
>
>
>> ----------------------------------------------------------
>> U-Boot 2010.12-00000-g9777ca6-dirty (Nov 26 2015 - 10:10:11) for Exynox4412
>>
>>
>> CPU: S5PC220 [Samsung SOC on SMP Platform Base on ARM CortexA9]
>> APLL = 1000MHz, MPLL = 800MHz
>> DRAM: 2 GiB
>>
>> PMIC VERSION : 0x00, CHIP REV : 2
>> TrustZone Enabled BSP
>> BL1 version: 20121128
>>
>>
>> Checking Boot Mode ... SDMMC
>> MMC Device 0: 14804 MB
>> MMC Device 1 not found
>> *** Warning - using default environment
>>
>> USB3503 NINT = OUTPUT LOW!
>> ModeKey Check... run normal_boot
>> No ethernet found.
>> Hit any key to stop autoboot: 0
>> Exynos4412 #
>> Exynos4412 #
>> Exynos4412 #
>> Exynos4412 # usb start
>> (Re)start USB...
>> USB0: Exynos4412-ehci: init hccr 12580000 and hcor 12580010 hc_length 16
>> usb: usb_refclk_enable is active low: NO
>> ProTIP: If usb doesn't work - try playing with 'usb_invert_clken' environment
>> USB EHCI 1.00
>> scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
>> EHCI fail timeout STS_ASS set
>>
>> USB device not accepting new address (error=80000000)
>> EHCI fail timeout STS_ASS set
>> 1 USB Device(s) found
>> scanning usb for storage devices... 0 Storage Device(s) found
>> scanning usb for ethernet devices... 0 Ethernet Device(s) found
>> Exynos4412 #
>>
>> Best Regards
>> -Anand
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox