* RE: fs_enet - support for SCC on CPM2?
From: Pelton, Dave @ 2006-09-26 15:22 UTC (permalink / raw)
To: Matt Hevern; +Cc: Linuxppc-embedded
> -----Original Message-----
> From: Matt Hevern
<snip>
>=20
> I am trying to compile for an freescale 82xx (CPM2) series=20
> processor, with ethernet on an SCC. (kernel 2.6.x) From what=20
> i can see, in the file drivers/net/fs_enet/fs_enet-main.c,
> the config option "CONFIG_FS_ENET_HAS_SCC" pulls in=20
> "fs_scc_ops" which are defined in=20
> drivers/net/fs_enet/mac-scc.c, but this file does not seem=20
> to have support for 82xx series, failing with various compile errors:
<snip>
> It seems like these errors are mostly due to the driver being tailored
for 8xx series.
<snip>
I had the same problem trying to use fs_enet for 82xx SCC Ethernet and
came to the same conclusion. The FCC could not be used instead of the
SCC because of pin limitations in the hardware design. I ended up using
the "old" SCC Ethernet driver by disabling CONFIG_FS_ENET_HAS_SCC and
enabling CONFIG_SCC_ENET (Under CPM2 options in kernel config). This
does not use the new platform bus structure, and arch/ppc/8260_io/enet.c
may require some board specific tweaks, but it does work.
- David Pelton.
^ permalink raw reply
* TFTP timeouts with EmbeddedPlanet 405 board
From: Josh Boyer @ 2006-09-26 15:26 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I've recently inherited an EmbeddedPlanet 405 Iceplanet eval board and
I'm having trouble getting the bootloader to tftp a kernel. Basically,
pings work, the file appears to be getting correctly served, however the
tftp transfer always times out.
Has anyone else seen this?
josh
^ permalink raw reply
* Re: [PATCH] Lazy interrupt disabling for 64-bit machines
From: Olof Johansson @ 2006-09-26 15:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1159261926.5462.54.camel@localhost.localdomain>
On Tue, 26 Sep 2006 19:12:06 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > I like it. Got any benchmarks that show a difference?
> >
> > At first glance I found it a bit hard to follow, since the old+new
> > terminology is a bit complicated. There's softe, proc_enabled and
> > hard_enabled. A s/proc_enabled/soft_enabled/g (and similar for
> > asm-offsets) might make it a little more intuitive, since you're
> > touching most uses of it already?
>
> Now think about using -ffixed=crN ... reserve a CR field and use that
> for per-cpu flags like that :)
You can also get away from doing the mfspr(SPRN_DEC) in
local_irq_enable() by changing the polarity of hard_enabled to
hard_disabled, and have different values for why it was disabled. Saves
an mfspr which can be costly, but adds one instruction (li (n>>8) or
so) in the exception entry path. Not which way that tradeoff will
swing, without benchmarking to show benefit it's just added complexity.
That can be done with a fixed cr too, it just uses two bits instead of
one. There are fewer to take from there though.
-Olof
^ permalink raw reply
* RE: Unable to boot linux on Xilinx ML403 board
From: Mohan Krishna T @ 2006-09-26 15:44 UTC (permalink / raw)
To: 'Grant Likely'; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0609260638t16dae54ct266548030e21ffd1@mail.gmail.com>
The zImage.initrd.elf is of size 3.4MB. I am getting hanged only when I am
using DMA for Ethernet. Booting is going fine when I am using FIFO Mode.
Thanks
Mohan Krishna
-----Original Message-----
From: glikely=40gmail.com =5Bmailto:glikely=40gmail.com=5D On Behalf Of =
Grant Likely
Sent: Tuesday, September 26, 2006 7:09 PM
To: Mohan Krishna T
Cc: Peter Ryser; linuxppc-embedded=40ozlabs.org
Subject: Re: Unable to boot linux on Xilinx ML403 board
On 9/26/06, Mohan Krishna T <tmk=40cmcltd.com> wrote:
> I have tried the option you have suggested but couldn't boot successfully.
I
> tried to debug where exactly the kernel is getting hanged. I could found
> that its hanging in gunzip() function call. It is never coming out of loop
> that decompress the ramdisk image.
How large is you zImage.embedded?
--=20
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely=40secretlab.ca
(403) 399-0195
DISCLAIMER
=E2=80=9CThe information contained in this e-mail message and/or =
attachments to it may contain confidential or privileged information. If =
you are not the intended recipient, any dissemination, use, review, =
distribution, printing or copying of the information contained in this =
e-mail message and/or attachments to it are strictly prohibited. If you =
have received this communication in error, please notify us by reply =
e-mail or telephone and immediately and permanently delete the message and =
any attachments. Thank you=22=
^ permalink raw reply
* Re: Unable to boot linux on Xilinx ML403 board
From: Grant Likely @ 2006-09-26 15:56 UTC (permalink / raw)
To: Mohan Krishna T; +Cc: linuxppc-embedded
In-Reply-To: <7225230023970127285@unknownmsgid>
On 9/26/06, Mohan Krishna T <tmk@cmcltd.com> wrote:
> The zImage.initrd.elf is of size 3.4MB. I am getting hanged only when I am
> using DMA for Ethernet. Booting is going fine when I am using FIFO Mode.
You may be hitting the 4MB upper limit for zImages. I had the same
problem with slightly smaller images, and it would hang at (seemingly)
random places everytime I changed something. Making the image smaller
made the problem go away.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: Unable to boot linux on Xilinx ML403 board
From: Mohan Krishna T @ 2006-09-26 15:58 UTC (permalink / raw)
To: 'Grant Likely'; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0609260856y69339eb2nb237e53efc2d6de5@mail.gmail.com>
I am using the same image for FIFO mode. It is booting without any problem.
The problem is only coming in DMA mode. Is there any restriction on size if
it is DMA mode? Or should I tale any extra care of RAMDISK if I am in DMA
mode?
Thanks and Regards
Mohan Krishna T
-----Original Message-----
From: glikely=40gmail.com =5Bmailto:glikely=40gmail.com=5D On Behalf Of =
Grant Likely
Sent: Tuesday, September 26, 2006 9:26 PM
To: Mohan Krishna T
Cc: Peter Ryser; linuxppc-embedded=40ozlabs.org
Subject: Re: Unable to boot linux on Xilinx ML403 board
On 9/26/06, Mohan Krishna T <tmk=40cmcltd.com> wrote:
> The zImage.initrd.elf is of size 3.4MB. I am getting hanged only when I am
> using DMA for Ethernet. Booting is going fine when I am using FIFO Mode.
You may be hitting the 4MB upper limit for zImages. I had the same
problem with slightly smaller images, and it would hang at (seemingly)
random places everytime I changed something. Making the image smaller
made the problem go away.
--=20
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely=40secretlab.ca
(403) 399-0195
DISCLAIMER
=E2=80=9CThe information contained in this e-mail message and/or =
attachments to it may contain confidential or privileged information. If =
you are not the intended recipient, any dissemination, use, review, =
distribution, printing or copying of the information contained in this =
e-mail message and/or attachments to it are strictly prohibited. If you =
have received this communication in error, please notify us by reply =
e-mail or telephone and immediately and permanently delete the message and =
any attachments. Thank you=22=
^ permalink raw reply
* Re: local_irq_save not masking interrupts
From: Scott Wood @ 2006-09-26 16:02 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: Liu Dave-r63238, linuxppc-embedded
In-Reply-To: <451900B0.7010006@cambridgebroadband.com>
Alex Zeffertt wrote:
> Well, mpc832xemds_phy_interrupt_enable() does nothing except call
> request_irq(,,SA_SHIRQ,,). I suspect that request_irq() is somehow
> reenabling interrupts, but I can't see where it might be doing so.
One possibile way (in 2.6.18; I'm assuming 2.6.11 is similar) is that
request_irq() calls setup_irq(), which calls register_irq_proc() and
register_handler_proc(), both of which call proc_mkdir(), which
eventually calls proc_create(), which calls kmalloc() with GFP_KERNEL.
This is probably a bug, since request_irq itself uses GFP_ATOMIC,
indicating an intent for request_irq() to be safely callable in atomic
context.
Can you disable the interrupts at the device level until the handler is
in place, and thus avoid the need to disable IRQs at all?
-Scott
^ permalink raw reply
* Re: local_irq_save not masking interrupts
From: Alex Zeffertt @ 2006-09-26 16:17 UTC (permalink / raw)
To: Scott Wood, linuxppc-embedded
In-Reply-To: <45194F1F.7030003@freescale.com>
Hi Scott,
Thanks for your reply. Comments below.
Scott Wood wrote:
> Alex Zeffertt wrote:
>> Well, mpc832xemds_phy_interrupt_enable() does nothing except call
>> request_irq(,,SA_SHIRQ,,). I suspect that request_irq() is somehow
>> reenabling interrupts, but I can't see where it might be doing so.
>
> One possibile way (in 2.6.18; I'm assuming 2.6.11 is similar) is that
> request_irq() calls setup_irq(), which calls register_irq_proc() and
> register_handler_proc(), both of which call proc_mkdir(), which
> eventually calls proc_create(), which calls kmalloc() with GFP_KERNEL.
> This is probably a bug, since request_irq itself uses GFP_ATOMIC,
> indicating an intent for request_irq() to be safely callable in atomic
> context.
>
I agree this indicates an intent to make it atomic, but I don't see how
this could cause interrupts to become re-enabled during the request_irq()
call. Also, since I am calling request_irq at insmod time, i.e. in process
context, both GFP_ flags *should* work.
> Can you disable the interrupts at the device level until the handler is
> in place, and thus avoid the need to disable IRQs at all?
>
> -Scott
Yup, I've come to the same conclusion. I now, for each shared interrupt:
* initialise all the devices which share the interrupt, turning interrupt generation off
* register all handlers for each device which shares the interrupt
* turn interrupt generation back on for each device.
This avoids the original problem, but it does not explain it. I still
can't see how I can get an interrupt on line 3 below:
1. local_irq_save(flags);
2. request_irq(MPC83xx_IRQ_EXT6, handler, SA_SHIRQ, "name", dev1);
3.
4. request_irq(MPC83xx_IRQ_EXT6, handler, SA_SHIRQ, "name", dev2);
5 local_irq_restore(flags);
Regards,
Alex
^ permalink raw reply
* Re: DLPAR fails on SLES9
From: jschopp @ 2006-09-26 16:24 UTC (permalink / raw)
To: ingvar; +Cc: linuxppc-dev
In-Reply-To: <83wt7qkiz1.fsf@uname.e.linpro.no>
> Is it possible to update the HMC, for example to 5.x.something without
> updating (read boot) the managed systems as well?
Yes, you should be able to update the HMC independently. Though having up to date
firmware on your managed system is also a good idea when you can afford the downtime (reboot).
^ permalink raw reply
* Re: local_irq_save not masking interrupts
From: Scott Wood @ 2006-09-26 16:27 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <45195296.8000405@cambridgebroadband.com>
Alex Zeffertt wrote:
> I agree this indicates an intent to make it atomic, but I don't see how
> this could cause interrupts to become re-enabled during the request_irq()
> call. Also, since I am calling request_irq at insmod time, i.e. in process
> context, both GFP_ flags *should* work.
You're effectively not in process context when you disable IRQs (at
least, if you want them to stay that way). By specifying GFP_KERNEL,
you're giving the allocator permission to go to sleep, enable IRQs, etc.
The IRQ enabling will happen any time cache_grow() is called with
GFP_WAIT (which is part of GFP_KERNEL), assuming a growable slab.
-Scott
^ permalink raw reply
* Re: fs_enet - support for SCC on CPM2?
From: Vitaly Bordug @ 2006-09-26 16:28 UTC (permalink / raw)
To: Pelton, Dave; +Cc: Linuxppc-embedded
In-Reply-To: <3B9518857C91E345AA1806A6F53C0EB7019F342B@onmxm01.ciena.com>
On Tue, 26 Sep 2006 11:22:30 -0400
"Pelton, Dave" <dpelton@ciena.com> wrote:
> > -----Original Message-----
> > From: Matt Hevern
> <snip>
> >
> > I am trying to compile for an freescale 82xx (CPM2) series
> > processor, with ethernet on an SCC. (kernel 2.6.x) From what
> > i can see, in the file drivers/net/fs_enet/fs_enet-main.c,
> > the config option "CONFIG_FS_ENET_HAS_SCC" pulls in
> > "fs_scc_ops" which are defined in
> > drivers/net/fs_enet/mac-scc.c, but this file does not seem
> > to have support for 82xx series, failing with various compile errors:
> <snip>
> > It seems like these errors are mostly due to the driver being tailored
> for 8xx series.
> <snip>
>
> I had the same problem trying to use fs_enet for 82xx SCC Ethernet and
> came to the same conclusion. The FCC could not be used instead of the
> SCC because of pin limitations in the hardware design. I ended up using
> the "old" SCC Ethernet driver by disabling CONFIG_FS_ENET_HAS_SCC and
> enabling CONFIG_SCC_ENET (Under CPM2 options in kernel config). This
> does not use the new platform bus structure, and arch/ppc/8260_io/enet.c
> may require some board specific tweaks, but it does work.
>
Scc Ethernet on 82xx was not supported because the hardware it was developed on
did not support such an option at all.
That was the reason why scc_enet is "tailored" for 8xx. If there is a desire and HW to
make it work, please go ahead, I'll assist as per time permits, and make sure the stuff
will be merged upstream.
Obsoleted things like 8260_io may disappear sooner or later (I bet sooner is more probably...)
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: Asterisk on Embedded Linux
From: Eugene Surovegin @ 2006-09-26 16:37 UTC (permalink / raw)
To: Iwan Koenig; +Cc: Linuxppc-embedded
In-Reply-To: <20060926064451.71706.qmail@web26012.mail.ukl.yahoo.com>
On Tue, Sep 26, 2006 at 08:44:51AM +0200, Iwan Koenig wrote:
> Does anyone known how to compile Asterisk for a
> powerpc-processor?
> I have tryed:
> ./configure --target=powerpc-linux
> --host=powerpc-604-linux-gnu --prefix=/opt/packages
> And it gives following error:
> /root/pwlib/include/ptlib.h... configure: error:
> cannot check for file existence when cross compiling
>
> Ok! I see that it is trying to find the PWLIB-Library.
> Also, i have tryed to compile the pwlib.
> But it didn't work :(. For PWLIB i need the OpenLDAP,
> and when i have compiled the OpenLDAP, than needs
> PWLIB other packages.......
> Also, have anyone ideas, how to compile Asterisk f?r a
> powerpc-processor with another way?
>
Usually, a lot of open-source software isn't cross-compile friendly.
The easiest way to actually build such stuff is to do a native build -
yes, this will be slow, but you'll probably spend more time fixing
makefiles and scripts (and will likely just gave up on this).
--
Eugene
^ permalink raw reply
* Re: local_irq_save not masking interrupts
From: Alex Zeffertt @ 2006-09-26 16:42 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <451954D8.3050909@freescale.com>
Scott Wood wrote:
> Alex Zeffertt wrote:
>> I agree this indicates an intent to make it atomic, but I don't see how
>> this could cause interrupts to become re-enabled during the request_irq()
>> call. Also, since I am calling request_irq at insmod time, i.e. in
>> process
>> context, both GFP_ flags *should* work.
>
> You're effectively not in process context when you disable IRQs (at
> least, if you want them to stay that way). By specifying GFP_KERNEL,
> you're giving the allocator permission to go to sleep, enable IRQs, etc.
> The IRQ enabling will happen any time cache_grow() is called with
> GFP_WAIT (which is part of GFP_KERNEL), assuming a growable slab.
Ah-ha! This explains a lot...
One of the oddities I was seeing with this problem was that if I
did an "ifconfig down" on a completely unrelated net_device (a vlan)
the problem would *not* occur, i.e. I did not get an interrupt
during the critical section. Now I understand why: the "ifconfig down"
command freed some memory so that the kmalloc(,GFP_KERNEL) did not
need to grow the cache.
It follows from what you are saying that kmalloc(,GFP_KERNEL)
MUST NOT occur anywhere in the call chain during a critical section.
This must catch others out too. Surely kmalloc/cache_grow should
return NULL rather than enable interrupts. In fact, shouldn't it be
a BUG() if kmalloc(,GFP_KERNEL) is called with IRQs disabled?
Thanks for your explanation!
Alex
^ permalink raw reply
* Re: local_irq_save not masking interrupts
From: Scott Wood @ 2006-09-26 16:52 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <45195882.1090003@cambridgebroadband.com>
Alex Zeffertt wrote:
> It follows from what you are saying that kmalloc(,GFP_KERNEL)
> MUST NOT occur anywhere in the call chain during a critical section.
>
> This must catch others out too. Surely kmalloc/cache_grow should
> return NULL rather than enable interrupts.
The local_irq_enable() is intended to reverse a previous
local_irq_save() done in the allocator (with the assumption that if
GFP_WAIT is specified, the flags saved had IRQs enabled), not to handle
the case where IRQs were disabled by kmalloc's caller. Returning NULL
would mean that slabs can never grow with GFP_KERNEL.
> In fact, shouldn't it be
> a BUG() if kmalloc(,GFP_KERNEL) is called with IRQs disabled?
Yes.
-Scott
^ permalink raw reply
* Re: Asterisk on Embedded Linux
From: Carlos Munoz @ 2006-09-26 17:37 UTC (permalink / raw)
To: Iwan Koenig; +Cc: Linuxppc-embedded
In-Reply-To: <20060926064451.71706.qmail@web26012.mail.ukl.yahoo.com>
Iwan Koenig wrote:
>Does anyone known how to compile Asterisk for a
>powerpc-processor?
>I have tryed:
>./configure --target=powerpc-linux
>--host=powerpc-604-linux-gnu --prefix=/opt/packages
>And it gives following error:
> /root/pwlib/include/ptlib.h... configure: error:
>cannot check for file existence when cross compiling
>
>Ok! I see that it is trying to find the PWLIB-Library.
>Also, i have tryed to compile the pwlib.
>But it didn't work :(. For PWLIB i need the OpenLDAP,
>and when i have compiled the OpenLDAP, than needs
>PWLIB other packages.......
>Also, have anyone ideas, how to compile Asterisk für a
>powerpc-processor with another way?
>
>Thanks!!!!
>
>
>
I'm not sure if our experience applies to you since we use asterisk as a
TA instead of a PBX in our embedded gateways. We ran into a lot of
problems when trying to cross-compile a trimmed down version of
asterisk. Basically, we only needed the sip stack, fxs support, and some
codecs. It was a big effort, but we are currently successfully
cross-compiling asterisk for several platforms. We had to change
Makefiles, source code, etc.
I would start by removing the references to PWLIB and anything I don't
need from the makefiles and #ifdefing code that uses it until I get it
to compile. Then start testing it and adding features as needed.
This is the command line we use to compile asterisk (just to give you
and idea. It won't work with your sources. We don't run configure):
make CC=powerpc-uclibc-gcc CONFIG_TA=y OPTIMIZE="-mcpu=603e -Os"
HOSTCC=gcc all
Carlos
^ permalink raw reply
* [PATCH] move drivers/macintosh variables to BSS
From: Olaf Hering @ 2006-09-26 20:15 UTC (permalink / raw)
To: Paul Mackeras, Benjamin Herrenschmidt, linuxppc-dev
Move all the initialized variables to bss and init them at runtime if needed.
Mark a version string as const.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
drivers/macintosh/adbhid.c | 4 ++--
drivers/macintosh/ans-lcd.c | 6 ++++--
drivers/macintosh/apm_emu.c | 2 +-
drivers/macintosh/mac_hid.c | 10 ++++++----
drivers/macintosh/therm_adt746x.c | 6 +++---
drivers/macintosh/via-cuda.c | 2 +-
drivers/macintosh/via-macii.c | 10 +++++-----
drivers/macintosh/via-maciisi.c | 6 +++---
drivers/macintosh/via-pmu.c | 22 ++++++++++++----------
drivers/macintosh/via-pmu68k.c | 7 ++++---
drivers/macintosh/windfarm_pm112.c | 3 ++-
drivers/macintosh/windfarm_smu_controls.c | 3 ++-
12 files changed, 45 insertions(+), 36 deletions(-)
Index: linux-2.6.18/drivers/macintosh/adbhid.c
===================================================================
--- linux-2.6.18.orig/drivers/macintosh/adbhid.c
+++ linux-2.6.18/drivers/macintosh/adbhid.c
@@ -580,8 +580,8 @@ static struct adb_request led_request;
static int leds_pending[16];
static int leds_req_pending;
static int pending_devs[16];
-static int pending_led_start=0;
-static int pending_led_end=0;
+static int pending_led_start;
+static int pending_led_end;
static DEFINE_SPINLOCK(leds_lock);
static void leds_done(struct adb_request *req)
Index: linux-2.6.18/drivers/macintosh/ans-lcd.c
===================================================================
--- linux-2.6.18.orig/drivers/macintosh/ans-lcd.c
+++ linux-2.6.18/drivers/macintosh/ans-lcd.c
@@ -21,8 +21,8 @@
#define ANSLCD_CTRL_IX 0x00
#define ANSLCD_DATA_IX 0x10
-static unsigned long anslcd_short_delay = 80;
-static unsigned long anslcd_long_delay = 3280;
+static unsigned long anslcd_short_delay;
+static unsigned long anslcd_long_delay;
static volatile unsigned char __iomem *anslcd_ptr;
#undef DEBUG
@@ -164,6 +164,8 @@ anslcd_init(void)
printk(KERN_DEBUG "LCD: init\n");
#endif
+ anslcd_short_delay = 80;
+ anslcd_long_delay = 3280;
anslcd_write_byte_ctrl ( 0x38 );
anslcd_write_byte_ctrl ( 0x0c );
anslcd_write_byte_ctrl ( 0x06 );
Index: linux-2.6.18/drivers/macintosh/apm_emu.c
===================================================================
--- linux-2.6.18.orig/drivers/macintosh/apm_emu.c
+++ linux-2.6.18/drivers/macintosh/apm_emu.c
@@ -102,7 +102,7 @@ static struct pmu_sleep_notifier apm_sle
SLEEP_LEVEL_USERLAND,
};
-static char driver_version[] = "0.5"; /* no spaces */
+static const char driver_version[] = "0.5"; /* no spaces */
#ifdef DEBUG
static char * apm_event_name[] = {
Index: linux-2.6.18/drivers/macintosh/mac_hid.c
===================================================================
--- linux-2.6.18.orig/drivers/macintosh/mac_hid.c
+++ linux-2.6.18/drivers/macintosh/mac_hid.c
@@ -17,10 +17,10 @@
static struct input_dev *emumousebtn;
static int emumousebtn_input_register(void);
-static int mouse_emulate_buttons = 0;
-static int mouse_button2_keycode = KEY_RIGHTCTRL; /* right control key */
-static int mouse_button3_keycode = KEY_RIGHTALT; /* right option key */
-static int mouse_last_keycode = 0;
+static int mouse_emulate_buttons;
+static int mouse_button2_keycode;
+static int mouse_button3_keycode;
+static int mouse_last_keycode;
#if defined(CONFIG_SYSCTL)
/* file(s) in /proc/sys/dev/mac_hid */
@@ -133,6 +133,8 @@ int __init mac_hid_init(void)
if (err)
return err;
+ mouse_button2_keycode = KEY_RIGHTCTRL; /* right control key */
+ mouse_button3_keycode = KEY_RIGHTALT; /* right option key */
#if defined(CONFIG_SYSCTL)
mac_hid_sysctl_header = register_sysctl_table(mac_hid_root_dir, 1);
#endif /* CONFIG_SYSCTL */
Index: linux-2.6.18/drivers/macintosh/therm_adt746x.c
===================================================================
--- linux-2.6.18.orig/drivers/macintosh/therm_adt746x.c
+++ linux-2.6.18/drivers/macintosh/therm_adt746x.c
@@ -47,11 +47,11 @@ static u8 FAN_SPD_SET[2] = {0x30, 0x31};
static u8 default_limits_local[3] = {70, 50, 70}; /* local, sensor1, sensor2 */
static u8 default_limits_chip[3] = {80, 65, 80}; /* local, sensor1, sensor2 */
-static char *sensor_location[3] = {NULL, NULL, NULL};
+static char *sensor_location[3];
-static int limit_adjust = 0;
+static int limit_adjust;
static int fan_speed = -1;
-static int verbose = 0;
+static int verbose;
MODULE_AUTHOR("Colin Leroy <colin@colino.net>");
MODULE_DESCRIPTION("Driver for ADT746x thermostat in iBook G4 and "
Index: linux-2.6.18/drivers/macintosh/via-cuda.c
===================================================================
--- linux-2.6.18.orig/drivers/macintosh/via-cuda.c
+++ linux-2.6.18/drivers/macintosh/via-cuda.c
@@ -86,7 +86,7 @@ static int data_index;
#ifdef CONFIG_PPC
static struct device_node *vias;
#endif
-static int cuda_fully_inited = 0;
+static int cuda_fully_inited;
#ifdef CONFIG_ADB
static int cuda_probe(void);
Index: linux-2.6.18/drivers/macintosh/via-macii.c
===================================================================
--- linux-2.6.18.orig/drivers/macintosh/via-macii.c
+++ linux-2.6.18/drivers/macintosh/via-macii.c
@@ -107,10 +107,10 @@ static enum macii_state {
awaiting_reply
} macii_state;
-static int need_poll = 0;
-static int command_byte = 0;
-static int last_reply = 0;
-static int last_active = 0;
+static int need_poll;
+static int command_byte;
+static int last_reply;
+static int last_active;
static struct adb_request *current_req;
static struct adb_request *last_req;
@@ -124,7 +124,7 @@ static int first_byte;
static int prefix_len;
static int status = ST_IDLE|TREQ;
static int last_status;
-static int driver_running = 0;
+static int driver_running;
/* debug level 10 required for ADB logging (should be && debug_adb, ideally) */
Index: linux-2.6.18/drivers/macintosh/via-maciisi.c
===================================================================
--- linux-2.6.18.orig/drivers/macintosh/via-maciisi.c
+++ linux-2.6.18/drivers/macintosh/via-maciisi.c
@@ -63,10 +63,10 @@ static volatile unsigned char *via;
#undef DEBUG_MACIISI_ADB
-static struct adb_request* current_req = NULL;
-static struct adb_request* last_req = NULL;
+static struct adb_request* current_req;
+static struct adb_request* last_req;
static unsigned char maciisi_rbuf[16];
-static unsigned char *reply_ptr = NULL;
+static unsigned char *reply_ptr;
static int data_index;
static int reading_reply;
static int reply_len;
Index: linux-2.6.18/drivers/macintosh/via-pmu.c
===================================================================
--- linux-2.6.18.orig/drivers/macintosh/via-pmu.c
+++ linux-2.6.18/drivers/macintosh/via-pmu.c
@@ -139,14 +139,14 @@ static int data_len;
static volatile int adb_int_pending;
static volatile int disable_poll;
static struct device_node *vias;
-static int pmu_kind = PMU_UNKNOWN;
-static int pmu_fully_inited = 0;
+static int pmu_kind;
+static int pmu_fully_inited;
static int pmu_has_adb;
static struct device_node *gpio_node;
-static unsigned char __iomem *gpio_reg = NULL;
-static int gpio_irq = NO_IRQ;
-static int gpio_irq_enabled = -1;
-static volatile int pmu_suspended = 0;
+static unsigned char __iomem *gpio_reg;
+static int gpio_irq;
+static int gpio_irq_enabled;
+static volatile int pmu_suspended;
static spinlock_t pmu_lock;
static u8 pmu_intr_mask;
static int pmu_version;
@@ -170,7 +170,7 @@ int pmu_battery_count;
int pmu_cur_battery;
unsigned int pmu_power_flags;
struct pmu_battery_info pmu_batteries[PMU_MAX_BATTERIES];
-static int query_batt_timer = BATTERY_POLLING_COUNT;
+static int query_batt_timer;
static struct adb_request batt_req;
static struct proc_dir_entry *proc_pmu_batt[PMU_MAX_BATTERIES];
@@ -179,7 +179,7 @@ int asleep;
BLOCKING_NOTIFIER_HEAD(sleep_notifier_list);
#ifdef CONFIG_ADB
-static int adb_dev_map = 0;
+static int adb_dev_map;
static int pmu_adb_flags;
static int pmu_probe(void);
@@ -361,6 +361,7 @@ int __init find_via_pmu(void)
PMU_DRIVER_VERSION, pbook_type[pmu_kind], pmu_version);
sys_ctrler = SYS_CTRLER_PMU;
+ query_batt_timer = BATTERY_POLLING_COUNT;
return 1;
fail:
@@ -414,10 +415,12 @@ static int __init via_pmu_start(void)
if (gpio_node == NULL)
gpio_node = of_find_node_by_name(NULL,
"pmu-interrupt");
+ gpio_irq = NO_IRQ;
if (gpio_node)
gpio_irq = irq_of_parse_and_map(gpio_node, 0);
if (gpio_irq != NO_IRQ) {
+ gpio_irq_enabled = -1;
if (request_irq(gpio_irq, gpio1_interrupt, 0,
"GPIO1 ADB", (void *)0))
printk(KERN_ERR "pmu: can't get irq %d"
@@ -2767,7 +2770,7 @@ pmu_polled_request(struct adb_request *r
#if defined(CONFIG_PM) && defined(CONFIG_PPC32)
-static int pmu_sys_suspended = 0;
+static int pmu_sys_suspended;
static int pmu_sys_suspend(struct sys_device *sysdev, pm_message_t state)
{
@@ -2807,7 +2810,6 @@ static struct sysdev_class pmu_sysclass
};
static struct sys_device device_pmu = {
- .id = 0,
.cls = &pmu_sysclass,
};
Index: linux-2.6.18/drivers/macintosh/via-pmu68k.c
===================================================================
--- linux-2.6.18.orig/drivers/macintosh/via-pmu68k.c
+++ linux-2.6.18/drivers/macintosh/via-pmu68k.c
@@ -96,10 +96,10 @@ static int data_index;
static int data_len;
static int adb_int_pending;
static int pmu_adb_flags;
-static int adb_dev_map = 0;
+static int adb_dev_map;
static struct adb_request bright_req_1, bright_req_2, bright_req_3;
-static int pmu_kind = PMU_UNKNOWN;
-static int pmu_fully_inited = 0;
+static int pmu_kind;
+static int pmu_fully_inited;
int asleep;
BLOCKING_NOTIFIER_HEAD(sleep_notifier_list);
@@ -184,6 +184,7 @@ int pmu_probe(void)
} else if (macintosh_config->adb_type == MAC_ADB_PB2) {
pmu_kind = PMU_68K_V2;
} else {
+ pmu_kind = PMU_UNKNOWN;
return -ENODEV;
}
Index: linux-2.6.18/drivers/macintosh/windfarm_pm112.c
===================================================================
--- linux-2.6.18.orig/drivers/macintosh/windfarm_pm112.c
+++ linux-2.6.18/drivers/macintosh/windfarm_pm112.c
@@ -91,7 +91,7 @@ static struct wf_cpu_pid_state cpu_pid[N
static u32 cpu_thist[CPU_TEMP_HIST_SIZE];
static int cpu_thist_pt;
static s64 cpu_thist_total;
-static s32 cpu_all_tmax = 100 << 16;
+static s32 cpu_all_tmax;
static int cpu_last_target;
static struct wf_pid_state backside_pid;
static int backside_tick;
@@ -683,6 +683,7 @@ static int __init wf_pm112_init(void)
++nr_cores;
printk(KERN_INFO "windfarm: initializing for dual-core desktop G5\n");
+ cpu_all_tmax = 100 << 16;
driver_register(&wf_pm112_driver);
return 0;
}
Index: linux-2.6.18/drivers/macintosh/windfarm_smu_controls.c
===================================================================
--- linux-2.6.18.orig/drivers/macintosh/windfarm_smu_controls.c
+++ linux-2.6.18/drivers/macintosh/windfarm_smu_controls.c
@@ -34,7 +34,7 @@
#define DBG(args...) do { } while(0)
#endif
-static int smu_supports_new_fans_ops = 1;
+static int smu_supports_new_fans_ops;
/*
* SMU fans control object
@@ -259,6 +259,7 @@ static int __init smu_controls_init(void
if (smu == NULL)
return -ENODEV;
+ smu_supports_new_fans_ops = 1;
/* Look for RPM fans */
for (fans = NULL; (fans = of_get_next_child(smu, fans)) != NULL;)
if (!strcmp(fans->name, "rpm-fans") ||
^ permalink raw reply
* [PATCH] avoid NULL pointer in gpio1_interrupt
From: Olaf Hering @ 2006-09-26 20:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
gpio1_interrupt() may dereference a NULL pointer if ioremap() fails.
But, maybe no gpio interrupt happens in the first place?
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
drivers/macintosh/via-pmu.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
Index: linux-2.6.18/drivers/macintosh/via-pmu.c
===================================================================
--- linux-2.6.18.orig/drivers/macintosh/via-pmu.c
+++ linux-2.6.18/drivers/macintosh/via-pmu.c
@@ -336,8 +336,10 @@ int __init find_via_pmu(void)
if (gaddr != OF_BAD_ADDR)
gpio_reg = ioremap(gaddr, 0x10);
}
- if (gpio_reg == NULL)
+ if (gpio_reg == NULL) {
printk(KERN_ERR "via-pmu: Can't find GPIO reg !\n");
+ goto fail_gpio;
+ }
} else
pmu_kind = PMU_UNKNOWN;
@@ -366,6 +368,9 @@ int __init find_via_pmu(void)
return 1;
fail:
of_node_put(vias);
+ iounmap(gpio_reg);
+ gpio_reg = NULL;
+ fail_gpio:
vias = NULL;
return 0;
}
^ permalink raw reply
* Re: [PATCH] Add powerpc get/set_rtc_time interface to new generic rtc class
From: Benjamin Herrenschmidt @ 2006-09-26 22:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <2FE0EA9E-D0E8-4A6B-8184-454DAAE02FC5@kernel.crashing.org>
On Tue, 2006-09-26 at 09:14 -0500, Kumar Gala wrote:
> On Sep 25, 2006, at 10:13 PM, Benjamin Herrenschmidt wrote:
>
> > On Mon, 2006-09-25 at 21:55 -0500, Kim Phillips wrote:
> >> Add powerpc get/set_rtc_time interface to new generic rtc class. This
> >> abstracts rtc chip specific code from the platform code for rtc-
> >> over-i2c
> >> platforms. Specific RTC chip support is now configured under
> >> Device Drivers -> Real Time Clock. Setting time of day from the RTC
> >> on startup is also configurable.
> >>
> >> Currently, the only default config in powerpc arch is the 8349 itx.
> >> Other platforms wanting to consolidate code may also use this.
> >>
> >> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> >
> > I think we should only get that in if we also adapt the various
> > platform
> > RTC code to be in drivers/rtc ... right now, enabling that option will
> > just break everybody.
>
> Maybe just drop the init call for now and let people migrate over to
> using this and moving the drivers over to drivers/rtc which aren't
> supported there.
Yup. We shouldn't change ppc_md from an initcall that way for something
that may not be supported by a platform. The platform code shall set
ppc_md. (maybe calling some init function for doing it) if the platform
supports the new class mecanism.
Ben.
^ permalink raw reply
* Re: [PATCH] avoid NULL pointer in gpio1_interrupt
From: Benjamin Herrenschmidt @ 2006-09-26 22:06 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060926202836.GA1051@aepfle.de>
On Tue, 2006-09-26 at 22:28 +0200, Olaf Hering wrote:
> gpio1_interrupt() may dereference a NULL pointer if ioremap() fails.
> But, maybe no gpio interrupt happens in the first place?
Nah, they would happen. Good catch tho I fail to see how ioremap would
fail that early during boot :)
Ben.
^ permalink raw reply
* Re: [PATCH] move drivers/macintosh variables to BSS
From: Benjamin Herrenschmidt @ 2006-09-26 22:45 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Paul Mackeras
In-Reply-To: <20060926201554.GA886@aepfle.de>
On Tue, 2006-09-26 at 22:15 +0200, Olaf Hering wrote:
> Move all the initialized variables to bss and init them at runtime if needed.
> Mark a version string as const.
What is the point of that ?
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> ---
> drivers/macintosh/adbhid.c | 4 ++--
> drivers/macintosh/ans-lcd.c | 6 ++++--
> drivers/macintosh/apm_emu.c | 2 +-
> drivers/macintosh/mac_hid.c | 10 ++++++----
> drivers/macintosh/therm_adt746x.c | 6 +++---
> drivers/macintosh/via-cuda.c | 2 +-
> drivers/macintosh/via-macii.c | 10 +++++-----
> drivers/macintosh/via-maciisi.c | 6 +++---
> drivers/macintosh/via-pmu.c | 22 ++++++++++++----------
> drivers/macintosh/via-pmu68k.c | 7 ++++---
> drivers/macintosh/windfarm_pm112.c | 3 ++-
> drivers/macintosh/windfarm_smu_controls.c | 3 ++-
> 12 files changed, 45 insertions(+), 36 deletions(-)
>
> Index: linux-2.6.18/drivers/macintosh/adbhid.c
> ===================================================================
> --- linux-2.6.18.orig/drivers/macintosh/adbhid.c
> +++ linux-2.6.18/drivers/macintosh/adbhid.c
> @@ -580,8 +580,8 @@ static struct adb_request led_request;
> static int leds_pending[16];
> static int leds_req_pending;
> static int pending_devs[16];
> -static int pending_led_start=0;
> -static int pending_led_end=0;
> +static int pending_led_start;
> +static int pending_led_end;
> static DEFINE_SPINLOCK(leds_lock);
>
> static void leds_done(struct adb_request *req)
> Index: linux-2.6.18/drivers/macintosh/ans-lcd.c
> ===================================================================
> --- linux-2.6.18.orig/drivers/macintosh/ans-lcd.c
> +++ linux-2.6.18/drivers/macintosh/ans-lcd.c
> @@ -21,8 +21,8 @@
> #define ANSLCD_CTRL_IX 0x00
> #define ANSLCD_DATA_IX 0x10
>
> -static unsigned long anslcd_short_delay = 80;
> -static unsigned long anslcd_long_delay = 3280;
> +static unsigned long anslcd_short_delay;
> +static unsigned long anslcd_long_delay;
> static volatile unsigned char __iomem *anslcd_ptr;
>
> #undef DEBUG
> @@ -164,6 +164,8 @@ anslcd_init(void)
> printk(KERN_DEBUG "LCD: init\n");
> #endif
>
> + anslcd_short_delay = 80;
> + anslcd_long_delay = 3280;
> anslcd_write_byte_ctrl ( 0x38 );
> anslcd_write_byte_ctrl ( 0x0c );
> anslcd_write_byte_ctrl ( 0x06 );
> Index: linux-2.6.18/drivers/macintosh/apm_emu.c
> ===================================================================
> --- linux-2.6.18.orig/drivers/macintosh/apm_emu.c
> +++ linux-2.6.18/drivers/macintosh/apm_emu.c
> @@ -102,7 +102,7 @@ static struct pmu_sleep_notifier apm_sle
> SLEEP_LEVEL_USERLAND,
> };
>
> -static char driver_version[] = "0.5"; /* no spaces */
> +static const char driver_version[] = "0.5"; /* no spaces */
>
> #ifdef DEBUG
> static char * apm_event_name[] = {
> Index: linux-2.6.18/drivers/macintosh/mac_hid.c
> ===================================================================
> --- linux-2.6.18.orig/drivers/macintosh/mac_hid.c
> +++ linux-2.6.18/drivers/macintosh/mac_hid.c
> @@ -17,10 +17,10 @@
>
> static struct input_dev *emumousebtn;
> static int emumousebtn_input_register(void);
> -static int mouse_emulate_buttons = 0;
> -static int mouse_button2_keycode = KEY_RIGHTCTRL; /* right control key */
> -static int mouse_button3_keycode = KEY_RIGHTALT; /* right option key */
> -static int mouse_last_keycode = 0;
> +static int mouse_emulate_buttons;
> +static int mouse_button2_keycode;
> +static int mouse_button3_keycode;
> +static int mouse_last_keycode;
>
> #if defined(CONFIG_SYSCTL)
> /* file(s) in /proc/sys/dev/mac_hid */
> @@ -133,6 +133,8 @@ int __init mac_hid_init(void)
> if (err)
> return err;
>
> + mouse_button2_keycode = KEY_RIGHTCTRL; /* right control key */
> + mouse_button3_keycode = KEY_RIGHTALT; /* right option key */
> #if defined(CONFIG_SYSCTL)
> mac_hid_sysctl_header = register_sysctl_table(mac_hid_root_dir, 1);
> #endif /* CONFIG_SYSCTL */
> Index: linux-2.6.18/drivers/macintosh/therm_adt746x.c
> ===================================================================
> --- linux-2.6.18.orig/drivers/macintosh/therm_adt746x.c
> +++ linux-2.6.18/drivers/macintosh/therm_adt746x.c
> @@ -47,11 +47,11 @@ static u8 FAN_SPD_SET[2] = {0x30, 0x31};
>
> static u8 default_limits_local[3] = {70, 50, 70}; /* local, sensor1, sensor2 */
> static u8 default_limits_chip[3] = {80, 65, 80}; /* local, sensor1, sensor2 */
> -static char *sensor_location[3] = {NULL, NULL, NULL};
> +static char *sensor_location[3];
>
> -static int limit_adjust = 0;
> +static int limit_adjust;
> static int fan_speed = -1;
> -static int verbose = 0;
> +static int verbose;
>
> MODULE_AUTHOR("Colin Leroy <colin@colino.net>");
> MODULE_DESCRIPTION("Driver for ADT746x thermostat in iBook G4 and "
> Index: linux-2.6.18/drivers/macintosh/via-cuda.c
> ===================================================================
> --- linux-2.6.18.orig/drivers/macintosh/via-cuda.c
> +++ linux-2.6.18/drivers/macintosh/via-cuda.c
> @@ -86,7 +86,7 @@ static int data_index;
> #ifdef CONFIG_PPC
> static struct device_node *vias;
> #endif
> -static int cuda_fully_inited = 0;
> +static int cuda_fully_inited;
>
> #ifdef CONFIG_ADB
> static int cuda_probe(void);
> Index: linux-2.6.18/drivers/macintosh/via-macii.c
> ===================================================================
> --- linux-2.6.18.orig/drivers/macintosh/via-macii.c
> +++ linux-2.6.18/drivers/macintosh/via-macii.c
> @@ -107,10 +107,10 @@ static enum macii_state {
> awaiting_reply
> } macii_state;
>
> -static int need_poll = 0;
> -static int command_byte = 0;
> -static int last_reply = 0;
> -static int last_active = 0;
> +static int need_poll;
> +static int command_byte;
> +static int last_reply;
> +static int last_active;
>
> static struct adb_request *current_req;
> static struct adb_request *last_req;
> @@ -124,7 +124,7 @@ static int first_byte;
> static int prefix_len;
> static int status = ST_IDLE|TREQ;
> static int last_status;
> -static int driver_running = 0;
> +static int driver_running;
>
> /* debug level 10 required for ADB logging (should be && debug_adb, ideally) */
>
> Index: linux-2.6.18/drivers/macintosh/via-maciisi.c
> ===================================================================
> --- linux-2.6.18.orig/drivers/macintosh/via-maciisi.c
> +++ linux-2.6.18/drivers/macintosh/via-maciisi.c
> @@ -63,10 +63,10 @@ static volatile unsigned char *via;
>
> #undef DEBUG_MACIISI_ADB
>
> -static struct adb_request* current_req = NULL;
> -static struct adb_request* last_req = NULL;
> +static struct adb_request* current_req;
> +static struct adb_request* last_req;
> static unsigned char maciisi_rbuf[16];
> -static unsigned char *reply_ptr = NULL;
> +static unsigned char *reply_ptr;
> static int data_index;
> static int reading_reply;
> static int reply_len;
> Index: linux-2.6.18/drivers/macintosh/via-pmu.c
> ===================================================================
> --- linux-2.6.18.orig/drivers/macintosh/via-pmu.c
> +++ linux-2.6.18/drivers/macintosh/via-pmu.c
> @@ -139,14 +139,14 @@ static int data_len;
> static volatile int adb_int_pending;
> static volatile int disable_poll;
> static struct device_node *vias;
> -static int pmu_kind = PMU_UNKNOWN;
> -static int pmu_fully_inited = 0;
> +static int pmu_kind;
> +static int pmu_fully_inited;
> static int pmu_has_adb;
> static struct device_node *gpio_node;
> -static unsigned char __iomem *gpio_reg = NULL;
> -static int gpio_irq = NO_IRQ;
> -static int gpio_irq_enabled = -1;
> -static volatile int pmu_suspended = 0;
> +static unsigned char __iomem *gpio_reg;
> +static int gpio_irq;
> +static int gpio_irq_enabled;
> +static volatile int pmu_suspended;
> static spinlock_t pmu_lock;
> static u8 pmu_intr_mask;
> static int pmu_version;
> @@ -170,7 +170,7 @@ int pmu_battery_count;
> int pmu_cur_battery;
> unsigned int pmu_power_flags;
> struct pmu_battery_info pmu_batteries[PMU_MAX_BATTERIES];
> -static int query_batt_timer = BATTERY_POLLING_COUNT;
> +static int query_batt_timer;
> static struct adb_request batt_req;
> static struct proc_dir_entry *proc_pmu_batt[PMU_MAX_BATTERIES];
>
> @@ -179,7 +179,7 @@ int asleep;
> BLOCKING_NOTIFIER_HEAD(sleep_notifier_list);
>
> #ifdef CONFIG_ADB
> -static int adb_dev_map = 0;
> +static int adb_dev_map;
> static int pmu_adb_flags;
>
> static int pmu_probe(void);
> @@ -361,6 +361,7 @@ int __init find_via_pmu(void)
> PMU_DRIVER_VERSION, pbook_type[pmu_kind], pmu_version);
>
> sys_ctrler = SYS_CTRLER_PMU;
> + query_batt_timer = BATTERY_POLLING_COUNT;
>
> return 1;
> fail:
> @@ -414,10 +415,12 @@ static int __init via_pmu_start(void)
> if (gpio_node == NULL)
> gpio_node = of_find_node_by_name(NULL,
> "pmu-interrupt");
> + gpio_irq = NO_IRQ;
> if (gpio_node)
> gpio_irq = irq_of_parse_and_map(gpio_node, 0);
>
> if (gpio_irq != NO_IRQ) {
> + gpio_irq_enabled = -1;
> if (request_irq(gpio_irq, gpio1_interrupt, 0,
> "GPIO1 ADB", (void *)0))
> printk(KERN_ERR "pmu: can't get irq %d"
> @@ -2767,7 +2770,7 @@ pmu_polled_request(struct adb_request *r
>
> #if defined(CONFIG_PM) && defined(CONFIG_PPC32)
>
> -static int pmu_sys_suspended = 0;
> +static int pmu_sys_suspended;
>
> static int pmu_sys_suspend(struct sys_device *sysdev, pm_message_t state)
> {
> @@ -2807,7 +2810,6 @@ static struct sysdev_class pmu_sysclass
> };
>
> static struct sys_device device_pmu = {
> - .id = 0,
> .cls = &pmu_sysclass,
> };
>
> Index: linux-2.6.18/drivers/macintosh/via-pmu68k.c
> ===================================================================
> --- linux-2.6.18.orig/drivers/macintosh/via-pmu68k.c
> +++ linux-2.6.18/drivers/macintosh/via-pmu68k.c
> @@ -96,10 +96,10 @@ static int data_index;
> static int data_len;
> static int adb_int_pending;
> static int pmu_adb_flags;
> -static int adb_dev_map = 0;
> +static int adb_dev_map;
> static struct adb_request bright_req_1, bright_req_2, bright_req_3;
> -static int pmu_kind = PMU_UNKNOWN;
> -static int pmu_fully_inited = 0;
> +static int pmu_kind;
> +static int pmu_fully_inited;
>
> int asleep;
> BLOCKING_NOTIFIER_HEAD(sleep_notifier_list);
> @@ -184,6 +184,7 @@ int pmu_probe(void)
> } else if (macintosh_config->adb_type == MAC_ADB_PB2) {
> pmu_kind = PMU_68K_V2;
> } else {
> + pmu_kind = PMU_UNKNOWN;
> return -ENODEV;
> }
>
> Index: linux-2.6.18/drivers/macintosh/windfarm_pm112.c
> ===================================================================
> --- linux-2.6.18.orig/drivers/macintosh/windfarm_pm112.c
> +++ linux-2.6.18/drivers/macintosh/windfarm_pm112.c
> @@ -91,7 +91,7 @@ static struct wf_cpu_pid_state cpu_pid[N
> static u32 cpu_thist[CPU_TEMP_HIST_SIZE];
> static int cpu_thist_pt;
> static s64 cpu_thist_total;
> -static s32 cpu_all_tmax = 100 << 16;
> +static s32 cpu_all_tmax;
> static int cpu_last_target;
> static struct wf_pid_state backside_pid;
> static int backside_tick;
> @@ -683,6 +683,7 @@ static int __init wf_pm112_init(void)
> ++nr_cores;
>
> printk(KERN_INFO "windfarm: initializing for dual-core desktop G5\n");
> + cpu_all_tmax = 100 << 16;
> driver_register(&wf_pm112_driver);
> return 0;
> }
> Index: linux-2.6.18/drivers/macintosh/windfarm_smu_controls.c
> ===================================================================
> --- linux-2.6.18.orig/drivers/macintosh/windfarm_smu_controls.c
> +++ linux-2.6.18/drivers/macintosh/windfarm_smu_controls.c
> @@ -34,7 +34,7 @@
> #define DBG(args...) do { } while(0)
> #endif
>
> -static int smu_supports_new_fans_ops = 1;
> +static int smu_supports_new_fans_ops;
>
> /*
> * SMU fans control object
> @@ -259,6 +259,7 @@ static int __init smu_controls_init(void
> if (smu == NULL)
> return -ENODEV;
>
> + smu_supports_new_fans_ops = 1;
> /* Look for RPM fans */
> for (fans = NULL; (fans = of_get_next_child(smu, fans)) != NULL;)
> if (!strcmp(fans->name, "rpm-fans") ||
^ permalink raw reply
* [PATCH 1/2] Add powerpc get/set_rtc_time interface to new generic rtc class
From: Kim Phillips @ 2006-09-26 22:46 UTC (permalink / raw)
To: linuxppc-dev
Add powerpc get/set_rtc_time interface to new generic rtc class. This
abstracts rtc chip specific code from the platform code for rtc-over-i2c
platforms. Specific RTC chip support is now configured under
Device Drivers -> Real Time Clock. Setting time of day from the RTC
on startup is also configurable.
this time without the potentially platform breaking initcall.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
arch/powerpc/kernel/time.c | 42 ++++++++++++++++++++++++++++++++++++++++++
include/asm-powerpc/time.h | 6 +++++-
2 files changed, 47 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 7a3c3f7..b4ed362 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -1048,6 +1048,48 @@ void __init time_init(void)
set_dec(tb_ticks_per_jiffy);
}
+#ifdef CONFIG_RTC_CLASS
+static int set_rtc_class_time(struct rtc_time *tm)
+{
+ int err;
+ struct class_device *class_dev =
+ rtc_class_open(CONFIG_RTC_HCTOSYS_DEVICE);
+
+ if (class_dev == NULL)
+ return -ENODEV;
+
+ err = rtc_set_time(class_dev, tm);
+
+ rtc_class_close(class_dev);
+
+ return 0;
+}
+
+static void get_rtc_class_time(struct rtc_time *tm)
+{
+ int err;
+ struct class_device *class_dev =
+ rtc_class_open(CONFIG_RTC_HCTOSYS_DEVICE);
+
+ if (class_dev == NULL)
+ return;
+
+ err = rtc_read_time(class_dev, tm);
+
+ rtc_class_close(class_dev);
+
+ return;
+}
+
+int __init rtc_class_hookup(void)
+{
+ ppc_md.get_rtc_time = get_rtc_class_time;
+ ppc_md.set_rtc_time = set_rtc_class_time;
+
+ return 0;
+}
+#endif /* CONFIG_RTC_CLASS */
+
#define FEBRUARY 2
#define STARTOFTIME 1970
diff --git a/include/asm-powerpc/time.h b/include/asm-powerpc/time.h
index 5785ac4..b051d4c 100644
--- a/include/asm-powerpc/time.h
+++ b/include/asm-powerpc/time.h
@@ -39,6 +39,10 @@ extern void generic_calibrate_decr(void)
extern void wakeup_decrementer(void);
extern void snapshot_timebase(void);
+#ifdef CONFIG_RTC_CLASS
+extern int __init rtc_class_hookup(void);
+#endif
+
/* Some sane defaults: 125 MHz timebase, 1GHz processor */
extern unsigned long ppc_proc_freq;
#define DEFAULT_PROC_FREQ (DEFAULT_TB_FREQ * 8)
@@ -234,4 +238,4 @@ #define snapshot_timebases() do { } wh
#endif
#endif /* __KERNEL__ */
-#endif /* __PPC64_TIME_H */
+#endif /* __POWERPC_TIME_H */
--
1.4.2.1
^ permalink raw reply related
* [PATCH 2/2] enable generic rtc hook for the MPC8349 mITX
From: Kim Phillips @ 2006-09-26 22:46 UTC (permalink / raw)
To: linuxppc-dev
enable generic rtc hook for the MPC8349 mITX.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
arch/powerpc/platforms/83xx/mpc834x_itx.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/powerpc/platforms/83xx/mpc834x_itx.c
index 969fbb6..8c676d7 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -109,6 +109,10 @@ static int __init mpc834x_itx_probe(void
return 1;
}
+#ifdef CONFIG_RTC_CLASS
+late_initcall(rtc_class_hookup);
+#endif
+
define_machine(mpc834x_itx) {
.name = "MPC834x ITX",
.probe = mpc834x_itx_probe,
--
1.4.2.1
^ permalink raw reply related
* Re: [PATCH 2/2] enable generic rtc hook for the MPC8349 mITX
From: Kumar Gala @ 2006-09-27 4:34 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20060926174651.032a474e.kim.phillips@freescale.com>
On Sep 26, 2006, at 5:46 PM, Kim Phillips wrote:
> enable generic rtc hook for the MPC8349 mITX.
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
>
> ---
> arch/powerpc/platforms/83xx/mpc834x_itx.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/
> powerpc/platforms/83xx/mpc834x_itx.c
> index 969fbb6..8c676d7 100644
> --- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
> +++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
> @@ -109,6 +109,10 @@ static int __init mpc834x_itx_probe(void
> return 1;
> }
>
> +#ifdef CONFIG_RTC_CLASS
> +late_initcall(rtc_class_hookup);
> +#endif
Any reason we can't just do this in setup_arch?
- k
> +
> define_machine(mpc834x_itx) {
> .name = "MPC834x ITX",
> .probe = mpc834x_itx_probe,
> --
> 1.4.2.1
^ permalink raw reply
* RFC/slightly offtopic: Automatic patchwork status updates
From: Jeremy Kerr @ 2006-09-27 5:28 UTC (permalink / raw)
To: linuxppc-dev, cbe-oss-dev; +Cc: Troy Rollo
Hi all,
For some time now, we've been running patchwork on the linuxppc and
cbe-oss-dev lists. For those who haven't seen it, it collects and
tracks patches posted to the lists, and shows them here:
http://patchwork.ozlabs.org/linuxppc
and
http://patchwork.ozlabs.org/cbe-oss-dev
However, the patch 'state' (eg, accepted, rejected, debug only, changes
requested) doesn't get updated very often, as it can be an unnecessary
burden on the maintainers.
All this information is available from the actual upstream tree itself,
so essentially patchwork *should* be able to just mirror the state.
So, I'd like to get a bit of discussion on how we can get this (or at
least most of it!) done automatically. For instance, can we come up
with a scheme that can detect if a patch has made it into paulus' tree
with some reasonable error rate?
If we can get something sketched up, I'll implement & integrate into
patchwork. Seeing as this is an own-time project for me though, there
will probably be a little latency in the process ;)
Cheers,
Jeremy
PS. do we need to create a separate patchwork list and move discussion
there?
^ permalink raw reply
* Re: RFC/slightly offtopic: Automatic patchwork status updates
From: Michael Neuling @ 2006-09-27 6:26 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, cbe-oss-dev, Troy Rollo
In-Reply-To: <200609271528.49260.jk@ozlabs.org>
> For some time now, we've been running patchwork on the linuxppc and
> cbe-oss-dev lists. For those who haven't seen it, it collects and
> tracks patches posted to the lists, and shows them here:
>
> http://patchwork.ozlabs.org/linuxppc
> and
> http://patchwork.ozlabs.org/cbe-oss-dev
>
> However, the patch 'state' (eg, accepted, rejected, debug only, changes
> requested) doesn't get updated very often, as it can be an unnecessary
> burden on the maintainers.
>
> All this information is available from the actual upstream tree itself,
> so essentially patchwork *should* be able to just mirror the state.
Personally, I use the git web server on kernel.org to see if my patches
are in a particular tree. I have a bookmark something like this:
http://git.kernel.org/git/?p=linux/kernel/git/paulus/powerpc.git&a=search&h=HEAD&s=Jeremy+Kerr
This may not solve all the problems you are trying to solve with
patchworks though.
Mikey
^ 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