Jean Delvare wrote:
On Tue, 16 Feb 2010 11:57:46 -0800, David Brownell wrote:
On Thursday 11 February 2010, Denis Turischev wrote:
Intel Poulsbo (SCH) chipset LPC bridge controller contains several
functions. Creating and MFD driver for the LPC bridge controller allows
Spelling nit: "Creating an" (not and). Keyboard, brain, or edit fault. ;)
simultaneous use of SMBus and GPIO interfaces on the SCH.
This looks like the right way to package such southbridge level
componentry. Maye not just these two interfaces, either.
But ... how does this play with ACPI? The last several Intel
systems I looked at seemed to expect ACPI to manage GPIOs and the
IRQs they may issue. (He wrote, staring at an ICH8-system where
ACPI uses GPIOs to manage several buttons and LEDs.)
It would seem error-prone to ignore that coupling on systems
with ACPI. Linux has enough trouble sorting out issues caused
by buggy AML (ACPI bytecode) without introducing conflicts in
who manages which hardware resource (ACPI vs. operating system).
Might be a good idea to use acpi_check_resource_conflict() or similar
before instantiating the platform devices.
May be it worth to add such resource check directly to mfd_add_device function?
Of course, if ACPI weren't being used to hide such board-specific
details from operating systems, such issues would not exist. But
such hiding is one of the basic goals of ACPI ... annoying.
Don't start me on this :(
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
