public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Guilherme Giácomo Simões" <trintaeoitogc@gmail.com>
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI: remove type return
Date: Fri, 9 Aug 2024 13:14:34 -0500	[thread overview]
Message-ID: <20240809181434.GA204249@bhelgaas> (raw)
In-Reply-To: <CAM_RzfYZLVTNgvML3OuBDoupcz4BxWHY3R1mUmVaskD5648x1A@mail.gmail.com>

On Thu, Aug 08, 2024 at 06:05:54PM -0300, Guilherme Giácomo Simões wrote:
> Bjorn Helgaas <helgaas@kernel.org> writes:
> >
> > On Tue, Aug 06, 2024 at 05:54:15PM -0300, Guilherme Giácomo Simões wrote:
> > > Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
> > > > On Sat, 3 Aug 2024, Guilherme Giacomo Simoes wrote:
> > > >
> > > > > I can see that the function pci_hp_add_brigde have a int return
> > > > > propagation.
> > > ...
> >
> > > > The lack of return value checking seems to be on the list in
> > > > pci_hp_add_bridge(). So perhaps the right course of action would be to
> > > > handle return values correctly.
> > >
> > > Ok, so if the right course is for the driver to handle return value,
> > > then this is a
> > > task for the driver developers, because only they know what to do when
> > > pci_hp_add_bridge() doesn't work correctly, right?
> >
> > pci_hp_add_bridge() is only for hotplug drivers, so the list of
> > callers is short and completely under our control.  There's plenty of
> > opportunity for improving this.  Beyond just the return value, all the
> > callers of pci_hp_add_bridge() should be doing much of the same work
> > that could potentially be factored out.
> 
> Okay, then what the action that the drivers must be do when the add
> bridge is failed?

pci_hp_add_bridge() fails when there's no bus number available to
assign to new hot-added devices.  When that happens, there's really
nothing the hotplug drivers can do to improve the situation.
pci_hp_add_bridge() already logs a message for one of the failure
cases.  It may be that it should also log a message for the other
failure case.  The end result is that we can't use the hot-added
devices because there's no space for them in the PCI bus number space,
so we can't address them.

Bjorn

      parent reply	other threads:[~2024-08-09 18:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-03 14:04 [PATCH] PCI: remove type return Guilherme Giacomo Simoes
2024-08-06 15:11 ` Ilpo Järvinen
2024-08-06 20:54   ` Guilherme Giácomo Simões
2024-08-06 21:36     ` Bjorn Helgaas
2024-08-08 21:05       ` Guilherme Giácomo Simões
2024-08-09 12:44         ` Guilherme Giácomo Simões
2024-08-09 18:14         ` Bjorn Helgaas [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=20240809181434.GA204249@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=trintaeoitogc@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