Re: [Qemu-devel] [PATCH 2/2] pci: allow DeviceClass fw_name to override pci_dev_fw_name() if set

[Mark Cave-Ayland]

On 24/06/18 04:55, Michael S. Tsirkin wrote:

> On Sat, Jun 23, 2018 at 09:50:28AM +0100, Mark Cave-Ayland wrote:
> > The current implementation of pci_dev_fw_name() scans through a fixed
> > set of PCI class descriptions to determine the firmware device name
> > but in some cases this isn't always appropriate, for example with
> > the macio device which uses a class code of 0xff (unassigned).
> >
> > Rather than add a new entry for the macio device and risk a potential
> > clash with another unassigned device later, add a check to
> > pcibus_get_fw_dev_path() that will use DeviceClass fw_name if set in
> > preference to pci_dev_fw_name().
> >
> > This enables PCI devices such as macio to set dc->fw_name as required
> > to match the name specified in the firmware.
> >
> > Signed-off-by: Mark Cave-Ayland <address@hidden>
>
>
> Do we know no existing pci device sets this?

Here was my basic check:

# Find all files containing PCIDevice
find . -type f -exec grep -l "PCIDevice" {} \; > /tmp/pcidevices.txt
# Of these return files containing 'dc->fw_name'
for FILE in `cat /tmp/pcidevices.txt`; do grep -H 'dc->fw_name' $FILE; done;

./hw/ppc/spapr.c:        snprintf(cpu_model, 32, "address@hidden", dc->fw_name, 
index);
./hw/ppc/spapr.c:        nodename = g_strdup_printf("address@hidden", 
dc->fw_name, index);
./hw/ppc/spapr.c:    nodename = g_strdup_printf("address@hidden", dc->fw_name, 
id);
./hw/pci-bridge/pci_expander_bridge.c:    dc->fw_name = "pci";
./hw/pci-host/designware.c:    dc->fw_name = "pci";
./hw/pci-host/piix.c:    dc->fw_name = "pci";
./hw/pci-host/gpex.c:    dc->fw_name = "pci";
./hw/pci-host/xilinx-pcie.c:    dc->fw_name = "pci";
./hw/pci-host/q35.c:    dc->fw_name = "pci";
./hw/pci-host/prep.c:    dc->fw_name = "pci";

From what I can see the usage in spapr.c is for setting the DT CPU name 
whilst all of the others are derived from 
PCIE_HOST_BRIDGE/PCI_HOST_BRIDGE which are ultimately sysbus devices.


ATB,

Mark.