On Mon, 26 Nov 2018 19:28:02 +0000 vitor <vitor.soares@xxxxxxxxxxxx> wrote: > On 26/11/18 19:08, Boris Brezillon wrote: > > On Mon, 26 Nov 2018 19:56:18 +0100 > > Boris Brezillon <boris.brezillon@xxxxxxxxxxx> wrote: > > > >>> - for the others it will easy the SoC integration avoiding > >>> duplicated work and doing things from scratch. > >> What would be duplicated? You want to support a new SoC, just add a new > >> entry in the of_match_table and you're done. When you need to add > >> SoC/integration specific stuff, create a struct and attach a different > >> instance per-compatible so that each SoC can have its own configuration > >> (or even init sequence if needed). That's how we do for pretty much all > >> IPs out there, why should designware ones be different? > > To be more specific, I'd like a real example that shows why the > > separation is needed. > > Ok no problem. We can delay this for PCI and other rules support. I finally understand what this separation is all about: supporting both PCI and platform devices. I guess I've been distracted by this sentence: " This patch will allow SOC integrators to add their code specific to DesignWare I3C IP. " which for me meant each SoC would have its own platform_driver. In any case, I think this is a bit premature do this separation, unless you already know about one integrator planning to expose this IP over PCI.
