From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: Peter Korsgaard <jacmet@sunsite.dk>
Cc: "U-Boot Version 2 (barebox)" <barebox@lists.infradead.org>
Subject: Re: [PATCH] commands: Remove reference to non-existent CONFIG_CMD_I2C.
Date: Mon, 21 Dec 2009 06:47:48 -0500 (EST) [thread overview]
Message-ID: <alpine.LFD.2.00.0912210643010.14007@localhost> (raw)
In-Reply-To: <87hbrkzh9w.fsf@macbook.be.48ers.dk>
On Mon, 21 Dec 2009, Peter Korsgaard wrote:
> >>>>> "Sascha" == Sascha Hauer <s.hauer@pengutronix.de> writes:
>
> Sascha> Ok, applied.
>
> Sascha> Is a i2c command really useful? For I2C eeproms you would
> Sascha> create an epprom driver which creates a file under /dev/ which
> Sascha> you can then access using the usual mm/mw commands. Maybe an
> Sascha> i2c command could be useful to register a new device on an I2C
> Sascha> bus.
>
> I could see basic I2C access being useful for debugging (of
> non-eeprom devices).
i was imagining the same thing, but since there's no such support at
the moment, there's little value in leaving that config variable
there.
just to be clear, i'm a big fan of adding new functionality all at
once, in one logical patch. when i run my scanning scripts on the
linux kernel, i frequently get *numerous* hits on undefined or
unreferences CONFIG_ variables, which turn out to be because someone
has *partially* added a feature but it's not complete, so you have
mysterious code or variables that no one else seems to reference, with
people saying, "oh, yeah, i'm getting to that, i'll be adding some
code to hook up with that shortly and finish it off."
personally, i'd rather that didn't happen, just because it's easier
to track paches if they're logically complete and coherent. in short,
when the time comes to add an "i2c" command, we can put everything
back in in one patch. sound reasonable?
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2009-12-21 11:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-21 11:17 Robert P. J. Day
2009-12-21 11:30 ` Sascha Hauer
2009-12-21 11:33 ` Robert P. J. Day
2009-12-21 11:40 ` Peter Korsgaard
2009-12-21 11:47 ` Robert P. J. Day [this message]
2009-12-21 11:54 ` Peter Korsgaard
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=alpine.LFD.2.00.0912210643010.14007@localhost \
--to=rpjday@crashcourse.ca \
--cc=barebox@lists.infradead.org \
--cc=jacmet@sunsite.dk \
/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