linux-kernel - Re: [PATCH] x86/mrst: add SFI platform device parsing code

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:	Wed, 22 Sep 2010 23:04:06 +0100
From:	Alan Cox <alan@...ux.intel.com>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	linux-kernel@...r.kernel.org, x86@...nel.org,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] x86/mrst: add SFI platform device parsing code

> This patch (and SFI in general) seems like entirely the wrong
> approach. You're gratuitously reinventing the wheel, and your
> proposed replacement isn't even round.

SFI is what is implemented on these platforms. SFI is what you get. Now
it's possible the firmware folks may move away from SFI for future
hardware but that remains 

> As Grant says, we already have a defined method for passing this kind
> of information to the kernel. We have well-thought-out bindings for

No we don't. The existing drivers we need don't support it.

> It makes *no* sense to add probe support for your 'special' platform
> devices to drivers which already have (or will need anyway) proper
> device-tree support.

I've not seen any which have device tree support that are being used.

> Seriously, just convert whatever crap you have into a device-tree at
> early boot (or preferably in the bootloader, and *beat* the firmware
> idiots until they provide it natively), and don't pollute the kernel
> any more than you have to with this idiocy.

Thats why its in arch/x86/kernel/mrst.c - an arch private file specific
to the platform which then provides platform data in the format drivers
already use.

It's really quite simple

If drivers expect device tree the mrst.c code can provide device tree -
but in the real world none we care about do so yet. If stuff moves to
device tree then the translation will move that way because its job is
to convert SFI to what the kernel wants.

Right now the kernel wants a mix of private structs and as far as
possible platform_foo() stuff. When that is changes the rest will
follow.

Alan

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