lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 17 Jun 2014 17:42:14 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org, mark.brown@...aro.org
Cc:	Tomasz Figa <t.figa@...sung.com>,
	linux-samsung-soc@...r.kernel.org,
	Kukjin Kim <kgene.kim@...sung.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Pankaj Dubey <pankaj.dubey@...sung.com>,
	linux-kernel@...r.kernel.org, joshi@...sung.com,
	vikas.sajjan@...sung.com, chow.kim@...sung.com,
	Lee Jones <lee.jones@...aro.org>
Subject: Re: [PATCH RFC] mfd: syscon: Decouple syscon interface from syscon devices

On Tuesday 17 June 2014 17:32:44 Tomasz Figa wrote:
> 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.
> 
> Signed-off-by: Tomasz Figa <t.figa@...sung.com>

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.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