Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Gabor Juhos <j4g8y7@gmail.com>
Cc: Wolfram Sang <wsa@kernel.org>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Andi Shyti <andi.shyti@kernel.org>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	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 2/3] i2c: pxa: prevent calling of the generic recovery init code
Date: Wed, 13 Aug 2025 16:10:19 +0300	[thread overview]
Message-ID: <aJyOu_GUlDPuJXO5@smile.fi.intel.com> (raw)
In-Reply-To: <8cb62eb9-9137-44b4-86f6-82f69813e83f@gmail.com>

On Wed, Aug 13, 2025 at 12:36:45PM +0200, Gabor Juhos wrote:
> 2025. 08. 11. 22:26 keltezéssel, Andy Shevchenko írta:
> > On Mon, Aug 11, 2025 at 09:49:56PM +0200, Gabor Juhos wrote:

...

> > TBH this sounds to me like trying to hack the solution and as you pointed out
> > the problem is in pinctrl state changes. I think it may affect not only I2C case.
> 
> It is not an error in the pinctrl code. I have checked and even fixed a few bugs
> in that.
> 
> > And I didn't get how recovery code affects the initialisation (enumeration).
> 
> Without the fix, it is not possible to initiate a transaction on the bus, which
> in turn prevents enumeration.

But why? As you said below the first pin control state is changed during the
probe, which is fine, and the culprit one happens on the recovery. Why is
recovery involved in probe? This is quite confusing...

> > Do we set pin control state back and forth during probe? May be this is a root cause?
> 
> Yes, basically. The state gets changed back and forth twice. Once in driver
> probe before the controller gets initialized, then once again in
> i2c_gpio_init_generic_recovery(). The problem is caused by the second state
> change as it runs after the controller gets enabled which confuses the hardware.

...

> >>  static int i2c_pxa_init_recovery(struct pxa_i2c *i2c)
> >>  {
> >>  	struct i2c_bus_recovery_info *bri = &i2c->recovery;
> > 
> >>  		return 0;
> >>  	}
> >>  
> >> +	bri->init_recovery = i2c_pxa_init_recovery_cb;
> > 
> > This is unfortunate. I would keep the naming schema consistent, i.e. rename
> > existing function and use its original name for the new callback.
> 
> I agree, but since the change is targeted also to stable kernels, I wanted to
> keep the change as minimal as possible.

Renaming is not a big deal AFAICS, but leaving this _cb will be confusing in a
long term. I prefer name to be changed.

> >>  	bri->prepare_recovery = i2c_pxa_prepare_recovery;
> >>  	bri->unprepare_recovery = i2c_pxa_unprepare_recovery;
> >>  	bri->recover_bus = i2c_generic_scl_recovery;

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2025-08-13 13:10 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)
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 [this message]
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=aJyOu_GUlDPuJXO5@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=andi.shyti@kernel.org \
    --cc=andrew@lunn.ch \
    --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=rmk+kernel@armlinux.org.uk \
    --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