mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lee Jones <lee@kernel.org>
To: Samuel Tirwa <samuel.tirwa@web.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] mfd: intel-lpss: fall back to polling when no usable IRQ
Date: Fri, 13 Nov 2026 19:35:57 +0000	[thread overview]
Message-ID: <179370025139.793788.5031830505403657514@kernel.org> (raw)
In-Reply-To: <20261103085954.1497-1-samuel.tirwa@web.de>

--- checkpatch.pl (1 issue) ---
Line 3: WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
----------------------------------

On Tue, 03 Nov 2026, Samuel Tirwa wrote:

> On platforms such as the HONOR MagicBook Pro 14 (2025) (Intel Core Ultra 9 285H)
> the firmware ACPI tables report the Intel LPSS I2C controllers' PCI INTx line as

These lines look excessively long.

> not connected (Interrupt Line = 0xff, GSI 255) and do not grant MSI control
> through _OSC.  As a result acpi_pci_irq_enable() sets dev->irq to
> IRQ_NOTCONNECTED and intel_lpss_probe() rejects it, so all three I2C
> controllers (8086:7778/7779/777a) fail to probe with -ENOTCONN and the
> touchpad/touchscreen are never exposed.
>
> Treat IRQ_NOTCONNECTED as 'no interrupt available' and pass 0 as the IRQ base
> to the child devices instead of failing.  The DesignWare I2C driver already
> supports a polling mode when no IRQ resource is present, which keeps the
> controllers functional on these firmwares.
>
> Signed-off-by: Samuel Tirwa <samuel.tirwa@web.de>
> ---
>  drivers/mfd/intel-lpss.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
> index f71e076..f785d5d 100644
> --- a/drivers/mfd/intel-lpss.c
> +++ b/drivers/mfd/intel-lpss.c
> @@ -1,5 +1,6 @@
>  #include <linux/mfd/core.h>
>  #include <linux/module.h>
> +#include <linux/interrupt.h>

Alphabetical.

>  int intel_lpss_probe(struct device *dev,
>                       const struct intel_lpss_platform_info *info)
> @@ -7,10 +8,17 @@ int intel_lpss_probe(struct device *dev,
>  	struct intel_lpss *lpss;
>  	int ret;
>
> -	if (!info || !info->mem || info->irq <= 0)
> +	if (!info || !info->mem)
>  		return -EINVAL;
>
> -	if (info->irq < 0)
> +	/*
> +	 * Firmware on some platforms (e.g. HONOR MagicBook Pro 14 2025)
> +	 * reports the LPSS PCI INTx line as not connected (IRQ_NOTCONNECTED).
> +	 * Fall back to polling mode in that case instead of failing probe.
> +	 */
> +	if (info->irq == IRQ_NOTCONNECTED)
> +		info->irq = 0;

Does this even compile?  Isn't 'info' declared 'const'?

Moreover, mfd_add_devices() inside intel_lpss_probe() passes 'info->irq' as
the 'irq_base' alongside a hardcoded 'n_resources = 2' on the 'mfd_cell'
definitions (which include DEFINE_RES_IRQ(0)).  Simply passing '0' as
'irq_base' does not omit the 'IORESOURCE_IRQ' resource - it just shifts the
child's IRQ resource to '0', whereas 'i2c-designware-platdrv' only enters
polling mode when 'platform_get_irq_optional()' returns '-ENXIO' (no IRQ
resource present), or should this be handled in the glue layer or by adjusting
how the cell resources are populated?

How was this tested?

> +	else if (info->irq < 0)
>  		return info->irq;
>
>  	lpss = devm_kzalloc(dev, sizeof(*lpss), GFP_KERNEL);
> -- 
> 2.56.0.windows.4
>

-- 
Lee Jones

  parent reply	other threads:[~2026-11-13 19:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03  8:59 Samuel Tirwa
2026-11-03  8:59 ` [PATCH 2/2] i2c: designware: use polling when IRQ resource is 0 Samuel Tirwa
2026-11-13 19:35 ` Lee Jones [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-11-03  8:57 [PATCH 1/2] mfd: intel-lpss: fall back to polling when no usable IRQ Samuel Tirwa

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=179370025139.793788.5031830505403657514@kernel.org \
    --to=lee@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=samuel.tirwa@web.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

all inboxes | Powered by JetHome®