From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Joe Perches <joe@perches.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>, walter harms <wharms@bfs.de>,
Antti Palosaari <crope@iki.fi>,
kernel-janitors@vger.kernel.org, rmallon@gmail.com,
shubhrajyoti@ti.com, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 13/13] drivers/media/tuners/e4000.c: use macros for i2c_msg initialization
Date: Sun, 7 Oct 2012 22:56:39 -0300 [thread overview]
Message-ID: <20121007225639.364a41b4@infradead.org> (raw)
In-Reply-To: <1349646718.15802.16.camel@joe-AO722>
Em Sun, 07 Oct 2012 14:51:58 -0700
Joe Perches <joe@perches.com> escreveu:
> On Sun, 2012-10-07 at 23:43 +0200, Julia Lawall wrote:
> > On Sun, 7 Oct 2012, Joe Perches wrote:
> > >> Are READ and WRITE the action names? They are really the important
> > >> information in this case.
> > >
> > > Yes, most (all?) uses of _READ and _WRITE macros actually
> > > perform some I/O.
> >
> > I2C_MSG_READ_DATA?
> > I2C_MSG_READ_INFO?
> > I2C_MSG_READ_INIT?
> > I2C_MSG_PREPARE_READ?
>
> Dunno, naming is hard. Maybe:
>
> I2C_INPUT_MSG
> I2C_OUTPUT_MSG
> I2C_OP_MSG
READ/WRITE sounds better, IMHO, as it will generally match with the
function names (they're generally named like foo_i2c_read or foo_reg_read).
I think none of them uses input or output. Btw, with I2C buses, a
register read is coded as a write ops, that sets the register's sub-address,
followed by a read ops from that (and subsequent) registers.
I'm afraid that using INPUT/OUTPUT will sound confusing.
So, IMHO, I2C_READ_MSG and I2C_WRITE_MSG sounds better.
Btw, as the WRITE + READ operation is very common (I think it is
much more common than a simple READ msg), it could make sense to have
just one macro for it, like:
INIT_I2C_READ_SUBADDR() that would take both write and read values.
I also don't like the I2C_MSG_OP. The operations there are always
read or write.
So, IMHO, the better would be to code the read and write message init message
as something similar to:
#define DECLARE_I2C_MSG_READ(_msg, _addr, _buf, _len, _flags) \
struct i2c_msg _msg[1] = { \
{.addr = _addr, .buf = _buf, .len = _len, .flags = (_flags) | I2C_M_RD } \
}
#define DECLARE_I2C_MSG_WRITE(_msg, _addr, _buf, _len, _flags) \
struct i2c_msg _msg[1] = { \
{.addr = _addr, .buf = _buf, .len = _len, .flags = (_flags) & ~I2C_M_RD } \
}
#define DECLARE_I2C_MSG_READ_SUBADDR(_msg, _addr, _subaddr, _sublen,_subflags, _buf,_len, _flags) \
struct i2c_msg _msg[2] = { \
{.addr = _addr, .buf = _subbuf, .len = _sublen, .flags = (_subflags) & ~I2C_M_RD } \
{.addr = _addr, .buf = _buf, .len = _len, .flags = (_flags) | I2C_M_RD } \
}
Notes:
1) in the case of DECLARE_I2C_MSG_READ_SUBADDR(), I'm almost sure that, in all cases, the
first message will always have buffer size equal to 1. If so, you can simplify the number
of arguments there.
2) It could make sense to have, in fact, two versions for each, one with _FLAGS and another one
without. On most cases, the one without flags are used.
3) I bet that most of the cases where 2 messages are used, the first message has length equal
to one, and it uses a fixed u8 constant with the I2C sub-address. So, maybe it would be nice
to have a variant for this case.
Cheers,
Mauro
next prev parent reply other threads:[~2012-10-08 1:57 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-07 15:38 [PATCH 0/11] introduce macros for i2c_msg initialization Julia Lawall
2012-10-07 15:38 ` [PATCH 13/13] drivers/media/tuners/e4000.c: use " Julia Lawall
2012-10-07 16:33 ` walter harms
2012-10-07 16:44 ` Julia Lawall
2012-10-07 17:13 ` walter harms
2012-10-07 17:18 ` Julia Lawall
2012-10-07 18:16 ` Joe Perches
2012-10-07 18:56 ` Julia Lawall
2012-10-07 21:39 ` Joe Perches
2012-10-07 21:43 ` Julia Lawall
2012-10-07 21:51 ` Joe Perches
2012-10-08 1:56 ` Mauro Carvalho Chehab [this message]
2012-10-08 2:11 ` Ryan Mallon
2012-10-08 7:54 ` Antti Palosaari
2012-10-08 8:31 ` Julia Lawall
2012-10-09 23:32 ` Mauro Carvalho Chehab
2012-10-11 6:45 ` Julia Lawall
2012-12-18 11:46 ` Jean Delvare
2012-12-18 12:36 ` Julia Lawall
2012-12-18 13:13 ` Wolfram Sang
2012-10-09 23:50 ` Mauro Carvalho Chehab
2012-10-08 5:04 ` Julia Lawall
2012-10-07 21:49 ` Ryan Mallon
2012-10-07 21:52 ` Ryan Mallon
2012-10-07 15:38 ` [PATCH 2/13] drivers/media/tuners/mxl5007t.c: " Julia Lawall
2012-10-09 12:30 ` Jean Delvare
2012-10-09 12:50 ` Julia Lawall
2012-10-07 15:38 ` [PATCH 3/13] drivers/media/tuners/qt1010.c: " Julia Lawall
2012-10-07 21:55 ` Ryan Mallon
2012-10-08 5:05 ` Julia Lawall
2012-10-08 5:13 ` Ryan Mallon
2012-10-08 5:24 ` Julia Lawall
2012-10-09 12:12 ` Jean Delvare
2012-10-09 12:51 ` Julia Lawall
2012-10-07 15:38 ` [PATCH 4/13] drivers/media/tuners/tda18212.c: " Julia Lawall
2012-10-07 15:38 ` [PATCH 5/13] drivers/media/tuners: " Julia Lawall
2012-10-07 22:05 ` Ryan Mallon
2012-10-08 5:12 ` Julia Lawall
2012-10-07 15:38 ` [PATCH 6/13] drivers/media/tuners/tda18271-common.c: " Julia Lawall
2012-10-07 15:38 ` [PATCH 7/13] drivers/media/tuners/tua9001.c: " Julia Lawall
2012-10-07 15:38 ` [PATCH 8/13] drivers/media/tuners/fc2580.c: " Julia Lawall
2012-10-07 15:38 ` [PATCH 9/13] drivers/media/tuners/fc0011.c: " Julia Lawall
2012-10-07 16:43 ` walter harms
2012-10-07 16:50 ` Julia Lawall
2012-10-07 16:54 ` walter harms
2012-10-07 18:05 ` Michael Büsch
2012-10-09 12:06 ` Jean Delvare
2012-10-07 15:38 ` [PATCH 10/13] drivers/media/tuners/tda8290.c: " Julia Lawall
2012-10-07 15:38 ` [PATCH 11/13] drivers/media/tuners/tda18218.c: " Julia Lawall
2012-10-07 15:38 ` [PATCH 12/13] drivers/media/tuners/max2165.c: " Julia Lawall
2012-10-07 22:14 ` Ryan Mallon
2012-10-08 5:13 ` Julia Lawall
2012-10-09 15:32 ` [PATCH 0/11] introduce " Jean Delvare
2012-10-09 15:43 ` Julia Lawall
2012-10-22 9:18 ` Julia Lawall
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=20121007225639.364a41b4@infradead.org \
--to=mchehab@infradead.org \
--cc=crope@iki.fi \
--cc=joe@perches.com \
--cc=julia.lawall@lip6.fr \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=rmallon@gmail.com \
--cc=shubhrajyoti@ti.com \
--cc=wharms@bfs.de \
/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).