linux-kernel - Re: [PATCH] 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, 02 Sep 2014 10:14:57 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	Lee Jones <lee.jones@...aro.org>, kgene.kim@...sung.com,
	linux@....linux.org.uk, naushad@...sung.com,
	Pankaj Dubey <pankaj.dubey@...sung.com>,
	Tomasz Figa <t.figa@...sung.com>, linux-kernel@...r.kernel.org,
	joshi@...sung.com, vikas.sajjan@...sung.com,
	linux-samsung-soc@...r.kernel.org, broonie@...nel.org,
	thomas.ab@...sung.com, chow.kim@...sung.com
Subject: Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices

On Tuesday 02 September 2014 09:05:16 Lee Jones wrote:
> On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> 
> > On Monday 01 September 2014 17:04:26 Lee Jones wrote:
> > > On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> > > > Maybe I'm misreading the patch, but I don't see how it creates a
> > > > migration path. What I want to end up with is infrastructure that
> > > > lets anybody call syscon_regmap_lookup_by_pdevname or
> > > > syscon_regmap_lookup_by_compatible (if they really need to)
> > > > without needing the platform_driver for syscon. That should not
> > > > require any form of compatibility layer because to the driver
> > > > using it there is no API change.
> > > 
> > > Somehow I think the likelyhood is that I am misreading the patch.
> > > 
> > > I thought that before this patch drivers we had to register a syscon
> > > device to bind to this driver, which was fine for the first use-cases
> > > of syscon as it wasn't required too early during boot.  However, now
> > > there are use-cases where systems require access to syscon registers
> > > eariler in boot we require a means to obtain access prior to device
> > > probing.  I thought this patch not only provides that possibilty, but
> > > also leaves in the ability to register direct from DT.
> > 
> > Right, it does provide the ability to have syscon before devices
> > are registered, I missed that part.
> > 
> > > > In contrast, this patch introduces a new of_syscon_{un,}register()
> > > > interface that would get removed after the the above has
> > > > been implemented, causing extra churn for any driver that also
> > > > wants to provide a regmap-like interface.
> > > 
> > > When will we ever not have to register syscon?
> > 
> > The idea is that we implicitly register the syscon block when someone
> > calls syscon_regmap_lookup_by_compatible or syscon_regmap_lookup_by_phandle
> > and then return a reference to that new syscon. When another driver
> > looks up the same device node, we just pass a reference to the existing
> > syscon.
> 
> Doesn't sound too unreasonable.  So how about instead of exporting
> these new of_syscon_{un,}register() calls, we make them static and
> call them from syscon_regmap_lookup_by_{phandle,compatible}?

Yes, that would be a good start. We should think about whether we want
to remove the existing DT probing at the same time, since it becomes
unused, and we might want to move the code to drivers/base/regmap_*.c
at some point.

	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/