There is nothing sensors-specific to i2c-stub.

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

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>

This is required to test some drivers, for example at24.

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

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>

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>

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 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>

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!