On Thu, Apr 18, 2024 at 12:53:26PM -0700, Sean Christopherson wrote:
> On Thu, Apr 18, 2024, Will Deacon wrote:
> > On Mon, Apr 15, 2024 at 10:03:51AM -0700, Sean Christopherson wrote:
> > > On Sat, Apr 13, 2024, Marc Zyngier wrote:
> > > > On Fri, 12 Apr 2024 15:54
On Mon, Apr 15, 2024 at 10:03:51AM -0700, Sean Christopherson wrote:
> On Sat, Apr 13, 2024, Marc Zyngier wrote:
> > On Fri, 12 Apr 2024 15:54:22 +0100, Sean Christopherson
> > wrote:
> > >
> > > On Fri, Apr 12, 2024, Marc Zyngier wrote:
> > > > On
t; -}
> -
> bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> {
> u64 size = (range->end - range->start) << PAGE_SHIFT;
Thanks. It's nice to see this code retire:
Acked-by: Will Deacon
Also, if you're in the business of hacking the MMU notifier code, it
> some places treat it as an empty ring, others - non empty.
> This patch does not attempt to change the existing behaviour.
>
> Cc: sta...@vger.kernel.org
> Reported-by: Gavin Shan
> Reported-by: Will Deacon
> Suggested-by: Will Deacon
> Fixes: 275bf960ac69 (&qu
On Tue, Mar 26, 2024 at 11:43:13AM +, Will Deacon wrote:
> On Tue, Mar 26, 2024 at 09:38:55AM +, Keir Fraser wrote:
> > On Tue, Mar 26, 2024 at 03:49:02AM -0400, Michael S. Tsirkin wrote:
> > > > Secondly, the debugging code is enhanced so th
On Tue, Mar 26, 2024 at 09:38:55AM +, Keir Fraser wrote:
> On Tue, Mar 26, 2024 at 03:49:02AM -0400, Michael S. Tsirkin wrote:
> > > Secondly, the debugging code is enhanced so that the available head for
> > > (last_avail_idx - 1) is read for twice and recorded. It means the
> > > available
On Tue, Mar 19, 2024 at 02:59:23PM +1000, Gavin Shan wrote:
> On 3/19/24 02:59, Will Deacon wrote:
> > On Thu, Mar 14, 2024 at 05:49:23PM +1000, Gavin Shan wrote:
> > > The issue is reported by Yihuang Yu who have 'netperf' test on
> > > NVidia's grace-grace and grace-ho
On Tue, Mar 19, 2024 at 03:36:31AM -0400, Michael S. Tsirkin wrote:
> On Mon, Mar 18, 2024 at 04:59:24PM +, Will Deacon wrote:
> > On Thu, Mar 14, 2024 at 05:49:23PM +1000, Gavin Shan wrote:
> > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> &
On Thu, Mar 14, 2024 at 05:49:23PM +1000, Gavin Shan wrote:
> The issue is reported by Yihuang Yu who have 'netperf' test on
> NVidia's grace-grace and grace-hopper machines. The 'netperf'
> client is started in the VM hosted by grace-hopper machine,
> while the 'netperf' server is running on
On Wed, 11 Oct 2023 19:57:26 +0200, Luca Weiss wrote:
> From: Vladimir Lypak
>
> If the IOMMU has a power domain then some state will be lost in
> qcom_iommu_suspend and TZ will reset device if we don't call
> qcom_scm_restore_sec_cfg before accessing it again.
>
>
> [...]
Applied to will
On Mon, Oct 30, 2023 at 09:00:53AM +0200, Mike Rapoport wrote:
> On Thu, Oct 26, 2023 at 11:24:39AM +0100, Will Deacon wrote:
> > On Thu, Oct 26, 2023 at 11:58:00AM +0300, Mike Rapoport wrote:
> > > On Mon, Oct 23, 2023 at 06:14:20PM +0100, Will Deacon wrote:
> > > >
On Thu, Oct 26, 2023 at 11:58:00AM +0300, Mike Rapoport wrote:
> On Mon, Oct 23, 2023 at 06:14:20PM +0100, Will Deacon wrote:
> > On Mon, Sep 18, 2023 at 10:29:46AM +0300, Mike Rapoport wrote:
> > > diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
> &
> - return __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START, VMALLOC_END,
> - GFP_KERNEL, PAGE_KERNEL_ROX, VM_FLUSH_RESET_PERMS,
> - NUMA_NO_NODE, __builtin_return_address(0));
> -}
It's slightly curious that we didn't clear the tag here, so it's nice that
it all happens magically with your series:
Acked-by: Will Deacon
Will
Hi Mike,
On Mon, Sep 18, 2023 at 10:29:46AM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Extend execmem parameters to accommodate more complex overrides of
> module_alloc() by architectures.
>
> This includes specification of a fallback range required by arm, arm64
> and
On Tue, 12 Sep 2023 15:31:38 +0200, Konrad Dybcio wrote:
> After the recent cleanups ([1], [2]) some in-tree abusers that directly
> accessed the RPM bus clocks, effectively circumventing and working
> against the efforts of the interconnect framework, were found.
>
> Patches 1-5 drop deprecated
On Wed, Apr 14, 2021 at 12:16:38PM +0200, Peter Zijlstra wrote:
> How's this then? Compile tested only on openrisc/simple_smp_defconfig.
>
> diff --git a/include/asm-generic/qspinlock.h b/include/asm-generic/qspinlock.h
> index d74b13825501..a7a1296b0b4d 100644
> ---
On Mon, Apr 12, 2021 at 05:31:13PM +0530, Sumit Garg wrote:
> On Tue, 30 Mar 2021 at 18:00, Sumit Garg wrote:
> > On Tue, 30 Mar 2021 at 14:07, Lecopzer Chen
> > wrote:
> > > > > On Fri, 15 Jan 2021 at 17:32, Sumit Garg
> > > > > wrote:
> > > > > >
> > > > > > With the recent feature added to
On Fri, Apr 09, 2021 at 09:38:15PM +0200, Arnd Bergmann wrote:
> On Fri, Apr 9, 2021 at 6:56 PM Sven Peter wrote:
> > On Wed, Apr 7, 2021, at 12:44, Will Deacon wrote:
> > > On Sun, Mar 28, 2021 at 09:40:07AM +0200, Sven Peter wrote:
> > >
> > >
On Thu, Apr 08, 2021 at 01:38:17PM -0500, Rob Herring wrote:
> On Thu, Apr 8, 2021 at 6:08 AM Mark Rutland wrote:
> > On Wed, Apr 07, 2021 at 01:44:37PM +0100, Will Deacon wrote:
> > > On Thu, Apr 01, 2021 at 02:45:21PM -0500, Rob Herring wrote:
> > > > On
On Wed, Mar 10, 2021 at 10:53:23AM +0530, Viresh Kumar wrote:
> Rename freq_scale to a less generic name, as it will get exported soon
> for modules. Since x86 already names its own implementation of this as
> arch_freq_scale, lets stick to that.
>
> Suggested-by: Will Deaco
On Fri, Apr 16, 2021 at 02:34:41PM +0100, Mark Rutland wrote:
> On Fri, Apr 16, 2021 at 01:33:22PM +0100, Catalin Marinas wrote:
> > On Fri, Apr 16, 2021 at 03:55:31PM +0800, He Zhe wrote:
> > > The general version of is_syscall_success does not handle 32-bit
> > > compatible case, which would
On Mon, Apr 19, 2021 at 11:40:54AM +0200, Paolo Bonzini wrote:
> On 19/04/21 11:36, Peter Zijlstra wrote:
> > On Mon, Apr 19, 2021 at 11:02:12AM +0200, Paolo Bonzini wrote:
> > > > void writer(void)
> > > > {
> > > > atomic_store_explicit(, seq+1, memory_order_relaxed);
> > > >
On Thu, Apr 15, 2021 at 04:26:46PM +, Ali Saidi wrote:
>
> On Thu, 15 Apr 2021 16:02:29 +0100, Will Deacon wrote:
> > On Thu, Apr 15, 2021 at 02:25:52PM +, Ali Saidi wrote:
> > > While this code is executed with the wait_lock held, a reader can
> > > ac
On Thu, Apr 15, 2021 at 04:37:58PM +0100, Catalin Marinas wrote:
> On Thu, Apr 15, 2021 at 04:28:21PM +0100, Will Deacon wrote:
> > On Thu, Apr 15, 2021 at 05:03:58PM +0200, Peter Zijlstra wrote:
> > > diff --git a/kernel/locking/qrwlock.c b/kernel/locking/qrwlock.c
> &
On Thu, Apr 15, 2021 at 05:03:58PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 15, 2021 at 02:25:52PM +, Ali Saidi wrote:
> > While this code is executed with the wait_lock held, a reader can
> > acquire the lock without holding wait_lock. The writer side loops
> > checking the value with the
_WAITING,
> + atomic_cond_read_relaxed(>cnts, VAL == _QW_WAITING);
> + } while (atomic_cmpxchg_acquire(>cnts, _QW_WAITING,
> _QW_LOCKED) != _QW_WAITING);
Patch looks good, so with an updated message:
Acked-by: Will Deacon
Will
On Thu, Apr 15, 2021 at 10:02:18AM +0100, Catalin Marinas wrote:
> (fixed Will's email address)
>
> On Thu, Apr 15, 2021 at 10:09:54AM +0200, Peter Zijlstra wrote:
> > On Thu, Apr 15, 2021 at 05:47:34AM +0900, Stafford Horne wrote:
> > > > How's this then? Compile tested only on
Hi Linus,
Please pull these three arm64 fixes for -rc8; summary in the tag. We
don't have anything else on the horizon, although two of these issues
(the asm constraint and kprobes bugs) have been around for a while so
you never know.
Cheers,
Will
--->8
The following changes since commit
On Mon, 12 Apr 2021 17:41:01 +0800, Jisheng Zhang wrote:
> If instruction being single stepped caused a page fault, the kprobes
> is cancelled to let the page fault handler continue as a normal page
> fault. But the local irqflags are disabled so cpu will restore pstate
> with DAIF masked. After
On Thu, Apr 08, 2021 at 04:06:23PM +0100, Mark Rutland wrote:
> On Thu, Apr 08, 2021 at 03:56:04PM +0100, Will Deacon wrote:
> > On Thu, Apr 08, 2021 at 03:37:23PM +0100, Vincenzo Frascino wrote:
> > > diff --git a/arch/arm64/kernel/entry-common.c
> > > b/arch/
nchronous
> tag check faults")
> Cc: Catalin Marinas
> Cc: Will Deacon
> Reported-by: Will Deacon
> Signed-off-by: Vincenzo Frascino
> ---
> arch/arm64/include/asm/mte.h | 8
> arch/arm64/kernel/entry-common.c | 6 ++
> arch/arm64/kernel/entr
Hi Joerg,
There's hardly anything on the SMMU front for 5.13, but please pull
these regardless. Summary in the tag.
Cheers,
Will
--->8
The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0:
Linux 5.12-rc3 (2021-03-14 14:41:02 -0700)
are available in the Git
Hi John,
On Thu, Apr 08, 2021 at 01:55:02PM +0100, John Garry wrote:
> On 08/04/2021 10:01, Jonathan Cameron wrote:
> > On Wed, 7 Apr 2021 21:40:05 +0100
> > Will Deacon wrote:
> >
> > > On Wed, Apr 07, 2021 at 05:49:02PM +0800, Qi Liu wrote:
> > > >
On Thu, Apr 01, 2021 at 04:23:44PM -0700, Kees Cook wrote:
> This provides the ability for architectures to enable kernel stack base
> address offset randomization. This feature is controlled by the boot
> param "randomize_kstack_offset=on/off", with its default value set by
>
> arch/arm64/kernel/Makefile | 5 +
> arch/arm64/kernel/syscall.c | 16 ++++
> 3 files changed, 22 insertions(+)
Acked-by: Will Deacon
Will
flag, cpu));
> +
> + /*
> + * The atomic_fetch_or_release() above must complete before the
> + * atomic_read_acquire() below to avoid racing aic_ipi_unmask().
> + */
(same here)
> + smp_mb__after_atomic();
> +
> + if (!(pending & irq_bit) &&
> + (atomic_read(per_cpu_ptr(_vipi_enable, cpu)) & irq_bit))
> + send |= AIC_IPI_SEND_CPU(cpu);
> + }
But with that:
Acked-by: Will Deacon
Will
return ioremap_np(offset, size) ?: ioremap(offset, size);
but however it's done, the logic looks good to me and thanks Hector for
updating this:
Acked-by: Will Deacon
Will
On Wed, Apr 07, 2021 at 04:31:31PM +0100, Alexandru Elisei wrote:
> On 3/26/21 3:16 AM, Yanan Wang wrote:
> > We currently uniformly permorm CMOs of D-cache and I-cache in function
> > user_mem_abort before calling the fault handlers. If we get concurrent
> > guest faults(e.g. translation faults,
On Wed, Apr 07, 2021 at 05:49:02PM +0800, Qi Liu wrote:
> PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported
> to sample bandwidth, latency, buffer occupation etc.
>
> Each PMU RCiEP device monitors multiple root ports, and each RCiEP is
> registered as a pmu in
[Moving Mark to To: since I'd like his view on this]
On Thu, Apr 01, 2021 at 02:45:21PM -0500, Rob Herring wrote:
> On Wed, Mar 31, 2021 at 11:01 AM Will Deacon wrote:
> >
> > On Tue, Mar 30, 2021 at 12:09:38PM -0500, Rob Herring wrote:
> > > On Tue, Mar 30, 2021 at 10:
On Wed, 7 Apr 2021 16:44:48 +0800, Zenghui Yu wrote:
> Per SMMUv3 spec, there is no Size and Addr field in the PREFETCH_CONFIG
> command and they're not used by the driver. Remove them.
>
> We can add them back if we're going to use PREFETCH_ADDR in the future.
Applied to will
On Sun, Mar 28, 2021 at 09:40:07AM +0200, Sven Peter wrote:
> Apple's DART iommu uses a pagetable format that shares some
> similarities with the ones already implemented by io-pgtable.c.
> Add a new format variant to support the required differences
> so that we don't have to duplicate the
On Sun, Mar 28, 2021 at 09:40:09AM +0200, Sven Peter wrote:
> Apple's new SoCs use iommus for almost all peripherals. These Device
> Address Resolution Tables must be setup before these peripherals can
> act as DMA masters.
>
> Signed-off-by: Sven Peter
> ---
> MAINTAINERS
On Thu, 1 Apr 2021 19:16:41 +0800, Qi Liu wrote:
> The initialization of value in function armv8pmu_read_hw_counter()
> and armv8pmu_read_counter() seem redundant, as they are soon updated.
> So, We can remove them.
Applied to will (for-next/perf), thanks!
[1/1] arm64: perf: Remove redundant
On Wed, Mar 31, 2021 at 12:52:11PM -0500, Rob Herring wrote:
> On Wed, Mar 31, 2021 at 10:38 AM Will Deacon wrote:
> >
> > On Tue, Mar 30, 2021 at 04:08:11PM -0500, Rob Herring wrote:
> > > On Tue, Mar 30, 2021 at 12:09 PM Rob Herring wrote:
> > > > On Tue,
Hi Kees,
On Wed, Mar 31, 2021 at 01:54:52PM -0700, Kees Cook wrote:
> Hi Will (and Mark and Catalin),
>
> Can you take this via the arm64 tree for v5.13 please? Thomas has added
> his Reviewed-by, so it only leaves arm64's. :)
Sorry, these got mixed up in my inbox so I just replied to v7 and v8
On Fri, Mar 19, 2021 at 02:28:34PM -0700, Kees Cook wrote:
> Allow for a randomized stack offset on a per-syscall basis, with roughly
> 5 bits of entropy. (And include AAPCS rationale AAPCS thanks to Mark
> Rutland.)
>
> In order to avoid unconditional stack canaries on syscall entry (due to
>
On Tue, Mar 30, 2021 at 01:57:47PM -0700, Kees Cook wrote:
> diff --git a/include/linux/randomize_kstack.h
> b/include/linux/randomize_kstack.h
> new file mode 100644
> index ..351520803006
> --- /dev/null
> +++ b/include/linux/randomize_kstack.h
> @@ -0,0 +1,55 @@
> +/*
On Tue, Mar 30, 2021 at 12:09:38PM -0500, Rob Herring wrote:
> On Tue, Mar 30, 2021 at 10:31 AM Will Deacon wrote:
> >
> > On Wed, Mar 10, 2021 at 05:08:29PM -0700, Rob Herring wrote:
> > > From: Raphael Gault
> > >
> > > Keep track of event opened w
On Wed, Mar 10, 2021 at 05:08:37PM -0700, Rob Herring wrote:
> From: Raphael Gault
>
> Add a documentation file to describe the access to the pmu hardware
> counters from userspace
>
> Signed-off-by: Raphael Gault
> Signed-off-by: Rob Herring
> ---
> v6:
> - Update the chained event section
On Tue, Mar 30, 2021 at 04:08:11PM -0500, Rob Herring wrote:
> On Tue, Mar 30, 2021 at 12:09 PM Rob Herring wrote:
> > On Tue, Mar 30, 2021 at 10:31 AM Will Deacon wrote:
> > > The logic here feels like it
> > > could with a bit of untangling.
> >
> > Yes
On Tue, Mar 30, 2021 at 10:35:21AM -0700, Daniel Walker wrote:
> On Mon, Mar 29, 2021 at 11:07:51AM +0100, Will Deacon wrote:
> > On Thu, Mar 25, 2021 at 12:59:56PM -0700, Daniel Walker wrote:
> > > On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote:
> > >
On Wed, Mar 31, 2021 at 05:22:18PM +0800, Jianlin Lv wrote:
> On Tue, Mar 30, 2021 at 5:31 PM Will Deacon wrote:
> >
> > On Tue, Mar 30, 2021 at 03:42:35PM +0800, Jianlin Lv wrote:
> > > A64_MOV is currently mapped to Add Instruction. Architecturally MOV
> > &
On Wed, Mar 10, 2021 at 05:08:29PM -0700, Rob Herring wrote:
> From: Raphael Gault
>
> Keep track of event opened with direct access to the hardware counters
> and modify permissions while they are open.
>
> The strategy used here is the same which x86 uses: every time an event
> is mapped, the
On Tue, Mar 30, 2021 at 08:03:36AM -0700, Rob Clark wrote:
> On Tue, Mar 30, 2021 at 2:34 AM Will Deacon wrote:
> >
> > On Mon, Mar 29, 2021 at 09:02:50PM -0700, Rob Clark wrote:
> > > On Mon, Mar 29, 2021 at 7:47 AM Will Deacon wrote:
> > > >
> > &g
ed-off-by: Raphael Gault
> Signed-off-by: Rob Herring
> ---
> arch/arm64/kernel/perf_event.c | 18 ++
> include/linux/perf/arm_pmu.h | 2 ++
> 2 files changed, 20 insertions(+)
Acked-by: Will Deacon
Will
On Tue, Mar 30, 2021 at 04:57:50AM -0700, zhouchuangao wrote:
> It can be optimized at compile time.
Hmm, I don't see it (and I also don't understand why we care). Do you have
numbers showing that this is worthwhile?
Will
On Mon, 29 Mar 2021 20:32:01 +0800, Qi Liu wrote:
> Fix following html build warnings:
> Documentation/admin-guide/perf/hisi-pmu.rst:61: WARNING: Unexpected
> indentation.
> Documentation/admin-guide/perf/hisi-pmu.rst:62: WARNING: Block quote ends
> without a blank line; unexpected unindent.
>
On Mon, Mar 29, 2021 at 09:02:50PM -0700, Rob Clark wrote:
> On Mon, Mar 29, 2021 at 7:47 AM Will Deacon wrote:
> >
> > On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
> > > db820c wants to use the qcom smmu path to get HUPCF set (which keeps
&g
On Tue, Mar 30, 2021 at 03:42:35PM +0800, Jianlin Lv wrote:
> A64_MOV is currently mapped to Add Instruction. Architecturally MOV
> (register) is an alias of ORR (shifted register) and MOV (to or from SP)
> is an alias of ADD (immediate).
> This patch redefines A64_MOV and uses existing
On Mon, Mar 29, 2021 at 12:15:16AM -0700, Nikitas Angelinas wrote:
> Since __MUTEX_INITIALIZER() is used on memory that is initialized to 0
> anyway this change should not have an effect, but it seems better to
> initialize osq explicitly for completeness, as done in other macros and
> functions
On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
> db820c wants to use the qcom smmu path to get HUPCF set (which keeps
> the GPU from wedging and then sometimes wedging the kernel after a
> page fault), but it doesn't have separate pagetables support yet in
> drm/msm so we can't go
On Wed, Mar 24, 2021 at 12:05:22PM +0800, Lecopzer Chen wrote:
> Before this patch, someone who wants to use VMAP_STACK when
> KASAN_GENERIC enabled must explicitly select KASAN_VMALLOC.
>
> From Will's suggestion [1]:
> > I would _really_ like to move to VMAP stack unconditionally, and
> >
Hi Hector,
On Fri, Mar 26, 2021 at 05:58:15PM +0900, Hector Martin wrote:
> On 25/03/2021 04.57, Will Deacon wrote:
> > > + event = readl(ic->base + AIC_EVENT);
> > > + type = FIELD_GET(AIC_EVENT_TYPE, event);
> > > + irq
On Thu, Mar 25, 2021 at 12:59:56PM -0700, Daniel Walker wrote:
> On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote:
> >
> > Ok, so you agree we don't need to provide two CMDLINE, one to be appended
> > and one to be prepended.
> >
> > Let's only provide once CMDLINE as of today,
On Mon, Mar 29, 2021 at 05:06:20PM +0800, liuqi (BA) wrote:
>
>
> On 2021/3/29 16:47, Will Deacon wrote:
> > On Fri, Mar 26, 2021 at 05:07:41PM +0800, Shaokun Zhang wrote:
> > > Apologies for the mistake.
> > >
> > > Will, shall I send a
On Fri, Mar 26, 2021 at 05:07:41PM +0800, Shaokun Zhang wrote:
> Apologies for the mistake.
>
> Will, shall I send a new version v5 to fix this issue or other?
Please send additional patches on top now that these are queued.
Thanks,
Will
On Thu, Mar 25, 2021 at 12:18:38PM +0100, Christophe Leroy wrote:
>
>
> Le 03/03/2021 à 18:57, Will Deacon a écrit :
> > On Tue, Mar 02, 2021 at 05:25:22PM +, Christophe Leroy wrote:
> > > Most architectures have similar boot command line manipulation
> &g
On Thu, Mar 25, 2021 at 08:24:53PM +0100, Dmitry Vyukov wrote:
> On Thu, Mar 25, 2021 at 8:10 PM Will Deacon wrote:
> > On Thu, Mar 25, 2021 at 07:34:54PM +0100, Dmitry Vyukov wrote:
> > > On Thu, Mar 25, 2021 at 7:20 PM Will Deacon wrote:
> > > > On Thu, Mar 18, 20
On Thu, Mar 25, 2021 at 07:34:54PM +0100, Dmitry Vyukov wrote:
> On Thu, Mar 25, 2021 at 7:20 PM Will Deacon wrote:
> >
> > On Thu, Mar 18, 2021 at 08:34:16PM +0100, Dmitry Vyukov wrote:
> > > On Thu, Mar 18, 2021 at 8:31 PM syzbot
> > > wrote:
> > > >
> watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [syz-executor.1:3684]
>
> +Will, arm
>
> If I am reading this commit correctly, this is caused by:
>
> commit cae118b6acc309539b9e846cbb19187c164c
> Author: Will Deacon
> Date: Wed Mar 3 13:49:27 2021 +
>
On Wed, 24 Mar 2021 16:16:03 +0800, Zhen Lei wrote:
> In arm_smmu_gerror_handler(), the value of the SMMU_GERROR register is
> filtered by GERROR_ERR_MASK. However, the GERROR_ERR_MASK does not contain
> the SFM bit. As a result, the subsequent error processing is not performed
> when only the SFM
On Mon, 15 Mar 2021 11:32:24 +0530, Rajendra Nayak wrote:
> Add the SoC specific compatible for SC7280 implementing
> arm,mmu-500.
Applied to will (for-joerg/arm-smmu/updates), thanks!
[1/1] dt-bindings: arm-smmu: Add compatible for SC7280 SoC
https://git.kernel.org/will/c/a9aa2bb18ecb
On Thu, Mar 25, 2021 at 08:29:57PM +0800, John Garry wrote:
> The Intel IOMMU driver supports flushing the per-CPU rcaches when a CPU is
> offlined.
>
> Let's move it to core code, so everyone can take advantage.
>
> Also throw in a patch to stop exporting free_iova_fast().
>
> Differences to
On Tue, Mar 09, 2021 at 12:10:44PM +0530, Sai Prakash Ranjan wrote:
> On 2021-02-05 17:38, Sai Prakash Ranjan wrote:
> > On 2021-02-04 03:16, Will Deacon wrote:
> > > On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote:
> > > > On 2021-02
On Tue, Mar 23, 2021 at 01:58:00PM +0800, Yong Wu wrote:
> This patch only adds support for building the IOMMU-v1 driver as module.
> Correspondingly switch the config to tristate.
>
> Signed-off-by: Yong Wu
> ---
> rebase on v5.12-rc2.
> ---
> drivers/iommu/Kconfig| 2 +-
>
/iommu/tegra-smmu.c | 5 +---
> drivers/iommu/virtio-iommu.c| 5 +---
> include/linux/iommu.h | 29 -
> 22 files changed, 31 insertions(+), 98 deletions(-)
I was worried this might blow up with !CONFIG_IOMMU_API, but actually
it all looks fine and is much cleaner imo so:
Acked-by: Will Deacon
Will
mu.c | 1 +
> drivers/iommu/virtio-iommu.c| 1 +
> include/linux/iommu.h | 9 +
> 5 files changed, 5 insertions(+), 8 deletions(-)
Acked-by: Will Deacon
Will
On Thu, Mar 25, 2021 at 01:10:12PM +0530, Sai Prakash Ranjan wrote:
> On 2021-03-15 00:31, Sai Prakash Ranjan wrote:
> > On 2021-03-12 04:59, Bjorn Andersson wrote:
> > > On Sat 27 Feb 07:53 CST 2021, Sai Prakash Ranjan wrote:
> > > > On 2021-02-27 00:44, Bjorn Andersson wrote:
> > > > > On Fri 26
1 file changed, 8 insertions(+), 7 deletions(-)
Acked-by: Will Deacon
Will
Hi Linus,
Please pull these arm64 fixes for -rc5. Minor fixes all over, ranging
from typos to tests to errata workarounds. Summary in the tag.
Cheers,
Will
--->8
The following changes since commit c8e3866836528a4ba3b0535834f03768d74f7d8e:
perf/arm_dmc620_pmu: Fix error return code in
On Thu, Mar 25, 2021 at 11:07:40PM +0900, Hector Martin wrote:
> On 25/03/2021 04.09, Arnd Bergmann wrote:
> > On Wed, Mar 24, 2021 at 7:12 PM Will Deacon wrote:
> > >
> > > > +/*
> > > > + * ioremap_np needs an explicit architecture implementation, as
On Mon, 8 Feb 2021 21:04:58 +0800, Qi Liu wrote:
> For each PMU event, there is a SMMU_EVENT_ATTR(xx, XX) and
> _event_attr_xx.attr.attr. Let's redefine the SMMU_EVENT_ATTR
> to simplify the smmu_pmu_events.
Applied to will (for-next/perf), thanks!
[1/1] drivers/perf: Simplify the SMMUv3 PMU
On Fri, 19 Mar 2021 18:04:30 +0800, Qi Liu wrote:
> Use the generic sysfs_emit() and sysfs_emit_at() function to take
> place of sprintf/snprintf/scnprintf, to avoid buffer overrun.
>
> Qi Liu (2):
> drivers/perf: convert sysfs scnprintf family to sysfs_emit_at() and
> sysfs_emit()
>
/arm64/Makefile | 5 +++--
> tools/perf/arch/powerpc/Makefile | 5 +++--
> tools/perf/arch/s390/Makefile| 5 +++--
> 3 files changed, 9 insertions(+), 6 deletions(-)
For arm64:
Acked-by: Will Deacon
Will
On Wed, 24 Mar 2021 12:24:58 +0530, Maninder Singh wrote:
> function protypes are missed before defination, which
> leads to compilation warning with "-Wmissing-prototypes"
> flag.
>
> https://lkml.org/lkml/2021/3/19/840
>
> arch/arm64/kernel/process.c:261:6: warning: no previous prototype for
Hi Hector,
Sorry it took me so long to get to this. Some comments below.
On Fri, Mar 05, 2021 at 06:38:51AM +0900, Hector Martin wrote:
> This is the root interrupt controller used on Apple ARM SoCs such as the
> M1. This irqchip driver performs multiple functions:
>
> * Handles both IRQs and
On Wed, Mar 24, 2021 at 06:59:21PM +, Mark Rutland wrote:
> On Wed, Mar 24, 2021 at 06:38:18PM +, Will Deacon wrote:
> > On Fri, Mar 05, 2021 at 06:38:48AM +0900, Hector Martin wrote:
> > > Apple ARM64 SoCs have a ton of vendor-specific registers we're going to
On Fri, Mar 05, 2021 at 06:38:48AM +0900, Hector Martin wrote:
> Apple ARM64 SoCs have a ton of vendor-specific registers we're going to
> have to deal with, and those don't really belong in sysreg.h with all
> the architectural registers. Make a new home for them, and add some
> registers which
er to remove if you just moved the definitions,
rather than reordered than and changed the comments at the same time!
But I *think* nothing had changed, so:
Acked-by: Will Deacon
Will
p((addr), (size),
> __pgprot(PROT_DEVICE_nGnRnE))
Probably worth noting that whether or not this actually results in a
non-posted mapping depends on the system architecture, but this is the
best we can do, so:
Acked-by: Will Deacon
I would personally prefer that drivers didn't have to care ab
,
> APPLE_CPU_PART_M1_ICESTORM)
> +#define MIDR_APPLE_M1_FIRESTORM MIDR_CPU_MODEL(ARM_CPU_IMP_APPLE,
> APPLE_CPU_PART_M1_FIRESTORM)
We usually only merge these when they're needed, but this SoC seems broken
enough that I can see the value in having them from the start :(
Acked-by: Will Deacon
Will
On Fri, Mar 05, 2021 at 06:38:43AM +0900, Hector Martin wrote:
> ARM64 currently defaults to posted MMIO (nGnRnE), but some devices
> require the use of non-posted MMIO (nGnRE). Introduce a new ioremap()
> variant to handle this case. ioremap_np() is aliased to ioremap() by
> default on arches
On Fri, Mar 05, 2021 at 06:38:36AM +0900, Hector Martin wrote:
> From: Marc Zyngier
>
> It seems that the CPU known as Apple M1 has the terrible habit
> of being stuck with HCR_EL2.E2H==1, in violation of the architecture.
>
> Try and work around this deplorable state of affairs by detecting
>
t; from AArch32 EL0, so we keep the common el0_fiq_invalid handler.
>
> Signed-off-by: Mark Rutland
> Tested-by: Hector Martin
> Cc: Catalin Marinas
> Cc: James Morse
> Cc: Marc Zyngier
> Cc: Thomas Gleixner
> Cc: Will Deacon
> ---
>
not have an
> effect on other systems - if spurious FIQs were arriving, they would
> already panic the kernel.
>
> Signed-off-by: Hector Martin
> Signed-off-by: Mark Rutland
> Tested-by: Hector Martin
> Cc: Catalin Marinas
> Cc: James Morse
> Cc: Marc Zyngier
>
e before DAIF rework]
> Signed-off-by: Mark Rutland
> Tested-by: Hector Martin
> Cc: Catalin Marinas
> Cc: James Morse
> Cc: Thomas Gleixner
> Cc: Will Deacon
> ---
> arch/arm64/kernel/entry.S | 80
> +------
> 1 file changed, 43 insertions(+), 37 deletions(-)
Acked-by: Will Deacon
Will
ufficient for debug purposes.
>
> Signed-off-by: Mark Rutland
> Tested-by: Hector Martin
> Cc: Catalin Marinas
> Cc: James Morse
> Cc: Marc Zyngier
> Cc: Thomas Gleixner
> Cc: Will Deacon
> ---
> arch/arm64/kernel/irq.c | 12 ++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
Acked-by: Will Deacon
Will
Please suggest a one if you have a better idea.
>
>
> arch/arm64/Kconfig | 3 +++
> arch/arm64/Makefile | 2 +-
> 2 files changed, 4 insertions(+), 1 deletion(-)
Acked-by: Will Deacon
Will
On Tue, Mar 23, 2021 at 12:08:56PM +, Robin Murphy wrote:
> On 2021-03-23 07:34, Yang Yingliang wrote:
> > When copy over 128 bytes, src/dst is added after
> > each ldp/stp instruction, it will cost more time.
> > To improve this, we only add src/dst after load
> > or store 64 bytes.
>
> This
1 - 100 of 10388 matches
Mail list logo
