linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robert Richter <rric@kernel.org>
To: Dejin Zheng <zhengdejin5@gmail.com>
Cc: corbet@lwn.net, jarkko.nikula@linux.intel.com,
	andriy.shevchenko@linux.intel.com,
	mika.westerberg@linux.intel.com, bhelgaas@google.com,
	wsa@kernel.org, linux-doc@vger.kernel.org,
	linux-i2c@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/4] PCI: Introduce pcim_alloc_irq_vectors()
Date: Thu, 25 Feb 2021 10:33:53 +0100	[thread overview]
Message-ID: <YDdvAYLckBHi7qSe@rric.localdomain> (raw)
In-Reply-To: <20210223141435.GA912403@nuc8i5>

On 23.02.21 22:14:35, Dejin Zheng wrote:
> On Tue, Feb 23, 2021 at 09:02:54AM +0100, Robert Richter wrote:
> > On 22.02.21 23:14:15, Dejin Zheng wrote:
> > > On Mon, Feb 22, 2021 at 11:56:08AM +0100, Robert Richter wrote:
> > > > On 20.02.21 00:46:49, Dejin Zheng wrote:
> > > > > > On 18.02.21 23:04:55, Dejin Zheng wrote:
> > > > 
> > > > > > > +	if (!dr || !dr->enabled)
> > > > > here checks whether the pci device is enabled.
> > > > 
> > > > What is the purpose of this? The device "is_managed" or not.
> > > >
> > > The device is managed or not by check whether "dr" is NULL. And
> > > check the "dr->enabled" is for the PCI device enable. I think it
> > > may not make sense to apply for irq vectors when PCI device is not
> > > enabled.
> > 
> > I don't see how a disabled device affects in any way the release of
> > the irq vectors during device removal. dr is always non-null in case
> > the device is managed, a check isn't needed for that.
> >
> Yes, the disabled device does not affect release irq vectors, But
> the disabled device affects apply for irq vectors, It is wrong to apply
> for the irq vectors when the device is not enabled.

What is the scenario you have in mind here? What does happen then?
The typical use case is to pcim_enable_device() it and then add the
irq vectors. It is always enabled then.

Even if the device could wrongly be disabled, it does not affect the
device's release.

Also, how is this related to pcim? There isn't a check in
pci_alloc_irq_vectors() either for that case. 

> Add this check can
> facilitate developers to find problems as soon as possible.

No, there are many ways to shoot yourself in the foot. We cannot add
checks here and there for this, esp. at runtime. If there is a valid
reason that the device must always be enabled and we cannot assume
this is the case, then we could add a WARN_ON(). But I doubt that.

-Robert

  reply	other threads:[~2021-02-25  9:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-18 15:04 [PATCH v4 0/4] Introduce pcim_alloc_irq_vectors() Dejin Zheng
2021-02-18 15:04 ` [PATCH v4 1/4] PCI: " Dejin Zheng
2021-02-19 14:40   ` Robert Richter
2021-02-19 14:48     ` Robert Richter
2021-02-19 16:15       ` Krzysztof Wilczyński
2021-02-22 10:59         ` Robert Richter
2021-02-19 14:48     ` Andy Shevchenko
2021-02-19 15:01       ` Robert Richter
2021-02-19 16:46     ` Dejin Zheng
2021-02-22 10:56       ` Robert Richter
2021-02-22 15:14         ` Dejin Zheng
2021-02-23  8:02           ` Robert Richter
2021-02-23 14:14             ` Dejin Zheng
2021-02-25  9:33               ` Robert Richter [this message]
2021-02-26 15:22                 ` Dejin Zheng
2021-02-18 15:04 ` [PATCH v4 2/4] Documentation: devres: Add pcim_alloc_irq_vectors() Dejin Zheng
2021-02-18 15:04 ` [PATCH v4 3/4] i2c: designware: Use the correct name of device-managed function Dejin Zheng
2021-02-18 15:35   ` Andy Shevchenko
2021-02-18 15:04 ` [PATCH v4 4/4] i2c: thunderx: " Dejin Zheng
2021-02-19 15:45   ` Robert Richter

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=YDdvAYLckBHi7qSe@rric.localdomain \
    --to=rric@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=corbet@lwn.net \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=wsa@kernel.org \
    --cc=zhengdejin5@gmail.com \
    /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).