Fix various printk format strings where %zd was passed a size_t;
those should be %zu instead.  (Courtesy of a version of GCC which
warns when these details are wrong.)
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

We check for address business in i2c_probe_address(),
i2c_detect_address() and i2c_new_probed_device(), but this isn't
sufficient. Drivers can call i2c_attach_client() and
i2c_new_device() on any address, so we must check the address there
as well.

This fixes bug #11239:
http://bugzilla.kernel.org/show_bug.cgi?id=11239Signed-off-by: NJean Delvare <khali@linux-fr.org>

In kernel 2.6.26, the ability to select I2C algorithm drivers manually
was removed, as all in-kernel drivers do that automatically. However
there were some complaints that it was a problem for out-of-tree I2C
bus drivers. In order to address these complaints, let's allow manual
selection of these drivers again, but still hide them by default for
better general user experience.

This closes bug #11140:
http://bugzilla.kernel.org/show_bug.cgi?id=11140Signed-off-by: NJean Delvare <khali@linux-fr.org>

Fix a NULL pointer dereference that happened when calling
i2c_new_probed_device on one of the addresses for which we use byte
reads instead of quick write for detection purpose (that is: 0x30-0x37
and 0x50-0x5f).
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The two I2C bus multiplexer drivers (i2c-amd756-s4882 and
i2c-nforce2-s4985) make use of the bus they want to multiplex before
checking if it is really present. Swap the instructions to test for
presence first. This fixes a oops reported by Ingo Molnar.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Ingo Molnar <mingo@elte.hu>

This just leaves include/asm-arm/plat-* to deal with.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Remove includes of asm/hardware.h in addition to asm/arch/hardware.h.
Then, since asm/hardware.h only exists to include asm/arch/hardware.h,
update everything to directly include asm/arch/hardware.h and remove
asm/hardware.h.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

There are 43 includes of asm/mach-types.h by files that don't
reference anything from that file.  Remove these unnecessary
includes.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

PM_SUSPEND_MEM: Blackfin does not maintain register state through
Hibernate. Save and restore peripheral base initialization during
PM transitions.
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NBryan Wu <cooloney@kernel.org>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Add support for CPU frequency scaling to the S3C24XX I2C driver.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Change the i2c_gpio driver to use platform_driver_register()
instead of platform_driver_probe() to ensure that is can
attach to any devices that may be loaded after it has initialised.
Acked-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Allow the platform data to specify the bus bumber that the
new I2C bus will be given. This is to allow the use of the
board registration mechanism to specify the new style of
I2C device registration which allows boards to provide a
list of attached devices.

Note, as discussed on the mailing list, we have dropped
backwards compatibility of adding an dynamic bus number
as it should not affect most boards to have the bus pinned
to 0 if they have either not specified platform data for
driver. Any board supplying platform data will automatically
have the bus_num field set to 0, and anyone who needs the
driver on a different bus number can supply platform data
to set bus_num.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

This patch adds functionality to the gpio-lib subsystem to make it
possible to enable the gpio-lib code even if the architecture code didn't
request to get it built in.

The archtitecture code does still need to implement the gpiolib accessor
functions in its asm/gpio.h file.  This patch adds the implementations for
x86 and PPC.

With these changes it is possible to run generic GPIO expansion cards on
every architecture that implements the trivial wrapper functions.  Support
for more architectures can easily be added.
Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: David Brownell <david-b@pacbell.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Samuel Ortiz <sameo@openedhand.com>
Cc: Kumar Gala <galak@gate.crashing.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Adrian Bunk <bunk@stusta.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Guennadi Liakhovetski <g.liakhovetski@pengutronix.de>
Cc: Greg KH <greg@kroah.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This mirrors the functionality that driver_for_each_device has as well.

We add a start variable, and all callers of the function are fixed up at
the same time.

The block layer will be using this new functionality in a follow-on
patch.


Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

device_create() is race-prone, so use the race-free
device_create_drvdata() instead as device_create() is going away.

Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The new-style max6875 driver implements the optional detect() callback
to cover the use cases of the legacy driver. I'm curious if anyone
really needs this though, so it might be removed in the feature.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The new-style pca9539 driver implements the optional detect() callback
to cover the use cases of the legacy driver.

Warning: users will now have to use the force module parameter to get
the driver to attach to their device. That's not a bad thing as these
devices can't be detected anyway.

Note that this doesn't change the fact that this driver is deprecated
in favor of gpio/pca953x.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The new-style pcf8575 driver implements the optional detect() callback
to cover the use cases of the legacy driver.

Warning: users will now have to use the force module parameter to get
the driver to attach to their device. That's not a bad thing as these
devices can't be detected anyway.

Note that this doesn't change the fact that this driver is deprecated
in favor of gpio/pcf857x.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The new-style pcf8574 driver implements the optional detect() callback
to cover the use cases of the legacy driver.

Warning: users will now have to use the force module parameter to get
the driver to attach to their device. That's not a bad thing as these
devices can't be detected anyway.

Note that this doesn't change the fact that this driver is deprecated
in favor of gpio/pcf857x.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The new-style pcf8591 driver implements the optional detect() callback
to cover the use cases of the legacy driver.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The new-style eeprom driver implements the optional detect() callback
to cover the use cases of the legacy driver.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Clear i2c_adapter.dev on adapter removal. This makes it possible to
re-add the adapter at a later point, which some drivers
(i2c-amd756-s4882, i2c-nforce2-s4985) actually do.

This fixes a bug reported by John Stultz here:
  http://lkml.org/lkml/2008/7/15/720
and by Ingo Molar there:
  http://lkml.org/lkml/2008/7/16/78Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>

Add a mechanism to let new-style i2c drivers optionally autodetect
devices they would support on selected buses and ask i2c-core to
instantiate them. This is a replacement for legacy i2c drivers, much
cleaner.

Where drivers had to implement both a legacy i2c_driver and a
new-style i2c_driver so far, this mechanism makes it possible to get
rid of the legacy i2c_driver and implement both enumerated and
detected device support with just one (new-style) i2c_driver.

Here is a quick conversion guide for these drivers, step by step:

* Delete the legacy driver definition, registration and removal.
  Delete the attach_adapter and detach_client methods of the legacy
  driver.

* Change the prototype of the legacy detect function from
    static int foo_detect(struct i2c_adapter *adapter, int address, int kind);
  to
    static int foo_detect(struct i2c_client *client, int kind,
    			  struct i2c_board_info *info);

* Set the new-style driver detect callback to this new function, and
  set its address_data to &addr_data (addr_data is generally provided
  by I2C_CLIENT_INSMOD.)

* Add the appropriate class to the new-style driver. This is
  typically the class the legacy attach_adapter method was checking
  for. Class checking is now mandatory (done by i2c-core.) See
  <linux/i2c.h> for the list of available classes.

* Remove the i2c_client allocation and freeing from the detect
  function. A pre-allocated client is now handed to you by i2c-core,
  and is freed automatically.

* Make the detect function fill the type field of the i2c_board_info
  structure it was passed as a parameter, and return 0, on success. If
  the detection fails, return -ENODEV.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

We call adapter->client_register for both legacy and new-style i2c
devices, however we only call adapter->client_unregister for legacy
drivers. This doesn't make much sense. Usually, drivers will undo
in client_unregister what they did in client_register, so we should
call neither or both for every given i2c device.

In order to ease the transition from legacy to new-style devices, it
seems preferable to actually call both.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: David Brownell <david-b@pacbell.net>

Clean up old i2c chip drivers:
* Name the i2c_client "client" instead of "new_client".
* Drop useless initializations to 0.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

This patch completes the conversion of the IBM IIC driver to an
of-platform driver.

It removes the index from the IBM IIC driver and makes it an unnumbered
driver. It then calls of_register_i2c_devices to properly register all
the child nodes in the DTS.
Signed-off-by: NSean MacLennan <smaclennan@pikatech.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Add a new-style driver for most I2C EEPROMs, giving sysfs read/write
access to their data. Tested with various chips and clock rates.
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Export the root of the i2c bus so that PowerPC device tree code can
iterate over devices on the i2c bus.
Signed-off-by: NJon Smirl <jonsmirl@gmail.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Fix driver power management:
- suspend the PSC while driver is idle.
- move PSC init/deinit to separate functions, as PSC must be
  initialized/shutdown on resume/suspend.
Signed-off-by: NManuel Lauss <mano@roarinelk.homelinux.net>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Implementing detach_client is optional, so there is no point in
an empty implementation.

Likewise, i2c driver IDs are optional, and we don't need one.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Signed-off-by: NJean Delvare <khali@linux-fr.org>

Check for ACPI resource conflicts in i2c bus drivers. I've included
all recent SMBus master drivers for PC hardware.

I've voluntarily left out:
* Drivers that don't run on PCs: they can't conflict with ACPI.
* Bit-banged bus device drivers: it's very unlikely that ACPI would
  deal with such buses.
Signed-off-by: NJean Delvare <jdelvare@suse.de>

Basic PM support: reinit the core on resume, disable it on suspend.
Signed-off-by: NManuel Lauss <mano@roarinelk.homelinux.net>
Acked-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

 The standard rtc-m41t80.c driver cannot be used with the SWARM as it is,
because the board does not provide setup information for the I2C core.  
As a result the bus and the address to probe for the M41T80 chip is not
known.

 Here is a set of changes that fix the problem:

1. swarm-i2c.c -- SWARM I2C board setup, currently for the M41T80 chip on 
   the bus #1 only (there is a MAX6654 temperature sensor on the bus #0 
   which may be added in the future if we have a driver for that chip).

2. The i2c-sibyte.c BCM1250A SMBus controller driver now registers its 
   buses as numbered so that board setup is correctly applied.
Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Move the check of pre-transaction and post-transaction conditions to
separate functions, and adjust them a bit. Having dedicated functions
for that ensures that errors are handled in a consistent way.

Bit HOST_BUSY of the status register is read-only, so writing to it is
certainly not going to clear it. If this bit is set then we simply
don't want to start the transaction, as it means that somebody else
(ACPI, SMM?) is already using the controller.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

"temp" isn't a terribly well chosen name for a local variable.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Bit BUS_ERR of the status register means that the ICH host controller
lost the arbitration. Report this event as such.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Dumping the register values before and after every transaction was
useful during driver development but now it's only spamming the log.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Struct members udelay and timeout aren't used anywhere, so drop them.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NEric Brower <ebrower@gmail.com>