Re: IIO_BUFFER - IIO_TRIGGERED_BUFFER circular dependency

[Jonathan Cameron <jic23@kernel.org>]

On 03/01/2013 05:20 PM, Guenter Roeck wrote:
> On Fri, Mar 01, 2013 at 04:04:29PM +0100, Lars-Peter Clausen wrote:
>> On 03/01/2013 03:41 PM, Guenter Roeck wrote:
>>> On Fri, Mar 01, 2013 at 02:38:30PM +0100, Lars-Peter Clausen wrote:
>>>> On 03/01/2013 05:32 AM, Guenter Roeck wrote:
>>>>> Hi all,
>>>>>
>>>>> IIO_TRIGGERED_BUFFER depends on IIO_BUFFER because of:
>>>>>
>>>>> drivers/iio/industrialio-triggered-buffer.c:20:16: error:
>>>>> ‘iio_sw_buffer_preenable’ undeclared here (not in a function)
>>>>>
>>>>> On the other side, it is often selected as follows.
>>>>>
>>>>> 	select IIO_TRIGGERED_BUFFER if (IIO_BUFFER)
>>>>>
>>>>> For that reason, selecting IIO_BUFFER in the IIO_TRIGGERED_BUFFER declaration
>>>>> results in a circular dependency. Sometimes the "if (IIO_BUFFER)" when selecting
>>>>> IIO_TRIGGERED_BUFFER is missing, though, which can result in the compile error.
>>>>>
>>>>> What is the proper solution ?
>>>>> - Add "if (IIO_BUFFER)" whenever IIO_TRIGGERED_BUFFER is selected
>>>>> or
>>>>> - Remove "if (IIO_BUFFER)" from IIO_TRIGGERED_BUFFER selection and add "select
>>>>>   IIO_BUFFER" to the IIO_TRIGGERED_BUFFER declaration
>>>>>
>>>>> I would prefer the latter to solve the problem for good.
>>>>
>>>> Hi,
>>>>
>>>> This is a bit tricky, some drivers have optional buffer support, so they
>>>> only select the helper module if buffer support is enabled, since they don't
>>>> use the helper module if buffer support is disabled. Other driver though
>>>> always want buffer support so they select the helper module unconditionally.
>>>> So far it was the responsibility of the driver's Kconfig entry to make sure
>>>> that if it selects IIO_TRIGGERED_BUFFER it needs to make sure that
>>>> IIO_BUFFER is also selected. As far as I can see all drivers do this
>>>> currently. Which one breaks things for you?
>>>>
>>> It is a randconfig thing, so it breaks in some of my nightly randconfig builds,
>>> and it has also been reported as build failure in the official builds. I can dig
>>> out some affected configurations and send it to you if you like.
>>
>> Yes that would be great, thanks.
>>
>>> but the gist of
>>> it is that IIO_TRIGGERED_BUFFER can be selected without IIO_BUFFER, but depends
>>> on it. That just isn't correct. Of course, the other option might be to make
>>> IIO_TRIGGERED_BUFFER dependent on IIO_BUFFER. Would that be acceptable ?
>>>
>>
>> That won't work, you can overwrite 'depends on' by selecting the symbol.
>>
>> But the reason why there is a cyclic dependency is not because of the
>> 'select IIO_TRIGGERED_BUFFER if (IIO_BUFFER)' but rather because
>> IIO_TRIGGERED_BUFFER is in an 'if IIO_BUFFER' section. Moving it out there
>> fixes the cyclic dependency error. But creates a recursive dependency warning.
>>
>> I think we could avoid this warning by introducing a new symbol. E.g.
>> IIO_BUFFER_INTERN (bad name). IIO_BUFFER_INTERN won't be user selectable. It
>> will be selected by IIO_BUFFER and IIO_TRIGGERED_BUFFER and if it is
>> selected buffer support is built. E.g. something like this:
>>
> Agreed, that would also solve the need of selecting IIO_BUFFER as well if
> IIO_TRIGGERED_BUFFER is selected. For now I solved the problem with the two
> patches I submitted, so assuming those are accepted I guess this one or
> something similar can wait for -next.
Agreed.  Sounds like Lars volunteered to do this to me ;) It's a little uggly
but I can't immediately think of anything better.
> 
> Thanks,
> Guenter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>