From: Artem Bityutskiy <dedekind1@gmail.com>
To: Amul Kumar Saha <amul.saha@samsung.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
Kyungmin Park <kmpark@infradead.org>,
linux-mtd@lists.infradead.org
Subject: Re: [PATCH] [OneNAND] OTP support re-implementation 1/1
Date: Thu, 03 Sep 2009 14:19:03 +0300 [thread overview]
Message-ID: <1251976743.5060.13.camel@localhost> (raw)
In-Reply-To: <FC4F021760EA4F649917598723041422@sisodomain.com>
On Thu, 2009-09-03 at 16:07 +0530, Amul Kumar Saha wrote:
> >> >> +
> >> >> +config ONENAND_OTP_AREA_BLOCK0
> >> >> + bool "BOTH OTP area AND Block[0]"
> >> >> + depends on MTD_ONENAND_OTP&& !ONENAND_OTP_AREA&& !ONENAND_OTP_BLOCK0
> >> >> + select ON_OTP_AREA_BLOCK0
> >> >> +
> >> >> +endif #MTD_ONENAND_OTP
> >> >
> >> > If there were 10 OTP blocks, would you add 10 options?
> >> > I mean, are these switches really needed? Can we remove them?
> >>
> >> There is just one OTP block.
> >> Three options are provided for the three known combinations of 1st Block and the OTP Block.
> >> The option to choose one should be provided to the user.
> >
> > Wouldn't it be better to make this run-time configurable? E.g., module
> > parameters? Too many config options are frowned upon usually.
> >
>
> I got it. But I guess in this case the numbers are not that big enough to call for Module parameters
> implementation.
> Is it okay?
IMO, the amount of OneNAND config options is already large, and I would
not introduce more.
With module parameters you may always add kernel boot options like:
onenand.otpblk=0
or something like this.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2009-09-03 11:19 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-17 10:43 [PATCH] [OneNAND] OTP support re-implementation 1/1 Amul Kumar Saha
2009-08-26 5:41 ` Amul Kumar Saha
2009-08-26 5:58 ` Artem Bityutskiy
2009-08-27 6:37 ` Amul Kumar Saha
2009-08-28 13:38 ` Artem Bityutskiy
2009-08-31 9:19 ` Amul Kumar Saha
2009-08-31 9:34 ` Kyungmin Park
2009-09-02 5:55 ` Amul Kumar Saha
2009-09-02 5:59 ` Amul Kumar Saha
2009-09-02 6:10 ` Artem Bityutskiy
2009-09-03 5:51 ` Amul Kumar Saha
2009-09-03 6:10 ` Artem Bityutskiy
2009-09-03 10:37 ` Amul Kumar Saha
2009-09-03 11:19 ` Artem Bityutskiy [this message]
2009-09-07 9:45 ` Amul Kumar Saha
2009-09-07 9:57 ` Kyungmin Park
2009-09-16 3:33 ` Amul Kumar Saha
2009-09-16 6:40 ` Artem Bityutskiy
2009-09-28 9:38 ` Artem Bityutskiy
2009-10-01 6:48 ` Amul Kumar Saha
2009-10-12 4:42 ` Amul Kumar Saha
-- strict thread matches above, loose matches on Subject: below --
2009-10-12 6:01 Amul Kumar Saha
2009-10-20 8:56 ` Artem Bityutskiy
2009-10-20 14:13 ` Adrian Hunter
2009-10-21 11:20 ` Amul Kumar Saha
2009-10-23 6:11 ` Artem Bityutskiy
2009-10-21 11:30 ` Amul Kumar Saha
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=1251976743.5060.13.camel@localhost \
--to=dedekind1@gmail.com \
--cc=amul.saha@samsung.com \
--cc=dwmw2@infradead.org \
--cc=kmpark@infradead.org \
--cc=linux-mtd@lists.infradead.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