linux-kernel - Re: [PATCH 1/3] MFD: introduce lpc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100216224947.5c46ff86@hyperion.delvare>
Date:	Tue, 16 Feb 2010 22:49:47 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	David Brownell <david-b@...bell.net>
Cc:	Denis Turischev <denis@...pulab.co.il>,
	LKML <linux-kernel@...r.kernel.org>,
	Samuel Ortiz <sameo@...ux.intel.com>, linux-i2c@...r.kernel.org
Subject: Re: [PATCH 1/3] MFD: introduce lpc_sch for Intel SCH LPC bridge

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.

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

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/