On Fri, Aug 21, 2020 at 02:26:14PM +1200, Barry Song wrote:
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index bdc1f33fd3d1..3f33b89aeab5 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++
On Fri, Aug 21, 2020 at 08:19:18AM +0200, Christoph Hellwig wrote:
> FYI, as of the last one I'm fine now, bit I really need an ACK from
> the arm64 maintainers.
Going through the dreaded backlog this morning...
Will
cfg = dev_iommu_priv_get(dev);
> - if (!cfg)
> - return -ENODEV;
> -
> smmu = cfg->smmu;
>
> ret = arm_smmu_rpm_get(smmu);
Acked-by: Will Deacon
Will
On Tue, Jul 28, 2020 at 01:07:14AM +, Jianyong Wu wrote:
>
>
> > -Original Message-
> > From: Will Deacon
> > Sent: Monday, July 27, 2020 7:38 PM
> > To: Jianyong Wu
> > Cc: net...@vger.kernel.org; yangbo...@nxp.com; john.stu...@linar
; > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -13427,8 +13427,18 @@ F: tools/perf/
> > > PERFORMANCE EVENTS SUBSYSTEM ARM64 PMU EVENTS
> > > R: John Garry
> > > R: Will Deacon
> > > +R: Mathieu Poirier
> > > +R:
On Tue, Aug 18, 2020 at 12:01:43PM -0700, Linus Torvalds wrote:
> On Mon, Aug 17, 2020 at 2:04 PM Yang Shi wrote:
> >
> > We could just skip the spurious TLB flush to mitigate the regression.
>
> Ok, this patch I will apply.
Cheers.
> I still hope that arm64 fixes (maybe already fixed) their
On Tue, Aug 18, 2020 at 08:31:08AM +0200, Paolo Bonzini wrote:
> On 11/08/20 12:27, Will Deacon wrote:
> > Will Deacon (2):
> > KVM: Pass MMU notifier range flags to kvm_unmap_hva_range()
> > KVM: arm64: Only reschedule if MMU_NOTIFIER_RANGE_BLOCKABLE is not set
> &g
On Tue, Aug 18, 2020 at 06:37:39PM +0900, Cho KyongHo wrote:
> On Tue, Aug 18, 2020 at 09:28:53AM +0100, Will Deacon wrote:
> > On Tue, Aug 18, 2020 at 04:43:10PM +0900, Cho KyongHo wrote:
> > > Cache maintenance operations in the most of CPU architectures needs
> >
On Tue, Aug 18, 2020 at 04:43:10PM +0900, Cho KyongHo wrote:
> Cache maintenance operations in the most of CPU architectures needs
> memory barrier after the cache maintenance for the DMAs to view the
> region of the memory correctly. The problem is that memory barrier is
> very expensive and
On Thu, Aug 13, 2020 at 08:11:02AM -0700, Rob Clark wrote:
> On Thu, Aug 13, 2020 at 6:14 AM Will Deacon wrote:
> >
> > On Mon, Aug 10, 2020 at 04:26:48PM -0600, Jordan Crouse wrote:
> > > Add domain attribute DOMAIN_ATTR_PGTABLE_CFG. This will be used by
> > &
On Mon, Aug 10, 2020 at 04:26:49PM -0600, Jordan Crouse wrote:
> Add a special implementation for the SMMU attached to most Adreno GPU
> target triggered from the qcom,adreno-smmu compatible string.
>
> The new Adreno SMMU implementation will enable split pagetables
> (TTBR1) for the domain
On Mon, Aug 10, 2020 at 04:26:44PM -0600, Jordan Crouse wrote:
> This series adds an Adreno SMMU implementation to arm-smmu to allow GPU
> hardware
> pagetable switching.
>
> The Adreno GPU has built in capabilities to switch the TTBR0 pagetable during
> runtime to allow each individual instance
On Mon, Aug 10, 2020 at 04:26:48PM -0600, Jordan Crouse wrote:
> Add domain attribute DOMAIN_ATTR_PGTABLE_CFG. This will be used by
> arm-smmu to share the current pagetable configuration with the
> leaf driver and to allow the leaf driver to set up a new pagetable
> configuration under certain
On Mon, Aug 10, 2020 at 04:26:57PM -0600, Jordan Crouse wrote:
> Add a new implementation hook to allow the implementation specific code
> to tweek the context bank configuration just before it gets written.
> The first user will be the Adreno GPU implementation to turn on
> SCTLR.HUPCF to ensure
riety of locking primitives which can be divided
> -into two categories:
> +into three categories:
>
> - Sleeping locks
> - CPU local locks
Acked-by: Will Deacon
Will
[ Adding John, as I only just realised he wasn't on CC and we were talking
about him! ]
On Thu, Aug 13, 2020 at 10:59:01AM +0100, Will Deacon wrote:
> On Wed, Aug 12, 2020 at 03:53:34PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Aug 12, 2020 at 10:06:53AM -0600, Mathieu Poirier
the cycles to
> > pick it up. Leo has spent a lot of time in that code and as such I
> > suggest that he starts maintaining it, probably following the same
> > kind of arrangement you and I have for coresight.
>
> Thats ok with me, I think we should ref
On Thu, Aug 13, 2020 at 02:49:37PM +0530, Sai Prakash Ranjan wrote:
> On 2020-08-13 14:33, Will Deacon wrote:
> > On Thu, Aug 13, 2020 at 01:48:34PM +0530, Sai Prakash Ranjan wrote:
> > > KRYO4XX gold/big CPU cores are based on Cortex-A76 which has CSV2
> > > bits
On Thu, Aug 13, 2020 at 01:48:34PM +0530, Sai Prakash Ranjan wrote:
> KRYO4XX gold/big CPU cores are based on Cortex-A76 which has CSV2
> bits set and are spectre-v2 safe. But on big.LITTLE systems where
> they are coupled with other CPU cores such as the KRYO4XX silver
> based on Cortex-A55 which
On Wed, Aug 12, 2020 at 05:42:05PM +0100, Szabolcs Nagy wrote:
> The 08/12/2020 18:37, Ard Biesheuvel wrote:
> > On Wed, 12 Aug 2020 at 18:00, Jessica Yu wrote:
> > > +++ Szabolcs Nagy [12/08/20 15:15 +0100]:
> > > >for me it bisects to
> > > >
> > >
On Tue, Aug 04, 2020 at 07:44:42PM +0530, Gaurav Kohli wrote:
> In a system where no cpu's implement SSBS, for
> them no need to set pstate. This might help to save
> few cpu cycles during context switch.
>
> Signed-off-by: Gaurav Kohli
>
> diff --git a/arch/arm64/kernel/process.c
On Wed, Aug 12, 2020 at 12:40:05PM +0200, pet...@infradead.org wrote:
> On Wed, Aug 12, 2020 at 10:56:56AM +0200, Ard Biesheuvel wrote:
> > The module .lds has BYTE(0) in the section contents to prevent the
> > linker from pruning them entirely. The (NOLOAD) is there to ensure
> > that this byte
On Tue, Aug 11, 2020 at 06:01:35PM +0200, Jessica Yu wrote:
> +++ Mauro Carvalho Chehab [11/08/20 17:27 +0200]:
> > Em Tue, 11 Aug 2020 16:55:24 +0200
> > pet...@infradead.org escreveu:
> >
> > > On Tue, Aug 11, 2020 at 04:34:27PM +0200, Mauro Carvalho Chehab wrote:
> > > > [33] .plt
On Tue, Aug 11, 2020 at 12:17:13PM +0100, Will Deacon wrote:
> On Tue, Aug 11, 2020 at 12:38:41PM +0200, pet...@infradead.org wrote:
> > diff --git a/drivers/tty/serial/amba-pl011.c
> > b/drivers/tty/serial/amba-pl011.c
> > index 8efd7c2a34fe..1717790ece2b 100644
> > --
On Tue, Aug 11, 2020 at 12:38:41PM +0200, pet...@infradead.org wrote:
> On Tue, Aug 11, 2020 at 11:13:13AM +0100, Will Deacon wrote:
> > Using magic-sysrq via a keyboard interrupt over the serial console results
> > in
> > the following lockdep splat with the PL011 UART
Signed-off-by: Will Deacon
---
arch/arm64/kvm/mmu.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 5f6b35c33618..bd47f06739d6 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -365,7 +365,8 @@ s
() and therefore the backend cannot sensibly decide
whether or not to block.
Add an extra 'flags' parameter to kvm_unmap_hva_range() so that
architectures are aware as to whether or not they are permitted to block.
Cc:
Cc: Marc Zyngier
Cc: Suzuki K Poulose
Cc: James Morse
Signed-off-by: Will Deacon
: Marc Zyngier
Cc: Suzuki K Poulose
Cc: James Morse
Cc: Thomas Bogendoerfer
Cc: Paul Mackerras
Cc: Paolo Bonzini
Cc: Sean Christopherson
--->8
Will Deacon (2):
KVM: Pass MMU notifier range flags to kvm_unmap_hva_range()
KVM: arm64: Only reschedule if MMU_NOTIFIER_RANGE_BLOCKABLE is not
Hi,
Using magic-sysrq via a keyboard interrupt over the serial console results in
the following lockdep splat with the PL011 UART driver on v5.8. I can reproduce
the issue under QEMU with arm64 defconfig + PROVE_LOCKING.
Any chance somebody could take a look, please? It's a little annoying,
On Wed, Aug 05, 2020 at 11:22:36AM -0400, Mathieu Desnoyers wrote:
> - On Aug 5, 2020, at 6:59 AM, Peter Zijlstra pet...@infradead.org wrote:
> > On Tue, Aug 04, 2020 at 07:01:53PM +0200, pet...@infradead.org wrote:
> >> On Tue, Aug 04, 2020 at 10:59:33AM -0400, Mathieu Desnoyers wrote:
> >> >
On Tue, Aug 04, 2020 at 07:03:06PM -0700, Palmer Dabbelt wrote:
> > On Tue, Aug 4, 2020 at 8:32 AM Greentime Hu wrote:
> > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > > index f4adb3684f3d..29b0f7108054 100644
> > > --- a/arch/riscv/mm/init.c
> > > +++ b/arch/riscv/mm/init.c
> >
Hi Linus,
Please pull these arm64 fixes for -rc8/final. The main one is to fix the
build after Willy's per-cpu entropy changes this week. Although that was
already resolved elsewhere, the arm64 fix here is useful cleanup anyway.
Other than that, we've got a fix for building with Clang's
On Thu, Jul 30, 2020 at 10:25:41PM -0700, Linus Torvalds wrote:
> On Thu, Jul 30, 2020 at 7:16 PM Willy Tarreau wrote:
> >
> > Don't you want to take Mark's patch anyway in addition to all this ? In
> > case anyone meets yet another build issue, they'd have more luck trying
> > to revert any
On Wed, 17 Jun 2020 19:17:28 +0800, John Garry wrote:
> Ensure that the ARM PMU PROFILING AND DEBUGGING maintainers are included
> for the HiSilicon PMU driver.
Applied to arm64 (for-next/fixes), thanks!
[1/1] MAINTAINERS: Include drivers subdirs for ARM PMU PROFILING AND DEBUGGING
entry
On Thu, 30 Jul 2020 08:37:01 -0700, Sami Tolvanen wrote:
> Commit f7b93d42945c ("arm64/alternatives: use subsections for replacement
> sequences") breaks LLVM's integrated assembler, because due to its
> one-pass design, it cannot compute instruction sequence lengths before the
> layout for the
On Thu, Jul 30, 2020 at 09:03:02AM +0100, John Garry wrote:
> On 17/06/2020 12:17, John Garry wrote:
> > Ensure that the ARM PMU PROFILING AND DEBUGGING maintainers are included
> > for the HiSilicon PMU driver.
>
> Just a reminder in case this minor patch was missed...
Sorry, yes, somehow this
On Thu, Jul 30, 2020 at 11:09:23AM +0100, Catalin Marinas wrote:
> On Thu, Jul 30, 2020 at 10:59:09AM +0100, Marc Zyngier wrote:
> > From 33d819f4efa0a4474b5dc2e4bcaef1b886ca30c3 Mon Sep 17 00:00:00 2001
> > From: Marc Zyngier
> > Date: Thu, 30 Jul 2020 10:53:05 +0100
> > Subject: [PATCH] arm64:
ory
Will Deacon (1):
iommu/arm-smmu: Move Arm SMMU drivers into their own subdirectory
MAINTAINERS| 4 ++--
drivers/iommu/Makefile | 5 +
drivers/iommu/arm/Makef
On Mon, Jul 27, 2020 at 03:45:37AM +, Jianyong Wu wrote:
> > From: Will Deacon
> >
> > We can advertise ourselves to guests as KVM and provide a basic features
> > bitmap for discoverability of future hypervisor services.
> >
> > Cc: Marc Zyngier
> &
Hi Linus,
Please pull this tiny arm64 fix for -rc7, which tells recent versions of
clang where to find the assembler for building the compat vDSO.
Cheers,
Will
--->8
The following changes since commit f32ed8eb0e3f0d0ef4ddb854554d60ca5863a9f9:
drivers/perf: Prevent forced unbinding of PMU
Hi Joerg,
On Wed, Jul 22, 2020 at 03:33:23PM +0200, Joerg Roedel wrote:
> On Tue, Jul 21, 2020 at 09:03:53AM +0100, Will Deacon wrote:
> > Please pull these Arm SMMU driver updates for 5.9. Summary is in the tag,
> > but the main thing is support for two new SoC integration
On Thu, Jul 23, 2020 at 08:47:59PM +0200, pet...@infradead.org wrote:
> On Thu, Jul 23, 2020 at 02:32:36PM -0400, Waiman Long wrote:
> > BTW, do you have any comment on my v2 lock holder cpu info qspinlock patch?
> > I will have to update the patch to fix the reported 0-day test problem, but
> > I
On Wed, 22 Jul 2020 21:15:10 -0700, Nathan Chancellor wrote:
> Newer versions of clang only look for $(COMPAT_GCC_TOOLCHAIN_DIR)as [1],
> rather than $(COMPAT_GCC_TOOLCHAIN_DIR)$(CROSS_COMPILE_COMPAT)as,
> resulting in the following build error:
>
> $ make -skj"$(nproc)" ARCH=arm64
phy (1):
iommu/arm-smmu: Update impl quirks comment
Tomasz Nowicki (2):
iommu/arm-smmu: Call configuration impl hook before consuming features
dt-bindings: arm-smmu: add compatible string for Marvell Armada-AP806
SMMU-500
Will Deacon (1):
iommu: Remove unu
On Mon, Jul 13, 2020 at 08:23:22PM +0800, boqun.f...@gmail.com wrote:
> On Fri, Jul 10, 2020 at 05:51:46PM +0100, Will Deacon wrote:
> > diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h
> > new file mode 100644
> > index ..92cc2f223
On Sat, 18 Jul 2020 12:34:52 -0700, Krishna Reddy wrote:
> Changes in v11:
> Addressed Rob comment on DT binding patch to set min/maxItems of reg property
> in else part.
> Rebased on top of
> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=for-joerg/arm-smmu/updates.
>
>
On Thu, 16 Jul 2020 13:11:23 +0800, Leo Yan wrote:
> This patch set is rebased for Peter's patch set to support
> cap_user_time/cap_user_time_short ABI for Arm64, and export Arm arch
> timer counter related parameters from kernel to Perf tool.
>
> After get feedback from Ahmed, this patch set
On Mon, Jul 20, 2020 at 11:23:13AM +0200, Thomas Gleixner wrote:
> Andy Lutomirski writes:
> > On Thu, Jul 16, 2020 at 12:31 PM Gabriel Krisman Bertazi
> > wrote:
> > The amount of syscall entry wiring that arches need to do is IMO
> > already a bit out of hand. Should we instead rename
On Thu, Jul 16, 2020 at 05:16:19PM -0700, Bjorn Andersson wrote:
> With many Qualcomm platforms not having functional S2CR BYPASS a
> temporary IOMMU domain, without translation, needs to be allocated in
> order to allow these memory transactions.
>
> Unfortunately the boot loader uses the first
On Thu, Jul 16, 2020 at 05:16:16PM -0700, Bjorn Andersson wrote:
> Some firmware found on various Qualcomm platforms traps writes to S2CR
> of type BYPASS and writes FAULT into the register. This prevents us from
> marking the streams for the display controller as BYPASS to allow
> continued
erf sampling
drivers/perf: Prevent forced unbinding of PMU drivers
Will Deacon (9):
efi/libstub/arm64: Retain 2MB kernel Image alignment if !KASLR
arm64: ptrace: Consistently use pseudo-singlestep exceptions
arm64: ptrace: Override SPSR.SS when single-stepping is enabled
ar
On Fri, 17 Jul 2020 16:49:23 +0800, Qi Liu wrote:
> Forcefully unbinding PMU drivers during perf sampling will lead to
> a kernel panic, because the perf upper-layer framework call a NULL
> pointer in this situation.
>
> To solve this issue, "suppress_bind_attrs" should be set to true, so
> that
On Thu, 16 Jul 2020 12:28:16 +0100, Will Deacon wrote:
> Although mmiowb() is concerned only with serialising MMIO writes occuring
> in contexts where a spinlock is held, the call to mmiowb_set_pending()
> from the MMIO write accessors can occur in preemptible contexts, such
> as d
On Fri, Jul 17, 2020 at 08:56:23AM +0800, Guo Ren wrote:
> BTW, Jim found a GCC security leak in arm64, and would you want to
> have a look at it?
Thanks. This seems to be tracked in their bugzilla here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191
I agree with Jim that this should be
x the test result get back to normal.
>
> Fixes: 89b15332af7c ("mm: drop mmap_sem before calling balance_dirty_pages()
> in write fault")
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Johannes Weiner
> Reported-by: Xu Yu
> Debugged-by: Xu Yu
> Tested
On Mon, Jul 13, 2020 at 02:50:20PM +0100, Will Deacon wrote:
> On Tue, Jul 07, 2020 at 10:00:12PM -0700, Krishna Reddy wrote:
> > Changes in v10:
> > Perform SMMU base ioremap before calling implementation init.
> > Check for Global faults across both ARM MMU-500s du
On Fri, Jul 17, 2020 at 10:32:53AM +0530, Anshuman Khandual wrote:
>
>
> On 07/16/2020 11:55 PM, Mike Kravetz wrote:
> >>From 17c8f37afbf42fe7412e6eebb3619c6e0b7e1c3c Mon Sep 17 00:00:00 2001
> > From: Mike Kravetz
> > Date: Tue, 14 Jul 2020 15:54:46 -0700
> > Subject: [PATCH] hugetlb: move cma
On Thu, Jul 16, 2020 at 01:00:43PM +0100, Will Deacon wrote:
> On Wed, 15 Jul 2020 09:06:45 +0200, Tomasz Nowicki wrote:
> > The series is meant to support SMMU for AP806 and a workaround
> > for accessing ARM SMMU 64bit registers is the gist of it.
> >
> > For the
On Thu, 16 Jul 2020 17:19:25 +0800, Qi Liu wrote:
> When users try to remove PMU modules during perf sampling, kernel panic
> will happen because the pmu->read() is a NULL pointer here.
>
> INFO on HiSilicon hip08 platform as follow:
> pc : hisi_uncore_pmu_event_update+0x30/0xa4 [hisi_uncore_pmu]
On Wed, 15 Jul 2020 09:06:45 +0200, Tomasz Nowicki wrote:
> The series is meant to support SMMU for AP806 and a workaround
> for accessing ARM SMMU 64bit registers is the gist of it.
>
> For the record, AP-806 can't access SMMU registers with 64bit width.
> This patches split the readq/writeq
On Thu, Jul 16, 2020 at 12:22:05PM +0100, Robin Murphy wrote:
> On 2020-07-16 11:56, John Garry wrote:
> > On 16/07/2020 11:28, Will Deacon wrote:
> > > On Thu, Jul 16, 2020 at 11:22:33AM +0100, Will Deacon wrote:
> > > > On Thu, Jul 16, 2020 at 11:19
: Paul Walmsley
Cc: Guo Ren
Cc: Michael Ellerman
Reported-by: Palmer Dabbelt
Signed-off-by: Will Deacon
---
I can queue this in the arm64 tree as a fix, as I already have some other
fixes targetting -rc6.
include/asm-generic/mmiowb.h | 6 --
1 file changed, 4 insertions(+), 2 deletions
On Thu, Jul 16, 2020 at 11:36:10AM +0100, John Garry wrote:
> On 16/07/2020 11:30, Will Deacon wrote:
> > On Thu, Jul 16, 2020 at 11:26:25AM +0100, Robin Murphy wrote:
> > > On 2020-07-16 10:41, Will Deacon wrote:
> > > > On Thu, Jul 16, 2020 at 05:19:25PM +0800,
On Thu, Jul 16, 2020 at 11:26:25AM +0100, Robin Murphy wrote:
> On 2020-07-16 10:41, Will Deacon wrote:
> > On Thu, Jul 16, 2020 at 05:19:25PM +0800, Qi Liu wrote:
> > > Kernel panic will also happen when users try to unbind PMU drivers with
> > > device. This u
On Thu, Jul 16, 2020 at 11:22:33AM +0100, Will Deacon wrote:
> On Thu, Jul 16, 2020 at 11:19:41AM +0100, Will Deacon wrote:
> > On Tue, Jun 23, 2020 at 01:28:36AM +0800, John Garry wrote:
> > > As mentioned in [0], the CPU may consume many cycles processing
> > > arm_smm
On Thu, Jul 16, 2020 at 11:19:41AM +0100, Will Deacon wrote:
> On Tue, Jun 23, 2020 at 01:28:36AM +0800, John Garry wrote:
> > As mentioned in [0], the CPU may consume many cycles processing
> > arm_smmu_cmdq_issue_cmdlist(). One issue we find is the cmpxchg() loop to
> > g
On Tue, Jun 23, 2020 at 01:28:40AM +0800, John Garry wrote:
> It has been shown that the cmpxchg() for finding space in the cmdq can
> be a bottleneck:
> - for more CPUs contending the cmdq, the cmpxchg() will fail more often
> - since the software-maintained cons pointer is updated on the same
On Tue, Jun 23, 2020 at 01:28:36AM +0800, John Garry wrote:
> As mentioned in [0], the CPU may consume many cycles processing
> arm_smmu_cmdq_issue_cmdlist(). One issue we find is the cmpxchg() loop to
> get space on the queue takes approx 25% of the cycles for this function.
>
> This series
On Thu, Jul 16, 2020 at 05:19:25PM +0800, Qi Liu wrote:
> Kernel panic will also happen when users try to unbind PMU drivers with
> device. This unbind issue could be solved by another patch latter.
>
> drivers/perf/arm_smmuv3_pmu.c | 1 +
> drivers/perf/fsl_imx8_ddr_perf.c
On Mon, Jul 13, 2020 at 11:19:17AM -0600, Jordan Crouse wrote:
> On Mon, Jul 13, 2020 at 04:09:02PM +0100, Will Deacon wrote:
> > On Fri, Jun 26, 2020 at 02:00:38PM -0600, Jordan Crouse wrote:
> > > diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
> &
o be unlucky enough to not get list.h via some other
> header file.
>
> Reported-by: Petr Mladek
> Tested-by: Petr Mladek
> Signed-off-by: Herbert Xu
Acked-by: Will Deacon
Will
On Thu, Jul 16, 2020 at 06:00:12PM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> arch/arm64/mm/init.c
>
> between commit:
>
> abb7962adc80 ("arm64/hugetlb: Reserve CMA areas for gigantic pages on 16K
> and 64K configs")
>
> from
On Wed, Jul 15, 2020 at 09:59:24AM -0700, Mike Kravetz wrote:
> On 7/15/20 1:18 AM, Will Deacon wrote:
> >> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> >> index f24acb3af741..a0007d1d12d2 100644
> >> --- a/mm/hugetlb.c
> >> +++ b/mm/hugetlb.c
Hi John,
On Wed, Jul 15, 2020 at 09:23:19AM +0100, John Garry wrote:
> > On Wed, Jun 17, 2020 at 09:05:11PM +0800, John Garry wrote:
> > > To allow userspace to identify the specific implementation of the device,
> > > add an "identifier" sysfs file.
> > >
> > > Encoding is as follows:
> > >
Hi Mike,
On Tue, Jul 14, 2020 at 04:21:01PM -0700, Mike Kravetz wrote:
> I agree we should only be concerned with N_MEMORY nodes for the CMA
> reservations. However, this patch got me thinking:
> - Do we really have to initiate the CMA reservations from arch specific code?
> - Can we move the
Kees Cook
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm64/kernel/asm-offsets.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> index 0577e21..37d5d3d 100644
> --- a
Hi John,
On Wed, Jun 17, 2020 at 09:05:11PM +0800, John Garry wrote:
> To allow userspace to identify the specific implementation of the device,
> add an "identifier" sysfs file.
>
> Encoding is as follows:
> hi1620: 0x0 (aka hip08)
> hi1630: 0x30
>
> Signed-off-by: John Garry
I'm
as a bit nervous about us passing GFP_KERNEL with a spinlock held, but
it looks like you've checked all the callsites and it looks fine to me, so:
Acked-by: Will Deacon
Joerg -- not sure what you want to do with this one, as it's likely to
conflict (trivially) with unrelated driver changes.
Will
tions(+), 5 deletions(-)
Acked-by: Will Deacon
(I'm assuming Joerg will pick this up for 5.9)
Thanks,
Will
Hi Tomasz,
On Thu, Jul 02, 2020 at 10:16:29PM +0200, Tomasz Nowicki wrote:
> There were already two versions of series to support SMMU for AP806,
> including workaround for accessing ARM SMMU 64bit registers.
> First [1] by Hanna Hawa and second [2] by Gregory CLEMENT.
> Since it got stuck this
On Mon, Jul 13, 2020 at 01:48:29PM -0700, John Stultz wrote:
> On Mon, Jul 13, 2020 at 1:41 PM Will Deacon wrote:
> > On Fri, Jul 10, 2020 at 03:21:53PM -0700, John Stultz wrote:
> > > On Fri, Jul 10, 2020 at 12:54 AM Will Deacon wrote:
> > > > On Thu, Jul 09,
On Fri, Jul 10, 2020 at 03:21:53PM -0700, John Stultz wrote:
> On Fri, Jul 10, 2020 at 12:54 AM Will Deacon wrote:
> > On Thu, Jul 09, 2020 at 08:28:45PM -0700, John Stultz wrote:
> > > On Thu, Jul 2, 2020 at 7:18 AM Will Deacon wrote:
> > > > On Thu, Jun 25,
On Mon, Jul 13, 2020 at 11:00:32AM -0600, Jordan Crouse wrote:
> On Mon, Jul 13, 2020 at 04:11:23PM +0100, Will Deacon wrote:
> > On Thu, Jun 11, 2020 at 04:36:56PM -0600, Jordan Crouse wrote:
> > > Add a new implementation hook to allow the implementation specific code
> >
On Thu, Jun 11, 2020 at 04:36:56PM -0600, Jordan Crouse wrote:
> Add a new implementation hook to allow the implementation specific code
> to tweek the context bank configuration just before it gets written.
> The first user will be the Adreno GPU implementation to turn on
> SCTLR.HUPCF to ensure
On Fri, Jun 26, 2020 at 02:00:38PM -0600, Jordan Crouse wrote:
> Add a link to the pointer to the struct device that is attached to a
> domain. This makes it easy to get the pointer if it is needed in the
> implementation specific code.
>
> Signed-off-by: Jordan Crouse
> ---
>
>
On Tue, Jul 07, 2020 at 10:00:12PM -0700, Krishna Reddy wrote:
> Changes in v10:
> Perform SMMU base ioremap before calling implementation init.
> Check for Global faults across both ARM MMU-500s during global interrupt.
> Check for context faults across all contexts of both ARM MMU-500s during
>
On Tue, Jul 07, 2020 at 10:00:17PM -0700, Krishna Reddy wrote:
> Add global/context fault hooks to allow vendor specific implementations
> override default fault interrupt handlers.
>
> Update NVIDIA implementation to override the default global/context fault
> interrupt handlers and handle
On Mon, Jun 08, 2020 at 04:13:08PM +0100, Will Deacon wrote:
> On Thu, Jun 04, 2020 at 02:39:04PM -0600, Jordan Crouse wrote:
> > When CONFIG_OF=n of_match_device() gets pre-processed out of existence
> > leaving qcom-smmu_client_of_match unused. Mark it as possibly unused to
> &
On Sun, Jul 12, 2020 at 04:20:58AM -0700, Liu Yi L wrote:
> This patch is added as instead of returning a boolean for DOMAIN_ATTR_NESTING,
> iommu_domain_get_attr() should return an iommu_nesting_info handle.
>
> Cc: Will Deacon
> Cc: Robin Murphy
> Cc: Eric Auger
> Cc:
Hi Leo,
On Mon, Jul 13, 2020 at 02:08:00PM +0800, Leo Yan wrote:
> On Tue, May 12, 2020 at 02:40:58PM +0200, Peter Zijlstra wrote:
> > Prompted by Leo's patches, here a series that corrects the arm64 perf
> > cap_user_time situation.
>
> I checked the latest mainline kernel code base, found
On Fri, Jul 10, 2020 at 10:06:12AM -0700, Nick Desaulniers wrote:
> On Fri, Jul 10, 2020 at 9:52 AM Will Deacon wrote:
> > diff --git a/include/linux/nospec.h b/include/linux/nospec.h
> > index 0c5ef54fd416..c1e79f72cd89 100644
> > --- a/include/linux/nospec.h
> > +
In preparation for removing smp_read_barrier_depends() altogether,
move the Alpha code over to using smp_rmb() and smp_mb() directly.
Acked-by: Paul E. McKenney
Signed-off-by: Will Deacon
---
arch/alpha/include/asm/atomic.h | 16
arch/alpha/include/asm/pgtable.h | 10
The [smp_]read_barrier_depends() macros no longer exist, so we don't
need to deal with them in the checkpatch script.
Acked-by: Paul E. McKenney
Signed-off-by: Will Deacon
---
scripts/checkpatch.pl | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/scripts
Alpha overrides __READ_ONCE() directly, so there's no need to use
smp_read_barrier_depends() in the core code. This also means that
__READ_ONCE() can be relied upon to provide dependency ordering.
Acked-by: Paul E. McKenney
Signed-off-by: Will Deacon
---
include/asm-generic/rwonce.h | 19
to
| indirect->addr after avail idx is increased
Remove the redundant barrier invocation.
Suggested-by: Jason Wang
Acked-by: Paul E. McKenney
Signed-off-by: Will Deacon
---
drivers/vhost/vhost.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/v
smp_read_barrier_depends() doesn't exist any more, so reword the two
comments that mention it to refer to "dependency ordering" instead.
Acked-by: Paul E. McKenney
Signed-off-by: Will Deacon
---
include/linux/percpu-refcount.h | 2 +-
include/linux/ptr_ring.h| 2 +-
2 files
-ld:./arch/arm64/kernel/vmlinux.lds:1: syntax error
In preparation for an arm64-private asm/rwonce.h implementation, which
will end up pulling assembly macros into linux/compiler.h, reduce the
number of headers we include directly and transitively in vmlinux.lds.S
Signed-off-by: Will Deacon
smp_read_barrier_depends() has gone the way of mmiowb() and so many
esoteric memory barriers before it. Drop the two mentions of this
deceased barrier from the LKMM informal explanation document.
Acked-by: Alan Stern
Acked-by: Paul E. McKenney
Signed-off-by: Will Deacon
---
.../Documentation
READ_ONCE() definition with one that provides acquire semantics when
building with LTO.
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/rwonce.h | 63 +++
arch/arm64/kernel/vdso/Makefile | 2 +-
arch/arm64/kernel/vdso32/Makefile | 2 +-
3 files changed, 65
From: SeongJae Park
This commit translates commit ("Documentation/barriers: Remove references to
[smp_]read_barrier_depends()") into Korean.
Signed-off-by: SeongJae Park
Reviewed-by: Yunjae Lee
Signed-off-by: Will Deacon
---
.../translations/ko_KR/memory-barriers.tx
1001 - 1100 of 10389 matches
Mail list logo
