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. Thanks, Guenter -- 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
