Scanning the BIOS memory for the apanel information is costly, so
avoid doing it on non-Fujitsu machines.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

I don't know if Fujitsu is ever going to produce Patsburg-based
machines, but if they do, I'd rather not probe the secondary (IDF)
SMBus channels. At least not until we have a good reason for doing so.

On a side note, I'm not even sure if it is right to enable detection
of HWMON and DDC devices on the IDF channels. Time will tell...
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch adds the SMBus controller DeviceID for the Intel Panther Point PCH.
Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Move the SMBus device ID definitions of recent devices from pci_ids.h
to the i2c-i801.c driver file. They don't have to be shared, as they
are clearly identified and only used in this driver. In the future,
such IDs will go to i2c-i801 directly. This will make adding support
for new devices much faster and easier, as it will avoid cross-
subsystem patch sets and merge conflicts.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Seth Heasley <seth.heasley@intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

Add the SMBus Controller DeviceIDs for the Intel DH89xxCC PCH.
Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Commit 5a0e3ad6 added direct inclusion
of <linux/slab.h> to those source files that appeared to need it, but
somehow missed this.  On most architectures <linux/slab.h> is still
indirectly included, but there are exceptions such as alpha.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

These are the extra 'Integrated Device Function' SMBus controllers found
on the Patsburg chipset. Mention the absence of slave mode support.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

It's poor form to keep driver state in global variables rather than
per-instance. It never really mattered in practice when there was only
one controller on the chipset, but the latest chipsets do have more
than one controller, so now we care.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Add support for the Intel Patsburg PCH SMBus Controller.
Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

This patch updates the defines for Intel devices in
include/linux/pci_ids.h, referenced in arch/x86/pci/irq.c and
drivers/i2c/busses/i2c-i801.c, reflecting approved legal branding, and
using fuller code-names for products under development.
Acked-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Fujitsu slightly changed the DMI strings in their recent machines,
(for example the D2778) and this breaks the automatic loading of the
needed fschmd driver. Being more tolerant on string comparison fixes
the issue.

This closes bug #15634:
https://bugzilla.kernel.org/show_bug.cgi?id=15634Signed-off-by: NJean Delvare <khali@linux-fr.org>
Tested-by: NSergey Spiridonov <sena@hurd.homeunix.org>
Cc: Hans de Goede <hdegoede@redhat.com>

Fix all checkpatch warnings. No functional changes are made.
Signed-off-by: NIvo Manca <pinkel@gmail.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Only the oldest devices lack some of the features supported by this
driver. List them explicitly, and default to all features enabled for
all other chips, including the ones added through sysfs. This will
make future driver maintenance easier.

In the unlikely event of a not yet supported device not implementing
all the features, one can always use the disable_features module
parameter to prevent the driver from attempting to use them.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NSeth Heasley <seth.heasley@intel.com>

Let the user disable selected features normally supported by the
device. This makes it possible to work around possible driver or
hardware bugs if the feature in question doesn't work as intended
for whatever reason.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Felix Rubinstein <felixru@gmail.com>

Experience has shown that the block buffer can only be used for SMBus
(not I2C) block transactions, even though the datasheet doesn't
mention this limitation.
Reported-by: NFelix Rubinstein <felixru@gmail.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Oleg Ryjkov <oryjkov@gmail.com>
Cc: stable@kernel.org

Add the Intel Cougar Point (PCH) SMBus controller device IDs.
Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The id_table field of the struct pci_driver is constant in <linux/pci.h>
so it is worth to make initialization data also constant.

The semantic match that finds this kind of pattern is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
disable decl_init,const_decl_init;
identifier I1, I2, x;
@@
	struct I1 {
	  ...
	  const struct I2 *x;
	  ...
	};
@s@
identifier r.I1, y;
identifier r.x, E;
@@
	struct I1 y = {
	  .x = E,
	};
@c@
identifier r.I2;
identifier s.E;
@@
	const struct I2 E[] = ... ;
@depends on !c@
identifier r.I2;
identifier s.E;
@@
+	const
	struct I2 E[] = ...;
// </smpl>
Signed-off-by: NMárton Németh <nm127@freemail.hu>
Cc: Julia Lawall <julia@diku.dk>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The Intel 82801 is sometimes used on systems with a BMC connected. The
BMC can access the SMBus, resulting in lost arbitration for the 82801.
We should let i2c-core retry transactions for us in this case.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

