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

[ron minnich]

On Thu, May 8, 2008 at 9:15 AM, Carl-Daniel Hailfinger
>> Disabling the device means we disable its memory and io space.
>>
>
> But it can still do DMA and issue IRQs, right?

not dma unless bus master is set, and no BIOS should ever set that
(but I bet EFI does as it has drivers ...)

>
> Also, does disabling memory and IO space set a special "disabled" flag
> or do we simply set each resource with a size of zero?

no, what should happen is you allocate the BARs but don't enable it.
Many OSes can re-enable a disabled device, but the can't handle BARs
with a value of 0.

>
>> Hiding the device means we disable its config space.
>>
>> So with any of the three resource types disabled, the device is not
>> really usable. They're just decoded differently.
>>
>
> not usable != disabled.

if the device is disabled, the OS can re-enable it. I've actually
re-enabled disabled bridges via setpci, for example. If the device is
hidden, the OS can do nothing to get to it.


>> absolutely. If you have a special disable function, you will also need a
>> special enable function. But that won't happen, as you don't re-enable a
>> device that you disabled on purpose.
>>
>
> Do we need special per-device functions for en-/disabling or is this
> doable with a generic PCI function?

Not quite! You can re-enable any disabled device with setpci -- I've
done it. But you can't re-enable a hidden device -- pci can't see it.

> Well, if you can hide a device, can it issue IRQs or perform DMA on its
> own initiative?

IRQs -- unclear. That's a little tricky. DMA, no, BUSMASTERing won't
be set for one thing.

I think if we add to many states we're going to be in PCI hell. Let's
be careful.

>
>> untouched is not an option we provided at any time before, but basically
>> it implies disabled, too.
>>
>
> I still think untouched could be useful. For one, it would allow us to
> minimize setup during early porting and we could do the rest of the
> setup from a network-loaded payload. That's not neccessary if you have a
> ROM emulator, but a big plus for those developers without one.
>


interesting idea but you have to make sure you know the implications
of this for bridges, etc. etc.

And if you don't allocate BARs, and the system comes up, you may find
there is no way to allocate the address space for the BARs -- there
may not be room. This happened on more than one occasion with, e.g.,
Quadrics.

ron