This patch adds checking for NULL value returned to prevent possible
NULL pointer dereference.
Also two unneeded 'return' are removed.
Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
---
Any comments are welcome.
arch/powerpc/platforms/celleb/pci.c | 23 ---
1 files chang
On Thu, 2007-11-08 at 02:12 +0300, Yuri Tikhonov wrote:
> This is the updated patch for support synchronization of L2-Cache with the
> external memory on the ppc44x-based platforms.
>
> Differencies against the previous patch-set:
> - remove L2_CACHE config option;
> - introduce the ppc machdep
On Mon, Nov 26, 2007 at 03:23:14AM +0300, Anton Vorontsov wrote:
> On Sat, Nov 24, 2007 at 04:26:13PM +0900, Paul Mundt wrote:
> > On Fri, Nov 23, 2007 at 07:49:33PM -0500, Jeff Garzik wrote:
> > > Anton Vorontsov wrote:
> > > >Here is the PATA Platform driver using OF infrastructure.
> > > >
> > >
On Sat, Nov 24, 2007 at 09:57:46PM +0100, Arnd Bergmann wrote:
> On Friday 23 November 2007, Anton Vorontsov wrote:
> >
> > +static struct of_device_id mpc834x_ids[] = {
> > + { .compatible = "pata-platform", },
> > + {},
> > +};
> > +
> > +static int __init mpc834x_declare_of_platform
On Sat, Nov 24, 2007 at 04:26:13PM +0900, Paul Mundt wrote:
> On Fri, Nov 23, 2007 at 07:49:33PM -0500, Jeff Garzik wrote:
> > Anton Vorontsov wrote:
> > >Here is the PATA Platform driver using OF infrastructure.
> > >
> > >Mostly it's just a wrapper around a bit modified pata_platform
> > >driver.
On Sat, Nov 24, 2007 at 09:50:07PM +0100, Arnd Bergmann wrote:
> On Friday 23 November 2007, Anton Vorontsov wrote:
> > Here is the PATA Platform driver using OF infrastructure.
> >
> > Mostly it's just a wrapper around a bit modified pata_platform
> > driver.
>
> Thanks a lot for doing this. Pat
This patch fixes bits of the DRM so to make the radeon DRI work on
non-cache coherent PCI DMA variants of the PowerPC processors.
It moves the few places that needs change to wrappers to that
other architectures with similar issues can easily add their
own changes to those wrappers, at least until
The OHCI driver's IRQ handler, while processing a WDH interrupt, masks
and unmasks it. I believe this is both broken (no dealign with write
posting) and totally useless as the IRQ cannot re-occur while we are in
the handler anyway.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
It
The OHCI IRQ handler has an optimisation that tries to avoid reading
the status register when it sees something has been put in the
controller "done list".
This optimisation is broken on controllers that use edge interrupt
signaling as it relies on "missed" interrupt to be re-emitted which
is not
On 11/24/07, Stephen Neuendorffer <[EMAIL PROTECTED]> wrote:
>
Thanks for all this work; comments below.
>
> Here's what I've gotten so far:
>
> Hard_Ethernet_MAC: [EMAIL PROTECTED] {
> #address-cells = <1>;
> #size-cells = <1>;
>
On Wednesday 21 November 2007, Kumar Gala wrote:
> + * Freescale 8xxx/3.0 Gb/s SATA nodes
> +
> + SATA nodes are defined to describe on-chip Serial ATA controllers.
> + Each SATA port should have its own node.
> +
> + Required properties:
> + - compatible : compatible list, co
This removes the handling for PTRACE_CONT et al from the powerpc
ptrace code, so it uses the new generic code via ptrace_request.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ptrace.c | 46 --
1 files changed, 0 insertions(+)
This defines the new standard arch_has_single_step macro. It makes the
existing set_single_step and clear_single_step entry points global, and
renames them to the new standard names user_enable_single_step and
user_disable_single_step, respectively.
Signed-off-by: Roland McGrath <[EMAIL PROTECTE
> You can dump the PCI config block in /sys with hexdump and see if the
> PCI_COMMAND_MEMORY bit is set. I was also unable to locate where in
> the kernel PCI_COMMAND_MEMORY is being set. It could be that it is set
> by the BIOS at boot on the x86 and not on the ppc.
The kernel doesn't until some
On 11/25/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> Now, regarding that user problem, this it totally unrelated as it's a
> "mac" card.
>
> It's possible that it's one of these radeons that disable ROM access via
> a register in which case a quirk is needed to re-enable it.
He says in
On Nov 25, 2007, at 8:18 AM, Vitaly Bordug wrote:
> To prevent using those pointers from within non-GPL modules. kind
> of policy now...
As the original copyright holder of nearly all of this of
this code, I do not wish this be done.
Thanks.
-- Dan
__
On Sun, 2007-11-25 at 18:00 +0100, Clemens Koller wrote:
> Put that PCI Card to your host where your stepper was working
> properly to see if it's a hardware issue with that card.
>
> Then it depends on how you control your stepper motor. If you use
> some bit-banging (which I wouldn't recommend)
On Sun, 2007-11-25 at 15:51 -0500, Jon Smirl wrote:
>
> They blocked the X server changes, which rendered the kernel support
> pointless. But that's all old news.
No, you are wrong, nothing was ever "blocked".
Ben.
___
Linuxppc-dev mailing list
Linu
On 11/25/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-11-25 at 08:30 -0500, Jon Smirl wrote:
> >
> > > The two cards with x86 firmware return 0xFF for those two readb()
> > > instructions, while the X1900 with OF returns 0x00 for the readb().
> > >
> > > Could one of the m
On Thu, 22 Nov 2007 17:54:13 +0100
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]>
Applied to linux-2.6-8xx.git, for-paulus b
On Thu, 22 Nov 2007 17:53:54 +0100
Jochen Friedrich wrote:
> Remove exports of __res and cpm_install_handler/cpm_free_handler.
> Remove cpm_install_handler/cpm_free_handler from the commproc.h as
> well. Both were used for ARCH=ppc and aren't defined for
> ARCH=powerpc.
>
> CC arch/powerpc/
On Thu, 22 Nov 2007 17:53:47 +0100
Jochen Friedrich wrote:
> fpi->cp_command should be overwritten only if
> CONFIG_PPC_CPM_NEW_BINDING is NOT set. Otherwise it is already set
> from the device tree.
>
> Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
> Cc: Paul Mackerras <[EMAIL PROTECTED]>
On Sun, 2007-11-25 at 08:30 -0500, Jon Smirl wrote:
>
> > The two cards with x86 firmware return 0xFF for those two readb()
> > instructions, while the X1900 with OF returns 0x00 for the readb().
> >
> > Could one of the more knowledgeable folk for PPC intricacies suggest
> why
> > those readb ca
On Sun, Nov 25, 2007 at 08:30:58AM -0500, Jon Smirl wrote:
> I don't know PPC at this low of level but it may be a problem with non
> word-aligned access to memory. I thought readb() was supposed to work
> on all archs and alignment issues are handled inside readb(). Also,
> the readw() may have an
Hi,
[can you CC me? I can sometimes only skim the lists]
> No, I saw the high hardware interrupt value in top and looked at
> /proc/interrupts and concluded that those are the evil source of the
> high load.
>
> > I'm fairly sure that I always had rather high numbers of interrupt
> > here. And t
Bai Shuwei schrieb:
Please don't cross-post.
> hi, all
> I bought a SMC1500 stepper motor card. And it can connect with host
> through parallel port. My target board is PowerPC 440, which hasn't
> parrallel port. So I bought a PCI to Parallel line for SMC1500. But when
> I run the stepper
On Sun, 25 Nov 2007 09:38:57 -0600
Timur Tabi wrote:
> Jochen Friedrich wrote:
> > fs_enet and cpm_uart need symbols from commproc.c (for CPM1) or
> > cpm2_common.c. Add EXPORT_SYMBOL_GPL for cpmp, cpm_setbrg and
> > cpm2_immr, so the drivers can be compiled as modules.
As I told replying to prev
On 11/25/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jochen Friedrich wrote:
> > fs_enet and cpm_uart need symbols from commproc.c (for CPM1) or
> > cpm2_common.c. Add EXPORT_SYMBOL_GPL for cpmp, cpm_setbrg and cpm2_immr,
> > so the drivers can be compiled as modules.
>
> Maybe this is a stupid que
Jochen Friedrich wrote:
> fs_enet and cpm_uart need symbols from commproc.c (for CPM1) or
> cpm2_common.c. Add EXPORT_SYMBOL_GPL for cpmp, cpm_setbrg and cpm2_immr,
> so the drivers can be compiled as modules.
Maybe this is a stupid question, but why did you choose EXPORT_SYMBOL_GPL and
not EXPOR
On 11/25/07, Robin H. Johnson <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 25, 2007 at 03:15:35AM -0800, Robin H. Johnson wrote:
> > I started in there from that, and ended up in pci-sysfs.c...
> > The ROM memcpy in drivers/pci/pci-sysfs.c:pci_read_rom() is never running.
> ...
> > [ 306.396743] drive
Hi,
Johannes Berg <[EMAIL PROTECTED]> wrote:
>> % diff /proc/interrupts <(sleep 2; cat /proc/interrupts)
>> --- /proc/interrupts2007-11-23 15:04:06.004846901 +0100
>> +++ /proc/self/fd/112007-11-23 15:04:05.952841422 +0100
>> @@ -1,15 +1,15 @@
>> CPU0
>> - 25: 18063968
On Sun, Nov 25, 2007 at 03:15:35AM -0800, Robin H. Johnson wrote:
> I started in there from that, and ended up in pci-sysfs.c...
> The ROM memcpy in drivers/pci/pci-sysfs.c:pci_read_rom() is never running.
...
> [ 306.396743] drivers/pci/pci-sysfs.c:577:pci_read_rom: size=0x0
> rom=0xd8008258
On Sat, Nov 24, 2007 at 09:13:40PM -0500, Jon Smirl wrote:
> The ROM is mapped in drivers/pci/rom.c
>
> You could add some printks and see if there is an error and if the ROM
> is accessible
>
> rom = ioremap(start, *size);
> if (!rom) {
> /* restore enable if iore
On Sun, Nov 25, 2007 at 10:42:42AM +0100, Andreas Schwab wrote:
> "Robin H. Johnson" <[EMAIL PROTECTED]> writes:
>
> > I put the card into an amd64 box, found the relevant 'rom' node ($ROM) under
> > /sys/device/pci*, and dumped it as follows:
> > # echo 1>$ROM
> Did you run it exactly like this?
"Robin H. Johnson" <[EMAIL PROTECTED]> writes:
> I put the card into an amd64 box, found the relevant 'rom' node ($ROM) under
> /sys/device/pci*, and dumped it as follows:
> # echo 1>$ROM
Did you run it exactly like this? Because this will echo exactly one
newline to $ROM. If you want to echo "
35 matches
Mail list logo
