On 10:07 Fri 21 Dec , Maxime Ripard wrote: > Le 20/12/2012 17:13, ludovic.desroches a écrit : > > On 12/20/2012 04:51 PM, Maxime Ripard wrote: > >> Hi Ludovic, > >> > >> Le 20/12/2012 11:52, ludovic.desroches a écrit : > >>>> I'm wondering, why are you using such a complex dt parsing code, and > >>>> bindings, when you only requires a boolean to switch between 8 and 10 > >>>> bits mode (which seem to be the only thing you support)? > >>> > >>> We will have a 10 and 12 bits mode on future ADCs and I would like to > >>> have something which could manage more than two resolutions if it > >>> happens one day. > >> > >> I see your point. I'm not fond at all of the existing bindings for the > >> driver (putting things like registers offset in the dt is a non-sense to > >> me, but hey...), so I'd like to still keep it as simple and non-bloated > >> as possible, but it's true that in the current situation, we probably > >> have no other choice. > >> > > > > I have the same feeling than you about ADC bindings, I think that there > > are too many parameters exhibited. Moreover, most of them are chip > > relative. > > > > I have not found other ways to deal with it properly. I would like to > > have them hidden into the driver (depending on the compatible string) > > but it will be a mess if we split parameters into dt and driver. > > I'm glad we feel the same way :) I'm not I fee; exactly this opposte way I do want to toucht the kernel code to add new soc so no I like this binding Best Regards, J. -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
