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]

Message-id: <007901cf8f9b$fe27ae70$fa770b50$@samsung.com>
Date:	Tue, 24 Jun 2014 16:33:28 +0530
From:	Pankaj Dubey <pankaj.dubey@...sung.com>
To:	'Lee Jones' <lee.jones@...aro.org>,
	'Tomasz Figa' <tomasz.figa@...il.com>
Cc:	'Arnd Bergmann' <arnd@...db.de>,
	linux-arm-kernel@...ts.infradead.org, mark.brown@...aro.org,
	'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>,
	linux-kernel@...r.kernel.org, joshi@...sung.com,
	vikas.sajjan@...sung.com, chow.kim@...sung.com,
	michal.simek@...inx.com
Subject: RE: [PATCH RFC] mfd: syscon: Decouple syscon interface from syscon
 devices

Hi,

On Wednesday, June 18 2014, Lee Jones wrote:
> On Tue, 17 Jun 2014, Tomasz Figa wrote:
> > 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.
> 
> +1 for this approach.
> 
> Michal, Pankay,
>   Does it also suit your needs?
> 

Sorry for late reply. 
I tested this patch after changing exynos PMU to be a syscon provider and it's working well.
So if we can address Arnd's comments, this patch will be helpful in making exynos PMU a 
complete platform driver.

Thanks,
Pankaj Dubey

> > >> 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.
> 
> 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

--
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/