Hello Ezequiel, On Tue, Mar 22, 2016 at 07:47:06PM -0500, Rob Herring wrote: > On Tue, Mar 22, 2016 at 5:50 PM, Ezequiel Garcia > <ezequiel@xxxxxxxxxxxxxxxxxxxx> wrote: > > (Adding DT people) Thanks. (I thought addressing the list was enough.) > > On 22 March 2016 at 18:08, Uwe Kleine-König > > <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > >> A plain binary encoding has some downsides compared to the usual Gray > >> encoding, but that doesn't stop hardware engineers to eventually use it. > >> So implement support for this encoding in the rotary encoder driver. > >> > >> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> > >> --- > >> Hello, > >> > >> an alternative to define this difference in the device tree is to use > >> something like: > >> > >> rotary-encoder,encoding = "binary"; > >> > >> or > >> > >> rotary-encoder,encoding = <ROTARY_ENCODER_ENCODING_BINARY>; > >> > >> instead of a property > >> > >> rotary-encoder,encoding-binary; > >> > >> . While the two first solutions make it obvious that there can only be > >> one encoding, they IMHO look ugly, so I went for the property without > >> value. What do you think? > >> > > > > Yes, picking something like: > > > > rotary-encoder,encoding = "binary"; > > > > emphasizing the fact that only one encoding will be used, > > will work better, scaling well if we need to introduce some > > "foobar" encoding. OK, then I stick to strings to not have to introduce magic constants or cpp symbols? > Fine, but "rotary-encoder" is not a vendor I've ever heard of. Just > "encoding" is sufficient. I picked that to be consistent with rotary-encoder,steps and other already existing properties documented in Documentation/devicetree/bindings/input/rotary-encoder.txt. Should the prefix be dropped for these, too (with compat code)? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html