On Fri, Jun 08, 2018 at 03:46:29PM +1000, Alexey Kardashevskiy wrote:
> Right now we have allocation code in pci-ioda.c and traversing code in
> pci.c, let's keep them toghether. However both files are big enough
> already so let's move this business to a new file.
>
> While we at it, move the
On Fri, Jun 08, 2018 at 03:46:28PM +1000, Alexey Kardashevskiy wrote:
> This gets rid of a useless wrapper around
> pnv_pci_ioda2_table_free_pages().
>
> Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 7 +--
> 1 file
Hi!
On Fri, Jun 08, 2018 at 01:27:39PM +, Christophe Leroy wrote:
> ---
> Not tested on PPC64.
> +#ifdef CPU_LITTLE_ENDIAN
> + rldicl. r8, r9, 0, 56
> + beq 20f
> + rldicl. r8, r9, 56, 56
> + beq 21f
> + rldicl. r8, r9, 48, 56
> + beq 22f
> + rldicl.
On Fri, 8 Jun 2018 15:51:03 +0200
Florian Weimer wrote:
> On 06/08/2018 03:49 PM, Michal Suchánek wrote:
> > On Fri, 8 Jun 2018 14:57:06 +0200
> > Florian Weimer wrote:
> >
> >> On 06/08/2018 02:54 PM, Michal Suchánek wrote:
> >>> On Fri, 8 Jun 2018 12:44:53 +0200
> >>> Florian Weimer
On 06/08/2018 03:49 PM, Michal Suchánek wrote:
On Fri, 8 Jun 2018 14:57:06 +0200
Florian Weimer wrote:
On 06/08/2018 02:54 PM, Michal Suchánek wrote:
On Fri, 8 Jun 2018 12:44:53 +0200
Florian Weimer wrote:
On 06/08/2018 12:15 PM, Michal Suchánek wrote:
On Fri, 8 Jun 2018 07:53:51
On Fri, 8 Jun 2018 14:57:06 +0200
Florian Weimer wrote:
> On 06/08/2018 02:54 PM, Michal Suchánek wrote:
> > On Fri, 8 Jun 2018 12:44:53 +0200
> > Florian Weimer wrote:
> >
> >> On 06/08/2018 12:15 PM, Michal Suchánek wrote:
> >>> On Fri, 8 Jun 2018 07:53:51 +0200
> >>> Florian Weimer
This patch modifies the test for testing the new assembly strlen() instead
of the generic strlen()
Signed-off-by: Christophe Leroy
---
v5: no change
v4: new
tools/testing/selftests/powerpc/stringloops/Makefile | 3 +--
.../selftests/powerpc/stringloops/asm/cache.h| 1 +
This patch renames memcmp test to memcmp_64 and adds
a memcmp_32 test for testing the 32 bits version of memcmp()
Signed-off-by: Christophe Leroy
---
v5: no change
v4: new
tools/testing/selftests/powerpc/stringloops/Makefile| 14 +++---
This patch adds a test for strlen()
string.c contains a copy of strlen() from lib/string.c
The test first tests the correctness of strlen() by comparing
the result with libc strlen(). It tests all cases of alignment.
It them tests the duration of an aligned strlen() on a 4 bytes string,
on a 16
The generic implementation of strlen() reads strings byte per byte.
This patch implements strlen() in assembly based on a read of entire
words, in the same spirit as what some other arches and glibc do.
On a 8xx the time spent in strlen is reduced by 2/3 for long strings.
strlen() selftest on
On 06/08/2018 02:54 PM, Michal Suchánek wrote:
On Fri, 8 Jun 2018 12:44:53 +0200
Florian Weimer wrote:
On 06/08/2018 12:15 PM, Michal Suchánek wrote:
On Fri, 8 Jun 2018 07:53:51 +0200
Florian Weimer wrote:
On 06/08/2018 04:34 AM, Ram Pai wrote:
So the remaining question at this point
On Fri, 8 Jun 2018 12:44:53 +0200
Florian Weimer wrote:
> On 06/08/2018 12:15 PM, Michal Suchánek wrote:
> > On Fri, 8 Jun 2018 07:53:51 +0200
> > Florian Weimer wrote:
> >
> >> On 06/08/2018 04:34 AM, Ram Pai wrote:
>
> So the remaining question at this point is whether the
On Fri, Jun 08, 2018 at 01:45:13PM +0200, Gabriel Paubert wrote:
> On Fri, Jun 08, 2018 at 10:20:41AM +, Christophe Leroy wrote:
> > + rlwinm. r8, r9, 0, 0xff00
> > + beq 20f
> > + rlwinm. r8, r9, 0, 0x00ff
> > + beq 21f
> > + rlwinm. r8, r9, 0, 0xff00
> > + beq
On Fri, Jun 08, 2018 at 10:20:41AM +, Christophe Leroy wrote:
> The generic implementation of strlen() reads strings byte per byte.
>
> This patch implements strlen() in assembly based on a read of entire
> words, in the same spirit as what some other arches and glibc do.
>
> On a 8xx the
On 06/08/2018 12:15 PM, Michal Suchánek wrote:
On Fri, 8 Jun 2018 07:53:51 +0200
Florian Weimer wrote:
On 06/08/2018 04:34 AM, Ram Pai wrote:
So the remaining question at this point is whether the Intel
behavior (default-deny instead of default-allow) is preferable.
Florian, remind me
On 06/08/2018 12:20 PM, Michael Ellerman wrote:
> Mahesh J Salgaonkar writes:
>> From: Mahesh Salgaonkar
>>
>> During Machine Check interrupt on pseries platform, register r3 points
>> RTAS extended event log passed by hypervisor. Since hypervisor uses r3
>> to pass pointer to rtas log, it
This patch modifies the test for testing the new assembly strlen() instead
of the generic strlen()
Signed-off-by: Christophe Leroy
---
v4: new
tools/testing/selftests/powerpc/stringloops/Makefile | 3 +--
.../selftests/powerpc/stringloops/asm/cache.h| 1 +
This patch renames memcmp test to memcmp_64 and adds
a memcmp_32 test for testing the 32 bits version of memcmp()
Signed-off-by: Christophe Leroy
---
v4: new
tools/testing/selftests/powerpc/stringloops/Makefile| 14 +++---
tools/testing/selftests/powerpc/stringloops/memcmp_32 |
The generic implementation of strlen() reads strings byte per byte.
This patch implements strlen() in assembly based on a read of entire
words, in the same spirit as what some other arches and glibc do.
On a 8xx the time spent in strlen is reduced by 2/3 for long strings.
strlen() selftest on
This patch adds a test for strlen()
string.c contains a copy of strlen() from lib/string.c
The test first tests the correctness of strlen() by comparing
the result with libc strlen(). It tests all cases of alignment.
It them tests the duration of an aligned strlen() on a 4 bytes string,
on a 16
On Fri, 8 Jun 2018 07:53:51 +0200
Florian Weimer wrote:
> On 06/08/2018 04:34 AM, Ram Pai wrote:
> >>
> >> So the remaining question at this point is whether the Intel
> >> behavior (default-deny instead of default-allow) is preferable.
> >
> > Florian, remind me what behavior needs to fixed?
When compile-testing on m68k or microblaze:
drivers/media/platform/fsl-viu.c:41:1: warning: "out_be32" redefined
drivers/media/platform/fsl-viu.c:42:1: warning: "in_be32" redefined
Fix this by replacing the check for PowerPC by checks for the presence
of {out,in}_be32().
As PowerPC
Hi Yangbo,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[also build test WARNING on next-20180608]
[cannot apply to v4.17]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On Thu, Jun 07, 2018 at 07:28:35PM +0300, Michael S. Tsirkin wrote:
> Let me restate it: DMA API has support for a wide range of hardware, and
> hardware based virtio implementations likely won't benefit from all of
> it.
That is completely wrong. All aspects of the DMA API are about the
system
On Thu, 2018-06-07 at 15:22 +0530, Naveen N. Rao wrote:
> We implement regs_set_return_value() and override_function_with_return()
> for this purpose.
>
> On powerpc, a return from a function (blr) just branches to the location
> contained in the link register. So, we can just update pt_regs
Mahesh J Salgaonkar writes:
> From: Mahesh Salgaonkar
>
> During Machine Check interrupt on pseries platform, register r3 points
> RTAS extended event log passed by hypervisor. Since hypervisor uses r3
> to pass pointer to rtas log, it stores the original r3 value at the
> start of the memory
On 06/08/2018 07:21 AM, Nicholas Piggin wrote:
> On Thu, 07 Jun 2018 22:59:04 +0530
> Mahesh J Salgaonkar wrote:
>
>> From: Mahesh Salgaonkar
>>
>> Extract the MCE error details from RTAS extended log and display it to
>> console.
>>
>> With this patch you should now see mce logs like below:
>>
On 06/08/2018 07:18 AM, Nicholas Piggin wrote:
> On Thu, 07 Jun 2018 22:58:55 +0530
> Mahesh J Salgaonkar wrote:
>
>> From: Mahesh Salgaonkar
>>
>> If we get a machine check exceptions due to SLB errors then dump the
>> current SLB contents which will be very much helpful in debugging the
>>
On 06/08/2018 07:01 AM, Nicholas Piggin wrote:
> On Thu, 07 Jun 2018 22:58:11 +0530
> Mahesh J Salgaonkar wrote:
>
>> From: Mahesh Salgaonkar
>>
>> rtas_log_buf is a buffer to hold RTAS event data that are communicated
>> to kernel by hypervisor. This buffer is then used to pass RTAS event
>>
On 06/08/2018 04:34 AM, Ram Pai wrote:
So the remaining question at this point is whether the Intel
behavior (default-deny instead of default-allow) is preferable.
Florian, remind me what behavior needs to fixed?
See the other thread. The Intel register equivalent to the AMR by
default
At the moment we allocate the entire TCE table, twice (hardware part and
userspace translation cache). This normally works as we normally have
contigous memory and the guest will map entire RAM for 64bit DMA.
However if we have sparse RAM (one example is a memory device), then
we will allocate
31 matches
Mail list logo
