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

On Thu, Sep 23, 2010 at 03:07:03AM -0300, Grant Likely wrote:

> My point is that an isolated translation layer becomes
> (exponentially?) more difficult to maintain for each additional
> platform that depends on it.  Support must be explicitly added for
> every device that gets attached to a moorestown system in a way that
> cannot be modularized and has the potential to become very large.

It's not just the per-device aspect of it, it's also what happens when
OEMs start placing devices with no upstream defined mappings on their
boards.  Regardless of any specs it seems unlikely that OEMs can be
reliably persuaded to coordinate the creation of new SFI mappings for
these devices with anyone which means that we're likely to end up with
multiple incompatible definitions.  Looking at the code as it is I don't
see any structure in there for handling that - it's assuming that we
know what the platform data for a given device is going to look like.

> From what I've seen tonight, dumping SFI data verbatim into a device
> tree isn't an option because SFI doesn't naturally group device data.
> I withdraw the suggestion.  So, I guess I agree.  There doesn't seem
> to be any way around machine-specific SFI translation code, regardless
> of whether it translates into direct registrations, or into a device
> tree.

One thing that might help here is to put in place the mechanisms for
adding board-specific overrides now (I'm presuming there's board naming
data in the SFI somewhere, I've not looked).  That should hopefully
provide some hints to people and would at least mean we've got something
to hang machine specific workarounds on.

To be honest I'd actually be inclined to go more towards the way the
non-DT embedded platforms have gone and just ignore the data we get
from SFI as much as possible and have board specific initialisation in
code; it's boring and repetitive but it's also clear and *relatively*
robust.

> > If a driver wants device tree the SFI parser would ideally supply it
> > with device tree. If the entire kernel goes device tree I will whoop
> > with joy and make SFI use it.

> :-)

To be honest I suspect we'll have similar issue with or without device
tree.
--
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/