> On Fri, 2015-03-20 at 11:55 +0700, Arseny Solokha wrote:
>>
>> And by the way, while revisiting the series I've noticed that though the
>> patch
>> 4/4 basically reverts [1], it leaves
>>
>> #define MPIC_GREG_GLOBAL_CONF_10x00030
>>
>> in arch/powerpc/include/asm/mpic.h untouche
Drop unused static procedure which doesn't have callers within its
translation unit. It had been already removed independently in QEMU[1]
from the OpenPIC implementation borrowed by the kernel.
[1] https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg01812.html
v4: Fixed the comment regarding
From: Hongtao Jia
MPIC version is useful information for both mpic_alloc() and mpic_init().
The patch provide an API to get MPIC version for reusing the code.
Also, some other IP block may need MPIC version for their own use.
The API for external use is also provided.
This function had been prev
On Tue, 2015-01-20 at 10:57 +0100, Christophe Leroy wrote:
> By default, TASK_SIZE is set to 0x8000 for PPC_8xx, which is most likely
> sufficient for most cases. However, kernel configuration allows to set
> TASK_SIZE
> to another value, so the 8xx shall handle it.
>
> Signed-off-by: Christo
On Fri, Dec 05, 2014 at 12:20:25PM +0100, LEROY Christophe wrote:
> When size is equal to 1, the test is always true so lets eliminate both 0 and
> 1
> at first.
>
> include/asm-generic/termios-base.h: In function
> 'user_termio_to_kernel_termios':
> include/asm-generic/termios-base.h:35:2: warn
On Fri, Dec 05, 2014 at 12:20:20PM +0100, LEROY Christophe wrote:
> include/linux/mm.h: In function 'is_vmalloc_addr':
> include/linux/mm.h:367:14: warning: comparison between signed and unsigned
> integer expressions [-Wsign-compare]
> return addr >= VMALLOC_START && addr < VMALLOC_END;
>
Am 20.03.2015 um 16:53 schrieb Laurent Dufour:
> Some architecture would like to be triggered when a memory area is moved
> through the mremap system call.
>
> This patch is introducing a new arch_remap mm hook which is placed in the
> path of mremap, and is called before the old area is unmapped
2015-03-21 5:20 GMT+08:00 Bjorn Helgaas :
> On Fri, Mar 20, 2015 at 11:06:16AM +0800, Wei Yang wrote:
>> This patchset enables the SRIOV on POWER8.
>>
>> The general idea is put each VF into one individual PE and allocate required
>> resources like MMIO/DMA/MSI. The major difficulty comes from the
On Fri, 2015-03-20 at 16:16 -0500, Bjorn Helgaas wrote:
>
> > The other option is you put the generic changes in a topic branch
> which
> > both of us merge and I take care of the rest.
>
> Yeah, I chatted with Wei this morning, and he reminded me that there's
> really not very much drivers/pci c
On Fri, Mar 20, 2015 at 11:06:30AM +0800, Wei Yang wrote:
> Previously the iommu_table had the same lifetime as a struct pnv_ioda_pe
> and was embedded in it. The pnv_ioda_pe was assigned to a PE on the bootup
> stage. Since PEs are based on the hardware layout which is static in the
> system, they
On Fri, Mar 20, 2015 at 11:06:16AM +0800, Wei Yang wrote:
> This patchset enables the SRIOV on POWER8.
>
> The general idea is put each VF into one individual PE and allocate required
> resources like MMIO/DMA/MSI. The major difficulty comes from the MMIO
> allocation and adjustment for PF's IOV B
On Fri, Mar 20, 2015 at 4:05 PM, Benjamin Herrenschmidt
wrote:
> On Fri, 2015-03-20 at 09:34 -0500, Bjorn Helgaas wrote:
>> On Fri, Mar 20, 2015 at 12:43 AM, Gavin Shan
>> wrote:
>> > On Fri, Mar 20, 2015 at 11:06:16AM +0800, Wei Yang wrote:
>> >
>> > [snip]
>> >
>> >>---
>> >>v14:
>> >> * cal
On Fri, 2015-03-20 at 09:34 -0500, Bjorn Helgaas wrote:
> On Fri, Mar 20, 2015 at 12:43 AM, Gavin Shan
> wrote:
> > On Fri, Mar 20, 2015 at 11:06:16AM +0800, Wei Yang wrote:
> >
> > [snip]
> >
> >>---
> >>v14:
> >> * call ppc_md.pcibios_fixup_sriov() in pcibios_add_device
> >> * add more expl
The patch defines PCI error types and functions in eeh.h and
exports function eeh_pe_inject_err(), which will be called by
VFIO driver to inject the specified PCI error to the indicated
PE for testing purpose.
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/eeh.h | 26
Those two patches are extention to EEH support for VFIO PCI devices,
which allows to inject EEH errors to VFIO PCI devices from userspace
for testing purpose.
Changelog
=
v2 -> v3:
* Use offsetofend(), instead of sizeof(struct vfio_eeh_pe_op)
to calculate argument buffer
The patch adds one more EEH sub-command (VFIO_EEH_PE_INJECT_ERR)
to inject the specified EEH error, which is represented by
(struct vfio_eeh_pe_err), to the indicated PE for testing purpose.
Signed-off-by: Gavin Shan
---
Documentation/vfio.txt| 12
drivers/vfio/vfio_spapr_ee
On Thu, Mar 19, 2015 at 9:13 PM, Dave Chinner wrote:
>
> Testing now. It's a bit faster - three runs gave 7m35s, 7m20s and
> 7m36s. IOWs's a bit better, but not significantly. page migrations
> are pretty much unchanged, too:
>
>558,632 migrate:mm_migrate_pages ( +- 6.38% )
Ok.
On 03/20/2015 04:26 PM, Guenter Roeck wrote:
> On Thu, Mar 19, 2015 at 06:44:40PM +0100, Cédric Le Goater wrote:
>> Hello !
>>
>> The current implementation of the driver uses an index for the hwmon
>> attribute which is extracted from the device node name. This index
>> is calculated by the OPAL
Some processes (CRIU) are moving the vDSO area using the mremap system
call. As a consequence the kernel reference to the vDSO base address is
no more valid and the signal return frame built once the vDSO has been
moved is not pointing to the new sigreturn address.
This patch handles vDSO remappin
Some architecture would like to be triggered when a memory area is moved
through the mremap system call.
This patch is introducing a new arch_remap mm hook which is placed in the
path of mremap, and is called before the old area is unmapped (and the
arch_unmap hook is called).
To no break the bui
CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.
However some architectures like powerpc are keeping a reference to the vDSO
base address to build th
On Fri, Mar 20, 2015 at 09:06:38AM +0100, Cedric Le Goater wrote:
> [ ... ]
>
>
> > @@ -265,10 +261,17 @@ static int create_device_attrs(struct pl
> >
> > sdata[count].id = sensor_id;
> > sdata[count].type = type;
> > - err = create_hwmon_attr_name(&pdev->dev,
On Thu, Mar 19, 2015 at 06:44:40PM +0100, Cédric Le Goater wrote:
> Hello !
>
> The current implementation of the driver uses an index for the hwmon
> attribute which is extracted from the device node name. This index
> is calculated by the OPAL firmware and its usage creates a dependency
> with
On Fri, Mar 20, 2015 at 12:43 AM, Gavin Shan wrote:
> On Fri, Mar 20, 2015 at 11:06:16AM +0800, Wei Yang wrote:
>
> [snip]
>
>>---
>>v14:
>> * call ppc_md.pcibios_fixup_sriov() in pcibios_add_device
>> * add more explanation in change log
>> * Following patches have been reordered to the beg
On 20.03.15 04:56, Arseny Solokha wrote:
> Drop unused static procedure which doesn't have callers within its
> translation unit. It had been already removed independently in QEMU[1]
> from the OpenPIC implementation borrowed from the kernel.
The order was reverse. QEMU's implementation was firs
From: Anshuman Khandual
This patch implements LED driver for PowerNV platform using the existing
generic LED class framework. It registers classdev structures for all
individual LEDs detected on the system through LED specific device tree
nodes. Device tree nodes specify what all kind of LEDs pre
From: Anshuman Khandual
This patch registers the following two new OPAL interfaces calls
for the platform LED subsystem. With the help of these new OPAL calls,
the kernel will be able to get or set the state of various individual
LEDs on the system at any given location code which is passed throu
The following series implements LED driver for PowerNV platform.
PowerNV platform has below type of indicators:
- System attention indicator (Check log indicator)
Indicates there is a problem with the system that needs attention.
- Identify
Helps the user locate/identify a particul
On Thu, Mar 19, 2015 at 06:29:47PM -0700, Linus Torvalds wrote:
> And the VM_WRITE test should be stable and not have any subtle
> interaction with the other changes that the numa pte things
> introduced. It would be good to see if the profiles then pop something
> *else* up as the performance diff
On Thu, Mar 19, 2015 at 04:05:46PM -0700, Linus Torvalds wrote:
> On Thu, Mar 19, 2015 at 3:41 PM, Dave Chinner wrote:
> >
> > My recollection wasn't faulty - I pulled it from an earlier email.
> > That said, the original measurement might have been faulty. I ran
> > the numbers again on the 3.19
On 03/19/2015 10:13 AM, Sam Bobroff wrote:
> Check that a syscall made during an active transaction will fail with
> the correct failure code and that one made during a suspended
> transaction will succeed.
>
> Signed-off-by: Sam Bobroff
The test works.
> +
> +int tm_syscall(void)
> +{
> +
On 03/19/2015 10:13 AM, Sam Bobroff wrote:
> This patch changes the syscall handler to doom (tabort) active
> transactions when a syscall is made and return immediately without
> performing the syscall.
>
> Currently, the system call instruction automatically suspends an
> active transaction which
On 03/20/2015 11:53 AM, Michael Ellerman wrote:
> On Sun, 2015-03-08 at 16:44 +0530, Vasant Hegde wrote:
>> From: Anshuman Khandual
>>
>> This patch registers the following two new OPAL interfaces calls
>> for the platform LED subsystem. With the help of these new OPAL calls,
>> the kernel will be
[ ... ]
> @@ -265,10 +261,17 @@ static int create_device_attrs(struct pl
>
> sdata[count].id = sensor_id;
> sdata[count].type = type;
> - err = create_hwmon_attr_name(&pdev->dev, type, np->name,
> - sdata[count].na
34 matches
Mail list logo
