[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGo_u6oQP6eGkCQe=uTBmUsKQqFbS9_xXYt24_HRtjEr561O=g@mail.gmail.com>
Date: Thu, 16 May 2013 15:42:39 -0500
From: Nishanth Menon <nm@...com>
To: Dan Murphy <dmurphy@...com>
Cc: Russell King - ARM Linux <linux@....linux.org.uk>,
BenoƮt Cousson <b-cousson@...com>,
Tony Lindgren <tony@...mide.com>,
devicetree-discuss@...ts.ozlabs.org,
lkml <linux-kernel@...r.kernel.org>,
linux-omap <linux-omap@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v4] ARM:dts:omap4-panda: Update the LED support for the
panda DTS
On Thu, May 16, 2013 at 3:22 PM, Dan Murphy <dmurphy@...com> wrote:
> On 05/16/2013 01:18 PM, Nishanth Menon wrote:
>> On Thu, May 16, 2013 at 10:35 AM, Dan Murphy <dmurphy@...com> wrote:
>>> I am not sure you really want to do this.
>>> If I make the pinctrl part of the led structure then the only way the gpio_wk7 on a1-a3 to be configured is when
>>> the CONFIG_LEDS_GPIO flag is set.
>>>
>>> Do you really want that dependency? You did say it was a key fix
>>> At least this way the pins are configured regardless of that flag.
>> That is better as the system will be left in the pinmux configuration
>> handed over from bootloader.
> So you want to depend on a boot loader to configure pins correctly for the kernel?
> Hmmm seems risky to me.
Not really! if it is a critical pinmux, pinmux defaults are great,
else belongs definitely to device->pinctrl :) depending on bootloader
pinmux implies NOT having pinmux even for device - NO. that is
definitely not what I stated.
Regards,
NM
--
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