should we have a Kconfig "device group" for I2C devices?

should we have a Kconfig "device group" for I2C devices?

[Peter Maydell]

Hi; I've been looking into what is the right way to handle in Kconfig
an i2c device which is intended for the user to specify on the command
line with a -device option.
(It's the lsm303dlhc magnetometer, currently in code review:
https://patchew.org/QEMU/20210921093227.18592-1-kevin.townsend@linaro.org/ )

Currently all our i2c devices are just pulled in by "select FOO" from
the Kconfig stanza for a board which has that kind of sensor hardwired
on-board. But for at least some of them it works fine to just specify
them on the commandline of any board that has an i2c controller that
allows pluggable devices. (For instance we do that kind of commandline
plugging in our test suite with tests/qtest/tmp105-test.c.)

What's the best way to structure this? For PCI we have the "device
group" PCI_DEVICES as documented in
https://qemu-project.gitlab.io/qemu/devel/kconfig.html#guidelines-for-writing-kconfig-files
and PCI devices say
    default y if PCI_DEVICES
    depends on PCI

For ISA devices we seem to make them say
    default y
    depends on ISA_BUS

I2C devices currently just say
    depends on I2C

Should we have an I2C_DEVICES, which boards where there's a sensible
user-pluggable i2c controller can specifically select ? Or should we
mark the i2c devices which are sensibly user-pluggable as
"default y" ? Or something else ?

thanks
-- PMM

Re: should we have a Kconfig "device group" for I2C devices?

[Paolo Bonzini]

On 1/28/22 15:17, Peter Maydell wrote:
> Hi; I've been looking into what is the right way to handle in Kconfig
> an i2c device which is intended for the user to specify on the command
> line with a -device option.
> (It's the lsm303dlhc magnetometer, currently in code review:
> https://patchew.org/QEMU/20210921093227.18592-1-kevin.townsend@linaro.org/  )
> 
> Currently all our i2c devices are just pulled in by "select FOO" from
> the Kconfig stanza for a board which has that kind of sensor hardwired
> on-board. But for at least some of them it works fine to just specify
> them on the commandline of any board that has an i2c controller that
> allows pluggable devices. (For instance we do that kind of commandline
> plugging in our test suite with tests/qtest/tmp105-test.c.)
> 
> What's the best way to structure this? For PCI we have the "device
> group" PCI_DEVICES as documented in
> https://qemu-project.gitlab.io/qemu/devel/kconfig.html#guidelines-for-writing-kconfig-files
> and PCI devices say
>      default y if PCI_DEVICES
>      depends on PCI
> 
> For ISA devices we seem to make them say
>      default y
>      depends on ISA_BUS
> 
> I2C devices currently just say
>      depends on I2C
> 
> Should we have an I2C_DEVICES, which boards where there's a sensible
> user-pluggable i2c controller can specifically select ? Or should we
> mark the i2c devices which are sensibly user-pluggable as
> "default y" ? Or something else ?

Yes, I think it's a good idea to have I2C_DEVICES like we have 
PCI_DEVICES.  This way we can skip them on x86 (where the SMBus 
controller is mostly a legacy device) but include them by default on 
AVR, embedded ARM, etc.

Paolo

Re: should we have a Kconfig "device group" for I2C devices?

[Philippe Mathieu-Daudé via]

+Alex

On 28/1/22 15:30, Paolo Bonzini wrote:
> On 1/28/22 15:17, Peter Maydell wrote:
>> Hi; I've been looking into what is the right way to handle in Kconfig
>> an i2c device which is intended for the user to specify on the command
>> line with a -device option.
>> (It's the lsm303dlhc magnetometer, currently in code review:
>> https://patchew.org/QEMU/20210921093227.18592-1-kevin.townsend@linaro.org/  
>> )
>>
>> Currently all our i2c devices are just pulled in by "select FOO" from
>> the Kconfig stanza for a board which has that kind of sensor hardwired
>> on-board. But for at least some of them it works fine to just specify
>> them on the commandline of any board that has an i2c controller that
>> allows pluggable devices. (For instance we do that kind of commandline
>> plugging in our test suite with tests/qtest/tmp105-test.c.)
>>
>> What's the best way to structure this? For PCI we have the "device
>> group" PCI_DEVICES as documented in
>> https://qemu-project.gitlab.io/qemu/devel/kconfig.html#guidelines-for-writing-kconfig-files 
>>
>> and PCI devices say
>>      default y if PCI_DEVICES
>>      depends on PCI
>>
>> For ISA devices we seem to make them say
>>      default y
>>      depends on ISA_BUS
>>
>> I2C devices currently just say
>>      depends on I2C
>>
>> Should we have an I2C_DEVICES, which boards where there's a sensible
>> user-pluggable i2c controller can specifically select ? Or should we
>> mark the i2c devices which are sensibly user-pluggable as
>> "default y" ? Or something else ?
> 
> Yes, I think it's a good idea to have I2C_DEVICES like we have 
> PCI_DEVICES.  This way we can skip them on x86 (where the SMBus 
> controller is mostly a legacy device) but include them by default on 
> AVR, embedded ARM, etc.

My first reaction was "Yes, generically each bus should have its
bus_DEVICES" switch; but then I wondered in which use case we still
need this switch.

- In the default case (--with-default-devices) if a board exposes a bus,
   we want to have all the devices compatible with the bus to be built.

- If we use --without-default-devices, then we only want the explicitly
   listed devices, and PCI_DEVICES=y here seems dubious to me.

- If we use --with-devices, this is similar to the previous case
   (--without-default-devices is a specific --with-devices case [*]).

Paolo, in what case do you see having a ${bus}_DEVICES config useful?

Thanks,

Phil.

[*] Actually I think --with-devices replaced
--with[out]-default-devices, it is more powerful / customizable;
we should only keep / maintain --with-devices and drop
--with[out]-default-devices options.