* [PATCH ARM32 v4.4 V2 00/47] V4.4 backport of arm32 Spectre patches
From: Viresh Kumar @ 2019-08-01 8:15 UTC (permalink / raw)
To: stable
Cc: Mark Rutland, Julien Thierry, Marc Zyngier, Viresh Kumar,
guohanjun, Will Deacon, mark.brown, Catalin Marinas, Russell King,
linux-arm-kernel
Hello,
Here is an attempt to backport arm32 spectre patches to v4.4 stable
tree. This was last tried around an year back by David Long [1]. He was
backporting only a subset (18) of patches and this series include a lot
of other patches present in Russell's spectre branch.
Just like arm64 backport [2], KVM patches are dropped and they can be
backported separately if required.
Dropped patches (compared to Russell's spectre branch):
KVM related:
3f7e8e2e1ebd ARM: KVM: invalidate BTB on guest exit for Cortex-A12/A17
0c47ac8cd157 ARM: KVM: invalidate icache on guest exit for Cortex-A15
3c908e16396d ARM: spectre-v2: KVM: invalidate icache on guest exit for Brahma B15
b800acfc70d9 ARM: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling
add5609877c6 ARM: KVM: report support for SMCCC_ARCH_WORKAROUND_1
Dropped in 4.9 backport as well:
73839798af7e ARM: 8790/1: signal: always use __copy_to_user to save iwmmxt context
Additional patches picked to avoid rebase conflicts and build issues:
9f73bd8bb445 ARM: uaccess: remove put_user() code duplication
122e022eebb3 arch: Introduce post-init read-only memory
7b90ba3eb4af ARM: 8595/2: apply more __ro_after_init
SMCCC related patches, are part of arm64 backport [2] as well and all
KVM related changes are dropped from them:
56b35dfda10c ARM: 8478/2: arm/arm64: add arm-smccc
e6e9cc47cea9 arm/arm64: KVM: Advertise SMCCC v1.1
91958fe7a4eb arm64: KVM: Report SMCCC_ARCH_WORKAROUND_1 BP hardening support
1b232ad7ca05 drivers/firmware: Expose psci_get_version through psci_ops structure
df2030616c6f firmware/psci: Expose PSCI conduit
30f8c32765fd firmware/psci: Expose SMCCC version through psci_ops
17f6f98d5069 arm/arm64: smccc: Make function identifiers an unsigned quantity
e6d9b2fef81e arm/arm64: smccc: Implement SMCCC v1.1 inline primitive
All the patches are pushed here [3].
This is tested in Linaro Lava on Qemu_arm and X15 platforms and the
results are here [4]. Lava also check for some Spectre tests and one of
the test fails on x15 with this message:
CVE-2018-3640: VULN (an up-to-date CPU microcode is needed to mitigate
this vulnerability).
Perhaps this is an issue with x15 setup and not the patches themselves ?
I have also pushed this to be tested by kernel-ci, looks like my branch
isn't getting tested there currently. I am co-ordinating with them to
get it tested soon, we can start the review process until that time
though.
--
Viresh
[1] https://lore.kernel.org/stable/20181031140436.2964-1-dave.long@linaro.org/
[2] https://lore.kernel.org/stable/cover.1562908074.git.viresh.kumar@linaro.org/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git stable/arm32/v4.4.y/spectre
[4] https://staging-qa-reports.linaro.org/lkft/vishal.bhoj-stable-arm32-v4.4.y-spectre/build/v3.16-rc2-119419-g4ba6a2292f0e/
Ard Biesheuvel (1):
ARM: 8809/1: proc-v7: fix Thumb annotation of cpu_v7_hvc_switch_mm
Jens Wiklander (1):
ARM: 8478/2: arm/arm64: add arm-smccc
Julien Thierry (9):
ARM: 8789/1: signal: copy registers using __copy_to_user()
ARM: 8791/1: vfp: use __copy_to_user() when saving VFP state
ARM: 8792/1: oabi-compat: copy oabi events using __copy_to_user()
ARM: 8793/1: signal: replace __put_user_error with __put_user
ARM: 8794/1: uaccess: Prevent speculative use of the current
addr_limit
ARM: 8795/1: spectre-v1.1: use put_user() for __put_user()
ARM: 8796/1: spectre-v1,v1.1: provide helpers for address sanitization
ARM: 8797/1: spectre-v1.1: harden __copy_to_user
ARM: 8810/1: vfp: Fix wrong assignement to ufp_exc
Kees Cook (2):
arch: Introduce post-init read-only memory
ARM: 8595/2: apply more __ro_after_init
Marc Zyngier (6):
arm/arm64: KVM: Advertise SMCCC v1.1
arm64: KVM: Report SMCCC_ARCH_WORKAROUND_1 BP hardening support
firmware/psci: Expose PSCI conduit
firmware/psci: Expose SMCCC version through psci_ops
arm/arm64: smccc: Make function identifiers an unsigned quantity
arm/arm64: smccc: Implement SMCCC v1.1 inline primitive
Russell King (27):
ARM: add more CPU part numbers for Cortex and Brahma B15 CPUs
ARM: bugs: prepare processor bug infrastructure
ARM: bugs: hook processor bug checking into SMP and suspend paths
ARM: bugs: add support for per-processor bug checking
ARM: spectre: add Kconfig symbol for CPUs vulnerable to Spectre
ARM: spectre-v2: harden branch predictor on context switches
ARM: spectre-v2: add Cortex A8 and A15 validation of the IBE bit
ARM: spectre-v2: harden user aborts in kernel space
ARM: spectre-v2: add firmware based hardening
ARM: spectre-v2: warn about incorrect context switching functions
ARM: spectre-v1: add speculation barrier (csdb) macros
ARM: spectre-v1: add array_index_mask_nospec() implementation
ARM: spectre-v1: fix syscall entry
ARM: signal: copy registers using __copy_from_user()
ARM: vfp: use __copy_from_user() when restoring VFP state
ARM: oabi-compat: copy semops using __copy_from_user()
ARM: use __inttype() in get_user()
ARM: spectre-v1: use get_user() for __get_user()
ARM: spectre-v1: mitigate user accesses
ARM: uaccess: remove put_user() code duplication
ARM: make lookup_processor_type() non-__init
ARM: split out processor lookup
ARM: clean up per-processor check_bugs method call
ARM: add PROC_VTABLE and PROC_TABLE macros
ARM: spectre-v2: per-CPU vtables to work around big.Little systems
ARM: ensure that processor vtables is not lost after boot
ARM: fix the cockup in the previous patch
Will Deacon (1):
drivers/firmware: Expose psci_get_version through psci_ops structure
arch/arm/include/asm/assembler.h | 23 +++
arch/arm/include/asm/barrier.h | 32 ++++
arch/arm/include/asm/bugs.h | 6 +-
arch/arm/include/asm/cp15.h | 18 ++
arch/arm/include/asm/cputype.h | 9 +
arch/arm/include/asm/proc-fns.h | 65 +++++--
arch/arm/include/asm/system_misc.h | 15 ++
arch/arm/include/asm/thread_info.h | 8 +-
arch/arm/include/asm/uaccess.h | 176 +++++++++++--------
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/bugs.c | 18 ++
arch/arm/kernel/cpuidle.c | 2 +-
arch/arm/kernel/entry-common.S | 18 +-
arch/arm/kernel/entry-header.S | 25 +++
arch/arm/kernel/head-common.S | 6 +-
arch/arm/kernel/setup.c | 50 +++---
arch/arm/kernel/signal.c | 126 +++++++-------
arch/arm/kernel/smp.c | 38 +++-
arch/arm/kernel/suspend.c | 2 +
arch/arm/kernel/sys_oabi-compat.c | 16 +-
arch/arm/lib/copy_from_user.S | 5 +
arch/arm/lib/copy_to_user.S | 6 +-
arch/arm/lib/delay.c | 2 +-
arch/arm/lib/uaccess_with_memcpy.c | 3 +-
arch/arm/mm/Kconfig | 23 +++
arch/arm/mm/Makefile | 2 +-
arch/arm/mm/fault.c | 3 +
arch/arm/mm/mmu.c | 2 +-
arch/arm/mm/proc-macros.S | 13 +-
arch/arm/mm/proc-v7-2level.S | 6 -
arch/arm/mm/proc-v7-bugs.c | 161 +++++++++++++++++
arch/arm/mm/proc-v7.S | 154 +++++++++++++----
arch/arm/vfp/vfpmodule.c | 37 ++--
arch/parisc/include/asm/cache.h | 3 +
drivers/firmware/Kconfig | 3 +
drivers/firmware/psci.c | 58 ++++++-
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/arm-smccc.h | 267 +++++++++++++++++++++++++++++
include/linux/cache.h | 14 ++
include/linux/psci.h | 14 ++
40 files changed, 1174 insertions(+), 257 deletions(-)
create mode 100644 arch/arm/kernel/bugs.c
create mode 100644 arch/arm/mm/proc-v7-bugs.c
create mode 100644 include/linux/arm-smccc.h
--
2.21.0.rc0.269.g1a574e7a288b
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] serial: imx: Avoid probe failure in case of missing gpiolib
From: Schrempf Frieder @ 2019-08-01 8:18 UTC (permalink / raw)
To: Greg Kroah-Hartman, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
Schrempf Frieder, Jiri Slaby
From: Frieder Schrempf <frieder.schrempf@kontron.de>
If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() will return
-ENOSYS and cause the probing of the imx UART to fail. As the
GPIOs are optional, we should continue probing in this case.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
---
drivers/tty/serial/imx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 10db3e54ac9e..51714498dacf 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2237,7 +2237,9 @@ static int imx_uart_probe(struct platform_device *pdev)
timer_setup(&sport->timer, imx_uart_timeout, 0);
sport->gpios = mctrl_gpio_init(&sport->port, 0);
- if (IS_ERR(sport->gpios))
+ if (PTR_ERR(sport->gpios) == -ENOSYS)
+ sport->gpios = NULL;
+ else if (IS_ERR(sport->gpios))
return PTR_ERR(sport->gpios);
sport->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 3/5] arm64: atomics: avoid out-of-line ll/sc atomics
From: Andrew Murray @ 2019-08-01 8:12 UTC (permalink / raw)
To: Boqun Feng
Cc: Mark Rutland, Peter Zijlstra, Catalin Marinas, Will Deacon,
Ard.Biesheuvel, linux-arm-kernel
In-Reply-To: <20190801031004.GD26905@tardis>
On Thu, Aug 01, 2019 at 11:10:04AM +0800, Boqun Feng wrote:
> Hi Andrew,
>
> On Wed, Jul 31, 2019 at 05:12:54PM +0100, Andrew Murray wrote:
> [...]
> > +
> > +#define __lse_ll_sc_body(op, ...) \
> > +({ \
> > + system_uses_lse_atomics() ? \
> > + __lse_##op(__VA_ARGS__) : \
> > + __ll_sc_##op(__VA_ARGS__); \
> > +})
> > +
> > +#define ATOMIC_OP(op) \
> > +static inline void arch_##op(int i, atomic_t *v) \
> > +{ \
> > + __lse_ll_sc_body(op, i, v); \
> > +}
> > +
> > +ATOMIC_OP(atomic_andnot)
> > +ATOMIC_OP(atomic_or)
> > +ATOMIC_OP(atomic_xor)
> > +ATOMIC_OP(atomic_add)
> > +ATOMIC_OP(atomic_and)
> > +ATOMIC_OP(atomic_sub)
> > +
> > +
> > +#define ATOMIC_FETCH_OP(name, op) \
> > +static inline int arch_##op##name(int i, atomic_t *v) \
> > +{ \
> > + return __lse_ll_sc_body(op, i, v); \
>
> Color me blind if I'm wrong, but should't this be:
>
> return __lse_ll_sc_body(op##name, i, v); \
>
> ? Otherwise all variants will use the fully-ordered implementation.
Yes you're correct, thanks for spotting this (and below)!
Thanks,
Andrew Murray
>
> > +}
> > +
> > +#define ATOMIC_FETCH_OPS(op) \
> > + ATOMIC_FETCH_OP(_relaxed, op) \
> > + ATOMIC_FETCH_OP(_acquire, op) \
> > + ATOMIC_FETCH_OP(_release, op) \
> > + ATOMIC_FETCH_OP( , op)
> > +
> > +ATOMIC_FETCH_OPS(atomic_fetch_andnot)
> > +ATOMIC_FETCH_OPS(atomic_fetch_or)
> > +ATOMIC_FETCH_OPS(atomic_fetch_xor)
> > +ATOMIC_FETCH_OPS(atomic_fetch_add)
> > +ATOMIC_FETCH_OPS(atomic_fetch_and)
> > +ATOMIC_FETCH_OPS(atomic_fetch_sub)
> > +ATOMIC_FETCH_OPS(atomic_add_return)
> > +ATOMIC_FETCH_OPS(atomic_sub_return)
> > +
> > +
> > +#define ATOMIC64_OP(op) \
> > +static inline void arch_##op(long i, atomic64_t *v) \
> > +{ \
> > + __lse_ll_sc_body(op, i, v); \
> > +}
> > +
> > +ATOMIC64_OP(atomic64_andnot)
> > +ATOMIC64_OP(atomic64_or)
> > +ATOMIC64_OP(atomic64_xor)
> > +ATOMIC64_OP(atomic64_add)
> > +ATOMIC64_OP(atomic64_and)
> > +ATOMIC64_OP(atomic64_sub)
> > +
> > +
> > +#define ATOMIC64_FETCH_OP(name, op) \
> > +static inline long arch_##op##name(long i, atomic64_t *v) \
> > +{ \
> > + return __lse_ll_sc_body(op, i, v); \
>
> Ditto.
>
> Regards,
> Boqun
>
> > +}
> > +
> > +#define ATOMIC64_FETCH_OPS(op) \
> > + ATOMIC64_FETCH_OP(_relaxed, op) \
> > + ATOMIC64_FETCH_OP(_acquire, op) \
> > + ATOMIC64_FETCH_OP(_release, op) \
> > + ATOMIC64_FETCH_OP( , op)
> > +
> > +ATOMIC64_FETCH_OPS(atomic64_fetch_andnot)
> > +ATOMIC64_FETCH_OPS(atomic64_fetch_or)
> > +ATOMIC64_FETCH_OPS(atomic64_fetch_xor)
> > +ATOMIC64_FETCH_OPS(atomic64_fetch_add)
> > +ATOMIC64_FETCH_OPS(atomic64_fetch_and)
> > +ATOMIC64_FETCH_OPS(atomic64_fetch_sub)
> > +ATOMIC64_FETCH_OPS(atomic64_add_return)
> > +ATOMIC64_FETCH_OPS(atomic64_sub_return)
> > +
> > +
> [...]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: next/master boot: 265 boots: 17 failed, 184 passed with 64 offline (next-20190730)
From: Linus Walleij @ 2019-08-01 8:09 UTC (permalink / raw)
To: Timur Tabi
Cc: Kernel Build Reports Mailman List, Jeffrey Hugo, Lina Iyer,
Stephen Boyd, Mark Brown, Bjorn Andersson, Lee Jones, Linux ARM
In-Reply-To: <c2e5cd69-2f95-fc47-4541-17a1d744f003@kernel.org>
On Thu, Aug 1, 2019 at 5:49 AM Timur Tabi <timur@kernel.org> wrote:
> On 7/31/19 12:58 PM, Jeffrey Hugo wrote:
> >>>
> >>> Timur/Stephen: any ideas?
> >
> > Timur's CAF account is no longer valid, I added his @kernel one.
>
> Delete everything specific to the QDF2400.
It appears Mark is still using it in his test farm, and now its sole
role is finding bugs in my code. Which it did! With so much elegance
that we could fix it up quickly.
> Qualcomm has made it very clear that they have no interest in developing
> ARM server chips. No QDF2400 system ever made it to official production.
That's sad. I remember we had lots of discussions around this at the
time. The ACPI code base and quirks we added is however used in
other Qualcomm-based machines now (what Lee is doing), so the effort
is not wasted at all.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 1/2] mm: page_alloc: introduce memblock_next_valid_pfn() (again) for arm64
From: Ard Biesheuvel @ 2019-08-01 8:06 UTC (permalink / raw)
To: Hanjun Guo
Cc: Catalin Marinas, Linux Kernel Mailing List, Mike Rapoport,
Linux-MM, Jia He, Andrew Morton, Will Deacon, linux-arm-kernel
In-Reply-To: <1563861073-47071-2-git-send-email-guohanjun@huawei.com>
On Tue, 23 Jul 2019 at 08:53, Hanjun Guo <guohanjun@huawei.com> wrote:
>
> From: Jia He <hejianet@gmail.com>
>
> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
> where possible") optimized the loop in memmap_init_zone(). But it causes
> possible panic on x86 due to specific memory mapping on x86_64 which will
> skip valid pfns as well, so Daniel Vacek reverted it later.
>
> But as suggested by Daniel Vacek, it is fine to using memblock to skip
> gaps and finding next valid frame with CONFIG_HAVE_ARCH_PFN_VALID.
>
> Daniel said:
> "On arm and arm64, memblock is used by default. But generic version of
> pfn_valid() is based on mem sections and memblock_next_valid_pfn() does
> not always return the next valid one but skips more resulting in some
> valid frames to be skipped (as if they were invalid). And that's why
> kernel was eventually crashing on some !arm machines."
>
> Introduce a new config option CONFIG_HAVE_MEMBLOCK_PFN_VALID and only
> selected for arm64, using the new config option to guard the
> memblock_next_valid_pfn().
>
> This was tested on a HiSilicon Kunpeng920 based ARM64 server, the speedup
> is pretty impressive for bootmem_init() at boot:
>
> with 384G memory,
> before: 13310ms
> after: 1415ms
>
> with 1T memory,
> before: 20s
> after: 2s
>
> Suggested-by: Daniel Vacek <neelx@redhat.com>
> Signed-off-by: Jia He <hejianet@gmail.com>
> Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
> ---
> arch/arm64/Kconfig | 1 +
> include/linux/mmzone.h | 9 +++++++++
> mm/Kconfig | 3 +++
> mm/memblock.c | 31 +++++++++++++++++++++++++++++++
> mm/page_alloc.c | 4 +++-
> 5 files changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 697ea0510729..058eb26579be 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -893,6 +893,7 @@ config ARCH_FLATMEM_ENABLE
>
> config HAVE_ARCH_PFN_VALID
> def_bool y
> + select HAVE_MEMBLOCK_PFN_VALID
>
> config HW_PERF_EVENTS
> def_bool y
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 70394cabaf4e..24cb6bdb1759 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1325,6 +1325,10 @@ static inline int pfn_present(unsigned long pfn)
> #endif
>
> #define early_pfn_valid(pfn) pfn_valid(pfn)
> +#ifdef CONFIG_HAVE_MEMBLOCK_PFN_VALID
> +extern unsigned long memblock_next_valid_pfn(unsigned long pfn);
> +#define next_valid_pfn(pfn) memblock_next_valid_pfn(pfn)
> +#endif
> void sparse_init(void);
> #else
> #define sparse_init() do {} while (0)
> @@ -1347,6 +1351,11 @@ struct mminit_pfnnid_cache {
> #define early_pfn_valid(pfn) (1)
> #endif
>
> +/* fallback to default definitions */
> +#ifndef next_valid_pfn
> +#define next_valid_pfn(pfn) (pfn + 1)
> +#endif
> +
> void memory_present(int nid, unsigned long start, unsigned long end);
>
> /*
> diff --git a/mm/Kconfig b/mm/Kconfig
> index f0c76ba47695..c578374b6413 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -132,6 +132,9 @@ config HAVE_MEMBLOCK_NODE_MAP
> config HAVE_MEMBLOCK_PHYS_MAP
> bool
>
> +config HAVE_MEMBLOCK_PFN_VALID
> + bool
> +
> config HAVE_GENERIC_GUP
> bool
>
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 7d4f61ae666a..d57ba51bb9cd 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1251,6 +1251,37 @@ int __init_memblock memblock_set_node(phys_addr_t base, phys_addr_t size,
> return 0;
> }
> #endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
> +
> +#ifdef CONFIG_HAVE_MEMBLOCK_PFN_VALID
> +unsigned long __init_memblock memblock_next_valid_pfn(unsigned long pfn)
> +{
> + struct memblock_type *type = &memblock.memory;
> + unsigned int right = type->cnt;
> + unsigned int mid, left = 0;
> + phys_addr_t addr = PFN_PHYS(++pfn);
> +
> + do {
> + mid = (right + left) / 2;
> +
> + if (addr < type->regions[mid].base)
> + right = mid;
> + else if (addr >= (type->regions[mid].base +
> + type->regions[mid].size))
> + left = mid + 1;
> + else {
> + /* addr is within the region, so pfn is valid */
> + return pfn;
> + }
> + } while (left < right);
> +
> + if (right == type->cnt)
> + return -1UL;
> + else
> + return PHYS_PFN(type->regions[right].base);
> +}
> +EXPORT_SYMBOL(memblock_next_valid_pfn);
> +#endif /* CONFIG_HAVE_MEMBLOCK_PFN_VALID */
> +
> #ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT
> /**
> * __next_mem_pfn_range_in_zone - iterator for for_each_*_range_in_zone()
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index d66bc8abe0af..70933c40380a 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5811,8 +5811,10 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone,
> * function. They do not exist on hotplugged memory.
> */
> if (context == MEMMAP_EARLY) {
> - if (!early_pfn_valid(pfn))
> + if (!early_pfn_valid(pfn)) {
> + pfn = next_valid_pfn(pfn) - 1;
This is the thing I objected to previously: subtracting 1 so the pfn++
in the for() produces the correct value.
Could we instead pull the next() operation into the for() construct as
the third argument?
> continue;
> + }
> if (!early_pfn_in_nid(pfn, nid))
> continue;
> if (overlap_memmap_init(zone, &pfn))
> --
> 2.19.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 7:59 UTC (permalink / raw)
To: Sumit Garg
Cc: tee-dev @ lists . linaro . org, Daniel Thompson, Jonathan Corbet,
jejb, Ard Biesheuvel, Linux Doc Mailing List, James Morris,
Jarkko Sakkinen, Linux Kernel Mailing List, dhowells,
linux-security-module, keyrings, Mimi Zohar, Casey Schaufler,
linux-integrity, Jens Wiklander, linux-arm-kernel,
Serge E. Hallyn
In-Reply-To: <CAFA6WYMOXQbL5OeheFUFpTr8gte8XHHr-71-h8+qX0+R_sekDQ@mail.gmail.com>
On Thu, Aug 1, 2019 at 10:40 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > I chose the userspace plugin due to this, you can use userspace aids
> > to provide any type of service. Use the crypto library you desire to
> > do the magic you want.
>
> Here TEE isn't similar to a user-space crypto library. In our case TEE
> is based on ARM TrustZone which only allows TEE communications to be
> initiated from privileged mode. So why would you like to route
> communications via user-mode (which is less secure) when we have
> standardised TEE interface available in kernel?
The physical access guards for reading/writing the involved critical
memory are identical as far as I know? Layered security is generally a
good thing, and the userspace pass actually adds a layer, so not sure
which is really safer?
In my case the rerouting was to done generalize it. Any type of trust
source, anywhere.
> > > Isn't actual purpose to have trusted keys is to protect user-space
> > > from access to kernel keys in plain format? Doesn't user mode helper
> > > defeat that purpose in one way or another?
> >
> > Not really. CPU is in the user mode while running the code, but the
> > code or the secure keydata being is not available to the 'normal'
> > userspace. It's like microkernel service/driver this way. The usermode
> > driver is part of the kernel image and it runs on top of a invisible
> > rootfs.
>
> Can you elaborate here with an example regarding how this user-mode
> helper will securely communicate with a hardware based trust source
> with other user-space processes denied access to that trust source?
The other user mode processes will never see the device node to open.
There is none in existence for them; it only exists in the ramfs based
root for the user mode helper.
--
Janne
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
From: Artur Świgoń @ 2019-08-01 7:59 UTC (permalink / raw)
To: Georgi Djakov, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-pm, dri-devel
Cc: Bartłomiej Żołnierkiewicz, sw0312.kim, krzk,
inki.dae, cw00.choi, myungjoo.ham, m.szyprowski
In-Reply-To: <6e8b2081-2fb3-9ab8-37d1-8b5fe5fd8e11@linaro.org>
Hi Georgi,
On Fri, 2019-07-26 at 11:05 +0300, Georgi Djakov wrote:
> Hi Artur,
>
> On 7/23/19 15:20, Artur Świgoń wrote:
> > This patch adds interconnect functionality to the exynos-bus devfreq
> > driver.
> >
> > The SoC topology is a graph (or, more specifically, a tree) and most of its
> > edges are taken from the devfreq parent-child hierarchy (cf.
> > Documentation/devicetree/bindings/devfreq/exynos-bus.txt). The previous
> > patch adds missing edges to the DT (under the name 'parent'). Due to
> > unspecified relative probing order, -EPROBE_DEFER may be propagated to
> > guarantee that a child is probed before its parent.
> >
> > Each bus is now an interconnect provider and an interconnect node as well
> > (cf. Documentation/interconnect/interconnect.rst), i.e. every bus registers
> > itself as a node. Node IDs are not hardcoded but rather assigned at
> > runtime, in probing order (subject to the above-mentioned exception
> > regarding relative order). This approach allows for using this driver with
> > various Exynos SoCs.
>
> I am not familiar with the Exynos bus topology, but it seems to me that it's not
> represented correctly. An interconnect provider with just a single node (port)
> is odd. I would expect that each provider consists of multiple master and slave
> nodes. This data would be used by a framework to understand what are the links
> and how the traffic flows between the IP blocks and through which buses.
To summarize the exynos-bus topology[1] used by the devfreq driver: There are
many data buses for data transfer in Samsung Exynos SoC. Every bus has its own
clock. Buses often share power lines, in which case one of the buses on the
power line is referred to as 'parent' (or as 'devfreq' in the DT). In the
particular case of Exynos4412[1][2], the topology can be expressed as follows:
bus_dmc
-- bus_acp
-- bus_c2c
bus_leftbus
-- bus_rightbus
-- bus_display
-- bus_fsys
-- bus_peri
-- bus_mfc
Where bus_dmc and bus_leftbus probably could be referred to as masters, and the
following indented nodes as slaves. Patch 08/11 of this RFC additionally adds
the following to the DT:
bus_dmc
-- bus_leftbus
Which makes the topology a valid tree.
The exynos-bus concept in devfreq[3] is designed in such a way that every bus is
probed separately as a platform device, and is a largely independent entity.
This RFC proposes an extension to the existing devfreq driver that basically
provides a simple QoS to ensure minimum clock frequency for selected buses
(possibly overriding devfreq governor calculations) using the interconnect
framework.
The hierarchy is modelled in such a way that every bus is an interconnect node.
On the other hand, what is considered an interconnect provider here is quite
arbitrary, but for the reasons mentioned in the above paragraph, this RFC
assumes that every bus is a provider of itself as a node. Using an alternative
singleton provider approach was deemed more complicated since the 'dev' field in
'struct icc_provider' has to be set to something meaningful and we are tied to
the 'samsung,exynos-bus' compatible string in the driver (and multiple instances
of exynos-bus probed in indeterminate relative order).
I'm looking forward to hearing any additional thoughts you may have on this
topic.
Best regards,
--
Artur Świgoń
Samsung R&D Institute Poland
Samsung Electronics
[1] Documentation/devicetree/bindings/devfreq/exynos-bus.txt
[2]
arch/arm/boot/dts/exynos4412-odroid-common.dtsi
[3] drivers/devfreq/exynos-bus.c
(subject of this patch)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Sumit Garg @ 2019-08-01 7:58 UTC (permalink / raw)
To: Janne Karhunen
Cc: dhowells, Daniel Thompson, Rouven Czerwinski, Ard Biesheuvel,
jejb, Jonathan Corbet, Linux Doc Mailing List,
Linux Kernel Mailing List, Jarkko Sakkinen,
tee-dev @ lists . linaro . org, linux-security-module, keyrings,
Mimi Zohar, Casey Schaufler, linux-integrity, linux-arm-kernel,
Serge E. Hallyn
In-Reply-To: <CAE=NcraqD9FNM0Gk9UGhPGi3heVzZrAKGc1gNZxoe1OnDaQ=pA@mail.gmail.com>
On Thu, 1 Aug 2019 at 13:00, Janne Karhunen <janne.karhunen@gmail.com> wrote:
>
> On Thu, Aug 1, 2019 at 9:50 AM Rouven Czerwinski
> <r.czerwinski@pengutronix.de> wrote:
>
> > > I'm aware of it - I have implemented a large part of the GP TEE APIs
> > > earlier (primarily the crypto functions). Does the TEE you work with
> > > actually support GP properly? Can I take a look at the code?
> >
> > AFAIK Sumit is working with the OP-TEE implementation, which can be
> > found on github: https://github.com/op-tee/optee_os
>
> Thanks, I will take a look.
For documentation, refer to: https://optee.readthedocs.io/
> The fundamental problem with these things
> is that there are infinite amount of ways how TEEs and ROTs can be
> done in terms of the hardware and software. I really doubt there are 2
> implementations in existence that are even remotely compatible in real
> life.
I agree with you regarding implementation specific nature of TEE but
having a standardized client interface does solves the problem.
> As such, all things TEE/ROT would logically really belong in the
> userland and thanks to the bpfilter folks now the umh logic really
> makes that possible ... I think. The key implementation I did was just
> an RFC on the concept, what if we start to move the stuff that really
> belongs in the userspace to this pseudo-userland. It's not kernel, but
> it's not commonly accessible userland either. The shared memory would
> also work without any modifications between the umh based TEE/ROT
> driver and the userland if needed.
>
> Anyway, just my .02c. I guess having any new support in the kernel for
> new trust sources is good and improvement from the current state. I
> can certainly make my stuff work with your setup as well, what ever
> people think is the best.
Yes your implementation can very well fit under trusted keys
abstraction framework without creating a new keytype: "ext-trusted".
-Sumit
>
>
> --
> Janne
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/3] dt-bindings: reset: amlogic, meson-gxbb-reset: update with SPDX Licence identifier
From: Neil Armstrong @ 2019-08-01 7:54 UTC (permalink / raw)
To: p.zabel; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190801075454.23547-1-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../reset/amlogic,meson-gxbb-reset.h | 51 +------------------
1 file changed, 1 insertion(+), 50 deletions(-)
diff --git a/include/dt-bindings/reset/amlogic,meson-gxbb-reset.h b/include/dt-bindings/reset/amlogic,meson-gxbb-reset.h
index 524d6077ac1b..ea5058618863 100644
--- a/include/dt-bindings/reset/amlogic,meson-gxbb-reset.h
+++ b/include/dt-bindings/reset/amlogic,meson-gxbb-reset.h
@@ -1,56 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause */
/*
- * This file is provided under a dual BSD/GPLv2 license. When using or
- * redistributing this file, you may do so under either license.
- *
- * GPL LICENSE SUMMARY
- *
* Copyright (c) 2016 BayLibre, SAS.
* Author: Neil Armstrong <narmstrong@baylibre.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of version 2 of the GNU General Public License as
- * published by the Free Software Foundation.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see <http://www.gnu.org/licenses/>.
- * The full GNU General Public License is included in this distribution
- * in the file called COPYING.
- *
- * BSD LICENSE
- *
- * Copyright (c) 2016 BayLibre, SAS.
- * Author: Neil Armstrong <narmstrong@baylibre.com>
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * * Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in
- * the documentation and/or other materials provided with the
- * distribution.
- * * Neither the name of Intel Corporation nor the names of its
- * contributors may be used to endorse or promote products derived
- * from this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#ifndef _DT_BINDINGS_AMLOGIC_MESON_GXBB_RESET_H
#define _DT_BINDINGS_AMLOGIC_MESON_GXBB_RESET_H
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] dt-bindings: reset: amlogic, meson8b-reset: update with SPDX Licence identifier
From: Neil Armstrong @ 2019-08-01 7:54 UTC (permalink / raw)
To: p.zabel; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190801075454.23547-1-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../dt-bindings/reset/amlogic,meson8b-reset.h | 51 +------------------
1 file changed, 1 insertion(+), 50 deletions(-)
diff --git a/include/dt-bindings/reset/amlogic,meson8b-reset.h b/include/dt-bindings/reset/amlogic,meson8b-reset.h
index 614aff2c7aff..c614438bcbdb 100644
--- a/include/dt-bindings/reset/amlogic,meson8b-reset.h
+++ b/include/dt-bindings/reset/amlogic,meson8b-reset.h
@@ -1,56 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause */
/*
- * This file is provided under a dual BSD/GPLv2 license. When using or
- * redistributing this file, you may do so under either license.
- *
- * GPL LICENSE SUMMARY
- *
* Copyright (c) 2016 BayLibre, SAS.
* Author: Neil Armstrong <narmstrong@baylibre.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of version 2 of the GNU General Public License as
- * published by the Free Software Foundation.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see <http://www.gnu.org/licenses/>.
- * The full GNU General Public License is included in this distribution
- * in the file called COPYING.
- *
- * BSD LICENSE
- *
- * Copyright (c) 2016 BayLibre, SAS.
- * Author: Neil Armstrong <narmstrong@baylibre.com>
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * * Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in
- * the documentation and/or other materials provided with the
- * distribution.
- * * Neither the name of Intel Corporation nor the names of its
- * contributors may be used to endorse or promote products derived
- * from this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#ifndef _DT_BINDINGS_AMLOGIC_MESON8B_RESET_H
#define _DT_BINDINGS_AMLOGIC_MESON8B_RESET_H
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] reset: reset-meson: update with SPDX Licence identifier
From: Neil Armstrong @ 2019-08-01 7:54 UTC (permalink / raw)
To: p.zabel; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190801075454.23547-1-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/reset/reset-meson.c | 51 +------------------------------------
1 file changed, 1 insertion(+), 50 deletions(-)
diff --git a/drivers/reset/reset-meson.c b/drivers/reset/reset-meson.c
index 5242e0679df7..7d05d766e1ea 100644
--- a/drivers/reset/reset-meson.c
+++ b/drivers/reset/reset-meson.c
@@ -1,58 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
/*
* Amlogic Meson Reset Controller driver
*
- * This file is provided under a dual BSD/GPLv2 license. When using or
- * redistributing this file, you may do so under either license.
- *
- * GPL LICENSE SUMMARY
- *
- * Copyright (c) 2016 BayLibre, SAS.
- * Author: Neil Armstrong <narmstrong@baylibre.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of version 2 of the GNU General Public License as
- * published by the Free Software Foundation.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see <http://www.gnu.org/licenses/>.
- * The full GNU General Public License is included in this distribution
- * in the file called COPYING.
- *
- * BSD LICENSE
- *
* Copyright (c) 2016 BayLibre, SAS.
* Author: Neil Armstrong <narmstrong@baylibre.com>
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * * Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in
- * the documentation and/or other materials provided with the
- * distribution.
- * * Neither the name of Intel Corporation nor the names of its
- * contributors may be used to endorse or promote products derived
- * from this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#include <linux/err.h>
#include <linux/init.h>
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] reset: meson: update with SPDX Licence identifier
From: Neil Armstrong @ 2019-08-01 7:54 UTC (permalink / raw)
To: p.zabel; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
This serie updates the Amlogic Reset driver and bindings.
Neil Armstrong (3):
reset: reset-meson: update with SPDX Licence identifier
dt-bindings: reset: amlogic,meson-gxbb-reset: update with SPDX Licence
identifier
dt-bindings: reset: amlogic,meson8b-reset: update with SPDX Licence
identifier
drivers/reset/reset-meson.c | 51 +------------------
.../reset/amlogic,meson-gxbb-reset.h | 51 +------------------
.../dt-bindings/reset/amlogic,meson8b-reset.h | 51 +------------------
3 files changed, 3 insertions(+), 150 deletions(-)
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: stm32: add DFSDM pins to stm32mp157c
From: Olivier Moysan @ 2019-08-01 7:46 UTC (permalink / raw)
To: linux-stm32, alexandre.torgue, robh, mark.rutland, devicetree,
linux-arm-kernel, linux-kernel, olivier.moysan
Add DFSDM pins to stm32mp157c.
Signed-off-by: Olivier Moysan <olivier.moysan@st.com>
---
arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 39 +++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
index 9eaec9bf8cb8..f96a928cbc49 100644
--- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
@@ -230,6 +230,45 @@
};
};
+ dfsdm_clkout_pins_a: dfsdm-clkout-pins-0 {
+ pins {
+ pinmux = <STM32_PINMUX('B', 13, AF3)>; /* DFSDM_CKOUT */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ };
+
+ dfsdm_clkout_sleep_pins_a: dfsdm-clkout-sleep-pins-0 {
+ pins {
+ pinmux = <STM32_PINMUX('B', 13, ANALOG)>; /* DFSDM_CKOUT */
+ };
+ };
+
+ dfsdm_data1_pins_a: dfsdm-data1-pins-0 {
+ pins {
+ pinmux = <STM32_PINMUX('C', 3, AF3)>; /* DFSDM_DATA1 */
+ };
+ };
+
+ dfsdm_data1_sleep_pins_a: dfsdm-data1-sleep-pins-0 {
+ pins {
+ pinmux = <STM32_PINMUX('C', 3, ANALOG)>; /* DFSDM_DATA1 */
+ };
+ };
+
+ dfsdm_data3_pins_a: dfsdm-data3-pins-0 {
+ pins {
+ pinmux = <STM32_PINMUX('F', 13, AF6)>; /* DFSDM_DATA3 */
+ };
+ };
+
+ dfsdm_data3_sleep_pins_a: dfsdm-data3-sleep-pins-0 {
+ pins {
+ pinmux = <STM32_PINMUX('F', 13, ANALOG)>; /* DFSDM_DATA3 */
+ };
+ };
+
ethernet0_rgmii_pins_a: rgmii-0 {
pins1 {
pinmux = <STM32_PINMUX('G', 5, AF11)>, /* ETH_RGMII_CLK125 */
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4.4 V2 25/43] arm64: Move BP hardening to check_and_switch_context
From: Viresh Kumar @ 2019-08-01 7:41 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Julien Thierry, Marc Zyngier, Greg KH, Will Deacon,
stable, mark.brown, linux-arm-kernel, Catalin Marinas,
Russell King, julien.thierry.kdev
In-Reply-To: <20190801073444.4n45h6kcbmejvzte@willie-the-truck>
On 01-08-19, 08:34, Will Deacon wrote:
> On Thu, Aug 01, 2019 at 12:35:41PM +0530, Viresh Kumar wrote:
> > On 01-08-19, 08:57, Greg KH wrote:
> > > On Thu, Aug 01, 2019 at 12:05:44PM +0530, Viresh Kumar wrote:
> > > > On 01-08-19, 07:30, Julien Thierry wrote:
> > > > > I must admit I am not familiar with backport/stable process enough. But
> > > > > personally I think the your suggestion seems more sensible than
> > > > > backporting 4 patches.
> > > > >
> > > > > Or you can maybe ignore patch 25 and say in patch 24 that among the
> > > > > changes made for the 4.4 codebase, the call arm64_apply_bp_hardening()
> > > > > was moved from post_ttbr_update_workaround as it doesn't exist and
> > > > > placed in check_and_switch_context() as it is its final destination.
> > > >
> > > > Done that and dropped the other two patches.
> > > >
> > > > > However, I really don't know what's the best way to proceed according to
> > > > > existing practices. So input from someone else would be welcome.
> > > >
> > > > Lets see if someone comes up and ask me to do something else :)
> > >
> > > Keeping the same patches that upstream has is almost always the better
> > > thing to do in the long-run.
> >
> > That would require two additional patches to be backported, 22 and 23
> > from this series. From your suggestion it seems that keeping them is
> > better here ?
>
> Yes. Backporting individual patches as they appear upstream is definitely
> the preferred method for -stable. It makes the relationship to mainline
> crystal clear, as well as any dependencies between patches that have been
> backported. Everytime we tweak something unecessarily in a stable backport,
> it just creates the potential for confusion and additional conflicts in
> future backports, so it's best to follow the shape of upstream as closely as
> possible, even if it results in additional patches.
>
> So I wouldn't worry about total number of patches. I'd worry more about
> things like conflicts, deviation from mainline and overall testing coverage.
Okay, I won't make these changes then. Thanks.
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Sumit Garg @ 2019-08-01 7:40 UTC (permalink / raw)
To: Janne Karhunen
Cc: tee-dev @ lists . linaro . org, Daniel Thompson, Jonathan Corbet,
jejb, Ard Biesheuvel, Linux Doc Mailing List, James Morris,
Jarkko Sakkinen, Linux Kernel Mailing List, dhowells,
linux-security-module, keyrings, Mimi Zohar, Casey Schaufler,
linux-integrity, Jens Wiklander, linux-arm-kernel,
Serge E. Hallyn
In-Reply-To: <CAE=NcraDkm5cxE=ceq_9XkQz=NZ6KdVXkNUsdD4G2LrWz-bpDw@mail.gmail.com>
On Thu, 1 Aug 2019 at 11:51, Janne Karhunen <janne.karhunen@gmail.com> wrote:
>
> On Wed, Jul 31, 2019 at 4:58 PM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> > > To clarify a bit further - my thought was to support any type of trust
> > > source.
> >
> > That could be very well accomplished via Trusted Keys abstraction
> > framework [1]. A trust source just need to implement following APIs:
> >
> > struct trusted_key_ops ts_trusted_key_ops = {
> > .migratable = 0, /* non-migratable */
> > .init = init_ts_trusted,
> > .seal = ts_key_seal,
> > .unseal = ts_key_unseal,
> > .get_random = ts_get_random,
> > .cleanup = cleanup_ts_trusted,
> > };
>
> Which is basically the same as implementing a new keytype in the
> kernel; abstraction is not raised in any considerable manner this way?
>
It doesn't create a new keytype. There is only single keytype:
"trusted" which could be implemented via one of the trust source
available in the system like TPM, TEE etc.
> I chose the userspace plugin due to this, you can use userspace aids
> to provide any type of service. Use the crypto library you desire to
> do the magic you want.
Here TEE isn't similar to a user-space crypto library. In our case TEE
is based on ARM TrustZone which only allows TEE communications to be
initiated from privileged mode. So why would you like to route
communications via user-mode (which is less secure) when we have
standardised TEE interface available in kernel?
>
>
> > > With the
> > > user mode helper in between anyone can easily add their own thing in
> > > there.
> >
> > Isn't actual purpose to have trusted keys is to protect user-space
> > from access to kernel keys in plain format? Doesn't user mode helper
> > defeat that purpose in one way or another?
>
> Not really. CPU is in the user mode while running the code, but the
> code or the secure keydata being is not available to the 'normal'
> userspace. It's like microkernel service/driver this way. The usermode
> driver is part of the kernel image and it runs on top of a invisible
> rootfs.
>
Can you elaborate here with an example regarding how this user-mode
helper will securely communicate with a hardware based trust source
with other user-space processes denied access to that trust source?
-Sumit
>
> --
> Janne
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/4] arm64: Make debug exception handlers visible from RCU
From: Will Deacon @ 2019-08-01 7:37 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Dan Rue, Daniel Diaz, Anders Roxell, Catalin Marinas,
Naresh Kamboju, Will Deacon, linux-kernel, Matt Hart,
Paul E . McKenney, linux-arm-kernel
In-Reply-To: <20190801143225.e61e38ce7a701407b19f8008@kernel.org>
Hi Masami,
On Thu, Aug 01, 2019 at 02:32:25PM +0900, Masami Hiramatsu wrote:
> On Wed, 31 Jul 2019 18:26:03 +0100
> Will Deacon <will@kernel.org> wrote:
> > On Thu, Jul 25, 2019 at 05:16:15PM +0900, Masami Hiramatsu wrote:
> > > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > > index 9568c116ac7f..ed6c55c87fdc 100644
> > > --- a/arch/arm64/mm/fault.c
> > > +++ b/arch/arm64/mm/fault.c
> > > @@ -777,6 +777,42 @@ void __init hook_debug_fault_code(int nr,
> > > debug_fault_info[nr].name = name;
> > > }
> > >
> > > +/*
> > > + * In debug exception context, we explicitly disable preemption.
> >
> > Maybe add "despite having interrupts disabled"?
>
> OK, I'll add it.
>
> > > + * This serves two purposes: it makes it much less likely that we would
> > > + * accidentally schedule in exception context and it will force a warning
> > > + * if we somehow manage to schedule by accident.
> > > + */
> > > +static void debug_exception_enter(struct pt_regs *regs)
> > > +{
> > > + if (user_mode(regs)) {
> > > + RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
> > > + } else {
> > > + /*
> > > + * We might have interrupted pretty much anything. In
> > > + * fact, if we're a debug exception, we can even interrupt
> > > + * NMI processing. We don't want this code makes in_nmi()
> > > + * to return true, but we need to notify RCU.
> > > + */
> > > + rcu_nmi_enter();
> > > + }
> > > +
> > > + preempt_disable();
> >
> > If you're addingt new functions for entry/exit, maybe move the
> > trace_hardirqs_{on,off}() calls in here too?
>
> OK, let's move it in these functions.
Brill, thanks. Please just resend this patch, as I can pick the other three
up as they are.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4.4 V2 25/43] arm64: Move BP hardening to check_and_switch_context
From: Will Deacon @ 2019-08-01 7:34 UTC (permalink / raw)
To: Viresh Kumar
Cc: Mark Rutland, Julien Thierry, Marc Zyngier, Greg KH, Will Deacon,
stable, mark.brown, linux-arm-kernel, Catalin Marinas,
Russell King, julien.thierry.kdev
In-Reply-To: <20190801070541.hpmadulgp45txfem@vireshk-i7>
On Thu, Aug 01, 2019 at 12:35:41PM +0530, Viresh Kumar wrote:
> On 01-08-19, 08:57, Greg KH wrote:
> > On Thu, Aug 01, 2019 at 12:05:44PM +0530, Viresh Kumar wrote:
> > > On 01-08-19, 07:30, Julien Thierry wrote:
> > > > I must admit I am not familiar with backport/stable process enough. But
> > > > personally I think the your suggestion seems more sensible than
> > > > backporting 4 patches.
> > > >
> > > > Or you can maybe ignore patch 25 and say in patch 24 that among the
> > > > changes made for the 4.4 codebase, the call arm64_apply_bp_hardening()
> > > > was moved from post_ttbr_update_workaround as it doesn't exist and
> > > > placed in check_and_switch_context() as it is its final destination.
> > >
> > > Done that and dropped the other two patches.
> > >
> > > > However, I really don't know what's the best way to proceed according to
> > > > existing practices. So input from someone else would be welcome.
> > >
> > > Lets see if someone comes up and ask me to do something else :)
> >
> > Keeping the same patches that upstream has is almost always the better
> > thing to do in the long-run.
>
> That would require two additional patches to be backported, 22 and 23
> from this series. From your suggestion it seems that keeping them is
> better here ?
Yes. Backporting individual patches as they appear upstream is definitely
the preferred method for -stable. It makes the relationship to mainline
crystal clear, as well as any dependencies between patches that have been
backported. Everytime we tweak something unecessarily in a stable backport,
it just creates the potential for confusion and additional conflicts in
future backports, so it's best to follow the shape of upstream as closely as
possible, even if it results in additional patches.
So I wouldn't worry about total number of patches. I'd worry more about
things like conflicts, deviation from mainline and overall testing coverage.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/14] ARM: move lpc32xx and dove to multiplatform
From: Arnd Bergmann @ 2019-08-01 7:33 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, LINUXWATCHDOG, Jason Cooper, David S. Miller,
Greg Kroah-Hartman, Linus Walleij, USB list, Vladimir Zapolskiy,
open list:GPIO SUBSYSTEM, soc, Networking, Alan Stern,
Guenter Roeck, linux-serial, Sylvain Lemieux, Gregory Clement,
Linux ARM, Sebastian Hesselbarth
In-Reply-To: <20190731225303.GC1330@shell.armlinux.org.uk>
On Thu, Aug 1, 2019 at 12:53 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Wed, Jul 31, 2019 at 09:56:42PM +0200, Arnd Bergmann wrote:
> > For dove, the patches are basically what I had proposed back in
> > 2015 when all other ARMv6/ARMv7 machines became part of a single
> > kernel build. I don't know what the state is mach-dove support is,
> > compared to the DT based support in mach-mvebu for the same
> > hardware. If they are functionally the same, we could also just
> > remove mach-dove rather than applying my patches.
>
> Well, the good news is that I'm down to a small board support file
> for the Dove Cubox now - but the bad news is, that there's still a
> board support file necessary to support everything the Dove SoC has
> to offer.
>
> Even for a DT based Dove Cubox, I'm still using mach-dove, but it
> may be possible to drop most of mach-dove now. Without spending a
> lot of time digging through it, it's impossible to really know.
Ok, so we won't remove it then, but I'd like to merge my patches to
at least get away from the special case of requiring a separate kernel
image for it.
Can you try if applying patches 12 and 14 from my series causes
problems for you? (it may be easier to apply the entire set
or pull from [1] to avoid rebase conflicts).
Arnd
[1] kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git mach-cleanup-5.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 7:30 UTC (permalink / raw)
To: Rouven Czerwinski
Cc: Sumit Garg, Daniel Thompson, Ard Biesheuvel, jejb,
Jonathan Corbet, Linux Doc Mailing List,
Linux Kernel Mailing List, Jarkko Sakkinen,
tee-dev @ lists . linaro . org, linux-security-module, keyrings,
Mimi Zohar, dhowells, Casey Schaufler, linux-integrity,
linux-arm-kernel, Serge E. Hallyn
In-Reply-To: <19d9be198619e951750dedeb4d0a7f372083b42c.camel@pengutronix.de>
On Thu, Aug 1, 2019 at 9:50 AM Rouven Czerwinski
<r.czerwinski@pengutronix.de> wrote:
> > I'm aware of it - I have implemented a large part of the GP TEE APIs
> > earlier (primarily the crypto functions). Does the TEE you work with
> > actually support GP properly? Can I take a look at the code?
>
> AFAIK Sumit is working with the OP-TEE implementation, which can be
> found on github: https://github.com/op-tee/optee_os
Thanks, I will take a look. The fundamental problem with these things
is that there are infinite amount of ways how TEEs and ROTs can be
done in terms of the hardware and software. I really doubt there are 2
implementations in existence that are even remotely compatible in real
life. As such, all things TEE/ROT would logically really belong in the
userland and thanks to the bpfilter folks now the umh logic really
makes that possible ... I think. The key implementation I did was just
an RFC on the concept, what if we start to move the stuff that really
belongs in the userspace to this pseudo-userland. It's not kernel, but
it's not commonly accessible userland either. The shared memory would
also work without any modifications between the umh based TEE/ROT
driver and the userland if needed.
Anyway, just my .02c. I guess having any new support in the kernel for
new trust sources is good and improvement from the current state. I
can certainly make my stuff work with your setup as well, what ever
people think is the best.
--
Janne
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mmc: atmel-mci: Mark expected switch fall-throughs
From: Ludovic Desroches @ 2019-08-01 7:11 UTC (permalink / raw)
To: Kees Cook
Cc: Stephen Rothwell, Ulf Hansson, Alexandre Belloni,
Gustavo A. R. Silva, linux-mmc, linux-kernel, linux-arm-kernel
In-Reply-To: <201907310905.B90C6E25@keescook>
On Wed, Jul 31, 2019 at 09:06:07AM -0700, Kees Cook wrote:
> On Wed, Jul 31, 2019 at 01:32:16PM +0200, Ludovic Desroches wrote:
> > > drivers/mmc/host/atmel-mci.c:2426:40: warning: this statement may fall through [-Wimplicit-fallthrough=]
> > > host->caps.need_notbusy_for_read_ops = 1;
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
> > > drivers/mmc/host/atmel-mci.c:2427:2: note: here
> > > case 0x100:
> > > ^~~~
> > >
> > > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> >
> > I don't know if there is a policy in the kernel about the expression to
> > use. As this one does the job
>
> Yup, documented here:
> https://www.kernel.org/doc/html/latest/process/deprecated.html#implicit-switch-case-fall-through
Thanks for the pointer.
Regards
Ludovic
>
> > Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
>
> Thanks!
>
> --
> Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] Re: [Patch v3 1/2] dt-bindings: spi: spi-fsl-qspi: Add ls2080a compatibility string to bindings
From: Ashish Kumar @ 2019-08-01 7:09 UTC (permalink / raw)
To: Rob Herring, Han Xu, broonie@kernel.org
Cc: devicetree@vger.kernel.org, bbrezillon@kernel.org, Kuldeep Singh,
Leo Li, linux-mtd@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <VE1PR04MB66874A887C5BE6209A4AE90F8FDF0@VE1PR04MB6687.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Leo Li
> Sent: Thursday, August 1, 2019 4:57 AM
> To: Ashish Kumar <ashish.kumar@nxp.com>; Rob Herring
> <robh@kernel.org>; Han Xu <han.xu@nxp.com>
> Cc: devicetree@vger.kernel.org; bbrezillon@kernel.org; broonie@kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-mtd@lists.infradead.org; Kuldeep
> Singh <kuldeep.singh@nxp.com>
> Subject: RE: [EXT] Re: [Patch v3 1/2] dt-bindings: spi: spi-fsl-qspi: Add ls2080a
> compatibility string to bindings
>
>
>
> > -----Original Message-----
> > From: Ashish Kumar
> > Sent: Monday, July 29, 2019 4:11 AM
> > To: Rob Herring <robh@kernel.org>; Leo Li <leoyang.li@nxp.com>
> > Cc: devicetree@vger.kernel.org; bbrezillon@kernel.org;
> > broonie@kernel.org; linux-arm-kernel@lists.infradead.org;
> > linux-mtd@lists.infradead.org; Kuldeep Singh <kuldeep.singh@nxp.com>
> > Subject: RE: [EXT] Re: [Patch v3 1/2] dt-bindings: spi: spi-fsl-qspi:
> > Add ls2080a compatibility string to bindings
> >
> >
> >
> > > -----Original Message-----
> > > From: Rob Herring <robh@kernel.org>
> > > Sent: Wednesday, July 10, 2019 1:39 AM
> > > To: Ashish Kumar <ashish.kumar@nxp.com>
> > > Cc: devicetree@vger.kernel.org; bbrezillon@kernel.org;
> > > broonie@kernel.org; linux-arm-kernel@lists.infradead.org;
> > > linux-mtd@lists.infradead.org; Ashish Kumar <ashish.kumar@nxp.com>;
> > > Kuldeep Singh <kuldeep.singh@nxp.com>; Ashish Kumar
> > > <ashish.kumar@nxp.com>
> > > Subject: [EXT] Re: [Patch v3 1/2] dt-bindings: spi: spi-fsl-qspi:
> > > Add ls2080a compatibility string to bindings
> > >
> > > Caution: EXT Email
> > >
> > > On Wed, 19 Jun 2019 16:41:53 +0530, Ashish Kumar wrote:
> > > > There are 2 version of QSPI-IP, according to which controller
> > > > registers sets can be big endian or little endian.There are some
> > > > other minor changes like RX fifo depth etc.
> > > >
> > > > The big endian version uses driver compatible "fsl,ls1021a-qspi"
> > > > and little endian version uses driver compatible "fsl,ls2080a-qspi"
> > > >
> > > > Signed-off-by: Kuldeep Singh <kuldeep.singh@nxp.com>
> > > > Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> > > > ---
> > > > v3:
> > > > Rebase to top
> > > > v2:
> > > > Convert to patch series and rebasing done on top of tree
> > > >
> > > > Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt | 3 +--
> > > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > > >
> > >
> > > Reviewed-by: Rob Herring <robh@kernel.org>
> >
> > Hi Leo,
> >
> > I think Rob, is waiting for you ack.
>
> Binding patches usually go through subsystem tree. So I think this actually
> need ack from qspi maintainer Han Xu and be picked up by SPI maintainer.
Hello Han Xu,
Could you please ack this few of my dts patches are dependent on this, waiting to be pushed from Shawn's tree.
Regards
Ashish
>
> Regards,
> Leo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] Re: [Patch v3 2/2] dt-bindings: spi: spi-fsl-qspi: Add bindings of ls1088a and ls1012a
From: Ashish Kumar @ 2019-08-01 7:09 UTC (permalink / raw)
To: Rob Herring, Han Xu, broonie@kernel.org
Cc: devicetree@vger.kernel.org, bbrezillon@kernel.org, Kuldeep Singh,
Leo Li, linux-mtd@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <VE1PR04MB66879C5045A813E7311534D68FDF0@VE1PR04MB6687.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Leo Li
> Sent: Thursday, August 1, 2019 4:59 AM
> To: Ashish Kumar <ashish.kumar@nxp.com>; Rob Herring
> <robh@kernel.org>; Han Xu <han.xu@nxp.com>
> Cc: devicetree@vger.kernel.org; bbrezillon@kernel.org; broonie@kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-mtd@lists.infradead.org; Kuldeep
> Singh <kuldeep.singh@nxp.com>
> Subject: RE: [EXT] Re: [Patch v3 2/2] dt-bindings: spi: spi-fsl-qspi: Add
> bindings of ls1088a and ls1012a
>
>
>
> > -----Original Message-----
> > From: Ashish Kumar
> > Sent: Monday, July 29, 2019 4:09 AM
> > To: Rob Herring <robh@kernel.org>; Leo Li <leoyang.li@nxp.com>
> > Cc: devicetree@vger.kernel.org; bbrezillon@kernel.org;
> > broonie@kernel.org; linux-arm-kernel@lists.infradead.org;
> > linux-mtd@lists.infradead.org; Kuldeep Singh <kuldeep.singh@nxp.com>
> > Subject: RE: [EXT] Re: [Patch v3 2/2] dt-bindings: spi: spi-fsl-qspi:
> > Add bindings of ls1088a and ls1012a
> >
> >
> >
> > > -----Original Message-----
> > > From: Rob Herring <robh@kernel.org>
> > > Sent: Wednesday, July 10, 2019 1:39 AM
> > > To: Ashish Kumar <ashish.kumar@nxp.com>
> > > Cc: devicetree@vger.kernel.org; bbrezillon@kernel.org;
> > > broonie@kernel.org; linux-arm-kernel@lists.infradead.org;
> > > linux-mtd@lists.infradead.org; Ashish Kumar <ashish.kumar@nxp.com>;
> > > Kuldeep Singh <kuldeep.singh@nxp.com>; Ashish Kumar
> > > <ashish.kumar@nxp.com>
> > > Subject: [EXT] Re: [Patch v3 2/2] dt-bindings: spi: spi-fsl-qspi:
> > > Add bindings of ls1088a and ls1012a
> > >
> > > Caution: EXT Email
> > >
> > > On Wed, 19 Jun 2019 16:41:54 +0530, Ashish Kumar wrote:
> > > > Signed-off-by: Kuldeep Singh <kuldeep.singh@nxp.com>
> > > > Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> > > > ---
> > > > v3:
> > > > Rebase to top
> > > > v2:
> > > > Convert to patch series and rebasing done on top of tree
> > > >
> > > > Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > >
> > > Reviewed-by: Rob Herring <robh@kernel.org>
> >
> > Hi Leo,
> >
> > I think Rob, is waiting for you ack.
>
> Binding patches usually go through subsystem tree. So I think this actually
> need ack from qspi maintainer Han Xu and be picked up by SPI maintainer.
Ok.
Hello Han Xu,
Could you please ack this few of my dts patches are dependent on this, waiting to be pushed from Shawn's tree.
Regards
Ashish
>
> Regards,
> Leo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4.4 V2 25/43] arm64: Move BP hardening to check_and_switch_context
From: Viresh Kumar @ 2019-08-01 7:05 UTC (permalink / raw)
To: Greg KH
Cc: Mark Rutland, Julien Thierry, Marc Zyngier, Catalin Marinas,
Will Deacon, stable, mark.brown, julien.thierry.kdev,
Russell King, linux-arm-kernel
In-Reply-To: <20190801065700.GA17391@kroah.com>
On 01-08-19, 08:57, Greg KH wrote:
> On Thu, Aug 01, 2019 at 12:05:44PM +0530, Viresh Kumar wrote:
> > On 01-08-19, 07:30, Julien Thierry wrote:
> > > I must admit I am not familiar with backport/stable process enough. But
> > > personally I think the your suggestion seems more sensible than
> > > backporting 4 patches.
> > >
> > > Or you can maybe ignore patch 25 and say in patch 24 that among the
> > > changes made for the 4.4 codebase, the call arm64_apply_bp_hardening()
> > > was moved from post_ttbr_update_workaround as it doesn't exist and
> > > placed in check_and_switch_context() as it is its final destination.
> >
> > Done that and dropped the other two patches.
> >
> > > However, I really don't know what's the best way to proceed according to
> > > existing practices. So input from someone else would be welcome.
> >
> > Lets see if someone comes up and ask me to do something else :)
>
> Keeping the same patches that upstream has is almost always the better
> thing to do in the long-run.
That would require two additional patches to be backported, 22 and 23
from this series. From your suggestion it seems that keeping them is
better here ?
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add Geert as Renesas SoC Co-Maintainer
From: Simon Horman @ 2019-08-01 7:00 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Stephen Rothwell, Arnd Bergmann, Kevin Hilman, Magnus Damm,
linux-kernel, linux-renesas-soc, Olof Johansson, Linus Torvalds,
linux-arm-kernel
In-Reply-To: <20190729175658.13672-1-geert+renesas@glider.be>
On Mon, Jul 29, 2019 at 07:56:58PM +0200, Geert Uytterhoeven wrote:
> At the end of the v5.3 upstream kernel development cycle, Simon will be
> stepping down from his role as Renesas SoC maintainer. Starting with
> the v5.4 development cycle, Geert is taking over this role.
>
> Add Geert as a co-maintainer, and add his git repository and branch.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Stephen: Can you please add my branch to linux-next, after Simon's
> branch, which may still receive fixes for v5.3?
>
> Thanks!
> ---
> MAINTAINERS | 4 ++++
> 1 file changed, 4 insertions(+)
For the record:
Acked-by: Simon Horman <horms+renesas@verge.net.au>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6426db5198f05377..6de667021591fb52 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2155,10 +2155,12 @@ F: Documentation/devicetree/bindings/arm/realtek.txt
>
> ARM/RENESAS ARM64 ARCHITECTURE
> M: Simon Horman <horms@verge.net.au>
> +M: Geert Uytterhoeven <geert+renesas@glider.be>
> M: Magnus Damm <magnus.damm@gmail.com>
> L: linux-renesas-soc@vger.kernel.org
> Q: http://patchwork.kernel.org/project/linux-renesas-soc/list/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git next
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git next
> S: Supported
> F: arch/arm64/boot/dts/renesas/
> F: Documentation/devicetree/bindings/arm/renesas.yaml
> @@ -2269,10 +2271,12 @@ F: drivers/media/platform/s5p-mfc/
>
> ARM/SHMOBILE ARM ARCHITECTURE
> M: Simon Horman <horms@verge.net.au>
> +M: Geert Uytterhoeven <geert+renesas@glider.be>
> M: Magnus Damm <magnus.damm@gmail.com>
> L: linux-renesas-soc@vger.kernel.org
> Q: http://patchwork.kernel.org/project/linux-renesas-soc/list/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git next
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git next
> S: Supported
> F: arch/arm/boot/dts/emev2*
> F: arch/arm/boot/dts/gr-peach*
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4.4 V2 25/43] arm64: Move BP hardening to check_and_switch_context
From: Greg KH @ 2019-08-01 6:57 UTC (permalink / raw)
To: Viresh Kumar
Cc: Mark Rutland, Julien Thierry, Marc Zyngier, Catalin Marinas,
Will Deacon, stable, mark.brown, julien.thierry.kdev,
Russell King, linux-arm-kernel
In-Reply-To: <20190801063544.ruw444isj5uojjdx@vireshk-i7>
On Thu, Aug 01, 2019 at 12:05:44PM +0530, Viresh Kumar wrote:
> On 01-08-19, 07:30, Julien Thierry wrote:
> > I must admit I am not familiar with backport/stable process enough. But
> > personally I think the your suggestion seems more sensible than
> > backporting 4 patches.
> >
> > Or you can maybe ignore patch 25 and say in patch 24 that among the
> > changes made for the 4.4 codebase, the call arm64_apply_bp_hardening()
> > was moved from post_ttbr_update_workaround as it doesn't exist and
> > placed in check_and_switch_context() as it is its final destination.
>
> Done that and dropped the other two patches.
>
> > However, I really don't know what's the best way to proceed according to
> > existing practices. So input from someone else would be welcome.
>
> Lets see if someone comes up and ask me to do something else :)
Keeping the same patches that upstream has is almost always the better
thing to do in the long-run.
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox