linux-kernel - Re: [PATCH RFC] mfd: syscon: Decouple syscon interface from syscon devices

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 23:26:22 +0200
From:	Tomasz Figa <tomasz.figa@...il.com>
To:	Arnd Bergmann <arnd@...db.de>,
	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

Hi Arnd,

On 17.06.2014 17:42, Arnd Bergmann wrote:
> 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.

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.

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

Best regards,
Tomasz
--
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/