Re: [RFC PATCH 14/23] watchdog/hardlockup: Decouple the hardlockup detector from perf
On Thu, Jun 14, 2018 at 11:41:44AM +1000, Nicholas Piggin wrote: > On Wed, 13 Jun 2018 18:19:01 -0700 > Ricardo Neri wrote: > > > On Wed, Jun 13, 2018 at 10:43:24AM +0200, Peter Zijlstra wrote: > > > On Tue, Jun 12, 2018 at 05:57:34PM -0700, Ricardo Neri wrote: > > > > The current default implementation of the hardlockup detector assumes > > > > that > > > > it is implemented using perf events. > > > > > > The sparc and powerpc things are very much not using perf. > > > > Isn't it true that the current hardlockup detector > > (under kernel/watchdog_hld.c) is based on perf? > > arch/powerpc/kernel/watchdog.c is a powerpc implementation that uses > the kernel/watchdog_hld.c framework. > > > As far as I understand, > > this hardlockup detector is constructed using perf events for architectures > > that don't provide an NMI watchdog. Perhaps I can be more specific and say > > that this synthetized detector is based on perf. > > The perf detector is like that, but we want NMI watchdogs to share > the watchdog_hld code as much as possible even for arch specific NMI > watchdogs, so that kernel and user interfaces and behaviour are > consistent. > > Other arch watchdogs like sparc are a little older so they are not > using HLD. You don't have to change those for your series, but it > would be good to bring them into the fold if possible at some time. > IIRC sparc was slightly non-trivial because it has some differences > in sysctl or cmdline APIs that we don't want to break. > > But powerpc at least needs to be updated if you change hld apis. I will look into updating at least the powerpc implementation as part of these changes. Thanks and BR, Ricardo ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 12/23] kernel/watchdog: Introduce a struct for NMI watchdog operations
On Thu, Jun 14, 2018 at 12:32:50PM +1000, Nicholas Piggin wrote: > On Wed, 13 Jun 2018 18:31:17 -0700 > Ricardo Neri wrote: > > > On Wed, Jun 13, 2018 at 09:52:25PM +1000, Nicholas Piggin wrote: > > > On Wed, 13 Jun 2018 11:26:49 +0200 (CEST) > > > Thomas Gleixner wrote: > > > > > > > On Wed, 13 Jun 2018, Peter Zijlstra wrote: > > > > > On Wed, Jun 13, 2018 at 05:41:41PM +1000, Nicholas Piggin wrote: > > > > > > On Tue, 12 Jun 2018 17:57:32 -0700 > > > > > > Ricardo Neri wrote: > > > > > > > > > > > > > Instead of exposing individual functions for the operations of > > > > > > > the NMI > > > > > > > watchdog, define a common interface that can be used across > > > > > > > multiple > > > > > > > implementations. > > > > > > > > > > > > > > The struct nmi_watchdog_ops is defined for such operations. These > > > > > > > initial > > > > > > > definitions include the enable, disable, start, stop, and cleanup > > > > > > > operations. > > > > > > > > > > > > > > Only a single NMI watchdog can be used in the system. The > > > > > > > operations of > > > > > > > this NMI watchdog are accessed via the new variable nmi_wd_ops. > > > > > > > This > > > > > > > variable is set to point the operations of the first NMI watchdog > > > > > > > that > > > > > > > initializes successfully. Even though at this moment, the only > > > > > > > available > > > > > > > NMI watchdog is the perf-based hardlockup detector. More > > > > > > > implementations > > > > > > > can be added in the future. > > > > > > > > > > > > Cool, this looks pretty nice at a quick glance. sparc and powerpc at > > > > > > least have their own NMI watchdogs, it would be good to have those > > > > > > converted as well. > > > > > > > > > > Yeah, agreed, this looks like half a patch. > > > > > > > > Though I'm not seeing the advantage of it. That kind of NMI watchdogs > > > > are > > > > low level architecture details so having yet another 'ops' data > > > > structure > > > > with a gazillion of callbacks, checks and indirections does not provide > > > > value over the currently available weak stubs. > > > > > > The other way to go of course is librify the perf watchdog and make an > > > x86 watchdog that selects between perf and hpet... I also probably > > > prefer that for code such as this, but I wouldn't strongly object to > > > ops struct if I'm not writing the code. It's not that bad is it? > > > > My motivation to add the ops was that the hpet and perf watchdog share > > significant portions of code. > > Right, a good motivation. > > > I could look into creating the library for > > common code and relocate the hpet watchdog into arch/x86 for the hpet- > > specific parts. > > If you can investigate that approach, that would be appreciated. I hope > I did not misunderstand you there, Thomas. > > Basically you would have perf infrastructure and hpet infrastructure, > and then the x86 watchdog driver will use one or the other of those. The > generic watchdog driver will be just a simple shim that uses the perf > infrastructure. Then hopefully the powerpc driver would require almost > no change. Sure, I will try to structure code to minimize the changes to the powerpc watchdog... without breaking the sparc one. Thanks and BR, Ricardo ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 20/23] watchdog/hardlockup/hpet: Rotate interrupt among all monitored CPUs
On Wed, Jun 13, 2018 at 11:48:09AM +0200, Thomas Gleixner wrote:
> On Tue, 12 Jun 2018, Ricardo Neri wrote:
> > + /* There are no CPUs to monitor. */
> > + if (!cpumask_weight(>monitored_mask))
> > + return NMI_HANDLED;
> > +
> > inspect_for_hardlockups(regs);
> >
> > + /*
> > +* Target a new CPU. Keep trying until we find a monitored CPU. CPUs
> > +* are addded and removed to this mask at cpu_up() and cpu_down(),
> > +* respectively. Thus, the interrupt should be able to be moved to
> > +* the next monitored CPU.
> > +*/
> > + spin_lock(_data->lock);
>
> Yuck. Taking a spinlock from NMI ...
I am sorry. I will look into other options for locking. Do you think rcu_lock
would help in this case? I need this locking because the CPUs being monitored
changes as CPUs come online and offline.
>
> > + for_each_cpu_wrap(cpu, >monitored_mask, smp_processor_id() + 1) {
> > + if (!irq_set_affinity(hld_data->irq, cpumask_of(cpu)))
> > + break;
>
> ... and then calling into generic interrupt code which will take even more
> locks is completely broken.
I will into reworking how the destination of the interrupt is set.
Thanks and BR,
Ricardo
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI
On Wed, Jun 13, 2018 at 11:06:25AM +0100, Marc Zyngier wrote:
> On 13/06/18 10:20, Thomas Gleixner wrote:
> > On Wed, 13 Jun 2018, Julien Thierry wrote:
> >> On 13/06/18 09:34, Peter Zijlstra wrote:
> >>> On Tue, Jun 12, 2018 at 05:57:23PM -0700, Ricardo Neri wrote:
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 5426627..dbc5e02 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -61,6 +61,8 @@
> *interrupt handler after suspending interrupts. For
> system
> *wakeup devices users need to implement wakeup
> detection in
> *their interrupt handlers.
> + * IRQF_DELIVER_AS_NMI - Configure interrupt to be delivered as
> non-maskable, if
> + *supported by the chip.
> */
> >>>
> >>> NAK on the first 6 patches. You really _REALLY_ don't want to expose
> >>> NMIs to this level.
> >>>
> >>
> >> I've been working on something similar on arm64 side, and effectively the
> >> one
> >> thing that might be common to arm64 and intel is the interface to set an
> >> interrupt as NMI. So I guess it would be nice to agree on the right
> >> approach
> >> for this.
> >>
> >> The way I did it was by introducing a new irq_state and let the irqchip
> >> driver
> >> handle most of the work (if it supports that state):
> >>
> >> https://lkml.org/lkml/2018/5/25/181
> >>
> >> This has not been ACKed nor NAKed. So I am just asking whether this is a
> >> more
> >> suitable approach, and if not, is there any suggestions on how to do this?
> >
> > I really didn't pay attention to that as it's burried in the GIC/ARM series
> > which is usually Marc's playground.
>
> I'm working my way through it ATM now that I have some brain cycles back.
>
> > Adding NMI delivery support at low level architecture irq chip level is
> > perfectly fine, but the exposure of that needs to be restricted very
> > much. Adding it to the generic interrupt control interfaces is not going to
> > happen. That's doomed to begin with and a complete abuse of the interface
> > as the handler can not ever be used for that.
>
> I can only agree with that. Allowing random driver to use request_irq()
> to make anything an NMI ultimately turns it into a complete mess ("hey,
> NMI is *faster*, let's use that"), and a potential source of horrible
> deadlocks.
>
> What I'd find more palatable is a way for an irqchip to be able to
> prioritize some interrupts based on a set of architecturally-defined
> requirements, and a separate NMI requesting/handling framework that is
> separate from the IRQ API, as the overall requirements are likely to
> completely different.
>
> It shouldn't have to be nearly as complex as the IRQ API, and require
> much stricter requirements in terms of what you can do there (flow
> handling should definitely be different).
Marc, Julien, do you plan to actively work on this? Would you mind keeping
me in the loop? I also need this work for this watchdog. In the meantime,
I will go through Julien's patches and try to adapt it to my work.
Thanks and BR,
Ricardo
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 17/23] watchdog/hardlockup/hpet: Convert the timer's interrupt to NMI
On Wed, Jun 13, 2018 at 11:07:20AM +0200, Peter Zijlstra wrote:
> On Tue, Jun 12, 2018 at 05:57:37PM -0700, Ricardo Neri wrote:
>
> +static bool is_hpet_wdt_interrupt(struct hpet_hld_data *hdata)
> +{
> + unsigned long this_isr;
> + unsigned int lvl_trig;
> +
> + this_isr = hpet_readl(HPET_STATUS) & BIT(hdata->num);
> +
> + lvl_trig = hpet_readl(HPET_Tn_CFG(hdata->num)) & HPET_TN_LEVEL;
> +
> + if (lvl_trig && this_isr)
> + return true;
> +
> + return false;
> +}
>
> > +static int hardlockup_detector_nmi_handler(unsigned int val,
> > + struct pt_regs *regs)
> > +{
> > + struct hpet_hld_data *hdata = hld_data;
> > + unsigned int use_fsb;
> > +
> > + /*
> > +* If FSB delivery mode is used, the timer interrupt is programmed as
> > +* edge-triggered and there is no need to check the ISR register.
> > +*/
> > + use_fsb = hdata->flags & HPET_DEV_FSB_CAP;
>
> Please do explain.. That FSB thing basically means MSI. But there's only
> a single NMI vector. How do we know this NMI came from the HPET?
Indeed, I see now that this is wrong. There is no way to know. The only way
is to use an IO APIC interrupt and read the HPET status register.
>
> > +
> > + if (!use_fsb && !is_hpet_wdt_interrupt(hdata))
>
> So you add _2_ HPET reads for every single NMI that gets triggered...
> and IIRC HPET reads are _slloww_.
Since the trigger mode of the HPET timer is not expected to change,
perhaps is_hpet_wdt_interrupt() can only need the interrupt status
register. This would reduce the reads to one. Furthermore, the hardlockup
detector can skip an X number of NMIs and reduce further the frequency
of reads. Does this make sense?
>
> > + return NMI_DONE;
> > +
> > + inspect_for_hardlockups(regs);
> > +
> > + if (!(hdata->flags & HPET_DEV_PERI_CAP))
> > + kick_timer(hdata);
> > +
> > + /* Acknowledge interrupt if in level-triggered mode */
> > + if (!use_fsb)
> > + hpet_writel(BIT(hdata->num), HPET_STATUS);
> > +
> > + return NMI_HANDLED;
>
> So if I read this right, when in FSB/MSI mode, we'll basically _always_
> claim every single NMI as handled?
>
> That's broken.
Yes, this is not correct. I will drop the functionality to use
FSB/MSI mode.
Thanks and BR,
Ricardo
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 17/23] watchdog/hardlockup/hpet: Convert the timer's interrupt to NMI
On Wed, Jun 13, 2018 at 11:40:00AM +0200, Thomas Gleixner wrote:
> On Tue, 12 Jun 2018, Ricardo Neri wrote:
> > @@ -183,6 +184,8 @@ static irqreturn_t hardlockup_detector_irq_handler(int
> > irq, void *data)
> > if (!(hdata->flags & HPET_DEV_PERI_CAP))
> > kick_timer(hdata);
> >
> > + pr_err("This interrupt should not have happened. Ensure delivery mode
> > is NMI.\n");
>
> Eeew.
If you don't mind me asking. What is the problem with this error message?
>
> > /**
> > + * hardlockup_detector_nmi_handler() - NMI Interrupt handler
> > + * @val: Attribute associated with the NMI. Not used.
> > + * @regs: Register values as seen when the NMI was asserted
> > + *
> > + * When an NMI is issued, look for hardlockups. If the timer is not
> > periodic,
> > + * kick it. The interrupt is always handled when if delivered via the
> > + * Front-Side Bus.
> > + *
> > + * Returns:
> > + *
> > + * NMI_DONE if the HPET timer did not cause the interrupt. NMI_HANDLED
> > + * otherwise.
> > + */
> > +static int hardlockup_detector_nmi_handler(unsigned int val,
> > + struct pt_regs *regs)
> > +{
> > + struct hpet_hld_data *hdata = hld_data;
> > + unsigned int use_fsb;
> > +
> > + /*
> > +* If FSB delivery mode is used, the timer interrupt is programmed as
> > +* edge-triggered and there is no need to check the ISR register.
> > +*/
> > + use_fsb = hdata->flags & HPET_DEV_FSB_CAP;
> > +
> > + if (!use_fsb && !is_hpet_wdt_interrupt(hdata))
> > + return NMI_DONE;
>
> So for 'use_fsb == True' every single NMI will fall through into the
> watchdog code below.
>
> > + inspect_for_hardlockups(regs);
> > +
> > + if (!(hdata->flags & HPET_DEV_PERI_CAP))
> > + kick_timer(hdata);
>
> And in case that the HPET does not support periodic mode this reprogramms
> the timer on every NMI which means that while perf is running the watchdog
> will never ever detect anything.
Yes. I see that this is wrong. With MSI interrupts, as far as I can
see, there is not a way to make sure that the HPET timer caused the NMI
perhaps the only option is to use an IO APIC interrupt and read the
interrupt status register.
>
> Aside of that, reading TWO HPET registers for every NMI is insane. HPET
> access is horribly slow, so any high frequency perf monitoring will take a
> massive performance hit.
If an IO APIC interrupt is used, only HPET register (the status register)
would need to be read for every NMI. Would that be more acceptable? Otherwise,
there is no way to determine if the HPET cause the NMI.
Alternatively, there could be a counter that skips reading the HPET status
register (and the detection of hardlockups) for every X NMIs. This would
reduce the overall frequency of HPET register reads.
Is that more acceptable?
Thanks and BR,
Ricardo
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v9 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU
On 06/12/2018 02:41 PM, Gary R Hook wrote: > Implement a skeleton framework for debugfs support in the AMD > IOMMU. Add an AMD-specific Kconfig boolean that depends upon > general enablement of DebugFS in the IOMMU. > > Signed-off-by: Gary R Hook Gary, Looks good to me. Thanks. > --- > drivers/iommu/Kconfig | 12 > drivers/iommu/Makefile|1 + > drivers/iommu/amd_iommu_debugfs.c | 33 + > drivers/iommu/amd_iommu_init.c|6 -- > drivers/iommu/amd_iommu_proto.h |6 ++ > drivers/iommu/amd_iommu_types.h |5 + > 6 files changed, 61 insertions(+), 2 deletions(-) > create mode 100644 drivers/iommu/amd_iommu_debugfs.c > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > index f9af25ac409f..5a9cef113763 100644 > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -146,6 +146,18 @@ config AMD_IOMMU_V2 > hardware. Select this option if you want to use devices that support > the PCI PRI and PASID interface. > > +config AMD_IOMMU_DEBUGFS > + bool "Enable AMD IOMMU internals in DebugFS" > + depends on AMD_IOMMU && IOMMU_DEBUGFS > + ---help--- > + !!!WARNING!!! !!!WARNING!!! !!!WARNING!!! !!!WARNING!!! > + > + DO NOT ENABLE THIS OPTION UNLESS YOU REALLY, -REALLY- KNOW WHAT YOU > ARE DOING!!! > + Exposes AMD IOMMU device internals in DebugFS. > + > + This option is -NOT- intended for production environments, and should > + not generally be enabled. > + > # Intel IOMMU support > config DMAR_TABLE > bool > diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile > index 74cfbc392862..47fd6ea9de2d 100644 > --- a/drivers/iommu/Makefile > +++ b/drivers/iommu/Makefile > @@ -11,6 +11,7 @@ obj-$(CONFIG_IOMMU_IOVA) += iova.o > obj-$(CONFIG_OF_IOMMU) += of_iommu.o > obj-$(CONFIG_MSM_IOMMU) += msm_iommu.o > obj-$(CONFIG_AMD_IOMMU) += amd_iommu.o amd_iommu_init.o > +obj-$(CONFIG_AMD_IOMMU_DEBUGFS) += amd_iommu_debugfs.o > obj-$(CONFIG_AMD_IOMMU_V2) += amd_iommu_v2.o > obj-$(CONFIG_ARM_SMMU) += arm-smmu.o > obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o -- ~Randy ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] mm: convert return type of handle_mm_fault() caller to vm_fault_t
Hi Souptick,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.17]
[cannot apply to linus/master powerpc/next sparc-next/master next-20180614]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Souptick-Joarder/mm-convert-return-type-of-handle_mm_fault-caller-to-vm_fault_t/20180615-030636
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
>> arch/powerpc/mm/copro_fault.c:36:5: error: conflicting types for
>> 'copro_handle_mm_fault'
int copro_handle_mm_fault(struct mm_struct *mm, unsigned long ea,
^
In file included from arch/powerpc/mm/copro_fault.c:27:0:
arch/powerpc/include/asm/copro.h:18:5: note: previous declaration of
'copro_handle_mm_fault' was here
int copro_handle_mm_fault(struct mm_struct *mm, unsigned long ea,
^
In file included from include/linux/linkage.h:7:0,
from include/linux/kernel.h:7,
from include/asm-generic/bug.h:18,
from arch/powerpc/include/asm/bug.h:128,
from include/linux/bug.h:5,
from arch/powerpc/include/asm/mmu.h:126,
from arch/powerpc/include/asm/lppaca.h:36,
from arch/powerpc/include/asm/paca.h:21,
from arch/powerpc/include/asm/current.h:16,
from include/linux/sched.h:12,
from arch/powerpc/mm/copro_fault.c:23:
arch/powerpc/mm/copro_fault.c:101:19: error: conflicting types for
'copro_handle_mm_fault'
EXPORT_SYMBOL_GPL(copro_handle_mm_fault);
^
include/linux/export.h:65:21: note: in definition of macro '___EXPORT_SYMBOL'
extern typeof(sym) sym; \
^~~
arch/powerpc/mm/copro_fault.c:101:1: note: in expansion of macro
'EXPORT_SYMBOL_GPL'
EXPORT_SYMBOL_GPL(copro_handle_mm_fault);
^
In file included from arch/powerpc/mm/copro_fault.c:27:0:
arch/powerpc/include/asm/copro.h:18:5: note: previous declaration of
'copro_handle_mm_fault' was here
int copro_handle_mm_fault(struct mm_struct *mm, unsigned long ea,
^
vim +/copro_handle_mm_fault +36 arch/powerpc/mm/copro_fault.c
7cd58e438 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2007-12-20
30
7cd58e438 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2007-12-20
31 /*
7cd58e438 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2007-12-20
32 * This ought to be kept in sync with the powerpc specific do_page_fault
7cd58e438 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2007-12-20
33 * function. Currently, there are a few corner cases that we haven't had
7cd58e438 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2007-12-20
34 * to handle fortunately.
7cd58e438 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2007-12-20
35 */
e83d01697 arch/powerpc/mm/copro_fault.c Ian Munsie 2014-10-08
@36 int copro_handle_mm_fault(struct mm_struct *mm, unsigned long ea,
7c71e54a4 arch/powerpc/mm/copro_fault.c Souptick Joarder 2018-06-15
37unsigned long dsisr, vm_fault_t *flt)
7cd58e438 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2007-12-20
38 {
7cd58e438 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2007-12-20
39struct vm_area_struct *vma;
7cd58e438 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2007-12-20
40unsigned long is_write;
7cd58e438 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2007-12-20
41int ret;
7cd58e438 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2007-12-20
42
60ee03194 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2009-02-17
43if (mm == NULL)
7cd58e438 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2007-12-20
44return -EFAULT;
60ee03194 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2009-02-17
45
60ee03194 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2009-02-17
46if (mm->pgd == NULL)
7cd58e438 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2007-12-20
47return -EFAULT;
7cd58e438 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2007-12-20
48
7cd58e438 arch/powerpc/platforms/cell/spu_fault.c Jeremy Kerr2007-12-20
49down_read(>mmap_sem);
60ee03194 arch/powerpc/platforms
[PATCH] mm: convert return type of handle_mm_fault() caller to vm_fault_t
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
In this patch all the caller of handle_mm_fault()
are changed to return vm_fault_t type.
Signed-off-by: Souptick Joarder
---
arch/alpha/mm/fault.c | 3 ++-
arch/arc/mm/fault.c | 4 +++-
arch/arm/mm/fault.c | 7 ---
arch/arm64/mm/fault.c | 6 +++---
arch/hexagon/mm/vm_fault.c| 2 +-
arch/ia64/mm/fault.c | 2 +-
arch/m68k/mm/fault.c | 4 ++--
arch/microblaze/mm/fault.c| 2 +-
arch/mips/mm/fault.c | 2 +-
arch/nds32/mm/fault.c | 2 +-
arch/nios2/mm/fault.c | 2 +-
arch/openrisc/mm/fault.c | 2 +-
arch/parisc/mm/fault.c| 2 +-
arch/powerpc/mm/copro_fault.c | 2 +-
arch/powerpc/mm/fault.c | 7 ---
arch/riscv/mm/fault.c | 3 ++-
arch/s390/mm/fault.c | 13 -
arch/sh/mm/fault.c| 4 ++--
arch/sparc/mm/fault_32.c | 3 ++-
arch/sparc/mm/fault_64.c | 3 ++-
arch/um/kernel/trap.c | 2 +-
arch/unicore32/mm/fault.c | 9 +
arch/x86/mm/fault.c | 5 +++--
arch/xtensa/mm/fault.c| 2 +-
drivers/iommu/amd_iommu_v2.c | 2 +-
drivers/iommu/intel-svm.c | 4 +++-
mm/hmm.c | 8
mm/ksm.c | 2 +-
28 files changed, 62 insertions(+), 47 deletions(-)
diff --git a/arch/alpha/mm/fault.c b/arch/alpha/mm/fault.c
index cd3c572..2a979ee 100644
--- a/arch/alpha/mm/fault.c
+++ b/arch/alpha/mm/fault.c
@@ -87,7 +87,8 @@
struct vm_area_struct * vma;
struct mm_struct *mm = current->mm;
const struct exception_table_entry *fixup;
- int fault, si_code = SEGV_MAPERR;
+ int si_code = SEGV_MAPERR;
+ vm_fault_t fault;
siginfo_t info;
unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index a0b7bd6..3a18d33 100644
--- a/arch/arc/mm/fault.c
+++ b/arch/arc/mm/fault.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -66,7 +67,8 @@ void do_page_fault(unsigned long address, struct pt_regs
*regs)
struct task_struct *tsk = current;
struct mm_struct *mm = tsk->mm;
siginfo_t info;
- int fault, ret;
+ int ret;
+ vm_fault_t fault;
int write = regs->ecr_cause & ECR_C_PROTV_STORE; /* ST/EX */
unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index b75eada..758abcb 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -219,12 +219,12 @@ static inline bool access_error(unsigned int fsr, struct
vm_area_struct *vma)
return vma->vm_flags & mask ? false : true;
}
-static int __kprobes
+static vm_fault_t __kprobes
__do_page_fault(struct mm_struct *mm, unsigned long addr, unsigned int fsr,
unsigned int flags, struct task_struct *tsk)
{
struct vm_area_struct *vma;
- int fault;
+ vm_fault_t fault;
vma = find_vma(mm, addr);
fault = VM_FAULT_BADMAP;
@@ -259,7 +259,8 @@ static inline bool access_error(unsigned int fsr, struct
vm_area_struct *vma)
{
struct task_struct *tsk;
struct mm_struct *mm;
- int fault, sig, code;
+ int sig, code;
+ vm_fault_t fault;
unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
if (notify_page_fault(regs, fsr))
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 2af3dd8..8da263b 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -371,12 +371,12 @@ static void do_bad_area(unsigned long addr, unsigned int
esr, struct pt_regs *re
#define VM_FAULT_BADMAP0x01
#define VM_FAULT_BADACCESS 0x02
-static int __do_page_fault(struct mm_struct *mm, unsigned long addr,
+static vm_fault_t __do_page_fault(struct mm_struct *mm, unsigned long addr,
unsigned int mm_flags, unsigned long vm_flags,
struct task_struct *tsk)
{
struct vm_area_struct *vma;
- int fault;
+ vm_fault_t fault;
vma = find_vma(mm, addr);
fault = VM_FAULT_BADMAP;
@@ -419,7 +419,7 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
struct task_struct *tsk;
struct mm_struct *mm;
struct siginfo si;
- int fault, major = 0;
+ vm_fault_t fault, major = 0;
unsigned long vm_flags = VM_READ | VM_WRITE;
unsigned int mm_flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
diff --git a/arch/hexagon/mm/vm_fault.c b/arch/hexagon/mm/vm_fault.c
index 3eec33c..5d1de6c 100644
---
Re: [PATCH 2/2] dma-mapping: move all DMA mapping code to kernel/dma
On Thu, Jun 14, 2018 at 03:13:46PM +0300, Andy Shevchenko wrote: > For my point of view, makes sense! > > > +config HAS_DMA > > + bool > > + depends on !NO_DMA > > + default y > > I see it's just move from other file, though we might switch to > def_bool y > instead of two lines. Makes sense, but I'd rather send it together with a bunch of other cleanups in that area for the 4.19 merge window. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RESEND 6/6] iommu/ipmmu-vmsa: Document R-Car V3H and E3 IPMMU DT bindings
From: Magnus Damm Update the IPMMU DT binding documentation to include the compat strings for the IPMMU devices included in the R-Car V3H and E3 SoCs. Signed-off-by: Magnus Damm Reviewed-by: Simon Horman Acked-by: Rob Herring Reviewed-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt index 8d145a4..c6e2d85 100644 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt @@ -21,6 +21,8 @@ Required Properties: - "renesas,ipmmu-r8a7796" for the R8A7796 (R-Car M3-W) IPMMU. - "renesas,ipmmu-r8a77965" for the R8A77965 (R-Car M3-N) IPMMU. - "renesas,ipmmu-r8a77970" for the R8A77970 (R-Car V3M) IPMMU. +- "renesas,ipmmu-r8a77980" for the R8A77980 (R-Car V3H) IPMMU. +- "renesas,ipmmu-r8a77990" for the R8A77990 (R-Car E3) IPMMU. - "renesas,ipmmu-r8a77995" for the R8A77995 (R-Car D3) IPMMU. - "renesas,ipmmu-vmsa" for generic R-Car Gen2 or RZ/G1 VMSA-compatible IPMMU. -- 2.7.4 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 2/2] dma-mapping: move all DMA mapping code to kernel/dma
Currently the code is split over various files with dma- prefixes in the
lib/ and drives/base directories, and the number of files keeps growing.
Move them into a single directory to keep the code together and remove
the file name prefixes. To match the irq infrastructure this directory
is placed under the kernel/ directory.
Signed-off-by: Christoph Hellwig
---
Documentation/driver-api/infrastructure.rst | 4 +-
MAINTAINERS | 9 +---
drivers/base/Makefile | 3 --
include/linux/dma-contiguous.h| 2 +-
init/Kconfig | 4 --
kernel/Makefile | 1 +
kernel/dma/Kconfig| 50 +++
kernel/dma/Makefile | 11
.../dma-coherent.c => kernel/dma/coherent.c | 0
.../dma/contiguous.c | 0
lib/dma-debug.c => kernel/dma/debug.c | 0
lib/dma-direct.c => kernel/dma/direct.c | 0
.../dma-mapping.c => kernel/dma/mapping.c | 2 +-
.../dma/noncoherent.c | 0
{lib => kernel/dma}/swiotlb.c | 0
lib/dma-virt.c => kernel/dma/virt.c | 2 -
lib/Kconfig | 47 +
lib/Makefile | 6 ---
18 files changed, 69 insertions(+), 72 deletions(-)
create mode 100644 kernel/dma/Kconfig
create mode 100644 kernel/dma/Makefile
rename drivers/base/dma-coherent.c => kernel/dma/coherent.c (100%)
rename drivers/base/dma-contiguous.c => kernel/dma/contiguous.c (100%)
rename lib/dma-debug.c => kernel/dma/debug.c (100%)
rename lib/dma-direct.c => kernel/dma/direct.c (100%)
rename drivers/base/dma-mapping.c => kernel/dma/mapping.c (99%)
rename lib/dma-noncoherent.c => kernel/dma/noncoherent.c (100%)
rename {lib => kernel/dma}/swiotlb.c (100%)
rename lib/dma-virt.c => kernel/dma/virt.c (98%)
diff --git a/Documentation/driver-api/infrastructure.rst
b/Documentation/driver-api/infrastructure.rst
index bee1b9a1702f..6172f3cc3d0b 100644
--- a/Documentation/driver-api/infrastructure.rst
+++ b/Documentation/driver-api/infrastructure.rst
@@ -49,10 +49,10 @@ Device Drivers Base
Device Drivers DMA Management
-
-.. kernel-doc:: drivers/base/dma-coherent.c
+.. kernel-doc:: kernel/dma/coherent.c
:export:
-.. kernel-doc:: drivers/base/dma-mapping.c
+.. kernel-doc:: kernel/dma/mapping.c
:export:
Device drivers PnP support
diff --git a/MAINTAINERS b/MAINTAINERS
index c13b9fb3be0b..a6844a9e2f64 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4359,12 +4359,7 @@ L: iommu@lists.linux-foundation.org
T: git git://git.infradead.org/users/hch/dma-mapping.git
W: http://git.infradead.org/users/hch/dma-mapping.git
S: Supported
-F: lib/dma-debug.c
-F: lib/dma-direct.c
-F: lib/dma-noncoherent.c
-F: lib/dma-virt.c
-F: drivers/base/dma-mapping.c
-F: drivers/base/dma-coherent.c
+F: kernel/dma/
F: include/asm-generic/dma-mapping.h
F: include/linux/dma-direct.h
F: include/linux/dma-mapping.h
@@ -13642,7 +13637,7 @@ M: Konrad Rzeszutek Wilk
L: iommu@lists.linux-foundation.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git
S: Supported
-F: lib/swiotlb.c
+F: kernel/dma/swiotlb.c
F: arch/*/kernel/pci-swiotlb.c
F: include/linux/swiotlb.h
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index b074f242a435..704f44295810 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -8,10 +8,7 @@ obj-y := component.o core.o bus.o dd.o
syscore.o \
topology.o container.o property.o cacheinfo.o \
devcon.o
obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
-obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
obj-y += power/
-obj-$(CONFIG_HAS_DMA) += dma-mapping.o
-obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
obj-$(CONFIG_ISA_BUS_API) += isa.o
obj-y += firmware_loader/
obj-$(CONFIG_NUMA) += node.o
diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index b67bf6ac907d..3c5a4cb3eb95 100644
--- a/include/linux/dma-contiguous.h
+++ b/include/linux/dma-contiguous.h
@@ -48,7 +48,7 @@
* CMA should not be used by the device drivers directly. It is
* only a helper framework for dma-mapping subsystem.
*
- * For more information, see kernel-docs in drivers/base/dma-contiguous.c
+ * For more information, see kernel-docs in kernel/dma/contiguous.c
*/
#ifdef __KERNEL__
diff --git a/init/Kconfig b/init/Kconfig
index 5a52f07259a2..fde3d09e8b27 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1719,10 +1719,6 @@ source "arch/Kconfig"
endmenu# General setup
-config HAVE_GENERIC_DMA_COHERENT
- bool
- default n
-
config RT_MUTEXES
[RFC] move dma mapping code to kernel/dma
Hi all, I'm tempted to send this little file move series to Linus around -rc1 where it would cause the least harm. Opinions? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 1/2] dma-mapping: use obj-y instead of lib-y for generic dma ops
We already have exact config symbols to select the direct, non-coherent, or virt dma ops. So use the normal obj- scheme to select them. Signed-off-by: Christoph Hellwig --- lib/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/Makefile b/lib/Makefile index 956b320292fe..5e0e160c9242 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -29,9 +29,9 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \ lib-$(CONFIG_PRINTK) += dump_stack.o lib-$(CONFIG_MMU) += ioremap.o lib-$(CONFIG_SMP) += cpumask.o -lib-$(CONFIG_DMA_DIRECT_OPS) += dma-direct.o -lib-$(CONFIG_DMA_NONCOHERENT_OPS) += dma-noncoherent.o -lib-$(CONFIG_DMA_VIRT_OPS) += dma-virt.o +obj-$(CONFIG_DMA_DIRECT_OPS) += dma-direct.o +obj-$(CONFIG_DMA_NONCOHERENT_OPS) += dma-noncoherent.o +obj-$(CONFIG_DMA_VIRT_OPS) += dma-virt.o lib-y += kobject.o klist.o obj-y += lockref.o -- 2.17.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RESEND 4/6] dt-bindings: iommu/ipmmu-vmsa: Add R-Car M3-N (R8A77965)
Add Renesas R-Car M3-N (R8A77965) compat string to IPMMU DT bindings documentation. Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt index ffadb7c..8d145a4 100644 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt @@ -19,6 +19,7 @@ Required Properties: - "renesas,ipmmu-r8a7794" for the R8A7794 (R-Car E2) IPMMU. - "renesas,ipmmu-r8a7795" for the R8A7795 (R-Car H3) IPMMU. - "renesas,ipmmu-r8a7796" for the R8A7796 (R-Car M3-W) IPMMU. +- "renesas,ipmmu-r8a77965" for the R8A77965 (R-Car M3-N) IPMMU. - "renesas,ipmmu-r8a77970" for the R8A77970 (R-Car V3M) IPMMU. - "renesas,ipmmu-r8a77995" for the R8A77995 (R-Car D3) IPMMU. - "renesas,ipmmu-vmsa" for generic R-Car Gen2 or RZ/G1 VMSA-compatible -- 2.7.4 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RESEND 3/6] iommu/ipmmu-vmsa: Hook up r8a779(70|95) DT matching code
From: Simon Horman
Support the r8a77970 (R-Car V3M) and r8a77995 (R-Car D3) IPMMUs by sharing
feature flags with r8a7795 (R-Car H3) and r8a7796 (R-Car M3-W). Also update
IOMMU_OF_DECLARE to hook up the compat strings.
Based on work for the r8a7796 by Magnus Damm
[rebased on v4.17]
Signed-off-by: Jacopo Mondi
Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
---
drivers/iommu/ipmmu-vmsa.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 04c8015..933a3da 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -763,6 +763,8 @@ static bool ipmmu_slave_whitelist(struct device *dev)
static const struct soc_device_attribute soc_rcar_gen3[] = {
{ .soc_id = "r8a7795", },
{ .soc_id = "r8a7796", },
+ { .soc_id = "r8a77970", },
+ { .soc_id = "r8a77995", },
{ /* sentinel */ }
};
@@ -943,6 +945,12 @@ static const struct of_device_id ipmmu_of_ids[] = {
.compatible = "renesas,ipmmu-r8a7796",
.data = _features_rcar_gen3,
}, {
+ .compatible = "renesas,ipmmu-r8a77970",
+ .data = _features_rcar_gen3,
+ }, {
+ .compatible = "renesas,ipmmu-r8a77995",
+ .data = _features_rcar_gen3,
+ }, {
/* Terminator */
},
};
@@ -1119,6 +1127,8 @@ module_exit(ipmmu_exit);
IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "renesas,ipmmu-vmsa");
IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795");
IOMMU_OF_DECLARE(ipmmu_r8a7796_iommu_of, "renesas,ipmmu-r8a7796");
+IOMMU_OF_DECLARE(ipmmu_r8a77970_iommu_of, "renesas,ipmmu-r8a77970");
+IOMMU_OF_DECLARE(ipmmu_r8a77995_iommu_of, "renesas,ipmmu-r8a77995");
MODULE_DESCRIPTION("IOMMU API for Renesas VMSA-compatible IPMMU");
MODULE_AUTHOR("Laurent Pinchart ");
--
2.7.4
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RESEND 2/6] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code
From: Magnus Damm
Support the r8a7796 IPMMU by sharing feature flags between
r8a7795 and r8a7796. Also update IOMMU_OF_DECLARE to hook
up the updated compat string.
[rebased on v4.17]
Signed-off-by: Jacopo Mondi
Signed-off-by: Magnus Damm
Reviewed-by: Geert Uytterhoeven
---
drivers/iommu/ipmmu-vmsa.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 5c1ade7..04c8015 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -760,8 +760,9 @@ static bool ipmmu_slave_whitelist(struct device *dev)
return false;
}
-static const struct soc_device_attribute soc_r8a7795[] = {
+static const struct soc_device_attribute soc_rcar_gen3[] = {
{ .soc_id = "r8a7795", },
+ { .soc_id = "r8a7796", },
{ /* sentinel */ }
};
@@ -769,7 +770,7 @@ static int ipmmu_of_xlate(struct device *dev,
struct of_phandle_args *spec)
{
/* For R-Car Gen3 use a white list to opt-in slave devices */
- if (soc_device_match(soc_r8a7795) && !ipmmu_slave_whitelist(dev))
+ if (soc_device_match(soc_rcar_gen3) && !ipmmu_slave_whitelist(dev))
return -ENODEV;
iommu_fwspec_add_ids(dev, spec->args, 1);
@@ -923,7 +924,7 @@ static const struct ipmmu_features ipmmu_features_default =
{
.twobit_imttbcr_sl0 = false,
};
-static const struct ipmmu_features ipmmu_features_r8a7795 = {
+static const struct ipmmu_features ipmmu_features_rcar_gen3 = {
.use_ns_alias_offset = false,
.has_cache_leaf_nodes = true,
.number_of_contexts = 8,
@@ -937,7 +938,10 @@ static const struct of_device_id ipmmu_of_ids[] = {
.data = _features_default,
}, {
.compatible = "renesas,ipmmu-r8a7795",
- .data = _features_r8a7795,
+ .data = _features_rcar_gen3,
+ }, {
+ .compatible = "renesas,ipmmu-r8a7796",
+ .data = _features_rcar_gen3,
}, {
/* Terminator */
},
@@ -1114,6 +1118,7 @@ module_exit(ipmmu_exit);
IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "renesas,ipmmu-vmsa");
IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795");
+IOMMU_OF_DECLARE(ipmmu_r8a7796_iommu_of, "renesas,ipmmu-r8a7796");
MODULE_DESCRIPTION("IOMMU API for Renesas VMSA-compatible IPMMU");
MODULE_AUTHOR("Laurent Pinchart ");
--
2.7.4
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RESEND 0/6] iommu: ipmmu-vmsa: Add more Gen3 SoCs support
Hello, this series collects patches sent to mailing lists in late 2017 to add support for a number of R-Car Gen3 SoCs to the ipmmu-vmsa driver. Part of the series these patches were part of went in through Alex Williamson tree and are now included in v4.17. These patches have not yet been collected, and need to be rebased on v4.17, and this what this series serves for. The series: - Increses the micro-TLB size to 48bits to accomodate newer SoCs - Adds support for M3-N, M3-W, V3-M and E3 to ipmmu-vmsa driver - Documents M3-N, V3H and E3 device tree bindings All patches have been acked/reviewed by, if nothing big happens they should be ready to be collected. Thanks j Jacopo Mondi (2): dt-bindings: iommu/ipmmu-vmsa: Add R-Car M3-N (R8A77965) iommu/ipmmu-vmsa: Hook up R8A77965 DT matching code Magnus Damm (3): iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48 iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code iommu/ipmmu-vmsa: Document R-Car V3H and E3 IPMMU DT bindings Simon Horman (1): iommu/ipmmu-vmsa: Hook up r8a779(70|95) DT matching code .../bindings/iommu/renesas,ipmmu-vmsa.txt | 3 ++ drivers/iommu/ipmmu-vmsa.c | 38 ++ 2 files changed, 34 insertions(+), 7 deletions(-) -- 2.7.4 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RESEND 5/6] iommu/ipmmu-vmsa: Hook up R8A77965 DT matching code
Add support for R-Car M3-N (R8A77965) SoC IPMMUs.
Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
---
drivers/iommu/ipmmu-vmsa.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 933a3da..6a0e714 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -763,6 +763,7 @@ static bool ipmmu_slave_whitelist(struct device *dev)
static const struct soc_device_attribute soc_rcar_gen3[] = {
{ .soc_id = "r8a7795", },
{ .soc_id = "r8a7796", },
+ { .soc_id = "r8a77965", },
{ .soc_id = "r8a77970", },
{ .soc_id = "r8a77995", },
{ /* sentinel */ }
@@ -945,6 +946,9 @@ static const struct of_device_id ipmmu_of_ids[] = {
.compatible = "renesas,ipmmu-r8a7796",
.data = _features_rcar_gen3,
}, {
+ .compatible = "renesas,ipmmu-r8a77965",
+ .data = _features_rcar_gen3,
+ }, {
.compatible = "renesas,ipmmu-r8a77970",
.data = _features_rcar_gen3,
}, {
@@ -1127,6 +1131,7 @@ module_exit(ipmmu_exit);
IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "renesas,ipmmu-vmsa");
IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795");
IOMMU_OF_DECLARE(ipmmu_r8a7796_iommu_of, "renesas,ipmmu-r8a7796");
+IOMMU_OF_DECLARE(ipmmu_r8a77965_iommu_of, "renesas,ipmmu-r8a77965");
IOMMU_OF_DECLARE(ipmmu_r8a77970_iommu_of, "renesas,ipmmu-r8a77970");
IOMMU_OF_DECLARE(ipmmu_r8a77995_iommu_of, "renesas,ipmmu-r8a77995");
--
2.7.4
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RESEND 1/6] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
From: Magnus Damm Bump up the maximum numbers of micro-TLBS to 48. Each IPMMU device instance get micro-TLB assignment via the "iommus" property in DT. Older SoCs tend to use a maximum number of 32 micro-TLBs per IPMMU instance however newer SoCs such as r8a7796 make use of up to 48 micro-TLBs. At this point no SoC specific handling is done to validate the maximum number of micro-TLBs, and because of that the DT information is assumed to be within correct range for each particular SoC. If needed in the future SoC specific feature flags can be added to handle the maximum number of micro-TLBs without requiring DT changes, however at this point this does not seem necessary. Signed-off-by: Magnus Damm Reviewed-by: Geert Uytterhoeven --- drivers/iommu/ipmmu-vmsa.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c index 40ae6e8..5c1ade7 100644 --- a/drivers/iommu/ipmmu-vmsa.c +++ b/drivers/iommu/ipmmu-vmsa.c @@ -194,7 +194,9 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device *dev) #define IMPMBA(n) (0x0280 + ((n) * 4)) #define IMPMBD(n) (0x02c0 + ((n) * 4)) -#define IMUCTR(n) (0x0300 + ((n) * 16)) +#define IMUCTR(n) ((n) < 32 ? IMUCTR0(n) : IMUCTR32(n)) +#define IMUCTR0(n) (0x0300 + ((n) * 16)) +#define IMUCTR32(n)(0x0600 + (((n) - 32) * 16)) #define IMUCTR_FIXADDEN(1 << 31) #define IMUCTR_FIXADD_MASK (0xff << 16) #define IMUCTR_FIXADD_SHIFT16 @@ -204,7 +206,9 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device *dev) #define IMUCTR_FLUSH (1 << 1) #define IMUCTR_MMUEN (1 << 0) -#define IMUASID(n) (0x0308 + ((n) * 16)) +#define IMUASID(n) ((n) < 32 ? IMUASID0(n) : IMUASID32(n)) +#define IMUASID0(n)(0x0308 + ((n) * 16)) +#define IMUASID32(n) (0x0608 + (((n) - 32) * 16)) #define IMUASID_ASID8_MASK (0xff << 8) #define IMUASID_ASID8_SHIFT8 #define IMUASID_ASID0_MASK (0xff << 0) @@ -955,7 +959,7 @@ static int ipmmu_probe(struct platform_device *pdev) } mmu->dev = >dev; - mmu->num_utlbs = 32; + mmu->num_utlbs = 48; spin_lock_init(>lock); bitmap_zero(mmu->ctx, IPMMU_CTX_MAX); mmu->features = of_device_get_match_data(>dev); -- 2.7.4 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 12/23] kernel/watchdog: Introduce a struct for NMI watchdog operations
On Thu, 14 Jun 2018, Nicholas Piggin wrote: > On Wed, 13 Jun 2018 18:31:17 -0700 > > I could look into creating the library for > > common code and relocate the hpet watchdog into arch/x86 for the hpet- > > specific parts. > > If you can investigate that approach, that would be appreciated. I hope > I did not misunderstand you there, Thomas. I'm not against cleanups and consolidation, quite the contrary. But this stuff just adds new infrastructure w/o showing that it's actually a cleanup and consolidation. Thanks, tglx ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH RESEND] iommu/msm: Don't call iommu_device_{, un}link from atomic context
Hi NIklas,
On Tue, Jun 12, 2018 at 7:36 PM, Niklas Cassel wrote:
> Fixes the following splat during boot:
>
> BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:747
> in_atomic(): 1, irqs_disabled(): 128, pid: 77, name: kworker/2:1
> 4 locks held by kworker/2:1/77:
> #0: (ptrval) ((wq_completion)"events"){+.+.}, at:
> process_one_work+0x1fc/0x8fc
> #1: (ptrval) (deferred_probe_work){+.+.}, at: process_one_work+0x1fc/0x8fc
> #2: (ptrval) (>mutex){}, at: __device_attach+0x40/0x178
> #3: (ptrval) (msm_iommu_lock){}, at: msm_iommu_add_device+0x28/0xcc
> irq event stamp: 348
> hardirqs last enabled at (347): [] kfree+0xe0/0x3c0
> hardirqs last disabled at (348): [] _raw_spin_lock_irqsave+0x2c/0x68
> softirqs last enabled at (0): [] copy_process.part.5+0x280/0x1a68
> softirqs last disabled at (0): [<>] (null)
> Preemption disabled at:
> [<>] (null)
> CPU: 2 PID: 77 Comm: kworker/2:1 Not tainted
> 4.17.0-rc5-wt-ath-01075-gaca0516bb4cf #239
> Hardware name: Generic DT based system
> Workqueue: events deferred_probe_work_func
> [] (unwind_backtrace) from [] (show_stack+0x20/0x24)
> [] (show_stack) from [] (dump_stack+0xa0/0xcc)
> [] (dump_stack) from [] (___might_sleep+0x1f8/0x2d4)
> ath10k_sdio mmc2:0001:1: Direct firmware load for
> ath10k/QCA9377/hw1.0/board-2.bin failed with error -2
> [] (___might_sleep) from [] (__might_sleep+0x70/0xa8)
> [] (__might_sleep) from [] (__mutex_lock+0x50/0xb28)
> [] (__mutex_lock) from [] (mutex_lock_nested+0x2c/0x34)
> ath10k_sdio mmc2:0001:1: board_file api 1 bmi_id N/A crc32 544289f7
> [] (mutex_lock_nested) from []
> (kernfs_find_and_get_ns+0x30/0x5c)
> [] (kernfs_find_and_get_ns) from []
> (sysfs_add_link_to_group+0x28/0x58)
> [] (sysfs_add_link_to_group) from []
> (iommu_device_link+0x50/0xb4)
> [] (iommu_device_link) from []
> (msm_iommu_add_device+0xa0/0xcc)
> [] (msm_iommu_add_device) from []
> (add_iommu_group+0x3c/0x64)
> [] (add_iommu_group) from [] (bus_for_each_dev+0x84/0xc4)
> [] (bus_for_each_dev) from [] (bus_set_iommu+0xd0/0x10c)
> [] (bus_set_iommu) from [] (msm_iommu_probe+0x5b8/0x66c)
> [] (msm_iommu_probe) from []
> (platform_drv_probe+0x60/0xbc)
> [] (platform_drv_probe) from []
> (driver_probe_device+0x30c/0x4cc)
> [] (driver_probe_device) from []
> (__device_attach_driver+0xac/0x14c)
> [] (__device_attach_driver) from []
> (bus_for_each_drv+0x68/0xc8)
> [] (bus_for_each_drv) from [] (__device_attach+0xe4/0x178)
> [] (__device_attach) from []
> (device_initial_probe+0x1c/0x20)
> [] (device_initial_probe) from []
> (bus_probe_device+0x98/0xa0)
> [] (bus_probe_device) from []
> (deferred_probe_work_func+0x74/0x198)
> [] (deferred_probe_work_func) from []
> (process_one_work+0x2c4/0x8fc)
> [] (process_one_work) from [] (worker_thread+0x2c4/0x5cc)
> [] (worker_thread) from [] (kthread+0x180/0x188)
> [] (kthread) from [] (ret_from_fork+0x14/0x20)
>
> Fixes: 42df43b36163 ("iommu/msm: Make use of iommu_device_register interface")
> Signed-off-by: Niklas Cassel
> ---
Thanks for the patch.
Reviewed-by: Vivek Gautam
Best regards
Vivek
> drivers/iommu/msm_iommu.c | 16 +---
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
> index 0d3350463a3f..9a95c9b9d0d8 100644
> --- a/drivers/iommu/msm_iommu.c
> +++ b/drivers/iommu/msm_iommu.c
> @@ -395,20 +395,15 @@ static int msm_iommu_add_device(struct device *dev)
> struct msm_iommu_dev *iommu;
> struct iommu_group *group;
> unsigned long flags;
> - int ret = 0;
>
> spin_lock_irqsave(_iommu_lock, flags);
> -
> iommu = find_iommu_for_dev(dev);
> + spin_unlock_irqrestore(_iommu_lock, flags);
> +
> if (iommu)
> iommu_device_link(>iommu, dev);
> else
> - ret = -ENODEV;
> -
> - spin_unlock_irqrestore(_iommu_lock, flags);
> -
> - if (ret)
> - return ret;
> + return -ENODEV;
>
> group = iommu_group_get_for_dev(dev);
> if (IS_ERR(group))
> @@ -425,13 +420,12 @@ static void msm_iommu_remove_device(struct device *dev)
> unsigned long flags;
>
> spin_lock_irqsave(_iommu_lock, flags);
> -
> iommu = find_iommu_for_dev(dev);
> + spin_unlock_irqrestore(_iommu_lock, flags);
> +
> if (iommu)
> iommu_device_unlink(>iommu, dev);
>
> - spin_unlock_irqrestore(_iommu_lock, flags);
> -
> iommu_group_remove_device(dev);
> }
>
> --
> 2.17.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
