FX erratum
010001")
Signed-off-by: Zhang Lei
[Mark: use MIDR_CPU_VAR_REV(), reword commit message]
Signed-off-by: Mark Rutland
---
arch/arm64/include/asm/cputype.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/incl
ts.infradead.org
> > Cc: linux-kernel@vger.kernel.org; Catalin Marinas
> > ; Mark Rutland ; Will
> > Deacon ; Zhang, Lei
> > Subject: [PATCH v5] arm64: Add workaround for Fujitsu A64FX erratum
> > 010001
> >
> > +/* Fujitsu Erratum 010001 affects A64FX
On Wed, Mar 13, 2019 at 03:57:42PM +0100, Arnd Bergmann wrote:
> On Wed, Mar 13, 2019 at 3:36 PM Mark Rutland wrote:
> > On Wed, Mar 13, 2019 at 10:18:44AM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 11, 2019 at 03:20:04PM +0100, Arnd Bergmann wrote:
> > > > O
A bit of history here,
> > >
> > > https://patchwork.kernel.org/patch/7344011/#15495901
> >
> > Ah, I had already forgotten about that discussion.
> >
> > At least the atomic_long part we discussed there has been resolved now
> > as part of commit b5d47
Hi Torsten,
On Mon, Mar 11, 2019 at 12:49:46PM +0100, Torsten Duwe wrote:
> On Wed, Feb 13, 2019 at 11:11:04AM +, Julien Thierry wrote:
> > Hi Torsten,
> >
> > On 08/02/2019 15:08, Torsten Duwe wrote:
> > > Patch series v8, as discussed.
> > > The whole series applies cleanly on 5.0-rc5
>
>
Hi,
On Sat, Mar 09, 2019 at 06:19:06PM -0700, Yu Zhao wrote:
> Switch from per mm_struct to per pmd page table lock by enabling
> ARCH_ENABLE_SPLIT_PMD_PTLOCK. This provides better granularity for
> large system.
>
> I'm not sure if there is contention on mm->page_table_lock. Given
> the option
Hi Alex,
On Thu, Feb 28, 2019 at 04:01:09PM +0200, Alexander Shishkin wrote:
> First, we have a race between perf_event_release_kernel() and
> perf_free_event(), which happens when parent's event is released while the
> child's fork fails (because of a fatal signal, for example), that looks
>
On Tue, Mar 05, 2019 at 05:31:12PM +, Russell King - ARM Linux admin wrote:
> Guys,
Hi Russell,
> We need to be smarter when writing Kconfig help. I'm just going
> through updating my build trees with the results of 5.0 development,
> and a number of the help texts are next to useless. For
some cases it's interesting for the user/developer to know if the OSI
> mode is supported by the PSCI FW. Therefore, let's print a message to the
> log, if that is the case.
>
> Cc: Lina Iyer
> Co-developed-by: Lina Iyer
> Reviewed-by: Daniel Lezcano
> Signed-off-by: Ulf Han
On Thu, Feb 28, 2019 at 02:59:16PM +0100, Ulf Hansson wrote:
> To allow arch back-end init ops to operate on the cpuidle driver for the
> corresponding CPU, let's pass along a pointer to the struct cpuidle_driver*
> and forward it the relevant layers of callbacks for ARM/ARM64.
>
> Following
On Thu, Feb 28, 2019 at 02:59:17PM +0100, Ulf Hansson wrote:
> Instead of iterating through all the state nodes in DT, to find out how
> many states that needs to be allocated, let's use the number already known
> by the cpuidle driver. In this way we can drop the iteration altogether.
>
>
On Thu, Feb 28, 2019 at 02:59:15PM +0100, Ulf Hansson wrote:
> Let's split the psci_dt_cpu_init_idle() function into two functions. This
> makes the code clearer and provides better re-usability.
>
> Cc: Lina Iyer
> Co-developed-by: Lina Iyer
> Signed-off-by: Ulf Hansso
gested-by: Mark Rutland
> Signed-off-by: Ulf Hansson
Acked-by: Mark Rutland
Mark.
> ---
> drivers/firmware/Kconfig | 15 +--
> drivers/firmware/Makefile | 3 +--
> drivers/firmware/psci/Kconfig | 13 +
>
On Thu, Feb 28, 2019 at 02:59:14PM +0100, Ulf Hansson wrote:
> The files for the PSCI firmware driver were moved to a sub-directory, let's
> update MAINTAINERS to reflect that.
>
> Suggested-by: Mark Rutland
> Signed-off-by: Ulf Hansson
Acked-by: Mark Rutland
Mark.
> ---
On Mon, Feb 25, 2019 at 01:01:08PM +0100, Dmitry Vyukov wrote:
> On Mon, Feb 25, 2019 at 12:35 PM Mark Rutland wrote:
> >
> > On Sat, Feb 23, 2019 at 11:29:45AM +0100, Dmitry Vyukov wrote:
> > > On Fri, Feb 22, 2019 at 7:29 PM Mark Rutland wrote:
> > > >
&
in case we call pte_free_kernel()
> on init_mm.
>
> Signed-off-by: Yu Zhao
Assuming that was all, this patch makes sense to me. FWIW:
Acked-by: Mark Rutland
Thanks,
Mark.
> ---
> arch/arm64/mm/mmu.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
builds, so that callers don't have to be aware of folding.
I couldn't think of a nicer way of distinguishing levels of table, and
having separate function pointers for each level seems over-the-top, so
otehr than that this looks good to me.
Assuming you're happy with the above change:
Acked-by: Mark Rutland
Thanks,
Mark.
On Sat, Feb 23, 2019 at 11:29:45AM +0100, Dmitry Vyukov wrote:
> On Fri, Feb 22, 2019 at 7:29 PM Mark Rutland wrote:
> >
> > When CONFIG_KASAN is selected, defines the
> > prototypes for kasan_check_{read,write}(), rather than inline stubs.
>
> +kasan-...@googlegrou
by this
change.
Signed-off-by: Mark Rutland
Cc: Alexander Potapenko
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: Ingo Molnar
---
include/linux/kasan-checks.h | 8 +---
mm/kasan/common.c| 8
scripts/Makefile.kasan | 2 +-
3 files changed, 10 insertions(+), 8 deletions
On Fri, Feb 22, 2019 at 07:17:00PM +0530, Pintu Agarwal wrote:
> Hi All,
Hi,
> I want to build Linux Kernel 4.20 for arm64 and use it on qemu-arm64.
> I see that there is a defconfig available in arch/arm64/configs/defconfig
> But I am not sure whether it will work for qemu-arm64, and by default
W:
Reviewed-by: Mark Rutland
Mark.
> ---
> arch/arm64/include/asm/kvm_arm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/kvm_arm.h
> b/arch/arm64/include/asm/kvm_arm.h
> index 6f602af5263c..d945a787f36e 100644
> --- a/arch
On Fri, Feb 22, 2019 at 04:23:23PM +0800, Leo Yan wrote:
> Use macro for ID_AA64MMFR1_EL1.VH bits shift instead of 8 directly.
>
> Signed-off-by: Leo Yan
It's always nice to get rid of magic numbers, and this is correct
AFAICT. FWIW:
Reviewed-by: Mark Rutland
Mark.
> ---
&
to detect such entries, but s390,
sparc, and x86 have all aligned on p?d_large(). Let's implement the same
for arm64 atop of p?d_cont().
With that:
Acked-by: Mark Rutland
Thanks,
Mark.
>
> Signed-off-by: James Morse
> Signed-off-by: Steven Price
> ---
> arch/arm64/include/asm/
the fact that they are always available
> (if
> + * the architecture supports large pages at the appropriate level) even
> + * if CONFIG_HUGETLB_PAGE is not defined.
I'm not sure if we need this part, since we don't mention
p?d_trans_huge(), etc, but either way:
Acked-by: Mark Rutland
Th
eter instead of creating a new API.
>
> A new register is not created to pass this parameter via
> SET/GET_ONE_REG interface as just a flag (KVM_ARM_VCPU_PTRAUTH)
> supplied is enough to enable this feature.
>
> Signed-off-by: Amit Daniel Kachhap
> Cc: Mark Rutland
> Cc:
On Tue, Feb 19, 2019 at 02:54:28PM +0530, Amit Daniel Kachhap wrote:
> From: Mark Rutland
>
> When pointer authentication is supported, a guest may wish to use it.
> This patch adds the necessary KVM infrastructure for this to work, with
> a semi-lazy context switch of the poi
tored in struct kvm_cpu_context as
> both host and guest can now use this field in a common way.
>
> Signed-off-by: Amit Daniel Kachhap
> Cc: Marc Zyngier
> Cc: Mark Rutland
> Cc: Christoffer Dall
> Cc: kvm...@lists.cs.columbia.edu
> ---
> arch/arm/include/asm/kvm
Hi,
On Tue, Feb 19, 2019 at 02:54:26PM +0530, Amit Daniel Kachhap wrote:
> From: Mark Rutland
>
> When restoring HCR_EL2 for the host, KVM uses HCR_HOST_VHE_FLAGS, which
> is a constant value. This works today, as the host HCR_EL2 value is
> always the same, but this will
On Mon, Feb 18, 2019 at 03:30:38PM +, Steven Price wrote:
> On 18/02/2019 15:06, Peter Zijlstra wrote:
> > On Mon, Feb 18, 2019 at 02:29:52PM +0000, Mark Rutland wrote:
> >> I think that Peter means p?d_huge(x) should imply p?d_large(x), e.g.
> >>
> >> #def
On Mon, Feb 18, 2019 at 12:29:22PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 15, 2019 at 05:02:22PM +, Steven Price wrote:
>
> > diff --git a/arch/arm64/include/asm/pgtable.h
> > b/arch/arm64/include/asm/pgtable.h
> > index de70c1eabf33..09d308921625 100644
> > ---
On Mon, Feb 18, 2019 at 02:11:40PM +, Steven Price wrote:
> On 18/02/2019 11:29, Peter Zijlstra wrote:
> > On Fri, Feb 15, 2019 at 05:02:22PM +, Steven Price wrote:
> >
> >> diff --git a/arch/arm64/include/asm/pgtable.h
> >> b/arch/arm64/include/asm/pgtable.h
> >> index
On Fri, Feb 15, 2019 at 05:02:27PM +, Steven Price wrote:
> The pte_hole() callback is called at multiple levels of the page tables.
> Code dumping the kernel page tables needs to know what at what depth
> the missing entry is. Add this is an extra parameter to pte_hole().
> When the depth
On Fri, Feb 15, 2019 at 05:02:22PM +, Steven Price wrote:
> From: James Morse
>
> Exposing the pud/pgd levels of the page tables to walk_page_range() means
> we may come across the exotic large mappings that come with large areas
> of contiguous memory (such as the kernel's linear map).
>
>
On Fri, Feb 15, 2019 at 05:02:24PM +, Steven Price wrote:
> From: James Morse
>
> Exposing the pud/pgd levels of the page tables to walk_page_range() means
> we may come across the exotic large mappings that come with large areas
> of contiguous memory (such as the kernel's linear map).
>
>
Hi,
On Wed, Feb 13, 2019 at 05:01:31PM -0700, Khalid Aziz wrote:
> From: Tycho Andersen
>
> XPFO doesn't support section/contiguous mappings yet, so let's disable it
> if XPFO is turned on.
>
> Thanks to Laura Abbot for the simplification from v5, and Mark Rutland for
>
On Thu, Feb 14, 2019 at 07:26:24AM +, Zhang, Lei wrote:
> Hi guys,
>
> Thanks for your comments.
> I am sending the revised patch, version 4, which includes a whole
> description of the patch.
>
> This patch adds a workaround for Fujitsu A64FX erratum 010001
>
> There are some discussions
On Wed, Feb 13, 2019 at 09:37:38AM +, Peng Fan wrote:
> The barriers are added for empty_zero_page, however the
> empty zero page has been moved to bss area by
> commit 5227cfa71f9e ("arm64: mm: place empty_zero_page in bss"),
> and it alreay added "dsb ishst" in head.S to make sure
> the
On Wed, Feb 13, 2019 at 09:37:29AM +, Peng Fan wrote:
> The empty zero page has been moved to bss area by
> commit 5227cfa71f9e ("arm64: mm: place empty_zero_page in bss"),
> and it alreay added "dsb ishst" in head.S to make sure the empty
> zero page visible to PTW.
>
> There is no code
ock resizing.
> */
I think that it would be better to remove the comment entirely. This
doesn't explain the intent, or rationale, and all this information is
obvious from a straight-line reading of the code.
If you remove the comment instead:
Acked-by: Mark Rutland
Mark.
> void __init paging_init(void)
> {
> --
> 2.16.4
>
/20181210175035.45096-1-mark.rutl...@arm.com/T/#m39ee97e01a02b5d054cca4d028445bb3a9818e91
Anders Roxell (1):
locking/atomics: Change 'fold' to 'grep'
Mark Rutland (1):
locking/atomics: Check atomic headers with sha1sum
include/asm-generic/atomic-instrumented.h | 1 +
include/asm-generic/atomic-long.h
Kamboju
Suggested-by: Will Deacon
Signed-off-by: Anders Roxell
[Mark: rework commit message]
Signed-off-by: Mark Rutland
Acked-by: Will Deacon
---
scripts/atomic/atomic-tbl.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/atomic/atomic-tbl.sh b/scripts/atomic
in this case.
Presumably, most developers have a working coreutils installation.
Signed-off-by: Mark Rutland
Acked-by: Will Deacon
Cc: Andrew Morton
Cc: Boqun Feng
Cc: Ingo Molnar
Cc: Peter Zijlstra
---
include/asm-generic/atomic-instrumented.h | 1 +
include/asm-generic/atomic-long.h | 1
rm32 as well.
>
> There should be no functional change as a result of this patch.
>
> Signed-off-by: Torsten Duwe
With the indentation removed from the commit text:
Reviewed-by: Mark Rutland
Mark.
>
> ---
> drivers/firmware/efi/libstub/Makefile |6 +++---
>
e no functional change as a result of this patch.
>
> Signed-off-by: Torsten Duwe
With the indentation removed from the commit text:
Reviewed-by: Mark Rutland
Mark.
>
> ---
> mm/kasan/Makefile |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> --- a/mm/kasa
e no functional change as a result of this patch.
>
> Signed-off-by: Torsten Duwe
With the indentation removed from the commit text:
Reviewed-by: Mark Rutland
Mark.
>
> ---
> mm/kasan/Makefile |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> --- a/mm/kasa
There should be no functional change as a result of this patch.
>
> Signed-off-by: Torsten Duwe
Thanks for splitting this out.
With the indentation removed from the commit text:
Reviewed-by: Mark Rutland
Thanks,
Mark.
>
> ---
> arch/arm64/kernel/Makefile |6 +++---
>
ith - I suspect the
> hisi/qcom/xgene ones suffer from similar issues, but it's going to take
> me a while longer to figure them out in detail.
>
> Robin.
These all looks sound to me, so FWIW:
Acked-by: Mark Rutland
Mark.
Commit-ID: 9dff0aa95a324e262ffb03f425d00e4751f3294e
Gitweb: https://git.kernel.org/tip/9dff0aa95a324e262ffb03f425d00e4751f3294e
Author: Mark Rutland
AuthorDate: Thu, 10 Jan 2019 14:27:45 +
Committer: Ingo Molnar
CommitDate: Mon, 4 Feb 2019 08:45:25 +0100
perf/core: Don't WARN
On Fri, Feb 01, 2019 at 03:44:38PM +, Reshetova, Elena wrote:
> > On Tue, Jan 29, 2019 at 01:55:32PM +, Reshetova, Elena wrote:
> > > > On Mon, Jan 28, 2019 at 02:27:26PM +0200, Elena Reshetova wrote:
> > > > > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > > > > index
On Tue, Jan 29, 2019 at 01:55:32PM +, Reshetova, Elena wrote:
> > On Mon, Jan 28, 2019 at 02:27:26PM +0200, Elena Reshetova wrote:
> > > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > > index 3cd13a3..a1e87d2 100644
> > > --- a/kernel/events/core.c
> > > +++
On Thu, Jan 24, 2019 at 07:25:53PM +0200, Mike Rapoport wrote:
> On Thu, Jan 24, 2019 at 04:51:53PM +0000, Mark Rutland wrote:
> > On Thu, Jan 24, 2019 at 04:19:33PM +, Christophe Leroy wrote:
> > > Since only the virtual address of allocated blocks is used,
> > > l
On Thu, Jan 24, 2019 at 04:19:43PM +, Christophe Leroy wrote:
> This patch activates CONFIG_THREAD_INFO_IN_TASK which
> moves the thread_info into task_struct.
>
> Moving thread_info into task_struct has the following advantages:
> - It protects thread_info from corruption in the case of
CONFIG_THREAD_INFO_IN_TASK is not selected these perform no
> refcounting, and this should only be a structural change that does not
> affect behaviour.
>
> Signed-off-by: Christophe Leroy
I'm not familiar with the powerpc code, but AFAICT this is analagous to
the arm64 code, and I'm not awar
y_nid() will panic itself
rather than returning NULL.
Otherwise, this looks like a nice cleanup. With the panics removed (or
using the _nopanic() allocators), feel free to add:
Acked-by: Mark Rutland
Thanks,
Mark.
On Wed, Jan 23, 2019 at 09:05:26AM -0800, Scott Branden wrote:
> Hi Mark,
>
> Hopefully I can shed some light on the use case inline.
>
> On 2019-01-23 8:48 a.m., Mark Rutland wrote:
> > On Mon, Jan 21, 2019 at 11:30:02AM +0530, Pramod Kumar wrote:
> > > On Mon, J
On Fri, Jan 18, 2019 at 11:16:20AM +0530, Pramod Kumar wrote:
> If CPU hotplug is supported, ipi_cpu_stop should use PSCI cpudie
> call to stop the CPU. This call ensures L1/L2 cache flush,
> CPUs cache-cohenrecy setting w.r.to interconnect.
>
> Apart from this, this gives control to f/w to
On Mon, Jan 21, 2019 at 11:30:02AM +0530, Pramod Kumar wrote:
> On Mon, Jan 21, 2019 at 11:28 AM Pramod Kumar
> wrote:
>
> Need comes from a specific use case where one Accelerator card(SoC) is
> plugged in a sever over a PCIe interface. This Card gets supply from a
> battery, which
On Tue, Jan 22, 2019 at 02:05:26AM +, Zhang, Lei wrote:
> Hi, Mark
>
> Thanks for your comments, and sorry for late.
>
> > -Original Message-
> > * Under what conditions can the fault occur? e.g. is this in place of
> > some other fault, or completely spurious?
> This fault can
Hi Will,
On Tue, Jan 22, 2019 at 05:44:02AM +, Will Deacon wrote:
> On Mon, Jan 21, 2019 at 02:21:28PM +, Catalin Marinas wrote:
> > On Sat, Jan 19, 2019 at 11:58:27PM +, Will Deacon wrote:
> > > On Thu, Jan 17, 2019 at 07:42:44AM +, chenwandun wrote:
> > > > Recently, I do some
Hi Stefan,
On Mon, Jan 21, 2019 at 03:41:11PM +0100, Stefan Agner wrote:
> Currently, if only a single interrupt is available, the code assigns
> this single interrupt to the first CPU. All other CPUs are left
> unsupported. This allows to use perf events only on processes using
> the first CPU.
On Wed, Jan 16, 2019 at 12:27:09PM +0200, Elena Reshetova wrote:
> atomic_t variables are currently used to implement reference
> counters with the following properties:
> - counter is initialized to 1 using atomic_set()
> - a resource is freed upon counter reaching zero
> - once counter
Hi Torsten,
On Fri, Jan 18, 2019 at 05:39:04PM +0100, Torsten Duwe wrote:
> Ftrace instrumentation might also be introduced by
> -fpatchable-function-entry, not only -pg. Ensure the Makefiles are
> flexible to filter out the respective flags in "notrace" directories.
I think this is a cleanup
Hi,
On Fri, Jan 18, 2019 at 12:52:38PM +, Zhang, Lei wrote:
> On some variants of the Fujitsu-A64FX cores ver(1.0, 1.1),
> memory accesses may cause undefined fault (Data abort, DFSC=0b11).
So that we can better understand the problem, could you please let us
know the following:
*
not. That must
> be always false.
>
> Signed-off-by: Masami Hiramatsu
Reviewed-by: Mark Rutland
Mark.
> ---
> arch/arm64/kernel/probes/kprobes.c |6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/arch/arm64/kernel/probes/kprobes.c
> b/arch/arm64/ke
On Mon, Jan 14, 2019 at 11:13:59PM +1100, Balbir Singh wrote:
> On Fri, Jan 04, 2019 at 05:50:18PM +0000, Mark Rutland wrote:
> > Hi Torsten,
> >
> > On Fri, Jan 04, 2019 at 03:10:53PM +0100, Torsten Duwe wrote:
> > > Use -fpatchable-function-entry (gcc8)
On Sat, Jan 12, 2019 at 02:57:01PM +0800, Changbin Du wrote:
> This patch adds a new trace option 'funcgraph-retval' and is disabled by
> default. When this option is enabled, fgraph tracer will show the return
> value of each function. This is useful to find/analyze a original error
> source in a
]---
Let's avoid this by checking that the requested allocation is possible
before calling kzalloc.
Reported-by: Julien Thierry
Signed-off-by: Mark Rutland
Cc: Alexander Shishkin
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
---
kernel/events/ring_buffer.c | 3 +++
1 file
On Tue, Jan 08, 2019 at 11:24:43AM +0800, Miles Chen wrote:
> On Mon, 2019-01-07 at 15:00 +0000, Mark Rutland wrote:
> > On Mon, Jan 07, 2019 at 07:21:20PM +0800, Miles Chen wrote:
> > > Current __virt_to_phys() only print warning messages for non-linear
> > > addres
On Mon, Jan 07, 2019 at 05:55:31PM +, Mark Brown wrote:
> On Mon, Jan 07, 2019 at 02:43:57PM +0000, Mark Rutland wrote:
>
> > Is it possible to use an allyesconfig rather than an allmodconfig? That
> > would leave all relevant options built-in.
>
> The allyesc
On Mon, Jan 07, 2019 at 07:21:20PM +0800, Miles Chen wrote:
> Current __virt_to_phys() only print warning messages for non-linear
> addresses. It's hard to catch all warnings by those messages.
Why? Are you seeing a large number of warnings somewhere?
> So add a VIRTUAL_BUG_ON() to trap all
Hi,
As a general thing, please Cc LAKML on patches for arm64.
On Thu, Dec 13, 2018 at 01:29:10PM +0100, Anders Roxell wrote:
> With this new config option, we can boot a allmodconfig kernel in qemu.
> Config options SERIAL_AMBA_PL011, SERIAL_AMBA_PL011_CONSOLE, UNIX needs
> to be enabled in
On Thu, Dec 13, 2018 at 03:18:23PM +, Mark Brown wrote:
> On Thu, Dec 13, 2018 at 01:29:10PM +0100, Anders Roxell wrote:
>
> > With this new config option, we can boot a allmodconfig kernel in qemu.
> > Config options SERIAL_AMBA_PL011, SERIAL_AMBA_PL011_CONSOLE, UNIX needs
> > to be enabled
On Fri, Jan 04, 2019 at 11:41:45PM +0100, Torsten Duwe wrote:
> On Fri, Jan 04, 2019 at 01:06:48PM -0500, Steven Rostedt wrote:
> > On Fri, 4 Jan 2019 17:50:18 +
> > Mark Rutland wrote:
> >
> > > At Linux Plumbers, I had a conversation with Steve Rostedt, and w
On Fri, Jan 04, 2019 at 10:33:40AM +0100, Pavel Machek wrote:
> On Fri 2019-01-04 09:21:30, Marc Zyngier wrote:
> > On 03/01/2019 20:29, Pavel Machek wrote:
> > > On Fri 2018-12-07 18:39:25, Kristina Martsenko wrote:
> > >> From: Mark Rutland
> > >
Hi Torsten,
On Fri, Jan 04, 2019 at 03:10:53PM +0100, Torsten Duwe wrote:
> Use -fpatchable-function-entry (gcc8) to add 2 NOPs at the beginning
> of each function. Replace the first NOP thus generated with a quick LR
> saver (move it to scratch reg x9), so the 2nd replacement insn, the call
> to
On Mon, Dec 10, 2018 at 05:50:33PM +, Mark Rutland wrote:
> Hi Ingo,
>
> I hope that these atomic scripting patches address your concerns with
> the atomics scripting infrastructure. These are based on the tip
> locking/core branch, leaving the headers checked-in.
>
> Th
Hi Ingo,
On Thu, Dec 06, 2018 at 05:13:44PM +0100, Ingo Molnar wrote:
>
> * Mark Rutland wrote:
>
> > Andrew and Ingo report that the check-atomics.sh script is simply too
> > slow to run for every kernel build, and it's impractical to make it
> > faster without rewr
Hi Ingo,
On Thu, Dec 06, 2018 at 05:15:28PM +0100, Ingo Molnar wrote:
>
> * Will Deacon wrote:
>
> > [+ Ingo and Mark]
> >
> > On Tue, Dec 04, 2018 at 10:47:13PM +0100, Anders Roxell wrote:
> > > Some distibutions and build systems doesn't include 'fold' from
> > > coreutils default.
> > >
>
in this case.
Presumably, most developers have a working coreutils installation.
Signed-off-by: Mark Rutland
Cc: Andrew Morton
Cc: Boqun Feng
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Will Deacon
---
include/asm-generic/atomic-instrumented.h | 1 +
include/asm-generic/atomic-long.h | 1
Kamboju
Suggested-by: Will Deacon
Signed-off-by: Anders Roxell
[Mark: rework commit message]
Signed-off-by: Mark Rutland
---
scripts/atomic/atomic-tbl.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/atomic/atomic-tbl.sh b/scripts/atomic/atomic-tbl.sh
index
actually sending patches will have a working coreutils.
Are you happy to pick these up?
Thanks,
Mark.
Anders Roxell (1):
locking/atomics: Change 'fold' to 'grep'
Mark Rutland (1):
locking/atomics: Check atomic headers with sha1sum
include/asm-generic/atomic-instrumented.h | 1 +
include/asm
On Fri, Dec 07, 2018 at 04:35:08PM +, Srinivas Kandagatla wrote:
> The FastRPC driver implements an IPC (Inter-Processor Communication)
> mechanism that allows for clients to transparently make remote method
> invocations across DSP and APPS boundaries. This enables developers
> to offload
On Fri, Dec 07, 2018 at 04:35:08PM +, Srinivas Kandagatla wrote:
> The FastRPC driver implements an IPC (Inter-Processor Communication)
> mechanism that allows for clients to transparently make remote method
> invocations across DSP and APPS boundaries. This enables developers
> to offload
On Thu, Dec 06, 2018 at 05:13:44PM +0100, Ingo Molnar wrote:
>
> * Mark Rutland wrote:
>
> > Andrew and Ingo report that the check-atomics.sh script is simply too
> > slow to run for every kernel build, and it's impractical to make it
> > faster without rewriting
On Thu, Dec 06, 2018 at 05:13:44PM +0100, Ingo Molnar wrote:
>
> * Mark Rutland wrote:
>
> > Andrew and Ingo report that the check-atomics.sh script is simply too
> > slow to run for every kernel build, and it's impractical to make it
> > faster without rewriting
On Fri, Nov 30, 2018 at 10:55:47AM +, Julien Thierry wrote:
> On 29/11/18 17:44, Mark Rutland wrote:
> > On Mon, Nov 12, 2018 at 11:56:59AM +, Julien Thierry wrote:
> >> + mov x2, #GIC_PRIO_IRQON
> >> + msr_s SYS_ICC_PMR_EL1, x2 // un
On Fri, Nov 30, 2018 at 10:55:47AM +, Julien Thierry wrote:
> On 29/11/18 17:44, Mark Rutland wrote:
> > On Mon, Nov 12, 2018 at 11:56:59AM +, Julien Thierry wrote:
> >> + mov x2, #GIC_PRIO_IRQON
> >> + msr_s SYS_ICC_PMR_EL1, x2 // un
On Mon, Nov 12, 2018 at 11:56:56AM +, Julien Thierry wrote:
> Mask the IRQ priority through PMR and re-enable IRQs at CPU level,
> allowing only higher priority interrupts to be received during interrupt
> handling.
>
> Signed-off-by: Julien Thierry
> Cc: Catalin Marinas
> Cc: Will Deacon
On Mon, Nov 12, 2018 at 11:56:56AM +, Julien Thierry wrote:
> Mask the IRQ priority through PMR and re-enable IRQs at CPU level,
> allowing only higher priority interrupts to be received during interrupt
> handling.
>
> Signed-off-by: Julien Thierry
> Cc: Catalin Marinas
> Cc: Will Deacon
On Mon, Nov 12, 2018 at 11:56:59AM +, Julien Thierry wrote:
> CPU does not received signals for interrupts with a priority masked by
> ICC_PMR_EL1. This means the CPU might not come back from a WFI
> instruction.
>
> Make sure ICC_PMR_EL1 does not mask interrupts when doing a WFI.
>
>
On Mon, Nov 12, 2018 at 11:56:59AM +, Julien Thierry wrote:
> CPU does not received signals for interrupts with a priority masked by
> ICC_PMR_EL1. This means the CPU might not come back from a WFI
> instruction.
>
> Make sure ICC_PMR_EL1 does not mask interrupts when doing a WFI.
>
>
ol system_supports_cnp(void)
> cpus_have_const_cap(ARM64_HAS_CNP);
> }
>
> +static inline bool system_supports_irq_prio_masking(void)
> +{
> + return IS_ENABLED(CONFIG_ARM64_PSEUDO_NMI) &&
> + cpus_have_const_cap(ARM64_HAS_IRQ_PRIO
ol system_supports_cnp(void)
> cpus_have_const_cap(ARM64_HAS_CNP);
> }
>
> +static inline bool system_supports_irq_prio_masking(void)
> +{
> + return IS_ENABLED(CONFIG_ARM64_PSEUDO_NMI) &&
> + cpus_have_const_cap(ARM64_HAS_IRQ_PRIO
On Mon, Nov 12, 2018 at 11:56:58AM +, Julien Thierry wrote:
> If ICC_PMR_EL1 is used to mask interrupts, its value should be
> saved/restored whenever a task is context switched out/in or
> gets an exception.
>
> Add PMR to the registers to save in the pt_regs struct upon kernel entry,
> and
On Mon, Nov 12, 2018 at 11:56:58AM +, Julien Thierry wrote:
> If ICC_PMR_EL1 is used to mask interrupts, its value should be
> saved/restored whenever a task is context switched out/in or
> gets an exception.
>
> Add PMR to the registers to save in the pt_regs struct upon kernel entry,
> and
On Mon, Nov 12, 2018 at 11:56:57AM +, Julien Thierry wrote:
> Introduce fixed values for PMR that are going to be used to mask and
> unmask interrupts by priority. These values are chosent in such a way
Nit: s/chosent/chosen/
> that a single bit (GIC_PMR_UNMASKED_BIT) encodes the information
On Mon, Nov 12, 2018 at 11:56:57AM +, Julien Thierry wrote:
> Introduce fixed values for PMR that are going to be used to mask and
> unmask interrupts by priority. These values are chosent in such a way
Nit: s/chosent/chosen/
> that a single bit (GIC_PMR_UNMASKED_BIT) encodes the information
rc Zyngier
The AArch32 ICC_RPR encoding looks right per ARM DDI 0487D.a table G7-3,
and the rest looks sane to me.
Reviewed-by: Mark Rutland
Mark.
> ---
> arch/arm/include/asm/arch_gicv3.h | 16
> arch/arm64/include/asm/arch_gicv3.h | 15 +++
> 2 files
rc Zyngier
The AArch32 ICC_RPR encoding looks right per ARM DDI 0487D.a table G7-3,
and the rest looks sane to me.
Reviewed-by: Mark Rutland
Mark.
> ---
> arch/arm/include/asm/arch_gicv3.h | 16
> arch/arm64/include/asm/arch_gicv3.h | 15 +++
> 2 files
> Cc: Suzuki K Poulose
> Cc: Marc Zyngier
Makes sense.
Reviewed-by: Mark Rutland
Mark.
> ---
> arch/arm64/kernel/cpufeature.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> in
701 - 800 of 8690 matches
Mail list logo
