Guilherme Giácomo Simões <trintaeoitogc@xxxxxxxxx> write:
>
> Bjorn Helgaas <helgaas@xxxxxxxxxx> writes:
> >
> > On Tue, Aug 06, 2024 at 05:54:15PM -0300, Guilherme Giácomo Simões wrote:
> > > Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx> 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.
> >
> > Bjorn
>
> Okay, then what the action that the drivers must be do when the add
> bridge is failed?
Maybe we can make a change to the drivers that use pci_hp_add_brigde() to
check the return of the function and return an error to its caller like this:
ret = pci_hp_add_bridge(dev);
if (ret)
goto out;
I have looked at all the drivers that use pci_hp_add_brigde() and they all have
an out flag to call pci_unlock_rescan_remove() to unlock the mutex and
return a code.
We can return in the out flag the code that is the return of
pci_hp_add_brigde() and
then we can set that return code to some #define to identify the error
that is returned.
