* Re: [PATCH] OF device tree: Move of_get_mac_address() to a common source file.
From: Timur Tabi @ 2010-11-01 12:04 UTC (permalink / raw)
To: Grant Likely
Cc: linux-mips, netdev, devicetree-discuss, David Daney, linux-kernel,
microblaze-uclinux, linuxppc-dev
In-Reply-To: <20101101051734.GB17587@angua.secretlab.ca>
On Mon, Nov 1, 2010 at 12:17 AM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
>> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
>> Cc: Michal Simek <monstr@monstr.eu>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Wolfram Sang <w.sang@pengutronix.de>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: Corey Minyard <cminyard@mvista.com>
>> Cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
>> Cc: Vitaly Bordug <vbordug@ru.mvista.com>
>> Cc: Anatolij Gustschin <agust@denx.de>
>> Cc: John Rigby <jcrigby@gmail.com>
>> Cc: Wolfgang Denk <wd@denx.de>
>> Cc: Anton Vorontsov <avorontsov@mvista.com>
>> Cc: Sandeep Gopalpet <Sandeep.Kumar@freescale.com>
>> Cc: Kumar Gala <galak@kernel.crashing.org>
>> Cc: Li Yang <leoli@freescale.com>
>> Cc: Sergey Matyukevich <geomatsi@gmail.com>
>> Cc: Jiri Pirko <jpirko@redhat.com>
>> Cc: Eric Dumazet <eric.dumazet@gmail.com>
>> Cc: Sean MacLennan <smaclennan@pikatech.com>
>> Cc: Sadanand Mutyala <Sadanand.Mutyala@xilinx.com>
>> Cc: Andres Salomon <dilinger@queued.net>
>> Cc: microblaze-uclinux@itee.uq.edu.au
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Cc: netdev@vger.kernel.org
>> Cc: devicetree-discuss@lists.ozlabs.org
>
> You don't need to believe everything that get_maintainers is telling
> you. =A0When you get a large list like this, don't Cc everyone, but
> apply some educated guesses. =A0You can guess that the PowerPC and
> Microblaze maintainers care because it touches their trees, and you
> can guess that I care because I'm the dt maintainer. David Miller
> isn't a bad guess because of networking. =A0But 22 people is excessive.
And ironically, he left out the person who wrote the function -- me.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] iSeries: Don't leak if allocations fail in mf_getSrcHistory
From: Michael Ellerman @ 2010-11-01 11:10 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel, Stephen Rothwell
In-Reply-To: <alpine.LNX.2.00.1010301911220.1572@swampdragon.chaosbits.net>
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]
On Sat, 2010-10-30 at 19:20 +0200, Jesper Juhl wrote:
> Hi,
>
> If memory is tight and a dynamic allocation fails there's no reason to
> make a bad situation worse by leaking memory.
>
> mf_getSrcHistory potentially leaks pages[0-3]. I believe the right thing
> to do is to free that memory again before returning -ENOMEM - which is
> what this patch does.
>
> I realize that the function is under '#if 0' so this probably doesn't
> matter much, but I assume that the function is still there for a reason
> (but I could be wrong, I don't know the powerpc code).
> Anyway, I suggest we remove the leak.
Stephen is the iSeries maintainer, and I think he #if 0'ed the code. But
I don't think it will ever be un-ifdef'ed, so should probably just be
removed.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 04/39] arch/powerpc: Update WARN uses
From: Michael Ellerman @ 2010-11-01 11:02 UTC (permalink / raw)
To: Joe Perches; +Cc: Paul Mackerras, Jiri Kosina, linuxppc-dev, linux-kernel
In-Reply-To: <c6c46b5924e1cc9720d3ad76e6c11e982bd661e5.1288471898.git.joe@perches.com>
[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]
On Sat, 2010-10-30 at 14:08 -0700, Joe Perches wrote:
> Coalesce long formats.
> Align arguments.
> Add missing newlines.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> arch/powerpc/kernel/hw_breakpoint.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
> index 5ecd040..d7343a7 100644
> --- a/arch/powerpc/kernel/hw_breakpoint.c
> +++ b/arch/powerpc/kernel/hw_breakpoint.c
> @@ -270,8 +270,8 @@ int __kprobes hw_breakpoint_handler(struct die_args *args)
> * message to let the user know about it.
> */
> if (!stepped) {
> - WARN(1, "Unable to handle hardware breakpoint. Breakpoint at "
> - "0x%lx will be disabled.", info->address);
> + WARN(1, "Unable to handle hardware breakpoint. Breakpoint at 0x%lx will be disabled.\n",
> + info->address);
That appears to have done nothing other than turn a short line into one
that is now > 80 columns. Is that the latest fad?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re:
From: Michal Simek @ 2010-11-01 6:29 UTC (permalink / raw)
To: microblaze-uclinux; +Cc: nacc, linuxppc-dev, miltonm
In-Reply-To: <1287422825-14999-2-git-send-email-nacc@us.ibm.com>
Hi,
Nishanth Aravamudan wrote:
> Use set_dma_ops and remove now used-once oddly named temp pointer sd.
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> Cc: benh@kernel.crashing.org
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> arch/microblaze/pci/pci-common.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
Is there any reason why you are sending me this patch again and again?
Please STOP doing this!
This patch was added to the mainline last week.
Regards,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [PATCH] OF device tree: Move of_get_mac_address() to a common source file.
From: Grant Likely @ 2010-11-01 5:17 UTC (permalink / raw)
To: David Daney
Cc: linux-mips, Corey Minyard, Anton Vorontsov, Paul Mackerras,
Sadanand Mutyala, Sergey Matyukevich, Sean MacLennan,
Wolfgang Denk, microblaze-uclinux, devicetree-discuss,
Andres Salomon, Michal Simek, Anatolij Gustschin, Eric Dumazet,
Jiri Pirko, netdev, linux-kernel, ralf, Sandeep Gopalpet,
Vitaly Bordug, linuxppc-dev, David S. Miller
In-Reply-To: <1288130833-16421-1-git-send-email-ddaney@caviumnetworks.com>
On Tue, Oct 26, 2010 at 03:07:13PM -0700, David Daney wrote:
> There are two identical implementations of of_get_mac_address(), one
> each in arch/powerpc/kernel/prom_parse.c and
> arch/microblaze/kernel/prom_parse.c. Move this function to a new
> common file of_net.{c,h} and adjust all the callers to include the new
> header.
Applied, thanks; but made some changes to protect this code because it
does not work on little endian (it can be fixed in a separate patch)
Also...
>
> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
> Cc: Michal Simek <monstr@monstr.eu>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Corey Minyard <cminyard@mvista.com>
> Cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
> Cc: Vitaly Bordug <vbordug@ru.mvista.com>
> Cc: Anatolij Gustschin <agust@denx.de>
> Cc: John Rigby <jcrigby@gmail.com>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Anton Vorontsov <avorontsov@mvista.com>
> Cc: Sandeep Gopalpet <Sandeep.Kumar@freescale.com>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: Li Yang <leoli@freescale.com>
> Cc: Sergey Matyukevich <geomatsi@gmail.com>
> Cc: Jiri Pirko <jpirko@redhat.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Sean MacLennan <smaclennan@pikatech.com>
> Cc: Sadanand Mutyala <Sadanand.Mutyala@xilinx.com>
> Cc: Andres Salomon <dilinger@queued.net>
> Cc: microblaze-uclinux@itee.uq.edu.au
> Cc: linux-kernel@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: netdev@vger.kernel.org
> Cc: devicetree-discuss@lists.ozlabs.org
You don't need to believe everything that get_maintainers is telling
you. When you get a large list like this, don't Cc everyone, but
apply some educated guesses. You can guess that the PowerPC and
Microblaze maintainers care because it touches their trees, and you
can guess that I care because I'm the dt maintainer. David Miller
isn't a bad guess because of networking. But 22 people is excessive.
g.
^ permalink raw reply
* eabi supported
From: Oliver Kowalke @ 2010-10-31 18:54 UTC (permalink / raw)
To: linuxppc-dev
Hi,
could you tell me which Linux distribution does support powerpc with
eabi (embedded abi)?
I tried 'T2 Project' but it doesn't offer ABI selection in its config
script.
thx,
Oliver
^ permalink raw reply
* Re: [PATCH v2 02/22] bitops: rename generic little-endian bitops functions
From: Hans-Christian Egtvedt @ 2010-10-31 14:02 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-arch, linux-m68k, kvm, Arnd Bergmann, David S. Miller,
Marcelo Tosatti, linux-kernel, rds-devel, Christoph Hellwig,
Andy Grover, netdev, Geert Uytterhoeven, Avi Kivity, Greg Ungerer,
Andreas Schwab, Andrew Morton, linuxppc-dev,
Hans-Christian Egtvedt, Paul Mackerras
In-Reply-To: <1287672077-5797-3-git-send-email-akinobu.mita@gmail.com>
Around Thu 21 Oct 2010 23:40:57 +0900 or thereabout, Akinobu Mita wrote:
> As a preparation for providing little-endian bitops for all architectures,
> This removes generic_ prefix from little-endian bitops function names
> in asm-generic/bitops/le.h.
>
> s/generic_find_next_le_bit/find_next_le_bit/
> s/generic_find_next_zero_le_bit/find_next_zero_le_bit/
> s/generic_find_first_zero_le_bit/find_first_zero_le_bit/
> s/generic___test_and_set_le_bit/__test_and_set_le_bit/
> s/generic___test_and_clear_le_bit/__test_and_clear_le_bit/
> s/generic_test_le_bit/test_le_bit/
> s/generic___set_le_bit/__set_le_bit/
> s/generic___clear_le_bit/__clear_le_bit/
> s/generic_test_and_set_le_bit/test_and_set_le_bit/
> s/generic_test_and_clear_le_bit/test_and_clear_le_bit/
>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> Cc: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Roman Zippel <zippel@linux-m68k.org>
> Cc: Andreas Schwab <schwab@linux-m68k.org>
> Cc: linux-m68k@lists.linux-m68k.org
> Cc: Greg Ungerer <gerg@uclinux.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Andy Grover <andy.grover@oracle.com>
> Cc: rds-devel@oss.oracle.com
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
> Cc: Avi Kivity <avi@redhat.com>
> Cc: Marcelo Tosatti <mtosatti@redhat.com>
> Cc: kvm@vger.kernel.org
> ---
> No change from previous submission
>
> arch/avr32/kernel/avr32_ksyms.c | 4 ++--
> arch/avr32/lib/findbit.S | 4 ++--
For the AVR32 changes.
Acked-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
<snipp patch>
--
Best regards, Hans-Christian Egtvedt
^ permalink raw reply
* Re: PowerMac G4 RAM
From: Benjamin Herrenschmidt @ 2010-10-31 11:28 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <AANLkTi=+kF+c=RC09_4V2wqw61xFhFHnvqYHAKbA0TpQ@mail.gmail.com>
On Sat, 2010-10-30 at 22:48 -0500, kevin diggs wrote:
> Hi,
>
> I have a G4 that has 1.25 G of ram. Under Linux I only get 768M?
> Anyone know why? It is a GiGE with a dual 7455 PowerLogix cpu upgrade.
> Kernel is 2.6.28.
Tried enabling CONFIG_HIGHMEM ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/1] powerpc: Fix initramfs size in PPC32 build
From: Geert Uytterhoeven @ 2010-10-31 10:14 UTC (permalink / raw)
To: Kerstin Jonsson, Hendrik Brueckner, Linus Torvalds
Cc: linux-arch, Michal Marek, linux-mmc, Linux Kernel Development,
Paul Mackerras, H. Peter Anvin, WANG Cong, Andrew Morton,
Michael Holzheu, linuxppc-dev
In-Reply-To: <1287742675-7614-1-git-send-email-kerstin.jonsson@ericsson.com>
On Fri, 22 Oct 2010, Kerstin Jonsson wrote:
> commit ffe8018c3424892c9590048fc36caa6c3e0c8a76 of the -mm tree
> fixes the initramfs size calculation for e.g. s390 but breaks it
> for 32bit architectures which do not define CONFIG_32BIT.
>
> This patch fix the problem for PPC32 which will elsewise end up
> with a __initramfs_size of 0.
>
> Signed-off-by: Kerstin Jonsson <kerstin.jonsson@ericsson.com>
> Cc: Paul Mackerras <paulus@samba.org>
> ---
> arch/powerpc/Kconfig | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 50cc5d9..d536fe4 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -4,6 +4,10 @@ config PPC32
> bool
> default y if !PPC64
>
> +config 32BIT
> + bool
> + default y if PPC32
> +
> config 64BIT
> bool
> default y if PPC64
> --
> 1.7.1
Thanks for the hint!
In the future, please CC linux-arch, or at least lkml, for things like this,
as it broke allmost all 32-bit arches.
Only mips, s390, and score set CONFIG_32BIT for 32-bit builds.
Would have saved me a bisection on m68k...
I came up with the alternative patch below to fix it in a single place.
---
>From d51254ca020a23050f1641d92d68113e55cc0467 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Sun, 31 Oct 2010 10:56:23 +0100
Subject: [PATCH] initramfs: Fix initramfs size for 32-bit arches
commit ffe8018c3424892c9590048fc36caa6c3e0c8a76 ("initramfs: fix initramfs size
calculation") broke 32-bit arches like (on ARAnyM):
VFS: Cannot open root device "hda1" or unknown-block(3,1)
Please append a correct "root=" boot option; here are the available partitions:
fe80 1059408 nfhd8 (driver?)
fe81 921600 nfhd8p1 00000000-0000-0000-0000-000000000nfhd8p1
fe82 137807 nfhd8p2 00000000-0000-0000-0000-000000000nfhd8p2
0200 3280 fd0 (driver?)
0201 3280 fd1 (driver?)
0300 1059408 hda driver: ide-gd
0301 921600 hda1 00000000-0000-0000-0000-000000000hda1
0302 137807 hda2 00000000-0000-0000-0000-000000000hda2
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,1)
As pointed out by Kerstin Jonsson <kerstin.jonsson@ericsson.com>, this is due
to CONFIG_32BIT not being defined.
Only mips, s390, and score set CONFIG_32BIT for 32-bit builds, so fix it for
all other 32-bit arches by inverting the logic and testing for CONFIG_64BIT,
which should be defined on all 64-bit arches.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
usr/initramfs_data.S | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/usr/initramfs_data.S b/usr/initramfs_data.S
index b9efed5..792a750 100644
--- a/usr/initramfs_data.S
+++ b/usr/initramfs_data.S
@@ -30,8 +30,8 @@ __irf_end:
.section .init.ramfs.info,"a"
.globl __initramfs_size
__initramfs_size:
-#ifdef CONFIG_32BIT
- .long __irf_end - __irf_start
-#else
+#ifdef CONFIG_64BIT
.quad __irf_end - __irf_start
+#else
+ .long __irf_end - __irf_start
#endif
--
1.7.0.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply related
* PowerMac G4 RAM
From: kevin diggs @ 2010-10-31 3:48 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I have a G4 that has 1.25 G of ram. Under Linux I only get 768M?
Anyone know why? It is a GiGE with a dual 7455 PowerLogix cpu upgrade.
Kernel is 2.6.28.
Thanks!
kevin
^ permalink raw reply
* Re: [PATCH] PowerPC/Cell: use vzalloc rather than vmalloc and memset in spu_alloc_lscsa_std
From: Arnd Bergmann @ 2010-10-30 21:41 UTC (permalink / raw)
To: Jesper Juhl; +Cc: cbe-oss-dev, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1010302004290.1572@swampdragon.chaosbits.net>
On Saturday 30 October 2010, Jesper Juhl wrote:
> We can get rid of a memset in
> arch/powerpc/platforms/cell/spufs/lscsa_alloc.c::spu_alloc_lscsa_std() by
> using vzalloc() rather than vmalloc()+memset().
>
> Completely untested patch below since I have no hardware nor tools to
> compile this.
>
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] PowerPC/Cell: use vzalloc rather than vmalloc and memset in spu_alloc_lscsa_std
From: Jeremy Kerr @ 2010-10-30 21:25 UTC (permalink / raw)
To: cbe-oss-dev
Cc: Arnd Bergmann, linux-kernel, Jesper Juhl, Paul Mackerras,
linuxppc-dev
In-Reply-To: <alpine.LNX.2.00.1010302004290.1572@swampdragon.chaosbits.net>
Jesper,
> We can get rid of a memset in
> arch/powerpc/platforms/cell/spufs/lscsa_alloc.c::spu_alloc_lscsa_std() by
> using vzalloc() rather than vmalloc()+memset().
Looks good to me.
Acked-By: Jeremy Kerr <jk@ozlabs.org>
Ben, could you apply this to the powerpc tree?
Cheers,
Jeremy
^ permalink raw reply
* [PATCH 04/39] arch/powerpc: Update WARN uses
From: Joe Perches @ 2010-10-30 21:08 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <cover.1288471897.git.joe@perches.com>
Coalesce long formats.
Align arguments.
Add missing newlines.
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/powerpc/kernel/hw_breakpoint.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
index 5ecd040..d7343a7 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -270,8 +270,8 @@ int __kprobes hw_breakpoint_handler(struct die_args *args)
* message to let the user know about it.
*/
if (!stepped) {
- WARN(1, "Unable to handle hardware breakpoint. Breakpoint at "
- "0x%lx will be disabled.", info->address);
+ WARN(1, "Unable to handle hardware breakpoint. Breakpoint at 0x%lx will be disabled.\n",
+ info->address);
perf_event_disable(bp);
goto out;
}
--
1.7.3.1.g432b3.dirty
^ permalink raw reply related
* [PATCH 00/39] Cleanup WARN #defines
From: Joe Perches @ 2010-10-30 21:08 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-fbdev, alsa-devel, dri-devel, socketcan-core, linux-mm,
devel, linux1394-devel, devel, linux-scsi, linux-acpi, linux-pm,
linux-media, linux-arch, intel-gfx, linux-tegra, linux-omap,
linux-arm-kernel, discuss, linux-nfs, netdev, linux-usb,
linux-wireless, linux-kernel, linux-alpha, linux-fsdevel,
linuxppc-dev
WARN uses sometimes use KERN_<level> but mostly don't
have any prefix.
Change the WARN macros and the warn_slowpath function to preface
KERN_WARNING and remove all the KERN_<level> uses from WARN sites.
Neatening clean up of include/asm-generic/bug.h
Update WARN macros
Add KERN_WARNING to WARN output
Remove any KERN_<level> from WARN uses
Coalesce formats
Align WARN arguments
Add some missing newlines to WARN uses
Add some missing first test argument (1, fmt, args) to WARN uses
Joe Perches (39):
include/asm-generic/bug.h: Update WARN macros
arch/alpha: Update WARN uses
arch/arm: Update WARN uses
arch/powerpc: Update WARN uses
arch/x86: Update WARN uses
drivers/acpi: Update WARN uses
drivers/base: Update WARN uses
drivers/block: Update WARN uses
drivers/cpuidle: Update WARN uses
drivers/firewire: Update WARN uses
drivers/firmware: Update WARN uses
drivers/gpio: Update WARN uses
drivers/gpu/drm: Update WARN uses
drivers/media/video: Update WARN uses
drivers/mfd: Update WARN uses
drivers/net/can: Update WARN uses
drivers/net/usb: Update WARN uses
drivers/net/wireless/iwlwifi: Update WARN uses
drivers/regulator: Update WARN uses
drivers/scsi/fcoe: Update WARN uses
drivers/staging: Update WARN uses
drivers/usb/musb: Update WARN uses
drivers/video/omap2/dss: Update WARN uses
fs/nfsd: Update WARN uses
fs/notify/inotify: Update WARN uses
fs/sysfs: Update WARN uses
fs/proc: Update WARN uses
fs: Update WARN uses
include/linux/device.h: Update WARN uses
kernel/irq: Update WARN uses
kernel/panic.c: Update warn_slowpath to use %pV
kernel: Update WARN uses
lib: Update WARN uses
mm: Update WARN uses
net/core/dev.c: Update WARN uses
net/ipv4/tcp.c: Update WARN uses
net/mac80211: Update WARN uses
net/rfkill/input.c: Update WARN uses
sound/soc/codecs/wm_hubs.c: Update WARN uses
arch/alpha/kernel/pci-sysfs.c | 14 ++--
arch/arm/mach-davinci/clock.c | 4 +-
arch/arm/mach-davinci/da830.c | 2 +-
arch/arm/mach-davinci/da850.c | 12 ++--
arch/arm/mach-omap2/clkt_clksel.c | 12 ++--
arch/arm/mach-omap2/clock.c | 16 ++--
arch/arm/mach-omap2/devices.c | 4 +-
arch/arm/mach-omap2/omap_hwmod.c | 47 +++++++-----
arch/arm/mach-omap2/pm34xx.c | 7 +-
arch/arm/mach-omap2/serial.c | 2 +-
arch/arm/mach-omap2/timer-gp.c | 3 +-
arch/arm/mach-tegra/clock.c | 3 +-
arch/arm/mach-tegra/timer.c | 2 +-
arch/arm/mach-u300/padmux.c | 14 +---
arch/arm/plat-omap/omap-pm-noop.c | 10 ++--
arch/powerpc/kernel/hw_breakpoint.c | 4 +-
arch/x86/kernel/acpi/boot.c | 2 +-
arch/x86/kernel/apic/apic.c | 2 +-
arch/x86/kernel/apic/es7000_32.c | 2 +-
arch/x86/kernel/cpu/perf_event.c | 4 +-
arch/x86/kernel/pci-calgary_64.c | 4 +-
arch/x86/kernel/tsc_sync.c | 4 +-
arch/x86/kernel/xsave.c | 2 +-
arch/x86/mm/ioremap.c | 5 +-
arch/x86/mm/pageattr-test.c | 2 +-
arch/x86/mm/pageattr.c | 5 +-
arch/x86/platform/sfi/sfi.c | 4 +-
drivers/acpi/ec.c | 4 +-
drivers/base/class.c | 4 +-
drivers/base/core.c | 5 +-
drivers/base/memory.c | 4 +-
drivers/base/sys.c | 10 +--
drivers/block/floppy.c | 2 +-
drivers/cpuidle/driver.c | 2 +-
drivers/firewire/core-transaction.c | 6 +-
drivers/firmware/dmi_scan.c | 2 +-
drivers/gpio/gpiolib.c | 4 +-
drivers/gpio/it8761e_gpio.c | 2 +-
drivers/gpu/drm/drm_crtc_helper.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 3 +-
drivers/gpu/drm/radeon/evergreen.c | 2 +-
drivers/gpu/drm/radeon/r100.c | 4 +-
drivers/gpu/drm/radeon/r300.c | 2 +-
drivers/gpu/drm/radeon/r600.c | 4 +-
drivers/gpu/drm/radeon/radeon_fence.c | 3 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 3 +-
drivers/gpu/drm/radeon/rs400.c | 2 +-
drivers/gpu/drm/radeon/rs600.c | 4 +-
drivers/media/video/s5p-fimc/fimc-core.c | 2 +-
drivers/media/video/sr030pc30.c | 2 +-
drivers/mfd/ezx-pcap.c | 5 +-
drivers/net/can/mscan/mscan.c | 2 +-
drivers/net/usb/ipheth.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-agn-sta.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-tx.c | 6 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +-
drivers/regulator/core.c | 3 +-
drivers/scsi/fcoe/libfcoe.c | 2 +-
drivers/staging/memrar/memrar_allocator.c | 2 +-
drivers/staging/solo6x10/solo6010-v4l2-enc.c | 2 +-
drivers/usb/musb/musb_host.c | 6 +-
drivers/video/omap2/dss/core.c | 3 +-
fs/bio.c | 2 +-
fs/buffer.c | 2 +-
fs/nfsd/nfs4state.c | 3 +-
fs/notify/inotify/inotify_fsnotify.c | 4 +-
fs/proc/generic.c | 9 +--
fs/super.c | 5 +-
fs/sysfs/dir.c | 3 +-
fs/sysfs/file.c | 4 +-
fs/sysfs/group.c | 4 +-
fs/sysfs/symlink.c | 10 +--
include/asm-generic/bug.h | 101 ++++++++++++++++----------
include/linux/device.h | 2 +-
kernel/irq/chip.c | 2 +-
kernel/irq/manage.c | 2 +-
kernel/notifier.c | 2 +-
kernel/panic.c | 40 +++++------
kernel/pm_qos_params.c | 6 +-
lib/debugobjects.c | 21 +++---
lib/iomap.c | 2 +-
lib/kobject.c | 9 +--
lib/kobject_uevent.c | 4 +-
lib/list_debug.c | 24 +++----
lib/plist.c | 12 ++--
mm/percpu.c | 4 +-
mm/vmalloc.c | 5 +-
net/core/dev.c | 3 +-
net/ipv4/tcp.c | 16 ++---
net/mac80211/agg-tx.c | 5 +-
net/mac80211/iface.c | 4 +-
net/mac80211/mlme.c | 2 +-
net/mac80211/rx.c | 4 +-
net/mac80211/tx.c | 4 +-
net/mac80211/util.c | 4 +-
net/mac80211/work.c | 4 +-
net/rfkill/input.c | 5 +-
sound/soc/codecs/wm_hubs.c | 2 +-
99 files changed, 319 insertions(+), 330 deletions(-)
--
1.7.3.1.g432b3.dirty
^ permalink raw reply
* Re: [MPC8xx] Initial MMU too low
From: Benjamin Herrenschmidt @ 2010-10-30 20:47 UTC (permalink / raw)
To: LEROY christophe; +Cc: linuxppc-dev
In-Reply-To: <4CCC06F8.3020506@c-s.fr>
On Sat, 2010-10-30 at 13:52 +0200, LEROY christophe wrote:
> Hello,
>
> When I build a kernel with DEBUG_LOCK_ALLOC set, I get a kernel which
> has __bss_stop above the C0800000 limit, and then I get a bad page
> exception during the zeroize of the __bss at startup, because the
> initial MMU only maps the first 8Mbytes.
>
> What can I do to fix that ?
Not much... maybe pin more initial TLBs ?
Ben.
^ permalink raw reply
* Re: [PATCH v2] powerpc: kvm: powerpc: fix information leak to userland
From: Alexander Graf @ 2010-10-30 19:16 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: kvm, Marcelo Tosatti, kernel-janitors, linux-kernel, kvm-ppc,
Paul Mackerras, Avi Kivity, linuxppc-dev
In-Reply-To: <1288464922-8812-1-git-send-email-segooon@gmail.com>
On 30.10.2010, at 11:55, Vasiliy Kulikov wrote:
> Structure kvm_ppc_pvinfo is copied to userland with "flags" and "pad"
> fields unitialized. It leads to leaking of contents of kernel stack
> memory. We have to initialize them to zero.
>=20
> In patch v1 Jan Kiszka suggested to fill reserved fields with zeros
> instead of memset'ting the whole struct. It makes sense as these
> fields are explicitly marked as padding. No more fields need zeroing.
>=20
> Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
> ---
> arch/powerpc/kvm/powerpc.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 2f87a16..5962336 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -604,6 +604,8 @@ static int kvm_vm_ioctl_get_pvinfo(struct =
kvm_ppc_pvinfo *pvinfo)
> pvinfo->hcall[1] =3D inst_ori | (KVM_SC_MAGIC_R0 & =
inst_imm_mask);
> pvinfo->hcall[2] =3D inst_sc;
> pvinfo->hcall[3] =3D inst_nop;
> + pvinfo->flags =3D 0;
> + memset(&pvinfo->pad, 0, sizeof(pvinfo->pad));
This should only be memset(pvinfo->pad), no? It's an array after all =
which automatically translates to a pointer when referenced.
Alex
^ permalink raw reply
* [PATCH v2] powerpc: kvm: powerpc: fix information leak to userland
From: Vasiliy Kulikov @ 2010-10-30 18:55 UTC (permalink / raw)
To: kernel-janitors
Cc: kvm, Marcelo Tosatti, Alexander Graf, kvm-ppc, linux-kernel,
Paul Mackerras, Avi Kivity, linuxppc-dev
Structure kvm_ppc_pvinfo is copied to userland with "flags" and "pad"
fields unitialized. It leads to leaking of contents of kernel stack
memory. We have to initialize them to zero.
In patch v1 Jan Kiszka suggested to fill reserved fields with zeros
instead of memset'ting the whole struct. It makes sense as these
fields are explicitly marked as padding. No more fields need zeroing.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
---
arch/powerpc/kvm/powerpc.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 2f87a16..5962336 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -604,6 +604,8 @@ static int kvm_vm_ioctl_get_pvinfo(struct kvm_ppc_pvinfo *pvinfo)
pvinfo->hcall[1] = inst_ori | (KVM_SC_MAGIC_R0 & inst_imm_mask);
pvinfo->hcall[2] = inst_sc;
pvinfo->hcall[3] = inst_nop;
+ pvinfo->flags = 0;
+ memset(&pvinfo->pad, 0, sizeof(pvinfo->pad));
return 0;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH] PowerPC/Cell: use vzalloc rather than vmalloc and memset in spu_alloc_lscsa_std
From: Jesper Juhl @ 2010-10-30 18:10 UTC (permalink / raw)
To: linux-kernel; +Cc: cbe-oss-dev, Paul Mackerras, linuxppc-dev, Arnd Bergmann
Hi,
We can get rid of a memset in
arch/powerpc/platforms/cell/spufs/lscsa_alloc.c::spu_alloc_lscsa_std() by
using vzalloc() rather than vmalloc()+memset().
Completely untested patch below since I have no hardware nor tools to
compile this.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
lscsa_alloc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spufs/lscsa_alloc.c b/arch/powerpc/platforms/cell/spufs/lscsa_alloc.c
index a101abf..3b894f5 100644
--- a/arch/powerpc/platforms/cell/spufs/lscsa_alloc.c
+++ b/arch/powerpc/platforms/cell/spufs/lscsa_alloc.c
@@ -36,10 +36,9 @@ static int spu_alloc_lscsa_std(struct spu_state *csa)
struct spu_lscsa *lscsa;
unsigned char *p;
- lscsa = vmalloc(sizeof(struct spu_lscsa));
+ lscsa = vzalloc(sizeof(struct spu_lscsa));
if (!lscsa)
return -ENOMEM;
- memset(lscsa, 0, sizeof(struct spu_lscsa));
csa->lscsa = lscsa;
/* Set LS pages reserved to allow for user-space mapping. */
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Plain text mails only, please http://www.expita.com/nomime.html
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
^ permalink raw reply related
* [PATCH] iSeries: Don't leak if allocations fail in mf_getSrcHistory
From: Jesper Juhl @ 2010-10-30 17:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, linux-kernel
Hi,
If memory is tight and a dynamic allocation fails there's no reason to
make a bad situation worse by leaking memory.
mf_getSrcHistory potentially leaks pages[0-3]. I believe the right thing
to do is to free that memory again before returning -ENOMEM - which is
what this patch does.
I realize that the function is under '#if 0' so this probably doesn't
matter much, but I assume that the function is still there for a reason
(but I could be wrong, I don't know the powerpc code).
Anyway, I suggest we remove the leak.
Please keep me on CC when replying.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
mf.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/iseries/mf.c b/arch/powerpc/platforms/iseries/mf.c
index 42d0a88..f67522a 100644
--- a/arch/powerpc/platforms/iseries/mf.c
+++ b/arch/powerpc/platforms/iseries/mf.c
@@ -1058,8 +1058,13 @@ static void mf_getSrcHistory(char *buffer, int size)
pages[2] = kmalloc(4096, GFP_ATOMIC);
pages[3] = kmalloc(4096, GFP_ATOMIC);
if ((ev == NULL) || (pages[0] == NULL) || (pages[1] == NULL)
- || (pages[2] == NULL) || (pages[3] == NULL))
+ || (pages[2] == NULL) || (pages[3] == NULL)) {
+ kfree(pages[3]);
+ kfree(pages[2]);
+ kfree(pages[1]);
+ kfree(pages[0]);
return -ENOMEM;
+ }
return_stuff.xType = 0;
return_stuff.xRc = 0;
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Plain text mails only, please http://www.expita.com/nomime.html
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
^ permalink raw reply related
* [MPC8xx] Initial MMU too low
From: LEROY christophe @ 2010-10-30 11:52 UTC (permalink / raw)
To: linuxppc-dev
Hello,
When I build a kernel with DEBUG_LOCK_ALLOC set, I get a kernel which
has __bss_stop above the C0800000 limit, and then I get a bad page
exception during the zeroize of the __bss at startup, because the
initial MMU only maps the first 8Mbytes.
What can I do to fix that ?
Regards
C. Leroy
^ permalink raw reply
* [PATCH] powerpc: kvm: fix information leak to userland
From: Vasiliy Kulikov @ 2010-10-30 9:04 UTC (permalink / raw)
To: kernel-janitors
Cc: kvm, Marcelo Tosatti, Alexander Graf, kvm-ppc, linux-kernel,
Paul Mackerras, Avi Kivity, linuxppc-dev
Structure kvm_ppc_pvinfo is copied to userland with flags and
pad fields unitialized. It leads to leaking of contents of
kernel stack memory.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
---
I cannot compile this driver, so it is not tested at all.
arch/powerpc/kvm/powerpc.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 2f87a16..38f756f 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -617,6 +617,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
switch (ioctl) {
case KVM_PPC_GET_PVINFO: {
struct kvm_ppc_pvinfo pvinfo;
+ memset(&pvinfo, 0, sizeof(pvinfo));
r = kvm_vm_ioctl_get_pvinfo(&pvinfo);
if (copy_to_user(argp, &pvinfo, sizeof(pvinfo))) {
r = -EFAULT;
--
1.7.0.4
^ permalink raw reply related
* Support for multiple port's
From: Thomas Taranowski @ 2010-10-29 23:09 UTC (permalink / raw)
To: linuxppc-dev
Going through the code, it looks like the rapidio driver assumes
there's only going to be a single Port implemented.
Snapshot of code assumes a single port atmu configuration block, which
is wrong for the p2020, and probably other QorIQ processors.
<snip>
priv->atmu_regs = (struct rio_atmu_regs *)(priv->regs_win
+ RIO_ATMU_REGS_OFFSET);
priv->maint_atmu_regs = priv->atmu_regs + 1;
priv->dbell_atmu_regs = priv->atmu_regs + 2;
priv->msg_regs = (struct rio_msg_regs *)(priv->regs_win +
((port->phy_type == RIO_PHY_SERIAL) ?
RIO_S_MSG_REGS_OFFSET : RIO_P_MSG_REGS_OFFSET));
<snip>
On the newer QorIQ P2020 processors there are 2 sets of port
registers, so the current code lays the dbell_atmu_regs structure on
top of the second set of atmu_regs. There are probably other issues
as well.
Are there any patch sets available that support the newer processors,
and multi-port ( multi-homed? ) RapidIO configurations?
Thanks!
^ permalink raw reply
* Re: RapidIO: MC Exception when enumerating peer to peer connection
From: Thomas Taranowski @ 2010-10-29 20:11 UTC (permalink / raw)
To: Micha Nelissen; +Cc: linuxppc-dev
In-Reply-To: <4CCA9207.8050506@neli.hopto.org>
Yes, I tried pretty much all combinations of boot order, but I believe
the preferred approach is to boot the agents first, then the host
according to my freescale documentation. My problem was that all
three devices had the same device id. Once I programmed them with
different device id's via the alternate device id register I could
finally get doorbell messages across with the jtag.
Thanks
On Fri, Oct 29, 2010 at 2:21 AM, Micha Nelissen <micha@neli.hopto.org> wrote:
> Thomas Taranowski wrote:
>>
>> use my trusty jtag to issue a Port Link Maintenance Request and
>> request status, I get back unrecoverable ackID error for port 1, and
>> error-stopped port_status for port 2.
>
> Did you try rebooting all devices together?
>
> Micha
>
^ permalink raw reply
* [PATCH 7/7] kgdb,ppc: Individual register get/set for ppc
From: Jason Wessel @ 2010-10-29 18:43 UTC (permalink / raw)
To: torvalds
Cc: kgdb-bugreport, linuxppc-dev, Dongdong Deng, linux-kernel,
Jason Wessel
In-Reply-To: <1288377821-24520-1-git-send-email-jason.wessel@windriver.com>
From: Dongdong Deng <dongdong.deng@windriver.com>
commit 534af1082329392bc29f6badf815e69ae2ae0f4c(kgdb,kdb: individual
register set and and get API) introduce dbg_get_reg/dbg_set_reg API
for individual register get and set.
This patch implement those APIs for ppc.
Signed-off-by: Dongdong Deng <dongdong.deng@windriver.com>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
CC: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/kgdb.h | 1 +
arch/powerpc/kernel/kgdb.c | 188 ++++++++++++++++++++++++++-------------
2 files changed, 126 insertions(+), 63 deletions(-)
diff --git a/arch/powerpc/include/asm/kgdb.h b/arch/powerpc/include/asm/kgdb.h
index edd2170..9db24e7 100644
--- a/arch/powerpc/include/asm/kgdb.h
+++ b/arch/powerpc/include/asm/kgdb.h
@@ -31,6 +31,7 @@ static inline void arch_kgdb_breakpoint(void)
asm(".long 0x7d821008"); /* twge r2, r2 */
}
#define CACHE_FLUSH_IS_SAFE 1
+#define DBG_MAX_REG_NUM 70
/* The number bytes of registers we have to save depends on a few
* things. For 64bit we default to not including vector registers and
diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index 7f61a3a..7a9db64 100644
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
@@ -194,40 +194,6 @@ static int kgdb_dabr_match(struct pt_regs *regs)
ptr = (unsigned long *)ptr32; \
} while (0)
-
-void pt_regs_to_gdb_regs(unsigned long *gdb_regs, struct pt_regs *regs)
-{
- unsigned long *ptr = gdb_regs;
- int reg;
-
- memset(gdb_regs, 0, NUMREGBYTES);
-
- for (reg = 0; reg < 32; reg++)
- PACK64(ptr, regs->gpr[reg]);
-
-#ifdef CONFIG_FSL_BOOKE
-#ifdef CONFIG_SPE
- for (reg = 0; reg < 32; reg++)
- PACK64(ptr, current->thread.evr[reg]);
-#else
- ptr += 32;
-#endif
-#else
- /* fp registers not used by kernel, leave zero */
- ptr += 32 * 8 / sizeof(long);
-#endif
-
- PACK64(ptr, regs->nip);
- PACK64(ptr, regs->msr);
- PACK32(ptr, regs->ccr);
- PACK64(ptr, regs->link);
- PACK64(ptr, regs->ctr);
- PACK32(ptr, regs->xer);
-
- BUG_ON((unsigned long)ptr >
- (unsigned long)(((void *)gdb_regs) + NUMREGBYTES));
-}
-
void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct task_struct *p)
{
struct pt_regs *regs = (struct pt_regs *)(p->thread.ksp +
@@ -271,44 +237,140 @@ void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct task_struct *p)
(unsigned long)(((void *)gdb_regs) + NUMREGBYTES));
}
-#define UNPACK64(dest, ptr) do { dest = *(ptr++); } while (0)
+#define GDB_SIZEOF_REG sizeof(unsigned long)
+#define GDB_SIZEOF_REG_U32 sizeof(u32)
-#define UNPACK32(dest, ptr) do { \
- u32 *ptr32; \
- ptr32 = (u32 *)ptr; \
- dest = *(ptr32++); \
- ptr = (unsigned long *)ptr32; \
- } while (0)
+#ifdef CONFIG_FSL_BOOKE
+#define GDB_SIZEOF_FLOAT_REG sizeof(unsigned long)
+#else
+#define GDB_SIZEOF_FLOAT_REG sizeof(u64)
+#endif
-void gdb_regs_to_pt_regs(unsigned long *gdb_regs, struct pt_regs *regs)
+struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] =
{
- unsigned long *ptr = gdb_regs;
- int reg;
-
- for (reg = 0; reg < 32; reg++)
- UNPACK64(regs->gpr[reg], ptr);
+ { "r0", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[0]) },
+ { "r1", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[1]) },
+ { "r2", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[2]) },
+ { "r3", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[3]) },
+ { "r4", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[4]) },
+ { "r5", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[5]) },
+ { "r6", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[6]) },
+ { "r7", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[7]) },
+ { "r8", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[8]) },
+ { "r9", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[9]) },
+ { "r10", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[10]) },
+ { "r11", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[11]) },
+ { "r12", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[12]) },
+ { "r13", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[13]) },
+ { "r14", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[14]) },
+ { "r15", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[15]) },
+ { "r16", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[16]) },
+ { "r17", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[17]) },
+ { "r18", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[18]) },
+ { "r19", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[19]) },
+ { "r20", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[20]) },
+ { "r21", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[21]) },
+ { "r22", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[22]) },
+ { "r23", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[23]) },
+ { "r24", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[24]) },
+ { "r25", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[25]) },
+ { "r26", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[26]) },
+ { "r27", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[27]) },
+ { "r28", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[28]) },
+ { "r29", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[29]) },
+ { "r30", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[30]) },
+ { "r31", GDB_SIZEOF_REG, offsetof(struct pt_regs, gpr[31]) },
+
+ { "f0", GDB_SIZEOF_FLOAT_REG, 0 },
+ { "f1", GDB_SIZEOF_FLOAT_REG, 1 },
+ { "f2", GDB_SIZEOF_FLOAT_REG, 2 },
+ { "f3", GDB_SIZEOF_FLOAT_REG, 3 },
+ { "f4", GDB_SIZEOF_FLOAT_REG, 4 },
+ { "f5", GDB_SIZEOF_FLOAT_REG, 5 },
+ { "f6", GDB_SIZEOF_FLOAT_REG, 6 },
+ { "f7", GDB_SIZEOF_FLOAT_REG, 7 },
+ { "f8", GDB_SIZEOF_FLOAT_REG, 8 },
+ { "f9", GDB_SIZEOF_FLOAT_REG, 9 },
+ { "f10", GDB_SIZEOF_FLOAT_REG, 10 },
+ { "f11", GDB_SIZEOF_FLOAT_REG, 11 },
+ { "f12", GDB_SIZEOF_FLOAT_REG, 12 },
+ { "f13", GDB_SIZEOF_FLOAT_REG, 13 },
+ { "f14", GDB_SIZEOF_FLOAT_REG, 14 },
+ { "f15", GDB_SIZEOF_FLOAT_REG, 15 },
+ { "f16", GDB_SIZEOF_FLOAT_REG, 16 },
+ { "f17", GDB_SIZEOF_FLOAT_REG, 17 },
+ { "f18", GDB_SIZEOF_FLOAT_REG, 18 },
+ { "f19", GDB_SIZEOF_FLOAT_REG, 19 },
+ { "f20", GDB_SIZEOF_FLOAT_REG, 20 },
+ { "f21", GDB_SIZEOF_FLOAT_REG, 21 },
+ { "f22", GDB_SIZEOF_FLOAT_REG, 22 },
+ { "f23", GDB_SIZEOF_FLOAT_REG, 23 },
+ { "f24", GDB_SIZEOF_FLOAT_REG, 24 },
+ { "f25", GDB_SIZEOF_FLOAT_REG, 25 },
+ { "f26", GDB_SIZEOF_FLOAT_REG, 26 },
+ { "f27", GDB_SIZEOF_FLOAT_REG, 27 },
+ { "f28", GDB_SIZEOF_FLOAT_REG, 28 },
+ { "f29", GDB_SIZEOF_FLOAT_REG, 29 },
+ { "f30", GDB_SIZEOF_FLOAT_REG, 30 },
+ { "f31", GDB_SIZEOF_FLOAT_REG, 31 },
+
+ { "pc", GDB_SIZEOF_REG, offsetof(struct pt_regs, nip) },
+ { "msr", GDB_SIZEOF_REG, offsetof(struct pt_regs, msr) },
+ { "cr", GDB_SIZEOF_REG_U32, offsetof(struct pt_regs, ccr) },
+ { "lr", GDB_SIZEOF_REG, offsetof(struct pt_regs, link) },
+ { "ctr", GDB_SIZEOF_REG_U32, offsetof(struct pt_regs, ctr) },
+ { "xer", GDB_SIZEOF_REG, offsetof(struct pt_regs, xer) },
+};
-#ifdef CONFIG_FSL_BOOKE
-#ifdef CONFIG_SPE
- for (reg = 0; reg < 32; reg++)
- UNPACK64(current->thread.evr[reg], ptr);
+char *dbg_get_reg(int regno, void *mem, struct pt_regs *regs)
+{
+ if (regno >= DBG_MAX_REG_NUM || regno < 0)
+ return NULL;
+
+ if (regno < 32 || regno >= 64)
+ /* First 0 -> 31 gpr registers*/
+ /* pc, msr, ls... registers 64 -> 69 */
+ memcpy(mem, (void *)regs + dbg_reg_def[regno].offset,
+ dbg_reg_def[regno].size);
+
+ if (regno >= 32 && regno < 64) {
+ /* FP registers 32 -> 63 */
+#if defined(CONFIG_FSL_BOOKE) && defined(CONFIG_SPE)
+ if (current)
+ memcpy(mem, current->thread.evr[regno-32],
+ dbg_reg_def[regno].size);
#else
- ptr += 32;
+ /* fp registers not used by kernel, leave zero */
+ memset(mem, 0, dbg_reg_def[regno].size);
#endif
+ }
+
+ return dbg_reg_def[regno].name;
+}
+
+int dbg_set_reg(int regno, void *mem, struct pt_regs *regs)
+{
+ if (regno >= DBG_MAX_REG_NUM || regno < 0)
+ return -EINVAL;
+
+ if (regno < 32 || regno >= 64)
+ /* First 0 -> 31 gpr registers*/
+ /* pc, msr, ls... registers 64 -> 69 */
+ memcpy((void *)regs + dbg_reg_def[regno].offset, mem,
+ dbg_reg_def[regno].size);
+
+ if (regno >= 32 && regno < 64) {
+ /* FP registers 32 -> 63 */
+#if defined(CONFIG_FSL_BOOKE) && defined(CONFIG_SPE)
+ memcpy(current->thread.evr[regno-32], mem,
+ dbg_reg_def[regno].size);
#else
- /* fp registers not used by kernel, leave zero */
- ptr += 32 * 8 / sizeof(int);
+ /* fp registers not used by kernel, leave zero */
+ return 0;
#endif
+ }
- UNPACK64(regs->nip, ptr);
- UNPACK64(regs->msr, ptr);
- UNPACK32(regs->ccr, ptr);
- UNPACK64(regs->link, ptr);
- UNPACK64(regs->ctr, ptr);
- UNPACK32(regs->xer, ptr);
-
- BUG_ON((unsigned long)ptr >
- (unsigned long)(((void *)gdb_regs) + NUMREGBYTES));
+ return 0;
}
void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long pc)
--
1.6.3.3
^ permalink raw reply related
* [MPC8272ADS] porting a custom patch from 2.6.21.7 to 2.6.35.7 for a custom board
From: Alexandru Ionut Grama @ 2010-10-29 14:09 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 16713 bytes --]
Hello linuxppc-dev community!
First of all, I want to introduce myself and my project. I'm working at the
Technical University of Madrid in a project for porting Linux to an embedded
system, a router. This project is my final degree thesis. This machine has a
MPC8272VRMIBA processor and a custom platform and seems to be based on
MPC8272ADS. The company that subsidizes us provides us a patch for making
the router compatible with Linux, but it only works for Linux-2.6.21.
I've achieve some aims, but for now I want to make openssl compatible with
SEC1.0. I want to use the Cryptographic-API with talitos to get the
advantage of using crypto-processor. I've decided to use Linux-2.6.35.7
because is the latest stable version of Linux, and adds new features to
"talitos". So, for now, my aim is to port the original patch to
Linux-2.6.35.7 to get CPM and serial port compatibility. After that I can do
kernel debugging for making Ethernet cards compatible, and finally make some
benchmark for the crypto system. The bad point is that the architecture of
kernel's code changes a lot and I don't know if the changes that I'm doing
are in the good way.
I'll try to explain my best what I'm doing.
Here is the original change:
diff -rcNP linux-2.6.21/arch/powerpc/mm/init_32.c
atlas_kernel/arch/powerpc/mm/init_32.c
*** linux-2.6.21/arch/powerpc/mm/init_32.c 2007-04-26 05:08:32.000000000
+0200
--- atlas_kernel/arch/powerpc/mm/init_32.c 2008-04-24 08:43:51.000000000
+0200
***************
*** 172,178 ****
#ifdef CONFIG_HIGHMEM
ioremap_base = PKMAP_BASE;
#else
! ioremap_base = 0xfe000000UL; /* for now, could be 0xfffff000 */
#endif /* CONFIG_HIGHMEM */
ioremap_bot = ioremap_base;
--- 172,178 ----
#ifdef CONFIG_HIGHMEM
ioremap_base = PKMAP_BASE;
#else
! ioremap_base = 0xff000000UL; /* for now, could be 0xfffff000 */ /*
gonza */
#endif /* CONFIG_HIGHMEM */
ioremap_bot = ioremap_base;
I reproduce this change with this:
diff -rc linux-2.6.35.7/arch/powerpc/include/asm/pgtable-ppc32.h
linux-agrama/arch/powerpc/include/asm/pgtable-ppc32.h
*** linux-2.6.35.7/arch/powerpc/include/asm/pgtable-ppc32.h 2010-09-29
03:09:08.000000000 +0200
--- linux-agrama/arch/powerpc/include/asm/pgtable-ppc32.h 2010-10-26
18:47:28.000000000 +0200
***************pq2ads
*** 63,69 ****
#ifdef CONFIG_HIGHMEM
#define KVIRT_TOP PKMAP_BASE
#else
! #define KVIRT_TOP (0xfe000000UL) /* for now, could be FIXMAP_BASE ? */
#endif
/*
--- 63,69 ----
#ifdef CONFIG_HIGHMEM
#define KVIRT_TOP PKMAP_BASE
#else
! #define KVIRT_TOP (0xff000000UL) /* for now, could be FIXMAP_BASE ? */ /*
agrama, antes KVIRT_TOP era 0xfe000000UL */
#endif
/*
Also, I've add the next line:
diff -rc linux-2.6.35.7/arch/powerpc/mm/init_32.c
linux-agrama/arch/powerpc/mm/init_32.c
*** linux-2.6.35.7/arch/powerpc/mm/init_32.c 2010-09-29
03:09:08.000000000 +0200
--- linux-agrama/arch/powerpc/mm/init_32.c 2010-10-29 10:28:43.000000000
+0200
***************
*** 178,184 ****
/* Initialize early top-down ioremap allocator */
ioremap_bot = IOREMAP_TOP;
!
/* Map in I/O resources */
if (ppc_md.progress)
ppc_md.progress("MMU:setio", 0x302);
--- 178,184 ----
/* Initialize early top-down ioremap allocator */
ioremap_bot = IOREMAP_TOP;
! ioremap_base = ioremap_bot; /*agrama*/
/* Map in I/O resources */
if (ppc_md.progress)
ppc_md.progress("MMU:setio", 0x302);
¿It's correct to add the line ioremap_base=ioremap_bot or ioremap_base it
not used anymore?
The next change it's about a jam on pci's kref. This line has been deleted
on 2.6.21:
diff -rcNP linux-2.6.21/arch/powerpc/platforms/82xx/mpc82xx_ads.c
atlas_kernel/arch/powerpc/platforms/82xx/mpc82xx_ads.c
*** linux-2.6.21/arch/powerpc/platforms/82xx/mpc82xx_ads.c 2007-04-26
05:08:32.000000000 +0200
--- atlas_kernel/arch/powerpc/platforms/82xx/mpc82xx_ads.c 2008-04-24
08:43:51.000000000 +0200
***************
*** 533,539 ****
return;
}
pci_clk_frq = *(uint *) ptr;
- of_node_put(np);
bus_range = get_property(np, "bus-range", &len);
if (bus_range == NULL || len < 2 * sizeof(int)) {
printk(KERN_WARNING "Can't get bus-range for %s, assume"
I didn't find an equivalent operation on 2.6.35 because the code has been
changed completly. ¿Where it's included this operation about the bus?
Here there's a change of the macro CPM_BASE_ADDR :
diff -rcNP linux-2.6.21/arch/powerpc/platforms/82xx/pq2ads.h
atlas_kernel/arch/powerpc/platforms/82xx/pq2ads.h
*** linux-2.6.21/arch/powerpc/platforms/82xx/pq2ads.h 2007-04-26
05:08:32.000000000 +0200
--- atlas_kernel/arch/powerpc/platforms/82xx/pq2ads.h 2008-04-24
08:43:51.000000000 +0200
***************
*** 30,36 ****
#define CPUINFO_MACHINE "PQ2 ADS PowerPC"
/* Backword-compatibility stuff for the drivers */
! #define CPM_MAP_ADDR ((uint)0xf0000000)
#define CPM_IRQ_OFFSET 0
/* The ADS8260 has 16, 32-bit wide control/status registers, accessed
--- 30,36 ----
#define CPUINFO_MACHINE "PQ2 ADS PowerPC"
/* Backword-compatibility stuff for the drivers */
! #define CPM_MAP_ADDR ((uint)0xff000000) /*gonza*/
#define CPM_IRQ_OFFSET 0
It's seems that it has to be 0xff000000, but in 2.6.35 this symbol it's not
used anymore. ¿Where it's defined right now, or how I can handle this
address? I need it for the next part, that it's the hardest one to modify.
Here comes the hardest part at the file
arch/powerpc/platforms/82xx/mpc82xx_ads.c:
***************
*** 632,637 ****
--- 632,643 ----
while (1) ;
}
+ static void __init m82xx_map_io(void) /* gonza */
+ {
+ io_block_mapping(CPM_MAP_ADDR, CPM_MAP_ADDR, ((uint)(4 * 64 * 1024)),
_PAGE_IO);
+ }
+
+
define_machine(mpc82xx_ads)
{
.name = "MPC82xx ADS",
***************
*** 642,645 ****
--- 648,652 ----
.get_irq = cpm2_get_irq,
.calibrate_decr = m82xx_calibrate_decr,
.restart = m82xx_restart,.halt = m82xx_halt,
+ .setup_io_mappings = m82xx_map_io, /* gonza */
};
Here it's a modification that sets the base address for CPM with
io_block_mapping. I've seen in another discussion that io_block_mapping it's
became deprecated and it's out or kernel code. Does ioremap() function
became smarter and you can use it instead of io_block_mapping? I've found
some part of the code that I think do the same stuff, but it's not seems
working. Also, I've tried with setbat() changing the addresses for
0xff000000, but it doesn't work. Also, I've removed the original setbat line
and let only mine. So it doesn't work with the both lines or letting only
mine (being ioremap() or setbat()).
*** linux-2.6.35.7/arch/powerpc/sysdev/cpm_common.c 2010-09-29
03:09:08.000000000 +0200
--- linux-agrama/arch/powerpc/sysdev/cpm_common.c 2010-10-29
13:20:35.000000000 +0200
***************
*** 58,63 ****
--- 58,64 ----
if (cpm_udbg_txdesc) {
#ifdef CONFIG_CPM2
setbat(1, 0xf0000000, 0xf0000000, 1024*1024, PAGE_KERNEL_NCG);
+ ioremap(((uint)0xff000000UL),(uint)1024*64*4);
#endif
udbg_putc = udbg_putc_cpm;
}
I've seen that .setup_io_mappings was removed from kernel code. It has beed
called in version 2.6.21.7 from arch/powerpc/mm/init_32.c. It's has the same
effect make this operation at arch/powerpc/sysdev/cpm_common.c ? Which
operation should I do, ioremap(),setbat() or another one?
The last part of the modification it's about the serial port. At the version
2.6.21.7 you can choose where it's connected the serial port
(SCC1,SCC2,SCC3,SCC4,SMC1 or SMC2). Our serial port it's connected over
SMC1. We define it with the var SERIAL_CPM_SMC1 at menuconfig. At the
2.6.35.7 there's no option for do that. How should i do to force the serial
on SMC1? Also, there's a change when you init the serial port:
diff -rcNP linux-2.6.21/drivers/serial/cpm_uart/cpm_uart_cpm2.c
atlas_kernel/drivers/serial/cpm_uart/cpm_uart_cpm2.c
*** linux-2.6.21/drivers/serial/cpm_uart/cpm_uart_cpm2.c 2007-04-26
05:08:32.000000000 +0200
--- atlas_kernel/drivers/serial/cpm_uart/cpm_uart_cpm2.c 2008-04-24
08:43:52.000000000 +0200
***************
*** 95,105 ****
volatile iop_cpm2_t *io = cpm2_map(im_ioport);
volatile cpmux_t *cpmux = cpm2_map(im_cpmux);
! /* SMC1 is only on port D */
! io->iop_ppard |= 0x00c00000;
! io->iop_pdird |= 0x00400000;
! io->iop_pdird &= ~0x00800000;
! io->iop_psord &= ~0x00c00000;
/* Wire BRG1 to SMC1 */
cpmux->cmx_smr &= 0x0f;
--- 95,105 ----
volatile iop_cpm2_t *io = cpm2_map(im_ioport);
volatile cpmux_t *cpmux = cpm2_map(im_cpmux);
! /* gonza, se cambia ppard por pparc*/
! io->iop_pparc |= 0x0c000000;
! io->iop_pdirc |= 0x04000000;
! io->iop_pdirc &= ~0x08000000;
! io->iop_psorc &= ~0x0c000000;
/* Wire BRG1 to SMC1 */
cpmux->cmx_smr &= 0x0f;
The change consists on use port c instead of port d. Also, the values that
are written are multiplied of 0x10. In version 2.6.35.7 I've made the next
change that I believe that makes the same stuff:
diff -rc linux-2.6.35.7/arch/powerpc/platforms/82xx/mpc8272_ads.c
linux-agrama/arch/powerpc/platforms/82xx/mpc8272_ads.c
*** linux-2.6.35.7/arch/powerpc/platforms/82xx/mpc8272_ads.c 2010-09-29
03:09:08.000000000 +0200
--- linux-agrama/arch/powerpc/platforms/82xx/mpc8272_ads.c 2010-10-28
15:05:49.000000000 +0200
***************
*** 108,113 ****
--- 108,127 ----
{3, 23, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{3, 24, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{3, 25, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+
+ #if 0 /* agrama */
+ /* En linux-2.6.21.7 (atlas):*/
+ /* gonza, se cambia ppard por pparc*/
+ io->iop_pparc |= 0x0c 00 00 00;
+ 1100
+ io->iop_pdirc |= 0x04000000;
+ io->iop_pdirc &= ~0x08000000;
+ io->iop_psorc &= ~0x0c000000;
+ #endif
+
+ /* SMC1 */ /* agrama */
+ {2, 26, (0*CPM_PIN_GPIO) | CPM_PIN_OUTPUT | CPM_PIN_SECONDARY}, /*
agrama */
+ {2, 27, (0*CPM_PIN_GPIO) | CPM_PIN_INPUT | CPM_PIN_SECONDARY}, /*
agrama */
};
There's another modification in version 2.6.21.7 about Ethernet, but I
believe that doesn't affect to serial port.
diff -rcNP linux-2.6.21/arch/powerpc/sysdev/fsl_soc.c
atlas_kernel/arch/powerpc/sysdev/fsl_soc.c
*** linux-2.6.21/arch/powerpc/sysdev/fsl_soc.c 2007-04-26
05:08:32.000000000 +0200
--- atlas_kernel/arch/powerpc/sysdev/fsl_soc.c 2008-04-24
08:43:51.000000000 +0200
***************
*** 679,685 ****
fs_enet_data.rx_ring = 32;
fs_enet_data.tx_ring = 32;
fs_enet_data.rx_copybreak = 240;
! fs_enet_data.use_napi = 0;
fs_enet_data.napi_weight = 17;
fs_enet_data.mem_offset = FCC_MEM_OFFSET(fcc_index);
fs_enet_data.cp_page = CPM_CR_FCC_PAGE(fcc_index);
--- 680,686 ----
fs_enet_data.rx_ring = 32;
fs_enet_data.tx_ring = 32;
fs_enet_data.rx_copybreak = 240;
! fs_enet_data.use_napi = 1;
fs_enet_data.napi_weight = 17;
fs_enet_data.mem_offset = FCC_MEM_OFFSET(fcc_index);
fs_enet_data.cp_page = CPM_CR_FCC_PAGE(fcc_index);
***************
*** 713,731 ****
fs_enet_mdio_bb_data.delay =
mdio_bb_prop[5];
fs_enet_mdio_bb_data.irq[0] = phy_irq[0];
fs_enet_mdio_bb_data.irq[1] = -1;
fs_enet_mdio_bb_data.irq[2] = -1;
fs_enet_mdio_bb_data.irq[3] = phy_irq[0];
fs_enet_mdio_bb_data.irq[31] = -1;
fs_enet_mdio_bb_data.mdio_dat.offset =
(u32)&cpm2_immr->im_ioport.iop_pdatc;
fs_enet_mdio_bb_data.mdio_dir.offset =
(u32)&cpm2_immr->im_ioport.iop_pdirc;
fs_enet_mdio_bb_data.mdc_dat.offset =
(u32)&cpm2_immr->im_ioport.iop_pdatc;
!
ret = platform_device_add_data(
fs_enet_mdio_bb_dev,
&fs_enet_mdio_bb_data,
--- 714,747 ----
fs_enet_mdio_bb_data.delay =
mdio_bb_prop[5];
+ /*gonza: Creo que aqui se esta suponiendo que hay phy con direccion 0 y
3*/
+ /*igual que en mii-bitbang.c*/
fs_enet_mdio_bb_data.irq[0] = phy_irq[0];
fs_enet_mdio_bb_data.irq[1] = -1;
fs_enet_mdio_bb_data.irq[2] = -1;
fs_enet_mdio_bb_data.irq[3] = phy_irq[0];
fs_enet_mdio_bb_data.irq[31] = -1;
+ /*gonza: uso los campos mdio_port y mdc_port que son
0=PORTA..3=PORTD*/
+ offset_port_port = (u32)&cpm2_immr->im_ioport.iop_pdirb -
(u32)&cpm2_immr->im_ioport.iop_pdira;
+
+ fs_enet_mdio_bb_data.mdio_dat.offset =
+ (u32)&cpm2_immr->im_ioport.iop_pdata +
+ (offset_port_port * fs_enet_mdio_bb_data.mdio_port);
+ fs_enet_mdio_bb_data.mdio_dir.offset =
+ (u32)&cpm2_immr->im_ioport.iop_pdira +
+ (offset_port_port * fs_enet_mdio_bb_data.mdio_port);
+ fs_enet_mdio_bb_data.mdc_dat.offset =
+ (u32)&cpm2_immr->im_ioport.iop_pdata +
+ (offset_port_port * fs_enet_mdio_bb_data.mdc_port);
+ #if 0
fs_enet_mdio_bb_data.mdio_dat.offset =
(u32)&cpm2_immr->im_ioport.iop_pdatc;
fs_enet_mdio_bb_data.mdio_dir.offset =
(u32)&cpm2_immr->im_ioport.iop_pdirc;
fs_enet_mdio_bb_data.mdc_dat.offset =
(u32)&cpm2_immr->im_ioport.iop_pdatc;
! #endif
ret = platform_device_add_data(
fs_enet_mdio_bb_dev,
&fs_enet_mdio_bb_data,
***************
*** 733,739 ****
if (ret)
goto unreg;
}
!
of_node_put(phy);
of_node_put(mdio);
--- 749,755 ----
if (ret)
goto unreg;
}
!
of_node_put(phy);
of_node_put(mdio);
***************
*** 754,759 ****
--- 770,777 ----
arch_initcall(fs_enet_of_init);
+ #if 0 /* gonza */
+
static const char scc_regs[] = "regs";
static const char scc_pram[] = "pram";
***************
*** 828,833 ****
--- 846,853 ----
}
arch_initcall(cpm_uart_of_init);
+ #endif
+
#endif /* CONFIG_CPM2 */
#ifdef CONFIG_8xx
***************
*** 1022,1027 ****
--- 1042,1050 ----
arch_initcall(fs_enet_of_init);
+ #endif /* CONFIG_8xx */
+
+ #if defined(CONFIG_CPM2) || defined(CONFIG_8xx)
static const char *smc_regs = "regs";
static const char *smc_pram = "pram";
***************
*** 1096,1099 ****
arch_initcall(cpm_smc_uart_of_init);
! #endif /* CONFIG_8xx */
--- 1119,1122 ----
arch_initcall(cpm_smc_uart_of_init);
! #endif /* CONFIG_CPM2 || CONFIG_8xx */
So, the questions are the next:
- linux-2.6.21/arch/powerpc/mm/init_32.c
linux-2.6.35.7/arch/powerpc/mm/pgtable_32.h
- It's ok what I'm doing changing here KVIRT_TOP?
- ioremap_base = ioremap_bot at linux-2.6.35.7/arch/powerpc/mm/init_32.c?
- linux-2.6.21/arch/powerpc/platforms/82xx/pq2ads.h
- Where and how can I define CMP_MAP_ADDR, that all the controllers can
use it?
- Changing the CMP_MAP_ADDR in 2.6.21.7 involves that I should use a
configuration for 2.6.35 based on PQ2ADS?
-linux-2.6.35.7/arch/powerpc/platforms/82xx/mpc8272_ads.c
- How shall I the same stuff asociated to the operation
.setup_io_mappings, that uses block_io_mapping?
-linux-2.6.35.7/drivers/serial/cpm_uart/cpm_uart_cpm2.c
- How shall I force the uart driver to work on SMC1?
- What shall I change to make the same operation at recognizing the uart,
(I mean, asingn control sequences to iop_pparc,iop_pdirc and iop_psorc), in
the new "style" of kernel architecture?
-linux-2.6.21/arch/powerpc/sysdev/fsl_soc.c
-This code it's necesary for making the UART works properly?
I really appreciate the work that you're doing adding features to the new
kernel, but it's very obscure for me to make the changes that I need, so
I'll apreciate very much your help with my issue. Also I think that it's a
very good way to show to the begginers (as me) how to make the proper
changes with the new style of the code.
King regards,
Alexandru
[-- Attachment #2: Type: text/html, Size: 18130 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