On Fri, Mar 10, 2017 at 11:09:08AM +1100, Daniel Axtens wrote:
> Hi Tobin,
>
> > .llong is an undocumented PPC specific directive. The generic
> > equivalent is .quad, but even better (because it's self describing) is
> > .8byte.
> >
> > Convert directives .llong -> .8byte
> >
> > Signed-off-by: T
On Fri, Mar 10, 2017 at 06:40:58PM +1100, Michael Ellerman wrote:
> Daniel Axtens writes:
>
> > Hi Tobin,
> >
> >> .llong is an undocumented PPC specific directive. The generic
> >> equivalent is .quad, but even better (because it's self describing) is
> >> .8byte.
> >>
> >> Convert directives .l
Christophe Leroy writes:
> Help a bit the compiler to provide better code:
>
> unsigned int f(int i)
> {
> return 1 << (31 - i);
> }
>
> unsigned int g(int i)
> {
> return 0x8000 >> i;
> }
>
> Disassembly of section .text:
>
> :
>0: 20 63 00 1f subfic r3,r3,31
>
On Wed, Mar 08, 2017 at 10:19:19PM +1000, Nicholas Piggin wrote:
> Hi Gautham,
>
> I'm just getting back to this. Sorry for the late reply, and
> thanks for the reviews.
No problems.
>
[..snip..]
> > > +#ifdef CONFIG_PPC_P7_NAP
> > > +EXC_COMMON_BEGIN(machine_check_idle_common)
> > > + bl
IRQ 0 is a valid HW interrupt. So get_irq() shall return 0 when
there is no irq, instead of returning irq_linear_revmap(... ,0)
Fixes: f2a0bd3753dad ("[POWERPC] 8xx: powerpc port of core CPM PIC")
Signed-off-by: Christophe Leroy
---
arch/powerpc/sysdev/mpc8xx_pic.c | 2 +-
1 file changed, 1 inse
Hari Bathini writes:
> Currently, the area to preserve boot memory is reserved at the top of
> RAM. This leaves fadump vulnerable to DLPAR memory remove operations.
> As memory for fadump needs to be reserved early in the boot process,
> fadump can't be registered after a DLPAR memory remove oper
Le 10/03/2017 à 09:41, Michael Ellerman a écrit :
Christophe Leroy writes:
Help a bit the compiler to provide better code:
unsigned int f(int i)
{
return 1 << (31 - i);
}
unsigned int g(int i)
{
return 0x8000 >> i;
}
Disassembly of section .text:
:
0: 20
It often happens to have simultanneous interrupts, for instance
when having double Ethernet attachment. With the current
implementation, we suffer the cost of kernel entry/exit for each
interrupt.
This patch introduces a loop in __do_irq() to handle all interrupts
at once before returning.
Signed
3.16.42-rc1 review patch. If anyone has any objections, please let me know.
--
From: Larry Finger
commit 8ae679c4bc2ea2d16d92620da8e3e9332fa4039f upstream.
I am getting the following warning when I build kernel 4.9-git on my
PowerBook G4 with a 32-bit PPC processor:
AS
OPAL returns OPAL_WRONG_STATE upon failing to provide
sensor data due to core sleeping/offline. Added check
in opal_get_sensor_data() for sensor read failure with
OPAL_WRONG_STATE return code and returned -EIO.
Signed-off-by: Vipin K Parashar
---
Changes in v4:
- Removed sleeping core log messag
On Fri, Mar 10, 2017 at 07:41:33PM +1100, Michael Ellerman wrote:
> Well yeah, it saves one instruction, but is it worth it? Are these gpio
> routines in some hot path I don't know about?
If there was a GCC PR for this we probably would make GCC optimise
this; there are many similar things that ar
On Fri, Mar 10, 2017 at 11:54:19AM +0100, Christophe LEROY wrote:
> gpio_get() and gpio_set() are used extensively by some GPIO based
> drivers like SPI, NAND, so it may be worth it as it doesn't impair
> readability (if anyone prefers, we could write (1 << 31) >> i instead
> of 0x8000 >>
Le 10/03/2017 à 14:06, Segher Boessenkool a écrit :
On Fri, Mar 10, 2017 at 11:54:19AM +0100, Christophe LEROY wrote:
gpio_get() and gpio_set() are used extensively by some GPIO based
drivers like SPI, NAND, so it may be worth it as it doesn't impair
readability (if anyone prefers, we could wr
On Fri, Mar 10, 2017 at 03:04:48PM +0100, Christophe LEROY wrote:
> Le 10/03/2017 à 14:06, Segher Boessenkool a écrit :
> >On Fri, Mar 10, 2017 at 11:54:19AM +0100, Christophe LEROY wrote:
> >>gpio_get() and gpio_set() are used extensively by some GPIO based
> >>drivers like SPI, NAND, so it may be
Le 10/03/2017 à 15:32, Segher Boessenkool a écrit :
On Fri, Mar 10, 2017 at 03:04:48PM +0100, Christophe LEROY wrote:
Le 10/03/2017 à 14:06, Segher Boessenkool a écrit :
On Fri, Mar 10, 2017 at 11:54:19AM +0100, Christophe LEROY wrote:
gpio_get() and gpio_set() are used extensively by some G
On 2017/03/02 08:38PM, Michael Ellerman wrote:
> Steven Rostedt writes:
>
> > On Tue, 28 Feb 2017 15:04:15 +1100
> > Michael Ellerman wrote:
> >
> > kernel/trace/ftrace.c more obvious.
> >>
> >> I don't know if it's really worth keeping the names the same across
> >> arches, especially as we al
On Fri, Mar 10, 2017 at 03:41:23PM +0100, Christophe LEROY wrote:
> gpio_get() and gpio_set() are used extensively by some GPIO based
> drivers like SPI, NAND, so it may be worth it as it doesn't impair
> readability (if anyone prefers, we could write (1 << 31) >> i instead
> of
On Thu, 02 Mar 2017 20:38:53 +1100
Michael Ellerman wrote:
> Steven Rostedt writes:
>
> > On Tue, 28 Feb 2017 15:04:15 +1100
> > Michael Ellerman wrote:
> >
> > kernel/trace/ftrace.c more obvious.
> >>
> >> I don't know if it's really worth keeping the names the same across
> >> arches, esp
On 2017/03/10 10:45AM, Steven Rostedt wrote:
> On Thu, 02 Mar 2017 20:38:53 +1100
> Michael Ellerman wrote:
>
> > Steven Rostedt writes:
> >
> > > On Tue, 28 Feb 2017 15:04:15 +1100
> > > Michael Ellerman wrote:
> > >
> > > kernel/trace/ftrace.c more obvious.
> > >>
> > >> I don't know if i
On Fri, 10 Mar 2017 21:38:53 +0530
"Naveen N. Rao" wrote:
> On 2017/03/10 10:45AM, Steven Rostedt wrote:
> > On Thu, 02 Mar 2017 20:38:53 +1100
> > Michael Ellerman wrote:
> > > So if we drop that we're left with ftrace.S - which seems perfect to me.
> >
> > Yeah, I agree. But then there's t
Work for Congestion State Notifications (CSCN) and Message Ring (MR)
handling is handled via the workqueue mechanism. This requires the
driver to disable those IRQs before scheduling the work and re-enabling
it once the work is completed so that the interrupt doesn't continually
fire.
Signed-off-b
21 matches
Mail list logo
