* [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default
From: Philipp Zabel @ 2017-04-13 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c22519f-64f8-7213-d458-23470bdd5ecd@xs4all.nl>
On Wed, 2017-04-12 at 09:03 +0200, Hans Verkuil wrote:
[...]
> >> Do you have a git tree with this patch? It is really hard to review without
> >> having the full imx-media-csi.c source.
> >
> > The patch applies on top of
> >
> > https://github.com/slongerbeam/mediatree.git imx-media-staging-md-v14
> >
> > I have uploaded a branch
> >
> > git://git.pengutronix.de/git/pza/linux imx-media-staging-md-v14+color
> >
> > with the patch applied on top.
> >
> >> I think one problem is that it is not clearly defined how subdevs and colorspace
> >> information should work.
>
> Ah, having the full source helped.
>
> Ignore my previous review, it was incorrect.
Ok.
> I'll have to think about this some more. I'll get back to this, but it may take some
> time since my vacation starts tomorrow. The spec is simply unclear about how to handle
> this so we have to come up with some guidelines.
Yes, please. Until then, have a nice vacation.
regards
Philipp
^ permalink raw reply
* [RFC PATCH 0/3] arm64: queued spinlocks and rw-locks
From: Yury Norov @ 2017-04-13 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a4f067df-4c22-5c90-d70a-809903c60296@codeaurora.org>
On Wed, Apr 12, 2017 at 01:04:55PM -0400, Adam Wallis wrote:
> On 4/10/2017 5:35 PM, Yury Norov wrote:
> > The patch of Jan Glauber enables queued spinlocks on arm64. I rebased it on
> > latest kernel sources, and added a couple of fixes to headers to apply it
> > smoothly.
> >
> > Though, locktourture test shows significant performance degradation in the
> > acquisition of rw-lock for read on qemu:
> >
> > Before After
> > spin_lock-torture: 38957034 37076367 -4.83
> > rw_lock-torture W: 5369471 18971957 253.33
> > rw_lock-torture R: 6413179 3668160 -42.80
> >
>
> On our 48 core QDF2400 part, I am seeing huge improvements with these patches on
> the torture tests. The improvements go up even further when I apply Jason Low's
> MCS Spinlock patch: https://lkml.org/lkml/2016/4/20/725
It sounds great. So performance issue is looking like my local
problem, most probably because I ran tests on Qemu VM.
I don't see any problems with this series, other than performance,
and if it looks fine now, I think it's good enough for upstream.
Yury.
^ permalink raw reply
* Testing kexec/kdump on ls2085ardb (arm64)
From: Denys Zagorui @ 2017-04-13 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b34ce5cb-82d3-a706-0a0b-98828ebb4417@redhat.com>
On 12.04.17 19:36, Pratyush Anand wrote:
> Hi Denys,
>
> On Wednesday 12 April 2017 08:05 PM, Denys Zagorui wrote:
>> Hello, Pratyush
>> Thanks for your reply.
>>
>> Could you describe how i can find out wich enable method used. One more
>> things, i made this tests on qemu, and it works. Logs attached.
>>
>
> From your board log (log_for_com ):
>
> PSCI: PSCI does not exist
>
>
> and then
>
> [ 60.561877] Can't kexec: CPUs are stuck in the kernel.
>
> Above message is coming from machine_kexec_prepare() when
> cpus_are_stuck_in_kernel() returns true. See, its implementation. It
> will return true if number of possible cpus is > 1 and cpu_die() is not
> implemented.
>
> You can boot your first kernel with nr_cpus=1 in kernel cmdline and
> then you should be able to kexec to the second kernel from there.
>
> However, it can not be a solution. You should update your firmware with
> psci implementation.
>
> For the time being you can have spin-table work aroudn like this [1],
> but please note that spin-table is discouraged upstream [2].
>
> [1]
> https://github.com/pratyushanand/linux/commit/a50e98635b7257c101f02f7ac488a4cb04187f6d
>
> [2] https://patchwork.kernel.org/patch/7873571/
>
>
> From your qemu log:
>
> [ 0.000000] psci: probing for conduit method from DT.
> [ 0.000000] psci: PSCIv0.2 detected in firmware.
> [ 0.000000] psci: Using standard PSCI v0.2 function IDs
> [ 0.000000] psci: Trusted OS migration not required
>
>
> and so it works :-)
>
>
> ~Pratyush
Hi Pratyush
Both solutions works. Thanks. It's temporary solution,
i will contact with NXP support team
Best Regards,
Denys
--
Denys Zagorui
GlobalLogic
Kyiv, 03038, Protasov Business Park, N.Grinchenka, 2/1
M +38.067.317.30.93
www.globallogic.com
http://www.globallogic.com/email_disclaimer.txt
^ permalink raw reply
* [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt
From: Mark Rutland @ 2017-04-13 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1490869877-118713-8-git-send-email-xiexiuqi@huawei.com>
Hi,
On Thu, Mar 30, 2017 at 06:31:07PM +0800, Xie XiuQi wrote:
> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
> index f20c64a..22f9c90 100644
> --- a/arch/arm64/include/asm/esr.h
> +++ b/arch/arm64/include/asm/esr.h
> @@ -106,6 +106,20 @@
> #define ESR_ELx_AR (UL(1) << 14)
> #define ESR_ELx_CM (UL(1) << 8)
>
> +#define ESR_Elx_DFSC_SEI (0x11)
We should probably have a definition for the uncategorized DFSC value,
too.
[...]
> index 43512d4..d8a7306 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -69,7 +69,14 @@
> #define BAD_FIQ 2
> #define BAD_ERROR 3
>
> + .arch_extension ras
Generally, arch_extension is a warning sign that code isn't going to
work with contemporary assemblers, which we likely need to support.
> +
> .macro kernel_entry, el, regsize = 64
> +#ifdef CONFIG_ARM64_ESB
> + .if \el == 0
> + esb
Here, I think that we'll need to macro this such that we can build with
existing toolchains.
e.g. in <asm/assembler.h> we need something like:
#define HINT_IMM_ESB 16
.macro ESB
hint #HINT_IMM_ESB
.endm
> + .endif
> +#endif
> sub sp, sp, #S_FRAME_SIZE
> .if \regsize == 32
> mov w0, w0 // zero upper 32 bits of x0
> @@ -208,6 +215,7 @@ alternative_else_nop_endif
> #endif
>
> .if \el == 0
> + msr daifset, #0xF // Set flags
Elsewhere in head.S we use helpers to fiddle with DAIF bits.
Please be consistent with that. Add an enable_all macro if we need one.
> ldr x23, [sp, #S_SP] // load return stack pointer
> msr sp_el0, x23
> #ifdef CONFIG_ARM64_ERRATUM_845719
> @@ -226,6 +234,15 @@ alternative_else_nop_endif
>
> msr elr_el1, x21 // set up the return data
> msr spsr_el1, x22
> +
> +#ifdef CONFIG_ARM64_ESB
> + .if \el == 0
> + esb // Error Synchronization Barrier
> + mrs x21, disr_el1 // Check for deferred error
We'll need an <asm/sysreg.h> definition for this register. With that, we
can use mrs_s here.
> + tbnz x21, #31, el1_sei
> + .endif
> +#endif
> +
> ldp x0, x1, [sp, #16 * 0]
> ldp x2, x3, [sp, #16 * 1]
> ldp x4, x5, [sp, #16 * 2]
> @@ -318,7 +335,7 @@ ENTRY(vectors)
> ventry el1_sync_invalid // Synchronous EL1t
> ventry el1_irq_invalid // IRQ EL1t
> ventry el1_fiq_invalid // FIQ EL1t
> - ventry el1_error_invalid // Error EL1t
> + ventry el1_error // Error EL1t
>
> ventry el1_sync // Synchronous EL1h
> ventry el1_irq // IRQ EL1h
> @@ -328,7 +345,7 @@ ENTRY(vectors)
> ventry el0_sync // Synchronous 64-bit EL0
> ventry el0_irq // IRQ 64-bit EL0
> ventry el0_fiq_invalid // FIQ 64-bit EL0
> - ventry el0_error_invalid // Error 64-bit EL0
> + ventry el0_error // Error 64-bit EL0
>
> #ifdef CONFIG_COMPAT
> ventry el0_sync_compat // Synchronous 32-bit EL0
> @@ -508,12 +525,31 @@ el1_preempt:
> ret x24
> #endif
>
> + .align 6
> +el1_error:
> + kernel_entry 1
> +el1_sei:
> + /*
> + * asynchronous SError interrupt from kernel
> + */
> + mov x0, sp
> + mrs x1, esr_el1
I don't think this is correct if we branched here from kernel_exit.
Surely we want the DISR_EL1 value, and ESR_EL1 is unrelated?
> + mov x2, #1 // exception level of SEI generated
> + b do_sei
You don't need to figure out the EL here. In do_sei() we can determine
the exception level from the regs (e.g. using user_mode(regs)).
> +ENDPROC(el1_error)
> +
> +
> /*
> * EL0 mode handlers.
> */
> .align 6
> el0_sync:
> kernel_entry 0
> +#ifdef CONFIG_ARM64_ESB
> + mrs x26, disr_el1
> + tbnz x26, #31, el0_sei // check DISR.A
> + msr daifclr, #0x4 // unmask SEI
> +#endif
Why do we duplicate this across the EL0 handlers, rather than making it
common in the el0 kernel_entry code?
> mrs x25, esr_el1 // read the syndrome register
> lsr x24, x25, #ESR_ELx_EC_SHIFT // exception class
> cmp x24, #ESR_ELx_EC_SVC64 // SVC in 64-bit state
> @@ -688,8 +724,38 @@ el0_inv:
> ENDPROC(el0_sync)
>
> .align 6
> +el0_error:
> + kernel_entry 0
> +el0_sei:
> + /*
> + * asynchronous SError interrupt from userspace
> + */
> + ct_user_exit
> + mov x0, sp
> + mrs x1, esr_el1
As with el1_sei, I don't think this is correct if we branched to
el0_sei. As far as I am aware, ESR_EL1 will contain whatever exception
we took, and the value we want is in DISR_EL1.
> + mov x2, #0
This EL parameter can go.
> + bl do_sei
> + b ret_to_user
> +ENDPROC(el0_error)
> +
> + .align 6
> el0_irq:
> kernel_entry 0
> +#ifdef CONFIG_ARM64_ESB
> + mrs x26, disr_el1
> + tbz x26, #31, el0_irq_naked // check DISR.A
> +
> + mov x0, sp
> + mrs x1, esr_el1
> + mov x2, 0
> +
> + /*
> + * The SEI generated at EL0 is not affect this irq context,
> + * so after sei handler, we continue process this irq.
> + */
> + bl do_sei
> + msr daifclr, #0x4 // unmask SEI
This rough pattern is duplicated several times across the EL0 entry
paths. I think it should be made common.
> +#endif
> el0_irq_naked:
> enable_dbg
> #ifdef CONFIG_TRACE_IRQFLAGS
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index b6d6727..99be6d8 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -643,6 +643,34 @@ asmlinkage void bad_mode(struct pt_regs *regs, int reason, unsigned int esr)
> handler[reason], smp_processor_id(), esr,
> esr_get_class_string(esr));
>
> + die("Oops - bad mode", regs, 0);
> + local_irq_disable();
> + panic("bad mode");
> +}
> +
> +static const char *sei_context[] = {
> + "userspace", /* EL0 */
> + "kernel", /* EL1 */
> +};
This should go. It's only used in one place, and would be clearer with
the strings inline. More on that below.
> +
> +static const char *sei_severity[] = {
Please name this for what it actually represents:
static const char *esr_aet_str[] = {
> + [0 ... ESR_ELx_AET_MAX] = "Unknown",
For consistency with esr_class_str, please make this:
[0 ... ESR_ELx_AET_MAX] = "UNRECOGNIZED AET",
... which makes it clear that this isn't some AET value which reports an
"Unknown" status.
> + [ESR_ELx_AET_UC] = "Uncontainable",
> + [ESR_ELx_AET_UEU] = "Unrecoverable",
> + [ESR_ELx_AET_UEO] = "Restartable",
> + [ESR_ELx_AET_UER] = "Recoverable",
> + [ESR_ELx_AET_CE] = "Corrected",
> +};
> +
> +DEFINE_PER_CPU(int, sei_in_process);
A previous patch added definition of this.
> +asmlinkage void do_sei(struct pt_regs *regs, unsigned int esr, int el)
> +{
> + int aet = ESR_ELx_AET(esr);
The AET field is only valid when the DFSC is 0b010001, so we need to
check that before we interpret AET.
> + console_verbose();
> +
> + pr_crit("Asynchronous SError interrupt detected on CPU%d, %s, %s\n",
> + smp_processor_id(), sei_context[el], sei_severity[aet]);
We should dump the full ESR_ELx value, regardless of what automated
decoding we do, so that we have a chance of debugging issues in the
field.
It would also be nice to align with how bad_mode reports this today.
Please make this:
pr_crit("SError detected on CPU%d while in %s mode: code: 0x%08x -- %s\n",
smp_processor_id(), user_mode(regs) ? "user" : "kernel",
esr, esr_aet_str[aet]);
... though it might be best to dump the raw SPSR rather than trying to
say user/kernel, so that we can distinguish EL1/EL2 with VHE, etc.
> +
> /*
> * In firmware first mode, we could assume firmware will only generate one
> * of cper records at a time. There is no risk for one cpu to parse ghes table.
> @@ -653,9 +681,31 @@ asmlinkage void bad_mode(struct pt_regs *regs, int reason, unsigned int esr)
> this_cpu_dec(sei_in_process);
> }
>
> - die("Oops - bad mode", regs, 0);
> + if (el == 0 && IS_ENABLED(CONFIG_ARM64_ESB) &&
Please use user_mode(regs), and get rid of the el parameter to this
function entirely.
> + cpus_have_cap(ARM64_HAS_RAS_EXTN)) {
> + siginfo_t info;
> + void __user *pc = (void __user *)instruction_pointer(regs);
> +
> + if (aet >= ESR_ELx_AET_UEO)
> + return;
We need to check the DFSC first, and 0b111 is a reserved value (which
the ARM ARM doesn't define the recoverability of), so I don't think this
is correct.
We should probably test the DSFC, then switch on the AET value, so as to
handle only the cases we are aware of.
> +
> + if (aet == ESR_ELx_AET_UEU) {
> + info.si_signo = SIGILL;
> + info.si_errno = 0;
> + info.si_code = ILL_ILLOPC;
> + info.si_addr = pc;
An unrecoverable error is not necessarily a particular bad instruction,
so I'm not sure this makes sense.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC
From: Corentin Labbe @ 2017-04-13 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492067108-14748-3-git-send-email-sean.wang@mediatek.com>
Hello
I have some minor comment below:
On Thu, Apr 13, 2017 at 03:05:08PM +0800, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> This patch adds support for hardware random generator on MT7623 SoC
> and should also work on other similar Mediatek SoCs. Currently,
> the driver is already tested successfully with rng-tools.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
> drivers/char/hw_random/Kconfig | 16 +++-
> drivers/char/hw_random/Makefile | 2 +-
> drivers/char/hw_random/mtk-rng.c | 174 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 190 insertions(+), 2 deletions(-)
> create mode 100644 drivers/char/hw_random/mtk-rng.c
>
> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> index 0cafe08..af782ce 100644
> --- a/drivers/char/hw_random/Kconfig
> +++ b/drivers/char/hw_random/Kconfig
> @@ -419,10 +419,24 @@ config HW_RANDOM_CAVIUM
> Generator hardware found on Cavium SoCs.
>
> To compile this driver as a module, choose M here: the
> - module will be called cavium_rng.
> + module will be called mtk-rng.
Unwanted change
>
> If unsure, say Y.
>
> +config HW_RANDOM_MTK
> + tristate "Mediatek Random Number Generator support"
> + depends on HW_RANDOM
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + default y
> + ---help---
> + This driver provides kernel-side support for the Random Number
> + Generator hardware found on Mediatek SoCs.
> +
> + To compile this driver as a module, choose M here. the
> + module will be called mtk-rng.
> +
> + If unsure, say Y.
> +
> endif # HW_RANDOM
>
> config UML_RANDOM
> diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
> index 5f52b1e..68be716 100644
> --- a/drivers/char/hw_random/Makefile
> +++ b/drivers/char/hw_random/Makefile
> @@ -1,7 +1,6 @@
> #
> # Makefile for HW Random Number Generator (RNG) device drivers.
> #
> -
Another unwanted change
> obj-$(CONFIG_HW_RANDOM) += rng-core.o
> rng-core-y := core.o
> obj-$(CONFIG_HW_RANDOM_TIMERIOMEM) += timeriomem-rng.o
> @@ -36,3 +35,4 @@ obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
> obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
> obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
> obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.o
> +obj-$(CONFIG_HW_RANDOM_MTK) += mtk-rng.o
> diff --git a/drivers/char/hw_random/mtk-rng.c b/drivers/char/hw_random/mtk-rng.c
> new file mode 100644
> index 0000000..6561ee0
> --- /dev/null
> +++ b/drivers/char/hw_random/mtk-rng.c
> @@ -0,0 +1,174 @@
> +/*
> + * Driver for Mediatek Hardware Random Number Generator
> + *
> + * Copyright (C) 2017 Sean Wang <sean.wang@mediatek.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#define MTK_RNG_DEV KBUILD_MODNAME
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/hw_random.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +
> +#define USEC_POLL 2
> +#define TIMEOUT_POLL 20
> +
> +#define RNG_CTRL 0x00
> +#define RNG_EN BIT(0)
> +#define RNG_READY BIT(31)
Keep only one space between define and name
> +
> +#define RNG_DATA 0x08
> +
> +#define to_mtk_rng(p) container_of(p, struct mtk_rng, rng)
> +
> +struct mtk_rng {
> + struct device *dev;
> + void __iomem *base;
> + struct clk *clk;
> + struct hwrng rng;
> +};
> +
> +static int mtk_rng_init(struct hwrng *rng)
> +{
> + struct mtk_rng *priv = to_mtk_rng(rng);
> + u32 val;
> + int err;
> +
> + err = clk_prepare_enable(priv->clk);
> + if (err)
> + return err;
> +
> + val = readl(priv->base + RNG_CTRL);
> + val |= RNG_EN;
> + writel(val, priv->base + RNG_CTRL);
> +
> + return 0;
> +}
> +
> +static void mtk_rng_cleanup(struct hwrng *rng)
> +{
> + struct mtk_rng *priv = to_mtk_rng(rng);
> + u32 val;
> +
> + val = readl(priv->base + RNG_CTRL);
> + val &= ~RNG_EN;
> + writel(val, priv->base + RNG_CTRL);
> +
> + clk_disable_unprepare(priv->clk);
> +}
> +
> +static bool mtk_rng_wait_ready(struct hwrng *rng, bool wait)
> +{
> + struct mtk_rng *priv = to_mtk_rng(rng);
> + int ready;
> +
> + ready = readl(priv->base + RNG_CTRL) & RNG_READY;
> + if (!ready && wait)
> + readl_poll_timeout_atomic(priv->base + RNG_CTRL, ready,
> + ready & RNG_READY, USEC_POLL,
> + TIMEOUT_POLL);
> + return !!ready;
> +}
> +
> +static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> +{
> + struct mtk_rng *priv = to_mtk_rng(rng);
> + int retval = 0;
> +
> + while (max >= sizeof(u32)) {
> + if (!mtk_rng_wait_ready(rng, wait))
> + break;
> +
> + *(u32 *)buf = readl(priv->base + RNG_DATA);
> + retval += sizeof(u32);
> + buf += sizeof(u32);
> + max -= sizeof(u32);
> + }
> +
> + if (unlikely(wait && max))
> + dev_warn(priv->dev, "timeout might be not properly set\n");
> +
> + return retval || !wait ? retval : -EIO;
> +}
> +
> +static int mtk_rng_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + int ret;
> + struct mtk_rng *priv;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(&pdev->dev, "no iomem resource\n");
> + return -ENXIO;
> + }
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = &pdev->dev;
> + priv->rng.name = pdev->name;
> + priv->rng.init = mtk_rng_init;
> + priv->rng.cleanup = mtk_rng_cleanup;
> + priv->rng.read = mtk_rng_read;
> +
> + priv->clk = devm_clk_get(&pdev->dev, "rng");
> + if (IS_ERR(priv->clk)) {
> + ret = PTR_ERR(priv->clk);
> + dev_err(&pdev->dev, "no clock for device: %d\n", ret);
> + return ret;
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
You get that resource twice
Regards
Corentin Labbe
^ permalink raw reply
* [RFC PATCH] of: Fix DMA configuration for non-DT masters
From: Oza Oza @ 2017-04-13 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b02ace9b-f8f3-269d-6db4-3c1b1ea1e816@arm.com>
On Wed, Mar 29, 2017 at 11:12 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 29/03/17 06:46, Oza Oza wrote:
>> On Wed, Mar 29, 2017 at 10:23 AM, Oza Oza <oza.oza@broadcom.com> wrote:
>>> On Wed, Mar 29, 2017 at 12:27 AM, Robin Murphy <robin.murphy@arm.com> wrote:
>>>> For PCI masters not represented in DT, we pass the OF node of their
>>>> associated host bridge to of_dma_configure(), such that they can inherit
>>>> the appropriate DMA configuration from whatever is described there.
>>>> Unfortunately, whilst this has worked for the "dma-coherent" property,
>>>> it turns out to miss the case where the host bridge node has a non-empty
>>>> "dma-ranges", since nobody is expecting the 'device' to be a bus itself.
>>>>
>>>> It transpires, though, that the de-facto interface since the prototype
>>>> change in 1f5c69aa51f9 ("of: Move of_dma_configure() to device.c to help
>>>> re-use") is very clear-cut: either the master_np argument is redundant
>>>> with dev->of_node, or dev->of_node is NULL and master_np is the relevant
>>>> parent bus. Let's ratify that behaviour, then teach the whole
>>>> of_dma_configure() pipeline to cope with both cases properly.
>>>>
>>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>
> [...]
>
>>>
>>> pci and memory mapped device world is different.
>
> ???
>
> No they aren't. There is nothing magic about PCI. PCI *is* a
> memory-mapped bus.
>
> The only PCI-specific aspect here is the Linux code path which passes a
> host controller node into of_dma_configure() where the latter expects a
> node for the actual endpoint device. It managed to work for
> "dma-coherent", because that may appear either directly on a device node
> or on any of its parent buses, but "dma-ranges" is *only* valid for DT
> nodes representing buses, thus reveals that using a parent bus to stand
> in for a device isn't actually correct. I only posted that horrible hack
> patch to prove the point that having a child node to represent the
> actual device is indeed sufficient to make of_dma_configure() work
> correctly for PCI masters as-is (modulo the other issues).
>
>> of course if you talk
>>> from iommu perspective, all the master are same for IOMMU
>
> I don't understand what you mean by that. There's nothing about IOMMUs
> here, it's purely about parsing DT properties correctly.
>
>>> but the original intention of the patch is to try to solve 2 problems.
>>> please refer to https://lkml.org/lkml/2017/3/29/10
>
> One patch should not solve two separate problems anyway. Taking a step
> back, there are at least 3 things that this discussion has brought up:
>
> 1) The way in which we call of_dma_configure() for PCI devices causes
> the "dma-ranges" property on PCI host controllers to be ignored.
>
> 2) of_dma_get_range() only considers the first entry in any "dma-ranges"
> property.
>
> 3) When of_dma_configure() does set a DMA mask, there is nothing on
> arm64 and other architectures to prevent drivers overriding that with a
> wider mask later.
>
> Those are 3 separate problems, to solve with 3 or more separate patches,
> and I have deliberately put the second and third to one side for the
> moment. This patch fixes problem 1.
>
>>> 1) expose generic API for pci world clients to configure their
>>> dma-ranges. right now there is none.
>>> 2) same API can be used by IOMMU to derive dma_mask.
>>>
>>> while the current patch posted to handle dma-ranges for both memory
>>> mapped and pci devices, which I think is overdoing.
>
> No, of_dma_configure() handles the "dma-ranges" property as it is
> defined in the DT spec to describe the mapping between a child bus
> address space and a parent bus address space. Whether those
> memory-mapped parent and child buses are PCI, ISA, AMBA, HyperTransport,
> or anything else is irrelevant other than for the encoding of the
> address specifiers. All this patch does is sort out the cases where we
> have a real device node to start at, from the cases where we don't and
> so start directly at the device's parent bus node instead.
>
>>> besides we have different configuration of dma-ranges based on iommu
>>> is enabled or not enabled.
>
> That doesn't sound right, unless you mean the firmware actually programs
> the host controller's AXI bridge differently for system configurations
> where the IOMMU is expected to be used or not? (and even then, I don't
> really see why it would be necessary to do that...)
>
>>> #define PCIE_DMA_RANGES dma-ranges = <0x43000000 0x00 0x80000000 0x00
>>> 0x80000000 0x00 0x80000000 \
>>> 0x43000000 0x08 0x00000000 0x08
>>> 0x00000000 0x08 0x00000000 \
>>> 0x43000000 0x80 0x00000000 0x80
>>> 0x00000000 0x40 0x00000000>;
>>> Not sure if this patch will consider above dma-ranges.
>>>
>>> my suggestion is to leave existing of_dma_get_range as is, and have
>>> new function for pci world as discussed in
>>> please refer to https://lkml.org/lkml/2017/3/29/10
>
> And then we keep adding new functions to do the exact same thing for
> every other discoverable bus type whose bridge is be described in DT? I
> fail to see how that is in any way better than simply fixing the
> existing code to work as it was intended to.
>
> of_dma_get_ranges() uses of_translate_dma_address() just the same way as
> existing PowerPC PCI code does, which further disproves your assertion
> that parsing PCI addresses is somehow special - it's really only a
> matter of getting the right number of address cells in order to to read
> a child address to give to of_translate_dma_address() in the first
> place. Incidentally, I now notice that the proposed
> of_pci_get_dma_ranges() is incomplete as it doesn't use
> of_translate_dma_address() or otherwise traverse upwards through the
> dma-ranges of any further parent buses.
>
>>>
>>> Regards,
>>> Oza.
>>
>> also I see that, in case of multiple ranges of_dma_get_range doesnt handle that.
>> and also it is not meant to handle.
>
> Yes, the existing code doesn't handle multiple dma-ranges entries,
> because nobody's had the need to implement that so far, and this patch
> does not change that because it's fixing a separate problem.
>
> Now, of course of_dma_get_range() *should* be capable of handling
> multiple entries regardless of this patch, and I'm going to write *that*
> patch right now (it's going to be a case of adding a handful of lines
> which probably won't even conflict with this one at all). If we had a
> bunch of different range parsing functions, we'd then have to duplicate
> the equivalent logic across all of them, which is clearly undesirable
> when it can easily be avoided altogether.
>
> Robin.
>
>> so with this patch will return wrong size and hence wrong dma_mask.
>> having said, I think it is better to separate pci world dma-ranges
>> function on of_pci.c
>>
>> for which my discussion with Rob already, (same thread)
>> https://lkml.org/lkml/2017/3/29/10
>> Waiting for Rob's viewpoint on this.
>>
>>
>> Regards,
>> Oza.
>>
>
first of all the patch
https://lkml.org/lkml/2017/3/30/304
is not only to address the original problem of dma_mask but also to
provide generic APIs
to PCI RC drivers such as pcie-iproc.c or even rcar to get their dma-ranges.
this API not only provides basis to retrieve the ranges but also it
should have capability to handle
inbound memory flags.
having said that the PCI dma-ranges do differ slightly from
traditional memory ranges.
because it has got flags.
now those flags could be IORESOURCE_CACHEABLE or anything else.
our SOC will be having use of these flags in near future (although can
not discuss details as of now).
but in short we will need these flags to be taken care which were
passed form DT.
so PCIe iproc driver calls this function to get all teh information
about dma-ranges.
now if such function exists, other framework could also make use of it
to get resources and figure out dma_mask.
and in that case you really need not change of_dma_get_range.
not only of_dma_get_range can hdnle PCI flags property but also it can
not handle multiple ranges because finally it has only
single *dma_addr, *paddr, *size out parameters.
so the burdon will be on API to fix the behavior as what to return
rather than having Caller to choose what to do with the ranges.
coming back to my current patch
currently it does not do flag handling, but in near future I will have
to add, but for that, this patch
https://lkml.org/lkml/2017/3/30/304
needs to bring under consideration to be ACKed.
hope this explains the need of API.
Regards,
Oza.
^ permalink raw reply
* [PATCH 1/2] phy: qcom-usb-hs: Replace the extcon API
From: Kishon Vijay Abraham I @ 2017-04-13 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1490675909-2533-1-git-send-email-cw00.choi@samsung.com>
Hi Chanwoo,
On Tuesday 28 March 2017 10:08 AM, Chanwoo Choi wrote:
> This patch uses the resource-managed extcon API for extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - (deprecated) extcon_get_cable_state_() -> extcon_get_state()
>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
I've missed merging this patch for the next merge window. If you want to take
this yourself.
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Thanks
Kishon
> ---
> drivers/phy/phy-qcom-usb-hs.c | 14 +++-----------
> 1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/phy/phy-qcom-usb-hs.c b/drivers/phy/phy-qcom-usb-hs.c
> index 94dfbfd739c3..f630fa553b7d 100644
> --- a/drivers/phy/phy-qcom-usb-hs.c
> +++ b/drivers/phy/phy-qcom-usb-hs.c
> @@ -156,12 +156,12 @@ static int qcom_usb_hs_phy_power_on(struct phy *phy)
> }
>
> if (uphy->vbus_edev) {
> - state = extcon_get_cable_state_(uphy->vbus_edev, EXTCON_USB);
> + state = extcon_get_state(uphy->vbus_edev, EXTCON_USB);
> /* setup initial state */
> qcom_usb_hs_phy_vbus_notifier(&uphy->vbus_notify, state,
> uphy->vbus_edev);
> - ret = extcon_register_notifier(uphy->vbus_edev, EXTCON_USB,
> - &uphy->vbus_notify);
> + ret = devm_extcon_register_notifier(&ulpi->dev, uphy->vbus_edev,
> + EXTCON_USB, &uphy->vbus_notify);
> if (ret)
> goto err_ulpi;
> }
> @@ -180,16 +180,8 @@ static int qcom_usb_hs_phy_power_on(struct phy *phy)
>
> static int qcom_usb_hs_phy_power_off(struct phy *phy)
> {
> - int ret;
> struct qcom_usb_hs_phy *uphy = phy_get_drvdata(phy);
>
> - if (uphy->vbus_edev) {
> - ret = extcon_unregister_notifier(uphy->vbus_edev, EXTCON_USB,
> - &uphy->vbus_notify);
> - if (ret)
> - return ret;
> - }
> -
> regulator_disable(uphy->v3p3);
> regulator_disable(uphy->v1p8);
> clk_disable_unprepare(uphy->sleep_clk);
>
^ permalink raw reply
* [PATCH 2/2] phy: rockchip-inno-usb2: Replace the extcon API
From: Kishon Vijay Abraham I @ 2017-04-13 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1490675909-2533-2-git-send-email-cw00.choi@samsung.com>
On Tuesday 28 March 2017 10:08 AM, Chanwoo Choi wrote:
> This patch uses the resource-managed extcon API for extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
> - extcon_set_cable_state_() -> extcon_set_state_sync()
>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: linux-rockchip at lists.infradead.org
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
for this too:
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/phy/phy-rockchip-inno-usb2.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c
> index 4ea95c28a66f..02751f70067e 100644
> --- a/drivers/phy/phy-rockchip-inno-usb2.c
> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
> @@ -540,7 +540,7 @@ static void rockchip_usb2phy_otg_sm_work(struct work_struct *work)
> rockchip_usb2phy_power_off(rport->phy);
> /* fall through */
> case OTG_STATE_B_IDLE:
> - if (extcon_get_cable_state_(rphy->edev, EXTCON_USB_HOST) > 0) {
> + if (extcon_get_state(rphy->edev, EXTCON_USB_HOST) > 0) {
> dev_dbg(&rport->phy->dev, "usb otg host connect\n");
> rport->state = OTG_STATE_A_HOST;
> rockchip_usb2phy_power_on(rport->phy);
> @@ -596,7 +596,7 @@ static void rockchip_usb2phy_otg_sm_work(struct work_struct *work)
> rport->vbus_attached = vbus_attach;
>
> if (notify_charger && rphy->edev) {
> - extcon_set_cable_state_(rphy->edev,
> + extcon_set_state_sync(rphy->edev,
> cable, vbus_attach);
> if (cable == EXTCON_CHG_USB_SDP)
> extcon_set_state_sync(rphy->edev,
> @@ -617,7 +617,7 @@ static void rockchip_usb2phy_otg_sm_work(struct work_struct *work)
> sch_work = true;
> break;
> case OTG_STATE_A_HOST:
> - if (extcon_get_cable_state_(rphy->edev, EXTCON_USB_HOST) == 0) {
> + if (extcon_get_state(rphy->edev, EXTCON_USB_HOST) == 0) {
> dev_dbg(&rport->phy->dev, "usb otg host disconnect\n");
> rport->state = OTG_STATE_B_IDLE;
> rockchip_usb2phy_power_off(rport->phy);
> @@ -1003,8 +1003,8 @@ static int rockchip_usb2phy_otg_port_init(struct rockchip_usb2phy *rphy,
> if (!IS_ERR(rphy->edev)) {
> rport->event_nb.notifier_call = rockchip_otg_event;
>
> - ret = extcon_register_notifier(rphy->edev, EXTCON_USB_HOST,
> - &rport->event_nb);
> + ret = devm_extcon_register_notifier(rphy->dev, rphy->edev,
> + EXTCON_USB_HOST, &rport->event_nb);
> if (ret)
> dev_err(rphy->dev, "register USB HOST notifier failed\n");
> }
>
^ permalink raw reply
* kvm/arm64: use-after-free in kvm_unmap_hva_handler/unmap_stage2_pmds
From: Andrey Konovalov @ 2017-04-13 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413093418.GC24027@leverpostej>
On Thu, Apr 13, 2017 at 11:34 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Apr 12, 2017 at 08:51:31PM +0200, Andrey Konovalov wrote:
>> On Wed, Apr 12, 2017 at 8:43 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> > On 12/04/17 17:19, Andrey Konovalov wrote:
>
>> >> I now have a way to reproduce it, so I can test proposed patches. I
>> >> don't have a simple C reproducer though.
>> >>
>> >> The bug happens when the following syzkaller program is executed:
>> >>
>> >> mmap(&(0x7f0000000000/0xc000)=nil, (0xc000), 0x3, 0x32, 0xffffffffffffffff, 0x0)
>> >> unshare(0x400)
>> >> perf_event_open(&(0x7f000002f000-0x78)={0x1, 0x78, 0x0, 0x0, 0x0, 0x0,
>> >> 0x0, 0x6, 0x0, 0x0, 0xd34, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> >> 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, 0x0, 0xffffffff,
>> >> 0xffffffffffffffff, 0x0)
>> >> r0 = openat$kvm(0xffffffffffffff9c,
>> >> &(0x7f000000c000-0x9)="2f6465762f6b766d00", 0x0, 0x0)
>> >> ioctl$TIOCSBRK(0xffffffffffffffff, 0x5427)
>> >> r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0)
>> >> syz_kvm_setup_cpu$arm64(r1, 0xffffffffffffffff,
>> >> &(0x7f0000dc6000/0x18000)=nil, &(0x7f000000c000)=[{0x0,
>> >> &(0x7f000000c000)="5ba3c16f533efbed09f8221253c73763327fadce2371813b45dd7f7982f84a873e4ae89a6c2bd1af83a6024c36a1ff518318",
>> >> 0x32}], 0x1, 0x0, &(0x7f000000d000-0x10)=[@featur2={0x1, 0x3}], 0x1)
>> >
>> > Is that the only thing the program does? Or is there anything running in
>> > parallel?
>>
>> These calls are executed repeatedly and in random order. That's all.
>>
>> Except that I'm running the reproducer on a real arm board, so there's
>> probably a bunch of stuff going on besides these calls.
>
> I had a go at reproducing this on an arm64 board following [1], but so
> far I've had no luck. I've dumped the above into syz-kvm-bug, and I'm
> trying to reproduce the issue with:
>
> PATH=$PATH:$(pwd)/bin syz-execprog \
> -executor $(pwd)/bin/syz-executor \
> -cover=0 -repeat=0 -procs 16 \
> syz-kvm-bug
>
> Just to check, is that the correct way to reproduce the problem with the
> above log?
Hi Mark,
You assume that you have KASAN enabled.
Since a few unintended line breaks were added in the email, here's the
program in plaintext:
https://gist.githubusercontent.com/xairy/69864355b5a64f74e7cb445b7325a7df/raw/bdbbbf177dbea13eac0a5ddfa9c3e6c32695b13b/kvm-arm-uaf-log
I run it as:
# ./syz-execprog -repeat=0 -collide=false -sandbox=namespace ./kvm-arm-uaf-log
And it takes less than a second to trigger the bug.
Thanks!
>
> How quickly does that reproduce the problem for you?
>
> Thanks,
> Mark.
>
> [1] https://github.com/google/syzkaller/wiki/How-to-execute-syzkaller-programs
^ permalink raw reply
* [PATCH RFC 0/5] *** SPI Slave mode support ***
From: jiada_wang at mentor.com @ 2017-04-13 12:13 UTC (permalink / raw)
To: linux-arm-kernel
From: Jiada Wang <jiada_wang@mentor.com>
v1:
add Slave mode support in SPI core
spidev create slave device when SPI controller work in slave mode
spi-imx support to work in slave mode
Jiada Wang (5):
spi: core: add support to work in Slave mode
spi: spidev: use different name for SPI controller slave mode device
spi: imx: add selection for iMX53 and iMX6 controller
ARM: dts: imx: change compatiblity for SPI controllers on imx53 later
soc
spi: imx: Add support for SPI Slave mode for imx53 and imx6 chips
Documentation/devicetree/bindings/spi/spi-bus.txt | 27 ++-
Documentation/spi/spi-summary | 19 +-
arch/arm/boot/dts/imx53.dtsi | 4 +-
arch/arm/boot/dts/imx6q.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl.dtsi | 8 +-
arch/arm/boot/dts/imx6sl.dtsi | 8 +-
arch/arm/boot/dts/imx6sx.dtsi | 8 +-
arch/arm/boot/dts/imx6ul.dtsi | 8 +-
drivers/spi/Kconfig | 14 +-
drivers/spi/spi-imx.c | 216 ++++++++++++++++++++--
drivers/spi/spi.c | 23 ++-
drivers/spi/spidev.c | 15 +-
include/linux/spi/spi.h | 15 ++
13 files changed, 310 insertions(+), 57 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH RFC 1/5] spi: core: add support to work in Slave mode
From: jiada_wang at mentor.com @ 2017-04-13 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492085644-4195-1-git-send-email-jiada_wang@mentor.com>
From: Jiada Wang <jiada_wang@mentor.com>
Add support for SPI bus controller to work in slave mode using
the existing SPI master framework.
- SPI device on SPI bus controller with 'spi-slave' property
declared in DT node represents SPI controller itself to work
as a slave device and listening to external SPI master devices
- when SPI bus controller works in slave mode, 'chip_select' and
'max_speed_hz' are not required.
- SPI slave mode continue to use 'struct spi_master'
Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
---
Documentation/devicetree/bindings/spi/spi-bus.txt | 27 ++++++++++++++---------
Documentation/spi/spi-summary | 19 +++++++++++-----
drivers/spi/Kconfig | 14 +++++++++++-
drivers/spi/spi.c | 23 ++++++++++++++++++-
include/linux/spi/spi.h | 15 +++++++++++++
5 files changed, 80 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt
index 4b1d6e7..96e93ba 100644
--- a/Documentation/devicetree/bindings/spi/spi-bus.txt
+++ b/Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -1,17 +1,20 @@
SPI (Serial Peripheral Interface) busses
-SPI busses can be described with a node for the SPI master device
-and a set of child nodes for each SPI slave on the bus. For this
-discussion, it is assumed that the system's SPI controller is in
-SPI master mode. This binding does not describe SPI controllers
-in slave mode.
+SPI busses can be described with a node for the SPI controller device
+and a set of child nodes for each SPI slave on the bus. The system's SPI
+controller can work either in master mode or in slave mode, based on the
+child node on it.
-The SPI master node requires the following properties:
+The SPI controller node requires the following properties:
+- compatible - name of SPI bus controller following generic names
+ recommended practice.
+
+In master mode, the SPI controller node requires the following additional
+properties:
- #address-cells - number of cells required to define a chip select
address on the SPI bus.
- #size-cells - should be zero.
-- compatible - name of SPI bus controller following generic names
- recommended practice.
+
No other properties are required in the SPI bus node. It is assumed
that a driver for an SPI bus device will understand that it is an SPI bus.
However, the binding does not attempt to define the specific method for
@@ -43,10 +46,11 @@ cs3 : &gpio1 2 0
SPI slave nodes must be children of the SPI master node and can
contain the following properties.
-- reg - (required) chip select address of device.
+- reg - (required, master mode only) chip select address of device.
- compatible - (required) name of SPI device following generic names
recommended practice.
-- spi-max-frequency - (required) Maximum SPI clocking speed of device in Hz.
+- spi-max-frequency - (required, master mode only) Maximum SPI clocking speed of
+ device in Hz.
- spi-cpol - (optional) Empty property indicating device requires
inverse clock polarity (CPOL) mode.
- spi-cpha - (optional) Empty property indicating device requires
@@ -63,6 +67,9 @@ contain the following properties.
used for MISO. Defaults to 1 if not present.
- spi-rx-delay-us - (optional) Microsecond delay after a read transfer.
- spi-tx-delay-us - (optional) Microsecond delay after a write transfer.
+- spi-slave - (optional) Empty property indicating SPI bus controller
+ itself works in slave mode to interface with external master
+ devices.
Some SPI controllers and devices support Dual and Quad SPI transfer mode.
It allows data in the SPI system to be transferred using 2 wires (DUAL) or 4
diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary
index d1824b3..4c2ceaa 100644
--- a/Documentation/spi/spi-summary
+++ b/Documentation/spi/spi-summary
@@ -62,9 +62,8 @@ chips described as using "three wire" signaling: SCK, data, nCSx.
(That data line is sometimes called MOMI or SISO.)
Microcontrollers often support both master and slave sides of the SPI
-protocol. This document (and Linux) currently only supports the master
-side of SPI interactions.
-
+protocol. This document (and Linux) supports both the master and slave
+sides of SPI interactions.
Who uses it? On what kinds of systems?
---------------------------------------
@@ -154,9 +153,8 @@ control audio interfaces, present touchscreen sensors as input interfaces,
or monitor temperature and voltage levels during industrial processing.
And those might all be sharing the same controller driver.
-A "struct spi_device" encapsulates the master-side interface between
-those two types of driver. At this writing, Linux has no slave side
-programming interface.
+A "struct spi_device" encapsulates the controller-side interface between
+those two types of drivers.
There is a minimal core of SPI programming interfaces, focussing on
using the driver model to connect controller and protocol drivers using
@@ -168,12 +166,21 @@ shows up in sysfs in several locations:
/sys/devices/.../CTLR/spiB.C ... spi_device on bus "B",
chipselect C, accessed through CTLR.
+ /sys/devices/.../CTLR/spiB-slv ... SPI bus "B" controller itself as a
+ spi_device works in slave mode, accessed through CTRL.
+
/sys/bus/spi/devices/spiB.C ... symlink to that physical
.../CTLR/spiB.C device
+ /sys/bus/spi/devices/spiB-slv ... symlink to that physical
+ .../CTLR/spiB-slv device
+
/sys/devices/.../CTLR/spiB.C/modalias ... identifies the driver
that should be used with this device (for hotplug/coldplug)
+ /sys/devices/.../CTLR/spiB-slv/modalias ... identifies the driver
+ that should be used with this device (for hotplug/coldplug)
+
/sys/bus/spi/drivers/D ... driver for one or more spi*.* devices
/sys/class/spi_master/spiB ... symlink (or actual device node) to
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 25ae7f2e..1096c7d 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -784,6 +784,18 @@ config SPI_TLE62X0
endif # SPI_MASTER
-# (slave support would go here)
+#
+# SLAVE side ... listening to other SPI masters
+#
+
+config SPI_SLAVE
+ bool "SPI slave protocol handlers"
+ help
+ If your system has a slave-capable SPI controller, you can enable
+ slave protocol handlers.
+
+if SPI_SLAVE
+
+endif # SPI_SLAVE
endif # SPI
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 90b5b2e..3af26e2 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -475,6 +475,12 @@ static void spi_dev_set_name(struct spi_device *spi)
return;
}
+ if (spi->slave_mode) {
+ dev_set_name(&spi->dev, "%s-slv",
+ dev_name(&spi->master->dev));
+ return;
+ }
+
dev_set_name(&spi->dev, "%s.%u", dev_name(&spi->master->dev),
spi->chip_select);
}
@@ -484,6 +490,9 @@ static int spi_dev_check(struct device *dev, void *data)
struct spi_device *spi = to_spi_device(dev);
struct spi_device *new_spi = data;
+ if (spi->slave_mode)
+ return 0;
+
if (spi->master == new_spi->master &&
spi->chip_select == new_spi->chip_select)
return -EBUSY;
@@ -523,6 +532,9 @@ int spi_add_device(struct spi_device *spi)
*/
mutex_lock(&spi_add_lock);
+ if (spi->slave_mode)
+ goto setup_spi;
+
status = bus_for_each_dev(&spi_bus_type, NULL, spi, spi_dev_check);
if (status) {
dev_err(dev, "chipselect %d already in use\n",
@@ -533,6 +545,7 @@ int spi_add_device(struct spi_device *spi)
if (master->cs_gpios)
spi->cs_gpio = master->cs_gpios[spi->chip_select];
+setup_spi:
/* Drivers may modify this initial i/o setup, but will
* normally rely on the device being setup. Devices
* using SPI_CS_HIGH can't coexist well otherwise...
@@ -1511,6 +1524,14 @@ static int of_spi_parse_dt(struct spi_master *master, struct spi_device *spi,
u32 value;
int rc;
+ if (of_find_property(nc, "spi-slave", NULL)) {
+ if (!spi_controller_has_slavemode(master))
+ return -EINVAL;
+
+ spi->slave_mode = 1;
+ return 0;
+ }
+
/* Device address */
rc = of_property_read_u32(nc, "reg", &value);
if (rc) {
@@ -1961,7 +1982,7 @@ int spi_register_master(struct spi_master *master)
status = device_add(&master->dev);
if (status < 0)
goto done;
- dev_dbg(dev, "registered master %s%s\n", dev_name(&master->dev),
+ dev_dbg(dev, "registered controller %s%s\n", dev_name(&master->dev),
dynamic ? " (dynamic)" : "");
/* If we're using a queued driver, start the queue */
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 75c6bd0..bb81425 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -115,6 +115,8 @@ void spi_statistics_add_transfer_stats(struct spi_statistics *stats,
* This may be changed by the device's driver, or left at the
* default (0) indicating protocol words are eight bit bytes.
* The spi_transfer.bits_per_word can override this for each transfer.
+ * @slave_mode: indicates whether SPI controller works in master mode
+ * or slave mode to transfer data with external spi devices.
* @irq: Negative, or the number passed to request_irq() to receive
* interrupts from this device.
* @controller_state: Controller's runtime state
@@ -144,6 +146,7 @@ struct spi_device {
u8 chip_select;
u8 bits_per_word;
u16 mode;
+ u8 slave_mode;
#define SPI_CPHA 0x01 /* clock phase */
#define SPI_CPOL 0x02 /* clock polarity */
#define SPI_MODE_0 (0|0) /* (original MicroWire) */
@@ -372,6 +375,7 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv)
* transfer_one callback.
* @handle_err: the subsystem calls the driver to handle an error that occurs
* in the generic implementation of transfer_one_message().
+ * @has_slavemode: checks whether SPI Controller supports slave mode or not.
* @unprepare_message: undo any work done by prepare_message().
* @spi_flash_read: to support spi-controller hardwares that provide
* accelerated interface to read from flash devices.
@@ -549,6 +553,7 @@ struct spi_master {
struct spi_transfer *transfer);
void (*handle_err)(struct spi_master *master,
struct spi_message *message);
+ bool (*has_slavemode)(struct spi_master *master);
/* gpio chip select */
int *cs_gpios;
@@ -590,6 +595,16 @@ static inline void spi_master_put(struct spi_master *master)
put_device(&master->dev);
}
+
+static inline bool spi_controller_has_slavemode(struct spi_master *master)
+{
+#ifdef CONFIG_SPI_SLAVE
+ if (master->has_slavemode)
+ return master->has_slavemode(master);
+#endif
+ return false;
+}
+
/* PM calls that need to be issued by the driver */
extern int spi_master_suspend(struct spi_master *master);
extern int spi_master_resume(struct spi_master *master);
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 2/5] spi: spidev: use different name for SPI controller slave mode device
From: jiada_wang at mentor.com @ 2017-04-13 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492085644-4195-1-git-send-email-jiada_wang@mentor.com>
From: Jiada Wang <jiada_wang@mentor.com>
SPI bus controller has started to support to work in slave mode,
for device SPI controller itself works in slave mode, use name
'spidev[bus]-slv' as its name to differentiate from other
SPI devices
Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
---
drivers/spi/spidev.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 9e2e099..e2996fb 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -781,9 +781,18 @@ static int spidev_probe(struct spi_device *spi)
struct device *dev;
spidev->devt = MKDEV(SPIDEV_MAJOR, minor);
- dev = device_create(spidev_class, &spi->dev, spidev->devt,
- spidev, "spidev%d.%d",
- spi->master->bus_num, spi->chip_select);
+ if (spi->slave_mode)
+ dev = device_create(spidev_class, &spi->dev,
+ spidev->devt, spidev,
+ "spidev%d-slv",
+ spi->master->bus_num);
+ else
+ dev = device_create(spidev_class, &spi->dev,
+ spidev->devt, spidev,
+ "spidev%d.%d",
+ spi->master->bus_num,
+ spi->chip_select);
+
status = PTR_ERR_OR_ZERO(dev);
} else {
dev_dbg(&spi->dev, "no minor number available!\n");
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 3/5] spi: imx: add selection for iMX53 and iMX6 controller
From: jiada_wang at mentor.com @ 2017-04-13 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492085644-4195-1-git-send-email-jiada_wang@mentor.com>
From: Jiada Wang <jiada_wang@mentor.com>
ECSPI contorller for iMX53 and iMX6 has few hardware issues
comparing to iMX51.
The change add possibility to detect which controller is used
to apply possible workaround and limitations.
Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
---
drivers/spi/spi-imx.c | 43 ++++++++++++++++++++++++++++++++++++++++---
1 file changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 9a7c62f..b2323b9 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -67,7 +67,8 @@ enum spi_imx_devtype {
IMX27_CSPI,
IMX31_CSPI,
IMX35_CSPI, /* CSPI on all i.mx except above */
- IMX51_ECSPI, /* ECSPI on i.mx51 and later */
+ IMX51_ECSPI, /* ECSPI on i.mx51 */
+ IMX53_ECSPI, /* ECSPI on i.mx53 and later */
};
struct spi_imx_data;
@@ -127,9 +128,32 @@ static inline int is_imx51_ecspi(struct spi_imx_data *d)
return d->devtype_data->devtype == IMX51_ECSPI;
}
+static inline int is_imx53_ecspi(struct spi_imx_data *d)
+{
+ return d->devtype_data->devtype == IMX53_ECSPI;
+}
+
static inline unsigned spi_imx_get_fifosize(struct spi_imx_data *d)
{
- return is_imx51_ecspi(d) ? 64 : 8;
+ switch (d->devtype_data->devtype) {
+ case IMX51_ECSPI:
+ case IMX53_ECSPI:
+ return 64;
+ default:
+ return 8;
+ }
+}
+
+static inline bool spi_imx_has_dmamode(struct spi_imx_data *d)
+{
+ switch (d->devtype_data->devtype) {
+ case IMX35_CSPI:
+ case IMX51_ECSPI:
+ case IMX53_ECSPI:
+ return true;
+ default:
+ return false;
+ }
}
#define MXC_SPI_BUF_RX(type) \
@@ -746,6 +770,15 @@ static struct spi_imx_devtype_data imx51_ecspi_devtype_data = {
.devtype = IMX51_ECSPI,
};
+static struct spi_imx_devtype_data imx53_ecspi_devtype_data = {
+ .intctrl = mx51_ecspi_intctrl,
+ .config = mx51_ecspi_config,
+ .trigger = mx51_ecspi_trigger,
+ .rx_available = mx51_ecspi_rx_available,
+ .reset = mx51_ecspi_reset,
+ .devtype = IMX53_ECSPI,
+};
+
static const struct platform_device_id spi_imx_devtype[] = {
{
.name = "imx1-cspi",
@@ -766,6 +799,9 @@ static const struct platform_device_id spi_imx_devtype[] = {
.name = "imx51-ecspi",
.driver_data = (kernel_ulong_t) &imx51_ecspi_devtype_data,
}, {
+ .name = "imx53-ecspi",
+ .driver_data = (kernel_ulong_t) &imx53_ecspi_devtype_data,
+ }, {
/* sentinel */
}
};
@@ -777,6 +813,7 @@ static const struct of_device_id spi_imx_dt_ids[] = {
{ .compatible = "fsl,imx31-cspi", .data = &imx31_cspi_devtype_data, },
{ .compatible = "fsl,imx35-cspi", .data = &imx35_cspi_devtype_data, },
{ .compatible = "fsl,imx51-ecspi", .data = &imx51_ecspi_devtype_data, },
+ { .compatible = "fsl,imx53-ecspi", .data = &imx53_ecspi_devtype_data, },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, spi_imx_dt_ids);
@@ -1266,7 +1303,7 @@ static int spi_imx_probe(struct platform_device *pdev)
* Only validated on i.mx35 and i.mx6 now, can remove the constraint
* if validated on other chips.
*/
- if (is_imx35_cspi(spi_imx) || is_imx51_ecspi(spi_imx)) {
+ if (spi_imx_has_dmamode(spi_imx)) {
ret = spi_imx_sdma_init(&pdev->dev, spi_imx, master);
if (ret == -EPROBE_DEFER)
goto out_clk_put;
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 4/5] ARM: dts: imx: change compatiblity for SPI controllers on imx53 later soc
From: jiada_wang at mentor.com @ 2017-04-13 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492085644-4195-1-git-send-email-jiada_wang@mentor.com>
From: Jiada Wang <jiada_wang@mentor.com>
for SPI controllers on imx53 and later SoCs, there is HW issue when
work in slave mode, as new device type 'IMX53_ECSPI' has been added
for these SPI controllers which is compatible with 'fsl,imx53-ecspi'.
This patch updates DTS to make imx53 later SPI controller only be
compatibile with 'fsl,imx53-ecspi'.
Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
---
arch/arm/boot/dts/imx53.dtsi | 4 ++--
arch/arm/boot/dts/imx6q.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl.dtsi | 8 ++++----
arch/arm/boot/dts/imx6sl.dtsi | 8 ++++----
arch/arm/boot/dts/imx6sx.dtsi | 8 ++++----
arch/arm/boot/dts/imx6ul.dtsi | 8 ++++----
6 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 2e516f4..9eeafb9 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -243,7 +243,7 @@
ecspi1: ecspi at 50010000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx53-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx53-ecspi";
reg = <0x50010000 0x4000>;
interrupts = <36>;
clocks = <&clks IMX5_CLK_ECSPI1_IPG_GATE>,
@@ -662,7 +662,7 @@
ecspi2: ecspi at 63fac000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx53-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx53-ecspi";
reg = <0x63fac000 0x4000>;
interrupts = <37>;
clocks = <&clks IMX5_CLK_ECSPI2_IPG_GATE>,
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index e9a5d0b..7373671 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -90,7 +90,7 @@
ecspi5: ecspi at 02018000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6q-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6q-ecspi", "fsl,imx53-ecspi";
reg = <0x02018000 0x4000>;
interrupts = <0 35 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6Q_CLK_ECSPI5>,
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 6d7bf64..4a4b509 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -265,7 +265,7 @@
ecspi1: ecspi at 02008000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6q-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6q-ecspi", "fsl,imx53-ecspi";
reg = <0x02008000 0x4000>;
interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_ECSPI1>,
@@ -279,7 +279,7 @@
ecspi2: ecspi at 0200c000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6q-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6q-ecspi", "fsl,imx53-ecspi";
reg = <0x0200c000 0x4000>;
interrupts = <0 32 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_ECSPI2>,
@@ -293,7 +293,7 @@
ecspi3: ecspi at 02010000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6q-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6q-ecspi", "fsl,imx53-ecspi";
reg = <0x02010000 0x4000>;
interrupts = <0 33 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_ECSPI3>,
@@ -307,7 +307,7 @@
ecspi4: ecspi at 02014000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6q-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6q-ecspi", "fsl,imx53-ecspi";
reg = <0x02014000 0x4000>;
interrupts = <0 34 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_ECSPI4>,
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index cc9572e..1d1200c 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -168,7 +168,7 @@
ecspi1: ecspi at 02008000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6sl-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6sl-ecspi", "fsl,imx53-ecspi";
reg = <0x02008000 0x4000>;
interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SL_CLK_ECSPI1>,
@@ -180,7 +180,7 @@
ecspi2: ecspi at 0200c000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6sl-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6sl-ecspi", "fsl,imx53-ecspi";
reg = <0x0200c000 0x4000>;
interrupts = <0 32 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SL_CLK_ECSPI2>,
@@ -192,7 +192,7 @@
ecspi3: ecspi at 02010000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6sl-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6sl-ecspi", "fsl,imx53-ecspi";
reg = <0x02010000 0x4000>;
interrupts = <0 33 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SL_CLK_ECSPI3>,
@@ -204,7 +204,7 @@
ecspi4: ecspi at 02014000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6sl-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6sl-ecspi", "fsl,imx53-ecspi";
reg = <0x02014000 0x4000>;
interrupts = <0 34 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SL_CLK_ECSPI4>,
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index dd4ec85..c115ed3 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -251,7 +251,7 @@
ecspi1: ecspi at 02008000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6sx-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6sx-ecspi", "fsl,imx53-ecspi";
reg = <0x02008000 0x4000>;
interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_ECSPI1>,
@@ -263,7 +263,7 @@
ecspi2: ecspi at 0200c000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6sx-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6sx-ecspi", "fsl,imx53-ecspi";
reg = <0x0200c000 0x4000>;
interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_ECSPI2>,
@@ -275,7 +275,7 @@
ecspi3: ecspi at 02010000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6sx-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6sx-ecspi", "fsl,imx53-ecspi";
reg = <0x02010000 0x4000>;
interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_ECSPI3>,
@@ -287,7 +287,7 @@
ecspi4: ecspi at 02014000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6sx-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6sx-ecspi", "fsl,imx53-ecspi";
reg = <0x02014000 0x4000>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_ECSPI4>,
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index b9d7d2d..d35ad5b 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -204,7 +204,7 @@
ecspi1: ecspi at 02008000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6ul-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6ul-ecspi", "fsl,imx53-ecspi";
reg = <0x02008000 0x4000>;
interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6UL_CLK_ECSPI1>,
@@ -216,7 +216,7 @@
ecspi2: ecspi at 0200c000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6ul-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6ul-ecspi", "fsl,imx53-ecspi";
reg = <0x0200c000 0x4000>;
interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6UL_CLK_ECSPI2>,
@@ -228,7 +228,7 @@
ecspi3: ecspi at 02010000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6ul-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6ul-ecspi", "fsl,imx53-ecspi";
reg = <0x02010000 0x4000>;
interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6UL_CLK_ECSPI3>,
@@ -240,7 +240,7 @@
ecspi4: ecspi at 02014000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6ul-ecspi", "fsl,imx51-ecspi";
+ compatible = "fsl,imx6ul-ecspi", "fsl,imx53-ecspi";
reg = <0x02014000 0x4000>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6UL_CLK_ECSPI4>,
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 5/5] spi: imx: Add support for SPI Slave mode for imx53 and imx6 chips
From: jiada_wang at mentor.com @ 2017-04-13 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492085644-4195-1-git-send-email-jiada_wang@mentor.com>
From: Jiada Wang <jiada_wang@mentor.com>
Previously i.MX SPI controller only works in Master mode.
This patch adds support to work also in Slave mode.
Currently SPI Slave mode support patch has the following limitations:
1. The stale data in RXFIFO will be dropped when the Slave does any new
transfer.
2. One transfer can be finished only after all transfer->len data been
transferred to master device
3. Slave device only accepts transfer->len data. Any data longer than this
from master device will be dropped. Any data shorter than this from
master will cause SPI to stuck due to mentioned HW limitation 2.
4. Only PIO transfer is supported in Slave mode.
Following HW limitation applies:
1. ECSPI has a HW issue when works in Slave mode, after 64
words written to TXFIFO, even TXFIFO becomes empty,
ECSPI_TXDATA keeps shift out the last word data,
so we have to disable ECSPI when in slave mode after the
transfer completes
2. Due to Freescale errata ERR003775 "eCSPI: Burst completion by Chip
Select (SS) signal in Slave mode is not functional" burst size must
be set exactly to the size of the transfer. This limit SPI transaction
with maximum 2^12 bits.
Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
---
drivers/spi/spi-imx.c | 173 ++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 159 insertions(+), 14 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index b2323b9..f6e1baa 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -53,9 +53,13 @@
/* generic defines to abstract from the different register layouts */
#define MXC_INT_RR (1 << 0) /* Receive data ready interrupt */
#define MXC_INT_TE (1 << 1) /* Transmit FIFO empty interrupt */
+#define MXC_INT_RDR BIT(4) /* Receive date threshold interrupt */
/* The maximum bytes that a sdma BD can transfer.*/
#define MAX_SDMA_BD_BYTES (1 << 15)
+/* The maximum bytes that IMX53_ECSPI can transfer in slave mode.*/
+#define MX53_MAX_TRANSFER_BYTES 512
+
struct spi_imx_config {
unsigned int speed_hz;
unsigned int bpw;
@@ -79,6 +83,7 @@ struct spi_imx_devtype_data {
void (*trigger)(struct spi_imx_data *);
int (*rx_available)(struct spi_imx_data *);
void (*reset)(struct spi_imx_data *);
+ void (*disable)(struct spi_imx_data *);
enum spi_imx_devtype devtype;
};
@@ -104,6 +109,10 @@ struct spi_imx_data {
const void *tx_buf;
unsigned int txfifo; /* number of words pushed in tx FIFO */
+ /* Slave mode */
+ unsigned int slave_mode;
+ unsigned int slave_burst;
+
/* DMA */
bool usedma;
u32 wml;
@@ -156,6 +165,19 @@ static inline bool spi_imx_has_dmamode(struct spi_imx_data *d)
}
}
+static bool spi_imx_has_slavemode(struct spi_master *master)
+{
+ struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+
+ switch (spi_imx->devtype_data->devtype) {
+ case IMX51_ECSPI:
+ case IMX53_ECSPI:
+ return true;
+ default:
+ return false;
+ }
+}
+
#define MXC_SPI_BUF_RX(type) \
static void spi_imx_buf_rx_##type(struct spi_imx_data *spi_imx) \
{ \
@@ -285,6 +307,7 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
#define MX51_ECSPI_INT 0x10
#define MX51_ECSPI_INT_TEEN (1 << 0)
#define MX51_ECSPI_INT_RREN (1 << 3)
+#define MX51_ECSPI_INT_RDREN (1 << 4)
#define MX51_ECSPI_DMA 0x14
#define MX51_ECSPI_DMA_TX_WML(wml) ((wml) & 0x3f)
@@ -301,6 +324,51 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
#define MX51_ECSPI_TESTREG 0x20
#define MX51_ECSPI_TESTREG_LBC BIT(31)
+static void mx53_ecspi_rx_slave(struct spi_imx_data *spi_imx)
+{
+ u32 val = be32_to_cpu(readl(spi_imx->base + MXC_CSPIRXDATA));
+
+ if (spi_imx->rx_buf) {
+ int shift = spi_imx->slave_burst % sizeof(val);
+
+ if (shift) {
+ memcpy(spi_imx->rx_buf,
+ ((u8 *)&val) + sizeof(val) - shift, shift);
+ } else {
+ *((u32 *)spi_imx->rx_buf) = val;
+ shift = sizeof(val);
+ }
+
+ spi_imx->rx_buf += shift;
+ spi_imx->slave_burst -= shift;
+ }
+}
+
+static void mx53_ecspi_tx_slave(struct spi_imx_data *spi_imx)
+{
+ u32 val = 0;
+ int shift = spi_imx->count % sizeof(val);
+
+ if (spi_imx->tx_buf) {
+ if (shift) {
+ memcpy(((u8 *)&val) + sizeof(val) - shift,
+ spi_imx->tx_buf, shift);
+ } else {
+ val = *((u32 *)spi_imx->tx_buf);
+ shift = sizeof(val);
+ }
+ val = cpu_to_be32(val);
+ spi_imx->tx_buf += shift;
+ }
+
+ if (!shift)
+ shift = sizeof(val);
+
+ spi_imx->count -= shift;
+
+ writel(val, spi_imx->base + MXC_CSPITXDATA);
+}
+
/* MX51 eCSPI */
static unsigned int mx51_ecspi_clkdiv(struct spi_imx_data *spi_imx,
unsigned int fspi, unsigned int *fres)
@@ -350,6 +418,9 @@ static void mx51_ecspi_intctrl(struct spi_imx_data *spi_imx, int enable)
if (enable & MXC_INT_RR)
val |= MX51_ECSPI_INT_RREN;
+ if (enable & MXC_INT_RDR)
+ val |= MX51_ECSPI_INT_RDREN;
+
writel(val, spi_imx->base + MX51_ECSPI_INT);
}
@@ -362,6 +433,15 @@ static void mx51_ecspi_trigger(struct spi_imx_data *spi_imx)
writel(reg, spi_imx->base + MX51_ECSPI_CTRL);
}
+static void __maybe_unused mx51_ecspi_disable(struct spi_imx_data *spi_imx)
+{
+ u32 ctrl;
+
+ ctrl = readl(spi_imx->base + MX51_ECSPI_CTRL);
+ ctrl &= ~MX51_ECSPI_CTRL_ENABLE;
+ writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
+}
+
static int mx51_ecspi_config(struct spi_device *spi,
struct spi_imx_config *config)
{
@@ -370,14 +450,13 @@ static int mx51_ecspi_config(struct spi_device *spi,
u32 clk = config->speed_hz, delay, reg;
u32 cfg = readl(spi_imx->base + MX51_ECSPI_CONFIG);
- /*
- * The hardware seems to have a race condition when changing modes. The
- * current assumption is that the selection of the channel arrives
- * earlier in the hardware than the mode bits when they are written at
- * the same time.
- * So set master mode for all channels as we do not support slave mode.
- */
- ctrl |= MX51_ECSPI_CTRL_MODE_MASK;
+ writel(0, spi_imx->base + MX51_ECSPI_CTRL);
+
+ /* set Master or Slave mode */
+ if (spi_imx->slave_mode)
+ ctrl &= ~MX51_ECSPI_CTRL_MODE_MASK;
+ else
+ ctrl |= MX51_ECSPI_CTRL_MODE_MASK;
/* set clock speed */
ctrl |= mx51_ecspi_clkdiv(spi_imx, config->speed_hz, &clk);
@@ -386,9 +465,21 @@ static int mx51_ecspi_config(struct spi_device *spi,
/* set chip select to use */
ctrl |= MX51_ECSPI_CTRL_CS(spi->chip_select);
- ctrl |= (config->bpw - 1) << MX51_ECSPI_CTRL_BL_OFFSET;
+ if (spi_imx->slave_mode && is_imx53_ecspi(spi_imx))
+ ctrl |= (spi_imx->slave_burst * 8 - 1)
+ << MX51_ECSPI_CTRL_BL_OFFSET;
+ else
+ ctrl |= (config->bpw - 1) << MX51_ECSPI_CTRL_BL_OFFSET;
- cfg |= MX51_ECSPI_CONFIG_SBBCTRL(spi->chip_select);
+ /*
+ * eCSPI burst completion by Chip Select signal in Slave mode
+ * is not functional, config SPI burst completed when
+ * BURST_LENGTH + 1 bits are received
+ */
+ if (spi_imx->slave_mode && is_imx53_ecspi(spi_imx))
+ cfg &= ~MX51_ECSPI_CONFIG_SBBCTRL(spi->chip_select);
+ else
+ cfg |= MX51_ECSPI_CONFIG_SBBCTRL(spi->chip_select);
if (spi->mode & SPI_CPHA)
cfg |= MX51_ECSPI_CONFIG_SCLKPHA(spi->chip_select);
@@ -767,6 +858,7 @@ static struct spi_imx_devtype_data imx51_ecspi_devtype_data = {
.trigger = mx51_ecspi_trigger,
.rx_available = mx51_ecspi_rx_available,
.reset = mx51_ecspi_reset,
+ .disable = mx51_ecspi_disable,
.devtype = IMX51_ECSPI,
};
@@ -776,6 +868,7 @@ static struct spi_imx_devtype_data imx53_ecspi_devtype_data = {
.trigger = mx51_ecspi_trigger,
.rx_available = mx51_ecspi_rx_available,
.reset = mx51_ecspi_reset,
+ .disable = mx51_ecspi_disable,
.devtype = IMX53_ECSPI,
};
@@ -838,14 +931,16 @@ static void spi_imx_push(struct spi_imx_data *spi_imx)
spi_imx->txfifo++;
}
- spi_imx->devtype_data->trigger(spi_imx);
+ if (!spi_imx->slave_mode)
+ spi_imx->devtype_data->trigger(spi_imx);
}
static irqreturn_t spi_imx_isr(int irq, void *dev_id)
{
struct spi_imx_data *spi_imx = dev_id;
- while (spi_imx->devtype_data->rx_available(spi_imx)) {
+ while (spi_imx->txfifo &&
+ spi_imx->devtype_data->rx_available(spi_imx)) {
spi_imx->rx(spi_imx);
spi_imx->txfifo--;
}
@@ -927,6 +1022,8 @@ static int spi_imx_setupxfer(struct spi_device *spi,
config.bpw = t ? t->bits_per_word : spi->bits_per_word;
config.speed_hz = t ? t->speed_hz : spi->max_speed_hz;
+ spi_imx->slave_mode = spi->slave_mode;
+
if (!config.speed_hz)
config.speed_hz = spi->max_speed_hz;
if (!config.bpw)
@@ -944,7 +1041,8 @@ static int spi_imx_setupxfer(struct spi_device *spi,
spi_imx->tx = spi_imx_buf_tx_u32;
}
- if (spi_imx_can_dma(spi_imx->bitbang.master, spi, t))
+ if (!spi->slave_mode &&
+ spi_imx_can_dma(spi_imx->bitbang.master, spi, t))
spi_imx->usedma = 1;
else
spi_imx->usedma = 0;
@@ -956,6 +1054,12 @@ static int spi_imx_setupxfer(struct spi_device *spi,
return ret;
}
+ if (is_imx53_ecspi(spi_imx) && spi_imx->slave_mode) {
+ spi_imx->rx = mx53_ecspi_rx_slave;
+ spi_imx->tx = mx53_ecspi_tx_slave;
+ spi_imx->slave_burst = t->len;
+ }
+
spi_imx->devtype_data->config(spi, &config);
return 0;
@@ -1117,16 +1221,46 @@ static int spi_imx_pio_transfer(struct spi_device *spi,
struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
unsigned long transfer_timeout;
unsigned long timeout;
+ int ret = transfer->len;
+
+ if (is_imx53_ecspi(spi_imx) && spi_imx->slave_mode &&
+ transfer->len > MX53_MAX_TRANSFER_BYTES) {
+ pr_err("Transaction too big, max size is %d bytes\n",
+ MX53_MAX_TRANSFER_BYTES);
+ return -EMSGSIZE;
+ }
spi_imx->tx_buf = transfer->tx_buf;
spi_imx->rx_buf = transfer->rx_buf;
spi_imx->count = transfer->len;
spi_imx->txfifo = 0;
+ if (spi_imx->slave_mode)
+ spi_imx->slave_burst = spi_imx->count;
+
reinit_completion(&spi_imx->xfer_done);
spi_imx_push(spi_imx);
+ if (spi_imx->slave_mode) {
+ spi_imx->devtype_data->intctrl(spi_imx, MXC_INT_TE |
+ MXC_INT_RDR);
+
+ if (wait_for_completion_interruptible(&spi_imx->xfer_done) < 0)
+ ret = -EINTR;
+
+ /* ecspi has a HW issue when works in Slave mode,
+ * after 64 words writtern to TXFIFO, even TXFIFO becomes empty,
+ * ECSPI_TXDATA keeps shift out the last word data,
+ * so we have to disable ECSPI when in slave mode after the
+ * transfer completes
+ */
+ if (spi_imx->devtype_data->disable)
+ spi_imx->devtype_data->disable(spi_imx);
+
+ goto out;
+ }
+
spi_imx->devtype_data->intctrl(spi_imx, MXC_INT_TE);
transfer_timeout = spi_imx_calculate_timeout(spi_imx, transfer->len);
@@ -1139,7 +1273,8 @@ static int spi_imx_pio_transfer(struct spi_device *spi,
return -ETIMEDOUT;
}
- return transfer->len;
+out:
+ return ret;
}
static int spi_imx_transfer(struct spi_device *spi,
@@ -1147,6 +1282,10 @@ static int spi_imx_transfer(struct spi_device *spi,
{
struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
+ /* flush rxfifo before transfer */
+ while (spi_imx->devtype_data->rx_available(spi_imx))
+ spi_imx->rx(spi_imx);
+
if (spi_imx->usedma)
return spi_imx_dma_transfer(spi_imx, transfer);
else
@@ -1155,6 +1294,11 @@ static int spi_imx_transfer(struct spi_device *spi,
static int spi_imx_setup(struct spi_device *spi)
{
+ if (spi->slave_mode) {
+ dev_dbg(&spi->dev, "%s: slave mode\n", __func__);
+ return 0;
+ }
+
dev_dbg(&spi->dev, "%s: mode %d, %u bpw, %d hz\n", __func__,
spi->mode, spi->bits_per_word, spi->max_speed_hz);
@@ -1254,6 +1398,7 @@ static int spi_imx_probe(struct platform_device *pdev)
spi_imx->bitbang.master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
if (is_imx35_cspi(spi_imx) || is_imx51_ecspi(spi_imx))
spi_imx->bitbang.master->mode_bits |= SPI_LOOP;
+ spi_imx->bitbang.master->has_slavemode = spi_imx_has_slavemode;
init_completion(&spi_imx->xfer_done);
--
2.7.4
^ permalink raw reply related
* [PATCH v34 04/14] arm64: kdump: reserve memory for crash dump kernel
From: David Woodhouse @ 2017-04-13 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170404092604.GB14898@arm.com>
On Tue, 2017-04-04 at 10:26 +0100, Will Deacon wrote:
> ?A
> patch making arm64 consistent could be discussed separately, otherwise kdump
> becomes the pedantic ISO guy trying to lead by example, but really everybody
> ignores him because it's completely inconsequential and they also know he
> went 35 versions without giving a monkey's.
I still don't see the logic there for *wanting* kdump to be wrong.
Sure, kdump getting it right doesn't necessarily make a big difference
in?itself.
But given that the error has been pointed out, what is the motivation
for *wanting* the error to remain in the kdump code, instead of just
fixing it? "Consistency" isn't an answer because we are *already*
inconsistent ? some code gets it right, and other code doesn't.
We should converge towards *correctness* rather than deliberately
adding more incorrect code.
I've used my 'i' key more times just in?typing this email than it would
have taken to just fix the problem the first time it was pointed out.
> David, since you seem to be the most outraged, fancy sending a patch? ;)
Coming up. In two parts ? user-visible messages, followed by cosmetic
and less relevant stuff.
--
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170413/3273313d/attachment.bin>
^ permalink raw reply
* [PATCH 1/2] arm64: Fix power-of-ten vs. power-of-two prefixes in user-visible messages
From: David Woodhouse @ 2017-04-13 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170404092604.GB14898@arm.com>
The IEC binary prefixes (Ki, Mi, Gi, etc.) were published over twenty
years ago. We should use them consistently, especially in user-visible
messages.
Sure, it doesn't often matter, just as *most* typos and spelling or
grammar mistakes don't often matter. But sometimes, such misuse really
do actually introduce ambiguity, and we should avoid that.
Conversely, there is absolutely no good reason *not* to be using the
binary prefixes. Some people once claimed to find them "ugly", or that
they would cause confusion. But those are purely down to unfamiliarity.
The perceived ugliness, and the alleged confusion, will pass with use.
The correctness, and the lack of ambiguity, will not.
ARM64 in particular, as a new platform, has no excuse for not using the
IEC prefixes which predate its existence by a decade and a half.
What's worse is that some people are pointing at the existing errors and
actually claiming that they want their *new* code to be deliberately
wrong in order to be "consistent" with what's there.
So let's fix the user-visible messages in all of arch/arm64 and nip
*that* particular stupidity in the bud...
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/arm64/Kconfig | 22 +++++++++++-----------
arch/arm64/kernel/efi.c | 2 +-
arch/arm64/kernel/setup.c | 2 +-
arch/arm64/mm/init.c | 36 ++++++++++++++++++------------------
4 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3741859..9643223 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -442,7 +442,7 @@ config CAVIUM_ERRATUM_22375
This implements two gicv3-its errata workarounds for ThunderX. Both
with small impact affecting only ITS table allocation.
- erratum 22375: only alloc 8MB table size
+ erratum 22375: only alloc 8MiB table size
erratum 24313: ignore memory access type
The fixes are in ITS initialization and basically ignore memory access
@@ -528,21 +528,21 @@ choice
Page size (translation granule) configuration.
config ARM64_4K_PAGES
- bool "4KB"
+ bool "4KiB"
help
- This feature enables 4KB pages support.
+ This feature enables 4KiB pages support.
config ARM64_16K_PAGES
- bool "16KB"
+ bool "16KiB"
help
- The system will use 16KB pages support. AArch32 emulation
- requires applications compiled with 16K (or a multiple of 16K)
+ The system will use 16KiB pages support. AArch32 emulation
+ requires applications compiled with 16KiB (or a multiple of 16KiB)
aligned segments.
config ARM64_64K_PAGES
- bool "64KB"
+ bool "64KiB"
help
- This feature enables 64KB pages support (4KB by default)
+ This feature enables 64KiB pages support (4KiB by default)
allowing only two levels of page tables and faster TLB
look-up. AArch32 emulation requires applications compiled
with 64K aligned segments.
@@ -1063,9 +1063,9 @@ config COMPAT
the user helper functions, VFP support and the ptrace interface are
handled appropriately by the kernel.
- If you use a page size other than 4KB (i.e, 16KB or 64KB), please be aware
- that you will only be able to execute AArch32 binaries that were compiled
- with page size aligned segments.
+ If you use a page size other than 4KiB (i.e, 16KiB or 64KiB), please be
+ aware that you will only be able to execute AArch32 binaries that were
+ compiled with page size aligned segments.
If you want to execute 32-bit userspace applications, say Y.
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 5d17f37..d80c11f 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -31,7 +31,7 @@ static __init pteval_t create_mapping_protection(efi_memory_desc_t *md)
return PROT_DEVICE_nGnRE;
if (WARN_ONCE(!PAGE_ALIGNED(md->phys_addr),
- "UEFI Runtime regions are not aligned to 64 KB -- buggy firmware?"))
+ "UEFI Runtime regions are not aligned to 64 KiB -- buggy firmware?"))
/*
* If the region is not aligned to the page size of the OS, we
* can not use strict permissions, since that would also affect
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 42274bd..86de05d 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -185,7 +185,7 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
if (!dt_virt || !early_init_dt_scan(dt_virt)) {
pr_crit("\n"
"Error: invalid device tree blob at physical address %pa (virtual address 0x%p)\n"
- "The dtb must be 8-byte aligned and must not exceed 2 MB in size\n"
+ "The dtb must be 8-byte aligned and must not exceed 2 MiB in size\n"
"\nPlease check your bootloader.",
&dt_phys, dt_virt);
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index e19e065..85481b9 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -111,7 +111,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
memset(zone_size, 0, sizeof(zone_size));
- /* 4GB maximum for 32-bit only capable devices */
+ /* 4GiB maximum for 32-bit only capable devices */
#ifdef CONFIG_ZONE_DMA
max_dma = PFN_DOWN(arm64_dma_phys_limit);
zone_size[ZONE_DMA] = max_dma - min;
@@ -182,7 +182,7 @@ static int __init early_mem(char *p)
return 1;
memory_limit = memparse(p, &p) & PAGE_MASK;
- pr_notice("Memory limited to %lldMB\n", memory_limit >> 20);
+ pr_notice("Memory limited to %lldMiB\n", memory_limit >> 20);
return 0;
}
@@ -242,7 +242,7 @@ void __init arm64_memblock_init(void)
* We can only add back the initrd memory if we don't end up
* with more memory than we can address via the linear mapping.
* It is up to the bootloader to position the kernel and the
- * initrd reasonably close to each other (i.e., within 32 GB of
+ * initrd reasonably close to each other (i.e., within 32 GiB of
* each other) so that all granule/#levels combinations can
* always access both.
*/
@@ -292,7 +292,7 @@ void __init arm64_memblock_init(void)
early_init_fdt_scan_reserved_mem();
- /* 4GB maximum for 32-bit only capable devices */
+ /* 4GiB maximum for 32-bit only capable devices */
if (IS_ENABLED(CONFIG_ZONE_DMA))
arm64_dma_phys_limit = max_zone_dma_phys();
else
@@ -425,35 +425,35 @@ void __init mem_init(void)
pr_notice("Virtual kernel memory layout:\n");
#ifdef CONFIG_KASAN
- pr_notice(" kasan : 0x%16lx - 0x%16lx (%6ld GB)\n",
+ pr_notice(" kasan : 0x%16lx - 0x%16lx (%6ld GiB)\n",
MLG(KASAN_SHADOW_START, KASAN_SHADOW_END));
#endif
- pr_notice(" modules : 0x%16lx - 0x%16lx (%6ld MB)\n",
+ pr_notice(" modules : 0x%16lx - 0x%16lx (%6ld MiB)\n",
MLM(MODULES_VADDR, MODULES_END));
- pr_notice(" vmalloc : 0x%16lx - 0x%16lx (%6ld GB)\n",
+ pr_notice(" vmalloc : 0x%16lx - 0x%16lx (%6ld GiB)\n",
MLG(VMALLOC_START, VMALLOC_END));
- pr_notice(" .text : 0x%p" " - 0x%p" " (%6ld KB)\n",
+ pr_notice(" .text : 0x%p" " - 0x%p" " (%6ld KiB)\n",
MLK_ROUNDUP(_text, _etext));
- pr_notice(" .rodata : 0x%p" " - 0x%p" " (%6ld KB)\n",
+ pr_notice(" .rodata : 0x%p" " - 0x%p" " (%6ld KiB)\n",
MLK_ROUNDUP(__start_rodata, __init_begin));
- pr_notice(" .init : 0x%p" " - 0x%p" " (%6ld KB)\n",
+ pr_notice(" .init : 0x%p" " - 0x%p" " (%6ld KiB)\n",
MLK_ROUNDUP(__init_begin, __init_end));
- pr_notice(" .data : 0x%p" " - 0x%p" " (%6ld KB)\n",
+ pr_notice(" .data : 0x%p" " - 0x%p" " (%6ld KiB)\n",
MLK_ROUNDUP(_sdata, _edata));
- pr_notice(" .bss : 0x%p" " - 0x%p" " (%6ld KB)\n",
+ pr_notice(" .bss : 0x%p" " - 0x%p" " (%6ld KiB)\n",
MLK_ROUNDUP(__bss_start, __bss_stop));
- pr_notice(" fixed : 0x%16lx - 0x%16lx (%6ld KB)\n",
+ pr_notice(" fixed : 0x%16lx - 0x%16lx (%6ld KiB)\n",
MLK(FIXADDR_START, FIXADDR_TOP));
- pr_notice(" PCI I/O : 0x%16lx - 0x%16lx (%6ld MB)\n",
+ pr_notice(" PCI I/O : 0x%16lx - 0x%16lx (%6ld MiB)\n",
MLM(PCI_IO_START, PCI_IO_END));
#ifdef CONFIG_SPARSEMEM_VMEMMAP
- pr_notice(" vmemmap : 0x%16lx - 0x%16lx (%6ld GB maximum)\n",
+ pr_notice(" vmemmap : 0x%16lx - 0x%16lx (%6ld GiB maximum)\n",
MLG(VMEMMAP_START, VMEMMAP_START + VMEMMAP_SIZE));
- pr_notice(" 0x%16lx - 0x%16lx (%6ld MB actual)\n",
+ pr_notice(" 0x%16lx - 0x%16lx (%6ld MiB actual)\n",
MLM((unsigned long)phys_to_page(memblock_start_of_DRAM()),
(unsigned long)virt_to_page(high_memory)));
#endif
- pr_notice(" memory : 0x%16lx - 0x%16lx (%6ld MB)\n",
+ pr_notice(" memory : 0x%16lx - 0x%16lx (%6ld MiB)\n",
MLM(__phys_to_virt(memblock_start_of_DRAM()),
(unsigned long)high_memory));
@@ -523,7 +523,7 @@ __setup("keepinitrd", keepinitrd_setup);
static int dump_mem_limit(struct notifier_block *self, unsigned long v, void *p)
{
if (memory_limit != (phys_addr_t)ULLONG_MAX) {
- pr_emerg("Memory Limit: %llu MB\n", memory_limit >> 20);
+ pr_emerg("Memory Limit: %llu MiB\n", memory_limit >> 20);
} else {
pr_emerg("Memory Limit: none\n");
}
--
2.9.3
--
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170413/3df3fc9e/attachment-0001.bin>
^ permalink raw reply related
* [PATCH 2/2] arm64: Fix power-of-ten vs. power-of-two prefixes in comments etc.
From: David Woodhouse @ 2017-04-13 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170404092604.GB14898@arm.com>
Less important than in user-visible messages, but still good practice as
there's still no excuse for ARM64 code to look like it was written before
1996.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 2 +-
.../boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 2 +-
arch/arm64/boot/dts/broadcom/ns2-xmc.dts | 24 +++++++++++-----------
arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 2 +-
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 2 +-
arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts | 2 +-
arch/arm64/boot/dts/marvell/berlin4ct-stb.dts | 2 +-
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 2 +-
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 2 +-
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 2 +-
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 2 +-
arch/arm64/include/asm/assembler.h | 2 +-
arch/arm64/include/asm/boot.h | 4 ++--
arch/arm64/include/asm/elf.h | 2 +-
arch/arm64/include/asm/fixmap.h | 6 +++---
arch/arm64/kernel/head.S | 8 ++++----
arch/arm64/kernel/hyp-stub.S | 2 +-
arch/arm64/kernel/kaslr.c | 14 ++++++-------
arch/arm64/kernel/module-plts.c | 2 +-
arch/arm64/kernel/vmlinux.lds.S | 18 ++++++++--------
arch/arm64/mm/mmu.c | 2 +-
arch/arm64/mm/proc.S | 2 +-
22 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index df539e8..f70fb13 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -694,7 +694,7 @@
memory at 80000000 {
device_type = "memory";
- /* last 16MB of the first memory area is reserved for secure world use by firmware */
+ /* last 16MiB of the first memory area is reserved for secure world use by firmware */
reg = <0x00000000 0x80000000 0x0 0x7f000000>,
<0x00000008 0x80000000 0x1 0x80000000>;
};
diff --git a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
index e3a1711..38ece4b 100644
--- a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
+++ b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
@@ -60,7 +60,7 @@
memory at 80000000 {
device_type = "memory";
- reg = <0 0x80000000 0 0x80000000>; /* 2GB @ 2GB */
+ reg = <0 0x80000000 0 0x80000000>; /* 2GiB @ 2GiB */
};
gic: interrupt-controller at 2c001000 {
diff --git a/arch/arm64/boot/dts/broadcom/ns2-xmc.dts b/arch/arm64/boot/dts/broadcom/ns2-xmc.dts
index 99a2723..5908524 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-xmc.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-xmc.dts
@@ -87,36 +87,36 @@
partition at 0 {
label = "nboot";
- reg = <0x00000000 0x00280000>; /* 2.5MB */
+ reg = <0x00000000 0x00280000>; /* 2.5MiB */
read-only;
};
partition at 280000 {
label = "nenv";
- reg = <0x00280000 0x00040000>; /* 0.25MB */
+ reg = <0x00280000 0x00040000>; /* 0.25MiB */
read-only;
};
partition at 2c0000 {
label = "ndtb";
- reg = <0x002c0000 0x00040000>; /* 0.25MB */
+ reg = <0x002c0000 0x00040000>; /* 0.25MiB */
read-only;
};
partition at 300000 {
label = "nsystem";
- reg = <0x00300000 0x03d00000>; /* 61MB */
+ reg = <0x00300000 0x03d00000>; /* 61MiB */
read-only;
};
partition at 4000000 {
label = "nrootfs";
- reg = <0x04000000 0x06400000>; /* 100MB */
+ reg = <0x04000000 0x06400000>; /* 100MiB */
};
partition at 0a400000{
label = "ncustfs";
- reg = <0x0a400000 0x35c00000>; /* 860MB */
+ reg = <0x0a400000 0x35c00000>; /* 860MiB */
};
};
};
@@ -156,32 +156,32 @@
partition at 0 {
label = "bl0";
- reg = <0x00000000 0x00080000>; /* 512KB */
+ reg = <0x00000000 0x00080000>; /* 512KiB */
};
partition at 80000 {
label = "fip";
- reg = <0x00080000 0x00150000>; /* 1344KB */
+ reg = <0x00080000 0x00150000>; /* 1344KiB */
};
partition at 1e0000 {
label = "env";
- reg = <0x001e0000 0x00010000>;/* 64KB */
+ reg = <0x001e0000 0x00010000>;/* 64KiB */
};
partition at 1f0000 {
label = "dtb";
- reg = <0x001f0000 0x00010000>; /* 64KB */
+ reg = <0x001f0000 0x00010000>; /* 64KiB */
};
partition at 200000 {
label = "kernel";
- reg = <0x00200000 0x00e00000>; /* 14MB */
+ reg = <0x00200000 0x00e00000>; /* 14MiB */
};
partition at 1000000 {
label = "rootfs";
- reg = <0x01000000 0x01000000>; /* 16MB */
+ reg = <0x01000000 0x01000000>; /* 16MiB */
};
};
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index c37110b..71ce1f1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -126,7 +126,7 @@
flash at 0 {
#address-cells = <1>;
#size-cells = <1>;
- compatible = "n25q128a13", "jedec,spi-nor"; /* 16MB */
+ compatible = "n25q128a13", "jedec,spi-nor"; /* 16MiB */
reg = <0>;
spi-max-frequency = <1000000>; /* input clock */
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index e5935f2..43e549f 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -152,7 +152,7 @@
memory at 80000000 {
device_type = "memory";
reg = <0x00000000 0x80000000 0 0x80000000>;
- /* DRAM space - 1, size : 2 GB DRAM */
+ /* DRAM space - 1, size : 2 GiB DRAM */
};
sysclk: sysclk {
diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts b/arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts
index fae6c69..4b3a5e2 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts
+++ b/arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts
@@ -56,7 +56,7 @@
memory at 1000000 {
device_type = "memory";
- /* the first 16MB is for firmwares' usage */
+ /* the first 16MiB is for firmwares' usage */
reg = <0 0x01000000 0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
index d47edad..049018b 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
+++ b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
@@ -56,7 +56,7 @@
memory at 1000000 {
device_type = "memory";
- /* the first 16MB is for firmwares' usage */
+ /* the first 16MiB is for firmwares' usage */
reg = <0 0x01000000 0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index c5f8f69..15f57e6 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -29,7 +29,7 @@
memory at 48000000 {
device_type = "memory";
- /* first 128MB is reserved for secure area. */
+ /* first 128MiB is reserved for secure area. */
reg = <0x0 0x48000000 0x0 0x38000000>;
};
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 7a8986e..35f7cd2 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -52,7 +52,7 @@
memory at 48000000 {
device_type = "memory";
- /* first 128MB is reserved for secure area. */
+ /* first 128MiB is reserved for secure area. */
reg = <0x0 0x48000000 0x0 0x38000000>;
};
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index c3f064a..4d1295e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -28,7 +28,7 @@
memory at 48000000 {
device_type = "memory";
- /* first 128MB is reserved for secure area. */
+ /* first 128MiB is reserved for secure area. */
reg = <0x0 0x48000000 0x0 0x38000000>;
};
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index c7f40f8..2a019a3 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -28,7 +28,7 @@
memory at 48000000 {
device_type = "memory";
- /* first 128MB is reserved for secure area. */
+ /* first 128MiB is reserved for secure area. */
reg = <0x0 0x48000000 0x0 0x78000000>;
};
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index 1b67c37..56094e2 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -165,7 +165,7 @@ lr .req x30 // link register
/*
* Pseudo-ops for PC-relative adr/ldr/str <reg>, <symbol> where
- * <symbol> is within the range +/- 4 GB of the PC when running
+ * <symbol> is within the range +/- 4 GiB of the PC when running
* in core kernel context. In module context, a movz/movk sequence
* is used, since modules may be loaded far away from the kernel
* when KASLR is in effect.
diff --git a/arch/arm64/include/asm/boot.h b/arch/arm64/include/asm/boot.h
index ebf2481..95e26bc 100644
--- a/arch/arm64/include/asm/boot.h
+++ b/arch/arm64/include/asm/boot.h
@@ -6,14 +6,14 @@
/*
* arm64 requires the DTB to be 8 byte aligned and
- * not exceed 2MB in size.
+ * not exceed 2MiB in size.
*/
#define MIN_FDT_ALIGN 8
#define MAX_FDT_SIZE SZ_2M
/*
* arm64 requires the kernel image to placed
- * TEXT_OFFSET bytes beyond a 2 MB aligned base
+ * TEXT_OFFSET bytes beyond a 2 MiB aligned base
*/
#define MIN_KIMG_ALIGN SZ_2M
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 5d17004..28e63ff 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -156,7 +156,7 @@ struct linux_binprm;
extern int arch_setup_additional_pages(struct linux_binprm *bprm,
int uses_interp);
-/* 1GB of VA */
+/* 1GiB of VA */
#ifdef CONFIG_COMPAT
#define STACK_RND_MASK (test_thread_flag(TIF_32BIT) ? \
0x7ff >> (PAGE_SHIFT - 12) : \
diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
index caf86be..7e90ab2 100644
--- a/arch/arm64/include/asm/fixmap.h
+++ b/arch/arm64/include/asm/fixmap.h
@@ -37,13 +37,13 @@ enum fixed_addresses {
FIX_HOLE,
/*
- * Reserve a virtual window for the FDT that is 2 MB larger than the
+ * Reserve a virtual window for the FDT that is 2 MiB larger than the
* maximum supported size, and put it at the top of the fixmap region.
* The additional space ensures that any FDT that does not exceed
* MAX_FDT_SIZE can be mapped regardless of whether it crosses any
- * 2 MB alignment boundaries.
+ * 2 MiB alignment boundaries.
*
- * Keep this at the top so it remains 2 MB aligned.
+ * Keep this at the top so it remains 2 MiB aligned.
*/
#define FIX_FDT_SIZE (MAX_FDT_SIZE + SZ_2M)
FIX_FDT_END,
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 4fb6ccd..067ddd6 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -45,11 +45,11 @@
#define __PHYS_OFFSET (KERNEL_START - TEXT_OFFSET)
#if (TEXT_OFFSET & 0xfff) != 0
-#error TEXT_OFFSET must be at least 4KB aligned
+#error TEXT_OFFSET must be at least 4KiB aligned
#elif (PAGE_OFFSET & 0x1fffff) != 0
-#error PAGE_OFFSET must be at least 2MB aligned
+#error PAGE_OFFSET must be at least 2MiB aligned
#elif TEXT_OFFSET > 0x1fffff
-#error TEXT_OFFSET must be less than 2MB
+#error TEXT_OFFSET must be less than 2MiB
#endif
/*
@@ -360,7 +360,7 @@ ENDPROC(preserve_boot_args)
* Setup the initial page tables. We only setup the barest amount which is
* required to get the kernel running. The following sections are required:
* - identity mapping to enable the MMU (low address, TTBR0)
- * - first few MB of the kernel linear mapping to jump to once the MMU has
+ * - first few MiB of the kernel linear mapping to jump to once the MMU has
* been enabled
*/
__create_page_tables:
diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index d3b5f75..9585ea7 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -106,7 +106,7 @@ ENDPROC(\label)
* be called on each CPU.
*
* x0 must be the physical address of the new vector table, and must be
- * 2KB aligned.
+ * 2KiB aligned.
*
* Before calling this, you must check that the stub hypervisor is installed
* everywhere, by waiting for any secondary CPUs to be brought up and then
diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
index d7e90d9..a5a3068 100644
--- a/arch/arm64/kernel/kaslr.c
+++ b/arch/arm64/kernel/kaslr.c
@@ -118,9 +118,9 @@ u64 __init kaslr_early_init(u64 dt_phys, u64 modulo_offset)
* OK, so we are proceeding with KASLR enabled. Calculate a suitable
* kernel image offset from the seed. Let's place the kernel in the
* lower half of the VMALLOC area (VA_BITS - 2).
- * Even if we could randomize at page granularity for 16k and 64k pages,
- * let's always round to 2 MB so we don't interfere with the ability to
- * map using contiguous PTEs
+ * Even if we could randomize at page granularity for 16KiB and 64KiB
+ * pages, let's always round to 2 MiB so we don't interfere with the
+ * ability to map using contiguous PTEs
*/
mask = ((1UL << (VA_BITS - 2)) - 1) & ~(SZ_2M - 1);
offset = seed & mask;
@@ -129,10 +129,10 @@ u64 __init kaslr_early_init(u64 dt_phys, u64 modulo_offset)
memstart_offset_seed = seed >> 48;
/*
- * The kernel Image should not extend across a 1GB/32MB/512MB alignment
- * boundary (for 4KB/16KB/64KB granule kernels, respectively). If this
- * happens, increase the KASLR offset by the size of the kernel image
- * rounded up by SWAPPER_BLOCK_SIZE.
+ * The kernel Image should not extend across a 1GiB/32MiB/512MiB
+ * alignment boundary (for 4KiB/16KiB/64KiB granule kernels,
+ * respectively). If this happens, increase the KASLR offset by
+ * the size of the kernel image rounded up by SWAPPER_BLOCK_SIZE.
*/
if ((((u64)_text + offset + modulo_offset) >> SWAPPER_TABLE_SHIFT) !=
(((u64)_end + offset + modulo_offset) >> SWAPPER_TABLE_SHIFT)) {
diff --git a/arch/arm64/kernel/module-plts.c b/arch/arm64/kernel/module-plts.c
index 1ce90d8..0d66734 100644
--- a/arch/arm64/kernel/module-plts.c
+++ b/arch/arm64/kernel/module-plts.c
@@ -118,7 +118,7 @@ static unsigned int count_plts(Elf64_Sym *syms, Elf64_Rela *rela, int num)
* We only have to consider branch targets that resolve
* to undefined symbols. This is not simply a heuristic,
* it is a fundamental limitation, since the PLT itself
- * is part of the module, and needs to be within 128 MB
+ * is part of the module, and needs to be within 128 MiB
* as well, so modules can never grow beyond that limit.
*/
s = syms + ELF64_R_SYM(rela[i].r_info);
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index b8deffa..93b39d6 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -25,12 +25,12 @@ jiffies = jiffies_64;
#define HYPERVISOR_TEXT \
/* \
- * Align to 4 KB so that \
+ * Align to 4 KiB so that \
* a) the HYP vector table is at its minimum \
* alignment of 2048 bytes \
* b) the HYP init code will not cross a page \
* boundary if its size does not exceed \
- * 4 KB (see related ASSERT() below) \
+ * 4 KiB (see related ASSERT() below) \
*/ \
. = ALIGN(SZ_4K); \
VMLINUX_SYMBOL(__hyp_idmap_text_start) = .; \
@@ -60,7 +60,7 @@ jiffies = jiffies_64;
* The size of the PE/COFF section that covers the kernel image, which
* runs from stext to _edata, must be a round multiple of the PE/COFF
* FileAlignment, which we set to its minimum value of 0x200. 'stext'
- * itself is 4 KB aligned, so padding out _edata to a 0x200 aligned
+ * itself is 4 KiB aligned, so padding out _edata to a 0x200 aligned
* boundary should be sufficient.
*/
PECOFF_FILE_ALIGNMENT = 0x200;
@@ -74,16 +74,16 @@ PECOFF_FILE_ALIGNMENT = 0x200;
#if defined(CONFIG_DEBUG_ALIGN_RODATA)
/*
- * 4 KB granule: 1 level 2 entry
- * 16 KB granule: 128 level 3 entries, with contiguous bit
- * 64 KB granule: 32 level 3 entries, with contiguous bit
+ * 4 KiB granule: 1 level 2 entry
+ * 16 KiB granule: 128 level 3 entries, with contiguous bit
+ * 64 KiB granule: 32 level 3 entries, with contiguous bit
*/
#define SEGMENT_ALIGN SZ_2M
#else
/*
- * 4 KB granule: 16 level 3 entries, with contiguous bit
- * 16 KB granule: 4 level 3 entries, without contiguous bit
- * 64 KB granule: 1 level 3 entry
+ * 4 KiB granule: 16 level 3 entries, with contiguous bit
+ * 16 KiB granule: 4 level 3 entries, without contiguous bit
+ * 64 KiB granule: 1 level 3 entry
*/
#define SEGMENT_ALIGN SZ_64K
#endif
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index d28dbcf..5d8b743 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -229,7 +229,7 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
next = pud_addr_end(addr, end);
/*
- * For 4K granule only, attempt to put down a 1GB block
+ * For 4KiB granule only, attempt to put down a 1GiB block
*/
if (use_1G_block(addr, next, phys) && !page_mappings_only) {
pud_set_huge(pud, phys, prot);
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 877d42f..daba6ba 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -221,7 +221,7 @@ ENTRY(__cpu_setup)
bic x0, x0, x5 // clear bits
orr x0, x0, x6 // set bits
/*
- * Set/prepare TCR and TTBR. We use 512GB (39-bit) address range for
+ * Set/prepare TCR and TTBR. We use 512GiB (39-bit) address range for
* both user and kernel.
*/
ldr x10, =TCR_TxSZ(VA_BITS) | TCR_CACHE_FLAGS | TCR_SMP_FLAGS | \
--
2.9.3
--
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170413/6fa9d272/attachment.bin>
^ permalink raw reply related
* [PATCH] fs: Preventing READ_IMPLIES_EXEC Propagation
From: dongbo (E) @ 2017-04-13 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492088223-98232-1-git-send-email-zhangshaokun@hisilicon.com>
From: Dong Bo <dongbo4@huawei.com>
In load_elf_binary(), once the READ_IMPLIES_EXEC flag is set,
the flag is propagated to its child processes, even the elf
files are marked as not requiring executable stack. It may
cause superfluous operations on some arch, e.g.
__sync_icache_dcache on aarch64 due to a PROT_READ mmap is
also marked as PROT_EXEC.
Signed-off-by: Dong Bo <dongbo4@huawei.com>
---
fs/binfmt_elf.c | 2 ++
fs/binfmt_elf_fdpic.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 5075fd5..c52e670 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -863,6 +863,8 @@ static int load_elf_binary(struct linux_binprm *bprm)
SET_PERSONALITY2(loc->elf_ex, &arch_state);
if (elf_read_implies_exec(loc->elf_ex, executable_stack))
current->personality |= READ_IMPLIES_EXEC;
+ else
+ current->personality &= ~READ_IMPLIES_EXEC;
if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
current->flags |= PF_RANDOMIZE;
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index cf93a4f..c4bc4d0 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -354,6 +354,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm)
set_personality(PER_LINUX);
if (elf_read_implies_exec(&exec_params.hdr, executable_stack))
current->personality |= READ_IMPLIES_EXEC;
+ else
+ current->personality &= ~READ_IMPLIES_EXEC;
setup_new_exec(bprm);
-- 1.9.1
.
^ permalink raw reply related
* [PATCH RFC 0/5] *** SPI Slave mode support ***
From: Mark Brown @ 2017-04-13 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492085644-4195-1-git-send-email-jiada_wang@mentor.com>
On Thu, Apr 13, 2017 at 05:13:59AM -0700, jiada_wang at mentor.com wrote:
> From: Jiada Wang <jiada_wang@mentor.com>
>
> v1:
> add Slave mode support in SPI core
> spidev create slave device when SPI controller work in slave mode
> spi-imx support to work in slave mode
Adding Geert who also had a series doing this in progress that was
getting very near to being merged.
>
> Jiada Wang (5):
> spi: core: add support to work in Slave mode
> spi: spidev: use different name for SPI controller slave mode device
> spi: imx: add selection for iMX53 and iMX6 controller
> ARM: dts: imx: change compatiblity for SPI controllers on imx53 later
> soc
> spi: imx: Add support for SPI Slave mode for imx53 and imx6 chips
>
> Documentation/devicetree/bindings/spi/spi-bus.txt | 27 ++-
> Documentation/spi/spi-summary | 19 +-
> arch/arm/boot/dts/imx53.dtsi | 4 +-
> arch/arm/boot/dts/imx6q.dtsi | 2 +-
> arch/arm/boot/dts/imx6qdl.dtsi | 8 +-
> arch/arm/boot/dts/imx6sl.dtsi | 8 +-
> arch/arm/boot/dts/imx6sx.dtsi | 8 +-
> arch/arm/boot/dts/imx6ul.dtsi | 8 +-
> drivers/spi/Kconfig | 14 +-
> drivers/spi/spi-imx.c | 216 ++++++++++++++++++++--
> drivers/spi/spi.c | 23 ++-
> drivers/spi/spidev.c | 15 +-
> include/linux/spi/spi.h | 15 ++
> 13 files changed, 310 insertions(+), 57 deletions(-)
>
> --
> 2.7.4
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170413/739216d3/attachment.sig>
^ permalink raw reply
* [PATCH v2] serial: 8250_early: Add earlycon support for Palmchip UART
From: Mason @ 2017-04-13 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7a016ff6-08fc-2811-92e0-7c4603fa8586@sigmadesigns.com>
On 10/04/2017 11:47, Marc Gonzalez wrote:
> @@ -172,3 +179,20 @@ OF_EARLYCON_DECLARE(omap8250, "ti,omap3-uart", early_omap8250_setup);
> OF_EARLYCON_DECLARE(omap8250, "ti,omap4-uart", early_omap8250_setup);
>
> #endif
> +
> +#ifdef CONFIG_SERIAL_8250_RT288X
> +
> +unsigned int au_serial_in(struct uart_port *p, int offset);
> +void au_serial_out(struct uart_port *p, int offset, int value);
Hmmm, I'm thinking that putting declarations in a .c file might
not be a very popular decision... ?
Would there be a header, shared by 8250_early.c and 8250_port.c
where it might be appropriate to declare au_serial_in/out?
> +static int __init early_au_setup(struct earlycon_device *dev, const char *opt)
> +{
> + dev->port.serial_in = au_serial_in;
> + dev->port.serial_out = au_serial_out;
> + dev->port.iotype = UPIO_AU;
> + dev->con->write = early_serial8250_write;
> + return 0;
> +}
> +OF_EARLYCON_DECLARE(palmchip, "ralink,rt2880-uart", early_au_setup);
> +
> +#endif
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index 080d5a59d0a7..1f08d22d1a80 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -313,7 +313,7 @@ static const s8 au_io_out_map[8] = {
> -1, /* UART_SCR (unmapped) */
> };
>
> -static unsigned int au_serial_in(struct uart_port *p, int offset)
> +unsigned int au_serial_in(struct uart_port *p, int offset)
> {
> if (offset >= ARRAY_SIZE(au_io_in_map))
> return UINT_MAX;
> @@ -323,7 +323,7 @@ static unsigned int au_serial_in(struct uart_port *p, int offset)
> return __raw_readl(p->membase + (offset << p->regshift));
> }
>
> -static void au_serial_out(struct uart_port *p, int offset, int value)
> +void au_serial_out(struct uart_port *p, int offset, int value)
> {
> if (offset >= ARRAY_SIZE(au_io_out_map))
> return;
>
^ permalink raw reply
* [PATCH 0/8] i.MX7 PCIe related device tree changes
From: Andrey Smirnov @ 2017-04-13 13:32 UTC (permalink / raw)
To: linux-arm-kernel
Shawn, everyone:
This series includes changes made to device-tree in order to support
PCIe on i.MX7 platform. They include:
- Bringing 'anatop-enable-bit' property of ANATOP regulators back
and extending it to all of the HW it is applicable to
- Adding GPCv2 node for i.MX7 (which was missing, despite the
irqchip driver for it being in the tree for quite some time)
- Adding a PCIe node for i.MX7
- Adding GPIO expander used by PCIe and enabling PCIe node from
above on i.MX7 based Sabre board
As usual, feedback is welcome.
Thanks,
Andrey Smrinov
Andrey Smirnov (8):
Revert "ARM: dts: imx: Remove unexistant property"
ARM: dts: imx6: Specify 'anatop-enable-bit' where appropriate
ARM: dts: imx7s: Adjust anatop-enable-bit for 'reg_1p0d'
ARM: dts: imx7s: Add node for GPC
ARM: dts: imx7s: Mark 'gpr' compatible with i.MX6 variant
ARM: dts: imx7d-sdb: Add GPIO expander node
ARM: dts: imx7d: Add node for PCIe controller
ARM: dts: imx7d-sdb: Enable PCIe peripheral
arch/arm/boot/dts/imx6qdl.dtsi | 3 +++
arch/arm/boot/dts/imx6sl.dtsi | 3 +++
arch/arm/boot/dts/imx6sx.dtsi | 3 +++
arch/arm/boot/dts/imx6ul.dtsi | 1 +
arch/arm/boot/dts/imx7d-sdb.dts | 39 +++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx7d.dtsi | 38 ++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx7s.dtsi | 31 +++++++++++++++++++++++++++++--
7 files changed, 116 insertions(+), 2 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 1/8] Revert "ARM: dts: imx: Remove unexistant property"
From: Andrey Smirnov @ 2017-04-13 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413133242.5068-1-andrew.smirnov@gmail.com>
Commit ca7734a ("regulator: anatop: Add support for
"anatop-enable-bit"") added code to support this particular binding
and 'anatop-enable-bit' is no longer an unused property.
This reverts commit 27958ccdf29e9971732e02494b48be54b0691269.
Cc: yurovsky at gmail.com
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/imx6ul.dtsi | 1 +
arch/arm/boot/dts/imx7s.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index b9d7d2d..6da2b77 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -542,6 +542,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2625000>;
anatop-max-voltage = <3400000>;
+ anatop-enable-bit = <0>;
};
reg_arm: regulator-vddcore {
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index c4f12fd..22c9788 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -516,6 +516,7 @@
anatop-min-bit-val = <8>;
anatop-min-voltage = <800000>;
anatop-max-voltage = <1200000>;
+ anatop-enable-bit = <31>;
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH 2/8] ARM: dts: imx6: Specify 'anatop-enable-bit' where appropriate
From: Andrey Smirnov @ 2017-04-13 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413133242.5068-1-andrew.smirnov@gmail.com>
ENABLE_LINREG bit is implemented by 3P0, 1P1 and 2P5 regulators on
i.MX6. This property is present in similar code in Fresscale BSP and
made its way upstream in imx6ul.dtsi, so this patch adds this property
to the rest of i.MX6 family for completness.
Cc: yurovsky at gmail.com
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/imx6qdl.dtsi | 3 +++
arch/arm/boot/dts/imx6sl.dtsi | 3 +++
arch/arm/boot/dts/imx6sx.dtsi | 3 +++
3 files changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index e426faa..0576ef6 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -644,6 +644,7 @@
anatop-min-bit-val = <4>;
anatop-min-voltage = <800000>;
anatop-max-voltage = <1375000>;
+ anatop-enable-bit = <0>;
};
regulator-3p0 {
@@ -658,6 +659,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2625000>;
anatop-max-voltage = <3400000>;
+ anatop-enable-bit = <0>;
};
regulator-2p5 {
@@ -672,6 +674,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2100000>;
anatop-max-voltage = <2875000>;
+ anatop-enable-bit = <0>;
};
reg_arm: regulator-vddcore {
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index cc9572e..3243af4 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -530,6 +530,7 @@
anatop-min-bit-val = <4>;
anatop-min-voltage = <800000>;
anatop-max-voltage = <1375000>;
+ anatop-enable-bit = <0>;
};
regulator-3p0 {
@@ -544,6 +545,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2625000>;
anatop-max-voltage = <3400000>;
+ anatop-enable-bit = <0>;
};
regulator-2p5 {
@@ -558,6 +560,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2100000>;
anatop-max-voltage = <2850000>;
+ anatop-enable-bit = <0>;
};
reg_arm: regulator-vddcore {
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 3f1416b..f16b9df 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -587,6 +587,7 @@
anatop-min-bit-val = <4>;
anatop-min-voltage = <800000>;
anatop-max-voltage = <1375000>;
+ anatop-enable-bit = <0>;
};
regulator-3p0 {
@@ -601,6 +602,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2625000>;
anatop-max-voltage = <3400000>;
+ anatop-enable-bit = <0>;
};
regulator-2p5 {
@@ -615,6 +617,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2100000>;
anatop-max-voltage = <2875000>;
+ anatop-enable-bit = <0>;
};
reg_arm: regulator-vddcore {
--
2.9.3
^ permalink raw reply related
* [PATCH 3/8] ARM: dts: imx7s: Adjust anatop-enable-bit for 'reg_1p0d'
From: Andrey Smirnov @ 2017-04-13 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413133242.5068-1-andrew.smirnov@gmail.com>
In PMU_REG_1P0Dn ENABLE_LINREG is bit 0. Bit 31 is called OVERRIDE and
it serves the function of granting permission to GPC IP block to alter
various bit-fields of the register. The reason why this property, that
trickeld here from Freescale BSP, is set to 31 is because in the code
it came from it is used in conjunction with a notifier handler for
REGULATOR_EVENT_PRE_DO_ENABLE and REGULATOR_EVENT_PRE_DO_DISABLE
events (not found in upstream kernel) that triggers GPC to start
manipulating aforementioned other bitfields.
Since:
a) none of the aforementioned machinery is implemented by
upstream
b) using 'anatop-enable-bit' in that capacity is a bit of a
semantic stretch
simplify the situation by setting the value of 'anatop-enable-bit' to
point to ENABLE_LINREG (same as i.MX6).
Cc: yurovsky at gmail.com
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/imx7s.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 22c9788..8fee299 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -516,7 +516,7 @@
anatop-min-bit-val = <8>;
anatop-min-voltage = <800000>;
anatop-max-voltage = <1200000>;
- anatop-enable-bit = <31>;
+ anatop-enable-bit = <0>;
};
};
--
2.9.3
^ permalink raw reply related
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