From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Alan Cox <alan@linux.intel.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Grant Likely <grant.likely@secretlab.ca>,
linux-kernel@vger.kernel.org, x86@kernel.org,
David Woodhouse <dwmw2@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] x86/mrst: add SFI platform device parsing code
Date: Thu, 23 Sep 2010 15:46:07 +0100 [thread overview]
Message-ID: <20100923144606.GH25663@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <20100923142720.13bf9d69@linux.intel.com>
On Thu, Sep 23, 2010 at 02:27:20PM +0100, Alan Cox wrote:
> > What is it about this platform that is going to restrict the problem?
> The sort of people who will be using it and how,
Can you be more specific? This is the same sort of thing people
normally say but the experience is that it rarely survives a successful
product.
> > Code which makes this sort of assumption about knowing the platforms
> > that the device will be deployed on well is relatively common but the
> > usual result is that OEMs want to change the reference platforms and
> > the assumptions that the code has been making about the systems and
> > about how people will work with the code break down.
> There are non reference platforms in existence without the problem you
> envisage having occurred. So I think we'll worry about it if it happens
> but knowing that with DMI we have the tools to deal with this.
It doesn't break down immediately; a combination of volume and the next
generation product coming along and grabbing attention is usually what
causes things to break down. However, if you're totally confident that
all the BIOS authors at the OEMs are going to work well together here
then I guess it's only Moorestown that's affected.
next prev parent reply other threads:[~2010-09-23 14:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-20 14:01 [PATCH] x86/mrst: add SFI platform device parsing code Alan Cox
2010-09-20 15:04 ` Mark Brown
2010-09-20 14:27 ` Alan Cox
2010-09-20 15:27 ` Mark Brown
2010-09-22 4:03 ` Grant Likely
2010-09-22 15:22 ` David Woodhouse
2010-09-22 15:33 ` Mark Brown
2010-09-22 15:35 ` David Woodhouse
2010-09-22 15:39 ` Mark Brown
2010-09-22 22:04 ` Alan Cox
2010-09-22 22:15 ` Alan Cox
2010-09-23 6:07 ` Grant Likely
2010-09-23 9:54 ` Mark Brown
2010-09-23 10:27 ` Alan Cox
2010-09-23 10:27 ` Mark Brown
2010-09-23 10:58 ` Alan Cox
2010-09-23 10:52 ` Mark Brown
2010-09-23 10:13 ` Alan Cox
2010-09-23 14:11 ` Mark Brown
2010-09-23 13:27 ` Alan Cox
2010-09-23 14:46 ` Mark Brown [this message]
2010-09-23 15:55 ` Alan Cox
2010-09-23 10:48 ` Alan Cox
2010-09-23 10:54 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100923144606.GH25663@rakim.wolfsonmicro.main \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alan@linux.intel.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dwmw2@infradead.org \
--cc=grant.likely@secretlab.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox