LinuxPPC-Dev Archive on lore.kernel.org

LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed

* Re: [PATCH] powerpc/fsl: Add support for pci(e) machine check exception on E500MC / E5500
From: Guenter Roeck @ 2014-09-30 15:50 UTC (permalink / raw)
  To: Scott Wood
  Cc: hongtao.jia@freescale.com, linux-kernel@vger.kernel.org,
	Guenter Roeck, Paul Mackerras, linuxppc-dev@lists.ozlabs.org,
	Jojy Varghese
In-Reply-To: <1412033466.13320.293.camel@snotra.buserror.net>

On Mon, Sep 29, 2014 at 06:31:06PM -0500, Scott Wood wrote:
> On Mon, 2014-09-29 at 23:03 +0000, Jojy Varghese wrote:
> > 
> > On 9/29/14 12:06 PM, "Guenter Roeck" <linux@roeck-us.net> wrote:
> > 
> > >On Mon, Sep 29, 2014 at 01:36:06PM -0500, Scott Wood wrote:
> > >> On Mon, 2014-09-29 at 09:48 -0700, Guenter Roeck wrote:
> > >> > From: Jojy G Varghese <jojyv@juniper.net>
> > >> > 
> > >> > For E500MC and E5500, a machine check exception in pci(e) memory space
> > >> > crashes the kernel.
> > >> > 
> > >> > Testing shows that the MCAR(U) register is zero on a MC exception for
> > >>the
> > >> > E5500 core. At the same time, DEAR register has been found to have the
> > >> > address of the faulty load address during an MC exception for this
> > >>core.
> > >> > 
> > >> > This fix changes the current behavior to fixup the result register
> > >> > and instruction pointers in the case of a load operation on a faulty
> > >> > PCI address.
> > >> > 
> > >> > The changes are:
> > >> > - Added the hook to pci machine check handing to the e500mc machine
> > >>check
> > >> >   exception handler.
> > >> > - For the E5500 core, load faulting address from SPRN_DEAR register.
> > >> >   As mentioned above, this is necessary because the E5500 core does
> > >>not
> > >> >   report the fault address in the MCAR register.
> > >> > 
> > >> > Cc: Scott Wood <scottwood@freescale.com>
> > >> > Signed-off-by: Jojy G Varghese <jojyv@juniper.net>
> > >> > [Guenter Roeck: updated description]
> > >> > Signed-off-by: Guenter Roeck <groeck@juniper.net>
> > >> > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > >> > ---
> > >> >  arch/powerpc/kernel/traps.c   | 3 ++-
> > >> >  arch/powerpc/sysdev/fsl_pci.c | 5 +++++
> > >> >  2 files changed, 7 insertions(+), 1 deletion(-)
> > >> > 
> > >> > diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> > >> > index 0dc43f9..ecb709b 100644
> > >> > --- a/arch/powerpc/kernel/traps.c
> > >> > +++ b/arch/powerpc/kernel/traps.c
> > >> > @@ -494,7 +494,8 @@ int machine_check_e500mc(struct pt_regs *regs)
> > >> >  	int recoverable = 1;
> > >> >  
> > >> >  	if (reason & MCSR_LD) {
> > >> > -		recoverable = fsl_rio_mcheck_exception(regs);
> > >> > +		recoverable = fsl_rio_mcheck_exception(regs) ||
> > >> > +			fsl_pci_mcheck_exception(regs);
> > >> >  		if (recoverable == 1)
> > >> >  			goto silent_out;
> > >> >  	}
> > >> > diff --git a/arch/powerpc/sysdev/fsl_pci.c
> > >>b/arch/powerpc/sysdev/fsl_pci.c
> > >> > index c507767..bdb956b 100644
> > >> > --- a/arch/powerpc/sysdev/fsl_pci.c
> > >> > +++ b/arch/powerpc/sysdev/fsl_pci.c
> > >> > @@ -1021,6 +1021,11 @@ int fsl_pci_mcheck_exception(struct pt_regs
> > >>*regs)
> > >> >  #endif
> > >> >  	addr += mfspr(SPRN_MCAR);
> > >> >  
> > >> > +#ifdef CONFIG_E5500_CPU
> > >> > +	if (mfspr(SPRN_EPCR) & SPRN_EPCR_ICM)
> > >> > +		addr = PFN_PHYS(vmalloc_to_pfn((void *)mfspr(SPRN_DEAR)));
> > >> > +#endif
> > >> 
> > >> Kconfig tells you what hardware is supported, not what hardware you're
> > >> actually running on.
> 
> Plus, CONFIG_E5500_CPU may not even be set when running on an e5500, as
> it is used for selecting GCC optimization settings.  You could have
> CONFIG_GENERIC_CPU instead.
> 
> And the subject says "E500MC / E5500", not just "E5500". :-)
> 
> > >Hi Scott,
> > >
> > >Good point. Jojy, guess we'll have to check if the CPU is actually an
> > >E5500.
> > >Can you look into that ?
> > 
> > 
> > "/proc/cpuinfo" shows the cpu as "e5500". Scott, are you suggesting that
> > we use a runtime method of determining the cpu type (cpu_spec's cpu_name
> > for
> > example).  
> 
> Yes, if there's a bug to be worked around, and we don't want to apply
> the workaround unconditionally, you should use PVR to determine whether
> you're running on an affected core.
> 
> > >> Can we rely on DEAR or is this just a side effect of likely having taken
> > >> a TLB miss for the address recently?  Perhaps we should use the
> > >> instruction emulation to determine the effective address instead.
> > >> 
> > >> Guenter, is this patch intended to deal with an erratum or are you
> > >> covering up legitimate errors?
> > >> 
> >
> > >Those are errors related to PCIe hotplug, and are seen with unexpected
> > >PCIe
> > >device removals (triggered, for example, by removing power from a PCIe
> > >adapter).
> > >The behavior we see on E5500 is quite similar to the same behavior on
> > >E500:
> > >If unhandled, the CPU keeps executing the same instruction over and over
> > >again
> > >if there is an error on a PCIe access and thus stalls. I don't know if
> > >this
> > >is considered an erratum or expected behavior, but it is one we have to
> > >address
> > >since we have to be able to handle that condition. 
> 
> The reason I ask is that the handling for e500 was described as an
> erratum workaround.  If it is an erratum it would be nice to know the
> erratum number and the full list of affected chips.
> 
My understanding, which may be wrong, was that this is expected behavior,
at least for E5500. I actually thought I had seen it somewhere in the
specification (response to PCIe errors), but I don't recall where exactly.

At least for my part I am not aware of an erratum.

> > >Ultimately, we'll want
> > >to
> > >implement PCIe error handlers for the affected drivers, but that will be
> > >a next
> > >step.
> 
> For now can we at least print a ratelimited error message?  I don't like
> the idea of silently ignoring these errors.  I suppose it's a separate
> issue from extending the workaround to cover e500mc, though.
> 
I don't really like the idea of printing an error message pretty much each time
when an unexpected hotplug event occurs.

> > According to the spec, we MCAR is supposed to hold the faulty data address
> > but for 5500 core, we found that MCAR is zero.
> 
> Which specific chip and revision did you see this on?  What is the value
> in MCSR?
> 
Jojy can answer that, at least for P5020. We have seen it on P5040 as well,
though, so it is not just limited to one chip/revision.

Guenter

> > You are right that DEAR entry could
> > be a resultOf a TLB miss but that¹s the register we could rely on.
> 
> If it's the result of a previous TLB miss then we can't rely on it.  The
> translation might have been loaded into the TLB before the hotplug
> event, or there might have been an interrupt between loading the
> translation into the TLB and using the translation.
> 
> > What do you mean by "instruction emulation"? 
> 
> mcheck_handle_load()
> 
> > Are you suggesting that we
> > examine the RD, RS 
> > registers for the instruction?
> 
> Yes, if we don't have a simpler reliable source of the address.
> 
> -Scott
> 
> 

^ permalink raw reply

* Re: [PATCH 0/9] powerpc/powernv: Support for fastsleep and winkle
From: Rafael J. Wysocki @ 2014-09-30 20:13 UTC (permalink / raw)
  To: Shreyas B Prabhu
  Cc: devicetree, Srivatsa S. Bhat, linux-pm, linux-kernel,
	Grant Likely, Rob Herring, Paul Mackerras, Preeti U. Murthy,
	linuxppc-dev
In-Reply-To: <542A65D5.4090003@linux.vnet.ibm.com>

On Tuesday, September 30, 2014 01:42:05 PM Shreyas B Prabhu wrote:
> Hi Rafael,
> 
> On Tuesday 30 September 2014 04:58 AM, Rafael J. Wysocki wrote:
> > On Monday, September 29, 2014 03:53:06 PM Shreyas B Prabhu wrote:
> >> Hi,
> >> Any updates on this patch series?
> > 
> > I have a couple of patches from there in my tree it seems.  Please have a look
> > at linux-pm.git/linux-next and please let me know if that's the case.
> > 
> 
> I checked linux-pm.git/linux-net (Last commit 067c17382165). None of the patches
> in this series are present in the tree. 

OK, thanks for checking.

Would you mind resending it with any ACKs or Reviewed-by tags received so far?


> >> On Thursday 18 September 2014 08:41 AM, Shreyas B Prabhu wrote:
> >>> Hi,
> >>>
> >>> In this patch series we use winkle for offlined cores. I successfully
> >>> tested the working of this with subcore functionality.
> >>>
> >>> Test scenario was as follows:
> >>> 1. Set SMT mode to 1, Set subores-per-core to 1
> >>> 2. Offline a core, in this case cpu 32 (sending it to winkle)
> >>> 3. Set subcores-per-core to 4
> >>> 4. Online the core
> >>> 5. Start a guest (Topology 1 core 2 threads) on a subcore, in this case
> >>> on cpu 36
> >>>
> >>> This works without any glitch.
> >>>
> >>> Thanks,
> >>> Shreyas
> >>>
> >>> On Monday 25 August 2014 11:31 PM, Shreyas B. Prabhu wrote:
> >>>> Fast sleep is an idle state, where the core and the L1 and L2
> >>>> caches are brought down to a threshold voltage. This also means that
> >>>> the communication between L2 and L3 caches have to be fenced. However
> >>>> the current P8 chips have a bug wherein this fencing between L2 and
> >>>> L3 caches get delayed by a cpu cycle. This can delay L3 response to
> >>>> the other cpus if they request for data during this time. Thus they
> >>>> would fetch the same data from the memory which could lead to data
> >>>> corruption if L3 cache is not flushed.
> >>>> Patch 4 adds support to work around this.
> >>>>
> >>>> 'Deep Winkle' is a deeper idle state where core and private L2 are powered
> >>>> off. While it offers higher power savings, it is at the cost of losing
> >>>> hypervisor register state and higher latency.
> >>>> Patch 5-9 adds support for winkle and uses it for offline cpus.
> >>>>
> >>>> Patch 1 - Moves parameters required discover idle states to a location 
> >>>> common to both cpuidle driver and powernv core code
> >>>> Patch 2 - Populates idle state details from device tree
> >>>> Patch 3 - Enables cpus to run guest after waking up from fastsleep/winkle
> >>>>
> >>>>
> >>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >>>> Cc: Paul Mackerras <paulus@samba.org>
> >>>> Cc: Michael Ellerman <mpe@ellerman.id.au>
> >>>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> >>>> Cc: Srivatsa S. Bhat <srivatsa@MIT.EDU>
> >>>> Cc: Preeti U. Murthy <preeti@linux.vnet.ibm.com>
> >>>> Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
> >>>> Cc: Rob Herring <robh+dt@kernel.org>
> >>>> Cc: Grant Likely <grant.likely@linaro.org>
> >>>> Cc: devicetree@vger.kernel.org
> >>>> Cc: linux-pm@vger.kernel.org
> >>>> Cc: linuxppc-dev@lists.ozlabs.org
> >>>>
> >>>> Preeti U Murthy (2):
> >>>>   cpuidle/powernv: Populate cpuidle state details by querying the
> >>>>     device-tree
> >>>>   powerpc/powernv/cpuidle: Add workaround to enable fastsleep
> >>>>
> >>>> Shreyas B. Prabhu (6):
> >>>>   powerpc/kvm/book3s_hv: Enable CPUs to run guest after waking up from
> >>>>     fast-sleep
> >>>>   powerpc/powernv: Add OPAL call to save and restore
> >>>>   powerpc: Adding macro for accessing Thread Switch Control Register
> >>>>   powerpc/powernv: Add winkle infrastructure
> >>>>   powerpc/powernv: Discover and enable winkle
> >>>>   powerpc/powernv: Enter deepest supported idle state in offline
> >>>>
> >>>> Srivatsa S. Bhat (1):
> >>>>   powerpc/powernv: Enable Offline CPUs to enter deep idle states
> >>>>
> >>>>  arch/powerpc/include/asm/machdep.h             |   4 +
> >>>>  arch/powerpc/include/asm/opal.h                |  10 ++
> >>>>  arch/powerpc/include/asm/paca.h                |   3 +
> >>>>  arch/powerpc/include/asm/ppc-opcode.h          |   2 +
> >>>>  arch/powerpc/include/asm/processor.h           |   6 +-
> >>>>  arch/powerpc/include/asm/reg.h                 |   1 +
> >>>>  arch/powerpc/kernel/asm-offsets.c              |   1 +
> >>>>  arch/powerpc/kernel/exceptions-64s.S           |  37 ++---
> >>>>  arch/powerpc/kernel/idle.c                     |  30 ++++
> >>>>  arch/powerpc/kernel/idle_power7.S              |  83 +++++++++-
> >>>>  arch/powerpc/platforms/powernv/opal-wrappers.S |   2 +
> >>>>  arch/powerpc/platforms/powernv/powernv.h       |   8 +
> >>>>  arch/powerpc/platforms/powernv/setup.c         | 217 +++++++++++++++++++++++++
> >>>>  arch/powerpc/platforms/powernv/smp.c           |  13 +-
> >>>>  arch/powerpc/platforms/powernv/subcore.c       |  15 ++
> >>>>  drivers/cpuidle/cpuidle-powernv.c              |  40 ++++-
> >>>>  16 files changed, 439 insertions(+), 33 deletions(-)
> >>>>
> >>
> > 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply

* Re: [PATCH] powerpc/fsl: Add support for pci(e) machine check exception on E500MC / E5500
From: Scott Wood @ 2014-09-30 20:17 UTC (permalink / raw)
  To: Jojy Varghese
  Cc: hongtao.jia@freescale.com, linux-kernel@vger.kernel.org,
	Guenter Roeck, Paul Mackerras, linuxppc-dev@lists.ozlabs.org,
	Guenter Roeck
In-Reply-To: <D0505C72.10E3B%jojyv@juniper.net>

On Tue, 2014-09-30 at 20:15 +0000, Jojy Varghese wrote:
> 
> On 9/30/14 8:50 AM, "Guenter Roeck" <linux@roeck-us.net> wrote:
> 
> >On Mon, Sep 29, 2014 at 06:31:06PM -0500, Scott Wood wrote:
> >> Which specific chip and revision did you see this on?  What is the value
> >> in MCSR?
> >> 
> >Jojy can answer that, at least for P5020. We have seen it on P5040 as
> >well,
> >though, so it is not just limited to one chip/revision.
> 
> The specifics are:
> PVR: 0x80240012
> Instruction that causes the MC exception: lwbrx
> 	The faulty load address is also present in RB. So we could change the
> logic to use that 
> instead of DEAR. What I don’t know is of there are other cases also which
> escapes the current logic.

Could you find out what MCSR was when that happened?  I'm most
interested in whether MAV was set, but the other bits would be
interesting as well.

-Scott

^ permalink raw reply

* Re: [PATCH] powerpc/fsl: Add support for pci(e) machine check exception on E500MC / E5500
From: Jojy Varghese @ 2014-09-30 20:15 UTC (permalink / raw)
  To: Guenter Roeck, Scott Wood
  Cc: hongtao.jia@freescale.com, Guenter Roeck,
	linux-kernel@vger.kernel.org, Paul Mackerras,
	linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20140930155029.GA4724@roeck-us.net>

