On 07/16/2013 03:28:06 AM, David Laight wrote:
> On 07/15/2013 11:53:54 AM, Scott Wood wrote:
> > On 07/15/2013 03:45:36 AM, David Laight wrote:
> >> Also, if the high word changes, there is no need to loop.
> >> Just return the second value with a low word of zero
> >> (the returned count happen
> On 07/15/2013 11:53:54 AM, Scott Wood wrote:
> > On 07/15/2013 03:45:36 AM, David Laight wrote:
> >> Also, if the high word changes, there is no need to loop.
> >> Just return the second value with a low word of zero
> >> (the returned count happened while the function was active).
> >
> > That w
On 07/15/2013 11:53:54 AM, Scott Wood wrote:
On 07/15/2013 03:45:36 AM, David Laight wrote:
Also, if the high word changes, there is no need to loop.
Just return the second value with a low word of zero
(the returned count happened while the function was active).
That would be more complicated
On 07/15/2013 01:03:22 AM, Aneesh Kumar K.V wrote:
Scott Wood writes:
> diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
> index ae0aaea..7f0e2e5 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
On 07/15/2013 03:45:36 AM, David Laight wrote:
> +#define MFTB(dest, scratch1, scratch2)\
> +90: mftbu scratch1; \
> + mftbl dest; \
> + mftbu scratch2; \
> + cmpwscratch1,scratch2; \
> + bne 90b;\
> +#define MFTB(dest, scratch1, scratch2) \
> +90: mftbu scratch1; \
> + mftbl dest; \
> + mftbu scratch2; \
> + cmpwscratch1,scratch2; \
> + bne 90b;\
> + rldimi dest,scratch1,32,0;
Ar
Scott Wood writes:
> diff --git a/arch/powerpc/platforms/Kconfig.cputype
> b/arch/powerpc/platforms/Kconfig.cputype
> index ae0aaea..7f0e2e5 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -165,6 +165,17 @@ config PPC_E500MC
> s
Erratum A-006598 says that 64-bit mftb is not atomic -- it's subject
to the same race condition as doing mftbu/mftbl on 32-bit, thus we
need to use the same loop to safely read it.
This deals with kernel and vdso accesses, but other userspace accesses
will of course need to be fixed elsewhere.
Th
