[...]

2) There are no requirements for arch/platforms/drivers to work in both cases
CONFIG_PM_RUNTIME=y/n. But they must be built without errors/warning for both
cases.

For cross SoC drivers this statement is not correct! Driver _must_
support the various combinations of CONFIG_PM*.

Therefore, I think it's better to strive towards a common solution and
to get the building blocks in place.

For example, for Keystone 2 only CONFIG_PM_RUNTIME=y is going to be supported
and if some one decided to disable it - it can be perfectly done from sys_fs/
user space.

I can't see why the sysfs option to disable runtime PM should affect
this discussion. That's done at runtime and after the device has been
probed.

3) pm_runtime_get_sync()(or similar) is good not only because i's waking up device, but also
because:
- it can wake up chain of devices (dev->parent->parent->...)

That's right. But that's not what this patchset aims to do.

I realize that the header of the cover letter isn't describing the
problem I am trying to solve very well. I guess the below header would
have been better:

"PM / Domains: Power up PM domains prior drivers starts to probe their devices"

- it can wake up power domain

Yes, but it requires CONFIG_PM_RUNTIME to be set.

Thus, to solve the problem during driver ->probe() we need another
solution which don't require CONFIG_PM_RUNTIME to be set. As this
patchset proposes.

- it connects device to domain/class/type/bus and so allow to add additional PM layer on top
  of Platform bus (for example arch/arm/mach-omap2/omap_device.c).

So, it will do all needed things, and if it doesn't that problem is in platfrom/bus/driver
code and not in Runtime PM.
if pm_runtime_get_sync() will be dropped - than all above will need to be implemented
around the ->probe().

I am not sure what you mean about dropping pm_runtime_get_sync()? All
I am saying is that we can't use it to power on PM domains during the
probe sequence.

Of course, you may still use pm_runtime_get_sync() from anywhere it's
needed, to for example handle device's parent/child relationships.

4) I've copied here comment from Rafael:
 >>>> Of course, if ->probe() is to call pm_runtime_resume() for this purpose,
 >>>> it must take the fact that the driver's own ->runtime_resume() may be called
 >>>> as a result of this into account.
 Agree, that's a little bit annoying, but we are living with that for more then
 5 years already (I'm 3 years) - so, I am, as driver developer, expecting above behavior
 (just walk through the drivers and you will see how many drivers expecting the same).

So, any volunteers to check and fix ~500 drivers.

We don't have to change these drivers. An certainly they are not 500. :-)

They will still work as is!

Though we need this fix to comply with them, which is supposed to go
in for 3.18 rc[n].
"PM / Domains: Fix initial default state of the need_restore flag"

[...]

Kind regards
Uffe