Am 18. Februar 2025 10:33:26 UTC schrieb Peter Maydell
<peter.mayd...@linaro.org>:
>On Mon, 17 Feb 2025 at 20:21, Bernhard Beschow <shen...@gmail.com> wrote:
>>
>>
>>
>> Am 17. Februar 2025 13:35:04 UTC schrieb Peter Maydell
>> <peter.mayd...@linaro.org>:
>> >On Tue, 4 Feb 2025 at 09:21, Bernhard Beschow <shen...@gmail.com> wrote:
>> >>
>> >> While at it and since they are user-creatable, build them when
>> >> CONFIG_I2C_DEVICES is set.
>> >
>> >The patch subject says this is just a rearrangement
>> >of the Kconfig stanzas with no behaviour change, but then the
>> >commit message body includes one.
>> >
>> >If you want to build these when CONFIG_I2C_DEVICES is set,
>> >that should be its own patch that does that.
>> >
>> >(The move of the Kconfig bits to hw/gpio is fixing a bug
>> >in 6328d8ffa6cb9d ("misc/pca955*: Move models under hw/gpio"),
>> >which moved the code but forgot to move the Kconfig sections.)
>>
>> Okay, I'll split the patch and use above commit message.
>>
>> >
>> >Separately, it's unclear to me how worthwhile it is to add
>> >these to CONFIG_I2C_DEVICES, because they're GPIO devices,
>> >which means there's not much you can do with them as a user:
>> >as far as I know you can't wire the output/input GPIO lines
>> >up to anything. We have the device models mainly for boards
>> >which provide them, so that guest code that expects to see
>> >them doesn't fall over on bootup, and because the board
>> >model code does have the APIs to wire up the GPIO lines.
>>
>> It's basically to satisfy Linux which will clog the i2c bus if such a GPIO
>> expander is configured in the DTB but missing in the emulation (it will
>> defer probing which will never make progress). Once it is its own patch we
>> can decide separately how to proceed with it, e.g. dropping.
>
>If Linux wants to see it because it's in the dtb for the
>hardware it sounds like the right answer is that we
>should create it in the board code, which we can do
>without adding it to CONFIG_I2C_DEVICES, because we
>can make the board code's Kconfig do "select PCA9552",
>like the aspeed board does already.
These devices are primarily intended for modeling our custom hardware on the
command line, for the purpose explained in [1]. While the real imx8mp-evk has a
tca6416, I'd rather avoid creating it in board code, even if there was a model
for it in QEMU. The reason is that the machine works fine without it as is, and
that omitting hardcoded peripherals seems to increase the utility of the
machine because it allows users to customize their machines without hardcoded
peripherals getting into their way.
Since the two device models in this patch work by chance if other machines
select them I'm fine with not implying CONFIG_I2C_DEVICES.
Best regards,
Bernhard
[1]
https://lore.kernel.org/qemu-devel/831901e4-69b2-4637-8507-77c7bf4da...@gmail.com/
>
>thanks
>-- PMM
