> On Mon, 2015-02-16 at 17:56 +0700, Arseny Solokha wrote:
>> Drop unused fsl_mpic_primary_get_version(), mpic_set_clk_ratio(),
>> mpic_set_serial_int().
>
> I'm always happy to remove unused code, but the interesting question is why
> are
> they unused? Please tell me in the changelog.
To being
On 2/18/2015 10:56 PM, Michael Ellerman wrote:
On Wed, 2015-02-18 at 21:36 -0400, Julian Margetson wrote:
On 2/18/2015 8:13 PM, Michael Ellerman wrote:
On Wed, 2015-02-18 at 15:45 -0400, Julian Margetson wrote:
On 2/15/2015 8:18 PM, Michael Ellerman wrote:
On Sun, 2015-02-15 at 08:16 -0400,
On Thu, 19 Feb 2015, David Miller wrote:
> From: Joseph Myers
> Date: Fri, 6 Feb 2015 17:25:29 +
>
> > * On SPARC, comparisons now use raw unpacking (this should not in fact
> > change how the emulation behaves, just make it more efficient).
>
> I did a sparc64 test build and it failed li
After d905c5df9aef ("PPC: POWERNV: move iommu_add_device earlier"), the
refcnt on the kobject backing the IOMMU group for a PCI device is
elevated by each call to pci_dma_dev_setup_pSeriesLP() (via
set_iommu_table_base_and_group). When we go to dlpar a multi-function
PCI device out:
iommu_
On Tue, Feb 17, 2015 at 09:36:47AM +1100, Gavin Shan wrote:
> On Mon, Feb 16, 2015 at 11:14:27AM -0200, casca...@linux.vnet.ibm.com wrote:
> >On Fri, Feb 13, 2015 at 03:54:55PM +1100, Gavin Shan wrote:
> >> VFIO PCI infrastructure depends on pci_reset_function() to do reset on
> >> PCI devices so t
From: Joseph Myers
Date: Thu, 19 Feb 2015 18:40:34 +
> On Thu, 19 Feb 2015, David Miller wrote:
>
>> From: Joseph Myers
>> Date: Fri, 6 Feb 2015 17:25:29 +
>>
>> > * On SPARC, comparisons now use raw unpacking (this should not in fact
>> > change how the emulation behaves, just make
The driver was ignoring limits requested by libata.force. The output
would look like:
fsl-sata ffe18000.sata: Sata FSL Platform/CSB Driver init
ata1: FORCE: PHY spd limit set to 1.5Gbps
ata1: SATA max UDMA/133 irq 74
ata1: Signature Update detected @ 0 msecs
ata1: SATA link up 3.0 Gbps (SStatus
From: Denis Kirjanov
Date: Tue, 17 Feb 2015 10:04:37 +0300
> This patch series enables BPF JIT on ppc32. There are relatevily
> few chnages in the code to make it work.
>
> All test_bpf tests passed both on 7447a and P2041-based machines.
>
> Changelog:
> v1 - > v2: Reordered Kconfig patch in t
On 2/19/15, David Miller wrote:
> From: Denis Kirjanov
> Date: Tue, 17 Feb 2015 10:04:37 +0300
>
>> This patch series enables BPF JIT on ppc32. There are relatevily
>> few chnages in the code to make it work.
>>
>> All test_bpf tests passed both on 7447a and P2041-based machines.
>>
>> Changelog:
On Fri, 2015-02-20 at 01:07 +0400, Denis Kirjanov wrote:
> On 2/19/15, David Miller wrote:
> > From: Denis Kirjanov
> > Date: Tue, 17 Feb 2015 10:04:37 +0300
> >
> >> This patch series enables BPF JIT on ppc32. There are relatevily
> >> few chnages in the code to make it work.
> >>
> >> All test_
On 2/20/15, Michael Ellerman wrote:
> On Fri, 2015-02-20 at 01:07 +0400, Denis Kirjanov wrote:
>> On 2/19/15, David Miller wrote:
>> > From: Denis Kirjanov
>> > Date: Tue, 17 Feb 2015 10:04:37 +0300
>> >
>> >> This patch series enables BPF JIT on ppc32. There are relatevily
>> >> few chnages in
On Tue, Feb 10, 2015 at 12:02:31PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2015-02-04 at 17:44 -0600, Bjorn Helgaas wrote:
> > >
> > > diff --git a/Documentation/powerpc/pci_iov_resource_on_powernv.txt
> > > b/Documentation/powerpc/pci_iov_resource_on_powernv.txt
> > > new file mode 100644
On 02/20/2015 05:41 AM, Nishanth Aravamudan wrote:
After d905c5df9aef ("PPC: POWERNV: move iommu_add_device earlier"), the
refcnt on the kobject backing the IOMMU group for a PCI device is
elevated by each call to pci_dma_dev_setup_pSeriesLP() (via
set_iommu_table_base_and_group). When we go to d
Just noticed - this patch should be split into two, they were squashed by
mistake, my bad.
On 02/16/2015 09:06 PM, Alexey Kardashevskiy wrote:
The existing implementation accounts the whole DMA window in
the locked_vm counter which is going to be even worse with multiple
containers and huge DM
On Thu, 2015-02-19 at 18:56 -0600, Bjorn Helgaas wrote:
> So there are the two windows of CPU address space that are routed to the
> PHB. And the PHB contains one M32 window and sixteen M64 windows. What
> happens if the PHB receives an access to something that was in one of the
> two CPU addres
On Thu, 2015-02-19 at 19:26 +0700, Arseny Solokha wrote:
> > On Mon, 2015-02-16 at 17:56 +0700, Arseny Solokha wrote:
> >> Drop unused fsl_mpic_primary_get_version(), mpic_set_clk_ratio(),
> >> mpic_set_serial_int().
> >
> > I'm always happy to remove unused code, but the interesting question is wh
Joseph Myers wrote:
> Please try this patch on top of the previous one. The way abort is
> redefined in the kernel code doesn't work for one place using it in an
> expression; this patch changes a comma expression to a statement
> expression. This didn't appear in my powerpc testing because t
On Thu, 2015-02-19 at 10:41 -0800, Nishanth Aravamudan wrote:
> After d905c5df9aef ("PPC: POWERNV: move iommu_add_device earlier"), the
> refcnt on the kobject backing the IOMMU group for a PCI device is
> elevated by each call to pci_dma_dev_setup_pSeriesLP() (via
> set_iommu_table_base_and_group)
> If I just get a patch saying "removed unused foo()", I have to go and dig and
> find out:
> - was it recently added and will be used soon?
> - is it ancient and never used, if so can we work out why, ie. feature X
> never landed so this code is no longer needed.
> - is it old code that
On Thu, Feb 19, 2015 at 04:57:47PM -0200, casca...@linux.vnet.ibm.com wrote:
>On Tue, Feb 17, 2015 at 09:36:47AM +1100, Gavin Shan wrote:
>> On Mon, Feb 16, 2015 at 11:14:27AM -0200, casca...@linux.vnet.ibm.com wrote:
>> >On Fri, Feb 13, 2015 at 03:54:55PM +1100, Gavin Shan wrote:
>> >> VFIO PCI in
20 matches
Mail list logo
