Around Thu 02 Jun 2016 17:39:46 +0200 or thereabout, Krzysztof Kozlowski wrote:
> After switching DMA attributes to unsigned long it is easier to just
> compare the bits.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> Documentation/DMA-API.txt | 4 +--
> arch/arc/mm/dma.c
Around Thu 02 Jun 2016 17:39:09 +0200 or thereabout, Krzysztof Kozlowski wrote:
> Split out subsystem specific changes for easier reviews. This will be
> squashed with main commit.
>
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Hans-Christian Noren Egtvedt
> ---
> arch/avr32/mm/dma-coherent
On 2016/6/6 4:10, kbuild test robot wrote:
Hi,
[auto build test ERROR on vfio/next]
[also build test ERROR on v4.7-rc1 next-20160603]
[cannot apply to pci/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-
On 2016/6/6 5:11, kbuild test robot wrote:
Hi,
[auto build test ERROR on vfio/next]
[also build test ERROR on v4.7-rc1 next-20160603]
[cannot apply to pci/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-
On 06/03/2016 03:56 AM, Cyril Bur wrote:
> On 1 June 2016 at 18:26, Anshuman Khandual
> wrote:
>
>> On 05/31/2016 04:42 AM, Michael Ellerman wrote:
>>> Hi Laurent,
>>>
>>> Sorry no. My next branch closed for 4.7 about 3 weeks ago.
>>>
>>> This series has been blocked for a long time on the gdb su
On 6/5/2016 10:00 PM, Michael Ellerman wrote:
On Sun, 2016-06-05 at 21:23 -0400, Julian Margetson wrote:
drivers/gpu/drm/drm_vm.c: In function ‘drm_dma_prot’:
drivers/gpu/drm/drm_vm.c:83:6: error: invalid operands to binary |
(have ‘pgprot_t {aka struct }’ and ‘int’)
tmp |= _
On Fri, 2016-03-06 at 03:49:48 UTC, Boqun Feng wrote:
> diff --git a/arch/powerpc/include/asm/spinlock.h
> b/arch/powerpc/include/asm/spinlock.h
> index 523673d7583c..2ed893662866 100644
> --- a/arch/powerpc/include/asm/spinlock.h
> +++ b/arch/powerpc/include/asm/spinlock.h
> @@ -64,6 +64,25 @@ st
From: Boqun Feng
There is an ordering issue with spin_unlock_wait() on powerpc, because
the spin_lock primitive is an ACQUIRE and an ACQUIRE is only ordering
the load part of the operation with memory operations following it.
Therefore the following event sequence can happen:
CPU 1
On 04/06/16 02:07, Scott Wood wrote:
On Mon, 2016-05-09 at 10:29 +0200, Sebastian Huber wrote:
Hello,
the "fman" Ethernet driver was integrated in mainline Linux Dezember
2015 ("drivers/net/ethernet/freescale/fman"). It seems that the other
parts, e.g. BMan, QMan ("drivers/soc/fsl/qbman") and b
On Mon, Jun 06, 2016 at 09:42:20PM +1000, Michael Ellerman wrote:
> +static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
> +{
> + arch_spinlock_t lock_val;
> +
> + smp_mb();
> +
> + /*
> + * Atomically load and store back the lock value (unchanged). This
> + * ensu
On Monday, June 06, 2016 09:22:31 AM Viresh Kumar wrote:
> On 03-06-16, 16:48, Steve Muckle wrote:
> > On Fri, Jun 03, 2016 at 07:05:14PM +0530, Viresh Kumar wrote:
> > ...
> > > @@ -468,20 +469,15 @@ unsigned int acpi_cpufreq_fast_switch(struct
> > > cpufreq_policy *policy,
> > > struct acpi_cp
On Mon, 2016-06-06 at 13:56 +0200, Peter Zijlstra wrote:
> On Mon, Jun 06, 2016 at 09:42:20PM +1000, Michael Ellerman wrote:
> > +static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
> > +{
> > + arch_spinlock_t lock_val;
> > +
> > + smp_mb();
> > +
> > + /*
> > +* Atomically l
On 6 June 2016 at 17:40, Rafael J. Wysocki wrote:
> On Monday, June 06, 2016 09:22:31 AM Viresh Kumar wrote:
>> I agree with that, though that requires larger changes across multiple
>> sites.
>
> What changes and where?
s/larger/some :)
So we can change all the callers of cpufreq_frequency_tab
On Mon, 2016-06-06 at 10:52 +0300, Denis Kirjanov wrote:
> Update: now with the proper mailing address.
>
> Hi,
>
> Posting if anyone knows how to quickly fix it :)
Sorry but no.
> Enabling CONFIG_PPC_EARLY_DEBUG on my quad G5 causes kernel to die
> with the unrecoverable exception 4100.
Th
On Mon, Jun 6, 2016 at 2:24 PM, Viresh Kumar wrote:
> On 6 June 2016 at 17:40, Rafael J. Wysocki wrote:
>> On Monday, June 06, 2016 09:22:31 AM Viresh Kumar wrote:
>
>>> I agree with that, though that requires larger changes across multiple
>>> sites.
>>
>> What changes and where?
>
> s/larger/so
SEC1 doesn't have IPSEC_ESP descriptor type but it is able to perform
IPSEC using HMAC_SNOOP_NO_AFEU, which is also existing on SEC2
In order to be able to define descriptors templates for SEC1 without
breaking SEC2+, we have to give lower priority to HMAC_SNOOP_NO_AFEU
so that SEC2+ selects IPSEC_
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 4ff03c3..ff8cf39 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -,14 +,6 @@ next:
This set of patches provides the implementation of AEAD for
talitos SEC1.
Changes in v2:
* Fixed compilation issue introduced by later cosmetic changes
requested by checkpatch script
* split "making mapping helpers more generic" in two parts
to better see the changes done after the move.
* reworke
In preparation of IPSEC for SEC1, first step is to make the mapping
helpers more generic so that they can also be used by AEAD functions.
First, the functions are moved before IPSEC functions in talitos.c
talitos_sg_unmap() and unmap_sg_talitos_ptr() are merged as they
are quite similar, the seco
This patchs enhances the IPSEC_ESP related functions for them to
also supports the same operations with descriptor type
HMAC_SNOOP_NO_AFEU.
The differences between the two descriptor types are:
* pointeurs 2 and 3 are swaped (Confidentiality key and
Primary EU Context IN)
* HMAC_SNOOP_NO_AFEU
Use helper for all modifications to talitos_ptr in preparation to
the implementation of AEAD for SEC1
to_talitos_ptr_extent_clear() has been removed in favor of
to_talitos_ptr_ext_set() to set any value and
to_talitos_ptr_ext_or() to or the extent field with a value
name has been shorten to help k
In order to be able to use the mapping/unmapping helpers for IPSEC
it needs to be move upper in the file
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 244 +++
1 file changed, 122 insertions(+), 122 deletions(-)
diff --git a/drivers/c
This will allow IPSEC on SEC1
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 180 +++
1 file changed, 180 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index dfd3a93..0418a2f 100644
--- a/drivers/crypto
On Fri, Jun 03, 2016 at 02:57:33PM +0800, Jia Hongtao wrote:
> For different types of SoC the sensor id and endianness may vary.
> "#thermal-sensor-cells" is used to provide sensor id information.
> "little-endian" property is to tell the endianness of TMU.
>
> Signed-off-by: Jia Hongtao
> ---
>
On Thu 2016-04-28 15:44:48, Josh Poimboeuf wrote:
> Change livepatch to use a basic per-task consistency model. This is the
> foundation which will eventually enable us to patch those ~10% of
> security patches which change function or data semantics. This is the
> biggest remaining piece needed
On Mon, Jun 06, 2016 at 03:54:41PM +0200, Petr Mladek wrote:
> On Thu 2016-04-28 15:44:48, Josh Poimboeuf wrote:
> > Change livepatch to use a basic per-task consistency model. This is the
> > foundation which will eventually enable us to patch those ~10% of
> > security patches which change funct
On Mon, Jun 06, 2016 at 10:17:25PM +1000, Michael Ellerman wrote:
> On Mon, 2016-06-06 at 13:56 +0200, Peter Zijlstra wrote:
> > On Mon, Jun 06, 2016 at 09:42:20PM +1000, Michael Ellerman wrote:
> > > +static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
> > > +{
> > > + arch_spinlock_t
On Fri, Jun 03, 2016 at 02:33:47PM +1000, Benjamin Herrenschmidt wrote:
> - For the above, can you show (or describe) where the qspinlock
> improves things compared to our current locks.
So currently PPC has a fairly straight forward test-and-set spinlock
IIRC. You have this because LPAR/virt
On 6 June 2016 at 18:27, Rafael J. Wysocki wrote:
> On Mon, Jun 6, 2016 at 2:24 PM, Viresh Kumar wrote:
>> On 6 June 2016 at 17:40, Rafael J. Wysocki wrote:
>>> On Monday, June 06, 2016 09:22:31 AM Viresh Kumar wrote:
>>
I agree with that, though that requires larger changes across multiple
From: Michael Ellerman
We're approaching 20 locations where we need to check for ELF ABI v2.
That's fine, except the logic is a bit awkward, because we have to check
that _CALL_ELF is defined and then what its value is.
So check it once in asm/types.h and define PPC64_ELF_ABI_v2 when ELF ABI
v2
Because of an improper dereference, a stray 'C' character was output to
the modalias when no 'compatible' was specified. This is the case for
some old PowerMac drivers which only set the 'name' property. Fix it to
let them match again.
Reported-by: Mathieu Malaterre
Signed-off-by: Wolfram Sang
T
On Mon, Jun 6, 2016 at 6:25 PM, Viresh Kumar wrote:
> On 6 June 2016 at 18:27, Rafael J. Wysocki wrote:
>> On Mon, Jun 6, 2016 at 2:24 PM, Viresh Kumar wrote:
>>> On 6 June 2016 at 17:40, Rafael J. Wysocki wrote:
On Monday, June 06, 2016 09:22:31 AM Viresh Kumar wrote:
>>>
> I agree wi
On 06/02/2016 08:45 AM, Mauricio Faria de Oliveira wrote:
Export cpu_to_core_id(). This will be used by the lpfc driver.
This enables topology_core_id() from (defined
to cpu_to_core_id() in arch/powerpc/include/asm/topology.h) to be
used by (non-builtin) modules.
That is arch-neutral, alread
On Mon, 2016-06-06 at 17:59 +0200, Peter Zijlstra wrote:
> On Fri, Jun 03, 2016 at 02:33:47PM +1000, Benjamin Herrenschmidt wrote:
> >
> > - For the above, can you show (or describe) where the qspinlock
> > improves things compared to our current locks.
> So currently PPC has a fairly straight
> -邮件原件-
> 发件人: Rob Herring [mailto:r...@kernel.org]
> 发送时间: Monday, June 06, 2016 9:47 PM
> 收件人: Hongtao Jia
> 抄送: edubez...@gmail.com; rui.zh...@intel.com; ga...@codeaurora.org;
> Scott Wood ; shawn...@kernel.org;
> devicet...@vger.kernel.org; linux...@vger.kernel.org; linux-
> ker...@v
On Mon, 2016-25-04 at 16:19:17 UTC, Khem Raj wrote:
> gcc-6 correctly warns about a out of bounds access
>
> arch/powerpc/kernel/ptrace.c:407:24: warning: index 32 denotes an offset
> greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}'
> [-Warray-bounds]
> offsetof(stru
On Wed, 2016-25-05 at 23:56:07 UTC, Gavin Shan wrote:
> In commit <8445a87f7092> ("powerpc/iommu: Remove the dependency
> on EEH struct in DDW mechanism"), the PE address was replaced
> with the PCI config address in order to remove dependency on EEH.
> According to PAPR spec, firmware (pHyp or QEM
For different types of SoC the sensor id and endianness may vary.
"#thermal-sensor-cells" is used to provide sensor id information.
"little-endian" property is to tell the endianness of TMU.
Signed-off-by: Jia Hongtao
---
Changes for V2:
* Remove formatting chnages.
Documentation/devicetree/bin
On 06-06-16, 23:56, Rafael J. Wysocki wrote:
> Since you are adding new code, you can write it so it doesn't do
> unnecessary checks from the start.
Hmm, I will do all that in this series only now.
> While at it, the "if ((freq < policy->min) || (freq > policy->max))"
> checks in cpufreq_find_ind
xinhui writes:
>> Has it always been broken?
>>
>
> no. after nvram partition corruption hit, all nvram partitions will be
> erased and re-alloc after the second machine reboot.
> I don't know who does it but i guess it is the firmware. :)
It is. PAPR says we format NVRAM when it's corrupted. Thi
40 matches
Mail list logo
