linux-kernel - Re: [RFC 3/8] mfd:syscon: Introduce claim/read/write/release APIs

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:	Thu, 09 May 2013 15:00:16 +0100
From:	Srinivas KANDAGATLA <srinivas.kandagatla@...com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Arnd Bergmann <arnd@...db.de>, dong.aisheng@...aro.org,
	sameo@...ux.intel.com, Rob Landley <rob@...dley.net>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Russell King <linux@....linux.org.uk>,
	Linus Walleij <linus.walleij@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>,
	Stuart Menefy <stuart.menefy@...com>,
	Shawn Guo <shawn.guo@...aro.org>,
	Olof Johansson <olof@...om.net>,
	Jason Cooper <jason@...edaemon.net>,
	Stephen Warren <swarren@...dia.com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Nicolas Pitre <nico@...aro.org>,
	Will Deacon <will.deacon@....com>,
	Dave Martin <dave.martin@...aro.org>,
	Marc Zyngier <marc.zyngier@....com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org,
	linux-arm-kernel@...ts.infradead.org, linux-serial@...r.kernel.org
Subject: Re: [RFC 3/8] mfd:syscon: Introduce claim/read/write/release APIs

On 09/05/13 14:26, Mark Brown wrote:
> On Thu, May 09, 2013 at 12:58:01PM +0100, Srinivas KANDAGATLA wrote:
> 
>> Currently, we have two bits of information which come from device trees.
>> 1> The syscon bank/group definition itself.
>> 2> syscon register offsets and bits information to the drivers.
> 
>> These are the 2 things which keep changing per each SOC.
> 
>> There is no other way to pass this information to the drivers other than
>> passing them as part of their own device node and syscon node.
> 
> Sure there is, for example the drivers could have this information
> internally as part of knowing which device they're working with or they
> could take advantage of some patterns in the register map to store some
> higher level information that they use to configure.
> 
Some of layouts of the sysconf registers are totally changed for each SOC.

Looking at driver by driver maybe some drivers can take advantage of the
patterns, but Am not sure if this will be a sustainable solution for all
the drivers.

The big disadvantage of this approach is that
- Every driver has to be touched for new SOC,
- Secondly the drivers will end up having more of such information than
code over a time.

>>>  and to the extent that it is sensible it feels like something
>>> which might be useful with any device using register maps, not just
>>> syscon.
> 
>> If you think this is going to be useful for other drivers, Am happy to
>> move this out of syscon to regmap something like adding
>> of_regmap_field_claim/regmap_field_claim/regmap_field_read/regmap_field_write/regmap_field_release
>> functions.
> 
>> so any exiting drivers can still use the old syscon API to get the
>> regmap instance.
>> Alternatively they can use the new regmap APIs directly.
> 
> Well, I'd need to see the code to decide if it was sane but I do think
> that if this is a good approach it's not syscon specific.  Anything like
> this needs to be independent of DT too since not all architectures use
> DT.
In the suggested approach, the API supports, both DT and non-DT style.

for DT style user can use.
of_regmap_field_claim -> regmap_field_read -> regmap_field_write-
->regmap_field_release

and for NON-DT user can use
regmap_field_claim  -> regmap_field_read -> regmap_field_write-
->regmap_field_release


thanks,
srini


> 

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