[coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead

[Stefan Reinauer]

ron minnich wrote:
> On Thu, May 8, 2008 at 7:51 AM, Stefan Reinauer <stepan at coresystems.de> wrote:
>
>   
> > > in some cases we actually have to allocate the BARs and so on and
> > > leave it disabled -- we don't know if the OS wants it, but if the OS
> > > wants it, it has to work. This is one of the less intuitive bits of
> > > the device bringup process.
>> Which device is that?
>>     
>
> Almost all of them. Consider a bridge.
>
>   
I still think a bridge that gets disabled in Config.lb or the dts should
not be set up. Otherwise it might be bridging, which would really not be
what we want if we disable the device.

I can't find any bridge in v2 from a quick scan that would stay un-enabled.

If we don't know whether the OS wants the device, we enable it, not
leave it or disable it.

We disable or hide the device, if that functionality is not there on the
_board_, ie. because it is not wired.

If we start thinking about what the OS wants in this context, we have to
call this ACPI and make distinctions between OSes in the DTS. ;-)

>> What does pci xx.x off end do then?
>>     
> in v2, it means that in the init function, the CMD register is
> un-enabled (I think; I have not looked at this code for a bit and it
> always confuses me).
>
> Look in pci_probe_dev for example: device is unconditionally enabled,
> so we can scan it.
>
> IIRC one case that drove this was multiple VGA cards -- you want to
> set up the BARs etc. for all but you really don't know what the OS
> will do -- maybe nothing -- but you want them there if it will do
> something.
>   
Unless the bios disables one of the devices, in which case the OS should
find nothing.

> There really is a difference between un-enabled (or disabled) and
> hidden; as you pointed out, hidden means no config space, or "will not
> show up in lspci".
>   
So disabled devices do show up in lspci?