From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Chen Ni <nichen@iscas.ac.cn>,
lee@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mfd: intel-lpss: Fix IRQ check
Date: Fri, 3 Nov 2023 08:41:40 +0200 [thread overview]
Message-ID: <20231103064140.GP17433@black.fi.intel.com> (raw)
In-Reply-To: <ZUOYR1l9D5s3bI37@smile.fi.intel.com>
On Thu, Nov 02, 2023 at 02:38:31PM +0200, Andy Shevchenko wrote:
> > > > > - if (!info || !info->mem || info->irq <= 0)
> > > > > + if (!info || !info->mem)
> > > >
> > > > This check (info->irq <= 0) covers both "invalid" interrupt numbers
> > > > (that's the negative errno and 0 as no interrupt) so I don't see how
> > > > this change makes it any better and the changelog does not clarify it
> > > > either.
> > >
> > > It makes sense. The IRQ here may not be 0. We should actually fix
> > > the PCI code to guarantee that (platform_get_irq() guarantees that
> > > in platform driver).
> >
> > Yeah but I mean the check above handles any "invalid" interrupt number
> > just fine regardless. I don't see any point changing that.
>
> The point is to have proper error code to be returned. Currently it's shadowed
> in this check.
Looking at this more, this patch actually introduces a bug.
We pass pci_dev->irq from intel-lpss-pci.c and that comes directly from
PCI core that assigns it in pci_read_irq(). This value is unsigned int
for starters so it is not designed to contain an error code, secondly it
can be 0 meaning "no IRQ" either if is SRIOV device or the interrupt
line is not assigned. I actually think SRIOV is a possibility for future
LPSS devices so we should be dealing with this properly.
next prev parent reply other threads:[~2023-11-03 6:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-01 6:26 [PATCH v2] mfd: intel-lpss: Fix IRQ check Chen Ni
2023-11-01 7:03 ` Mika Westerberg
2023-11-01 9:38 ` Andy Shevchenko
2023-11-01 9:42 ` Andy Shevchenko
2023-11-01 10:47 ` Mika Westerberg
2023-11-02 12:38 ` Andy Shevchenko
2023-11-03 6:41 ` Mika Westerberg [this message]
2023-11-03 14:58 ` 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=20231103064140.GP17433@black.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nichen@iscas.ac.cn \
/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.