linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "andriy.shevchenko" <andriy.shevchenko@linux.intel.com>
To: 黄碧波 <huangbibo@uniontech.com>
Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	linux-i2c <linux-i2c@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"mika.westerberg" <mika.westerberg@linux.intel.com>,
	"p.zabel" <p.zabel@pengutronix.de>
Subject: Re: [PATCH] i2c: designware: I2C unexpected interrupt handling will cause kernel panic
Date: Fri, 12 Nov 2021 12:26:14 +0200	[thread overview]
Message-ID: <YY5BRrE8bLyvd3PB@smile.fi.intel.com> (raw)
In-Reply-To: <tencent_48E4F3B231317FCA25752384@qq.com>

On Fri, Nov 12, 2021 at 03:35:07AM +0000, 黄碧波 wrote:
> Hi Andy,

First of all, please fix your email client (it mangled the message
in a bad way) and do not top post!

> This patch is to make the kernel more stable &amp; stronger,
> Even if there is an unexpected I2C interrupt, kernel will not crash

As far as I can see this is, as Jarkko said, the change to hide the real issue.

> Let me elaborate on this issue:
> The BIOS support EFI RTC feature and add the I2C bus descr in the ACPI table (RTC chip is connected to I2C bus), The OS matches and registers the I2C bus driver.
> 
> When OS get RTC time by BIOS interface (Runtime Server), crash occurs.
> The&nbsp; BIOS interface direct acces registers to sends and receives data, which conflicts with the&nbsp; I2C driver
> 
> This is a BIOS error and the root cause of this issue. The final solution is to delete the I2C device node in the ACPI table

Oh, yeah, yet another brain damaged design. If somebody wants to have driver of
the I²C peripheral in the ASL, it's not gonna work in Linux (in 99.99% cases).

What you should do is go and fix BIOS that it won't do two things together, i.e.
ASL based driver and exposure of I²C host controller in ACPI.

On the constructive way, you need to use DMI quirks and somehow make EFI and
I²C code to be communicating nicely in the kernel.

The patch makes no sense to me, the problem is obviously somewhere else.

NAK.

> &nbsp;
> &nbsp;
> ------------------&nbsp;Original&nbsp;------------------
> From: &nbsp;"Jarkko Nikula"<jarkko.nikula@linux.intel.com&gt;;
> Date: &nbsp;Thu, Nov 11, 2021 02:06 PM
> To: &nbsp;"huangbibo"<huangbibo@uniontech.com&gt;; "linux-i2c"<linux-i2c@vger.kernel.org&gt;; 
> Cc: &nbsp;"linux-kernel"<linux-kernel@vger.kernel.org&gt;; "mika.westerberg"<mika.westerberg@linux.intel.com&gt;; "andriy.shevchenko"<andriy.shevchenko@linux.intel.com&gt;; "p.zabel"<p.zabel@pengutronix.de&gt;; 
> Subject: &nbsp;Re: [PATCH] i2c: designware: I2C unexpected interrupt handling will cause kernel panic
> 
> &nbsp;
> 
> Hi
> 
> On 11/11/21 8:57 AM, huangbibo wrote:
> &gt; I2C interrupts may be triggered unexpectedly,
> &gt; such as programs that directly access I2C registers,
> &gt; bus conflicts caused by hardware design defects, etc.
> &gt; These can cause null pointer reference errors and kernel panic.
> &gt; 
> &gt; kernel log:
> &gt; [&nbsp;&nbsp; 52.676442] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> &gt; ...
> &gt; [&nbsp;&nbsp; 52.816536] Workqueue: efi_rts_wq efi_call_rts
> &gt; [&nbsp;&nbsp; 52.820968] pstate: 60000085 (nZCv daIf -PAN -UAO)
> &gt; [&nbsp;&nbsp; 52.825753] pc : i2c_dw_isr+0x36c/0x5e0 [i2c_designware_core]
> &gt; [&nbsp;&nbsp; 52.831487] lr : i2c_dw_isr+0x88/0x5e0 [i2c_designware_core]
> &gt; [&nbsp;&nbsp; 52.837134] sp : ffff8020fff17650
> &gt; [&nbsp;&nbsp; 52.924451] Call trace:
> &gt; [&nbsp;&nbsp; 52.926888]&nbsp; i2c_dw_isr+0x36c/0x5e0 [i2c_designware_core]
> &gt; ...
> &gt; [&nbsp;&nbsp; 52.957394]&nbsp; gic_handle_irq+0x7c/0x178
> &gt; [&nbsp;&nbsp; 52.961130]&nbsp; el1_irq+0xb0/0x140
> &gt; [&nbsp;&nbsp; 52.964259]&nbsp; 0x21291d30
> &gt; [&nbsp;&nbsp; 52.983729]&nbsp; 0x21160938
> &gt; [&nbsp;&nbsp; 52.986164]&nbsp; __efi_rt_asm_wrapper+0x28/0x44
> &gt; [&nbsp;&nbsp; 52.990335]&nbsp; efi_call_rts+0x78/0x448
> &gt; [&nbsp;&nbsp; 53.019021] Kernel panic - not syncing: Fatal exception in interrupt

-- 
With Best Regards,
Andy Shevchenko



  parent reply	other threads:[~2021-11-12 10:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11  6:57 [PATCH] i2c: designware: I2C unexpected interrupt handling will cause kernel panic huangbibo
2021-11-11 14:05 ` Jarkko Nikula
     [not found]   ` <tencent_48E4F3B231317FCA25752384@qq.com>
2021-11-12 10:26     ` andriy.shevchenko [this message]
2021-11-11 16:13 ` Andy Shevchenko

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=YY5BRrE8bLyvd3PB@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=huangbibo@uniontech.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=p.zabel@pengutronix.de \
    /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).