From: Ian Munsie
commit 0712dc7e73e59d79bcead5d5520acf4e9e917e87 upstream.
for the 3.18 stable series
An issue was introduced with "cxl: Unmap MMIO regions when detaching a
context" (b123429e6a9e8d03aacf888d23262835f0081448) where closing a
context normally could also unmap the problem state are
Excerpts from Greg KH's message of 2015-02-25 11:32:29 +1100:
> What stable kernel(s) are you wanting this series to go into?
Hi Greg,
These three patches are for 3.18 and 3.19.
Cheers,
-Ian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
On Tue, 2015-02-24 at 10:38 +0100, Geert Uytterhoeven wrote:
> Hi Michael,
>
> On Tue, Feb 24, 2015 at 5:52 AM, Michael Ellerman wrote:
> >> > + error: book3s_64_vio_hv.c: undefined reference to
> >> > `power7_wakeup_loss': => .text+0x408)
> >>
> >> pseries_defconfig
> >
> > This one is actua
On Wed, 2015-02-04 at 14:47 +0800, Dongsheng Wang wrote:
> +void ppc_md_fixup(void)
> +{
This name is way too generic (though it's moot since you shouldn't use
ppc_md for this).
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,fpga-qixis");
> + if (!np
On Mon, 2015-02-02 at 00:53 -0600, Emil Medve wrote:
> From: Kumar Gala
>
> Change-Id: If643fa5ba0a903aef8f5056a2c90ebecc995b760
Remove these.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linux
On Sun, 2015-02-01 at 15:48 -0600, Emil Medve wrote:
> From: Andy Fleming
>
> Change-Id: I4489db79957ad533f4ba3f04fe7d5bcb3288e981
Again, remove these.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listi
On Tue, 2015-01-20 at 04:09 -0600, Emil Medve wrote:
> Where the memset() is not necessary
>
> Signed-off-by: Emil Medve
> ---
> drivers/clk/clk-ppc-corenet.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc-corenet.c
>
On Tue, 2015-01-20 at 04:09 -0600, Emil Medve wrote:
> Change-Id: I1a80ad7b9f6854791bd270b746f93a91439155a6
> Signed-off-by: Emil Medve
No Change-Id, and don't bundle patches meant for my tree in the same
patchset as patches meant for other trees. There's no dependency
between them.
-Scott
__
On Mon, Feb 23, 2015 at 03:21:19PM +1100, Michael Ellerman wrote:
> From: Ryan Grimm
>
> Commit 4beb5421babee1204757b877622830c6aa31be6d upstream.
>
> Select defaults such that a PERST causes flash image reload. Select which
> image based on what the card is set up to load.
>
> CXL_VSEC_PERST_
On Wed, 2015-02-25 at 07:40 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2015-02-24 at 14:34 -0600, Scott Wood wrote:
> > On Fri, 2015-02-20 at 19:35 +1100, Benjamin Herrenschmidt wrote:
> > > static u64 dma_direct_get_required_mask(struct device *dev)
> > > diff --git a/arch/powerpc/mm/mem.c b/
On Tue, 2015-02-24 at 10:37 -0600, Suresh E. Warrier wrote:
> On 02/23/2015 09:38 PM, Benjamin Herrenschmidt wrote:
> > On Mon, 2015-02-23 at 18:10 -0600, Suresh E. Warrier wrote:
> >> Export __spin_yield so that the arch_spin_unlock() function
> >> can be invoked from a module.
> >
> > Make it EX
On Fri, 2015-02-20 at 19:35 +1100, Benjamin Herrenschmidt wrote:
> @@ -149,14 +141,13 @@ static void dma_direct_unmap_sg(struct device *dev,
> struct scatterlist *sg,
>
> static int dma_direct_dma_supported(struct device *dev, u64 mask)
> {
> -#ifdef CONFIG_PPC64
> - /* Could be improved s
Thanks
after skipping several times :
git bisect skip
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
b486e0e6d599b9ca8667fb9a7d49b7383ee963c7
eab3bbeffd152125ae0f90863b8e9bc8eef49423
960cd9d4fef6dd9e235c0e5c0d4ed027f8a48025
f02ad907cd9e7fe3a6405d2d005840912
On Tue, 2015-02-24 at 14:34 -0600, Scott Wood wrote:
> On Fri, 2015-02-20 at 19:35 +1100, Benjamin Herrenschmidt wrote:
> > @@ -149,14 +141,13 @@ static void dma_direct_unmap_sg(struct device *dev,
> > struct scatterlist *sg,
> >
> > static int dma_direct_dma_supported(struct device *dev, u64 m
On 2/20/2015 6:21 PM, Martin Hicks wrote:
> 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
[PATCH v1 3/3] SHA1 for PPC/SPE - kernel config
Integrate the module into the kernel config tree.
Signed-off-by: Markus Stockhausen
diff --git a/arch/powerpc/crypto/Makefile b/arch/powerpc/crypto/Makefile
index 1698fb9..d400bf9 100644
--- a/arch/powerpc/crypto/Makefile
+++ b/arch/powerpc/crypto
[PATCH v1 2/3] SHA1 for PPC/SPE - glue
Glue code for crypto infrastructure. Call the assembler
code where required. Disable preemption during calculation
and enable SPE instructions in the kernel prior to the
call. Avoid to disable preemption for too long.
Take a little care about small input da
[PATCH v1 0/3] SHA1 for PPC/SPE
The following patches add support for SIMD accelerated SHA1
calculation on PPC processors with SPE instruction set. The
implementation takes care of the following constraints:
- independant of processor endianess
- save SPE registers for interrupt context compatib
[PATCH v1 1/3] SHA1 for PPC/SPE - assembler
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 increasing
performance even mo
Am 2015-02-24 um 12:08 schrieb Julian Margetson:
> Problems with the Gib bisect
> Kernel wont compile after 10th bisect .
You can try "git bisect skip" to select another commit for testing.
Hopefully that one compiles fine then.
Gerhard
> drivers/built-in.o: In function `drm_mode_atomic_ioctl':
On 2/24/2015 7:10 AM, Julian Margetson wrote:
Problems with the Gib bisect
Kernel wont compile after 10th bisect .
drivers/built-in.o: In function `drm_mode_atomic_ioctl':
(.text+0x865dc): undefined reference to `__get_user_bad'
make: *** [vmlinux] Error 1
root@julian-VirtualBox:/usr/src/linux#
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 to. In some cases, adjustment of a resource is necessary to locate
On 02/23/2015 09:38 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2015-02-23 at 18:10 -0600, Suresh E. Warrier wrote:
>> Export __spin_yield so that the arch_spin_unlock() function
>> can be invoked from a module.
>
> Make it EXPORT_SYMBOL_GPL. Also explain why a module might need it
>
Sure, I wil
On Mon, Jan 19, 2015 at 04:05:15PM +0100, Wolfram Sang wrote:
>
> > > + struct i2c_adapter_quirks *quirks;
> > > };
> > > #define to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev)
> > >
> >
> > I suggest to add const.
> > const struct i2c_adapter_quirks *quirks;
> >
> > also, in
On Mon, Jan 12, 2015 at 12:08:14PM +, Russell King - ARM Linux wrote:
> On Fri, Jan 09, 2015 at 06:21:32PM +0100, Wolfram Sang wrote:
> > +static int i2c_quirk_error(struct i2c_adapter *adap, struct i2c_msg *msg,
> > char *err_msg)
> > +{
> > + dev_err(&adap->dev, "quirk: %s (addr 0x%04x, si
> > + if (msgs[i].flags & I2C_M_RD) {
> > + if (i2c_quirk_exceeded(len, max_read))
> > + return i2c_quirk_error(adap, &msgs[i], "msg
> > too long");
> > + } else {
> > + if (i2c_quirk_exceeded(le
Problems with the Gib bisect
Kernel wont compile after 10th bisect .
drivers/built-in.o: In function `drm_mode_atomic_ioctl':
(.text+0x865dc): undefined reference to `__get_user_bad'
make: *** [vmlinux] Error 1
root@julian-VirtualBox:/usr/src/linux# git bisect log
git bisect start
# bad: [c517d83
On Tue, Feb 24, 2015 at 01:39:46AM -0800, Arjan van de Ven wrote:
> one of the question is if you want to serialize, or if you just want
> to label. If you take a cookie (could just be a monotonic increasing
> number) at the start of the oops and then prefix/postfix the stack
> printing with that
I had a hanging Uboot problem with a Sam440ep board.Never figured the problem
out but
It workedd for another two years after the problems began. Died for good last
September with the hanging becoming a daily issue.
Dont think that it was overheating. I thought that it could have been a problem
From: Ingo Molnar
...
> So why not trylock and time out here after a few seconds,
> instead of indefinitely supressing some potentially vital
> output due to some other CPU crashing/locking with the lock
> held?
I've used that for status requests that usually lock a table
to get a consistent view.
Hi Stewart,
I looked into ACPI and found details about it. But before we
go into
discussing more details of it, would like to share a brief about OPAL
platform
events (EPOW/DPO) work and original design proposed.
As if now OPAL platform events work supports two events:
EPOW (Early Po
>> Some architectures already have their own recursive
>> locking for oopses and we have another version for
>> serialising dump_stack.
>>
>> Create a common version and use it everywhere (oopses,
>> BUGs, WARNs, dump_stack, soft lockups and hard lockups).
>
> Dunno. I've had cases where the simult
Hi Michael,
On Tue, Feb 24, 2015 at 5:52 AM, Michael Ellerman wrote:
>> > + error: book3s_64_vio_hv.c: undefined reference to
>> > `power7_wakeup_loss': => .text+0x408)
>>
>> pseries_defconfig
>
> This one is actually from pseries_defconfig+POWERNV=n, so I think I
Thanks!
> broke your scrip
On Tue, Feb 24, 2015 at 02:35:04AM -0600, Bjorn Helgaas wrote:
> From: Wei Yang
>
> 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
Drop unused fsl_mpic_primary_get_version(), mpic_set_clk_ratio(),
mpic_set_serial_int().
+ fsl_mpic_primary_get_version() is just a safe wrapper around
fsl_mpic_get_version() for SMP configurations. While the latter is
called explicitly for handling PIC initialization and setting up error
interr
Drop ucc_slow_poll_transmitter_now() which has no users since its
inception in 2007 in commit 986585385131 ("[POWERPC] Add QUICC
Engine (QE) infrastructure").
Signed-off-by: Arseny Solokha
---
arch/powerpc/include/asm/ucc_slow.h | 13 -
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 5 --
Drop unused static procedure which doesn't have callers within its
translation unit. It had been already removed independently in QEMU[1]
from the OpenPIC implementation borrowed from the kernel.
[1] https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg01812.html
Signed-off-by: Arseny Solokha
This series removes unused functions from powerpc tree that I've been
able to discover.
Two machines at hands, e300 and e500 based, boot and run without
regressions on my workload with this series applied. The removed code
seems also been rarely touched, so it seems the series is safe at least
in
Drop planetcore_set_serial_speed() which had no users since its
inception in commit fec6047047fd ("[POWERPC] bootwrapper: Add PlanetCore
firmware support") in 2007.
Signed-off-by: Arseny Solokha
---
arch/powerpc/boot/planetcore.c | 33 -
arch/powerpc/boot/planetco
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 locate
> it to a correct position in M64.
>
> Add pnv_pci_vf_resou
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 locate
> it to a correct position in M64.
>
> Add pnv_pci_vf_resou
On Tue, Feb 24, 2015 at 02:34:42AM -0600, Bjorn Helgaas wrote:
> From: Wei Yang
>
> 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.
>
>
On Tue, Feb 24, 2015 at 02:34:35AM -0600, Bjorn Helgaas wrote:
> From: Wei Yang
>
> 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.
I'd like a little more explanation about why we're calling
iomm
On Tue, Feb 24, 2015 at 02:34:13AM -0600, Bjorn Helgaas wrote:
> From: Wei Yang
>
> If we're going to reassign resources with flag PCI_REASSIGN_ALL_RSRC, all
> resources will be cleaned out during device header fixup time and then get
> reassigned by PCI core. However, the VF resources won't be
On Tue, Feb 24, 2015 at 02:33:52AM -0600, Bjorn Helgaas wrote:
> From: Wei Yang
>
> 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
On Tue, Feb 24, 2015 at 02:34:06AM -0600, Bjorn Helgaas wrote:
> From: Wei Yang
>
> 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
From: Wei Yang
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
Signed-off-by: Bjorn Helg
From: Wei Yang
In struct pci_dn, the pcidev field is assigned but not used, so remove it.
Signed-off-by: Wei Yang
Signed-off-by: Bjorn Helgaas
Acked-by: Gavin Shan
---
arch/powerpc/include/asm/pci-bridge.h |1 -
arch/powerpc/platforms/powernv/pci-ioda.c |1 -
2 files changed, 2 d
From: Wei Yang
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
Signed-off-by: Bjorn Helgaas
---
arch/powerpc/in
From: Wei Yang
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 tha
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 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.
[
From: Wei Yang
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,
From: Wei Yang
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
From: Wei Yang
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
Signed-off-by: Bjorn Helgaas
---
arch/powerpc/include/asm/iommu.h |3 +++
arch/powerpc/platforms/p
From: Wei Yang
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
Signed-off-by: Bjorn Helgaas
---
arch/powerpc/platforms/powernv/
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
From: Wei Yang
If we're going to reassign resources with flag PCI_REASSIGN_ALL_RSRC, all
resources will be cleaned out during device header fixup time and then get
reassigned by PCI core. However, the VF resources won't be reassigned and
thus, we shouldn't clean them out.
If the pci_dev is a VF
From: Wei Yang
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 indi
From: Wei Yang
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 Endpoi
From: Wei Yang
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
Signed-off-by: Bjorn Helgaas
---
drivers/pci/iov.c | 19 +++
From: Wei Yang
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()
From: Wei Yang
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(
From: Wei Yang
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
Signed-of
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.c b/drivers/pci/iov.c
From: Wei Yang
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.
From: Wei Yang
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 si
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 insertions(+), 2 deletion
Wei Yang's most recent POWER8 SR-IOV patchset was v11, posted on Jan 15,
2015.
I'm having a hard time keeping everything straight between the tweaks I've
made on my branch and incremental updates. I think it's easier to repost
the whole series so one can easily collect everything that goes togeth
On Tue, 2015-02-24 at 02:13 -0600, Bjorn Helgaas wrote:
>
> Ah, yes, now I see the problem. I don't really like having to export
> pci_iov_virtfn_bus() and pci_iov_virtfn_devfn(), but it's probably not
> worth the hassle of changing it, and I think adding more pcibios
> interfaces
> would be even
On Mon, Feb 23, 2015 at 11:13:49AM +1100, Gavin Shan wrote:
> On Fri, Feb 20, 2015 at 05:19:17PM -0600, Bjorn Helgaas wrote:
> >On Thu, Jan 15, 2015 at 10:27:58AM +0800, Wei Yang wrote:
> >> From: Gavin Shan
> >>
> >> pci_dn is the extension of PCI device node and it's created from
> >> device no
70 matches
Mail list logo