On Wed, Sep 22, 2021 at 09:36:21AM +0300, Andy Shevchenko wrote: > On Thu, Sep 16, 2021 at 02:51:23PM +0200, Florian Eckert wrote: > > Hello Andy, > > > > I just wanted to port my target an APU3 (x86_64) to kernel version 5.10 in > > OpenWrt. > > This is the next stable LTS kernel version in OpenWrt. > > > > On my board I have this device as an I2c bus IO-expander with which I > > control additional LEDs. > > For this purpose I have a platform driver. Which registers these additional > > LEDs. > > I have now discovered that the platform driver no longer compiles due to > > this change, as the platform data for the mcp23017 have been removed by this > > change in kernel version 5.8. Ah, now I got it. You want to instantiate the I2C expander itself, so as I mentioned below it can be easily done via SSDT overlays: https://connect.linaro.org/resources/lvc21f/lvc21f-304/ https://www.youtube.com/watch?v=nlKjUAv3RL0&ab_channel=OSDNConf https://stackoverflow.com/questions/65727454/ https://stackoverflow.com/questions/60105101/ https://stackoverflow.com/questions/54768841/ https://stackoverflow.com/questions/46095840/ https://github.com/westeri/meta-acpi/tree/master/recipes-bsp/acpi-tables/samples/ > > I don't have control over the BIOS (coreboot) > > It's open source. > > > and I can't adjust the ACPI > > tables. > > Actually you can (to some extend) even for closed sourced firmwares (either > with rewriting DSDT as Hackintosh project does, or via SSDT overlays, I gave a > talk on Linaro Connect about this). > > > Since this is an x86 platform, I can't work with a device tree, can I? > > Ideally you need to fix the ACPI tables, but this won't fix older firmwares > anyway. As a workaround you may convert platform data to use software nodes. > > See the example (in v5.15-rc1): > > drivers/mfd/intel_quark_i2c_gpio.c > drivers/gpio/gpio-dwapb.c > drivers/i2c/busses/i2c-designware-platdrv.c > > of such conversion. > > > On 2020-04-07 19:38, Andy Shevchenko wrote: > > > Platform data is a legacy interface to supply device properties > > > to the driver. In this case we even don't have in-kernel users > > > for it. Just remove it for good. -- With Best Regards, Andy Shevchenko