linux-kernel - Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH

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 13:20:21 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	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, arjan@...ux.intel.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, Aug 27, 2010 at 12:53 PM, Thomas Gleixner <tglx@...utronix.de> 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.

I knew you were going to say that!  :-)

Ohtak-san, for this patch I'd like you to drop the separate driver
that only registers the spi_devices and just submit the core driver.
(You can of course keep the spi_device registration in your own tree
for debug purposes).  I'll expect that the device will get
instantiated using a device tree to determine which spi_devices are
present.  The parsing of spi device tree data will be moving into the
core spi subsystem code in the next merge window most likely, so it
can all be handled transparently.

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

Indeed.  BTW, Ohtak-san, is this spi bus device something brand new,
or is it derived from an existing spi device?

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