* Re: [RESEND] [PATCH 1/2 v2] [OF] Add of_device_is_available function
From: Paul Mackerras @ 2008-03-24 11:39 UTC (permalink / raw)
To: Josh Boyer; +Cc: sfr, linuxppc-dev
In-Reply-To: <20080301174825.57715d46@zod.rchland.ibm.com>
Josh Boyer writes:
> This adds a function called of_device_is_available that checks the state
> of the status property of a device. If the property is absent or set to
> either "okay" or "ok", it returns 1. Otherwise it returns 0.
Well actually...
> + if (statlen > 0) {
> + if (!strncmp(status, "okay", 4) || !strncmp(status, "ok", 2))
> + return 1;
The second test will succeed for anything that starts with "ok", so
the first test is redundant. I suspect you want strcmp instead of
strncmp in both tests.
Paul.
^ permalink raw reply
* Re: [PATCH 2/11] cell: generalize io-workarounds code
From: Benjamin Herrenschmidt @ 2008-03-24 10:44 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus
In-Reply-To: <1206355309.7197.32.camel@pasglop>
On Mon, 2008-03-24 at 21:41 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2008-03-14 at 21:20 +0900, Ishizaki Kou wrote:
> > This patch splits cell io-workaround code into spider-pci dependent
> > code and a generic part, and also adds interfaces to the generic
> > io-workaround mechanism.
> >
> > Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
> > ---
>
> Hi !
>
> I noticed that you add a second level of indirection. We already have
> one going to the workarounds in the first place, so that looks a bit too
> much to my taste.
>
> I may have missed something in your patch but if the workarounds are
> specific to a given bridge, they may as well set the top level
> indirections once straight to the right workarounds.
Looking more closely, I wonder if a good solution would be to move the
function pointers away from globals, to the dev_archdata structure,
and thus make them per-device (like the DMA ops)
That way, you can populate the workarounds differently for the PCI
devices and the PCI-E devices at probe time and still have only one
indirection.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/11] cell: generalize io-workarounds code
From: Benjamin Herrenschmidt @ 2008-03-24 10:41 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080314.212034.-1625856941.kouish@swc.toshiba.co.jp>
On Fri, 2008-03-14 at 21:20 +0900, Ishizaki Kou wrote:
> This patch splits cell io-workaround code into spider-pci dependent
> code and a generic part, and also adds interfaces to the generic
> io-workaround mechanism.
>
> Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
> ---
Hi !
I noticed that you add a second level of indirection. We already have
one going to the workarounds in the first place, so that looks a bit too
much to my taste.
I may have missed something in your patch but if the workarounds are
specific to a given bridge, they may as well set the top level
indirections once straight to the right workarounds.
Also, my understanding is that we are pretty much using the same bridge
on the cell blades, so is there any way that can be consolidated rather
than having function pointers ?
I'll try to have a closer look next week, but I'm a bit worried by
having all IO go through 2 level of function pointers, the PPE isn't
very good at it and this will slow things down more than they already
are.
Cheers,
Ben.
^ permalink raw reply
* [LMB]: Add lmb_alloc_nid()
From: David Miller @ 2008-03-24 9:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
This function will be used by the NUMA setup code on sparc64, and also
it can be used by powerpc, replacing it's hand crafted
"careful_allocation()" function in arch/powerpc/mm/numa.c
If x86 ever converts it's NUMA support over to using the LMB helpers,
it can use this too as it has something entirely similar.
[LMB]: Add lmb_alloc_nid()
A variant of lmb_alloc() that tries to allocate memory on a specified
NUMA node 'nid' but falls back to normal lmb_alloc() if that fails.
The caller provides a 'nid_range' function pointer which assists the
allocator. It is given args 'start', 'end', and pointer to integer
'this_nid'.
It places at 'this_nid' the NUMA node id that corresponds to 'start',
and returns the end address within 'start' to 'end' at which memory
assosciated with 'nid' ends.
This callback allows a platform to use lmb_alloc_nid() in just
about any context, even ones in which early_pfn_to_nid() might
not be working yet.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/linux/lmb.h | 2 +
lib/lmb.c | 86 +++++++++++++++++++++++++++++++++++++++++++++------
2 files changed, 78 insertions(+), 10 deletions(-)
diff --git a/include/linux/lmb.h b/include/linux/lmb.h
index 632717c..271153d 100644
--- a/include/linux/lmb.h
+++ b/include/linux/lmb.h
@@ -42,6 +42,8 @@ extern void __init lmb_init(void);
extern void __init lmb_analyze(void);
extern long __init lmb_add(u64 base, u64 size);
extern long __init lmb_reserve(u64 base, u64 size);
+extern u64 __init lmb_alloc_nid(u64 size, u64 align, int nid,
+ u64 (*nid_range)(u64, u64, int *));
extern u64 __init lmb_alloc(u64 size, u64 align);
extern u64 __init lmb_alloc_base(u64 size,
u64, u64 max_addr);
diff --git a/lib/lmb.c b/lib/lmb.c
index e3c8dcb..5e76b36 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -227,6 +227,82 @@ long __init lmb_overlaps_region(struct lmb_region *rgn, u64 base,
return (i < rgn->cnt) ? i : -1;
}
+static u64 lmb_align_down(u64 addr, u64 size)
+{
+ return addr & ~(size - 1);
+}
+
+static u64 lmb_align_up(u64 addr, u64 size)
+{
+ return (addr + (size - 1)) & ~(size - 1);
+}
+
+static u64 __init lmb_alloc_nid_unreserved(u64 start, u64 end,
+ u64 size, u64 align)
+{
+ u64 base;
+ long j;
+
+ base = lmb_align_down((end - size), align);
+ while (start <= base &&
+ ((j = lmb_overlaps_region(&lmb.reserved, base, size)) >= 0))
+ base = lmb_align_down(lmb.reserved.region[j].base - size,
+ align);
+
+ if (base != 0 && start <= base) {
+ if (lmb_add_region(&lmb.reserved, base,
+ lmb_align_up(size, align)) < 0)
+ base = ~(u64)0;
+ return base;
+ }
+
+ return ~(u64)0;
+}
+
+static u64 __init lmb_alloc_nid_region(struct lmb_property *mp,
+ u64 (*nid_range)(u64, u64, int *),
+ u64 size, u64 align, int nid)
+{
+ u64 start, end;
+
+ start = mp->base;
+ end = start + mp->size;
+
+ start = lmb_align_up(start, align);
+ while (start < end) {
+ u64 this_end;
+ int this_nid;
+
+ this_end = nid_range(start, end, &this_nid);
+ if (this_nid == nid) {
+ u64 ret = lmb_alloc_nid_unreserved(start, this_end,
+ size, align);
+ if (ret != ~(u64)0)
+ return ret;
+ }
+ start = this_end;
+ }
+
+ return ~(u64)0;
+}
+
+u64 __init lmb_alloc_nid(u64 size, u64 align, int nid,
+ u64 (*nid_range)(u64 start, u64 end, int *nid))
+{
+ struct lmb_region *mem = &lmb.memory;
+ int i;
+
+ for (i = 0; i < mem->cnt; i++) {
+ u64 ret = lmb_alloc_nid_region(&mem->region[i],
+ nid_range,
+ size, align, nid);
+ if (ret != ~(u64)0)
+ return ret;
+ }
+
+ return lmb_alloc(size, align);
+}
+
u64 __init lmb_alloc(u64 size, u64 align)
{
return lmb_alloc_base(size, align, LMB_ALLOC_ANYWHERE);
@@ -245,16 +321,6 @@ u64 __init lmb_alloc_base(u64 size, u64 align, u64 max_addr)
return alloc;
}
-static u64 lmb_align_down(u64 addr, u64 size)
-{
- return addr & ~(size - 1);
-}
-
-static u64 lmb_align_up(u64 addr, u64 size)
-{
- return (addr + (size - 1)) & ~(size - 1);
-}
-
u64 __init __lmb_alloc_base(u64 size, u64 align, u64 max_addr)
{
long i, j;
--
1.5.4.rc3.14.g44397
^ permalink raw reply related
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-03-24 8:05 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get a few more bug-fixes for powerpc that should go in 2.6.25.
Thanks,
Paul.
arch/powerpc/mm/hash_utils_64.c | 11 ++++++++---
arch/powerpc/sysdev/bestcomm/bestcomm.c | 8 ++++++--
arch/powerpc/sysdev/ipic.c | 2 +-
drivers/net/fec_mpc52xx_phy.c | 3 ++-
4 files changed, 17 insertions(+), 7 deletions(-)
commit 7ea6fd7e2df041297298b5feb5b7b78a2b1a5310
Author: Anatolij Gustschin <agust@denx.de>
Date: Sat Mar 22 21:49:05 2008 +1100
[POWERPC] Fix Oops with TQM5200 on TQM5200
The "bestcomm-core" driver defines its of_match table as follows
static struct of_device_id mpc52xx_bcom_of_match[] = {
{ .type = "dma-controller", .compatible = "fsl,mpc5200-bestcomm", },
{ .type = "dma-controller", .compatible = "mpc5200-bestcomm", },
{},
};
so while registering the driver, the driver's probe function won't be
called, because the device tree node doesn't have a device_type
property. Thus the driver's bcom_engine structure won't be allocated.
Referencing this structure later causes observed Oops.
Checking bcom_eng pointer for NULL before referencing data pointed
by it prevents oopsing, but fec driver still doesn't work (because
of the lost bestcomm match and resulted task allocation failure).
Actually the compatible property exists and should match and so
the fec driver should work.
This removes .type = "dma-controller" from the bestcomm driver's
mpc52xx_bcom_of_match table to solve the problem.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 9560aea4e9d17cb75113c6051e800222fd5c71a4
Author: Grant Likely <grant.likely@secretlab.ca>
Date: Sat Mar 22 14:41:05 2008 +1100
[POWERPC] mpc5200: Fix null dereference if bestcomm fails to initialize
If the bestcomm initialization fails, calls to the task allocate
function should fail gracefully instead of oopsing with a NULL deref.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit b8c19eb16a7e6df57d0f6d67e42ce026e5d5930b
Author: Grant Likely <grant.likely@secretlab.ca>
Date: Sat Mar 22 14:20:29 2008 +1100
[POWERPC] mpc5200-fec: Fix possible NULL dereference in mdio driver
If the reg property is missing from the phy node (unlikely, but possible),
then the kernel will oops with a NULL pointer dereference. This fixes
it by checking the pointer first.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 1428a9fa586cb80acf98289f797f58b8bd662598
Author: Olaf Hering <olaf@aepfle.de>
Date: Tue Mar 18 06:53:05 2008 +1100
[POWERPC] Fix crash in init_ipic_sysfs on efika
The global primary_ipic in arch/powerpc/sysdev/ipic.c can remain NULL
if ipic_init() fails, which will happen on machines that don't have an
ipic interrupt controller. init_ipic_sysfs() will crash in that case.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit cfe666b145cecffe784d98e60ffe201a5dc57ac3
Author: Paul Mackerras <paulus@samba.org>
Date: Mon Mar 24 17:41:22 2008 +1100
[POWERPC] Don't use 64k pages for ioremap on pSeries
On pSeries, the hypervisor doesn't let us map in the eHEA ethernet
adapter using 64k pages, and thus the ehea driver will fail if 64k
pages are configured. This works around the problem by always
using 4k pages for ioremap on pSeries (but not on other platforms).
A better fix would be to check whether the partition could ever
have an eHEA adapter, and only force 4k pages if it could, but this
will do for 2.6.25.
This is based on an earlier patch by Tony Breeds.
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Paul Mackerras @ 2008-03-24 8:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <Pine.LNX.4.64.0803210418170.8073@blarg.am.freescale.net>
Kumar Gala writes:
> since you are going to send something to linus let me update the fsl
> defconfigs and send you a pull request.
OK -- I'm about to send Linus a pull request now in case he feels like
releasing 2.6.25 this weekend. I'll send him another pull request
with your defconfig update and whatever else has turned up when I get
your pull request.
Paul.
^ permalink raw reply
* Re: [PATCH 4/8] powerpc ptrace: forced_successful_syscall_return()
From: Paul Mackerras @ 2008-03-24 7:55 UTC (permalink / raw)
To: Roland McGrath
Cc: linux-arch, tony.luck, linux-ia64, linux-kernel, David Miller,
linuxppc-dev, Thomas Gleixner, sparclinux, Andrew Morton,
Linus Torvalds, Ingo Molnar, Richard Henderson
In-Reply-To: <20080319211936.28E8B26F9A7@magilla.localdomain>
Roland McGrath writes:
> Define the forced_successful_syscall_return() macro to
> pair with our force_successful_syscall_return() definition.
>
> Signed-off-by: Roland McGrath <roland@redhat.com>
Looks OK to me, but what's it useful for?
Paul.
^ permalink raw reply
* Re: [PATCH] [POWERPC] mpc5200: fix incorrect compatible string for the mdio node
From: Paul Mackerras @ 2008-03-24 7:24 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1206156315-4734-1-git-send-email-grant.likely@secretlab.ca>
Grant Likely writes:
> The MDIO node in the lite5200b.dts file needs to also claim compatibility
> with the older mpc5200 chip.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> Paul, this one should also go in for .26
OK, I'll put it in the powerpc-next branch. Or did you mean it should
go in .25?
Paul.
^ permalink raw reply
* Re: Oops with TQM5200 on TQM5200
From: Paul Mackerras @ 2008-03-24 6:47 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, Anatolij Gustschin
In-Reply-To: <47E3561B.6040505@grandegger.com>
Wolfgang Grandegger writes:
> Bartlomiej Sieka wrote:
> > Grant Likely wrote:
> >> Paul, my git server is down at the moment. Can you please pick this
> >> one up for .25? It is needed to boot the tqm5200 board.
> >
> > Could we also have similar fixes for cm5200.dts and motionpro.dts picked
> > up? I could provide the patches within a day -- will this be OK?
>
> At that occasion, could you please also add two CAN nodes to tqm5200.dts
> as shown:
Does this really need to go in for 2.6.25 -- i.e., does it fix a
regression or a serious bug (not just a missing feature)? If so,
please send it with a proper subject and patch description, with your
Signed-off-by.
Paul.
^ permalink raw reply
* RE: dcr stuff.
From: Stephen Neuendorffer @ 2008-03-24 4:34 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, git-dev
In-Reply-To: <20080321201704.032999c3@zod.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]
-----Original Message-----
From: Josh Boyer [mailto:jwboyer@linux.vnet.ibm.com]
Sent: Fri 3/21/2008 6:17 PM
To: Stephen Neuendorffer
Cc: linuxppc-dev@ozlabs.org; git-dev
Subject: Re: dcr stuff.
On Fri, 21 Mar 2008 12:05:40 -0700
"Stephen Neuendorffer" <stephen.neuendorffer@xilinx.com> wrote:
> > Is there a plan here? (In particular, in FPGA designs, its possible to
> > have crazy things like multiple independent dcr busses, some using
> > native access, some using mmio. Or even if there is one bus, many of
> > the existing non-linux drivers we have assume native or mmio access.
> > I'd like to clean this up, obviously.. :)
> Clean it up how? I'd hate to add bloat to boards with native DCR
> access just because a few require oddities.
>
> If it ain't broke, don't fix it.
>
> josh
Certainly, if it ain't broke don't fix it. What I'm really trying to do is figure out how to clean up alot of non-mainline drivers.
At the moment, several cores use DCR, but the drivers for those cores have internal code for DCR, their own ifdefs, etc. This *is* broken.
I'm looking at the available documentation to figure out the best way of approaching the problem.
It might be nice if there was an extra layer of indirection which was only enabled if DCR_NATIVE and DCR_MMIO, and which was no cost otherwise,
but the bigger problem I see in the short term is that we'll likely have to support ARCH ppc for at least some time into the future, and it would be
nice if we used the same driver code to do it: it doesn't seem obvious how to achieve this.
Steve
[-- Attachment #2: Type: text/html, Size: 2239 bytes --]
^ permalink raw reply
* dtc: Simplify error handling for unparseable input
From: David Gibson @ 2008-03-24 3:44 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Currently, main() tests if it got a valid input tree from whichever
dt_from_*() function it invoked and if not, die()s. For one thing,
this test has, for no good reason, three different ways for those
functions to communicate a failure to provide input (bi NULL, bi->dt
NULL, or bi->error non-zero). For another, in every case save one, if
the dt_from_*() functions are unable to provide input they will
immediately die() (with a more specific error message) rather than
proceeding to the test in main().
Therefore, this patch removes this test, making the one case that
could have triggered it (in dt_from_source()) call die() directly
instead. With this change, the error field in struct boot_info is now
unused, so remove it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
dtc.c | 3 ---
dtc.h | 1 -
livetree.c | 1 -
treesource.c | 6 ++++--
4 files changed, 4 insertions(+), 7 deletions(-)
Index: dtc/dtc.h
===================================================================
--- dtc.orig/dtc.h 2008-03-24 14:33:33.000000000 +1100
+++ dtc/dtc.h 2008-03-24 14:33:34.000000000 +1100
@@ -232,7 +232,6 @@
struct boot_info {
struct reserve_info *reservelist;
struct node *dt; /* the device tree */
- int error;
};
struct boot_info *build_boot_info(struct reserve_info *reservelist,
Index: dtc/livetree.c
===================================================================
--- dtc.orig/livetree.c 2008-03-24 14:18:44.000000000 +1100
+++ dtc/livetree.c 2008-03-24 14:33:34.000000000 +1100
@@ -172,7 +172,6 @@
bi = xmalloc(sizeof(*bi));
bi->reservelist = reservelist;
bi->dt = tree;
- bi->error = 0;
return bi;
}
Index: dtc/dtc.c
===================================================================
--- dtc.orig/dtc.c 2008-03-24 14:35:05.000000000 +1100
+++ dtc/dtc.c 2008-03-24 14:35:10.000000000 +1100
@@ -201,9 +201,6 @@
if (inf && inf->file != stdin)
fclose(inf->file);
- if (! bi || ! bi->dt || bi->error)
- die("Couldn't read input tree\n");
-
fill_fullpaths(bi->dt, "");
process_checks(force, bi);
Index: dtc/treesource.c
===================================================================
--- dtc.orig/treesource.c 2008-03-24 14:33:44.000000000 +1100
+++ dtc/treesource.c 2008-03-24 14:35:52.000000000 +1100
@@ -36,9 +36,11 @@
yyin = srcpos_file->file;
if (yyparse() != 0)
- return NULL;
+ die("Unable to parse input tree\n");
+
+ if (treesource_error)
+ die("Syntax error parsing input tree\n");
- the_boot_info->error = treesource_error;
return the_boot_info;
}
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* dtc: Clean up included Makefile fragments
From: David Gibson @ 2008-03-24 2:24 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Currently the Makefile.dtc and Makefile.libfdt fragments include a
number of things that seemed like they might be useful for other
projects embedding the pieces, or for a make dist target.
Well, we have no make dist target, it's become fairly unclear that
these things would actually be useful to embedders (the kernel
certainly doesn't use them), and it's a bunch of stuff with no current
users.
This patch, therefore, removes a bunch of unused definitions from the
Makefile fragments. It also removes a dependency declared in
Makefile.libfdt (of libfdt.a on the constituent .o files) which was
incorrect (wrong path), and if corrected would be redundant with the
similar dependency in the top-level makefile.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Makefile | 7 ++++---
Makefile.dtc | 18 +-----------------
libfdt/Makefile.libfdt | 7 -------
tests/Makefile.tests | 4 ++--
4 files changed, 7 insertions(+), 29 deletions(-)
Index: dtc/Makefile.dtc
===================================================================
--- dtc.orig/Makefile.dtc 2008-03-24 13:16:17.000000000 +1100
+++ dtc/Makefile.dtc 2008-03-24 13:24:06.000000000 +1100
@@ -5,21 +5,5 @@
#
DTC_SRCS = dtc.c flattree.c fstree.c data.c livetree.c treesource.c srcpos.c \
checks.c
-DTC_EXTRA = dtc.h srcpos.h
-DTC_LEXFILES = dtc-lexer.l
-DTC_BISONFILES = dtc-parser.y
-
-DTC_LEX_SRCS = $(DTC_LEXFILES:%.l=%.lex.c)
-DTC_BISON_SRCS = $(DTC_BISONFILES:%.y=%.tab.c)
-DTC_BISON_INCLUDES = $(DTC_BISONFILES:%.y=%.tab.h)
-
-DTC_GEN_SRCS = $(DTC_LEX_SRCS) $(DTC_BISON_SRCS)
-DTC_GEN_ALL = $(DTC_GEN_SRCS) $(DTC_BISON_INCLUDES)
+DTC_GEN_SRCS = dtc-lexer.lex.c dtc-parser.tab.c
DTC_OBJS = $(DTC_SRCS:%.c=%.o) $(DTC_GEN_SRCS:%.c=%.o)
-
-DTC_CLEANFILES = $(DTC_GEN_ALL)
-
-# We assume the containing Makefile system can do auto-dependencies for most
-# things, but we supply the dependencies on generated header files explicitly
-
-$(addprefix $(DTC_objdir)/,$(DTC_GEN_SRCS:%.c=%.o)): $(addprefix $(DTC_objdir)/,$(DTC_BISON_INCLUDES))
Index: dtc/Makefile
===================================================================
--- dtc.orig/Makefile 2008-03-24 13:16:17.000000000 +1100
+++ dtc/Makefile 2008-03-24 13:17:58.000000000 +1100
@@ -53,7 +53,7 @@
$(INSTALL) -d $(DESTDIR)$(BINDIR)
$(INSTALL) -m 755 dtc $(DESTDIR)$(BINDIR)
$(INSTALL) -d $(DESTDIR)$(LIBDIR)
- $(INSTALL) -m 644 $(LIBFDT_LIB) $(DESTDIR)$(LIBDIR)
+ $(INSTALL) -m 644 $(LIBFDT_lib) $(DESTDIR)$(LIBDIR)
$(INSTALL) -d $(DESTDIR)$(INCLUDEDIR)
$(INSTALL) -m 644 $(addprefix $(LIBFDT_srcdir)/,$(LIBFDT_INCLUDES)) $(DESTDIR)$(INCLUDEDIR)
@@ -135,12 +135,13 @@
#
LIBFDT_objdir = libfdt
LIBFDT_srcdir = libfdt
+LIBFDT_lib = $(LIBFDT_objdir)/libfdt.a
include $(LIBFDT_srcdir)/Makefile.libfdt
.PHONY: libfdt
-libfdt: $(LIBFDT_LIB)
+libfdt: $(LIBFDT_lib)
-$(LIBFDT_LIB): $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_OBJS))
+$(LIBFDT_lib): $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_OBJS))
libfdt_clean:
@$(VECHO) CLEAN "(libfdt)"
Index: dtc/libfdt/Makefile.libfdt
===================================================================
--- dtc.orig/libfdt/Makefile.libfdt 2008-03-24 13:16:17.000000000 +1100
+++ dtc/libfdt/Makefile.libfdt 2008-03-24 13:17:58.000000000 +1100
@@ -4,11 +4,4 @@
# be easily embeddable into other systems of Makefiles.
#
LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c
-LIBFDT_INCLUDES = fdt.h libfdt.h
-LIBFDT_EXTRA = libfdt_internal.h
-LIBFDT_LIB = libfdt/libfdt.a
-
LIBFDT_OBJS = $(LIBFDT_SRCS:%.c=%.o)
-
-$(LIBFDT_objdir)/$(LIBFDT_LIB): $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_OBJS))
-
Index: dtc/tests/Makefile.tests
===================================================================
--- dtc.orig/tests/Makefile.tests 2008-03-24 13:16:17.000000000 +1100
+++ dtc/tests/Makefile.tests 2008-03-24 13:17:58.000000000 +1100
@@ -35,9 +35,9 @@
.PHONY: tests
tests: $(TESTS) $(TESTS_TREES)
-$(LIB_TESTS): %: $(TESTS_PREFIX)testutils.o $(LIBFDT_LIB)
+$(LIB_TESTS): %: $(TESTS_PREFIX)testutils.o $(LIBFDT_lib)
-$(LIBTREE_TESTS): %: $(TESTS_PREFIX)testutils.o $(TESTS_PREFIX)trees.o $(LIBFDT_LIB)
+$(LIBTREE_TESTS): %: $(TESTS_PREFIX)testutils.o $(TESTS_PREFIX)trees.o $(LIBFDT_lib)
$(TESTS_PREFIX)dumptrees: $(TESTS_PREFIX)trees.o
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: DTC Patch Catch Up
From: David Gibson @ 2008-03-24 0:43 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1JdPvk-0005mf-2k@jdl.com>
On Sun, Mar 23, 2008 at 08:08:08AM -0500, Jon Loeliger wrote:
> Folks,
>
> I've applied the following patches from Gibson,
> in this order, to the DTC and pushed it out
> to git.jdl.com:
>
> dtc: Fix error reporting in push_input_file()
> dtc: Implement checks for the format of node and property names
> dtc: Fix indentation of fixup_phandle_references
> dtc: Strip redundant "name" properties
> dtc: Test and fix conversion to/from old dtb versions
> dtc: Use for_each_marker_of_type in asm_emit_data()
> dtc: Make -I dtb mode use fill_fullpaths()
> dtc: Make eval_literal() static
> dtc: Assorted improvements to test harness
> dtc: Testcases for input handling
> dtc: Make dtc_open_file() die() if unable to open requested file
> dtc: Remove ugly include stack abuse
> dtc: Abolish asize field of struct data
> dtc: Add some documentation for the dts formta
> dtc: Cleanup \nnn and \xNN string escape handling
> dtc: Change exit code for usage message
Hurrah :)
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] scanlog_init cleanup, minor fixes
From: Nathan Lynch @ 2008-03-23 22:51 UTC (permalink / raw)
To: linuxppc-dev
scanlog_init() could use some love.
* properly return -ENODEV if this system doesn't support scan-log-dump
* don't printk if scan-log-dump not present; only older systems have it
* convert from create_proc_entry() to preferred proc_create()
* allocate zeroed data buffer
* fix potential memory leak of ent->data on failed create_proc_entry()
* simplify control flow
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
(not urgent, please consider for 2.6.26)
arch/powerpc/platforms/pseries/scanlog.c | 37 ++++++++++++++---------------
1 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/scanlog.c b/arch/powerpc/platforms/pseries/scanlog.c
index 8e1ef16..e5b0ea8 100644
--- a/arch/powerpc/platforms/pseries/scanlog.c
+++ b/arch/powerpc/platforms/pseries/scanlog.c
@@ -195,31 +195,30 @@ const struct file_operations scanlog_fops = {
static int __init scanlog_init(void)
{
struct proc_dir_entry *ent;
+ void *data;
+ int err = -ENOMEM;
ibm_scan_log_dump = rtas_token("ibm,scan-log-dump");
- if (ibm_scan_log_dump == RTAS_UNKNOWN_SERVICE) {
- printk(KERN_ERR "scan-log-dump not implemented on this system\n");
- return -EIO;
- }
+ if (ibm_scan_log_dump == RTAS_UNKNOWN_SERVICE)
+ return -ENODEV;
- ent = create_proc_entry("ppc64/rtas/scan-log-dump", S_IRUSR, NULL);
- if (ent) {
- ent->proc_fops = &scanlog_fops;
- /* Ideally we could allocate a buffer < 4G */
- ent->data = kmalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
- if (!ent->data) {
- printk(KERN_ERR "Failed to allocate a buffer\n");
- remove_proc_entry("scan-log-dump", ent->parent);
- return -ENOMEM;
- }
- ((unsigned int *)ent->data)[0] = 0;
- } else {
- printk(KERN_ERR "Failed to create ppc64/scan-log-dump proc entry\n");
- return -EIO;
- }
+ /* Ideally we could allocate a buffer < 4G */
+ data = kzalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
+ if (!data)
+ goto err;
+
+ ent = proc_create("ppc64/rtas/scan-log-dump", S_IRUSR, NULL,
+ &scanlog_fops);
+ if (!ent)
+ goto err;
+
+ ent->data = data;
proc_ppc64_scan_log_dump = ent;
return 0;
+err:
+ kfree(data);
+ return err;
}
static void __exit scanlog_cleanup(void)
--
1.5.4.rc5
^ permalink raw reply related
* DTC Patch Catch Up
From: Jon Loeliger @ 2008-03-23 13:08 UTC (permalink / raw)
To: linuxppc-dev
Folks,
I've applied the following patches from Gibson,
in this order, to the DTC and pushed it out
to git.jdl.com:
dtc: Fix error reporting in push_input_file()
dtc: Implement checks for the format of node and property names
dtc: Fix indentation of fixup_phandle_references
dtc: Strip redundant "name" properties
dtc: Test and fix conversion to/from old dtb versions
dtc: Use for_each_marker_of_type in asm_emit_data()
dtc: Make -I dtb mode use fill_fullpaths()
dtc: Make eval_literal() static
dtc: Assorted improvements to test harness
dtc: Testcases for input handling
dtc: Make dtc_open_file() die() if unable to open requested file
dtc: Remove ugly include stack abuse
dtc: Abolish asize field of struct data
dtc: Add some documentation for the dts formta
dtc: Cleanup \nnn and \xNN string escape handling
dtc: Change exit code for usage message
Thanks,
jdl
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Sven Luther @ 2008-03-23 10:24 UTC (permalink / raw)
To: David Woodhouse; +Cc: Sven Luther, Olaf Hering, Paul Mackerras, linuxppc-dev
In-Reply-To: <1206267193.9540.137.camel@pmac.infradead.org>
On Sun, Mar 23, 2008 at 10:13:12AM +0000, David Woodhouse wrote:
> On Sun, 2008-03-23 at 11:12 +0100, Sven Luther wrote:
> > On Sun, Mar 23, 2008 at 09:00:41AM +0000, David Woodhouse wrote:
> > > On Sat, 2008-03-22 at 16:25 +0100, Sven Luther wrote:
> > > > BTW, it was reported to me that the ethernet drivers don't get
> > > > autoloaded by udev. Is this a failure of udev missing the of_plateform
> > > > support, or a deficiency of the ethernet drivers ?
> > >
> > > As far as I know, they _are_ being loaded properly. Otherwise, the
> > > Fedora installer wouldn't work.
> >
> > Yes, but you probably have the of_plateform udev patch, no ?
>
> Not any more. That was merged a while ago, wasn't it?
So, the only explanation would be if debian had a very outdated udev
which does not include this patch.
Friendly,
Sven Luther
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: David Woodhouse @ 2008-03-23 10:13 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, Olaf Hering, Paul Mackerras
In-Reply-To: <20080323101215.GA26361@powerlinux.fr>
On Sun, 2008-03-23 at 11:12 +0100, Sven Luther wrote:
> On Sun, Mar 23, 2008 at 09:00:41AM +0000, David Woodhouse wrote:
> > On Sat, 2008-03-22 at 16:25 +0100, Sven Luther wrote:
> > > BTW, it was reported to me that the ethernet drivers don't get
> > > autoloaded by udev. Is this a failure of udev missing the of_plateform
> > > support, or a deficiency of the ethernet drivers ?
> >
> > As far as I know, they _are_ being loaded properly. Otherwise, the
> > Fedora installer wouldn't work.
>
> Yes, but you probably have the of_plateform udev patch, no ?
Not any more. That was merged a while ago, wasn't it?
--
dwmw2
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Sven Luther @ 2008-03-23 10:12 UTC (permalink / raw)
To: David Woodhouse; +Cc: Sven Luther, Olaf Hering, Paul Mackerras, linuxppc-dev
In-Reply-To: <1206262841.9540.119.camel@pmac.infradead.org>
On Sun, Mar 23, 2008 at 09:00:41AM +0000, David Woodhouse wrote:
> On Sat, 2008-03-22 at 16:25 +0100, Sven Luther wrote:
> > BTW, it was reported to me that the ethernet drivers don't get
> > autoloaded by udev. Is this a failure of udev missing the of_plateform
> > support, or a deficiency of the ethernet drivers ?
>
> As far as I know, they _are_ being loaded properly. Otherwise, the
> Fedora installer wouldn't work.
Yes, but you probably have the of_plateform udev patch, no ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: David Woodhouse @ 2008-03-23 9:00 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, Olaf Hering, Paul Mackerras
In-Reply-To: <20080322152528.GA6272@powerlinux.fr>
On Sat, 2008-03-22 at 16:25 +0100, Sven Luther wrote:
> BTW, it was reported to me that the ethernet drivers don't get
> autoloaded by udev. Is this a failure of udev missing the of_plateform
> support, or a deficiency of the ethernet drivers ?
As far as I know, they _are_ being loaded properly. Otherwise, the
Fedora installer wouldn't work.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: Stephen Rothwell @ 2008-03-23 5:38 UTC (permalink / raw)
To: David Woodhouse; +Cc: Étienne Bersac, linuxppc-dev
In-Reply-To: <1206228673.9540.115.camel@pmac.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
Hi Dave,
On Sat, 22 Mar 2008 23:31:13 +0000 David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Sun, 2008-03-23 at 10:25 +1100, Stephen Rothwell wrote:
> > Why would you expect otherwise (from the C standard):
> >
> > "Unlike the bitwise binary & operator, the && operator guarantees
> > left-to-right evaluation; there is a sequence point after the evaluation
> > of the first operand. If the first operand compares equal to 0, the
> > second operand is not evaluated."
>
> Because it's Saturday night
That seems like all the explanation necessary :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: Andreas Schwab @ 2008-03-23 1:01 UTC (permalink / raw)
To: David Woodhouse; +Cc: Étienne Bersac, Stephen Rothwell, linuxppc-dev
In-Reply-To: <1206228673.9540.115.camel@pmac.infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> - all = all && pm121_register_control(ct, "optical-driver-fan", FAN_OD);
> - all = all && pm121_register_control(ct, "hard-driver-fan", FAN_HD);
> - all = all && pm121_register_control(ct, "cpu-driver-fan", FAN_CPU);
> - all = all && pm121_register_control(ct, "cpufreq-clamp", CPUFREQ);
> + all = pm121_register_control(ct, "optical-drive-fan", FAN_OD) && all;
> + all = pm121_register_control(ct, "hard-drive-fan", FAN_HD) && all;
> + all = pm121_register_control(ct, "cpu-fan", FAN_CPU) && all;
> + all = pm121_register_control(ct, "cpufreq-clamp", CPUFREQ) && all;
You can also write all &= ... if pm121_register_control always return
0/1 (or make it 0/1 with !!).
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: David Woodhouse @ 2008-03-22 23:31 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Étienne Bersac, linuxppc-dev
In-Reply-To: <20080323102502.e0754062.sfr@canb.auug.org.au>
On Sun, 2008-03-23 at 10:25 +1100, Stephen Rothwell wrote:
> Why would you expect otherwise (from the C standard):
>
> "Unlike the bitwise binary & operator, the && operator guarantees
> left-to-right evaluation; there is a sequence point after the evaluation
> of the first operand. If the first operand compares equal to 0, the
> second operand is not evaluated."
Because it's Saturday night, I wasn't expecting that construct there
(because it seems to require that the sensors/controls are detected in
the precise order that they're checked for, otherwise it'll never match
the ones which are found out of order), and mostly because I'm stupid.
This seems to fix it (note the change of the control names too):
--- drivers/macintosh/windfarm_pm121.c~ 2008-03-22 19:13:22.000000000 +0000
+++ drivers/macintosh/windfarm_pm121.c 2008-03-22 23:23:44.000000000 +0000
@@ -867,7 +867,7 @@ static struct wf_control* pm121_register
{
if (controls[id] == NULL && !strcmp(ct->name, match)) {
if (wf_get_control(ct) == 0)
- controls[FAN_OD] = ct;
+ controls[id] = ct;
}
return controls[id];
}
@@ -879,10 +879,10 @@ static void pm121_new_control(struct wf_
if (pm121_all_controls_ok)
return;
- all = all && pm121_register_control(ct, "optical-driver-fan", FAN_OD);
- all = all && pm121_register_control(ct, "hard-driver-fan", FAN_HD);
- all = all && pm121_register_control(ct, "cpu-driver-fan", FAN_CPU);
- all = all && pm121_register_control(ct, "cpufreq-clamp", CPUFREQ);
+ all = pm121_register_control(ct, "optical-drive-fan", FAN_OD) && all;
+ all = pm121_register_control(ct, "hard-drive-fan", FAN_HD) && all;
+ all = pm121_register_control(ct, "cpu-fan", FAN_CPU) && all;
+ all = pm121_register_control(ct, "cpufreq-clamp", CPUFREQ) && all;
if (all)
pm121_all_controls_ok = 1;
@@ -909,24 +909,24 @@ static void pm121_new_sensor(struct wf_s
if (pm121_all_sensors_ok)
return;
- all = all && pm121_register_sensor(sr, "cpu-temp",
- &sensor_cpu_temp);
- all = all && pm121_register_sensor(sr, "cpu-current",
- &sensor_cpu_current);
- all = all && pm121_register_sensor(sr, "cpu-voltage",
- &sensor_cpu_voltage);
- all = all && pm121_register_sensor(sr, "cpu-power",
- &sensor_cpu_power);
- all = all && pm121_register_sensor(sr, "hard-drive-temp",
- &sensor_hard_drive_temp);
- all = all && pm121_register_sensor(sr, "optical-drive-temp",
- &sensor_optical_drive_temp);
- all = all && pm121_register_sensor(sr, "incoming-air-temp",
- &sensor_incoming_air_temp);
- all = all && pm121_register_sensor(sr, "north-bridge-temp",
- &sensor_north_bridge_temp);
- all = all && pm121_register_sensor(sr, "gpu-temp",
- &sensor_gpu_temp);
+ all = pm121_register_sensor(sr, "cpu-temp",
+ &sensor_cpu_temp) && all;
+ all = pm121_register_sensor(sr, "cpu-current",
+ &sensor_cpu_current) && all;
+ all = pm121_register_sensor(sr, "cpu-voltage",
+ &sensor_cpu_voltage) && all;
+ all = pm121_register_sensor(sr, "cpu-power",
+ &sensor_cpu_power) && all;
+ all = pm121_register_sensor(sr, "hard-drive-temp",
+ &sensor_hard_drive_temp) && all;
+ all = pm121_register_sensor(sr, "optical-drive-temp",
+ &sensor_optical_drive_temp) && all;
+ all = pm121_register_sensor(sr, "incoming-air-temp",
+ &sensor_incoming_air_temp) && all;
+ all = pm121_register_sensor(sr, "north-bridge-temp",
+ &sensor_north_bridge_temp) && all;
+ all = pm121_register_sensor(sr, "gpu-temp",
+ &sensor_gpu_temp) && all;
if (all)
pm121_all_sensors_ok = 1;
--
dwmw2
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: Stephen Rothwell @ 2008-03-22 23:25 UTC (permalink / raw)
To: David Woodhouse; +Cc: Étienne Bersac, linuxppc-dev
In-Reply-To: <1206226966.9540.104.camel@pmac.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]
On Sat, 22 Mar 2008 23:02:46 +0000 David Woodhouse <dwmw2@infradead.org> wrote:
>
> Yeah, there's weird shit going on with the sensor/control registration.
> I think GCC is be miscompiling it -- the sequence of
> all = all && pm121_register_control(foo...);
> all = all && pm121_register_control(bar...);
> is bailing out as soon as 'all' gets set to zero. Despite the fact that
> pm121_register_control() quite blatantly has side-effects.
Why would you expect otherwise (from the C standard):
"Unlike the bitwise binary & operator, the && operator guarantees
left-to-right evaluation; there is a sequence point after the evaluation
of the first operand. If the first operand compares equal to 0, the
second operand is not evaluated."
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: Benjamin Herrenschmidt @ 2008-03-22 23:25 UTC (permalink / raw)
To: David Woodhouse; +Cc: Étienne Bersac, linuxppc-dev
In-Reply-To: <1206227641.9540.108.camel@pmac.infradead.org>
On Sat, 2008-03-22 at 23:14 +0000, David Woodhouse wrote:
> On Sat, 2008-03-22 at 23:02 +0000, David Woodhouse wrote:
> >
> > Yeah, there's weird shit going on with the sensor/control
> > registration.
> > I think GCC is be miscompiling it -- the sequence of
> > all = all && pm121_register_control(foo...);
> > all = all && pm121_register_control(bar...);
> > is bailing out as soon as 'all' gets set to zero. Despite the fact
> > that pm121_register_control() quite blatantly has side-effects.
And it's just supposed to do that no ?
Ben.
> That's after I fix the names in pm121_new_control() and fix
> pm121_register_control() to set controls[id] instead of always setting
> controls[FAN_OD], btw. Without that I don't think it could ever have
> worked.
>
> But it's still broken. I'll try to cut it down and file a GCC bug...
>
> .pm121_new_control:
> .LFB929:
> .loc 1 883 0
> .LVL44:
> mflr 0
> .LCFI38:
> std 0,16(1)
> .LCFI39:
> std 30,-16(1)
> .LCFI40:
> std 31,-8(1)
> .LCFI41:
> stdu 1,-128(1)
> .LCFI42:
> ld 30,.LCTOC0@toc(2)
> mr 31,3
> .loc 1 886 0
> ld 9,.LC47-.LCTOC1(30)
> lwz 0,48(9)
> cmpwi 7,0,0
> bne 7,.L31
> .LVL45:
> .loc 1 889 0
> ld 4,.LC49-.LCTOC1(30)
> li 5,2
> bl .pm121_register_control
> cmpdi 7,3,0
> beq 7,.L31
> .loc 1 890 0
> mr 3,31
> ld 4,.LC51-.LCTOC1(30)
> li 5,1
> bl .pm121_register_control
> cmpdi 7,3,0
> beq 7,.L31
> .loc 1 891 0
> mr 3,31
> ld 4,.LC53-.LCTOC1(30)
> li 5,0
> bl .pm121_register_control
> cmpdi 7,3,0
> beq 7,.L31
> .loc 1 892 0
> mr 3,31
> ld 4,.LC55-.LCTOC1(30)
> li 5,3
> bl .pm121_register_control
> cmpdi 7,3,0
> beq 7,.L31
> .loc 1 895 0
> ld 3,.LC57-.LCTOC1(30)
> bl .printk
> nop
> .loc 1 896 0
> ld 9,.LC47-.LCTOC1(30)
> li 0,1
> stw 0,48(9)
> .LVL46:
> .L31:
> .loc 1 898 0
> addi 1,1,128
> ld 0,16(1)
> mtlr 0
> ld 30,-16(1)
> ld 31,-8(1)
> .LVL47:
> blr
>
>
>
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: David Woodhouse @ 2008-03-22 23:14 UTC (permalink / raw)
To: benh; +Cc: Étienne Bersac, linuxppc-dev
In-Reply-To: <1206226966.9540.104.camel@pmac.infradead.org>
On Sat, 2008-03-22 at 23:02 +0000, David Woodhouse wrote:
>
> Yeah, there's weird shit going on with the sensor/control
> registration.
> I think GCC is be miscompiling it -- the sequence of
> all = all && pm121_register_control(foo...);
> all = all && pm121_register_control(bar...);
> is bailing out as soon as 'all' gets set to zero. Despite the fact
> that pm121_register_control() quite blatantly has side-effects.
That's after I fix the names in pm121_new_control() and fix
pm121_register_control() to set controls[id] instead of always setting
controls[FAN_OD], btw. Without that I don't think it could ever have
worked.
But it's still broken. I'll try to cut it down and file a GCC bug...
.pm121_new_control:
.LFB929:
.loc 1 883 0
.LVL44:
mflr 0
.LCFI38:
std 0,16(1)
.LCFI39:
std 30,-16(1)
.LCFI40:
std 31,-8(1)
.LCFI41:
stdu 1,-128(1)
.LCFI42:
ld 30,.LCTOC0@toc(2)
mr 31,3
.loc 1 886 0
ld 9,.LC47-.LCTOC1(30)
lwz 0,48(9)
cmpwi 7,0,0
bne 7,.L31
.LVL45:
.loc 1 889 0
ld 4,.LC49-.LCTOC1(30)
li 5,2
bl .pm121_register_control
cmpdi 7,3,0
beq 7,.L31
.loc 1 890 0
mr 3,31
ld 4,.LC51-.LCTOC1(30)
li 5,1
bl .pm121_register_control
cmpdi 7,3,0
beq 7,.L31
.loc 1 891 0
mr 3,31
ld 4,.LC53-.LCTOC1(30)
li 5,0
bl .pm121_register_control
cmpdi 7,3,0
beq 7,.L31
.loc 1 892 0
mr 3,31
ld 4,.LC55-.LCTOC1(30)
li 5,3
bl .pm121_register_control
cmpdi 7,3,0
beq 7,.L31
.loc 1 895 0
ld 3,.LC57-.LCTOC1(30)
bl .printk
nop
.loc 1 896 0
ld 9,.LC47-.LCTOC1(30)
li 0,1
stw 0,48(9)
.LVL46:
.L31:
.loc 1 898 0
addi 1,1,128
ld 0,16(1)
mtlr 0
ld 30,-16(1)
ld 31,-8(1)
.LVL47:
blr
--
dwmw2
^ 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