Re: crash in init_ipic_sysfs on efika
On Sat, 2008-03-22 at 16:25 +0100, Sven Luther wrote: BTW, it was reported to me that the ethernet drivers don't get autoloaded by udev. Is this a failure of udev missing the of_plateform support, or a deficiency of the ethernet drivers ? As far as I know, they _are_ being loaded properly. Otherwise, the Fedora installer wouldn't work. -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: crash in init_ipic_sysfs on efika
On Sun, Mar 23, 2008 at 09:00:41AM +, David Woodhouse wrote: On Sat, 2008-03-22 at 16:25 +0100, Sven Luther wrote: BTW, it was reported to me that the ethernet drivers don't get autoloaded by udev. Is this a failure of udev missing the of_plateform support, or a deficiency of the ethernet drivers ? As far as I know, they _are_ being loaded properly. Otherwise, the Fedora installer wouldn't work. Yes, but you probably have the of_plateform udev patch, no ? Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: crash in init_ipic_sysfs on efika
On Sun, 2008-03-23 at 11:12 +0100, Sven Luther wrote: On Sun, Mar 23, 2008 at 09:00:41AM +, David Woodhouse wrote: On Sat, 2008-03-22 at 16:25 +0100, Sven Luther wrote: BTW, it was reported to me that the ethernet drivers don't get autoloaded by udev. Is this a failure of udev missing the of_plateform support, or a deficiency of the ethernet drivers ? As far as I know, they _are_ being loaded properly. Otherwise, the Fedora installer wouldn't work. Yes, but you probably have the of_plateform udev patch, no ? Not any more. That was merged a while ago, wasn't it? -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: crash in init_ipic_sysfs on efika
On Sun, Mar 23, 2008 at 10:13:12AM +, David Woodhouse wrote: On Sun, 2008-03-23 at 11:12 +0100, Sven Luther wrote: On Sun, Mar 23, 2008 at 09:00:41AM +, David Woodhouse wrote: On Sat, 2008-03-22 at 16:25 +0100, Sven Luther wrote: BTW, it was reported to me that the ethernet drivers don't get autoloaded by udev. Is this a failure of udev missing the of_plateform support, or a deficiency of the ethernet drivers ? As far as I know, they _are_ being loaded properly. Otherwise, the Fedora installer wouldn't work. Yes, but you probably have the of_plateform udev patch, no ? Not any more. That was merged a while ago, wasn't it? So, the only explanation would be if debian had a very outdated udev which does not include this patch. Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
DTC Patch Catch Up
Folks, I've applied the following patches from Gibson, in this order, to the DTC and pushed it out to git.jdl.com: dtc: Fix error reporting in push_input_file() dtc: Implement checks for the format of node and property names dtc: Fix indentation of fixup_phandle_references dtc: Strip redundant name properties dtc: Test and fix conversion to/from old dtb versions dtc: Use for_each_marker_of_type in asm_emit_data() dtc: Make -I dtb mode use fill_fullpaths() dtc: Make eval_literal() static dtc: Assorted improvements to test harness dtc: Testcases for input handling dtc: Make dtc_open_file() die() if unable to open requested file dtc: Remove ugly include stack abuse dtc: Abolish asize field of struct data dtc: Add some documentation for the dts formta dtc: Cleanup \nnn and \xNN string escape handling dtc: Change exit code for usage message Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] scanlog_init cleanup, minor fixes
scanlog_init() could use some love.
* properly return -ENODEV if this system doesn't support scan-log-dump
* don't printk if scan-log-dump not present; only older systems have it
* convert from create_proc_entry() to preferred proc_create()
* allocate zeroed data buffer
* fix potential memory leak of ent-data on failed create_proc_entry()
* simplify control flow
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
(not urgent, please consider for 2.6.26)
arch/powerpc/platforms/pseries/scanlog.c | 37 ++---
1 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/scanlog.c
b/arch/powerpc/platforms/pseries/scanlog.c
index 8e1ef16..e5b0ea8 100644
--- a/arch/powerpc/platforms/pseries/scanlog.c
+++ b/arch/powerpc/platforms/pseries/scanlog.c
@@ -195,31 +195,30 @@ const struct file_operations scanlog_fops = {
static int __init scanlog_init(void)
{
struct proc_dir_entry *ent;
+ void *data;
+ int err = -ENOMEM;
ibm_scan_log_dump = rtas_token(ibm,scan-log-dump);
- if (ibm_scan_log_dump == RTAS_UNKNOWN_SERVICE) {
- printk(KERN_ERR scan-log-dump not implemented on this
system\n);
- return -EIO;
- }
+ if (ibm_scan_log_dump == RTAS_UNKNOWN_SERVICE)
+ return -ENODEV;
-ent = create_proc_entry(ppc64/rtas/scan-log-dump, S_IRUSR, NULL);
- if (ent) {
- ent-proc_fops = scanlog_fops;
- /* Ideally we could allocate a buffer 4G */
- ent-data = kmalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
- if (!ent-data) {
- printk(KERN_ERR Failed to allocate a buffer\n);
- remove_proc_entry(scan-log-dump, ent-parent);
- return -ENOMEM;
- }
- ((unsigned int *)ent-data)[0] = 0;
- } else {
- printk(KERN_ERR Failed to create ppc64/scan-log-dump proc
entry\n);
- return -EIO;
- }
+ /* Ideally we could allocate a buffer 4G */
+ data = kzalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
+ if (!data)
+ goto err;
+
+ ent = proc_create(ppc64/rtas/scan-log-dump, S_IRUSR, NULL,
+ scanlog_fops);
+ if (!ent)
+ goto err;
+
+ ent-data = data;
proc_ppc64_scan_log_dump = ent;
return 0;
+err:
+ kfree(data);
+ return err;
}
static void __exit scanlog_cleanup(void)
--
1.5.4.rc5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: DTC Patch Catch Up
On Sun, Mar 23, 2008 at 08:08:08AM -0500, Jon Loeliger wrote: Folks, I've applied the following patches from Gibson, in this order, to the DTC and pushed it out to git.jdl.com: dtc: Fix error reporting in push_input_file() dtc: Implement checks for the format of node and property names dtc: Fix indentation of fixup_phandle_references dtc: Strip redundant name properties dtc: Test and fix conversion to/from old dtb versions dtc: Use for_each_marker_of_type in asm_emit_data() dtc: Make -I dtb mode use fill_fullpaths() dtc: Make eval_literal() static dtc: Assorted improvements to test harness dtc: Testcases for input handling dtc: Make dtc_open_file() die() if unable to open requested file dtc: Remove ugly include stack abuse dtc: Abolish asize field of struct data dtc: Add some documentation for the dts formta dtc: Cleanup \nnn and \xNN string escape handling dtc: Change exit code for usage message Hurrah :) -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: dcr stuff.
-Original Message- From: Josh Boyer [mailto:[EMAIL PROTECTED] Sent: Fri 3/21/2008 6:17 PM To: Stephen Neuendorffer Cc: linuxppc-dev@ozlabs.org; git-dev Subject: Re: dcr stuff. On Fri, 21 Mar 2008 12:05:40 -0700 Stephen Neuendorffer [EMAIL PROTECTED] wrote: Is there a plan here? (In particular, in FPGA designs, its possible to have crazy things like multiple independent dcr busses, some using native access, some using mmio. Or even if there is one bus, many of the existing non-linux drivers we have assume native or mmio access. I'd like to clean this up, obviously.. :) Clean it up how? I'd hate to add bloat to boards with native DCR access just because a few require oddities. If it ain't broke, don't fix it. josh Certainly, if it ain't broke don't fix it. What I'm really trying to do is figure out how to clean up alot of non-mainline drivers. At the moment, several cores use DCR, but the drivers for those cores have internal code for DCR, their own ifdefs, etc. This *is* broken. I'm looking at the available documentation to figure out the best way of approaching the problem. It might be nice if there was an extra layer of indirection which was only enabled if DCR_NATIVE and DCR_MMIO, and which was no cost otherwise, but the bigger problem I see in the short term is that we'll likely have to support ARCH ppc for at least some time into the future, and it would be nice if we used the same driver code to do it: it doesn't seem obvious how to achieve this. Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
