* [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 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 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] 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 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 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: 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 2/2] arm64/numa: fix incorrect print of end_pfn
From: Will Deacon @ 2016-10-20 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476935576-59941-2-git-send-email-guohanjun@huawei.com>
On Thu, Oct 20, 2016 at 11:52:56AM +0800, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> When booting on NUMA system with memory-less node (no
> memory dimm on this memory controller), the print
> for setup_node_data() is incorrect:
>
> NUMA: Initmem setup node 2 [mem 0x00000000-0xffffffffffffffff]
>
> It should be 0, not 0xffffffffffffffff as there is
> no memory on that node.
Wouldn't it make more sense to print something useful, like "memory-less
node"?
Will
^ permalink raw reply
* [PATCH 1/2] arm64/numa: fix pcpu_cpu_distance() to get correct CPU proximity
From: Will Deacon @ 2016-10-20 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476935576-59941-1-git-send-email-guohanjun@huawei.com>
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))?
Will
^ permalink raw reply
* [PATCH 4/4] ARM: at91/dt: sama5d4: Add new MA5D4EVK manufacturer compat
From: Alexandre Belloni @ 2016-10-20 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919214044.9615-4-marex@denx.de>
On 19/09/2016 at 23:40:44 +0200, Marek Vasut wrote :
> The board is now manufactured by Aries Embedded GmbH, update compat string.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi | 4 ++--
> arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 0/5] Cavium ThunderX uncore PMU support
From: Mark Rutland @ 2016-10-20 10:44 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?
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/
Mark.
^ permalink raw reply
* [PATCH v2] arm64: Add support for additional relocations in the kexec purgatory code
From: Catalin Marinas @ 2016-10-20 10:43 UTC (permalink / raw)
To: linux-arm-kernel
When compiling the kexec-tools with gcc6, the following additional
reolcations are generated in the purgatory.ro file:
R_AARCH64_ADR_PREL_PG_HI21
R_AARCH64_ADD_ABS_LO12_NC
R_AARCH64_LDST64_ABS_LO12_NC
This patch modifies the arm64 machine_apply_elf_rel() function to handle
these relocations.
Cc: Geoff Levand <geoff@infradead.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
Changes for v2:
- Fixed the type string to drop the "R_AARCH64_" prefix
kexec/arch/arm64/kexec-arm64.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 2e8839a..e067a23 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -550,6 +550,14 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
# define R_AARCH64_ADR_PREL_LO21 274
#endif
+#if !defined(R_AARCH64_ADR_PREL_PG_HI21)
+# define R_AARCH64_ADR_PREL_PG_HI21 275
+#endif
+
+#if !defined(R_AARCH64_ADD_ABS_LO12_NC)
+# define R_AARCH64_ADD_ABS_LO12_NC 277
+#endif
+
#if !defined(R_AARCH64_JUMP26)
# define R_AARCH64_JUMP26 282
#endif
@@ -558,10 +566,15 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
# define R_AARCH64_CALL26 283
#endif
+#if !defined(R_AARCH64_LDST64_ABS_LO12_NC)
+# define R_AARCH64_LDST64_ABS_LO12_NC 286
+#endif
+
uint64_t *loc64;
uint32_t *loc32;
uint64_t *location = (uint64_t *)ptr;
uint64_t data = *location;
+ uint64_t imm;
const char *type = NULL;
switch(r_type) {
@@ -585,6 +598,19 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
*loc32 = cpu_to_le32(le32_to_cpu(*loc32)
+ (((value - address) << 3) & 0xffffe0));
break;
+ case R_AARCH64_ADR_PREL_PG_HI21:
+ type = "ADR_PREL_PG_HI21";
+ imm = ((value & ~0xfff) - (address & ~0xfff)) >> 12;
+ loc32 = ptr;
+ *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
+ + ((imm & 3) << 29) + ((imm & 0x1ffffc) << (5 - 2)));
+ break;
+ case R_AARCH64_ADD_ABS_LO12_NC:
+ type = "ADD_ABS_LO12_NC";
+ loc32 = ptr;
+ *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
+ + ((value & 0xfff) << 10));
+ break;
case R_AARCH64_JUMP26:
type = "JUMP26";
loc32 = ptr;
@@ -597,6 +623,15 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
*loc32 = cpu_to_le32(le32_to_cpu(*loc32)
+ (((value - address) >> 2) & 0x3ffffff));
break;
+ case R_AARCH64_LDST64_ABS_LO12_NC:
+ if (value & 7)
+ die("%s: ERROR Unaligned value: %lx\n", __func__,
+ value);
+ type = "LDST64_ABS_LO12_NC";
+ loc32 = ptr;
+ *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
+ + ((value & 0xff8) << (10 - 3)));
+ break;
default:
die("%s: ERROR Unknown type: %lu\n", __func__, r_type);
break;
--
2.10.0
^ permalink raw reply related
* [PATCH v3 0/5] Cavium ThunderX uncore PMU support
From: Mark Rutland @ 2016-10-20 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476955841-27898-1-git-send-email-jglauber@cavium.com>
On Thu, Oct 20, 2016 at 11:30:36AM +0200, Jan Glauber wrote:
> Sorry for the long time it took for re-cooking this patch set.
> The v3 should address all of Marks previous comments, things I didn't
> change are listed below.
>
> Not changed:
> - Stick to NUMA node ID to detect the socket a device belongs to but made
> uncore depend on CONFIG_NUMA.
> - Stick to initcall for uncore framework because it is easier to do the
> scanning for the same type of PCI devices, also I don't know if the PCI layer
> would allow for several drivers to register for the same device ID.
>
> 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.
I take it you were tryign to open per-task, non system-wide events?
As a shared resource, per-task events do not make sense, and thus using
perf_sw_context does not make sense.
I take it If you expose a cpumask, and open the event in system-wide
mode (passing '-a' to perf tool), things should work even if using
perf_invalid_context.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 0/5] Cavium ThunderX uncore PMU support
From: Peter Zijlstra @ 2016-10-20 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476955841-27898-1-git-send-email-jglauber@cavium.com>
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?
^ permalink raw reply
* [PATCH 15/19] reset: sti: Remove STiH415/6 reset support
From: Philipp Zabel @ 2016-10-20 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b9a50ba1-9932-0d71-6b61-efccee587d74@st.com>
Am Dienstag, den 11.10.2016, 09:05 +0200 schrieb Patrice Chotard:
> Hi Philipp
>
> On 09/27/2016 10:02 AM, Philipp Zabel wrote:
> > Hi Peter,
> >
> > Am Mittwoch, den 14.09.2016, 14:27 +0100 schrieb Peter Griffin:
> >> Support for STiH415/6 SoCs is being removed from the
> >> kernel because the platforms are obsolete. This patch removes
> >> the reset drivers for these SoC's.
> >>
> >> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> >> Cc: <p.zabel@pengutronix.de>
> >> ---
>
> [...]
>
> >> - .driver = {
> >> - .name = "reset-stih416",
> >> - .of_match_table = stih416_reset_match,
> >> - },
> >> -};
> >> -
> >> -static int __init stih416_reset_init(void)
> >> -{
> >> - return platform_driver_register(&stih416_reset_driver);
> >> -}
> >> -arch_initcall(stih416_reset_init);
> >
> > Can I pick up patches 15 and 19, or are there dependencies in the
> > series?
>
> Yes, you can pick up patches 15 and 19
Done.
regards
Philipp
^ permalink raw reply
* [PATCHv3 4/4] arm64: dump: Add checking for writable and exectuable pages
From: Ard Biesheuvel @ 2016-10-20 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476828091-17802-5-git-send-email-labbott@redhat.com>
On 18 October 2016 at 23:01, Laura Abbott <labbott@redhat.com> wrote:
>
> Page mappings with full RWX permissions are a security risk. x86
> has an option to walk the page tables and dump any bad pages.
> (See e1a58320a38d ("x86/mm: Warn on W^X mappings")). Add a similar
> implementation for arm64.
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Tested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> v3: Rebased for header guard fixup, whitespace fixes
> ---
> arch/arm64/Kconfig.debug | 29 +++++++++++++++++++++++
> arch/arm64/include/asm/ptdump.h | 8 +++++++
> arch/arm64/mm/dump.c | 52 +++++++++++++++++++++++++++++++++++++++++
> arch/arm64/mm/mmu.c | 2 ++
> 4 files changed, 91 insertions(+)
>
> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
> index 21a5b74..d1ebd46 100644
> --- a/arch/arm64/Kconfig.debug
> +++ b/arch/arm64/Kconfig.debug
> @@ -42,6 +42,35 @@ config ARM64_RANDOMIZE_TEXT_OFFSET
> of TEXT_OFFSET and platforms must not require a specific
> value.
>
> +config DEBUG_WX
> + bool "Warn on W+X mappings at boot"
> + select ARM64_PTDUMP_CORE
> + ---help---
> + Generate a warning if any W+X mappings are found at boot.
> +
> + This is useful for discovering cases where the kernel is leaving
> + W+X mappings after applying NX, as such mappings are a security risk.
> + This check also includes UXN, which should be set on all kernel
> + mappings.
> +
> + Look for a message in dmesg output like this:
> +
> + arm64/mm: Checked W+X mappings: passed, no W+X pages found.
> +
> + or like this, if the check failed:
> +
> + arm64/mm: Checked W+X mappings: FAILED, <N> W+X pages found.
> +
> + Note that even if the check fails, your kernel is possibly
> + still fine, as W+X mappings are not a security hole in
> + themselves, what they do is that they make the exploitation
> + of other unfixed kernel bugs easier.
> +
> + There is no runtime or memory usage effect of this option
> + once the kernel has booted up - it's a one time check.
> +
> + If in doubt, say "Y".
> +
> config DEBUG_SET_MODULE_RONX
> bool "Set loadable kernel module data as NX and text as RO"
> depends on MODULES
> diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
> index f72ee69..6afd847 100644
> --- a/arch/arm64/include/asm/ptdump.h
> +++ b/arch/arm64/include/asm/ptdump.h
> @@ -42,5 +42,13 @@ static inline int ptdump_debugfs_register(struct ptdump_info *info,
> return 0;
> }
> #endif
> +void ptdump_check_wx(void);
> #endif /* CONFIG_ARM64_PTDUMP_CORE */
> +
> +#ifdef CONFIG_DEBUG_WX
> +#define debug_checkwx() ptdump_check_wx()
> +#else
> +#define debug_checkwx() do { } while (0)
> +#endif
> +
> #endif /* __ASM_PTDUMP_H */
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index bb36649..4913af5 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -74,6 +74,8 @@ struct pg_state {
> unsigned long start_address;
> unsigned level;
> u64 current_prot;
> + bool check_wx;
> + unsigned long wx_pages;
> };
>
> struct prot_bits {
> @@ -202,6 +204,35 @@ static void dump_prot(struct pg_state *st, const struct prot_bits *bits,
> }
> }
>
> +static void note_prot_uxn(struct pg_state *st, unsigned long addr)
> +{
> + if (!st->check_wx)
> + return;
> +
> + if ((st->current_prot & PTE_UXN) == PTE_UXN)
> + return;
> +
> + WARN_ONCE(1, "arm64/mm: Found non-UXN mapping at address %p/%pS\n",
> + (void *)st->start_address, (void *)st->start_address);
> +
> + st->wx_pages += (addr - st->start_address) / PAGE_SIZE;
> +}
> +
> +static void note_prot_wx(struct pg_state *st, unsigned long addr)
> +{
> + if (!st->check_wx)
> + return;
> + if ((st->current_prot & PTE_RDONLY) == PTE_RDONLY)
> + return;
> + if ((st->current_prot & PTE_PXN) == PTE_PXN)
> + return;
> +
> + WARN_ONCE(1, "arm64/mm: Found insecure W+X mapping at address %p/%pS\n",
> + (void *)st->start_address, (void *)st->start_address);
> +
> + st->wx_pages += (addr - st->start_address) / PAGE_SIZE;
> +}
> +
Why are these separate functions, and why is wx_pages increased twice,
potentially?
Given how rare non-UXN kernel mappings should be, could we not just add
if ((st->current_prot & PTE_UXN) == 0)
WARN(xxx)
(without the _ONCE) to note_prot_wx(), and drop note_prot_uxn() entirely?
> static void note_page(struct pg_state *st, unsigned long addr, unsigned level,
> u64 val)
> {
> @@ -219,6 +250,8 @@ static void note_page(struct pg_state *st, unsigned long addr, unsigned level,
> unsigned long delta;
>
> if (st->current_prot) {
> + note_prot_uxn(st, addr);
> + note_prot_wx(st, addr);
> pt_dump_seq_printf(st->seq, "0x%016lx-0x%016lx ",
> st->start_address, addr);
>
> @@ -344,6 +377,25 @@ static struct ptdump_info kernel_ptdump_info = {
> .base_addr = VA_START,
> };
>
> +void ptdump_check_wx(void)
> +{
> + struct pg_state st = {
> + .seq = NULL,
> + .marker = (struct addr_marker[]) {
> + { -1, NULL},
> + },
> + .check_wx = true,
> + };
> +
> + walk_pgd(&st, &init_mm, 0);
> + note_page(&st, 0, 0, 0);
> + if (st.wx_pages)
> + pr_info("Checked W+X mappings: FAILED, %lu W+X pages found\n",
> + st.wx_pages);
Could we upgrade this to pr_warn?
> + else
> + pr_info("Checked W+X mappings: passed, no W+X pages found\n");
> +}
> +
> static int ptdump_init(void)
> {
> ptdump_initialize();
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 05615a3..2cbe2fe 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -42,6 +42,7 @@
> #include <asm/tlb.h>
> #include <asm/memblock.h>
> #include <asm/mmu_context.h>
> +#include <asm/ptdump.h>
>
> u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
>
> @@ -396,6 +397,7 @@ void mark_rodata_ro(void)
> section_size = (unsigned long)__init_begin - (unsigned long)__start_rodata;
> create_mapping_late(__pa(__start_rodata), (unsigned long)__start_rodata,
> section_size, PAGE_KERNEL_RO);
> + debug_checkwx();
> }
>
> static void __init map_kernel_segment(pgd_t *pgd, void *va_start, void *va_end,
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Sekhar Nori @ 2016-10-20 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bb7bac91-8eb1-fe23-ca9c-857e0fda6ecd@ti.com>
On Thursday 20 October 2016 03:51 PM, Tomi Valkeinen wrote:
> On 20/10/16 13:07, Sekhar Nori wrote:
>
>> Per me, compatible property is an ordered list precisely for the reason
>> that things should continue to "work" with as closely matched driver as
>> possible. So even if someone is running a kernel which does not
>> recognize "ti,da850-tilcdc", it should still be able to probe the driver
>> based on "ti,am33xx-tilcdc" and provide as close to full functionality
>> as possible.
>>
>> That said, I will not insist on keeping it around if Tomi is
>> uncomfortable. And having read the binding documentation accepted by
>> Jyri, it actually says the compatible property should be __one of__
>> "ti,am33xx-tilcdc" or "ti,da850-tilcdc".
>
> Well, they are just not compatible as far as I know. If the LCDC on
> DA850 would be identified as AM335x LCDC, and used as such, it would not
> work at all. They have different registers, AM335x LCDC has registers
> that do not exist on DA850.
>
> With our driver it happens to work, because the driver looks at the IP
> revision in the registers, and then decides that this IP is not AM335x
> LCDC even if the dts says so. But I see that as a driver "feature",
> nothing that the .dts can depend on.
>
> Perhaps it might work the other way around, using DA850 driver on
> AM335x, as DA850 LCDC is a kind of subset of AM335x LCDC. But I'm not
> sure even about that.
Alright, thanks for the detailed explanation. I dropped the "ti,am33xx-
tilcdc" from the list and here is the updated patch I am queuing for
reference.
Thanks,
Sekhar
--8<--
Author: Karl Beldan <kbeldan@baylibre.com>
AuthorDate: Wed Oct 5 15:05:32 2016 +0200
Commit: Sekhar Nori <nsekhar@ti.com>
CommitDate: Thu Oct 20 15:57:21 2016 +0530
ARM: dts: da850: add a node for the LCD controller
Add pins used by the LCD controller and a disabled LCDC node to be
reused in device trees including da850.dtsi.
Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
[Bartosz:
- added the commit description
- changed the dt node name to a generic one
- added a da850-specific compatible string
- removed the tilcdc,panel node
- moved the pins definitions to da850.dtsi as suggested by
Sekhar Nori (was in: da850-lcdk.dts)]
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
[nsekhar at ti.com: fix compatible property and remove interrupt-parent]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b91c680..901d5c98d5f0 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -186,6 +186,27 @@
0xc 0x88888888 0xffffffff
>;
};
+ lcd_pins: pinmux_lcd_pins {
+ pinctrl-single,bits = <
+ /*
+ * LCD_D[2], LCD_D[3], LCD_D[4], LCD_D[5],
+ * LCD_D[6], LCD_D[7]
+ */
+ 0x40 0x22222200 0xffffff00
+ /*
+ * LCD_D[10], LCD_D[11], LCD_D[12], LCD_D[13],
+ * LCD_D[14], LCD_D[15], LCD_D[0], LCD_D[1]
+ */
+ 0x44 0x22222222 0xffffffff
+ /* LCD_D[8], LCD_D[9] */
+ 0x48 0x00000022 0x000000ff
+
+ /* LCD_PCLK */
+ 0x48 0x02000000 0x0f000000
+ /* LCD_AC_ENB_CS, LCD_VSYNC, LCD_HSYNC */
+ 0x4c 0x02000022 0x0f0000ff
+ >;
+ };
};
edma0: edma at 0 {
@@ -399,6 +420,13 @@
<&edma0 0 1>;
dma-names = "tx", "rx";
};
+
+ display: display at 213000 {
+ compatible = "ti,da850-tilcdc";
+ reg = <0x213000 0x1000>;
+ interrupts = <52>;
+ status = "disabled";
+ };
};
aemif: aemif at 68000000 {
compatible = "ti,da850-aemif";
^ permalink raw reply related
* [PATCH v2 3/6] ARM: at91: Add armv7m support
From: Alexandre Belloni @ 2016-10-20 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5506721.HBUId2vnJb@wuerfel>
Hi,
On 20/10/2016 at 11:52:20 +0200, Arnd Bergmann wrote :
> On Thursday, October 20, 2016 11:41:32 AM CEST Alexandre Belloni wrote:
> > +
> > +static void __init samx7_dt_device_init(void)
> > +{
> > + struct soc_device *soc;
> > + struct device *soc_dev = NULL;
> > +
> > + soc = at91_soc_init(samx7_socs);
> > + if (soc)
> > + soc_dev = soc_device_to_device(soc);
> > +
> > + of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);
> > +}
>
> This was initially the idea for the soc_device, but we've stopped
> using it as the parent for the on-chip devices a while ago.
>
> Just register the device for identification here, and use
> of_platform_default_populate with a NULL parent as most others do.
>
> We should also investigate whether we can convert the three other
> at91 variants to do the same without breaking expectations in user space.
>
My opinion is that we could just remove the whole at91_soc_init stuff
but I think Nicolas still wants the two info lines to be printed for
debugging/support purposes. I'm not sure how much this is used anyway
and I don't find the sysfs attributes to be particularly useful.
Also, removing soc.c is a 10% reduction of the code in mach-at91 ;)
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Tomi Valkeinen @ 2016-10-20 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c6fcceb-c6f2-219d-492a-a8b38fd83093@ti.com>
On 20/10/16 13:07, Sekhar Nori wrote:
> Per me, compatible property is an ordered list precisely for the reason
> that things should continue to "work" with as closely matched driver as
> possible. So even if someone is running a kernel which does not
> recognize "ti,da850-tilcdc", it should still be able to probe the driver
> based on "ti,am33xx-tilcdc" and provide as close to full functionality
> as possible.
>
> That said, I will not insist on keeping it around if Tomi is
> uncomfortable. And having read the binding documentation accepted by
> Jyri, it actually says the compatible property should be __one of__
> "ti,am33xx-tilcdc" or "ti,da850-tilcdc".
Well, they are just not compatible as far as I know. If the LCDC on
DA850 would be identified as AM335x LCDC, and used as such, it would not
work at all. They have different registers, AM335x LCDC has registers
that do not exist on DA850.
With our driver it happens to work, because the driver looks at the IP
revision in the registers, and then decides that this IP is not AM335x
LCDC even if the dts says so. But I see that as a driver "feature",
nothing that the .dts can depend on.
Perhaps it might work the other way around, using DA850 driver on
AM335x, as DA850 LCDC is a kind of subset of AM335x LCDC. But I'm not
sure even about that.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/b0a52fc5/attachment.sig>
^ permalink raw reply
* [PATCHv3 1/4] arm64: dump: Make ptdump debugfs a separate option
From: Ard Biesheuvel @ 2016-10-20 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476828091-17802-2-git-send-email-labbott@redhat.com>
On 18 October 2016 at 23:01, Laura Abbott <labbott@redhat.com> wrote:
>
> ptdump_register currently initializes a set of page table information and
> registers debugfs. There are uses for the ptdump option without wanting the
> debugfs options. Split this out to make it a separate option.
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Tested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> v3: Minor header guard fixup.
>
> Mark Rutland pointed out that this needs to be reviewed by the EFI maintainers
> so I'm explicitly adding appropriate people/lists.
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/Kconfig.debug | 6 +++++-
> arch/arm64/include/asm/ptdump.h | 15 +++++++++------
> arch/arm64/mm/Makefile | 3 ++-
> arch/arm64/mm/dump.c | 26 +++++---------------------
> arch/arm64/mm/ptdump_debugfs.c | 31 +++++++++++++++++++++++++++++++
> drivers/firmware/efi/arm-runtime.c | 4 ++--
> 6 files changed, 54 insertions(+), 31 deletions(-)
> create mode 100644 arch/arm64/mm/ptdump_debugfs.c
>
> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
> index b661fe7..21a5b74 100644
> --- a/arch/arm64/Kconfig.debug
> +++ b/arch/arm64/Kconfig.debug
> @@ -2,9 +2,13 @@ menu "Kernel hacking"
>
> source "lib/Kconfig.debug"
>
> -config ARM64_PTDUMP
> +config ARM64_PTDUMP_CORE
> + def_bool n
> +
> +config ARM64_PTDUMP_DEBUGFS
> bool "Export kernel pagetable layout to userspace via debugfs"
> depends on DEBUG_KERNEL
> + select ARM64_PTDUMP_CORE
> select DEBUG_FS
> help
> Say Y here if you want to show the kernel pagetable layout in a
> diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
> index 07b8ed0..16335da 100644
> --- a/arch/arm64/include/asm/ptdump.h
> +++ b/arch/arm64/include/asm/ptdump.h
> @@ -16,9 +16,10 @@
> #ifndef __ASM_PTDUMP_H
> #define __ASM_PTDUMP_H
>
> -#ifdef CONFIG_ARM64_PTDUMP
> +#ifdef CONFIG_ARM64_PTDUMP_CORE
>
> #include <linux/mm_types.h>
> +#include <linux/seq_file.h>
>
> struct addr_marker {
> unsigned long start_address;
> @@ -32,13 +33,15 @@ struct ptdump_info {
> unsigned long max_addr;
> };
>
> -int ptdump_register(struct ptdump_info *info, const char *name);
> -
> +void ptdump_walk_pgd(struct seq_file *s, struct ptdump_info *info);
> +#ifdef CONFIG_ARM64_PTDUMP_DEBUGFS
> +int ptdump_debugfs_register(struct ptdump_info *info, const char *name);
> #else
> -static inline int ptdump_register(struct ptdump_info *info, const char *name)
> +static inline int ptdump_debugfs_register(struct ptdump_info *info,
> + const char *name)
> {
> return 0;
> }
> -#endif /* CONFIG_ARM64_PTDUMP */
> -
> +#endif
> +#endif /* CONFIG_ARM64_PTDUMP_CORE */
> #endif /* __ASM_PTDUMP_H */
> diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
> index 54bb209..e703fb9 100644
> --- a/arch/arm64/mm/Makefile
> +++ b/arch/arm64/mm/Makefile
> @@ -3,7 +3,8 @@ obj-y := dma-mapping.o extable.o fault.o init.o \
> ioremap.o mmap.o pgd.o mmu.o \
> context.o proc.o pageattr.o
> obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
> -obj-$(CONFIG_ARM64_PTDUMP) += dump.o
> +obj-$(CONFIG_ARM64_PTDUMP_CORE) += dump.o
> +obj-$(CONFIG_ARM64_PTDUMP_DEBUGFS) += ptdump_debugfs.o
> obj-$(CONFIG_NUMA) += numa.o
>
> obj-$(CONFIG_KASAN) += kasan_init.o
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index 9c3e75d..f0f0be7 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -304,9 +304,8 @@ static void walk_pgd(struct pg_state *st, struct mm_struct *mm,
> }
> }
>
> -static int ptdump_show(struct seq_file *m, void *v)
> +void ptdump_walk_pgd(struct seq_file *m, struct ptdump_info *info)
> {
> - struct ptdump_info *info = m->private;
> struct pg_state st = {
> .seq = m,
> .marker = info->markers,
> @@ -315,33 +314,16 @@ static int ptdump_show(struct seq_file *m, void *v)
> walk_pgd(&st, info->mm, info->base_addr);
>
> note_page(&st, 0, 0, 0);
> - return 0;
> }
>
> -static int ptdump_open(struct inode *inode, struct file *file)
> +static void ptdump_initialize(void)
> {
> - return single_open(file, ptdump_show, inode->i_private);
> -}
> -
> -static const struct file_operations ptdump_fops = {
> - .open = ptdump_open,
> - .read = seq_read,
> - .llseek = seq_lseek,
> - .release = single_release,
> -};
> -
> -int ptdump_register(struct ptdump_info *info, const char *name)
> -{
> - struct dentry *pe;
> unsigned i, j;
>
> for (i = 0; i < ARRAY_SIZE(pg_level); i++)
> if (pg_level[i].bits)
> for (j = 0; j < pg_level[i].num; j++)
> pg_level[i].mask |= pg_level[i].bits[j].mask;
> -
> - pe = debugfs_create_file(name, 0400, NULL, info, &ptdump_fops);
> - return pe ? 0 : -ENOMEM;
> }
>
> static struct ptdump_info kernel_ptdump_info = {
> @@ -352,6 +334,8 @@ static struct ptdump_info kernel_ptdump_info = {
>
> static int ptdump_init(void)
> {
> - return ptdump_register(&kernel_ptdump_info, "kernel_page_tables");
> + ptdump_initialize();
> + return ptdump_debugfs_register(&kernel_ptdump_info,
> + "kernel_page_tables");
> }
> device_initcall(ptdump_init);
> diff --git a/arch/arm64/mm/ptdump_debugfs.c b/arch/arm64/mm/ptdump_debugfs.c
> new file mode 100644
> index 0000000..eee4d86
> --- /dev/null
> +++ b/arch/arm64/mm/ptdump_debugfs.c
> @@ -0,0 +1,31 @@
> +#include <linux/debugfs.h>
> +#include <linux/seq_file.h>
> +
> +#include <asm/ptdump.h>
> +
> +static int ptdump_show(struct seq_file *m, void *v)
> +{
> + struct ptdump_info *info = m->private;
> + ptdump_walk_pgd(m, info);
> + return 0;
> +}
> +
> +static int ptdump_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, ptdump_show, inode->i_private);
> +}
> +
> +static const struct file_operations ptdump_fops = {
> + .open = ptdump_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> +};
> +
> +int ptdump_debugfs_register(struct ptdump_info *info, const char *name)
> +{
> + struct dentry *pe;
> + pe = debugfs_create_file(name, 0400, NULL, info, &ptdump_fops);
> + return pe ? 0 : -ENOMEM;
> +
> +}
> diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
> index 7c75a8d..349dc3e 100644
> --- a/drivers/firmware/efi/arm-runtime.c
> +++ b/drivers/firmware/efi/arm-runtime.c
> @@ -39,7 +39,7 @@ static struct mm_struct efi_mm = {
> .mmlist = LIST_HEAD_INIT(efi_mm.mmlist),
> };
>
> -#ifdef CONFIG_ARM64_PTDUMP
> +#ifdef CONFIG_ARM64_PTDUMP_DEBUGFS
> #include <asm/ptdump.h>
>
> static struct ptdump_info efi_ptdump_info = {
> @@ -53,7 +53,7 @@ static struct ptdump_info efi_ptdump_info = {
>
> static int __init ptdump_init(void)
> {
> - return ptdump_register(&efi_ptdump_info, "efi_page_tables");
> + return ptdump_debugfs_register(&efi_ptdump_info, "efi_page_tables");
> }
> device_initcall(ptdump_init);
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] arm64: kernel: force ET_DYN ELF type for CONFIG_RELOCATABLE=y
From: Ard Biesheuvel @ 2016-10-20 10:12 UTC (permalink / raw)
To: linux-arm-kernel
GNU ld used to set the ELF file type to ET_DYN for PIE executables, which
is the same file type used for shared libraries. However, this was changed
recently, and now PIE executables are emitted as ET_EXEC instead.
The distinction is only relevant for ELF loaders, and so there is little
reason to care about the difference when building the kernel, which is
why the change has gone unnoticed until now.
However, debuggers do use the ELF binary, and expect ET_EXEC type files
to appear in memory at the exact offset described in the ELF metadata.
This means source level debugging is no longer possible when KASLR is in
effect or when executing the stub.
So add the -shared LD option when building with CONFIG_RELOCATABLE=y. This
forces the ELF file type to be set to ET_DYN (which is what you get when
building with binutils 2.24 and earlier anyway), and has no other ill
effects.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
The difference in output between ET_EXEC and ET_DYN file types for
'readelf -a vmlinux':
--- /tmp/exec 2016-10-19 17:46:51.368841538 +0100
+++ /tmp/dyn 2016-10-19 17:46:01.774879088 +0100
@@ -5,7 +5,7 @@
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
- Type: EXEC (Executable file)
+ Type: DYN (Shared object file)
Machine: AArch64
Version: 0x1
Entry point address: 0xffff000008080000
@@ -239199,7 +239199,7 @@
108973: 0000000000000000 0 FILE LOCAL DEFAULT ABS
108974: ffff0000089800a0 0 OBJECT LOCAL DEFAULT ABS _GLOBAL_OFFSET_TABLE_
108975: ffff0000081a7c70 0 NOTYPE LOCAL DEFAULT 2 $x
-108976: ffff0000081a7c74 8 FUNC LOCAL DEFAULT 2 e843419 at 001a_00000473_99c
+108976: ffff0000081a7c74 8 FUNC LOCAL DEFAULT 2 e843419 at 001a_00000472_99c
108977: ffff0000081a7c74 0 NOTYPE LOCAL DEFAULT 2 $x
108978: ffff000008d7c118 136 FUNC GLOBAL DEFAULT 19 __efistub_fdt_delprop
108979: ffff000008819db8 36 FUNC GLOBAL DEFAULT 2 arch_timer_get_kvm_info
@@ -269256,4 +269256,4 @@
Displaying notes found at file offset 0x00cf5740 with length 0x00000024:
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
- Build ID: a63334609e04d620ea175bb9e88bc68989dc0402
+ Build ID: 7f489d756b1799111b0128ffa61546c2ac1f6e2a
arch/arm64/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index ab51aed6b6c1..3635b8662724 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -15,7 +15,7 @@ CPPFLAGS_vmlinux.lds = -DTEXT_OFFSET=$(TEXT_OFFSET)
GZFLAGS :=-9
ifneq ($(CONFIG_RELOCATABLE),)
-LDFLAGS_vmlinux += -pie -Bsymbolic
+LDFLAGS_vmlinux += -pie -shared -Bsymbolic
endif
ifeq ($(CONFIG_ARM64_ERRATUM_843419),y)
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: Add support for additional relocations in the kexec purgatory code
From: Catalin Marinas @ 2016-10-20 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15f9c4d2-34a8-fd74-05ec-0a8df41bc93a@infradead.org>
On Wed, Oct 19, 2016 at 03:52:30PM -0700, Geoff Levand wrote:
> Hi Catalin,
>
> On 10/19/2016 08:58 AM, Catalin Marinas wrote:
> > diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
> > index 2e8839a..e067a23 100644
> > --- a/kexec/arch/arm64/kexec-arm64.c
> > +++ b/kexec/arch/arm64/kexec-arm64.c
> > @@ -585,6 +598,19 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
> > *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
> > + (((value - address) << 3) & 0xffffe0));
> > break;
> > + case R_AARCH64_ADR_PREL_PG_HI21:
> > + type = "ADR_PREL_PG_HI21";
> > + imm = ((value & ~0xfff) - (address & ~0xfff)) >> 12;
> > + loc32 = ptr;
> > + *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
> > + + ((imm & 3) << 29) + ((imm & 0x1ffffc) << (5 - 2)));
> > + break;
> > + case R_AARCH64_ADD_ABS_LO12_NC:
> > + type = "R_AARCH64_ADD_ABS_LO12_NC";
>
> Following with the others, this should be 'type = "ADD_ABS_LO12_NC"'.
Ah, I missed this detail. I'll post a v2 shortly.
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH v5 11/23] usb: chipidea: Emulate OTGSC interrupt enable path
From: Peter Chen @ 2016-10-20 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147694652997.28344.1048935134595924905@sboyd-linaro>
On Wed, Oct 19, 2016 at 11:55:29PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-10-19 01:02:11)
> > On Tue, Oct 18, 2016 at 06:53:07PM -0700, Stephen Boyd wrote:
> > > If you're asking if I've made modifications to extcon-usb-gpio, then the
> > > answer is no. The branch on linaro.org git server from the cover-letter
> > > is the branch I've used to test this with. This patch is specifically to
> > > fix issues with that design on the db410c board that has only one pin
> > > for ID and vbus detection. It's the schematic that we've discussed in
> > > another thread.
> > >
> > > extcon-usb-gpio sends two extcon events, EXTCON_USB_HOST (for the id
> > > pin) and EXTCON_USB (for the vbus). So afaik it does support vbus
> > > events.
> > >
> >
> > Hmm, in fact, your ID event is the same with vbus event, you take
> > external vbus event as ID event for extcon-usb-gpio handling. Yes,
> > it can work due to it sends EXTCON_USB_HOST event first.
> >
> > Where you change the USB_SW_SEL_PM pin?
>
> Currently that is done with the mux driver I sent based on the extcon
> event. We don't know if that's before or after the controller handles
> the extcon event though, so the pin should probably be changed from the
> chipidea driver instead to be more explicit. Why do you ask though?
I was just curious how you handle it, now I am clear. From my point,
the suitable way may be: mux driver + user app (echo role through
debugfs). The extcon-usb-gpio is not necessary, since you have already
known role at mux driver.
The current kernel has no framework to handle dual-role switch at kernel
space.
> > At some situations, the vbus may already be there before starting
> > gadget. So we need to check vbus event after switch to gadget in
> > order to handle missing vbus event. The typical use cases are plugging
> > vbus cable before driver load or the vbus has already been there
> > after stopping host but before starting gadget.
> >
> > Signed-off-by: Peter Chen <peter.chen@nxp.com>
>
> Yes this should work. Light testing doesn't show any problems so far.
>
> > ---
> > drivers/usb/chipidea/core.c | 4 ----
> > drivers/usb/chipidea/otg.c | 10 ++++++----
> > drivers/usb/chipidea/udc.c | 2 ++
> > 3 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index b814d91..a7d2c68 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -992,10 +992,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
> > }
> >
> > if (!ci_otg_is_fsm_mode(ci)) {
> > - /* only update vbus status for peripheral */
> > - if (ci->role == CI_ROLE_GADGET)
> > - ci_handle_vbus_change(ci);
> > -
> > ret = ci_role_start(ci, ci->role);
> > if (ret) {
> > dev_err(dev, "can't start %s role\n",
> > diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
> > index 695f3fe..99c0709 100644
> > --- a/drivers/usb/chipidea/otg.c
> > +++ b/drivers/usb/chipidea/otg.c
> > @@ -134,9 +134,9 @@ void ci_handle_vbus_change(struct ci_hdrc *ci)
> > if (!ci->is_otg)
> > return;
> >
> > - if (hw_read_otgsc(ci, OTGSC_BSV))
> > + if (hw_read_otgsc(ci, OTGSC_BSV) && !ci->vbus_active)
> > usb_gadget_vbus_connect(&ci->gadget);
> > - else
> > + else if (!hw_read_otgsc(ci, OTGSC_BSV) && ci->vbus_active)
> > usb_gadget_vbus_disconnect(&ci->gadget);
> > }
> >
> > @@ -175,10 +175,12 @@ static void ci_handle_id_switch(struct ci_hdrc *ci)
> >
> > ci_role_stop(ci);
> >
> > - if (role == CI_ROLE_GADGET)
> > + if (role == CI_ROLE_GADGET &&
> > + IS_ERR(ci->platdata->vbus_extcon.edev))
> > /*
> > * wait vbus lower than OTGSC_BSV before connecting
> > - * to host
> > + * to host. And if vbus's status is an external
> > + * connector, it doesn't need to wait here.
>
> because OTGSC_BSV will toggle based on the extcon state and not when the
> phy connects to the host? It would be good to explain why it's not
> needed instead of just repeating what the code is doing.
>
Thanks, will change like below
"
If connecting status is from an external connector instead of register,
we don't need to care vbus on the board, since it will not affect external
connector status.
"
> > */
> > hw_wait_vbus_lower_bsv(ci);
> >
> > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > index 001c2fa..184ffba 100644
> > --- a/drivers/usb/chipidea/udc.c
> > +++ b/drivers/usb/chipidea/udc.c
> > @@ -1963,6 +1963,8 @@ static int udc_id_switch_for_device(struct ci_hdrc *ci)
> > /* Clear and enable BSV irq */
> > hw_write_otgsc(ci, OTGSC_BSVIS | OTGSC_BSVIE,
> > OTGSC_BSVIS | OTGSC_BSVIE);
> > + /* vbus change may has already been occurred */
>
> "vbus change may have already occurred"?
Yes, will change.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Sekhar Nori @ 2016-10-20 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJXT8hcSc0-svbwAq5r_JOFsYV852gtE0vuXL8hHykXnRQ@mail.gmail.com>
On Monday 17 October 2016 07:31 PM, Bartosz Golaszewski wrote:
> 2016-10-17 14:29 GMT+02:00 Tomi Valkeinen <tomi.valkeinen@ti.com>:
>> On 17/10/16 14:40, Laurent Pinchart wrote:
>>> Hello,
>>>
>>> On Monday 17 Oct 2016 10:33:58 Tomi Valkeinen wrote:
>>>> On 17/10/16 10:12, Sekhar Nori wrote:
>>>>> On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
>>>>>> On 15/10/16 20:42, Sekhar Nori wrote:
>>>>>>>> diff --git a/arch/arm/boot/dts/da850.dtsi
>>>>>>>> b/arch/arm/boot/dts/da850.dtsi
>>>>>>>> index f79e1b9..32908ae 100644
>>>>>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>>>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>>>>>> @@ -399,6 +420,14 @@
>>>>>>>> <&edma0 0 1>;
>>>>>>>> dma-names = "tx", "rx";
>>>>>>>> };
>>>>>>>> +
>>>>>>>> + display: display at 213000 {
>>>>>>>> + compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
>>>>>>>
>>>>>>> This should instead be:
>>>>>>>
>>>>>>> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>>>>>>>
>>>>>>> as the closest match should appear first in the list.
>>>>>>
>>>>>> Actually I don't think that's correct. The LCDC on da850 is not
>>>>>> compatible with the LCDC on AM335x. I think it should be just
>>>>>> "ti,da850-tilcdc".
>>>>>
>>>>> So if "ti,am33xx-tilcdc" is used, the display wont work at all? If thats
>>>>> the case, I wonder how the patch passed testing. Bartosz?
>>>>
>>>> AM3 has "version 2" of LCDC, whereas DA850 is v1. They are quite
>>>> similar, but different.
>>>>
>>>> The driver gets the version number from LCDC's register, and acts based
>>>> on that, so afaik the compatible string doesn't really affect the
>>>> functionality (as long as it matches).
>>>>
>>>> But even if it works with the current driver, I don't think
>>>> "ti,am33xx-tilcdc" and "ti,da850-tilcdc" are compatible in the HW level.
>>>
>>> If the hardware provides IP revision information, how about just "ti,lcdc" ?
>>
>> Maybe, and I agree that's the "correct" way, but looking at the history,
>> it's not just once or twice when we've suddenly found out some
>> difference or bug or such in an IP revision, or the integration to a
>> SoC, that can't be found based on the IP revision.
>>
>> That's why I feel it's usually safer to have the SoC revision there in
>> the compatible string.
I agree with Tomi here. Lets keep the soc part number in the compatible
string. More often than not, some undocumented, undiscovered issue pops
up over time. Its much safer to have the SoC revision in there.
>>
>> That said, we have only a few different old SoCs with LCDC (compared to,
>> say, OMAP DSS) so in this case perhaps just "ti,lcdc" would be fine.
>>
>> Tomi
>>
>
> I Sekhar is ok with this, I'll send a follow-up patch for that.
Per me, compatible property is an ordered list precisely for the reason
that things should continue to "work" with as closely matched driver as
possible. So even if someone is running a kernel which does not
recognize "ti,da850-tilcdc", it should still be able to probe the driver
based on "ti,am33xx-tilcdc" and provide as close to full functionality
as possible.
That said, I will not insist on keeping it around if Tomi is
uncomfortable. And having read the binding documentation accepted by
Jyri, it actually says the compatible property should be __one of__
"ti,am33xx-tilcdc" or "ti,da850-tilcdc".
Thanks,
Sekhar
^ permalink raw reply
* [RESEND PATCH v2 1/3] reset: oxnas: Add OX820 support
From: Philipp Zabel @ 2016-10-20 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005152710.2898-2-narmstrong@baylibre.com>
Am Mittwoch, den 05.10.2016, 17:27 +0200 schrieb Neil Armstrong:
> In order to support the Oxford Semiconductor OX820 SoC, add a new
> compatible string.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/reset/reset-oxnas.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/reset/reset-oxnas.c b/drivers/reset/reset-oxnas.c
> index 9449805..0d9036d 100644
> --- a/drivers/reset/reset-oxnas.c
> +++ b/drivers/reset/reset-oxnas.c
> @@ -80,6 +80,7 @@ static const struct reset_control_ops oxnas_reset_ops = {
>
> static const struct of_device_id oxnas_reset_dt_ids[] = {
> { .compatible = "oxsemi,ox810se-reset", },
> + { .compatible = "oxsemi,ox820-reset", },
> { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, oxnas_reset_dt_ids);
Applied all three, thanks.
regards
Philipp
^ 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