Couple of nits, but otherwise I think this is good if you address my and Mark's comments

So it would be helpful to see an acpidump of a system with these devices.

If I understand correctly, you leave acpi_iicdev around to attach to the device enumerated by acpi0? For PCI we mostly avoided this since we ignored devices without _HID avoiding the need to copy resources over. It's not clear to me why you need to leave this device around for suspend/resume to work. The iicbus device will be invoked during suspend/resume and can pass those events down to children as needed. The acpi_iicbus driver should be responsible for invoking any needed ACPI methods on handles as part of that. You really want that behavior so you can control when the ACPI methods are invoked in relation to the driver-specific methods (e.g. if an iic child device driver had its own suspend/resume methods). You wouldn't want _PS3 to get run before the driver has a chance to save state for example. For PCI we manage this by having the ACPI PCI bus driver invoke any needed ACPI methods in the right order explicitly related to the PCI device driver methods. I think you probably don't want device_t nodes for acpi_iicdev around at all, but instead probably want to just delete them outright when you encounter one unless it is already attached by some other driver.

In D22901#501848, @jhb wrote:

So it would be helpful to see an acpidump of a system with these devices.

I do not have such a devices. I can provide dumps made by someone else only. See e.g. https://github.com/major/xps-13-9343-dsdt/blob/master/DSDT.dsl . Interesting device is _SB_.PCI0.I2C0.TPD4. It has _PS0, _PS3 and even _PRW methods defined.

If I understand correctly, you leave acpi_iicdev around to attach to the device enumerated by acpi0?

Yes. It is done to reuse acpi bus resource parser and suspend/resume support.

For PCI we mostly avoided this since we ignored devices without _HID avoiding the need to copy resources over. It's not clear to me why you need to leave this device around for suspend/resume to work. The iicbus device will be invoked during suspend/resume and can pass those events down to children as needed. The acpi_iicbus driver should be responsible for invoking any needed ACPI methods on handles as part of that. You really want that behavior so you can control when the ACPI methods are invoked in relation to the driver-specific methods (e.g. if an iic child device driver had its own suspend/resume methods). You wouldn't want _PS3 to get run before the driver has a chance to save state for example. For PCI we manage this by having the ACPI PCI bus driver invoke any needed ACPI methods in the right order explicitly related to the PCI device driver methods.

I think you probably don't want device_t nodes for acpi_iicdev around at all, but instead probably want to just delete them outright when you encounter one unless it is already attached by some other driver.

Ok. It looks like splitting functionality between 2 drivers makes things unclean. I will rewrite the driver to not use acpi_iicdev for the cost of some code duplication.