Re: [PATCH] usb: cdns3: attempt to fix Kconfig dependencies

[Arnd Bergmann]

On Mon, Apr 6, 2026, at 03:30, Peter Chen (CIX) wrote:
> On 26-04-03 20:50:52, Arnd Bergmann wrote:
>> 
>> The only other alternative I see would be to split up the
>> platform driver support into separate modules for cdns3 and
>> cdnsp as well, which would make the dependencies trivial but
>> require reworking of the actual in a way that I haven't
>> been able to figure out yet. If you are already integrating
>> other changes for the next attempt, maybe you can try to
>> come up with a solution for this as well.
>
> Thanks for your suggestion, creating different platform driver
> between cdns3 and cdnsp is the way we used at downstream, but
> when I try to upstream cdsnp platform driver support, I find
> the two platforms driver are 95% identical in content, so I
> would like to keep one platform driver and one binding doc.

I gave this some more thought and realized that the best
way to handle it is probably by reworking the cdns3 driver
to no longer require the separate platform_device registration
for the child device. This would make it work like most other
drivers in the kernel, which helps both with the module
dependencies and with new developers working on it.

The way I think this can work would be:

- turn drivers/usb/cdns3/cdns3-plat.c into a library module
  that exports the probe/remove/suspend/resume functions
- Remove the of_platform_populate()/platform_device_unregister()
  calls from soc specific drivers
- Change the individual probe/remove callbacks to
  call the exported functions from the generic driver
- Integrate cdns3_platform_data into struct cdns, and
  pass that from the soc specific driver into the common
  code
- Set cdns->gadget_init in the soc specific driver

There may be additional steps needed to make this work, but
the result should be much cleaner.

> By the way, are there any randconfigs I could run to avoid
> the similar break, of course, I will pass my local USB
> randconfigs tests?

Not easily, my randconfig build setup works by having a
tree with lots of fixes and workarounds for all the known
unfixed issues, so I can see regressions more quickly
and test more of the corner cases than the automated
build bots do. In most cases, the 0day bot should find
the same regressions I do, but it will take a little
longer.

      Arnd