Christoph Hellwig writes:
> We want to use the dma_direct_ namespace for a generic implementation,
> so rename powerpc to the second best choice: dma_nommu_.
I'm not a fan of "nommu". Some of the users of direct ops *are* using an
IOMMU, they're just setting up a 1:1 mapping once at init time, r
On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman wrote:
> Christoph Hellwig writes:
>
>> We want to use the dma_direct_ namespace for a generic implementation,
>> so rename powerpc to the second best choice: dma_nommu_.
>
> I'm not a fan of "nommu". Some of the users of direct ops *are* using an
Missing patch description explaining why this change is desirable.
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig wrote:
> --- a/lib/dma-direct.c
> +++ b/lib/dma-direct.c
> @@ -39,7 +39,7 @@ static void *dma_direct_alloc(struct device *dev, size_t
> size,
> if (gfpflags_allow_blockin
Hi Christoph,
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig wrote:
> CONFIG_ALPHA_JENSEN has failed to compile since commit aca05038
> ("alpha/dma: use common noop dma ops"), so mark it as broken.
unknown revision or path not in the working tree.
Ah, you dropped the leading "6":
6aca0503847
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig wrote:
> Life the code from x86 so that we behave consistently. In the future we
> should probably warn if any of these is set.
>
> Signed-off-by: Christoph Hellwig
For m68k:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig wrote:
> The current PCI_DMA_BUS_IS_PHYS decided if a dma implementation is bound
> by the dma mask in the device because it directly maps to a physical
> address range (modulo an offset in the device), or if it is virtualized
> by an iommu and ca
Jose Ricardo Ziviani writes:
> This patch provides the MMIO load/store vector indexed
> X-Form emulation.
>
> Instructions implemented: lvx, stvx
>
> Signed-off-by: Jose Ricardo Ziviani
> ---
> arch/powerpc/include/asm/kvm_host.h | 2 +
> arch/powerpc/include/asm/kvm_ppc.h| 4 +
> arc
Add a test case of the error code reported when we take a SEGV on a
mapped but inaccessible area. We broke this recently.
Based on a test case from John Sperbeck .
Signed-off-by: Michael Ellerman
---
tools/testing/selftests/powerpc/mm/.gitignore| 3 +-
tools/testing/selftests/powerpc/mm/Ma
Jose Ricardo Ziviani writes:
> The hotplug engine uses its own workqueue to handle IRQ requests, the
> problem is that such workqueue is initialized after init_ras_IRQ, which
> will cause a kernel panic if any hotplug interruption is issued in that
> period of time.
>
> This patch changes the dlp
On 29/12/17 08:18, Christoph Hellwig wrote:
> The trivial direct mapping implementation already does a virtual to
> physical translation which isn't strictly a noop, and will soon learn
> to do non-direct but linear physical to dma translations through the
> device offset and a few small tricks. R
On 29/12/17 08:18, Christoph Hellwig wrote:
> This means it uses whatever linear remapping scheme that the architecture
> provides is used in the generic dma_direct ops.
>
> Signed-off-by: Christoph Hellwig
> ---
> lib/dma-direct.c | 18 +++---
> 1 file changed, 7 insertions(+), 11 d
On 29/12/17 08:18, Christoph Hellwig wrote:
> If we got back an allocation that wasn't inside the support coherent mask,
> retry the allocation using GFP_DMA.
>
> Based on the x86 code.
>
> Signed-off-by: Christoph Hellwig
> ---
> lib/dma-direct.c | 25 -
> 1 file change
On 29/12/17 08:18, Christoph Hellwig wrote:
> So that they don't need to indirect through the operation vector.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/arm/mm/dma-mapping-nommu.c | 9 +++--
> include/linux/dma-direct.h | 5 +
> lib/dma-direct.c| 6 +++---
>
From: Michael Ellerman
Date: Fri, 22 Dec 2017 15:22:22 +1100
>> On Tue, Dec 19 2017, Michael Ellerman
>> wrote:
>>> This revert seems to have broken networking on one of my powerpc
>>> machines, according to git bisect.
>>>
>>> The symptom is DHCP fails and I don't get a link, I didn't dig any
On Tue, 2018-01-02 at 11:50 -0500, David Miller wrote:
> From: Michael Ellerman
> Date: Fri, 22 Dec 2017 15:22:22 +1100
>
> >> On Tue, Dec 19 2017, Michael Ellerman
> >> wrote:
> >>> This revert seems to have broken networking on one of my powerpc
> >>> machines, according to git bisect.
> >>>
On Tue, Jan 02, 2018 at 10:46:07PM +1100, Michael Ellerman wrote:
> Jose Ricardo Ziviani writes:
>
> > The hotplug engine uses its own workqueue to handle IRQ requests, the
> > problem is that such workqueue is initialized after init_ras_IRQ, which
> > will cause a kernel panic if any hotplug int
On Tue, Jan 2, 2018 at 3:03 AM, Michael Ellerman wrote:
> Add a test case of the error code reported when we take a SEGV on a
> mapped but inaccessible area. We broke this recently.
>
> Based on a test case from John Sperbeck .
>
> Signed-off-by: Michael Ellerman
> ---
> tools/testing/selftests/
This adds support for emitting special sections such as initcall arrays,
PCI fixups and tracepoints as relative references rather than absolute
references. This reduces the size by 50% on 64-bit architectures, but
more importantly, it removes the need for carrying relocation metadata
for these sect
Before updating certain subsystems to use place relative 32-bit
relocations in special sections, to save space and reduce the
number of absolute relocations that need to be processed at runtime
by relocatable kernels, introduce the Kconfig symbol and define it
for some architectures that should be
To allow existing C code to be incorporated into the decompressor or
the UEFI stub, introduce a CPP macro that turns all EXPORT_SYMBOL_xxx
declarations into nops, and #define it in places where such exports
are undesirable. Note that this gets rid of a rather dodgy redefine
of linux/export.h's head
An ordinary arm64 defconfig build has ~64 KB worth of __ksymtab
entries, each consisting of two 64-bit fields containing absolute
references, to the symbol itself and to a char array containing
its name, respectively.
When we build the same configuration with KASLR enabled, we end
up with an addit
Allow the initcall tables to be emitted using relative references that
are only half the size on 64-bit architectures and don't require fixups
at runtime on relocatable kernels.
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Cc: James Morris
Cc: "Serge E. Hallyn"
Signed-off-by: Ard
To avoid the need for relocating absolute references to tracepoint
structures at boot time when running relocatable kernels (which may
take a disproportionate amount of space), add the option to emit
these tables as relative references instead.
Cc: Ingo Molnar
Acked-by: Steven Rostedt (VMware)
S
In preparation of allowing architectures to use relative references
in jump_label entries [which can dramatically reduce the memory
footprint], introduce abstractions for references to the 'code' and
'key' members of struct jump_entry.
Signed-off-by: Ard Biesheuvel
---
arch/arm/include/asm/jump_
Allow the PCI quirk tables to be emitted in a way that avoids absolute
references to the hook functions. This reduces the size of the entries,
and, more importantly, makes them invariant under runtime relocation
(e.g., for KASLR)
Acked-by: Bjorn Helgaas
Signed-off-by: Ard Biesheuvel
---
drivers
On a randomly chosen distro kernel build for arm64, vmlinux.o shows the
following sections, containing jump label entries, and the associated
RELA relocation records, respectively:
...
[38088] __jump_table PROGBITS 00e19f30
0002ea10 00
In preparation of switching x86 to use place-relative references for
the code, target and key members of struct jump_entry, replace direct
references to the struct member with invocations of the new accessors.
This will allow us to make the switch by modifying the accessors only.
Signed-off-by: Ar
Similar to the arm64 case, 64-bit x86 can benefit from using 32-bit
relative references rather than 64-bit absolute ones when emitting
struct jump_entry instances. Not only does this reduce the memory
footprint of the entries themselves by 50%, it also removes the need
for carrying relocation metad
On Fri, 2017-12-08 at 17:11 +1100, Paul Mackerras wrote:
> POWER9 has hardware bugs relating to transactional memory and thread
> reconfiguration (changes to hardware SMT mode). Specifically, the
> core
> does not have enough storage to store a complete checkpoint of all
> the
> architected state
On Tue, Dec 19, 2017 at 9:00 AM, Nicolin Chen wrote:
>
> ==Background==
> The fsl_ssi driver was designed for PPC originally and then it has
> been updated to support different modes for i.MX Series, including
> SDMA, I2S Master mode, AC97 and older i.MXs with FIQ, by different
> contributors for
On Tue, 2 Jan 2018, Ard Biesheuvel wrote:
> To allow existing C code to be incorporated into the decompressor or
> the UEFI stub, introduce a CPP macro that turns all EXPORT_SYMBOL_xxx
> declarations into nops, and #define it in places where such exports
> are undesirable. Note that this gets rid
On 2 January 2018 at 23:47, Nicolas Pitre wrote:
> On Tue, 2 Jan 2018, Ard Biesheuvel wrote:
>
>> To allow existing C code to be incorporated into the decompressor or
>> the UEFI stub, introduce a CPP macro that turns all EXPORT_SYMBOL_xxx
>> declarations into nops, and #define it in places where
On Sun, Dec 24, 2017 at 02:49:23AM +1000, Nicholas Piggin wrote:
> Platforms with a panic handler that halts the system can have problems
> getting kernel messages out, because the panic notifiers are called
> before kernel/panic.c does its flushing of printk buffers an console
> etc.
>
> This was
On Sun, Dec 24, 2017 at 02:49:22AM +1000, Nicholas Piggin wrote:
> The die() oops path contains a serializing lock to prevent oops
> messages from being interleaved. In the case of a system reset
> initiated oops (e.g., qemu nmi command), __die was being called
> which lacks that synchronisation an
On 19/12/17 02:21, Frederic Barrat wrote:
The NPU was already abstracted by opal as a virtual PHB for nvlink,
but it helps to be able to differentiate between a nvlink or opencapi
PHB, as it's not completely transparent to linux. In particular, PE
assignment differs and we'll also need the inform
On 19/12/17 02:21, Frederic Barrat wrote:
OCXL_BASE triggers the platform support needed by the driver.
Signed-off-by: Frederic Barrat
---
drivers/misc/Kconfig | 1 +
drivers/misc/Makefile | 1 +
drivers/misc/ocxl/Kconfig | 25 +
drivers/misc/ocxl/Make
John Sperbeck writes:
> On Tue, Jan 2, 2018 at 3:03 AM, Michael Ellerman wrote:
>> Add a test case of the error code reported when we take a SEGV on a
>> mapped but inaccessible area. We broke this recently.
>>
>> Based on a test case from John Sperbeck .
>>
>> Signed-off-by: Michael Ellerman
.
Geert Uytterhoeven writes:
> On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman wrote:
>> Christoph Hellwig writes:
>>
>>> We want to use the dma_direct_ namespace for a generic implementation,
>>> so rename powerpc to the second best choice: dma_nommu_.
>>
>> I'm not a fan of "nommu". Some of t
Nicholas Piggin writes:
> There are several cases outside the normal address space management
> where a CPU's entire local TLB is to be flushed:
>
> 1. Booting the kernel, in case something has left stale entries in
> the TLB (e.g., kexec).
>
> 2. Machine check, to clean corrupted TLB en
On 19/12/17 02:21, Frederic Barrat wrote:
Add an ocxl driver to handle generic opencapi devices. Of course, it's
not meant to be the only opencapi driver, any device is free to
implement its own. But if a host application only needs basic services
like attaching to an opencapi adapter, have trans
On 19/12/17 02:21, Frederic Barrat wrote:
Implement a few platform-specific calls which can be used by drivers:
- provide the Transaction Layer capabilities of the host, so that the
driver can find some common ground and configure the device and host
appropriately.
- provide the hw interr
Hi Michael,
On Wed, Jan 3, 2018 at 7:24 AM, Michael Ellerman wrote:
> Geert Uytterhoeven writes:
>
>> On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman
>> wrote:
>>> Christoph Hellwig writes:
>>>
We want to use the dma_direct_ namespace for a generic implementation,
so rename powerp
42 matches
Mail list logo
