* [PATCH V15 04/11] efi: parse ARM processor error
From: Tyler Baicar @ 2017-04-18 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492556723-9189-1-git-send-email-tbaicar@codeaurora.org>
Add support for ARM Common Platform Error Record (CPER).
UEFI 2.6 specification adds support for ARM specific
processor error information to be reported as part of the
CPER records. This provides more detail on for processor error logs.
Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
CC: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
Reviewed-by: James Morse <james.morse@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/cper.c | 135 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/cper.h | 54 ++++++++++++++++++
2 files changed, 189 insertions(+)
diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index 46585f9..f959185 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -110,12 +110,15 @@ void cper_print_bits(const char *pfx, unsigned int bits,
static const char * const proc_type_strs[] = {
"IA32/X64",
"IA64",
+ "ARM",
};
static const char * const proc_isa_strs[] = {
"IA32",
"IA64",
"X64",
+ "ARM A32/T32",
+ "ARM A64",
};
static const char * const proc_error_type_strs[] = {
@@ -184,6 +187,128 @@ static void cper_print_proc_generic(const char *pfx,
printk("%s""IP: 0x%016llx\n", pfx, proc->ip);
}
+#if defined(CONFIG_ARM64) || defined(CONFIG_ARM)
+static const char * const arm_reg_ctx_strs[] = {
+ "AArch32 general purpose registers",
+ "AArch32 EL1 context registers",
+ "AArch32 EL2 context registers",
+ "AArch32 secure context registers",
+ "AArch64 general purpose registers",
+ "AArch64 EL1 context registers",
+ "AArch64 EL2 context registers",
+ "AArch64 EL3 context registers",
+ "Misc. system register structure",
+};
+
+static void cper_print_proc_arm(const char *pfx,
+ const struct cper_sec_proc_arm *proc)
+{
+ int i, len, max_ctx_type;
+ struct cper_arm_err_info *err_info;
+ struct cper_arm_ctx_info *ctx_info;
+ char newpfx[64];
+
+ printk("%ssection length: %d\n", pfx, proc->section_length);
+ printk("%sMIDR: 0x%016llx\n", pfx, proc->midr);
+
+ len = proc->section_length - (sizeof(*proc) +
+ proc->err_info_num * (sizeof(*err_info)));
+ if (len < 0) {
+ printk("%ssection length is too small\n", pfx);
+ printk("%sfirmware-generated error record is incorrect\n", pfx);
+ printk("%sERR_INFO_NUM is %d\n", pfx, proc->err_info_num);
+ return;
+ }
+
+ if (proc->validation_bits & CPER_ARM_VALID_MPIDR)
+ printk("%sMPIDR: 0x%016llx\n", pfx, proc->mpidr);
+ if (proc->validation_bits & CPER_ARM_VALID_AFFINITY_LEVEL)
+ printk("%serror affinity level: %d\n", pfx,
+ proc->affinity_level);
+ if (proc->validation_bits & CPER_ARM_VALID_RUNNING_STATE) {
+ printk("%srunning state: 0x%x\n", pfx, proc->running_state);
+ printk("%sPSCI state: %d\n", pfx, proc->psci_state);
+ }
+
+ snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
+
+ err_info = (struct cper_arm_err_info *)(proc + 1);
+ for (i = 0; i < proc->err_info_num; i++) {
+ printk("%sError info structure %d:\n", pfx, i);
+ printk("%sversion:%d\n", newpfx, err_info->version);
+ printk("%slength:%d\n", newpfx, err_info->length);
+ if (err_info->validation_bits &
+ CPER_ARM_INFO_VALID_MULTI_ERR) {
+ if (err_info->multiple_error == 0)
+ printk("%ssingle error\n", newpfx);
+ else if (err_info->multiple_error == 1)
+ printk("%smultiple errors\n", newpfx);
+ else
+ printk("%smultiple errors count:%u\n",
+ newpfx, err_info->multiple_error);
+ }
+ if (err_info->validation_bits & CPER_ARM_INFO_VALID_FLAGS) {
+ if (err_info->flags & CPER_ARM_INFO_FLAGS_FIRST)
+ printk("%sfirst error captured\n", newpfx);
+ if (err_info->flags & CPER_ARM_INFO_FLAGS_LAST)
+ printk("%slast error captured\n", newpfx);
+ if (err_info->flags & CPER_ARM_INFO_FLAGS_PROPAGATED)
+ printk("%spropagated error captured\n",
+ newpfx);
+ if (err_info->flags & CPER_ARM_INFO_FLAGS_OVERFLOW)
+ printk("%soverflow occurred, error info is incomplete\n",
+ newpfx);
+ }
+ printk("%serror_type: %d, %s\n", newpfx, err_info->type,
+ err_info->type < ARRAY_SIZE(proc_error_type_strs) ?
+ proc_error_type_strs[err_info->type] : "unknown");
+ if (err_info->validation_bits & CPER_ARM_INFO_VALID_ERR_INFO)
+ printk("%serror_info: 0x%016llx\n", newpfx,
+ err_info->error_info);
+ if (err_info->validation_bits & CPER_ARM_INFO_VALID_VIRT_ADDR)
+ printk("%svirtual fault address: 0x%016llx\n",
+ newpfx, err_info->virt_fault_addr);
+ if (err_info->validation_bits &
+ CPER_ARM_INFO_VALID_PHYSICAL_ADDR)
+ printk("%sphysical fault address: 0x%016llx\n",
+ newpfx, err_info->physical_fault_addr);
+ err_info += 1;
+ }
+ ctx_info = (struct cper_arm_ctx_info *)err_info;
+ max_ctx_type = ARRAY_SIZE(arm_reg_ctx_strs) - 1;
+ for (i = 0; i < proc->context_info_num; i++) {
+ int size = sizeof(*ctx_info) + ctx_info->size;
+
+ printk("%sContext info structure %d:\n", pfx, i);
+ if (len < size) {
+ printk("%ssection length is too small\n", newpfx);
+ printk("%sfirmware-generated error record is incorrect\n", pfx);
+ return;
+ }
+ if (ctx_info->type > max_ctx_type) {
+ printk("%sInvalid context type: %d\n", newpfx,
+ ctx_info->type);
+ printk("%sMax context type: %d\n", newpfx,
+ max_ctx_type);
+ return;
+ }
+ printk("%sregister context type %d: %s\n", newpfx,
+ ctx_info->type, arm_reg_ctx_strs[ctx_info->type]);
+ print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4,
+ (ctx_info + 1), ctx_info->size, 0);
+ len -= size;
+ ctx_info = (struct cper_arm_ctx_info *)((long)ctx_info + size);
+ }
+
+ if (len > 0) {
+ printk("%sVendor specific error info has %u bytes:\n", pfx,
+ len);
+ print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4, ctx_info,
+ len, true);
+ }
+}
+#endif
+
static const char * const mem_err_type_strs[] = {
"unknown",
"no error",
@@ -461,6 +586,16 @@ static void cper_estatus_timestamp(const char *pfx,
cper_print_pcie(newpfx, pcie, gdata);
else
goto err_section_too_small;
+ } else if ((IS_ENABLED(CONFIG_ARM64) || IS_ENABLED(CONFIG_ARM)) &&
+ !uuid_le_cmp(*sec_type, CPER_SEC_PROC_ARM)) {
+ struct cper_sec_proc_arm *arm_err;
+
+ arm_err = acpi_hest_get_payload(gdata);
+ printk("%ssection_type: ARM processor error\n", newpfx);
+ if (gdata->error_data_length >= sizeof(*arm_err))
+ cper_print_proc_arm(newpfx, arm_err);
+ else
+ goto err_section_too_small;
} else
printk("%s""section type: unknown, %pUl\n", newpfx, sec_type);
diff --git a/include/linux/cper.h b/include/linux/cper.h
index dcacb1a..85450f3 100644
--- a/include/linux/cper.h
+++ b/include/linux/cper.h
@@ -180,6 +180,10 @@ enum {
#define CPER_SEC_PROC_IPF \
UUID_LE(0xE429FAF1, 0x3CB7, 0x11D4, 0x0B, 0xCA, 0x07, 0x00, \
0x80, 0xC7, 0x3C, 0x88, 0x81)
+/* Processor Specific: ARM */
+#define CPER_SEC_PROC_ARM \
+ UUID_LE(0xE19E3D16, 0xBC11, 0x11E4, 0x9C, 0xAA, 0xC2, 0x05, \
+ 0x1D, 0x5D, 0x46, 0xB0)
/* Platform Memory */
#define CPER_SEC_PLATFORM_MEM \
UUID_LE(0xA5BC1114, 0x6F64, 0x4EDE, 0xB8, 0x63, 0x3E, 0x83, \
@@ -255,6 +259,22 @@ enum {
#define CPER_PCIE_SLOT_SHIFT 3
+#define CPER_ARM_VALID_MPIDR 0x00000001
+#define CPER_ARM_VALID_AFFINITY_LEVEL 0x00000002
+#define CPER_ARM_VALID_RUNNING_STATE 0x00000004
+#define CPER_ARM_VALID_VENDOR_INFO 0x00000008
+
+#define CPER_ARM_INFO_VALID_MULTI_ERR 0x0001
+#define CPER_ARM_INFO_VALID_FLAGS 0x0002
+#define CPER_ARM_INFO_VALID_ERR_INFO 0x0004
+#define CPER_ARM_INFO_VALID_VIRT_ADDR 0x0008
+#define CPER_ARM_INFO_VALID_PHYSICAL_ADDR 0x0010
+
+#define CPER_ARM_INFO_FLAGS_FIRST 0x0001
+#define CPER_ARM_INFO_FLAGS_LAST 0x0002
+#define CPER_ARM_INFO_FLAGS_PROPAGATED 0x0004
+#define CPER_ARM_INFO_FLAGS_OVERFLOW 0x0008
+
/*
* All tables and structs must be byte-packed to match CPER
* specification, since the tables are provided by the system BIOS
@@ -340,6 +360,40 @@ struct cper_ia_proc_ctx {
__u64 mm_reg_addr;
};
+/* ARM Processor Error Section */
+struct cper_sec_proc_arm {
+ __u32 validation_bits;
+ __u16 err_info_num; /* Number of Processor Error Info */
+ __u16 context_info_num; /* Number of Processor Context Info Records*/
+ __u32 section_length;
+ __u8 affinity_level;
+ __u8 reserved[3]; /* must be zero */
+ __u64 mpidr;
+ __u64 midr;
+ __u32 running_state; /* Bit 0 set - Processor running. PSCI = 0 */
+ __u32 psci_state;
+};
+
+/* ARM Processor Error Information Structure */
+struct cper_arm_err_info {
+ __u8 version;
+ __u8 length;
+ __u16 validation_bits;
+ __u8 type;
+ __u16 multiple_error;
+ __u8 flags;
+ __u64 error_info;
+ __u64 virt_fault_addr;
+ __u64 physical_fault_addr;
+};
+
+/* ARM Processor Context Information Structure */
+struct cper_arm_ctx_info {
+ __u16 version;
+ __u16 type;
+ __u32 size;
+};
+
/* Old Memory Error Section UEFI 2.1, 2.2 */
struct cper_sec_mem_err_old {
__u64 validation_bits;
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH V15 03/11] cper: add timestamp print to CPER status printing
From: Tyler Baicar @ 2017-04-18 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492556723-9189-1-git-send-email-tbaicar@codeaurora.org>
The ACPI 6.1 spec added a timestamp to the HEST generic data
structure. Print the timestamp out when printing out the error
status information.
Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
CC: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
Reviewed-by: James Morse <james.morse@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/cper.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index 8328a6f..46585f9 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -32,6 +32,8 @@
#include <linux/acpi.h>
#include <linux/pci.h>
#include <linux/aer.h>
+#include <linux/printk.h>
+#include <linux/bcd.h>
#include <acpi/ghes.h>
#define INDENT_SP " "
@@ -387,6 +389,29 @@ static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie *pcie,
pfx, pcie->bridge.secondary_status, pcie->bridge.control);
}
+static void cper_estatus_timestamp(const char *pfx,
+ struct acpi_hest_generic_data_v300 *gdata)
+{
+ __u8 hour, min, sec, day, mon, year, century, *timestamp;
+
+ if (gdata->validation_bits & ACPI_HEST_GEN_VALID_TIMESTAMP) {
+ timestamp = (__u8 *)&(gdata->time_stamp);
+ sec = bcd2bin(timestamp[0]);
+ min = bcd2bin(timestamp[1]);
+ hour = bcd2bin(timestamp[2]);
+ day = bcd2bin(timestamp[4]);
+ mon = bcd2bin(timestamp[5]);
+ year = bcd2bin(timestamp[6]);
+ century = bcd2bin(timestamp[7]);
+
+ if (*(timestamp + 3) & 0x1)
+ printk("%stimestamp is precise\n", pfx);
+
+ printk("%stime: %02d%02d-%02d-%02d %02d:%02d:%02d\n", pfx,
+ century, year, mon, day, hour, min, sec);
+ }
+}
+
static void
cper_estatus_print_section(const char *pfx, struct acpi_hest_generic_data *gdata,
int sec_no)
@@ -395,6 +420,9 @@ static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie *pcie,
__u16 severity;
char newpfx[64];
+ if (acpi_hest_get_version(gdata) >= 3)
+ cper_estatus_timestamp(pfx, (struct acpi_hest_generic_data_v300 *)gdata);
+
severity = gdata->error_severity;
printk("%s""Error %d, type: %s\n", pfx, sec_no,
cper_severity_str(severity));
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH V15 02/11] ras: acpi/apei: cper: add support for generic data v3 structure
From: Tyler Baicar @ 2017-04-18 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492556723-9189-1-git-send-email-tbaicar@codeaurora.org>
The ACPI 6.1 spec adds a new version of the generic data structure.
Add support to handle the new structure as well as properly verify
and iterate through the generic data entries.
Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
CC: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
Reviewed-by: James Morse <james.morse@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/acpi/apei/ghes.c | 6 +++---
drivers/firmware/efi/cper.c | 37 ++++++++++++++++++++++---------------
include/acpi/ghes.h | 22 ++++++++++++++++++++++
3 files changed, 47 insertions(+), 18 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 6d87ab7..dfb7dd2 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -429,7 +429,7 @@ static void ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, int
int flags = -1;
int sec_sev = ghes_severity(gdata->error_severity);
struct cper_sec_mem_err *mem_err;
- mem_err = (struct cper_sec_mem_err *)(gdata + 1);
+ mem_err = acpi_hest_get_payload(gdata);
if (!(mem_err->validation_bits & CPER_MEM_VALID_PA))
return;
@@ -466,7 +466,7 @@ static void ghes_do_proc(struct ghes *ghes,
if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
CPER_SEC_PLATFORM_MEM)) {
struct cper_sec_mem_err *mem_err;
- mem_err = (struct cper_sec_mem_err *)(gdata+1);
+ mem_err = acpi_hest_get_payload(gdata);
ghes_edac_report_mem_error(ghes, sev, mem_err);
arch_apei_report_mem_error(sev, mem_err);
@@ -476,7 +476,7 @@ static void ghes_do_proc(struct ghes *ghes,
else if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
CPER_SEC_PCIE)) {
struct cper_sec_pcie *pcie_err;
- pcie_err = (struct cper_sec_pcie *)(gdata+1);
+ pcie_err = acpi_hest_get_payload(gdata);
if (sev == GHES_SEV_RECOVERABLE &&
sec_sev == GHES_SEV_RECOVERABLE &&
pcie_err->validation_bits & CPER_PCIE_VALID_DEVICE_ID &&
diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index d425374..8328a6f 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -32,6 +32,7 @@
#include <linux/acpi.h>
#include <linux/pci.h>
#include <linux/aer.h>
+#include <acpi/ghes.h>
#define INDENT_SP " "
@@ -386,8 +387,9 @@ static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie *pcie,
pfx, pcie->bridge.secondary_status, pcie->bridge.control);
}
-static void cper_estatus_print_section(
- const char *pfx, const struct acpi_hest_generic_data *gdata, int sec_no)
+static void
+cper_estatus_print_section(const char *pfx, struct acpi_hest_generic_data *gdata,
+ int sec_no)
{
uuid_le *sec_type = (uuid_le *)gdata->section_type;
__u16 severity;
@@ -403,14 +405,18 @@ static void cper_estatus_print_section(
snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_GENERIC)) {
- struct cper_sec_proc_generic *proc_err = (void *)(gdata + 1);
+ struct cper_sec_proc_generic *proc_err;
+
+ proc_err = acpi_hest_get_payload(gdata);
printk("%s""section_type: general processor error\n", newpfx);
if (gdata->error_data_length >= sizeof(*proc_err))
cper_print_proc_generic(newpfx, proc_err);
else
goto err_section_too_small;
} else if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
- struct cper_sec_mem_err *mem_err = (void *)(gdata + 1);
+ struct cper_sec_mem_err *mem_err;
+
+ mem_err = acpi_hest_get_payload(gdata);
printk("%s""section_type: memory error\n", newpfx);
if (gdata->error_data_length >=
sizeof(struct cper_sec_mem_err_old))
@@ -419,7 +425,9 @@ static void cper_estatus_print_section(
else
goto err_section_too_small;
} else if (!uuid_le_cmp(*sec_type, CPER_SEC_PCIE)) {
- struct cper_sec_pcie *pcie = (void *)(gdata + 1);
+ struct cper_sec_pcie *pcie;
+
+ pcie = acpi_hest_get_payload(gdata);
printk("%s""section_type: PCIe error\n", newpfx);
if (gdata->error_data_length >= sizeof(*pcie))
cper_print_pcie(newpfx, pcie, gdata);
@@ -438,7 +446,7 @@ void cper_estatus_print(const char *pfx,
const struct acpi_hest_generic_status *estatus)
{
struct acpi_hest_generic_data *gdata;
- unsigned int data_len, gedata_len;
+ unsigned int data_len;
int sec_no = 0;
char newpfx[64];
__u16 severity;
@@ -452,11 +460,10 @@ void cper_estatus_print(const char *pfx,
data_len = estatus->data_length;
gdata = (struct acpi_hest_generic_data *)(estatus + 1);
snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
- while (data_len >= sizeof(*gdata)) {
- gedata_len = gdata->error_data_length;
+ while (data_len >= acpi_hest_get_size(gdata)) {
cper_estatus_print_section(newpfx, gdata, sec_no);
- data_len -= gedata_len + sizeof(*gdata);
- gdata = (void *)(gdata + 1) + gedata_len;
+ data_len -= acpi_hest_get_record_size(gdata);
+ gdata = acpi_hest_get_next(gdata);
sec_no++;
}
}
@@ -486,12 +493,12 @@ int cper_estatus_check(const struct acpi_hest_generic_status *estatus)
return rc;
data_len = estatus->data_length;
gdata = (struct acpi_hest_generic_data *)(estatus + 1);
- while (data_len >= sizeof(*gdata)) {
- gedata_len = gdata->error_data_length;
- if (gedata_len > data_len - sizeof(*gdata))
+ while (data_len >= acpi_hest_get_size(gdata)) {
+ gedata_len = acpi_hest_get_error_length(gdata);
+ if (gedata_len > data_len - acpi_hest_get_size(gdata))
return -EINVAL;
- data_len -= gedata_len + sizeof(*gdata);
- gdata = (void *)(gdata + 1) + gedata_len;
+ data_len -= acpi_hest_get_record_size(gdata);
+ gdata = acpi_hest_get_next(gdata);
}
if (data_len)
return -EINVAL;
diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
index 68f088a..b89361a 100644
--- a/include/acpi/ghes.h
+++ b/include/acpi/ghes.h
@@ -12,6 +12,20 @@
#define GHES_TO_CLEAR 0x0001
#define GHES_EXITING 0x0002
+#define acpi_hest_get_error_length(gdata) \
+ (((struct acpi_hest_generic_data *)(gdata))->error_data_length)
+#define acpi_hest_get_size(gdata) \
+ ((acpi_hest_get_version(gdata) >= 3) ? \
+ sizeof(struct acpi_hest_generic_data_v300) : \
+ sizeof(struct acpi_hest_generic_data))
+#define acpi_hest_get_record_size(gdata) \
+ (acpi_hest_get_size(gdata) + \
+ acpi_hest_get_error_length(gdata))
+#define acpi_hest_get_next(gdata) \
+ ((void *)(gdata) + acpi_hest_get_record_size(gdata))
+#define acpi_hest_get_version(gdata) \
+ (gdata->revision >> 8)
+
struct ghes {
union {
struct acpi_hest_generic *generic;
@@ -73,3 +87,11 @@ static inline void ghes_edac_unregister(struct ghes *ghes)
{
}
#endif
+
+static inline void *acpi_hest_get_payload(struct acpi_hest_generic_data *gdata)
+{
+ if (acpi_hest_get_version(gdata) >= 3)
+ return (void *)(((struct acpi_hest_generic_data_v300 *)(gdata)) + 1);
+
+ return gdata + 1;
+}
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH V15 01/11] acpi: apei: read ack upon ghes record consumption
From: Tyler Baicar @ 2017-04-18 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492556723-9189-1-git-send-email-tbaicar@codeaurora.org>
A RAS (Reliability, Availability, Serviceability) controller
may be a separate processor running in parallel with OS
execution, and may generate error records for consumption by
the OS. If the RAS controller produces multiple error records,
then they may be overwritten before the OS has consumed them.
The Generic Hardware Error Source (GHES) v2 structure
introduces the capability for the OS to acknowledge the
consumption of the error record generated by the RAS
controller. A RAS controller supporting GHESv2 shall wait for
the acknowledgment before writing a new error record, thus
eliminating the race condition.
Add support for parsing of GHESv2 sub-tables as well.
Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
CC: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
Reviewed-by: James Morse <james.morse@arm.com>
---
drivers/acpi/apei/ghes.c | 55 +++++++++++++++++++++++++++++++++++++++++++++---
drivers/acpi/apei/hest.c | 7 ++++--
include/acpi/ghes.h | 5 ++++-
3 files changed, 61 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 79b3c9c..6d87ab7 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -46,6 +46,7 @@
#include <linux/nmi.h>
#include <linux/sched/clock.h>
+#include <acpi/actbl1.h>
#include <acpi/ghes.h>
#include <acpi/apei.h>
#include <asm/tlbflush.h>
@@ -80,6 +81,10 @@
((struct acpi_hest_generic_status *) \
((struct ghes_estatus_node *)(estatus_node) + 1))
+#define IS_HEST_TYPE_GENERIC_V2(ghes) \
+ ((struct acpi_hest_header *)ghes->generic)->type == \
+ ACPI_HEST_TYPE_GENERIC_ERROR_V2
+
/*
* This driver isn't really modular, however for the time being,
* continuing to use module_param is the easiest way to remain
@@ -240,6 +245,17 @@ static int ghes_estatus_pool_expand(unsigned long len)
return 0;
}
+static int map_gen_v2(struct ghes *ghes)
+{
+ return apei_map_generic_address(&ghes->generic_v2->read_ack_register);
+}
+
+static void unmap_gen_v2(struct ghes *ghes)
+{
+ apei_unmap_generic_address(&ghes->generic_v2->read_ack_register);
+ return;
+}
+
static struct ghes *ghes_new(struct acpi_hest_generic *generic)
{
struct ghes *ghes;
@@ -249,10 +265,17 @@ static struct ghes *ghes_new(struct acpi_hest_generic *generic)
ghes = kzalloc(sizeof(*ghes), GFP_KERNEL);
if (!ghes)
return ERR_PTR(-ENOMEM);
+
ghes->generic = generic;
+ if (IS_HEST_TYPE_GENERIC_V2(ghes)) {
+ rc = map_gen_v2(ghes);
+ if (rc)
+ goto err_free;
+ }
+
rc = apei_map_generic_address(&generic->error_status_address);
if (rc)
- goto err_free;
+ goto err_unmap_read_ack_addr;
error_block_length = generic->error_block_length;
if (error_block_length > GHES_ESTATUS_MAX_SIZE) {
pr_warning(FW_WARN GHES_PFX
@@ -264,13 +287,16 @@ static struct ghes *ghes_new(struct acpi_hest_generic *generic)
ghes->estatus = kmalloc(error_block_length, GFP_KERNEL);
if (!ghes->estatus) {
rc = -ENOMEM;
- goto err_unmap;
+ goto err_unmap_status_addr;
}
return ghes;
-err_unmap:
+err_unmap_status_addr:
apei_unmap_generic_address(&generic->error_status_address);
+err_unmap_read_ack_addr:
+ if (IS_HEST_TYPE_GENERIC_V2(ghes))
+ unmap_gen_v2(ghes);
err_free:
kfree(ghes);
return ERR_PTR(rc);
@@ -280,6 +306,8 @@ static void ghes_fini(struct ghes *ghes)
{
kfree(ghes->estatus);
apei_unmap_generic_address(&ghes->generic->error_status_address);
+ if (IS_HEST_TYPE_GENERIC_V2(ghes))
+ unmap_gen_v2(ghes);
}
static inline int ghes_severity(int severity)
@@ -649,6 +677,21 @@ static void ghes_estatus_cache_add(
rcu_read_unlock();
}
+static int ghes_ack_error(struct acpi_hest_generic_v2 *generic_v2)
+{
+ int rc;
+ u64 val = 0;
+
+ rc = apei_read(&val, &generic_v2->read_ack_register);
+ if (rc)
+ return rc;
+
+ val &= generic_v2->read_ack_preserve << generic_v2->read_ack_register.bit_offset;
+ val |= generic_v2->read_ack_write << generic_v2->read_ack_register.bit_offset;
+
+ return apei_write(val, &generic_v2->read_ack_register);
+}
+
static int ghes_proc(struct ghes *ghes)
{
int rc;
@@ -661,6 +704,12 @@ static int ghes_proc(struct ghes *ghes)
ghes_estatus_cache_add(ghes->generic, ghes->estatus);
}
ghes_do_proc(ghes, ghes->estatus);
+
+ if (IS_HEST_TYPE_GENERIC_V2(ghes)) {
+ rc = ghes_ack_error(ghes->generic_v2);
+ if (rc)
+ return rc;
+ }
out:
ghes_clear_estatus(ghes);
return rc;
diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
index 8f2a98e..456b488 100644
--- a/drivers/acpi/apei/hest.c
+++ b/drivers/acpi/apei/hest.c
@@ -52,6 +52,7 @@
[ACPI_HEST_TYPE_AER_ENDPOINT] = sizeof(struct acpi_hest_aer),
[ACPI_HEST_TYPE_AER_BRIDGE] = sizeof(struct acpi_hest_aer_bridge),
[ACPI_HEST_TYPE_GENERIC_ERROR] = sizeof(struct acpi_hest_generic),
+ [ACPI_HEST_TYPE_GENERIC_ERROR_V2] = sizeof(struct acpi_hest_generic_v2),
};
static int hest_esrc_len(struct acpi_hest_header *hest_hdr)
@@ -141,7 +142,8 @@ static int __init hest_parse_ghes_count(struct acpi_hest_header *hest_hdr, void
{
int *count = data;
- if (hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR)
+ if (hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR ||
+ hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR_V2)
(*count)++;
return 0;
}
@@ -152,7 +154,8 @@ static int __init hest_parse_ghes(struct acpi_hest_header *hest_hdr, void *data)
struct ghes_arr *ghes_arr = data;
int rc, i;
- if (hest_hdr->type != ACPI_HEST_TYPE_GENERIC_ERROR)
+ if (hest_hdr->type != ACPI_HEST_TYPE_GENERIC_ERROR &&
+ hest_hdr->type != ACPI_HEST_TYPE_GENERIC_ERROR_V2)
return 0;
if (!((struct acpi_hest_generic *)hest_hdr)->enabled)
diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
index 720446c..68f088a 100644
--- a/include/acpi/ghes.h
+++ b/include/acpi/ghes.h
@@ -13,7 +13,10 @@
#define GHES_EXITING 0x0002
struct ghes {
- struct acpi_hest_generic *generic;
+ union {
+ struct acpi_hest_generic *generic;
+ struct acpi_hest_generic_v2 *generic_v2;
+ };
struct acpi_hest_generic_status *estatus;
u64 buffer_paddr;
unsigned long flags;
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH V15 00/11] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64
From: Tyler Baicar @ 2017-04-18 23:05 UTC (permalink / raw)
To: linux-arm-kernel
When a memory error, CPU error, PCIe error, or other type of hardware error
that's covered by RAS occurs, firmware should populate the shared GHES memory
location with the proper GHES structures to notify the OS of the error.
For example, platforms that implement firmware first handling may implement
separate GHES sources for corrected errors and uncorrected errors. If the
error is an uncorrectable error, then the firmware will notify the OS
immediately since the error needs to be handled ASAP. The OS will then be able
to take the appropriate action needed such as offlining a page. If the error
is a corrected error, then the firmware will not interrupt the OS immediately.
Instead, the OS will see and report the error the next time it's GHES timer
expires. The kernel will first parse the GHES structures and report the errors
through the kernel logs and then notify the user space through RAS trace
events. This allows user space applications such as RAS Daemon to see the
errors and report them however the user desires. This patchset extends the
kernel functionality for RAS errors based on updates in the UEFI 2.6 and
ACPI 6.1 specifications.
An example flow from firmware to user space could be:
+---------------+
+-------->| |
| | GHES polling |--+
+-------------+ | source | | +---------------+ +------------+
| | +---------------+ | | Kernel GHES | | |
| Firmware | +-->| CPER AER and |-->| RAS trace |
| | +---------------+ | | EDAC drivers | | event |
+-------------+ | | | +---------------+ +------------+
| | GHES sci |--+
+-------->| source |
+---------------+
Add support for Generic Hardware Error Source (GHES) v2, which introduces the
capability for the OS to acknowledge the consumption of the error record
generated by the Reliability, Availability and Serviceability (RAS) controller.
This eliminates potential race conditions between the OS and the RAS controller.
Add support for the timestamp field added to the Generic Error Data Entry v3,
allowing the OS to log the time that the error is generated by the firmware,
rather than the time the error is consumed. This improves the correctness of
event sequences when analyzing error logs. The timestamp is added in
ACPI 6.1, reference Table 18-343 Generic Error Data Entry.
Add support for ARMv8 Common Platform Error Record (CPER) per UEFI 2.6
specification. ARMv8 specific processor error information is reported as part of
the CPER records. This provides more detail on for processor error logs. This
can help describe ARMv8 cache, tlb, and bus errors.
Synchronous External Abort (SEA) represents a specific processor error condition
in ARM systems. A handler is added to recognize SEA errors, and a notifier is
added to parse and report the errors before the process is killed. Refer to
section N.2.1.1 in the Common Platform Error Record appendix of the UEFI 2.6
specification.
Currently the kernel ignores CPER records that are unrecognized.
On the other hand, UEFI spec allows for non-standard (eg. vendor
proprietary) error section type in CPER (Common Platform Error Record),
as defined in section N2.3 of UEFI version 2.5. Therefore, user
is not able to see hardware error data of non-standard section.
If section Type field of Generic Error Data Entry is unrecognized,
prints out the raw data in dmesg buffer, and also adds a tracepoint
for reporting such hardware errors.
Currently even if an error status block's severity is fatal, the kernel
does not honor the severity level and panic. With the firmware first
model, the platform could inform the OS about a fatal hardware error
through the non-NMI GHES notification type. The OS should panic when a
hardware error record is received with this severity.
Add support to handle SEAs that occur while a KVM guest kernel is
running. Currently these are unsupported by the guest abort handling.
V15:Rebase on 4.11-rc7
Use wrapper functions for [un]mapping kernel acknowledgement register
Spacing and name changes to make code cleaner
Break up timestamp print to be more readable
Break generic error data v3 structure handling code into seperate patch
and have timestamp handling in it's own patch
Put ARM CPER handling into ifdef for ARM systems
Add braces and missing space to KVM patch
V14:Make sure function prototypes are in the __ASSEMBLY__ block
Change is_abort_synchronous to is_abort_sea
Use phys_addr_t for SEA address
Return after successful SEA handling in handle_guest_abort()
V13:Rebase on 4.11rc2
Print decimal and hex sizes for unknown CPER section errors
Use proper CONFIG_* when using IS_ENABLED
Move handle_guest_sea call prior to SEI check
Add a return value to handle_guest_sea
Move RCU locking into ghes_notify_sea
Add valid bit checks to ARM trace event
Remove GPIO, SEI, and GSIV cases in GHES
Add ARCH_HAVE_NMI_SAFE_CMPXCHG since we added NMI usage
V12:Remove double quotes from CPER code
Add helper function to check all SEA cases in KVM patch
Replace nmi_enter/exit with rcu_read_lock/unlock for KVM SEA
Change HAVE_ACPI_APEI_SEA to ACPI_APEI_SEA in KVM SEA case
V11:Change print_hex_dump calls to include ASCII output
Change HAVE_ACPI_APEI_SEA to ACPI_APEI_SEA and make it 'default y'
Add unknown print back when printing unknown CPER section
Make sure to use "%s"" in CPER code
Spacing fix when checking if SEA is enabled
V10:Fix spacing of trace event enabled if statement
V9: Move SEA_FnV_MASK to ESR_ELx_FnV
Move HAVE_NMI into alphabetical order
Remove duplicate hardirq.h include
Only call ghes_notify_sea if HAVE_ACPI_APEI_SEA
Make ACPI_APEI_SEA depend on ACPI_APEI_GHES
Use phys_addr_t for physical address variable
Make ghes_sea_add() return void
Add include guard to ghes.h
Verify HAVE_RAS before calling ras trace events
Call __ghes_print_estatus() before __ghes_call_panic()
Add trace_*_event_enabled() checks for both new trace events
V8: Remove SEA notifier
Add FAR not valid bit check when populating the SEA error address
Move nmi_enter/exit() to architecture specific code
Add synchronize_rcu() usage to SEA handling
Make GHES_IOREMAP_PAGES always 2
Update ghes_ioremap_pfn_nmi() to work like ghes_ioremap_pfn_irq()
Remove the SEA print from handle_guest_sea()
V7: Update a couple prints for ARM processor errors
Add Print notifying if overflow occurred for ARM processor errors
Check for ARM configuration to allow the compiler to ignore ARM code
on non-ARM systems
Use SEA acronym instead of spelling it out
Update fault_info prints to be more clear
Add NMI locking to SEA notification
Remove error info structure from ARM trace event since there can be
a variable amount of these structures
V6: Change HEST_TYPE_GENERIC_V2 to IS_HEST_TYPE_GENERIC_V2 for readability
Move APEI helper defines from cper.h to ghes.h
Add data_len decrement back into print loop
Change references to ARMv8 to just ARM
Rewrite ARM processor context info parsing
Check valid bit of ARM error info field before printing it
Add include of linux/uuid.h in ghes.c
V5: Fix GHES goto logic for error conditions
Change ghes_do_read_ack to ghes_ack_error
Make sure data version check is >= 3
Use CPER helper functions in print functions
Make handle_guest_sea() dummy function static for arm
Add arm to subject line for KVM patch
V4: Add bit offset left shift to read_ack_write value
Make HEST generic and generic_v2 structures a union in the ghes structure
Move gdata v3 helper functions into ghes.h to avoid duplication
Reorder the timestamp print and avoid memcpy
Add helper functions for gdata size checking
Rename the SEA functions
Add helper function for GHES panics
Set fru_id to NULL UUID at variable declaration
Limit ARM trace event parameters to the needed structures
Reorder the ARM trace event variables to save space
Add comment for why we don't pass SEAs to the guest when it aborts
Move ARM trace event call into GHES driver instead of CPER
V3: Fix unmapped address to the read_ack_register in ghes.c
Add helper function to get the proper payload based on generic data entry
version
Move timestamp print to avoid changing function calls in cper.c
Remove patch "arm64: exception: handle instruction abort at current EL"
since the el1_ia handler is already added in 4.8
Add EFI and ARM64 dependencies for HAVE_ACPI_APEI_SEA
Add a new trace event for ARM type errors
Add support to handle KVM guest SEAs
V2: Add PSCI state print for the ARMv8 error type.
Separate timestamp year into year and century using BCD format.
Rebase on top of ACPICA 20160318 release and remove header file changes
in include/acpi/actbl1.h.
Add panic OS with fatal error status block patch.
Add processing of unrecognized CPER error section patches with updates
from previous comments. Original patches: https://lkml.org/lkml/2015/9/8/646
V1: https://lkml.org/lkml/2016/2/5/544
Jonathan (Zhixiong) Zhang (1):
acpi: apei: panic OS with fatal error status block
Tyler Baicar (10):
acpi: apei: read ack upon ghes record consumption
ras: acpi/apei: cper: add support for generic data v3 structure
cper: add timestamp print to CPER status printing
efi: parse ARM processor error
arm64: exception: handle Synchronous External Abort
acpi: apei: handle SEA notification type for ARMv8
efi: print unrecognized CPER section
ras: acpi / apei: generate trace event for unrecognized CPER section
trace, ras: add ARM processor error trace event
arm/arm64: KVM: add guest SEA support
arch/arm/include/asm/kvm_arm.h | 10 ++
arch/arm/include/asm/system_misc.h | 5 +
arch/arm/kvm/mmu.c | 35 +++++-
arch/arm64/Kconfig | 2 +
arch/arm64/include/asm/esr.h | 1 +
arch/arm64/include/asm/kvm_arm.h | 10 ++
arch/arm64/include/asm/system_misc.h | 2 +
arch/arm64/mm/fault.c | 77 +++++++++++--
drivers/acpi/apei/Kconfig | 15 +++
drivers/acpi/apei/ghes.c | 184 ++++++++++++++++++++++++++----
drivers/acpi/apei/hest.c | 7 +-
drivers/firmware/efi/cper.c | 213 ++++++++++++++++++++++++++++++++---
drivers/ras/ras.c | 2 +
include/acpi/ghes.h | 34 +++++-
include/linux/cper.h | 54 +++++++++
include/ras/ras_event.h | 90 +++++++++++++++
16 files changed, 687 insertions(+), 54 deletions(-)
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 2/2] hwmon: (brcmstb) Add driver for Broadcom STB DPFE
From: Guenter Roeck @ 2017-04-18 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f8c99c6f-8c53-0d0e-0712-d001c1e45f75@gmail.com>
Hi Florian,
On Tue, Apr 18, 2017 at 03:29:55PM -0700, Florian Fainelli wrote:
> Hey Guenter,
>
> On 04/18/2017 01:58 PM, Guenter Roeck wrote:
> > Hi Markus,
> >
> > On Tue, Apr 18, 2017 at 01:17:02PM -0700, Markus Mayer wrote:
> >> From: Markus Mayer <mmayer@broadcom.com>
> >>
> >> This driver allows access to DRAM properties, such as the refresh rate,
> >> via the Broadcom STB DDR PHY Front End (DPFE). The refresh rate can be
> >> used as indirect indicator of the DRAM temperature.
> >>
> >> The driver also allows setting of the sampling interval.
> >>
> >> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
> >> ---
> > [ ... ]
> >
> >> +
> >> +static SENSOR_DEVICE_ATTR(dpfe_info, 0444, show_info, NULL, 1000);
> >> +static SENSOR_DEVICE_ATTR(dpfe_refresh, 0644, show_refresh, store_refresh,
> >> + 1000);
> >> +static SENSOR_DEVICE_ATTR(dpfe_vendor, 0444, show_vendor, NULL, 1000);
> >> +static struct attribute *dpfe_attrs[] = {
> >> + &sensor_dev_attr_dpfe_info.dev_attr.attr,
> >> + &sensor_dev_attr_dpfe_refresh.dev_attr.attr,
> >> + &sensor_dev_attr_dpfe_vendor.dev_attr.attr,
> >> + NULL
> >> +};
> >> +ATTRIBUTE_GROUPS(dpfe);
> >> +
> >
> > There is not a single standard hwmon attribute. I don't know how
> > to classify this driver, and where it should reside, but it is not
> > a hwmon driver.
>
> This is a driver that talks to an embedded CPU running firmware which is
> capable of giving various informations about the DRAM chip being
> populated, including a temperature trend (hotter or cooler). We thought
> initially we would be able to expose the actual temperature, but this in
> turn required a lot more knowledge about the DRAM chip that we wish we
> knew about. That is sort of where and why this driver was proposed for
> hwmon.
>
> Which subsystem do you think would be best for this driver drivers/misc/
> or drivers/soc/bcm/brcmstb/ maybe?
Both should work. I would probably try misc first and let Greg tell me
which way to go ;-).
Thanks,
Guenter
^ permalink raw reply
* [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
From: Benjamin Herrenschmidt @ 2017-04-18 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418154937.GA1006@red-moon>
On Tue, 2017-04-18 at 16:49 +0100, Lorenzo Pieralisi wrote:
> I can do that yes, which already means I have to know if eg microblaze
> (drivers/pci/host/pcie-xilinx.c) can provide a mapping with nonposted
> writes semantics, otherwise it is a dead-end.
>
> Another option would be going back to what v1 did, namely, to implement
> a pci_remap_cfgspace() interface (it is the _nopost() suffix that stirred
> debate - nobody would object to having a default pci_remap_cfgspace()
> implementation that defaults to ioremap_nocache(), I know Bjorn does not
> like it to be PCI specific, just adding an option on the table to make
> progress).
Well, it boils down again to the fact that a mapping attribute isn't
sufficient.
Let's say I'm microblaze and I can't do non-posted mapping. Then the
Host Bridge driver needs to *know* that so it can implement a different
workaround, such as reading back from some bridge register after every
config write which ensures the previous write reached its destination
for example, or whatever other IP specific mechanism.
Cheers,
Ben.
^ permalink raw reply
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
From: Benjamin Herrenschmidt @ 2017-04-18 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418110350.GA1941@red-moon>
On Tue, 2017-04-18 at 12:03 +0100, Lorenzo Pieralisi wrote:
> > The above would effectively disable mmap'ing of IO space for any
> > architecture that doesn't have pgprot_nonposted... so everybody
> > except
> > ARM. Thus breaking a number of systems that have been working fine
> > for
> > years.
>
> pci_remap_iospace() is used on ARM/ARM64 only AFAICT I do not
> understand
> what I would actually break (and I am not sure at all how well PCI IO
> space is tested on ARM/ARM64 machines anyway).
My bad, I incorrectly assumed you were hacking the generic sysfs PCI
mapping.
Cheers,
Ben.
^ permalink raw reply
* [PATCH 2/2] hwmon: (brcmstb) Add driver for Broadcom STB DPFE
From: Florian Fainelli @ 2017-04-18 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418205839.GA3554@roeck-us.net>
Hey Guenter,
On 04/18/2017 01:58 PM, Guenter Roeck wrote:
> Hi Markus,
>
> On Tue, Apr 18, 2017 at 01:17:02PM -0700, Markus Mayer wrote:
>> From: Markus Mayer <mmayer@broadcom.com>
>>
>> This driver allows access to DRAM properties, such as the refresh rate,
>> via the Broadcom STB DDR PHY Front End (DPFE). The refresh rate can be
>> used as indirect indicator of the DRAM temperature.
>>
>> The driver also allows setting of the sampling interval.
>>
>> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
>> ---
> [ ... ]
>
>> +
>> +static SENSOR_DEVICE_ATTR(dpfe_info, 0444, show_info, NULL, 1000);
>> +static SENSOR_DEVICE_ATTR(dpfe_refresh, 0644, show_refresh, store_refresh,
>> + 1000);
>> +static SENSOR_DEVICE_ATTR(dpfe_vendor, 0444, show_vendor, NULL, 1000);
>> +static struct attribute *dpfe_attrs[] = {
>> + &sensor_dev_attr_dpfe_info.dev_attr.attr,
>> + &sensor_dev_attr_dpfe_refresh.dev_attr.attr,
>> + &sensor_dev_attr_dpfe_vendor.dev_attr.attr,
>> + NULL
>> +};
>> +ATTRIBUTE_GROUPS(dpfe);
>> +
>
> There is not a single standard hwmon attribute. I don't know how
> to classify this driver, and where it should reside, but it is not
> a hwmon driver.
This is a driver that talks to an embedded CPU running firmware which is
capable of giving various informations about the DRAM chip being
populated, including a temperature trend (hotter or cooler). We thought
initially we would be able to expose the actual temperature, but this in
turn required a lot more knowledge about the DRAM chip that we wish we
knew about. That is sort of where and why this driver was proposed for
hwmon.
Which subsystem do you think would be best for this driver drivers/misc/
or drivers/soc/bcm/brcmstb/ maybe?
--
Florian
^ permalink raw reply
* [PATCH] ARM: dts: rockchip: reuse firefly dtsi
From: Heiko Stuebner @ 2017-04-18 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418121527.3155-1-eddie.cai.linux@gmail.com>
Hi Eddie,
Am Dienstag, 18. April 2017, 20:15:27 CEST schrieb Eddie Cai:
> firefly reload is very similar with firefly board, so reuse firefly dtsi
>
> Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
> ---
> arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 310 ------------------
> arch/arm/boot/dts/rk3288-firefly-reload.dts | 368 ++--------------------
I would disagree and remember having a similar discussion when the reload-
support was initially submitted. Please keep in mind that the firefly-
reload is a som+baseboard combination, so somebody could (or maybe
already has) create a completely different baseboard for the som that
does not have any similarities with the original firefly.
The previous firefly being a real single board.
We also don't combine rock2 and firefly and other boards following the
general rk3288 design guidelines :-) and the original firefly and reload are
very different boards if you look at them.
Heiko
^ permalink raw reply
* [PATCH 2/2] hwmon: (brcmstb) Add driver for Broadcom STB DPFE
From: Guenter Roeck @ 2017-04-18 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418201702.57019-3-code@mmayer.net>
Hi Markus,
On Tue, Apr 18, 2017 at 01:17:02PM -0700, Markus Mayer wrote:
> From: Markus Mayer <mmayer@broadcom.com>
>
> This driver allows access to DRAM properties, such as the refresh rate,
> via the Broadcom STB DDR PHY Front End (DPFE). The refresh rate can be
> used as indirect indicator of the DRAM temperature.
>
> The driver also allows setting of the sampling interval.
>
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
> ---
[ ... ]
> +
> +static SENSOR_DEVICE_ATTR(dpfe_info, 0444, show_info, NULL, 1000);
> +static SENSOR_DEVICE_ATTR(dpfe_refresh, 0644, show_refresh, store_refresh,
> + 1000);
> +static SENSOR_DEVICE_ATTR(dpfe_vendor, 0444, show_vendor, NULL, 1000);
> +static struct attribute *dpfe_attrs[] = {
> + &sensor_dev_attr_dpfe_info.dev_attr.attr,
> + &sensor_dev_attr_dpfe_refresh.dev_attr.attr,
> + &sensor_dev_attr_dpfe_vendor.dev_attr.attr,
> + NULL
> +};
> +ATTRIBUTE_GROUPS(dpfe);
> +
There is not a single standard hwmon attribute. I don't know how
to classify this driver, and where it should reside, but it is not
a hwmon driver.
Thanks,
Guenter
^ permalink raw reply
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Stefan Wahren @ 2017-04-18 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=VHkJFrsJDmMytbUw=WjKQaGZ-8Ewfy5bPCA82AWS4O2Q@mail.gmail.com>
> Doug Anderson <dianders@chromium.org> hat am 18. April 2017 um 22:41 geschrieben:
>
>
> Stefan,
>
> On Tue, Apr 18, 2017 at 1:25 PM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> > Hi,
> >
> > [add Johan]
> >
> >> Stefan Wahren <stefan.wahren@i2se.com> hat am 18. April 2017 um 10:07 geschrieben:
> >>
> >>
> >> Am 18.04.2017 um 00:37 schrieb Doug Anderson:
> >> > Hi,
> >> >
> >> > On Mon, Apr 17, 2017 at 4:05 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> >> >> Hi,
> >> >>
> >> >>> Stefan Wahren <stefan.wahren@i2se.com> hat am 31. Oktober 2016 um 21:34 geschrieben:
> >> >>>
> >> >>>
> >> >>> I inspired by this issue [1] i build up a slightly modified setup with a
> >> >>> Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and 5 Prolific
> >> >>> PL2303 USB to serial convertors. I modified the usb_test for dwc2 [2], which
> >> >>> only tries to open all ttyUSB devices one after the other.
> >> >>>
> >> >>> Unfortunately the complete system stuck after opening the first ttyUSB device (
> >> >>> heartbeat LED stop blinking, no reaction to debug UART). The only way to
> >> >>> reanimate the system is to powerdown the USB hub with the USB to serial
> >> >>> convertors.
> >> >>>
> >> >>> [1] - https://github.com/raspberrypi/linux/issues/1692
> >> >>> [2] - https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b279dbaa
> >> >> since this issue still exists with 4.11 (even without or with microframe scheduler enabled), i want to ask some additional questions:
> >> >>
> >> >> Is this issue reproducible with other dwc2 platforms than bcm2835?
> >> > +Edmund Szeto, who I seem to remember emailing me about similar
> >> > questions in the past.
> >> >
> >> >
> >> >> Does the soft lockup also occurs after opening the second serial convertor or later?
> >> > I don't have serial converters easily available to me, but back in the
> >> > day when I was stressing things out on rk3288 I never saw anything
> >> > this bad. ...of course, on rk3288 we've got 4 A17 cores running
> >> > really fast, so possibly just being slower is what causes your
> >> > problems here?
> >>
> >> The downstream kernel of the Raspberry Pi foundation with it's
> >> out-of-tree dwc_otg driver is able to handle 8 serial converter on a RPI
> >> B. I would be happy to get at least 2 or 3 working on mainline.
> >>
> >> >
> >> > I will make the following observations:
> >> >
> >> > 1. With dwc2 you often end up in the situation where you need to
> >> > service an interrupt every 125 uS. If servicing that interrupt takes
> >> > anywhere near 125 uS in the common case then you'll be in trouble.
> >>
> >> I will try to measure this with a logic analyzer.
> >>
> >
> > i took GPIO17 to measure _dwc2_hcd_irq and GPIO18 to measure _dwc2_hcd_urb_enqueue (patch against 4.11rc1 below).
> >
> > So i made my observations for 3 test cases:
> >
> > 1) no serial converter connected (idle)
> > 2) 1 FTDI serial converter connected
> > 3) 1 PL2303 serial converter connected
> >
> > case | ksoftirq cpu | mean duration | max duration | max duration | urb_enqueue |
> > | | hcd_irq | hcd_irq | urb_enqueue | within 10 sec|
> > -------+------------------+---------------+---------------+--------------+--------------+
> > idle | 0.0% | 2 us | 16.5 us | 12 us | 5 |
> > FTDI | 25.0% | 8.5 us | 18.0 us | 31000 us | ~ 400 |
> > PL2303 | top doesn't work | 8.5 us | 22.5 us | 900000 us | 4 |
>
> It's hard to know for sure that all of this time is really in
> urb_enqueue(). Possible we could have task switched out and been
> blocked elsewhere. Using ftrace to get more fine-grained timings
> would be useful. ktime_get(), ktime_sub(), and ktime_to_us() are your
> friends here if you want to use trace_printk.
>
I saw your last reply after sending my last mail. I will go further with ftrace.
^ permalink raw reply
* [v4.9-rt PATCH] ARM: mm: remove tasklist locking from update_sections_early()
From: Grygorii Strashko @ 2017-04-18 20:48 UTC (permalink / raw)
To: linux-arm-kernel
The below backtrace can be observed on -rt kernel with CONFIG_DEBUG_RODATA
option enabled:
BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:993
in_atomic(): 1, irqs_disabled(): 128, pid: 14, name: migration/0
1 lock held by migration/0/14:
#0: (tasklist_lock){+.+...}, at: [<c01183e8>] update_sections_early+0x24/0xdc
irq event stamp: 38
hardirqs last enabled at (37): [<c08f6f7c>] _raw_spin_unlock_irq+0x24/0x68
hardirqs last disabled at (38): [<c01fdfe8>] multi_cpu_stop+0xd8/0x138
softirqs last enabled at (0): [<c01303ec>] copy_process.part.5+0x238/0x1b64
softirqs last disabled at (0): [< (null)>] (null)
Preemption disabled at: [<c01fe244>] cpu_stopper_thread+0x80/0x10c
CPU: 0 PID: 14 Comm: migration/0 Not tainted 4.9.21-rt16-02220-g49e319c #15
Hardware name: Generic DRA74X (Flattened Device Tree)
[<c0112014>] (unwind_backtrace) from [<c010d370>] (show_stack+0x10/0x14)
[<c010d370>] (show_stack) from [<c049beb8>] (dump_stack+0xa8/0xd4)
[<c049beb8>] (dump_stack) from [<c01631a0>] (___might_sleep+0x1bc/0x2ac)
[<c01631a0>] (___might_sleep) from [<c08f7244>] (__rt_spin_lock+0x1c/0x30)
[<c08f7244>] (__rt_spin_lock) from [<c08f77a4>] (rt_read_lock+0x54/0x68)
[<c08f77a4>] (rt_read_lock) from [<c01183e8>] (update_sections_early+0x24/0xdc)
[<c01183e8>] (update_sections_early) from [<c01184b0>] (__fix_kernmem_perms+0x10/0x1c)
[<c01184b0>] (__fix_kernmem_perms) from [<c01fe010>] (multi_cpu_stop+0x100/0x138)
[<c01fe010>] (multi_cpu_stop) from [<c01fe24c>] (cpu_stopper_thread+0x88/0x10c)
[<c01fe24c>] (cpu_stopper_thread) from [<c015edc4>] (smpboot_thread_fn+0x174/0x31c)
[<c015edc4>] (smpboot_thread_fn) from [<c015a988>] (kthread+0xf0/0x108)
[<c015a988>] (kthread) from [<c0108818>] (ret_from_fork+0x14/0x3c)
Freeing unused kernel memory: 1024K (c0d00000 - c0e00000)
The stop_machine() is called with cpus = NULL from fix_kernmem_perms() and
mark_rodata_ro() which means only one CPU will execute
update_sections_early() while all other CPUs will spin and wait. Hence,
it's safe to remove tasklist locking from update_sections_early(). As part of
this change also mark functions which are local to this module as static
to simplify code analize in the future.
Cc: Kees Cook <keescook@chromium.org>
Cc: Laura Abbott <labbott@redhat.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
arch/arm/mm/init.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 370581a..a77953a 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -693,30 +693,28 @@ static void update_sections_early(struct section_perm perms[], int n)
{
struct task_struct *t, *s;
- read_lock(&tasklist_lock);
for_each_process(t) {
if (t->flags & PF_KTHREAD)
continue;
for_each_thread(t, s)
set_section_perms(perms, n, true, s->mm);
}
- read_unlock(&tasklist_lock);
set_section_perms(perms, n, true, current->active_mm);
set_section_perms(perms, n, true, &init_mm);
}
-int __fix_kernmem_perms(void *unused)
+static int __fix_kernmem_perms(void *unused)
{
update_sections_early(nx_perms, ARRAY_SIZE(nx_perms));
return 0;
}
-void fix_kernmem_perms(void)
+static void fix_kernmem_perms(void)
{
stop_machine(__fix_kernmem_perms, NULL, NULL);
}
-int __mark_rodata_ro(void *unused)
+static int __mark_rodata_ro(void *unused)
{
update_sections_early(ro_perms, ARRAY_SIZE(ro_perms));
return 0;
--
2.10.1
^ permalink raw reply related
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Doug Anderson @ 2017-04-18 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <186569458.91967.1492547106553@email.1und1.de>
Stefan,
On Tue, Apr 18, 2017 at 1:25 PM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Hi,
>
> [add Johan]
>
>> Stefan Wahren <stefan.wahren@i2se.com> hat am 18. April 2017 um 10:07 geschrieben:
>>
>>
>> Am 18.04.2017 um 00:37 schrieb Doug Anderson:
>> > Hi,
>> >
>> > On Mon, Apr 17, 2017 at 4:05 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>> >> Hi,
>> >>
>> >>> Stefan Wahren <stefan.wahren@i2se.com> hat am 31. Oktober 2016 um 21:34 geschrieben:
>> >>>
>> >>>
>> >>> I inspired by this issue [1] i build up a slightly modified setup with a
>> >>> Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and 5 Prolific
>> >>> PL2303 USB to serial convertors. I modified the usb_test for dwc2 [2], which
>> >>> only tries to open all ttyUSB devices one after the other.
>> >>>
>> >>> Unfortunately the complete system stuck after opening the first ttyUSB device (
>> >>> heartbeat LED stop blinking, no reaction to debug UART). The only way to
>> >>> reanimate the system is to powerdown the USB hub with the USB to serial
>> >>> convertors.
>> >>>
>> >>> [1] - https://github.com/raspberrypi/linux/issues/1692
>> >>> [2] - https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b279dbaa
>> >> since this issue still exists with 4.11 (even without or with microframe scheduler enabled), i want to ask some additional questions:
>> >>
>> >> Is this issue reproducible with other dwc2 platforms than bcm2835?
>> > +Edmund Szeto, who I seem to remember emailing me about similar
>> > questions in the past.
>> >
>> >
>> >> Does the soft lockup also occurs after opening the second serial convertor or later?
>> > I don't have serial converters easily available to me, but back in the
>> > day when I was stressing things out on rk3288 I never saw anything
>> > this bad. ...of course, on rk3288 we've got 4 A17 cores running
>> > really fast, so possibly just being slower is what causes your
>> > problems here?
>>
>> The downstream kernel of the Raspberry Pi foundation with it's
>> out-of-tree dwc_otg driver is able to handle 8 serial converter on a RPI
>> B. I would be happy to get at least 2 or 3 working on mainline.
>>
>> >
>> > I will make the following observations:
>> >
>> > 1. With dwc2 you often end up in the situation where you need to
>> > service an interrupt every 125 uS. If servicing that interrupt takes
>> > anywhere near 125 uS in the common case then you'll be in trouble.
>>
>> I will try to measure this with a logic analyzer.
>>
>
> i took GPIO17 to measure _dwc2_hcd_irq and GPIO18 to measure _dwc2_hcd_urb_enqueue (patch against 4.11rc1 below).
>
> So i made my observations for 3 test cases:
>
> 1) no serial converter connected (idle)
> 2) 1 FTDI serial converter connected
> 3) 1 PL2303 serial converter connected
>
> case | ksoftirq cpu | mean duration | max duration | max duration | urb_enqueue |
> | | hcd_irq | hcd_irq | urb_enqueue | within 10 sec|
> -------+------------------+---------------+---------------+--------------+--------------+
> idle | 0.0% | 2 us | 16.5 us | 12 us | 5 |
> FTDI | 25.0% | 8.5 us | 18.0 us | 31000 us | ~ 400 |
> PL2303 | top doesn't work | 8.5 us | 22.5 us | 900000 us | 4 |
It's hard to know for sure that all of this time is really in
urb_enqueue(). Possible we could have task switched out and been
blocked elsewhere. Using ftrace to get more fine-grained timings
would be useful. ktime_get(), ktime_sub(), and ktime_to_us() are your
friends here if you want to use trace_printk.
> So it seems the serial USB driver has also an impact. In the analyzer trace the FTDI triggers many smaller urb_enqueue calls in the opposite to the PL2303 which only has few but huge calls.
>
> Additional notes:
> After closing the serial connection to the FTDI the system is usable as before. In case of PL2303 i need to disconnect the converter in order to get a usable system.
>
> Why do they behave so differently?
> Are these results of a overload?
> Doug, can you point me to your timing patch?
I did in the previous message, but basically take a look at:
https://chromium-review.googlesource.com/c/321980/4/drivers/usb/core/hcd.c#1668
I never posted this upstream since it was just a test patch.
>
> Thanks
> Stefan
>
> PS: My hacky patches for measuring
>
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 1a7e830..aa490c3 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -930,6 +930,9 @@ struct dwc2_hsotg {
> struct dentry *debug_root;
> struct debugfs_regset32 *regset;
>
> + int gpio_17;
> + int gpio_18;
> +
> /* DWC OTG HW Release versions */
> #define DWC2_CORE_REV_2_71a 0x4f54271a
> #define DWC2_CORE_REV_2_90a 0x4f54290a
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index a73722e..97271c8 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -45,6 +45,7 @@
> #include <linux/platform_device.h>
> #include <linux/dma-mapping.h>
> #include <linux/delay.h>
> +#include <linux/gpio.h>
> #include <linux/io.h>
> #include <linux/slab.h>
> #include <linux/usb.h>
> @@ -4595,13 +4596,17 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd, struct urb *urb,
> bool qh_allocated = false;
> struct dwc2_qtd *qtd;
>
> + gpio_set_value(hsotg->gpio_18, 1);
> +
> if (dbg_urb(urb)) {
> dev_vdbg(hsotg->dev, "DWC OTG HCD URB Enqueue\n");
> dwc2_dump_urb_info(hcd, urb, "urb_enqueue");
> }
>
> - if (!ep)
> + if (!ep) {
> + gpio_set_value(hsotg->gpio_18, 0);
> return -EINVAL;
> + }
>
> if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS ||
> usb_pipetype(urb->pipe) == PIPE_INTERRUPT) {
> @@ -4628,8 +4633,10 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd, struct urb *urb,
>
> dwc2_urb = dwc2_hcd_urb_alloc(hsotg, urb->number_of_packets,
> mem_flags);
> - if (!dwc2_urb)
> + if (!dwc2_urb) {
> + gpio_set_value(hsotg->gpio_18, 0);
> return -ENOMEM;
> + }
>
> dwc2_hcd_urb_set_pipeinfo(hsotg, dwc2_urb, usb_pipedevice(urb->pipe),
> usb_pipeendpoint(urb->pipe), ep_type,
> @@ -4705,6 +4712,8 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd, struct urb *urb,
>
> spin_unlock_irqrestore(&hsotg->lock, flags);
>
> + gpio_set_value(hsotg->gpio_18, 0);
> +
> return 0;
>
> fail3:
> @@ -4732,6 +4741,8 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd, struct urb *urb,
> fail0:
> kfree(dwc2_urb);
>
> + gpio_set_value(hsotg->gpio_18, 0);
> +
> return retval;
> }
>
> @@ -4825,8 +4836,15 @@ static void _dwc2_hcd_endpoint_reset(struct usb_hcd *hcd,
> static irqreturn_t _dwc2_hcd_irq(struct usb_hcd *hcd)
> {
> struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
> + irqreturn_t ret;
>
> - return dwc2_handle_hcd_intr(hsotg);
> + gpio_set_value(hsotg->gpio_17, 1);
> +
> + ret = dwc2_handle_hcd_intr(hsotg);
> +
> + gpio_set_value(hsotg->gpio_17, 0);
> +
> + return ret;
> }
>
> /*
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 9564bc7..e3f8a8a 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -35,6 +35,7 @@
> */
>
> #include <linux/kernel.h>
> +#include <linux/gpio.h>
> #include <linux/module.h>
> #include <linux/slab.h>
> #include <linux/clk.h>
> @@ -404,6 +405,16 @@ static int dwc2_driver_probe(struct platform_device *dev)
> return hsotg->irq;
> }
>
> + hsotg->gpio_17 = 475;
> + retval = devm_gpio_request_one(hsotg->dev, hsotg->gpio_17, GPIOF_OUT_INIT_LOW, "gpio_17");
> + if (retval)
> + pr_warn("Unable to request GPIO17: %d\n", retval);
> +
> + hsotg->gpio_18 = 476;
> + retval = devm_gpio_request_one(hsotg->dev, hsotg->gpio_18, GPIOF_OUT_INIT_LOW, "gpio_18");
> + if (retval)
> + pr_warn("Unable to request GPIO18: %d\n", retval);
> +
> dev_dbg(hsotg->dev, "registering common handler for irq%d\n",
> hsotg->irq);
> retval = devm_request_irq(hsotg->dev, hsotg->irq,
^ permalink raw reply
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Stefan Wahren @ 2017-04-18 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79b9b35b-0600-771f-4cd2-9e03c5ba3a25@i2se.com>
Hi,
[add Johan]
> Stefan Wahren <stefan.wahren@i2se.com> hat am 18. April 2017 um 10:07 geschrieben:
>
>
> Am 18.04.2017 um 00:37 schrieb Doug Anderson:
> > Hi,
> >
> > On Mon, Apr 17, 2017 at 4:05 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> >> Hi,
> >>
> >>> Stefan Wahren <stefan.wahren@i2se.com> hat am 31. Oktober 2016 um 21:34 geschrieben:
> >>>
> >>>
> >>> I inspired by this issue [1] i build up a slightly modified setup with a
> >>> Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and 5 Prolific
> >>> PL2303 USB to serial convertors. I modified the usb_test for dwc2 [2], which
> >>> only tries to open all ttyUSB devices one after the other.
> >>>
> >>> Unfortunately the complete system stuck after opening the first ttyUSB device (
> >>> heartbeat LED stop blinking, no reaction to debug UART). The only way to
> >>> reanimate the system is to powerdown the USB hub with the USB to serial
> >>> convertors.
> >>>
> >>> [1] - https://github.com/raspberrypi/linux/issues/1692
> >>> [2] - https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b279dbaa
> >> since this issue still exists with 4.11 (even without or with microframe scheduler enabled), i want to ask some additional questions:
> >>
> >> Is this issue reproducible with other dwc2 platforms than bcm2835?
> > +Edmund Szeto, who I seem to remember emailing me about similar
> > questions in the past.
> >
> >
> >> Does the soft lockup also occurs after opening the second serial convertor or later?
> > I don't have serial converters easily available to me, but back in the
> > day when I was stressing things out on rk3288 I never saw anything
> > this bad. ...of course, on rk3288 we've got 4 A17 cores running
> > really fast, so possibly just being slower is what causes your
> > problems here?
>
> The downstream kernel of the Raspberry Pi foundation with it's
> out-of-tree dwc_otg driver is able to handle 8 serial converter on a RPI
> B. I would be happy to get at least 2 or 3 working on mainline.
>
> >
> > I will make the following observations:
> >
> > 1. With dwc2 you often end up in the situation where you need to
> > service an interrupt every 125 uS. If servicing that interrupt takes
> > anywhere near 125 uS in the common case then you'll be in trouble.
>
> I will try to measure this with a logic analyzer.
>
i took GPIO17 to measure _dwc2_hcd_irq and GPIO18 to measure _dwc2_hcd_urb_enqueue (patch against 4.11rc1 below).
So i made my observations for 3 test cases:
1) no serial converter connected (idle)
2) 1 FTDI serial converter connected
3) 1 PL2303 serial converter connected
case | ksoftirq cpu | mean duration | max duration | max duration | urb_enqueue |
| | hcd_irq | hcd_irq | urb_enqueue | within 10 sec|
-------+------------------+---------------+---------------+--------------+--------------+
idle | 0.0% | 2 us | 16.5 us | 12 us | 5 |
FTDI | 25.0% | 8.5 us | 18.0 us | 31000 us | ~ 400 |
PL2303 | top doesn't work | 8.5 us | 22.5 us | 900000 us | 4 |
So it seems the serial USB driver has also an impact. In the analyzer trace the FTDI triggers many smaller urb_enqueue calls in the opposite to the PL2303 which only has few but huge calls.
Additional notes:
After closing the serial connection to the FTDI the system is usable as before. In case of PL2303 i need to disconnect the converter in order to get a usable system.
Why do they behave so differently?
Are these results of a overload?
Doug, can you point me to your timing patch?
Thanks
Stefan
PS: My hacky patches for measuring
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 1a7e830..aa490c3 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -930,6 +930,9 @@ struct dwc2_hsotg {
struct dentry *debug_root;
struct debugfs_regset32 *regset;
+ int gpio_17;
+ int gpio_18;
+
/* DWC OTG HW Release versions */
#define DWC2_CORE_REV_2_71a 0x4f54271a
#define DWC2_CORE_REV_2_90a 0x4f54290a
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index a73722e..97271c8 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -45,6 +45,7 @@
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
#include <linux/delay.h>
+#include <linux/gpio.h>
#include <linux/io.h>
#include <linux/slab.h>
#include <linux/usb.h>
@@ -4595,13 +4596,17 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd, struct urb *urb,
bool qh_allocated = false;
struct dwc2_qtd *qtd;
+ gpio_set_value(hsotg->gpio_18, 1);
+
if (dbg_urb(urb)) {
dev_vdbg(hsotg->dev, "DWC OTG HCD URB Enqueue\n");
dwc2_dump_urb_info(hcd, urb, "urb_enqueue");
}
- if (!ep)
+ if (!ep) {
+ gpio_set_value(hsotg->gpio_18, 0);
return -EINVAL;
+ }
if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS ||
usb_pipetype(urb->pipe) == PIPE_INTERRUPT) {
@@ -4628,8 +4633,10 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd, struct urb *urb,
dwc2_urb = dwc2_hcd_urb_alloc(hsotg, urb->number_of_packets,
mem_flags);
- if (!dwc2_urb)
+ if (!dwc2_urb) {
+ gpio_set_value(hsotg->gpio_18, 0);
return -ENOMEM;
+ }
dwc2_hcd_urb_set_pipeinfo(hsotg, dwc2_urb, usb_pipedevice(urb->pipe),
usb_pipeendpoint(urb->pipe), ep_type,
@@ -4705,6 +4712,8 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd, struct urb *urb,
spin_unlock_irqrestore(&hsotg->lock, flags);
+ gpio_set_value(hsotg->gpio_18, 0);
+
return 0;
fail3:
@@ -4732,6 +4741,8 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd, struct urb *urb,
fail0:
kfree(dwc2_urb);
+ gpio_set_value(hsotg->gpio_18, 0);
+
return retval;
}
@@ -4825,8 +4836,15 @@ static void _dwc2_hcd_endpoint_reset(struct usb_hcd *hcd,
static irqreturn_t _dwc2_hcd_irq(struct usb_hcd *hcd)
{
struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+ irqreturn_t ret;
- return dwc2_handle_hcd_intr(hsotg);
+ gpio_set_value(hsotg->gpio_17, 1);
+
+ ret = dwc2_handle_hcd_intr(hsotg);
+
+ gpio_set_value(hsotg->gpio_17, 0);
+
+ return ret;
}
/*
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 9564bc7..e3f8a8a 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -35,6 +35,7 @@
*/
#include <linux/kernel.h>
+#include <linux/gpio.h>
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/clk.h>
@@ -404,6 +405,16 @@ static int dwc2_driver_probe(struct platform_device *dev)
return hsotg->irq;
}
+ hsotg->gpio_17 = 475;
+ retval = devm_gpio_request_one(hsotg->dev, hsotg->gpio_17, GPIOF_OUT_INIT_LOW, "gpio_17");
+ if (retval)
+ pr_warn("Unable to request GPIO17: %d\n", retval);
+
+ hsotg->gpio_18 = 476;
+ retval = devm_gpio_request_one(hsotg->dev, hsotg->gpio_18, GPIOF_OUT_INIT_LOW, "gpio_18");
+ if (retval)
+ pr_warn("Unable to request GPIO18: %d\n", retval);
+
dev_dbg(hsotg->dev, "registering common handler for irq%d\n",
hsotg->irq);
retval = devm_request_irq(hsotg->dev, hsotg->irq,
^ permalink raw reply related
* [PATCH 2/2] hwmon: (brcmstb) Add driver for Broadcom STB DPFE
From: Markus Mayer @ 2017-04-18 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418201702.57019-1-code@mmayer.net>
From: Markus Mayer <mmayer@broadcom.com>
This driver allows access to DRAM properties, such as the refresh rate,
via the Broadcom STB DDR PHY Front End (DPFE). The refresh rate can be
used as indirect indicator of the DRAM temperature.
The driver also allows setting of the sampling interval.
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
---
MAINTAINERS | 8 +
drivers/hwmon/Kconfig | 13 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/brcmstb-dpfe.c | 689 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 711 insertions(+)
create mode 100644 drivers/hwmon/brcmstb-dpfe.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 676c139..d2d0495 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2825,6 +2825,14 @@ S: Maintained
F: Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt
F: drivers/cpufreq/brcmstb*
+BROADCOM STB DPFE HWMON DRIVER
+M: Markus Mayer <mmayer@broadcom.com>
+M: bcm-kernel-feedback-list at broadcom.com
+L: linux-hwmon at vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/hwmon/brcmstb*
+F: drivers/hwmon/brcmstb*
+
BROADCOM SPECIFIC AMBA DRIVER (BCMA)
M: Rafa? Mi?ecki <zajec5@gmail.com>
L: linux-wireless at vger.kernel.org
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 0649d53f3..54bb55c 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -355,6 +355,19 @@ config SENSORS_ATXP1
This driver can also be built as a module. If so, the module
will be called atxp1.
+config SENSORS_BRCMSTB_DPFE
+ tristate "BRCMSTB DPFE driver"
+ depends on ARCH_BRCMSTB
+ default y
+ help
+ If you say yes here you get support for the Broadcom set-top box
+ DDR PHY Front End (DPFE) interface.
+
+ The driver allows one to query the DRAM refresh rate, which in turn,
+ provides an indirect means for deriving the DRAM temperature.
+
+ If in doubt, say N.
+
config SENSORS_DS620
tristate "Dallas Semiconductor DS620"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 5509edf..cec13ec 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SENSORS_ATK0110) += asus_atk0110.o
# Native drivers
# asb100, then w83781d go first, as they can override other drivers' addresses.
obj-$(CONFIG_SENSORS_ASB100) += asb100.o
+obj-$(CONFIG_SENSORS_BRCMSTB_DPFE) += brcmstb-dpfe.o
obj-$(CONFIG_SENSORS_W83627HF) += w83627hf.o
obj-$(CONFIG_SENSORS_W83792D) += w83792d.o
obj-$(CONFIG_SENSORS_W83793) += w83793.o
diff --git a/drivers/hwmon/brcmstb-dpfe.c b/drivers/hwmon/brcmstb-dpfe.c
new file mode 100644
index 0000000..01abea8
--- /dev/null
+++ b/drivers/hwmon/brcmstb-dpfe.c
@@ -0,0 +1,689 @@
+/*
+ * Temperature sensor driver for Broadcom set top box SoCs
+ *
+ * Copyright (c) 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/firmware.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+#define DRVNAME "brcmstb-dpfe"
+#define FIRMWARE_NAME "dpfe.bin"
+#define DT_COMPAT_DMEM "brcm,dpfe-dmem"
+#define DT_COMPAT_IMEM "brcm,dpfe-imem"
+
+/* DCPU register offsets */
+#define REG_DCPU_RESET 0x0
+#define REG_TO_DCPU_MBOX 0x10
+#define REG_TO_HOST_MBOX 0x14
+
+/* Message RAM */
+#define DCPU_MSG_RAM(x) (0x100 + (x) * sizeof(u32))
+
+/* DRAM Info Offsets & Masks */
+#define DRAM_INFO_INTERVAL 0x0
+#define DRAM_INFO_MR4 0x4
+#define DRAM_INFO_ERROR 0x8
+#define DRAM_INFO_MASK 0xff
+
+/* DRAM MR4 Offsets & Masks */
+#define DRAM_MR4_REFRESH 0x0 /* Refresh rate */
+#define DRAM_MR4_SR_ABORT 0x3 /* Self Refresh Abort */
+#define DRAM_MR4_PPRE 0x4 /* Post-package repair entry/exit */
+#define DRAM_MR4_TH_OFFS 0x5 /* Thermal Offset; vendor specific */
+#define DRAM_MR4_TUF 0x7 /* Temperature Update Flag */
+
+#define DRAM_MR4_REFRESH_MASK 0x7
+#define DRAM_MR4_SR_ABORT_MASK 0x1
+#define DRAM_MR4_PPRE_MASK 0x1
+#define DRAM_MR4_TH_OFFS_MASK 0x3
+#define DRAM_MR4_TUF_MASK 0x1
+
+/* DRAM Vendor Offsets & Masks */
+#define DRAM_VENDOR_MR5 0x0
+#define DRAM_VENDOR_MR6 0x4
+#define DRAM_VENDOR_MR7 0x8
+#define DRAM_VENDOR_MR8 0xc
+#define DRAM_VENDOR_ERROR 0x10
+#define DRAM_VENDOR_MASK 0xff
+
+/* Reset register bits & masks */
+#define DCPU_RESET_SHIFT 0x0
+#define DCPU_RESET_MASK 0x1
+#define DCPU_CLK_DISABLE_SHIFT 0x2
+
+/* DCPU return codes */
+#define DCPU_RET_SUCCESS 0x00000001
+#define DCPU_RET_ERR_HEADER 0x80000001
+#define DCPU_RET_ERR_INVAL 0x80000002
+#define DCPU_RET_ERR_CHKSUM 0x80000004
+#define DCPU_RET_ERR_OTHER 0x80000008
+
+/* Firmware magic */
+#define DPFE_BE_MAGIC 0xfe1010fe
+#define DPFE_LE_MAGIC 0xfe0101fe
+
+/* Error codes */
+#define ERR_INVALID_MAGIC -1
+#define ERR_INVALID_SIZE -2
+#define ERR_INVALID_CHKSUM -3
+
+/* Message types */
+#define DPFE_MSG_TYPE_COMMAND 1
+#define DPFE_MSG_TYPE_RESPONSE 2
+
+#define DELAY_LOOP_MAX 200000
+
+enum dpfe_msg_fields {
+ MSG_HEADER,
+ MSG_COMMAND,
+ MSG_ARG_COUNT,
+ MSG_ARG0,
+ MSG_CHKSUM,
+ MSG_FIELD_MAX /* Last entry */
+};
+
+enum dpfe_commands {
+ DPFE_CMD_GET_INFO,
+ DPFE_CMD_GET_REFRESH,
+ DPFE_CMD_GET_VENDOR,
+ DPFE_CMD_MAX /* Last entry */
+};
+
+struct dpfe_msg {
+ u32 header;
+ u32 command;
+ u32 arg_count;
+ u32 arg0;
+ u32 chksum; /* This is the sum of all other entries. */
+};
+
+/*
+ * Format of the binary firmware file:
+ *
+ * entry
+ * 0 header
+ * value: 0xfe0101fe <== little endian
+ * 0xfe1010fe <== big endian
+ * 1 sequence:
+ * [31:16] total segments on this build
+ * [15:0] this segment sequence.
+ * 2 FW version
+ * 3 IMEM byte size
+ * 4 DMEM byte size
+ * IMEM
+ * DMEM
+ * last checksum ==> sum of everything
+ */
+struct dpfe_firmware_header {
+ u32 magic;
+ u32 sequence;
+ u32 version;
+ u32 imem_size;
+ u32 dmem_size;
+};
+
+/* Things we only need during initialization. */
+struct init_data {
+ void __iomem *dmem;
+ void __iomem *imem;
+ unsigned int dmem_len;
+ unsigned int imem_len;
+ unsigned int chksum;
+ bool is_big_endian;
+};
+
+/* Things we need for as long as we are active. */
+struct private_data {
+ void __iomem *regs;
+ void __iomem *dmem;
+ struct mutex lock;
+};
+
+/* List of supported firmware commands */
+const u32 dpfe_commands[DPFE_CMD_MAX][MSG_FIELD_MAX] = {
+ [DPFE_CMD_GET_INFO] = {
+ [MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
+ [MSG_COMMAND] = 1,
+ [MSG_ARG_COUNT] = 1,
+ [MSG_ARG0] = 1,
+ [MSG_CHKSUM] = 4,
+ },
+ [DPFE_CMD_GET_REFRESH] = {
+ [MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
+ [MSG_COMMAND] = 2,
+ [MSG_ARG_COUNT] = 1,
+ [MSG_ARG0] = 1,
+ [MSG_CHKSUM] = 5,
+ },
+ [DPFE_CMD_GET_VENDOR] = {
+ [MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
+ [MSG_COMMAND] = 2,
+ [MSG_ARG_COUNT] = 1,
+ [MSG_ARG0] = 2,
+ [MSG_CHKSUM] = 6,
+ },
+};
+
+static u32 dpfe_readl(const void __iomem *addr)
+{
+ return le32_to_cpu(readl_relaxed(addr));
+}
+
+static void dpfe_writel(u32 value, void __iomem *addr)
+{
+ writel_relaxed(cpu_to_le32(value), addr);
+}
+
+static void __iomem *__map_region(const char *name)
+{
+ struct device_node *np;
+ void __iomem *ptr;
+
+ np = of_find_compatible_node(NULL, NULL, name);
+ if (!np)
+ return NULL;
+
+ ptr = of_iomap(np, 0);
+ of_node_put(np);
+
+ return ptr;
+}
+
+static void __disable_dcpu(void __iomem *regs)
+{
+ u32 val;
+
+ /* Check if DCPU is running */
+ val = dpfe_readl(regs + REG_DCPU_RESET);
+ if (!(val & DCPU_RESET_MASK)) {
+ /* Put DCPU in reset */
+ val |= (1 << DCPU_RESET_SHIFT);
+ dpfe_writel(val, regs + REG_DCPU_RESET);
+ }
+}
+
+static void __enable_dcpu(void __iomem *regs)
+{
+ u32 val;
+
+ /* Clear mailbox registers. */
+ dpfe_writel(0, regs + REG_TO_DCPU_MBOX);
+ dpfe_writel(0, regs + REG_TO_HOST_MBOX);
+
+ /* Disable DCPU clock gating */
+ val = dpfe_readl(regs + REG_DCPU_RESET);
+ val &= ~(1 << DCPU_CLK_DISABLE_SHIFT);
+ dpfe_writel(val, regs + REG_DCPU_RESET);
+
+ /* Take DCPU out of reset */
+ val = dpfe_readl(regs + REG_DCPU_RESET);
+ val &= ~(1 << DCPU_RESET_SHIFT);
+ dpfe_writel(val, regs + REG_DCPU_RESET);
+}
+
+static unsigned int get_msg_chksum(const u32 msg[])
+{
+ unsigned int sum = 0;
+ unsigned int i;
+
+ /* Don't include the last field in the checksum. */
+ for (i = 0; i < MSG_FIELD_MAX - 1; i++)
+ sum += msg[i];
+
+ return sum;
+}
+
+static int __send_command(struct private_data *priv, unsigned int cmd,
+ u32 result[])
+{
+ const u32 *msg = dpfe_commands[cmd];
+ void __iomem *regs = priv->regs;
+ unsigned int i, chksum;
+ int ret = 0;
+ u32 resp;
+
+ if (cmd >= DPFE_CMD_MAX)
+ return -1;
+
+ mutex_lock(&priv->lock);
+
+ /* Write command and arguments to message area */
+ for (i = 0; i < MSG_FIELD_MAX; i++)
+ dpfe_writel(msg[i], regs + DCPU_MSG_RAM(i));
+
+ /* Tell DCPU there is a command waiting */
+ dpfe_writel(1, regs + REG_TO_DCPU_MBOX);
+
+ /* Wait for DCPU to process the command */
+ for (i = 0; i < DELAY_LOOP_MAX; i++) {
+ /* Read response code */
+ resp = dpfe_readl(regs + REG_TO_HOST_MBOX);
+ if (resp > 0)
+ break;
+ udelay(5);
+ }
+ if (i == DELAY_LOOP_MAX)
+ ret = -ETIMEDOUT;
+
+ /* Read response data */
+ for (i = 0; i < MSG_FIELD_MAX; i++)
+ result[i] = dpfe_readl(regs + DCPU_MSG_RAM(i));
+
+ /* Tell DCPU we are done */
+ dpfe_writel(0, regs + REG_TO_HOST_MBOX);
+
+ mutex_unlock(&priv->lock);
+
+ if (!ret) {
+ /* Verify response */
+ chksum = get_msg_chksum(result);
+ if (chksum != result[MSG_CHKSUM])
+ ret = -1;
+ }
+
+ if (!ret) {
+ switch (resp) {
+ case DCPU_RET_SUCCESS:
+ break;
+ case DCPU_RET_ERR_HEADER:
+ case DCPU_RET_ERR_INVAL:
+ case DCPU_RET_ERR_CHKSUM:
+ case DCPU_RET_ERR_OTHER:
+ ret = -1;
+ break;
+ }
+ }
+
+ return ret;
+}
+
+/* Ensure that the firmware file loaded meets all the requirements. */
+static int __verify_firmware(struct init_data *init,
+ const struct firmware *fw)
+{
+ const struct dpfe_firmware_header *header = (void *)fw->data;
+ unsigned int dmem_size, imem_size, total_size;
+ bool is_big_endian = false;
+ const u32 *chksum;
+
+ if (header->magic == DPFE_BE_MAGIC)
+ is_big_endian = true;
+ else if (header->magic != DPFE_LE_MAGIC)
+ return ERR_INVALID_MAGIC;
+
+ if (is_big_endian) {
+ dmem_size = be32_to_cpu(header->dmem_size);
+ imem_size = be32_to_cpu(header->imem_size);
+ } else {
+ dmem_size = header->dmem_size;
+ imem_size = header->imem_size;
+ }
+
+ /* Data and instruction sections are 32 bit words. */
+ if ((dmem_size % sizeof(u32)) != 0 || (imem_size % sizeof(u32)) != 0)
+ return ERR_INVALID_SIZE;
+
+ /*
+ * The header + the data section + the instruction section + the
+ * checksum must be equal to the total firmware size.
+ */
+ total_size = dmem_size + imem_size + sizeof(*header) + sizeof(*chksum);
+ if (total_size != fw->size)
+ return ERR_INVALID_SIZE;
+
+ /* The checksum comes at the very end. */
+ chksum = (void *)fw->data + sizeof(*header) + dmem_size + imem_size;
+
+ init->is_big_endian = is_big_endian;
+ init->dmem_len = dmem_size;
+ init->imem_len = imem_size;
+ init->chksum = (is_big_endian) ? be32_to_cpu(*chksum) : *chksum;
+
+ return 0;
+}
+
+/* Verify checksum by reading back the firmware from co-processor RAM. */
+static int __verify_fw_checksum(struct init_data *init,
+ const struct dpfe_firmware_header *header,
+ u32 checksum)
+{
+ u32 magic, sequence, version, sum;
+ u32 __iomem *dmem = init->dmem;
+ u32 __iomem *imem = init->imem;
+ unsigned int i;
+
+ if (init->is_big_endian) {
+ magic = be32_to_cpu(header->magic);
+ sequence = be32_to_cpu(header->sequence);
+ version = be32_to_cpu(header->version);
+ } else {
+ magic = header->magic;
+ sequence = header->sequence;
+ version = header->version;
+ }
+
+ sum = magic + sequence + version + init->dmem_len + init->imem_len;
+
+ for (i = 0; i < init->dmem_len / sizeof(u32); i++)
+ sum += dpfe_readl(dmem + i);
+
+ for (i = 0; i < init->imem_len / sizeof(u32); i++)
+ sum += dpfe_readl(imem + i);
+
+ return (sum == checksum) ? 0 : -1;
+}
+
+static int __write_firmware(u32 __iomem *mem, const u32 *fw,
+ unsigned int size, bool is_big_endian)
+{
+ unsigned int i;
+
+ /* Convert size to 32-bit words. */
+ size /= sizeof(u32);
+
+ /* It is recommended to clear the firmware area first. */
+ for (i = 0; i < size; i++)
+ dpfe_writel(0, mem + i);
+
+ /* Now copy it. */
+ if (is_big_endian) {
+ for (i = 0; i < size; i++)
+ dpfe_writel(be32_to_cpu(fw[i]), mem + i);
+ } else {
+ for (i = 0; i < size; i++)
+ dpfe_writel(fw[i], mem + i);
+ }
+
+ return 0;
+}
+
+static int brcmstb_hwmon_download_firwmare(struct platform_device *pdev,
+ struct init_data *init)
+{
+ const struct dpfe_firmware_header *header;
+ unsigned int dmem_size, imem_size;
+ struct device *dev = &pdev->dev;
+ bool is_big_endian = false;
+ struct private_data *priv;
+ const struct firmware *fw;
+ const u32 *dmem, *imem;
+ const void *fw_blob;
+ int ret;
+
+ ret = request_firmware(&fw, FIRMWARE_NAME, dev);
+ /* request_firmware() prints its own error messages. */
+ if (ret)
+ return ret;
+
+ priv = platform_get_drvdata(pdev);
+
+ ret = __verify_firmware(init, fw);
+ if (ret)
+ return -EFAULT;
+
+ __disable_dcpu(priv->regs);
+
+ is_big_endian = init->is_big_endian;
+ dmem_size = init->dmem_len;
+ imem_size = init->imem_len;
+
+ /* At the beginning of the firmware blob is a header. */
+ header = (struct dpfe_firmware_header *)fw->data;
+ /* Void pointer to the beginning of the actual firmware. */
+ fw_blob = fw->data + sizeof(*header);
+ /* IMEM comes right after the header. */
+ imem = fw_blob;
+ /* DMEM follows after IMEM. */
+ dmem = fw_blob + imem_size;
+
+ ret = __write_firmware(init->dmem, dmem, dmem_size, is_big_endian);
+ if (ret)
+ return ret;
+ ret = __write_firmware(init->imem, imem, imem_size, is_big_endian);
+ if (ret)
+ return ret;
+
+ ret = __verify_fw_checksum(init, header, init->chksum);
+ if (ret)
+ return ret;
+
+ __enable_dcpu(priv->regs);
+
+ return 0;
+}
+
+static ssize_t generic_show(unsigned int command, u32 response[],
+ struct device *dev, char *buf)
+{
+ struct private_data *priv;
+ int ret;
+
+ priv = dev_get_drvdata(dev);
+
+ ret = __send_command(priv, command, response);
+ if (ret)
+ return sprintf(buf, "error %d\n", ret);
+
+ return 0;
+}
+
+static ssize_t show_info(struct device *dev, struct device_attribute *devattr,
+ char *buf)
+{
+ u32 response[MSG_FIELD_MAX];
+ unsigned int info;
+ int ret;
+
+ ret = generic_show(DPFE_CMD_GET_INFO, response, dev, buf);
+ if (ret)
+ return ret;
+
+ info = response[MSG_ARG0];
+
+ return sprintf(buf, "%u.%u.%u.%u\n",
+ (info >> 24) & 0xff,
+ (info >> 16) & 0xff,
+ (info >> 8) & 0xff,
+ info & 0xff);
+}
+
+static ssize_t show_refresh(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ u32 response[MSG_FIELD_MAX];
+ void __iomem *info;
+ struct private_data *priv;
+ unsigned int offset;
+ u8 refresh, sr_abort, ppre, thermal_offs, tuf;
+ u32 mr4;
+ int ret;
+
+ ret = generic_show(DPFE_CMD_GET_REFRESH, response, dev, buf);
+ if (ret)
+ return ret;
+
+ priv = dev_get_drvdata(dev);
+ offset = response[MSG_ARG0];
+ info = priv->dmem + offset;
+
+ mr4 = dpfe_readl(info + DRAM_INFO_MR4) & DRAM_INFO_MASK;
+
+ refresh = (mr4 >> DRAM_MR4_REFRESH) & DRAM_MR4_REFRESH_MASK;
+ sr_abort = (mr4 >> DRAM_MR4_SR_ABORT) & DRAM_MR4_SR_ABORT_MASK;
+ ppre = (mr4 >> DRAM_MR4_PPRE) & DRAM_MR4_PPRE_MASK;
+ thermal_offs = (mr4 >> DRAM_MR4_TH_OFFS) & DRAM_MR4_TH_OFFS_MASK;
+ tuf = (mr4 >> DRAM_MR4_TUF) & DRAM_MR4_TUF_MASK;
+
+ return sprintf(buf, "%#x %#x %#x %#x %#x %#x %#x\n",
+ dpfe_readl(info + DRAM_INFO_INTERVAL),
+ refresh, sr_abort, ppre, thermal_offs, tuf,
+ dpfe_readl(info + DRAM_INFO_ERROR));
+}
+
+static ssize_t store_refresh(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ u32 response[MSG_FIELD_MAX];
+ struct private_data *priv;
+ void __iomem *info;
+ unsigned int offset;
+ unsigned long val;
+ int ret;
+
+ if (kstrtoul(buf, 0, &val) < 0)
+ return -EINVAL;
+
+ priv = dev_get_drvdata(dev);
+
+ ret = __send_command(priv, DPFE_CMD_GET_REFRESH, response);
+ if (ret)
+ return ret;
+
+ offset = response[MSG_ARG0];
+ info = priv->dmem + offset + DRAM_MR4_REFRESH;
+ dpfe_writel(val, info);
+
+ return count;
+}
+
+
+static ssize_t show_vendor(struct device *dev, struct device_attribute *devattr,
+ char *buf)
+{
+ u32 response[MSG_FIELD_MAX];
+ struct private_data *priv;
+ void __iomem *info;
+ unsigned int offset;
+ int ret;
+
+ ret = generic_show(DPFE_CMD_GET_VENDOR, response, dev, buf);
+ if (ret)
+ return ret;
+
+ offset = response[MSG_ARG0];
+ priv = dev_get_drvdata(dev);
+ info = priv->dmem + offset;
+
+ return sprintf(buf, "%#x %#x %#x %#x %#x\n",
+ dpfe_readl(info + DRAM_VENDOR_MR5) & DRAM_VENDOR_MASK,
+ dpfe_readl(info + DRAM_VENDOR_MR6) & DRAM_VENDOR_MASK,
+ dpfe_readl(info + DRAM_VENDOR_MR7) & DRAM_VENDOR_MASK,
+ dpfe_readl(info + DRAM_VENDOR_MR8) & DRAM_VENDOR_MASK,
+ dpfe_readl(info + DRAM_VENDOR_ERROR));
+}
+
+static SENSOR_DEVICE_ATTR(dpfe_info, 0444, show_info, NULL, 1000);
+static SENSOR_DEVICE_ATTR(dpfe_refresh, 0644, show_refresh, store_refresh,
+ 1000);
+static SENSOR_DEVICE_ATTR(dpfe_vendor, 0444, show_vendor, NULL, 1000);
+static struct attribute *dpfe_attrs[] = {
+ &sensor_dev_attr_dpfe_info.dev_attr.attr,
+ &sensor_dev_attr_dpfe_refresh.dev_attr.attr,
+ &sensor_dev_attr_dpfe_vendor.dev_attr.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(dpfe);
+
+static int brcmstb_hwmon_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device *hwmon_dev = NULL;
+ struct private_data *priv;
+ struct init_data init;
+ struct resource *res;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ mutex_init(&priv->lock);
+ platform_set_drvdata(pdev, priv);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(priv->regs)) {
+ dev_err(dev, "couldn't map DT entry brcm,dpfe-cpu\n");
+ return -ENODEV;
+ }
+
+ init.dmem = __map_region(DT_COMPAT_DMEM);
+ if (!init.dmem) {
+ dev_err(dev, "Couldn't map %s\n", DT_COMPAT_DMEM);
+ return -ENOENT;
+ }
+ init.imem = __map_region(DT_COMPAT_IMEM);
+ if (init.imem) {
+ ret = brcmstb_hwmon_download_firwmare(pdev, &init);
+ } else {
+ ret = -ENOENT;
+ dev_err(dev, "Couldn't map %s\n", DT_COMPAT_IMEM);
+ }
+
+ /* We don't need IMEM after initialization. */
+ iounmap(init.imem);
+
+ if (!ret) {
+ hwmon_dev = devm_hwmon_device_register_with_groups(dev,
+ "brcmstb_dpfe", priv, dpfe_groups);
+ if (IS_ERR(hwmon_dev))
+ ret = PTR_ERR(hwmon_dev);
+ }
+
+ if (ret) {
+ iounmap(init.dmem);
+ dev_err(dev, "failed to initialize -- error %d\n", ret);
+ } else {
+ priv->dmem = init.dmem;
+ dev_info(dev, "registered.\n");
+ }
+
+ return ret;
+}
+
+static int brcmstb_hwmon_remove(struct platform_device *pdev)
+{
+ struct private_data *priv;
+
+ priv = platform_get_drvdata(pdev);
+ iounmap(priv->dmem);
+
+ return 0;
+}
+
+static const struct of_device_id brcmstb_hwmon_of_match[] = {
+ { .compatible = "brcm,dpfe-cpu", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, brcmstb_hwmon_of_match);
+
+static struct platform_driver brcmstb_hwmon_driver = {
+ .driver = {
+ .name = DRVNAME,
+ .of_match_table = brcmstb_hwmon_of_match,
+ },
+ .probe = brcmstb_hwmon_probe,
+ .remove = brcmstb_hwmon_remove,
+};
+
+module_platform_driver(brcmstb_hwmon_driver);
+
+MODULE_AUTHOR("Markus Mayer <mmayer@broadcom.com>");
+MODULE_DESCRIPTION("BRCMSTB Hardware Monitoring");
+MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors
From: Markus Mayer @ 2017-04-18 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418201702.57019-1-code@mmayer.net>
From: Markus Mayer <mmayer@broadcom.com>
Provide bindings for the Broadcom STB DDR PHY Front End (DPFE).
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
---
.../devicetree/bindings/hwmon/brcmstb-dpfe.txt | 68 ++++++++++++++++++++++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
diff --git a/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt b/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
new file mode 100644
index 0000000..3519197
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
@@ -0,0 +1,68 @@
+DDR PHY Front End (DPFE) for Broadcom STB
+=========================================
+
+DPFE and the DPFE firmware provide an interface for the host CPU to
+communicate with the DCPU, which resides inside the DDR PHY.
+
+There are three memory regions for interacting with the DCPU.
+
+The DCPU Register Space
+-----------------------
+
+Required properties:
+ - compatible: must be one of brcm,bcm7271-dpfe-cpu, brcm,dpfe-cpu-v12.0.0.0
+ or brcm,dpfe-cpu
+ - reg: must reference the start address and length of the DCPU register
+ space
+
+Optional properties:
+ - cell-index: the index of the DPFE instance; will default to 0 if not set
+
+Example:
+ dpfe_cpu0: dpfe-cpu at f1132000 {
+ compatible = "brcm,bcm7271-dpfe-cpu",
+ "brcm,dpfe-cpu-v12.0.0.0",
+ "brcm,dpfe-cpu";
+ reg = <0xf1132000 0x180>;
+ cell-index = <0>;
+ };
+
+The DCPU Data Memory Space
+--------------------------
+
+Required properties:
+ - compatible: must be one of brcm,bcm7271-dpfe-dmem, brcm,dpfe-dmem-v12.0.0.0
+ or brcm,dpfe-dmem
+ - reg: must reference the start address and length of the DCPU DMEM space
+
+Optional properties:
+ - cell-index: the index of the DPFE instance; will default to 0 if not set
+
+Example:
+ dpfe_dmem0: dpfe-dmem at f1134000 {
+ compatible = "brcm,bcm7271-dpfe-dmem",
+ "brcm,dpfe-dmem-v12.0.0.0",
+ "brcm,dpfe-dmem";
+ reg = <0xf1134000 0x1000>;
+ cell-index = <0>;
+ };
+
+The DCPU Instruction Memory Space
+---------------------------------
+
+Required properties:
+ - compatible: must be one of brcm,bcm7271-dpfe-imem, brcm,dpfe-imem-v12.0.0.0
+ or brcm,dpfe-imem
+ - reg: must reference the start address and length of the DCPU IMEM space
+
+Optional properties:
+ - cell-index: the index of the DPFE instance; will default to 0 if not set
+
+Example:
+ dpfe_imem0: dpfe-imem at f1138000 {
+ compatible = "brcm,bcm7271-dpfe-imem",
+ "brcm,dpfe-imem-v12.0.0.0",
+ "brcm,dpfe-imem";
+ reg = <0xf1138000 0x4000>;
+ cell-index = <0>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] HWMON driver for Broadcom STB DPFE
From: Markus Mayer @ 2017-04-18 20:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Mayer <mmayer@broadcom.com>
This series introduces a driver to interact with the Broadcom STB DDR
PHY Front End (DPFE), specifically to communicate with the DCPU that is
part of the DDR PHY and which is running its own firmware.
The DCPU provides information such as DRAM refresh rate, which can be
used as indirect indicator for the DRAM temperature (the higher the
refresh rate, the hotter the RAM).
Markus Mayer (2):
dt/bindings: Add bindings for Broadcom STB DRAM Sensors
hwmon: (brcmstb) Add driver for Broadcom STB DPFE
.../devicetree/bindings/hwmon/brcmstb-dpfe.txt | 68 ++
MAINTAINERS | 8 +
drivers/hwmon/Kconfig | 13 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/brcmstb-dpfe.c | 689 +++++++++++++++++++++
5 files changed, 779 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
create mode 100644 drivers/hwmon/brcmstb-dpfe.c
--
2.7.4
^ permalink raw reply
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Doug Anderson @ 2017-04-18 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79b9b35b-0600-771f-4cd2-9e03c5ba3a25@i2se.com>
Hi,
On Tue, Apr 18, 2017 at 1:07 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>> 1. With dwc2 you often end up in the situation where you need to
>> service an interrupt every 125 uS. If servicing that interrupt takes
>> anywhere near 125 uS in the common case then you'll be in trouble.
>
> I will try to measure this with a logic analyzer.
Why a logic analyzer? I'd think that "ftrace" would be your friend
here. If you configure it just right you ought to be able to figure
out exactly what your kernel is doing.
...or, if you don't want to learn ftrace (it's cool and worth it, but
there's some time) you can just use "trace_printk" to get a fairly
low-over head printout to a memory buffer. You can put that printout
in various places in the code and figure out what's taking so long.
In fact, that's exactly how the patch at
<https://chromium-review.googlesource.com/c/321980/4/drivers/usb/core/hcd.c>
works.
-Doug
^ permalink raw reply
* [Query] Enabling parent device clock from resume_noirq
From: Grygorii Strashko @ 2017-04-18 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <62cd5ee0-3f0c-5e65-5f64-0c91a2a6f1e6@ti.com>
+ linux-pm
On 04/18/2017 01:07 AM, Kishon Vijay Abraham I wrote:
> Hi,
>
> resume_noirq callbacks are used in PCIe core to restore PCI state (this
> accesses PCI module). So the clocks of PCI module has to be enabled before
> resume_noirq.
>
> The clocks for the PCI module in DRA7xx is provided by PIPE3 PHY device which
> in turn gets it's clock from OCP2SCP device. During resume_noirq callbacks,
> pm_runtime is disabled, so pm_runtime_get_sync is ineffective. However
> pm_runtime can be enabled using pm_runtime_force_resume. Now the problem is
> adding pm_runtime_force_resume() in resume_noirq callback of pci-dra7xx driver
> will enable only the pm_runtime of PCI device but not PIPE3 PHY or OCP2SCP.
> Adding pm_runtime_force_resume() in resume_noirq callback of PIPE3 PHY driver
> or OCP2SCP driver will not help if the resume_noirq callbacks in PIP3PHY driver
> and OCP2SCP driver are invoked after the resume_noirq of pci-dra7xx driver.
>
> How to enable the pm_runtime of parent devices in resume_noirq callback? Does
> existing pm_runtime framework has support for that?
>
Most probably you've hit the issue described in [1].
In general, if pci-dra7xx is consumer of PIPE3 PHY device and
PIPE3 PHY device is child of OCP2SCP then suspend/resume order should be
- pci-dra7xx
- PIPE3 PHY
- OCP2SCP
and resume
- OCP2SCP
- PIPE3 PHY
- pci-dra7xx
and in this case pm_runtime_force_x() might work.
Hence, approach [1] was not accepted (personally I still like it) and
"Functional dependencies tracking support" was introduced instead by commit 9ed9895 [2]
you can try it.
But, as per code, I'm not sure that Functional dependencies properly tracked in
pm_runtime_force_x() functions.
PS: you can try to reorder device's nodes in DT and place PCI node after "ocp2scp" :P
[1] "driver core: Ensure proper suspend/resume ordering"
https://patchwork.kernel.org/patch/7153201/
[2] https://patchwork.kernel.org/patch/9404547/
--
regards,
-grygorii
^ permalink raw reply
* [PATCH] fs: Preventing READ_IMPLIES_EXEC Propagation
From: Peter Maydell @ 2017-04-18 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418170118.GH27592@e104818-lin.cambridge.arm.com>
On 18 April 2017 at 18:01, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Thu, Apr 13, 2017 at 08:33:52PM +0800, dongbo (E) wrote:
>> From: Dong Bo <dongbo4@huawei.com>
>>
>> In load_elf_binary(), once the READ_IMPLIES_EXEC flag is set,
>> the flag is propagated to its child processes, even the elf
>> files are marked as not requiring executable stack. It may
>> cause superfluous operations on some arch, e.g.
>> __sync_icache_dcache on aarch64 due to a PROT_READ mmap is
>> also marked as PROT_EXEC.
> That's affecting most architectures with a risk of ABI breakage. We
> could do it on arm64 only, though I'm not yet clear on the ABI
> implications (at a first look, there shouldn't be any).
Is there a reason why it isn't just straightforwardly a bug
(which we could fix) to make READ_IMPLIES_EXEC propagate to
child processes? AFAICT this should be per-process: just because
init happens not to have been (re)compiled to permit non-executable
stacks doesn't mean every process on the system needs to have
an executable stack. Behaviour shouldn't be variable across
architectures either, I would hope.
thanks
-- PMM
^ permalink raw reply
* [GIT PULL] bcm2835-dt-next-2017-03-30
From: Florian Fainelli @ 2017-04-18 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418195452.prp2ortwv7u3hfok@tarshish>
On 04/18/2017 12:54 PM, Baruch Siach wrote:
> Hi Eric, Florian,
>
> On Thu, Mar 30, 2017 at 12:13:43PM -0700, Eric Anholt wrote:
>> Here's the pull request for those changes I'd misplaced from 4.11.
>> This may be my last PR of the cycle. The only change I have left on
>> my radar for 4.12 is
>> http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-March/006097.html
>
> Any chance of getting these fixes into 4.12-rc1?
I will merge Eric's PR in the next few days, and we'll see from there.
>
> Thanks,
> baruch
>
>>
>> The following changes since commit 7f31a955a0c34de0463f7ff50b2bd62a5cce4204:
>>
>> ARM: dts: bcm2835: add sdhost controller to devicetree (2017-03-17 17:35:50 -0700)
>>
>> are available in the git repository at:
>>
>> git://github.com/anholt/linux tags/bcm2835-dt-next-2017-03-30
>>
>> for you to fetch changes up to 10b6c0c2e2bb8cd1be682f8d36ef597e3419cb88:
>>
>> ARM: dts: bcm2835: add index to the ethernet alias (2017-03-27 10:10:39 -0700)
>>
>> ----------------------------------------------------------------
>> This pull request brings back bcm2835 DT fixups from Baruch Siach that
>> got misplaced after a PR for 4.11 got rejected.
>>
>> ----------------------------------------------------------------
>> Baruch Siach (4):
>> ARM: dts: bcm2835: fix uart0 pinctrl node names
>> ARM: dts: bcm2835: fix i2c0 pins
>> ARM: dts: bcm2835: fix uart0/uart1 pins
>> ARM: dts: bcm2835: add index to the ethernet alias
>>
>> arch/arm/boot/dts/bcm283x-rpi-smsc9512.dtsi | 2 +-
>> arch/arm/boot/dts/bcm283x-rpi-smsc9514.dtsi | 2 +-
>> arch/arm/boot/dts/bcm283x.dtsi | 22 +++++++++++++---------
>> 3 files changed, 15 insertions(+), 11 deletions(-)
>
--
Florian
^ permalink raw reply
* [PATCH v2 net-next] drivers: net: xgene-v2: Extend ethtool statistics
From: David Miller @ 2017-04-18 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492472875-32385-1-git-send-email-isubramanian@apm.com>
From: Iyappan Subramanian <isubramanian@apm.com>
Date: Mon, 17 Apr 2017 16:47:55 -0700
> This patch adds extended statistics reporting to ethtool.
>
> In summary, this patch,
>
> - adds ethtool.h with the statistics register definitions
> - adds 'struct xge_gstrings_extd_stats' to gather extended stats
> - modifies xge_get_strings(), get_sset_count() and
> get_ethtool_stats() accordingly
> - moves 'struct xge_gstrings_stats' to ethtool.h
>
> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Applied, thanks.
^ permalink raw reply
* [GIT PULL] bcm2835-dt-next-2017-03-30
From: Baruch Siach @ 2017-04-18 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170330191343.31647-1-eric@anholt.net>
Hi Eric, Florian,
On Thu, Mar 30, 2017 at 12:13:43PM -0700, Eric Anholt wrote:
> Here's the pull request for those changes I'd misplaced from 4.11.
> This may be my last PR of the cycle. The only change I have left on
> my radar for 4.12 is
> http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-March/006097.html
Any chance of getting these fixes into 4.12-rc1?
Thanks,
baruch
>
> The following changes since commit 7f31a955a0c34de0463f7ff50b2bd62a5cce4204:
>
> ARM: dts: bcm2835: add sdhost controller to devicetree (2017-03-17 17:35:50 -0700)
>
> are available in the git repository at:
>
> git://github.com/anholt/linux tags/bcm2835-dt-next-2017-03-30
>
> for you to fetch changes up to 10b6c0c2e2bb8cd1be682f8d36ef597e3419cb88:
>
> ARM: dts: bcm2835: add index to the ethernet alias (2017-03-27 10:10:39 -0700)
>
> ----------------------------------------------------------------
> This pull request brings back bcm2835 DT fixups from Baruch Siach that
> got misplaced after a PR for 4.11 got rejected.
>
> ----------------------------------------------------------------
> Baruch Siach (4):
> ARM: dts: bcm2835: fix uart0 pinctrl node names
> ARM: dts: bcm2835: fix i2c0 pins
> ARM: dts: bcm2835: fix uart0/uart1 pins
> ARM: dts: bcm2835: add index to the ethernet alias
>
> arch/arm/boot/dts/bcm283x-rpi-smsc9512.dtsi | 2 +-
> arch/arm/boot/dts/bcm283x-rpi-smsc9514.dtsi | 2 +-
> arch/arm/boot/dts/bcm283x.dtsi | 22 +++++++++++++---------
> 3 files changed, 15 insertions(+), 11 deletions(-)
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* arm64: Question about warnings due to unspecified ASM operand width
From: Ard Biesheuvel @ 2017-04-18 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418192317.GC128305@google.com>
On 18 April 2017 at 20:23, Matthias Kaehlcke <mka@chromium.org> wrote:
> Hoi Ard,
>
> Thanks for your reply!
>
> El Tue, Apr 18, 2017 at 03:29:39PM +0100 Ard Biesheuvel ha dit:
>
>> On 18 April 2017 at 02:31, Matthias Kaehlcke <mka@chromium.org> wrote:
>> > Hi,
>> >
>> > During my work on improving support for kernel builds with clang I
>> > came across a bunch of warnings on arm64 builds about the width of
>> > operands in assembly not being specified:
>> >
>> > arch/arm64/include/asm/arch_timer.h:92:46: error: value size does
>> > not match register size specified by the constraint and modifier [-Werror,-Wasm-operand-widths]
>> > asm volatile("mrs %0, cntfrq_el0" : "=r" (val));
>> >
>> > I understand that this is usually not a problem and might even be
>> > desired to give the compiler more flexiblity in the use of the
>> > available registers.
>> >
>> > My goal is to eventually build the kernel without warnings, not
>> > necessarily fixing all of them, warnings can also be disabled, e.g.
>> > in case of spurious warnings or a high number of occurrences that is
>> > too expensive to fix.
>> >
>> > Before delving into 'fixing' these 'asm-operand-widths' warnings I'd
>> > be interested to know if this is actually desirable or if it is
>> > preferred to keep the operand width unspecified in certain cases.
>> >
>>
>>
>> The root cause is that Clang infers the size of the register from the
>> size of the operand, while GCC always uses an xN register for a %
>> placeholder.
>>
>> With msr/mrs instructions, we can only use xN registers
>
> Good to know, thanks!
>
>> and so the only way to fix this is to ensure that we always use
>> 64-bit operands even for 32-bit system registers. This may be
>> possible in most cases, but assigning 32-bit struct fields becomes a
>> bit painful this way, and 'fixing' what is arguably not broken to
>> begin with may not be something Catalin is eager to accept.
>
> I'm not sure this would be an issue. Clang does not warn about 32-bit
> operands used with 64-bit registers, but about the register type not
> being specified at all. I think we should be fine with specifying xN
> registers for msr/mrs instructions.
>
It appears this was actually fixed in Clang. Formerly, it would
implicitly use %w for 32-bit operands, which breaks if the
instructions (such as msr/mrs, but there are more) don't support it.
Now it uses x registers for unqualified placeholders, and only issues a warning.
So we'd need to update all templates to use explicit qualifiers. I
don't think that should be a problem for anyone.
^ 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