i2c-host for v6.18

i2c-host for v6.18

[Andi Shyti]

Hi Wolfram,

here is the pull request for this cycle. I was hoping it would be
more substantial, but I ran into a nasty issue with my gpg setup
that blocked me from pushing to kernel.org for several weeks. The
kernel.org helpdesk helped me sort it out, but unfortunately a
bit too late, so this is all I managed to gather in time.

I am sorry for the disruption. I will set up a backup solution so
that I can avoid this problem in the future.

Thanks and I wish you a great weekend,
Andi

The following changes since commit 7d0a66e4bb9081d75c82ec4957c50034cb0ea449:

  Linux 6.18 (2025-11-30 14:42:10 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git tags/i2c-host-6.19

for you to fetch changes up to 362e391005a98827a2d98b63f1e9001dd592bc63:

  dt-bindings: i2c: qcom-cci: Document SM8750 compatible (2025-12-03 21:50:26 +0100)

----------------------------------------------------------------
i2c-host for v6.19

- general cleanups in bcmi2835, designware, pcf8584 and stm32
- amd-mp2: fix device refcount
- bcm, pxa, rcar: fix void-pointer-to-enum-cast warning
- designware: avoid interrupt storms caused by bad firmware
- designware: use dedicated xfer function for AMD NAVI
- i801: fix supported features
- spacemit: fix device detection failures

New device support:
- Intel Diamond Rapids and Nova Lake-S (i801)
- Mobileye
- Rockchip RK3506
- Qualcomm Kaanapali, MSM8953 and SM8750

----------------------------------------------------------------
Benoît Monin (4):
      dt-bindings: i2c: dw: Add Mobileye I2C controllers
      i2c: designware: Optimize flag reading in i2c_dw_read()
      i2c: designware: Sort compatible strings in alphabetical order
      i2c: designware: Add dedicated algorithm for AMD NAVI

Brian Masney (1):
      i2c: busses: bcm2835: convert from round_rate() to determine_rate()

Cezar Chiru (5):
      i2c: pcf8584: Remove debug macros from i2c-algo-pcf.c
      i2c: pcf8584: Fix do not use assignment inside if conditional
      i2c: pcf8584: Move 'ret' variable inside for loop, goto out if ret < 0.
      i2c: pcf8584: Make pcf_doAddress() function void
      i2c: pcf8584: Change pcf_doAdress() to pcf_send_address()

Hangxiang Ma (2):
      dt-bindings: i2c: qcom-cci: Document Kaanapali compatible
      dt-bindings: i2c: qcom-cci: Document SM8750 compatible

Heikki Krogerus (1):
      i2c: i801: Fix the Intel Diamond Rapids features

Heiko Stuebner (1):
      dt-bindings: i2c: i2c-rk3x: Add compatible string for RK3506

Jarkko Nikula (1):
      i2c: i801: Add support for Intel Nova Lake-S

Jinhui Guo (1):
      i2c: designware: Disable SMBus interrupts to prevent storms from mis-configured firmware

Krzysztof Kozlowski (3):
      i2c: bcm-iproc: Fix Wvoid-pointer-to-enum-cast warning
      i2c: pxa: Fix Wvoid-pointer-to-enum-cast warning
      i2c: rcar: Fix Wvoid-pointer-to-enum-cast warning

Luca Weiss (1):
      dt-bindings: i2c: qcom-cci: Document msm8953 compatible

Ma Ke (1):
      i2c: fix reference leak in MP2 PCI device

Markus Elfring (2):
      i2c: designware: Omit a variable reassignment in dw_i2c_plat_probe()
      i2c: stm32: Omit two variable reassignments in stm32_i2c_dma_request()

Nathan Chancellor (1):
      i2c: designware: Remove i2c_dw_remove_lock_support()

Troy Mitchell (1):
      i2c: spacemit: fix detect issue

Zeng Guang (1):
      i2c: i801: Add support for Intel Diamond Rapids

 Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml            |   1 +
 Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml        |   6 ++++
 Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml |   7 +++++
 Documentation/i2c/busses/i2c-i801.rst                          |   2 ++
 drivers/i2c/algos/i2c-algo-pcf.c                               | 105 +++++++++++++++++----------------------------------------------------
 drivers/i2c/busses/Kconfig                                     |   2 ++
 drivers/i2c/busses/i2c-amd-mp2-pci.c                           |   5 +++-
 drivers/i2c/busses/i2c-bcm-iproc.c                             |   3 +-
 drivers/i2c/busses/i2c-bcm2835.c                               |  12 ++++----
 drivers/i2c/busses/i2c-designware-core.h                       |   2 +-
 drivers/i2c/busses/i2c-designware-master.c                     |  34 +++++++++++++++--------
 drivers/i2c/busses/i2c-designware-platdrv.c                    |  17 ++----------
 drivers/i2c/busses/i2c-i801.c                                  |   6 ++++
 drivers/i2c/busses/i2c-k1.c                                    |  19 +++++++++----
 drivers/i2c/busses/i2c-pxa.c                                   |   2 +-
 drivers/i2c/busses/i2c-rcar.c                                  |   2 +-
 drivers/i2c/busses/i2c-stm32.c                                 |   7 ++---
 17 files changed, 105 insertions(+), 127 deletions(-)

Re: i2c-host for v6.18

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]

Hi Andi,

> here is the pull request for this cycle. I was hoping it would be
> more substantial, but I ran into a nasty issue with my gpg setup
> that blocked me from pushing to kernel.org for several weeks. The
> kernel.org helpdesk helped me sort it out, but unfortunately a
> bit too late, so this is all I managed to gather in time.

Things happen. Don't worry about this one...

> I am sorry for the disruption. I will set up a backup solution so
> that I can avoid this problem in the future.

Another tree at gitlab maybe?

> The following changes since commit 7d0a66e4bb9081d75c82ec4957c50034cb0ea449:
> 
>   Linux 6.18 (2025-11-30 14:42:10 -0800)

Urgs, but this is highly problematic. I can't pull something based on
6.18. Usually, things are based on -rc1 or something early to show Linus
that it has been in -next for a while. He won't pull something that is
less than 48 hours in public and so won't I.

I hope you still have the ref of the branch *before* you rebased to
6.18. Please send a pull request for this old one.

And I am quite sure I said it before: Please *do* *not* rebase branches
you have published which are meant to be consumed! Other people (me!)
depend on their stability and history. In very rare cases, sometimes a
commit needs to be modified or deleted. But the base should really stay
the base. If you need a newer one (also rare), merge it.

Not pulled, sorry.

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: i2c-host for v6.18

[Andi Shyti]

Hi Wolfram,

> >   Linux 6.18 (2025-11-30 14:42:10 -0800)
> 
> Urgs, but this is highly problematic. I can't pull something based on
> 6.18. Usually, things are based on -rc1 or something early to show Linus
> that it has been in -next for a while. He won't pull something that is
> less than 48 hours in public and so won't I.

Just a note that I merged the last few patches on Wednesday. So,
if the 48 hour window applies, we are well within it.

> I hope you still have the ref of the branch *before* you rebased to
> 6.18. Please send a pull request for this old one.

As I mentioned privately, I can split this into two pull requests
and use the older reference for the earlier patches if that
helps. To me it feels more like a formality, since those patches
have already been in -next for a few weeks and were only rebased
on top of v6.18. But I am happy to do whatever you prefer.

Andi

Re: i2c-host for v6.18

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]


> > Urgs, but this is highly problematic. I can't pull something based on
> > 6.18. Usually, things are based on -rc1 or something early to show Linus
> > that it has been in -next for a while. He won't pull something that is
> > less than 48 hours in public and so won't I.
> 
> Just a note that I merged the last few patches on Wednesday. So,
> if the 48 hour window applies, we are well within it.

Well, it is not strictly about 48 hours... I just picked the number
because all of the rebased patches were ~2 days old at the time I looked
at them.

> As I mentioned privately, I can split this into two pull requests
> and use the older reference for the earlier patches if that
> helps. To me it feels more like a formality, since those patches
> have already been in -next for a few weeks and were only rebased
> on top of v6.18.

But this is the key point: after rebasing, no one can see how long they
have been in -next. Especially not the person you ask to pull. This
doesn't look trustworthy. If you hadn't rebased, then one can easily see
that most patches have been in -next for weeks. And if then there are
some new patches on top which are simple enough (like adding an ID),
then the whole pull request probably still looks trustworthy.

> But I am happy to do whatever you prefer.

I prefer one pull request using the ref before the 6.18 rebase.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]