* Re: [PATCH] char: hvc: check for error case
From: Chris Metcalf @ 2010-09-13 13:12 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: Arnd Bergmann, kernel-janitors, linux-kernel, FUJITA Tomonori,
Paul Mundt, linuxppc-dev
In-Reply-To: <1284317835-5086-1-git-send-email-segooon@gmail.com>
On 9/12/2010 2:57 PM, Vasiliy Kulikov wrote:
> hvc_alloc() may fail, if so exit from init() with error.
>
> Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Thanks, accepted into my tree (for the next merge window). In practice all
this means is in debug mode we'll get a warning from do_one_initcall()
rather than silence, but you're right, it's technically better. :-)
> ---
> I cannot compile this driver at all, so it is not tested.
>
> drivers/char/hvc_tile.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/hvc_tile.c b/drivers/char/hvc_tile.c
> index c4efb55..7a84a05 100644
> --- a/drivers/char/hvc_tile.c
> +++ b/drivers/char/hvc_tile.c
> @@ -61,7 +61,8 @@ console_initcall(hvc_tile_console_init);
>
> static int __init hvc_tile_init(void)
> {
> - hvc_alloc(0, 0, &hvc_tile_get_put_ops, 128);
> - return 0;
> + struct hvc_struct *s;
> + s = hvc_alloc(0, 0, &hvc_tile_get_put_ops, 128);
> + return IS_ERR(s) ? PTR_ERR(s) : 0;
> }
> device_initcall(hvc_tile_init);
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: [PATCH] char: hvc: check for error case
From: Vasiliy Kulikov @ 2010-09-13 13:32 UTC (permalink / raw)
To: Chris Metcalf
Cc: Arnd Bergmann, kernel-janitors, linux-kernel, FUJITA Tomonori,
Paul Mundt, linuxppc-dev
In-Reply-To: <4C8E2355.60807@tilera.com>
On Mon, Sep 13, 2010 at 09:12 -0400, Chris Metcalf wrote:
> Thanks, accepted into my tree (for the next merge window). In practice all
> this means is in debug mode we'll get a warning from do_one_initcall()
> rather than silence, but you're right, it's technically better. :-)
Anyway it's better, if user sees warning in the dmesg, he/she might
response to this situation.
Best,
--
Vasiliy
^ permalink raw reply
* Re: [PATCH] APM821xx: Add support for new SoC APM821xx
From: Josh Boyer @ 2010-09-13 13:44 UTC (permalink / raw)
To: Olof Johansson; +Cc: Tirumala Marri, linuxppc-dev
In-Reply-To: <20100906154526.GA515@lixom.net>
On Mon, Sep 06, 2010 at 10:45:26AM -0500, Olof Johansson wrote:
>On Sun, Sep 05, 2010 at 10:19:53PM -0700, Tirumala Marri wrote:
>> >
>> > Then the device tree identifier, and the cpu setup functions, etc,
>> > should indicate
>> > 464, not APM821xx.
>> This is new SoC based on 464 cpu core. All the previous SoC device tree
>> CPU portion uses SoC name.
>
>Hm, you're right. Confusing.
>
>Still, the cpu setup functions would make more sense to have the core
>name in, not the SoC name. Especially since multiple SoC families might
>use the same core, etc.
In theory. In practice, it just makes it a damn mess. I'd rather leave
it as-is until we can get a good split-out of the core variants and what
their setup functions might require. Starting with just this SoC and not
fixing everything else is going to be confusing and probably wrong.
josh
^ permalink raw reply
* Re: [PATCH v1] APM821xx: Add support for new SoC APM821xx
From: Josh Boyer @ 2010-09-13 13:54 UTC (permalink / raw)
To: tmarri; +Cc: linuxppc-dev
In-Reply-To: <1284143257-15993-1-git-send-email-tmarri@apm.com>
On Fri, Sep 10, 2010 at 11:27:37AM -0700, tmarri@apm.com wrote:
>From: Tirumala Marri <tmarri@apm.com>
>
>This patch adds CPU, device tree, defconfig and bluestone board
>support for APM821xx SoC.
>
>Signed-off-by: Tirumala R Marri <tmarri@apm.com>
>+ cpus {
>+ #address-cells = <1>;
>+ #size-cells = <0>;
>+
>+ cpu@0 {
>+ device_type = "cpu";
>+ model = "PowerPC,464";
Let's just keep this as it was in your first patch for now. See why in
later comments. (Also, the whitespace is odd here anyway.)
>+ reg = <0x00000000>;
>+ clock-frequency = <0>; /* Filled in by U-Boot */
Out of curiosity, which version of U-Boot has (or will have) this support?
>diff --git a/arch/powerpc/configs/44x/bluestone_defconfig b/arch/powerpc/configs/44x/bluestone_defconfig
>new file mode 100644
>index 0000000..ac65b48
>--- /dev/null
>+++ b/arch/powerpc/configs/44x/bluestone_defconfig
This defconfig is much better. Thanks.
>diff --git a/arch/powerpc/kernel/cpu_setup_44x.S b/arch/powerpc/kernel/cpu_setup_44x.S
>index 7d606f8..549f482 100644
>--- a/arch/powerpc/kernel/cpu_setup_44x.S
>+++ b/arch/powerpc/kernel/cpu_setup_44x.S
>@@ -35,6 +35,7 @@ _GLOBAL(__setup_cpu_440grx)
> _GLOBAL(__setup_cpu_460ex)
> _GLOBAL(__setup_cpu_460gt)
> _GLOBAL(__setup_cpu_460sx)
>+_GLOBAL(__setup_cpu_464)
> mflr r4
> bl __init_fpu_44x
> bl __fixup_440A_mcheck
This doesn't look correct. Not all 464 cores will have an FPU.
Additionally, if this were correct then you could just replace all of
the 460xx setup functions with a single one instead of adding one for
464 cores and ignoring those.
>diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
>index 1f9123f..89e55b1 100644
>--- a/arch/powerpc/kernel/cputable.c
>+++ b/arch/powerpc/kernel/cputable.c
>@@ -48,6 +48,7 @@ extern void __setup_cpu_440x5(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_460ex(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_460gt(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_460sx(unsigned long offset, struct cpu_spec *spec);
>+extern void __setup_cpu_464(unsigned long offset, struct cpu_spec *spec);
> extern void __setup_cpu_603(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_604(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_750(unsigned long offset, struct cpu_spec* spec);
>@@ -1805,6 +1806,20 @@ static struct cpu_spec __initdata cpu_specs[] = {
> .machine_check = machine_check_440A,
> .platform = "ppc440",
> },
>+ { /* 464 in APM821xx */
>+ .pvr_mask = 0xffffff00,
>+ .pvr_value = 0x12C41C80,
>+ .cpu_name = "464 in APM821xx",
That's a bit of an odd cpu_name. Let's just stick with the SoC name for
this, as the PVR really identifies the SoC on 4xx, not the core. I'd
suggest just creating the __setup_cpu_apm821xx function for now. We can
sort out how to break out the 4xx core inside the SoC later.
josh
^ permalink raw reply
* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Timur Tabi @ 2010-09-13 14:10 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A1FC158@zch01exm23.fsl.freescale.net>
On Mon, Sep 13, 2010 at 2:30 AM, Zang Roy-R61911 <r61911@freescale.com> wrote:
> What is the different for unsigned int and u32? I think they are same.
Roy, please don't ever write code that assumes that sizeof(int) == 4.
There's a reason why we have unsized integer types (like int, long,
and short) and sized integer types (like u8, u16, u32). If you want
an integer of a specific size, you should use a sized integer type.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Artem Bityutskiy @ 2010-09-13 14:27 UTC (permalink / raw)
To: Timur Tabi
Cc: Wood Scott-B07421, Zang Roy-R61911, Lan Chunhe-B25806,
linuxppc-dev, linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <AANLkTimfKwdw+nLAjDjxf52dbZKLF-3aES+bT7CHskAS@mail.gmail.com>
On Mon, 2010-09-13 at 09:10 -0500, Timur Tabi wrote:
> On Mon, Sep 13, 2010 at 2:30 AM, Zang Roy-R61911 <r61911@freescale.com> wrote:
>
> > What is the different for unsigned int and u32? I think they are same.
>
> Roy, please don't ever write code that assumes that sizeof(int) == 4.
> There's a reason why we have unsized integer types (like int, long,
> and short) and sized integer types (like u8, u16, u32). If you want
> an integer of a specific size, you should use a sized integer type.
Yes, sizeof(int) == 4 assumption is not good.
But sizeof(int) >= 4 is perfectly fine.
It is OK to rely on the fact that unsigned int is _at least_ 32-bit, not
less. And if you know 32 bits is enough, and you are fine with more, it
is _better_ to avoid u32. Simply because with unsigned int you do not
limit the compiler and CPU and let them use native integers, rather than
strictly 32-bit. This potentially gives the compiler and CPU more room
for optimization.
I see people use u32 and the friends too much. It is safe and better to
use native types, unless you really have to make the variable to be
strictly u32.
I did not follow this particular conversation and do not judge which
type is better in this case. I am talking in general. :-)
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply
* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Timur Tabi @ 2010-09-13 14:35 UTC (permalink / raw)
To: dedekind1
Cc: Wood Scott-B07421, Zang Roy-R61911, Lan Chunhe-B25806,
linuxppc-dev, linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <1284388075.10955.51.camel@localhost>
On Mon, Sep 13, 2010 at 9:27 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> Yes, sizeof(int) == 4 assumption is not good.
>
> But sizeof(int) >= 4 is perfectly fine.
I have to disagree. I don't see how you can say that == is not okay,
but >= is okay. That just doesn't make any sense. Obviously, you
have to make some assumptions about sizeof(int), but that assumption
should be nothing more than "it should be big enough for these small
numbers that I'm using".
> I see people use u32 and the friends too much.
I agree with that.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Scott Wood @ 2010-09-13 16:27 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, Geert Uytterhoeven, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A1FC150@zch01exm23.fsl.freescale.net>
On Mon, 13 Sep 2010 00:22:10 -0700
"Zang Roy-R61911" <r61911@freescale.com> wrote:
>=20
>=20
> > -----Original Message-----
> > From: geert.uytterhoeven@gmail.com [mailto:geert.uytterhoeven@gmail.com=
] On
> > Behalf Of Geert Uytterhoeven
> > Sent: Thursday, September 09, 2010 19:06 PM
> > To: Zang Roy-R61911
> > Cc: linux-mtd@lists.infradead.org; Wood Scott-B07421; dedekind1@gmail.c=
om; Lan
> > Chunhe-B25806; linuxppc-dev@ozlabs.org; akpm@linux-foundation.org;
> > dwmw2@infradead.org; Gala Kumar-B11780
> > Subject: Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue=
with
> > 36bit mode
> >=20
> > On Thu, Sep 9, 2010 at 12:20, Roy Zang <tie-fei.zang@freescale.com> wro=
te:
> > > From: Lan Chunhe-B25806 <b25806@freescale.com>
> > >
> > > When system uses 36bit physical address, res.start is 36bit
> > > physical address. But the function of in_be32 returns 32bit
> > > physical address. Then both of them compared each other is
> > > wrong. So by converting the address of res.start into
> > > the right format fixes this issue.
> >=20
> > > =A0/**
> > > + * fsl_lbc_addr - convert the base address
> > > + * @addr_base: base address of the memory bank
> > > + *
> > > + * This function converts a base address of lbc into the right forma=
t for
> > the BR
> > > + * registers. If the SOC has eLBC then it returns 32bit physical add=
ress
> > else
> > > + * it returns 34bit physical address for local bus(Example: MPC8641).
> > > + */
> > > +unsigned int fsl_lbc_addr(phys_addr_t addr_base)
> > ^^^^^^^^^^^^
> > Shouldn't this be u32 or __be32, for consistency with the actual
> > comparisons below?
> __be32 is better.
I disagree, the return from this function is native-endian. It should
be u32.
-Scott
^ permalink raw reply
* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Artem Bityutskiy @ 2010-09-13 16:45 UTC (permalink / raw)
To: Timur Tabi
Cc: Wood Scott-B07421, Zang Roy-R61911, Lan Chunhe-B25806,
linuxppc-dev, linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <AANLkTinyELs7KNDQxWsaR8Ea13SewWYwgtnie_P7cAzC@mail.gmail.com>
On Mon, 2010-09-13 at 09:35 -0500, Timur Tabi wrote:
> On Mon, Sep 13, 2010 at 9:27 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
>
> > Yes, sizeof(int) == 4 assumption is not good.
> >
> > But sizeof(int) >= 4 is perfectly fine.
>
> I have to disagree. I don't see how you can say that == is not okay,
> but >= is okay.
If I assume that int == 4, which is true for all platform ATM, and will
most probably stay true for very long time, I still make an unnecessary
assumption which C99 does not guarantee. This is just not very clean. So
for things which require exactly 32 bits, u32 or C99 uint32_t should be
used.
On the other hand, if a have a local variable "var" which needs to store
values which I know will always fit 32 bits, and I do not use it in
operations (I/O, etc) which require exactly 32 bits, it is better to use
unsigned int for it. Unsigned int is reliably >= 4 in Linux.
This is wat I meant that sizeof(int) >= 4 is perfectly fine. One
everywhere, of course, but in many cases.
To put it differently, if there is no special reason to limit the
variable by exactly 32 bits, it is better to use int.
--
Best Regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply
* Re: [PATCH 11/11] sound: Remove pr_<level> uses of KERN_<level>
From: Geoff Levand @ 2010-09-13 17:55 UTC (permalink / raw)
To: Joe Perches
Cc: cbe-oss-dev, alsa-devel, Jiri Kosina, Takashi Iwai, Mark Brown,
linux-kernel, Jaroslav Kysela, linuxppc-dev, Liam Girdwood
In-Reply-To: <27a88f64b5bfec16c8abf5aca89b7a1b7533ecb9.1284267142.git.joe@perches.com>
[-- Attachment #1: Type: text/plain, Size: 662 bytes --]
Hi Joe,
On 09/11/2010 10:10 PM, Joe Perches wrote:
> sound/ppc/snd_ps3.c | 2 +-
>
> diff --git a/sound/ppc/snd_ps3.c b/sound/ppc/snd_ps3.c
> index 2f12da4..581a670 100644
> --- a/sound/ppc/snd_ps3.c
> +++ b/sound/ppc/snd_ps3.c
> @@ -579,7 +579,7 @@ static int snd_ps3_delay_to_bytes(struct snd_pcm_substream *substream,
> rate * delay_ms / 1000)
> * substream->runtime->channels;
>
> - pr_debug(KERN_ERR "%s: time=%d rate=%d bytes=%ld, frames=%d, ret=%d\n",
> + pr_debug("%s: time=%d rate=%d bytes=%ld, frames=%d, ret=%d\n",
> __func__,
> delay_ms,
> rate,
snd_ps3.c looks OK.
Acked-by: Geoff Levand <geoff@infradead.org>
[-- Attachment #2: 0x2E141B16.asc --]
[-- Type: application/pgp-keys, Size: 9418 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Timur Tabi @ 2010-09-13 18:36 UTC (permalink / raw)
To: dedekind1
Cc: Wood Scott-B07421, Zang Roy-R61911, Lan Chunhe-B25806,
linuxppc-dev, linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <1284396320.1783.30.camel@brekeke>
On Mon, Sep 13, 2010 at 11:45 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> Unsigned int is reliably >= 4 in Linux.
Not exactly. sizeof(unsigned int) is effectively never greater than 4
in Linux (I think it's still 32 bits even on a 64-bit kernel), so it
makes no sense to say >=. So since you can't say that sizeof(int) ==
4, and you can't say that sizeof(int) > 4, then you certainly can't
say that sizeof(int) >= 4.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Artem Bityutskiy @ 2010-09-13 18:46 UTC (permalink / raw)
To: Timur Tabi
Cc: Wood Scott-B07421, Zang Roy-R61911, Lan Chunhe-B25806,
linuxppc-dev, linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <AANLkTimUR5-hWRkDAwWTXJYCOcse7LTR0r-vSsZec1g1@mail.gmail.com>
On Mon, 2010-09-13 at 13:36 -0500, Timur Tabi wrote:
> On Mon, Sep 13, 2010 at 11:45 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> > Unsigned int is reliably >= 4 in Linux.
>
> Not exactly. sizeof(unsigned int) is effectively never greater than 4
> in Linux
I know and said the same in the other paragraph which you cut.
> (I think it's still 32 bits even on a 64-bit kernel)
Yes.
> , so it
> makes no sense to say >=. So since you can't say that sizeof(int) ==
> 4, and you can't say that sizeof(int) > 4, then you certainly can't
> say that sizeof(int) >= 4.
It also makes no sense to send "makes no sense" answer 2 times in a row
and it makes no sense to not read and not try to understand the e-mail
you are replying (even though the english of the writer is not perfect)
So it makes no sense to continue arguing.
But it makes some sense to go sleep, good night.
--
Best Regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply
* [PATCH 02/25] arch/powerpc: Use static const char arrays
From: Joe Perches @ 2010-09-13 19:47 UTC (permalink / raw)
To: linux-kernel; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <cover.1284406638.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/powerpc/boot/addnote.c | 4 ++--
arch/powerpc/boot/cuboot-c2k.c | 4 ++--
arch/powerpc/kernel/irq.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/addnote.c b/arch/powerpc/boot/addnote.c
index b1e5611..349b553 100644
--- a/arch/powerpc/boot/addnote.c
+++ b/arch/powerpc/boot/addnote.c
@@ -20,7 +20,7 @@
#include <string.h>
/* CHRP note section */
-char arch[] = "PowerPC";
+static const char arch[] = "PowerPC";
#define N_DESCR 6
unsigned int descr[N_DESCR] = {
@@ -33,7 +33,7 @@ unsigned int descr[N_DESCR] = {
};
/* RPA note section */
-char rpaname[] = "IBM,RPA-Client-Config";
+static const char rpaname[] = "IBM,RPA-Client-Config";
/*
* Note: setting ignore_my_client_config *should* mean that OF ignores
diff --git a/arch/powerpc/boot/cuboot-c2k.c b/arch/powerpc/boot/cuboot-c2k.c
index e435949..030d7db 100644
--- a/arch/powerpc/boot/cuboot-c2k.c
+++ b/arch/powerpc/boot/cuboot-c2k.c
@@ -62,9 +62,9 @@ static void c2k_bridge_setup(u32 mem_size)
/* Get the cpu -> pci i/o & mem mappings from the device tree */
devp = NULL;
for (bus = 0; ; bus++) {
- char name[] = "pci ";
+ char name[sizeof("pciX")];
- name[strlen(name)-1] = bus+'0';
+ sprintf(name, "pci%c", bus + '0');
devp = find_node_by_alias(name);
if (devp == NULL)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 4a65386..47fbc56 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -1143,7 +1143,7 @@ static int virq_debug_show(struct seq_file *m, void *private)
unsigned long flags;
struct irq_desc *desc;
const char *p;
- char none[] = "none";
+ static const char none[] = "none";
int i;
seq_printf(m, "%-5s %-7s %-15s %s\n", "virq", "hwirq",
--
1.7.3.rc1
^ permalink raw reply related
* [PATCH 00/25] treewide-next: Use static const char arrays
From: Joe Perches @ 2010-09-13 19:47 UTC (permalink / raw)
To: linux-kernel
Cc: Amit Kumar Salecha, linux-fbdev, Greg Kroah-Hartman, James Smart,
linux-mips, VMware, Inc., PJ Waskiewicz, Shreyas Bhatewara,
alsa-devel, Jaroslav Kysela, J. Bruce Fields,
James E.J. Bottomley, Paul Mackerras, linux-i2c, Brett Rudley,
sparclinux, Martin Schwidefsky, devel, linux-s390, linux-acpi,
linux-scsi, Florian Tobias Schandinat, e1000-devel,
Trond Myklebust, Jesse Brandeburg, Neil Brown, Jeff Kirsher,
linux-wireless, Ingo Molnar, linux-usb, Len Brown, Alex Duyck,
Peter Zijlstra, Henry Ptasinski, Heiko Carstens,
Thomas Winischhofer, Mauro Carvalho Chehab,
Arnaldo Carvalho de Melo, Jean Delvare (PC drivers, core),
mjpeg-users, Ben Dooks (embedded platforms), linux-nfs,
linux-arm-kernel, Neela Syam Kolli, Karsten Keil, Linus Walleij,
netdev, Anirban Chakraborty, Bruce Allan, Nohee Ko, Ralf Baechle,
Joseph Chan, John Ronciak, Takashi Iwai, linux-driver, linux390,
linux-media, linuxppc-dev, David S. Miller
Using static const char foo[] = "bar" can save some
code and text space, so change the places where it's possible.
Also change the places that use
char foo[] = "barX";
...
foo[3] = value + '0';
where X is typically changed
char foo[sizeof("barX")];
...
sprintf(foo, "bar%c", value + '0');
Joe Perches (25):
arch/mips: Use static const char arrays
arch/powerpc: Use static const char arrays
drivers/acpi: Use static const char arrays
drivers/char: Use static const char arrays
drivers/i2c: Use static const char arrays
drivers/isdn: Use static const char arrays
drivers/media: Use static const char arrays
drivers/net/atl1c: Use static const char arrays
drivers/net/atl1e: Use static const char arrays
drivers/net/(intel): Use static const char arrays
drivers/net/netxen: Use static const char arrays
drivers/net/qlcnic: Use static const char arrays
drivers/net/spider_net.c: Use static const char arrays
drivers/net/vnxnet3: Use static const char arrays
drivers/net/wireless/ipw2x00: Use static const char arrays
drivers/s390/char: Use static const char arrays
drivers/scsi: Use static const char arrays
drivers/serial/suncore.c: Use static const char arrays
drivers/staging: Use static const char arrays
drivers/usb: Use static const char arrays
drivers/video: Use static const char arrays
net/dsa: Use static const char arrays
net/sunrpc: Use static const char arrays
sound: Use static const char arrays
tools/perf/util: Use static const char arrays
arch/mips/pnx8550/common/reset.c | 4 ++--
arch/powerpc/boot/addnote.c | 4 ++--
arch/powerpc/boot/cuboot-c2k.c | 4 ++--
arch/powerpc/kernel/irq.c | 2 +-
drivers/acpi/sleep.c | 4 ++--
drivers/char/hvc_vio.c | 2 +-
drivers/i2c/busses/i2c-stu300.c | 4 ++--
drivers/isdn/hysdn/hycapi.c | 2 +-
drivers/isdn/mISDN/dsp_cmx.c | 2 +-
drivers/media/video/zoran/zoran_device.c | 5 ++---
drivers/net/atl1c/atl1c.h | 4 ++--
drivers/net/atl1c/atl1c_main.c | 4 ++--
drivers/net/atl1e/atl1e.h | 4 ++--
drivers/net/atl1e/atl1e_main.c | 4 ++--
drivers/net/e1000/e1000.h | 2 +-
drivers/net/e1000/e1000_main.c | 4 ++--
drivers/net/e1000e/e1000.h | 2 +-
drivers/net/e1000e/netdev.c | 2 +-
drivers/net/igb/igb.h | 4 ++--
drivers/net/igb/igb_main.c | 4 ++--
drivers/net/igbvf/igbvf.h | 2 +-
drivers/net/igbvf/netdev.c | 2 +-
drivers/net/ixgb/ixgb.h | 2 +-
drivers/net/ixgb/ixgb_main.c | 2 +-
drivers/net/ixgbe/ixgbe.h | 2 +-
drivers/net/ixgbe/ixgbe_main.c | 4 ++--
drivers/net/ixgbevf/ixgbevf.h | 2 +-
drivers/net/ixgbevf/ixgbevf_main.c | 2 +-
drivers/net/netxen/netxen_nic.h | 2 +-
drivers/net/netxen/netxen_nic_main.c | 2 +-
drivers/net/qlcnic/qlcnic.h | 2 +-
drivers/net/qlcnic/qlcnic_main.c | 2 +-
drivers/net/spider_net.c | 2 +-
drivers/net/vmxnet3/vmxnet3_drv.c | 2 +-
drivers/net/vmxnet3/vmxnet3_int.h | 2 +-
drivers/net/wireless/ipw2x00/ipw2100.c | 2 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 2 +-
drivers/net/wireless/ipw2x00/libipw_module.c | 2 +-
drivers/s390/char/vmlogrdr.c | 4 ++--
drivers/scsi/bnx2i/bnx2i_hwi.c | 6 +++---
drivers/scsi/lpfc/lpfc_init.c | 2 +-
drivers/scsi/megaraid/megaraid_mbox.c | 6 +++---
drivers/serial/suncore.c | 4 ++--
drivers/staging/brcm80211/util/bcmutils.c | 2 +-
drivers/staging/comedi/drivers/comedi_bond.c | 2 +-
drivers/staging/cxt1e1/ossiRelease.c | 2 +-
drivers/staging/go7007/go7007-driver.c | 2 +-
drivers/staging/msm/mdp.c | 2 +-
.../staging/rtl8192e/ieee80211/ieee80211_module.c | 2 +-
.../staging/rtl8192u/ieee80211/ieee80211_module.c | 2 +-
drivers/staging/tidspbridge/rmgr/dbdcd.c | 6 +++---
drivers/usb/atm/ueagle-atm.c | 14 +++++---------
drivers/usb/otg/langwell_otg.c | 2 +-
drivers/video/sh_mipi_dsi.c | 4 ++--
drivers/video/sis/sis_main.c | 10 +++++-----
drivers/video/via/viafbdev.c | 2 +-
net/dsa/dsa.c | 2 +-
net/dsa/dsa_priv.h | 2 +-
net/sunrpc/auth_gss/gss_krb5_mech.c | 2 +-
sound/core/misc.c | 5 ++++-
tools/perf/util/ui/setup.c | 3 ++-
tools/perf/util/ui/util.c | 3 ++-
62 files changed, 98 insertions(+), 98 deletions(-)
--
1.7.3.rc1
^ permalink raw reply
* [PATCH 04/25] drivers/char: Use static const char arrays
From: Joe Perches @ 2010-09-13 19:47 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev
In-Reply-To: <cover.1284406638.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/char/hvc_vio.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/hvc_vio.c b/drivers/char/hvc_vio.c
index 27370e9..5e2f52b 100644
--- a/drivers/char/hvc_vio.c
+++ b/drivers/char/hvc_vio.c
@@ -39,7 +39,7 @@
#include "hvc_console.h"
-char hvc_driver_name[] = "hvc_console";
+static const char hvc_driver_name[] = "hvc_console";
static struct vio_device_id hvc_driver_table[] __devinitdata = {
{"serial", "hvterm1"},
--
1.7.3.rc1
^ permalink raw reply related
* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Scott Wood @ 2010-09-13 20:04 UTC (permalink / raw)
To: Timur Tabi
Cc: Wood Scott-B07421, dedekind1, Zang Roy-R61911, Lan Chunhe-B25806,
linuxppc-dev, linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <AANLkTimUR5-hWRkDAwWTXJYCOcse7LTR0r-vSsZec1g1@mail.gmail.com>
On Mon, 13 Sep 2010 13:36:45 -0500
Timur Tabi <timur.tabi@gmail.com> wrote:
> On Mon, Sep 13, 2010 at 11:45 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> > Unsigned int is reliably >= 4 in Linux.
>
> Not exactly. sizeof(unsigned int) is effectively never greater than 4
> in Linux (I think it's still 32 bits even on a 64-bit kernel), so it
> makes no sense to say >=.
I think the point is that if a machine/ABI comes along with
sizeof(int) > 4 (e.g. if there's a significant penalty for working
with anything < 64-bit), Linux might consider supporting that. Whereas
if someone points to their microcontroller or ancient 286 with
sizeof(int) == 2, the answer would be, "Here's a nickel, kid -- get a
real computer".
-Scott
^ permalink raw reply
* Re: [PATCH 11/11] sound: Remove pr_<level> uses of KERN_<level>
From: Takashi Iwai @ 2010-09-13 21:41 UTC (permalink / raw)
To: Joe Perches
Cc: cbe-oss-dev, alsa-devel, Jiri Kosina, Geoff Levand, Mark Brown,
linux-kernel, Jaroslav Kysela, linuxppc-dev, Liam Girdwood
In-Reply-To: <27a88f64b5bfec16c8abf5aca89b7a1b7533ecb9.1284267142.git.joe@perches.com>
At Sat, 11 Sep 2010 22:10:59 -0700,
Joe Perches wrote:
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied to sound git tree now. Thanks.
Takashi
> ---
> sound/ppc/snd_ps3.c | 2 +-
> sound/soc/s3c24xx/s3c-dma.c | 3 +--
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/sound/ppc/snd_ps3.c b/sound/ppc/snd_ps3.c
> index 2f12da4..581a670 100644
> --- a/sound/ppc/snd_ps3.c
> +++ b/sound/ppc/snd_ps3.c
> @@ -579,7 +579,7 @@ static int snd_ps3_delay_to_bytes(struct snd_pcm_substream *substream,
> rate * delay_ms / 1000)
> * substream->runtime->channels;
>
> - pr_debug(KERN_ERR "%s: time=%d rate=%d bytes=%ld, frames=%d, ret=%d\n",
> + pr_debug("%s: time=%d rate=%d bytes=%ld, frames=%d, ret=%d\n",
> __func__,
> delay_ms,
> rate,
> diff --git a/sound/soc/s3c24xx/s3c-dma.c b/sound/soc/s3c24xx/s3c-dma.c
> index 1b61c23..f1b1bc4 100644
> --- a/sound/soc/s3c24xx/s3c-dma.c
> +++ b/sound/soc/s3c24xx/s3c-dma.c
> @@ -94,8 +94,7 @@ static void s3c_dma_enqueue(struct snd_pcm_substream *substream)
>
> if ((pos + len) > prtd->dma_end) {
> len = prtd->dma_end - pos;
> - pr_debug(KERN_DEBUG "%s: corrected dma len %ld\n",
> - __func__, len);
> + pr_debug("%s: corrected dma len %ld\n", __func__, len);
> }
>
> ret = s3c2410_dma_enqueue(prtd->params->channel,
> --
> 1.7.3.rc1
>
^ permalink raw reply
* RE: [PATCH v1] APM821xx: Add support for new SoC APM821xx
From: Tirumala Marri @ 2010-09-13 23:01 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20100913135410.GB31548@zod.rchland.ibm.com>
> >+ clock-frequency = <0>; /* Filled in by U-Boot */
>
> Out of curiosity, which version of U-Boot has (or will have) this
> support?
[Marri] Currently I am working with u-boot list to accept my patch. It
should
be available as soon as it is accepted.
>
> >diff --git a/arch/powerpc/configs/44x/bluestone_defconfig
> b/arch/powerpc/configs/44x/bluestone_defconfig
> >new file mode 100644
> >index 0000000..ac65b48
> >--- /dev/null
> >+++ b/arch/powerpc/configs/44x/bluestone_defconfig
>
> This defconfig is much better. Thanks.
>
> >diff --git a/arch/powerpc/kernel/cpu_setup_44x.S
> b/arch/powerpc/kernel/cpu_setup_44x.S
> >index 7d606f8..549f482 100644
> >--- a/arch/powerpc/kernel/cpu_setup_44x.S
> >+++ b/arch/powerpc/kernel/cpu_setup_44x.S
> >@@ -35,6 +35,7 @@ _GLOBAL(__setup_cpu_440grx)
> > _GLOBAL(__setup_cpu_460ex)
> > _GLOBAL(__setup_cpu_460gt)
> > _GLOBAL(__setup_cpu_460sx)
> >+_GLOBAL(__setup_cpu_464)
> > mflr r4
> > bl __init_fpu_44x
> > bl __fixup_440A_mcheck
>
> This doesn't look correct. Not all 464 cores will have an FPU.
> Additionally, if this were correct then you could just replace all of
> the 460xx setup functions with a single one instead of adding one for
> 464 cores and ignoring those.
[Marri] I reverted back apm821xx in the next patch.
>
> >diff --git a/arch/powerpc/kernel/cputable.c
> b/arch/powerpc/kernel/cputable.c
> >index 1f9123f..89e55b1 100644
> >--- a/arch/powerpc/kernel/cputable.c
> >+++ b/arch/powerpc/kernel/cputable.c
> >@@ -48,6 +48,7 @@ extern void __setup_cpu_440x5(unsigned long offset,
> struct cpu_spec* spec);
> > extern void __setup_cpu_460ex(unsigned long offset, struct cpu_spec*
> spec);
> > extern void __setup_cpu_460gt(unsigned long offset, struct cpu_spec*
> spec);
> > extern void __setup_cpu_460sx(unsigned long offset, struct cpu_spec
> *spec);
> >+extern void __setup_cpu_464(unsigned long offset, struct cpu_spec
> *spec);
> > extern void __setup_cpu_603(unsigned long offset, struct cpu_spec*
> spec);
> > extern void __setup_cpu_604(unsigned long offset, struct cpu_spec*
> spec);
> > extern void __setup_cpu_750(unsigned long offset, struct cpu_spec*
> spec);
> >@@ -1805,6 +1806,20 @@ static struct cpu_spec __initdata cpu_specs[] =
> {
> > .machine_check = machine_check_440A,
> > .platform = "ppc440",
> > },
> >+ { /* 464 in APM821xx */
> >+ .pvr_mask = 0xffffff00,
> >+ .pvr_value = 0x12C41C80,
> >+ .cpu_name = "464 in APM821xx",
>
> That's a bit of an odd cpu_name. Let's just stick with the SoC name
> for
> this, as the PVR really identifies the SoC on 4xx, not the core. I'd
> suggest just creating the __setup_cpu_apm821xx function for now. We
> can
> sort out how to break out the 4xx core inside the SoC later.
[Marri]Sure will do.
^ permalink raw reply
* [PATCH v2] APM821xx: Add support for new SoC APM821xx
From: tmarri @ 2010-09-13 23:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tmarri
From: Tirumala Marri <tmarri@apm.com>
This patch adds CPU, device tree, defconfig and bluestone board
support for APM821xx SoC.
Signed-off-by: Tirumala R Marri <tmarri@apm.com>
---
V1:
* CPU name changed to 464.
* defconfig is created using "make savedefconfig".
V2:
* CPU name changed back to apm821xx for now.
* some white space problem in device tree.
---
arch/powerpc/boot/dts/bluestone.dts | 254 ++++++++++++++++++++++++++
arch/powerpc/configs/44x/bluestone_defconfig | 68 +++++++
arch/powerpc/kernel/cpu_setup_44x.S | 1 +
arch/powerpc/kernel/cputable.c | 15 ++
arch/powerpc/platforms/44x/Kconfig | 16 ++
arch/powerpc/platforms/44x/ppc44x_simple.c | 1 +
6 files changed, 355 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/bluestone.dts
create mode 100644 arch/powerpc/configs/44x/bluestone_defconfig
diff --git a/arch/powerpc/boot/dts/bluestone.dts b/arch/powerpc/boot/dts/bluestone.dts
new file mode 100644
index 0000000..9bb3d72
--- /dev/null
+++ b/arch/powerpc/boot/dts/bluestone.dts
@@ -0,0 +1,254 @@
+/*
+ * Device Tree for Bluestone (APM821xx) board.
+ *
+ * Copyright (c) 2010, Applied Micro Circuits Corporation
+ * Author: Tirumala R Marri <tmarri@apm.com>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "apm,bluestone";
+ compatible = "apm,bluestone";
+ dcr-parent = <&{/cpus/cpu@0}>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,apm821xx";
+ reg = <0x00000000>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <32>;
+ d-cache-line-size = <32>;
+ i-cache-size = <32768>;
+ d-cache-size = <32768>;
+ dcr-controller;
+ dcr-access-method = "native";
+ next-level-cache = <&L2C0>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x00000000 0x00000000>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0x0c0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0x0d0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0x1e 0x4 0x1f 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0x0e0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0xa 0x4 0xb 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = "ibm,uic";
+ interrupt-controller;
+ cell-index = <3>;
+ dcr-reg = <0x0f0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0x10 0x4 0x11 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-apm821xx";
+ dcr-reg = <0x00e 0x002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-apm821xx";
+ dcr-reg = <0x00c 0x002>;
+ };
+
+ plb {
+ compatible = "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: sdram {
+ compatible = "ibm,sdram-apm821xx";
+ dcr-reg = <0x010 0x002>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal2";
+ descriptor-memory = "ocm";
+ dcr-reg = <0x180 0x062>;
+ num-tx-chans = <1>;
+ num-rx-chans = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-parent = <&UIC2>;
+ interrupts = < /*TXEOB*/ 0x6 0x4
+ /*RXEOB*/ 0x7 0x4
+ /*SERR*/ 0x3 0x4
+ /*TXDE*/ 0x4 0x4
+ /*RXDE*/ 0x5 0x4
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0xb0000000 0x00000004 0xb0000000 0x50000000>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc";
+ dcr-reg = <0x012 0x002>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ /* ranges property is supplied by U-Boot */
+ ranges = < 0x00000003 0x00000000 0xe0000000 0x8000000>;
+ interrupts = <0x6 0x4>;
+ interrupt-parent = <&UIC1>;
+
+ nor_flash@0,0 {
+ compatible = "amd,s29gl512n", "cfi-flash";
+ bank-width = <2>;
+ reg = <0x00000000 0x00000000 0x00400000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "kernel";
+ reg = <0x00000000 0x00180000>;
+ };
+ partition@180000 {
+ label = "env";
+ reg = <0x00180000 0x00020000>;
+ };
+ partition@1a0000 {
+ label = "u-boot";
+ reg = <0x001a0000 0x00060000>;
+ };
+ };
+ }
+
+ UART0: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0xef600300 0x00000008>;
+ virtual-reg = <0xef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <0x1 0x4>;
+ };
+
+ IIC0: i2c@ef600700 {
+ compatible = "ibm,iic";
+ reg = <0xef600700 0x00000014>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0x2 0x4>;
+ };
+
+ IIC1: i2c@ef600800 {
+ compatible = "ibm,iic";
+ reg = <0xef600800 0x00000014>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0x3 0x4>;
+ };
+
+ RGMII0: emac-rgmii@ef601500 {
+ compatible = "ibm,rgmii";
+ reg = <0xef601500 0x00000008>;
+ has-mdio;
+ };
+
+ TAH0: emac-tah@ef601350 {
+ compatible = "ibm,tah";
+ reg = <0xef601350 0x00000030>;
+ };
+
+ EMAC0: ethernet@ef600c00 {
+ device_type = "network";
+ compatible = "ibm,emac4sync";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0x0 0x1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0x0 &UIC2 0x10 0x4
+ /*Wake*/ 0x1 &UIC2 0x14 0x4>;
+ reg = <0xef600c00 0x000000c4>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <9000>;
+ rx-fifo-size = <16384>;
+ tx-fifo-size = <2048>;
+ phy-mode = "rgmii";
+ phy-map = <0x00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ tah-device = <&TAH0>;
+ tah-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+ };
+
+ };
+};
diff --git a/arch/powerpc/configs/44x/bluestone_defconfig b/arch/powerpc/configs/44x/bluestone_defconfig
new file mode 100644
index 0000000..ac65b48
--- /dev/null
+++ b/arch/powerpc/configs/44x/bluestone_defconfig
@@ -0,0 +1,68 @@
+CONFIG_44x=y
+CONFIG_EXPERIMENTAL=y
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_EMBEDDED=y
+# CONFIG_VM_EVENT_COUNTERS is not set
+# CONFIG_PCI_QUIRKS is not set
+# CONFIG_COMPAT_BRK is not set
+CONFIG_BLUESTONE=y
+# CONFIG_EBONY is not set
+# CONFIG_KVM_GUEST is not set
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_SPARSE_IRQ=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE=""
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_CONNECTOR=y
+CONFIG_MTD=y
+CONFIG_MTD_PARTITIONS=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_OF_PARTS=y
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_PROC_DEVICETREE=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=35000
+CONFIG_NETDEVICES=y
+CONFIG_NET_ETHERNET=y
+CONFIG_IBM_NEW_EMAC=y
+CONFIG_IBM_NEW_EMAC_RXB=256
+CONFIG_IBM_NEW_EMAC_TXB=256
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=2
+CONFIG_SERIAL_8250_RUNTIME_UARTS=2
+CONFIG_SERIAL_8250_EXTENDED=y
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_IBM_IIC=y
+CONFIG_SENSORS_AD7414=y
+# CONFIG_HID_SUPPORT is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_M41T80=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_TMPFS=y
+CONFIG_CRAMFS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS=y
diff --git a/arch/powerpc/kernel/cpu_setup_44x.S b/arch/powerpc/kernel/cpu_setup_44x.S
index 7d606f8..e32b4a9 100644
--- a/arch/powerpc/kernel/cpu_setup_44x.S
+++ b/arch/powerpc/kernel/cpu_setup_44x.S
@@ -35,6 +35,7 @@ _GLOBAL(__setup_cpu_440grx)
_GLOBAL(__setup_cpu_460ex)
_GLOBAL(__setup_cpu_460gt)
_GLOBAL(__setup_cpu_460sx)
+_GLOBAL(__setup_cpu_apm821xx)
mflr r4
bl __init_fpu_44x
bl __fixup_440A_mcheck
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 1f9123f..b7ac795 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -48,6 +48,7 @@ extern void __setup_cpu_440x5(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_460ex(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_460gt(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_460sx(unsigned long offset, struct cpu_spec *spec);
+extern void __setup_cpu_apm821xx(unsigned long offset, struct cpu_spec *spec);
extern void __setup_cpu_603(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_604(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_750(unsigned long offset, struct cpu_spec* spec);
@@ -1805,6 +1806,20 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_440A,
.platform = "ppc440",
},
+ { /* 464 in APM821xx */
+ .pvr_mask = 0xffffff00,
+ .pvr_value = 0x12C41C80,
+ .cpu_name = "APM821XX",
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE |
+ PPC_FEATURE_HAS_FPU,
+ .mmu_features = MMU_FTR_TYPE_44x,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .cpu_setup = __setup_cpu_apm821xx,
+ .machine_check = machine_check_440A,
+ .platform = "ppc440",
+ },
{ /* 476 core */
.pvr_mask = 0xffff0000,
.pvr_value = 0x11a50000,
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 69d668c..0f979c5 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -17,6 +17,16 @@ config BAMBOO
help
This option enables support for the IBM PPC440EP evaluation board.
+config BLUESTONE
+ bool "Bluestone"
+ depends on 44x
+ default n
+ select PPC44x_SIMPLE
+ select APM821xx
+ select IBM_NEW_EMAC_RGMII
+ help
+ This option enables support for the APM APM821xx Evaluation board.
+
config EBONY
bool "Ebony"
depends on 44x
@@ -293,6 +303,12 @@ config 460SX
select IBM_NEW_EMAC_ZMII
select IBM_NEW_EMAC_TAH
+config APM821xx
+ bool
+ select PPC_FPU
+ select IBM_NEW_EMAC_EMAC4
+ select IBM_NEW_EMAC_TAH
+
# 44x errata/workaround config symbols, selected by the CPU models above
config IBM440EP_ERR42
bool
diff --git a/arch/powerpc/platforms/44x/ppc44x_simple.c b/arch/powerpc/platforms/44x/ppc44x_simple.c
index 5f7a29d..7ddcba3 100644
--- a/arch/powerpc/platforms/44x/ppc44x_simple.c
+++ b/arch/powerpc/platforms/44x/ppc44x_simple.c
@@ -52,6 +52,7 @@ machine_device_initcall(ppc44x_simple, ppc44x_device_probe);
static char *board[] __initdata = {
"amcc,arches",
"amcc,bamboo",
+ "amcc,bluestone",
"amcc,canyonlands",
"amcc,glacier",
"ibm,ebony",
--
1.6.1.rc3
^ permalink raw reply related
* Re: [PATCH 02/25] arch/powerpc: Use static const char arrays
From: Stephen Rothwell @ 2010-09-14 2:02 UTC (permalink / raw)
To: Joe Perches; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <a2d6296e9aabed2de77ae0b44f16b13008129e48.1284406638.git.joe@perches.com>
[-- Attachment #1: Type: text/plain, Size: 591 bytes --]
Hi Joe,
On Mon, 13 Sep 2010 12:47:40 -0700 Joe Perches <joe@perches.com> wrote:
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> arch/powerpc/boot/addnote.c | 4 ++--
> arch/powerpc/boot/cuboot-c2k.c | 4 ++--
> arch/powerpc/kernel/irq.c | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
I am also unsure that the transformation to cuboot-c2k.c adds anything.
Other than that
Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 02/25] arch/powerpc: Use static const char arrays
From: Stephen Rothwell @ 2010-09-14 2:04 UTC (permalink / raw)
To: Joe Perches; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <a2d6296e9aabed2de77ae0b44f16b13008129e48.1284406638.git.joe@perches.com>
[-- Attachment #1: Type: text/plain, Size: 168 bytes --]
BTW, Ben Herrenschmidt is the current PowerPC maintainer.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 04/25] drivers/char: Use static const char arrays
From: Stephen Rothwell @ 2010-09-14 2:06 UTC (permalink / raw)
To: Joe Perches; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <a2936d6a439d294efa41dd567d29d0d301e844de.1284406638.git.joe@perches.com>
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
Hi Joe,
On Mon, 13 Sep 2010 12:47:42 -0700 Joe Perches <joe@perches.com> wrote:
>
> Signed-off-by: Joe Perches <joe@perches.com>
Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* RE: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Zang Roy-R61911 @ 2010-09-14 4:09 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: dedekind1, Lan Chunhe-B25806, linuxppc-dev, linux-mtd,
Geert Uytterhoeven, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <20100913112749.2fb32b3d@schlenkerla.am.freescale.net>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, September 14, 2010 0:28 AM
> To: Zang Roy-R61911
> Cc: Geert Uytterhoeven; linux-mtd@lists.infradead.org; Wood =
Scott-B07421;
> dedekind1@gmail.com; Lan Chunhe-B25806; linuxppc-dev@ozlabs.org; =
akpm@linux-
> foundation.org; dwmw2@infradead.org; Gala Kumar-B11780
> Subject: Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc =
issue with
> 36bit mode
>=20
> On Mon, 13 Sep 2010 00:22:10 -0700
> "Zang Roy-R61911" <r61911@freescale.com> wrote:
>=20
> >
> >
> > > -----Original Message-----
> > > From: geert.uytterhoeven@gmail.com =
[mailto:geert.uytterhoeven@gmail.com]
> On
> > > Behalf Of Geert Uytterhoeven
> > > Sent: Thursday, September 09, 2010 19:06 PM
> > > To: Zang Roy-R61911
> > > Cc: linux-mtd@lists.infradead.org; Wood Scott-B07421; =
dedekind1@gmail.com;
> Lan
> > > Chunhe-B25806; linuxppc-dev@ozlabs.org; akpm@linux-foundation.org;
> > > dwmw2@infradead.org; Gala Kumar-B11780
> > > Subject: Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc =
issue
> with
> > > 36bit mode
> > >
> > > On Thu, Sep 9, 2010 at 12:20, Roy Zang =
<tie-fei.zang@freescale.com> wrote:
> > > > From: Lan Chunhe-B25806 <b25806@freescale.com>
> > > >
> > > > When system uses 36bit physical address, res.start is 36bit
> > > > physical address. But the function of in_be32 returns 32bit
> > > > physical address. Then both of them compared each other is
> > > > wrong. So by converting the address of res.start into
> > > > the right format fixes this issue.
> > >
> > > > =A0/**
> > > > + * fsl_lbc_addr - convert the base address
> > > > + * @addr_base: base address of the memory bank
> > > > + *
> > > > + * This function converts a base address of lbc into the right =
format
> for
> > > the BR
> > > > + * registers. If the SOC has eLBC then it returns 32bit =
physical
> address
> > > else
> > > > + * it returns 34bit physical address for local bus(Example: =
MPC8641).
> > > > + */
> > > > +unsigned int fsl_lbc_addr(phys_addr_t addr_base)
> > > ^^^^^^^^^^^^
> > > Shouldn't this be u32 or __be32, for consistency with the actual
> > > comparisons below?
> > __be32 is better.
>=20
> I disagree, the return from this function is native-endian. It should
> be u32.
But the return of this value is ONLY used for br comparing. It is big =
endia.
Thanks.
Roy=20
^ permalink raw reply
* Re: linux-next: build warnings after merge of the final tree (tip treee related)
From: Stephen Rothwell @ 2010-09-14 4:50 UTC (permalink / raw)
To: Yinghai Lu
Cc: Peter Zijlstra, linux-kernel, linux-next, H. Peter Anvin,
Ingo Molnar, ppc-dev, Thomas Gleixner
In-Reply-To: <4C8DDFB4.1020508@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2881 bytes --]
Hi Yinghai,
On Mon, 13 Sep 2010 01:24:20 -0700 Yinghai Lu <yinghai@kernel.org> wrote:
>
> On 09/12/2010 09:39 PM, Stephen Rothwell wrote:
> >
> > Your patch fixes some of the warnings, but still leaves these for a
> > powerpc allnoconfig build:
> >
> > WARNING: mm/built-in.o(.text+0x25d80): Section mismatch in reference from the function memblock_double_array() to the function .init.text:memblock_free()
> > The function memblock_double_array() references
> > the function __init memblock_free().
> > This is often because memblock_double_array lacks a __init
> > annotation or the annotation of memblock_free is wrong.
> >
> > WARNING: mm/built-in.o(.text+0x26318): Section mismatch in reference from the function memblock_reserve_reserved_regions() to the function .init.text:memblock_reserve()
> > The function memblock_reserve_reserved_regions() references
> > the function __init memblock_reserve().
> > This is often because memblock_reserve_reserved_regions lacks a __init
> > annotation or the annotation of memblock_reserve is wrong.
> >
> > WARNING: mm/built-in.o(.text+0x26490): Section mismatch in reference from the function memblock_free_reserved_regions() to the function .init.text:memblock_free()
> > The function memblock_free_reserved_regions() references
> > the function __init memblock_free().
> > This is often because memblock_free_reserved_regions lacks a __init
> > annotation or the annotation of memblock_free is wrong.
>
> v1 already changed them all to __init_memblock, so we should not have those warnings.
They are still marked as __init in include/linux/memblock.h. I don't
think that they need to be marked at all there.
> > And these for a i386 defconfig build:
> >
> > WARNING: mm/built-in.o(.text+0x1e261): Section mismatch in reference from the function memblock_is_memory() to the variable .init.data:memblock
> > The function memblock_is_memory() references
> > the variable __initdata memblock.
> > This is often because memblock_is_memory lacks a __initdata
> > annotation or the annotation of memblock is wrong.
> >
> > WARNING: mm/built-in.o(.text+0x1e27f): Section mismatch in reference from the function memblock_is_region_memory() to the variable .init.data:memblock
> > The function memblock_is_region_memory() references
> > the variable __initdata memblock.
> > This is often because memblock_is_region_memory lacks a __initdata
> > annotation or the annotation of memblock is wrong.
>
> you must have old gcc, those functions are not used with i386.
I am not sure what the compiler version has to do with it, but I am using
gcc 4.4.4 which is fairly recent. The X86 Kconfig selects HAVE_MEMBLOCK
unconditionally, so mm/memblock.c is built on i386.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: pci_request_regions() failure
From: tiejun.chen @ 2010-09-14 5:38 UTC (permalink / raw)
To: Ravi Gupta; +Cc: linuxppc-dev
In-Reply-To: <AANLkTinPb2KYDtb2fRZ0n9d2=sB1GU1o-LygPFe_BGwp@mail.gmail.com>
Ravi Gupta wrote:
> Hi Tiejun,
>
> Firstly I think we'd better print the BAR0 and BAR1 on the probe function of
>> your device driver because you have to make sure if a8000000-a803ffff is
>> assigned to BAR0 and 0xa8040000-0xa807ffff for BAR1 as we expect.
>>
>> u32 value;
>> pci_read_config_word(pdev, PCI_BASE_ADDRESS_0, &value); printk...
>> pci_read_config_word(pdev, PCI_BASE_ADDRESS_1, &value); printk....
>>
>>
> Both the BAR's values are coming out to be zero.
>
>
>> And you can print this pci_resource_start(pdev, bar),
>> pci_resource_len(pdev,
>> bar) from the function, __pci_request_region, on the file
>> drivers/pci/pci.c.
>> Please check this as well.
>>
>
> I have done the changes in the __pci_request_region. But as you suggested
> earlier that one should call pci_request_regions() after pci_enable_device()
> in the driver code. My driver is failing at the pci_enable_device() only.
> Hence __pci_request_region() is not getting called. If, just for RND, I call
> pci_request_regions() before pci_enable_device(), it give me the following
> O/P.
>
> __pci_request_region : Base Address = 0
> __pci_request_region : Length Address = 1125903130362788
> __pci_request_region : Base Address = 0
> __pci_request_region : Length Address = 1125903130362788
According to these values I think the kernel don't assign the resources to your
PCI device.
>
>
>> And currently we have to debug this so on the function,
>> __pci_assign_resource,
>> from the file drivers/pci/setup-res.c, we can force skipping temporarily
>> pci_bus_alloc_resource for bus 0001:01 since that will call
>> pci_update_resource
>> for bus 0001:01.
>>
>> static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
>> int resno)
>> {
>> struct resource *res = dev->resource + resno;
>> resource_size_t size, min, align;
>> int ret;
>>
>> size = resource_size(res);
>> min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO :
>> PCIBIOS_MIN_MEM;
>> align = pci_resource_alignment(dev, res);
>> -------
>> if (bus->number == 0x01) {
>> ret = -ENOMEM
>> return ret;
>> }
>> -------
>>
>> I means we don't want to assign resource as the below line on the log.
>> ------
>> pci 0001:01:00.0: BAR 8: assigned [mem 0xa8000000-0xa80fffff]
>>
>> I expect the following output:
>> ------
>> pci 0001:01:00.0: BAR 8: can't assign mem pref (size 0x100000)
>>
>>
> This I have done successfully.
Sure.
>
> Dmesg
> ================================================================
> Using MPC837x RDB/WLAN machine description
> Initializing cgroup subsys cpuset
> Initializing cgroup subsys cpu
> Linux version 2.6.35 (okapi@okapi) (gcc version 4.2.3 (Sourcery G++ Lite
> 4.2-171)) #35 Mon Sep 13 13:43:01 IST 2010
> Found initrd at 0xcf46d000:0xcf7b15b7
> Found legacy serial port 0 for /immr@e0000000/serial@4500
> mem=e0004500, taddr=e0004500, irq=0, clk=400000002, speed=0
> Found legacy serial port 1 for /immr@e0000000/serial@4600
> mem=e0004600, taddr=e0004600, irq=0, clk=400000002, speed=0
> bootconsole [udbg0] enabled
> Found FSL PCI host bridge at 0x00000000e0008500. Firmware bus number: 0->0
> PCI host bridge /pci@e0008500 (primary) ranges:
> MEM 0x0000000090000000..0x000000009fffffff -> 0x0000000090000000
> MEM 0x0000000080000000..0x000000008fffffff -> 0x0000000080000000 Prefetch
> IO 0x00000000e0300000..0x00000000e03fffff -> 0x0000000000000000
> No pci config register base in dev tree, using default
> Found FSL PCI host bridge at 0x00000000e0009000. Firmware bus number: 0->255
> PCI host bridge /pcie@e0009000 ranges:
> MEM 0x00000000a8000000..0x00000000b7ffffff -> 0x00000000a8000000
> IO 0x00000000b8000000..0x00000000b87fffff -> 0x0000000000000000
> No pci config register base in dev tree, using default
> Found FSL PCI host bridge at 0x00000000e000a000. Firmware bus number: 0->255
> PCI host bridge /pcie@e000a000 ranges:
> MEM 0x00000000c8000000..0x00000000d7ffffff -> 0x00000000c8000000
> IO 0x00000000d8000000..0x00000000d87fffff -> 0x0000000000000000
> Top of RAM: 0x10000000, Total RAM: 0x10000000
> Memory hole size: 0MB
> Zone PFN ranges:
> DMA 0x00000000 -> 0x00010000
> Normal empty
> HighMem empty
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0x00000000 -> 0x00010000
> On node 0 totalpages: 65536
> free_area_init_node: node 0, pgdat c042d978, node_mem_map c0800000
> DMA zone: 512 pages used for memmap
> DMA zone: 0 pages reserved
> DMA zone: 65024 pages, LIFO batch:15
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
> Kernel command line: root=/dev/ram ramdisk_size=120000 rw ip=10.20.50.230:10
> .20.50.70:10.20.50.50:255.255.0.0:PowerQUICC:eth0:off console=ttyS0,115200
> mtdparts=nand:4m(kernel),-(jffs2)
> PID hash table entries: 1024 (order: 0, 4096 bytes)
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> High memory: 0k
> Memory: 249920k/262144k available (4092k kernel code, 12224k reserved, 248k
> data, 2207k bss, 192k init)
> Kernel virtual memory layout:
> * 0xfffcf000..0xfffff000 : fixmap
> * 0xff800000..0xffc00000 : highmem PTEs
> * 0xfe6f7000..0xff800000 : early ioremap
> * 0xd1000000..0xfe6f7000 : vmalloc & ioremap
> Hierarchical RCU implementation.
> RCU-based detection of stalled CPUs is disabled.
> Verbose stalled-CPUs detection is disabled.
> NR_IRQS:512
> IPIC (128 IRQ sources) at d1000700
> time_init: decrementer frequency = 100.000000 MHz
> time_init: processor frequency = 800.000004 MHz
> clocksource: timebase mult[2800000] shift[22] registered
> clockevent: decrementer mult[19999999] shift[32] cpu[0]
> Console: colour dummy device 80x25
> pid_max: default: 32768 minimum: 301
> Security Framework initialized
> SELinux: Disabled at boot.
> Mount-cache hash table entries: 512
> Initializing cgroup subsys ns
> Initializing cgroup subsys cpuacct
> Initializing cgroup subsys devices
> NET: Registered protocol family 16
> irq: irq 38 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 38
> __irq_set_trigger: setting type, irq = 38, flags = 8
> ipic_set_irq_type function, with virq = 38, flow = 8
> irq: irq 74 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 74
> __irq_set_trigger: setting type, irq = 74, flags = 8
> ipic_set_irq_type function, with virq = 74, flow = 8
> irq: irq 75 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 75
> __irq_set_trigger: setting type, irq = 75, flags = 8
> ipic_set_irq_type function, with virq = 75, flow = 8
> PCI: Probing PCI hardware
> PCI: Scanning PHB /pci@e0008500
> PCI: PHB IO resource = 0000000000000000-00000000000fffff [100]
> PCI: PHB MEM resource 0 = 0000000090000000-000000009fffffff [200]
> PCI: PHB MEM resource 1 = 0000000080000000-000000008fffffff [2200]
> PCI: PHB MEM offset = 0000000000000000
> PCI: PHB IO offset = 00000000
> probe mode: 0
> pci_bus 0000:00: scanning bus
> pci : vendor id = 0x1957
> pci 0000:00:00.0: found [1957:00c6] class 000b20 header type 00
> pci 0000:00:00.0: reg 10: [mem 0x00000000-0x000fffff]
> pci 0000:00:00.0: reg 18: [mem 0x00000000-0x0fffffff 64bit pref]
> pci 0000:00:00.0: calling fixup_hide_host_resource_fsl+0x0/0x58
> pci 0000:00:00.0: calling pcibios_fixup_resources+0x0/0x180
> pci 0000:00:00.0: calling quirk_fsl_pcie_header+0x0/0x48
> pci 0000:00:00.0: calling quirk_resource_alignment+0x0/0x1c0
> pci 0000:00:00.0: supports D1 D2
> pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot
> pci 0000:00:00.0: PME# disabled
> pci_bus 0000:00: fixups for bus
> PCI: Fixup bus devices 0 (PHB)
> PCI: Try to map irq for 0000:00:00.0...
> pci_bus 0000:00: bus scan returning with max=00
> PCI: Scanning PHB /pcie@e0009000
> PCI: PHB IO resource = 00000000ff7fe000-00000000ffffdfff [100]
> PCI: PHB MEM resource 0 = 00000000a8000000-00000000b7ffffff [200]
> PCI: PHB MEM offset = 0000000000000000
> PCI: PHB IO offset = ff7fe000
> probe mode: 0
> pci_bus 0001:01: scanning bus
> pci : vendor id = 0x1957
> pci 0001:01:00.0: found [1957:00c6] class 000b20 header type 01
> pci 0001:01:00.0: ignoring class b20 (doesn't match header type 01)
> pci 0001:01:00.0: calling fixup_hide_host_resource_fsl+0x0/0x58
> pci 0001:01:00.0: calling pcibios_fixup_resources+0x0/0x180
> pci 0001:01:00.0: calling quirk_fsl_pcie_header+0x0/0x48
> pci 0001:01:00.0: calling quirk_resource_alignment+0x0/0x1c0
> pci 0001:01:00.0: supports D1 D2
> pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot
> pci 0001:01:00.0: PME# disabled
> pci_bus 0001:01: fixups for bus
> PCI: Fixup bus devices 1 (PHB)
> PCI: Try to map irq for 0001:01:00.0...
> pci 0001:01:00.0: scanning [bus 01-ff] behind bridge, pass 0
> pci 0001:01:00.0: bus configuration invalid, reconfiguring
> pci 0001:01:00.0: scanning [bus 00-00] behind bridge, pass 1
> pci_bus 0001:02: scanning bus
> pci : vendor id = 0x1204
> pci 0001:02:00.0: trying to set all zeros in BARs
> pci 0001:02:00.0: found [1204:e250] class 000000 header type 00
> pci 0001:02:00.0: reg 10: [mem 0x00000000-0x0003ffff]
> pci 0001:02:00.0: reg 14: [mem 0x00000000-0x0003ffff]
> pci 0001:02:00.0: calling pcibios_fixup_resources+0x0/0x180
> PCI:0001:02:00.0 Resource 0 0000000000000000-000000000003ffff [40200] is
> unassigned
> PCI:0001:02:00.0 Resource 1 0000000000000000-000000000003ffff [40200] is
> unassigned
> pci 0001:02:00.0: calling quirk_resource_alignment+0x0/0x1c0
> pci_bus 0001:02: fixups for bus
> pci 0001:01:00.0: PCI bridge to [bus 02-ff]
> pci 0001:01:00.0: bridge window [io 0x0000-0x0000] (disabled)
> pci 0001:01:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
> pci 0001:01:00.0: bridge window [mem 0x00000000-0x000fffff pref]
> (disabled)
> PCI: Fixup bus devices 2 (0001:01:00.0)
> PCI: Try to map irq for 0001:02:00.0...
> Got one, spec 2 cells (0x00000001 0x00000008...) on /immr@e0000000
> /interrupt-controller@700
> irq: irq 1 on host /immr@e0000000/interrupt-controller@700 mapped to virtual
> irq 16
> __irq_set_trigger: setting type, irq = 16, flags = 8
> ipic_set_irq_type function, with virq = 16, flow = 8
> Mapped to linux irq 16
> pci_bus 0001:02: bus scan returning with max=02
> pci_bus 0001:01: bus scan returning with max=02
> PCI: Scanning PHB /pcie@e000a000
> PCI: PHB IO resource = 00000000feffc000-00000000ff7fbfff [100]
> PCI: PHB MEM resource 0 = 00000000c8000000-00000000d7ffffff [200]
> PCI: PHB MEM offset = 0000000000000000
> PCI: PHB IO offset = feffc000
> probe mode: 0
> pci_bus 0002:03: scanning bus
> pci_bus 0002:03: fixups for bus
> PCI: Fixup bus devices 3 (PHB)
> pci_bus 0002:03: bus scan returning with max=03
> PCI->OF bus map:
> 0 -> 0
> 1 -> 0
> 3 -> 0
> PCI: Allocating bus resources for 0000:00...
> PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000fffff [0x100],
> parent c0405660 (PCI IO)
> PCI: PHB (bus 0) bridge rsrc 1: 0000000090000000-000000009fffffff [0x200],
> parent c0405644 (PCI mem)
> PCI: PHB (bus 0) bridge rsrc 2: 0000000080000000-000000008fffffff [0x2200],
> parent c0405644 (PCI mem)
> PCI: Allocating bus resources for 0001:01...
> PCI: PHB (bus 1) bridge rsrc 0: 00000000ff7fe000-00000000ffffdfff [0x100],
> parent c0405660 (PCI IO)
> PCI: PHB (bus 1) bridge rsrc 1: 00000000a8000000-00000000b7ffffff [0x200],
> parent c0405644 (PCI mem)
> PCI: Allocating bus resources for 0001:02...
> PCI: Allocating bus resources for 0002:03...
> PCI: PHB (bus 3) bridge rsrc 0: 00000000feffc000-00000000ff7fbfff [0x100],
> parent c0405660 (PCI IO)
> PCI: PHB (bus 3) bridge rsrc 1: 00000000c8000000-00000000d7ffffff [0x200],
> parent c0405644 (PCI mem)
> Reserving legacy ranges for domain 0000
> Candidate legacy IO: [io 0x0000-0x0fff]
> hose mem offset: 0000000000000000
> hose mem res: [mem 0x90000000-0x9fffffff]
> hose mem res: [mem 0x80000000-0x8fffffff pref]
> Reserving legacy ranges for domain 0001
> Candidate legacy IO: [io 0xff7fe000-0xff7fefff]
> hose mem offset: 0000000000000000
> hose mem res: [mem 0xa8000000-0xb7ffffff]
> Reserving legacy ranges for domain 0002
> Candidate legacy IO: [io 0xfeffc000-0xfeffcfff]
> hose mem offset: 0000000000000000
> hose mem res: [mem 0xc8000000-0xd7ffffff]
> PCI: Assigning unassigned resources...
> pci 0001:01:00.0: BAR 8: can't assign mem (size 0x100000)
> pci 0001:01:00.0: PCI bridge to [bus 02-02]
> pci 0001:01:00.0: __pci_setup_bridge: Disabling prefetch window.
> pci 0001:01:00.0: __pci_setup_bridge: Prefetch window disabled successfully.
> pci 0001:01:00.0: bridge window [io disabled]
> pci 0001:01:00.0: bridge window [mem disabled]
> pci 0001:01:00.0: bridge window [mem pref disabled]
I cannot see 0001:02 is assigned again. I guess the code we modify issue 0001:02
is skipped so please check. I only hope do for 0001:01, not 0001:02.
And I think we have to clean all pre-allocated resource from the bootloader.
Firstly remove all previous change from your kernel to restore the original state.
Add the follows into kernel. (i.e. your target.c)
void debug_pci_fixup_resource(struct pci_dev* dev)
{
pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, 0);
pci_write_config_dword(dev, PCI_BASE_ADDRESS_1, 0);
if (dev->hdr_type == PCI_HEADER_TYPE_NORMAL) {
pci_write_config_dword(dev, PCI_BASE_ADDRESS_2, 0);
pci_write_config_dword(dev, PCI_BASE_ADDRESS_3, 0);
pci_write_config_dword(dev, PCI_BASE_ADDRESS_4, 0);
pci_write_config_dword(dev, PCI_BASE_ADDRESS_5, 0);
}
}
DECLARE_PCI_FIXUP_EARLY(PCI_ANY_ID, PCI_ANY_ID, debug_pci_fixup_resource);
Then you try to track why we miss allocating 0001:02.
Cheers
Tiejun
> pci_bus 0000:00: resource 0 [io 0x0000-0xfffff]
> pci_bus 0000:00: resource 1 [mem 0x90000000-0x9fffffff]
> pci_bus 0000:00: resource 2 [mem 0x80000000-0x8fffffff pref]
> pci_bus 0001:01: resource 0 [io 0xff7fe000-0xffffdfff]
> pci_bus 0001:01: resource 1 [mem 0xa8000000-0xb7ffffff]
> pci_bus 0002:03: resource 0 [io 0xfeffc000-0xff7fbfff]
> pci_bus 0002:03: resource 1 [mem 0xc8000000-0xd7ffffff]
> Registering qe_ic with sysfs...
> Registering ipic with sysfs...
> bio: create slab <bio-0> at 0
> vgaarb: loaded
> SCSI subsystem initialized
> Switching to clocksource timebase
> NET: Registered protocol family 2
> IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP reno registered
> UDP hash table entries: 256 (order: 0, 4096 bytes)
> UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> NET: Registered protocol family 1
> pci 0000:00:00.0: calling quirk_cardbus_legacy+0x0/0x44
> pci 0000:00:00.0: calling quirk_usb_early_handoff+0x0/0x740
> pci 0001:01:00.0: calling quirk_cardbus_legacy+0x0/0x44
> pci 0001:01:00.0: calling quirk_usb_early_handoff+0x0/0x740
> pci 0001:02:00.0: calling quirk_cardbus_legacy+0x0/0x44
> pci 0001:02:00.0: calling quirk_usb_early_handoff+0x0/0x740
> PCI: CLS 32 bytes, default 32
> Trying to unpack rootfs image as initramfs...
> rootfs image is not initramfs (no cpio magic); looks like an initrd
> Freeing initrd memory: 3345k freed
> irq: irq 9 on host /immr@e0000000/interrupt-controller@700 mapped to virtual
> irq 17
> __irq_set_trigger: setting type, irq = 17, flags = 8
> ipic_set_irq_type function, with virq = 17, flow = 8
> irq: irq 10 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 18
> __irq_set_trigger: setting type, irq = 18, flags = 8
> ipic_set_irq_type function, with virq = 18, flow = 8
> irq: irq 80 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 80
> __irq_set_trigger: setting type, irq = 80, flags = 8
> ipic_set_irq_type function, with virq = 80, flow = 8
> audit: initializing netlink socket (disabled)
> type=2000 audit(0.220:1): initialized
> JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
> SGI XFS with security attributes, large block/inode numbers, no debug
> enabled
> msgmni has been set to 494
> alg: No test for cipher_null (cipher_null-generic)
> alg: No test for ecb(cipher_null) (ecb-cipher_null)
> alg: No test for digest_null (digest_null-generic)
> alg: No test for compress_null (compress_null-generic)
> alg: No test for stdrng (krng)
> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 17) is a 16550A
> console [ttyS0] enabled, bootconsole disabled
> serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 18) is a 16550A
> brd: module loaded
> of_mpc8xxx_spi_probe function called.
> irq: irq 16 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 19
> __irq_set_trigger: setting type, irq = 19, flags = 8
> ipic_set_irq_type function, with virq = 19, flow = 8
> mpc8xxx_spi_probe function called.
> mpc8xxx_spi e0007000.spi: at 0xd1078000 (irq = 19), CPU mode
> irq: irq 32 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 32
> __irq_set_trigger: setting type, irq = 32, flags = 8
> ipic_set_irq_type function, with virq = 32, flow = 8
> irq: irq 33 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 33
> __irq_set_trigger: setting type, irq = 33, flags = 8
> ipic_set_irq_type function, with virq = 33, flow = 8
> irq: irq 34 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 34
> __irq_set_trigger: setting type, irq = 34, flags = 8
> ipic_set_irq_type function, with virq = 34, flow = 8
> eth0: Gianfar Ethernet Controller Version 1.2, 04:00:00:00:00:0a
> eth0: Running with NAPI enabled
> eth0: RX BD ring size for Q[0]: 256
> eth0: TX BD ring size for Q[0]: 256
> irq: irq 35 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 35
> __irq_set_trigger: setting type, irq = 35, flags = 8
> ipic_set_irq_type function, with virq = 35, flow = 8
> irq: irq 36 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 36
> __irq_set_trigger: setting type, irq = 36, flags = 8
> ipic_set_irq_type function, with virq = 36, flow = 8
> irq: irq 37 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 37
> __irq_set_trigger: setting type, irq = 37, flags = 8
> ipic_set_irq_type function, with virq = 37, flow = 8
> eth1: Gianfar Ethernet Controller Version 1.2, 00:00:00:00:00:00
> eth1: Running with NAPI enabled
> eth1: RX BD ring size for Q[0]: 256
> eth1: TX BD ring size for Q[0]: 256
> ucc_geth: QE UCC Gigabit Ethernet Controller
> Freescale PowerQUICC MII Bus: probed
> irq: irq 17 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 20
> __irq_set_trigger: setting type, irq = 20, flags = 8
> ipic_set_irq_type function, with virq = 20, flow = 8
> Freescale PowerQUICC MII Bus: probed
> mice: PS/2 mouse device common for all mice
> Skipping unavailable LED gpio -19 (pwr)
> Skipping unavailable LED gpio -19 (hdd)
> TCP cubic registered
> NET: Registered protocol family 17
> registered taskstats version 1
> drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
> RAMDISK: gzip image found at block 0
> VFS: Mounted root (ext2 filesystem) on device 1:0.
> Freeing unused kernel memory: 192k init
> PHY: mdio@e0024520:02 - Link is Up - 10/Half
> ================================================================
>
> Regards,
> Ravi
>
^ 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