summaryrefslogtreecommitdiffstats
path: root/Documentation/i2c/i2c-stub (follow)
Commit message (Collapse)AuthorAgeFilesLines
* docs: i2c: convert to ReST and add to driver-api booksetMauro Carvalho Chehab2019-07-311-64/+0
| | | | | | | | | | | Convert each file at I2C subsystem, renaming them to .rst and adding to the driver-api book. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Acked-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
* i2c: stub: Add support for banked register rangesJean Delvare2014-07-171-4/+7
| | | | | | | | | | | | | Some chips implement banked register ranges. This allows implementing more registers than the limited 8-bit address space originally allows. In order to access a register on these chips, you must first select the proper bank. Add support for this mechanism to the i2c-stub driver so that such chips can be emulated. All the bank settings are passed as module parameters. Signed-off-by: Jean Delvare <jdelvare@suse.de> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: stub: Add support for SMBus block commandsGuenter Roeck2014-07-171-2/+10
| | | | | | | | | | | | | | | | SMBus block commands are different to I2C block commands since the returned data is not normally accessible with byte or word commands on other command offsets. Add linked list of 'block' commands to support those commands. Access mechanism is quite simple: Block commands must be written before they can be read. Subsequent writes can be partial. Block read commands always return the number of bytes associated with the longest previous write. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c-stub: Documentation updateJean Delvare2009-12-061-2/+2
| | | | | | There is nothing sensors-specific to i2c-stub. Signed-off-by: Jean Delvare <khali@linux-fr.org>
* i2c-stub: Allow user to disable some commandsJean Delvare2009-12-061-0/+6
| | | | | | | | Add a module parameter to override the functionality bitfield. This lets the user disable some commands. This can be used to force a chip driver to take different code paths. Signed-off-by: Jean Delvare <khali@linux-fr.org>
* i2c-stub: Implement I2C block supportJean Delvare2009-12-061-3/+3
| | | | | | This is required to test some drivers, for example at24. Signed-off-by: Jean Delvare <khali@linux-fr.org>
* i2c-stub: Use a single array for byte and word operationsJean Delvare2008-01-271-3/+0
| | | | | | | This mimics the behavior of actual SMBus chips better. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Mark M. Hoffman <mhoffman@lightlink.com>
* i2c-stub: Mention the existence of an helper scriptJean Delvare2008-01-271-0/+3
| | | | | | | There's a new script named i2c-stub-from-dump that can be very helpful when working with the i2c-stub driver. Signed-off-by: Jean Delvare <khali@linux-fr.org>
* i2c-stub: Support multiple chipsJean Delvare2007-10-131-10/+8
| | | | | | | | | Add support for multiple chips to i2c-stub. I've changed the memory allocation scheme from static to dynamic, so that we don't waste too much memory. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Mark M. Hoffman <mhoffman@lightlink.com>
* i2c-stub: Chip address as a module parameterJean Delvare2006-09-271-2/+13
| | | | | | | | | | | | | | | i2c-stub: Chip address as a module parameter Add a mandatory chip_addr parameter to i2c-stub. This parameter defines to which chip address the driver will respond, instead of reponding to all addresses as before. The idea is to prevent the users from loading i2c-stub at random and being then confused by the results of sensors-detect or other user-space tools. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-171-0/+38
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!