-Original Message-
From: Alexey Kardashevskiy [mailto:a...@ozlabs.ru]
Sent: Tuesday, August 13, 2013 5:41 AM
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/13/2013 02:14 AM,
On 08/13/2013 08:44 PM, Bhushan Bharat-R65777 wrote:
-Original Message- From: Alexey Kardashevskiy
[mailto:a...@ozlabs.ru] Sent: Tuesday, August 13, 2013 5:41 AM To:
Bhushan Bharat-R65777 Cc: b...@kernel.crashing.org;
linuxppc-dev@lists.ozlabs.org Subject: Re: Powerpc: Kernel
-Original Message-
From: Alexey Kardashevskiy [mailto:a...@ozlabs.ru]
Sent: Tuesday, August 13, 2013 6:25 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/13/2013 08:44 PM,
Adding PowerPC list
On 13/08/13 14:00, Rafael J. Wysocki wrote:
On Monday, August 12, 2013 02:27:47 PM Sudeep KarkadaNagesha wrote:
The following changes since commit
d4e4ab86bcba5a72779c43dc1459f71fea3d89c8:
Linux 3.11-rc5 (2013-08-11 18:04:20 -0700)
are available in the git repository
On Mon, Aug 12, 2013 at 9:01 AM, Nicolin Chen b42...@freescale.com wrote:
+Required properties:
+
+ - compatible : Compatible list, contains fsl,chip-spdif. Using general
Can't we just use fsl,fsl-spdif instead?
+ fsl,fsl-spdif will get the default SoC type -- imx6q-spdif.
+
I think this
On 13/08/13 16:40, Sudeep KarkadaNagesha wrote:
Adding PowerPC list
On 13/08/13 14:00, Rafael J. Wysocki wrote:
On Monday, August 12, 2013 02:27:47 PM Sudeep KarkadaNagesha wrote:
The following changes since commit
d4e4ab86bcba5a72779c43dc1459f71fea3d89c8:
Linux 3.11-rc5 (2013-08-11
On 08/13/2013 05:40 PM, Sudeep KarkadaNagesha wrote:
Adding PowerPC list
On 13/08/13 14:00, Rafael J. Wysocki wrote:
On Monday, August 12, 2013 02:27:47 PM Sudeep KarkadaNagesha wrote:
The following changes since commit
d4e4ab86bcba5a72779c43dc1459f71fea3d89c8:
Linux 3.11-rc5 (2013-08-11
On Tue, Aug 13, 2013 at 10:40 AM, Sudeep KarkadaNagesha
sudeep.karkadanage...@arm.com wrote:
Adding PowerPC list
On 13/08/13 14:00, Rafael J. Wysocki wrote:
On Monday, August 12, 2013 02:27:47 PM Sudeep KarkadaNagesha wrote:
The following changes since commit
On Tue, Aug 13, 2013 at 2:58 PM, Fabio Estevam feste...@gmail.com wrote:
On Mon, Aug 12, 2013 at 9:01 AM, Nicolin Chen b42...@freescale.com wrote:
+Required properties:
+
+ - compatible : Compatible list, contains fsl,chip-spdif. Using general
Can't we just use fsl,fsl-spdif instead?
Or
On Tue, Aug 13, 2013 at 02:58:26PM -0300, Fabio Estevam wrote:
On Mon, Aug 12, 2013 at 9:01 AM, Nicolin Chen b42...@freescale.com wrote:
+Required properties:
+ - compatible : Compatible list, contains fsl,chip-spdif. Using
general
Can't we just use fsl,fsl-spdif instead?
It's better
On Tuesday, August 13, 2013 01:44:23 PM Rob Herring wrote:
On Tue, Aug 13, 2013 at 10:40 AM, Sudeep KarkadaNagesha
sudeep.karkadanage...@arm.com wrote:
Adding PowerPC list
On 13/08/13 14:00, Rafael J. Wysocki wrote:
On Monday, August 12, 2013 02:27:47 PM Sudeep KarkadaNagesha wrote:
On Tue, 2013-08-13 at 16:40 +0100, Sudeep KarkadaNagesha wrote:
There seems to be conflict in the new function of_get_cpu_node added.
PowerPC also defines the same function name. Further microblaze and
openrisc declares it(can be removed) but doesn't define it.
To fix this:
1. I can rename
On Tue, 2013-08-13 at 19:29 +0100, Sudeep KarkadaNagesha wrote:
I don't understand completely the use of ibm,ppc-interrupt-server#s and
its implications on generic of_get_cpu_node implementation.
I see the PPC specific definition of of_get_cpu_node uses thread id only
in 2 instances. Based on
On Tue, 2013-08-13 at 13:44 -0500, Rob Herring wrote:
It is up to Rafael if he is willing/able to rebase his tree, but I
would drop this series until this is sorted out. I think the new
common function should be and can be generalized to work for powerpc.
It would need to make reg property
On Tue, 2013-08-13 at 21:45 +0200, Rafael J. Wysocki wrote:
I'd go for 1 above personally.
Yuck no. Two functions with roughly the same name and the same purpose
differing only by an underscore just because one can't take 5mn to
reconcile the new one with the old one ? No way.
Ben.
On Thu, 2013-08-01 at 14:44 +1000, Alexey Kardashevskiy wrote:
This is to reserve a capablity number for upcoming support
of H_PUT_TCE_INDIRECT and H_STUFF_TCE pseries hypercalls
which support mulptiple DMA map/unmap operations per one call.
Gleb, any chance you can put this (and the next one)
Hi Fabio,
Thank you for the comments.
On Tue, Aug 13, 2013 at 02:58:26PM -0300, Fabio Estevam wrote:
On Mon, Aug 12, 2013 at 9:01 AM, Nicolin Chen b42...@freescale.com wrote:
+Required properties:
+
+ - compatible : Compatible list, contains fsl,chip-spdif. Using
general
Can't
On Tue, Aug 13, 2013 at 02:58:26PM -0300, Fabio Estevam wrote:
On Mon, Aug 12, 2013 at 9:01 AM, Nicolin Chen b42...@freescale.com wrote:
+Required properties:
+
+ - compatible : Compatible list, contains fsl,chip-spdif. Using
general
Can't we just use fsl,fsl-spdif instead?
+
We can use the wrapper functions platform_{get,set}_drvdata() instead of
dev_{get,set}_drvdata() with pdev-dev, it is convenient for user.
Also, unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.
changelog:
We can use the wrapper functions platform_{get,set}_drvdata() instead of
dev_{get,set}_drvdata() with ofdev-dev, it is convenient for user.
Also, unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.
unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.
Signed-off-by: Libo Chen libo.c...@huawei.com
---
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c |1 -
1 files changed, 0 insertions(+), 1
On Thu, 2013-08-08 at 17:45 -0500, Scott Wood wrote:
powerpc/e500: Update compilation flags with core specific
options
This breaks the build for my FSL test configs. For some reason gcc 4.7.3
doesn't know about -mcpu=e5500
Additionally, on 64-bit, that means one can no longer make a
Hi Shwan,
On Wed, Aug 14, 2013 at 11:27:00AM +0800, Shawn Guo wrote:
I do not think we need this general compatible string. Device tree
compatible should be specific.
So I should just use 'fsl,chip-spdif and list all chip-spdif
in compatible list?
I added 'fsl,fsl-spdif' just for those
23 matches
Mail list logo