+devicetree maintainers On Mon, Mar 18, 2024, Pandey, Radhey Shyam wrote: > > > > Instead, perhaps we can do it as following: > > * Keep the setting of the controller registers in the core > > * Create a software_node to pass a software property to the core > Thanks. By software property you mean flags or caps that can be passed > glue drivers to dwc3 core driver ? > > dwc3_set_quirks(struct dwc3 *dwc, u64 flags); > > Defines quirks in core.h > > DWC3_FLAGS_COMMON > DWC3_XLNX_CCI > DWC3_XLNX_IPD > DWC3_REALTEK_RES_FIX > > Then based on these quirks/flags program it in core.c. > Is this approach fine and aligned with your thoughts? > Not as a flag. Create 4 properties for GSBUSCFG0.DATRDREQINFO, DESRDREQINFO, DATWRREQINFO, and DESWRREQINFO in your glue driver. Pass them through your software node as PROPERTY_ENTRY_U16. The core will override the default coreConsultant value of GSBUSCFG0 based on these properties in dwc3_get_properties(). Check drivers/usb/dwc3/host.c for reference. > > > > > These software properties will not be documented in the devicetree > > binding. Just document them in the driver core header. They are simply > > driver properties that get passed through software node. > > > > You can add the software node using device_add_software_node(). This can > > be done before calling of_platform_populate() in dwc3-xilinx (can be > > done in pltfm_init()) > > > > Let me know if this works for you. > > Hi Rob/Krzysztof, Just want to check in with you for your opinion. To summarize my suggestion to Pandey, here are the key notes: * Platform specific settings are set in glue drivers (match through compatible string) * These settings are set by controller registers that should only be accessible in the dwc3 core * So, the suggestion is to pass these settings as properties using software_node created from the glue driver to the dwc3 core * These properties will not be documented in the devicetree binding, but only in the driver We're already doing that to some properties such as "linux,sysdev_is_parent" If this suggestion makes sense, would the prefix "linux," for linux specific binding or "snps," is a better fit? Thanks, Thinh
