* [PATCH] arm64: export memblock_reserve()d regions via /proc/iomem
From: James Morse @ 2018-05-15 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507024024.GA11326@linaro.org>
Hi Akashi,
On 07/05/18 03:40, Akashi Takahiro wrote:
> On Wed, May 02, 2018 at 11:35:04AM +0100, James Morse wrote:
>> On 25/04/18 14:22, James Morse wrote:
>>> There has been some confusion around what is necessary to prevent kexec
>>> overwriting important memory regions. memblock: reserve, or nomap?
>>> Only memblock nomap regions are reported via /proc/iomem, kexec's
>>> user-space doesn't know about memblock_reserve()d regions.
>>> But this was always broken, as the UEFI memory map is also reserved
>>> and not marked as nomap.
>>> Lastly, we add the memblock_reserved() regions using
>>> reserve_region_with_split(), which will fill in the gaps between the
>>> existing named regions. (e.g. the regions occupied by the __init code).
>>> This call uses the slab allocator, so has to run from an initcall.
>> Re-reading Akashi's description of how kdump generates the ELF headers for
>> /proc/vmcore, this change might break kdump, as now the memblock_reserved()
>> regions may be missing from /proc/vmcore. (I'll test that).
> I also tested your patch, and there seems to be something wrong.
(excellent, I've been trying to remember how to build crash!)
> Actually, crash utility fails to read the core:
> crash-arm64: read error: kernel virtual address: ffff0000091fa998 \
> type: "shadow_timekeeper xtime_sec"
> crash-arm64: read error: kernel virtual address: ffff0000091fda48 \
> type: "high_memory"
> Adding some debug messages shows that "shadow_timekeeper" variable
> belongs to the range (A), which is originally part of "Kernel data"
> and should have been unmarked from "reserved" list.
Heh, so it caught fire even earlier. I was expecting only the per-cpu regions to
go missing.
Yes, the problems are going to be spurious-reserved and regions that aren't
reserved anymore, but were when the /proc/iomem list was generated.
>> Unless there is a 'name' for a region that kexec-tools interprets as "don't
>> overwrite this, but do include it in the ELF header", then we're stuck. We can't
>> fix kexec without breaking kdump, we have to change user-space.
>>
>> Of the two, missing data from kdump vmcore would be preferable to failed-to-boot
>> kexec.
>
> Well, kexec has had this potential bug since the day One in mainline.
> (we were then using "boot wrapper" instead of normal boot loaders though.)
> Even if we accept your assertion above now, future new-comers may
> "rediscover" a kdump bug and make a complaint time to time.
> So I think that we would be better off fixing the issue right now
> completely with accompanying user-space change.
I agree we need to fix this 'now'. But changing user-space means people still
hit this bug, and are told 'update both user-space and your kernel'.
This is because kexec-tools is using the /proc/iomem list for two things:
1 don't write here, you need it to boot.
2 preserve this memory, you need it in the vmcore.
I think kdump is less common and more best-effort, my preference would be:
>> If we have to change user-space, I'd like to make use of the kernels
>> ability to generate the ELF header itself, (e.g. kexec_file_load()).
For kexec-tools to load the vmcore data it currently generates itself from
/sys/kernel/kdump_elf_header or similar.
This splits the 1&2 cases above, meaning the kernel can export information for
(1) via /proc/iomem and (2) via the new file.
old kexec-tools still works for kexec, but hits the problem you found for kdump.
new kexec-tools aware of (2) works in both cases.
But merging this patch to fix old kexec-tools will prevent us doing anything
'neater', and any fix for old-kexec is going to break kdump with the same
user-space.
For your proposed kexec-tool and kernel changes, how will old kexec-tools work?
Is it going to be any worse than today?
Thanks,
James
^ permalink raw reply
* [PATCH v9 07/11] arm64: kexec_file: add crash dump support
From: James Morse @ 2018-05-15 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180425062629.29404-8-takahiro.akashi@linaro.org>
Hi Akashi,
On 25/04/18 07:26, AKASHI Takahiro wrote:
> Enabling crash dump (kdump) includes
> * prepare contents of ELF header of a core dump file, /proc/vmcore,
> using crash_prepare_elf64_headers(), and
> * add two device tree properties, "linux,usable-memory-range" and
> "linux,elfcorehdr", which represent repsectively a memory range
(Nit: respectively)
> to be used by crash dump kernel and the header's location
> arch/arm64/include/asm/kexec.h | 4 +
> arch/arm64/kernel/kexec_image.c | 9 +-
> arch/arm64/kernel/machine_kexec_file.c | 202 +++++++++++++++++++++++++
In this patch, machine_kexec_file.c gains its own private fdt array encoder.
> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> index 37c0a9dc2e47..ec674f4d267c 100644
> --- a/arch/arm64/kernel/machine_kexec_file.c
> +++ b/arch/arm64/kernel/machine_kexec_file.c
> @@ -76,6 +81,78 @@ int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> return ret;
> }
>
> +static int __init arch_kexec_file_init(void)
> +{
> + /* Those values are used later on loading the kernel */
> + __dt_root_addr_cells = dt_root_addr_cells;
> + __dt_root_size_cells = dt_root_size_cells;
> +
> + return 0;
> +}
> +late_initcall(arch_kexec_file_init);
If we need these is it worth taking them out of __initdata? I note they've been
'temporary' for quite a long time.
> +
> +#define FDT_ALIGN(x, a) (((x) + (a) - 1) & ~((a) - 1))
> +#define FDT_TAGALIGN(x) (FDT_ALIGN((x), FDT_TAGSIZE))
> +
> +static int fdt_prop_len(const char *prop_name, int len)
> +{
> + return (strlen(prop_name) + 1) +
> + sizeof(struct fdt_property) +
> + FDT_TAGALIGN(len);
> +}
This stuff should really be in libfdt.h Those macros come from
libfdt_internal.h, so we're probably doing something wrong here.
> +static bool cells_size_fitted(unsigned long base, unsigned long size)
> +{
> + /* if *_cells >= 2, cells can hold 64-bit values anyway */
> + if ((__dt_root_addr_cells == 1) && (base >= (1ULL << 32)))
> + return false;
> +
> + if ((__dt_root_size_cells == 1) && (size >= (1ULL << 32)))
> + return false;
Using '> U32_MAX' here may be more readable.
> + return true;
> +}
> +
> +static void fill_property(void *buf, u64 val64, int cells)
> +{
> + u32 val32;
> +
> + if (cells == 1) {
> + val32 = cpu_to_fdt32((u32)val64);
> + memcpy(buf, &val32, sizeof(val32));
> + } else {
> + memset(buf, 0, cells * sizeof(u32) - sizeof(u64));
> + buf += cells * sizeof(u32) - sizeof(u64);
Is this trying to clear the 'top' cells and shuffle the pointer to point at the
'bottom' 2? I'm pretty sure this isn't endian safe.
Do we really expect a system to have #address-cells > 2?
> + val64 = cpu_to_fdt64(val64);
> + memcpy(buf, &val64, sizeof(val64));
> + }
> +}
> +
> +static int fdt_setprop_range(void *fdt, int nodeoffset, const char *name,
> + unsigned long addr, unsigned long size)
(the device-tree spec describes a 'ranges' property, which had me confused. This
is encoding a prop-encoded-array)
> +{
> + void *buf, *prop;
> + size_t buf_size;
> + int result;
> +
> + buf_size = (__dt_root_addr_cells + __dt_root_size_cells) * sizeof(u32);
> + prop = buf = vmalloc(buf_size);
virtual memory allocation for something less than PAGE_SIZE?
> + if (!buf)
> + return -ENOMEM;
> +
> + fill_property(prop, addr, __dt_root_addr_cells);
> + prop += __dt_root_addr_cells * sizeof(u32);
> +
> + fill_property(prop, size, __dt_root_size_cells);
> +
> + result = fdt_setprop(fdt, nodeoffset, name, buf, buf_size);
> +
> + vfree(buf);
> +
> + return result;
> +}
Doesn't this stuff belong in libfdt? I guess there is no 'add array element' api
because this the first time we've wanted to create a node with more than
key=fixed-size-value.
I don't think this belongs in arch C code. Do we have a plan for getting libfdt
to support encoding prop-arrays? Can we put it somewhere anyone else duplicating
this will find it, until we can (re)move it?
I have no idea how that happens... it looks like the devicetree list is the
place to ask.
> static int setup_dtb(struct kimage *image,
> unsigned long initrd_load_addr, unsigned long initrd_len,
> char *cmdline, unsigned long cmdline_len,
> @@ -88,10 +165,26 @@ static int setup_dtb(struct kimage *image,
> int range_len;
> int ret;
>
> + /* check ranges against root's #address-cells and #size-cells */
> + if (image->type == KEXEC_TYPE_CRASH &&
> + (!cells_size_fitted(image->arch.elf_load_addr,
> + image->arch.elf_headers_sz) ||
> + !cells_size_fitted(crashk_res.start,
> + crashk_res.end - crashk_res.start + 1))) {
> + pr_err("Crash memory region doesn't fit into DT's root cell sizes.\n");
> + ret = -EINVAL;
> + goto out_err;
> + }
To check I've understood this properly: This can happen if the firmware provided
a DTB with 32bit address/size cells, but at least some of the memory requires 64
bit address/size cells. This could only happen on a UEFI system where the
firmware-DTB doesn't describe memory. ACPI-only systems would have the EFIstub DT.
> /* duplicate dt blob */
> buf_size = fdt_totalsize(initial_boot_params);
> range_len = (__dt_root_addr_cells + __dt_root_size_cells) * sizeof(u32);
>
> + if (image->type == KEXEC_TYPE_CRASH)
> + buf_size += fdt_prop_len("linux,elfcorehdr", range_len)
> + + fdt_prop_len("linux,usable-memory-range",
> + range_len);
> +
> if (initrd_load_addr)
> buf_size += fdt_prop_len("linux,initrd-start", sizeof(u64))
> + fdt_prop_len("linux,initrd-end", sizeof(u64));
> @@ -113,6 +206,23 @@ static int setup_dtb(struct kimage *image,
> if (nodeoffset < 0)
> goto out_err;
>
> + if (image->type == KEXEC_TYPE_CRASH) {
> + /* add linux,elfcorehdr */
> + ret = fdt_setprop_range(buf, nodeoffset, "linux,elfcorehdr",
> + image->arch.elf_load_addr,
> + image->arch.elf_headers_sz);
> + if (ret)
> + goto out_err;
> +
> + /* add linux,usable-memory-range */
> + ret = fdt_setprop_range(buf, nodeoffset,
> + "linux,usable-memory-range",
> + crashk_res.start,
> + crashk_res.end - crashk_res.start + 1);
Don't you need to add "linux,usable-memory-range" to the buf_size estimate?
> + if (ret)
> + goto out_err;
> + }
> @@ -148,17 +258,109 @@ static int setup_dtb(struct kimage *image,
> +static struct crash_mem *get_crash_memory_ranges(void)
> +{
> + unsigned int nr_ranges;
> + struct crash_mem *cmem;
> +
> + nr_ranges = 1; /* for exclusion of crashkernel region */
> + walk_system_ram_res(0, -1, &nr_ranges, get_nr_ranges_callback);
> +
> + cmem = vmalloc(sizeof(struct crash_mem) +
> + sizeof(struct crash_mem_range) * nr_ranges);
> + if (!cmem)
> + return NULL;
> +
> + cmem->max_nr_ranges = nr_ranges;
> + cmem->nr_ranges = 0;
> + walk_system_ram_res(0, -1, cmem, add_mem_range_callback);
> +
> + /* Exclude crashkernel region */
> + if (crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end)) {
> + vfree(cmem);
> + return NULL;
> + }
> +
> + return cmem;
> +}
Could this function be included in prepare_elf_headers() so that the alloc() and
free() occur together.
> +static int prepare_elf_headers(void **addr, unsigned long *sz)
> +{
> + struct crash_mem *cmem;
> + int ret = 0;
> +
> + cmem = get_crash_memory_ranges();
> + if (!cmem)
> + return -ENOMEM;
> +
> + ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
> +
> + vfree(cmem);
> + return ret;
> +}
All this is moving memory-range information from core-code's
walk_system_ram_res() into core-code's struct crash_mem, and excluding
crashk_res, which again is accessible to the core code.
It looks like this is duplicated in arch/x86 and arch/arm64 because arm64
doesn't have a second 'crashk_low_res' region, and always wants elf64, instead
of when IS_ENABLED(CONFIG_X86_64).
If we can abstract just those two, more of this could be moved to core code
where powerpc can make use of it if they want to support kdump with
kexec_file_load().
But, its getting late for cross-architecture dependencies, lets put that on the
for-later list. (assuming there isn't a powerpc-kdump series out there adding a
third copy of this)
Thanks,
James
^ permalink raw reply
* [PATCH v2 4/4] KVM: arm64: Add support for PUD hugepages at stage 2
From: Punit Agrawal @ 2018-05-15 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515165620.37l2epyno3vdcisu@armageddon.cambridge.arm.com>
Catalin Marinas <catalin.marinas@arm.com> writes:
> On Tue, May 01, 2018 at 11:26:59AM +0100, Punit Agrawal wrote:
>> KVM currently supports PMD hugepages at stage 2. Extend the stage 2
>> fault handling to add support for PUD hugepages.
>>
>> Addition of pud hugepage support enables additional hugepage
>> sizes (e.g., 1G with 4K granule) which can be useful on cores that
>> support mapping larger block sizes in the TLB entries.
>>
>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>> Cc: Christoffer Dall <christoffer.dall@arm.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Russell King <linux@armlinux.org.uk>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> ---
>> arch/arm/include/asm/kvm_mmu.h | 19 ++++++++++++
>> arch/arm64/include/asm/kvm_mmu.h | 15 ++++++++++
>> arch/arm64/include/asm/pgtable-hwdef.h | 4 +++
>> arch/arm64/include/asm/pgtable.h | 2 ++
>> virt/kvm/arm/mmu.c | 40 ++++++++++++++++++++++++--
>> 5 files changed, 77 insertions(+), 3 deletions(-)
>
> Since this patch touches a couple of core arm64 files:
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Thanks Catalin.
I've posted a v3 with minor changes yesterday[0]. Can you comment there?
Or maybe Marc can apply the tag while merging the patches.
[0] https://lkml.org/lkml/2018/5/14/912
^ permalink raw reply
* [PATCH v9 07/11] arm64: kexec_file: add crash dump support
From: James Morse @ 2018-05-15 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180425062629.29404-8-takahiro.akashi@linaro.org>
Hi guys,
(CC: +RobH, devicetree list)
On 25/04/18 07:26, AKASHI Takahiro wrote:
> Enabling crash dump (kdump) includes
> * prepare contents of ELF header of a core dump file, /proc/vmcore,
> using crash_prepare_elf64_headers(), and
> * add two device tree properties, "linux,usable-memory-range" and
> "linux,elfcorehdr", which represent repsectively a memory range
> to be used by crash dump kernel and the header's location
kexec_file_load() on arm64 needs to be able to create a prop encoded array to
the FDT, but there doesn't appear to be a libfdt helper to do this.
Akashi's code below adds fdt_setprop_range() to the arch code, and duplicates
bits of libfdt_internal.h to do the work.
How should this be done? I'm assuming this is something we need a new API in
libfdt.h for. How do these come about, and is there an interim step we can use
until then?
Thanks!
James
> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> index 37c0a9dc2e47..ec674f4d267c 100644
> --- a/arch/arm64/kernel/machine_kexec_file.c
> +++ b/arch/arm64/kernel/machine_kexec_file.c
> @@ -76,6 +81,78 @@ int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> return ret;
> }
>
> +static int __init arch_kexec_file_init(void)
> +{
> + /* Those values are used later on loading the kernel */
> + __dt_root_addr_cells = dt_root_addr_cells;
> + __dt_root_size_cells = dt_root_size_cells;
> +
> + return 0;
> +}
> +late_initcall(arch_kexec_file_init);
> +
> +#define FDT_ALIGN(x, a) (((x) + (a) - 1) & ~((a) - 1))
> +#define FDT_TAGALIGN(x) (FDT_ALIGN((x), FDT_TAGSIZE))
> +
> +static int fdt_prop_len(const char *prop_name, int len)
> +{
> + return (strlen(prop_name) + 1) +
> + sizeof(struct fdt_property) +
> + FDT_TAGALIGN(len);
> +}
> +
> +static bool cells_size_fitted(unsigned long base, unsigned long size)
> +{
> + /* if *_cells >= 2, cells can hold 64-bit values anyway */
> + if ((__dt_root_addr_cells == 1) && (base >= (1ULL << 32)))
> + return false;
> +
> + if ((__dt_root_size_cells == 1) && (size >= (1ULL << 32)))
> + return false;
> +
> + return true;
> +}
> +
> +static void fill_property(void *buf, u64 val64, int cells)
> +{
> + u32 val32;
> +
> + if (cells == 1) {
> + val32 = cpu_to_fdt32((u32)val64);
> + memcpy(buf, &val32, sizeof(val32));
> + } else {
> + memset(buf, 0, cells * sizeof(u32) - sizeof(u64));
> + buf += cells * sizeof(u32) - sizeof(u64);
> +
> + val64 = cpu_to_fdt64(val64);
> + memcpy(buf, &val64, sizeof(val64));
> + }
> +}
> +
> +static int fdt_setprop_range(void *fdt, int nodeoffset, const char *name,
> + unsigned long addr, unsigned long size)
> +{
> + void *buf, *prop;
> + size_t buf_size;
> + int result;
> +
> + buf_size = (__dt_root_addr_cells + __dt_root_size_cells) * sizeof(u32);
> + prop = buf = vmalloc(buf_size);
> + if (!buf)
> + return -ENOMEM;
> +
> + fill_property(prop, addr, __dt_root_addr_cells);
> + prop += __dt_root_addr_cells * sizeof(u32);
> +
> + fill_property(prop, size, __dt_root_size_cells);
> +
> + result = fdt_setprop(fdt, nodeoffset, name, buf, buf_size);
> +
> + vfree(buf);
> +
> + return result;
> +}
> +
> static int setup_dtb(struct kimage *image,
> unsigned long initrd_load_addr, unsigned long initrd_len,
> char *cmdline, unsigned long cmdline_len,
> @@ -88,10 +165,26 @@ static int setup_dtb(struct kimage *image,
> int range_len;
> int ret;
>
> + /* check ranges against root's #address-cells and #size-cells */
> + if (image->type == KEXEC_TYPE_CRASH &&
> + (!cells_size_fitted(image->arch.elf_load_addr,
> + image->arch.elf_headers_sz) ||
> + !cells_size_fitted(crashk_res.start,
> + crashk_res.end - crashk_res.start + 1))) {
> + pr_err("Crash memory region doesn't fit into DT's root cell sizes.\n");
> + ret = -EINVAL;
> + goto out_err;
> + }
> +
> /* duplicate dt blob */
> buf_size = fdt_totalsize(initial_boot_params);
> range_len = (__dt_root_addr_cells + __dt_root_size_cells) * sizeof(u32);
>
> + if (image->type == KEXEC_TYPE_CRASH)
> + buf_size += fdt_prop_len("linux,elfcorehdr", range_len)
> + + fdt_prop_len("linux,usable-memory-range",
> + range_len);
> +
> if (initrd_load_addr)
> buf_size += fdt_prop_len("linux,initrd-start", sizeof(u64))
> + fdt_prop_len("linux,initrd-end", sizeof(u64));
> @@ -113,6 +206,23 @@ static int setup_dtb(struct kimage *image,
> if (nodeoffset < 0)
> goto out_err;
>
> + if (image->type == KEXEC_TYPE_CRASH) {
> + /* add linux,elfcorehdr */
> + ret = fdt_setprop_range(buf, nodeoffset, "linux,elfcorehdr",
> + image->arch.elf_load_addr,
> + image->arch.elf_headers_sz);
> + if (ret)
> + goto out_err;
> +
> + /* add linux,usable-memory-range */
> + ret = fdt_setprop_range(buf, nodeoffset,
> + "linux,usable-memory-range",
> + crashk_res.start,
> + crashk_res.end - crashk_res.start + 1);
> + if (ret)
> + goto out_err;
> + }
> +
> /* add bootargs */
> if (cmdline) {
> ret = fdt_setprop(buf, nodeoffset, "bootargs",
^ permalink raw reply
* [PATCH 0/3] coresight: Don't use contextID with PID namespaces
From: Mathieu Poirier @ 2018-05-15 17:13 UTC (permalink / raw)
To: linux-arm-kernel
Since the in-kernel value of a PID differs from what is seen from
PID namespaces, using contextID tracing with PID namespaces makes the
feature confusing to use and potentially subject to leaking out internal
kernel information.
This set returns an error if contextID and PID namespaces are used in
conjunction and gets rid of the vpid-to-pid translation function as it
is no longer needed.
Thanks,
Mathieu
Mathieu Poirier (3):
coresight: etm3x: Don't use contextID with PID namespaces
coresight: etm4x: Don't use contextID with PID namespaces
coresight: Remove function coresight_vpid_to_pid()
drivers/hwtracing/coresight/coresight-etm.h | 3 --
.../hwtracing/coresight/coresight-etm3x-sysfs.c | 43 +++++++++++++++++---
drivers/hwtracing/coresight/coresight-etm3x.c | 4 +-
.../hwtracing/coresight/coresight-etm4x-sysfs.c | 47 +++++++++++++++++-----
drivers/hwtracing/coresight/coresight-etm4x.h | 3 --
include/linux/coresight.h | 20 ---------
6 files changed, 76 insertions(+), 44 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] coresight: etm3x: Don't use contextID with PID namespaces
From: Mathieu Poirier @ 2018-05-15 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526404417-32507-1-git-send-email-mathieu.poirier@linaro.org>
Tracers can trigger trace acquisition based on contextID value, something
that isn't useful when PID namespaces are enabled. Indeed the PID value
of a process has a different representation in the kernel and the PID
namespace, making the feature confusing and potentially leaking internal
kernel information.
As such simply return an error when the feature is being used from a
PID namespace other than the default one.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
drivers/hwtracing/coresight/coresight-etm.h | 3 --
.../hwtracing/coresight/coresight-etm3x-sysfs.c | 43 +++++++++++++++++++---
drivers/hwtracing/coresight/coresight-etm3x.c | 4 +-
3 files changed, 38 insertions(+), 12 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
index e8b4549e30e2..79e1ad860d8a 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -168,8 +168,6 @@
* @seq_curr_state: current value of the sequencer register.
* @ctxid_idx: index for the context ID registers.
* @ctxid_pid: value for the context ID to trigger on.
- * @ctxid_vpid: Virtual PID seen by users if PID namespace is enabled, otherwise
- * the same value of ctxid_pid.
* @ctxid_mask: mask applicable to all the context IDs.
* @sync_freq: Synchronisation frequency.
* @timestamp_event: Defines an event that requests the insertion
@@ -202,7 +200,6 @@ struct etm_config {
u32 seq_curr_state;
u8 ctxid_idx;
u32 ctxid_pid[ETM_MAX_CTXID_CMP];
- u32 ctxid_vpid[ETM_MAX_CTXID_CMP];
u32 ctxid_mask;
u32 sync_freq;
u32 timestamp_event;
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
index 9435c1481f61..75487b3fad86 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
@@ -4,6 +4,7 @@
* Author: Mathieu Poirier <mathieu.poirier@linaro.org>
*/
+#include <linux/pid_namespace.h>
#include <linux/pm_runtime.h>
#include <linux/sysfs.h>
#include "coresight-etm.h"
@@ -1025,8 +1026,15 @@ static ssize_t ctxid_pid_show(struct device *dev,
struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
struct etm_config *config = &drvdata->config;
+ /*
+ * Don't use contextID tracing if coming from a PID namespace. See
+ * comment in ctxid_pid_store().
+ */
+ if (task_active_pid_ns(current) != &init_pid_ns)
+ return -EINVAL;
+
spin_lock(&drvdata->spinlock);
- val = config->ctxid_vpid[config->ctxid_idx];
+ val = config->ctxid_pid[config->ctxid_idx];
spin_unlock(&drvdata->spinlock);
return sprintf(buf, "%#lx\n", val);
@@ -1037,19 +1045,28 @@ static ssize_t ctxid_pid_store(struct device *dev,
const char *buf, size_t size)
{
int ret;
- unsigned long vpid, pid;
+ unsigned long pid;
struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
struct etm_config *config = &drvdata->config;
- ret = kstrtoul(buf, 16, &vpid);
+ /*
+ * When contextID tracing is enabled the tracers will insert the
+ * value found in the contextID register in the trace stream. But if
+ * a process is in a namespace the PID of that process as seen from the
+ * namespace won't be what the kernel sees, something that makes the
+ * feature confusing and can potentially leak kernel only information.
+ * As such refuse to use the feature if @current is not in the initial
+ * PID namespace.
+ */
+ if (task_active_pid_ns(current) != &init_pid_ns)
+ return -EINVAL;
+
+ ret = kstrtoul(buf, 16, &pid);
if (ret)
return ret;
- pid = coresight_vpid_to_pid(vpid);
-
spin_lock(&drvdata->spinlock);
config->ctxid_pid[config->ctxid_idx] = pid;
- config->ctxid_vpid[config->ctxid_idx] = vpid;
spin_unlock(&drvdata->spinlock);
return size;
@@ -1063,6 +1080,13 @@ static ssize_t ctxid_mask_show(struct device *dev,
struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
struct etm_config *config = &drvdata->config;
+ /*
+ * Don't use contextID tracing if coming from a PID namespace. See
+ * comment in ctxid_pid_store().
+ */
+ if (task_active_pid_ns(current) != &init_pid_ns)
+ return -EINVAL;
+
val = config->ctxid_mask;
return sprintf(buf, "%#lx\n", val);
}
@@ -1076,6 +1100,13 @@ static ssize_t ctxid_mask_store(struct device *dev,
struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
struct etm_config *config = &drvdata->config;
+ /*
+ * Don't use contextID tracing if coming from a PID namespace. See
+ * comment in ctxid_pid_store().
+ */
+ if (task_active_pid_ns(current) != &init_pid_ns)
+ return -EINVAL;
+
ret = kstrtoul(buf, 16, &val);
if (ret)
return ret;
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 15ed64d51a5b..7c74263c333d 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -230,10 +230,8 @@ void etm_set_default(struct etm_config *config)
config->seq_curr_state = 0x0;
config->ctxid_idx = 0x0;
- for (i = 0; i < ETM_MAX_CTXID_CMP; i++) {
+ for (i = 0; i < ETM_MAX_CTXID_CMP; i++)
config->ctxid_pid[i] = 0x0;
- config->ctxid_vpid[i] = 0x0;
- }
config->ctxid_mask = 0x0;
/* Setting default to 1024 as per TRM recommendation */
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] coresight: etm4x: Don't use contextID with PID namespaces
From: Mathieu Poirier @ 2018-05-15 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526404417-32507-1-git-send-email-mathieu.poirier@linaro.org>
As with ETM3x, the ETM4x tracers can trigger trace acquisition based on
contextID value, something that isn't useful when PID namespaces are
enabled. Indeed the PID value of a process has a different representation
in the kernel and the PID namespace, making the feature confusing and
potentially leaking internal kernel information.
As such simply return an error when the feature is being used from a
PID namespace other than the default one.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
.../hwtracing/coresight/coresight-etm4x-sysfs.c | 47 +++++++++++++++++-----
drivers/hwtracing/coresight/coresight-etm4x.h | 3 --
2 files changed, 38 insertions(+), 12 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
index 4eb8da785ce0..a0365e23678e 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
@@ -4,6 +4,7 @@
* Author: Mathieu Poirier <mathieu.poirier@linaro.org>
*/
+#include <linux/pid_namespace.h>
#include <linux/pm_runtime.h>
#include <linux/sysfs.h>
#include "coresight-etm4x.h"
@@ -250,10 +251,8 @@ static ssize_t reset_store(struct device *dev,
}
config->ctxid_idx = 0x0;
- for (i = 0; i < drvdata->numcidc; i++) {
+ for (i = 0; i < drvdata->numcidc; i++)
config->ctxid_pid[i] = 0x0;
- config->ctxid_vpid[i] = 0x0;
- }
config->ctxid_mask0 = 0x0;
config->ctxid_mask1 = 0x0;
@@ -1637,9 +1636,16 @@ static ssize_t ctxid_pid_show(struct device *dev,
struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
struct etmv4_config *config = &drvdata->config;
+ /*
+ * Don't use contextID tracing if coming from a PID namespace. See
+ * comment in ctxid_pid_store().
+ */
+ if (task_active_pid_ns(current) != &init_pid_ns)
+ return -EINVAL;
+
spin_lock(&drvdata->spinlock);
idx = config->ctxid_idx;
- val = (unsigned long)config->ctxid_vpid[idx];
+ val = (unsigned long)config->ctxid_pid[idx];
spin_unlock(&drvdata->spinlock);
return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
}
@@ -1649,26 +1655,35 @@ static ssize_t ctxid_pid_store(struct device *dev,
const char *buf, size_t size)
{
u8 idx;
- unsigned long vpid, pid;
+ unsigned long pid;
struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
struct etmv4_config *config = &drvdata->config;
/*
+ * When contextID tracing is enabled the tracers will insert the
+ * value found in the contextID register in the trace stream. But if
+ * a process is in a namespace the PID of that process as seen from the
+ * namespace won't be what the kernel sees, something that makes the
+ * feature confusing and can potentially leak kernel only information.
+ * As such refuse to use the feature if @current is not in the initial
+ * PID namespace.
+ */
+ if (task_active_pid_ns(current) != &init_pid_ns)
+ return -EINVAL;
+
+ /*
* only implemented when ctxid tracing is enabled, i.e. at least one
* ctxid comparator is implemented and ctxid is greater than 0 bits
* in length
*/
if (!drvdata->ctxid_size || !drvdata->numcidc)
return -EINVAL;
- if (kstrtoul(buf, 16, &vpid))
+ if (kstrtoul(buf, 16, &pid))
return -EINVAL;
- pid = coresight_vpid_to_pid(vpid);
-
spin_lock(&drvdata->spinlock);
idx = config->ctxid_idx;
config->ctxid_pid[idx] = (u64)pid;
- config->ctxid_vpid[idx] = (u64)vpid;
spin_unlock(&drvdata->spinlock);
return size;
}
@@ -1682,6 +1697,13 @@ static ssize_t ctxid_masks_show(struct device *dev,
struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
struct etmv4_config *config = &drvdata->config;
+ /*
+ * Don't use contextID tracing if coming from a PID namespace. See
+ * comment in ctxid_pid_store().
+ */
+ if (task_active_pid_ns(current) != &init_pid_ns)
+ return -EINVAL;
+
spin_lock(&drvdata->spinlock);
val1 = config->ctxid_mask0;
val2 = config->ctxid_mask1;
@@ -1699,6 +1721,13 @@ static ssize_t ctxid_masks_store(struct device *dev,
struct etmv4_config *config = &drvdata->config;
/*
+ * Don't use contextID tracing if coming from a PID namespace. See
+ * comment in ctxid_pid_store().
+ */
+ if (task_active_pid_ns(current) != &init_pid_ns)
+ return -EINVAL;
+
+ /*
* only implemented when ctxid tracing is enabled, i.e. at least one
* ctxid comparator is implemented and ctxid is greater than 0 bits
* in length
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index b7c4a6f6c6b9..52786e9d8926 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -230,8 +230,6 @@
* @addr_type: Current status of the comparator register.
* @ctxid_idx: Context ID index selector.
* @ctxid_pid: Value of the context ID comparator.
- * @ctxid_vpid: Virtual PID seen by users if PID namespace is enabled, otherwise
- * the same value of ctxid_pid.
* @ctxid_mask0:Context ID comparator mask for comparator 0-3.
* @ctxid_mask1:Context ID comparator mask for comparator 4-7.
* @vmid_idx: VM ID index selector.
@@ -274,7 +272,6 @@ struct etmv4_config {
u8 addr_type[ETM_MAX_SINGLE_ADDR_CMP];
u8 ctxid_idx;
u64 ctxid_pid[ETMv4_MAX_CTXID_CMP];
- u64 ctxid_vpid[ETMv4_MAX_CTXID_CMP];
u32 ctxid_mask0;
u32 ctxid_mask1;
u8 vmid_idx;
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] coresight: Remove function coresight_vpid_to_pid()
From: Mathieu Poirier @ 2018-05-15 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526404417-32507-1-git-send-email-mathieu.poirier@linaro.org>
Now that we prevent users from using contextID tracing when PID namespaces
are involved there is no client for function coresight_vpid_to_pid(). As
such simply remove it.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
include/linux/coresight.h | 20 --------------------
1 file changed, 20 deletions(-)
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index c265e0468414..e5421b83e4e6 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -267,24 +267,4 @@ static inline struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, const struct device_node *node) { return NULL; }
#endif
-#ifdef CONFIG_PID_NS
-static inline unsigned long
-coresight_vpid_to_pid(unsigned long vpid)
-{
- struct task_struct *task = NULL;
- unsigned long pid = 0;
-
- rcu_read_lock();
- task = find_task_by_vpid(vpid);
- if (task)
- pid = task_pid_nr(task);
- rcu_read_unlock();
-
- return pid;
-}
-#else
-static inline unsigned long
-coresight_vpid_to_pid(unsigned long vpid) { return vpid; }
-#endif
-
#endif
--
2.7.4
^ permalink raw reply related
* [PATCH v9 06/11] arm64: kexec_file: allow for loading Image-format kernel
From: James Morse @ 2018-05-15 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515051308.GD2737@linaro.org>
Hi Akashi,
On 15/05/18 06:13, AKASHI Takahiro wrote:
> On Fri, May 11, 2018 at 06:07:06PM +0100, James Morse wrote:
>> On 07/05/18 08:21, AKASHI Takahiro wrote:
>>> On Tue, May 01, 2018 at 06:46:11PM +0100, James Morse wrote:
>>>> On 25/04/18 07:26, AKASHI Takahiro wrote:
>>>>> This patch provides kexec_file_ops for "Image"-format kernel. In this
>>>>> implementation, a binary is always loaded with a fixed offset identified
>>>>> in text_offset field of its header.
>>
>>>>> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
>>>>> index e4de1223715f..3cba4161818a 100644
>>>>> --- a/arch/arm64/include/asm/kexec.h
>>>>> +++ b/arch/arm64/include/asm/kexec.h
>>>> Could we check branch_code is non-zero, and text-offset points within image-size?
>>>
>>> We could do it, but I don't think this check is very useful.
>>>
>>>>
>>>> We could check that this platform supports the page-size/endian config that this
>>>> Image was built with... We get a message from the EFI stub if the page-size
>>>> can't be supported, it would be nice to do the same here (as we can).
>>>
>>> There is no restriction on page-size or endianness for kexec.
>>
>> No, but it won't boot if the hardware doesn't support it. The kernel will spin
>> at a magic address that is, difficult, to debug without JTAG. The bug report
>> will be "it didn't boot".
>
> OK.
> Added sanity checks for cpu features, endianness as well as page size.
>
>>
>>> What will be the purpose of this check?
>>
>> These values are in the header so that the bootloader can check them, then print
>> a meaningful error. Here, kexec_file_load() is playing the part of the bootloader.
>> I'm assuming kexec_file_load() can only be used to kexec linux... unlike regular
>> kexec. Is this where I'm going wrong?
Trying to work this out for myself: we can't support any UEFI application as we
can't give it the boot-services environment, so I'm pretty sure
kexec_file_load() must be linux-specific.
Can we state somewhere that we only expect arm64 linux to be booted with
kexec_file_load()? Its not clear from the kconfig text, which refers to kexec,
which explicitly states it can boot other OS. But for kexec_file_load() we're
following the kernel's booting.txt.
>>>>> diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
>>>>> new file mode 100644
>>>>> index 000000000000..4dd524ad6611
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/kernel/kexec_image.c
>>>>> @@ -0,0 +1,79 @@
>>>>
>>>>> +static void *image_load(struct kimage *image,
>>>>> + char *kernel, unsigned long kernel_len,
>>>>> + char *initrd, unsigned long initrd_len,
>>>>> + char *cmdline, unsigned long cmdline_len)
>>>>> +{
>>>>> + struct kexec_buf kbuf;
>>>>> + struct arm64_image_header *h = (struct arm64_image_header *)kernel;
>>>>> + unsigned long text_offset;
>>>>> + int ret;
>>>>> +
>>>>> + /* Load the kernel */
>>>>> + kbuf.image = image;
>>>>> + kbuf.buf_min = 0;
>>>>> + kbuf.buf_max = ULONG_MAX;
>>>>> + kbuf.top_down = false;
>>>>> +
>>>>> + kbuf.buffer = kernel;
>>>>> + kbuf.bufsz = kernel_len;
>>>>> + kbuf.memsz = le64_to_cpu(h->image_size);
>>>>> + text_offset = le64_to_cpu(h->text_offset);
>>>>> + kbuf.buf_align = SZ_2M;
>>>>
>>>>> + /* Adjust kernel segment with TEXT_OFFSET */
>>>>> + kbuf.memsz += text_offset;
>>>>> +
>>>>> + ret = kexec_add_buffer(&kbuf);
>>>>> + if (ret)
>>>>> + goto out;
>>>>> +
>>>>> + image->arch.kern_segment = image->nr_segments - 1;
>>>>
>>>> You only seem to use kern_segment here, and in load_other_segments() called
>>>> below. Could it not be a local variable passed in? Instead of arch-specific data
>>>> we keep forever?
>>>
>>> No, kern_segment is also used in load_other_segments() in machine_kexec_file.c.
>>> To optimize memory hole allocation logic in locate_mem_hole_callback(),
>>> we need to know the exact range of kernel image (start and end).
>>
>> That's the second user. My badly-made point is one calls the other, but passes
>> the data via some until-kexec lifetime struct. (its not important, just an
>> indicator this worked differently in the past and hasn't been cleaned up).
>> I meant something like [0].
>
> OK, but instead of adding kern_seg, I want to change the interface to:
>
> | extern int load_other_segments(struct kimage *image,
> | unsigned long kernel_load_addr, unsigned long kernel_size,
> | char *initrd, unsigned long initrd_len,
> | char *cmdline, unsigned long cmdline_len);
>
> This way, we will in future be able to address an issue I mentioned in
> my previous e-mail. (If we support vmlinux, the kernel occupies two segments
> for text and data, respectively.)
Aha, its not from old-stuff, its for future-stuff!
James
^ permalink raw reply
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
From: Jeremy Linton @ 2018-05-15 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511235807.30834-3-jeremy.linton@arm.com>
Hi Greg,
Have you had a chance to look at the cachinfo parts of this patch?
Comments?
Thanks,
On 05/11/2018 06:57 PM, Jeremy Linton wrote:
> The original intent in cacheinfo was that an architecture
> specific populate_cache_leaves() would probe the hardware
> and then cache_shared_cpu_map_setup() and
> cache_override_properties() would provide firmware help to
> extend/expand upon what was probed. Arm64 was really
> the only architecture that was working this way, and
> with the removal of most of the hardware probing logic it
> became clear that it was possible to simplify the logic a bit.
>
> This patch combines the walk of the DT nodes with the
> code updating the cache size/line_size and nr_sets.
> cache_override_properties() (which was DT specific) is
> then removed. The result is that cacheinfo.of_node is
> no longer used as a temporary place to hold DT references
> for future calls that update cache properties. That change
> helps to clarify its one remaining use (matching
> cacheinfo nodes that represent shared caches) which
> will be used by the ACPI/PPTT code in the following patches.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/riscv/kernel/cacheinfo.c | 1 -
> drivers/base/cacheinfo.c | 65 +++++++++++++++++++------------------------
> 2 files changed, 29 insertions(+), 37 deletions(-)
>
> diff --git a/arch/riscv/kernel/cacheinfo.c b/arch/riscv/kernel/cacheinfo.c
> index 10ed2749e246..0bc86e5f8f3f 100644
> --- a/arch/riscv/kernel/cacheinfo.c
> +++ b/arch/riscv/kernel/cacheinfo.c
> @@ -20,7 +20,6 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
> struct device_node *node,
> enum cache_type type, unsigned int level)
> {
> - this_leaf->of_node = node;
> this_leaf->level = level;
> this_leaf->type = type;
> /* not a sector cache */
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> index 09ccef7ddc99..a872523e8951 100644
> --- a/drivers/base/cacheinfo.c
> +++ b/drivers/base/cacheinfo.c
> @@ -71,7 +71,7 @@ static inline int get_cacheinfo_idx(enum cache_type type)
> return type;
> }
>
> -static void cache_size(struct cacheinfo *this_leaf)
> +static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
> {
> const char *propname;
> const __be32 *cache_size;
> @@ -80,13 +80,14 @@ static void cache_size(struct cacheinfo *this_leaf)
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> propname = cache_type_info[ct_idx].size_prop;
>
> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
> + cache_size = of_get_property(np, propname, NULL);
> if (cache_size)
> this_leaf->size = of_read_number(cache_size, 1);
> }
>
> /* not cache_line_size() because that's a macro in include/linux/cache.h */
> -static void cache_get_line_size(struct cacheinfo *this_leaf)
> +static void cache_get_line_size(struct cacheinfo *this_leaf,
> + struct device_node *np)
> {
> const __be32 *line_size;
> int i, lim, ct_idx;
> @@ -98,7 +99,7 @@ static void cache_get_line_size(struct cacheinfo *this_leaf)
> const char *propname;
>
> propname = cache_type_info[ct_idx].line_size_props[i];
> - line_size = of_get_property(this_leaf->of_node, propname, NULL);
> + line_size = of_get_property(np, propname, NULL);
> if (line_size)
> break;
> }
> @@ -107,7 +108,7 @@ static void cache_get_line_size(struct cacheinfo *this_leaf)
> this_leaf->coherency_line_size = of_read_number(line_size, 1);
> }
>
> -static void cache_nr_sets(struct cacheinfo *this_leaf)
> +static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
> {
> const char *propname;
> const __be32 *nr_sets;
> @@ -116,7 +117,7 @@ static void cache_nr_sets(struct cacheinfo *this_leaf)
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> propname = cache_type_info[ct_idx].nr_sets_prop;
>
> - nr_sets = of_get_property(this_leaf->of_node, propname, NULL);
> + nr_sets = of_get_property(np, propname, NULL);
> if (nr_sets)
> this_leaf->number_of_sets = of_read_number(nr_sets, 1);
> }
> @@ -135,32 +136,27 @@ static void cache_associativity(struct cacheinfo *this_leaf)
> this_leaf->ways_of_associativity = (size / nr_sets) / line_size;
> }
>
> -static bool cache_node_is_unified(struct cacheinfo *this_leaf)
> +static bool cache_node_is_unified(struct cacheinfo *this_leaf,
> + struct device_node *np)
> {
> - return of_property_read_bool(this_leaf->of_node, "cache-unified");
> + return of_property_read_bool(np, "cache-unified");
> }
>
> -static void cache_of_override_properties(unsigned int cpu)
> +static void cache_of_set_props(struct cacheinfo *this_leaf,
> + struct device_node *np)
> {
> - int index;
> - struct cacheinfo *this_leaf;
> - struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
> -
> - for (index = 0; index < cache_leaves(cpu); index++) {
> - this_leaf = this_cpu_ci->info_list + index;
> - /*
> - * init_cache_level must setup the cache level correctly
> - * overriding the architecturally specified levels, so
> - * if type is NONE at this stage, it should be unified
> - */
> - if (this_leaf->type == CACHE_TYPE_NOCACHE &&
> - cache_node_is_unified(this_leaf))
> - this_leaf->type = CACHE_TYPE_UNIFIED;
> - cache_size(this_leaf);
> - cache_get_line_size(this_leaf);
> - cache_nr_sets(this_leaf);
> - cache_associativity(this_leaf);
> - }
> + /*
> + * init_cache_level must setup the cache level correctly
> + * overriding the architecturally specified levels, so
> + * if type is NONE at this stage, it should be unified
> + */
> + if (this_leaf->type == CACHE_TYPE_NOCACHE &&
> + cache_node_is_unified(this_leaf, np))
> + this_leaf->type = CACHE_TYPE_UNIFIED;
> + cache_size(this_leaf, np);
> + cache_get_line_size(this_leaf, np);
> + cache_nr_sets(this_leaf, np);
> + cache_associativity(this_leaf);
> }
>
> static int cache_setup_of_node(unsigned int cpu)
> @@ -193,6 +189,7 @@ static int cache_setup_of_node(unsigned int cpu)
> np = of_node_get(np);/* cpu node itself */
> if (!np)
> break;
> + cache_of_set_props(this_leaf, np);
> this_leaf->of_node = np;
> index++;
> }
> @@ -203,7 +200,6 @@ static int cache_setup_of_node(unsigned int cpu)
> return 0;
> }
> #else
> -static void cache_of_override_properties(unsigned int cpu) { }
> static inline int cache_setup_of_node(unsigned int cpu) { return 0; }
> static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
> struct cacheinfo *sib_leaf)
> @@ -286,12 +282,6 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
> }
> }
>
> -static void cache_override_properties(unsigned int cpu)
> -{
> - if (of_have_populated_dt())
> - return cache_of_override_properties(cpu);
> -}
> -
> static void free_cache_attributes(unsigned int cpu)
> {
> if (!per_cpu_cacheinfo(cpu))
> @@ -325,6 +315,10 @@ static int detect_cache_attributes(unsigned int cpu)
> if (per_cpu_cacheinfo(cpu) == NULL)
> return -ENOMEM;
>
> + /*
> + * populate_cache_leaves() may completely setup the cache leaves and
> + * shared_cpu_map or it may leave it partially setup.
> + */
> ret = populate_cache_leaves(cpu);
> if (ret)
> goto free_ci;
> @@ -338,7 +332,6 @@ static int detect_cache_attributes(unsigned int cpu)
> goto free_ci;
> }
>
> - cache_override_properties(cpu);
> return 0;
>
> free_ci:
>
^ permalink raw reply
* [PATCH v3 4/4] KVM: arm64: Add support for PUD hugepages at stage 2
From: Catalin Marinas @ 2018-05-15 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514144304.10484-5-punit.agrawal@arm.com>
On Mon, May 14, 2018 at 03:43:04PM +0100, Punit Agrawal wrote:
> KVM only supports PMD hugepages at stage 2. Extend the stage 2 fault
> handling to add support for PUD hugepages.
>
> Addition of pud hugepage support enables additional hugepage
> sizes (e.g., 1G with 4K granule) which can be useful on cores that
> support mapping larger block sizes in the TLB entries.
>
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/include/asm/kvm_mmu.h | 19 ++++++++++++
> arch/arm64/include/asm/kvm_mmu.h | 15 ++++++++++
> arch/arm64/include/asm/pgtable-hwdef.h | 4 +++
> arch/arm64/include/asm/pgtable.h | 2 ++
> virt/kvm/arm/mmu.c | 40 ++++++++++++++++++++++++--
> 5 files changed, 77 insertions(+), 3 deletions(-)
It looks like I acked an earlier version. I'll ack it again here:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH v4 0/6] clocksource: rework Atmel TCB timer driver
From: Sebastian Andrzej Siewior @ 2018-05-15 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502181046.GG19273@piout.net>
On 2018-05-02 20:10:46 [+0200], Alexandre Belloni wrote:
> > > As said below, this is solving multiple issues, including the one for
> > > SoCs that don't have the PIT.
> > will the PIT be removed? Where it needs the PIT?
> >
>
> The last patch is unselecting the PIT driver so by default it is not
> enabled. The PIT driver will stay just in case someone has to use it
> e.g. when they are using all the TCB channels for something else.
> However, recent Atmel SoC have a TCB without any output so it can ony be
> used as a timer. Some other SoCs don't have a PIT at all.
The question was more "does it make sense to keep the 'old' PIT driver
around or can it be removed and the TCB driver will be used by
everyone"?
> > > The remaining one would be "clocksource: TCLIB: Allow higher clock rates
> > > for clock events"
> >
> > I see. So I would need to keep that patch in queue after it was
> > dismissed from duty?
>
> Boris suggested a DT binding to allow changing the rate but it didn't
> reach consensus at the time. this is something that will ne to be
> revived at some point and I would very much like having that upstream
> too.
Does make sense to have a low frequency clock here? I think from
clocksource point of view it makes sense to have it (highres) enabled
and not having to adjust the DT first (not to mention to learn about
it).
Sebastian
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Add support for audio over HDMI for Odroid X/X2/U3
From: Krzysztof Kozlowski @ 2018-05-15 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514080148.10150-1-s.nawrocki@samsung.com>
On Mon, May 14, 2018 at 10:01:48AM +0200, Sylwester Nawrocki wrote:
> This patch switches Odroid X/X2/U3 to use dedicated Odroid audio subsystem
> DT bindings instead of the simple-card in order to add support for audio
> over HDMI.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 33 +++++++++++++++----------
> arch/arm/boot/dts/exynos4412-odroidu3.dts | 6 ++---
> arch/arm/boot/dts/exynos4412-odroidx.dts | 6 ++---
> 3 files changed, 26 insertions(+), 19 deletions(-)
>
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm: dts: omap: fix OF graph in omap3-devkit8000
From: Tony Lindgren @ 2018-05-15 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508135930.5768-5-robh@kernel.org>
* Rob Herring <robh@kernel.org> [180508 07:01]:
> omap3-devkit8000-common.dtsi defines a graph connection for DVI, but
> then omap3-devkit8000-lcd-common.dtsi overrides that with a graph
> connection for the LCD as the same output signals are used. This
> leaves an incomplete graph as the TFP410 output has only half a
> connection. The result is the following warning:
>
> arch/arm/boot/dts/omap3-devkit8000-lcd70.dtb: Warning (graph_endpoint): /encoder0/ports/port at 0/endpoint: graph connection to node '/ocp at 68000000/dss at 48050000/port/endpoint' is not bidirectional
>
> Fix this by defining multiple endpoints which is the correct way to show
> a 1 to many connection.
Applying into omap-for-v4.18/dt-fixes thanks.
Tony
^ permalink raw reply
* [PATCH] arm: dts: omap: fix OMAP3 CM-T3x OF graph video connectors
From: Tony Lindgren @ 2018-05-15 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508135930.5768-6-robh@kernel.org>
* Rob Herring <robh@kernel.org> [180508 07:01]:
> The OMAP3 CM-T3x based boards define 2 /connector nodes for S-Video and
> DVI output. However, since they have the same node name, the S-Video
> connector overwritten. This leaves a dangling graph connection which
> gives the following warning:
>
> arch/arm/boot/dts/omap3-sbc-t3517.dtb: Warning (graph_endpoint): /ocp at 68000000/dss at 48050000/encoder at 48050c00/port/endpoint: graph connection to node '/connector/port/endpoint' is not bidirectional
>
> Fix this by renaming the nodes to s-video-connector and dvi-connector.
Applying this too into omap-for-v4.18/dt-fixes.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: dts: am335x-evmsk: Add phandle for the backlight for the panel
From: Tony Lindgren @ 2018-05-15 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508100433.1051-1-peter.ujfalusi@ti.com>
* Peter Ujfalusi <peter.ujfalusi@ti.com> [180508 03:05]:
> With the backlight phandle the driver can manage the backlight on/off in
> sync with the panel enable/disable.
Applying into omap-for-v4.18/dt thanks.
Tony
^ permalink raw reply
* [PATCH] clk: stm32mp1: Add CLK_IGNORE_UNUSED to ck_sys_dbg clock
From: Stephen Boyd @ 2018-05-15 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1524556723-26926-1-git-send-email-gabriel.fernandez@st.com>
Quoting gabriel.fernandez at st.com (2018-04-24 00:58:43)
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> Don't disable the dbg clock if was set by bootloader.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
Applied to clk-next
^ permalink raw reply
* [PATCH v4 0/8] PCI: leak fixes, removable generic PCI host, assorted stuff
From: Bjorn Helgaas @ 2018-05-15 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526375226.git.jan.kiszka@siemens.com>
On Tue, May 15, 2018 at 11:06:59AM +0200, Jan Kiszka wrote:
> Changes in v4:
> - restore pci_free_resource_list() in error path of
> of_pci_get_host_bridge_resources()
>
> Changes in v3:
> - refactor series to be both bisectable and simpler while reworking
> of_pci_get_host_bridge_resources()
> - include of_pci_get_host_bridge_resources() removal
> - include devm_of_pci_get_host_bridge_resources() error path fixes
> - effectively, no functional changes to v2
>
> Changes in v2:
> - patch 1: commit message reworking as suggested by Lorenzo
> - patch 3-6: split-up as suggested by Bjorn
> - patch 8: new
> - patch 10: select PCI_DOMAINS from PCI_HOST_GENERIC, rather than
> allowing manual choice, as suggested by Lorenzo
>
> This primarily enables to unbind the generic PCI host controller without
> leaving lots of memory leaks behind. A previous proposal patch 5 was
> rejected because of those issues [1].
>
> The fixes have been validated in the Jailhouse setup, where we add and
> remove a virtual PCI host controller on hypervisor activation/
> deactivation, with the help of kmemleak.
>
> Besides that, there is tiny PCI API cleanup at the beginning and
> support for manually enabled PCI domains at the end that enables the
> Jailhouse scenario.
This is beautiful! Thanks for tweaking this one more time; I think it
really makes the patches much more readable.
I applied these with the tested-by/reviewed-by/acks to pci/resource for
v4.18.
Andy's comments certainly make sense, but doing it in the "Rework
of_pci_get_host_bridge_resources()" patch would make that patch less
obvious, so I'd rather do it as a cleanup on top.
> [1] http://lkml.iu.edu/hypermail/linux/kernel/1606.3/00072.html
>
>
> CC: Jingoo Han <jingoohan1@gmail.com>
> CC: Joao Pinto <Joao.Pinto@synopsys.com>
> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> CC: Will Deacon <will.deacon@arm.com>
>
> Jan Kiszka (8):
> PCI: Make pci_get_new_domain_nr() static
> PCI: Fix memory leak of devm_pci_alloc_host_bridge()
> PCI: Rename device node parameter of
> of_pci_get_host_bridge_resources()
> PCI: Replace dev_node parameter of of_pci_get_host_bridge_resources
> with device
> PCI: Replace pr_*() with dev_*() in of_pci_get_host_bridge_resources()
> PCI: Rework of_pci_get_host_bridge_resources() to
> devm_of_pci_get_host_bridge_resources()
> PCI: Add support for unbinding the generic PCI host controller
> PCI: Enable PCI_DOMAINS along with generic PCI host controller
>
> drivers/pci/dwc/pcie-designware-host.c | 2 +-
> drivers/pci/host/Kconfig | 1 +
> drivers/pci/host/pci-aardvark.c | 5 ++-
> drivers/pci/host/pci-ftpci100.c | 4 +--
> drivers/pci/host/pci-host-common.c | 13 +++++++
> drivers/pci/host/pci-host-generic.c | 1 +
> drivers/pci/host/pci-v3-semi.c | 3 +-
> drivers/pci/host/pci-versatile.c | 3 +-
> drivers/pci/host/pci-xgene.c | 3 +-
> drivers/pci/host/pcie-altera.c | 5 ++-
> drivers/pci/host/pcie-iproc-platform.c | 4 +--
> drivers/pci/host/pcie-rcar.c | 5 ++-
> drivers/pci/host/pcie-rockchip.c | 4 +--
> drivers/pci/host/pcie-xilinx-nwl.c | 4 +--
> drivers/pci/host/pcie-xilinx.c | 4 +--
> drivers/pci/of.c | 65 ++++++++++++++++------------------
> drivers/pci/pci.c | 6 ++--
> drivers/pci/probe.c | 4 ++-
> include/linux/of_pci.h | 4 +--
> include/linux/pci-ecam.h | 1 +
> include/linux/pci.h | 3 --
> 21 files changed, 76 insertions(+), 68 deletions(-)
>
> --
> 2.13.6
>
^ permalink raw reply
* [PATCH v9 00/24] ILP32 for ARM64
From: Yury Norov @ 2018-05-15 19:11 UTC (permalink / raw)
To: linux-arm-kernel
This series enables AARCH64 with ILP32 mode.
As supporting work, it introduces ARCH_32BIT_OFF_T configuration
option that is enabled for existing 32-bit architectures but disabled
for new arches (so 64-bit off_t userspace type is used by new userspace).
Also it deprecates getrlimit and setrlimit syscalls prior to prlimit64.
Based on kernel v4.16. Tested with LTP, glibc testsuite, trinity, lmbench,
CPUSpec.
This series on github:
https://github.com/norov/linux/tree/ilp32-4.16
Linaro toolchain:
http://snapshots.linaro.org/components/toolchain/binaries/7.3-2018.04-rc1/aarch64-linux-gnu_ilp32/
Debian repo:
http://people.linaro.org/~wookey/ilp32/
OpenSUSE repo:
https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:ILP32
Changes:
v3: https://lkml.org/lkml/2014/9/3/704
v4: https://lkml.org/lkml/2015/4/13/691
v5: https://lkml.org/lkml/2015/9/29/911
v6: https://lkml.org/lkml/2016/5/23/661
v7: https://lkml.org/lkml/2017/1/9/213
v8: https://lkml.org/lkml/2017/6/19/624
v9: - rebased on top of v4.16;
- signal subsystem reworked to avoid code duplication, as requested
by Dave Martin (patches 18 and 20);
- new files introduced in series use SPDX notation for license;
- linux-api and linux-arch CCed as the series changes kernel ABI;
- checkpatch and other minor fixes.
Andrew Pinski (4):
arm64: rename COMPAT to AARCH32_EL0 in Kconfig
arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
it
arm64:ilp32: add ARM64_ILP32 to Kconfig
Catalin Marinas (1):
arm64: ilp32: Make the Kconfig option default y
Dave Martin (1):
arm64: signal: Make parse_user_sigframe() independent of rt_sigframe
layout
James Morse (1):
ptrace: Add compat PTRACE_{G,S}ETSIGMASK handlers
Philipp Tomsich (1):
arm64:ilp32: add vdso-ilp32 and use for signal return
Yury Norov (16):
compat ABI: use non-compat openat and open_by_handle_at variants
32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option
asm-generic: Drop getrlimit and setrlimit syscalls from default list
thread: move thread bits accessors to separated file
arm64: ilp32: add documentation on the ILP32 ABI for ARM64
arm64: rename functions that reference compat term
arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
arm64: introduce binfmt_elf32.c
arm64: change compat_elf_hwcap and compat_elf_hwcap2 prefix to a32
arm64: ilp32: introduce binfmt_ilp32.c
arm64: ilp32: share aarch32 syscall handlers
arm64: signal: share lp64 signal structures and routines to ilp32
arm64: signal32: move ilp32 and aarch32 common code to separated file
arm64: ilp32: introduce ilp32-specific sigframe and ucontext
arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
Documentation/arm64/ilp32.txt | 45 +++
arch/Kconfig | 15 +
arch/arc/Kconfig | 1 +
arch/arc/include/uapi/asm/unistd.h | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 18 +-
arch/arm64/Makefile | 3 +
arch/arm64/include/asm/compat.h | 19 +-
arch/arm64/include/asm/elf.h | 36 +-
arch/arm64/include/asm/fpsimd.h | 2 +-
arch/arm64/include/asm/ftrace.h | 2 +-
arch/arm64/include/asm/hwcap.h | 8 +-
arch/arm64/include/asm/is_compat.h | 78 ++++
arch/arm64/include/asm/processor.h | 15 +-
arch/arm64/include/asm/ptrace.h | 12 +-
arch/arm64/include/asm/seccomp.h | 2 +-
arch/arm64/include/asm/signal32.h | 19 +-
arch/arm64/include/asm/signal32_common.h | 13 +
arch/arm64/include/asm/signal_common.h | 306 +++++++++++++++
arch/arm64/include/asm/signal_ilp32.h | 23 ++
arch/arm64/include/asm/syscall.h | 2 +-
arch/arm64/include/asm/thread_info.h | 4 +-
arch/arm64/include/asm/unistd.h | 6 +-
arch/arm64/include/asm/vdso.h | 6 +
arch/arm64/include/uapi/asm/bitsperlong.h | 9 +-
arch/arm64/include/uapi/asm/unistd.h | 13 +
arch/arm64/kernel/Makefile | 8 +-
arch/arm64/kernel/armv8_deprecated.c | 6 +-
arch/arm64/kernel/asm-offsets.c | 9 +-
arch/arm64/kernel/binfmt_elf32.c | 35 ++
arch/arm64/kernel/binfmt_ilp32.c | 87 +++++
arch/arm64/kernel/cpufeature.c | 28 +-
arch/arm64/kernel/cpuinfo.c | 18 +-
arch/arm64/kernel/debug-monitors.c | 4 +-
arch/arm64/kernel/entry.S | 37 +-
arch/arm64/kernel/entry32.S | 80 ----
arch/arm64/kernel/entry32_common.S | 97 +++++
arch/arm64/kernel/entry_ilp32.S | 12 +
arch/arm64/kernel/head.S | 2 +-
arch/arm64/kernel/hw_breakpoint.c | 8 +-
arch/arm64/kernel/perf_callchain.c | 28 +-
arch/arm64/kernel/perf_regs.c | 4 +-
arch/arm64/kernel/process.c | 11 +-
arch/arm64/kernel/ptrace.c | 36 +-
arch/arm64/kernel/signal.c | 352 +++---------------
arch/arm64/kernel/signal32.c | 111 +++---
arch/arm64/kernel/signal32_common.c | 37 ++
arch/arm64/kernel/signal_ilp32.c | 65 ++++
arch/arm64/kernel/sys_compat.c | 10 +-
arch/arm64/kernel/sys_ilp32.c | 90 +++++
arch/arm64/kernel/traps.c | 11 +-
arch/arm64/kernel/vdso-ilp32/.gitignore | 2 +
arch/arm64/kernel/vdso-ilp32/Makefile | 82 ++++
arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S | 22 ++
arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S | 84 +++++
arch/arm64/kernel/vdso.c | 65 +++-
arch/arm64/kernel/vdso/gettimeofday.S | 20 +-
arch/arm64/kernel/vdso/vdso.S | 6 +-
arch/arm64/mm/mmap.c | 2 +-
arch/blackfin/Kconfig | 1 +
arch/c6x/include/uapi/asm/unistd.h | 1 +
arch/cris/Kconfig | 1 +
arch/frv/Kconfig | 1 +
arch/h8300/Kconfig | 1 +
arch/h8300/include/uapi/asm/unistd.h | 1 +
arch/hexagon/Kconfig | 1 +
arch/hexagon/include/uapi/asm/unistd.h | 1 +
arch/m32r/Kconfig | 1 +
arch/m68k/Kconfig | 1 +
arch/metag/Kconfig | 1 +
arch/metag/include/uapi/asm/unistd.h | 1 +
arch/microblaze/Kconfig | 1 +
arch/mips/Kconfig | 1 +
arch/mn10300/Kconfig | 1 +
arch/nios2/Kconfig | 1 +
arch/nios2/include/uapi/asm/unistd.h | 1 +
arch/openrisc/Kconfig | 1 +
arch/openrisc/include/uapi/asm/unistd.h | 1 +
arch/parisc/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
arch/score/Kconfig | 1 +
arch/score/include/uapi/asm/unistd.h | 1 +
arch/sh/Kconfig | 1 +
arch/sparc/Kconfig | 1 +
arch/tile/Kconfig | 1 +
arch/tile/include/uapi/asm/unistd.h | 1 +
arch/tile/kernel/compat.c | 3 +
arch/unicore32/Kconfig | 1 +
arch/unicore32/include/uapi/asm/unistd.h | 1 +
arch/x86/Kconfig | 1 +
arch/x86/um/Kconfig | 1 +
arch/xtensa/Kconfig | 1 +
drivers/clocksource/arm_arch_timer.c | 4 +-
include/linux/fcntl.h | 2 +-
include/linux/sched.h | 1 +
include/linux/thread_bits.h | 76 ++++
include/linux/thread_info.h | 64 +---
include/uapi/asm-generic/unistd.h | 10 +-
kernel/ptrace.c | 48 ++-
scripts/checksyscalls.sh | 5 +
100 files changed, 1675 insertions(+), 698 deletions(-)
create mode 100644 Documentation/arm64/ilp32.txt
create mode 100644 arch/arm64/include/asm/is_compat.h
create mode 100644 arch/arm64/include/asm/signal32_common.h
create mode 100644 arch/arm64/include/asm/signal_common.h
create mode 100644 arch/arm64/include/asm/signal_ilp32.h
create mode 100644 arch/arm64/kernel/binfmt_elf32.c
create mode 100644 arch/arm64/kernel/binfmt_ilp32.c
create mode 100644 arch/arm64/kernel/entry32_common.S
create mode 100644 arch/arm64/kernel/entry_ilp32.S
create mode 100644 arch/arm64/kernel/signal32_common.c
create mode 100644 arch/arm64/kernel/signal_ilp32.c
create mode 100644 arch/arm64/kernel/sys_ilp32.c
create mode 100644 arch/arm64/kernel/vdso-ilp32/.gitignore
create mode 100644 arch/arm64/kernel/vdso-ilp32/Makefile
create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S
create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S
create mode 100644 include/linux/thread_bits.h
--
2.17.0
^ permalink raw reply
* [PATCH 01/24] arm64: signal: Make parse_user_sigframe() independent of rt_sigframe layout
From: Yury Norov @ 2018-05-15 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515191214.5045-1-ynorov@caviumnetworks.com>
From: Dave Martin <Dave.Martin@arm.com>
ILP32 uses the same struct sigcontext as the native ABI (i.e.,
LP64), but a different layout for the rest of the signal frame (since
siginfo_t and ucontext_t are both ABI-dependent).
Since the purpose of parse_user_sigframe() is really to parse sigcontext
and not the whole signal frame, the function does not need to depend
on the layout of rt_sigframe -- the only purpose of the rt_sigframe
pointer is for use as a base to measure the signal frame size.
So, this patch renames the function to make it clear that only the
sigcontext is really being parsed, and makes the sigframe base pointer
generic. A macro is defined to provide a suitable duck-typed interface
that can be used with both sigframe definitions.
Suggested-by: Yury Norov <ynorov@caviumnetworks.com>
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
---
arch/arm64/kernel/signal.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index f60c052e8d1c..65406218743c 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -334,17 +334,16 @@ extern int restore_sve_fpsimd_context(struct user_ctxs *user);
#endif /* ! CONFIG_ARM64_SVE */
-
-static int parse_user_sigframe(struct user_ctxs *user,
- struct rt_sigframe __user *sf)
+static int __parse_user_sigcontext(struct user_ctxs *user,
+ struct sigcontext __user const *sc,
+ void __user const *sigframe_base)
{
- struct sigcontext __user *const sc = &sf->uc.uc_mcontext;
struct _aarch64_ctx __user *head;
char __user *base = (char __user *)&sc->__reserved;
size_t offset = 0;
size_t limit = sizeof(sc->__reserved);
bool have_extra_context = false;
- char const __user *const sfp = (char const __user *)sf;
+ char const __user *const sfp = (char const __user *)sigframe_base;
user->fpsimd = NULL;
user->sve = NULL;
@@ -493,6 +492,9 @@ static int parse_user_sigframe(struct user_ctxs *user,
return -EINVAL;
}
+#define parse_user_sigcontext(user, sf) \
+ __parse_user_sigcontext(user, &(sf)->uc.uc_mcontext, sf)
+
static int restore_sigframe(struct pt_regs *regs,
struct rt_sigframe __user *sf)
{
@@ -518,7 +520,7 @@ static int restore_sigframe(struct pt_regs *regs,
err |= !valid_user_regs(®s->user_regs, current);
if (err == 0)
- err = parse_user_sigframe(&user, sf);
+ err = parse_user_sigcontext(&user, sf);
if (err == 0) {
if (!user.fpsimd)
--
2.17.0
^ permalink raw reply related
* [PATCH 02/24] ptrace: Add compat PTRACE_{G,S}ETSIGMASK handlers
From: Yury Norov @ 2018-05-15 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515191214.5045-1-ynorov@caviumnetworks.com>
From: James Morse <james.morse@arm.com>
compat_ptrace_request() lacks handlers for PTRACE_{G,S}ETSIGMASK,
instead using those in ptrace_request(). The compat variant should
read a compat_sigset_t from userspace instead of ptrace_request()s
sigset_t.
While compat_sigset_t is the same size as sigset_t, it is defined as
2xu32, instead of a single u64. On a big-endian CPU this means that
compat_sigset_t is passed to user-space using middle-endianness,
where the least-significant u32 is written most significant byte
first.
If ptrace_request()s code is used userspace will read the most
significant u32 where it expected the least significant.
Instead of duplicating ptrace_request()s code as a special case in
the arch code, handle it here.
Fixes: 29000caecbe87 ("ptrace: add ability to get/set signal-blocked mask")
CC: Andrey Vagin <avagin@openvz.org>
Reported-by: Zhou Chengming <zhouchengming1@huawei.com>
Signed-off-by: James Morse <james.morse@arm.com>
Yury:
Replace sigset_{to,from}_compat() with new {get,put}_compat_sigset()
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
---
kernel/ptrace.c | 48 ++++++++++++++++++++++++++++++++++++------------
1 file changed, 36 insertions(+), 12 deletions(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 21fec73d45d4..214944d7c268 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -880,6 +880,22 @@ static int ptrace_regset(struct task_struct *task, int req, unsigned int type,
EXPORT_SYMBOL_GPL(task_user_regset_view);
#endif
+static int ptrace_setsigmask(struct task_struct *child, sigset_t *new_set)
+{
+ sigdelsetmask(new_set, sigmask(SIGKILL)|sigmask(SIGSTOP));
+
+ /*
+ * Every thread does recalc_sigpending() after resume, so
+ * retarget_shared_pending() and recalc_sigpending() are not
+ * called here.
+ */
+ spin_lock_irq(&child->sighand->siglock);
+ child->blocked = *new_set;
+ spin_unlock_irq(&child->sighand->siglock);
+
+ return 0;
+}
+
int ptrace_request(struct task_struct *child, long request,
unsigned long addr, unsigned long data)
{
@@ -951,18 +967,7 @@ int ptrace_request(struct task_struct *child, long request,
break;
}
- sigdelsetmask(&new_set, sigmask(SIGKILL)|sigmask(SIGSTOP));
-
- /*
- * Every thread does recalc_sigpending() after resume, so
- * retarget_shared_pending() and recalc_sigpending() are not
- * called here.
- */
- spin_lock_irq(&child->sighand->siglock);
- child->blocked = new_set;
- spin_unlock_irq(&child->sighand->siglock);
-
- ret = 0;
+ ret = ptrace_setsigmask(child, &new_set);
break;
}
@@ -1181,6 +1186,7 @@ int compat_ptrace_request(struct task_struct *child, compat_long_t request,
{
compat_ulong_t __user *datap = compat_ptr(data);
compat_ulong_t word;
+ sigset_t new_set;
siginfo_t siginfo;
int ret;
@@ -1221,6 +1227,24 @@ int compat_ptrace_request(struct task_struct *child, compat_long_t request,
else
ret = ptrace_setsiginfo(child, &siginfo);
break;
+ case PTRACE_GETSIGMASK:
+ if (addr != sizeof(compat_sigset_t))
+ return -EINVAL;
+
+ ret = put_compat_sigset((compat_sigset_t __user *) datap,
+ &child->blocked, sizeof(compat_sigset_t));
+ break;
+ case PTRACE_SETSIGMASK:
+ if (addr != sizeof(compat_sigset_t))
+ return -EINVAL;
+
+ ret = get_compat_sigset(&new_set,
+ (compat_sigset_t __user *) datap);
+ if (ret)
+ break;
+
+ ret = ptrace_setsigmask(child, &new_set);
+ break;
#ifdef CONFIG_HAVE_ARCH_TRACEHOOK
case PTRACE_GETREGSET:
case PTRACE_SETREGSET:
--
2.17.0
^ permalink raw reply related
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
From: Andy Shevchenko @ 2018-05-15 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <78b08b68-ff57-8dd8-6eb1-00548f275eac@arm.com>
On Tue, May 15, 2018 at 8:15 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> On 05/11/2018 06:57 PM, Jeremy Linton wrote:
>> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
>> + cache_size = of_get_property(np, propname, NULL);
>> if (cache_size)
>> this_leaf->size = of_read_number(cache_size, 1);
Can't you switch to of_read_property_uXX() variant here?
>> - line_size = of_get_property(this_leaf->of_node, propname,
>> NULL);
>> + line_size = of_get_property(np, propname, NULL);
Ditto.
>> - nr_sets = of_get_property(this_leaf->of_node, propname, NULL);
>> + nr_sets = of_get_property(np, propname, NULL);
>> if (nr_sets)
>> this_leaf->number_of_sets = of_read_number(nr_sets, 1);
Ditto.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v9 00/24] ILP32 for ARM64
From: Yury Norov @ 2018-05-15 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515191214.5045-1-ynorov@caviumnetworks.com>
Hi all,
On Tue, May 15, 2018 at 10:11:50PM +0300, Yury Norov wrote:
> This series enables AARCH64 with ILP32 mode.
>
> As supporting work, it introduces ARCH_32BIT_OFF_T configuration
> option that is enabled for existing 32-bit architectures but disabled
> for new arches (so 64-bit off_t userspace type is used by new userspace).
> Also it deprecates getrlimit and setrlimit syscalls prior to prlimit64.
>
> Based on kernel v4.16. Tested with LTP, glibc testsuite, trinity, lmbench,
> CPUSpec.
>
> This series on github:
> https://github.com/norov/linux/tree/ilp32-4.16
> Linaro toolchain:
> http://snapshots.linaro.org/components/toolchain/binaries/7.3-2018.04-rc1/aarch64-linux-gnu_ilp32/
> Debian repo:
> http://people.linaro.org/~wookey/ilp32/
> OpenSUSE repo:
> https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:ILP32
>
> Changes:
> v3: https://lkml.org/lkml/2014/9/3/704
> v4: https://lkml.org/lkml/2015/4/13/691
> v5: https://lkml.org/lkml/2015/9/29/911
> v6: https://lkml.org/lkml/2016/5/23/661
> v7: https://lkml.org/lkml/2017/1/9/213
> v8: https://lkml.org/lkml/2017/6/19/624
> v9: - rebased on top of v4.16;
> - signal subsystem reworked to avoid code duplication, as requested
> by Dave Martin (patches 18 and 20);
> - new files introduced in series use SPDX notation for license;
> - linux-api and linux-arch CCed as the series changes kernel ABI;
> - checkpatch and other minor fixes.
My mail server seems broken. I will try to submit series tomorroe
again. Sorry for noise.
Yury
^ permalink raw reply
* [PATCHv2] arm64: dts: stratix10: Add QSPI support for Stratix10
From: Thor Thayer @ 2018-05-15 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20b33e1d-0609-78dd-dc9c-922658a11f18@kernel.org>
On 05/15/2018 10:11 AM, Dinh Nguyen wrote:
>
> On 05/11/2018 11:10 AM, thor.thayer at linux.intel.com wrote:
>> From: Thor Thayer <thor.thayer@linux.intel.com>
>>
>> Add qspi_clock
>> The qspi_clk frequency is updated by U-Boot before starting Linux.
>> Add QSPI interface node.
>> Add QSPI flash memory child node.
>> Setup the QSPI memory in 2 partitions.
>>
>> Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
>> ---
>> v2 s/_/-/ in qspi-clk
>> rename flash node.
>> use partition child node notation<snip>>> + qspi: spi at ff8d2000 {
>> + compatible = "cdns,qspi-nor";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0xff8d2000 0x100>,
>> + <0xff900000 0x100000>;
>> + interrupts = <0 3 4>;
>> + cdns,fifo-depth = <128>;
>> + cdns,fifo-width = <4>;
>> + cdns,trigger-address = <0x00000000>;
>> + clocks = <&qspi_clk>;
>> + bus-num = <1>;
>
> I don't you need "bus-num" anymore right? I don't see it getting used
> anywhere in the driver.
>
> Dinh
>
Yes, I missed that holdover. Thanks, I'll correct that.
^ permalink raw reply
* [xlnx:master 1122/1651] drivers/dma//xilinx/xilinx_ps_pcie_platform.c:2957:14: error: 'DMA_SG' undeclared; did you mean 'DMA_PQ'?
From: kbuild test robot @ 2018-05-15 20:17 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/Xilinx/linux-xlnx master
head: c3ad4b9f92cef73b118446312f39f2dbe9fc0ff1
commit: 818f168696f561c127f161379eb5b8d1835218a2 [1122/1651] Merge tag 'v4.14' into master
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 818f168696f561c127f161379eb5b8d1835218a2
# save the attached .config to linux build tree
make ARCH=x86_64
Note: the xlnx/master HEAD c3ad4b9f92cef73b118446312f39f2dbe9fc0ff1 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
In file included from drivers/net/ethernet/cadence/macb_pci.c:29:0:
>> drivers/net/ethernet/cadence/macb.h:927:2: error: unknown type name 'phy_interface_t'
phy_interface_t phy_interface;
^~~~~~~~~~~~~~~
>> drivers/net/ethernet/cadence/macb.h:943:24: error: field 'ptp_caps' has incomplete type
struct ptp_clock_info ptp_caps;
^~~~~~~~
--
>> drivers/media//platform/xilinx/xilinx-csi2rxss.c:43:10: fatal error: media/v4l2-of.h: No such file or directory
#include <media/v4l2-of.h>
^~~~~~~~~~~~~~~~~
compilation terminated.
--
In file included from drivers/dma//xilinx/xilinx_ps_pcie.h:16:0,
from drivers/dma//xilinx/xilinx_ps_pcie_platform.c:15:
drivers/dma//xilinx/xilinx_ps_pcie_platform.c: In function 'xlnx_pcie_dma_driver_probe':
>> drivers/dma//xilinx/xilinx_ps_pcie_platform.c:2957:14: error: 'DMA_SG' undeclared (first use in this function); did you mean 'DMA_PQ'?
dma_cap_set(DMA_SG, xdev->common.cap_mask);
^
include/linux/dmaengine.h:1201:46: note: in definition of macro 'dma_cap_set'
#define dma_cap_set(tx, mask) __dma_cap_set((tx), &(mask))
^~
drivers/dma//xilinx/xilinx_ps_pcie_platform.c:2957:14: note: each undeclared identifier is reported only once for each function it appears in
dma_cap_set(DMA_SG, xdev->common.cap_mask);
^
include/linux/dmaengine.h:1201:46: note: in definition of macro 'dma_cap_set'
#define dma_cap_set(tx, mask) __dma_cap_set((tx), &(mask))
^~
>> drivers/dma//xilinx/xilinx_ps_pcie_platform.c:2972:15: error: 'struct dma_device' has no member named 'device_prep_dma_sg'; did you mean 'device_prep_dma_pq'?
xdev->common.device_prep_dma_sg = xlnx_ps_pcie_dma_prep_dma_sg;
^~~~~~~~~~~~~~~~~~
device_prep_dma_pq
--
drivers/dma//xilinx/xilinx_ps_pcie_dma_client.c: In function 'initiate_sync_transfer':
>> drivers/dma//xilinx/xilinx_ps_pcie_dma_client.c:310:17: error: 'struct dma_device' has no member named 'device_prep_dma_sg'; did you mean 'device_prep_dma_pq'?
txd = device->device_prep_dma_sg(chan, dst_sg->sgl,
^~~~~~~~~~~~~~~~~~
device_prep_dma_pq
drivers/dma//xilinx/xilinx_ps_pcie_dma_client.c: In function 'initiate_async_transfer':
drivers/dma//xilinx/xilinx_ps_pcie_dma_client.c:697:17: error: 'struct dma_device' has no member named 'device_prep_dma_sg'; did you mean 'device_prep_dma_pq'?
txd = device->device_prep_dma_sg(chan, dst_sg->sgl,
^~~~~~~~~~~~~~~~~~
device_prep_dma_pq
vim +2957 drivers/dma//xilinx/xilinx_ps_pcie_platform.c
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2909
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2910 xdev->is_rootdma = device_property_read_bool(&platform_dev->dev,
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2911 "rootdma");
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2912
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2913 xdev->dev = &platform_dev->dev;
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2914 xdev->board_number = board_number;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2915
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2916 err = device_property_read_u32(&platform_dev->dev, "numchannels",
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2917 &xdev->num_channels);
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2918 if (err) {
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2919 dev_err(&platform_dev->dev,
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2920 "Unable to find numchannels property\n");
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2921 goto platform_driver_probe_return;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2922 }
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2923
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2924 if (xdev->num_channels == 0 || xdev->num_channels >
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2925 MAX_ALLOWED_CHANNELS_IN_HW) {
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2926 dev_warn(&platform_dev->dev,
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2927 "Invalid xlnx-num_channels property value\n");
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2928 xdev->num_channels = MAX_ALLOWED_CHANNELS_IN_HW;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2929 }
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2930
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2931 xdev->channels =
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2932 (struct ps_pcie_dma_chan *)devm_kzalloc(&platform_dev->dev,
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2933 sizeof(struct ps_pcie_dma_chan)
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2934 * xdev->num_channels,
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2935 GFP_KERNEL);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2936 if (!xdev->channels) {
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2937 err = -ENOMEM;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2938 goto platform_driver_probe_return;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2939 }
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2940
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2941 if (xdev->is_rootdma)
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2942 err = read_rootdma_config(platform_dev, xdev);
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2943 else
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2944 err = read_epdma_config(platform_dev, xdev);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2945
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2946 if (err) {
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2947 dev_err(&platform_dev->dev,
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2948 "Unable to initialize dma configuration\n");
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2949 goto platform_driver_probe_return;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2950 }
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2951
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2952 /* Initialize the DMA engine */
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2953 INIT_LIST_HEAD(&xdev->common.channels);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2954
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2955 dma_cap_set(DMA_SLAVE, xdev->common.cap_mask);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2956 dma_cap_set(DMA_PRIVATE, xdev->common.cap_mask);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 @2957 dma_cap_set(DMA_SG, xdev->common.cap_mask);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2958 dma_cap_set(DMA_INTERRUPT, xdev->common.cap_mask);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2959
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2960 xdev->common.src_addr_widths = DMA_SLAVE_BUSWIDTH_UNDEFINED;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2961 xdev->common.dst_addr_widths = DMA_SLAVE_BUSWIDTH_UNDEFINED;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2962 xdev->common.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2963 xdev->common.device_alloc_chan_resources =
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2964 xlnx_ps_pcie_dma_alloc_chan_resources;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2965 xdev->common.device_free_chan_resources =
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2966 xlnx_ps_pcie_dma_free_chan_resources;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2967 xdev->common.device_terminate_all = xlnx_ps_pcie_dma_terminate_all;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2968 xdev->common.device_tx_status = dma_cookie_status;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2969 xdev->common.device_issue_pending = xlnx_ps_pcie_dma_issue_pending;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2970 xdev->common.device_prep_dma_interrupt =
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2971 xlnx_ps_pcie_dma_prep_interrupt;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 @2972 xdev->common.device_prep_dma_sg = xlnx_ps_pcie_dma_prep_dma_sg;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2973 xdev->common.device_prep_slave_sg = xlnx_ps_pcie_dma_prep_slave_sg;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2974 xdev->common.residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2975
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2976 for (i = 0; i < xdev->num_channels; i++) {
8ddb7910 Ravi Shankar Jonnalagadda 2017-05-12 2977 err = probe_channel_properties(platform_dev, xdev, i);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2978
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2979 if (err != 0) {
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2980 dev_err(xdev->dev,
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2981 "Unable to read channel properties\n");
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2982 goto platform_driver_probe_return;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2983 }
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2984 }
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2985
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2986 if (xdev->is_rootdma)
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2987 err = platform_irq_setup(xdev);
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2988 else
8ddb7910 Ravi Shankar Jonnalagadda 2017-05-12 2989 err = irq_setup(xdev);
8ddb7910 Ravi Shankar Jonnalagadda 2017-05-12 2990 if (err) {
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2991 dev_err(xdev->dev, "Cannot request irq lines for device %d\n",
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2992 xdev->board_number);
8ddb7910 Ravi Shankar Jonnalagadda 2017-05-12 2993 goto platform_driver_probe_return;
8ddb7910 Ravi Shankar Jonnalagadda 2017-05-12 2994 }
8ddb7910 Ravi Shankar Jonnalagadda 2017-05-12 2995
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2996 err = dma_async_device_register(&xdev->common);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2997 if (err) {
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2998 dev_err(xdev->dev,
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2999 "Unable to register board %d with dma framework\n",
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 3000 xdev->board_number);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3001 goto platform_driver_probe_return;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3002 }
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3003
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3004 platform_set_drvdata(platform_dev, xdev);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3005
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 3006 board_number++;
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 3007
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 3008 dev_info(&platform_dev->dev, "PS PCIe Platform driver probed\n");
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3009 return 0;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3010
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3011 platform_driver_probe_return:
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3012 return err;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3013 }
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3014
:::::: The code at line 2957 was first introduced by commit
:::::: 361e937922b2073151335141bcd67b37f46b52fb PCI: ZYNQMP EP driver: Adding support for ZynqMP ep driver
:::::: TO: Ravi Shankar Jonnalagadda <venkata.ravi.jonnalagadda@xilinx.com>
:::::: CC: Michal Simek <michal.simek@xilinx.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 61983 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180516/69687a2f/attachment-0001.gz>
^ 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