* Re: MODPOST section mismatches
From: Steve Heflin @ 2008-02-22 23:07 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <20080222163625.29433d12@weaponx>
At 05:36 PM 2/22/2008, you wrote:
>On Fri, 22 Feb 2008 17:26:52 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > FLAT_MEM is one of the configuration options:
> > CONFIG_ARCH_FLATMEM_ENABLE=y
>
>That has to do with NUMA stuff. It really doesn't have much bearing on
>the section warnings.
ah, thanks for setting me straight. I thought it meant that
everything existed in a flat address space and existed in memory at
the same time, and therefore the different section warnings might not apply.
^ permalink raw reply
* Re: [PATCH] powerpc: Get rid of invalid shifts in math-emu
From: Segher Boessenkool @ 2008-02-22 23:13 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1203719063.6976.22.camel@pasglop>
> _However_ there are significant code changes in there, and I don't
> actually understand that code (well, I admit I haven't tried),
Yeah, it's written in 70's style C. Yuck.
> so it could definitely use a bit of a commit message explaining
> the rationale
Right. I had to fix git-send-email and then I forgot to type up
some more comments.
> (you are removing a lot of stuff),
Not actually, more below.
> and maybe somebody
> can run a few tests to make sure things work fine ?
That would be nice. I don't know any comprehensive IEEE FP test suite
to use on this, nor do I have a platform that normally uses this code
(though I bet I could force a 750 to use it, some way).
I'll resend with some coherent checkin comment after someone has tested
this :-)
This patch is a prime example why diff -c is so much more readable
than diff -u. But let's not digress, let's look at the code!
So the code used to look like:
#define _FP_FRAC_SLL_2(X,N)
\
do {
\
if ((N) < _FP_W_TYPE_SIZE)
\
{
\
if (__builtin_constant_p(N) && (N) == 1)
\
{
\
X##_f1 = X##_f1 + X##_f1 + (((_FP_WS_TYPE)(X##_f0)) < 0);
\
X##_f0 += X##_f0;
\
}
\
else
\
{
\
X##_f1 = X##_f1 << (N) | X##_f0 >> (_FP_W_TYPE_SIZE - (N));
\
X##_f0 <<= (N);
\
}
\
}
\
else
\
{
\
X##_f1 = X##_f0 << ((N) - _FP_W_TYPE_SIZE);
\
X##_f0 = 0;
\
}
\
} while (0)
and after my change it is:
#define _FP_FRAC_SLL_2(X,N)
\
do {
\
int n = (N);
\
if (n >= _FP_W_TYPE_SIZE)
\
{
\
X##_f1 = X##_f0;
\
X##_f0 = 0;
\
n -= _FP_W_TYPE_SIZE;
\
}
\
X##_f1 = X##_f1 << n | X##_f0 >> (_FP_W_TYPE_SIZE - n - 1) >> 1;
\
X##_f0 <<= n;
\
} while (0)
The __builtin_constant_p(N) && (N == 1) special casing in the original
is just noise, it won't result in more efficient code. When N is a
compile-time constant (remember, this "function" is a preprocessor
macro),
one of the two branches of the "if" in the original evokes undefined
behaviour (shift by a negative number, resp. shift by a number >= 32).
I rewrote this to "shift" by a whole word first if necessary, and then
by whatever is left.
With recent GCC, all this nonsense doesn't help a bit: f could just have
been a u64, with no worse code generated. OTOH, I don't really feel
like rewriting all of this. I might have to though, if I want to get
rid
of all the "might be used uninitialised" warnings and errors as well :-(
Segher
^ permalink raw reply
* Re: [PATCH RFC 4/7] [GPIO] Let drivers link if they support GPIO API as an addition
From: David Brownell @ 2008-02-22 23:42 UTC (permalink / raw)
To: cbouatmailru, avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071210230445.GA1141@zarina>
On Monday 10 December 2007, Anton Vorontsov wrote:
> On Mon, Dec 10, 2007 at 02:55:24PM -0800, David Brownell wrote:
> > The point of CONFIG_GENERIC_GPIO is to be *the* conditional used to
> > tell whether that programming interface is available ... starting
> > from "#include <asm/gpio.h>", and including all gpio_*() calls.
> >
> > So my first reaction is to not like this patch. It changes semantics
> > in an incompatible way. And AFAICT, needlessly so.
>
> Why incompatible? gpio-aware drivers will get -ENOSYS on gpio_request,
> thus they will not do anything wrong. GPIO-only drivers could still
> depend on GENERIC_GPIO, and their behaviour will not change.
If you still want this, I think a better approach would be:
http://marc.info/?l=linux-kernel&m=120295461410848&w=2
That is, #include <linux/gpio.h> and have *that* do the relevant
switch, based on GENERIC_GPIO. No semantic changes at all, if
one discounts the implicit switch to <linux/gpio.h> (important
for platforms that don't *have* any <asm/gpio.h> header), which
won't affect any existing code.
So your NAND code could use that, and work equally well on
SOC variants that have generic GPIOs and those that don't.
Comments?
- Dave
^ permalink raw reply
* [PATCH] [POWERPC] 40X: Add Default Restart Machdep Method to 40X Platforms
From: Grant Erickson @ 2008-02-22 23:28 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
This patch restores the reset on restart functionality to 40x-based
platforms that was formerly provided--but not used in arch/powerpc--by
abort() in head_40x.S. This functionality is now provided by
ppc40x_reset_system(char *) in a fashion similar to that of the 44x-based
platforms.
Compiled, linked and tested against the AMCC Haleakala board.
Signed-off-by: Grant Erickson <gerickson@nuovations.com>
---
diff -rauN linux-2.6.25-rc2-git1/arch/powerpc/kernel/head_40x.S
linux-2.6.25-rc2-git1.N/arch/powerpc/kernel/head_40x.S
--- linux-2.6.25-rc2-git1/arch/powerpc/kernel/head_40x.S 2008-01-24
14:58:37.000000000 -0800
+++ linux-2.6.25-rc2-git1.N/arch/powerpc/kernel/head_40x.S 2008-02-22
11:02:56.000000000 -0800
@@ -961,11 +961,6 @@
blr
-_GLOBAL(abort)
- mfspr r13,SPRN_DBCR0
- oris r13,r13,DBCR0_RST_SYSTEM@h
- mtspr SPRN_DBCR0,r13
-
_GLOBAL(set_context)
#ifdef CONFIG_BDI_SWITCH
diff -rauN linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/40x.h
linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/40x.h
--- linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/40x.h 1969-12-31
16:00:00.000000000 -0800
+++ linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/40x.h 2008-02-22
11:02:56.000000000 -0800
@@ -0,0 +1,6 @@
+#ifndef __POWERPC_PLATFORMS_40X_40X_H
+#define __POWERPC_PLATFORMS_40X_40X_H
+
+extern void ppc40x_reset_system(char *cmd);
+
+#endif /* __POWERPC_PLATFORMS_40X_40X_H */
diff -rauN linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/ep405.c
linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/ep405.c
--- linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/ep405.c 2008-02-22
11:07:53.000000000 -0800
+++ linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/ep405.c 2008-02-22
11:02:56.000000000 -0800
@@ -30,6 +30,8 @@
#include <asm/uic.h>
#include <asm/pci-bridge.h>
+#include "40x.h"
+
static struct device_node *bcsr_node;
static void __iomem *bcsr_regs;
@@ -119,5 +121,6 @@
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
- .calibrate_decr = generic_calibrate_decr,
+ .restart = ppc40x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
};
diff -rauN linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/kilauea.c
linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/kilauea.c
--- linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/kilauea.c 2008-02-22
11:07:53.000000000 -0800
+++ linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/kilauea.c
2008-02-22 11:02:56.000000000 -0800
@@ -21,6 +21,8 @@
#include <asm/uic.h>
#include <asm/pci-bridge.h>
+#include "40x.h"
+
static __initdata struct of_device_id kilauea_of_bus[] = {
{ .compatible = "ibm,plb4", },
{ .compatible = "ibm,opb", },
@@ -54,5 +56,6 @@
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
- .calibrate_decr = generic_calibrate_decr,
+ .restart = ppc40x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
};
diff -rauN linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/makalu.c
linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/makalu.c
--- linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/makalu.c 2008-02-22
11:07:53.000000000 -0800
+++ linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/makalu.c
2008-02-22 11:02:56.000000000 -0800
@@ -21,6 +21,8 @@
#include <asm/uic.h>
#include <asm/pci-bridge.h>
+#include "40x.h"
+
static __initdata struct of_device_id makalu_of_bus[] = {
{ .compatible = "ibm,plb4", },
{ .compatible = "ibm,opb", },
@@ -54,5 +56,6 @@
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
- .calibrate_decr = generic_calibrate_decr,
+ .restart = ppc40x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
};
diff -rauN linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/Makefile
linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/Makefile
--- linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/Makefile 2008-02-22
11:07:53.000000000 -0800
+++ linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/Makefile
2008-02-22 11:02:56.000000000 -0800
@@ -1,3 +1,4 @@
+obj-$(CONFIG_40x) += misc_40x.o
obj-$(CONFIG_KILAUEA) += kilauea.o
obj-$(CONFIG_MAKALU) += makalu.o
obj-$(CONFIG_WALNUT) += walnut.o
diff -rauN linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/misc_40x.S
linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/misc_40x.S
--- linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/misc_40x.S
1969-12-31 16:00:00.000000000 -0800
+++ linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/misc_40x.S
2008-02-22 15:19:14.000000000 -0800
@@ -0,0 +1,30 @@
+/*
+ * This file contains miscellaneous low-level functions for PPC 40x.
+ *
+ * Copyright (c) 1999 Grant Erickson <grant@lcse.umn.edu>
+ * Copyright 2007 David Gibson <dwg@au1.ibm.com>, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+
+#include <asm/reg.h>
+#include <asm/ppc_asm.h>
+
+ .text
+
+/*
+ * void ppc40x_reset_system(char *cmd)
+ *
+ * At present, this just applies a system reset which, historically, when
+ * this routine existed as '_abort' in head_40x.S was sufficient for most
+ * systems.
+ */
+_GLOBAL(ppc40x_reset_system)
+ mfspr r13,SPRN_DBCR0
+ oris r13,r13,DBCR0_RST_SYSTEM@h
+ mtspr SPRN_DBCR0,r13
+ b . /* Just in case reset fails. */
diff -rauN linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/virtex.c
linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/virtex.c
--- linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/virtex.c 2008-02-22
11:07:53.000000000 -0800
+++ linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/virtex.c
2008-02-22 11:02:56.000000000 -0800
@@ -15,6 +15,8 @@
#include <asm/time.h>
#include <asm/xilinx_intc.h>
+#include "40x.h"
+
static struct of_device_id xilinx_of_bus_ids[] __initdata = {
{ .compatible = "xlnx,plb-v46-1.00.a", },
{ .compatible = "xlnx,plb-v34-1.01.a", },
@@ -48,5 +50,6 @@
.probe = virtex_probe,
.init_IRQ = xilinx_intc_init_tree,
.get_irq = xilinx_intc_get_irq,
- .calibrate_decr = generic_calibrate_decr,
+ .restart = ppc40x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
};
diff -rauN linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/walnut.c
linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/walnut.c
--- linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/walnut.c 2008-02-22
11:07:53.000000000 -0800
+++ linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/walnut.c
2008-02-22 11:02:56.000000000 -0800
@@ -27,6 +27,8 @@
#include <asm/uic.h>
#include <asm/pci-bridge.h>
+#include "40x.h"
+
static __initdata struct of_device_id walnut_of_bus[] = {
{ .compatible = "ibm,plb3", },
{ .compatible = "ibm,opb", },
@@ -61,5 +63,6 @@
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
+ .restart = ppc40x_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
^ permalink raw reply
* Re: libfdt: More tests of NOP handling behaviour
From: Jerry Van Baren @ 2008-02-22 23:42 UTC (permalink / raw)
To: David Gibson, Jon Loeliger, linuxppc-dev
In-Reply-To: <20080220020407.GC18944@localhost.localdomain>
David Gibson wrote:
> On Tue, Feb 19, 2008 at 08:18:19PM -0500, Jerry Van Baren wrote:
>> Jon Loeliger wrote:
>>> So, like, the other day David Gibson mumbled:
>>>> In light of the recently discovered bug with NOP handling, this adds
>>>> some more testcases for NOP handling. Specifically, it adds a helper
>>>> program which will add a NOP tag after every existing tag in a dtb,
>>>> and runs the standard battery of tests over trees mangled in this way.
>>>>
>>>> For now, this does not add a NOP at the very beginning of the
>>>> structure block. This causes problems for libfdt at present, because
>>>> we assume in many places that the root node's BEGIN_NODE tag is at
>>>> offset 0. I'm still contemplating what to do about this (with one
>>>> option being simply to declare such dtbs invalid).
>>>>
>>>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>>> Applied.
>>>
>>> BTW, declaring DTBs with BEGIN_NODES not at offset 0
>>> as invalid seems like a fine choice to me.
>>>
>>> jdl
>> FWIIW, I vote ditto on declaring DTBs with BEGIN_NODES not at offset 0
>> as invalid. The root being at offset 0 assumption is pretty well
>> entrenched and I cannot think of any reason to change it that would be
>> worth the effort.
>
> Well, it's actually not that hard to deal with. I've already been
> planning to add a helper function/macro which validates a node offset
> (something currently open-coded in a whole bunch of places). It would
> be fairly easy to make it skip over nops as well.
>
> But, likewise I can think of no reason that NOPs before the root node
> would be useful or likely to occur in practice.
Hi David,
Originally, finding the root node by searching the path "/" would return
an error so I specifically caught that case and used 0 for the offset.
I looked over the current u-boot and libfdt code and it looks like that
works now (u-boot no longer traps "/") so the offset 0 == root node
assumption is no longer built into u-boot. That is good.
OTOH, now I got some comments in u-boot I need to fix. :-/ Oh well, it
is a net win. :-)
Best regards,
gvb
^ permalink raw reply
* RE: NETdev driver question xxxx_type_trans()
From: Russell McGuire @ 2008-02-22 23:48 UTC (permalink / raw)
To: 'Andy Fleming'; +Cc: linuxppc-embedded
In-Reply-To: <E5A4895F-4CED-44C5-BFD1-9FD3E57F69CF@freescale.com>
Andy,
Thanks... I only have the hdlc_type_trans, on the RX side of the equation.
I want the driver to be able to support two modes, so not sure if I am going
to have to put an ioctl switch into to turn this on / off.
Mode 1) I want the driver to be able to simulate an Ethernet device, which I
assume will need to use the hdlc_type_trans(), to remove layer 2.
Mode 2) I want the driver to be able to support fully RAW mode, but then
again, perhaps the hdlc_type_trans() knows this already depending on what
mode I am setup in, via 'sethdlc' ???
At the moment before I am able to use the device, I have to configure it via
'sethdlc hdlc0 hdlc-eth' or similar. <-- that previous call I assuming links
it to the TCP/IP stack as I can assign IP addresses with
"ifconfig hdlc0 up 192.168.1.100".
However, for true P2P support, I was wanting to be able to open the device
directly and manage everything directly at the application level, i.e. the
only protocol would be "Application Layer->HDLC" and nothing in between.
In that case, I was concerned that any removal of Layer 2 stuff, simply
would be unnecessary as the 83xx already pulls the HDLC layer stuff off,
before I get the sk_buff. <Using the MCC Engine to a TDM<T1> port>.
So not sure if the kernel will let me... But that is one of my goals.
-Russ
> -----Original Message-----
> From: Andy Fleming [mailto:afleming@freescale.com]
> Sent: Friday, February 22, 2008 12:39 PM
> To: rmcguire@videopresence.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: NETdev driver question xxxx_type_trans()
>
>
> On Feb 22, 2008, at 14:26, Russell McGuire wrote:
>
> > All,
> >
> > A general and specific question on the behavior of netdev devices
> > before received sk_buff(s) get passed up to the kernel.
> >
> > I am almost done creating / testing an HDLC device driver for the
> > 83xx.
> >
> >
> > I have it working at a low level and was printing out skb_bufs
> > before and after TX and RX, to ensure data integrity.
> >
> > Due to me having the print_skbbuf, AFTER the hdlc_type_trans(skb,
> > ndev).
> >
> > I thought I was continuously losing 14 bytes of data, after a
> > little digging I realized that the hdlc_type_trans() call
> >
> > was shifting the skb->data pointer forward by 14 bytes. ????????
> >
> > Is this corresponding to a 14 byte pad that the kernel stack adds
> > before it sends it down?
> >
> > And why isn't the data length being shortened as a result after I
> > call hdlc_type_trans?
> >
> > Anyway. I guess I am confused as to what this function was intended
> > for, I see there are other calls for eth_type_trans, so I imagine
> > their usage is similar.
> >
> > When are they needed?
> >
>
>
> They move the data pointer to point to the start of the L2 header.
> There's no need for the kernel to see the L1 header, and it doesn't
> expect it to be there when it looks at the skb.
>
> You shouldn't be using it for TX packets. For TX, I believe the
> kernel takes care of setting up the L1 header, though I'm not
> familiar with the kernel's hdlc support.
>
> Andy
^ permalink raw reply
* Re: [PATCH RFC 4/7] [GPIO] Let drivers link if they support GPIO API as an addition
From: Anton Vorontsov @ 2008-02-22 23:35 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev
In-Reply-To: <200802221542.03359.david-b@pacbell.net>
On Fri, Feb 22, 2008 at 03:42:03PM -0800, David Brownell wrote:
> On Monday 10 December 2007, Anton Vorontsov wrote:
> > On Mon, Dec 10, 2007 at 02:55:24PM -0800, David Brownell wrote:
>
> > > The point of CONFIG_GENERIC_GPIO is to be *the* conditional used to
> > > tell whether that programming interface is available ... starting
> > > from "#include <asm/gpio.h>", and including all gpio_*() calls.
> > >
> > > So my first reaction is to not like this patch. It changes semantics
> > > in an incompatible way. And AFAICT, needlessly so.
> >
> > Why incompatible? gpio-aware drivers will get -ENOSYS on gpio_request,
> > thus they will not do anything wrong. GPIO-only drivers could still
> > depend on GENERIC_GPIO, and their behaviour will not change.
>
> If you still want this, I think a better approach would be:
>
> http://marc.info/?l=linux-kernel&m=120295461410848&w=2
>
> That is, #include <linux/gpio.h> and have *that* do the relevant
> switch, based on GENERIC_GPIO. No semantic changes at all, if
> one discounts the implicit switch to <linux/gpio.h> (important
> for platforms that don't *have* any <asm/gpio.h> header), which
> won't affect any existing code.
>
> So your NAND code could use that, and work equally well on
> SOC variants that have generic GPIOs and those that don't.
>
> Comments?
I like it. :-) Thanks.
p.s. would be great to see this in 2.6.25, so we can start use
this include for the new code.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: MODPOST section mismatches
From: Josh Boyer @ 2008-02-23 0:30 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <20080222230722.B7FDBDDE45@ozlabs.org>
On Fri, 22 Feb 2008 18:07:37 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:
> At 05:36 PM 2/22/2008, you wrote:
> >On Fri, 22 Feb 2008 17:26:52 -0500
> >Steve Heflin <sheflin@newagemicro.com> wrote:
> >
> > > FLAT_MEM is one of the configuration options:
> > > CONFIG_ARCH_FLATMEM_ENABLE=y
> >
> >That has to do with NUMA stuff. It really doesn't have much bearing on
> >the section warnings.
>
> ah, thanks for setting me straight. I thought it meant that
> everything existed in a flat address space and existed in memory at
> the same time, and therefore the different section warnings might not apply.
Nah. The section warnings come about because if something is marked
__init but referenced in a function that isn't then an oops could occur
because the __init sections are discarded after a certain point in the
kernel boot. The same is true for __devinit, etc.
So the section warnings are still bugs that need fixing, but they're
orthogonal to the memory model for the most part.
josh
^ permalink raw reply
* Re: MODPOST section mismatches
From: Steve Heflin @ 2008-02-23 0:38 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <20080222183025.280b6ea3@vader.jdub.homelinux.org>
At 07:30 PM 2/22/2008, you wrote:
>On Fri, 22 Feb 2008 18:07:37 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > At 05:36 PM 2/22/2008, you wrote:
> > >On Fri, 22 Feb 2008 17:26:52 -0500
> > >Steve Heflin <sheflin@newagemicro.com> wrote:
> > >
> > > > FLAT_MEM is one of the configuration options:
> > > > CONFIG_ARCH_FLATMEM_ENABLE=y
> > >
> > >That has to do with NUMA stuff. It really doesn't have much bearing on
> > >the section warnings.
> >
> > ah, thanks for setting me straight. I thought it meant that
> > everything existed in a flat address space and existed in memory at
> > the same time, and therefore the different section warnings might
> not apply.
>
>Nah. The section warnings come about because if something is marked
>__init but referenced in a function that isn't then an oops could occur
>because the __init sections are discarded after a certain point in the
>kernel boot. The same is true for __devinit, etc.
>
>So the section warnings are still bugs that need fixing, but they're
>orthogonal to the memory model for the most part.
>
>josh
Isn't there a way to keep the __init sections from being discarded
such that I can run it without an oops occurring?
thanks for your help!
Steve
^ permalink raw reply
* Re: [PATCH 1/5] [POWERPC] Add AMCC 460EX/460GT support to cputable.c & cpu_setup_44x.S
From: Paul Mackerras @ 2008-02-23 2:30 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1203602435-11302-1-git-send-email-sr@denx.de>
Stefan Roese writes:
> Signed-off-by: Stefan Roese <sr@denx.de>
That's a very uninformative commit message. :)
How about putting a brief description of the AMCC 460 family in here?
Paul.
^ permalink raw reply
* Re: [PATCH 2/5] [POWERPC] Add AMCC Canyonlands 460EX eval board support to platforms/44x
From: Paul Mackerras @ 2008-02-23 2:31 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1203602446-11330-1-git-send-email-sr@denx.de>
Stefan Roese writes:
> Signed-off-by: Stefan Roese <sr@denx.de>
Put a brief description of the Canyonlands in the patch description.
Paul.
^ permalink raw reply
* Re: [PATCH 5/5] [POWERPC] Add 460EX PCIe support to 4xx pci driver
From: Paul Mackerras @ 2008-02-23 2:34 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1203602482-11415-1-git-send-email-sr@denx.de>
Stefan Roese writes:
> Tested on AMCC Canyonlands eval board.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
With 173 lines of code added, you could spend a paragraph in the patch
description telling us why the patch is doing what it's doing the way
it's doing it. Perhaps even tell us why it takes 173 new lines of
code to do something that sounds pretty simple - tell us what the
complexities you encountered were.
Paul.
^ permalink raw reply
* Re: [PATCH 1/5] [POWERPC] Add AMCC 460EX/460GT support to cputable.c & cpu_setup_44x.S
From: Stefan Roese @ 2008-02-23 7:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18367.34134.510940.418464@cargo.ozlabs.ibm.com>
On Saturday 23 February 2008, Paul Mackerras wrote:
> Stefan Roese writes:
> > Signed-off-by: Stefan Roese <sr@denx.de>
>
> That's a very uninformative commit message. :)
>
> How about putting a brief description of the AMCC 460 family in here?
You're right. I was a little bit lazy. :)
I'll add some more text to the commit messages and resubmit in a short while.
Best regards,
Stefan
^ permalink raw reply
* Re: MPC8540 : What's "SPE used in kernel" ?
From: Philippe De Muyter @ 2008-02-23 9:24 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev
In-Reply-To: <08A7CD2B-27EA-4C97-9220-314E36BBBAA6@freescale.com>
On Fri, Feb 22, 2008 at 12:33:19PM -0600, Andy Fleming wrote:
>
> On Feb 22, 2008, at 03:50, Philippe De Muyter wrote:
>
>> Dear list,
>>
>> I have just compiled linux-2.6.24 for a MPC8540 target using a MPC8540
>> specific gcc.
>>
>> I then got tan infinity of "SPE used in kernel" messages. Looking at the
>> sources I ifdeffed out the printk call in KernelSPE, and I now have a
>> silent kernel, that seems to work fine.
>>
>> Is there something wrong in my setting and should I look further to
>> debug this problem or is this perfectly normal ?
>>
>> I wonder why a kernel configured for E500 and compiled by a E500-specific
>> gcc
>> triggers this message. Is it invalid to use SPE instructions in the
>> kernel
>> or do I misunderstand the message ?
>
>
> We don't currently support using SPE in the kernel. Are you using SPE in
> the kernel for some reason? Do you think that the compiler is
> automatically generating SPE code in the kernel? I've never seen that
> before.
>
> Andy
I have bought a modified CLFS installation targetting by default a MPC8540.
By default my powerpc compiler thus generates also SPE instructions.
And I built linux using that compiler.
My first trial used ARCH=ppc and caused this infinity of "SPE used in kernel"
messages, but I then recompiled linux with ARCH=powerpc. With the message
not ifdef'ed out, this second kernel does not emit "SPE used in kernel"
messages, but I noticed problems with processes dying unexpectedly
(like in the first one, but after my first mail to the list).
Do you by chance know which MPC8540 registers are not saved by the kernel ?
Philippe
^ permalink raw reply
* Re: MPC8540 : What's "SPE used in kernel" ?
From: Johannes Berg @ 2008-02-23 9:51 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080223092458.GA6873@10.1.86.20>
[-- Attachment #1: Type: text/plain, Size: 483 bytes --]
> My first trial used ARCH=ppc and caused this infinity of "SPE used in kernel"
> messages, but I then recompiled linux with ARCH=powerpc. With the message
> not ifdef'ed out, this second kernel does not emit "SPE used in kernel"
> messages,
If I were to venture a guess I'd point to the fact that the arch/powerpc
Makefile contains
# No SPE instruction when building kernel
KBUILD_CFLAGS += $(call cc-option,-mno-spe)
while the arch/ppc one doesn't.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: MPC8540 : What's "SPE used in kernel" ?
From: Philippe De Muyter @ 2008-02-23 10:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1203760269.13162.11.camel@johannes.berg>
Hi Johanness,
On Sat, Feb 23, 2008 at 10:51:08AM +0100, Johannes Berg wrote:
>
> > My first trial used ARCH=ppc and caused this infinity of "SPE used in kernel"
> > messages, but I then recompiled linux with ARCH=powerpc. With the message
> > not ifdef'ed out, this second kernel does not emit "SPE used in kernel"
> > messages,
>
> If I were to venture a guess I'd point to the fact that the arch/powerpc
> Makefile contains
>
> # No SPE instruction when building kernel
> KBUILD_CFLAGS += $(call cc-option,-mno-spe)
OK, that's a good point.
But as I said in the same mail, processes still dies unexpectedly.
>
> while the arch/ppc one doesn't.
>
> johannes
Philippe
^ permalink raw reply
* Re: MPC8540 : What's "SPE used in kernel" ?
From: Johannes Berg @ 2008-02-23 10:25 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080223101707.GA7194@10.1.86.20>
[-- Attachment #1: Type: text/plain, Size: 246 bytes --]
> But as I said in the same mail, processes still dies unexpectedly.
Yeah, no idea though. I guess you could try putting that into the
arch/ppc Makefile, but arch/ppc will be removed this year so you don't
want to rely on it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH 2/2] firewire: endianess annotations
From: Stefan Richter @ 2008-02-23 11:24 UTC (permalink / raw)
To: linux1394-devel
Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, sparclinux,
Jarod Wilson, Sam Ravnborg, Harvey Harrison
In-Reply-To: <tkrat.e2bfb30f2c0ae70a@s5r6.in-berlin.de>
Kills warnings from 'make C=1 CHECKFLAGS="-D__CHECK_ENDIAN__" modules':
drivers/firewire/fw-transaction.c:771:10: warning: incorrect type in assignment (different base types)
drivers/firewire/fw-transaction.c:771:10: expected unsigned int [unsigned] [usertype] <noident>
drivers/firewire/fw-transaction.c:771:10: got restricted unsigned int [usertype] <noident>
drivers/firewire/fw-transaction.h:93:10: warning: incorrect type in assignment (different base types)
drivers/firewire/fw-transaction.h:93:10: expected unsigned int [unsigned] [usertype] <noident>
drivers/firewire/fw-transaction.h:93:10: got restricted unsigned int [usertype] <noident>
drivers/firewire/fw-ohci.c:1490:8: warning: restricted degrades to integer
drivers/firewire/fw-ohci.c:1490:35: warning: restricted degrades to integer
drivers/firewire/fw-ohci.c:1516:5: warning: cast to restricted type
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: sparclinux@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org
---
drivers/firewire/fw-ohci.c | 4 ++--
drivers/firewire/fw-transaction.c | 2 +-
drivers/firewire/fw-transaction.h | 6 +++---
3 files changed, 6 insertions(+), 6 deletions(-)
Index: linux/drivers/firewire/fw-ohci.c
===================================================================
--- linux.orig/drivers/firewire/fw-ohci.c
+++ linux/drivers/firewire/fw-ohci.c
@@ -1487,7 +1487,7 @@ static int handle_ir_dualbuffer_packet(s
void *p, *end;
int i;
- if (db->first_res_count > 0 && db->second_res_count > 0) {
+ if (db->first_res_count != 0 && db->second_res_count != 0) {
if (ctx->excess_bytes <= le16_to_cpu(db->second_req_count)) {
/* This descriptor isn't done yet, stop iteration. */
return 0;
@@ -1513,7 +1513,7 @@ static int handle_ir_dualbuffer_packet(s
memcpy(ctx->header + i + 4, p + 8, ctx->base.header_size - 4);
i += ctx->base.header_size;
ctx->excess_bytes +=
- (le32_to_cpu(*(u32 *)(p + 4)) >> 16) & 0xffff;
+ (le32_to_cpu(*(__le32 *)(p + 4)) >> 16) & 0xffff;
p += ctx->base.header_size + 4;
}
ctx->header_length = i;
Index: linux/drivers/firewire/fw-transaction.c
===================================================================
--- linux.orig/drivers/firewire/fw-transaction.c
+++ linux/drivers/firewire/fw-transaction.c
@@ -751,7 +751,7 @@ handle_topology_map(struct fw_card *card
void *payload, size_t length, void *callback_data)
{
int i, start, end;
- u32 *map;
+ __be32 *map;
if (!TCODE_IS_READ_REQUEST(tcode)) {
fw_send_response(card, request, RCODE_TYPE_ERROR);
Index: linux/drivers/firewire/fw-transaction.h
===================================================================
--- linux.orig/drivers/firewire/fw-transaction.h
+++ linux/drivers/firewire/fw-transaction.h
@@ -85,12 +85,12 @@
static inline void
fw_memcpy_from_be32(void *_dst, void *_src, size_t size)
{
- u32 *dst = _dst;
- u32 *src = _src;
+ u32 *dst = _dst;
+ __be32 *src = _src;
int i;
for (i = 0; i < size / 4; i++)
- dst[i] = cpu_to_be32(src[i]);
+ dst[i] = be32_to_cpu(src[i]);
}
static inline void
--
Stefan Richter
-=====-==--- --=- =-===
http://arcgraph.de/sr/
^ permalink raw reply
* [PATCH 0/2] firewire: endinaness warnings (was Re: sparse - make __CHECK_ENDIAN__ default enabled?)
From: Stefan Richter @ 2008-02-23 11:23 UTC (permalink / raw)
To: linux1394-devel
Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, sparclinux,
Jarod Wilson, Sam Ravnborg, Harvey Harrison
In-Reply-To: <1203545913.25307.47.camel@brick>
On 20 Feb, Harvey Harrison wrote on LKML:
> On Wed, 2008-02-20 at 23:03 +0100, Sam Ravnborg wrote:
>> Hi Harvey.
>>
>> Can I ask you to look into the worst offenders so we
>> can make -D__CHECK_ENDIAN__ enabled per default
>> in the kernel.
>> Or maybe we should do it anyway?
>
> Well, I've got the worst of fs and drivers/ata done so far, still
> weeping over the 5500 warnings in drivers. (X86_32 allyesconfig).
> People ignore the existing warnings anyway, why not toss a few more
> on the pile?
>
> I'll look them over tonight and see how bad it would be.
I looked into drivers/firewire and drivers/ieee1394. As expected, there
are quite a lot endianess related warnings in the latter because this is
code from way before sparse was regularly used.
There are also a few warnings in the former, even though sparse checks
were run before submission of the whole drivers/firewire stack. I will
follow up with two patches:
1/2 firewire: endianess fix
2/2 firewire: endianess annotations
Whether the "fix" is really a fix remains to be seen; I don't have a big
endian Linux box myself.
--
Stefan Richter
-=====-==--- --=- =-===
http://arcgraph.de/sr/
^ permalink raw reply
* [PATCH 1/2] firewire: endianess fix
From: Stefan Richter @ 2008-02-23 11:24 UTC (permalink / raw)
To: linux1394-devel
Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, sparclinux,
Jarod Wilson, Sam Ravnborg, Harvey Harrison
In-Reply-To: <tkrat.e2bfb30f2c0ae70a@s5r6.in-berlin.de>
The generation of incoming requests was filled in in wrong byte order on
machines with big endian CPU.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: sparclinux@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org
---
This patch is a shot in the dark, based on a warning when building with
C=1 CHECKFLAGS="-D__CHECK_ENDIAN__". Is it really a fix, or was the
previous code accidentally correct?
This needs to be tested on different big endian PCs, if possible with
the Apple Uninorth FireWire controller and other types of controllers.
One test which involves ohci->request_generation is simply with an SBP-2
device (harddisk, CD-ROM...). Does SBP-2 login etc. work?
If possible, also test whether the device remains accessible after
forcing a bus reset, e.g. by "echo br short > firecontrol". You need
the easy to build utility firecontrol and a libraw1394 with "juju"
backend. See wiki.linux1394.org for directions.
drivers/firewire/fw-ohci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/drivers/firewire/fw-ohci.c
===================================================================
--- linux.orig/drivers/firewire/fw-ohci.c
+++ linux/drivers/firewire/fw-ohci.c
@@ -375,7 +375,7 @@ static __le32 *handle_ar_packet(struct a
*/
if (p.ack + 16 == 0x09)
- ohci->request_generation = (buffer[2] >> 16) & 0xff;
+ ohci->request_generation = (p.header[2] >> 16) & 0xff;
else if (ctx == &ohci->ar_request_ctx)
fw_core_handle_request(&ohci->card, &p);
else
--
Stefan Richter
-=====-==--- --=- =-===
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 1/2] firewire: endianess fix
From: Stefan Richter @ 2008-02-23 11:36 UTC (permalink / raw)
To: linux1394-devel
Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, sparclinux,
Jarod Wilson, Sam Ravnborg, Harvey Harrison
In-Reply-To: <tkrat.9e19fa31951506af@s5r6.in-berlin.de>
I wrote:
> If possible, also test whether the device remains accessible after
> forcing a bus reset, e.g. by "echo br short > firecontrol".
"echo br short | firecontrol" of course.
This test should actually not really be necessary because simply
plugging the SBP-2 device in should already cause enough generation
changes for the code to trip over an endianess bug before or after thhe
patch, me thinks.
--
Stefan Richter
-=====-==--- --=- =-===
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 1/2] firewire: endianess fix
From: Stefan Richter @ 2008-02-23 12:12 UTC (permalink / raw)
To: linux1394-devel
Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, sparclinux,
Jarod Wilson, Sam Ravnborg, Harvey Harrison
In-Reply-To: <tkrat.9e19fa31951506af@s5r6.in-berlin.de>
I wrote:
> This needs to be tested on different big endian PCs, if possible with
> the Apple Uninorth FireWire controller and other types of controllers.
> One test which involves ohci->request_generation is simply with an SBP-2
> device (harddisk, CD-ROM...). Does SBP-2 login etc. work?
Hmm, no, tests with SBP-2 devices won't trigger that problem at all.
All of the requests from the device will be:
- read requests to the host's config ROM, handled by the controller's
physical response unit instead of the driver stack's response
handlers,
- read requests to ORBs and read and write requests to SCSI data
buffers which are DMA-mapped at bus addresses below 4G, hence be
handled by the physical response unit as well,
- write requests to firewire-sbp2's status FIFO which is mapped into
a FireWire address range for which PCI write posting is enabled,
hence no response subaction will be generated (unified transaction)
and therefore ohci->request_generation remain unused.
Alas I have no idea how to create a simple test setup which really
triggers the questionable code. Or wait, it should be triggered by
replacing
&fw_high_memory_region
by
&fw_private_region
in drivers/firewire/fw-sbp2.c and testing with any SBP-2 device which is
_not_ based on the PL3507 bridge chip. This moves the status FIFO into
an area outside of PCI write posting and forces the driver stack to
generate response packets. (Some PL-3507 only accept unified
transactions, hence this test needs to be performed with other bridge
chips.)
--
Stefan Richter
-=====-==--- --=- =-===
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
From: Jean Delvare @ 2008-02-23 12:43 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linux-kernel, linuxppc-dev list, i2c, Scott Wood
In-Reply-To: <47BEAF00.50106@scram.de>
Hi Jochen,
On Fri, 22 Feb 2008 12:16:16 +0100, Jochen Friedrich wrote:
> Hi Jean,
>
> >> +/*
> >> + * Wait for patch from Jon Smirl
> >> + * #include "powerpc-common.h"
> >> + */
> >
> > It doesn't make sense to merge this comment upstream.
>
> I know you don't like the patch from Jon Smirl and you also explained your reasons.
> Fortunately, I2c no longer uses numeric device IDs but names. So what are the alternatives?
>
> 1. modify the I2c subsystem to accept OF names additionally to I2c names (proposed by Jon smirl).
The problem I have with this is that it breaks compatibility. The chip
name is not only used for device/driver matching, it is also exported
to userspace as a sysfs attribute ("name"). Applications might rely on
it. At least libsensors does.
One way to work around the problem would be to use separate fields for
device/driver matching and the "name" attribute. However, this will add
some complexity to the i2c-core code and cost some memory as well, so
it is far from perfect.
> 2. record the I2c name in the dts tree, either as seperate tag (like linux,i2c-name="<i2c-name>")
> or as additional compatible entry (like compatible="...", "linux,<i2c-name>").
This would work, and it would require almost no change to the current
i2c-core code, but I thought that these dts files were not under our
control?
The problem I see with this approach is that the name translation would
have to be done for each dts file, rather than just once for each device
type. This means more work, but maybe this can be done if at least part
of it is automated. I admit that I never considered this option because
I considered the dts files as read-only. If this assumption was
incorrect, then maybe this is the best solution. Can you please
elaborate on the details of this proposal?
> 3. use a glue layer with a translation map.
This is what we do at the moment (see i2c_devices in
arch/powerpc/sysdev/fsl_soc.c). Jon Smirl is worried that it won't
scale well though, and I can't disagree.
> What is the preferred way to do this?
I still have to think about it. I didn't have much time to work on this
during the last 2 weeks, hopefully I will fine some time to experiment
again soon. As I underlined before, my patch set affects no less than 5
subsystems with different needs and expectations, it's no trivial
change.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 1/5] [POWERPC] Add AMCC 460EX/460GT support to cputable.c & cpu_setup_44x.S
From: Josh Boyer @ 2008-02-23 13:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <18367.34134.510940.418464@cargo.ozlabs.ibm.com>
On Sat, 23 Feb 2008 13:30:46 +1100
Paul Mackerras <paulus@samba.org> wrote:
> Stefan Roese writes:
>
> > Signed-off-by: Stefan Roese <sr@denx.de>
>
> That's a very uninformative commit message. :)
>
> How about putting a brief description of the AMCC 460 family in here?
It's rather boring at the moment. 460EX and 460GT are using a 440
core. But mentioning that is also important I would think.
josh
^ permalink raw reply
* Re: [PATCH] [POWERPC] 40X: Add Default Restart Machdep Method to 40X Platforms
From: Josh Boyer @ 2008-02-23 16:37 UTC (permalink / raw)
To: Grant Erickson; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <C3E49AAC.D8E4%erick205@umn.edu>
On Fri, 22 Feb 2008 15:28:44 -0800
Grant Erickson <erick205@umn.edu> wrote:
> This patch restores the reset on restart functionality to 40x-based
> platforms that was formerly provided--but not used in arch/powerpc--by
> abort() in head_40x.S. This functionality is now provided by
> ppc40x_reset_system(char *) in a fashion similar to that of the 44x-based
> platforms.
>
> Compiled, linked and tested against the AMCC Haleakala board.
>
> Signed-off-by: Grant Erickson <gerickson@nuovations.com>
This patch is word wrapped. Seems your mailer decided to eat tabs as
well.
josh
^ 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