On 6/8/2020 12:26 PM, Nicolas Saenz Julienne wrote:
> The Raspberry Pi 4 gets its USB functionality from VL805, a PCIe chip
> that implements the xHCI. After a PCI fundamental reset, VL805's
> firmware may either be loaded directly from an EEPROM or, if not
> present, by the SoC's co-processor, VideoCore. RPi4's VideoCore OS
> contains both the non public firmware load logic and the VL805 firmware
> blob.
>
> We control this trough a reset controller device that's able to trigger
> the aforementioned process when relevant.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@xxxxxxx>
> ---
[snip]
> +static int rpi_usb_reset_reset(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct rpi_usb_reset *priv = to_rpi_usb(rcdev);
> + u32 dev_addr;
> + int ret;
> +
> + /*
> + * The pci device address is expected like this:
> + *
> + * PCI_BUS << 20 | PCI_SLOT << 15 | PCI_FUNC << 12
> + *
> + * But since rpi's PCIe setup is hardwired, we know the address in
> + * advance.
> + */
> + dev_addr = 0x100000;
You could encode the device address as part of the reset identifier,
such that if we ever have more devices to reset, then we only need to
define new identifiers for them, and internally within your reset
controller provide you can resolve that reset identifier 0 is PCI_BUS <<
20 | PCI_SLOT << 15 | PCI_FUN << 12 for instance.
This would make your reset controller define a "#reset-cells" property
to 1 now, such that no further DT ABI breakage would occur if you were
to extend it later on.
--
Florian
