On Tue, 7 May 2019 11:52:44 +1000
Sam Bobroff wrote:
> On Mon, May 06, 2019 at 03:58:45PM -0600, Alex Williamson wrote:
> > On Fri, 19 Apr 2019 17:37:17 +0200
> > Greg Kurz wrote:
> >
> > > If vfio_pci_register_dev_region() fails then we should rollback
> > > previous changes, ie. unmap the A
Hi Sasha,
I don't think GCC 4.6 is the minimum supported for 4.14
As far as I can see, commit cafa0010cd51f ("Raise the minimum required
gcc version to 4.6") has not been applied to 4.14 and I can't see any
reason such a commit should apply on a stable branch.
Christophe
Le 07/05/2019 à 07:
"Christopher M. Riedl" writes:
> diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
> index b33bafb8fcea..d775da9b9227 100644
> --- a/arch/powerpc/kernel/security.c
> +++ b/arch/powerpc/kernel/security.c
> @@ -391,6 +394,15 @@ static void toggle_count_cache_flush(bool ena
Hi Dan,
"Aneesh Kumar K.V" writes:
> This move the dependency to DEV_DAX_PMEM_COMPAT such that only
> if DEV_DAX_PMEM is built as module we can allow the compat support.
>
> This allows to test the new code easily in a emulation setup where we
> often build things without module support.
>
> S
> On May 7, 2019 at 5:54 AM Michael Ellerman wrote:
>
>
> "Christopher M. Riedl" writes:
> > diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
> > index b33bafb8fcea..d775da9b9227 100644
> > --- a/arch/powerpc/kernel/security.c
> > +++ b/arch/powerpc/kernel/security
Add support for disabling the kernel implemented spectre v2 mitigation
(count cache flush on context switch) via the nospectre_v2 cmdline
option.
Suggested-by: Michael Ellerman
Signed-off-by: Christopher M. Riedl
Reviewed-by: Andrew Donnellan
---
v2->v3:
Address mpe's nitpick
arch/pow
https://bugzilla.kernel.org/show_bug.cgi?id=203517
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
CC||fs_bt...@kernel-bugs.os
https://bugzilla.kernel.org/show_bug.cgi?id=203517
--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 282669
--> https://bugzilla.kernel.org/attachment.cgi?id=282669&action=edit
bisect.log
--
You are receiving this mail because:
You are watching the assignee of the bug
Selects HAVE_C_RECORDMCOUNT to use the C version of the recordmcount
intead of the old Perl Version of recordmcount.
This should improve build time. It also seems like the old Perl Version
misses some calls to _mcount that the C version finds.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kc
Cache instructions (dcbz, dcbi, dcbf and dcbst) take two registers
that are summed to obtain the target address. Using '%y0' argument
gives GCC the opportunity to use both registers instead of only one
with the second being forced to 0.
Suggested-by: Segher Boessenkool
Signed-off-by: Christophe L
https://bugzilla.kernel.org/show_bug.cgi?id=203517
--- Comment #5 from Erhard F. (erhar...@mailbox.org) ---
Some more info about the system:
Talos II running Gentoo Linux ppc64, Big Endian.
btrfs root filesystem (zstd compressed, standard compression level).
swap: /sbin/zram-init -d0 -s32 -azstd -
On Sun, May 05, 2019 at 05:02:05AM +, Po Liu wrote:
> Current kernel code do not support the dynamic posix clock alarm set.
> This code would support it by the posix timer structure.
>
> 319 const struct k_clock clock_posix_dynamic = {
>
> 320 .clock_getres = pc_clock_getres,
> 321
On 2019-04-16 16:05:06 Tue, Hari Bathini wrote:
> From: Hari Bathini
>
> Firmware provides architected register state data at the time of crash.
> Process this data and build CPU notes to append to ELF core.
>
> Signed-off-by: Hari Bathini
> Signed-off-by: Vasant Hegde
> ---
>
> Changes in v2
Hi folks,
Just an FYI in case anyone else is seeing crashes very early in boot in
linux-next with the above config options.
The problem is the combination of some new code called via printk(),
check_pointer() which calls probe_kernel_read(). That then calls
allow_user_access() (PPC_KUAP) and tha
On Tue, May 7, 2019 at 4:50 AM Aneesh Kumar K.V
wrote:
>
>
> Hi Dan,
>
> "Aneesh Kumar K.V" writes:
>
> > This move the dependency to DEV_DAX_PMEM_COMPAT such that only
> > if DEV_DAX_PMEM is built as module we can allow the compat support.
> >
> > This allows to test the new code easily in a emu
Hi Christophe,
On Tue, May 07, 2019 at 01:31:39PM +, Christophe Leroy wrote:
> Cache instructions (dcbz, dcbi, dcbf and dcbst) take two registers
> that are summed to obtain the target address. Using '%y0' argument
> gives GCC the opportunity to use both registers instead of only one
> with th
On Tue, May 07, 2019 at 07:43:56PM +0530, Mahesh J Salgaonkar wrote:
> Can we use SPRN_* #defines which are already present in asm/reg.h instead of
> hard coding numbers for switch cases ? You may want to add new #defines
> for NIP, MSR and CCR.
But none of those three are SPRs. Please don't poll
Le 01/05/2019 à 12:32, Michael Ellerman a écrit :
Laurent Dufour writes:
Le 23/04/2019 à 18:04, Dave Hansen a écrit :
On 4/23/19 4:16 AM, Laurent Dufour wrote:
...
There are 2 assumptions here:
1. 'start' and 'end' are page aligned (this is guaranteed by __do_munmap().
2. the VDSO is 1
Le 07/05/2019 à 17:10, Segher Boessenkool a écrit :
Hi Christophe,
On Tue, May 07, 2019 at 01:31:39PM +, Christophe Leroy wrote:
Cache instructions (dcbz, dcbi, dcbf and dcbst) take two registers
that are summed to obtain the target address. Using '%y0' argument
gives GCC the opportunity
On 2019-04-16 16:06:13 Tue, Hari Bathini wrote:
> OPAL loads kernel & initrd at 512MB offset (256MB size), also exported
> as ibm,opal/dump/fw-load-area. So, if boot memory size of FADump is
> less than 768MB, kernel memory to be exported as '/proc/vmcore' would
> be overwritten by f/w while loadin
On Tue, 7 May 2019 09:01:45 +0200
Greg Kurz wrote:
> On Tue, 7 May 2019 11:52:44 +1000
> Sam Bobroff wrote:
>
> > On Mon, May 06, 2019 at 03:58:45PM -0600, Alex Williamson wrote:
> > > On Fri, 19 Apr 2019 17:37:17 +0200
> > > Greg Kurz wrote:
> > >
> > > > If vfio_pci_register_dev_regio
By converting start and size to page granularity, we actually ignore
unaligned parts within a page instead of properly bailing out with an
error.
Cc: Andrew Morton
Cc: Oscar Salvador
Cc: Michal Hocko
Cc: David Hildenbrand
Cc: Pavel Tatashin
Cc: Qian Cai
Cc: Wei Yang
Cc: Arun KS
Cc: Mathieu
We only want memory block devices for memory to be onlined/offlined
(add/remove from the buddy). This is required so user space can
online/offline memory and kdump gets notified about newly onlined memory.
Only such memory has the requirement of having to span whole memory blocks.
Let's factor out
Will come in handy when wanting to handle errors after
arch_add_memory().
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Mike Rapoport
Cc: David Hildenbrand
Cc: Vasily Gorbik
Cc: Oscar Salvador
Signed-off-by: David Hildenbrand
---
arch/s390/mm/init.c | 1
No longer needed, the callers of arch_add_memory() can handle this
manually.
Cc: Andrew Morton
Cc: David Hildenbrand
Cc: Michal Hocko
Cc: Oscar Salvador
Cc: Pavel Tatashin
Cc: Wei Yang
Cc: Joonsoo Kim
Cc: Qian Cai
Cc: Arun KS
Cc: Mathieu Malaterre
Signed-off-by: David Hildenbrand
---
i
Unused, and memory unplug path should never care about zones. This is
the job of memory offlining. ZONE_DEVICE might require special care -
the caller of arch_remove_memory() should handle this.
Signed-off-by: David Hildenbrand
---
include/linux/memory_hotplug.h | 2 +-
mm/memory_hotplug.c
Let's factor out removing of memory block devices, which is only
necessary for memory added via add_memory() and friends that created
memory block devices. Remove the devices before calling
arch_remove_memory().
This finishes factoring out memory block device handling from
arch_add_memory() and ar
Only memory to be added to the buddy and to be onlined/offlined by
user space using memory block devices needs (and should have!) memory
block devices.
Factor out creation of memory block devices Create all devices after
arch_add_memory() succeeded. We can later drop the want_memblock parameter,
b
Let's prepare for better error handling while adding memory by allowing
to use arch_remove_memory() and __remove_pages() even if
CONFIG_MEMORY_HOTREMOVE is not set. CONFIG_MEMORY_HOTREMOVE effectively
covers
- Offlining of system ram (memory block devices) - offline_pages()
- Unplug of system ram -
We really don't want anything during memory hotunplug to fail.
We always pass a valid memory block device, that check can go. Avoid
allocating memory and eventually failing. As we are always called under
lock, we can use a static piece of memory. This avoids having to put
the structure onto the sta
On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>
> We only want memory block devices for memory to be onlined/offlined
> (add/remove from the buddy). This is required so user space can
> online/offline memory and kdump gets notified about newly onlined memory.
>
> Only such memory has th
On 07.05.19 21:04, Dan Williams wrote:
> On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>>
>> We only want memory block devices for memory to be onlined/offlined
>> (add/remove from the buddy). This is required so user space can
>> online/offline memory and kdump gets notified about newl
On 07.05.19 21:21, David Hildenbrand wrote:
> On 07.05.19 21:04, Dan Williams wrote:
>> On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>>>
>>> We only want memory block devices for memory to be onlined/offlined
>>> (add/remove from the buddy). This is required so user space can
>>> onlin
On Tue, May 7, 2019 at 12:38 PM David Hildenbrand wrote:
>
> On 07.05.19 21:21, David Hildenbrand wrote:
> > On 07.05.19 21:04, Dan Williams wrote:
> >> On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
> >>>
> >>> We only want memory block devices for memory to be onlined/offlined
> >>> (
On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>
> By converting start and size to page granularity, we actually ignore
> unaligned parts within a page instead of properly bailing out with an
> error.
>
> Cc: Andrew Morton
> Cc: Oscar Salvador
> Cc: Michal Hocko
> Cc: David Hildenbran
On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>
> Will come in handy when wanting to handle errors after
> arch_add_memory().
>
> Cc: Martin Schwidefsky
> Cc: Heiko Carstens
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Mike Rapoport
> Cc: David Hildenbrand
> Cc: Vasily Gorbik
> C
Hi Nathan,
On 5/6/19 12:14 PM, Nathan Lynch wrote:
Hi Juliet,
Juliet Kim writes:
Fix extending start/stop topology update scope during LPM
Commit 65b9fdadfc4d ("powerpc/pseries/mobility: Extend start/stop
topology update scope") made the change to the duration that
topology updates are suppres
On 07.05.19 22:46, Dan Williams wrote:
> On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>>
>> Will come in handy when wanting to handle errors after
>> arch_add_memory().
>>
>> Cc: Martin Schwidefsky
>> Cc: Heiko Carstens
>> Cc: Andrew Morton
>> Cc: Michal Hocko
>> Cc: Mike Rapoport
On Tue, May 7, 2019 at 1:47 PM David Hildenbrand wrote:
>
> On 07.05.19 22:46, Dan Williams wrote:
> > On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
> >>
> >> Will come in handy when wanting to handle errors after
> >> arch_add_memory().
> >>
> >> Cc: Martin Schwidefsky
> >> Cc: Heiko
On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>
> Let's prepare for better error handling while adding memory by allowing
> to use arch_remove_memory() and __remove_pages() even if
> CONFIG_MEMORY_HOTREMOVE is not set. CONFIG_MEMORY_HOTREMOVE effectively
> covers
> - Offlining of system
On 07.05.19 23:02, Dan Williams wrote:
> On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>>
>> Let's prepare for better error handling while adding memory by allowing
>> to use arch_remove_memory() and __remove_pages() even if
>> CONFIG_MEMORY_HOTREMOVE is not set. CONFIG_MEMORY_HOTREMOVE
On 07.05.19 22:57, Dan Williams wrote:
> On Tue, May 7, 2019 at 1:47 PM David Hildenbrand wrote:
>>
>> On 07.05.19 22:46, Dan Williams wrote:
>>> On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
Will come in handy when wanting to handle errors after
arch_add_memory().
On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>
> No longer needed, the callers of arch_add_memory() can handle this
> manually.
>
> Cc: Andrew Morton
> Cc: David Hildenbrand
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Cc: Pavel Tatashin
> Cc: Wei Yang
> Cc: Joonsoo Kim
> Cc: Qian
On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>
> Only memory to be added to the buddy and to be onlined/offlined by
> user space using memory block devices needs (and should have!) memory
> block devices.
>
> Factor out creation of memory block devices Create all devices after
> arch_a
On 07.05.19 23:19, Dan Williams wrote:
> On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>>
>> No longer needed, the callers of arch_add_memory() can handle this
>> manually.
>>
>> Cc: Andrew Morton
>> Cc: David Hildenbrand
>> Cc: Michal Hocko
>> Cc: Oscar Salvador
>> Cc: Pavel Tatash
On Tue, May 7, 2019 at 2:24 PM David Hildenbrand wrote:
>
> On 07.05.19 23:19, Dan Williams wrote:
> > On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
> >>
> >> No longer needed, the callers of arch_add_memory() can handle this
> >> manually.
> >>
> >> Cc: Andrew Morton
> >> Cc: David H
On Tue, May 7, 2019 at 11:39 AM David Hildenbrand wrote:
>
> Let's factor out removing of memory block devices, which is only
> necessary for memory added via add_memory() and friends that created
> memory block devices. Remove the devices before calling
> arch_remove_memory().
>
> This finishes f
>> +static void unregister_memory(struct memory_block *memory)
>> +{
>> + BUG_ON(memory->dev.bus != &memory_subsys);
>
> Given this should never happen and only a future kernel developer
> might trip over it, do we really need to kill that developer's
> machine? I.e. s/BUG/WARN/? I guess an
On Tue, May 07, 2019 at 03:51:21PM -0700, Yury Norov wrote:
> Commit ed1cd6deb013 ("powerpc: Activate CONFIG_THREAD_INFO_IN_TASK")
> removes the function current_thread_info(). It's wrong because the
> function is used in non-arch code and is part of API.
In include/linux/thread_info.h:
#ifdef CO
Commit ed1cd6deb013 ("powerpc: Activate CONFIG_THREAD_INFO_IN_TASK")
removes the function current_thread_info(). It's wrong because the
function is used in non-arch code and is part of API.
For my series of arm64/ilp32, after applying the patch
https://github.com/norov/linux/commit/b269e51eee66ffe
On Tue, May 07, 2019 at 11:58:56PM +0100, Al Viro wrote:
> On Tue, May 07, 2019 at 03:51:21PM -0700, Yury Norov wrote:
> > Commit ed1cd6deb013 ("powerpc: Activate CONFIG_THREAD_INFO_IN_TASK")
> > removes the function current_thread_info(). It's wrong because the
> > function is used in non-arch cod
Hi, Christophe and everyone from the LinuxPPC community,
Hope you are doing well!
I was working with Daniel, and we were reviewing the ipic source code and came
to these questions:
1. The first one came up while reviewing the document "Understanding
IPIC" from NXP (*). The document state
On Tue, May 7, 2019 at 11:39 AM David Hildenbrand wrote:
>
> We really don't want anything during memory hotunplug to fail.
> We always pass a valid memory block device, that check can go. Avoid
> allocating memory and eventually failing. As we are always called under
> lock, we can use a static p
Hari Bathini's on April 16, 2019 8:35 pm:
> From: Hari Bathini
>
> Export /proc/opalcore file to analyze opal crashes. Since opalcore can
> be generated independent of CONFIG_FA_DUMP support in kernel, add this
> support under a new kernel config option CONFIG_OPAL_CORE. Also, avoid
> code duplic
On Tue, May 7, 2019 at 11:39 AM David Hildenbrand wrote:
>
> Unused, and memory unplug path should never care about zones. This is
> the job of memory offlining. ZONE_DEVICE might require special care -
> the caller of arch_remove_memory() should handle this.
The ZONE_DEVICE usage does not requir
Yury Norov writes:
> On Tue, May 07, 2019 at 11:58:56PM +0100, Al Viro wrote:
>> On Tue, May 07, 2019 at 03:51:21PM -0700, Yury Norov wrote:
>> > Commit ed1cd6deb013 ("powerpc: Activate CONFIG_THREAD_INFO_IN_TASK")
>> > removes the function current_thread_info(). It's wrong because the
>> > functi
Christophe Leroy writes:
> Selects HAVE_C_RECORDMCOUNT to use the C version of the recordmcount
> intead of the old Perl Version of recordmcount.
>
> This should improve build time. It also seems like the old Perl Version
> misses some calls to _mcount that the C version finds.
That would make th
If you compile with KVM but without CONFIG_HAVE_HW_BREAKPOINT you fail
at linking with:
arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x708): undefined reference to
`dawr_force_enable'
This was caused by this recent patch:
commit c1fe190c06723322f2dfac31d3b982c581e434ef
Author: Michael N
Hi Richard,
Thank you for your reply.
Br,
Po Liu
> -Original Message-
> From: Richard Cochran [mailto:richardcoch...@gmail.com]
> Sent: 2019年5月7日 21:50
> To: Po Liu
> Cc: net...@vger.kernel.org; linux-ker...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; linux-arm-ker...@lists.inf
From: Petr Štetiar Sent: Tuesday, May 7, 2019 5:25 AM
> There was NVMEM support added to of_get_mac_address, so it could now
> return ERR_PTR encoded error values, so we need to adjust all current users
> of of_get_mac_address to this new fact.
>
> While at it, remove superfluous is_valid_ether_a
Hi Abhishek,
Apologies for this delayed review.
On Mon, Apr 22, 2019 at 01:32:31AM -0500, Abhishek Goel wrote:
> Currently, the cpuidle governors determine what idle state a idling CPU
> should enter into based on heuristics that depend on the idle history on
> that CPU. Given that no predictive
Abhishek Goel's on April 22, 2019 4:32 pm:
> Currently, the cpuidle governors determine what idle state a idling CPU
> should enter into based on heuristics that depend on the idle history on
> that CPU. Given that no predictive heuristic is perfect, there are cases
> where the governor predicts a
On pseries, custom PCI resource alignment specified with the commandline
argument pci=resource_alignment is disabled due to PCI resources being
managed by the firmware. However, in the case of PCI hotplug the
resources are managed by the kernel, so custom alignments should be
honored in these cases
Introduce a new pcibios function pcibios_ignore_alignment_request
which allows the PCI core to defer to platform-specific code to
determine whether or not to ignore alignment requests for PCI resources.
The existing behavior is to simply ignore alignment requests when
PCI_PROBE_ONLY is set. This i
Hi,
Many architectures have similar, if not identical implementation of
pte_alloc_one_kernel(), pte_alloc_one(), pte_free_kernel() and pte_free().
A while ago Anshuman suggested to introduce a common definition of
GFP_PGTABLE and during the discussion it was suggested to rather
consolidate the al
Most architectures have identical or very similar implementation of
pte_alloc_one_kernel(), pte_alloc_one(), pte_free_kernel() and pte_free().
Add a generic implementation that can be reused across architectures and
enable its use on x86.
The generic implementation uses
GFP_KERNEL | __GF
alpha allocates PTE pages with __get_free_page() and uses
GFP_KERNEL | __GFP_ZERO for the allocations.
Switch it to the generic version that does exactly the same thing for the
kernel page tables and adds __GFP_ACCOUNT for the user PTEs.
The alpha pte_free() and pte_free_kernel() versions are ide
Replace __get_free_page() and alloc_pages() calls with the generic
__pte_alloc_one_kernel() and __pte_alloc_one().
There is no functional change for the kernel PTE allocation.
The difference for the user PTEs, is that the clear_pte_table() is now
called after pgtable_page_ctor() and the addition
The PTE allocations in arm64 are identical to the generic ones modulo the
GFP flags.
Using the generic pte_alloc_one() functions ensures that the user page
tables are allocated with __GFP_ACCOUNT set.
The arm64 definition of PGALLOC_GFP is removed and replaced with
GFP_PGTABLE_USER for p[gum]d_al
The csky implementation pte_alloc_one(), pte_free_kernel() and pte_free()
is identical to the generic except of lack of __GFP_ACCOUNT for the user
PTEs allocation.
Switch csky to use generic version of these functions.
The csky implementation of pte_alloc_one_kernel() is not replaced because
it d
The hexagon implementation pte_alloc_one(), pte_alloc_one_kernel(),
pte_free_kernel() and pte_free() is identical to the generic except of
lack of __GFP_ACCOUNT for the user PTEs allocation.
Switch hexagon to use generic version of these functions.
Signed-off-by: Mike Rapoport
---
arch/hexagon/
The sun3 MMU variant of m68k uses GFP_KERNEL to allocate a PTE page and
then memset(0) or clear_highpage() to clear it.
This is equivalent to allocating the page with GFP_KERNEL | __GFP_ZERO,
which allows replacing sun3 implementation of pte_alloc_one() and
pte_alloc_one_kernel() with the generic
MIPS allocates kernel PTE pages with
__get_free_pages(GFP_KERNEL | __GFP_ZERO, PTE_ORDER)
and user PTE pages with
pte = alloc_pages(GFP_KERNEL, PTE_ORDER)
and then uses clear_highpage(pte) to zero out the allocated page for the
user page tables.
The PTE_ORDER is hardwired to ze
The nds32 implementation of pte_alloc_one_kernel() differs from the generic
in the use of __GFP_RETRY_MAYFAIL flag, which is removed after the
conversion.
The nds32 version of pte_alloc_one() missed the call to pgtable_page_ctor()
and also used __GFP_RETRY_MAYFAIL. Switching it to use generic
__pt
nios2 allocates kernel PTE pages with
__get_free_pages(GFP_KERNEL | __GFP_ZERO, PTE_ORDER);
and user page tables with
pte = alloc_pages(GFP_KERNEL, PTE_ORDER);
if (pte)
clear_highpage();
The PTE_ORDER is hardwired to zero, which makes nios2 implementation
parisc allocates PTE pages with __get_free_page() and uses
GFP_KERNEL | __GFP_ZERO for the allocations.
Switch it to the generic version that does exactly the same thing for the
kernel page tables and adds __GFP_ACCOUNT for the user PTEs.
The pte_free_kernel() and pte_free() versions on are ident
The only difference between the generic and RISC-V implementation of PTE
allocation is the usage of __GFP_RETRY_MAYFAIL for both kernel and user
PTEs and the absence of __GFP_ACCOUNT for the user PTEs.
The conversion to the generic version removes the __GFP_RETRY_MAYFAIL and
ensures that GFP_ACCOU
um allocates PTE pages with __get_free_page() and uses
GFP_KERNEL | __GFP_ZERO for the allocations.
Switch it to the generic version that does exactly the same thing for the
kernel page tables and adds __GFP_ACCOUNT for the user PTEs.
The pte_free() and pte_free_kernel() versions are identical to
Replace __get_free_page() and alloc_pages() calls with the generic
__pte_alloc_one_kernel() and __pte_alloc_one().
There is no functional change for the kernel PTE allocation.
The difference for the user PTEs, is that the clear_pte_table() is now
called after pgtable_page_ctor() and the addition
The powernv platform is the only one that directly accesses SCOMs. Move the
support code to platforms/powernv, and get rid of the PPC_SCOM Kconfig
option, as SCOM support is always selected when compiling for powernv.
This also means that the Kconfig item for CONFIG_SCOM_DEBUGFS will actually
show
On Wed, May 01, 2019 at 10:59:00PM -0500, Gustavo A. R. Silva wrote:
> Mark,
>
> I wonder if you are going to take this patch.
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so
on so unless there is some
Enable the pcibios_after_init hook on all powerpc platforms.
This hook is executed at the end of pcibios_init and was previously
only available on CONFIG_PPC32.
Since it is useful and not inherently limited to 32-bit mode,
remove the limitation and allow it on all powerpc platforms.
Signed-off-by
(Resent to include relevant mailing lists - sorry about that!)
Hello all,
This patch set implements support for user-specified PCI resource
alignment on the pseries platform for hotplugged PCI devices.
Currently on pseries, PCI resource alignments specified with the
pci=resource_alignment command
83 matches
Mail list logo
