[PATCH v4] create modalias file in sysfs for bus of_platform
Create /sys/bus/of_platform/devices/*/modalias file to allow autoloading
of modules. modalias files are already present for many other bus types.
Signed-off-by: Olaf Hering [EMAIL PROTECTED]
---
drivers/of/device.c | 33 ++---
drivers/of/platform.c |3 +++
2 files changed, 21 insertions(+), 15 deletions(-)
Index: linux-2.6/drivers/of/device.c
===
--- linux-2.6.orig/drivers/of/device.c
+++ linux-2.6/drivers/of/device.c
@@ -77,7 +77,7 @@ void of_dev_put(struct of_device *dev)
}
EXPORT_SYMBOL(of_dev_put);
-static ssize_t dev_show_devspec(struct device *dev,
+static ssize_t devspec_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct of_device *ofdev;
@@ -86,7 +86,22 @@ static ssize_t dev_show_devspec(struct d
return sprintf(buf, %s, ofdev-node-full_name);
}
-static DEVICE_ATTR(devspec, S_IRUGO, dev_show_devspec, NULL);
+static ssize_t modalias_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ ssize_t len;
+
+ len = of_device_get_modalias(to_of_device(dev), buf, PAGE_SIZE - 2);
+ buf[len] = '\n';
+ buf[len+1] = 0;
+ return len+1;
+}
+
+struct device_attribute of_platform_device_attrs[] = {
+ __ATTR_RO(devspec),
+ __ATTR_RO(modalias),
+ __ATTR_NULL
+};
/**
* of_release_dev - free an of device structure when all users of it are
finished.
@@ -107,25 +122,13 @@ EXPORT_SYMBOL(of_release_dev);
int of_device_register(struct of_device *ofdev)
{
- int rc;
-
BUG_ON(ofdev-node == NULL);
-
- rc = device_register(ofdev-dev);
- if (rc)
- return rc;
-
- rc = device_create_file(ofdev-dev, dev_attr_devspec);
- if (rc)
- device_unregister(ofdev-dev);
-
- return rc;
+ return device_register(ofdev-dev);
}
EXPORT_SYMBOL(of_device_register);
void of_device_unregister(struct of_device *ofdev)
{
- device_remove_file(ofdev-dev, dev_attr_devspec);
device_unregister(ofdev-dev);
}
EXPORT_SYMBOL(of_device_unregister);
Index: linux-2.6/drivers/of/platform.c
===
--- linux-2.6.orig/drivers/of/platform.c
+++ linux-2.6/drivers/of/platform.c
@@ -17,6 +17,8 @@
#include linux/of_device.h
#include linux/of_platform.h
+extern struct device_attribute of_platform_device_attrs[];
+
static int of_platform_bus_match(struct device *dev, struct device_driver *drv)
{
struct of_device *of_dev = to_of_device(dev);
@@ -93,6 +95,7 @@ int of_bus_type_init(struct bus_type *bu
bus-remove = of_platform_device_remove;
bus-suspend = of_platform_device_suspend;
bus-resume = of_platform_device_resume;
+ bus-dev_attrs = of_platform_device_attrs;
return bus_register(bus);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] windfarm: add PowerMac 12,1 support
From: Étienne Bersac [EMAIL PROTECTED]
Implement a new driver named windfarm_pm121 which drive fans on PowerMac
12,1 machine : iMac G5 iSight (rev C) 17 and 20. It's based on
windfarm_pm81 driver from Benjamin Herrenschmidt.
Signed-off-by: Étienne Bersac [EMAIL PROTECTED]
---
Implement fan control for PowerMac 12,1 machines. This needs update to
windfarm_lm75 and windfarm_max6690 sensors drivers in order to properly
match sensors by their location. The code is based on windfarm_pm81
driver, adapted to the complexity of PowerMac 12,1 : 4 system control
loops instead of one, per-control target correction and per-model
control rubber-banding.
All the data are copied from Darwin 8.10 AppleMacRISC4PE-185.0.0 module
as well as correction formula.
diff --git a/arch/powerpc/configs/g5_defconfig
b/arch/powerpc/configs/g5_defconfig
index 3673dd2..4c048b3 100644
--- a/arch/powerpc/configs/g5_defconfig
+++ b/arch/powerpc/configs/g5_defconfig
@@ -667,6 +667,7 @@ CONFIG_WINDFARM=y
CONFIG_WINDFARM_PM81=y
CONFIG_WINDFARM_PM91=y
CONFIG_WINDFARM_PM112=y
+CONFIG_WINDFARM_PM121=y
# CONFIG_PMAC_RACKMETER is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 77f50b6..2d028e6 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -234,6 +234,14 @@ config WINDFARM_PM112
which are the recent dual and quad G5 machines using the
970MP dual-core processor.
+config WINDFARM_PM121
+ tristate Support for thermal management on PowerMac12,1
+ depends on WINDFARM I2C PMAC_SMU
+ select I2C_POWERMAC
+ help
+ This driver provides thermal control for the PowerMac12,1
+ which is the iMac G5 (iSight) 970MP
+
config ANSLCD
tristate Support for ANS LCD display
depends on ADB_CUDA PPC_PMAC
diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile
index 2dfc3f4..e3132ef 100644
--- a/drivers/macintosh/Makefile
+++ b/drivers/macintosh/Makefile
@@ -42,4 +42,9 @@ obj-$(CONFIG_WINDFARM_PM112) += windfarm_pm112.o
windfarm_smu_sat.o \
windfarm_smu_sensors.o \
windfarm_max6690_sensor.o \
windfarm_lm75_sensor.o windfarm_pid.o
+obj-$(CONFIG_WINDFARM_PM121) += windfarm_pm121.o windfarm_smu_sat.o \
+ windfarm_smu_controls.o \
+ windfarm_smu_sensors.o \
+ windfarm_max6690_sensor.o \
+ windfarm_lm75_sensor.o windfarm_pid.o
obj-$(CONFIG_PMAC_RACKMETER) += rack-meter.o
diff --git a/drivers/macintosh/windfarm_lm75_sensor.c
b/drivers/macintosh/windfarm_lm75_sensor.c
index 7e10c3a..b92b959 100644
--- a/drivers/macintosh/windfarm_lm75_sensor.c
+++ b/drivers/macintosh/windfarm_lm75_sensor.c
@@ -127,6 +127,12 @@ static struct wf_lm75_sensor *wf_lm75_create(struct
i2c_adapter *adapter,
*/
if (!strcmp(loc, Hard drive) || !strcmp(loc, DRIVE BAY))
lm-sens.name = hd-temp;
+ else if (!strcmp(loc, Incoming Air Temp))
+ lm-sens.name = incoming-air-temp;
+ else if (!strcmp(loc, ODD Temp))
+ lm-sens.name = optical-drive-temp;
+ else if (!strcmp(loc, HD Temp))
+ lm-sens.name = hard-drive-temp;
else
goto fail;
diff --git a/drivers/macintosh/windfarm_max6690_sensor.c
b/drivers/macintosh/windfarm_max6690_sensor.c
index 5f03aab..e207a90 100644
--- a/drivers/macintosh/windfarm_max6690_sensor.c
+++ b/drivers/macintosh/windfarm_max6690_sensor.c
@@ -77,18 +77,28 @@ static struct wf_sensor_ops wf_max6690_ops = {
.owner = THIS_MODULE,
};
-static void wf_max6690_create(struct i2c_adapter *adapter, u8 addr)
+static void wf_max6690_create(struct i2c_adapter *adapter, u8 addr,
+ const char *loc)
{
struct wf_6690_sensor *max;
- char *name = backside-temp;
+ char *name;
max = kzalloc(sizeof(struct wf_6690_sensor), GFP_KERNEL);
if (max == NULL) {
printk(KERN_ERR windfarm: Couldn't create MAX6690 sensor %s:
- no memory\n, name);
+ no memory\n, loc);
return;
}
+ if (!strcmp(loc, BACKSIDE))
+ name = backside-temp;
+ else if (!strcmp(loc, NB Ambient))
+ name = north-bridge-temp;
+ else if (!strcmp(loc, GPU Ambient))
+ name = gpu-temp;
+ else
+ goto fail;
+
max-sens.ops = wf_max6690_ops;
max-sens.name = name;
max-i2c.addr = addr 1;
@@ -138,9 +148,7 @@ static int wf_max6690_attach(struct i2c_adapter *adapter)
if (loc == NULL || addr == 0)
continue;
printk(found max6690, loc=%s addr=0x%02x\n, loc, addr);
-
[BUILD FAILURE]2.6.24-git{1,2} kernel powerpc linkage failure
Hi, The 2.6.24-git2 kernel build fails on the power boxes with following build failure LD init/built-in.o LD .tmp_vmlinux1 arch/powerpc/kernel/built-in.o: In function `fphalf': arch/powerpc/kernel/vector.S:(.toc+0x1428): undefined reference to `devices_subsys' make: *** [.tmp_vmlinux1] Error 1 This built-failure was seen in the mm broken-out-2007-11-06-02-32, I have tested the patch posted to lkml at http://lkml.org/lkml/2007/11/6/208 fixes this issue. -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to for-2.6.25/master branches of powerpc.git
On Jan 26, 2008, at 12:16 AM, Paul Mackerras wrote: This includes commits pulled from Josh Boyer, Kumar Gala, Grant Likely, and Olof Johansson. I reverted the Fake NUMA emulation for PowerPC commit because it changed behaviour even when the fake numa command-line option wasn't given. I'll be asking Linus to pull within the next few days, so please remind me about anything else that should go in 2.6.25. Paul. I've got a bunch of patches queued up in my tree that I'll ask you to pull in the next day or so. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] FIXED_MII_100_FDX
On Jan 26, 2008, at 12:54 AM, Sean MacLennan wrote: On the last git pull, FIXED_MII_100_FDX was removed from the phy Kconfig, but the Kconfig for CPMAC still tried to select it. Cheers, Sean Signed-off-by: Sean MacLennan [EMAIL PROTECTED] --- diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 9af05a2..297a4b5 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1710,7 +1710,6 @@ config CPMAC depends on NET_ETHERNET EXPERIMENTAL AR7 select PHYLIB select FIXED_PHY - select FIXED_MII_100_FDX help TI AR7 CPMAC Ethernet support This patch isn't sufficient. AntonV has posted a proper fix that we need Jeff to pick up. http://ozlabs.org/pipermail/linuxppc-dev/2008-January/050330.html - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
On Fri, Jan 25, 2008 at 09:50:00AM +0100, Peter Zijlstra wrote: On Fri, 2008-01-25 at 18:25 +1100, Benjamin Herrenschmidt wrote: On Fri, 2008-01-25 at 18:03 +1100, Benjamin Herrenschmidt wrote: On Fri, 2008-01-25 at 17:54 +1100, Benjamin Herrenschmidt wrote: Here, I do the test of running 4 times the repro-case provided by Michel with nice 19 and a dd eating CPU with nice 0. Without this option, I get the dd at 100% and the nice 19 shells down below it with whatever is left of the CPUs. With this option, dd gets about 50% of one CPU and the niced processes still get most of the time. Ben, I presume you had CONFIG_FAIR_USER_SCHED turned on too? Also were the dd process and the niced processes running under different user ids? If so, that is expected behavior, that we divide CPU equally among users first and then among the processes within each user. FYI. This is a 4 way G5 (ppc64) I also tested responsiveness of X running with or without that option and with niced CPU eaters in the background (still 4 of them, one per CPU), and I can confirm Michel observations, it gets very sluggish (maybe not -as- bad as his but still pretty annoying) with the fair group scheduler enabled. When CONFIG_FAIR_GROUP_SCHED (and CONFIG_FAIR_USER_SCHED) is not enabled, X will be given higher priority for running on CPU when compared to other niced tasks. When the above options are turned on, X (running under root uid) would be given lesser priority to run when compared to other niced tasks running user different uids. Hence I expect some drop in interactivity-experience with FAIR_GROUP_SCHED on. Can you pls let me know if any of these makes a difference: 1. Run niced tasks as root. This would bring X and niced tasks in the same scheduler group domain, which would give X much more CPU power when compared to niced tasks. 2. Keep the niced tasks running under a non-root uid, but increase root users cpu share. # echo 8192 /sys/kernel/uids/0/cpu_share This should bump up root user's priority for running on CPU and also give a better desktop experience. Here, X is running with nice=0 Curious, sounds like an issue with the group load balancer, vatsa, any ideas? The group scheduler's SMP-load balance in 2.6.24 is not the best it could be. sched-devel has a better load balancer, which I am presuming will go into 2.6.25 soon. In this case, I suspect that's not the issue. If X and the niced processes are running under different uids, this (niced processes getting more cpu power) is on expected lines. Will wait for Ben to confirm this. -- Regards, vatsa ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote: Ben, I presume you had CONFIG_FAIR_USER_SCHED turned on too? Yes. It seems to be automatically turned on whenever FAIR_GROUP is turned on. Considering how bad the behaviour is for a standard desktop configuration, I'd be tempted to say to change it to default n. If I recall, CONFIG_FAIR_USER_SCHED was turned on as default at the same time as CONFIG_FAIR_GROUP_SCHED as a means to flesh out fair-group scheduler bugs. Also at that time, CONFIG_FAIR_CGROUP_SCHED was not available in mainline as the second option for grouping tasks. Going forward, I am of the favor to turn off CONFIG_FAIR_USER_SCHED by default, but turning on CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED on by default. That way all tasks belong to same group by default unless admin explicitly creates groups and moves around tasks between them. This will be good for desktop user who may choose to keep all tasks in one group by default, but also giving him/her the flexibility of exploiting fair-group scheduler by creating custom task groups and adjusting their cpu shares (for ex: kernel compile group or multi-media group). If someone still needs the fair-user scheduler (as provided by CONFIG_FAIR_USER_SCHED), they can still get it with CONFIG_FAIR_CGROUP_SCHED by running a daemon [1] that dynamically moves around tasks into different task group based on userid. Ingo/Peter, what do you think? Also were the dd process and the niced processes running under different user ids? If so, that is expected behavior, that we divide CPU equally among users first and then among the processes within each user. They were different users and that behaviour seems to be a very stupid default behaviour for a desktop machine. Take this situation: - X running as root - User apps running as user - Background crap (indexing daemons etc...) running as their own user or nobody Unless you can get some kind of grouping based on user sessions including suid binaries, X etc... I think this shouldn't default y in Kconfig. yes, see above. Not that it seems that Michel reported far worse behaviour than what I saw, including pretty hickup'ish X behaviour even without the fair group scheduler compared to 2.6.23. It might be because he's running X niced to -1 (I leave X at 0 and let the scheduler deal with it in general) though. Hmm ..with X niced to -1, it should get more cpu power leading to a better desktop experience. Michel, You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 was the cause for this bad behavior. Do you see behavior change (from good-bad) immediately after applying that patch during your bisect process? 2. Keep the niced tasks running under a non-root uid, but increase root users cpu share. # echo 8192 /sys/kernel/uids/0/cpu_share This should bump up root user's priority for running on CPU and also give a better desktop experience. Allright, that's something that might need to be set by default by the kernel ... as it will take some time to have knowledge of those knobs to percolate to distros. Too bad you can't do the opposite by default for nobody as there's no standard uid for it. The group scheduler's SMP-load balance in 2.6.24 is not the best it could be. sched-devel has a better load balancer, which I am presuming will go into 2.6.25 soon. In this case, I suspect that's not the issue. If X and the niced processes are running under different uids, this (niced processes getting more cpu power) is on expected lines. Will wait for Ben to confirm this. I would suggest turning the fair group scheduler to default n in stable for now. I would prefer to have CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you think is the desktop experience with that combination? Reference: 1. http://article.gmane.org/gmane.linux.kernel/553267 -- Regards, vatsa ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote: Ben, I presume you had CONFIG_FAIR_USER_SCHED turned on too? Yes. It seems to be automatically turned on whenever FAIR_GROUP is turned on. Considering how bad the behaviour is for a standard desktop configuration, I'd be tempted to say to change it to default n. If I recall, CONFIG_FAIR_USER_SCHED was turned on as default at the same time as CONFIG_FAIR_GROUP_SCHED as a means to flesh out fair-group scheduler bugs. Also at that time, CONFIG_FAIR_CGROUP_SCHED was not available in mainline as the second option for grouping tasks. Going forward, I am of the favor to turn off CONFIG_FAIR_USER_SCHED by default, but turning on CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED on by default. That way all tasks belong to same group by default unless admin explicitly creates groups and moves around tasks between them. This will be good for desktop user who may choose to keep all tasks in one group by default, but also giving him/her the flexibility of exploiting fair-group scheduler by creating custom task groups and adjusting their cpu shares (for ex: kernel compile group or multi-media group). If someone still needs the fair-user scheduler (as provided by CONFIG_FAIR_USER_SCHED), they can still get it with CONFIG_FAIR_CGROUP_SCHED by running a daemon [1] that dynamically moves around tasks into different task group based on userid. Ingo/Peter, what do you think? Also were the dd process and the niced processes running under different user ids? If so, that is expected behavior, that we divide CPU equally among users first and then among the processes within each user. They were different users and that behaviour seems to be a very stupid default behaviour for a desktop machine. Take this situation: - X running as root - User apps running as user - Background crap (indexing daemons etc...) running as their own user or nobody Unless you can get some kind of grouping based on user sessions including suid binaries, X etc... I think this shouldn't default y in Kconfig. yes, see above. Not that it seems that Michel reported far worse behaviour than what I saw, including pretty hickup'ish X behaviour even without the fair group scheduler compared to 2.6.23. It might be because he's running X niced to -1 (I leave X at 0 and let the scheduler deal with it in general) though. Hmm ..with X niced to -1, it should get more cpu power leading to a better desktop experience. Michel, You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 was the cause for this bad behavior. Do you see behavior change (from good-bad) immediately after applying that patch during your bisect process? 2. Keep the niced tasks running under a non-root uid, but increase root users cpu share. # echo 8192 /sys/kernel/uids/0/cpu_share This should bump up root user's priority for running on CPU and also give a better desktop experience. Allright, that's something that might need to be set by default by the kernel ... as it will take some time to have knowledge of those knobs to percolate to distros. Too bad you can't do the opposite by default for nobody as there's no standard uid for it. The group scheduler's SMP-load balance in 2.6.24 is not the best it could be. sched-devel has a better load balancer, which I am presuming will go into 2.6.25 soon. In this case, I suspect that's not the issue. If X and the niced processes are running under different uids, this (niced processes getting more cpu power) is on expected lines. Will wait for Ben to confirm this. I would suggest turning the fair group scheduler to default n in stable for now. I would prefer to have CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you think is the desktop experience with that combination? Reference: 1. http://article.gmane.org/gmane.linux.kernel/553267 -- Regards, vatsa ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
On Sat, Jan 26, 2008 at 04:15:52PM +1100, Benjamin Herrenschmidt wrote: Michel, You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 was the cause for this bad behavior. Do you see behavior change (from good-bad) immediately after applying that patch during your bisect process? Also Michel, double check your .config in both cases. And also Michel whether CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED gives more or less same desktop exp as !CONFIG_FAIR_GROUP_SCHED pls! I would prefer to have CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you think is the desktop experience with that combination? I'm going to give that a try but unfortunately, it will have to wait until I'm back from LCA in a bit more than a week. -- Regards, vatsa ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Reminder: removal of arch/ppc
Kumar Gala wrote: 4xx: EBONY I have an Ebony at hand, so if no one takes it, I'll give it a try to port it over. Regards, Zoltan HERPAI ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Reminder: removal of arch/ppc
On Sat, 26 Jan 2008 10:09:25 +0100 Zoltan HERPAI [EMAIL PROTECTED] wrote: Kumar Gala wrote: 4xx: EBONY I have an Ebony at hand, so if no one takes it, I'll give it a try to port it over. It's ported. It was the first 4xx board to be ported. Thanks for offering though! josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 063/196] kset: convert /sys/devices to use kset_create
On Fri, Jan 25, 2008 at 09:24:54PM -0800, Greg KH wrote: On Fri, Jan 25, 2008 at 09:40:55PM -0600, Olof Johansson wrote: On Thu, Jan 24, 2008 at 11:10:01PM -0800, Greg Kroah-Hartman wrote: Dynamically create the kset instead of declaring it statically. We also rename devices_subsys to devices_kset to catch all users of the variable. Guess what, you broke powerpc again! I did this ON PURPOSE!!! The linux-kernel archives hold the details, and I was told by the PPC64 IBM people that they would fix this properly for 2.6.25, and not to hold back on my changes. This has been known for many months now. Yeah, my bad. :( I thought this was new, but it was just not exposed by my scripts because of the EHEA build errors (they were actual compile errors, while this was a link error, so it never go this far). That's why I didn't see it in -rc8-mm1 and thought it was new. -extern struct kset devices_subsys; /* needed for vio_find_name() */ +extern struct kset *devices_kset; /* needed for vio_find_name() */ No, this just papers over the real problem here. For some reason, the vio code thinks it is acceptable to walk the whole device tree and match by a name and just assume that they got the correct device. You call this enterprise grade? :) You need to just put your device on a real bus, and then just walk the bus. That's the ONLY way you can guarantee the proper name will return what you want, and you get the pointer that you really think you are getting. Hmm, they are already on a bus. Odd, must be done like this for legacy reasons. [...] So no, I'm going to leave the build broken for this code, because that is what it really is. Please fix it correctly. Alright, I'll leave that to people who care about vio and can test the proper fix. After a quick glance it looks like it should be easy to use bus_find_device() for it instead. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE]2.6.24-git{1,2} kernel powerpc linkage failure
On Sat, Jan 26, 2008 at 06:53:31PM +0530, Kamalesh Babulal wrote: Hi, The 2.6.24-git2 kernel build fails on the power boxes with following build failure LD init/built-in.o LD .tmp_vmlinux1 arch/powerpc/kernel/built-in.o: In function `fphalf': arch/powerpc/kernel/vector.S:(.toc+0x1428): undefined reference to `devices_subsys' make: *** [.tmp_vmlinux1] Error 1 This built-failure was seen in the mm broken-out-2007-11-06-02-32, I have tested the patch posted to lkml at http://lkml.org/lkml/2007/11/6/208 fixes this issue. And that patch is wrong, see my post on lkml about this yesterday. Paul is working on a correct patch, and if I get some time this afternoon, I'll do one too. thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to for-2.6.25/master branches of powerpc.git
Paul, please pull the following mpc52xx changes. Also, I'd like to have the following patch picked up, but I'm a bit nervous about it. Kumar has said it looks good, but I'm still not 100% sure about eliminating the KBUILD_IMAGE and BOOTIMAGE variables. I *think* it's safe, but I'm not a build system expert. http://patchwork.ozlabs.org/linuxppc/patch?person=486id=16264 Cheers, g. The following changes since commit 55852bed57a97b08ab56028f1054d48d45de3aec: Paul Mackerras (1): Revert [POWERPC] Fake NUMA emulation for PowerPC are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.25 Grant Likely (6): [POWERPC] mpc52xx: clean up Kconfig [POWERPC] mpc5200: normalize compatible property bindings [POWERPC] mpc5200: make dts files conform to generic names recommended practice [POWERPC] Efika: prune fixups and make them more carefull [POWERPC] Add common clock setting routine mpc52xx_psc_set_clkdiv() [POWERPC] mpc52xx_psc_spi device driver must not touch port_config and cdm Paul Gortmaker (1): [POWERPC] mpc5200: add #address-cells and #size-cells to soc node. arch/powerpc/boot/dts/cm5200.dts | 60 +-- arch/powerpc/boot/dts/lite5200.dts | 96 +++-- arch/powerpc/boot/dts/lite5200b.dts | 93 +++- arch/powerpc/boot/dts/motionpro.dts | 68 +--- arch/powerpc/boot/dts/tqm5200.dts| 45 - arch/powerpc/boot/serial.c |2 +- arch/powerpc/kernel/prom_init.c | 149 ++ arch/powerpc/platforms/52xx/Kconfig | 41 +++- arch/powerpc/platforms/52xx/efika.c |3 + arch/powerpc/platforms/52xx/lite5200.c | 28 -- arch/powerpc/platforms/52xx/lite5200_pm.c|9 ++- arch/powerpc/platforms/52xx/mpc5200_simple.c |6 +- arch/powerpc/platforms/52xx/mpc52xx_common.c | 117 - arch/powerpc/platforms/52xx/mpc52xx_pci.c| 10 ++- arch/powerpc/platforms/52xx/mpc52xx_pic.c| 16 +++- arch/powerpc/platforms/52xx/mpc52xx_pm.c |9 ++- arch/powerpc/sysdev/bestcomm/bestcomm.c | 16 ++- arch/ppc/syslib/mpc52xx_setup.c | 36 ++ drivers/ata/pata_mpc52xx.c |6 +- drivers/net/fec_mpc52xx.c|6 +- drivers/net/fec_mpc52xx_phy.c|8 +- drivers/serial/mpc52xx_uart.c|4 +- drivers/spi/mpc52xx_psc_spi.c| 82 +- drivers/usb/host/ohci-ppc-of.c |2 + include/asm-powerpc/mpc52xx.h|9 +- 25 files changed, 478 insertions(+), 443 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix powerpc vio_find_name to not use devices_subsys
This fixes vio_find_name() in arch/powerpc/kernel/vio.c, which is
currently broken because it tries to use devices_subsys. That is bad
for two reasons: (1) it's doing (or trying to do) a scan of all
devices when it should only be scanning those on the vio bus, and
(2) devices_subsys was an internal symbol of the device system code
which was never meant for external use and has now gone away, and
thus the kernel fails to compile on pSeries.
The new version uses bus_find_device() on the vio bus (vio_bus_type).
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
Greg, do you want to send this to Linus or will I do that? Or do you
have a better version? :)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 19a5656..b179b7e 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -37,8 +37,6 @@
#include asm/iseries/hv_call_xm.h
#include asm/iseries/iommu.h
-extern struct kset devices_subsys; /* needed for vio_find_name() */
-
static struct bus_type vio_bus_type;
static struct vio_dev vio_bus_device = { /* fake parent device */
@@ -361,19 +359,23 @@ EXPORT_SYMBOL(vio_get_attribute);
#ifdef CONFIG_PPC_PSERIES
/* vio_find_name() - internal because only vio.c knows how we formatted the
* kobject name
- * XXX once vio_bus_type.devices is actually used as a kset in
- * drivers/base/bus.c, this function should be removed in favor of
- * device_find(kobj_name, vio_bus_type)
*/
-static struct vio_dev *vio_find_name(const char *kobj_name)
+static int name_cmp(struct device *dev, void *data)
+{
+ const char *name = data;
+
+ return !strcmp(name, dev-bus_id);
+}
+
+static struct vio_dev *vio_find_name(const char *name)
{
- struct kobject *found;
+ struct device *found;
- found = kset_find_obj(devices_subsys, kobj_name);
+ found = bus_find_device(vio_bus_type, NULL, (void *)name, name_cmp);
if (!found)
return NULL;
- return to_vio_dev(container_of(found, struct device, kobj));
+ return to_vio_dev(found);
}
/**
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to for-2.6.25/master branches of powerpc.git
On 1/26/08, Grant Likely [EMAIL PROTECTED] wrote: Grant Likely (6): [POWERPC] mpc52xx: clean up Kconfig [POWERPC] mpc5200: normalize compatible property bindings [POWERPC] mpc5200: make dts files conform to generic names recommended practice [POWERPC] Efika: prune fixups and make them more carefull [POWERPC] Add common clock setting routine mpc52xx_psc_set_clkdiv() [POWERPC] mpc52xx_psc_spi device driver must not touch port_config and cdm Does this fix these warnings... CC drivers/spi/mpc52xx_psc_spi.o drivers/spi/mpc52xx_psc_spi.c: In function 'mpc52xx_psc_spi_activate_cs': drivers/spi/mpc52xx_psc_spi.c:110: warning: passing argument 1 of 'in_be16' from incompatible pointer type drivers/spi/mpc52xx_psc_spi.c:116: warning: passing argument 1 of 'out_be16' from incompatible pointer type drivers/spi/mpc52xx_psc_spi.c: In function 'mpc52xx_psc_spi_port_config': drivers/spi/mpc52xx_psc_spi.c:417: warning: passing argument 1 of 'out_be16' from incompatible pointer type -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to for-2.6.25/master branches of powerpc.git
On Sat, 2008-01-26 at 17:16 +1100, Paul Mackerras wrote: This includes commits pulled from Josh Boyer, Kumar Gala, Grant Likely, and Olof Johansson. I reverted the Fake NUMA emulation for PowerPC commit because it changed behaviour even when the fake numa command-line option wasn't given. I'll be asking Linus to pull within the next few days, so please remind me about anything else that should go in 2.6.25. Can you grab these four assuming there's no objections in the meantime. http://patchwork.ozlabs.org/linuxppc/patch?q=ellermanid=16430 http://patchwork.ozlabs.org/linuxppc/patch?q=ellermanid=16433 http://patchwork.ozlabs.org/linuxppc/patch?q=ellermanid=16434 http://patchwork.ozlabs.org/linuxppc/patch?q=ellermanid=16437 cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix powerpc vio_find_name to not use devices_subsys
On Sun, Jan 27, 2008 at 11:45:30AM +1100, Paul Mackerras wrote: This fixes vio_find_name() in arch/powerpc/kernel/vio.c, which is currently broken because it tries to use devices_subsys. That is bad for two reasons: (1) it's doing (or trying to do) a scan of all devices when it should only be scanning those on the vio bus, and (2) devices_subsys was an internal symbol of the device system code which was never meant for external use and has now gone away, and thus the kernel fails to compile on pSeries. The new version uses bus_find_device() on the vio bus (vio_bus_type). Signed-off-by: Paul Mackerras [EMAIL PROTECTED] --- Greg, do you want to send this to Linus or will I do that? Or do you have a better version? :) I'll send it to him, with a minor change (I'm going to make this a core function, as others also use the same functionality, no need for everyone to re-invent the wheel all the time. I also have some other patches to send him to fix up the fall-out of these driver core changes :) thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 04/11] ps3fb: Inline macros that are used only once
On Fri, 25 Jan 2008 16:06:27 +0100 Geert Uytterhoeven [EMAIL PROTECTED] wrote: From: Geert Uytterhoeven [EMAIL PROTECTED] ps3fb: inline the X_OFF(), Y_OFF(), WIDTH(), HEIGHT(), and VP_OFF() macros, as they're used in one place only I think the term open-code would be more suitable here. inlining means make it an inline function. I'll update the changelog. -#define X_OFF(i) (ps3fb_res[i].xoff) /* left/right margin (pixel) */ -#define Y_OFF(i) (ps3fb_res[i].yoff) /* top/bottom margin (pixel) */ -#define WIDTH(i) (ps3fb_res[i].xres) /* width of FB */ -#define HEIGHT(i)(ps3fb_res[i].yres) /* height of FB */ #define BPP 4 /* number of bytes per pixel */ -/* Start of the virtual frame buffer (relative to fullscreen ) */ -#define VP_OFF(i)((WIDTH(i) * Y_OFF(i) + X_OFF(i)) * BPP) - static int ps3fb_mode; module_param(ps3fb_mode, int, 0); @@ -611,7 +604,10 @@ static int ps3fb_set_par(struct fb_info par-width = info-var.xres; par-height = info-var.yres; - offset = VP_OFF(i); + + /* Start of the virtual frame buffer (relative to fullscreen) */ + offset = ps3fb_res[i].yoff * ddr_line_length + ps3fb_res[i].xoff * BPP; + ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 00/11] ps3av/3fb patches for 2.6.25
On Fri, 25 Jan 2008 16:06:23 +0100 Geert Uytterhoeven [EMAIL PROTECTED] wrote: Hare are the ps3av/fb patches for 2.6.25: I would have to say: it's a bit late to be submitting things of this nature for 2.6.25. Given the mess everyone has made of everything there's little chance that I'll be able to do a 2.6.24-mm1 so this stuff basically goes into mainline without public testing. I don't think many people care much about ps3 so whatever. But if it were core code or a popular driver then I would probably slip this back to 2.6.26. We haven't heard from Tony in a while so I guess I'm fbdev maintainer again. Be afraid. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 09/11] ps3fb: Round up video modes
On Fri, 25 Jan 2008 16:06:32 +0100 Geert Uytterhoeven [EMAIL PROTECTED]
wrote:
static int ps3fb_cmp_mode(const struct fb_videomode *vmode,
const struct fb_var_screeninfo *var)
{
- /* resolution + black border must match a native resolution */
- if (vmode-left_margin + vmode-xres + vmode-right_margin !=
- var-left_margin + var-xres + var-right_margin ||
- vmode-upper_margin + vmode-yres + vmode-lower_margin !=
- var-upper_margin + var-yres + var-lower_margin)
+ long xres, yres, left_margin, right_margin, upper_margin, lower_margin;
+ long dx, dy;
I don't think these need to be longs? And they probably don't need to be
signed either.
If a switch to u32 improves the code any, it might be worth doing..
All the typecasting which this patch adds makes me wonder if the choice
of types requires a general revisit...
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
