* [PATCH] powerpc/fsl_lbc: Increase the number of possible lbc banks
From: mware @ 2009-06-11 3:01 UTC (permalink / raw)
To: linuxppc-dev
Currently the fsl,*lbc devices support 8 banks (ie OR and BR registers).
This is adequate for most pq2 and pq3 processors, but not the MPC8280 which
has 12 banks.
Signed-Off-By: Mark Ware <mware@elphinstone.net>
---
arch/powerpc/include/asm/fsl_lbc.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_lbc.h b/arch/powerpc/include/asm/=
fsl_lbc.h
index 63a4f77..1b5a210 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -95,8 +95,8 @@ struct fsl_lbc_bank {
};
struct fsl_lbc_regs {
- struct fsl_lbc_bank bank[8];
- u8 res0[0x28];
+ struct fsl_lbc_bank bank[12];
+ u8 res0[0x8];
__be32 mar; /**< UPM Address Register */
u8 res1[0x4];
__be32 mamr; /**< UPMA Mode Register */
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] powerpc/boot: cuboot: Fix up ethernet3 MAC address on MPC85xx
From: Kumar Gala @ 2009-06-11 2:54 UTC (permalink / raw)
To: Nate Case; +Cc: linuxppc-dev
In-Reply-To: <1244499462-18719-1-git-send-email-ncase@xes-inc.com>
On Jun 8, 2009, at 5:17 PM, Nate Case wrote:
> MPC85xx platforms do support 4 ethernet ports, so make sure the boot
> wrapper fixes up all of them in the fdt.
>
> Signed-off-by: Nate Case <ncase@xes-inc.com>
> ---
> arch/powerpc/boot/cuboot-85xx.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/cuboot-85xx.c b/arch/powerpc/boot/
> cuboot-85xx.c
> index 6776a1a..277ba4a 100644
> --- a/arch/powerpc/boot/cuboot-85xx.c
> +++ b/arch/powerpc/boot/cuboot-85xx.c
> @@ -15,6 +15,7 @@
> #include "cuboot.h"
>
> #define TARGET_85xx
> +#define TARGET_HAS_ETH3
This is problematic in that we'd be changing the memory layout of the
bd_t and not ALL 85xx's have HAS_ETH3 set.
- k
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Kumar Gala @ 2009-06-11 2:45 UTC (permalink / raw)
To: Dan Williams
Cc: David Hawkins, Ira Snyder, Liu Dave-R63238, linux-kernel,
linuxppc-dev, Timur Tabi
In-Reply-To: <e9c3a7c20904271349m134ff7f2s9d7901015454cf3d@mail.gmail.com>
On Apr 27, 2009, at 3:49 PM, Dan Williams wrote:
> On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com>
> wrote:
>> Adding Kumar to the CC: list, since he might pick up the patch.
>>
>
> Acked-by: Dan Williams <dan.j.williams@intel.com>
>
> I agree with taking this through Kumar's tree.
I'm going through patches for .31.. Should I still pick this up?
Going forward should I pick up fsldma patches?
- k
^ permalink raw reply
* Re: [PATCH] powerpc: minimizing the configuration of linkstation_defconfig
From: Kumar Gala @ 2009-06-11 2:46 UTC (permalink / raw)
To: Rogério Brito; +Cc: linuxppc-dev, Guennadi Liakhovetski, linux-kernel
In-Reply-To: <20090516160453.GA15138@ime.usp.br>
On May 16, 2009, at 11:04 AM, Rog=E9rio Brito wrote:
> Hi, Kumar, Guennadi, and Co.
>
>
> This patch addresses the following issues:
>
> 01. makes CFQ the default scheduler, to be in line with the rest of
> the kernel.
>
> 02. since linkstations are meant to store files, enable large blk
> devices.
>
> 03. disable CONFIG_MIGRATION in in such low memory devices.
>
> 04. disable CONFIG_BLK_DEV_RAM.
>
> 05. disable CONFIG_SCSI_LOWLEVEL, as no device under that tree is
> used.
>
> 06. idem for CONFIG_NETDEV_10000.
>
> 07. idem for CONFIG_WIRELESS.
>
> 08. idem for CONFIG_HWMON.
>
> 09. idem for CONFIG_CRYPTO_HW.
>
> 10. disable CONFIG_VIDEO_OUTPUT_CONTROL.
>
> 11. keep consistency and disable extended attributes in CIFS, ext3,
> and NFS.
>
> 12. enable CONFIG_PRINTK_TIME.
>
> Signed-off-by: Rog=E9rio Brito <rbrito@ime.usp.br>
>
> ---
>
> This is the patch for tidying the defconfig. I'm still having issues
> with the MTD devices, it seems. :-( I will investigate this now.
>
> I can send a similar patch to storcenter.
Did you ever resolve the MTD issue?
- k=
^ permalink raw reply
* Re: [PATCH v2] 83xx: add support for the kmeter1 board.
From: Kumar Gala @ 2009-06-11 2:43 UTC (permalink / raw)
To: hs; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <49F7DC0C.3080409@denx.de>
On Apr 28, 2009, at 11:48 PM, Heiko Schocher wrote:
> The following series implements basic board support for
> the kmeter1 board from keymile, based on a MPC8360.
>
> This series provides the following functionality:
>
> - The board can boot with a serial console on UART1
> - Ethernet:
> UCC1 in RGMII mode
> UCC2 in RGMII mode
> UCC4 in RMII mode
> UCC5 in RMII mode
> UCC6 in RMII mode
> UCC7 in RMII mode
> UCC8 in RMII mode
>
> following patch is necessary for working UCC in RMII mode:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070909.html
>
> - Flash accessed via MTD layer
>
> On this hardware there is an Intel P30 flash, following patch
> series is necessary for working with this hardware:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070716.html
>
> - I2C using I2C Bus 1 from the MPC8360 cpu
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> ---
> changes since v1:
> - added comments from Kumar Gala and Scott Wood
> - get rid of using get_immrbase() in board specific code
>
> $ ./scripts/checkpatch.pl 0001--Patch-v2-83xx-add-support-for-the-
> kmeter1-board.patch
> total: 0 errors, 0 warnings, 1626 lines checked
>
> 0001--Patch-v2-83xx-add-support-for-the-kmeter1-board.patch has no
> obvious style problems and is ready for submission.
>
> arch/powerpc/boot/dts/kmeter1.dts | 513 +++++++++++++++
> arch/powerpc/configs/83xx/kmeter1_defconfig | 908 ++++++++++++++++++
> +++++++++
> arch/powerpc/platforms/83xx/Kconfig | 7 +
> arch/powerpc/platforms/83xx/Makefile | 1 +
> arch/powerpc/platforms/83xx/kmeter1.c | 188 ++++++
> 5 files changed, 1617 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/kmeter1.dts
> create mode 100644 arch/powerpc/configs/83xx/kmeter1_defconfig
> create mode 100644 arch/powerpc/platforms/83xx/kmeter1.c
>
> diff --git a/arch/powerpc/boot/dts/kmeter1.dts b/arch/powerpc/boot/
> dts/kmeter1.dts
> new file mode 100644
> index 0000000..63c27da
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/kmeter1.dts
> @@ -0,0 +1,513 @@
> +/*
> + * Keymile KMETER1 Device Tree Source
> + *
> + * 2008 DENX Software Engineering GmbH
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + model = "KMETER1";
> + compatible = "keymile,KMETER1";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + aliases {
> + ethernet0 = &enet_piggy2;
> + ethernet1 = &enet_estar1;
> + ethernet2 = &enet_estar2;
> + ethernet3 = &enet_eth1;
> + ethernet4 = &enet_eth2;
> + ethernet5 = &enet_eth3;
> + ethernet6 = &enet_eth4;
> + serial0 = &serial0;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,8360@0 {
> + device_type = "cpu";
> + reg = <0x0>;
> + d-cache-line-size = <32>; // 32 bytes
> + i-cache-line-size = <32>; // 32 bytes
> + d-cache-size = <32768>; // L1, 32K
> + i-cache-size = <32768>; // L1, 32K
> + timebase-frequency = <0>; /* Filled in by U-Boot */
> + bus-frequency = <0>; /* Filled in by U-Boot */
> + clock-frequency = <0>; /* Filled in by U-Boot */
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0 0>; /* Filled in by U-Boot */
> + };
> +
> + soc8360@e0000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + compatible = "simple-bus";
this should be:
compatible = "fsl,mpc8360-immr", "simple-bus";
>
> + ranges = <0x0 0xe0000000 0x00200000>;
> + reg = <0xe0000000 0x00000200>;
> + bus-frequency = <0>; /* Filled in by U-Boot */
> +
>
> + ipic: pic@700 {
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + compatible = "fsl,pq2pro-pic", "fsl,ipic";
> + interrupt-controller;
> + reg = <0x700 0x100>;
> + device_type = "ipic";
drop the device_type.
>
> + };
> +
> + qe@100000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "qe";
> + compatible = "fsl,qe";
> + ranges = <0x0 0x100000 0x100000>;
> + reg = <0x100000 0x480>;
> + clock-frequency = <0>; /* Filled in by U-Boot */
> + brg-frequency = <0>; /* Filled in by U-Boot */
> + bus-frequency = <0>; /* Filled in by U-Boot */
> +
> +
> +
> + mdio@3320 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x3320 0x18>;
> + compatible = "fsl,ucc-mdio";
> +
> + /* Piggy2 (UCC4, MDIO 0x00, RMII) */
> + phy_piggy2: ethernet-phy@00 {
> + reg = <0x0>;
> + device_type = "ethernet-phy";
drop the device_type (and the one's below)
>
> + };
> +
> + /* Eth-1 (UCC5, MDIO 0x08, RMII) */
> + phy_eth1: ethernet-phy@08 {
> + reg = <0x08>;
> + device_type = "ethernet-phy";
> + };
> +
> + /* Eth-2 (UCC6, MDIO 0x09, RMII) */
> + phy_eth2: ethernet-phy@09 {
> + reg = <0x09>;
> + device_type = "ethernet-phy";
> + };
> +
> + /* Eth-3 (UCC7, MDIO 0x0a, RMII) */
> + phy_eth3: ethernet-phy@0a {
> + reg = <0x0a>;
> + device_type = "ethernet-phy";
> + };
> +
> + /* Eth-4 (UCC8, MDIO 0x0b, RMII) */
> + phy_eth4: ethernet-phy@0b {
> + reg = <0x0b>;
> + device_type = "ethernet-phy";
> + };
> +
> + /* ESTAR-1 (UCC1, MDIO 0x10, RGMII) */
> + phy_estar1: ethernet-phy@10 {
> + interrupt-parent = <&ipic>;
> + interrupts = <17 0x8>;
> + reg = <0x10>;
> + device_type = "ethernet-phy";
> + };
> +
> + /* ESTAR-2 (UCC2, MDIO 0x11, RGMII) */
> + phy_estar2: ethernet-phy@11 {
> + interrupt-parent = <&ipic>;
> + interrupts = <18 0x8>;
> + reg = <0x11>;
> + device_type = "ethernet-phy";
> + };
> + };
> +
> + qeic: interrupt-controller@80 {
> + interrupt-controller;
> + compatible = "fsl,qe-ic";
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + reg = <0x80 0x80>;
> + interrupts = <32 8 33 8>;
> + interrupt-parent = <&ipic>;
> + };
> + };
> + };
> +
> + localbus@e0005000 {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc8360-localbus", "fsl,pq2pro-localbus",
> + "simple-bus";
> + reg = <0xe0005000 0xd8>;
> + ranges = <0 0 0xf0000000 0x04000000>; /* Filled in by U-Boot */
> +
> + flash@f0000000,0 {
> + compatible = "cfi-flash";
> + /*
> + * The Intel P30 chip has 2 non-identical chips on
> + * one die, so we need to define 2 seperate regions
> + * that are scanned by physmap_of independantly.
> + */
> + reg = <0 0x00000000 0x02000000
> + 0 0x02000000 0x02000000>; /* Filled in by U-Boot */
> + bank-width = <2>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + label = "u-boot";
> + reg = <0 0x40000>;
> + };
> + partition@40000 {
> + label = "env";
> + reg = <0x40000 0x40000>;
> + };
> + partition@80000 {
> + label = "dtb";
> + reg = <0x80000 0x20000>;
> + };
> + partition@a0000 {
> + label = "kernel";
> + reg = <0xa0000 0x300000>;
> + };
> + partition@3a0000 {
> + label = "ramdisk";
> + reg = <0x3a0000 0x800000>;
> + };
> + partition@ba0000 {
> + label = "user";
> + reg = <0xba0000 0x3460000>;
> + };
> + };
> + };
> +};
Sorry for taking so long to review this again.
- k
^ permalink raw reply
* Re: [PATCH] Re:[BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Nathan Lynch @ 2009-06-11 2:28 UTC (permalink / raw)
To: subrata
Cc: Sachin P Sant, Stephen Rothwell, netdev, Linux-Kernel,
Linuxppc-dev, Linux-Next, Li Yang, Balbir Singh
In-Reply-To: <1244685364.6494.14.camel@subratamodak.linux.ibm.com>
Subrata Modak <subrata@linux.vnet.ibm.com> writes:
> On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
>> Hi Subrata,
>>=20
>> On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm=
.com> wrote:
>> >
>> > /* Find the TBI PHY. If it's not there, we don't support SGMII */
>> > - ph =3D of_get_property(np, "tbi-handle", NULL);
>> > + ph =3D (phandle *)of_get_property(np, "tbi-handle", NULL);
>>=20
>> You don't need this cast because of_get_property() returns "void *".
>
> Stephen,
>
> True. But without this gcc complains:
>
> CC [M] drivers/net/ucc_geth.o
> drivers/net/ucc_geth.c: In function =E2=80=98ucc_geth_probe=E2=80=99:
> drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers
> from pointer target type
ph should be declared const phandle *. Look at other uses of
of_get_property.
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: add nor flash partitions for mpc8569mds
From: Kumar Gala @ 2009-06-11 2:20 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc-dev, Haiying Wang
In-Reply-To: <1243389905.13410.6.camel@kevin>
On May 26, 2009, at 9:05 PM, Kevin Hao wrote:
> Add 4 partitions in nor flash. Also fix nor flash
> bank width bug.
Can you explain this.. I'm trying to understand why you set the bank-
width to 1
- k
>
>
> Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
> ---
> arch/powerpc/boot/dts/mpc8569mds.dts | 24 +++++++++++++++++++++++-
> 1 files changed, 23 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8569mds.dts b/arch/powerpc/
> boot/dts/mpc8569mds.dts
> index 39c2927..1f98990 100644
> --- a/arch/powerpc/boot/dts/mpc8569mds.dts
> +++ b/arch/powerpc/boot/dts/mpc8569mds.dts
> @@ -70,8 +70,30 @@
> #size-cells = <1>;
> compatible = "cfi-flash";
> reg = <0x0 0x0 0x02000000>;
> - bank-width = <2>;
> + bank-width = <1>;
> device-width = <1>;
> + partition@0 {
> + label = "ramdisk";
> + reg = <0x00000000 0x01c00000>;
> + };
> + partition@1c00000 {
> + label = "kernel";
> + reg = <0x01c00000 0x002e0000>;
> + };
> + partiton@1ee0000 {
> + label = "dtb";
> + reg = <0x01ee0000 0x00020000>;
> + };
> + partition@1f00000 {
> + label = "firmware";
> + reg = <0x01f00000 0x00080000>;
> + read-only;
> + };
> + partition@1f80000 {
> + label = "u-boot";
> + reg = <0x01f80000 0x00080000>;
> + read-only;
> + };
> };
>
> bcsr@1,0 {
> --
> 1.6.0.4.771.gef3b3
^ permalink raw reply
* Re: [PATCH] Re:[BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Tony Breeds @ 2009-06-11 2:22 UTC (permalink / raw)
To: Subrata Modak
Cc: Sachin P Sant, Stephen Rothwell, netdev, Linux-Kernel,
Linuxppc-dev, Linux-Next, Li Yang, Balbir Singh
In-Reply-To: <1244685364.6494.14.camel@subratamodak.linux.ibm.com>
On Thu, Jun 11, 2009 at 07:26:04AM +0530, Subrata Modak wrote:
> On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
> > Hi Subrata,
> >
> > On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm.com> wrote:
> > >
> > > /* Find the TBI PHY. If it's not there, we don't support SGMII */
> > > - ph = of_get_property(np, "tbi-handle", NULL);
> > > + ph = (phandle *)of_get_property(np, "tbi-handle", NULL);
> >
> > You don't need this cast because of_get_property() returns "void *".
>
> Stephen,
>
> True. But without this gcc complains:
>
> CC [M] drivers/net/ucc_geth.o
> drivers/net/ucc_geth.c: In function ‘ucc_geth_probe’:
> drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers
> from pointer target type
>
> Else gcc just builds fine:
>
> CC [M] drivers/net/ucc_geth.o
>
> This is an just an extra caution to fix both the build and warning
> regression(s).
ph needs to be const.
I think the following untested (and hence un-signed-off-by) patch is closer,
however I also think that the whole SGMII setup code could use the various OF
helper functions better :)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index e2f2e91..796253d 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3603,6 +3603,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
struct resource res;
struct device_node *phy;
int err, ucc_num, max_speed = 0;
+ const phandle *ph;
const u32 *fixed_link;
const unsigned int *prop;
const char *sprop;
@@ -3821,7 +3822,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
/* Find the TBI PHY. If it's not there, we don't support SGMII */
ph = of_get_property(np, "tbi-handle", NULL);
if (ph) {
- struct device_node *tbi = of_find_node_by_phandle(*ph);
+ struct device_node *tbi = of_find_node_by_phandle(*ph), *mdio;
struct of_device *ofdev;
struct mii_bus *bus;
const unsigned int *id;
Yours Tony
^ permalink raw reply related
* [PATCH][Resend][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Subrata Modak @ 2009-06-11 2:13 UTC (permalink / raw)
To: michael, netdev, Li Yang, Stephen Rothwell
Cc: Sachin P Sant, Linux-Kernel, Linuxppc-dev, Linux-Next,
Subrata Modak, Balbir Singh
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2274 bytes --]
Hi Michael,
>On Thu, 2009-06-11 at 12:03 +1000, Michael Ellerman wrote:
>On Thu, 2009-06-11 at 07:26 +0530, Subrata Modak wrote:
> > On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
> > > Hi Subrata,
> > >
> > > On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm.com> wrote:
> > > >
> > > > /* Find the TBI PHY. If it's not there, we don't support SGMII */
> > > > - ph = of_get_property(np, "tbi-handle", NULL);
> > > > + ph = (phandle *)of_get_property(np, "tbi-handle", NULL);
> > >
> > > You don't need this cast because of_get_property() returns "void *".
> >
> > Stephen,
> >
> > True. But without this gcc complains:
> >
> > CC [M] drivers/net/ucc_geth.o
> > drivers/net/ucc_geth.c: In function ‘ucc_geth_probe’:
> > drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers from pointer target type
> ^^^^^^^^^^^
>
> And what does that warning actually mean?
>
> Your cast actually introduces a bug.
>
Ok fine. Here is a revised patch.
Subject: [PATCH][Resend][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
Reference(s):
http://lkml.org/lkml/2009/6/4/241,
http://lkml.org/lkml/2009/6/10/338,
Fix the following build error:
drivers/net/ucc_geth.c: In function bucc_geth_probeb:
drivers/net/ucc_geth.c:3822: error: 'ph' undeclared (first use in this function)
drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is reported only once
drivers/net/ucc_geth.c:3822: error: for each function it appears in.)
drivers/net/ucc_geth.c:3832: error: 'mdio' undeclared (first use in this function)
make[2]: *** [drivers/net/ucc_geth.o] Error 1
Signed-off-by: Subrata Modak <subrata@linux.vnet.ibm.com>
---
--- linux-2.6.30-rc8/drivers/net/ucc_geth.c.orig 2009-06-10 11:58:39.000000000 -0500
+++ linux-2.6.30-rc8/drivers/net/ucc_geth.c 2009-06-10 20:53:25.000000000 -0500
@@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *match)
{
+ struct device_node *mdio;
+ phandle *ph;
struct device *device = &ofdev->dev;
struct device_node *np = ofdev->node;
struct net_device *dev = NULL;
---
Regards--
Subrata
> cheers
^ permalink raw reply
* Re: [PATCH] Re:[BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Michael Ellerman @ 2009-06-11 2:03 UTC (permalink / raw)
To: subrata
Cc: Sachin P Sant, Stephen Rothwell, netdev, Linux-Kernel,
Linuxppc-dev, Linux-Next, Li Yang, Balbir Singh
In-Reply-To: <1244685364.6494.14.camel@subratamodak.linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 940 bytes --]
On Thu, 2009-06-11 at 07:26 +0530, Subrata Modak wrote:
> On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
> > Hi Subrata,
> >
> > On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm.com> wrote:
> > >
> > > /* Find the TBI PHY. If it's not there, we don't support SGMII */
> > > - ph = of_get_property(np, "tbi-handle", NULL);
> > > + ph = (phandle *)of_get_property(np, "tbi-handle", NULL);
> >
> > You don't need this cast because of_get_property() returns "void *".
>
> Stephen,
>
> True. But without this gcc complains:
>
> CC [M] drivers/net/ucc_geth.o
> drivers/net/ucc_geth.c: In function ‘ucc_geth_probe’:
> drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers from pointer target type
^^^^^^^^^^^
And what does that warning actually mean?
Your cast actually introduces a bug.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 00/33] My PS3-specific patches for 2.6.31
From: Michael Ellerman @ 2009-06-11 2:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Gary Thomas
In-Reply-To: <1244684128.5739.30.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]
On Thu, 2009-06-11 at 11:35 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-06-11 at 11:32 +1000, Michael Ellerman wrote:
> > The way I think of it is that the "merge window" is the time for
> > maintainers to merge with Linus.
> >
> > So if you're sending patches to a maintainer you need to have sent all
> > your patches to them _before_ then. So the merge window for you is the
> > weeks prior to the "merge window".
>
> Right. But a patch generally needs time to be reviewed, spun several
> times, etc... so just the week before the merge window is probably too
> late :-)
Sure. I mean that's when you should be sending polished code that's
ready to merge. In the same way that the maintainers are sending
polished ready to merge code to Linus during the merge window.
But absolutely, most patches need to be reviewed at least once before
they're ready, which is probably a week at best.
But really people should just be sending patches ASAP, even if they're
not 100% finished, so they get as much exposure as early as possible.
Sitting on patches waiting for the "right time" to send them is the
wrong approach IMHO.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Re:[BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Subrata Modak @ 2009-06-11 1:56 UTC (permalink / raw)
To: Stephen Rothwell, netdev, Li Yang
Cc: Sachin P Sant, Linuxppc-dev, Linux-Next, Linux-Kernel,
Balbir Singh
In-Reply-To: <20090611110523.1fd56a41.sfr@canb.auug.org.au>
On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
> Hi Subrata,
>
> On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm.com> wrote:
> >
> > /* Find the TBI PHY. If it's not there, we don't support SGMII */
> > - ph = of_get_property(np, "tbi-handle", NULL);
> > + ph = (phandle *)of_get_property(np, "tbi-handle", NULL);
>
> You don't need this cast because of_get_property() returns "void *".
Stephen,
True. But without this gcc complains:
CC [M] drivers/net/ucc_geth.o
drivers/net/ucc_geth.c: In function ‘ucc_geth_probe’:
drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers
from pointer target type
Else gcc just builds fine:
CC [M] drivers/net/ucc_geth.o
This is an just an extra caution to fix both the build and warning
regression(s).
Regards--
Subrata
>
^ permalink raw reply
* Re: [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash size
From: Kumar Gala @ 2009-06-11 1:51 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Scott Wood, linuxppc-dev, linux-kernel
In-Reply-To: <1242155174-2513-1-git-send-email-wd@denx.de>
On May 12, 2009, at 2:06 PM, Wolfgang Denk wrote:
> The current device tree for the MPC8272ADS assumes a mapping of 32 MB
> of NOR flash at 0xFE00.0000, while there are actually only 8 MB on
> the boards, mapped at 0xFF80.0000. When booting an uImage with such a
> device tree, the kernel crashes because 0xFE00.0000 is not mapped.
>
> Also introduce aliases for serial[01] and ethernet[01].
>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Scott Wood <scottwood@freescale.com>
> cc: Kumar Gala <galak@kernel.crashing.org>
> ---
> I am not really sure what the typical flash size on MPC8272ADS boards
> is. The board I used for testing is marked as "Prototype", so it may
> not be the release configuration. On the other hand, the manual also
> says 8 MB, Vitaly Borduk confirms 8 MB on his board, too, and Scott
> Wood eventually tested only with cuImage which fixes up the localbus
> mappings, thus eventually concealing the issue.
>
> I'm posting this as reference in case the 8 MB should turn out to be
> correct. -- wd
>
> arch/powerpc/boot/dts/mpc8272ads.dts | 19 +++++++++++++------
> 1 files changed, 13 insertions(+), 6 deletions(-)
applied to next.
- k
^ permalink raw reply
* Re: [PATCH 4/4] MPC85xx: Add UCC6 and UCC8 nodes in SGMII mode for MPC8569MDS
From: Kumar Gala @ 2009-06-11 1:51 UTC (permalink / raw)
To: Haiying Wang; +Cc: linuxppc-dev, davem, netdev
In-Reply-To: <1243951456-4685-4-git-send-email-Haiying.Wang@freescale.com>
On Jun 2, 2009, at 9:04 AM, Haiying Wang wrote:
> Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8569mds.dts | 63 +++++++++++++++++++++++++
> +++++++++
> 1 files changed, 63 insertions(+), 0 deletions(-)
applied to next.
- k
^ permalink raw reply
* Re: [PATCH] powerpc/83xx: Update sdhci nodes per new bindings
From: Kumar Gala @ 2009-06-11 1:51 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20090610151926.GA32386@oksana.dev.rtsoft.ru>
On Jun 10, 2009, at 10:19 AM, Anton Vorontsov wrote:
> As of commit 404614728f857d0ac63d29c3a29d0cf392a15598 ("Update FSL
> esdhc binding"), we use "fsl,esdhc" compatible entry as a base
> match. U-Boot will use the same compatible to fixup esdhc nodes.
>
> This patch updates 83xx dts files so that they conform to the new
> bindings.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc8377_mds.dts | 2 +-
> arch/powerpc/boot/dts/mpc8377_rdb.dts | 2 +-
> arch/powerpc/boot/dts/mpc8378_mds.dts | 2 +-
> arch/powerpc/boot/dts/mpc8378_rdb.dts | 2 +-
> arch/powerpc/boot/dts/mpc8379_mds.dts | 2 +-
> arch/powerpc/boot/dts/mpc8379_rdb.dts | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
applied to next.
- k
^ permalink raw reply
* Re: [PATCH] powerpc/86xx: Add I2C device mappings in DTS for SBC610
From: Kumar Gala @ 2009-06-11 1:50 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev
In-Reply-To: <20090519094057.11438.12921.stgit@ES-J7S4D2J>
On May 19, 2009, at 4:40 AM, Martyn Welch wrote:
> Mappings for temperature sensors (adt7461 and lm92) are missing from
> the
> SBC610's DTS file.
>
> Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
> ---
>
> arch/powerpc/boot/dts/gef_sbc610.dts | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
applied to next.
- k
^ permalink raw reply
* Re: [PATCH v2] Add MSI interrupts to DTS of MPC8315E-RDB
From: Kumar Gala @ 2009-06-11 1:50 UTC (permalink / raw)
To: leon.woestenberg; +Cc: Leon Woestenberg, linux-kernel, linuxppc-dev
In-Reply-To: <4a2a9611.06c8100a.49ae.ffff88e4@mx.google.com>
On Jun 6, 2009, at 11:15 AM, leon.woestenberg@gmail.com wrote:
> The PCIe MSI interrupts are missing from the device tree source, and
> thus were not enabled. This patch adds them.
>
> v2 of the patch fixes inconsistent white space, reported by David
> Gibson.
>
> Tested to work on MPC8315E-RDB with custom FPGA PCIe device.
>
> Signed-off-by: Leon Woestenberg <leon@sidebranch.com>
> Tested-by: Leon Woestenberg <leon@sidebranch.com>
applied to next.
- k
^ permalink raw reply
* linux-next: powerpc tree build warning
From: Stephen Rothwell @ 2009-06-11 1:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-next, Paul Mackerras, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 373 bytes --]
Hi Ben,
Today's linux-next build (powerpc ppc64_defconfig) produced this warning:
arch/powerpc/platforms/Kconfig.cputype:60:warning: defaults for choice values not supported
We appear to have CONFIG_PPC_BOOK3S int two places which is confusing
Kconfig.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] MPC85xx: Add UCC6 and UCC8 nodes in SGMII mode for MPC8569MDS
From: Kumar Gala @ 2009-06-11 1:35 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, netdev, Haiying.Wang
In-Reply-To: <20090603.035132.157926180.davem@davemloft.net>
On Jun 3, 2009, at 5:51 AM, David Miller wrote:
> From: Haiying Wang <Haiying.Wang@freescale.com>
> Date: Tue, 2 Jun 2009 10:04:16 -0400
>
>> Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
>
> I couldn't apply this to net-next-2.6 because this DTS
> file being patched doesn't exist there.
>
> Perhaps the powerpc-next tree can suck it in...
I'll pick this one up and send it via the powerpc tree.
- k
^ permalink raw reply
* Re: [PATCH 00/33] My PS3-specific patches for 2.6.31
From: Benjamin Herrenschmidt @ 2009-06-11 1:35 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev list, Gary Thomas
In-Reply-To: <1244683951.4674.5.camel@concordia>
On Thu, 2009-06-11 at 11:32 +1000, Michael Ellerman wrote:
> The way I think of it is that the "merge window" is the time for
> maintainers to merge with Linus.
>
> So if you're sending patches to a maintainer you need to have sent all
> your patches to them _before_ then. So the merge window for you is the
> weeks prior to the "merge window".
Right. But a patch generally needs time to be reviewed, spun several
times, etc... so just the week before the merge window is probably too
late :-)
A good rule is that people should start sending things to the list for
review about one kernel release in advance :-)
Now, -rc4 should generally be the wakeup call. It's when I start
frowning even on bug fixes, and putting together a next branch, at least
normally. I can be flexible but people need to try to play nicely too.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2 -next] powerpc/85xx: Add support for X-ES MPC85xx boards
From: David Gibson @ 2009-06-11 1:32 UTC (permalink / raw)
To: Nate Case; +Cc: linuxppc-dev
In-Reply-To: <1244673039-1089-1-git-send-email-ncase@xes-inc.com>
On Wed, Jun 10, 2009 at 05:30:39PM -0500, Nate Case wrote:
> Add support for X-ES single-board computers based on the Freescale
> MPC85xx processors. Changes include:
[snip]
> diff --git a/arch/powerpc/boot/dts/xcalibur1501.dts b/arch/powerpc/boot/dts/xcalibur1501.dts
> new file mode 100644
> index 0000000..497af7a
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/xcalibur1501.dts
> @@ -0,0 +1,759 @@
> +/*
> + * Copyright (C) 2008 Extreme Engineering Solutions, Inc.
> + * Based on MPC8572DS device tree from Freescale Semiconductor, Inc.
> + *
> + * XCalibur1501 6U CompactPCI single-board computer based on MPC8572E
> + *
> + * This is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +/ {
> + model = "xes,xcalibur1501";
> + compatible = "xes,xcalibur1501", "xes,MPC8572";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + form-factor = "6U cPCI";
> + boot-bank = <0x0>; /* 0: Primary flash, 1: Secondary flash */
These last two aren't standard properties, so should probably be
"xes,form-factor" and "xes,boot-bank".
[snip]
> + pmcslots {
What does this structure model? Without any reg properties it's kind
of hard to see what you could do with it.
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pmcslot@0 {
Since you have an unit address, you must also have a reg property to
match, so reg = <0> in this case.
> + cell-index = <0>;
Don't use cell-index here, it's redundant with the reg value that you
should have.
> + /*
> + * boolean properties (true if defined):
> + * monarch;
> + * module-present;
> + */
> + };
> +
> + pmcslot@1 {
> + cell-index = <1>;
> + /*
> + * boolean properties (true if defined):
> + * monarch;
> + * module-present;
> + */
> + };
> + };
> +
> + xmcslots {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + xmcslot@0 {
> + cell-index = <0>;
Same comments here.
> + /*
> + * boolean properties (true if defined):
> + * module-present;
> + */
> + };
> +
> + xmcslot@1 {
> + cell-index = <1>;
> + /*
> + * boolean properties (true if defined):
> + * module-present;
> + */
> + };
> + };
> +
> + cpci {
> + /*
> + * boolean properties (true if defined):
> + * system-controller;
> + */
> + system-controller;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,8572@0 {
> + device_type = "cpu";
> + reg = <0x0>;
> + d-cache-line-size = <32>; // 32 bytes
> + i-cache-line-size = <32>; // 32 bytes
> + d-cache-size = <0x8000>; // L1, 32K
> + i-cache-size = <0x8000>; // L1, 32K
> + timebase-frequency = <0>;
> + bus-frequency = <0>;
> + clock-frequency = <0>;
> + next-level-cache = <&L2>;
> + };
> +
> + PowerPC,8572@1 {
> + device_type = "cpu";
> + reg = <0x1>;
> + d-cache-line-size = <32>; // 32 bytes
> + i-cache-line-size = <32>; // 32 bytes
> + d-cache-size = <0x8000>; // L1, 32K
> + i-cache-size = <0x8000>; // L1, 32K
> + timebase-frequency = <0>;
> + bus-frequency = <0>;
> + clock-frequency = <0>;
> + next-level-cache = <&L2>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
I assume this node's reg property is supposed to be filled in by the
bootloader. Best to have an explanatory comment, and/or a template
reg property here.
[snip]
> + soc8572@ef000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + compatible = "simple-bus";
This compatible value needs a more specific entry for the specific SoC
type.
[snip]
> + /* eTSEC 1 front panel 0 */
> + enet0: ethernet@24000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + cell-index = <0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <0x24000 0x1000>;
> + ranges = <0x0 0x24000 0x1000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <29 2 30 2 34 2>;
> + interrupt-parent = <&mpic>;
> + tbi-handle = <&tbi0>;
> + phy-handle = <&phy0>;
> + phy-connection-type = "sgmii";
> +
> + mdio@520 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,gianfar-mdio";
> + reg = <0x520 0x20>;
> +
> + phy0: ethernet-phy@1 {
> + interrupt-parent = <&mpic>;
> + interrupts = <4 1>;
> + reg = <0x1>;
> + device_type = "ethernet-phy";
Drop this device_type.
> + };
> + phy1: ethernet-phy@2 {
> + interrupt-parent = <&mpic>;
> + interrupts = <4 1>;
> + reg = <0x2>;
> + device_type = "ethernet-phy";
> + };
> + phy2: ethernet-phy@3 {
> + interrupt-parent = <&mpic>;
> + interrupts = <5 1>;
> + reg = <0x3>;
> + device_type = "ethernet-phy";
> + };
> + phy3: ethernet-phy@4 {
> + interrupt-parent = <&mpic>;
> + interrupts = <5 1>;
> + reg = <0x4>;
> + device_type = "ethernet-phy";
> + };
> + tbi0: tbi-phy@11 {
> + reg = <0x11>;
> + device_type = "tbi-phy";
> + };
> + };
> + };
> +
> + /* eTSEC 2 front panel 1 */
> + enet1: ethernet@25000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + cell-index = <1>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <0x25000 0x1000>;
> + ranges = <0x0 0x25000 0x1000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <35 2 36 2 40 2>;
> + interrupt-parent = <&mpic>;
> + tbi-handle = <&tbi1>;
> + phy-handle = <&phy1>;
> + phy-connection-type = "sgmii";
> +
> + mdio@520 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,gianfar-tbi";
> + reg = <0x520 0x20>;
> +
> + tbi1: tbi-phy@11 {
> + reg = <0x11>;
> + device_type = "tbi-phy";
> + };
> + };
> + };
> +
> + /* eTSEC 3 PICMG2.16 backplane port 0 */
> + enet2: ethernet@26000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + cell-index = <2>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <0x26000 0x1000>;
> + ranges = <0x0 0x26000 0x1000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <31 2 32 2 33 2>;
> + interrupt-parent = <&mpic>;
> + tbi-handle = <&tbi2>;
> + phy-handle = <&phy2>;
> + phy-connection-type = "sgmii";
> +
> + mdio@520 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,gianfar-tbi";
> + reg = <0x520 0x20>;
> +
> + tbi2: tbi-phy@11 {
> + reg = <0x11>;
> + device_type = "tbi-phy";
And this one, too. Although this node should probably have a
compatible property instead.
[snip]
> + tlu@2f000 {
> + device_type = "tlu";
Drop this device_type also.
> diff --git a/arch/powerpc/boot/dts/xpedite5200.dts b/arch/powerpc/boot/dts/xpedite5200.dts
> new file mode 100644
> index 0000000..15a5883
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/xpedite5200.dts
Analagous comments for the other device trees.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 00/33] My PS3-specific patches for 2.6.31
From: Michael Ellerman @ 2009-06-11 1:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Gary Thomas
In-Reply-To: <1244681320.5739.5.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]
On Thu, 2009-06-11 at 10:48 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-06-10 at 15:53 -0600, Gary Thomas wrote:
>
> > Trying to understand the process (in preparation for any patches
> > I may want to push upstream) - how can this be too late for 2.6.31?
> > 2.6.30 just came out today...
>
> I'm taking the liberty to reply to the list here because I think
> more people need to understand that problem :-)
>
> Because the process is such that new features can only be merged
> during the 2 weeks merge window, which started ... yesterday.
>
> Also, it's frowned upon to have lots of new stuff close to the end of
> the merge window.
>
> The idea is that stuff to go into 2.6.31 should have essentially been
> ready to merge -before- the merge window opens, ie, before 2.6.30 is
> released, for us maintainers to be ready to push things out when the
> merge window open and spend that time sorting out collisions &
> conflicts, -not- reviewing new features that have been sent way too
> late.
The way I think of it is that the "merge window" is the time for
maintainers to merge with Linus.
So if you're sending patches to a maintainer you need to have sent all
your patches to them _before_ then. So the merge window for you is the
weeks prior to the "merge window".
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: next branch update
From: Benjamin Herrenschmidt @ 2009-06-11 1:30 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev list
In-Reply-To: <20090610210923.2323202f@lappy.seanm.ca>
On Wed, 2009-06-10 at 21:09 -0400, Sean MacLennan wrote:
> I was expecting an rc9 and another week. Probably others where caught
> off guard. Patch below.
>
Note that this simple patch qualifies as a bug fix in my book and thus
is less constrainted. I would happily have merged it in -rc4 :-)
Cheers,
Ben.
^ permalink raw reply
* Re: next branch update
From: Sean MacLennan @ 2009-06-11 1:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1244681452.5739.7.camel@pasglop>
On Thu, 11 Jun 2009 10:50:52 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> n Wed, 2009-06-10 at 17:56 -0400, Sean MacLennan wrote:
> > What ever happened to this patch?
>
> Dunno... It should have been in patchwork. I remember the patch
> in fact and I intended to merge it... Can you re-submit with
> appropriate cset comment, signed-off-by etc... ?
>
> (Mistakes -do- happen, which is why we can be flexible with the rules,
> btw, but heh, 33 new patches the day the merge window opens is a bit
> over the top).
I was expecting an rc9 and another week. Probably others where caught
off guard. Patch below.
Cheers,
Sean
If no device is passed to __dma_alloc_coherent, it defaults to using ISA_DMA_THRESHOLD
for the mask. This patch provides a reasonable default rather than 0.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
index 21ff868..7f3c1c7 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -43,7 +43,13 @@ static int __init warp_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- return of_flat_dt_is_compatible(root, "pika,warp");
+ if (!of_flat_dt_is_compatible(root, "pika,warp"))
+ return 0;
+
+ /* For __dma_alloc_coherent */
+ ISA_DMA_THRESHOLD = ~0L;
+
+ return 1;
}
define_machine(warp) {
^ permalink raw reply related
* Re: [PATCH] Re:[BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Stephen Rothwell @ 2009-06-11 1:05 UTC (permalink / raw)
To: Subrata Modak
Cc: Sachin P Sant, netdev, Linux-Kernel, Linuxppc-dev, Linux-Next,
Li Yang, Balbir Singh
In-Reply-To: <20090610174323.28045.70169.sendpatchset@subratamodak.linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 470 bytes --]
Hi Subrata,
On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm.com> wrote:
>
> /* Find the TBI PHY. If it's not there, we don't support SGMII */
> - ph = of_get_property(np, "tbi-handle", NULL);
> + ph = (phandle *)of_get_property(np, "tbi-handle", NULL);
You don't need this cast because of_get_property() returns "void *".
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ 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