On 02/21/2015 12:52 AM, Guenter Roeck wrote:
> On 02/20/2015 12:15 PM, Cedric Le Goater wrote:
>> On 02/20/2015 05:52 PM, Guenter Roeck wrote:
>>> On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
Hello !
These patches rework the ibmpowernv driver to support the new d
On Fri, Feb 20, 2015 at 11:13:33AM -0600, Paul Clarke wrote:
>
> implement arch_irq_work_has_interrupt() for powerpc
>
> (resending because I messed up the e-mail addresses)
>
> Commit 9b01f5bf3 introduced a dependency on "IRQ work self-IPIs" for
> full dynamic ticks to be enabled, by expecting
On 02/20/2015 12:15 PM, Cedric Le Goater wrote:
On 02/20/2015 05:52 PM, Guenter Roeck wrote:
On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
Hello !
These patches rework the ibmpowernv driver to support the new device
tree as proposed by this patchset on the skiboot mailing l
On Tue, Feb 10, 2015 at 07:14:45PM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2015-02-10 at 14:25 +0800, Wei Yang wrote:
> > PF's resource will be assigned first, including normal BARs and IOV
> > BARs.
> >
> > Then PF's driver will create VFs, in virtfn_add(). In this function,
> > VF's
> > r
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 node. Unfortunately, VFs that are enabled dynamically by
> PF's driver and they don't have corresponding device nodes, and
> pci_dn. The patch
On Thu, Jan 15, 2015 at 10:27:51AM +0800, Wei Yang wrote:
> When implementing the SR-IOV on PowerNV platform, some resource reservation
> is needed for VFs which 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.
>
> In this
On 2/18/2015 11:25 PM, Julian Margetson wrote:
On 2/18/2015 10:56 PM, Michael Ellerman wrote:
On Wed, 2015-02-18 at 21:36 -0400, Julian Margetson wrote:
On 2/18/2015 8:13 PM, Michael Ellerman wrote:
On Wed, 2015-02-18 at 15:45 -0400, Julian Margetson wrote:
On 2/15/2015 8:18 PM, Michael Elle
I've just noticed that performance is pretty terrible with maxcpus=1, so
I'll investigate that.
mh
On Fri, Feb 20, 2015 at 11:21 AM, Martin Hicks wrote:
> I was testing dm-crypt performance with a Freescale P1022 board with
> a recent kernel and was getting IO errors while doing testing with LUK
aFrom: Denis Kirjanov
Date: Tue, 17 Feb 2015 10:04:37 +0300
> This patch series enables BPF JIT on ppc32. There are relatevily
> few chnages in the code to make it work.
>
> All test_bpf tests passed both on 7447a and P2041-based machines.
>
> Changelog:
> v1 - > v2: Reordered Kconfig patch in
On 02/20/2015 05:52 PM, Guenter Roeck wrote:
> On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
>> Hello !
>>
>> These patches rework the ibmpowernv driver to support the new device
>> tree as proposed by this patchset on the skiboot mailing list :
>>
>> https://lists.ozlabs.org
On 02/20/2015 05:53 PM, Guenter Roeck wrote:
> On Fri, Feb 20, 2015 at 04:07:35PM +0100, Cédric Le Goater wrote:
>
> You should explain here why this patch is needed.
Yes. What it does is to check that the firmware exposes the service
this driver is using (OPAL_SENSOR_READ). I will fix it.
Thank
Resending to linux-crypto in plain text.
Sorry to everyone else for the duplication.
mh
On Fri, Feb 20, 2015 at 1:23 PM, Martin Hicks wrote:
>
> I've just noticed that performance is pretty terrible with maxcpus=1, so
> I'll investigate that.
> mh
>
> On Fri, Feb 20, 2015 at 11:21 AM, Martin Hick
Use helper functions to access current->state.
Direct assignments are prone to races and therefore buggy.
current->state = TASK_RUNNING can be replaced by __set_current_state()
Thanks to Peter Zijlstra for the exact definition of the problem.
Suggested-By: Peter Zijlstra
Signed-off-by: Fabian F
implement arch_irq_work_has_interrupt() for powerpc
(resending because I messed up the e-mail addresses)
Commit 9b01f5bf3 introduced a dependency on "IRQ work self-IPIs" for
full dynamic ticks to be enabled, by expecting architectures to
implement a suitable arch_irq_work_has_interrupt() rout
implement arch_irq_work_has_interrupt() for powerpc
Commit 9b01f5bf3 introduced a dependency on "IRQ work self-IPIs" for
full dynamic ticks to be enabled, by expecting architectures to
implement a suitable arch_irq_work_has_interrupt() routine.
Several arches have implemented this routine, in
The newer talitos hardware has support for AES in XTS mode.
Signed-off-by: Martin Hicks
---
drivers/crypto/talitos.c | 33 +
drivers/crypto/talitos.h |1 +
2 files changed, 34 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
in
This just cleans up some of the initializers, and improves the comments
should any other ablkcipher modes be added in the future. The header
words 1 and 5 have more possibilities than just passing an IV. These
are pointers to the Cipher Context in/out registers.
Signed-off-by: Martin Hicks
---
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 size be passed into the crypto engine
as an XTS cip
On Fri, Feb 20, 2015 at 04:07:35PM +0100, Cédric Le Goater wrote:
You should explain here why this patch is needed.
> Signed-off-by: Cédric Le Goater
> ---
> arch/powerpc/platforms/powernv/opal-sensor.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/platforms/power
On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
> Hello !
>
> These patches rework the ibmpowernv driver to support the new device
> tree as proposed by this patchset on the skiboot mailing list :
>
> https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html
>
> T
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.
---
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
+++ b/drivers/crypto/talitos.c
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
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
Hello !
These patches rework the ibmpowernv driver to support the new device
tree as proposed by this patchset on the skiboot mailing list :
https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html
They are based on Linux 3.19 and were tested on IBM Power and Open Power
systems r
On Fri, 2015-02-20 at 09:43 -0500, Bob Cochran wrote:
> On 02/05/2015 10:52 AM, Emil Medve wrote:
> > Hello Bob,
> >
> >
> > On 02/05/2015 09:48 AM, Bob Cochran wrote:
> > > On 02/04/2015 09:48 AM, Emil Medve wrote:
> > > >
> > > > Hello,
> > > >
> > > >
> > > > This is the first attempt to pu
On 20/02/2015 16:06, Sebastian Andrzej Siewior wrote:
> On 02/20/2015 03:57 PM, Paolo Bonzini wrote:
>> Yes, but large latencies just mean the code has to be rewritten (x86
>> doesn't anymore do event injection in an atomic regions for example).
>> Until it is, using raw_spin_lock is correct.
>
This patch reworks the ibmpowernv driver to support the new device tree
for sensors exposed by OPAL. It also adds new sensors : the core and
memory buffers DTS.
Hopefully, the proposed framework is good enough to easily add sensors
for other resources such as volts, planar temperatures, etc.
Sign
On 02/20/2015 04:10 PM, Paolo Bonzini wrote:
> On 20/02/2015 16:06, Sebastian Andrzej Siewior wrote:
>> On 02/20/2015 03:57 PM, Paolo Bonzini wrote:
>
>>> Yes, but large latencies just mean the code has to be rewritten (x86
>>> doesn't anymore do event injection in an atomic regions for example).
Currently, when a sensor value is read, the kernel calls OPAL, which in
turn builds a message for the FSP, and waits for a message back. However,
some sensors can be read synchronously (core temperatures for instance)
and don't need to wait for a response.
This patch modifies the opal call to acce
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/powernv/opal-sensor.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/opal-sensor.c
b/arch/powerpc/platforms/powernv/opal-sensor.c
index 4ab67ef7abc9..544292f2020f 100644
--- a/arch/powerpc/platfo
On 02/20/2015 03:57 PM, Paolo Bonzini wrote:
>
>
> On 20/02/2015 15:54, Sebastian Andrzej Siewior wrote:
>> Usually you see "scheduling while atomic" on -RT and convert them to
>> raw locks if it is appropriate.
>>
>> Bogdan wrote in 2/2 that he needs to limit the number of CPUs in oder
>> not ca
On 20/02/2015 15:54, Sebastian Andrzej Siewior wrote:
> Usually you see "scheduling while atomic" on -RT and convert them to
> raw locks if it is appropriate.
>
> Bogdan wrote in 2/2 that he needs to limit the number of CPUs in oder
> not cause a DoS and large latencies in the host. I haven't se
On 02/20/2015 03:12 PM, Paolo Bonzini wrote:
>> Thomas, what is the usual approach for patches like this? Do you take
>> them into your rt tree or should they get integrated to upstream?
>
> Patch 1 is definitely suitable for upstream, that's the reason why we
> have raw_spin_lock vs. raw_spin_unl
On 02/05/2015 10:52 AM, Emil Medve wrote:
Hello Bob,
On 02/05/2015 09:48 AM, Bob Cochran wrote:
On 02/04/2015 09:48 AM, Emil Medve wrote:
Hello,
This is the first attempt to publish the Freescale DPAA B/QMan
drivers. They are
not to be applied yet. At this stage, this is more or less the
On 20.02.15 15:12, Paolo Bonzini wrote:
>
>
> On 20/02/2015 14:45, Alexander Graf wrote:
>>
>>
>> On 18.02.15 10:32, Bogdan Purcareata wrote:
>>> This patchset enables running KVM SMP guests with external interrupts on an
>>> underlying RT-enabled Linux. Previous to this patch, a guest with in-
On 20/02/2015 14:45, Alexander Graf wrote:
>
>
> On 18.02.15 10:32, Bogdan Purcareata wrote:
>> This patchset enables running KVM SMP guests with external interrupts on an
>> underlying RT-enabled Linux. Previous to this patch, a guest with in-kernel
>> MPIC
>> emulation could easily panic the
On 18.02.15 10:32, Bogdan Purcareata wrote:
> This patchset enables running KVM SMP guests with external interrupts on an
> underlying RT-enabled Linux. Previous to this patch, a guest with in-kernel
> MPIC
> emulation could easily panic the kernel due to preemption when delivering IPIs
> and ex
On 18.02.15 10:32, Bogdan Purcareata wrote:
> Due to the introduction of the raw_spinlock for the KVM openpic, guests with a
> high number of VCPUs may induce great latencies on the underlying RT Linux
> system (e.g. cyclictest reports latencies of ~15ms for guests with 24 VCPUs).
> This can be f
C99 says that a precision given as simply '.' with no following digits
or * should be interpreted as 0. The kernel's printf implementation,
however, treats this case as if the precision was omitted. C99 also
says that if both the precision and value are 0, no digits should be
printed. Even if the k
Some drivers try to use a 64-bit dma_mask and a smaller (32-bit typically)
coherent dma mask.
We don't currently support that on platforms that do direct DMA
because:
- We use the generic dma_set_coherent_mask()
- It will use dma_supported() with the provided mask
- Our imlpementation of the
We don't initialize it, we don't use it, remove it.
We can bring it back if we ever wish to have support for devices
who have smaller than 32-bit DMA limitations but I don't think
we care much anymore.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/Kconfig |2 +-
arch/powerpc/k
We do this for consistency and also in order to support the use of a
consistent mask smaller than the dma mask in subsequent patches.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/dma-swiotlb.c | 3 ---
arch/powerpc/mm/mem.c | 6 ++
2 files changed, 6 insertions(+
45 matches
Mail list logo
