On Wed, Sep 8, 2021 at 8:02 PM Marek Behún <ka...@kernel.org> wrote: > > On Wed, 8 Sep 2021 09:06:28 +0800 > Bin Meng <bmeng...@gmail.com> wrote: > > > On Wed, Sep 8, 2021 at 12:07 AM Marek Behún <marek.be...@nic.cz> > > wrote: > > > > > > From: Pali Rohár <p...@kernel.org> > > > > > > Some PCIe controller's read_config() method support indicating error > > > directly via return value, but some cannot distinguish all-ones (or > > > all-zeros) read response from an error. > > > > > > The current code in pci_bind_bus_devices() interprets all-ones / > > > all-zeros in PCI_VENDOR_ID register as "nothing connected", and > > > continues the cycle, but an error returned via return value breaks > > > the cycle. > > > > > > This is wrong for the PCIe controllers which return this error via > > > return value. > > > > > > Handle all errors when reading PCI_VENDOR_ID the same way. > > > > > > This fixes enumeration of PCI devices for example when there is a > > > PCI bridge connected behind another PCI bridge and not all ports are > > > connected to a device, and the controller (for example Aardvark) > > > translates the UR error (Unsupported Request) as -EOPNOTSUPP. > > > > > > Signed-off-by: Pali Rohár <p...@kernel.org> > > > Signed-off-by: Marek Behún <marek.be...@nic.cz> > > > --- > > > drivers/pci/pci-uclass.c | 9 +-------- > > > 1 file changed, 1 insertion(+), 8 deletions(-) > > > > > > > Is it possible to update these PCI controller drivers to fill in > > vendor id to all zeros when there is an errror? > > It is, but we think it is wrong. If the PCI controller supports > reporting errors, they should be propagated. > > What we might want to change in those controller drivers, though, is > error numbers, so that they are the same for each controller. For > example Unsupported Request should be always translated to EOPNOTSUPP.
So if it is a real error that for some reason the controller cannot read the configuration space, we should abort instead of continue looping. Not sure what is the best approach though. FWIW, Reviewed-by: Bin Meng <bmeng...@gmail.com>