Hi Pranith,
On Sat, 20 Dec 2014 11:47:18 -0500 Pranith Kumar bobby.pr...@gmail.com wrote:
Wire up sys_execveat(). This passes the selftests for the system call.
Thanks for this, but ...
diff --git a/arch/powerpc/include/asm/systbl.h
b/arch/powerpc/include/asm/systbl.h
index
2014-12-21 5:05 GMT+01:00 Michael Neuling mi...@neuling.org:
Remove the function mmio_size_show() that is not used anywhere.
Did you compile check this patch?
drivers/misc/cxl/sysfs.c:291:74: error: ‘mmio_size_show’ undeclared here
(not in a function)
It's used here:
static
On Sun, Dec 21, 2014 at 4:56 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
Hi Pranith,
On Sat, 20 Dec 2014 11:47:18 -0500 Pranith Kumar bobby.pr...@gmail.com
wrote:
Wire up sys_execveat(). This passes the selftests for the system call.
Thanks for this, but ...
diff --git
Wire up sys_execveat(). This passes the selftests for the system call.
Check success of execveat(3, '../execveat', 0)... [OK]
Check success of execveat(5, 'execveat', 0)... [OK]
Check success of execveat(6, 'execveat', 0)... [OK]
Check success of execveat(-100,
arch/powerpc/kvm/built-in.o: In function `kvm_no_guest':
arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x724): undefined reference to
`power7_wakeup_loss'
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for
Generated with coccinelle. The big cleanup was pulled in this merge window.
This series catches the bits fallen through. The patches shall go in via the
subsystem trees. If possible for 3.19 to increase consistency I'd say, but you
decide, of course.
cocci-file used:
@match1@
declarer name
This platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
Generated with coccinelle. SmPL file is in the introductory msg. The big
cleanup was pulled in this merge window. This series catches the bits fallen
This platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
Generated with coccinelle. SmPL file is in the introductory msg. The big
cleanup was pulled in this merge window. This series catches the bits fallen
On 21.12.14 15:13, Andreas Schwab wrote:
arch/powerpc/kvm/built-in.o: In function `kvm_no_guest':
arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x724): undefined reference to
`power7_wakeup_loss'
Ugh. We just removed support for 970 HV mode, but that obviously doesn't
mean you can't compile
On Fri, 2014-12-19 at 17:21 +0100, Wolfram Sang wrote:
On Thu, Nov 06, 2014 at 08:50:04PM +1100, Benjamin Herrenschmidt wrote:
On Thu, 2014-11-06 at 10:25 +0100, Wolfram Sang wrote:
On Thu, Nov 06, 2014 at 01:19:36PM +1100, Benjamin Herrenschmidt wrote:
On Thu, 2014-11-06 at 02:45 +0100,
On Sun, 2014-12-21 at 23:56 +0100, Alexander Graf wrote:
On 21.12.14 15:13, Andreas Schwab wrote:
arch/powerpc/kvm/built-in.o: In function `kvm_no_guest':
arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x724): undefined reference
to `power7_wakeup_loss'
Ugh. We just removed support for
On Fri, 2014-12-19 at 01:23 -0600, Xie Shaohui-B21989 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Friday, December 19, 2014 6:01 AM
To: Xie Shaohui-B21989
Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Medve
Emilian- EMMEDVE1; Liberman
On Sat, 2014-20-12 at 22:42:32 UTC, Rickard Strandqvist wrote:
Removes some functions that are not used anywhere:
mpc7448_hpc2_halt() mpc7448_hpc2_power_off()
The other option would be to wire it up.
But the default implementations do more or less the same thing.
As far as I can see these
On Sun, 2014-12-21 at 13:46 +0100, Rickard Strandqvist wrote:
2014-12-21 5:05 GMT+01:00 Michael Neuling mi...@neuling.org:
Remove the function mmio_size_show() that is not used anywhere.
Did you compile check this patch?
drivers/misc/cxl/sysfs.c:291:74: error: ‘mmio_size_show’
On Sat, 2014-20-12 at 15:00:01 UTC, Rickard Strandqvist wrote:
Remove the function ps3_repository_write_highmem_info() that is not used
anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Actually it looks like everything under
This patchset enables the SRIOV on POWER8.
The gerneral 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 BAR.
On P8, we use M64BT to cover a PF's IOV BAR, which could make
VFs are dynamically created/released when driver enable them. On some
platforms, like PowerNV, special resources are necessary to enable VFs.
This patch adds two hooks for platform initialization before creating the VFs.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
drivers/pci/iov.c |
When implementing the SR-IOV on PowerNV platform, some resource reservation is
needed for VFs which don't exist at the bootup stage. To do the match between
resources and VFs, the code need to get the VF's BDF in advance.
In this patch, it exports the interface to retrieve VF's BDF:
* Make the
The alignment of PF's IOV BAR is designed to be the individual size of a VF's
BAR size. This works fine for many platforms, but on PowerNV platform it needs
some change.
The original alignment works, since at sizing and assigning stage the
requirement is from an individual VF's BAR size instead
Currently we don't store the VF BAR size, and each time we calculate the size
by dividing the PF's IOV BAR size by total_VFs.
This patch stores the VF BAR size in pci_sriov and introduces a function to
retrieve it. Also, it adds a log message to show the total PF's IOV BAR size.
Signed-off-by:
At resource sizing/assigning stage, resources are divided into two lists,
requested list and additional list, while the alignement of the additional
IOV BAR is not taken into the sizing and assigning procedure.
This is reasonable in the original implementation, since IOV BAR's alignment is
mostly
In order to enable SRIOV on PowerNV platform, the PF's IOV BAR needs to be
adjusted:
1. size expaned
2. aligned to M64BT size
This patch documents this change on the reason and how.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
.../powerpc/pci_iov_resource_on_powernv.txt
From: Gavin Shan gws...@linux.vnet.ibm.com
pci_dn is the extension of PCI device node and it's created from
device node. Unfortunately, VFs that are enabled dynamically by
PF's driver and they don't have corresponding device nodes, and
pci_dn. The patch refactors pci_dn to support VFs:
*
The PCI config accessors rely on device node. Unfortunately, VFs
don't have corresponding device nodes. So we have to switch to
pci_dn for PCI config access.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 14 +-
The field pci_dn-pcidev is assigned but not used.
This patch removes this field.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Acked-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/pci-bridge.h |1 -
arch/powerpc/platforms/powernv/pci-ioda.c |1 -
2 files
Current iommu_table of a PE is a static field. This will have a problem when
iommu_free_table is called.
This patch allocate iommu_table dynamically.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/iommu.h |3 +++
On PHB3, PF IOV BAR will be covered by M64 BAR to have better PE isolation.
Mostly the total_pe number is different from the total_VFs, which will lead to
a conflict between MMIO space and the PE number.
For example, total_VFs is 128 and total_pe is 256, then the second half of M64
BAR space will
This patch implements the pcibios_iov_resource_alignment() on powernv
platform.
On PowerNV platform, there are 3 cases for the IOV BAR:
1. initial state, the IOV BAR size is multiple times of VF BAR size
2. after expanded, the IOV BAR size is expanded to meet the M64 segment size
3. sizing stage,
On PowrNV platform, resource position in M64 implies the PE# the resource
belongs to. In some particular case, adjustment of a resource is necessary to
locate it to a correct position in M64.
This patch introduces a function to shift the 'real' PF IOV BAR address
according to an offset.
VFs are created, when pci device is enabled.
This patch tries best to assign maximum resources and PEs for VF when pci
device is enabled. Enough M64 assigned to cover the IOV BAR, IOV BAR is
shifted to meet the PE# indicated by M64. VF's pdn-pdev and pdn-pe_number
are fixed.
Signed-off-by: Wei
M64 aperture size is limited on PHB3. When the IOV BAR is too big, this will
exceed the limitation and failed to be assigned.
This patch introduce a different mechanism based on the IOV BAR size:
IOV BAR size is smaller than 64M, expand to total_pe.
IOV BAR size is bigger than 64M, roundup
When IOV BAR is big, each of it is covered by 4 M64 window. This leads to
several VF PE sits in one PE in terms of M64.
This patch group VF PEs according to the M64 allocation.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/pci-bridge.h |2 +-
If we're going to reassign resources with flag PCI_REASSIGN_ALL_RSRC, all
resources will be cleaned out during device header fixup time and then get
reassigned by PCI core. However, the VF resources won't be reassigned and
thus, we shouldn't clean them out.
This patch adds a condition. If the
Bjorn,
This patch set is tested on 3.19-rc1 and with the offset/stride update patch.
I see your comment on the MEM64 issue, so if that is reverted, this
patch set will not work. While I think we can work in parallel, I sent it here
for more comment and to see whether I understand your previous
On Wed, 2014-12-17 at 10:27 +0100, Alexander Graf wrote:
On 17.12.14 04:44, Anton Blanchard wrote:
Hi Alex,
Git bisect managed to point me to this commit as the offender for
OOPSes on e5500 and e6500 (and maybe the G4 as well, not sure).
Doing a git revert of this commit on top of
So, I haven't seen this coming in via ppc. I am going to send another
pull request to Linus tomorrow and will include it unless somebody
objects soon.
Sorry, communication break down between Ben I. I'm happy for you to take it.
It is already upstream :) But thanks!
signature.asc
From: Cody P Schafer c...@linux.vnet.ibm.com
(struct perf_pmu_events_attr) is defined in include/linux/perf_event.h,
but the only show for it is in x86 and contains x86 specific stuff.
Make a generic one for those of us who are just using the event_str.
CC: Sukadev Bhattiprolu
The current support for the 24x7 and GPCI counters in the kernel requires
users to specify the domain and offset of the event numerically, which is
obviously hard to use:
perf stat -C 0 -e \
'hv_24x7/domain=2,offset=0xd58,starting_index=0,lpar=0x/' \
sleep 1
This
From: Cody P Schafer c...@linux.vnet.ibm.com
Helper for constructing static struct perf_pmu_events_attr s.
CC: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
CC: Haren Myneni hb...@us.ibm.com
CC: Cody P Schafer d...@codyps.com
Signed-off-by: Cody P Schafer c...@linux.vnet.ibm.com
---
Define a lite version of the EVENT_DEFINE_RANGE_FORMAT() that avoids
defining helper functions for the bit-field ranges.
Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
---
arch/powerpc/perf/hv-common.h | 10 ++
1 file changed, 10 insertions(+)
diff --git
From: Cody P Schafer c...@linux.vnet.ibm.com
Retrieves and parses the 24x7 catalog on POWER systems that supply it
(right now, only POWER 8). Events are exposed via sysfs in the standard
fashion, and are all parameterized.
$ cd /sys/bus/event_source/devices/hv_24x7/events
$ cat
From: Cody P Schafer c...@linux.vnet.ibm.com
This adds (in req-gen/) a framework for defining gpci counter requests.
It uses macro magic similar to ftrace.
Also convert the existing hv-gpci request structures and enum values to
use the new framework (and adjust old users of the structs and enum
From: Cody P Schafer c...@linux.vnet.ibm.com
Changelog[v6]
[Cody Schafer] Update Contact info to Linux on Power Developer list
CC: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
CC: Haren Myneni hb...@us.ibm.com
CC: Cody P Schafer d...@codyps.com
Signed-off-by: Cody P Schafer
From: Cody P Schafer c...@linux.vnet.ibm.com
Add the remaining gpci requests that contain counters suitable for use
by perf. Omit those that don't contain any counters (but note their
ommision).
Changelog[v6]
[Jiri Olsa, Sukadev Bhattiprolu] Replace 'starting_index' with what
it
Description of event parameters from the documentation patch:
Event parameters are a basic way for partial events to be specified in
sysfs with per-event names given to the fields that need to be filled in
when using a particular event.
It is intended for supporting cases where
From: Cody P Schafer c...@linux.vnet.ibm.com
Enable event specification like:
pmu/event_name,param1=0x1,param2=0x4/
Assuming that
/sys/bus/event_source/devices/pmu/events/event_name
Contains something like
param2=?,bar=1,param1=?
Changelog[v4]:
[Jiri Olsa]
From: Cody P Schafer c...@linux.vnet.ibm.com
Event parameters are a basic way for partial events to be specified in
sysfs with per-event names given to the fields that need to be filled in
when using a particular event.
It is intended for supporting cases where the single 'cpu' parameter is
From: Cody P Schafer c...@linux.vnet.ibm.com
This causes `perf list pmu` to show parameters for parameterized events
like:
pmu/event_name,param1=?,param2=?/ [Kernel PMU event]
An example:
hv_24x7/HPM_TLBIE__PHYS_CORE,core=?/ [Kernel PMU event]
Changelog[v6]
[Jir Olsa, Sukadev
From: Cody P Schafer c...@linux.vnet.ibm.com
Changelog[v6]:
- [Sukadev Bhattiprolu]: Update documentation of perf-list and
perf-record; Added documentation for perf-stat.
CC: Haren Myneni hb...@us.ibm.com
CC: Cody P Schafer d...@codyps.com
Signed-off-by: Cody P Schafer
49 matches
Mail list logo