DQoNCk9uIDkvMzAvMTQgODo1MCBBTSwgIkd1ZW50ZXIgUm9lY2siIDxsaW51eEByb2Vjay11cy5u
ZXQ+IHdyb3RlOg0KDQo+T24gTW9uLCBTZXAgMjksIDIwMTQgYXQgMDY6MzE6MDZQTSAtMDUwMCwg
U2NvdHQgV29vZCB3cm90ZToNCj4+IE9uIE1vbiwgMjAxNC0wOS0yOSBhdCAyMzowMyArMDAwMCwg
Sm9qeSBWYXJnaGVzZSB3cm90ZToNCj4+ID4gDQo+PiA+IE9uIDkvMjkvMTQgMTI6MDYgUE0sICJH
dWVudGVyIFJvZWNrIiA8bGludXhAcm9lY2stdXMubmV0PiB3cm90ZToNCj4+ID4gDQo+PiA+ID5P
biBNb24sIFNlcCAyOSwgMjAxNCBhdCAwMTozNjowNlBNIC0wNTAwLCBTY290dCBXb29kIHdyb3Rl
Og0KPj4gPiA+PiBPbiBNb24sIDIwMTQtMDktMjkgYXQgMDk6NDggLTA3MDAsIEd1ZW50ZXIgUm9l
Y2sgd3JvdGU6DQo+PiA+ID4+ID4gRnJvbTogSm9qeSBHIFZhcmdoZXNlIDxqb2p5dkBqdW5pcGVy
Lm5ldD4NCj4+ID4gPj4gPiANCj4+ID4gPj4gPiBGb3IgRTUwME1DIGFuZCBFNTUwMCwgYSBtYWNo
aW5lIGNoZWNrIGV4Y2VwdGlvbiBpbiBwY2koZSkgbWVtb3J5DQo+PnNwYWNlDQo+PiA+ID4+ID4g
Y3Jhc2hlcyB0aGUga2VybmVsLg0KPj4gPiA+PiA+IA0KPj4gPiA+PiA+IFRlc3Rpbmcgc2hvd3Mg
dGhhdCB0aGUgTUNBUihVKSByZWdpc3RlciBpcyB6ZXJvIG9uIGEgTUMNCj4+ZXhjZXB0aW9uIGZv
cg0KPj4gPiA+PnRoZQ0KPj4gPiA+PiA+IEU1NTAwIGNvcmUuIEF0IHRoZSBzYW1lIHRpbWUsIERF
QVIgcmVnaXN0ZXIgaGFzIGJlZW4gZm91bmQgdG8NCj4+aGF2ZSB0aGUNCj4+ID4gPj4gPiBhZGRy
ZXNzIG9mIHRoZSBmYXVsdHkgbG9hZCBhZGRyZXNzIGR1cmluZyBhbiBNQyBleGNlcHRpb24gZm9y
DQo+PnRoaXMNCj4+ID4gPj5jb3JlLg0KPj4gPiA+PiA+IA0KPj4gPiA+PiA+IFRoaXMgZml4IGNo
YW5nZXMgdGhlIGN1cnJlbnQgYmVoYXZpb3IgdG8gZml4dXAgdGhlIHJlc3VsdA0KPj5yZWdpc3Rl
cg0KPj4gPiA+PiA+IGFuZCBpbnN0cnVjdGlvbiBwb2ludGVycyBpbiB0aGUgY2FzZSBvZiBhIGxv
YWQgb3BlcmF0aW9uIG9uIGENCj4+ZmF1bHR5DQo+PiA+ID4+ID4gUENJIGFkZHJlc3MuDQo+PiA+
ID4+ID4gDQo+PiA+ID4+ID4gVGhlIGNoYW5nZXMgYXJlOg0KPj4gPiA+PiA+IC0gQWRkZWQgdGhl
IGhvb2sgdG8gcGNpIG1hY2hpbmUgY2hlY2sgaGFuZGluZyB0byB0aGUgZTUwMG1jDQo+Pm1hY2hp
bmUNCj4+ID4gPj5jaGVjaw0KPj4gPiA+PiA+ICAgZXhjZXB0aW9uIGhhbmRsZXIuDQo+PiA+ID4+
ID4gLSBGb3IgdGhlIEU1NTAwIGNvcmUsIGxvYWQgZmF1bHRpbmcgYWRkcmVzcyBmcm9tIFNQUk5f
REVBUg0KPj5yZWdpc3Rlci4NCj4+ID4gPj4gPiAgIEFzIG1lbnRpb25lZCBhYm92ZSwgdGhpcyBp
cyBuZWNlc3NhcnkgYmVjYXVzZSB0aGUgRTU1MDAgY29yZQ0KPj5kb2VzDQo+PiA+ID4+bm90DQo+
PiA+ID4+ID4gICByZXBvcnQgdGhlIGZhdWx0IGFkZHJlc3MgaW4gdGhlIE1DQVIgcmVnaXN0ZXIu
DQo+PiA+ID4+ID4gDQo+PiA+ID4+ID4gQ2M6IFNjb3R0IFdvb2QgPHNjb3R0d29vZEBmcmVlc2Nh
bGUuY29tPg0KPj4gPiA+PiA+IFNpZ25lZC1vZmYtYnk6IEpvankgRyBWYXJnaGVzZSA8am9qeXZA
anVuaXBlci5uZXQ+DQo+PiA+ID4+ID4gW0d1ZW50ZXIgUm9lY2s6IHVwZGF0ZWQgZGVzY3JpcHRp
b25dDQo+PiA+ID4+ID4gU2lnbmVkLW9mZi1ieTogR3VlbnRlciBSb2VjayA8Z3JvZWNrQGp1bmlw
ZXIubmV0Pg0KPj4gPiA+PiA+IFNpZ25lZC1vZmYtYnk6IEd1ZW50ZXIgUm9lY2sgPGxpbnV4QHJv
ZWNrLXVzLm5ldD4NCj4+ID4gPj4gPiAtLS0NCj4+ID4gPj4gPiAgYXJjaC9wb3dlcnBjL2tlcm5l
bC90cmFwcy5jICAgfCAzICsrLQ0KPj4gPiA+PiA+ICBhcmNoL3Bvd2VycGMvc3lzZGV2L2ZzbF9w
Y2kuYyB8IDUgKysrKysNCj4+ID4gPj4gPiAgMiBmaWxlcyBjaGFuZ2VkLCA3IGluc2VydGlvbnMo
KyksIDEgZGVsZXRpb24oLSkNCj4+ID4gPj4gPiANCj4+ID4gPj4gPiBkaWZmIC0tZ2l0IGEvYXJj
aC9wb3dlcnBjL2tlcm5lbC90cmFwcy5jDQo+PmIvYXJjaC9wb3dlcnBjL2tlcm5lbC90cmFwcy5j
DQo+PiA+ID4+ID4gaW5kZXggMGRjNDNmOS4uZWNiNzA5YiAxMDA2NDQNCj4+ID4gPj4gPiAtLS0g
YS9hcmNoL3Bvd2VycGMva2VybmVsL3RyYXBzLmMNCj4+ID4gPj4gPiArKysgYi9hcmNoL3Bvd2Vy
cGMva2VybmVsL3RyYXBzLmMNCj4+ID4gPj4gPiBAQCAtNDk0LDcgKzQ5NCw4IEBAIGludCBtYWNo
aW5lX2NoZWNrX2U1MDBtYyhzdHJ1Y3QgcHRfcmVncw0KPj4qcmVncykNCj4+ID4gPj4gPiAgCWlu
dCByZWNvdmVyYWJsZSA9IDE7DQo+PiA+ID4+ID4gIA0KPj4gPiA+PiA+ICAJaWYgKHJlYXNvbiAm
IE1DU1JfTEQpIHsNCj4+ID4gPj4gPiAtCQlyZWNvdmVyYWJsZSA9IGZzbF9yaW9fbWNoZWNrX2V4
Y2VwdGlvbihyZWdzKTsNCj4+ID4gPj4gPiArCQlyZWNvdmVyYWJsZSA9IGZzbF9yaW9fbWNoZWNr
X2V4Y2VwdGlvbihyZWdzKSB8fA0KPj4gPiA+PiA+ICsJCQlmc2xfcGNpX21jaGVja19leGNlcHRp
b24ocmVncyk7DQo+PiA+ID4+ID4gIAkJaWYgKHJlY292ZXJhYmxlID09IDEpDQo+PiA+ID4+ID4g
IAkJCWdvdG8gc2lsZW50X291dDsNCj4+ID4gPj4gPiAgCX0NCj4+ID4gPj4gPiBkaWZmIC0tZ2l0
IGEvYXJjaC9wb3dlcnBjL3N5c2Rldi9mc2xfcGNpLmMNCj4+ID4gPj5iL2FyY2gvcG93ZXJwYy9z
eXNkZXYvZnNsX3BjaS5jDQo+PiA+ID4+ID4gaW5kZXggYzUwNzc2Ny4uYmRiOTU2YiAxMDA2NDQN
Cj4+ID4gPj4gPiAtLS0gYS9hcmNoL3Bvd2VycGMvc3lzZGV2L2ZzbF9wY2kuYw0KPj4gPiA+PiA+
ICsrKyBiL2FyY2gvcG93ZXJwYy9zeXNkZXYvZnNsX3BjaS5jDQo+PiA+ID4+ID4gQEAgLTEwMjEs
NiArMTAyMSwxMSBAQCBpbnQgZnNsX3BjaV9tY2hlY2tfZXhjZXB0aW9uKHN0cnVjdA0KPj5wdF9y
ZWdzDQo+PiA+ID4+KnJlZ3MpDQo+PiA+ID4+ID4gICNlbmRpZg0KPj4gPiA+PiA+ICAJYWRkciAr
PSBtZnNwcihTUFJOX01DQVIpOw0KPj4gPiA+PiA+ICANCj4+ID4gPj4gPiArI2lmZGVmIENPTkZJ
R19FNTUwMF9DUFUNCj4+ID4gPj4gPiArCWlmIChtZnNwcihTUFJOX0VQQ1IpICYgU1BSTl9FUENS
X0lDTSkNCj4+ID4gPj4gPiArCQlhZGRyID0gUEZOX1BIWVModm1hbGxvY190b19wZm4oKHZvaWQg
KiltZnNwcihTUFJOX0RFQVIpKSk7DQo+PiA+ID4+ID4gKyNlbmRpZg0KPj4gPiA+PiANCj4+ID4g
Pj4gS2NvbmZpZyB0ZWxscyB5b3Ugd2hhdCBoYXJkd2FyZSBpcyBzdXBwb3J0ZWQsIG5vdCB3aGF0
IGhhcmR3YXJlDQo+PnlvdSdyZQ0KPj4gPiA+PiBhY3R1YWxseSBydW5uaW5nIG9uLg0KPj4gDQo+
PiBQbHVzLCBDT05GSUdfRTU1MDBfQ1BVIG1heSBub3QgZXZlbiBiZSBzZXQgd2hlbiBydW5uaW5n
IG9uIGFuIGU1NTAwLCBhcw0KPj4gaXQgaXMgdXNlZCBmb3Igc2VsZWN0aW5nIEdDQyBvcHRpbWl6
YXRpb24gc2V0dGluZ3MuICBZb3UgY291bGQgaGF2ZQ0KPj4gQ09ORklHX0dFTkVSSUNfQ1BVIGlu
c3RlYWQuDQo+PiANCj4+IEFuZCB0aGUgc3ViamVjdCBzYXlzICJFNTAwTUMgLyBFNTUwMCIsIG5v
dCBqdXN0ICJFNTUwMCIuIDotKQ0KPj4gDQo+PiA+ID5IaSBTY290dCwNCj4+ID4gPg0KPj4gPiA+
R29vZCBwb2ludC4gSm9qeSwgZ3Vlc3Mgd2UnbGwgaGF2ZSB0byBjaGVjayBpZiB0aGUgQ1BVIGlz
IGFjdHVhbGx5IGFuDQo+PiA+ID5FNTUwMC4NCj4+ID4gPkNhbiB5b3UgbG9vayBpbnRvIHRoYXQg
Pw0KPj4gPiANCj4+ID4gDQo+PiA+ICIvcHJvYy9jcHVpbmZvIiBzaG93cyB0aGUgY3B1IGFzICJl
NTUwMCIuIFNjb3R0LCBhcmUgeW91IHN1Z2dlc3RpbmcNCj4+dGhhdA0KPj4gPiB3ZSB1c2UgYSBy
dW50aW1lIG1ldGhvZCBvZiBkZXRlcm1pbmluZyB0aGUgY3B1IHR5cGUgKGNwdV9zcGVjJ3MNCj4+
Y3B1X25hbWUNCj4+ID4gZm9yDQo+PiA+IGV4YW1wbGUpLiAgDQo+PiANCj4+IFllcywgaWYgdGhl
cmUncyBhIGJ1ZyB0byBiZSB3b3JrZWQgYXJvdW5kLCBhbmQgd2UgZG9uJ3Qgd2FudCB0byBhcHBs
eQ0KPj4gdGhlIHdvcmthcm91bmQgdW5jb25kaXRpb25hbGx5LCB5b3Ugc2hvdWxkIHVzZSBQVlIg
dG8gZGV0ZXJtaW5lIHdoZXRoZXINCj4+IHlvdSdyZSBydW5uaW5nIG9uIGFuIGFmZmVjdGVkIGNv
cmUuDQo+PiANCj4+ID4gPj4gQ2FuIHdlIHJlbHkgb24gREVBUiBvciBpcyB0aGlzIGp1c3QgYSBz
aWRlIGVmZmVjdCBvZiBsaWtlbHkgaGF2aW5nDQo+PnRha2VuDQo+PiA+ID4+IGEgVExCIG1pc3Mg
Zm9yIHRoZSBhZGRyZXNzIHJlY2VudGx5PyAgUGVyaGFwcyB3ZSBzaG91bGQgdXNlIHRoZQ0KPj4g
PiA+PiBpbnN0cnVjdGlvbiBlbXVsYXRpb24gdG8gZGV0ZXJtaW5lIHRoZSBlZmZlY3RpdmUgYWRk
cmVzcyBpbnN0ZWFkLg0KPj4gPiA+PiANCj4+ID4gPj4gR3VlbnRlciwgaXMgdGhpcyBwYXRjaCBp
bnRlbmRlZCB0byBkZWFsIHdpdGggYW4gZXJyYXR1bSBvciBhcmUgeW91DQo+PiA+ID4+IGNvdmVy
aW5nIHVwIGxlZ2l0aW1hdGUgZXJyb3JzPw0KPj4gPiA+PiANCj4+ID4NCj4+ID4gPlRob3NlIGFy
ZSBlcnJvcnMgcmVsYXRlZCB0byBQQ0llIGhvdHBsdWcsIGFuZCBhcmUgc2VlbiB3aXRoDQo+PnVu
ZXhwZWN0ZWQNCj4+ID4gPlBDSWUNCj4+ID4gPmRldmljZSByZW1vdmFscyAodHJpZ2dlcmVkLCBm
b3IgZXhhbXBsZSwgYnkgcmVtb3ZpbmcgcG93ZXIgZnJvbSBhDQo+PlBDSWUNCj4+ID4gPmFkYXB0
ZXIpLg0KPj4gPiA+VGhlIGJlaGF2aW9yIHdlIHNlZSBvbiBFNTUwMCBpcyBxdWl0ZSBzaW1pbGFy
IHRvIHRoZSBzYW1lIGJlaGF2aW9yIG9uDQo+PiA+ID5FNTAwOg0KPj4gPiA+SWYgdW5oYW5kbGVk
LCB0aGUgQ1BVIGtlZXBzIGV4ZWN1dGluZyB0aGUgc2FtZSBpbnN0cnVjdGlvbiBvdmVyIGFuZA0K
Pj5vdmVyDQo+PiA+ID5hZ2Fpbg0KPj4gPiA+aWYgdGhlcmUgaXMgYW4gZXJyb3Igb24gYSBQQ0ll
IGFjY2VzcyBhbmQgdGh1cyBzdGFsbHMuIEkgZG9uJ3Qga25vdw0KPj5pZg0KPj4gPiA+dGhpcw0K
Pj4gPiA+aXMgY29uc2lkZXJlZCBhbiBlcnJhdHVtIG9yIGV4cGVjdGVkIGJlaGF2aW9yLCBidXQg
aXQgaXMgb25lIHdlIGhhdmUNCj4+dG8NCj4+ID4gPmFkZHJlc3MNCj4+ID4gPnNpbmNlIHdlIGhh
dmUgdG8gYmUgYWJsZSB0byBoYW5kbGUgdGhhdCBjb25kaXRpb24uDQo+PiANCj4+IFRoZSByZWFz
b24gSSBhc2sgaXMgdGhhdCB0aGUgaGFuZGxpbmcgZm9yIGU1MDAgd2FzIGRlc2NyaWJlZCBhcyBh
bg0KPj4gZXJyYXR1bSB3b3JrYXJvdW5kLiAgSWYgaXQgaXMgYW4gZXJyYXR1bSBpdCB3b3VsZCBi
ZSBuaWNlIHRvIGtub3cgdGhlDQo+PiBlcnJhdHVtIG51bWJlciBhbmQgdGhlIGZ1bGwgbGlzdCBv
ZiBhZmZlY3RlZCBjaGlwcy4NCj4+IA0KPk15IHVuZGVyc3RhbmRpbmcsIHdoaWNoIG1heSBiZSB3
cm9uZywgd2FzIHRoYXQgdGhpcyBpcyBleHBlY3RlZCBiZWhhdmlvciwNCj5hdCBsZWFzdCBmb3Ig
RTU1MDAuIEkgYWN0dWFsbHkgdGhvdWdodCBJIGhhZCBzZWVuIGl0IHNvbWV3aGVyZSBpbiB0aGUN
Cj5zcGVjaWZpY2F0aW9uIChyZXNwb25zZSB0byBQQ0llIGVycm9ycyksIGJ1dCBJIGRvbid0IHJl
Y2FsbCB3aGVyZSBleGFjdGx5Lg0KPg0KPkF0IGxlYXN0IGZvciBteSBwYXJ0IEkgYW0gbm90IGF3
YXJlIG9mIGFuIGVycmF0dW0uDQo+DQo+PiA+ID5VbHRpbWF0ZWx5LCB3ZSdsbCB3YW50DQo+PiA+
ID50bw0KPj4gPiA+aW1wbGVtZW50IFBDSWUgZXJyb3IgaGFuZGxlcnMgZm9yIHRoZSBhZmZlY3Rl
ZCBkcml2ZXJzLCBidXQgdGhhdA0KPj53aWxsIGJlDQo+PiA+ID5hIG5leHQNCj4+ID4gPnN0ZXAu
DQo+PiANCj4+IEZvciBub3cgY2FuIHdlIGF0IGxlYXN0IHByaW50IGEgcmF0ZWxpbWl0ZWQgZXJy
b3IgbWVzc2FnZT8gIEkgZG9uJ3QgbGlrZQ0KPj4gdGhlIGlkZWEgb2Ygc2lsZW50bHkgaWdub3Jp
bmcgdGhlc2UgZXJyb3JzLiAgSSBzdXBwb3NlIGl0J3MgYSBzZXBhcmF0ZQ0KPj4gaXNzdWUgZnJv
bSBleHRlbmRpbmcgdGhlIHdvcmthcm91bmQgdG8gY292ZXIgZTUwMG1jLCB0aG91Z2guDQo+PiAN
Cj5JIGRvbid0IHJlYWxseSBsaWtlIHRoZSBpZGVhIG9mIHByaW50aW5nIGFuIGVycm9yIG1lc3Nh
Z2UgcHJldHR5IG11Y2gNCj5lYWNoIHRpbWUNCj53aGVuIGFuIHVuZXhwZWN0ZWQgaG90cGx1ZyBl
dmVudCBvY2N1cnMuDQo+DQo+PiA+IEFjY29yZGluZyB0byB0aGUgc3BlYywgd2UgTUNBUiBpcyBz
dXBwb3NlZCB0byBob2xkIHRoZSBmYXVsdHkgZGF0YQ0KPj5hZGRyZXNzDQo+PiA+IGJ1dCBmb3Ig
NTUwMCBjb3JlLCB3ZSBmb3VuZCB0aGF0IE1DQVIgaXMgemVyby4NCj4+IA0KPj4gV2hpY2ggc3Bl
Y2lmaWMgY2hpcCBhbmQgcmV2aXNpb24gZGlkIHlvdSBzZWUgdGhpcyBvbj8gIFdoYXQgaXMgdGhl
IHZhbHVlDQo+PiBpbiBNQ1NSPw0KPj4gDQo+Sm9qeSBjYW4gYW5zd2VyIHRoYXQsIGF0IGxlYXN0
IGZvciBQNTAyMC4gV2UgaGF2ZSBzZWVuIGl0IG9uIFA1MDQwIGFzDQo+d2VsbCwNCj50aG91Z2gs
IHNvIGl0IGlzIG5vdCBqdXN0IGxpbWl0ZWQgdG8gb25lIGNoaXAvcmV2aXNpb24uDQoNClRoZSBz
cGVjaWZpY3MgYXJlOg0KUFZSOiAweDgwMjQwMDEyDQpJbnN0cnVjdGlvbiB0aGF0IGNhdXNlcyB0
aGUgTUMgZXhjZXB0aW9uOiBsd2JyeA0KCVRoZSBmYXVsdHkgbG9hZCBhZGRyZXNzIGlzIGFsc28g
cHJlc2VudCBpbiBSQi4gU28gd2UgY291bGQgY2hhbmdlIHRoZQ0KbG9naWMgdG8gdXNlIHRoYXQg
DQppbnN0ZWFkIG9mIERFQVIuIFdoYXQgSSBkb26hr3Qga25vdyBpcyBvZiB0aGVyZSBhcmUgb3Ro
ZXIgY2FzZXMgYWxzbyB3aGljaA0KZXNjYXBlcyB0aGUgY3VycmVudCBsb2dpYy4NCg0KCQkJCQkN
CgkJCQkNCgkJCQ0KCQkNCgkNCg0KPg0KPkd1ZW50ZXINCj4NCj4+ID4gWW91IGFyZSByaWdodCB0
aGF0IERFQVIgZW50cnkgY291bGQNCj4+ID4gYmUgYSByZXN1bHRPZiBhIFRMQiBtaXNzIGJ1dCB0
aGF0qfZzIHRoZSByZWdpc3RlciB3ZSBjb3VsZCByZWx5IG9uLg0KPj4gDQo+PiBJZiBpdCdzIHRo
ZSByZXN1bHQgb2YgYSBwcmV2aW91cyBUTEIgbWlzcyB0aGVuIHdlIGNhbid0IHJlbHkgb24gaXQu
ICBUaGUNCj4+IHRyYW5zbGF0aW9uIG1pZ2h0IGhhdmUgYmVlbiBsb2FkZWQgaW50byB0aGUgVExC
IGJlZm9yZSB0aGUgaG90cGx1Zw0KPj4gZXZlbnQsIG9yIHRoZXJlIG1pZ2h0IGhhdmUgYmVlbiBh
biBpbnRlcnJ1cHQgYmV0d2VlbiBsb2FkaW5nIHRoZQ0KPj4gdHJhbnNsYXRpb24gaW50byB0aGUg
VExCIGFuZCB1c2luZyB0aGUgdHJhbnNsYXRpb24uDQo+PiANCj4+ID4gV2hhdCBkbyB5b3UgbWVh
biBieSAiaW5zdHJ1Y3Rpb24gZW11bGF0aW9uIj8NCj4+IA0KPj4gbWNoZWNrX2hhbmRsZV9sb2Fk
KCkNCj4+IA0KPj4gPiBBcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCB3ZQ0KPj4gPiBleGFtaW5lIHRo
ZSBSRCwgUlMNCj4+ID4gcmVnaXN0ZXJzIGZvciB0aGUgaW5zdHJ1Y3Rpb24/DQo+PiANCj4+IFll
cywgaWYgd2UgZG9uJ3QgaGF2ZSBhIHNpbXBsZXIgcmVsaWFibGUgc291cmNlIG9mIHRoZSBhZGRy
ZXNzLg0KPj4gDQo+PiAtU2NvdHQNCj4+IA0KPj4gDQoNCg==

^ permalink raw reply

* Re: [PATCH] powerpc/fsl: Add support for pci(e) machine check exception on E500MC / E5500
From: Jojy Varghese @ 2014-09-30 20:20 UTC (permalink / raw)
  To: Scott Wood
  Cc: hongtao.jia@freescale.com, linux-kernel@vger.kernel.org,
	Guenter Roeck, Paul Mackerras, linuxppc-dev@lists.ozlabs.org,
	Guenter Roeck
In-Reply-To: <1412108227.13320.309.camel@snotra.buserror.net>



On 9/30/14 1:17 PM, "Scott Wood" <scottwood@freescale.com> wrote:

>On Tue, 2014-09-30 at 20:15 +0000, Jojy Varghese wrote:
>>=20
>> On 9/30/14 8:50 AM, "Guenter Roeck" <linux@roeck-us.net> wrote:
>>=20
>> >On Mon, Sep 29, 2014 at 06:31:06PM -0500, Scott Wood wrote:
>> >> Which specific chip and revision did you see this on?  What is the
>>value
>> >> in MCSR?
>> >>=20
>> >Jojy can answer that, at least for P5020. We have seen it on P5040 as
>> >well,
>> >though, so it is not just limited to one chip/revision.
>>=20
>> The specifics are:
>> PVR: 0x80240012
>> Instruction that causes the MC exception: lwbrx
>> 	The faulty load address is also present in RB. So we could change the
>> logic to use that
>> instead of DEAR. What I don=B9t know is of there are other cases also
>>which
>> escapes the current logic.
>
>Could you find out what MCSR was when that happened?  I'm most
>interested in whether MAV was set, but the other bits would be
>interesting as well.

MCSR=3Da000 ( Load Error Report)
>
>-Scott
>
>
Thanks
Jojy

^ permalink raw reply

* Re: [PATCH v4 10/10] powerpc/perf/hv-24x7: Document sysfs event description entries
From: Cody P Schafer @ 2014-09-30 21:03 UTC (permalink / raw)
  To: Sukadev Bhattiprolu
  Cc: Andi Kleen, Michael Ellerman, Peter Zijlstra, Linux PPC, LKML,
	Stephane Eranian, Paul Mackerras, Arnaldo Carvalho de Melo,
	Jiri Olsa, Anshuman Khandual
In-Reply-To: <1411586844-21381-11-git-send-email-sukadev@linux.vnet.ibm.com>

> +What:          /sys/bus/event_source/devices/hv_24x7/event_descs/<event-name>
> +Date:          February 2014
> +Contact:       Cody P Schafer <cody@linux.vnet.ibm.com>

May want to change this contact email to an address that still works
(perhaps the ppc devel list?)

^ permalink raw reply

* Re: [v2,2/4] Simplify catalog_read()
From: Michael Ellerman @ 2014-10-01  0:32 UTC (permalink / raw)
  To: sukadev, Arnaldo Carvalho de Melo, ak, Jiri Olsa, peterz, eranian,
	Paul Mackerras
  Cc: linuxppc-dev, dev, linux-kernel, Michael Ellerman,
	Anshuman Khandual
In-Reply-To: <1411586681-21262-3-git-send-email-sukadev@linux.vnet.ibm.com>

