Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/26/2011 3:38 PM, B.J. Buchalter wrote:
Why not do the following:

        #define OMAP_GPIO_REV_0	0
        #define OMAP_GPIO_REV_1	1
        #define OMAP_GPIO_REV_2	2
        #define OMAP_GPIO_REV_3	3
/*
	OMAP_GPIO_REV_0:	OMAP2420
	OMAP_GPIO_REV_1:	OMAP2430
	OMAP_GPIO_REV_2:	OMAP3, DMxxx
	OMAP_GPIO_REV_3:	OMAP4, OMAP5, DM816x
*/

   +	switch (oh->class->rev) {     ## This is auto-generated.
   +	case 0:				## But this is our code.

       I am recommending this to read as:

   +	switch (oh->class->rev) {     ## This is auto-generated.
   +	case OMAP_GPIO_REV_0:		## More readable.

That approach solves both issues -- Revision ->  Chip mapping in comment, no magic numbers in the code, and no implied restriction of the rev number to a specific SoC. Using the defines makes it easier to search the code for a specific revision, since you would no longer get false positives for all the other '0' and '1' constants that appear in the code. It also makes it indexible by tools like LXR.

This is indeed what was done for I2C recently.
The point is that this kind of define does not bring a lot of semantic. But on the other hand it will definitively help the search aspect.

Thanks,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux