From: Xuelin Shi
The RaidEngine is a new FSL hardware used for Raid5/6 acceration.
This patch enables the RaidEngine functionality and provides
hardware offloading capability for memcpy, xor and pq computation.
It works with async_tx.
Signed-off-by: Harninder Rai
Signed-off-by: Xuelin Shi
---
* Kees Cook wrote:
> To address the "offset2lib" ASLR weakness[1], this separates ET_DYN
> ASLR from mmap ASLR, as already done on s390. The architectures
> that are already randomizing mmap (arm, arm64, mips, powerpc, s390,
> and x86), have their various forms of arch_mmap_rnd() made available
On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
> Traditionally after a migration operation drmgr has coordinated the device
> tree
> update with the kernel in userspace via the ugly /proc/ppc64/ofdt interface.
> This
> can be better done fully in the kernel where support already exists.
On Mon, 2015-03-02 at 13:30 -0800, Tyrel Datwyler wrote:
> On 03/01/2015 08:19 PM, Cyril Bur wrote:
> > On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
> >> During suspend/migration operation we must wait for the VASI state reported
> >> by the hypervisor to become Suspending prior to maki
On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
> This patchset simplifies the usage of rtas_ibm_suspend_me() by removing an
> extraneous function parameter, fixes device tree updating on little endian
> platforms, and adds a mechanism for informing drmgr that the kernel is
> cabable of
>
This patch allows a context (different from kernel context)
to reserve a MSI bank for itself. And then the devices in the
context will share the MSI bank.
VFIO meta driver is one of typical user of these APIs. It will
reserve a MSI bank for MSI interrupt support of direct assignment
PCI devices to
With this patchset we add MSI bank partitioning support. MSI bank
partitioning is required for supporting direct device assignment
of MSI capable PCI devices. One MSI bank will be allocated for
"kernel context". VFIO can allocate one MSI bank per "context".
And all devices in the context will share
Having absolute address simplifies the code and also removes the
confusion around feature->msiir_offset and msi_data->msiir_offset.
Signed-off-by: Bharat Bhushan
---
arch/powerpc/sysdev/fsl_msi.c | 9 +++--
arch/powerpc/sysdev/fsl_msi.h | 2 +-
2 files changed, 4 insertions(+), 7 deletions(-
Moving out the specific MSI device search out of main loop. And now
the specific msi device search is placed with other "fsl.msi" specific
code in same function.
This is in preparation to MSI bank partitioning.
Signed-off-by: Bharat Bhushan
---
arch/powerpc/sysdev/fsl_msi.c | 39
With this patch a "context" can allocate a MSI bank and use the
allocated MSI-bank for the devices in that "context".
kernel/host "context" is "NULL", So all devices owned by kernel
will share a MSI bank allocated with "context = NULL.
This patch is in direction to have separate MSI bank for kern
From: Tang Yuantian
This driver works on all QorIQ platforms which include
ARM-based cores and PPC-based cores.
Rename it in order to represent better.
Signed-off-by: Tang Yuantian
Acked-by: Viresh Kumar
---
v3, v4
- none
v2:
- use -C -M options when format-patch
drivers/cpuf
From: Tang Yuantian
Freescale introduced new ARM core-based SoCs which support dynamic
frequency switch feature. DFS on new SoCs are compatible with current
PowerPC CoreNet platforms. In order to support those new platforms,
this driver needs to be updated. The main changes include:
1. Changed t
In preparation for moving ET_DYN randomization into the ELF loader
(which requires a static ELF_ET_DYN_BASE), this redefines s390's existing
ET_DYN randomization away from a separate function (randomize_et_dyn)
and into ELF_ET_DYN_BASE and a call to arch_mmap_rnd(). This refactoring
results in the
When an architecture fully supports randomizing the ELF load location, a
per-arch mmap_rnd() function is used to finding a randomized
mmap base. In preparation for randomizing the location of ET_DYN binaries
separately from mmap, this renames and exports these functions as
arch_mmap_rnd(). Addition
This fixes the "offset2lib" weakness in ASLR for arm, arm64, mips,
powerpc, and x86. The problem is that if there is a leak of ASLR from
the executable (ET_DYN), it means a leak of shared library offset as
well (mmap), and vice versa. Further details and a PoC of this attack
are available here:
htt
The arch_randomize_brk() function is used on several architectures,
even those that don't support ET_DYN ASLR. To avoid bulky extern/#define
tricks, consolidate the support under CONFIG_ARCH_HAS_ELF_RANDOMIZE for
the architectures that support it, while still handling CONFIG_COMPAT_BRK.
Signed-off
To address the "offset2lib" ASLR weakness[1], this separates ET_DYN
ASLR from mmap ASLR, as already done on s390. The architectures
that are already randomizing mmap (arm, arm64, mips, powerpc, s390,
and x86), have their various forms of arch_mmap_rnd() made available
via the new CONFIG_ARCH_HAS_EL
In preparation for exporting per-arch mmap randomization functions,
this moves the ASLR calculations for mmap on ARM into a separate routine.
Signed-off-by: Kees Cook
---
arch/arm/mm/mmap.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mm/mmap.c b/ar
Most architectures don't need to do anything special for the strict
seccomp syscall entries. Remove the redundant headers and reduce the
others.
Signed-off-by: Kees Cook
---
v2:
- use Kbuild "generic-y" instead of explicit #include lines (sfr)
---
arch/arm/include/asm/Kbuild | 1 +
On Mon, Mar 2, 2015 at 1:26 PM, Andrew Morton wrote:
> On Thu, 26 Feb 2015 19:07:09 -0800 Kees Cook wrote:
>
>> This separates ET_DYN ASLR from mmap ASLR, as already done on s390. The
>> various architectures that are already randomizing mmap (arm, arm64, mips,
>> powerpc, s390, and x86), have th
On Mon, Mar 02, 2015 at 03:37:28PM +0100, Milan Broz wrote:
>
> If crypto API allows to encrypt more sectors in one run
> (handling IV internally) dmcrypt can be modified of course.
>
> But do not forget we can use another IV (not only sequential number)
> e.g. ESSIV with XTS as well (even if it
On Mon, Mar 02, 2015 at 04:44:19PM -0500, Martin Hicks wrote:
>
> Write (MB/s)Read (MB/s)
> Unencrypted 140 176
> aes-xts-plain64 512b 113 115
> aes-xts-plain64 4kB 71 56
I got the two AES lines backwards. Sorry about th
On 03/01/2015 09:20 PM, Cyril Bur wrote:
> On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
>> We currently use the device tree update code in the kernel after resuming
>> from a suspend operation to re-sync the kernels view of the device tree with
>> that of the hypervisor. The code as it
On Mon, Mar 02, 2015 at 03:25:56PM +0200, Horia Geantă wrote:
> On 2/20/2015 7:00 PM, Martin Hicks wrote:
> > This adds the AES-XTS mode, supported by the Freescale SEC 3.3.2.
> >
> > One of the nice things about this hardware is that it knows how to deal
> > with encrypt/decrypt requests that are
On 03/01/2015 08:19 PM, Cyril Bur wrote:
> On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
>> During suspend/migration operation we must wait for the VASI state reported
>> by the hypervisor to become Suspending prior to making the ibm,suspend-me
>> RTAS call. Calling routines to rtas_ibm_
On Thu, 26 Feb 2015 19:07:09 -0800 Kees Cook wrote:
> This separates ET_DYN ASLR from mmap ASLR, as already done on s390. The
> various architectures that are already randomizing mmap (arm, arm64, mips,
> powerpc, s390, and x86), have their various forms of arch_mmap_rnd()
> made available via th
Add a function that will enable changing the MAC address
of an ibmveth interface while it is still running.
Signed-off-by: Thomas Falcon
---
v3:
removed text wrapping in error message
v2:
If h_change_logical_lan_mac fails, dev->dev_addr will not be changed.
drivers/net/ethernet/ibm/ibmvet
On 02/28/2015 02:59 AM, Jiri Pirko wrote:
> Sat, Feb 28, 2015 at 06:56:04AM CET, tlfal...@linux.vnet.ibm.com wrote:
>> Add a function that will enable changing the MAC address
>> of an ibmveth interface while it is still running.
>>
>> Signed-off-by: Thomas Falcon
>> ---
>> v2:
>> If h_change_lo
Hi Stewart,
Tried to fake ACPI via acpi_bus_generate_netlink_event
and found that
it needs other files which arch specific and use x86 assembly.
Regards,
Vipin
On 02/24/2015 03:14 PM, Vipin K Parashar wrote:
Hi Stewart,
I looked into ACPI and found details about it. Bu
On Thu, Feb 19, 2015 at 03:05:47PM -0500, Martin Hicks wrote:
>
>
> The driver was ignoring limits requested by libata.force. The output
> would look like:
>
> fsl-sata ffe18000.sata: Sata FSL Platform/CSB Driver init
> ata1: FORCE: PHY spd limit set to 1.5Gbps
> ata1: SATA max UDMA/133 irq 74
Hello Scott,
On 03/02/2015 09:32 AM, Emil Medve wrote:
> From: Igal Liberman
>
> Describe the PHY topology for all configurations supported by each board
>
> Based on prior work by Andy Fleming
>
> Change-Id: I4fbcc5df9ee7c4f784afae9dab5d1e78cdc24f0f
Bah, I'll remove this...
> Signed-off-b
From: Igal Liberman
Describe the PHY topology for all configurations supported by each board
Based on prior work by Andy Fleming
Change-Id: I4fbcc5df9ee7c4f784afae9dab5d1e78cdc24f0f
Signed-off-by: Igal Liberman
Signed-off-by: Shruti Kanetkar
Signed-off-by: Emil Medve
---
arch/powerpc/boot/
On 03/02/2015 02:25 PM, Horia Geantă wrote:
> On 2/20/2015 7:00 PM, Martin Hicks wrote:
>> This adds the AES-XTS mode, supported by the Freescale SEC 3.3.2.
>>
>> One of the nice things about this hardware is that it knows how to deal
>> with encrypt/decrypt requests that are larger than sector siz
On 2/20/2015 7:00 PM, Martin Hicks wrote:
> This adds the AES-XTS mode, supported by the Freescale SEC 3.3.2.
>
> One of the nice things about this hardware is that it knows how to deal
> with encrypt/decrypt requests that are larger than sector size, but that
> also requires that that the sector
On Tue, Feb 24, 2015 at 08:36:40PM +0100, Markus Stockhausen wrote:
> This is the assembler code for SHA1 implementation with
> the SIMD SPE instruction set. With the enhanced instruction
> set we can operate on 2 32 bit words in parallel. That helps
> reducing the time to calculate W16-W79. For
From: Yanjiang Jin
The k(un)map function may be called in atomic context in the
function map_and_flush(), so use k(un)map_atomic to replace it,
else we would get the below warning during kdump:
BUG: sleeping function called from invalid context at include/linux/highmem.h:58
in_atomic(): 1, irqs_
On Mon, Mar 02, 2015 at 06:56:19PM +1100, Benjamin Herrenschmidt wrote:
>On Mon, 2015-03-02 at 15:50 +0800, Wei Yang wrote:
>> >
>> >Is there a hotplug remove path where we should also be calling
>> >iommu_free_table()?
>>
>> When VF is not introduced, no one calls this on powernv platform.
>>
>>
On Tue, Feb 24, 2015 at 11:10:33AM -0600, Bjorn Helgaas wrote:
>On Tue, Feb 24, 2015 at 3:00 AM, Bjorn Helgaas wrote:
>> On Tue, Feb 24, 2015 at 02:34:57AM -0600, Bjorn Helgaas wrote:
>>> From: Wei Yang
>>>
>>> On PowerNV platform, resource position in M64 implies the PE# the resource
>>> belongs
38 matches
Mail list logo
