ichx_gpio_check_available() returns either 0 or -ENXIO depending on whether
the given GPIO is available or not. However, callers of this function treat
the return value as boolean:

	...
	if (!ichx_gpio_check_available(gpio, nr))
		return -ENXIO;

which erroneusly fails when the GPIO is available and not vice versa.

Fix this by making the function return boolean as expected by the callers.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

As reported by CONFIG_DEBUG_SPINLOCK=y.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NPeter Tyser <ptyser@xes-inc.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Cc: Grant Likely <grant.likely@secretlab.ca>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: Peter Tyser <ptyser@xes-inc.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Peter Tyser <ptyser@xes-inc.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Peter Tyser <ptyser@xes-inc.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The ICH chips have their GPIO pins organized in 2 or 3 independent
groups of 32 GPIO pins. It can happen that the ACPI BIOS wants to make
use of pins in one group, preventing the OS to access these. This does
not prevent the OS from accessing the other group(s).

This is the case for example on my Asus Z8NA-D6 board. The ACPI BIOS
wants to control GPIO 18 (group 1), while I (the OS) need to control
GPIO 52 and 53 (group 2) for SMBus multiplexing.

So instead of checking for ACPI resource conflict on the whole I/O
range, check on a per-group basis, and consider it a success if at
least one of the groups is available for the OS to use.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Peter Tyser <ptyser@xes-inc.com>
Cc: Aaron Sierra <asierra@xes-inc.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

This driver works on many Intel chipsets, including the ICH6, ICH7,
ICH8, ICH9, ICH10, 3100, Series 5/3400 (Ibex Peak), Series 6/C200
(Cougar Point), and NM10 (Tiger Point).

Additional Intel chipsets should be easily supported if needed, eg the
ICH1-5, EP80579, etc.

Tested on QM67 (Cougar Point), QM57 (Ibex Peak), 3100 (Whitmore Lake),
and NM10 (Tiger Point).

Includes work from Jean Delvare:
        - Resource leak removal during module load/unload
        - GPIO API bit value enforcement

Also includes code cleanup from Guenter Roeck and Grant Likely.
Signed-off-by: NPeter Tyser <ptyser@xes-inc.com>
Signed-off-by: NAaron Sierra <asierra@xes-inc.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>