Commit 903b40a [soc/intel: Replace uses of dev_find_slot()] replaced calls to dev_find_slot() with calls to pcidev_path_on_root() for all Intel common SoCs, but it seems unclear exactly what problem this was intended to fix, and has created problems with locating hidden PCI devices.
Commit f2ac0137 [soc/intel: Fix regression with hidden PCI devices] fixed this partially by creating a debug version of pcidev_path_on_root() which falls back on dev_find_slot(), but did not apply it to all devices which need it. On SKL/KBL alone, there are at least 5 different function calls accessing a dozen PCI devices which require falling back on dev_find_slot().
Kyosti has expressed a desire to eliminate the use of dev_find_slot() since it can potentially return false positives prior to device enumeration in ramstage, but as currently implemented the cure seems worse than the disease.
Short term, it seems like having pcidev_path_on_root() fall back on dev_find_slot() with a loud warning (like pcidev_path_on_root_debug() does now) makes the most sense, vs having two nearly identical function calls used inconsistently. Long term, we need a better strategy for dealing with PCI devices which get hidden by FSP / are in violation of PCI spec.
But since discussion on Gerrit seems to have died, reviving it here for a larger audience.
cheers, Matt
Hi Matt,
thanks for bringing the topic up. Please also contact your Intel reps about this via commercial support channel as well. I believe Patrick G. once stated that he could act as a relay when it comes to disputes between commercial and community development 'strategies'.
On Wed, Sep 25, 2019 at 8:48 PM Matt DeVillier matt.devillier@gmail.com wrote:
Commit 903b40a [soc/intel: Replace uses of dev_find_slot()] replaced calls to dev_find_slot() with calls to pcidev_path_on_root() for all Intel common SoCs, but it seems unclear exactly what problem this was intended to fix, and has created problems with locating hidden PCI devices.
I believe [1] commit explains dev_find_slot() with enough details.
Commit f2ac0137 [soc/intel: Fix regression with hidden PCI devices] fixed this partially by creating a debug version of pcidev_path_on_root() which falls back on dev_find_slot(), but did not apply it to all devices which need it. On SKL/KBL alone, there are at least 5 different function calls accessing a dozen PCI devices which require falling back on dev_find_slot().
Kyosti has expressed a desire to eliminate the use of dev_find_slot() since it can potentially return false positives prior to device enumeration in ramstage, but as currently implemented the cure seems worse than the disease.
Short term, it seems like having pcidev_path_on_root() fall back on dev_find_slot() with a loud warning (like pcidev_path_on_root_debug() does now) makes the most sense, vs having two nearly identical function calls used inconsistently. Long term, we need a better strategy for dealing with PCI devices which get hidden by FSP / are in violation of PCI spec.
But since discussion on Gerrit seems to have died, reviving it here for a larger audience.
I will quote below what I already wrote in gerrit [2], [3]:
The trouble is the entire PCI subsystem in ramstage is based on matching the vendor/device ID register with a PCI driver and to the source we want to control that device with. To allow this hiding of PCI devices will ultimately force us to write the control somewhere in the scope of SOC instead. Oh, but wait, perhaps the intention is for us to __not__ write that control anymore but let the FSP blob do all that too!
AFAICS, hardware that does not respond to vendor/device ID register reads does not meet PCI compliance. I am willing to hit +2 on removing support for platforms that do not meet PCI compliance, specially when in the cases here, it is a matter of broken FSP blobs and not broken silicon per-se.
Also, I should not be accepting new callers for dev_find_slot() due the ill semantics it has. Prior to device enumeration, it can return false positives because all devices appear on bus 0. So please look for alternative solution if you want to support Intel's initiative of more blob less FOSS.
I suggest you post on the mailing list. That active PCI devices no longer respond to Vendor ID / Device ID queries does not meet PCI compliance, as I understand the specs. Unfortunately, someone with enough authority inside the org will likely decide it's just fine that ramstage will no longer be designed using PCI drivers and allow use of shim calling massive FSP blob.
As for solutions:
Preferably fix FSP and not allow this PCI hide-and-seek.
or
Rewrite PCI device enumeration such that devices that do not respond to ID queries are not permanently removed from topology links. You need platform hooks to decide whether to remove a particular device (based on B:D.F) or not. This would avoid ill dev_find_slot() then.
or
Revert to __SIMPLE_DEVICE__ for PCI access. But __SIMPLE_DEVICE__ is also on my kill list due to uglyness and high maintenance whenever we attempt to move sources to earlier stages. Unfortunately things found in soc/intel has slowed down the process to standstill and work is not funded.
[1] https://review.coreboot.org/c/coreboot/+/26447 [2] https://review.coreboot.org/c/coreboot/+/35087 [3] https://review.coreboot.org/c/coreboot/+/35088
Regards, Kyösti Mälkki
Kyösti Mälkki:
Preferably fix FSP and not allow this PCI hide-and-seek.
Only for my own education, is that related to https://www.spinics.net/lists/kernel/msg2709360.html?
On Thu, Sep 26, 2019 at 8:51 AM Kyösti Mälkki kyosti.malkki@gmail.com wrote:
Hi Matt,
thanks for bringing the topic up. Please also contact your Intel reps about this via commercial support channel as well. I believe Patrick G. once stated that he could act as a relay when it comes to disputes between commercial and community development 'strategies'.
On Wed, Sep 25, 2019 at 8:48 PM Matt DeVillier matt.devillier@gmail.com wrote:
Commit 903b40a [soc/intel: Replace uses of dev_find_slot()] replaced
calls to dev_find_slot() with calls to pcidev_path_on_root() for all Intel common SoCs, but it seems unclear exactly what problem this was intended to fix, and has created problems with locating hidden PCI devices.
I believe [1] commit explains dev_find_slot() with enough details.
Commit f2ac0137 [soc/intel: Fix regression with hidden PCI devices]
fixed this partially by creating a debug version of pcidev_path_on_root() which falls back on dev_find_slot(), but did not apply it to all devices which need it. On SKL/KBL alone, there are at least 5 different function calls accessing a dozen PCI devices which require falling back on dev_find_slot().
Kyosti has expressed a desire to eliminate the use of dev_find_slot()
since it can potentially return false positives prior to device enumeration in ramstage, but as currently implemented the cure seems worse than the disease.
Short term, it seems like having pcidev_path_on_root() fall back on
dev_find_slot() with a loud warning (like pcidev_path_on_root_debug() does now) makes the most sense, vs having two nearly identical function calls used inconsistently. Long term, we need a better strategy for dealing with PCI devices which get hidden by FSP / are in violation of PCI spec.
But since discussion on Gerrit seems to have died, reviving it here for
a larger audience.
I just noticed these commits and have commented there. :)
I will quote below what I already wrote in gerrit [2], [3]:
The trouble is the entire PCI subsystem in ramstage is based on matching the vendor/device ID register with a PCI driver and to the source we want to control that device with. To allow this hiding of PCI devices will ultimately force us to write the control somewhere in the scope of SOC instead. Oh, but wait, perhaps the intention is for us to __not__ write that control anymore but let the FSP blob do all that too!
I think we can provide a semantic of "possibly hidden" devices and provide operations which do the correct thing provided the platform constraints. I do want to understand the complete problem, though.
My current understanding is that we're forcing a device to be unhidden after a sequence we know that hides a particular device. And we're attempting to put it back to hidden permanently because of policy enforced by a silicon vendor. However, if an access comes after the hide sequence we trip over the NULL check if the device was removed from the topology. What I couldn't figure out was what caused the need for f2ac0137? p2sb was working still? The commits don't have more information as to the circumstances of the failure.
AFAICS, hardware that does not respond to vendor/device ID register reads does not meet PCI compliance. I am willing to hit +2 on removing support for platforms that do not meet PCI compliance, specially when in the cases here, it is a matter of broken FSP blobs and not broken silicon per-se.
I'm not in agreement on the policies/thinking from all the hardware vendors. Many issues have arisen in not thinking through pci dev/fun allocation. e.g. function 0 can be hidden but functions >1 should be around. Definitely a violation of PCI spec and many things have been worked around that.
That said, computer architecture/design is messy, and I think it's naive to think everything is spec compliant. There are complex fabrics and fabric policies in all these devices that are utilized to provide a "pci". And as firmware people we need to deal with the realities of the hardware. That's pretty much the point of firmware: prepare the abstractions for the OS to make those assumptions of aligning with specs. Even then, some things just can't be fixed (check out all the quirks and layering violations in the drivers).
Also, I should not be accepting new callers for dev_find_slot() due the ill semantics it has. Prior to device enumeration, it can return false positives because all devices appear on bus 0. So please look for alternative solution if you want to support Intel's initiative of more blob less FOSS.
dev_find_slot() failures have nothing to do with blobs or not. Certainly, some of the circumstances have tripped up some of the assumptions made in that code. And I agree we should move away from using that API and/or removing it.
I suggest you post on the mailing list. That active PCI devices no longer respond to Vendor ID / Device ID queries does not meet PCI compliance, as I understand the specs. Unfortunately, someone with enough authority inside the org will likely decide it's just fine that ramstage will no longer be designed using PCI drivers and allow use of shim calling massive FSP blob.
As for solutions:
Preferably fix FSP and not allow this PCI hide-and-seek.
or
Rewrite PCI device enumeration such that devices that do not respond to ID queries are not permanently removed from topology links. You
I thought that the devices being removed was part of the original problem?
need platform hooks to decide whether to remove a particular device (based on B:D.F) or not. This would avoid ill dev_find_slot() then.
I have some ideas on some solutions, but I want to understand the failure that occurred after 903b40a.
or
Revert to __SIMPLE_DEVICE__ for PCI access. But __SIMPLE_DEVICE__ is also on my kill list due to uglyness and high maintenance whenever we attempt to move sources to earlier stages. Unfortunately things found in soc/intel has slowed down the process to standstill and work is not funded.
[1] https://review.coreboot.org/c/coreboot/+/26447 [2] https://review.coreboot.org/c/coreboot/+/35087 [3] https://review.coreboot.org/c/coreboot/+/35088
Regards, Kyösti Mälkki _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
In a nutshell:
The implementation of dev_find_slot() traverses the linked list of all devices in the devicetree, regardless of the topology. Since PCI bus numbers are only assigned in early ramstage, this function is not a reliable API. Furthermore, referencing (dynamically) assigned PCI busses by integers (>1) is also prone to errors as insertion of PCIe add-on cards will shift these.
Now.. during PCI enumeration, missing static devices are only removed from the PCI topology links, not the 'linked list of all devices' that dev_find_slot(). AFAICS, this is the root cause why pcidev_on_root() caused regressions with 903b40a. 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.
Kyösti
On Thu, Sep 26, 2019 at 10:06 AM Kyösti Mälkki kyosti.malkki@gmail.com wrote:
In a nutshell:
The implementation of dev_find_slot() traverses the linked list of all devices in the devicetree, regardless of the topology. Since PCI bus numbers are only assigned in early ramstage, this function is not a reliable API. Furthermore, referencing (dynamically) assigned PCI busses by integers (>1) is also prone to errors as insertion of PCIe add-on cards will shift these.
Now.. during PCI enumeration, missing static devices are only removed from the PCI topology links, not the 'linked list of all devices' that dev_find_slot(). AFAICS, this is the root cause why pcidev_on_root() caused regressions with 903b40a. 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.
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.
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) 3. Symbol alias for pci b/d/f lookup (equivalent of simple device but cleaner) so we can perform pci operations. 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.
Kyösti
On Thu, Sep 26, 2019 at 7:45 PM Aaron Durbin adurbin@google.com wrote:
On Thu, Sep 26, 2019 at 10:06 AM Kyösti Mälkki kyosti.malkki@gmail.com 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.
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:
- Easy way to directly retrieve a device's chip config object w/o traversing the device hierarchy. Which leads to...
- Symbol alias for accessing struct device directly (no bdf lookup)
- Symbol alias for pci b/d/f lookup (equivalent of simple device but cleaner) so we can perform pci operations.
- 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? 6. Devicetree in ENV SMM is problematic when chip config is mutable in ENV_RAMSTAGE. 7. In general, trend seems to be the need to do more and earlier, like assign some resources of SATA or eMMC in romstage already.
Kyösti
On 27.09.19 15:42, Kyösti Mälkki wrote:
On Thu, Sep 26, 2019 at 7:45 PM Aaron Durbin adurbin@google.com wrote:
On Thu, Sep 26, 2019 at 10:06 AM Kyösti Mälkki kyosti.malkki@gmail.com 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:
- Easy way to directly retrieve a device's chip config object w/o traversing the device hierarchy. Which leads to...
- Symbol alias for accessing struct device directly (no bdf lookup)
More on this in a separate email.
- 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?
- 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.
- 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?
- Devicetree in ENV SMM is problematic when chip config is mutable in
ENV_RAMSTAGE.
Do we need chip config in SMM?
Nico
On Fri, Sep 27, 2019 at 7:42 PM Nico Huber nico.h@gmx.de wrote:
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?
I got side-tracked from the PCI development, also I noticed the one big [RFC] commit on my local tree I had never pushed.
1. I want to remove all preprocessor #ifdef __SIMPLE_DEVICE__ mess. We currently have that because of name collisions, some of that looked prettier prior to removal of device_t but we definitely do not want that back.
2. I have experimented with romstage, switching from passing immediate BDF value PCI_DEV(b,d,f) to struct pointer; I have not seen performance or code size penalty. Having inspected some of the generated objects, code patterns that transfer multiple register values from devtree.cb to a single PCI device are actually tighter assembly code (on x86). My vision here is we need to optimise the developer's use of time.
3. I want to keep pci_devfn_t available for PCI subsystem primitives, like <device/pci_mmio_cfg.h> and <arch/pci_io_cfg.h>. Also I would like to keep those files simple and see at most an anonymous struct device. I am not convinced if we are ready to really require C_ENVIRONMENT_BOOTBLOCK with next release? The forms with pci_devfn_t do work with romcc and we need that little PCI configuration in bootblocks.
4. I do not want to make devicetree compulsory for (gcc-built) bootblocks. But if we can drop the topology links there, the size impact would not be that bad. If we follow this approach, and get all romstages converted to use struct device, we could reconsider #3.
5. I don't plan to fix/clean amdfam10 from the preprocessor mess discussed here (or elsewhere).
Kyösti Mälkki
On Fri, Sep 27, 2019 at 10:42 AM Nico Huber nico.h@gmx.de wrote:
On 27.09.19 15:42, Kyösti Mälkki wrote:
On Thu, Sep 26, 2019 at 7:45 PM Aaron Durbin adurbin@google.com wrote:
On Thu, Sep 26, 2019 at 10:06 AM Kyösti Mälkki kyosti.malkki@gmail.com
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:
- Easy way to directly retrieve a device's chip config object w/o
traversing the device hierarchy. Which leads to...
- Symbol alias for accessing struct device directly (no bdf lookup)
More on this in a separate email.
- 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?
We could give it a go. One issue we have is the use of dev->bus->dev in encoding buses.
static __always_inline pci_devfn_t pcidev_bdf(const struct device *dev) {
-------return (dev->path.pci.devfn << 12) | (dev->bus->secondary << 20);
}
If we wanted to get to more code consistency we need a better way to track bus number (even though we don't use it in practice currently). It could be as simple as us just conditionally supporting buses > 0 or not depending on the environment. I don't think this is a huge blocker, but I wanted to bring it up.
To be explicit you are thinking the following?
struct device { struct device_path path; void *config; };
- 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.
- 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?
Ya. I think that's likely what is required.
- Devicetree in ENV SMM is problematic when chip config is mutable in
ENV_RAMSTAGE.
Do we need chip config in SMM?
I'm not sure. I don't recall us needing it at the moment.
Nico
On Fri, Sep 27, 2019 at 3:58 PM Aaron Durbin via coreboot coreboot@coreboot.org wrote:
- 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?
Ya. I think that's likely what is required.
https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src...
This function should really be in common code (and I guess called from SOC specific to supply the list) as it only seems to exist in skylake/apollolake dirs...
-duncan
On 26.09.19 18:45, Aaron Durbin via coreboot wrote:
Here's some of the requirements/issues we should resolve that come to mind:
- 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)
What we already have:
Static pointers to `struct device` for devices with a globally valid address (PCI devices on bus 0 and PNP devices), e.g.:
DEVTREE_CONST struct device *DEVTREE_CONST __pci_0_02_0 = &_dev6; DEVTREE_CONST struct device *DEVTREE_CONST __pnp_002e_00 = &_dev56;
What I suggested somewhere on Gerrit:
At the chip driver level, add a header file that maps these to more distinct names, e.g.
#define igd_dev __pci_0_02_0;
But that was last week. Since then I've written yet another override tree and realized something. We write a lot lines like
device pci 02.0 on end # Integrated Graphics Device
What's wrong with that? (if you know me it's obvious) there is a comment! IIRC, Kyösti suggested it already, we could let sconfig read a chip specific mapping for device names. That would also allow us to write the above as
device igd on end
Mapping could look like this:
device pci 00.0 alias mch device pci 02.0 alias igd
and we could directly generate pointers with these names:
DEVTREE_CONST struct device *DEVTREE_CONST igd_dev = &_dev6;
Limitations: Actually, chip drivers can't provide global names. What should sconfig generate if a second instance of a chip pops up? So the generated pointers must somehow be limited to chips that can only occur once, e.g. PCH, single socket CPU.
What do you think?
Nico
On Fri, Sep 27, 2019 at 11:11 AM Nico Huber nico.h@gmx.de wrote:
On 26.09.19 18:45, Aaron Durbin via coreboot wrote:
Here's some of the requirements/issues we should resolve that come to
mind:
- 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)
What we already have:
Static pointers to `struct device` for devices with a globally valid address (PCI devices on bus 0 and PNP devices), e.g.:
DEVTREE_CONST struct device *DEVTREE_CONST __pci_0_02_0 = &_dev6; DEVTREE_CONST struct device *DEVTREE_CONST __pnp_002e_00 = &_dev56;What I suggested somewhere on Gerrit:
At the chip driver level, add a header file that maps these to more distinct names, e.g.
#define igd_dev __pci_0_02_0;But that was last week. Since then I've written yet another override tree and realized something. We write a lot lines like
Have you pushed this patch?
device pci 02.0 on end # Integrated Graphics DeviceWhat's wrong with that? (if you know me it's obvious) there is a comment! IIRC, Kyösti suggested it already, we could let sconfig read a chip specific mapping for device names. That would also allow us to write the above as
device igd on endMapping could look like this:
device pci 00.0 alias mch device pci 02.0 alias igd
We can do this in 2 stages, I think, right? Or were you wanting to push a mapping along with the alias wording? I could run with what you had prior in patch from the get go and follow up with further clean up.
and we could directly generate pointers with these names:
DEVTREE_CONST struct device *DEVTREE_CONST igd_dev = &_dev6;Limitations: Actually, chip drivers can't provide global names. What should sconfig generate if a second instance of a chip pops up? So the generated pointers must somehow be limited to chips that can only occur once, e.g. PCH, single socket CPU.
What do you think?
Nico
On Fri, Sep 27, 2019 at 8:11 PM Nico Huber nico.h@gmx.de wrote:
On 26.09.19 18:45, Aaron Durbin via coreboot wrote:
Here's some of the requirements/issues we should resolve that come to mind:
- 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)
What we already have:
Static pointers to `struct device` for devices with a globally valid address (PCI devices on bus 0 and PNP devices), e.g.:
DEVTREE_CONST struct device *DEVTREE_CONST __pci_0_02_0 = &_dev6; DEVTREE_CONST struct device *DEVTREE_CONST __pnp_002e_00 = &_dev56;What I suggested somewhere on Gerrit:
At the chip driver level, add a header file that maps these to more distinct names, e.g.
#define igd_dev __pci_0_02_0;But that was last week. Since then I've written yet another override tree and realized something. We write a lot lines like
device pci 02.0 on end # Integrated Graphics DeviceWhat's wrong with that? (if you know me it's obvious) there is a comment! IIRC, Kyösti suggested it already, we could let sconfig read a chip specific mapping for device names. That would also allow us to write the above as
One way or another, I would like most of <soc/pci_devs.h> gone and same information derived from devicetree.cb files.
For the record, I am rebasing my local trees, this work removes most if not all #if __SIMPLE_DEVICE__ under soc/intel. Except for [1] and [2] I do not have any work pending related to providing usable alias names, or much interest to work on devicetree.cb parser.
[1] https://review.coreboot.org/c/coreboot/+/31936 [2] https://review.coreboot.org/c/coreboot/+/31934
Kyösti
-
Aaron Durbin -
awokd -
Duncan Laurie -
Kyösti Mälkki -
Matt DeVillier -
Nico Huber