* Re: [PATCH 01/15] Extract the file descriptor search logic in SPU coredump code
From: Andrew Morton @ 2007-09-12 8:35 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200709121817.43263.jk@ozlabs.org>
On Wed, 12 Sep 2007 18:17:42 +1000 Jeremy Kerr <jk@ozlabs.org> wrote:
> This series looks good to me, thanks for the fixes. I'll do some testing
> tomorrow but it looks like it'll be fine as-is.
>
> Andrew - almost all of these are for spufs, the notable exception being:
>
> [PATCH 12/15] Cleanup ELF coredump extra notes logic
>
> which touches the generic elf/coredump path.
>
> Are you ok for me to merge this to my spufs tree, and upstream via
> paulus?
Sure. I'd only get in the way with spufs stuff.
^ permalink raw reply
* [patch 1/3] PS3: Fix CONFIG_SMP=n, CONFIG_KEXEC=y build
From: geoffrey.levand @ 2007-09-12 8:43 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Jeremy Kerr
In-Reply-To: <20070912084314.057513210@am.sony.com>
From: Jeremy Kerr <jk@ozlabs.org>
Currently, the ps3 kernel fails to build without smp but with kexec, as
ps3_kexec_cpu_down needs ps3_smp_cleanup_cpu, which isn't defined on UP
kernels. This change adds an empty ps3_smp_cleanup_cpu for UP kernels.
Booted on ps3.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/platform.h | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -47,7 +47,11 @@ void __init ps3_register_ipi_debug_brk(u
/* smp */
void smp_init_ps3(void);
+#ifdef CONFIG_SMP
void ps3_smp_cleanup_cpu(int cpu);
+#else
+static inline void ps3_smp_cleanup_cpu(int cpu) { }
+#endif
/* time */
--
^ permalink raw reply
* [patch 2/3] PS3: Add new LV1 error codes
From: geoffrey.levand @ 2007-09-12 8:43 UTC (permalink / raw)
To: paulus; +Cc: Geert Uytterhoeven, linuxppc-dev
In-Reply-To: <20070912084314.057513210@am.sony.com>
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
PS3: Add new error codes that may be returned by the LV1 hypervisor
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
include/asm-powerpc/ps3.h | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/include/asm-powerpc/ps3.h
+++ b/include/asm-powerpc/ps3.h
@@ -229,6 +229,9 @@ enum lv1_result {
LV1_INVALID_CLASS_ID = -21,
LV1_CONSTRAINT_NOT_SATISFIED = -22,
LV1_ALIGNMENT_ERROR = -23,
+ LV1_HARDWARE_ERROR = -24,
+ LV1_INVALID_DATA_FORMAT = -25,
+ LV1_INVALID_OPERATION = -26,
LV1_INTERNAL_ERROR = -32768,
};
@@ -284,6 +287,12 @@ static inline const char* ps3_result(int
return "LV1_CONSTRAINT_NOT_SATISFIED (-22)";
case LV1_ALIGNMENT_ERROR:
return "LV1_ALIGNMENT_ERROR (-23)";
+ case LV1_HARDWARE_ERROR:
+ return "LV1_HARDWARE_ERROR (-24)";
+ case LV1_INVALID_DATA_FORMAT:
+ return "LV1_INVALID_DATA_FORMAT (-25)";
+ case LV1_INVALID_OPERATION:
+ return "LV1_INVALID_OPERATION (-26)";
case LV1_INTERNAL_ERROR:
return "LV1_INTERNAL_ERROR (-32768)";
default:
--
^ permalink raw reply
* [patch 0/3] PS3 patches for 2.6.24
From: geoffrey.levand @ 2007-09-12 8:43 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Paul,
This is a small set of patches for 2.6.24.
--
^ permalink raw reply
* [patch 3/3] PS3: Enhance storage probe debug output
From: geoffrey.levand @ 2007-09-12 8:43 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070912084314.057513210@am.sony.com>
Add some more info to the PS3 storage probe debug output.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/device-init.c | 24 ++++++++++++++++--------
1 files changed, 16 insertions(+), 8 deletions(-)
--- a/arch/powerpc/platforms/ps3/device-init.c
+++ b/arch/powerpc/platforms/ps3/device-init.c
@@ -297,8 +297,8 @@ static int ps3_storage_wait_for_device(c
u64 dev_port;
} *notify_event;
- pr_debug(" -> %s:%u: bus_id %u, dev_id %u, dev_type %u\n", __func__,
- __LINE__, repo->bus_id, repo->dev_id, repo->dev_type);
+ pr_debug(" -> %s:%u: (%u:%u:%u)\n", __func__, __LINE__, repo->bus_id,
+ repo->dev_id, repo->dev_type);
buf = kzalloc(512, GFP_KERNEL);
if (!buf)
@@ -359,6 +359,11 @@ static int ps3_storage_wait_for_device(c
break;
}
+ pr_debug("%s:%d: notify event (%u:%u:%u): event_type 0x%lx, "
+ "port %lu\n", __func__, __LINE__, repo->bus_index,
+ repo->dev_index, repo->dev_type,
+ notify_event->event_type, notify_event->dev_port);
+
if (notify_event->event_type != notify_region_probe ||
notify_event->bus_id != repo->bus_id) {
pr_debug("%s:%u: bad notify_event: event %lu, "
@@ -370,8 +375,9 @@ static int ps3_storage_wait_for_device(c
if (notify_event->dev_id == repo->dev_id &&
notify_event->dev_type == repo->dev_type) {
- pr_debug("%s:%u: device ready: dev_id %u\n", __func__,
- __LINE__, repo->dev_id);
+ pr_debug("%s:%u: device ready (%u:%u:%u)\n", __func__,
+ __LINE__, repo->bus_index, repo->dev_index,
+ repo->dev_type);
error = 0;
break;
}
@@ -412,9 +418,10 @@ static int ps3_setup_storage_dev(const s
return -ENODEV;
}
- pr_debug("%s:%u: index %u:%u: port %lu blk_size %lu num_blocks %lu "
+ pr_debug("%s:%u: (%u:%u:%u): port %lu blk_size %lu num_blocks %lu "
"num_regions %u\n", __func__, __LINE__, repo->bus_index,
- repo->dev_index, port, blk_size, num_blocks, num_regions);
+ repo->dev_index, repo->dev_type, port, blk_size, num_blocks,
+ num_regions);
p = kzalloc(sizeof(struct ps3_storage_device) +
num_regions * sizeof(struct ps3_storage_region),
@@ -681,8 +688,9 @@ static int ps3_probe_thread(void *data)
pr_debug("%s:%u: find device error.\n",
__func__, __LINE__);
else {
- pr_debug("%s:%u: found device\n", __func__,
- __LINE__);
+ pr_debug("%s:%u: found device (%u:%u:%u)\n",
+ __func__, __LINE__, repo->bus_index,
+ repo->dev_index, repo->dev_type);
ps3_register_repository_device(repo);
ps3_repository_bump_device(repo);
ms = 250;
--
^ permalink raw reply
* Re: [PATCH 15/15] Add DEFINE_SPUFS_ATTRIBUTE()
From: Arnd Bergmann @ 2007-09-12 8:47 UTC (permalink / raw)
To: linuxppc-dev, michael; +Cc: Jeremy Kerr, linux-kernel
In-Reply-To: <1189583353.17835.22.camel@concordia.ozlabs.ibm.com>
On Wednesday 12 September 2007, Michael Ellerman wrote:
> On Wed, 2007-09-12 at 17:43 +1000, Michael Ellerman wrote:
> > This patch adds DEFINE_SPUFS_ATTRIBUTE(), a wraper around
> > DEFINE_SIMPLE_ATTRIBUTE which does the specified locking for the get
> > routine for us.
> >
> > Unfortunately we need two get routines (a locked and unlocked version) to
> > support the coredump code. This patch hides one of those (the locked version)
> > inside the macro foo.
>
> jk said:
> > "Good god man!"
>
> Yeah, I'm a bit lukewarm on this one. But the diffstat is nice, 50% code
> reduction ain't bad :)
Have you looked at the change in object code size? I would expect the
object code to actually become bigger. I also think that it hurts
readability rather than help it.
Maybe a better solution is to change the core dump code to not
require the mutex to be held in the first place. By the time
we get to call the get functions, it should already be in
saved state and no longer be able to get scheduled, so we might
not actually need all the extra tricks with avoiding the
mutex to be taken again.
Arnd <><
^ permalink raw reply
* Re: [PATCH 11/15] Combine spufs_coredump_calls with spufs_calls
From: Arnd Bergmann @ 2007-09-12 8:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jeremy Kerr, linux-kernel
In-Reply-To: <5d0eaf2dbfd1046983f3e6f96ff6b8d967ec3801.1189583010.git.michael@ellerman.id.au>
On Wednesday 12 September 2007, Michael Ellerman wrote:
> Because spufs might be built as a module, we can't have other parts of the
> kernel calling directly into it, we need stub routines that check first if the
> module is loaded.
>
> Currently we have two structures which hold callbacks for these stubs, the
> syscalls are in spufs_calls and the coredump calls are in spufs_coredump_calls.
> In both cases the logic for registering/unregistering is essentially the same,
> so we can simplify things by combining the two.
Nice cleanup!
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
^ permalink raw reply
* Re: [PATCH 10/15] Add contents of npc file to SPU coredumps
From: Arnd Bergmann @ 2007-09-12 8:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jeremy Kerr, linux-kernel
In-Reply-To: <6566ec53f4b03dbf089291a7335f5370c6a88088.1189583010.git.michael@ellerman.id.au>
On Wednesday 12 September 2007, Michael Ellerman wrote:
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
^ permalink raw reply
* Re: [PATCH 09/15] Internal __spufs_get_foo() routines should take a spu_context *
From: Arnd Bergmann @ 2007-09-12 8:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jeremy Kerr, linux-kernel
In-Reply-To: <6e0eb3cefccb1e79c306afd10604f478069d768d.1189583010.git.michael@ellerman.id.au>
On Wednesday 12 September 2007, Michael Ellerman wrote:
> The SPUFS attribute get routines take a void * because the generic attribute
> code doesn't know what sort of data it's passing around.
>
> However our internal __spufs_get_foo() routines can take a spu_context *
> directly, which saves plonking it in and out of a void * again.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
^ permalink raw reply
* Re: [PATCH 08/15] Use spufs_coredump_num_notes everywhere, and don't NULL terminate
From: Arnd Bergmann @ 2007-09-12 8:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jeremy Kerr, linux-kernel
In-Reply-To: <163f3c08c2c47d47103f234d6caa517ed9a44036.1189583010.git.michael@ellerman.id.au>
On Wednesday 12 September 2007, Michael Ellerman wrote:
> The spufs_coredump_read array is NULL terminated, and we also store the size.
> We only need one or the other, and storing the size should save a teensy bit
> of memory vs NULL terminating, so do that.
Given that we have another array in there with almost the same contents
and that is NULL terminated, I'd vote for doing it the other way and also
use NULL-termination instead of the count here.
Arnd <><
^ permalink raw reply
* Re: Flash on ep8248e standard motherboards
From: Laurent Pinchart @ 2007-09-12 9:10 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Alan Bennett
In-Reply-To: <bfa0697f0709041108u2c6b719dj600cb2eb25b66a4a@mail.gmail.com>
Hi Alan,
On Tuesday 04 September 2007 20:08, Alan Bennett wrote:
> Please accept my apologies for sending the last email and accept this
> email address and question. without the disclaimer.
> ---------------------------------------------------
>
> Hello;
> We have a custom board based on the ep8248e design from Embedded
> Planet and I'm trying to use something other than codewarrior to flash
> u-boot srec's
>
> I'm not sure where the problem is, but I'm unable to flash the
> u-boot.srec onto the Embedded Planet board (using the BDI2000), let
> alone our custom board.
> 1. Embedded Planet ep8248E
> 64 MB SDRAM
> 64 MB Flash (x2 Am29LV256M)
> 2. Custom
> 128 MB SDRAM
> 128 MB Flash (X2 Spansion S29GL512N)
>
> NOTE: CW successfully flashes both parts, but then again, it's CW.
>
>
> BDI 2000 Config File:
> ; initialize - FLASH BR0 & OR0 (64 Mbyte)
> ;*******************************************
> WM32 0xf0010100 0xfc001801
> WM32 0xf0010104 0xfc0008c2
> [FLASH]
> CHIPTYPE MIRRORX16
> CHIPSIZE 0x2000000
> BUSWIDTH 16
>
> I then attempt to unlock/erase/program
> Check for Sanity (NOTE: using BDI 2000 PROMPT)
> md 0xf0010100 2
> f0010100 : 0xf8001801 - 134211583 ....
> f0010104 : 0xf80008b2 - 134215502 ....
> md 0xfff00000 2
> fff00000 : 0x10101010 269488144 ....
> fff00004 : 0x10101010 269488144 ....
> All looks good. (10101010 is the existing planet core header)
>
> TRY TO UNLOCK
> unlock 0xfff00000 1000
> Unlocking flash at 0xfff00000
> # Invalid parameter for flash programming
>
> TRY TO ERASE
> erase 0xfff00000 UNLOCK 1000
> Erasing flash at 0xfff00000
> # Erasing flash memory failed
> BUT
> erase 0xffff0000 UNLOCK 1000
> Erasing flash at 0xffff0000
> Erasing flash passed
> HOWEVER
> mm 0xffff0000 0xdeadbeef
> md 0xffff0000 1
> ffff0000 : 0xffffffff
> SO it doesn't seem to allow write access afterall...
You need to use the 'prog' command to write to flash. 'md' won't do.
> Is there anyone that has a BDI 2000 config file for flashing the
> ep8248e motherboard the 8MB Flash Version (64 MB flash version)
Regards,
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Adeos patch for 2.6.15 ppc kernel
From: Konstantin Boyanov @ 2007-09-12 9:12 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 507 bytes --]
Hello everybody,
I have a simple question - where can I find an Adeos patch for a
2.6.15kernel? I'm trying to integrate Xenomai in it, but as I read in
the
installation notes i first must patch a fresh kernel with a corresponding
adeos patch. I googled around but found nothing of use, only the latest
patches for 2.6.20-2.6.22, and also the denx linux-2.6 git repository. Is
the kernel there already patched wiht adeos?
Any help and guidance are highly apreciated.
With best regards,
Kosntantin Boyanov
[-- Attachment #2: Type: text/html, Size: 624 bytes --]
^ permalink raw reply
* Re: Adeos patch for 2.6.15 ppc kernel
From: Johan Borkhuis @ 2007-09-12 9:33 UTC (permalink / raw)
To: Konstantin Boyanov; +Cc: linuxppc-dev
In-Reply-To: <929bf310709120212y3211a73au791663992965c80e@mail.gmail.com>
Konstantin Boyanov wrote:
> Hello everybody,
>
> I have a simple question - where can I find an Adeos patch for a
> 2.6.15 kernel? I'm trying to integrate Xenomai in it, but as I read in
> the installation notes i first must patch a fresh kernel with a
> corresponding adeos patch. I googled around but found nothing of use,
> only the latest patches for 2.6.20-2.6.22, and also the denx linux-2.6
> git repository. Is the kernel there already patched wiht adeos?
>
> Any help and guidance are highly apreciated.
There are ppc-patches available for kernel 2.6.13, 2.6.14, 2.6.18 and
2.6.19. For powerpc there are patches available for 2.6.20 and newer.
Kind regards,
Johan Borkhuis
^ permalink raw reply
* Z85230 chip
From: raul.moreno @ 2007-09-12 9:22 UTC (permalink / raw)
To: linuxppc-embedded
Hello everybody,
I am interested in using a Z85230 chip. I've seen that the synchronous =
mode
is supported in a driver and there is a comment about the attempt to un=
ify
the asynchronous mode too from 2.5 Linux version.
Does anyone know if the driver z85230.c included both operation modes
currently? Or does another driver exist which merges the asynchronous m=
ode?
Cheers,
Ra=FAl Moreno
***********Internet Email Confidentiality Footer*************
This email and any files transmitted with it are confidential and inten=
ded
solely for the use of the organization or individual to whom they are
addressed. It is expressly forbidden to retransmit or copy email and/o=
r
this attached files without our permission . If you are not the
addressee indicated in this message (or responsible for delivery of the=
message to such person), you may not copy or deliver this message
to anyone. In such case, you should destroy this message and kindly
notify the sender by reply email. Please advise immediately if you or
your employer does not consent to Internet email for messages of this
kind. Opinions, conclusions and other information in this message that=
do not relate to the official business of my firm shall be understood a=
s
neither given nor endorsed by it.=
^ permalink raw reply
* Re: SYSFS: need a noncaching read
From: Greg KH @ 2007-09-12 10:01 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linuxppc-dev, Heiko Schocher, linux-kernel, Detlev Zundel
In-Reply-To: <20070912053207.GH23573@pengutronix.de>
On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > I have developed a device driver and use the sysFS to export some
> > registers to userspace.
>
> Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
> not to play around with registers from userspace.
>
> > I opened the sysFS File for one register and did some reads from this
> > File, but I alwas becoming the same value from the register, whats not
> > OK, because they are changing. So I found out that the sysFS caches
> > the reads ... :-(
>
> Yes, it does. What you can do is close()ing the file handle between
> accesses, which makes it work but is slow.
Do an lseek back to 0 and then re-read, you will get called in your
driver again.
Not that this is a good thing to do for this kind of thing, as others
have already said.
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH 1/5] Add Freescale DMA and DMA channel to Documentation/powerpc/booting-without-of.txt file.
From: Zhang Wei-r63237 @ 2007-09-12 10:13 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev, paulus, David Gibson
In-Reply-To: <20070911141907.GF1932@ld0162-tx32.am.freescale.net>
> > >=20
> > > On Fri, Sep 07, 2007 at 04:43:35PM +0200, Segher=20
> Boessenkool wrote:
> > > > > + l) Freescale DMA
> > > >=20
> > > > > + - compatible : Should be "fsl,dma".
> > > >=20
> > > > Please choose some more specific name. "fsl,mpc8540-dma" would
> > > > be a reasonable choice perhaps.
> > >=20
> > > More precisely, the compatible property should always=20
> have an specific
> > > entry based on the exact chip the DMA engine resides in,=20
> as well as a
> > > more general entry for any fsl dma engine of this type.
> > >=20
> > There is only difference in DMA channel and not in DMA node=20
> now. Does it
> > need add the precise compatible property name?
>=20
> Yes. First of all, there most likely is a difference -- the=20
> endianness
> of the shared status summary register. Secondly, the device=20
> tree should
> not make assumptions as far as whether the user is going to bind to
> individual channels or the whole controller.
I have a strange issue here. If I rename 'fsl,dma' to 'fsl,mpc8540-dma',
the 'fsl,mpc8540-dma-channel' will be also regarded as DMA device not
DMA channel.
Thanks!
- zw
^ permalink raw reply
* Re: [PATCH] powerpc: add new required termio functions
From: Heiko Carstens @ 2007-09-12 10:20 UTC (permalink / raw)
To: Michael Neuling
Cc: linux-kernel, linuxppc-dev, paulus, Alan Cox, akpm,
Linus Torvalds, David S. Miller, Martin Schwidefsky
In-Reply-To: <8018.1189562679@neuling.org>
On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> The "tty: termios locking functions break with new termios type" patch
> (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
> [...]
> I'm guessing other architectures are broken too?
FWIW, the above quoted patch breaks s390 as well.
^ permalink raw reply
* Re: [PATCH] powerpc: add new required termio functions
From: Andrew Morton @ 2007-09-12 11:01 UTC (permalink / raw)
To: Heiko Carstens
Cc: Michael Neuling, linux-kernel, linuxppc-dev, paulus, Alan Cox,
Linus Torvalds, David S. Miller, Martin Schwidefsky
In-Reply-To: <20070912102032.GB7858@osiris.boeblingen.de.ibm.com>
On Wed, 12 Sep 2007 12:20:32 +0200 Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> > The "tty: termios locking functions break with new termios type" patch
> > (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
> > [...]
> > I'm guessing other architectures are broken too?
>
> FWIW, the above quoted patch breaks s390 as well.
Does this fix it?
diff -puN drivers/char/tty_ioctl.c~powerpc-add-new-required-termio-functions drivers/char/tty_ioctl.c
--- a/drivers/char/tty_ioctl.c~powerpc-add-new-required-termio-functions
+++ a/drivers/char/tty_ioctl.c
@@ -795,6 +795,19 @@ int n_tty_ioctl(struct tty_struct * tty,
if (L_ICANON(tty))
retval = inq_canon(tty);
return put_user(retval, (unsigned int __user *) arg);
+#ifndef TCGETS2
+ case TIOCGLCKTRMIOS:
+ if (kernel_termios_to_user_termios((struct termios __user *)arg, real_tty->termios_locked))
+ return -EFAULT;
+ return 0;
+
+ case TIOCSLCKTRMIOS:
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+ if (user_termios_to_kernel_termios(real_tty->termios_locked, (struct termios __user *) arg))
+ return -EFAULT;
+ return 0;
+#else
case TIOCGLCKTRMIOS:
if (kernel_termios_to_user_termios_1((struct termios __user *)arg, real_tty->termios_locked))
return -EFAULT;
@@ -806,6 +819,7 @@ int n_tty_ioctl(struct tty_struct * tty,
if (user_termios_to_kernel_termios_1(real_tty->termios_locked, (struct termios __user *) arg))
return -EFAULT;
return 0;
+#endif
case TIOCPKT:
{
_
^ permalink raw reply
* Re: [PATCH 07/15] Don't return -ENOSYS as extra notes size if spufs is not loaded
From: Arnd Bergmann @ 2007-09-12 11:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jeremy Kerr, linux-kernel
In-Reply-To: <628a383203480c3ce59125feccc32168de919014.1189583010.git.michael@ellerman.id.au>
On Wednesday 12 September 2007, Michael Ellerman wrote:
> Because the SPU coredump code might be built as part of a module (spufs),
> we have a stub which is called by the coredump code, this routine then calls
> into spufs if it's loaded.
>
> Unfortunately the stub returns -ENOSYS if spufs is not loaded, which is
> interpreted by the coredump code as an extra note size of -38 bytes. This
> leads to a corrupt core dump.
>
> If spufs is not loaded there will be no SPU ELF notes to write, and so the
> extra notes size will be == 0.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
^ permalink raw reply
* Re: SYSFS: need a noncaching read
From: Heiko Schocher @ 2007-09-12 11:13 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-kernel, Detlev Zundel
In-Reply-To: <20070912100123.GA23182@kroah.com>
Hello Greg
Am Mittwoch, den 12.09.2007, 03:01 -0700 schrieb Greg KH:
> On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> > On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > > I have developed a device driver and use the sysFS to export some
> > > registers to userspace.
> >
> > Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
> > not to play around with registers from userspace.
> >
> > > I opened the sysFS File for one register and did some reads from this
> > > File, but I alwas becoming the same value from the register, whats not
> > > OK, because they are changing. So I found out that the sysFS caches
> > > the reads ... :-(
> >
> > Yes, it does. What you can do is close()ing the file handle between
> > accesses, which makes it work but is slow.
>
> Do an lseek back to 0 and then re-read, you will get called in your
> driver again.
No thats not true. I thought this too, but if I make a:
seek (fd, 0L, SEEK_SET);
in Userspace, there is no retrigger in the sysFS, my driver is *not*
called again. So I made a own sysfs_seek function, which does retrigger
the driver ...
Is this really wanted in the sysFS, that there is no way to retrigger a
read?
thanks
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH] powerpc: add new required termio functions
From: Michael Neuling @ 2007-09-12 11:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Heiko Carstens, linux-kernel, linuxppc-dev, paulus, Alan Cox,
Linus Torvalds, David S. Miller, Martin Schwidefsky
In-Reply-To: <20070912040109.3f6a9149.akpm@linux-foundation.org>
In message <20070912040109.3f6a9149.akpm@linux-foundation.org> you wrote:
> On Wed, 12 Sep 2007 12:20:32 +0200 Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
>
> > On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> > > The "tty: termios locking functions break with new termios type" patch
> > > (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
> > > [...]
> > > I'm guessing other architectures are broken too?
> >
> > FWIW, the above quoted patch breaks s390 as well.
>
> Does this fix it?
FYI it does fix powerpc, but I suspect you were asking about s390 here.
Mikey
>
> diff -puN drivers/char/tty_ioctl.c~powerpc-add-new-required-termio-functions
drivers/char/tty_ioctl.c
> --- a/drivers/char/tty_ioctl.c~powerpc-add-new-required-termio-functions
> +++ a/drivers/char/tty_ioctl.c
> @@ -795,6 +795,19 @@ int n_tty_ioctl(struct tty_struct * tty,
> if (L_ICANON(tty))
> retval = inq_canon(tty);
> return put_user(retval, (unsigned int __user *) arg);
> +#ifndef TCGETS2
> + case TIOCGLCKTRMIOS:
> + if (kernel_termios_to_user_termios((struct termios __us
er *)arg, real_tty->termios_locked))
> + return -EFAULT;
> + return 0;
> +
> + case TIOCSLCKTRMIOS:
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> + if (user_termios_to_kernel_termios(real_tty->termios_lo
cked, (struct termios __user *) arg))
> + return -EFAULT;
> + return 0;
> +#else
> case TIOCGLCKTRMIOS:
> if (kernel_termios_to_user_termios_1((struct termios __
user *)arg, real_tty->termios_locked))
> return -EFAULT;
> @@ -806,6 +819,7 @@ int n_tty_ioctl(struct tty_struct * tty,
> if (user_termios_to_kernel_termios_1(real_tty->termios_
locked, (struct termios __user *) arg))
> return -EFAULT;
> return 0;
> +#endif
>
> case TIOCPKT:
> {
> _
>
^ permalink raw reply
* [PATCH] [POWERPC] ucc_geth: fix compilation
From: Anton Vorontsov @ 2007-09-12 11:24 UTC (permalink / raw)
To: linuxppc-dev
This patch is against paulus/powerpc.git or galak/powerpc.git tree.
Both affected.
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
There is no qe_bd_t typedef any longer, now it's struct qe_bd.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 12e01b2..9a38dfe 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2148,7 +2148,7 @@ static void ucc_geth_memclean(struct ucc_geth_private *ugeth)
for (j = 0; j < ugeth->ug_info->bdRingLenTx[i]; j++) {
if (ugeth->tx_skbuff[i][j]) {
dma_unmap_single(NULL,
- ((qe_bd_t *)bd)->buf,
+ ((struct qe_bd *)bd)->buf,
(in_be32((u32 *)bd) &
BD_LENGTH_MASK),
DMA_TO_DEVICE);
--
1.5.0.6
^ permalink raw reply related
* [PATCH] [POWERPC] ucc_geth: fix module removal
From: Anton Vorontsov @ 2007-09-12 11:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev
- uccf should be set to NULL to not double-free memory on
subsequent calls;
- ind_hash_q and group_hash_q lists should be initialized in the
probe() function, instead of struct_init() (called by open()),
otherwise there will be an oops if ucc_geth_driver removed
prior 'ifconfig ethX up';
- add unregister_netdev();
- reorder geth_remove() steps.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 9a38dfe..bc2b3bf 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2080,8 +2080,10 @@ static void ucc_geth_memclean(struct ucc_geth_private *ugeth)
if (!ugeth)
return;
- if (ugeth->uccf)
+ if (ugeth->uccf) {
ucc_fast_free(ugeth->uccf);
+ ugeth->uccf = NULL;
+ }
if (ugeth->p_thread_data_tx) {
qe_muram_free(ugeth->thread_dat_tx_offset);
@@ -2312,10 +2314,6 @@ static int ucc_struct_init(struct ucc_geth_private *ugeth)
ug_info = ugeth->ug_info;
uf_info = &ug_info->uf_info;
- /* Create CQs for hash tables */
- INIT_LIST_HEAD(&ugeth->group_hash_q);
- INIT_LIST_HEAD(&ugeth->ind_hash_q);
-
if (!((uf_info->bd_mem_part == MEM_PART_SYSTEM) ||
(uf_info->bd_mem_part == MEM_PART_MURAM))) {
if (netif_msg_probe(ugeth))
@@ -3949,6 +3947,10 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
ugeth = netdev_priv(dev);
spin_lock_init(&ugeth->lock);
+ /* Create CQs for hash tables */
+ INIT_LIST_HEAD(&ugeth->group_hash_q);
+ INIT_LIST_HEAD(&ugeth->ind_hash_q);
+
dev_set_drvdata(device, dev);
/* Set the dev->base_addr to the gfar reg region */
@@ -4002,9 +4004,10 @@ static int ucc_geth_remove(struct of_device* ofdev)
struct net_device *dev = dev_get_drvdata(device);
struct ucc_geth_private *ugeth = netdev_priv(dev);
- dev_set_drvdata(device, NULL);
- ucc_geth_memclean(ugeth);
+ unregister_netdev(dev);
free_netdev(dev);
+ ucc_geth_memclean(ugeth);
+ dev_set_drvdata(device, NULL);
return 0;
}
--
1.5.0.6
^ permalink raw reply related
* [PATCH] [POWERPC] ucc_fast: fix debug output
From: Anton Vorontsov @ 2007-09-12 11:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Timur Tabi
Timur, want to take this along with your qe_lib cleanup queue?
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 40 ++++++++++++++++----------------
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
index 3df202e..ab4b3cf 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
@@ -30,45 +30,45 @@
void ucc_fast_dump_regs(struct ucc_fast_private * uccf)
{
- printk(KERN_INFO "UCC%d Fast registers:", uccf->uf_info->ucc_num);
- printk(KERN_INFO "Base address: 0x%08x", (u32) uccf->uf_regs);
+ printk(KERN_INFO "UCC%d Fast registers:\n", uccf->uf_info->ucc_num);
+ printk(KERN_INFO "Base address: 0x%08x\n", (u32) uccf->uf_regs);
- printk(KERN_INFO "gumr : addr - 0x%08x, val - 0x%08x",
+ printk(KERN_INFO "gumr : addr - 0x%08x, val - 0x%08x\n",
(u32) & uccf->uf_regs->gumr, in_be32(&uccf->uf_regs->gumr));
- printk(KERN_INFO "upsmr : addr - 0x%08x, val - 0x%08x",
+ printk(KERN_INFO "upsmr : addr - 0x%08x, val - 0x%08x\n",
(u32) & uccf->uf_regs->upsmr, in_be32(&uccf->uf_regs->upsmr));
- printk(KERN_INFO "utodr : addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "utodr : addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->utodr, in_be16(&uccf->uf_regs->utodr));
- printk(KERN_INFO "udsr : addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "udsr : addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->udsr, in_be16(&uccf->uf_regs->udsr));
- printk(KERN_INFO "ucce : addr - 0x%08x, val - 0x%08x",
+ printk(KERN_INFO "ucce : addr - 0x%08x, val - 0x%08x\n",
(u32) & uccf->uf_regs->ucce, in_be32(&uccf->uf_regs->ucce));
- printk(KERN_INFO "uccm : addr - 0x%08x, val - 0x%08x",
+ printk(KERN_INFO "uccm : addr - 0x%08x, val - 0x%08x\n",
(u32) & uccf->uf_regs->uccm, in_be32(&uccf->uf_regs->uccm));
- printk(KERN_INFO "uccs : addr - 0x%08x, val - 0x%02x",
+ printk(KERN_INFO "uccs : addr - 0x%08x, val - 0x%02x\n",
(u32) & uccf->uf_regs->uccs, uccf->uf_regs->uccs);
- printk(KERN_INFO "urfb : addr - 0x%08x, val - 0x%08x",
+ printk(KERN_INFO "urfb : addr - 0x%08x, val - 0x%08x\n",
(u32) & uccf->uf_regs->urfb, in_be32(&uccf->uf_regs->urfb));
- printk(KERN_INFO "urfs : addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "urfs : addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->urfs, in_be16(&uccf->uf_regs->urfs));
- printk(KERN_INFO "urfet : addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "urfet : addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->urfet, in_be16(&uccf->uf_regs->urfet));
- printk(KERN_INFO "urfset: addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "urfset: addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->urfset,
in_be16(&uccf->uf_regs->urfset));
- printk(KERN_INFO "utfb : addr - 0x%08x, val - 0x%08x",
+ printk(KERN_INFO "utfb : addr - 0x%08x, val - 0x%08x\n",
(u32) & uccf->uf_regs->utfb, in_be32(&uccf->uf_regs->utfb));
- printk(KERN_INFO "utfs : addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "utfs : addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->utfs, in_be16(&uccf->uf_regs->utfs));
- printk(KERN_INFO "utfet : addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "utfet : addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->utfet, in_be16(&uccf->uf_regs->utfet));
- printk(KERN_INFO "utftt : addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "utftt : addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->utftt, in_be16(&uccf->uf_regs->utftt));
- printk(KERN_INFO "utpt : addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "utpt : addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->utpt, in_be16(&uccf->uf_regs->utpt));
- printk(KERN_INFO "urtry : addr - 0x%08x, val - 0x%08x",
+ printk(KERN_INFO "urtry : addr - 0x%08x, val - 0x%08x\n",
(u32) & uccf->uf_regs->urtry, in_be32(&uccf->uf_regs->urtry));
- printk(KERN_INFO "guemr : addr - 0x%08x, val - 0x%02x",
+ printk(KERN_INFO "guemr : addr - 0x%08x, val - 0x%02x\n",
(u32) & uccf->uf_regs->guemr, uccf->uf_regs->guemr);
}
EXPORT_SYMBOL(ucc_fast_dump_regs);
--
1.5.0.6
^ permalink raw reply related
* [PATCH] [POWERPC] mpc8568e_mds: UCC0's PHY is at 0x7, not 0x1
From: Anton Vorontsov @ 2007-09-12 11:25 UTC (permalink / raw)
To: linuxppc-dev
There was probably a typo in the documentation, or it's hw errata.
Recent u-boot also using 0x7.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index b1dcfbe..719929c 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -97,10 +97,10 @@
device_type = "mdio";
compatible = "gianfar";
reg = <24520 20>;
- phy0: ethernet-phy@0 {
+ phy0: ethernet-phy@7 {
interrupt-parent = <&mpic>;
interrupts = <1 1>;
- reg = <0>;
+ reg = <7>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
@@ -417,10 +417,10 @@
/* These are the same PHYs as on
* gianfar's MDIO bus */
- qe_phy0: ethernet-phy@00 {
+ qe_phy0: ethernet-phy@07 {
interrupt-parent = <&mpic>;
interrupts = <1 1>;
- reg = <0>;
+ reg = <7>;
device_type = "ethernet-phy";
};
qe_phy1: ethernet-phy@01 {
--
1.5.0.6
^ permalink raw reply related
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