On Wed, 2014-24-09 at 19:24:39 UTC, sukadev@linux.vnet.ibm.com wrote:
> catalog_read() implements the read interface for the sysfs file
> 
> 	/sys/bus/event_source/devices/hv_24x7/interface/catalog
> 
> It essentially takes a buffer, an offset and count as parameters
> to the read() call.  It makes a hypervisor call to read a specific
> page from the catalog and copy the required bytes into the given
> buffer. Each call to catalog_read() returns at most one 4K page.
> 
> Given these requirements, we should be able to simplify the
> catalog_read().
> 
> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
> index 2f2215c..9427ef7 100644
> --- a/arch/powerpc/perf/hv-24x7.c
> +++ b/arch/powerpc/perf/hv-24x7.c
> @@ -185,6 +105,8 @@ static ssize_t catalog_read(struct file *filp, struct kobject *kobj,
>  	ssize_t ret = 0;
>  	size_t catalog_len = 0, catalog_page_len = 0, page_count = 0;
>  	loff_t page_offset = 0;
> +	loff_t offset_in_page;
> +	size_t copy_len;
>  	uint64_t catalog_version_num = 0;
>  	void *page = kmem_cache_alloc(hv_page_cache, GFP_USER);
>  	struct hv_24x7_catalog_page_0 *page_0 = page;
> @@ -203,6 +125,7 @@ static ssize_t catalog_read(struct file *filp, struct kobject *kobj,
>  
>  	page_offset = offset / 4096;
>  	page_count  = count  / 4096;

I don't see where page_count is used.

> +	offset_in_page = count % 4096;

Shouldn't offset_in_page be based on offset ?

cheers

^ permalink raw reply

* Re: [PATCH] powerpc/fsl: Add support for pci(e) machine check exception on E500MC / E5500
From: Scott Wood @ 2014-10-01  0:43 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: hongtao.jia@freescale.com, linux-kernel@vger.kernel.org,
	Guenter Roeck, Paul Mackerras, linuxppc-dev@lists.ozlabs.org,
	Jojy Varghese
In-Reply-To: <20140930155029.GA4724@roeck-us.net>

On Tue, 2014-09-30 at 08:50 -0700, Guenter Roeck wrote:
> On Mon, Sep 29, 2014 at 06:31:06PM -0500, Scott Wood wrote:
> > On Mon, 2014-09-29 at 23:03 +0000, Jojy Varghese wrote:
> > > 
> > > On 9/29/14 12:06 PM, "Guenter Roeck" <linux@roeck-us.net> wrote:
> > > 
> > > >Those are errors related to PCIe hotplug, and are seen with unexpected
> > > >PCIe
> > > >device removals (triggered, for example, by removing power from a PCIe
> > > >adapter).
> > > >The behavior we see on E5500 is quite similar to the same behavior on
> > > >E500:
> > > >If unhandled, the CPU keeps executing the same instruction over and over
> > > >again
> > > >if there is an error on a PCIe access and thus stalls. I don't know if
> > > >this
> > > >is considered an erratum or expected behavior, but it is one we have to
> > > >address
> > > >since we have to be able to handle that condition. 
> > 
> > The reason I ask is that the handling for e500 was described as an
> > erratum workaround.  If it is an erratum it would be nice to know the
> > erratum number and the full list of affected chips.
> > 
> My understanding, which may be wrong, was that this is expected behavior,
> at least for E5500. I actually thought I had seen it somewhere in the
> specification (response to PCIe errors), but I don't recall where exactly.
> 
> At least for my part I am not aware of an erratum.

Jia Hongtao, can you comment here?

> > > >Ultimately, we'll want
> > > >to
> > > >implement PCIe error handlers for the affected drivers, but that will be
> > > >a next
> > > >step.
> > 
> > For now can we at least print a ratelimited error message?  I don't like
> > the idea of silently ignoring these errors.  I suppose it's a separate
> > issue from extending the workaround to cover e500mc, though.
> > 
> I don't really like the idea of printing an error message pretty much each time
> when an unexpected hotplug event occurs.

Unexpected events seem like the sort of thing you'd want to log, but my
concern is that this might not be the only cause of PCI errors.

-Scott

^ permalink raw reply

* Re: [v2,2/4] Simplify catalog_read()
From: Sukadev Bhattiprolu @ 2014-10-01  0:59 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: ak, Michael Ellerman, peterz, linuxppc-dev, linux-kernel, eranian,
	Paul Mackerras, Arnaldo Carvalho de Melo, dev, Jiri Olsa,
	Anshuman Khandual
In-Reply-To: <20141001003213.A8F78140273@ozlabs.org>

Michael Ellerman [mpe@ellerman.id.au] wrote:
| > @@ -203,6 +125,7 @@ static ssize_t catalog_read(struct file *filp, struct kobject *kobj,
| >  
| >  	page_offset = offset / 4096;
| >  	page_count  = count  / 4096;
| 
| I don't see where page_count is used.

Yes, I will remove it.

| 
| > +	offset_in_page = count % 4096;
| 
| Shouldn't offset_in_page be based on offset ?

Yes. I will fix that.

Thanks,

Sukadev

^ permalink raw reply

* Re: [v2, 1/4] powerpc/perf/hv-24x7: use kmem_cache instead of aligned stack allocations
From: Michael Ellerman @ 2014-10-01  1:23 UTC (permalink / raw)
  To: sukadev, Arnaldo Carvalho de Melo, ak, Jiri Olsa, peterz, eranian,
	Paul Mackerras
  Cc: linuxppc-dev, dev, linux-kernel, Anshuman Khandual
In-Reply-To: <1411586681-21262-2-git-send-email-sukadev@linux.vnet.ibm.com>

On Wed, 2014-24-09 at 19:24:38 UTC, sukadev@linux.vnet.ibm.com wrote:
> From: Cody P Schafer <cody@linux.vnet.ibm.com>
> 
> Ian pointed out the use of __aligned(4096) caused rather large stack
> consumption in single_24x7_request(), so use the kmem_cache
> hv_page_cache (which we've already got set up for other allocations)
> insead of allocating locally.
> 
> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
> index 70d4f74..2f2215c 100644
> --- a/arch/powerpc/perf/hv-24x7.c
> +++ b/arch/powerpc/perf/hv-24x7.c
> @@ -294,7 +294,7 @@ static unsigned long single_24x7_request(u8 domain, u32 offset, u16 ix,
>  					 u16 lpar, u64 *res,
>  					 bool success_expected)
>  {
> -	unsigned long ret;
> +	unsigned long ret = -ENOMEM;
>  
>  	/*
>  	 * request_buffer and result_buffer are not required to be 4k aligned,
> @@ -304,7 +304,27 @@ static unsigned long single_24x7_request(u8 domain, u32 offset, u16 ix,
>  	struct reqb {
>  		struct hv_24x7_request_buffer buf;
>  		struct hv_24x7_request req;
> -	} __packed __aligned(4096) request_buffer = {
> +	} __packed * request_buffer;

No space after the * please.

> +	struct resb {

You never use the struct name so this can be anonymous, eg:

	struct {
		struct hv_24x7_data_result_buffer buf;
		...

> +		struct hv_24x7_data_result_buffer buf;
> +		struct hv_24x7_result res;
> +		struct hv_24x7_result_element elem;
> +		__be64 result;
> +	} __packed * result_buffer;

No space again.

> +	BUILD_BUG_ON(sizeof(*request_buffer) > 4096);
> +	BUILD_BUG_ON(sizeof(*result_buffer) > 4096);
> +
> +	request_buffer = kmem_cache_alloc(hv_page_cache, GFP_USER);

Why aren't we using kzalloc here?

It looks like we're initialising everything below except the reserved fields,
but are they allowed to be non-zero? It's probably safer to just kzalloc it.

> +	if (!request_buffer)
> +		goto out_reqb;

If prefer labels to be named for what they do, so this would be just "out".

> +
> +	result_buffer = kmem_cache_zalloc(hv_page_cache, GFP_USER);
> +	if (!result_buffer)
> +		goto out_resb;

And this would be "out_free_request_buffer".

> +
> +	*request_buffer = (struct reqb) {
>  		.buf = {
>  			.interface_version = HV_24X7_IF_VERSION_CURRENT,
>  			.num_requests = 1,
> @@ -320,28 +340,30 @@ static unsigned long single_24x7_request(u8 domain, u32 offset, u16 ix,
>  		}
>  	};
>  
> -	struct resb {
> -		struct hv_24x7_data_result_buffer buf;
> -		struct hv_24x7_result res;
> -		struct hv_24x7_result_element elem;
> -		__be64 result;
> -	} __packed __aligned(4096) result_buffer = {};
> -
>  	ret = plpar_hcall_norets(H_GET_24X7_DATA,
> -			virt_to_phys(&request_buffer), sizeof(request_buffer),
> -			virt_to_phys(&result_buffer),  sizeof(result_buffer));
> +			virt_to_phys(request_buffer), sizeof(*request_buffer),
> +			virt_to_phys(result_buffer),  sizeof(*result_buffer));
>  
>  	if (ret) {
>  		if (success_expected)
>  			pr_err_ratelimited("hcall failed: %d %#x %#x %d => 0x%lx (%ld) detail=0x%x failing ix=%x\n",
>  					domain, offset, ix, lpar,
>  					ret, ret,
> -					result_buffer.buf.detailed_rc,
> -					result_buffer.buf.failing_request_ix);
> -		return ret;
> +					result_buffer->buf.detailed_rc,
> +					result_buffer->buf.failing_request_ix);
> +		goto out_hcall;
>  	}
>  
> -	*res = be64_to_cpu(result_buffer.result);
> +	*res = be64_to_cpu(result_buffer->result);
> +	kfree(result_buffer);
> +	kfree(request_buffer);
> +	return ret;
> +
> +out_hcall:
> +	kfree(result_buffer);
> +out_resb:
> +	kfree(request_buffer);
> +out_reqb:
>  	return ret;
>  }

Wouldn't this be better as:

	*res = be64_to_cpu(result_buffer->result);

out_free_result_buffer:
	kfree(result_buffer);
out_free_request_buffer:
	kfree(request_buffer);
out:
	return ret;
}


cheers

^ permalink raw reply

* [PATCH 1/4] pci/msi: Move "force_32bit_msi" flag from powerpc to generic pci_dev
From: Benjamin Herrenschmidt @ 2014-10-01  2:09 UTC (permalink / raw)
  To: Alex Deucher, Bjorn Helgaas
  Cc: linuxppc-dev, Dave Airlie, linux-pci, Anton Blanchard,
	Yijing Wang, Takashi Iwai, Brian King
In-Reply-To: <1412112324.4285.160.camel@pasglop>


Some devices have broken 64-bit MSI support which only support some
address bits (40 to 48 typically). This doesn't work on some platforms
such as POWER servers, so we need a quirk.

Currently we keep a flag in a powerpc specific data structure which we
have per PCI device. However this is impractical as we really want the
driver to set that flag appropriately (and the driver shouldn't touch
that arch specific data structure).

It's also not unlikely that this limitation will affect other architectures
in the long run so may as well be prepared for it.

So this moves the flag to struct pci_dev instead and adjusts the
corresponding arch/powerpc code to look for it there. At this point,
there is no attempt at making other architectures honor it just yet
though from what I can tell, x86 seems to always use 32-bit addresses
for MSIs.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>
---

Note: CC'ing stable as I really want this to hit distros, without that
(and the three subsequent patches), we crash during boot with a number
of radeon cards on power machines.

Note2: Alex, we can wait for the response of the HW guys for which revisions
actually need the quirk in hda_intel but I don't see a big risk or issue in
just doing it for all AMD/ATI for now and fix that up later

 arch/powerpc/include/asm/pci-bridge.h     | 2 --
 arch/powerpc/kernel/pci_64.c              | 5 +----
 arch/powerpc/platforms/powernv/pci-ioda.c | 3 +--
 arch/powerpc/platforms/powernv/pci.c      | 3 +--
 arch/powerpc/platforms/pseries/msi.c      | 2 +-
 include/linux/pci.h                       | 1 +
 6 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index 4ca90a3..725247b 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -159,8 +159,6 @@ struct pci_dn {
 
 	int	pci_ext_config_space;	/* for pci devices */
 
-	bool	force_32bit_msi;
-
 	struct	pci_dev *pcidev;	/* back-pointer to the pci device */
 #ifdef CONFIG_EEH
 	struct eeh_dev *edev;		/* eeh device */
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 155013d..a6ce5fe 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -269,10 +269,7 @@ EXPORT_SYMBOL(pcibus_to_node);
 
 static void quirk_radeon_32bit_msi(struct pci_dev *dev)
 {
-	struct pci_dn *pdn = pci_get_pdn(dev);
-
-	if (pdn)
-		pdn->force_32bit_msi = true;
+	dev->force_32bit_msi = true;
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x68f2, quirk_radeon_32bit_msi);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0xaa68, quirk_radeon_32bit_msi);
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index df241b1..9d98475 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1311,7 +1311,6 @@ static int pnv_pci_ioda_msi_setup(struct pnv_phb *phb, struct pci_dev *dev,
 				  unsigned int is_64, struct msi_msg *msg)
 {
 	struct pnv_ioda_pe *pe = pnv_ioda_get_pe(dev);
-	struct pci_dn *pdn = pci_get_pdn(dev);
 	struct irq_data *idata;
 	struct irq_chip *ichip;
 	unsigned int xive_num = hwirq - phb->msi_base;
@@ -1327,7 +1326,7 @@ static int pnv_pci_ioda_msi_setup(struct pnv_phb *phb, struct pci_dev *dev,
 		return -ENXIO;
 
 	/* Force 32-bit MSI on some broken devices */
-	if (pdn && pdn->force_32bit_msi)
+	if (dev->force_32bit_msi)
 		is_64 = 0;
 
 	/* Assign XIVE to PE */
diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
index b854b57..4e43a6f 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -50,9 +50,8 @@ static int pnv_msi_check_device(struct pci_dev* pdev, int nvec, int type)
 {
 	struct pci_controller *hose = pci_bus_to_host(pdev->bus);
 	struct pnv_phb *phb = hose->private_data;
-	struct pci_dn *pdn = pci_get_pdn(pdev);
 
-	if (pdn && pdn->force_32bit_msi && !phb->msi32_support)
+	if (pdev->force_32bit_msi && !phb->msi32_support)
 		return -ENODEV;
 
 	return (phb && phb->msi_bmp.bitmap) ? 0 : -ENODEV;
diff --git a/arch/powerpc/platforms/pseries/msi.c b/arch/powerpc/platforms/pseries/msi.c
index 18ff462..b3f2c1a 100644
--- a/arch/powerpc/platforms/pseries/msi.c
+++ b/arch/powerpc/platforms/pseries/msi.c
@@ -429,7 +429,7 @@ static int rtas_setup_msi_irqs(struct pci_dev *pdev, int nvec_in, int type)
 	 */
 again:
 	if (type == PCI_CAP_ID_MSI) {
-		if (pdn->force_32bit_msi) {
+		if (pdev->force_32bit_msi) {
 			rc = rtas_change_msi(pdn, RTAS_CHANGE_32MSI_FN, nvec);
 			if (rc < 0) {
 				/*
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 96453f9..740cadd 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -331,6 +331,7 @@ struct pci_dev {
 	unsigned int	is_added:1;
 	unsigned int	is_busmaster:1; /* device is busmaster */
 	unsigned int	no_msi:1;	/* device may not use msi */
+	unsigned int    force_32bit_msi:1;	/* Device has broken 64-bit MSIs */
 	unsigned int	block_cfg_access:1;	/* config space access is blocked */
 	unsigned int	broken_parity_status:1;	/* Device generates false positive parity */
 	unsigned int	irq_reroute_variant:2;	/* device needs IRQ rerouting variant */

^ permalink raw reply related

* [PATCH 2/4] gpu/radeon: Generalize 64-bit MSI quirks
From: Benjamin Herrenschmidt @ 2014-10-01  2:09 UTC (permalink / raw)
  To: Alex Deucher, Bjorn Helgaas
  Cc: linuxppc-dev, Dave Airlie, linux-pci, Anton Blanchard,
	Yijing Wang, Takashi Iwai, Brian King


A number of radeon cards have a HW limitation causing them to be
unable to generate the full 64-bit of address bits for MSIs. This
breaks MSIs on some platforms such as POWER machines.

We used to have a powerpc specific quirk to address that on a
single card, but this doesn't scale very well, this is better
put under control of the drivers who know precisely what a given
HW revision can do.

This moves the setting of the quirk flag to the radeon driver

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>
---
 arch/powerpc/kernel/pci_64.c            |  1 -
 drivers/gpu/drm/radeon/radeon_irq_kms.c | 10 ++++++++++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index a6ce5fe..66e1cd0 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -271,5 +271,4 @@ static void quirk_radeon_32bit_msi(struct pci_dev *dev)
 {
 	dev->force_32bit_msi = true;
 }
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x68f2, quirk_radeon_32bit_msi);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0xaa68, quirk_radeon_32bit_msi);
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 16807af..7ea1ea9 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -202,6 +202,16 @@ static bool radeon_msi_ok(struct radeon_device *rdev)
 	if (rdev->flags & RADEON_IS_AGP)
 		return false;
 
+	/*
+	 * Older chips have a HW limitation, they can only generate 40 bits
+	 * of address for "64-bit" MSIs which breaks on some platforms, notably
+	 * IBM POWER servers, so we limit them
+	 */
+	if (rdev->family < CHIP_BONAIRE) {
+		dev_info(rdev->dev, "radeon: MSI limited to 32-bit\n");
+		rdev->pdev->force_32bit_msi = true;
+	}
+
 	/* force MSI on */
 	if (radeon_msi == 1)
 		return true;

^ permalink raw reply related

* [PATCH 4/4] sounds/hda/radeon: Disable 64-bit DMA on radeon
From: Benjamin Herrenschmidt @ 2014-10-01  2:09 UTC (permalink / raw)
  To: Alex Deucher, Bjorn Helgaas
  Cc: linuxppc-dev, Dave Airlie, linux-pci, Anton Blanchard,
	Yijing Wang, Takashi Iwai, Brian King

The chipset has a limitation in the number of address bits it
can generate. The graphics portion uses a specific mask of
40 or 48 bits depending on the generation. For audio, it's a bit
less of an issue, so just mark them as no-64bit for now.

Without this, it crashes on POWER machines which can use high bits
in the DMA address to distinguish between DMA windows. 

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>
---
 sound/pci/hda/hda_intel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 3e6d22d..2b679d5 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -297,7 +297,7 @@ enum {
 /* quirks for ATI/AMD HDMI */
 #define AZX_DCAPS_PRESET_ATI_HDMI \
 	(AZX_DCAPS_NO_TCSEL | AZX_DCAPS_SYNC_WRITE | AZX_DCAPS_POSFIX_LPIB|\
-	 AZX_DCAPS_NO_MSI64)
+	 AZX_DCAPS_NO_MSI64 | AZX_DCAPS_NO_64BIT)
 
 /* quirks for Nvidia */
 #define AZX_DCAPS_PRESET_NVIDIA \

^ permalink raw reply related

* [PATCH 3/4] sound/hda/radeon: Generalize 64-bit MSI quirks
From: Benjamin Herrenschmidt @ 2014-10-01  2:09 UTC (permalink / raw)
  To: Alex Deucher, Bjorn Helgaas
  Cc: linuxppc-dev, Dave Airlie, linux-pci, Anton Blanchard,
	Yijing Wang, Takashi Iwai, Brian King

A number of radeon cards have a HW limitation causing them to be
unable to generate the full 64-bit of address bits for MSIs. This
breaks MSIs on some platforms such as POWER machines.

We used to have a powerpc specific quirk to address that on a
single card, but this doesn't scale very well, this is better
put under control of the drivers who know precisely what a given
HW revision can do.

This moves the setting of the quirk flag to the HDA driver when
detecting the radeon audio interface.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>
---
 arch/powerpc/kernel/pci_64.c |  6 ------
 sound/pci/hda/hda_intel.c    | 10 ++++++++--
 sound/pci/hda/hda_priv.h     |  1 +
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 66e1cd0..b15194e 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -266,9 +266,3 @@ int pcibus_to_node(struct pci_bus *bus)
 }
 EXPORT_SYMBOL(pcibus_to_node);
 #endif
-
-static void quirk_radeon_32bit_msi(struct pci_dev *dev)
-{
-	dev->force_32bit_msi = true;
-}
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0xaa68, quirk_radeon_32bit_msi);
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index aa302fb..3e6d22d 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -296,7 +296,8 @@ enum {
 
 /* quirks for ATI/AMD HDMI */
 #define AZX_DCAPS_PRESET_ATI_HDMI \
-	(AZX_DCAPS_NO_TCSEL | AZX_DCAPS_SYNC_WRITE | AZX_DCAPS_POSFIX_LPIB)
+	(AZX_DCAPS_NO_TCSEL | AZX_DCAPS_SYNC_WRITE | AZX_DCAPS_POSFIX_LPIB|\
+	 AZX_DCAPS_NO_MSI64)
 
 /* quirks for Nvidia */
 #define AZX_DCAPS_PRESET_NVIDIA \
@@ -1505,9 +1506,14 @@ static int azx_first_init(struct azx *chip)
 		return -ENXIO;
 	}
 
-	if (chip->msi)
+	if (chip->msi) {
+		if (chip->driver_caps & AZX_DCAPS_NO_MSI64) {
+			dev_dbg(card->dev, "Disabling 64bit MSI\n");
+			pci->force_32bit_msi = true;
+		}
 		if (pci_enable_msi(pci) < 0)
 			chip->msi = 0;
+	}
 
 	if (azx_acquire_irq(chip, 0) < 0)
 		return -EBUSY;
diff --git a/sound/pci/hda/hda_priv.h b/sound/pci/hda/hda_priv.h
index 949cd43..5016014 100644
--- a/sound/pci/hda/hda_priv.h
+++ b/sound/pci/hda/hda_priv.h
@@ -171,6 +171,7 @@ enum { SDI0, SDI1, SDI2, SDI3, SDO0, SDO1, SDO2, SDO3 };
 #define AZX_DCAPS_PM_RUNTIME	(1 << 26)	/* runtime PM support */
 #define AZX_DCAPS_I915_POWERWELL (1 << 27)	/* HSW i915 powerwell support */
 #define AZX_DCAPS_CORBRP_SELF_CLEAR (1 << 28)	/* CORBRP clears itself after reset */
+#define AZX_DCAPS_NO_MSI64      (1 << 29)	/* Stick to 32-bit MSIs */
 
 /* HD Audio class code */
 #define PCI_CLASS_MULTIMEDIA_HD_AUDIO	0x0403

^ permalink raw reply related

* Re: [02/21] powerpc/eeh: Add eeh_pe_state sysfs entry
From: Michael Ellerman @ 2014-10-01  3:43 UTC (permalink / raw)
  To: Gavin Shan, linuxppc-dev
In-Reply-To: <1412044750-24460-2-git-send-email-gwshan@linux.vnet.ibm.com>

On Tue, 2014-30-09 at 02:38:51 UTC, Gavin Shan wrote:
> diff --git a/arch/powerpc/kernel/eeh_sysfs.c b/arch/powerpc/kernel/eeh_sysfs.c
> index e2595ba..eb15be4 100644
> --- a/arch/powerpc/kernel/eeh_sysfs.c
> +++ b/arch/powerpc/kernel/eeh_sysfs.c
> @@ -54,6 +54,62 @@ EEH_SHOW_ATTR(eeh_mode,            mode,            "0x%x");
>  EEH_SHOW_ATTR(eeh_config_addr,     config_addr,     "0x%x");
>  EEH_SHOW_ATTR(eeh_pe_config_addr,  pe_config_addr,  "0x%x");
>  
> +static ssize_t eeh_pe_state_show(struct device *dev,
> +				 struct device_attribute *attr, char *buf)
> +{
> +	struct pci_dev *pdev = to_pci_dev(dev);
> +	struct eeh_dev *edev = pci_dev_to_eeh_dev(pdev);
> +	int state;
> +
> +	if (!edev || !edev->pe)
> +		return -ENODEV;
> +
> +	state = eeh_ops->get_state(edev->pe, NULL);
> +	return sprintf(buf, "%08x %08x\n",
> +		       state, edev->pe->state);

Looking at all the other eeh sysfs files, they all use 0x%x. Which makes it
much clearer when you're looking at the file in userspace that the content is
hex.

Please send an incremental patch to change the format to 0x%08x, unless there's
a good reason not to.

cheers

^ permalink raw reply

* Re: [02/21] powerpc/eeh: Add eeh_pe_state sysfs entry
From: Gavin Shan @ 2014-10-01  4:20 UTC (permalink / raw)
  To: Michael Ellerman; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <20141001034343.9626514012C@ozlabs.org>

On Wed, Oct 01, 2014 at 01:43:43PM +1000, Michael Ellerman wrote:
>On Tue, 2014-30-09 at 02:38:51 UTC, Gavin Shan wrote:
>> diff --git a/arch/powerpc/kernel/eeh_sysfs.c b/arch/powerpc/kernel/eeh_sysfs.c
>> index e2595ba..eb15be4 100644
>> --- a/arch/powerpc/kernel/eeh_sysfs.c
>> +++ b/arch/powerpc/kernel/eeh_sysfs.c
>> @@ -54,6 +54,62 @@ EEH_SHOW_ATTR(eeh_mode,            mode,            "0x%x");
>>  EEH_SHOW_ATTR(eeh_config_addr,     config_addr,     "0x%x");
>>  EEH_SHOW_ATTR(eeh_pe_config_addr,  pe_config_addr,  "0x%x");
>>  
>> +static ssize_t eeh_pe_state_show(struct device *dev,
>> +				 struct device_attribute *attr, char *buf)
>> +{
>> +	struct pci_dev *pdev = to_pci_dev(dev);
>> +	struct eeh_dev *edev = pci_dev_to_eeh_dev(pdev);
>> +	int state;
>> +
>> +	if (!edev || !edev->pe)
>> +		return -ENODEV;
>> +
>> +	state = eeh_ops->get_state(edev->pe, NULL);
>> +	return sprintf(buf, "%08x %08x\n",
>> +		       state, edev->pe->state);
>
>Looking at all the other eeh sysfs files, they all use 0x%x. Which makes it
>much clearer when you're looking at the file in userspace that the content is
>hex.
>
>Please send an incremental patch to change the format to 0x%08x, unless there's
>a good reason not to.
>

Agree and will do :)

Thanks,
Gavin

>cheers
>

^ permalink raw reply

* [PATCH] powerpc/eeh: Show hex prefix for PE state sysfs
From: Gavin Shan @ 2014-10-01  4:34 UTC (permalink / raw)
  To: mpe; +Cc: linuxppc-dev, Gavin Shan

As Michael suggested, the hex prefix for the output of EEH PE
state sysfs entry (/sys/bus/pci/devices/xxx/eeh_pe_state) is
always informative to users.

Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
 arch/powerpc/kernel/eeh_sysfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/eeh_sysfs.c b/arch/powerpc/kernel/eeh_sysfs.c
index 9a44010..f19b1e5 100644
--- a/arch/powerpc/kernel/eeh_sysfs.c
+++ b/arch/powerpc/kernel/eeh_sysfs.c
@@ -65,7 +65,7 @@ static ssize_t eeh_pe_state_show(struct device *dev,
 		return -ENODEV;
 
 	state = eeh_ops->get_state(edev->pe, NULL);
-	return sprintf(buf, "%08x %08x\n",
+	return sprintf(buf, "%0x08x %0x08x\n",
 		       state, edev->pe->state);
 }
 
-- 
1.8.3.2

^ permalink raw reply related

* [PATCH] powerpc: Reimplement __get_SP() as a function not a define
From: Anton Blanchard @ 2014-10-01  5:10 UTC (permalink / raw)
  To: zhong, benh, paulus, mpe; +Cc: linuxppc-dev

Li Zhong points out an issue with our current __get_SP()
implementation. If ftrace function tracing is enabled (ie -pg
profiling using _mcount) we spill a stack frame on 64bit all the
time.

If a function calls __get_SP() and later calls a function that is
tail call optimised, we will pop the stack frame and the value
returned by __get_SP() is no longer valid. An example from Li can
be found in save_stack_trace -> save_context_stack:

c0000000000432c0 <.save_stack_trace>:
c0000000000432c0:       mflr    r0
c0000000000432c4:       std     r0,16(r1)
c0000000000432c8:       stdu    r1,-128(r1) <-- stack frame for _mcount
c0000000000432cc:       std     r3,112(r1)
c0000000000432d0:       bl      <._mcount>
c0000000000432d4:       nop

c0000000000432d8:       mr      r4,r1 <-- __get_SP()

c0000000000432dc:       ld      r5,632(r13)
c0000000000432e0:       ld      r3,112(r1)
c0000000000432e4:       li      r6,1

c0000000000432e8:       addi    r1,r1,128 <-- pop stack frame

c0000000000432ec:       ld      r0,16(r1)
c0000000000432f0:       mtlr    r0
c0000000000432f4:       b       <.save_context_stack> <-- tail call optimized

save_context_stack ends up with a stack pointer below the current
one, and it is likely to be scribbled over.

Fix this by making __get_SP() a function which returns the
callers stack frame. Also replace inline assembly which grabs
the stack pointer in save_stack_trace and show_stack with
__get_SP().

Reported-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
---
 arch/powerpc/include/asm/reg.h   | 3 +--
 arch/powerpc/kernel/misc.S       | 4 ++++
 arch/powerpc/kernel/process.c    | 2 +-
 arch/powerpc/kernel/stacktrace.c | 2 +-
 4 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 0c05059..0f973c0 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1264,8 +1264,7 @@ static inline unsigned long mfvtb (void)
 
 #define proc_trap()	asm volatile("trap")
 
-#define __get_SP()	({unsigned long sp; \
-			asm volatile("mr %0,1": "=r" (sp)); sp;})
+extern unsigned long __get_SP(void);
 
 extern unsigned long scom970_read(unsigned int address);
 extern void scom970_write(unsigned int address, unsigned long value);
diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S
index 7ce26d4..120deb7 100644
--- a/arch/powerpc/kernel/misc.S
+++ b/arch/powerpc/kernel/misc.S
@@ -114,3 +114,7 @@ _GLOBAL(longjmp)
 	mtlr	r0
 	mr	r3,r4
 	blr
+
+_GLOBAL(__get_SP)
+	PPC_LL	r3,0(r1)
+	blr
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index aa1df89..3cc6439 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1545,7 +1545,7 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
 		tsk = current;
 	if (sp == 0) {
 		if (tsk == current)
-			asm("mr %0,1" : "=r" (sp));
+			sp = __get_SP();
 		else
 			sp = tsk->thread.ksp;
 	}
diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c
index 3d30ef1..7f65bae 100644
--- a/arch/powerpc/kernel/stacktrace.c
+++ b/arch/powerpc/kernel/stacktrace.c
@@ -50,7 +50,7 @@ void save_stack_trace(struct stack_trace *trace)
 {
 	unsigned long sp;
 
-	asm("mr %0,1" : "=r" (sp));
+	sp = __get_SP();
 
 	save_context_stack(trace, sp, current, 1);
 }
-- 
1.9.1

^ permalink raw reply related

* [PATCH v3 0/5] powerpc/perf: Miscellaneous fixes
From: Sukadev Bhattiprolu @ 2014-10-01  6:03 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo, ak, Jiri Olsa, peterz, eranian,
	Paul Mackerras
  Cc: Michael Ellerman, linux-kernel, dev, linuxppc-dev,
	Anshuman Khandual

Miscellaenous fixes for perf and 24x7 counters in powerpc.

Patches 1,3,4 were submitted earlier as a part of the parametrized
events for 24x7 counters. But they are not directly related to the
parametrized events.

Patch 2 simplifies and fixes a bug in catalog_read() which causes the
catalog file to not read first page.

Changelog[v3]
	[Michael Ellerman] Cleanup patches 1 and 2 and fix a bug
	Add patch 5/5 to update contact info for 24x7 and GPCI counters

Changelog[v2]
	Rebase to perf/core tree.

Cody P Schafer (3):
  powerpc/perf/hv-24x7: use kmem_cache instead of aligned stack
    allocations
  perf Documentation: sysfs events/ interfaces
  perf Documentation: remove duplicated docs for powerpc cpu specific
    events

Sukadev Bhattiprolu (2):
  Simplify catalog_read()
  powerpc: Update contact info in Documentation files

 .../testing/sysfs-bus-event_source-devices-events  | 611 ++-------------------
 .../testing/sysfs-bus-event_source-devices-hv_24x7 |   6 +-
 .../testing/sysfs-bus-event_source-devices-hv_gpci |  12 +-
 arch/powerpc/perf/hv-24x7.c                        | 156 ++----
 4 files changed, 109 insertions(+), 676 deletions(-)

-- 
1.8.3.1

^ permalink raw reply

* [PATCH 1/5] powerpc/perf/hv-24x7: use kmem_cache instead of aligned stack allocations
From: Sukadev Bhattiprolu @ 2014-10-01  6:03 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo, ak, Jiri Olsa, peterz, eranian,
	Paul Mackerras
  Cc: Michael Ellerman, linux-kernel, dev, linuxppc-dev,
	Anshuman Khandual
In-Reply-To: <1412143402-26061-1-git-send-email-sukadev@linux.vnet.ibm.com>

From: Cody P Schafer <dev@codyps.com>

Ian pointed out the use of __aligned(4096) caused rather large stack
consumption in single_24x7_request(), so use the kmem_cache
hv_page_cache (which we've already got set up for other allocations)
insead of allocating locally.

CC: Haren Myneni <hbabu@us.ibm.com>
Reported-by: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Cody P Schafer <dev@codyps.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
Changelog [v3]:
	[Michael Ellerman] Cleanup code and use kmem..zalloc()

 arch/powerpc/perf/hv-24x7.c | 55 ++++++++++++++++++++++++++++++---------------
 1 file changed, 37 insertions(+), 18 deletions(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 70d4f74..697759d 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -294,7 +294,7 @@ static unsigned long single_24x7_request(u8 domain, u32 offset, u16 ix,
 					 u16 lpar, u64 *res,
 					 bool success_expected)
 {
-	unsigned long ret;
+	unsigned long ret = -ENOMEM;
 
 	/*
 	 * request_buffer and result_buffer are not required to be 4k aligned,
@@ -304,7 +304,27 @@ static unsigned long single_24x7_request(u8 domain, u32 offset, u16 ix,
 	struct reqb {
 		struct hv_24x7_request_buffer buf;
 		struct hv_24x7_request req;
-	} __packed __aligned(4096) request_buffer = {
+	} __packed *request_buffer;
+
+	struct {
+		struct hv_24x7_data_result_buffer buf;
+		struct hv_24x7_result res;
+		struct hv_24x7_result_element elem;
+		__be64 result;
+	} __packed *result_buffer;
+
+	BUILD_BUG_ON(sizeof(*request_buffer) > 4096);
+	BUILD_BUG_ON(sizeof(*result_buffer) > 4096);
+
+	request_buffer = kmem_cache_zalloc(hv_page_cache, GFP_USER);
+	if (!request_buffer)
+		goto out;
+
+	result_buffer = kmem_cache_zalloc(hv_page_cache, GFP_USER);
+	if (!result_buffer)
+		goto out_free_request_buffer;
+
+	*request_buffer = (struct reqb) {
 		.buf = {
 			.interface_version = HV_24X7_IF_VERSION_CURRENT,
 			.num_requests = 1,
@@ -320,28 +340,27 @@ static unsigned long single_24x7_request(u8 domain, u32 offset, u16 ix,
 		}
 	};
 
-	struct resb {
-		struct hv_24x7_data_result_buffer buf;
-		struct hv_24x7_result res;
-		struct hv_24x7_result_element elem;
-		__be64 result;
-	} __packed __aligned(4096) result_buffer = {};
-
 	ret = plpar_hcall_norets(H_GET_24X7_DATA,
-			virt_to_phys(&request_buffer), sizeof(request_buffer),
-			virt_to_phys(&result_buffer),  sizeof(result_buffer));
+			virt_to_phys(request_buffer), sizeof(*request_buffer),
+			virt_to_phys(result_buffer),  sizeof(*result_buffer));
 
 	if (ret) {
 		if (success_expected)
-			pr_err_ratelimited("hcall failed: %d %#x %#x %d => 0x%lx (%ld) detail=0x%x failing ix=%x\n",
-					domain, offset, ix, lpar,
-					ret, ret,
-					result_buffer.buf.detailed_rc,
-					result_buffer.buf.failing_request_ix);
-		return ret;
+			pr_err_ratelimited("hcall failed: %d %#x %#x %d => "
+				"0x%lx (%ld) detail=0x%x failing ix=%x\n",
+				domain, offset, ix, lpar, ret, ret,
+				result_buffer->buf.detailed_rc,
+				result_buffer->buf.failing_request_ix);
+		goto out_free_result_buffer;
 	}
 
-	*res = be64_to_cpu(result_buffer.result);
+	*res = be64_to_cpu(result_buffer->result);
+
+out_free_result_buffer:
+	kfree(result_buffer);
+out_free_request_buffer:
+	kfree(request_buffer);
+out:
 	return ret;
 }
 
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH 3/5] perf Documentation: sysfs events/ interfaces
From: Sukadev Bhattiprolu @ 2014-10-01  6:03 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo, ak, Jiri Olsa, peterz, eranian,
	Paul Mackerras
  Cc: Michael Ellerman, linux-kernel, dev, linuxppc-dev,
	Anshuman Khandual
In-Reply-To: <1412143402-26061-1-git-send-email-sukadev@linux.vnet.ibm.com>

From: Cody P Schafer <dev@codyps.com>

Add documentation for the <event>, <event>.scale, and <event>.unit
files in sysfs.

	<event>.scale and <event>.unit were undocumented.
	<event> was previously documented only for specific powerpc pmu events.

CC: Haren Myneni <hbabu@us.ibm.com>
Signed-off-by: Cody P Schafer <dev@codyps.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
 .../testing/sysfs-bus-event_source-devices-events  | 60 ++++++++++++++++++++++
 1 file changed, 60 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
index 7b40a3c..a5226f0 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
@@ -599,3 +599,63 @@ Description:	POWER-systems specific performance monitoring events
 		Further, multiple terms like 'event=0xNNNN' can be specified
 		and separated with comma. All available terms are defined in
 		the /sys/bus/event_source/devices/<dev>/format file.
+
+What: /sys/bus/event_source/devices/<pmu>/events/<event>
+Date: 2014/02/24
+Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:	Per-pmu performance monitoring events specific to the running system
+
+		Each file (except for some of those with a '.' in them, '.unit'
+		and '.scale') in the 'events' directory describes a single
+		performance monitoring event supported by the <pmu>. The name
+		of the file is the name of the event.
+
+		File contents:
+
+			<term>[=<value>][,<term>[=<value>]]...
+
+		Where <term> is one of the terms listed under
+		/sys/bus/event_source/devices/<pmu>/format/ and <value> is
+		a number is base-16 format with a '0x' prefix (lowercase only).
+		If a <term> is specified alone (without an assigned value), it
+		is implied that 0x1 is assigned to that <term>.
+
+		Examples (each of these lines would be in a seperate file):
+
+			event=0x2abc
+			event=0x423,inv,cmask=0x3
+			domain=0x1,offset=0x8,starting_index=0xffff
+
+		Each of the assignments indicates a value to be assigned to a
+		particular set of bits (as defined by the format file
+		corresponding to the <term>) in the perf_event structure passed
+		to the perf_open syscall.
+
+What: /sys/bus/event_source/devices/<pmu>/events/<event>.unit
+Date: 2014/02/24
+Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:	Perf event units
+
+		A string specifying the English plural numerical unit that <event>
+		(once multiplied by <event>.scale) represents.
+
+		Example:
+
+			Joules
+
+What: /sys/bus/event_source/devices/<pmu>/events/<event>.scale
+Date: 2014/02/24
+Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:	Perf event scaling factors
+
+		A string representing a floating point value expressed in
+		scientific notation to be multiplied by the event count
+		recieved from the kernel to match the unit specified in the
+		<event>.unit file.
+
+		Example:
+
+			2.3283064365386962890625e-10
+
+		This is provided to avoid performing floating point arithmetic
+		in the kernel.
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH 2/5] Simplify catalog_read()
From: Sukadev Bhattiprolu @ 2014-10-01  6:03 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo, ak, Jiri Olsa, peterz, eranian,
	Paul Mackerras
  Cc: Michael Ellerman, linux-kernel, dev, linuxppc-dev,
	Anshuman Khandual
In-Reply-To: <1412143402-26061-1-git-send-email-sukadev@linux.vnet.ibm.com>

catalog_read() implements the read interface for the sysfs file

	/sys/bus/event_source/devices/hv_24x7/interface/catalog

It essentially takes a buffer, an offset and count as parameters
to the read() call.  It makes a hypervisor call to read a specific
page from the catalog and copy the required bytes into the given
buffer. Each call to catalog_read() returns at most one 4K page.

Given these requirements, we should be able to simplify the
catalog_read().

Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
Changelog[v3]
	[Michael Ellerman] offset_in_page must be based on offsetr;
	page_count is unnecessary.

 arch/powerpc/perf/hv-24x7.c | 101 ++++++--------------------------------------
 1 file changed, 14 insertions(+), 87 deletions(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 697759d..6c8710d 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -75,86 +75,6 @@ static struct attribute_group format_group = {
 
 static struct kmem_cache *hv_page_cache;
 
-/*
- * read_offset_data - copy data from one buffer to another while treating the
- *                    source buffer as a small view on the total avaliable
- *                    source data.
- *
- * @dest: buffer to copy into
- * @dest_len: length of @dest in bytes
- * @requested_offset: the offset within the source data we want. Must be > 0
- * @src: buffer to copy data from
- * @src_len: length of @src in bytes
- * @source_offset: the offset in the sorce data that (src,src_len) refers to.
- *                 Must be > 0
- *
- * returns the number of bytes copied.
- *
- * The following ascii art shows the various buffer possitioning we need to
- * handle, assigns some arbitrary varibles to points on the buffer, and then
- * shows how we fiddle with those values to get things we care about (copy
- * start in src and copy len)
- *
- * s = @src buffer
- * d = @dest buffer
- * '.' areas in d are written to.
- *
- *                       u
- *   x         w	 v  z
- * d           |.........|
- * s |----------------------|
- *
- *                      u
- *   x         w	z     v
- * d           |........------|
- * s |------------------|
- *
- *   x         w        u,z,v
- * d           |........|
- * s |------------------|
- *
- *   x,w                u,v,z
- * d |..................|
- * s |------------------|
- *
- *   x        u
- *   w        v		z
- * d |........|
- * s |------------------|
- *
- *   x      z   w      v
- * d            |------|
- * s |------|
- *
- * x = source_offset
- * w = requested_offset
- * z = source_offset + src_len
- * v = requested_offset + dest_len
- *
- * w_offset_in_s = w - x = requested_offset - source_offset
- * z_offset_in_s = z - x = src_len
- * v_offset_in_s = v - x = request_offset + dest_len - src_len
- */
-static ssize_t read_offset_data(void *dest, size_t dest_len,
-				loff_t requested_offset, void *src,
-				size_t src_len, loff_t source_offset)
-{
-	size_t w_offset_in_s = requested_offset - source_offset;
-	size_t z_offset_in_s = src_len;
-	size_t v_offset_in_s = requested_offset + dest_len - src_len;
-	size_t u_offset_in_s = min(z_offset_in_s, v_offset_in_s);
-	size_t copy_len = u_offset_in_s - w_offset_in_s;
-
-	if (requested_offset < 0 || source_offset < 0)
-		return -EINVAL;
-
-	if (z_offset_in_s <= w_offset_in_s)
-		return 0;
-
-	memcpy(dest, src + w_offset_in_s, copy_len);
-	return copy_len;
-}
-
 static unsigned long h_get_24x7_catalog_page_(unsigned long phys_4096,
 					      unsigned long version,
 					      unsigned long index)
@@ -183,8 +103,10 @@ static ssize_t catalog_read(struct file *filp, struct kobject *kobj,
 {
 	unsigned long hret;
 	ssize_t ret = 0;
-	size_t catalog_len = 0, catalog_page_len = 0, page_count = 0;
+	size_t catalog_len = 0, catalog_page_len = 0;
 	loff_t page_offset = 0;
+	loff_t offset_in_page;
+	size_t copy_len;
 	uint64_t catalog_version_num = 0;
 	void *page = kmem_cache_alloc(hv_page_cache, GFP_USER);
 	struct hv_24x7_catalog_page_0 *page_0 = page;
@@ -202,7 +124,7 @@ static ssize_t catalog_read(struct file *filp, struct kobject *kobj,
 	catalog_len = catalog_page_len * 4096;
 
 	page_offset = offset / 4096;
-	page_count  = count  / 4096;
+	offset_in_page = offset % 4096;
 
 	if (page_offset >= catalog_page_len)
 		goto e_free;
@@ -216,8 +138,13 @@ static ssize_t catalog_read(struct file *filp, struct kobject *kobj,
 		}
 	}
 
-	ret = read_offset_data(buf, count, offset,
-				page, 4096, page_offset * 4096);
+	copy_len = 4096 - offset_in_page;
+	if (copy_len > count)
+		copy_len = count;
+
+	memcpy(buf, page+offset_in_page, copy_len);
+	ret = copy_len;
+
 e_free:
 	if (hret)
 		pr_err("h_get_24x7_catalog_page(ver=%lld, page=%lld) failed:"
@@ -225,9 +152,9 @@ e_free:
 		       catalog_version_num, page_offset, hret);
 	kmem_cache_free(hv_page_cache, page);
 
-	pr_devel("catalog_read: offset=%lld(%lld) count=%zu(%zu) catalog_len=%zu(%zu) => %zd\n",
-			offset, page_offset, count, page_count, catalog_len,
-			catalog_page_len, ret);
+	pr_devel("catalog_read: offset=%lld(%lld) count=%zu "
+			"catalog_len=%zu(%zu) => %zd\n", offset, page_offset,
+			count, catalog_len, catalog_page_len, ret);
 
 	return ret;
 }
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH 4/5] perf Documentation: remove duplicated docs for powerpc cpu specific events
From: Sukadev Bhattiprolu @ 2014-10-01  6:03 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo, ak, Jiri Olsa, peterz, eranian,
	Paul Mackerras
  Cc: Michael Ellerman, linux-kernel, dev, linuxppc-dev,
	Anshuman Khandual
In-Reply-To: <1412143402-26061-1-git-send-email-sukadev@linux.vnet.ibm.com>

From: Cody P Schafer <dev@codyps.com>

Listing specific events doesn't actually help us at all here because:
 - these events actually vary between different ppc processors, they
   aren't garunteed to be present.
 - the documentation of the (generic) file contents is now superceded by the
   docs for arbitrary event file contents.

CC: Haren Myneni <hbabu@us.ibm.com>
Signed-off-by: Cody P Schafer <dev@codyps.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
 .../testing/sysfs-bus-event_source-devices-events  | 573 ---------------------
 1 file changed, 573 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
index a5226f0..20979f8 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
@@ -27,579 +27,6 @@ Description:	Generic performance monitoring events
 		"basename".
 
 
-What: 		/sys/devices/cpu/events/PM_1PLUS_PPC_CMPL
-		/sys/devices/cpu/events/PM_BRU_FIN
-		/sys/devices/cpu/events/PM_BR_MPRED
-		/sys/devices/cpu/events/PM_CMPLU_STALL
-		/sys/devices/cpu/events/PM_CMPLU_STALL_BRU
-		/sys/devices/cpu/events/PM_CMPLU_STALL_DCACHE_MISS
-		/sys/devices/cpu/events/PM_CMPLU_STALL_DFU
-		/sys/devices/cpu/events/PM_CMPLU_STALL_DIV
-		/sys/devices/cpu/events/PM_CMPLU_STALL_ERAT_MISS
-		/sys/devices/cpu/events/PM_CMPLU_STALL_FXU
-		/sys/devices/cpu/events/PM_CMPLU_STALL_IFU
-		/sys/devices/cpu/events/PM_CMPLU_STALL_LSU
-		/sys/devices/cpu/events/PM_CMPLU_STALL_REJECT
-		/sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR
-		/sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR_LONG
-		/sys/devices/cpu/events/PM_CMPLU_STALL_STORE
-		/sys/devices/cpu/events/PM_CMPLU_STALL_THRD
-		/sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR
-		/sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR_LONG
-		/sys/devices/cpu/events/PM_CYC
-		/sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED
-		/sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED_IC_MISS
-		/sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
-		/sys/devices/cpu/events/PM_GCT_NOSLOT_IC_MISS
-		/sys/devices/cpu/events/PM_GRP_CMPL
-		/sys/devices/cpu/events/PM_INST_CMPL
-		/sys/devices/cpu/events/PM_LD_MISS_L1
-		/sys/devices/cpu/events/PM_LD_REF_L1
-		/sys/devices/cpu/events/PM_RUN_CYC
-		/sys/devices/cpu/events/PM_RUN_INST_CMPL
-		/sys/devices/cpu/events/PM_IC_DEMAND_L2_BR_ALL
-		/sys/devices/cpu/events/PM_GCT_UTIL_7_TO_10_SLOTS
-		/sys/devices/cpu/events/PM_PMC2_SAVED
-		/sys/devices/cpu/events/PM_VSU0_16FLOP
-		/sys/devices/cpu/events/PM_MRK_LSU_DERAT_MISS
-		/sys/devices/cpu/events/PM_MRK_ST_CMPL
-		/sys/devices/cpu/events/PM_NEST_PAIR3_ADD
-		/sys/devices/cpu/events/PM_L2_ST_DISP
-		/sys/devices/cpu/events/PM_L2_CASTOUT_MOD
-		/sys/devices/cpu/events/PM_ISEG
-		/sys/devices/cpu/events/PM_MRK_INST_TIMEO
-		/sys/devices/cpu/events/PM_L2_RCST_DISP_FAIL_ADDR
-		/sys/devices/cpu/events/PM_LSU1_DC_PREF_STREAM_CONFIRM
-		/sys/devices/cpu/events/PM_IERAT_WR_64K
-		/sys/devices/cpu/events/PM_MRK_DTLB_MISS_16M
-		/sys/devices/cpu/events/PM_IERAT_MISS
-		/sys/devices/cpu/events/PM_MRK_PTEG_FROM_LMEM
-		/sys/devices/cpu/events/PM_FLOP
-		/sys/devices/cpu/events/PM_THRD_PRIO_4_5_CYC
-		/sys/devices/cpu/events/PM_BR_PRED_TA
-		/sys/devices/cpu/events/PM_EXT_INT
-		/sys/devices/cpu/events/PM_VSU_FSQRT_FDIV
-		/sys/devices/cpu/events/PM_MRK_LD_MISS_EXPOSED_CYC
-		/sys/devices/cpu/events/PM_LSU1_LDF
-		/sys/devices/cpu/events/PM_IC_WRITE_ALL
-		/sys/devices/cpu/events/PM_LSU0_SRQ_STFWD
-		/sys/devices/cpu/events/PM_PTEG_FROM_RL2L3_MOD
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_SHR
-		/sys/devices/cpu/events/PM_DATA_FROM_L21_MOD
-		/sys/devices/cpu/events/PM_VSU1_SCAL_DOUBLE_ISSUED
-		/sys/devices/cpu/events/PM_VSU0_8FLOP
-		/sys/devices/cpu/events/PM_POWER_EVENT1
-		/sys/devices/cpu/events/PM_DISP_CLB_HELD_BAL
-		/sys/devices/cpu/events/PM_VSU1_2FLOP
-		/sys/devices/cpu/events/PM_LWSYNC_HELD
-		/sys/devices/cpu/events/PM_PTEG_FROM_DL2L3_SHR
-		/sys/devices/cpu/events/PM_INST_FROM_L21_MOD
-		/sys/devices/cpu/events/PM_IERAT_XLATE_WR_16MPLUS
-		/sys/devices/cpu/events/PM_IC_REQ_ALL
-		/sys/devices/cpu/events/PM_DSLB_MISS
-		/sys/devices/cpu/events/PM_L3_MISS
-		/sys/devices/cpu/events/PM_LSU0_L1_PREF
-		/sys/devices/cpu/events/PM_VSU_SCALAR_SINGLE_ISSUED
-		/sys/devices/cpu/events/PM_LSU1_DC_PREF_STREAM_CONFIRM_STRIDE
-		/sys/devices/cpu/events/PM_L2_INST
-		/sys/devices/cpu/events/PM_VSU0_FRSP
-		/sys/devices/cpu/events/PM_FLUSH_DISP
-		/sys/devices/cpu/events/PM_PTEG_FROM_L2MISS
-		/sys/devices/cpu/events/PM_VSU1_DQ_ISSUED
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_DMEM
-		/sys/devices/cpu/events/PM_LSU_FLUSH_ULD
-		/sys/devices/cpu/events/PM_PTEG_FROM_LMEM
-		/sys/devices/cpu/events/PM_MRK_DERAT_MISS_16M
-		/sys/devices/cpu/events/PM_THRD_ALL_RUN_CYC
-		/sys/devices/cpu/events/PM_MEM0_PREFETCH_DISP
-		/sys/devices/cpu/events/PM_MRK_STALL_CMPLU_CYC_COUNT
-		/sys/devices/cpu/events/PM_DATA_FROM_DL2L3_MOD
-		/sys/devices/cpu/events/PM_VSU_FRSP
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_L21_MOD
-		/sys/devices/cpu/events/PM_PMC1_OVERFLOW
-		/sys/devices/cpu/events/PM_VSU0_SINGLE
-		/sys/devices/cpu/events/PM_MRK_PTEG_FROM_L3MISS
-		/sys/devices/cpu/events/PM_MRK_PTEG_FROM_L31_SHR
-		/sys/devices/cpu/events/PM_VSU0_VECTOR_SP_ISSUED
-		/sys/devices/cpu/events/PM_VSU1_FEST
-		/sys/devices/cpu/events/PM_MRK_INST_DISP
-		/sys/devices/cpu/events/PM_VSU0_COMPLEX_ISSUED
-		/sys/devices/cpu/events/PM_LSU1_FLUSH_UST
-		/sys/devices/cpu/events/PM_FXU_IDLE
-		/sys/devices/cpu/events/PM_LSU0_FLUSH_ULD
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_DL2L3_MOD
-		/sys/devices/cpu/events/PM_LSU_LMQ_SRQ_EMPTY_ALL_CYC
-		/sys/devices/cpu/events/PM_LSU1_REJECT_LMQ_FULL
-		/sys/devices/cpu/events/PM_INST_PTEG_FROM_L21_MOD
-		/sys/devices/cpu/events/PM_INST_FROM_RL2L3_MOD
-		/sys/devices/cpu/events/PM_SHL_CREATED
-		/sys/devices/cpu/events/PM_L2_ST_HIT
-		/sys/devices/cpu/events/PM_DATA_FROM_DMEM
-		/sys/devices/cpu/events/PM_L3_LD_MISS
-		/sys/devices/cpu/events/PM_FXU1_BUSY_FXU0_IDLE
-		/sys/devices/cpu/events/PM_DISP_CLB_HELD_RES
-		/sys/devices/cpu/events/PM_L2_SN_SX_I_DONE
-		/sys/devices/cpu/events/PM_STCX_CMPL
-		/sys/devices/cpu/events/PM_VSU0_2FLOP
-		/sys/devices/cpu/events/PM_L3_PREF_MISS
-		/sys/devices/cpu/events/PM_LSU_SRQ_SYNC_CYC
-		/sys/devices/cpu/events/PM_LSU_REJECT_ERAT_MISS
-		/sys/devices/cpu/events/PM_L1_ICACHE_MISS
-		/sys/devices/cpu/events/PM_LSU1_FLUSH_SRQ
-		/sys/devices/cpu/events/PM_LD_REF_L1_LSU0
-		/sys/devices/cpu/events/PM_VSU0_FEST
-		/sys/devices/cpu/events/PM_VSU_VECTOR_SINGLE_ISSUED
-		/sys/devices/cpu/events/PM_FREQ_UP
-		/sys/devices/cpu/events/PM_DATA_FROM_LMEM
-		/sys/devices/cpu/events/PM_LSU1_LDX
-		/sys/devices/cpu/events/PM_PMC3_OVERFLOW
-		/sys/devices/cpu/events/PM_MRK_BR_MPRED
-		/sys/devices/cpu/events/PM_SHL_MATCH
-		/sys/devices/cpu/events/PM_MRK_BR_TAKEN
-		/sys/devices/cpu/events/PM_ISLB_MISS
-		/sys/devices/cpu/events/PM_DISP_HELD_THERMAL
-		/sys/devices/cpu/events/PM_INST_PTEG_FROM_RL2L3_SHR
-		/sys/devices/cpu/events/PM_LSU1_SRQ_STFWD
-		/sys/devices/cpu/events/PM_PTEG_FROM_DMEM
-		/sys/devices/cpu/events/PM_VSU_2FLOP
-		/sys/devices/cpu/events/PM_GCT_FULL_CYC
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_L3_CYC
-		/sys/devices/cpu/events/PM_LSU_SRQ_S0_ALLOC
-		/sys/devices/cpu/events/PM_MRK_DERAT_MISS_4K
-		/sys/devices/cpu/events/PM_BR_MPRED_TA
-		/sys/devices/cpu/events/PM_INST_PTEG_FROM_L2MISS
-		/sys/devices/cpu/events/PM_DPU_HELD_POWER
-		/sys/devices/cpu/events/PM_MRK_VSU_FIN
-		/sys/devices/cpu/events/PM_LSU_SRQ_S0_VALID
-		/sys/devices/cpu/events/PM_GCT_EMPTY_CYC
-		/sys/devices/cpu/events/PM_IOPS_DISP
-		/sys/devices/cpu/events/PM_RUN_SPURR
-		/sys/devices/cpu/events/PM_PTEG_FROM_L21_MOD
-		/sys/devices/cpu/events/PM_VSU0_1FLOP
-		/sys/devices/cpu/events/PM_SNOOP_TLBIE
-		/sys/devices/cpu/events/PM_DATA_FROM_L3MISS
-		/sys/devices/cpu/events/PM_VSU_SINGLE
-		/sys/devices/cpu/events/PM_DTLB_MISS_16G
-		/sys/devices/cpu/events/PM_FLUSH
-		/sys/devices/cpu/events/PM_L2_LD_HIT
-		/sys/devices/cpu/events/PM_NEST_PAIR2_AND
-		/sys/devices/cpu/events/PM_VSU1_1FLOP
-		/sys/devices/cpu/events/PM_IC_PREF_REQ
-		/sys/devices/cpu/events/PM_L3_LD_HIT
-		/sys/devices/cpu/events/PM_DISP_HELD
-		/sys/devices/cpu/events/PM_L2_LD
-		/sys/devices/cpu/events/PM_LSU_FLUSH_SRQ
-		/sys/devices/cpu/events/PM_BC_PLUS_8_CONV
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_MOD_CYC
-		/sys/devices/cpu/events/PM_L2_RCST_BUSY_RC_FULL
-		/sys/devices/cpu/events/PM_TB_BIT_TRANS
-		/sys/devices/cpu/events/PM_THERMAL_MAX
-		/sys/devices/cpu/events/PM_LSU1_FLUSH_ULD
-		/sys/devices/cpu/events/PM_LSU1_REJECT_LHS
-		/sys/devices/cpu/events/PM_LSU_LRQ_S0_ALLOC
-		/sys/devices/cpu/events/PM_L3_CO_L31
-		/sys/devices/cpu/events/PM_POWER_EVENT4
-		/sys/devices/cpu/events/PM_DATA_FROM_L31_SHR
-		/sys/devices/cpu/events/PM_BR_UNCOND
-		/sys/devices/cpu/events/PM_LSU1_DC_PREF_STREAM_ALLOC
-		/sys/devices/cpu/events/PM_PMC4_REWIND
-		/sys/devices/cpu/events/PM_L2_RCLD_DISP
-		/sys/devices/cpu/events/PM_THRD_PRIO_2_3_CYC
-		/sys/devices/cpu/events/PM_MRK_PTEG_FROM_L2MISS
-		/sys/devices/cpu/events/PM_IC_DEMAND_L2_BHT_REDIRECT
-		/sys/devices/cpu/events/PM_DATA_FROM_L31_SHR
-		/sys/devices/cpu/events/PM_IC_PREF_CANCEL_L2
-		/sys/devices/cpu/events/PM_MRK_FIN_STALL_CYC_COUNT
-		/sys/devices/cpu/events/PM_BR_PRED_CCACHE
-		/sys/devices/cpu/events/PM_GCT_UTIL_1_TO_2_SLOTS
-		/sys/devices/cpu/events/PM_MRK_ST_CMPL_INT
-		/sys/devices/cpu/events/PM_LSU_TWO_TABLEWALK_CYC
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_L3MISS
-		/sys/devices/cpu/events/PM_LSU_SET_MPRED
-		/sys/devices/cpu/events/PM_FLUSH_DISP_TLBIE
-		/sys/devices/cpu/events/PM_VSU1_FCONV
-		/sys/devices/cpu/events/PM_DERAT_MISS_16G
-		/sys/devices/cpu/events/PM_INST_FROM_LMEM
-		/sys/devices/cpu/events/PM_IC_DEMAND_L2_BR_REDIRECT
-		/sys/devices/cpu/events/PM_INST_PTEG_FROM_L2
-		/sys/devices/cpu/events/PM_PTEG_FROM_L2
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_L21_SHR_CYC
-		/sys/devices/cpu/events/PM_MRK_DTLB_MISS_4K
-		/sys/devices/cpu/events/PM_VSU0_FPSCR
-		/sys/devices/cpu/events/PM_VSU1_VECT_DOUBLE_ISSUED
-		/sys/devices/cpu/events/PM_MRK_PTEG_FROM_RL2L3_MOD
-		/sys/devices/cpu/events/PM_MEM0_RQ_DISP
-		/sys/devices/cpu/events/PM_L2_LD_MISS
-		/sys/devices/cpu/events/PM_VMX_RESULT_SAT_1
-		/sys/devices/cpu/events/PM_L1_PREF
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_LMEM_CYC
-		/sys/devices/cpu/events/PM_GRP_IC_MISS_NONSPEC
-		/sys/devices/cpu/events/PM_PB_NODE_PUMP
-		/sys/devices/cpu/events/PM_SHL_MERGED
-		/sys/devices/cpu/events/PM_NEST_PAIR1_ADD
-		/sys/devices/cpu/events/PM_DATA_FROM_L3
-		/sys/devices/cpu/events/PM_LSU_FLUSH
-		/sys/devices/cpu/events/PM_LSU_SRQ_SYNC_COUNT
-		/sys/devices/cpu/events/PM_PMC2_OVERFLOW
-		/sys/devices/cpu/events/PM_LSU_LDF
-		/sys/devices/cpu/events/PM_POWER_EVENT3
-		/sys/devices/cpu/events/PM_DISP_WT
-		/sys/devices/cpu/events/PM_IC_BANK_CONFLICT
-		/sys/devices/cpu/events/PM_BR_MPRED_CR_TA
-		/sys/devices/cpu/events/PM_L2_INST_MISS
-		/sys/devices/cpu/events/PM_NEST_PAIR2_ADD
-		/sys/devices/cpu/events/PM_MRK_LSU_FLUSH
-		/sys/devices/cpu/events/PM_L2_LDST
-		/sys/devices/cpu/events/PM_INST_FROM_L31_SHR
-		/sys/devices/cpu/events/PM_VSU0_FIN
-		/sys/devices/cpu/events/PM_VSU1_FCONV
-		/sys/devices/cpu/events/PM_INST_FROM_RMEM
-		/sys/devices/cpu/events/PM_DISP_CLB_HELD_TLBIE
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_DMEM_CYC
-		/sys/devices/cpu/events/PM_BR_PRED_CR
-		/sys/devices/cpu/events/PM_LSU_REJECT
-		/sys/devices/cpu/events/PM_GCT_UTIL_3_TO_6_SLOTS
-		/sys/devices/cpu/events/PM_CMPLU_STALL_END_GCT_NOSLOT
-		/sys/devices/cpu/events/PM_LSU0_REJECT_LMQ_FULL
-		/sys/devices/cpu/events/PM_VSU_FEST
-		/sys/devices/cpu/events/PM_NEST_PAIR0_AND
-		/sys/devices/cpu/events/PM_PTEG_FROM_L3
-		/sys/devices/cpu/events/PM_POWER_EVENT2
-		/sys/devices/cpu/events/PM_IC_PREF_CANCEL_PAGE
-		/sys/devices/cpu/events/PM_VSU0_FSQRT_FDIV
-		/sys/devices/cpu/events/PM_MRK_GRP_CMPL
-		/sys/devices/cpu/events/PM_VSU0_SCAL_DOUBLE_ISSUED
-		/sys/devices/cpu/events/PM_GRP_DISP
-		/sys/devices/cpu/events/PM_LSU0_LDX
-		/sys/devices/cpu/events/PM_DATA_FROM_L2
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_RL2L3_MOD
-		/sys/devices/cpu/events/PM_VSU0_VECT_DOUBLE_ISSUED
-		/sys/devices/cpu/events/PM_VSU1_2FLOP_DOUBLE
-		/sys/devices/cpu/events/PM_THRD_PRIO_6_7_CYC
-		/sys/devices/cpu/events/PM_BC_PLUS_8_RSLV_TAKEN
-		/sys/devices/cpu/events/PM_BR_MPRED_CR
-		/sys/devices/cpu/events/PM_L3_CO_MEM
-		/sys/devices/cpu/events/PM_DATA_FROM_RL2L3_MOD
-		/sys/devices/cpu/events/PM_LSU_SRQ_FULL_CYC
-		/sys/devices/cpu/events/PM_TABLEWALK_CYC
-		/sys/devices/cpu/events/PM_MRK_PTEG_FROM_RMEM
-		/sys/devices/cpu/events/PM_LSU_SRQ_STFWD
-		/sys/devices/cpu/events/PM_INST_PTEG_FROM_RMEM
-		/sys/devices/cpu/events/PM_FXU0_FIN
-		/sys/devices/cpu/events/PM_LSU1_L1_SW_PREF
-		/sys/devices/cpu/events/PM_PTEG_FROM_L31_MOD
-		/sys/devices/cpu/events/PM_PMC5_OVERFLOW
-		/sys/devices/cpu/events/PM_LD_REF_L1_LSU1
-		/sys/devices/cpu/events/PM_INST_PTEG_FROM_L21_SHR
-		/sys/devices/cpu/events/PM_DATA_FROM_RMEM
-		/sys/devices/cpu/events/PM_VSU0_SCAL_SINGLE_ISSUED
-		/sys/devices/cpu/events/PM_BR_MPRED_LSTACK
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_RL2L3_MOD_CYC
-		/sys/devices/cpu/events/PM_LSU0_FLUSH_UST
-		/sys/devices/cpu/events/PM_LSU_NCST
-		/sys/devices/cpu/events/PM_BR_TAKEN
-		/sys/devices/cpu/events/PM_INST_PTEG_FROM_LMEM
-		/sys/devices/cpu/events/PM_DTLB_MISS_4K
-		/sys/devices/cpu/events/PM_PMC4_SAVED
-		/sys/devices/cpu/events/PM_VSU1_PERMUTE_ISSUED
-		/sys/devices/cpu/events/PM_SLB_MISS
-		/sys/devices/cpu/events/PM_LSU1_FLUSH_LRQ
-		/sys/devices/cpu/events/PM_DTLB_MISS
-		/sys/devices/cpu/events/PM_VSU1_FRSP
-		/sys/devices/cpu/events/PM_VSU_VECTOR_DOUBLE_ISSUED
-		/sys/devices/cpu/events/PM_L2_CASTOUT_SHR
-		/sys/devices/cpu/events/PM_DATA_FROM_DL2L3_SHR
-		/sys/devices/cpu/events/PM_VSU1_STF
-		/sys/devices/cpu/events/PM_ST_FIN
-		/sys/devices/cpu/events/PM_PTEG_FROM_L21_SHR
-		/sys/devices/cpu/events/PM_L2_LOC_GUESS_WRONG
-		/sys/devices/cpu/events/PM_MRK_STCX_FAIL
-		/sys/devices/cpu/events/PM_LSU0_REJECT_LHS
-		/sys/devices/cpu/events/PM_IC_PREF_CANCEL_HIT
-		/sys/devices/cpu/events/PM_L3_PREF_BUSY
-		/sys/devices/cpu/events/PM_MRK_BRU_FIN
-		/sys/devices/cpu/events/PM_LSU1_NCLD
-		/sys/devices/cpu/events/PM_INST_PTEG_FROM_L31_MOD
-		/sys/devices/cpu/events/PM_LSU_NCLD
-		/sys/devices/cpu/events/PM_LSU_LDX
-		/sys/devices/cpu/events/PM_L2_LOC_GUESS_CORRECT
-		/sys/devices/cpu/events/PM_THRESH_TIMEO
-		/sys/devices/cpu/events/PM_L3_PREF_ST
-		/sys/devices/cpu/events/PM_DISP_CLB_HELD_SYNC
-		/sys/devices/cpu/events/PM_VSU_SIMPLE_ISSUED
-		/sys/devices/cpu/events/PM_VSU1_SINGLE
-		/sys/devices/cpu/events/PM_DATA_TABLEWALK_CYC
-		/sys/devices/cpu/events/PM_L2_RC_ST_DONE
-		/sys/devices/cpu/events/PM_MRK_PTEG_FROM_L21_MOD
-		/sys/devices/cpu/events/PM_LARX_LSU1
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_RMEM
-		/sys/devices/cpu/events/PM_DISP_CLB_HELD
-		/sys/devices/cpu/events/PM_DERAT_MISS_4K
-		/sys/devices/cpu/events/PM_L2_RCLD_DISP_FAIL_ADDR
-		/sys/devices/cpu/events/PM_SEG_EXCEPTION
-		/sys/devices/cpu/events/PM_FLUSH_DISP_SB
-		/sys/devices/cpu/events/PM_L2_DC_INV
-		/sys/devices/cpu/events/PM_PTEG_FROM_DL2L3_MOD
-		/sys/devices/cpu/events/PM_DSEG
-		/sys/devices/cpu/events/PM_BR_PRED_LSTACK
-		/sys/devices/cpu/events/PM_VSU0_STF
-		/sys/devices/cpu/events/PM_LSU_FX_FIN
-		/sys/devices/cpu/events/PM_DERAT_MISS_16M
-		/sys/devices/cpu/events/PM_MRK_PTEG_FROM_DL2L3_MOD
-		/sys/devices/cpu/events/PM_GCT_UTIL_11_PLUS_SLOTS
-		/sys/devices/cpu/events/PM_INST_FROM_L3
-		/sys/devices/cpu/events/PM_MRK_IFU_FIN
-		/sys/devices/cpu/events/PM_ITLB_MISS
-		/sys/devices/cpu/events/PM_VSU_STF
-		/sys/devices/cpu/events/PM_LSU_FLUSH_UST
-		/sys/devices/cpu/events/PM_L2_LDST_MISS
-		/sys/devices/cpu/events/PM_FXU1_FIN
-		/sys/devices/cpu/events/PM_SHL_DEALLOCATED
-		/sys/devices/cpu/events/PM_L2_SN_M_WR_DONE
-		/sys/devices/cpu/events/PM_LSU_REJECT_SET_MPRED
-		/sys/devices/cpu/events/PM_L3_PREF_LD
-		/sys/devices/cpu/events/PM_L2_SN_M_RD_DONE
-		/sys/devices/cpu/events/PM_MRK_DERAT_MISS_16G
-		/sys/devices/cpu/events/PM_VSU_FCONV
-		/sys/devices/cpu/events/PM_ANY_THRD_RUN_CYC
-		/sys/devices/cpu/events/PM_LSU_LMQ_FULL_CYC
-		/sys/devices/cpu/events/PM_MRK_LSU_REJECT_LHS
-		/sys/devices/cpu/events/PM_MRK_LD_MISS_L1_CYC
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_L2_CYC
-		/sys/devices/cpu/events/PM_INST_IMC_MATCH_DISP
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_RMEM_CYC
-		/sys/devices/cpu/events/PM_VSU0_SIMPLE_ISSUED
-		/sys/devices/cpu/events/PM_MRK_PTEG_FROM_RL2L3_SHR
-		/sys/devices/cpu/events/PM_VSU_FMA_DOUBLE
-		/sys/devices/cpu/events/PM_VSU_4FLOP
-		/sys/devices/cpu/events/PM_VSU1_FIN
-		/sys/devices/cpu/events/PM_NEST_PAIR1_AND
-		/sys/devices/cpu/events/PM_INST_PTEG_FROM_RL2L3_MOD
-		/sys/devices/cpu/events/PM_PTEG_FROM_RMEM
-		/sys/devices/cpu/events/PM_LSU_LRQ_S0_VALID
-		/sys/devices/cpu/events/PM_LSU0_LDF
-		/sys/devices/cpu/events/PM_FLUSH_COMPLETION
-		/sys/devices/cpu/events/PM_ST_MISS_L1
-		/sys/devices/cpu/events/PM_L2_NODE_PUMP
-		/sys/devices/cpu/events/PM_INST_FROM_DL2L3_SHR
-		/sys/devices/cpu/events/PM_MRK_STALL_CMPLU_CYC
-		/sys/devices/cpu/events/PM_VSU1_DENORM
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_SHR_CYC
-		/sys/devices/cpu/events/PM_NEST_PAIR0_ADD
-		/sys/devices/cpu/events/PM_INST_FROM_L3MISS
-		/sys/devices/cpu/events/PM_EE_OFF_EXT_INT
-		/sys/devices/cpu/events/PM_INST_PTEG_FROM_DMEM
-		/sys/devices/cpu/events/PM_INST_FROM_DL2L3_MOD
-		/sys/devices/cpu/events/PM_PMC6_OVERFLOW
-		/sys/devices/cpu/events/PM_VSU_2FLOP_DOUBLE
-		/sys/devices/cpu/events/PM_TLB_MISS
-		/sys/devices/cpu/events/PM_FXU_BUSY
-		/sys/devices/cpu/events/PM_L2_RCLD_DISP_FAIL_OTHER
-		/sys/devices/cpu/events/PM_LSU_REJECT_LMQ_FULL
-		/sys/devices/cpu/events/PM_IC_RELOAD_SHR
-		/sys/devices/cpu/events/PM_GRP_MRK
-		/sys/devices/cpu/events/PM_MRK_ST_NEST
-		/sys/devices/cpu/events/PM_VSU1_FSQRT_FDIV
-		/sys/devices/cpu/events/PM_LSU0_FLUSH_LRQ
-		/sys/devices/cpu/events/PM_LARX_LSU0
-		/sys/devices/cpu/events/PM_IBUF_FULL_CYC
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_DL2L3_SHR_CYC
-		/sys/devices/cpu/events/PM_LSU_DC_PREF_STREAM_ALLOC
-		/sys/devices/cpu/events/PM_GRP_MRK_CYC
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_RL2L3_SHR_CYC
-		/sys/devices/cpu/events/PM_L2_GLOB_GUESS_CORRECT
-		/sys/devices/cpu/events/PM_LSU_REJECT_LHS
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_LMEM
-		/sys/devices/cpu/events/PM_INST_PTEG_FROM_L3
-		/sys/devices/cpu/events/PM_FREQ_DOWN
-		/sys/devices/cpu/events/PM_PB_RETRY_NODE_PUMP
-		/sys/devices/cpu/events/PM_INST_FROM_RL2L3_SHR
-		/sys/devices/cpu/events/PM_MRK_INST_ISSUED
-		/sys/devices/cpu/events/PM_PTEG_FROM_L3MISS
-		/sys/devices/cpu/events/PM_RUN_PURR
-		/sys/devices/cpu/events/PM_MRK_GRP_IC_MISS
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_L3
-		/sys/devices/cpu/events/PM_PTEG_FROM_RL2L3_SHR
-		/sys/devices/cpu/events/PM_LSU_FLUSH_LRQ
-		/sys/devices/cpu/events/PM_MRK_DERAT_MISS_64K
-		/sys/devices/cpu/events/PM_INST_PTEG_FROM_DL2L3_MOD
-		/sys/devices/cpu/events/PM_L2_ST_MISS
-		/sys/devices/cpu/events/PM_MRK_PTEG_FROM_L21_SHR
-		/sys/devices/cpu/events/PM_LWSYNC
-		/sys/devices/cpu/events/PM_LSU0_DC_PREF_STREAM_CONFIRM_STRIDE
-		/sys/devices/cpu/events/PM_MRK_LSU_FLUSH_LRQ
-		/sys/devices/cpu/events/PM_INST_IMC_MATCH_CMPL
-		/sys/devices/cpu/events/PM_NEST_PAIR3_AND
-		/sys/devices/cpu/events/PM_PB_RETRY_SYS_PUMP
-		/sys/devices/cpu/events/PM_MRK_INST_FIN
-		/sys/devices/cpu/events/PM_MRK_PTEG_FROM_DL2L3_SHR
-		/sys/devices/cpu/events/PM_INST_FROM_L31_MOD
-		/sys/devices/cpu/events/PM_MRK_DTLB_MISS_64K
-		/sys/devices/cpu/events/PM_LSU_FIN
-		/sys/devices/cpu/events/PM_MRK_LSU_REJECT
-		/sys/devices/cpu/events/PM_L2_CO_FAIL_BUSY
-		/sys/devices/cpu/events/PM_MEM0_WQ_DISP
-		/sys/devices/cpu/events/PM_DATA_FROM_L31_MOD
-		/sys/devices/cpu/events/PM_THERMAL_WARN
-		/sys/devices/cpu/events/PM_VSU0_4FLOP
-		/sys/devices/cpu/events/PM_BR_MPRED_CCACHE
-		/sys/devices/cpu/events/PM_L1_DEMAND_WRITE
-		/sys/devices/cpu/events/PM_FLUSH_BR_MPRED
-		/sys/devices/cpu/events/PM_MRK_DTLB_MISS_16G
-		/sys/devices/cpu/events/PM_MRK_PTEG_FROM_DMEM
-		/sys/devices/cpu/events/PM_L2_RCST_DISP
-		/sys/devices/cpu/events/PM_LSU_PARTIAL_CDF
-		/sys/devices/cpu/events/PM_DISP_CLB_HELD_SB
-		/sys/devices/cpu/events/PM_VSU0_FMA_DOUBLE
-		/sys/devices/cpu/events/PM_FXU0_BUSY_FXU1_IDLE
-		/sys/devices/cpu/events/PM_IC_DEMAND_CYC
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_L21_SHR
-		/sys/devices/cpu/events/PM_MRK_LSU_FLUSH_UST
-		/sys/devices/cpu/events/PM_INST_PTEG_FROM_L3MISS
-		/sys/devices/cpu/events/PM_VSU_DENORM
-		/sys/devices/cpu/events/PM_MRK_LSU_PARTIAL_CDF
-		/sys/devices/cpu/events/PM_INST_FROM_L21_SHR
-		/sys/devices/cpu/events/PM_IC_PREF_WRITE
-		/sys/devices/cpu/events/PM_BR_PRED
-		/sys/devices/cpu/events/PM_INST_FROM_DMEM
-		/sys/devices/cpu/events/PM_IC_PREF_CANCEL_ALL
-		/sys/devices/cpu/events/PM_LSU_DC_PREF_STREAM_CONFIRM
-		/sys/devices/cpu/events/PM_MRK_LSU_FLUSH_SRQ
-		/sys/devices/cpu/events/PM_MRK_FIN_STALL_CYC
-		/sys/devices/cpu/events/PM_L2_RCST_DISP_FAIL_OTHER
-		/sys/devices/cpu/events/PM_VSU1_DD_ISSUED
-		/sys/devices/cpu/events/PM_PTEG_FROM_L31_SHR
-		/sys/devices/cpu/events/PM_DATA_FROM_L21_SHR
-		/sys/devices/cpu/events/PM_LSU0_NCLD
-		/sys/devices/cpu/events/PM_VSU1_4FLOP
-		/sys/devices/cpu/events/PM_VSU1_8FLOP
-		/sys/devices/cpu/events/PM_VSU_8FLOP
-		/sys/devices/cpu/events/PM_LSU_LMQ_SRQ_EMPTY_CYC
-		/sys/devices/cpu/events/PM_DTLB_MISS_64K
-		/sys/devices/cpu/events/PM_THRD_CONC_RUN_INST
-		/sys/devices/cpu/events/PM_MRK_PTEG_FROM_L2
-		/sys/devices/cpu/events/PM_PB_SYS_PUMP
-		/sys/devices/cpu/events/PM_VSU_FIN
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_MOD
-		/sys/devices/cpu/events/PM_THRD_PRIO_0_1_CYC
-		/sys/devices/cpu/events/PM_DERAT_MISS_64K
-		/sys/devices/cpu/events/PM_PMC2_REWIND
-		/sys/devices/cpu/events/PM_INST_FROM_L2
-		/sys/devices/cpu/events/PM_GRP_BR_MPRED_NONSPEC
-		/sys/devices/cpu/events/PM_INST_DISP
-		/sys/devices/cpu/events/PM_MEM0_RD_CANCEL_TOTAL
-		/sys/devices/cpu/events/PM_LSU0_DC_PREF_STREAM_CONFIRM
-		/sys/devices/cpu/events/PM_L1_DCACHE_RELOAD_VALID
-		/sys/devices/cpu/events/PM_VSU_SCALAR_DOUBLE_ISSUED
-		/sys/devices/cpu/events/PM_L3_PREF_HIT
-		/sys/devices/cpu/events/PM_MRK_PTEG_FROM_L31_MOD
-		/sys/devices/cpu/events/PM_MRK_FXU_FIN
-		/sys/devices/cpu/events/PM_PMC4_OVERFLOW
-		/sys/devices/cpu/events/PM_MRK_PTEG_FROM_L3
-		/sys/devices/cpu/events/PM_LSU0_LMQ_LHR_MERGE
-		/sys/devices/cpu/events/PM_BTAC_HIT
-		/sys/devices/cpu/events/PM_L3_RD_BUSY
-		/sys/devices/cpu/events/PM_LSU0_L1_SW_PREF
-		/sys/devices/cpu/events/PM_INST_FROM_L2MISS
-		/sys/devices/cpu/events/PM_LSU0_DC_PREF_STREAM_ALLOC
-		/sys/devices/cpu/events/PM_L2_ST
-		/sys/devices/cpu/events/PM_VSU0_DENORM
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_DL2L3_SHR
-		/sys/devices/cpu/events/PM_BR_PRED_CR_TA
-		/sys/devices/cpu/events/PM_VSU0_FCONV
-		/sys/devices/cpu/events/PM_MRK_LSU_FLUSH_ULD
-		/sys/devices/cpu/events/PM_BTAC_MISS
-		/sys/devices/cpu/events/PM_MRK_LD_MISS_EXPOSED_CYC_COUNT
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_L2
-		/sys/devices/cpu/events/PM_LSU_DCACHE_RELOAD_VALID
-		/sys/devices/cpu/events/PM_VSU_FMA
-		/sys/devices/cpu/events/PM_LSU0_FLUSH_SRQ
-		/sys/devices/cpu/events/PM_LSU1_L1_PREF
-		/sys/devices/cpu/events/PM_IOPS_CMPL
-		/sys/devices/cpu/events/PM_L2_SYS_PUMP
-		/sys/devices/cpu/events/PM_L2_RCLD_BUSY_RC_FULL
-		/sys/devices/cpu/events/PM_LSU_LMQ_S0_ALLOC
-		/sys/devices/cpu/events/PM_FLUSH_DISP_SYNC
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_DL2L3_MOD_CYC
-		/sys/devices/cpu/events/PM_L2_IC_INV
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_L21_MOD_CYC
-		/sys/devices/cpu/events/PM_L3_PREF_LDST
-		/sys/devices/cpu/events/PM_LSU_SRQ_EMPTY_CYC
-		/sys/devices/cpu/events/PM_LSU_LMQ_S0_VALID
-		/sys/devices/cpu/events/PM_FLUSH_PARTIAL
-		/sys/devices/cpu/events/PM_VSU1_FMA_DOUBLE
-		/sys/devices/cpu/events/PM_1PLUS_PPC_DISP
-		/sys/devices/cpu/events/PM_DATA_FROM_L2MISS
-		/sys/devices/cpu/events/PM_SUSPENDED
-		/sys/devices/cpu/events/PM_VSU0_FMA
-		/sys/devices/cpu/events/PM_STCX_FAIL
-		/sys/devices/cpu/events/PM_VSU0_FSQRT_FDIV_DOUBLE
-		/sys/devices/cpu/events/PM_DC_PREF_DST
-		/sys/devices/cpu/events/PM_VSU1_SCAL_SINGLE_ISSUED
-		/sys/devices/cpu/events/PM_L3_HIT
-		/sys/devices/cpu/events/PM_L2_GLOB_GUESS_WRONG
-		/sys/devices/cpu/events/PM_MRK_DFU_FIN
-		/sys/devices/cpu/events/PM_INST_FROM_L1
-		/sys/devices/cpu/events/PM_IC_DEMAND_REQ
-		/sys/devices/cpu/events/PM_VSU1_FSQRT_FDIV_DOUBLE
-		/sys/devices/cpu/events/PM_VSU1_FMA
-		/sys/devices/cpu/events/PM_MRK_LD_MISS_L1
-		/sys/devices/cpu/events/PM_VSU0_2FLOP_DOUBLE
-		/sys/devices/cpu/events/PM_LSU_DC_PREF_STRIDED_STREAM_CONFIRM
-		/sys/devices/cpu/events/PM_INST_PTEG_FROM_L31_SHR
-		/sys/devices/cpu/events/PM_MRK_LSU_REJECT_ERAT_MISS
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_L2MISS
-		/sys/devices/cpu/events/PM_DATA_FROM_RL2L3_SHR
-		/sys/devices/cpu/events/PM_INST_FROM_PREF
-		/sys/devices/cpu/events/PM_VSU1_SQ
-		/sys/devices/cpu/events/PM_L2_LD_DISP
-		/sys/devices/cpu/events/PM_L2_DISP_ALL
-		/sys/devices/cpu/events/PM_THRD_GRP_CMPL_BOTH_CYC
-		/sys/devices/cpu/events/PM_VSU_FSQRT_FDIV_DOUBLE
-		/sys/devices/cpu/events/PM_INST_PTEG_FROM_DL2L3_SHR
-		/sys/devices/cpu/events/PM_VSU_1FLOP
-		/sys/devices/cpu/events/PM_HV_CYC
-		/sys/devices/cpu/events/PM_MRK_LSU_FIN
-		/sys/devices/cpu/events/PM_MRK_DATA_FROM_RL2L3_SHR
-		/sys/devices/cpu/events/PM_DTLB_MISS_16M
-		/sys/devices/cpu/events/PM_LSU1_LMQ_LHR_MERGE
-		/sys/devices/cpu/events/PM_IFU_FIN
-		/sys/devices/cpu/events/PM_1THRD_CON_RUN_INSTR
-		/sys/devices/cpu/events/PM_CMPLU_STALL_COUNT
-		/sys/devices/cpu/events/PM_MEM0_PB_RD_CL
-		/sys/devices/cpu/events/PM_THRD_1_RUN_CYC
-		/sys/devices/cpu/events/PM_THRD_2_CONC_RUN_INSTR
-		/sys/devices/cpu/events/PM_THRD_2_RUN_CYC
-		/sys/devices/cpu/events/PM_THRD_3_CONC_RUN_INST
-		/sys/devices/cpu/events/PM_THRD_3_RUN_CYC
-		/sys/devices/cpu/events/PM_THRD_4_CONC_RUN_INST
-		/sys/devices/cpu/events/PM_THRD_4_RUN_CYC
-
-Date:		2013/01/08
-
-Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
-		Linux Powerpc mailing list <linuxppc-dev@ozlabs.org>
-
-Description:	POWER-systems specific performance monitoring events
-
-		A collection of performance monitoring events that may be
-		supported by the POWER CPU. These events can be monitored
-		using the 'perf(1)' tool.
-
-		These events may not be supported by other CPUs.
-
-		The contents of each file would look like:
-
-			event=0xNNNN
-
-		where 'N' is a hex digit and the number '0xNNNN' shows the
-		"raw code" for the perf event identified by the file's
-		"basename".
-
-		Further, multiple terms like 'event=0xNNNN' can be specified
-		and separated with comma. All available terms are defined in
-		the /sys/bus/event_source/devices/<dev>/format file.
-
 What: /sys/bus/event_source/devices/<pmu>/events/<event>
 Date: 2014/02/24
 Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH 5/5] powerpc: Update contact info in Documentation files
From: Sukadev Bhattiprolu @ 2014-10-01  6:03 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo, ak, Jiri Olsa, peterz, eranian,
	Paul Mackerras
  Cc: Michael Ellerman, linux-kernel, dev, linuxppc-dev,
	Anshuman Khandual
In-Reply-To: <1412143402-26061-1-git-send-email-sukadev@linux.vnet.ibm.com>

Cody's email address has changed. Update the contact information for
the 24x7 and GPCI counters to the PowerPC developers mailing list.

Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
 .../ABI/testing/sysfs-bus-event_source-devices-hv_24x7       |  6 +++---
 .../ABI/testing/sysfs-bus-event_source-devices-hv_gpci       | 12 ++++++------
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
index e78ee79..32f3f5f 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
@@ -1,6 +1,6 @@
 What:		/sys/bus/event_source/devices/hv_24x7/interface/catalog
 Date:		February 2014
-Contact:	Cody P Schafer <cody@linux.vnet.ibm.com>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 Description:
 		Provides access to the binary "24x7 catalog" provided by the
 		hypervisor on POWER7 and 8 systems. This catalog lists events
@@ -10,14 +10,14 @@ Description:
 
 What:		/sys/bus/event_source/devices/hv_24x7/interface/catalog_length
 Date:		February 2014
-Contact:	Cody P Schafer <cody@linux.vnet.ibm.com>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 Description:
 		A number equal to the length in bytes of the catalog. This is
 		also extractable from the provided binary "catalog" sysfs entry.
 
 What:		/sys/bus/event_source/devices/hv_24x7/interface/catalog_version
 Date:		February 2014
-Contact:	Cody P Schafer <cody@linux.vnet.ibm.com>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 Description:
 		Exposes the "version" field of the 24x7 catalog. This is also
 		extractable from the provided binary "catalog" sysfs entry.
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
index 3fa58c2..3ca4e55 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
@@ -1,6 +1,6 @@
 What:		/sys/bus/event_source/devices/hv_gpci/interface/collect_privileged
 Date:		February 2014
-Contact:	Cody P Schafer <cody@linux.vnet.ibm.com>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 Description:
 		'0' if the hypervisor is configured to forbid access to event
 		counters being accumulated by other guests and to physical
@@ -9,35 +9,35 @@ Description:
 
 What:		/sys/bus/event_source/devices/hv_gpci/interface/ga
 Date:		February 2014
-Contact:	Cody P Schafer <cody@linux.vnet.ibm.com>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 Description:
 		0 or 1. Indicates whether we have access to "GA" events (listed
 		in arch/powerpc/perf/hv-gpci.h).
 
 What:		/sys/bus/event_source/devices/hv_gpci/interface/expanded
 Date:		February 2014
-Contact:	Cody P Schafer <cody@linux.vnet.ibm.com>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 Description:
 		0 or 1. Indicates whether we have access to "EXPANDED" events (listed
 		in arch/powerpc/perf/hv-gpci.h).
 
 What:		/sys/bus/event_source/devices/hv_gpci/interface/lab
 Date:		February 2014
-Contact:	Cody P Schafer <cody@linux.vnet.ibm.com>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 Description:
 		0 or 1. Indicates whether we have access to "LAB" events (listed
 		in arch/powerpc/perf/hv-gpci.h).
 
 What:		/sys/bus/event_source/devices/hv_gpci/interface/version
 Date:		February 2014
-Contact:	Cody P Schafer <cody@linux.vnet.ibm.com>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 Description:
 		A number indicating the version of the gpci interface that the
 		hypervisor reports supporting.
 
 What:		/sys/bus/event_source/devices/hv_gpci/interface/kernel_version
 Date:		February 2014
-Contact:	Cody P Schafer <cody@linux.vnet.ibm.com>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 Description:
 		A number indicating the latest version of the gpci interface
 		that the kernel is aware of.
-- 
1.8.3.1

^ permalink raw reply related

* Re: [PATCH v2 02/17] powerpc/cell: Move data segment faulting code out of cell platform
From: Michael Ellerman @ 2014-10-01  6:47 UTC (permalink / raw)
  To: Michael Neuling, greg, arnd, mpe, benh
  Cc: cbe-oss-dev, mikey, Aneesh Kumar K.V, imunsie, linux-kernel,
	linuxppc-dev, jk, anton
In-Reply-To: <1412073306-13812-3-git-send-email-mikey@neuling.org>

On Tue, 2014-30-09 at 10:34:51 UTC, Michael Neuling wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
> 
> __spu_trap_data_seg() currently contains code to determine the VSID and ESID
> required for a particular EA and mm struct.
> 
> This code is generically useful for other co-processors.  This moves the code
> of the cell platform so it can be used by other powerpc code.  It also adds 1TB
> segment handling which Cell didn't have.

I'm not loving this.

For starters the name "copro_data_segment()" doesn't contain any verbs, and it
doesn't tell me what it does.

If we give it a name that says what it does, we get copro_get_ea_esid_and_vsid().
Or something equally ugly.

And then in patch 10 you move the bulk of the logic into calculate_vsid().

So instead can we:
 - add a small helper that does the esid calculation, eg. calculate_esid() ?
 - factor out the vsid logic into a helper, calculate_vsid() ?
 - rework the spu code to use those, dropping __spu_trap_data_seg()
 - use the helpers in the cxl code


cheers

^ permalink raw reply

page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox