On 27.09.19 15:42, Kyösti Mälkki wrote: > On Thu, Sep 26, 2019 at 7:45 PM Aaron Durbin <[email protected]> wrote: >> >> On Thu, Sep 26, 2019 at 10:06 AM Kyösti Mälkki <[email protected]> >> wrote: >>> Should be easy enough to implement >>> platform hook telling to not remove PCI device node from topology >>> links (based on BDF), even when it does not respond to ID queries.
For those who missed it: we already have a `hidden` keyword in sconfig which complements `on`/`off`. Currently it's only used to write static ACPI _STA methods. Maybe we could just use that? If a device is known to be hidden on purpose, don't detach it from the topology but report attempts to access PCI config? >> >> >> Yes, we can certainly do that. However, I also think this issue and yours >> and Nico's devicetree work are somewhat related as well as >> https://review.coreboot.org/c/coreboot/+/35621. > > I'll try to rebase all my work during the weekend> >> Here's some of the requirements/issues we should resolve that come to mind: >> >> 1. Easy way to directly retrieve a device's chip config object w/o >> traversing the device hierarchy. Which leads to... >> 2. Symbol alias for accessing struct device directly (no bdf lookup) More on this in a separate email. >> 3. Symbol alias for pci b/d/f lookup (equivalent of simple device but >> cleaner) so we can perform pci operations. IIRC, I asked this elsewhere already. Do we want to keep simple device? If we reduce `struct device` to b/d/f and a pointer to the chip info in early stages, couldn't we just use `struct device` for PCI config access everywhere? >> 4. possibly hidden pci devices >> >> Anything else I'm missing? I think a lot of the issues we're running into >> could be fixed w/ the above. Let me know what you think. >> > > 5. PCI coalesce can alter PCI dev.fn assignments? That's a serious problem. I noticed that CFL FSP can reassign them without being asked to, unpredictably (e.g. if a device fails to show up in whatever timeframe FSP assumes). Solution might be simple? A chip->enable_dev() that updates b/d/f based on DID? > 6. Devicetree in ENV SMM is problematic when chip config is mutable in > ENV_RAMSTAGE. Do we need chip config in SMM? Nico _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
