From: Ira Weiny
Every arch has the same check for a not HIGHMEM page. Define
kmap_atomic_fast() to quickly return already mapped pages and reduce the
code duplication by lifting this check to the core.
Reviewed-by: Dan Williams
Signed-off-by: Ira Weiny
---
arch/arc/mm/highmem.c| 7 ++
From: Ira Weiny
The kmap code for all the architectures is almost 100% identical.
Lift the common code to the core. Use ARCH_HAS_KMAP to indicate if an
arch needs a special kmap.
This also has the benefit of changing kmap() on a number of
architectures to be an inline call rather than an actua
From: Ira Weiny
Every single architecture (including !CONFIG_HIGHMEM) calls...
pagefault_enable();
preempt_enable();
... before returning from __kunmap_atomic(). Lift this code into the
kunmap_atomic() macro.
Reviewed-by: Dan Williams
Signed-off-by: Ira Weiny
---
arch/arc/m
From: Ira Weiny
Replace the use of BUG_ON(in_interrupt()) in the kmap() and kunmap()
in favor of might_sleep().
Besides the benefits of might_sleep(), this normalizes the
implementations such that they can be made generic in subsequent
patches.
Reviewed-by: Dan Williams
Signed-off-by: Ira Wein
From: Ira Weiny
All architectures do exactly the same thing for kunmap(); remove all the
duplicate definitions and lift the call to the core.
Reviewed-by: Dan Williams
Signed-off-by: Ira Weiny
---
arch/arc/include/asm/highmem.h| 9 -
arch/arm/include/asm/highmem.h| 1
From: Ira Weiny
The kmap infrastructure has been copied almost verbatim to every architecture.
This series consolidates obvious duplicated code. (k[un]map_atmoic has some
additional duplication between some of the architectures but the differences
were such to not warrant further changes.)
0day
On Tue, 21 Apr 2020 17:41:59 +0200 Christoph Hellwig wrote:
> To remove the use of set_fs in the coredump code there needs to be a
> way to convert a kernel siginfo to a userspace compat siginfo.
>
> Call that function copy_siginfo_to_compat and factor it out of
> copy_siginfo_to_user32.
>
> Th
Hi Daniel,
Thanks for the test. Can you send me the full log which may contain the
system info such as the following:
-
phys_mem_size = 0x2
dcache_bsize = 0x20
icache_bsize = 0x20
cpu_features = 0x0003008003b6
Excerpts from Rich Felker's message of April 26, 2020 9:11 am:
> On Sun, Apr 26, 2020 at 08:58:19AM +1000, Nicholas Piggin wrote:
>> Excerpts from Christophe Leroy's message of April 25, 2020 10:20 pm:
>> >
>> >
>> > Le 25/04/2020 à 12:56, Nicholas Piggin a écrit :
>> >> Excerpts from Christophe
On Sun, 26 Apr 2020 08:13:17 +0530 Anshuman Khandual
wrote:
>
>
> On 04/26/2020 06:25 AM, Andrew Morton wrote:
> > On Tue, 14 Apr 2020 17:14:30 +0530 Anshuman Khandual
> > wrote:
> >
> >> There are multiple similar definitions for arch_clear_hugepage_flags() on
> >> various platforms. This
On 04/26/2020 06:25 AM, Andrew Morton wrote:
> On Tue, 14 Apr 2020 17:14:30 +0530 Anshuman Khandual
> wrote:
>
>> There are multiple similar definitions for arch_clear_hugepage_flags() on
>> various platforms. This introduces HAVE_ARCH_CLEAR_HUGEPAGE_FLAGS for those
>> platforms that need to
>From 10ea2eaf492ca3f22f67a5a63a2b7865e45299ad Mon Sep 17 00:00:00 2001
From: Ram Pai
Date: Mon, 24 Feb 2020 01:09:48 -0500
Subject: [PATCH v3] powerpc/XIVE: SVM: share the event-queue page with the
Hypervisor.
XIVE interrupt controller uses an Event Queue (EQ) to enqueue event
notifications whe
386 randconfig-a002-20200426
i386 randconfig-a001-20200426
x86_64 randconfig-a002-20200426
i386 randconfig-f002-20200425
i386 randconfig-f003-20200425
x86_64 randconfig-f003-20200425
i386 r
c6x randconfig-a001-20200422
sparc64 randconfig-a001-20200422
microblaze randconfig-a001-20200422
nios2randconfig-a001-20200425
c6x randconfig-a001-20200425
h8300randconfig-a001-20200425
sparc64
On Tue, 14 Apr 2020 17:14:30 +0530 Anshuman Khandual
wrote:
> There are multiple similar definitions for arch_clear_hugepage_flags() on
> various platforms. This introduces HAVE_ARCH_CLEAR_HUGEPAGE_FLAGS for those
> platforms that need to define their own arch_clear_hugepage_flags() while
> also
nios2randconfig-a001-20200424
c6x randconfig-a001-20200424
h8300randconfig-a001-20200424
sparc64 randconfig-a001-20200424
microblaze randconfig-a001-20200424
nios2randconfig-a001-20200425
c6x
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Linus,
Please pull some more powerpc fixes for 5.7.
The lib/mpi one is all contained within #ifdef _ARCH_PPC.
cheers
The following changes since commit ae83d0b416db002fe95601e7f97f64b59514d936:
Linux 5.7-rc2 (2020-04-19 14:35:30 -0700)
ar
On Wed, 2020-04-22 at 05:41:29 UTC, Stephen Rothwell wrote:
> Hi all,
>
> After merging the powerpc tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> In file included from :32:
> ./usr/include/asm/vas-api.h:15:2: error: unknown type name '__u32'
>15 | __u32 versio
On Mon, 2020-04-20 at 05:37:42 UTC, Christophe Leroy wrote:
> WRITE_RO lkdtm test works.
>
> But when selecting CONFIG_DEBUG_RODATA_TEST, the kernel reports
> rodata_test: test data was not read only
>
> This is because when rodata test runs, there are still old entries
> in TLB.
>
> Flush
On Fri, 2020-04-17 at 11:58:36 UTC, Christophe Leroy wrote:
> CONFIG_PPC_KUAP_DEBUG is not selectable because it depends on PPC_32
> which doesn't exists.
>
> Fixing it leads to a deadlock due to a vital register getting
> clobbered in _switch().
>
> Change dependency to PPC32 and use r0 instead
On Thu, 2020-04-16 at 22:19:08 UTC, Chris Packham wrote:
> If {i,d}-cache-block-size is set and {i,d}-cache-line-size is not, use
> the block-size value for both. Per the devicetree spec cache-line-size
> is only needed if it differs from the block size.
>
> Originally the code would fallback from
On Mon, 2020-04-13 at 19:50:42 UTC, Nathan Chancellor wrote:
> 0day reports over and over on an powerpc randconfig with clang:
>
> lib/mpi/generic_mpih-mul1.c:37:13: error: invalid use of a cast in a
> inline asm context requiring an l-value: remove the cast or build with
> -fheinous-gnu-extension
Excerpts from Rich Felker's message of April 26, 2020 2:22 am:
> On Sat, Apr 25, 2020 at 08:56:54PM +1000, Nicholas Piggin wrote:
>> >> The ELF v2 ABI convention would suit it well, because the caller already
>> >> requires the function address for ctr, so having it in r12 will
>> >> eliminate the
On Sun, Apr 26, 2020 at 08:58:19AM +1000, Nicholas Piggin wrote:
> Excerpts from Christophe Leroy's message of April 25, 2020 10:20 pm:
> >
> >
> > Le 25/04/2020 à 12:56, Nicholas Piggin a écrit :
> >> Excerpts from Christophe Leroy's message of April 25, 2020 5:47 pm:
> >>>
> >>>
> >>> Le 25/04/
Excerpts from Christophe Leroy's message of April 25, 2020 10:20 pm:
>
>
> Le 25/04/2020 à 12:56, Nicholas Piggin a écrit :
>> Excerpts from Christophe Leroy's message of April 25, 2020 5:47 pm:
>>>
>>>
>>> Le 25/04/2020 à 07:22, Nicholas Piggin a écrit :
As noted in the 'scv' thread, powerp
On Sat, Apr 25, 2020 at 02:15:49PM -0500, Segher Boessenkool wrote:
> On Sat, Apr 25, 2020 at 08:53:13PM +0200, Borislav Petkov wrote:
> > On Sat, Apr 25, 2020 at 01:37:01PM -0500, Segher Boessenkool wrote:
> > > That is a lot more typing then
> > > asm("");
> >
> > That's why a macro with a hop
On Sat, Apr 25, 2020 at 02:15:49PM -0500, Segher Boessenkool wrote:
> My point is that you should explain at *every use* of this why you cannot
> have tail calls *there*. This is very unusual, after all.
>
> There are *very* few places where you want to prevent tail calls, that's
> why there is n
On 4/23/20 8:11 AM, Derrick, Jonathan wrote:
Hi Sathyanarayanan,
On Wed, 2020-04-22 at 15:50 -0700, Kuppuswamy, Sathyanarayanan wrote:
On 4/20/20 2:37 PM, Jon Derrick wrote:
The existing portdrv model prevents DPC services without either OS
control (_OSC) granted to AER services, a Host Br
On Sat, Apr 25, 2020 at 08:53:13PM +0200, Borislav Petkov wrote:
> On Sat, Apr 25, 2020 at 01:37:01PM -0500, Segher Boessenkool wrote:
> > That is a lot more typing then
> > asm("");
>
> That's why a macro with a hopefully more descriptive name would be
> telling more than a mere asm("").
My
On Sat, Apr 25, 2020 at 01:37:01PM -0500, Segher Boessenkool wrote:
> That is a lot more typing then
> asm("");
That's why a macro with a hopefully more descriptive name would be
telling more than a mere asm("").
> but more seriously, you probably should explain why you do not want a
> tail
On Sat, Apr 25, 2020 at 07:31:40PM +0200, Borislav Petkov wrote:
> > There's also the one in init/main.c which is used by multiple
> > architectures. On x86 at least, the call to arch_call_rest_init at the
> > end of start_kernel does not get tail-call optimized by gcc-10, but I
> > don't see anyth
On Sat, Apr 25, 2020 at 07:31:40PM +0200, Borislav Petkov wrote:
> Hmm, that's what I was afraid of - having to sprinkle this around. Yah, let's
> wait for compiler guys to have a look here and then maybe I'll convert that
> thing to a macro called
>
> compiler_prevent_tail_call_opt()
>
> o
On Sat, Apr 25, 2020 at 11:04:40AM -0400, Arvind Sankar wrote:
> I'd put the clause about stack protector being disabled and the
> tail-call one together, to make clear that you still need the never
> return and always inline bits.
Done.
> Also, this function is implemented by multiple arch's and
On Fri, Apr 24, 2020 at 09:22:32AM +0200, David Hildenbrand wrote:
> On 12.04.20 21:48, Mike Rapoport wrote:
> > From: Baoquan He
> >
> > When called during boot the memmap_init_zone() function checks if each PFN
> > is valid and actually belongs to the node being initialized using
> > early_pfn_
On Sat, Apr 25, 2020 at 08:56:54PM +1000, Nicholas Piggin wrote:
> >> The ELF v2 ABI convention would suit it well, because the caller already
> >> requires the function address for ctr, so having it in r12 will
> >> eliminate the need for address calculation, which suits the vdso data
> >> page ac
On Sat, Apr 25, 2020 at 10:57:59AM +0200, Borislav Petkov wrote:
> On Fri, Apr 24, 2020 at 09:46:57PM -0400, Arvind Sankar wrote:
> > The comment above boot_init_stack_canary's definition should be updated
> > to note that it needs to be called from a function that, in addition to
> > not returning
On Tue, Apr 21, 2020 at 01:02:31PM +0200, Frederic Barrat wrote:
Le 18/04/2020 à 16:40, Sasha Levin a écrit :
From: Frederic Barrat
[ Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 ]
This shouldn't be backported to stable.
I've dropped this and the other two commits you've poi
On Sat, 25 Apr 2020 10:10:14 -0400
Steven Rostedt wrote:
> Deciding to BUG on not based on the return code of patch_instruction()
That was suppose to be "to BUG on or not,"
-- Steve
> is the way to go IMO.
On Fri, 24 Apr 2020 14:26:02 -0500
"Christopher M. Riedl" wrote:
> On Fri Apr 24, 2020 at 9:15 AM, Steven Rostedt wrote:
> > On Thu, 23 Apr 2020 18:21:14 +0200
> > Christophe Leroy wrote:
> >
> >
> > > Le 23/04/2020 à 17:09, Naveen N. Rao a écrit :
> > > > With STRICT_KERNEL_RWX, we are cur
On Sat, 25 Apr 2020 10:11:56 +
Christophe Leroy wrote:
>
> Sure it's be more explicit, but then more lines also. 3 lines for only
> one really usefull.
>
> With goto, I would look like:
>
> diff --git a/arch/powerpc/kernel/optprobes.c
> b/arch/powerpc/kernel/optprobes.c
> index 046485bb0a
Le 25/04/2020 à 12:56, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of April 25, 2020 5:47 pm:
Le 25/04/2020 à 07:22, Nicholas Piggin a écrit :
As noted in the 'scv' thread, powerpc's vdso calling convention does not
match the C ELF ABI calling convention (or the prop
Excerpts from Christophe Leroy's message of April 25, 2020 5:47 pm:
>
>
> Le 25/04/2020 à 07:22, Nicholas Piggin a écrit :
>> As noted in the 'scv' thread, powerpc's vdso calling convention does not
>> match the C ELF ABI calling convention (or the proposed scv convention).
>> I think we could im
On 04/24/2020 06:26 PM, Naveen N. Rao wrote:
Steven Rostedt wrote:
On Thu, 23 Apr 2020 17:41:52 +0200
Christophe Leroy wrote:
> diff --git a/arch/powerpc/kernel/optprobes.c
b/arch/powerpc/kernel/optprobes.c
> index 024f7aad1952..046485bb0a52 100644
> --- a/arch/powerpc/kernel/optprobes.c
>
Let's reduce the number of registers used in TLB miss handlers.
We have both r9 and r12 available for any temporary use.
r9 is enough, avoid using r12.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_40x.S | 70 --
1 file changed, 33 insertions(+),
This erratum is dedicated to IBM 405GP and STB03xxx
which are now gone.
Remove this erratum.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/asm-405.h | 19 ---
arch/powerpc/include/asm/atomic.h| 11 ---
arch/powerpc/include/asm/bitops.
ISS4xx has support for 405GP which is obsolete.
Remote it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/44x/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index 39e93d23fb38..78
We have r12 available, use it to keep CR around and don't
save it in SPRN_SPRG_SCRATCH6.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_40x.S | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/he
This erratum was for IBM 403GCX, 405EP and STB03xxx which are
now gone.
Remove this erratum.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_40x.S | 6 --
arch/powerpc/platforms/40x/Kconfig | 4
2 files changed, 10 deletions(-)
diff --git a/arch/powerpc/kernel/head_40
All platforms selecting the obsolete processor are gone now.
Remove support for it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/cputable.c | 13 -
arch/powerpc/platforms/40x/Kconfig | 6 --
2 files changed, 19 deletions(-)
diff --git a/arch/powerpc/kernel/cputa
EP405 is an old type of board based on a 405GP which is obsolete.
Remove it.
Signed-off-by: Christophe Leroy
---
v4: A few things from previous patch are now here as there are not related to
walnut
---
arch/powerpc/boot/Makefile | 3 +-
arch/powerpc/boot/dts/ep405.dts
CONFIG_WALNUT is not selected by any config and is based
on 405GP which is obsolete.
Remove it.
Signed-off-by: Christophe Leroy
---
v4: Moved a few things related to EP405 to next patch
Signed-off-by: Christophe Leroy
---
arch/powerpc/boot/Makefile | 4 +-
arch/powerpc/boot/
CONFIG_STB03xxx is not user selectable and is not selected
by any config.
Remove it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/cputable.c | 13 -
arch/powerpc/platforms/40x/Kconfig | 5 -
2 files changed, 18 deletions(-)
diff --git a/arch/powerpc/kernel/cputa
CONFIG_403GCX is not user selectable and is not
selected by any platform.
Remove it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/cache.h | 2 +-
arch/powerpc/include/asm/reg_booke.h | 54
arch/powerpc/include/asm/time.h | 12 ---
arch/
40x was the last user of PTE_ATOMIC_UPDATES.
Drop everything related to PTE_ATOMIC_UPDATES.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/nohash/32/pgtable.h | 32
arch/powerpc/include/asm/nohash/64/pgtable.h | 27 -
2 files changed, 59 deleti
From: Michal Simek
The latest Xilinx design tools called ISE and EDK has been released in
October 2013. New tool doesn't support any PPC405/PPC440 new designs.
These platforms are no longer supported and tested.
PowerPC 405/440 port is orphan from 2013 by
commit cdeb89943bfc ("MAINTAINERS: Fix i
Commit 1bc54c03117b ("powerpc: rework 4xx PTE access and TLB miss")
reworked 44x PTE access to avoid atomic pte updates, and
left 8xx, 40x and fsl booke with atomic pte updates.
Commit 6cfd8990e27d ("powerpc: rework FSL Book-E PTE access and TLB
miss") removed atomic pte updates on fsl booke.
It we
v1 and v2 of this series were aiming at removing 40x entirely,
but it led to protests.
v3 is trying to start modernising powerpc 40x:
- Rework TLB miss handlers to not use PTE_ATOMIC_UPDATES and _PAGE_HWWRITE
- Remove old versions of 40x processors, namely 403 and 405GP and associated
errata.
- La
On Sat, Apr 25, 2020 at 3:30 PM Shengjiu Wang wrote:
>
> The patch 955ac624058f: "ASoC: fsl_easrc: Add EASRC ASoC CPU DAI
> drivers" from Apr 16, 2020, leads to the following Smatch complaint:
>
> sound/soc/fsl/fsl_easrc.c:1529 fsl_easrc_hw_free()
> warn: variable dereferenced before check 'ctx' (
Le 25/04/2020 à 07:22, Nicholas Piggin a écrit :
As noted in the 'scv' thread, powerpc's vdso calling convention does not
match the C ELF ABI calling convention (or the proposed scv convention).
I think we could implement a new ABI by basically duplicating function
entry points with different
The patch 955ac624058f: "ASoC: fsl_easrc: Add EASRC ASoC CPU DAI
drivers" from Apr 16, 2020, leads to the following Smatch complaint:
sound/soc/fsl/fsl_easrc.c:1529 fsl_easrc_hw_free()
warn: variable dereferenced before check 'ctx' (see line 1527)
sound/soc/fsl/fsl_easrc.c
1526 struct
60 matches
Mail list logo
