28 May, 2010

1 commit

  • gpiolib doesn't need to modify the names and I assume most initializers
    use string constants that shouldn't be modified anyhow.

    [akpm@linux-foundation.org: fix drivers/gpio/cs5535-gpio.c]
    Signed-off-by: Uwe Kleine-König
    Cc: Kevin Wells
    Cc: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Uwe Kleine-König
     

22 May, 2010

1 commit


19 May, 2010

1 commit


28 Apr, 2010

1 commit

  • Bill Gatliff reported the following bug when using the irq_chip facility
    of the pca953x driver on a PPC platform:

    BUG: scheduling while atomic: insmod/1530/0x00000002

    He traced it back to an i2c transaction in pca953x_irq_set_type(), which
    can be called with interrupt disabled (from __setup_irq()). As the i2c
    controller can sleep while sending a message, this qualifies as a bad
    idea.

    This patch moves the i2c transaction to pca953x_irq_bus_sync_unlock(),
    where it is actually safe to send an i2c message.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Marc Zyngier
    Reported-by: Bill Gatliff
    Cc: Eric Miao
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Marc Zyngier
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

07 Mar, 2010

1 commit

  • Most of the GPIO expanders controlled by the pca953x driver are able to
    report changes on the input pins through an *INT pin.

    This patch implements the irq_chip functionality (edge detection only).

    The driver has been tested on an Arcom Zeus.

    [akpm@linux-foundation.org: the compiler does inlining for us nowadays]
    Signed-off-by: Marc Zyngier
    Cc: Eric Miao
    Cc: Haojian Zhuang
    Cc: David Brownell
    Cc: Nate Case
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Marc Zyngier
     

23 Sep, 2009

2 commits


19 Jun, 2009

3 commits

  • PCA9556 is the software-compatible predecessor to the PCA9557, so add it
    to the supported I2C device ID table.

    Signed-off-by: Nate Case
    Cc: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nate Case
     
  • On OpenFirmware platforms, it makes the most sense to get platform_data
    from the device tree. Make an attempt to translate OF node properties
    into platform_data struct before bailing out.

    Note that the implementation approach taken differs from other device
    drivers that make use of device tree information. This is because I2C
    chips are already registered automatically by of_i2c, so we can get by
    with a small translator function in the driver.

    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: kfree(NULL) is legal]
    Signed-off-by: Nate Case
    Cc: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nate Case
     
  • Add support to the PCA953x driver to use the GPIOLIB naming facility for
    GPIOs.

    Signed-off-by: Daniel Silverstone
    Cc: Ben Gardner
    Cc: Jean Delvare
    Cc: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Daniel Silverstone
     

16 Jan, 2009

1 commit

  • A number of drivers in drivers/gpio return -ENODEV when confronted with
    missing setup parameters such as the platform data. However, returning
    -ENODEV causes the driver layer to silently ignore the driver as it
    assumes the probe did not find anything and was only speculative.

    To make life easier to discern why a driver is not being attached, change
    to returning -EINVAL, which is a better description of the fact that the
    driver data was not valid.

    Also add a set of dev_dbg() statements to the error paths to provide an
    better explanation of the error as there may be more that one point in the
    driver.

    Signed-off-by: Ben Dooks
    Cc: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ben Dooks
     

07 Jan, 2009

1 commit


17 Oct, 2008

1 commit

  • Make the I2C external GPIO expander drivers register themselves at
    subsys_initcall() time when they're statically linked.

    SOC-integrated GPIOs are available starting very early -- early in
    arch_initcall() at latest, but often even before initcalls start to run --
    so this improves consistency, so more subsystems can rely on GPIOs in
    their own subsys_initcall() code.

    (This isn't a theoretical problem. This is one of several patches needed
    to resolve oopsing observed when statically linking kernels on a DaVinci
    EVM. Its pcf857x GPIOs needed to be available well before some other
    drivers initialized.)

    Signed-off-by: David Brownell
    Cc: Jean Delvare
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Brownell
     

26 Jul, 2008

