All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Nikula <jarkko.nikula@linux.intel.com>
To: Kim Phillips <kim.phillips@amd.com>, linux-i2c@vger.kernel.org
Cc: Wolfram Sang <wsa@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Jan Dabros <jsd@semihalf.com>, Andi Shyti <andi.shyti@kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	V Narasimhan <Narasimhan.V@amd.com>
Subject: Re: [PATCH] i2c: designware: Revert recent changes to i2c_dw_probe_lock_support()
Date: Tue, 16 Jan 2024 10:15:25 +0200	[thread overview]
Message-ID: <f4b3cc62-8620-4810-97f7-bcc39220b12e@linux.intel.com> (raw)
In-Reply-To: <00f98ff9-ce2f-4edd-b4e4-a17e1a0170cd@amd.com>

On 1/16/24 00:44, Kim Phillips wrote:
> On 1/15/24 3:16 PM, Kim Phillips wrote:
>> On 1/12/24 2:13 AM, Jarkko Nikula wrote:
>>> On 1/11/24 19:56, Kim Phillips wrote:
>>>>> [    6.245173] i2c_designware AMDI0010:00: Unknown Synopsys 
>>>>> component type: 0xffffffff
>>>
>>> This has puzzled me all the time since I'm unable to see which one of 
>>> Andy's patches could cause it. However controller is clearly powered 
>>> down since DW_IC_COMP_TYPE register reads 0xffffffff.
> 
> Just FYI, that message is apparently 'normal' as, e.g., a stable v6.4
> based tree emits it, but it doesn't crash because of it:
> 
Ah, makes sense. I understood from Narasimhan's earlier mail vanilla 
doesn't show it and that made me confused.

> So I just tested checking out bd466a892612, and indeed it produces
> the stacktrace.  Prior to that commit is v6.7-rc3, which boots fine.
> So right now I'm suspecting bd466a892612 is to blame for the stacktrace.
> 
This also makes most sense to me and was my first guess. I let Andy to 
look at more deeply does my speculation about runtime PM being active in 
parallel with post probe code since before his commit driver disabled 
the runtime PM before returning from probe.

Now if after that commit oops doesn't occur always it will easily 
misguide in bisecting and can lead to random results. Those are very 
hard to track sometimes. Good that you found this issue very immediately 
when code went to linux-next!

      reply	other threads:[~2024-01-16  8:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-11 12:56 [PATCH] i2c: designware: Revert recent changes to i2c_dw_probe_lock_support() Jarkko Nikula
2024-01-11 17:56 ` Kim Phillips
2024-01-12  8:13   ` Jarkko Nikula
2024-01-13 19:26     ` Wolfram Sang
2024-01-14 17:06       ` Andy Shevchenko
2024-01-15  6:58         ` Jarkko Nikula
2024-01-15 21:16     ` Kim Phillips
2024-01-15 22:44       ` Kim Phillips
2024-01-16  8:15         ` Jarkko Nikula [this message]

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=f4b3cc62-8620-4810-97f7-bcc39220b12e@linux.intel.com \
    --to=jarkko.nikula@linux.intel.com \
    --cc=Narasimhan.V@amd.com \
    --cc=andi.shyti@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=jsd@semihalf.com \
    --cc=kim.phillips@amd.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.