[v5,00/24] i2c: designware: code consolidation & cleanups

The series now consists the following groups of patches:
- fixing cleanup order in error path and remove (patches 1-4)
- refactoring i2c_dw_*_lock_support() (patches 5-6)
- refactoring module alias and device ID tables (patches 7-10)
- unifying firmware parsing and configuring code (patches 11-15)
- miscellaneous cleanups (patches 16-17,21-24)
- consolidating PM ops (patch 18)
- using device_set_node() for all drivers (patches 19-20)

Changelog v5:
- collected tags (Serge, Jarkko, Andi)
- corrected commit messages in patches 7, 18, 19 (Andi)
- amended grammar in the patch 24 as suggested (Andi)

v4: https://lore.kernel.org/r/20231120144641.1660574-1-andriy.shevchenko@linux.intel.com

Changelog v4:
- dropped first patch as controversial (Jarkko)
- dropped Fixes tag from a few patches (Jarkko)
- moved a hunk in patch 1 to patch 2 where it belongs (Jarkko)
- exported i2c_dw_disable() for modular building (Jarkko)
- added tags (Mario, Jarkko)

v3: https://lore.kernel.org/r/20231110182304.3894319-1-andriy.shevchenko@linux.intel.com

Changelog v3:
- doubled the size of the series
- fixed compilation error (LKP)
- added tags (Andi)

v2: https://lore.kernel.org/r/20231109182823.3531846-1-andriy.shevchenko@linux.intel.com

Changelog v2:
- reworked the series to make it less twisted (Jarkko, Andi)
- added tags to the patches that have been rebased (Andi, Mario, Jarkko)
- introduced a few new changes (PM ops, export namespace)

v1: https://lore.kernel.org/r/20230725143023.86325-1-andriy.shevchenko@linux.intel.com

Andy Shevchenko (24):
  i2c: designware: Fix PM calls order in dw_i2c_plat_probe()
  i2c: designware: Fix reset call order in dw_i2c_plat_probe()
  i2c: designware: Let PCI core to take care about interrupt vectors
  i2c: designware: Fix lock probe call order in dw_i2c_plat_probe()
  i2c: designware: Replace a while-loop by for-loop
  i2c: designware: Save pointer to semaphore callbacks instead of index
  i2c: designware: Add missing 'c' into PCI IDs variable name
  i2c: designware: Replace MODULE_ALIAS() with MODULE_DEVICE_TABLE()
  i2c: designware: Unify terminator in device ID tables
  i2c: designware: Always provide device ID tables
  i2c: designware: Drop return value from i2c_dw_acpi_configure()
  i2c: designware: Drop return value from dw_i2c_of_configure()
  i2c: designware: Rename dw_i2c_of_configure() -> i2c_dw_of_configure()
  i2c: designware: Consolidate firmware parsing and configuring code
  i2c: designware: Unify the firmware type checks
  i2c: designware: Move exports to I2C_DW namespaces
  i2c: designware: Remove ->disable() callback
  i2c: designware: Consolidate PM ops
  i2c: designware: Uninline i2c_dw_probe()
  i2c: designware: Propagate firmware node
  i2c: designware: Use pci_get_drvdata()
  i2c: designware: Use temporary variable for struct device
  i2c: designware: Get rid of redundant 'else'
  i2c: designware: Fix spelling and other issues in the comments

 drivers/i2c/busses/i2c-designware-amdpsp.c  |  14 +-
 drivers/i2c/busses/i2c-designware-common.c  | 167 +++++++++-
 drivers/i2c/busses/i2c-designware-core.h    |  47 +--
 drivers/i2c/busses/i2c-designware-master.c  |  19 +-
 drivers/i2c/busses/i2c-designware-pcidrv.c  | 114 ++-----
 drivers/i2c/busses/i2c-designware-platdrv.c | 337 +++++++-------------
 drivers/i2c/busses/i2c-designware-slave.c   |  12 +-
 7 files changed, 339 insertions(+), 371 deletions(-)

> Wolfram, is there any chance to get this into this (v6.8) cycle?

Sure, due to lots of travels and other issues I am in general very late
with preparing the merge window.

Applied to for-next, thanks!

On Tue, Dec 19, 2023 at 11:23:14AM +0100, Wolfram Sang wrote:
> 
> > Wolfram, is there any chance to get this into this (v6.8) cycle?
> 
> Sure, due to lots of travels and other issues I am in general very late
> with preparing the merge window.
> 
> Applied to for-next, thanks!

Awesome!
Thank you and happy holidays!

Hi Wolfram

On 12/19/23 12:23, Wolfram Sang wrote:
> 
>> Wolfram, is there any chance to get this into this (v6.8) cycle?
> 
> Sure, due to lots of travels and other issues I am in general very late
> with preparing the merge window.
> 
> Applied to for-next, thanks!
> 
Can we put this on hold from not being queued into v6.8 or better drop 
the whole patchset?

Andy is right now out of office and there is a serious i2c-designware 
regression in linux-next on AMD machine and I'm not able to figure out 
quickly reason for it:

https://lore.kernel.org/linux-i2c/20231229120820.GCZY62tM7z4v2XmOAZ@fat_crate.local/

On Fri, Jan 05, 2024 at 11:54:52AM +0200, Jarkko Nikula wrote:
> On 12/19/23 12:23, Wolfram Sang wrote:
> > 
> > > Wolfram, is there any chance to get this into this (v6.8) cycle?
> > 
> > Sure, due to lots of travels and other issues I am in general very late
> > with preparing the merge window.
> > 
> > Applied to for-next, thanks!
> > 
> Can we put this on hold from not being queued into v6.8 or better drop the
> whole patchset?
> 
> Andy is right now out of office and there is a serious i2c-designware
> regression in linux-next on AMD machine and I'm not able to figure out
> quickly reason for it:
> 
> https://lore.kernel.org/linux-i2c/20231229120820.GCZY62tM7z4v2XmOAZ@fat_crate.local/

We have time to nail down it after rc1 is out, don't we?

> We have time to nail down it after rc1 is out, don't we?

Well, I think I can wait a week into the mergewindow until I send out my
pull request. So, you guys have a bit of time to work on this
regression. Sounds good?