1 commit

  • This adds a simple sysfs interface for GPIOs.

    /sys/class/gpio
    /export ... asks the kernel to export a GPIO to userspace
    /unexport ... to return a GPIO to the kernel
    /gpioN ... for each exported GPIO #N
    /value ... always readable, writes fail for input GPIOs
    /direction ... r/w as: in, out (default low); write high, low
    /gpiochipN ... for each gpiochip; #N is its first GPIO
    /base ... (r/o) same as N
    /label ... (r/o) descriptive, not necessarily unique
    /ngpio ... (r/o) number of GPIOs; numbered N .. N+(ngpio - 1)

    GPIOs claimed by kernel code may be exported by its owner using a new
    gpio_export() call, which should be most useful for driver debugging.
    Such exports may optionally be done without a "direction" attribute.

    Userspace may ask to take over a GPIO by writing to a sysfs control file,
    helping to cope with incomplete board support or other "one-off"
    requirements that don't merit full kernel support:

    echo 23 > /sys/class/gpio/export
    ... will gpio_request(23, "sysfs") and gpio_export(23);
    use /sys/class/gpio/gpio-23/direction to (re)configure it,
    when that GPIO can be used as both input and output.
    echo 23 > /sys/class/gpio/unexport
    ... will gpio_free(23), when it was exported as above

    The extra D-space footprint is a few hundred bytes, except for the sysfs
    resources associated with each exported GPIO. The additional I-space
    footprint is about two thirds of the current size of gpiolib (!). Since
    no /dev node creation is involved, no "udev" support is needed.

    Related changes:

    * This adds a device pointer to "struct gpio_chip". When GPIO
    providers initialize that, sysfs gpio class devices become children of
    that device instead of being "virtual" devices.

    * The (few) gpio_chip providers which have such a device node have
    been updated.

    * Some gpio_chip drivers also needed to update their module "owner"
    field ... for which missing kerneldoc was added.

    * Some gpio_chips don't support input GPIOs. Those GPIOs are now
    flagged appropriately when the chip is registered.

    Based on previous patches, and discussion both on and off LKML.

    A Documentation/ABI/testing/sysfs-gpio update is ready to submit once this
    merges to mainline.

    [akpm@linux-foundation.org: a few maintenance build fixes]
    Signed-off-by: David Brownell
    Cc: Guennadi Liakhovetski
    Cc: Greg KH
    Cc: Kay Sievers
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Brownell
     

05 Jul, 2008

1 commit

  • The pca953x driver can handle another 8-bit I/O expander, the max7310.
    This patch adds that chip to the list of supported IDs in that driver, and
    expands the Kconfig helptext accordingly.

    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Brownell
     

25 May, 2008

1 commit


01 May, 2008

1 commit


30 Apr, 2008

2 commits

  • Based on earlier work by Jon Smirl and Jochen Friedrich.

    Update most new-style i2c drivers to use standard module aliasing
    instead of the old driver_name/type driver matching scheme. I've
    left the video drivers apart (except for SoC camera drivers) as
    they're a bit more diffcult to deal with, they'll have their own
    patch later.

    Signed-off-by: Jean Delvare
    Cc: Jon Smirl
    Cc: Jochen Friedrich

    Jean Delvare
     
  • Based on earlier work by Jon Smirl and Jochen Friedrich.

    This patch allows new-style i2c chip drivers to have alias names using
    the official kernel aliasing system and MODULE_DEVICE_TABLE(). At this
    point, the old i2c driver binding scheme (driver_name/type) is still
    supported.

    Signed-off-by: Jean Delvare
    Cc: Jochen Friedrich
    Cc: Jon Smirl
    Cc: Kay Sievers

    Jean Delvare
     

28 Apr, 2008

1 commit

  • Use the newly introduced owner field in struct gpio_chip to protect the
    current (small) set of non-SOC GPIO drivers from being unloaded while any of
    their GPIOs are in use.

    Signed-off-by: Guennadi Liakhovetski
    [ add mcp23s08 and pcf857x ]
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Guennadi Liakhovetski
     

11 Mar, 2008

1 commit

  • The pca953x driver is an I2C driver so gpio_chip->can_sleep should be set.
    This lets upper layers know they should use the gpio_*_cansleep() calls to
    access values, and may not access them from nonsleeping contexts.

    Signed-off-by: Arnaud Patard
    Signed-off-by: David Brownell
    Acked-by: "eric miao"
    Cc: Jean Delvare
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arnaud Patard
     

07 Feb, 2008

3 commits

  • This third part of an extension to support more pca953x chips updates the
    logic to handle the smaller register widths used by the 4-bit and 8-bit parts,
    and to use the chip type to determine how many GPIOs it provides.

    As long as we don't support interrupt and reset capabilities, those size
    issues are the only software-visible differences between these parts.

    Signed-off-by: Guennadi Liakhovetski
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Guennadi Liakhovetski
     
  • This second part of an extension to support more pca953x chips renames the C
    and Kconfig symbols. All affected files were updated by sed, except for a
    couple of obvious exceptions. It also updates the Kconfig helptext.

    Signed-off-by: Guennadi Liakhovetski
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Guennadi Liakhovetski
     
  • First part of an extension to let the pca9539 driver support more chips,
    starting with pca9534, pca9535, pca9536, pca9537, and pca9538.

    This renames the files and modifies the Makefile.

    Signed-off-by: Guennadi Liakhovetski
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Guennadi Liakhovetski