[PATCH 4/5] powerpc: wii: Don't rely on the reserved memory hack

Signed-off-by: Jonathan Neuschäfer --- arch/powerpc/platforms/embedded6xx/wii.c | 14 +- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git a/arch/powerpc/platforms/embedded6xx/wii.c b/arch/powerpc/platforms/embedded6xx/wii.c index

[PATCH 1/5] powerpc: mm: Simplify page_is_ram by using memblock_is_memory

Instead of open-coding the search in page_is_ram, call memblock_is_memory. Signed-off-by: Jonathan Neuschäfer --- arch/powerpc/mm/mem.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index

[PATCH 0/5] PPC32/ioremap: Use memblock API to check for RAM

This patchset solves the same problem as my previous one[1] but follows a rather different approach. Instead of implementing DISCONTIGMEM for PowerPC32, I simply switched the "is this RAM" check in __ioremap_caller to the existing page_is_ram function, and unified page_is_ram to search

Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace

Yeah, I think metadata will evolve for a while till it settle's down. Since ocxl_ioctl_get_metadata is exposed via uapi, a newer program calling an older kernel will never work, since the size of that struct will always be larger than what the OS supports and our copy_to_user() will fail. The

[PATCH] PCI/AER: Add a null check before eeh_ops->notify_resume callback.

This patch puts a NULL check before branching to the address pointed to by eeh_ops->notify_resume in eeh_report_resume(). The callback is used to notify the arch EEH code that a pci device is back online. For PPC64 presently, only an implementation for pseries platform is available and not for

Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests

On Tue, Feb 20, 2018 at 11:32:25AM +, Horia Geantă wrote: > > If final/finup is optional, how is the final hash supposed to be retrieved? Sometimes the computation ends with a partial hash, that's what export is for. Also it is completely legal to abandon the hash state entirely. >

Re: [PATCH 4.14, 4.9] crypto: talitos - fix Kernel Oops on hashing an empty file

Le 22/02/2018 à 09:30, Horia Geantă a écrit : On 2/22/2018 9:08 AM, Christophe Leroy wrote: Upstream 87a81dce53b1ea61acaeefa5191a0376a2d1d721 Performing the hash of an empty file leads to a kernel Oops [ 44.504600] Unable to handle kernel paging request for data at address 0x000c [

Re: [PATCH 4.14, 4.9] crypto: talitos - fix Kernel Oops on hashing an empty file

On 2/22/2018 9:08 AM, Christophe Leroy wrote: > Upstream 87a81dce53b1ea61acaeefa5191a0376a2d1d721 > > Performing the hash of an empty file leads to a kernel Oops > > [ 44.504600] Unable to handle kernel paging request for data at address > 0x000c > [ 44.512819] Faulting instruction

<    1   2