Re: [RFC PATCH 5/8] media/i2c/Kconfig: drop superfluous MEDIA_CONTROLLER

[Hans Verkuil <hansverk@cisco.com>]

On 12/19/2014 01:18 PM, Laurent Pinchart wrote:
> Hi Hans,
> 
> On Friday 19 December 2014 12:44:46 Hans Verkuil wrote:
>> On 12/08/2014 12:38 AM, Laurent Pinchart wrote:
>>> On Thursday 04 December 2014 10:54:56 Hans Verkuil wrote:
>>>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>>>
>>>> These drivers depend on VIDEO_V4L2_SUBDEV_API, which in turn
>>>> depends on MEDIA_CONTROLLER. So it is sufficient to just depend
>>>> on VIDEO_V4L2_SUBDEV_API.
>>>
>>> Shouldn't the VIDEO_V4L2_SUBDEV_API dependency be dropped from those (and
>>> other) subdev drivers ? They don't require the userspace API, just the
>>> kernel part.
>>
>> They set V4L2_SUBDEV_FL_HAS_DEVNODE and use v4l2_subdev_get_try_format,
>> so they do need VIDEO_V4L2_SUBDEV_API. Or am I missing something?
> 
> VIDEO_V4L2_SUBDEV_API was initially designed to cover both the subdev 
> userspace API and the subdev in-kernel pad-level API. Now that the latter has 
> been found useful without the former, I think we should revisit the idea.
> 
> Does it still make sense to have a single Kconfig option to cover both 
> concepts ? Should it be kept a-is, split in two, or redefined to cover the 
> userspace API only (with the v4l2_subdev_get_try_* functions being then always 
> available) ? As the idea is to standardize on pad-level operations for in-
> kernel communication between bridges and subdevs the v4l2_subdev_get_try_* 
> functions will get increasingly used in most (if not all) subdev drivers.

OK, but if you don't mind I would make such changes in a separate patch.
This patch just removes an obviously superfluous dependency and brings these
drivers in line with the others.

Removing it altogether is a separate issue.

Regards,

	Hans