* [PATCH v3 0/5] Cavium ThunderX uncore PMU support
From: Peter Zijlstra @ 2016-10-20 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020104417.GD10234@leverpostej>
On Thu, Oct 20, 2016 at 11:44:18AM +0100, Mark Rutland wrote:
> On Thu, Oct 20, 2016 at 12:37:07PM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 20, 2016 at 11:30:36AM +0200, Jan Glauber wrote:
> > > Note:
> > > I'm using perf_sw_context in difference to perf_invalid_context
> > > (see WARN_ON in perf_pmu_register). Reason is that with perf_invalid_context
> > > add() is never called and the counter results are shown as "unsupported" by
> > > perf. With perf_sw_context everything works as expected.
> >
> > What?! All the uncore PMUs use perf_invalid_context. What doesn't work
> > for you?
>
> I think there's general confusion over the use of invalid context.
> Perhaps we could clear that up with:
>
> #define perf_uncore_context perf_invalid_context
>
> and
>
> s/perf_hw_context/perf_cpu_hw_context/
What might be missing is the fact that these are _TASK_ contexts.
New names might clarify things a little though.
^ permalink raw reply
* [PATCH v3 0/5] Cavium ThunderX uncore PMU support
From: Mark Rutland @ 2016-10-20 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020105501.GU3102@twins.programming.kicks-ass.net>
On Thu, Oct 20, 2016 at 12:55:01PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 20, 2016 at 11:44:18AM +0100, Mark Rutland wrote:
> > I think there's general confusion over the use of invalid context.
> > Perhaps we could clear that up with:
> >
> > #define perf_uncore_context perf_invalid_context
> >
> > and
> >
> > s/perf_hw_context/perf_cpu_hw_context/
>
> What might be missing is the fact that these are _TASK_ contexts.
Yes, that too.
> New names might clarify things a little though.
I'll add that to the list of cleanup/rework I've been meaning to look
at.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 0/5] Cavium ThunderX uncore PMU support
From: Jan Glauber @ 2016-10-20 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020103707.GB3175@twins.programming.kicks-ass.net>
On Thu, Oct 20, 2016 at 12:37:07PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 20, 2016 at 11:30:36AM +0200, Jan Glauber wrote:
> > Note:
> > I'm using perf_sw_context in difference to perf_invalid_context
> > (see WARN_ON in perf_pmu_register). Reason is that with perf_invalid_context
> > add() is never called and the counter results are shown as "unsupported" by
> > perf. With perf_sw_context everything works as expected.
>
> What?! All the uncore PMUs use perf_invalid_context. What doesn't work
> for you?
As I said, perf reports the values as "unsupported". But as Mark pointed
out, I wasn't using -a switch, just "perf stat -e \thunderx_lmc\blah\ -- ...".
^ permalink raw reply
* [PATCH] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1
From: Rameshwar Prasad Sahu @ 2016-10-20 11:14 UTC (permalink / raw)
To: linux-arm-kernel
This patch enables NCQ support for APM X-Gene SATA controller
hardware v1.1 that was broken with hardware v1.0.
Signed-off-by: Rameshwar Prasad Sahu <rsahu@apm.com>
---
drivers/ata/ahci_xgene.c | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 73b19b2..8b88be9 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -87,6 +87,7 @@
enum xgene_ahci_version {
XGENE_AHCI_V1 = 1,
+ XGENE_AHCI_V1_1,
XGENE_AHCI_V2,
};
@@ -734,6 +735,7 @@ static struct scsi_host_template ahci_platform_sht = {
#ifdef CONFIG_ACPI
static const struct acpi_device_id xgene_ahci_acpi_match[] = {
{ "APMC0D0D", XGENE_AHCI_V1},
+ { "APMC0D67", XGENE_AHCI_V1_1},
{ "APMC0D32", XGENE_AHCI_V2},
{},
};
@@ -742,6 +744,7 @@ MODULE_DEVICE_TABLE(acpi, xgene_ahci_acpi_match);
static const struct of_device_id xgene_ahci_of_match[] = {
{.compatible = "apm,xgene-ahci", .data = (void *) XGENE_AHCI_V1},
+ {.compatible = "apm,xgene-ahci-v1-1", .data = (void *) XGENE_AHCI_V1_1},
{.compatible = "apm,xgene-ahci-v2", .data = (void *) XGENE_AHCI_V2},
{},
};
@@ -755,8 +758,7 @@ static int xgene_ahci_probe(struct platform_device *pdev)
struct resource *res;
const struct of_device_id *of_devid;
enum xgene_ahci_version version = XGENE_AHCI_V1;
- const struct ata_port_info *ppi[] = { &xgene_ahci_v1_port_info,
- &xgene_ahci_v2_port_info };
+ const struct ata_port_info *ppi;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device *pdev)
dev_warn(&pdev->dev, "%s: Error reading device info. Assume version1\n",
__func__);
version = XGENE_AHCI_V1;
- } else if (info->valid & ACPI_VALID_CID) {
- version = XGENE_AHCI_V2;
}
}
}
@@ -858,18 +858,20 @@ skip_clk_phy:
switch (version) {
case XGENE_AHCI_V1:
+ ppi = &xgene_ahci_v1_port_info;
hpriv->flags = AHCI_HFLAG_NO_NCQ;
break;
case XGENE_AHCI_V2:
+ ppi = &xgene_ahci_v2_port_info;
hpriv->flags |= AHCI_HFLAG_YES_FBS;
hpriv->irq_handler = xgene_ahci_irq_intr;
break;
default:
+ ppi = &xgene_ahci_v1_port_info;
break;
}
- rc = ahci_platform_init_host(pdev, hpriv, ppi[version - 1],
- &ahci_platform_sht);
+ rc = ahci_platform_init_host(pdev, hpriv, ppi, &ahci_platform_sht);
if (rc)
goto disable_resources;
--
1.7.1
^ permalink raw reply related
* [PATCH v2 0/3] efi: add support for seeding the kernel RNG from UEFI
From: Ard Biesheuvel @ 2016-10-20 11:21 UTC (permalink / raw)
To: linux-arm-kernel
This implements generic EFI core kernel code to seed the kernel entropy
pool from a Linux specific UEFI configuration table containing a random seed
supplied by the firmware. (#1)
In addition, it wires it up for ARM and arm64, by invoking the EFI_RNG_PROTOCOL
UEFI protocol from the stub, and populating such a UEFI config table using its
output.
Changes since v1:
- Add a patch to actually build random.c for the ARM version of the stub, so
that the functionality that patch #3 adds is available on ARM as well as arm64
- Handle the kexec case, by updating the seed in the configuration table on
reboot.
How to wire this up for x86 is left as an exercise for the Intel developer.
Ard Biesheuvel (3):
efi: add support for seeding the RNG from a UEFI config table
efi/libstub: add random.c to ARM build
efi/arm*: libstub: invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table
drivers/firmware/efi/efi.c | 67 ++++++++++++++++++++
drivers/firmware/efi/libstub/Makefile | 4 +-
drivers/firmware/efi/libstub/arm-stub.c | 2 +
drivers/firmware/efi/libstub/efi-stub-helper.c | 9 ---
drivers/firmware/efi/libstub/efistub.h | 11 ++++
drivers/firmware/efi/libstub/random.c | 48 ++++++++++++++
include/linux/efi.h | 9 +++
7 files changed, 139 insertions(+), 11 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/3] efi: add support for seeding the RNG from a UEFI config table
From: Ard Biesheuvel @ 2016-10-20 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476962486-18368-1-git-send-email-ard.biesheuvel@linaro.org>
Specify a Linux specific UEFI configuration table that carries some
random bits, and use the contents during early boot to seed the kernel's
random number generator. This allows much strong random numbers to be
generated early on.
The entropy is fed to the kernel using add_device_randomness(), which is
documented as being appropriate for being called very early.
Since UEFI configuration tables may also be consumed by kexec'd kernels,
register a reboot notifier that updates the seed in the table.
Note that the config table could be generated by the EFI stub or by any
other UEFI driver or application (e.g., GRUB), but the random seed table
GUID and the associated functionality should be considered an internal
kernel interface (unless it is promoted to ABI later on)
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/efi.c | 67 ++++++++++++++++++++
include/linux/efi.h | 8 +++
2 files changed, 75 insertions(+)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 1ac199cd75e7..47937ffd9f2f 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -24,6 +24,8 @@
#include <linux/of_fdt.h>
#include <linux/io.h>
#include <linux/platform_device.h>
+#include <linux/random.h>
+#include <linux/reboot.h>
#include <linux/slab.h>
#include <linux/acpi.h>
#include <linux/ucs2_string.h>
@@ -48,6 +50,7 @@ struct efi __read_mostly efi = {
.esrt = EFI_INVALID_TABLE_ADDR,
.properties_table = EFI_INVALID_TABLE_ADDR,
.mem_attr_table = EFI_INVALID_TABLE_ADDR,
+ .rng_seed = EFI_INVALID_TABLE_ADDR,
};
EXPORT_SYMBOL(efi);
@@ -438,6 +441,7 @@ static __initdata efi_config_table_type_t common_tables[] = {
{EFI_SYSTEM_RESOURCE_TABLE_GUID, "ESRT", &efi.esrt},
{EFI_PROPERTIES_TABLE_GUID, "PROP", &efi.properties_table},
{EFI_MEMORY_ATTRIBUTES_TABLE_GUID, "MEMATTR", &efi.mem_attr_table},
+ {LINUX_EFI_RANDOM_SEED_TABLE_GUID, "RNG", &efi.rng_seed},
{NULL_GUID, NULL, NULL},
};
@@ -499,6 +503,29 @@ int __init efi_config_parse_tables(void *config_tables, int count, int sz,
pr_cont("\n");
set_bit(EFI_CONFIG_TABLES, &efi.flags);
+ if (efi.rng_seed != EFI_INVALID_TABLE_ADDR) {
+ struct linux_efi_random_seed *seed;
+ u32 size = 0;
+
+ seed = early_memremap(efi.rng_seed, sizeof(*seed));
+ if (seed != NULL) {
+ size = seed->size;
+ early_memunmap(seed, sizeof(*seed));
+ } else {
+ pr_err("Could not map UEFI random seed!\n");
+ }
+ if (size > 0) {
+ seed = early_memremap(efi.rng_seed,
+ sizeof(*seed) + size);
+ if (seed != NULL) {
+ add_device_randomness(seed->bits, seed->size);
+ early_memunmap(seed, sizeof(*seed) + size);
+ } else {
+ pr_err("Could not map UEFI random seed!\n");
+ }
+ }
+ }
+
/* Parse the EFI Properties table if it exists */
if (efi.properties_table != EFI_INVALID_TABLE_ADDR) {
efi_properties_table_t *tbl;
@@ -822,3 +849,43 @@ int efi_status_to_err(efi_status_t status)
return err;
}
+
+#ifdef CONFIG_KEXEC
+static int update_efi_random_seed(struct notifier_block *nb,
+ unsigned long code, void *unused)
+{
+ struct linux_efi_random_seed *seed;
+ u32 size = 0;
+
+ seed = memremap(efi.rng_seed, sizeof(*seed), MEMREMAP_WB);
+ if (seed != NULL) {
+ size = seed->size;
+ memunmap(seed);
+ } else {
+ pr_err("Could not map UEFI random seed!\n");
+ }
+ if (size > 0) {
+ seed = memremap(efi.rng_seed, sizeof(*seed) + size,
+ MEMREMAP_WB);
+ if (seed != NULL) {
+ get_random_bytes(seed->bits, seed->size);
+ memunmap(seed);
+ } else {
+ pr_err("Could not map UEFI random seed!\n");
+ }
+ }
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block efi_random_seed_nb = {
+ .notifier_call = update_efi_random_seed,
+};
+
+static int register_update_efi_random_seed(void)
+{
+ if (efi.rng_seed == EFI_INVALID_TABLE_ADDR)
+ return 0;
+ return register_reboot_notifier(&efi_random_seed_nb);
+}
+late_initcall(register_update_efi_random_seed);
+#endif
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 2d089487d2da..85e28b138cdd 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -599,6 +599,7 @@ void efi_native_runtime_setup(void);
*/
#define LINUX_EFI_ARM_SCREEN_INFO_TABLE_GUID EFI_GUID(0xe03fc20a, 0x85dc, 0x406e, 0xb9, 0x0e, 0x4a, 0xb5, 0x02, 0x37, 0x1d, 0x95)
#define LINUX_EFI_LOADER_ENTRY_GUID EFI_GUID(0x4a67b082, 0x0a4c, 0x41cf, 0xb6, 0xc7, 0x44, 0x0b, 0x29, 0xbb, 0x8c, 0x4f)
+#define LINUX_EFI_RANDOM_SEED_TABLE_GUID EFI_GUID(0x1ce1e5bc, 0x7ceb, 0x42f2, 0x81, 0xe5, 0x8a, 0xad, 0xf1, 0x80, 0xf5, 0x7b)
typedef struct {
efi_guid_t guid;
@@ -872,6 +873,7 @@ extern struct efi {
unsigned long esrt; /* ESRT table */
unsigned long properties_table; /* properties table */
unsigned long mem_attr_table; /* memory attributes table */
+ unsigned long rng_seed; /* UEFI firmware random seed */
efi_get_time_t *get_time;
efi_set_time_t *set_time;
efi_get_wakeup_time_t *get_wakeup_time;
@@ -1493,4 +1495,10 @@ efi_status_t efi_exit_boot_services(efi_system_table_t *sys_table,
struct efi_boot_memmap *map,
void *priv,
efi_exit_boot_map_processing priv_func);
+
+struct linux_efi_random_seed {
+ u32 size;
+ u8 bits[];
+};
+
#endif /* _LINUX_EFI_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] efi/libstub: add random.c to ARM build
From: Ard Biesheuvel @ 2016-10-20 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476962486-18368-1-git-send-email-ard.biesheuvel@linaro.org>
Make random.c build for ARM by moving the fallback definition of
EFI_ALLOC_ALIGN to efistub.h
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/libstub/Makefile | 4 ++--
drivers/firmware/efi/libstub/efi-stub-helper.c | 9 ---------
drivers/firmware/efi/libstub/efistub.h | 9 +++++++++
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index c06945160a41..40ddf8f763a8 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -36,11 +36,11 @@ arm-deps := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c sort.c
$(obj)/lib-%.o: $(srctree)/lib/%.c FORCE
$(call if_changed_rule,cc_o_c)
-lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o string.o \
+lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o string.o random.o \
$(patsubst %.c,lib-%.o,$(arm-deps))
lib-$(CONFIG_ARM) += arm32-stub.o
-lib-$(CONFIG_ARM64) += arm64-stub.o random.o
+lib-$(CONFIG_ARM64) += arm64-stub.o
CFLAGS_arm64-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
#
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c b/drivers/firmware/efi/libstub/efi-stub-helper.c
index aded10662020..3c2fe209bbfe 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -32,15 +32,6 @@
static unsigned long __chunk_size = EFI_READ_CHUNK_SIZE;
-/*
- * Allow the platform to override the allocation granularity: this allows
- * systems that have the capability to run with a larger page size to deal
- * with the allocations for initrd and fdt more efficiently.
- */
-#ifndef EFI_ALLOC_ALIGN
-#define EFI_ALLOC_ALIGN EFI_PAGE_SIZE
-#endif
-
#define EFI_MMAP_NR_SLACK_SLOTS 8
struct file_info {
diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index ee49cd23ee63..fe1f22584c69 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -15,6 +15,15 @@
*/
#undef __init
+/*
+ * Allow the platform to override the allocation granularity: this allows
+ * systems that have the capability to run with a larger page size to deal
+ * with the allocations for initrd and fdt more efficiently.
+ */
+#ifndef EFI_ALLOC_ALIGN
+#define EFI_ALLOC_ALIGN EFI_PAGE_SIZE
+#endif
+
void efi_char16_printk(efi_system_table_t *, efi_char16_t *);
efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg, void *__image,
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] efi/arm*: libstub: invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table
From: Ard Biesheuvel @ 2016-10-20 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476962486-18368-1-git-send-email-ard.biesheuvel@linaro.org>
Invoke the EFI_RNG_PROTOCOL protocol in the context of the stub and
install the Linux-specific RNG seed UEFI config table. This will be
picked up by the EFI routines in the core kernel to seed the kernel
entropy pool.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/libstub/arm-stub.c | 2 +
drivers/firmware/efi/libstub/efistub.h | 2 +
drivers/firmware/efi/libstub/random.c | 48 ++++++++++++++++++++
include/linux/efi.h | 1 +
4 files changed, 53 insertions(+)
diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c
index 993aa56755f6..b4f7d78f9e8b 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -340,6 +340,8 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
if (status != EFI_SUCCESS)
pr_efi_err(sys_table, "Failed initrd from command line!\n");
+ efi_random_get_seed(sys_table);
+
new_fdt_addr = fdt_addr;
status = allocate_new_fdt_and_exit_boot(sys_table, handle,
&new_fdt_addr, dram_base + MAX_FDT_OFFSET,
diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index fe1f22584c69..b98824e3800a 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -71,4 +71,6 @@ efi_status_t efi_random_alloc(efi_system_table_t *sys_table_arg,
efi_status_t check_platform_features(efi_system_table_t *sys_table_arg);
+efi_status_t efi_random_get_seed(efi_system_table_t *sys_table_arg);
+
#endif
diff --git a/drivers/firmware/efi/libstub/random.c b/drivers/firmware/efi/libstub/random.c
index 0c9f58c5ba50..4aa35c4fe029 100644
--- a/drivers/firmware/efi/libstub/random.c
+++ b/drivers/firmware/efi/libstub/random.c
@@ -141,3 +141,51 @@ efi_status_t efi_random_alloc(efi_system_table_t *sys_table_arg,
return status;
}
+
+#define RANDOM_SEED_SIZE 32
+
+efi_status_t efi_random_get_seed(efi_system_table_t *sys_table_arg)
+{
+ efi_guid_t rng_proto = EFI_RNG_PROTOCOL_GUID;
+ efi_guid_t rng_algo_raw = EFI_RNG_ALGORITHM_RAW;
+ efi_guid_t rng_table_guid = LINUX_EFI_RANDOM_SEED_TABLE_GUID;
+ struct efi_rng_protocol *rng;
+ struct linux_efi_random_seed *seed;
+ efi_status_t status;
+
+ status = efi_call_early(locate_protocol, &rng_proto, NULL,
+ (void **)&rng);
+ if (status != EFI_SUCCESS)
+ return status;
+
+ status = efi_call_early(allocate_pool, EFI_RUNTIME_SERVICES_DATA,
+ sizeof(*seed) + RANDOM_SEED_SIZE,
+ (void **)&seed);
+ if (status != EFI_SUCCESS)
+ return status;
+
+ status = rng->get_rng(rng, &rng_algo_raw, RANDOM_SEED_SIZE,
+ seed->bits);
+ if (status == EFI_UNSUPPORTED)
+ /*
+ * Use whatever algorithm we have available if the raw algorithm
+ * is not implemented.
+ */
+ status = rng->get_rng(rng, NULL, RANDOM_SEED_SIZE,
+ seed->bits);
+
+ if (status != EFI_SUCCESS)
+ goto err_freepool;
+
+ seed->size = RANDOM_SEED_SIZE;
+ status = efi_call_early(install_configuration_table, &rng_table_guid,
+ seed);
+ if (status != EFI_SUCCESS)
+ goto err_freepool;
+
+ return EFI_SUCCESS;
+
+err_freepool:
+ efi_call_early(free_pool, seed);
+ return status;
+}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 85e28b138cdd..f5a821d9b90c 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -589,6 +589,7 @@ void efi_native_runtime_setup(void);
#define DEVICE_TREE_GUID EFI_GUID(0xb1b621d5, 0xf19c, 0x41a5, 0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0)
#define EFI_PROPERTIES_TABLE_GUID EFI_GUID(0x880aaca3, 0x4adc, 0x4a04, 0x90, 0x79, 0xb7, 0x47, 0x34, 0x08, 0x25, 0xe5)
#define EFI_RNG_PROTOCOL_GUID EFI_GUID(0x3152bca5, 0xeade, 0x433d, 0x86, 0x2e, 0xc0, 0x1c, 0xdc, 0x29, 0x1f, 0x44)
+#define EFI_RNG_ALGORITHM_RAW EFI_GUID(0xe43176d7, 0xb6e8, 0x4827, 0xb7, 0x84, 0x7f, 0xfd, 0xc4, 0xb6, 0x85, 0x61)
#define EFI_MEMORY_ATTRIBUTES_TABLE_GUID EFI_GUID(0xdcfa911d, 0x26eb, 0x469f, 0xa2, 0x20, 0x38, 0xb7, 0xdc, 0x46, 0x12, 0x20)
#define EFI_CONSOLE_OUT_DEVICE_GUID EFI_GUID(0xd3b36f2c, 0xd551, 0x11d4, 0x9a, 0x46, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: fix show_regs fallout from KERN_CONT changes
From: Mark Rutland @ 2016-10-20 11:23 UTC (permalink / raw)
To: linux-arm-kernel
Recently in commit 4bcc595ccd80decb ("printk: reinstate KERN_CONT for
printing continuation lines"), the behaviour of printk changed w.r.t.
KERN_CONT. Now, KERN_CONT is mandatory to continue existing lines.
Without this, prefixes are inserted, making output illegible, e.g.
[ 1007.069010] pc : [<ffff00000871898c>] lr : [<ffff000008718948>] pstate: 40000145
[ 1007.076329] sp : ffff000008d53ec0
[ 1007.079606] x29: ffff000008d53ec0 [ 1007.082797] x28: 0000000080c50018
[ 1007.086160]
[ 1007.087630] x27: ffff000008e0c7f8 [ 1007.090820] x26: ffff80097631ca00
[ 1007.094183]
[ 1007.095653] x25: 0000000000000001 [ 1007.098843] x24: 000000ea68b61cac
[ 1007.102206]
... or when dumped with the userpace dmesg tool, which has slightly
different implicit newline behaviour. e.g.
[ 1007.069010] pc : [<ffff00000871898c>] lr : [<ffff000008718948>] pstate: 40000145
[ 1007.076329] sp : ffff000008d53ec0
[ 1007.079606] x29: ffff000008d53ec0
[ 1007.082797] x28: 0000000080c50018
[ 1007.086160]
[ 1007.087630] x27: ffff000008e0c7f8
[ 1007.090820] x26: ffff80097631ca00
[ 1007.094183]
[ 1007.095653] x25: 0000000000000001
[ 1007.098843] x24: 000000ea68b61cac
[ 1007.102206]
We can't simply always use KERN_CONT for lines which may or may not be
continuations. That causes line prefixes (e.g. timestamps) to be
supressed, and the alignment of all but the first line will be broken.
For even more fun, we can't simply insert some dummy empty-string printk
calls, as GCC warns for an empty printk string, and even if we pass
KERN_DEFAULT explcitly to silence the warning, the prefix gets swallowed
unless there is an additional part to the string.
Instead, we must manually iterate over pairs of registers, which gives
us the legible output we want in either case, e.g.
[ 169.771790] pc : [<ffff00000871898c>] lr : [<ffff000008718948>] pstate: 40000145
[ 169.779109] sp : ffff000008d53ec0
[ 169.782386] x29: ffff000008d53ec0 x28: 0000000080c50018
[ 169.787650] x27: ffff000008e0c7f8 x26: ffff80097631de00
[ 169.792913] x25: 0000000000000001 x24: 00000027827b2cf4
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/process.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index ddce61b..3f31cf93 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -187,10 +187,19 @@ void __show_regs(struct pt_regs *regs)
printk("pc : [<%016llx>] lr : [<%016llx>] pstate: %08llx\n",
regs->pc, lr, regs->pstate);
printk("sp : %016llx\n", sp);
- for (i = top_reg; i >= 0; i--) {
+
+ i = top_reg;
+
+ while (i >= 0) {
printk("x%-2d: %016llx ", i, regs->regs[i]);
- if (i % 2 == 0)
- printk("\n");
+ i--;
+
+ if (i % 2 == 0) {
+ pr_cont("x%-2d: %016llx ", i, regs->regs[i]);
+ i--;
+ }
+
+ pr_cont("\n");
}
printk("\n");
}
--
1.9.1
^ permalink raw reply related
* [PATCH v3 0/5] Cavium ThunderX uncore PMU support
From: Jan Glauber @ 2016-10-20 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020103707.GB3175@twins.programming.kicks-ass.net>
On Thu, Oct 20, 2016 at 12:37:07PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 20, 2016 at 11:30:36AM +0200, Jan Glauber wrote:
> > Note:
> > I'm using perf_sw_context in difference to perf_invalid_context
> > (see WARN_ON in perf_pmu_register). Reason is that with perf_invalid_context
> > add() is never called and the counter results are shown as "unsupported" by
> > perf. With perf_sw_context everything works as expected.
>
> What?! All the uncore PMUs use perf_invalid_context. What doesn't work
> for you?
OK, so using perf_invalid_context and "-a" seems to work.
But I must say that I hate that from a user perspective. The user needs to know about
the type of PMU behind the event and then provide "-a" or get a "<not supported"
as counter value?
^ permalink raw reply
* [PATCH] arm64: remove pr_cont abuse from mem_init
From: Mark Rutland @ 2016-10-20 11:24 UTC (permalink / raw)
To: linux-arm-kernel
All the lines printed by mem_init are independent, with each ending with
a newline. While they logically form a large block, none are actually
continuations of previous lines.
The kernel-side printk code and the userspace demsg tool differ in their
handling of KERN_CONT following a newline, and while this isn't always a
problem kernel-side, it does cause difficulty for userspace. Using
pr_cont causes the userspace tool to not print line prefix (e.g.
timestamps) even when following a newline, mis-aligning the output and
making it harder to read, e.g.
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000088b0000 ( 8384 KB)
.rodata : 0xffff0000088b0000 - 0xffff000008c50000 ( 3712 KB)
.init : 0xffff000008c50000 - 0xffff000008d50000 ( 1024 KB)
.data : 0xffff000008d50000 - 0xffff000008e25200 ( 853 KB)
.bss : 0xffff000008e25200 - 0xffff000008e6bec0 ( 284 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0026000000 ( 608 MB actual)
memory : 0xffff800000000000 - 0xffff800980000000 ( 38912 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
Fix this by using pr_notice consistently for all lines, which both the
kernel and userspace are happy with.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/mm/init.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 21c489b..212c4d1 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -421,35 +421,35 @@ void __init mem_init(void)
pr_notice("Virtual kernel memory layout:\n");
#ifdef CONFIG_KASAN
- pr_cont(" kasan : 0x%16lx - 0x%16lx (%6ld GB)\n",
+ pr_notice(" kasan : 0x%16lx - 0x%16lx (%6ld GB)\n",
MLG(KASAN_SHADOW_START, KASAN_SHADOW_END));
#endif
- pr_cont(" modules : 0x%16lx - 0x%16lx (%6ld MB)\n",
+ pr_notice(" modules : 0x%16lx - 0x%16lx (%6ld MB)\n",
MLM(MODULES_VADDR, MODULES_END));
- pr_cont(" vmalloc : 0x%16lx - 0x%16lx (%6ld GB)\n",
+ pr_notice(" vmalloc : 0x%16lx - 0x%16lx (%6ld GB)\n",
MLG(VMALLOC_START, VMALLOC_END));
- pr_cont(" .text : 0x%p" " - 0x%p" " (%6ld KB)\n",
+ pr_notice(" .text : 0x%p" " - 0x%p" " (%6ld KB)\n",
MLK_ROUNDUP(_text, _etext));
- pr_cont(" .rodata : 0x%p" " - 0x%p" " (%6ld KB)\n",
+ pr_notice(" .rodata : 0x%p" " - 0x%p" " (%6ld KB)\n",
MLK_ROUNDUP(__start_rodata, __init_begin));
- pr_cont(" .init : 0x%p" " - 0x%p" " (%6ld KB)\n",
+ pr_notice(" .init : 0x%p" " - 0x%p" " (%6ld KB)\n",
MLK_ROUNDUP(__init_begin, __init_end));
- pr_cont(" .data : 0x%p" " - 0x%p" " (%6ld KB)\n",
+ pr_notice(" .data : 0x%p" " - 0x%p" " (%6ld KB)\n",
MLK_ROUNDUP(_sdata, _edata));
- pr_cont(" .bss : 0x%p" " - 0x%p" " (%6ld KB)\n",
+ pr_notice(" .bss : 0x%p" " - 0x%p" " (%6ld KB)\n",
MLK_ROUNDUP(__bss_start, __bss_stop));
- pr_cont(" fixed : 0x%16lx - 0x%16lx (%6ld KB)\n",
+ pr_notice(" fixed : 0x%16lx - 0x%16lx (%6ld KB)\n",
MLK(FIXADDR_START, FIXADDR_TOP));
- pr_cont(" PCI I/O : 0x%16lx - 0x%16lx (%6ld MB)\n",
+ pr_notice(" PCI I/O : 0x%16lx - 0x%16lx (%6ld MB)\n",
MLM(PCI_IO_START, PCI_IO_END));
#ifdef CONFIG_SPARSEMEM_VMEMMAP
- pr_cont(" vmemmap : 0x%16lx - 0x%16lx (%6ld GB maximum)\n",
+ pr_notice(" vmemmap : 0x%16lx - 0x%16lx (%6ld GB maximum)\n",
MLG(VMEMMAP_START, VMEMMAP_START + VMEMMAP_SIZE));
- pr_cont(" 0x%16lx - 0x%16lx (%6ld MB actual)\n",
+ pr_notice(" 0x%16lx - 0x%16lx (%6ld MB actual)\n",
MLM((unsigned long)phys_to_page(memblock_start_of_DRAM()),
(unsigned long)virt_to_page(high_memory)));
#endif
- pr_cont(" memory : 0x%16lx - 0x%16lx (%6ld MB)\n",
+ pr_notice(" memory : 0x%16lx - 0x%16lx (%6ld MB)\n",
MLM(__phys_to_virt(memblock_start_of_DRAM()),
(unsigned long)high_memory));
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/3] efi: add support for seeding the RNG from a UEFI config table
From: Ard Biesheuvel @ 2016-10-20 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476962486-18368-2-git-send-email-ard.biesheuvel@linaro.org>
On 20 October 2016 at 12:21, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> Specify a Linux specific UEFI configuration table that carries some
> random bits, and use the contents during early boot to seed the kernel's
> random number generator. This allows much strong random numbers to be
> generated early on.
>
> The entropy is fed to the kernel using add_device_randomness(), which is
> documented as being appropriate for being called very early.
>
> Since UEFI configuration tables may also be consumed by kexec'd kernels,
> register a reboot notifier that updates the seed in the table.
>
> Note that the config table could be generated by the EFI stub or by any
> other UEFI driver or application (e.g., GRUB), but the random seed table
> GUID and the associated functionality should be considered an internal
> kernel interface (unless it is promoted to ABI later on)
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> drivers/firmware/efi/efi.c | 67 ++++++++++++++++++++
> include/linux/efi.h | 8 +++
> 2 files changed, 75 insertions(+)
>
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 1ac199cd75e7..47937ffd9f2f 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -24,6 +24,8 @@
> #include <linux/of_fdt.h>
> #include <linux/io.h>
> #include <linux/platform_device.h>
> +#include <linux/random.h>
> +#include <linux/reboot.h>
> #include <linux/slab.h>
> #include <linux/acpi.h>
> #include <linux/ucs2_string.h>
> @@ -48,6 +50,7 @@ struct efi __read_mostly efi = {
> .esrt = EFI_INVALID_TABLE_ADDR,
> .properties_table = EFI_INVALID_TABLE_ADDR,
> .mem_attr_table = EFI_INVALID_TABLE_ADDR,
> + .rng_seed = EFI_INVALID_TABLE_ADDR,
> };
> EXPORT_SYMBOL(efi);
>
> @@ -438,6 +441,7 @@ static __initdata efi_config_table_type_t common_tables[] = {
> {EFI_SYSTEM_RESOURCE_TABLE_GUID, "ESRT", &efi.esrt},
> {EFI_PROPERTIES_TABLE_GUID, "PROP", &efi.properties_table},
> {EFI_MEMORY_ATTRIBUTES_TABLE_GUID, "MEMATTR", &efi.mem_attr_table},
> + {LINUX_EFI_RANDOM_SEED_TABLE_GUID, "RNG", &efi.rng_seed},
> {NULL_GUID, NULL, NULL},
> };
>
> @@ -499,6 +503,29 @@ int __init efi_config_parse_tables(void *config_tables, int count, int sz,
> pr_cont("\n");
> set_bit(EFI_CONFIG_TABLES, &efi.flags);
>
> + if (efi.rng_seed != EFI_INVALID_TABLE_ADDR) {
> + struct linux_efi_random_seed *seed;
> + u32 size = 0;
> +
> + seed = early_memremap(efi.rng_seed, sizeof(*seed));
> + if (seed != NULL) {
> + size = seed->size;
> + early_memunmap(seed, sizeof(*seed));
> + } else {
> + pr_err("Could not map UEFI random seed!\n");
> + }
> + if (size > 0) {
> + seed = early_memremap(efi.rng_seed,
> + sizeof(*seed) + size);
> + if (seed != NULL) {
> + add_device_randomness(seed->bits, seed->size);
> + early_memunmap(seed, sizeof(*seed) + size);
> + } else {
> + pr_err("Could not map UEFI random seed!\n");
> + }
> + }
> + }
> +
> /* Parse the EFI Properties table if it exists */
> if (efi.properties_table != EFI_INVALID_TABLE_ADDR) {
> efi_properties_table_t *tbl;
> @@ -822,3 +849,43 @@ int efi_status_to_err(efi_status_t status)
>
> return err;
> }
> +
> +#ifdef CONFIG_KEXEC
> +static int update_efi_random_seed(struct notifier_block *nb,
> + unsigned long code, void *unused)
> +{
> + struct linux_efi_random_seed *seed;
> + u32 size = 0;
> +
I forgot to git-add this bit here:
+ if (!kexec_in_progress)
+ return NOTIFY_DONE;
+
> + seed = memremap(efi.rng_seed, sizeof(*seed), MEMREMAP_WB);
> + if (seed != NULL) {
> + size = seed->size;
> + memunmap(seed);
> + } else {
> + pr_err("Could not map UEFI random seed!\n");
> + }
> + if (size > 0) {
> + seed = memremap(efi.rng_seed, sizeof(*seed) + size,
> + MEMREMAP_WB);
> + if (seed != NULL) {
> + get_random_bytes(seed->bits, seed->size);
> + memunmap(seed);
> + } else {
> + pr_err("Could not map UEFI random seed!\n");
> + }
> + }
> + return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block efi_random_seed_nb = {
> + .notifier_call = update_efi_random_seed,
> +};
> +
> +static int register_update_efi_random_seed(void)
> +{
> + if (efi.rng_seed == EFI_INVALID_TABLE_ADDR)
> + return 0;
> + return register_reboot_notifier(&efi_random_seed_nb);
> +}
> +late_initcall(register_update_efi_random_seed);
> +#endif
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 2d089487d2da..85e28b138cdd 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -599,6 +599,7 @@ void efi_native_runtime_setup(void);
> */
> #define LINUX_EFI_ARM_SCREEN_INFO_TABLE_GUID EFI_GUID(0xe03fc20a, 0x85dc, 0x406e, 0xb9, 0x0e, 0x4a, 0xb5, 0x02, 0x37, 0x1d, 0x95)
> #define LINUX_EFI_LOADER_ENTRY_GUID EFI_GUID(0x4a67b082, 0x0a4c, 0x41cf, 0xb6, 0xc7, 0x44, 0x0b, 0x29, 0xbb, 0x8c, 0x4f)
> +#define LINUX_EFI_RANDOM_SEED_TABLE_GUID EFI_GUID(0x1ce1e5bc, 0x7ceb, 0x42f2, 0x81, 0xe5, 0x8a, 0xad, 0xf1, 0x80, 0xf5, 0x7b)
>
> typedef struct {
> efi_guid_t guid;
> @@ -872,6 +873,7 @@ extern struct efi {
> unsigned long esrt; /* ESRT table */
> unsigned long properties_table; /* properties table */
> unsigned long mem_attr_table; /* memory attributes table */
> + unsigned long rng_seed; /* UEFI firmware random seed */
> efi_get_time_t *get_time;
> efi_set_time_t *set_time;
> efi_get_wakeup_time_t *get_wakeup_time;
> @@ -1493,4 +1495,10 @@ efi_status_t efi_exit_boot_services(efi_system_table_t *sys_table,
> struct efi_boot_memmap *map,
> void *priv,
> efi_exit_boot_map_processing priv_func);
> +
> +struct linux_efi_random_seed {
> + u32 size;
> + u8 bits[];
> +};
> +
> #endif /* _LINUX_EFI_H */
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 3/3] arm64: suspend: Reconfigure PSTATE after resume from idle
From: Lorenzo Pieralisi @ 2016-10-20 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476786468-2173-4-git-send-email-james.morse@arm.com>
On Tue, Oct 18, 2016 at 11:27:48AM +0100, James Morse wrote:
> The suspend/resume path in kernel/sleep.S, as used by cpu-idle, does not
> save/restore PSTATE. As a result of this cpufeatures that were detected
> and have bits in PSTATE get lost when we resume from idle.
>
> UAO gets set appropriately on the next context switch. PAN will be
> re-enabled next time we return from user-space, but on a preemptible
> kernel we may run work accessing user space before this point.
>
> Add code to re-enable theses two features in __cpu_suspend_exit().
> We re-use uao_thread_switch() passing current.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>
> ---
> This patch applies to linux-stable v4.7.8, but with some fuzz...
> but 'git am' rejects it.
>
> asm/exec.h is my best guess at the appropriate header file. Contradictions
> welcome.
uaccess.h ? It is a shame you have to export uao_thread_switch() (see
below for a possible solution) but I agree that prevents useless code
duplication and that this needs fixing.
> arch/arm64/include/asm/exec.h | 3 +++
> arch/arm64/kernel/process.c | 3 ++-
> arch/arm64/kernel/suspend.c | 11 +++++++++++
> 3 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/exec.h b/arch/arm64/include/asm/exec.h
> index db0563c23482..f7865dd9d868 100644
> --- a/arch/arm64/include/asm/exec.h
> +++ b/arch/arm64/include/asm/exec.h
> @@ -18,6 +18,9 @@
> #ifndef __ASM_EXEC_H
> #define __ASM_EXEC_H
>
> +#include <linux/sched.h>
> +
> extern unsigned long arch_align_stack(unsigned long sp);
> +void uao_thread_switch(struct task_struct *next);
>
> #endif /* __ASM_EXEC_H */
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 27b2f1387df4..4f186c56c5eb 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -49,6 +49,7 @@
> #include <asm/alternative.h>
> #include <asm/compat.h>
> #include <asm/cacheflush.h>
> +#include <asm/exec.h>
> #include <asm/fpsimd.h>
> #include <asm/mmu_context.h>
> #include <asm/processor.h>
> @@ -301,7 +302,7 @@ static void tls_thread_switch(struct task_struct *next)
> }
>
> /* Restore the UAO state depending on next's addr_limit */
> -static void uao_thread_switch(struct task_struct *next)
> +void uao_thread_switch(struct task_struct *next)
> {
> if (IS_ENABLED(CONFIG_ARM64_UAO)) {
> if (task_thread_info(next)->addr_limit == KERNEL_DS)
> diff --git a/arch/arm64/kernel/suspend.c b/arch/arm64/kernel/suspend.c
> index ad734142070d..bb0cd787a9d3 100644
> --- a/arch/arm64/kernel/suspend.c
> +++ b/arch/arm64/kernel/suspend.c
> @@ -1,8 +1,11 @@
> #include <linux/ftrace.h>
> #include <linux/percpu.h>
> #include <linux/slab.h>
> +#include <asm/alternative.h>
> #include <asm/cacheflush.h>
> +#include <asm/cpufeature.h>
> #include <asm/debug-monitors.h>
> +#include <asm/exec.h>
> #include <asm/pgtable.h>
> #include <asm/memory.h>
> #include <asm/mmu_context.h>
> @@ -50,6 +53,14 @@ void notrace __cpu_suspend_exit(void)
> set_my_cpu_offset(per_cpu_offset(cpu));
>
> /*
> + * PSTATE was not saved over suspend/resume, re-enable any detected
> + * features that might not have been set correctly.
> + */
> + asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_HAS_PAN,
> + CONFIG_ARM64_PAN));
> + uao_thread_switch(current);
set_fs(get_fs());
would do (?), but that's horrendous to say the least, maybe you can
refactor the code in asm/uaccess.h to achieve the same goal (ie you
factor out the code setting UAO from set_fs() in a separate inline that
you can also reuse in uao_thread_switch() and here).
Other than that:
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> +
> + /*
> * Restore HW breakpoint registers to sane values
> * before debug exceptions are possibly reenabled
> * through local_dbg_restore.
> --
> 2.8.0.rc3
>
^ permalink raw reply
* [PATCH v3 0/5] Cavium ThunderX uncore PMU support
From: Peter Zijlstra @ 2016-10-20 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020112351.GC13708@hardcore>
On Thu, Oct 20, 2016 at 01:23:51PM +0200, Jan Glauber wrote:
> On Thu, Oct 20, 2016 at 12:37:07PM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 20, 2016 at 11:30:36AM +0200, Jan Glauber wrote:
> > > Note:
> > > I'm using perf_sw_context in difference to perf_invalid_context
> > > (see WARN_ON in perf_pmu_register). Reason is that with perf_invalid_context
> > > add() is never called and the counter results are shown as "unsupported" by
> > > perf. With perf_sw_context everything works as expected.
> >
> > What?! All the uncore PMUs use perf_invalid_context. What doesn't work
> > for you?
>
> OK, so using perf_invalid_context and "-a" seems to work.
>
> But I must say that I hate that from a user perspective. The user needs to know about
> the type of PMU behind the event and then provide "-a" or get a "<not supported"
> as counter value?
This really boils down to the fact that users really had better know
what they're on about.
There's only so much you can let clueless people do.
The fact is, they already _manually_ select your (uncore) PMU, so they
had then better also know what its limitations are.
^ permalink raw reply
* [PATCH] pinctrl: st: don't specify default interrupt trigger
From: Patrice Chotard @ 2016-10-20 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476774988-13484-1-git-send-email-patrice.chotard@st.com>
On 10/18/2016 09:16 AM, patrice.chotard at st.com wrote:
> From: Patrice Chotard <patrice.chotard@st.com>
>
> Thanks to 332e99d5ae4 which now alerts of default
> trigger usage when configuring interrupts.
>
> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
> ---
> drivers/pinctrl/pinctrl-st.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/pinctrl-st.c b/drivers/pinctrl/pinctrl-st.c
> index 99da4cf..b7bb371 100644
> --- a/drivers/pinctrl/pinctrl-st.c
> +++ b/drivers/pinctrl/pinctrl-st.c
> @@ -1512,7 +1512,7 @@ static int st_gpiolib_register_bank(struct st_pinctrl *info,
> if (info->irqmux_base || gpio_irq > 0) {
> err = gpiochip_irqchip_add(&bank->gpio_chip, &st_gpio_irqchip,
> 0, handle_simple_irq,
> - IRQ_TYPE_LEVEL_LOW);
> + IRQ_TYPE_NONE);
> if (err) {
> gpiochip_remove(&bank->gpio_chip);
> dev_info(dev, "could not add irqchip\n");
>
Hi Linus
I forgot to mention that this patch is dedicated for v4.9-rcs
Thanks
Patrice
^ permalink raw reply
* [PATCH 0/4] ARM64: dts: meson-gxbb: Add MMC and Wifi support
From: Neil Armstrong @ 2016-10-20 11:42 UTC (permalink / raw)
To: linux-arm-kernel
This patchsets adds the MMC nodes in the GX dtsi and adds the GXBB clocks
attributes in the GXBB dtsi.
Then MMC/SD/SDIO support is added to :
- p20x : SD, SDIO, MMC
- a95x : SD, SDIO, MMC
- Odroid-C2 : SD, MMC
WiFi support is also added by enabling the 32768Hz clock generated by PWM
on p20x and A95x and adding the SDIO power sequence.
This patchset is based on Kevin Hilman's amlogic v4.10/dt64 tree at [1]
[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git
Kevin Hilman (1):
ARM64: dts: meson-gxbb: add MMC support
Neil Armstrong (3):
ARM64: dts: meson-gxbb: Add Wifi 32K clock for p20x boards
ARM64: dts: meson-gxbb: Add P20x Wifi SDIO support
ARM64: dts: meson-gxbb: Add MMC nodes to Nexbox A95x
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 21 ++++
.../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 122 ++++++++++++++++++++
.../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 88 ++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 127 +++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 24 +++-
5 files changed, 381 insertions(+), 1 deletion(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/4] ARM64: dts: meson-gxbb: add MMC support
From: Neil Armstrong @ 2016-10-20 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476963777-1804-1-git-send-email-narmstrong@baylibre.com>
From: Kevin Hilman <khilman@baylibre.com>
Add binding and basic support for the SD/eMMC controller on Amlogic
S905/GXBB devices.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 21 +++++
.../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 88 +++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 98 ++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 24 +++++-
4 files changed, 230 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index a6cd953..fd1d0de 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -203,6 +203,27 @@
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xd0000000 0x0 0x200000>;
+
+ sd_emmc_a: mmc at 70000 {
+ compatible = "amlogic,meson-gx-mmc", "amlogic,meson-gxbb-mmc";
+ reg = <0x0 0x70000 0x0 0x2000>;
+ interrupts = <GIC_SPI 216 IRQ_TYPE_EDGE_RISING>;
+ status = "disabled";
+ };
+
+ sd_emmc_b: mmc at 72000 {
+ compatible = "amlogic,meson-gx-mmc", "amlogic,meson-gxbb-mmc";
+ reg = <0x0 0x72000 0x0 0x2000>;
+ interrupts = <GIC_SPI 217 IRQ_TYPE_EDGE_RISING>;
+ status = "disabled";
+ };
+
+ sd_emmc_c: mmc at 74000 {
+ compatible = "amlogic,meson-gx-mmc", "amlogic,meson-gxbb-mmc";
+ reg = <0x0 0x74000 0x0 0x2000>;
+ interrupts = <GIC_SPI 218 IRQ_TYPE_EDGE_RISING>;
+ status = "disabled";
+ };
};
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index a45d101..238fbea 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -85,6 +85,56 @@
default-state = "off";
};
};
+
+ tflash_vdd: regulator-tflash_vdd {
+ /*
+ * signal name from schematics: TFLASH_VDD_EN
+ */
+ compatible = "regulator-fixed";
+
+ regulator-name = "TFLASH_VDD";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&gpio_ao GPIOAO_12 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ tf_io: gpio-regulator-tf_io {
+ compatible = "regulator-gpio";
+
+ regulator-name = "TF_IO";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+
+ /*
+ * signal name from schematics: TF_3V3N_1V8_EN
+ */
+ gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
+ gpios-states = <0>;
+
+ states = <3300000 0
+ 1800000 1>;
+ };
+
+ vcc1v8: regulator-vcc1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ vcc3v3: regulator-vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
+ };
};
&uart_AO {
@@ -127,3 +177,41 @@
&usb1 {
status = "okay";
};
+
+/* SD */
+&sd_emmc_b {
+ status = "okay";
+ pinctrl-0 = <&sdcard_pins>;
+ pinctrl-names = "default";
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <100000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+
+ vmmc-supply = <&tflash_vdd>;
+ vqmmc-supply = <&tf_io>;
+};
+
+/* eMMC */
+&sd_emmc_c {
+ status = "okay";
+ pinctrl-0 = <&emmc_pins>;
+ pinctrl-names = "default";
+
+ bus-width = <8>;
+ cap-sd-highspeed;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vcc3v3>;
+ vqmmc-supply = <&vcc1v8>;
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 031d69b..86e740f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -70,6 +70,47 @@
gpio = <&gpio GPIODV_24 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+ vddio_card: gpio-regulator {
+ compatible = "regulator-gpio";
+
+ regulator-name = "VDDIO_CARD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpios = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+
+ /* Based on P200 schematics, signal CARD_1.8V/3.3V_CTR */
+ states = <1800000 0
+ 3300000 1>;
+ };
+
+ vddio_boot: regulator-vddio_boot {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_BOOT";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ vddao_3v3: regulator-vddao_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vcc_3v3: regulator-vcc_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
+ };
};
/* This UART is brought out to the DB9 connector */
@@ -107,3 +148,60 @@
&usb1 {
status = "okay";
};
+
+/* Wireless SDIO Module */
+&sd_emmc_a {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <100000000>;
+
+ non-removable;
+ disable-wp;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_boot>;
+};
+
+/* SD card */
+&sd_emmc_b {
+ status = "okay";
+ pinctrl-0 = <&sdcard_pins>;
+ pinctrl-names = "default";
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <100000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_card>;
+};
+
+/* eMMC */
+&sd_emmc_c {
+ status = "okay";
+ pinctrl-0 = <&emmc_pins>;
+ pinctrl-names = "default";
+
+ bus-width = <8>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vcc_3v3>;
+ vqmmc-supply = <&vddio_boot>;
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index aad639a..22940bb 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -349,7 +349,8 @@
mux {
groups = "emmc_nand_d07",
"emmc_cmd",
- "emmc_clk";
+ "emmc_clk",
+ "emmc_ds";
function = "emmc";
};
};
@@ -545,3 +546,24 @@
#mbox-cells = <1>;
};
};
+
+&sd_emmc_a {
+ clocks = <&clkc CLKID_SD_EMMC_A>,
+ <&xtal>,
+ <&clkc CLKID_FCLK_DIV2>;
+ clock-names = "core", "clkin0", "clkin1";
+};
+
+&sd_emmc_b {
+ clocks = <&clkc CLKID_SD_EMMC_B>,
+ <&xtal>,
+ <&clkc CLKID_FCLK_DIV2>;
+ clock-names = "core", "clkin0", "clkin1";
+};
+
+&sd_emmc_c {
+ clocks = <&clkc CLKID_SD_EMMC_C>,
+ <&xtal>,
+ <&clkc CLKID_FCLK_DIV2>;
+ clock-names = "core", "clkin0", "clkin1";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] ARM64: dts: meson-gxbb: Add Wifi 32K clock for p20x boards
From: Neil Armstrong @ 2016-10-20 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476963777-1804-1-git-send-email-narmstrong@baylibre.com>
Add a 32768Hz clock generated by the PWM E port used by the WiFi module.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 86e740f..6861b0a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -111,6 +111,13 @@
compatible = "mmc-pwrseq-emmc";
reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
};
+
+ wifi32k: wifi32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
};
/* This UART is brought out to the DB9 connector */
@@ -205,3 +212,11 @@
vmmc-supply = <&vcc_3v3>;
vqmmc-supply = <&vddio_boot>;
};
+
+&pwm_ef {
+ status = "okay";
+ pinctrl-0 = <&pwm_e_pins>;
+ pinctrl-names = "default";
+ clocks = <&clkc CLKID_FCLK_DIV4>;
+ clock-names = "clkin0";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] ARM64: dts: meson-gxbb: Add P20x Wifi SDIO support
From: Neil Armstrong @ 2016-10-20 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476963777-1804-1-git-send-email-narmstrong@baylibre.com>
Add Wifi module support on the Amlogic P20x boards on the SDIO port.
The Wifi module also needs a 32768Hz clock provided by the PWM E port
through a pwm-clock node in it's power sequence.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 6861b0a..203be28 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -118,6 +118,13 @@
clock-frequency = <32768>;
pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
};
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <&wifi32k>;
+ clock-names = "ext_clock";
+ };
};
/* This UART is brought out to the DB9 connector */
@@ -171,8 +178,15 @@
non-removable;
disable-wp;
+ mmc-pwrseq = <&sdio_pwrseq>;
+
vmmc-supply = <&vddao_3v3>;
vqmmc-supply = <&vddio_boot>;
+
+ brcmf: bcrmf at 1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ };
};
/* SD card */
--
1.9.1
^ permalink raw reply related
* [PATCH 4/4] ARM64: dts: meson-gxbb: Add MMC nodes to Nexbox A95x
From: Neil Armstrong @ 2016-10-20 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476963777-1804-1-git-send-email-narmstrong@baylibre.com>
Add support for eMMC/SD/SDIO on the Nexbox A95x.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 122 +++++++++++++++++++++
1 file changed, 122 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 399d85f..9696820 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -87,6 +87,61 @@
gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_LOW>;
};
};
+
+ vddio_card: gpio-regulator {
+ compatible = "regulator-gpio";
+
+ regulator-name = "VDDIO_CARD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpios = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+
+ /* Based on P200 schematics, signal CARD_1.8V/3.3V_CTR */
+ states = <1800000 0
+ 3300000 1>;
+ };
+
+ vddio_boot: regulator-vddio_boot {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_BOOT";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ vddao_3v3: regulator-vddao_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vcc_3v3: regulator-vcc_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
+ };
+
+ wifi32k: wifi32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <&wifi32k>;
+ clock-names = "ext_clock";
+ };
};
&uart_AO {
@@ -107,3 +162,70 @@
pinctrl-0 = <&remote_input_ao_pins>;
pinctrl-names = "default";
};
+
+/* Wireless SDIO Module */
+&sd_emmc_a {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <100000000>;
+
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&sdio_pwrseq>;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_boot>;
+};
+
+/* SD card */
+&sd_emmc_b {
+ status = "okay";
+ pinctrl-0 = <&sdcard_pins>;
+ pinctrl-names = "default";
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <100000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_card>;
+};
+
+/* eMMC */
+&sd_emmc_c {
+ status = "okay";
+ pinctrl-0 = <&emmc_pins>;
+ pinctrl-names = "default";
+
+ bus-width = <8>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vcc_3v3>;
+ vqmmc-supply = <&vddio_boot>;
+};
+
+&pwm_ef {
+ status = "okay";
+ pinctrl-0 = <&pwm_e_pins>;
+ pinctrl-names = "default";
+ clocks = <&clkc CLKID_FCLK_DIV4>;
+ clock-names = "clkin0";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH] ARM64: defconfig: Enable MMC related configs
From: Neil Armstrong @ 2016-10-20 11:49 UTC (permalink / raw)
To: linux-arm-kernel
Enable MMC related defaults configs for MMC, PWM and PWM clock.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index dab2cb0..920f1e8 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -341,6 +341,7 @@ CONFIG_USB_RENESAS_USBHS_UDC=m
CONFIG_MMC=y
CONFIG_MMC_BLOCK_MINORS=32
CONFIG_MMC_ARMMMCI=y
+CONFIG_MMC_MESON_GX=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_ACPI=y
CONFIG_MMC_SDHCI_PLTFM=y
@@ -387,6 +388,7 @@ CONFIG_XEN_GRANT_DEV_ALLOC=y
CONFIG_COMMON_CLK_SCPI=y
CONFIG_COMMON_CLK_CS2000_CP=y
CONFIG_COMMON_CLK_S2MPS11=y
+CONFIG_COMMON_CLK_PWM=y
CONFIG_CLK_QORIQ=y
CONFIG_COMMON_CLK_QCOM=y
CONFIG_MSM_GCC_8916=y
@@ -404,6 +406,7 @@ CONFIG_ARCH_TEGRA_210_SOC=y
CONFIG_EXTCON_USB_GPIO=y
CONFIG_PWM=y
CONFIG_PWM_TEGRA=m
+CONFIG_PWM_MESON=m
CONFIG_COMMON_RESET_HI6220=y
CONFIG_PHY_RCAR_GEN3_USB2=y
CONFIG_PHY_HI6220_USB=y
--
1.9.1
^ permalink raw reply related
* [PATCH 6/8] pinctrl: aspeed-g4: Capture SuperIO pinmux dependency
From: Linus Walleij @ 2016-10-20 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b5f67ba76018314d08e240f95951751896687d37.1474986045.git-series.andrew@aj.id.au>
On Tue, Sep 27, 2016 at 4:50 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> Two LPC-related signals in the AST2400 depend on state in the SuperIO IP
> block. Use the recently added infrastructure to capture this
> relationship.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Patch applied for v4.10.
(Tell me if I'm applying patches in wrong order or something, and
I hope this doesn't clash with the fixes.)
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] pinctrl: st: don't specify default interrupt trigger
From: Peter Griffin @ 2016-10-20 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <729ebc94-5476-65a7-cc17-eabfba0d2404@st.com>
Hi Patrice,
On Thu, 20 Oct 2016, Patrice Chotard wrote:
>
>
> On 10/18/2016 09:16 AM, patrice.chotard at st.com wrote:
> > From: Patrice Chotard <patrice.chotard@st.com>
> >
> > Thanks to 332e99d5ae4 which now alerts of default
> > trigger usage when configuring interrupts.
> >
> > Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
> > ---
> > drivers/pinctrl/pinctrl-st.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pinctrl/pinctrl-st.c b/drivers/pinctrl/pinctrl-st.c
> > index 99da4cf..b7bb371 100644
> > --- a/drivers/pinctrl/pinctrl-st.c
> > +++ b/drivers/pinctrl/pinctrl-st.c
> > @@ -1512,7 +1512,7 @@ static int st_gpiolib_register_bank(struct st_pinctrl *info,
> > if (info->irqmux_base || gpio_irq > 0) {
> > err = gpiochip_irqchip_add(&bank->gpio_chip, &st_gpio_irqchip,
> > 0, handle_simple_irq,
> > - IRQ_TYPE_LEVEL_LOW);
> > + IRQ_TYPE_NONE);
> > if (err) {
> > gpiochip_remove(&bank->gpio_chip);
> > dev_info(dev, "could not add irqchip\n");
> >
>
> Hi Linus
>
> I forgot to mention that this patch is dedicated for v4.9-rcs
Wow, v4.9-rc is a noisy boot without this patch :)
Acked-by: Peter Griffin <peter.griffin@linaro.org>
^ permalink raw reply
* [PATCH v2 1/6] ARM: at91: Documentation: add samx7 families
From: Nicolas Ferre @ 2016-10-20 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020094135.18221-2-alexandre.belloni@free-electrons.com>
Le 20/10/2016 ? 11:41, Alexandre Belloni a ?crit :
> The Atmel sams70, samv70 and samv71 are Cortex-M7 based MCUs that can run
> Linux (without MMU).
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
> Documentation/arm/Atmel/README | 44 +++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 41 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/arm/Atmel/README b/Documentation/arm/Atmel/README
> index 6ca78f818dbf..e403697ee9fc 100644
> --- a/Documentation/arm/Atmel/README
> +++ b/Documentation/arm/Atmel/README
> @@ -14,9 +14,9 @@ official Atmel product name. Anyway, files, directories, git trees,
> git branches/tags and email subject always contain this "at91" sub-string.
>
>
> -AT91 SoCs
Nope: AT91 is our historical name within the Linux community, we will
keep it.
> ----------
> -Documentation and detailled datasheet for each product are available on
> +SMART SoCs
And I'm not sure about the naming of the product line nowadays:
Atmel | SMART MPUs?
Microchip / Atmel | SMART MPUs?
Microchip MPUs?
But SoC is definitively too generic and "SMART" not needed here: let's
keep the MPUs/MCUs only difference for this document.
> +----------
> +Documentation and detailed datasheet for each product are available on
> the Atmel website: http://www.atmel.com.
>
> Flavors:
> @@ -101,6 +101,44 @@ the Atmel website: http://www.atmel.com.
> + Datasheet
> http://www.atmel.com/Images/Atmel-11267-32-bit-Cortex-A5-Microcontroller-SAMA5D2_Datasheet.pdf
>
> +SMART MCUs
> +----------
> + * ARM Cortex-M7 MCUs
> + - sams70 family
> + - sams70j19
> + - sams70j20
> + - sams70j21
> + - sams70n19
> + - sams70n20
> + - sams70n21
> + - sams70q19
> + - sams70q20
> + - sams70q21
> + + Datasheet
> + http://www.atmel.com/Images/Atmel-11242-32-bit-Cortex-M7-Microcontroller-SAM-S70Q-SAM-S70N-SAM-S70J_Datasheet.pdf
> +
> + - samv70 family
> + - samv70j19
> + - samv70j20
> + - samv70n19
> + - samv70n20
> + - samv70q19
> + - samv70q20
> + + Datasheet
> + http://www.atmel.com/Images/Atmel-11297-32-bit-Cortex-M7-Microcontroller-SAM-V70Q-SAM-V70N-SAM-V70J_Datasheet.pdf
> +
> + - samv71 family
> + - samv71j19
> + - samv71j20
> + - samv71j21
> + - samv71n19
> + - samv71n20
> + - samv71n21
> + - samv71q19
> + - samv71q20
> + - samv71q21
> + + Datasheet
> + http://www.atmel.com/Images/Atmel-44003-32-bit-Cortex-M7-Microcontroller-SAM-V71Q-SAM-V71N-SAM-V71J_Datasheet.pdf
>
> Linux kernel information
> ------------------------
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 1/2] arm64/numa: fix pcpu_cpu_distance() to get correct CPU proximity
From: Hanjun Guo @ 2016-10-20 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020104815.GC24914@arm.com>
On 2016/10/20 18:48, Will Deacon wrote:
> On Thu, Oct 20, 2016 at 11:52:55AM +0800, Hanjun Guo wrote:
>> From: Yisheng Xie <xieyisheng1@huawei.com>
>>
>> The pcpu_build_alloc_info() function group CPUs according to their
>> proximity, by call callback function @cpu_distance_fn from different
>> ARCHs.
>>
>> For arm64 the callback of @cpu_distance_fn is
>> pcpu_cpu_distance(from, to)
>> -> node_distance(from, to)
>> The @from and @to for function node_distance() should be nid.
>>
>> However, pcpu_cpu_distance() in arch/arm64/mm/numa.c just past the
>> cpu id for @from and @to.
>>
>> For this incorrect cpu proximity get from ARCH, it may cause each CPU
>> in one group and make group_cnt out of bound:
>>
>> setup_per_cpu_areas()
>> pcpu_embed_first_chunk()
>> pcpu_build_alloc_info()
>> in pcpu_build_alloc_info, since cpu_distance_fn will return
>> REMOTE_DISTANCE if we pass cpu ids (0,1,2...), so
>> cpu_distance_fn(cpu, tcpu) > LOCAL_DISTANCE will wrongly be ture.
>>
>> This may results in triggering the BUG_ON(unit != nr_units) later:
>>
>> [ 0.000000] kernel BUG at mm/percpu.c:1916!
>> [ 0.000000] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
>> [ 0.000000] Modules linked in:
>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc1-00003-g14155ca-dirty #26
>> [ 0.000000] Hardware name: Hisilicon Hi1616 Evaluation Board (DT)
>> [ 0.000000] task: ffff000008d6e900 task.stack: ffff000008d60000
>> [ 0.000000] PC is at pcpu_embed_first_chunk+0x420/0x704
>> [ 0.000000] LR is at pcpu_embed_first_chunk+0x3bc/0x704
>> [ 0.000000] pc : [<ffff000008c754f4>] lr : [<ffff000008c75490>] pstate: 800000c5
>> [ 0.000000] sp : ffff000008d63eb0
>> [ 0.000000] x29: ffff000008d63eb0 [ 0.000000] x28: 0000000000000000
>> [ 0.000000] x27: 0000000000000040 [ 0.000000] x26: ffff8413fbfcef00
>> [ 0.000000] x25: 0000000000000042 [ 0.000000] x24: 0000000000000042
>> [ 0.000000] x23: 0000000000001000 [ 0.000000] x22: 0000000000000046
>> [ 0.000000] x21: 0000000000000001 [ 0.000000] x20: ffff000008cb3bc8
>> [ 0.000000] x19: ffff8413fbfcf570 [ 0.000000] x18: 0000000000000000
>> [ 0.000000] x17: ffff000008e49ae0 [ 0.000000] x16: 0000000000000003
>> [ 0.000000] x15: 000000000000001e [ 0.000000] x14: 0000000000000004
>> [ 0.000000] x13: 0000000000000000 [ 0.000000] x12: 000000000000006f
>> [ 0.000000] x11: 00000413fbffff00 [ 0.000000] x10: 0000000000000004
>> [ 0.000000] x9 : 0000000000000000 [ 0.000000] x8 : 0000000000000001
>> [ 0.000000] x7 : ffff8413fbfcf63c [ 0.000000] x6 : ffff000008d65d28
>> [ 0.000000] x5 : ffff000008d65e50 [ 0.000000] x4 : 0000000000000000
>> [ 0.000000] x3 : ffff000008cb3cc8 [ 0.000000] x2 : 0000000000000040
>> [ 0.000000] x1 : 0000000000000040 [ 0.000000] x0 : 0000000000000000
>> [...]
>> [ 0.000000] Call trace:
>> [ 0.000000] Exception stack(0xffff000008d63ce0 to 0xffff000008d63e10)
>> [ 0.000000] 3ce0: ffff8413fbfcf570 0001000000000000 ffff000008d63eb0 ffff000008c754f4
>> [ 0.000000] 3d00: ffff000008d63d50 ffff0000081af210 00000413fbfff010 0000000000001000
>> [ 0.000000] 3d20: ffff000008d63d50 ffff0000081af220 00000413fbfff010 0000000000001000
>> [ 0.000000] 3d40: 00000413fbfcef00 0000000000000004 ffff000008d63db0 ffff0000081af390
>> [ 0.000000] 3d60: 00000413fbfcef00 0000000000001000 0000000000000000 0000000000001000
>> [ 0.000000] 3d80: 0000000000000000 0000000000000040 0000000000000040 ffff000008cb3cc8
>> [ 0.000000] 3da0: 0000000000000000 ffff000008d65e50 ffff000008d65d28 ffff8413fbfcf63c
>> [ 0.000000] 3dc0: 0000000000000001 0000000000000000 0000000000000004 00000413fbffff00
>> [ 0.000000] 3de0: 000000000000006f 0000000000000000 0000000000000004 000000000000001e
>> [ 0.000000] 3e00: 0000000000000003 ffff000008e49ae0
>> [ 0.000000] [<ffff000008c754f4>] pcpu_embed_first_chunk+0x420/0x704
>> [ 0.000000] [<ffff000008c6658c>] setup_per_cpu_areas+0x38/0xc8
>> [ 0.000000] [<ffff000008c608d8>] start_kernel+0x10c/0x390
>> [ 0.000000] [<ffff000008c601d8>] __primary_switched+0x5c/0x64
>> [ 0.000000] Code: b8018660 17ffffd7 6b16037f 54000080 (d4210000)
>> [ 0.000000] ---[ end trace 0000000000000000 ]---
>> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>>
>> Fix by getting CPUs proximity through its node. We only care about
>> whether it is LOCAL_DISTANCE or not, for pcpu_build_alloc_info() only
>> use this to group CPUs.
>>
>> Fixes: 7af3a0a99252 ("arm64/numa: support HAVE_SETUP_PER_CPU_AREA")
>> Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Zhen Lei <thunder.leizhen@huawei.com>
>> ---
>> arch/arm64/mm/numa.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index 778a985..34415fc 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -147,7 +147,10 @@ static int __init early_cpu_to_node(int cpu)
>>
>> static int __init pcpu_cpu_distance(unsigned int from, unsigned int to)
>> {
>> - return node_distance(from, to);
>> + if (early_cpu_to_node(from) == early_cpu_to_node(to))
>> + return LOCAL_DISTANCE;
>> + else
>> + return REMOTE_DISTANCE;
> Why can't this be node_distance(early_cpu_to_node(from), early_cpu_to_node(to))?
It's really some coding style preference and the caller function is only care about
it's LOCAL_DISTANCE or not, as we said in the commit message.
But using node_distance() will save few lines of code and no functional change,
will update it.
Thanks
Hanjun
^ 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