* Re: [PATCH] powerpc/p3060qds: Fix select of 'MPC8xxx_GPIO'
From: Kumar Gala @ 2011-11-20 15:53 UTC (permalink / raw)
To: Paul Bolle; +Cc: linux-kernel, Anatolij Gustschin, linuxppc-dev, Shengzhou Liu
In-Reply-To: <1321141830.20271.22.camel@x61.thuisdomein>
On Nov 12, 2011, at 5:50 PM, Paul Bolle wrote:
> The driver for the Freescale P3060 QDS got added by commit 96cc017c5b
> ("[...] Add support for P3060QDS board"). Its Kconfig entry selects
> MPC8xxx_GPIO. But at the time that driver got added MPC8xxx_GPIO was
> already renamed to GPIO_MPC8XXX, by commit c68308dd50c ("gpio: move
> mpc8xxx/512x gpio driver to drivers/gpio").
>
> So make this driver select GPIO_MPC8XXX.
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> 0) Bravely untested: I haven't got the hardware nor the PPC toolchain
> needed to build this. And it seems this needs (build) testing anyhow.
>
> 1) Sent to the people who wrote the two patches mentioned in the commit
> explanation and CC'd the non-authors who signed-off these patches.
>
> 2) The config tools do not complain about selects that cannot be met
> because they concern a Kconfig symbol that doesn't even exist. Shouldn't
> they be made to complain in that case?
>
> arch/powerpc/platforms/85xx/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied to merge
- k
^ permalink raw reply
* [PATCH] powerpc/85xx: Fix compile error on p3060_qds.c
From: Kumar Gala @ 2011-11-20 15:59 UTC (permalink / raw)
To: linuxppc-dev
arch/powerpc/platforms/85xx/p3060_qds.c: In function '__machine_initcall_p3060_qds_declare_of_platform_devices':
arch/powerpc/platforms/85xx/p3060_qds.c:73:1: error: implicit declaration of function 'declare_of_platform_devices'
declare_of_platform_devices should have been corenet_ds_publish_devices.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/platforms/85xx/p3060_qds.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p3060_qds.c b/arch/powerpc/platforms/85xx/p3060_qds.c
index 01dcf44..081cf4a 100644
--- a/arch/powerpc/platforms/85xx/p3060_qds.c
+++ b/arch/powerpc/platforms/85xx/p3060_qds.c
@@ -70,7 +70,7 @@ define_machine(p3060_qds) {
.power_save = e500_idle,
};
-machine_device_initcall(p3060_qds, declare_of_platform_devices);
+machine_device_initcall(p3060_qds, corenet_ds_publish_devices);
#ifdef CONFIG_SWIOTLB
machine_arch_initcall(p3060_qds, swiotlb_setup_bus_notifier);
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 01/29] powerpc/85xx: Simplify P1020RDB CAMP dts using includes
From: Kumar Gala @ 2011-11-20 16:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1321514181-28897-1-git-send-email-galak@kernel.crashing.org>
On Nov 17, 2011, at 1:15 AM, Kumar Gala wrote:
> If we include the p1020rdb.dts instead of p1020si.dts we greatly =
reduce
> duplication and maintenance. We can just list which devices are
> disabled for the given core and mpic protected sources.
>=20
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/boot/dts/p1020rdb_camp_core0.dts | 154 =
+------------------------
> arch/powerpc/boot/dts/p1020rdb_camp_core1.dts | 11 +--
> 2 files changed, 4 insertions(+), 161 deletions(-)
applied 1-29, and v2 for p2041 & p1022 to 'next'
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Fix compile error on p3060_qds.c
From: Kumar Gala @ 2011-11-20 16:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1321804775-15455-1-git-send-email-galak@kernel.crashing.org>
On Nov 20, 2011, at 9:59 AM, Kumar Gala wrote:
> arch/powerpc/platforms/85xx/p3060_qds.c: In function =
'__machine_initcall_p3060_qds_declare_of_platform_devices':
> arch/powerpc/platforms/85xx/p3060_qds.c:73:1: error: implicit =
declaration of function 'declare_of_platform_devices'
>=20
> declare_of_platform_devices should have been =
corenet_ds_publish_devices.
>=20
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/platforms/85xx/p3060_qds.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied to merge
- k=
^ permalink raw reply
* Re: [PATCH v2 1/7] powerpc/85xx: re-enable timebase sync disabled by KEXEC patch
From: Kumar Gala @ 2011-11-20 16:46 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Zhao Chenhui
In-Reply-To: <20111118180114.GB28562@schlenkerla.am.freescale.net>
On Nov 18, 2011, at 12:01 PM, Scott Wood wrote:
> On Fri, Nov 18, 2011 at 08:35:02AM -0600, Kumar Gala wrote:
>>=20
>> On Nov 16, 2011, at 12:42 PM, Scott Wood wrote:
>>=20
>>> On 11/16/2011 03:55 AM, Zhao Chenhui wrote:
>>>> From: Li Yang <leoli@freescale.com>
>>>>=20
>>>> The timebase sync is not only necessary when using KEXEC. It should =
also
>>>> be used by normal boot up and cpu hotplug. Remove the ifdef added =
by
>>>> the KEXEC patch.
>>>=20
>>> Again, no it should not be used by normal boot up (whether KEXEC =
support
>>> is enabled or not). We should only do timebase sync when we =
actually
>>> need to (when we've actually just reset a core), and we should do it =
the
>>> way U-Boot does rather than with smp-tbsync.c.
>>=20
>>=20
>> How can we do u-boot bases timebase sync after the system us up and
>> running? For example would we losing some ticks of time in the case
>> that one core is up and we bring a second core online?
>=20
> Yes, we'll lose a small handful of ticks relative to wall clock time =
--
> but it'll be the same loss on all cores. It's better than possibly
> having the timebase be imperfectly synchronized, and should complete =
more
> quickly.
Hmm, I wondering how many ticks it really is.
> This is only during intrusive events such as kexec or deep sleep (we =
only
> need to reset the core for jog on mpc8536 which has only one core).=20
> During deep sleep all cores' timebases will be stopped. Kexec is
> resetting the kernel; it's not going to care what the old timebase =
was,
> and should resync from RTC.
>=20
> Even if we end up using this for some future power management mode =
where
> we take down some CPUs to the point their timebase stops, but never =
take
> down others, the time loss should be negligible (for comparison, =
what's
> the error tolerance on the crystal frequency?) and acceptable for what =
is
> still a fairly intrusive and rare event.
I'm also concerned about how this ends up working for p4080 when we have =
to sync up to 8 cores or more in the future.
- k=
^ permalink raw reply
* Re: 3.2.0-rc1 panic on PowerPC
From: Christian Kujau @ 2011-11-20 23:31 UTC (permalink / raw)
To: LKML; +Cc: linuxppc-dev
In-Reply-To: <alpine.DEB.2.01.1111150035560.8000@trent.utfs.org>
On Tue, 15 Nov 2011 at 00:44, Christian Kujau wrote:
> I noticed a few crashes on this PowerBook G4 lately, starting somewhere in
> 3.2.0-rc1. The crashes are really rare and as I'm not on the system all
> the time I did not notice most of them. By the time I did, the screen was
> blank already and I had to hard-reset the box. But not this time:
>
> http://nerdbynature.de/bits/3.2.0-rc1/oops/
>
> When the crash occured, the system was failry loaded (CPU and disk I/O
> wise), so that may have triggered it. I tried to type off the stack trace,
> I hope there are not too many typos, see below.
>
> The machine is fairly old, so maybe it's "just" bad RAM or something, I
> wouldn't be suprised. But maybe not, the box us pretty stable most of the
> time and only now I notice these rare crashes.
Happened again with 3.2.0-rc2-00027-gff0ff78, this time with netconsole
enabled. But this time the machine just stopped, w/o any output on the
screen or on netconsole :(
Christian.
> If anyone could take a quick look...?
>
> Thank you,
> Christian.
>
> Instruction dump:
> 92c40008 68000001 0f000000 80040000 5400003c 90040000 817f000c 380bffff
> 901f000c 2f090000 81640018 81440014 <916a0004> 914b0000 92840014 92a49918
> Kernel panic - not syncing: Fatal exception in interrupt
> Call Trace:
> show_stack+0x70/0x1bc (unreliable)
> panic+0xc8/0x220
> die+0x2ac/0x2b8
> bad_page_fault+0xbc/0x104
> handle_page_fault+0x7c/0x80
> Exception: 300 at T.975+0x3f4/0x570
> LR = T.957+0x300/0x570
> kmem_cache_alloc+0x150/0x150
> __aloc_skb+0x50/0x148
> tcp_send_ack+0x35/0x138
> tcp_delay_timer+0x140/0x244
> run_timer_softirq+0x1a0/0x2ec
> __do_softirq+0xf4/0x1bc
> call_do_softirq+0x14/0x24
> do_softirq+0xfc/0x128
> irq_exit+0xa0/0xa4
> timer_interrupt+0x148/0x180
> ret_from_except+0x0/0x14
> cpu_idle+0xa0/0x118
> rest_init+0xf0/0x114
> start_kernel+0x2d0/0x2f0
> 0x3444
> Rebooting in 180 seconds..
>
> --
> BOFH excuse #184:
>
> loop found in loop in redundant loopback
> --
> 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/
>
--
BOFH excuse #387:
Your computer's union contract is set to expire at midnight.
^ permalink raw reply
* Re: 3.2.0-rc1 panic on PowerPC
From: Benjamin Herrenschmidt @ 2011-11-21 0:58 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, LKML
In-Reply-To: <alpine.DEB.2.01.1111201529070.8000@trent.utfs.org>
On Sun, 2011-11-20 at 15:31 -0800, Christian Kujau wrote:
> On Tue, 15 Nov 2011 at 00:44, Christian Kujau wrote:
> > I noticed a few crashes on this PowerBook G4 lately, starting somewhere in
> > 3.2.0-rc1. The crashes are really rare and as I'm not on the system all
> > the time I did not notice most of them. By the time I did, the screen was
> > blank already and I had to hard-reset the box. But not this time:
> >
> > http://nerdbynature.de/bits/3.2.0-rc1/oops/
> >
> > When the crash occured, the system was failry loaded (CPU and disk I/O
> > wise), so that may have triggered it. I tried to type off the stack trace,
> > I hope there are not too many typos, see below.
> >
> > The machine is fairly old, so maybe it's "just" bad RAM or something, I
> > wouldn't be suprised. But maybe not, the box us pretty stable most of the
> > time and only now I notice these rare crashes.
>
> Happened again with 3.2.0-rc2-00027-gff0ff78, this time with netconsole
> enabled. But this time the machine just stopped, w/o any output on the
> screen or on netconsole :(
I've seen something similar with 3.2-rc2 at cfcfc9ec, unfortunately I
couldn't capture the oops log at the time.
Looks like there's some kind of memory corruption happening. So far I
haven't been able to get a good target at what could be causing it.
Cheers,
Ben.
> Christian.
>
> > If anyone could take a quick look...?
> >
> > Thank you,
> > Christian.
> >
> > Instruction dump:
> > 92c40008 68000001 0f000000 80040000 5400003c 90040000 817f000c 380bffff
> > 901f000c 2f090000 81640018 81440014 <916a0004> 914b0000 92840014 92a49918
> > Kernel panic - not syncing: Fatal exception in interrupt
> > Call Trace:
> > show_stack+0x70/0x1bc (unreliable)
> > panic+0xc8/0x220
> > die+0x2ac/0x2b8
> > bad_page_fault+0xbc/0x104
> > handle_page_fault+0x7c/0x80
> > Exception: 300 at T.975+0x3f4/0x570
> > LR = T.957+0x300/0x570
> > kmem_cache_alloc+0x150/0x150
> > __aloc_skb+0x50/0x148
> > tcp_send_ack+0x35/0x138
> > tcp_delay_timer+0x140/0x244
> > run_timer_softirq+0x1a0/0x2ec
> > __do_softirq+0xf4/0x1bc
> > call_do_softirq+0x14/0x24
> > do_softirq+0xfc/0x128
> > irq_exit+0xa0/0xa4
> > timer_interrupt+0x148/0x180
> > ret_from_except+0x0/0x14
> > cpu_idle+0xa0/0x118
> > rest_init+0xf0/0x114
> > start_kernel+0x2d0/0x2f0
> > 0x3444
> > Rebooting in 180 seconds..
> >
> > --
> > BOFH excuse #184:
> >
> > loop found in loop in redundant loopback
> > --
> > 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/
> >
>
^ permalink raw reply
* Re: 3.2.0-rc1 panic on PowerPC
From: Christian Kujau @ 2011-11-21 1:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, LKML
In-Reply-To: <1321837101.13860.6.camel@pasglop>
On Mon, 21 Nov 2011 at 11:58, Benjamin Herrenschmidt wrote:
> I've seen something similar with 3.2-rc2 at cfcfc9ec, unfortunately I
> couldn't capture the oops log at the time.
It just happened again today, after heavy CPU & IO load (rsyncing from/to
external disks on dm-crypt). This time the oops was printed on the screen
but nothing on netconsole:
http://nerdbynature.de/bits/3.2.0-rc1/oops/oops3m.JPG
It looks like the oops I reported earlier (oops2m.JPG) so I doubt it's a
random corruption due to hardware issues...?
Any debug or boot options to set in my next kernel build?
Thanks,
Christian.
> Looks like there's some kind of memory corruption happening. So far I
> haven't been able to get a good target at what could be causing it.
--
BOFH excuse #90:
Budget cuts
^ permalink raw reply
* Re: 3.2.0-rc1 panic on PowerPC
From: Benjamin Herrenschmidt @ 2011-11-21 1:25 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, LKML
In-Reply-To: <alpine.DEB.2.01.1111201701000.8000@trent.utfs.org>
On Sun, 2011-11-20 at 17:17 -0800, Christian Kujau wrote:
> On Mon, 21 Nov 2011 at 11:58, Benjamin Herrenschmidt wrote:
> > I've seen something similar with 3.2-rc2 at cfcfc9ec, unfortunately I
> > couldn't capture the oops log at the time.
>
> It just happened again today, after heavy CPU & IO load (rsyncing from/to
> external disks on dm-crypt). This time the oops was printed on the screen
> but nothing on netconsole:
>
> http://nerdbynature.de/bits/3.2.0-rc1/oops/oops3m.JPG
>
> It looks like the oops I reported earlier (oops2m.JPG) so I doubt it's a
> random corruption due to hardware issues...?
Yeah it's starting to look like a pattern. Your latest oops looks a lot
like the one I had (though it was with tg3 on the g5), ie, vfs_read ->
driver -> allocator -> crash.
> Any debug or boot options to set in my next kernel build?
Well, you can turn everything on see whether that makes any difference
or finds something a bit more precisely
Cheers,
Ben.
> Thanks,
> Christian.
>
> > Looks like there's some kind of memory corruption happening. So far I
> > haven't been able to get a good target at what could be causing it.
>
^ permalink raw reply
* Re: 3.2.0-rc1 panic on PowerPC
From: Benjamin Herrenschmidt @ 2011-11-21 1:51 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, LKML
In-Reply-To: <1321838742.13860.8.camel@pasglop>
On Mon, 2011-11-21 at 12:25 +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2011-11-20 at 17:17 -0800, Christian Kujau wrote:
> > On Mon, 21 Nov 2011 at 11:58, Benjamin Herrenschmidt wrote:
> > > I've seen something similar with 3.2-rc2 at cfcfc9ec, unfortunately I
> > > couldn't capture the oops log at the time.
> >
> > It just happened again today, after heavy CPU & IO load (rsyncing from/to
> > external disks on dm-crypt). This time the oops was printed on the screen
> > but nothing on netconsole:
> >
> > http://nerdbynature.de/bits/3.2.0-rc1/oops/oops3m.JPG
> >
> > It looks like the oops I reported earlier (oops2m.JPG) so I doubt it's a
> > random corruption due to hardware issues...?
>
> Yeah it's starting to look like a pattern. Your latest oops looks a lot
> like the one I had (though it was with tg3 on the g5), ie, vfs_read ->
> driver -> allocator -> crash.
>
> > Any debug or boot options to set in my next kernel build?
>
> Well, you can turn everything on see whether that makes any difference
> or finds something a bit more precisely
BTW. SLUB or SLAB ? Mine was SLUB with SLUB_DEBUG enabled (tho the debug
didn't seem to catch anything).
Cheers,
Ben.
^ permalink raw reply
* Re: 3.2.0-rc1 panic on PowerPC
From: Christian Kujau @ 2011-11-21 2:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, LKML
In-Reply-To: <1321840301.13860.9.camel@pasglop>
On Mon, 21 Nov 2011 at 12:51, Benjamin Herrenschmidt wrote:
> BTW. SLUB or SLAB ? Mine was SLUB with SLUB_DEBUG enabled (tho the debug
> didn't seem to catch anything).
SLUB, and SLUB_DEBUG=y (but w/o SLUB_DEBUG_ON and SLUB_STATS). Full config
here: http://nerdbynature.de/bits/3.2.0-rc1/oops/config.txt
I'm compiling today's git checkout (mainline) with more debug settings
enabled[0], let's see if this helps anything.
Christian.
[0] diff to old config
+CONFIG_RT_MUTEX_TESTER=y
+CONFIG_DEBUG_LOCKDEP=y
+CONFIG_DEBUG_HIGHMEM=y
+CONFIG_DEBUG_INFO=y
+CONFIG_DEBUG_VM=y
+CONFIG_DEBUG_WRITECOUNT=y
+CONFIG_DEBUG_LIST=y
+CONFIG_ATOMIC64_SELFTEST=y
+CONFIG_XMON=y
+CONFIG_XMON_DEFAULT=y
+CONFIG_XMON_DISASSEMBLY=y
+CONFIG_DEBUGGER=y
--
BOFH excuse #242:
Software uses US measurements, but the OS is in metric...
^ permalink raw reply
* Re: [PATCH v3 2/3] hvc_init(): Enforce one-time initialization.
From: Rusty Russell @ 2011-11-21 5:01 UTC (permalink / raw)
To: Miche Baker-Harvey
Cc: Stephen Rothwell, xen-devel, Konrad Rzeszutek Wilk,
Greg Kroah-Hartman, linux-kernel, virtualization, Anton Blanchard,
Amit Shah, Mike Waychison, ppc-dev, Eric Northrup
In-Reply-To: <CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
On Thu, 17 Nov 2011 10:57:37 -0800, Miche Baker-Harvey <miche@google.com> wrote:
> Rusty, Michael, Stephen, et al,
>
> Thanks for your comments on these patches.
>
> For what I'm trying to do, all three patches are necessary, but maybe
> I'm going about it the wrong way. Your input would be appreciated.
> I'm in no way claiming that these patches are "right", just that it's
> working for me, and that what's in the current pool is not.
We have to *understand* the code. If we don't, we need to rewrite the
code so we *do* understand it, or make way for someone who does.
I'm looking at the kvm man page to try to figure out how to have virtio
console, and it's deeply unclear. What kvm commandline are you using?
I'll try to debug it here, and see what I learn about hvc_console.
Cheers,
Rusty.
^ permalink raw reply
* [PATCH] powerpc/85xx: Add lbc suspend support for PM
From: Jia Hongtao @ 2011-11-21 6:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: B11780, b38951
Power supply for LBC registers is off when system go to deep-sleep state.
We save the values of registers before suspend and restore to registers
after resume.
We removed the last two reservation arrays from struct fsl_lbc_regs for
allocating less memory and minimizing the memcpy size.
Signed-off-by: Jiang Yutang <b14898@freescale.com>
Signed-off-by: Jia Hongtao <B38951@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/include/asm/fsl_lbc.h | 7 +++++--
arch/powerpc/sysdev/fsl_lbc.c | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_lbc.h b/arch/powerpc/include/asm/fsl_lbc.h
index 8a0b5ec..420b453 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -238,8 +238,6 @@ struct fsl_lbc_regs {
#define FPAR_LP_CI_SHIFT 0
__be32 fbcr; /**< Flash Byte Count Register */
#define FBCR_BC 0x00000FFF
- u8 res11[0x8];
- u8 res8[0xF00];
};
/*
@@ -294,6 +292,11 @@ struct fsl_lbc_ctrl {
/* status read from LTESR by irq handler */
unsigned int irq_status;
+
+#ifdef CONFIG_SUSPEND
+ /* save regs when system go to deep-sleep */
+ struct fsl_lbc_regs *saved_regs;
+#endif
};
extern int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base,
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index d917573..9f33e40 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -330,6 +330,38 @@ err:
return ret;
}
+#ifdef CONFIG_SUSPEND
+
+/* save lbc registers */
+static int fsl_lbc_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct fsl_lbc_ctrl *ctrl = dev_get_drvdata(&pdev->dev);
+ struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
+
+ ctrl->saved_regs = kmalloc(sizeof(struct fsl_lbc_regs), GFP_KERNEL);
+ if (!ctrl->saved_regs)
+ return -ENOMEM;
+
+ _memcpy_fromio(ctrl->saved_regs, lbc, sizeof(struct fsl_lbc_regs));
+ return 0;
+}
+
+/* restore lbc registers */
+static int fsl_lbc_resume(struct platform_device *pdev)
+{
+ struct fsl_lbc_ctrl *ctrl = dev_get_drvdata(&pdev->dev);
+ struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
+
+ if (ctrl->saved_regs) {
+ _memcpy_toio(lbc, ctrl->saved_regs,
+ sizeof(struct fsl_lbc_regs));
+ kfree(ctrl->saved_regs);
+ ctrl->saved_regs = NULL;
+ }
+ return 0;
+}
+#endif /* CONFIG_SUSPEND */
+
static const struct of_device_id fsl_lbc_match[] = {
{ .compatible = "fsl,elbc", },
{ .compatible = "fsl,pq3-localbus", },
@@ -344,6 +376,10 @@ static struct platform_driver fsl_lbc_ctrl_driver = {
.of_match_table = fsl_lbc_match,
},
.probe = fsl_lbc_ctrl_probe,
+#ifdef CONFIG_SUSPEND
+ .suspend = fsl_lbc_suspend,
+ .resume = fsl_lbc_resume,
+#endif
};
static int __init fsl_lbc_init(void)
--
1.7.5.1
^ permalink raw reply related
* Re: 3.2.0-rc1 panic on PowerPC
From: Markus Trippelsdorf @ 2011-11-21 8:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Christian Kujau, linuxppc-dev, LKML
In-Reply-To: <1321838742.13860.8.camel@pasglop>
On 2011.11.21 at 12:25 +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2011-11-20 at 17:17 -0800, Christian Kujau wrote:
> > On Mon, 21 Nov 2011 at 11:58, Benjamin Herrenschmidt wrote:
> > > I've seen something similar with 3.2-rc2 at cfcfc9ec, unfortunately I
> > > couldn't capture the oops log at the time.
> >
> > It just happened again today, after heavy CPU & IO load (rsyncing from/to
> > external disks on dm-crypt). This time the oops was printed on the screen
> > but nothing on netconsole:
> >
> > http://nerdbynature.de/bits/3.2.0-rc1/oops/oops3m.JPG
> >
> > It looks like the oops I reported earlier (oops2m.JPG) so I doubt it's a
> > random corruption due to hardware issues...?
>
> Yeah it's starting to look like a pattern. Your latest oops looks a lot
> like the one I had (though it was with tg3 on the g5), ie, vfs_read ->
> driver -> allocator -> crash.
I might be seeing a similar issue on x86_64. See:
http://thread.gmane.org/gmane.linux.kernel.mm/70254
--
Markus
^ permalink raw reply
* Re: [PATCH 01/11] KVM: PPC: Add memory-mapping support for PCI passthrough and emulation
From: Paul Mackerras @ 2011-11-21 11:03 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <4EC8F158.8010706@redhat.com>
On Sun, Nov 20, 2011 at 02:23:52PM +0200, Avi Kivity wrote:
>
> There is no "the VMA". There could be multiple VMAs, or none (with the
> mmap() coming afterwards). You could do all the checks you want here,
> only to have host userspace remap it under your feet. This needs to be
> done on a per-page basis at fault time.
OK, so that's a somewhat different mental model than I had in mind. I
can change the code to do almost everything on a per-page basis at
fault time on POWER7. There is one thing we can't do at fault time,
which is to tell the hardware the page size for the "virtual real mode
area" (VRMA), which is a mapping of the memory starting at guest
physical address zero. We can however work out that pagesize the
first time we run a vcpu. By that stage we must have some memory
mapped at gpa 0, otherwise the vcpu is not going to get very far. We
will need to look for the page size of whatever is mapped at gpa 0 at
that point and give it to the hardware.
On PPC970, which is a much older processor, we can't intercept the
page faults (at least not without running the whole guest in user mode
and emulating all the privileged instructions), so once we have given
the guest access to a page, we can't revoke it. We will have to take
and keep a reference to the page so it doesn't go away underneath us,
which of course doesn't guarantee that userland can continue to see
it, but does at least mean we won't corrupt memory.
> > + /*
> > + * We require read & write permission as we cannot yet
> > + * enforce guest read-only protection or no access.
> > + */
> > + if ((vma->vm_flags & (VM_READ | VM_WRITE)) !=
> > + (VM_READ | VM_WRITE))
> > + goto err_unlock;
>
> This, too, must be done at get_user_pages() time.
>
> What happens if mmu notifiers tell you to write protect a page?
On POWER7, we have to remove access to the page, and then when we get
a fault on the page, request write access when we do
get_user_pages_fast.
Paul.
^ permalink raw reply
* Re: [RFC PATCH v5 0/9] fadump: Firmware-assisted dump support for Powerpc.
From: Cong Wang @ 2011-11-21 12:03 UTC (permalink / raw)
To: Vivek Goyal
Cc: Mahesh J Salgaonkar, Kexec-ml, Linux Kernel, Milton Miller,
linuxppc-dev, Randy Dunlap, Eric W. Biederman, Anton Blanchard
In-Reply-To: <20111115151145.16533.16384.stgit@mars.in.ibm.com>
Vivek, could you please review this patchset?
Thanks.
^ permalink raw reply
* Re: [PATCH 01/11] KVM: PPC: Add memory-mapping support for PCI passthrough and emulation
From: Avi Kivity @ 2011-11-21 12:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <20111121110356.GA1516@bloggs.ozlabs.ibm.com>
On 11/21/2011 01:03 PM, Paul Mackerras wrote:
> On Sun, Nov 20, 2011 at 02:23:52PM +0200, Avi Kivity wrote:
> >
> > There is no "the VMA". There could be multiple VMAs, or none (with the
> > mmap() coming afterwards). You could do all the checks you want here,
> > only to have host userspace remap it under your feet. This needs to be
> > done on a per-page basis at fault time.
>
> OK, so that's a somewhat different mental model than I had in mind. I
> can change the code to do almost everything on a per-page basis at
> fault time on POWER7. There is one thing we can't do at fault time,
> which is to tell the hardware the page size for the "virtual real mode
> area" (VRMA), which is a mapping of the memory starting at guest
> physical address zero. We can however work out that pagesize the
> first time we run a vcpu. By that stage we must have some memory
> mapped at gpa 0, otherwise the vcpu is not going to get very far. We
> will need to look for the page size of whatever is mapped at gpa 0 at
> that point and give it to the hardware.
Ok. Do you need to check at fault time that your assumptions haven't
changed, then?
> On PPC970, which is a much older processor, we can't intercept the
> page faults (at least not without running the whole guest in user mode
> and emulating all the privileged instructions), so once we have given
> the guest access to a page, we can't revoke it. We will have to take
> and keep a reference to the page so it doesn't go away underneath us,
> which of course doesn't guarantee that userland can continue to see
> it, but does at least mean we won't corrupt memory.
Yes, this is similar to kvm/x86 before mmu notifiers were added.
>
> > > + /*
> > > + * We require read & write permission as we cannot yet
> > > + * enforce guest read-only protection or no access.
> > > + */
> > > + if ((vma->vm_flags & (VM_READ | VM_WRITE)) !=
> > > + (VM_READ | VM_WRITE))
> > > + goto err_unlock;
> >
> > This, too, must be done at get_user_pages() time.
> >
> > What happens if mmu notifiers tell you to write protect a page?
>
> On POWER7, we have to remove access to the page, and then when we get
> a fault on the page, request write access when we do
> get_user_pages_fast.
Ok, so no ksm for you. Does this apply to kvm-internal write
protection, like we do for the framebuffer and live migration? I guess
you don't care much about the framebuffer (and anyway it doesn't need
read-only access), but removing access for live migration is painful.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* [PATCH 1/3]arch:powerpc:sysdev:mpic.c Remove extra semicolon.
From: Justin P. Mattock @ 2011-11-21 16:43 UTC (permalink / raw)
To: trivial; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel, Justin P. Mattock
From: "Justin P. Mattock" <justinmattock@gmail.com>
The patch below removes an extra semicolon.
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
CC: linuxppc-dev@lists.ozlabs.org
CC: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/sysdev/mpic.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 8c7e852..b3fa3d7 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -901,7 +901,7 @@ int mpic_set_irq_type(struct irq_data *d, unsigned int flow_type)
if (vold != vnew)
mpic_irq_write(src, MPIC_INFO(IRQ_VECTOR_PRI), vnew);
- return IRQ_SET_MASK_OK_NOCOPY;;
+ return IRQ_SET_MASK_OK_NOCOPY;
}
void mpic_set_vector(unsigned int virq, unsigned int vector)
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc/85xx: p1022ds: enable monitor switching via pixis indirect mode
From: Timur Tabi @ 2011-11-21 17:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <20111119120455.8435467a8c11a2a122321670@canb.auug.org.au>
Stephen Rothwell wrote:
> exit_lcs1_iounmap:
> iounmap(lbc_lcs1_ba);
> exit_lcs0_iounmap:
> iounmap(lbc_lcs0_ba);
> exit_indirect_node:
> of_node_put(indirect_node);
> exit_guts_iounmap:
> iounmap(guts);
The point I'm trying to make is that I don't want to have multiple goto exit labels. If I have to rearrange the code or add/delete code, then I probably would need to make similar changes to these labels. I just don't like that sort of thing.
I appreciate your taking the time to review my code and provide suggestions. However, considering that I'm modifying my own code, I would hope that you can appreciate my personal coding style preference. And my style is to reduce the number of labels, even if it means superfluous checks in the exit code.
So Kumar, if there are no further objections, please apply this patch as-is. Thank you.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 01/11] KVM: PPC: Add memory-mapping support for PCI passthrough and emulation
From: Paul Mackerras @ 2011-11-21 21:29 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <4ECA42A2.1040300@redhat.com>
On Mon, Nov 21, 2011 at 02:22:58PM +0200, Avi Kivity wrote:
> On 11/21/2011 01:03 PM, Paul Mackerras wrote:
> > OK, so that's a somewhat different mental model than I had in mind. I
> > can change the code to do almost everything on a per-page basis at
> > fault time on POWER7. There is one thing we can't do at fault time,
> > which is to tell the hardware the page size for the "virtual real mode
> > area" (VRMA), which is a mapping of the memory starting at guest
> > physical address zero. We can however work out that pagesize the
> > first time we run a vcpu. By that stage we must have some memory
> > mapped at gpa 0, otherwise the vcpu is not going to get very far. We
> > will need to look for the page size of whatever is mapped at gpa 0 at
> > that point and give it to the hardware.
>
> Ok. Do you need to check at fault time that your assumptions haven't
> changed, then?
At fault time, if we are expecting a large page and we find a small
page, pretty much all we can do is return from the vcpu_run ioctl with
an EFAULT error -- so yes we do check the page-size assumption at
fault time. The other way around isn't a problem (expecting small
page and find large page), of course.
> > > What happens if mmu notifiers tell you to write protect a page?
> >
> > On POWER7, we have to remove access to the page, and then when we get
> > a fault on the page, request write access when we do
> > get_user_pages_fast.
>
> Ok, so no ksm for you. Does this apply to kvm-internal write
> protection, like we do for the framebuffer and live migration? I guess
> you don't care much about the framebuffer (and anyway it doesn't need
> read-only access), but removing access for live migration is painful.
For the framebuffer, we can use the hardware 'C' (changed) bit to
detect dirty pages without having to make them read-only.
On further thought, we can in fact make pages read-only when the guest
thinks they're read/write, at the cost of making the real protection
faults in the guest a little slower. I'll look into it.
Paul.
^ permalink raw reply
* Re: [PATCH v3 2/3] hvc_init(): Enforce one-time initialization.
From: Miche Baker-Harvey @ 2011-11-21 22:16 UTC (permalink / raw)
To: Rusty Russell
Cc: Stephen Rothwell, xen-devel, Konrad Rzeszutek Wilk,
Greg Kroah-Hartman, linux-kernel, virtualization, Anton Blanchard,
Amit Shah, Mike Waychison, ppc-dev, Eric Northrup
In-Reply-To: <87lira9ii7.fsf@rustcorp.com.au>
Thanks, Rusty. I'm not using QEMU though, just KVM. I create the device,=
wait
for the message from the guest that the device is ready, and then add ports=
.
Miche
On Sun, Nov 20, 2011 at 9:01 PM, Rusty Russell <rusty@rustcorp.com.au> wrot=
e:
> On Thu, 17 Nov 2011 10:57:37 -0800, Miche Baker-Harvey <miche@google.com>=
wrote:
>> Rusty, Michael, Stephen, et al,
>>
>> Thanks for your comments on these patches.
>>
>> For what I'm trying to do, all three patches are necessary, but maybe
>> I'm going about it the wrong way. Your input would be appreciated.
>> I'm in no way claiming that these patches are "right", just that it's
>> working for me, and that what's in the current pool is not.
>
> We have to *understand* the code. =A0If we don't, we need to rewrite the
> code so we *do* understand it, or make way for someone who does.
>
> I'm looking at the kvm man page to try to figure out how to have virtio
> console, and it's deeply unclear. =A0What kvm commandline are you using?
> I'll try to debug it here, and see what I learn about hvc_console.
>
> Cheers,
> Rusty.
>
^ permalink raw reply
* Re: [PATCH v3 2/3] hvc_init(): Enforce one-time initialization.
From: Rusty Russell @ 2011-11-22 0:58 UTC (permalink / raw)
To: Miche Baker-Harvey
Cc: Stephen Rothwell, xen-devel, Konrad Rzeszutek Wilk,
Greg Kroah-Hartman, linux-kernel, virtualization, Anton Blanchard,
Amit Shah, Mike Waychison, ppc-dev, Eric Northrup
In-Reply-To: <CAB8Rdaqno9kVHB8wsbH5=zs_ppUkd1G=siywFFfH3Ud21qK3FA@mail.gmail.com>
On Mon, 21 Nov 2011 14:16:38 -0800, Miche Baker-Harvey <miche@google.com> wrote:
> Thanks, Rusty. I'm not using QEMU though, just KVM. I create the device, wait
> for the message from the guest that the device is ready, and then add ports.
>
> Miche
OK, since Amit was the one who implemented multi-port console, I'm going
to hand this to him.
I'm sure he's been looking for excuses to dive back into the console
code!
Cheers,
Rusty.
^ permalink raw reply
* [PATCH] USB: fsl_udc_core: Use (&) instead of (==) to compare ISO XFER
From: Peter Chen @ 2011-11-22 1:15 UTC (permalink / raw)
To: leoli, balbi; +Cc: gregkh, linuxppc-dev, linux-usb, stable
Some ISO gadgets, like audio, has SYNC attribute as well as
USB_ENDPOINT_XFER_ISOC for their bmAttributes at ISO endpoint
descriptor. So, it needs to use & instead of == to judge if
it is ISO XFER.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
---
drivers/usb/gadget/fsl_udc_core.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c
index d786ba3..bf40de3 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -877,7 +877,7 @@ fsl_ep_queue(struct usb_ep *_ep, struct usb_request *_req, gfp_t gfp_flags)
VDBG("%s, bad ep", __func__);
return -EINVAL;
}
- if (ep->desc->bmAttributes == USB_ENDPOINT_XFER_ISOC) {
+ if (ep->desc->bmAttributes & USB_ENDPOINT_XFER_ISOC) {
if (req->req.length > ep->ep.maxpacket)
return -EMSGSIZE;
}
@@ -1032,7 +1032,7 @@ static int fsl_ep_set_halt(struct usb_ep *_ep, int value)
goto out;
}
- if (ep->desc->bmAttributes == USB_ENDPOINT_XFER_ISOC) {
+ if (ep->desc->bmAttributes & USB_ENDPOINT_XFER_ISOC) {
status = -EOPNOTSUPP;
goto out;
}
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] USB: fsl_udc_core: Use (&) instead of (==) to compare ISO XFER
From: Michal Nazarewicz @ 2011-11-22 1:22 UTC (permalink / raw)
To: leoli, balbi, Peter Chen; +Cc: gregkh, linuxppc-dev, linux-usb, stable
In-Reply-To: <1321924521-3218-1-git-send-email-peter.chen@freescale.com>
On Tue, 22 Nov 2011 02:15:21 +0100, Peter Chen <peter.chen@freescale.com=
> wrote:
> Some ISO gadgets, like audio, has SYNC attribute as well as
> USB_ENDPOINT_XFER_ISOC for their bmAttributes at ISO endpoint
> descriptor. So, it needs to use & instead of =3D=3D to judge if
> it is ISO XFER.
>
> Signed-off-by: Peter Chen <peter.chen@freescale.com>
> ---
> drivers/usb/gadget/fsl_udc_core.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fs=
l_udc_core.c
> index d786ba3..bf40de3 100644
> --- a/drivers/usb/gadget/fsl_udc_core.c
> +++ b/drivers/usb/gadget/fsl_udc_core.c
> @@ -877,7 +877,7 @@ fsl_ep_queue(struct usb_ep *_ep, struct usb_reques=
t *_req, gfp_t gfp_flags)
> VDBG("%s, bad ep", __func__);
> return -EINVAL;
> }
> - if (ep->desc->bmAttributes =3D=3D USB_ENDPOINT_XFER_ISOC) {
> + if (ep->desc->bmAttributes & USB_ENDPOINT_XFER_ISOC) {
What you really meant is:
(ep->desc->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) =3D=3D USB_ENDPOIN=
T_XFER_ISOC
It would probably be useful to create a function that performs that chec=
k rather
than having to type all of that every time.
> if (req->req.length > ep->ep.maxpacket)
> return -EMSGSIZE;
> }
> @@ -1032,7 +1032,7 @@ static int fsl_ep_set_halt(struct usb_ep *_ep, i=
nt value)
> goto out;
> }
>- if (ep->desc->bmAttributes =3D=3D USB_ENDPOINT_XFER_ISOC) {
> + if (ep->desc->bmAttributes & USB_ENDPOINT_XFER_ISOC) {
> status =3D -EOPNOTSUPP;
> goto out;
> }
-- =
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=3D./ `o
..o | Computer Science, Micha=C5=82 =E2=80=9Cmina86=E2=80=9D Nazarewicz=
(o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--
^ permalink raw reply
* Re: [PATCH] USB: fsl_udc_core: Use (&) instead of (==) to compare ISO XFER
From: Michal Nazarewicz @ 2011-11-22 1:26 UTC (permalink / raw)
To: leoli, balbi, Peter Chen; +Cc: gregkh, linuxppc-dev, linux-usb, stable
In-Reply-To: <op.v5bp28eu3l0zgt@mpn-glaptop>
> On Tue, 22 Nov 2011 02:15:21 +0100, Peter Chen <peter.chen@freescale.c=
om> wrote:
>> @@ -877,7 +877,7 @@ fsl_ep_queue(struct usb_ep *_ep, struct usb_reque=
st *_req, gfp_t gfp_flags)
>> VDBG("%s, bad ep", __func__);
>> return -EINVAL;
>> }
>> - if (ep->desc->bmAttributes =3D=3D USB_ENDPOINT_XFER_ISOC) {
>> + if (ep->desc->bmAttributes & USB_ENDPOINT_XFER_ISOC) {
On Tue, 22 Nov 2011 02:22:10 +0100, Michal Nazarewicz <mina86@mina86.com=
> wrote:
> What you really meant is:
>
> (ep->desc->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) =3D=3D USB_ENDPO=
INT_XFER_ISOC
>
> It would probably be useful to create a function that performs that ch=
eck rather
> than having to type all of that every time.
Ah, there it is:
usb_endpoint_xfer_isoc(ep)
:)
>
>> if (req->req.length > ep->ep.maxpacket)
>> return -EMSGSIZE;
>> }
-- =
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=3D./ `o
..o | Computer Science, Micha=C5=82 =E2=80=9Cmina86=E2=80=9D Nazarewicz=
(o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--
^ 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