[BUG] usb: dwc2: Unsafe PCI fallback in dwc2_init_params may crash on non-PCI platforms

[realssl]

Dear Yinbo Zhu and Rob Herring,

I hope you are well.

While reviewing the DWC2 driver, I noticed a potential crash risk in the 
`dwc2_init_params` function (drivers/usb/dwc2/params.c), introduced by the 
combination of your two patches:

- Yinbo's PCI support patch (which added `pci_match_id` inside params.c)
- Rob's subsequent patch that replaced `of_match_device` with 
  `device_get_match_data` but retained the PCI fallback path.

The current code looks like this (simplified):

    set_params = device_get_match_data(hsotg->dev);
    if (set_params) {
        set_params(hsotg);
    } else {
        const struct pci_device_id *pmatch =
            pci_match_id(dwc2_pci_ids, to_pci_dev(hsotg->dev->parent));
        if (pmatch && pmatch->driver_data) {
            set_params = (set_params_cb)pmatch->driver_data;
            set_params(hsotg);
        }
    }

This design has one critical issue:

1. **Real crash on non-PCI platforms** – If the device is not a PCI device
   (e.g., platform/DT or ACPI) and `device_get_match_data()` returns NULL
   (missing match entry), the code falls back to the PCI path. It then calls
   `to_pci_dev(hsotg->dev->parent)` on a non-PCI parent device, resulting in a
   wild pointer. Subsequent `pci_match_id` and the function-pointer call will
   access invalid memory, leading to an `Unable to handle kernel paging request`
   and system crash.

This can be triggered on many ARM/RISC-V boards using DWC2 as a platform device,
especially if the device tree is missing a matching compatible or the driver
data is not properly set.

Could you please comment on whether you have plans to fix this? I believe the
proper solution is to move the PCI-specific matching logic out of the core
`params.c` and into `dwc2_pci.c`, where the probe function can explicitly set
the parameters. The core should only rely on `device_get_match_data()` and fall
back to safe defaults or return an error.

Thank you for your time and for your contributions to the kernel. I look
forward to your response.

BRs.liangliang.
Thanks.