Re: iio: STMicroelectronics iio drivers

[Denis CIOCCA <denis.ciocca@st.com>]

Hi Jonathan,

I'm working on the problems that you described, but why if I compile one=20
file how module the #define IIO_CONFIG_*** aren't works?
For st_sensors I modified the Kconfig removing the description and=20
changed tristate option to bool, in drivers I want to leave 4 modules=20
(if it is possible) but if I compile as module the #define don't work.

Denis


On 01/16/2013 09:48 AM, Jonathan Cameron wrote:
> On 15/01/13 23:01, Jonathan Cameron wrote:
>> On 01/15/2013 10:33 PM, Jonathan Cameron wrote:
>>> On 01/15/2013 08:30 AM, Denis CIOCCA wrote:
>>>> Hi Jonathan,
>>>>
>>>> I sent to you the new patches to fix the u8 casting and a little bugfi=
x in the header files (functions within #ifdef).
>>>> Thanks,
>>>>
>>>> Denis
>>>>
>>>>
>>> Denis,
>>>
>>> Just been running some build tests on this.  You need to
>>> do a lot more testing of the various possible combinations
>>> I think. Right now I can't build and so far I'm not entirely
>>> sure why.
>>>
>>>     CHECK   drivers/iio/accel/st_accel_i2c.c
>>> drivers/iio/accel/st_accel_i2c.c:38:9: error: undefined identifier 'st_=
sensors_i2c_configure'
>>>     CC [M]  drivers/iio/accel/st_accel_i2c.o
>>> drivers/iio/accel/st_accel_i2c.c: In function 'st_accel_i2c_probe':
>>> drivers/iio/accel/st_accel_i2c.c:38:2: error: implicit declaration of f=
unction 'st_sensors_i2c_configure'
>>> make[3]: *** [drivers/iio/accel/st_accel_i2c.o] Error 1
>>> make[2]: *** [drivers/iio/accel] Error 2
>>> make[1]: *** [drivers/iio] Error 2
>>> make: *** [drivers] Error 2
>>>
>>> For reasons that aren't immediately clear ifdef CONFIG statements don't
>>> seem to be working...
>>
>> Of course, I had relevant bits compiling as modules.
>>
>> I think we should rethink the module structure here so that this mess do=
esn't occur.
>> One core driver with multiple files seems right to me.
>>
>> so a make file looking something like.
>> obj-$(CONFIG_IIO_ST_SENSORS_CORE) +=3D st_sensors.o
>> st_sensors-y :=3D st_sensors_core.o
>> st_sensors-$(CONFIG_IIO_ST_SENSORS_I2C) +=3D st_sensors_i2c.o
>> st_sensors-$(CONFIG_IIO_ST_SENSORS_SPI) +=3D st_sensors_spi.o
>> st_sensors-$(CONFIG_IIO_ST_SENSORS_TRIGGERED_BUFFER) +=3D st_sensors_tri=
gger.o st_sensors_buffer.o
>>
>> and a kconfig where all by the sensors_core entry are boolean.
>>
>> Similarly for the drivers.  Thus we end up with 4 modules rather than do=
zens and
>> hopefully the build logic will work fine in all cases.
>>
>> Also note that I think you can't have buffering for accel and not gyro e=
tc.
>>
> Thinking a little more on this, I can see why you'd want separate
> library drivers for the i2c and spi parts.  You would however benefit
> from pulling the bits in the ifdefs out to separate headers without any
> protection and then including them only where needed.  The triggered
> buffer bit still wants to be in the main st_sensors module though via
> the boolean suggestion above. You may even want to hide away the
> config options for the library support (don't give them a description
> and they won't show up in make menuconfig etc).  I can't see why
> people would want to manually select them without the drivers.
>
>   From the buffered point of view, I'd go with the same trick for config
> that most other drivers have and make it dependent on IIO_BUFFER on the
> assumption that won't be there on a stripped down system anyway and it
> makes life nice and simple without any interesting issues like will be
> seen here.
>
> Jonathan
>>
>>
>>>
>>> I also suspect we have too many complex build options in here in the fi=
rst
>>> place. It's probably not unreasonable for instance to build in buffered=
 support
>>> if buffering is enabled in general for IIO rather than explicitly.
>>>
>>> Jonathan
>>> --
>>> 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
>>>
>> --
>> 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
>>
>