[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20140704163119.GB7106@leverpostej>
Date: Fri, 4 Jul 2014 17:31:19 +0100
From: Mark Rutland <mark.rutland@....com>
To: Daniel Jeong <gshark.jeong@...il.com>
Cc: Jingoo Han <jg1.han@...sung.com>, Bryan Wu <cooloney@...il.com>,
Lee Jones <lee.jones@...aro.org>,
Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
Tomi Valkeinen <tomi.valkeinen@...com>,
"grant.likely@...aro.org" <grant.likely@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Randy Dunlap <rdunlap@...radead.org>,
Daniel Jeong <daniel.jeong@...com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [RFC v4 2/2] backlight: device tree: add new tps611xx backlight
binding
> > +- rfa-enable: enable request for acknowledge.
> > + If RFA is enabled, the data byte includes the RFA bit and device will
> wait
> > + and check acknowledge from device.
>
> You didn't answer my question as to why this should be in the DT.
>
>
> According to the RFA enable, the easy scale pin works differently.
> This value should be set before the first data transfer.
Sure, things works differently if this is set. That I understood.
What I haven't heard is a rationale as to why this configuration option
shuold be in the DT.
Can I enable this on all implementations, or not?
When would I enable this and when would I not?
The property reads like a switch to turn a feature on, rather than the
description of the presence of a feature.
Mark.
--
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