From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linux-foundation.org (smtp1.linux-foundation.org [140.211.169.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.linux-foundation.org", Issuer "CA Cert Signing Authority" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 6B03DB7CB6 for ; Tue, 9 Feb 2010 08:05:27 +1100 (EST) Date: Mon, 8 Feb 2010 13:04:55 -0800 From: Andrew Morton To: Anton Vorontsov Subject: Re: [PATCH] leds-gpio: Fix default state handling on OF platforms Message-Id: <20100208130455.8cb90ff1.akpm@linux-foundation.org> In-Reply-To: <20100205205437.GA4733@oksana.dev.rtsoft.ru> References: <20100205205437.GA4733@oksana.dev.rtsoft.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: linuxppc-dev@ozlabs.org, Trent Piepho , linux-kernel@vger.kernel.org, Richard Purdie List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 5 Feb 2010 23:54:37 +0300 Anton Vorontsov wrote: > The driver wrongly sets default state for LEDs that don't specify > default-state property. > > Currently the driver handles default state this way: > > memset(&led, 0, sizeof(led)); > for_each_child_of_node(np, child) { > state = of_get_property(child, "default-state", NULL); > if (state) { > if (!strcmp(state, "keep")) > led.default_state = LEDS_GPIO_DEFSTATE_KEEP; > ... > } > ret = create_gpio_led(&led, ...); > } > > Which means that all LEDs that do not specify default-state will > inherit the last value of the default-state property, which is wrong. Does this actually happen in any 2.6.33 driver code? If so, we might want to merge this into 2.6.33. And perhaps earlier kernels. Or not. There's no way for me to tell :(