On 8/10/21 9:47 AM, Jeremy Linton wrote:

quoted

quoted

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index 53cab975f612..7d77fc72c2a4 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c

@@ -169,6 +169,9 @@ static struct mcfg_fixup mcfg_quirks[] = {

         ALTRA_ECAM_QUIRK(1, 13),
         ALTRA_ECAM_QUIRK(1, 14),
         ALTRA_ECAM_QUIRK(1, 15),
+
+       { "bcm2711", "", 0, 0, MCFG_BUS_ANY, &bcm2711_pcie_ops,
+         DEFINE_RES_MEM(0xFD500000, 0xA000) },
  };

  static char mcfg_oem_id[ACPI_OEM_ID_SIZE];

@@ -198,8 +201,19 @@ static void pci_mcfg_apply_quirks(struct acpi_pci_root *root,

         u16 segment = root->segment;
         struct resource *bus_range = &root->secondary;
         struct mcfg_fixup *f;
+       const char *soc;
         int i;

+       /*
+        * This could be a machine with a PCI/SMC conduit,
+        * which means it doens't have MCFG. Get the machineid from
+        * the namespace definition instead.
+        */
+       if (!fwnode_property_read_string(acpi_fwnode_handle(root->device),
+                                        "linux,pcie-quirk", &soc)) {
+               memcpy(mcfg_oem_id, soc, ACPI_OEM_ID_SIZE);
+       }
+

Is there any specific reason for not using the firmware agnostic API to get properties?


  if (!device_property_read_string(root->device, "linux,pcie-quirk", &soc)) {
      memcpy(mcfg_oem_id, soc, ACPI_OEM_ID_SIZE);
  }

IIRC it was because the "device" here isn't a struct device, rather a
struct acpi_device. I think this is the normal way in this situation
since we are directly picking up the fwnode rather than finding a
generic node and then backtracking to get the fwnode. 

Yes, you are right.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel