linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Gabor Juhos <j4g8y7@gmail.com>, Wolfram Sang <wsa@kernel.org>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Andi Shyti <andi.shyti@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
	Hanna Hawa <hhhawa@amazon.com>,
	Robert Marko <robert.marko@sartura.hr>,
	Linus Walleij <linus.walleij@linaro.org>,
	linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Imre Kaloz <kaloz@openwrt.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH v2 1/3] i2c: add init_recovery() callback
Date: Wed, 13 Aug 2025 16:23:04 +0100	[thread overview]
Message-ID: <aJyt2I1w6VYo1PPD@shell.armlinux.org.uk> (raw)
In-Reply-To: <aJpP5eABTYnQRV82@smile.fi.intel.com>

On Mon, Aug 11, 2025 at 11:17:41PM +0300, Andy Shevchenko wrote:
> On Mon, Aug 11, 2025 at 09:49:55PM +0200, Gabor Juhos wrote:
> > Add a new init_recovery() callback to struct 'i2c_bus_recovery_info'
> > and modify the i2c_init_recovery() function to call that if specified
> > instead of the generic i2c_gpio_init_recovery() function.
> > 
> > This allows controller drivers to skip calling the generic code by
> > implementing a dummy callback function, or alternatively to run a
> > fine tuned custom implementation.
> > 
> > This is needed for the 'i2c-pxa' driver in order to be able to fix
> > a long standing bug for which the fix will be implemented in a
> 
> > followup patch.
> 
> "...next change."
> 
> ...
> 
> The first traditional question is why the generic recovery is not working.

I opposed the conversion of my recovery code to generic recovery when
it was first mooted for this driver, and was over-ruled. Lo and behold,
as I predicted, generic recovery fails with i2c-pxa. I now don't
remember the details, but there has been a regression reported...

Given that I was over-ruled, I am not minded to go back and try and
find either the previous discussion (google can be exceedingly
difficult now to find such history) nor to try and work it out again
(I've other things, including meetings today.)

Nevertheless, all I now remember is that generic recovery breaks
i2c-pxa, whereas my recovery works.

If I had to guess, I suspect it's something to do with how careful I
was to ensure a glitchless transition between i2c mode and GPIO mode
on the pinmux, and the generic recovery probably isn't as careful, but
I could be wrong there.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

  parent reply	other threads:[~2025-08-13 15:23 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-11 19:49 [PATCH v2 0/3] i2c: pxa: fix I2C communication on Armada 3700 Gabor Juhos
2025-08-11 19:49 ` [PATCH v2 1/3] i2c: add init_recovery() callback Gabor Juhos
2025-08-11 20:17   ` Andy Shevchenko
2025-08-13 10:24     ` Gabor Juhos
2025-08-13 13:06       ` Andy Shevchenko
2025-08-13 14:51         ` Gabor Juhos
2025-08-13 15:23     ` Russell King (Oracle) [this message]
2025-08-11 19:49 ` [PATCH v2 2/3] i2c: pxa: prevent calling of the generic recovery init code Gabor Juhos
2025-08-11 20:26   ` Andy Shevchenko
2025-08-13 10:36     ` Gabor Juhos
2025-08-13 13:10       ` Andy Shevchenko
2025-08-13 15:17         ` Gabor Juhos
2025-08-13 15:28           ` Russell King (Oracle)
2025-08-17 14:59             ` Gabor Juhos
2025-08-17 15:53               ` Russell King (Oracle)
2025-08-19  8:07                 ` Gabor Juhos
2025-08-11 19:49 ` [PATCH v2 3/3] i2c: pxa: handle 'Early Bus Busy' condition on Armada 3700 Gabor Juhos
2025-08-11 20:31   ` Andy Shevchenko
2025-08-13 10:50     ` Gabor Juhos
2025-08-13 13:11       ` Andy Shevchenko
2025-08-13 15:19         ` Gabor Juhos
2025-08-11 20:12 ` [PATCH v2 0/3] i2c: pxa: fix I2C communication " Andy Shevchenko
2025-08-13 10:13   ` Gabor Juhos
2025-08-13 13:02     ` Andy Shevchenko
2025-08-13 14:50       ` Gabor Juhos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aJyt2I1w6VYo1PPD@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andi.shyti@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=hhhawa@amazon.com \
    --cc=j4g8y7@gmail.com \
    --cc=kaloz@openwrt.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robert.marko@sartura.hr \
    --cc=stable@vger.kernel.org \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=wsa@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).