12 Jan, 2006

1 commit

  • - Move capable() from sched.h to capability.h;

    - Use where capable() is used
    (in include/, block/, ipc/, kernel/, a few drivers/,
    mm/, security/, & sound/;
    many more drivers/ to go)

    Signed-off-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy.Dunlap
     

09 Jan, 2006

1 commit

  • HDIO_GETGEO is implemented in most block drivers, and all of them have to
    duplicate the code to copy the structure to userspace, as well as getting
    the start sector. This patch moves that to common code [1] and adds a
    ->getgeo method to fill out the raw kernel hd_geometry structure. For many
    drivers this means ->ioctl can go away now.

    [1] the s390 block drivers are odd in this respect. xpram sets ->start
    to 4 always which seems more than odd, and the dasd driver shifts
    the start offset around, probably because of it's non-standard
    sector size.

    Signed-off-by: Christoph Hellwig
    Cc: Jens Axboe
    Cc:
    Cc: Jeff Dike
    Cc: Paolo Giarrusso
    Cc: Bartlomiej Zolnierkiewicz
    Cc: Neil Brown
    Cc: Markus Lidel
    Cc: Russell King
    Cc: David Woodhouse
    Cc: Martin Schwidefsky
    Cc: James Bottomley
    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     

06 Jan, 2006

3 commits

  • Now that i2c_add_driver() doesn't need the module owner to be set by
    hand, we can delete it from the drivers. This patch catches all of the
    drivers that I found in the current tree (if a driver sets the .owner by
    hand, it's not a problem, just not needed.)

    Signed-off-by: Greg Kroah-Hartman
    Cc: Jean Delvare

    Greg Kroah-Hartman
     
  • We should use the i2c_driver.driver's .name and .owner fields
    instead of the i2c_driver's ones.

    This patch updates the drivers for acorn arch.

    Signed-off-by: Laurent Riffard
    Signed-off-by: Jean Delvare
    Acked-by: Russell King
    Signed-off-by: Greg Kroah-Hartman

    Laurent Riffard
     
  • Just about every i2c chip driver sets the I2C_DF_NOTIFY flag, so we
    can simply make it the default and drop the flag. If any driver really
    doesn't want to be notified when i2c adapters are added, that driver
    can simply omit to set .attach_adapter. This approach is also more
    robust as it prevents accidental NULL pointer dereferences.

    Signed-off-by: Jean Delvare
    Signed-off-by: Greg Kroah-Hartman

    Jean Delvare
     

31 Oct, 2005

1 commit


21 Sep, 2005

1 commit


10 Sep, 2005

1 commit


07 Aug, 2005

1 commit


22 Jun, 2005

1 commit

  • Some months ago, you killed the address ranges mechanism from all
    sensors i2c chip drivers (both the module parameters and the in-code
    address lists). I think it was a very good move, as the ranges can
    easily be replaced by individual addresses, and this allowed for
    significant cleanups in the i2c core (let alone the impressive size
    shrink for all these drivers).

    Unfortunately you did not do the same for non-sensors i2c chip drivers.
    These need the address ranges even less, so we could get rid of the
    ranges here as well for another significant i2c core cleanup. Here comes
    a patch which does just that. Since the process is exactly the same as
    what you did for the other drivers set already, I did not split this one
    in parts.

    A documentation update is included.

    The change saves 308 bytes in the i2c core, and an average 1382 bytes
    for chip drivers which use I2C_CLIENT_INSMOD, 126 bytes for those which
    do not.

    This change is required if we want to merge the sensors and non-sensors
    i2c code (and we want to do this).

    Signed-off-by: Jean Delvare
    Signed-off-by: Greg Kroah-Hartman

    Index: gregkh-2.6/Documentation/i2c/writing-clients
    ===================================================================

    Jean Delvare
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds