On Wed, 2015-08-19 at 15:12 +1000, Ian Munsie wrote:
> Excerpts from Michael Ellerman's message of 2015-08-19 14:49:30 +1000:
> > Do we really need the accessors? They don't buy anything I can see over just
> > using ctx->priv directly.
>
> The reasoning there is because we don't currently expose
On Wed, 2015-08-19 at 14:19 +1000, Ian Munsie wrote:
> From: Ian Munsie
>
> This adds an afu_driver_ops structure with event_pending and
> deliver_event callbacks. An AFU driver can fill these out and associate
> it with a context to enable passing custom AFU specific events to
> userspace.
What
Excerpts from Michael Ellerman's message of 2015-08-19 14:49:30 +1000:
> Do we really need the accessors? They don't buy anything I can see over just
> using ctx->priv directly.
The reasoning there is because we don't currently expose the contents of
stuct cxl_context to afu drivers, rather they j
On Wed, 2015-08-19 at 14:19 +1000, Ian Munsie wrote:
> From: Michael Neuling
>
> This provides AFU drivers a means to associate private data with a cxl
> context. This is particularly intended for make the new callbacks for
> driver specific events easier for AFU drivers to use, as they can easil
From: Michael Neuling
This provides AFU drivers a means to associate private data with a cxl
context. This is particularly intended for make the new callbacks for
driver specific events easier for AFU drivers to use, as they can easily
get back to any private data structures they may use.
Signed
From: Ian Munsie
This adds an afu_driver_ops structure with event_pending and
deliver_event callbacks. An AFU driver can fill these out and associate
it with a context to enable passing custom AFU specific events to
userspace.
The cxl driver will call event_pending() during poll, select, read, e
On Wed, Aug 19, 2015 at 10:01:44AM +0800, Wei Yang wrote:
>When M64 BAR is set to Single PE mode, the PE# assigned to VF could be
>sparse.
>
>This patch restructures the patch to allocate sparse PE# for VFs when M64
>BAR is set to Single PE mode. Also it rename the offset to pe_num_map to
>reflect
On Wed, Aug 19, 2015 at 10:01:41AM +0800, Wei Yang wrote:
>In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
>BARs in Single PE mode to cover the number of VFs required to be enabled.
>By doing so, several VFs would be in one VF Group and leads to interference
>between VFs i
Each VF could have 6 BARs at most. When the total BAR size exceeds the
gate, after expanding it will also exhaust the M64 Window.
This patch limits the boundary by checking the total VF BAR size instead of
the individual BAR.
Signed-off-by: Wei Yang
Reviewed-by: Gavin Shan
---
arch/powerpc/pla
When M64 BAR is set to Single PE mode, the PE# assigned to VF could be
sparse.
This patch restructures the patch to allocate sparse PE# for VFs when M64
BAR is set to Single PE mode. Also it rename the offset to pe_num_map to
reflect the content is the PE number.
Signed-off-by: Wei Yang
---
arc
At the moment 64bit-prefetchable window can be maximum 64GB, which is
currently got from device tree. This means that in shared mode the maximum
supported VF BAR size is 64GB/256=256MB. While this size could exhaust the
whole 64bit-prefetchable window. This is a design decision to set a
boundary to
The alignment of IOV BAR on PowerNV platform is the total size of the IOV
BAR. No matter whether the IOV BAR is extended with number of
roundup_pow_of_two(total_vfs) or number of max PE number (256), the total
size could be calculated by (vfs_expanded * VF_BAR_size).
This patch simplifies the pnv_
In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
BARs in Single PE mode to cover the number of VFs required to be enabled.
By doing so, several VFs would be in one VF Group and leads to interference
between VFs in the same group.
And in this patch, m64_wins is renamed to m
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.
This patch makes this explicit.
Signed-off-by: Wei Yang
Reviewed-by: Gavin Sha
In original design, it tries to group VFs to enable more number of VFs in the
system, when VF BAR is bigger than 64MB. This design has a flaw in which one
error on a VF will interfere other VFs in the same group.
This patch series change this design by using M64 BAR in Single PE mode to
cover only
On Tue, 2015-08-18 at 12:35 +0200, Javier Martinez Canillas wrote:
> Hello Michael,
>
> On 08/18/2015 12:24 PM, Michael Ellerman wrote:
> > On Thu, 2015-30-07 at 16:18:30 UTC, Javier Martinez Canillas wrote:
> >> The I2C core always reports the MODALIAS uevent as "i2c: >> regardless if the driver
Hi Guilherme,
Thanks for the patches.
On Tue, 2015-08-18 at 18:13 -0300, Guilherme G. Piccoli wrote:
> Commit 1851617cd2 ("PCI/MSI: Disable MSI at enumeration even if kernel
> doesn't support MSI") changed the location of the code that disables
> MSI/MSI-X interrupts at PCI probe time in devices
Acked-by: Ian Munsie
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
If we open a context but do not start it (either because we do not attempt
to start it, or because it fails to start for some reason), we are left
with a context in state OPENED. Previously, cxl_release_context() only
allowed releasing contexts in state CLOSED, so attempting to release an
OPENED co
On 19/08/15 02:23, Michael Neuling wrote:
So this doesn't break when you add a new state, is it worth writing it as:
if (ctx->status >= STARTED)
return -EBUSY;
?
Yeah I think that would be more future proof, although it won't make a
difference with the current code.
These 2 patches correct a bogus behaviour introduced by commit 1851617cd2
("PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI").
The commit moved the logic responsible to disable MSI/MSI-X interrupts
at PCI probe time to a new function, named pci_msi_setup_pci_dev(), that
is no
Since the commit 1851617cd2 ("PCI/MSI: Disable MSI at enumeration even if
kernel doesn't support MSI"), MSI/MSI-X interrupts aren't being disabled
at PCI probe time, as the logic responsible for this was moved in the
aforementioned commit from pci_device_add() to pci_setup_device(). The
latter func
Commit 1851617cd2 ("PCI/MSI: Disable MSI at enumeration even if kernel
doesn't support MSI") changed the location of the code that disables
MSI/MSI-X interrupts at PCI probe time in devices that have this flag set.
It moved the code from pci_msi_init_pci_dev() to a new function named
pci_msi_setup_
Update the annotation for the kaddr pointer returned by direct_access()
so that it is a __pmem pointer. This is consistent with the PMEM driver
and with how this direct_access() pointer is used in the DAX code.
Signed-off-by: Ross Zwisler
Reviewed-by: Christoph Hellwig
---
Documentation/filesy
The goal of this series is to enhance the DAX I/O path so that all operations
that store data (I/O writes, zeroing blocks, punching holes, etc.) properly
synchronize the stores to media using the PMEM API. This ensures that the
data DAX is writing is durable on media before the operation completes
Update the annotation for the kaddr pointer returned by direct_access()
so that it is a __pmem pointer. This is consistent with the PMEM driver
and with how this direct_access() pointer is used in the DAX code.
Signed-off-by: Ross Zwisler
Reviewed-by: Christoph Hellwig
---
Documentation/filesy
The goal of this series is to enhance the DAX I/O path so that all operations
that store data (I/O writes, zeroing blocks, punching holes, etc.) properly
synchronize the stores to media using the PMEM API. This ensures that the data
DAX is writing is durable on media before the operation completes
On Tue, 2015-08-18 at 19:19 +1000, Michael Ellerman wrote:
> On Tue, 2015-08-18 at 16:30 +1000, Andrew Donnellan wrote:
> > If we open a context but do not start it (either because we do not attempt
> > to start it, or because it fails to start for some reason), we are left
> > with a context in st
On Tue, 2015-08-18 at 04:26 -0500, Hou Zhiqiang-B48286 wrote:
> Hi Scott,
>
> Removed both pcibios_fixup_phb and pcibios_fixup_bus.
> Could you please help to apply it?
I applied it and sent a pull request yesterday.
-Scott
___
Linuxppc-dev mailing l
On Mon, 2015-27-07 at 04:39:33 UTC, "David A. Long" wrote:
> From: "David A. Long"
>
> The pt_regs_offset structure is used for the HAVE_REGS_AND_STACK_ACCESS_API
> feature and has identical definitions in four different arch ptrace.h
> include files. It seems unlikely that definition would ever
Hello Michael,
On 08/18/2015 12:24 PM, Michael Ellerman wrote:
> On Thu, 2015-30-07 at 16:18:30 UTC, Javier Martinez Canillas wrote:
>> The I2C core always reports the MODALIAS uevent as "i2c:> regardless if the driver was matched using the I2C id_table or the
>> of_match_table. So the driver need
On Thu, 2015-30-07 at 16:18:30 UTC, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c: regardless if the driver was matched using the I2C id_table or the
> of_match_table. So the driver needs to export the I2C table and this
> be built into the module or udev
On Sat, 2015-25-07 at 05:21:10 UTC, Vasant Hegde wrote:
> This patch implements LED driver for PowerNV platform using the existing
> generic LED class framework.
>
> PowerNV platform has below type of LEDs:
> - System attention
> Indicates there is a problem with the system that needs atte
2015-08-18 12:21 GMT+03:00 Aneesh Kumar K.V :
> Andrey Ryabinin writes:
>
>> 2015-08-18 8:42 GMT+03:00 Aneesh Kumar K.V :
>>> Andrey Ryabinin writes:
>>>
>>>
>>> But that is introducting conditionals in core code for no real benefit.
>>> This also will break when we eventually end up tracking vma
Hi Scott,
Removed both pcibios_fixup_phb and pcibios_fixup_bus.
Could you please help to apply it?
> -Original Message-
> From: Zhiqiang Hou [mailto:b48...@freescale.com]
> Sent: 2015年8月10日 17:40
> To: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wood Scott-
> B07421
> Cc: Hu
Andrey Ryabinin writes:
> 2015-08-18 8:42 GMT+03:00 Aneesh Kumar K.V :
>> Andrey Ryabinin writes:
>>
>>
>> But that is introducting conditionals in core code for no real benefit.
>> This also will break when we eventually end up tracking vmalloc ?
>
> Ok, that's a very good reason to not do this
On Tue, 2015-08-18 at 16:30 +1000, Andrew Donnellan wrote:
> If we open a context but do not start it (either because we do not attempt
> to start it, or because it fails to start for some reason), we are left
> with a context in state OPENED. Previously, cxl_release_context() only
> allowed releas
2015-08-18 8:29 GMT+03:00 Aneesh Kumar K.V :
> Andrey Ryabinin writes:
>
>> On 08/17/2015 09:36 AM, Aneesh Kumar K.V wrote:
>>> We can't use generic functions like print_hex_dump to access kasan
>>> shadow region. This require us to setup another kasan shadow region
>>> for the address passed (kas
2015-08-18 8:42 GMT+03:00 Aneesh Kumar K.V :
> Andrey Ryabinin writes:
>
>> 2015-08-17 12:50 GMT+03:00 Aneesh Kumar K.V
>> :
>>> Because of the above I concluded that we may not be able to do
>>> inline instrumentation. Now if we are not doing inline instrumentation,
>>> we can simplify kasan sup
2015-08-18 8:36 GMT+03:00 Aneesh Kumar K.V :
> Andrey Ryabinin writes:
>
>> 2015-08-17 15:13 GMT+03:00 Andrey Ryabinin :
>>>
>>> Did you disable stack instrumentation (in scripts/Makefile.kasa),
>>> or you version of gcc doesn't support it (e.g. like 4.9.x on x86) ?
>>>
>>> Because this can't work
In order to workaround Erratum A-008139, we have to invalidate the
tlb entry with tlbilx before overwriting. Due to the performance
consideration, we don't add any memory barrier when acquire/release
the tcd lock. This means the two load instructions for esel_next do
have the possibility to return
* Andrew Morton wrote:
> On Tue, 18 Aug 2015 07:38:25 +0200 Christoph Hellwig wrote:
>
> > On Mon, Aug 17, 2015 at 02:24:29PM -0700, Andrew Morton wrote:
> > > 110254 bytes saved, shrinking the kernel by a whopping 0.17%.
> > > Thoughts?
> >
> > Sounds fine to me.
>
> OK, I'll clean it up a
42 matches
Mail list logo
