* Re: [PATCH] xmon: Clear all breakpoints when xmon is disabled via debugfs
From: Balbir Singh @ 2018-03-04 21:27 UTC (permalink / raw)
To: Vaibhav Jain
Cc: Michael Ellerman, Frederic Barrat,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
linux-kernel@vger.kernel.org, Benjamin Herrenschmidt,
Paul Mackerras, Nicholas Piggin, Douglas Miller
In-Reply-To: <20180304173132.19677-1-vaibhav@linux.vnet.ibm.com>
On Mon, Mar 5, 2018 at 4:31 AM, Vaibhav Jain <vaibhav@linux.vnet.ibm.com> wrote:
> Presently when xmon is disabled by debugfs any existing
> instruction/data-access breakpoints set are not disabled. This may
> lead to kernel oops when those breakpoints are hit as the necessary
> debugger hooks aren't installed.
>
> Hence this patch introduces a new function named clear_all_bpt()
> which is called when xmon is disabled via debugfs. The function will
> unpatch/clear all the trap and ciabr/dab based breakpoints.
>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
> ---
Reviewed-by: Balbir Singh <bsingharora@gmail.com>
Balbir
^ permalink raw reply
* Re: [PATCH v2] xmon: Setup xmon debugger hooks when first break-point is set
From: Balbir Singh @ 2018-03-04 21:29 UTC (permalink / raw)
To: Vaibhav Jain
Cc: Michael Ellerman, Frederic Barrat,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
linux-kernel@vger.kernel.org, Benjamin Herrenschmidt,
Paul Mackerras, Nicholas Piggin, Douglas Miller
In-Reply-To: <20180304173025.19520-1-vaibhav@linux.vnet.ibm.com>
On Mon, Mar 5, 2018 at 4:30 AM, Vaibhav Jain <vaibhav@linux.vnet.ibm.com> wrote:
> Presently sysrq key for xmon('x') is registered during kernel init
> irrespective of the value of kernel param 'xmon'. Thus xmon is enabled
> even if 'xmon=off' is passed on the kernel command line. However this
> doesn't enable the kernel debugger hooks needed for instruction or data
> breakpoints. Thus when a break-point is hit with xmon=off a kernel oops
> of the form below is reported:
>
> Oops: Exception in kernel mode, sig: 5 [#1]
> < snip >
> Trace/breakpoint trap
>
> To fix this the patch checks and enables debugger hooks when an
> instruction or data break-point is set via xmon console.
>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
> ---
Reviewed-by: Balbir Singh <bsingharora@gmail.com>
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/64s/idle: POWER9 ESL=0 stop avoid save/restore overhead
From: Paul Mackerras @ 2018-03-04 23:01 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: Vaidyanathan Srinivasan, linuxppc-dev, Gautham R . Shenoy
In-Reply-To: <20180301215734.6602315e@roar.ozlabs.ibm.com>
On Thu, Mar 01, 2018 at 09:57:34PM +1000, Nicholas Piggin wrote:
> On Thu, 1 Mar 2018 00:04:39 +0530
> Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> wrote:
>
> > * Nicholas Piggin <npiggin@gmail.com> [2017-11-18 00:08:07]:
[snip]
> > > diff --git a/arch/powerpc/platforms/powernv/idle.c b/arch/powerpc/platforms/powernv/idle.c
> > > index a921d5428d76..610b1637c16f 100644
> > > --- a/arch/powerpc/platforms/powernv/idle.c
> > > +++ b/arch/powerpc/platforms/powernv/idle.c
> > > @@ -621,7 +621,12 @@ static int __init pnv_power9_idle_init(struct device_node *np, u32 *flags,
> > > continue;
> > > }
> > >
> > > - if (max_residency_ns < residency_ns[i]) {
> > > + /*
> > > + * Deepest stop for unplug must be PSSCR[EC]=1 (wakeup at
> > > + * 0x100.
> > > + */
> > > + if ((max_residency_ns < residency_ns[i])&&
> > > + (psscr_val[i] & PSSCR_EC)) {
> > > max_residency_ns = residency_ns[i];
> > > pnv_deepest_stop_psscr_val = psscr_val[i];
> > > pnv_deepest_stop_psscr_mask = psscr_mask[i];
> >
> > If firmware did not provide any ESL=EC=1 state, we can still leave
> > threads in stop ESL=0 state. This is just a corner case or random
> > test scenario. Why do we want to enforce that offline cpus really use
> > a ESL=0 state or just spin?
>
> It's because power9_offline_stop only has cases for EC=ESL=1
> states now.
>
> It actually looks like EC=ESL=0 unplug today is broken KVM, because
> the wakeup side does not check HWTHREAD_REQ, and yet they do set
> HWTHREAD_IN_IDLE. That would probably hang in KVM if we run with
> dependent threads, wouldn't it?
Right. KVM with indep_threads_mode=N is broken at the moment if you
run with powersave=off or if firmware provides no stop states with
EC=ESL=1. I'm not sure what's the best way to fix that.
> I think banning it for now should be okay.
Banning what exactly?
Paul.
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Fix guest time accounting with VIRT_CPU_ACCOUNTING_GEN
From: Paul Mackerras @ 2018-03-04 22:49 UTC (permalink / raw)
To: Laurent Vivier
Cc: linux-kernel, linuxppc-dev, kvm-ppc, David Gibson, Paolo Bonzini
In-Reply-To: <20180302105156.19506-1-lvivier@redhat.com>
On Fri, Mar 02, 2018 at 11:51:56AM +0100, Laurent Vivier wrote:
> Since commit 8b24e69fc47e ("KVM: PPC: Book3S HV: Close race with testing
> for signals on guest entry"), if CONFIG_VIRT_CPU_ACCOUNTING_GEN is set, the
> guest time is not accounted to guest time and user time, but instead to
> system time.
>
> This is because guest_enter()/guest_exit() are called while interrupts
> are disabled and the tick counter cannot be updated between them.
>
> To fix that, move guest_exit() after local_irq_enable(), and as
> guest_enter() is called with IRQ disabled, calls guest_enter_irqoff()
> instead.
>
> Fixes: 8b24e69fc47e
> ("KVM: PPC: Book3S HV: Close race with testing for signals on guest entry")
> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Thanks, applied to my kvm-ppc-fixes branch.
Paul.
^ permalink raw reply
* [PATCH V2 15/27] cpufreq: powernv: Don't validate the frequency table twice
From: Viresh Kumar @ 2018-03-05 4:19 UTC (permalink / raw)
To: Rafael Wysocki, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
Cc: Viresh Kumar, linux-pm, Vincent Guittot, linuxppc-dev
In-Reply-To: <3120e4db4ae3bc014d198a206f46be1305ec65e8.1519620578.git.viresh.kumar@linaro.org>
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from powernv driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V1->V2:
- s/powerenv/powernv/
drivers/cpufreq/powernv-cpufreq.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
index 29cdec198657..0591874856d3 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -812,7 +812,7 @@ static int powernv_cpufreq_target_index(struct cpufreq_policy *policy,
static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
- int base, i, ret;
+ int base, i;
struct kernfs_node *kn;
struct global_pstate_info *gpstates;
@@ -848,15 +848,10 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
gpstates->timer.expires = jiffies +
msecs_to_jiffies(GPSTATE_TIMER_INTERVAL);
spin_lock_init(&gpstates->gpstate_lock);
- ret = cpufreq_table_validate_and_show(policy, powernv_freqs);
-
- if (ret < 0) {
- kfree(policy->driver_data);
- return ret;
- }
+ policy->freq_table = powernv_freqs;
policy->fast_switch_possible = true;
- return ret;
+ return 0;
}
static int powernv_cpufreq_cpu_exit(struct cpufreq_policy *policy)
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* Re: [PATCH 1/2] powerpc/perf: Fix kernel address leak to userspace via BHRB buffer
From: Balbir Singh @ 2018-03-05 6:16 UTC (permalink / raw)
To: Madhavan Srinivasan
Cc: Michael Ellerman, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)
In-Reply-To: <1520164518-19097-1-git-send-email-maddy@linux.vnet.ibm.com>
On Sun, Mar 4, 2018 at 10:55 PM, Madhavan Srinivasan
<maddy@linux.vnet.ibm.com> wrote:
> The current Branch History Rolling Buffer (BHRB) code does
> not check for any privilege levels before updating the data
> from BHRB. This leaks kernel addresses to userspace even when
> profiling only with userspace privileges. Add proper checks
> to prevent it.
>
> Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
> ---
> arch/powerpc/perf/core-book3s.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index f89bbd54ecec..337db5831749 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -457,6 +457,10 @@ static void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
> /* invalid entry */
> continue;
>
> + if (perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN) &&
> + is_kernel_addr(addr))
> + continue;
> +
Looks good to me. The scope of the leaks concern is KASLR related or
something else (figuring out what's in the cache?)
Acked-by: Balbir Singh <bsingharora@gmail.com>
Balbir Singh.
^ permalink raw reply
* Re: [PATCH AUTOSEL for 4.9 005/219] kretprobes: Ensure probe location is at function entry
From: Naveen N. Rao @ 2018-03-05 7:02 UTC (permalink / raw)
To: Sasha Levin, linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Arnaldo Carvalho de Melo, Ananth N Mavinakayanahalli,
linuxppc-dev@lists.ozlabs.org, Michael Ellerman, Steven Rostedt,
Masami Hiramatsu
In-Reply-To: <20180303222716.26640-5-alexander.levin@microsoft.com>
Hi Sasha,
Sasha Levin wrote:
> From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
>=20
> [ Upstream commit 90ec5e89e393c76e19afc845d8f88a5dc8315919 ]
>=20
Sorry if this is obvious, but why was this patch picked up for -stable? =20
I don't see the upstream commit tagging -stable, so curious why this was=20
done.
I don't think this patch should be pushed to -stable since this is not=20
really a bug fix. There are also other dependencies for this change (see=20
commit a64e3f35a45f4a, for instance), including how userspace (perf)=20
builds out the retprobe argument. As such, please drop this from -stable=20
(for 3.18. 4.4 and 4.9).
Thanks,
Naveen
=
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/perf: Fix the kernel address leak to userspace via SDAR
From: Naveen N. Rao @ 2018-03-05 8:21 UTC (permalink / raw)
To: Madhavan Srinivasan, mpe; +Cc: linuxppc-dev
In-Reply-To: <1520164518-19097-2-git-send-email-maddy@linux.vnet.ibm.com>
Madhavan Srinivasan wrote:
> Sampled Data Address Register (SDAR) is a 64-bit
> register that contains the effective address of
> the storage operand of an instruction that was
> being executed, possibly out-of-order, at or around
> the time that the Performance Monitor alert occurred.
>=20
> In certain scenario SDAR happen to contain the kernel
> address even for userspace only sampling. Add checks
> to prevent it.
>=20
> Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
> ---
> arch/powerpc/perf/core-book3s.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>=20
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-boo=
k3s.c
> index 337db5831749..c4525323d691 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -95,7 +95,7 @@ static inline unsigned long perf_ip_adjust(struct pt_re=
gs *regs)
> {
> return 0;
> }
> -static inline void perf_get_data_addr(struct pt_regs *regs, u64 *addrp) =
{ }
> +static inline void perf_get_data_addr(struct pt_regs *regs, u64 *addrp, =
struct perf_event *event) { }
> static inline u32 perf_get_misc_flags(struct pt_regs *regs)
> {
> return 0;
> @@ -174,7 +174,7 @@ static inline unsigned long perf_ip_adjust(struct pt_=
regs *regs)
> * pointed to by SIAR; this is indicated by the [POWER6_]MMCRA_SDSYNC, t=
he
> * [POWER7P_]MMCRA_SDAR_VALID bit in MMCRA, or the SDAR_VALID bit in SIE=
R.
> */
> -static inline void perf_get_data_addr(struct pt_regs *regs, u64 *addrp)
> +static inline void perf_get_data_addr(struct pt_regs *regs, u64 *addrp, =
struct perf_event *event)
> {
> unsigned long mmcra =3D regs->dsisr;
> bool sdar_valid;
> @@ -198,6 +198,11 @@ static inline void perf_get_data_addr(struct pt_regs=
*regs, u64 *addrp)
>=20
> if (!(mmcra & MMCRA_SAMPLE_ENABLE) || sdar_valid)
> *addrp =3D mfspr(SPRN_SDAR);
> +
> + if (perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN) &&
> + (event->attr.exclude_kernel || event->attr.exclude_hv) &&
I may be missing something, but if !capable(CAP_SYS_ADMIN), should we=20
still check the exclude_kernel/exclude_hv fields in the event attribute? =20
Aren't those user controlled?
- Naveen
> + is_kernel_addr(mfspr(SPRN_SDAR)))
> + *addrp =3D 0;
> }
>=20
> static bool regs_sihv(struct pt_regs *regs)
> @@ -2054,7 +2059,7 @@ static void record_and_restart(struct perf_event *e=
vent, unsigned long val,
>=20
> if (event->attr.sample_type &
> (PERF_SAMPLE_ADDR | PERF_SAMPLE_PHYS_ADDR))
> - perf_get_data_addr(regs, &data.addr);
> + perf_get_data_addr(regs, &data.addr, event);
>=20
> if (event->attr.sample_type & PERF_SAMPLE_BRANCH_STACK) {
> struct cpu_hw_events *cpuhw;
> --=20
> 2.7.4
>=20
>=20
=
^ permalink raw reply
* Re: [PATCH v3 02/10] include: Move compat_timespec/ timeval to compat_time.h
From: Christian Borntraeger @ 2018-03-05 9:30 UTC (permalink / raw)
To: Deepa Dinamani, tglx, john.stultz
Cc: linux-kernel, arnd, y2038, acme, benh, catalin.marinas, cmetcalf,
cohuck, davem, deller, devel, gerald.schaefer, gregkh,
heiko.carstens, hoeppner, hpa, jejb, jwi, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, mark.rutland, mingo, mpe,
oberpar, oprofile-list, paulus, peterz, ralf, rostedt, rric,
schwidefsky, sebott, sparclinux, sth, ubraun, will.deacon, x86
In-Reply-To: <20180116021818.24791-3-deepa.kernel@gmail.com>
On 01/16/2018 03:18 AM, Deepa Dinamani wrote:
> All the current architecture specific defines for these
> are the same. Refactor these common defines to a common
> header file.
>
> The new common linux/compat_time.h is also useful as it
> will eventually be used to hold all the defines that
> are needed for compat time types that support non y2038
> safe types. New architectures need not have to define these
> new types as they will only use new y2038 safe syscalls.
> This file can be deleted after y2038 when we stop supporting
> non y2038 safe syscalls.
You are now include a <linux/*.h> from several asm files
(
arch/arm64/include/asm/stat.h
arch/s390/include/asm/elf.h
arch/x86/include/asm/ftrace.h
arch/x86/include/asm/sys_ia32.h
)
It works, and it is done in many places, but it looks somewhat weird.
Would it make sense to have an asm-generic/compate-time.h instead? Asking for
opinions here.
>
> The patch also requires an operation similar to:
>
> git grep "asm/compat\.h" | cut -d ":" -f 1 | xargs -n 1 sed -i -e "s%asm/compat.h%linux/compat.h%g"
some comments from the s390 perspective:
> --- a/arch/s390/hypfs/hypfs_sprp.c
> +++ b/arch/s390/hypfs/hypfs_sprp.c
ok.
[...]
> --- a/arch/s390/include/asm/elf.h
> +++ b/arch/s390/include/asm/elf.h
> @@ -126,7 +126,7 @@
> */
>
> #include <asm/ptrace.h>
> -#include <asm/compat.h>
> +#include <linux/compat.h>
> #include <asm/syscall.h>
> #include <asm/user.h>
see above.
[...]
> --- a/arch/s390/kvm/priv.c
> +++ b/arch/s390/kvm/priv.c
ok
> --- a/arch/s390/pci/pci_clp.c
> +++ b/arch/s390/pci/pci_clp.c
ok
> --- a/drivers/s390/block/dasd_ioctl.c
> +++ b/drivers/s390/block/dasd_ioctl.c
ok
> --- a/drivers/s390/char/fs3270.c
> +++ b/drivers/s390/char/fs3270.c
ok
> --- a/drivers/s390/char/sclp_ctl.c
> +++ b/drivers/s390/char/sclp_ctl.c
ok
> --- a/drivers/s390/char/vmcp.c
> +++ b/drivers/s390/char/vmcp.c
ok
> --- a/drivers/s390/cio/chsc_sch.c
> +++ b/drivers/s390/cio/chsc_sch.c
ok
> --- a/drivers/s390/net/qeth_core_main.c
> +++ b/drivers/s390/net/qeth_core_main.c
> @@ -32,7 +32,7 @@
> #include <asm/chpid.h>
> #include <asm/io.h>
> #include <asm/sysinfo.h>
> -#include <asm/compat.h>
> +#include <linux/compat.h>
> #include <asm/diag.h>
> #include <asm/cio.h>
> #include <asm/ccwdev.h>
Can you move that into the other includes (where all the other <linux/*> includes are.
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/64s/idle: POWER9 ESL=0 stop avoid save/restore overhead
From: Nicholas Piggin @ 2018-03-05 9:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Vaidyanathan Srinivasan, linuxppc-dev, Gautham R . Shenoy
In-Reply-To: <20180304230101.GC14569@fergus.ozlabs.ibm.com>
On Mon, 5 Mar 2018 10:01:01 +1100
Paul Mackerras <paulus@ozlabs.org> wrote:
> On Thu, Mar 01, 2018 at 09:57:34PM +1000, Nicholas Piggin wrote:
> > On Thu, 1 Mar 2018 00:04:39 +0530
> > Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> wrote:
> >
> > > * Nicholas Piggin <npiggin@gmail.com> [2017-11-18 00:08:07]:
> [snip]
> > > > diff --git a/arch/powerpc/platforms/powernv/idle.c b/arch/powerpc/platforms/powernv/idle.c
> > > > index a921d5428d76..610b1637c16f 100644
> > > > --- a/arch/powerpc/platforms/powernv/idle.c
> > > > +++ b/arch/powerpc/platforms/powernv/idle.c
> > > > @@ -621,7 +621,12 @@ static int __init pnv_power9_idle_init(struct device_node *np, u32 *flags,
> > > > continue;
> > > > }
> > > >
> > > > - if (max_residency_ns < residency_ns[i]) {
> > > > + /*
> > > > + * Deepest stop for unplug must be PSSCR[EC]=1 (wakeup at
> > > > + * 0x100.
> > > > + */
> > > > + if ((max_residency_ns < residency_ns[i])&&
> > > > + (psscr_val[i] & PSSCR_EC)) {
> > > > max_residency_ns = residency_ns[i];
> > > > pnv_deepest_stop_psscr_val = psscr_val[i];
> > > > pnv_deepest_stop_psscr_mask = psscr_mask[i];
> > >
> > > If firmware did not provide any ESL=EC=1 state, we can still leave
> > > threads in stop ESL=0 state. This is just a corner case or random
> > > test scenario. Why do we want to enforce that offline cpus really use
> > > a ESL=0 state or just spin?
> >
> > It's because power9_offline_stop only has cases for EC=ESL=1
> > states now.
> >
> > It actually looks like EC=ESL=0 unplug today is broken KVM, because
> > the wakeup side does not check HWTHREAD_REQ, and yet they do set
> > HWTHREAD_IN_IDLE. That would probably hang in KVM if we run with
> > dependent threads, wouldn't it?
>
> Right. KVM with indep_threads_mode=N is broken at the moment if you
> run with powersave=off or if firmware provides no stop states with
> EC=ESL=1. I'm not sure what's the best way to fix that.
For EC=ESL=1, would it be enough to do a test and branch right
after the stop instruction?
> > I think banning it for now should be okay.
>
> Banning what exactly?
power9 CPU unplug using a EC=ESL=0 stop state.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v8 18/24] mm: Provide speculative fault infrastructure
From: Laurent Dufour @ 2018-03-05 10:50 UTC (permalink / raw)
To: Daniel Jordan, paulmck, peterz, akpm, kirill, ak, mhocko, dave,
jack, Matthew Wilcox, benh, mpe, paulus, Thomas Gleixner,
Ingo Molnar, hpa, Will Deacon, Sergey Senozhatsky,
Andrea Arcangeli, Alexei Starovoitov, kemi.wang,
sergey.senozhatsky.work
Cc: linux-kernel, linux-mm, haren, khandual, npiggin, bsingharora,
Tim Chen, linuxppc-dev, x86
In-Reply-To: <5b16d6ce-6b62-e4ca-2d78-c25bb008e27e@oracle.com>
Hi Jordan,
Thanks for reporting this.
On 26/02/2018 18:16, Daniel Jordan wrote:
> Hi Laurent,
>
> This series doesn't build for me[*] when CONFIG_TRANSPARENT_HUGEPAGE is unset.
>
> The problem seems to be that the BUILD_BUG() version of pmd_same is called in
> pte_map_lock:
>
> On 02/16/2018 10:25 AM, Laurent Dufour wrote:
>> +static bool pte_map_lock(struct vm_fault *vmf)
>> +{
> ...snip...
>> + if (!pmd_same(pmdval, vmf->orig_pmd))
>> + goto out;
>
> Since SPF can now call pmd_same without THP, maybe the way to fix it is just
>
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index 2cfa3075d148..e130692db24a 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -375,7 +375,8 @@ static inline int pte_unused(pte_t pte)
> #endif
>
> #ifndef __HAVE_ARCH_PMD_SAME
> -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +#if defined(CONFIG_TRANSPARENT_HUGEPAGE) || \
> + defined(CONFIG_SPECULATIVE_PAGE_FAULT)
> static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b)
> {
> return pmd_val(pmd_a) == pmd_val(pmd_b);
We can't fix that this way because some architectures define their own
pmd_same() function (like ppc64), thus forcing the define here will be useless
since __HAVE_ARCH_PMD_SAME is set in that case.
The right way to fix that is to _not check_ for the PMD value in pte_spinlock()
when CONFIG_TRANSPARENT_HUGEPAGE is not set since there is no risk of
collapsing operation in our back if THP are disabled.
I'll fix that in the next version.
Laurent.
> ?
>
> Daniel
>
>
> [*] The errors are:
>
> In file included from /home/dmjordan/src/linux/include/linux/kernel.h:10:0,
> from /home/dmjordan/src/linux/include/linux/list.h:9,
> from /home/dmjordan/src/linux/include/linux/smp.h:12,
> from /home/dmjordan/src/linux/include/linux/kernel_stat.h:5,
> from /home/dmjordan/src/linux/mm/memory.c:41:
> In function ‘pmd_same.isra.104’,
> inlined from ‘pte_map_lock’ at /home/dmjordan/src/linux/mm/memory.c:2380:7:
> /home/dmjordan/src/linux/include/linux/compiler.h:324:38: error: call to
> ‘__compiletime_assert_391’ declared with attribute error: BUILD_BUG failed
> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> ^
> /home/dmjordan/src/linux/include/linux/compiler.h:304:4: note: in definition of
> macro ‘__compiletime_assert’
> prefix ## suffix(); \
> ^~~~~~
> /home/dmjordan/src/linux/include/linux/compiler.h:324:2: note: in expansion of
> macro ‘_compiletime_assert’
> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> ^~~~~~~~~~~~~~~~~~~
> /home/dmjordan/src/linux/include/linux/build_bug.h:45:37: note: in expansion of
> macro ‘compiletime_assert’
> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> ^~~~~~~~~~~~~~~~~~
> /home/dmjordan/src/linux/include/linux/build_bug.h:79:21: note: in expansion of
> macro ‘BUILD_BUG_ON_MSG’
> #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
> ^~~~~~~~~~~~~~~~
> /home/dmjordan/src/linux/include/asm-generic/pgtable.h:391:2: note: in
> expansion of macro ‘BUILD_BUG’
> BUILD_BUG();
> ^~~~~~~~~
> CC block/elevator.o
> CC crypto/crypto_wq.o
> In function ‘pmd_same.isra.104’,
> inlined from ‘pte_spinlock’ at /home/dmjordan/src/linux/mm/memory.c:2326:7,
> inlined from ‘handle_pte_fault’ at
> /home/dmjordan/src/linux/mm/memory.c:4181:7:
> /home/dmjordan/src/linux/include/linux/compiler.h:324:38: error: call to
> ‘__compiletime_assert_391’ declared with attribute error: BUILD_BUG failed
> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> ^
> /home/dmjordan/src/linux/include/linux/compiler.h:304:4: note: in definition of
> macro ‘__compiletime_assert’
> prefix ## suffix(); \
> ^~~~~~
> /home/dmjordan/src/linux/include/linux/compiler.h:324:2: note: in expansion of
> macro ‘_compiletime_assert’
> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> ^~~~~~~~~~~~~~~~~~~
> /home/dmjordan/src/linux/include/linux/build_bug.h:45:37: note: in expansion of
> macro ‘compiletime_assert’
> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> ^~~~~~~~~~~~~~~~~~
> /home/dmjordan/src/linux/include/linux/build_bug.h:79:21: note: in expansion of
> macro ‘BUILD_BUG_ON_MSG’
> #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
> ^~~~~~~~~~~~~~~~
> /home/dmjordan/src/linux/include/asm-generic/pgtable.h:391:2: note: in
> expansion of macro ‘BUILD_BUG’
> BUILD_BUG();
> ^~~~~~~~~
> ...
> make[2]: *** [/home/dmjordan/src/linux/scripts/Makefile.build:316: mm/memory.o]
> Error 1
> make[1]: *** [/home/dmjordan/src/linux/Makefile:1047: mm] Error 2
>
^ permalink raw reply
* Re: [v3, 1/2] ocxl: Add get_metadata IOCTL to share OCXL information to userspace
From: Michael Ellerman @ 2018-03-05 12:36 UTC (permalink / raw)
To: Alastair D'Silva, linuxppc-dev, linux-kernel
Cc: alastair, arnd, frederic.barrat, gregkh, andrew.donnellan,
Alastair D'Silva
In-Reply-To: <20180222041739.27899-2-alastair@au1.ibm.com>
On Thu, 2018-02-22 at 04:17:38 UTC, "Alastair D'Silva" wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> Some required information is not exposed to userspace currently (eg. the
> PASID), pass this information back, along with other information which
> is currently communicated via sysfs, which saves some parsing effort in
> userspace.
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Series applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/07c5ccd70ad702e561fcda8e4df494
cheers
^ permalink raw reply
* Re: powerpc/boot: Fix random build errors
From: Michael Ellerman @ 2018-03-05 12:36 UTC (permalink / raw)
To: Guenter Roeck, Benjamin Herrenschmidt
Cc: Paul Mackerras, linuxppc-dev, Guenter Roeck, linux-kernel
In-Reply-To: <1519419359-19163-1-git-send-email-linux@roeck-us.net>
On Fri, 2018-02-23 at 20:55:59 UTC, Guenter Roeck wrote:
> Once in a while I see build errors similar to the following
> when building images from a clean tree.
>
> Building powerpc:virtex-ml507:44x/virtex5_defconfig ... failed
> ------------
> Error log:
> arch/powerpc/boot/treeboot-akebono.c:37:20: fatal error:
> libfdt.h: No such file or directory
>
> Building powerpc:bamboo:smpdev:44x/bamboo_defconfig ... failed
> ------------
> Error log:
> arch/powerpc/boot/treeboot-akebono.c:37:20: fatal error:
> libfdt.h: No such file or directory
>
> arch/powerpc/boot/treeboot-currituck.c:35:20: fatal error:
> libfdt.h: No such file or directory
>
> Rebuilds will succeed.
>
> Turns out that several source files in arch/powerpc/boot/ include
> libfdt.h, but Makefile dependencies are incomplete. Let's fix that.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/64c3f648c25d108f346fdc96c15180
cheers
^ permalink raw reply
* Re: selftests/powerpc: Skip tm-trap if transactional memory is not enabled
From: Michael Ellerman @ 2018-03-05 12:36 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: gromero
In-Reply-To: <20180226021926.32513-1-mpe@ellerman.id.au>
On Mon, 2018-02-26 at 02:19:26 UTC, Michael Ellerman wrote:
> Some processor revisions do not support transactional memory, and
> additionally kernel support can be disabled. In either case the
> tm-trap test should be skipped, otherwise it will fail with a SIGILL.
>
> Fixes: a08082f8e4e1 ("powerpc/selftests: Check endianness on trap in TM")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/192b2e742c06af399e8eecb4a17265
cheers
^ permalink raw reply
* Re: selftests/powerpc: Fix missing clean of pmu/lib.o
From: Michael Ellerman @ 2018-03-05 12:36 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20180228093257.13049-1-mpe@ellerman.id.au>
On Wed, 2018-02-28 at 09:32:57 UTC, Michael Ellerman wrote:
> The tm-resched-dscr test links against pmu/lib.o, but we don't have a
> rule to clean pmu/lib.o. This can lead to a build break if you build
> for big endian and then little, or vice versa.
>
> Fix it by making tm-resched-dscr depend on pmu/lib.c, causing the code
> to be built directly in, meaning no .o is generated.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/b7abbd5a3533a31a1e7d4696ea275d
cheers
^ permalink raw reply
* Re: [v2] selftests/powerpc: Skip the subpage_prot tests if the syscall is unavailable
From: Michael Ellerman @ 2018-03-05 12:36 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: aneesh.kumar
In-Reply-To: <20180302020108.22174-1-mpe@ellerman.id.au>
On Fri, 2018-03-02 at 02:01:08 UTC, Michael Ellerman wrote:
> The subpage_prot syscall is only functional when the system is using
> the Hash MMU. Since commit 5b2b80714796 ("powerpc/mm: Invalidate
> subpage_prot() system call on radix platforms") it returns ENOENT when
> the Radix MMU is active. Currently this just makes the test fail.
>
> Additionally the syscall is not available if the kernel is built with
> 4K pages, or if CONFIG_PPC_SUBPAGE_PROT=n, in which case it returns
> ENOSYS because the syscall is missing entirely.
>
> So check explicitly for ENOENT and ENOSYS and skip if we see either of
> those.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/cd4a6f3ab4d80cb919d15897eb3cbc
cheers
^ permalink raw reply
* barrier_nospec for POWER
From: Michal Suchánek @ 2018-03-05 13:13 UTC (permalink / raw)
To: linuxppc-dev
Hello,
there is x86 barrier_nospec which implements the same barrier as the
earlier out-of-tree gmb() barrier but instead of sprinkling the barrier
randomly in kernel code it put it in copy_from_user. We have the
firmware support for barrier_nospec already reported from the hcall
which is used for RFI flushes. So copy-pasting this from x86 should not
be that difficult.
However, there is separate patch which protects the NR_syscalls check of
syscall entry which does not apply on powerpc because the check is done
in assembly. I did not manage to write a barrier_nospec that compiles
both in C and asm so you are spared a RFC patch.
Is there some work in progress on addressing this?
Thanks
Michal
^ permalink raw reply
* [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw)
To: will.deacon, robin.murphy, mark.rutland, catalin.marinas
Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li,
shawnguo, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor,
Nipun Gupta
In-Reply-To: <1520260166-29387-1-git-send-email-nipun.gupta@nxp.com>
The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a binding for
mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
.../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..011c7d6 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices
such as network interfaces, crypto accelerator instances, L2 switches,
etc.
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is cannot be used to describe the relationship
+between fsl-mc and IOMMUs, so an iommu-parent property is used to define
+the same.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
Required properties:
- compatible
@@ -88,14 +106,27 @@ Sub-nodes:
Value type: <phandle>
Definition: Specifies the phandle to the PHY device node associated
with the this dpmac.
+Optional properties:
+
+- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
+ The property specifies the IOMMU behind which the devices on
+ fsl-mc bus are residing.
Example:
+ smmu: iommu@5000000 {
+ compatible = "arm,mmu-500";
+ #iommu-cells = <1>;
+ stream-match-mask = <0x7C00>;
+ ...
+ };
+
fsl_mc: fsl-mc@80c000000 {
compatible = "fsl,qoriq-mc";
reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */
<0x00000000 0x08340000 0 0x40000>; /* MC control reg */
msi-parent = <&its>;
+ iommu-parent = <&smmu>;
#address-cells = <3>;
#size-cells = <1>;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/6] iommu: support iommu configuration for fsl-mc devices
From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw)
To: will.deacon, robin.murphy, mark.rutland, catalin.marinas
Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li,
shawnguo, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor,
Nipun Gupta
In-Reply-To: <1520260166-29387-1-git-send-email-nipun.gupta@nxp.com>
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
drivers/iommu/of_iommu.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..cc2fb9c 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
#include <linux/of_iommu.h>
#include <linux/of_pci.h>
#include <linux/slab.h>
+#include <linux/fsl/mc.h>
#define NO_IOMMU 1
@@ -160,6 +161,26 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
return err;
}
+static int
+of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+ struct device_node *master_np)
+{
+ struct of_phandle_args iommu_spec;
+ int err;
+
+ iommu_spec.np = of_parse_phandle(master_np, "iommu-parent", 0);
+ if (!iommu_spec.np)
+ return NO_IOMMU;
+
+ iommu_spec.args[0] = mc_dev->icid;
+ iommu_spec.args_count = 1;
+
+ err = of_iommu_xlate(&mc_dev->dev, &iommu_spec);
+ of_node_put(iommu_spec.np);
+
+ return err;
+}
+
const struct iommu_ops *of_iommu_configure(struct device *dev,
struct device_node *master_np)
{
@@ -191,6 +212,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
err = pci_for_each_dma_alias(to_pci_dev(dev),
of_pci_iommu_init, &info);
+ } else if (dev_is_fsl_mc(dev)) {
+ err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
} else {
struct of_phandle_args iommu_spec;
int idx = 0;
--
1.9.1
^ permalink raw reply related
* [PATCH 3/6] iommu: arm-smmu: Add support for the fsl-mc bus
From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw)
To: will.deacon, robin.murphy, mark.rutland, catalin.marinas
Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li,
shawnguo, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor,
Nipun Gupta
In-Reply-To: <1520260166-29387-1-git-send-email-nipun.gupta@nxp.com>
Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
drivers/iommu/arm-smmu.c | 7 +++++++
drivers/iommu/iommu.c | 21 +++++++++++++++++++++
include/linux/fsl/mc.h | 8 ++++++++
include/linux/iommu.h | 2 ++
4 files changed, 38 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
#include <linux/spinlock.h>
#include <linux/amba/bus.h>
+#include <linux/fsl/mc.h>
#include "io-pgtable.h"
#include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
if (dev_is_pci(dev))
group = pci_device_group(dev);
+ else if (dev_is_fsl_mc(dev))
+ group = fsl_mc_device_group(dev);
else
group = generic_device_group(dev);
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
}
#endif
+#ifdef CONFIG_FSL_MC_BUS
+ if (!iommu_present(&fsl_mc_bus_type))
+ bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops);
+#endif
}
static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 69fef99..fbeebb2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
#include <linux/pci.h>
#include <linux/bitops.h>
#include <linux/property.h>
+#include <linux/fsl/mc.h>
#include <trace/events/iommu.h>
static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
return iommu_group_alloc();
}
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+ struct device *cont_dev = fsl_mc_cont_dev(dev);
+ struct iommu_group *group;
+
+ /* Container device is responsible for creating the iommu group */
+ if (fsl_mc_is_cont_dev(dev)) {
+ group = iommu_group_alloc();
+ if (IS_ERR(group))
+ return NULL;
+ } else {
+ get_device(cont_dev);
+ group = iommu_group_get(cont_dev);
+ put_device(cont_dev);
+ }
+
+ return group;
+}
+
/**
* iommu_group_get_for_dev - Find or create the IOMMU group for a device
* @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index 765ba41..ae9382b 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
#define dev_is_fsl_mc(_dev) (0)
#endif
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+ FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+ (_dev) : (_dev)->parent)
+
/*
* module_fsl_mc_driver() - Helper macro for drivers that don't do
* anything special in module init/exit. This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 41b8c57..00a460b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain *domain,
extern struct iommu_group *pci_device_group(struct device *dev);
/* Generic device grouping function */
extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
/**
* struct iommu_fwspec - per-device IOMMU instance data
--
1.9.1
^ permalink raw reply related
* [PATCH 4/6] bus: fsl-mc: remove dma ops setup from driver
From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw)
To: will.deacon, robin.murphy, mark.rutland, catalin.marinas
Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li,
shawnguo, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor,
Nipun Gupta
In-Reply-To: <1520260166-29387-1-git-send-email-nipun.gupta@nxp.com>
The dma setup for fsl-mc devices is being done from device_add()
function. So, no need to call in mc bus driver.
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 1b333c4..c9a239a 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -616,6 +616,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
mc_dev->icid = parent_mc_dev->icid;
mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
mc_dev->dev.dma_mask = &mc_dev->dma_mask;
+ mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
dev_set_msi_domain(&mc_dev->dev,
dev_get_msi_domain(&parent_mc_dev->dev));
}
@@ -633,10 +634,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
goto error_cleanup_dev;
}
- /* Objects are coherent, unless 'no shareability' flag set. */
- if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
- arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
-
/*
* The device-specific probe callback will get invoked by device_add()
*/
--
1.9.1
^ permalink raw reply related
* [PATCH 5/6] dma-mapping: support fsl-mc bus
From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw)
To: will.deacon, robin.murphy, mark.rutland, catalin.marinas
Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li,
shawnguo, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor,
Nipun Gupta
In-Reply-To: <1520260166-29387-1-git-send-email-nipun.gupta@nxp.com>
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
drivers/base/dma-mapping.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 3b11835..2279c4d 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -334,6 +334,7 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags)
* Common configuration to enable DMA API use for a device
*/
#include <linux/pci.h>
+#include <linux/fsl/mc.h>
int dma_configure(struct device *dev)
{
@@ -349,6 +350,12 @@ int dma_configure(struct device *dev)
dma_dev = dma_dev->parent;
}
+ if (dev_is_fsl_mc(dev)) {
+ dma_dev = dev;
+ while (dev_is_fsl_mc(dma_dev))
+ dma_dev = dma_dev->parent;
+ }
+
if (dma_dev->of_node) {
ret = of_dma_configure(dev, dma_dev->of_node);
} else if (has_acpi_companion(dma_dev)) {
--
1.9.1
^ permalink raw reply related
* [PATCH 6/6] dts: fsl-ls208x: updated DT with SMMU support for fsl-mc
From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw)
To: will.deacon, robin.murphy, mark.rutland, catalin.marinas
Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li,
shawnguo, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor,
Nipun Gupta
In-Reply-To: <1520260166-29387-1-git-send-email-nipun.gupta@nxp.com>
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index f3a40af..1f15492 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -135,6 +135,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+ dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
clockgen: clocking@1300000 {
compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */
<0x00000000 0x08340000 0 0x40000>; /* MC control reg */
msi-parent = <&its>;
+ iommu-parent = <&smmu>;
+ dma-coherent;
#address-cells = <3>;
#size-cells = <1>;
@@ -460,6 +463,8 @@
compatible = "arm,mmu-500";
reg = <0 0x5000000 0 0x800000>;
#global-interrupts = <12>;
+ stream-match-mask = <0x7C00>;
+ dma-coherent;
interrupts = <0 13 4>, /* global secure fault */
<0 14 4>, /* combined secure interrupt */
<0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
<0 204 4>, <0 205 4>,
<0 206 4>, <0 207 4>,
<0 208 4>, <0 209 4>;
- mmu-masters = <&fsl_mc 0x300 0>;
};
dspi: dspi@2100000 {
--
1.9.1
^ permalink raw reply related
* [PATCH 0/6] Support for fsl-mc bus and its devices in SMMU
From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw)
To: will.deacon, robin.murphy, mark.rutland, catalin.marinas
Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li,
shawnguo, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor,
Nipun Gupta
This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.
These patches
- Define the new property 'iommu-parent' for fsl-mc bus (patch 1)
- Integrates the fsl-mc bus with the SMMU using this
IOMMU binding (patch 2,3)
- Adds the dma-mapping support for fsl-mc bus (patch 4,5)
- Updates the fsl-mc device node with iommu/dma related changes
This patchset is based on staging-testing tree where fsl-mc bus is out
from staging
This patchset is dependent on patch https://patchwork.kernel.org/patch/10207507/;
otherwise DPAA2 Ethernet driver functionality will break.
Nipun Gupta (6):
Docs: dt: add fsl-mc iommu-parent device-tree binding
iommu: support iommu configuration for fsl-mc devices
iommu: arm-smmu: Add support for the fsl-mc bus
bus: fsl-mc: remove dma ops setup from driver
dma-mapping: support fsl-mc bus
dts: fsl-ls208x: updated DT with SMMU support for fsl-mc
.../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 ++++-
drivers/base/dma-mapping.c | 7 +++++
drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +---
drivers/iommu/arm-smmu.c | 7 +++++
drivers/iommu/iommu.c | 21 +++++++++++++++
drivers/iommu/of_iommu.c | 23 ++++++++++++++++
include/linux/fsl/mc.h | 8 ++++++
include/linux/iommu.h | 2 ++
9 files changed, 105 insertions(+), 5 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
From: Robin Murphy @ 2018-03-05 14:53 UTC (permalink / raw)
To: Nipun Gupta, will.deacon, mark.rutland, catalin.marinas
Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li,
shawnguo, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor
In-Reply-To: <1520260166-29387-2-git-send-email-nipun.gupta@nxp.com>
On 05/03/18 14:29, Nipun Gupta wrote:
> The existing IOMMU bindings cannot be used to specify the relationship
> between fsl-mc devices and IOMMUs. This patch adds a binding for
> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
Given that allowing "msi-parent" for #msi-cells > 1 is merely a
backward-compatibility bodge full of hard-coded assumptions, why would
we want to knowingly introduce a similarly unpleasant equivalent for
IOMMUs? What's wrong with "iommu-map"?
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
> .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> index 6611a7c..011c7d6 100644
> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices
> such as network interfaces, crypto accelerator instances, L2 switches,
> etc.
>
> +For an overview of the DPAA2 architecture and fsl-mc bus see:
> +drivers/staging/fsl-mc/README.txt
> +
> +As described in the above overview, all DPAA2 objects in a DPRC share the
> +same hardware "isolation context" and a 10-bit value called an ICID
> +(isolation context id) is expressed by the hardware to identify
> +the requester.
IOW, precisely the case for which "{msi,iommu}-map" exist. Yes, I know
they're currently documented under bindings/pci, but they're not really
intended to be absolutely PCI-specific.
Robin.
> +The generic 'iommus' property is cannot be used to describe the relationship
> +between fsl-mc and IOMMUs, so an iommu-parent property is used to define
> +the same.
> +
> +For generic IOMMU bindings, see
> +Documentation/devicetree/bindings/iommu/iommu.txt.
> +
> +For arm-smmu binding, see:
> +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> +
> Required properties:
>
> - compatible
> @@ -88,14 +106,27 @@ Sub-nodes:
> Value type: <phandle>
> Definition: Specifies the phandle to the PHY device node associated
> with the this dpmac.
> +Optional properties:
> +
> +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> + The property specifies the IOMMU behind which the devices on
> + fsl-mc bus are residing.
>
> Example:
>
> + smmu: iommu@5000000 {
> + compatible = "arm,mmu-500";
> + #iommu-cells = <1>;
> + stream-match-mask = <0x7C00>;
> + ...
> + };
> +
> fsl_mc: fsl-mc@80c000000 {
> compatible = "fsl,qoriq-mc";
> reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */
> <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
> msi-parent = <&its>;
> + iommu-parent = <&smmu>;
> #address-cells = <3>;
> #size-cells = <1>;
>
>
^ 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