On 10/19/2018 03:31 AM, Christophe Leroy wrote:
> commit d7880812b359 ("idle: Add the stack canary init to
> cpu_startup_entry()") added the call to boot_init_stack_canary()
> in cpu_startup_entry() in an #ifdef CONFIG_X86 statement, with
> the intention to remove that #ifdef later.
>
> While impl
Hi Christophe,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on xen-tip/linux-next]
[also build test ERROR on v4.19-rc8 next-20181019]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
Hi Christophe,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on xen-tip/linux-next]
[also build test ERROR on v4.19-rc8 next-20181019]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
On Fri, 19 Oct 2018 05:09:49 PDT (-0700), Christoph Hellwig wrote:
There is no good reason to duplicate the PCI menu in every architecture.
Instead provide a selectable HAVE_PCI symbol that indicates availability
of PCI support and the handle the rest in drivers/pci.
Note that for powerpc we now
On Thu, Oct 18, 2018 at 2:09 PM Frank Rowand wrote:
>
> On 10/18/18 10:09, Rob Herring wrote:
> > On Mon, Oct 15, 2018 at 07:37:24PM -0700, frowand.l...@gmail.com wrote:
> >> From: Frank Rowand
> >>
> >> "of: overlay: add missing of_node_get() in __of_attach_node_sysfs"
> >> added a missing of_no
On Fri, Oct 19, 2018 at 8:14 AM, Christophe Leroy
wrote:
> In the powerpc, there are several places implementing safe
> access to user data. This is sometimes implemented using
> probe_kerne_address() with additional access_ok() verification,
> sometimes with get_user() enclosed in a pagefault_dis
On Fri, Oct 19, 2018 at 02:09:48PM +0200, Christoph Hellwig wrote:
> Various powerpc boards select the PCI_MSI config option without selecting
> PCI, resulting in potentially not compilable configurations if the by
> default enabled PCI option is disabled. Explicitly select PCI to ensure
> we alwa
In the powerpc, there are several places implementing safe
access to user data. This is sometimes implemented using
probe_kerne_address() with additional access_ok() verification,
sometimes with get_user() enclosed in a pagefault_disable()/enable()
pair, etc... :
show_user_instructions()
ba
On Fri, Oct 19, 2018 at 9:23 PM Russell King - ARM Linux
wrote:
> > index a68b34183107..b185794549be 100644
> > --- a/arch/arm/mach-pxa/Kconfig
> > +++ b/arch/arm/mach-pxa/Kconfig
> > @@ -125,7 +125,7 @@ config MACH_ARMCORE
> > bool "CompuLab CM-X255/CM-X270 modules"
> > select ARCH_H
On Fri, Oct 19, 2018 at 9:10 PM Christoph Hellwig wrote:
>
> No arm config enables EISA, and arm does not include drivers/eisa/Kconfig
> which provides support for things like PCI to EISA bridges, so it is most
> likely dead.
>
> If this is wrong we will be able to resurrect it easily by selecting
On Fri, Oct 19, 2018 at 02:09:49PM +0200, Christoph Hellwig wrote:
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index e33735ce1c14..7495d0a0aa31 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -149,9 +149,6 @@ config ARM_DMA_IOMMU_ALIGNMENT
>
> endif
>
> -config MIGHT_HAV
Let architectures opt into EISA support by selecting HAS_EISA and
handle everything else in drivers/eisa.
Signed-off-by: Christoph Hellwig
Acked-by: Thomas Gleixner
---
arch/alpha/Kconfig | 15 ---
arch/mips/Kconfig | 31 +--
arch/powerpc/Kconfig
There is no good reason to duplicate the RAPIDIO menu in various
architectures. Instead provide a selectable HAVE_RAPIDIO symbol
that indicates native availability of RAPIDIO support and the handle
the rest in drivers/pci. This also means we now provide support
for PCI(e) to Rapidio bridges for e
There is nothing architecture specific in the PCMCIA core, so allow
building it everywhere. The actual host controllers will depend on ISA,
PCI or a specific SOC.
Signed-off-by: Christoph Hellwig
Acked-by: Dominik Brodowski
Acked-by: Thomas Gleixner
---
arch/alpha/Kconfig | 2 --
arch/arm
There is no good reason to duplicate the PCI menu in every architecture.
Instead provide a selectable HAVE_PCI symbol that indicates availability
of PCI support and the handle the rest in drivers/pci.
Note that for powerpc we now select HAVE_PCI globally instead of the
convoluted mess of condition
Various powerpc boards select the PCI_MSI config option without selecting
PCI, resulting in potentially not compilable configurations if the by
default enabled PCI option is disabled. Explicitly select PCI to ensure
we always have valid configs.
Signed-off-by: Christoph Hellwig
Acked-by: Thomas
Signed-off-by: Christoph Hellwig
Acked-by: Thomas Gleixner
---
arch/powerpc/Kconfig | 4
drivers/scsi/Kconfig | 6 +++---
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e8c8970248bc..d4e97469a5f0 100644
--- a/arch/powerpc/Kco
This option isn't actually used anywhere.
Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt
---
arch/powerpc/Kconfig | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index a80669209155..e8c8970248bc 100644
--- a/arch/powerpc
No arm config enables EISA, and arm does not include drivers/eisa/Kconfig
which provides support for things like PCI to EISA bridges, so it is most
likely dead.
If this is wrong we will be able to resurrect it easily by selecting
HAVE_EISA for the right arm configs after this series.
Suggested-by
Hi all,
currently every architecture that wants to provide on of the common
periphal busses needs to add some boilerplate code and include the
right Kconfig files. This series instead just selects the presence
(when needed) and then handles everything in the bus-specific
Kconfig file under drive
We plan to enable building the PCMCIA core and drivers, and the
non-prefixed PCMCIA name clashes with some arch headers.
Signed-off-by: Christoph Hellwig
Acked-by: Thomas Gleixner
---
drivers/scsi/aha152x.c | 14 +++---
drivers/scsi/pcmcia/aha152x_core.c | 2 +-
2 files cha
On Fri, Oct 19, 2018 at 09:22:08AM +0200, Geert Uytterhoeven wrote:
> Hi Christoph,
>
> On Fri, Oct 19, 2018 at 9:10 AM Christoph Hellwig wrote:
> > On Fri, Oct 19, 2018 at 09:07:51AM +0200, Geert Uytterhoeven wrote:
> > > Without this:
> > > - It's hard to visually match your untagged cover le
Hi Rob,
On Wed, Oct 10, 2018 at 01:51:24PM -0500, Rob Herring wrote:
> On Wed, Oct 10, 2018 at 11:50 AM Will Deacon wrote:
> > On Tue, Oct 09, 2018 at 01:14:02PM -0500, Rob Herring wrote:
> > > I guess the single interrupt case is less obvious now with no
> > > description (it's the first list it
Le 19/10/2018 à 12:01, Juergen Gross a écrit :
On 19/10/2018 11:29, Christophe Leroy wrote:
commit d7880812b359 ("idle: Add the stack canary init to
cpu_startup_entry()") added the call to boot_init_stack_canary()
in cpu_startup_entry() in an #ifdef CONFIG_X86 statement, with
the intention to
commit d7880812b359 ("idle: Add the stack canary init to
cpu_startup_entry()") added the call to boot_init_stack_canary()
in cpu_startup_entry() in an #ifdef CONFIG_X86 statement, with
the intention to remove that #ifdef later.
While implementing stack protector for powerpc, it has been
observed t
This changes the KVM code that emulates the decrementer function to do
the conversion of decrementer values to time intervals in nanoseconds
by calling the tb_to_ns() function exported by the powerpc timer code,
in preference to open-coded arithmetic using values from the
decrementer_clockevent str
On 19/10/2018 11:29, Christophe Leroy wrote:
> commit d7880812b359 ("idle: Add the stack canary init to
> cpu_startup_entry()") added the call to boot_init_stack_canary()
> in cpu_startup_entry() in an #ifdef CONFIG_X86 statement, with
> the intention to remove that #ifdef later.
>
> While impleme
commit d7880812b359 ("idle: Add the stack canary init to
cpu_startup_entry()") added the call to boot_init_stack_canary()
in cpu_startup_entry() in an #ifdef CONFIG_X86 statement, with
the intention to remove that #ifdef later.
While implementing stack protector for powerpc, it has been
observed t
Hi Christoph,
On Fri, Oct 19, 2018 at 9:10 AM Christoph Hellwig wrote:
> On Fri, Oct 19, 2018 at 09:07:51AM +0200, Geert Uytterhoeven wrote:
> > Without this:
> > - It's hard to visually match your untagged cover letter with the
> > actual patches,
> > - Your individual patches lack the versi
On Fri, Oct 19, 2018 at 09:07:51AM +0200, Geert Uytterhoeven wrote:
> Without this:
> - It's hard to visually match your untagged cover letter with the
> actual patches,
> - Your individual patches lack the version info, so people cannot see which
> version review comments in an email reply
Hi Christoph,
On Fri, Oct 19, 2018 at 9:00 AM Christoph Hellwig wrote:
> On Wed, Oct 17, 2018 at 10:30:49AM +0200, Geert Uytterhoeven wrote:
> > Please use "git format-patch -v --cover" to prepare patch series
> > for sending with git-send-email.
> >
> > "-v" to prefix all patches with version
On Fri, Oct 19, 2018 at 01:46:50PM +0900, Masahiro Yamada wrote:
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -59,6 +59,7 @@ config ARM
> > select HAVE_ARCH_TRACEHOOK
> > select HAVE_ARM_SMCCC if CPU_V7
> > select HAVE_EBPF_JIT if !CPU_ENDIAN_BE32
> > +
On Fri, Oct 19, 2018 at 02:07:04PM +0900, Masahiro Yamada wrote:
> We could add 'depends on HAVE_PCI' or something
> to guard it to avoid changing the logic.
I guess that makes sense.
> config PCI_ENDPOINT
> bool "PCI Endpoint Support"
> depends on HAVE_PCI # Is this correct ?
On Wed, Oct 17, 2018 at 10:30:49AM +0200, Geert Uytterhoeven wrote:
> Please use "git format-patch -v --cover" to prepare patch series
> for sending with git-send-email.
>
> "-v" to prefix all patches with version number ,
> "--cover" to have a "[PATCH 0/]" prefix in the cover letter.
We had
Using this HW assistance implies some constraints on the
page table structure:
- Regardless of the main page size used (4k or 16k), the
level 1 table (PGD) contains 1024 entries and each PGD entry covers
a 4Mbytes area which is managed by a level 2 table (PTE) containing
also 1024 entries each desc
commit 1bc54c03117b9 ("powerpc: rework 4xx PTE access and TLB miss")
introduced non atomic PTE updates and started the work of removing
PTE updates in TLB miss handlers, but kept PTE_ATOMIC_UPDATES for the
8xx with the following comment:
/* Until my rework is finished, 8xx still needs atomic PTE up
In order to allow the 8xx to handle pte_fragments, this patch
extends the use of pte_fragments to nohash/32 platforms.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/mmu_context.h | 2 +-
arch/powerpc/include/asm/nohash/32/mmu-40x.h | 1 +
arch/powerpc/include/asm/nohash/32
BOOK3S/32 cannot be BOOKE, so remove useless code
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/pgalloc.h | 18 --
arch/powerpc/include/asm/book3s/32/pgtable.h | 14 --
2 files changed, 32 deletions(-)
diff --git a/arch/powerpc/include/asm/bo
As in PPC64, inline pte_alloc_one() and pte_alloc_one_kernel()
in PPC32. This will allow to switch nohash/32 to pte_fragment
without impacting hash/32.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/pgalloc.h | 22 --
arch/powerpc/include/asm/nohash/32
In the same way as PPC64, let's handle pte allocation directly
in kernel_map_page() when slab is not available.
The new function early_pte_alloc_kernel() is put in as inline in
platforms pgalloc.h, this will allow to have different ones later.
It is not an issue because early_pte_alloc_kernel() is
As this is running with MMU off, the CPU only does speculative
fetch for code in the same page.
Following the significant size reduction of TLB handler routines,
the side handlers can be brought back close to the main part,
ie in the same page.
Signed-off-by: Christophe Leroy
---
arch/powerpc/k
This patch reworks the TLB Miss handler in order to not use r12
register, hence avoiding having to save it into SPRN_SPRG_SCRATCH2.
In the DAR Fixup code we can now use SPRN_M_TW, freeing
SPRN_SPRG_SCRATCH2.
Then SPRN_SPRG_SCRATCH2 may be used for something else in the future.
Signed-off-by: Chr
For using 512k pages with hardware assistance, the PTEs have to be spread
every 128 bytes in the L2 table.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/hugetlb.h | 4 +++-
arch/powerpc/mm/hugetlbpage.c | 13 +
arch/powerpc/mm/tlb_nohash.c | 3 +++
3 files
Today, on the 8xx the TLB handlers do SW tablewalk by doing all
the calculation in ASM, in order to match with the Linux page
table structure.
The 8xx offers hardware assistance which allows significant size
reduction of the TLB handlers, hence also reduces the time spent
in the handlers.
However
In preparation of making use of hardware assistance in TLB handlers,
this patch temporarily disables 16K pages and 512K pages. The reason
is that when using HW assistance in 4K pages mode, the linux model
fit with the HW model for 4K pages and 8M pages.
However for 16K pages and 512K mode some add
In order to simplify time critical exceptions handling 8xx
specific SW perf counters, this patch moves the counters into
the beginning of memory. This is possible because .text is readable
and the counters are never modified outside of the handlers.
By doing this, we avoid having to set a second r
The 8xx TLB miss routines are patched when (de)activating
perf counters.
This patch uses the new patch_site functionality in order
to get a better code readability and avoid a label mess when
dumping the code with 'objdump -d'
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/nohash/
The 8xx TLB miss routines are patched at startup at several places.
This patch uses the new patch_site functionality in order
to get a better code readability and avoid a label mess when
dumping the code with 'objdump -d'
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/nohash/32/mm
This patch adds a helper to get the address of a patch_site
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/code-patching.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/include/asm/code-patching.h
b/arch/powerpc/include/asm/code-patching.h
index 31733a95bbd
This patch move pgtable_t into platform headers.
It gets rid of the CONFIG_PPC_64K_PAGES case for PPC64
as nohash/64 doesn't support CONFIG_PPC_64K_PAGES.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/mmu-hash.h | 2 ++
arch/powerpc/inclu
The purpose of this patch is to move platform specific
mmu-xxx.h files in platform directories like pte-xxx.h files.
In the meantime this patch creates common nohash and
nohash/32 + nohash/64 mmu.h files for future common parts.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Christophe Leroy
---
There is no point in taking the page table lock as pte_frag or
pmd_frag are always NULL when we have only one fragment.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/pgtable-book3s64.c | 3 +++
arch/powerpc/mm/pgtable-frag.c | 3 +++
2 files changed, 6 in
In preparation of next patch which generalises the use of
pte_fragment_alloc() for all, this patch moves the related functions
in a place that is common to all subarches.
The 8xx will need that for supporting 16k pages, as in that mode
page tables still have a size of 4k.
Since pte_fragment with
53 matches
Mail list logo
