An error occurred fetching the project authors.
- 18 Sep, 2015 1 commit
-
-
Masanari Iida authored
This patch fix spelling typos in Documentation/misc-devices. Signed-off-by:
Masanari Iida <standby24x7@gmail.com> Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
- 04 Oct, 2009 2 commits
-
-
Jean Delvare authored
There is no point in implementing a detect callback for the MAX6875, as this device can't be detected. It was there solely to handle "force" module parameters to instantiate devices, but now we have a better sysfs interface that can do the same. So we can get rid of the ugly module parameters and the detect callback. This basically divides the binary module size by 2. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Acked-by:
Wolfram Sang <w.sang@pengutronix.de> Acked-by:
Ben Gardner <gardner.ben@gmail.com>
-
Jean Delvare authored
Some times ago the eeprom and max6875 drivers moved to drivers/misc/eeprom, but their documentation did not follow. It's finally time to get rid of Documentation/i2c/chips. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Cc: Ben Gardner <gardner.ben@gmail.com> Acked-by:
Wolfram Sang <w.sang@pengutronix.de>
-
- 16 Jul, 2008 1 commit
-
-
Jean Delvare authored
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:
Jean Delvare <khali@linux-fr.org>
-
- 12 Jul, 2007 1 commit
-
-
Jean Delvare authored
Let the drivers specify how many bytes they want to read with i2c_smbus_read_i2c_block_data(). So far, the block count was hard-coded to I2C_SMBUS_BLOCK_MAX (32), which did not make much sense. Many driver authors complained about this before, and I believe it's about time to fix it. Right now, authors have to do technically stupid things, such as individual byte reads or full-fledged I2C messaging, to work around the problem. We do not want to encourage that. I even found that some bus drivers (e.g. i2c-amd8111) already implemented I2C block read the "right" way, that is, they didn't follow the old, broken standard. The fact that it was never noticed before just shows how little i2c_smbus_read_i2c_block_data() was used, which isn't that surprising given how broken its prototype was so far. There are some obvious compatiblity considerations: * This changes the i2c_smbus_read_i2c_block_data() prototype. Users outside the kernel tree will notice at compilation time, and will have to update their code. * User-space has access to i2c_smbus_xfer() directly using i2c-dev, so the changed expectations would affect tools such as i2cdump. In order to preserve binary compatibility, we give I2C_SMBUS_I2C_BLOCK_DATA a new numeric value, and define I2C_SMBUS_I2C_BLOCK_BROKEN with the old numeric value. When i2c-dev receives a transaction with the old value, it can convert it to the new format on the fly. Signed-off-by:
Jean Delvare <khali@linux-fr.org>
-
- 05 Sep, 2005 2 commits
-
-
bgardner@wabtec.com authored
Fix a spelling error and change a sysfs name. Signed-off-by:
Ben Gardner <bgardner@wabtec.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
bgardner@wabtec.com authored
Updates to the max6875 driver documentation. This brings the documentation in sync with the code, which was recently simplified. This patch is based off 2.6.13-rc2-mm2. Signed-off-by:
Ben Gardner <bgardner@wabtec.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
- 11 Jul, 2005 1 commit
-
-
Jean Delvare authored
Here is a proposed documentation update for the new max6875 i2c chip driver. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
- 22 Jun, 2005 1 commit
-
-
BGardner@Wabtec.com authored
This patch adds support for the MAX6875/MAX6874 chips. Signed-off-by:
Ben Gardner <bgardner@wabtec.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-