On Mon, 13 Jun 2011, Robert Jarzmik wrote:
> On 06/07/2011 12:02 PM, Guennadi Liakhovetski wrote:
> >
> > A general question to you: from your comments I haven't understood: have
> > you also tested the patches or only reviewed them?
>
> I had reviewed them so far.
>
> Now, please have my :
> A
On 06/07/2011 12:02 PM, Guennadi Liakhovetski wrote:
A general question to you: from your comments I haven't understood: have
you also tested the patches or only reviewed them?
I had reviewed them so far.
Now, please have my :
Acked-by: Robert Jarzmik
The ack includes a test done on my plat
On 06/07/2011 12:02 PM, Guennadi Liakhovetski wrote:
On Mon, 6 Jun 2011, Robert Jarzmik wrote:
On 06/06/2011 07:20 PM, Guennadi Liakhovetski wrote:
It is more convenient to propagate the higher level abstraction - the
struct mt9m111 object into functions and then retrieve a pointer to
the i2c
On Mon, 6 Jun 2011, Robert Jarzmik wrote:
> On 06/06/2011 07:20 PM, Guennadi Liakhovetski wrote:
> > It is more convenient to propagate the higher level abstraction - the
> > struct mt9m111 object into functions and then retrieve a pointer to
> > the i2c client, if needed, than to do the reverse.
On 06/06/2011 07:20 PM, Guennadi Liakhovetski wrote:
It is more convenient to propagate the higher level abstraction - the
struct mt9m111 object into functions and then retrieve a pointer to
the i2c client, if needed, than to do the reverse.
Agreed.
One minor point, you ofter replace :
> - str
It is more convenient to propagate the higher level abstraction - the
struct mt9m111 object into functions and then retrieve a pointer to
the i2c client, if needed, than to do the reverse.
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/video/mt9m111.c | 124 +++--
