[PATCH v5 10/29] pci: Adjust dm_pci_read_bar32() to return errors correctly

[Simon Glass]

Hi,

On Thu, 9 Apr 2020 at 03:39, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>
> > From: Andy Shevchenko <andy.shevchenko at gmail.com>
> > Date: Thu, 9 Apr 2020 12:06:11 +0300
> >
> > On Thu, Apr 9, 2020 at 2:00 AM Simon Glass <sjg at chromium.org> wrote:
> > >
> > > At present if reading a BAR returns 0xffffffff (e.g. the device is not
> > > present) then the value is masked and a different value is returned.
> > > This makes it harder to detect the problem when debugging.
> >
> > If you insisting on the code, you may need to reword the commit
> > message, at least by removing ambiguous "device not present", because
> > this is not how PCI spec defines situations when device is not
> > present.
>
> In addition to that:
>
> The 0xffffffff value is an artifact of how x86 systems handle aborted
> PCI transactions.  Other architectures will probably generate a fault
> of some sorts.  It looks like at least some of the pci drivers in
> u-boot emulate the x86 behaviour but I'm not sure all of them do.

This is not intended to be used to detect missing devices. It's just
that we should not be masking an obviously invalid value, to make it
look more valid. It is very confusing.

I'll update the comment message.

Regards,
Simon