18 Sep, 2006

1 commit

  • If the user tries to traverse to the next node of the
    last node, we get NULL in current_node and a zero phandle
    returned. That's fine, but if the user tries to obtain
    properties in that state, we try to dereference a NULL
    pointer in the downcall to the of_*() routines.

    So protect against that.

    Signed-off-by: David S. Miller

    David S. Miller
     

22 Jul, 2006

1 commit


03 Jul, 2006

1 commit


01 Jul, 2006

1 commit


27 Jun, 2006

4 commits


26 Jun, 2006

4 commits


24 Jun, 2006

4 commits


20 Jun, 2006

1 commit

  • This ugly hack was long overdue to die.

    It was a way to print out Sparc interrupts in a more freindly format,
    since IRQ numbers were arbitrary opaque 32-bit integers which vectored
    into PIL levels. These 32-bit integers were not necessarily in the
    0-->NR_IRQS range, but the PILs they vectored to were.

    The idea now is that we will increase NR_IRQS a little bit and use a
    virtualreal IRQ number mapping scheme similar to PowerPC.

    That makes this IRQ printing hack irrelevant, and furthermore only a
    handful of drivers actually used __irq_itoa() making it even less
    useful.

    Signed-off-by: David S. Miller

    David S. Miller
     

13 May, 2006

1 commit


22 Mar, 2006

1 commit


20 Mar, 2006

1 commit


15 Jan, 2006

1 commit


16 Dec, 2005

3 commits


23 Nov, 2005

1 commit


13 Nov, 2005

1 commit

  • On Fri, Nov 11, 2005 at 12:58:40PM -0800, David S. Miller wrote:
    >
    > This change:
    >
    > diff-tree 8ca2bdc7a98b9584ac5f640761501405154171c7 (from feee207e44d3643d19e648aAuthor: Christoph Hellwig
    > Date: Wed Nov 9 12:07:18 2005 -0800
    >
    > [SPARC] sbus rtc: implement ->compat_ioctl
    >
    > Signed-off-by: Christoph Hellwig
    > Signed-off-by: David S. Miller
    >
    > results in the console now getting spewed on sparc64 systems
    > with messages like:
    >
    > [ 11.968298] ioctl32(hwclock:464): Unknown cmd fd(3) cmd(401c7014){00} arg(efc
    > What's happening is hwclock tries first the SBUS rtc device ioctls
    > then the normal rtc driver ones.
    >
    > So things actually worked better when we had the SBUS rtc compat ioctl
    > directly handled via the generic compat ioctl code.
    >
    > There are _so_ many rtc drivers in the kernel implementing the
    > generic rtc ioctls that I don't think putting a ->compat_ioctl
    > into all of them to fix this problem is feasible. Unless we
    > write a single rtc_compat_ioctl(), export it to modules, and hook
    > it into all of those somehow.
    >
    > But even that doesn't appear to have any pretty implementation.
    >
    > Any better ideas?

    We had similar problems with other ioctls where userspace did things
    like that. What we did there was to put the compat handler to generic
    code. The patch below does that, adding a big comment about what's
    going on and removing the COMPAT_IOCTL entires for these on powerpc
    that not only weren't ever useful but are duplicated now aswell.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: David S. Miller

    Christoph Hellwig
     

11 Nov, 2005

1 commit


10 Nov, 2005

2 commits


09 Nov, 2005

1 commit


08 Nov, 2005

4 commits


07 Nov, 2005

1 commit

  • This is the remaining misc drivers/ part of the big kfree cleanup patch.

    Remove pointless checks for NULL prior to calling kfree() in misc files in
    drivers/.

    Signed-off-by: Jesper Juhl
    Acked-by: Aristeu Sergio Rozanski Filho
    Acked-by: Roland Dreier
    Acked-by: Pierre Ossman
    Acked-by: Jean Delvare
    Acked-by: Greg Kroah-Hartman
    Acked-by: Len Brown
    Acked-by: "Antonino A. Daplas"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jesper Juhl
     

13 Sep, 2005

2 commits


11 Sep, 2005

1 commit


10 Sep, 2005

1 commit


31 Aug, 2005

1 commit