On Mon, 17 Feb 2025 at 20:21, Bernhard Beschow <[email protected]> wrote: > > > > Am 17. Februar 2025 13:35:04 UTC schrieb Peter Maydell > <[email protected]>: > >On Tue, 4 Feb 2025 at 09:21, Bernhard Beschow <[email protected]> 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. thanks -- PMM
