[OpenBIOS] r505 - trunk/openbios-devel/drivers

[Blue Swirl]

On 7/5/09, Igor Kovalenko <igor.v.kovalenko at gmail.com> wrote:
> On Mon, Jul 6, 2009 at 12:09 AM, Blue Swirl<blauwirbel at gmail.com> wrote:
>  > On 7/5/09, Igor Kovalenko <igor.v.kovalenko at gmail.com> wrote:
>  >> On Sun, Jul 5, 2009 at 10:32 PM, <svn at openbios.org> wrote:
>  >>  > Author: blueswirl
>  >>  > Date: 2009-07-05 20:32:50 +0200 (Sun, 05 Jul 2009)
>  >>  > New Revision: 505
>  >>  >
>  >>  > Modified:
>  >>  >   trunk/openbios-devel/drivers/pci.c
>  >>  > Log:
>  >>  > Don't try to configure non-existent BARs of bridge devices
>  >>  >
>  >>  > QEMU commit b7ee1603c16c1feb0d439d2ddf6cf824119d0aab improved the PCI bridge
>  >>  > device handling. PCI bridges use different header format from ordinary PCI
>  >>  > devices, especially BAR registers do not exist. OpenBIOS tried to configure
>  >>  > the bridges based on the non-BAR data which was assumed to be BARs.
>  >>
>  >>
>  >> I stumbled across this as well. My solution was inspired by linux
>  >>  code, please see
>  >>  attached sparc64-pci-bridge patch. The difference is actually small. Added value
>  >>  is dealing with ROM bars in other header type, also irq setup function and
>  >>  pci bar setup function are extracted.
>  >>
>  >>  This patch is against r504. In case this looks better here is my sign-off
>  >>
>  >>  Signed-off-by: igor.v.kovalenko at gmail.com
>  >
>  > Yes, it looks like an improvement. Shouldn't the bridge check also
>  > check the subclass? Otherwise EBUS BARs would not handled like they
>  > should.
>
>
> I think header type matters. Maybe it is just wrong for qemu ebus bridge.

No, but APB should have a bridge header type. Then the check could be
just for header type, unless that breaks other architectures.