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]
Date:	Fri, 27 Aug 2010 21:06:42 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Arjan van de Ven <arjan@...ux.intel.com>
cc:	Grant Likely <grant.likely@...retlab.ca>,
	Masayuki Ohtak <masa-korg@....okisemi.com>,
	meego-dev@...go.com, LKML <linux-kernel@...r.kernel.org>,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	qi.wang@...el.com, yong.y.wang@...el.com,
	andrew.chih.howe.khor@...el.com, gregkh@...e.de,
	Tomoya MORINAGA <morinaga526@....okisemi.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_SPI driver to 2.6.35

On Fri, 27 Aug 2010, Arjan van de Ven wrote:

> On 8/27/2010 11:53 AM, Thomas Gleixner wrote:
> > B1;2401;0cOn Fri, 27 Aug 2010, Grant Likely wrote:
> >    
> > > [cc'ing Thomas Gleixner and David Woodhouse since this driver needs to
> > > get some data about the platform (to know what spi_devices are
> > > present) and I don't know how that is handled for x86 SoCs.]
> > >      
> > The best way to do all this platform specific configuration is to use
> > device tree. I really don't want to have x86/mach-xyz/board[A-Z]
> > horror, which is unavoidable when we don't get a sensible way to
> > configure the boards. SFI was meant to provide a lightweight ACPI, but
> > now that device tree is generic and more platforms are using it, I
> > really want to standartize on that and forget SFI.
> > 
> > That makes even more sense, as all these AMBA peripherals which are
> > duct-taped to a x86 core can be found in other SoCs with different
> > cores as well.
> >    
> 
> I tentatively agree, but this has to coexist with ACPI, which most of these
> platforms will also have,
> for power management if nothing else.

power management and configuration of SoCs with a lot of configurable
pins and peripherals are two different beasts. power management will
probably not change much between two boards, but the peripherals and
pin configuration makes the big difference and I don't wont to pull
out that information from ACPI. Especially not when we talk about
device drivers which can be shared with other architectures.

Also you dont want to burden BSP developers with getting those ACPI
tables right.

Thanks,

	tglx

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