Re: ML403 USB driver
Grant Likely-2 wrote: > > On 11/20/07, Lorenz Kolb <[EMAIL PROTECTED]> wrote: > >> >> Anyway, only one of the two peripheral ports seems to be active. > > Yes, I've got that problem here too. I haven't yet solved it. Any > help would be appreciated. > > Cheers, > g. > > Well that's what we have found out till now, maybe it helps, or at least what we think to have found out: - First of all to the non functioning peripheral port: It is "USB Peripheral 1". According to the schematics it should be powered using the OTGVBus-Port of the Cypress-Controller (nevertheless it has currently no level) - Secondly there is no configuration 1 Host + 2 Peripherals according to the datasheet from Cypress - Thirdly the initial configuration (at least that is what we are guessing) seems to be done via some standalone program coming from an Eeprom. - The three pins near the UART port are the serial console for the Cypress chip (we have not yet done any tests with that). - At least the peripherals are connected in a right way, as one SIE can only have one peripheral Some question aside the peripheral topic: Has anyone any idea how to make the cypress chip to have a _normal_ Host not an OTG one (as some USB-Hub might save us from our dilemma why we tried to use gadgets in peripheral mode)? Regards, Lorenz Kolb -- View this message in context: http://www.nabble.com/ML403-USB-driver-tf4844098.html#a13872475 Sent from the linuxppc-embedded mailing list archive at Nabble.com. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH try2] powerpc: Add support for PORTA and PORTB odr registers
Jochen Friedrich wrote: > PORTA and PORTB have odr registers, as well. However, the PORTB odr > register is only 16bit. > > Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]> Acked-by: Scott Wood <[EMAIL PROTECTED]> BTW, you may want to send the patches to linuxppc-dev rather than linuxppc-embedded... Despite what MAINTAINERS says, the former is where most patches get posted. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Debugging with gdbserver slow
Hi everyone, Im using gdbserver to debug Linux apps on my embedded board, but it takes like 3-6 sec to step one line of code. Its about the same to go from breakpoint to breakpont. Im using TCP to connect the host to the target. Is this typical or is there some setting wrong or was it built wrong. Its a PPC405 in a Xilinx FPGA. Thanks khollan -- View this message in context: http://www.nabble.com/Debugging-with-gdbserver-slow-tf4846374.html#a13865715 Sent from the linuxppc-embedded mailing list archive at Nabble.com. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
linux2.6.19.2-> mpc8xx_wdt.c: timeout extended to reach several seconds... but I have a problem
Till yesterday I thought I was able to code a simple driver but now I'm facing a problem that is puzzling me. I added a kernel timer (triggering every 500 ms) to reset the watchdog of mpc8xx. This timer starts when the driver is opened. The timer is rearmed till a counter reaches a zero value. A process can use the write method of the driver to set the counter to a preferred value. If the application misses to set the counter, it will decrease to zero and then the board will restart. Unfortunately as soon as my application "calls" the write method the kernel freezes. If the watchdog is enabled the board restarts otherwise the kernel remains blocked forever without any indication. Even if I empty the write method leaving only the get_user the board freezes. Below you can find the code, if anyone has an hint I would really appreciate his advice: ___ /* * mpc8xx_wdt.c - MPC8xx watchdog userspace interface * * Author: Florian Schirmer <[EMAIL PROTECTED]> * * 2002 (c) Florian Schirmer <[EMAIL PROTECTED]> This file is licensed under * the terms of the GNU General Public License version 2. This program * is licensed "as is" without any warranty of any kind, whether express * or implied. */ #include #include #include #include #include #include #include #include #include #include #define KTIMER_TIMEOUT (HZ/2) static struct timer_list wd_timer; /* structure for timer administration */ static unsigned long mpc8xx_wdt_dummy; static int timer_count = 600; static unsigned long wdt_opened; static int wdt_status; static spinlock_t counter_spinlock; static void mpc8xx_wdt_handler_disable(void) { volatile ushort __iomem *piscr; piscr = (ushort *)&((immap_t*)IMAP_ADDR)->im_sit.sit_piscr; if (!m8xx_has_internal_rtc) m8xx_wdt_stop_timer(); else out_be16(piscr, in_be16(piscr) & ~(PISCR_PIE | PISCR_PTE)); printk(KERN_NOTICE "mpc8xx_wdt: keep-alive handler deactivated\n"); } static void mpc8xx_wdt_handler_enable(void) { volatile ushort __iomem *piscr; piscr = (ushort *)&((immap_t*)IMAP_ADDR)->im_sit.sit_piscr; if (!m8xx_has_internal_rtc) m8xx_wdt_install_timer(); else out_be16(piscr, in_be16(piscr) | PISCR_PIE | PISCR_PTE); printk(KERN_NOTICE "mpc8xx_wdt: keep-alive handler activated\n"); } static int mpc8xx_wdt_open(struct inode *inode, struct file *file) { if (test_and_set_bit(0, &wdt_opened)) return -EBUSY; m8xx_wdt_reset(); wd_timer.expires = jiffies + KTIMER_TIMEOUT; add_timer (&wd_timer); /* ...re-activate timer */ mpc8xx_wdt_handler_disable(); return 0; } static int mpc8xx_wdt_release(struct inode *inode, struct file *file) { m8xx_wdt_reset(); #if !defined(CONFIG_WATCHDOG_NOWAYOUT) mpc8xx_wdt_handler_enable(); #endif clear_bit(0, &wdt_opened); return 0; } static void mpc8xx_wdt_ktimer_handler(unsigned long data) { int counter; spin_lock(&counter_spinlock); counter = timer_count--; spin_unlock(&counter_spinlock); printk("Counter %d\n", counter); if (counter > 0) { wd_timer.expires = jiffies + KTIMER_TIMEOUT; add_timer (&wd_timer);/* ...re-activate timer */ m8xx_wdt_reset(); } else { printk(KERN_NOTICE "mpc8xx_wdt: Watchdog expired ... restarting\n"); } } static ssize_t mpc8xx_wdt_write(struct file *file, const char *data, size_t len, loff_t * ppos) { unsigned long flags; int new_count; if (len != sizeof(new_count)) { return -EINVAL; } /* copy count value into kernel space */ get_user(new_count, (int *) data); printk("new_count %d\n", new_count); /* Removing the following three lines doesn't prevent the kernel freeze */ spin_lock_irqsave(&counter_spinlock, flags); timer_count = (HZ*new_count)/KTIMER_TIMEOUT; spin_unlock_irqrestore(&counter_spinlock, flags); return (sizeof(new_count)); } static int mpc8xx_wdt_ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg) { int timeout; static struct watchdog_info info = { .options = WDIOF_KEEPALIVEPING, .firmware_version = 0, .identity = "MPC8xx watchdog", }; switch (cmd) { case WDIOC_GETSUPPORT: if (copy_to_user((void *)arg, &info, sizeof(info))) return -EFAULT; break; case WDIOC_GETSTATUS: case WDIOC_GETBOOTSTATUS: if (put_user(wdt_status, (int *)arg)) return -EFAULT; wdt_status &
Re: 2.6 kernel hangs after loading device tree
Hi, I got a solution to this.The problem was with the current speed parameter in the DTS,as stated.You need to explicity specify the speed.It doesnot get filled in from U-boot.You can also probabaly check the kernel log buf to see what values are set for these parameters.Anyways,changing the current speed made it work me and my 2.6 kernel is now up. Thanks. Charanya. > Date: Mon, 19 Nov 2007 16:08:03 -0800 (PST) > From: abhi_linux <[EMAIL PROTECTED]> > Subject: Re: 2.6 kernel hangs after loading device tree > To: linuxppc-embedded@ozlabs.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > > Hello > Did u get a solution to this? I have similar issues. How do u enable > debugging in UBoot? > Thanks > > charanya venkatraman wrote: > > > > Hi all > >Sorry about the previous mail.Got sent by mistake. > > > > Iam using the 2.6.22.5 kernel on MPC 8560 and MPC8540 on my custom > > board.Mykernel hangs after loading the device tree in both the > > processors .There is > > no output on the serial port after loading the device tree.Am using U-boot > > 1.2.0 as the bootloader.After enabling debug in u-boot i could see that > > the > > control is getting transferred to the kernel after which it hangs.Earlier > > i > > tried using 2.6.21 which also hangs at the same point.The config files > > used > > were MPC8540ADS_defconfig and MPC8560ADS_defconfig under powerpc > > directory. > > The changes that were made to the device tree are: > > 1.The reg and ranges properties of the soc node have been changed to > > account > > for the change in CCSRBAR of my board. > > 2.Removed the PCI,mdio nodes and ethernet nodes since i dont need support > > for these as of now. > > > > I have tried the following console arguments: > > MPC8540: bootargs root=/dev/ram rw console=ttyS0,115200 > > MPC8560:bootargs root=/dev/ram rw console=ttyCPM0,115200 > > > > Any help on this issue?? > > > > Thanks. > > Charanya. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] powerpc: Change _tlbie arguments to reflect new API
On Tue, 20 Nov 2007 18:21:29 +0100 Jochen Friedrich <[EMAIL PROTECTED]> wrote: > A new pid argument has been added to _tlbie for 4xx platforms. > Add this argument to the 8xx path in mem.c, as well. As 8xx > does not need th epid information, this argument can always be 0. This is already fixed in Paul's tree. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] powerpc: Change _tlbie arguments to reflect new API
A new pid argument has been added to _tlbie for 4xx platforms. Add this argument to the 8xx path in mem.c, as well. As 8xx does not need th epid information, this argument can always be 0. Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]> CC arch/powerpc/mm/mem.o arch/powerpc/mm/mem.c: In function 'update_mmu_cache': arch/powerpc/mm/mem.c:467: error: too few arguments to function '_tlbie' make[1]: *** [arch/powerpc/mm/mem.o] Error 1 make: *** [arch/powerpc/mm] Error 2 --- arch/powerpc/mm/mem.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index 81eb96e..e07852e 100644 --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -464,7 +464,7 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned long address, * we invalidate the TLB here, thus avoiding dcbst * misbehaviour. */ - _tlbie(address); + _tlbie(address, 0); #endif if (!PageReserved(page) && !test_bit(PG_arch_1, &page->flags)) { -- 1.5.3.4 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH try2] powerpc: Add support for PORTA and PORTB odr registers
PORTA and PORTB have odr registers, as well. However, the PORTB odr register is only 16bit. Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/commproc.c | 19 --- 1 files changed, 16 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c index d5a0dcf..c0d00c2 100644 --- a/arch/powerpc/sysdev/commproc.c +++ b/arch/powerpc/sysdev/commproc.c @@ -411,7 +411,7 @@ EXPORT_SYMBOL(cpm_dpram_phys); #endif /* !CONFIG_PPC_CPM_NEW_BINDING */ struct cpm_ioport16 { - __be16 dir, par, sor, dat, intr; + __be16 dir, par, odr_sor, dat, intr; __be16 res[3]; }; @@ -441,6 +441,13 @@ static void cpm1_set_pin32(int port, int pin, int flags) else clrbits32(&iop->par, pin); + if (port == CPM_PORTB) { + if (flags & CPM_PIN_OPENDRAIN) + setbits16(&mpc8xx_immr->im_cpm.cp_pbodr, pin); + else + clrbits16(&mpc8xx_immr->im_cpm.cp_pbodr, pin); + } + if (port == CPM_PORTE) { if (flags & CPM_PIN_SECONDARY) setbits32(&iop->sor, pin); @@ -474,11 +481,17 @@ static void cpm1_set_pin16(int port, int pin, int flags) else clrbits16(&iop->par, pin); + if (port == CPM_PORTA) { + if (flags & CPM_PIN_OPENDRAIN) + setbits16(&iop->odr_sor, pin); + else + clrbits16(&iop->odr_sor, pin); + } if (port == CPM_PORTC) { if (flags & CPM_PIN_SECONDARY) - setbits16(&iop->sor, pin); + setbits16(&iop->odr_sor, pin); else - clrbits16(&iop->sor, pin); + clrbits16(&iop->odr_sor, pin); } } -- 1.5.3.4 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ML403 USB driver
On 11/20/07, Lorenz Kolb <[EMAIL PROTECTED]> wrote: > > Hi, > > we just tried the USB driver (from Peter Korsgaard) from Grant's virtex > tree. > > Nevertheless we could not get the peripheral ports work as gadgets. > Has anyone tried (and probably fixed) that before? That driver does not work for gadget ports. > > Anyway, only one of the two peripheral ports seems to be active. Yes, I've got that problem here too. I haven't yet solved it. Any help would be appreciated. > We use kernel 2.6.22 (as some usb related stuff has recently changed and the > driver would have to be changed), usb host works (usb-storage, cdc_ether, > some more stuff we tested) Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
ML403 USB driver
Hi, we just tried the USB driver (from Peter Korsgaard) from Grant's virtex tree. Nevertheless we could not get the peripheral ports work as gadgets. Has anyone tried (and probably fixed) that before? Anyway, only one of the two peripheral ports seems to be active. We use kernel 2.6.22 (as some usb related stuff has recently changed and the driver would have to be changed), usb host works (usb-storage, cdc_ether, some more stuff we tested) Regards, Lorenz Kolb -- View this message in context: http://www.nabble.com/ML403-USB-driver-tf4844098.html#a13858912 Sent from the linuxppc-embedded mailing list archive at Nabble.com. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Oops: of_platform_serial_probe
>> @@ -36,6 +36,10 @@ static int __devinit of_platform_serial_setup(struct >> of_device *ofdev, >> memset(port, 0, sizeof *port); >> spd = of_get_property(np, "current-speed", NULL); >> clk = of_get_property(np, "clock-frequency", NULL); >> + if (!spd) { >> + dev_warn(&ofdev->dev, "no current-speed property set\n"); >> + return -ENODEV; >> + } >> if (!clk) { >> dev_warn(&ofdev->dev, "no clock-frequency property set\n"); >> return -ENODEV; > > This looks wrong. Since the current-speed property is not mandated by open > firmware, > we should not error out here, but simply use the setting from the command > line > or whatever other defaults can be used. Not setting port->custom_divisor at > all > should do the job. Understood... but then, my console just stops / gets reinitialized to some unknown baudrate when I get to of_serial.c. :-( Regards, Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Problem with uboot on lite5200
Hello, Wolfgang! Wolfgang Denk schrieb: > In message <[EMAIL PROTECTED]> you wrote: >> How should people get a glue what's current, when in the section >> "Latest News" at http://sourceforge.net/projects/u-boot/ the people >> still find a more or less official looking "u-boot-1.1.5" release. > > Maybe by reading the very first two lines on the SF page: > > ... > NOTE: current source code is available from DENX git > repository and FTP server; see http://www.denx.de/en/Software/GIT I tried to convince you to point them to the releases... and _not_ to any repository. > The problem is that you cannot really "shut down" a SourceForge > project (please correct me if I'm wrong). I don't like SourceForge for some reasons... now, if that's true, I got one more. But anyway, there should be a way to update the "Latest News"... in a way it points to current stuff. >>> Current U-Boot is 1.3.0-rc4. Please wake up. >> Well... maybe it's better to remove all references to the old >> releases at sourceforge and point them to ftp://ftp.denx.de/pub/u-boot/ > > Can you please teach me how to do that? I would expect that one of the project admins (i.e. you) is able to update the site information. You could update the SF project as you did since u-boot-0.2.0. If you don't want to continue with SF, propably an update to a "last SF version" with nothing more than an README should suffice. Well, I know you expect people to read... I'm just wondering why so many people use ancient versions. (-: > And 1.3.0 will be out in less than 2 hours from now :-) Well... that's great... thank you all! Regards, -- Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Oops: of_platform_serial_probe
On Tuesday 20 November 2007, Clemens Koller wrote: > The device tree is the default one which comes with the kernel: > paulus.git/arch/powerpc/boot/dts/mpc8540ads.dts > which contains: > > [EMAIL PROTECTED] { > device_type = "serial"; > compatible = "ns16550"; > reg = <4500 100>; // reg base, size > clock-frequency = <0>; // should we fill in in > uboot? > interrupts = <2a 2>; > interrupt-parent = <&mpic>; > }; > > [EMAIL PROTECTED] { > device_type = "serial"; > compatible = "ns16550"; > reg = <4600 100>; // reg base, size > clock-frequency = <0>; // should we fill in in > uboot? > interrupts = <2a 2>; > interrupt-parent = <&mpic>; > }; > > > One potential problem that I can see is a missing 'current-speed' > > property in your tree, which would cause this behavior. > > That's correct. Should be fixed in all .dts' ? It depends a lot on how the systems are used. current-speed only makes sense if there is a boot loader that also does some serial I/O at a speed it sets up itself. > > It looks > > like many device trees set this, but it is not required by all > > bindings. > > How should someone know, when it's really needed and when not? The point of current-speed is that the kernel can tell what bitrate was used by the boot loader and set up the same speed so that your terminal emulation does not get garbled output when changing from boot loader messages to kernel messages. > > If that's the case, the patch below should fix your > > problem, but you probably want to set the current-speed anyway, > > according to your boot loader settings. > > I think there was no need to set it again, because of: console=ttyS0,115200 > But I'll verify... When current-speed is set, you don't need to override the speed at the command line. > @@ -36,6 +36,10 @@ static int __devinit of_platform_serial_setup(struct > of_device *ofdev, > memset(port, 0, sizeof *port); > spd = of_get_property(np, "current-speed", NULL); > clk = of_get_property(np, "clock-frequency", NULL); > + if (!spd) { > + dev_warn(&ofdev->dev, "no current-speed property set\n"); > + return -ENODEV; > + } > if (!clk) { > dev_warn(&ofdev->dev, "no clock-frequency property set\n"); > return -ENODEV; This looks wrong. Since the current-speed property is not mandated by open firmware, we should not error out here, but simply use the setting from the command line or whatever other defaults can be used. Not setting port->custom_divisor at all should do the job. Arnd <>< ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 2.6 kernel hangs after loading device tree
> charanya venkatraman wrote: >> Hi all >>Sorry about the previous mail.Got sent by mistake. >> >> Iam using the 2.6.22.5 kernel on MPC 8560 and MPC8540 on my custom >> board.Mykernel hangs after loading the device tree in both the >> processors. There is >> no output on the serial port after loading the device tree. >> I have tried the following console arguments: >> MPC8540: bootargs root=/dev/ram rw console=ttyS0,115200 >> MPC8560:bootargs root=/dev/ram rw console=ttyCPM0,115200 >> >> Any help on this issue?? Maybe your problem is related to... See the thread at: http://ozlabs.org/pipermail/linuxppc-embedded/2007-November/028968.html (I use Paulus' git tree.) Regards, Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Oops: of_platform_serial_probe
Hi, Arnd! Arnd Bergmann schrieb: > On Monday 19 November 2007, Clemens Koller wrote: >> Unable to handle kernel paging request for data at address 0x >> Faulting instruction address: 0xc018f03c >> Oops: Kernel access of bad area, sig: 11 [#1] >> MPC85xx ADS >> Modules linked in: >> NIP: c018f03c LR: c018f00c CTR: c00127b4 >> REGS: c0821cf0 TRAP: 0300 Not tainted (2.6.24-rc2-ge6a5c27f) >> MSR: 00029000 CR: 42022088 XER: 2000 >> DEAR: , ESR: >> TASK = c081e000[1] 'swapper' THREAD: c082 >> GPR00: b100 c0821da0 c081e000 c0833e10 0004 c0821d80 c03d3064 c05eea80 >> GPR08: 0200 0002 002a 13ab6680 82022042 c03318a4 c033188c >> GPR16: c0331908 c03318f0 c03a0e30 c0331930 c033191c 007fff00 0ffeccbc c03a >> GPR24: c0821dc4 0003 c0934cf8 cba8 c0833e00 c07fdc6c >> NIP [c018f03c] of_platform_serial_probe+0x118/0x1e4 >> LR [c018f00c] of_platform_serial_probe+0xe8/0x1e4 >> Call Trace: > > Ok, that is a NULL pointer access, probably somewhere in the > of_platform_serial_setup that can be inlined. Please post the > device tree entries for your serial ports so we can see what > goes wrong there. The device tree is the default one which comes with the kernel: paulus.git/arch/powerpc/boot/dts/mpc8540ads.dts which contains: [EMAIL PROTECTED] { device_type = "serial"; compatible = "ns16550"; reg = <4500 100>; // reg base, size clock-frequency = <0>; // should we fill in in uboot? interrupts = <2a 2>; interrupt-parent = <&mpic>; }; [EMAIL PROTECTED] { device_type = "serial"; compatible = "ns16550"; reg = <4600 100>; // reg base, size clock-frequency = <0>; // should we fill in in uboot? interrupts = <2a 2>; interrupt-parent = <&mpic>; }; > One potential problem that I can see is a missing 'current-speed' > property in your tree, which would cause this behavior. That's correct. Should be fixed in all .dts' ? > It looks > like many device trees set this, but it is not required by all > bindings. How should someone know, when it's really needed and when not? > If that's the case, the patch below should fix your > problem, but you probably want to set the current-speed anyway, > according to your boot loader settings. I think there was no need to set it again, because of: console=ttyS0,115200 But I'll verify... > --- a/drivers/serial/of_serial.c > +++ b/drivers/serial/of_serial.c > @@ -56,7 +56,8 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev, >port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP >| UPF_FIXED_PORT; >port->dev = &ofdev->dev; > - port->custom_divisor = *clk / (16 * (*spd)); > + if (spd) > + port->custom_divisor = *clk / (16 * (*spd)); > >return 0; > } > Ack! However, I changed it similar to the available code. No idea what's better here. At least it should tell the user: Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A console [ttyS0] enabled serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 42) is a 16550A of_serial e0004500.serial: no current-speed property set of_serial e0004600.serial: no current-speed property set Patch attached. Regards, -- Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com Warn user when current-speed property isn't set and exit. Signed-off-by: Clemens Koller <[EMAIL PROTECTED]> CC: Arnd Bergmann <[EMAIL PROTECTED]> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c index a64d858..e035cb2 100644 --- a/drivers/serial/of_serial.c +++ b/drivers/serial/of_serial.c @@ -36,6 +36,10 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev, memset(port, 0, sizeof *port); spd = of_get_property(np, "current-speed", NULL); clk = of_get_property(np, "clock-frequency", NULL); + if (!spd) { + dev_warn(&ofdev->dev, "no current-speed property set\n"); + return -ENODEV; + } if (!clk) { dev_warn(&ofdev->dev, "no clock-frequency property set\n"); return -ENODEV; ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded