* [PATCH v2 1/7] drm/panel: simple: add support for Ampire AM-800480AYTZQW-00H
From: Rob Herring @ 2018-01-05 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515046345-15881-2-git-send-email-jagan@amarulasolutions.com>
On Thu, Jan 04, 2018 at 11:42:19AM +0530, Jagan Teki wrote:
> This adds support for the Ampire AM-800480AYTZQW-00H 7.0" WGA LCD,
> which can be supported by the simple panel driver.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v2:
> - Updated binding info about optional properties, node and example
>
> .../display/panel/ampire,am-800480aytzqw-00h.txt | 25 ++++++++++++++++++++
Reviewed-by: Rob Herring <robh@kernel.org>
> drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
> 2 files changed, 52 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
^ permalink raw reply
* [PATCH v2 4/7] drm/panel: simple: Add support for KEO TX31D200VM0BAA
From: Rob Herring @ 2018-01-05 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515046345-15881-5-git-send-email-jagan@amarulasolutions.com>
On Thu, Jan 04, 2018 at 11:42:22AM +0530, Jagan Teki wrote:
> This adds support for the Kaohsiung Opto-Electronics.,
> TX31D200VM0BAA 12.3" HSXGA LVDS panel, which can be
> supported by the simple panel driver.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v2:
> - Updated binding info about optional properties, node and example
>
> .../bindings/display/panel/koe,tx31d200vm0baa.txt | 25 ++++++++++++++++++++
Reviewed-by: Rob Herring <robh@kernel.org>
> drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
> 2 files changed, 52 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt
^ permalink raw reply
* [PATCH v1 4/6] dt-bindings: clock: mediatek: add "simple-mfd" in audsys documentation
From: Rob Herring @ 2018-01-05 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bd1cb0aeaf07b4bf2cedbf00ef8fedc6ba01f9cb.1515038387.git.ryder.lee@mediatek.com>
On Thu, Jan 04, 2018 at 03:44:20PM +0800, Ryder Lee wrote:
> Add "simple-mfd" to support MFD device and add a compatible string for MT2701.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> .../bindings/arm/mediatek/mediatek,audsys.txt | 21 +++++++++++++++------
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> index 9b8f578..6e97552 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> @@ -6,17 +6,25 @@ The MediaTek AUDSYS controller provides various clocks to the system.
> Required Properties:
>
> - compatible: Should be one of:
> - - "mediatek,mt7622-audsys", "syscon"
> + - "mediatek,mt2701-audsys", "syscon", "simple-mfd"
> + - "mediatek,mt7622-audsys", "syscon", "simple-mfd"
> - #clock-cells: Must be 1
I don't think this is a simple-mfd. The AFE uses clocks created by its
parent, right? So the parent should be probed first. You should have
the parent instantiate the child nodes.
> The AUDSYS controller uses the common clk binding from
> Documentation/devicetree/bindings/clock/clock-bindings.txt
> The available clocks are defined in dt-bindings/clock/mt*-clk.h.
>
> +See ../sound/mt2701-afe-pcm.txt for details about required subnode.
> +
> Example:
>
> -audsys: audsys at 11220000 {
> - compatible = "mediatek,mt7622-audsys", "syscon";
> - reg = <0 0x11220000 0 0x1000>;
> - #clock-cells = <1>;
> -};
> + audsys: audio-subsystem at 11220000 {
> + compatible = "mediatek,mt2701-audsys", "syscon", "simple-mfd";
> + reg = <0 0x11220000 0 0x1000>;
> + #clock-cells = <1>;
> +
> + afe: audio-controller {
> + compatible = "mediatek,mt2701-audio";
> + ...
> + };
> + };
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" 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 v1 5/6] clk: mediatek: update missing clock data for MT7622 audsys
From: Rob Herring @ 2018-01-05 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <296e97ad8720d575918657e821bb2a01a2d31c49.1515038387.git.ryder.lee@mediatek.com>
On Thu, Jan 04, 2018 at 03:44:21PM +0800, Ryder Lee wrote:
> Add missing clock data 'CLK_AUDIO_AFE_CONN' for MT7622 audsys.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> drivers/clk/mediatek/clk-mt7622-aud.c | 3 ++-
> include/dt-bindings/clock/mt7622-clk.h | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c b/drivers/clk/mediatek/clk-mt7622-aud.c
> index fad7d9f..96959ad 100644
> --- a/drivers/clk/mediatek/clk-mt7622-aud.c
> +++ b/drivers/clk/mediatek/clk-mt7622-aud.c
> @@ -106,6 +106,7 @@
> GATE_AUDIO1(CLK_AUDIO_INTDIR, "audio_intdir", "intdir_sel", 20),
> GATE_AUDIO1(CLK_AUDIO_A1SYS, "audio_a1sys", "a1sys_hp_sel", 21),
> GATE_AUDIO1(CLK_AUDIO_A2SYS, "audio_a2sys", "a2sys_hp_sel", 22),
> + GATE_AUDIO1(CLK_AUDIO_AFE_CONN, "audio_afe_conn", "a1sys_hp_sel", 23),
> /* AUDIO2 */
> GATE_AUDIO2(CLK_AUDIO_UL1, "audio_ul1", "a1sys_hp_sel", 0),
> GATE_AUDIO2(CLK_AUDIO_UL2, "audio_ul2", "a1sys_hp_sel", 1),
> @@ -146,7 +147,7 @@ static int clk_mt7622_audiosys_init(struct platform_device *pdev)
> clk_data = mtk_alloc_clk_data(CLK_AUDIO_NR_CLK);
>
> mtk_clk_register_gates(node, audio_clks, ARRAY_SIZE(audio_clks),
> - clk_data);
> + clk_data);
Drop this unrelated change.
>
> r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> if (r)
> diff --git a/include/dt-bindings/clock/mt7622-clk.h b/include/dt-bindings/clock/mt7622-clk.h
> index 3e514ed..e9d77f0 100644
> --- a/include/dt-bindings/clock/mt7622-clk.h
> +++ b/include/dt-bindings/clock/mt7622-clk.h
> @@ -235,7 +235,8 @@
> #define CLK_AUDIO_MEM_ASRC3 43
> #define CLK_AUDIO_MEM_ASRC4 44
> #define CLK_AUDIO_MEM_ASRC5 45
> -#define CLK_AUDIO_NR_CLK 46
> +#define CLK_AUDIO_AFE_CONN 46
> +#define CLK_AUDIO_NR_CLK 47
>
> /* SSUSBSYS */
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" 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 2/5] clk: lpc32xx: read-only divider can propagate rate change
From: Jerome Brunet @ 2018-01-05 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5a256cde-8e59-4921-f6e2-fecd3d1c3377@mleia.com>
On Fri, 2018-01-05 at 20:12 +0200, Vladimir Zapolskiy wrote:
> Hi Jerome,
>
> On 01/05/2018 07:09 PM, Jerome Brunet wrote:
> > When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the
> > register shall be left un-touched, but it does not mean the clock
> > should stop rate propagation if CLK_SET_RATE_PARENT is set
> >
>
> okay, the statement sounds correct, but there is no such clocks on LPC32xx,
> thus I hardly can confirm that adding dead/inapplicable code is a fix.
>
> > This properly handled in qcom clk-regmap-divider but it was not in the
> > lpc32xx divider
> >
> > Fixes: f7c82a60ba26 ("clk: lpc32xx: add common clock framework driver")
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
>
> I would suggest to drop two LPC32xx clock driver changes from the series.
Hi Vladimir,
This is fine by me. Whether LPC32xx supports CLK_DIVIDER_READ_ONLY is up to you,
but you should be consistent about it.
I added the fix to LPC32xx because it looks like the generic divider (a lot) and
appears to support CLK_DIVIDER_READ_ONLY. If it does not, could you please kill
the related code ?
Regards
Jerome
>
> --
> With best wishes,
> Vladimir
^ permalink raw reply
* [PATCH 09/67] arc: remove CONFIG_ARC_PLAT_NEEDS_PHYS_TO_DMA
From: Vineet Gupta @ 2018-01-05 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171229081911.2802-10-hch@lst.de>
On 12/29/2017 12:25 AM, Christoph Hellwig wrote:
> We always use the stub definitions, so remove the unused other code.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Vineet Gupta <vgupta@synopsys.com>
FWIW, it was removed and reintroduced as one of the customers wanted it, which is
not relevant now !
Thx,
-Vineet
> ---
> arch/arc/Kconfig | 3 ---
> arch/arc/include/asm/dma-mapping.h | 7 -------
> arch/arc/mm/dma.c | 14 +++++++-------
> 3 files changed, 7 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index 9d5fd00d9e91..f3a80cf164cc 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -463,9 +463,6 @@ config ARCH_PHYS_ADDR_T_64BIT
> config ARCH_DMA_ADDR_T_64BIT
> bool
>
> -config ARC_PLAT_NEEDS_PHYS_TO_DMA
> - bool
> -
> config ARC_KVADDR_SIZE
> int "Kernel Virtual Address Space size (MB)"
> range 0 512
> diff --git a/arch/arc/include/asm/dma-mapping.h b/arch/arc/include/asm/dma-mapping.h
> index 94285031c4fb..7a16824bfe98 100644
> --- a/arch/arc/include/asm/dma-mapping.h
> +++ b/arch/arc/include/asm/dma-mapping.h
> @@ -11,13 +11,6 @@
> #ifndef ASM_ARC_DMA_MAPPING_H
> #define ASM_ARC_DMA_MAPPING_H
>
> -#ifndef CONFIG_ARC_PLAT_NEEDS_PHYS_TO_DMA
> -#define plat_dma_to_phys(dev, dma_handle) ((phys_addr_t)(dma_handle))
> -#define plat_phys_to_dma(dev, paddr) ((dma_addr_t)(paddr))
> -#else
> -#include <plat/dma.h>
> -#endif
> -
> extern const struct dma_map_ops arc_dma_ops;
>
> static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
> diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
> index fad18261ef6a..1d405b86250c 100644
> --- a/arch/arc/mm/dma.c
> +++ b/arch/arc/mm/dma.c
> @@ -60,7 +60,7 @@ static void *arc_dma_alloc(struct device *dev, size_t size,
> /* This is linear addr (0x8000_0000 based) */
> paddr = page_to_phys(page);
>
> - *dma_handle = plat_phys_to_dma(dev, paddr);
> + *dma_handle = paddr;
>
> /* This is kernel Virtual address (0x7000_0000 based) */
> if (need_kvaddr) {
> @@ -92,7 +92,7 @@ static void *arc_dma_alloc(struct device *dev, size_t size,
> static void arc_dma_free(struct device *dev, size_t size, void *vaddr,
> dma_addr_t dma_handle, unsigned long attrs)
> {
> - phys_addr_t paddr = plat_dma_to_phys(dev, dma_handle);
> + phys_addr_t paddr = dma_handle;
> struct page *page = virt_to_page(paddr);
> int is_non_coh = 1;
>
> @@ -111,7 +111,7 @@ static int arc_dma_mmap(struct device *dev, struct vm_area_struct *vma,
> {
> unsigned long user_count = vma_pages(vma);
> unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> - unsigned long pfn = __phys_to_pfn(plat_dma_to_phys(dev, dma_addr));
> + unsigned long pfn = __phys_to_pfn(dma_addr);
> unsigned long off = vma->vm_pgoff;
> int ret = -ENXIO;
>
> @@ -175,7 +175,7 @@ static dma_addr_t arc_dma_map_page(struct device *dev, struct page *page,
> if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
> _dma_cache_sync(paddr, size, dir);
>
> - return plat_phys_to_dma(dev, paddr);
> + return paddr;
> }
>
> /*
> @@ -190,7 +190,7 @@ static void arc_dma_unmap_page(struct device *dev, dma_addr_t handle,
> size_t size, enum dma_data_direction dir,
> unsigned long attrs)
> {
> - phys_addr_t paddr = plat_dma_to_phys(dev, handle);
> + phys_addr_t paddr = handle;
>
> if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
> _dma_cache_sync(paddr, size, dir);
> @@ -224,13 +224,13 @@ static void arc_dma_unmap_sg(struct device *dev, struct scatterlist *sg,
> static void arc_dma_sync_single_for_cpu(struct device *dev,
> dma_addr_t dma_handle, size_t size, enum dma_data_direction dir)
> {
> - _dma_cache_sync(plat_dma_to_phys(dev, dma_handle), size, DMA_FROM_DEVICE);
> + _dma_cache_sync(dma_handle, size, DMA_FROM_DEVICE);
> }
>
> static void arc_dma_sync_single_for_device(struct device *dev,
> dma_addr_t dma_handle, size_t size, enum dma_data_direction dir)
> {
> - _dma_cache_sync(plat_dma_to_phys(dev, dma_handle), size, DMA_TO_DEVICE);
> + _dma_cache_sync(dma_handle, size, DMA_TO_DEVICE);
> }
>
> static void arc_dma_sync_sg_for_cpu(struct device *dev,
^ permalink raw reply
* [Bug] Endless deferred probe of dwc2 on RPi 3
From: Stefan Wahren @ 2018-01-05 20:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
i noticed on my Raspberry Pi 3 (Linux 4.15rc6, ARM64, defconfig) that probing of dwc2 driver is deferred endlessly. This issue is triggered by a recent DT clean up 014d6da6cb25 ("ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells") which is correct according to Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
Here is the call stack which always returns -EPROBE_DEFER on this platform:
dwc2_lowlevel_hw_init()
devm_phy_get()
phy_get()
_of_phy_get()
Btw Raspberry Pi 2 (ARM, multi_v7_defconfig) is also affected, but not Raspberry Pi Zero W (ARM, bcm2835_config) while all 3 platforms share the same USB DT nodes.
Any ideas to fix this issue are welcome.
Best regards
Stefan
^ permalink raw reply
* [PATCH] arm64: Implement branch predictor hardening for Falkor
From: Shanker Donthineni @ 2018-01-05 20:28 UTC (permalink / raw)
To: linux-arm-kernel
Falkor is susceptible to branch predictor aliasing and can
theoretically be attacked by malicious code. This patch
implements a mitigation for these attacks, preventing any
malicious entries from affecting other victim contexts.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
---
This patch has been verified using tip of
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti
and
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64?h=v4.15-rc6&id=c622cc013cece073722592cff1ac6643a33b1622
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/include/asm/kvm_asm.h | 2 ++
arch/arm64/kernel/bpi.S | 8 +++++++
arch/arm64/kernel/cpu_errata.c | 49 ++++++++++++++++++++++++++++++++++++++--
arch/arm64/kvm/hyp/entry.S | 12 ++++++++++
arch/arm64/kvm/hyp/switch.c | 10 ++++++++
6 files changed, 81 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 51616e7..7049b48 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -43,7 +43,8 @@
#define ARM64_SVE 22
#define ARM64_UNMAP_KERNEL_AT_EL0 23
#define ARM64_HARDEN_BRANCH_PREDICTOR 24
+#define ARM64_HARDEN_BP_POST_GUEST_EXIT 25
-#define ARM64_NCAPS 25
+#define ARM64_NCAPS 26
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index ab4d0a9..24961b7 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -68,6 +68,8 @@
extern u32 __init_stage2_translation(void);
+extern void __qcom_hyp_sanitize_btac_predictors(void);
+
#endif
#endif /* __ARM_KVM_ASM_H__ */
diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S
index 2b10d52..44ffcda 100644
--- a/arch/arm64/kernel/bpi.S
+++ b/arch/arm64/kernel/bpi.S
@@ -77,3 +77,11 @@ ENTRY(__psci_hyp_bp_inval_start)
ldp x2, x3, [sp], #16
ldp x0, x1, [sp], #16
ENTRY(__psci_hyp_bp_inval_end)
+
+ENTRY(__qcom_hyp_sanitize_link_stack_start)
+ stp x29, x30, [sp, #-16]!
+ .rept 16
+ bl . + 4
+ .endr
+ ldp x29, x30, [sp], #16
+ENTRY(__qcom_hyp_sanitize_link_stack_end)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index cb0fb37..daf53a5 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -54,6 +54,8 @@ static int cpu_enable_trap_ctr_access(void *__unused)
#ifdef CONFIG_KVM
extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
+extern char __qcom_hyp_sanitize_link_stack_start[];
+extern char __qcom_hyp_sanitize_link_stack_end[];
static void __copy_hyp_vect_bpi(int slot, const char *hyp_vecs_start,
const char *hyp_vecs_end)
@@ -96,8 +98,10 @@ static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
spin_unlock(&bp_lock);
}
#else
-#define __psci_hyp_bp_inval_start NULL
-#define __psci_hyp_bp_inval_end NULL
+#define __psci_hyp_bp_inval_start NULL
+#define __psci_hyp_bp_inval_end NULL
+#define __qcom_hyp_sanitize_link_stack_start NULL
+#define __qcom_hyp_sanitize_link_stack_start NULL
static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
const char *hyp_vecs_start,
@@ -138,6 +142,29 @@ static int enable_psci_bp_hardening(void *data)
return 0;
}
+
+static void qcom_link_stack_sanitization(void)
+{
+ u64 tmp;
+
+ asm volatile("mov %0, x30 \n"
+ ".rept 16 \n"
+ "bl . + 4 \n"
+ ".endr \n"
+ "mov x30, %0 \n"
+ : "=&r" (tmp));
+}
+
+static int qcom_enable_link_stack_sanitization(void *data)
+{
+ const struct arm64_cpu_capabilities *entry = data;
+
+ install_bp_hardening_cb(entry, qcom_link_stack_sanitization,
+ __qcom_hyp_sanitize_link_stack_start,
+ __qcom_hyp_sanitize_link_stack_end);
+
+ return 0;
+}
#endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */
#define MIDR_RANGE(model, min, max) \
@@ -302,6 +329,24 @@ static int enable_psci_bp_hardening(void *data)
MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
.enable = enable_psci_bp_hardening,
},
+ {
+ .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
+ MIDR_ALL_VERSIONS(MIDR_QCOM_FALKOR_V1),
+ .enable = qcom_enable_link_stack_sanitization,
+ },
+ {
+ .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
+ MIDR_ALL_VERSIONS(MIDR_QCOM_FALKOR),
+ .enable = qcom_enable_link_stack_sanitization,
+ },
+ {
+ .capability = ARM64_HARDEN_BP_POST_GUEST_EXIT,
+ MIDR_ALL_VERSIONS(MIDR_QCOM_FALKOR_V1),
+ },
+ {
+ .capability = ARM64_HARDEN_BP_POST_GUEST_EXIT,
+ MIDR_ALL_VERSIONS(MIDR_QCOM_FALKOR),
+ },
#endif
{
}
diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
index 12ee62d..9c45c6a 100644
--- a/arch/arm64/kvm/hyp/entry.S
+++ b/arch/arm64/kvm/hyp/entry.S
@@ -196,3 +196,15 @@ alternative_endif
eret
ENDPROC(__fpsimd_guest_restore)
+
+ENTRY(__qcom_hyp_sanitize_btac_predictors)
+ /**
+ * Call SMC64 with Silicon provider serviceID 23<<8 (0xc2001700)
+ * 0xC2000000-0xC200FFFF: assigned to SiP Service Calls
+ * b15-b0: contains SiP functionID
+ */
+ movz x0, #0x1700
+ movk x0, #0xc200, lsl #16
+ smc #0
+ ret
+ENDPROC(__qcom_hyp_sanitize_btac_predictors)
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 4d273f6..7e37379 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -406,6 +406,16 @@ int __hyp_text __kvm_vcpu_run(struct kvm_vcpu *vcpu)
/* 0 falls through to be handled out of EL2 */
}
+ if (cpus_have_const_cap(ARM64_HARDEN_BP_POST_GUEST_EXIT)) {
+ u32 midr = read_cpuid_id();
+
+ /* Apply BTAC predictors mitigation to all Falkor chips */
+ if (((midr & MIDR_CPU_MODEL_MASK) == MIDR_QCOM_FALKOR) ||
+ ((midr & MIDR_CPU_MODEL_MASK) == MIDR_QCOM_FALKOR_V1)) {
+ __qcom_hyp_sanitize_btac_predictors();
+ }
+ }
+
fp_enabled = __fpsimd_enabled();
__sysreg_save_guest_state(guest_ctxt);
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH] mtd/nand/atmel: Delete an error message for a failed memory allocation in two functions
From: SF Markus Elfring @ 2018-01-05 20:55 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 5 Jan 2018 21:45:04 +0100
Omit an extra message for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/mtd/nand/atmel/nand-controller.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/atmel/nand-controller.c b/drivers/mtd/nand/atmel/nand-controller.c
index 90a71a56bc23..a41b999229c9 100644
--- a/drivers/mtd/nand/atmel/nand-controller.c
+++ b/drivers/mtd/nand/atmel/nand-controller.c
@@ -1612,10 +1612,8 @@ static int atmel_nand_register(struct atmel_nand *nand)
mtd->name = devm_kasprintf(nc->dev, GFP_KERNEL,
"%s:nand.%d", dev_name(nc->dev),
nand->cs[0].id);
- if (!mtd->name) {
- dev_err(nc->dev, "Failed to allocate mtd->name\n");
+ if (!mtd->name)
return -ENOMEM;
- }
}
ret = nand_scan_tail(mtd);
@@ -1654,10 +1652,8 @@ static struct atmel_nand *atmel_nand_create(struct atmel_nand_controller *nc,
nand = devm_kzalloc(nc->dev,
sizeof(*nand) + (numcs * sizeof(*nand->cs)),
GFP_KERNEL);
- if (!nand) {
- dev_err(nc->dev, "Failed to allocate NAND object\n");
+ if (!nand)
return ERR_PTR(-ENOMEM);
- }
nand->numcs = numcs;
--
2.15.1
^ permalink raw reply related
* [PATCH] mtd/nand/sunxi: Delete an error message for a failed memory allocation in sunxi_nand_chip_init()
From: SF Markus Elfring @ 2018-01-05 21:34 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 5 Jan 2018 22:27:09 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/mtd/nand/sunxi_nand.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 82244be3e766..ebfa130a9285 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -2019,10 +2019,8 @@ static int sunxi_nand_chip_init(struct device *dev, struct sunxi_nfc *nfc,
sizeof(*chip) +
(nsels * sizeof(struct sunxi_nand_chip_sel)),
GFP_KERNEL);
- if (!chip) {
- dev_err(dev, "could not allocate chip\n");
+ if (!chip)
return -ENOMEM;
- }
chip->nsels = nsels;
chip->selected = -1;
--
2.15.1
^ permalink raw reply related
* [PATCH v5 3/9] ACPI: Enable PPTT support on ARM64
From: Jeremy Linton @ 2018-01-05 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213172647.GA3316@red-moon>
Hi,
On 12/13/2017 11:26 AM, Lorenzo Pieralisi wrote:
> On Fri, Dec 01, 2017 at 04:23:24PM -0600, Jeremy Linton wrote:
>> Now that we have a PPTT parser, in preparation for its use
>> on arm64, lets build it.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>> ---
>> arch/arm64/Kconfig | 1 +
>> drivers/acpi/Kconfig | 3 +++
>> drivers/acpi/Makefile | 1 +
>> 3 files changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index a93339f5178f..e62fd1e08c1f 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -7,6 +7,7 @@ config ARM64
>> select ACPI_REDUCED_HARDWARE_ONLY if ACPI
>> select ACPI_MCFG if ACPI
>> select ACPI_SPCR_TABLE if ACPI
>> + select ACPI_PPTT if ACPI
>> select ARCH_CLOCKSOURCE_DATA
>> select ARCH_HAS_DEBUG_VIRTUAL
>> select ARCH_HAS_DEVMEM_IS_ALLOWED
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 46505396869e..df7aebf0af0e 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -545,6 +545,9 @@ config ACPI_CONFIGFS
>>
>> if ARM64
>> source "drivers/acpi/arm64/Kconfig"
>> +
>> +config ACPI_PPTT
>> + bool
>
> We need to make a choice here. Either PPTT is considered ARM64 only and
> we move code and config to drivers/acpi/arm64/Kconfig or we leave it in
> drivers/acpi/pptt.c and we add a Kconfig entry in drivers/acpi/Kconfig
> (and we make pptt.c compile on !ARM64 - which is what it should be given
> that there is nothing ARM64 specific in it).
No one else has expressed and opinion about this here..
So i'm not sure what to think.
OTOH a lot of people didn't like it when I had it in the arm64
directory, which was my original opinion. It seems other people thought
that at some point in the future other ACPI platforms would want to use
it so putting it in the arm64 directory was a mistake.
So, I'm leaning towards leaving it like it is, under the assumption that
when someone puts in the effort to verify it on another ACPI platform
they can move the config option up 6 lines. In the meantime I don't
think it should be enabled on platforms where it hasn't been tested or
is basically blocked (cpu_cacheinfo->cpu_map_populated) from executing
or there isn't currently any benefit.
Hence I'm planning on leaving it as is until I get further clarity.
>
> Lorenzo
>
>> endif
>>
>> config TPS68470_PMIC_OPREGION
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 41954a601989..b6056b566df4 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -87,6 +87,7 @@ obj-$(CONFIG_ACPI_BGRT) += bgrt.o
>> obj-$(CONFIG_ACPI_CPPC_LIB) += cppc_acpi.o
>> obj-$(CONFIG_ACPI_SPCR_TABLE) += spcr.o
>> obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
>> +obj-$(CONFIG_ACPI_PPTT) += pptt.o
>>
>> # processor has its own "processor." module_param namespace
>> processor-y := processor_driver.o
>> --
>> 2.13.5
>>
^ permalink raw reply
* [PATCH v5 3/9] ACPI: Enable PPTT support on ARM64
From: Rafael J. Wysocki @ 2018-01-05 22:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f0f8c79a-2ff2-abe9-4a16-79485f0a1e2c@arm.com>
On Fri, Jan 5, 2018 at 10:58 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> Hi,
>
>
> On 12/13/2017 11:26 AM, Lorenzo Pieralisi wrote:
>>
>> On Fri, Dec 01, 2017 at 04:23:24PM -0600, Jeremy Linton wrote:
>>>
>>> Now that we have a PPTT parser, in preparation for its use
>>> on arm64, lets build it.
>>>
>>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>>> ---
>>> arch/arm64/Kconfig | 1 +
>>> drivers/acpi/Kconfig | 3 +++
>>> drivers/acpi/Makefile | 1 +
>>> 3 files changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index a93339f5178f..e62fd1e08c1f 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -7,6 +7,7 @@ config ARM64
>>> select ACPI_REDUCED_HARDWARE_ONLY if ACPI
>>> select ACPI_MCFG if ACPI
>>> select ACPI_SPCR_TABLE if ACPI
>>> + select ACPI_PPTT if ACPI
>>> select ARCH_CLOCKSOURCE_DATA
>>> select ARCH_HAS_DEBUG_VIRTUAL
>>> select ARCH_HAS_DEVMEM_IS_ALLOWED
>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>> index 46505396869e..df7aebf0af0e 100644
>>> --- a/drivers/acpi/Kconfig
>>> +++ b/drivers/acpi/Kconfig
>>> @@ -545,6 +545,9 @@ config ACPI_CONFIGFS
>>> if ARM64
>>> source "drivers/acpi/arm64/Kconfig"
>>> +
>>> +config ACPI_PPTT
>>> + bool
>>
>>
>> We need to make a choice here. Either PPTT is considered ARM64 only and
>> we move code and config to drivers/acpi/arm64/Kconfig or we leave it in
>> drivers/acpi/pptt.c and we add a Kconfig entry in drivers/acpi/Kconfig
>> (and we make pptt.c compile on !ARM64 - which is what it should be given
>> that there is nothing ARM64 specific in it).
>
>
> No one else has expressed and opinion about this here..
>
> So i'm not sure what to think.
>
> OTOH a lot of people didn't like it when I had it in the arm64 directory,
> which was my original opinion. It seems other people thought that at some
> point in the future other ACPI platforms would want to use it so putting it
> in the arm64 directory was a mistake.
In my view it may go directly into drivers/acpi/ for the time being.
That said, going forward it may be useful to add a special
subdirectory under drivers/acpi/ for these "table drivers" as we seem
to be acquiring them at alarming rate.
> So, I'm leaning towards leaving it like it is, under the assumption that
> when someone puts in the effort to verify it on another ACPI platform they
> can move the config option up 6 lines. In the meantime I don't think it
> should be enabled on platforms where it hasn't been tested or is basically
> blocked (cpu_cacheinfo->cpu_map_populated) from executing or there isn't
> currently any benefit.
Agreed.
Thanks,
Rafael
^ permalink raw reply
* [PATCH] ASoC: rockchip: i2s: Support mono capture
From: Matthias Kaehlcke @ 2018-01-05 22:12 UTC (permalink / raw)
To: linux-arm-kernel
The Rockchip I2S controller only allows to configure even numbers of
capture channels. It is still possible to capture monophonic audio by
using dual-channel mode and ignoring the 'data' from the second
channel.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
sound/soc/rockchip/rockchip_i2s.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/rockchip/rockchip_i2s.c b/sound/soc/rockchip/rockchip_i2s.c
index 908211e1d6fc..cc22ab3d10dd 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -328,6 +328,7 @@ static int rockchip_i2s_hw_params(struct snd_pcm_substream *substream,
val |= I2S_CHN_4;
break;
case 2:
+ case 1:
val |= I2S_CHN_2;
break;
default:
@@ -460,7 +461,7 @@ static struct snd_soc_dai_driver rockchip_i2s_dai = {
},
.capture = {
.stream_name = "Capture",
- .channels_min = 2,
+ .channels_min = 1,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_192000,
.formats = (SNDRV_PCM_FMTBIT_S8 |
@@ -654,7 +655,7 @@ static int rockchip_i2s_probe(struct platform_device *pdev)
}
if (!of_property_read_u32(node, "rockchip,capture-channels", &val)) {
- if (val >= 2 && val <= 8)
+ if (val >= 1 && val <= 8)
soc_dai->capture.channels_max = val;
}
--
2.16.0.rc0.223.g4a4ac83678-goog
^ permalink raw reply related
* [PATCH v3 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox
From: Jiaying Liang @ 2018-01-05 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105153146.lgxlhfsql5tq2kn5@rob-hp-laptop>
> -----Original Message-----
> From: Rob Herring [mailto:robh at kernel.org]
> Sent: Friday, January 05, 2018 7:32 AM
> To: Jiaying Liang <jliang@xilinx.com>
> Cc: jassisinghbrar at gmail.com; michal.simek at xilinx.com;
> mark.rutland at arm.com; linux-arm-kernel at lists.infradead.org;
> devicetree at vger.kernel.org; linux-kernel at vger.kernel.org; Jiaying Liang
> <jliang@xilinx.com>
> Subject: Re: [PATCH v3 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox
>
> On Thu, Jan 04, 2018 at 03:51:31PM -0800, Wendy Liang wrote:
> > Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block in
> > ZynqMP SoC used for the communication between various processor
> > systems.
> >
> > Signed-off-by: Wendy Liang <jliang@xilinx.com>
> > ---
> > .../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt | 104
> +++++++++++++++++++++
> > 1 file changed, 104 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt
>
> Please add acks and reviewed-by's when posting new versions.
[Wendy] Thanks, will add this in the next version.
^ permalink raw reply
* [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero
From: Kani, Toshi @ 2018-01-05 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514460261-65222-1-git-send-email-guohanjun@huawei.com>
On Thu, 2017-12-28 at 19:24 +0800, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> When we using iounmap() to free the 4K mapping, it just clear the PTEs
> but leave P4D/PUD/PMD unchanged, also will not free the memory of page
> tables.
>
> This will cause issues on ARM64 platform (not sure if other archs have
> the same issue) for this case:
>
> 1. ioremap a 4K size, valid page table will build,
> 2. iounmap it, pte0 will set to 0;
> 3. ioremap the same address with 2M size, pgd/pmd is unchanged,
> then set the a new value for pmd;
> 4. pte0 is leaked;
> 5. CPU may meet exception because the old pmd is still in TLB,
> which will lead to kernel panic.
>
> Fix it by skip setting up the huge I/O mappings when p4d/pud/pmd is
> zero.
Hi Hanjun,
I tested the above steps on my x86 box, but was not able to reproduce
your kernel panic. On x86, a 4K vaddr gets allocated from a small
fragmented free range, whereas a 2MB vaddr is from a larger free range.
Their addrs have different alignments (4KB & 2MB) as well. So, the
steps did not lead to use a same pmd entry.
However, I agree that zero'd pte entries will be leaked when a pmd map
is set if they are present under the pmd.
I also tested your patch on my x86 box. Unfortunately, it effectively
disabled 2MB mappings. While a 2MB vaddr gets allocated from a larger
free range, it sill comes from a free range covered by zero'd pte
entries. So, it ends up with 4KB mappings with your changes.
I think we need to come up with other approach.
Thanks,
-Toshi
^ permalink raw reply
* [PATCH v8] arm64: dts: meson-axg: switch uart_ao clock to CLK81
From: Kevin Hilman @ 2018-01-05 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215141741.175985-1-yixun.lan@amlogic.com>
Yixun Lan <yixun.lan@amlogic.com> writes:
> Switch the uart_ao pclk to CLK81 since the clock driver is ready.
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Applied to v4.16/dt64 with Neil's tag.
Kevin
^ permalink raw reply
* [PATCH v2] ARM64: dts: meson-axg: add the SPICC controller
From: Kevin Hilman @ 2018-01-05 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215144217.223593-1-yixun.lan@amlogic.com>
Yixun Lan <yixun.lan@amlogic.com> writes:
> From: Sunny Luo <sunny.luo@amlogic.com>
>
> Add DT info for the SPICC controller which found in
> the Amlogic's Meson-AXG SoC.
>
> Signed-off-by: Sunny Luo <sunny.luo@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Applied with Neil's tag.
Kevin
^ permalink raw reply
* [PATCH v4 1/2] ARM64: dts: meson-axg: add ethernet mac controller
From: Kevin Hilman @ 2018-01-05 23:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216035527.96952-2-yixun.lan@amlogic.com>
Yixun Lan <yixun.lan@amlogic.com> writes:
> Add DT info for the stmmac ethernet MAC which found in
> the Amlogic's Meson-AXG SoC, also describe the ethernet
> pinctrl & clock information here.
>
> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Applied to v4.16/dt64,
Kevin
^ permalink raw reply
* [PATCH v2 0/5] ARM64: dts: meson-axg: UART DT updates
From: Yixun Lan @ 2018-01-06 0:10 UTC (permalink / raw)
To: linux-arm-kernel
HI Kevin
These are the UART DT updates for the Meson-AXG platform.
The patch 1 is a general fix.
Other patches are about adding clock & pinctrl info, then using them.
Last patch enable UART_A which connect to a BT module on the S400 board.
Note:
This series depend on previous UART_AO clock switch patch[1]
also, these patch request clocks, so they need the
tag:meson-clk-for-v4.16-2 from clk-meson's tree in order to compile.
Changes since v1 at [2]:
-- fix address range for all platform
-- squash patch 1, 3 (drop compatible & add clock)
-- fix typo in pinctrl info
-- add Jerome's Ack
[1]
http://lkml.kernel.org/r/20171215141741.175985-1-yixun.lan at amlogic.com
[2]
http://lkml.kernel.org/r/20180105095621.196472-1-yixun.lan at amlogic.com
Yixun Lan (5):
ARM64: dts: meson: uart: fix address space range
ARM64: dts: meson-axg: uart: drop legacy compatible name from EE UART
ARM64: dts: meson-axg: uart: Add the pinctrl info description
ARM64: dts: meson-axg: complete the pinctrl info for UART_AO_A
ARM64: dts: meson-axg: enable the UART_A controller
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 9 ++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 109 ++++++++++++++++++++++++-
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 10 +--
3 files changed, 119 insertions(+), 9 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH v2 1/5] ARM64: dts: meson: uart: fix address space range
From: Yixun Lan @ 2018-01-06 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106001044.108163-1-yixun.lan@amlogic.com>
The address space range is actually 0x18, fixed here.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 10 +++++-----
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index a80632641b39..70c776ef7aa7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -165,14 +165,14 @@
uart_A: serial at 24000 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
- reg = <0x0 0x24000 0x0 0x14>;
+ reg = <0x0 0x24000 0x0 0x18>;
interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
uart_B: serial at 23000 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
- reg = <0x0 0x23000 0x0 0x14>;
+ reg = <0x0 0x23000 0x0 0x18>;
interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 6cb3c2a52baf..4ee2e7951482 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -235,14 +235,14 @@
uart_A: serial at 84c0 {
compatible = "amlogic,meson-gx-uart";
- reg = <0x0 0x84c0 0x0 0x14>;
+ reg = <0x0 0x84c0 0x0 0x18>;
interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
uart_B: serial at 84dc {
compatible = "amlogic,meson-gx-uart";
- reg = <0x0 0x84dc 0x0 0x14>;
+ reg = <0x0 0x84dc 0x0 0x18>;
interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
@@ -287,7 +287,7 @@
uart_C: serial at 8700 {
compatible = "amlogic,meson-gx-uart";
- reg = <0x0 0x8700 0x0 0x14>;
+ reg = <0x0 0x8700 0x0 0x18>;
interrupts = <GIC_SPI 93 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
@@ -404,14 +404,14 @@
uart_AO: serial at 4c0 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
- reg = <0x0 0x004c0 0x0 0x14>;
+ reg = <0x0 0x004c0 0x0 0x18>;
interrupts = <GIC_SPI 193 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
uart_AO_B: serial at 4e0 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
- reg = <0x0 0x004e0 0x0 0x14>;
+ reg = <0x0 0x004e0 0x0 0x18>;
interrupts = <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
--
2.15.1
^ permalink raw reply related
* [PATCH v2 2/5] ARM64: dts: meson-axg: uart: drop legacy compatible name from EE UART
From: Yixun Lan @ 2018-01-06 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106001044.108163-1-yixun.lan@amlogic.com>
When update the clock info for the UART controller in the EE domain,
the driver explicitly require 'pclk' in order to work properly.
With current logic of the code, the driver will go for the legacy clock probe
routine[1] if it find current compatible string match to 'amlogic,meson-uart',
which result in not requesting the 'pclk' clock, thus break the driver in the end.
[1] drivers/tty/serial/meson_uart.c:685
/* Use legacy way until all platforms switch to new bindings */
if (of_device_is_compatible(pdev->dev.of_node, "amlogic,meson-uart"))
ret = meson_uart_probe_clocks_legacy(pdev, port);
else
ret = meson_uart_probe_clocks(pdev, port);
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 70c776ef7aa7..644d0f9eaf8c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -164,17 +164,21 @@
};
uart_A: serial at 24000 {
- compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
+ compatible = "amlogic,meson-gx-uart";
reg = <0x0 0x24000 0x0 0x18>;
interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
+ clocks = <&xtal>, <&clkc CLKID_UART0>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
};
uart_B: serial at 23000 {
- compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
+ compatible = "amlogic,meson-gx-uart";
reg = <0x0 0x23000 0x0 0x18>;
interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
+ clocks = <&xtal>, <&clkc CLKID_UART1>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
};
};
--
2.15.1
^ permalink raw reply related
* [PATCH v2 3/5] ARM64: dts: meson-axg: uart: Add the pinctrl info description
From: Yixun Lan @ 2018-01-06 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106001044.108163-1-yixun.lan@amlogic.com>
Describe the pinctrl info for the UART controller which is found
in the Meson-AXG SoCs.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 97 ++++++++++++++++++++++++++++++
1 file changed, 97 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 644d0f9eaf8c..1eb45781c850 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -448,6 +448,70 @@
function = "spi1";
};
};
+
+ uart_a_pins: uart_a {
+ mux {
+ groups = "uart_tx_a",
+ "uart_rx_a";
+ function = "uart_a";
+ };
+ };
+
+ uart_a_cts_rts_pins: uart_a_cts_rts {
+ mux {
+ groups = "uart_cts_a",
+ "uart_rts_a";
+ function = "uart_a";
+ };
+ };
+
+ uart_b_x_pins: uart_b_x {
+ mux {
+ groups = "uart_tx_b_x",
+ "uart_rx_b_x";
+ function = "uart_b";
+ };
+ };
+
+ uart_b_x_cts_rts_pins: uart_b_x_cts_rts {
+ mux {
+ groups = "uart_cts_b_x",
+ "uart_rts_b_x";
+ function = "uart_b";
+ };
+ };
+
+ uart_b_z_pins: uart_b_z {
+ mux {
+ groups = "uart_tx_b_z",
+ "uart_rx_b_z";
+ function = "uart_b";
+ };
+ };
+
+ uart_b_z_cts_rts_pins: uart_b_z_cts_rts {
+ mux {
+ groups = "uart_cts_b_z",
+ "uart_rts_b_z";
+ function = "uart_b";
+ };
+ };
+
+ uart_ao_b_z_pins: uart_ao_b_z {
+ mux {
+ groups = "uart_ao_tx_b_z",
+ "uart_ao_rx_b_z";
+ function = "uart_ao_b_gpioz";
+ };
+ };
+
+ uart_ao_b_z_cts_rts_pins: uart_ao_b_z_cts_rts {
+ mux {
+ groups = "uart_ao_cts_b_z",
+ "uart_ao_rts_b_z";
+ function = "uart_ao_b_gpioz";
+ };
+ };
};
};
@@ -492,12 +556,45 @@
gpio-ranges = <&pinctrl_aobus 0 0 15>;
};
+
remote_input_ao_pins: remote_input_ao {
mux {
groups = "remote_input_ao";
function = "remote_input_ao";
};
};
+
+ uart_ao_a_pins: uart_ao_a {
+ mux {
+ groups = "uart_ao_tx_a",
+ "uart_ao_rx_a";
+ function = "uart_ao_a";
+ };
+ };
+
+ uart_ao_a_cts_rts_pins: uart_ao_a_cts_rts {
+ mux {
+ groups = "uart_ao_cts_a",
+ "uart_ao_rts_a";
+ function = "uart_ao_a";
+ };
+ };
+
+ uart_ao_b_pins: uart_ao_b {
+ mux {
+ groups = "uart_ao_tx_b",
+ "uart_ao_rx_b";
+ function = "uart_ao_b";
+ };
+ };
+
+ uart_ao_b_cts_rts_pins: uart_ao_b_cts_rts {
+ mux {
+ groups = "uart_ao_cts_b",
+ "uart_ao_rts_b";
+ function = "uart_ao_b";
+ };
+ };
};
pwm_AO_ab: pwm at 7000 {
--
2.15.1
^ permalink raw reply related
* [PATCH v2 4/5] ARM64: dts: meson-axg: complete the pinctrl info for UART_AO_A
From: Yixun Lan @ 2018-01-06 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106001044.108163-1-yixun.lan@amlogic.com>
Explictly request the pinctrl info for the UART_AO_A controller,
otherwise we may need to rely on bootloader for the initialization.
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 447b98d30921..9c1b78028ccb 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -26,6 +26,8 @@
&uart_AO {
status = "okay";
+ pinctrl-0 = <&uart_ao_a_pins>;
+ pinctrl-names = "default";
};
&ir {
--
2.15.1
^ permalink raw reply related
* [PATCH v2 5/5] ARM64: dts: meson-axg: enable the UART_A controller
From: Yixun Lan @ 2018-01-06 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106001044.108163-1-yixun.lan@amlogic.com>
The UART_A is connected to a BT module on the S400 board.
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 9c1b78028ccb..d56894dbb209 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -14,6 +14,7 @@
aliases {
serial0 = &uart_AO;
+ serial1 = &uart_A;
};
};
@@ -24,6 +25,12 @@
pinctrl-names = "default";
};
+&uart_A {
+ status = "okay";
+ pinctrl-0 = <&uart_a_pins>;
+ pinctrl-names = "default";
+};
+
&uart_AO {
status = "okay";
pinctrl-0 = <&uart_ao_a_pins>;
--
2.15.1
^ permalink raw reply related
* [GIT PULL] Amlogic 64-bit DT changes for v4.16, round 3
From: Kevin Hilman @ 2018-01-06 0:26 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
A final round of 64-bit DT changes for Amlogic SoCs.
These were just waiting for the clock dependencies to land in the clock
tree which they now have. I've merged the same tag into this branch to
avoid any dependency issues.
Thanks,
Kevin
The following changes since commit 43b9f617b5f98f2f7abb508fef5e535e5fb66a41:
arm64: dts: meson-axg: add new reset DT node (2017-12-15 16:20:29 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64-3
for you to fetch changes up to f6f6ac914b82402b910b783cd13bf72de067f69f:
ARM64: dts: meson-axg: enable ethernet for A113D S400 board (2018-01-05 15:27:31 -0800)
----------------------------------------------------------------
Another round of 64-bit DT changes for the new Amlogic SoCs. These
include IR, SPI and ethernet MAC support for the new AXG family SoCs.
----------------------------------------------------------------
Kevin Hilman (1):
Merge tag 'meson-clk-headers-for-v4.16-2' of git://github.com/BayLibre/clk-meson into v4.16/dt64
Qiufang Dai (1):
clk: meson-axg: add clocks dt-bindings required header
Sunny Luo (1):
ARM64: dts: meson-axg: add the SPICC controller
Yixun Lan (5):
dt-bindings: clock: add compatible variant for the Meson-AXG
arm64: dts: meson-axg: switch uart_ao clock to CLK81
ARM64: dts: meson-axg: enable IR controller
ARM64: dts: meson-axg: add ethernet mac controller
ARM64: dts: meson-axg: enable ethernet for A113D S400 board
Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt | 7 +++--
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 13 ++++++++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
include/dt-bindings/clock/axg-clkc.h | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 251 insertions(+), 4 deletions(-)
create mode 100644 include/dt-bindings/clock/axg-clkc.h
^ 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