Dongsheng Wang writes:
> From: Wang Dongsheng
>
> This issue caused on 'commit 990486c8af04 ("strscpy: zero any trailing
> garbage bytes in the destination")'.
>
> zero_bytemask is not implemented on PowerPC. So copy the zero_bytemask
> of BIG_ENDIAN implementation from include/asm-generic/word-
Hi Peter,
Sorry for replying late.
On Thu, Oct 01, 2015 at 02:27:16PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 16, 2015 at 11:49:33PM +0800, Boqun Feng wrote:
> > Unlike other atomic operation variants, cmpxchg{,64}_acquire and
> > atomic{,64}_cmpxchg_acquire don't have acquire semantics if the
The provides memblock_is_memory() function that
tries to find a given physical address in the memblock.memory.regions.
Let's use this function instead of direct coding of the same functionality.
Signed-off-by: Alexander Kuleshov
---
arch/powerpc/mm/mem.c | 6 ++
1 file changed, 2 insertions
When configuring the MDIO subsystem it is also necessary to configure
the TBI register. Make sure the TBI is contained within the mapped
register range in order to:
a) make sure the address is computed correctly
b) make users aware that we're actually accessing that register
In case of error, prin
commit afae5ad78b342f401c28b0bb1adb3cd494cb125a
"net/fsl_pq_mdio: streamline probing of MDIO nodes"
added support for different types of MDIO devices:
1) Gianfar MDIO nodes that only map the MII registers
2) Gianfar MDIO nodes that map the full MDIO register set
3) eTSEC2 MDIO nodes (which map t
Hi Linus,
On Wed, 7 Oct 2015 20:27:38 -0400 Chris Metcalf wrote:
>
> On 10/7/2015 6:44 PM, Stephen Rothwell wrote:
> >
> > After merging Linus' tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > lib/string.c: In function 'strscpy':
> > lib/string.c:209:4: error
On Thu, 2015-10-01 at 19:26 -0500, Scott Wood wrote:
> [Resending to updated e-mail address]
>
> On Tue, 2015-08-11 at 11:25 -0700, Michael Turquette wrote:
> > Hi Scott,
> >
> > Quoting Scott Wood (2015-06-18 19:49:10)
> > > The existing device tree bindings are error-prone and inflexible.
> >
Hi Geoff,
Am Freitag, 9. Oktober 2015, 10:45:42 schrieb Geoff Levand:
> Hi Marc,
>
> On Thu, 2015-10-08 at 11:10 -0700, Geoff Levand wrote:
> > > On Mon, 2015-10-05 at 12:27 +0200, Marc Dietrich wrote:
> > > > > I tried with ps3-queue and still no luck. Petitboot just says
> > > > > "Booting kern
On Fri, Oct 09, 2015 at 10:43:27AM -0700, Paul E. McKenney wrote:
> On Fri, Oct 09, 2015 at 10:51:29AM +0100, Will Deacon wrote:
> > How do people feel about including these in memory-barriers.txt? I find
> > them considerably easier to read than our current kernel code + list of
> > possible order
Hi Marc,
On Thu, 2015-10-08 at 11:10 -0700, Geoff Levand wrote:
> > On Mon, 2015-10-05 at 12:27 +0200, Marc Dietrich wrote:
> > > > I tried with ps3-queue and still no luck. Petitboot just says
> > > > "Booting kernel
> > > > ..." thats all - no output.
> > > >
> > > > FW is 3.15 of course
> > >
On Fri, Oct 09, 2015 at 10:51:29AM +0100, Will Deacon wrote:
> Hi Paul,
>
> On Thu, Oct 08, 2015 at 03:17:16PM -0700, Paul E. McKenney wrote:
> > On Thu, Oct 08, 2015 at 01:59:38PM +0100, Will Deacon wrote:
> > > I thought Paul was talking about something like this case:
> > >
> > > CPU A CPU
On Fri, Oct 09, 2015 at 01:25:54PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2015 at 10:51:29AM +0100, Will Deacon wrote:
> > > The corresponding litmus tests are below.
> >
> > How do people feel about including these in memory-barriers.txt? I find
> > them considerably easier to read than o
Hi Gerlando,
[auto build test WARNING on net/master -- if it's inappropriate base, please
ignore]
config: powerpc-tqm8541_defconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chm
On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote:
> On Fri, Oct 09, 2015 at 10:31:38AM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 08, 2015 at 02:44:39PM -0700, Paul E. McKenney wrote:
> > > On Thu, Oct 08, 2015 at 01:16:38PM +0200, Peter Zijlstra wrote:
> > > > On Thu, Oct 08, 2015 at
On 10/08/2015 10:55 PM, Dongsheng Wang wrote:
From: Wang Dongsheng
This issue caused on 'commit 990486c8af04 ("strscpy: zero any trailing
garbage bytes in the destination")'.
zero_bytemask is not implemented on PowerPC. So copy the zero_bytemask
of BIG_ENDIAN implementation from include/asm-ge
On Fri, Oct 09, 2015 at 01:51:11PM +0100, Will Deacon wrote:
> On Fri, Oct 09, 2015 at 01:12:02PM +0200, Peter Zijlstra wrote:
> > On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote:
> > > > Which leads me to think I would like to suggest alternative rules for
> > > > RELEASE/ACQUIRE (to r
On Fri, Oct 09, 2015 at 01:12:02PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote:
> > > Which leads me to think I would like to suggest alternative rules for
> > > RELEASE/ACQUIRE (to replace those Will suggested; as I think those are
> > > partly respon
On Fri, Oct 09, 2015 at 01:02:46PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote:
> > Stepping back a second, I believe that there are three cases:
> >
> >
> > RELEASE X -> ACQUIRE Y (same CPU)
> >* Needs a barrier on TSO architectures for full or
On Fri, Oct 09, 2015 at 10:51:29AM +0100, Will Deacon wrote:
> > The corresponding litmus tests are below.
>
> How do people feel about including these in memory-barriers.txt? I find
> them considerably easier to read than our current kernel code + list of
> possible orderings + wall of text, but
On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote:
>
> > - RELEASE -> ACQUIRE _chains_ (on shared variables) preserve causality,
> >(because each link is fully ordered) but are not transitive.
>
> Yup, and that's the same for UNLOCK -> LOCK, too.
Agreed, except RELEASE/ACQUIRE is
On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote:
> > Which leads me to think I would like to suggest alternative rules for
> > RELEASE/ACQUIRE (to replace those Will suggested; as I think those are
> > partly responsible for my confusion).
>
> Yeah, sorry. I originally used the phrase
On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote:
> Stepping back a second, I believe that there are three cases:
>
>
> RELEASE X -> ACQUIRE Y (same CPU)
>* Needs a barrier on TSO architectures for full ordering
+PPC
> UNLOCK X -> LOCK Y (same CPU)
>* Needs a barrier
Hi Paul,
On Thu, Oct 08, 2015 at 03:17:16PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 08, 2015 at 01:59:38PM +0100, Will Deacon wrote:
> > I thought Paul was talking about something like this case:
> >
> > CPU A CPU B CPU C
> > foo = 1
> > UNLOCK x
> > LOCK x
> >
On Fri, Oct 09, 2015 at 10:31:38AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 08, 2015 at 02:44:39PM -0700, Paul E. McKenney wrote:
> > On Thu, Oct 08, 2015 at 01:16:38PM +0200, Peter Zijlstra wrote:
> > > On Thu, Oct 08, 2015 at 02:50:36PM +1100, Michael Ellerman wrote:
> > > > On Wed, 2015-10-07
From: Benjamin Herrenschmidt
> Sent: 09 October 2015 09:15
> On Fri, 2015-10-09 at 10:46 +0800, Wei Yang wrote:
> > On PHB_IODA2, we enable SRIOV devices by mapping IOV BAR with M64 BARs. If
> > a SRIOV device's IOV BAR is not 64bit-prefetchable, this is not assigned
> > from 64bit prefetchable win
On Thu, Oct 08, 2015 at 02:44:39PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 08, 2015 at 01:16:38PM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 08, 2015 at 02:50:36PM +1100, Michael Ellerman wrote:
> > > On Wed, 2015-10-07 at 08:25 -0700, Paul E. McKenney wrote:
> >
> > > > Currently, we do ne
On Fri, 2015-10-09 at 10:46 +0800, Wei Yang wrote:
> On PHB_IODA2, we enable SRIOV devices by mapping IOV BAR with M64 BARs. If
> a SRIOV device's IOV BAR is not 64bit-prefetchable, this is not assigned
> from 64bit prefetchable window, which means M64 BAR can't work on it.
Won't this cause a lot
On Thu, Oct 08, 2015 at 02:44:39PM -0700, Paul E. McKenney wrote:
> > > > I am with Peter -- we do need the benchmark results for PPC.
> > >
> > > Urgh, sorry guys. I have been slowly doing some benchmarks, but time is
> > > not
> > > plentiful at the moment.
> > >
> > > If we do a straight lws
28 matches
Mail list logo
