[PATCH v2] powerpc/86xx: Update GE Fanuc sbc310 DTS
Update GE Fanuc DTS to match the alterations suggested during the merge of
the ppc9a DTS in commit 740d36ae6344f38c4da64c2ede765d7d2dd1f132
Signed-off-by: Martyn Welch martyn.we...@gefanuc.com
---
v2: Fixed run on message.
Kumar: I think the problem may be that this patch depends on a previous patch:
http://patchwork.ozlabs.org/patch/29335/
Martyn
arch/powerpc/boot/dts/gef_sbc310.dts | 29 +
1 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc310.dts
b/arch/powerpc/boot/dts/gef_sbc310.dts
index 7810ea9..2107d3c 100644
--- a/arch/powerpc/boot/dts/gef_sbc310.dts
+++ b/arch/powerpc/boot/dts/gef_sbc310.dts
@@ -83,34 +83,34 @@
/* fl...@0,0 is a mirror of part of the memory in fl...@1,0
fl...@0,0 {
- compatible = cfi-flash;
- reg = 0 0 0x0100;
+ compatible = gef,sbc310-firmware-mirror, cfi-flash;
+ reg = 0x0 0x0 0x0100;
bank-width = 2;
device-width = 2;
#address-cells = 1;
#size-cells = 1;
partit...@0 {
label = firmware;
- reg = 0x 0x0100;
+ reg = 0x0 0x0100;
read-only;
};
};
*/
fl...@1,0 {
- compatible = cfi-flash;
- reg = 1 0 0x800;
+ compatible = gef,sbc310-paged-flash, cfi-flash;
+ reg = 0x1 0x0 0x800;
bank-width = 2;
device-width = 2;
#address-cells = 1;
#size-cells = 1;
partit...@0 {
label = user;
- reg = 0x 0x0780;
+ reg = 0x0 0x780;
};
partit...@780 {
label = firmware;
- reg = 0x0780 0x0080;
+ reg = 0x780 0x80;
read-only;
};
};
@@ -121,18 +121,16 @@
};
w...@4,2000 {
- #interrupt-cells = 2;
- device_type = watchdog;
- compatible = gef,fpga-wdt;
+ compatible = gef,sbc310-fpga-wdt, gef,fpga-wdt-1.00,
+ gef,fpga-wdt;
reg = 0x4 0x2000 0x8;
interrupts = 0x1a 0x4;
interrupt-parent = gef_pic;
};
/*
w...@4,2010 {
- #interrupt-cells = 2;
- device_type = watchdog;
- compatible = gef,fpga-wdt;
+ compatible = gef,sbc310-fpga-wdt, gef,fpga-wdt-1.00,
+ gef,fpga-wdt;
reg = 0x4 0x2010 0x8;
interrupts = 0x1b 0x4;
interrupt-parent = gef_pic;
@@ -141,7 +139,7 @@
gef_pic: p...@4,4000 {
#interrupt-cells = 1;
interrupt-controller;
- compatible = gef,fpga-pic;
+ compatible = gef,sbc310-fpga-pic, gef,fpga-pic;
reg = 0x4 0x4000 0x20;
interrupts = 0x8
0x9;
@@ -161,7 +159,7 @@
#size-cells = 1;
#interrupt-cells = 2;
device_type = soc;
- compatible = simple-bus;
+ compatible = fsl,mpc8641-soc, simple-bus;
ranges = 0x0 0xfef0 0x0010;
bus-frequency = ;
@@ -412,5 +410,4 @@
0x0 0x0040;
};
};
-
};
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus !
Here's a bunch of defconfig updates for freescale embedded platforms
along with a handful of fixes for those from Kumar, and one important
one liner fix for a thinko/typo by myself in the embedded CPU context
management code on SMP.
The following changes since commit 658874f05d040ca96eb5ba9b1c30ce0ff287d762:
Linus Torvalds (1):
Merge branch 'i2c-fixes-rc4' of git://aeryn.fluff.org.uk/bjdooks/linux
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Anton Vorontsov (3):
powerpc/85xx: Fix ethernet link detection on MPC8569E-MDS boards
powerpc/85xx: Don't scan for TBI PHY addresses on MPC8569E-MDS boards
powerpc/83xx: Fix PCI IO base address on MPC837xE-RDB boards
Kumar Gala (2):
powerpc/mm: Fix SMP issue with MMU context handling code
powerpc: Update defconfigs for embedded 6xx/7xxx, 8xx, 8{3,5,6}xxx
Mark Ware (1):
cpm_uart: Don't use alloc_bootmem in cpm_uart_cpm2.c
Martyn Welch (2):
powerpc/86xx: Update defconfig for GE Fanuc's PPC9A
powerpc/86xx: Update GE Fanuc sbc310 default configuration
arch/powerpc/boot/dts/mpc8377_rdb.dts |2 +-
arch/powerpc/boot/dts/mpc8378_rdb.dts |2 +-
arch/powerpc/boot/dts/mpc8379_rdb.dts |2 +-
arch/powerpc/boot/dts/mpc8569mds.dts |4 +
arch/powerpc/configs/83xx/asp8347_defconfig | 106 +++--
arch/powerpc/configs/83xx/kmeter1_defconfig | 176 +---
arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 168 +--
arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 168 +--
arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 111 +++--
arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 120 +++--
arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 114 +++--
arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 114 +++--
arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 104 +++--
arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 111 +++--
arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 104 +++--
arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 110 +++--
arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 162 +---
arch/powerpc/configs/83xx/sbc834x_defconfig | 103 +++--
arch/powerpc/configs/85xx/ksi8560_defconfig | 93 +++--
arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 91 +++--
arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 99 +++--
arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 99 +++--
arch/powerpc/configs/85xx/sbc8548_defconfig | 96 +++--
arch/powerpc/configs/85xx/sbc8560_defconfig | 91 +++--
arch/powerpc/configs/85xx/socrates_defconfig | 165 +---
arch/powerpc/configs/85xx/stx_gp3_defconfig | 119 +++--
arch/powerpc/configs/85xx/tqm8540_defconfig | 100 +++--
arch/powerpc/configs/85xx/tqm8541_defconfig | 101 +++--
arch/powerpc/configs/85xx/tqm8548_defconfig | 100 +++--
arch/powerpc/configs/85xx/tqm8555_defconfig | 101 +++--
arch/powerpc/configs/85xx/tqm8560_defconfig | 101 +++--
arch/powerpc/configs/85xx/xes_mpc85xx_defconfig | 118 +++--
arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 521 -
arch/powerpc/configs/86xx/gef_sbc310_defconfig| 216 +++---
arch/powerpc/configs/86xx/gef_sbc610_defconfig| 130 --
arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig | 118 +++--
arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig | 186
arch/powerpc/configs/86xx/sbc8641d_defconfig | 112 +++--
arch/powerpc/configs/adder875_defconfig | 97 +++--
arch/powerpc/configs/c2k_defconfig| 121 +++--
arch/powerpc/configs/ep8248e_defconfig| 97 +++--
arch/powerpc/configs/ep88xc_defconfig | 91 +++--
arch/powerpc/configs/linkstation_defconfig| 116 +++--
arch/powerpc/configs/mgcoge_defconfig | 97 +++--
arch/powerpc/configs/mgsuvd_defconfig | 89 ++--
arch/powerpc/configs/mpc7448_hpc2_defconfig | 103 +++--
arch/powerpc/configs/mpc8272_ads_defconfig| 104 +++--
arch/powerpc/configs/mpc83xx_defconfig| 162 +---
arch/powerpc/configs/mpc85xx_defconfig| 193
arch/powerpc/configs/mpc85xx_smp_defconfig| 193
arch/powerpc/configs/mpc866_ads_defconfig | 92 ++--
arch/powerpc/configs/mpc86xx_defconfig| 186
arch/powerpc/configs/mpc885_ads_defconfig | 91 +++--
arch/powerpc/configs/pq2fads_defconfig| 110 +++--
arch/powerpc/configs/prpmc2800_defconfig | 158 +--
arch/powerpc/configs/storcenter_defconfig | 108 +++--
arch/powerpc/mm/mmu_context_nohash.c |1 +
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 13 +
drivers/serial/cpm_uart/cpm_uart_cpm2.c |2 +-
59 files changed, 4007 insertions(+), 2755
Re: Next July 29 : Hugetlb test failure (OOPS free_hugepte_range)
Sachin Sant wrote: next-20090728 worked fine. Last commit that changed arch/powerpc/mm/hugetlbpage.c was cb7f3f2d92d1b26c13e30e639b6ee4a78e9a3afa powerpc: Add memory management headers for new 64-bit BookE I will try reverting that commit and check if that helps. Hi Ben, Reverting the above patch helped. The tests ran fine against the patched kernel. But ofcourse that's not the solution :-) Here is some data from xmon that might help find the reason for the failure. This is with today's next. : [ cut here ] cpu 0x0: Vector: 700 (Program Check) at [c00038923560] pc: c00486d4: .free_hugepte_range+0x68/0xa0 lr: c0048954: .hugetlb_free_pgd_range+0x248/0x38c sp: c000389237e0 msr: 80029032 current = 0xc0003b1d7780 paca= 0xc1002400 pid = 2839, comm = readback kernel BUG at /home/linux-2.6.31-rc4/arch/powerpc/include/asm/pgalloc.h:36! enter ? for help [c00038923880] c0048954 .hugetlb_free_pgd_range+0x248/0x38c [c00038923970] c0165a48 .free_pgtables+0xa0/0x154 [c00038923a30] c0167f78 .exit_mmap+0x13c/0x1cc [c00038923ae0] c00997ec .mmput+0x68/0x14c [c00038923b70] c009f1d4 .exit_mm+0x190/0x1b8 [c00038923c20] c00a16e8 .do_exit+0x214/0x784 [c00038923d00] c00a1d1c .do_group_exit+0xc4/0xf8 [c00038923da0] c00a1d7c .SyS_exit_group+0x2c/0x48 [c00038923e30] c00085b4 syscall_exit+0x0/0x40 --- Exception: c01 (System Call) at 0fe15038 SP (ffb8e030) is in userspace 0:mon e cpu 0x0: Vector: 700 (Program Check) at [c00038923560] pc: c00486d4: .free_hugepte_range+0x68/0xa0 lr: c0048954: .hugetlb_free_pgd_range+0x248/0x38c sp: c000389237e0 msr: 80029032 current = 0xc0003b1d7780 paca= 0xc1002400 pid = 2839, comm = readback kernel BUG at /home/linux-2.6.31-rc4/arch/powerpc/include/asm/pgalloc.h:36! 0:mon r R00 = 0001 R16 = R01 = c000389237e0 R17 = 0001 R02 = c0f165a8 R18 = 3fff R03 = c14504d0 R19 = R04 = c00039390001 R20 = R05 = 0007 R21 = 0100 R06 = R22 = 4000 R07 = 4000 R23 = c14504d0 R08 = c0003d708188 R24 = 3fff R09 = c0003eb4 R25 = 0007 R10 = c0003d708188 R26 = c0003ebd41b8 R11 = 0018 R27 = c14504d0 R12 = 4448 R28 = c0003eb40018 R13 = c1002400 R29 = 0008 R14 = R30 = 4000 R15 = R31 = c000389237e0 pc = c00486d4 .free_hugepte_range+0x68/0xa0 lr = c0048954 .hugetlb_free_pgd_range+0x248/0x38c msr = 80029032 cr = 20042444 ctr = 8000b6f4 xer = 0001 trap = 700 0:mon Line 36 of arch/powerpc/include/asm/pgalloc.h corresponds to BUG_ON(cachenum PGF_CACHENUM_MASK); May be something to do with number of elements in huge_pgtable_cache_name ?? Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Next July 29 : Hugetlb test failure (OOPS free_hugepte_range)
On Thu, 2009-07-30 at 17:55 +0530, Sachin Sant wrote: Sachin Sant wrote: next-20090728 worked fine. Last commit that changed arch/powerpc/mm/hugetlbpage.c was cb7f3f2d92d1b26c13e30e639b6ee4a78e9a3afa powerpc: Add memory management headers for new 64-bit BookE I will try reverting that commit and check if that helps. Hi Ben, Reverting the above patch helped. The tests ran fine against the patched kernel. But ofcourse that's not the solution :-) Here is some data from xmon that might help find the reason for the failure. This is with today's next. Thanks. I'll have a look next week. I think when I changed the indices I may have forgotten to update something. Cheers, Ben. : [ cut here ] cpu 0x0: Vector: 700 (Program Check) at [c00038923560] pc: c00486d4: .free_hugepte_range+0x68/0xa0 lr: c0048954: .hugetlb_free_pgd_range+0x248/0x38c sp: c000389237e0 msr: 80029032 current = 0xc0003b1d7780 paca= 0xc1002400 pid = 2839, comm = readback kernel BUG at /home/linux-2.6.31-rc4/arch/powerpc/include/asm/pgalloc.h:36! enter ? for help [c00038923880] c0048954 .hugetlb_free_pgd_range+0x248/0x38c [c00038923970] c0165a48 .free_pgtables+0xa0/0x154 [c00038923a30] c0167f78 .exit_mmap+0x13c/0x1cc [c00038923ae0] c00997ec .mmput+0x68/0x14c [c00038923b70] c009f1d4 .exit_mm+0x190/0x1b8 [c00038923c20] c00a16e8 .do_exit+0x214/0x784 [c00038923d00] c00a1d1c .do_group_exit+0xc4/0xf8 [c00038923da0] c00a1d7c .SyS_exit_group+0x2c/0x48 [c00038923e30] c00085b4 syscall_exit+0x0/0x40 --- Exception: c01 (System Call) at 0fe15038 SP (ffb8e030) is in userspace 0:mon e cpu 0x0: Vector: 700 (Program Check) at [c00038923560] pc: c00486d4: .free_hugepte_range+0x68/0xa0 lr: c0048954: .hugetlb_free_pgd_range+0x248/0x38c sp: c000389237e0 msr: 80029032 current = 0xc0003b1d7780 paca= 0xc1002400 pid = 2839, comm = readback kernel BUG at /home/linux-2.6.31-rc4/arch/powerpc/include/asm/pgalloc.h:36! 0:mon r R00 = 0001 R16 = R01 = c000389237e0 R17 = 0001 R02 = c0f165a8 R18 = 3fff R03 = c14504d0 R19 = R04 = c00039390001 R20 = R05 = 0007 R21 = 0100 R06 = R22 = 4000 R07 = 4000 R23 = c14504d0 R08 = c0003d708188 R24 = 3fff R09 = c0003eb4 R25 = 0007 R10 = c0003d708188 R26 = c0003ebd41b8 R11 = 0018 R27 = c14504d0 R12 = 4448 R28 = c0003eb40018 R13 = c1002400 R29 = 0008 R14 = R30 = 4000 R15 = R31 = c000389237e0 pc = c00486d4 .free_hugepte_range+0x68/0xa0 lr = c0048954 .hugetlb_free_pgd_range+0x248/0x38c msr = 80029032 cr = 20042444 ctr = 8000b6f4 xer = 0001 trap = 700 0:mon Line 36 of arch/powerpc/include/asm/pgalloc.h corresponds to BUG_ON(cachenum PGF_CACHENUM_MASK); May be something to do with number of elements in huge_pgtable_cache_name ?? Thanks -Sachin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][sata_fsl] Defer non-ncq commands when ncq commands active
Hello,
Signed-off-by: Ashish Kalra ashish.ka...@freescale.com
---
drivers/ata/sata_fsl.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 5a88b44..a33f130 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -1262,6 +1262,7 @@ static struct scsi_host_template sata_fsl_sht = {
static struct ata_port_operations sata_fsl_ops = {
.inherits = sata_pmp_port_ops,
+ .qc_defer = ata_std_qc_defer;
.qc_prep = sata_fsl_qc_prep,
.qc_issue = sata_fsl_qc_issue,
.qc_fill_rtf = sata_fsl_qc_fill_rtf,
This doesn't look like it should change anything. sata_fsl_ops inherits
from sata_pmp_port_ops, which inherits from sata_port_ops, which already
sets qc_defer to ata_std_qc_defer.
Oh, yes. Actually this patch was for older kernels where there inheritence was
not there. As you mentioned, this patch is not required now.
Thanks,
Ashish
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][sata_fsl] Defer non-ncq commands when ncq commands active
On Jul 30, 2009, at 8:23 AM, Kalra Ashish-B00888 wrote:
Hello,
Signed-off-by: Ashish Kalra ashish.ka...@freescale.com
---
drivers/ata/sata_fsl.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 5a88b44..a33f130 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -1262,6 +1262,7 @@ static struct scsi_host_template
sata_fsl_sht = {
static struct ata_port_operations sata_fsl_ops = {
.inherits = sata_pmp_port_ops,
+ .qc_defer = ata_std_qc_defer;
.qc_prep = sata_fsl_qc_prep,
.qc_issue = sata_fsl_qc_issue,
.qc_fill_rtf = sata_fsl_qc_fill_rtf,
This doesn't look like it should change anything. sata_fsl_ops
inherits
from sata_pmp_port_ops, which inherits from sata_port_ops, which
already
sets qc_defer to ata_std_qc_defer.
Oh, yes. Actually this patch was for older kernels where there
inheritence was not there. As you mentioned, this patch is not
required now.
How old? Should we be asking for this to be applied to some of the
stable kernel series?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][sata_fsl] Defer non-ncq commands when ncq commands active
Hello Kumar, This doesn't look like it should change anything. sata_fsl_ops inherits from sata_pmp_port_ops, which inherits from sata_port_ops, which already sets qc_defer to ata_std_qc_defer. Oh, yes. Actually this patch was for older kernels where there inheritence was not there. As you mentioned, this patch is not required now. How old? Should we be asking for this to be applied to some of the stable kernel series? I believe that the inheritence stuff was added in 2.6.26, thus, this patch is required for quite old kernels ( 2.6.26 ). Thanks, Ashish ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][sata_fsl] Defer non-ncq commands when ncq commands active
On Jul 30, 2009, at 8:58 AM, Kalra Ashish-B00888 wrote: Hello Kumar, This doesn't look like it should change anything. sata_fsl_ops inherits from sata_pmp_port_ops, which inherits from sata_port_ops, which already sets qc_defer to ata_std_qc_defer. Oh, yes. Actually this patch was for older kernels where there inheritence was not there. As you mentioned, this patch is not required now. How old? Should we be asking for this to be applied to some of the stable kernel series? I believe that the inheritence stuff was added in 2.6.26, thus, this patch is required for quite old kernels ( 2.6.26 ). Ok, than I'm not going to worry about it. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC
On Fri, Jul 24, 2009 at 11:21:56AM -0400, Solomon Peachy wrote:
This patch adds support for the ESTeem 195E Hotfoot SBC.
I've been maintaining this out-of-tree for some time now for
older kernels, but recently I ported it to the new unified powerpc
tree with the intent of pushing it upstream.
The 195E boards use ancient versions of u-boot and a slightly mangled
verison of the oft-abused ppcboot header.
There are several variants of the SBC deployed, single/dual
ethernet+serial, and also 4MB/8MB flash variations. In the interest of
having a single kernel image boot on all boards, the cuboot shim detects
the differences and mangles the DTS tree appropriately.
With the exception of the CF interface that was never populated on
production boards, this code/DTS supports all boardpop options.
Signed-off-by: Solomon Peachy solo...@linux-wlan.com
Overall, really nice. Just a few questions below.
--- linux-2.6.30/arch/powerpc/boot/cuboot-hotfoot.c1969-12-31
19:00:00.0 -0500
+++ linux-2.6.30.hotfoot/arch/powerpc/boot/cuboot-hotfoot.c2009-07-07
12:55:23.0 -0400
@@ -0,0 +1,142 @@
+/*
+ * Old U-boot compatibility for Esteem 195E Hotfoot CPU Board
+ *
+ * Author: Solomon Peachy solo...@linux-wlan.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include ops.h
+#include stdio.h
+#include reg.h
+#include dcr.h
+#include 4xx.h
+#include cuboot.h
+
+#define TARGET_4xx
+#define TARGET_HOTFOOT
+#include ppcboot.h
+
+static bd_t bd;
+
+#define NUM_REGS 3
+
+static void hotfoot_fixups(void)
+{
+ u32 uart = mfdcr(DCRN_CPC0_UCR) 0x7f;
+
+ dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+
+ dt_fixup_cpu_clocks(bd.bi_procfreq, bd.bi_procfreq, 0);
+ dt_fixup_clock(/plb, bd.bi_plb_busfreq);
+ dt_fixup_clock(/plb/opb, bd.bi_opbfreq);
+ dt_fixup_clock(/plb/ebc, bd.bi_pci_busfreq);
+ dt_fixup_clock(/plb/opb/ser...@ef600300, bd.bi_procfreq / uart);
+ dt_fixup_clock(/plb/opb/ser...@ef600400, bd.bi_procfreq / uart);
+
+ dt_fixup_mac_address_by_alias(ethernet0, bd.bi_enetaddr);
+ dt_fixup_mac_address_by_alias(ethernet1, bd.bi_enet1addr);
+
+ /* Is this a single eth/serial board? */
+ if ((bd.bi_enet1addr[0] == 0)
+ (bd.bi_enet1addr[1] == 0)
+ (bd.bi_enet1addr[2] == 0)
+ (bd.bi_enet1addr[3] == 0)
+ (bd.bi_enet1addr[4] == 0)
+ (bd.bi_enet1addr[5] == 0)) {
+ void *devp;
+
+ printf(Trimming devtree for single eth board\n);
+
+ devp = finddevice(/plb/opb/ser...@ef600300);
+ if (!devp)
+ fatal(Can't find node for /plb/opb/ser...@ef600300);
+ del_node(devp);
Slightly confused here. You delete the first serial node in the single eth
case?
+
+ devp = finddevice(/plb/opb/ether...@ef600900);
+ if (!devp)
+ fatal(Can't find node for /plb/opb/ether...@ef600900);
+ del_node(devp);
+ }
+
+ ibm4xx_quiesce_eth((u32 *)0xef600800, (u32 *)0xef600900);
Shouldn't you do the quiesce conditionally if the other eth port doesn't
exist?
+
+ /* Fix up flash size in fdt for 4M boards. */
+ if (bd.bi_flashsize 0x80) {
+ u32 regs[NUM_REGS];
+ void *devp = finddevice(/plb/ebc/nor_fl...@0);
+ if (!devp)
+ fatal(Can't find FDT node for nor_flash!??);
+
+ printf(Fixing devtree for 4M Flash\n);
+
+ /* First fix up the base addresse */
+ getprop(devp, reg, regs, sizeof(regs));
+ regs[0] = 0;
+ regs[1] = 0xffc0;
+ regs[2] = 0x0040;
+ setprop(devp, reg, regs, sizeof(regs));
+
+ /* Then the offsets */
+ devp = finddevice(/plb/ebc/nor_fl...@0/partit...@0);
+ if (!devp)
+ fatal(Can't find FDT node for partit...@0);
+ getprop(devp, reg, regs, 2*sizeof(u32));
+ regs[0] -= 0x40;
+ setprop(devp, reg, regs, 2*sizeof(u32));
+
+ devp = finddevice(/plb/ebc/nor_fl...@0/partit...@1);
+ if (!devp)
+ fatal(Can't find FDT node for partit...@1);
+ getprop(devp, reg, regs, 2*sizeof(u32));
+ regs[0] -= 0x40;
+ setprop(devp, reg, regs, 2*sizeof(u32));
+
+ devp = finddevice(/plb/ebc/nor_fl...@0/partit...@2);
+ if (!devp)
+ fatal(Can't find FDT node for partit...@2);
+ getprop(devp, reg, regs, 2*sizeof(u32));
+ regs[0] -= 0x40;
+ setprop(devp, reg, regs, 2*sizeof(u32));
+
+ devp = finddevice(/plb/ebc/nor_fl...@0/partit...@3);
+
[PATCH 5/5] sound/aoa: Add kmalloc NULL tests
From: Julia Lawall ju...@diku.dk
Check that the result of kzalloc is not NULL before a dereference.
The semantic match that finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@@
expression *x;
identifier f;
constant char *C;
@@
x = \(kmalloc\|kcalloc\|kzalloc\)(...);
... when != x == NULL
when != x != NULL
when != (x || ...)
(
kfree(x)
|
f(...,C,...,x,...)
|
*f(...,x,...)
|
*x-f
)
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
---
sound/aoa/core/gpio-pmf.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/sound/aoa/core/gpio-pmf.c b/sound/aoa/core/gpio-pmf.c
index 5ca2220..b4439ce 100644
--- a/sound/aoa/core/gpio-pmf.c
+++ b/sound/aoa/core/gpio-pmf.c
@@ -182,6 +182,12 @@ static int pmf_set_notify(struct gpio_runtime *rt,
if (!old notify) {
irq_client = kzalloc(sizeof(struct pmf_irq_client),
GFP_KERNEL);
+ if (!irq_client) {
+ err = -ENOMEM;
+ printk(KERN_ERR snd-aoa: gpio layer failed to
+register %s irq (%d)\n, name, err);
+ goto out_unlock;
+ }
irq_client-data = notif;
irq_client-handler = pmf_handle_notify_irq;
irq_client-owner = THIS_MODULE;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/5] sound/aoa: Add kmalloc NULL tests
On Thu, 30 Jul 2009, Johannes Berg wrote:
On Thu, 2009-07-30 at 16:11 +0200, Julia Lawall wrote:
From: Julia Lawall ju...@diku.dk
Check that the result of kzalloc is not NULL before a dereference.
irq_client = kzalloc(sizeof(struct pmf_irq_client),
GFP_KERNEL);
+ if (!irq_client) {
+ err = -ENOMEM;
+ printk(KERN_ERR snd-aoa: gpio layer failed to
+register %s irq (%d)\n, name, err);
+ goto out_unlock;
+ }
Looks good, thanks, but I'd really drop the printk if only to not have
the string there, that doesn't really seem interesting.
The printk is based on similar error handling code a few lines later:
if (err) {
printk(KERN_ERR snd-aoa: gpio layer failed to
register %s irq (%d)\n, name,
err);
kfree(irq_client);
goto out_unlock;
}
Should the printk be removed in this case as well? Or is it ok to fail
silently in one case and not in the other?
julia
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/5] sound/aoa: Add kmalloc NULL tests
On Thu, 2009-07-30 at 16:11 +0200, Julia Lawall wrote:
From: Julia Lawall ju...@diku.dk
Check that the result of kzalloc is not NULL before a dereference.
irq_client = kzalloc(sizeof(struct pmf_irq_client),
GFP_KERNEL);
+ if (!irq_client) {
+ err = -ENOMEM;
+ printk(KERN_ERR snd-aoa: gpio layer failed to
+ register %s irq (%d)\n, name, err);
+ goto out_unlock;
+ }
Looks good, thanks, but I'd really drop the printk if only to not have
the string there, that doesn't really seem interesting.
johannes
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
can the kernel show user task stack backtrace ?
Afaik the kernel only shows the stack backtrace of the kernel stack
(of a task).
I wonder if there would be anything wrong with letting it show
the user task stack backtrace in certain cases.
Read the rest to see what I mean.
If kernel.print-fatal-signals has been enabled a crashing
application makes the kernel show this:
ca2/943: potentially unexpected fatal signal 11.
NIP: 144c LR: 1444 CTR:
REGS: ce73df50 TRAP: 0300 Not tainted (2.6.28)
MSR: d032 EE,PR,ME,IR,DR CR: 22000422 XER: 2000
DAR: d003, DSISR: 2200
TASK = ceb7a3e0[943] 'ca2' THREAD: ce73c000
GPR00: 000e bf963b30 48025450 000a 0ff0ac2c 22000422 0001 0ff5e6b0
GPR08: 0001 d003 1032 1001896c 0ffe9000
GPR16: 0ffca59c 1009b940 100a8b6a 100bf234 bfea22b8 100bf224
GPR24: 100bf008 1009b960 4801e858 4802dd34 4802e7e0 0ffec8d8 bf963b30
Call Trace:
Segmentation fault
#
It's a real pity the user task stack backtrace isn't shown.
We're dealing with some complex (3rd party) applications and I like to see a
user task stack backtrace.
(Of course the way to go here is to use a debugger (gdb) and
do a backtrace (with the coredump file).
However, debugging takes some time. Besides the info is there
it only needs to be shown. Often just this info is enough to
pinpoint the problem)
Obviously the arch/powerpc/kernel/process.c:show_stack function
isn't meant for doing this. It only shows the kernel stack.
Btw. this doesn't work in my case since validate_sp returns 0 (because
sp is assigned the user-space stack (bf963b30) while kernel stack starts at
ce73c000).
Though if it would work it isn't very usefull I guess since the crashing app
not enters kernel-mode (via sys-calls).
If I change arch/powerpc/kernel/process.c:show_stack (of kernel 2.6.28) like
this:
do {
#if 0
if (!validate_sp(sp, tsk, STACK_FRAME_OVERHEAD))
return;
#endif
.
.
.
} while ((count++ kstack_depth_to_print) (sp != 0));
the following is shown:
ca2/943: potentially unexpected fatal signal 11.
NIP: 144c LR: 1444 CTR: c001fd7c
REGS: ce73df50 TRAP: 0300 Not tainted (2.6.28)
MSR: f932 EE,PR,FP,ME,IR,DR CR: 22000422 XER: 2000
DAR: d003, DSISR: 2200
TASK = cf09b340[943] 'ca2' THREAD: ce73c000
GPR00: 000e bfd65b30 48025450 000a 0ff0ac2c 22000422 0001 0ff5e6b0
GPR08: 0001 d003 1032 1001896c 0ffe9000
GPR16: 0ffca59c 1009b940 100a8b6a 100bf234 bfb532b8 100bf224
GPR24: 100bf008 1009b960 4801e858 4802dd34 4802e7e0 0ffec8d8 bfd65b30
Call Trace:
[bfd65b30] [1444] 0x1444 (unreliable)
[bfd65b60] [1490] 0x1490
[bfd65b90] [14cc] 0x14cc
[bfd65ba0] [0feb39c8] 0xfeb39c8
[bfd65dd0] [0feb3ad4] 0xfeb3ad4
[bfd65de0] [] 0x00
Segmentation fault
#
which is what I want.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: missing tests after ioremap()?
Missing tests after ioremap()
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
Shouldn't we test whether ioremaps fail?
diff --git a/arch/powerpc/platforms/powermac/feature.c
b/arch/powerpc/platforms/powermac/feature.c
index e6c0040..3a4ebd3 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -2589,9 +2589,16 @@ static void __init probe_uninorth(void)
if (address == 0)
return;
uninorth_base = ioremap(address, 0x4);
+ if (uninorth_base == NULL)
+ return;
uninorth_rev = in_be32(UN_REG(UNI_N_VERSION));
- if (uninorth_maj == 3 || uninorth_maj == 4)
+ if (uninorth_maj == 3 || uninorth_maj == 4) {
u3_ht_base = ioremap(address + U3_HT_CONFIG_BASE, 0x1000);
+ if (u3_ht_base == NULL) {
+ iounmap(uninorth_base);
+ return;
+ }
+ }
printk(KERN_INFO Found %s memory controller host bridge
@ 0x%08x revision: 0x%02x\n, uninorth_maj == 3 ? U3 :
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: can the kernel show user task stack backtrace ?
We're dealing with some complex (3rd party) applications and I like to see a user task stack backtrace. (Of course the way to go here is to use a debugger (gdb) and do a backtrace (with the coredump file). Actually, you can intercept SIGSEGV and print your own stack from within the signal handler. You can also open /proc/self/maps and print it, to ease understanding the various pointers in there, especially if the application is using a number of shared libs. This is usually easier than getting to a core dump, although there is less information than what the core offers. I have the code for ARM and I've it on ppc once, but I must dig for the actual code. /alessandro ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: can the kernel show user task stack backtrace ?
On Thu, 30 Jul 2009, Alessandro Rubini wrote: We're dealing with some complex (3rd party) applications and I like to see a user task stack backtrace. (Of course the way to go here is to use a debugger (gdb) and do a backtrace (with the coredump file). Actually, you can intercept SIGSEGV and print your own stack from within the signal handler. You can also open /proc/self/maps and print it, to ease understanding the various pointers in there, especially if the application is using a number of shared libs. This is usually easier than getting to a core dump, although there is less information than what the core offers. I have the code for ARM and I've it on ppc once, but I must dig for the actual code. I think libSegFault.so (part of glibc) can do that by simply preloading it LD_PRELOAD=/lib/libSegFault.so ./your_segfaulting_app should do the trick. hofrat ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: fsldma patches?
Kumar Gala wrote: Dan, What happened with the set of patches that Ira posted for fsldma? I have just sent a pull request with the pending backlog of dmaengine fixes. Our discussion of the fsldma slave implementation did not conclude in time for me to get a pull request out before the close of the 2.6.31 merge window. I have queued it up for 2.6.32. -- Dan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC
On Thu, Jul 30, 2009 at 10:06:30AM -0400, Josh Boyer wrote:
+devp = finddevice(/plb/opb/ser...@ef600300);
+if (!devp)
+fatal(Can't find node for /plb/opb/ser...@ef600300);
+del_node(devp);
Slightly confused here. You delete the first serial node in the single eth
case?
The board is actually single eth/serial or dual eth/serial. And strictly
speaking, this serial port is the second one in the devicetree...
(The PPC405EP's serial boards aren't created equally; the first is a
dumb tx/rx-only port while the second has a full set of signals.
The hotfoot is wired such that the second, full-featured port is the
primary/console/boot port)
+
+devp = finddevice(/plb/opb/ether...@ef600900);
+if (!devp)
+fatal(Can't find node for /plb/opb/ether...@ef600900);
+del_node(devp);
+}
+
+ibm4xx_quiesce_eth((u32 *)0xef600800, (u32 *)0xef600900);
Shouldn't you do the quiesce conditionally if the other eth port doesn't
exist?
I don't know if this is strictly necessary with the modern ibm_emac
driver, but it's certainly safe to call because all 405EPs have dual
ethernet controllers.
From the (pre-dts) driver perspecive, the only way to tell if the
hotfoot had one ethernet port or two was that the second PHY failed to
initialize.
Additionally, the production bootloader (u-boot 1.2.0.x) isn't terribly
smart and tries to drive the second controller if the first one doesn't
have a cable plugged in, so it's possible the second controller is
running when control is handed over to Linux, even on single ethernet
boards.
+UART0: ser...@ef600400 {
+device_type = serial;
+compatible = ns16550;
+reg = 0xef600400 0x0008;
+virtual-reg = 0xef600400;
+clock-frequency = 0; /* Filled in by zImage */
+current-speed = 0x9600;
Just a question, but is the baud supposed to be 38400 or 9600? At first
glance
it almost seems like a typo :).
It's supposed to be 38400 baud, hence the explicit 0x in front. (I lost
count of the number of times I saw '38400' listed in various dts
files...)
+gpio-leds {
+ compatible = gpio-leds;
+ status {
+label = Status;
+gpios = GPIO 1 0;
+/* linux,default=trigger = ..; */
+ };
What does that comment mean?
Whoops, it's supposed to read 'linux,default-trigger', but the LEDs are
manually twiddled for the time being. I'd forgotten to strip that out.
(see linux/Documentation/powerpc/dts-bindings/gpio/led.txt)
Ok. So I'm not really all that thrilled with changes to ppcboot.h.
We try to keep this file as much in-sync with U-Boot as we can. Did
your HOTFOOT changes get pulled into upstream U-Boot?
Yeah, I thought this may be a problem, but I didn't know a better way to
go about this and still maintain compatibility with the many thousands
of boards already in the field. I mean, I could strip out the ppcboot.h
changes and maintain that as an out-of-tree patch, but without that
patch, the kernel won't boot on in-the-field boards, rendering the
upstreaming of support for this board kinda pointless.
I haven't tried to push anything to upstream u-boot, given how ancient
the in-production bootloader is. The guy who originally mangled u-boot
for this board did so before the standard 405EP dual ethernet layout
was added, and never tried to push it upstream. Any upstream uboot work
will take the form of a native dts/fdt port that probably won't use
ppcboot.h anyway, which brings us full circle...
- Solomon
--
Solomon Peachysolo...@linux-wlan.com
AbsoluteValue Systems http://www.linux-wlan.com
721-D North Drive +1 (321) 259-0737 (office)
Melbourne, FL 32934 +1 (321) 259-0286 (fax)
pgpeNX3q078Xt.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC
On Thu, Jul 30, 2009 at 03:45:06PM -0400, Solomon Peachy wrote:
On Thu, Jul 30, 2009 at 10:06:30AM -0400, Josh Boyer wrote:
+ devp = finddevice(/plb/opb/ser...@ef600300);
+ if (!devp)
+ fatal(Can't find node for /plb/opb/ser...@ef600300);
+ del_node(devp);
Slightly confused here. You delete the first serial node in the single eth
case?
The board is actually single eth/serial or dual eth/serial. And strictly
speaking, this serial port is the second one in the devicetree...
Maybe a brief comment in the code explaining that would help. Also, I did
notice the DTS had them in the order you mention, and I forgot to come back
and correct my question there.
+
+ devp = finddevice(/plb/opb/ether...@ef600900);
+ if (!devp)
+ fatal(Can't find node for /plb/opb/ether...@ef600900);
+ del_node(devp);
+ }
+
+ ibm4xx_quiesce_eth((u32 *)0xef600800, (u32 *)0xef600900);
Shouldn't you do the quiesce conditionally if the other eth port doesn't
exist?
I don't know if this is strictly necessary with the modern ibm_emac
driver, but it's certainly safe to call because all 405EPs have dual
ethernet controllers.
From the (pre-dts) driver perspecive, the only way to tell if the
hotfoot had one ethernet port or two was that the second PHY failed to
initialize.
Additionally, the production bootloader (u-boot 1.2.0.x) isn't terribly
smart and tries to drive the second controller if the first one doesn't
have a cable plugged in, so it's possible the second controller is
running when control is handed over to Linux, even on single ethernet
boards.
OK, that makes sense.
+ UART0: ser...@ef600400 {
+ device_type = serial;
+ compatible = ns16550;
+ reg = 0xef600400 0x0008;
+ virtual-reg = 0xef600400;
+ clock-frequency = 0; /* Filled in by zImage */
+ current-speed = 0x9600;
Just a question, but is the baud supposed to be 38400 or 9600? At first
glance
it almost seems like a typo :).
It's supposed to be 38400 baud, hence the explicit 0x in front. (I lost
count of the number of times I saw '38400' listed in various dts
files...)
Cool. Just checking.
+ gpio-leds {
+compatible = gpio-leds;
+status {
+ label = Status;
+ gpios = GPIO 1 0;
+ /* linux,default=trigger = ..; */
+};
What does that comment mean?
Whoops, it's supposed to read 'linux,default-trigger', but the LEDs are
manually twiddled for the time being. I'd forgotten to strip that out.
(see linux/Documentation/powerpc/dts-bindings/gpio/led.txt)
OK. If it's not needed just yank it.
Ok. So I'm not really all that thrilled with changes to ppcboot.h.
We try to keep this file as much in-sync with U-Boot as we can. Did
your HOTFOOT changes get pulled into upstream U-Boot?
Yeah, I thought this may be a problem, but I didn't know a better way to
go about this and still maintain compatibility with the many thousands
of boards already in the field. I mean, I could strip out the ppcboot.h
changes and maintain that as an out-of-tree patch, but without that
patch, the kernel won't boot on in-the-field boards, rendering the
upstreaming of support for this board kinda pointless.
I haven't tried to push anything to upstream u-boot, given how ancient
the in-production bootloader is. The guy who originally mangled u-boot
for this board did so before the standard 405EP dual ethernet layout
was added, and never tried to push it upstream. Any upstream uboot work
will take the form of a native dts/fdt port that probably won't use
ppcboot.h anyway, which brings us full circle...
There is another way. Perhaps you could just copy ppcboot.h to a new file
called hotfoot.h and just use that. It's a duplication of ppcboot.h to
some degree, but it seems to make sense for your board and it helps preserve
the stock ppcboot.h for other boards.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gianfar: fix coalescing setup in ethtool support
From: Li Yang le...@freescale.com Date: Wed, 29 Jul 2009 16:51:57 +0800 Parameter order for using mk_ic_value(count, time) was reversed, the patch fixes this. Signed-off-by: Jiajun Wu b06...@freescale.com Signed-off-by: Li Yang le...@freescale.com Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] Support for PCI Express reset type
This is the first of three patches that implement a bit field that PCI Express
device drivers can use to indicate they need a fundamental reset during error
recovery.
By default, the EEH framework on powerpc does what's known as a hot reset during
recovery of a PCI Express device. We've found a case where the device needs a fundamental
reset to recover properly. The current PCI error recovery and EEH frameworks do not support
this distinction.
The attached patch (courtesy of Richard Lary) adds a bit field to pci_dev that
indicates whether the device requires a fundamental reset during recovery.
These patches supersede the previously submitted patch that implemented a fundamental reset bit field.
Please review and let me know of any concerns.
Signed-off-by: Mike Mason mm...@us.ibm.com
Signed-off-by: Richard Lary rl...@us.ibm.com
diff -uNrp a/include/linux/pci.h b/include/linux/pci.h
--- a/include/linux/pci.h 2009-07-13 14:25:37.0 -0700
+++ b/include/linux/pci.h 2009-07-15 10:25:37.0 -0700
@@ -273,6 +273,7 @@ struct pci_dev {
unsigned intari_enabled:1; /* ARI forwarding */
unsigned intis_managed:1;
unsigned intis_pcie:1;
+ unsigned intneeds_freset:1; /* Dev requires fundamental reset */
unsigned intstate_saved:1;
unsigned intis_physfn:1;
unsigned intis_virtfn:1;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] Support for PCI Express reset type
This is the second of three patches that implement a bit field that PCI Express device drivers can use to indicate they need a fundamental reset during error recovery. By default, the EEH framework on powerpc does what's known as a hot reset during recovery of a PCI Express device. We've found a case where the device needs a fundamental reset to recover properly. The current PCI error recovery and EEH frameworks do not support this distinction. The attached patch updates the Documentation/PCI/pci-error-recovery.txt file with changes related to this new bit field, as well a few unrelated updates. These patches supersede the previously submitted patch that implemented a fundamental reset bit field. Please review and let me know of any concerns. Signed-off-by: Mike Mason mm...@us.ibm.com Signed-off-by: Richard Lary rl...@us.ibm.com --- a/Documentation/PCI/pci-error-recovery.txt 2009-06-09 20:05:27.0 -0700 +++ b/Documentation/PCI/pci-error-recovery.txt 2009-07-30 13:57:15.0 -0700 @@ -4,15 +4,17 @@ February 2, 2006 Current document maintainer: - Linas Vepstas li...@austin.ibm.com + Linas Vepstas linasveps...@gmail.com + updated by Richard Lary rl...@us.ibm.com + and Mike Mason mm...@us.ibm.com on 27-Jul-2009 Many PCI bus controllers are able to detect a variety of hardware PCI errors on the bus, such as parity errors on the data and address busses, as well as SERR and PERR errors. Some of the more advanced chipsets are able to deal with these errors; these include PCI-E chipsets, -and the PCI-host bridges found on IBM Power4 and Power5-based pSeries -boxes. A typical action taken is to disconnect the affected device, +and the PCI-host bridges found on IBM Power4, Power5 and Power6-based +pSeries boxes. A typical action taken is to disconnect the affected device, halting all I/O to it. The goal of a disconnection is to avoid system corruption; for example, to halt system memory corruption due to DMA's to wild addresses. Typically, a reconnection mechanism is also @@ -37,10 +39,11 @@ is forced by the need to handle multi-fu devices that have multiple device drivers associated with them. In the first stage, each driver is allowed to indicate what type of reset it desires, the choices being a simple re-enabling of I/O -or requesting a hard reset (a full electrical #RST of the PCI card). -If any driver requests a full reset, that is what will be done. +or requesting a slot reset. -After a full reset and/or a re-enabling of I/O, all drivers are +If any driver requests a slot reset, that is what will be done. + +After a reset and/or a re-enabling of I/O, all drivers are again notified, so that they may then perform any device setup/config that may be required. After these have all completed, a final resume normal operations event is sent out. @@ -101,7 +104,7 @@ if it implements any, it must implement is not implemented, the corresponding feature is considered unsupported. For example, if mmio_enabled() and resume() aren't there, then it is assumed that the driver is not doing any direct recovery and requires -a reset. If link_reset() is not implemented, the card is assumed as +a slot reset. If link_reset() is not implemented, the card is assumed to not care about link resets. Typically a driver will want to know about a slot_reset(). @@ -111,7 +114,7 @@ sequence described below. STEP 0: Error Event --- -PCI bus error is detect by the PCI hardware. On powerpc, the slot +A PCI bus error is detected by the PCI hardware. On powerpc, the slot is isolated, in that all I/O is blocked: all reads return 0x, all writes are ignored. @@ -139,7 +142,7 @@ The driver must return one of the follow a chance to extract some diagnostic information (see mmio_enable, below). - PCI_ERS_RESULT_NEED_RESET: - Driver returns this if it can't recover without a hard + Driver returns this if it can't recover without a slot reset. - PCI_ERS_RESULT_DISCONNECT: Driver returns this if it doesn't want to recover at all. @@ -169,11 +172,11 @@ is STEP 6 (Permanent Failure). The current powerpc implementation doesn't much care if the device attempts I/O at this point, or not. I/O's will fail, returning - a value of 0xff on read, and writes will be dropped. If the device - driver attempts more than 10K I/O's to a frozen adapter, it will - assume that the device driver has gone into an infinite loop, and - it will panic the kernel. There doesn't seem to be any other - way of stopping a device driver that insists on spinning on I/O. + a value of 0xff on read, and writes will be dropped. If more than + EEH_MAX_FAILS I/O's are attempted to a frozen adapter, EEH + assumes that the device driver has gone into an infinite loop + and
[PATCH 3/3] Support for PCI Express reset type
This is the third of three patches that implement a bit field that PCI Express
device drivers can use to indicate they need a fundamental reset during error
recovery.
By default, the EEH framework on powerpc does what's known as a hot reset during
recovery of a PCI Express device. We've found a case where the device needs a fundamental
reset to recover properly. The current PCI error recovery and EEH frameworks do not support
this distinction.
The attached patch makes changes to EEH to utilize the new bit field.
These patches supersede the previously submitted patch that implemented a
fundamental reset bit field.
Please review and let me know of any concerns.
Signed-off-by: Mike Mason mm...@us.ibm.com
Signed-off-by: Richard Lary rl...@us.ibm.com
diff -uNrp a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
--- a/arch/powerpc/kernel/pci_64.c 2009-07-13 14:25:24.0 -0700
+++ b/arch/powerpc/kernel/pci_64.c 2009-07-15 10:26:26.0 -0700
@@ -143,6 +143,7 @@ struct pci_dev *of_create_pci_dev(struct
dev-dev.bus = pci_bus_type;
dev-devfn = devfn;
dev-multifunction = 0; /* maybe a lie? */
+ dev-needs_freset = 0; /* pcie fundamental reset required */
dev-vendor = get_int_prop(node, vendor-id, 0x);
dev-device = get_int_prop(node, device-id, 0x);
diff -uNrp a/arch/powerpc/platforms/pseries/eeh.c
b/arch/powerpc/platforms/pseries/eeh.c
--- a/arch/powerpc/platforms/pseries/eeh.c 2009-06-09 20:05:27.0
-0700
+++ b/arch/powerpc/platforms/pseries/eeh.c 2009-07-15 10:29:04.0
-0700
@@ -744,7 +744,15 @@ int pcibios_set_pcie_reset_state(struct
static void __rtas_set_slot_reset(struct pci_dn *pdn)
{
- rtas_pci_slot_reset (pdn, 1);
+ struct pci_dev *dev = pdn-pcidev;
+
+ /* Determine type of EEH reset required by device,
+* default hot reset or fundamental reset
+*/
+ if (dev-needs_freset)
+ rtas_pci_slot_reset(pdn, 3);
+ else
+ rtas_pci_slot_reset(pdn, 1);
/* The PCI bus requires that the reset be held high for at least
* a 100 milliseconds. We wait a bit longer 'just in case'. */___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Help, please... Multi-Media Distro for PPC?
Ok so I'm really new to this but a single line answer will do, like One of the best and noob friendly PPC Multi media distributors would be _. What I have: A PPC ibook G3 laptop What I need help with: Finding a linux based multi-media workstation Why: I really want to become more savvy with linux and I need this element added to my physical studio's repertoire. My artist studio needs a computer workstation and linux seems the best way for me to go. Specifically: I've been searching around the web for a while now and have not yet found a PPC optimized(or even kind-of) distro for a multi-media studio for PPC based macs. I need some sort of: -image, video, audio editing and layering software package. So, Does this even exist? I've seen Umbutu Studio; that seems to do the job, however I've read that it would not work with my hardware, true? or is there a similar type package for PPC? Thank you all so much and any input is much appreciated! -Andrew -- View this message in context: http://www.nabble.com/Help%2C-please...-Multi-Media-Distro-for-PPC--tp24628615p24628615.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 0/6] Device table matching for SPI subsystem
Andrew, This new patch set overwrites following patches: hwmon-lm70-convert-to-device-table-matching.patch hwmon-adxx-convert-to-device-table-matching.patch spi-merge-probe-and-probe_id-callbacks.patch spi-prefix-modalias-with-spi.patch of-remove-stmm25p40-alias.patch mtd-m25p80-convert-to-device-table-matching.patch spi-add-support-for-device-table-matching.patch Changes since v1: - Implemented Ben Dooks' idea of spi_get_device_id(), so we won't call spi_match_id() twice for drivers that don't need the id. - spi: Merge probe and probe_id callbacks patch no longer needed as we don't change probe()'s arguments; - Rename spi_device_id-data to driver_data, and turn it into kernel_ulong_t to match majority of subsystems. Most drivers don't need a pointer type anyway (e.g. m25p80 needs it, but lm70 and adcxx don't); - SPI_NAME_SIZE now defined to 32 (as it should be, using 20 for name size was a cut-n-paste typo from I2C defines). Thanks! -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/6] spi: Add support for device table matching
With this patch spi drivers can use standard spi_driver.id_table and
MODULE_DEVICE_TABLE() mechanisms to bind against the devices. Just
like we do with I2C drivers.
This is useful when a single driver supports several variants of
devices but it is not possible to detect them in run-time (like
non-JEDEC chips probing in drivers/mtd/devices/m25p80.c), and
when platform_data usage is overkill.
This patch also makes life a lot easier on OpenFirmware platforms,
since with OF we extensively use proper device IDs in modaliases.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/spi/spi.c | 23 +++
include/linux/mod_devicetable.h | 10 ++
include/linux/spi/spi.h | 10 --
scripts/mod/file2alias.c| 13 +
4 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 70845cc..8518a6e 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -59,9 +59,32 @@ static struct device_attribute spi_dev_attrs[] = {
* and the sysfs version makes coldplug work too.
*/
+static const struct spi_device_id *spi_match_id(const struct spi_device_id *id,
+ const struct spi_device *sdev)
+{
+ while (id-name[0]) {
+ if (!strcmp(sdev-modalias, id-name))
+ return id;
+ id++;
+ }
+ return NULL;
+}
+
+const struct spi_device_id *spi_get_device_id(const struct spi_device *sdev)
+{
+ const struct spi_driver *sdrv = to_spi_driver(sdev-dev.driver);
+
+ return spi_match_id(sdrv-id_table, sdev);
+}
+EXPORT_SYMBOL_GPL(spi_get_device_id);
+
static int spi_match_device(struct device *dev, struct device_driver *drv)
{
const struct spi_device *spi = to_spi_device(dev);
+ const struct spi_driver *sdrv = to_spi_driver(drv);
+
+ if (sdrv-id_table)
+ return !!spi_match_id(sdrv-id_table, spi);
return strcmp(spi-modalias, drv-name) == 0;
}
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 1bf5900..b34f1ef 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -399,6 +399,16 @@ struct i2c_device_id {
__attribute__((aligned(sizeof(kernel_ulong_t;
};
+/* spi */
+
+#define SPI_NAME_SIZE 32
+
+struct spi_device_id {
+ char name[SPI_NAME_SIZE];
+ kernel_ulong_t driver_data /* Data private to the driver */
+ __attribute__((aligned(sizeof(kernel_ulong_t;
+};
+
/* dmi */
enum dmi_field {
DMI_NONE,
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index c47c4b4..2b444df 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -20,6 +20,7 @@
#define __LINUX_SPI_H
#include linux/device.h
+#include linux/mod_devicetable.h
/*
* INTERFACES between SPI master-side drivers and SPI infrastructure.
@@ -86,7 +87,7 @@ struct spi_device {
int irq;
void*controller_state;
void*controller_data;
- charmodalias[32];
+ charmodalias[SPI_NAME_SIZE];
/*
* likely need more hooks for more protocol options affecting how
@@ -145,6 +146,7 @@ struct spi_message;
/**
* struct spi_driver - Host side protocol driver
+ * @id_table: List of SPI devices supported by this driver
* @probe: Binds this driver to the spi device. Drivers can verify
* that the device is actually present, and may need to configure
* characteristics (such as bits_per_word) which weren't needed for
@@ -170,6 +172,7 @@ struct spi_message;
* MMC, RTC, filesystem character device nodes, and hardware monitoring.
*/
struct spi_driver {
+ const struct spi_device_id *id_table;
int (*probe)(struct spi_device *spi);
int (*remove)(struct spi_device *spi);
void(*shutdown)(struct spi_device *spi);
@@ -732,7 +735,7 @@ struct spi_board_info {
* controller_data goes to spi_device.controller_data,
* irq is copied too
*/
- charmodalias[32];
+ charmodalias[SPI_NAME_SIZE];
const void *platform_data;
void*controller_data;
int irq;
@@ -800,4 +803,7 @@ spi_unregister_device(struct spi_device *spi)
device_unregister(spi-dev);
}
+extern const struct spi_device_id *
+spi_get_device_id(const struct spi_device *sdev);
+
#endif /* __LINUX_SPI_H */
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 40e0045..9d446e3 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -657,6 +657,15 @@ static int do_i2c_entry(const char *filename, struct
i2c_device_id *id,
return 1;
}
+/* Looks like: S */
+static
[PATCH 3/6] of: Remove stm,m25p40 alias
The alias isn't needed any longer since the m25p80 driver converted
to the module device table matching.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/of/base.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 69f85c0..ddf224d 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -447,7 +447,6 @@ struct of_modalias_table {
static struct of_modalias_table of_modalias_table[] = {
{ fsl,mcu-mpc8349emitx, mcu-mpc8349emitx },
{ mmc-spi-slot, mmc_spi },
- { stm,m25p40, m25p80 },
};
/**
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/6] mtd: m25p80: Convert to device table matching
This patch converts the m25p80 driver so that now it uses .id_table
for device matching, making it properly detect devices on OpenFirmware
platforms (prior to this patch the driver misdetected non-JEDEC chips,
seeing all chips as m25p80).
Also, now jedec_probe() only does jedec probing, nothing else. If it
is not able to detect a chip, NULL is returned and the driver fall
backs to the information specified by the platform (platform_data, or
exact ID).
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/mtd/devices/m25p80.c | 146 +++---
1 files changed, 80 insertions(+), 66 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 10ed195..0d74b38 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -21,6 +21,7 @@
#include linux/interrupt.h
#include linux/mutex.h
#include linux/math64.h
+#include linux/mod_devicetable.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
@@ -462,8 +463,6 @@ static int m25p80_write(struct mtd_info *mtd, loff_t to,
size_t len,
*/
struct flash_info {
- char*name;
-
/* JEDEC id zero means no ID (most older chips); otherwise it has
* a high byte of zero plus three data bytes: the manufacturer id,
* then a two byte device id.
@@ -481,74 +480,83 @@ struct flash_info {
#defineSECT_4K 0x01/* OPCODE_BE_4K works uniformly
*/
};
+#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
+ ((kernel_ulong_t)(struct flash_info) { \
+ .jedec_id = (_jedec_id),\
+ .ext_id = (_ext_id),\
+ .sector_size = (_sector_size), \
+ .n_sectors = (_n_sectors), \
+ .flags = (_flags), \
+ })
/* NOTE: double check command sets and memory organization when you add
* more flash chips. This current list focusses on newer chips, which
* have been converging on command sets which including JEDEC ID.
*/
-static struct flash_info __devinitdata m25p_data [] = {
-
+static const struct spi_device_id m25p_ids[] = {
/* Atmel -- some are (confusingly) marketed as DataFlash */
- { at25fs010, 0x1f6601, 0, 32 * 1024, 4, SECT_4K, },
- { at25fs040, 0x1f6604, 0, 64 * 1024, 8, SECT_4K, },
+ { at25fs010, INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
+ { at25fs040, INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
- { at25df041a, 0x1f4401, 0, 64 * 1024, 8, SECT_4K, },
- { at25df641, 0x1f4800, 0, 64 * 1024, 128, SECT_4K, },
+ { at25df041a, INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K) },
+ { at25df641, INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K) },
- { at26f004, 0x1f0400, 0, 64 * 1024, 8, SECT_4K, },
- { at26df081a, 0x1f4501, 0, 64 * 1024, 16, SECT_4K, },
- { at26df161a, 0x1f4601, 0, 64 * 1024, 32, SECT_4K, },
- { at26df321, 0x1f4701, 0, 64 * 1024, 64, SECT_4K, },
+ { at26f004, INFO(0x1f0400, 0, 64 * 1024, 8, SECT_4K) },
+ { at26df081a, INFO(0x1f4501, 0, 64 * 1024, 16, SECT_4K) },
+ { at26df161a, INFO(0x1f4601, 0, 64 * 1024, 32, SECT_4K) },
+ { at26df321, INFO(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
/* Macronix */
- { mx25l12805d, 0xc22018, 0, 64 * 1024, 256, },
+ { mx25l12805d, INFO(0xc22018, 0, 64 * 1024, 256, 0) },
/* Spansion -- single (large) sector size only, at least
* for the chips listed here (without boot sectors).
*/
- { s25sl004a, 0x010212, 0, 64 * 1024, 8, },
- { s25sl008a, 0x010213, 0, 64 * 1024, 16, },
- { s25sl016a, 0x010214, 0, 64 * 1024, 32, },
- { s25sl032a, 0x010215, 0, 64 * 1024, 64, },
- { s25sl064a, 0x010216, 0, 64 * 1024, 128, },
-{ s25sl12800, 0x012018, 0x0300, 256 * 1024, 64, },
- { s25sl12801, 0x012018, 0x0301, 64 * 1024, 256, },
+ { s25sl004a, INFO(0x010212, 0, 64 * 1024, 8, 0) },
+ { s25sl008a, INFO(0x010213, 0, 64 * 1024, 16, 0) },
+ { s25sl016a, INFO(0x010214, 0, 64 * 1024, 32, 0) },
+ { s25sl032a, INFO(0x010215, 0, 64 * 1024, 64, 0) },
+ { s25sl064a, INFO(0x010216, 0, 64 * 1024, 128, 0) },
+ { s25sl12800, INFO(0x012018, 0x0300, 256 * 1024, 64, 0) },
+ { s25sl12801, INFO(0x012018, 0x0301, 64 * 1024, 256, 0) },
/* SST -- large erase sizes are overlays, sectors are 4K */
- { sst25vf040b, 0xbf258d, 0, 64 * 1024, 8, SECT_4K, },
- { sst25vf080b, 0xbf258e, 0, 64 * 1024, 16, SECT_4K, },
- { sst25vf016b, 0xbf2541, 0, 64 * 1024, 32, SECT_4K, },
- { sst25vf032b, 0xbf254a, 0, 64 * 1024, 64, SECT_4K, },
+ { sst25vf040b, INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K) },
+ { sst25vf080b, INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K) },
+
[PATCH 4/6] hwmon: adxx: Convert to device table matching
This patch makes the code a little bit nicer, and shorter.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/hwmon/adcxx.c | 101 -
1 files changed, 16 insertions(+), 85 deletions(-)
diff --git a/drivers/hwmon/adcxx.c b/drivers/hwmon/adcxx.c
index 242294d..5e9e095 100644
--- a/drivers/hwmon/adcxx.c
+++ b/drivers/hwmon/adcxx.c
@@ -43,6 +43,7 @@
#include linux/hwmon.h
#include linux/hwmon-sysfs.h
#include linux/mutex.h
+#include linux/mod_devicetable.h
#include linux/spi/spi.h
#define DRVNAMEadcxx
@@ -157,8 +158,9 @@ static struct sensor_device_attribute ad_input[] = {
/*--*/
-static int __devinit adcxx_probe(struct spi_device *spi, int channels)
+static int __devinit adcxx_probe(struct spi_device *spi)
{
+ int channels = spi_get_device_id(spi)-driver_data;
struct adcxx *adc;
int status;
int i;
@@ -204,26 +206,6 @@ out_err:
return status;
}
-static int __devinit adcxx1s_probe(struct spi_device *spi)
-{
- return adcxx_probe(spi, 1);
-}
-
-static int __devinit adcxx2s_probe(struct spi_device *spi)
-{
- return adcxx_probe(spi, 2);
-}
-
-static int __devinit adcxx4s_probe(struct spi_device *spi)
-{
- return adcxx_probe(spi, 4);
-}
-
-static int __devinit adcxx8s_probe(struct spi_device *spi)
-{
- return adcxx_probe(spi, 8);
-}
-
static int __devexit adcxx_remove(struct spi_device *spi)
{
struct adcxx *adc = dev_get_drvdata(spi-dev);
@@ -241,79 +223,33 @@ static int __devexit adcxx_remove(struct spi_device *spi)
return 0;
}
-static struct spi_driver adcxx1s_driver = {
- .driver = {
- .name = adcxx1s,
- .owner = THIS_MODULE,
- },
- .probe = adcxx1s_probe,
- .remove = __devexit_p(adcxx_remove),
+static const struct spi_device_id adcxx_ids[] = {
+ { adcxx1s, 1 },
+ { adcxx2s, 2 },
+ { adcxx4s, 4 },
+ { adcxx8s, 8 },
+ { },
};
+MODULE_DEVICE_TABLE(spi, adcxx_ids);
-static struct spi_driver adcxx2s_driver = {
+static struct spi_driver adcxx_driver = {
.driver = {
- .name = adcxx2s,
+ .name = adcxx,
.owner = THIS_MODULE,
},
- .probe = adcxx2s_probe,
- .remove = __devexit_p(adcxx_remove),
-};
-
-static struct spi_driver adcxx4s_driver = {
- .driver = {
- .name = adcxx4s,
- .owner = THIS_MODULE,
- },
- .probe = adcxx4s_probe,
- .remove = __devexit_p(adcxx_remove),
-};
-
-static struct spi_driver adcxx8s_driver = {
- .driver = {
- .name = adcxx8s,
- .owner = THIS_MODULE,
- },
- .probe = adcxx8s_probe,
+ .id_table = adcxx_ids,
+ .probe = adcxx_probe,
.remove = __devexit_p(adcxx_remove),
};
static int __init init_adcxx(void)
{
- int status;
- status = spi_register_driver(adcxx1s_driver);
- if (status)
- goto reg_1_failed;
-
- status = spi_register_driver(adcxx2s_driver);
- if (status)
- goto reg_2_failed;
-
- status = spi_register_driver(adcxx4s_driver);
- if (status)
- goto reg_4_failed;
-
- status = spi_register_driver(adcxx8s_driver);
- if (status)
- goto reg_8_failed;
-
- return status;
-
-reg_8_failed:
- spi_unregister_driver(adcxx4s_driver);
-reg_4_failed:
- spi_unregister_driver(adcxx2s_driver);
-reg_2_failed:
- spi_unregister_driver(adcxx1s_driver);
-reg_1_failed:
- return status;
+ return spi_register_driver(adcxx_driver);
}
static void __exit exit_adcxx(void)
{
- spi_unregister_driver(adcxx1s_driver);
- spi_unregister_driver(adcxx2s_driver);
- spi_unregister_driver(adcxx4s_driver);
- spi_unregister_driver(adcxx8s_driver);
+ spi_unregister_driver(adcxx_driver);
}
module_init(init_adcxx);
@@ -322,8 +258,3 @@ module_exit(exit_adcxx);
MODULE_AUTHOR(Marc Pignat);
MODULE_DESCRIPTION(National Semiconductor adcxx8sxxx Linux driver);
MODULE_LICENSE(GPL);
-
-MODULE_ALIAS(adcxx1s);
-MODULE_ALIAS(adcxx2s);
-MODULE_ALIAS(adcxx4s);
-MODULE_ALIAS(adcxx8s);
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/6] hwmon: lm70: Convert to device table matching
This patch makes the code a little bit nicer, and shorter.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/hwmon/lm70.c | 55 +
1 files changed, 19 insertions(+), 36 deletions(-)
diff --git a/drivers/hwmon/lm70.c b/drivers/hwmon/lm70.c
index ae6204f..ab8a5d3 100644
--- a/drivers/hwmon/lm70.c
+++ b/drivers/hwmon/lm70.c
@@ -32,6 +32,7 @@
#include linux/sysfs.h
#include linux/hwmon.h
#include linux/mutex.h
+#include linux/mod_devicetable.h
#include linux/spi/spi.h
@@ -130,11 +131,20 @@ static DEVICE_ATTR(name, S_IRUGO, lm70_show_name, NULL);
/*--*/
-static int __devinit common_probe(struct spi_device *spi, int chip)
+static int __devinit lm70_probe(struct spi_device *spi)
{
+ int chip = spi_get_device_id(spi)-driver_data;
struct lm70 *p_lm70;
int status;
+ /* signaling is SPI_MODE_0 for both LM70 and TMP121 */
+ if (spi-mode (SPI_CPOL | SPI_CPHA))
+ return -EINVAL;
+
+ /* 3-wire link (shared SI/SO) for LM70 */
+ if (chip == LM70_CHIP_LM70 !(spi-mode SPI_3WIRE))
+ return -EINVAL;
+
/* NOTE: we assume 8-bit words, and convert to 16 bits manually */
p_lm70 = kzalloc(sizeof *p_lm70, GFP_KERNEL);
@@ -170,24 +180,6 @@ out_dev_reg_failed:
return status;
}
-static int __devinit lm70_probe(struct spi_device *spi)
-{
- /* signaling is SPI_MODE_0 on a 3-wire link (shared SI/SO) */
- if ((spi-mode (SPI_CPOL | SPI_CPHA)) || !(spi-mode SPI_3WIRE))
- return -EINVAL;
-
- return common_probe(spi, LM70_CHIP_LM70);
-}
-
-static int __devinit tmp121_probe(struct spi_device *spi)
-{
- /* signaling is SPI_MODE_0 with only MISO connected */
- if (spi-mode (SPI_CPOL | SPI_CPHA))
- return -EINVAL;
-
- return common_probe(spi, LM70_CHIP_TMP121);
-}
-
static int __devexit lm70_remove(struct spi_device *spi)
{
struct lm70 *p_lm70 = dev_get_drvdata(spi-dev);
@@ -201,41 +193,32 @@ static int __devexit lm70_remove(struct spi_device *spi)
return 0;
}
-static struct spi_driver tmp121_driver = {
- .driver = {
- .name = tmp121,
- .owner = THIS_MODULE,
- },
- .probe = tmp121_probe,
- .remove = __devexit_p(lm70_remove),
+
+static const struct spi_device_id lm70_ids[] = {
+ { lm70, LM70_CHIP_LM70 },
+ { tmp121, LM70_CHIP_TMP121 },
+ { },
};
+MODULE_DEVICE_TABLE(spi, lm70_ids);
static struct spi_driver lm70_driver = {
.driver = {
.name = lm70,
.owner = THIS_MODULE,
},
+ .id_table = lm70_ids,
.probe = lm70_probe,
.remove = __devexit_p(lm70_remove),
};
static int __init init_lm70(void)
{
- int ret = spi_register_driver(lm70_driver);
- if (ret)
- return ret;
-
- ret = spi_register_driver(tmp121_driver);
- if (ret)
- spi_unregister_driver(lm70_driver);
-
- return ret;
+ return spi_register_driver(lm70_driver);
}
static void __exit cleanup_lm70(void)
{
spi_unregister_driver(lm70_driver);
- spi_unregister_driver(tmp121_driver);
}
module_init(init_lm70);
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 6/6] spi: Prefix modalias with spi:
This makes it consistent with other buses (platform, i2c, vio, ...). I'm not sure why we use the prefixes, but there must be a reason. This was easy enough to do it, and I did it. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- drivers/gpio/max7301.c |1 + drivers/gpio/mcp23s08.c|1 + drivers/hwmon/lis3lv02d_spi.c |2 +- drivers/hwmon/max.c|1 + drivers/input/touchscreen/ad7877.c |1 + drivers/input/touchscreen/ad7879.c |1 + drivers/input/touchscreen/ads7846.c|1 + drivers/leds/leds-dac124s085.c |1 + drivers/mfd/ezx-pcap.c |1 + drivers/misc/eeprom/at25.c |2 +- drivers/mmc/host/mmc_spi.c |1 + drivers/mtd/devices/mtd_dataflash.c|1 + drivers/net/enc28j60.c |1 + drivers/net/ks8851.c |1 + drivers/net/wireless/libertas/if_spi.c |1 + drivers/net/wireless/p54/p54spi.c |1 + drivers/net/wireless/wl12xx/main.c |1 + drivers/rtc/rtc-ds1305.c |1 + drivers/rtc/rtc-ds1390.c |1 + drivers/rtc/rtc-ds3234.c |1 + drivers/rtc/rtc-m41t94.c |1 + drivers/rtc/rtc-max6902.c |1 + drivers/rtc/rtc-r9701.c|1 + drivers/rtc/rtc-rs5c348.c |1 + drivers/serial/max3100.c |1 + drivers/spi/spi.c |3 ++- drivers/spi/spidev.c |1 + drivers/spi/tle62x0.c |1 + drivers/staging/stlc45xx/stlc45xx.c|1 + drivers/video/backlight/corgi_lcd.c|1 + drivers/video/backlight/ltv350qv.c |1 + drivers/video/backlight/tdo24m.c |1 + drivers/video/backlight/tosa_lcd.c |2 +- drivers/video/backlight/vgg2432a4.c|3 +-- include/linux/mod_devicetable.h|1 + scripts/mod/file2alias.c |4 ++-- 36 files changed, 38 insertions(+), 8 deletions(-) diff --git a/drivers/gpio/max7301.c b/drivers/gpio/max7301.c index 7b82eaa..480956f 100644 --- a/drivers/gpio/max7301.c +++ b/drivers/gpio/max7301.c @@ -339,3 +339,4 @@ module_exit(max7301_exit); MODULE_AUTHOR(Juergen Beisert); MODULE_LICENSE(GPL v2); MODULE_DESCRIPTION(MAX7301 SPI based GPIO-Expander); +MODULE_ALIAS(spi: DRIVER_NAME); diff --git a/drivers/gpio/mcp23s08.c b/drivers/gpio/mcp23s08.c index f6fae0e..c6c7aa1 100644 --- a/drivers/gpio/mcp23s08.c +++ b/drivers/gpio/mcp23s08.c @@ -433,3 +433,4 @@ static void __exit mcp23s08_exit(void) module_exit(mcp23s08_exit); MODULE_LICENSE(GPL); +MODULE_ALIAS(spi:mcp23s08); diff --git a/drivers/hwmon/lis3lv02d_spi.c b/drivers/hwmon/lis3lv02d_spi.c index 3827ff0..b7aed07 100644 --- a/drivers/hwmon/lis3lv02d_spi.c +++ b/drivers/hwmon/lis3lv02d_spi.c @@ -112,4 +112,4 @@ module_exit(lis302dl_exit); MODULE_AUTHOR(Daniel Mack dan...@caiaq.de); MODULE_DESCRIPTION(lis3lv02d SPI glue layer); MODULE_LICENSE(GPL); - +MODULE_ALIAS(spi: DRV_NAME); diff --git a/drivers/hwmon/max.c b/drivers/hwmon/max.c index bfaa665..9ac4972 100644 --- a/drivers/hwmon/max.c +++ b/drivers/hwmon/max.c @@ -242,3 +242,4 @@ module_exit(max_exit); MODULE_AUTHOR(Eric Miao eric.m...@marvell.com); MODULE_DESCRIPTION(MAX ADC Driver); MODULE_LICENSE(GPL); +MODULE_ALIAS(spi:max); diff --git a/drivers/input/touchscreen/ad7877.c b/drivers/input/touchscreen/ad7877.c index ecaeb7e..eb83939 100644 --- a/drivers/input/touchscreen/ad7877.c +++ b/drivers/input/touchscreen/ad7877.c @@ -842,3 +842,4 @@ module_exit(ad7877_exit); MODULE_AUTHOR(Michael Hennerich henner...@blackfin.uclinux.org); MODULE_DESCRIPTION(AD7877 touchscreen Driver); MODULE_LICENSE(GPL); +MODULE_ALIAS(spi:ad7877); diff --git a/drivers/input/touchscreen/ad7879.c b/drivers/input/touchscreen/ad7879.c index 5d8a703..19b4db7 100644 --- a/drivers/input/touchscreen/ad7879.c +++ b/drivers/input/touchscreen/ad7879.c @@ -779,3 +779,4 @@ module_exit(ad7879_exit); MODULE_AUTHOR(Michael Hennerich henner...@blackfin.uclinux.org); MODULE_DESCRIPTION(AD7879(-1) touchscreen Driver); MODULE_LICENSE(GPL); +MODULE_ALIAS(spi:ad7879); diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c index ba9d38c..09c8109 100644 --- a/drivers/input/touchscreen/ads7846.c +++ b/drivers/input/touchscreen/ads7846.c @@ -1256,3 +1256,4 @@ module_exit(ads7846_exit); MODULE_DESCRIPTION(ADS7846 TouchScreen Driver); MODULE_LICENSE(GPL); +MODULE_ALIAS(spi:ads7846); diff --git a/drivers/leds/leds-dac124s085.c b/drivers/leds/leds-dac124s085.c index 098d9aa..2913d76 100644 --- a/drivers/leds/leds-dac124s085.c +++ b/drivers/leds/leds-dac124s085.c @@ -148,3 +148,4 @@ module_exit(dac124s085_leds_exit); MODULE_AUTHOR(Guennadi Liakhovetski l...@denx.de); MODULE_DESCRIPTION(DAC124S085 LED driver); MODULE_LICENSE(GPL v2); +MODULE_ALIAS(spi:dac124s085); diff --git
Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC
On Thu, Jul 30, 2009 at 04:08:49PM -0400, Josh Boyer wrote:
On Thu, Jul 30, 2009 at 03:45:06PM -0400, Solomon Peachy wrote:
On Thu, Jul 30, 2009 at 10:06:30AM -0400, Josh Boyer wrote:
[snip]
+ UART0: ser...@ef600400 {
+ device_type = serial;
+ compatible = ns16550;
+ reg = 0xef600400 0x0008;
+ virtual-reg = 0xef600400;
+ clock-frequency = 0; /* Filled in by zImage */
+ current-speed = 0x9600;
Just a question, but is the baud supposed to be 38400 or 9600? At first
glance
it almost seems like a typo :).
It's supposed to be 38400 baud, hence the explicit 0x in front. (I lost
count of the number of times I saw '38400' listed in various dts
files...)
Cool. Just checking.
Um.. except, surely it's clearer to just list 38400 in decimal, rather
than 0x9600 which people are very likely to misread as 9600.
--
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@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Help, please... Multi-Media Distro for PPC?
On Thu, Jul 30, 2009 at 07:33:24AM -0700, skateaboard wrote: Ok so I'm really new to this but a single line answer will do, like One of the best and noob friendly PPC Multi media distributors would be _. What I have: A PPC ibook G3 laptop What I need help with: Finding a linux based multi-media workstation Why: I really want to become more savvy with linux and I need this element added to my physical studio's repertoire. My artist studio needs a computer workstation and linux seems the best way for me to go. Specifically: I've been searching around the web for a while now and have not yet found a PPC optimized(or even kind-of) distro for a multi-media studio for PPC based macs. I need some sort of: -image, video, audio editing and layering software package. So, Does this even exist? I've seen Umbutu Studio; that seems to do the I don't think you are going to find any distro that will work sufficiently well on that class of hardware to do what you are attempting. A G3 is pretty old... I don't know how much RAM and what CPU you have, but the only base distros I know of that would work there are probably gentoo, debian, or for a long shot Fedora. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC
On Fri, Jul 31, 2009 at 10:45:24AM +1000, David Gibson wrote:
On Thu, Jul 30, 2009 at 04:08:49PM -0400, Josh Boyer wrote:
On Thu, Jul 30, 2009 at 03:45:06PM -0400, Solomon Peachy wrote:
On Thu, Jul 30, 2009 at 10:06:30AM -0400, Josh Boyer wrote:
[snip]
+UART0: ser...@ef600400 {
+device_type = serial;
+compatible = ns16550;
+reg = 0xef600400 0x0008;
+virtual-reg = 0xef600400;
+clock-frequency = 0; /* Filled in by
zImage */
+current-speed = 0x9600;
Just a question, but is the baud supposed to be 38400 or 9600? At first
glance
it almost seems like a typo :).
It's supposed to be 38400 baud, hence the explicit 0x in front. (I lost
count of the number of times I saw '38400' listed in various dts
files...)
Cool. Just checking.
Um.. except, surely it's clearer to just list 38400 in decimal, rather
than 0x9600 which people are very likely to misread as 9600.
That was my point, yes. It is clearer, yes. It's his board though, so I'm
not going to nit-pick about it.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/20] powerpc/mm: Add HW threads support to no_hash TLB management
On Jul 24, 2009, at 4:15 AM, Benjamin Herrenschmidt wrote: The current no hash MMU context management code is written with the assumption that one CPU == one TLB. This is not the case on implementations that support HW multithreading, where several linux CPUs can share the same TLB. This adds some basic support for this to our context management and our TLB flushing code. It also cleans up the optional debugging output a bit Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- I'm getting this nice oops on 32-bit book-e SMP (and I'm guessing its because of this patch) Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc0016dac Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=8 MPC8572 DS Modules linked in: NIP: c0016dac LR: c0016d58 CTR: 001e REGS: eed77ce0 TRAP: 0300 Not tainted (2.6.31-rc4-00442-gdb4c9c5) MSR: 00021000 ME,CE CR: 24288482 XER: 2000 DEAR: , ESR: TASK = eecfe140[1581] 'msgctl08' THREAD: eed76000 CPU: 0 GPR00: 0040 eed77d90 eecfe140 0001 c05bf074 c05c0cf4 GPR08: 0003 0002 ff7f 9b05 1004f894 c05bdd24 0001 GPR16: c05ab890 c05c0ce8 c04e0f58 c04da364 c05c c04cfa04 GPR24: 0002 c05c0cd8 0080 ef056380 0017 NIP [c0016dac] switch_mmu_context+0x15c/0x520 LR [c0016d58] switch_mmu_context+0x108/0x520 Call Trace: [eed77d90] [c0016d58] switch_mmu_context+0x108/0x520 (unreliable) [eed77df0] [c040efec] schedule+0x2bc/0x800 [eed77e70] [c01b9268] do_msgrcv+0x198/0x420 [eed77ef0] [c01b9520] sys_msgrcv+0x30/0xa0 [eed77f10] [c0003fe8] sys_ipc+0x1a8/0x2c0 [eed77f40] [c00116c4] ret_from_syscall+0x0/0x3c Instruction dump: 57402834 7c00f850 3920fffe 5d2a003e 397b0010 5500103a 7ceb0214 6000 6000 8167 39080001 38e70004 7c0be82e 7c005038 7c0be92e 8126 ---[ end trace 3c4c3106446e1bd8 ]--- - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/20] powerpc/mm: Add HW threads support to no_hash TLB management
On Jul 30, 2009, at 10:12 PM, Kumar Gala wrote:
On Jul 24, 2009, at 4:15 AM, Benjamin Herrenschmidt wrote:
The current no hash MMU context management code is written with
the assumption that one CPU == one TLB. This is not the case on
implementations that support HW multithreading, where several
linux CPUs can share the same TLB.
This adds some basic support for this to our context management
and our TLB flushing code.
It also cleans up the optional debugging output a bit
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
I'm getting this nice oops on 32-bit book-e SMP (and I'm guessing
its because of this patch)
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0016dac
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=8 MPC8572 DS
Modules linked in:
NIP: c0016dac LR: c0016d58 CTR: 001e
REGS: eed77ce0 TRAP: 0300 Not tainted (2.6.31-rc4-00442-gdb4c9c5)
MSR: 00021000 ME,CE CR: 24288482 XER: 2000
DEAR: , ESR:
TASK = eecfe140[1581] 'msgctl08' THREAD: eed76000 CPU: 0
GPR00: 0040 eed77d90 eecfe140 0001
c05bf074 c05c0cf4
GPR08: 0003 0002 ff7f 9b05 1004f894
c05bdd24 0001
GPR16: c05ab890 c05c0ce8 c04e0f58 c04da364 c05c
c04cfa04
GPR24: 0002 c05c0cd8 0080
ef056380 0017
NIP [c0016dac] switch_mmu_context+0x15c/0x520
LR [c0016d58] switch_mmu_context+0x108/0x520
Call Trace:
[eed77d90] [c0016d58] switch_mmu_context+0x108/0x520 (unreliable)
[eed77df0] [c040efec] schedule+0x2bc/0x800
[eed77e70] [c01b9268] do_msgrcv+0x198/0x420
[eed77ef0] [c01b9520] sys_msgrcv+0x30/0xa0
[eed77f10] [c0003fe8] sys_ipc+0x1a8/0x2c0
[eed77f40] [c00116c4] ret_from_syscall+0x0/0x3c
Instruction dump:
57402834 7c00f850 3920fffe 5d2a003e 397b0010 5500103a 7ceb0214
6000
6000 8167 39080001 38e70004 7c0be82e 7c005038 7c0be92e
8126
---[ end trace 3c4c3106446e1bd8 ]---
On Jul 24, 2009, at 4:15 AM, Benjamin Herrenschmidt wrote:
@@ -247,15 +261,20 @@ void switch_mmu_context(struct mm_struct
* local TLB for it and unmark it before we use it
*/
if (test_bit(id, stale_map[cpu])) {
- pr_devel([%d] flushing stale context %d for mm @%p !\n,
-cpu, id, next);
+ pr_hardcont( | stale flush %d [%d..%d],
+ id, cpu_first_thread_in_core(cpu),
+ cpu_last_thread_in_core(cpu));
+
local_flush_tlb_mm(next);
/* XXX This clear should ultimately be part of
local_flush_tlb_mm */
- __clear_bit(id, stale_map[cpu]);
+ for (cpu = cpu_first_thread_in_core(cpu);
+cpu = cpu_last_thread_in_core(cpu); cpu++)
+ __clear_bit(id, stale_map[cpu]);
}
This looks a bit dodgy. using 'cpu' as both the loop variable and
what you are computing to determine loop start/end..
Changing this to:
unsigned int i;
...
for (i = cpu_first_thread_in_core(cpu);
i = cpu_last_thread_in_core(cpu); i++)
__clear_bit(id, stale_map[i]);
seems to clear up the oops.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
