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
prev 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 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.