When we have MMU on exceptions (POWER8) and a relocatable kernel, we
need to branch from the initial exception vectors at 0x0 to up high
where the kernel might be located. Currently we do this using the link
register.
Unfortunately this corrupts the link stack and instead we should use the
count
Fcc: +outbox
Subject: [PATCH v2] powerpc: Avoid link stack corruption for MMU on exceptions
In-reply-to: <20130813150617.dba639d38dad2ea41668c...@canb.auug.org.au>
References: <18522.1376360...@ale.ozlabs.ibm.com>
<20130813150617.dba639d38dad2ea41668c...@canb.auug.org.au>
Comments: In-reply-to Ste
Hi Mikey,
On Tue, 13 Aug 2013 12:20:22 +1000 Michael Neuling wrote:
>
> @@ -101,14 +102,14 @@
> * kernel, we need to use LR to get to the 2nd level handler. So,
> save/restore
^^
CTR
> * it when required.
> */
> -#define SAVE_LR(reg, area) mflrreg ; s
On Sun, Aug 11, 2013 at 11:02:28PM -0700, Sukadev Bhattiprolu wrote:
> Michael Ellerman [mich...@ellerman.id.au] wrote:
> | On Fri, 2013-08-09 at 11:24 -0700, Sukadev Bhattiprolu wrote:
> | > I am tryng to compile clean mainline kernel with a few different config
> files
> | > and running into err
When we have MMU on exceptions (POWER8) and a relocatable kernel, we
need to branch from the initial exception vectors at 0x0 to up high
where the kernel might be located. Currently we do this using the link
register.
Unfortunately this corrupts the link stack and instead we should use the
count
On 08/13/2013 02:14 AM, Bhushan Bharat-R65777 wrote:
>
>
>> -Original Message-
>> From: Alexey Kardashevskiy [mailto:a...@ozlabs.ru]
>> Sent: Monday, August 12, 2013 7:44 PM
>> To: Bhushan Bharat-R65777
>> Cc: b...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
>> Subject: Re: Powerpc
On Mon, 2013-08-12 at 13:06 +0200, Wladislav Wiebe wrote:
> Hi guys,
>
> we got the real root cause of the allocation issue:
>
> Subject: [PATCH 1/1] of: fdt: fix memory initialization for expanded DT
>
> Already existing property flags are filled wrong for properties created from
> initial FDT.
On Mon, 2013-08-12 at 16:48 +0200, Sebastian Andrzej Siewior wrote:
> From: Thomas Gleixner
>
> These low level handlers cannot be threaded. Mark them NO_THREAD
>
> Reported-by: leroy christophe
> Tested-by: leroy christophe
> Signed-off-by: Thomas Gleixner
> Signed-off-by: Sebastian Andrzej
On Mon, 12 Aug 2013 16:17:53 +0200
Sebastian Andrzej Siewior wrote:
> My gcc-4.3.5 fails to compile due to:
>
> |cc1: warnings being treated as errors
> |arch/powerpc/platforms/52xx/mpc52xx_pic.c: In function ‘mpc52xx_irqhost_map’:
> |arch/powerpc/platforms/52xx/mpc52xx_pic.c:343: error: ‘irqchi
On Tue, 2013-08-13 at 08:57 +1100, Stephen N Chivers wrote:
> Scott Wood wrote on 08/09/2013 04:07:24 AM:
>
> > From: Scott Wood
> > To: Kumar Gala
> > Cc: Stephen N Chivers , ,
> > , Chris Proctor
> > Date: 08/09/2013 04:08 AM
> > Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support
Scott Wood wrote on 08/09/2013 04:07:24 AM:
> From: Scott Wood
> To: Kumar Gala
> Cc: Stephen N Chivers , ,
> , Chris Proctor
> Date: 08/09/2013 04:08 AM
> Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for
> Motorola/Emerson MVME5100.
>
> On Thu, 2013-08-08 at 10:30 -0500, K
On Mon, 2013-08-12 at 16:25 -0500, Nathan Fontenot wrote:
> On 08/12/2013 04:13 PM, Benjamin Herrenschmidt wrote:
> > On Mon, 2013-08-12 at 08:01 -0500, Nathan Fontenot wrote:
> >>> Can you tell me a bit more, the above makes me nervous...
> >>
> >> Ok, I agree. that message isn't quite right.
> >>
The NX driver uses the transformation context to store several fields
containing data related to the state of the operations in progress.
Since a single tfm can be used by different kernel threads at the same
time, we need to protect the data stored into the context.
This patch makes use of spin l
On Mon, 2013-08-12 at 16:48 +0200, Sebastian Andrzej Siewior wrote:
> From: Thomas Gleixner
>
> These low level handlers cannot be threaded. Mark them NO_THREAD
>
> Reported-by: leroy christophe
> Tested-by: leroy christophe
> Signed-off-by: Thomas Gleixner
> Signed-off-by: Sebastian Andrzej
On 08/12/2013 04:13 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2013-08-12 at 08:01 -0500, Nathan Fontenot wrote:
>>> Can you tell me a bit more, the above makes me nervous...
>>
>> Ok, I agree. that message isn't quite right.
>>
>> What I wanted to convey is that memory hotplug is not fully suppor
On Mon, 2013-08-12 at 08:01 -0500, Nathan Fontenot wrote:
> > Can you tell me a bit more, the above makes me nervous...
>
> Ok, I agree. that message isn't quite right.
>
> What I wanted to convey is that memory hotplug is not fully supported
> on powerpc with SPARSE_VMEMMAP enabled.. Perhaps the
Kumar Gala wrote on 08/09/2013 01:30:53 AM:
> From: Kumar Gala
> To: Stephen N Chivers
> Cc: b...@kernel.crashing.org, pau...@samba.org, Chris Proctor
> , linuxppc-dev@lists.ozlabs.org
> Date: 08/09/2013 01:31 AM
> Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for
> Motorola/E
On Tue, Aug 06, 2013 at 02:11:21PM -0400, Chris Metcalf wrote:
> This change improves and cleans up the tile console.
>
> - We enable HVC_IRQ support on tilegx, with the addition of a new
> Tilera hypervisor API for tilegx to allow a console IPI. If IPI
> support is not available we fall back
On Tue, Aug 06, 2013 at 10:44:03PM +0200, Gerhard Sittig wrote:
> prepare and enable the FIFO clock upon PSC FIFO initialization,
> check for and propagage errors when enabling the PSC FIFO clock,
> disable and unprepare the FIFO clock upon PSC FIFO uninitialization,
> remove the pre-enable workaro
On Tue, Aug 06, 2013 at 10:44:01PM +0200, Gerhard Sittig wrote:
> after device tree based clock lookup became available, the peripheral
> driver need no longer construct clock names which include the PSC index,
> remove the "psc%d_mclk" template and unconditionally use 'mclk'
>
> acquire and relea
On Tue, Aug 06, 2013 at 10:43:42PM +0200, Gerhard Sittig wrote:
> cleanup the clock API use of the UART driver which is shared among the
> MPC512x and the MPC5200 platforms
> - get, prepare, and enable the MCLK during port allocation; disable,
> unprepare and put the MCLK upon port release; hold
On 08/12/2013 05:24 PM, Libo Chen wrote:
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen
---
.../net/ethernet/freesca
> -Original Message-
> From: Wood Scott-B07421
> Sent: Saturday, August 10, 2013 6:35 AM
> To: Bhushan Bharat-R65777
> Cc: b...@kernel.crashing.org; ag...@suse.de; pau...@samba.org;
> k...@vger.kernel.org; kvm-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> Bhushan Bharat-R65777
> S
On Sun, Aug 11, 2013 at 7:32 PM, Benjamin Herrenschmidt
wrote:
> Do that help with e1000 as well ? IE. A bad clock might have caused
> malfunctions of the DMA for example...
No, it didn't help with the e1000. In fact, we have separate clocks
for the on-board components. This particular case was
> -Original Message-
> From: Bhushan Bharat-R65777
> Sent: Monday, August 12, 2013 9:45 PM
> To: 'Alexey Kardashevskiy'
> Cc: b...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
> Subject: RE: Powerpc: Kernel warn_on when enabling IOMMU_API
>
>
>
> > -Original Message-
> >
On Mon, 2013-08-12 at 10:46 +0800, Zhang Haijun wrote:
> On 08/09/2013 10:48 PM, Kumar Gala wrote:
>
> > On Jul 31, 2013, at 1:25 AM, Haijun Zhang wrote:
> >
> > > Add function to support get voltage from device-tree.
> > > If there are voltage-range specified in device-tree node, this function
>
> -Original Message-
> From: Alexey Kardashevskiy [mailto:a...@ozlabs.ru]
> Sent: Monday, August 12, 2013 7:44 PM
> To: Bhushan Bharat-R65777
> Cc: b...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: Powerpc: Kernel warn_on when enabling IOMMU_API
>
> On 08/12/2013 08:
From: Thomas Gleixner
These low level handlers cannot be threaded. Mark them NO_THREAD
Reported-by: leroy christophe
Tested-by: leroy christophe
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
This patch has been posted on Feb 13, 2013 and nobody responded back t
My gcc-4.3.5 fails to compile due to:
|cc1: warnings being treated as errors
|arch/powerpc/platforms/52xx/mpc52xx_pic.c: In function ‘mpc52xx_irqhost_map’:
|arch/powerpc/platforms/52xx/mpc52xx_pic.c:343: error: ‘irqchip’ may be used
uninitialized in this function
since commit e34298c ("powerpc:
On 08/12/2013 08:20 PM, Bhushan Bharat-R65777 wrote:
> And this simple fix work for me
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index b20ff17..8869b0d 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -48,6 +48,8 @@
> #include
>
Hello everyone!
2013/7/14 Gerhard Sittig :
> @@ -50,9 +50,23 @@
> #define MPC_DMA_DESCRIPTORS64
>
> /* Macro definitions */
> -#define MPC_DMA_CHANNELS 64
> #define MPC_DMA_TCD_OFFSET 0x1000
>
> +/*
> + * the maximum channel count, and specific channels which need
> + * special pr
Hello everyone!
Changes offered in this letter:
- Adding a flag "will_access_peripheral" to DMA transfer descriptor
according recommendations of Gerhard Sittig.
This flag is set in mpc_dma_prep_memcpy() and mpc_dma_prep_slave_sg()
and is evaluated in mpc_dma_execute().
- Adding locking and remov
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Libo Chen (8):
net: fsl_pq_mdio: use platform_{get,set}_drvdata()
net: ucc_geth: use platform_{g
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen
---
.../net/ethernet/freescale/fs_enet/fs_enet-main.c |1 -
1 files ch
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen
---
drivers/net/ethernet/freescale/ucc_geth.c |4 +---
1 files changed,
On 08/11/2013 07:19 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2013-08-09 at 10:32 -0500, Nathan Fontenot wrote:
>
>> +void register_page_bootmem_memmap(unsigned long section_nr,
>> + struct page *start_page, unsigned long size)
>> +{
>> +WARN_ONCE(1, KERN_INFO
>>
So far "/sys/devices/system/cpu/cpuX/topology/physical_package_id"
was always default (-1) on ppc64 architecture.
Now, some systems have an ibm,chip-id property in the cpu nodes in
the device tree. On these systems, we now use this information to
display physical_package_id.
Signed-off-by: Vasant
Add S/PDIF machine driver for Freescale i.MX series SoC.
Signed-off-by: Nicolin Chen
---
.../devicetree/bindings/sound/imx-audio-spdif.txt | 29 +
sound/soc/fsl/Kconfig | 11 ++
sound/soc/fsl/Makefile |2 +
sound/soc/fsl/imx-s
This patch add S/PDIF controller driver for Freescale SoC.
Signed-off-by: Nicolin Chen
---
.../devicetree/bindings/sound/fsl,spdif.txt| 100 ++
sound/soc/fsl/Kconfig |3 +
sound/soc/fsl/Makefile |2 +
sound/soc/fsl/fsl_spd
Changelog:
v3->v4:
* Use regmap for CPU DAI driver.
* Use individual clock source for 32KHz, 44KHz, 48KHz playback.
* Determine clock source configuration from 'clocks' entry.
* Added imx53 to compatible list, merged imx6q and imx6dl in the list.
* Improve the algorism of reverse_bits().
* Dr
Changelog:
v3->v4:
* Use regmap for CPU DAI driver.
* Use individual clock source for 32KHz, 44KHz, 48KHz playback.
* Determine clock source configuration from 'clocks' entry.
* Added imx53 to compatible list, merged imx6q and imx6dl in the list.
* Improve the algorism of reverse_bits().
* Dr
This patch add S/PDIF controller driver for Freescale SoC.
Signed-off-by: Nicolin Chen
---
.../devicetree/bindings/sound/fsl,spdif.txt| 100 ++
sound/soc/fsl/Kconfig |3 +
sound/soc/fsl/Makefile |2 +
sound/soc/fsl/fsl_spd
Add S/PDIF machine driver for Freescale i.MX series SoC.
Signed-off-by: Nicolin Chen
---
.../devicetree/bindings/sound/imx-audio-spdif.txt | 29 +
sound/soc/fsl/Kconfig | 11 ++
sound/soc/fsl/Makefile |2 +
sound/soc/fsl/imx-s
Hi guys,
we got the real root cause of the allocation issue:
Subject: [PATCH 1/1] of: fdt: fix memory initialization for expanded DT
Already existing property flags are filled wrong for properties created from
initial FDT. This could cause problems if this DYNAMIC device-tree functions
are used
Hi Alexey/Ben,
When I enable the IOMMU_API then I get warn_on in arch/powerpc/kernel/iommu.c
(here is the code snapshot)
{
1110 static int iommu_add_device(struct device *dev)
{
1112 struct iommu_table *tbl;
1113 int ret = 0;
1114
1115 if (WARN_ON(dev->iommu_group))
On Thu, Aug 08, 2013 at 22:12 +0200, Anatolij Gustschin wrote:
>
> On Tue, 6 Aug 2013 22:43:49 +0200
> Gerhard Sittig wrote:
> ...
> > diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
> > index 46ac1dd..549ff08 100644
> > --- a/arch/powerpc/sysdev/fsl_pci.c
> > +++ b/ar
On 08/12/2013 11:59 AM, Paul Mackerras wrote:
Some systems have an ibm,chip-id property in the cpu nodes in the
device tree. On these systems, we now use that to compute the
cpu_core_mask (i.e. the set of core siblings) rather than looking
at cache properties.
Looks fine.
Tested-by: Vasant He
47 matches
Mail list logo
