From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Charles Manning <manningc2@actrix.gen.nz>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
ryan@bluewatersys.com, akpm@linux-foundation.org
Subject: Re: [PATCH 0/10] Add yaffs2 file system: Fifth patchset
Date: Thu, 17 Feb 2011 06:08:02 +0000 [thread overview]
Message-ID: <20110217060800.GA9645@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <201102171722.15683.manningc2@actrix.gen.nz>
On Thu, Feb 17, 2011 at 05:22:15PM +1300, Charles Manning wrote:
> On Thursday 17 February 2011 16:49:14 Mark Brown wrote:
> > You're missing the use case here - I'm talking about the situation where
> > you completely ignore the vendor BSP and go direct to mainline without
> > reference to the vendor provided stuff. The user may not even have the
> > vendor provided BSP to look at.
> I don't understand what problem you are trying to illustrate.
> First off, kernel BSPs should always be available in accordance with the GPL.
Sure, but the effort involved in obtaining them (especially for older
boards) often greatly exceeds the value of looking at them - often it's
much easier to go direct to mainline.
> Secondly the defaults work for just about every case. So long as the mtd has
> been set up then dropping in yaffs using defaults is generally pretty
> straight forward and there is no tuning required,
> Some tuning is required if the mtd does not pass through all the info that is
> required. In the fullness of time I would expect that this info would be
> provided by mtd.
Your descriptions made it sound like tthis was higher level information
that was being provided. If it's just fixups to the flash description
then I would expect that the flash driver would handle it as you suggest.
> My point was that the "platform data" -- well just about all of it -- is
> exposed via the mtd interface. That tells you the number of blocks, block
> size, bytes per block etc. Enough to figure out almost all the runtime stuff.
Right, which is why I'm assuming that this build time configuration
stuff is things that can't be read directly from the hardware and needs
to be passed in via some other mechanism. If it's stuff that can be
read from the MTD subsystem then clearly it should be read from the MTD
subsystem.
> I think I can dump all the config stuff and just set it to the most useful
> defaults. Many of the settings are really only there for debug etc.
That sounds like a good plan.
next prev parent reply other threads:[~2011-02-17 6:08 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-09 3:25 [PATCH 0/10] Add yaffs2 file system: Fifth patchset Charles Manning
2011-02-09 3:25 ` [PATCH 01/10] Add yaffs2 file system: allocators, bitmap and block handling Charles Manning
2011-02-09 3:26 ` [PATCH 02/10] Add yaffs2 file system: attrib and xattrib handling Charles Manning
2011-02-09 22:33 ` Ryan Mallon
2011-02-09 3:26 ` [PATCH 03/10] Add yaffs2 file system: checkpoint streaming Charles Manning
2011-02-10 22:27 ` Jesper Juhl
2011-02-10 22:44 ` Ryan Mallon
2011-02-10 22:50 ` Charles Manning
2011-02-09 3:26 ` [PATCH 04/10] Add yaffs2 file system: flash interface and ecc handling Charles Manning
2011-02-09 3:26 ` [PATCH 05/10] Add yaffs2 file system: tags handling Charles Manning
2011-02-09 3:26 ` [PATCH 06/10] Add yaffs2 file system: tracing and verification handling Charles Manning
2011-02-11 23:01 ` Ryan Mallon
2011-02-09 3:26 ` [PATCH 07/10] Add yaffs2 file system: yaffs1 and yaffs2 mode handling Charles Manning
2011-02-09 3:26 ` [PATCH 08/10] Add yaffs2 file system: core guts code Charles Manning
2011-02-10 2:27 ` Ryan Mallon
2011-02-09 3:26 ` [PATCH 09/10] Add yaffs2 file system: Linux glue code Charles Manning
2011-02-10 22:07 ` Ryan Mallon
2011-02-10 22:47 ` Charles Manning
2011-02-17 22:24 ` Ryan Mallon
2011-02-09 3:26 ` [PATCH 10/10] Add yaffs2 file system: hok in to Linux tree Charles Manning
2011-02-09 4:52 ` [PATCH 0/10] Add yaffs2 file system: Fifth patchset Christoph Hellwig
2011-02-09 18:22 ` Charles Manning
2011-02-16 8:04 ` Christoph Hellwig
2011-02-16 22:12 ` Charles Manning
2011-02-17 1:48 ` Mark Brown
2011-02-17 2:31 ` Charles Manning
2011-02-17 2:52 ` Ryan Mallon
2011-02-17 3:49 ` Charles Manning
2011-02-17 23:41 ` Greg KH
2011-02-18 0:01 ` Mark Brown
2011-02-18 0:33 ` Greg KH
2011-02-18 0:43 ` Mark Brown
2011-02-18 0:55 ` Ryan Mallon
2011-02-18 0:58 ` Greg KH
2011-02-20 17:25 ` Charles Manning
2011-02-20 20:07 ` Greg KH
2011-02-20 20:52 ` Ryan Mallon
2011-02-20 22:29 ` Greg KH
2011-02-20 22:57 ` Ryan Mallon
2011-02-18 1:08 ` Mark Brown
2011-02-17 3:49 ` Mark Brown
2011-02-17 4:22 ` Charles Manning
2011-02-17 6:08 ` Mark Brown [this message]
2011-02-19 17:45 ` Pavel Machek
2011-08-17 12:12 ` Linus Walleij
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=20110217060800.GA9645@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manningc2@actrix.gen.nz \
--cc=ryan@bluewatersys.com \
/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;
as well as URLs for NNTP newsgroup(s).