usb: dwc3: pci: Store device properties dynamically

Quoted 64 lines · Andy Shevchenko

Quoted 22 lines · Thinh Nguyen

Quoted 21 lines · Andy Shevchenko

Quoted 18 lines · Thinh Nguyen

Quoted 8 lines · Andy Shevchenko

Quoted 5 lines · Thinh Nguyen

Add the ability to add device properties dynamically. Currently, device properties are added to platform device using platform_device_add_properties(). However, this function does not allow adding properties incrementally. It is useful to have this ability when the driver needs to set common device properties across different HW

Quoted 7 lines

I'm not sure it's useful anyhow.

Quoted 3 lines

or
if IP and FPGA validation test different configurations for different HW.

Shouldn't be a separate stuff for FPGA exclusively?

Can you clarify/expand your question?

Quoted 8 lines

Quoted 5 lines

FPGA is the one which might have different properties at run time for the same device.
So, why do we care on driver / generic level of it?

Shouldn't be FPGA manager take care of it (via DT overlays, for example)?

Normally it is handled using DT overlays. But for using FPGA as PCI device, I'm not aware of a better solution.

If it's a PCI device, it may utilize PCI (hot plug if you would like to change IP at run time) with appropriate IDs and stuff, right?

Quoted 18 lines

Quoted 13 lines

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

Introduce two new functions to do so:
* dwc3_pci_add_one_property() - this function adds one property to dwc->properties array and increase its size as needed
* dwc3_pci_add_properties() - this function takes a null terminated array of device properties and add them to dwc->properties

Quoted 6 lines

Quoted 1 line

So, why you can't use ACPI / DT here?

dwc3_pci_add_properties() is a convenient function that takes statically allocated array of (quirks) properties for different HW and store them to dwc->properties. The idea is to add more properties on top of these required quirks.

Quoted 4 lines

Yes, I understand that. What's wrong with DT? The built-in device properties have the same nature as usual properties for DT. Whenever driver calls device_property_read_uXX() or alike it would check all property provides for asked one.

Quoted 5 lines

I may not have explained fully in my commit message the purpose of this change. That's why I think I misinterpreted your previous question.

With this new debugging feature, we want to delay adding device properties until the user initiates it.

So, see above.
When user wants to enable this IP at run time it will be a PCI hot plug event which makes device appear behind PCI switch. When device appears it would have it's own VndrID/DevID + sub pair.

Quoted 3 lines

Based on that IDs you may apply hard coded quirks (though I am against quirks in new hardware) as it's done right now.

Hi Andy,

Using VID/PID is not really feasible for our use case. If we only had a few concrete devices then it would be ok.

But understand that this an IP running on an FPGA validation platform. The IP is very large and flexible with *many* parameters that we must test against. It is also deployed by our customers with widely varying configurations. So we are constantly testing these as well.

One of the last pieces for moving our FPGA validation completely to the in-kernel Linux stack is the ability to configure the driver to set parameters that are not visible to the driver, or with parameters that we want to constrain for testing.