xHCI's PCI fixup, run at the end of pcie-brcmstb's probe, depends on
RPi4's VideoCore firmware interface to be up and running. It's possible
for both initializations to race, so make sure it's available prior
starting.
Signed-off-by: Nicolas Saenz Julienne <[email protected]>
---
drivers/pci/controller/pcie-brcmstb.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index d20aabc26273..9600052f768c 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -28,6 +28,8 @@
#include <linux/string.h>
#include <linux/types.h>
+#include <soc/bcm2835/raspberrypi-firmware.h>
+
#include "../pci.h"
/* BRCM_PCIE_CAP_REGS - Offset for the mandatory capability config regs */
@@ -917,11 +919,24 @@ static int brcm_pcie_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node, *msi_np;
struct pci_host_bridge *bridge;
+ struct device_node *fw_np;
struct brcm_pcie *pcie;
struct pci_bus *child;
struct resource *res;
int ret;
+ /*
+ * We have to wait for the Raspberry Pi's firmware interface to be up
+ * as some PCI fixups depend on it.
+ */
+ fw_np = of_find_compatible_node(NULL, NULL,
+ "raspberrypi,bcm2835-firmware");
+ if (fw_np && !rpi_firmware_get(fw_np)) {
+ of_node_put(fw_np);
+ return -EPROBE_DEFER;
+ }
+ of_node_put(fw_np);
+
bridge = devm_pci_alloc_host_bridge(&pdev->dev, sizeof(*pcie));
if (!bridge)
return -ENOMEM;
--
2.25.0
On 2/19/20 4:39 AM, Nicolas Saenz Julienne wrote:
> xHCI's PCI fixup, run at the end of pcie-brcmstb's probe, depends on
> RPi4's VideoCore firmware interface to be up and running. It's possible
> for both initializations to race, so make sure it's available prior
> starting.
>
> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
It does not look like there is something making sure that
CONFIG_RASPBERRYPI_FIRMWARE is being selected or depended on, should we
have a "default XHCI_PCI" added to drivers/firmware/Kconfig?
--
Florian
On Wed, 2020-02-19 at 11:21 -0800, Florian Fainelli wrote:
> On 2/19/20 4:39 AM, Nicolas Saenz Julienne wrote:
> > xHCI's PCI fixup, run at the end of pcie-brcmstb's probe, depends on
> > RPi4's VideoCore firmware interface to be up and running. It's possible
> > for both initializations to race, so make sure it's available prior
> > starting.
> >
> > Signed-off-by: Nicolas Saenz Julienne <[email protected]>
>
> Reviewed-by: Florian Fainelli <[email protected]>
>
> It does not look like there is something making sure that
> CONFIG_RASPBERRYPI_FIRMWARE is being selected or depended on, should we
> have a "default XHCI_PCI" added to drivers/firmware/Kconfig?
I think having that would enable the firmware interface for all XHCI_PCI users,
which isn't ideal. The firmware call has stubs for the case the firmware
interace isn't compiled, so no problem there. Ultimately we want to enable
CONFIG_RASPBERRYPI_FIRMWARE only when the built image targets the RPi4
(reglardless of being arm64/arm32). But I don't think that's feasible.
Regards,
Nicolas
On 2/20/2020 10:14 AM, Nicolas Saenz Julienne wrote:
> On Wed, 2020-02-19 at 11:21 -0800, Florian Fainelli wrote:
>> On 2/19/20 4:39 AM, Nicolas Saenz Julienne wrote:
>>> xHCI's PCI fixup, run at the end of pcie-brcmstb's probe, depends on
>>> RPi4's VideoCore firmware interface to be up and running. It's possible
>>> for both initializations to race, so make sure it's available prior
>>> starting.
>>>
>>> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
>>
>> Reviewed-by: Florian Fainelli <[email protected]>
>>
>> It does not look like there is something making sure that
>> CONFIG_RASPBERRYPI_FIRMWARE is being selected or depended on, should we
>> have a "default XHCI_PCI" added to drivers/firmware/Kconfig?
>
> I think having that would enable the firmware interface for all XHCI_PCI users,
> which isn't ideal. The firmware call has stubs for the case the firmware
> interace isn't compiled, so no problem there. Ultimately we want to enable
> CONFIG_RASPBERRYPI_FIRMWARE only when the built image targets the RPi4
> (reglardless of being arm64/arm32). But I don't think that's feasible.
It would enable the driver, which is only functional if the matching
Device Tree node is present, that seems like a reasonable price to pay
for a multiplatform kernel. After all, this is a functional dependency
for the Pi4.
--
Florian