When an ACPI resource conflict is detected, error messages are already
printed by ACPI. There's no point in causing the driver core to print
more error messages, so return one of the error codes for which no
message is printed.

This fixes bug #14293:
http://bugzilla.kernel.org/show_bug.cgi?id=14293Signed-off-by: NJean 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: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Detect various FSC hwmon IC's based on DMI tables and then let
the i2c-i801 driver instantiate the i2c client devices. Note that
some of the info in the added table is indentical for all rows, still
this is kept in the table to keep the code general and thus (hopefully)
easily extensible in the future.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

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

Convert the apanel driver to the new i2c device driver binding model,
as the legacy model is going away soon. In the new model, the apanel
driver is no longer scanning all the i2c adapters, instead the
relevant bus driver (i2c-i801) is instantiating the device as needed.

One side benefit is that the apanel driver will now load automatically
on all systems where it is needed.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>

Adds the Intel Ibex Peak (PCH) SMBus Controller Device IDs.
Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

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

Check for ACPI resource conflicts in i2c bus drivers. I've included
all recent SMBus master drivers for PC hardware.

I've voluntarily left out:
* Drivers that don't run on PCs: they can't conflict with ACPI.
* Bit-banged bus device drivers: it's very unlikely that ACPI would
  deal with such buses.
Signed-off-by: NJean Delvare <jdelvare@suse.de>

Move the check of pre-transaction and post-transaction conditions to
separate functions, and adjust them a bit. Having dedicated functions
for that ensures that errors are handled in a consistent way.

Bit HOST_BUSY of the status register is read-only, so writing to it is
certainly not going to clear it. If this bit is set then we simply
don't want to start the transaction, as it means that somebody else
(ACPI, SMM?) is already using the controller.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

"temp" isn't a terribly well chosen name for a local variable.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Bit BUS_ERR of the status register means that the ICH host controller
lost the arbitration. Report this event as such.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Dumping the register values before and after every transaction was
useful during driver development but now it's only spamming the log.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Let general purpose I2C/SMBus bus drivers add SPD to their class. Once
this is done, we will be able to tell the eeprom driver to only probe
for SPD EEPROMs and similar on these buses.

Note that I took a conservative approach here, adding I2C_CLASS_SPD to
many drivers that have no idea whether they can host SPD EEPROMs or not.
This is to make sure that the eeprom driver doesn't stop probing buses
where SPD EEPROMs or equivalent live.

So, bus driver maintainers and users should feel free to remove the SPD
class from drivers those buses never have SPD EEPROMs or they don't
want the eeprom driver to bind to them. Likewise, feel free to add the
SPD class to any bus driver I might have missed.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Many PC SMBus host controller drivers don't properly handle the case
where they are requested to achieve a transaction they do not support.
Update them so that the consistently print a warning message and
return a single error value in this case.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Tighten error paths used by various i2c adapters (mostly x86) so
they return real fault/errno codes instead of a "-1" (which is
most often interpreted as "-EPERM").  Build tested, with eyeball
review.

One minor initial goal is to have adapters consistently return
the code "-ENXIO" when addressing a device doesn't get an ACK
response, at least in the probe paths where they are already
good at stifling related logspam.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Add the Intel ICH10 SMBus Controller DeviceID's and updates
Tolapai support.
Signed-off-by: NJason Gaston <jason.d.gaston@intel.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

I2C block read is supported since the ICH5. I couldn't get it to work
using the block buffer, so it's using the old-style byte-by-byte mode
for now.

Note: I'm also updating the driver author... The i2c-i801 driver was
really written by Mark Studebaker, even though he based his work on
the i2c-piix4 driver which was written by Philip Edelbrock.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Clear special mode bits (PEC, block buffer) at driver load time,
you never know in which state the device was left by its last user.

Also make sure that we reset the block buffer mode at the end of every
transaction, not only when PEC was used.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Use separate flags with explicit names to describe the features of
the ICH chip.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Provide a clearer documentation of which additional features each
ICH chip support, and which of these the driver supports.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Rename I2C_FUNC_SMBUS_HWPEC_CALC as I2C_FUNC_SMBUS_PEC, and list that
functionality as always available through the software implementation.
Update documentation accordingly (and list similar requirements).

The way it's currently packaged doesn't present the capability in a
useful way.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NJean Delvare <khali@linux-fr.org>