tree c6db93cec270cc6bc2be6c105d4ffe7031732c00
parent a91e0057b56edf05b153b0e5f9bab8e0eecf99f2
author Gunnar Mills <gmills@us.ibm.com> 1729883387 -0500
committer Gunnar Mills <gunnar@gmills.xyz> 1730302208 +0000

Remove 2nd incorrect TotalCores

bmcweb has 2 places where it is setting the processor's TotalCores, here
and in the getCpuDataByInterface call[1].

The way being removed of getting TotalCores, assumes the path of cores
is <processorPath/core*>, it also has some interesting logic for
present.

The getCpuDataByInterface goes out to D-Bus and gets the CoreCount
value, part of the CPU interface[2] in PDI.

IBM isn't using this path way of getting TotalCores. Don't see any
company that is but hard to know. Since this way is wrong, don't think
we should put behind a meson option, instead just remove.

History:
Aug, 2019: IBM added getting "TotalCores" by assuming this core path[3]
Aug, 2020: Intel added CPU properties including corecount to PDI[4]
Sept, 2020: Intel adds using this D-Bus property[5]

Long term, it would be good to model the cores, the cores and processor
have an association,[6] the bmcweb review for the cores is using this
association[7].

[1]: https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/processor.hpp#L133
[2]: https://github.com/openbmc/phosphor-dbus-interfaces/blob/73c931fb942daa714bfff17e950b9d5622a25842/yaml/xyz/openbmc_project/Inventory/Item/Cpu.interface.yaml#L46
[3]: https://github.com/openbmc/bmcweb/commit/ec8faf9243b6f6320daeb3ba6a94d1f257034506
[4]: https://github.com/openbmc/phosphor-dbus-interfaces/commit/259f49e0c40b287d9ea79f77db1654da47161340
[5]: https://github.com/openbmc/bmcweb/commit/029cc1f4106968f7e871d17a8bcb71a303a12ffa
[6]: https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/56395
[7]: https://gerrit.openbmc.org/c/openbmc/bmcweb/+/38570

Tested: It builds. TotalCores is still there.

Change-Id: I9f244a33eca0e4a9838eb55ada09733807439877
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>