Hi Pranith,
On Sat, 20 Dec 2014 11:47:18 -0500 Pranith Kumar 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 ce9577d..778844a 100644
> --- a
2014-12-21 5:05 GMT+01:00 Michael Neuling :
>> 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 struct devi
On Sun, Dec 21, 2014 at 4:56 AM, Stephen Rothwell wrote:
> Hi Pranith,
>
> On Sat, 20 Dec 2014 11:47:18 -0500 Pranith Kumar
> 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
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, '/home/pranith/linux/...ftests/exec/
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 som
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 module
This platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: Wolfram Sang
---
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
through. The patches s
This platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: Wolfram Sang
---
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
through. The patches s
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 compi
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:
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 supp
> 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
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 we
On Sun, 2014-12-21 at 13:46 +0100, Rickard Strandqvist wrote:
> 2014-12-21 5:05 GMT+01:00 Michael Neuling :
> >> 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 he
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 CONFIG_PS3_REPOSI
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
---
drivers/pci/iov.c | 19 +++
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 of
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: We
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
---
.../powerpc/pci_iov_resource_on_powernv.txt| 215 +++
From: Gavin Shan
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:
* pci_dn is organized as a hiera
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
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 14 +-
arch/powerpc/platforms/powernv/pci.c |
The field pci_dn->pcidev is assigned but not used.
This patch removes this field.
Signed-off-by: Wei Yang
Acked-by: Gavin Shan
---
arch/powerpc/include/asm/pci-bridge.h |1 -
arch/powerpc/platforms/powernv/pci-ioda.c |1 -
2 files changed, 2 deletions(-)
diff --git a/arch/powerpc/
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
---
arch/powerpc/include/asm/iommu.h |3 +++
arch/powerpc/platforms/powernv/pci-ioda.c | 26 ++
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.
Signed-of
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 power2
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
---
arch/powerpc/include/asm/pci-bridge.h |2 +-
arch/powerpc/platforms/powernv/pci-io
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 pci_
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 co
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
> > 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
From: Cody P Schafer
(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
CC: Haren Myneni
CC: Cody P Schafer
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 pat
From: Cody P Schafer
Helper for constructing static struct perf_pmu_events_attr s.
CC: Sukadev Bhattiprolu
CC: Haren Myneni
CC: Cody P Schafer
Signed-off-by: Cody P Schafer
---
include/linux/perf_event.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/linux/perf_event.h b
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
---
arch/powerpc/perf/hv-common.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/perf/hv-common.h b/arch/power
From: Cody P Schafer
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 HPM_CS_FROM_L4_LDATA__PH
From: Cody P Schafer
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
values to cope with chan
From: Cody P Schafer
Changelog[v6]
[Cody Schafer] Update Contact info to Linux on Power Developer list
CC: Sukadev Bhattiprolu
CC: Haren Myneni
CC: Cody P Schafer
Signed-off-by: Cody P Schafer
---
.../testing/sysfs-bus-event_source-devices-hv_24x7 | 22 ++
1 file
From: Cody P Schafer
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 really means for the ev
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
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] Merge to recent perf-core
From: Cody P Schafer
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
insufficient. For example, P
From: Cody P Schafer
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 Bhattiprolu] Drop the '$' si
From: Cody P Schafer
Changelog[v6]:
- [Sukadev Bhattiprolu]: Update documentation of perf-list and
perf-record; Added documentation for perf-stat.
CC: Haren Myneni
CC: Cody P Schafer
Signed-off-by: Cody P Schafer
Signed-off-by: Sukadev Bhattiprolu
---
tools/perf/Documentat
49 matches
Mail list logo
