From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hans de Goede <hdegoede@redhat.com>
Date: Sun, 28 Dec 2014 11:55:23 +0100
Subject: [U-Boot] [PATCH 05/17] sunxi: video: Improve monitor video-mode
 option handling
In-Reply-To: <1419759605.13595.45.camel@hellion.org.uk>
References: <1419447989-21959-1-git-send-email-hdegoede@redhat.com>	
	<1419447989-21959-6-git-send-email-hdegoede@redhat.com>
	<1419759605.13595.45.camel@hellion.org.uk>
Message-ID: <549FE19B.1000005@redhat.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi,

On 28-12-14 10:40, Ian Campbell wrote:
> On Wed, 2014-12-24 at 20:06 +0100, Hans de Goede wrote:
>
>> +enum sunxi_monitor {
>> +	sunxi_monitor_none,
>> +	sunxi_monitor_dvi,
>> +	sunxi_monitor_hdmi,
>> +	sunxi_monitor_lcd,
>> +	sunxi_monitor_vga,
>> +};
> [...]
>> +	const char *mon_desc[] = { "none", "dvi", "hdmi", "lcd", "vga" };
>
> These risk getting out of sync. I half expect the array will be punted
> by the compiler into static storage anyway, so you could just make it a
> global up near the enum (and perhaps use the [sunxi_monitor_none] =
> "none" initialiser style).
>
> Another option (which I think I prefer) would be a get_mon_desc helper
> with a switch in it over the enum, returning the const char *. Then the
> compiler will (hopefully) complain if a new enum is added without a
> corresponding description.

Yeah the compiler will complain then. I've gone with your suggestion
to add a get_mon_desc helper, note that I did need to also add a
SUNXI_MONITOR_LAST define to use in the loop to compare the user provided
string with the get_mon_desc strings. I've put this directly under the enum
to make it hard to overlook and skip it when updating the enum.

Regards,

Hans