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]

Message-ID: <518B8F49.5020902@st.com>
Date:	Thu, 09 May 2013 12:58:01 +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 10:51, Mark Brown wrote:
> On Wed, May 08, 2013 at 06:42:04PM +0100, Srinivas KANDAGATLA wrote:
> 
> Fix your mailer to word wrap within paragraphs.
> 
Sorry about that.
>> Ultimately the syscon_write use the regmap_update_bits, however we
>> really want is the flexibility in using/referring the syscon
>> registers/bits in both device-trees and non-device tree cases.
> 
> So what you're looking for here is some way to offload discovery of
> register fields from the driver?

Exactly,

As the System configuration registers change per each SOC, and the
logic/code to drive still remain same across SOCs.

It makes sense to abstract the information of sysconf register and its
offsets from the driver, as we do not want to change the driver per each
SOC.

> 
>> The reason for these APIs, is the extent of syscon usage is very high
>> in ST set-top-box parts.
> 
>> Without these new APIs, its very difficult to pass this information to
>> the drivers.
> 
> I'm not 100% convinced that putting all this information into DT is a
> good idea,

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.

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

regmap_field_claim to claim bits of the register
of_regmap_field_claim DT version of reg_map_field_claim.
regmap_field_write to write to bits of register
regmap_field_read to bit of the register.
regmap_field_release to release the bits of the register.

For DT version it might involve adding new member to struct
regmap_config to lookup regmap by phandle, so that regmap can get hold
of regmap instance from device tree phandle.
syscon driver already does this in syscon_regmap_lookup_by_phandle()

On the device tree side it will look like:
syscfg_sbc:syscon@...00000{
	compatible	= "syscon";
	reg		= <0xfe600000 0x1000>;
};

node {
	property-1 = <&syscfg_sbc 10 0 31>;
};

property has "phandle", register_offset, lsb, msb.

On the driver side, it can just use the API's like

field = of_regmap_field_claim(np, "property-1");
regmap_field_write(field, val);
regmap_field_release(field);

All this involves is very minimal code change in syscon and a new APIs
and DT awareness into regmap.

What do you think?

Thanks,
srini

>  For example many MFDs have similar needs - essentially the
> system controllers are just a particular kind of MFD.  To me that says
> that this should be outside syscon so other things can use it.

> 

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