On Tue, 17 Jun 2014, Tomasz Figa wrote:

On 17.06.2014 17:42, Arnd Bergmann wrote:

quoted

On Tuesday 17 June 2014 17:32:44 Tomasz Figa wrote:

quoted

Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated driver. However in certain use
cases it is desirable to make a device used with another driver a syscon
interface provider. For example, certain SoCs (e.g. Exynos) contain
system controller blocks which perform various functions such as power
domain control, CPU power management, low power mode control, but in
addition contain certain IP integration glue, such as various signal
masks, coprocessor power control, etc. In such case, there is a need to
have a dedicated driver for such system controller but also share
registers with other drivers. The latter is where the syscon interface
is helpful.

This patch decouples syscon object from syscon driver, so that it can be
registered from any driver in addition to the original "syscon" platform
driver.

+1 for this approach.

Michal, Pankay,
  Does it also suit your needs?

quoted

quoted

Signed-off-by: Tomasz Figa <redacted>

Hi Tomasz,

This seems like a reasonable way of solving the problem, but I think
there is an even better one that we have about in the past: if we
promote syscon from a platform driver into a a drivers/base/ helper
that is independent of the platform device matching, we can use
call syscon_regmap_lookup_* for any device node, whether it's already
bound to a driver or not, which do what you need. It would also make
it easier to call the syscon code before the platform_device
infrastructure gets initialized, which is something a number of
people have asked for, e.g. for using regmap to do SMP bringup
or for clock registration.

Basically, unless I'm missing your point, this is what my patch does,
except that I don't move it to drivers/base/ and the registration
function I added require a pointer to struct device. Indeed, decoupling
it further from the driver model, by adding of_syscon_register() should
be useful for early users.

If agreed by Arnd, I think this work can be completed as a subsequent
patch.

Should I move this to drivers/base/, even though from current location
it can be used outside the platform driver anyway?

If I'm being honest with myself, I'd say that Syscon wasn't really an
MFD driver.  I'm happy to keep it in there any continue maintaining
it, but wouldn't block a move either.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog