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' faile
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_UNDE
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/T104
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.
>
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.
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: Pan
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
>
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: er
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 pi
'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/kern
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/arc
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 si
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/Documentatio
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 B
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 --
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 particula
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 throu
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
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 fr
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_rando
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
> > + a
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 even
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
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 fr
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:
* 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 adj
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 go
27 matches
Mail list logo
