LPe31002网卡的网卡适配器界面的部件编码（LPe31002-M6-AP） 和其他界面的pcie卡的部件编码（LPe31002-AP）不一致
操作系统：
软件版本： OpenUBMC2603
硬件配置：
适配完lpe31002网卡之后，升级最新的BMC版本
在网卡适配器界面的部件编码信息显示为（LPe31002-M6-AP）在其他的pcie卡界面显示为（LPe31002-AP）
期望结果是两个信息一致
两个信息不一致
代码参考了lpe35002网卡的数据来源，发现适配时两个信息跟lpe35002的数据来源相同，但是lpe35002的两界面的部件编码信息相同，不明白为什么lpe31002的这两个界面的部件编码信息不同
造成两个数据不同的个原因可能是因为网卡适配器界面的部件编码信息是来源于PLDM，pcie卡界面的信息来源于Pcie配置空间，两张卡数据不同源，但是参考了lpe35002网卡，数据虽然不同源，但是两个界面的部件编码信息相同。
答案内容由AI生成，仅供参考：
根据社区的处理结论（针对同类问题），解决方向如下：
PCIeCard.PartNumber 也能从EEPROM更新社区回复明确指出：
“PCIe卡角度，从日志来看，使用了设备树方式加载，但是没有配置FruData，这种情况会从sr里取PartNumber——如果需要卡的PartNumber能从eeprom中更新，需要配置FruData，可以参考SP680的配置。”
也就是说，在CSR/SR文件中正确配置 FruData，使北向资源树能够主动从FRU数据中获取部件编码，而不是依赖SR中的静态值。
社区特别指出：
“不建议自己更新PartNumber。”
以及：
“厂商代码不应违反已经在社区评审过的帖子的约束。”
因此，正确的处理方式是推动厂商（博通/Emulex）的南向代码遵循社区规范，不应在运行时自行更新设备树的PartNumber属性，而是通过配置 FruData 由BMC框架统一完成数据同步。这样才能保证两个界面的部件编码保持一致。
| 现象 | 原因 |
|---|---|
网卡适配器界面显示 LPe31002-M6-AP |
厂商南向代码通过PLDM从FRU读取并覆写了设备树属性 |
PCIe卡界面显示 LPe31002-AP |
北向资源树 PCIeCard.PartNumber 使用SR配置值，未被同步更新 |
| 两个界面不一致 | 资源树 → 设备树仅首次同步，厂商代码违反社区规范自行更新设备树且未同步北向 |
根本结论：这不是数据源不同本身导致的问题，而是厂商南向代码违规修改了设备树属性，且未同步到北向资源树所致。解决该问题需要遵循社区规范，通过配置 FruData 让BMC框架统一管理PartNumber的获取与同步，而不是放任厂商代码自行覆写。
您所描述的LPe31002网卡“网卡适配器界面”与“PCIe卡界面”部件编码不一致的问题，与社区中已知的FC卡PartNumber不同步问题（涉及LPe32002）属于同一种类型。根据上下文中的讨论记录，可以对根因进行如下解释。
PCIeCard.PartNumber）：该界面显示的是资源树上的配置值，通常来源于SR（CSR）配置文件中的定义。根据社区讨论记录（对应LPe32002 FC卡的同类型问题）明确指出：
“component_drivers组件中会使用pldm命令去获取fru信息，然后把获取到的PartNumber值更新到设备树，但是资源树上的PCIeCard.PartNumber没有同步。”
“这部分代码是博通厂商南向的代码，会更新设备树的属性，北向的属性没有被同步。”
这正好解释了您的现象：
LPe31002-AP；LPe31002-M6-AP。社区回复强调：
“代码逻辑是从资源树到设备树，只有第一次上树的时候会用设备树的东西同步资源树。不建议自己更新PartNumber。”
也就是说，只有在资源对象第一次创建（上树）时，才会用设备树中的信息去初始化资源树。此后，南向设备树属性的任何变化都不会自动反映到北向资源树上，导致两个界面的部件编码不一致。
社区在评审该问题时给出的明确立场是：
“厂商代码不应违反已经在社区评审过的帖子的约束。”
这意味着LPe31002（以及LPe32002）的厂商适配代码在运行时直接修改设备树属性，违反了社区既定的数据流规范（资源树 → 设备树的单向同步原则），这是问题产生的直接原因。
关于您提到的LPe35002网卡，上下文没有提供LPe35002的具体适配细节，因此无法直接确认其配置方式。
但根据社区讨论中体现的规范原则可以推断：LPe35002很可能未采用类似的厂商南向覆写逻辑，或者其FRU中读出的部件编码与SR配置值一致，因此两个界面的显示没有产生差异。这与“厂商代码不应违反社区约束”的原则是一致的——差异的根源在于厂商代码行为是否符合规范，而非数据源本身是否不同。
根据社区的处理结论（针对同类问题），解决方向如下：
PCIeCard.PartNumber 也能从EEPROM更新社区回复明确指出：
“PCIe卡角度，从日志来看，使用了设备树方式加载，但是没有配置FruData，这种情况会从sr里取PartNumber——如果需要卡的PartNumber能从eeprom中更新，需要配置FruData，可以参考SP680的配置。”
也就是说，在CSR/SR文件中正确配置 FruData，使北向资源树能够主动从FRU数据中获取部件编码，而不是依赖SR中的静态值。
社区特别指出：
“不建议自己更新PartNumber。”
以及：
“厂商代码不应违反已经在社区评审过的帖子的约束。”
因此，正确的处理方式是推动厂商（博通/Emulex）的南向代码遵循社区规范，不应在运行时自行更新设备树的PartNumber属性，而是通过配置 FruData 由BMC框架统一完成数据同步。这样才能保证两个界面的部件编码保持一致。
| 现象 | 原因 |
|---|---|
网卡适配器界面显示 LPe31002-M6-AP |
厂商南向代码通过PLDM从FRU读取并覆写了设备树属性 |
PCIe卡界面显示 LPe31002-AP |
北向资源树 PCIeCard.PartNumber 使用SR配置值，未被同步更新 |
| 两个界面不一致 | 资源树 → 设备树仅首次同步，厂商代码违反社区规范自行更新设备树且未同步北向 |
根本结论：这不是数据源不同本身导致的问题，而是厂商南向代码违规修改了设备树属性，且未同步到北向资源树所致。解决该问题需要遵循社区规范，通过配置 FruData 让BMC框架统一管理PartNumber的获取与同步，而不是放任厂商代码自行覆写。
这卡是你们自己适配的CSR吗?
是的
检查一下网卡对象的PartNumber是从什么属性同步过去的
网卡的partnumber属性值是从pcie配置空间获取的，依赖bios上报
指的是NetworkAdapter的PartNumber是怎么来的，PCIeCard上最优先是用Fru上的部件编码
networkadapter的partnumber刚开始会使用SR文件中配置的值，但是后续会被PLDM里面的值更新，优先级pldm里的值比较高
如果来源不一致，二者不一致也正常，卡上配的不一致就会不一致。
好的
这边如果确定解决可以点一下解决方案