commit 96f699ad09c8b3c55cd229506a9add0047838e3e upstream.

I've tested TSL2550 driver and I've found a bug: when light is off,
returned value from tsl2550_calculate_lux function is -1 when it should
be 0 (sensor correctly read that light was off).

I think the bug is that a zero c0 value (approximated value of ch0) is
misinterpreted as an error.

Signed-off-by: Michele Jr De Candia <michele.decandia@valueteam.com>
Acked-by: Rodolfo Giometti <giometti@linux.it>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

* 'i2c-for-2630-rc5' of git://aeryn.fluff.org.uk/bjdooks/linux:
  i2c-cpm: Pass dev ptr to dma_*_coherent rather than NULL
  i2c: Enable i2c-s3c2410 for S3C64XX too
  i2c-mpc: bug fix for MPC52xx clock setting and printout
  i2c-pxa.c: timeouts off by 1

Recent DMA changes result in a BUG() when NULL is passed to
dma_alloc_coherent in place of a device.

Signed-off-by: Mark Ware <mware@elphinstone.net>
[ben-linux@fluff.org: fix patch moves]
Signed-off-by: Ben Dooks <ben-linux@fluff.org>

This controller is also present on the S3C64xx series processors so
enable the driver in Kconfig for those platforms.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>

The clock setting did not work for the MPC52xx due to a stupid bug.
Furthermore, the dev info output "clock=0" for old device trees was
misleading. This patch fixes both issues.

Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>

Currently, the i2c-algo-pca driver does nothing if the chip enters state
0x30 (Data byte in I2CDAT has been transmitted; NOT ACK has been
received).  Thus, the i2c bus connected to the controller gets stuck
afterwards.

I have seen this kind of error on a custom board in certain load
situations most probably caused by interference or noise.

A possible reaction is to let the controller generate a STOP condition.
This is documented in the PCA9564 data sheet (2006-09-01) and the same
is done for other NACK states as well.

Further, state 0x38 isn't handled completely, either. Try to do another
START in this case like the data sheet says. As this couldn't be tested,
I've added a comment to try to reset the chip if the START doesn't help
as suggested by Wolfram Sang.

Signed-off-by: Enrik Berkhan <Enrik.Berkhan@ge.com>
Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>

When fetching DDC using i2c algo bit, we were often seeing timeouts
before getting valid EDID on a retry. The VESA spec states 2ms is the
DDC timeout, so when this translates into 1 jiffie and we are close
to the end of the time period, it could return with a timeout less than
2ms.

Change this code to use time_after instead of time_after_eq.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>

with while (timeout++ < MAX_TIMEOUT); timeout reaches MAX_TIMEOUT + 1
after the loop, so the tests below are off by one.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>

With `while (timeout--)' timeout reaches -1 after the loop, so the tests
below are off by one.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>

While it isn't the way the standard device binding model works, it is
OK for new-style drivers to implement attach_adapter. It may help
convert the renaming legacy drivers to new style drivers faster.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>