23.08.2021 17:33, Thierry Reding пишет: > On Sat, Aug 21, 2021 at 08:45:54PM +0300, Dmitry Osipenko wrote: >> 20.08.2021 16:08, Ulf Hansson пишет: >> ... >>>> I suppose if there's really no good way of doing this other than >>>> providing a struct device, then so be it. I think the cleaned up sysfs >>>> shown in the summary above looks much better than what the original >>>> would've looked like. >>>> >>>> Perhaps an additional tweak to that would be to not create platform >>>> devices. Instead, just create struct device. Those really have >>>> everything you need (.of_node, and can be used with RPM and GENPD). As I >>>> mentioned earlier, platform device implies a CPU-memory-mapped bus, >>>> which this clearly isn't. It's kind of a separate "bus" if you want, so >>>> just using struct device directly seems more appropriate. >>> >>> Just a heads up. If you don't use a platform device or have a driver >>> associated with it for probing, you need to manage the attachment to >>> genpd yourself. That means calling one of the dev_pm_domain_attach*() >>> APIs, but that's perfectly fine, ofcourse. >>> >>>> >>>> We did something similar for XUSB pads, see drivers/phy/tegra/xusb.[ch] >>>> for an example of how that was done. I think you can do something >>>> similar here. >> >> We need a platform device because we have a platform device driver that >> must be bound to the device, otherwise PMC driver state won't be synced >> since it it's synced after all drivers of devices that reference PMC >> node in DT are probed. > > I think the causality is the wrong way around. It's more likely that you > added the platform driver because you have a platform device that you > want to bind against. > > You can have drivers bind to other types of devices, although it's a bit > more work than abusing platform devices for it. > > There's the "auxiliary" bus that seems like it would be a somewhat > better fit (see Documentation/driver-api/auxiliary_bus.rst), though it > doesn't look like this fits the purpose exactly. I think a custom bus > (or perhaps something that could be deployed more broadly across CCF) > would be more appropriate. > > Looking around, it seems like clk/imx and clk/samsung abuse the platform > bus in a similar way, so they would benefit from a "clk" bus as well. It may be nice to have a dedicated clk bus, but this is too much effort for nearly nothing in our case. It shouldn't be a problem to convert drivers to use clk bus once it will be implemented. It shouldn't be a part of this series, IMO.
