* Re: PS3: Strange issue with kexec and FreeBSD loader
From: Benjamin Herrenschmidt @ 2013-02-21 0:32 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
In-Reply-To: <51253558.1070407@mail.ru>
On Wed, 2013-02-20 at 21:43 +0100, Phileas Fogg wrote:
> I found the single commit which brakes kexec stuff for FreeBSD loader or other
> custom ELF kernels on the PS3 console.
>
>
> From 7230c5644188cd9e3fb380cc97dde00c464a3ba7 Mon Sep 17 00:00:00 2001
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Tue, 6 Mar 2012 18:27:59 +1100
> Subject: [PATCH] powerpc: Rework lazy-interrupt handling
Odd... That rework had its own issues and so several patches went in
subsequently to address them. It's possible that the PS3 does more
horrid stuff we missed here but I don't quite see how to relate that to
your specific memory corruption problem...
Do you see any "pattern" to the corruption ? Does it looks like
something known ? IE., exception frame, ASCII data, MSR values, ...
Ben.
^ permalink raw reply
* Re: PS3: Strange issue with kexec and FreeBSD loader
From: Geoff Levand @ 2013-02-21 0:14 UTC (permalink / raw)
To: Phileas Fogg; +Cc: cbe-oss-dev, linuxppc-dev
In-Reply-To: <51201276.8020104@mail.ru>
Hi Phileas,
On Sun, 2013-02-17 at 00:12 +0100, Phileas Fogg wrote:
> I found new clues about the problem.
>
> Normally the device tree memory segment is allocated at the top of the boot
> memory region. The boot memory size on the PS3 console is 128MB.
>
> root@ps3-linux:~# kexec -l loader.ps3
> segment[0].mem:0x131d000 memsz:262144
> segment[1].mem:0x135d000 memsz:36864
> segment[2].mem:0x7fff000 memsz:4096
>
> And the device tree is located at address 0x7fff000, it's the last page of the
> boot memory.
>
> I changed the kexec-tools and made it store the device tree just after the
> purgatory code which is located at address 0x135d000. Like here:
>
> root@ps3-linux:~# kexec -l loader.ps3
> segment[0].mem:0x131d000 memsz:262144
> segment[1].mem:0x135d000 memsz:36864
> segment[2].mem:0x1366000 memsz:4096 <---- new address of device tree segment
>
> And now the sha256 verification is always successful for the FreeBSD loader too.
> But still no idea what actually corrupts the device tree segment when it's
> located at the top of the boot memory region. And why it happens on Linux 3.7
> and Linux 3.8 but not on Linux 3.3.8.
Excellent work so far.
You may be able to use the Cell Processor's DABR (Data Address Breakpoint)
register to find out what code is writing to that memory area. I have a
helper patch to setup the DABR register from kernel code here:
http://git.kernel.org/?p=linux/kernel/git/geoff/ps3-linux.git;a=commitdiff;h=c46799f5c6ba7594cdaa248ec60a50c7ad1cdeaa
-Geoff
^ permalink raw reply
* Re: PS3: Strange issue with kexec and FreeBSD loader
From: Phileas Fogg @ 2013-02-20 20:43 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
In-Reply-To: <5123D864.4060503@mail.ru>
Phileas Fogg wrote:
> Phileas Fogg wrote:
>> I could finally find the commit which broke FreeBSD booting in linux-stable.git
>> repository.
>> The Linux 3.4-rc1 seems to have this problem already.
>>
>> --------------
>> commit 5375871d432ae9fc581014ac117b96aaee3cd0c7
>> Merge: b57cb72 dfbc2d7
>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>> Date: Wed Mar 21 18:55:10 2012 -0700
>>
>> Merge branch 'next' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
>>
>> Pull powerpc merge from Benjamin Herrenschmidt:
>> "Here's the powerpc batch for this merge window. It is going to be a
>> bit more nasty than usual as in touching things outside of
>> arch/powerpc mostly due to the big iSeriesectomy :-) We finally got
>> rid of the bugger (legacy iSeries support) which was a PITA to
>> maintain and that nobody really used anymore.
>>
>> Here are some of the highlights:
>>
>> - Legacy iSeries is gone. Thanks Stephen ! There's still some bits
>> and pieces remaining if you do a grep -ir series arch/powerpc but
>> they are harmless and will be removed in the next few weeks
>> hopefully.
>>
>> - The 'fadump' functionality (Firmware Assisted Dump) replaces the
>> previous (equivalent) "pHyp assisted dump"... it's a rewrite of a
>> mechanism to get the hypervisor to do crash dumps on pSeries, the
>> new implementation hopefully being much more reliable. Thanks
>> Mahesh Salgaonkar.
>>
>> - The "EEH" code (pSeries PCI error handling & recovery) got a big
>> spring cleaning, motivated by the need to be able to implement a
>> new backend for it on top of some new different type of firwmare.
>>
>> The work isn't complete yet, but a good chunk of the cleanups is
>> there. Note that this adds a field to struct device_node which is
>> not very nice and which Grant objects to. I will have a patch soon
>> that moves that to a powerpc private data structure (hopefully
>> before rc1) and we'll improve things further later on (hopefully
>> getting rid of the need for that pointer completely). Thanks Gavin
>> Shan.
>>
>> - I dug into our exception & interrupt handling code to improve the
>> way we do lazy interrupt handling (and make it work properly with
>> "edge" triggered interrupt sources), and while at it found & fixed
>> a wagon of issues in those areas, including adding support for page
>> fault retry & fatal signals on page faults.
>>
>> - Your usual random batch of small fixes & updates, including a bunch
>> of new embedded boards, both Freescale and APM based ones, etc..."
>>
>> I fixed up some conflicts with the generalized irq-domain changes from
>> Grant Likely, hopefully correctly.
>>
>> * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
>> (141 commits)
>> powerpc/ps3: Do not adjust the wrapper load address
>> powerpc: Remove the rest of the legacy iSeries include files
>> powerpc: Remove the remaining CONFIG_PPC_ISERIES pieces
>> init: Remove CONFIG_PPC_ISERIES
>> powerpc: Remove FW_FEATURE ISERIES from arch code
>> tty/hvc_vio: FW_FEATURE_ISERIES is no longer selectable
>> powerpc/spufs: Fix double unlocks
>> powerpc/5200: convert mpc5200 to use of_platform_populate()
>> powerpc/mpc5200: add options to mpc5200_defconfig
>> powerpc/mpc52xx: add a4m072 board support
>> powerpc/mpc5200: update mpc5200_defconfig to fit for charon board
>> Documentation/powerpc/mpc52xx.txt: Checkpatch cleanup
>> powerpc/44x: Add additional device support for APM821xx SoC and Bluestone
>> board
>> powerpc/44x: Add support PCI-E for APM821xx SoC and Bluestone board
>> MAINTAINERS: Update PowerPC 4xx tree
>> powerpc/44x: The bug fixed support for APM821xx SoC and Bluestone board
>> powerpc: document the FSL MPIC message register binding
>> powerpc: add support for MPIC message register API
>> powerpc/fsl: Added aliased MSIIR register address to MSI node in dts
>> powerpc/85xx: mpc8548cds - add 36-bit dts
>> ...
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> Reverting this commit fixes the problem with SHA256 checkusm in the purgatory
> code too. I'm trying to find out which commit exactly caused the problem.
>
> regards
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
I found the single commit which brakes kexec stuff for FreeBSD loader or other
custom ELF kernels on the PS3 console.
From 7230c5644188cd9e3fb380cc97dde00c464a3ba7 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue, 6 Mar 2012 18:27:59 +1100
Subject: [PATCH] powerpc: Rework lazy-interrupt handling
regards
^ permalink raw reply
* Re: [PATCH][RFC] Replaced tlbilx with tlbwe in the initialization code
From: Diana Craciun @ 2013-02-20 14:31 UTC (permalink / raw)
To: Stuart Yoder; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <CALRxmdCpS6cJ6kJ=cg4Mre6YA572fxyk+596E1k1MX+iRL7s9Q@mail.gmail.com>
On 02/20/2013 04:22 PM, Stuart Yoder wrote:
> On Tue, Feb 19, 2013 at 1:47 PM, Scott Wood <scottwood@freescale.com> wrote:
>> This patch addresses boot-time invalidations only. How will you handle
>> hugetlb invalidations (or indirect entry invalidations, once that becomes
>> supported)?
> We do envision that "direct guest TLB management" is an opt-in option
> that a guest can enable.
>
> If LRAT is on, with TLB management directly handled by guests, the only
> mechanism we have to do TLB1 invalidates is tlbwe. That is our only option
> as far as I know. So, hugetlb and indirect entries will each need to be
> addressed separately. The kernel code that handles these either needs
> to be A) modified to unconditionally do all invalidates by tlbwe or B)
> conditionally
> use tlbwe depending on whether this is a guest that has enabled direct
> TLB management.
>
> Stuart
>
In case of indirect entries I think we can configure tlbwe and tlbilx to
go to the hypervisor. The guest should not mix tlbwe (for TLB0) and
hardware page table walk, so we can support this scenario without
modifying the guest.
Diana
^ permalink raw reply
* Re: [PATCH][RFC] Replaced tlbilx with tlbwe in the initialization code
From: Stuart Yoder @ 2013-02-20 14:22 UTC (permalink / raw)
To: Scott Wood; +Cc: Diana Craciun, linuxppc-dev
In-Reply-To: <1361303278.29654.7@snotra>
On Tue, Feb 19, 2013 at 1:47 PM, Scott Wood <scottwood@freescale.com> wrote:
>
> This patch addresses boot-time invalidations only. How will you handle
> hugetlb invalidations (or indirect entry invalidations, once that becomes
> supported)?
We do envision that "direct guest TLB management" is an opt-in option
that a guest can enable.
If LRAT is on, with TLB management directly handled by guests, the only
mechanism we have to do TLB1 invalidates is tlbwe. That is our only option
as far as I know. So, hugetlb and indirect entries will each need to be
addressed separately. The kernel code that handles these either needs
to be A) modified to unconditionally do all invalidates by tlbwe or B)
conditionally
use tlbwe depending on whether this is a guest that has enabled direct
TLB management.
Stuart
^ permalink raw reply
* RE: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
From: Sethi Varun-B16395 @ 2013-02-20 9:41 UTC (permalink / raw)
To: Craciun Diana Madalina-STFD002
Cc: Wood Scott-B07421, joro@8bytes.org, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5123A169.9060100@freescale.com>
> -----Original Message-----
> From: Craciun Diana Madalina-STFD002
> Sent: Tuesday, February 19, 2013 9:30 PM
> To: Sethi Varun-B16395
> Cc: iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;
> linux-kernel@vger.kernel.org; Wood Scott-B07421; joro@8bytes.org; Yoder
> Stuart-B08248
> Subject: Re: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU
> API implementation.
>=20
> On 02/18/2013 02:52 PM, Varun Sethi wrote:
> > +/**
> > + * pamu_get_ppaace() - Return the primary PACCE
> > + * @liodn: liodn PAACT index for desired PAACE
> > + *
> > + * Returns the ppace pointer upon success else return
> > + * null.
> > + */
> > +static struct paace *pamu_get_ppaace(int liodn) {
> > + if (!ppaact || liodn > PAACE_NUMBER_ENTRIES) {
>=20
> Shouldn't be "liodn >=3D PAACE_NUMBER_ENTRIES" ?
Yes, will fix this.
-Varun
^ permalink raw reply
* Re: [PATCH] powerpc/rtas_flash: Free kmem upon module exit
From: Vasant Hegde @ 2013-02-20 9:32 UTC (permalink / raw)
To: linuxppc-dev, benh
In-Reply-To: <20130208111742.31083.67858.stgit@hegdevasant.in.ibm.com>
Ben,
Let me know your thoughts on this patch.
-Vasant
On 02/08/2013 04:48 PM, Vasant Hegde wrote:
> Memory allocated to rtas_firmware_flash_list in rtas_flash_write
> is not freed during module exit. We hit below call trace if we
> unload rtas_flash module after loading new firmware image and
> before rebooting the system.
>
> Call trace:
> ----------
> Feb 6 08:42:10 eagle3 kernel: kmem_cache_destroy rtas_flash_cache: Slab cache still has objects
> Feb 6 08:42:10 eagle3 kernel: Call Trace:
> Feb 6 08:42:10 eagle3 kernel: [c00000001c303b40] [c000000000014940] .show_stack+0x70/0x1c0 (unreliable)
> Feb 6 08:42:10 eagle3 kernel: [c00000001c303bf0] [c000000000199bec] .kmem_cache_destroy+0x15c/0x170
> Feb 6 08:42:10 eagle3 kernel: [c00000001c303c90] [d000000006fa1208] .rtas_flash_cleanup+0x3c/0x80 [rtas_flash]
> Feb 6 08:42:10 eagle3 kernel: [c00000001c303d20] [c0000000000f8970] .SyS_delete_module+0x1d0/0x2e0
> Feb 6 08:42:10 eagle3 kernel: [c00000001c303e30] [c000000000009954] syscall_exit+0x0/0x94
>
> This patch frees rtas_firmware_flash_list during module exit.
>
> Signed-off-by: Vasant Hegde<hegdevasant@linux.vnet.ibm.com>
> ---
> arch/powerpc/kernel/rtas_flash.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
> index 8329190..e22ef34 100644
> --- a/arch/powerpc/kernel/rtas_flash.c
> +++ b/arch/powerpc/kernel/rtas_flash.c
> @@ -790,6 +790,11 @@ static void __exit rtas_flash_cleanup(void)
> {
> rtas_flash_term_hook = NULL;
>
> + if (rtas_firmware_flash_list) {
> + free_flash_list(rtas_firmware_flash_list);
> + rtas_firmware_flash_list = NULL;
> + }
> +
> if (flash_block_cache)
> kmem_cache_destroy(flash_block_cache);
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH][RFC] Replaced tlbilx with tlbwe in the initialization code
From: Diana Craciun @ 2013-02-20 9:22 UTC (permalink / raw)
To: Scott Wood; +Cc: Yoder Stuart-B08248, linuxppc-dev
In-Reply-To: <1361303278.29654.7@snotra>
On 02/19/2013 09:47 PM, Scott Wood wrote:
> On 02/15/2013 09:16:15 AM, Diana Craciun wrote:
>> On 02/15/2013 02:11 AM, Benjamin Herrenschmidt wrote:
>>> On Thu, 2013-02-14 at 14:56 +0200, Diana Craciun wrote:
>>>> From: Diana Craciun <Diana.Craciun@freescale.com>
>>>>
>>>> On Freescale e6500 cores EPCR[DGTMI] controls whether guest
>>>> supervisor
>>>> state can execute TLB management instructions. If EPCR[DGTMI]=0
>>>> tlbwe and tlbilx are allowed to execute normally in the guest state.
>>>>
>>>> A hypervisor may choose to virtualize TLB1 and for this purpose it
>>>> may use IPROT to protect the entries for being invalidated by the
>>>> guest. However, because tlbwe and tlbilx execution in the guest
>>>> state
>>>> are sharing the same bit, it is not possible to have a scenario
>>>> where
>>>> tlbwe is allowed to be executed in guest state and tlbilx traps.
>>>> When
>>>> guest TLB management instructions are allowed to be executed in
>>>> guest
>>>> state the guest cannot use tlbilx to invalidate TLB1 guest entries.
>>> Sorry, I don't understand the explanation... can you be more
>>> detailed ?
>> TLB1 supports huge page sizes. The guest may see the memory as
>> contiguous but it sees the guest physical memory as presented by the
>> hypervisor. In reality the real physical memory may be fragmented. In
>> this case the hypervisor can add more than one TLB1 entry for one
>> guest request and the hypervisor will keep track of all fragments.
>> When the guest performs a tlbilx, the hypervisor will correctly
>> invalidate all the corresponding fragments because both tlbwe and
>> tlbilx trap and has full control of tlb management instructions
>> targeting TLB1.
>>
>> For e6500 a single bit controls if tlbwe and tlbilx trap to the
>> Hypervisor. tlbwe targeting TLB1 always traps. But if we want to use
>> LRAT for TLB0, we have to configure tlbwe (targeting TLB 0) to go
>> directly to the guest. But in this case tlbilx (which is targeting
>> both TLBs) will never trap.
>>
>> If the tlbilx does not trap, the guest can invalidate only one of
>> (possible more) fragments and furthermore the synchronization between
>> what entries the hypervisor thinks there are in the TLB1 and what are
>> the actual entries is lost.
> This patch addresses boot-time invalidations only. How will you handle
> hugetlb invalidations (or indirect entry invalidations, once that
> becomes supported)?
>
> -Scott
I will not handle them. This patch offers the possibility to run Linux
under hypervisor without using hugetlb or indirect entries (of course in
case when we configure tlb management instructions to go to the guest
because otherwise it works)
If indirect entries are supported most likely we will configure tlbilx
and tlbwe to trap. In this case LRAT will be still used through the page
table walk mechanism.
Diana
^ permalink raw reply
* RE: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
From: Wang Dongsheng-B40534 @ 2013-02-20 5:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3887203D-64E3-4BA5-AB2A-20BE668560A4@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Tuesday, February 19, 2013 3:43 AM
> To: Wang Dongsheng-B40534
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
>=20
>=20
> On Jan 30, 2013, at 9:10 PM, Wang Dongsheng wrote:
>=20
> > Add irq_set_wake support. Just add IRQF_NO_SUSPEND to desc->action-
> >flag.
> > So the wake up interrupt will not be disable in suspend_device_irqs.
> >
> > Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> > ---
> > arch/powerpc/sysdev/mpic.c | 15 +++++++++++++++
> > 1 files changed, 15 insertions(+), 0 deletions(-)
>=20
> Why are we doing this globally for all interrupts? Don't we only have=20
> some specific interrupts that wake us up?
> Also, I'm guessing the wake behavior for interrupts is FSL specific so
> should not apply to ALL users of MPIC.
That is IRQ wakeup (PM) control. Actually not all interrupts will be set.
We just let mpic have this ability. It's control by driver.
If a device has the ability to wake up system, this device driver can set
irq wake up(through enable/disable_irq_wake()), and the driver do not need
add a flag(IRQF_NO_SUSPEND) to request_irq().
for example,
suspend()
{
...;
enable_irq_wake(irq);
...;
}
resume()
{
...;
disable_irq_wake(irq);
...;
}
>=20
> - k
>=20
> >
> > diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> > index 9c6e535..2ed0220 100644
> > --- a/arch/powerpc/sysdev/mpic.c
> > +++ b/arch/powerpc/sysdev/mpic.c
> > @@ -920,6 +920,18 @@ int mpic_set_irq_type(struct irq_data *d, unsigned
> int flow_type)
> > return IRQ_SET_MASK_OK_NOCOPY;
> > }
> >
> > +static int mpic_irq_set_wake(struct irq_data *d, unsigned int on) {
> > + struct irq_desc *desc =3D container_of(d, struct irq_desc, irq_data);
> > +
> > + if (on)
> > + desc->action->flags |=3D IRQF_NO_SUSPEND;
> > + else
> > + desc->action->flags &=3D ~IRQF_NO_SUSPEND;
> > +
> > + return 0;
> > +}
> > +
> > void mpic_set_vector(unsigned int virq, unsigned int vector) {
> > struct mpic *mpic =3D mpic_from_irq(virq); @@ -957,6 +969,7 @@ static
> > struct irq_chip mpic_irq_chip =3D {
> > .irq_unmask =3D mpic_unmask_irq,
> > .irq_eoi =3D mpic_end_irq,
> > .irq_set_type =3D mpic_set_irq_type,
> > + .irq_set_wake =3D mpic_irq_set_wake,
> > };
> >
> > #ifdef CONFIG_SMP
> > @@ -971,6 +984,7 @@ static struct irq_chip mpic_tm_chip =3D {
> > .irq_mask =3D mpic_mask_tm,
> > .irq_unmask =3D mpic_unmask_tm,
> > .irq_eoi =3D mpic_end_irq,
> > + .irq_set_wake =3D mpic_irq_set_wake,
> > };
> >
> > #ifdef CONFIG_MPIC_U3_HT_IRQS
> > @@ -981,6 +995,7 @@ static struct irq_chip mpic_irq_ht_chip =3D {
> > .irq_unmask =3D mpic_unmask_ht_irq,
> > .irq_eoi =3D mpic_end_ht_irq,
> > .irq_set_type =3D mpic_set_irq_type,
> > + .irq_set_wake =3D mpic_irq_set_wake,
> > };
> > #endif /* CONFIG_MPIC_U3_HT_IRQS */
> >
> > --
> > 1.7.5.1
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* RE: [PATCH] powerpc/85xx: dts - add ranges property for SEC
From: Liu Po-B43644 @ 2013-02-20 1:37 UTC (permalink / raw)
To: Gala Kumar-B11780; +Cc: <linuxppc-dev@ozlabs.org>
In-Reply-To: <CF1EE7AED478CD48A05574C8E2DA142D72B420@039-SN1MPN1-005.039d.mgd.msft.net>
Thanks again for the fix. Just ignore this post.
Best regards,
Liu Po
- 8038
-----Original Message-----
From: Gala Kumar-B11780=20
Sent: Wednesday, February 20, 2013 12:01 AM
To: Liu Po-B43644
Cc: <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH] powerpc/85xx: dts - add ranges property for SEC
On Feb 18, 2013, at 6:29 PM, Po Liu wrote:
> This facilitates getting the physical address of the SEC node.
>=20
> Signed-off-by: Liu po <po.liu@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Why are you reposting this, I already applied it:
http://git.kernel.org/?p=3Dlinux/kernel/git/galak/powerpc.git;a=3Dcommit;h=
=3Ddb29cd3c4497e7edf9176284ba7cf3cec1814c7a
- k
^ permalink raw reply
* Please pull 'next' branch of 5xxx tree
From: Anatolij Gustschin @ 2013-02-19 23:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
Hi Ben !
Please pull mpc5xxx patches for v3.9. The bestcomm driver is
moved to drivers/dma (so it will be usable for ColdFire).
mpc5121 now provides common dtsi file and existing mpc5121 device
trees use it. There are some minor clock init and sparse fixes
and updates for various 5200 device tree files from Grant. Some
fixes for bugs in the mpc5121 DIU driver are also included here
(Andrew Morton suggested to push them via my mpc5xxx tree).
All these patches have already been in linux-next for a while.
Thanks!
Anatolij
The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed:
Linux 3.8-rc2 (2013-01-02 18:13:21 -0800)
are available in the git repository at:
git://git.denx.de/linux-2.6-agust.git next
Anatolij Gustschin (11):
powerpc/mpc5121: add common .dtsi and use it in mpc5121ads.dts
powerpc/mpc5121: pdm360ng.dts: use common mpc5121.dtsi
mpc5121: remove obsolete cell-index property from PSC clock code
mpc5121: don't check PSC ac97 using node name
powerpc/512x: initialize clocks before bus probing
drivers/video: fsl-diu-fb: fix pixel formats for 24 and 16 bpp
drivers/video: fsl-diu-fb: fix bugs in interrupt handling
powerpc/512x: add function for chip select parameter configuration
powerpc/mpc512x: fix noderef sparse warnings
powerpc/mpc512x: fix sparce warnings for non static symbols
powerpc/mpc5xxx: fix sparse warning for non static symbol
Grant Likely (2):
powerpc/5200: Add Lite5200 on-board LEDs as devices
powerpc/5200: Use the gpt* labels to simplify mpc5200 dts files
Philippe De Muyter (1):
powerpc, dma: move bestcomm driver from arch/powerpc/sysdev to drivers/dma
arch/powerpc/boot/dts/a3m071.dts | 6 +-
arch/powerpc/boot/dts/a4m072.dts | 27 +-
arch/powerpc/boot/dts/cm5200.dts | 6 +-
arch/powerpc/boot/dts/digsy_mtc.dts | 14 +-
arch/powerpc/boot/dts/lite5200b.dts | 23 +-
arch/powerpc/boot/dts/media5200.dts | 6 +-
arch/powerpc/boot/dts/motionpro.dts | 26 +-
arch/powerpc/boot/dts/mpc5121.dtsi | 410 ++++++++++++++++++++
arch/powerpc/boot/dts/mpc5121ads.dts | 319 ++-------------
arch/powerpc/boot/dts/mpc5200b.dtsi | 25 +-
arch/powerpc/boot/dts/mucmc52.dts | 48 +--
arch/powerpc/boot/dts/o2d.dtsi | 27 +-
arch/powerpc/boot/dts/pcm030.dts | 48 +--
arch/powerpc/boot/dts/pcm032.dts | 45 +--
arch/powerpc/boot/dts/pdm360ng.dts | 273 ++------------
arch/powerpc/boot/dts/uc101.dts | 52 +--
arch/powerpc/include/asm/mpc5121.h | 17 +
arch/powerpc/platforms/512x/clock.c | 34 +-
arch/powerpc/platforms/512x/mpc512x_shared.c | 32 ++-
arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 6 +-
arch/powerpc/platforms/Kconfig | 2 -
arch/powerpc/sysdev/Makefile | 1 -
arch/powerpc/sysdev/mpc5xxx_clocks.c | 4 +-
drivers/Makefile | 2 +-
drivers/ata/pata_mpc52xx.c | 6 +-
drivers/dma/Kconfig | 2 +
drivers/dma/Makefile | 1 +
.../sysdev => drivers/dma}/bestcomm/Kconfig | 0
.../sysdev => drivers/dma}/bestcomm/Makefile | 0
.../powerpc/sysdev => drivers/dma}/bestcomm/ata.c | 6 +-
.../dma}/bestcomm/bcom_ata_task.c | 0
.../dma}/bestcomm/bcom_fec_rx_task.c | 0
.../dma}/bestcomm/bcom_fec_tx_task.c | 0
.../dma}/bestcomm/bcom_gen_bd_rx_task.c | 0
.../dma}/bestcomm/bcom_gen_bd_tx_task.c | 0
.../sysdev => drivers/dma}/bestcomm/bestcomm.c | 6 +-
.../powerpc/sysdev => drivers/dma}/bestcomm/fec.c | 6 +-
.../sysdev => drivers/dma}/bestcomm/gen_bd.c | 6 +-
.../powerpc/sysdev => drivers/dma}/bestcomm/sram.c | 2 +-
drivers/net/ethernet/freescale/fec_mpc52xx.c | 4 +-
drivers/video/fsl-diu-fb.c | 64 ++--
.../sysdev => include/linux/fsl}/bestcomm/ata.h | 0
.../linux/fsl}/bestcomm/bestcomm.h | 0
.../linux/fsl}/bestcomm/bestcomm_priv.h | 0
.../sysdev => include/linux/fsl}/bestcomm/fec.h | 0
.../sysdev => include/linux/fsl}/bestcomm/gen_bd.h | 0
.../sysdev => include/linux/fsl}/bestcomm/sram.h | 0
sound/soc/fsl/mpc5200_dma.c | 4 +-
48 files changed, 716 insertions(+), 844 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc5121.dtsi
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/Kconfig (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/Makefile (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/ata.c (97%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bcom_ata_task.c (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bcom_fec_rx_task.c (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bcom_fec_tx_task.c (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bcom_gen_bd_rx_task.c (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bcom_gen_bd_tx_task.c (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bestcomm.c (99%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/fec.c (98%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/gen_bd.c (98%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/sram.c (99%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/ata.h (100%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/bestcomm.h (100%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/bestcomm_priv.h (100%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/fec.h (100%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/gen_bd.h (100%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/sram.h (100%)
^ permalink raw reply
* Re: [PATCH][RFC] Replaced tlbilx with tlbwe in the initialization code
From: Scott Wood @ 2013-02-19 19:47 UTC (permalink / raw)
To: Diana Craciun; +Cc: linuxppc-dev
In-Reply-To: <511E513F.7090103@freescale.com>
On 02/15/2013 09:16:15 AM, Diana Craciun wrote:
> On 02/15/2013 02:11 AM, Benjamin Herrenschmidt wrote:
>> On Thu, 2013-02-14 at 14:56 +0200, Diana Craciun wrote:
>>> From: Diana Craciun <Diana.Craciun@freescale.com>
>>>=20
>>> On Freescale e6500 cores EPCR[DGTMI] controls whether guest =20
>>> supervisor
>>> state can execute TLB management instructions. If EPCR[DGTMI]=3D0
>>> tlbwe and tlbilx are allowed to execute normally in the guest state.
>>>=20
>>> A hypervisor may choose to virtualize TLB1 and for this purpose it
>>> may use IPROT to protect the entries for being invalidated by the
>>> guest. However, because tlbwe and tlbilx execution in the guest =20
>>> state
>>> are sharing the same bit, it is not possible to have a scenario =20
>>> where
>>> tlbwe is allowed to be executed in guest state and tlbilx traps. =20
>>> When
>>> guest TLB management instructions are allowed to be executed in =20
>>> guest
>>> state the guest cannot use tlbilx to invalidate TLB1 guest entries.
>> Sorry, I don't understand the explanation... can you be more =20
>> detailed ?
>=20
> TLB1 supports huge page sizes. The guest may see the memory as =20
> contiguous but it sees the guest physical memory as presented by the =20
> hypervisor. In reality the real physical memory may be fragmented. In =20
> this case the hypervisor can add more than one TLB1 entry for one =20
> guest request and the hypervisor will keep track of all fragments. =20
> When the guest performs a tlbilx, the hypervisor will correctly =20
> invalidate all the corresponding fragments because both tlbwe and =20
> tlbilx trap and has full control of tlb management instructions =20
> targeting TLB1.
>=20
> For e6500 a single bit controls if tlbwe and tlbilx trap to the =20
> Hypervisor. tlbwe targeting TLB1 always traps. But if we want to use =20
> LRAT for TLB0, we have to configure tlbwe (targeting TLB 0) to go =20
> directly to the guest. But in this case tlbilx (which is targeting =20
> both TLBs) will never trap.
>=20
> If the tlbilx does not trap, the guest can invalidate only one of =20
> (possible more) fragments and furthermore the synchronization between =20
> what entries the hypervisor thinks there are in the TLB1 and what are =20
> the actual entries is lost.
This patch addresses boot-time invalidations only. How will you handle =20
hugetlb invalidations (or indirect entry invalidations, once that =20
becomes supported)?
-Scott=
^ permalink raw reply
* Re: [PATCH 2/2] of: use platform_device_add
From: Jason Gunthorpe @ 2013-02-19 19:03 UTC (permalink / raw)
To: Grant Likely
Cc: Russell King - ARM Linux, Linux Kernel Mailing List, Rob Herring,
Greg Kroah-Hartman, Shawn Guo, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CACxGe6sJfRZ4AaDDtoQv6c-xOdB6-=cCJSn6fKawB0ULnzQFoA@mail.gmail.com>
On Sun, Feb 17, 2013 at 10:49:08AM +0000, Grant Likely wrote:
> > > The patch introduce a regression on imx6q boot. The IOMUXC block on
> > > imx6q is special. It acts not only a pin controller but also a system
> > > controller with a bunch of system level registers in there. That's why
> > > we currently have the following two nodes in imx6q device tree with the
> > > same start "reg" address, which work with drivers/mfd/syscon.c and
> > > drivers/pinctrl/pinctrl-imx6q.c respectively.
> > >
> > > gpr: iomuxc-gpr@020e0000 {
> > > compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
> > > reg = <0x020e0000 0x38>;
> > > };
> > >
> > > iomuxc: iomuxc@020e0000 {
> > > compatible = "fsl,imx6q-iomuxc";
> > > reg = <0x020e0000 0x4000>;
> > > };
> > >
> > > With the patch in place, pinctrl-imx6q fails to register like below.
> > >
> > > syscon 20e0000.iomuxc: syscon regmap start 0x20e0000 end 0x20e3fff registered
> > > imx6q-pinctrl 20e0000.iomuxc: can't request region for resource [mem 0x020e0000-0x020e3fff]
> > > imx6q-pinctrl: probe of 20e0000.iomuxc failed with error -16
>
> Strictly you're not supposed to do that with the device tree. There
> shouldn't be two nodes using the same overlapping memory region unless
> they are parent/child. That rule has been around for a long time, but
> the core never checked for it. What /should/ happen is the two drivers
> should be cooperating for the register region and only one device
> driver probe sets up both behaviours.
This case was something we both discussed when this patch was first
brough up, and both our tests seemed like it was OK.. What is going on
here that these non-staggered regions are failing? It looks like the
platform devices registered but the devm_request_and_iormap failed?
> >> It also breaks all of_amba_device users.
> >>
> >> of_amba_device_create() --> amba_device_add() --> request_resource()
> >> and fails.
> >
> > Presumably that's because we no longer know what the parent resource
> > is supposed to be?
>
> Hmmm, it looks that way, yes. Currently the OF code is using
> iomem_resource as the parent for all amba_device_add() calls
> (driver/of/platform.c), but if the parent node gets registered as a
> platform device and it has the resources then the parenthood chain
> doesn't match up. It isn't immediately obvious to me how to fix this.
> I'm going to drop the patch from my tree. I could use some help
> figuring out what the correct behaviour really should be here.
I looked for a bit and it wasn't obvious to me where the colliding
request_resource was coming from. The DTs for amba busses seem to all
be placed under the root node, or within a simple bus, so there is not
parent platform device and the use of iomem_resource should still be OK?
Jason
^ permalink raw reply
* Re: PS3: Strange issue with kexec and FreeBSD loader
From: Phileas Fogg @ 2013-02-19 19:54 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
In-Reply-To: <5123C729.5040607@mail.ru>
Phileas Fogg wrote:
> I could finally find the commit which broke FreeBSD booting in linux-stable.git
> repository.
> The Linux 3.4-rc1 seems to have this problem already.
>
> --------------
> commit 5375871d432ae9fc581014ac117b96aaee3cd0c7
> Merge: b57cb72 dfbc2d7
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Wed Mar 21 18:55:10 2012 -0700
>
> Merge branch 'next' of
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
>
> Pull powerpc merge from Benjamin Herrenschmidt:
> "Here's the powerpc batch for this merge window. It is going to be a
> bit more nasty than usual as in touching things outside of
> arch/powerpc mostly due to the big iSeriesectomy :-) We finally got
> rid of the bugger (legacy iSeries support) which was a PITA to
> maintain and that nobody really used anymore.
>
> Here are some of the highlights:
>
> - Legacy iSeries is gone. Thanks Stephen ! There's still some bits
> and pieces remaining if you do a grep -ir series arch/powerpc but
> they are harmless and will be removed in the next few weeks
> hopefully.
>
> - The 'fadump' functionality (Firmware Assisted Dump) replaces the
> previous (equivalent) "pHyp assisted dump"... it's a rewrite of a
> mechanism to get the hypervisor to do crash dumps on pSeries, the
> new implementation hopefully being much more reliable. Thanks
> Mahesh Salgaonkar.
>
> - The "EEH" code (pSeries PCI error handling & recovery) got a big
> spring cleaning, motivated by the need to be able to implement a
> new backend for it on top of some new different type of firwmare.
>
> The work isn't complete yet, but a good chunk of the cleanups is
> there. Note that this adds a field to struct device_node which is
> not very nice and which Grant objects to. I will have a patch soon
> that moves that to a powerpc private data structure (hopefully
> before rc1) and we'll improve things further later on (hopefully
> getting rid of the need for that pointer completely). Thanks Gavin
> Shan.
>
> - I dug into our exception & interrupt handling code to improve the
> way we do lazy interrupt handling (and make it work properly with
> "edge" triggered interrupt sources), and while at it found & fixed
> a wagon of issues in those areas, including adding support for page
> fault retry & fatal signals on page faults.
>
> - Your usual random batch of small fixes & updates, including a bunch
> of new embedded boards, both Freescale and APM based ones, etc..."
>
> I fixed up some conflicts with the generalized irq-domain changes from
> Grant Likely, hopefully correctly.
>
> * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
> (141 commits)
> powerpc/ps3: Do not adjust the wrapper load address
> powerpc: Remove the rest of the legacy iSeries include files
> powerpc: Remove the remaining CONFIG_PPC_ISERIES pieces
> init: Remove CONFIG_PPC_ISERIES
> powerpc: Remove FW_FEATURE ISERIES from arch code
> tty/hvc_vio: FW_FEATURE_ISERIES is no longer selectable
> powerpc/spufs: Fix double unlocks
> powerpc/5200: convert mpc5200 to use of_platform_populate()
> powerpc/mpc5200: add options to mpc5200_defconfig
> powerpc/mpc52xx: add a4m072 board support
> powerpc/mpc5200: update mpc5200_defconfig to fit for charon board
> Documentation/powerpc/mpc52xx.txt: Checkpatch cleanup
> powerpc/44x: Add additional device support for APM821xx SoC and Bluestone
> board
> powerpc/44x: Add support PCI-E for APM821xx SoC and Bluestone board
> MAINTAINERS: Update PowerPC 4xx tree
> powerpc/44x: The bug fixed support for APM821xx SoC and Bluestone board
> powerpc: document the FSL MPIC message register binding
> powerpc: add support for MPIC message register API
> powerpc/fsl: Added aliased MSIIR register address to MSI node in dts
> powerpc/85xx: mpc8548cds - add 36-bit dts
> ...
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
Reverting this commit fixes the problem with SHA256 checkusm in the purgatory
code too. I'm trying to find out which commit exactly caused the problem.
regards
^ permalink raw reply
* Re: [PATCH v5 29/45] x86/xen: Use get/put_online_cpus_atomic() to prevent CPU offline
From: Srivatsa S. Bhat @ 2013-02-19 18:29 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: linux-doc, peterz, fweisbec, linux-kernel, mingo, linux-arch,
linux, xiaoguangrong, wangyun, paulmck, nikunj, linux-pm, rusty,
rostedt, rjw, namhyung, tglx, linux-arm-kernel, netdev, oleg, sbw,
tj, akpm, linuxppc-dev
In-Reply-To: <20130219181038.GB18244@phenom.dumpdata.com>
On 02/19/2013 11:40 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 22, 2013 at 01:10:51PM +0530, Srivatsa S. Bhat wrote:
>> Once stop_machine() is gone from the CPU offline path, we won't be able to
>> depend on preempt_disable() or local_irq_disable() to prevent CPUs from
>> going offline from under us.
>>
>> Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
>> while invoking from atomic context.
>>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> Weird. I see this in the patch but I don't see it in the header?
Meaning, you didn't get this email at all?
> Did you
> explicitly suppress the CC part?
>
No.. I sent the entire patchset to a set of email ids and in addition to
that I CC'ed individual patches to the respective maintainers/lists (the
CC: list in the changelog). I used the --auto knob from stgit to do that.
>
> Anyhow, the patch looks sane enough, thought I need to to run it through
> a test framework just to be on a sure side.
>
Sure, thank you. But you might want to test the v6 that I sent out
yesterday instead of v5. Oh, wait a min, you didn't get the v6 mail also?
Here it is, for your reference:
http://marc.info/?l=linux-kernel&m=136119260122255&w=2
Regards,
Srivatsa S. Bhat
>> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Cc: x86@kernel.org
>> Cc: xen-devel@lists.xensource.com
>> Cc: virtualization@lists.linux-foundation.org
>> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
>> ---
^ permalink raw reply
* Re: [PATCH v5 29/45] x86/xen: Use get/put_online_cpus_atomic() to prevent CPU offline
From: Konrad Rzeszutek Wilk @ 2013-02-19 18:10 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: linux-doc, peterz, fweisbec, linux-kernel, mingo, linux-arch,
linux, xiaoguangrong, wangyun, paulmck, nikunj, linux-pm, rusty,
rostedt, rjw, namhyung, tglx, linux-arm-kernel, netdev, oleg, sbw,
tj, akpm, linuxppc-dev
In-Reply-To: <20130122074046.13822.61950.stgit@srivatsabhat.in.ibm.com>
On Tue, Jan 22, 2013 at 01:10:51PM +0530, Srivatsa S. Bhat wrote:
> Once stop_machine() is gone from the CPU offline path, we won't be able to
> depend on preempt_disable() or local_irq_disable() to prevent CPUs from
> going offline from under us.
>
> Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
> while invoking from atomic context.
>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Weird. I see this in the patch but I don't see it in the header? Did you
explicitly suppress the CC part?
Anyhow, the patch looks sane enough, thought I need to to run it through
a test framework just to be on a sure side.
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: xen-devel@lists.xensource.com
> Cc: virtualization@lists.linux-foundation.org
> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> ---
>
> arch/x86/xen/mmu.c | 11 +++++++++--
> arch/x86/xen/smp.c | 9 +++++++++
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 01de35c..6a95a15 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -39,6 +39,7 @@
> * Jeremy Fitzhardinge <jeremy@xensource.com>, XenSource Inc, 2007
> */
> #include <linux/sched.h>
> +#include <linux/cpu.h>
> #include <linux/highmem.h>
> #include <linux/debugfs.h>
> #include <linux/bug.h>
> @@ -1163,9 +1164,13 @@ static void xen_drop_mm_ref(struct mm_struct *mm)
> */
> static void xen_exit_mmap(struct mm_struct *mm)
> {
> - get_cpu(); /* make sure we don't move around */
> + /*
> + * Make sure we don't move around, and prevent CPUs from going
> + * offline.
> + */
> + get_online_cpus_atomic();
> xen_drop_mm_ref(mm);
> - put_cpu();
> + put_online_cpus_atomic();
>
> spin_lock(&mm->page_table_lock);
>
> @@ -1371,6 +1376,7 @@ static void xen_flush_tlb_others(const struct cpumask *cpus,
> args->op.arg2.vcpumask = to_cpumask(args->mask);
>
> /* Remove us, and any offline CPUS. */
> + get_online_cpus_atomic();
> cpumask_and(to_cpumask(args->mask), cpus, cpu_online_mask);
> cpumask_clear_cpu(smp_processor_id(), to_cpumask(args->mask));
>
> @@ -1383,6 +1389,7 @@ static void xen_flush_tlb_others(const struct cpumask *cpus,
> MULTI_mmuext_op(mcs.mc, &args->op, 1, NULL, DOMID_SELF);
>
> xen_mc_issue(PARAVIRT_LAZY_MMU);
> + put_online_cpus_atomic();
> }
>
> static unsigned long xen_read_cr3(void)
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 4f7d259..7d753ae 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -16,6 +16,7 @@
> #include <linux/err.h>
> #include <linux/slab.h>
> #include <linux/smp.h>
> +#include <linux/cpu.h>
> #include <linux/irq_work.h>
>
> #include <asm/paravirt.h>
> @@ -487,8 +488,10 @@ static void __xen_send_IPI_mask(const struct cpumask *mask,
> {
> unsigned cpu;
>
> + get_online_cpus_atomic();
> for_each_cpu_and(cpu, mask, cpu_online_mask)
> xen_send_IPI_one(cpu, vector);
> + put_online_cpus_atomic();
> }
>
> static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
> @@ -551,8 +554,10 @@ void xen_send_IPI_all(int vector)
> {
> int xen_vector = xen_map_vector(vector);
>
> + get_online_cpus_atomic();
> if (xen_vector >= 0)
> __xen_send_IPI_mask(cpu_online_mask, xen_vector);
> + put_online_cpus_atomic();
> }
>
> void xen_send_IPI_self(int vector)
> @@ -572,20 +577,24 @@ void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
> if (!(num_online_cpus() > 1))
> return;
>
> + get_online_cpus_atomic();
> for_each_cpu_and(cpu, mask, cpu_online_mask) {
> if (this_cpu == cpu)
> continue;
>
> xen_smp_send_call_function_single_ipi(cpu);
> }
> + put_online_cpus_atomic();
> }
>
> void xen_send_IPI_allbutself(int vector)
> {
> int xen_vector = xen_map_vector(vector);
>
> + get_online_cpus_atomic();
> if (xen_vector >= 0)
> xen_send_IPI_mask_allbutself(cpu_online_mask, xen_vector);
> + put_online_cpus_atomic();
> }
>
> static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
>
> --
> 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: PS3: Strange issue with kexec and FreeBSD loader
From: Phileas Fogg @ 2013-02-19 18:40 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
In-Reply-To: <1360365046.495584377@f356.mail.ru>
I could finally find the commit which broke FreeBSD booting in linux-stable.git
repository.
The Linux 3.4-rc1 seems to have this problem already.
--------------
commit 5375871d432ae9fc581014ac117b96aaee3cd0c7
Merge: b57cb72 dfbc2d7
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed Mar 21 18:55:10 2012 -0700
Merge branch 'next' of
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
Pull powerpc merge from Benjamin Herrenschmidt:
"Here's the powerpc batch for this merge window. It is going to be a
bit more nasty than usual as in touching things outside of
arch/powerpc mostly due to the big iSeriesectomy :-) We finally got
rid of the bugger (legacy iSeries support) which was a PITA to
maintain and that nobody really used anymore.
Here are some of the highlights:
- Legacy iSeries is gone. Thanks Stephen ! There's still some bits
and pieces remaining if you do a grep -ir series arch/powerpc but
they are harmless and will be removed in the next few weeks
hopefully.
- The 'fadump' functionality (Firmware Assisted Dump) replaces the
previous (equivalent) "pHyp assisted dump"... it's a rewrite of a
mechanism to get the hypervisor to do crash dumps on pSeries, the
new implementation hopefully being much more reliable. Thanks
Mahesh Salgaonkar.
- The "EEH" code (pSeries PCI error handling & recovery) got a big
spring cleaning, motivated by the need to be able to implement a
new backend for it on top of some new different type of firwmare.
The work isn't complete yet, but a good chunk of the cleanups is
there. Note that this adds a field to struct device_node which is
not very nice and which Grant objects to. I will have a patch soon
that moves that to a powerpc private data structure (hopefully
before rc1) and we'll improve things further later on (hopefully
getting rid of the need for that pointer completely). Thanks Gavin
Shan.
- I dug into our exception & interrupt handling code to improve the
way we do lazy interrupt handling (and make it work properly with
"edge" triggered interrupt sources), and while at it found & fixed
a wagon of issues in those areas, including adding support for page
fault retry & fatal signals on page faults.
- Your usual random batch of small fixes & updates, including a bunch
of new embedded boards, both Freescale and APM based ones, etc..."
I fixed up some conflicts with the generalized irq-domain changes from
Grant Likely, hopefully correctly.
* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
(141 commits)
powerpc/ps3: Do not adjust the wrapper load address
powerpc: Remove the rest of the legacy iSeries include files
powerpc: Remove the remaining CONFIG_PPC_ISERIES pieces
init: Remove CONFIG_PPC_ISERIES
powerpc: Remove FW_FEATURE ISERIES from arch code
tty/hvc_vio: FW_FEATURE_ISERIES is no longer selectable
powerpc/spufs: Fix double unlocks
powerpc/5200: convert mpc5200 to use of_platform_populate()
powerpc/mpc5200: add options to mpc5200_defconfig
powerpc/mpc52xx: add a4m072 board support
powerpc/mpc5200: update mpc5200_defconfig to fit for charon board
Documentation/powerpc/mpc52xx.txt: Checkpatch cleanup
powerpc/44x: Add additional device support for APM821xx SoC and Bluestone
board
powerpc/44x: Add support PCI-E for APM821xx SoC and Bluestone board
MAINTAINERS: Update PowerPC 4xx tree
powerpc/44x: The bug fixed support for APM821xx SoC and Bluestone board
powerpc: document the FSL MPIC message register binding
powerpc: add support for MPIC message register API
powerpc/fsl: Added aliased MSIIR register address to MSI node in dts
powerpc/85xx: mpc8548cds - add 36-bit dts
...
^ permalink raw reply
* Re: [PATCH] bsc9131:l2sram: Add compatible string for BSC9131 platform
From: Gala Kumar-B11780 @ 2013-02-19 17:18 UTC (permalink / raw)
To: Rai Harninder-B01044; +Cc: <linuxppc-dev@ozlabs.org>
In-Reply-To: <1361265261-28169-1-git-send-email-harninder.rai@freescale.com>
On Feb 19, 2013, at 3:14 AM, Harninder Rai wrote:
> Signed-off-by: Harninder Rai <harninder.rai@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] bsc9131/dts: Correct typo in SDHC device node
From: Gala Kumar-B11780 @ 2013-02-19 17:18 UTC (permalink / raw)
To: Rai Harninder-B01044; +Cc: <linuxppc-dev@ozlabs.org>
In-Reply-To: <1361265238-28100-1-git-send-email-harninder.rai@freescale.com>
On Feb 19, 2013, at 3:13 AM, Harninder Rai wrote:
> BSC9131RDB doesn't have SDHC enabled. As a result of this typo,
> the node was not getting disabled from the device tree which was
> leading to linux hang during bootup
>=20
> Signed-off-by: Harninder Rai <harninder.rai@freescale.com>
> ---
> arch/powerpc/boot/dts/bsc9131rdb.dtsi | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied to next
- k
^ permalink raw reply
* [git pull] Please pull powerpc.git next branch
From: Kumar Gala @ 2013-02-19 17:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Mostly misc code cleanups in various board ports and adding support for a
new MPC85xx board - ppa8548.
- k
The following changes since commit 2468dcf641e4f3e1b0153e3e11ca20740b2f4ce8:
Ian Munsie (1):
powerpc: Add support for context switching the TAR register
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git next
Gerlando Falauto (2):
powerpc/83xx: refactor mpc8360e quirk for kmeter1
powerpc/83xx: apply mpc8360e quirk for kmeter1 only when par_io is present
Harninder Rai (2):
powerpc/85xx: bsc9131 - Correct typo in SDHC device node
powerpc/85xx: l2sram - Add compatible string for BSC9131 platform
Holger Brunck (3):
powerpc/82xx: fix checkpatch warnings for km82xx.c
powerpc/83xx: fix checkpatch warnings for km83xx.c
powerpc/83xx: update kmeter1_defconfig
Julia Lawall (1):
arch/powerpc/platforms/85xx/p1022_ds.c: adjust duplicate test
Kim Phillips (4):
powerpc/fsl: lbc: sparse fixes
powerpc/fsl: fsl_soc: sparse fixes
powerpc/fsl: ifc: sparse fixes
powerpc/fsl: msi: sparse fixes
Paul Gortmaker (4):
powerpc/85xx: split sbc8548 dts file into pre and post chunks
powerpc/85xx: update sbc8548 flash information to match recent u-boot
powerpc/85xx: add alternate dts file for sbc8548 boot via SODIMM
powerpc/85xx: enable MTD options in sbc8548 defconfig
Po Liu (1):
powerpc/85xx: dts - add ranges property for SEC
Scott Wood (2):
powerpc/mpic: allow coreint to be determined by MPIC version
powerpc/e500/qemu-e500: enable coreint
Stef van Os (1):
powerpc/85xx: Board support for ppa8548
Timur Tabi (3):
powerpc/85xx: describe the PAMU topology in the device tree
powerpc/85xx: fix various PCI node compatible strings
powerpc/fsl: remove extraneous DIU platform functions
Vakul Garg (1):
crypto: caam - Added property fsl, sec-era in SEC4.0 device tree binding.
Varun Sethi (1):
powerpc/fsl_pci: Store the pci ctlr device ptr in the pci ctlr struct
Wei Yongjun (1):
powerpc/85xx: use for_each_compatible_node() macro
.../devicetree/bindings/crypto/fsl-sec4.txt | 12 +-
.../devicetree/bindings/powerpc/fsl/guts.txt | 13 +-
.../devicetree/bindings/powerpc/fsl/pamu.txt | 140 ++++++++
arch/powerpc/boot/dts/bsc9131rdb.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 4 +-
arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 6 +-
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 87 ++++-
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 87 ++++-
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 74 +++-
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 92 ++++-
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 92 ++++-
arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi | 1 +
arch/powerpc/boot/dts/ppa8548.dts | 166 +++++++++
arch/powerpc/boot/dts/sbc8548-altflash.dts | 115 +++++++
arch/powerpc/boot/dts/sbc8548-post.dtsi | 295 ++++++++++++++++
arch/powerpc/boot/dts/sbc8548-pre.dtsi | 52 +++
arch/powerpc/boot/dts/sbc8548.dts | 356 ++------------------
arch/powerpc/configs/83xx/kmeter1_defconfig | 6 +-
arch/powerpc/configs/85xx/ppa8548_defconfig | 65 ++++
arch/powerpc/configs/85xx/sbc8548_defconfig | 19 ++
arch/powerpc/platforms/512x/mpc512x_shared.c | 5 -
arch/powerpc/platforms/82xx/km82xx.c | 6 +-
arch/powerpc/platforms/83xx/km83xx.c | 161 ++++-----
arch/powerpc/platforms/85xx/Kconfig | 7 +
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +-
arch/powerpc/platforms/85xx/p1022_ds.c | 40 +--
arch/powerpc/platforms/85xx/p1022_rdk.c | 12 -
arch/powerpc/platforms/85xx/ppa8548.c | 98 ++++++
arch/powerpc/platforms/85xx/qemu_e500.c | 7 +-
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
arch/powerpc/sysdev/fsl_ifc.c | 2 +-
arch/powerpc/sysdev/fsl_lbc.c | 6 +-
arch/powerpc/sysdev/fsl_msi.c | 4 +-
arch/powerpc/sysdev/fsl_pci.c | 24 +-
arch/powerpc/sysdev/fsl_pci.h | 2 +-
arch/powerpc/sysdev/fsl_soc.c | 4 +-
arch/powerpc/sysdev/mpic.c | 26 +-
38 files changed, 1530 insertions(+), 564 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
create mode 100644 arch/powerpc/boot/dts/ppa8548.dts
create mode 100644 arch/powerpc/boot/dts/sbc8548-altflash.dts
create mode 100644 arch/powerpc/boot/dts/sbc8548-post.dtsi
create mode 100644 arch/powerpc/boot/dts/sbc8548-pre.dtsi
create mode 100644 arch/powerpc/configs/85xx/ppa8548_defconfig
create mode 100644 arch/powerpc/platforms/85xx/ppa8548.c
^ permalink raw reply
* Re: [PATCH] bsc913x:defconfig: Add new defconfig file for BSC913x platforms
From: Gala Kumar-B11780 @ 2013-02-19 16:01 UTC (permalink / raw)
To: Rai Harninder-B01044; +Cc: <linuxppc-dev@ozlabs.org>
In-Reply-To: <1361265290-28206-1-git-send-email-harninder.rai@freescale.com>
On Feb 19, 2013, at 3:14 AM, Harninder Rai wrote:
> BSC913x are heterogeneous platforms having DSP and PowerPC.
> * Lot of new IPs like AIC (Antenna Interface Controller), RF (radio) etc
> * Such IPs are not present in any other 85xx platform
> * Lot of optimizations related to ethernet/ASF (Application Specific Fast=
path)
> are enabled in this config
> * IPC for inter-domain communication (DSP and PA) is present
>=20
> Signed-off-by: Harninder Rai <harninder.rai@freescale.com>
> ---
> arch/powerpc/configs/qoriq_sdk_asf_term_defconfig | 209 ++++++++++++++++=
+++++
> 1 files changed, 209 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/configs/qoriq_sdk_asf_term_defconfig
I'm ignoring this as this is clearly meant for FSL SDK and not upstream.
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: dts - add ranges property for SEC
From: Gala Kumar-B11780 @ 2013-02-19 16:01 UTC (permalink / raw)
To: Liu Po-B43644; +Cc: <linuxppc-dev@ozlabs.org>
In-Reply-To: <1361233746-19106-1-git-send-email-po.liu@freescale.com>
On Feb 18, 2013, at 6:29 PM, Po Liu wrote:
> This facilitates getting the physical address of the SEC node.
>=20
> Signed-off-by: Liu po <po.liu@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Why are you reposting this, I already applied it:
http://git.kernel.org/?p=3Dlinux/kernel/git/galak/powerpc.git;a=3Dcommit;h=
=3Ddb29cd3c4497e7edf9176284ba7cf3cec1814c7a
- k=
^ permalink raw reply
* Re: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
From: Diana Craciun @ 2013-02-19 15:59 UTC (permalink / raw)
To: Varun Sethi
Cc: joro, stuart.yoder, linux-kernel, iommu, scottwood, linuxppc-dev
In-Reply-To: <1361191939-21260-7-git-send-email-Varun.Sethi@freescale.com>
On 02/18/2013 02:52 PM, Varun Sethi wrote:
> +/**
> + * pamu_get_ppaace() - Return the primary PACCE
> + * @liodn: liodn PAACT index for desired PAACE
> + *
> + * Returns the ppace pointer upon success else return
> + * null.
> + */
> +static struct paace *pamu_get_ppaace(int liodn)
> +{
> + if (!ppaact || liodn > PAACE_NUMBER_ENTRIES) {
Shouldn't be "liodn >= PAACE_NUMBER_ENTRIES" ?
> + pr_err("PPAACT doesn't exist\n");
> + return NULL;
> + }
> +
> + return &ppaact[liodn];
> +}
> +
Diana
^ permalink raw reply
* Re: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
From: Srivatsa S. Bhat @ 2013-02-19 10:58 UTC (permalink / raw)
To: David Laight
Cc: linux-doc, peterz, fweisbec, linux-kernel, namhyung,
Michel Lespinasse, mingo, linux-arch, linux, xiaoguangrong,
wangyun, paulmck, nikunj, linux-pm, rusty, rostedt, rjw,
vincent.guittot, tglx, linux-arm-kernel, netdev, oleg, sbw, tj,
akpm, linuxppc-dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7154@saturn3.aculab.com>
On 02/19/2013 04:12 PM, David Laight wrote:
>> I wouldn't go that far... ;-) Unfairness is not a show-stopper right?
>> IMHO, the warning/documentation should suffice for anybody wanting to
>> try out this locking scheme for other use-cases.
>
> I presume that by 'fairness' you mean 'write preference'?
>
Yep.
> I'd not sure how difficult it would be, but maybe have two functions
> for acquiring the lock for read, one blocks if there is a writer
> waiting, the other doesn't.
>
> That way you can change the individual call sites separately.
>
Right, we could probably use that method to change the call sites in
multiple stages, in the future.
> The other place I can imagine a per-cpu rwlock being used
> is to allow a driver to disable 'sleep' or software controlled
> hardware removal while it performs a sequence of operations.
>
BTW, per-cpu rwlocks use spinlocks underneath, so they can be used only
in atomic contexts (you can't sleep holding this lock). So that would
probably make it less attractive or useless to "heavy-weight" usecases
like the latter one you mentioned. They probably need to use per-cpu
rw-semaphore or some such, which allows sleeping. I'm not very certain
of the exact usecases you are talking about, but I just wanted to
point out that percpu-rwlocks might not be applicable to many scenarios.
..(which might be a good thing, considering its unfair property today).
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* RE: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
From: David Laight @ 2013-02-19 10:42 UTC (permalink / raw)
To: Srivatsa S. Bhat, Michel Lespinasse
Cc: linux-doc, peterz, fweisbec, linux-kernel, mingo, linux-arch,
linux, xiaoguangrong, wangyun, paulmck, nikunj, linux-pm, rusty,
rostedt, rjw, namhyung, tglx, linux-arm-kernel, netdev, oleg,
vincent.guittot, sbw, tj, akpm, linuxppc-dev
In-Reply-To: <51234C23.2030909@linux.vnet.ibm.com>
> I wouldn't go that far... ;-) Unfairness is not a show-stopper right?
> IMHO, the warning/documentation should suffice for anybody wanting to
> try out this locking scheme for other use-cases.
I presume that by 'fairness' you mean 'write preference'?
I'd not sure how difficult it would be, but maybe have two functions
for acquiring the lock for read, one blocks if there is a writer
waiting, the other doesn't.
That way you can change the individual call sites separately.
The other place I can imagine a per-cpu rwlock being used
is to allow a driver to disable 'sleep' or software controlled
hardware removal while it performs a sequence of operations.
David
^ 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