Re: i2c_powermac: Kernel access of bad area
Ben, Christian,
On Thu, 7 Jan 2010 17:17:38 +0100, Jean Delvare wrote:
On Wed, 6 Jan 2010 19:41:05 -0800 (PST), Christian Kujau wrote:
Hi Jean,
On Wed, 6 Jan 2010 at 17:37, Jean Delvare wrote:
I think that sysfs files creation should be moved to the end of
probe_thermostat() and sysfs files removal should be moved to the
beginning of remove_thermostat(). Something like the totally untested
patch below (no ppc machine at hand):
I applied your patch to 2.6.33-rc3, and was able to unload i2c-powermac and
then reading the files left in /sys/devices/temperatures. I even tried to
read the non-existant files (e.g. sensor1_fan_speed, etc...), but the
kernel just wouldn't oops :)
So the initial oops is gone - yeah!
Ben, what about applying this patch of mine, as Christian reported it
fixed his oops?
However, the Badness remains when I try to modprobe i2c-powermac again:
[ 442.148222] PowerMac i2c bus pmu 2 registered
[ 442.148792] PowerMac i2c bus pmu 1 registered
[ 442.149299] PowerMac i2c bus mac-io 0 registered
[ 442.163573] adt746x: ADT7467 initializing
[ 442.170072] adt746x: Lowering max temperatures from 73, 80, 109 to 67,
47, 67
[ 442.176559] PowerMac i2c bus uni-n 1 registered
[ 442.227115] sysfs: cannot create duplicate filename '/devices/ams'
[ 442.227697] [ cut here ]
[ 442.228176] Badness at fs/sysfs/dir.c:487
[ 442.228642] NIP: c00eb71c LR: c00eb71c CTR:
[ 442.229117] REGS: eea0fa50 TRAP: 0700 Not tainted (2.6.33-rc3)
[ 442.229592] MSR: 00029032 EE,ME,CE,IR,DR CR: 42008444 XER:
[ 442.230151] TASK = eea1[2821] 'modprobe' THREAD: eea0e000
[ 442.230191] GPR00: c00eb71c eea0fb00 eea1 004c 64c6
[ 442.230758] GPR08: efa71740 c03e 64c6 44008428 10020390
100e 100df49c
[ 442.231326] GPR16: 100b54c0 100df49c 100ddd20 1018fb08 100b5340 c03e674c
c03e6720 c03ea044
[ 442.231902] GPR24: 24008422 ffea eea0fb58 ef0e9000 ef0e9000
ef0a9ea0 ffef
[ 442.233187] NIP [c00eb71c] sysfs_add_one+0x94/0xc0
[ 442.233695] LR [c00eb71c] sysfs_add_one+0x94/0xc0
[ 442.234363] Call Trace:
I've put the whole dmesg on:
http://nerdbynature.de/bits/2.6.33-rc2/i2c_powermac/r1/
Hmm. Looks like a different but somewhat similar problem in the ams
driver: some code that is in ams_exit() (the module exit code) should
instead be called when the device (not module) is removed. It probably
doesn't make much of a difference in the PMU case, but in the I2C case
it does matter.
The following, totally untested patch may fix it. I make no guarantee
that my code isn't racy though, I'm not familiar enough with the ams
driver code to tell for sure.
---
drivers/hwmon/ams/ams-core.c | 11 +++
drivers/hwmon/ams/ams-i2c.c |2 ++
drivers/hwmon/ams/ams-pmu.c |2 ++
drivers/hwmon/ams/ams.h |1 +
4 files changed, 12 insertions(+), 4 deletions(-)
--- linux-2.6.33-rc3.orig/drivers/hwmon/ams/ams-core.c2009-06-10
05:05:27.0 +0200
+++ linux-2.6.33-rc3/drivers/hwmon/ams/ams-core.c 2010-01-07
17:14:25.0 +0100
@@ -213,7 +213,7 @@ int __init ams_init(void)
return -ENODEV;
}
-void ams_exit(void)
+void ams_sensor_detach(void)
{
/* Remove input device */
ams_input_exit();
@@ -221,9 +221,6 @@ void ams_exit(void)
/* Remove attributes */
device_remove_file(ams_info.of_dev-dev, dev_attr_current);
- /* Shut down implementation */
- ams_info.exit();
-
/* Flush interrupt worker
*
* We do this after ams_info.exit(), because an interrupt might
@@ -239,6 +236,12 @@ void ams_exit(void)
pmf_unregister_irq_client(ams_freefall_client);
}
+static void __exit ams_exit(void)
+{
+ /* Shut down implementation */
+ ams_info.exit();
+}
+
MODULE_AUTHOR(Stelian Pop, Michael Hanselmann);
MODULE_DESCRIPTION(Apple Motion Sensor driver);
MODULE_LICENSE(GPL);
--- linux-2.6.33-rc3.orig/drivers/hwmon/ams/ams-i2c.c 2009-06-10
05:05:27.0 +0200
+++ linux-2.6.33-rc3/drivers/hwmon/ams/ams-i2c.c 2010-01-07
17:12:46.0 +0100
@@ -238,6 +238,8 @@ static int ams_i2c_probe(struct i2c_clie
static int ams_i2c_remove(struct i2c_client *client)
{
if (ams_info.has_device) {
+ ams_sensor_detach();
+
/* Disable interrupts */
ams_i2c_set_irq(AMS_IRQ_ALL, 0);
--- linux-2.6.33-rc3.orig/drivers/hwmon/ams/ams-pmu.c 2009-06-10
05:05:27.0 +0200
+++ linux-2.6.33-rc3/drivers/hwmon/ams/ams-pmu.c 2010-01-07
17:13:47.0 +0100
@@ -133,6 +133,8 @@ static void ams_pmu_get_xyz(s8 *x, s8 *y
static void ams_pmu_exit(void)
{
+ ams_sensor_detach();
+
/* Disable interrupts */
ams_pmu_set_irq(AMS_IRQ_ALL, 0);
---
Re: [PATCHv3 2/2] powerpc: implement arch_scale_smt_power for Power7
On Fri, 2010-01-29 at 12:23 +1100, Benjamin Herrenschmidt wrote: On machine that don't have SMT, I would like to avoid calling arch_scale_smt_power() at all if possible (in addition to not compiling it in if SMT is not enabled in .config). Now, I must say I'm utterly confused by how the domains are setup and I haven't quite managed to sort it out... it looks to me that SD_SHARE_CPUPOWER is always going to be set on all CPUs when the config option is set (though each CPU will have its own domain) or am I misguided ? IE. Is there any sense in having at least a fast exit path out of arch_scale_smt_power() for non-SMT CPUs ? The sched_domain creation code is a f'ing stink pile that hurts everybody's brain. The AMD magny-cours people sort of cleaned it up a bit but didn't go nearly far enough. Doing so is somewhere on my todo list, but sadly that thing is way larger than my spare time. Now SD_SHARE_CPUPOWER _should_ only be set for SMT domains, because only SMT siblings share cpupower. SD_SHARE_PKG_RESOURCES _should_ be set for both SMT and MC, because they all share the same cache domain. If it all works out that way in practice on powerpc is another question entirely ;-) That said, I'm still not entirely convinced I like this usage of cpupower, its supposed to be a normalization scale for load-balancing, not a placement hook. I'd be much happier with a SD_GROUP_ORDER or something like that, that works together with SD_PREFER_SIBLING to pack active tasks to cpus in ascending group order. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Proc/CpuInfo - Timebase
Hi, On a powerpc system running linux, when I see cat /proc/cpuinfo, I find the value of timebase. Can somebody suggest on what is that, and how is it used? Regards, Ajay. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Proc/CpuInfo - Timebase
On a powerpc system running linux, when I see cat /proc/cpuinfo, I find the value of timebase. Can somebody suggest on what is that, and how is it used? It is the frequency (in Hz) of the clock that increments the Time Base Register (TBR). After reading TBR (or calculating a difference between two TBR values) you can use timebase to convert to real time units, such as microseconds/nanoseconds/picoseconds. For debugging I log events together with a TBR reading, which I can later convert to a time from reset (or a time from the moment when the kernel initialised TBR to zero, which happens in some kernels). Clive ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv3 2/2] powerpc: implement arch_scale_smt_power for Power7
On Thu, Jan 28, 2010 at 05:20:55PM -0600, Joel Schopp wrote: On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads there is performance benefit to idling the higher numbered threads in the core. Really 2, 3, or 4? When you have 4 idle threads out of 4, performance becomes a minor concern, no? ;-) Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] eeh: fixing pci_dev dependency
On 28 January 2010 18:04, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2010-01-27 at 12:43 -0600, lei...@linux.vnet.ibm.com wrote: Currently pci_dev can be null when EEH is in action. This patch just assure that we pci_dev is not NULL before calling pci_dev_put. Like all variants of *_put(), it already checks for a NULL argument afaik. So that patch should be unnecessary. Ah, OK, I paniced when I saw that and assumed the worst --linas ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 1/3] i2c-mpc: use __devinit[data] for initialization functions and data
On Thu, Jan 28, 2010 at 02:25:39PM +0100, Wolfgang Grandegger wrote: From: Wolfgang Grandegger w...@denx.de __devinit[data] has not yet been used for all initialization functions and data. To avoid truncating lines, the struct mpc_i2c_match_data has been renamed to mpc_i2c_data, which is even the better name. Signed-off-by: Wolfgang Grandegger w...@denx.de Tested-by: Wolfram Sang w.s...@pengutronix.de -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 2/3] i2c-mpc: add support for the MPC512x processors from Freescale
On Thu, Jan 28, 2010 at 02:25:40PM +0100, Wolfgang Grandegger wrote:
From: Wolfgang Grandegger w...@denx.de
The setclock initialization functions have been renamed to setup
because I2C interrupts must be enabled for the MPC512x. This requires
to handle fsl,preserve-clocking in a slighly different way. Also,
the old settings are now reported calling dev_dbg(). For the MPC512x
the clock setup function of the MPC52xx can be re-used. Furthermore,
the Kconfig help has been updated and corrected.
Signed-off-by: Wolfgang Grandegger w...@denx.de
One minor thing and you can add my
Reviewed-by: Wolfram Sang w.s...@pengutronix.de
---
drivers/i2c/busses/Kconfig |7 +-
drivers/i2c/busses/i2c-mpc.c | 127
++
2 files changed, 94 insertions(+), 40 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 5f318ce..5477e41 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -418,13 +418,12 @@ config I2C_IXP2000
instead.
config I2C_MPC
- tristate MPC107/824x/85xx/52xx/86xx
+ tristate MPC107/824x/85xx/512x/52xx/83xx/86xx
depends on PPC32
help
If you say yes to this option, support will be included for the
- built-in I2C interface on the MPC107/Tsi107/MPC8240/MPC8245 and
- MPC85xx/MPC8641 family processors. The driver may also work on 52xx
- family processors, though interrupts are known not to work.
+ built-in I2C interface on the MPC107, Tsi107, MPC512x, MPC52xx,
+ MPC8240, MPC8245, MPC83xx, MPC85xx and MPC8641 family processors.
This driver can also be built as a module. If so, the module
will be called i2c-mpc.
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 275ebe6..1af0730 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -31,6 +31,9 @@
#define DRV_NAME mpc-i2c
+#define MPC_I2C_CLOCK_SAFE 0
For clarity, I think this define should also be used when checking for the
condition (instead of using !clock).
+#define MPC_I2C_CLOCK_PRESERVE (~0U)
+
#define MPC_I2C_FDR 0x04
#define MPC_I2C_CR0x08
#define MPC_I2C_SR0x0c
@@ -67,9 +70,8 @@ struct mpc_i2c_divider {
};
struct mpc_i2c_data {
- void (*setclock)(struct device_node *node,
- struct mpc_i2c *i2c,
- u32 clock, u32 prescaler);
+ void (*setup)(struct device_node *node, struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler);
u32 prescaler;
};
@@ -164,7 +166,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned
timeout, int writing)
return 0;
}
-#ifdef CONFIG_PPC_MPC52xx
+#if defined(CONFIG_PPC_MPC52xx) || defined(CONFIG_PPC_MPC512x)
static const struct __devinitdata mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
{20, 0x20}, {22, 0x21}, {24, 0x22}, {26, 0x23},
{28, 0x24}, {30, 0x01}, {32, 0x25}, {34, 0x02},
@@ -216,12 +218,18 @@ static int __devinit mpc_i2c_get_fdr_52xx(struct
device_node *node, u32 clock,
return div ? (int)div-fdr : -EINVAL;
}
-static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
- struct mpc_i2c *i2c,
- u32 clock, u32 prescaler)
+static void __devinit mpc_i2c_setup_52xx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
{
int ret, fdr;
+ if (clock == MPC_I2C_CLOCK_PRESERVE) {
+ dev_dbg(i2c-dev, using fdr %d\n,
+ readb(i2c-base + MPC_I2C_FDR));
+ return;
+ }
+
ret = mpc_i2c_get_fdr_52xx(node, clock, prescaler);
fdr = (ret = 0) ? ret : 0x3f; /* backward compatibility */
@@ -230,13 +238,49 @@ static void __devinit mpc_i2c_setclock_52xx(struct
device_node *node,
if (ret = 0)
dev_info(i2c-dev, clock %d Hz (fdr=%d)\n, clock, fdr);
}
-#else /* !CONFIG_PPC_MPC52xx */
-static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
- struct mpc_i2c *i2c,
- u32 clock, u32 prescaler)
+#else /* !(CONFIG_PPC_MPC52xx || CONFIG_PPC_MPC512x) */
+static void __devinit mpc_i2c_setup_52xx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
+{
+}
+#endif /* CONFIG_PPC_MPC52xx || CONFIG_PPC_MPC512x */
+
+#ifdef CONFIG_PPC_MPC512x
+static void __devinit mpc_i2c_setup_512x(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
+{
+ struct device_node *node_ctrl;
+ void __iomem *ctrl;
+ const u32 *pval;
+
Re: [PATCHv3 2/2] powerpc: implement arch_scale_smt_power for Power7
Gabriel Paubert wrote: On Thu, Jan 28, 2010 at 05:20:55PM -0600, Joel Schopp wrote: On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads there is performance benefit to idling the higher numbered threads in the core. Really 2, 3, or 4? When you have 4 idle threads out of 4, performance becomes a minor concern, no? ;-) Gabriel Yes, but going from 4 idle to 3 idle you want to keep the slanted weights. If you ignored 4 you'd place wrong and then correct it after the fact. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 3/3] powerpc: doc/dts-bindings: update doc of FSL I2C bindings
On Thu, Jan 28, 2010 at 02:25:41PM +0100, Wolfgang Grandegger wrote: From: Wolfgang Grandegger w...@denx.de This patch adds the MPC5121 to the list of supported devices, enhances the doc of the clock-frequency property and removes the obsolete cell-index property from the example nodes. Furthermore and example for the MPC5121 has been added. Signed-off-by: Wolfgang Grandegger w...@denx.de Reviewed-by: Wolfram Sang w.s...@pengutronix.de -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv3 2/2] powerpc: implement arch_scale_smt_power for Power7
That said, I'm still not entirely convinced I like this usage of cpupower, its supposed to be a normalization scale for load-balancing, not a placement hook. Even if you do a placement hook you'll need to address it in the load balancing as well. Consider a single 4 thread SMT core with 4 running tasks. If 2 of them exit the remaining 2 will need to be load balanced within the core in a way that takes into account the dynamic nature of the thread power. This patch does that. I'd be much happier with a SD_GROUP_ORDER or something like that, that works together with SD_PREFER_SIBLING to pack active tasks to cpus in ascending group order. I don't see this load-balancing patch as mutually exclusive with a patch to fix placement. But even if it is a mutually exclusive solution there is no reason we can't fix things now with this patch and then later take it out when it's fixed another way. This patch series is straightforward, non-intrusive, and without it the scheduler is broken on this processor. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv3 2/2] powerpc: implement arch_scale_smt_power for Power7
Benjamin Herrenschmidt wrote: On Thu, 2010-01-28 at 17:24 -0600, Joel Schopp wrote: On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads there is performance benefit to idling the higher numbered threads in the core. This patch implements arch_scale_smt_power to dynamically update smt thread power in these idle cases in order to prefer threads 0,1 over threads 2,3 within a core. Almost there :-) Joel, Peter, can you help me figure something out tho ? On machine that don't have SMT, I would like to avoid calling arch_scale_smt_power() at all if possible (in addition to not compiling it in if SMT is not enabled in .config). Now, I must say I'm utterly confused by how the domains are setup and I haven't quite managed to sort it out... it looks to me that SD_SHARE_CPUPOWER is always going to be set on all CPUs when the config option is set (though each CPU will have its own domain) or am I misguided ? IE. Is there any sense in having at least a fast exit path out of arch_scale_smt_power() for non-SMT CPUs ? Joel, can you look at compiling it out when SMT is not set ? We don't want to bloat SMP kernels for 32-bit non-SMT embedded platforms. I can wrap the powerpc definition of arch_scale_smt in an #ifdef, if it's not there the scheduler uses the default, which is the same as it uses if SMT isn't compiled. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: i2c_powermac: Kernel access of bad area
Ben, what about applying this patch of mine, as Christian reported it
fixed his oops?
Sure. I never quite know with i2c which ones you will apply directly and
which ones you want to go through my tree :-)
Hopefully they should still be referened on patchwork, I'll dig there
and pick them up.
Cheers,
Ben.
However, the Badness remains when I try to modprobe i2c-powermac again:
[ 442.148222] PowerMac i2c bus pmu 2 registered
[ 442.148792] PowerMac i2c bus pmu 1 registered
[ 442.149299] PowerMac i2c bus mac-io 0 registered
[ 442.163573] adt746x: ADT7467 initializing
[ 442.170072] adt746x: Lowering max temperatures from 73, 80, 109 to 67,
47, 67
[ 442.176559] PowerMac i2c bus uni-n 1 registered
[ 442.227115] sysfs: cannot create duplicate filename '/devices/ams'
[ 442.227697] [ cut here ]
[ 442.228176] Badness at fs/sysfs/dir.c:487
[ 442.228642] NIP: c00eb71c LR: c00eb71c CTR:
[ 442.229117] REGS: eea0fa50 TRAP: 0700 Not tainted (2.6.33-rc3)
[ 442.229592] MSR: 00029032 EE,ME,CE,IR,DR CR: 42008444 XER:
[ 442.230151] TASK = eea1[2821] 'modprobe' THREAD: eea0e000
[ 442.230191] GPR00: c00eb71c eea0fb00 eea1 004c 64c6
[ 442.230758] GPR08: efa71740 c03e 64c6 44008428
10020390 100e 100df49c
[ 442.231326] GPR16: 100b54c0 100df49c 100ddd20 1018fb08 100b5340
c03e674c c03e6720 c03ea044
[ 442.231902] GPR24: 24008422 ffea eea0fb58 ef0e9000
ef0e9000 ef0a9ea0 ffef
[ 442.233187] NIP [c00eb71c] sysfs_add_one+0x94/0xc0
[ 442.233695] LR [c00eb71c] sysfs_add_one+0x94/0xc0
[ 442.234363] Call Trace:
I've put the whole dmesg on:
http://nerdbynature.de/bits/2.6.33-rc2/i2c_powermac/r1/
Hmm. Looks like a different but somewhat similar problem in the ams
driver: some code that is in ams_exit() (the module exit code) should
instead be called when the device (not module) is removed. It probably
doesn't make much of a difference in the PMU case, but in the I2C case
it does matter.
The following, totally untested patch may fix it. I make no guarantee
that my code isn't racy though, I'm not familiar enough with the ams
driver code to tell for sure.
---
drivers/hwmon/ams/ams-core.c | 11 +++
drivers/hwmon/ams/ams-i2c.c |2 ++
drivers/hwmon/ams/ams-pmu.c |2 ++
drivers/hwmon/ams/ams.h |1 +
4 files changed, 12 insertions(+), 4 deletions(-)
--- linux-2.6.33-rc3.orig/drivers/hwmon/ams/ams-core.c 2009-06-10
05:05:27.0 +0200
+++ linux-2.6.33-rc3/drivers/hwmon/ams/ams-core.c 2010-01-07
17:14:25.0 +0100
@@ -213,7 +213,7 @@ int __init ams_init(void)
return -ENODEV;
}
-void ams_exit(void)
+void ams_sensor_detach(void)
{
/* Remove input device */
ams_input_exit();
@@ -221,9 +221,6 @@ void ams_exit(void)
/* Remove attributes */
device_remove_file(ams_info.of_dev-dev, dev_attr_current);
- /* Shut down implementation */
- ams_info.exit();
-
/* Flush interrupt worker
*
* We do this after ams_info.exit(), because an interrupt might
@@ -239,6 +236,12 @@ void ams_exit(void)
pmf_unregister_irq_client(ams_freefall_client);
}
+static void __exit ams_exit(void)
+{
+ /* Shut down implementation */
+ ams_info.exit();
+}
+
MODULE_AUTHOR(Stelian Pop, Michael Hanselmann);
MODULE_DESCRIPTION(Apple Motion Sensor driver);
MODULE_LICENSE(GPL);
--- linux-2.6.33-rc3.orig/drivers/hwmon/ams/ams-i2c.c 2009-06-10
05:05:27.0 +0200
+++ linux-2.6.33-rc3/drivers/hwmon/ams/ams-i2c.c2010-01-07
17:12:46.0 +0100
@@ -238,6 +238,8 @@ static int ams_i2c_probe(struct i2c_clie
static int ams_i2c_remove(struct i2c_client *client)
{
if (ams_info.has_device) {
+ ams_sensor_detach();
+
/* Disable interrupts */
ams_i2c_set_irq(AMS_IRQ_ALL, 0);
--- linux-2.6.33-rc3.orig/drivers/hwmon/ams/ams-pmu.c 2009-06-10
05:05:27.0 +0200
+++ linux-2.6.33-rc3/drivers/hwmon/ams/ams-pmu.c2010-01-07
17:13:47.0 +0100
@@ -133,6 +133,8 @@ static void ams_pmu_get_xyz(s8 *x, s8 *y
static void ams_pmu_exit(void)
{
+ ams_sensor_detach();
+
/* Disable interrupts */
ams_pmu_set_irq(AMS_IRQ_ALL, 0);
--- linux-2.6.33-rc3.orig/drivers/hwmon/ams/ams.h 2009-06-10
05:05:27.0 +0200
+++ linux-2.6.33-rc3/drivers/hwmon/ams/ams.h2010-01-07
17:11:43.0 +0100
@@ -61,6 +61,7 @@ extern struct ams ams_info;
extern void ams_sensors(s8 *x, s8 *y, s8 *z);
extern int ams_sensor_attach(void);
+extern void ams_sensor_detach(void);
extern int ams_pmu_init(struct device_node *np);
extern int ams_i2c_init(struct device_node *np);
Christian, did
Re: [PATCH]: powerpc: Fix build breakage due to incorrect location of autoconf.h
On Thu, 28 Jan 2010 09:52:41 +0100 Joakim Tjernlund joakim.tjernl...@transmode.se wrote: Commit 6846ee5ca68d81e6baccf0d56221d7a00c1be18b made the new optimized inflate only available on arch's that define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS. This will again enable the optimization for all arch's by by defining our own endian independent version of unaligned access. As an added bonus, arch's that define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS do a plain load instead. Given that we're at -rc5, that changelog says to me this is a 2.6.34 patch. If that is wrong, please tell me why. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Add a new platform for maple so a different link address can be set
From: Corey Minyard cminy...@mvista.com The maple platform failed to load because it's firmware could not take a link address of 0x400. A new platform type with a link address of 0x40 had to be created for the maple. Signed-off-by: Corey Minyard cminy...@mvista.com --- Without this patch the firmware loader says it is unable to parse the ELF header and dies. This patch lets 2.6.31 boot without issue. At the current head of k.org git, at least with an NFS mount, I'm getting: Kernel panic - not syncing: No init found So I'm not sure what the deal is there, but this patch is still required to get the firmware to load the kernel. Index: linux-2.6.31/arch/powerpc/boot/wrapper === --- linux-2.6.31.orig/arch/powerpc/boot/wrapper +++ linux-2.6.31/arch/powerpc/boot/wrapper @@ -145,6 +145,10 @@ pseries) platformo=$object/of.o link_address='0x400' ;; +maple) +platformo=$object/of.o +link_address='0x40' +;; pmac|chrp) platformo=$object/of.o ;; @@ -313,7 +319,7 @@ fi # post-processing needed for some platforms case $platform in -pseries|chrp) +pseries|chrp|maple) $objbin/addnote $ofile ;; coff) Index: linux-2.6.31/arch/powerpc/boot/Makefile === --- linux-2.6.31.orig/arch/powerpc/boot/Makefile +++ linux-2.6.31/arch/powerpc/boot/Makefile @@ -167,7 +167,7 @@ quiet_cmd_wrap = WRAP$@ $(if $3, -s $3)$(if $4, -d $4)$(if $5, -i $5) vmlinux image-$(CONFIG_PPC_PSERIES)+= zImage.pseries -image-$(CONFIG_PPC_MAPLE) += zImage.pseries +image-$(CONFIG_PPC_MAPLE) += zImage.maple image-$(CONFIG_PPC_IBM_CELL_BLADE) += zImage.pseries image-$(CONFIG_PPC_PS3)+= dtbImage.ps3 image-$(CONFIG_PPC_CELLEB) += zImage.pseries @@ -346,7 +346,7 @@ install: $(CONFIGURE) $(addprefix $(obj) clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \ zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \ zImage.iseries zImage.miboot zImage.pmac zImage.pseries \ - simpleImage.* otheros.bld *.dtb + zImage.maple simpleImage.* otheros.bld *.dtb # clean up files cached by wrapper clean-kernel := vmlinux.strip vmlinux.bin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Add DMA mask to MPSC serial and network and UART device to serial
From: Corey Minyard cminy...@mvista.com
The MPSC drivers that use DMA need to set coherent_dma_mask to allow
dma_alloc_xxx routines to work properly. Also, the mpsc serial driver
needed to set pi-port.dev to register properly. With these fixes,
the MPSC drivers seem to work again.
Signed-off-by: Corey Minyard cminy...@mvista.com
---
I'm not really sure about where to set the coherent_dma_mask, it seems
like a more general place would be better but I couldn't find it.
Without these, the console stops working after the switchover and
the network driver fails to allocate buffers. With these, my board
boots up and works fine.
Index: linux-2.6.31/drivers/serial/mpsc.c
===
--- linux-2.6.31.orig/drivers/serial/mpsc.c
+++ linux-2.6.31/drivers/serial/mpsc.c
@@ -2071,6 +2071,9 @@ static int mpsc_drv_probe(struct platfor
if (!(rc = mpsc_drv_map_regs(pi, dev))) {
mpsc_drv_get_platform_data(pi, dev, dev-id);
+ dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ pi-port.dev = dev-dev;
+
if (!(rc = mpsc_make_ready(pi))) {
spin_lock_init(pi-tx_lock);
if (!(rc = uart_add_one_port(mpsc_reg,
Index: linux-2.6.31/drivers/net/mv643xx_eth.c
===
--- linux-2.6.31.orig/drivers/net/mv643xx_eth.c
+++ linux-2.6.31/drivers/net/mv643xx_eth.c
@@ -2916,7 +2916,7 @@ static int mv643xx_eth_probe(struct plat
mp-shared = platform_get_drvdata(pd-shared);
mp-base = mp-shared-base + 0x0400 + (pd-port_number 10);
mp-port_num = pd-port_number;
-
+ pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
mp-dev = dev;
set_params(mp, pd);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: i2c_powermac: Kernel access of bad area
On Fri, 29 Jan 2010 at 09:18, Jean Delvare wrote: Christian, did you ever test this second patch of mine? If you did, what was the outcome? Sorry, I must've missed that 2nd patch of yours. I'll test this now and report back. Thanks, Christian. -- BOFH excuse #112: The monitor is plugged into the serial port ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
