Re: [RFCv1 PATCH 1/7] gspca: allow subdrivers to use the control framework.

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 05/05/2012 04:50 PM, Hans Verkuil wrote:
> On Sat May 5 2012 16:46:32 Hans de Goede wrote:
>> Hi,
>>
>> On 05/05/2012 10:34 AM, Hans Verkuil wrote:
>>> On Sat May 5 2012 09:43:01 Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> I'm slowly working my way though this series today (both review, as well
>>>> as some tweaks and testing).
>>>
>>> Thanks for that!
>>>
>>> One note: I initialized the controls in sd_init. That's wrong, it should be
>>> sd_config. sd_init is also called on resume, so that would initialize the
>>> controls twice.
>>
>> You cannot move the initializing of the controls to sd_config, since in many
>> cases the sensor probing is done in sd_init, and we need to know the sensor
>> type to init the controls.
>
> Or you move the sensor probing to sd_config as I did. It makes no sense
> anyway to do sensor probing every time you resume.
>
> Unless there is another good reason for doing the probing in sd_init I prefer
> to move it to sd_config.

Sensor probing does more then just sensor probing, it also configures
things like the i2c clockrate, and if the bus between bridge and sensor
is spi / i2c or 3-wire, or whatever ...

After a suspend resume all bets are of wrt bridge state, so we prefer to
always do a full re-init as we do on initial probe, so that we (hopefully)
will put the bridge back in a sane state.

I think moving the probing from init to config is a bad idea, the chance
that we will get regressions (after a suspend/resume) from this are too
big IMHO.

Regards,

Hans