Re: BUG: perf error on syscalls for powerpc64.
On 2015年07月17日 09:51, Sukadev Bhattiprolu wrote: Zumeng Chen [zumeng.c...@gmail.com] wrote: | 3. What I have seen in 3.14.x kernel, | == | And so far, no more difference to 4.x kernel from me about this part if | I'm right. | | *) With 1028ccf5 | | perf list|grep -i syscall got me nothing. | | | *) Without 1028ccf5 | root@localhost:~# perf list|grep -i syscall |syscalls:sys_enter_socket [Tracepoint event] |syscalls:sys_exit_socket [Tracepoint event] |syscalls:sys_enter_socketpair [Tracepoint event] |syscalls:sys_exit_socketpair [Tracepoint event] |syscalls:sys_enter_bind[Tracepoint event] |syscalls:sys_exit_bind [Tracepoint event] |syscalls:sys_enter_listen [Tracepoint event] |syscalls:sys_exit_listen [Tracepoint event] |... ... Are you seeing this on big-endian or little-endian system? Big one. IIRC, I saw the opposite behavior on an LE system a few months ago. i.e. without 1028ccf5, 'perf listf|grep syscall' failed. I wonder if this has anything to do with the bug. Cheers, Zumeng Applying 1028ccf5, seemed to fix it. Sukadev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RESEND,v3] powerpc/pseries: Limit EPOW reset event warnings
* Michael Ellerman [2015-07-16 14:05:52]:
[..]
>
> Why are we even getting these reset events when nothing has happened?
Thanks for the review. It was seen only on one machine, couldn't
get hold of the machine any more. I am guessing here, that it might be
the firmware.
>
> > Also, merged adjacent pr_err/pr_emerg into single one to reduce
> > the number of lines printed per warning.
[..]
> >
> > +/* Flag to limit EPOW RESET warning. */
> > +static bool epow_state;
>
> This name is terrible, it doesn't give me any hint to what it means.
>
> But really it should be a counter, not a boolean.
>
> We could have multiple EPOW events come in and then later get the reset events
> for them, couldn't we?
>
>
> So what about:
>
> static unsigned epow_event_depth;
>
--->8
From 0d27916fd09a9f0912a217432a41e2b579dc2952 Mon Sep 17 00:00:00 2001
From: Kamalesh Babulal
Date: Fri, 17 Jul 2015 13:19:31 +0530
Subject: [PATCH v4] powerpc/pseries: Limit EPOW reset event warnings
Kernel prints respective warnings about various EPOW events for
user information/action after parsing EPOW interrupts. At times
EPOW reset event warning, such as below could flood kernel log,
over a period of time.
May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared
May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared
May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared
May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared
May 25 04:04:24 alp kernel: Non critical power or cooling issue cleared
May 25 04:07:18 alp kernel: Non critical power or cooling issue cleared
May 25 04:13:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:26 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:36 alp kernel: Non critical power or cooling issue cleared
This patch avoids these multiple EPOW reset warnings by using epow_depth
counter. Which is incremented every time EPOW event is reported and
decremented on EPOW_RESET event. With this approach number EPOW RESET
warning matches the number of EPOW events.
Also, merged adjacent pr_info/pr_err/pr_emerg into single one to reduce
the number of lines printed per warning across the file and converted
non-critical errors to pr_info from pr_error, including grammar
correction in the warnings printed.
Suggested-by: Michael Ellerman
Cc: Anshuman Khandual
Cc: Anton Blanchard
Cc: Vipin K Parashar
Signed-off-by: Kamalesh Babulal
---
V4: Changes:
- Changed the approach to depth counter to match the EPOW events and
EPOW reset.
- Converted pr_err() ot pr_info() for non-critical errors.
- Merged adjacent warnings into single line across the file.
- Fixed grammar in the warnings to make is short.
v3 Changes:
- Limit warning printed by EPOW RESET event, by guarding it with bool flag.
Instead of rate limiting all the EPOW events.
v2 Changes:
- Merged multiple adjacent pr_err/pr_emerg into single line to reduce
multi-line
warnings, based on Michael's comments.
arch/powerpc/platforms/pseries/ras.c | 53
1 file changed, 29 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/ras.c
b/arch/powerpc/platforms/pseries/ras.c
index 02e4a17..995cab8 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -40,6 +40,8 @@ static int ras_check_exception_token;
#define EPOW_SENSOR_TOKEN 9
#define EPOW_SENSOR_INDEX 0
+static unsigned epow_event_depth;
+
static irqreturn_t ras_epow_interrupt(int irq, void *dev_id);
static irqreturn_t ras_error_interrupt(int irq, void *dev_id);
@@ -82,32 +84,30 @@ static void handle_system_shutdown(char event_modifier)
{
switch (event_modifier) {
case EPOW_SHUTDOWN_NORMAL:
- pr_emerg("Firmware initiated power off");
+ pr_emerg("Firmware initiated power off\n");
orderly_poweroff(true);
break;
case EPOW_SHUTDOWN_ON_UPS:
- pr_emerg("Loss of power reported by firmware, system is "
- "running on UPS/battery");
- pr_emerg("Check RTAS error log for details");
+ pr_emerg("Loss of power reported, system is running on"
+" UPS/battery. Check RTAS error log for details\n");
orderly_poweroff(true);
break;
case EPOW_SHUTDOWN_LOSS_OF_CRITICAL_FUNCTIONS:
- pr_emerg("Loss of system critical functions reported by "
- "firmware");
- pr_emerg("Check RTAS error log for details");
+ pr_emerg("
Re: [PATCH 6/6] cputime: Introduce cputime_to_timespec64()/timespec64_to_cputime()
On 16 July 2015 at 18:43, Thomas Gleixner wrote: > On Thu, 16 Jul 2015, Baolin Wang wrote: >> On 15 July 2015 at 19:55, Thomas Gleixner wrote: >> > On Wed, 15 Jul 2015, Baolin Wang wrote: >> > >> >> On 15 July 2015 at 18:31, Thomas Gleixner wrote: >> >> > On Wed, 15 Jul 2015, Baolin Wang wrote: >> >> > >> >> >> The cputime_to_timespec() and timespec_to_cputime() functions are >> >> >> not year 2038 safe on 32bit systems due to that the struct timepsec >> >> >> will overflow in 2038 year. >> >> > >> >> > And how is this relevant? cputime is not based on wall clock time at >> >> > all. So what has 2038 to do with cputime? >> >> > >> >> > We want proper explanations WHY we need such a change. >> >> >> >> When converting the posix-cpu-timers, it call the >> >> cputime_to_timespec() function. Thus it need a conversion for this >> >> function. >> > >> > There is no requirement to convert posix-cpu-timers on their own. We >> > need to adopt the posix cpu timers code because it shares syscalls >> > with the other posix timers, but that still does not explain why we >> > need these functions. >> > >> >> In posix-cpu-timers, it also defined some 'k_clock struct' variables, >> and we need to convert the callbacks of the 'k_clock struct' which are >> not year 2038 safe on 32bit systems. Some callbacks which need to >> convert call the cputime_to_timespec() function, thus we also want to >> convert the cputime_to_timespec() function to a year 2038 safe >> function to make all them ready for the year 2038 issue. > > You are not getting it at all. > > 1) We need to change k_clock callbacks due to 2038 issues > > 2) posix cpu timers implement affected callbacks > > 3) posix cpu timers themself and cputime are NOT affected by 2038 > > So we have 2 options to change the code in posix cpu timers: > >A) Do the timespec/timespec64 conversion in the posix cpu timer > callbacks and leave the cputime functions untouched. > >B) Implement cputime/timespec64 functions to avoid #A > >If you go for #B, you need to provide a reasonable explanation why >it is better than #A. And that explanation has absolutely nothing >to do with 2038 safety. Very thanks for your explanation, and I'll think about that. > > Not everything is a 2038 issue, just because the only tool you have is > a timespec64. > > Thanks, > > tglx > > > -- Baolin.wang Best Regards ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Use hardware RNG for arch_get_random_seed_* not arch_get_random_*
The hardware RNG on POWER8 and POWER7+ can be relatively slow, since
it can only supply one 64-bit value per microsecond. Currently we
read it in arch_get_random_long(), but that slows down reading from
/dev/urandom since the code in random.c calls arch_get_random_long()
for every longword read from /dev/urandom.
Since the hardware RNG supplies high-quality entropy on every read, it
matches the semantics of arch_get_random_seed_long() better than those
of arch_get_random_long(). Therefore this commit makes the code use
the POWER8/7+ hardware RNG only for arch_get_random_seed_{long,int}
and not for arch_get_random_{long,int}.
This won't affect any other PowerPC-based platforms because none of
them currently support a hardware RNG.
Signed-off-by: Paul Mackerras
---
arch/powerpc/include/asm/archrandom.h | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/archrandom.h
b/arch/powerpc/include/asm/archrandom.h
index 0cc6eed..a4c3f54 100644
--- a/arch/powerpc/include/asm/archrandom.h
+++ b/arch/powerpc/include/asm/archrandom.h
@@ -7,13 +7,22 @@
static inline int arch_get_random_long(unsigned long *v)
{
+ return 0;
+}
+
+static inline int arch_get_random_int(unsigned int *v)
+{
+ return 0;
+}
+
+static inline int arch_get_random_seed_long(unsigned long *v)
+{
if (ppc_md.get_random_long)
return ppc_md.get_random_long(v);
return 0;
}
-
-static inline int arch_get_random_int(unsigned int *v)
+static inline int arch_get_random_seed_int(unsigned int *v)
{
unsigned long val;
int rc;
@@ -27,22 +36,13 @@ static inline int arch_get_random_int(unsigned int *v)
static inline int arch_has_random(void)
{
- return !!ppc_md.get_random_long;
-}
-
-static inline int arch_get_random_seed_long(unsigned long *v)
-{
- return 0;
-}
-static inline int arch_get_random_seed_int(unsigned int *v)
-{
return 0;
}
+
static inline int arch_has_random_seed(void)
{
- return 0;
+ return !!ppc_md.get_random_long;
}
-
#endif /* CONFIG_ARCH_RANDOM */
#ifdef CONFIG_PPC_POWERNV
--
2.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Use hardware RNG for arch_get_random_seed_* not arch_get_random_*
On Fri, Jul 17, 2015 at 07:15:58PM +1000, Paul Mackerras wrote:
> @@ -7,13 +7,22 @@
>
> static inline int arch_get_random_long(unsigned long *v)
> {
> + return 0;
> +}
> +
> +static inline int arch_get_random_int(unsigned int *v)
> +{
> + return 0;
> +}
> +
> +static inline int arch_get_random_seed_long(unsigned long *v)
> +{
> if (ppc_md.get_random_long)
> return ppc_md.get_random_long(v);
You probably want to change that last name (ppc_md.get_random_long) then?
Pretty confusing like this :-)
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RESEND,v3] powerpc/pseries: Limit EPOW reset event warnings
On 07/16/2015 09:35 AM, Michael Ellerman wrote:
On Wed, 2015-15-07 at 04:22:06 UTC, Kamalesh Babulal wrote:
Kernel prints respective warnings about various EPOW events for
user information/action after parsing EPOW interrupts.Prompting
user to take action depending upon the severity of the event.
At times EPOW reset event warning, such as below could flood
kernel log, over a period of time.
May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared
May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared
May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared
May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared
May 25 04:04:24 alp kernel: Non critical power or cooling issue cleared
May 25 04:07:18 alp kernel: Non critical power or cooling issue cleared
May 25 04:13:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:26 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:36 alp kernel: Non critical power or cooling issue cleared
This patch avoids these multiple EPOW reset warnings by using a boolean
flag. This flag is initialized to false and is set to true upon arrival
of EPOW event. This same flag is checked and reset during EPOW_RESET
scenario to filter out valid EPOW reset events and avoid multiple warning
logs.
Why are we even getting these reset events when nothing has happened?
Also, merged adjacent pr_err/pr_emerg into single one to reduce
the number of lines printed per warning.
Suggested-by: Vipin K Parashar
[Vipin: edited the changelog]
Cc: Anshuman Khandual
Cc: Anton Blanchard
Cc: Michael Ellerman
Signed-off-by: Kamalesh Babulal
---
v3 Changes:
- Limit warning printed by EPOW RESET event, by guarding it with bool flag.
Instead of rate limiting all the EPOW events.
v2 Changes:
- Merged multiple adjacent pr_err/pr_emerg into single line to reduce
multi-line
warnings, based on Michael's comments.
arch/powerpc/platforms/pseries/ras.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/ras.c
b/arch/powerpc/platforms/pseries/ras.c
index 02e4a17..b30396a 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -40,6 +40,9 @@ static int ras_check_exception_token;
#define EPOW_SENSOR_TOKEN 9
#define EPOW_SENSOR_INDEX 0
+/* Flag to limit EPOW RESET warning. */
+static bool epow_state;
This name is terrible, it doesn't give me any hint to what it means.
But really it should be a counter, not a boolean.
We could have multiple EPOW events come in and then later get the reset events
for them, couldn't we?
As per PAPR i see below description of EPOW_RESET
EPOW_RESET / MESSAGE (0) - No EPOW event is pending.
So we probably need to understand if it is send only after all EPOW
events have
reset or just last EPOW event. From the PAPR description is seems to be
first case.
So what about:
static unsigned epow_event_depth;
And then below:
@@ -145,21 +148,27 @@ static void rtas_parse_epow_errlog(struct rtas_error_log
*log)
epow_event_depth++;
switch (action_code) {
case EPOW_RESET:
if (epow_event_depth)
epow_event_depth--;
if (epow_event_depth)
+ pr_err("Non critical power or cooling issue cleared");
break;
And that's all you need.
case EPOW_WARN_COOLING:
- pr_err("Non critical cooling issue reported by firmware");
- pr_err("Check RTAS error log for details");
+ pr_err("Non critical cooling issue reported by firmware, "
+ "Check RTAS error log for details");
This should be:
pr_err("Non-critical cooling issue reported by firmware, check RTAS
error log for details.\n");
But that's too long, so how about:
pr_err("Non-critical cooling issue reported, check RTAS error log
for details.\n");
And if it's non-critical it shouldn't be pr_err(), it should be pr_info().
Similarly for all the other messages.
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 2/2] powerpc/kexec: Reset HILE before entering target kernel
On Fri, Jul 17, 2015 at 11:53:38AM +1000, Benjamin Herrenschmidt wrote: > On Fri, 2015-07-10 at 15:19 +1000, Samuel Mendoza-Jonas wrote: > > +#if defined(CONFIG_PPC_BOOK3S_64) && defined(CONFIG_PPC_POWERNV) > > + li r3,(FW_FEATURE_OPAL >> 16) > > + rldicr r3,r3,16,63 > > + and.r3,r3,r26 > > + cmpwi r3,0 > > + beq 99f > > If FW_FEATRURE_OPAL is 0x8000 then the li will sign extend. > > The rldicr has a mask of all F's so it will keep all the bits you > don't care about. > > So together, you'll get compares happening on bits above the 16 you care > about that might change the result of your comparison incorrectly. > > Since FW_FEATURE_* bits aren't ABI, they can change, so we don't want > to impose a constraint on them. > > Thus I would recommend using an rdlicl r3,r3,16,48 (aka srdi r3,r3,48) > instead which is going to clear all bits above 0x. Or the other way around: instead of loading and masking, load zero and OR the bits in: + li r3,0 + ori r3,(FW_FEATURE_OPAL >> 16) + rldicr r3,r3,16,63 + and.r3,r3,r26 + cmpwi r3,0 + beq 99f which of course is better written as + li r3,0 + orisr3,(FW_FEATURE_OPAL >> 16) + and.r3,r3,r26 + cmpwi r3,0 + beq 99f which is + andis. r3,r26,(FW_FEATURE_OPAL >> 16) + cmpwi r3,0 + beq 99f which is + andis. r3,r26,(FW_FEATURE_OPAL >> 16) + beq 99f > Now, that being said, FW_FEATURE_* can be 64-bit All of the code above only works for single-bit constants inside 0x though (or 0x7fff for the original). > and this isn't perf > critical so why not just load the full 64-bit constant into r3 and > be done with it ? There's a macro to do that: > > LOAD_REG_IMMEDIATE(r3,FW_FEATURE_OPAL) And as you say later, use C. Yeah. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Use hardware RNG for arch_get_random_seed_* not arch_get_random_*
On Fri, Jul 17, 2015 at 04:37:57AM -0500, Segher Boessenkool wrote:
> On Fri, Jul 17, 2015 at 07:15:58PM +1000, Paul Mackerras wrote:
> > @@ -7,13 +7,22 @@
> >
> > static inline int arch_get_random_long(unsigned long *v)
> > {
> > + return 0;
> > +}
> > +
> > +static inline int arch_get_random_int(unsigned int *v)
> > +{
> > + return 0;
> > +}
> > +
> > +static inline int arch_get_random_seed_long(unsigned long *v)
> > +{
> > if (ppc_md.get_random_long)
> > return ppc_md.get_random_long(v);
>
> You probably want to change that last name (ppc_md.get_random_long) then?
> Pretty confusing like this :-)
Fair point. New patch coming.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc: Use hardware RNG for arch_get_random_seed_* not arch_get_random_*
The hardware RNG on POWER8 and POWER7+ can be relatively slow, since
it can only supply one 64-bit value per microsecond. Currently we
read it in arch_get_random_long(), but that slows down reading from
/dev/urandom since the code in random.c calls arch_get_random_long()
for every longword read from /dev/urandom.
Since the hardware RNG supplies high-quality entropy on every read, it
matches the semantics of arch_get_random_seed_long() better than those
of arch_get_random_long(). Therefore this commit makes the code use
the POWER8/7+ hardware RNG only for arch_get_random_seed_{long,int}
and not for arch_get_random_{long,int}.
This won't affect any other PowerPC-based platforms because none of
them currently support a hardware RNG. To make it clear that the
ppc_md function pointer is used for arch_get_random_seed_*, we rename
it from get_random_long to get_random_seed.
Signed-off-by: Paul Mackerras
---
v2: Rename the ppc_md hook too.
arch/powerpc/include/asm/archrandom.h | 28 ++--
arch/powerpc/include/asm/machdep.h| 2 +-
arch/powerpc/platforms/powernv/rng.c | 2 +-
arch/powerpc/platforms/pseries/rng.c | 2 +-
4 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/include/asm/archrandom.h
b/arch/powerpc/include/asm/archrandom.h
index 0cc6eed..85e88f7 100644
--- a/arch/powerpc/include/asm/archrandom.h
+++ b/arch/powerpc/include/asm/archrandom.h
@@ -7,14 +7,23 @@
static inline int arch_get_random_long(unsigned long *v)
{
- if (ppc_md.get_random_long)
- return ppc_md.get_random_long(v);
-
return 0;
}
static inline int arch_get_random_int(unsigned int *v)
{
+ return 0;
+}
+
+static inline int arch_get_random_seed_long(unsigned long *v)
+{
+ if (ppc_md.get_random_seed)
+ return ppc_md.get_random_seed(v);
+
+ return 0;
+}
+static inline int arch_get_random_seed_int(unsigned int *v)
+{
unsigned long val;
int rc;
@@ -27,22 +36,13 @@ static inline int arch_get_random_int(unsigned int *v)
static inline int arch_has_random(void)
{
- return !!ppc_md.get_random_long;
-}
-
-static inline int arch_get_random_seed_long(unsigned long *v)
-{
- return 0;
-}
-static inline int arch_get_random_seed_int(unsigned int *v)
-{
return 0;
}
+
static inline int arch_has_random_seed(void)
{
- return 0;
+ return !!ppc_md.get_random_seed;
}
-
#endif /* CONFIG_ARCH_RANDOM */
#ifdef CONFIG_PPC_POWERNV
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index 952579f..cab6753 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -249,7 +249,7 @@ struct machdep_calls {
#endif
#ifdef CONFIG_ARCH_RANDOM
- int (*get_random_long)(unsigned long *v);
+ int (*get_random_seed)(unsigned long *v);
#endif
};
diff --git a/arch/powerpc/platforms/powernv/rng.c
b/arch/powerpc/platforms/powernv/rng.c
index 6eb808f..5dcbdea 100644
--- a/arch/powerpc/platforms/powernv/rng.c
+++ b/arch/powerpc/platforms/powernv/rng.c
@@ -128,7 +128,7 @@ static __init int rng_create(struct device_node *dn)
pr_info_once("Registering arch random hook.\n");
- ppc_md.get_random_long = powernv_get_random_long;
+ ppc_md.get_random_seed = powernv_get_random_long;
return 0;
}
diff --git a/arch/powerpc/platforms/pseries/rng.c
b/arch/powerpc/platforms/pseries/rng.c
index e096087..31ca557 100644
--- a/arch/powerpc/platforms/pseries/rng.c
+++ b/arch/powerpc/platforms/pseries/rng.c
@@ -38,7 +38,7 @@ static __init int rng_init(void)
pr_info("Registering arch random hook.\n");
- ppc_md.get_random_long = pseries_get_random_long;
+ ppc_md.get_random_seed = pseries_get_random_long;
return 0;
}
--
2.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v6 0/3] LED driver for PowerNV platform
The following series implements LED driver for PowerNV platform.
PowerNV platform has below type of LEDs:
- System attention
Indicates there is a problem with the system that needs attention.
- Identify
Helps the user locate/identify a particular FRU or resource in the
system.
- Fault
Indicates there is a problem with the FRU or resource at the
location with which the indicator is associated.
On PowerNV (Non Virtualized) platform OPAL firmware provides LED information
to host via device tree (location code and LED type). During init we check
for 'ibm,opal/leds' node in device tree to enable LED driver. And we use
OPAL API's to get/set LEDs.
Note that on PowerNV platform firmware can activate fault LED, if it can isolate
the problem. Also one can modify the LEDs using service processor interface.
None
of these involes kernel. Hence we retain LED state in unload path.
Sample LED device tree output:
--
leds {
compatible = "ibm,opal-v3-led";
led-mode = "lightpath";
U78C9.001.RST0027-P1-C1 {
led-types = "identify", "fault";
};
...
...
}
Sample sysfs output:
.
├── U78CB.001.WZS008R-A1:fault
│ ├── brightness
│ ├── device -> ../../../opal_leds
│ ├── max_brightness
│ ├── power
│ │ ├── async
│ │ ├── autosuspend_delay_ms
│ │ ├── control
│ │ ├── runtime_active_kids
│ │ ├── runtime_active_time
│ │ ├── runtime_enabled
│ │ ├── runtime_status
│ │ ├── runtime_suspended_time
│ │ └── runtime_usage
│ ├── subsystem -> ../../../../../class/leds
│ ├── trigger
│ └── uevent
├── U78CB.001.WZS008R-A1:identify
│ ├── brightness
│ ├── device -> ../../../opal_leds
│ ├── max_brightness
│ ├── power
│ │ ├── async
│ │ ├── autosuspend_delay_ms
│ │ ├── control
│ │ ├── runtime_active_kids
│ │ ├── runtime_active_time
│ │ ├── runtime_enabled
│ │ ├── runtime_status
│ │ ├── runtime_suspended_time
│ │ └── runtime_usage
│ ├── subsystem -> ../../../../../class/leds
│ ├── trigger
│ └── uevent
patch 1/2: PowerNV architecture specific code. This adds necessary
OPAL APIs.
patch 2/2: Create LED platform device and export OPAL symbols
patch 3/3: Actual LED driver implemenation for PowerNV platform.
Note that this version of patchset is based on top of v4.2-rc2.
@Jacek,
Let me know if you want me to rebase this patchset on top of LED tree.
Previous patchset:
v5: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-July/130602.html
v4: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-April/128028.html
v3: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-April/127702.html
v2: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-March/126301.html
v1: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-March/125705.html
Changes in v6:
- Added loc_code and type to powernv_led_data structure instead of parsing
them from led classdev name.
- Fixed documentation issues.
- Fixed mutex_destry issue
- Replaced led_classdev_register with devm_led_classdev_register
Changes in v5:
- Rebased on top of Linus tree
- Renamed led as leds and updated documentation
- As Ben and Arnd suggested, removed phandle from documenation
- As Ben suggested removed led-loc device tree property
- As Jacek suggested, added back compatible property to documentation
Changes in v4:
- Updated macros to reflect platform.
- s/u64/__be64/g for big endian data we get from firmware
- Addressed review comments from Jacek. Major once are:
Removed list in powernv_led_data structure
s/kzalloc/devm_kzalloc/
Removed compatible property from documentation
s/powernv_led_set_queue/powernv_brightness_set/
- Removed LED specific brightness_set/get function. Instead this version
uses single function to queue all LED set/get requests. Later we use
LED name to detect LED type and value.
- Removed hardcoded LED type used in previous version. Instead we use
led-types property to form LED classdev.
Changes in v3:
- Addressed review comments from Jacek. Major once are:
Replaced spin lock and mutex and removed redundant structures
Replaced pr_* with dev_*
Moved OPAL platform sepcific part to separate patch
Moved repteated code to common function
Added device tree documentation for LEDs
Changes in v2:
- Rebased patches on top of mpe's next branch
https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/log/?h=next
- Added System Attention Indicator support
- Removed redundant code in leds-powernv.c file
Anshuman Khandual (1):
powerpc/powernv: Add OPAL interfaces for accessing and modifying
system LED states
Vasant Hegde (2):
powerpc/powernv: Create LED platform device
leds/powernv: Add driver for PowerNV platform
.../devicetree/bindings/leds/leds-powernv.txt | 26 ++
arch/powerpc/include/asm/opal-
[PATCH v6 1/3] powerpc/powernv: Add OPAL interfaces for accessing and modifying system LED states
From: Anshuman Khandual
This patch registers the following two new OPAL interfaces calls
for the platform LED subsystem. With the help of these new OPAL calls,
the kernel will be able to get or set the state of various individual
LEDs on the system at any given location code which is passed through
the LED specific device tree nodes.
(1) OPAL_LEDS_GET_INDICATOR opal_leds_get_ind
(2) OPAL_LEDS_SET_INDICATOR opal_leds_set_ind
Signed-off-by: Anshuman Khandual
Signed-off-by: Vasant Hegde
Acked-by: Stewart Smith
Tested-by: Stewart Smith
Acked-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/opal-api.h| 25 -
arch/powerpc/include/asm/opal.h| 4
arch/powerpc/platforms/powernv/opal-wrappers.S | 2 ++
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index e9e4c52..8f8c45f 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -154,7 +154,9 @@
#define OPAL_FLASH_WRITE 111
#define OPAL_FLASH_ERASE 112
#define OPAL_PRD_MSG 113
-#define OPAL_LAST 113
+#define OPAL_LEDS_GET_INDICATOR114
+#define OPAL_LEDS_SET_INDICATOR115
+#define OPAL_LAST 115
/* Device tree flags */
@@ -756,6 +758,27 @@ struct opal_i2c_request {
__be64 buffer_ra; /* Buffer real address */
};
+/* LED Mode */
+#define POWERNV_LED_MODE_LIGHT_PATH"lightpath"
+#define POWERNV_LED_MODE_GUIDING_LIGHT "guidinglight"
+
+/* LED type */
+#define POWERNV_LED_TYPE_IDENTIFY "identify"
+#define POWERNV_LED_TYPE_FAULT "fault"
+#define POWERNV_LED_TYPE_ATTENTION "attention"
+
+enum OpalSlotLedType {
+ OPAL_SLOT_LED_TYPE_ID = 0, /* IDENTIFY LED */
+ OPAL_SLOT_LED_TYPE_FAULT = 1, /* FAULT LED */
+ OPAL_SLOT_LED_TYPE_ATTN = 2,/* System Attention LED */
+ OPAL_SLOT_LED_TYPE_MAX = 3
+};
+
+enum OpalSlotLedState {
+ OPAL_SLOT_LED_STATE_OFF = 0,/* LED is OFF */
+ OPAL_SLOT_LED_STATE_ON = 1 /* LED is ON */
+};
+
#endif /* __ASSEMBLY__ */
#endif /* __OPAL_API_H */
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 958e941..3233e6d 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -195,6 +195,10 @@ int64_t opal_ipmi_recv(uint64_t interface, struct
opal_ipmi_msg *msg,
int64_t opal_i2c_request(uint64_t async_token, uint32_t bus_id,
struct opal_i2c_request *oreq);
int64_t opal_prd_msg(struct opal_prd_msg *msg);
+int64_t opal_leds_get_ind(char *loc_code, __be64 *led_mask,
+ __be64 *led_value, __be64 *max_led_type);
+int64_t opal_leds_set_ind(uint64_t token, char *loc_code, const u64 led_mask,
+ const u64 led_value, __be64 *max_led_type);
int64_t opal_flash_read(uint64_t id, uint64_t offset, uint64_t buf,
uint64_t size, uint64_t token);
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index d6a7b82..34c2734 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -297,3 +297,5 @@ OPAL_CALL(opal_flash_read,
OPAL_FLASH_READ);
OPAL_CALL(opal_flash_write,OPAL_FLASH_WRITE);
OPAL_CALL(opal_flash_erase,OPAL_FLASH_ERASE);
OPAL_CALL(opal_prd_msg,OPAL_PRD_MSG);
+OPAL_CALL(opal_leds_get_ind, OPAL_LEDS_GET_INDICATOR);
+OPAL_CALL(opal_leds_set_ind, OPAL_LEDS_SET_INDICATOR);
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v6 3/3] leds/powernv: Add driver for PowerNV platform
This patch implements LED driver for PowerNV platform using the existing
generic LED class framework.
PowerNV platform has below type of LEDs:
- System attention
Indicates there is a problem with the system that needs attention.
- Identify
Helps the user locate/identify a particular FRU or resource in the
system.
- Fault
Indicates there is a problem with the FRU or resource at the
location with which the indicator is associated.
We register classdev structures for all individual LEDs detected on the
system through LED specific device tree nodes. Device tree nodes specify
what all kind of LEDs present on the same location code. It registers
LED classdev structure for each of them.
All the system LEDs can be found in the same regular path /sys/class/leds/.
We don't use LED colors. We use LED node and led-types property to form
LED classdev. Our LEDs have names in this format.
:
Any positive brightness value would turn on the LED and a zero value would
turn off the LED. The driver will return LED_FULL (255) for any turned on
LED and LED_OFF (0) for any turned off LED.
As per the LED class framework, the 'brightness_set' function should not
sleep. Hence these functions have been implemented through global work
queue tasks which might sleep on OPAL async call completion.
The platform level implementation of LED get and set state has been achieved
through OPAL calls. These calls are made available for the driver by
exporting from architecture specific codes.
Signed-off-by: Vasant Hegde
Signed-off-by: Anshuman Khandual
Acked-by: Stewart Smith
Tested-by: Stewart Smith
---
.../devicetree/bindings/leds/leds-powernv.txt | 26 ++
drivers/leds/Kconfig | 11 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-powernv.c| 422 +
4 files changed, 460 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-powernv.txt
create mode 100644 drivers/leds/leds-powernv.c
diff --git a/Documentation/devicetree/bindings/leds/leds-powernv.txt
b/Documentation/devicetree/bindings/leds/leds-powernv.txt
new file mode 100644
index 000..6665569
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-powernv.txt
@@ -0,0 +1,26 @@
+Device Tree binding for LEDs on IBM Power Systems
+-
+
+Required properties:
+- compatible : Should be "ibm,opal-v3-led".
+- led-mode : Should be "lightpath" or "guidinglight".
+
+Each location code of FRU/Enclosure must be expressed in the
+form of a sub-node.
+
+Required properties for the sub nodes:
+- led-types : Supported LED types (attention/identify/fault) provided
+ in the form of string array.
+
+Example:
+
+leds {
+ compatible = "ibm,opal-v3-led";
+ led-mode = "lightpath";
+
+ U78C9.001.RST0027-P1-C1 {
+ led-types = "identify", "fault";
+ };
+ ...
+ ...
+};
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 9ad35f7..f218cc3a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -560,6 +560,17 @@ config LEDS_BLINKM
This option enables support for the BlinkM RGB LED connected
through I2C. Say Y to enable support for the BlinkM LED.
+config LEDS_POWERNV
+ tristate "LED support for PowerNV Platform"
+ depends on LEDS_CLASS
+ depends on PPC_POWERNV
+ depends on OF
+ help
+ This option enables support for the system LEDs present on
+ PowerNV platforms. Say 'y' to enable this support in kernel.
+ To compile this driver as a module, choose 'm' here: the module
+ will be called leds-powernv.
+
config LEDS_SYSCON
bool "LED support for LEDs on system controllers"
depends on LEDS_CLASS=y
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 8d6a24a..6a943d1 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
obj-$(CONFIG_LEDS_PM8941_WLED) += leds-pm8941-wled.o
obj-$(CONFIG_LEDS_KTD2692) += leds-ktd2692.o
+obj-$(CONFIG_LEDS_POWERNV) += leds-powernv.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-powernv.c b/drivers/leds/leds-powernv.c
new file mode 100644
index 000..c3c0b0c
--- /dev/null
+++ b/drivers/leds/leds-powernv.c
@@ -0,0 +1,422 @@
+/*
+ * PowerNV LED Driver
+ *
+ * Copyright IBM Corp. 2015
+ *
+ * Author: Vasant Hegde
+ * Author: Anshuman Khandual
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include
[PATCH v6 2/3] powerpc/powernv: Create LED platform device
This patch adds platform devices for leds. Also export LED related
OPAL API's so that led driver can use these APIs.
Signed-off-by: Vasant Hegde
Acked-by: Benjamin Herrenschmidt
---
arch/powerpc/platforms/powernv/opal.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index f084afa..6839358 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -648,7 +648,7 @@ static void opal_init_heartbeat(void)
static int __init opal_init(void)
{
- struct device_node *np, *consoles;
+ struct device_node *np, *consoles, *leds;
int rc;
opal_node = of_find_node_by_path("/ibm,opal");
@@ -689,6 +689,13 @@ static int __init opal_init(void)
/* Setup a heatbeat thread if requested by OPAL */
opal_init_heartbeat();
+ /* Create leds platform devices */
+ leds = of_find_node_by_path("/ibm,opal/leds");
+ if (leds) {
+ of_platform_device_create(leds, "opal_leds", NULL);
+ of_node_put(leds);
+ }
+
/* Create "opal" kobject under /sys/firmware */
rc = opal_sysfs_init();
if (rc == 0) {
@@ -841,3 +848,6 @@ EXPORT_SYMBOL_GPL(opal_rtc_write);
EXPORT_SYMBOL_GPL(opal_tpo_read);
EXPORT_SYMBOL_GPL(opal_tpo_write);
EXPORT_SYMBOL_GPL(opal_i2c_request);
+/* Export these symbols for PowerNV LED class driver */
+EXPORT_SYMBOL_GPL(opal_leds_get_ind);
+EXPORT_SYMBOL_GPL(opal_leds_set_ind);
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/rtas: Introduce rtas_get_sensor_fast() for IRQ handlers
The EPOW interrupt handler uses rtas_get_sensor(), which in turn
uses rtas_busy_delay() to wait for RTAS becoming ready in case it
is necessary. But rtas_busy_delay() is annotated with might_sleep()
and thus may not be used by interrupts handlers like the EPOW handler!
This leads to the following BUG when CONFIG_DEBUG_ATOMIC_SLEEP is
enabled:
BUG: sleeping function called from invalid context at
arch/powerpc/kernel/rtas.c:496
in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/1
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.2.0-rc2-thuth #6
Call Trace:
[c0007ffe7b90] [c0807670] dump_stack+0xa0/0xdc (unreliable)
[c0007ffe7bc0] [c00e1f14] ___might_sleep+0x134/0x180
[c0007ffe7c20] [c002aec0] rtas_busy_delay+0x30/0xd0
[c0007ffe7c50] [c002bde4] rtas_get_sensor+0x74/0xe0
[c0007ffe7ce0] [c0083264] ras_epow_interrupt+0x44/0x450
[c0007ffe7d90] [c0120260] handle_irq_event_percpu+0xa0/0x300
[c0007ffe7e70] [c0120524] handle_irq_event+0x64/0xc0
[c0007ffe7eb0] [c0124dbc] handle_fasteoi_irq+0xec/0x260
[c0007ffe7ef0] [c011f4f0] generic_handle_irq+0x50/0x80
[c0007ffe7f20] [c0010f3c] __do_irq+0x8c/0x200
[c0007ffe7f90] [c00236cc] call_do_irq+0x14/0x24
[c0007e6f39e0] [c0011144] do_IRQ+0x94/0x110
[c0007e6f3a30] [c0002594] hardware_interrupt_common+0x114/0x180
Fix this issue by introducing a new rtas_get_sensor_fast() function
that does not use rtas_busy_delay() - and thus can only be used for
sensors that do not cause a BUSY condition (which should be the case
for the sensor that is queried by the EPOW IRQ handler).
Signed-off-by: Thomas Huth
---
arch/powerpc/include/asm/rtas.h | 1 +
arch/powerpc/kernel/rtas.c | 17 +
arch/powerpc/platforms/pseries/ras.c | 3 ++-
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 7a4ede1..b77ef36 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -343,6 +343,7 @@ extern void rtas_power_off(void);
extern void rtas_halt(void);
extern void rtas_os_term(char *str);
extern int rtas_get_sensor(int sensor, int index, int *state);
+extern int rtas_get_sensor_fast(int sensor, int index, int *state);
extern int rtas_get_power_level(int powerdomain, int *level);
extern int rtas_set_power_level(int powerdomain, int level, int *setlevel);
extern bool rtas_indicator_present(int token, int *maxindex);
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 7a488c1..caffb10 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -584,6 +584,23 @@ int rtas_get_sensor(int sensor, int index, int *state)
}
EXPORT_SYMBOL(rtas_get_sensor);
+int rtas_get_sensor_fast(int sensor, int index, int *state)
+{
+ int token = rtas_token("get-sensor-state");
+ int rc;
+
+ if (token == RTAS_UNKNOWN_SERVICE)
+ return -ENOENT;
+
+ rc = rtas_call(token, 2, 2, state, sensor, index);
+ WARN_ON(rc == RTAS_BUSY || (rc >= RTAS_EXTENDED_DELAY_MIN &&
+ rc <= RTAS_EXTENDED_DELAY_MAX));
+
+ if (rc < 0)
+ return rtas_error_rc(rc);
+ return rc;
+}
+
bool rtas_indicator_present(int token, int *maxindex)
{
int proplen, count, i;
diff --git a/arch/powerpc/platforms/pseries/ras.c
b/arch/powerpc/platforms/pseries/ras.c
index 02e4a17..3b6647e 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -189,7 +189,8 @@ static irqreturn_t ras_epow_interrupt(int irq, void *dev_id)
int state;
int critical;
- status = rtas_get_sensor(EPOW_SENSOR_TOKEN, EPOW_SENSOR_INDEX, &state);
+ status = rtas_get_sensor_fast(EPOW_SENSOR_TOKEN, EPOW_SENSOR_INDEX,
+ &state);
if (state > 3)
critical = 1; /* Time Critical */
--
1.8.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2 1/2] Documentation/features: Add na key to arch-support.txt
To be used for features we will not support on a particular architecture. The git log that adds this needs to provide the justification 'why?' Signed-off-by: Ananth N Mavinakayanahalli --- Documentation/features/arch-support.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/features/arch-support.txt b/Documentation/features/arch-support.txt index d22a109..f2b272e 100644 --- a/Documentation/features/arch-support.txt +++ b/Documentation/features/arch-support.txt @@ -8,4 +8,5 @@ The meaning of entries in the tables is: | ok | # feature supported by the architecture |TODO| # feature not yet supported by the architecture | .. | # feature cannot be supported by the hardware +| na | # feature will not be supported by the architecture ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2 2/2] kprobes: Mark OPTPROBES na for powerpc
Kprobes uses a breakpoint instruction to trap into execution flow and the probed instruction is single-stepped from an alternate location. On some architectures like x86, under certain conditions, the OPTPROBES feature enables replacing the probed instruction with a jump instead, resulting in a significant perfomance boost (one single-step exception is bypassed for each kprobe). Powerpc has an in-kernel instruction emulator. Kprobes on powerpc uses this emulator already and bypasses the single-step exception, with a lot less complexity. Hence, mark OPTPROBES na for powerpc. Signed-off-by: Ananth N Mavinakayanahalli --- .../features/debug/optprobes/arch-support.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/features/debug/optprobes/arch-support.txt b/Documentation/features/debug/optprobes/arch-support.txt index b8999d8..73662f9 100644 --- a/Documentation/features/debug/optprobes/arch-support.txt +++ b/Documentation/features/debug/optprobes/arch-support.txt @@ -27,7 +27,7 @@ | nios2: | TODO | |openrisc: | TODO | | parisc: | TODO | -| powerpc: | TODO | +| powerpc: | na | |s390: | TODO | | score: | TODO | | sh: | TODO | ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/nvram: Add missing kfree in error path
If 'nvram_write_header' fails, then 'new_part' should be freed, otherwise,
there is a memory leak.
Signed-off-by: Christophe JAILLET
---
This patch is *untested* because I have no way to trigger the error.
---
arch/powerpc/kernel/nvram_64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
index 1e703f8..574ff59 100644
--- a/arch/powerpc/kernel/nvram_64.c
+++ b/arch/powerpc/kernel/nvram_64.c
@@ -1079,6 +1079,7 @@ loff_t __init nvram_create_partition(const char *name,
int sig,
if (rc <= 0) {
pr_err("nvram_create_os_partition: nvram_write_header "
"failed (%d)\n", rc);
+ kfree(new_part);
return rc;
}
list_add_tail(&new_part->partition, &free_part->partition);
--
2.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/nvram: Fix function name in some errors messages.
'nvram_create_os_partition' should be 'nvram_create_partition'.
Use __func__ to have it right, as done elsewhere in this file.
Signed-off-by: Christophe JAILLET
---
arch/powerpc/kernel/nvram_64.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
index 574ff59..4dab163 100644
--- a/arch/powerpc/kernel/nvram_64.c
+++ b/arch/powerpc/kernel/nvram_64.c
@@ -1065,7 +1065,7 @@ loff_t __init nvram_create_partition(const char *name,
int sig,
/* Create our OS partition */
new_part = kmalloc(sizeof(*new_part), GFP_KERNEL);
if (!new_part) {
- pr_err("nvram_create_os_partition: kmalloc failed\n");
+ pr_err("%s: kmalloc failed\n", __func__);
return -ENOMEM;
}
@@ -1077,8 +1077,7 @@ loff_t __init nvram_create_partition(const char *name,
int sig,
rc = nvram_write_header(new_part);
if (rc <= 0) {
- pr_err("nvram_create_os_partition: nvram_write_header "
- "failed (%d)\n", rc);
+ pr_err("%s: nvram_write_header failed (%d)\n", __func__, rc);
kfree(new_part);
return rc;
}
@@ -1091,8 +1090,8 @@ loff_t __init nvram_create_partition(const char *name,
int sig,
free_part->header.checksum = nvram_checksum(&free_part->header);
rc = nvram_write_header(free_part);
if (rc <= 0) {
- pr_err("nvram_create_os_partition: nvram_write_header "
- "failed (%d)\n", rc);
+ pr_err("%s: nvram_write_header failed (%d)\n",
+ __func__, rc);
return rc;
}
} else {
@@ -1106,11 +1105,12 @@ loff_t __init nvram_create_partition(const char *name,
int sig,
tmp_index += NVRAM_BLOCK_LEN) {
rc = ppc_md.nvram_write(nv_init_vals, NVRAM_BLOCK_LEN,
&tmp_index);
if (rc <= 0) {
- pr_err("nvram_create_partition: nvram_write failed
(%d)\n", rc);
+ pr_err("%s: nvram_write failed (%d)\n",
+ __func__, rc);
return rc;
}
}
-
+
return new_part->index + NVRAM_HEADER_LEN;
}
--
2.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ipmi/powernv: Fix potential invalid pointer dereference
Hi Corey,
On 07/16/2015 08:31 PM, Corey Minyard wrote:
Ok, this looks fine. A couple of question...
Do I need to send this upstream right now? How well has this been tested?
I would want either Jeremy or Alistair to review this patch before you
send this
upstream. There is also firmware piece
http://patchwork.ozlabs.org/patch/496645/
awaiting review.
In the testing front, I manually made the opal_ipmi_recv() function to
fail for testing
the error path and see if the driver recovers from it and subsequent
ipmi commands
work all good.
Do you want this backported to 4.0 stable?
Yes, I want this to be be backported to 4.0 stable.
Thanks,
Neelesh.
-corey
On 07/16/2015 06:16 AM, Neelesh Gupta wrote:
If the OPAL call to receive the ipmi message fails, then we free up the
smi message and return. But, the driver still holds the reference to
old smi message in the 'cur_msg' which can potentially be accessed later
and freed again leading to kernel oops. To fix it up,
The kernel driver should reset the 'cur_msg' and send reply to the user
in addition to freeing the message.
Signed-off-by: Neelesh Gupta
---
drivers/char/ipmi/ipmi_powernv.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_powernv.c b/drivers/char/ipmi/ipmi_powernv.c
index 9b409c0..637486d 100644
--- a/drivers/char/ipmi/ipmi_powernv.c
+++ b/drivers/char/ipmi/ipmi_powernv.c
@@ -143,9 +143,16 @@ static int ipmi_powernv_recv(struct ipmi_smi_powernv *smi)
pr_devel("%s: -> %d (size %lld)\n", __func__,
rc, rc == 0 ? size : 0);
if (rc) {
- spin_unlock_irqrestore(&smi->msg_lock, flags);
- ipmi_free_smi_msg(msg);
- return 0;
+ /* If came via the poll, and response was not yet ready */
+ if (rc == OPAL_EMPTY) {
+ spin_unlock_irqrestore(&smi->msg_lock, flags);
+ return 0;
+ } else {
+ smi->cur_msg = NULL;
+ spin_unlock_irqrestore(&smi->msg_lock, flags);
+ send_error_reply(smi, msg, IPMI_ERR_UNSPECIFIED);
+ return 0;
+ }
}
if (size < sizeof(*opal_msg)) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] macintosh/ans-lcd: fix build failure after module_init/exit relocation
After commit 0fd972a7d91d ("module: relocate module_init from init.h to
module.h")
ans-lcd module fails to build with:
drivers/macintosh/ans-lcd.c:201:1: warning: data definition has no type or
storage class [enabled by default]
module_init(anslcd_init);
^
drivers/macintosh/ans-lcd.c:201:1: error: type defaults to 'int' in declaration
of 'module_init' [-Werror=implicit-int]
drivers/macintosh/ans-lcd.c:201:1: warning: parameter names (without types) in
function declaration [enabled by default]
drivers/macintosh/ans-lcd.c:202:1: warning: data definition has no type or
storage class [enabled by default]
module_exit(anslcd_exit);
^
drivers/macintosh/ans-lcd.c:202:1: error: type defaults to 'int' in declaration
of 'module_exit' [-Werror=implicit-int]
drivers/macintosh/ans-lcd.c:202:1: warning: parameter names (without types) in
function declaration [enabled by default]
drivers/macintosh/ans-lcd.c:155:1: warning: 'anslcd_init' defined but not used
[-Wunused-function]
anslcd_init(void)
^
drivers/macintosh/ans-lcd.c:195:1: warning: 'anslcd_exit' defined but not used
[-Wunused-function]
anslcd_exit(void)
^
This commit fixes it by replacing linux/init.h by linux/module.h.
Fixes: 0fd972a7d91d ("module: relocate module_init from init.h to module.h")
Signed-off-by: Luis Henriques
---
drivers/macintosh/ans-lcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/macintosh/ans-lcd.c b/drivers/macintosh/ans-lcd.c
index 1a57e88a38f7..cd35079c8c98 100644
--- a/drivers/macintosh/ans-lcd.c
+++ b/drivers/macintosh/ans-lcd.c
@@ -7,7 +7,7 @@
#include
#include
#include
-#include
+#include
#include
#include
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] x86, irq: Rename VECTOR_UNDEFINED and VECTOR_RETRIGGERED to IRQ_*
On Sun, 12 Jul 2015, Bjorn Helgaas wrote: > The per-cpu vector_irq[] table is indexed by CPU vector numbers, and each > entry contains an IRQ number. > > Rename the special values VECTOR_UNDEFINED and VECTOR_RETRIGGERED to > IRQ_UNDEFINED and IRQ_RETRIGGERED to indicate that they are in the IRQ > number space, not the CPU vector number space. Makes some sense, but OTOH vector_irq actually reflects the vector state not the irq number state. The fact that we store the Linux irq number in vector_irq is just an implementation detail. VECTOR_UNDEFINED is certainly a misnomer; that should be VECTOR_UNUSED VECTOR_RETRIGGERED is pretty accurate. In the case we retrigger an interrupt, we merily use the Linux irq number to figure out which vector to kick. And after we retriggered it, we lose the association to the Linux irq number completely. That said, I'm working on storing the irq descriptor pointer in vector_irq instead of the irq number, which has the advantage that we avoid the lookup of the irq descriptor in the interrupt hotpath. Thanks, tglx ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[net-next 02/14] freescale: remove incorrect copied comment
From: Jacob Keller The comment in question is word-for-word copied from ixgbe, and clearly has no meaning in freescale's driver. (it even says 'return an error' when the code clearly does not). Remove the comment as it is obviously incorrect and not applicable to the code as it is today. CC: Pantelis Antoniou CC: Vitaly Bordug CC: Signed-off-by: Jacob Keller Signed-off-by: Jeff Kirsher --- drivers/net/ethernet/freescale/fec_ptp.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c index a15663a..7a8386a 100644 --- a/drivers/net/ethernet/freescale/fec_ptp.c +++ b/drivers/net/ethernet/freescale/fec_ptp.c @@ -506,12 +506,6 @@ int fec_ptp_set(struct net_device *ndev, struct ifreq *ifr) break; default: - /* -* register RXMTRL must be set in order to do V1 packets, -* therefore it is not possible to time stamp both V1 Sync and -* Delay_Req messages and hardware does not support -* timestamping all packets => return error -*/ fep->hwts_rx_en = 1; config.rx_filter = HWTSTAMP_FILTER_ALL; break; -- 2.4.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 3/3] leds/powernv: Add driver for PowerNV platform
Hi Vasant,
On 07/17/2015 12:41 PM, Vasant Hegde wrote:
This patch implements LED driver for PowerNV platform using the existing
generic LED class framework.
PowerNV platform has below type of LEDs:
- System attention
Indicates there is a problem with the system that needs attention.
- Identify
Helps the user locate/identify a particular FRU or resource in the
system.
- Fault
Indicates there is a problem with the FRU or resource at the
location with which the indicator is associated.
We register classdev structures for all individual LEDs detected on the
system through LED specific device tree nodes. Device tree nodes specify
what all kind of LEDs present on the same location code. It registers
LED classdev structure for each of them.
All the system LEDs can be found in the same regular path /sys/class/leds/.
We don't use LED colors. We use LED node and led-types property to form
LED classdev. Our LEDs have names in this format.
:
Any positive brightness value would turn on the LED and a zero value would
turn off the LED. The driver will return LED_FULL (255) for any turned on
LED and LED_OFF (0) for any turned off LED.
As per the LED class framework, the 'brightness_set' function should not
sleep. Hence these functions have been implemented through global work
queue tasks which might sleep on OPAL async call completion.
The platform level implementation of LED get and set state has been achieved
Please don't exceed 75 character line length limit.
through OPAL calls. These calls are made available for the driver by
exporting from architecture specific codes.
Signed-off-by: Vasant Hegde
Signed-off-by: Anshuman Khandual
Acked-by: Stewart Smith
Tested-by: Stewart Smith
---
.../devicetree/bindings/leds/leds-powernv.txt | 26 ++
drivers/leds/Kconfig | 11 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-powernv.c| 422 +
4 files changed, 460 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-powernv.txt
create mode 100644 drivers/leds/leds-powernv.c
diff --git a/Documentation/devicetree/bindings/leds/leds-powernv.txt
b/Documentation/devicetree/bindings/leds/leds-powernv.txt
new file mode 100644
index 000..6665569
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-powernv.txt
@@ -0,0 +1,26 @@
+Device Tree binding for LEDs on IBM Power Systems
+-
+
+Required properties:
+- compatible : Should be "ibm,opal-v3-led".
+- led-mode : Should be "lightpath" or "guidinglight".
+
+Each location code of FRU/Enclosure must be expressed in the
+form of a sub-node.
+
+Required properties for the sub nodes:
+- led-types : Supported LED types (attention/identify/fault) provided
+ in the form of string array.
+
+Example:
+
+leds {
+ compatible = "ibm,opal-v3-led";
+ led-mode = "lightpath";
+
+ U78C9.001.RST0027-P1-C1 {
+ led-types = "identify", "fault";
+ };
+ ...
+ ...
+};
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 9ad35f7..f218cc3a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -560,6 +560,17 @@ config LEDS_BLINKM
This option enables support for the BlinkM RGB LED connected
through I2C. Say Y to enable support for the BlinkM LED.
+config LEDS_POWERNV
+ tristate "LED support for PowerNV Platform"
+ depends on LEDS_CLASS
+ depends on PPC_POWERNV
+ depends on OF
+ help
+ This option enables support for the system LEDs present on
+ PowerNV platforms. Say 'y' to enable this support in kernel.
+ To compile this driver as a module, choose 'm' here: the module
+ will be called leds-powernv.
+
config LEDS_SYSCON
bool "LED support for LEDs on system controllers"
depends on LEDS_CLASS=y
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 8d6a24a..6a943d1 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
obj-$(CONFIG_LEDS_PM8941_WLED)+= leds-pm8941-wled.o
obj-$(CONFIG_LEDS_KTD2692)+= leds-ktd2692.o
+obj-$(CONFIG_LEDS_POWERNV) += leds-powernv.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-powernv.c b/drivers/leds/leds-powernv.c
new file mode 100644
index 000..c3c0b0c
--- /dev/null
+++ b/drivers/leds/leds-powernv.c
@@ -0,0 +1,422 @@
+/*
+ * PowerNV LED Driver
+ *
+ * Copyright IBM Corp. 2015
+ *
+ * Author: Vasant Hegde
+ * Author: Anshuman Khandual
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as
Re: [PATCH v6 3/3] leds/powernv: Add driver for PowerNV platform
On 07/17/2015 08:55 PM, Jacek Anaszewski wrote:
> Hi Vasant,
Hi Jacek,
.../...
>> As per the LED class framework, the 'brightness_set' function should not
>> sleep. Hence these functions have been implemented through global work
>> queue tasks which might sleep on OPAL async call completion.
>>
>> The platform level implementation of LED get and set state has been achieved
>
> Please don't exceed 75 character line length limit.
Ok. I will fix it.. But I thought 80 character is the limit.
>
>> through OPAL calls. These calls are made available for the driver by
>> exporting from architecture specific codes.
>>
.../...
>> +
>> +#include
>> +
>> +/*
>> + * By default unload path resets all the LEDs. But on PowerNV platform
>> + * we want to retain LED state across reboot as these are controlled by
>> + * firmware. Also service processor can modify the LEDs independent of
>> + * OS. Hence avoid resetting LEDs in unload path.
>> + */
>> +static bool led_disabled;
>
> Please move this to the struct powernv_leds_priv.
Hmmm.. Ok. Will update and use platform_get_drvdata to access
platform_get_drvdata.
>
>> +
>> +/* Map LED type to description. */
>> +struct led_type_map {
>> +const inttype;
>> +const char*desc;
>> +};
>> +static const struct led_type_map led_type_map[] = {
>> +{OPAL_SLOT_LED_TYPE_ID,POWERNV_LED_TYPE_IDENTIFY},
>> +{OPAL_SLOT_LED_TYPE_FAULT,POWERNV_LED_TYPE_FAULT},
>> +{OPAL_SLOT_LED_TYPE_ATTN,POWERNV_LED_TYPE_ATTENTION},
>> +{-1,NULL},
>> +};
>> +
>> +/*
>> + * LED set routines have been implemented as work queue tasks scheduled
>> + * on the global work queue. Individual task calls OPAL interface to set
>> + * the LED state which might sleep for some time.
>> + */
>> +struct powernv_led_data {
>> +struct led_classdevcdev;
>> +char*loc_code;/* LED location code */
>> +intled_type;/* OPAL_SLOT_LED_TYPE_* */
>> +enum led_brightnessvalue;/* Brightness value */
>> +struct mutexlock;
>> +struct work_structwork_led;/* LED update workqueue */
>> +};
>> +
>> +struct powernv_leds_priv {
>> +int num_leds;
>> +struct powernv_led_data powernv_leds[];
>> +};
>> +
>> +static __be64 max_led_type = cpu_to_be64(OPAL_SLOT_LED_TYPE_MAX);
>
> The C standard prohibits initialization of global objects with non-constant
> values. Section 6.7.8 of the C99 standard states:
>
> "All the expressions in an initializer for an object that has static storage
> duration shall be constant expressions or string literals."
>
> Compilation succeeds when using powerpc64-linux-gcc because then
> the following version of macro is used:
>
> #define cpu_to_be64(x) (x)
>
> and not
>
> #define cpu_to_be64(x) swab64(x)
>
> Please move max_led_type also to the struct powernv_leds_priv
> and initialize it dynamically.
Yeah.. I should have added this to structure itself. Will fix.
>
>> +
>> +
>> +static inline int sizeof_powernv_leds_priv(int num_leds)
>> +{
>> +return sizeof(struct powernv_leds_priv) +
>> +(sizeof(struct powernv_led_data) * num_leds);
>> +}
>> +/* Returns OPAL_SLOT_LED_TYPE_* for given led type string */
>> +static int powernv_get_led_type(const char *led_type_desc)
>> +{
>> +int i;
>> +
>> +for (i = 0; i < ARRAY_SIZE(led_type_map); i++)
>> +if (!strcmp(led_type_map[i].desc, led_type_desc))
>> +return led_type_map[i].type;
>> +
>> +return -1;
>> +}
>> +
>> +/*
>> + * This commits the state change of the requested LED through an OPAL call.
>> + * This function is called from work queue task context when ever it gets
>> + * scheduled. This function can sleep at opal_async_wait_response call.
>> + */
>> +static void powernv_led_set(struct powernv_led_data *powernv_led)
>> +{
>> +int rc, token;
>> +u64 led_mask, led_value = 0;
>> +__be64 max_type;
>> +struct opal_msg msg;
>> +struct device *dev = powernv_led->cdev.dev;
>> +
>> +/* Prepare for the OPAL call */
>> +max_type = max_led_type;
>> +led_mask = OPAL_SLOT_LED_STATE_ON << powernv_led->led_type;
>> +if (powernv_led->value)
>> +led_value = led_mask;
>> +
>> +/* OPAL async call */
>> +token = opal_async_get_token_interruptible();
>> +if (token < 0) {
>> +if (token != -ERESTARTSYS)
>> +dev_err(dev, "%s: Couldn't get OPAL async token\n",
>> +__func__);
>> +return;
>> +}
>> +
>> +rc = opal_leds_set_ind(token, powernv_led->loc_code,
>> + led_mask, led_value, &max_type);
>> +if (rc != OPAL_ASYNC_COMPLETION) {
>> +dev_err(dev, "%s: OPAL set LED call failed for %s [rc=%d]\n",
>> +__func__, powernv_led->loc_code, rc);
>> +goto out_token;
>> +}
>> +
>> +rc = opal_async_wait_response(token, &msg);
>> +if (rc) {
>> +dev_err(dev,
>> +"%s: Failed to wait for the async response
Re: [PATCH][v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB board support
On Fri, 2015-07-17 at 01:17 -0500, Jain Priyanka-B32167 wrote:
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Friday, July 17, 2015 1:06 AM
> > To: Jain Priyanka-B32167
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB
> > board support
> >
> > > > +i2c@118100{
> > > > + mux@77{
> > > > + compatible = "nxp,pca9546";
> > > > + reg = <0x77>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + };
> > >
> > > A mux with no nodes under it (and yet it has #address-cells/#size-
> > > cells)?
> > > What is it multiplexing?
> > > [Priyanka]: PCA9546 is i2c mux device , to which other i2c devices
> > > (up-to 8
> > > ) can be further connected on output channels On T104xD4RDB, channel
> > > 0, 1, 3 line are connected to PEX device, Channel 2 to hdmi interface
> > > (initialization is done in u-boot only), other channels are grounded.
> > > So, as such Linux is not using the second level I2C devices connected
> > > on this MUX device. So, I have not shown next level hierarchy.
> > > Should I replace 'mux' with some other name? . Please suggest.
> >
> > The device tree describes the hardware, not just what Linux uses... but
> > what
> > I don't understand is why you describe the mux at all if you're not going
> > to
> > describe what goes underneath it.
> >
> [Jain Priyanka-B32167] : Is below looks OK?
> i2c@118100{
> + i2c@77{
> + compatible = "nxp,pca9546";
> + reg = <0x77>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
Where in my above comment did it appear that I was complaining about the node
name?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] x86, irq: Rename VECTOR_UNDEFINED and VECTOR_RETRIGGERED to IRQ_*
On Fri, Jul 17, 2015 at 9:06 AM, Thomas Gleixner wrote: > On Sun, 12 Jul 2015, Bjorn Helgaas wrote: > >> The per-cpu vector_irq[] table is indexed by CPU vector numbers, and each >> entry contains an IRQ number. >> >> Rename the special values VECTOR_UNDEFINED and VECTOR_RETRIGGERED to >> IRQ_UNDEFINED and IRQ_RETRIGGERED to indicate that they are in the IRQ >> number space, not the CPU vector number space. > > Makes some sense, but OTOH vector_irq actually reflects the vector > state not the irq number state. The fact that we store the Linux irq > number in vector_irq is just an implementation detail. > > VECTOR_UNDEFINED is certainly a misnomer; that should be VECTOR_UNUSED > > VECTOR_RETRIGGERED is pretty accurate. In the case we retrigger an > interrupt, we merily use the Linux irq number to figure out which > vector to kick. And after we retriggered it, we lose the association > to the Linux irq number completely. > > That said, I'm working on storing the irq descriptor pointer in > vector_irq instead of the irq number, which has the advantage that we > avoid the lookup of the irq descriptor in the interrupt hotpath. OK, I'll abandon this. Thanks for taking a look! Bjorn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BUG: perf error on syscalls for powerpc64.
On 2015年07月17日 09:59, Ian Munsie wrote: Excerpts from Sukadev Bhattiprolu's message of 2015-07-17 11:51:04 +1000: Are you seeing this on big-endian or little-endian system? IIRC, I saw the opposite behavior on an LE system a few months ago. i.e. without 1028ccf5, 'perf listf|grep syscall' failed. Applying 1028ccf5, seemed to fix it. You could be on to something there - IIRC the ABI was changed for LE to remove the dot symbols. Might be worth testing on both. Yeah, thanks Ian for your hints. it should be the dot symbols. So I'll believe it's good in 4.x, thanks Michael for your patience as well. Cheers, Zumeng Cheers, -Ian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
