* [PATCH v29 5/9] arm64: kdump: add VMCOREINFO's for user-space tools
From: AKASHI Takahiro @ 2016-12-28 4:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161228043347.27358-1-takahiro.akashi@linaro.org>
In addition to common VMCOREINFO's defined in
crash_save_vmcoreinfo_init(), we need to know, for crash utility,
- kimage_voffset
- PHYS_OFFSET
to examine the contents of a dump file (/proc/vmcore) correctly
due to the introduction of KASLR (CONFIG_RANDOMIZE_BASE) in v4.6.
- VA_BITS
is also required for makedumpfile command.
arch_crash_save_vmcoreinfo() appends them to the dump file.
More VMCOREINFO's may be added later.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: James Morse <james.morse@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/kernel/machine_kexec.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index c60346d33bb1..994fe0bc5cc0 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -17,6 +17,7 @@
#include <asm/cacheflush.h>
#include <asm/cpu_ops.h>
+#include <asm/memory.h>
#include <asm/mmu_context.h>
#include "cpu-reset.h"
@@ -260,3 +261,13 @@ void machine_crash_shutdown(struct pt_regs *regs)
pr_info("Starting crashdump kernel...\n");
}
+
+void arch_crash_save_vmcoreinfo(void)
+{
+ VMCOREINFO_NUMBER(VA_BITS);
+ /* Please note VMCOREINFO_NUMBER() uses "%d", not "%x" */
+ vmcoreinfo_append_str("NUMBER(kimage_voffset)=0x%llx\n",
+ kimage_voffset);
+ vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%llx\n",
+ PHYS_OFFSET);
+}
--
2.11.0
^ permalink raw reply related
* [PATCH v29 6/9] arm64: kdump: provide /proc/vmcore file
From: AKASHI Takahiro @ 2016-12-28 4:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161228043347.27358-1-takahiro.akashi@linaro.org>
Add arch-specific functions to provide a dump file, /proc/vmcore.
This file is in ELF format and its ELF header needs to be prepared by
userspace tools, like kexec-tools, in adance. The primary kernel is
responsible to allocate the region with reserve_elfcorehdr() at boot time
and advertize its location to crash dump kernel via a new device-tree
property, "linux,elfcorehdr".
Then crash dump kernel will access the primary kernel's memory with
copy_oldmem_page(), which feeds the data page-by-page by ioremap'ing it
since it does not reside in linear mapping on crash dump kernel.
We also need our own elfcorehdr_read() here since the header is placed
within crash dump kernel's usable memory.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: James Morse <james.morse@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/Kconfig | 11 +++++++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/crash_dump.c | 71 ++++++++++++++++++++++++++++++++++++++++++
arch/arm64/mm/init.c | 54 ++++++++++++++++++++++++++++++++
4 files changed, 137 insertions(+)
create mode 100644 arch/arm64/kernel/crash_dump.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 111742126897..2bd6a1a062b9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -693,6 +693,17 @@ config KEXEC
but it is independent of the system firmware. And like a reboot
you can start any kernel with it, not just Linux.
+config CRASH_DUMP
+ bool "Build kdump crash kernel"
+ help
+ Generate crash dump after being started by kexec. This should
+ be normally only set in special crash dump kernels which are
+ loaded in the main kernel with kexec-tools into a specially
+ reserved region and then later executed after a crash by
+ kdump/kexec.
+
+ For more details see Documentation/kdump/kdump.txt
+
config XEN_DOM0
def_bool y
depends on XEN
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 7d66bbaafc0c..6a7384eee08d 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -50,6 +50,7 @@ arm64-obj-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
arm64-obj-$(CONFIG_HIBERNATION) += hibernate.o hibernate-asm.o
arm64-obj-$(CONFIG_KEXEC) += machine_kexec.o relocate_kernel.o \
cpu-reset.o
+arm64-obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
obj-y += $(arm64-obj-y) vdso/ probes/
obj-m += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/crash_dump.c b/arch/arm64/kernel/crash_dump.c
new file mode 100644
index 000000000000..c3d5a21c081e
--- /dev/null
+++ b/arch/arm64/kernel/crash_dump.c
@@ -0,0 +1,71 @@
+/*
+ * Routines for doing kexec-based kdump
+ *
+ * Copyright (C) 2014 Linaro Limited
+ * Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/crash_dump.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+#include <linux/memblock.h>
+#include <linux/uaccess.h>
+#include <asm/memory.h>
+
+/**
+ * copy_oldmem_page() - copy one page from old kernel memory
+ * @pfn: page frame number to be copied
+ * @buf: buffer where the copied page is placed
+ * @csize: number of bytes to copy
+ * @offset: offset in bytes into the page
+ * @userbuf: if set, @buf is in a user address space
+ *
+ * This function copies one page from old kernel memory into buffer pointed by
+ * @buf. If @buf is in userspace, set @userbuf to %1. Returns number of bytes
+ * copied or negative error in case of failure.
+ */
+ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
+ size_t csize, unsigned long offset,
+ int userbuf)
+{
+ void *vaddr;
+
+ if (!csize)
+ return 0;
+
+ vaddr = memremap(__pfn_to_phys(pfn), PAGE_SIZE, MEMREMAP_WB);
+ if (!vaddr)
+ return -ENOMEM;
+
+ if (userbuf) {
+ if (copy_to_user((char __user *)buf, vaddr + offset, csize)) {
+ memunmap(vaddr);
+ return -EFAULT;
+ }
+ } else {
+ memcpy(buf, vaddr + offset, csize);
+ }
+
+ memunmap(vaddr);
+
+ return csize;
+}
+
+/**
+ * elfcorehdr_read - read from ELF core header
+ * @buf: buffer where the data is placed
+ * @csize: number of bytes to read
+ * @ppos: address in the memory
+ *
+ * This function reads @count bytes from elf core header which exists
+ * on crash dump kernel's memory.
+ */
+ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos)
+{
+ memcpy(buf, phys_to_virt((phys_addr_t)*ppos), count);
+ return count;
+}
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 1d62bf71b531..ef8adfde32e7 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -38,6 +38,7 @@
#include <linux/swiotlb.h>
#include <linux/vmalloc.h>
#include <linux/kexec.h>
+#include <linux/crash_dump.h>
#include <asm/boot.h>
#include <asm/fixmap.h>
@@ -183,6 +184,57 @@ static void __init reserve_crashkernel(void)
}
#endif /* CONFIG_KEXEC_CORE */
+#ifdef CONFIG_CRASH_DUMP
+static int __init early_init_dt_scan_elfcorehdr(unsigned long node,
+ const char *uname, int depth, void *data)
+{
+ const __be32 *reg;
+ int len;
+
+ if (depth != 1 || strcmp(uname, "chosen") != 0)
+ return 0;
+
+ reg = of_get_flat_dt_prop(node, "linux,elfcorehdr", &len);
+ if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
+ return 1;
+
+ elfcorehdr_addr = dt_mem_next_cell(dt_root_addr_cells, ®);
+ elfcorehdr_size = dt_mem_next_cell(dt_root_size_cells, ®);
+
+ return 1;
+}
+
+/*
+ * reserve_elfcorehdr() - reserves memory for elf core header
+ *
+ * This function reserves elf core header given in "elfcorehdr=" kernel
+ * command line parameter. This region contains all the information about
+ * primary kernel's core image and is used by a dump capture kernel to
+ * access the system memory on primary kernel.
+ */
+static void __init reserve_elfcorehdr(void)
+{
+ of_scan_flat_dt(early_init_dt_scan_elfcorehdr, NULL);
+
+ if (!elfcorehdr_size)
+ return;
+
+ if (memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)) {
+ pr_warn("elfcorehdr is overlapped\n");
+ return;
+ }
+
+ memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
+
+ pr_info("Reserving %lldKB of memory@0x%llx for elfcorehdr\n",
+ elfcorehdr_size >> 10, elfcorehdr_addr);
+}
+#else
+static void __init reserve_elfcorehdr(void)
+{
+ ;
+}
+#endif /* CONFIG_CRASH_DUMP */
/*
* Return the maximum physical address for ZONE_DMA (DMA_BIT_MASK(32)). It
* currently assumes that for memory starting above 4G, 32-bit devices will
@@ -441,6 +493,8 @@ void __init arm64_memblock_init(void)
reserve_crashkernel();
+ reserve_elfcorehdr();
+
dma_contiguous_reserve(arm64_dma_phys_limit);
memblock_allow_resize();
--
2.11.0
^ permalink raw reply related
* [PATCH v29 7/9] arm64: kdump: enable kdump in defconfig
From: AKASHI Takahiro @ 2016-12-28 4:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161228043347.27358-1-takahiro.akashi@linaro.org>
Kdump is enabled by default as kexec is.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 869dded0f09f..5ce7cd00f4ea 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -79,6 +79,7 @@ CONFIG_CMA=y
CONFIG_SECCOMP=y
CONFIG_XEN=y
CONFIG_KEXEC=y
+CONFIG_CRASH_DUMP=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_COMPAT=y
CONFIG_CPU_IDLE=y
--
2.11.0
^ permalink raw reply related
* [PATCH v29 8/9] Documentation: kdump: describe arm64 port
From: AKASHI Takahiro @ 2016-12-28 4:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161228043347.27358-1-takahiro.akashi@linaro.org>
Add arch specific descriptions about kdump usage on arm64 to kdump.txt.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
Documentation/kdump/kdump.txt | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index b0eb27b956d9..615434d81108 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -18,7 +18,7 @@ memory image to a dump file on the local disk, or across the network to
a remote system.
Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64,
-s390x and arm architectures.
+s390x, arm and arm64 architectures.
When the system kernel boots, it reserves a small section of memory for
the dump-capture kernel. This ensures that ongoing Direct Memory Access
@@ -249,6 +249,13 @@ Dump-capture kernel config options (Arch Dependent, arm)
AUTO_ZRELADDR=y
+Dump-capture kernel config options (Arch Dependent, arm64)
+----------------------------------------------------------
+
+- Please note that kvm of the dump-capture kernel will not be enabled
+ on non-VHE systems even if it is configured. This is because the CPU
+ will not be reset to EL2 on panic.
+
Extended crashkernel syntax
===========================
@@ -305,6 +312,8 @@ Boot into System Kernel
kernel will automatically locate the crash kernel image within the
first 512MB of RAM if X is not given.
+ On arm64, use "crashkernel=Y[@X]". Note that the start address of
+ the kernel, X if explicitly specified, must be aligned to 2MiB (0x200000).
Load the Dump-capture Kernel
============================
@@ -327,6 +336,8 @@ For s390x:
- Use image or bzImage
For arm:
- Use zImage
+For arm64:
+ - Use vmlinux or Image
If you are using a uncompressed vmlinux image then use following command
to load dump-capture kernel.
@@ -370,6 +381,9 @@ For s390x:
For arm:
"1 maxcpus=1 reset_devices"
+For arm64:
+ "1 maxcpus=1 reset_devices"
+
Notes on loading the dump-capture kernel:
* By default, the ELF headers are stored in ELF64 format to support
--
2.11.0
^ permalink raw reply related
* [PATCH v29 9/9] Documentation: dt: chosen properties for arm64 kdump
From: AKASHI Takahiro @ 2016-12-28 4:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161228043347.27358-1-takahiro.akashi@linaro.org>
From: James Morse <james.morse@arm.com>
Add documentation for
linux,crashkernel-base and crashkernel-size,
linux,usable-memory-range
linux,elfcorehdr
used by arm64 kdump to decribe the kdump reserved area, and
the elfcorehdr's location within it.
Signed-off-by: James Morse <james.morse@arm.com>
[takahiro.akashi at linaro.org: added "linux,crashkernel-base" and "-size" ]
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: devicetree at vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
---
Documentation/devicetree/bindings/chosen.txt | 50 ++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 6ae9d82d4c37..7b115165e9ec 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -52,3 +52,53 @@ This property is set (currently only on PowerPC, and only needed on
book3e) by some versions of kexec-tools to tell the new kernel that it
is being booted by kexec, as the booting environment may differ (e.g.
a different secondary CPU release mechanism)
+
+linux,crashkernel-base
+linux,crashkernel-size
+----------------------
+
+These properties (currently used on PowerPC and arm64) indicates
+the base address and the size, respectively, of the reserved memory
+range for crash dump kernel.
+e.g.
+
+/ {
+ chosen {
+ linux,crashkernel-base = <0x9 0xf0000000>;
+ linux,crashkernel-size = <0x0 0x10000000>;
+ };
+};
+
+linux,usable-memory-range
+-------------------------
+
+This property (currently used only on arm64) holds the memory range,
+the base address and the size, which can be used as system ram on
+the *current* kernel. Note that, if this property is present, any memory
+regions under "memory" nodes in DT blob or ones marked as "conventional
+memory" in EFI memory map should be ignored.
+e.g.
+
+/ {
+ chosen {
+ linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>;
+ };
+};
+
+The main usage is for crash dump kernel to identify its own usable
+memory and exclude, at its boot time, any other memory areas that are
+part of the panicked kernel's memory.
+
+linux,elfcorehdr
+----------------
+
+This property (currently used only on arm64) holds the memory range,
+the address and the size, of the elf core header which mainly describes
+the panicked kernel's memory layout as PT_LOAD segments of elf format.
+e.g.
+
+/ {
+ chosen {
+ linux,elfcorehdr = <0x9 0xfffff000 0x0 0x800>;
+ };
+};
--
2.11.0
^ permalink raw reply related
* [PATCH] PCI: exynos: refactor exynos pcie driver
From: Jaehoon Chung @ 2016-12-28 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGcde9HTd7Gxc89ZaYW8z-pc91ps3kwHx3KsEpNRLcoHO9S-zw@mail.gmail.com>
Hi Pankaj,
On 12/28/2016 12:10 PM, Pankaj Dubey wrote:
> Hi Jaehoon,
>
> On 27 December 2016 at 15:48, Jaehoon Chung <jh80.chung@samsung.com> wrote:
>> Dear Alim,
>>
>> On 12/27/2016 03:34 PM, Alim Akhtar wrote:
>>> Hi Jaehoon,
>>>
>> [snip]
>>>>
>>>> Ah. Right..And i'm doing the refactoring to reuse the current pci-exynos.c.
>>> There is a nice refactoring patch posted by Pankaj recently @
>>> https://lkml.org/lkml/2016/12/23/73
>>> I would suggest you to rebase your work on this top.
>>
>> Well, i don't think so. Pankaj's patch might be good way..but i can't agree about a few point.
>> If based on Pankaj's patch, it's more complex..
>>
>> why put the ops callback for getting clock and mem resource?
>>
>
> I think I replied reason behind this in reply to Jingoo. Well I will
> explain with some example here. Current exynos_pcie struct contains
> all mem, phy, gpio and clock resources in one place and this driver is
> supported only for Exynos5440. Until this it was fine. As Jingoo
> mentioned when he up streamed this driver, generic phy framework was
> not ready so he used phy_base along with some additional phy related
> sfr base in pcie driver itself.
>
> Moving ahead for adding support for PCIe module on Exynos7, Exynos5433
> or other existing Exynos (non-mainlined) and some of upcoming SoC
> seeing the differences in these resources (mem, clk, regmap handles,
> gpio etc.) we will endup adding following kind of code in probe to get
> these resources from DT
>
> if (of_machine_is_compatible(exynos7420)) {
> /* get certain mem resources */
> /* get certain clock resources */
> /* get certain regmap handle resources if required */
> } else if (of_machine_is_compatble(exynos5433)) {
> /* get certain but may be different mem resources */
> /* get certain clock resources */
> /* get certain regmap handle resources if required */
> } else if (of_machine_is_compatible(exynosMMMM)) {
> //may be something else
> }
>
> for giving real example, exynos7420 does not uses only two clocks
> "bus", "pcie_bus" there are other clocks required to be taken care in
> driver. It also need to take care of pmu regmap handle and sysreg
> regmap handle.
>
> So if we keep exynos_pcie as only struct then we will keep adding all
> these resources in only one struct making it more complex. Also
> resource initialization part will become complex. For the same reason
> I decided to separate these rather keeping them in single struct. This
> is very obvious design used in many drivers (samsung or other
> vendors). Just to give one more example see pcie-qcom.c where they
> also have different clocks and it is managed in same fashion.
>
>> If PHY generic framework is used, it's unnecessary. because it needs to get elbi and dbi resources.
>
> Surely elbi and dbi are fixed, but as we already have one example of
> exynos5440 which used block_base (additional SFR base other than phy
> base), I can see some of existing and upcoming SoC will need more SFR
> base than these two, it all depends on how h/w engineers design these
> modules and distribute SFR access.
>
>> clock resources("pcie" and "pcie_bus") are general things.
>>
>
> With current Exynos SoCs which have PCIe hardware modules I can see
> this will not remain uniform across various SoCs, some of them require
> more clocks to be handled by PCIe driver.
>
>> If Pankaj's patch is applied, also need to make the exynos5433_pcie_* callback functions?
>> It doesn't make sense.
>>
>
> Adding exynos5433_pcie_ops struct and hooks specific to the exynos5433
> is a small overhead compared to the flexibility it provides. This will
> make current driver flexibility with less
> of_machine_is_compatible(...) kind of conditional statement, less
> complex exynos_pcie struct.
> For the hooks of exynos_pcie_ops also if two different Exynos SoC
> shares same mem, clock and other resources the actual hooks will point
> to same functions so no overhead of implementing these for each SoC.
> Only separate implementation will be required if they differ in these
> resources. This approach also very common across various drivers
> nothing special here.
>
> I hope I am clear in explaining the intention and pros and cons of
> both approaches.
Yep, clear..Well, My opinion is also my preference.
(Maybe i think that you also know a little what my meaning is. )
There is no objection that we want to support the other Exynos variants. :)
This discussion is for how to support better than now.
So I will send the patch based on your patch...then we can discuss more. how about?
I think we can maintain more better than now.
As you already know, current exynos-pcie has to modify for supporting other.
>
>> I want to know maintainer's opinion..we can just touch a little for supporting All Exynos SoCs.
>>
>
> I also have same intention but design should be flexible to adopt
> future SoC at least some of them which we are seeing will be supported
> soon and we can see the differences.
Sure, I will wait for your patch.
And You can also check my patches.. :)
Best Regards,
Jaehoon Chung
>
> Thanks,
> Pankaj Dubey
>
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>>> Maybe..Today or Tomorrow..I will send the patches..At that time, could you also check them?
>>>> Any comments might be helpful to me! :)
>>>>
>>> Will wait for you patches :-)
>>>
>>>> Best Regards,
>>>> Jaehoon Chung
>>>>
>> [snip]
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* [PATCH 0/3] Add clock and power domain DT nodes for Mediatek MT2701
From: James Liao @ 2016-12-28 5:46 UTC (permalink / raw)
To: linux-arm-kernel
This patch series base on v4.10-rc1, include MT2701 power domain and clock
DT nodes.
An early patch [1] which was not applied in v4.10-rc1 also included in this
patch series.
[1] https://patchwork.kernel.org/patch/9457625/
James Liao (3):
arm: dts: mt2701: Sort DT nodes by register address
arm: dts: mt2701: Add subsystem clock controller device nodes
arm: dts: mt2701: Add power domain controller device node
arch/arm/boot/dts/mt2701.dtsi | 84 +++++++++++++++++++++++++++++++++----------
1 file changed, 66 insertions(+), 18 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/3] arm: dts: mt2701: Sort DT nodes by register address
From: James Liao @ 2016-12-28 5:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482904006-44232-1-git-send-email-jamesjj.liao@mediatek.com>
This patch rearrange MT2701 DT nodes to keep them in ascending order.
Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
---
arch/arm/boot/dts/mt2701.dtsi | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 7eab6f4..73f4b7c 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -96,24 +96,6 @@
<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
- pio: pinctrl at 10005000 {
- compatible = "mediatek,mt2701-pinctrl";
- reg = <0 0x1000b000 0 0x1000>;
- mediatek,pctl-regmap = <&syscfg_pctl_a>;
- pins-are-numbered;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- syscfg_pctl_a: syscfg at 10005000 {
- compatible = "mediatek,mt2701-pctl-a-syscfg", "syscon";
- reg = <0 0x10005000 0 0x1000>;
- };
-
topckgen: syscon at 10000000 {
compatible = "mediatek,mt2701-topckgen", "syscon";
reg = <0 0x10000000 0 0x1000>;
@@ -134,6 +116,24 @@
#reset-cells = <1>;
};
+ pio: pinctrl at 10005000 {
+ compatible = "mediatek,mt2701-pinctrl";
+ reg = <0 0x1000b000 0 0x1000>;
+ mediatek,pctl-regmap = <&syscfg_pctl_a>;
+ pins-are-numbered;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ syscfg_pctl_a: syscfg at 10005000 {
+ compatible = "mediatek,mt2701-pctl-a-syscfg", "syscon";
+ reg = <0 0x10005000 0 0x1000>;
+ };
+
watchdog: watchdog at 10007000 {
compatible = "mediatek,mt2701-wdt",
"mediatek,mt6589-wdt";
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] arm: dts: mt2701: Add subsystem clock controller device nodes
From: James Liao @ 2016-12-28 5:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482904006-44232-1-git-send-email-jamesjj.liao@mediatek.com>
Add MT2701 subsystem clock controllers, inlcude mmsys, imgsys,
vdecsys, hifsys, ethsys and bdpsys.
Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
---
arch/arm/boot/dts/mt2701.dtsi | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 73f4b7c..150c48d 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -214,4 +214,40 @@
clock-names = "baud", "bus";
status = "disabled";
};
+
+ mmsys: syscon at 14000000 {
+ compatible = "mediatek,mt2701-mmsys", "syscon";
+ reg = <0 0x14000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ imgsys: syscon at 15000000 {
+ compatible = "mediatek,mt2701-imgsys", "syscon";
+ reg = <0 0x15000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ vdecsys: syscon at 16000000 {
+ compatible = "mediatek,mt2701-vdecsys", "syscon";
+ reg = <0 0x16000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ hifsys: syscon at 1a000000 {
+ compatible = "mediatek,mt2701-hifsys", "syscon";
+ reg = <0 0x1a000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ ethsys: syscon at 1b000000 {
+ compatible = "mediatek,mt2701-ethsys", "syscon";
+ reg = <0 0x1b000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ bdpsys: syscon at 1c000000 {
+ compatible = "mediatek,mt2701-bdpsys", "syscon";
+ reg = <0 0x1c000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
};
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] arm: dts: mt2701: Add power domain controller device node
From: James Liao @ 2016-12-28 5:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482904006-44232-1-git-send-email-jamesjj.liao@mediatek.com>
Add power domain controller node (scpsys) for MT2701.
Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
---
arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 150c48d..bdf8954 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -13,6 +13,7 @@
*/
#include <dt-bindings/clock/mt2701-clk.h>
+#include <dt-bindings/power/mt2701-power.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset/mt2701-resets.h>
@@ -134,6 +135,17 @@
reg = <0 0x10005000 0 0x1000>;
};
+ scpsys: scpsys at 10006000 {
+ compatible = "mediatek,mt2701-scpsys", "syscon";
+ #power-domain-cells = <1>;
+ reg = <0 0x10006000 0 0x1000>;
+ infracfg = <&infracfg>;
+ clocks = <&topckgen CLK_TOP_MM_SEL>,
+ <&topckgen CLK_TOP_MFG_SEL>,
+ <&topckgen CLK_TOP_ETHIF_SEL>;
+ clock-names = "mm", "mfg", "ethif";
+ };
+
watchdog: watchdog at 10007000 {
compatible = "mediatek,mt2701-wdt",
"mediatek,mt6589-wdt";
--
1.9.1
^ permalink raw reply related
* [PATCH] arm64: Do not include linux/uaccess.h from assembler files
From: Thomas Petazzoni @ 2016-12-28 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482748268-10399-1-git-send-email-linux@roeck-us.net>
Hello,
On Mon, 26 Dec 2016 02:31:08 -0800, Guenter Roeck wrote:
> Including linux/uaccess.h from assembler files in arm64 builds results
> in the following build errors.
>
> In file included from arm64/include/asm/asm-offsets.h:1:0,
> from arch/arm64/include/asm/assembler.h:26,
> from arch/arm64/include/asm/alternative.h:68,
> from arch/arm64/kernel/entry.S
>
> include/linux/sched/prio.h: Assembler messages:
> include/linux/sched/prio.h:47: Error:
> unknown mnemonic `static' --
> `static inline long nice_to_rlimit(long nice)'
> build/include/linux/sched/prio.h:48: Error:
> junk at end of line, first unrecognized character is `{'
>
> [and many more]
>
> If asm/uaccess.h is not included, many of the affected files fail to build
> with errors such as the following.
>
> arch/arm64/lib/copy_to_user.S: Assembler messages:
> arch/arm64/lib/copy_to_user.S:66: Error:
> unknown mnemonic `uaccess_enable_not_uao' --
> `uaccess_enable_not_uao x3,x4'
> arch/arm64/lib/copy_template.S:71: Error:
> unknown mnemonic `uao_user_alternative' --
> `uao_user_alternative 9998f,strb,st trb,tmp1w,dst,#1'
>
> Either drop the include if unnecessary or, if needed, replace with
> asm/uaccess.h.
>
> Fixes: 7c0f6ba682b9 ("Replace <asm/uaccess.h> with <linux/uaccess.h> globally")
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(fixes the arm64 build, result boot tested on real HW)
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2016-12-28 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481720175-12703-1-git-send-email-andrei.pistirica@microchip.com>
On Wed, Dec 14, 2016 at 02:56:14PM +0200, Andrei Pistirica wrote:
> Note 1: Kbuild uses "select" instead of "imply", and the macb maintainer agreed
> to make the change when it will be available in net-next.
> +config MACB_USE_HWSTAMP
> + bool "Use IEEE 1588 hwstamp"
> + depends on MACB
> + default y
> + select PTP_1588_CLOCK
The imply key word has been merged as of:
237e3ad Kconfig: Introduce the "imply" keyword
Please use it.
Thanks,
Richard
> + ---help---
> + Enable IEEE 1588 Precision Time Protocol (PTP) support for MACB.
^ permalink raw reply
* [PATCH] thermal: mtk_thermal: Staticise a number of data variables
From: Vivek Gautam @ 2016-12-28 8:46 UTC (permalink / raw)
To: linux-arm-kernel
Sparse throws following warnings:
drivers/thermal/mtk_thermal.c:186:11: warning: symbol 'mt8173_bank_data' was not declared. Should it be static?
drivers/thermal/mtk_thermal.c:193:11: warning: symbol 'mt8173_msr' was not declared. Should it be static?
drivers/thermal/mtk_thermal.c:197:11: warning: symbol 'mt8173_adcpnp' was not declared. Should it be static?
drivers/thermal/mtk_thermal.c:201:11: warning: symbol 'mt8173_mux_values' was not declared. Should it be static?
drivers/thermal/mtk_thermal.c:204:11: warning: symbol 'mt2701_bank_data' was not declared. Should it be static?
drivers/thermal/mtk_thermal.c:208:11: warning: symbol 'mt2701_msr' was not declared. Should it be static?
drivers/thermal/mtk_thermal.c:212:11: warning: symbol 'mt2701_adcpnp' was not declared. Should it be static?
drivers/thermal/mtk_thermal.c:216:11: warning: symbol 'mt2701_mux_values' was not declared. Should it be static?
Make these variables as static to fix these warnings.
Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
---
Based on Torvald's master branch. Build tested.
drivers/thermal/mtk_thermal.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index 34169c32d495..1aff7fde54b1 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -183,37 +183,37 @@ struct mtk_thermal {
};
/* MT8173 thermal sensor data */
-const int mt8173_bank_data[MT8173_NUM_ZONES][3] = {
+static const int mt8173_bank_data[MT8173_NUM_ZONES][3] = {
{ MT8173_TS2, MT8173_TS3 },
{ MT8173_TS2, MT8173_TS4 },
{ MT8173_TS1, MT8173_TS2, MT8173_TSABB },
{ MT8173_TS2 },
};
-const int mt8173_msr[MT8173_NUM_SENSORS_PER_ZONE] = {
+static const int mt8173_msr[MT8173_NUM_SENSORS_PER_ZONE] = {
TEMP_MSR0, TEMP_MSR1, TEMP_MSR2, TEMP_MSR2
};
-const int mt8173_adcpnp[MT8173_NUM_SENSORS_PER_ZONE] = {
+static const int mt8173_adcpnp[MT8173_NUM_SENSORS_PER_ZONE] = {
TEMP_ADCPNP0, TEMP_ADCPNP1, TEMP_ADCPNP2, TEMP_ADCPNP3
};
-const int mt8173_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
+static const int mt8173_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
/* MT2701 thermal sensor data */
-const int mt2701_bank_data[MT2701_NUM_SENSORS] = {
+static const int mt2701_bank_data[MT2701_NUM_SENSORS] = {
MT2701_TS1, MT2701_TS2, MT2701_TSABB
};
-const int mt2701_msr[MT2701_NUM_SENSORS_PER_ZONE] = {
+static const int mt2701_msr[MT2701_NUM_SENSORS_PER_ZONE] = {
TEMP_MSR0, TEMP_MSR1, TEMP_MSR2
};
-const int mt2701_adcpnp[MT2701_NUM_SENSORS_PER_ZONE] = {
+static const int mt2701_adcpnp[MT2701_NUM_SENSORS_PER_ZONE] = {
TEMP_ADCPNP0, TEMP_ADCPNP1, TEMP_ADCPNP2
};
-const int mt2701_mux_values[MT2701_NUM_SENSORS] = { 0, 1, 16 };
+static const int mt2701_mux_values[MT2701_NUM_SENSORS] = { 0, 1, 16 };
/**
* The MT8173 thermal controller has four banks. Each bank can read up to
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
From: Herbert Xu @ 2016-12-28 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6124F827-BA28-4A3D-B05F-EBCB1323955D@linaro.org>
On Tue, Dec 27, 2016 at 02:26:35PM +0000, Ard Biesheuvel wrote:
>
> You just nacked the v2 of this series (due to the chunksize/walksize) and i rewrote them as skciphers as well
Sorry. Would you like me to revert or just send a new series
on top of this?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
From: Herbert Xu @ 2016-12-28 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8OkOR3Xzx=XEOWyFpo6sLiq=WQrq0SauaY0V57uYetCQ@mail.gmail.com>
On Tue, Dec 27, 2016 at 06:35:46PM +0000, Ard Biesheuvel wrote:
>
> OK, I will try to hack something up.
>
> One thing to keep in mind though is that stacked chaining modes should
> present the data with the same granularity for optimal performance.
> E.g., xts(ecb(aes)) should pass 8 blocks at a time. How should this
> requirement be incorporated according to you?
xts tries to do a page at a time, which should be good enough, no?
In general this parameter should be visible to internal API users
such as xts so they could use it to determine how it wants to
structure its walks.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
From: Ard Biesheuvel @ 2016-12-28 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161228090350.GD11904@gondor.apana.org.au>
> On 28 Dec 2016, at 09:03, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
>> On Tue, Dec 27, 2016 at 02:26:35PM +0000, Ard Biesheuvel wrote:
>>
>> You just nacked the v2 of this series (due to the chunksize/walksize) and i rewrote them as skciphers as well
>
> Sorry. Would you like me to revert or just send a new series
> on top of this?
>
No worries. If you can, please drop them entirely, or revert them otherwise. I will resend after the holidays
> Thanks,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
From: Herbert Xu @ 2016-12-28 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AA6F25FA-C998-462F-9E25-FF543BBE3EA7@linaro.org>
On Wed, Dec 28, 2016 at 09:11:03AM +0000, Ard Biesheuvel wrote:
>
> > On 28 Dec 2016, at 09:03, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> >
> >> On Tue, Dec 27, 2016 at 02:26:35PM +0000, Ard Biesheuvel wrote:
> >>
> >> You just nacked the v2 of this series (due to the chunksize/walksize) and i rewrote them as skciphers as well
> >
> > Sorry. Would you like me to revert or just send a new series
> > on top of this?
> >
>
> No worries. If you can, please drop them entirely, or revert them otherwise. I will resend after the holidays
OK I will revert. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2 1/3] crypto: chacha20 - convert generic and x86 versions to skcipher
From: Herbert Xu @ 2016-12-28 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161227100452.GB10629@gondor.apana.org.au>
On Tue, Dec 27, 2016 at 06:04:52PM +0800, Herbert Xu wrote:
> On Fri, Dec 09, 2016 at 02:33:51PM +0000, Ard Biesheuvel wrote:
> > This converts the ChaCha20 code from a blkcipher to a skcipher, which
> > is now the preferred way to implement symmetric block and stream ciphers.
> >
> > This ports the generic and x86 versions at the same time because the
> > latter reuses routines of the former.
> >
> > Note that the skcipher_walk() API guarantees that all presented blocks
> > except the final one are a multiple of the chunk size, so we can simplify
> > the encrypt() routine somewhat.
> >
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> Patch applied. Thanks.
I'm reverting this patch because it breaks the build on ARM without
the two subsequent patches.
When resubmitting please make sure that the kernel can build and
work after each patch. Otherwise git bisections will fail.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
From: Ard Biesheuvel @ 2016-12-28 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161228091020.GE11904@gondor.apana.org.au>
> On 28 Dec 2016, at 09:10, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
>> On Tue, Dec 27, 2016 at 06:35:46PM +0000, Ard Biesheuvel wrote:
>>
>> OK, I will try to hack something up.
>>
>> One thing to keep in mind though is that stacked chaining modes should
>> present the data with the same granularity for optimal performance.
>> E.g., xts(ecb(aes)) should pass 8 blocks at a time. How should this
>> requirement be incorporated according to you?
>
> xts tries to do a page at a time, which should be good enough, no?
>
Yes, if the xts chaining mode driver invokes the ecb transform with that granularity, it should be fine. Note that this is a theoretical
concern for this mode in particular, given that the bit sliced aes code implements the xts bits as well
> In general this parameter should be visible to internal API users
> such as xts so they could use it to determine how it wants to
> structure its walks.
>
Ok, so that implies a field in the skcipher algo struct then, rather than some definition internal to the driver?
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2 1/3] crypto: chacha20 - convert generic and x86 versions to skcipher
From: Herbert Xu @ 2016-12-28 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161228091801.GA12318@gondor.apana.org.au>
On Wed, Dec 28, 2016 at 05:18:01PM +0800, Herbert Xu wrote:
> On Tue, Dec 27, 2016 at 06:04:52PM +0800, Herbert Xu wrote:
> > On Fri, Dec 09, 2016 at 02:33:51PM +0000, Ard Biesheuvel wrote:
> > > This converts the ChaCha20 code from a blkcipher to a skcipher, which
> > > is now the preferred way to implement symmetric block and stream ciphers.
> > >
> > > This ports the generic and x86 versions at the same time because the
> > > latter reuses routines of the former.
> > >
> > > Note that the skcipher_walk() API guarantees that all presented blocks
> > > except the final one are a multiple of the chunk size, so we can simplify
> > > the encrypt() routine somewhat.
> > >
> > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >
> > Patch applied. Thanks.
>
> I'm reverting this patch because it breaks the build on ARM without
> the two subsequent patches.
>
> When resubmitting please make sure that the kernel can build and
> work after each patch. Otherwise git bisections will fail.
Sorry, it only broke the build because I applied your other two
patches first.
So I'll just revert all three and it should work.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2 1/3] crypto: chacha20 - convert generic and x86 versions to skcipher
From: Ard Biesheuvel @ 2016-12-28 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161228091801.GA12318@gondor.apana.org.au>
> On 28 Dec 2016, at 09:18, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
>> On Tue, Dec 27, 2016 at 06:04:52PM +0800, Herbert Xu wrote:
>>> On Fri, Dec 09, 2016 at 02:33:51PM +0000, Ard Biesheuvel wrote:
>>> This converts the ChaCha20 code from a blkcipher to a skcipher, which
>>> is now the preferred way to implement symmetric block and stream ciphers.
>>>
>>> This ports the generic and x86 versions at the same time because the
>>> latter reuses routines of the former.
>>>
>>> Note that the skcipher_walk() API guarantees that all presented blocks
>>> except the final one are a multiple of the chunk size, so we can simplify
>>> the encrypt() routine somewhat.
>>>
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>
>> Patch applied. Thanks.
>
> I'm reverting this patch because it breaks the build on ARM without
> the two subsequent patches.
>
> When resubmitting please make sure that the kernel can build and
> work after each patch. Otherwise git bisections will fail.
>
Ehm, could you keep this one and revert the other two instead please? This patch will not change in the respin, and the other two are blkciphers rather than skciphers (and in the arm64 version, I optimized the asm code as well) so they will look rather different ( as they do in the nacked v2)
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
From: Herbert Xu @ 2016-12-28 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B32240B5-953F-42A2-A010-6FF64AC45859@linaro.org>
On Wed, Dec 28, 2016 at 09:19:32AM +0000, Ard Biesheuvel wrote:
>
> Ok, so that implies a field in the skcipher algo struct then, rather than some definition internal to the driver?
Oh yes it should definitely be visible to other crypto API drivers
and algorithms. It's just that we don't want to export it outside
of the crypto API, e.g., to IPsec or algif.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2 1/3] crypto: chacha20 - convert generic and x86 versions to skcipher
From: Herbert Xu @ 2016-12-28 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C46A3CDE-2329-4171-B4C5-071423EC3B4B@linaro.org>
On Wed, Dec 28, 2016 at 09:23:07AM +0000, Ard Biesheuvel wrote:
>
> Ehm, could you keep this one and revert the other two instead please? This patch will not change in the respin, and the other two are blkciphers rather than skciphers (and in the arm64 version, I optimized the asm code as well) so they will look rather different ( as they do in the nacked v2)
OK I will keep this patch and revert the other two.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] pinctrl: meson: fix gpio request disabling other modes
From: Linus Walleij @ 2016-12-28 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206140817.11708-1-narmstrong@baylibre.com>
On Tue, Dec 6, 2016 at 3:08 PM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> The pinctrl_gpio_request is called with the "full" gpio number, already
> containing the base, then meson_pmx_request_gpio is then called with the
> final pin number.
> Remove the base addition when calling meson_pmx_disable_other_groups.
>
> Fixes: 6ac730951104 ("pinctrl: add driver for Amlogic Meson SoCs")
> CC: Beniamino Galvani <b.galvani@gmail.com>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Patch applied for fixes. Sorry for the delay, merge window appeared inbetween.
Yours,
Linus Walleij
^ permalink raw reply
* [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Rafal Ozieblo @ 2016-12-28 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481720175-12703-1-git-send-email-andrei.pistirica@microchip.com>
> From: Andrei Pistirica [mailto:andrei.pistirica at microchip.com]
> Sent: 14 grudnia 2016 13:56
> Subject: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
>
> Cadence GEM provides a 102 bit time counter with 48 bits for seconds,
> 30 bits for nsecs and 24 bits for sub-nsecs to control 1588 timestamping.
>
> This patch does the following:
> - Registers to ptp clock framework
> - Timer initialization is done by writing time of day to the timer counter.
> - ns increment register is programmed as NSEC_PER_SEC/tsu-clock-rate.
> For a 16 bit subns precision, the subns increment equals
> remainder of (NS_PER_SEC/TSU_CLK) * (2^16).
> - Timestamps are obtained from the TX/RX PTP event/PEER registers.
> The timestamp obtained thus is updated in skb for upper layers to access.
> - The drivers register functions with ptp to perform time and frequency
> adjustment.
> - Time adjustment is done by writing to the 1558_ADJUST register.
> The controller will read the delta in this register and update the timer
> counter register. Alternatively, for large time offset adjustments,
> the driver reads the secs and nsecs counter values, adds/subtracts the
> delta and updates the timer counter.
> - Frequency is adjusted by adjusting addend (8bit nanosecond increment) and
> addendsub (16bit increment nanosecond fractions).
> The 102bit counter is incremented at nominal frequency with addend and
> addendsub values. Each period addend and addendsub values are adjusted
> based on ppm drift.
>
> Signed-off-by: Andrei Pistirica <andrei.pistirica@microchip.com>
> Signed-off-by: Harini Katakam <harinik@xilinx.com>
> ---
> Patch history:
>
> Version 1:
> This patch is based on original Harini's patch, implemented in a separate file to ease the review/maintanance and integration with other platforms (e.g. Zynq Ultrascale+ MPSoC).
> Feature was tested on SAMA5D2 platform using ptp4l v1.6 from linuxptp project and also with ptpd2 version 2.3.1. PTP was tested over
> IPv4,IPv6 and 802.3 protocols.
>
> In case that macb is compiled as a module, it has been renamed to cadence-macb.ko to avoid naming confusion in Makefile.
>
> Version 2 modifications:
> - bitfields for TSU are named according to SAMA5D2 data sheet
> - identify GEM-PTP support based on platform capability
> - add spinlock for TSU access
> - change macb_ptp_adjfreq and use fewer 64bit divisions
>
> Version 3 modifications:
> - new adjfine api with one 64 division for frequency adjustment
> (based on Richard's input)
> - add maximum adjustment frequency (ppb) based on nominal frequency
> - per platform PTP configuration
> - cosmetic changes
> Note 1: Kbuild uses "select" instead of "imply", and the macb maintainer agreed
> to make the change when it will be available in net-next.
>
> Version 4 modifications:
> - update adjfine for a better approximation
> - add maximum adjustment frequency callback to PTP platform configuraion
>
> Note 1: This driver does not support GEM-GXL!
> Note 2: Patch on net-next, on December 14th.
>
> drivers/net/ethernet/cadence/Kconfig | 10 +-
> drivers/net/ethernet/cadence/Makefile | 8 +-
> drivers/net/ethernet/cadence/macb.h | 118 ++++++++++
> drivers/net/ethernet/cadence/macb_ptp.c | 366 ++++++++++++++++++++++++++++++++
> 4 files changed, 500 insertions(+), 2 deletions(-) create mode 100644 drivers/net/ethernet/cadence/macb_ptp.c
>
> diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
> index f0bcb15..ebbc65f 100644
> --- a/drivers/net/ethernet/cadence/Kconfig
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -29,6 +29,14 @@ config MACB
> support for the MACB/GEM chip.
>
> To compile this driver as a module, choose M here: the module
> - will be called macb.
> + will be called cadence-macb.
> +
> +config MACB_USE_HWSTAMP
> + bool "Use IEEE 1588 hwstamp"
> + depends on MACB
> + default y
> + select PTP_1588_CLOCK
> + ---help---
> + Enable IEEE 1588 Precision Time Protocol (PTP) support for MACB.
>
> endif # NET_CADENCE
> diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile
> index 91f79b1..4402d42 100644
> --- a/drivers/net/ethernet/cadence/Makefile
> +++ b/drivers/net/ethernet/cadence/Makefile
> @@ -2,4 +2,10 @@
> # Makefile for the Atmel network device drivers.
> #
>
> -obj-$(CONFIG_MACB) += macb.o
> +cadence-macb-y := macb.o
> +
> +ifeq ($(CONFIG_MACB_USE_HWSTAMP),y)
> +cadence-macb-y += macb_ptp.o
> +endif
> +
> +obj-$(CONFIG_MACB) += cadence-macb.o
> diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
> index d67adad..e65e985 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -10,6 +10,9 @@
> #ifndef _MACB_H
> #define _MACB_H
>
> +#include <linux/ptp_clock.h>
> +#include <linux/ptp_clock_kernel.h>
> +
> #define MACB_GREGS_NBR 16
> #define MACB_GREGS_VERSION 2
> #define MACB_MAX_QUEUES 8
> @@ -131,6 +134,20 @@
> #define GEM_RXIPCCNT 0x01a8 /* IP header Checksum Error Counter */
> #define GEM_RXTCPCCNT 0x01ac /* TCP Checksum Error Counter */
> #define GEM_RXUDPCCNT 0x01b0 /* UDP Checksum Error Counter */
> +#define GEM_TISUBN 0x01bc /* 1588 Timer Increment Sub-ns */
> +#define GEM_TSH 0x01c0 /* 1588 Timer Seconds High */
> +#define GEM_TSL 0x01d0 /* 1588 Timer Seconds Low */
> +#define GEM_TN 0x01d4 /* 1588 Timer Nanoseconds */
> +#define GEM_TA 0x01d8 /* 1588 Timer Adjust */
> +#define GEM_TI 0x01dc /* 1588 Timer Increment */
> +#define GEM_EFTSL 0x01e0 /* PTP Event Frame Tx Seconds Low */
> +#define GEM_EFTN 0x01e4 /* PTP Event Frame Tx Nanoseconds */
> +#define GEM_EFRSL 0x01e8 /* PTP Event Frame Rx Seconds Low */
> +#define GEM_EFRN 0x01ec /* PTP Event Frame Rx Nanoseconds */
> +#define GEM_PEFTSL 0x01f0 /* PTP Peer Event Frame Tx Secs Low */
> +#define GEM_PEFTN 0x01f4 /* PTP Peer Event Frame Tx Ns */
> +#define GEM_PEFRSL 0x01f8 /* PTP Peer Event Frame Rx Sec Low */
> +#define GEM_PEFRN 0x01fc /* PTP Peer Event Frame Rx Ns */
> #define GEM_DCFG1 0x0280 /* Design Config 1 */
> #define GEM_DCFG2 0x0284 /* Design Config 2 */
> #define GEM_DCFG3 0x0288 /* Design Config 3 */
> @@ -174,6 +191,7 @@
> #define MACB_NCR_TPF_SIZE 1
> #define MACB_TZQ_OFFSET 12 /* Transmit zero quantum pause frame */
> #define MACB_TZQ_SIZE 1
> +#define MACB_SRTSM_OFFSET 15
>
> /* Bitfields in NCFGR */
> #define MACB_SPD_OFFSET 0 /* Speed */
> @@ -319,6 +337,32 @@
> #define MACB_PTZ_SIZE 1
> #define MACB_WOL_OFFSET 14 /* Enable wake-on-lan interrupt */
> #define MACB_WOL_SIZE 1
> +#define MACB_DRQFR_OFFSET 18 /* PTP Delay Request Frame Received */
> +#define MACB_DRQFR_SIZE 1
> +#define MACB_SFR_OFFSET 19 /* PTP Sync Frame Received */
> +#define MACB_SFR_SIZE 1
> +#define MACB_DRQFT_OFFSET 20 /* PTP Delay Request Frame Transmitted */
> +#define MACB_DRQFT_SIZE 1
> +#define MACB_SFT_OFFSET 21 /* PTP Sync Frame Transmitted */
> +#define MACB_SFT_SIZE 1
> +#define MACB_PDRQFR_OFFSET 22 /* PDelay Request Frame Received */
> +#define MACB_PDRQFR_SIZE 1
> +#define MACB_PDRSFR_OFFSET 23 /* PDelay Response Frame Received */
> +#define MACB_PDRSFR_SIZE 1
> +#define MACB_PDRQFT_OFFSET 24 /* PDelay Request Frame Transmitted */
> +#define MACB_PDRQFT_SIZE 1
> +#define MACB_PDRSFT_OFFSET 25 /* PDelay Response Frame Transmitted */
> +#define MACB_PDRSFT_SIZE 1
> +#define MACB_SRI_OFFSET 26 /* TSU Seconds Register Increment */
> +#define MACB_SRI_SIZE 1
> +
> +/* Timer increment fields */
> +#define MACB_TI_CNS_OFFSET 0
> +#define MACB_TI_CNS_SIZE 8
> +#define MACB_TI_ACNS_OFFSET 8
> +#define MACB_TI_ACNS_SIZE 8
> +#define MACB_TI_NIT_OFFSET 16
> +#define MACB_TI_NIT_SIZE 8
>
> /* Bitfields in MAN */
> #define MACB_DATA_OFFSET 0 /* data */
> @@ -386,6 +430,17 @@
> #define GEM_PBUF_LSO_OFFSET 27
> #define GEM_PBUF_LSO_SIZE 1
>
> +/* Bitfields in TISUBN */
> +#define GEM_SUBNSINCR_OFFSET 0
> +#define GEM_SUBNSINCR_SIZE 16
> +
> +/* Bitfields in TI */
> +#define GEM_NSINCR_OFFSET 0
> +#define GEM_NSINCR_SIZE 8
> +
> +/* Bitfields in ADJ */
> +#define GEM_ADDSUB_OFFSET 31
> +#define GEM_ADDSUB_SIZE 1
> /* Constants for CLK */
> #define MACB_CLK_DIV8 0
> #define MACB_CLK_DIV16 1
> @@ -417,6 +472,7 @@
> #define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x20000000
> #define MACB_CAPS_SG_DISABLED 0x40000000
> #define MACB_CAPS_MACB_IS_GEM 0x80000000
> +#define MACB_CAPS_GEM_HAS_PTP 0x00000020
>
> /* LSO settings */
> #define MACB_LSO_UFO_ENABLE 0x01
> @@ -782,6 +838,20 @@ struct macb_or_gem_ops {
> int (*mog_rx)(struct macb *bp, int budget);
> };
>
> +/* MACB-PTP interface: adapt to platform needs and GEM (e.g. GXL). */
> +struct macb_ptp_info {
> + void (*ptp_init)(struct net_device *ndev);
> + void (*ptp_remove)(struct net_device *ndev);
> + s32 (*get_ptp_max_adj)(void);
> + unsigned int (*get_tsu_rate)(struct macb *bp);
> + int (*get_ts_info)(struct net_device *dev,
> + struct ethtool_ts_info *info);
> + int (*get_hwtst)(struct net_device *netdev,
> + struct ifreq *ifr);
> + int (*set_hwtst)(struct net_device *netdev,
> + struct ifreq *ifr, int cmd);
> +};
> +
> struct macb_config {
> u32 caps;
> unsigned int dma_burst_length;
> @@ -874,11 +944,59 @@ struct macb {
> unsigned int jumbo_max_len;
>
> u32 wol;
> +
> + struct macb_ptp_info *ptp_info;
> +#ifdef CONFIG_MACB_USE_HWSTAMP
> + bool hwts_tx_en;
> + bool hwts_rx_en;
> + spinlock_t tsu_clk_lock; /* gem tsu clock locking */
> + unsigned int tsu_rate;
> +
> + struct ptp_clock *ptp_clock;
> + struct ptp_clock_info ptp_caps;
> + u32 ns_incr;
> + u32 subns_incr;
> +#endif
> };
>
> +#ifdef CONFIG_MACB_USE_HWSTAMP
> +void gem_ptp_init(struct net_device *ndev); void gem_ptp_remove(struct
> +net_device *ndev); void gem_ptp_txstamp(struct macb *bp, struct sk_buff
> +*skb); void gem_ptp_rxstamp(struct macb *bp, struct sk_buff *skb);
> +
> +static inline void gem_ptp_do_txstamp(struct macb *bp, struct sk_buff
> +*skb) {
> + if (!bp->hwts_tx_en)
> + return;
> +
> + return gem_ptp_txstamp(bp, skb);
> +}
> +
> +static inline void gem_ptp_do_rxstamp(struct macb *bp, struct sk_buff
> +*skb) {
> + if (!bp->hwts_rx_en)
> + return;
> +
> + return gem_ptp_rxstamp(bp, skb);
> +}
> +
> +#else
> +static inline void gem_ptp_init(struct net_device *ndev) { } static
> +inline void gem_ptp_remove(struct net_device *ndev) { }
> +
> +static inline void gem_ptp_do_txstamp(struct macb *bp, struct sk_buff
> +*skb) { } static inline void gem_ptp_do_rxstamp(struct macb *bp, struct
> +sk_buff *skb) { } #endif
> +
> static inline bool macb_is_gem(struct macb *bp) {
> return !!(bp->caps & MACB_CAPS_MACB_IS_GEM); }
>
> +static inline bool gem_has_ptp(struct macb *bp) {
> + return !!(bp->caps & MACB_CAPS_GEM_HAS_PTP); }
> +
> #endif /* _MACB_H */
> diff --git a/drivers/net/ethernet/cadence/macb_ptp.c b/drivers/net/ethernet/cadence/macb_ptp.c
> new file mode 100644
> index 0000000..6121b2a
> --- /dev/null
> +++ b/drivers/net/ethernet/cadence/macb_ptp.c
> @@ -0,0 +1,366 @@
> +/*
> + * 1588 PTP support for GEM device.
> + *
> + * Copyright (C) 2016 Microchip Technology
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/device.h>
> +#include <linux/etherdevice.h>
> +#include <linux/platform_device.h>
> +#include <linux/time64.h>
> +#include <linux/ptp_classify.h>
> +#include <linux/if_ether.h>
> +#include <linux/if_vlan.h>
> +#include <linux/net_tstamp.h>
> +
> +#include "macb.h"
> +
> +#define GEM_PTP_TIMER_NAME "gem-ptp-timer"
> +
> +static inline void gem_tsu_get_time(struct macb *bp,
> + struct timespec64 *ts)
> +{
> + u64 sec, sech, secl;
> +
> + spin_lock(&bp->tsu_clk_lock);
> +
> + /* GEM's internal time */
> + sech = gem_readl(bp, TSH);
> + secl = gem_readl(bp, TSL);
> + ts->tv_nsec = gem_readl(bp, TN);
> + ts->tv_sec = (sech << 32) | secl;
> +
> + /* minimize error */
> + sech = gem_readl(bp, TSH);
> + secl = gem_readl(bp, TSL);
> + sec = (sech << 32) | secl;
> + if (ts->tv_sec != sec) {
> + ts->tv_sec = sec;
> + ts->tv_nsec = gem_readl(bp, TN);
> + }
> +
> + spin_unlock(&bp->tsu_clk_lock);
> +}
> +
> +static inline void gem_tsu_set_time(struct macb *bp,
> + const struct timespec64 *ts)
> +{
> + u32 ns, sech, secl;
> + s64 word_mask = 0xffffffff;
> +
> + sech = (u32)ts->tv_sec;
> + secl = (u32)ts->tv_sec;
> + ns = ts->tv_nsec;
> + if (ts->tv_sec > word_mask)
> + sech = (ts->tv_sec >> 32);
> +
> + spin_lock(&bp->tsu_clk_lock);
> +
> + /* TSH doesn't latch the time and no atomicity! */
> + gem_writel(bp, TN, 0); /* clear to avoid overflow */
> + gem_writel(bp, TSH, sech);
> + gem_writel(bp, TSL, secl);
> + gem_writel(bp, TN, ns);
> +
> + spin_unlock(&bp->tsu_clk_lock);
> +}
> +
> +static int gem_ptp_adjfine(struct ptp_clock_info *ptp, long scaled_ppm)
> +{
> + struct macb *bp = container_of(ptp, struct macb, ptp_caps);
> + u32 word, diff;
> + u64 adj, rate;
> + int neg_adj = 0;
> +
> + if (scaled_ppm < 0) {
> + neg_adj = 1;
> + scaled_ppm = -scaled_ppm;
> + }
> + rate = scaled_ppm;
> +
> + /* word: unused(8bit) | ns(8bit) | fractions(16bit) */
> + word = (bp->ns_incr << 16) + bp->subns_incr;
> +
> + adj = word;
> + adj *= rate;
> + adj += 500000UL << 16;
> + adj >>= 16; /* remove fractions */
> + diff = div_u64(adj, 1000000UL);
> + word = neg_adj ? word - diff : word + diff;
> +
> + spin_lock(&bp->tsu_clk_lock);
> +
> + gem_writel(bp, TISUBN, GEM_BF(SUBNSINCR, (word & 0xffff)));
> + gem_writel(bp, TI, GEM_BF(NSINCR, (word >> 16)));
> +
> + spin_unlock(&bp->tsu_clk_lock);
> + return 0;
> +}
> +
> +static int gem_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta) {
> + struct macb *bp = container_of(ptp, struct macb, ptp_caps);
> + struct timespec64 now, then = ns_to_timespec64(delta);
> + u32 adj, sign = 0;
> +
> + if (delta < 0) {
> + delta = -delta;
> + sign = 1;
> + }
> +
> + if (delta > 0x3FFFFFFF) {
> + gem_tsu_get_time(bp, &now);
> +
> + if (sign)
> + now = timespec64_sub(now, then);
> + else
> + now = timespec64_add(now, then);
> +
> + gem_tsu_set_time(bp, (const struct timespec64 *)&now);
> + } else {
> + adj = delta;
> + if (sign)
> + adj |= GEM_BIT(ADDSUB);
> +
> + gem_writel(bp, TA, adj);
> + }
> +
> + return 0;
> +}
> +
> +static int gem_ptp_gettime(struct ptp_clock_info *ptp, struct
> +timespec64 *ts) {
> + struct macb *bp = container_of(ptp, struct macb, ptp_caps);
> +
> + gem_tsu_get_time(bp, ts);
> +
> + return 0;
> +}
> +
> +static int gem_ptp_settime(struct ptp_clock_info *ptp,
> + const struct timespec64 *ts)
> +{
> + struct macb *bp = container_of(ptp, struct macb, ptp_caps);
> +
> + gem_tsu_set_time(bp, ts);
> +
> + return 0;
> +}
> +
> +static int gem_ptp_enable(struct ptp_clock_info *ptp,
> + struct ptp_clock_request *rq, int on) {
> + return -EOPNOTSUPP;
> +}
I think, we can support here:
1. PTP_CLK_REQ_EXTTS (interrupt mask register 0x030, bit 29: tsu_timer_comparison_mask)
2. PTP_CLK_REQ_PPS (interrupt mask register 0x030, bit 26: tsu_seconds_register_increment_mask)
> +
> +static struct ptp_clock_info gem_ptp_caps_template = {
> + .owner = THIS_MODULE,
> + .name = GEM_PTP_TIMER_NAME,
> + .max_adj = 0,
> + .n_alarm = 0,
> + .n_ext_ts = 0,
> + .n_per_out = 0,
> + .n_pins = 0,
> + .pps = 0,
> + .adjfine = gem_ptp_adjfine,
> + .adjtime = gem_ptp_adjtime,
> + .gettime64 = gem_ptp_gettime,
> + .settime64 = gem_ptp_settime,
> + .enable = gem_ptp_enable,
> +};
> +
> +static void gem_ptp_init_timer(struct macb *bp) {
> + struct timespec64 now;
> + u32 rem = 0;
> +
> + getnstimeofday64(&now);
> + gem_tsu_set_time(bp, (const struct timespec64 *)&now);
Why do you change TSU clock here? Is it necessary? You overwrite all values
even when someone doesn't need it. ptp4l calls ioctl SIOCSHWTSTAMP on start.
IMHO, there should be set up TSU and Increments.
> +
> + bp->ns_incr = div_u64_rem(NSEC_PER_SEC, bp->tsu_rate, &rem);
> + if (rem) {
> + u64 adj = rem;
> +
> + adj <<= 16; /* 16 bits nsec fragments */
> + bp->subns_incr = div_u64(adj, bp->tsu_rate);
> + } else {
> + bp->subns_incr = 0;
> + }
> +
> + gem_writel(bp, TISUBN, GEM_BF(SUBNSINCR, bp->subns_incr));
> + gem_writel(bp, TI, GEM_BF(NSINCR, bp->ns_incr));
The same comment like above.
> + gem_writel(bp, TA, 0);
What is the reason for zeroing Timer Adjust Register?
> +}
> +
> +static void gem_ptp_clear_timer(struct macb *bp) {
> + bp->ns_incr = 0;
> + bp->subns_incr = 0;
> +
> + gem_writel(bp, TISUBN, GEM_BF(SUBNSINCR, 0));
> + gem_writel(bp, TI, GEM_BF(NSINCR, 0));
> + gem_writel(bp, TA, 0);
> +}
> +
> +/* While GEM can timestamp PTP packets, it does not mark the RX
> +descriptor
> + * to identify them. UDP packets must be parsed to identify PTP packets.
> + *
> + * Note: Inspired from drivers/net/ethernet/ti/cpts.c */ static int
> +gem_get_ptp_peer(struct sk_buff *skb, int ptp_class) {
> + unsigned int offset = 0;
> + u8 *msgtype, *data = skb->data;
> +
> + /* PTP frames are rare! */
> + if (likely(ptp_class == PTP_CLASS_NONE))
> + return -1;
> +
> + if (ptp_class & PTP_CLASS_VLAN)
> + offset += VLAN_HLEN;
> +
> + switch (ptp_class & PTP_CLASS_PMASK) {
> + case PTP_CLASS_IPV4:
> + offset += ETH_HLEN + IPV4_HLEN(data + offset) + UDP_HLEN;
> + break;
> + case PTP_CLASS_IPV6:
> + offset += ETH_HLEN + IP6_HLEN + UDP_HLEN;
> + break;
> + case PTP_CLASS_L2:
> + offset += ETH_HLEN;
> + break;
> +
> + /* something went wrong! */
> + default:
> + return -1;
> + }
> +
> + if (skb->len + ETH_HLEN < offset + OFF_PTP_SEQUENCE_ID)
> + return -1;
> +
> + if (unlikely(ptp_class & PTP_CLASS_V1))
> + msgtype = data + offset + OFF_PTP_CONTROL;
> + else
> + msgtype = data + offset;
> +
> + return (*msgtype) & 0x2;
> +}
> +
> +static void gem_ptp_tx_hwtstamp(struct macb *bp, struct sk_buff *skb,
> + int peer_ev)
> +{
> + struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
> + struct timespec64 ts;
> + u64 ns;
> +
> + /* PTP Peer Event Frame packets */
> + if (peer_ev) {
> + ts.tv_sec = gem_readl(bp, PEFTSL);
> + ts.tv_nsec = gem_readl(bp, PEFTN);
> +
> + /* PTP Event Frame packets */
> + } else {
> + ts.tv_sec = gem_readl(bp, EFTSL);
> + ts.tv_nsec = gem_readl(bp, EFTN);
> + }
I'm wondering what is a difference between timestamp in transmit buffer descriptor (Word 2 and 3)
and PTP Event Frame Transmitted Seconds/Nanoseconds Register (0x1E0, 0x1E4).
> + ns = timespec64_to_ns(&ts);
> +
> + memset(shhwtstamps, 0, sizeof(struct skb_shared_hwtstamps));
> + shhwtstamps->hwtstamp = ns_to_ktime(ns);
> + skb_tstamp_tx(skb, skb_hwtstamps(skb)); }
> +
> +static void gem_ptp_rx_hwtstamp(struct macb *bp, struct sk_buff *skb,
> + int peer_ev)
> +{
> + struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
> + struct timespec64 ts;
> + u64 ns;
> +
> + if (peer_ev) {
> + /* PTP Peer Event Frame packets */
> + ts.tv_sec = gem_readl(bp, PEFRSL);
> + ts.tv_nsec = gem_readl(bp, PEFRN);
> + } else {
> + /* PTP Event Frame packets */
> + ts.tv_sec = gem_readl(bp, EFRSL);
> + ts.tv_nsec = gem_readl(bp, EFRN);
> + }
The same concerns like above.
> + ns = timespec64_to_ns(&ts);
> +
> + memset(shhwtstamps, 0, sizeof(struct skb_shared_hwtstamps));
> + shhwtstamps->hwtstamp = ns_to_ktime(ns); }
> +
> +/* no static, GEM PTP interface functions */ void
> +gem_ptp_txstamp(struct macb *bp, struct sk_buff *skb) {
> + if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) {
> + int class = ptp_classify_raw(skb);
> + int peer;
> +
> + peer = gem_get_ptp_peer(skb, class);
> + if (peer < 0)
> + return;
> +
> + /* Timestamp this packet */
> + gem_ptp_tx_hwtstamp(bp, skb, peer);
> + }
> +}
> +
> +void gem_ptp_rxstamp(struct macb *bp, struct sk_buff *skb) {
> + int class, peer;
> +
> + __skb_push(skb, ETH_HLEN);
> + class = ptp_classify_raw(skb);
> + __skb_pull(skb, ETH_HLEN);
> +
> + peer = gem_get_ptp_peer(skb, class);
> + if (peer < 0)
> + return;
> +
> + gem_ptp_rx_hwtstamp(bp, skb, peer);
> +}
> +
> +void gem_ptp_init(struct net_device *ndev) {
> + struct macb *bp = netdev_priv(ndev);
> +
> + spin_lock_init(&bp->tsu_clk_lock);
> + bp->ptp_caps = gem_ptp_caps_template;
> +
> + /* nominal frequency and maximum adjustment in ppb */
> + bp->tsu_rate = bp->ptp_info->get_tsu_rate(bp);
> + bp->ptp_caps.max_adj = bp->ptp_info->get_ptp_max_adj();
> +
> + gem_ptp_init_timer(bp);
> +
> + bp->ptp_clock = ptp_clock_register(&bp->ptp_caps, NULL);
> + if (IS_ERR(&bp->ptp_clock)) {
> + bp->ptp_clock = NULL;
> + pr_err("ptp clock register failed\n");
> + return;
But you have already overwritten TSU and Increments.
> + }
> +
> + dev_info(&bp->pdev->dev, "%s ptp clock registered.\n",
> + GEM_PTP_TIMER_NAME);
> +}
> +
> +void gem_ptp_remove(struct net_device *ndev) {
> + struct macb *bp = netdev_priv(ndev);
> +
> + if (bp->ptp_clock)
> + ptp_clock_unregister(bp->ptp_clock);
> +
> + gem_ptp_clear_timer(bp);
> +
> + dev_info(&bp->pdev->dev, "%s ptp clock unregistered.\n",
> + GEM_PTP_TIMER_NAME);
> +}
> --
> 2.7.4
>
Why don't you support HWTSTAMP_TX_ONESTEP_SYNC?
(Network control register 0x000, bit 24: one_step_sync_mode)
Best regards,
Rafal Ozieblo | Firmware System Engineer,
www.cadence.com
^ 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