* regarding lspci
From: rahul @ 2006-07-11 9:29 UTC (permalink / raw)
To: linuxppc-embedded list, ilugc
Hi All
My target system is powerpc , linux-2.6.11.
when i give the lspci in my target system , it says "can't find the
command".
I have seen in the ramdisk directory, i could not see the lspci utility
or pci utilities. Even in the busybox i could not find the utility.
In linux i have enabled the pci support.
How to get the utility to busybox. I have searched in the net but could
not succeed.
Can anyone please help me in this regard. plz correct me if i am missing
some basic configuration .
Thanks & Regards
Rahul
^ permalink raw reply
* OpenIPMI for ppc
From: salvatore cusenza @ 2006-07-11 8:10 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 219 bytes --]
Hi,
I'm trying to cross-compile OpenIPMI-1.4.27 library for ppc (MPC852 and
linux-2.4.20 Denk's distribution).
I have not found so far suggestions about building and configuring OpenIPMI
for ppc.
Could anybody help me?
[-- Attachment #2: Type: text/html, Size: 263 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Xserve cpu-meter LEDs
From: Benjamin Herrenschmidt @ 2006-07-11 5:04 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: debian-powerpc@lists.debian.org
This is a very preliminary driver for the front-panel CPU-meter blue
LEDs of the Xserve. I've tested it on an Xserve G5, though it should
work on the old G4 ones as well.
It's a bit rough at the moment. I want to add a proper PWM to the DMA
sample buffers in order to have a per-LED intensity value so we can make
smoother/funnier things with the LEDs (right now it's 0 or 0xff -> off
or on) and I want to add a userland interface that allows to mmap the
"user buffer" (which contains per-LED 8 bits samples containing an
intensity) in which case the in-kernel CPU-meter control would get
disabled and userland would be free to do whatever it wants.
Also, the CPU-meter thing itself is also a bit simplistic, one may want
to transform the load value through a nice curve and
But that's a first cut and I won't have time to hack on it for some time
now (at least til end of august) so if somebody else wants to play with
it, feel free and send me patches :)
Index: linux-irq-work/drivers/macintosh/rack-meter.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-irq-work/drivers/macintosh/rack-meter.c 2006-07-11 14:58:22.000000000 +1000
@@ -0,0 +1,539 @@
+#define DEBUG
+
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/dma-mapping.h>
+#include <linux/kernel_stat.h>
+
+#include <asm/io.h>
+#include <asm/prom.h>
+#include <asm/machdep.h>
+#include <asm/pmac_feature.h>
+#include <asm/dbdma.h>
+#include <asm/dbdma.h>
+#include <asm/macio.h>
+#include <asm/keylargo.h>
+
+/* Number of samples in a sample buffer */
+#define SAMPLE_COUNT 256
+
+/* CPU meter sampling rate in ms */
+#define CPU_SAMPLING_RATE 250
+
+struct rackmeter_dma {
+ struct dbdma_cmd cmd[4] ____cacheline_aligned;
+ u32 mark ____cacheline_aligned;
+ u32 buf1[SAMPLE_COUNT] ____cacheline_aligned;
+ u32 buf2[SAMPLE_COUNT] ____cacheline_aligned;
+} ____cacheline_aligned;
+
+struct rackmeter_cpu {
+ struct work_struct sniffer;
+ cputime64_t prev_wall;
+ cputime64_t prev_idle;
+} ____cacheline_aligned;
+
+struct rackmeter {
+ struct macio_dev *mdev;
+ unsigned int irq;
+ struct device_node *i2s;
+ u8 *ubuf;
+ struct dbdma_regs __iomem *dma_regs;
+ void __iomem *i2s_regs;
+ dma_addr_t dma_buf_p;
+ struct rackmeter_dma *dma_buf_v;
+ int stale_irq;
+ struct rackmeter_cpu cpu[2];
+};
+
+/* To be set as a tunable */
+static int rackmeter_ignore_nice;
+
+/* This GPIO is whacked by the OS X driver when initializing */
+#define RACKMETER_MAGIC_GPIO 0x78
+
+/* This is copied from cpufreq_ondemand, maybe we should put it in
+ * a common header somewhere
+ */
+static inline cputime64_t get_cpu_idle_time(unsigned int cpu)
+{
+ cputime64_t retval;
+
+ retval = cputime64_add(kstat_cpu(cpu).cpustat.idle,
+ kstat_cpu(cpu).cpustat.iowait);
+
+ if (rackmeter_ignore_nice)
+ retval = cputime64_add(retval, kstat_cpu(cpu).cpustat.nice);
+
+ return retval;
+}
+
+static void rackmeter_setup_i2s(struct rackmeter *rm)
+{
+ struct macio_chip *macio = rm->mdev->bus->chip;
+
+ /* First whack magic GPIO */
+ pmac_do_feature_call(PMAC_FTR_WRITE_GPIO, NULL,
+ RACKMETER_MAGIC_GPIO, 5);
+
+
+ /* Call feature code to enable the sound channel and the proper
+ * clock sources
+ */
+ pmac_do_feature_call(PMAC_FTR_SOUND_CHIP_ENABLE, rm->i2s, 0, 1);
+
+ /* Power i2s and stop i2s clock. We whack MacIO FCRs directly for now.
+ * This is a bit racy, thus we should add new platform functions to
+ * handle that. snd-aoa needs that too
+ */
+ MACIO_BIS(KEYLARGO_FCR1, KL1_I2S0_ENABLE);
+ MACIO_BIC(KEYLARGO_FCR1, KL1_I2S0_CLK_ENABLE_BIT);
+ (void)MACIO_IN32(KEYLARGO_FCR1);
+ udelay(10);
+
+ /* Then setup i2s. For now, we use the same magic value that
+ * the OS X driver seems to use. We might want to play around
+ * with the clock divisors later
+ */
+ out_le32(rm->i2s_regs + 0x10, 0x01fa0000);
+ (void)in_le32(rm->i2s_regs + 0x10);
+ udelay(10);
+
+ /* Fully restart i2s*/
+ MACIO_BIS(KEYLARGO_FCR1, KL1_I2S0_CELL_ENABLE |
+ KL1_I2S0_CLK_ENABLE_BIT);
+ (void)MACIO_IN32(KEYLARGO_FCR1);
+ udelay(10);
+}
+
+static void rackmeter_set_default_pattern(struct rackmeter *rm)
+{
+ int i;
+
+ for (i = 0; i < 16; i++) {
+ if (i < 8)
+ rm->ubuf[i] = (i & 1) * 255;
+ else
+ rm->ubuf[i] = ((~i) & 1) * 255;
+ }
+}
+
+static void rackmeter_setup_dbdma(struct rackmeter *rm)
+{
+ struct rackmeter_dma *db = rm->dma_buf_v;
+ struct dbdma_cmd *cmd = db->cmd;
+
+ /* Make sure dbdma is reset */
+ DBDMA_DO_RESET(rm->dma_regs);
+
+ db->mark = 0;
+
+ pr_debug("rackmeter: mark offset=0x%lx\n",
+ offsetof(struct rackmeter_dma, mark));
+ pr_debug("rackmeter: buf1 offset=0x%lx\n",
+ offsetof(struct rackmeter_dma, buf1));
+ pr_debug("rackmeter: buf2 offset=0x%lx\n",
+ offsetof(struct rackmeter_dma, buf2));
+
+ /* Prepare 4 dbdma commands for the 2 buffers */
+ memset(cmd, 0, 4 * sizeof(struct dbdma_cmd));
+ st_le16(&cmd->req_count, 4);
+ st_le16(&cmd->command, STORE_WORD | INTR_ALWAYS | KEY_SYSTEM);
+ st_le32(&cmd->phy_addr, rm->dma_buf_p +
+ offsetof(struct rackmeter_dma, mark));
+ st_le32(&cmd->cmd_dep, 0x02000000);
+ cmd++;
+
+ st_le16(&cmd->req_count, SAMPLE_COUNT * 4);
+ st_le16(&cmd->command, OUTPUT_MORE);
+ st_le32(&cmd->phy_addr, rm->dma_buf_p +
+ offsetof(struct rackmeter_dma, buf1));
+ cmd++;
+
+ st_le16(&cmd->req_count, 4);
+ st_le16(&cmd->command, STORE_WORD | INTR_ALWAYS | KEY_SYSTEM);
+ st_le32(&cmd->phy_addr, rm->dma_buf_p +
+ offsetof(struct rackmeter_dma, mark));
+ st_le32(&cmd->cmd_dep, 0x01000000);
+ cmd++;
+
+ st_le16(&cmd->req_count, SAMPLE_COUNT * 4);
+ st_le16(&cmd->command, OUTPUT_MORE | BR_ALWAYS);
+ st_le32(&cmd->phy_addr, rm->dma_buf_p +
+ offsetof(struct rackmeter_dma, buf2));
+ st_le32(&cmd->cmd_dep, rm->dma_buf_p);
+
+ /* Program the DBDMA and start it */
+ mb();
+ out_le32(&rm->dma_regs->cmdptr_hi, 0);
+ out_le32(&rm->dma_regs->cmdptr, rm->dma_buf_p);
+ out_le32(&rm->dma_regs->control, (RUN << 16) | RUN);
+}
+
+static void rackmeter_do_timer(void *data)
+{
+ struct rackmeter *rm = data;
+ unsigned int cpu = smp_processor_id();
+ struct rackmeter_cpu *rcpu = &rm->cpu[cpu];
+ cputime64_t cur_jiffies, total_idle_ticks;
+ unsigned int total_ticks, idle_ticks;
+ int i, offset, load;
+
+ cur_jiffies = jiffies64_to_cputime64(get_jiffies_64());
+ total_ticks = (unsigned int)cputime64_sub(cur_jiffies,
+ rcpu->prev_wall);
+ rcpu->prev_wall = cur_jiffies;
+
+ total_idle_ticks = get_cpu_idle_time(cpu);
+ idle_ticks = (unsigned int) cputime64_sub(total_idle_ticks,
+ rcpu->prev_idle);
+ rcpu->prev_idle = total_idle_ticks;
+
+ /* We do a very dumb calculation to update the LEDs for now,
+ * we'll do better once we have actual PWM implemented
+ */
+ load = (8 * (total_ticks - idle_ticks)) / total_ticks;
+
+ offset = cpu << 3;
+ for (i = 0; i < 8; i++)
+ rm->ubuf[i + offset] = (load > i) ? 0xff : 0;
+
+ schedule_delayed_work_on(cpu, &rcpu->sniffer,
+ msecs_to_jiffies(CPU_SAMPLING_RATE));
+}
+
+static void rackmeter_init_cpu_sniffer(struct rackmeter *rm)
+{
+ unsigned int cpu;
+
+ /* This driver works only with 1 or 2 CPUs numbered 0 and 1,
+ * but that's really all we have on Apple Xserve
+ */
+ for_each_online_cpu(cpu) {
+ struct rackmeter_cpu *rcpu;
+
+ if (cpu > 1)
+ continue;
+ rcpu = &rm->cpu[cpu];;
+ INIT_WORK(&rcpu->sniffer, rackmeter_do_timer, rm);
+ rcpu->prev_idle = get_cpu_idle_time(cpu);
+ rcpu->prev_wall = jiffies64_to_cputime64(get_jiffies_64());
+ schedule_delayed_work_on(cpu, &rm->cpu[cpu].sniffer,
+ msecs_to_jiffies(CPU_SAMPLING_RATE));
+ }
+}
+
+static int rackmeter_setup(struct rackmeter *rm)
+{
+ pr_debug("rackmeter: setting up i2s..\n");
+ rackmeter_setup_i2s(rm);
+
+ pr_debug("rackmeter: setting up default pattern..\n");
+ rackmeter_set_default_pattern(rm);
+
+ pr_debug("rackmeter: setting up dbdma..\n");
+ rackmeter_setup_dbdma(rm);
+
+ pr_debug("rackmeter: start CPU measurements..\n");
+ rackmeter_init_cpu_sniffer(rm);
+
+ printk(KERN_INFO "RackMeter initialized\n");
+
+ return 0;
+}
+
+/* XXX FIXME: No PWM yet, this is 0/1 */
+static u32 rackmeter_calc_sample(struct rackmeter *rm, unsigned int index)
+{
+ int led;
+ u32 sample = 0;
+
+ for (led = 0; led < 16; led++) {
+ sample >>= 1;
+ sample |= ((rm->ubuf[led] >= 0x80) << 15);
+ }
+ return (sample << 17) | (sample >> 15);
+}
+
+static irqreturn_t rackmeter_irq(int irq, void *arg, struct pt_regs *regs)
+{
+ struct rackmeter *rm = arg;
+ struct rackmeter_dma *db = rm->dma_buf_v;
+ unsigned int mark, i;
+ u32 *buf;
+
+ /* Flush PCI buffers with an MMIO read. Maybe we could actually
+ * check the status one day ... in case things go wrong, though
+ * this never happened to me
+ */
+ (void)in_le32(&rm->dma_regs->status);
+
+ /* Make sure the CPU gets us in order */
+ rmb();
+
+ /* Read mark */
+ mark = db->mark;
+ if (mark != 1 && mark != 2) {
+ printk(KERN_WARNING "rackmeter: Incorrect DMA mark 0x%08x\n",
+ mark);
+ /* We allow for 3 errors like that (stale DBDMA irqs) */
+ if (++rm->stale_irq > 3) {
+ printk(KERN_ERR "rackmeter: Too many errors,"
+ " stopping DMA\n");
+ DBDMA_DO_RESET(rm->dma_regs);
+ }
+ return IRQ_HANDLED;
+ }
+
+ /* Next buffer we need to fill is mark value */
+ buf = mark == 1 ? db->buf1 : db->buf2;
+
+ /* Fill it now. This routine converts the 8 bits depth sample array
+ * into the PWM bitmap for each LED.
+ */
+ for (i = 0; i < SAMPLE_COUNT; i++)
+ buf[i] = rackmeter_calc_sample(rm, i);
+
+
+ return IRQ_HANDLED;
+}
+
+static int rackmeter_probe(struct macio_dev* mdev,
+ const struct of_device_id *match)
+{
+ struct device_node *i2s = NULL, *np = NULL;
+ struct rackmeter *rm = NULL;
+ struct resource ri2s, rdma;
+ int rc = -ENODEV;
+
+ pr_debug("rackmeter_probe()\n");
+
+ /* Get i2s-a node */
+ while ((i2s = of_get_next_child(mdev->ofdev.node, i2s)) != NULL)
+ if (strcmp(i2s->name, "i2s-a") == 0)
+ break;
+ if (i2s == NULL) {
+ pr_debug(" i2s-a child not found\n");
+ goto bail;
+ }
+ /* Get lightshow or virtual sound */
+ while ((np = of_get_next_child(i2s, np)) != NULL) {
+ if (strcmp(np->name, "lightshow") == 0)
+ break;
+ if ((strcmp(np->name, "sound") == 0) &&
+ get_property(np, "virtual", NULL) != NULL)
+ break;
+ }
+ if (np == NULL) {
+ pr_debug(" lightshow or sound+virtual child not found\n");
+ goto bail;
+ }
+
+ /* Create and initialize our instance data */
+ rm = kzalloc(sizeof(struct rackmeter), GFP_KERNEL);
+ if (rm == NULL) {
+ printk(KERN_ERR "rackmeter: failed to allocate memory !\n");
+ rc = -ENOMEM;
+ goto bail_release;
+ }
+ rm->mdev = mdev;
+ rm->i2s = i2s;
+ dev_set_drvdata(&mdev->ofdev.dev, rm);
+ /* Check resources availability. We need at least resource 0 and 1 */
+#if 0 /* Use that when i2s-a is finally an mdev per-se */
+ if (macio_resource_count(mdev) < 2 || macio_irq_count(mdev) < 2) {
+ printk(KERN_ERR
+ "rackmeter: found match but lacks resources: %s"
+ " (%d resources, %d interrupts)\n",
+ mdev->ofdev.node->full_name);
+ rc = -ENXIO;
+ goto bail_free;
+ }
+ if (macio_request_resources(mdev, "rackmeter")) {
+ printk(KERN_ERR
+ "rackmeter: failed to request resources: %s\n",
+ mdev->ofdev.node->full_name);
+ rc = -EBUSY;
+ goto bail_free;
+ }
+ rm->irq = macio_irq(mdev, 1);
+#else
+ rm->irq = irq_of_parse_and_map(i2s, 1);
+ if (rm->irq == NO_IRQ ||
+ of_address_to_resource(i2s, 0, &ri2s) ||
+ of_address_to_resource(i2s, 1, &rdma)) {
+ printk(KERN_ERR
+ "rackmeter: found match but lacks resources: %s",
+ mdev->ofdev.node->full_name);
+ rc = -ENXIO;
+ goto bail_free;
+ }
+#endif
+
+ pr_debug(" i2s @0x%08x\n", (unsigned int)ri2s.start);
+ pr_debug(" dma @0x%08x\n", (unsigned int)rdma.start);
+ pr_debug(" irq %d\n", rm->irq);
+
+ rm->ubuf = (u8 *)__get_free_page(GFP_KERNEL);
+ if (rm->ubuf == NULL) {
+ printk(KERN_ERR
+ "rackmeter: failed to allocate samples page !\n");
+ rc = -ENOMEM;
+ goto bail_release;
+ }
+
+ rm->dma_buf_v = dma_alloc_coherent(&macio_get_pci_dev(mdev)->dev,
+ sizeof(struct rackmeter_dma),
+ &rm->dma_buf_p, GFP_KERNEL);
+ if (rm->dma_buf_v == NULL) {
+ printk(KERN_ERR
+ "rackmeter: failed to allocate dma buffer !\n");
+ rc = -ENOMEM;
+ goto bail_free_samples;
+ }
+#if 0
+ rm->i2s_regs = ioremap(macio_resource_start(mdev, 0), 0x1000);
+#else
+ rm->i2s_regs = ioremap(ri2s.start, 0x1000);
+#endif
+ if (rm->i2s_regs == NULL) {
+ printk(KERN_ERR
+ "rackmeter: failed to map i2s registers !\n");
+ rc = -ENXIO;
+ goto bail_free_dma;
+ }
+#if 0
+ rm->dma_regs = ioremap(macio_resource_start(mdev, 1), 0x100);
+#else
+ rm->dma_regs = ioremap(rdma.start, 0x100);
+#endif
+ if (rm->dma_regs == NULL) {
+ printk(KERN_ERR
+ "rackmeter: failed to map dma registers !\n");
+ rc = -ENXIO;
+ goto bail_unmap_i2s;
+ }
+
+ rc = rackmeter_setup(rm);
+ if (rc) {
+ printk(KERN_ERR
+ "rackmeter: failed to initialize !\n");
+ rc = -ENXIO;
+ goto bail_unmap_dma;
+ }
+
+ rc = request_irq(rm->irq, rackmeter_irq, 0, "rackmeter", rm);
+ if (rc != 0) {
+ printk(KERN_ERR
+ "rackmeter: failed to request interrupt !\n");
+ goto bail_stop_dma;
+ }
+ of_node_put(np);
+ return 0;
+
+ bail_stop_dma:
+ DBDMA_DO_RESET(rm->dma_regs);
+ bail_unmap_dma:
+ iounmap(rm->dma_regs);
+ bail_unmap_i2s:
+ iounmap(rm->i2s_regs);
+ bail_free_dma:
+ dma_free_coherent(&macio_get_pci_dev(mdev)->dev,
+ sizeof(struct rackmeter_dma),
+ rm->dma_buf_v, rm->dma_buf_p);
+ bail_free_samples:
+ free_page((unsigned long)rm->ubuf);
+ bail_release:
+#if 0
+ macio_release_resources(mdev);
+#endif
+ bail_free:
+ kfree(rm);
+ bail:
+ of_node_put(i2s);
+ of_node_put(np);
+ dev_set_drvdata(&mdev->ofdev.dev, NULL);
+ return rc;
+}
+
+static int rackmeter_remove(struct macio_dev* mdev)
+{
+ struct rackmeter *rm = dev_get_drvdata(&mdev->ofdev.dev);
+
+ /* Clear reference to private data */
+ dev_set_drvdata(&mdev->ofdev.dev, NULL);
+
+ /* Stop/reset dbdma */
+ DBDMA_DO_RESET(rm->dma_regs);
+
+ /* Release the IRQ */
+ free_irq(rm->irq, rm);
+
+ /* Unmap registers */
+ iounmap(rm->dma_regs);
+ iounmap(rm->i2s_regs);
+
+ /* Free DMA */
+ dma_free_coherent(&macio_get_pci_dev(mdev)->dev,
+ sizeof(struct rackmeter_dma),
+ rm->dma_buf_v, rm->dma_buf_p);
+
+ /* Free samples */
+ free_page((unsigned long)rm->ubuf);
+
+#if 0
+ /* Release resources */
+ macio_release_resources(mdev);
+#endif
+
+ /* Get rid of me */
+ kfree(rm);
+
+ return 0;
+}
+
+static int rackmeter_shutdown(struct macio_dev* dev)
+{
+ return 0;
+}
+
+static struct of_device_id rackmeter_match[] = {
+ { .name = "i2s" },
+ { }
+};
+
+static struct macio_driver rackmeter_drv = {
+ .name = "rackmeter",
+ .owner = THIS_MODULE,
+ .match_table = rackmeter_match,
+ .probe = rackmeter_probe,
+ .remove = rackmeter_remove,
+ .shutdown = rackmeter_shutdown,
+};
+
+
+static int __init rackmeter_init(void)
+{
+ pr_debug("rackmeter_init()\n");
+
+ return macio_register_driver(&rackmeter_drv);
+}
+
+static void __exit rackmeter_exit(void)
+{
+ pr_debug("rackmeter_exit()\n");
+
+ macio_unregister_driver(&rackmeter_drv);
+}
+
+module_init(rackmeter_init);
+module_exit(rackmeter_exit);
+
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Benjamin Herrenschmidt <benh@kernel.crashing.org>");
+MODULE_DESCRIPTION("RackMeter: Support vu-meter on XServe front panel");
Index: linux-irq-work/drivers/macintosh/Kconfig
===================================================================
--- linux-irq-work.orig/drivers/macintosh/Kconfig 2006-07-10 16:12:38.000000000 +1000
+++ linux-irq-work/drivers/macintosh/Kconfig 2006-07-10 16:45:50.000000000 +1000
@@ -218,4 +218,11 @@
tristate "Support for ANS LCD display"
depends on ADB_CUDA && PPC_PMAC
+config PMAC_RACKMETER
+ tristate "Support for Apple XServe front panel LEDs"
+ depends on PPC_PMAC
+ help
+ This driver procides some support to control the front panel
+ blue LEDs "vu-meter" of the XServer macs.
+
endmenu
Index: linux-irq-work/drivers/macintosh/Makefile
===================================================================
--- linux-irq-work.orig/drivers/macintosh/Makefile 2006-07-10 16:12:38.000000000 +1000
+++ linux-irq-work/drivers/macintosh/Makefile 2006-07-10 16:45:50.000000000 +1000
@@ -42,3 +42,4 @@
windfarm_smu_sensors.o \
windfarm_max6690_sensor.o \
windfarm_lm75_sensor.o windfarm_pid.o
+obj-$(CONFIG_PMAC_RACKMETER) += rack-meter.o
Index: linux-irq-work/include/asm-powerpc/dbdma.h
===================================================================
--- linux-irq-work.orig/include/asm-powerpc/dbdma.h 2006-07-10 16:12:38.000000000 +1000
+++ linux-irq-work/include/asm-powerpc/dbdma.h 2006-07-10 16:45:50.000000000 +1000
@@ -95,7 +95,13 @@
#define DBDMA_DO_STOP(regs) do { \
out_le32(&((regs)->control), (RUN|FLUSH)<<16); \
while(in_le32(&((regs)->status)) & (ACTIVE|FLUSH)) \
- ; \
+ ; \
+} while(0)
+
+#define DBDMA_DO_RESET(regs) do { \
+ out_le32(&((regs)->control), (ACTIVE|DEAD|WAKE|FLUSH|PAUSE|RUN)<<16);\
+ while(in_le32(&((regs)->status)) & (RUN)) \
+ ; \
} while(0)
#endif /* _ASM_DBDMA_H_ */
^ permalink raw reply
* Re: [PATCH] powerpc: unify 32 and 64bit panic_on_oops messages
From: Horms @ 2006-07-11 1:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Anton Blanchard
In-Reply-To: <20060706101521.GE26612@verge.net.au>
First up, sorry for the silly subject in the original post, that was an
error.
Secondly, when I sent the x86_64 version of this patch Andi Kleen
pointed out that calling ssleep() will just cause an early panic if the
code is in interrupt context. Accordingly, I plan to post patches to
remoove the ssleep(). So please ignore the patch that is bellow.
Thanks
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
On Thu, 6 Jul 2006 19:15:22 +0900, Horms wrote:
> I have been looking at unifying the way that panic_on_oops logs
> what it is doing between the different architectures that implement it.
> The first cab off the rank is the patch below which removes a seemingly
> silly difference between the behaviour on 32 and 64 bit powerpc.
>
> I have not been able to test this as I do not have a ppc64 machine
> at my disposal. However I did test that it compiles thanks to
> the wonders of crosstool.
>
> Signed-Off-By: Horms <horms@verge.net.au>
>
> arch/powerpc/kernel/traps.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 52f5659..908231a 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -157,10 +157,8 @@ #endif
> panic("Fatal exception in interrupt");
>
> if (panic_on_oops) {
> -#ifdef CONFIG_PPC64
> printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
> ssleep(5);
> -#endif
> panic("Fatal exception");
> }
> do_exit(err);
^ permalink raw reply
* Re: ppc -> powerpc porting
From: Benjamin Herrenschmidt @ 2006-07-10 21:43 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.60.0607102135330.10561@poirot.grange>
On Mon, 2006-07-10 at 21:43 +0200, Guennadi Liakhovetski wrote:
> On Mon, 10 Jul 2006, Vitaly Bordug wrote:
>
> > On Mon, 10 Jul 2006 12:14:24 -0500
> > "Rune Torgersen" <runet@innovsys.com> wrote:
> >
> > > To make my life a little easier: Does anybody have a list of stuff to
> > > watch out for/need to do when porting a board from ppc to powerpc?
> > > The board uses a Freescale 8265 and runs under 2.6.17, using platfrom
> > > device support for accessing fs_enet driver.
>
> Look at Documentation/powerpc/booting-without-of.txt -
You guys be careful, if you use OpenPIC/MPIC, that there is an error in
that documentation for the interrupt specifier definition. I'll send an
updated documentation soon with some more details about the OF interrupt
tree, but in the meantime, the proper sense encoding for MPIC is:
0 = rising edge
1 = negative level
2 = positive level
3 = falling edge
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Make snd-aoa cope with lack of line-output-detect property
From: Benjamin Herrenschmidt @ 2006-07-10 21:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1152537082.30697.37.camel@localhost>
On Mon, 2006-07-10 at 15:11 +0200, Johannes Berg wrote:
> On Mon, 2006-07-10 at 22:39 +1000, Paul Mackerras wrote:
> > The snd-aoa stuff falls over on my G4 powerbook (1.5GHz Albook) with a
> > null pointer dereference in of_find_property. It turns out that this
> > was because it couldn't find a device node for the line-output detect
> > GPIO. This patch fixes it.
>
> That's interesting. I thought I was running this code. Hmm :>
Slightly different model I suppose, 5,4 vs. 5,6 no ? Paul, can you send
Johannes a dumb of your device-tree ?
> I should probably drop the get_irq function completely and do that in
> line. And yes, that should be NO_IRQ I guess. I'll prepare a patch
> later.
Ben.
^ permalink raw reply
* Re: Linux v2.6.18-rc1
From: Benjamin Herrenschmidt @ 2006-07-10 21:17 UTC (permalink / raw)
To: Alan Cox; +Cc: Steve Fox, linuxppc-dev, linux-kernel
In-Reply-To: <1152542413.27368.131.camel@localhost.localdomain>
> That in repeat generally means the IRQ logic on the platform has been
> broken. If we don't get interrupts we don't work very well.
>
> Also check if booting with "nodma" set on the relevant ide interface
> makes a difference. Just to be sure. If it does then submit patches to
> fix the bug.
it's most certainly an irq problem as I just rewrote the irq logic of
powerpc :) There have been some issues and I've just sent some new
patches fixing them, let's see if that's enough. I'll give a js20 a try
today at work.
Ben.
^ permalink raw reply
* Re: Linux v2.6.18-rc1
From: Benjamin Herrenschmidt @ 2006-07-10 21:16 UTC (permalink / raw)
To: will_schmidt; +Cc: Steve Fox, linuxppc-dev, linux-kernel
In-Reply-To: <1152537672.28828.4.camel@farscape.rchland.ibm.com>
On Mon, 2006-07-10 at 08:21 -0500, Will Schmidt wrote:
> On Sun, 2006-09-07 at 20:34 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2006-07-07 at 10:41 -0500, Steve Fox wrote:
> > > We've got a ppc64 machine that won't boot with this due to an IDE error.
> >
> > What machine precisely ?
>
> I see a slightly more verbose version on a JS20 blade.
Can you try with the new patches I posted yesterday ?
Ben.
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Arnd Bergmann @ 2006-07-10 20:49 UTC (permalink / raw)
To: Mike Kravetz
Cc: Bryan Rosenburg, linuxppc-dev, Nathan Lynch, Christopher Yeoh
In-Reply-To: <20060710203510.GA30793@w-mikek2.ibm.com>
On Monday 10 July 2006 22:35, Mike Kravetz wrote:
> On Thu, Jun 22, 2006 at 03:56:09PM -0700, Mike Kravetz wrote:
> > This version addresses all comments received except Arnd's issue
> > with an #ifdef for each function in the assembly file.
>
> I was thinking of changing the names of all the assembly routines from
> plpar_hcall_*() to plpar_hcall_*_asm(). The instrumented version of the
> routines would be named plpar_hcall_*_inst(). Then, the header file
> would contain definitions such as:
>
> #ifdef CONFIG_HCALL_STATS
> #define plpar_hcall_*() plpar_hcall_*_inst()
> .
> #else
> #define plpar_hcall_*() plpar_hcall_*_asm()
> .
> #endif
>
> Is that any better than all the individual #ifdefs in the .S file? Is it
> still too ugly?
>
I guess it's better to have the #ifdef in the header file, but then
again, you could just as well save some source lines doing
#ifndef CONFIG_HCALL_STATS
#define plpar_hcalldef(x) plpar_call_ ## x ## _asm
#else
#define plpar_hcalldef(x) plpar_call_ ## x ## _inst
#endif
#define plpar_call_foo plpar_hcalldef(foo)
Arnd <><
^ permalink raw reply
* FW: ppc -> powerpc porting
From: Rune Torgersen @ 2006-07-10 20:38 UTC (permalink / raw)
To: linuxppc-dev
> From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]=20
> Sent: Monday, July 10, 2006 12:42
> We have mpc8272 under arch/powerpc as work-in-progress,=20
> latest fs_enet being merged now.
>=20
> I think it'll be a week or 2 before first submit, so it may=20
> make sense just to wait a bit :)
Ok. I sor of used the ppc version of the 8272 to get fs_enet working.=20
fs_enet is not my main concern. My concern is everything else... OF
tree, new IRQ code (we have two local IRQ muxes in FPGA modeled afrer
the PCI mux on 8266ADS). Our current port is running on 2.6.12. We have
a 2.6 17 port working, but have not started using it yet. I want to wait
until we have ported to powerpc/=20
^ permalink raw reply
* RE: ppc -> powerpc porting
From: Rune Torgersen @ 2006-07-10 20:36 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20060710214158.1d8dcf2c@vitb.ru.mvista.com>
> From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]=20
> Sent: Monday, July 10, 2006 12:42
> We have mpc8272 under arch/powerpc as work-in-progress,=20
> latest fs_enet being merged now.
>=20
> I think it'll be a week or 2 before first submit, so it may=20
> make sense just to wait a bit :)
Ok. I sor of used the ppc version of the 8272 to get fs_enet working.=20
fs_enet is not my main concern. My concern is everything else... OF
tree, new IRQ code (we have two local IRQ muxes in FPGA modeled afrer
the PCI mux on 8266ADS). Our current port is running on 2.6.12. We have
a 2.6 17 port working, but have not started using it yet. I want to wait
until we have ported to powerpc/=20
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Mike Kravetz @ 2006-07-10 20:35 UTC (permalink / raw)
To: linuxppc-dev
Cc: Bryan Rosenburg, Christopher Yeoh, Nathan Lynch, Arnd Bergmann
In-Reply-To: <20060622225609.GA4877@w-mikek2.ibm.com>
On Thu, Jun 22, 2006 at 03:56:09PM -0700, Mike Kravetz wrote:
> This version addresses all comments received except Arnd's issue
> with an #ifdef for each function in the assembly file.
I was thinking of changing the names of all the assembly routines from
plpar_hcall_*() to plpar_hcall_*_asm(). The instrumented version of the
routines would be named plpar_hcall_*_inst(). Then, the header file
would contain definitions such as:
#ifdef CONFIG_HCALL_STATS
#define plpar_hcall_*() plpar_hcall_*_inst()
.
#else
#define plpar_hcall_*() plpar_hcall_*_asm()
.
#endif
Is that any better than all the individual #ifdefs in the .S file? Is it
still too ugly?
I'm open to any suggestions.
Thanks,
--
Mike
^ permalink raw reply
* Re: ppc -> powerpc porting
From: Guennadi Liakhovetski @ 2006-07-10 19:43 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20060710214158.1d8dcf2c@vitb.ru.mvista.com>
On Mon, 10 Jul 2006, Vitaly Bordug wrote:
> On Mon, 10 Jul 2006 12:14:24 -0500
> "Rune Torgersen" <runet@innovsys.com> wrote:
>
> > To make my life a little easier: Does anybody have a list of stuff to
> > watch out for/need to do when porting a board from ppc to powerpc?
> > The board uses a Freescale 8265 and runs under 2.6.17, using platfrom
> > device support for accessing fs_enet driver.
Look at Documentation/powerpc/booting-without-of.txt - there's a section
on that. I am attempting the same sort of conversion for an embedded
mpc8241 board, so, would be glad to share ideas / experiences, I think, we
won't offend others if we just discuss our problems on this list, maybe
even somebody else will find it useful:-)) The first step I am trying to
perform is to switch to the device-tree boot. Does your board already use
it or does it have OF?
> We have mpc8272 under arch/powerpc as work-in-progress, latest fs_enet being merged now.
>
> I think it'll be a week or 2 before first submit, so it may make sense just to wait a bit :)
Yep, you could wait, but, you see, an example will be great, but, I am
afraid, all ports will be pretty different, so, we'll all have to "invent
the wheel." Is your code available somewhere in some repository to have a
look at?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: Linux v2.6.18-rc1
From: Steve Fox @ 2006-07-10 18:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
In-Reply-To: <1152549482.2658.29.camel@flooterbu>
On Mon, 10 Jul 2006 11:38:02 -0500, Steve Fox wrote:
> Also, booting with ide=nodma, as Alan suggested to Will, did not help.
I'm not sure if it was due to using the nodma parameter or not, but I did
get a few more details during this boot. No idea if they're useful or not.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide:
Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD8111: IDE controller at PCI slot 0000:00:04.1 AMD8111: chipset revision
3 AMD8111: 0000:00:04.1 (rev 03) UDMA133 controller AMD8111: 100% native
mode on irq 17
ide0: BM-DMA at 0x7c00-0x7c07, BIOS settings: hda:pio, hdb:pio ide1:
BM-DMA at 0x7c08-0x7c0f, BIOS settings: hdc:pio, hdd:pio
hda: TOSHIBA MK4019GAXB, ATA DISK drive ide0 at 0x7400-0x7407,0x6c02 on
irq 17 hda: max request size: 128KiB
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: 78140160 sectors (40007 MB), CHS=65535/16/63 hda: lost interrupt hda:
cache flushes supported
hda:<4>hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda1 hda2 hda3 hda4 <<4>hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda5<4>hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
--
Steve Fox
IBM Linux Technology Center
^ permalink raw reply
* Re: ppc -> powerpc porting
From: Vitaly Bordug @ 2006-07-10 17:41 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0189DE5E@ismail.innsys.innovsys.com>
On Mon, 10 Jul 2006 12:14:24 -0500
"Rune Torgersen" <runet@innovsys.com> wrote:
> To make my life a little easier: Does anybody have a list of stuff to
> watch out for/need to do when porting a board from ppc to powerpc?
> The board uses a Freescale 8265 and runs under 2.6.17, using platfrom
> device support for accessing fs_enet driver.
>
We have mpc8272 under arch/powerpc as work-in-progress, latest fs_enet being merged now.
I think it'll be a week or 2 before first submit, so it may make sense just to wait a bit :)
--
Sincerely,
Vitaly
^ permalink raw reply
* ppc -> powerpc porting
From: Rune Torgersen @ 2006-07-10 17:14 UTC (permalink / raw)
To: linuxppc-dev
To make my life a little easier: Does anybody have a list of stuff to
watch out for/need to do when porting a board from ppc to powerpc?
The board uses a Freescale 8265 and runs under 2.6.17, using platfrom
device support for accessing fs_enet driver.
^ permalink raw reply
* Re: Linux v2.6.18-rc1
From: Steve Fox @ 2006-07-10 16:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1152441242.4128.33.camel@localhost.localdomain>
On Sun, 2006-07-09 at 20:34 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2006-07-07 at 10:41 -0500, Steve Fox wrote:
> > We've got a ppc64 machine that won't boot with this due to an IDE error.
>
> What machine precisely ?
It's called bl5-6 in ABAT and lists itself as a 970 (8842-P1Z).
Also, booting with ide=nodma, as Alan suggested to Will, did not help.
> > [snip]
> > Freeing unused kernel memory: 256k freed
> > running (1:2) /init autobench_args: ABAT:1152213829
> >
> > creating device nodes .hda: lost interrupt
> > hda: lost interrupt
> > hda: lost interrupt
> > hda: lost interrupt
> > hda: lost interrupt
> > hda: lost interrupt
> > hda: lost interrupt
> > hda: lost interrupt
> > hda: lost interrupt
> >
>
--
Steve Fox
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 6/6] Account for memmap and optionally the kernel image as holes
From: Mel Gorman @ 2006-07-10 15:31 UTC (permalink / raw)
To: David Howells
Cc: akpm, davej, tony.luck, linuxppc-dev, ak, bob.picco, linux-kernel,
linux-mm
In-Reply-To: <7220.1152531055@warthog.cambridge.redhat.com>
On (10/07/06 12:30), David Howells didst pronounce:
> Mel Gorman <mel@csn.ul.ie> wrote:
>
> > +unsigned long __initdata dma_reserve;
>
> Should this be static? Or should it be predeclared in a header file
> somewhere?
>
It should be static as it's set by set_dma_reserve(). Thanks.
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm6-106-account_kernel_mmap/mm/page_alloc.c linux-2.6.17-mm6-107-fixstatic/mm/page_alloc.c
--- linux-2.6.17-mm6-106-account_kernel_mmap/mm/page_alloc.c 2006-07-10 15:55:09.000000000 +0100
+++ linux-2.6.17-mm6-107-fixstatic/mm/page_alloc.c 2006-07-10 16:03:26.000000000 +0100
@@ -87,7 +87,7 @@ int min_free_kbytes = 1024;
unsigned long __meminitdata nr_kernel_pages;
unsigned long __meminitdata nr_all_pages;
-unsigned long __initdata dma_reserve;
+static unsigned long __initdata dma_reserve;
#ifdef CONFIG_ARCH_POPULATES_NODE_MAP
/*
^ permalink raw reply
* Re: Linux v2.6.18-rc1
From: Alan Cox @ 2006-07-10 14:40 UTC (permalink / raw)
To: will_schmidt; +Cc: Steve Fox, linux-kernel, linuxppc-dev
In-Reply-To: <1152537672.28828.4.camel@farscape.rchland.ibm.com>
Ar Llu, 2006-07-10 am 08:21 -0500, ysgrifennodd Will Schmidt:
> On Sun, 2006-09-07 at 20:34 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2006-07-07 at 10:41 -0500, Steve Fox wrote:
> > > We've got a ppc64 machine that won't boot with this due to an IDE error.
> >
> > What machine precisely ?
>
> I see a slightly more verbose version on a JS20 blade.
>
> hda: dma_timer_expiry: dma status == 0x24
> hda: DMA interrupt recovery
> hda: lost interrupt
That in repeat generally means the IRQ logic on the platform has been
broken. If we don't get interrupts we don't work very well.
Also check if booting with "nodma" set on the relevant ide interface
makes a difference. Just to be sure. If it does then submit patches to
fix the bug.
Alan
^ permalink raw reply
* Re: MPC5200 boot giving "request_module: runaway loop modprobe binfmt-4c46" errors
From: gturnock @ 2006-07-10 13:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-embedded, gturnock
[-- Attachment #1: Type: text/html, Size: 2176 bytes --]
^ permalink raw reply
* Re: Linux v2.6.18-rc1
From: Will Schmidt @ 2006-07-10 13:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Steve Fox, linuxppc-dev, linux-kernel
In-Reply-To: <1152441242.4128.33.camel@localhost.localdomain>
On Sun, 2006-09-07 at 20:34 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2006-07-07 at 10:41 -0500, Steve Fox wrote:
> > We've got a ppc64 machine that won't boot with this due to an IDE error.
>
> What machine precisely ?
I see a slightly more verbose version on a JS20 blade.
hda: dma_timer_expiry: dma status == 0x24
hda: DMA interrupt recovery
hda: lost interrupt
>
> > [snip]
> > Freeing unused kernel memory: 256k freed
> > running (1:2) /init autobench_args: ABAT:1152213829
> >
> > creating device nodes .hda: lost interrupt
> > hda: lost interrupt
> > hda: lost interrupt
> > hda: lost interrupt
> > hda: lost interrupt
> > hda: lost interrupt
> > hda: lost interrupt
> > hda: lost interrupt
> > hda: lost interrupt
> >
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] Make snd-aoa cope with lack of line-output-detect property
From: Johannes Berg @ 2006-07-10 13:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17586.19091.512322.908434@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]
On Mon, 2006-07-10 at 22:39 +1000, Paul Mackerras wrote:
> The snd-aoa stuff falls over on my G4 powerbook (1.5GHz Albook) with a
> null pointer dereference in of_find_property. It turns out that this
> was because it couldn't find a device node for the line-output detect
> GPIO. This patch fixes it.
That's interesting. I thought I was running this code. Hmm :>
I should probably drop the get_irq function completely and do that in
line. And yes, that should be NO_IRQ I guess. I'll prepare a patch
later.
Thanks,
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: patches added to powerpc.git tree
From: Johannes Berg @ 2006-07-10 13:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17586.18872.10354.559506@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 352 bytes --]
On Mon, 2006-07-10 at 22:36 +1000, Paul Mackerras wrote:
> I assumed it would go via the alsa tree...
It couldn't because it depends on stuff that isn't in the alsa tree.
> Do you want it to go via the powerpc tree? I'm on vacation and 1000km
> from home, so the latency would be pretty long. :)
No, went through Andrew now.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 15/20] [powerpc, netdevices] Constify & voidify get_property()
From: Paul Mackerras @ 2006-07-10 12:43 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <200607101340.22068.jk@ozlabs.org>
Jeremy Kerr writes:
> Hm, that's odd - you mean the patch doesn't apply, or that it introduces
> incorrect whitepace? I can apply this patch (from patchwork or the list
> archives) without problems.
The git-applymbox script says the patch is corrupt, because several of
the context lines that should start with <space><tab> had the space
removed.
Paul.
^ permalink raw reply
* [PATCH] Make snd-aoa cope with lack of line-output-detect property
From: Paul Mackerras @ 2006-07-10 12:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
The snd-aoa stuff falls over on my G4 powerbook (1.5GHz Albook) with a
null pointer dereference in of_find_property. It turns out that this
was because it couldn't find a device node for the line-output detect
GPIO. This patch fixes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/sound/aoa/core/snd-aoa-gpio-feature.c b/sound/aoa/core/snd-aoa-gpio-feature.c
index 7ae0c0b..e35a1c6 100644
--- a/sound/aoa/core/snd-aoa-gpio-feature.c
+++ b/sound/aoa/core/snd-aoa-gpio-feature.c
@@ -112,7 +112,10 @@ static struct device_node *get_gpio(char
static void get_irq(struct device_node * np, int *irqptr)
{
- *irqptr = irq_of_parse_and_map(np, 0);
+ if (np)
+ *irqptr = irq_of_parse_and_map(np, 0);
+ else
+ *irqptr = -1; /* XXX should this be NO_IRQ? */
}
/* 0x4 is outenable, 0x1 is out, thus 4 or 5 */
@@ -322,7 +325,7 @@ static int ftr_set_notify(struct gpio_ru
return -EINVAL;
}
- if (irq == -1)
+ if (irq == -1) /* XXX should this be NO_IRQ? */
return -ENODEV;
mutex_lock(¬if->mutex);
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox