[GIT PULL] i2c for v7.3, part 2

[GIT PULL] i2c for v7.3, part 2

[Andi Shyti]

Hi Linus,

as anticipated, here is the second part of the I2C pull request
for v7.3. I waited a little before sending it because I wanted
to give the branch a few more days of testing after merging the
Rust pull request.

It contains a few small fixes and cleanups around probe error
handling, resource management and a minor Rust cleanup.

(I added this short introduction to the tag log, as I noticed
you copied it from there in the past.)

The branch is rebased onto your I2C part 1 merge commit.

That should be all from I2C for v7.3.

Thank you,
Andi

The following changes since commit abea5c349368a683e40fdc2e745099aaaacc89d7:

  Merge tag 'i2c-7.3-part1' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux (2026-08-19 09:23:13 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git tags/i2c-7.3-part2

for you to fetch changes up to d576a9561a1c80ae593539fb0ce0743d66825ac2:

  Merge tag 'rust-i2c-for-7.3' into i2c/i2c (2026-08-22 14:19:34 +0200)

----------------------------------------------------------------
i2c for v7.3, part 2

Fixes and cleanups around probe error handling, resource
management and a minor Rust cleanup.

Drivers:
- several drivers: drop duplicate IRQ error reporting
- imx-lpi2c: improve probe initialization and error cleanup
- mxs: fix DMA channel leak on probe failure
- ocores: fix clock cleanup on resume failure
- rcar: handle reset controllers without status support

Muxes:
- demux-pinctrl: fix OF node leak on allocation failure

Rust:
- mark trivial I2cAdapter reference-counting methods inline

----------------------------------------------------------------
Andi Shyti (1):
      Merge tag 'rust-i2c-for-7.3' into i2c/i2c

Carlos Song (2):
      i2c: imx-lpi2c: properly unwind resources on probe failure
      i2c: imx-lpi2c: reset controller in probe stage

Linkai Gong (1):
      i2c: mux: demux-pinctrl: fix OF node leak on kstrdup failure

Nicolás Antinori (1):
      i2c: rust: mark I2cAdapter methods as inline

Pei Xiao (1):
      i2c: busses: drop redundant dev_err_probe() around irq helpers

Ruoyu Wang (2):
      i2c: ocores: Disable clock on failed resume
      i2c: mxs: fix DMA channel leak on probe error

Wolfram Sang (1):
      i2c: rcar: fix reset handling for Gen5

 drivers/i2c/busses/i2c-amd-asf-plat.c      |  4 ++--
 drivers/i2c/busses/i2c-bcm-iproc.c         |  3 +--
 drivers/i2c/busses/i2c-gxp.c               |  2 +-
 drivers/i2c/busses/i2c-hisi.c              |  2 +-
 drivers/i2c/busses/i2c-imx-lpi2c.c         | 40 ++++++++++++++++++++++++++++------------
 drivers/i2c/busses/i2c-imx.c               |  2 +-
 drivers/i2c/busses/i2c-k1.c                |  4 ++--
 drivers/i2c/busses/i2c-ls2x.c              |  2 +-
 drivers/i2c/busses/i2c-microchip-corei2c.c |  3 +--
 drivers/i2c/busses/i2c-mlxbf.c             |  2 +-
 drivers/i2c/busses/i2c-mxs.c               |  5 +----
 drivers/i2c/busses/i2c-nomadik.c           |  3 +--
 drivers/i2c/busses/i2c-ocores.c            |  6 +++++-
 drivers/i2c/busses/i2c-qcom-geni.c         |  3 +--
 drivers/i2c/busses/i2c-rcar.c              | 27 ++++++++++++---------------
 drivers/i2c/busses/i2c-riic.c              |  3 +--
 drivers/i2c/busses/i2c-rzv2m.c             |  2 +-
 drivers/i2c/busses/i2c-sprd.c              |  4 +---
 drivers/i2c/busses/i2c-st.c                |  3 +--
 drivers/i2c/busses/i2c-stm32f4.c           |  6 ++----
 drivers/i2c/busses/i2c-stm32f7.c           |  4 ++--
 drivers/i2c/busses/i2c-sun6i-p2wi.c        |  4 +---
 drivers/i2c/busses/i2c-synquacer.c         |  2 +-
 drivers/i2c/busses/i2c-uniphier-f.c        |  2 +-
 drivers/i2c/busses/i2c-uniphier.c          |  2 +-
 drivers/i2c/busses/i2c-viai2c-wmt.c        |  3 +--
 drivers/i2c/busses/i2c-viai2c-zhaoxin.c    |  3 +--
 drivers/i2c/busses/i2c-xlp9xx.c            |  2 +-
 drivers/i2c/muxes/i2c-demux-pinctrl.c      |  1 +
 rust/kernel/i2c.rs                         |  3 +++
 30 files changed, 78 insertions(+), 74 deletions(-

Re: [GIT PULL] i2c for v7.3, part 2

[Linus Torvalds]

On Mon, 24 Aug 2026 at 04:55, Andi Shyti <andi.shyti@kernel.org> wrote:
>
> (I added this short introduction to the tag log, as I noticed
> you copied it from there in the past.)

Yes, so different people have different models - some people put
everything in the signed tag message, some people do all the
explanations in the email as they send out the pull request, and
others do a bit of both: the tag may contain a summary, and then the
pull request email contains some general commentary.

It's not a huge deal for me which approach people use, because I
typically end up reading and editing the merge message anyway. Partly
just to try to make the merge messages have some consistency (well, a
couple of different formats, there's no "one single merge message
format"), but mostly simply because that's my workflow around it as
part of reading the pull request explanations.

So it's not really even "extra work" for me - massanging that merge
commit message is in many ways the thing that is what I do as a
central part of familiarizing myself with what the high-level "what is
going on" is.

That said, putting the short intro into the signed tag has some
advantages - if it's all there in the tag, it's just one less
operation for me that I can mess up (most commonly by just forgetting
to integrate the email part of the message as I do the merge).

But it's really not a huge deal and there are no really hard rules.

Sometimes there's no summary (particularly if there are just a couple
of things and a summary isn't needed and makes no sense), and
sometimes the summary is all there is (because the details are just
not interesting in themselves,and the summary explains the big picture
sufficiently).

And quite often, I and submaintainers have different ideas of what is
the really relevant part, and I edit things to what I think is more
readable anyway.

In fact, the biggest help is keeping the messages neutral wrt tense
and operaitons. Your merge message was great in that respect, and I
didn't have to edit it for silly details like I often do for merge
messages.

THAT is actually a small (and unimportant) pet peeve of mine: text
like "This pull request does..." may make sense in an email (because
the email *is* a pull request), but I feel it makes absolutely no
sense in a merge commit message (because at that point it is no longer
a pull request, and it no longer "does", it "did").

Using present tense - particularly in some common forms ("This does X,
fixing Y") just is something I try to avoid. Using present tense may
again make sense at the point it was written, but two years later it's
just odd. This is why I much prefer imperative voice (ie "Fix XYZ"),
because it's neutral.

Another thing I don't love is pointless "Five patches to do XYZ". That
"five patches" is not relevant in the big picture. What might be
relevant is "Clean up ABC in otder to fix XYZ", but not how many
patches it took.

And as I don't want those kinds of things to typically be part of the
merge message, and I end up editing that kind of verbiage away,

Unless I get bored and lazy - and admittedlly "lazy" is both my middle
name and my default state of being.

                Linus

Re: [GIT PULL] i2c for v7.3, part 2

[pr-tracker-bot]

The pull request you sent on Mon, 24 Aug 2026 13:55:39 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git tags/i2c-7.3-part2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/47096fc3d064a07c0842f748b99ebf01be120f2b

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html