lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1210110836030.2010@hadrien>
Date:	Thu, 11 Oct 2012 08:45:43 +0200 (CEST)
From:	Julia Lawall <julia.lawall@...6.fr>
To:	Mauro Carvalho Chehab <mchehab@...radead.org>
cc:	Julia Lawall <julia.lawall@...6.fr>,
	Ryan Mallon <rmallon@...il.com>, Joe Perches <joe@...ches.com>,
	walter harms <wharms@....de>, ben-linux@...ff.org,
	w.sang@...gutronix.de, linux-i2c@...r.kernel.org,
	khali@...ux-fr.org, Antti Palosaari <crope@....fi>,
	kernel-janitors@...r.kernel.org, shubhrajyoti@...com,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 13/13] drivers/media/tuners/e4000.c: use macros for
 i2c_msg initialization

I found 6 cases where there are more than 2 messages in the array.  I
didn't check how many cases where there are two messages but there is
something other than one read and one write.

Perhaps a reasonable option would be to use

I2C_MSG_READ
I2C_MSG_WRITE
I2C_MSG_READ_OP
I2C_MSG_WRITE_OP

The last two are for the few cases where more flags are specified.  As
compared to the original proposal of I2C_MSG_OP, these keep the READ or
WRITE idea in the macro name.  The additional argument to the OP macros
would be or'd with the read or write (nothing to do in this case) flags as
appropriate.

Mauro proposed INIT_I2C_READ_SUBADDR for the very common case where a
message array has one read and one write.  I think that putting one
I2C_MSG_READ and one I2C_MSG_WRITE in this case is readable enough, and
avoids the need to do something special for the cases that don't match the
expectations of INIT_I2C_READ_SUBADDR.

I propose not to do anything for the moment either for sizes or for
message or buffer arrays that contain only one element.

julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