Hi Scott,
I sent V3 of this patch a few days ago.
Comments are welcome.
Thanks.
-Hongtao
> -Original Message-
> From: Jia Hongtao [mailto:hongtao@freescale.com]
> Sent: Thursday, February 26, 2015 3:23 PM
> To: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; asolo...@kb.kras.ru
> C
On Mon, 2015-03-02 at 09:42 -0600, Emil Medve wrote:
> 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: I4fbcc5df9ee7c4f784afae9dab5d
In order to enable SRIOV on PowerNV platform, the PF's IOV BAR needs to be
adjusted:
1. size expanded
2. aligned to M64BT size
This patch documents this change on the reason and how.
[bhelgaas: reformat, clarify, expand]
Signed-off-by: Wei Yang
---
.../powerpc/pci_iov_resource_on_power
In struct pci_dn, the pcidev field is assigned but not used, so remove it.
Signed-off-by: Wei Yang
Acked-by: Gavin Shan
---
arch/powerpc/include/asm/pci-bridge.h |1 -
arch/powerpc/platforms/powernv/pci-ioda.c |1 -
2 files changed, 2 deletions(-)
diff --git a/arch/powerpc/include/
When IOV BAR is big, each is covered by 4 M64 windows. This leads to
several VF PE sits in one PE in terms of M64.
Group VF PEs according to the M64 allocation.
[bhelgaas: use dev_printk() when possible]
Signed-off-by: Wei Yang
---
arch/powerpc/include/asm/pci-bridge.h |2 +-
arch/powe
M64 aperture size is limited on PHB3. When the IOV BAR is too big, this
will exceed the limitation and failed to be assigned.
Introduce a different mechanism based on the IOV BAR size:
- if IOV BAR size is smaller than 64MB, expand to total_pe
- if IOV BAR size is bigger than 64MB, roundup p
On PowerNV platform, resource position in M64 implies the PE# the resource
belongs to. In some cases, adjustment of a resource is necessary to locate
it to a correct position in M64.
Add pnv_pci_vf_resource_shift() to shift the 'real' PF IOV BAR address
according to an offset.
[bhelgaas: rework
Implement pcibios_iov_resource_alignment() on powernv platform.
On PowerNV platform, there are 3 cases for the IOV BAR:
1. initial state, the IOV BAR size is multiple times of VF BAR size
2. after expanded, the IOV BAR size is expanded to meet the M64 segment size
3. sizing stage, the IOV BAR is t
On PHB3, PF IOV BAR will be covered by M64 window to have better PE
isolation. The total_pe number is usually different from total_VFs, which
can lead to a conflict between MMIO space and the PE number.
For example, if total_VFs is 128 and total_pe is 256, the second half of
M64 window will be pa
Current iommu_table of a PE is a static field. This will have a problem
when iommu_free_table() is called.
Allocate iommu_table dynamically.
Signed-off-by: Wei Yang
---
arch/powerpc/include/asm/iommu.h |3 +++
arch/powerpc/platforms/powernv/pci-ioda.c | 26 ++
The PCI config accessors previously relied on device_node. Unfortunately,
VFs don't have a corresponding device_node, so change the accessors to use
pci_dn instead.
[bhelgaas: changelog]
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 14 +-
arch/powerpc/platf
From: Gavin Shan
pci_dn is the extension of PCI device node and is created from device node.
Unfortunately, VFs are enabled dynamically by PF's driver and they don't
have corresponding device nodes, and pci_dn. Refactor pci_dn to support
VFs:
* pci_dn is organized as a hierarchy tree. VF's
Flag PCI_REASSIGN_ALL_RSRC is used to ignore resources information setup by
firmware, so that kernel would re-assign all resources of pci devices.
On powerpc arch, this happens in a header fixup function
pcibios_fixup_resources(), which will clean up the resources if this flag
is set. This works f
When sizing and assigning resources, we divide the resources into two
lists: the requested list and the additional list. We don't consider the
alignment of additional VF(n) BAR space.
This is reasonable because the alignment required for the VF(n) BAR space
is the size of an individual VF BAR, no
Per the SR-IOV spec r1.1, sec 3.3.14, the required alignment of a PF's IOV
BAR is the size of an individual VF BAR, and the size consumed is the
individual VF BAR size times NumVFs.
The PowerNV platform has additional alignment requirements to help support
its Partitionable Endpoint device isolati
VFs are dynamically created when a driver enables them. On some platforms,
like PowerNV, special resources are necessary to enable VFs.
Add platform hooks for enabling and disabling VFs.
Signed-off-by: Wei Yang
---
drivers/pci/iov.c | 19 +++
1 file changed, 19 insertions(+)
On PowerNV, some resource reservation is needed for SR-IOV VFs that don't
exist at the bootup stage. To do the match between resources and VFs, the
code need to get the VF's BDF in advance.
Rename virtfn_bus() and virtfn_devfn() to pci_iov_virtfn_bus() and
pci_iov_virtfn_devfn() and export them.
An SR-IOV device can change its First VF Offset and VF Stride based on the
values of ARI Capable Hierarchy and NumVFs. The number of buses required
for all VFs is determined by NumVFs, First VF Offset, and VF Stride (see
SR-IOV spec r1.1, sec 2.1.2).
Previously pci_iov_bus_range() computed how ma
The First VF Offset and VF Stride fields depend on the NumVFs setting, so
refresh the cached fields in struct pci_sriov when updating NumVFs. See
the SR-IOV spec r1.1, sec 3.3.9 and 3.3.10.
[bhelgaas: changelog, remove kernel-doc comment marker]
Signed-off-by: Wei Yang
---
drivers/pci/iov.c |
From: Bjorn Helgaas
Most of PCI uses "res = &dev->resource[i]", not "res = dev->resource + i".
Use that style in iov.c also.
No functional change.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/iov.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/iov.
Currently we don't store the individual VF BAR size. We calculate it when
needed by dividing the PF's IOV resource size (which contains space for
*all* the VFs) by total_VFs or by reading the BAR in the SR-IOV capability
again.
Keep the individual VF BAR size in struct pci_sriov.barsz[], add
pci_
When we size VF BAR0, VF BAR1, etc., from the SR-IOV Capability of a PF, we
learn the alignment requirement and amount of space consumed by a single
VF. But when VFs are enabled, *each* of the NumVFs consumes that amount of
space, so the total size of the PF resource is "VF BAR size * NumVFs".
Ad
From: Bjorn Helgaas
If we don't have space for all the bus numbers required to enable VFs,
print the largest bus number required and the range available.
No functional change; improved error message only.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/iov.c |7 +--
1 file changed, 5 ins
This patchset enables the SRIOV on POWER8.
The gerneral idea is put each VF into one individual PE and allocate required
resources like MMIO/DMA/MSI. The major difficulty comes from the MMIO
allocation and adjustment for PF's IOV BAR.
On P8, we use M64BT to cover a PF's IOV BAR, which could make
Hi Linus,
Please pull some powerpc fixes for 4.0:
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux.git tags/powerpc-4.0-2
f
* Kees Cook wrote:
> On Mon, Mar 2, 2015 at 11:31 PM, Ingo Molnar wrote:
> >
> > * 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, arm
On Mon, 2015-03-02 at 16:19 -0800, Kees Cook wrote:
> 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. Furt
On Tue, Feb 24, 2015 at 03:00:37AM -0600, 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 to. In some cases, adjustment of a resource is necessary to
In preparation for splitting out ET_DYN ASLR, this refactors the use of
mmap_rnd() to be used similarly to arm and x86, and extracts the checking
of PF_RANDOMIZE.
Signed-off-by: Kees Cook
---
arch/s390/mm/mmap.c | 34 +++---
1 file changed, 23 insertions(+), 11 deleti
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
is available here:
http
In preparation for splitting out ET_DYN ASLR, extract the mmap ASLR
selection into a separate function.
Signed-off-by: Kees Cook
---
arch/mips/mm/mmap.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index f
When an architecture fully supports randomizing the ELF load location,
a per-arch mmap_rnd() function is used to find 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(). Additionall
In preparation for splitting out ET_DYN ASLR, this refactors the use of
mmap_rnd() to be used similarly to arm and x86. This additionally enables
mmap ASLR on legacy mmap layouts, which appeared to be missing on arm64,
and was already supported on arm. Additionally removes a copy/pasted
declaration
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
In preparation for splitting out ET_DYN ASLR, this refactors the use of
mmap_rnd() to be used similarly to arm, and extracts the checking of
PF_RANDOMIZE.
Signed-off-by: Kees Cook
---
arch/x86/mm/mmap.c | 36
1 file changed, 20 insertions(+), 16 deletions(-)
In preparation for splitting out ET_DYN ASLR, this moves the ASLR calculations
for mmap on ARM into a separate routine, similar to x86. This also removes
the redundant check of personality (PF_RANDOMIZE is already set before calling
arch_pick_mmap_layout).
Signed-off-by: Kees Cook
---
arch/arm/m
In preparation for splitting out ET_DYN ASLR, this refactors the use of
mmap_rnd() to be used similarly to arm and x86.
Signed-off-by: Kees Cook
---
Can mmap ASLR be safely enabled in the legacy mmap case here? Other archs
use "mm->mmap_base = TASK_UNMAPPED_BASE + random_factor".
---
arch/powerp
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 in a call to arch_mmap_rnd(). This refactoring results in
the same ET_DYN randomization on s390.
Signed-off-by: Kees Cook
---
arch/s39
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
On 03/03/2015 05:20 PM, Cyril Bur wrote:
> On Tue, 2015-03-03 at 15:15 -0800, Tyrel Datwyler wrote:
>> On 03/02/2015 01:49 PM, Tyrel Datwyler wrote:
>>> 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 upda
On Tue, 2015-03-03 at 15:15 -0800, Tyrel Datwyler wrote:
> On 03/02/2015 01:49 PM, Tyrel Datwyler wrote:
> > 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
> >>> f
On Tue, 3 Mar 2015 08:21:35 -0500
Martin Hicks wrote:
> The submission count was off by one.
>
> Signed-off-by: Martin Hicks
> ---
sadly, this directly contradicts:
commit 4b24ea971a93f5d0bec34bf7bfd0939f70cfaae6
Author: Vishnu Suresh
Date: Mon Oct 20 21:06:18 2008 +0800
crypto: talit
On Tue, 3 Mar 2015 08:21:37 -0500
Martin Hicks wrote:
> @@ -1170,6 +1237,8 @@ static struct talitos_edesc *talitos_edesc_alloc(struct
> device *dev,
>edesc->dma_len,
>DMA_BIDIRECTIONAL);
>
On 03/02/2015 01:49 PM, Tyrel Datwyler wrote:
> 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 t
On 03/02/2015 10:24 PM, Michael Ellerman wrote:
> 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
This patch re-uses hsdev->dev which is allocated on heap. Therefore, the
private structure, which is global variable, is reduced by one field.
In one case ap->dev is used and there it seems to be right decision.
Signed-off-by: Andy Shevchenko
---
drivers/ata/sata_dwc_460ex.c | 23 +++---
On 03/02/2015 10:10 PM, Michael Ellerman wrote:
> 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 f
The SATA implementation based on two actually different devices, i.e. SATA and
DMA controllers.
For Synopsys DesignWare DMA we have already a generic implementation of the
driver. Thus, the patch 1/2 converts the code to use DMAEngine framework and
dw_dmac driver.
In future it will be better to s
The SATA implementation based on two actually different devices, i.e. SATA and
DMA controllers.
For Synopsys DesignWare DMA we have already a generic implementation of the
driver. Thus, the patch converts the code to use DMAEngine framework and
dw_dmac driver.
In future it will be better to split
On 03/02/2015 10:15 PM, Michael Ellerman wrote:
> 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
b
From: Thomas Falcon
Date: Mon, 2 Mar 2015 11:56:12 -0600
> Add a function that will enable changing the MAC address
> of an ibmveth interface while it is still running.
>
> Signed-off-by: Thomas Falcon
Applied, thanks.
___
Linuxppc-dev mailing list
On Thu, Feb 26, 2015 at 05:11:42PM +0100, Christophe Leroy wrote:
> On CPM2, the SPI parameter RAM is dynamically allocated in the dualport RAM
> whereas in CPM1, it is statically allocated to a default address with
> capability to relocate it somewhere else via the use of CPM micropatch.
> The add
On Mon, Mar 2, 2015 at 11:31 PM, Ingo Molnar wrote:
>
> * 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)
On Tue, Mar 3, 2015 at 12:30 AM, Ingo Molnar wrote:
>
> * Kees Cook wrote:
>
>> Most architectures don't need to do anything special for the strict
>> seccomp syscall entries. Remove the redundant headers and reduce the
>> others.
>
>> 19 files changed, 27 insertions(+), 137 deletions(-)
>
> Lov
On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
wrote:
> On 3/3/2015 12:09 AM, Martin Hicks wrote:
>>
>> 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.
>>>
>>>
On 3/3/2015 12:09 AM, Martin Hicks wrote:
>
> 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
I was running into situations where the hardware FIFO was filling up, and
the code was returning EAGAIN to dm-crypt and just dropping the submitted
crypto request.
This adds support in talitos for a software backlog queue. When requests
can't be queued to the hardware immediately EBUSY is returne
This is preparatory work for moving to using the crypto async queue
handling code. A talitos_request structure is buried into each
talitos_edesc so that when talitos_submit() is called, everything required
to defer the submission to the hardware is contained within talitos_edesc.
Signed-off-by: M
The submission count was off by one.
Signed-off-by: Martin Hicks
---
drivers/crypto/talitos.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 89cf4d5..7709805 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/cr
This is properly defined in the md5 header file.
Signed-off-by: Martin Hicks
---
drivers/crypto/talitos.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index c49d977..89cf4d5 100644
--- a/drivers/crypto/talitos.c
I was testing dm-crypt performance with a Freescale P1022 board with
a recent kernel and was getting IO errors while doing testing with LUKS.
Investigation showed that all hardware FIFO slots were filling and
the driver was returning EAGAIN to the block layer, which is not an
expected response for
There were multiple loops in a row, for each separate step of the
initialization of the channels. Simplify to a single loop.
Signed-off-by: Martin Hicks
---
drivers/crypto/talitos.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/talitos.c b/driv
Internally, of_find_node_by_name() calls of_node_put() on its "from"
parameter, which must not be done on "master", as it's still in use, and
will be released manually later. This may cause a zero kref refcount.
Call of_node_get() before to compensate for this.
Signed-off-by: Geert Uytterhoeven
* Kees Cook wrote:
> Most architectures don't need to do anything special for the strict
> seccomp syscall entries. Remove the redundant headers and reduce the
> others.
> 19 files changed, 27 insertions(+), 137 deletions(-)
Lovely cleanup factor.
Just to make sure, are you sure the 32-bit d
Mon, Mar 02, 2015 at 06:56:12PM 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
Reviewed-by: Jiri Pirko
___
Linuxppc-d
65 matches
Mail list logo