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

Mark Kettenis mark.kettenis at xs4all.nl
Thu Apr 9 11:38:56 CEST 2020


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


More information about the U-Boot mailing list