PCI: Use pci_speed_string() for all PCI/PCI-X/PCIe strings

PCI: Use pci_speed_string() for all PCI/PCI-X/PCIe strings

BugLink: https://bugs.launchpad.net/bugs/1970798
Previously some PCI speed strings came from pci_speed_string(), some came
from the PCIe-specific PCIE_SPEED2STR(), and some came from a PCIe-specific
switch statement.  These methods were inconsistent:

  pci_speed_string()     PCIE_SPEED2STR()     switch
  ------------------     ----------------     ------
  33 MHz PCI
  ...
  2.5 GT/s PCIe          2.5 GT/s             2.5 GT/s
  5.0 GT/s PCIe          5 GT/s               5 GT/s
  8.0 GT/s PCIe          8 GT/s               8 GT/s
  16.0 GT/s PCIe         16 GT/s              16 GT/s
  32.0 GT/s PCIe         32 GT/s              32 GT/s

Standardize on pci_speed_string() as the single source of these strings.

Note that this adds ".0" and "PCIe" to some messages, including sysfs
"max_link_speed" files, a brcmstb "link up" message, and the link status
dmesg logging, e.g.,

  nvme 0000:01:00.0: 16.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x4 link at 0000:00:01.1 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)

I think it's better to standardize on a single version of the speed text.
Previously we had strings like this:

  /sys/bus/pci/slots/0/cur_bus_speed: 8.0 GT/s PCIe
  /sys/bus/pci/slots/0/max_bus_speed: 8.0 GT/s PCIe
  /sys/devices/pci0000:00/0000:00:1c.0/current_link_speed: 8 GT/s
  /sys/devices/pci0000:00/0000:00:1c.0/max_link_speed: 8 GT/s

This changes the latter two to match the slots files:

  /sys/devices/pci0000:00/0000:00:1c.0/current_link_speed: 8.0 GT/s PCIe
  /sys/devices/pci0000:00/0000:00:1c.0/max_link_speed: 8.0 GT/s PCIe

Based-on-patch by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
(backport from commit 6348a34dcb98d8e285685a205f2a601817fa2d38)
[context adjustment to remove changes to pcie-brcmstb.c]
Signed-off-by: Ian May <ian.may@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>