Extract the logic for searching through the file descriptors for spu contexts
into a separate routine, coredump_next_context(), so we can use it elsewhere
in future. In the process we flatten the for loop, and move the NOSCHED test
into coredump_next_context().
Signed-off-by: Michael Ellerman <[EM
Remove the ctx_info struct entirely, and also the ctx_info_list. This fixes
a race where two processes can clobber each other's ctx_info structs.
Instead of using the list, we just repeat the search through the file
descriptor table.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/p
It makes sense to stop the SPU processes as soon as possible. Also if we
dont acquire_saved() I think there's a possibility that the value in
csa.priv2.spu_lslr_RW won't be accurate.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/spufs/coredump.c |2 ++
1
The spufs_coredump_reader array contains the size of the data that will be
returned by the read routine. Currently these are specified as literals, and
though some are obvious, sizeof(u32) == 4, others are not, 69 * 8 == ???
Instead, use sizeof() whatever type is returned by each routine, or in
t
Unfortunately GDB expects some of the SPU coredump values to be identical
in format to what is found in spufs. This means we need to dump some of
the values as ASCII strings, not the actual values.
Because we don't know what the values will be, we always print the values
with the format "0x%.16lx"
The routine to dump the local store, __spufs_mem_read(), does not take the
spu_lslr_RW value into account - so we shouldn't check it when we're
calculating the size either.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/spufs/coredump.c | 16 ++--
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 not
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.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/spufs/coredump.
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 Ell
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/spufs/file.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spufs/file.c
b/arch/powerpc/platforms/cell/spufs/file.c
index d19220f..52f020a 100644
--- a/
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
To start with, arch_notes_size() etc. is a little too ambiguous a name for
my liking, so change the function names to be more explicit.
Calling through macros is ugly, especially with hidden parameters, so don't
do that, call the routines directly.
Use ARCH_HAVE_EXTRA_ELF_NOTES as the only flag,
Rework spufs_coredump_extra_notes_write() to check for and return errors.
If we're coredumping to a pipe we can't trust file->f_pos, we need to
maintain the foffset value passed to us. The cleanest way to do this is
to have the low level write routine increment foffset when we've
successfully writ
Currently the spu coredump code doesn't respect the ulimit, it should.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/spufs/coredump.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spufs/coredump.c
b/a
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)
ins
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 th
On Wednesday 12 September 2007, Vitaly Bordug wrote:
>
> Well, it's more a rewrite than a move, based on 64-bit implementation.
ok.
> > Could you perhaps split the patch into two separate changesets, one
> > that makes both functions identical in place, and one that merges
> > them to live in a
Hi Michael,
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/core
On Wed, 2007-09-12 at 07:16 +1000, Paul Mackerras wrote:
> > +/* Overrides the weak version in kernel/power/main.c */
> > +void arch_suspend_disable_irqs(void)
> > +{
> > + if (ppc_md.suspend_disable_irqs)
> > + ppc_md.suspend_disable_irqs();
> > + else
> > + generic_suspen
On Wed, 12 Sep 2007 18:17:42 +1000 Jeremy Kerr <[EMAIL PROTECTED]> 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]
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
PS3: Add new error codes that may be returned by the LV1 hypervisor
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
---
include/asm-powerpc/ps3.h |9 +
1 file changed, 9 insertions(+)
Paul,
This is a small set of patches for 2.6.24.
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
From: Jeremy Kerr <[EMAIL PROTECTED]>
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 <
Add some more info to the PS3 storage probe debug output.
Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
---
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/powe
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 n
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 th
On Wednesday 12 September 2007, Michael Ellerman wrote:
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Arnd Bergmann <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-d
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 plo
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 th
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 lat
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 ar
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
> > >
> > > On Fri, Sep 07, 2007 at 04:43:35PM +0200, Segher
> Boessenkool wrote:
> > > > > + l) Freescale DMA
> > > >
> > > > > +- compatible : Should be "fsl,dma".
> > > >
> > > > Please choose some more specific name. "fsl,mpc8540-dma" would
> > > > be a reasonable choice perhaps.
> >
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
On Wed, 12 Sep 2007 12:20:32 +0200 Heiko Carstens <[EMAIL PROTECTED]> 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.
> >
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
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 use
In message <[EMAIL PROTECTED]> you wrote:
> On Wed, 12 Sep 2007 12:20:32 +0200 Heiko Carstens <[EMAIL PROTECTED]> 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
> > > (f629307c857c030d5a3dd7
This patch is against paulus/powerpc.git or galak/powerpc.git tree.
Both affected.
- - - -
From: Anton Vorontsov <[EMAIL PROTECTED]>
There is no qe_bd_t typedef any longer, now it's struct qe_bd.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/net/ucc_geth.c |2 +-
1 files ch
- 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';
-
Timur, want to take this along with your qe_lib cleanup queue?
- - - -
From: Anton Vorontsov <[EMAIL PROTECTED]>
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 40
1 files changed, 20 insertions(+), 20 deletions(-
There was probably a typo in the documentation, or it's hw errata.
Recent u-boot also using 0x7.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8568mds.dts |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc856
Lately I've got this nice badness on mdio bus removal:
Device 'e0103120:06' does not have a release() function, it is broken and must
be fixed.
[ cut here ]
Badness at drivers/base/core.c:107
NIP: c015c1a8 LR: c015c1a8 CTR: c0157488
REGS: c34bdcf0 TRAP: 0700 Not tainted
On Wed, Sep 12, 2007 at 04:01:09AM -0700, Andrew Morton wrote:
> On Wed, 12 Sep 2007 12:20:32 +0200 Heiko Carstens <[EMAIL PROTECTED]> 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
> > > (f
On Wednesday 12 September 2007, Michael Ellerman wrote:
> The routine to dump the local store, __spufs_mem_read(), does not take the
> spu_lslr_RW value into account - so we shouldn't check it when we're
> calculating the size either.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-
On Wed, Sep 12, 2007 at 01:13:32PM +0200, Heiko Schocher wrote:
> 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 devel
2.6.22.5 crashes on resume on an iBook G3 600MHz. when cpufreq_userspace is
active. System is PowerBook4,3, 750FX revision 2.3
2.6.18 crashed also on resume, but I dont know if this was the same bug.
The oopes differ. Once I get an 'Unrecoverable FP Unavailable
Exception 801' in audit_log_vformat
On Wed, Sep 12, 2007 at 12:34:09PM +0100, Christoph Hellwig wrote:
> On Wed, Sep 12, 2007 at 04:01:09AM -0700, Andrew Morton wrote:
> > On Wed, 12 Sep 2007 12:20:32 +0200 Heiko Carstens <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> > > > Th
Hello Greg,
Am Mittwoch, den 12.09.2007, 04:39 -0700 schrieb Greg KH:
> > > 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
From: Hoang-Nam Nguyen <[EMAIL PROTECTED]>
...because, on virtualized hardware like System p, we can't be sure that the
physical pages behind them are contiguous.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
Another patch for 2.6.24 that will apply cleanly on top of my previous
patchset
David Miller <[EMAIL PROTECTED]> wrote on 12.09.2007 14:50:04:
> From: Jan-Bernd Themann <[EMAIL PROTECTED]>
> Date: Fri, 7 Sep 2007 11:37:02 +0200
>
> > 2) On SMP systems: after netif_rx_complete has been called on CPU1
> >(+interruts enabled), netif_rx_schedule could be called on CPU2
> >
From: Christoph Raisch <[EMAIL PROTECTED]>
Date: Wed, 12 Sep 2007 15:10:08 +0200
> This is definitely not something we can change in the HEA device driver
> alone.
And it shouldn't be, x86 implements the policy in irq balance
daemon, powerpc should do it wherever it would be appropriate
there.
>
On Wed, Sep 12, 2007 at 01:52:57PM +0200, Heiko Carstens wrote:
> > I might be missing something, but the the right fix is probably to
> > apply the arch patches from Alan to powerpc and s390. We don't want to
> > be left over without all the nice termios features on these platforms,
> > do we?
>
On Tuesday 11 September 2007 16:51, Nathan Lynch wrote:
> > - get_paca()->paca_index, __FUNCTION__, \
> > + smp_processor_id(), __FUNCTION__, \
>
> I think I see these macros used in preemptible code (e.g. ehca_probe),
> where smp_processo
On Thu, 30 Aug 2007 10:33:28 +0200
Stefan Roese <[EMAIL PROTECTED]> wrote:
> Problem Description and Fix : Memory Read Multiples(MRM) do not work
> correctly on PPC 440EPX based systems. A PCI driver determines whether
> MRMs are supported by reading the PCI cache line size register. If this
> val
We can use raw_smp_processor_id() here because the processor ID is only used
for debug output and may therefore be preemption-unsafe.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
This is the same patch, but with smp_processor_id() replaced by
raw_smp_processor_id(), as kindly pointed out
David,
I'm splitting this up since the mdio & phy comments are more general
that the 8572.dts
>>> [snip]
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "mdio";
>>>
>>> I don't thi
+ reg = ;
+ fsl,has-rstcr;
+ };
+
+ mpic: [EMAIL PROTECTED] {
+ clock-frequency = <0>;
+ interrupt-controller;
+ #address-cells = <0>;
+
Hi David and Grant
>> > For example emaclite driver needs information about turning on/off ping
>> > pong
buffer...
>> >
>> > I would like to make this properly.
>>
>> FDT design is just as much art as it is science. It takes taste and
>> judgement to desgin a nice set of bindings. Your best op
Commit f629307c857c030d5a3dd777fee37c8bb395e171 introduced uses of
kernel_termios_to_user_termios_1 and user_termios_to_kernel_termios_1
on all architectures. However, powerpc, s390, avr32 and frv don't
currently define those functions since their termios struct didn't
need to be changed when the
On Sep 12, 2007, at 9:45 AM, Josh Boyer wrote:
> On Thu, 30 Aug 2007 10:33:28 +0200
> Stefan Roese <[EMAIL PROTECTED]> wrote:
>
>> Problem Description and Fix : Memory Read Multiples(MRM) do not work
>> correctly on PPC 440EPX based systems. A PCI driver determines
>> whether
>> MRMs are suppor
On Wed, Sep 12, 2007 at 03:13:09AM -0700, Zhang Wei-r63237 wrote:
> 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.
What tree are you using? Commit 804ace8881d211ac448082e871dd312132393
On Wednesday 12 September 2007, Christoph Raisch wrote:
> David Miller <[EMAIL PROTECTED]> wrote on 12.09.2007 14:50:04:
>
> > I agree that it should be fixed, but we should also fix the IRQ
> > distribution scheme used on powerpc platforms which is totally
> > broken in these cases.
>
> This is d
Kumar, can you please pick up the following patches and push them to paulus?
http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11303
http://patchwork.ozlabs.org/linuxppc/patch?id=13235
http://patchwork.ozlabs.org/linuxppc/patch?id=13249
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab
On Sep 12, 2007, at 10:48 AM, Grant Likely wrote:
> Kumar, can you please pick up the following patches and push them
> to paulus?
>
> http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11303
I'll hand this one.
> http://patchwork.ozlabs.org/linuxppc/patch?id=13235
> http://patchwork.ozla
Ben, Uli
Paul/BenH suggested that you might be able to help with my question.
> On Aug 17, 2007, at 7:54 PM, Segher Boessenkool wrote:
>
>>> Is anyone really still using the stabs format for kernel debug?
>>>
>>> can we kill off the .stabs references?
>>
>> What, you want to replace them with dwa
On 9/12/07, Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Sep 12, 2007, at 10:48 AM, Grant Likely wrote:
>
> > Kumar, can you please pick up the following patches and push them
> > to paulus?
> >
> > http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11303
>
> I'll hand this one.
>
> > http://pa
On Wed, 12 Sep 2007 10:13:50 +0200
Arnd Bergmann wrote:
> On Wednesday 12 September 2007, Vitaly Bordug wrote:
>
> >
> > Well, it's more a rewrite than a move, based on 64-bit
> > implementation.
>
> ok.
>
> > > Could you perhaps split the patch into two separate changesets,
> > > one that mak
On Thu, 13 Sep 2007, Paul Mackerras wrote:
>
> Linus, this seems a bit cleaner than putting ifdefs in
> drivers/char/tty_ioctl.c, and it fixes the compile error on powerpc.
> Your choice whether to use this patch or Tony's.
Yeah, I'll take this one. I just wanted to understand why it triggered
Added basic board port for MPC8572 DS reference platform that is
similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
Updated device tree based on comments.
arch/powerpc/boot/dts/mpc8572ds.dts | 385
arch/powerp
On Wed, Sep 12, 2007 at 11:20:06AM -0500, Kumar Gala wrote:
> + [EMAIL PROTECTED] {
> + reg = <0 0 0 0 0>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + device_type = "pci";
> + [E
Removed the following cruft from .dts files:
* 32-bit in cpu node -- doesn't exist in any spec and not used by kernel
* built-in for non-standard buses (ISA, PCI)
* Removed #interrupt-cells in places they don't need to be set
* Fixed ranges on lite5200*
---
Exists in my for-2.6.24 branch
arch/p
On Sep 12, 2007, at 11:36 AM, Scott Wood wrote:
> On Wed, Sep 12, 2007 at 11:20:06AM -0500, Kumar Gala wrote:
>> +[EMAIL PROTECTED] {
>> +reg = <0 0 0 0 0>;
>> +#size-cells = <2>;
>> +#address-cells = <3>;
>> +
On Wed, Sep 12, 2007 at 12:04:20PM -0500, Kumar Gala wrote:
> I'm leaving them for now to match the others, we can clean them all
> up at the same time.
OK.
> Technically built-in is spec'd by the CHRP spec for ISA/PCI.
I looked in the CHRP I/O Device Reference and didn't see it, though I may
On Wednesday 12 September 2007 20:01, Greg KH wrote:
> 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.
> >
> > U
On Wednesday September 12, [EMAIL PROTECTED] wrote:
> On Wednesday 12 September 2007 20:01, Greg KH wrote:
> > 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
On Sep 12, 2007, at 06:26, Anton Vorontsov wrote:
> Lately I've got this nice badness on mdio bus removal:
>
> Device 'e0103120:06' does not have a release() function, it is
> broken and must be fixed.
> [ cut here ]
> Badness at drivers/base/core.c:107
> NIP: c015c1a8 L
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get four small bug-fixes for embedded powerpc from Kumar, plus a
one-liner from Olof that I missed putting in the previous batch.
Thanks,
Paul.
arch/powerpc/kernel/legacy_serial.c|
Hello,
> > I have looked up "kernel/irq/manage.c". "-ENOSYS" is returned on function
> > "setup_irq" because the used irq(MPC52xx_IRQ2) is the same as no_irq_chip.
> >
> > THE MPC52xx_IRQ2 is a excerpt from "include/ppc/mpc52xx.h" (per copy
> > paste), but mpc52xx is (now) a powerpc-arch. What is
On 9/12/07, S. Fricke <[EMAIL PROTECTED]> wrote:
> Hello,
>
> > > I have looked up "kernel/irq/manage.c". "-ENOSYS" is returned on function
> > > "setup_irq" because the used irq(MPC52xx_IRQ2) is the same as no_irq_chip.
> > >
> > > THE MPC52xx_IRQ2 is a excerpt from "include/ppc/mpc52xx.h" (per co
Anton Vorontsov wrote:
> This patch is against paulus/powerpc.git or galak/powerpc.git tree.
> Both affected.
Acked-by: Timur Tabi <[EMAIL PROTECTED]>
This is an important fix. Without it, 836x and 832x won't build.
--
Timur Tabi
Linux Kernel Developer @ Freescale
_
What happens if someone runs the new driver with older firmware? Or
what if someone upgrades the firmware without updating the driver?
- R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Esben Haabendal wrote:
> Also, fs_enet_mdio_bb_exit does not work, as shown in the log below.
> Not that I need it, but I guess it should be working when it is there.
I think this is a generic PHY issue, addressed by this patch:
http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042342.html
On Wed, 2007-09-12 at 10:47 +0200, Arnd Bergmann wrote:
> 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 loc
Looks a lot better, thanks!
Some minor nits and suggestions...
> +/ {
> + model = "fsl,MPC8572DS";
> + compatible = "fsl,MPC8572DS", "fsl,MPC85xxDS";
We don't want "xx" compatible entries; especially here it makes
no sense at all. If the board is compatible to some other (older)
board,
+ [EMAIL PROTECTED] {
+ reg = <0 0 0 0 0>;
>>>
>>> This looks kind of bogus...
>>
>> Its a PCIe to PCI bridge that is transparent.
>
> Right if it has no control registers, I think it should just lack
> 'reg', not define a zero-length register block.
"reg" f
>> 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.
>
> What tree are you using? Commit
> 804ace8881d211ac448082e871dd312132393049
> in Paul's git tree should have fixed that.
Str
>>> + i8259: [EMAIL PROTECTED] {
>>> + reg = <1 20 2
>>> + 1 a0 2
>>> + 1 4d0 2>;
>>> +
> + [EMAIL PROTECTED] {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + ranges = < ffe0 0010>;
> + reg = ; // CCSRBAR & soc regs, remove
> once parse
> code for immrbase fixed
Hrm,
> * 32-bit in cpu node -- doesn't exist in any spec and not used by
> kernel
Yeah.
> * built-in for non-standard buses (ISA, PCI)
"built-in" is some weird CHRP property, so yes we don't need it
or want it.
> * Removed #interrupt-cells in places they don't need to be set
Great :-)
> * Fixed r
>>> well the ifdefs are orthogonal. We don't have a way of knowing
>>> primary from the device tree today.
>>
>> How about something like "fsl,primary-phb" in the bus device node? I
>> don't
>> know, maybe it's already been discussed and turned down for some
>> reason.
>
> It's more of a Linux i
+struct ranges_pci {
+ unsigned int pci_space;
+ u64 pci_addr;
+ phys_addr_t phys_addr;
+ u64 size;
+} __attribute__((packed));
+
>>>
>>> This structure definition uses unaligned members because of the
>>> 'packed' attribute. Is that really what you intended?
>>> + [EMAIL PROTECTED] {
>>> + compatible = "fsl,8572-l2-cache-controller";
>>> + reg = <2 1000>;
>>> + cache-line-size = <20>; // 32 bytes
>>> + cache-size = <8>; // L2, 512K
>>> + interr
On Sep 12, 2007, at 5:10 PM, Segher Boessenkool wrote:
>> * 32-bit in cpu node -- doesn't exist in any spec and not used by
>> kernel
>
> Yeah.
>
>> * built-in for non-standard buses (ISA, PCI)
>
> "built-in" is some weird CHRP property, so yes we don't need it
> or want it.
Do you suggest we
On Sep 12, 2007, at 8:20 AM, Segher Boessenkool wrote:
+ [EMAIL PROTECTED] {
+ compatible = "fsl,8572-l2-cache-controller";
+ reg = <2 1000>;
+ cache-line-size = <20>; // 32 bytes
+ cache-siz
On Sep 12, 2007, at 9:10 AM, Segher Boessenkool wrote:
+ i8259: [EMAIL PROTECTED] {
+ reg = <1 20 2
+ 1 a0 2
+
On Sep 12, 2007, at 8:36 AM, Segher Boessenkool wrote:
> Looks a lot better, thanks!
>
> Some minor nits and suggestions...
>
>> +/ {
>> +model = "fsl,MPC8572DS";
>> +compatible = "fsl,MPC8572DS", "fsl,MPC85xxDS";
>
> We don't want "xx" compatible entries; especially here it makes
> no se
Jan-Bernd Themann wrote:
> Introduces a module parameter to decide whether the physical
> port link state is propagated to the network stack or not.
> It makes sense not to take the physical port state into account
> on machines with more logical partitions that communicate
> with each other. This
Hi,
I am try to boot the 2.6.23-rc3 kernel to my custom board based on
8641D Processor. After uncompressing the kernel it was hang. I got the
following messages.
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x60.
Then i tried to debug with GDB. In
On Sep 12, 2007, at 11:18 PM, sivaji wrote:
>
> Hi,
> I am try to boot the 2.6.23-rc3 kernel to my custom board
> based on
> 8641D Processor. After uncompressing the kernel it was hang. I got the
> following messages.
>
>Uncompressing Kernel Image ... OK
>Booting using flat devi
1 - 100 of 127 matches
Mail list logo
