i2c-core takes care of the possible corruption of 24RF08 chips for quite some times, so device devices no longer need to do it. And they really should not, as applying the prevention twice voids it. I thought that I had fixed all drivers long ago but apparently I had missed that one. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Ben Gardner <bgardner@wabtec.com>
The i2c-amd756 driver pretends to support SMBus process call transactions but actually does not. Fix it. Signed-off-by: Jean Delvare <khali@linux-fr.org>
Remove the old driver_name/type scheme for i2c driver matching. Only the standard aliasing model will be used from now on. Signed-off-by: Jean Delvare <khali@linux-fr.org>
There is a strange chip at 0x2e on the second SMBus channel of the DFI Lanparty NF4 Expert motherboard. Accessing the chip reboots the system. As there's nothing interesting on this SMBus channel, the easiest and safest thing to do is to disable it on that board. This is a better fix to bug #5889 than the it87 driver update that was done originally: http://bugzilla.kernel.org/show_bug.cgi?id=5889 Signed-off-by: Jean Delvare <khali@linux-fr.org>
The Alchemy platform code registers the SMBus device using the virtual address of its registers instead of the physical one -- fix this, taking into account that actually the whole megabyte is decoded by any of the programmable serial controllers (one of which is SMBus), and that all the Alchemy peripherals are directly mappable into KSEG1 kernel space and therefore ioremap() call would just boil down to CKSEG1ADDR() invocation. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
As the old driver_name/type matching scheme is going away soon, change the dummy device mechanism to use the new matching scheme. This has the downside that dummy i2c clients can no longer choose their name, they'll all appear as "dummy" in sysfs and in log messages. I don't think it is a problem in practice though, as there is little reason to use these i2c clients to log messages. Signed-off-by: Jean Delvare <khali@linux-fr.org>
The i2c_sibyte_add_bus() function is not called, nor meant to, from outside, so mark it as static; fixing a sparse warning too. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Jean Delvare <khali@linux-fr.org>
The frequency may have been once hardcoded to 100 kHz, but currently it is passed as an argument to i2c_sibyte_add_bus(), so update the comment to match code. While at it, reformat a nearby comment for consistency. No functional changes. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Jean Delvare <khali@linux-fr.org>
We had a report that running sensors-detect on a Sapphire AM2RD790 motherbord killed the CPU. While the exact cause is still unknown, I'd rather play it safe and prevent any access to the SMBus on that machine by not letting the i2c-piix4 driver attach to the SMBus host device on that machine. Also blacklist a similar board made by DFI. Signed-off-by: Jean Delvare <khali@linux-fr.org>
Per the PIIX4 errata, there maybe a delay between setting the start bit in the Smbus Host Controller Register and the transaction actually starting. If the driver doesn't delay long enough, it may appear that the transaction is complete when actually it hasn't started, this may lead to bus collisions. While 1 ms appears to be enough for most chips, the ServerWorks CSB5 wants 2 ms. Signed-off-by: David Milburn <dmilburn@redhat.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>